Ryzen 7000 amdgpu boot hang | Hacker News Reader

Ryzen 7000 amdgpu boot hang

aigarius.com

124 pointspabs3125 comments

OP's issue stems from running Debian, when the supported systems are "RHEL x86 64-Bit" and "Ubuntu x86 64-Bit".

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.

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.

Been reported before as well: https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=firmware-a...

No idea why this made it to the frontpage though.

Because online, drama tops non-drama? This is the worst aspect of this site being more Reddit-like for me.

So, the issue is that Debian has older and non-updated packages, correct?

Aka the meme about Debian's packages being stale is on-point in this case?

Surprised to see that if true, esp. since Ubuntu has it working.

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).

That should be the headline here surely.

Debian has been noted in the past to ship ancient, outdated, and broken software.

Though the slow rate of change is part of its value prop.

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.

Well, looks like the "stable" version crashed

The old definition of stable, where software might be missing needed security patches or hw related updates might need a rethink

To be fair, a computer that does not start is extremely stable and can reliably to be trusted on to always do the same thing.

In a way, cryptographic keys are also more stable if they have less entropy.

Its also very compliant with modern security rules.

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.

Meh? If you want to run hardware released last week you do check if the software you're installing can run on it.

Edit: anyone remembers having to prepare a sata driver floppy for windows 2000 (or was it 7?) when sata was new?

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 like a twitchy video game! I feel your pain.

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.

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.

Or when it doesn't support your NVME disk but it gives you cryptic messages that don't explain why it doesn't like the disk.

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.

> Wow is it slow to POST

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.

Any idea why they're so slow to post? Or if this is something that can ever be fixed? The b550 (zen 3) board I replaced was way faster.

I wouldn't mind so much if suspend & resume worked.

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.

That makes sense for first boot. But does it really have to do some variant of that every time the system boots up?

How would it know if you haven't changed your RAM?

Consider that using the same settings with different parts might lead to subtle instability, not a full on-boot crash.

Surely it can know that. Don’t ram chips identify with vendor / serial number etc?

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.

That sounds awfully fragile to me. Any kind of bump to the case could cause problems?

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 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.

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'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.

[1]: https://www.systemverilog.io/ddr4-initialization-and-calibra...

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.

EXPO breaks S3 sleep at least in some cases. A few motherboard vendors even disable the S3 state when EXPO is enabled.

https://old.reddit.com/r/Amd/comments/xwfadm/when_expo_is_en...

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.

IIRC they also said not to disable EXPO.

The 7950X at 65W TDP delivers 12% more than the 5950X at 105W TDP.

The 7700X at 65W TDP delivers 16% more than the 5800X at 105W TDP and 38% more than the 5700X at 65W TDP.

88W PPT = 65W TDP

And they can be undervolted as well.

Source: https://www.computerbase.de/2022-09/amd-ryzen-7950x-7900x-77...

edit: added 5700X

I’m running DDR5-6000 via EXPO and I haven’t had any issues with stability so far.

Now boot times on the other hand… If I didn’t have a motherboard with a debug digit readout, I definitely would have thought something was busted.

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.

I have the same problem. Ryzen 5600H laptop. I "fixed" it with a posthook Script thats switches between my first and second tty. That works for me.

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.

Same for me. I even had it working for a while but then a kernel upgrade or something else seemed to have broken it again.

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.

> 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.

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?

Man, you have a lot going on!

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 was inspired this morning to try, and switching to a virtual terminal before suspending seems to work in my case!

  [Unit]
  Description=Switches to a TTY before suspending
  Before=sleep.target
  StopWhenUnneeded=yes
  
  [Service]
  Type=oneshot
  RemainAfterExit=yes
  ExecStart=/bin/bash -c 'fgconsole > 
  /tmp/fix_resume_active_console'
  ExecStart=/usr/bin/chvt 1
  ExecStop=/bin/bash -c '/usr/bin/chvt $(cat 
  /tmp/fix_resume_active_console)'
  
  [Install]
  WantedBy=sleep.target

> My zen3 system with 6800xt GPU doesn't resume from suspend reliably in Arch Linux.

My Zen3 system with a 6700XT suspends fine on PopOS

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!

Hey josephg, does your motherboard disable sleep states when using XMP or EXPO memory configurations?

That could explain the crash when suspending.

How can you tell in Linux?

>Wow is it slow to POST. It takes about 20 seconds from when I power it on before grub shows up

I remember from some reviews that the new Ryzens took a long time on the first boot for analyzing the RAM or something.

Could it be forgetting that analysis and having to do it again? Maybe try manually setting some RAM settings?

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 all astonishingly user-hostile.

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 :)

Removing the quiet and splash parameters from the kernel boot parameters in grub will usually do the job of generating normal verbose output.

In most I've encountered, PgDn switches to showing you the system boot log

Of course it is possible; check your kernel parameters and remove "quiet splash" to disable it permanently. For one-time, just press Esc.

Can disable them in UEFI.

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

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.

You are usually able to hit escape and look at dmesg instead of the splash.

Not once it's hung. They also turn on quiet mode, so it won't display most kernel messages anyway.

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?

Unfortunately, it seems that error paths are generally not very well tested in amdgpu.

> so you are booting a Debian system using the new build-in video card of the new CPUs

Do you see the error? Will not work with Debian for sure. Rather try a proper OS with updated firmware, like Fedora.

Is the problem the colons in the logs? Because I can’t read any of the logs with big bright pink highlights around the colons either.

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.

Does it mean the no tweaking or easy road is still to go with Intel igpu ?

No, it means (like it does for every single other platform) that you need to use a distro that's newer than the hardware you're running on.

Debian is sadly behind a lot of the time.

So, stick to before-last gen. hardware then, got it ^^.

Debian is intentionally behind

Another data point that going with AMD isn't guaranteed that everything works out of the box.

Another data point that linux is still as amateurish as ever.

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.

>You surely mean the whole IT industry.

Hehe true, the exception's are probably people who work on rockets and satellites ;)

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...

Most of the CPU's are a ~decade old, before you even consider it for a launch.

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.

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.

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.

I have an M1 MacBook Pro and software is annoying me on a daily basis. In contrast, my AMD builds and laptops have been solid.

New AMD GPU releases are crapfor a while. They're getting better fast, though

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.

They say they support "RHEL x86 64-Bit" and "Ubuntu x86 64-Bit", and OP was using Debian.

https://www.amd.com/en/products/cpu/amd-ryzen-7-7700x

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".

https://www.phoronix.com/review/amd-ryzen7-7700x

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.

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 is not the problem, Linux is perfectly fine. Just Debian is the problem.

Funny then that my example was with redhat linux....but as always, they are a problem too right, just your distribution X is the best right?

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...

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.

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.

Yeah on the server, not so much on the Desktop.

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.

> I'm using it personally and professionally, 500+ of my colleagues use it in a professional capacity

Yeah sure...all of them Googler's right?

No, I'd rather not say, but it's a large software company. Windows is the default option, and the policy allows for Linux, upon user request.

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.

Challenge Accepted and won.

>(lenovo T61p)

Not the person you're responding to but I wouldn't call a T61p brand new, it was released in 2012 after all.

Yes let's throw it away because Linux is like Windows...just buy new stuff, 10 years is really to old.

> 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.

So what is your point?

>I don't think Windows 11 works to well on a laptop of that era either.

Windows 10 works perfectly.

>plan to play the latest AAA games on a 2007 laptop either.

Well yes i do actually, like Morrowind...but hey who talks about the latest AAA Games, Games from 2001 need Acceleration too.

So what's your point?

It is very useful those apps exist.

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.

Reply on news.ycombinator.com