On Wed, 1 May 2013, Martin Mokrejs wrote: > Sarah Sharp wrote: > > The "HW died, polling stopped" message is harmless. It happens when the > > xHCI host goes into a PCI low power state (D3). When the PCI host goes > > into D3cold, the registers will read as all Fs, and the polling loop > > will mistakenly believe the hardware has been removed. However, this > > bug only effects the debug code. It does not effect any other part of > > the xHCI driver. > > I think I do not mind it affects just the XHCI_DEBUG stuff. I just refer > to "those" places in the source code where something else *could* happen: > a detection of a silently ejected or dead hardware. > > I really did unplug the express card providing second USB3.0 controller > (11:00). My point was that although pciehp did not propagate the hot eject > to downstream drivers (xhci_hcd) I believe xhci_hcd could have realized it > by itself because it does polling time to time and this, albeit debugging > code, shows where roughly something more clever could happen. Ideally in > place of the "HC error bitmask = 0x4" (due to un-notified hot removal) or > at least at the time when "HW died, polling stopped" was printed > (un-notified hot-reinsert) xhci_hcd could realize a device is gone.
That's not how drivers work in Linux. They don't unbind all by themselves; they wait until the bus-level code tells them to unbind. xhci-hcd is not alone in this respect; all the drivers behave this way. > So what can be done so that the user does not have to run > > echo 1 > /sys/bus/pci/devices/0000:11:00.0/remove > > manually? Couldn't xhci_hcd detect somehow that the device is dead or ejected? It could detect that the device is dead. In fact, it probably detects that now. But even if it could tell that the device had been ejected, it would not unbind itself. What can be done is to fix the PCIe core code so that it correctly realizes when an eject takes place. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
