![]() | |||||||||||
Messages in this thread Complete thread (EXPERIMENTAL) |
On Fri, 21 Apr 2006, Pavel Machek wrote:
Not sure why it needs time. Waiting for disk to spin up? I don't know, and can't hear, but doubt it (I can't see why it'd need disk spun up just to do an ata_dev_set_xfermode). Will it recover from the timeout?
No, after that wait for 30 seconds, it degenerates into attempting I/O, getting errors, remounting the root readonly, can't get much further. Would sticking ata_set_mode() at the end of timeout routine help?
Well, moving the ata_set_mode after the ata_start_drive does help: then the ata_start_drive times out and fails, but that does not seem to matter at all, and the ata_set_mode then succeeds and all is well. I guess that amounts to what you meant; but all the same, I won't be alone in preferring to wait 2 seconds than 30 seconds! But you've made me try a bit harder, and the patch below, waiting for ATA_BUSY to clear, copying a line used in several other places there, fixes it in a much more satisfactory way than mdelay(2000). (I checked how long it in fact was waiting, saw various waits between 0.8s and 1.3s). This is a patch I'd not be ashamed to send Jeff Garzik cc linux-ide, even if we can't name precisely why it's ATA_BUSY then. But I'll give it a day or so of real-life suspend/resuming first - Arkadiusz and I both noticed we're more likely to resume successfully after a brief suspend, so longer suspends are needed for proper testing. Well this looks like definite progress. Does kind of look like spinning up. + ata_busy_sleep(ap, ATA_TMOUT_BOOT_QUICK, ATA_TMOUT_BOOT);
Huh. That function actually "busy sleeps". How aptly named. -- Mathematics is the supreme nostalgia of our time. | ||||||||||
![]() | |||||||||||
| Last update: 2006-04-21 20:56 [W:0.387 / U:0.030 seconds] ©2003-2005 Jasper Spaans | |||||||||||