Summary: | graphics/gpu-firmware-kmod and or graphics/drm-fbsd11.2-kmod crashing 11.2 to 11.4 with a Radeon HD 5770 card | ||
---|---|---|---|
Product: | Ports & Packages | Reporter: | Pau Amma <pauamma> |
Component: | Individual Port(s) | Assignee: | freebsd-x11 (Nobody) <x11> |
Status: | Closed Overcome By Events | ||
Severity: | Affects Some People | CC: | bennett, danfe, emaste, gnn, grahamperrin, imp, jmd, lwhsu, manu, newton.ja.terry, portmaster, pr, wulf, x11, zeising |
Priority: | --- | ||
Version: | Latest | ||
Hardware: | Any | ||
OS: | Any |
Description
Pau Amma
2020-06-20 17:29:41 UTC
Is this a problem even after the recent updates to the graphics stack? Have you tried 12.1 with drm-fbsd12.0-kmod or current with drm-devel-kmod? (In reply to Niclas Zeising from comment #1) *digs through old emails forwarded from linimon again* Scott Bennett wrote, on the topic of upgrading from 11.3 to 12.1: > > > > > > On 2020-04-13 14:06, Scott Bennett wrote: > > > > > > > > > > > > > If I can ever get 12.1 to build on 11.3, I can upgrade. (The impossibility to upgrade using source being a different problem, for which they can't open a bug for yet, due to the lack of a GUI browser until X works at all.) Does that answer your question? I have two events to report since Pau Amma filed this PR for me. The first is that I can, after all, file PRs (and, I hope, comments) using lynx(1). The other is that last month I decided to try to build 12.1-STABLE again, so I updated my source tree, entered "make -j3 buildworld", and for the first time ever, it didn't stop during the first few second, but instead ran to completion. I have no idea what changed in the source tree to make that happen. I then built three kernels successfully, but have yet to install any of this because, while I was waiting for an appropriate time to do it, Don Wilde began to complain on -stable@ of symptoms in 12.1 that matched several of those for the memory management bugs introduced into the kernel in 11.2 and still present in 11.4-PRELEASE. That told me that at least some of those bugs had, contrary to my hopes, made it into 12, so there was little point in going through the major upheaval and lost time of a major release upgrade at this time. But to return to Niclas's query's intent, I would ask in reply, which bug are you inquiring about? The bug in radeonkms.ko as provided in graphics/gpu-firmware-kmod? Or the one in graphics/drm-fbsd11.2-kmod? (In reply to Scott Bennett from comment #3) radeonkms.ko is provided by drm-*-kmod. gpu-firmware-kmod provides firmware that all (modern) GPUs need in order to run. Niclas, you are correct, of course. I misstated the question. But my question remains, which bug are you asking about? The bug in the firmware that hangs the GPU? Or the bug in DRM that crashes the system a few seconds after the GPU has hung instead of responding in a useful manner? On another note, I should mention that I have yet to find a way to upload attachments to bugzilla using lynx(1), so please keep that in mind if you need any further documentation beyond what Pau Amma posted here for me. If necessary, I can probably email whatever may be needed to a requesting party. (In reply to Scott Bennett from comment #5) I am referring to the problem you have of running a FreeBSD gui. Has that been fixed with recent updates in the graphics stack? Is this issue still relevant? From the logs from pauAmma, I see you are still using 1.18.4, that has been updated. The drivers have also been updated, and if you are running current you can try drm-devel-kmod, which is the development version of the drivers. Speaking of GUI, you should be able to use scfb (if using EFI boot) or vesa to get a working, but software accelerated GUI. That should be enough to get browsing going, for instance. (In reply to Scott Bennett from comment #5) > On another note, I should mention that I have yet to find a way to upload > attachments to bugzilla using lynx(1) Doesn't "Enter path to the file on your computer" work? Alternatively you can "Paste the text to be added as an attachment". Take a look at https://lynx.invisible-island.net/lynx_help/keystrokes/edit_help.html , "Editing Keymap" , "Insert file in textarea". I don't have a problem running a graphical browser per se. As stated in my original description I have a problem with two things: 1) the GPU hangs in under 35 hours and 2) the driver, instead of doing something rational like reinitializing the GPU and restoring the screen image, crashes the system without so much as a sync(). Such a combination is actually much worse than useless. The GPU hang, I presume, is due to a bug in the firmware modules loaded by the DRM driver, which is radeonkms.ko in this case. My machine is running 11.4-PRERELEASE r360432. I have postponed updating to the 12.-STABLE version that finally built successfully under the present system. There is presently no justification for an upgrade's lost time when there is no production version of FreeBSD available and security patches are still being made available for the experimental versions that are available, including the version listed in the previous sentence. Unfortunately, I naively updated beyond the 11.1 to 11.2 boundary and upgraded my pools, so I had left myself no way to return to 11.1, the last production release of FreeBSD. 11.1, is no longer available for production use because no security patches patches for it are made available since it reached EOL years ago. (In reply to Scott Bennett from comment #8) As long as you are running unsupported FreeBSD versions, there is not much I can do. FreeBSD 11.4-PRERELEASE is not a supported version. I suggest you either run FreeBSD 11.4 or better yet 12.1, both are supported. You can also run the latest 11-stable or 12-stable, or 13-current. I don't know why your GPU hangs, however, there has been a lot of development both in the FreeBSD base system as well as the various ports that is the graphics stack. I asked if this was a problem with an updated FreeBSD version, and updated components. The log you have pasted is from xorg-server 1.18, which has been replaced, so I'm asking again: Is this a problem with FreeBSD 12.1 using drm-fbsd12.0-kmod and the latest version of gpu-firmware-kmod? Have you tried FreeBSD current with drm-devel-kmod? I do not know what you mean by "there are no production versions of FreeBSD", currently, the supported releases are 11.3 (that will go EOL soon), 11.4 and 12.1. 12.2 is planned to be released later this year. Both 11.2 and 11.1 are EOL, since quite some time. I had not been aware that a stable/11 revision became unsupported in under 80 days. 11.2+ and 12 have kernel bugs in memory management that necessitate reboots every few days to return the system to usability. That time period can be extended if the kinds of things run on the system are very limited and some sysctl variables are properly tweaked. However, whether sooner or later, a reboot is necessary. For example, since my most recent reboot, the system has remained up for a bit over 28 days, but it will have to be rebooted soon because the pagedaemon is taking 60% to 100% of one core in searching for page frames it can return to the free list because the free list has finally dropped below 410 MB, the amount I set vm.pageout_wakeup_thresh because it appears to be the minimum necessary for the kernel to start paging in a process that has been marked a swapped out, even something as small as /bin/sh. An OS that needs a reboot every few days (usually between 3 and 9) is not a production version by any stretch of the imagination. We lived with such things in the 1960s, but things were also expected to be better in the future. They *were* better for quite a while, but apparently FreeBSD has reversed course in that respect. As for your questions, I thought my previous response was clear enough, but then, I thought my original description was, too. Apparently, neither was. I have not, at present, any reason good enough to justify the lost time to do an upgrade to 12.1, whether -RELEASE or -STABLE. Has there been any change to gpu-firmware-kmod for stable/11 since 28 April 2020? If not, then I would expect the GPU hangs to remain a problem. If so, please advise, and I will rebuild gpu-firmware-kmod. Has radeonkms.ko had any changes to how it is intended to respond to a GPU hang? If the GPU hangs may have been fixed, then it may not matter so much whether DRM has been fixed, at least until the next GPU-hanging bug is introduced into firmware for a card. If the firmware is still buggy, but DRM's response may have changed, then I will try it. If not, then there appears to be no reason for me to waste the time on it. So please do let me know whether each port has been updated in a way that may help. I have never run -CURRENT and don't intend to do so unless conceivably in a VM. I only have one functional machine. By today's standards it is now slow, so I don't want to divert it very much from the work I have it doing. (In reply to Niclas Zeising from comment #9) > As long as you are running unsupported FreeBSD versions, there is not much > I can do. FreeBSD 11.4-PRERELEASE is not a supported version. And what exactly had changed in between 11.4-PRERELEASE and 11.4-RELEASE graphics-wise? It always saddens me to see these "ah, you're running prerelease version" or "sorry, support for version X.Y had ended yesterday, please update to newer version" phrases, like it would make a difference (pro tip: no, it won't). > I suggest you either run FreeBSD 11.4 or better yet 12.1, both are supported. Unless we're talking about some specific changes, simply switching to 11.4 or 12.1 would most likely not magically make things better all of sudden. radeon(4) cards, which used to work before, are currently broken in FreeBSD, and that raises two questions: 1) what had caused the breakage, and 2) how to fix it. AFAIK, there are no answers for both of them ATM. > I don't know why your GPU hangs, however, there has been a lot of development > both in the FreeBSD base system as well as the various ports that is the > graphics stack. Tests I've done couple of months ago, trying various combinations of FreeBSD 13-CURRENT base and different drm-kmod drivers did not show any improvements; that is, I was not able to get back the experience of ca. 2017-2018 where radeon(4) cards have been working fine on FreeBSD. FWIW, I just updated my stable/11 source tree and started a buildworld. It should be done in several hours. When I'm next awake after it has finished, I'll start the buildkernel. However, I will need to wait for a good time for installing and rebooting, etc. In light of Alexey's comment I would rather not take the system down until it really needs it, however. (Setting vm.pageout_oom_seq=1024000 seems to have postponed the anticipated need to reboot the other night by eventually scrounging up enough page frames for the free list to let it keep going. pagedaemon now has a total CPU time of 6.5 to 7 hours on it.) Anyway, I want to thank Alexey for taking the time to confirm that Radeon support is buggy on more than just my system. AFAIK, he did that of his own initiative. And I do notice that he asked Niclas the same questions that I did. I am still hoping to see answers to them because they may determine whether there is yet sufficient reason to go through the hassle of moving to stable/12. Without them there certainly is not. The graphics drivers are highly sensitive to many things most other drivers are not. There's enough churn, even in stable, in the parts of the kernel that matter the graphics team is unable to provide much, if any, support for non-released versions of FreeBSD (plus very recent current and stable branches). There's simply not the resources there to chase down all the variants. Maybe there is something different, maybe not, in the 11.4-PRERELEASE, maybe it will work, maybe not, but the resources in the graphics team aren't such that they can provide support. It's unfortunate, since many other drivers just work unless there's some specific bug fix missing. However, given the wide variety of cards, and the historic sensitivity of the code, it's better to communicate the limits than to suggest the graphics team can help with old versions of FreeBSD. In conversations with the team, I know they'd like to have enough resources to help everybody. Given the size of the team, speed of API changes in -current and Linux, it's hard to find the time. Warner, I guess I need to correct my previous statement that Alexey had asked the same questions I had. My questions were rather more general than his. I asked, "Has there been any change to gpu-firmware-kmod for stable/11 since 28 April 2020?" and "Has radeonkms.ko had any changes to how it is intended to respond to a GPU hang?" Surely the first question is easy enough for anyone on the x11 team to answer. The second one would likely take a bit closer look at the update log for radeonkms.ko, but it also might be as simple as seeing that there were no changes made at all during the time period in question. IOW, there ought to be no problem in answering the questions I had asked, and it also I ought to take no more than a few minutes at worst to find the answers and tell me. If there is no difference in a module between two dates, then updating to the current date should naturally be expected to be a waste of time in terms of finding solutions to the problems. There is now a new obstacle for me. My stable/11 "make buildworld" ran to many hours, finally finishing about 7:15 p.m. llvm continues to grow at an alarming rate, so now it takes longer to build it than all the rest of FreeBSD combined. I then ran buildkernel, which ran almost to completion, but failed near the very end due to large numbers of compilation errors from having uncommented "options EVDEV_SUPPORT" because it is supposedly now required and there is now supposedly a way to continue to use moused with it enabled. So next I will try updating to tonight's source tree and run it all again. If I don't see any changed modules that look like they might have anything to do with EVDEV_SUPPORT, then I will look again tomorrow and, if necessary, repeat each day or two until I do see such and then will try building world and kernel again. Until then, I don't see the need to waste processing time. I reiterate that I have not asked whether the problems in gpu-firmware-kmod of drm-fbsd11.2-kmod have been fixed. I have asked whether the particular modules supporting a Radeon HD 5770 have even been changed since 28 April 2020. Warner, I also have a parting question for you, raised by Niclas. For how many days is a particular stable/11 or stable/12 revision considered to be supported? (In reply to Warner Losh from comment #13) > The graphics drivers are highly sensitive to many things most other drivers > are not. Could you elaborate a bit more on this? When DRM bits were in the base, FreeBSD had offered awesome graphics experience, despite that it was claimed those bits were actually not maintained very well. That was just 2-3 years ago, then we started to deteriorate rapidly. What had changed? Why did we allow it? Why no one waived the red flag? > There's enough churn, even in stable, in the parts of the kernel that matter > the graphics team is unable to provide much, if any, support for non-released > versions of FreeBSD (plus very recent current and stable branches). This just means that there's bad communication and coordination of development efforts between the graphics team and src team. In other words, our process sucks (that's how our users see it). > Maybe there is something different, maybe not, in the 11.4-PRERELEASE, maybe > it will work, maybe not Well, these "maybenots" make us look pretty bad, that's for sure. I keep receiving emails about more users switching from FreeBSD to GNU/Linux precisely because of lack of focus and uncertainty even among developers themselves. (In reply to Scott Bennett from comment #14) EVDEV_SUPPORT (or any evdev related kernel options) are not supported on 11. There is a reason they are not in GENERIC. They are not needed on 11, however, the handling of input devices will not be as good as on 12 or later (things like advanced touchpad features, hotplug and so on might not work). (In reply to Alexey Dokuchaev from comment #15) (In reply to Warner Losh from comment #13) >> The graphics drivers are highly sensitive to many things most other drivers >> are not. > Could you elaborate a bit more on this? When DRM bits were in the base, > FreeBSDhad offered awesome graphics experience, despite that it was claimed > those bits were actually not maintained very well. That was just 2-3 years ago, > then we started to deteriorate rapidly. What had changed? Why did we allow it? > Why no one waived the red flag? FreeBSD did not have a great graphics experience 2-3 years ago, not with the code in base at least. The code in base (now called drm-legacy or legacy drm or drm2) was never well supported by the project after being imported. This showed in lack of updates, and generally bad support for modern hardware. The source was ported and imported around 2012, and then updated to eventually mostly match what was in Linux 3.8, several years later. This meant that hardware support ended with Haswell, a CPU from 2013. On the AMD side, I am not exactly sure where support ends, but amdgpu.ko does not exist in drm-legacy, which is needed to support things more recent than around HD7700-series, released in 2012 (according to Wikipedia). In the meantime, things moved on, both in the userland parts of the graphics stack, as well as the kernel drivers (drm-legacy doesn't support dri3, as an example), and FreeBSD lagged further and further behind. It was not possible to buy reasonably new hardware hand have it work as a desktop, for instance. drm-legacy had been a full port of the graphics drivers in Linux, meaning that all kernel interfaces (mostly VM stuff) had to be rewritten. This made porting new versions of the driver quite hard, from my understanding, and also made maintenance hard (apart from keeping the driver compiling, maybe). To remedy this, and to ease with further porting and updating, the new version of the driver was made to use the linux kpi interface in FreeBSD (this already existed, but was extended). This made it easier to update the driver, as all shims needed lived in one place, and could be reused, making the diff of the driver against the Linux upstream much smaller and more manageable. At the same time, to ease development effort, and because of licensing issues, the driver was moved outside the FreeBSD source tree. This meant we could deliver updates and bug fixes much faster to users, no need to wait for releases or erratas, for instance. It also made it easier for developers not being FreeBSD committers to contribute. Without these efforts, support for graphics on FreeBSD would most likely had ended with Haswell, and radeonkms.ko, and the FreeBSD project would be even less relevant in the desktop segment. As for deteriorating, I do not at all agree. On the AMD side, things are a little less stable, and certain GPUs are having some issues, especially older GPUs, from the bug reports we get. However, I'm running FreeBSD as a desktop across two different laptop models, as well as a desktop, and I know several other laptop models that work without issues. With CURRENT and drm-devel-kmod we even support the very latest gen10 Intel CPUs, as well as recent AMD GPU offerings, something that was simply not possible with drm-legacy. The support matrix for graphics hardware is enormous. We can not test on every single GPU out there, that is simply not feasible. We in the Graphics Team try our best to test on a variety of hardware, but sometimes, there will be regressions. At some point we also need to move forward, to keep up with upstream, both on the userland and kernel side. >> There's enough churn, even in stable, in the parts of the kernel that matter >> the graphics team is unable to provide much, if any, support for non-released >> versions of FreeBSD (plus very recent current and stable branches). > This just means that there's bad communication and coordination of development > efforts between the graphics team and src team. In other words, our process > sucks (that's how our users see it). No, this means that this is extremely complex. Support for old STABLE (and CURRENT) revisions have always been best-effort. If you are tracking the development branches, you have to keep up. While there are no fixed lines, for graphics we try to keep the support window a couple of months, but that's not always possible. With "options EVDEV_SUPPORT" once again commented out, buildworld and buildkernel completed normally. I'm now waiting for an appropriate time to installkernel, reboot, installworld, reboot, etc. I am also waiting for an answer to the two questions I asked to find out whether there is any point in doing the update at this time. The update would bring my system up to r363403 of stable/11, whereas it is presently running r360432. Niclas, because r363403 is from early a.m.--FreeBSD now takes a ridiculous amount of time to build, mainly due to llvm--do you consider it unsupported already? I have now been running FreeBSD hellas 11.4-STABLE FreeBSD 11.4-STABLE #26 r363403: Wed Jul 22 02:34:08 CDT 2020 bennett@hellas:/usr/obj/usr/src/sys/hellas amd64 for 7:39AM up 4 days, 22:44 plus the time it will take to post this message. Niclas has not yet answered my two yes/no questions originally asked here on 17 July 2020. However, since then I have answered the second one myself by running portmaster graphics/drm-fbsd11.2-kmod and seeing that it rebuilt and reinstalled the same version of the port after an svn update /usr/ports. I do not have the same answer for graphics/gpu-firmware-kmod because I neglected to run it under script(1) in single-user mode. As of the time and date I installed the OS upgrade and reinstalled drm-fbsd11.2-kmod, there had been no change to the latter since 28 April, which means that the drm bug hasn't been touched since then. If I can please get an answer to my question about changes to gpu-firmware-kmod during that same time period, then we will know whether anything has been done there, too. On 21 July, another point was raised by Niclas, so I asked it here of Warner. To date, I have seen no answer to that question either. I do want to know that answer because it might give me some idea how many more times I might be told to update (again) to a "supported" revision or go away before I decide that going away is the only remaining option to get to a system with usable graphics. I've been without usable graphics under FreeBSD off and on since I started using FreeBSD 5.2.1 in 2005 with the "off" periods lasting from months to *years* at a time. This time has been going on for months already. If I had wanted a system for character terminal use only, I would gotten something with an RS232 port and tracked down an old VT100 or the like. Lest Niclas still not understand, a) I do not like having my system crash, leaving a mess to clean up manually and get everything restarted, b) there is no reason to test again software that has not changed, so I won't do that, and c) abandoning this discussion solves nothing, improves nothing, and frustrates immensely. Another month and a half has ticked by with no response and no action. Meanwhile I have further upgraded my system to FreeBSD hellas 11.4-STABLE FreeBSD 11.4-STABLE #27 r364474: Sat Aug 22 22:59:43 CDT 2020 bennett@hellas:/usr/obj/usr/src/sys/hellas amd64 and expect to update again in the next few days. I recently borrowed a laptop and installed NomadBSD onto an external USB hard drive. It seems to work well and doesn't crash, although something initially dims the screen until the screen is unreadable except in a pitch black room. To counter that, I added a "/usr/local/bin/xset -dpms standby" line to .xinitrc, so that it puts the screen into standby, at which point I can hit any key or move the trackball, which turns the screen back on at normal brightness. It does require logging in and then entering startx in the blind, but at least it is then usable. But, to get back to the topic of this ticket, I would just like to say that it would be nice to have a usable, safe graphics stack to use with FreeBSD on this tower machine. It would also be nice not to continue to be ignored w.r.t. this PR. (In reply to Scott Bennett from comment #20) Hi! I am not sure exactly what else you expect. You are expected to run a supported version of FreeBSD. Currently, that's 11.3, 11.4 and 12.1. 11.3 stops being supported at the end of September. We also try to support the latest STABLE and CURRENT branches, but if you are using those branches, you are expected to keep up with development, and to upgrade in a timely fashion. When it comes to graphics, we try to support everything that Linux supports when it comes to AMD/ATI and Intel GPUs (nVidia is providing binary drivers, so I have to refer to them for support for nVidia GPUs). However, the graphics team is a small team, and it is mostly a volunteer effort, which means that it is impossible for us to test every combination of hardware and software, and especially for older GPUs, there might be regressions, both in FreeBSD and imported from Linux (the GPU drivers for Intel and AMD/ATI comes originally from Linux). I'm sorry that you feel you've had a sub-par experience wrt. graphics on FreeBSD. At the same time, I must say that I don't share your experience. I've been using FreeBSD on a desktop for over a decade without much issue, and I use FreeBSD as a desktop OS on a daily basis. gpu-firmware-kmod is regularly updated, when there is new firmware. I cannot, however, tell if it is relevant for your GPU. Generally, it is firmware for more modern ATI/AMD and Intel GPUs that are updated. The firmwares are provided by Intel and AMD, and pulled in from the Linux firmware repository. I don't know much about NomadBSD, haven't used it myself. But if it works for you, then, by all means, use it. I note that NomadBSD is based on FreeBSD 12.1. FreeBSD 12.1 (and the upcoming 12.2) uses a more recent version of the gpu-kmod driver, based on Linux 4.16. There have also been a lot of changes to the Linux KPI compat layer between FreeBSD 11 and 12. If NomadBSD works, perhaps the problems you are experiencing have been solved. I have been quite patient in trying to help you, explain the situation and solve the issues, and I've spent a lot of time replying to you here. However, if all you are going to do is complain and rant, I am less inclined to help. Remember that we are all volunteers, working on FreeBSD and FreeBSD Graphics in our spare time. Regards Niclas FreeBSD Graphics Team >I am not sure exactly what else you expect. I expected at minimum an answer to yes/no questions (see comment #10). >You are expected to run a supported version of FreeBSD. Currently, that's >11.3, 11.4 and 12.1. 11.3 stops being supported at the end of September. We >also try to support the latest STABLE and CURRENT branches, but if you are >using those branches, you are expected to keep up with development, and to >upgrade in a timely fashion. And there you dodge the questions in comments #10, #14, #18, #19, and #20 again. Have the firmware modules changed since 28 April 2020? How long are stable revisions considered to be adequately up to date to be supported? >I don't know much about NomadBSD, haven't used it myself. But if it works for >you, then, by all means, use it. I note that NomadBSD is based on FreeBSD >12.1. FreeBSD 12.1 (and the upcoming 12.2) uses a more recent version of the >gpu-kmod driver, based on Linux 4.16. There have also been a lot of changes to >the Linux KPI compat layer between FreeBSD 11 and 12. If NomadBSD works, perhaps the problems you are experiencing have been solved. Obviously irrelevant. NomadBSD is running on a laptop's AMD APU. The problems are occurring on a tower with a Radeon HD 5770 card made by MSI. It's worth noting that the condescension of your final paragraph is off- target, as well as moderately offensive. I do, of course, understand that you are a volunteer. However, if you are unwilling or unable to support the Radeon HD 5770, then you should either state that up front or perhaps try to find another team member who is willing and able to support it. Dodging questions and hoping the problem will just go away is not being patient or helpful. More than two months ago you instructed me to repeat something that was already known to fail with those versions of the firmware and DRM module. Because that seemed a pointless thing to do, I asked whether a) the firmware had changed or b) radeonkms.ko had changed. I later answered the radeonkms.ko question in the negative. I still do not know about the firmware. I also asked in various ways how recent a revision of a STABLE branch of FreeBSD was considered sufficiently recent to be supported. I am still waiting to get the answers to those two questions. If either has changed since 20 April 2020, then I will certainly try running xorg again. Until then, I cannot see a reason to crash my system deliberately by running versions that have been proven to fail. It really is a simple and obvious decision to make. Four days ago I upgraded my system to stable/11 r368269 and then rebuilt and reinstalled gpu-firmware-kmod and drm-fbsd11.2-kmod. I then rebooted, logged in, rebuilt and installed windowmaker, and then entered "startx". The screen went black, and about 11 seconds later the system did a hard BIOS reset. Apparently, there is no longer *any* support for a Radeon HD 5770, even though older cards *are* supported, at least according to other posters on this and other lists. The following messages appear in /var/log/messages immediately before the beginning of the messages from the reboot. Dec 17 13:15:45 hellas kernel: drmn0: ring 0 stalled for more than 10498msec Dec 17 13:15:45 hellas kernel: drmn0: GPU lockup (current fence id 0x0000000000000008 last fence id 0x000000000000002b on ring 0) Thus it is clear that neither the firmware bug nor the DRM bug has been corrected in more recent versions of those modules. Doesn't the x11 team report firmware bugs to AMD? Doesn't the x11 team report DRM bugs upstream to whoever is developing/maintaining X11 for LINUX or for whatever? If so in either case, does any response come back to the x11 team? Has either bug yet been reported upstream? Pau Amma kindly first filed this PR on my behalf six months ago, and I have seen no sign of any resolution, except for mantras to spend lots of money. As far as I can tell, spending on another GPU is not the answer. A new GPU is likely not to be supported yet or become unsupported within four or five years, leaving a very narrow window during which it would actually be useful, making that a very poor investment of scarce resources. Dear Scott, you, like many other, are just the innocent victim of a FreeBSD documentation bug. FreeBSD does not support graphics. Period. The project is at the "proof of concept" level, nothing more. Do yourself a favor and stop investing time in this: when you report a problem in the graphic subsystem in the best case it will be ignored. In the worst case you will get misleading information (like "try this, do that") that keeps you busy for months, but there is no solution at sight. Look at this pr: reported in June (6 months and 2 days ago), current status: open. Come back in another 6 months it will either be dead or still open. "Understaffed" is the apparent condition, the true reality is that FreeBSD is just not meant for desktop users. Too many have spent long hours, efforts, energy and sometime also money fighting windmills to promote graphic use in FreeBSD. I urge you to learn there other have failed and take it from there: look elsewhere. A few facts that can help you understand how big is this documentation bug: 1) sys/dev/drm2/radeon/radeon_drv.c, line 123 reads: int radeon_audio = 0; For the sake of completeness, this same line is line 158 for Linux users https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/radeon/radeon_drv.c and reads: int radeon_audio = -1; This means that audio is not going to work on any Radeon card with FreeBSD. It has been like this ever since, and it's a "workaround" so that developers have the time to run the "proof of concept" show without having to deal with minor details such as having FreeBSD produce noise out of your speakers. Watching a video is enough, why would anyone want to hear it as well? 2) On Radeon, if you want to boot with drm driver, you have to disable the console, and see nothing during the boot. You cannot boot in single user mode (I mean, you could, but with a black cursor on a black screen), should you need to fix anything. This is acceptable for a "proof of concept" but definitely not for a production system. This has been like this for years now, rest assured it will stay like that. 3) If you happen to be a programmer willing to help there is no documentation that can guide you trough your process. You either are a FreeBSD master (e.g. buy a course from McKusick) or you will very likely find yourself staring at a hung screen. Don't look for a tutorial or a guide. Those who have the knowledge are too busy running the "proof of concept show" (did I state this already?) to write something down and help others make their way trought. 4) Should you manage to reach the magic point (an alchemy of hardware and software mix) where you can run clinfo you will get a core dump. vlc? Hangs on the second video (remember, still no audio). Don't use VAAPI, just don't, ok? Chromium (sorry, Chrome is not supported) requires 875 patch files (not lines, files) to build, so don't expect it to work: it's just another proof of concept. 5) Yes, I could go on, I think this is enough for you to open your eyes. I have been in the FreeBSD ecosystem for a few decades now and saw too many falling apart when they hit the graphic subsystem not to spend a few minutes and warn you about this important documentation bug. My recommendation is to switch to some Linux distro for production. Any crappy Linux (sorry for the redundant terms) would do, it just delivers what FreeBSD is unable to and it works out of the box with your current hardware. And remember to tell your friends that FreeBSD does not support graphics. Now you know. Regards, (In reply to pr from comment #24) > A few facts that can help you understand how big is this documentation bug: > 1) sys/dev/drm2/radeon/radeon_drv.c, line 123 reads: > int radeon_audio = 0; > For the sake of completeness, this same line is line 158 for Linux users > https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/radeon/radeon_drv.c and reads: > int radeon_audio = -1; Please, do not confuse people with comparing apples and oranges. Linux driver, corresponding to our deprecated base version (v3.8), also has radeon_audio set to 0: https://github.com/torvalds/linux/blob/v3.8/drivers/gpu/drm/radeon/radeon_drv.c#L144 While current FreeBSD driver has radeon_audio set to -1: https://github.com/freebsd/drm-kmod/blob/5.4-lts/drivers/gpu/drm/radeon/radeon_drv.c#L193 I don't know, if it works though. (In reply to pr from comment #24) Comments such as this are both incorrect and unhelpful. Please be considerate of the team that is doing this work and post your vitriol elsewhere. FreeBSD 11 isn't supported anymore, closing. My questions remained unanswered by the time this was closed. In the comments made by manu@ when closing quite a few other PRs on 19 November 2021, he appears to disagree with the FreeBSD project's web site, which says that FreeBSD 12.2 is still a supported release. Perhaps he should either change the web site or change his comments. Although this PR ended being closed in the manner I had expected, it was another example of a PR being dispensed with in a thoroughly unprofessional way. (In reply to Scott Bennett from comment #28) Did you not try 13.0-RELEASE? (In reply to Graham Perrin from comment #29) > Did you not try 13.0-RELEASE? And what makes you think this would improve anything? E.g. I've recently updated my fresh -CURRENT and thus had to rebuild DRM ports. The one I'm supposed to use, based on Linux 5.4, had broken laptop resume from S3 for me (once again). Then I've tried to build `graphics/drm-fbsd12.0-kmod' like I did before, but now the codebases had diverged far enough so it would require non-trivial patching to get Linux 4.16 DRM bits on recent -CURRENT. So updating made things *worse* for me (breaking resume), not better. FWIW, I've had to agree on what Scott had said in comment #28, bugs filed about graphics stuff typically sit there with no research or resolution only to be closed later as "overcome by events" (wtf?), that's why I stopped filing X11-related PRs. (In reply to Alexey Dokuchaev from comment #30) CURRENT is not release engineered. In reply to Graham Perrin in comment #29: No, I have not tried 13.0 on my tower, nor do I plan to do so. Having actually learned from long and often hard experience, I avoid .0 releases of most software and especially operating system software. Also, I just took advantage of some free time over the holiday weekend to upgrade FreeBSD on this system from 11.4-STABLE to 12.2-RELEASE and am still reinstalling packages and ports, so please allow me some time to complete that process and to catch my breath a bit. :-} Once all that has been done, I will try running xorg both with and without scfb to see what happens. Quite unexpectedly, I received a hand-me-down at the T-Day family gathering, a Radeon HD 6970 card. After I see whether upgrading has made any difference in gpu-firmware-kmod's behavior or drm-kmod's behavior, I will replace the Radeon HD 5770 card with the Radeon HD 6970 card and then try that card both with and without scfb. My prediction regarding drm-kmod is that there is no change that will affect the situation of a hung GPU. As far as basic, console-mode support for gpu-firmware-kmod is concerned, I suspect that that will work okay, but whether it, too, will crash within 35 hours is concerned, I have no idea, but it will be an interesting set of experiments to run. Meanwhile my system is running 12.2-RELEASE without xorg, but also without obvious problems, other than the previously described memory management problems, which, I admit, I have not had much time to explore yet, although I have seen some evidence already that at least some are still present in the 12.2 kernel. 12.3 is due to be released in the next few days, and then I will have the same problems to explore all over again. As usual, I expect to wait a week or two after the release for early problems to be fixed before I proceed with that upgrade. Adding to my projected time frame are things like overdue ZFS pool scrubs, pool upgrades, etc. I want to add some thanks here to Pau Amma, who so kindly posted this PR for me last year. (In reply to Alexey Dokuchaev from comment #30) > bugs filed about graphics stuff typically sit there with no research or resolution only to be > closed later as "overcome by events" Like many things in FreeBSD, there is far more demand for support than there is supply of people who have the time to do the work. Thus, when someone eventually tries to prune stale things out of the PR database, they get criticized instead of thanked. This is one reason why I strongly suggest to new bug triagers "do not start with the oldest PRs. You will mostly get negative feedback, and that leads to burnout". It's also why I do not try to do such work myself, any more. mcl In the past few weeks I have upgraded FreeBSD from source on my tower from 11.4-STABLE to 12.2-RELEASE and then re-installed ports preferentially from 2021Q4 packages, but building from ports where necessary (portmaster -P). Note that graphics/gpu-firmware-kmod and graphics/drm-fbsd12.0-kmod were both installed from ports. Using the virtual terminal mode with radeonkms.ko loaded worked, though with the same sorts of colorful screen artifacts as were present under 11.4-STABLE. Attempting to run xorg with radeonkms.ko resulted in a kernel panic after 10 to 20 seconds. Attempting to run xorg with radeonkms.ko loaded and scfb specified as the driver to use resulted in some configuration steps occurring, followed by xorg shutting down. IOW, the result is that I had no support at all in 12.2-RELEASE. A few days ago following a hung system due to power fluctuations, I did the upgrade to 12.3-RELEASE, also from source, and then rebuilt both gpu-firmware-kmod and drm-fbsd12.0-kmod. When using virtual terminals, there are now somewhat less frequent screen artifacts thus far, but there are still plenty of them. Attempting to run xorg with radeonkms.ko resulted in xorg going through much of the normal configurations steps, followed by xorg shutting itself down. Attempting to run xorg with radeonkms.ko loaded and the scfb driver specified resulted in a much abbreviated set of configuration steps and a shutdown. 12.3-RELEASE appears to have no functional graphics support either. Both 12.2-RELEASE and 12.3-RELEASE are allegedly "supported" releases of FreeBSD at this time. Is there any possibility that the X11 team believes that these releases are supposed to be supported at present? The xorg log files from the two experiments described above under 12.3-RELEASE are available, but I cannot seem to post them with lynx(1), and because I have no functioning graphics at present, I cannot use a graphical web browser to upload the log files. Also, I believe this PR should be reopened now that it once again involves supposedly supported releases of FreeBSD. (In reply to Scott Bennett from comment #34) > … 12.2-RELEASE 2021Q4 packages … Noted. > graphics/gpu-firmware-kmod and graphics/drm-fbsd12.0-kmod were both > installed from ports. Which branch? > kernel panic If you allowed the system to save the core dump, please attach relevant information to a separate bug. Thanks. (In reply to Scott Bennett from comment #34) > … 𡀦12.2-RELEASE and 12.3-RELEASE are allegedly "supported" … supposed … Factually ========= 12.2-RELEASE, 12.3-RELEASE and 13.0-RELEASE are: * release engineered <https://docs.freebsd.org/en/articles/freebsd-releng/> * supported <https://www.freebsd.org/security/#sup> <https://www.freebsd.org/security/#model> NB the rationale. Compared to 12.⋯: * 13.⋯ and 14.0-CURRENT allow superior DRM. stable/13 can be used with: * graphics/drm-fbsd13-kmod <https://www.freshports.org/graphics/drm-fbsd13-kmod/> * graphics/drm-devel-kmod (DRM currently superior to graphics/drm-current-kmod) <https://www.freshports.org/graphics/drm-devel-kmod/>. More on support: * <https://forums.freebsd.org/posts/547353> – in particular: > merges to stable/12 are naturally less frequent than > merges to stable/13 I assume that the ports branch is whatever is the default for 12.2-RELEASE. How would I check to be sure? I have not changed anything to configure this that I know of. /etc/rc.conf has dumpdev="/dev/ada0p13" dumpdir="/var/crash" No panic dumps have been saved by savecore(8) since late July 2020. Yes, Graham, I am well aware of the project's view of support. What I was asking, in effect, was whether the graphics team concurs with the official position of the FreeBSD project. Earlier postings by at least one team member seemed to suggest that the graphics team did *not* concur. (In reply to Scott Bennett from comment #38) The graphics team wishes it has the resources to support everything that the larger project supports. However, we could support older releases badly, but tell people they work. Or we could tell them that newer releases are much better tested and tend to work a lot better because that's where the graphics team has focused its limited resources. In the past, we've done the former and disappointed a lot of people. We're doing the latter now to be honest and to give better advise about what's know to work because the developers are using that. Until we have more resources, this is the best that can be done. (In reply to Warner Losh from comment #39) In light of that. May I humbly suggest that rather than leading users like Scott on. That graphics@ simply return ENOTIME. IMHO all the energy and frustration that went into this pr(1) could have been better spent doing *productive* things instead -- especially if graphics@ is strapped for resources/manpower. (In reply to Chris Hutchinson from comment #40) The headline of this issue refrences 11.4, which is not supported, and this issue was closed as OBE when 11.4 went out of support. FreeBSD 12.2 (for a little while longer) and FreeBSD 12.3 are supported releases, but 13.0 really provides a better experience. If there is an issue that can be reproduced on 12.3 or 13.0 and sufficient detail is available (such as a kernel panic backtrace) please submit a new PR with those details. |