| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Tue, 20 Mar 2007 20:19:11 +1100 From: Paul Mackerras <paulus@...ba.org> To: David Miller <davem@...emloft.net> Cc: jesse.barnes@...el.com, zaitcev@...hat.com, jg@...top.org, linux-kernel@...r.kernel.org Subject: Re: BSOD David Miller writes: > Mode setting is complex and it is not going to work exactly when you > need the kernel crash message the most. It's a matter of writing maybe a dozen MMIO registers on the ATI chips, for instance, with some delays. Provided we have interrupts disabled and udelay still works, there's not a lot of the kernel that we need to rely on to do that. > After debugging the kernel for 10+ years I can tell you one thing, for > a bad crash what's going to happen is you'll get the printk but that's > about all that will work at that point, and the kernel is going to > hang next. Sometimes you won't get the whole panic message, just > the beginning, even with the most simplistic printk implementation. > > You will not, I repeat, will not be able to mode switch or anything > non-trivial like that when the kernel is in this state. > > Mode switching on panic, just say no. :-) Anything is better than nothing. At the moment we get nothing if you are in X when the panic occurs, even for the nicest, most well-behaved panics. :) If we can change that to getting something sometimes, that's a win. Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists