HDD problems causing Kernel panics in Linux/Debian?
in [Linux Hardware]
|
Prev: Upgraded my old Debian box to Kernel 2.6.32, but missing sensors datas and can't compile the latest stable NVIDIA driver.
Next: Logs and dumps for kernel panics to collect and analyze?
From: Arno on 8 Mar 2010 23:13 In comp.sys.ibm.pc.hardware.storage ANTant(a)zimage.com wrote: >>>> You don't need to, no disk access is possible after a kernel >>>> panic, hence no loging. The only thing you can do, is to >>>> look at the screen or to enable the serial console output and >>>> log that on another machine. >>>> >>>> The reason no disk access is possible is simple: A kernel >>>> panic only hapens when the kernel internal state is regarded >>>> as seriously corrupted. A disk access could then cause serious >>>> filesystem corruption (at least writing) and is therefore >>>> not done. >> >>> So Windows' blue screens with memory dumps are different? >> >> You can get a memory dump under Linux as well by using >> the magic sys-req ley (if compiled in), but you cannto write >> to disk after a panic. It is a safety measure. > How about writing to an USB drive or something else? No. The problem is that a kernel panic is severe and it is unknown which kernel internal structures are corrupted. If any of the filesystem structures are corrupt, you could do arbitrary damage to any accessible filesystem. Unix (and Linux) has far higher data integrity requirements than Windows ever had. You also have to take into account that Unix systems are designed to be long-running, so the chance of the next reboot being a power-failure is actually high. As a consequence Unix filesystems are very robust to just being disconnected at an arbitraty point in time. For that reason not writing anything when a kernel panic happens has a pretty good chance of not causing any filesystem corruption and data corruption only to open files. On the other hand, the serial interface is simple, so console output, including error messages, will still be written to it. If you need that output, connect a different computer to the serial port, activate the serial console and capture its output. I have done this a number of times, mostly to try out experimental kernels on a cluster, but also to debug kernel panics. The kernel options (boot time kernel commandline) for enabling the serial console are (copy&paste from kernel-paramaters.txt): tty<n> Use the virtual console device <n>. ttyS<n>[,options] ttyUSB0[,options] Use the specified serial port. The options are of the form "bbbbpnf", where "bbbb" is the baud rate, "p" is parity ("n", "o", or "e"), "n" is number of bits, and "f" is flow control ("r" for RTS or omit it). Default is "9600n8". See Documentation/serial-console.txt for more information. See Documentation/networking/netconsole.txt for an alternative. uart[8250],io,<addr>[,options] uart[8250],mmio,<addr>[,options] Start an early, polled-mode console on the 8250/16550 UART at the specified I/O port or MMIO address, switching to the matching ttyS device later. The options are the same as for ttyS, above. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno(a)wagner.name GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans
From: Ant on 9 Mar 2010 01:32 On 3/8/2010 8:13 PM PT, Arno typed: > On the other hand, the serial interface is simple, so console > output, including error messages, will still be written to it. > If you need that output, connect a different computer to > the serial port, activate the serial console and capture > its output. I have done this a number of times, mostly to > try out experimental kernels on a cluster, but also to debug > kernel panics. [snipped] Can I use my old serial external dial-up modem for this? -- "... Hey. Could we do that again? I know we haven't met, but I don't want to be an ant. You know? I mean, it's like we go through life with our antennae bouncing off one another, continously on ant autopilot, with nothing really human required of us. 'Stop.' 'Go.' 'Walk here.' 'Drive there.' All action basically for survival. All communication simply to keep this ant colony buzzing along in an efficient, polite manner. 'Here's your change.' 'Paper or plastic?' 'Credit or debit?"' 'You want ketchup with that' I don't want a straw. I want real human moments. I want to see you. I want you to see me. I don't want to give that up. I don't want to be ant, you know?" "Yeah... yeah I know. I don't want to be an ant either. Thanks for kinda, like, josteling me there... I've been kinda on zombie autopilot lately. I don't feel like an ant in my head, but I guess I probably look like one..." --Waking Life movie. /\___/\ / /\ /\ \ Phil./Ant @ http://antfarm.ma.cx (Personal Web Site) | |o o| | Ant's Quality Foraged Links: http://aqfl.net \ _ / Nuke ANT from e-mail address: philpi(a)earthlink.netANT ( ) or ANTant(a)zimage.com Ant is currently not listening to any songs on his home computer.
From: Vlad_Inhaler on 9 Mar 2010 11:12 On Mar 9, 12:52 am, Arno <m...(a)privacy.net> wrote: > In comp.sys.ibm.pc.hardware.storage Ant <a...(a)zimage.comant> wrote: > > > On 3/7/2010 9:20 AM PT, Arno typed: > > >> The reason no disk access is possible is simple: A kernel > >> panic only hapens when the kernel internal state is regarded > >> as seriously corrupted. A disk access could then cause serious > >> filesystem corruption (at least writing) and is therefore > >> not done. > > So Windows' blue screens with memory dumps are different? > > You can get a memory dump under Linux as well by using > the magic sys-req ley (if compiled in), but you cannto write > to disk after a panic. It is a safety measure. > > Arno > -- > Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: a...(a)wagner.name > GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F > ---- > Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans I would have no hesitation in creating a special partition for panic dumps, hell - if standard Linux filesystems are that sensitive I'd even make it VFAT or whatever else is necessary. I have reproducible kernel hangs under a certain kind of load, they are *not* temperature related and I have no way of working out what the hell is going on. Oh, the machine is dual-boot and I don't have these problems under XP. Going further into that here would be hijacking this thread, and I have tried that before now anyway without success. Having some sensible way of taking dumps for further analysis would be a really *good thing* - hell, I'd even put an additional old IDE drive in there as a destination device if that was what it took. Sorry, but that is a 'safety feature' I am not that happy with. Windows can do it, mainframe OSs can do it . . .
From: Rod Speed on 9 Mar 2010 12:07 Ant wrote > Arno wrote >> On the other hand, the serial interface is simple, so console >> output, including error messages, will still be written to it. >> If you need that output, connect a different computer to >> the serial port, activate the serial console and capture >> its output. I have done this a number of times, mostly to >> try out experimental kernels on a cluster, but also to debug >> kernel panics. > Can I use my old serial external dial-up modem for this? Nope, you need a serial cable between the PCs. It would be a lot better if Linux allowed a dump to a USB stick if you are happy to risk the contents of the USB stick on a kernal panic.
From: Arno on 9 Mar 2010 12:47
In comp.sys.ibm.pc.hardware.storage Ant <ant(a)zimage.comant> wrote: > On 3/8/2010 8:13 PM PT, Arno typed: >> On the other hand, the serial interface is simple, so console >> output, including error messages, will still be written to it. >> If you need that output, connect a different computer to >> the serial port, activate the serial console and capture >> its output. I have done this a number of times, mostly to >> try out experimental kernels on a cluster, but also to debug >> kernel panics. > [snipped] > Can I use my old serial external dial-up modem for this? Should be possible. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno(a)wagner.name GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans |