OSNews

simpler only if it works
if it doesn't it can destroy data

don't forget that you can't trust the kernel anymore when it KDLs

Windows does it fine. Sorry.

Windows is also not alpha-state software with only a handful of active developers that are actually familiar with the internal workings.

While running Windows, remove your system SATA disk/ssd and check how it works fine.
Now imagine that instead of human removal the cause is disk controler going crazy sometimes, not definitively. Or it's manufacturer driver is immature and don't have this quicky hardware workaround (disclaimer: all kernel crashes appearing in this comment are fictitious. Any resemblance to real ones, pending or past, is purely coincidental...)

How do you get enough data to discover the root cause?

Plus, please notice that Haiku don't have the resources Microsoft had to wrote its Windows kernel, and still it took a lot of time to reach a mature kernel crash features set. And calling the bluescreen a mature kernel debugger is kinda funny, BTW...

Edited 2012-07-03 09:39 UTC

Right, because that's going to work reliably when the kernel panics.

Right, because that's going to work reliably when the kernel panics. "

Well, to be fair, most people don't even know what a kernel panic is - or what it means...

Most OSes just do something fancy, like 'bluescreen', or reboot.

the BSOD is actually pretty advanced.

Considering it does it in the users own language and logs the result in the event viewer.

But hey lets just vote me down.

So English is Danish, eh?

No BSOD is actaully in the users own language for the most part. Including Danish I suspect.

Oh well, normal OSNews Crap.

Edited 2012-07-02 20:35 UTC

Amusingly, I think that was what most people were thinking when they read *your* comment.

Well still it doesn't invalidate the first sentence. The Windows Kernel panic is multi-language.

No other OS does that to my knowledge.

Only the best ones does both ;-)

Better would be to reboot into a google search of the BSOD error message/s that one didn't have time to read when it booted.

Noway. End-user may choose to stay in that "live-bsod" mode and enjoy reliable web surfing instead of return fixing his usual Windows experience...

Your KDL is caused by an issue relating *to* storage. How do you propose writing anything to the disk?

Your KDL is caused before any relevant busses are enabled. How do you propose writing anything to disk?

Why do you feel the need to make this volume of posts on one single topic without introducing anything new?

This doesn't even make any sense, are you serious or just trolling? Do you asume that every kernel panic will happen on the developer's system so he can fix it right away?

That's chicken and egg: how do you fix the root cause of most kernel panic in an OS without having solid crash reports in the first place?!

Promise, when Haiku kernel will be rock solid, we'll remove the qrcode feature and use instead a disk log writer. Happy?

BTW, why keeping a kernel disk log writer if your kernel don't panic anymore at all? Why instead of making Windows BSDO multi-langugage aware Microsoft don't fix the root cause of these BSODs in the first place?

Simple answer: because kernel developers needs it.
Period.
Now please, let's move on.

Please don't remove it (looks like you're involved?), I think it's great / brilliant / cute, an awesome idea... maybe even all informational popups etc. should have qrcode?


Though, I can see one downside - unpleasant shudder when seeing some random large QR code somewhere.
(kinda like my buddy used Windows error sound for SMS arrival, which made some people in public transport visibly disturbed, a bit)

Now I also wonder if QR code (~animation?...) could be extended to quickly transfer smallish amounts of data; I imagine it could possibly often be more immediately intuitive than bluetooth or wifi.

Edited 2012-07-06 02:19 UTC

I LOL'd. ^_^

It's just an extra feature to aid in the process of reporting bugs when the kernel crashes. The old method of taking a screenshot using a camera still works fine.

As for me, I don't have a smart phone but I also haven't seen Haiku crash in a long long time on my computer.

Or you could spend time writing the error log to the primary storage device which the OS already knows.

One of the possible causes of the kernel panic is not being able to access said device, so where do you suggest to write the log?

But let's say you actually dump the file. What if the system doesn't boot anymore? Do your move the partition / drive to a different Haiku machine?

Do you realize this is an, WIP OS with no stable release right?

Edited 2012-07-03 00:14 UTC

Writing data to a storage device requires a lot of hardware control to *still* work. What happened when the boot device is an USB one and the panic is due to USB bus controler or its driver code? How do you write anything to a data storage device in such case?

Same goes for ATA bus, which is not *that* trivial to access.

Meanwhile, displaying data is simple: just write bytes at a well-known address within framebuffer addresses range. Simple and highly reliable.

What was not simple and reliable was copying the data displayed that way.

Edited 2012-07-03 09:35 UTC

Relax, would you? It's simply an alternative way to get the information out of the kernel debugger in order to be able to copy it into bug reports. Since most modern systems don't have serial ports any more, it can't be captured that way, and photographs of a computer monitor are large, unwieldy and can be a pain to get focused properly without cutting off important bits of information.

One of Hakiu's goals is to "build the operating system of the future". Something like this is exactly the type of thing that helps fulfill that goal.

Err Event Viewer in Windows or at least a Kernel dump.

It is the 21st century my friend, people have worked out how to write text file to a hardrive.

Edited 2012-07-02 20:46 UTC

And how do you get the text file to the kernel developer???

Remember, the machine doesn't actually work reliably - otherwise it wouldn't be generating kernel panics.

This is so fricken obvious - I can't believe you are still arguing about this...

Yes, I've never seen Windows Event viewer "loose" a critical error message... evar! Same goes for kernel dumps.

You are completely missing the point. The information being displayed is of no use at all to an end user. On Windows you get stop codes - are you saying a stop code conveys useful information to the user? It is a completely meaningless number...

Haiku is not Windows or Linux. The userbase is very small and is under rapid development. Googling stop codes or other such nonsense to try and figure out why something is going wrong (as an end user) is likely to be very hit or miss, mostly miss. The real purpose of the information is to allow a kernel developer to determine what went wrong. That is, btw, the real purpose of the information for Windows too - the fact they you can often look up stop codes on the web and gleam out what is going on from them is due to its popularity - nothing more.

More importantly though, for it to be of any use to anyone it has to be communicated to the developer... How exactly do you get the debug log off the hard-drive of the machine that doesn't work reliably???

The whole point is to make it simple to communicate the information to a developer. It is much cleaner to get an easy to decipher QRCode than it is to try and squint it out of a bad photo of a monitor.

Sure, the stop code approach (which serves roughly the same purpose) works too, but stop codes are just keys to a lookup - the stop code itself means nothing unless you already know where in the code they get hit. Using QR codes you can actually put a fair amount of meaningful information INTO the "stop code".

I suspect Haiku is not far enough along yet to get religious about how they handle kernel panics internally, different subsystems likely dump/panic in different ways (with differing levels of detail). This is a catchall mechanism to deal with the issue of inconsistent error handling.

I would like to see something as consistent as stop codes used for Haiku as well one day, but I think this QR code thing is a lovely idea for the time being. And it will remain useful even if they get to that point (as a way to convey additional information).

It may seem a bit odd but it's not such a bad idea. The Linux kernel developers are presently considering patches that would print a QR code to the screen in case of a panic (and for just the same reasons).

<patent troll mode>
Quick, Haiku guys, let's secure this patent!
</patent troll mode>

Well, at least Haiku will be a prior art of something ;-)

Edited 2012-07-04 07:22 UTC

I think that's an awesome idea... maybe all informational popups etc. should have qrcode.

Not really... this is less of a WTF, and more of a "why hasn't someone thought of that before".

It's exactly the same old behaviour - dumping debug info to the screen on a crash - but it does so in a way that a reliable digital copy can be made (instead of a hand-written transcript, or a blurry photo of the screen). Brilliant.

Yeah, that was my reaction too. It's not much more complicated than the traditional approach of dumping "techie gibberish" to the screen, but it does so in a way that allows that info to be copied off the machine in an error-free manner. It's a brilliant idea.