linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: A Sun <as1033x@comcast.net>
To: linux-media@vger.kernel.org
Cc: Sean Young <sean@mess.org>,
	Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Subject: [PATCH v1 3/3] [media] mceusb: Show USB halt/stall error recovery
Date: Sat, 1 Jun 2019 19:35:09 -0400	[thread overview]
Message-ID: <43f4ef6e-2c64-cd7a-26f7-3c1309b68936@comcast.net> (raw)
In-Reply-To: <999ae5cd-d72b-983f-2f96-5aaca72e8214@comcast.net>

Update dev_err() messages to report status (including success) for each
step of USB RX HALT and TX HALT error recovery. If error recovery fails,
show the message:
        stuck RX HALT state requires USB Reset Device to clear
or
        stuck TX HALT state requires USB Reset Device to clear

This and related message revisions pertain to functions:
        mceusb_defer_kevent()           error handler dispatcher
        mceusb_deferred_kevent()        error handler itself

This patch just affects RX and TX HALT error handling and recovery
reporting.

A possible future patch may enable the mceusb driver to attempt
itself usb_reset_device() when necessary.

---

As seen on very rare occasions with mceusb device 2304:0225
        [59388.696941] mceusb 1-1.1.2:1.0: Error: urb status = -32 (RX HALT)
        [59388.698838] mceusb 1-1.1.2:1.0: rx clear halt error -32
the device can get into RX or TX HALT state where usb_clear_halt()
also fails and also returns -EPIPE (HALT/STALL). After which,
all further mceusb device control and data I/O fails with HALT/STALL.
Cause and problem replication conditions are still unknown.

As seen in https://ubuntuforums.org/showthread.php?t=2406882
        ...
        mceusb 2-1.4:1.0: Error: urb status = -32 (RX HALT)
        ...
for an unknown mceusb device, usb_clear_halt() apparently can return
false success. After which, RX HALT immediately reoccurs resulting in
a RX halt and clear halt infinite loop and message flooding. Again,
cause and problem replication conditions remain unknown.

After observing a rx clear halt fault with mceusb 2304:0225, further
troubleshooting reveals usb_reset_device() is able to restore device
functionality.
        $ lsusb
        Bus 001 Device 010: ID 2304:0225 Pinnacle Systems, Inc. Remote Kit Infrared Transceiver
        ...
        $ sudo ./usbreset /dev/bus/usb/001/010  # ioctl(fd, USBDEVFS_RESET, 0);
        Resetting USB device /dev/bus/usb/001/010
        Reset successful
        $ dmesg
        ...
        [272392.540679] usb 1-1.2.7: reset full-speed USB device number 10 using dwc_otg
        [272392.676616] Registered IR keymap rc-rc6-mce
        ...
        [272392.678313] rc rc0: lirc_dev: driver ir-lirc-codec (mceusb) registered at minor = 0
        [272392.678616] mceusb 1-1.2.7:1.0: long-range (0x1) receiver active
        [272392.940671] mceusb 1-1.2.7:1.0: Registered Pinnacle Systems PCTV Remote USB with mce emulator interface version 1
        [272392.940687] mceusb 1-1.2.7:1.0: 2 tx ports (0x3 cabled) and 2 rx sensors (0x1 active)
        ...

Additional findings are "modprobe -r mceusb" and "modprobe mceusb"
are unable to clear stuck RX or TX HALT state.
Attempts to call usb_reset_endpoint() and usb_reset_configuration()
from within the mceusb driver also did not clear stuck HALTs.

A possible future patch could have the mceusb call usb_reset_device()
on itself, when necessary. Limiting the number of HALT error recovery
attempts may also be necessary to prevent halt/clear-halt loops.

Unresolved for now, deadlock complications occur if mceusb's worker
thread, mceusb_deferred_kevent(), calls usb_reset_device(),
which calls mceusb_dev_disconnect(), which calls cancel_work_sync(),
which waits on the still active worker thread.

Signed-off-by: A Sun <as1033x@comcast.net>
---
 drivers/media/rc/mceusb.c | 35 +++++++++++++++++++++++++----------
 1 file changed, 25 insertions(+), 10 deletions(-)

diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index efffb1795..5d81ccafc 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -765,7 +765,7 @@ static void mceusb_defer_kevent(struct mceusb_dev *ir, int kevent)
 {
 	set_bit(kevent, &ir->kevent_flags);
 	if (!schedule_work(&ir->kevent))
-		dev_err(ir->dev, "kevent %d may have been dropped", kevent);
+		dev_dbg(ir->dev, "kevent %d already scheduled", kevent);
 	else
 		dev_dbg(ir->dev, "kevent %d scheduled", kevent);
 }
@@ -1404,19 +1404,26 @@ static void mceusb_deferred_kevent(struct work_struct *work)
 		container_of(work, struct mceusb_dev, kevent);
 	int status;
 
+	dev_info(ir->dev, "kevent handler called (flags 0x%lx)",
+		 ir->kevent_flags);
+
 	if (test_bit(EVENT_RX_HALT, &ir->kevent_flags)) {
 		usb_unlink_urb(ir->urb_in);
 		status = usb_clear_halt(ir->usbdev, ir->pipe_in);
+		dev_err(ir->dev, "rx clear halt status = %d", status);
 		if (status < 0) {
-			dev_err(ir->dev, "rx clear halt error %d",
-				status);
-		}
-		clear_bit(EVENT_RX_HALT, &ir->kevent_flags);
-		if (status == 0) {
+			/*
+			 * Unable to clear RX stall/halt.
+			 * Will need to call usb_reset_device().
+			 */
+			dev_err(ir->dev,
+				"stuck RX HALT state requires USB Reset Device to clear");
+		} else {
+			clear_bit(EVENT_RX_HALT, &ir->kevent_flags);
 			status = usb_submit_urb(ir->urb_in, GFP_KERNEL);
 			if (status < 0) {
 				dev_err(ir->dev,
-					"rx unhalt submit urb error %d",
+					"rx unhalt submit urb error = %d",
 					status);
 			}
 		}
@@ -1424,9 +1431,17 @@ static void mceusb_deferred_kevent(struct work_struct *work)
 
 	if (test_bit(EVENT_TX_HALT, &ir->kevent_flags)) {
 		status = usb_clear_halt(ir->usbdev, ir->pipe_out);
-		if (status < 0)
-			dev_err(ir->dev, "tx clear halt error %d", status);
-		clear_bit(EVENT_TX_HALT, &ir->kevent_flags);
+		dev_err(ir->dev, "tx clear halt status = %d", status);
+		if (status < 0) {
+			/*
+			 * Unable to clear TX stall/halt.
+			 * Will need to call usb_reset_device().
+			 */
+			dev_err(ir->dev,
+				"stuck TX HALT state requires USB Reset Device to clear");
+		} else {
+			clear_bit(EVENT_TX_HALT, &ir->kevent_flags);
+		}
 	}
 }
 
-- 
2.11.0


  parent reply	other threads:[~2019-06-01 23:39 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <999ae5cd-d72b-983f-2f96-5aaca72e8214@comcast.net>
2019-06-01 23:34 ` [PATCH v1 1/3] [media] mceusb: Disable "nonsensical irdata" messages A Sun
2019-06-01 23:34 ` [PATCH v1 2/3] [media] mceusb: Reword messages referring to "urb" A Sun
2019-06-01 23:35 ` A Sun [this message]
2019-06-06  9:53   ` [PATCH v1 3/3] [media] mceusb: Show USB halt/stall error recovery Sean Young
2019-06-06 21:11     ` A Sun
2019-06-08  8:37       ` Sean Young
2019-06-09  0:56         ` A Sun
2019-06-19  7:53         ` [PATCH v2 0/3] [media] mceusb: Error message text revisions A Sun
2019-06-19  7:53         ` [PATCH v2 1/3] [media] mceusb: Disable "nonsensical irdata" messages A Sun
2019-06-19  7:54         ` [PATCH v2 2/3] [media] mceusb: Reword messages referring to "urb" A Sun
2019-06-25 10:51           ` Sean Young
2019-06-25 15:01             ` A Sun
2019-06-25 16:12               ` Sean Young
2019-06-25 21:29                 ` A Sun
2019-07-15 12:28                   ` Sean Young
2019-07-21 21:31                     ` A Sun
2019-08-10 12:17                       ` Sean Young
2019-06-19  7:54         ` [PATCH v2 3/3] [media] mceusb: Show USB halt/stall error recovery A Sun
2019-07-15  2:54           ` 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=43f4ef6e-2c64-cd7a-26f7-3c1309b68936@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).