Re: sd_resume redundant? [was: [PATCH] libata: implement ata_wait_after_reset()]
Randy Dunlap wrote: On Sun, 20 May 2007 11:45:03 -0600 Robert Hancock wrote: Indan Zupancic wrote: Everything seems to work fine without sd_resume(), so why is it needed? Because not all disks spin up without being told to do so and like it or not spinning disks up on resume is the default behavior. As I wrote in the other reply, it would be worthwhile to make it configurable. Not even after they receive a read command? Ugh. ATA disks are supposed to spin up, yes. SCSI disks require a command to tell them to spin up if they're in the "stopped" state. Good info, but linux-ide was dropped. Is that due to lack of reply-to-all or is it a newsgroup thing or what? That would be a newsgroup thing. It seems that sometimes CCs get dropped when the posts are forwarded to fa.linux.kernel where I normally read them. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - 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/
Re: sd_resume redundant? [was: [PATCH] libata: implement ata_wait_after_reset()]
On Sun, May 20, 2007 19:17, Tejun Heo wrote: > Indan Zupancic wrote: >> So over all it takes half a second longer to detect the disk, but >> because everything waits on it, it takes more than three seconds >> longer to resume. > > Eeeek. Extra three secs doesn't sound too hot. :-( Hey, without your reset fix it was 11 seconds slower. ;-) Well, it used to be around 1.7 seconds to resume, and now (after the fixes) it's 2.8 (according to the dmesg timestamps). But the first timestamp printed was 0.7, and now it's 2.1, so I don't know if it's a real slowdown or that the timer is set correctly earlier. That was with 2.19 btw, I don't know what happened in the meantime. I suspect the timer changes. To know for sure I'd need to boot an older kernel and measure resume time with a stopwatch. >> Setting manage_start_stop to 0 fixes it and is good enough for me, I >> didn't notice anything bad yet because of the unmanaged >> stop. Implementing background spin up will fix it too. > > Just commenting out sd_resume() would be a better solution for your > case tho. I like your idea below more. ;-) Everything seems to work fine without sd_resume(), so why is it needed? >>> Because not all disks spin up without being told to do so and like it or >>> not spinning disks up on resume is the default behavior. As I wrote in >>> the other reply, it would be worthwhile to make it configurable. >> >> Not even after they receive a read command? Ugh. > > After receiving a command which requires media access, they do. What > I was saying is that the current default behavior is to spin up all > devices on resume and part of that is achieved by sd_resume(). > > Hmmm... skipping START_STOP during sd_resume() actually is a pretty > good solution for ATA devices. I'll think about it. I can't speak for others, but for me this would fix all regressions and even disk spin up seems half a second faster without the START_STOP. It would also solve the laptopmode thing, not unnecessarily spinning up disks that don't need to be (if the hardware doesn't do it). 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/
Re: sd_resume redundant? [was: [PATCH] libata: implement ata_wait_after_reset()]
On Sun, 20 May 2007 11:45:03 -0600 Robert Hancock wrote: > Indan Zupancic wrote: > >>> Everything seems to work fine without sd_resume(), so why is it needed? > >> Because not all disks spin up without being told to do so and like it or > >> not spinning disks up on resume is the default behavior. As I wrote in > >> the other reply, it would be worthwhile to make it configurable. > > > > Not even after they receive a read command? Ugh. > > ATA disks are supposed to spin up, yes. SCSI disks require a command to > tell them to spin up if they're in the "stopped" state. Good info, but linux-ide was dropped. Is that due to lack of reply-to-all or is it a newsgroup thing or what? --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - 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/
Re: sd_resume redundant? [was: [PATCH] libata: implement ata_wait_after_reset()]
Indan Zupancic wrote: Everything seems to work fine without sd_resume(), so why is it needed? Because not all disks spin up without being told to do so and like it or not spinning disks up on resume is the default behavior. As I wrote in the other reply, it would be worthwhile to make it configurable. Not even after they receive a read command? Ugh. ATA disks are supposed to spin up, yes. SCSI disks require a command to tell them to spin up if they're in the "stopped" state. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - 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/
Re: sd_resume redundant? [was: [PATCH] libata: implement ata_wait_after_reset()]
Indan Zupancic wrote: >> Can you try to measure with sd_resume in place? > > [2.173366] sd 0:0:0:0: [sda] Starting disk > [2.475422] ata2: SATA link down (SStatus 0 SControl 310) > [5.478403] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310) > [5.481928] ata1.00: ata_hpa_resize 1: sectors = 234441648, hpa_sectors = > 234441648 > [5.485904] ata1.00: ata_hpa_resize 1: sectors = 234441648, hpa_sectors = > 234441648 > [5.485913] ata1.00: configured for UDMA/100 > [5.505109] sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors (120034 > MB) > [5.505461] sd 0:0:0:0: [sda] Write Protect is off > [5.505465] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 > [5.505612] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, > doesn't support DPO or > FUA > ... > [6.157259] Restarting tasks ... done. > > > And with echo 0 > /sys/class/scsi_disk/0\:0\:0\:0/manage_start_stop: > > [2.476476] ata2: SATA link down (SStatus 0 SControl 310) > ... > [2.825479] Restarting tasks ... done. > ... > [5.022076] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310) > [5.025605] ata1.00: ata_hpa_resize 1: sectors = 234441648, hpa_sectors = > 234441648 > [5.028594] ata1.00: ata_hpa_resize 1: sectors = 234441648, hpa_sectors = > 234441648 > [5.028606] ata1.00: configured for UDMA/100 > [5.028720] sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors (120034 > MB) > [5.028767] sd 0:0:0:0: [sda] Write Protect is off > [5.028773] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 > [5.028831] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, > doesn't support DPO or > FUA > > So over all it takes half a second longer to detect the disk, but > because everything waits on it, it takes more than three seconds > longer to resume. Eeeek. Extra three secs doesn't sound too hot. :-( > Setting manage_start_stop to 0 fixes it and is good enough for me, I > didn't notice anything bad yet because of the unmanaged > stop. Implementing background spin up will fix it too. Just commenting out sd_resume() would be a better solution for your case tho. >>> Everything seems to work fine without sd_resume(), so why is it needed? >> Because not all disks spin up without being told to do so and like it or >> not spinning disks up on resume is the default behavior. As I wrote in >> the other reply, it would be worthwhile to make it configurable. > > Not even after they receive a read command? Ugh. After receiving a command which requires media access, they do. What I was saying is that the current default behavior is to spin up all devices on resume and part of that is achieved by sd_resume(). Hmmm... skipping START_STOP during sd_resume() actually is a pretty good solution for ATA devices. I'll think about it. Thanks. -- tejun - 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/
Re: sd_resume redundant? [was: [PATCH] libata: implement ata_wait_after_reset()]
On Sun, May 20, 2007 11:54, Tejun Heo wrote: > Indan Zupancic wrote: >> On Sat, May 19, 2007 21:04, Tejun Heo wrote: >>> Tejun Heo wrote: Yeah, if SCR registers are accessible, 0xff doesn't indicate the device isn't there, so the whole skip-0xff logic probably shouldn't apply in such cases, but we can also achieve pretty good result by just making the first reset tries a bit more aggressive. >>> So, here's the patch. >>> >>> Paul, can you please test this patch without the previous patch? Indan, >>> this should reduce the resume delay. Please test. But you'll still >>> feel some added delay compared to 2.6.20 due to the mentioned >>> suspend/resume change. >> >> This removed the COMRESET errors indeed, and with sd_resume() >> disabled everything is speedy again (2s or so. Still a desktop pc). >> I didn't try with sd_resume enabled. > > Can you try to measure with sd_resume in place? [2.173366] sd 0:0:0:0: [sda] Starting disk [2.475422] ata2: SATA link down (SStatus 0 SControl 310) [5.478403] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310) [5.481928] ata1.00: ata_hpa_resize 1: sectors = 234441648, hpa_sectors = 234441648 [5.485904] ata1.00: ata_hpa_resize 1: sectors = 234441648, hpa_sectors = 234441648 [5.485913] ata1.00: configured for UDMA/100 [5.505109] sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors (120034 MB) [5.505461] sd 0:0:0:0: [sda] Write Protect is off [5.505465] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [5.505612] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA ... [6.157259] Restarting tasks ... done. And with echo 0 > /sys/class/scsi_disk/0\:0\:0\:0/manage_start_stop: [2.476476] ata2: SATA link down (SStatus 0 SControl 310) ... [2.825479] Restarting tasks ... done. ... [5.022076] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310) [5.025605] ata1.00: ata_hpa_resize 1: sectors = 234441648, hpa_sectors = 234441648 [5.028594] ata1.00: ata_hpa_resize 1: sectors = 234441648, hpa_sectors = 234441648 [5.028606] ata1.00: configured for UDMA/100 [5.028720] sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors (120034 MB) [5.028767] sd 0:0:0:0: [sda] Write Protect is off [5.028773] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [5.028831] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA So over all it takes half a second longer to detect the disk, but because everything waits on it, it takes more than three seconds longer to resume. Setting manage_start_stop to 0 fixes it and is good enough for me, I didn't notice anything bad yet because of the unmanaged stop. Implementing background spin up will fix it too. >> Everything seems to work fine without sd_resume(), so why is it needed? > > Because not all disks spin up without being told to do so and like it or > not spinning disks up on resume is the default behavior. As I wrote in > the other reply, it would be worthwhile to make it configurable. Not even after they receive a read command? Ugh. Greeting, 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/
Re: sd_resume redundant? [was: [PATCH] libata: implement ata_wait_after_reset()]
Indan Zupancic wrote: > On Sat, May 19, 2007 21:04, Tejun Heo wrote: >> Tejun Heo wrote: >>> Yeah, if SCR registers are accessible, 0xff doesn't indicate the device >>> isn't there, so the whole skip-0xff logic probably shouldn't apply in >>> such cases, but we can also achieve pretty good result by just making >>> the first reset tries a bit more aggressive. >> So, here's the patch. >> >> Paul, can you please test this patch without the previous patch? Indan, >> this should reduce the resume delay. Please test. But you'll still >> feel some added delay compared to 2.6.20 due to the mentioned >> suspend/resume change. > > This removed the COMRESET errors indeed, and with sd_resume() > disabled everything is speedy again (2s or so. Still a desktop pc). > I didn't try with sd_resume enabled. Can you try to measure with sd_resume in place? > Everything seems to work fine without sd_resume(), so why is it needed? Because not all disks spin up without being told to do so and like it or not spinning disks up on resume is the default behavior. As I wrote in the other reply, it would be worthwhile to make it configurable. -- tejun - 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/
Re: sd_resume redundant? [was: [PATCH] libata: implement ata_wait_after_reset()]
Indan Zupancic wrote: On Sat, May 19, 2007 21:04, Tejun Heo wrote: Tejun Heo wrote: Yeah, if SCR registers are accessible, 0xff doesn't indicate the device isn't there, so the whole skip-0xff logic probably shouldn't apply in such cases, but we can also achieve pretty good result by just making the first reset tries a bit more aggressive. So, here's the patch. Paul, can you please test this patch without the previous patch? Indan, this should reduce the resume delay. Please test. But you'll still feel some added delay compared to 2.6.20 due to the mentioned suspend/resume change. This removed the COMRESET errors indeed, and with sd_resume() disabled everything is speedy again (2s or so. Still a desktop pc). I didn't try with sd_resume enabled. Can you try to measure with sd_resume in place? Everything seems to work fine without sd_resume(), so why is it needed? Because not all disks spin up without being told to do so and like it or not spinning disks up on resume is the default behavior. As I wrote in the other reply, it would be worthwhile to make it configurable. -- tejun - 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/
Re: sd_resume redundant? [was: [PATCH] libata: implement ata_wait_after_reset()]
On Sun, May 20, 2007 11:54, Tejun Heo wrote: Indan Zupancic wrote: On Sat, May 19, 2007 21:04, Tejun Heo wrote: Tejun Heo wrote: Yeah, if SCR registers are accessible, 0xff doesn't indicate the device isn't there, so the whole skip-0xff logic probably shouldn't apply in such cases, but we can also achieve pretty good result by just making the first reset tries a bit more aggressive. So, here's the patch. Paul, can you please test this patch without the previous patch? Indan, this should reduce the resume delay. Please test. But you'll still feel some added delay compared to 2.6.20 due to the mentioned suspend/resume change. This removed the COMRESET errors indeed, and with sd_resume() disabled everything is speedy again (2s or so. Still a desktop pc). I didn't try with sd_resume enabled. Can you try to measure with sd_resume in place? [2.173366] sd 0:0:0:0: [sda] Starting disk [2.475422] ata2: SATA link down (SStatus 0 SControl 310) [5.478403] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310) [5.481928] ata1.00: ata_hpa_resize 1: sectors = 234441648, hpa_sectors = 234441648 [5.485904] ata1.00: ata_hpa_resize 1: sectors = 234441648, hpa_sectors = 234441648 [5.485913] ata1.00: configured for UDMA/100 [5.505109] sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors (120034 MB) [5.505461] sd 0:0:0:0: [sda] Write Protect is off [5.505465] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [5.505612] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA ... [6.157259] Restarting tasks ... done. And with echo 0 /sys/class/scsi_disk/0\:0\:0\:0/manage_start_stop: [2.476476] ata2: SATA link down (SStatus 0 SControl 310) ... [2.825479] Restarting tasks ... done. ... [5.022076] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310) [5.025605] ata1.00: ata_hpa_resize 1: sectors = 234441648, hpa_sectors = 234441648 [5.028594] ata1.00: ata_hpa_resize 1: sectors = 234441648, hpa_sectors = 234441648 [5.028606] ata1.00: configured for UDMA/100 [5.028720] sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors (120034 MB) [5.028767] sd 0:0:0:0: [sda] Write Protect is off [5.028773] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [5.028831] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA So over all it takes half a second longer to detect the disk, but because everything waits on it, it takes more than three seconds longer to resume. Setting manage_start_stop to 0 fixes it and is good enough for me, I didn't notice anything bad yet because of the unmanaged stop. Implementing background spin up will fix it too. Everything seems to work fine without sd_resume(), so why is it needed? Because not all disks spin up without being told to do so and like it or not spinning disks up on resume is the default behavior. As I wrote in the other reply, it would be worthwhile to make it configurable. Not even after they receive a read command? Ugh. Greeting, 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/
Re: sd_resume redundant? [was: [PATCH] libata: implement ata_wait_after_reset()]
Indan Zupancic wrote: Can you try to measure with sd_resume in place? [2.173366] sd 0:0:0:0: [sda] Starting disk [2.475422] ata2: SATA link down (SStatus 0 SControl 310) [5.478403] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310) [5.481928] ata1.00: ata_hpa_resize 1: sectors = 234441648, hpa_sectors = 234441648 [5.485904] ata1.00: ata_hpa_resize 1: sectors = 234441648, hpa_sectors = 234441648 [5.485913] ata1.00: configured for UDMA/100 [5.505109] sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors (120034 MB) [5.505461] sd 0:0:0:0: [sda] Write Protect is off [5.505465] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [5.505612] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA ... [6.157259] Restarting tasks ... done. And with echo 0 /sys/class/scsi_disk/0\:0\:0\:0/manage_start_stop: [2.476476] ata2: SATA link down (SStatus 0 SControl 310) ... [2.825479] Restarting tasks ... done. ... [5.022076] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310) [5.025605] ata1.00: ata_hpa_resize 1: sectors = 234441648, hpa_sectors = 234441648 [5.028594] ata1.00: ata_hpa_resize 1: sectors = 234441648, hpa_sectors = 234441648 [5.028606] ata1.00: configured for UDMA/100 [5.028720] sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors (120034 MB) [5.028767] sd 0:0:0:0: [sda] Write Protect is off [5.028773] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [5.028831] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA So over all it takes half a second longer to detect the disk, but because everything waits on it, it takes more than three seconds longer to resume. Eeeek. Extra three secs doesn't sound too hot. :-( Setting manage_start_stop to 0 fixes it and is good enough for me, I didn't notice anything bad yet because of the unmanaged stop. Implementing background spin up will fix it too. Just commenting out sd_resume() would be a better solution for your case tho. Everything seems to work fine without sd_resume(), so why is it needed? Because not all disks spin up without being told to do so and like it or not spinning disks up on resume is the default behavior. As I wrote in the other reply, it would be worthwhile to make it configurable. Not even after they receive a read command? Ugh. After receiving a command which requires media access, they do. What I was saying is that the current default behavior is to spin up all devices on resume and part of that is achieved by sd_resume(). Hmmm... skipping START_STOP during sd_resume() actually is a pretty good solution for ATA devices. I'll think about it. Thanks. -- tejun - 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/
Re: sd_resume redundant? [was: [PATCH] libata: implement ata_wait_after_reset()]
Indan Zupancic wrote: Everything seems to work fine without sd_resume(), so why is it needed? Because not all disks spin up without being told to do so and like it or not spinning disks up on resume is the default behavior. As I wrote in the other reply, it would be worthwhile to make it configurable. Not even after they receive a read command? Ugh. ATA disks are supposed to spin up, yes. SCSI disks require a command to tell them to spin up if they're in the stopped state. -- Robert Hancock Saskatoon, SK, Canada To email, remove nospam from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - 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/
Re: sd_resume redundant? [was: [PATCH] libata: implement ata_wait_after_reset()]
On Sun, 20 May 2007 11:45:03 -0600 Robert Hancock wrote: Indan Zupancic wrote: Everything seems to work fine without sd_resume(), so why is it needed? Because not all disks spin up without being told to do so and like it or not spinning disks up on resume is the default behavior. As I wrote in the other reply, it would be worthwhile to make it configurable. Not even after they receive a read command? Ugh. ATA disks are supposed to spin up, yes. SCSI disks require a command to tell them to spin up if they're in the stopped state. Good info, but linux-ide was dropped. Is that due to lack of reply-to-all or is it a newsgroup thing or what? --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - 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/
Re: sd_resume redundant? [was: [PATCH] libata: implement ata_wait_after_reset()]
On Sun, May 20, 2007 19:17, Tejun Heo wrote: Indan Zupancic wrote: So over all it takes half a second longer to detect the disk, but because everything waits on it, it takes more than three seconds longer to resume. Eeeek. Extra three secs doesn't sound too hot. :-( Hey, without your reset fix it was 11 seconds slower. ;-) Well, it used to be around 1.7 seconds to resume, and now (after the fixes) it's 2.8 (according to the dmesg timestamps). But the first timestamp printed was 0.7, and now it's 2.1, so I don't know if it's a real slowdown or that the timer is set correctly earlier. That was with 2.19 btw, I don't know what happened in the meantime. I suspect the timer changes. To know for sure I'd need to boot an older kernel and measure resume time with a stopwatch. Setting manage_start_stop to 0 fixes it and is good enough for me, I didn't notice anything bad yet because of the unmanaged stop. Implementing background spin up will fix it too. Just commenting out sd_resume() would be a better solution for your case tho. I like your idea below more. ;-) Everything seems to work fine without sd_resume(), so why is it needed? Because not all disks spin up without being told to do so and like it or not spinning disks up on resume is the default behavior. As I wrote in the other reply, it would be worthwhile to make it configurable. Not even after they receive a read command? Ugh. After receiving a command which requires media access, they do. What I was saying is that the current default behavior is to spin up all devices on resume and part of that is achieved by sd_resume(). Hmmm... skipping START_STOP during sd_resume() actually is a pretty good solution for ATA devices. I'll think about it. I can't speak for others, but for me this would fix all regressions and even disk spin up seems half a second faster without the START_STOP. It would also solve the laptopmode thing, not unnecessarily spinning up disks that don't need to be (if the hardware doesn't do it). 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/
Re: sd_resume redundant? [was: [PATCH] libata: implement ata_wait_after_reset()]
Randy Dunlap wrote: On Sun, 20 May 2007 11:45:03 -0600 Robert Hancock wrote: Indan Zupancic wrote: Everything seems to work fine without sd_resume(), so why is it needed? Because not all disks spin up without being told to do so and like it or not spinning disks up on resume is the default behavior. As I wrote in the other reply, it would be worthwhile to make it configurable. Not even after they receive a read command? Ugh. ATA disks are supposed to spin up, yes. SCSI disks require a command to tell them to spin up if they're in the stopped state. Good info, but linux-ide was dropped. Is that due to lack of reply-to-all or is it a newsgroup thing or what? That would be a newsgroup thing. It seems that sometimes CCs get dropped when the posts are forwarded to fa.linux.kernel where I normally read them. -- Robert Hancock Saskatoon, SK, Canada To email, remove nospam from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - 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/
sd_resume redundant? [was: [PATCH] libata: implement ata_wait_after_reset()]
On Sat, May 19, 2007 21:04, Tejun Heo wrote: > Tejun Heo wrote: >> Yeah, if SCR registers are accessible, 0xff doesn't indicate the device >> isn't there, so the whole skip-0xff logic probably shouldn't apply in >> such cases, but we can also achieve pretty good result by just making >> the first reset tries a bit more aggressive. > > So, here's the patch. > > Paul, can you please test this patch without the previous patch? Indan, > this should reduce the resume delay. Please test. But you'll still > feel some added delay compared to 2.6.20 due to the mentioned > suspend/resume change. This removed the COMRESET errors indeed, and with sd_resume() disabled everything is speedy again (2s or so. Still a desktop pc). I didn't try with sd_resume enabled. Everything seems to work fine without sd_resume(), so why is it needed? 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/
sd_resume redundant? [was: [PATCH] libata: implement ata_wait_after_reset()]
On Sat, May 19, 2007 21:04, Tejun Heo wrote: Tejun Heo wrote: Yeah, if SCR registers are accessible, 0xff doesn't indicate the device isn't there, so the whole skip-0xff logic probably shouldn't apply in such cases, but we can also achieve pretty good result by just making the first reset tries a bit more aggressive. So, here's the patch. Paul, can you please test this patch without the previous patch? Indan, this should reduce the resume delay. Please test. But you'll still feel some added delay compared to 2.6.20 due to the mentioned suspend/resume change. This removed the COMRESET errors indeed, and with sd_resume() disabled everything is speedy again (2s or so. Still a desktop pc). I didn't try with sd_resume enabled. Everything seems to work fine without sd_resume(), so why is it needed? 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/
