On Tue, Aug 11, 2015 at 12:31:47PM +0200, Yegor Yefremov wrote:
> On Tue, Aug 11, 2015 at 11:58 AM, Bjørn Mork <bjorn@xxxxxxx> wrote:
> > [replaced 'netdev' with 'linux-usb' as this concerns a USB serial driver only]
> >
> > Yegor Yefremov <yegorslists@xxxxxxxxxxxxxx> writes:
> >
> >> I have following problem. When removing USB dongle 07d1:3e01 or
> >> SierraWireless MC7304 I get following messages:
> >>
> >> option1 ttyUSB10: option_instat_callback: error -71
> >> option1 ttyUSB9: option_instat_callback: error -71
> >> option1 ttyUSB10: option_instat_callback: error -71
> >> option1 ttyUSB9: option_instat_callback: error -71
> >> option1 ttyUSB10: option_instat_callback: error -71
> >> option1 ttyUSB9: option_instat_callback: error -71
> >> INFO: rcu_sched detected stalls on CPUs/tasks: {} (detected by 0,
> >> t=2102 jiffies, g=694, c=693, q=24)
> >> INFO: Stall ended before state dump start
> >> option1 ttyUSB10: option_instat_callback: error -71
> >>
> >> drivers/usb/serial/option.c seems to make nothing with such a status
> >> and just prints error. How one would handle this properly and just
> >> unregister device? Do you need more info?
> >>
> >> Tested kernels: 3.18.20 and 4.2.0-rc5 (this kernel shows only RCU stall crash)
> >> Hardware: TI am335x
> >
> >
> > Isn't the device unregistered? What else can be done here?
>
> The problem is, that the system is dead (stall). It only prints
> "option1 ttyUSB10: option_instat_callback: error -71" endlessly
> (kernel 3.18.20) and console shows no reaction for input. And when you
> start watchdog from userspace the systems reboots after specified
> timeout (watchdog -t 5 -T 10 /dev/watchdog).
Related issues have been reported with musb (BeagleBone Black) and dwc
controllers (RPi) when using an external hub.
The exact reasons have not yet been fully determined, including whether
it is the hub driver that is prevented from processing the event or if
the disconnect event is never received at all. See for example:
https://lkml.kernel.org/r/20150409171314.GA30002@localhost
In the cases I've seen, changing the timing slightly was enough to make
the problem go away. Specifically, avoiding a large, unnecessary memcpy
or silencing an error message was sufficient.
This obviously does not solve the underlying issue, but could you try
the below patch nonetheless? We don't want these error messages for the
"valid" use case of removing an in-use device anyway.
Thanks,
Johan
>From 81913b6a91bd53b4f00455618c141c35148acbfc Mon Sep 17 00:00:00 2001
From: Johan Hovold <johan@xxxxxxxxxx>
Date: Mon, 17 Aug 2015 16:48:47 +0200
Subject: [PATCH] USB: option: silence interrupt errors
Avoid spamming the logs (e.g. with -EPROTO errors) when attempting to
resubmit the interrupt urb while a disconnect of an in-use device is
being processed.
Signed-off-by: Johan Hovold <johan@xxxxxxxxxx>
---
drivers/usb/serial/option.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 983c911b3986..3992f7709b70 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -1942,7 +1942,7 @@ static void option_instat_callback(struct urb *urb)
} else if (status == -ENOENT || status == -ESHUTDOWN) {
dev_dbg(dev, "%s: urb stopped: %d\n", __func__, status);
} else
- dev_err(dev, "%s: error %d\n", __func__, status);
+ dev_dbg(dev, "%s: error %d\n", __func__, status);
/* Resubmit urb so we continue receiving IRQ data */
if (status != -ESHUTDOWN && status != -ENOENT) {
--
2.4.6
--
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
