Linux Developers Consider On-Screen QR Codes For Kernel Panics

An anonymous reader writes "Linux kernel developers are currently evaluating the possibility of using QR codes to display kernel oops/panic messages. Right now a lot of text is dumped to the screen when a kernel oops occurs, most of which isn't easily archivable by normal Linux end-users. With QR codes as Linux oops messages, a smart-phone could capture the display and either report the error string or redirect them to an error page on Kernel.org. The idea of using QR codes within the Linux kernel is still being discussed by upstream developers."

Comments

Good idea

[Primate Pete]

I'm not sure how hard it would be to pull this off in practice, but kudos to the team for improving (or at least thinking about) better usability from the kernel out.

Re:Good idea

[Kjella]

Very unlikely.. the information in a QR code is probably just enough to say "I run kernel X (build Y) and it crashed with error code Z at instruction 12345 in module 123", if it was a kernel dump that's different but I have seen these without the QR codes and there's nothing sensitive there.

Re:Good idea

[Levex]

We are encoding the full Oops, i.e. from the "cut here" to the "end trace" marker. Classic won't ever go away, and we had already created a configuration option called CONFIG_QR_OOPS that can disable this at all. In case your distro or you had compiled it in and you don't want to have QR codes on your screen, I just added a new kernel parameter currently called 'qr_oops', which can as well disable it.

Re:Good idea

[Pinhedd]

Kernel crashes occur when the kernel enters an inconsistent or invalid state from which it cannot recover.

When a user program fails, the kernel maintains consistency, can cleanly terminate the process, and can accurately report the cause of the failure if need be (illegal instruction, deadlock, access violation, etc...).

When a kernel fails the very systems that it relies on to report failures may very well be compromised by whatever caused the kernel to fail in the first place. As such, any kernel fault reporting needs to be incredibly robust and as independent of other kernel mechanisms as possible. Dumping text to a serial terminal is the preferred method because it's incredibly simple and relies on nothing else, meaning that barring a failure of the system memory it should always act as a reliable fallback.

Dumping kernel memory to a disk might fail if the state of the file system is compromised, if the storage controller is compromised, or if any number of intermediary systems are compromised by the inconsistent state of the kernel. Many operating systems do attempt to dump crash memory to the swap file / swap partition as this is less likely to cause data corruption than writing to a particular file in the file system.

It "can" be done, but that does not necessarily make it a good idea.

Re:Huh?

[ledow]

You lose nothing.

Anything that could have been logged to disk will have been.

Anything that couldn't is probably FAR TOO LONG to even start taking down any other way and almost certainly will cut through the screen buffer limit anyway (every kernel panic I've had - which is about a dozen I think - was like that).

Let's compare and contrast to, say, Windows. Bluescreen with minidump and error code that has 7 million potential causes.

At least with a QR code, for those totally undumpable errors, you stand half a chance of snapping it and providing several kiloybytes of useful information for someone to work from - that they know hasn't been transcribed wrongly. And can be taken from even a completely hung machine.

It's a good idea. Someone needs to make a patch for it. The biggest problem - as always - will be making sure you can get to the point that you can write to the video memory and do so with enough processing / storage to be able to write something useful into the QR code.

Re:Wish other OSs did this...

[Anonymous Coward]

And with QR codes, the conversation becomes this:

"My computer froze."
"What happened?"
"It put some white and black crap on the screen."
"What did it say?"
"How the fuck should I know? It was random white and black dots! Like a fucking Rorschach test!"
"It probably was a kernel panic. What was the error?"
"I dunno, because like I said, ALL IT HAD WAS SOME DOTS AND SHIT. Then it rebooted! So it's gone! FUCK!"

How is that an improvement? Yes it's a change, but it's not an improvement.

Re:Huh?

[Guspaz]

QR codes use Reed-Solomon error correction, so you don't get missing or corrupt data (in that the QR reader knows if it reconstructed all the data correctly or not). Readers will typically only "read" the code if they manage to reconstruct the entire thing. The error correction helps compensate for poor image quality, and the fact that the image is monochrome makes things like exposure less critical. There are four levels of error correction, which allow for the reconstruction of 7%, 15%,25%, or 30% of codewords respectively.

QR codes can store up to a bit under 3KB of data (the largest size with the lowest error correction), but I couldn't get my phone to read any v40 QR codes (the largest ones), and v25 took some effort. The plan for QR codes of kernel oopses will probably fail for that reason, if nothing else (that they need v40 codes to store an entire oops, and few phones will read v40 codes).