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 for Android: free password hash cracker in your pocket

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

Message-ID: <20090211152530.GA18660@elte.hu>
Date:	Wed, 11 Feb 2009 16:25:30 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Tejun Heo <htejun@...il.com>
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


* Tejun Heo <htejun@...il.com> wrote:

> 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.  :-)

it's very sporadic - out of thousands of bootups this is the first time :-/

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