davesedar
Posts: 31
Joined: Mon Mar 05, 2012 3:41 pm

Re: USB/serial converters very broken on Pi

Sat Jan 12, 2013 4:55 pm

O/S: 2012-12-16 wheezy-raspbian
I followed the instructions:
apt-get update
apt-get upgrade
wget http://goo.gl/1BOfJ -O /usr/bin/rpi-update && sudo chmod +x /usr/bin/rpi-update
apt-get install git-core
rpi-update

and created 'my.rules' in /etc/udev/rules.d
containing:
ATTRS {idVendor}=="110a", ATTRS {idProduct}=="1110", SYMLINK+="MOXA", ACTION=="add", OWNER=="pi"

but my Perl program:
$ob = Device::SerialPort->new("/dev/MOXA") || die "Cant open port: $!\n";

fails "can't getattr: Inappropriate ioctl for device..."

with the MOXA UPort 1110

any assistance gratefully appreciated
David Sedar

arsi
Posts: 6
Joined: Fri Nov 02, 2012 5:09 pm

Re: USB/serial converters very broken on Pi

Sat Jan 12, 2013 8:07 pm

Hi,
I found this on freebsd:

Fix LOW and FULL speed USB INTERRUPT endpoint support for the
DWC OTG driver. Fix a hang issue when using LOW and FULL speed
BULK traffic. Make sure we don't ask for data in the last
microframe. This allows using devices like USB mice and USB
keyboards connected to the RPI-B.

http://comments.gmane.org/gmane.os.free ... src/157559
http://code.metager.de/source/history/f ... /dwc_otg.h

It is the use of a Linux patch from RPI kernel, or that really works on freebsd???

ArSi

M33P
Posts: 199
Joined: Sun Sep 02, 2012 1:14 pm

Re: USB/serial converters very broken on Pi

Sat Jan 12, 2013 10:24 pm

arsi wrote:Hi,
I found this on freebsd:

Fix LOW and FULL speed USB INTERRUPT endpoint support for the
DWC OTG driver. Fix a hang issue when using LOW and FULL speed
BULK traffic. Make sure we don't ask for data in the last
microframe. This allows using devices like USB mice and USB
keyboards connected to the RPI-B.

http://comments.gmane.org/gmane.os.free ... src/157559
http://code.metager.de/source/history/f ... /dwc_otg.h

It is the use of a Linux patch from RPI kernel, or that really works on freebsd???

ArSi
It seems that FreeBSD have rolled their own driver. There would be no chance of integrating that into Linux because the codebases are entirely different - but that doesn't mean we can't take the lessons that they have learned with the hardware.

arsi
Posts: 6
Joined: Fri Nov 02, 2012 5:09 pm

Re: USB/serial converters very broken on Pi

Sat Jan 12, 2013 10:31 pm

;) Of course without DMA It will be slow and it will load the processor..

I have luckily completed stable OpenWrt kernel with dwc_otg.speed=1..
There are two PL2303 and USB modem sierrawireles and has been running for a month without freezing.
On the PL2303 driver I have turn off interrupt endpoint.
And it runs stable on 85 pieces of RPI. The final number will be 157..
I'm doing a commercial project, data transfer from PLC..

Arsi

MozisII
Posts: 11
Joined: Wed Jan 30, 2013 10:11 pm
Contact: Website

Re: USB/serial converters very broken on Pi

Mon Feb 18, 2013 2:55 pm

I apply toggle identification patch to my kernel to search about ftdi hang problem. I use ttyAMA0 device to monitor system and don't use ethernet (no ethernet cable).
Toggle pbm depend on ftdi chips:
FT232R, FT245R and FT2232M are OK
FT232BM crash at first access and sometime keep working with only one toggle error.
I put smsc95xx in module to test with or without lan driver: no change
I try with the Raspberry 'A' model : ALL IS WORKING.
If y add an USB hub I've same toggle error.
It's not a problem of power because I've same problem with a powered USB hub.

