Nikita V. Youshchenko wrote:
[..]
down (&usblp->sem);
[..]
Looks like (!usblp->wcomplete) was false, and (!usblp->present) was false,
and (usblp->writeurb->status != 0), so it just looped in this loop
forever, ignoring any signals.
[..]
Anyway. looks like some bug in the mentioned code? It's clear that
busy-loop is possible there. Maybe at least it should check for signals
after return from schedule()?
OK, here's a shot in the dark...
What if you, at least, replace the down() above with:
if (down_interruptible (&usblp->sem))
return -ERESTARTSYS;
Now you should be able to abort the cat.
However, the fact that usblp_check_status() ignores -ENODEV and returns
0 (OK) to usblp_write() is not really a hit. Imho usblp_write() should
get -ENODEV, release usblp->sem, drop everything and let the driver
clean up.
Regards
/Jocke
-------------------------------------------------------
This SF.net email is sponsored by: 2005 Windows Mobile Application Contest
Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones
for the chance to win $25,000 and application distribution. Enter today at
http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
