linux-kernel - Re: [bug] sata detection problem

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, 12 Feb 2009 00:11:39 +0900
From:	Tejun Heo <htejun@...il.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Alan Cox <alan@...rguk.ukuu.org.uk>, linux-kernel@...r.kernel.org,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [bug] sata detection problem

Hello,

Ingo Molnar wrote:
> Hm, in a boot test i had this boot failure:
> 
> [   15.504053] calling  piix_init+0x0/0x30 @ 1
> [   15.508050] ata_piix 0000:00:1f.1: version 2.12
> [   15.516193] ACPI: PCI Interrupt Link [LNKG] enabled at IRQ 11
> [   15.520029] ata_piix 0000:00:1f.1: PCI INT A -> Link[LNKG] -> GSI 11 (level, low) -> IRQ 11
> [   15.524072] ata_piix 0000:00:1f.1: setting latency timer to 64
> [   15.528115] scsi0 : ata_piix
> [   15.531526] scsi1 : ata_piix
> [   15.544044] ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xffa0 irq 14
> [   15.548028] ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xffa8 irq 15
> [   15.716358] ata1.00: ATAPI: ýVýVýVýVýVýýýýýýýýýýýýýýýýýýýýýýýýýýýýýý, ý.ýVýVýV, max UDMA7
> [   15.720044] ata1.00: limited to UDMA/33 due to 40-wire cable
> [   15.740296] ata1.00: configured for UDMA/33

That's one strange ghost device detection.  Because PATA doesn't have
a reliable way of determining device presence, libata uses combination
of tests along the probing sequence to determine device presence.
Each test is intentionally made somewhat relaxed to avoid missing a
present device (and those condition often do trigger).  It seems
somehow it is passing all the existing tests.  The hardest part
probably is the IDENTIFY command sequence but for SFF controllers it's
done via polling instead of IRQ and thus by having the right (or
wrong) status register value a port with floating pins may be able to
pass it.

How reproducible is the problem?  It can probably be worked around by
making the NODEV_HINT checking a tad bit tighter in SFF host state
machine.  PATA device presence detection is an art not an exact
science.  :-)

Can you please apply the attached patch and report the log after the
problem happens?

Thanks.

-- 
tejun

View attachment "probe-debug.patch" of type "text/x-patch" (2556 bytes)