Subject: kern/25041: USB isochronous transfers
To: None <email@example.com>
From: Iain Hibbert <firstname.lastname@example.org>
Date: 05/03/2006 17:16:09
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
I find when attempting to do USB isochronous transfers, the machine is
locking up in an interrupt loop. Well, I found the particular trouble, not
sure what to suggest about it, however.
in dev/usb/usbdi.c, function usb_transfer_complete() is called when a USB
transfer is complete, it does some cleanup, then calls the upper driver
xfer->callback(xfer, xfer->priv, xfer->status);
then it calls the lower device method done routine, to do some cleanup.
but in most cases so far as I can see (ugen and uaudio for isoc), the
callback function has already recycled the xfer. I wonder then, is it
supported to recycle the xfer in the callback function? There are several
PRs that seem to relate to this,
"USB isoc locks"
this relates to ohci.c but its the same issue, that the xfer has
been recycled. I guess that this PR should be closed, since the suggested
fix was actioned (ohci.c 1.150-1.151) some time ago.
"Isochronous USB transfers from ugen hang on DIAGNOSTIC"
this is the exact problem I have and so far as I can see, the
internals of the xfer structure are not relevant at this time (its on
queue rather than busy because its been requeued) so it makes no point to
act differently inside DIAGNOSTIC. My fix is attached, to remove that
"usb ugen(4) fix/enhancement"
this is where the fix for pr/22218 above came from.
"potential invalid memory access"
Another one that could probably be closed? the changes mentioned
here have already been actioned and he mentions the issue of the done
method touching the xfer though not quite in this context.
Looking deeper, ehci.c and ohci.c do nothing in the ->done function so
its not an issue there, but uhci.c uses it to cancel the interrupt, which
I guess is ok as its only queued at this stage and not actually active. It
definitely needs cancelling even though the xfer is queued again as when
it is not, the system locks up in an interrupt loop.
Now, I dont know if it can happen that the transfer can have passed
through the queue and be busy again at this point. If there is a USB
expert then maybe they could consider that?
I also wonder if it would be better to switch around the ->callback and
->done calls so that the upper layer is not called until the hardware is
finished? I dont know if that would be safe however, there may be other
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=diff
Content-Description: uhci.c diff
Content-Disposition: ATTACHMENT; FILENAME=diff