Re: 2.6.39-rc5-git2 boot crashs

[werner]

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@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Fri, Apr 29, 2011 at 8:39 PM, werner 
> <w.landgraf@xxxxx> 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@xxxxx>
---
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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/