linux-kernel - Regression: libata: implement ata_wait_after

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>] [day] [month] [year] [list]

Date:	Sat, 3 Nov 2007 18:13:10 +0100
From:	Luca Tettamanti <kronos.it@...il.com>
To:	Tejun Heo <htejun@...il.com>, Jeff Garzik <jeff@...zik.org>
Cc:	linux-kernel@...r.kernel.org
Subject: Regression: libata: implement ata_wait_after_reset()

Hi,
latest git causes my extra disk controller to die with screaming
interrupts. Picture here:

http://img113.imageshack.us/my.php?image=im000708vj7.jpg

The controller card is this one (SATA port is not in use):

05:02.0 Mass storage controller: ALi Corporation ALi M5281 Serial ATA / RAID Host Controller (rev a4) (prog-if 85)
        Subsystem: ALi Corporation ALi M5281 Serial ATA / RAID Host Controller
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 128, Cache Line Size: 512 bytes
        Interrupt: pin A routed to IRQ 19
        Region 0: I/O ports at c000 [size=8]
        Region 1: I/O ports at bc00 [size=4]
        Region 2: I/O ports at b880 [size=8]
        Region 3: I/O ports at b800 [size=4]
        Region 4: I/O ports at b480 [size=16]
        Expansion ROM at ff7f0000 [disabled] [size=64K]

05:02.1 Mass storage controller: ALi Corporation M5228 ALi ATA/RAID Controller (rev c6) (prog-if 85)
        Subsystem: ALi Corporation Unknown device 5281
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 128
        Interrupt: pin A routed to IRQ 19
        Region 0: I/O ports at c880 [size=8]
        Region 1: I/O ports at c800 [size=4]
        Region 2: I/O ports at c480 [size=8]
        Region 3: I/O ports at c400 [size=4]
        Region 4: I/O ports at c080 [size=16]

The driver is pata_ali. I bisected it down to:

kronos:~/src/linux-2.6.git$ git bisect bad
88ff6eafbb2a1c55f0f0e2e16d72e7b10d8ae8a5 is first bad commit
commit 88ff6eafbb2a1c55f0f0e2e16d72e7b10d8ae8a5
Author: Tejun Heo <htejun@...il.com>
Date:   Tue Oct 16 14:21:24 2007 -0700

    libata: implement ata_wait_after_reset()

    On certain device/controller combination, 0xff status is asserted
    after reset and doesn't get cleared during 150ms post-reset wait.  As
    0xff status is interpreted as no device (for good reasons), this can
    lead to misdetection on such cases.

    This patch implements ata_wait_after_reset() which replaces the 150ms
    sleep and waits upto ATA_TMOUT_FF_WAIT if status is 0xff.
    ATA_TMOUT_FF_WAIT is currently 800ms which is enough for
    HHD424020F7SV00 to get detected but not enough for Quantum GoVault
    drive which is known to take upto 2s.

    Without parallel probing, spending 2s on 0xff port would incur too
    much delay on ata_piix's which use 0xff to indicate empty port and
    doesn't have SCR register, so GoVault needs to wait till parallel
    probing.

    Signed-off-by: Tejun Heo <htejun@...il.com>
    Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
    Signed-off-by: Jeff Garzik <jeff@...zik.org>

:040000 040000 44a0d6b9b2b0e7d4721c013d90a7ccd9656dcd2c 8587bfcf26176f1286bfab26cd6d150712dfd5f8 M      drivers
:040000 040000 2775bec0948fd2306c750b3a215f449c8b3d13ba 8c0fdbb87154af8fc804918a29e72060a2c6939c M      include

I can set up a serial console if you need further debug output.

Luca
-- 
Non sempre quello che viene dopo e` progresso.
Alessandro Manzoni
-
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/