|
1)
Message boards :
GPUs :
Radeon RX 7900 XTX Linux (Fedora) Crashes Frequently
(Message 112176)
Posted 27 Jun 2023 by Paul Post: Okay, it looks like at least Sam was able to get it working and is crunching with the 7900. System looks stable, turning in lots of tasks consistently. Sam used the AMD installer on Ubuntu LTS. It's not clear how much OSS that includes, but it could be the proprietary driver, too; I don't understand that installer very well. Devastating, but I guess that's something I have to expect. Not sure what to do. It's bad enough that I would have to do a full reinstall on an encrypted system, but to have to switch to another distro, and LTS at that...I'm used to getting the latest kernels. But, I suppose I could live without it. That will take a lot of planning, even if I decided to do it. |
|
2)
Message boards :
GPUs :
Radeon RX 7900 XTX Linux (Fedora) Crashes Frequently
(Message 112173)
Posted 27 Jun 2023 by Paul Post: Right. I was really convinced for a long while that it was thermal. But, with the manufacturer's help, I think we ruled that out. I was using boinccmd to manually throttle GPU crunching and keep temps very low, like 75 C junction temps, and that didn't improve the symptoms. Also, I let the thing run hot hot hot, like 100 C junction, for over an hour before it crashed, which wasn't worse than when I kept it cold. My 5700XT had a problem with thermals. It behaved *very* similarly before I increased the fan curve, then all problems went away. So, I was *sure* this problem was also thermal. But, after a lot of testing, it doesn't seem correlated to thermals. The manufacturer is quite confident about this, and I reluctantly agree, finally. Another confusing factor is that, since this problem started so long ago, I've actually upgraded my distro's major version (and many weekly updates) during the course of testing. In that time, I've had rocm-opencl updates, mesa updates, and LLVM updates. My system still has LLVM15 libs, which I *think* is what is being used for ROCm OCL, but the default/main LLVM is v16. If there is a problem with the driver and/or OCL stack, I wonder if it could be something with LLVM? I mean, that makes some sense, right? |
|
3)
Message boards :
GPUs :
Radeon RX 7900 XTX Linux (Fedora) Crashes Frequently
(Message 112158)
Posted 27 Jun 2023 by Paul Post: I had seen that thread, that's the thread I was referring to in my original post. It's interesting how different the distributions can be. My symptoms are quite different: I had a few results marked as 'invalid', but very few actual errors. The errors that did occur were catastrophic, and the driver couldn't contain them, causing the whole display subsystem to fail. That's the issue I mean to bring up here. When it crunches and completes work, it seems fine. Perhaps more invalids than my 6800XT, but it's also faster, so, perhaps the same rate of invalids, but I don't know because it won't stay running for 24 hrs straight, so I can't get a good average! I checked the ICD on my system, as you suggest. Thanks for that suggestion. AFAICT, it is correct. I only have one icd file, it's owned by the same package (ROCm-opencl v.5.5.1) that owns the library to which it points, and that .so exists and had a good sig. It also seems pretty current, but internal vs external numbering makes it hard to know. I'm hoping the manufacturer has something helpful to tell me, but that will take a few more days. Sounds like I got a lemon, though, at this point. An expensive lemon. Everyone thought that things would get fixed, driver-wise, when the PRO cards go released, but that happened two months ago. So, I'm pretty confused. |
|
4)
Message boards :
GPUs :
Radeon RX 7900 XTX Linux (Fedora) Crashes Frequently
(Message 112154)
Posted 26 Jun 2023 by Paul Post: That would be good in the aggregate. But, it's a disaster for me with this card. I don't know what I'm going to do. I feel like the new drivers are much better, overall, because the installation issues have mostly been resolved, despite the fact that my distro isn't supported. Catalyst is really really old, too. The current drivers eliminated direct OpenCL support years go. I think all of RDNA2 was ROCm-based only. So, this feels like an RDNA3-specific issue, not a driver development issue, although I grant that it is hard to make such a distinction; both issues could occur at the same time. |
|
5)
Message boards :
GPUs :
Radeon RX 7900 XTX Linux (Fedora) Crashes Frequently
(Message 112143)
Posted 26 Jun 2023 by Paul Post: Hi Keith, That is all true. However, I've had great--well, we can call it luck, then--with AMD for the past 10 years. I wouldn't be so concerned or upset if it wasn't so far outside my typical experience. AMD is currently occupying a very unique space and I've become quite dependent on them, I now realize. This is the first experience I've ever had like this. In fact, it's probably the worst experience with hardware I've ever had, at least since the time in the 90s when I got a shaved and re-labeled CPU from a highly reputable local reseller. I think it is likely a driver problem. Since the professional cards you mention are not even out yet, I'm hoping the drivers will improve when those cards finally hit the retail market. AMD has made a commitment to support the OSS ecosystem, so I don't think my expectations are wholly unreasonable. The consumer cards are expensive enough. If I ever had a hope to get a PRO card, they are long gone since the price spike last year. |
|
6)
Message boards :
GPUs :
Radeon RX 7900 XTX Linux (Fedora) Crashes Frequently
(Message 112122)
Posted 25 Jun 2023 by Paul Post: I saw user @1082528 (magic_sam)'s post about problems getting BOINC to recognize a 7900 GPU on Ubuntu LTS, but that experience seems very different from mine on Fedora. Since Fedora has been including (some) ROCm pkgs in their distribution, no thrid-party software is necessary to get OpenCL running. This has (and is) working perfectly fine with a 6800XT as I write. (Although, I get more invalid WUs than I would like.) When I put the 7900 in the same system, I get a frequent crashes the desktop (but not the rest of the system) while crunching with BOINC. I've tried running it in my system on three different occasions and, eventually, it starts crashing so frequently I cannot use the system. Einstein@Home is the only project for which I do GPU crunching. I'm posting here since I'm hoping more folks here may be using the card for other projects. I've even had the card RMA-ed and I've been talking to the manufacturer about the problem. I originally thought it was a temperature issue, since I had strong evidence that was a problem with my 5700XT and the 7900 lacks any fan control on Linux, but I'm now convinced temps are not the issue. My best idea now is that there is a problem with AMDGPU or the OpenCL stack. There are lots of reports against AMDGPU of crashes within various games, but I don't have that problem; my issues occur outside of games. - Is anyone else having frequent crashes with OpenCL on the 7900? - Any advice? I'm wondering if should try to debug E@H as it runs, but that sounds difficult. |
|
7)
Message boards :
Projects :
Milkyway is down and unreachable
(Message 107380)
Posted 14 Mar 2022 by Paul Post: Okay, things seem working again. |
|
8)
Message boards :
Projects :
Milkyway is down and unreachable
(Message 107370)
Posted 14 Mar 2022 by Paul Post: Seems down to me, now. I've had problems for a few days, and out of work for more than 24 hours. I can't get to homepage, forums, status page, and BOINC times out talking to servers. |
|
9)
Message boards :
BOINC Manager :
boincmgr Broken after Linux Weekly Package Update
(Message 107283)
Posted 5 Mar 2022 by Paul Post: Did you run "./_autosetup -f" after the last updates? Yes |
|
10)
Message boards :
BOINC Manager :
boincmgr Broken after Linux Weekly Package Update
(Message 107271)
Posted 4 Mar 2022 by Paul Post: That's one idea, but there's no guarantee that will work of my case. Since no one seems to know what is wrong, there's no reason to think that would work, either. I've heard of such things, infrequently, in my 22 years of UNIX/Linux system administration, but I've never found that to be the solution. I know why that works for M$ Windows, but I don't understand why that works in Linux. It would probably take me two full days to rebuild my system from scratch, and, if I actually had the time for that, I'd spend it finding the problem, rather than reinstalling 99 % of things that are working. Besides, I can test that idea and learn more by building it on my VM without rebuilding my system. So, we'll know if there is anything wrong with my build+system combo more quickly by doing that. Or, as someone else suggested, I could get the boincmgr binary from my distribution and either, just copy that, or ldd it and see if it's linked any differently than my own build. I think there are still some outstanding troubleshooting tasks I could try. |
|
11)
Message boards :
BOINC Manager :
boincmgr Broken after Linux Weekly Package Update
(Message 107255)
Posted 3 Mar 2022 by Paul Post: You could replace the self compiled boincmgr executable with that from the distro. Hmm, this is pretty intriguing. Thanks for the link because it says on that page that Fedora 35, my distro, has 3.1.5 in it's offical repository, but it wasn't installed on my system, and I didn't even see that pkg when I searched the repository. So, I checked in the Fedora build system, itself, and I see that the package wxGTK (no '3') is actually the 3.1.5 version. That was shocking to me, because I remember the case I just recounted to you in the previous post when wxGTK pkg was 2.x! So, when I saw wxGTK pkg in the repo, I assumed it was still version 2.x for compatibility, and that wxGTK3, which I have, would be the right one. Why would I think that they are going back to the unnumbered package for an minor revision update of the numbered package? Confusing. Anyway, it was trivial to install wxGTK pkg and rebuild, using the --with-wx-config build option I mentioned. Now I have this: $ ldd ./clientgui/boincmgr | grep '(not found|wx)'
libwx_gtk3u_webview-3.1.so.5 => /lib64/libwx_gtk3u_webview-3.1.so.5 (0x00007f13c1c70000)
libwx_gtk3u_xrc-3.1.so.5 => /lib64/libwx_gtk3u_xrc-3.1.so.5 (0x00007f13c1b83000)
libwx_gtk3u_html-3.1.so.5 => /lib64/libwx_gtk3u_html-3.1.so.5 (0x00007f13c1aa8000)
libwx_gtk3u_qa-3.1.so.5 => /lib64/libwx_gtk3u_qa-3.1.so.5 (0x00007f13c1a7c000)
libwx_gtk3u_core-3.1.so.5 => /lib64/libwx_gtk3u_core-3.1.so.5 (0x00007f13c1259000)
libwx_baseu_xml-3.1.so.5 => /lib64/libwx_baseu_xml-3.1.so.5 (0x00007f13c1241000)
libwx_baseu_net-3.1.so.5 => /lib64/libwx_baseu_net-3.1.so.5 (0x00007f13c11e7000)
libwx_baseu-3.1.so.5 => /lib64/libwx_baseu-3.1.so.5 (0x00007f13c0fa4000)
But, alas, the new binary fails with the same exit code (193) as the other one. I get the feeling something else, something deeper, has changed and I don't know what. It must have been caused by an update, but since I always have boincmgr running, it had to have been one of just a few updates I did before the last reboot. I could try to review those and see if anything sticks out. I don't have time to check right now, though. I wonder if wxGTK got updated and what I really need to do it is downgrade it? ...No, looks like the only version of wxGTK3 in F35 is the one I have, so that's not it. I really don't think it's related to wxGTK; we've ruled it out, AFAICT. I wonder if it would be easier to try to build it on my F35 or F36 VM and just see if it runs. |
|
12)
Message boards :
BOINC Manager :
boincmgr Broken after Linux Weekly Package Update
(Message 107250)
Posted 2 Mar 2022 by Paul Post:
Yes, that's what I did. I would use the distro boincmgr, but it depends on a system boinc service. I had problems with that a long time ago and just gave up. At the time, it was hard to allow a system service to access the GPU. I assume that's been solved, but I'm happy with my current setup, otherwise, so I'd prefer not to switch. Building boincmgr has been very successful over the decades, so this is a surprising change. It's interesting that you mention wx_GTK! The last time I had some trouble building boincmgr was when there was a different default wx_GTK version on my system than what boincmgr wanted. IIRC, it was around the switch from 2.x to 3.0. Do you remember that? I had to give the build option -- let's see, I made a note of this at the time, yeah, here it is -- --with-wx-config=/usr/bin/wx-config-3.0. Yeah, now I remember, the configure script wasn't finding wx-config-3.0, it was still finding wx-config, so I had to point it to the new version, which my system had, but it wasn't the default. Now 3.0 is the default. I see 3.0.5.1 is actually the devel package that is installed. That is the closest thing to this that I can remember, and now you bring up wxGTK, so maybe we're on the right track. But, since there is only one wx-config file on the system (and all aliases that point to it), I don't think the build is getting confused about which version to use. checking for wx-config... /usr/bin/wx-config checking for wxWidgets version >= 3.0.0... yes (version 3.0.5) checking for wxWidgets static library... no checking if wxWidgets works... yes checking for default wxWidgets config... gtk3-unicode-3.0 checking for wxwidgets options... --unicode=yes checking wxWidgets config to use... gtk3-unicode-3.0 checking for wx-config... (cached) /usr/bin/wx-config checking for wxWidgets version >= 3.0.0 ( --unicode=yes)... yes (version 3.0.5) checking for wxWidgets static library... no checking if wxWidgets uses the GTK+ toolkit... gtk+-3.0 But, I guess it could be another case of a new devel pkg that isn't the default...hmm, that'd be *exactly* the same thing. Guess I haven't checked to see if there is a newer stable release... Looks like 3.0.5 is the latest stable version and my distro doesn't have any newer versions packaged. But, 3.1.5 is available from the project. Do you think that is worth trying? I don't think anything on my system could be built against a version that didn't have a corresponding -devel pkg in the repo, but I could be wrong about that, I guess. |
|
13)
Message boards :
BOINC Manager :
boincmgr Broken after Linux Weekly Package Update
(Message 107235)
Posted 1 Mar 2022 by Paul Post: One of the reasons I stopped updating my systems, and disable auto update. Yeah, that's one way to handle it. That's not an option right now, though. I can hardly go back to having a separate chassis for crunching, at least not at the current market prices for GPUs! Besides, even if I did, I couldn't leave my desktop *not* crunching; just wouldn't feel right after 22 years of BOINC work. ;-) I considered that approach many years ago: If I spend my main budget on my cruncher box for RAC, my desktop will not be enjoyable, and if I skimp on my cruncher box, I'll have low RAC *and* my desktop will be just be idle when it could be crunching. |
|
14)
Message boards :
BOINC Manager :
boincmgr Broken after Linux Weekly Package Update
(Message 107234)
Posted 1 Mar 2022 by Paul Post: Did you check whether all required libs are available after the update? Ah, no that's a good idea... $ ldd boincmgr
linux-vdso.so.1 (0x00007fff181f6000)
libnotify.so.4 => /lib64/libnotify.so.4 (0x00007f2b05ad7000)
libwx_gtk3u_xrc-3.0.so.0 => /lib64/libwx_gtk3u_xrc-3.0.so.0 (0x00007f2b05a05000)
libwx_gtk3u_webview-3.0.so.0 => /lib64/libwx_gtk3u_webview-3.0.so.0 (0x00007f2b059e1000)
libwx_gtk3u_html-3.0.so.0 => /lib64/libwx_gtk3u_html-3.0.so.0 (0x00007f2b0590e000)
libwx_gtk3u_qa-3.0.so.0 => /lib64/libwx_gtk3u_qa-3.0.so.0 (0x00007f2b058e3000)
libwx_gtk3u_adv-3.0.so.0 => /lib64/libwx_gtk3u_adv-3.0.so.0 (0x00007f2b05714000)
libwx_gtk3u_core-3.0.so.0 => /lib64/libwx_gtk3u_core-3.0.so.0 (0x00007f2b05110000)
libwx_baseu_xml-3.0.so.0 => /lib64/libwx_baseu_xml-3.0.so.0 (0x00007f2b050fc000)
libwx_baseu_net-3.0.so.0 => /lib64/libwx_baseu_net-3.0.so.0 (0x00007f2b050b8000)
libwx_baseu-3.0.so.0 => /lib64/libwx_baseu-3.0.so.0 (0x00007f2b04e88000)
libcurl.so.4 => /lib64/libcurl.so.4 (0x00007f2b04de3000)
libssl.so.1.1 => /lib64/libssl.so.1.1 (0x00007f2b04d46000)
libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f2b04a56000)
libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007f2b0498b000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f2b04977000)
libX11.so.6 => /lib64/libX11.so.6 (0x00007f2b0482f000)
libXss.so.1 => /lib64/libXss.so.1 (0x00007f2b0482a000)
libgtk-3.so.0 => /lib64/libgtk-3.so.0 (0x00007f2b04013000)
libgdk-3.so.0 => /lib64/libgdk-3.so.0 (0x00007f2b03f0b000)
libz.so.1 => /lib64/libz.so.1 (0x00007f2b03ef1000)
libpangocairo-1.0.so.0 => /lib64/libpangocairo-1.0.so.0 (0x00007f2b03edf000)
libpango-1.0.so.0 => /lib64/libpango-1.0.so.0 (0x00007f2b03e78000)
libharfbuzz.so.0 => /lib64/libharfbuzz.so.0 (0x00007f2b03da1000)
libatk-1.0.so.0 => /lib64/libatk-1.0.so.0 (0x00007f2b03d77000)
libcairo-gobject.so.2 => /lib64/libcairo-gobject.so.2 (0x00007f2b03d69000)
libcairo.so.2 => /lib64/libcairo.so.2 (0x00007f2b03c4d000)
libgdk_pixbuf-2.0.so.0 => /lib64/libgdk_pixbuf-2.0.so.0 (0x00007f2b03c1d000)
libgio-2.0.so.0 => /lib64/libgio-2.0.so.0 (0x00007f2b03a43000)
libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x00007f2b039e7000)
libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007f2b038ac000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f2b0368b000)
libm.so.6 => /lib64/libm.so.6 (0x00007f2b035af000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f2b03594000)
libc.so.6 => /lib64/libc.so.6 (0x00007f2b0338a000)
libwebkit2gtk-4.0.so.37 => /lib64/libwebkit2gtk-4.0.so.37 (0x00007f2b007bb000)
libmspack.so.0 => /lib64/libmspack.so.0 (0x00007f2b007a6000)
libSDL2-2.0.so.0 => /lib64/libSDL2-2.0.so.0 (0x00007f2b005fd000)
libSM.so.6 => /lib64/libSM.so.6 (0x00007f2b005f2000)
libpng16.so.16 => /lib64/libpng16.so.16 (0x00007f2b005b9000)
libjpeg.so.62 => /lib64/libjpeg.so.62 (0x00007f2b00537000)
libtiff.so.5 => /lib64/libtiff.so.5 (0x00007f2b004b0000)
libexpat.so.1 => /lib64/libexpat.so.1 (0x00007f2b0047d000)
libnghttp2.so.14 => /lib64/libnghttp2.so.14 (0x00007f2b00455000)
libidn2.so.0 => /lib64/libidn2.so.0 (0x00007f2b00434000)
libssh.so.4 => /lib64/libssh.so.4 (0x00007f2b003c5000)
libpsl.so.5 => /lib64/libpsl.so.5 (0x00007f2b003b1000)
libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f2b0035a000)
libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f2b0027a000)
libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f2b00262000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f2b0025b000)
libldap_r-2.4.so.2 => /lib64/libldap_r-2.4.so.2 (0x00007f2b001ff000)
liblber-2.4.so.2 => /lib64/liblber-2.4.so.2 (0x00007f2b001ec000)
libbrotlidec.so.1 => /lib64/libbrotlidec.so.1 (0x00007f2b001de000)
libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f2b001c9000)
libxcb.so.1 => /lib64/libxcb.so.1 (0x00007f2b0019e000)
libXext.so.6 => /lib64/libXext.so.6 (0x00007f2b00189000)
libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0 (0x00007f2b00182000)
libpangoft2-1.0.so.0 => /lib64/libpangoft2-1.0.so.0 (0x00007f2b00167000)
libfontconfig.so.1 => /lib64/libfontconfig.so.1 (0x00007f2b00118000)
libfribidi.so.0 => /lib64/libfribidi.so.0 (0x00007f2b000f8000)
libepoxy.so.0 => /lib64/libepoxy.so.0 (0x00007f2afffc3000)
libXi.so.6 => /lib64/libXi.so.6 (0x00007f2afffb1000)
libatk-bridge-2.0.so.0 => /lib64/libatk-bridge-2.0.so.0 (0x00007f2afff78000)
libcloudproviders.so.0 => /lib64/libcloudproviders.so.0 (0x00007f2afff5e000)
libtracker-sparql-3.0.so.0 => /lib64/libtracker-sparql-3.0.so.0 (0x00007f2affe99000)
libwayland-client.so.0 => /opt/amdgpu/lib64/libwayland-client.so.0 (0x00007f2affc87000)
libXfixes.so.3 => /lib64/libXfixes.so.3 (0x00007f2affc7e000)
libxkbcommon.so.0 => /lib64/libxkbcommon.so.0 (0x00007f2affc35000)
libwayland-cursor.so.0 => /opt/amdgpu/lib64/libwayland-cursor.so.0 (0x00007f2affa2d000)
libwayland-egl.so.1 => /opt/amdgpu/lib64/libwayland-egl.so.1 (0x00007f2aff82b000)
libXcursor.so.1 => /lib64/libXcursor.so.1 (0x00007f2aff81e000)
libXdamage.so.1 => /lib64/libXdamage.so.1 (0x00007f2aff817000)
libXcomposite.so.1 => /lib64/libXcomposite.so.1 (0x00007f2aff812000)
libXrandr.so.2 => /lib64/libXrandr.so.2 (0x00007f2aff805000)
libXinerama.so.1 => /lib64/libXinerama.so.1 (0x00007f2aff800000)
libthai.so.0 => /lib64/libthai.so.0 (0x00007f2aff7f5000)
libgraphite2.so.3 => /lib64/libgraphite2.so.3 (0x00007f2aff7d2000)
libpixman-1.so.0 => /lib64/libpixman-1.so.0 (0x00007f2aff726000)
libxcb-shm.so.0 => /lib64/libxcb-shm.so.0 (0x00007f2aff721000)
libxcb-render.so.0 => /lib64/libxcb-render.so.0 (0x00007f2aff711000)
libXrender.so.1 => /lib64/libXrender.so.1 (0x00007f2aff704000)
libmount.so.1 => /lib64/libmount.so.1 (0x00007f2aff6bd000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f2aff692000)
libffi.so.6 => /lib64/libffi.so.6 (0x00007f2aff687000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f2aff60f000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2b05b17000)
libwpe-1.0.so.1 => /lib64/libwpe-1.0.so.1 (0x00007f2aff604000)
libWPEBackend-fdo-1.0.so.1 => /lib64/libWPEBackend-fdo-1.0.so.1 (0x00007f2aff5eb000)
libEGL.so.1 => /opt/amdgpu/lib64/libEGL.so.1 (0x00007f2aff3a5000)
libjavascriptcoregtk-4.0.so.18 => /lib64/libjavascriptcoregtk-4.0.so.18 (0x00007f2afde4d000)
libxml2.so.2 => /lib64/libxml2.so.2 (0x00007f2afdcc3000)
libsqlite3.so.0 => /lib64/libsqlite3.so.0 (0x00007f2afdb85000)
libxslt.so.1 => /lib64/libxslt.so.1 (0x00007f2afdb40000)
libOpenGL.so.0 => /lib64/libOpenGL.so.0 (0x00007f2afdb15000)
libGLX.so.0 => /lib64/libGLX.so.0 (0x00007f2afdae1000)
libwoff2dec.so.1.0.2 => /lib64/libwoff2dec.so.1.0.2 (0x00007f2afdad4000)
libharfbuzz-icu.so.0 => /lib64/libharfbuzz-icu.so.0 (0x00007f2afdacf000)
libgcrypt.so.20 => /lib64/libgcrypt.so.20 (0x00007f2afd993000)
libgstapp-1.0.so.0 => /lib64/libgstapp-1.0.so.0 (0x00007f2afd97d000)
libgstbase-1.0.so.0 => /lib64/libgstbase-1.0.so.0 (0x00007f2afd8f6000)
libgstreamer-1.0.so.0 => /lib64/libgstreamer-1.0.so.0 (0x00007f2afd7a3000)
libgstpbutils-1.0.so.0 => /lib64/libgstpbutils-1.0.so.0 (0x00007f2afd75f000)
libgstaudio-1.0.so.0 => /lib64/libgstaudio-1.0.so.0 (0x00007f2afd6db000)
libgsttag-1.0.so.0 => /lib64/libgsttag-1.0.so.0 (0x00007f2afd698000)
libgstvideo-1.0.so.0 => /lib64/libgstvideo-1.0.so.0 (0x00007f2afd5d2000)
libgstgl-1.0.so.0 => /lib64/libgstgl-1.0.so.0 (0x00007f2afd54e000)
libgstfft-1.0.so.0 => /lib64/libgstfft-1.0.so.0 (0x00007f2afd540000)
libopenjp2.so.7 => /lib64/libopenjp2.so.7 (0x00007f2afd4e6000)
libwebpdemux.so.2 => /lib64/libwebpdemux.so.2 (0x00007f2afd4df000)
libwebp.so.7 => /lib64/libwebp.so.7 (0x00007f2afd470000)
libsoup-2.4.so.1 => /lib64/libsoup-2.4.so.1 (0x00007f2afd3c9000)
libenchant-2.so.2 => /lib64/libenchant-2.so.2 (0x00007f2afd3bb000)
libsecret-1.so.0 => /lib64/libsecret-1.so.0 (0x00007f2afd36c000)
libtasn1.so.6 => /lib64/libtasn1.so.6 (0x00007f2afd354000)
libhyphen.so.0 => /lib64/libhyphen.so.0 (0x00007f2afd34c000)
liblcms2.so.2 => /lib64/liblcms2.so.2 (0x00007f2afd2e7000)
libwayland-server.so.0 => /opt/amdgpu/lib64/libwayland-server.so.0 (0x00007f2afd0d2000)
libmanette-0.2.so.0 => /lib64/libmanette-0.2.so.0 (0x00007f2afd0a1000)
libseccomp.so.2 => /lib64/libseccomp.so.2 (0x00007f2afd07f000)
libicui18n.so.69 => /lib64/libicui18n.so.69 (0x00007f2afcd54000)
libicuuc.so.69 => /lib64/libicuuc.so.69 (0x00007f2afcb60000)
libsystemd.so.0 => /lib64/libsystemd.so.0 (0x00007f2afca8e000)
libICE.so.6 => /lib64/libICE.so.6 (0x00007f2afca70000)
libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f2afca65000)
libzstd.so.1 => /lib64/libzstd.so.1 (0x00007f2afc9b6000)
libjbig.so.2.1 => /lib64/libjbig.so.2.1 (0x00007f2afc9a8000)
libunistring.so.2 => /lib64/libunistring.so.2 (0x00007f2afc823000)
libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f2afc812000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f2afc809000)
libsasl2.so.3 => /lib64/libsasl2.so.3 (0x00007f2afc7e9000)
libbrotlicommon.so.1 => /lib64/libbrotlicommon.so.1 (0x00007f2afc7c6000)
libXau.so.6 => /lib64/libXau.so.6 (0x00007f2afc7c0000)
libdbus-1.so.3 => /lib64/libdbus-1.so.3 (0x00007f2afc76e000)
libatspi.so.0 => /lib64/libatspi.so.0 (0x00007f2afc72f000)
libstemmer.so.0 => /lib64/libstemmer.so.0 (0x00007f2afc6da000)
libjson-glib-1.0.so.0 => /lib64/libjson-glib-1.0.so.0 (0x00007f2afc6ad000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f2afc6a8000)
libdatrie.so.1 => /lib64/libdatrie.so.1 (0x00007f2afc69f000)
libblkid.so.1 => /lib64/libblkid.so.1 (0x00007f2afc665000)
libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007f2afc5ce000)
libgbm.so.1 => /opt/amdgpu/lib64/libgbm.so.1 (0x00007f2afc3bf000)
libglapi.so.0 => /opt/amdgpu/lib64/libglapi.so.0 (0x00007f2afc186000)
libX11-xcb.so.1 => /lib64/libX11-xcb.so.1 (0x00007f2afc181000)
libxcb-dri2.so.0 => /lib64/libxcb-dri2.so.0 (0x00007f2afc178000)
libxcb-xfixes.so.0 => /lib64/libxcb-xfixes.so.0 (0x00007f2afc16e000)
libdrm.so.2 => /opt/amdgpu/lib64/libdrm.so.2 (0x00007f2afbf5a000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f2afbf55000)
libxcb-dri3.so.0 => /lib64/libxcb-dri3.so.0 (0x00007f2afbf4e000)
libxcb-present.so.0 => /lib64/libxcb-present.so.0 (0x00007f2afbf49000)
libxcb-sync.so.1 => /lib64/libxcb-sync.so.1 (0x00007f2afbf3d000)
libxshmfence.so.1 => /lib64/libxshmfence.so.1 (0x00007f2afbf38000)
liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f2afbf0c000)
libGLdispatch.so.0 => /lib64/libGLdispatch.so.0 (0x00007f2afbe54000)
libwoff2common.so.1.0.2 => /lib64/libwoff2common.so.1.0.2 (0x00007f2afbe4f000)
libicudata.so.69 => /lib64/libicudata.so.69 (0x00007f2afa2f2000)
libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00007f2afa2cc000)
libunwind.so.8 => /lib64/libunwind.so.8 (0x00007f2afa2b2000)
libdw.so.1 => /lib64/libdw.so.1 (0x00007f2afa21c000)
liborc-0.4.so.0 => /lib64/liborc-0.4.so.0 (0x00007f2afa198000)
libgstallocators-1.0.so.0 => /lib64/libgstallocators-1.0.so.0 (0x00007f2afa18f000)
libevdev.so.2 => /lib64/libevdev.so.2 (0x00007f2afa170000)
libgudev-1.0.so.0 => /lib64/libgudev-1.0.so.0 (0x00007f2afa162000)
liblz4.so.1 => /lib64/liblz4.so.1 (0x00007f2afa13e000)
libcap.so.2 => /lib64/libcap.so.2 (0x00007f2afa134000)
libcrypt.so.2 => /lib64/libcrypt.so.2 (0x00007f2afa0f8000)
libelf.so.1 => /lib64/libelf.so.1 (0x00007f2afa0dd000)
libudev.so.1 => /lib64/libudev.so.1 (0x00007f2afa0b1000)
$ ldd boinc | grep -v 0x
$ ldd boinccmd | grep -v 0x
IIRC, it says "not found" if something is missing, right? So, everything is there. I don't think boincmgr would build successfully if it couldn't link, so such an error should be caught a build time, too. But, yeah, easy enough to check, so, good suggestion. |
|
15)
Message boards :
BOINC Manager :
boincmgr Broken after Linux Weekly Package Update
(Message 107233)
Posted 1 Mar 2022 by Paul Post: Is it just the manager crashing or is the client not running either? Just the manager is crashing on start. boinc runs the client and it seems fine. |
|
16)
Message boards :
BOINC Manager :
boincmgr Broken after Linux Weekly Package Update
(Message 107202)
Posted 25 Feb 2022 by Paul Post: I typically keep up on my distribution updates. After updating, today, boincmgr will not run. I tried to rebuild it from src, but that didn't help, which is odd because that has certainly has fixed similar problems in the past, many times. On the other hand, that would happen between major distribution version updates, not weekly, bug fix updates. I'm currently running Fedora 35. There is no output from boincmgr to the console, but the program exits with code 193. I also see this: stderrgui.txt: SIGABRT: abort called Stack trace (33 frames): ./boincmgr[0x5f85b0] /lib64/libc.so.6(+0x42750)[0x7f2d5c23a750] /lib64/libc.so.6(+0x8f88c)[0x7f2d5c28788c] /lib64/libc.so.6(raise+0x16)[0x7f2d5c23a6a6] /lib64/libc.so.6(abort+0xd3)[0x7f2d5c2247d3] /lib64/libwebkit2gtk-4.0.so.37(+0x626d97)[0x7f2d59c4fd97] /lib64/libwebkit2gtk-4.0.so.37(+0x970405)[0x7f2d59f99405] /lib64/libwebkit2gtk-4.0.so.37(+0x970f15)[0x7f2d59f99f15] /lib64/libwebkit2gtk-4.0.so.37(+0x8853ec)[0x7f2d59eae3ec] /lib64/libwebkit2gtk-4.0.so.37(+0x86a227)[0x7f2d59e93227] /lib64/libwebkit2gtk-4.0.so.37(+0x899b42)[0x7f2d59ec2b42] /lib64/libwebkit2gtk-4.0.so.37(+0x9015dc)[0x7f2d59f2a5dc] /lib64/libgobject-2.0.so.0(+0x22e37)[0x7f2d5c877e37] /lib64/libgobject-2.0.so.0(g_object_new_with_properties+0x20d)[0x7f2d5c878d1d] /lib64/libgobject-2.0.so.0(g_object_new+0xc1)[0x7f2d5c879821] /lib64/libwebkit2gtk-4.0.so.37(+0x8eeb79)[0x7f2d59f17b79] /lib64/libglib-2.0.so.0(g_once_impl+0x65)[0x7f2d5c792c25] /lib64/libwebkit2gtk-4.0.so.37(webkit_web_context_get_default+0x45)[0x7f2d59f17c65] /lib64/libwx_gtk3u_webview-3.0.so.0(_ZN15wxWebViewWebKit6CreateEP8wxWindowiRK8wxStringRK7wxPointRK6wxSizelS4_+0x14f)[0x7f2d5e8692af] /lib64/libwx_gtk3u_webview-3.0.so.0(_ZN9wxWebView3NewEP8wxWindowiRK8wxStringRK7wxPointRK6wxSizeS4_lS4_+0x162)[0x7f2d5e86a1c2] ./boincmgr[0x538b00] ./boincmgr[0x538d63] ./boincmgr[0x5acb4f] ./boincmgr[0x47b011] ./boincmgr[0x47b841] ./boincmgr[0x483b08] ./boincmgr[0x4b1da1] ./boincmgr[0x4b34c4] /lib64/libwx_baseu-3.0.so.0(_Z7wxEntryRiPPw+0x9a)[0x7f2d5dde46aa] ./boincmgr[0x44a6b8] /lib64/libc.so.6(+0x2d560)[0x7f2d5c225560] /lib64/libc.so.6(__libc_start_main+0x7c)[0x7f2d5c22560c] ./boincmgr[0x455605] Exiting... I strace-ed it, but that didn't provide me any insights. |
|
17)
Message boards :
Questions and problems :
Only Computing Schedule Preferences Not Working
(Message 97770)
Posted 16 Apr 2020 by Paul Post: Hi Keith. Hey, great tip to restart BOINC mgr. After 20 years, that is a dependency I hadn't noticed before. I think that was it; seems to be using my schedule, now. |
|
18)
Message boards :
Questions and problems :
Only Computing Schedule Preferences Not Working
(Message 97725)
Posted 16 Apr 2020 by Paul Post: I'm having an odd problem with my BOINC manager. It says I'm "Using web-based preference" from a specific project, and that seems to work as I have made many changes over the years and my client seems to update pretty quickly. When I update BOINC, the log shows the new preferences. But, I've tried to use the schedule to limit the time of day that BOINC computes and these settings, specifically, seem to have no effect. When I make changes and update, the log shows the preferences are checked, but it reports no changes. Any idea what could be happening? |
|
19)
Message boards :
GPUs :
Recent frequent linux errors with amdgpu, kernel 5.10+, multiple projects
(Message 97232)
Posted 2 Apr 2020 by Paul Post: Two weekends ago I did a normal system update and got kernel 5.10. Since then, I've been getting a lot of this: Apr 01 22:24:41 hostname kernel: [drm:amdgpu_ttm_backend_bind [amdgpu]] *ERROR* failed to pin userptr Apr 01 22:24:41 hostname kernel: ------------[ cut here ]------------ Apr 01 22:24:41 hostname kernel: kernel BUG at mm/slub.c:304! Apr 01 22:24:41 hostname kernel: invalid opcode: 0000 [#1] SMP NOPTI Apr 01 22:24:41 hostname kernel: CPU: 1 PID: 11895 Comm: setiathome_8.22 Not tainted 5.5.11-200.fc31.x86_64 #1 Apr 01 22:24:41 hostname kernel: Hardware name: Gigabyte Technology Co., Ltd. B450 AORUS PRO WIFI/B450 AORUS PRO WIFI-CF, BIOS F50 11/27/2019 Apr 01 22:24:41 hostname kernel: RIP: 0010:kfree+0x23c/0x250 ... Apr 01 22:24:41 hostname kernel: ---[ end trace caf6b7bf7cc304f1 ]--- 80 in about 10 days. Same thing with Einstein@Home. I updated kernel to 5.11 and BIOS, but it came right back after boot. AFAICT, things were fine right before that. Is this a known thing? |
|
20)
Message boards :
BOINC Manager :
After Update to BOINC Manager 7.16.4, System Tray Icon Missing (Linux)
(Message 95619)
Posted 3 Feb 2020 by Paul Post: I just built 7.16.4 from git and updated my installation. At first, boincmgr wouldn't talk to the client. But, I rebuilt it and now it seems to work like before (I think I last rebuit in 2017 7.14 maybe?). It's functional, but the desktop integration is dramatically different than it has been for the last 15 years. It used to be that BOINC would show in the system tray and when you clicked the window manager's exit button, BOINC would just minimize. This isn't a huge usability issue, but it is such a big change, I'm worried something is broken. Also, I miss the tray icon quite a lot. Does anyone know if these changes are expected or is there something broken on my system? |
Copyright © 2024 University of California.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License,
Version 1.2 or any later version published by the Free Software Foundation.