Re: possible xhci bug on linux-next
Hi, (Carlos, please Cc linux-omap on things related to OMAP :-) Mathias Nyman <mathias.ny...@intel.com> writes: > Adding Felipe, > > First warning is when dwc3_omap requests threaded irq > > On 14.06.2017 16:03, Carlos Hernandez wrote: >> linux-next fails to boot due to what appears to be a xhci bug. Problem >> observed at least on am57xx-evm, dra72x-evm and dra7xx-evm. According to >> Tony Lindgren the issue is marking a shared interrupt disabled on start-up. >> >> [0.00] Booting Linux on physical CPU 0x0 >> [0.00] Linux version 4.12.0-rc5-next-20170613 >> (lcpd...@dflsdit-build06.dal.design.ti.com) (gcc version 6.2.1 20161016 >> (Linaro GCC 6.2-2016.11) ) #2 SMP Tue Jun 13 13:52:56 CDT 2017 >> [0.00] CPU: ARMv7 Processor [412fc0f2] revision 2 (ARMv7), >> cr=10c5387d >> [0.00] CPU: div instructions available: patching division code >> [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction >> cache >> [0.00] OF: fdt: Machine model: TI AM5728 BeagleBoard-X15 >> [0.00] Memory policy: Data cache writealloc >> [0.00] cma: Reserved 24 MiB at 0xfe00 >> [0.00] OMAP4: Map 0xffd0 to fe60 for dram barrier >> [0.00] DRA752 ES1.1 >> [0.00] percpu: Embedded 17 pages/cpu @eed82000 s40936 r8192 d20504 >> u69632 >> [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total >> pages: 522047 >> [0.00] Kernel command line: console=ttyO2,115200n8 >> earlyprintk=serial,ttyO2,115200n8 rootwait sysrq_always_enabled >> ip=:eth0:dhcp root=/dev/nfs rw >> nfsroot=192.168.0.1:/home/tigtfarm03/NFS_exports/am57xx-evm1//autofs/d3fd317ecf18e621cf951fd5ef72179d,nolock,v3,tcp,rsize=4096,wsize=4096 >> [0.00] sysrq: sysrq always enabled. >> [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes) >> [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 >> bytes) >> [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) >> [0.00] Memory: 2025704K/2095100K available (9216K kernel code, 892K >> rwdata, 3176K rodata, 2048K init, 8710K bss, 44820K reserved, 24576K >> cma-reserved, 1284092K highmem) >> [0.00] Virtual kernel memory layout: >> [0.00] vector : 0x - 0x1000 ( 4 kB) >> [0.00] fixmap : 0xffc0 - 0xfff0 (3072 kB) >> [0.00] vmalloc : 0xf080 - 0xff80 ( 240 MB) >> [0.00] lowmem : 0xc000 - 0xf000 ( 768 MB) >> [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) >> [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) >> [0.00] .text : 0xc0008000 - 0xc0a0 (10208 kB) >> [0.00] .init : 0xc0e0 - 0xc100 (2048 kB) >> [0.00] .data : 0xc100 - 0xc10df398 ( 893 kB) >> [0.00].bss : 0xc10e90d0 - 0xc196aa80 (8711 kB) >> [0.00] Running RCU self tests >> [0.00] Hierarchical RCU implementation. >> [0.00] RCU event tracing is enabled. >> [0.00] RCU lockdep checking is enabled. >> [0.00] RCU callback double-/use-after-free debug enabled. >> [0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 >> [0.00] GIC: Using split EOI/Deactivate mode >> [0.00] kmemleak: Kernel memory leak detector disabled >> [0.00] OMAP clockevent source: timer1 at 32786 Hz >> [0.00] arch_timer: cp15 timer(s) running at 6.14MHz (phys). >> [0.00] clocksource: arch_sys_counter: mask: 0xff >> max_cycles: 0x16af5adb9, max_idle_ns: 440795202250 ns >> [0.06] sched_clock: 56 bits at 6MHz, resolution 162ns, wraps every >> 4398046511023ns >> [0.25] Switching to timer-based delay loop, resolution 162ns >> [0.000458] clocksource: 32k_counter: mask: 0x max_cycles: >> 0x, max_idle_ns: 58327039986419 ns >> [0.000474] OMAP clocksource: 32k_counter at 32768 Hz >> [0.001737] Console: colour dummy device 80x30 >> [0.001770] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., >> Ingo Molnar >> [0.001785] ... MAX_LOCKDEP_SUBCLASSES: 8 >> [0.001799] ... MAX_LOCK_DEPTH: 48 >> [0.001813] ... MAX_LOCKDEP_KEYS:8191 >> [0.001826] ... CLASSHASH_SIZE: 4096 >> [0.001840] ... MAX_LOCKDEP_ENTRIES: 32768 >> [0.001854] ... MAX_LOCKDEP_CHAINS: 65536 >> [0.001867] ... CHAINHASH_SIZE: 32
Re: possible xhci bug on linux-next
Adding Felipe, First warning is when dwc3_omap requests threaded irq On 14.06.2017 16:03, Carlos Hernandez wrote: linux-next fails to boot due to what appears to be a xhci bug. Problem observed at least on am57xx-evm, dra72x-evm and dra7xx-evm. According to Tony Lindgren the issue is marking a shared interrupt disabled on start-up. [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 4.12.0-rc5-next-20170613 (lcpd...@dflsdit-build06.dal.design.ti.com) (gcc version 6.2.1 20161016 (Linaro GCC 6.2-2016.11) ) #2 SMP Tue Jun 13 13:52:56 CDT 2017 [0.00] CPU: ARMv7 Processor [412fc0f2] revision 2 (ARMv7), cr=10c5387d [0.00] CPU: div instructions available: patching division code [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [0.00] OF: fdt: Machine model: TI AM5728 BeagleBoard-X15 [0.00] Memory policy: Data cache writealloc [0.00] cma: Reserved 24 MiB at 0xfe00 [0.00] OMAP4: Map 0xffd0 to fe60 for dram barrier [0.00] DRA752 ES1.1 [0.00] percpu: Embedded 17 pages/cpu @eed82000 s40936 r8192 d20504 u69632 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 522047 [0.00] Kernel command line: console=ttyO2,115200n8 earlyprintk=serial,ttyO2,115200n8 rootwait sysrq_always_enabled ip=:eth0:dhcp root=/dev/nfs rw nfsroot=192.168.0.1:/home/tigtfarm03/NFS_exports/am57xx-evm1//autofs/d3fd317ecf18e621cf951fd5ef72179d,nolock,v3,tcp,rsize=4096,wsize=4096 [0.00] sysrq: sysrq always enabled. [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Memory: 2025704K/2095100K available (9216K kernel code, 892K rwdata, 3176K rodata, 2048K init, 8710K bss, 44820K reserved, 24576K cma-reserved, 1284092K highmem) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xffc0 - 0xfff0 (3072 kB) [0.00] vmalloc : 0xf080 - 0xff80 ( 240 MB) [0.00] lowmem : 0xc000 - 0xf000 ( 768 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .text : 0xc0008000 - 0xc0a0 (10208 kB) [0.00] .init : 0xc0e0 - 0xc100 (2048 kB) [0.00] .data : 0xc100 - 0xc10df398 ( 893 kB) [0.00].bss : 0xc10e90d0 - 0xc196aa80 (8711 kB) [0.00] Running RCU self tests [0.00] Hierarchical RCU implementation. [0.00] RCU event tracing is enabled. [0.00] RCU lockdep checking is enabled. [0.00] RCU callback double-/use-after-free debug enabled. [0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 [0.00] GIC: Using split EOI/Deactivate mode [0.00] kmemleak: Kernel memory leak detector disabled [0.00] OMAP clockevent source: timer1 at 32786 Hz [0.00] arch_timer: cp15 timer(s) running at 6.14MHz (phys). [0.00] clocksource: arch_sys_counter: mask: 0xff max_cycles: 0x16af5adb9, max_idle_ns: 440795202250 ns [0.06] sched_clock: 56 bits at 6MHz, resolution 162ns, wraps every 4398046511023ns [0.25] Switching to timer-based delay loop, resolution 162ns [0.000458] clocksource: 32k_counter: mask: 0x max_cycles: 0x, max_idle_ns: 58327039986419 ns [0.000474] OMAP clocksource: 32k_counter at 32768 Hz [0.001737] Console: colour dummy device 80x30 [0.001770] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.001785] ... MAX_LOCKDEP_SUBCLASSES: 8 [0.001799] ... MAX_LOCK_DEPTH: 48 [0.001813] ... MAX_LOCKDEP_KEYS:8191 [0.001826] ... CLASSHASH_SIZE: 4096 [0.001840] ... MAX_LOCKDEP_ENTRIES: 32768 [0.001854] ... MAX_LOCKDEP_CHAINS: 65536 [0.001867] ... CHAINHASH_SIZE: 32768 [0.001880] memory used by lock dependency info: 5167 kB [0.001894] per task-struct memory footprint: 1536 bytes [0.003715] kmemleak: Early log buffer exceeded (9401), please increase DEBUG_KMEMLEAK_EARLY_LOG_SIZE [0.003751] Calibrating delay loop (skipped), value calculated using timer frequency.. 12.29 BogoMIPS (lpj=61475) [0.003779] pid_max: default: 32768 minimum: 301 [0.004258] Security Framework initialized [0.004448] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes) [0.004469] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes) [0.007060] CPU: Testing write buffer coherency: ok [0.008191] /cpus/cpu@0 missing clock-frequency property [0.008222] /cpus/cpu@1 missing clock-frequency property [0.008241] CPU0: thread -1, cpu 0
possible xhci bug on linux-next
linux-next fails to boot due to what appears to be a xhci bug. Problem observed at least on am57xx-evm, dra72x-evm and dra7xx-evm. According to Tony Lindgren the issue is marking a shared interrupt disabled on start-up. [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 4.12.0-rc5-next-20170613 (lcpd...@dflsdit-build06.dal.design.ti.com) (gcc version 6.2.1 20161016 (Linaro GCC 6.2-2016.11) ) #2 SMP Tue Jun 13 13:52:56 CDT 2017 [0.00] CPU: ARMv7 Processor [412fc0f2] revision 2 (ARMv7), cr=10c5387d [0.00] CPU: div instructions available: patching division code [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [0.00] OF: fdt: Machine model: TI AM5728 BeagleBoard-X15 [0.00] Memory policy: Data cache writealloc [0.00] cma: Reserved 24 MiB at 0xfe00 [0.00] OMAP4: Map 0xffd0 to fe60 for dram barrier [0.00] DRA752 ES1.1 [0.00] percpu: Embedded 17 pages/cpu @eed82000 s40936 r8192 d20504 u69632 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 522047 [0.00] Kernel command line: console=ttyO2,115200n8 earlyprintk=serial,ttyO2,115200n8 rootwait sysrq_always_enabled ip=:eth0:dhcp root=/dev/nfs rw nfsroot=192.168.0.1:/home/tigtfarm03/NFS_exports/am57xx-evm1//autofs/d3fd317ecf18e621cf951fd5ef72179d,nolock,v3,tcp,rsize=4096,wsize=4096 [0.00] sysrq: sysrq always enabled. [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Memory: 2025704K/2095100K available (9216K kernel code, 892K rwdata, 3176K rodata, 2048K init, 8710K bss, 44820K reserved, 24576K cma-reserved, 1284092K highmem) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xffc0 - 0xfff0 (3072 kB) [0.00] vmalloc : 0xf080 - 0xff80 ( 240 MB) [0.00] lowmem : 0xc000 - 0xf000 ( 768 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .text : 0xc0008000 - 0xc0a0 (10208 kB) [0.00] .init : 0xc0e0 - 0xc100 (2048 kB) [0.00] .data : 0xc100 - 0xc10df398 ( 893 kB) [0.00].bss : 0xc10e90d0 - 0xc196aa80 (8711 kB) [0.00] Running RCU self tests [0.00] Hierarchical RCU implementation. [0.00] RCU event tracing is enabled. [0.00] RCU lockdep checking is enabled. [0.00] RCU callback double-/use-after-free debug enabled. [0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 [0.00] GIC: Using split EOI/Deactivate mode [0.00] kmemleak: Kernel memory leak detector disabled [0.00] OMAP clockevent source: timer1 at 32786 Hz [0.00] arch_timer: cp15 timer(s) running at 6.14MHz (phys). [0.00] clocksource: arch_sys_counter: mask: 0xff max_cycles: 0x16af5adb9, max_idle_ns: 440795202250 ns [0.06] sched_clock: 56 bits at 6MHz, resolution 162ns, wraps every 4398046511023ns [0.25] Switching to timer-based delay loop, resolution 162ns [0.000458] clocksource: 32k_counter: mask: 0x max_cycles: 0x, max_idle_ns: 58327039986419 ns [0.000474] OMAP clocksource: 32k_counter at 32768 Hz [0.001737] Console: colour dummy device 80x30 [0.001770] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.001785] ... MAX_LOCKDEP_SUBCLASSES: 8 [0.001799] ... MAX_LOCK_DEPTH: 48 [0.001813] ... MAX_LOCKDEP_KEYS:8191 [0.001826] ... CLASSHASH_SIZE: 4096 [0.001840] ... MAX_LOCKDEP_ENTRIES: 32768 [0.001854] ... MAX_LOCKDEP_CHAINS: 65536 [0.001867] ... CHAINHASH_SIZE: 32768 [0.001880] memory used by lock dependency info: 5167 kB [0.001894] per task-struct memory footprint: 1536 bytes [0.003715] kmemleak: Early log buffer exceeded (9401), please increase DEBUG_KMEMLEAK_EARLY_LOG_SIZE [0.003751] Calibrating delay loop (skipped), value calculated using timer frequency.. 12.29 BogoMIPS (lpj=61475) [0.003779] pid_max: default: 32768 minimum: 301 [0.004258] Security Framework initialized [0.004448] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes) [0.004469] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes) [0.007060] CPU: Testing write buffer coherency: ok [0.008191] /cpus/cpu@0 missing clock-frequency property [0.008222] /cpus/cpu@1 missing clock-frequency property [0.008241] CPU0: thread -1, cpu 0, socket 0, mpidr 8000 [0.009506] Setting up static identity map for 0x8010 - 0x80100078 [0.010150
[xHCI bug report]: some USB3.0 devices will be re-enumerated immediately after we safely remove it(but not plug out the cable)
Hi All, On Intel Z77(Fresco xHCI host controller integrated) platform and VIA VT3456 platform, indeed with almost all the vendor's xHCI host controller, some USB3.0 storage devices, such as WD/HGST TURBO mobile MX3, will be re-enumerated immediately after we safely remove it in Ubuntu distributors and but don't plug out the cable. For safely removing, the sys file remove will be write and the usb_remove_device() routine will be called. In this case, xHCI driver places the port into disable state firstly and then set it to RxDetect state. After these settings with the issued devices, the link state will be U0, rather than Rxdetect/Polling, and then the device will be re-enumerated. Thanks a lot -- 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: [xHCI bug report]: some USB3.0 devices will be re-enumerated immediately after we safely remove it(but not plug out the cable)
Hi, Have you tried the latest kernel? Can below commit change anything? commit bb86cf569bbd7ad4dce581a37c7fbd748057e9dc Author: Gavin Guo gavin@canonical.com Date: Fri Jul 18 01:12:13 2014 +0800 usb: Check if port status is equal to RxDetect When using USB 3.0 pen drive with the [AMD] FCH USB XHCI Controller [1022:7814], the second hotplugging will experience the USB 3.0 pen drive is recognized as high-speed device. After bisecting the kernel, I found the commit number 41e7e056cdc662f704fa9262e5c6e213b4ab45dd (USB: Allow USB 3.0 ports to be disabled.) causes the bug. After doing some experiments, the bug can be fixed by avoiding executing the function hub_usb3_port_disable(). Because the port status with [AMD] FCH USB XHCI Controlleris [1022:7814] is already in RxDetect (I tried printing out the port status before setting to Disabled state), it's reasonable to check the port status before really executing hub_usb3_port_disable(). Fixes: 41e7e056cdc6 (USB: Allow USB 3.0 ports to be disabled.) Signed-off-by: Gavin Guo gavin@canonical.com Acked-by: Alan Stern st...@rowland.harvard.edu Cc: sta...@vger.kernel.org Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org Thanks, -baolu On 2014年11月24日 16:22, cobec...@via-alliance.com wrote: Hi All, On Intel Z77(Fresco xHCI host controller integrated) platform and VIA VT3456 platform, indeed with almost all the vendor's xHCI host controller, some USB3.0 storage devices, such as WD/HGST TURBO mobile MX3, will be re-enumerated immediately after we safely remove it in Ubuntu distributors and but don't plug out the cable. For safely removing, the sys file remove will be write and the usb_remove_device() routine will be called. In this case, xHCI driver places the port into disable state firstly and then set it to RxDetect state. After these settings with the issued devices, the link state will be U0, rather than Rxdetect/Polling, and then the device will be re-enumerated. Thanks a lot -- 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 -- 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: xHCI bug
Hi, On Fri, Nov 07, 2014 at 03:40:01PM +0200, Mathias Nyman wrote: On 07.11.2014 00:25, Felipe Balbi wrote: On Thu, Nov 06, 2014 at 10:36:30AM -0600, Felipe Balbi wrote: On Thu, Nov 06, 2014 at 06:31:20PM +0200, Mathias Nyman wrote: On 05.11.2014 21:28, Felipe Balbi wrote: Hi, On Tue, Oct 14, 2014 at 04:34:00PM +0300, Mathias Nyman wrote: Could you try with xhci debugging enabled? (will probably produce a lot of output) echo -n 'module xhci_hcd =p' /sys/kernel/debug/dynamic_debug/control I'll try, sure. I used tracing otherwise the problem wouldn't show up. Attached you can find output: 0b7e070de7b65de9f70805f4639b3e58 xhci-timeout-testusb.txt.gz Thanks, looks like we end up calling cleanup_halted_endpoint() a lot. This will (try to) reset the endpoint and move to handle the next TD (URB). This is called when we're processing contorl transfers and something out of the ordinary happends (returned STALL, BABBLE, and some other reasons) I need to dig a bit deeper to know what actually is going on. any news here ? It's been almost a month. While looking at this and other bugs I found races between reset endpoint, reset device, and set dequeue pointer commands. I suspect the loop in your logs is due to starting the endpoint ring too early after reset. It restarts before we move past the problematic TD, and start executing it again. The logs don't show why the TD fails in the first place, but I got another patch fixing other race issues which might help. Both patches are now in a reset-rework topic branch at: git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git reset-rework Its based on 3.18-rc2. I haven't still got or set up a usb device with gadget zero to test it out myself I'll try to run it today or tomorrow. seems to be working so far. It has been running for at least a couple hours. I'll leave it running until Monday or Tuesday before giving you a Tested-by, though. Thanks, much appreciated. Sounds promising so far, hope it lasts over the weekend Alright, it has been running for almost 4 days and failures so far: [1]+ ./test.sh # uptime 15:20:15 up 3 days, 20:08, 1 user, load average: 1.63, 1.84, 1.86 So, for both commits on reset-rework (see below), you can have my: Tested-by: Felipe Balbi ba...@ti.com 8--- commit d0a6a31173ccc49625c3e6e9e8a86e4a6e885ea6 Author: Mathias Nyman mathias.ny...@linux.intel.com Date: Thu Nov 6 18:06:09 2014 +0200 xhci: don't start a halted endpoint before its new dequeue is set A halted endpoint ring must first be reset, then move the ring dequeue pointer past the problematic TRB. If we start the ring too early after reset, but before moving the dequeue pointer we will end up executing the same problematic TRB again. As we always issue a set tranfer dequeue command after a reset endpoint command we can skip starting endpoint rings at reset endpoint command completion. Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com commit 117e8a66b8665a78a1eef1344c05901b1d94 Author: Mathias Nyman mathias.ny...@linux.intel.com Date: Tue Nov 4 19:00:47 2014 +0200 xhci: Don't set freed transfer dq pointers after device reset If an endpoint halts, or we want to cancel a URB, we need to modify TRBs on the endpoint ring. Before editing the trbs we need to stop the ring, and after editing, then restart the ring from a working place. Usually the next TD after the failed or cancelled one. If a reset device command is queued in the middle of this it will disable all endpoints and and free the rings. The Set transfer dequeue command queued after device reset will try to set invalid pointers. To avoid this we check if a unhandled device reset is queued before queuing a set transfer dequeue command, and make sure we clear endpoint state and stopped_td pointers after device reset. Also give back all the cancelled URBs from the old ring after device reset. Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com -- balbi signature.asc Description: Digital signature
Re: xHCI bug
On 07.11.2014 00:25, Felipe Balbi wrote: On Thu, Nov 06, 2014 at 10:36:30AM -0600, Felipe Balbi wrote: On Thu, Nov 06, 2014 at 06:31:20PM +0200, Mathias Nyman wrote: On 05.11.2014 21:28, Felipe Balbi wrote: Hi, On Tue, Oct 14, 2014 at 04:34:00PM +0300, Mathias Nyman wrote: Could you try with xhci debugging enabled? (will probably produce a lot of output) echo -n 'module xhci_hcd =p' /sys/kernel/debug/dynamic_debug/control I'll try, sure. I used tracing otherwise the problem wouldn't show up. Attached you can find output: 0b7e070de7b65de9f70805f4639b3e58 xhci-timeout-testusb.txt.gz Thanks, looks like we end up calling cleanup_halted_endpoint() a lot. This will (try to) reset the endpoint and move to handle the next TD (URB). This is called when we're processing contorl transfers and something out of the ordinary happends (returned STALL, BABBLE, and some other reasons) I need to dig a bit deeper to know what actually is going on. any news here ? It's been almost a month. While looking at this and other bugs I found races between reset endpoint, reset device, and set dequeue pointer commands. I suspect the loop in your logs is due to starting the endpoint ring too early after reset. It restarts before we move past the problematic TD, and start executing it again. The logs don't show why the TD fails in the first place, but I got another patch fixing other race issues which might help. Both patches are now in a reset-rework topic branch at: git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git reset-rework Its based on 3.18-rc2. I haven't still got or set up a usb device with gadget zero to test it out myself I'll try to run it today or tomorrow. seems to be working so far. It has been running for at least a couple hours. I'll leave it running until Monday or Tuesday before giving you a Tested-by, though. Thanks, much appreciated. Sounds promising so far, hope it lasts over the weekend -Mathias -- 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: xHCI bug
On 05.11.2014 21:28, Felipe Balbi wrote: Hi, On Tue, Oct 14, 2014 at 04:34:00PM +0300, Mathias Nyman wrote: Could you try with xhci debugging enabled? (will probably produce a lot of output) echo -n 'module xhci_hcd =p' /sys/kernel/debug/dynamic_debug/control I'll try, sure. I used tracing otherwise the problem wouldn't show up. Attached you can find output: 0b7e070de7b65de9f70805f4639b3e58 xhci-timeout-testusb.txt.gz Thanks, looks like we end up calling cleanup_halted_endpoint() a lot. This will (try to) reset the endpoint and move to handle the next TD (URB). This is called when we're processing contorl transfers and something out of the ordinary happends (returned STALL, BABBLE, and some other reasons) I need to dig a bit deeper to know what actually is going on. any news here ? It's been almost a month. While looking at this and other bugs I found races between reset endpoint, reset device, and set dequeue pointer commands. I suspect the loop in your logs is due to starting the endpoint ring too early after reset. It restarts before we move past the problematic TD, and start executing it again. The logs don't show why the TD fails in the first place, but I got another patch fixing other race issues which might help. Both patches are now in a reset-rework topic branch at: git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git reset-rework Its based on 3.18-rc2. I haven't still got or set up a usb device with gadget zero to test it out myself -Mathias -- 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: xHCI bug
On Thu, Nov 06, 2014 at 06:31:20PM +0200, Mathias Nyman wrote: On 05.11.2014 21:28, Felipe Balbi wrote: Hi, On Tue, Oct 14, 2014 at 04:34:00PM +0300, Mathias Nyman wrote: Could you try with xhci debugging enabled? (will probably produce a lot of output) echo -n 'module xhci_hcd =p' /sys/kernel/debug/dynamic_debug/control I'll try, sure. I used tracing otherwise the problem wouldn't show up. Attached you can find output: 0b7e070de7b65de9f70805f4639b3e58 xhci-timeout-testusb.txt.gz Thanks, looks like we end up calling cleanup_halted_endpoint() a lot. This will (try to) reset the endpoint and move to handle the next TD (URB). This is called when we're processing contorl transfers and something out of the ordinary happends (returned STALL, BABBLE, and some other reasons) I need to dig a bit deeper to know what actually is going on. any news here ? It's been almost a month. While looking at this and other bugs I found races between reset endpoint, reset device, and set dequeue pointer commands. I suspect the loop in your logs is due to starting the endpoint ring too early after reset. It restarts before we move past the problematic TD, and start executing it again. The logs don't show why the TD fails in the first place, but I got another patch fixing other race issues which might help. Both patches are now in a reset-rework topic branch at: git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git reset-rework Its based on 3.18-rc2. I haven't still got or set up a usb device with gadget zero to test it out myself I'll try to run it today or tomorrow. -- balbi signature.asc Description: Digital signature
Re: xHCI bug
On Thu, Nov 06, 2014 at 10:36:30AM -0600, Felipe Balbi wrote: On Thu, Nov 06, 2014 at 06:31:20PM +0200, Mathias Nyman wrote: On 05.11.2014 21:28, Felipe Balbi wrote: Hi, On Tue, Oct 14, 2014 at 04:34:00PM +0300, Mathias Nyman wrote: Could you try with xhci debugging enabled? (will probably produce a lot of output) echo -n 'module xhci_hcd =p' /sys/kernel/debug/dynamic_debug/control I'll try, sure. I used tracing otherwise the problem wouldn't show up. Attached you can find output: 0b7e070de7b65de9f70805f4639b3e58 xhci-timeout-testusb.txt.gz Thanks, looks like we end up calling cleanup_halted_endpoint() a lot. This will (try to) reset the endpoint and move to handle the next TD (URB). This is called when we're processing contorl transfers and something out of the ordinary happends (returned STALL, BABBLE, and some other reasons) I need to dig a bit deeper to know what actually is going on. any news here ? It's been almost a month. While looking at this and other bugs I found races between reset endpoint, reset device, and set dequeue pointer commands. I suspect the loop in your logs is due to starting the endpoint ring too early after reset. It restarts before we move past the problematic TD, and start executing it again. The logs don't show why the TD fails in the first place, but I got another patch fixing other race issues which might help. Both patches are now in a reset-rework topic branch at: git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git reset-rework Its based on 3.18-rc2. I haven't still got or set up a usb device with gadget zero to test it out myself I'll try to run it today or tomorrow. seems to be working so far. It has been running for at least a couple hours. I'll leave it running until Monday or Tuesday before giving you a Tested-by, though. -- balbi signature.asc Description: Digital signature
Re: xHCI bug
Hi, On Tue, Oct 14, 2014 at 04:34:00PM +0300, Mathias Nyman wrote: Could you try with xhci debugging enabled? (will probably produce a lot of output) echo -n 'module xhci_hcd =p' /sys/kernel/debug/dynamic_debug/control I'll try, sure. I used tracing otherwise the problem wouldn't show up. Attached you can find output: 0b7e070de7b65de9f70805f4639b3e58 xhci-timeout-testusb.txt.gz Thanks, looks like we end up calling cleanup_halted_endpoint() a lot. This will (try to) reset the endpoint and move to handle the next TD (URB). This is called when we're processing contorl transfers and something out of the ordinary happends (returned STALL, BABBLE, and some other reasons) I need to dig a bit deeper to know what actually is going on. any news here ? It's been almost a month. cheers -- balbi signature.asc Description: Digital signature
Re: xHCI bug
On 13.10.2014 18:55, Felipe Balbi wrote: Hi, On Mon, Oct 13, 2014 at 09:22:46AM -0500, Felipe Balbi wrote: Could you try with xhci debugging enabled? (will probably produce a lot of output) echo -n 'module xhci_hcd =p' /sys/kernel/debug/dynamic_debug/control I'll try, sure. I used tracing otherwise the problem wouldn't show up. Attached you can find output: 0b7e070de7b65de9f70805f4639b3e58 xhci-timeout-testusb.txt.gz Thanks, looks like we end up calling cleanup_halted_endpoint() a lot. This will (try to) reset the endpoint and move to handle the next TD (URB). This is called when we're processing contorl transfers and something out of the ordinary happends (returned STALL, BABBLE, and some other reasons) I need to dig a bit deeper to know what actually is going on. -Mathias -- 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: xHCI bug
Hi
On 10.10.2014 21:47, Felipe Balbi wrote:
Hi Mathias,
I seem to be able to rather easily kill xHCI by just running
test.sh/testusb with a USB2 device attached to it (I used my AM437x
Starter Kit for the test).
I noticed that after not too long, all tests started failing (see below)
but using ehci, it works just fine (afaicr).
Here's a snippet of the hang, but it has been running for a while and
before testusb I ran over 24 hours of MSC testing, also passed full
USB20CV and USB30CV with g_mass_storage and g_zero (and most other
gadget drivers too):
Ouch, I don't have a proper device in my office to run testusb with, I probably
should set up one here.
(If I understood correctly any device able to use g_zero should work?)
Could you try with xhci debugging enabled? (will probably produce a lot of
output)
echo -n 'module xhci_hcd =p' /sys/kernel/debug/dynamic_debug/control
[874685.176903] usbtest 1-7:3.0: Linux gadget zero
[874685.176906] usbtest 1-7:3.0: high-speed {control in/out bulk-in bulk-out}
tests (+alt)
[874703.140258] usbtest 1-7:3.0: TEST 9: ch9 (subset) control tests, 5000
times
[874723.716857] usbtest 1-7:3.0: TEST 10: queue 32 control calls, 5000 times
[874743.773236] usbtest 1-7:3.0: TEST 14: 15000 ep0out, 1..256 vary 1
[874748.774291] usbtest 1-7:3.0: ctrl_out write failed, code -110, count 0
[874754.297205] usbtest 1-7:3.0: set altsetting to 0 failed, -110
Timeout?
...
[874790.680681] xhci_hcd :00:14.0: URB transfer length is wrong, xHC
issue? req. len = 0, act. len = 4294967288
Hmm, act. len value looks awfully close to full 32 bit, driver might be
wrapping around something here.
-Mathias
--
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: xHCI bug
On 10.10.2014 22:01, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [141010 11:51]: Hi again, On Fri, Oct 10, 2014 at 01:47:55PM -0500, Felipe Balbi wrote: I seem to be able to rather easily kill xHCI by just running test.sh/testusb with a USB2 device attached to it (I used my AM437x Starter Kit for the test). I think Tony mentioned taht it's also pretty easy to break xHCI by trying to cold flash an old N900 Heh yeah. After upgrading my build box, I noticed few things. The new mobo came with xchi, and the following broke: 1. My old printer MFC-7820N no longer worked for scanning 2. Trying to cold flash any omap3 boards over USB stopped working for most of the time 3. Back-ups to a USB drive occasionally started failing 4. After disabling xhci in the BIOS, things were still flakey with ehci 5. I ended up installing a usb2.0 ehci pcie card to fix things Hmm, sounds like it might not only be a xhci issue then. If you for some reason want to enable xhci and try coldflashing n900/use scanner could you enable xhci debugging and send me the output of a failing case? echo -n 'module xhci_hcd =p' /sys/kernel/debug/dynamic_debug/control -Mathias -- 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: xHCI bug
On Mon, Oct 13, 2014 at 03:38:24PM +0300, Mathias Nyman wrote:
Hi
On 10.10.2014 21:47, Felipe Balbi wrote:
Hi Mathias,
I seem to be able to rather easily kill xHCI by just running
test.sh/testusb with a USB2 device attached to it (I used my AM437x
Starter Kit for the test).
I noticed that after not too long, all tests started failing (see below)
but using ehci, it works just fine (afaicr).
Here's a snippet of the hang, but it has been running for a while and
before testusb I ran over 24 hours of MSC testing, also passed full
USB20CV and USB30CV with g_mass_storage and g_zero (and most other
gadget drivers too):
Ouch, I don't have a proper device in my office to run testusb with, I
probably should set up one here.
(If I understood correctly any device able to use g_zero should work?)
correct, anything that can run g_zero.
Could you try with xhci debugging enabled? (will probably produce a
lot of output)
echo -n 'module xhci_hcd =p' /sys/kernel/debug/dynamic_debug/control
I'll try, sure.
[874685.176903] usbtest 1-7:3.0: Linux gadget zero
[874685.176906] usbtest 1-7:3.0: high-speed {control in/out bulk-in
bulk-out} tests (+alt)
[874703.140258] usbtest 1-7:3.0: TEST 9: ch9 (subset) control tests, 5000
times
[874723.716857] usbtest 1-7:3.0: TEST 10: queue 32 control calls, 5000
times
[874743.773236] usbtest 1-7:3.0: TEST 14: 15000 ep0out, 1..256 vary 1
[874748.774291] usbtest 1-7:3.0: ctrl_out write failed, code -110, count 0
[874754.297205] usbtest 1-7:3.0: set altsetting to 0 failed, -110
Timeout?
yeah, testusb won't wait forever :-)
[874790.680681] xhci_hcd :00:14.0: URB transfer length is wrong, xHC
issue? req. len = 0, act. len = 4294967288
Hmm, act. len value looks awfully close to full 32 bit, driver might be
wrapping around something here.
true.
--
balbi
signature.asc
Description: Digital signature
xHCI bug
Hi Mathias,
I seem to be able to rather easily kill xHCI by just running
test.sh/testusb with a USB2 device attached to it (I used my AM437x
Starter Kit for the test).
I noticed that after not too long, all tests started failing (see below)
but using ehci, it works just fine (afaicr).
Here's a snippet of the hang, but it has been running for a while and
before testusb I ran over 24 hours of MSC testing, also passed full
USB20CV and USB30CV with g_mass_storage and g_zero (and most other
gadget drivers too):
[874685.176903] usbtest 1-7:3.0: Linux gadget zero
[874685.176906] usbtest 1-7:3.0: high-speed {control in/out bulk-in bulk-out}
tests (+alt)
[874703.140258] usbtest 1-7:3.0: TEST 9: ch9 (subset) control tests, 5000 times
[874723.716857] usbtest 1-7:3.0: TEST 10: queue 32 control calls, 5000 times
[874743.773236] usbtest 1-7:3.0: TEST 14: 15000 ep0out, 1..256 vary 1
[874748.774291] usbtest 1-7:3.0: ctrl_out write failed, code -110, count 0
[874754.297205] usbtest 1-7:3.0: set altsetting to 0 failed, -110
[874759.819703] usbtest 1-7:3.0: set altsetting to 0 failed, -110
[874765.341962] usbtest 1-7:3.0: set altsetting to 0 failed, -110
[874765.863127] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874766.383337] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874766.903526] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874767.423750] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874767.943965] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874768.464174] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874768.988078] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874769.376451] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874769.896675] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874770.416920] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874770.937170] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874771.306870] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874771.829525] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874772.349723] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874772.870041] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874773.363080] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874773.866381] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874774.386594] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874774.910836] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874775.431062] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874775.951018] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874776.347478] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874776.867690] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874777.387859] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874777.911980] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874778.432250] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874778.952692] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874779.472784] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874780.008646] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874780.528880] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874780.925468] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874781.297533] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874781.817776] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874782.341828] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874782.862237] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874783.382444] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874783.902684] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874784.430835] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874784.954964] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874785.475225] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874785.999464] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874786.519801] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874787.039882] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874787.560232] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874788.080327] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874788.600517] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874789.120687] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874789.641042] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874790.161156] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874790.680681] xhci_hcd :00:14.0: URB transfer length is wrong, xHC issue?
req. len = 0, act. len = 4294967288
[874790.680707] usbtest 1-7:3.0: TEST 1: write 2048 bytes 5000 times
[874800.683902] usb 1-7: test1 failed, iterations left 4999, status -110 (not 0)
[874801.205807] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874801.726028] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874802.246264] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874802.770493] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874803.290302] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874803.810881] usbtest 1-7:3.0: set altsetting to 0
Re: xHCI bug
Hi again, On Fri, Oct 10, 2014 at 01:47:55PM -0500, Felipe Balbi wrote: I seem to be able to rather easily kill xHCI by just running test.sh/testusb with a USB2 device attached to it (I used my AM437x Starter Kit for the test). I think Tony mentioned taht it's also pretty easy to break xHCI by trying to cold flash an old N900 -- balbi signature.asc Description: Digital signature
Re: xHCI bug
* Felipe Balbi ba...@ti.com [141010 11:51]: Hi again, On Fri, Oct 10, 2014 at 01:47:55PM -0500, Felipe Balbi wrote: I seem to be able to rather easily kill xHCI by just running test.sh/testusb with a USB2 device attached to it (I used my AM437x Starter Kit for the test). I think Tony mentioned taht it's also pretty easy to break xHCI by trying to cold flash an old N900 Heh yeah. After upgrading my build box, I noticed few things. The new mobo came with xchi, and the following broke: 1. My old printer MFC-7820N no longer worked for scanning 2. Trying to cold flash any omap3 boards over USB stopped working for most of the time 3. Back-ups to a USB drive occasionally started failing 4. After disabling xhci in the BIOS, things were still flakey with ehci 5. I ended up installing a usb2.0 ehci pcie card to fix things Regards, Tony -- 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: [xhci] BUG: unable to handle kernel NULL pointer dereference at (null)
I love 0day! That is all. On Wed, Aug 27, 2014 at 10:09 AM, Fengguang Wu fengguang...@intel.com wrote: Greetings, 0day kernel testing robot got the below dmesg and the first bad commit is git://git.kernel.org/pub/scm/linux/kernel/git/djbw/usb.git td-fragments-v1 commit e65e21a542cab81d794db4e5fe919c4e1d624ea7 Author: Dan Williams dan.j.willi...@intel.com AuthorDate: Tue Jul 22 00:08:51 2014 -0700 Commit: Dan Williams dan.j.willi...@intel.com CommitDate: Fri Aug 22 10:06:50 2014 -0700 xhci: unit test ring enqueue/dequeue routines Given the complexity of satisfying xhci 1.0+ host trb boundary constraints, provide a test case that exercises inserting mid-segment links into a ring. The linker --wrap= option is used to not pollute the global identifier space and to make it clear which standard xhci driver routines are being mocked-up. The --wrap= option does not come into play when both xhci-hcd and xhci-test are built-in to the kernel, so namespace collisions are prevented by excluding xhci-test from the build when xhci-hcd is built-in. It's unfortunate that this is an in-kernel test rather than userspace and that the infrastructure is custom rather than generic. That said, it serves its purpose of exercising the corner cases of the scatterlist parsing implementation in xhci. Cc: Rusty Russell ru...@rustcorp.com.au Signed-off-by: Dan Williams dan.j.willi...@intel.com +--+++ | | fb6fa3e625 | e65e21a542 | +--+++ | boot_successes | 60 | 0 | | boot_failures| 0 | 20 | | BUG:unable_to_handle_kernel_NULL_pointer_dereference | 0 | 20 | | Oops | 0 | 20 | | RIP:setup_test_skip64| 0 | 20 | | Kernel_panic-not_syncing:Fatal_exception | 0 | 20 | | backtrace:do_test| 0 | 20 | | backtrace:xhci_test_init | 0 | 20 | | backtrace:kernel_init_freeable | 0 | 20 | +--+++ [ 12.405859] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 12.406471] ohci-pci: OHCI PCI platform driver [ 12.406906] ohci-platform: OHCI generic platform driver [ 12.407510] BUG: unable to handle kernel NULL pointer dereference at (null) [ 12.408218] IP: [81968843] setup_test_skip64+0x183/0x270 [ 12.408781] PGD 0 [ 12.409010] Oops: [#1] SMP DEBUG_PAGEALLOC [ 12.409450] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.16.0-rc5-00225-ge65e21a #6 [ 12.410102] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 12.410599] task: 880012128000 ti: 88001213 task.ti: 88001213 [ 12.410950] RIP: 0010:[81968843] [81968843] setup_test_skip64+0x183/0x270 [ 12.410950] RSP: :880012133d08 EFLAGS: 00010202 [ 12.410950] RAX: 880012117000 RBX: RCX: 0007800f [ 12.410950] RDX: 0040 RSI: 0f01 RDI: [ 12.410950] RBP: 880012133d48 R08: 0fe0 R09: [ 12.410950] R10: 000f R11: 0001 R12: 8000 [ 12.410950] R13: R14: ffe0 R15: ffe0 [ 12.410950] FS: () GS:88001240() knlGS: [ 12.410950] CS: 0010 DS: ES: CR0: 8005003b [ 12.410950] CR2: CR3: 02568000 CR4: 06b0 [ 12.410950] Stack: [ 12.410950] 880012133ddc 880012133de8 880012133e10 [ 12.410950] 88000b1a2400 [ 12.410950] 880012133e48 81d71168 303a35343200 [ 12.410950] Call Trace: [ 12.410950] [81d71168] do_test.constprop.70+0x47/0x894 [ 12.410950] [819686c0] ? setup_test_32_248_8+0x340/0x340 [ 12.410950] [81826630] ? device_create_groups_vargs+0xe0/0x1a0 [ 12.410950] [82d3a394] ? ohci_platform_init+0x60/0x60 [ 12.410950] [82d3a585] xhci_test_init+0x1f1/0x2a5 [ 12.410950] [819686c0] ? setup_test_32_248_8+0x340/0x340 [ 12.410950] [81968380] ? setup_test_wrap64+0x320/0x320 [ 12.410950] [81968060] ? setup_test_dont_trim+0x2f0/0x2f0 [ 12.410950] [81967d70] ?
Re: [Pull Request] xhci: Bug fixes, now with more tags!
On Mon, Nov 11, 2013 at 11:27:13AM +0100, Vincent Thiele wrote: This Bug is still not completely solved (Ubuntu 13.10 newest kernel 3.11) Have you tried compiling 3.12 instead? I don't have any control over when Ubuntu picks up bug fixes for their kernel. Syslog: Nov 2 18:44:29 Arbeits-PC whoopsie[961]: online Nov 2 18:45:41 whoopsie[961]: last message repeated 2 times Nov 2 18:56:27 Arbeits-PC kernel: [ 8411.030685] usb 3-2: USB disconnect, device number 21 Nov 2 18:56:27 Arbeits-PC colord: device removed: sysfs-LGE-Nexus_4 Nov 2 18:56:28 Arbeits-PC kernel: [ 8412.253950] usb 3-2: new high-speed USB device number 25 using xhci_hcd Nov 2 18:56:28 Arbeits-PC kernel: [ 8412.270843] usb 3-2: New USB device found, idVendor=18d1, idProduct=4ee1 Nov 2 18:56:28 Arbeits-PC kernel: [ 8412.270848] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Nov 2 18:56:28 Arbeits-PC kernel: [ 8412.270851] usb 3-2: Product: Nexus 4 Nov 2 18:56:28 Arbeits-PC kernel: [ 8412.270854] usb 3-2: Manufacturer: LGE Nov 2 18:56:28 Arbeits-PC kernel: [ 8412.270856] usb 3-2: SerialNumber: 00294807ce91f316 Nov 2 18:56:28 Arbeits-PC colord: Device added: sysfs-LGE-Nexus_4 Nov 2 18:56:28 Arbeits-PC dbus[651]: [system] Activating service name='org.freedesktop.hostname1' (using servicehelper) Nov 2 18:56:28 Arbeits-PC dbus[651]: [system] Successfully activated service 'org.freedesktop.hostname1' Nov 2 18:56:28 Arbeits-PC kernel: [ 8412.451541] usb 3-2: USB disconnect, device number 25 Nov 2 18:56:28 Arbeits-PC colord: device removed: sysfs-LGE-Nexus_4 Nov 2 18:56:29 Arbeits-PC kernel: [ 8413.735802] usb 3-2: new high-speed USB device number 30 using xhci_hcd Nov 2 18:56:45 Arbeits-PC kernel: [ 8418.728670] xhci_hcd :03:00.0: Timeout while waiting for address device command Nov 2 18:56:45 Arbeits-PC kernel: [ 8429.521172] [sched_delayed] sched: RT throttling activated Nov 2 18:56:45 Arbeits-PC rtkit-daemon[1321]: The canary thread is apparently starving. Taking action. Nov 2 18:56:45 Arbeits-PC rtkit-daemon[1321]: Demoting known real-time threads. Nov 2 18:56:45 Arbeits-PC rtkit-daemon[1321]: Successfully demoted thread 2186 of process 2142 (n/a). Nov 2 18:56:45 Arbeits-PC rtkit-daemon[1321]: Successfully demoted thread 2185 of process 2142 (n/a). Nov 2 18:56:45 Arbeits-PC rtkit-daemon[1321]: Successfully demoted thread 2184 of process 2142 (n/a). Nov 2 18:56:45 Arbeits-PC rtkit-daemon[1321]: Successfully demoted thread 2142 of process 2142 (n/a). Nov 2 18:56:45 Arbeits-PC rtkit-daemon[1321]: Demoted 4 threads. Nov 2 18:56:45 Arbeits-PC kernel: [ 8429.720909] usb 3-2: Device not responding to set address. Nov 2 18:56:45 Arbeits-PC kernel: [ 8429.924616] usb 3-2: device not accepting address 30, error -71 Nov 2 18:57:05 Arbeits-PC kernel: [ 8434.917500] xhci_hcd :03:00.0: Timeout while waiting for a slot Nov 2 18:57:05 Arbeits-PC kernel: [ 8449.102462] xhci_hcd :03:00.0: Stopped the command ring failed, maybe the host is dead Nov 2 18:57:05 Arbeits-PC kernel: [ 8449.102479] xhci_hcd :03:00.0: Abort command ring failed Nov 2 18:57:05 Arbeits-PC kernel: [ 8449.102677] xhci_hcd :03:00.0: HC died; cleaning up Nov 2 18:57:05 Arbeits-PC kernel: [ 8449.104659] xHCI xhci_free_dev called with unaddressed device Nov 2 18:57:10 Arbeits-PC kernel: [ 8454.094047] xhci_hcd :03:00.0: Timeout while waiting for a slot Nov 2 18:57:10 Arbeits-PC kernel: [ 8454.094051] xhci_hcd :03:00.0: Abort the command ring, but the xHCI is dead. Nov 2 18:57:10 Arbeits-PC kernel: [ 8454.094060] xHCI xhci_free_dev called with unaddressed device Nov 2 18:57:15 Arbeits-PC kernel: [ 8459.086911] xhci_hcd :03:00.0: Timeout while waiting for a slot Nov 2 18:57:15 Arbeits-PC kernel: [ 8459.086917] xhci_hcd :03:00.0: Abort the command ring, but the xHCI is dead. Nov 2 18:57:15 Arbeits-PC kernel: [ 8459.086930] xHCI xhci_free_dev called with unaddressed device Nov 2 18:57:15 Arbeits-PC kernel: [ 8459.086940] usb 3-1: USB disconnect, device number 2 Nov 2 18:57:15 Arbeits-PC udisksd[2260]: Cleaning up mount point /media/vincent/Elements (device 8:33 no longer exist) Nov 2 18:57:15 Arbeits-PC ntfs-3g[2477]: Unmounting /dev/sdc1 (Elements) Short system hang with looping audio after that every usb-device which is connected with this usb-controller is disconnected until i reboot the system. 2013/11/3 Vincent Thiele vincentthi...@gmail.com: This Bug is still not completely solved (Ubuntu 13.10 newest kernel 3.11) Syslog: Nov 2 18:44:29 Arbeits-PC whoopsie[961]: online Nov 2 18:45:41 whoopsie[961]: last message repeated 2 times Nov 2 18:56:27 Arbeits-PC kernel: [ 8411.030685] usb 3-2: USB disconnect, device number 21 Nov 2 18:56:27 Arbeits-PC colord: device removed: sysfs-LGE-Nexus_4 Nov 2 18:56:28 Arbeits-PC kernel: [ 8412.253950] usb 3-2: new high-speed USB device number 25 using xhci_hcd Nov 2 18:56:28 Arbeits-PC kernel: [ 8412.270843]
Re: [Pull Request] xhci: Bug fixes, now with more tags!
This Bug is still not completely solved (Ubuntu 13.10 newest kernel 3.11) Syslog: Nov 2 18:44:29 Arbeits-PC whoopsie[961]: online Nov 2 18:45:41 whoopsie[961]: last message repeated 2 times Nov 2 18:56:27 Arbeits-PC kernel: [ 8411.030685] usb 3-2: USB disconnect, device number 21 Nov 2 18:56:27 Arbeits-PC colord: device removed: sysfs-LGE-Nexus_4 Nov 2 18:56:28 Arbeits-PC kernel: [ 8412.253950] usb 3-2: new high-speed USB device number 25 using xhci_hcd Nov 2 18:56:28 Arbeits-PC kernel: [ 8412.270843] usb 3-2: New USB device found, idVendor=18d1, idProduct=4ee1 Nov 2 18:56:28 Arbeits-PC kernel: [ 8412.270848] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Nov 2 18:56:28 Arbeits-PC kernel: [ 8412.270851] usb 3-2: Product: Nexus 4 Nov 2 18:56:28 Arbeits-PC kernel: [ 8412.270854] usb 3-2: Manufacturer: LGE Nov 2 18:56:28 Arbeits-PC kernel: [ 8412.270856] usb 3-2: SerialNumber: 00294807ce91f316 Nov 2 18:56:28 Arbeits-PC colord: Device added: sysfs-LGE-Nexus_4 Nov 2 18:56:28 Arbeits-PC dbus[651]: [system] Activating service name='org.freedesktop.hostname1' (using servicehelper) Nov 2 18:56:28 Arbeits-PC dbus[651]: [system] Successfully activated service 'org.freedesktop.hostname1' Nov 2 18:56:28 Arbeits-PC kernel: [ 8412.451541] usb 3-2: USB disconnect, device number 25 Nov 2 18:56:28 Arbeits-PC colord: device removed: sysfs-LGE-Nexus_4 Nov 2 18:56:29 Arbeits-PC kernel: [ 8413.735802] usb 3-2: new high-speed USB device number 30 using xhci_hcd Nov 2 18:56:45 Arbeits-PC kernel: [ 8418.728670] xhci_hcd :03:00.0: Timeout while waiting for address device command Nov 2 18:56:45 Arbeits-PC kernel: [ 8429.521172] [sched_delayed] sched: RT throttling activated Nov 2 18:56:45 Arbeits-PC rtkit-daemon[1321]: The canary thread is apparently starving. Taking action. Nov 2 18:56:45 Arbeits-PC rtkit-daemon[1321]: Demoting known real-time threads. Nov 2 18:56:45 Arbeits-PC rtkit-daemon[1321]: Successfully demoted thread 2186 of process 2142 (n/a). Nov 2 18:56:45 Arbeits-PC rtkit-daemon[1321]: Successfully demoted thread 2185 of process 2142 (n/a). Nov 2 18:56:45 Arbeits-PC rtkit-daemon[1321]: Successfully demoted thread 2184 of process 2142 (n/a). Nov 2 18:56:45 Arbeits-PC rtkit-daemon[1321]: Successfully demoted thread 2142 of process 2142 (n/a). Nov 2 18:56:45 Arbeits-PC rtkit-daemon[1321]: Demoted 4 threads. Nov 2 18:56:45 Arbeits-PC kernel: [ 8429.720909] usb 3-2: Device not responding to set address. Nov 2 18:56:45 Arbeits-PC kernel: [ 8429.924616] usb 3-2: device not accepting address 30, error -71 Nov 2 18:57:05 Arbeits-PC kernel: [ 8434.917500] xhci_hcd :03:00.0: Timeout while waiting for a slot Nov 2 18:57:05 Arbeits-PC kernel: [ 8449.102462] xhci_hcd :03:00.0: Stopped the command ring failed, maybe the host is dead Nov 2 18:57:05 Arbeits-PC kernel: [ 8449.102479] xhci_hcd :03:00.0: Abort command ring failed Nov 2 18:57:05 Arbeits-PC kernel: [ 8449.102677] xhci_hcd :03:00.0: HC died; cleaning up Nov 2 18:57:05 Arbeits-PC kernel: [ 8449.104659] xHCI xhci_free_dev called with unaddressed device Nov 2 18:57:10 Arbeits-PC kernel: [ 8454.094047] xhci_hcd :03:00.0: Timeout while waiting for a slot Nov 2 18:57:10 Arbeits-PC kernel: [ 8454.094051] xhci_hcd :03:00.0: Abort the command ring, but the xHCI is dead. Nov 2 18:57:10 Arbeits-PC kernel: [ 8454.094060] xHCI xhci_free_dev called with unaddressed device Nov 2 18:57:15 Arbeits-PC kernel: [ 8459.086911] xhci_hcd :03:00.0: Timeout while waiting for a slot Nov 2 18:57:15 Arbeits-PC kernel: [ 8459.086917] xhci_hcd :03:00.0: Abort the command ring, but the xHCI is dead. Nov 2 18:57:15 Arbeits-PC kernel: [ 8459.086930] xHCI xhci_free_dev called with unaddressed device Nov 2 18:57:15 Arbeits-PC kernel: [ 8459.086940] usb 3-1: USB disconnect, device number 2 Nov 2 18:57:15 Arbeits-PC udisksd[2260]: Cleaning up mount point /media/vincent/Elements (device 8:33 no longer exist) Nov 2 18:57:15 Arbeits-PC ntfs-3g[2477]: Unmounting /dev/sdc1 (Elements) Short system hang with looping audio after that every usb-device which is connected with this usb-controller is disconnected until i reboot the system. 2013/11/3 Vincent Thiele vincentthi...@gmail.com: This Bug is still not completely solved (Ubuntu 13.10 newest kernel 3.11) Syslog: Nov 2 18:44:29 Arbeits-PC whoopsie[961]: online Nov 2 18:45:41 whoopsie[961]: last message repeated 2 times Nov 2 18:56:27 Arbeits-PC kernel: [ 8411.030685] usb 3-2: USB disconnect, device number 21 Nov 2 18:56:27 Arbeits-PC colord: device removed: sysfs-LGE-Nexus_4 Nov 2 18:56:28 Arbeits-PC kernel: [ 8412.253950] usb 3-2: new high-speed USB device number 25 using xhci_hcd Nov 2 18:56:28 Arbeits-PC kernel: [ 8412.270843] usb 3-2: New USB device found, idVendor=18d1, idProduct=4ee1 Nov 2 18:56:28 Arbeits-PC kernel: [ 8412.270848] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Nov 2 18:56:28 Arbeits-PC kernel: [ 8412.270851] usb 3-2: Product: Nexus 4 Nov 2 18:56:28
Re: [Pull Request] xhci: Bug fixes, now with more tags!
This Bug is still not completely solved (Ubuntu 13.10 newest kernel 3.11) Syslog: Nov 2 18:44:29 Arbeits-PC whoopsie[961]: online Nov 2 18:45:41 whoopsie[961]: last message repeated 2 times Nov 2 18:56:27 Arbeits-PC kernel: [ 8411.030685] usb 3-2: USB disconnect, device number 21 Nov 2 18:56:27 Arbeits-PC colord: device removed: sysfs-LGE-Nexus_4 Nov 2 18:56:28 Arbeits-PC kernel: [ 8412.253950] usb 3-2: new high-speed USB device number 25 using xhci_hcd Nov 2 18:56:28 Arbeits-PC kernel: [ 8412.270843] usb 3-2: New USB device found, idVendor=18d1, idProduct=4ee1 Nov 2 18:56:28 Arbeits-PC kernel: [ 8412.270848] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Nov 2 18:56:28 Arbeits-PC kernel: [ 8412.270851] usb 3-2: Product: Nexus 4 Nov 2 18:56:28 Arbeits-PC kernel: [ 8412.270854] usb 3-2: Manufacturer: LGE Nov 2 18:56:28 Arbeits-PC kernel: [ 8412.270856] usb 3-2: SerialNumber: 00294807ce91f316 Nov 2 18:56:28 Arbeits-PC colord: Device added: sysfs-LGE-Nexus_4 Nov 2 18:56:28 Arbeits-PC dbus[651]: [system] Activating service name='org.freedesktop.hostname1' (using servicehelper) Nov 2 18:56:28 Arbeits-PC dbus[651]: [system] Successfully activated service 'org.freedesktop.hostname1' Nov 2 18:56:28 Arbeits-PC kernel: [ 8412.451541] usb 3-2: USB disconnect, device number 25 Nov 2 18:56:28 Arbeits-PC colord: device removed: sysfs-LGE-Nexus_4 Nov 2 18:56:29 Arbeits-PC kernel: [ 8413.735802] usb 3-2: new high-speed USB device number 30 using xhci_hcd Nov 2 18:56:45 Arbeits-PC kernel: [ 8418.728670] xhci_hcd :03:00.0: Timeout while waiting for address device command Nov 2 18:56:45 Arbeits-PC kernel: [ 8429.521172] [sched_delayed] sched: RT throttling activated Nov 2 18:56:45 Arbeits-PC rtkit-daemon[1321]: The canary thread is apparently starving. Taking action. Nov 2 18:56:45 Arbeits-PC rtkit-daemon[1321]: Demoting known real-time threads. Nov 2 18:56:45 Arbeits-PC rtkit-daemon[1321]: Successfully demoted thread 2186 of process 2142 (n/a). Nov 2 18:56:45 Arbeits-PC rtkit-daemon[1321]: Successfully demoted thread 2185 of process 2142 (n/a). Nov 2 18:56:45 Arbeits-PC rtkit-daemon[1321]: Successfully demoted thread 2184 of process 2142 (n/a). Nov 2 18:56:45 Arbeits-PC rtkit-daemon[1321]: Successfully demoted thread 2142 of process 2142 (n/a). Nov 2 18:56:45 Arbeits-PC rtkit-daemon[1321]: Demoted 4 threads. Nov 2 18:56:45 Arbeits-PC kernel: [ 8429.720909] usb 3-2: Device not responding to set address. Nov 2 18:56:45 Arbeits-PC kernel: [ 8429.924616] usb 3-2: device not accepting address 30, error -71 Nov 2 18:57:05 Arbeits-PC kernel: [ 8434.917500] xhci_hcd :03:00.0: Timeout while waiting for a slot Nov 2 18:57:05 Arbeits-PC kernel: [ 8449.102462] xhci_hcd :03:00.0: Stopped the command ring failed, maybe the host is dead Nov 2 18:57:05 Arbeits-PC kernel: [ 8449.102479] xhci_hcd :03:00.0: Abort command ring failed Nov 2 18:57:05 Arbeits-PC kernel: [ 8449.102677] xhci_hcd :03:00.0: HC died; cleaning up Nov 2 18:57:05 Arbeits-PC kernel: [ 8449.104659] xHCI xhci_free_dev called with unaddressed device Nov 2 18:57:10 Arbeits-PC kernel: [ 8454.094047] xhci_hcd :03:00.0: Timeout while waiting for a slot Nov 2 18:57:10 Arbeits-PC kernel: [ 8454.094051] xhci_hcd :03:00.0: Abort the command ring, but the xHCI is dead. Nov 2 18:57:10 Arbeits-PC kernel: [ 8454.094060] xHCI xhci_free_dev called with unaddressed device Nov 2 18:57:15 Arbeits-PC kernel: [ 8459.086911] xhci_hcd :03:00.0: Timeout while waiting for a slot Nov 2 18:57:15 Arbeits-PC kernel: [ 8459.086917] xhci_hcd :03:00.0: Abort the command ring, but the xHCI is dead. Nov 2 18:57:15 Arbeits-PC kernel: [ 8459.086930] xHCI xhci_free_dev called with unaddressed device Nov 2 18:57:15 Arbeits-PC kernel: [ 8459.086940] usb 3-1: USB disconnect, device number 2 Nov 2 18:57:15 Arbeits-PC udisksd[2260]: Cleaning up mount point /media/vincent/Elements (device 8:33 no longer exist) Nov 2 18:57:15 Arbeits-PC ntfs-3g[2477]: Unmounting /dev/sdc1 (Elements) Short system hang with looping audio after that every usb-device which is connected with this usb-controller is disconnected until i reboot the system. 2013/7/25 Greg Kroah-Hartman gre...@linuxfoundation.org: On Thu, Jul 25, 2013 at 08:16:03AM -0700, Sarah Sharp wrote: The following changes since commit 94190301ffa059c2d127b3a67ec5d161d5c62681: usb: option: add TP-LINK MA260 (2013-07-23 16:07:51 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git tags/for-usb-linus-2013-07-25 Ah, much better, thanks for upgrading git. Now pulled and pushed out. 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
Re: [Pull Request] xHCI bug fixes for 3.12 (Link PM and misc)
On Tue, Oct 15, 2013 at 01:09:16PM -0700, Greg Kroah-Hartman wrote: On Tue, Oct 15, 2013 at 12:44:08PM -0700, Sarah Sharp wrote: So I'd like to take these for 3.13-rc1, and if they are fixes, take them into the 3.12-stable tree (and older ones) when they hit Linus's tree then. Ok, fine with me. Just to be clear though: are you asking me to delay these long-standing bugs because we're now at -rc5, or do you always want me to delay them for the next kernel release? Because we are at -rc5. Maybe something like this could go into -rc2 and possibly -rc3, but come on, -rc5? Thank you for clarifying the line of where you cut off non-regression pulls for your usb-linus branch. I will make my future pull requests match that. Look at all of the pushback Linus has been giving maintainers on lkml, this shouldn't be news. I'm sorry for missing those emails; I don't normally keep up with LKML. I will strive to pay attention to future email Linus sends. Sarah Sharp -- 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: [Pull Request] xHCI bug fixes for 3.12 (Link PM and misc)
On Mon, Oct 14, 2013 at 05:24:10PM -0700, Sarah Sharp wrote: The following changes since commit f4c19b8e165cff1a6607c21f8809441d61cab7ec: USB: serial: option: add support for Inovia SEW858 device (2013-10-11 16:17:51 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git tags/for-usb-linus-2013-10-14 for you to fetch changes up to 0ef7a36cb604c65ca1c84d3dd9a9363498ed028a: xhci: correct the usage of USB_CTRL_SET_TIMEOUT (2013-10-14 17:12:10 -0700) xHCI bug fixes for 3.12 (Link PM and misc) Hi Greg, I hope you're recovered from your trip. :) Thanks, just in time to leave again in 4 days... Here's five patches for 3.12. The first four patches address issues with USB 2.0 Link PM that were causing distros to report that attaching a USB 3.0 device to a USB 2.0 port makes the device not enumerate on Intel Haswell ULT systems with USB 2.0 hardware-enabled Link PM. This issue has been reproduced under both Ubuntu and ChromeOS. The patches are marked for stable. The last patch is a simple fix to use jiffies instead of msec on a completion timeout. The issue that caused the timeout to expire was fixed in commit ec7e43e2d98173483866fe2e4e690143626b659c xhci: Ensure a command structure points to the correct trb on the command ring. The driver wouldn't normally hit this timeout if the host and driver were functioning correctly, and I don't have any reports of other systems that hit this timeout. This makes it low-priority, so I'm not marking it for stable. All of these are for issues that do not look like regressions to me, but rather, long-standing bugs. While I'm all about fixing bugs and problems, none of these seem like urgent fixes for things that have been recently broken. So I'd like to take these for 3.13-rc1, and if they are fixes, take them into the 3.12-stable tree (and older ones) when they hit Linus's tree then. I can take these as patches for my usb-next branch by hand if you want, or I can take a new pull request for that branch. 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
Re: [Pull Request] xHCI bug fixes for 3.12 (Link PM and misc)
On Tue, Oct 15, 2013 at 08:09:01AM -0700, Greg Kroah-Hartman wrote: All of these are for issues that do not look like regressions to me, but rather, long-standing bugs. While I'm all about fixing bugs and problems, none of these seem like urgent fixes for things that have been recently broken. I agree, they're not regressions. The support for USB 2.0 Link PM on Haswell ULT was added in 3.11, and the code has always caused these broken USB 3.0 devices to not enumerate when plugged into USB 2.0 ports. We just didn't catch it until now. And yes, the first patch fixes a long-standing bug. So I'd like to take these for 3.13-rc1, and if they are fixes, take them into the 3.12-stable tree (and older ones) when they hit Linus's tree then. Ok, fine with me. Just to be clear though: are you asking me to delay these long-standing bugs because we're now at -rc5, or do you always want me to delay them for the next kernel release? I can take these as patches for my usb-next branch by hand if you want, or I can take a new pull request for that branch. I'll send you a separate pull request tomorrow. I've got a bunch of patches for usb-next anyway. Sarah Sharp -- 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: [Pull Request] xHCI bug fixes for 3.12 (Link PM and misc)
On Tue, Oct 15, 2013 at 12:44:08PM -0700, Sarah Sharp wrote: So I'd like to take these for 3.13-rc1, and if they are fixes, take them into the 3.12-stable tree (and older ones) when they hit Linus's tree then. Ok, fine with me. Just to be clear though: are you asking me to delay these long-standing bugs because we're now at -rc5, or do you always want me to delay them for the next kernel release? Because we are at -rc5. Maybe something like this could go into -rc2 and possibly -rc3, but come on, -rc5? Look at all of the pushback Linus has been giving maintainers on lkml, this shouldn't be news. 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
[Pull Request] xHCI bug fixes for 3.12 (Link PM and misc)
The following changes since commit f4c19b8e165cff1a6607c21f8809441d61cab7ec: USB: serial: option: add support for Inovia SEW858 device (2013-10-11 16:17:51 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git tags/for-usb-linus-2013-10-14 for you to fetch changes up to 0ef7a36cb604c65ca1c84d3dd9a9363498ed028a: xhci: correct the usage of USB_CTRL_SET_TIMEOUT (2013-10-14 17:12:10 -0700) xHCI bug fixes for 3.12 (Link PM and misc) Hi Greg, I hope you're recovered from your trip. :) Here's five patches for 3.12. The first four patches address issues with USB 2.0 Link PM that were causing distros to report that attaching a USB 3.0 device to a USB 2.0 port makes the device not enumerate on Intel Haswell ULT systems with USB 2.0 hardware-enabled Link PM. This issue has been reproduced under both Ubuntu and ChromeOS. The patches are marked for stable. The last patch is a simple fix to use jiffies instead of msec on a completion timeout. The issue that caused the timeout to expire was fixed in commit ec7e43e2d98173483866fe2e4e690143626b659c xhci: Ensure a command structure points to the correct trb on the command ring. The driver wouldn't normally hit this timeout if the host and driver were functioning correctly, and I don't have any reports of other systems that hit this timeout. This makes it low-priority, so I'm not marking it for stable. Sarah Sharp Mathias Nyman (1): xhci: Enable LPM support only for hardwired or BESL devices Sarah Sharp (3): usb: Disable USB 2.0 Link PM before device reset. xhci: Set L1 device slot on USB2 LPM enable/disable. usb: Don't enable USB 2.0 Link PM by default. xiao jin (1): xhci: correct the usage of USB_CTRL_SET_TIMEOUT drivers/usb/core/driver.c |3 + drivers/usb/core/hub.c | 34 + drivers/usb/core/sysfs.c|6 +- drivers/usb/host/xhci-hub.c |2 +- drivers/usb/host/xhci-mem.c | 10 --- drivers/usb/host/xhci.c | 167 ++- drivers/usb/host/xhci.h |1 + include/linux/usb.h |4 +- 8 files changed, 67 insertions(+), 160 deletions(-) -- 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: [Pull Request v2] xhci: Bug fixes and quirks for 3.12
Ping. Have a couple more patches to send you for 3.12, can you pull this? Thanks, Sarah Sharp On Wed, Oct 09, 2013 at 04:37:27PM -0700, Sarah Sharp wrote: The following changes since commit d0e639c9e06d44e713170031fe05fb60ebe680af: Linux 3.12-rc4 (2013-10-06 14:00:20 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git tags/for-usb-linus-2013-10-09 for you to fetch changes up to 638298dc66ea36623dbc2757a24fc2c4ab41b016: xhci: Fix spurious wakeups after S5 on Haswell (2013-10-09 16:27:20 -0700) xhci: Bug fixes and quirks for 3.12 Hi Greg, Here's four patches for 3.12. The first patch is a bug fix for the USB 2.0 Link PM registers that I sent out to the list a long time ago (August), but forgot to queue up. The second and fourth patches are quirks for xHCI hosts. These patches are marked for stable. The third patch fixes a bug uncovered with sparse. Sarah Sharp Oliver Neukum (1): xhci: quirk for extra long delay for S4 Sarah Sharp (1): xhci: Don't enable/disable RWE on bus suspend/resume. Takashi Iwai (1): xhci: Fix spurious wakeups after S5 on Haswell Xenia Ragiadakou (1): xhci: fix write to USB3_PSSEN and XUSB2PRM pci config registers drivers/usb/host/pci-quirks.c |4 ++-- drivers/usb/host/xhci-hub.c | 26 -- drivers/usb/host/xhci-pci.c | 25 + drivers/usb/host/xhci.c | 14 +- drivers/usb/host/xhci.h |2 ++ 5 files changed, 42 insertions(+), 29 deletions(-) -- 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 -- 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: [Pull Request v2] xhci: Bug fixes and quirks for 3.12
On Fri, Oct 11, 2013 at 11:36:57AM -0700, Sarah Sharp wrote: Ping. Have a couple more patches to send you for 3.12, can you pull this? Now pulled, I was on a plane from Korea, so patience please, I have no idea what day it is anymore (two days of flying for 2 days of meetings, not a good idea...) 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
[Pull Request] xhci: Bug fixes and quirks for 3.12
The following changes since commit d0e639c9e06d44e713170031fe05fb60ebe680af: Linux 3.12-rc4 (2013-10-06 14:00:20 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git tags/for-usb-linus-2012-10-09 for you to fetch changes up to 0bde621adf7fdc386bc8544ebb0fa90fa00cb285: xhci: Fix spurious wakeups after S5 on Haswell (2013-10-09 08:24:29 -0700) xhci: Bug fixes and quirks for 3.12 Hi Greg, Here's five patches for 3.12. The first patch is a bug fix for the USB 2.0 Link PM registers that I sent out to the list a long time ago (August), but forgot to queue up. The second and fifth patches are quirks for xHCI hosts. These patches are marked for stable. The third patch fixes a sparse warning, and the fourth patch is a trivial cleanup. Sarah Sharp Oliver Neukum (1): xhci: quirk for extra long delay for S4 Sachin Kamat (1): usb: xhci: Staticize xhci_del_comp_mod_timer Sarah Sharp (1): xhci: Don't enable/disable RWE on bus suspend/resume. Takashi Iwai (1): xhci: Fix spurious wakeups after S5 on Haswell Xenia Ragiadakou (1): xhci: fix write to USB3_PSSEN and XUSB2PRM pci config registers drivers/usb/host/pci-quirks.c |4 ++-- drivers/usb/host/xhci-hub.c | 29 ++--- drivers/usb/host/xhci-pci.c | 25 + drivers/usb/host/xhci.c | 14 +- drivers/usb/host/xhci.h |2 ++ 5 files changed, 44 insertions(+), 30 deletions(-) -- 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
[Pull Request v2] xhci: Bug fixes and quirks for 3.12
The following changes since commit d0e639c9e06d44e713170031fe05fb60ebe680af: Linux 3.12-rc4 (2013-10-06 14:00:20 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git tags/for-usb-linus-2013-10-09 for you to fetch changes up to 638298dc66ea36623dbc2757a24fc2c4ab41b016: xhci: Fix spurious wakeups after S5 on Haswell (2013-10-09 16:27:20 -0700) xhci: Bug fixes and quirks for 3.12 Hi Greg, Here's four patches for 3.12. The first patch is a bug fix for the USB 2.0 Link PM registers that I sent out to the list a long time ago (August), but forgot to queue up. The second and fourth patches are quirks for xHCI hosts. These patches are marked for stable. The third patch fixes a bug uncovered with sparse. Sarah Sharp Oliver Neukum (1): xhci: quirk for extra long delay for S4 Sarah Sharp (1): xhci: Don't enable/disable RWE on bus suspend/resume. Takashi Iwai (1): xhci: Fix spurious wakeups after S5 on Haswell Xenia Ragiadakou (1): xhci: fix write to USB3_PSSEN and XUSB2PRM pci config registers drivers/usb/host/pci-quirks.c |4 ++-- drivers/usb/host/xhci-hub.c | 26 -- drivers/usb/host/xhci-pci.c | 25 + drivers/usb/host/xhci.c | 14 +- drivers/usb/host/xhci.h |2 ++ 5 files changed, 42 insertions(+), 29 deletions(-) -- 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: [Pull Request] xhci: Bug fixes for 3.12.
On Mon, Sep 23, 2013 at 05:58:56PM -0700, Sarah Sharp wrote: The following changes since commit 9d23108df359e572a0dca0b631bfee9f5e0fa9ea: Merge tag 'staging-3.12-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging (2013-09-23 12:53:07 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git tags/for-usb-linus-2013-09-23 Pulled and pushed out, 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
Re: [Pull Request] xhci: Bug fixes for 3.12.
On 27/08/13 21:26, Sarah Sharp wrote: The following changes since commit 154547c4fe0fbe92185e69a6cdc2b0502b361995: USB: serial: clean up attribute permissions (2013-08-25 15:12:03 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git tags/for-usb-next-2013-08-27 for you to fetch changes up to 0730d52a86919300a39a2be37f6c140997dfb82f: xhci:prevent callbacks suppressed when debug is not enabled (2013-08-27 08:56:31 -0700) xhci: Bug fixes for 3.12. Hi Greg, Here's three low-priority bug fixes that should be queued for 3.12. They disable runtime PM for hosts that need the XHCI_RESET_ON_RESUME quirk, fix USB 2.0 Link PM on hosts that don't have BESL support, and prevent a bunch of log spam. Please pull into usb-next for 3.12. Sarah Sharp Dmitry Kasatkin (1): xhci:prevent callbacks suppressed when debug is not enabled Mathias Nyman (1): xhci: fix port BESL LPM capability checking Shawn Nematbakhsh (1): usb: xhci: Disable runtime PM suspend for quirky controllers drivers/usb/host/xhci-ext-caps.h |2 +- drivers/usb/host/xhci-ring.c | 24 drivers/usb/host/xhci.c | 22 ++ 3 files changed, 31 insertions(+), 17 deletions(-) Hello, I sent 2 patches. Only second one was taken. [PATCHv2 2/2] [PATCHv2 1/2] is required to prevent build break. Thanks, Dmitry -- 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: [Pull Request] xhci: Bug fixes for 3.12.
On Tue, Aug 27, 2013 at 11:26:55AM -0700, Sarah Sharp wrote: The following changes since commit 154547c4fe0fbe92185e69a6cdc2b0502b361995: USB: serial: clean up attribute permissions (2013-08-25 15:12:03 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git tags/for-usb-next-2013-08-27 Pulled and pushed out, 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
[Pull Request] xhci: Bug fixes, now with more tags!
The following changes since commit 94190301ffa059c2d127b3a67ec5d161d5c62681: usb: option: add TP-LINK MA260 (2013-07-23 16:07:51 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git tags/for-usb-linus-2013-07-25 for you to fetch changes up to d66eaf9f89502971fddcb0de550b01fa6f409d83: xhci: fix null pointer dereference on ring_doorbell_for_active_rings (2013-07-25 08:10:09 -0700) xhci: Bug fixes, now with more tags! Hi Greg, Here's five bug fixes for 3.12. The three patches are marked for stable. Two fix NULL pointer dereferences. The third marked for stable suppresses some serious log spam from unnecessary xHCI driver warnings, whenever an isochronous short packet happens on an xHCI 1.0 host. The other two patches fix build warnings. Sarah Sharp George Cherian (1): usb: host: xhci: Enable XHCI_SPURIOUS_SUCCESS for all controllers with xhci 1.0 Oleksij Rempel (1): xhci: fix null pointer dereference on ring_doorbell_for_active_rings Olof Johansson (1): usb: xhci: Mark two functions __maybe_unused Randy Dunlap (1): usb: fix build warning in pci-quirks.h when CONFIG_PCI is not enabled Sarah Sharp (1): xhci: Avoid NULL pointer deref when host dies. drivers/usb/host/pci-quirks.h |1 + drivers/usb/host/xhci-pci.c |1 - drivers/usb/host/xhci-ring.c |2 +- drivers/usb/host/xhci.c | 17 - 4 files changed, 14 insertions(+), 7 deletions(-) -- 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: [Pull Request] xhci: Bug fixes, now with more tags!
On Thu, Jul 25, 2013 at 08:16:03AM -0700, Sarah Sharp wrote: The following changes since commit 94190301ffa059c2d127b3a67ec5d161d5c62681: usb: option: add TP-LINK MA260 (2013-07-23 16:07:51 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git tags/for-usb-linus-2013-07-25 Ah, much better, thanks for upgrading git. Now pulled and pushed out. 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
[Pull Request] xHCI bug fix for 3.9
The following changes since commit 2a40f324541ee61c22146214349c2ce9f5c30bcf: USB: EHCI: fix regression during bus resume (2013-03-15 12:07:53 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git for-usb-linus for you to fetch changes up to f8264340e694604863255cc0276491d17c402390: USB: xhci - fix bit definitions for IMAN register (2013-03-18 08:25:13 -0700) xHCI bug fix for 3.9 Hi Greg, Here's one xHCI bug fix. We had two register bits flipped. Sarah Sharp Dmitry Torokhov (1): USB: xhci - fix bit definitions for IMAN register drivers/usb/host/xhci.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) -- 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
[Pull Request v2] xHCI bug fix for 3.9
(Actually pushed the git tag this time: for-usb-linus-2013-03-18) The following changes since commit 2a40f324541ee61c22146214349c2ce9f5c30bcf: USB: EHCI: fix regression during bus resume (2013-03-15 12:07:53 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git for-usb-linus-2013-03-18 for you to fetch changes up to f8264340e694604863255cc0276491d17c402390: USB: xhci - fix bit definitions for IMAN register (2013-03-18 08:25:13 -0700) xHCI bug fix for 3.9 Hi Greg, Here's one xHCI bug fix. We had two register bits flipped. Sarah Sharp Dmitry Torokhov (1): USB: xhci - fix bit definitions for IMAN register drivers/usb/host/xhci.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) -- 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
[Pull Request] xHCI bug fixes for 3.7-rc3
The following changes since commit 3b6054da68f9b0d5ed6a7ed0f42a79e61904352c: usb hub: send clear_tt_buffer_complete events when canceling TT clear work (2012-10-22 11:34:41 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git for-usb-linus-2012-10-23 for you to fetch changes up to 16b45fdf9c4e82f5d3bc53aa70737650e7c8d5ed: xhci: fix integer overflow (2012-10-23 15:43:38 -0700) xHCI fixes for 3.7-rc3 Hi Greg, Here's four bug fixes for 3.7. The first patch fixes a potential deadlock in the USB port power off code, and the last two patches fix bugs in the USB 3.0 Link PM patchset. The second one is trivial and removes an unnecessary cast. Sarah Sharp Lan Tianyu (2): usb/xhci: release xhci-lock during turning on/off usb port's acpi power resource and checking the existence of port's power resource usb/xhci: Remove (__force__ __u16) before assigning DeviceRemovable and assign directly. Oliver Neukum (2): xhci: endianness xhci_calculate_intel_u2_timeout xhci: fix integer overflow drivers/usb/host/xhci-hub.c |9 ++--- drivers/usb/host/xhci.c |4 ++-- 2 files changed, 8 insertions(+), 5 deletions(-) -- 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: [Pull Request] xHCI bug fixes for 3.7-rc3
On Tue, Oct 23, 2012 at 03:53:26PM -0700, Sarah Sharp wrote: The following changes since commit 3b6054da68f9b0d5ed6a7ed0f42a79e61904352c: usb hub: send clear_tt_buffer_complete events when canceling TT clear work (2012-10-22 11:34:41 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git for-usb-linus-2012-10-23 Pulled and pushed out. 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
Re: XHCI Bug discovered in 3.6-RC6 (solution included)
Hi
I have posted the required patch for this:
usb: host: xhci: Fix Null pointer dereferencing with 71c731a for non-x86 systems
Can we please get that in ?
On Tue, Sep 18, 2012 at 8:06 PM, Greg KH g...@kroah.com wrote:
On Tue, Sep 18, 2012 at 02:51:57AM +0200, Sebastian Gottschall (DD-WRT) wrote:
this following function is missing a important NULL check. if DMI is
not available or not enabled in the kernel config (which is common
in my case, since its a ARM Platform with XHCI support)
the xhci-hcd driver will crash due nullpointer access since
dmi_get_system_info returns always NULL if DMI support is not
enabled.
static bool compliance_mode_recovery_timer_quirk_check(void)
{
const char *dmi_product_name, *dmi_sys_vendor;
dmi_product_name = dmi_get_system_info(DMI_PRODUCT_NAME);
dmi_sys_vendor = dmi_get_system_info(DMI_SYS_VENDOR);
if (!(strstr(dmi_sys_vendor, Hewlett-Packard)))
return false;
if (strstr(dmi_product_name, Z420) ||
strstr(dmi_product_name, Z620) ||
strstr(dmi_product_name, Z820))
return true;
return false;
}
proposed patch: simply add
if (!dmi_sys_vendor || !dmi_product_name)
return false;
even better. disable the whole quirk handling for this case if
CONFIG_DMI is not set
Care to send a patch to fix this up?
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
Thanks
vivek
--
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: XHCI Bug discovered in 3.6-RC6 (solution included)
A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Tue, Sep 25, 2012 at 03:12:33PM +0530, Vivek Gautam wrote: Hi I have posted the required patch for this: usb: host: xhci: Fix Null pointer dereferencing with 71c731a for non-x86 systems You sent this last saturday, a mere 3 days ago, two of them on a weekend, please be patient. 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
Re: [Pull Request] xHCI bug fixes for 3.7
On Tue, Sep 25, 2012 at 03:29:23PM -0700, Sarah Sharp wrote: The following changes since commit f3f4bf5cf0896e58e9831ea53bcb8c7d88127d20: USB: ohci-at91: fix null pointer in ohci_hcd_at91_overcurrent_irq (2012-09-24 10:42:25 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git for-usb-next-2012-09-25 Pulled and pushed out, 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
Re: XHCI Bug discovered in 3.6-RC6 (solution included)
Apologies for that. I should have been rather a bit patient. Best regards Vivek On Tue, Sep 25, 2012 at 7:10 PM, Greg KH g...@kroah.com wrote: A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Tue, Sep 25, 2012 at 03:12:33PM +0530, Vivek Gautam wrote: Hi I have posted the required patch for this: usb: host: xhci: Fix Null pointer dereferencing with 71c731a for non-x86 systems You sent this last saturday, a mere 3 days ago, two of them on a weekend, please be patient. 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
Re: XHCI Bug discovered in 3.6-RC6 (solution included)
On Tue, Sep 18, 2012 at 02:51:57AM +0200, Sebastian Gottschall (DD-WRT) wrote:
this following function is missing a important NULL check. if DMI is
not available or not enabled in the kernel config (which is common
in my case, since its a ARM Platform with XHCI support)
the xhci-hcd driver will crash due nullpointer access since
dmi_get_system_info returns always NULL if DMI support is not
enabled.
static bool compliance_mode_recovery_timer_quirk_check(void)
{
const char *dmi_product_name, *dmi_sys_vendor;
dmi_product_name = dmi_get_system_info(DMI_PRODUCT_NAME);
dmi_sys_vendor = dmi_get_system_info(DMI_SYS_VENDOR);
if (!(strstr(dmi_sys_vendor, Hewlett-Packard)))
return false;
if (strstr(dmi_product_name, Z420) ||
strstr(dmi_product_name, Z620) ||
strstr(dmi_product_name, Z820))
return true;
return false;
}
proposed patch: simply add
if (!dmi_sys_vendor || !dmi_product_name)
return false;
even better. disable the whole quirk handling for this case if
CONFIG_DMI is not set
Care to send a patch to fix this up?
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
Re: XHCI Bug discovered in 3.6-RC6 (solution included)
this following function is missing a important NULL check. if DMI is not
available or not enabled in the kernel config (which is common in my
case, since its a ARM Platform with XHCI support)
the xhci-hcd driver will crash due nullpointer access since
dmi_get_system_info returns always NULL if DMI support is not enabled.
static bool compliance_mode_recovery_timer_quirk_check(void)
{
const char *dmi_product_name, *dmi_sys_vendor;
dmi_product_name = dmi_get_system_info(DMI_PRODUCT_NAME);
dmi_sys_vendor = dmi_get_system_info(DMI_SYS_VENDOR);
if (!(strstr(dmi_sys_vendor, Hewlett-Packard)))
return false;
if (strstr(dmi_product_name, Z420) ||
strstr(dmi_product_name, Z620) ||
strstr(dmi_product_name, Z820))
return true;
return false;
}
proposed patch: simply add
if (!dmi_sys_vendor || !dmi_product_name)
return false;
even better. disable the whole quirk handling for this case if
CONFIG_DMI is not set
--
Mit freundlichen Grüssen / Regards
Sebastian Gottschall / CTO
NewMedia-NET GmbH - DD-WRT
Firmensitz: Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565
--
Mit freundlichen Grüssen / Regards
Sebastian Gottschall / CTO
NewMedia-NET GmbH - DD-WRT
Firmensitz: Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email:s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565
--
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: [Pull Request] xHCI bug fixes for 3.6
On Wed, Aug 08, 2012 at 12:36:11PM -0700, Sarah Sharp wrote: The following changes since commit 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee: Linux 3.6-rc1 (2012-08-02 16:38:10 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git for-usb-linus-2012-08-08 Pulled and pushed out, 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
[Pull Request] xHCI bug fixes for 3.6
The following changes since commit 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee: Linux 3.6-rc1 (2012-08-02 16:38:10 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git for-usb-linus-2012-08-08 for you to fetch changes up to 50d0206fcaea3e736f912fd5b00ec6233fb4ce44: xhci: Fix bug after deq ptr set to link TRB. (2012-08-08 12:17:38 -0700) xHCI bug fixes and host quirks. Hi Greg, Here's four patches for 3.6. Most are marked for stable as well. The first one makes the xHCI driver load properly on newer Rensas hosts. The next two fix issues with the Etron host incorrectly marking short transfers as successful, and avoiding log warning spam for hosts that make the same mistake. The last patch fixes a really nasty xHCI driver bug that could cause general protection faults when devices stall transfers. Sarah Sharp Sarah Sharp (4): xhci: Increase reset timeout for Renesas 720201 host. xhci: Add Etron XHCI_TRUST_TX_LENGTH quirk. xhci: Rate-limit XHCI_TRUST_TX_LENGTH quirk warning. xhci: Fix bug after deq ptr set to link TRB. drivers/usb/host/xhci-pci.c |1 + drivers/usb/host/xhci-ring.c | 40 drivers/usb/host/xhci.c |5 +++-- drivers/usb/host/xhci.h |2 ++ 4 files changed, 30 insertions(+), 18 deletions(-) -- 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
