NVIDIA GeForce RTX 30 Series Linux Driver/Support Expectations

[starshipeleven]

ever heard of bios updates?

Something that can go horribly wrong due to mistakes from manufacturer or user and brick the device (or only some revisions of the hardware)?
Yeah, I've heard of them. Years ago a customer paid me to repair a bunch of office PCs in a larger fleet that were bricked by automatic firmware updates and I have hardware flashing tools (i.e. things that connect directly to the SPI flash memory on the device) to do that.
I've seen some SSDs that were automatically updated and then stopped working after a reboot.
Apple laptops also sometimes fail the firmware upgrade for the T2 chip firmware (the security chip thing) so they brick themselves after they reboot until someone connects them to another Apple PC and runs a diagnostic tool to manually update the firmware again.
And if we start talking of OS-firmware like for example network routers/access points it's even worse, NEVER EVER leave updates enabled, always validate the update on some guinea pig devices before updating the whole fleet.

That's why I prefer OS-loadable firmware wherever possible. Mistakes happen. Most of your devices aren't businness grade so don't expect high quality validation teams, it's probably a couple dudes that deal with the firmware for all devices in the same product line.
With OS-loadable firmware it's much much harder to brick the device.

Also hard to believe that it is just capturing the firmware load,

It's using Linux kernel security features so it requires a purposefully compromised Linux kernel to access them on load, this isn't something easy to automate on the user's distro, and therefore nouveau developers lost interest in fighting the tide.

You can't just extract them from the driver blob because the one in the blob is generic and is modified by the driver before loading, similar to the vBIOS thing, you can't just extract the vBIOS on flash, you must extract the one from your own running system because UEFI does modify things to create your system's actual vBIOS.

should not be rocket science to trace that on windows, a VM, or extract form other drivers,

This has been explained years ago by nouveau developers, but feel free to think you somehow know better without even knowing how this whole shebang works.

an at least somewhat working open driver and nothing at all for big vendor like RedHat^W IBM and other such heavyweights.

Servers use NVIDIA blob driver, wtf are you talking about.

[rene]

Something that can go horribly wrong due to mistakes from manufacturer or user and brick the device (or only some revisions of the hardware)?
Yeah, I've heard of them. Years ago a customer paid me to repair a bunch of office PCs in a larger fleet that were bricked by automatic firmware updates and I have hardware flashing tools (i.e. things that connect directly to the SPI flash memory on the device) to do that.
I've seen some SSDs that were automatically updated and then stopped working after a reboot.
Apple laptops also sometimes fail the firmware upgrade for the T2 chip firmware (the security chip thing) so they brick themselves after they reboot until someone connects them to another Apple PC and runs a diagnostic tool to manually update the firmware again.
And if we start talking of OS-firmware like for example network routers/access points it's even worse, NEVER EVER leave updates enabled, always validate the update on some guinea pig devices before updating the whole fleet.

That's why I prefer OS-loadable firmware wherever possible. Mistakes happen. Most of your devices aren't businness grade so don't expect high quality validation teams, it's probably a couple dudes that deal with the firmware for all devices in the same product line.
With OS-loadable firmware it's much much harder to brick the device.

It's using Linux kernel security features so it requires a purposefully compromised Linux kernel to access them on load, this isn't something easy to automate on the user's distro, and therefore nouveau developers lost interest in fighting the tide.

You can't just extract them from the driver blob because the one in the blob is generic and is modified by the driver before loading, similar to the vBIOS thing, you can't just extract the vBIOS on flash, you must extract the one from your own running system because UEFI does modify things to create your system's actual vBIOS.

This has been explained years ago by nouveau developers, but feel free to think you somehow know better without even knowing how this whole shebang works.

Servers use NVIDIA blob driver, wtf are you talking about.

Everyone knows servers run Windows. After all all this open source Linux hippie stuff is just a hobby.

[mppix]

rene i think starshipeleven is arguing that Nvidia should implement fwupd support in their GPU's.

[starshipeleven]

Everyone knows servers run Windows. After all all this open source Linux hippie stuff is just a hobby.

I like how you assume that everyone that uses Linux must care about opensource. Server operators and embedded device users sure don't.

[starshipeleven]

rene i think starshipeleven is arguing that Nvidia should implement fwupd support in their GPU's.

No I'm not. I'm saying firmware loaded on runtime are preferrable in most cases to firmware stored on the device.

Fwupd is just a tool to upgrade the firmware. It does not protect you from firmware update issues, it has bricked devices in the past https://github.com/fwupd/fwupd/issues/655, with the help of the stupid fucking GNOME Software that does not warn the user in Ubuntu and just updates automatically all firmware it has bricked laptops too https://askubuntu.com/questions/1077...laptop-bricked and given how these things go, it will keep bricking devices in the future.

Because no matter the tool you use, if flashing a static firmware goes wrong for many reasons not under your control (as in many cases the "flashing tool" is just sending the firmware image to the device and asking it to "do the thing", it's not accessing flash and writing it personally like back in the day), or if an untrained user freaks out while this process is happening and pulls the power plug, the device is bricked.

Yes if devices actually used a dual-firmware partition so they could always fall back to a known working firmware you would not have these issues, but you know no OEM is smart enough to do this, and even the ones that do like Gigabyte fail to document how the fuck it is supposed to work so people need to short pins around the SPI flash chip to get the damn system to use the backup firmware chip.

Meanwhile, if you fail to load a firmware on runtime or you load a corrupted firmware you can just power-cycle the device and try again.

[mppix]

No I'm not. I'm saying firmware loaded on runtime are preferrable in most cases to firmware stored on the device.

Fwupd is just a tool to upgrade the firmware. It does not protect you from firmware update issues, it has bricked devices in the past https://github.com/fwupd/fwupd/issues/655, with the help of the stupid fucking GNOME Software that does not warn the user in Ubuntu and just updates automatically all firmware it has bricked laptops too https://askubuntu.com/questions/1077...laptop-bricked and given how these things go, it will keep bricking devices in the future.

Because no matter the tool you use, if flashing a static firmware goes wrong for many reasons not under your control (as in many cases the "flashing tool" is just sending the firmware image to the device and asking it to "do the thing", it's not accessing flash and writing it personally like back in the day), or if an untrained user freaks out while this process is happening and pulls the power plug, the device is bricked.

Yes if devices actually used a dual-firmware partition so they could always fall back to a known working firmware you would not have these issues, but you know no OEM is smart enough to do this, and even the ones that do like Gigabyte fail to document how the fuck it is supposed to work so people need to short pins around the SPI flash chip to get the damn system to use the backup firmware chip.

Meanwhile, if you fail to load a firmware on runtime or you load a corrupted firmware you can just power-cycle the device and try again.

You live in a sad world.

[starshipeleven]

You live in a sad world.

Well yeah, I work in IT.

I see when this stuff fails. I'm the one that says "it's dead, Jim" to people about their device (as in most cases it's not worth trying to fix them even if I have the tools)

Even a 99.9% reliable system will fail once every 1000 times and given how many devices are out there, this is not an insignificant number. This means that while you may not ever encounter one failure in your own life, a poor sucker will.

Meanwhile, firmware loaded on runtime has no such issues.

[tildearrow]

Everyone knows servers run Windows.

Please widen your mind...

Out of so many sites I have visited in the past, the only major ones that use Windows are Stack Exchange and Newegg...

[rene]

Please widen your mind...

Out of so many sites I have visited in the past, the only major ones that use Windows are Stack Exchange and Newegg...

that was ironic, a funny reply to those who defend NVidias's binary only blob. I know nobody who uses Windows nor Nvidia for anything seriously.