# Keyspan USB to serial port converter

## TomorrowPlusX

Back when I was running slackware, I could use my keyspan usb->seral converter (nice box, gives me 4 serial ports on one usb; I need it for robotics research/work I'm doing) simply by including usb serial port support and the keyspan drivers in the kernel configuration.

To access the serial ports, I just opened /dev/ttyUSB[0,1,2,3]

Now, under gentoo, with devfs, I would expect to find /dev/usb/tts/[0,1,2,3] -- but no luck. Now, I did select USB support, USB serial support, and the specific keyspan driver for my kernel; I tried compiling it in the kernel & as modules, for the latter I put usb-uhci, usbserial & keyspan into my modules.autoload -- running lsmod:

Module                  Size  Used by    Not tainted

mousedev                3872   0  (unused)

keyspan                26948   0  (unused)

usbserial              17344   0  [keyspan]

usb-storage            20764   0  (unused)

hid                    19072   0  (unused)

usb-uhci               21860   0  (unused)

snd-pcm-oss            35428   0  (unused)

snd-mixer-oss           9344   1  [snd-pcm-oss]

snd-cs46xx             69764   3

snd-rawmidi            13088   0  [snd-cs46xx]

snd-seq-device          3808   0  [snd-rawmidi]

snd-pcm                50624   2  [snd-pcm-oss snd-cs46xx]

snd-timer              10944   0  [snd-pcm]

snd-ac97-codec         23588   0  [snd-cs46xx]

snd                    26248   0  [snd-pcm-oss snd-mixer-oss snd-cs46xx snd-rawmidi snd-seq-device snd-pcm snd-timer snd-ac97-codec]

usbcore                62944   1  [keyspan usbserial usb-storage hid usb-uhci]

But no matter what, I just can't access my damned serial ports... this is kind of make or break for me & gentoo. If I can't talk to my robotics hardware (custom stuff, lots of fun) I've got to go back to slack... :(

So, please... *please* does anybody have any suggestions?

For reference, I *have* searched -- and I gave a shot with hotplug but all it did was hang. It seemed to crash on shutdown, and provide absolutely nothing while actually running.

----------

## delta407

What does "dmesg | grep usb" say? Also, what is the contents of /dev/usb/?

----------

## TomorrowPlusX

The output of 

#dmesg | grep usb

usb.c: registered new driver usbdevfs

usb.c: registered new driver hub

usb-uhci.c: $Revision: 1.275 $ time 00:04:39 Jul  5 2002

usb-uhci.c: High bandwidth mode enabled

usb-uhci.c: USB UHCI at I/O 0x1c20, IRQ 11

usb-uhci.c: Detected 2 ports

usb.c: new USB bus registered, assigned bus number 1

usb.c: kmalloc IF d3374420, numif 1

usb.c: new device strings: Mfr=0, Product=2, SerialNumber=1

usb.c: USB device number 1 default language ID 0x0

usb.c: hub driver claimed interface d3374420

usb.c: kusbd: /sbin/hotplug add 1

usb-uhci.c: v1.275:USB Universal Host Controller Interface driver

usb.c: registered new driver hiddev

usb.c: registered new driver hid

usb.c: registered new driver usb-storage

usb.c: registered new driver serial

usbserial.c: USB Serial Driver core v1.4

usbserial.c: USB Serial support registered for Keyspan USA18X - (without firmware)

usbserial.c: USB Serial support registered for Keyspan USA19 - (without firmware)

usbserial.c: USB Serial support registered for Keyspan USA19W - (without firmware)

usbserial.c: USB Serial support registered for Keyspan USA28 - (without firmware)

usbserial.c: USB Serial support registered for Keyspan USA28X - (without firmware)

usbserial.c: USB Serial support registered for Keyspan USA28XA - (without firmware)

usbserial.c: USB Serial support registered for Keyspan USA28XB - (without firmware)

usbserial.c: USB Serial support registered for Keyspan USA49W - (without firmware)

usbserial.c: USB Serial support registered for Keyspan USA18X

usbserial.c: USB Serial support registered for Keyspan USA19

usbserial.c: USB Serial support registered for Keyspan USA19W

usbserial.c: USB Serial support registered for Keyspan USA28

usbserial.c: USB Serial support registered for Keyspan USA28X/XB

usbserial.c: USB Serial support registered for Keyspan USA28XA

usbserial.c: USB Serial support registered for Keyspan USA49W

usb.c: kmalloc IF cda358c0, numif 1

usb.c: new device strings: Mfr=0, Product=0, SerialNumber=0

usbserial.c: Keyspan USA49W - (without firmware) converter detected

usb.c: serial driver claimed interface cda358c0

usb.c: kusbd: /sbin/hotplug add 2

usb.c: USB disconnect on device 2

usb-uhci.c: interrupt, status 2, frame# 502

usbdevfs: USBDEVFS_CONTROL failed dev 2 rqt 128 rq 6 len 18 ret -84

usbdevfs: USBDEVFS_CONTROL failed dev 2 rqt 128 rq 6 len 18 ret -84

usbdevfs: USBDEVFS_CONTROL failed dev 2 rqt 128 rq 6 len 18 ret -84

--

And the only entry in /dev/usb is 'hid', but there's nothing in there (I'm using a thinkpad with touchpoint ('nipple')), I compiled in HID just because I figured I might use a usb mouse eventually.

