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

[Anonymous Coward]

how soon until someone accidentally posts a QR code containing confidential information, since they cannot read it themselves.

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

[Zocalo]

It might actually be more than that. Worst case, the screen in in 80x25 text mode (assuming a PC), which gives 2,000 binary bits, but if you start playing around with extended ASCII graphics characters you could probably encode a KB of data quite easily. Hardly a crash dump, but easily enough to get across the essentials.

Re:Good idea

[Guspaz]

They're encoding the kernel oops. Here's one example oops they're using in that thread:

http://levex.fedorapeople.org/...

Re:Good idea

[davester666]

You are confusing what is encoded in a QR code and what is displayed textually onscreen.

Re:Good idea

[TFlan91]

you're assuming everyone has a smartphone. this idea is completely cutting off non-smartphone users

Re:Good idea

[Anonymous Coward]

You just have to reprogram the VGA font table with 2 wide by 4 high bitmaps (because you can fit 256 such glyphs into the standard vga font table), and you now have 16000 pixels to work with instead of 2000, a bitmap display with a 160x100 pixel resolution; VGA text mode is 640x400 pixels, and each virtual pixel is 4x4 screen pixels, the standard VGA font is 8x16 pixels.

BTW, you can't encode 2000 bits into a QR code with a 2000 bit bitmap, as it has parity and spatial clock recovery built in to the code.

Since the system has crashed, there is no harm in replacing the vga font table, and it is so universal that you can do it on all hardware with VGA (the font table is always at a fixed memory address in PC architecture) without any interaction with device drivers.

Of course you can also put the VGA into a standard graphics mode with no knowledge of the previous graphics card state, simply by programming known io ports with known values, this actually seems altogether more reliable than relying on the Linux framebuffer drivers which don't always work when X11 drivers are using the hardware, but could be considered reliable if KMS is used.

Re:Good idea

[rnturn]

``Hardly a crash dump, but easily enough to get across the essentials.''

Here's a crazy idea: instead of working on displaying cutesy graphics images that need to be decoded using a smart phone and a web site, what about actually generating a freakin' crash dump? Is there a technical reason that Linux is unable to do this? If crash dumps are really not possible, how about a plain 'ol text file in the root directory containing the reason for the crash/panic?

Re:Good idea

[Primate Pete]

No, it's adding smartphone users. I presume the basic panic information would continue to be available.

Re:Good idea

[Anonymous Coward]

Why would adding a QR code preclude generating a crash dump like usual? If you have a crash dump and can use it, the QR code won't change anything. If the after the crash a disk is not accessable, then you now have a format that is easier to "copy-paste" in effect by using a smart phone, or if you don't have one, tediously writing down any other text information on the screwn.

Re:Good idea

[Anonymous Coward]

Crash dumps are possible and exist already, there's just not enough real estate on a monitor to view the entire dump

Plain text files aren't necessarily possible as the crash means everything is suspect and any writing to the disk a) might fail or b) might cause data loss by corrupting the filesystem

Re:Good idea

[thegarbz]

Just from my own experience the only kernel panic I've ever encountered was due to a failed SATA controller. But conceivably bugs in new beta file systems (you jumped on the brtfs bandwagon yet?), hardddisk failure, SATA failure, or failure in the PCI controller.

Mind you that's not a reason not to do it, just that there are times when it's not useful. The same machine with the dead SATA controller also had Windows on it which managed to bluescreen without creating a crash dump.

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

[icebike]

how soon until someone accidentally posts a QR code containing confidential information, since they cannot read it themselves.

Since the crash handler itself generates the code that takes your phone's browser directly to the report site, this isn't going to be a problem.

Have you never actually uses a qr code the leads to a web site?

Re:Good idea

[jones_supa]

Plain text files aren't necessarily possible as the crash means everything is suspect and any writing to the disk a) might fail or b) might cause data loss by corrupting the filesystem

How does Windows do it then?

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:Good idea

[Pinhedd]

Windows writes crash data to the swap file and even then it fails from time to time.

Re:Good idea

[AmiMoJo]

You usually don't want to write to the filesystem in the event of a kernel panic. It could make things worse and corrupt it. Once you kernel panic you are basically screwed and can't rely on any services beyond really low level BIOS stuff to work. Poking some text to the screen buffer is about it.

Windows does core dumps using a specially reserved area of the boot drive and using low level boot driver calls. It can still fail but at least has a fairly low probability of damaging the filesystem further. I suppose Linux could maybe dump to the swap partition or something.

Re:Good idea

[Lemming Mark]

As AmiMoJo also noted, when you have a kernel panic all bets are off regarding which parts of the kernel are OK. If the behaviour of the disk driver or filesystem have been affected, it could damage your filesystem to try to write a kernel dump into a normal disk partition. It might work but it does seem a good idea to be properly paranoid. I didn't know that Windows uses a special reserved area of the boot drive - that does make sense as a solution!

There have been various systems for crash dumping under Linux, though. I think the de-facto solution (the one that was accepted by the kernel devs) ended up being kdump, which is based on kexec (kexec is "boot directly to a new kernel from an old kernel, without a reboot"). This allows full crash dumps with (hopefully) decent safety, so it is possible to do this if configured.

