On Mon, 19 Jan 2009, Sam Liddicott wrote: > >> My USB hard disk has a built-in hub as lsusb shows: > >> > >> Bus 005 Device 006: ID 1058:0702 Western Digital Technologies, Inc. > >> Passport External HDD > >> Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > >> > > > > This doesn't show anything one way or another, since it doesn't > > indicate whether device 006 is a hub or not. > > > > Device 001 is a hub, though, surely? It vanishes when I remove the USB > hard disk. Device 001 is always a root hub, a virtual hub associated with a USB host controller. It's not a real hub. It shouldn't vanish unless you unload the host controller driver. > > What devices? It sure looks like it enumerated the hub. That's what > > the last line indicates. > > > > Yes, but it didn't seem to enumerate the hard disk sitting of the end of > it. > > I think I was too brief on my data sources for which I apologise. > > The lsusb (shown above) was taken from my desktop PC based on a diff of > lsusb before and after inserting the disk. (The musicpal doesn't have > lsusb). > > The dmesg above is from the musicpal. > > It seems like the musicpal notices the hub built-in to the disk but not > the disk Okay. That's better than not enumerating the four-port hub at all. > So I did some "control" tests using a cheap 4 port hub, which my desktop > PC lsusb shows as: > Bus 003 Device 005: ID 058f:9254 Alcor Micro Corp. Hub > > Although it recognizes and mounts a usb memory stick when plugged > directly, it fails to do so if it is plugging in via the 4 port hub. > > >> if I plug in a 4 port hub, dmesg -c shows: > >> > >> $ dmesg -c > >> usb 1-1: new high speed USB device using ehci-mv88w8xx8 and address 12 > >> usb 1-1: ep0 maxpacket = 8 > >> usb 1-1: new high speed USB device using ehci-mv88w8xx8 and address 13 > >> usb 1-1: ep0 maxpacket = 8 > >> usb 1-1: new high speed USB device using ehci-mv88w8xx8 and address 14 > >> usb 1-1: ep0 maxpacket = 8 > >> usb 1-1: new high speed USB device using ehci-mv88w8xx8 and address 15 > >> usb 1-1: ep0 maxpacket = 8 That shows the system detecting the hub four times, and each time failing to enumerate it. > >> but the new hubs don't show up > >> $ ls -l /sys/bus/usb/drivers/hub/ > >> lrwxrwxrwx 1 root root 0 Jan 17 10:56 1-0:1.0 -> > >> ./../../../devices/platform/ehci-mv88w8xx8.1436/usb1/1-0:1.0 > >> --w------- 1 root root 4096 Jan 17 10:56 bind > >> --w------- 1 root root 4096 Jan 17 10:56 new_id > >> --w------- 1 root root 4096 Jan 17 10:56 unbind > >> > > The dmesg above is from the musicpal when I insert a cheap self-powered > 4 port hub Could this be a power issue? If the cheap hub is bus-powered, your musicpal device might not provide enough Vbus power for the hub to work. Or for the hub + USB stick. > Aye, I could have asked a clearer question if I had known enough to > construct one... > but I didn't know if it happened in kernel space, and I thought the hub > driver was in usbcore anyway (and therefore always present), It is. > so I am so > far from what little I know... > > the only loadable module is the wland river, the rest is static. > > The dmesg below was when I do the same thing on my desktop pc: > > [47303.184027] usb 3-2: new full speed USB device using uhci_hcd and > address 5 > [47303.354191] usb 3-2: configuration #1 chosen from 1 choice > [47303.357401] hub 3-2:1.0: USB hub found > [47303.359030] hub 3-2:1.0: 4 ports detected > > I note that it doesn't mention assigning addresses - unlike the musicpal > which assigned 4 Sure it does. Didn't you see the "using uhci_hcd and address 5" part? It's on the first line above. > I was hoping to do either a spot-the-difference or check that which > thing my bad system isn't doing. As I think usbcore holds the hub > drivers I was hoping the problem would be down to a hotplug action or > something... Nope. Like I said, the problem isn't in userspace. > > Obviously you need a lot more information to find the problem. You > > should use a kernel with CONFIG_USB_DEBUG enabled, and you should use > > usbmon (see Documentation/usb/usbmon.txt) to trace what happens when > > the hub is plugged in. > > > > I'm using a 2.6.16 kernel and have checked "a" config file for that > kernel but don't find any obvious config options that might affect the > availability of the hub driver. Forget about the hub driver. Do what I said: enable CONFIG_USB_DEBUG, and use usbmon if you can. It wouldn't hurt to move up to a more recent kernel version as well... > If the kernel has kexec, I might manage what you say, otherwise it's > going to be fun and games as there's only about 200K spare in the flash > anyway... Doesn't your boot loader support loading a kernel image from a network connection? 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
