| 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
| ||
|
Message-ID: <web-515901951@zbackend1.aha.ru> Date: Sat, 30 Apr 2011 00:13:24 -0400 From: "werner" <w.landgraf@...ru> To: Linus Torvalds <torvalds@...ux-foundation.org>, linux-kernel@...r.kernel.org Subject: Re: 2.6.39-rc5-git2 boot crashs The problem that the computer crashs if zip, unzip or move a big file, started with -rc1 The problem with the secondary reset-resistent crashs after a primary and-of-boot or after-boot crash started with -rc3 or -rc4, at least I perceived it then, but it's possible that it occured also before, at least then I didn't note it Now I see, that nor the syslog don't contain everything (this was also better with 2.6.38.4). For example, currently aren't logged these crashs which currently occure during rtc0 initializing (in addition to the other crashs protocolled in the log files). Also, as you can see from my before-last message, with the screen foto of /dev/pts/0 w.r.t. boot_vga, this also don't appear in the log file which was added at the end of the same message. For being -rc5 , that kernel is rather bad. I hope you get through to correct it until -rc10 W.Landgraf ========================================================= On Fri, 29 Apr 2011 21:00:24 -0700 Linus Torvalds <torvalds@...ux-foundation.org> wrote: > On Fri, Apr 29, 2011 at 8:39 PM, werner ><w.landgraf@...ru> wrote: >> >> At my reclamation thread about 2.6.39-rc3,4 crashs, I >>informed that there >> was a reset-resistent change of the system after crashs, >>so that on >> subsequent boots (after a 'primary' crash rather at the >>end of booting) it >> happened an early 'secondary' crash at the time of >>initializing ata0, with >> funny effects like that the grafic card (or anything >>else) was identified as >> an ata device, with subsequent 'read erros' on it and >>crash. This >> 'secondary' effect repeated and repeated and gone away >>only at booting with >> a normal kernel (2.6.38.4 or 2.6.26.2). But if >>afterwards booting again with >> 2.6.39-rc3 or -rc4 , then at the end of the boot it >>crashed, and at >> subsequent boots again continued this reset-resistent >>effect that it crasha >> again and again with ata0 problems, until I reboot with >>2.6.38.4 or 2.6.26.2 >> , or waiting 5 minutes (perhaps until the memory >>discharged). >> >> All these problems dont happen with 2.6.38.4 or 2.6.26.2 > > Do you think you could bisect when that odd after-reset >behavior started? > > It does sound like you have some PCI-level problem (some >device that > has "sticky" state and doesn't get reset properly). Most >likely a > hardware "feature" (there is various PCI hardware that >allows things > like device identifiers to be written to), coupled with >a firmware bug > that doesn't reset things. > > But it would be intriguing to hear when it started >happening, so that > we can figure out exactly _what_ isn't getting properly >reset.. > > The logfs oops may just be a result of "autodetect any >random > filesystem" in that confused state. So when the state >isn't confused, > you'd not see the oops, because nothing ever tries to >mount the > invalid logfs image. > > Linus > > "werner" <w.landgraf@...ru> --- Professional hosting for everyone - http://www.host.ru -- 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