In kdump, you have a "spare" kernel loaded in some reserved memory and waiting to execute. When the primary kernel panics it will (if possible) begin executing the dump kernel, which is (hopefully) able to reinitialise the hardware and filesystem drivers, then write out the rest of memory to disk. I'm not sure how protected kdump's kernel is from whatever trashed the "main" kernel but there are things that would help - for instance, if they map its memory read only (or even keep it unmapped) so that somebody's buffer overflow can't just scribble on it during the crash.

Obviously, having a full kernel available to do the crashdump makes it easier to do other clever tricks, in principle - such as writing the dump out to a server on the network. That's not new, in that there used to be a kernel patch allowing a panicked kernel directly to write out a dump to network, it just seems easier to do it the kdump way, with a whole fresh kernel. Having a fully-working kernel, rather than one which is trying to restrict its behaviour, means you can rely on more kernel services - and probably just write your dumper code as a userspace program! Having just installed system-config-kdump on Fedora 20, I see that there's an option to dump to NFS, or to an SSH-able server - the latter would never be sanely doable from within the kernel but pretty easy from userspace.

Various distros do support kdump. I think it's often not enabled by default and does require a (comparatively small) amount of reserved RAM. So that's some motivation for basic QR code tracebacks. I suppose another reason is if they expect they can mostly decipher what happened from a traceback, without the dump being necessary - plus, with a bug report you can easily C&P a traceback.

This discussion has just inspired me to install the tools, so maybe I'll find out what it's like...

Re:Good idea

[ericloewe]

In case of a panic, you don't really want to be messing around with disks, in case you break something.

Re:Good idea

[drinkypoo]

Just from my own experience the only kernel panic I've ever encountered was due to a failed SATA controller.

In recent times I have also had a kernel panic due to a failed nVidia driver.

Re:Good idea

[awshidahak]

I have a smartphone, but it can't scan QR codes because the camera is too crappy.

Re:Good idea

[Pinhedd]

I never claimed that it was hard. I claimed that it's not bulletproof and it requires substantially more forethought than at first seems

Re:Good idea

[Pinhedd]

Says the AC.

My understanding is that crash dumps are written to the swap file and the crash dumps are extracted during the next boot when the kernel is once again in a consistent state

Re:Good idea

[Spugglefink]

I have a couple of bad micro SD cards. Put one into a card reader on a Linux machine, try to read some of the files, and presto magnifico, kernel panic every time. Windows handles this corruption a lot more elegantly, incidentally, but the hardware is toast either way.

Re:Good idea

[strikethree]

If crash dumps are really not possible, how about a plain 'ol text file in the root directory containing the reason for the crash/panic?

It is easily possible to do what you want. Trivially so... so why isn't it done? There is an answer to that question my friend and the answer is this:

A kernel will panic when it detects that the environment it is running in is not the same environment it thinks it is running in. What this means is that the kernel can no longer be certain of anything, up to and including whether or not it can write coherently to a file system. Rather than potentially trashing your file system, the kernel just prints to the screen as nothing can be damaged by that... but even that is dangerous. What the kernel thinks is the screen may not actually be the screen anymore.

In other words, once there is corruption in the kernel's environment, all bets are off and nothing is guaranteed, not even writing an error message to the screen. Writing coherently to a file system is actually a fairly complex event and is extremely dangerous in this situation.

Re:Good idea

[strikethree]

Thank you. You are awesome! I like the compile time and parameter passing configuration options to both be available. You are smart and doing it right. Keep on keeping on. :)

Re:Good idea

[dizdar]

“Yeah, that sounds bad. Have you checked the log files for errors?” I said, “Indeed, I would do that if I hadn’t broken every component that a logging system needs to log data. I have a network file system, and I have broken the network, and I have broken the file system, and my machines crash when I make eye contact with them. I HAVE NO TOOLS BECAUSE I’VE DESTROYED MY TOOLS WITH MY TOOLS. My only logging option is to hire monks to transcribe the subjective experience of watching my machines die as I weep tears of blood.”

Quote from here

Huh?

[Anonymous Coward]

And if no one with a phone is there?

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:Huh?

[ledow]

Just over a kilobyte, I think.

But that can be compressed as it doesn't NEED to be human-readable any more. So you can easily fit in a few Kb of useful data, I should think.

And as data density rises, so does the error correction but if the QR code reads (you have a device that reads them directly, why bother to snap a shot then process the image separately?) then it was a success. Hover and hold until you get the beep, on almost any smartphone made this decade.

But, no, you won't get CORRUPT data. The QR code either works or doesn't, like barcodes either scan or don't. You don't scan a book and get sold a DVD. Same principle.

What you might have is trouble getting a decent QR read on a crappy low-res camera but that's - again - no worse than the prior situation where I've seen kernel-panic screenshots you can't even read, let alone decode.

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).

Re:Huh?

[Kjella]

What is the size limit of a QRcode? Doesn't increasing the density of information contained in the image lead to the possibility of corrupt/missing data due to poor camera quality, motion blur, over/under exposure, or something along those lines?

They contain quite a bit of error correction so either it won't decode or it will with >99.99% probability decode correctly. You can store almost 3kB in a 177x177 QR code, but for the same physical area it's a trade-off between information density and readability. The bigger you make the QR "pixels" the less camera resolution you need, but the less information you can store as well.

Re:Huh?

[Rich0]

Yup. For the most part the only way I can capture a panic/dump is by phone anyway, and a QR code would allow me to capture a lot more info than 25 lines of text in an image file.

If I post an image, I'm lucky if anybody looks at it. If I post the text of the error, there is a good chance that somebody will stumble on it using Google and actually make some use of it.

Re:Huh?

[MightyYar]

I'm sure the folks discussing this are smarter than I am, but this is Slashdot, so I'll do some uninformed speculation anyway. Because it's fun.

The sample oops is 3134 bytes in plain ASCII. Plain old zip gives 1589 bytes, xz does a little better with 1492 (and only 1446 with lzma). I believe xz could do even better if the dictionary could be fixed and thus not embedded in the file. Doing a base64 encode on that gets to 1929 bytes.

So it looks to me (based on my sample of one...) like you could use version 27 or 28 with the lowest level of error correction. Probably let the library just scale it to whatever size is necessary.

Re:Huh?

[Anonymous Coward]

Or they could invent a binary oops format.

All I care for understanding an oops is the stacktrace (4/8 bytes * stack-depth) and the contents of the registers (8bytes * 20 on x86_64, 4bytes * 33 on ARM, IICC) and a condition code (4 bytes), that's more like ~320 bytes.

Re:Huh?

[nadaou]

> (that they need v40 codes to store an entire oops, and
> few phones will read v40 codes).

few of today's phones perhaps. but the development of phones is
not exactly at a standstill, when QR-oops gets released with some
future kernel what will the phone technology support then?

to quote Doc Brown, you have to think four dimensionally.

Re:Huh?

[ncc74656]

curl http://levex.fedorapeople.org/... | lzma -z9c | base64 | qrencode -t ANSIUTF8

This produces output too large to fit on most screens unless your console font is ridiculously small or your screen resolution is higher than most (my notebook has a 15" 1680x1050 panel). Also, it appears the console (on Ubuntu, anyway) doesn't handle UTF-8. Falling back to ANSI, it's even farther from being feasible.

Re:Huh?

[Levex]

Yes this causes a big output since my (and I suspect yours as well) terminal uses size 12 fonts, but in the crash situation we do it one screen pixel per QR pixel. There is a file called qr_code.png in that folder I gave in the thread, which is the actual result unscaled. It's 147x147 which can fit on every screen I know of.
How to handle textmode is still an ongoing question. We'll first get it working on the framebuffer then maybe we'll find a solution for textmode, if it's even possible.

Re:Huh?

[MurukeshM]

That image is practically unreadable. As pointed out later on, the 600x600 scaled version worked much better and scaling each QR pixel by 3 is the current idea.

Re:Huh?

[serviscope_minor]

Plain old zip gives 1589 bytes, xz does a little better with 1492 (and only 1446 with lzma)

Interesting. I guess the xz header is marginally heavier than the old lzma tool. I think the compression algorithms are the same.

Doing a base64 encode on that gets to 1929 bytes.

wot no base 85? :)

The base85 encoding scheme is slightly more expensive (requires heavy use of integer division), but is more efficient (5 to 4 versus 4 to 3). Would give 1808 bytes instead.

Given the rather uniform nature of kernel crashdumps, you might be better off with Huffman encoding on 16 bit pairs, with a custom dictionary.

Either way though it looks perfectly possible.

Re:Huh?

[Levex]

I could read it with my phone, but yes that's what we agreed upon. I will implement scaling in the coming days

Re:Huh?

[Hamsterdan]

"If I post an image, I'm lucky if anybody looks at it. If I post the text of the error, there is a good chance that somebody will stumble on it using Google and actually make some use of it."

^-THIS!

While on the subject, any way to get people to stop doing how-tos with video? I can't print a video

Re:Huh?

[wonkey_monkey]

The error correction helps compensate for poor image quality

As long as people aren't abusing it to do things like this.

long-term applicablity?

[Anonymous Coward]

I worry about the long-term applicability of QR codes. In 10 years, are they still going to be convenient to read, or is some guy going to have to dig out an old smartphone to read the error output from his decade old system?

Re:long-term applicablity?

[istartedi]

No, just rebuild the kernel. It should be a build option for text or QR panics.

Re:long-term applicablity?

[Nikker]

The QR code has really nothing to do with smartphones. You could take a picture of it with any camera and upload it. QR Codes are just a software library that evaluates based on white and black marks within the picture.

Re:long-term applicablity?

[phantomfive]

I strongly support backwards compatibility, but chances are you won't have anyone to send it to, if you're running a 10 year old kernel. No one will want to debug that, except maybe yourself, but then you'll probably have all the stuff you need to read it (and might even have the text output piping to somewhere else, too).

Re:long-term applicablity?

[The123king]

People were probably saying the same thing half a century ago when barcodes were introduced

Not enough data

[MichaelSmith]

QR codes are highly redundant and don't actually contain much data. There isn't enough space for a stack trace or anything like that. Probaby not even a register dump on those big modern CPUs.

Re:Not enough data

[smittyoneeach]

http://en.wikipedia.org/wiki/QR_code

Re:Not enough data

[wiredlogic]

The 40-L QR code format (177x177) encodes 2953 bytes. That is a useable amount of data for a kernel dump.

Re:Not enough data

[Anonymous Coward]

1) No, 2953 bytes is not enough for a "kernel dump". "Kernel dump" as a term/phrase doesn't even make any sense, come to think of it. Did you mean a stack trace? Register dump? Because "kernel dump" makes me think of "memory dump", i.e. dumping all contents of RAM to swap + rebooting system (which later notices the crash dump header in swap and hopefully extracts it).

2) If just a stack trace or register dump: 40-L may be too high a resolution to reliably work when using a mobile phone camera to take a picture of an LCD screen. There's often too much noise (high ISO) in this situation. Lower-resolution QR codes means more likely successful recognition and decoding. http://en.wikipedia.org/wiki/Image_noise#Low_and_high-ISO_noise_examples

3) What I haven't seen mentioned: how exactly do the developers plan on printing a QR code when someone's using a text-only console? Don't tell me "everything on Linux console uses a graphical framebuffer now" because that's completely false (lots of folks disable this, and some distros disable it by default). What's going to happen when the kernel crashes? It uses BIOS INT 0x10 to switch to 320x200 VGA mode and show a QR code? Is it going to change the on-screen font masks/bitmaps to display "tiled" pixel data that represents a QR code?

I have a better idea: how about just keeping things how they are. People using mobile phones to take a photo of a stack trace + register dump mostly works reliably (barring wobbly hands). Console fonts are quite legible even if the person has consumed too much cappuccino, while QR codes, especially high-resolution QR codes, are going to be a lot less legible in that situation. My reaction to this proposal would be: what does using a QR code get us that we don't already have available with existing technology and methodologies in place? (FYI: the correct answer to that question is: "nothing")

Re:Not enough data

[Guspaz]

Except L implies the lowest amount of error correction, making it the hardest to read, and few devices will read 40 codes anyhow. They're enormous.

Re:Not enough data

[wiredlogic]

You don't need high levels of error correction. That is meant for printed codes that may be damaged. You aren't likely to be displaying on a screen that is so broken that large chunks are missing.

Re:Not enough data

[Guspaz]

It also means that, in marginal conditions, it can reconstruct code blocks that it didn't manage to read correctly. It's not just useful for printed codes.

Re:Not enough data

[jeremyp]

I have a better idea: how about just keeping things how they are. People using mobile phones to take a photo of a stack trace + register dump mostly works reliably (barring wobbly hands).

^^ This.

