On Tuesday, November 16, 2010 07:48:07 am vasos wrote: > On 16/09/2010 12:50 ÎÎ, vasos wrote: > > On 15/09/2010 06:10 ÎÎ, Don Dutile wrote: > >> vasos wrote: > >>> Hello, > >>> > >>> i wish to report a strange issue that my machine experiences with a > >>> NEC USB 3.0 PCI-Express (x1 slot) controller. Normally the controller > >>> uses the xhci (usb3) kernel driver. > >>> Now the machine is running > >>> > >>> Linux xxxx 2.6.35.4 #2 SMP Wed Sep 1 10:15:04 UTC 2010 x86_64 GNU/Linux > >>> > >>> Note that this issue was present in 2.6.34 and 2.6.33 but i though that > >>> it might get fixed in the meantime. > >>> > >>> > >>> > >>> The issue > >>> ---------- > >>> The controller is sometimes detected and some times not. I mean that at > >>> some boots it > >>> is present as a PCI device (listed in pci -v as > >>> 05:00.0 USB Controller: NEC Corporation Device 0194 (rev 03) > >>> (prog-if 30) > >>> Flags: bus master, fast devsel, latency 0, IRQ 16 > >>> Memory at febfe000 (64-bit, non-prefetchable) [size=8K] > >>> Capabilities: [50] Power Management version 3 > >>> Capabilities: [70] MSI: Enable- Count=1/8 Maskable- 64bit+ > >>> Capabilities: [90] MSI-X: Enable- Count=8 Masked- > >>> Capabilities: [a0] Express Endpoint, MSI 00 > >>> Capabilities: [100] Advanced Error Reporting > >>> Capabilities: [140] Device Serial Number ff-ff-ff-ff-ff-ff-ff-ff > >>> Capabilities: [150] #18 > >>> Kernel driver in use: xhci_hcd > >>> ) > >>> > >>> and some other times it just does not exist. > >>> Maybe it is PCIe express related. Also people on linux-usb mailing list > >>> suggested this. > >>> I include 2 full dmesg logs ziped due to the size as well a unified > >>> diff > >>> of them. > >>> > >>> NOTE that "echo 1> /sys/bus/pci/rescan" does not do anything. > >>> > >>> > >>> Please cc the replies if any to the sender email (noxelia ...) > >>> > >>> > >> Is this x1 device in a x4 (or higher xN) slot? > >> I've seen x4 slots not lane-(width) sync with x1 NICs in some systems > >> (even though the PCIe spec says it should), esp. if one resets the > >> device > >> after boot (i.e., flr reset). > >> > >> If so, try the card in a x1 slot& see if the problem goes away. > >> > > > > The card fits exactly on the x1 slot (the smallest possible). > > Thanks > > > > vasil > > Hello, > > i want to note that the issue has been resolved after i moved the pcie > x1 expansion card from one x1 slot to another x1 slot. The MB has 2 x1 > slots and 1 x16 (i think) slot. This seems like only a workaround, not a real resolution, unless you have some evidence that the first x1 slot (where the controller is only detected sometimes) is physically broken on the motherboard. Is there *any* kernel where the controller is reliably detected in the first slot? What about with Windows? From your dmesg logs, it looks like the BIOS is doing something different in the working vs. the non- working cases: - #6 [00000fdf38 - 00000ff780] BIOS reserved - #7 [00000fdde0 - 00000fdf38] MP-table mpc + #6 [00000fdf30 - 00000ff780] BIOS reserved + #7 [00000fdde0 - 00000fdf30] MP-table mpc It's interesting that the MP-table seems to be a different size; can you dump out both tables so we can compare them? Maybe it's related to BIOS settings (though I doubt you're changing them), or something to do with the way the previous boot was shut down? If you can figure out the pattern, maybe it will help identify a Linux bug or help write a quirk to work around a BIOS issue. Bjorn -- 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