----------

## delta407

You might consider putting that in a [ code ] block, but anyway...

Here's what I see in that:

```
usb.c: hub driver claimed interface d3374420

usbserial.c: Keyspan USA49W - (without firmware) converter detected

usb.c: serial driver claimed interface cda358c0
```

Okay, so the USB hub (built in) is device 1, and the serial thing is device 2. We're good so far; I wanted to see if your serial thingy was being talked to by the driver.

```
usb.c: USB disconnect on device 2
```

 :Exclamation:  That's probably your problem. Is there anything in the surrounding area? (dmesg | less)

```
usbdevfs: USBDEVFS_CONTROL failed dev 2 rqt 128 rq 6 len 18 ret -84

usbdevfs: USBDEVFS_CONTROL failed dev 2 rqt 128 rq 6 len 18 ret -84

usbdevfs: USBDEVFS_CONTROL failed dev 2 rqt 128 rq 6 len 18 ret -84
```

Right, because it got a disconnect signal.

Try booting your computer with it unplugged, and then do this:

```
# killall -USR1 metalog  (only do this if you run metalog)

# tail -n 0 -f /var/log/kernel/current
```

Plug your device in, and you should see kernel messages in real-time as they are generated.

----------

## TomorrowPlusX

Sorry about the code formatting -- I don't know if anybody else has this trouble, but the formatting buttons don't seem to do a damn thing in konq ;) 

I'm guessing the formatting is open-bracket code close-bracket yadda yadda.

```

rial.c: USB Serial support registered for Keyspan USA49W

Jul  9 00:25:29 [kernel] keyspan.c: v1.1.1:Keyspan USB to Serial Converter Driver

Jul  9 00:28:11 [kernel] eth0: MII link partner: 45e1

Jul  9 00:28:11 [kernel] eth0: media 100BaseT, silicon revision 4

Jul  9 00:29:16 [kernel] hub.c: port 1, portstatus 101, change 1, 12 Mb/s

Jul  9 00:29:16 [kernel] hub.c: port 1, portstatus 101, change 0, 12 Mb/s

Jul  9 00:29:16 [kernel] hub.c: port 1, portstatus 101, change 0, 12 Mb/s

Jul  9 00:29:16 [kernel] hub.c: port 1, portstatus 101, change 0, 12 Mb/s

Jul  9 00:29:16 [kernel] hub.c: port 1, portstatus 101, change 0, 12 Mb/s

Jul  9 00:29:16 [kernel] hub.c: port 1, portstatus 103, change 0, 12 Mb/s

Jul  9 00:29:16 [kernel] usb.c: kmalloc IF cc538be0, numif 1

Jul  9 00:29:16 [kernel] usb.c: new device strings: Mfr=0, Product=0, SerialNumber=0

Jul  9 00:29:17 [kernel] usb.c: serial driver claimed interface cc538be0

Jul  9 00:29:17 [kernel] hub.c: port 2, portstatus 100, change 0, 12 Mb/s

Jul  9 00:29:20 [kernel] usb-uhci.c: interrupt, status 2, frame# 538

Jul  9 00:29:20 [kernel] usbdevfs: USBDEVFS_CONTROL failed dev 2 rqt 128 rq 6 len 18 ret -84

Jul  9 00:29:20 [kernel] usbdevfs: USBDEVFS_CONTROL failed dev 2 rqt 128 rq 6 len 18 ret -84

Jul  9 00:29:20 [kernel] usbdevfs: USBDEVFS_CONTROL failed dev 2 rqt 128 rq 6 len 18 ret -84

```

