From: Magnus L. <le...@gm...> - 2008-01-10 11:47:15
|
Hi all, On my system (Debian 4, kernel 2.6.23 and user-mode-linux_2.6.18-1um-2etch2 on a 386 machine), I run several virtual machines, each one using one or more serial ports (modems). If I include the "standard" serial ports, ttyS0 and ttyS1, on the linux commandline, the virtual machine starts up and the ports are accessible from inside as ttyS0 and ttyS1. However, I need more serial ports, so I have tested several devices such as the Digi Neo PCI card and the Edgeport USB-to-serial converter. Problem is, that these devices are not accessible from inside the virtual machine (but they work fine if accessed from the host system). Devices are owned by the user running the virtual machine. In the Digi Neo case, specifying port /dev/ttyn1a on the command line linux root=/dev/ubda ubd0=/umlroot/test.rootfs ubd1=/umlroot/test.swapfs eth0=tuntap,,,192.168.1.10 umid=test ssl0=tty:/dev/ttyn1a mem=256M con=pty con0=fd:0,fd:1 should make /dev/ttyn1a accessible as /dev/ttyS0 inside the virtual machine. Same thing for Edgeport, linux root=/dev/ubda ubd0=/umlroot/test.rootfs ubd1=/umlroot/test.swapfs eth0=tuntap,,,192.168.1.10 umid=test ssl0=tty:/dev/ttyUSB0 mem=256M con=pty con0=fd:0,fd:1 should make /dev/ttyUSB0 accessible as /dev/ttyS0. The only way I get this to work is by using the following ugly workaround on the host system before booting the virtual machines: for DEVICE in `ls -1 /dev/ttyUSB* /dev/ttyn1* ` do nohup /sbin/slattach -s 115200 $DEVICE & > /tmp/foo 2>&1 done sleep 10 ps -ef| grep slattach | grep -v grep | awk '{print $2}' | while read PID do echo "slattach PID is $PID , killing it" >> /tmp/foo 2>&1 kill $PID >> /tmp/foo 2>&1 done (slattach -e does not work, so for each device I start slattach in the background and then kill it). I have been testing several kernel and uml versions, without luck. Any help is greatly appreciated. /Magnus |
From: Jeff D. <jd...@ad...> - 2008-01-12 16:14:42
|
On Thu, Jan 10, 2008 at 12:47:12PM +0100, Magnus Legardt wrote: > The only way I get this to work is by using the following ugly workaround on > the host system before booting the virtual machines: How do you normally access them on the host, and what happens when you try the same thing inside the UML? Jeff -- Work email - jdike at linux dot intel dot com |
From: Magnus L. <le...@gm...> - 2008-01-12 17:43:31
|
On Jan 12, 2008 5:14 PM, Jeff Dike <jd...@ad...> wrote: > On Thu, Jan 10, 2008 at 12:47:12PM +0100, Magnus Legardt wrote: > > The only way I get this to work is by using the following ugly > workaround on > > the host system before booting the virtual machines: > > How do you normally access them on the host, and what happens when you > try the same thing inside the UML? Normally I access them using minicom or chat/ppp. I can type AT commands or set up a ppp connection. Using minicom inside UML (without workaround) just gives me a screen saying "Welcome to minicom etc. etc.", but no commands can be entered. In the chat case, same thing. No response to the AT command sent can be seen in the syslog. I made another interesting observation on one of my test systems. On this specific system, the only way to get things running was to start minicom outside and inside of the UML simultaneously. As soon as both minicom sessions come up, the modem responds from inside UML. I then exit from both sessions - and everything's fine... /Magnus |
From: Jeff D. <jd...@ad...> - 2008-01-14 15:16:23
|
On Sat, Jan 12, 2008 at 06:43:29PM +0100, Magnus Legardt wrote: > Using minicom inside UML (without workaround) just gives me a screen saying > "Welcome to minicom etc. etc.", but no commands can be entered. Run strace on minicom, on the host and on UML, and see what differences there are. In particular, see if ioctls are failing inside UML and succeeding on the host. Jeff -- Work email - jdike at linux dot intel dot com |
From: Magnus L. <le...@gm...> - 2008-01-23 10:20:14
|
Did that, but saw no differences in ioctl's, which led me to the conclusion that I hadn't done my setserials correctly... So I slapped myself in the face, did setserial on the host and in the UML, and now it works. Apparently setserial was not needed on ports /dev/ttyS0 and /dev/ttyS1, but indeed for the Digi serial port cards and USB-to-serial converters. Thanks for your help, Magnus On Jan 14, 2008 4:16 PM, Jeff Dike <jd...@ad...> wrote: > On Sat, Jan 12, 2008 at 06:43:29PM +0100, Magnus Legardt wrote: > > Using minicom inside UML (without workaround) just gives me a screen > saying > > "Welcome to minicom etc. etc.", but no commands can be entered. > > Run strace on minicom, on the host and on UML, and see what > differences there are. In particular, see if ioctls are failing > inside UML and succeeding on the host. > > Jeff > > -- > Work email - jdike at linux dot intel dot com > |