On Wed, 26 Oct 2011, OBD wrote: > On 25 October 2011 20:34, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > Aha! �OHCI controllers from NVIDIA are known to have some weird bugs. > > The kernel tries to work around them, but it doesn't always do a > > perfect job. > > > > Below is a patch you can try out. �It won't fix the problem directly, > > but it will create two new sysfs files for you. �After you boot the new > > kernel, but before attaching the modem, look at: > > > > � � � �/sys/bus/pci/devices/0000:00:02.0/shutdown_quirk > > � � � �/sys/bus/pci/devices/0000:00:04.0/shutdown_quirk > > > > I expect each of them will contain a 0. �Try writing a 1 into each and > > then see how the modem behaves. > > > Thanks Alan. > > I tried the fix that you provided on 3.0.4 version of the kernel, but > it did not quite work as expected. > I could see these two sysfs files, and their value was 0 as you > expected. However changing the value to 1 made no difference as far as > the USB modem is concerned. It continues to connect and disconnect > regularly. It was stupid of me to send that patch. I thought of it immediately when I saw the NVIDIA controllers, but the patch has no effect on new devices when they are plugged in. All it affects is what happens when the system is shut down. So forget about it; you can remove it. > Further, I did try the other modem that was working before, and it > continues to work even after application of this patch. Another > noticeable thing is the complete absence of "unable to enumerate USB > device" message in the dmesg output. This indicates you don't have a controller problem after all. It might be something as simple as a bad USB cable connection. Or maybe the AMD computer doesn't provide quite enough power -- do the modems have their own power supply, or do they run on USB bus power? > I have attached usbmon logs after application of the patch (if it helps). > > The dmesg output (same as before): > > [ 659.529977] usb 3-2: new full speed USB device number 24 using ohci_hcd > [ 659.734814] scsi18 : usb-storage 3-2:1.0 > [ 664.831694] usb 3-2: USB disconnect, device number 24 > [ 665.559981] usb 3-2: new full speed USB device number 25 using ohci_hcd > [ 669.274840] usb 3-2: USB disconnect, device number 25 > [ 671.426632] usb 3-2: new full speed USB device number 26 using ohci_hcd > [ 671.631504] scsi19 : usb-storage 3-2:1.0 > [ 676.735364] usb 3-2: USB disconnect, device number 26 > [ 677.473296] usb 3-2: new full speed USB device number 27 using ohci_hcd > [ 681.188466] usb 3-2: USB disconnect, device number 27 > [ 683.339962] usb 3-2: new full speed USB device number 28 using ohci_hcd > [ 683.544892] scsi20 : usb-storage 3-2:1.0 > [ 688.645222] usb 3-2: USB disconnect, device number 28 > > > I am not sure if this points to anything or not, but the in the above > dmesg output, scsi device detection does not occur with each USB > device connect/disconnect cycle. Yes, that shows up in the usbmon log too. The log shows that the device seems to alternate between presenting a mass-storage interface and presenting a communications interface. Try one more experiment: Collect two equivalent usbmon traces, one from each of the computers. And this time, unload ehci-hcd before starting the trace. That just might have some effect. Perhaps comparing the two traces will show something. Although I doubt it -- this really does look like a low-level problem, like the sort of thing that happens when a device doesn't have quite enough power. Alan Stern -- 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
