Greg, The serial adapter issue opened up again, so I thought I would let you know what's up. When I got the Belkin F5U109 working it was on a tower based on an Intel D854EBG2 motherboard (http://www.intel.com/design/motherbd/bg2/). The tower was never the target platform, I just used it thinking if the adapter worked on one it would work on the target platform.
I then changed platform to a Dell Inspiron 8100 (laptop). I tried the first serial serial device that has typically given the least trouble on other adapters -- it only produced gibberish. The second serial device that gives the most trouble worked like a champ, just as it did (sur- prisingly) on the tower. Here are the log messages I'm seeing when the adapter is connected to the 8100: Sep 26 09:37:59 Forsyth kernel: usb-uhci.c: USB UHCI at I/O 0xdce0, IRQ 10 Sep 26 09:37:59 Forsyth kernel: usb-uhci.c: Detected 2 ports Sep 26 09:37:59 Forsyth kernel: usb.c: new USB bus registered, assigned bus number 1 Sep 26 09:37:59 Forsyth kernel: hub.c: USB hub found Sep 26 09:37:59 Forsyth kernel: hub.c: 2 ports detected Sep 26 09:37:59 Forsyth kernel: usb-uhci.c: v1.275:USB Universal Host Controller Interface driver Sep 26 09:37:59 Forsyth kernel: hub.c: USB new device connect on bus1/1, assigned device number 2 Sep 26 09:37:59 Forsyth kernel: usb.c: USB device 2 (vend/prod 0x50d/0x109) is not claimed by any active driver. Sep 26 09:37:59 Forsyth kernel: usb.c: registered new driver serial Sep 26 09:37:59 Forsyth kernel: usbserial.c: USB Serial support registered for Generic Sep 26 09:37:59 Forsyth kernel: usbserial.c: USB Serial Driver core v1.4 Sep 26 09:37:59 Forsyth kernel: usbserial.c: USB Serial support registered for Magic Control Technology USB-RS232 Sep 26 09:37:59 Forsyth kernel: usbserial.c: Magic Control Technology USB-RS232 converter detected Sep 26 09:37:59 Forsyth kernel: usbserial.c: Magic Control Technology USB-RS232 converter now attached to ttyUSB0 (or usb/tts/0 for devfs) Sep 26 09:37:59 Forsyth kernel: usbserial.c: USB Serial support registered for MCT/Sitecom USB-RS232 Sep 26 09:37:59 Forsyth kernel: usbserial.c: USB Serial support registered for MCT/D-Link DU-H3SP USB BAY Sep 26 09:37:59 Forsyth kernel: mct_u232.c: v1.1:Magic Control Technology USB-RS232 converter driver The device giving the gibberish is a serial barcode reader. It turns out that if I can get one device working on the serial-to-USB adapter then the other can go on the serial port, so I'm not terribly stuck. I'm just curious why there was a problem. Another important fact to note 8100 laptop is not the target laptop. The target laptop is a Dell Latitude C840 -- I'm told by a fellow engineer that the hubs are the same -- I'm going to try a practical test to be sure. Therefore, can you think of any known problems that would explain why the serial barcode reader would produce gibberish (it looks just like what one would see if one did not have the data/stop/parity right)? Is there anything I can do to make this easier to diagnose (for your sake)? Regards, Joel Breazeale > Greg, > > It turns out "pilot-induced-turbulence" was the cause of the second > device not working. It's now working. It seems the Belkin F5U109 > will work for us in 2.4.18-3. I'll make sure the "powers-that-be" > undertand the kernel we are using needs updating. > > Regards, > Joel Breazeale > > > > On Tue, Sep 23, 2003 at 04:17:55PM -0500, Joel L. Breazeale wrote: > > > Greg, > > > > > > Thank you for your reply. It's also reassuring to know a bug was actually > > > found and *fixed*! 8-) > > > > > > I have some news. I tried a Belkin F5U109 and it worked, at least for the > > > one device I was trying to get working. I did not experience a dropped > > > character after 20 trials. Here what I'm seeing in /var/log/messages for > > > your information: > > > > Nice, looks good. > > > > > I have a follow-up I hope you can comment upon. Now that it seems the first > > > device works and doesn't drop characters, I have one other device that I'd > > > like to see if I can get working (but it's not crucial) with the same adapter. > > > I'm forced to use the adapter as the target laptop only has one serial port. > > > The second device works fine with /dev/ttyS0. Should the code that works with > > > the serial port be able to work unchanged with /dev/ttyUSB0? My guess is that > > > it should. The current code sets line speed (B19200) and mode (CS7 | CLOCAL | > > > CREAD | PARENB), all that serial stuff you would expect; may I presume the com- > > > bination of serial-to-USB adapter and driver should cause the adapter to be re- > > > configured to use the correct serial settings? > > > > Yes, it should all "just work". Just point your program to > > /dev/ttyUSB0. > > > > > If all of this is true then it's curious that this just doesn't work. > > > Perhaps I've found a problem. I would be glad to pursue it if it > > > would ultimately help to shore up a bug. If you can give me any > > > pointers on proceeding on debugging this situation I would be glad to > > > try. It might be useful to know the devide in question only trans- > > > mits data. > > > > What is not working? Some usb-serial drivers do not handle all of the > > different serial ioctls (don't know about this driver, as I didn't write > > it.) For example, the "setserial" program will not work on most > > usb-serial drivers (the io_edgeport and io_ti drivers being the > > exception). > > > > thanks, > > > > greg k-h > > > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