Note: the first line, "rial.c ..." -- that's how it showed up... not a cut-n-paste error.

I've gathered, from troubles I had with my atapi zip drive (which worked under slackware), that not all linux drivers have been ported to devfs.

I'd be more than willing to migrate my machine to a static dev/ directory if you think that might fix this. Frankly, as nice as devfs is, it loses its luster for me if half my hardware doesn't work under it!

----------

## TomorrowPlusX

I noticed that there are *two* usb-uhci drivers, I picked the first one, do you think I should try the "JE" version?

----------

## delta407

Correct, a handful of drivers don't play nicely with devfs. You don't have to use it (though it's recommended); just add "gentoo=nodevfs" to your kernel options and mknod as necessary.

----------

## TomorrowPlusX

Is there a mknod script which will fully populate a /dev directory? I'll be honest -- I'm not looking forward to manually looking up the device ids for dozens/hundreds/thousands of nodes ;)

Otherwise, would it be "safe" to simply "cp -a" the /dev directory from my slack install? 

Of course, I'd rather fix the problem, than avoid the symptoms.

----------

## delta407

"cp -a" should do it, or you could use some special tar options (which I don't recall, p?).

----------

## TomorrowPlusX

Well it looks like I'm going to have to try not using devfs. However, my concern is, well, how.

What's a good approach? 

My guess, off the top of my head, would be to save my current /dev directory (perhaps tar it up, or just cp -a it somehwere else like /devfs, and then copy over the /dev directory from slack, then reboot with the nodevfs option.

Does this sound safe? Of course, I'll back up my data beforehand. I always do ;)

Oh, one more thing, if this works, I owe you a pizza. I just don't know enough about problem solving under linux.

----------

## delta407

 *TomorrowPlusX wrote:*   

> Does this sound safe? Of course, I'll back up my data beforehand. I always do 

 

You don't really need to back it up, though; you have a minimal /dev directory that is hidden when devfs is enabled. You should be able to boot up normally with the nodevfs option without doing anything else.

Anyway, try this under Slack:

```
# tar czpvf slack-dev-entries.tar.gz /dev/
```

That should produce a tarball of your /dev directory, and it should be small enough to fit onto a floppy. Get that tarball into Gentoo somehow (floppy, CD, e-mail it to yourself, whatever), boot up with the nodevfs option, and do this:

```
# cd /

# mv dev dev.old

# tar xzpvf /path/to/slack-dev-entries.tar.gz
```

That will move your current /dev (the one that ships with Gentoo despite devfs) to /dev.old and reproduce your Slackware /dev tree, including your USB stuff, onto your Gentoo box.

----------

## TomorrowPlusX

Hey, I just wanted to say that I got it working! In the end, after mucking about with non-devfs, various kernel configs, etc etc etc until I wanted to vomit with rage, I got it working using... my vanilla 2.4.17 kernel from my old slack box. It even works with devfs, so basically, it was nothing but a kernel issue.

That's it. I don't know if 2.4.19 introduced a usbserial bug, or if it's a compatibility issue with all the patches in the gentoo kernel, but the fact is, it doesn't work with the gentoo kernel. I'll try out a vanilla 2.4.19 jus to see. Depending on the outcome I'll submit a bug report to gentoo or (I guess) kernel.org.

The great part, though, is that it even works with hotplug! So while I had to reboot my system under slack to get the serial adaper, now I just plug it in. Haha!

----------

## delta407

 *TomorrowPlusX wrote:*   

> I'll try out a vanilla 2.4.19 jus to see.

 

Well, that is, once 2.4.19 is released.  :Wink: 

Glad to hear it's workin'.

----------

## TomorrowPlusX

Touche`

Well, anyway -- thanks for the help! While what we discussed didn't directly solve the problem, it led me down a path which eventually *did* solve it. So yes, thanks!

----------

## gvs

http://www.pdaexpertos.com/Tutoriales/Linux/Palm_y_Linux.shtml

 *Quote:*   

>  # mknod /dev/ttyUSB0 c 188 0
> 
> # mknod /dev/ttyUSB1 c 188 1
> 
> # chmod 666 /dev/ttyUSB*

 

----------

