On Wed, Jul 4, 2012 at 3:14 PM, Rafael J. Wysocki <rjw@xxxxxxx> wrote: > On Wednesday, July 04, 2012, Alan Stern wrote: >> On Wed, 4 Jul 2012, AceLan Kao wrote: >> >> > We contacted the ASUS' BIOS engineer and try to verify this issue, for >> > it happened >> > on many ASUS' machines. Then they found that the system hangs in their >> > BIOS code. >> > The code will try to disable the USB if they found the PCI COMMAND >> > register is not zero. >> > >> > That's not a correct behavior that BIOS should do, the PCI COMMAND >> > register is not >> > represent if the USB is disabled or not, It's a workaround they tried to fix >> > another issue in windows long time ago, but ASUS' BIOS engineer refuse to remove >> > that part of code. But windows will clear the PCI COMMAND register if >> > windows is already >> > disabled the USB. >> > So, I try to write this quirk. >> >> > > Is there any reason not to clear the PCI COMMAND register of every PCI >> > > USB host controller when entering S3? >> > Quote from ASUS, they only mentioned EHCI >> > --------- >> > BIOS will check EHCI command register PCI regiter offset 04h to see if >> > USB is disabled or not. >> > Because regiter offset 04h is not cleared, BIOS think USB is not disabled. >> > Then BIOS will try to disabled USB, but the USB is disabled by Ubuntu >> > already. This conflict will cause system hang. >> > ASUS think since Ubuntu will disable USB, it also need to clear the >> > register too. >> > --------- >> >> How about this patch instead? (I haven't tested it yet...) >> >> Rafael, does this seem okay with no special quirk flag? Or should the >> command register be cleared as part of the USB code? > > Well, the clearing of it in the USB code would probably be too early, > so we don't really have much choice. > > I suppose we can add pci_fixup_suspend_noirq for that in analogy with > pci_fixup_suspend, but I'm not sure it's worth the effort. > > Bjorn, what do you think? I agree; it doesn't seem like a new fixup type is worth the trouble. I wish we knew more about what's really going on here. I looked through the bug reports AceLan dug up, and I don't get the feeling that anybody really has a grand unified theory about why Windows works but Linux doesn't. But I'm willing to apply one of these patches if you and/or Alan sign off on it. >> Index: usb-3.5/drivers/pci/pci-driver.c >> =================================================================== >> --- usb-3.5.orig/drivers/pci/pci-driver.c >> +++ usb-3.5/drivers/pci/pci-driver.c >> @@ -748,6 +748,18 @@ static int pci_pm_suspend_noirq(struct d >> >> pci_pm_set_unknown_state(pci_dev); >> >> + /* >> + * Some BIOSes from ASUS have a bug: If a USB EHCI host controller's >> + * PCI COMMAND register isn't 0, the BIOS assumes that the controller >> + * hasn't been quiesced and tries to turn it off. If the controller >> + * is already in D3, this can hang or cause memory corruption. >> + * >> + * Since the value of the COMMAND register doesn't matter once the >> + * device has been suspended, we can safely set it to 0 here. >> + */ >> + if (pci_dev->class == PCI_CLASS_SERIAL_USB_EHCI) >> + pci_write_config_word(pci_dev, PCI_COMMAND, 0); >> + >> return 0; >> } >> >> >> >> > > -- > To unsubscribe from this list: send the line "unsubscribe linux-pci" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
