public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Lutz Vieweg <lvml@5t9.de>
To: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	devel@driverdev.osuosl.org
Subject: Re: [PATCH 2/2] staging: rts5139: Use correct USB transfer interval to fix syslog spamming
Date: Tue, 17 Sep 2013 11:56:07 +0200	[thread overview]
Message-ID: <52382737.7030608@5t9.de> (raw)
In-Reply-To: <1370283242-24434-3-git-send-email-marcus.overhagen@gmail.com>

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@gmail.com>
> ---
>   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


      reply	other threads:[~2013-09-17  9:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-03 18:14 [PATCH 0/2] staging: rts5139: Fix SD card reader for Samsung NP730U3E Marcus Overhagen
2013-06-03 18:14 ` [PATCH 1/2] staging: rts5139: Fix SD card detection on Samsung NP730U3E Ultrabook Marcus Overhagen
2013-06-03 18:14 ` [PATCH 2/2] staging: rts5139: Use correct USB transfer interval to fix syslog spamming Marcus Overhagen
2013-09-17  9:56   ` Lutz Vieweg [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52382737.7030608@5t9.de \
    --to=lvml@5t9.de \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox