linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: A Sun <as1033x@comcast.net>
To: Sean Young <sean@mess.org>
Cc: linux-media@vger.kernel.org,
	Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Subject: Re: [PATCH 1/3] [media] mceusb: RX -EPIPE (urb status = -32) lockup failure fix
Date: Thu, 30 Mar 2017 12:35:17 -0400	[thread overview]
Message-ID: <58DD33C5.2020202@comcast.net> (raw)
In-Reply-To: <20170330071222.GA9579@gofer.mess.org>

On 3/30/2017 3:12 AM, Sean Young wrote:
> On Wed, Mar 29, 2017 at 06:04:58PM -0400, A Sun wrote:
>> On 3/29/2017 5:06 PM, Sean Young wrote:
>> <snip>
>>>
>>> Anyway, you're right and this patch looks ok. It would be nice to have the
>>> tx case handled too though.
>>>
>>> Thanks
>>> Sean
>>>
>>
>> Thanks; I'm looking at handling the tx case. If I can figure out the details, I'll post a new patch proposal separate, and likely dependent, on this one.
>>
>> My main obstacle at the moment, is I'm looking for a way to get mceusb device to respond with a USB TX error halt/stall (rather than the typical ACK and NAK) on a TX endpoint, in order to test halt/stall error detection and recovery for TX. ..A Sun
> 
> If you send IR, the drivers send a usb packet. However, the kernel will
> sleep for however long the IR is in ir_lirc_transmit_ir, so your other option
> is to set the transmit carrier repeatedly instead. You'd have to set the
> carrier to a different value every time.
> 
> 
> {
> 	int fd, carrier;
> 
> 	fd = open("/dev/lirc0", O_RDWR);
> 	carrier = 38000;
> 	for (;;) {
> 		ioctl(fd, LIRC_SET_SEND_CARRIER, &carrier);
> 		if (++carrier >= 40000)
> 			carrier = 38000;
> 	}
> }
> 
> 
> Sean
> 

Thanks, this is good to know, for testing where multiple TX I/Os are pending prior to fault. 

I found a way to set up the TX -EPIPE fault administratively:

	retval = usb_control_msg(ir->usbdev, usb_sndctrlpipe(ir->usbdev, 0),
		USB_REQ_SET_FEATURE, USB_RECIP_ENDPOINT,
		USB_ENDPOINT_HALT, usb_pipeendpoint(ir->pipe_out),
		NULL, 0, USB_CTRL_SET_TIMEOUT);
	dev_dbg(ir->dev, "set halt retval, %d", retval);
	
and have replications now for TX error and lock -out. Error occurs for every TX. No message flooding otherwise, as we expect. The RX side remains working.

...
[  249.986174] mceusb 1-1.2:1.0: requesting 38000 HZ carrier
[  249.986210] mceusb 1-1.2:1.0: send request called (size=0x4)
[  249.986256] mceusb 1-1.2:1.0: send request complete (res=0)
[  249.986403] mceusb 1-1.2:1.0: Error: request urb status = -32 (TX HALT)
[  249.999885] mceusb 1-1.2:1.0: send request called (size=0x3)
[  249.999929] mceusb 1-1.2:1.0: send request complete (res=0)
[  250.000013] mceusb 1-1.2:1.0: Error: request urb status = -32 (TX HALT)
[  250.019830] mceusb 1-1.2:1.0: send request called (size=0x21)
[  250.019868] mceusb 1-1.2:1.0: send request complete (res=0)
[  250.020007] mceusb 1-1.2:1.0: Error: request urb status = -32 (TX HALT)
...

  reply	other threads:[~2017-03-30 16:35 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-25 16:59 [PATCH] mceusb: RX -EPIPE lockup fault and more A Sun
2017-03-26 10:27 ` Sean Young
2017-03-26 16:36   ` [PATCH 0/3] [media] " A Sun
2017-03-26 18:28   ` [PATCH 1/3] [media] mceusb: RX -EPIPE (urb status = -32) lockup failure fix A Sun
2017-03-26 20:31     ` Sean Young
2017-03-27  8:18       ` A Sun
2017-03-28 20:25         ` Sean Young
2017-03-29  1:40           ` A Sun
2017-03-29 21:06             ` Sean Young
2017-03-29 22:04               ` A Sun
2017-03-30  7:12                 ` Sean Young
2017-03-30 16:35                   ` A Sun [this message]
2017-03-26 18:33   ` [PATCH 2/3] [media] mceusb: sporadic RX truncation corruption fix A Sun
2017-03-26 19:04   ` [PATCH 3/3] [media] mceusb: fix inaccurate debug buffer dumps,and misleading debug messages A Sun

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=58DD33C5.2020202@comcast.net \
    --to=as1033x@comcast.net \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@osg.samsung.com \
    --cc=sean@mess.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;
as well as URLs for NNTP newsgroup(s).