Re: I'd like to donate a MacBook Pro
On Mon, May 01, 2017 at 12:27:41AM -0600, Alex Henrie wrote: > Dear kernel developers, > > I have a MacBookPro12,1 A1502 with a very annoying problem. Every time > it boots, the screen stays black for about 90 seconds, and the > keyboard is unresponsive for an additional 40 seconds. Both the > internal keyboard and (if present) external USB keyboard are > unresponsive. This is a big problem because I use LUKS full-disk > encryption, and I can't put in the password without the keyboard > working. On every boot, I get something like: > > starting version 232 > > A password is required to access the cryptroot volume: > Enter passphrase for /dev/sda4: [ 13.697887] usb 2-3: device not > accepting address 2, error -62 > [ 24.790929] usb2-3: device not accepting address 3, error -62 > [ 36.097301] usb2-3: device not accepting address 4, error -62 > [ 47.403659] usb2-3: device not accepting address 5, error -62 > [ 47.430395] usb2-port3: unable to enumerate USB device > > After the final error message, the keyboard starts working and I can > input my password. The dmesg log contains an additional error, > "xhci_hcd :00:14.0: Timeout while waiting for setup device > command", interspersed with the "device not accepting address" errors. > Resetting the SMC and the NVRAM did not help. > > I am confident that this is a common problem because I have found > various other users complaining about it: > > https://bbs.archlinux.org/viewtopic.php?pid=1613363#p1613363 > https://bbs.archlinux.org/viewtopic.php?pid=1451053#p1451053 > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1668105 > https://bugzilla.kernel.org/show_bug.cgi?id=115741 > > Mine is an older MacBook model that is not prohibitively expensive > (about 400 USD). Do any of you think that you can fix this bug? If so, > I would love to set up an identical model with an identical Arch Linux > configuration to my own and send it to you to keep and debug. You are not saying what kernel version you are using here, newer ones have fixed issues like this. Have you tried 4.10? 4.11? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Asmedia USB 1343 crashes
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. 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 Later on, devices start to throw errors and eventually everything goes away. A little while ago, I disabled usb autosuspend and things seem to be behaving. I'm currently running 4.11-rc7 but the issue appeared on several earlier kernels as well. -- Thomas Fjellstrom tho...@fjellstrom.ca -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: musb: musb_cppi41: Update an error message
Hi,
On Fri, Apr 28, 2017 at 06:04:54PM +0200, Alexandre Bailon wrote:
> If dma_request_slave_channel() failed to return a channel,
> then the driver will print an error and request to defer probe.
> Update the error message to explain we are defrering probe.
>
> Signed-off-by: Alexandre Bailon
> ---
> drivers/usb/musb/musb_cppi41.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/usb/musb/musb_cppi41.c b/drivers/usb/musb/musb_cppi41.c
> index e7c8b1b..e6b9161 100644
> --- a/drivers/usb/musb/musb_cppi41.c
> +++ b/drivers/usb/musb/musb_cppi41.c
> @@ -676,6 +676,7 @@ static int cppi41_dma_controller_start(struct
> cppi41_dma_controller *controller)
> dc = dma_request_slave_channel(dev->parent, str);
> if (!dc) {
> dev_err(dev, "Failed to request %s.\n", str);
> + dev_info(dev, "Deferring probe.\n");
Please merge the two lines above into one statement, using dev_info().
> ret = -EPROBE_DEFER;
> goto err;
> }
Regards,
-Bin.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Asmedia USB 1343 crashes
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. > 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. Alan Stern > Later on, devices start to throw errors and eventually everything goes away. > > A little while ago, I disabled usb autosuspend and things seem to be behaving. > > I'm currently running 4.11-rc7 but the issue appeared on several earlier > kernels as well. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Asmedia USB 1343 crashes
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] [0.00] Linux version 4.11.0-rc7 (moose@natasha) (gcc version 6.3.0 20170316 (Debian 6.3.0-9) ) #6 SMP PREEMPT Tue Apr 18 21:11:50 MDT 2017 [0.00] Command line: BOOT_IMAGE=/vmlinuz-4.11.0-rc7 root=/dev/mapper/natasha--vg-root ro radeon.dpm=0 amdgpu.dpm=0 panic=0 quiet resume=/dev/mapper/natasha--vg-swap_1 [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' [0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 [0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format. [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009] usable [0.00] BIOS-e820: [mem 0x0010-0xba4b2fff] usable [0.00] BIOS-e820: [mem 0xba4b3000-0xba8f7fff] reserved [0.00] BIOS-e820: [mem 0xba8f8000-0xba907fff] ACPI data [0.00] BIOS-e820: [mem 0xba908000-0xbb70afff] ACPI NVS [0.00] BIOS-e820: [mem 0xbb70b000-0xbc9c0fff] reserved [0.00] BIOS-e820: [mem 0xbc9c1000-0xbca34fff] type 20 [0.00] BIOS-e820: [mem 0xbca35000-0xbca35fff] usable [0.00] BIOS-e820: [mem 0xbca36000-0xbcc3bfff] ACPI NVS [0.00] BIOS-e820: [mem 0xbcc3c000-0xbd082fff] usable [0.00] BIOS-e820: [mem 0xbd083000-0xbd7f3fff] reserved [0.00] BIOS-e820: [mem 0xbd7f4000-0xbd7f] usable [0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfec1-0xfec10fff] reserved [0.00] BIOS-e820: [mem 0xfec2-0xfec20fff] reserved [0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] reserved [0.00] BIOS-e820: [mem 0xfed61000-0xfed70fff] reserved [0.00] BIOS-e820: [mem 0xfed8-0xfed8] reserved [0.00] BIOS-e820: [mem 0xfef0-0x] reserved [0.00] BIOS-e820: [mem 0x00011000-0x00083eff] usable [0.00] NX (Execute Disable) protection: active [0.00] efi: EFI v2.10 by American Megatrends [0.00] efi: ACPI=0xba8ff000 ACPI 2.0=0xba8ff000 SMBIOS=0xf04c0 [0.00] SMBIOS 2.7 present. [0.00] DMI: To be filled by O.E.M. To be filled by O.E.M./970 PRO GAMING/AURA, BIOS 0901 11/07/2016 [0.00] AGP: No AGP bridge found [0.00] e820: last_pfn = 0x83f000 max_arch_pfn = 0x4 [0.00] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WC UC- WT [0.00] e820: last_pfn = 0xbd800 max_arch_pfn = 0x4 [0.00] Scanning 1 areas for low memory corruption [0.00] Using GB pages for direct mapping [0.00] Secure boot could not be determined [0.00] RAMDISK: [mem 0x36365000-0x371a9fff] [0.00] ACPI: Early table checksum verification disabled [0.00] ACPI: RSDP 0xBA8FF000 24 (v02 ALASKA) [0.00] ACPI: XSDT 0xBA8FF078 64 (v01 ALASKA A M I 01072009 AMI 00010013) [0.00] ACPI: FACP 0xBA905F08 00010C (v05 ALASKA A M I 01072009 AMI 00010013) [0.00] ACPI BIOS Warning (bug): Optional FADT field Pm2ControlBlock has valid Length but zero Address: 0x/0x1 (20170119/tbfadt-658) [0.00] ACPI: DSDT 0xBA8FF
Re: USB-related lock inversion complaint
On Fri, 28 Apr 2017, Alan Stern wrote:
> On Fri, 28 Apr 2017, Bart Van Assche wrote:
>
> > Hello,
> >
> > Every time I boot a particular development server the complaint shown
> > below appears in the system log. I don't know when this behavior has
> > been introduced. But I noticed that I can reproduce this with older
> > kernel versions, e.g. 4.4.63. Does anyone know what is going on or how
> > to fix this?
> >
> > Thanks,
> >
> > Bart.
> >
> > usb 1-8: new low-speed USB device number 2 using xhci_hcd
> > usb 3-1: new high-speed USB device number 2 using ehci-pci
> >
> > =
> > [ INFO: possible irq lock inversion dependency detected ]
> > 4.11.0-rc8-dbg+ #1 Not tainted
> > -
> > swapper/7/0 just changed the state of lock:
> > �(&(&ehci->lock)->rlock){-.-...}, at: []
> > ehci_hrtimer_func+0x29/0xc0 [ehci_hcd]
> > but this lock took another, HARDIRQ-unsafe lock in the past:
> > �(hcd_urb_list_lock){+.}
> >
> >
> > and interrupts could create inverse lock ordering between them.
>
> I often find these lockdep splats difficult to understand. In this
> case, why does lockdep think hcd_urb_list_lock is hardirq-unsafe? It's
> supposed to be hardirq-safe.
Peter Zijlstra kindly provided the answer to my question off-list; see
below.
> > other info that might help us debug this:
> > �Possible interrupt unsafe locking scenario:
> >
> > ���CPU0CPU1
> > ���
> > � lock(hcd_urb_list_lock);
> > ���local_irq_disable();
> > ���lock(&(&ehci->lock)->rlock);
> > ���lock(hcd_urb_list_lock);
> > �
> > lock(&(&ehci->lock)->rlock);
> > �*** DEADLOCK ***
> >
> > no locks held by swapper/7/0.
> > the shortest dependencies between 2nd lock and 1st lock:
> > �-> (hcd_urb_list_lock){+.} ops: 252 {
> > HARDIRQ-ON-W at:
> > ��__lock_acquire+0x602/0x1280
> > ��lock_acquire+0xd5/0x1c0
> > ��_raw_spin_lock+0x2f/0x40
> > ��usb_hcd_unlink_urb_from_ep+0x1b/0x60 [usbcore]
> > ��xhci_giveback_urb_in_irq.isra.45+0x70/0x1b0 [xhci_hcd]
> > ��finish_td.constprop.60+0x1d8/0x2e0 [xhci_hcd]
> > ��xhci_irq+0xdd6/0x1fa0 [xhci_hcd]
> > ��usb_hcd_irq+0x26/0x40 [usbcore]
> > ��irq_forced_thread_fn+0x2f/0x70
> > ��irq_thread+0x149/0x1d0
> > ��kthread+0x113/0x150
> > ��ret_from_fork+0x2e/0x40
He wrote:
> There, that's where we hold the lock with interrupts enabled.
>
> So someone forced interrupt threading and the code assumes the interrupt
> code has IRQs disabled or something along those lines.
So we should be able to fix the problem by changing spin_lock/unlock in
xhci_irq() to spin_lock_irqsave/restore. Bart, please try out the
patch below.
Alan Stern
Index: usb-4.x/drivers/usb/host/xhci-ring.c
===
--- usb-4.x.orig/drivers/usb/host/xhci-ring.c
+++ usb-4.x/drivers/usb/host/xhci-ring.c
@@ -2628,26 +2628,27 @@ static int xhci_handle_event(struct xhci
irqreturn_t xhci_irq(struct usb_hcd *hcd)
{
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+ unsigned long flags;
u32 status;
u64 temp_64;
union xhci_trb *event_ring_deq;
dma_addr_t deq;
- spin_lock(&xhci->lock);
+ spin_lock_irqsave(&xhci->lock, flags);
/* Check if the xHC generated the interrupt, or the irq is shared */
status = readl(&xhci->op_regs->status);
if (status == 0x)
goto hw_died;
if (!(status & STS_EINT)) {
- spin_unlock(&xhci->lock);
+ spin_unlock_irqrestore(&xhci->lock, flags);
return IRQ_NONE;
}
if (status & STS_FATAL) {
xhci_warn(xhci, "WARNING: Host System Error\n");
xhci_halt(xhci);
hw_died:
- spin_unlock(&xhci->lock);
+ spin_unlock_irqrestore(&xhci->lock, flags);
return IRQ_HANDLED;
}
@@ -2679,7 +2680,7 @@ hw_died:
temp_64 = xhci_read_64(xhci, &xhci->ir_set->erst_dequeue);
xhci_write_64(xhci, temp_64 | ERST_EHB,
&xhci->ir_set->erst_dequeue);
- spin_unlock(&xhci->lock);
+ spin_unlock_irqrestore(&xhci->lock, flags);
return IRQ_HANDLED;
}
@@ -2707,7 +2708,7 @@ hw_died:
temp_64 |= ERST_EHB;
xhci_write_64(xhci, temp_64, &xhci->ir_set->erst_dequeue);
- spin_unlock(&xhci->lock);
+ spin_unlock_irqrestore(&xhci->lock, flags);
return IRQ_HANDLED;
}
--
To unsubscribe from this list: send the line "un
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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel / USB bug
Anyone ? Le 30/04/2017 à 18:34, Nicolas Repentin a écrit : > Hi all, > > I got some bugs on USB 3.0 storage. > > I've created a bugzilla here: > > https://bugzilla.kernel.org/show_bug.cgi?id=189631 > > Can you please help to correct this please? > > > It happens during transfers or big copies to the usb 3.0 storage drive. > > I still got the bug on Archlinux with kernel 4.10.11-1. > > > Thanks > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Asmedia USB 1343 crashes
On Monday, May 1, 2017 1:57:53 PM MDT Alan Stern wrote: > 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. I'm not sure what program that comes from either, I'll look it up. Something to note is that things work fine if suspend is disabled or using the regular usb 2 ports on my motherboard instead of the usb 3 ports. I also saw different error messages, much more severe ones that caused the xhci host to lock up completely and it didn't seem to need me to plug phones in to cause it. I'll follow up after i get it to happen again. > Alan Stern > > -- Thomas Fjellstrom tho...@fjellstrom.ca -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: musb: Fix trying to suspend while active for OTG configurations
On Wed, Apr 19, 2017 at 11:22:55AM +0300, Peter Ujfalusi wrote:
>
>
> On 2017-04-07 17:35, Tony Lindgren wrote:
> >Commit d8e5f0eca1e8 ("usb: musb: Fix hardirq-safe hardirq-unsafe
> >lock order error") caused a regression where musb keeps trying to
> >enable host mode with no cable connected. This seems to be caused
> >by the fact that now phy is enabled earlier, and we are wrongly
> >trying to force USB host mode on an OTG port. The errors we are
> >getting are "trying to suspend as a_idle while active".
> >
> >For ports configured as OTG, we should not need to do anything
> >to try to force USB host mode on it's OTG port. Trying to force host
> >mode in this case just seems to completely confuse the musb state
> >machine.
> >
> >Let's fix the issue by making musb_host_setup() attempt to force the
> >mode only if port_mode is configured for host mode.
>
> Tested-by: Peter Ujfalusi
>
> >
> >Fixes: d8e5f0eca1e8 ("usb: musb: Fix hardirq-safe hardirq-unsafe
> >lock order error")
> >Cc: Johan Hovold
> >Reported-by: Laurent Pinchart
> >Reported-by: Peter Ujfalusi
> >Tested-by: Peter Ujfalusi
> >Signed-off-by: Tony Lindgren
Applied. Thanks.
-Bin.
> >---
> > drivers/usb/musb/musb_host.c | 9 +
> > 1 file changed, 5 insertions(+), 4 deletions(-)
> >
> >diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
> >--- a/drivers/usb/musb/musb_host.c
> >+++ b/drivers/usb/musb/musb_host.c
> >@@ -2780,10 +2780,11 @@ int musb_host_setup(struct musb *musb, int
> >power_budget)
> > int ret;
> > struct usb_hcd *hcd = musb->hcd;
> >
> >-MUSB_HST_MODE(musb);
> >-musb->xceiv->otg->default_a = 1;
> >-musb->xceiv->otg->state = OTG_STATE_A_IDLE;
> >-
> >+if (musb->port_mode == MUSB_PORT_MODE_HOST) {
> >+MUSB_HST_MODE(musb);
> >+musb->xceiv->otg->default_a = 1;
> >+musb->xceiv->otg->state = OTG_STATE_A_IDLE;
> >+}
> > otg_set_host(musb->xceiv->otg, &hcd->self);
> > hcd->self.otg_port = 1;
> > musb->xceiv->otg->host = &hcd->self;
> >
>
> - Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB-related lock inversion complaint
On Mon, 2017-05-01 at 13:39 -0400, Alan Stern wrote: > On Fri, 28 Apr 2017, Alan Stern wrote: > > On Fri, 28 Apr 2017, Bart Van Assche wrote: > He wrote: > > > There, that's where we hold the lock with interrupts enabled. > > > > So someone forced interrupt threading and the code assumes the interrupt > > code has IRQs disabled or something along those lines. > > So we should be able to fix the problem by changing spin_lock/unlock in > xhci_irq() to spin_lock_irqsave/restore. Bart, please try out the > patch below. Hello Alan, Thanks for getting back to me and sorry that I forgot to mention that I had enabled interrupt threading. Is the patch you posted against a USB tree that is not yet upstream? It did not apply cleanly against kernel v4.11. But a backport of that patch to kernel v4.11 made the lock inversion complaints disappear so I think you can add: Tested-by: Bart Van Assche -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB-related lock inversion complaint
On Mon, 1 May 2017, Bart Van Assche wrote: > On Mon, 2017-05-01 at 13:39 -0400, Alan Stern wrote: > > On Fri, 28 Apr 2017, Alan Stern wrote: > > > On Fri, 28 Apr 2017, Bart Van Assche wrote: > > He wrote: > > > > > There, that's where we hold the lock with interrupts enabled. > > > > > > So someone forced interrupt threading and the code assumes the interrupt > > > code has IRQs disabled or something along those lines. > > > > So we should be able to fix the problem by changing spin_lock/unlock in > > xhci_irq() to spin_lock_irqsave/restore. Bart, please try out the > > patch below. > > Hello Alan, > > Thanks for getting back to me and sorry that I forgot to mention that I had > enabled interrupt threading. Is the patch you posted against a USB tree that > is not yet upstream? It did not apply cleanly against kernel v4.11. But a Actually, it was against an older kernel version. I haven't updated my source repository recently. > backport of that patch to kernel v4.11 made the lock inversion complaints > disappear so I think you can add: > > Tested-by: Bart Van Assche -- Okay, I will update the patch and submit it. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: xhci: fix lock-inversion problem
With threaded interrupts, bottom-half handlers are called with
interrupts enabled. Therefore they can't safely use spin_lock(); they
have to use spin_lock_irqsave(). Lockdep warns about a violation
occurring in xhci_irq():
=
[ INFO: possible irq lock inversion dependency detected ]
4.11.0-rc8-dbg+ #1 Not tainted
-
swapper/7/0 just changed the state of lock:
(&(&ehci->lock)->rlock){-.-...}, at: []
ehci_hrtimer_func+0x29/0xc0 [ehci_hcd]
but this lock took another, HARDIRQ-unsafe lock in the past:
(hcd_urb_list_lock){+.}
and interrupts could create inverse lock ordering between them.
other info that might help us debug this:
Possible interrupt unsafe locking scenario:
CPU0CPU1
lock(hcd_urb_list_lock);
local_irq_disable();
lock(&(&ehci->lock)->rlock);
lock(hcd_urb_list_lock);
lock(&(&ehci->lock)->rlock);
*** DEADLOCK ***
no locks held by swapper/7/0.
the shortest dependencies between 2nd lock and 1st lock:
-> (hcd_urb_list_lock){+.} ops: 252 {
HARDIRQ-ON-W at:
__lock_acquire+0x602/0x1280
lock_acquire+0xd5/0x1c0
_raw_spin_lock+0x2f/0x40
usb_hcd_unlink_urb_from_ep+0x1b/0x60 [usbcore]
xhci_giveback_urb_in_irq.isra.45+0x70/0x1b0 [xhci_hcd]
finish_td.constprop.60+0x1d8/0x2e0 [xhci_hcd]
xhci_irq+0xdd6/0x1fa0 [xhci_hcd]
usb_hcd_irq+0x26/0x40 [usbcore]
irq_forced_thread_fn+0x2f/0x70
irq_thread+0x149/0x1d0
kthread+0x113/0x150
ret_from_fork+0x2e/0x40
This patch fixes the problem.
Signed-off-by: Alan Stern
Reported-and-tested-by: Bart Van Assche
CC:
---
The backport to earlier kernel versions will be nontrivial, because
earlier versions of this routine included multiple spin_unlock() calls.
[as1825]
drivers/usb/host/xhci-ring.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Index: usb-4.x/drivers/usb/host/xhci-ring.c
===
--- usb-4.x.orig/drivers/usb/host/xhci-ring.c
+++ usb-4.x/drivers/usb/host/xhci-ring.c
@@ -2677,11 +2677,12 @@ irqreturn_t xhci_irq(struct usb_hcd *hcd
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
union xhci_trb *event_ring_deq;
irqreturn_t ret = IRQ_NONE;
+ unsigned long flags;
dma_addr_t deq;
u64 temp_64;
u32 status;
- spin_lock(&xhci->lock);
+ spin_lock_irqsave(&xhci->lock, flags);
/* Check if the xHC generated the interrupt, or the irq is shared */
status = readl(&xhci->op_regs->status);
if (status == ~(u32)0) {
@@ -2757,7 +2758,7 @@ irqreturn_t xhci_irq(struct usb_hcd *hcd
ret = IRQ_HANDLED;
out:
- spin_unlock(&xhci->lock);
+ spin_unlock_irqrestore(&xhci->lock, flags);
return ret;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression - Linux 4.9: ums_eneub6250 broken: transfer buffer not dma capable - Trace
On Wed, 26 Apr 2017, Andreas Hartmann wrote: > On 04/24/2017 at 10:39 PM Alan Stern wrote: > > On Sun, 23 Apr 2017, Andreas Hartmann wrote: > > > >> Am 23.04.2017 um 18:09 schrieb Alan Stern: > >>> On Sat, 22 Apr 2017, Andreas Hartmann wrote: > >>> > > In the meanwhile, I see another problem. The SCSI residue value is > > getting overwritten when new firmware is sent to the device. Like I > > said > > before, it's amazing this driver has ever worked. > > It depends on how you define "worked" ... > >>> > >>> How well _did_ it work in the past? > >> > >> As you already could see it: sometimes it has been working, sometimes > >> not. It's been just chance. I was hoping to get it fixed this way. > >> > >> Some time ago, there was a OS driver provided by the manufacturer (?) > >> (keucr), which worked without any problem (for me). But this driver was > >> removed in 3.17 [1] and replaced by this one. This driver _never_ worked > >> reliably. > > > > Ah. > > > >> I applied this new patch, too and attached the newly created debugs. But > >> first of all: you are great! The loading of the SD card now works as > >> expected! This is covered by the logfiles usb-ene-2*. It contains the > >> physical removing w/o loading the filesystem before (i.e. w/o mount / > >> unmount and remove procedure by software before) > > > > Well, the log does show that the patch wasn't quite correct. Below is > > an updated version. > > > >> The second pair of logfiles usb-ene-3* covers a *new* problem during > >> removing of SD cards via software after mount / umount. The problem is, > >> that on removing it via GUI, suddenly *3* device entries appear, which > >> could be activated (the same as the initial entry). After a few seconds, > >> 2 of them disappeared again and one stays. This happens with two > >> different SD cards here, another card doesn't show this problem. > >> > >> I would be very glad if you could fix this hopefully last issue, too :-) > >> (if it is a problem at all). > > > > It's possible that the updated patch will help with all those > > notifications. At least, the sense data should now be correct. > > > > As for the 3 device entries, I'm not sure where to look for them in > > your logs. > > The remove part should start in usb-ene-3.log.gz with > > [ 4261.261188] *** thread awakened Starting from that point, the log file shows four apparently successful writes, followed by what looks like a re-scan of the device and a bunch of reads. > In usb-ene-3.pcapng.gz it should start around package 2925. That is indeed where the disconnect first appears. > But to be honest - I'm missing some URB packages in the pcapng-file > which are reported in the log file: Between package 2924 and 2925 are > about 8s difference. I can't find this difference in the logfile. Is it > possible that there are some URBs not being sent out? No, your files are correct. The last READ command finishes at timestamp 4261.990022 in the log file (entry 2924 in the pcap file). Everything after that is ALLOW MEDIUM REMOVAL, REQUEST SENSE, and TEST UNIT READY until timestamp 4269.794577 (when the disconnect occurs), and for those commands the driver does not perform any communication with the device. Which for TEST UNIT READY, at least, is undoubtedly a bug. That command should return a failure if the card has been removed, and obviously it can't do that if it doesn't check with the device to see whether the card is still present. There's still no indication of three extra device entries anywhere. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[usb-host] question about pointer dereference before null check
Hello everybody, While taking a look into Coverity ID 100828 I ran into the following piece of code at drivers/usb/host/ehci-sched.c:1096: u32 addr; int think_time; int hs_transfers; addr = dev->ttport << 24; if (!ehci_is_TDI(ehci) || (dev->tt->hub != ehci_to_hcd(ehci)->self.root_hub)) addr |= dev->tt->hub->devnum << 16; addr |= epnum << 8; addr |= dev->devnum; stream->ps.usecs = HS_USECS_ISO(maxp); think_time = dev->tt ? dev->tt->think_time : 0; The issue here is that dev->tt is being dereferenced before null check. I was thinking on placing think_time = dev->tt ? dev->tt->think_time : 0; just before the _if_ statement. But this doesn't address the problem of dev->tt actually being NULL. While looking into the callers of the function containing this piece of code (iso_stream_init()) my impression is that dev->tt is not NULL at the time this function is called and, a very simple patch like the following can be applied in order to avoid the Coverity issue: -think_time = dev->tt ? dev->tt->think_time : 0; +think_time = dev->tt->think_time; But I can't tell for sure, so in case dev->tt is NULL, a good strategy to properly update the _addr_ variable would be needed. What do you think? I would really appreciate any comment on this, Thank you! -- Gustavo A. R. Silva -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: gadget: udc: add null check before pointer dereference
Add null check before dereferencing dev->regs pointer inside
net2280_led_shutdown() function.
Addresses-Coverity-ID: 101783
Signed-off-by: Gustavo A. R. Silva
---
drivers/usb/gadget/udc/net2280.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/udc/net2280.c b/drivers/usb/gadget/udc/net2280.c
index 3828c2e..1898a4b 100644
--- a/drivers/usb/gadget/udc/net2280.c
+++ b/drivers/usb/gadget/udc/net2280.c
@@ -3573,7 +3573,11 @@ static void net2280_remove(struct pci_dev *pdev)
BUG_ON(dev->driver);
/* then clean up the resources we allocated during probe() */
- net2280_led_shutdown(dev);
+
+ if (dev->regs) {
+ net2280_led_shutdown(dev);
+ iounmap(dev->regs);
+ }
if (dev->requests) {
int i;
for (i = 1; i < 5; i++) {
@@ -3588,8 +3592,6 @@ static void net2280_remove(struct pci_dev *pdev)
free_irq(pdev->irq, dev);
if (dev->quirks & PLX_PCIE)
pci_disable_msi(pdev);
- if (dev->regs)
- iounmap(dev->regs);
if (dev->region)
release_mem_region(pci_resource_start(pdev, 0),
pci_resource_len(pdev, 0));
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: musb: musb_cppi41: Update an error message
Hi Alexandre,
On Friday 28 April 2017 09:34 PM, Alexandre Bailon wrote:
> If dma_request_slave_channel() failed to return a channel,
> then the driver will print an error and request to defer probe.
> Update the error message to explain we are defrering probe.
>
> Signed-off-by: Alexandre Bailon
> ---
> drivers/usb/musb/musb_cppi41.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/usb/musb/musb_cppi41.c b/drivers/usb/musb/musb_cppi41.c
> index e7c8b1b..e6b9161 100644
> --- a/drivers/usb/musb/musb_cppi41.c
> +++ b/drivers/usb/musb/musb_cppi41.c
> @@ -676,6 +676,7 @@ static int cppi41_dma_controller_start(struct
> cppi41_dma_controller *controller)
> dc = dma_request_slave_channel(dev->parent, str);
> if (!dc) {
> dev_err(dev, "Failed to request %s.\n", str);
> + dev_info(dev, "Deferring probe.\n");
> ret = -EPROBE_DEFER;
> goto err;
> }
It looks like you will be better-off using dma_request_chan() instead so
you can get an error pointer back and not return -EPROBE_DEFER
irrespective of the actual error.
Thanks,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 3/3] USB3/DWC3: Enable undefined length INCR burst type
> -Original Message- > From: Felipe Balbi [mailto:ba...@kernel.org] > Sent: Friday, March 10, 2017 7:27 PM > To: Jerry Huang ; robh...@kernel.org; > mark.rutl...@arm.com; catalin.mari...@arm.com > Cc: linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org; > devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Rajesh > Bhagat > Subject: RE: [PATCH v4 3/3] USB3/DWC3: Enable undefined length INCR burst > type > > > Hi, > > Jerry Huang writes: > >> >> -- > >> >> 1.7.9.5 > >> > Hi, Balbi and all guys, > >> > Any comment for these patches? Can they be accepted? > >> > >> Rob had comments which you didn't reply yet. I cannot take this > >> patchset yet ;-) > >> > > Balbi, > > > > I look into his mail again, which was based v3, and I replied it. > > > > He had different understanding for undefined length burst mode. > > > > It seems he think for this mode, just setting bit[0] (INCRBrstEna) and > > don't need to set other field. > > > > However, according to the DWC USB3.0 controller databook, when it is > > undefined length INCR burst mode, we still need to set one max burst > > type, such as INCR8, which means controller will use any length less > > than or equal to this INCR8. > > Rob, do you agree with the patch now? > > -- > balbi Hi, Balbi, Any comment for these patches? Or any chance to merge them? -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: hub: judge BOS field in usb_reset_and_verify_device()
From: "Jianxing.Wang"
When notebook with intel-3165-wifi suspend and resume,crash for
udev->bos is NULL.
Signed-off-by: Jianxing.Wang
---
drivers/usb/core/hub.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 5286bf6..3b5493a 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4281,10 +4281,12 @@ static void hub_set_initial_usb2_lpm_policy(struct
usb_device *udev)
if (hub)
connect_type = hub->ports[udev->portnum - 1]->connect_type;
- if ((udev->bos->ext_cap->bmAttributes & cpu_to_le32(USB_BESL_SUPPORT))
||
- connect_type == USB_PORT_CONNECT_TYPE_HARD_WIRED) {
- udev->usb2_hw_lpm_allowed = 1;
- usb_set_usb2_hardware_lpm(udev, 1);
+ if (udev->bos != NULL) {
+ if ((udev->bos->ext_cap->bmAttributes &
cpu_to_le32(USB_BESL_SUPPORT)) ||
+ connect_type ==
USB_PORT_CONNECT_TYPE_HARD_WIRED) {
+ udev->usb2_hw_lpm_allowed = 1;
+ usb_set_usb2_hardware_lpm(udev, 1);
+ }
}
}
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
