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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
