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-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
