Re: [PATCH 2/2] staging: rts5139: Use correct USB transfer intervalto fix syslog spamming

From: Lutz Vieweg
Date: Tue Sep 17 2013 - 05:56:24 EST


On 06/03/2013 08:14 PM, Marcus Overhagen wrote:
Using correct transfer interval as specified by the USB endpoint
when doing the interrupt transfer fixes the warning printed by
xhci USB core on every transfer that resulted in spamming
"xhci_queue_intr_tx: 74 callbacks suppressed" to syslog
every 5 seconds.

Signed-off-by: Marcus Overhagen <marcus.overhagen@xxxxxxxxx>
---
drivers/staging/rts5139/rts51x_transport.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/rts5139/rts51x_transport.c b/drivers/staging/rts5139/rts51x_transport.c
index c573618..c172f4a 100644
--- a/drivers/staging/rts5139/rts51x_transport.c
+++ b/drivers/staging/rts5139/rts51x_transport.c
@@ -635,10 +635,10 @@ int rts51x_get_epc_status(struct rts51x_chip *chip, u16 *status)
ep = chip->usb->pusb_dev->ep_in[usb_pipeendpoint(pipe)];

/* fill and submit the URB */
- /* We set interval to 1 here, so the polling interval is controlled
- * by our polling thread */
+ /* Set interval to 10 here to match the endpoint descriptor,
+ * the polling interval is controlled by the polling thread */
usb_fill_int_urb(chip->usb->intr_urb, chip->usb->pusb_dev, pipe,
- status, 2, urb_done_completion, &urb_done, 1);
+ status, 2, urb_done_completion, &urb_done, 10);

result = rts51x_msg_common(chip, chip->usb->intr_urb, 100);

This change breaks the rts5139 driver for me: I have been using the
rts5139 driver with the built-in card reader of an Asus UX32VD (see
http://www.linlap.com/asus_ux32vd for all Details on that hardware)
and linux-3.8.8 successfully for quite a long time.

I recently upgraded to linux-3.11.1, which includes the above patch.

After upgrading I got I/O-errors like the following ones while reading -
when I just "dd" from the device to /dev/null, these errors occur
after transferring somewhere from ~700MB to ~7GB, and even though this
sounds like an erratic behaviour, it is perfectly reproducable every
time I just read continously from the device:

kernel: [ 1540.909901] sd 8:0:0:0: [sdc] Device not ready
kernel: [ 1540.909905] sd 8:0:0:0: [sdc]
kernel: [ 1540.909906] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
kernel: [ 1540.909908] sd 8:0:0:0: [sdc]
kernel: [ 1540.909909] Sense Key : Not Ready [current]
kernel: [ 1540.909912] sd 8:0:0:0: [sdc]
kernel: [ 1540.909915] Add. Sense: Medium not present
kernel: [ 1540.909917] sd 8:0:0:0: [sdc] CDB:
kernel: [ 1540.909918] Read(10): 28 00 00 0f 8d f0 00 00 10 00
kernel: [ 1540.909923] end_request: I/O error, dev sdc, sector 1019376
kernel: [ 1540.909926] quiet_error: 26 callbacks suppressed
kernel: [ 1540.909927] Buffer I/O error on device sdc, logical block 127422
kernel: [ 1540.909931] Buffer I/O error on device sdc, logical block 127423
kernel: [ 1540.909961] sd 8:0:0:0: [sdc] Device not ready
kernel: [ 1540.909963] sd 8:0:0:0: [sdc]
kernel: [ 1540.909963] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
kernel: [ 1540.909965] sd 8:0:0:0: [sdc]
kernel: [ 1540.909965] Sense Key : Not Ready [current]
kernel: [ 1540.909967] sd 8:0:0:0: [sdc]
kernel: [ 1540.909968] Add. Sense: Medium not present
kernel: [ 1540.909970] sd 8:0:0:0: [sdc] CDB:
kernel: [ 1540.909970] Read(10): 28 00 00 0f 8e 00 00 00 f0 00
kernel: [ 1540.909975] end_request: I/O error, dev sdc, sector 1019392
kernel: [ 1540.909976] Buffer I/O error on device sdc, logical block 127424
kernel: [ 1540.909977] Buffer I/O error on device sdc, logical block 127425
kernel: [ 1540.909978] Buffer I/O error on device sdc, logical block 127426
kernel: [ 1540.909980] Buffer I/O error on device sdc, logical block 127427
kernel: [ 1540.909981] Buffer I/O error on device sdc, logical block 127428
kernel: [ 1540.909982] Buffer I/O error on device sdc, logical block 127429
kernel: [ 1540.909983] Buffer I/O error on device sdc, logical block 127430
kernel: [ 1540.909985] Buffer I/O error on device sdc, logical block 127431

I verified, with different SDXC cards, that I reliably do not get these
errors when booting linux-3.8.8, then I reverted
status, 2, urb_done_completion, &urb_done, 10);
back into
status, 2, urb_done_completion, &urb_done, 1);
in the linux-3.11.1 source, and verified that then linux-3.11.1
works as good as linux-3.8.8 with the "dd to /dev/null" again, no more
I/O-errors like the above.
(BTW: The SDXC card I was using most was a SanDisk Extreme Pro 64GB SDXC.)

Your comment on the change says it is meant to get rid of syslog messages like:
"xhci_queue_intr_tx: 74 callbacks suppressed"
I do not have such messages, neither with or without the above change.

Regards,

Lutz Vieweg

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/