On Thu, 13 Oct 2011, gene heskett wrote: > Anyway, I did get one boot to the rebuilt kernel to work, but in text > mode only. Here is that dmesg ... > usb 1-2.1: new full speed USB device using ehci_hcd and address 8 > hub 1-2:1.0: port 1 not reset yet, waiting 10ms > usb 1-2.1: ep0 maxpacket = 8 > usb 1-2.1: default language 0x0409 > usb 1-2.1: udev 8, busnum 1, minor = 7 > usb 1-2.1: New USB device found, idVendor=03eb, idProduct=3301 > usb 1-2.1: New USB device strings: Mfr=0, Product=2, SerialNumber=0 > usb 1-2.1: Product: Standard USB Hub > usb 1-2.1: usb_probe_device > usb 1-2.1: configuration #1 chosen from 1 choice > usb 1-2.1: adding 1-2.1:1.0 (config #1, interface 0) > hub 1-2.1:1.0: usb_probe_interface > hub 1-2.1:1.0: usb_probe_interface - got id > hub 1-2.1:1.0: USB hub found > hub 1-2.1:1.0: 4 ports detected > hub 1-2.1:1.0: standalone hub > hub 1-2.1:1.0: ganged power switching > hub 1-2.1:1.0: global over-current protection > hub 1-2.1:1.0: power on to power good time: 100ms > hub 1-2.1:1.0: local power source is good > hub 1-2.1:1.0: no over-current condition exists > hub 1-2.1:1.0: enabling power on all ports ... > usb 1-2.1.4.4.4: new full speed USB device using ehci_hcd and address 19 > hub 1-2.1.4.4:1.0: port 4 not reset yet, waiting 10ms > usb 1-2.1.4.4.4: default language 0x0409 > usb 1-2.1.4.4.4: udev 19, busnum 1, minor = 18 > usb 1-2.1.4.4.4: New USB device found, idVendor=04f9, idProduct=0033 > usb 1-2.1.4.4.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 > usb 1-2.1.4.4.4: Product: HL-2140 series > usb 1-2.1.4.4.4: Manufacturer: Brother > usb 1-2.1.4.4.4: SerialNumber: L7J156867 > ^^^^^^^^^^^^^^^^it did find it^^^^^^^^^^^^^^^ > I put a tail on messages and after about 10 unplug-replug cycles of the > parent hub, it finally did find the Brother HL-2140 printer. > > A snip from the messages log: For kernel work, you should always use dmesg rather than /var/log/messages. > Fudge, 8 hours work for nothing. I only changed the CONFIG_USB_DEBUG, but the messages logs has: > ct 12 22:32:17 coyote klogd: Notice: NX (Execute Disable) protection cannot be enabled: non-PAE kernel! That's part of the reason. Systems are usually set up so that debugging messages don't get stored in /var/log/messages. Dmesg keeps everything. > Continuing to the usb section: ... > Oct 12 22:32:17 coyote klogd: usb 1-2.1: new full speed USB device using ehci_hcd and address 8 > Oct 12 22:32:17 coyote klogd: usb 1-2.1: New USB device found, idVendor=03eb, idProduct=3301 > Oct 12 22:32:17 coyote klogd: usb 1-2.1: New USB device strings: Mfr=0, Product=2, SerialNumber=0 > Oct 12 22:32:17 coyote klogd: usb 1-2.1: Product: Standard USB Hub > Oct 12 22:32:17 coyote klogd: hub 1-2.1:1.0: USB hub found > Oct 12 22:32:17 coyote klogd: hub 1-2.1:1.0: 4 ports detected ... > Ok, that is about the end of that time slot, here is where I finally got it > to recognize the printer, by multiple unplug-replugs of the parent hub. Bear > in mind there is this 4 port hub, which has a 16 foot extension cable/hub > plugged into it, and a 7 port alps hub plugged into the hub on the end of > the cable. > > Here is an instance when it was not rediscovered: ... > Oct 12 22:46:26 coyote klogd: usb 1-2: new high speed USB device using ehci_hcd and address 20 > Oct 12 22:46:26 coyote klogd: usb 1-2: New USB device found, idVendor=0409, idProduct=005a > Oct 12 22:46:26 coyote klogd: usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 > Oct 12 22:46:26 coyote klogd: hub 1-2:1.0: USB hub found > Oct 12 22:46:26 coyote klogd: hub 1-2:1.0: 4 ports detected > Oct 12 22:46:26 coyote klogd: usb 1-2.1: new full speed USB device using ehci_hcd and address 21 > Oct 12 22:46:26 coyote klogd: usb 1-2.1: New USB device found, idVendor=03eb, idProduct=3301 > Oct 12 22:46:26 coyote klogd: usb 1-2.1: New USB device strings: Mfr=0, Product=2, SerialNumber=0 > Oct 12 22:46:26 coyote klogd: usb 1-2.1: Product: Standard USB Hub > Oct 12 22:46:26 coyote klogd: hub 1-2.1:1.0: USB hub found > Oct 12 22:46:26 coyote klogd: hub 1-2.1:1.0: 4 ports detected > Oct 12 22:46:26 coyote klogd: hub 1-2.1:1.0: config failed, can't get hub status (err -32) That line shows the problem. The hub didn't report its status. > And that is the total output for that unplug-replug instance. Unplugged time > is 3-5 seconds each time. All hubs remained powered during this. Only the > data cable to the hub was pulled. > > I get the impression the usb queries are not giving sufficient time for > the response to arrive. No, it's not that. Your 1-2.1 hub is crap -- replace it if you can. (Maybe keep it as a spare or for testing.) It's not even a USB-2.0 hub; it only runs at full speed. In the path leading to the Brother printer, 1-2.1 is the second hub down from the computer. That is, the hub plugged directly into the computer is 1-2, and 1-2.1 is plugged into 1-2. If that's the hub built into the extension cable ... well, now you can see why extension cables aren't always a great idea. If it will make life easier, you can use software to do the equivalent of the unplug/replug: echo 0 >/sys/bus/usb/devices/1-2/bConfigurationValue is much like unplugging the cable from the computer. The same command with 1 in place of 0 is like replugging. You may find that using 1-2.1 in place of 1-2 in these commands works a little better. Or maybe not; without proper debugging info it's hard to know what's going on. > And now I'm having x problems, my cursor is disappearing for 5 seconds at > a time. Can't help with that, I'm afraid... Good luck, 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
