On Wed, 21 Jan 2004, Axel Waggershauser wrote:
> > Are you saying that the problem comes up only
> > when you disconnect during your test transmission?
>
> Yes.
I get a definite feeling that your UHCI controllers don't work right
when nothing is plugged in to them.
> > Can you post your debugging log information, from when you start your test
> > up until shortly after the suspend_hc message?
>
> 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? And I wish I had asked you to put a
printk in uhci_urb_enqueue() so that we could see URBs being submitted as
well as finishing up. But that doesn't really matter...
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.
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.
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.
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.
> > If you have another USB device, you could try plugging it in and
> > unplugging it, to see what interrupts you get. I'm thinking that maybe
> > part of the trouble is caused by your test device, although I can't
> > imagine how.
>
> I used my USB mouse, plugged it in and unplugged. I disconnected the
> power of the machine beforehand and rebooted trying to make sure the
> controller hardware is not in some "ill" state. The result is as with my
> device: there is no uhci_irq call after the disconnect and still nothing
> after the suspend_hc.
This confirms what I wrote above. Your controllers are not behaving
according to the UHCI Specification, when nothing is plugged in to them.
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
static int debug = 1;
Alternatively, you could rmmod the uhci-hcd module and then modprobe it
again with "modprobe uhci-hcd debug=3".
Normally the controller will be suspended 1 second after you unplug the
device, but you can increase that delay by editing near line 2082, the
line after
uhci->state = UHCI_SUSPENDING_GRACE;
Change the next line from
uhci->state_end = jiffies + HZ;
to
uhci->state_end = jiffies + HZ*30;
and the delay will be increased to 30 seconds. That should give you
enough time to read the file contents. The file will indicate the
current settings in all the TDs (transaction descriptors) for your URB,
which should tell us what the controller thinks is going on.
Alan Stern
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
