Bill Davidsen wrote:
I think the solution to your problem is adjusting command timeout to
more reasonable values which should make the problem more bearable.
It'll take some time to figure out how to make timeouts more
intelligent without breaking support for slow devices. I'll work on
that.
Tejun, would it be possible and sensible to either let the user tune
this per-drive, or to have the kernel note how long {something} takes
and auto-tune to that? As you said, the issue is not breaking slow devices.
I think the driver can be made to have sufficient static intelligence to
not require user or auto tuning. !BUSY wait in pre/postreset which are
often cause of unnecessary 30s delay during recovery can be avoided by...
1. for !hotplug, waiting for BSY before reset doesn't make sense in the
first place (why would we be resetting the device if it can clear BSY?)
2. for hotplug, we can make things much more intelligent. e.g. try
prereset waiting and softreset from 0-5s, then hardresets 5-10s, 10-15s,
15-30s and 30s-60s, which will guarantee 1. slow device is given full
idle 30s to get ready eventually 2. recovery reset is complete in 60s,
while giving fast devices several chances to be fast.
And, for IO command timeouts, some operating system is said to use 7s
timeout for ATA IO commands and simply adopting that value would be good
enough. We also can choose more agressive timeouts for some EH commands
(IDNTIFY, SET_FEATURES...).
With all above combined, EH recovery should be pretty snappy and
recovery time well-bound.
--
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/
[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]
