On 02.11.2012 10:42, Alan Stern wrote: > On Thu, 1 Nov 2012, Matthias Schniedermeyer wrote: > > > > Okay, Matthias, here's an updated version of that patch. The only > > > difference is that it puts the usb_hcd_alloc_bandwidth() call _before_ > > > the usb_disable_interface() calls. > > > > This time it worked. The HDD showed up after the echo. > > Great! > > > Could the kernel automate this, like do what the echo triggers > > automatically 1-2 seconds after it sees the error? I guess it's only > > about 1 second or so that this HDD/enclosure-pair spins/boots up too > > slow. > > That's not such a good idea. Firstly, although your device requires > only 1 second, other devices might need different amounts of time. > Secondly, what if the second attempt fails? Do we try again, and then > again, forever (and spamming the kernel log with an error message each > time)? I wouldn't say forever, my instict would say about 5 times with increasingly longer intervals. Say 1,2,3,4,5 seconds for a total of 15 seconds. Then you can always do another manual try. > And then what about other sorts of errors? Should the kernel > automatically retry every operation whenever there's a failure? I see what you mean, my case is relatively clear cut, but others might not be. And it MAY be that WD fixed the "problem" in newer revision of the same HDD-model. At last 1 (of 4) i bought last week and which i just tested showed up in time. > No, it's better for the retries to be carried out by the caller. In > this case the caller is you, although you could write a udev script to > do it automatically. Which i will be doing for myself, as i don't want to do that manually whenever i want to switch on one of the problematic HDDs. I have at least 2 HDDs which have this problem, 1 that worked and 3 which are currently unknown, but i bought them together with the 1 that worked so i have a little hope. -- Matthias -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
