Edgeport 416 failure during open under Linux

I’ve got two Edgeport 416/DB9 units here that “almost” work.

When plugged into my Linux machine (2.6.31), they appear to properly register
with the kernel:

usb 8-1.3.5: new full speed USB device using uhci_hcd and address 36
usb 8-1.3.5: New USB device found, idVendor=1608, idProduct=0012
usb 8-1.3.5: New USB device strings: Mfr=1, Product=2, SerialNumber=5
usb 8-1.3.5: Product: Edgeport/416
usb 8-1.3.5: Manufacturer: Inside Out Networks
usb 8-1.3.5: SerialNumber: V63177617-0
usb 8-1.3.5: configuration #1 chosen from 1 choice
io_edgeport 8-1.3.5:1.0: Edgeport 8 port adapter converter detected
usb 8-1.3.5: Inside Out Networks Edgeport/416 detected
usb 8-1.3.5: firmware: requesting edgeport/down.fw
usb 8-1.3.5: firmware: requesting edgeport/boot.fw
usb 8-1.3.5: Edgeport 8 port adapter converter now attached to ttyUSB16
usb 8-1.3.5: Edgeport 8 port adapter converter now attached to ttyUSB17
usb 8-1.3.5: Edgeport 8 port adapter converter now attached to ttyUSB18
usb 8-1.3.5: Edgeport 8 port adapter converter now attached to ttyUSB19
usb 8-1.3.5: Edgeport 8 port adapter converter now attached to ttyUSB20
usb 8-1.3.5: Edgeport 8 port adapter converter now attached to ttyUSB21
usb 8-1.3.5: Edgeport 8 port adapter converter now attached to ttyUSB22
usb 8-1.3.5: Edgeport 8 port adapter converter now attached to ttyUSB23
usb 8-1.3.6: new full speed USB device using uhci_hcd and address 37
usb 8-1.3.6: New USB device found, idVendor=1608, idProduct=0012
usb 8-1.3.6: New USB device strings: Mfr=1, Product=2, SerialNumber=5
usb 8-1.3.6: Product: Edgeport/416
usb 8-1.3.6: Manufacturer: Inside Out Networks
usb 8-1.3.6: SerialNumber: V63177617-1
usb 8-1.3.6: configuration #1 chosen from 1 choice
io_edgeport 8-1.3.6:1.0: Edgeport 8 port adapter converter detected
usb 8-1.3.6: Inside Out Networks Edgeport/416 detected
usb 8-1.3.6: firmware: requesting edgeport/down.fw
usb 8-1.3.6: firmware: requesting edgeport/boot.fw
usb 8-1.3.6: Edgeport 8 port adapter converter now attached to ttyUSB24
usb 8-1.3.6: Edgeport 8 port adapter converter now attached to ttyUSB25
usb 8-1.3.6: Edgeport 8 port adapter converter now attached to ttyUSB26
usb 8-1.3.6: Edgeport 8 port adapter converter now attached to ttyUSB27
usb 8-1.3.6: Edgeport 8 port adapter converter now attached to ttyUSB28
usb 8-1.3.6: Edgeport 8 port adapter converter now attached to ttyUSB29
usb 8-1.3.6: Edgeport 8 port adapter converter now attached to ttyUSB30
usb 8-1.3.6: Edgeport 8 port adapter converter now attached to ttyUSB31

However, any attempt to open one of the ports causes a timeout, and an error
from the open call.

Both units are P/N 50000780-01 E

The LED behavior of these units might also be of interest:
When the unit is powered on, but not connected via USB, both LEDs flash red quickly.
Once connected via USB, the LEDs flash green slowly.
As soon as an attempt to open a port fails, the LED for that group of 8 ports
stops flashing (stays off).

The same kernel and drivers work fine for an Edgeport 416 DB-25 (50000781-01 A),
and also an Edgeport 412 (50000778-01 B).

Any insight would be appreciated.

I think we should try to rule out bad hardware, as both of those Edgeports are older, based on the chipset, which is based on the 50xxxxxx part numbers.

Please connect them to a Windows-based computer (preferrably Windows XP, but Vista, Windows 7, Server 2003 and Server 2008 are also supported) and install them using the latest Edgeport driver for Windows:

http://ftp1.digi.com/support/driver/40002537_H.zip

Just extract the zip file, connect the Edgeports to the computer, then point the found new hardware wizards to the location of the extracted zip file. Since these are multi-port units, you may have to go through lots of Wizards, especially since you have two units. Watch Windows Device Manager and be sure to keep updating the driver until all Edgeport-related components with yellow warning icons get corrected.

At that point, the System Status LEDs on both units should be blinking green slowly, meaning that the driver is loaded and the units are idle.

Now run the Edgeport Configuration Utility from the start menu, in the Digi USB folder. Select one of the units, click Test Ports, then click Begin Test. Do the ports pass or fail? Run that test a few times to see if the results are consistent. Then test the other Edgeport the same way. What are the results?

Hi Jeremy,

Thanks for the reply.

I use Linux as my main OS, so my access to Windows is limited.

