Cursory internet search brings up a Linux review page, where on the first page, it's explicitly stated that to run the cpu, the user is "needing Linux 5.18 + Mesa 22 / linux-firmware.git as of this month to make use of the Radeon iGPU under Linux", and later that "AMD Zen 4 processors [..] are working out-of-the-box on modern Linux distributions like Ubuntu 22.04 and newer."
Or rather, it is an issue with Debian; and all they need to do to fix it is update the firmware package; not sure what's preventing them from adding new firmwares at least.
Unfortunately, the firmware-amd-graphics package in the Debian non-free archive has not been updated since October 2021. My understanding is that to use AMD GPU hardware released after that point, either the package maintainer will need to update the package with the new firmware from upstream or users will need to get the firmware directly from upstream themselves (as described in this post).
Another way to call "ancient and outdated" software is "stable". But I can understand that if you really need the latest version of a piece of software to get your hardware to work, you will not be satisfied with the "stable" version from last year...
"stable" has multiple meanings, and conflating them leads to a lot of confusion.
In the context of Debian, "stable" means that the software that makes up a given distribution does not change, even as the world — hardware, services, expectations — changes around it.
If you take "stable" to mean "I can use the OS to do my job, even as my hardware, the services I connect to over networks, and my expectations evolve over time", then in my experience a rolling release like Arch Linux works much better.
I've got an Arch Linux server for my email, git, etc that I've done virtually nothing other than package updates to for ~20 years (with two full hardware replacements "out from under the disks" in that time) and it still works as perfectly as it ever did, meanwhile equivalent Debian servers would have needed multiple brittle "upgrade the whole world" updates over the same time period and yet still would have been running ancient outdated software for the majority of that time.
While I’m a fan of Arch Linux, following the mainline kernel closely causes breakages once in a while. I recall some breaking changes in a patch kernel release with mdraid a few years ago, and just recently they broke the Intel GPU in a patch released for recently released hardware (the new framework laptop, among others).
Yup. Arch has an officially supported `linux-lts` package which I use on my server, it's a good choice unless you need a bleeding edge kernel for hardware support etc.
Yeah, there has to be a better way of rolling out hardware support without making the distro unstable for old hardware..
Even with Jammy/Mint I'm having to use mainline installer to get support for a 2022 laptop that would otherwise suffer insufferable keyboard input lag and issues.. Something the Mint community tries to scare people away from.
And the Window 7 fresh install conundrum, how do you install wifi drivers when your laptop only has wifi and no ethernet?
I also have a vague recollection of needing to install windows 98 from a floppy disk boot, then upgrading to windows XP as an upgrade, just because the bios didn’t support a cd-rom boot option. Fun times.
I remember doing that for XP. There were also dedicated software to prepare install media that included the sata drivers, so you could use that with machines without a floppy drive.
I remember windows would give you what felt like 10ms to press f6 to load a driver. The text offering you the option would sit on the screen for about two seconds after the opportunity has been missed (causing confusion), and your only solution was to hit reset and try again.
No no no. You don't press F keys when the message to press them shows up at boot. You start compulsively hitting them with one hand before you press the power button with the other, and only stop when you see the screen you're expecting.
Exactly how I would have done things except the hardware we used to sell had F6 to load raid management firmware.. so too early and I would end up looking at disk configurations. Of course there was no exit when I pressed too early, just another reset button :)
Just for another datapoint: I'm using one of the new zen4 cpus with Linux Mint. I'm still using the older 5.15.0-50 kernel but almost everything is working fine anyway. That said:
- I'm using an old dedicated graphics card (a RX480) instead of the integrated graphics on the CPU.
- The system hard crashes when I suspend then resume.
- Wow is it slow to POST. It takes about 20 seconds from when I power it on before grub shows up. Hopefully this gets fixed in a future BIOS version. (MSI hasn't updated the BIOS since release.)
- I also get a few warnings in dmesg about ACPI objects being already defined.
Other than that, everything feels solid. Sound, wifi and ethernet all work fine. All the cores show up and run great.
My zen3 system with 6800xt GPU doesn't resume from suspend reliably in Arch Linux. It works maybe 1 in 4 attempts. Otherwise, the AMDGPU driver hits a timeout and resets the GPU, and then my compositor has a bunch of open but invalid GL contexts or whatever. Sometimes I can switch to a virtual terminal and recover from it, but the attempt to do so tends to cause the system to lock up.
Interesting. Just switching to the tty doesn't fix things for me, though. I need to restart my whole graphical environment i.e. by restarting my display manager. So, it's about as convenient as just shutting down and powering back up.
It's unfortunate because my desktop eats up about 110W when idle, and approximately 0W when suspended. I also use some sketchy successor to "barrier" to share my mouse and keyboard with my work laptop, and that somehow keeps my monitors from shutting off if I happen to leave the mouse cursor on the laptop's screen. That's another 100W according to my UPS.
There are undoubtedly dozens of power plants that exist purely due to the overall number of software bugs that exist. They're talking about banning natural gas in favor of electrical heating here in California, and I live in a chillier climate, so I must be saving the Earth by leaving my desktop powered on most of the time out of convenience.
> Just switching to the tty doesn't fix things for me
I found a very strange one... Had the same issue. Switching to tty and then back to GUI would work fine so, to me, it wasn't that much of an issue. I used that workaround for months. Then one day I decided to look into it: switched the HDMI cable for a DisplayPort cable and the problem is now gone! If I put the HDMI cable back on, the issue happens again. It may or may not help some people having similar issues with their desktops.
I currently have a monitor plugged in via DP, another one via HDMI, and a VR headset also via DP. Having the VR headset plugged in causes no shortage of display and audio bugs.
I need to change my desk configuration in a few months, and it's going to get a lot simpler since I am going to separate out my work setup. At that point I won't be able to justify keeping the desktop powered on 24/7, so working suspend would be a major quality of life improvement. I'll keep that in mind, and try to avoid HDMI completely.
It's frustrated me to the point that it was a major factor in deciding to splurge on buying a Steam Deck. The suspend / resume works so flawlessly on it that I weep. I keep an arbitrary game running on it in the drawer of my night stand. I don't actually have the energy to play a game that often, but knowing that resume button will work brings me great comfort.
This happens to me and I think it was a bug from a bios update to gigabyte motherboards. Haven't been able to suspend witbout a script for over a year.
I have a Gigabyte motherboard too, an Aorus Master b550. It was my first time going with their brand, and I'm ambivalent. The hardware seems nice. Their BIOS do seem a bit buggy, but I don't know how it compares to anything else this decade. I tried contacting their customer service to tell them their @bios tool doesn't work anymore, and it was a complete waste of my time.
On the other hand, why wouldn't this likely be an AMDGPU driver issue? I suppose I should try booting into Windows and suspending from there, just to see if it's reliable. I could also try backing off my fclk frequency, and disable resizeable BAR for the laughs. I could even go as far as swapping my older Nvidia GPU back in and see if that suspends and resumes ok. I'm expecting a new born baby this week, so it's not like I have anything better to do!
I don't like producing e-waste, but if I conclusively knew it was a systemic Gigabyte issue, I would seriously consider switching to a new motherboard from another vendor. I built this desktop after being in the hospital ICU for 5 days, and promised myself I wouldn't spare any expense. I also expect it to last the next decade, and so I don't want to be annoyed by it long term...
Would you be able to share the details of your script? Or does it simply switch to a virtual terminal before suspending, then switch back after resuming?
Regarding e-waste. Not sure where you live, but we have Freecycle and a Facebook "Buy nothing" group that my wife uses. They let us find a home for tons of stuff we otherwise would have had to throw out.
For posterity, I finally tracked down my suspend issue. It was a combination of an overly aggressive amdgpu.ppfeaturemask kernel option, and a regression in the kernel module. I updated archwiki so hopefully it doesn't bite anyone else.
I finally just tracked down my issues. There was a recent addition to the amdgpu.ppfeaturemask kernel option, and the archwiki recommended value was enabling an unstable asynchronous mode. Additionally, there was a recent regression in the AMDGPU kernel module that's now fixed in 6.1rc2. So with a tweaked boot parameter and a manually compiled kernel, I have working suspend!
My understanding is that it is intentionally slow the first time you boot but should be normally slow after that. Apparently it is trying how fast it can clock the memory or something like that.
It is _ridiculously_ slow on first boot after a cleared CMOS due to the extra memory training - as in minutes. 20 seconds to post is the normal time after that initial boot and a decent time at that for these boards.
Suspend + resume works for me on Windows, haven’t tried Linux yet so can’t say if it’s in that half or maybe something board/firmware revision specific though.
Not sure why they take so much longer. Zen 3 was definitely faster for me as well. I’m not holding my breath that it’ll get significantly faster but I suppose it’s possible an update could do it.
> haven’t tried Linux yet so can’t say if it’s in that half or maybe something board/firmware revision specific though.
Its probably just bugs in the 5.15 kernel I'm still running. Full zen 4 support wasn't added until linux 6.0, so I think I'm doing well as it is. Fingers crossed suspend is fixed by a newer kernel.
Given everything else in the system seems to work fine, I'm not too fussed.
First-gen products often have issues like this. My old X370 board (zen1 era) turns off and on again twice before actually booting; a similar zen3 system doesn't need that and boots faster in general.
it's doing DDR Training. It's not necessarily how fast it can clock the memory. It's essentially putting an oscilloscope to the memory traces and checking how to generate the necessary signals fast enough while still being recognized on the other end. Simply because at the clock speeds and latency requirements of DDR5 Memory, the signal path is unique enough between CPUs, Motherboards and RAM Sticks that you need to configure the clock generation individually for that setup.
On some level, the BIOS has to determine if new chips have appeared on the bus. But also check that conditions haven't changed.
If you took out a RAM stick and inserted it into the same slot, the conditions (due to dust, moisture, difference in seating) could be enough to throw off the reliability of the training data. So at minimum it has to verify the settings to be correct.
I don't have one of these systems, but my laptop does a quite slow training process on cleared CMOS or new memory, and it definitely doesn't do it every time. I would imagine they only rerun this kind of thing if the SPD doesn't match the one from the stored training, or something along those lines.
Why wouldn't it run a subset of tests on each boot? It seems like it would be silly not to. That's probably one of the mechanisms by which the bios will automatically revert to "safe" settings after a botched overclock.
You could do an experiment. Remove some of the RAM modules and see if the 20 second boot time decreases.
Serial numbers that are supposed to be unique aren't necessarily unique. I would guess that the BIOS talk to an EEPROM on the RAM modules rather than to the memory chips themselves. It would be very easy for a manufacturer to flash identical contents to every EEPROM in a batch, or with a sequentially increasing serial, rather than bother with a database.
What if you reinsert the same RAM stick into the same slot? Minute differences in insertion force and direction can lead to the frequency response of the RAM stick changing. Data paths might now be a micrometer long and require the BIOS to retrain the communication controller to compensate for that.
DDR5 tops out somewhere around 8 Gigahertz clock speed, which means the data signals travel 3 centimeters before the next clock signal arrives. At those time scales it means you're going to have to align those data signals down to the micrometer if you want them to be properly received.
It could. Probably not for most minor bumps but reinsertion in the slot is more likely to cause issues than small bumps once insertion forces are being applied constantly. Hence the BIOS has to check.
I'm not sure if it needs to take that long, however --- from my understanding, the training process has existed in some form since the early days of DDR and it's done by a sort of binary search (set the timings to one end until errors start appearing, then to the other end, and choose the midpoint). Maybe the newer generations are doing far more worst-case testing?
Training becomes more complex as you approach higher frequency domains. It's not simply a trivial binary search anymore as there is more than a few parameters (how fast the clock has to rise, how long you can and must hold clock and data lines for, what order data lines have to be held in, to compensate for speed-of-light lag, etc.)
I found this[1] page helpful in describing the DD4 training and calibration procedure. Though, while it's fairly involved, I'd be surprised if it took minutes to complete.
Out of curiosity what fabric and memory clock are you able to run at? I’m either extremely unlucky or running into an early firmware bug as I can’t get anything above 2100 MHz fabric to boot reliably.
I didn't touch the clock speeds from whatever the defaults are. Given the reported thermals, I'm tempted to go the other way and underclock the system. Losing ~5% performance to get a 50% reduction in power consumption would be a great deal if I can get it.
That said, I did activate EXPO on my 6000 MHz RAM sticks - which at first caused the system to hard freeze and nothing short of a CMOS clear could bring it back. But in the end, re-seating the RAM sticks seems to have sorted that one out and its running at the full rated speed now.
I had the EXACT same problem. I left my machine running for 30 minutes after turning on EXPO after hearing about “training”.
Hard reboot, CPU code error… uh oh. Clear CMOS, boots again at 3000mhz. Decide to install Windows first, and then after I turned EXPO back on and have had zero issues at full rated speed. Even ram memtest to be sure.
Im running a MSI MPG x670e Carbon Wifi for what it’s worth.
Seems weird that installing windows fixed a ram issue. I wonder if there's a launch day CPU microcode update or something that windows installed that made a difference?
I'm also using a MSI board FWIW: MAG B650M Mortar (WIFI)
The German CT magazine tested the Ryzen 7000 recently and they said the eco mode (or similar name) reduced the power consumption significantly (IIRC <65W after) with only modest (<5%) performance drop.
This is a general problem with all amdgpu-supported devices too new to have firmware shipped in a distro. And a boot hang is a terrible way to find out you're missing firmware.
Yeah, like, seems odd to boot hang here. Why doesn't it just say "nope" to whatever it's being asked to do (KMS or something i assume, i have no idea) and move on.
I have a new Intel NUC whose Iris graphics is apparently little too new for ubuntu's drivers/firmware (works fine on fedora beta and if i and install newer custom-build kernels on ubuntu). It hangs completely on startup without giving me any info.
That's actually one of the worst parts of these stupid splash-screened distros.
Because they don't bother to help you at all, you have to go through some other mechanism (rescue mode), and understand how to debug the original problem.
It's been forever since I daily drove Linux sadly... is it possible to disable those splash screens and put the old TTY boot sequence stuff back? That was always super handy debugging whatever thing I'd recently broken at boot. And I personally think it looks way cooler :)
It's not the bootsplash that causes the "hang", it's the AMDGPU driver kicking in. With firmware issues or amdgpu bugs in the past, my tty goes away when the module is inserted. The driver goes in, the system tries to switch to an accelerated framebuffer, the GPU driver has a problem, and you're left just looking at a black screen.
Bootsplash just does this earlier in the process by inserting the module and throwing up some DRM/GBM app while in initramfs.
The system was still up, I ssh'd in and looked at the logs.
I was an early X570/Zen 2 and RDNA adopter. CPU/MB wete mostly fine but I couldn't get proper Vulkan support for an year until I pulled the trigger on a rolling distro for that particular build
Is it the driver that complains and then hangs instead of just giving up and letting the boot continue with a fallback? Because clearly it seems the hardware is there for a fallback to plain old VGA?
Yeah, that was very distracting. It seems all the colons are wrapped in "err"-class span elements for some reason. Must be some blog styling software that has gone off its rails or something.
"Stable" in its unchanging meaning is an all or nothing philosophy. If you are running on prerelease hardware you do not have a "stable" system.
The are plenty of rolling (Arch) or certified (RHEL) systems that ensure you have a "stable" experience in its always works meaning.
Michael on Phoronix didn't seem to have a problem running his tests on the CPU, because it was "working out-of-the-box on modern Linux distributions like Ubuntu 22.04 and newer".
This doesn't seem a reasonable notion of "out of the box": trying to use an officially unsupported distribution that doesn't include new binary blobs for new hardware is an experiment, not an update that is expected to work flawlessly: and since the binary blobs are working well and readily available the blame is split among the optimist (mostly) and Debian, not AMD and other driver authors.
Intel 11th gen wasn't exactly totally smooth sailing on the graphics front either. Isn't, in fact: I believe the recent reports of an update actually breaking laptop displays were on those chips.
Is it Linux, or is it the whole "consumer pc" industry, putting out shoddily engineered product to save a cent?
I have two HP laptops that won't completely work with Windows, even the latest 11 22h2, yet have worked perfectly fine in Linux since day 1. And they're nothing fancy, either: year-old "enterprise" models, AMD/Intel with integrated graphics.
Sure, they don't break on boot (though one requires an external mouse to install windows), but they're clearly not fully supported, even after installing the plethora of HP drivers. The Intel one only recently got a graphics driver upgrade that allows it to reliably output 4k@60Hz over the usb-c ports.
I guess my point is, if all OSs seem equally amateurish, at least on the hardware support front, maybe it's not the OSs that are amateurish?
You surely mean the whole IT industry. The only one that do not issue recalls or warranty refund/ when end product has major issues/misfunction and just tell people to live with those bugs until they potentially fix them or not.
Well, I think you'll have no end to grief if you try to mix rockets and satellites from different decades together and put them on the launch pad today...
Yeah this. My old 3700X rig would need to be power cycled 3-4 times before it booted. This turned out to be the Radeon GPU I chucked in it inflaming the boot sequence in some way. Put an nvidia one in and it was fine. The Radeon worked fine on another machine.
Own an M1 MacBook Pro now and never looked back at the hell of custom built PCs favourably.
Annoying edges perhaps but as far as reliability goes, this MacBook Pro is the most reliable thing I've had since windows 2000 on an old Intel 440BX board. That's been a hell of a long journey of crap.
I get the feeling that computers are more and more picky when it comes to working with different components.
I have two HP laptops, both supporting DisplayPort alt-mode over USB-C. I have Windows 11 and arch Linux on both, up-to-date. My USB dock's display out works at 4k@60 with both Linuxes, but only one windows. Go figure.
Yeah I had this problem as well with my old Dell and Windows. Also weird problems with high DPI displays and window sizes. If I unplugged one monitor, the other one would drop for a second and then the menu bars would shrink on the still plugged in display.
Now I have a studio display. Get out of box, plug it in, works. Open laptop, spans display instantly. Unplug, windows move to the laptop. Never goes wrong. No bugs.
Linux, really has a problem and no one seems to care, if your HW is to old you have a problem, like my T61p RHEL9 panics a boot-time, but no problem, the kernel is anyway to new for the nvidia 240 series of drivers.
In the article the opposite....hint..hat would be no problem with windows...something has so change in the Linux-Mindset
Linux not working, and Windows working in a situation is a single datapoint.
Two things:
1. Current Windows is supposed to be a supported platform by virtually all current hardware, because Windows is the de-facto consumer and office platform for decades. Linux, in comparison, is an aftermarket solution.
2. Windows, as a platform, is rife with problems, driver problems included. The word "driver" is present 12 times in this collection, for an example: https://itvision.altervista.org/why-windows-10-sucks.html (compared to the 46 times in the respective Linux article)
The Linux mindset, whatever it's supposed to mean, is perfectly fine. It works well, since its inception, as evidenced by the incredible amount of mindshare that goes into Linux - ranging from hobbyist interest to enterprise and government involvement.
>The Linux mindset, whatever it's supposed to mean, is perfectly fine. It works well, since its inception, as evidenced by the incredible amount of mindshare that goes into Linux - ranging from hobbyist interest to enterprise and government involvement.
No, it works well, for a long time now, on desktop too. I'm using it personally and professionally, 500+ of my colleagues use it in a professional capacity. Various businesses and governments also build their systems on it. The system is capable, and it's not being held back by technical issues, of which all operating systems have many. And it's especially not held back by "mindset" - if anything, it's supported by its mindset. Its reason to exist, and why it's continuing to be attractive is the mindset.
> Linux, really has a problem and no one seems to care, if your HW is to old you have a problem,
Mac OS Monterrey do not work to well on a powerbook G4 and even a Macbook contemporary to your T61P is not supported by post 2015 Mac OS releases.
I don't think Windows 11 works to well on a laptop of that era either.
I am pretty sure you can get a working T61P with some sort of Linux/BSD distro and security updates one way or another. It might means losing 3D acceleration support but I don't think you have any plan to play the latest AAA games on a 2007 laptop either.
I'm not sure. I challenge you to put a windows 7 or 10 boot disk into a brand new PC and see if you don't encounter any issues in the installation. I definitely recall running into problems. One of the big ones was often no working wifi/ethernet drivers, so you couldn't even install new drivers.
I could install Windows2000 on that machine, it was delivered with Windows7 and Windows10 works too (lenovo T61p)...the Ethernet drivers are really not a problem and wireless works without problems even on Windows2000, same with the Nvidia drivers...works on all 3 Windows's.
A lot of different entities put work into a Linux distribution. In OP's case, it's probably Debian that's at fault, or rather, it's Debian who could fix the issue. The CPU doesn't support every distro explicitly, just Ubuntu and RHEL. OP is using Debian. Therefore it's either Debian's, or OP's problem.
In your case, it sounds like RHEL either had a regression, or decided not to support the architecture anymore. The laptop's release year is 2007, which is not too long ago, so I'd expect Linux to work on the machine. If this is a single incident, it might be an issue with the kernel, the distro, the particular media it's written on, or the machine itself.
RHEL 9 is similar to Debian, too old. Arch and Fedora don't have any problems. Well, Arch got an amdgpu wakeup issue, but they do have proper docs to fix it.
RHEL9 is based on Fedora 34, and btw like i wrote the kernel is to -->NEW<-- for nvidia driver 340. But hey in typical Linux fashion, just use distro x i "never had that problem"...oh btw i use arch...
They also advertise the lack of ads in those apps so I suspect they are financed by some public (or charitable) institution. Unfortunately, all apps can't be finances this way so I personally would really like for some privacy minded ad network to appear.
I suppose most people associate ads with no tracking/ids as useless (paying an order of magnitude less than the alternative). I wish some innovative method emerged to make privacy friendly ads have comparable sucess rates.
"Hangs at boot" hardly requires a new CPU. You can enjoy the year of Linux on the desktop with any old Intel CPU, too, since Ubuntu broke all Intel iGPUs in the pre-release Kinetic, right before the pointless "kernel freeze".
People do not use Linux when they expect to have better than even odds of the machine booting.
>People do not use Linux when they expect to have better than even odds of the machine booting.
I think it's the opposite. People frequently run a Linux live boot, to rescue a failing PC, Linux or not. If you google "live boot" or "rescue usb", most of the results are Linux, or are using Linux under the hood.
https://www.amd.com/en/products/cpu/amd-ryzen-7-7700x
Cursory internet search brings up a Linux review page, where on the first page, it's explicitly stated that to run the cpu, the user is "needing Linux 5.18 + Mesa 22 / linux-firmware.git as of this month to make use of the Radeon iGPU under Linux", and later that "AMD Zen 4 processors [..] are working out-of-the-box on modern Linux distributions like Ubuntu 22.04 and newer."
https://www.phoronix.com/review/amd-ryzen7-7700x
This is a non-issue.