Re: rc5 seemed to kill a disk that rc4-mm1 likes. Also some X trouble.

[Helge Hafting]

Danny ter Haar wrote:

> Andrew Morton  <akpm@xxxxxxxx> wrote:
>  
>
> > Helge Hafting <helgehaf@xxxxxxxxxxxxx> wrote:
> >    
> >
> > > 2.6.13-rc5 seemed to kill a scsi disk (sdb) for me, where 2.6.13-rc4-mm1
> > > have no problems with the same disk.
> > >      
>
> Sort of same with me:
> 2.6.12-mm1 runs for _weeks_ where others keep crashing:
>
>  
>
> > The latest -git kernel (or 2.6.13-rc6 if it's there) with APCI enabled is
> > the one to test, please.
> >    
>
> no rc6 yet, i did however experience the following:
>
> reboot   system boot  2.6.12-mm1       Sun Aug  7 18:20          (00:36)
> dth      pts/1        zaphod.dth.net   Sun Aug  7 15:41 - crash  (02:38)
> reboot   system boot  2.6.13-rc5-git5  Sun Aug  7 14:04          (04:52)
> reboot   system boot  2.6.13-rc5-git4  Sun Aug  7 10:05          (03:43)
> reboot   system boot  2.6.13-rc5-git3  Fri Aug  5 16:55         (1+17:07)
>
> git3 lasted near 2 days
> git4 ran for nearly 5 hours than i upgraded to
> git5 didn't last longer than 2.5 hours
>
> Fortunatly some info was found in the log files.
> What i dont "get" is that ethernet also goes down when the scsi
> controller goes bezerk.
> I'm pretty sure it's not a hardware problem since 2.6.12-mm1 survives
> and brings this usenet host in the worldwide top 1000.
>  
Interesting. 
I have no idea what the core problem is, but one problem will often lead
to others.  My scsi problem froze some apps that couldn't be paged in
from the "failing" disk, for example.

Something going wrong in the kernel can delay other devices for too long,
maybe your network driver was hit by nasty latency in the middle of 
something
as the scsi controller reset itself.  It may also be memory scribbling.

I sometimes gets x lockups with rc5.  Sometimes they just lock one display,
sometimes the whole machine locks solid necessitating a reset. sysrq+B
did not work, on either keyboard.

rc5 is no good for amd64, and it doesn't need power management to go wrong.

Helge Hafting
-
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/