Hi all,
Background: I'm trying to debug a Xen setup and the hypervisor outputs its info via the com port.
This seems like it should be a cakewalk but I've been fighting this for almost a week now.
All I'm trying to do is dump output from one com port on one machine to the com port on a different machine.
I've tried simple cat a file to one com port and cat the other. I've tried minicom ctrl-A S and ctrl-A R with zmodem in both directions for days without any success.
Yesterday I installed putty and selecting "serial" gets me nowhere, so for spits and giggles I chose "ssh" and entered the hostname of the target machine. It asked for my login name, presented my key and, voilá, I'm logged into the remote machine.
That step alone verifies that com port hardware, flow rates and handshakes, and null modem cable all work.
Does anybody else have any clues here; I obviously don't :/
Thanks for any and all help, Mike Wright
On 06/24/2011 03:10 PM, Mike Wright wrote:
Hi all,
Background: I'm trying to debug a Xen setup and the hypervisor outputs its info via the com port.
This seems like it should be a cakewalk but I've been fighting this for almost a week now.
All I'm trying to do is dump output from one com port on one machine to the com port on a different machine.
I've tried simple cat a file to one com port and cat the other. I've tried minicom ctrl-A S and ctrl-A R with zmodem in both directions for days without any success.
zmodem is used to move files, not for normal, interactive communication. You can think of zmodem sort of like FTP.
Yesterday I installed putty and selecting "serial" gets me nowhere, so for spits and giggles I chose "ssh" and entered the hostname of the target machine. It asked for my login name, presented my key and, voilá, I'm logged into the remote machine.
That step alone verifies that com port hardware, flow rates and handshakes, and null modem cable all work.
Does anybody else have any clues here; I obviously don't :/
If you're simply trying to capture the output of the Xen hypervisor on machine A to machine B via a serial port, then:
1. On A, make sure you have these things set up in the "kernel" line of the grub stanza used to boot the Xen kernel:
com1=38400,8n1 console=com1
2. On B, use minicom to set the baud rate and format for its serial port to 38400 baud, 8 data bits, 1 stop bit, no parity and no flow control). If you don't know how to do this, first run minicom in setup mode:
$ minicom -s
2a. Use the down arrow to highlight "Serial port setup" and press ENTER. This puts you in the serial port setup screen.
2b. In the serial port setup screen, press "A" and change the port to /dev/ttyS0, then press ENTER.
2c. Press "E" and you'll be in the serial parameters screen.
2d. In the serial parameters screen, press "D" to select 38400 baud, then press "Q" to select 8N1. Finally, press ENTER to exit the serial parameters screen and return to the serial port setup screen.
2e. Back in the serial port setup screen, press ENTER to exit the screen.
2f. Back at the configuration screen, use the down arrow to highlight "Exit" and press ENTER. You're now in the terminal I/O part of minicom.
3. Reboot A and make it come up in Xen.
At this point, anything sent to A's serial port should show up on the screen on B.
To exit minicom, use CTRL-A, Q and select "Yes". ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, C2 Hosting ricks@nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - A day for firm decisions!!! Well, then again, maybe not! - ----------------------------------------------------------------------
On 06/24/2011 03:56 PM, Rick Stevens wrote:
On 06/24/2011 03:10 PM, Mike Wright wrote:
Hi all,
Background: I'm trying to debug a Xen setup and the hypervisor outputs its info via the com port.
This seems like it should be a cakewalk but I've been fighting this for almost a week now.
All I'm trying to do is dump output from one com port on one machine to the com port on a different machine.
I've tried simple cat a file to one com port and cat the other. I've tried minicom ctrl-A S and ctrl-A R with zmodem in both directions for days without any success.
Hi Rick. You're ever helpful.
zmodem is used to move files, not for normal, interactive communication. You can think of zmodem sort of like FTP.
Yeah, I was using a 10k text file filled with random ascii chars.
Yesterday I installed putty and selecting "serial" gets me nowhere, so for spits and giggles I chose "ssh" and entered the hostname of the target machine. It asked for my login name, presented my key and, voilá, I'm logged into the remote machine.
That step alone verifies that com port hardware, flow rates and handshakes, and null modem cable all work.
Does anybody else have any clues here; I obviously don't :/
If you're simply trying to capture the output of the Xen hypervisor on machine A to machine B via a serial port, then:
- On A, make sure you have these things set up in the "kernel" line of
the grub stanza used to boot the Xen kernel:
com1=38400,8n1 console=com1
- On B, use minicom to set the baud rate and format for its serial port
to 38400 baud, 8 data bits, 1 stop bit, no parity and no flow control). If you don't know how to do this, first run minicom in setup mode:
$ minicom -s
2a. Use the down arrow to highlight "Serial port setup" and press ENTER. This puts you in the serial port setup screen.
2b. In the serial port setup screen, press "A" and change the port to /dev/ttyS0, then press ENTER.
2c. Press "E" and you'll be in the serial parameters screen.
2d. In the serial parameters screen, press "D" to select 38400 baud, then press "Q" to select 8N1. Finally, press ENTER to exit the serial parameters screen and return to the serial port setup screen.
2e. Back in the serial port setup screen, press ENTER to exit the screen.
2f. Back at the configuration screen, use the down arrow to highlight "Exit" and press ENTER. You're now in the terminal I/O part of minicom.
- Reboot A and make it come up in Xen.
At this point, anything sent to A's serial port should show up on the screen on B.
And not a peep.
I really appreciate your help, Rick. This is especially frustrating because I used to hack uarts in machine code, and before that using timing loops and shift flags in the cpu, so I could talk to teletypes.
Wonder if there is something with my Gigabyte motherboard that's interfering with the Xen code. I've seen something about their mobo's not honoring C1, C2 in the ACPI? code.
Time to move on. There are other fish to fry ;D
To exit minicom, use CTRL-A, Q and select "Yes".
- Rick Stevens, Systems Engineer, C2 Hosting ricks@nerd.com -
- AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
-
A day for firm decisions!!! Well, then again, maybe not! -
Mike Wright writes:
Yesterday I installed putty and selecting "serial" gets me nowhere, so for spits and giggles I chose "ssh" and entered the hostname of the target machine. It asked for my login name, presented my key and, voilá, I'm logged into the remote machine.
That step alone verifies that com port hardware, flow rates and handshakes, and null modem cable all work.
I dont't see how it does. ssh doesn't know anything about serial ports, AFAIK. Furthermore, I'm unable to figure out how ssh, or anything else, would have the knowledge to map some arbitrary hostname to a specific serial port on my machine.
More than likely, ssh connected to your machine via TCP/IP, thus proving nothing.
Does anybody else have any clues here; I obviously don't :/
This should not be a difficult problem to solve.
1) Verify that you have both serial ports wired correctly. Presumably, you have a "null modem" adapter wired in, to cross the appropriate pins. I used to do serial port hacking, and I used to remember all the pinouts by heart. Don't remember them anymore, but I still remember the logical names.
2) Run minicom on both machines, set them to to the same speed/parity/stop settings, but turn off flow control, and turn off echo. Use 9600bps, it's a reliable failsafe. It's possible that older hardware may not support higher speeds. It's possible that your null-modem adaptor does not cross the RTS/CTS and DTR/DSR pins, so hardware flow control will not work. If they're set to the same speed, anything you type on one machine, in minicom, should show up in the other one's screen, and vice versa.
3) If you're not getting any response from minicom, and you have them at the same speed/parity/stop setting, and no flow contorl, there could only be two reasons for that:
A) Your null-modem adapter is not a null-modem adapter.
B) One or the other minicom opened the wrong serial port device. If your machine has two serial ports, it's a trial and error which one is ttyS0, and which one is ttyS1. Even if your server has one serial port visible, it's entirely possible that your motherboard's chipset actually has two UARTs, but only one of them is wired to an actual serial port, so even if you have only one serial port sticking out, it may very well be ttyS1, rather than ttyS0.
Well, you also mentioned Xen, and if one of your machines is a virtual machine, it's possible that Xen is not connecting your VM's logical serial port to your actual hardware serial port. I don't know much about Xen, so you'll need to try to dig through its documentation to see if it says anything about supporting serial ports.
If in doubt, get rid of Xen temporarily, and run minicom natively on both hosts, and get them talking to each other. Once you've proven that you have the serial ports wired correctly, then bring Xen into the picture, and try to get it working with Xen.
On 06/24/2011 05:13 PM, Sam Varshavchik wrote:
Mike Wright writes:
Yesterday I installed putty and selecting "serial" gets me nowhere, so for spits and giggles I chose "ssh" and entered the hostname of the target machine. It asked for my login name, presented my key and, voilá, I'm logged into the remote machine.
That step alone verifies that com port hardware, flow rates and handshakes, and null modem cable all work.
I dont't see how it does. ssh doesn't know anything about serial ports, AFAIK. Furthermore, I'm unable to figure out how ssh, or anything else, would have the knowledge to map some arbitrary hostname to a specific serial port on my machine.
Thanks for your help, Sam. (I remember you from way back on my days on the qmail and inter7 lists).
After a week at this my head is scrambled. I misunderstood and thought putty was another serial application and all the other stuff went over that. Jeez. Where was my head. TCP has ports, not serial.
More than likely, ssh connected to your machine via TCP/IP, thus proving nothing.
I repeat the following line. Hit me with a clueX4.
Does anybody else have any clues here; I obviously don't :/
This should not be a difficult problem to solve.
- Verify that you have both serial ports wired correctly. Presumably,
you have a "null modem" adapter wired in, to cross the appropriate pins. I used to do serial port hacking, and I used to remember all the pinouts by heart. Don't remember them anymore, but I still remember the logical names.
- Run minicom on both machines, set them to to the same
speed/parity/stop settings, but turn off flow control, and turn off echo. Use 9600bps, it's a reliable failsafe. It's possible that older hardware may not support higher speeds. It's possible that your null-modem adaptor does not cross the RTS/CTS and DTR/DSR pins, so hardware flow control will not work. If they're set to the same speed, anything you type on one machine, in minicom, should show up in the other one's screen, and vice versa.
- If you're not getting any response from minicom, and you have them at
the same speed/parity/stop setting, and no flow contorl, there could only be two reasons for that:
A) Your null-modem adapter is not a null-modem adapter.
B) One or the other minicom opened the wrong serial port device. If your machine has two serial ports, it's a trial and error which one is ttyS0, and which one is ttyS1. Even if your server has one serial port visible, it's entirely possible that your motherboard's chipset actually has two UARTs, but only one of them is wired to an actual serial port, so even if you have only one serial port sticking out, it may very well be ttyS1, rather than ttyS0.
After much mucking about I got one machine to echo gibberish to the other, even though both have the same settings. One echoes even though echo is set to off.
Sunday I'll go buy two connectors and wire my own 3-wire null modem cable: ground, tx, rx. I'm tending to agree with you that something in the cable chain is messed up. The motherboard has a header to com adapter that could also be a source of trouble.
Thanks again.
Well, you also mentioned Xen, and if one of your machines is a virtual machine, it's possible that Xen is not connecting your VM's logical serial port to your actual hardware serial port. I don't know much about Xen, so you'll need to try to dig through its documentation to see if it says anything about supporting serial ports.
Xen domain0. No virtuals
If in doubt, get rid of Xen temporarily, and run minicom natively on both hosts, and get them talking to each other. Once you've proven that you have the serial ports wired correctly, then bring Xen into the picture, and try to get it working with Xen.
Mike Wright writes:
Sunday I'll go buy two connectors and wire my own 3-wire null modem cable: ground, tx, rx.
With that, you have to turn hardware flow control off.
I would also recomment crossing DTR with DSR and CTS, to get hardware flow control.
I'm tending to agree with you that something in
the cable chain is messed up.
A gender-changer is NOT the same thing as a null-modem adapter. That's the most common oversight. If you have something in there that swaps the genders around, it might be just a straight-through gender-changer. In addition to changing genders, the right pins need to be crossed, that's what a null- modem adapter does.
On Fri, Jun 24, 2011 at 7:05 PM, Sam Varshavchik mrsam@courier-mta.com wrote:
Mike Wright writes:
Sunday I'll go buy two connectors and wire my own 3-wire null modem cable: ground, tx, rx.
With that, you have to turn hardware flow control off.
I would also recomment crossing DTR with DSR and CTS, to get hardware flow control.
I'm tending to agree with you that something in the cable chain is messed up.
A gender-changer is NOT the same thing as a null-modem adapter. That's the most common oversight. If you have something in there that swaps the genders around, it might be just a straight-through gender-changer. In addition to changing genders, the right pins need to be crossed, that's what a null-modem adapter does.
If you need the wiring diagram for a null modem do a web search. Here's one for DB-9 connectors: http://image.pinout.net/pinout_9_pin_files/connector_pinout.php?image=Null-M...