Then the problem occur ONLY when there is a physical USB hub between dwc and FTDI.

It seems that dwc documentation about internal register is not publicly available then it will be hard to find a solution.

BerryPicker
Posts: 177
Joined: Tue Oct 16, 2012 3:03 pm
Location: The East of England

Re: USB/serial converters very broken on Pi

Thu Feb 21, 2013 6:00 pm

MozisII wrote:It seems that dwc documentation about internal register is not publicly available then it will be hard to find a solution.
Please excuse me if this post is out of place, most of the discussion is well above my head, but I came across the following item in which Hans Petter Selasky suggests that documentation is available.
Raspberry PI gets USB support [FreeBSD 10 current]
http://lists.freebsd.org/pipermail/free ... 04099.html

M33P
Posts: 199
Joined: Sun Sep 02, 2012 1:14 pm

Re: USB/serial converters very broken on Pi

Sat Mar 02, 2013 11:22 am

I am now in possession of a FT232BM/BL based serial adapter (el cheapo RS232/RS485 converter on Ebay).

I can confirm that with the latest kernel on a default Raspbian the only step required to hard-lock the Pi is "minicom -D /dev/ttyUSB0".

- Behind a hub, USB port at highspeed: crash
- Behind a hub, USB port forced at fullspeed: works
- No hub (model A therefore port = fullspeed): works

It seems that putting this device behind a transaction translator causes the Pi to go boom. To the kernel cave!

M33P
Posts: 199
Joined: Sun Sep 02, 2012 1:14 pm

Re: USB/serial converters very broken on Pi

Tue Mar 05, 2013 8:08 pm

Fixed it, I think.

https://github.com/raspberrypi/linux/pull/242

Change is not merged yet - you'll have to patch the most recent kernel on github. Testing would be welcome - the FT232BM/BL and FT8U232 should now work with USB2.0 hubs.

It should also fix crashes for random data toggle errors - the intermittent freezes experienced by people with long uptime applications.

MozisII
Posts: 11
Joined: Wed Jan 30, 2013 10:11 pm
Contact: Website

Re: USB/serial converters very broken on Pi

Wed Mar 06, 2013 10:51 am

Cool !
I will test it this WE. How did you force speed on a hub port ?

MacJL
Posts: 7
Joined: Thu Aug 02, 2012 9:40 am

Re: USB/serial converters very broken on Pi

Thu Mar 07, 2013 9:35 am

Hello,

I saw that your patch was included in the last kernel on github https://github.com/Hexxeh/rpi-firmware/ ... 4c26c05b9d

So i've updated to the last kernel with rpi-update, and removed the 'dwc_otg.speed=1' option.

It works!!! I've no more crash with my FT232BL. With previous kernel, the rpi crashed every time when opening the tty.

Thank you M33P!

coyotebush
Posts: 12
Joined: Fri Mar 01, 2013 7:39 pm

Re: USB/serial converters very broken on Pi

Thu Mar 07, 2013 9:38 pm

Likewise, the latest update fixes the crashing problem when talking to a u-blox LEA-4T GPS receiver. The receiver has an "on chip" usb to serial converter with protocol similar to FTDI.

Thanks!

FYI.
[ 3.192047] usb 1-1.3: new full-speed USB device number 4 using dwc_otg
[ 3.310744] usb 1-1.3: New USB device found, idVendor=1546, idProduct=01a4
[ 3.319805] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 3.329237] usb 1-1.3: Product: ANTARIS(r) 4 - GPS Receiver
[ 3.337011] usb 1-1.3: Manufacturer: u-blox AG

AgomezCasa
Posts: 1
Joined: Sat Mar 09, 2013 7:31 am

Re: USB/serial converters very broken on Pi

Sat Mar 09, 2013 7:37 am

Thanks M33P
Now works perfecty my RFID Reader with FT232BL
I can keep going with my project

MozisII
Posts: 11
Joined: Wed Jan 30, 2013 10:11 pm
Contact: Website

