Re: 3.7.3, ttyUSB0 serial problem - devices stop working and only reboot helps (Inappropriate ioctl for device)
Arkadiusz Miskiewicz wrote: On Saturday 19 of January 2013, Arkadiusz Miskiewicz wrote: On Saturday 19 of January 2013, Greg Kroah-Hartman wrote: On Fri, Jan 18, 2013 at 11:28:43PM +0100, Arkadiusz Miskiewicz wrote: Hi. Using 3.7.3 kernel and connecting two rs232 usb adapters, CP2102 and FT232RL, one after disconnecting another. After few cycles of reconnecting and using socat (below) I'm getting problems accessing ttyUSB0: ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0x7fffb70c6ae0) = -1 ENOTTY (Inappropriate ioctl for device) Unloading and reloading (by udev) modules ftdio_sio, cp210x, usbserial doesn't help. I have to reboot to get ttyUSB0 working (regardless of which driver, ftdio_sio or cp210x is handling ttyUSB0 - both stop working). Any clues? The kernel log shows the device getting removed a bunch and then coming back, which implies electrical issues (flaky connection, low power, etc.) Are you really removing it and plugging it back in? Or is it doing it all by itself? I was doing plug in CP2102, remove it, plug in FT232RL after few seconds, remove it, plug in CP... (and various variations, several times) and testing with socat before removing devices. After some iteration the problem appears and only reboot helps. The issue is really weird. Machine is Thinkpad T400 2764CTO (latest bios). When the problem happened on 3.7.3 today I rebooted into 3.8rc4 and ... freshly after reboot and plugging in PL2303 adapter the problem was already there. Didn't have to do unplug/plug cycle to make it happen. Looks like sometimes reboot cures the problem, sometimes it doesn't. Now powered off laptop and powered it on - problem gone. Connected PL2303, ran socat, disconnected PL2303 (while socat was running) - problem happened again. Looks like it doesn't depend on adapter chip type. So to reproduce here: - boot fresh 3.8rc4 - plug in some adapter (PL2303 for example) - run socat -ddd -s -u /dev/ttyUSB0,raw,echo=0,b115200,crnl,noctty,nonblock - | logger - it should run fine, without any error - disconnect adapter; socat should exit with error W cannot restore terminal settings on fd 3: Input/output error - plug in adapter again - run socat again - this time error E tcgetattr(3, 0x7fff21411780): Inappropriate ioctl for device immediately always; regardless which adapter is used and if kernel module drivers for these adapters were reloaded dmesg: http://pastebin.com/r1Q5mmgt config: http://pastebin.com/8dpFFzuU lspci: http://pastebin.com/TBtUg1tW lsusb: http://pastebin.com/SueVw9CD [ 53.776047] usb 4-1: new full-speed USB device number 2 using uhci_hcd [ 53.938053] usb 4-1: New USB device found, idVendor=067b, idProduct=2303 [ 53.938060] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 53.938065] usb 4-1: Product: USB-Serial Controller [ 53.938068] usb 4-1: Manufacturer: Prolific Technology Inc. [ 53.949924] usbcore: registered new interface driver usbserial [ 53.950364] usbcore: registered new interface driver usbserial_generic [ 53.951147] usbserial: USB Serial support registered for generic [ 53.954268] usbcore: registered new interface driver pl2303 [ 53.955009] usbserial: USB Serial support registered for pl2303 [ 53.955039] pl2303 4-1:1.0: pl2303 converter detected [ 53.967394] usb 4-1: pl2303 converter now attached to ttyUSB0 [ 64.492122] usb 4-1: USB disconnect, device number 2 [ 64.501748] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0 [ 64.502343] pl2303 4-1:1.0: device disconnected [ 66.494930] usb 4-1: new full-speed USB device number 3 using uhci_hcd [ 66.654247] usb 4-1: New USB device found, idVendor=067b, idProduct=2303 [ 66.654261] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 66.654269] usb 4-1: Product: USB-Serial Controller [ 66.654276] usb 4-1: Manufacturer: Prolific Technology Inc. [ 66.659661] pl2303 4-1:1.0: pl2303 converter detected [ 66.671587] usb 4-1: pl2303 converter now attached to ttyUSB0 5722 munmap(0x7f1bfc0d7000, 4096) = 0 5722 write(2, 2013/01/19 09:36:38 socat[5722] E tcgetattr(3, 0x7fffeff64020): Inappropriate ioctl for device\n, 95) = 95 5722 ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0x7fffeff63e50) = -1 ENOTTY (Inappropriate ioctl for device) 5722 write(2, 2013/01/19 09:36:38 socat[5722] E tcgetattr(3, 0x7fffeff63f90): Inappropriate ioctl for device\n, 95) = 95 5722 ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0x7fffeff63ec0) = -1 ENOTTY (Inappropriate ioctl for device) 5722 write(2, 2013/01/19 09:36:38 socat[5722] E tcgetattr(3, 0x7fffeff64160): Inappropriate ioctl for device\n, 95) = 95 5722 fcntl(3, F_SETFD, FD_CLOEXEC) = 0 5722 ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0x7fffeff64330) = -1 ENOTTY (Inappropriate ioctl for device) 5722 select(4, [3], [1], [], NULL) = 2 (in [3], out [1]) If I unplug the USB device
Re: Linux 3.8-rc1 - another regression on USB :-(
Alan Stern wrote: On Tue, 15 Jan 2013, Woody Suwalski wrote: Another important change is that the EHCI driver is now split into two modules. That can slow down loading and affect the timing. Alan Stern My testcase is a live initramfs + squash root. The boot logic is as stable as can be - unchanged since 2.6.2x kernels. And it was working fine till 3.8-rc1. The modules are insmoded in a fixed order: usb-common, usbcore, xhci-hcd, ehci-hcd, uhci-hcd, ohci-hcd, usbhid, usb_storage,... But apparently you don't insmod ehci-pci. That could cause problems, if your EHCI controller is PCI-based. If all USB is built as modules - I get read errors from USB drives when accessing squash image, boot fails. What read errors? What is the cause of these errors? If usb-common and usbcore are built in, system seems to crawl with a very slow USB, but boots. That could be caused by timing between hcd modules. Do have a dmesg log with timestamps so we can see where things go slow? I suggest enabling CONFIG_PRINTK_TIME and CONFIG_USB_DEBUG. You might even want CONFIG_USB_STORAGE_DEBUG, although that often logs too much information. If usb-common, usbcore and ehci-hcd are built-in, all works OK like before 3.8. What about ehci-pci? Alan, it took me 2 times re-reading the email to notice... You were talking about ehci-pci, not ehci-hcd... Old assumptions die hard... Yep, that was it. Catch22 - I would have noticed new dependency if I could boot, but to boot I have had needed to notice the new dependency... Case solved 8-) Thanks, Woody -- 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: Linux 3.8-rc1 - another regression on USB :-(
Alan Stern wrote: On Sat, 12 Jan 2013, Andreas Mohr wrote: There's of course the EHCI vs. UHCI(/OHCI) duality (EHCI host controller responsible for high speed transfers, the other for 1.1 full speed, both serving the same port connectors). So if the coordination between the two is a problem, you might end up with merely full speed on a 2.0 port. And with drivers builtin vs. module, the init sequence/timing might possibly be affected - right? Perhaps this got worsened by semi-recent driver init kernel changes? (AFAIR the kernel was changed to init more things in parallel, for faster bootup). So maybe that affected EHCI vs. UHCI coordination timing. Another important change is that the EHCI driver is now split into two modules. That can slow down loading and affect the timing. Alan Stern My testcase is a live initramfs + squash root. The boot logic is as stable as can be - unchanged since 2.6.2x kernels. And it was working fine till 3.8-rc1. The modules are insmoded in a fixed order: usb-common, usbcore, xhci-hcd, ehci-hcd, uhci-hcd, ohci-hcd, usbhid, usb_storage,... If all USB is built as modules - I get read errors from USB drives when accessing squash image, boot fails. If usb-common and usbcore are built in, system seems to crawl with a very slow USB, but boots. That could be caused by timing between hcd modules. If usb-common, usbcore and ehci-hcd are built-in, all works OK like before 3.8. I was testing on machines without xhci or ohci hardware, so these drivers probably are not playing any role. I have retried initramfs with a 1s sleep between insmods to verify if it is timing - still the same read errors - so the main issue is _not_ timing. The read errors problem is 100% reproducible for me, the blocks where read fails are not fixed - every (failed) boot errors start appearing in a bit different location. Just selecting a differently - configured kernel image makes the boot work, so it is not a problem of squash image, USB drive, squashfs driver. Scratching my head loudly, Woody -- 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: Linux 3.8-rc1 - another regression on USB :-(
Greg Kroah-Hartman wrote: On Sun, Dec 23, 2012 at 02:35:49PM -0800, Linus Torvalds wrote: Woody, Any chance you can bisect this? It's not going to be hugely pleasant (with 11k+ commits in between 3.7 and 3.8-rc1 you'll have to compile and test at least 14 kernels), but it would help enormously. Of course, maybe some USB person can guess what would cause the device to go offline.. Added Greg and the linux-usb mailing list to the participants list: the images are in the original email on lkml, but there isn't anything particularly interesting there, it really just seems to be an unexpected and spurious USB disconnect, resulting in USB disconnect, device number 2 followed by Rejecting I/O to offline device. I don't see any images on lkml, sorry. The kernel log for when the disconnect happened would be great to get. The kernel can't cause a device to disconnect, that's an electrical thing usually, is this perchance a flaky device/connection? Or has it always worked on older kernels? What host controller is being used here (xhci, ehci, etc.?) thanks, greg k-h Greg, Linus, It sounds insane, but after banging on the issue I have found out that USB problem is caused (also in vanilla kernel) with a config change: USB-all built as modules - bad USB USB core built in, UHCI/EHCI modules - semi functional - but 1Mb/s transfer USB core and UHCI EHCI built-in - bingo - no issues. Could anybody duplicate that, or is it somehow my setup??? Thanks, Woody -- 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: INVALID Linux 3.8-rc1 - another regression on USB :-(
Woody Suwalski wrote: Greg Kroah-Hartman wrote: On Sun, Dec 23, 2012 at 02:35:49PM -0800, Linus Torvalds wrote: Woody, Any chance you can bisect this? It's not going to be hugely pleasant (with 11k+ commits in between 3.7 and 3.8-rc1 you'll have to compile and test at least 14 kernels), but it would help enormously. Of course, maybe some USB person can guess what would cause the device to go offline.. Added Greg and the linux-usb mailing list to the participants list: the images are in the original email on lkml, but there isn't anything particularly interesting there, it really just seems to be an unexpected and spurious USB disconnect, resulting in USB disconnect, device number 2 followed by Rejecting I/O to offline device. I don't see any images on lkml, sorry. The kernel log for when the disconnect happened would be great to get. The kernel can't cause a device to disconnect, that's an electrical thing usually, is this perchance a flaky device/connection? Or has it always worked on older kernels? What host controller is being used here (xhci, ehci, etc.?) thanks, greg k-h I backtrack - it is not directly a USB problem. If I boot the image into a single mode, and then verify reading the squashfs as a compressed file or the files in the mounted uncompressed image - there are no errors on read. Yet if i let it boot into X - it does not - gets bogged with disk access errors. And then there is no access to a USB key anymore. Will need to investigate further.. Sorry for the alarm, Greg... Problem must be caused by third-party patches - tests with vanilla+overlayfs show that all works as expected. Happy New Year 2013 redfaced Woody -- 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
