From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marc Dionne Subject: Re: [git patches] libata updates - (improve post-reset device ready test) regression Date: Wed, 07 May 2008 23:13:56 -0400 Message-ID: <48226FF4.1070103@gmail.com> References: <20080506154847.GA15299@havoc.gtf.org> <20080507145616.GA2210@gentoox2.trippelsdorf.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7BIT Return-path: Received: from relais.videotron.ca ([24.201.245.36]:56535 "EHLO relais.videotron.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753405AbYEHDN5 (ORCPT ); Wed, 7 May 2008 23:13:57 -0400 In-reply-to: Sender: linux-ide-owner@vger.kernel.org List-Id: linux-ide@vger.kernel.org To: Takashi Iwai Cc: Markus Trippelsdorf , Jeff Garzik , Andrew Morton , Linus Torvalds , linux-ide@vger.kernel.org, LKML , htejun@gmail.com 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