On Mon, May 09, 2011 at 09:16:04AM -0700, Andy Ross wrote: > The background here: > > The ExoPC tablet (intel pinetrail) with recent kernels is reliably > hanging for ~90 seconds on boot. I tracked this down to the > pci_write_config_byte() call in the ehci quirk handler that tries to > write the "BIOS handoff" semaphore. It doesn't look like it's > failing: the rest of the handoff process completes successfully after > it returns. > > Beyond discovering that it's a little timing-sensitive (the hang is > reliable in an unpatched 2.6.38, was sporadic on earlier MeeGo > kernels, and happens only about 25% of the time or so if I add a > msleep(1) immediately before the call) I couldn't find any magic to > fix it. The #if'd out SMI enable immediately above seemed promising, > but was ineffective. > > So I hacked in a "ehci_force_handoff" parameter to turn the handoff > process off and treat it as it already does on failure. The fact that > the code seems prepared to handle this tells me (maybe) that this > isn't too likely to wreck things. It seems to work great to restore > boot times on the ExoPC, and testing on two other pinetrail netbooks > didn't show anything problems. > > Ideas? Ick. Sounds like a BIOS bug to me, have you worked with the BIOS people to track down why this call to it is taking so long? I really don't want to add a parameter for something like this if at all possible, as distros will not know how to enable this or not. At worse case, could we trigger off of known DMI strings for the broken machines? thanks, greg k-h -- 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
