On Tue, 30 Dec 2003, Rogério Brito wrote:
> Ok, I tried the patch that you sent me. Since you said "instead", I
> removed the earlier patch before applying the current one.
Good.
> BTW, there was one tiny little problem which I was able to solve: the
> function deb_dbg that you used in the new patch didn't seem to be
> defined and I changed it to dev_dbg instead. It worked then. :-)
I try to avoid those little typos, but sometimes they creep in there
anyway... I'm glad you could figure it out and get it going.
> > > This time, I didn't disable the hotplug scripts, but right after I
> > > booted in single user mode, I did the "echo 4 > /proc/driver/uhci/..."
> > > command that you told me to use, before plugging the drive.
> >
> > It turns out that's not necessary. The problem occurs at a different
> > level, I think. Anyway, your logs so far haven't contained any
> > debugging information coming from that "echo 4..." command.
>
> Ok, I'll keep doing it if it does no harm, but I'll stop if you tell me
> to.
The "echo 4..." is okay. But hotplugging may complicate things a little
bit. I'd turn that off.
> Anyway, this time I'm putting two sets of dmesg logs. The second set of
> dmesg logs was generated after I (warm) rebooted my computer.
>
> I put two sets of logs because the messages that I saw in the first set
> (after plugging the drive) were not what I usually see (the second one
> seems to be more typical).
>
> Actually I thought that the drive was working when I saw the messages
> from the first set of logs, but when I tried to mount the drive, I got
> the same familiar "not a block device" message from mount. :-(
As far as I can tell, the drive really was working the first time. The
only reason you didn't see the block device was because of some hotplug
problem. Apparently the usb-storage module wasn't loaded when it should
have been. You can see it for yourself in the log; the line that says
Initializing USB Mass Storage driver...
should appear right after the line that says
SCSI subsystem initialized
But it doesn't; it comes much later. That's an indication that your
hotplug setup may not be quite right.
However, never mind hotplug problems for now. If the embedded hub doesn't
work right -- like what happened in your second test -- it won't matter
what the hotplug system does!
> As usual, the logs are at <http://www.ime.usp.br/~rbrito/usb/>.
>
> BTW, please let me know if you'd prefer if I posted the logs in any
> other way (say, like sending it via e-mail).
Yes. You may have noticed, each of your before-plugging, after-plugging,
after-unplugging logs is just an extension of the previous one. So you
don't have to include all three; it would be enough to include just the
last one and edit it by hand to indicate when you did the plugging and
unplugging.
Also, most of the stuff at the beginning of the log is unnecessary. In
fact, pretty much all the interesting lines are the ones that begin with
"usb 1-" or "hub 1-", plus the lines around them. And you can even skip
the first group of lines that begin with "hub 1-0:1.0:" because that's
just the initialization of a USB controller in your computer.
Put all that together, and assuming you have turned off hotplugging, the
log from your second test would end up looking like this:
hub 1-0:1.0: port 1, status 300, change 3, 1.5 Mb/s
hub 1-0:1.0: clear C_CONNECTION = 0
hub 1-0:1.0: port 2, status 100, change 3, 12 Mb/s
hub 1-0:1.0: clear C_CONNECTION = 0
hub 1-0:1.0: port 1 enable change, status 300
hub 1-0:1.0: port 2 enable change, status 100
--- plug ---
drivers/usb/host/uhci-hcd.c: d400: wakeup_hc
hub 1-0:1.0: port 2, status 101, change 3, 12 Mb/s
hub 1-0:1.0: clear C_CONNECTION = 0
hub 1-0:1.0: port 2 status 101 change 2
hub 1-0:1.0: port 2 status 101 change 2
hub 1-0:1.0: port 2 status 101 change 2
hub 1-0:1.0: port 2 status 101 change 2
hub 1-0:1.0: port 2 status 101 change 2
hub 1-0:1.0: debounce: port 2: delay 100ms stable 4 status 0x101
hub 1-0:1.0: new USB device on port 2, assigned address 2
usb 1-2: new device strings: Mfr=1, Product=3, SerialNumber=0
drivers/usb/core/message.c: USB device number 2 default language ID 0x409
usb 1-2: Product: USB Embedded Hub
usb 1-2: Manufacturer: Leading Driver Co.,LTD.
usb 1-2: registering 1-2:1.0 (config #1, interface 0)
hub 1-2:1.0: usb_probe_interface
hub 1-2:1.0: usb_probe_interface - got id
hub 1-2:1.0: USB hub found
hub 1-2:1.0: 2 ports detected
hub 1-2:1.0: compound device; port removable status: FF
hub 1-2:1.0: individual port power switching
hub 1-2:1.0: individual port over-current protection
hub 1-2:1.0: Port indicators are not supported
hub 1-2:1.0: power on to power good time: 100ms
hub 1-2:1.0: hub controller current requirement: 100mA
hub 1-2:1.0: local power source is lost (inactive)
hub 1-2:1.0: no over-current condition exists
hub 1-2:1.0: enabling power on all ports
hub 1-2:1.0: transfer --> -75
usb 1-2: control timeout on ep0in
--- unplug ---
drivers/usb/host/uhci-hcd.c: d400: suspend_hc
hub 1-2:1.0: hub_port_status failed (err = -110)
usb 1-2: control timeout on ep0in
hub 1-2:1.0: hub_port_status failed (err = -110)
usb 1-2: control timeout on ep0in
hub 1-2:1.0: hub_hub_status failed (err = -110)
hub 1-2:1.0: get_hub_status failed
hub 1-0:1.0: port 2, status 100, change 3, 12 Mb/s
hub 1-0:1.0: clear C_CONNECTION = 0
usb 1-2: USB disconnect, address 2
usb 1-2: usb_disable_device nuking all URBs
uhci_hcd 0000:00:04.2: shutdown urb d7ae6880 pipe 40408280 ep1in-intr
usb 1-2: unregistering interface 1-2:1.0
usb 1-2: hcd_unlink_urb d7ae6880 fail -16
usb 1-2: unregistering device
hub 1-0:1.0: port 2 enable change, status 100
That's good because it contains just the important information, and it's
short enough that you can easily paste it in an email message.
Okay, I've got another patch for you to try. It adds a little extra
diagnostic information to the previous patch (which it includes); I want
to be sure that the failure really does occur where I think it does.
Also, if you find that you still get alignment offsets when applying this
patch, you could put your original copy of drivers/usb/core/hub.c on your
web page. That way I'll be able to make patches against your version.
Alan Stern
--- 2.6/drivers/usb/core/hub.c.orig Fri Dec 19 10:55:07 2003
+++ 2.6/drivers/usb/core/hub.c Wed Dec 31 15:51:57 2003
@@ -855,6 +855,8 @@
wait_ms(HUB_DEBOUNCE_STEP);
ret = hub_port_status(hub, port, &portstatus, &portchange);
+ dev_dbg(hubdev(hub), "port_status= %d, port %d status %x change %x\n",
+ ret, port+1, portstatus, portchange);
if (ret < 0)
return -1;
@@ -869,7 +871,8 @@
connection = portstatus & USB_PORT_STAT_CONNECTION;
if ((portchange & USB_PORT_STAT_C_CONNECTION)) {
- clear_port_feature(hub, port+1, USB_PORT_FEAT_C_CONNECTION);
+ ret = clear_port_feature(hub, port+1,
USB_PORT_FEAT_C_CONNECTION);
+ dev_dbg(hubdev(hub), "clear C_CONNECTION2 = %d\n", ret);
}
}
@@ -893,7 +896,8 @@
port + 1, portstatus, portchange, portspeed (portstatus));
/* Clear the connection change status */
- clear_port_feature(hub, port + 1, USB_PORT_FEAT_C_CONNECTION);
+ i = clear_port_feature(hub, port + 1, USB_PORT_FEAT_C_CONNECTION);
+ dev_dbg(&hubstate->intf->dev, "clear C_CONNECTION1 = %d\n", i);
/* Disconnect any existing devices under this port */
if (hub->children[port])
@@ -1064,6 +1068,8 @@
for (i = 0; i < hub->descriptor->bNbrPorts; i++) {
ret = hub_port_status(dev, i, &portstatus, &portchange);
+ dev_dbg(hubdev(dev),
+ "intial port %d status: ret = %d\n", i+1, ret);
if (ret < 0) {
continue;
}
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
