[BUG] 2.6.29-rc2-git1 to -rc5: libata lockup on boot, LED solid, 100% CPU

[BUG] 2.6.29-rc2-git1 to -rc5: libata lockup on boot, LED solid, 100% CPU

[Andreas Mohr]

Hello all,

My Inspiron 8000 ICH2 (i810) P3/700 UP has a hard time booting 2.6.29 things:

[loaded init, shell stuff]
...
ata1.00: configured for UDMA/100
ata1.01: configured for UDMA/33
ata1: EH complete
...
Uniform CD-ROM driver Revision: 3.20
[LAST LINE, FULL STOP]
---> hangs with IDE LED solidly on! <---

NOTE: kernel did NOT hang when accidentally running rc2-git1 w/o any modules loaded!
(IOW, probably a module-related hang)
disabling sr_mod.ko will make a boot proceed a tiny bit, then hang anyway

Could be mutex deadlock (CPU hot, 100%?)
no log errors whatsoever
latest known working: .28-rc6 (admittedly somewhat old; DOES work currently)
earliest known buggy: -rc2-git1, -rc4 also, -rc5 also
no SysRq available (notebook keys: no workey, /proc/sysrq obviously
not available either)

Should I test 2.6.28.5? Every build will take two hours though...
Not ATA-SFF 32bit bug problem, right? (already committed?)
http://marc.info/?l=linux-kernel&m=123254501314058&w=2
CONFIG_LOCK_STAT is NOT set/guilty here http://lkml.org/lkml/2009/2/16/5
Will try disabling CD-ROM drives in BIOS or so.
Any other promising ideas/patches available? libata logging? mutex
logging?

CC'd Tejun since he's been a miracle to work with recently concerning
all things ATA ;)

On a related note, -rc4 works nicely on my Aspire One, despite me
betting that it would end up with at least two new major issues again...
(note: plus full UDMA/66 after resume! - Tejun)
-rc5 on a P4HT blue skies, too...
Maybe kernel quality doesn't actually degrade after all...

Thanks,

Andreas Mohr

Re: [BUG] 2.6.29-rc2-git1 to -rc5: libata lockup on boot, LED solid, 100% CPU

[Mikael Pettersson]

Andreas Mohr writes:
 > Hello all,
 > 
 > My Inspiron 8000 ICH2 (i810) P3/700 UP has a hard time booting 2.6.29 things:
 > 
 > [loaded init, shell stuff]
 > ...
 > ata1.00: configured for UDMA/100
 > ata1.01: configured for UDMA/33
 > ata1: EH complete
 > ...
 > Uniform CD-ROM driver Revision: 3.20
 > [LAST LINE, FULL STOP]
 > ---> hangs with IDE LED solidly on! <---
 > 
 > NOTE: kernel did NOT hang when accidentally running rc2-git1 w/o any modules loaded!
 > (IOW, probably a module-related hang)
 > disabling sr_mod.ko will make a boot proceed a tiny bit, then hang anyway
 > 
 > Could be mutex deadlock (CPU hot, 100%?)
 > no log errors whatsoever
 > latest known working: .28-rc6 (admittedly somewhat old; DOES work currently)
 > earliest known buggy: -rc2-git1, -rc4 also, -rc5 also
 > no SysRq available (notebook keys: no workey, /proc/sysrq obviously
 > not available either)
 > 
 > Should I test 2.6.28.5? Every build will take two hours though...
 > Not ATA-SFF 32bit bug problem, right? (already committed?)
 > http://marc.info/?l=linux-kernel&m=123254501314058&w=2

To me it looks like the 32-bit PIO bug. The patch you cited above was
just the first to identify the issue. This is still unfixed in 29-rc5.
Please test Sergei's latest proposed patch posted yesterday to linux-ide.

Re: [BUG] 2.6.29-rc2-git1 to -rc5: libata lockup on boot, LED solid, 100% CPU

[Andreas Mohr]

<wim@iguana.be>
Bcc: 
Subject: Re: [BUG] 2.6.29-rc2-git1 to -rc5: libata lockup on boot, LED
	solid, 100% CPU
Reply-To: 
In-Reply-To: <18841.54304.460011.351580@harpo.it.uu.se>
X-Priority: none

[CC'd Sergei and Wim; thanks a lot for your work!]

Hi,

On Mon, Feb 16, 2009 at 10:01:20PM +0100, Mikael Pettersson wrote:
> Andreas Mohr writes:
>  > Should I test 2.6.28.5? Every build will take two hours though...
>  > Not ATA-SFF 32bit bug problem, right? (already committed?)
>  > http://marc.info/?l=linux-kernel&m=123254501314058&w=2
> 
> To me it looks like the 32-bit PIO bug. The patch you cited above was
> just the first to identify the issue. This is still unfixed in 29-rc5.
> Please test Sergei's latest proposed patch posted yesterday to linux-ide.

Bingo. That patch ( http://marc.info/?l=linux-ide&m=123482861218381&w=2 )
made -rc5 boot for me. Well, after additionally disabling iTCO_wdt.ko,
that is... (on my Dell Inspiron 8000 i810)

And HDD did seem to be a wee bit more reponsive, too, but that could be
mere illusion...

Thanks,

Andreas Mohr