A DRM-Based Linux Oops Viewer Is Being Proposed Again - Similar To Blue Screen of Death

[dpanter]

Isnt the bsod essentially just a frozen blue screen with a cryptic error message? You can't screen capture, you can't do shit. Except write it down and reset the machine.

Unless the machine reboots before you have a chance to read the BSOD error code... because Microsoft.

[milkylainen]

Is that because it's an optional feature, or because those machines don't implement the full spec correctly? Because if it's the latter, then those same machines are the ones most likely to experience driver crashes.

It's optional. The situation is a pita. ERST is not mandatory and not all PCs run in UEFI mode (also don't know how coherent UEFI is in this regard). So you probably can't rely on UEFI variable stores etc either.

[PhilipeLouchtch]

So you probably can't rely on UEFI variable stores etc either.

So what if the feature is not consistent, it's significantly better than without!
Let's inventorize all possible issues and discuss approaches.

Let's summarize:
- system will most likely have extremely limited capabilities, but let's assume we end up in an error handler and can generate/get/have received an error code.
- Video driver might have crashed, can't rely on it. Can we start some extremely basic VGA mode?
- Can we reserve a chunk for kernel memory where we can be more sure it is not corrupted during a fault? And store the extremely bare essentials for presenting error to user?
- Can we try storing things into UEFI? Each boot, we'd have to probe for last-run error messages

[discordian]

Unless the machine reboots before you have a chance to read the BSOD error code... because Microsoft.

Disable the automatic restart on error, is poking a checkbox above your skills? (rhetorical question since you rather claim shit than look anything up)

[JustRob]

A few years ago I was trying out different Linuxes to see if there was one that I might prefer to Debian (or Solaris).

I don't remember which one it was but the kernel panic was truly wonderful.

The program that caused the problem would simply terminate and you'd be dumped back at a working command prompt (if at the command line) or simply have a working Desktop. In either mode a popup would slide up in the lower right corner explaining what the problem was and allowing the option to dismiss or report. If you choose report then within a half hour (or so) a fix for the Kernel would be posted for download and installation. It could hardly be less painless and easy. No waiting, freezing, rebooting.

Forgot which OS it was, but it was one of the top ten, and unfortunately not Debian (unless it's since been implemented).

[ssokolow]

A few years ago I was trying out different Linuxes to see if there was one that I might prefer to Debian (or Solaris).

I don't remember which one it was but the kernel panic was truly wonderful.

The program that caused the problem would simply terminate and you'd be dumped back at a working command prompt (if at the command line) or simply have a working Desktop. In either mode a popup would slide up in the lower right corner explaining what the problem was and allowing the option to dismiss or report. If you choose report then within a half hour (or so) a fix for the Kernel would be posted for download and installation. It could hardly be less painless and easy. No waiting, freezing, rebooting.

Forgot which OS it was, but it was one of the top ten, and unfortunately not Debian (unless it's since been implemented).

Either it wasn't actually a kernel panic or it was running your apps virtualized and the virtualized kernel crashed. (Which isn't a big help, because it tends to be the drivers for actual hardware which contain the panic-inducing bugs most often)

By definition, a kernel panic requires a reboot because the kernel panics when it's in a state where, at best, you'd get data corruption by continuing onward.

[Ironmask]

Given that the only kernel crashes I have seen in the last 24 months were caused by the "amdgpu" driver, I would not expect a crashed GPU driver to be able to display the message.

I've has GPU hardware faults on my Windows machine and even I still got to see an error message. The display was a bit crusty and low-resolution, but it still managed to get the message out to me. As others have said, absolutely anything would be better than just showing nothing. At least try to get the message to the user.

[dpanter]

is poking a checkbox above your skills? (rhetorical question since you rather claim shit than look anything up)

Dude. Nice attitude.
Obviously sarcasm is lost on you, but thanks for trying.

[jo-erlend]

Isnt the bsod essentially just a frozen blue screen with a cryptic error message? You can't screen capture, you can't do shit. Except write it down and reset the machine.

Or photograph it and send it to someone who might understand what the errors mean? If you mean the information isn't useful at all, then why log it at all?

[Guest]

Well I could not care less if the screen was red, green, blue, yellow or pink.... The last 10 years or so I have not seen single a Oops at all on my Debian boxes.
That being said, I prefer black screen with red text. It's time to bring back the famous GURU MEDITATION from the good old Amiga days! And I actually think that a nice juicy PENGUIN MEDITATION message would do the trick

Nah, I'd prefer a GNU meditation, especially because GNU is shorter and sounds more like "guru".