However, I do keep a single crusty old Windows machine (Win2K) around to deal with
these kinds of situations, so I fired it up and connected one of the Edgeports.

The machine recognized that an Edgeport was plugged in, and asked to install a driver.
I pointed it at the driver you provided, but it wasn’t happy (claimed it could not locate a
driver for the device in that directory). This is not much of a surprise, given that you
didn’t list W2K as being supported.

Short of updating the version of Windows on that machine, it there anything else
I can try?

You’ll need to use an older Edgeport driver for Windows 2000:

http://ftp1.digi.com/support/driver/40002537_F.zip

That helped.

The W2K machine found only half of the first edgeport (the P1-8 LED went
slow flashing green, but the P9-16 LED stayed fast flashing red).

I plugged in the second edgeport, and both P1-8, and P9-16 flashed slow green.

For both units, I ran the internal loopback test on all available ports (only 8 on the first
unit, all 16 on the second unit). As you suggested, I ran the tests multiple times. The
tests passed in all cases.

Regarding the first unit, try unplugging/replugging the USB cable then clicking the Refresh button in the Edgeport Configuration Utility. Does that get the other eight ports to show up?

I tried unplugging/replugging and hitting refresh, but it didn’t help.

That behavior does not bother me much, as Linux was happy to see all 16 ports
of both units.

If it helps, we can restrict our conversation to the one unit that worked 100% under
W2K.

Have you applied the latest linux-usb patches for your 2.6.31 kernel?

I seem to recall an issue that was fixed somewhere around version 2.6.34.

The 2.6.31 kernel is unpatched.

I just downloaded 2.6.37 and compared the io_edgeport driver source. I see some
minor changes, but not much that might explain this issue.

If needed, I can rebuild the kernel for that machine. If we really suspect the kernel,
I’ll go down that path. However, I’m a little skeptical as that kernel is successfully
working with the other two EdgePorts mentioned above.

That was my first thought. However, if the hardware works in a different platform, it would suggest the issue is with the driver/firmware in Linux.

What are you using to open the ports in Linux?

What is the exact (timeout) error seen?

Before attempting to open the ports, are you able to issue stty against the ports and see the settings?

The failure is in the Unix open call. I can make it happen using anything that
tries to open the device.

For example:

strace cat /dev/ttyUSB16

yields:

open(“/dev/ttyUSB16”, O_RDONLY|O_LARGEFILE) = -1 ENODEV (No such device)

Before posting here, I played around a bit with the driver, and traced it back
to a failure in the “edge_open” function of the io_edgeport driver:

wait_event_timeout(edge_port->wait_open, !edge_port->openPending,
OPEN_TIMEOUT);

the wait is timing out… When it does, it returns ENODEV.

I can debug this further, but I figured that since I’ve seen the behavior from two
different devices, it was probably something that was already known.

Oops. I overlooked your final question about being able to use stty.

The answer is no. stty tries to “open” the device before it can query it. The open fails
with ENODEV.

At this point, all I can think of is trying the new kernel/patches to see if it addresses this as I have not heard of this behavior.

Very good. I’ll update the kernel when I get a chance, although it might be the
weekend before I have enough time.

BTW: the symptoms I’m having sound very much like the ones described here:
http://forums.digi.com/support/forum/viewthread_thread,4977#15792
(in cantus’ second post where the behavior of the “New” Edgeports is described)

Unfortunately, I don’t think they ever got to the bottom of that issue.

I’ll post here again after updating the kernel.

To my knowledge both the working and non-working units both have the same chipset. Jeremym should be able to confirm this.

The two 50000780-01 E units are older 930 chipset variants that use the io_edgeport driver.

About the other two Edgeports that work fine:

Edgeport 416 DB-25 (50000781-01 A) - this is also a 930-based unit.

Edgeport 412 (50000778-01 B) - I’m not sure which chipset that is. I can help investigate this if needed.

I found some time today to build the 2.6.37 kernel for another machine I have
here. The machine behaves identically to the 2.6.31 machine I was testing with
previously (works with the 412, the 416-DB25, but times out during open with the
416-DB9 devices).

Hello everyone,

I have the exact same behavior as squirest explains here in this thread on Post Count: 9.

Does anyone have a solution for this? We would really love to fix the Edgeport/416 for our CentOS 6 machine under kernel 2.6.32-279.14.1.el6.i686.

Many thanks,

David

Hi there,

We’ve got three (for us new in box) Edgeport/416’s with apparently the same 930 chipset… And exactly the issues described here and elsewhere on this forum.

Did anyone succeed in getting their Edgeport/416 up and running in Linux? We tried with a 3.16 series kernel, but it fails like above: all the /dev/ttyUSB ports are being created, but when opening the device it fails (and the leds stop blinking). Box seems to work on Windows, as does the self test when executed there.

Could it be something firmware related? I notice the ‘down’ and ‘boot’ files in the kernel tree haven’t been touched since 2008; couldn’t we pick these from the Windows driver? Or am I now looking for a solution in the wrong place :slight_smile: