linux-kernel - Re: [PATCH] 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <1800.81.207.0.53.1179590050.squirrel@secure.samage.net>
Date:	Sat, 19 May 2007 17:54:10 +0200 (CEST)
From:	"Indan Zupancic" <indan@....nu>
To:	"Tejun Heo" <htejun@...il.com>
Cc:	"Paul Mundt" <lethal@...ux-sh.org>, "Tejun Heo" <htejun@...il.com>,
	jeff@...zik.org, linux-ide@...r.kernel.org,
	linux-kernel@...r.kernel.org, garyhade@...ibm.com
Subject: Re: [PATCH] libata: implement ata_wait_after_reset()

On Wed, May 16, 2007 18:44, Tejun Heo wrote:
> 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.

Using sata_sil (SiI 3512) with a ST3120827AS disk here.

For me the COMRESET happens after resume (s2ram):

[    2.174342] sd 0:0:0:0: [sda] Starting disk
[    2.476407] ata1: device not ready (errno=-19), forcing hardreset
[    2.476429] ata2: SATA link down (SStatus 0 SControl 310)
[    2.931793] ata1: COMRESET failed (errno=-19)
[    2.931797] ata1: reset failed (errno=-19), retrying in 10 secs
[   12.918421] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[   12.921957] ata1.00: ata_hpa_resize 1: sectors = 234441648, hpa_sectors = 234441648
[   12.925908] ata1.00: ata_hpa_resize 1: sectors = 234441648, hpa_sectors = 234441648

With your patch applied the output is:

[    2.173369] sd 0:0:0:0: [sda] Starting disk
[    2.475431] ata1: device not ready (errno=-19), forcing hardreset
[    2.475453] ata2: SATA link down (SStatus 0 SControl 310)
[    3.592930] ata1: COMRESET failed (errno=-19)
[    3.592934] ata1: reset failed (errno=-19), retrying in 9 secs
[   12.917446] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[   12.920969] ata1.00: ata_hpa_resize 1: sectors = 234441648, hpa_sectors = 234441648
[   12.924945] ata1.00: ata_hpa_resize 1: sectors = 234441648, hpa_sectors = 234441648

Resume takes now ten seconds or more, while it used to take only a few seconds,
what changed? A few kernel versions ago (2.6.21-rc or so?) it retried in 5 seconds
instead of 10, but even that is too long.

Maybe a silly question, but why do we wait for the harddisk to show up? Maybe that
makes a little bit of sense at bootup, but for resume from ram, where nothing is
supposed to have changed, it seems a bit strange. Why not wait when something tries
to access the harddisk or something?

I wonder if sil_pci_device_resume() and sd_resume() know about each other...
I'll disable sd_resume() and see how that goes.

Greetings,

Indan


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