I have reported the issue in bugzilla, before (bug 43073). Because the problem does not appear every time, I am able to boot with new kernels (sometimes). I also found that the problem is triggered by a specific sequence of io read/write operations (including the software reset) related to the host controller (during init) and by changing the operations or inserting delays between them it can be solved. However, since I wasn't able to duplicate the issue on other computers (which I know I should have done first) it could be a hardware failure (a weird one) brought to surface by that software change (I know for sure it's the function I mentioned below). If that is true, than I appologize for not having it tested in more detail first. On the other hand, (I don't know the exact specs) if it is not the hardware, I can provide further details if needed. Calin Demian 2012/4/23 Bjorn Helgaas <bhelgaas@xxxxxxxxxx>: > On Wed, Apr 11, 2012 at 1:38 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: >> On Wed, 11 Apr 2012, Calin Demian wrote: >> >>> Hi! >>> Yes, in fact I did allready follow the execution, and it looks like this: >>> function file >>> pci_apply_final_quirks /drivers/pci/quirks.c >>> pci_fixup_device ~ >>> pci_do_fixups ~ >>> here, for the ohci busses 2 functions are called: >>> nv_msi_ht_cap_quirk_all /drivers/usb/host/pci-quirks.c >> >> What is that? It's not present in my copy of the kernel source. >> >>> quirk_usb_early_handoff ~ >>> quirk_usb_early_handoff calls the following 3 functions: >>> pci_enable_device(pdev) /drivers/pci/pci.c >>> quirk_usb_handoff_ohci(pdev) /drivers/usb/host/pci-quirks.c >>> pci_disable_device(pdev) >>> >>> The execution stops inside pci_disable_device, but because >>> quirk_usb_handoff_ohci is the only function that has changed between >>> versions 3.0.13 and 3.0.20 from the list of files mentioned above, it >>> seems that this function changed behaviour in a way that my computer >>> doesn't like. >> >> That cannot be right. The call to pci_disable_device was added after >> the change to quirk_usb_handoff_ohci. >> >>> Further trace: >>> pci_disable_device >>> do_pci_disable_device >>> pci_read_config_word >> >> I have no idea why your computer would crash inside or after >> pci_read_config_word. >> >> Anyway, this is a PCI problem, not a USB problem. Maybe the PCI >> experts can help. I have CC'ed the linux-pci mailing list. >> >> Alan Stern >> >>> with respect, >>> Calin Demian >>> >>> >>> 2012/4/11 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>: >>> > On Wed, 11 Apr 2012, Calin Demian wrote: >>> > >>> >> 1.Boot problem: computer stops responding during boot. >>> >> >>> >> 2.The symptom doesn't occur allways, but when it does, it is at the >>> >> same point during the boot process. The last messages displayed differ >>> >> between different kernel versions, but are the same each time. >>> >> I would appreciate if you could take a look at function >>> >> "quirk_usb_handoff_ohci" in file /drivers/usb/host/pci-quirks.c - >>> >> which was modified in version 3.0.17 of the mainline kernel. The >>> >> problem appeared when upgrading Ubuntu from mainline kernel version >>> >> 3.0.13 to version 3.0.20. Searching the changelogs I found that this >>> >> function was modified between the two releases. The computer freezes >>> >> durin applying the quirks (pci_apply_final_quirks) for bus >>> >> 0000:00:13.1 (the 2nd OHCI bus). Controller is ALI (EHCI 8 ports + >>> >> OHCI 3x3 ports), dev_id 5237(OHCI). > > It sounds like this is a regression between 3.0.13 and 3.0.20. Can > you please open a bug report here: > > https://bugzilla.kernel.org/enter_bug.cgi?product=Drivers&component=PCI > > and attach dmesg or serial console logs with "debug ignore_loglevel > initcall_debug" for both kernels? For 3.0.20 you probably can't get a > dmesg log because of the hang, so a digital photo would be fine, too. > > Thanks, > Bjorn -- 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
