On Sat, Jul 10, 2010 at 02:21:41PM -0400, Alan Stern wrote: > > The Rio Karma USB storage driver broke for me in recent kernels, while > > normal USB storage works fine. I bisected it back to this commit: > > > > commit 0ede76fcec5415ef82a423a95120286895822e2d > > In theory it could cause a problem, but I don't see how. More > debugging would help. > > What does usbmon reveal? Or CONFIG_USB_STORAGE_DEBUG? Good idea. I didn't save the output, but the 'dma already free' error happens in the error path after the initialization already failed, so that's probably a red herring. The transfer sequence looked like: send cmd 1 recv ack send cmd 2 recv -> -EPIPE The recv side isn't using us->iobuf after all, it's the second use of a driver-allocated buffer. This patch fixes it for me, what do you think? From: Bob Copeland <me@xxxxxxxxxxxxxxx> Date: Sun, 11 Jul 2010 09:21:56 -0400 Subject: [PATCH] usb: initialize transfer flags in usb storage Commit 0ede76fcec5415ef82a423a95120286895822e2d, "USB: remove uses of URB_NO_SETUP_DMA_MAP" introduced a regression by inadvertantly removing initialization of the transfer flags. This caused initialization failures in the ums-karma driver. Signed-off-by: Bob Copeland <me@xxxxxxxxxxxxxxx> --- drivers/usb/storage/transport.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/usb/storage/transport.c b/drivers/usb/storage/transport.c index 4471642..c17b7b0 100644 --- a/drivers/usb/storage/transport.c +++ b/drivers/usb/storage/transport.c @@ -142,6 +142,7 @@ static int usb_stor_msg_common(struct us_data *us, int timeout) us->current_urb->actual_length = 0; us->current_urb->error_count = 0; us->current_urb->status = 0; + us->current_urb->transfer_flags = 0; /* we assume that if transfer_buffer isn't us->iobuf then it * hasn't been mapped for DMA. Yes, this is clunky, but it's -- 1.6.3.3 -- Bob Copeland %% www.bobcopeland.com -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