Add a bit of OCR software and you have a system that can both be read by humans without the aid of special software and by computers to produce textual output with a bit of special software (you need a bit of special software anyway for QR codes, so you don't lose anything).

Re:Dump kernel to serial printer

[smittyoneeach]

You gonna need a big bowl to catch all them corn flakes, mister.

They make about as much sense as anything else

[Anonymous Coward]

Inscrutable error messages seem to be par for the course when you're looking at kernel panics.

Re:Dump kernel to serial printer

[Hsien-Ko]

Ironically most older x86 motherboards (pre-1994) didn't have an onboard serial port either.

Re:Dump kernel to serial printer

[Anonymous Coward]

Or just display a short number code. Displaying a QR code won't solve anything, it will just obfuscate the error and leave the user without any easily memorable reference. This sounds more to me like "let's do it because it's modern and hip" rather than it being actually useful.

Wish other OSs did this...

[jpellino]

Anything's an improvement over:
"My computer froze."
"What happened?"
"It put some message on the screen."
"What did it say?"
"Something about an error."
"What error?"
"I dunno. It had some numbers and letters and stuff."

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:Wish other OSs did this...

[ToasterMonkey]

Anything's an improvement over:
"My computer froze."
"What happened?"
"It put some message on the screen."
"What did it say?"
"Something about an error."
"What error?"
"I dunno. It had some numbers and letters and stuff."

"Show me!"
"I already rebooted it."

Personally I would rather have a more sophisticated crash dump system, like other OSs, because whatever is going to fit in a QR code isn't going to help much unless you're looking up known issues in an enterprise Linux vendor's bug database. That's assuming they can cram a stack trace into QR codes, AAAAND you have a problem that leaves a predictable stack trace.

I don't remember the last time I had a Solaris system crash that didn't leave a dump (try not to giggle). It would have be be way back pre-ZFS, on a janky server without a dump partition. I'm also reading that Windows saves memory dumps to the page file going back to XP.

You go into the average Linux environment and even if it's not a "paid support is for wusses" camp, you are _EXTREMELY_ unlikely to have anything of value to send to support. Maybe your hawt X86 firmware will have logged an issue! ROFL.

Reboot and hope for the best :\

Re:Wish other OSs did this...

[Anonymous Coward]

I can't think of anyone I know who can't identify QR codes. They're stamped over fucking everything in retail now.

Re:Wish other OSs did this...

[Anonymous Coward]

I doubt the kernel developer that implements this would forget to put the message

"Make a photo of this black-and-white dots and send it to crash@kernel.org so we can try to figure out what happened. Thanks for making the Linux kernel better!"

at the top of the black and white dots.

Re:Wish other OSs did this...

[AmiMoJo]

I think most people with smartphones recognize QR codes now, so there is at least a chance they will be able to take an image or use a decoder app on it. Well, next time anyway. And hopefully it will have enough info for you to know what happened.

Re:Wish other OSs did this...

[Prototerm]

And suppose you don't have a smartphone?

Re:Wish other OSs did this...

[Flammon]

There's no need to take a photo and send it; the QR code can include a URL with crash info. The user would simply need to scan it and follow the link.

The message could be: "Please scan QR code to report Linux kernel bug."

Re:Wish other OSs did this...

[tomlouie]

"You are infected with a virus! Scan this QR code RIGHT NOW to clean your OS!"

Re:Wish other OSs did this...

[mlw4428]

I know many people (even those in their 30s) who can't easily ID a QR code.

Re:Dump kernel to serial printer

[Anonymous Coward]

Nothing is stopping you from displaying a short summary of the error and a code number in addition to the QR code. Depending on how much information gets jammed into the QR code though, it can be a lot harder to dump that all to the screw and expect a person to remember (or even write it down correctly).

Re:Dump kernel to serial printer

[khellendros1984]

Or do both. Short number code, some diagnostic data on the screen, and a QR code linking to more info. The QR doesn't have to be much more than a couple square cm in a corner of the screen.

You get the prize of dumbest comment on slashdot

[Anonymous Coward]

Really? You think your end user who hasn't got the brains to take a screenshot of human readable text and send it to you and who probably has never even heard of QR codes is going to have the presence of mind and technical knowledge and ability to take a picture of the code and send it to you?

That has to be one of the dumbest things I've heard on slashdot...and that's REALLY saying something.

It's even more worrying that the Linux Kernel devs are giving this idea the time of day.

simple approach

[belmolis]

How about a slight modification of a classic: Just change the background color of the display. Even 1 byte RGB gives you 256 messages. (I guess lighting would affect this.)

Re:simple approach

[jones_supa]

How about a slight modification of a classic: Just change the background color of the display. Even 1 byte RGB gives you 256 messages. (I guess lighting would affect this.)

Even if we could accurately capture the precise background color value of the display, how could only one byte give enough information for anything useful?

Re:Dump kernel to serial printer

[Anonymous Coward]

But back in the days ISA based parallel and serial cards were commonly used and low level enough (using the well known IRQ/ DMA/ memory addresses) to just work and stand in as system console. Today's PCI or USB serial adaptor cards are overpriced (rare) and just that, not the 'real thing' but higher level adaptors, leaving several of the old fashioned protocols unsupported and mostly not being able to be used as ttyS0 (or COM1) as it's neither supported by the low-level drivers nor takes I/O 0x3f8 and irq 4.

Re:Dump kernel to serial printer

[Anonymous Coward]

No! We cannot do both! It must be either one or the other!

Re:Headless systems or Virtual Machines?

[Anonymous Coward]

Or enable SOL...

No way!

[msobkow]

I am NOT buying a fucking cell phone to read a core dump.

Just fuck right off already. Not everyone wants a digital leash.

Re:No way!

[adnonsense]

You don't need a cellphone to decode QR code images.

Just sayin', like.

Re:No way!

[msobkow]

Troll?

How so?

Because I don't want to buy into the digital leash mentality that "everyone owns a cell phone?"

Fuck you.

Re:No way!

[Levex]

You don't have to buy a smartphone. This is entirely *optional* and 'classic' will not ever go away.

Re:Dump kernel to serial printer

[polymeris]

There is only so much information you can store in a couple square cm, if you want it to be able to be reliably retrieved by a camera, qr code or not. Your comment.

Re:You get the prize of dumbest comment on slashdo

[Anonymous Coward]

The point here is that in a kernel panic, there's no way to save a screen shot or copy-and-paste anything into a file - all you have is (probably) a full kernel dump and a message on the screen, which can be transcribed with errors, and Step 2 is rebooting.

Just drop to debugger mode on reboot.

[VortexCortex]

This is why my alternate OS eschews absolute minimalism and includes mandatory "userspace" features in its design, so it can rely on them being present. I handle the whole (multi) boot process within the OS, so I can launch other OSs from within a running instance. Boot process integration was necessary for firmware segmented loading (optionally put part of the OS in firmware, see: Coreboot). Since the OS handles boot itself it can avoid immediately crapping all over memory at boot and instead upon soft-boot the early-environment kernel detects whether the OS is resident in memory, whether the kernel halted properly in a "panic" or froze due to other lockup/powerloss, whether an unrecoverable error occurred, what the error message(s) are, walk the memory manager and move pertinent information out of the way into previously unused memory pages, then load the 2nd stage kernel into RAM with the debug option enabled (unless --no-debug is passed by its bootstrap loader's manual override). Finally the OS continues its boot process and its built in debugger launches, so I can read any detailed prior error messages left, save/print them, and attempt to debug the last thing the kernel or any of its programs was doing, or mark the prior memory free and return to standard operations. While there is no guarantee the RAM is still valid I can even attempt to restore program states and resume operation after a "panic" (if the bug was something small fixable via correcting a few erroneous bytes of memory).

Unlike Linux, my kernel includes many dedicated features of a full operating system, such as text editor, assembler, disassembler, compiler, file-system, debugger etc. so it is larger than Linux kernel itself in footprint. I can optionally remove some of these essential features if needed for my embedded projects, but I never have since memory isn't that expensive -- Being able to debug via serial console a glitched robot after reset is a godsend. Less modularity comes with its downsides, but the pros of being able to deploy programs as cross platform byte-code and have the OS "compile on install" programs into its private internal file system, and cryptographically sign the cached binaries to optionally secure the entire boot process and all running processes, far outweighs the cons. Being able to debug itself is just a side effect of other design decisions.

My "Toy" OS design has many similarities with classic OSs of old (bytecode instead of BASIC baked in), and seeks to address problems I foresaw with lack of hardware enforced sandboxing API in modern OSs: My kernel can run a program or its modules as emulated bytecode if the code is untrusted, or is loaded as a plugin. I use more than just the two userspace / kernelspace execution privilege levels in order to hardware-enforce something like a submodule level SEGFAULT to grant applications more control over their plugins or runtime scripts (also compiled as bytecode by the OS via scripting API).

4 execution privilege rings are available on x86, as opposed to 2 on ARM and thus some security features are not hardware enforced on ARM -- this is an instance of modern monolithic OS design influencing hardware design (everyone's using only 2, so ARM has 2 rings), much as C'ish calling constructs influenced x86 chipset instructions (ENTER, LEAVE, etc.) which BTW lead to inherently insecure practices such as placing mutable parameters and code pointers on the same stack (stack smashing / overrun is prevented via separate call and data stacks, kind of like good ol' FORTH used -- I'm only able to do so because all executable code is required to pass through the OS compiler / sanity checker).

I'm now seeing many of these features appear piecemeal in higher level constructs: E.g. Google's NACL bytecode for Chrome "apps", or .NET bytecode being able to go native, or Android's JIT and its native code interface, etc. I think future OSs would benefit from adopting better software deployment systems by incorporating a compiler / debugg

Re:Just drop to debugger mode on reboot.

[Anonymous Coward]

Am intrigued by what you're saying. It's either a late april fool, or what sounds like a very interesting project - can you provide a link to details of the OS?

Re:Just drop to debugger mode on reboot.

[Zontar The Mindless]

Or better yet, a link to source or installation image.

The matrix

[BlazingATrail]

I prefer all my BSOD, crashes and core dumps to use the Matrix dripping green characters and pixel crap method of reporting errors. It's easier to see the patterns. Guru meditation # 42

Re:The matrix

[Prototerm]

Extra points for the Guru Meditation Error! C=

Re:The matrix

[strikethree]

LoL, I was terrified the first time I saw Guru Meditation Mode. I thought I had broken my computer forever... that being said, there is no #42 (maybe a funny Douglas Adams reference?).

http://en.wikipedia.org/wiki/G...

Re:The matrix

[BlazingATrail]

Of course,.... 42 is the answer but we will never know the ultimate question!

Great idea but limited

[zzyzyx]

I think it's a great idea to make error reporting easier. I recently experienced an oops but didn't report it because there was no immediate way to do it. However relying on a framebuffer being present is a mistake, in my case it was on an embedded headless system, and framebuffers generally are available only on desktops which are far from being the majority of Linux usage.

Re:Great idea but limited

[Levex]

If your embedded board has a HDMI connector, then there is a great chance there is a framebuffer as well. AFAIK, most embedded system only ship a framebuffer and somekind of serial output interface. The real problem in fact is how would you get that framebuffer after a crash occured and you don't have a screen nearby to connect to the HDMI/VGA connector.

Re:Great idea but limited

[serviscope_minor]

Yeah, the more deeply embedded, the bigger the pain. Most embedded things have some sort of serial port, and I believe you can send plain text dumps over that.

Re:Great idea but limited

[Levex]

That already exists in the kernel by providing "console=ttyS0,9600" or so on the command line. :-)

Re:Dump kernel to serial printer

[flyingfsck]

Bah. Punch cards are so much better. You young, know nothing, whipper snappers with your newfangled hoosammawhatsits...

Re:Dump kernel to serial printer

[rogoshen1]

subset of linux users with access to only one device vs the subset of linux users who would troubleshoot a machine via cell phone.... ?

Re:Dump kernel to serial printer

[icebike]

Or just display a short number code. Displaying a QR code won't solve anything, it will just obfuscate the error and leave the user without any easily memorable reference. This sounds more to me like "let's do it because it's modern and hip" rather than it being actually useful.

The QR code can not only indicate the exact location of the error, but can take you to a website on the phone, with a url long enough to log
  many key points about the error.

Even if it logs very little, developers will get more input this way than they do now, because when your machine is crashed, you can't report anything and once it reboots, you have other priorities than digging in the last crash dump.

However, other than collecting statistics, it might not do any good. Even when you do submit a dump, you get the request to install debug symbol packages and trigger the crash again. Ah, no, that isn't going to happen. Or there will be necessary drivers installed that taint the kernel, and devs wont touch it until replace your video card, untaint your kernel, and trigger another dump.

Re:And people think Linux is GOOD? REALLY?

[Zontar The Mindless]

Do you even know what a kernel panic is, or what is likely to cause one?

Re:Worst idea I've heard in years.

[Levex]

They won't disappear, it's going to be optional and will be seamlessly available next to the text crash.

Re:Kernel "PANIC"

[Zontar The Mindless]

From our friends over at Merriam-Webster:

panic
noun

: a state or feeling of extreme fear that makes someone unable to act or think normally

: a situation that causes many people to become afraid and to rush to do something

You were saying...?

It would help, some.

[Anonymous Coward]

The current model of kernel panics is broken.
Currently, we can diagnose a fault if: The user has access to the console (unlikely, machines are usually in data centres, though some of them manage to set up KVM properly) and can take a screen shot (more likely, nowadays, thanks to phone cameras) and the useful information (the backtrace) hasn't scrolled off.

This solution addresses the third part.It does nothing to address the first; and makes the second worse. (You really expect the QR code to be useful after it's been displayed on the crustiest monitor in a datacentre, captured at a weird angle on a phone and sent to us as a badly compressed jpeg?)

I understand the technical reasons why the crash cannot be written to disk - the kernel has crashed, disk drivers are in a bad state.
But can we please write to a reserved partition with a dedicated driver, or something? Or make netconsole a default?

Just show smileys

[Anonymous Coward]

Linux must be ubuntufied. We need to hide everything because it's way to complicated for the common user or his dog. We need more splash-screens to hide all the stuff that makes no sense anyway. Who want's to know if a module didn't get loaded? As a matter of fact, we should remove unnecessary logs (like message, dmesg, audit), because nobody gives a rats ass. Also: Why have a console? Or init-mode 3 ? People want the graphical stuff, let's get rid of all the ballast like command-line. Those few people still using ancient tools like 'make', 'vi' or (o my god) 'ifconfig' should go and find themselves something else to brag with. Linux MUST go mainstream.

Re:Just show smileys

[jones_supa]

That is somewhat a problem, I agree. Please make this QR code display friendly, such as "Your operating system kernel has crashed. For advanced users, a QR code containing additional information is provided below. By taking a photograph of it, you can help the developers to solve the problem. [QR code picture] Press any key to restart." Maybe include the Tux logo there to show that this is about Linux.

Wayland should improve the situation too, as we can settle with a proper graphics more earlier at the boot. The current situation of flashing back and forth a framebuffer console and some kind of clunky boot animation is terrible. And god forbid if there is some spurious messages shown as "kvm: disabled by bios" which will only confuse the newbie to think that something is wrong.

Yeah. Make it smooth, I say.

Re:Just show smileys

[serviscope_minor]

We need to hide everything because it's way to complicated for the common user

I don't really care about the common user: I like linux much the way it is. However, I don't like transcribing whole screenfuls of text by hand to report bugs. That massively, royally sucks.

This isn't about making Linux shiny-happy it's about making it easier for developers to debug the kernel.

Re:Just show smileys

[The123king]

Linux is mainstream... Android is based on Linux, the Big Blue supports Linux on its big iron, most web servers in existence run Linux. Because of this, removing the command-line stuff will almost always be counter-productive. One of Linux many strengths (and perceived weaknesses) comes from its command-line.

GNU/Linux will always be associated with sandal-wearing neckbeards, and nothing will ever change that. You should be glad that the majority of the internet, the majority of smartphones, and the majority of academia use Linux on a day-to-day basis. Their will never be a "Year of the Linux Desktop", but the "Year of the Linux Smartphone", "Year of the Linux Server" and "Year of the Linux Mainframe" have all been and gone.

Re:Dump kernel to serial printer

[TheRaven64]

Is the point to give the users something useful? I assumed it was to give the devs something to debug. Asking the user to transcribe a kernel stack trace is not likely to happen, but a QR code that encodes a bit of text saying 'please email to crash@linux.org' followed by the stack trace would mean that you'd actually get something vaguely useful in some cases, rather than the user just shrugging and power cycling the box.

Re:So...

[jones_supa]

There isn't, and that is quite common actually. However the QR code could encode more information and, with some nifty algorithms, can be automatically interpreted from a photograph to kernel crash information files.

Re:This would be nice, but

[jones_supa]

That would be so tricky that it's probably not feasible for the attacker. Basically you would have to both have a vulnerability in the QR code processing code in the phone and, a compromised Linux kernel in your PC which injects malicious data into the dump.

But yes, you raise an interesting point.

Bug reporting will be much easier

[allo]

Do you want to mail them physical screenshots? With a qr code, you can mail text.

"Stealing" my idea :(

[Megol]

(Not true as I haven't communicated that idea to anyone - and an idea can't be stolen anyway).

There are a number of advantages of doing this, non-technical people are likely to be familiar with QR-codes, most people have access to digital cameras and resources to convert the QR code to a link and using this works as long as the screen can be written to. Storage system failure or network system failures wouldn't be a hinder to provide a thorough failure analysis.

The sole disadvantage IMHO is that one have to have a QR encoder resident and functional at the time of a panic. Not a big problem.

Re:"Stealing" my idea :(

[The123king]

Your idea was "stolen" nearly 2 years ago mate.

Re:Worst idea I've heard in years.

[serviscope_minor]

Now they want to bury the kernel error messages in a QR code? That REALLY takes the cake.

This is not burying or hiding. It's there in full view if you have a decoder, and even better, you can send it to a mailing list without having to transcribe the sodding thing by hand. Bonus: no transcription errors!

Seems like a win to me especially as no one is ever planning on making it mandatory. It's a fantastic option if you don't have a convenient way to log a serial console.

I'm massively not a fan of exsessive complexity, but this atually sounds like a neat idea.

Catch up...

[The123king]

Linux was beaten as the first by a long shot. Haiku has had this for 1 3/4 years.

Re:Dump kernel to serial printer

[KozmoStevnNaut]

A lot of newer motherboards actually have hardware serial and parallel ports again. I've been looking at LGA 1150 motherboards, and I would estimate that at least half of them have those ports.

Re:And people think Linux is GOOD? REALLY?

[The123king]

A problem has been detected and Slashdot has shut down to prevent damage to your brain

The problem seems to be caused by the following user: ANONYMOUS COWARD If this is the first time you have seen this Stop error screen, refresh your browser. If this screen appears again, follow these steps:

Check to see if any new topics or comments are properly displayed. If this a new comment, ask Slashdot to filter Anonymous Coward comments you don't need.

If problems continue, disable or remove any newly-posted Anonymous Coward comments. Disable short-term memory options such as recall and storage. If you need to use Moderator points to remove or disable comments, press the drop-down menu below the comment, and then select -1 Troll.

Technical information:

*** STOP: 0x0000050 (0x616E6f6E,0x796D6F75,0x7320636F,0x77617264) ***

*** ANONYMOUS COWARD - Address 63726170 base at 706F7374 datestamp 35343134/code

Re:And people think Linux is GOOD? REALLY?

[gnupun]

Can kernel panic info also be saved to a disk log instead of just showing it on the screen? It could also be logged to a USB drive or something connected to the network or in the extreme case, CMOS space in BIOS.

Whatever the method, the log information should be easily accessible on reboot without the use of cameras/cell phones etc.

Abnormal Linux end-users do fine.

[fygment]

It says, `` ... most of which isn't easily archivable by normal Linux end-users. Abnormal Linux end-users easily archive the text. If you have to use QR codes ... maybe you aren't the right kind of Linux end-user. Just saying.

Re:Dump kernel to serial printer

[kelemvor4]

Who cares, motherboards still come with expansion slots? PCI 2-Serial/1-Parallel Port Host Controller Card $3.67 If you want a serial card, put one in.

Fine, but could have problems

[fa2k]

Good idea, but I hope they keep all existing systems in place, and make it optional. Graphics drivers are massively complex, and are probably a significant source of oops. If displaying a QR code means that the kernel needs to interact more with the drivers, and (oh god i hope not) change the resolution to display a QR code, then I expect more fail. People can take photos of the crash messages in 80x25 character consoles anyway, so let's not destroy that.

Re:Dump kernel to serial printer

[CurryCamel]

Ok, then.
Then all we need is a printer to hook up to that serial port.

Re:Dump kernel to serial printer

[Hal_Porter]

You could sound the message out in Frequency Shift Keying.

E.g.

http://en.wikipedia.org/wiki/K...

1200 baud is 120 characters per second. So you could dump an uncompressed 80x24 screen of text in 16 seconds. You'd just repeat the dump over and over again.

Software on a mobile phone would capture the FSK and submit it as a bug report.

Perhaps a less whimsical way to do it would be to write to a dump file and submit when the system reboots. E.g. the kernel could keep enough of the Bios alive so that it could switch back to real mode and use int 13h to write to reserved bit of the disk.

Obfuscation of a sort

[userw014]

How is using using QR codes any improvement over such dusty techniques as unique error numbers, like "ABEND 07235453" - other than it doesn't require any discipline in registering error numbers?

Wouldn't integrating the frame buffer into kernel oops messages be one (small) step into the MS/Windows disease of integrating user land GUI primitives in the kernel?

This seems to be a solution for desktop (or laptop) Linux only - so it shouldn't be the default.

Most of the time when I'm dealing with Linux, it's either as a tablet (android), a server (used to run 150 headless servers, now I run only about 30), or as an embedded device from the low-end (an internet camera or a WiFi router running DD-WRT) to high-end (research lab equipment supported by a vendor.) My work desktop (Ubuntu) already hides as many error messages as possible, and I don't expect any Linux desktops in an office/workplace setting to reveal such messages - whether they're text, QR code, or cryptic IBM-like ABEND number.

Yes, it'll help Linux geeks report kernel oops messages to the kernel developers better (provided they can capture the image). But for most uses of Linux, it's unnecessary complication.

Re:You get the prize of dumbest comment on slashdo

[jpellino]

Yes, I do. http://i.imgur.com/zMyvT.jpg

I think having the option to scan the QR code with a simple message to do so is one more way to get the info needed.
Aiming a smartphone at the screen is easier than framing a screen with your phone's camera and hoping for a solid shot without a flash before it does something even stranger.

They're used on beer ads, chain pizza ads, breakfast cereal and at Disney parks.
So yes, I think the average end user has a shot at this.

I'm thinking of Windows in particular, that usually ends up with anywhere from one to a dozen lines of codes to reference.
Linked to a database, it has all the info you need.

It's pretty reliable stuff: http://datagenetics.com/blog/n...

Which is likely why people would rather scan QR codes than take pictures of every magazine ad they see.

Re:Dump kernel to serial printer

[X0563511]

*cough* you can already do all this if you want.

(just include your magic in the kdump init script / initrd to do with the dump information as you will)