Re: USB/serial converters (not very) broken on Pi

Sun Mar 10, 2013 10:34 am

I've just tested on my 'B' model with and without external hub:
FT232M : OK
FT2232M : OK
Then thanks a lot P33M! :lol:

gkoper
Posts: 13
Joined: Sun Mar 10, 2013 2:53 pm

Re: USB/serial converters (not very) broken on Pi

Sun Mar 10, 2013 2:59 pm

Dear all

I am quite new to this but I just quickly wanted to test fhem running on an RPI with an FHZ1300PC. The system freezes as soon as I try to connect the associated USB port. This seems very much the problem you describe here, but I fear my unix-knowledge is a bit outdated (by 20 years, although it will come back in due time). Anyway, how can I quickly continue this little project to see if I the FHZ1300PC performs well enough?

Thanks in advance,

Ger

gkoper
Posts: 13
Joined: Sun Mar 10, 2013 2:53 pm

Re: USB/serial converters (not very) broken on Pi

Mon Mar 11, 2013 4:48 am

On the FHEM forum the solution was posted,
see http://forum.fhem.de/index.php?t=msg&th ... 0&rid=1090

jdubin
Posts: 12
Joined: Sun Jun 03, 2012 2:27 am

Re: USB/serial converters (not very) broken on Pi

Fri Mar 15, 2013 2:18 am

I have a Multi-Tech MTA9234ZBA-USB which I'm trying to use with Hylafax, but the modem resets (and eventually the raspi locks up) whenever faxaddmodem (a script which calls stty) probes for the speed to communicate with the device. It's very similar to what you're describing with the FTDI devices, but this one uses a TI USB 3410.

I just ran rpi-update (#393 PREEMPT Fri Mar 8 16:36:28 GMT 2013), and as far as I can tell I have the update which includes the patch... but the problem remains. The patch doesn't seem specific to the problems of the FTDI devices, but then again, I have no idea what this patch actually does.

Any tips? Is there a chance this is related and that there's a fix coming down the track?

Thanks,
Jeff

BTW: Here is the output of dmesg from where the problem occurs:

Code: Select all

[  228.972455] ti_usb_3410_5052_1 ttyUSB0: ti_open - cannot clear output buffers, -71
[  229.194532] usb 1-1.2.4.2: USB disconnect, device number 10
[  229.195155] ti_usb_3410_5052_1 ttyUSB0: TI USB 3410 1 port adapter converter now disconnected from ttyUSB0
[  229.195243] ti_usb_3410_5052 1-1.2.4.2:2.0: device disconnected
[  229.436770] usb 1-1.2.4.2: new full-speed USB device number 11 using dwc_otg
[  229.553116] usb 1-1.2.4.2: New USB device found, idVendor=06e0, idProduct=0319
[  229.553147] usb 1-1.2.4.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  229.553163] usb 1-1.2.4.2: Product: TUSB3410 Serial Port
[  229.553176] usb 1-1.2.4.2: Manufacturer: Texas Instruments
[  229.555850] ti_usb_3410_5052 1-1.2.4.2:1.0: TI USB 3410 1 port adapter converter detected
[  230.256876] usb 1-1.2.4.2: reset full-speed USB device number 11 using dwc_otg
[  230.360624] usb 1-1.2.4.2: device firmware changed
[  230.361031] ti_usb_3410_5052: probe of 1-1.2.4.2:1.0 failed with error -5
[  230.368426] usb 1-1.2.4.2: USB disconnect, device number 11
[  230.446912] usb 1-1.2.4.2: new full-speed USB device number 12 using dwc_otg
[  230.586674] usb 1-1.2.4.2: New USB device found, idVendor=06e0, idProduct=0319
[  230.586705] usb 1-1.2.4.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  230.586722] usb 1-1.2.4.2: Product: TUSB3410 Serial Port
[  230.586736] usb 1-1.2.4.2: Manufacturer: Texas Instruments
[  230.589032] ti_usb_3410_5052 1-1.2.4.2:2.0: TI USB 3410 1 port adapter converter detected
[  230.589474] usb 1-1.2.4.2: TI USB 3410 1 port adapter converter now attached to ttyUSB0

