[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <48226FF4.1070103@gmail.com>
Date: Wed, 07 May 2008 23:13:56 -0400
From: Marc Dionne <marc.c.dionne@...il.com>
To: Takashi Iwai <tiwai@...e.de>
Cc: Markus Trippelsdorf <markus@...ppelsdorf.de>,
Jeff Garzik <jeff@...zik.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
linux-ide@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
htejun@...il.com
Subject: Re: [git patches] libata updates - (improve post-reset device ready
test) regression
07/05/08 12:35 PM, Takashi Iwai:
>
> The same problem appears on my machine, too:
>
> libata version 3.00 loaded.
> ata_piix 0000:00:1f.2: version 2.12
> ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19 (level, low) -> IRQ 19
> ata_piix 0000:00:1f.2: MAP [ P0 P2 P1 P3 ]
> PCI: Setting latency timer of device 0000:00:1f.2 to 64
> scsi0 : ata_piix
> scsi1 : ata_piix
> ata1: SATA max UDMA/133 cmd 0xe400 ctl 0xe500 bmdma 0xe800 irq 19
> ata2: SATA max UDMA/133 cmd 0xe600 ctl 0xe700 bmdma 0xe808 irq 19
> ata1.00: ATA-7: HDS728080PLA380, PF2OA60A, max UDMA/133
> ata1.00: 160836480 sectors, multi 16: LBA48 NCQ (depth 0/32)
> ata1.00: configured for UDMA/133
> ata2: link is slow to respond, please be patient (ready=0)
> ata2: device not ready (errno=-16), forcing hardreset
> ata2: link is slow to respond, please be patient (ready=0)
> ata2: SRST failed (errno=-16)
> ata2: link is slow to respond, please be patient (ready=0)
> ata2: SRST failed (errno=-16)
> ata2: link is slow to respond, please be patient (ready=0)
> ata2: SRST failed (errno=-16)
> ata2: SRST failed (errno=-16)
> ata2: reset failed, giving up
>
>
> Takashi
Same here as well, with sata_nv.
The patch comment states:
> This patch implements ata_check_ready(), which takes TF status value
> and determines whether the port is ready or not considering the above
> and other conditions, and use it in @check_ready() functions. This is
> safe as both 0x77 and 0x7f aren't valid ready status value even though
> they have BSY bit cleared.
.. but adding a print to the ata_check_ready function shows the status in my
case is systematically 0x7f for all unconnected links. This makes
ata_*_check_ready return 0 where it previously returned 1, and triggers several
hundred retries (over several minutes) before the boot proceeds.
Marc
--
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