Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by Chewi View Post
    always loved that one

    Comment


    • #12
      Originally posted by waxhead View Post
      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
      Yes indeed!

      Amiga just did so many things' right, out of the box, including Guru Meditation...

      Comment


      • #13
        Do it like on the Atari ST: display a number of bombs, depending on the type of error

        Comment


        • #14
          Originally posted by ssokolow View Post
          There's a reason that BIOS-based systems use serial consoles for debug logging. Writing to COM1 is both simple and pretty much guaranteed to work if your kernel is un-corrupted enough to reach the panic handler.
          As a developer, sure. An UART is useful. As a normal user, not so much. Users probably just want to send that bugreport with the dump.

          In the case of a modern PC, couldn't there be a ACPI non executable binary dump region somewhere that can be used?
          Without dragging through a monstrous ACPI handling interface? Like a straight memory write, pre-mapped?
          Because the whole idea here is that the kernel is broken beyond saving a dump and logs on normal media.
          Users don't care much about the actual "BSOD" screen itself. And writing a tiny KSM driver for _every_ hardware for this to become uniform seems... a bit optimistic?

          Edit: Turns out ACPI has ERST for this very purpose. Not all machines implements them though. Linux can use it as pstore for kernel oopses already.
          https://www.kernel.org/doc/Documenta...testing/pstore
          Last edited by milkylainen; 10 March 2019, 05:13 PM.

          Comment


          • #15
            Originally posted by milkylainen View Post


            Edit: Turns out ACPI has ERST for this very purpose. Not all machines implements them though.
            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.

            Comment


            • #16
              Originally posted by ssokolow View Post
              That wouldn't help. After a kernel panic has occurred, you can't really trust anything because there may be arbitrary memory corruption. (It's basically the closest thing to the kernel segfaulting, except that the part which just "segfaulted" is the part responsible for detecting that something went wrong and the part responsible for keeping the system going.)
              Explain to my why anybody would care about verifiable system state to do a last ditch effort of informing the user of the reason why the system crashed? Implement the reasonably safest yet quickest/easiest to complete method and we'll see how well it does in practice. Get the ball rolling.

              In the name of usability, the best thing we should try is getting some error message over the the user. If the screen goes crazy. even that is easier to understand than just a frozen screen (will it ever resume? maybe the user was doing something important and is willing to wait hours)

              Comment


              • #17
                Originally posted by milkylainen View Post
                As a developer, sure. An UART is useful. As a normal user, not so much. Users probably just want to send that bugreport with the dump.
                Naturally. I was just using it as an example. In the UEFI era, there are better options such as storing the crash log in non-volatile memory before rebooting.

                Comment


                • #18
                  Originally posted by waxhead View Post
                  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
                  GNU Meditation?

                  Or if we are going Tux-themed, then the yellow-orange of his beak and feet as the screen color (which is also a natural 'warning' color anyway) :-)
                  Maybe an icon of the penguin attacking Linus :-P

                  Comment


                  • #19
                    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.

                    Comment


                    • #20
                      Originally posted by Space Heater View Post

                      I'd strongly prefer an explicit error message rather than a frozen or black screen.
                      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.

                      Comment

                      Working...
                      X