[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.1705011348490.1893-100000@iolanthe.rowland.org>
Date: Mon, 1 May 2017 13:57:53 -0400 (EDT)
From: Alan Stern <stern@...land.harvard.edu>
To: Thomas Fjellstrom <thomas@...llstrom.ca>
cc: linux-usb@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: Asmedia USB 1343 crashes
On Mon, 1 May 2017, Thomas Fjellstrom wrote:
> On Monday, May 1, 2017 10:54:12 AM MDT Alan Stern wrote:
> > On Mon, 1 May 2017, Thomas Fjellstrom wrote:
> > > I've got a 970 Pro gaming aura motherboard with an Asmedia 1343 Usb 3.1
> > > controller. It's been consistently throwing errors and eventually crashing
> > > and becomming unresponsive.
> >
> > Maybe if you posted a kernel log showing those errors, people would
> > have a better idea of what's causing your problems.
>
> I was going to, but it seems I lost my previous log. I've searched through the
> system logs and haven't found a good clean set of logs, but I'll post what I
> have (at end of message), and later re-test with autosuspend on.
>
> > > Even just plugging in one device to the rear port will eventually cause
> > > the
> > > controller to die. Usually only takes a few hours for it to completely
> > > die.
> > >
> > >
> > > One of the errors that shows up consistently is:
> > >
> > > usbfs: process did not claim interface 0 before use
> >
> > This warning message is not related to the Asmedia controller. It
> > refers to some program running on the computer, and the same message
> > would appear no matter what sort of controller was being used.
>
> Ah. I figured since it was a kernel message, it was directly connected to the
> issues.
>
> > Alan Stern
> >
> [snip]
...
> [ 81.609260] usb 1-1.4: new high-speed USB device number 3 using xhci_hcd
> [ 81.701710] usb 1-1.4: New USB device found, idVendor=2109, idProduct=2812
> [ 81.701713] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> [ 81.701716] usb 1-1.4: Product: USB2.0 Hub
> [ 81.701717] usb 1-1.4: Manufacturer: VIA Labs, Inc.
> [ 81.702643] hub 1-1.4:1.0: USB hub found
> [ 81.702943] hub 1-1.4:1.0: 4 ports detected
> [ 81.918578] usb 2-1.4: new SuperSpeed USB device number 3 using xhci_hcd
> [ 82.166707] usb 2-1.4: New USB device found, idVendor=2109, idProduct=0812
> [ 82.166712] usb 2-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> [ 82.166714] usb 2-1.4: Product: USB3.0 Hub
> [ 82.166717] usb 2-1.4: Manufacturer: VIA Labs, Inc.
> [ 82.168062] hub 2-1.4:1.0: USB hub found
> [ 82.168743] hub 2-1.4:1.0: 4 ports detected
> [ 103.735979] usb 1-1.4.4: new high-speed USB device number 4 using xhci_hcd
> [ 103.826980] usb 1-1.4.4: New USB device found, idVendor=05c6, idProduct=9039
> [ 103.826985] usb 1-1.4.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> [ 103.826987] usb 1-1.4.4: Product: Android
> [ 103.826989] usb 1-1.4.4: Manufacturer: Android
> [ 103.826992] usb 1-1.4.4: SerialNumber: XH023891
> [ 103.852744] usb 1-1.4.4: usbfs: process 4360 (ThreadWeaver::T) did not claim interface 0 before use
> [ 103.930343] usb 1-1.4.4: reset high-speed USB device number 4 using xhci_hcd
> [ 104.021437] usb 1-1.4.4: usbfs: process 4360 (ThreadWeaver::T) did not claim interface 0 before use
> [ 104.098365] usb 1-1.4.4: reset high-speed USB device number 4 using xhci_hcd
[lots of resets and warnings cut out]
Well, this answers one question: The program not claiming interface 0
is ThreadWeaver::T, whatever that is. This isn't really an error, but
it is sloppy programming. You could report it to the maintainers of
that program.
The log shows a more or less constant series of warnings and resets as
long as the Android device is plugged in. This would explain any
unresponsiveness, although it doesn't explain eventual crashes.
If you know what that ThreadWeaver program is, and if you don't need
it, you could try disabling or removing it to see if the situation
improves.
Alan Stern
Powered by blists - more mailing lists