ftdi-usb-sio-devel Mailing List for FTDI USB Serial Converter Driver (Page 5)
Brought to you by:
bryder
Menu
▾
▴
ftdi-usb-sio-devel — FTDI USB Device Driver development discussion list
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
(11) |
Nov
(25) |
Dec
(25) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(16) |
Feb
(98) |
Mar
(46) |
Apr
(35) |
May
(15) |
Jun
(73) |
Jul
(49) |
Aug
(28) |
Sep
(16) |
Oct
(24) |
Nov
(36) |
Dec
(37) |
| 2004 |
Jan
(40) |
Feb
(21) |
Mar
(32) |
Apr
(27) |
May
(32) |
Jun
(48) |
Jul
(62) |
Aug
(22) |
Sep
(13) |
Oct
(14) |
Nov
(24) |
Dec
(26) |
| 2005 |
Jan
(15) |
Feb
(14) |
Mar
(31) |
Apr
(19) |
May
(23) |
Jun
(76) |
Jul
(64) |
Aug
(68) |
Sep
(30) |
Oct
(11) |
Nov
(20) |
Dec
(14) |
| 2006 |
Jan
(7) |
Feb
(5) |
Mar
(10) |
Apr
(10) |
May
(17) |
Jun
(13) |
Jul
(9) |
Aug
(8) |
Sep
(27) |
Oct
(54) |
Nov
(38) |
Dec
(31) |
| 2007 |
Jan
(21) |
Feb
(4) |
Mar
(3) |
Apr
(3) |
May
(3) |
Jun
(2) |
Jul
(2) |
Aug
(11) |
Sep
(4) |
Oct
(2) |
Nov
(1) |
Dec
|
| 2008 |
Jan
(2) |
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
(8) |
Sep
|
Oct
(3) |
Nov
(6) |
Dec
(2) |
| 2009 |
Jan
(14) |
Feb
(3) |
Mar
(4) |
Apr
|
May
(1) |
Jun
(2) |
Jul
(5) |
Aug
|
Sep
(1) |
Oct
(1) |
Nov
(5) |
Dec
(6) |
| 2010 |
Jan
(3) |
Feb
(5) |
Mar
(2) |
Apr
(4) |
May
(1) |
Jun
(7) |
Jul
(7) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
(15) |
Dec
(1) |
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(2) |
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
(1) |
Mar
|
Apr
(9) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
(3) |
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
(6) |
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
(9) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Bill R. <bil...@gm...> - 2009-11-02 16:05:54
|
Probably the easiest and safest thing to do is to completely remove the ftdi_sio module. Otherwise you can setup rmmod in you /etc/sudoers file. On Tue, Nov 3, 2009 at 2:55 AM, T. Horsnell <ts...@mr...> wrote: > Hi, > I've just started with libftdi, and am getting an error during > ftdi_open_usb_dev when it tries to detatch any existing ftdi_sio module, > when running as a non-root user. > > Everything works OK when I run as root. > > Presuming that a user-mode prog wasnt able to do the > usb_detach_kernel_driver_np, > I did 'rmmod ftdi_sio', and commented out the 'usb_detach_kernel_driver_np' > line in > the library, but I now get a -3 error at the 'usb_set_configuration' step, > unless > I run as root. > > What permissions do I need to set on what files to be able to do things > as a non-root user? > > Many thanks, > Terry > > > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Ftdi-usb-sio-devel mailing list > Ftd...@li... > https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel > |
|
From: T. H. <ts...@mr...> - 2009-11-02 14:01:54
|
Hi, I've just started with libftdi, and am getting an error during ftdi_open_usb_dev when it tries to detatch any existing ftdi_sio module, when running as a non-root user. Everything works OK when I run as root. Presuming that a user-mode prog wasnt able to do the usb_detach_kernel_driver_np, I did 'rmmod ftdi_sio', and commented out the 'usb_detach_kernel_driver_np' line in the library, but I now get a -3 error at the 'usb_set_configuration' step, unless I run as root. What permissions do I need to set on what files to be able to do things as a non-root user? Many thanks, Terry |
|
From: jbassettCorrilan <jba...@co...> - 2009-10-05 18:34:44
|
Hello folks I have a Zalmand VFD LCD style device with id 040b:7000. I have compiled ftdi_sio as a module on Gentoo 2.6.27 kernel. "modprobe ftdi_sio vendor=0x040b product=0x7000" produces this dmesg output, it appears the device has been configured properly with the nodes: [ 128.579883] usbcore: registered new interface driver usbserial [ 128.581490] usbserial: USB Serial support registered for generic [ 128.582308] usbserial_generic 1-2:1.0: usb_probe_interface [ 128.582323] usbserial_generic 1-2:1.0: usb_probe_interface - got id [ 128.582713] usbserial_generic 1-2:1.2: usb_probe_interface [ 128.582724] usbserial_generic 1-2:1.2: usb_probe_interface - got id [ 128.583524] usbserial_generic 5-1:1.0: usb_probe_interface [ 128.583537] usbserial_generic 5-1:1.0: usb_probe_interface - got id [ 128.583929] usbserial_generic 5-1:1.1: usb_probe_interface [ 128.583940] usbserial_generic 5-1:1.1: usb_probe_interface - got id [ 128.584405] usbcore: registered new interface driver usbserial_generic [ 128.584415] usbserial: USB Serial Driver core [ 128.597107] usbserial: USB Serial support registered for FTDI USB Serial Device [ 128.597453] ftdi_sio 5-1:1.0: usb_probe_interface [ 128.597476] ftdi_sio 5-1:1.0: usb_probe_interface - got id [ 128.597920] ftdi_sio 5-1:1.0: FTDI USB Serial Device converter detected [ 128.598174] ftdi_sio: Detected FT2232C [ 128.598479] usb 5-1: FTDI USB Serial Device converter now attached to ttyUSB0 [ 128.598711] ftdi_sio 5-1:1.1: usb_probe_interface [ 128.598735] ftdi_sio 5-1:1.1: usb_probe_interface - got id [ 128.599035] ftdi_sio 5-1:1.1: FTDI USB Serial Device converter detected [ 128.599223] ftdi_sio: Detected FT2232C [ 128.599487] usb 5-1: FTDI USB Serial Device converter now attached to ttyUSB1 [ 128.599682] usbcore: registered new interface driver ftdi_sio [ 128.599694] ftdi_sio: v1.4.3:USB FTDI Serial Converters Driver Upon attempting to use the nodes at all (such as echo "Hello" > /dev/ttyUSB0 or 1) I receive the following errors in dmesg output and that particular console effectively locks up: [ 248.073129] ftdi_sio: ftdi_set_termios FAILED to set databits/stopbits/parity [ 248.074131] ftdi_sio: ftdi_set_termios urb failed to set baudrate [ 248.075130] ftdi_sio: urb failed to clear flow control [ 248.076133] ftdi_sio: update_mctrl Error from MODEM_CTRL urb: DTR HIGH, RTS HIGH [ 248.076151] BUG: unable to handle kernel NULL pointer dereference at 00000028 [ 248.076158] IP: [<f9230446>] :ftdi_sio:ftdi_open+0x144/0x191 [ 248.076191] *pde = 00000000 [ 248.076198] Oops: 0002 [#1] SMP [ 248.076213] Modules linked in: ftdi_sio usbserial i915 snd_pcm_oss snd_mixer_oss mt352 saa7134_alsa saa7134_dvb videobuf_dvb dvb_core saa7134 tuner tuner_xc2028 snd_hda_intel ir_common videodev intelfb snd_pcm v4l1_compat compat_ioctl32 v4l2_common snd_timer videobuf_dma_sg snd_page_alloc snd_hwdep videobuf_core i2c_algo_bit lirc_mceusb2 snd tveeprom ohci1394 lirc_dev usbhid ieee1394 soundcore [ 248.076305] [ 248.076314] Pid: 6328, comm: bash Not tainted (2.6.27-gentoo-r8 #26) [ 248.076325] EIP: 0060:[<f9230446>] EFLAGS: 00010246 CPU: 0 [ 248.076342] EIP is at ftdi_open+0x144/0x191 [ftdi_sio] [ 248.076353] EAX: 00000002 EBX: f70b5000 ECX: 00000000 EDX: 00000000 [ 248.076363] ESI: f71e7540 EDI: efd71000 EBP: efe23e4c ESP: efe23e34 [ 248.076374] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 [ 248.076385] Process bash (pid: 6328, ti=efe22000 task=efd953f0 task.ti=efe22000) [ 248.076392] Stack: efdb5400 f70b5000 efd71000 f9239a60 efd71000 f6c11840 efe23e6c f9227e72 [ 248.076412] f73d7f00 efdb5400 efd7104c f9227d93 f73d7f00 0bc00001 efe23e90 c0359792 [ 248.076431] 00008241 00000000 00000001 efdb5400 00000000 f71e7f04 00000000 efe23eb0 [ 248.076449] Call Trace: [ 248.076462] [<f9227e72>] ? serial_open+0xdf/0x138 [usbserial] [ 248.076481] [<f9227d93>] ? serial_open+0x0/0x138 [usbserial] [ 248.076498] [<c0359792>] ? tty_open+0x167/0x2ab [ 248.076513] [<c027c25d>] ? chrdev_open+0x11f/0x158 [ 248.076527] [<c0278509>] ? __dentry_open+0x10e/0x1fc [ 248.076539] [<c0278616>] ? nameidata_to_filp+0x1f/0x33 [ 248.076552] [<c027c13e>] ? chrdev_open+0x0/0x158 [ 248.076564] [<c0282ffc>] ? do_filp_open+0x344/0x5ed [ 248.076577] [<c02665b0>] ? handle_mm_fault+0x4fa/0x54e [ 248.076591] [<c028b6fa>] ? alloc_fd+0x5c/0xd4 [ 248.076603] [<c0278327>] ? do_sys_open+0x44/0xb9 [ 248.076615] [<c02783de>] ? sys_open+0x1e/0x26 [ 248.076627] [<c02038b6>] ? syscall_call+0x7/0xb [ 248.076640] ======================= [ 248.076648] Code: 34 c7 80 66 2a fc 89 c2 89 d8 e8 92 44 34 c7 c7 46 74 00 00 00 00 8b 5d ec 0f b6 8f 88 00 00 00 8b 97 84 00 00 00 8b 03 c1 e1 0f <89> 5a 28 c7 42 68 5f 0a 23 f9 c1 e0 08 0d 80 00 00 c0 09 c1 89 [ 248.076724] EIP: [<f9230446>] ftdi_open+0x144/0x191 [ftdi_sio] SS:ESP 0068:efe23e34 [ 248.076749] ---[ end trace 8622a1ddfc18a9dc ]--- Here is my lsmod output: Module Size Used by ftdi_sio 44808 1 usbserial 26600 3 ftdi_sio i915 26112 3 snd_pcm_oss 33312 0 snd_mixer_oss 12800 1 snd_pcm_oss mt352 5892 2 saa7134_alsa 10432 0 saa7134_dvb 18444 32 videobuf_dvb 4740 1 saa7134_dvb dvb_core 64896 2 saa7134_dvb,videobuf_dvb saa7134 127444 2 saa7134_alsa,saa7134_dvb tuner 20936 0 tuner_xc2028 17840 4 snd_hda_intel 253324 0 ir_common 35076 1 saa7134 videodev 30336 2 saa7134,tuner intelfb 31396 0 snd_pcm 57988 3 snd_pcm_oss,saa7134_alsa,snd_hda_intel v4l1_compat 12548 1 videodev compat_ioctl32 1536 1 saa7134 v4l2_common 9216 2 saa7134,tuner snd_timer 16904 1 snd_pcm videobuf_dma_sg 10244 3 saa7134_alsa,saa7134_dvb,saa7134 snd_page_alloc 7176 2 snd_hda_intel,snd_pcm snd_hwdep 6532 1 snd_hda_intel videobuf_core 14340 3 videobuf_dvb,saa7134,videobuf_dma_sg i2c_algo_bit 5380 1 intelfb lirc_mceusb2 12416 1 snd 41764 7 snd_pcm_oss,snd_mixer_oss,saa7134_alsa,snd_hda_intel,snd_pcm,snd_timer,snd_hwdep tveeprom 11012 1 saa7134 ohci1394 25776 0 lirc_dev 9752 3 lirc_mceusb2 usbhid 23680 0 ieee1394 67648 1 ohci1394 soundcore 5856 1 snd And here is my lsusb output: Bus 003 Device 002: ID 179d:0010 Bus 003 Device 001: ID 1d6b:0001 Bus 004 Device 001: ID 1d6b:0001 Bus 005 Device 002: ID 040b:7000 Weltrend Semiconductor Bus 005 Device 001: ID 1d6b:0001 Bus 002 Device 002: ID 0c16:0001 Gyration, Inc. Bus 002 Device 001: ID 1d6b:0001 Bus 001 Device 004: ID 0aec:3260 Neodio Technologies Corp. 7-in-1 Card Reader Bus 001 Device 003: ID 03f0:4e11 Hewlett-Packard Bus 001 Device 001: ID 1d6b:0002 Any finally the output of cat /proc/bus/usb/devices for the Weltrend device after modprobing the ftdi_sio module: T: Bus=05 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=040b ProdID=7000 Rev= 0.00 S: Manufacturer=AOpen Inc. S: Product=AOpen Inc. C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr= 64mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=03(HID ) Sub=00 Prot=00 Driver=ftdi_sio E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=36ms E: Ad=03(O) Atr=03(Int.) MxPS= 64 Ivl=10ms I:* If#= 1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=01 Driver=ftdi_sio E: Ad=82(I) Atr=03(Int.) MxPS= 64 Ivl=36ms Does anyone know what may be the problem or of any fixes? Any help/advice greatly appreciated. Thankyou Jason |
|
From: Pierre-Luc D. <pld...@pl...> - 2009-09-24 04:33:59
|
Hi, I was looking at the driver code source to find differences between between control commands for FT8U232AM and FT232BM. The only thing I could find is the value of the divisor that can differ for some particular baud rates. Am I right or this is only how the driver differs for these two chips? Thank you! |
|
From: Olivier F. <of...@ne...> - 2009-07-28 07:55:30
|
Hello, I checked the 2.6.30.3 kernel and I saw that the version of the included driver is the 1.4.3. Is there a plan to include the 1.5.0 in the vanilla kernel ? Is it a work in progress ? Sorry if this question has already been answered, I didn't found anything on the web. Thanks for your work on providing the FTDI driver for Linux. -- Olivier FAURAX |
|
From: Richard C. <sp...@ec...> - 2009-07-23 01:08:09
|
I've found that when I write to the device file, if I use writes which are greater than 15 bytes in length, all hell eventually breaks loose. I'm not sure what the sequence of events are that trigger hell, but it really seems as if if I limit the writes I make to 15 bytes (using direct system calls to write() rather than any language-dependant write) then everything works like it is supposed to. I can send the same amount of data as before, I just have to break it up into 15 byte chunks. ...and 16 bytes isn't small enough, it has to be 15 bytes. If I don't, then after some time (it kind of seems like I have to do a large read later) the driver will lock up. Sometimes the read() and write() system calls lock up. Sometimes using the stty command on the device file will lock up stty within a system call. Sometimes commands like 'lsusb -v' will also lock up in a system call. ...or maybe I shouldn't say 'sometimes' since usually they all happen, it's just that nothing is guaranteed. Sometimes disconnecting the device can return things to normal, though it might take a few attempts and some waiting, but since I upgraded to kernel 2.6.29-gentoo-r5, disconnecting the device when it is in this state causes an oops: Jul 22 13:59:46 isuck kernel: usb 1-2.2: clear tt 1 (90b1) error -71 Jul 22 13:59:46 isuck kernel: usb 1-2.2: clear tt 1 (10b2) error -71 Jul 22 13:59:46 isuck kernel: usb 1-2.2: clear tt 1 (10b2) error -71 Jul 22 13:59:46 isuck kernel: usb 1-2.2.4: clear tt 1 (90a1) error -71 Jul 22 13:59:46 isuck kernel: usb 1-2.2: USB disconnect, address 8 Jul 22 13:59:46 isuck kernel: usb 1-2.2.3: USB disconnect, address 11 Jul 22 13:59:46 isuck kernel: ftdi_sio ttyUSB1: FTDI USB Serial Device converter now disconnected from ttyUSB1 Jul 22 13:59:46 isuck kernel: ftdi_sio 1-2.2.3:1.0: device disconnected Jul 22 13:59:46 isuck kernel: usb 1-2.2.4: USB disconnect, address 9 Jul 22 13:59:46 isuck kernel: usb 1-2.2.4.3: USB disconnect, address 10 Jul 22 13:59:46 isuck kernel: ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 Jul 22 13:59:46 isuck kernel: ftdi_sio 1-2.2.4.3:1.0: device disconnected Jul 22 13:59:46 isuck kernel: BUG: unable to handle kernel NULL pointer dereference at 0000006c Jul 22 13:59:46 isuck kernel: IP: [<c03a333c>] ftdi_set_termios+0x3c/0x670 Jul 22 13:59:46 isuck kernel: *pde = 00000000 Jul 22 13:59:46 isuck kernel: Oops: 0000 [#1] PREEMPT SMP Jul 22 13:59:46 isuck kernel: last sysfs file: /sys/devices/pci0000:00/0000:00:1e.0/0000:04:03.0/class Jul 22 13:59:46 isuck kernel: Modules linked in: cryptoloop loop Jul 22 13:59:46 isuck kernel: Jul 22 13:59:46 isuck kernel: Pid: 20031, comm: stty Not tainted (2.6.29-gentoo-r5.isuck #10) MacBook3,1 Jul 22 13:59:46 isuck kernel: EIP: 0060:[<c03a333c>] EFLAGS: 00210246 CPU: 1 Jul 22 13:59:46 isuck kernel: EIP is at ftdi_set_termios+0x3c/0x670 Jul 22 13:59:46 isuck kernel: EAX: eb67a800 EBX: 00000000 ECX: eb7e3e38 EDX: 00000005 Jul 22 13:59:46 isuck kernel: ESI: eb769000 EDI: eb55db40 EBP: 00000000 ESP: eb7e3dc0 Jul 22 13:59:46 isuck kernel: DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Jul 22 13:59:46 isuck kernel: Process stty (pid: 20031, ti=eb7e2000 task=eb748d00 task.ti=eb7e2000) Jul 22 13:59:46 isuck kernel: Stack: Jul 22 13:59:46 isuck kernel: 7fffffff eb67a800 7fffffff eb67a8e4 c04c89a5 eb67a800 eb7e3e38 eb769000 Jul 22 13:59:46 isuck kernel: eb67a800 eb6e7400 00000005 c013deed c03a3300 eb769000 eb67a800 eb7e3e38 Jul 22 13:59:46 isuck kernel: c039e8c4 eb748d00 c013dd60 eb7e3e0c eb7e3e0c eb7e3e38 eb67a814 eb55db6c Jul 22 13:59:46 isuck kernel: Call Trace: Jul 22 13:59:46 isuck kernel: [<c04c89a5>] schedule_timeout+0x85/0xc0 Jul 22 13:59:46 isuck kernel: [<c013deed>] finish_wait+0x2d/0x70 Jul 22 13:59:46 isuck kernel: [<c03a3300>] ftdi_set_termios+0x0/0x670 Jul 22 13:59:46 isuck kernel: BUG: unable to handle kernel NULL pointer dereference at 00000044 Jul 22 13:59:46 isuck kernel: IP: [<c0133a2f>] del_timer+0xf/0x60 Jul 22 13:59:46 isuck kernel: *pde = 00000000 Jul 22 13:59:46 isuck kernel: [<c039e8c4>] serial_set_termios+0x44/0xd0 Jul 22 13:59:46 isuck kernel: [<c013dd60>] autoremove_wake_function+0x0/0x50 Jul 22 13:59:46 isuck kernel: [<c02a9cfb>] set_termios+0x25b/0x420 Jul 22 13:59:46 isuck kernel: [<c02a7480>] n_tty_ioctl+0x0/0xe0 Jul 22 13:59:46 isuck kernel: [<c02aa260>] tty_mode_ioctl+0x2c0/0x530 Jul 22 13:59:46 isuck kernel: [<c02aa745>] tty_ldisc_try+0x35/0x50 Jul 22 13:59:46 isuck kernel: [<c02aaa8c>] tty_ldisc_ref_wait+0xc/0xa0 Jul 22 13:59:46 isuck kernel: [<c039e652>] serial_ioctl+0x52/0xb0 Jul 22 13:59:46 isuck kernel: [<c02a7480>] n_tty_ioctl+0x0/0xe0 Jul 22 13:59:46 isuck kernel: [<c02a5256>] tty_ioctl+0x116/0x820 Jul 22 13:59:46 isuck kernel: [<c028c511>] rb_insert_color+0xc1/0xf0 Jul 22 13:59:46 isuck kernel: [<c02a5140>] tty_ioctl+0x0/0x820 Jul 22 13:59:46 isuck kernel: [<c018e2db>] vfs_ioctl+0x2b/0x90 Jul 22 13:59:46 isuck kernel: [<c0170575>] __vma_link+0x45/0x80 Jul 22 13:59:46 isuck kernel: [<c018e4eb>] do_vfs_ioctl+0x7b/0x5c0 Jul 22 13:59:46 isuck kernel: [<c0171840>] do_brk+0x300/0x340 Jul 22 13:59:46 isuck kernel: [<c018ea6d>] sys_ioctl+0x3d/0x70 Jul 22 13:59:46 isuck kernel: [<c01033f1>] sysenter_do_call+0x12/0x25 Jul 22 13:59:46 isuck kernel: Code: 24 18 8b 1d e8 c1 6a c0 8b 02 85 db 8b 00 89 44 24 24 8b 44 24 20 8b aa 6c 01 00 00 8b 78 30 8b 17 89 54 24 28 0f 85 49 05 00 00 <8b> 55 6c 85 d2 74 22 f7 47 08 0f 10 00 00 74 19 8b 0d e8 c1 6a Jul 22 13:59:46 isuck kernel: EIP: [<c03a333c>] ftdi_set_termios+0x3c/0x670 SS:ESP 0068:eb7e3dc0 Jul 22 13:59:46 isuck kernel: ---[ end trace 9c54124943e0dab1 ]--- On the bright side, those device files are stuck, and so I get new device files when I reattach the devices, and so I can use them again immediately. (Before I'd just get the same device files again, which often inheireted their broken state from their last use.) On the dark side, any processes that had those devices open are stuck as well, and sometimes the oops message is followed by a message that I need to reboot. ...which remindes me, I need to reboot. Anyway, I wonder, why does this driver implement TTY devices? Maybe it's different from the other supported chips, but the UM245R I'm using has nothing at all in common with a serial port, let alone a TTY, other than the fact that they're all character devices. It'd be a lot more convienent if the driver created simple character devices, like "/dev/FTDI/whatever" where 'whatever' is the serial number of the device. Then I wouldn't have to parse through 'dmesg' and 'lsusb -v' to track down which device file refers to which physical device, nor would I have to use the 'stty' command to disable all of the nonsense in the TTY layer. Then I could just "hexdump -C < /dev/FTDI/TS154323" and not have to worry that it's been unplugged recently and so I need to run "stty raw -echo < /dev/ttyUSB0" again, or that it might now refer to some completely different device which can happen since I often plug in two at at time. |
|
From: Satoru M. <sat...@gm...> - 2009-07-16 09:35:26
|
Hi David, Thank you very much! I confirmed this problem was fixed with modified ftdi_sio driver. Best regards, Satoru On Thu, Jul 16, 2009 at 17:10, David Decotigny<dav...@ll...> wrote: > > Hello, > > This sounds close to: > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/376128 > If this is it, you might have to recompile a newer kernel, or fix the > bug by yourself (1-liner). > > Regards, > |
|
From: David D. <dav...@ll...> - 2009-07-16 08:54:34
|
Hello, This sounds close to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/376128 If this is it, you might have to recompile a newer kernel, or fix the bug by yourself (1-liner). Regards, |
|
From: Satoru M. <sat...@gm...> - 2009-07-15 05:52:28
|
Hi all,
I'm using FT2232 usb serial device with Linux PC and I have a problem
that I get error on re-opening usb serial port after closing the port
with excess input data from usb serial device.
- connect usb serial device which keeps sending data.
- on Linux PC, open usb serial port and not read any data from the
port. (not call read())
- close the port.
- try to open the port again, but open() returns -1 with errno is EIO(=5).
Once fall in this situation,
- removing and attaching the usb device cannot recover it. (open error again)
- unloading and loading (rmmod and modprobe) ftdi_sio module cannot recover it.
- try to unload usbserial module after unloading ftdi_sio, get following error.
ERROR: Module usbserial is in use
"rmmod -f" then following error.
ERROR: Removing 'usbserial': Resource temporarily unavailable
- only reboot Linux can recover this situation.
I think it is similar to the case reported by Paul in
"[Ftdi-usb-sio-devel] cannot open port after improper closing" at
2009-02-13 00:13.
I'd like to know how to avoid this situation and recover it without
rebooting Linux.
Could anyone give me advice ?
My environment is:
Linux PC: DELL Inspiron Mini 9 and 10.
kernel: 2.6.28-13 (Ubuntu 9.04 Netbook Remix)
ftdi_sio: v1.4.3
Source code that I used for the test is below.
------
#include <stdlib.h>
#include <stdio.h>
#include <errno.h>
#include <fcntl.h>
#include <string.h>
#include <termios.h>
#include <signal.h>
struct termios gOldTio;
int my_open(const char *device){
struct termios newtio;
int fd;
tcflag_t baudflag = B57600;
fd = open(device, O_RDWR | O_NOCTTY);
if (fd < 0){
fprintf(stderr,"Unable to open device %s for rw : %i\n", device, errno);
if((fd = open(device, O_RDONLY | O_NOCTTY)) < 0){
fprintf(stderr,"Unable to open device %s for read only :
%i\n", device, errno);
return -1;
}
}
tcgetattr(fd,&gOldTio);
memset(&newtio, 0, sizeof(newtio));
newtio.c_cflag = CS8 | CLOCAL | CREAD;
newtio.c_iflag = IGNPAR | IGNBRK;
newtio.c_cc [VMIN] = 1; /* Otherwise we go info busy loop */
cfsetispeed(&newtio, baudflag);
cfsetospeed(&newtio, baudflag);
newtio.c_oflag = 0;
if (tcflush(fd, TCIFLUSH) >= 0 && tcsetattr(fd, TCSANOW, &newtio) >= 0){
return fd;
}
close(fd);
return -1;
}
int gFd = -1;
void my_shutdown(int val){
tcflush(gFd,TCIFLUSH);
tcsetattr(gFd,TCSANOW,&gOldTio);
close(gFd);
exit(0);
}
int main(int argc, char **argv){
char *dev = "/dev/ttyUSB1";
if(argc == 2){
dev = argv[1];
}
gFd = my_open(dev);
if(gFd != -1){
if (signal(SIGTERM,my_shutdown) == SIG_ERR){
}
if (signal(SIGINT,my_shutdown) == SIG_ERR){
}
while(1){
char buf[1024];
//*** read(gFd,buf,sizeof(buf));
}
close(gFd);
}
return 0;
}
------
Thanks
Satoru
|
|
From: ham <ham...@ya...> - 2009-06-21 03:19:55
|
sudo lsusb -v
Bus 001 Device 003: ID 0403:c8d8 Future Technology Devices International, Ltd
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x0403 Future Technology Devices International, Ltd
idProduct 0xc8d8
bcdDevice 4.00
iManufacturer 1 FTDI
iProduct 2 EPSILON Phoenix USB V2.29
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 2 EPSILON Phoenix USB V2.29
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Status: 0x0000
(Bus Powered)
|
|
From: ham <ham...@ya...> - 2009-06-20 13:22:37
|
hi could any one help me to setup this card reader on ubuntu 8.04 server here the picture of the programmer [IMG]http://www.epsilon.com.pl/test/img/support/phx_usb_zo_i_bo2_250.jpg[/IMG] here some info [url=http://www.epsilon.com.pl/test/index...hx_usb_cfg.htm]Epsilon Sklep on-line[/url] thanks |
|
From: Bill R. <bil...@gm...> - 2009-03-10 17:39:29
|
The other questions is What is using 100% CPU? top should give you a hint. If it's your program you'll know where to look. On Wed, Mar 11, 2009 at 6:13 AM, Toan Pham <tph...@gm...> wrote: > you shouldn't get that high CPU utilization. Would you please compile > the kernel with usb debug, and ftdi_sio loaded with debug=1. > I also use the same chip on linux 2.6.21 and tried on the lastest > Ubuntu and had no problem. Although, i didn't run it at 230400, and > flow control enabled. If possible, would you please try to run it at > lower baudrate and/or without software flow control? > . thank you. > > Toan > > > On Tue, Mar 10, 2009 at 11:41 AM, iMac 266 <im...@gm...> wrote: > > Hi, > > > > I am using a FT232RL USB to Serial adapter. Baudrate = 230400, one stop > and > > start bit, software flow control enabled. > > > > I am using this on the 2.6.27 kernel. > > > > I am wondering why my cpu is at 100% when I am transmitting data > > continuously. When I use the same adapter and python code on a windows > > machine I get 3% cpu usage. Is this a known issue? > > > > Thanks, > > > > Tim > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > > Ftdi-usb-sio-devel mailing list > > Ftd...@li... > > https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel > > > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Ftdi-usb-sio-devel mailing list > Ftd...@li... > https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel > |
|
From: Toan P. <tph...@gm...> - 2009-03-10 17:14:07
|
you shouldn't get that high CPU utilization. Would you please compile the kernel with usb debug, and ftdi_sio loaded with debug=1. I also use the same chip on linux 2.6.21 and tried on the lastest Ubuntu and had no problem. Although, i didn't run it at 230400, and flow control enabled. If possible, would you please try to run it at lower baudrate and/or without software flow control? . thank you. Toan On Tue, Mar 10, 2009 at 11:41 AM, iMac 266 <im...@gm...> wrote: > Hi, > > I am using a FT232RL USB to Serial adapter. Baudrate = 230400, one stop and > start bit, software flow control enabled. > > I am using this on the 2.6.27 kernel. > > I am wondering why my cpu is at 100% when I am transmitting data > continuously. When I use the same adapter and python code on a windows > machine I get 3% cpu usage. Is this a known issue? > > Thanks, > > Tim > > ------------------------------------------------------------------------------ > > _______________________________________________ > Ftdi-usb-sio-devel mailing list > Ftd...@li... > https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel > > |
|
From: iMac 2. <im...@gm...> - 2009-03-10 15:41:24
|
Hi, I am using a FT232RL USB to Serial adapter. Baudrate = 230400, one stop and start bit, software flow control enabled. I am using this on the 2.6.27 kernel. I am wondering why my cpu is at 100% when I am transmitting data continuously. When I use the same adapter and python code on a windows machine I get 3% cpu usage. Is this a known issue? Thanks, Tim |
|
From: Islam S. B. <isl...@gm...> - 2009-03-09 14:53:44
|
Hello List, I was evaluating a design option to choose the FT4232H chip from FTDI to convert from serial to usb. I was asking about the status of the support of this chip in the ftdi_sio kernel driver. By looking at the source of 2.6.28 kernel <http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/usb/serial/ftdi_sio.h;h=e300c840f8cad0dda5d1bbe30d070212f925b6a6;hb=7a203f3b089be4410fe065dd9927027eade94557>, I can see no sign of the FT4232H support. The enum typedef enum { SIO = 1, FT8U232AM = 2, FT232BM = 3, FT2232C = 4, FT232RL = 5, } ftdi_chip_type_t; does not contain the chip type of FT4232H. So I assumed that the chip is not yet supported. Also, checking OpenOCD development list: https://lists.berlios.de/pipermail/openocd-development/2009-February/004749.html it seems like the support for this chip is not done yet. Can anybody confirm the status of this chip and whether it is planned to be supported in the near future? Thank you very much for your time and consideration. Regards, Islam -- Islam Samir Badreldin Software Lead Engineer BioBusiness, Egypt http://biobusiness-eg.com/ |
|
From: Paul T. <pth...@gm...> - 2009-02-13 14:16:26
|
How do you reset it? 2009/2/13 David Decotigny <dav...@ll...>: > > Hello, > > Something similar sometimes happens to us. My understanding is that the > ftdi output buffer (slave device's side) is full and keeps on being > filled by the HCI or linux usb layers (?), but the slave device doesn't > eat that data. On our design, resetting the slave device does the trick > (it will eat some data at startup, so generally we have to reset it > several times so that it drains completely the linux/hci buffered data > via the ftdi). > > I don't know if there is any means to cleanly drain all the buffers > (provided my understanding was right) in software. Any hint would be > welcome. > > I might be wrong in my explanation. Please don't hesitate to correct me. > Hope this helps anyway, > |
|
From: David D. <dav...@ll...> - 2009-02-13 08:35:44
|
Hello, Something similar sometimes happens to us. My understanding is that the ftdi output buffer (slave device's side) is full and keeps on being filled by the HCI or linux usb layers (?), but the slave device doesn't eat that data. On our design, resetting the slave device does the trick (it will eat some data at startup, so generally we have to reset it several times so that it drains completely the linux/hci buffered data via the ftdi). I don't know if there is any means to cleanly drain all the buffers (provided my understanding was right) in software. Any hint would be welcome. I might be wrong in my explanation. Please don't hesitate to correct me. Hope this helps anyway, |
|
From: Paul T. <pth...@gm...> - 2009-02-13 00:13:21
|
I'm using the ftdi_sio driver in the 2.6.28.4 kernel. Sometimes when I kill an app, I can no longer access /dev/ttyUSB0 (i.e. close never got called). minicom, my app & more all fail. "more /dev/ttyUSB0" returns "/dev/ttyUSB0: Input/output error". I don't get any errors in dmesg. This persists after unloading and reloading the module. The platform is the AT91RM9200 (an arm9 processor). Does anyone else see this? Am I missing something small? thanks, Paul |
|
From: Bill R. <bil...@gm...> - 2009-01-30 19:48:06
|
On Sat, Jan 31, 2009 at 4:15 AM, Toan Pham <tph...@gm...> wrote: > Bill, > > I have a question about flow control in the ftdi driver. > I notice that when I use serial port without flow control, the > ftdi driver still does some kind of flow control with the ftdi chip. > This is found in the set_mctrl, clear_mctrl, and update_mctrl functions. i don't know about those functions. Ian Abbott implemented them. http://www.mail-archive.com/bk-...@vg.../msg07158.html Looks like using them can make a massive difference to performance. The best place to look will probably be the usb_serial stuff or further up the stack in the tty driver. > > > Is there a documentation on how flow control is implemented in this driver? > > Also, in the function update_mctrl, when something goes bad > you disconnect the usb device, as seen in the code below. > I've been experiencing alot of disconnections at this point, > maybe due to noise in the bus; but I've tried shorter cable > length, and disconnection still happen. Would you please > explain why we disconnect here, and how often we do > flow control request with the chip? thank you. I assume that if an error is seen the assumption is made that the usb connection needs to be dropped. You could try removing the usb_disconnect but to be careful I suggest you dig around and see which error codes returned by usb_control_msg you should and shouldn't drop the connection on. Of course be prepared for panics or something if you try this! > > > > > > REFERENCE: > > --------------------------------------------------------------------------------- > static int update_mctrl(struct usb_serial_port *port, unsigned int > set, unsigned int clear) > { > struct ftdi_private *priv = usb_get_serial_port_data(port); > char *buf; > unsigned urb_value; > int rv; > > if (((set | clear) & (TIOCM_DTR | TIOCM_RTS)) == 0) { > dbg("%s - DTR|RTS not being set|cleared", __FUNCTION__); > return 0; /* no change */ > } > > buf = kmalloc(1, GFP_NOIO); > if (!buf) { > return -ENOMEM; > } > > clear &= ~set; /* 'set' takes precedence over 'clear' */ > urb_value = 0; > if (clear & TIOCM_DTR) > urb_value |= FTDI_SIO_SET_DTR_LOW; > if (clear & TIOCM_RTS) > urb_value |= FTDI_SIO_SET_RTS_LOW; > if (set & TIOCM_DTR) > urb_value |= FTDI_SIO_SET_DTR_HIGH; > if (set & TIOCM_RTS) > urb_value |= FTDI_SIO_SET_RTS_HIGH; > rv = usb_control_msg(port->serial->dev, > usb_sndctrlpipe(port->serial->dev, 0), > FTDI_SIO_SET_MODEM_CTRL_REQUEST, > FTDI_SIO_SET_MODEM_CTRL_REQUEST_TYPE, > urb_value, priv->interface, > buf, 0, WDR_TIMEOUT); > > kfree(buf); > if (rv < 0) { > err("%s Error from MODEM_CTRL urb: DTR %s, RTS %s", > __FUNCTION__, > (set & TIOCM_DTR) ? "HIGH" : > (clear & TIOCM_DTR) ? "LOW" : "unchanged", > (set & TIOCM_RTS) ? "HIGH" : > (clear & TIOCM_RTS) ? "LOW" : "unchanged"); > usb_disconnect(port); /* THIS IS WHERE I OFFEN GET > DISCONNECTIONS, > i AM NOT SURE WHAT WENT BAD, HOST CONTROLLER, HUB, DEVICE?*/ > } else { > dbg("%s - DTR %s, RTS %s", __FUNCTION__, > (set & TIOCM_DTR) ? "HIGH" : > (clear & TIOCM_DTR) ? "LOW" : "unchanged", > (set & TIOCM_RTS) ? "HIGH" : > (clear & TIOCM_RTS) ? "LOW" : "unchanged"); > priv->last_dtr_rts = (priv->last_dtr_rts & ~clear) | set; > } > return rv; > } > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Ftdi-usb-sio-devel mailing list > Ftd...@li... > https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel > |
|
From: Toan P. <tph...@gm...> - 2009-01-30 15:15:13
|
Bill,
I have a question about flow control in the ftdi driver.
I notice that when I use serial port without flow control, the
ftdi driver still does some kind of flow control with the ftdi chip.
This is found in the set_mctrl, clear_mctrl, and update_mctrl functions.
Is there a documentation on how flow control is implemented in this driver?
Also, in the function update_mctrl, when something goes bad
you disconnect the usb device, as seen in the code below.
I've been experiencing alot of disconnections at this point,
maybe due to noise in the bus; but I've tried shorter cable
length, and disconnection still happen. Would you please
explain why we disconnect here, and how often we do
flow control request with the chip? thank you.
REFERENCE:
---------------------------------------------------------------------------------
static int update_mctrl(struct usb_serial_port *port, unsigned int
set, unsigned int clear)
{
struct ftdi_private *priv = usb_get_serial_port_data(port);
char *buf;
unsigned urb_value;
int rv;
if (((set | clear) & (TIOCM_DTR | TIOCM_RTS)) == 0) {
dbg("%s - DTR|RTS not being set|cleared", __FUNCTION__);
return 0; /* no change */
}
buf = kmalloc(1, GFP_NOIO);
if (!buf) {
return -ENOMEM;
}
clear &= ~set; /* 'set' takes precedence over 'clear' */
urb_value = 0;
if (clear & TIOCM_DTR)
urb_value |= FTDI_SIO_SET_DTR_LOW;
if (clear & TIOCM_RTS)
urb_value |= FTDI_SIO_SET_RTS_LOW;
if (set & TIOCM_DTR)
urb_value |= FTDI_SIO_SET_DTR_HIGH;
if (set & TIOCM_RTS)
urb_value |= FTDI_SIO_SET_RTS_HIGH;
rv = usb_control_msg(port->serial->dev,
usb_sndctrlpipe(port->serial->dev, 0),
FTDI_SIO_SET_MODEM_CTRL_REQUEST,
FTDI_SIO_SET_MODEM_CTRL_REQUEST_TYPE,
urb_value, priv->interface,
buf, 0, WDR_TIMEOUT);
kfree(buf);
if (rv < 0) {
err("%s Error from MODEM_CTRL urb: DTR %s, RTS %s",
__FUNCTION__,
(set & TIOCM_DTR) ? "HIGH" :
(clear & TIOCM_DTR) ? "LOW" : "unchanged",
(set & TIOCM_RTS) ? "HIGH" :
(clear & TIOCM_RTS) ? "LOW" : "unchanged");
usb_disconnect(port); /* THIS IS WHERE I OFFEN GET DISCONNECTIONS,
i AM NOT SURE WHAT WENT BAD, HOST CONTROLLER, HUB, DEVICE?*/
} else {
dbg("%s - DTR %s, RTS %s", __FUNCTION__,
(set & TIOCM_DTR) ? "HIGH" :
(clear & TIOCM_DTR) ? "LOW" : "unchanged",
(set & TIOCM_RTS) ? "HIGH" :
(clear & TIOCM_RTS) ? "LOW" : "unchanged");
priv->last_dtr_rts = (priv->last_dtr_rts & ~clear) | set;
}
return rv;
}
|
|
From: Bill R. <bil...@gm...> - 2009-01-28 18:05:47
|
That's a repeatable enough problem you should raise it with the linux usb developer folks. It's quite possibly a problem with the USB stack itself and if you get that many errors you'd be a great test case for them to try to fix it. Of course it could also be an actual hardware bug. At the very least it would help in making the error recovery in the stack better. On Thu, Jan 29, 2009 at 3:40 AM, Toan Pham <tph...@gm...> wrote: > Bill Ryder, > > This bug seem very related to the bus disconnect and reconnect problem > that I discussed to you about a month ago. > What happened was: we had 4 keypads on a USB bus which sends and > receive data to the linux host in relatively low bandwidth, > approximately 4 bytes per Endpoint transaction per keypad per .3 > second. Running at this rate, we experience approximately 5 > disconnection-reconnection per day per system (usb bus). In many > cases, our application is able to redetect and communicate with > keypads with has been disconnected/reconnected. In some rare cases, > physical disconnect and reconnect of a device is required for our > application to talk to it. > > Here is a dmesg of one system running UBUNTU : > > -------------------------------------------------------------------------------------------------- > [358472.160465] hub 3-0:1.0: port 2 disabled by hub (EMI?), re-enabling... > [358472.160491] usb 3-2: USB disconnect, address 8 > [358472.160494] usb 3-2.1: USB disconnect, address 15 > [358472.160632] ftdi_sio 3-2.1:1.0: device disconnected > [358472.160747] usb 3-2.2: USB disconnect, address 10 > [358472.160839] ftdi_sio 3-2.2:1.0: device disconnected > [358472.160942] usb 3-2.3: USB disconnect, address 11 > [358472.161028] ftdi_sio 3-2.3:1.0: device disconnected > [358472.161126] usb 3-2.4: USB disconnect, address 14 > [358472.161209] ftdi_sio 3-2.4:1.0: device disconnected > [358472.272338] usb 3-2: new full speed USB device using uhci_hcd and > address 16 > [358472.273327] > /build/buildd/linux-2.6.24/drivers/usb/serial/ftdi_sio.c: error from > flowcontrol urb > [358472.273400] > /build/buildd/linux-2.6.24/drivers/usb/serial/ftdi_sio.c: update_mctrl > Error from MODEM_CTRL urb: DTR LOW, RTS LOW > [358472.273794] ftdi_sio ttyUSB2: FTDI USB Serial Device converter now > disconnected from ttyUSB2 > [358472.282327] > /build/buildd/linux-2.6.24/drivers/usb/serial/ftdi_sio.c: error from > flowcontrol urb > [358472.282403] > /build/buildd/linux-2.6.24/drivers/usb/serial/ftdi_sio.c: update_mctrl > Error from MODEM_CTRL urb: DTR LOW, RTS LOW > [358472.282781] ftdi_sio ttyUSB3: FTDI USB Serial Device converter now > disconnected from ttyUSB3 > [358472.290235] > /build/buildd/linux-2.6.24/drivers/usb/serial/ftdi_sio.c: error from > flowcontrol urb > [358472.290309] > /build/buildd/linux-2.6.24/drivers/usb/serial/ftdi_sio.c: update_mctrl > Error from MODEM_CTRL urb: DTR LOW, RTS LOW > [358472.290691] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now > disconnected from ttyUSB0 > [358472.383373] > /build/buildd/linux-2.6.24/drivers/usb/serial/ftdi_sio.c: error from > flowcontrol urb > [358472.383425] > /build/buildd/linux-2.6.24/drivers/usb/serial/ftdi_sio.c: update_mctrl > Error from MODEM_CTRL urb: DTR LOW, RTS LOW > [358472.383809] ftdi_sio ttyUSB1: FTDI USB Serial Device converter now > disconnected from ttyUSB1 > [358472.415852] usb 3-2: configuration #1 chosen from 1 choice > [358472.418784] hub 3-2:1.0: USB hub found > [358472.420745] hub 3-2:1.0: 4 ports detected > [358472.749410] usb 3-2.1: new full speed USB device using uhci_hcd > and address 17 > [358472.908371] usb 3-2.1: configuration #1 chosen from 1 choice > [358472.911319] ftdi_sio 3-2.1:1.0: FTDI USB Serial Device converter > detected > [358472.911350] > /build/buildd/linux-2.6.24/drivers/usb/serial/ftdi_sio.c: Detected > FT232RL > [358472.911498] usb 3-2.1: FTDI USB Serial Device converter now > attached to ttyUSB0 > [358473.136029] usb 3-2.2: new full speed USB device using uhci_hcd > and address 18 > [358473.295999] usb 3-2.2: configuration #1 chosen from 1 choice > [358473.298945] ftdi_sio 3-2.2:1.0: FTDI USB Serial Device converter > detected > [358473.298977] > /build/buildd/linux-2.6.24/drivers/usb/serial/ftdi_sio.c: Detected > FT232RL > [358473.299129] usb 3-2.2: FTDI USB Serial Device converter now > attached to ttyUSB1 > [358473.519654] usb 3-2.3: new full speed USB device using uhci_hcd > and address 19 > [358473.679628] usb 3-2.3: configuration #1 chosen from 1 choice > [358473.682569] ftdi_sio 3-2.3:1.0: FTDI USB Serial Device converter > detected > [358473.682602] > /build/buildd/linux-2.6.24/drivers/usb/serial/ftdi_sio.c: Detected > FT232RL > [358473.682749] usb 3-2.3: FTDI USB Serial Device converter now > attached to ttyUSB2 > [358473.903279] usb 3-2.4: new full speed USB device using uhci_hcd > and address 20 > [358474.063248] usb 3-2.4: configuration #1 chosen from 1 choice > [358474.066194] ftdi_sio 3-2.4:1.0: FTDI USB Serial Device converter > detected > [358474.066227] > /build/buildd/linux-2.6.24/drivers/usb/serial/ftdi_sio.c: Detected > FT232RL > [358474.066374] usb 3-2.4: FTDI USB Serial Device converter now > attached to ttyUSB3 > > > > ANOTHER DMESG OF A SYSTEM RUNNING T2 (OUR CUSTOMIZED EMBEDDED LINUX OS) > > ----------------------------------------------------------------------------------------------------------------- > usb 2-1: USB disconnect, address 28 > usb 2-1.1: USB disconnect, address 29 > ftdi_sio 2-1.1:1.0: device disconnected > usb 2-1.2: USB disconnect, address 30 > drivers/usb/serial/ftdi_sio.c: update_mctrl Error from MODEM_CTRL urb: > DTR LOW, RTS LOW > drivers/usb/serial/ftdi_sio.c: update_mctrl Error from MODEM_CTRL urb: > DTR LOW, RTS LOW > drivers/usb/serial/ftdi_sio.c: error from flowcontrol urb > drivers/usb/serial/ftdi_sio.c: update_mctrl Error from MODEM_CTRL urb: > DTR LOW, RTS LOW > drivers/usb/serial/ftdi_sio.c: update_mctrl Error from MODEM_CTRL urb: > DTR LOW, RTS LOW > drivers/usb/serial/ftdi_sio.c: update_mctrl Error from MODEM_CTRL urb: > DTR LOW, RTS LOW > drivers/usb/serial/ftdi_sio.c: error from flowcontrol urb > drivers/usb/serial/ftdi_sio.c: update_mctrl Error from MODEM_CTRL urb: > DTR LOW, RTS LOW > drivers/usb/serial/ftdi_sio.c: update_mctrl Error from MODEM_CTRL urb: > DTR LOW, RTS LOW > drivers/usb/serial/ftdi_sio.c: update_mctrl Error from MODEM_CTRL urb: > DTR LOW, RTS LOW > drivers/usb/serial/ftdi_sio.c: error from flowcontrol urb > drivers/usb/serial/ftdi_sio.c: update_mctrl Error from MODEM_CTRL urb: > DTR LOW, RTS LOW > ftdi_sio 2-1.2:1.0: device disconnected > usb 2-1.3: USB disconnect, address 31 > ftdi_sio 2-1.3:1.0: device disconnected > usb 2-1.4: USB disconnect, address 32 > ftdi_sio 2-1.4:1.0: device disconnected > usb 2-1: clear tt 1 (9201) error -108 > usb 2-1: clear tt 1 (91f1) error -19 > ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from > ttyUSB0 > ftdi_sio ttyUSB1: FTDI USB Serial Device converter now disconnected from > ttyUSB1 > ftdi_sio ttyUSB3: FTDI USB Serial Device converter now disconnected from > ttyUSB3 > drivers/usb/serial/ftdi_sio.c: error from flowcontrol urb > drivers/usb/serial/ftdi_sio.c: update_mctrl Error from MODEM_CTRL urb: > DTR LOW, RTS LOW > ftdi_sio ttyUSB2: FTDI USB Serial Device converter now disconnected from > ttyUSB2 > usb 2-1: new high speed USB device using ehci_hcd and address 33 > usb 2-1: configuration #1 chosen from 1 choice > hub 2-1:1.0: USB hub found > hub 2-1:1.0: 4 ports detected > usb 2-1.1: new full speed USB device using ehci_hcd and address 34 > usb 2-1.1: configuration #1 chosen from 1 choice > ftdi_sio 2-1.1:1.0: FTDI USB Serial Device converter detected > drivers/usb/serial/ftdi_sio.c: Detected FT232RL > usb 2-1.1: FTDI USB Serial Device converter now attached to ttyUSB0 > usb 2-1.2: new full speed USB device using ehci_hcd and address 35 > usb 2-1.2: configuration #1 chosen from 1 choice > ftdi_sio 2-1.2:1.0: FTDI USB Serial Device converter detected > drivers/usb/serial/ftdi_sio.c: Detected FT232RL > usb 2-1.2: FTDI USB Serial Device converter now attached to ttyUSB1 > usb 2-1.3: new full speed USB device using ehci_hcd and address 36 > usb 2-1.3: configuration #1 chosen from 1 choice > ftdi_sio 2-1.3:1.0: FTDI USB Serial Device converter detected > drivers/usb/serial/ftdi_sio.c: Detected FT232RL > usb 2-1.3: FTDI USB Serial Device converter now attached to ttyUSB2 > usb 2-1.4: new full speed USB device using ehci_hcd and address 37 > usb 2-1.4: configuration #1 chosen from 1 choice > ftdi_sio 2-1.4:1.0: FTDI USB Serial Device converter detected > drivers/usb/serial/ftdi_sio.c: Detected FT232RL > usb 2-1.4: FTDI USB Serial Device converter now attached to ttyUSB3 > usb 2-1.4: USB disconnect, address 37 > ftdi_sio 2-1.4:1.0: device disconnected > usb 2-1.4: new full speed USB device using ehci_hcd and address 38 > drivers/usb/serial/ftdi_sio.c: error from flowcontrol urb > drivers/usb/serial/ftdi_sio.c: update_mctrl Error from MODEM_CTRL urb: > DTR LOW, RTS LOW > ftdi_sio ttyUSB3: FTDI USB Serial Device converter now disconnected from > ttyUSB3 > usb 2-1.4: configuration #1 chosen from 1 choice > ftdi_sio 2-1.4:1.0: FTDI USB Serial Device converter detected > drivers/usb/serial/ftdi_sio.c: Detected FT232RL > usb 2-1.4: FTDI USB Serial Device converter now attached to ttyUSB3 > usb 2-1.4: USB disconnect, address 38 > ftdi_sio 2-1.4:1.0: device disconnected > drivers/usb/serial/ftdi_sio.c: error from flowcontrol urb > drivers/usb/serial/ftdi_sio.c: update_mctrl Error from MODEM_CTRL urb: > DTR LOW, RTS LOW > ftdi_sio ttyUSB3: FTDI USB Serial Device converter now disconnected from > ttyUSB3 > usb 2-1.4: new full speed USB device using ehci_hcd and address 39 > usb 2-1.4: configuration #1 chosen from 1 choice > ftdi_sio 2-1.4:1.0: FTDI USB Serial Device converter detected > drivers/usb/serial/ftdi_sio.c: Detected FT232RL > usb 2-1.4: FTDI USB Serial Device converter now attached to ttyUSB3 > > > I've just ordered the TOTAL PHASE Beagle USB 480 Protocol analyzer > with hardware filtering. > Hopefully in the next few days, I'd be able to findout what really > happened. > > Toan > > > > > On Wed, Jan 28, 2009 at 3:57 AM, Bill Ryder <bil...@gm...> > wrote: > > This bit is suspicious: > > > > [72206.721645] /tmp/linux-2.6.27.9/drivers/ > > usb/serial/ftdi_sio.c: (this > > is ok on close) nonzero read bulk status received: -75 > > [72206.721652] /tmp/linux-2.6.27.9/drivers/usb/serial/ftdi_sio.c: > > ftdi_write_bulk_callback - port 0 > > [72206.856067] hub 4-0:1.0: port 2 disabled by hub (EMI?), re-enabling... > > [72206.856076] usb 4-2: USB disconnect, address 43 > > The write bulk callback gives an error then the usb stack says the hub > has > > disabled the port - which is probably the cause of the error. > > > > You could try it without the hub in the way or maybe off another usb > port. > > > > > > > > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by: > > SourcForge Community > > SourceForge wants to tell your story. > > http://p.sf.net/sfu/sf-spreadtheword > > _______________________________________________ > > Ftdi-usb-sio-devel mailing list > > Ftd...@li... > > https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel > > > > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Ftdi-usb-sio-devel mailing list > Ftd...@li... > https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel > |
|
From: David D. <dav...@ll...> - 2009-01-28 17:57:18
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, Bill Ryder wrote: > You could try it without the hub in the way or maybe off another usb port. Indeed, it seems to have been something like this. I didn't use a hub, at least not one I plugged myself: I was using a usb port available in front of the PC box. However, it looks like this port was behind "something" (a hub ?) somewhere inside the PC box. Anyway, now I am using one of the usb ports on the back of the PC, and everything seems to work really well: we could perform at least 200000 write/read cycles [128 bytes] without any error. I don't know if it's a hub thing or not, but using this other port seems to have solved our problem. Now we're trying write/read cycles on a 16384-byte deep Fifo for the next 12h, and we'll see tomorrow morning if it worked... Thank you a lot ! Long live ftdi_sio ! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmAnHAACgkQld7vhusVrCF2/wCfSia+YWzf2kefq8+zQvx6ALFp U2gAnR9mF5RRbV5obqhYvzpLPZC7naqL =mJJh -----END PGP SIGNATURE----- |
|
From: Toan P. <tph...@gm...> - 2009-01-28 14:41:14
|
Bill Ryder, This bug seem very related to the bus disconnect and reconnect problem that I discussed to you about a month ago. What happened was: we had 4 keypads on a USB bus which sends and receive data to the linux host in relatively low bandwidth, approximately 4 bytes per Endpoint transaction per keypad per .3 second. Running at this rate, we experience approximately 5 disconnection-reconnection per day per system (usb bus). In many cases, our application is able to redetect and communicate with keypads with has been disconnected/reconnected. In some rare cases, physical disconnect and reconnect of a device is required for our application to talk to it. Here is a dmesg of one system running UBUNTU : -------------------------------------------------------------------------------------------------- [358472.160465] hub 3-0:1.0: port 2 disabled by hub (EMI?), re-enabling... [358472.160491] usb 3-2: USB disconnect, address 8 [358472.160494] usb 3-2.1: USB disconnect, address 15 [358472.160632] ftdi_sio 3-2.1:1.0: device disconnected [358472.160747] usb 3-2.2: USB disconnect, address 10 [358472.160839] ftdi_sio 3-2.2:1.0: device disconnected [358472.160942] usb 3-2.3: USB disconnect, address 11 [358472.161028] ftdi_sio 3-2.3:1.0: device disconnected [358472.161126] usb 3-2.4: USB disconnect, address 14 [358472.161209] ftdi_sio 3-2.4:1.0: device disconnected [358472.272338] usb 3-2: new full speed USB device using uhci_hcd and address 16 [358472.273327] /build/buildd/linux-2.6.24/drivers/usb/serial/ftdi_sio.c: error from flowcontrol urb [358472.273400] /build/buildd/linux-2.6.24/drivers/usb/serial/ftdi_sio.c: update_mctrl Error from MODEM_CTRL urb: DTR LOW, RTS LOW [358472.273794] ftdi_sio ttyUSB2: FTDI USB Serial Device converter now disconnected from ttyUSB2 [358472.282327] /build/buildd/linux-2.6.24/drivers/usb/serial/ftdi_sio.c: error from flowcontrol urb [358472.282403] /build/buildd/linux-2.6.24/drivers/usb/serial/ftdi_sio.c: update_mctrl Error from MODEM_CTRL urb: DTR LOW, RTS LOW [358472.282781] ftdi_sio ttyUSB3: FTDI USB Serial Device converter now disconnected from ttyUSB3 [358472.290235] /build/buildd/linux-2.6.24/drivers/usb/serial/ftdi_sio.c: error from flowcontrol urb [358472.290309] /build/buildd/linux-2.6.24/drivers/usb/serial/ftdi_sio.c: update_mctrl Error from MODEM_CTRL urb: DTR LOW, RTS LOW [358472.290691] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 [358472.383373] /build/buildd/linux-2.6.24/drivers/usb/serial/ftdi_sio.c: error from flowcontrol urb [358472.383425] /build/buildd/linux-2.6.24/drivers/usb/serial/ftdi_sio.c: update_mctrl Error from MODEM_CTRL urb: DTR LOW, RTS LOW [358472.383809] ftdi_sio ttyUSB1: FTDI USB Serial Device converter now disconnected from ttyUSB1 [358472.415852] usb 3-2: configuration #1 chosen from 1 choice [358472.418784] hub 3-2:1.0: USB hub found [358472.420745] hub 3-2:1.0: 4 ports detected [358472.749410] usb 3-2.1: new full speed USB device using uhci_hcd and address 17 [358472.908371] usb 3-2.1: configuration #1 chosen from 1 choice [358472.911319] ftdi_sio 3-2.1:1.0: FTDI USB Serial Device converter detected [358472.911350] /build/buildd/linux-2.6.24/drivers/usb/serial/ftdi_sio.c: Detected FT232RL [358472.911498] usb 3-2.1: FTDI USB Serial Device converter now attached to ttyUSB0 [358473.136029] usb 3-2.2: new full speed USB device using uhci_hcd and address 18 [358473.295999] usb 3-2.2: configuration #1 chosen from 1 choice [358473.298945] ftdi_sio 3-2.2:1.0: FTDI USB Serial Device converter detected [358473.298977] /build/buildd/linux-2.6.24/drivers/usb/serial/ftdi_sio.c: Detected FT232RL [358473.299129] usb 3-2.2: FTDI USB Serial Device converter now attached to ttyUSB1 [358473.519654] usb 3-2.3: new full speed USB device using uhci_hcd and address 19 [358473.679628] usb 3-2.3: configuration #1 chosen from 1 choice [358473.682569] ftdi_sio 3-2.3:1.0: FTDI USB Serial Device converter detected [358473.682602] /build/buildd/linux-2.6.24/drivers/usb/serial/ftdi_sio.c: Detected FT232RL [358473.682749] usb 3-2.3: FTDI USB Serial Device converter now attached to ttyUSB2 [358473.903279] usb 3-2.4: new full speed USB device using uhci_hcd and address 20 [358474.063248] usb 3-2.4: configuration #1 chosen from 1 choice [358474.066194] ftdi_sio 3-2.4:1.0: FTDI USB Serial Device converter detected [358474.066227] /build/buildd/linux-2.6.24/drivers/usb/serial/ftdi_sio.c: Detected FT232RL [358474.066374] usb 3-2.4: FTDI USB Serial Device converter now attached to ttyUSB3 ANOTHER DMESG OF A SYSTEM RUNNING T2 (OUR CUSTOMIZED EMBEDDED LINUX OS) ----------------------------------------------------------------------------------------------------------------- usb 2-1: USB disconnect, address 28 usb 2-1.1: USB disconnect, address 29 ftdi_sio 2-1.1:1.0: device disconnected usb 2-1.2: USB disconnect, address 30 drivers/usb/serial/ftdi_sio.c: update_mctrl Error from MODEM_CTRL urb: DTR LOW, RTS LOW drivers/usb/serial/ftdi_sio.c: update_mctrl Error from MODEM_CTRL urb: DTR LOW, RTS LOW drivers/usb/serial/ftdi_sio.c: error from flowcontrol urb drivers/usb/serial/ftdi_sio.c: update_mctrl Error from MODEM_CTRL urb: DTR LOW, RTS LOW drivers/usb/serial/ftdi_sio.c: update_mctrl Error from MODEM_CTRL urb: DTR LOW, RTS LOW drivers/usb/serial/ftdi_sio.c: update_mctrl Error from MODEM_CTRL urb: DTR LOW, RTS LOW drivers/usb/serial/ftdi_sio.c: error from flowcontrol urb drivers/usb/serial/ftdi_sio.c: update_mctrl Error from MODEM_CTRL urb: DTR LOW, RTS LOW drivers/usb/serial/ftdi_sio.c: update_mctrl Error from MODEM_CTRL urb: DTR LOW, RTS LOW drivers/usb/serial/ftdi_sio.c: update_mctrl Error from MODEM_CTRL urb: DTR LOW, RTS LOW drivers/usb/serial/ftdi_sio.c: error from flowcontrol urb drivers/usb/serial/ftdi_sio.c: update_mctrl Error from MODEM_CTRL urb: DTR LOW, RTS LOW ftdi_sio 2-1.2:1.0: device disconnected usb 2-1.3: USB disconnect, address 31 ftdi_sio 2-1.3:1.0: device disconnected usb 2-1.4: USB disconnect, address 32 ftdi_sio 2-1.4:1.0: device disconnected usb 2-1: clear tt 1 (9201) error -108 usb 2-1: clear tt 1 (91f1) error -19 ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 ftdi_sio ttyUSB1: FTDI USB Serial Device converter now disconnected from ttyUSB1 ftdi_sio ttyUSB3: FTDI USB Serial Device converter now disconnected from ttyUSB3 drivers/usb/serial/ftdi_sio.c: error from flowcontrol urb drivers/usb/serial/ftdi_sio.c: update_mctrl Error from MODEM_CTRL urb: DTR LOW, RTS LOW ftdi_sio ttyUSB2: FTDI USB Serial Device converter now disconnected from ttyUSB2 usb 2-1: new high speed USB device using ehci_hcd and address 33 usb 2-1: configuration #1 chosen from 1 choice hub 2-1:1.0: USB hub found hub 2-1:1.0: 4 ports detected usb 2-1.1: new full speed USB device using ehci_hcd and address 34 usb 2-1.1: configuration #1 chosen from 1 choice ftdi_sio 2-1.1:1.0: FTDI USB Serial Device converter detected drivers/usb/serial/ftdi_sio.c: Detected FT232RL usb 2-1.1: FTDI USB Serial Device converter now attached to ttyUSB0 usb 2-1.2: new full speed USB device using ehci_hcd and address 35 usb 2-1.2: configuration #1 chosen from 1 choice ftdi_sio 2-1.2:1.0: FTDI USB Serial Device converter detected drivers/usb/serial/ftdi_sio.c: Detected FT232RL usb 2-1.2: FTDI USB Serial Device converter now attached to ttyUSB1 usb 2-1.3: new full speed USB device using ehci_hcd and address 36 usb 2-1.3: configuration #1 chosen from 1 choice ftdi_sio 2-1.3:1.0: FTDI USB Serial Device converter detected drivers/usb/serial/ftdi_sio.c: Detected FT232RL usb 2-1.3: FTDI USB Serial Device converter now attached to ttyUSB2 usb 2-1.4: new full speed USB device using ehci_hcd and address 37 usb 2-1.4: configuration #1 chosen from 1 choice ftdi_sio 2-1.4:1.0: FTDI USB Serial Device converter detected drivers/usb/serial/ftdi_sio.c: Detected FT232RL usb 2-1.4: FTDI USB Serial Device converter now attached to ttyUSB3 usb 2-1.4: USB disconnect, address 37 ftdi_sio 2-1.4:1.0: device disconnected usb 2-1.4: new full speed USB device using ehci_hcd and address 38 drivers/usb/serial/ftdi_sio.c: error from flowcontrol urb drivers/usb/serial/ftdi_sio.c: update_mctrl Error from MODEM_CTRL urb: DTR LOW, RTS LOW ftdi_sio ttyUSB3: FTDI USB Serial Device converter now disconnected from ttyUSB3 usb 2-1.4: configuration #1 chosen from 1 choice ftdi_sio 2-1.4:1.0: FTDI USB Serial Device converter detected drivers/usb/serial/ftdi_sio.c: Detected FT232RL usb 2-1.4: FTDI USB Serial Device converter now attached to ttyUSB3 usb 2-1.4: USB disconnect, address 38 ftdi_sio 2-1.4:1.0: device disconnected drivers/usb/serial/ftdi_sio.c: error from flowcontrol urb drivers/usb/serial/ftdi_sio.c: update_mctrl Error from MODEM_CTRL urb: DTR LOW, RTS LOW ftdi_sio ttyUSB3: FTDI USB Serial Device converter now disconnected from ttyUSB3 usb 2-1.4: new full speed USB device using ehci_hcd and address 39 usb 2-1.4: configuration #1 chosen from 1 choice ftdi_sio 2-1.4:1.0: FTDI USB Serial Device converter detected drivers/usb/serial/ftdi_sio.c: Detected FT232RL usb 2-1.4: FTDI USB Serial Device converter now attached to ttyUSB3 I've just ordered the TOTAL PHASE Beagle USB 480 Protocol analyzer with hardware filtering. Hopefully in the next few days, I'd be able to findout what really happened. Toan On Wed, Jan 28, 2009 at 3:57 AM, Bill Ryder <bil...@gm...> wrote: > This bit is suspicious: > > [72206.721645] /tmp/linux-2.6.27.9/drivers/ > usb/serial/ftdi_sio.c: (this > is ok on close) nonzero read bulk status received: -75 > [72206.721652] /tmp/linux-2.6.27.9/drivers/usb/serial/ftdi_sio.c: > ftdi_write_bulk_callback - port 0 > [72206.856067] hub 4-0:1.0: port 2 disabled by hub (EMI?), re-enabling... > [72206.856076] usb 4-2: USB disconnect, address 43 > The write bulk callback gives an error then the usb stack says the hub has > disabled the port - which is probably the cause of the error. > > You could try it without the hub in the way or maybe off another usb port. > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Ftdi-usb-sio-devel mailing list > Ftd...@li... > https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel > > |
|
From: Bill R. <bil...@gm...> - 2009-01-28 08:57:25
|
This bit is suspicious: [72206.721645] /tmp/linux-2.6.27.9/drivers/usb/serial/ftdi_sio.c: (this is ok on close) nonzero read bulk status received: -75 [72206.721652] /tmp/linux-2.6.27.9/drivers/usb/serial/ftdi_sio.c: ftdi_write_bulk_callback - port 0 [72206.856067] hub 4-0:1.0: port 2 disabled by hub (EMI?), re-enabling... [72206.856076] usb 4-2: USB disconnect, address 43 The write bulk callback gives an error then the usb stack says the hub has disabled the port - which is probably the cause of the error. You could try it without the hub in the way or maybe off another usb port. |
|
From: David D. <dav...@ll...> - 2009-01-28 08:15:17
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, In our setup, we have a PC with its USB connected to a FTDI245BL chip connected to a (hardware) FIFO: we (the PC) first write 128 bytes to the FTDI, and then we expect to read back the exact same bytes from the FTDI. That is: the fifo first stores all the 128 bytes we write, then immediatly (a few nanoseconds later) sends them back to us, all this via the FTDI of course. I am running intrepid with kernel 2.6.27-9 on an UP IA32 (Pentium 4) machine (2.4GHz). The problem I am reporting is also reproducible with the ftdi_sio module recompiled from a vanilla kernel.org's 2.6.27.9 kernel. My kernel is not tainted. So, our setup works "most" of the time: we can do thousands of such write/read sessions of 128 bytes in a row. But at some point the read() returns with a length of '0', even though we did have everything written to our FIFO device (we checked with a digital analyzer), and sent back by our FIFO device to the FTDI (likewise). So I guess the FTDI sent everything back to the host (at least the debug below seems to confirm). The problem seems to happen independently on the size of our FIFO device / the size of the data packets we are using (we tried 32, 128, 256, 2048 bytes); however, the larger they are, the easier we get the bug. Moreover, it seems related to the load on the PC: the more it is loaded, the more likely this bug is going to show up. All this tends to suggest this bug is some kind of driver (synchronization ?) problem. When I load the ftdi_sio module in debug mode, I get the following messages when the write/read *works*: - -------------------------------------------------------------------- [72206.672669] ftdi_sio ttyUSB0: ftdi_write - length = 128, data = be bf c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd [72206.672744] /tmp/linux-2.6.27.9/drivers/usb/serial/ftdi_sio.c: ftdi_write write returning: 128 [72206.673520] /tmp/linux-2.6.27.9/drivers/usb/serial/ftdi_sio.c: ftdi_write_bulk_callback - port 0 [72206.688570] /tmp/linux-2.6.27.9/drivers/usb/serial/ftdi_sio.c: ftdi_read_bulk_callback - port 0 [72206.688577] /tmp/linux-2.6.27.9/drivers/usb/serial/ftdi_sio.c: ftdi_process_read - port 0 - -------------------------------------------------------------------- And when it *does not work* (ie. read() returns 0), we get: - -------------------------------------------------------------------- [72206.720802] ftdi_sio ttyUSB0: ftdi_write - length = 128, data = d9 da db dc dd de df e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf d0 d1 d2 d3 d4 d5 d6 d7 d8 [72206.720875] /tmp/linux-2.6.27.9/drivers/usb/serial/ftdi_sio.c: ftdi_write write returning: 128 [72206.721639] /tmp/linux-2.6.27.9/drivers/usb/serial/ftdi_sio.c: ftdi_read_bulk_callback - port 0 [72206.721645] /tmp/linux-2.6.27.9/drivers/usb/serial/ftdi_sio.c: (this is ok on close) nonzero read bulk status received: -75 [72206.721652] /tmp/linux-2.6.27.9/drivers/usb/serial/ftdi_sio.c: ftdi_write_bulk_callback - port 0 [72206.856067] hub 4-0:1.0: port 2 disabled by hub (EMI?), re-enabling... [72206.856076] usb 4-2: USB disconnect, address 43 [72206.859191] ftdi_sio 4-2:1.0: device disconnected [72206.859712] /tmp/linux-2.6.27.9/drivers/usb/serial/ftdi_sio.c: ftdi_close [72206.859722] /tmp/linux-2.6.27.9/drivers/usb/serial/ftdi_sio.c: ftdi_shutdown [72206.859748] /tmp/linux-2.6.27.9/drivers/usb/serial/ftdi_sio.c: ftdi_sio_port_remove [72206.859752] /tmp/linux-2.6.27.9/drivers/usb/serial/ftdi_sio.c: remove_sysfs_attrs [72206.860121] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 - -------------------------------------------------------------------- When it fails, I always had the write callback called /after/ the read callback (as is the case above). But I am not sure it does NEVER happen when everything is fine too. I can send the full traces to whoever wants to analyze them. Code-wise, I do have a problem figuring out what this "-75" return value stands for. Maybe it could help, maybe it should be ignored in some cases. Looking at the code, it seems that the snippet involved is: - -------------------------------------------------------------------- static void ftdi_read_bulk_callback(struct urb *urb) { [...] int status = urb->status; [...] if (status) { /* This will happen at close every time so it is a dbg not an err */ dbg("(this is ok on close) nonzero read bulk status received: %d", status); return; } [...] } - -------------------------------------------------------------------- So, to summarize my thoughts: could it be that the write/read callbacks are not allowed to get interleaved ? Or is it something else ? What does a status of -75 mean ? I can provide any further information on request. Thanks a lot for any help ! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmAE/8ACgkQld7vhusVrCEhkgCfbOO0m4T00Qsc8FGHB31LSqee Qn0AoIyz7n2WS+XIqKtdWkCM2Qu2P1Wb =bWPC -----END PGP SIGNATURE----- |
350 messages has been excluded from this view by a project administrator.
