linux-kernel - Re: 2.6.23-rc7-mm1 AHCI ATA errors -- won't boot

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 27 Sep 2007 10:05:23 +0900
From:	Tejun Heo <htejun@...il.com>
To:	"Berck E. Nash" <flyboy@...il.com>
CC:	Bernd Schmidt <bernds_cb1@...nline.de>,
	Jeff Garzik <jeff@...zik.org>,
	"linux-ide@...r.kernel.org" <linux-ide@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: 2.6.23-rc7-mm1 AHCI ATA errors -- won't boot

Berck E. Nash wrote:
> Bernd Schmidt wrote:
>> One of these appears in my system as well (ASUS P5W-DH Deluxe
>> mainboard).  Here's the hdparm output:
> 
> Yup, same mainboard here.
> 
>> Since about 2.6.17 or 2.6.18, it has been causing long delays while
>> booting:
>> ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
>> ata2.00: qc timeout (cmd 0xec)
>> ata2.00: failed to IDENTIFY (I/O error, err_mask=0x5)
>> ata2: port is slow to respond, please be patient (Status 0x80)
>> ata2: COMRESET failed (errno=-16)
>> ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
>> ata2.00: ATA-6: Config  Disk, RGL10364, max UDMA/133
>> ata2.00: 640 sectors, multi 1: LBA
>> ata2.00: configured for UDMA/133
> 
> And yup, same problem with the painful boot delays since 2.6.18.  Tejun
> indicated that a fix would get merged with 2.6.23, but that didn't
> happen.  Here's hoping something makes it into .24!

Yeah, it is the sil4726 virtual device which is really crappy as an ATA
device.  About the fix, I thought PMP support would fix it but the
controller on P5W-DH doesn't support PMP.  It can only talk to the
virtual device or the device attached to the first port depending on how
the PMP chip is configured.  It seems we'll have to blacklist the
mainboard and skip or use modified reset sequence on the affected port,
so that's why the fix was delayed.  I'm currently on the road but I'll
look into it when I get back (next week).

Thanks.

-- 
tejun

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