M33P
Posts: 199
Joined: Sun Sep 02, 2012 1:14 pm

Re: USB/serial converters (not very) broken on Pi

Fri Mar 15, 2013 8:15 am

I think this device needs firmware, from looking at the datasheet.

What is listed in dmesg when you first plug the device in? It should load firmware on detection. The only message I can see once the device is "soft reset" is
[ 230.360624] usb 1-1.2.4.2: device firmware changed
Which is not particularly informative.

5V power OK ? via hub or direct from Pi?

jdubin
Posts: 12
Joined: Sun Jun 03, 2012 2:27 am

Re: USB/serial converters (not very) broken on Pi

Fri Mar 15, 2013 2:36 pm

Yep, the firmware was something I struggled with at first, but I eventually found mts_mt9234zba.fw was needed and placed it in /lib/firmware. The modem does communicate okay at first (e.g. AT commands via minicom are successful); it's only when stty tries to do its thing that it locks up. My power source seems to (finally) be solid (5.3v @ 2A HP Touchpad adapter), but I've also added a powered hub to be sure. Here's the output of dmesg after initially plugging in the device:

Code: Select all

[45894.512004] usb 1-1.2.4.2: new full-speed USB device number 13 using dwc_otg
[45894.628567] usb 1-1.2.4.2: New USB device found, idVendor=06e0, idProduct=0319
[45894.628600] usb 1-1.2.4.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[45894.628616] usb 1-1.2.4.2: Product: TUSB3410 Serial Port
[45894.628630] usb 1-1.2.4.2: Manufacturer: Texas Instruments
[45894.634875] ti_usb_3410_5052 1-1.2.4.2:1.0: TI USB 3410 1 port adapter converter detected
[45895.352124] usb 1-1.2.4.2: reset full-speed USB device number 13 using dwc_otg
[45895.455958] usb 1-1.2.4.2: device firmware changed
[45895.456392] ti_usb_3410_5052: probe of 1-1.2.4.2:1.0 failed with error -5
[45895.460403] usb 1-1.2.4.2: USB disconnect, device number 13
[45895.542159] usb 1-1.2.4.2: new full-speed USB device number 14 using dwc_otg
[45895.681470] usb 1-1.2.4.2: New USB device found, idVendor=06e0, idProduct=0319
[45895.681503] usb 1-1.2.4.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[45895.681520] usb 1-1.2.4.2: Product: TUSB3410 Serial Port
[45895.681534] usb 1-1.2.4.2: Manufacturer: Texas Instruments
[45895.684757] ti_usb_3410_5052 1-1.2.4.2:2.0: TI USB 3410 1 port adapter converter detected
[45895.685194] usb 1-1.2.4.2: TI USB 3410 1 port adapter converter now attached to ttyUSB0

M33P
Posts: 199
Joined: Sun Sep 02, 2012 1:14 pm

Re: USB/serial converters (not very) broken on Pi

Fri Mar 15, 2013 3:12 pm

Well this is new and interesting.

With the device plugged in, can you do sudo lsusb -v -d 06e0: and post the output

If you do a stty /dev/ttyUSB0 & , does the command prompt return? If it does, then try looking at what it's doing with top

jdubin
Posts: 12
Joined: Sun Jun 03, 2012 2:27 am

Re: USB/serial converters (not very) broken on Pi

Fri Mar 15, 2013 4:42 pm

Running stty -F /dev/ttyUSB0 gives me the following:

Code: Select all

