Re: OHCI unplug kernel crash in kernel 4.3, 4.4 and 4.5
Am Montag, den 29.02.2016, 18:07 +0100 schrieb Joerg Roedel: > On Mon, Feb 29, 2016 at 10:36:07AM -0500, Alan Stern wrote: > > > > The lines added by the patch were never executed. This means that > > dev->archdata.iommu is getting set to NULL some place other than > > unlink_domain_info(). I have no idea where that would be. > > > > Joerg, can you suggest any possibilities? > Hmm, looks like the domain is removed from the device before the > driver > is unbound. Can you please try the attached diff? > It seems that this patch solve the problem. This is the kernel log with your patch together with the one from alan. pciehp :06:03.0:pcie24: Card not present on Slot(3) pciehp :00:1c.4:pcie04: Card not present on Slot(4) pciehp :00:1c.4:pcie04: slot(4): Link Down event ehci-pci :0b:00.2: USB bus 7 deregistered pciehp :00:1c.4:pcie04: Link Down event ignored on slot(4): already powering off ohci-pci :0b:00.1: HC died; cleaning up ohci-pci :0b:00.1: remove, state 4 usb usb6: USB disconnect, device number 1 ohci-pci :0b:00.1: USB bus 6 deregistered ohci-pci :0b:00.0: HC died; cleaning up ohci-pci :0b:00.0: remove, state 4 usb usb5: USB disconnect, device number 1 ohci-pci :0b:00.0: USB bus 5 deregistered pciehp :09:03.0:pcie24: unloading service driver pciehp pciehp :09:03.0:pcie24: Timeout on hotplug command 0x1038 (issued 45628 msec ago) pciehp :09:03.0:pcie24: pcie_do_write_cmd: no response from device iommu: Removing device :0b:00.0 from group 20 pci :0b:00.0: unlink_domain_info CPU: 0 PID: 157 Comm: kworker/0:2 Not tainted 4.5.0-rc6-dirty #11 Hardware name: Dell Inc. XPS 2720/05R2TK , BIOS A12 09/21/2015 Workqueue: pciehp-3 pciehp_power_thread 880469c1bb88 80558bbb 880443898980 880447797000 880469c1bbc0 8063691c 0286 8804477972e0 0003 880447797098 Call Trace: [] dump_stack+0x4d/0x72 [] __dmar_remove_one_dev_info+0x20c/0x220 [] dmar_remove_one_dev_info.isra.55+0x27/0x40 [] device_notifier+0x43/0x80 [] notifier_call_chain+0x4a/0x70 [] __blocking_notifier_call_chain+0x47/0x60 [] blocking_notifier_call_chain+0x16/0x20 [] device_del+0x173/0x240 [] pci_remove_bus_device+0x77/0xf0 [] pci_remove_bus_device+0x31/0xf0 [] pci_remove_bus_device+0x31/0xf0 [] pci_remove_bus_device+0x31/0xf0 [] pci_stop_and_remove_bus_device+0x1a/0x20 [] pciehp_unconfigure_device+0x9b/0x180 [] pciehp_disable_slot+0x43/0xb0 [] pciehp_power_thread+0x8d/0xb0 [] process_one_work+0x140/0x3e0 [] worker_thread+0x4e/0x480 [] ? process_one_work+0x3e0/0x3e0 [] ? process_one_work+0x3e0/0x3e0 [] kthread+0xc9/0xe0 [] ? kthread_create_on_node+0x180/0x180 [] ret_from_fork+0x3f/0x70 [] ? kthread_create_on_node+0x180/0x180 iommu: Removing device :0b:00.1 from group 20 pci :0b:00.1: unlink_domain_info CPU: 0 PID: 157 Comm: kworker/0:2 Not tainted 4.5.0-rc6-dirty #11 Hardware name: Dell Inc. XPS 2720/05R2TK , BIOS A12 09/21/2015 Workqueue: pciehp-3 pciehp_power_thread 880469c1bb88 80558bbb 88042a8c0c40 880447796000 880469c1bbc0 8063691c 0286 8804477962e0 0003 880447796098 Call Trace: [] dump_stack+0x4d/0x72 [] __dmar_remove_one_dev_info+0x20c/0x220 [] dmar_remove_one_dev_info.isra.55+0x27/0x40 [] device_notifier+0x43/0x80 [] notifier_call_chain+0x4a/0x70 [] __blocking_notifier_call_chain+0x47/0x60 [] blocking_notifier_call_chain+0x16/0x20 [] device_del+0x173/0x240 [] pci_remove_bus_device+0x77/0xf0 [] pci_remove_bus_device+0x31/0xf0 [] pci_remove_bus_device+0x31/0xf0 [] pci_remove_bus_device+0x31/0xf0 [] pci_stop_and_remove_bus_device+0x1a/0x20 [] pciehp_unconfigure_device+0x9b/0x180 [] pciehp_disable_slot+0x43/0xb0 [] pciehp_power_thread+0x8d/0xb0 [] process_one_work+0x140/0x3e0 [] worker_thread+0x4e/0x480 [] ? process_one_work+0x3e0/0x3e0 [] ? process_one_work+0x3e0/0x3e0 [] kthread+0xc9/0xe0 [] ? kthread_create_on_node+0x180/0x180 [] ret_from_fork+0x3f/0x70 [] ? kthread_create_on_node+0x180/0x180 iommu: Removing device :0b:00.2 from group 20 pci :0b:00.2: unlink_domain_info CPU: 0 PID: 157 Comm: kworker/0:2 Not tainted 4.5.0-rc6-dirty #11 Hardware name: Dell Inc. XPS 2720/05R2TK , BIOS A12 09/21/2015 Workqueue: pciehp-3 pciehp_power_thread 880469c1bb88 80558bbb 880436a36fc0 88046458f000 880469c1bbc0 8063691c 0286 88046458f2e0 0003 88046458f098 Call Trace: [] dump_stack+0x4d/0x72 [] __dmar_remove_one_dev_info+0x20c/0x220 [] dmar_remove_one_dev_info.isra.55+0x27/0x40 [] device_notifier+0x43/0x80 [] notifier_call_chain+0x4a/0x70 [] __blocking_notifier_call_chain+0x47/0x60 [] blocking_notifier_call_chain+0x16/0x20 [] device_del+0x173/0x240 [] pci_remove_bus_device+0x77/0xf0 [] pci_remove_bus_device+0x31/0xf0 []
OHCI unplug kernel crash in kernel 4.3, 4.4 and 4.5
I still reported this bug 6 Weeks ago... and i checked it know with the current kernel 4.5.0-rc5. The bug is yet not fixed. A unplug of an USB 1.0 OHCI controller express card will result in a kernel crash. The express card is attached via thunderbolt and a sonnet express card to thunderbolt adapter. The computer hangs after the unplug, only a power down fix the situation. This is the kernel log of a kernel 4.4 via netconsole: pciehp :06:03.0:pcie24: Card not present on Slot(3) pciehp :06:03.0:pcie24: slot(3): Link Down event pciehp :06:03.0:pcie24: Link Down event ignored on slot(3): already powering off ehci-pci :0b:00.2: HC died; cleaning up ehci-pci :0b:00.2: remove, state 4 usb usb5: USB disconnect, device number 1 pciehp :00:1c.4:pcie04: Card not present on Slot(4) pciehp :00:1c.4:pcie04: slot(4): Link Down event ehci-pci :0b:00.2: USB bus 5 deregistered ohci-pci :0b:00.1: HC died; cleaning up ohci-pci :0b:00.1: remove, state 4 usb usb7: USB disconnect, device number 1 pciehp :00:1c.4:pcie04: Link Down event ignored on slot(4): already powering off ohci-pci :0b:00.1: USB bus 7 deregistered ohci-pci :0b:00.0: HC died; cleaning up ohci-pci :0b:00.0: remove, state 4 usb usb6: USB disconnect, device number 1 [ cut here ] kernel BUG at drivers/iommu/intel-iommu.c:3592! invalid opcode: [#1] PREEMPT SMP Modules linked in: ohci_pci ohci_hcd binfmt_misc netconsole configfs bbswitch(O) iwlmvm iwlwifi vboxnetadp(O) vboxnetflt(O) vboxdrv(O) nvidia(PO) vhost_net tun vhost kvm_intel kvm irqbypass dell_smm_hwmon [last unloaded: netconsole] CPU: 0 PID: 4857 Comm: kworker/0:3 Tainted: P O4.4.0- gentoo #1 Hardware name: Dell Inc. XPS 2720/05R2TK , BIOS A12 09/21/2015 Workqueue: pciehp-3 pciehp_power_thread task: 8804070a2300 ti: 8803e4658000 task.ti: 8803e4658000 RIP: 0010:[] [] intel_unmap+0x1c4/0x1d0 RSP: 0018:8803e465bb98 EFLAGS: 00010246 RAX: RBX: 8804225fb098 RCX: c000 RDX: RSI: c000 RDI: 8804225fb098 RBP: 8803e465bbd0 R08: R09: R10: 88046cc000c0 R11: R12: R13: c000 R14: 880468caa400 R15: e8c13800 FS: () GS:88047f20() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f2515680324 CR3: 0120a000 CR4: 001406f0 Stack: 8804101e4a78 8803e465bbf0 ea000f915840 812a3ec0 880468caa400 e8c13800 8803e465bbf0 8061ee8a 88045e68f000 8804225fb098 8803e465bc28 Call Trace: [] intel_free_coherent+0x5a/0xa0 [] ohci_stop+0x144/0x1c0 [ohci_hcd] [] usb_remove_hcd+0xe4/0x1a0 [] usb_hcd_pci_remove+0x63/0x130 [] pci_device_remove+0x39/0xc0 [] __device_release_driver+0x96/0x130 [] device_release_driver+0x23/0x30 [] pci_stop_bus_device+0x8a/0xa0 [] pci_stop_bus_device+0x31/0xa0 [] pci_stop_bus_device+0x31/0xa0 [] pci_stop_bus_device+0x31/0xa0 [] pci_stop_and_remove_bus_device+0x12/0x20 [] pciehp_unconfigure_device+0x9b/0x180 [] pciehp_disable_slot+0x43/0xb0 [] pciehp_power_thread+0x8d/0xb0 [] process_one_work+0x144/0x3c0 [] worker_thread+0x4b/0x440 [] ? process_one_work+0x3c0/0x3c0 [] ? process_one_work+0x3c0/0x3c0 [] kthread+0xc9/0xe0 [] ? kthread_create_on_node+0x180/0x180 [] ret_from_fork+0x3f/0x70 [] ? kthread_create_on_node+0x180/0x180 Code: f9 48 89 de e8 fe cd ff ff 4c 89 e6 4c 89 f7 e8 23 92 ff ff 4c 89 ef e8 0b cf ff ff 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d c3 <0f> 0b e8 45 cf ff ff e9 f3 fe ff ff 0f 1f 44 00 00 55 48 8b 76 RIP [] intel_unmap+0x1c4/0x1d0 RSP ---[ end trace ad0596f59dc3d9e0 ]--- BUG: unable to handle kernel paging request at ffd8 IP: [] kthread_data+0x11/0x20 PGD 120b067 PUD 120d067 PMD 0 Oops: [#2] PREEMPT SMP Modules linked in: ohci_pci ohci_hcd binfmt_misc netconsole configfs bbswitch(O) iwlmvm iwlwifi vboxnetadp(O) vboxnetflt(O) vboxdrv(O) nvidia(PO) vhost_net tun vhost kvm_intel kvm irqbypass dell_smm_hwmon [last unloaded: netconsole] CPU: 0 PID: 4857 Comm: kworker/0:3 Tainted: P DO4.4.0- gentoo #1 Hardware name: Dell Inc. XPS 2720/05R2TK , BIOS A12 09/21/2015 task: 8804070a2300 ti: 8803e4658000 task.ti: 8803e4658000 RIP: 0010:[] [] kthread_data+0x11/0x20 RSP: 0018:8803e465b878 EFLAGS: 00010002 RAX: RBX: RCX: 814bd980 RDX: RSI: RDI: 8804070a2300 RBP: 8803e465b888 R08: R09: 880468dfe901 R10: 2800 R11: 001a R12: R13: 000154c0 R14: 8804070a2300 R15: 88047f2154c0 FS: () GS:88047f20() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 0028 CR3: 0120a000 CR4:
Re: Missing USB XHCI and EHCI reset for kexec
Am Montag, den 14.04.2014, 12:27 -0400 schrieb Alan Stern: On Mon, 14 Apr 2014 stef...@seibold.net wrote: Zitat von Alan Stern st...@rowland.harvard.edu: 6[ 167.936921] usb 2-2.1: new full-speed USB device number 3 using ohci-pci 6[ 168.067890] usb 2-2.1: New USB device found, idVendor=076b, idProduct=a021 6[ 168.074871] usb 2-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 6[ 168.082226] usb 2-2.1: Product: Smart Card Reader 6[ 168.086963] usb 2-2.1: Manufacturer: USB 6[ 168.172893] usb 2-2.2: new low-speed USB device number 4 using ohci-pci 6[ 168.300839] usb 2-2.2: New USB device found, idVendor=0aad, idProduct=0024 6[ 168.307823] usb 2-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 6[ 168.315180] usb 2-2.2: Product: FrontPanel USB Keyboard 6[ 168.320436] usb 2-2.2: Manufacturer: RohdeSchwarz 6[ 168.337895] input: RohdeSchwarz FrontPanel USB Keyboard as /devices/pci:00/:00:17.0/usb2/2-2/2-2.2/2-2.2:1.0/input/input0 6[ 168.360988] input: RohdeSchwarz FrontPanel USB Keyboard as /devices/pci:00/:00:17.0/usb2/2-2/2-2.2/2-2.2:1.1/input/input1 Since some devices work and some don't, maybe part of the problem lies in the particular devices. The problem lies on the Bus 001 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub, which hangs for arround 162 seconds after a kexec. The Bus 002 Device 003: ID 076b:a021 OmniKey AG CCID Smart Card Reader and Bus 002 Device 004: ID 0aad:0024 Rohde Schwarz GmbH Co. KG are attached to this Hub. What about if you just do: rmmod ehci-pci modprobe ehci-pci The kernel is monolitic because the USB HW is needed in a early boot stage. The problem also occurs with ehci-fsl used in by an other PowerPC device, which is a part of the SoC and is not attached to the PCI bus. One thing is that the echo 1 /sys/bus/pci/drivers/ehci-pci/\:00\:17.2/reset workaround will no longer work for kernel 3.14. Instead, you could try echo :00:17.2 /sys/bus/pci/drivers/ehci-pci/unbind echo :00:17.2 /sys/bus/pci/drivers/ehci-pci/bind I did a unbind and bind of the ehci-pci and ohci-pci, after this i got the following dmesg log: ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ehci-pci: EHCI PCI platform driver ehci-pci :00:17.2: EHCI Host Controller ehci-pci :00:17.2: new USB bus registered, assigned bus number 1 ehci-pci :00:17.2: irq 22, io mem 0xc0006800 ehci-pci :00:17.2: USB 2.0 started, EHCI 1.00 hub 1-0:1.0: USB hub found hub 1-0:1.0: 5 ports detected ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver ohci_hcd :00:17.0: OHCI Host Controller ohci_hcd :00:17.0: new USB bus registered, assigned bus number 2 ohci_hcd :00:17.0: irq 20, io mem 0xc0004000 hub 2-0:1.0: USB hub found hub 2-0:1.0: 3 ports detected ohci_hcd :00:17.1: OHCI Host Controller ohci_hcd :00:17.1: new USB bus registered, assigned bus number 3 ohci_hcd :00:17.1: irq 21, io mem 0xc0005000 hub 3-0:1.0: USB hub found hub 3-0:1.0: 2 ports detected Freescale High-Speed USB SOC Device Controller driver (Apr 20, 2007) mousedev: PS/2 mouse device common for all mice i2c /dev entries driver mpc-i2c fef03000.i2c: timeout 100 us rtc-rs5c372 0-0032: rs5c372a found, 24hr, driver version 0.6 rtc-rs5c372 0-0032: rtc core: registered rtc-rs5c372 as rtc0 mpc-i2c fef03100.i2c: timeout 100 us usbcore: registered new interface driver usbhid usbhid: USB HID core driver rsfrontp: using key table SMBV (117) usbcore: registered new interface driver rsfrontp rsfrontp: RS USB HID Frontpanel driver (v1.2) usbcore: registered new interface driver rsknop rsknop: RS USB HID Knop support (v1.4) usb 1-2: new high-speed USB device number 2 using ehci-pci zram: Created 1 device(s) ... TCP: cubic registered NET: Registered protocol family 17 rtc-rs5c372 0-0032: setting system clock to 2014-04-14 14:51:50 UTC (1397487110) Freeing unused kernel memory: 996K (c032e000 - c0427000) hub 1-2:1.0: USB hub found hub 1-2:1.0: 4 ports detected yaffs: dev is 32505859 name is mtdblock3 rw yaffs: passed flags yaffs: yaffs: Attempting MTD mount of 31.3,mtdblock3 yaffs: auto selecting yaffs2 yaffs: yaffs_read_super: is_checkpointed 1 usb 2-2: new full-speed USB device number 2 using ohci_hcd hub 2-2:1.0: USB hub found hub 2-2:1.0: 2 ports detected usbcore: registered new interface driver usb-storage usb 2-2.1: new full-speed USB device number 3 using ohci_hcd usb 2-2.2: new low-speed USB device number 4 using ohci_hcd input: RohdeSchwarz FrontPanel USB Keyboard as /devices/pci:00/:00:17.0/usb2/2-2/2-2.2/2-2.2:1.0/input/input0 fsl-gianfar fef24000.ethernet eth0: mac: 00:90:b8:1b:36:37 input: RohdeSchwarz FrontPanel USB Keyboard as /devices/pci:00/:00:17.0/usb2/2-2/2-2.2/2-2.2:1.1/input/input1 fsl-gianfar fef24000.ethernet eth0: Running
Re: Missing USB XHCI and EHCI reset for kexec
Am Montag, den 14.04.2014, 13:58 -0400 schrieb Alan Stern: On Mon, 14 Apr 2014, Stefani Seibold wrote: An other PowerPC device which is nearly eactly the same HW but without this USB HUB works perfectly. Maybe you should replace that hub with a different brand. Thats not possible, because the Hub is soldered on the board. And it is also not a HW issue, since the Hub works perfectly which all previous kernels including 3.4. One other thing you can try is to increase the reset timeout in drivers/usb/host/ehci-hub.c. This is under the USB_PORT_FEAT_RESET case in ehci_hub_control(), around line 1225: /* * caller must wait, then call GetPortStatus * usb 2.0 spec says 50 ms resets on root */ ehci-reset_done [wIndex] = jiffies + msecs_to_jiffies (50); Increasing the 50 to 100 or more might help. Alan Stern I tried this, when i increase the value to 1000, the reset and enumeration process will be faster after a kexec: 28 Seconds vs. 162 Seconds. - Stefani -- 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: Missing USB XHCI and EHCI reset for kexec
Am Dienstag, den 15.04.2014, 15:33 -0300 schrieb Thadeu Lima de Souza Cascardo: On Tue, Apr 15, 2014 at 05:00:28PM +0200, stef...@seibold.net wrote: Zitat von Thadeu Lima de Souza Cascardo casca...@linux.vnet.ibm.com: On Tue, Apr 15, 2014 at 12:04:17PM +0200, stef...@seibold.net wrote: Zitat von Thadeu Lima de Souza Cascardo casca...@linux.vnet.ibm.com: On Mon, Apr 14, 2014 at 05:44:58PM +0200, stef...@seibold.net wrote: Zitat von Benjamin Herrenschmidt b...@au1.ibm.com: I don't know about EHCI specifically but this is a known issue with XHCI, I observe similar issues on other powerpc platforms (servers) and this isn't architecture specific (looks more like actualy xhc implementation specific). Thadeu Cascardo (on CC) has been the one investigating that on our side, he might have more to add including patches. I have now a kernel 3.14 dmesg log of the problem. After a kexec the kexeced 3.14 kernel shows: [1.170029] xhci_hcd 0001:03:00.0: xHCI Host Controller [1.175306] xhci_hcd 0001:03:00.0: new USB bus registered, assigned bus number 1 [1.212561] xhci_hcd 0001:03:00.0: Host not halted after 16000 microseconds. [1.219621] xhci_hcd 0001:03:00.0: can't setup: -110 [1.224597] xhci_hcd 0001:03:00.0: USB bus 1 deregistered [1.230021] xhci_hcd 0001:03:00.0: init 0001:03:00.0 fail, -110 [1.235955] xhci_hcd: probe of 0001:03:00.0 failed with error -110 What is your controller vendor and device IDs? Is that a TI chip? Yes it is a TI chip, vendor ID 104c and product ID 8241. Can you check if the patch I sent a month ago fixes it? [1] There's the whole story there. In fact, you will also need something like the patch below. Can you apply only the first one, verify, and, then, the other one as well, and report what worked for you? [1] http://marc.info/?l=linux-usbm=139483181809062w=2 I tried the attach patch and it did not help. This is what i expected because this is a fix in the shutdown path, which will never called when doing a forced kexec. Hi, Stefani. Did you try with both patches applied? How do you evoke the forced kexec? Is that a kexec on panic? Does it really need to be forced? With no clean shutdown, platform and drivers would need to issue resets, like you mentioned below, to get the system into a clean state. Yes, i applied both patches. But without success. IMHO i think it is necessary to bring the device i a clean state when the driver use the HW. I have a running a 3.10.23 kernel. This kernel do a kexec for a kernel 3.14. Since the kernel 3.10.23 did not performe a clean shutdown, the state of the XHCI Controller is undefined. So when And the clean shutdown requires both of my patches, for TI chips, as far as I know. It looks like the problem is issuing a halt when there are pending URBs. kernel 3.14 will probe XHCI it will find a XHCI controller which was not performed a reset. The problem is not that a reset hasn't been issued. A PCI function reset should fix most of the problems with a bad device state, when the reset works. However, the problem is that it was not cleanly shut down. URBs should have been canceled and removed from the controller queue, and it should have halted after that. Again, i think it is the job of the driver to bring the chip in a clean state before using them. A driver should never expect a reset state of a chip. So i think it is necessary to reset the XHCI controller and all devices on this bus. This is what i do with a echo 1 /sys/bus/pci/drivers/xhci_hcd/0001:03:00.0/reset before the kexec. One way to look at that is making the PCI code issue resets to all buses before doing any other access. That will make booting more slow, and there are a lot of other corner cases where this might not be enough. It's probably more sane to try to get the 3.10.23 kernel to do a clean shutdown, if possible. With this driver design the kexec functionality is usesless on PowerPC. X86 looks a little bit better. - Stefani What is the vendor and device ID you are using on your X86 system? This is not a matter of what architecture you are using, it's the XHCI controller which does not behave as well as the one you are using on X86, which is likely an Intel one. It is an Intel 8086:8c31. But this was only a side note. We need a generic solution not a vendor specific one. Otherwise kexec is useless on other architectures. - Stefani -- 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: Missing USB XHCI and EHCI reset for kexec
Am Dienstag, den 15.04.2014, 15:49 -0300 schrieb Thadeu Lima de Souza Cascardo: On Tue, Apr 15, 2014 at 08:42:58PM +0200, Stefani Seibold wrote: Am Dienstag, den 15.04.2014, 15:33 -0300 schrieb Thadeu Lima de Souza Cascardo: On Tue, Apr 15, 2014 at 05:00:28PM +0200, stef...@seibold.net wrote: Zitat von Thadeu Lima de Souza Cascardo casca...@linux.vnet.ibm.com: On Tue, Apr 15, 2014 at 12:04:17PM +0200, stef...@seibold.net wrote: Zitat von Thadeu Lima de Souza Cascardo casca...@linux.vnet.ibm.com: On Mon, Apr 14, 2014 at 05:44:58PM +0200, stef...@seibold.net wrote: Zitat von Benjamin Herrenschmidt b...@au1.ibm.com: I don't know about EHCI specifically but this is a known issue with XHCI, I observe similar issues on other powerpc platforms (servers) and this isn't architecture specific (looks more like actualy xhc implementation specific). Thadeu Cascardo (on CC) has been the one investigating that on our side, he might have more to add including patches. I have now a kernel 3.14 dmesg log of the problem. After a kexec the kexeced 3.14 kernel shows: [1.170029] xhci_hcd 0001:03:00.0: xHCI Host Controller [1.175306] xhci_hcd 0001:03:00.0: new USB bus registered, assigned bus number 1 [1.212561] xhci_hcd 0001:03:00.0: Host not halted after 16000 microseconds. [1.219621] xhci_hcd 0001:03:00.0: can't setup: -110 [1.224597] xhci_hcd 0001:03:00.0: USB bus 1 deregistered [1.230021] xhci_hcd 0001:03:00.0: init 0001:03:00.0 fail, -110 [1.235955] xhci_hcd: probe of 0001:03:00.0 failed with error -110 What is your controller vendor and device IDs? Is that a TI chip? Yes it is a TI chip, vendor ID 104c and product ID 8241. Can you check if the patch I sent a month ago fixes it? [1] There's the whole story there. In fact, you will also need something like the patch below. Can you apply only the first one, verify, and, then, the other one as well, and report what worked for you? [1] http://marc.info/?l=linux-usbm=139483181809062w=2 I tried the attach patch and it did not help. This is what i expected because this is a fix in the shutdown path, which will never called when doing a forced kexec. Hi, Stefani. Did you try with both patches applied? How do you evoke the forced kexec? Is that a kexec on panic? Does it really need to be forced? With no clean shutdown, platform and drivers would need to issue resets, like you mentioned below, to get the system into a clean state. Yes, i applied both patches. But without success. IMHO i think it is necessary to bring the device i a clean state when the driver use the HW. I have a running a 3.10.23 kernel. This kernel do a kexec for a kernel 3.14. Since the kernel 3.10.23 did not performe a clean shutdown, the state of the XHCI Controller is undefined. So when And the clean shutdown requires both of my patches, for TI chips, as far as I know. It looks like the problem is issuing a halt when there are pending URBs. kernel 3.14 will probe XHCI it will find a XHCI controller which was not performed a reset. The problem is not that a reset hasn't been issued. A PCI function reset should fix most of the problems with a bad device state, when the reset works. However, the problem is that it was not cleanly shut down. URBs should have been canceled and removed from the controller queue, and it should have halted after that. Again, i think it is the job of the driver to bring the chip in a clean state before using them. A driver should never expect a reset state of a chip. So i think it is necessary to reset the XHCI controller and all devices on this bus. This is what i do with a echo 1 /sys/bus/pci/drivers/xhci_hcd/0001:03:00.0/reset before the kexec. One way to look at that is making the PCI code issue resets to all buses before doing any other access. That will make booting more slow, and there are a lot of other corner cases where this might not be enough. It's probably more sane to try to get the 3.10.23 kernel to do a clean shutdown, if possible. With this driver design the kexec functionality is usesless on PowerPC. X86 looks a little bit better. - Stefani What is the vendor and device ID you are using on your X86 system? This is not a matter of what architecture you are using, it's the XHCI controller which does not behave as well as the one you are using on X86, which is likely an Intel one. It is an Intel 8086:8c31. But this was only a side note. We need a generic solution not a vendor specific one. Otherwise kexec
Re: Missing USB XHCI and EHCI reset for kexec
Am Dienstag, den 15.04.2014, 15:02 -0400 schrieb Alan Stern: On Tue, 15 Apr 2014, Stefani Seibold wrote: I did a unbind and bind of the ehci-pci and ohci-pci, after this i got the following dmesg log: ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ehci-pci: EHCI PCI platform driver ehci-pci :00:17.2: EHCI Host Controller ehci-pci :00:17.2: new USB bus registered, assigned bus number 1 ehci-pci :00:17.2: irq 22, io mem 0xc0006800 ehci-pci :00:17.2: USB 2.0 started, EHCI 1.00 hub 1-0:1.0: USB hub found hub 1-0:1.0: 5 ports detected ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver ohci_hcd :00:17.0: OHCI Host Controller ohci_hcd :00:17.0: new USB bus registered, assigned bus number 2 ohci_hcd :00:17.0: irq 20, io mem 0xc0004000 hub 2-0:1.0: USB hub found hub 2-0:1.0: 3 ports detected ohci_hcd :00:17.1: OHCI Host Controller ohci_hcd :00:17.1: new USB bus registered, assigned bus number 3 ohci_hcd :00:17.1: irq 21, io mem 0xc0005000 hub 3-0:1.0: USB hub found hub 3-0:1.0: 2 ports detected ... usbcore: registered new interface driver USB-SATA-storage USB SATA Mass Storage support registered. usb 1-4: new high-speed USB device number 4 using ehci-pci : ports detected What driver is this? I've never heard of USB-SATA-storage. This is a special embedded USB SATA driver written by me. It is mostly a fork of the usb-storage driver but handle only one vendor and product ID and does switch on a port bit. On the other side this vendor and product ID is black listed in the regular usb-storage driver. ohci_hcd :00:17.0: remove, state 1 usb usb2: USB disconnect, device number 1 usb 2-2: USB disconnect, device number 2 usb 2-2.1: USB disconnect, device number 3 usb 2-2.2: USB disconnect, device number 4 ohci_hcd :00:17.0: USB bus 2 deregistered ohci_hcd :00:17.1: remove, state 1 usb usb3: USB disconnect, device number 1 ohci_hcd :00:17.1: USB bus 3 deregistered ehci-pci :00:17.2: remove, state 1 usb usb1: USB disconnect, device number 1 usb 1-2: USB disconnect, device number 2 usb 1-4: USB disconnect, device number 4 ehci-pci :00:17.2: USB bus 1 deregistered ohci_hcd :00:17.0: OHCI Host Controller ohci_hcd :00:17.0: new USB bus registered, assigned bus number 1 ohci_hcd :00:17.0: irq 20, io mem 0xc0004000 hub 1-0:1.0: USB hub found hub 1-0:1.0: 3 ports detected ohci_hcd :00:17.1: OHCI Host Controller ohci_hcd :00:17.1: new USB bus registered, assigned bus number 2 ohci_hcd :00:17.1: irq 21, io mem 0xc0005000 hub 2-0:1.0: USB hub found hub 2-0:1.0: 2 ports detected ehci-pci :00:17.2: EHCI Host Controller ehci-pci :00:17.2: new USB bus registered, assigned bus number 3 ehci-pci :00:17.2: irq 22, io mem 0xc0006800 ehci-pci :00:17.2: USB 2.0 started, EHCI 1.00 hub 3-0:1.0: USB hub found hub 3-0:1.0: 5 ports detected hub 1-0:1.0: USB hub found hub 1-0:1.0: 3 ports detected hub 2-0:1.0: USB hub found hub 2-0:1.0: 2 ports detected usb 3-2: new high-speed USB device number 2 using ehci-pci hub 3-2:1.0: USB hub found hub 3-2:1.0: 4 ports detected usb 3-4: new high-speed USB device number 4 using ehci-pci usb 3-4: device descriptor read/64, error -110 usb 3-4: device descriptor read/64, error -110 usb 3-4: new high-speed USB device number 5 using ehci-pci usb 3-4: device descriptor read/64, error -110 usb 3-4: device descriptor read/64, error -110 usb 3-4: new high-speed USB device number 6 using ehci-pci usb 3-4: device descriptor read/8, error -110 usb 3-4: device descriptor read/8, error -110 usb 3-4: new high-speed USB device number 7 using ehci-pci usb 3-4: device descriptor read/8, error -110 usb 3-4: device descriptor read/8, error -110 hub 3-0:1.0: unable to enumerate USB device on port 4 usb 1-2: new full-speed USB device number 2 using ohci_hcd hub 1-2:1.0: USB hub found hub 1-2:1.0: 2 ports detected usb 2-2: new full-speed USB device number 2 using ohci_hcd usb 2-2: device descriptor read/64, error -110 usb 2-2: device descriptor read/64, error -110 usb 2-2: new full-speed USB device number 3 using ohci_hcd usb 2-2: device descriptor read/64, error -110 usb 2-2: device descriptor read/64, error -110 usb 2-2: new full-speed USB device number 4 using ohci_hcd usb 2-2: device descriptor read/8, error -110 usb 2-2: device descriptor read/8, error -110 usb 2-2: new full-speed USB device number 5 using ohci_hcd usb 2-2: device descriptor read/8, error -110 usb 2-2: device descriptor read/8, error -110 hub 2-0:1.0: unable to enumerate USB device on port 2 usb 1-2.1: new full-speed USB device number 3 using ohci_hcd usb 1-2.2: new low-speed USB device number 4 using ohci_hcd input: RohdeSchwarz FrontPanel USB Keyboard as /devices/pci:00/:00:17.0/usb1/1-2/1-2.2/1-2.2:1.0/input/input2 input
Re: Missing USB XHCI and EHCI reset for kexec
Am Dienstag, den 15.04.2014, 15:05 -0400 schrieb Alan Stern: On Tue, 15 Apr 2014, Stefani Seibold wrote: One other thing you can try is to increase the reset timeout in drivers/usb/host/ehci-hub.c. This is under the USB_PORT_FEAT_RESET case in ehci_hub_control(), around line 1225: /* * caller must wait, then call GetPortStatus * usb 2.0 spec says 50 ms resets on root */ ehci-reset_done [wIndex] = jiffies + msecs_to_jiffies (50); Increasing the 50 to 100 or more might help. Alan Stern I tried this, when i increase the value to 1000, the reset and enumeration process will be faster after a kexec: 28 Seconds vs. 162 Seconds. Even 28 seconds is much longer than it should be. And a 1000-ms long reset signal is a lot longer than any device should need. Anyway, since you saw the same problem after unbind and rebind, you don't have to perform a kexec for testing. Right, but i would prefer a solution for this. Since it works perfectly in kernel 3.4 i don't think it is a hardware issue. - Stefani -- 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: Missing USB XHCI and EHCI reset for kexec
Am Dienstag, den 15.04.2014, 15:02 -0400 schrieb Alan Stern: On Tue, 15 Apr 2014, Stefani Seibold wrote: I did a unbind and bind of the ehci-pci and ohci-pci, after this i got the following dmesg log: ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ehci-pci: EHCI PCI platform driver ehci-pci :00:17.2: EHCI Host Controller ehci-pci :00:17.2: new USB bus registered, assigned bus number 1 ehci-pci :00:17.2: irq 22, io mem 0xc0006800 ehci-pci :00:17.2: USB 2.0 started, EHCI 1.00 hub 1-0:1.0: USB hub found hub 1-0:1.0: 5 ports detected ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver ohci_hcd :00:17.0: OHCI Host Controller ohci_hcd :00:17.0: new USB bus registered, assigned bus number 2 ohci_hcd :00:17.0: irq 20, io mem 0xc0004000 hub 2-0:1.0: USB hub found hub 2-0:1.0: 3 ports detected ohci_hcd :00:17.1: OHCI Host Controller ohci_hcd :00:17.1: new USB bus registered, assigned bus number 3 ohci_hcd :00:17.1: irq 21, io mem 0xc0005000 hub 3-0:1.0: USB hub found hub 3-0:1.0: 2 ports detected ... usbcore: registered new interface driver USB-SATA-storage USB SATA Mass Storage support registered. usb 1-4: new high-speed USB device number 4 using ehci-pci : ports detected What driver is this? I've never heard of USB-SATA-storage. ohci_hcd :00:17.0: remove, state 1 usb usb2: USB disconnect, device number 1 usb 2-2: USB disconnect, device number 2 usb 2-2.1: USB disconnect, device number 3 usb 2-2.2: USB disconnect, device number 4 ohci_hcd :00:17.0: USB bus 2 deregistered ohci_hcd :00:17.1: remove, state 1 usb usb3: USB disconnect, device number 1 ohci_hcd :00:17.1: USB bus 3 deregistered ehci-pci :00:17.2: remove, state 1 usb usb1: USB disconnect, device number 1 usb 1-2: USB disconnect, device number 2 usb 1-4: USB disconnect, device number 4 ehci-pci :00:17.2: USB bus 1 deregistered ohci_hcd :00:17.0: OHCI Host Controller ohci_hcd :00:17.0: new USB bus registered, assigned bus number 1 ohci_hcd :00:17.0: irq 20, io mem 0xc0004000 hub 1-0:1.0: USB hub found hub 1-0:1.0: 3 ports detected ohci_hcd :00:17.1: OHCI Host Controller ohci_hcd :00:17.1: new USB bus registered, assigned bus number 2 ohci_hcd :00:17.1: irq 21, io mem 0xc0005000 hub 2-0:1.0: USB hub found hub 2-0:1.0: 2 ports detected ehci-pci :00:17.2: EHCI Host Controller ehci-pci :00:17.2: new USB bus registered, assigned bus number 3 ehci-pci :00:17.2: irq 22, io mem 0xc0006800 ehci-pci :00:17.2: USB 2.0 started, EHCI 1.00 hub 3-0:1.0: USB hub found hub 3-0:1.0: 5 ports detected hub 1-0:1.0: USB hub found hub 1-0:1.0: 3 ports detected hub 2-0:1.0: USB hub found hub 2-0:1.0: 2 ports detected usb 3-2: new high-speed USB device number 2 using ehci-pci hub 3-2:1.0: USB hub found hub 3-2:1.0: 4 ports detected usb 3-4: new high-speed USB device number 4 using ehci-pci usb 3-4: device descriptor read/64, error -110 usb 3-4: device descriptor read/64, error -110 usb 3-4: new high-speed USB device number 5 using ehci-pci usb 3-4: device descriptor read/64, error -110 usb 3-4: device descriptor read/64, error -110 usb 3-4: new high-speed USB device number 6 using ehci-pci usb 3-4: device descriptor read/8, error -110 usb 3-4: device descriptor read/8, error -110 usb 3-4: new high-speed USB device number 7 using ehci-pci usb 3-4: device descriptor read/8, error -110 usb 3-4: device descriptor read/8, error -110 hub 3-0:1.0: unable to enumerate USB device on port 4 usb 1-2: new full-speed USB device number 2 using ohci_hcd hub 1-2:1.0: USB hub found hub 1-2:1.0: 2 ports detected usb 2-2: new full-speed USB device number 2 using ohci_hcd usb 2-2: device descriptor read/64, error -110 usb 2-2: device descriptor read/64, error -110 usb 2-2: new full-speed USB device number 3 using ohci_hcd usb 2-2: device descriptor read/64, error -110 usb 2-2: device descriptor read/64, error -110 usb 2-2: new full-speed USB device number 4 using ohci_hcd usb 2-2: device descriptor read/8, error -110 usb 2-2: device descriptor read/8, error -110 usb 2-2: new full-speed USB device number 5 using ohci_hcd usb 2-2: device descriptor read/8, error -110 usb 2-2: device descriptor read/8, error -110 hub 2-0:1.0: unable to enumerate USB device on port 2 usb 1-2.1: new full-speed USB device number 3 using ohci_hcd usb 1-2.2: new low-speed USB device number 4 using ohci_hcd input: RohdeSchwarz FrontPanel USB Keyboard as /devices/pci:00/:00:17.0/usb1/1-2/1-2.2/1-2.2:1.0/input/input2 input: RohdeSchwarz FrontPanel USB Keyboard as /devices/pci:00/:00:17.0/usb1/1-2/1-2.2/1-2.2:1.1/input/input3 So two devices failed to initialize after the drivers were rebound: 3-4 and 2-2. We know that 3-4 was the mass-storage device, but I can't tell from this log
Re: Missing USB XHCI and EHCI reset for kexec
Am Dienstag, den 15.04.2014, 15:14 -0400 schrieb Alan Stern: On Tue, 15 Apr 2014, Stefani Seibold wrote: usbcore: registered new interface driver USB-SATA-storage USB SATA Mass Storage support registered. usb 1-4: new high-speed USB device number 4 using ehci-pci : ports detected What driver is this? I've never heard of USB-SATA-storage. This is a special embedded USB SATA driver written by me. It is mostly a fork of the usb-storage driver but handle only one vendor and product ID and does switch on a port bit. On the other side this vendor and product ID is black listed in the regular usb-storage driver. Is it possible that your driver leaves the device in a strange state where it won't initialize properly? I don't think so, because the driver was not used in this test due a missing harddisk. But i will do a test tomorrow in the office. - Stefani -- 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: Missing USB XHCI and EHCI reset for kexec
Am Montag, den 14.04.2014, 12:27 -0400 schrieb Alan Stern: On Mon, 14 Apr 2014 stef...@seibold.net wrote: Zitat von Alan Stern st...@rowland.harvard.edu: 6[ 167.936921] usb 2-2.1: new full-speed USB device number 3 using ohci-pci 6[ 168.067890] usb 2-2.1: New USB device found, idVendor=076b, idProduct=a021 6[ 168.074871] usb 2-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 6[ 168.082226] usb 2-2.1: Product: Smart Card Reader 6[ 168.086963] usb 2-2.1: Manufacturer: USB 6[ 168.172893] usb 2-2.2: new low-speed USB device number 4 using ohci-pci 6[ 168.300839] usb 2-2.2: New USB device found, idVendor=0aad, idProduct=0024 6[ 168.307823] usb 2-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 6[ 168.315180] usb 2-2.2: Product: FrontPanel USB Keyboard 6[ 168.320436] usb 2-2.2: Manufacturer: RohdeSchwarz 6[ 168.337895] input: RohdeSchwarz FrontPanel USB Keyboard as /devices/pci:00/:00:17.0/usb2/2-2/2-2.2/2-2.2:1.0/input/input0 6[ 168.360988] input: RohdeSchwarz FrontPanel USB Keyboard as /devices/pci:00/:00:17.0/usb2/2-2/2-2.2/2-2.2:1.1/input/input1 Since some devices work and some don't, maybe part of the problem lies in the particular devices. The problem lies on the Bus 001 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub, which hangs for arround 162 seconds after a kexec. The Bus 002 Device 003: ID 076b:a021 OmniKey AG CCID Smart Card Reader and Bus 002 Device 004: ID 0aad:0024 Rohde Schwarz GmbH Co. KG are attached to this Hub. Actually, it looks like they are plugged into the Texas Instruments hub, not the Standard Microsystems hub (because they are on bus 2, not bus 1). Did you rearrange the USB cables? You are right, sorry for the confusion. I can't rearrange the cables because the HUB is on board. An other PowerPC device which is nearly eactly the same HW but without this USB HUB works perfectly. Maybe you should replace that hub with a different brand. Thats not possible, because the Hub is soldered on the board. And it is also not a HW issue, since the Hub works perfectly which all previous kernels including 3.4. This is the output of lsusb: Bus 001 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub Bus 001 Device 004: ID 0928:0007 Oxford Semiconductor, Ltd Bus 002 Device 002: ID 0451:2036 Texas Instruments, Inc. TUSB2036 Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 003: ID 076b:a021 OmniKey AG CCID Smart Card Reader Bus 002 Device 004: ID 0aad:0024 Rohde Schwarz GmbH Co. KG Here, the only device that might be plugged into the Standard Microsystems hub is the Oxford Semiconductor thing (whatever it is). What about if you just do: rmmod ehci-pci modprobe ehci-pci The kernel is monolitic because the USB HW is needed in a early boot stage. The problem also occurs with ehci-fsl used in by an other PowerPC device, which is a part of the SoC and is not attached to the PCI bus. One thing is that the echo 1 /sys/bus/pci/drivers/ehci-pci/\:00\:17.2/reset workaround will no longer work for kernel 3.14. Instead, you could try echo :00:17.2 /sys/bus/pci/drivers/ehci-pci/unbind echo :00:17.2 /sys/bus/pci/drivers/ehci-pci/bind I am now at home. I will do this tomorrow. Thanks so much for your support. - Stefani -- 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
EHCI hotplug kernel crash in kernel 3.14 and 3.13
A hot plug of an USB 2.0 EHCI controller cardbus card will result in a kernel crash. This is the kernel log of a vanilla 3.14 x86_64 kernel. I will attach my kernel config. [ 70.418181] pcmcia_socket pcmcia_socket0: pccard: CardBus card inserted into slot 0 [ 70.418209] pci :04:00.0: [1033:0035] type 00 class 0x0c0310 [ 70.418239] pci :04:00.0: reg 0x10: [mem 0x-0x0fff] [ 70.418359] pci :04:00.0: supports D1 D2 [ 70.418362] pci :04:00.0: PME# supported from D0 D1 D2 D3hot [ 70.418500] pci :04:00.1: [1033:0035] type 00 class 0x0c0310 [ 70.418529] pci :04:00.1: reg 0x10: [mem 0x-0x0fff] [ 70.418653] pci :04:00.1: supports D1 D2 [ 70.418655] pci :04:00.1: PME# supported from D0 D1 D2 D3hot [ 70.418756] pci :04:00.2: [1033:00e0] type 00 class 0x0c0320 [ 70.418784] pci :04:00.2: reg 0x10: [mem 0x-0x00ff] [ 70.418912] pci :04:00.2: supports D1 D2 [ 70.418915] pci :04:00.2: PME# supported from D0 D1 D2 D3hot [ 70.419040] pci :04:00.0: BAR 0: assigned [mem 0xf140-0xf1400fff] [ 70.419051] pci :04:00.1: BAR 0: assigned [mem 0xf1401000-0xf1401fff] [ 70.419059] pci :04:00.2: BAR 0: assigned [mem 0xf1402000-0xf14020ff] [ 70.419112] pci :04:00.0: enabling device ( - 0002) [ 70.419350] pci :04:00.1: enabling device ( - 0002) [ 70.419508] pci :04:00.2: enabling device ( - 0002) [ 70.419755] ehci-pci :04:00.2: EHCI Host Controller [ 70.419874] ehci-pci :04:00.2: new USB bus registered, assigned bus number 9 [ 70.419980] ehci-pci :04:00.2: irq 19, io mem 0xf1402000 [ 70.422796] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 70.424894] ohci-pci: OHCI PCI platform driver [ 70.425072] ehci-pci :04:00.2: USB 2.0 started, EHCI 0.95 [ 70.425132] usb usb9: New USB device found, idVendor=1d6b, idProduct=0002 [ 70.425135] usb usb9: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 70.425138] usb usb9: Product: EHCI Host Controller [ 70.425141] usb usb9: Manufacturer: Linux 3.14.0 ehci_hcd [ 70.425144] usb usb9: SerialNumber: :04:00.2 [ 70.425332] hub 9-0:1.0: USB hub found [ 70.425344] hub 9-0:1.0: 5 ports detected [ 70.425556] BUG: unable to handle kernel NULL pointer dereference at 0040 [ 70.425560] IP: [814947cc] usb_set_configuration+0x1c/0x7d0 [ 70.425568] PGD 30d571067 PUD 30d570067 PMD 0 [ 70.425572] Oops: [#1] PREEMPT SMP [ 70.425576] Modules linked in: ohci_pci(+) ohci_hcd rfcomm btusb ppdev intel_agp intel_gtt 8250 video parport_pc parport serial_core nvidia(PO) drm agpgart [ 70.425604] CPU: 3 PID: 83 Comm: pccardd Tainted: P O 3.14.0 #1 [ 70.425607] Hardware name: Dell Inc. Precision M6400 /0G841G, BIOS A13 06/05/2013 [ 70.425609] task: 88030eefe150 ti: 88030ef86000 task.ti: 88030ef86000 [ 70.425611] RIP: 0010:[814947cc] [814947cc] usb_set_configuration+0x1c/0x7d0 [ 70.425615] RSP: 0018:88030ef87ba0 EFLAGS: 00010286 [ 70.425617] RAX: 88030c7ce800 RBX: RCX: 88030ea57000 [ 70.425619] RDX: 88030dcb6800 RSI: 0001 RDI: [ 70.425620] RBP: 88030ef87c38 R08: 88030dfa6910 R09: [ 70.425622] R10: 4e2e R11: R12: [ 70.425624] R13: R14: 814a0b80 R15: 88030c7ce800 [ 70.425626] FS: () GS:88031fd8() knlGS: [ 70.425628] CS: 0010 DS: ES: CR0: 8005003b [ 70.425630] CR2: 0040 CR3: 00030c714000 CR4: 000407e0 [ 70.425631] Stack: [ 70.425632] 81340110 814a0b80 88030ef87bc8 817b3858 [ 70.425636] 88030dcb6898 88030ef87c00 813d6daf 88030f429000 [ 70.425640] 00010ef87bf0 813d4737 88030ef87c00 8133f19a [ 70.425644] Call Trace: [ 70.425650] [81340110] ? pci_do_find_bus+0x70/0x70 [ 70.425653] [814a0b80] ? hcd_pci_suspend_noirq+0xa0/0xa0 [ 70.425659] [817b3858] ? klist_iter_exit+0x18/0x30 [ 70.425663] [813d6daf] ? bus_find_device+0x7f/0xb0 [ 70.425666] [813d4737] ? put_device+0x17/0x20 [ 70.425669] [8133f19a] ? pci_dev_put+0x1a/0x20 [ 70.425672] [81340361] ? pci_get_dev_by_id+0x61/0x90 [ 70.425675] [814a0b80] ? hcd_pci_suspend_noirq+0xa0/0xa0 [ 70.425679] [814a0bcb] ehci_post_add+0x4b/0x60 [ 70.425682] [814a0070] for_each_companion+0x80/0xa0 [ 70.425685] [814a0504] usb_hcd_pci_probe+0x474/0x4e0 [ 70.425688] [8133f614] pci_device_probe+0x84/0xe0 [ 70.425692] [813d89f6] driver_probe_device+0x76/0x240 [ 70.425695] [813d8bc0] ? driver_probe_device+0x240/0x240 [ 70.425698] [813d8bfb] __device_attach+0x3b/0x40 [
Missing USB XHCI and EHCI reset for kexec
When executing a kexec kernel on a PowerPC board the new started kernel will not find already enumerated USB devices due a missing reset on the USB bus. As a work around a echo 1 /sys/bus/pci/drivers/[ex]hci-pci/BUS-ADDRESS-OF-THE-HCD/reset will solve this. But this is far from beauty. My latest kernel without this issue was for EHCI kernel 2.6.39 and for XHCI kernel 3.4, but i have no idea when exactly this behavior was introduced. For X86 all is fine. -- 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
EHCI threadirq
Hi Alan, i just checked the current linux git tree and the 3.13 kernel. In both i miss your fix for the thread irq support in the ehci hcd which you had promised. - Stefani -- 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 storage vanilla kernel 3.13 hang on DELL PRECISION M6400
Am Samstag, den 15.02.2014, 02:33 +0100 schrieb Thomas Gleixner: On Fri, 14 Feb 2014, Stefani Seibold wrote: Am Freitag, den 14.02.2014, 10:32 -0500 schrieb Alan Stern: On Fri, 14 Feb 2014, Stefani Seibold wrote: Hi Alan; Am Donnerstag, den 13.02.2014, 15:55 -0500 schrieb Alan Stern: Stefani, please try the patch below, with threadirq and the plain vanilla kernel. It ought to fix your problem, but let's make certain. I tried the patch on 3.13.2 together with the commit 88ed9fd50e57 and it seems that it solves the problem. I also tried the current 3.14.0-rc2-00271-g4675348 without any modifications and without our patch... and it also works. 3.14-rc2 works with no modifications at all? Then it looks like the patch is unnecessary. But I'm surprised that it works. As far as I know, there haven't been any changes since 3.13 that would fix this problem. I surprised too. I think it is a kind of race condition and IMHO the patch is necessary. Lockdep does not care about race conditions and humble opinions at all. It observes that one place takes the lock with interrupts enabled and the other takes it in hardirq context. It's that simple. So now the question is why one kernel triggers the lockdep warning and a later version does not while all involved parties claim that nothing has changed. Before we jump into detailed analysis, let's make sure that this happens - with the same .config (i.e. lockdep and the device driver in question enabled) - the same system (i.e. the same drivers loaded and handling the same devices) - the device driver actually doing something which might cause lockdep to yell. When this is the case, then the claim that nothing has changed is simply wrong and we need to figure out which allegedly unrelated change has caused this change in behaviour. The patch is needed from a code analysis POV. I've been wrong before, but you really need to provide evidence why 3.14-rc2 does not show the behaviour and which change has caused that before I'm going to back off. IMHO is not a convincing argument! I have cross tested Alan's patch again with kernel 3.13.2 and the current 3.14-rc2. I have now exactly the same .config, the same system and the same kernel cmdline. A kernel 3.13.2 without Alan's patch freeze when accessing a USB flash memory connect to the EHCI. With this patch everything is fine. The current 3.14-rc2 freeze also when the patch is not applied. With this patch it works. The reason that my first test show a different behaviour on the 3.14 kernel was that the cmdline was missing the threadirq, because the boot loader was missconfigured. So i will give an ACK for the patch. - Stefani -- 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 storage vanilla kernel 3.13 hang on DELL PRECISION M6400
Hi Alan;
Am Donnerstag, den 13.02.2014, 15:55 -0500 schrieb Alan Stern:
Stefani, please try the patch below, with threadirq and the plain
vanilla kernel. It ought to fix your problem, but let's make certain.
I tried the patch on 3.13.2 together with the commit 88ed9fd50e57 and it
seems that it solves the problem.
I also tried the current 3.14.0-rc2-00271-g4675348 without any
modifications and without our patch... and it also works.
Both are tested with the kernel parameter threadirqs.
- Stefani
Index: usb-3.14/drivers/usb/host/ehci-hcd.c
===
--- usb-3.14.orig/drivers/usb/host/ehci-hcd.c
+++ usb-3.14/drivers/usb/host/ehci-hcd.c
@@ -683,10 +683,11 @@ EXPORT_SYMBOL_GPL(ehci_setup);
static irqreturn_t ehci_irq (struct usb_hcd *hcd)
{
struct ehci_hcd *ehci = hcd_to_ehci (hcd);
+ unsigned long flags;
u32 status, masked_status, pcd_status = 0, cmd;
int bh;
- spin_lock (ehci-lock);
+ spin_lock_irqsave(ehci-lock, flags);
status = ehci_readl(ehci, ehci-regs-status);
@@ -704,7 +705,7 @@ static irqreturn_t ehci_irq (struct usb_
/* Shared IRQ? */
if (!masked_status || unlikely(ehci-rh_state == EHCI_RH_HALTED)) {
- spin_unlock(ehci-lock);
+ spin_unlock_irqrestore(ehci-lock, flags);
return IRQ_NONE;
}
@@ -815,7 +816,7 @@ dead:
if (bh)
ehci_work (ehci);
- spin_unlock (ehci-lock);
+ spin_unlock_irqrestore(ehci-lock, flags);
if (pcd_status)
usb_hcd_poll_rh_status(hcd);
return IRQ_HANDLED;
--
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 storage vanilla kernel 3.13 hang on DELL PRECISION M6400
Am Freitag, den 14.02.2014, 10:32 -0500 schrieb Alan Stern: On Fri, 14 Feb 2014, Stefani Seibold wrote: Hi Alan; Am Donnerstag, den 13.02.2014, 15:55 -0500 schrieb Alan Stern: Stefani, please try the patch below, with threadirq and the plain vanilla kernel. It ought to fix your problem, but let's make certain. I tried the patch on 3.13.2 together with the commit 88ed9fd50e57 and it seems that it solves the problem. I also tried the current 3.14.0-rc2-00271-g4675348 without any modifications and without our patch... and it also works. 3.14-rc2 works with no modifications at all? Then it looks like the patch is unnecessary. But I'm surprised that it works. As far as I know, there haven't been any changes since 3.13 that would fix this problem. I surprised too. I think it is a kind of race condition and IMHO the patch is necessary. - Stefani -- 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 storage vanilla kernel 3.13 hang on DELL PRECISION M6400
Am Mittwoch, den 12.02.2014, 10:37 -0500 schrieb Alan Stern: On Wed, 12 Feb 2014, Stefani Seibold wrote: Hi, Am Dienstag, den 11.02.2014, 11:30 -0500 schrieb Alan Stern: On Mon, 10 Feb 2014, Stefani Seibold wrote: I have more information about the bug. I tested with a USB 3.0 Expresscard and this works with 3.13. I also found an old USB 1.1 HUB in my USB gadget box. When i attach the USB flash storage to the USB 1.1 hub there is also no problem. Since the USB 1.1 Hub is attached to the EHCI we can assume that the bug is not in the phy support nor in the USB storage driver. So i thing the bug must be located in the EHCI HC driver. Yes, it probably is. Can you build 3.13 with CONFIG_USB_DEBUG enabled? Maybe some debugging information will show up in the dmesg log and provide a clue. I tried the kernel with CONFIG_USB_DEBUG, but i did not get any USB Debug after the computer freeze. Did anything show up before the freeze? After a minute i get the attached output. Sorry i was only able to do screen shot. It looks like something locked ehci-lock and then never unlocked it. But from the screen shot, I can't tell where this happened. I was able to get the whole kernel messages via netconsole. I also had enable CONFIG_USB_DEBUG and all kinds of lock detection. When i attach the USB flash memory (sdc), the system freeze and the fan's of the machine will get noisy. So i think the CPU is 100 % in use. I attach the dmesg output and the current kernel config. Also, I tried to reproduce this failure on my own computer, using 3.14-rc1, but everything worked correctly. I will try the 3.14 kernel... But it makes me crazy when a bug disappears without an explanation. Okay, the debugging info in your dmesg log indicates the cause of the problem. It looks like the bug is related to commit 88ed9fd50e57 (usb/hcd: remove unnecessary local_irq_save) by Michael Opdenacker. (Note: As far as I can tell, the commit itself is okay, but it exposes a bug somewhere else in the kernel.) If you revert that commit from 3.13, does it fix the problem? Reverting the commit 88ed9fd50e57 solve the problem. Thank you so much. - Stefani -- 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 storage vanilla kernel 3.13 hang on DELL PRECISION M6400
Am Mittwoch, den 12.02.2014, 16:57 +0100 schrieb Michael Opdenacker: On 02/12/2014 04:47 PM, Stefani Seibold wrote: Am Mittwoch, den 12.02.2014, 10:37 -0500 schrieb Alan Stern: On Wed, 12 Feb 2014, Stefani Seibold wrote: Hi, Am Dienstag, den 11.02.2014, 11:30 -0500 schrieb Alan Stern: On Mon, 10 Feb 2014, Stefani Seibold wrote: I have more information about the bug. I tested with a USB 3.0 Expresscard and this works with 3.13. I also found an old USB 1.1 HUB in my USB gadget box. When i attach the USB flash storage to the USB 1.1 hub there is also no problem. Since the USB 1.1 Hub is attached to the EHCI we can assume that the bug is not in the phy support nor in the USB storage driver. So i thing the bug must be located in the EHCI HC driver. Yes, it probably is. Can you build 3.13 with CONFIG_USB_DEBUG enabled? Maybe some debugging information will show up in the dmesg log and provide a clue. I tried the kernel with CONFIG_USB_DEBUG, but i did not get any USB Debug after the computer freeze. Did anything show up before the freeze? After a minute i get the attached output. Sorry i was only able to do screen shot. It looks like something locked ehci-lock and then never unlocked it. But from the screen shot, I can't tell where this happened. I was able to get the whole kernel messages via netconsole. I also had enable CONFIG_USB_DEBUG and all kinds of lock detection. When i attach the USB flash memory (sdc), the system freeze and the fan's of the machine will get noisy. So i think the CPU is 100 % in use. I attach the dmesg output and the current kernel config. Also, I tried to reproduce this failure on my own computer, using 3.14-rc1, but everything worked correctly. I will try the 3.14 kernel... But it makes me crazy when a bug disappears without an explanation. Okay, the debugging info in your dmesg log indicates the cause of the problem. It looks like the bug is related to commit 88ed9fd50e57 (usb/hcd: remove unnecessary local_irq_save) by Michael Opdenacker. (Note: As far as I can tell, the commit itself is okay, but it exposes a bug somewhere else in the kernel.) If you revert that commit from 3.13, does it fix the problem? Reverting the commit 88ed9fd50e57 solve the problem. Thank you so much. Oops, I'll try to reproduce and investigate. Thanks for the investigations!!! I think the problem has maybe to do with the threadirqs kernel parameter. - Stefani -- 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 storage vanilla kernel 3.13 hang on DELL PRECISION M6400
Am Mittwoch, den 12.02.2014, 08:28 -0800 schrieb Greg KH: On Wed, Feb 12, 2014 at 05:20:10PM +0100, Stefani Seibold wrote: Am Mittwoch, den 12.02.2014, 16:57 +0100 schrieb Michael Opdenacker: On 02/12/2014 04:47 PM, Stefani Seibold wrote: Am Mittwoch, den 12.02.2014, 10:37 -0500 schrieb Alan Stern: On Wed, 12 Feb 2014, Stefani Seibold wrote: Hi, Am Dienstag, den 11.02.2014, 11:30 -0500 schrieb Alan Stern: On Mon, 10 Feb 2014, Stefani Seibold wrote: I have more information about the bug. I tested with a USB 3.0 Expresscard and this works with 3.13. I also found an old USB 1.1 HUB in my USB gadget box. When i attach the USB flash storage to the USB 1.1 hub there is also no problem. Since the USB 1.1 Hub is attached to the EHCI we can assume that the bug is not in the phy support nor in the USB storage driver. So i thing the bug must be located in the EHCI HC driver. Yes, it probably is. Can you build 3.13 with CONFIG_USB_DEBUG enabled? Maybe some debugging information will show up in the dmesg log and provide a clue. I tried the kernel with CONFIG_USB_DEBUG, but i did not get any USB Debug after the computer freeze. Did anything show up before the freeze? After a minute i get the attached output. Sorry i was only able to do screen shot. It looks like something locked ehci-lock and then never unlocked it. But from the screen shot, I can't tell where this happened. I was able to get the whole kernel messages via netconsole. I also had enable CONFIG_USB_DEBUG and all kinds of lock detection. When i attach the USB flash memory (sdc), the system freeze and the fan's of the machine will get noisy. So i think the CPU is 100 % in use. I attach the dmesg output and the current kernel config. Also, I tried to reproduce this failure on my own computer, using 3.14-rc1, but everything worked correctly. I will try the 3.14 kernel... But it makes me crazy when a bug disappears without an explanation. Okay, the debugging info in your dmesg log indicates the cause of the problem. It looks like the bug is related to commit 88ed9fd50e57 (usb/hcd: remove unnecessary local_irq_save) by Michael Opdenacker. (Note: As far as I can tell, the commit itself is okay, but it exposes a bug somewhere else in the kernel.) If you revert that commit from 3.13, does it fix the problem? Reverting the commit 88ed9fd50e57 solve the problem. Thank you so much. Oops, I'll try to reproduce and investigate. Thanks for the investigations!!! I think the problem has maybe to do with the threadirqs kernel parameter. I don't think threaded irqs work very well with USB, can you try turning that off and seeing if the issue goes away? I use threaded irqs since more than two years without any problem. It works with OHCI, UHCI, EHCI and XHCI. This was the first time that an problem occurred. And yes, the issues goes away when no thread irqs are used (with and without the patch). - Stefani -- 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 storage vanilla kernel 3.13 hang on DELL PRECISION M6400
Am Montag, den 10.02.2014, 12:09 -0500 schrieb Alan Stern: On Mon, 10 Feb 2014, Stefani Seibold wrote: Am Montag, den 10.02.2014, 10:56 -0500 schrieb Alan Stern: On Mon, 10 Feb 2014, Stefani Seibold wrote: Hi, the USB storage does not longer work on my DELL PRECISION M6400 with a plain vanilla 3.13 kernel. When i attach a USB storage flash memory the system freeze immediately or after accessing the flash. It makes not difference mounting via a GNOME desktop or mounting as root in a text console. There is no problem with all previous kernel like 3.12.7, everything is okay. All of the previous vanilla kernels works perfectly since nearly six years on my workstation. What kind of information do you need to figure out the problem and fix this regression? It would help to see a usbmon trace from 3.13 together with a usbmon trace from an earlier, working kernel. (The instructions are in Documentation/usb/usbmon.txt.) Start the usbmon trace just before you plug in the flash device. Alan Stern I did and attached the USB trace for 3.13.2 and for 3.12.7. One interesting thing was that the bus in 3.12.7 was sometimes 6 and sometimes 2. The bus number doesn't matter; it's allowed to change every time you reboot. The bus change without a reboot! The two traces are almost identical. This is puzzling; I don't see any significant differences at all. The problem is that the machine complete freeze, so the dump stops. I get no crash log or anything else. The computer is still dead. Only the LED of the usb flash storage is very fast flashing. It looks like you will have to use git bisect to find the change that caused the regression. That's to dangerous for me, because it is a production machine. - Stefani -- 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 storage vanilla kernel 3.13 hang on DELL PRECISION M6400
Am Montag, den 10.02.2014, 12:09 -0500 schrieb Alan Stern: On Mon, 10 Feb 2014, Stefani Seibold wrote: Am Montag, den 10.02.2014, 10:56 -0500 schrieb Alan Stern: On Mon, 10 Feb 2014, Stefani Seibold wrote: Hi, the USB storage does not longer work on my DELL PRECISION M6400 with a plain vanilla 3.13 kernel. When i attach a USB storage flash memory the system freeze immediately or after accessing the flash. It makes not difference mounting via a GNOME desktop or mounting as root in a text console. There is no problem with all previous kernel like 3.12.7, everything is okay. All of the previous vanilla kernels works perfectly since nearly six years on my workstation. What kind of information do you need to figure out the problem and fix this regression? It would help to see a usbmon trace from 3.13 together with a usbmon trace from an earlier, working kernel. (The instructions are in Documentation/usb/usbmon.txt.) Start the usbmon trace just before you plug in the flash device. Alan Stern I did and attached the USB trace for 3.13.2 and for 3.12.7. One interesting thing was that the bus in 3.12.7 was sometimes 6 and sometimes 2. I have more information about the bug. I tested with a USB 3.0 Expresscard and this works with 3.13. I also found an old USB 1.1 HUB in my USB gadget box. When i attach the USB flash storage to the USB 1.1 hub there is also no problem. Since the USB 1.1 Hub is attached to the EHCI we can assume that the bug is not in the phy support nor in the USB storage driver. So i thing the bug must be located in the EHCI HC driver. - Stefani -- 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] add ftdi_sio USB ID for GDM Boost V1.x
This patch add a missing usb device id for the GDMBoost V1.x device
The patch is against 3.9-rc5
Signed-off-by: Stefani Seibold stef...@seibold.net
---
ftdi_sio.c |1 +
ftdi_sio_ids.h |1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 9886180..145979f 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -189,6 +189,7 @@ static struct usb_device_id id_table_combined [] = {
{ USB_DEVICE(FTDI_VID, FTDI_OPENDCC_THROTTLE_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_OPENDCC_GATEWAY_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_OPENDCC_GBM_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_OPENDCC_GBM_BOOST_PID) },
{ USB_DEVICE(NEWPORT_VID, NEWPORT_AGILIS_PID) },
{ USB_DEVICE(INTERBIOMETRICS_VID, INTERBIOMETRICS_IOBOARD_PID) },
{ USB_DEVICE(INTERBIOMETRICS_VID, INTERBIOMETRICS_MINI_IOBOARD_PID) },
diff --git a/drivers/usb/serial/ftdi_sio_ids.h
b/drivers/usb/serial/ftdi_sio_ids.h
index e79861e..3c00351 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -74,6 +74,7 @@
#define FTDI_OPENDCC_THROTTLE_PID 0xBFDA
#define FTDI_OPENDCC_GATEWAY_PID 0xBFDB
#define FTDI_OPENDCC_GBM_PID 0xBFDC
+#define FTDI_OPENDCC_GBM_BOOST_PID 0xBFDD
/* NZR SEM 16+ USB (http://www.nzr.de) */
#define FTDI_NZR_SEM_USB_PID 0xC1E0 /* NZR SEM-LOG16+ */
--
1.8.1.5
--
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
