Announcement

Collapse
No announcement yet.

DRM Panic Handling Is Back To Being Talked About

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

  • DRM Panic Handling Is Back To Being Talked About

    Phoronix: DRM Panic Handling Is Back To Being Talked About

    During the early days of kernel mode-setting (KMS) one of the frequently talked about future improvements that could be made as a result of it were improved error messages (like Windows BSODs) in the case of problems and other improvements on that front. While patches have emerged from time to time, it still seems like functionality that's still less than fulfilled compared to the original talked about goals. Patches this week have been revived for DRM panic handling...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    I also have a vague memory or talk about calling a kernel debugger on panics.

    Comment


    • #3
      That would be nice, but please do not make them Blue :P
      ## VGA ##
      AMD: X1950XTX, HD3870, HD5870
      Intel: GMA45, HD3000 (Core i5 2500K)

      Comment


      • #4
        Let's see, what does Microsoft Windows do that Linux doesn't? I know, BSOD, let's add it!

        Comment


        • #5
          ideally, the system would just recover from any errors and (or, at least) write something to the system log about what happened. However, whenever that is not possible, it is nice to be able to get some information about what happened before rebooting.

          Comment


          • #6
            Someone trying to make Linux more user-friendly? He'll be shot, buried and ridiculed by the community.

            Comment


            • #7
              Originally posted by eydee View Post
              Someone trying to make Linux more user-friendly? He'll be shot, buried and ridiculed by the community.
              It does not seem this dev is getting "shot, buried and ridiculed" though.

              Comment


              • #8
                Originally posted by Nobu View Post
                ideally, the system would just recover from any errors and (or, at least) write something to the system log about what happened. However, whenever that is not possible, it is nice to be able to get some information about what happened before rebooting.
                This is about kernel panicking. It's for when the only way to recover the kernel is to reboot, the filesystem drivers are in an unknown state that could potentially corrupt data if called, and writing crash dumps to UEFI non-volatile storage to be recovered on next boot is still effectively a pie-in-the-sky idea.

                Of course, the most impressive approach I've seen is the Haiku (open-source BeOS successor) solution. A crash dumps you into KDL (Kernel Debugging Land) and KDL has a command which you can type to convert the debug output into a QR code for easy copy-pasting via smartphone.

                Comment


                • #9
                  Originally posted by Nobu View Post
                  ideally, the system would just recover from any errors and (or, at least) write something to the system log about what happened. However, whenever that is not possible, it is nice to be able to get some information about what happened before rebooting.
                  I am not so sure it is not possible. Have a look at Minix 3 (don't forget the 3). That is in essence a self healing kernel and that may very well be the future for operating systems.

                  http://www.dirtcellar.net

                  Comment


                  • #10
                    Originally posted by ssokolow View Post
                    writing crash dumps to UEFI non-volatile storage to be recovered on next boot is still effectively a pie-in-the-sky idea.
                    what are you talking about? this already works and I used this many times on my system already...

                    Comment

                    Working...
                    X