[email protected]:~# stty -F /dev/ttyUSB0
speed 38400 baud; line = 0;
eof = ^A;
-brkint -icrnl -imaxbel
-isig -echo
[email protected]:~# stty -F /dev/ttyUSB0
stty: /dev/ttyUSB0: Input/output error
Out of, say, 35 times running stty like that, about 20 of them will reset the modem (which is what gives the I/O error) and generates messages in the log (like my first post, above). Same thing happens when I try to set the port speed (e.g. stty -F /dev/ttyUSB0 9600). Top shows udevd and khubd go towards the top of the list, but only with a percent or two of usage. Strangely, it hasn't locked up for me yet... I wonder if the patch has fixed that part?

FWIW, the modem works without a hitch on an x86 box running Centos 6, plus I've tried a second (identical) modem to be sure it wasn't a problem due to broken hardware.

Here's the output of lsusb:

Code: Select all

[email protected] ~ $ sudo lsusb -v -d 06e0:

Bus 001 Device 016: ID 06e0:0319 Multi-Tech Systems, Inc.
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            2 Communications
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         8
  idVendor           0x06e0 Multi-Tech Systems, Inc.
  idProduct          0x0319
  bcdDevice            1.01
  iManufacturer           1 Texas Instruments
  iProduct                2 TUSB3410 Serial Port
  iSerial                 0
  bNumConfigurations      2
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           39
    bNumInterfaces          1
    bConfigurationValue     2
    iConfiguration          0
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0
      bInterfaceProtocol      0
      iInterface              0
      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     0x01  EP 1 OUT
        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     0x83  EP 3 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0002  1x 2 bytes
        bInterval               1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           39
    bNumInterfaces          1
    bConfigurationValue     2
    iConfiguration          0
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0
      bInterfaceProtocol      0
      iInterface              0
      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     0x01  EP 1 OUT
        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     0x83  EP 3 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0002  1x 2 bytes
        bInterval               1
Device Status:     0x0001
  Self Powered
Thanks for taking the time to look at this!

M33P
Posts: 199
Joined: Sun Sep 02, 2012 1:14 pm

Re: USB/serial converters (not very) broken on Pi

Sat Mar 16, 2013 7:17 pm

The most recent USB fix prevents the Pi from locking up when accessing certain broken USB1.1 devices (commonly found to be oddball USB serial devices). The retry mechanism I implemented will try a max of 3 transactions before returning with an error.

Prior to an rpi-update, did the device ever give an I/O error without locking up?

Note that all of the devices that previously locked up a Pi would work OK on a PC.

obcd
Posts: 917
Joined: Sun Jul 29, 2012 9:06 pm

Re: USB/serial converters (not very) broken on Pi

Sun Mar 17, 2013 7:29 am

