Ok, I checked the computer and to my surprise, now it's working fine (at least until now). Greg is right. It was the hardware. If I knew that I wouldn't raise this discussion. I didn't know, ok? Anyway it's a strange failure mode... Thank you again Calin Demian 2012/4/27 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>: > On Thu, 26 Apr 2012, Greg KH wrote: > >> On Thu, Apr 26, 2012 at 02:28:59PM -0400, Alan Stern wrote: >> > This patch (as1549) fixes a rare problem affecting at least one OHCI >> > controller: The controller requires a delay of at least 1 microsecond >> > following a reset, even though it says that it is ready immediately. >> > >> > The fix is to do the delay first, before checking whether the reset is >> > complete in the retry loop. > >> So we just slowed down the init sequence here by 1us for all systems due >> to one specific broken machine? > > All systems with PCI-based OHCI controllers -- but Calin isn't certain > there's only one machine with this hardware bug. > > Furthermore, it's not clear whether things will slow down at all. If > the controller takes more than 1 us to reset anyway, this change won't > make any difference. I haven't tested to see how many iterations the > loop takes on my machine. > >> When we have systems that are working really hard to tweak out the >> fastest boot speed possible, is this really advisable? > > I don't know how hard those systems are working to improve boot speed. > If they have reached the point where a couple of microseconds makes a > noticeable difference then they have gotten a lot farther than I ever > thought they could. > > Other changes could have a bigger impact on boot speed. For example, > the ehci_bios_handoff() routine has a loop that waits for 10 ms on each > iteration. If that delay were reduced to 5 ms, we could expect to save > a couple of milliseconds on average. That's a factor of 2000 more than > the OHCI change under discussion. > >> How about a hardware-specific quirk here for such broken hardware >> instead? > > If you and Calin think it's really necessary. On the other hand, if > you prefer to reject this patch on the basis that it helps only one > machine, I don't mind. > > Alan Stern > -- 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
