Pete,
On Dienstag, 24. Juli 2007, Pete Zaitcev wrote:
Please keep in mind that all this discussion about short reads has
nothing to do with your real problem (e.g. the device which used to
reply with a stall stopped to do so, or it continues to reply with a
stall token, but EHCI fails to
On Wed, 25 Jul 2007 08:30:40 +0200, Wolfgang Mües [EMAIL PROTECTED] wrote:
Pete,
On Dienstag, 24. Juli 2007, Pete Zaitcev wrote:
Please keep in mind that all this discussion about short reads has
nothing to do with your real problem (e.g. the device which used to
reply with a stall
On Tue, 24 Jul 2007 01:55:26 -0400, Pavel Roskin [EMAIL PROTECTED] wrote:
The driver stopped working after I upgraded from Linux 2.6.22 to Linux
2.6.23-rc1. No compile errors or warnings needed to be fixed.
I was able to check that the data buffer remains unchanged even though
the data size
On Tue, 24 Jul 2007, Pete Zaitcev wrote:
On Tue, 24 Jul 2007 01:55:26 -0400, Pavel Roskin [EMAIL PROTECTED] wrote:
The driver stopped working after I upgraded from Linux 2.6.22 to Linux
2.6.23-rc1. No compile errors or warnings needed to be fixed.
I was able to check that the data
Hi, Pete!
On Tue, 2007-07-24 at 13:09 -0700, Pete Zaitcev wrote:
On Tue, 24 Jul 2007 01:55:26 -0400, Pavel Roskin [EMAIL PROTECTED] wrote:
I was able to check that the data buffer remains unchanged even though
the data size is not 0. Actually, the return code is 0, which indicates
that 0
On Tue, 24 Jul 2007 16:26:30 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote:
2.6.23-rc1 has no apparent problem with control messages in ehci-hcd on
my machine. Is it possible that the device really has sent back 0
bytes?
usbmon might help here.
I didn't ask Pavel to run usbmon because
On Tue, 24 Jul 2007, Pavel Roskin wrote:
Hi, Pete!
On Tue, 2007-07-24 at 13:09 -0700, Pete Zaitcev wrote:
On Tue, 24 Jul 2007 01:55:26 -0400, Pavel Roskin [EMAIL PROTECTED] wrote:
I was able to check that the data buffer remains unchanged even though
the data size is not 0.
On Tuesday 24 July 2007, Pavel Roskin wrote:
The URB_SHORT_NOT_OK flag is not default. I don't remember exactly why.
I guess you mean that the temporary URB in usb_internal_control_msg()
should use that flag? That sounds like a good idea, at least on the
surface.
No it doesn't. It's
On Tue, 24 Jul 2007 16:28:15 -0400, Pavel Roskin [EMAIL PROTECTED] wrote:
It turns out usb_control_msg() returns 0 in two cases where it returns
-EPIPE in Linux 2.6.22.
This is significant. EPIPE is a stall, but zero bytes is zero bytes.
Normally they do not mix. If a device stalls a request,
On Tue, 24 Jul 2007, Pavel Roskin wrote:
However, I think it's wrong to return 0 if more than 0 bytes were
requested. usb_control_msg() is synchronous, and the caller is supposed
to wait for the data. If the function returns and the data is not
there, it should be an error IMHO.
No. The
On Tue, 2007-07-24 at 16:46 -0400, Alan Stern wrote:
I found the problem. Greg's urb-status conversion was somewhat hasty.
Here's an untested patch to fix it.
It's working, thank you!!!
--
Regards,
Pavel Roskin
-
On Tue, 24 Jul 2007 16:46:21 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote:
static int usb_start_wait_urb(struct urb *urb, int timeout, int
*actual_length)
{
- struct completion done;
+ struct api_context ctx;
unsigned long expire;
int retval;
- int status =
On Tue, 2007-07-24 at 13:52 -0700, Pete Zaitcev wrote:
On Tue, 24 Jul 2007 16:28:15 -0400, Pavel Roskin [EMAIL PROTECTED] wrote:
It turns out usb_control_msg() returns 0 in two cases where it returns
-EPIPE in Linux 2.6.22.
This is significant. EPIPE is a stall, but zero bytes is zero
On Tue, 24 Jul 2007, Pete Zaitcev wrote:
On Tue, 24 Jul 2007 16:46:21 -0400 (EDT), Alan Stern [EMAIL PROTECTED]
wrote:
static int usb_start_wait_urb(struct urb *urb, int timeout, int
*actual_length)
{
- struct completion done;
+ struct api_context ctx;
unsigned long
On Tue, 24 Jul 2007 18:18:04 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote:
static int usb_start_wait_urb(struct urb *urb, int timeout, int
*actual_length)
{
- int status = urb-status;
retval = usb_submit_urb(urb, GFP_NOIO);
Oh. My. God.
I'm not quite sure what to
Hello!
I'm trying to prepare an old driver for Atmel based USB 802.11b devices
for inclusion into the kernel. It still needs work on the 802.11 side,
but now USB is giving me headaches.
The driver stopped working after I upgraded from Linux 2.6.22 to Linux
2.6.23-rc1. No compile errors or
16 matches
Mail list logo