If the patch kicks in, does that mean that an usb packet gets lost or are the 3 retries taking care of that?
(I didn't had time to check it out yet)

M33P
Posts: 199
Joined: Sun Sep 02, 2012 1:14 pm

Re: USB/serial converters (not very) broken on Pi

Sun Mar 17, 2013 4:34 pm

The same transaction is retried so no packets should be dropped. The max error count for one transaction is 3 - a data toggle will almost always sort itself out after one retry.

jdubin
Posts: 12
Joined: Sun Jun 03, 2012 2:27 am

Re: USB/serial converters (not very) broken on Pi

Sun Mar 17, 2013 5:35 pm

Prior to an rpi-update, did the device ever give an I/O error without locking up?
The logs would show a USB disconnect, followed immediately by it finding it again. It might do this three or four times before the pi would lock up. See below for an example (from a log made before the updated kernel). I'm pretty sure this is when the faxaddmodem script was probing for the correct speed to talk to the serial port.

Code: Select all

Mar 11 16:50:56 localhost kernel: [  615.070241] usb 1-1.2.4.2: USB disconnect, device number 8
Mar 11 16:50:58 localhost kernel: [  617.606302] usb 1-1.2.4.2: new full-speed USB device number 9 using dwc_otg
Mar 11 16:50:58 localhost kernel: [  617.722508] usb 1-1.2.4.2: New USB device found, idVendor=06e0, idProduct=0319
Mar 11 16:50:58 localhost kernel: [  617.722543] usb 1-1.2.4.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Mar 11 16:50:58 localhost kernel: [  617.722559] usb 1-1.2.4.2: Product: TUSB3410 Serial Port
Mar 11 16:50:58 localhost kernel: [  617.722574] usb 1-1.2.4.2: Manufacturer: Texas Instruments
Mar 11 16:50:58 localhost kernel: [  617.725063] ti_usb_3410_5052 1-1.2.4.2:1.0: TI USB 3410 1 port adapter converter detected
Mar 11 16:50:59 localhost kernel: [  618.436454] usb 1-1.2.4.2: reset full-speed USB device number 9 using dwc_otg
Mar 11 16:50:59 localhost kernel: [  618.540118] usb 1-1.2.4.2: device firmware changed
Mar 11 16:50:59 localhost kernel: [  618.540592] ti_usb_3410_5052: probe of 1-1.2.4.2:1.0 failed with error -5
Mar 11 16:50:59 localhost kernel: [  618.547213] usb 1-1.2.4.2: USB disconnect, device number 9
Mar 11 16:50:59 localhost kernel: [  618.626365] usb 1-1.2.4.2: new full-speed USB device number 10 using dwc_otg
Mar 11 16:50:59 localhost kernel: [  618.764965] usb 1-1.2.4.2: New USB device found, idVendor=06e0, idProduct=0319
Mar 11 16:50:59 localhost kernel: [  618.764998] usb 1-1.2.4.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Mar 11 16:50:59 localhost kernel: [  618.765014] usb 1-1.2.4.2: Product: TUSB3410 Serial Port
Mar 11 16:50:59 localhost kernel: [  618.765027] usb 1-1.2.4.2: Manufacturer: Texas Instruments
Mar 11 16:50:59 localhost kernel: [  618.767279] ti_usb_3410_5052 1-1.2.4.2:1.0: TI USB 3410 1 port adapter converter detected
Mar 11 16:50:59 localhost kernel: [  618.767416] ti_usb_3410_5052: probe of 1-1.2.4.2:1.0 failed with error -5
Mar 11 16:50:59 localhost kernel: [  618.769637] ti_usb_3410_5052 1-1.2.4.2:2.0: TI USB 3410 1 port adapter converter detected
Mar 11 16:50:59 localhost kernel: [  618.770107] usb 1-1.2.4.2: TI USB 3410 1 port adapter converter now attached to ttyUSB0

dennyfmn
Posts: 27
Joined: Thu Aug 16, 2012 1:36 pm

Re: USB/serial converters (not very) broken on Pi

Mon Apr 22, 2013 12:51 pm

Future Technology Devices International, Ltd FT232 improved a little but not fixed.

Updated to latest kernel #414 from #371 with rpi-update. The operation of the Smarthome Insteon 2413U, USB PLM (Power Line Modem) with embedded Future Technology Devices International, Ltd FT232 USB-Serial (UART) has been improved but not fixed.

My looping test which toggles an Insteon ApplicanceLinc on/off every three seconds stalls in 2-3 hours but now just stalls the process. You can now ^C the process and return to the shell. With previous kernels, the whole machine would hang requiring a power down/up.

This is on a model B Pi with an 8 GB class 4 SD card. No overclocking or special entries in config.txt or cmdline.txt.

cmdline.txt:
dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait

I have not tried kernel #414 with dwc_otg.speed=1. For me this would not be a good workaround since it severely limits network performance.

The same 2413U USB PLM running on a Debian x86 host runs the looping script without hanging or stalling.

Interestingly enough, the combination of an Insteon serial PLM, model number 2413S, connected to either of my Prolific Technology Inc. pl2303 based USB to serial adapters, an old one and a new one, run without hanging. These tests were run on a different Raspberry Pi with kernel #250 back in November 2012.

If I can be of any help testing updates please let me know. It would be great to be able to use an 2413U Insteon USB PLM directly.

Return to “Troubleshooting”