linux-kernel - Re: [PATCH] Re: [git patches] libata updates - (improve post-reset device ready test) regression

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]

Message-ID: <dd18b0c30805082043x39a58680nb36960e464c80936@mail.gmail.com>
Date:	Fri, 9 May 2008 03:43:27 +0000
From:	"Justin Mattock" <justinmattock@...il.com>
To:	"Tejun Heo" <htejun@...il.com>
Cc:	"Jeff Garzik" <jeff@...zik.org>,
	"Markus Trippelsdorf" <markus@...ppelsdorf.de>,
	linux-ide@...r.kernel.org,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Linus Torvalds" <torvalds@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	"Takashi Iwai" <tiwai@...e.de>, marc.c.dionne@...il.com,
	dl9pf@....de, bug-track@...her-privat.net, sitsofe@...oo.com
Subject: Re: [PATCH] Re: [git patches] libata updates - (improve post-reset device ready test) regression

On Fri, May 9, 2008 at 2:57 AM, Tejun Heo <htejun@...il.com> wrote:
> Jeff Garzik wrote:
>>
>> Markus Trippelsdorf wrote:
>>>>
>>>> Tejun Heo (12):
>>>>      libata: improve post-reset device ready test
>>>
>>> This commit (78ab88f04f44bed566d51dce0c7cbfeff6449a06) causes a long
>>> boot delay with my onboard Promise controller. It seems like libata
>>> probes for a nonexisting PATA drive...
>>>
>>> ACPI: PCI Interrupt 0000:00:08.0[A] -> GSI 18 (level, low) -> IRQ 18
>>> scsi0 : sata_promise
>>> scsi1 : sata_promise
>>> scsi2 : sata_promise
>>> ata1: SATA max UDMA/133 mmio m4096@...b600000 port 0xfb600200 irq 18
>>> ata2: SATA max UDMA/133 mmio m4096@...b600000 port 0xfb600280 irq 18
>>> ata3: PATA max UDMA/133 mmio m4096@...b600000 port 0xfb600300 irq 18
>>> ata1: SATA link down (SStatus 0 SControl 300)
>>> ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>>> ata2.00: ATA-7: SAMSUNG HD753LJ, 1AA01109, max UDMA7
>>> ata2.00: 1465149168 sectors, multi 0: LBA48 NCQ (depth 0/32)
>>> ata2.00: configured for UDMA/133
>>>                                                  ata3: link is slow to
>>> respond, please be patient (ready=0)
>>> ata3: device not ready (errno=-16), forcing hardreset
>>> ata3: link is slow to respond, please be patient (ready=0)
>>> ata3: SRST failed (errno=-16)
>>> ata3: link is slow to respond, please be patient (ready=0)
>>> ata3: SRST failed (errno=-16)
>>> ata3: link is slow to respond, please be patient (ready=0)
>>> ata3: SRST failed (errno=-16)
>>>  - Last output repeated twice -
>>> ata3: reset failed, giving up
>>
>> Does the attached patch fix things?
>>
>> It basically reverts the patch, while still maintaining the consolidation.
>>  It looks like that status evaluation is not as universal as believed.
>
> This means that we need to make custom readiness tests for controllers using
> 0x77 or 0x7f.  Eeeek... Both groups of controllers are behaving in incorrect
> way.  Controllers shouldn't use 0x77 or 0x7f for either busy or ready states
> - it's invalid for both, yet, some use the 77/7f for busy while others use
> them for ready state.  Great.  :-(
>
> Jeff, can you please revert 78ab88f04f44bed566d51dce0c7cbfeff6449a06 for
> now?  I'll post updated patch.
>
> Markus, Alexey, Marc, which controllers are you using?
>
> 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/
>

Hello; Im getting that same message here as well, If you have the
patch I'll give it a try to see if it works.
regards;

-- 
Justin P. Mattock
--
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/