Date: Wed, 5 May 2004 17:39:39 -0400 From: "Rita Lin" <ritalin@comcast.net> To: <freebsd-hackers@freebsd.org> Subject: Is it possible to lose a xfer request queued using usbd_transfer()? Message-ID: <002701c432e9$783dc7a0$9402a8c0@emachine> References: <004c01c43053$2a775920$9402a8c0@emachine> <20040503120824.GG38488@cicely12.cicely.de> <008901c4314e$72b214e0$9402a8c0@emachine> <20040503211005.GJ38488@cicely12.cicely.de> <001a01c43156$bce21c60$9402a8c0@emachine> <20040503222538.GK38488@cicely12.cicely.de> <006f01c43160$b84a1220$9402a8c0@emachine> <20040503232850.GL38488@cicely12.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, I stumbled on a problem that I need some suggestion to continue tracking where the problem is. I started a tip session to the usb port, after typing two characters, any more input returned TS_BUSY. I noticed that this problem also exists when I do a 'cat junk > /dev/ucom0'. After two consecutive usbd_transfer(), it sits there. After some code tracking, I found that the ucomwritecb() for the third usbd_transfer() never gets called in uhci_idone(). I haven't dig further down yet. I'm going to do that tomorrow. If you have some idea, or have some suggestion how I can tackle this problem, please shine some light on me. The first two usbd_transfer are successful, and I could see the packets going out to the USB port with a USB analyzer. Thank you so much. Rita
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?002701c432e9$783dc7a0$9402a8c0>