2) The Linux kernel should be more careful with these inputs to avoid a kernel panic when it runs on a bad motherboard. At the least, it should give end users a more useful error message than "kernel panic". At the most, it should disable the module if it's not critical, and continue booting up.
From the wikipedia article about kernel panic:
The kernel routines that handle panics (in AT&T-derived and BSD Unix source code, a roThe information provided is of highly technical nature and aims to assist a system administrator or software developer in diagnosing the problem.utine known as panic()) are generally designed to output an error message to the console [...] The information provided is of highly technical nature and aims to assist a system administrator or software developer in diagnosing the problem.
Yes, a kernel panic is like a GPF. However, I don't agree that it should never occur, it was designed for a reason. To fail safely and give an error message when the kernel does not know how to recover from an error in a safe way.
If the kernel knew enough of what was wrong to provide a "useful error message" to the end user it wouldn't have needed to panic in the first place.
So far, I have never seen a kernel panic after the kernel is fully up and running. However, during boot, if the kernel is not fully up yet it probably does not have enough information yet to recover from a hardware bug, and if such a bug were to occur a panic would be perfectly appropriate.
Saying that if the hardware works for other OSs then the kernel should never have a reason to fail on it(after all it should be able to adapt to the quirks just like other do) is stupid as evidenced by TFA since sometimes some bugs are aimed directly at the linux kernel and won't show up on other OSs. Also, emulating windows bugs because hardware manufacturers tailor their hardware to them cannot result in anything good.
Slashdot Mirror
2) The Linux kernel should be more careful with these inputs to avoid a kernel panic when it runs on a bad motherboard. At the least, it should give end users a more useful error message than "kernel panic". At the most, it should disable the module if it's not critical, and continue booting up.
From the wikipedia article about kernel panic:
The kernel routines that handle panics (in AT&T-derived and BSD Unix source code, a roThe information provided is of highly technical nature and aims to assist a system administrator or software developer in diagnosing the problem.utine known as panic()) are generally designed to output an error message to the console [...] The information provided is of highly technical nature and aims to assist a system administrator or software developer in diagnosing the problem.
Yes, a kernel panic is like a GPF. However, I don't agree that it should never occur, it was designed for a reason. To fail safely and give an error message when the kernel does not know how to recover from an error in a safe way. If the kernel knew enough of what was wrong to provide a "useful error message" to the end user it wouldn't have needed to panic in the first place.
So far, I have never seen a kernel panic after the kernel is fully up and running. However, during boot, if the kernel is not fully up yet it probably does not have enough information yet to recover from a hardware bug, and if such a bug were to occur a panic would be perfectly appropriate.
Saying that if the hardware works for other OSs then the kernel should never have a reason to fail on it(after all it should be able to adapt to the quirks just like other do) is stupid as evidenced by TFA since sometimes some bugs are aimed directly at the linux kernel and won't show up on other OSs. Also, emulating windows bugs because hardware manufacturers tailor their hardware to them cannot result in anything good.