On Wed, 2004-01-21 at 23:25, Alan Stern wrote:
> > It is attached. There are quite a lot non-problematic URB's to and from
> > the device before the interesting part begins. I need those to set up my
> > device.
>
> What are those "disable" messages?
hcd_endpoint_disable()
> Basically there are three strange things in your log.
>
> 1. The other controller (the one at address e800) keeps showing
> status = 32. That is not supposed to happen more than once. If you look
> at the beginning of uhci_irq(), you'll see that after status is read the
> driver then writes it back to the controller. The status register is
> defined in the UHCI Specification as read/write-clear, meaning that when
> you write a "1" to any bit in the register that bit will be cleared. So
> the 32 should be set back to 0 by the write. It's only supposed to get
> set to 32 at the time the controller stops -- and the driver isn't
> stopping the controller because it's _already_ stopped! So you should see
> a single interrupt with status = 32, and then any later interrupts should
> have status = 0.
I included an additional "inw(io_addr + USBSTS)" call right after the
"outw(status, io_addr + USBSTS);" line in uhci_irq to check weather the
read/write-clear mechanism is working at all. I made the observation
that it seems to work for some bits (at least for 0x1, 0x2 and 0x4 -
meaning the first three least significant bits) but not for the 0x20 bit
(the state = 32). I observed the transitions 1->0, 2->0, 3->0, 36->32
and 32->32.
> 2. When you unplug your device, the bulk-in transaction that is
> currently running should abort and complete with an error code -84
> (-EILSEQ). You said before that sometimes that happened. Well, it should
> always happen. When your computer sends an IN packet the device is
> supposed to respond with either NAK, STALL, DATA0, or DATA1 within a
> certain timeout. Since your device is unplugged it can't respond, so the
> computer tries again, up to 3 times. After 3 timeouts the controller is
> supposed to interrupt and signal a timeout error. That didn't happen in
> your log.
These news made me investigate some not yet mentioned aspect of the
"unplugging" process of my device. Due to the devices need for more
power than 500mA we had to provide external power which we just supplied
by cutting the host power supply and provide it external. The
"unplugging" I used to talk about is done by just switching the power
off. This is violating the spec, since the plugs are designed to make it
the other way round: first disconnect the data wires, than the power.
However tests with the correct unplugging method (pull the cable)
revealed that the problem is basically the same, just the statistics
"inverted" - meaning instead of say 1 of 10 tries of correct -84 results
and 9 unlink_urb failures, I get 9 correct runs and 1 failure.
> 3. When the controller is suspended or halted, it is supposed to
> generate an interrupt with status = 32, to let the driver know that the
> suspend has occurred. Your controller isn't doing that.
I tried another peace of hardware, a laptop with an Intel UHCI
controller. This machine is running with a vanilla 2.6.0 kernel. I just
added one printk to the uhci_irq() function. With respect to the
suspension behavior and the read/write-clear mechanism, it behaves
exactly like the other devices (see above). I made the "mouse
plug/unplug test". I did not test if the controller behaves differently
with my device than the others.
This lets me suspect that your information about the specification in
this regard is either wrong or a lot of hardware (at least 3 different
types) just violate the USB spec. One last possibility would probably be
that our device somehow trashed all that hardware, which is unlikely,
because we use it under Windows for about 5 years now.
The simple test I made just required one addition of a printk to
uhci_irq, maybe someone else could repeat that and try to backup your
statement.
> Also I suppose the reason we don't see any interrupts for the e800
> controller after you unplugged is because it shares the IRQ line with the
> e400 controller, and now neither of them is generating interrupt requests.
That means the second uhci_irq line I see is there because the kernel
interrupt handling code calls uhci_irq always for both controllers
because it does not know which one generated the interrupt. And the call
is not ignored because the write-clear mechanism does not affect the
0x20 bit?
> There's one more thing you could try testing: Set the debug level to 3 and
> read (and post!) the /proc/driver/uhci... file for your controller after
> unplugging but before the controller is suspended. You can set the debug
> level from 1 (the default) to 3 by editing the line that says
Attached is the result.
Thanks,
Axel
HC status
usbcmd = 00c1 Maxp64 CF RS
usbstat = 0000
usbint = 000f
usbfrnum = (0)4b8
flbaseadd = 0e31c000
sof = 40
stat1 = 0480
stat2 = 0580 LowSpeed
Frame List
Skeleton QH's
- skel_int128_qh
[cdeb4000] link (0deb4032) element (00000001)
urbp == NULL
- skel_int64_qh
[cdeb4030] link (0deb4062) element (00000001)
urbp == NULL
- skel_int32_qh
[cdeb4060] link (0deb4092) element (00000001)
urbp == NULL
- skel_int16_qh
[cdeb4090] link (0deb40c2) element (00000001)
urbp == NULL
- skel_int8_qh
[cdeb40c0] link (0deb40f2) element (00000001)
urbp == NULL
- skel_int4_qh
[cdeb40f0] link (0deb4122) element (00000001)
urbp == NULL
- skel_int2_qh
[cdeb4120] link (0deb4152) element (00000001)
urbp == NULL
- skel_int1_qh
[cdeb4150] link (0deb4182) element (00000001)
urbp == NULL
- skel_ls_control_qh
[cdeb4180] link (0deb41b2) element (00000001)
urbp == NULL
- skel_hs_control_qh
[cdeb41b0] link (0deb41e2) element (00000001)
urbp == NULL
- skel_bulk_qh
[cdeb41e0] link (0deb4212) element (00000001)
urbp == NULL
- skel_term_qh
[cdeb4210] link (00000001) element (0e340000)
urbp == NULL
Main list URBs: Empty
Remove list URBs:
1: urb_priv [ccad54a4] urb [cef0f0e0] qh [00000000] Dev=2 EP=4(IN) BLK FSBR_TO
Status=0 TDs=3984 queued URBs=0
Complete list URBs: Empty
