Re: Serial console problems with stable/8
On Mon, Sep 13, 2010 at 09:19:54PM -0700, Jeremy Chadwick wrote: > On Mon, Sep 13, 2010 at 08:44:02PM +0200, Ed Schouten wrote: > > Maybe we should just implement /dev/console in such a way that it can > > never get stuck on dcd. I've seen this break too many times. > > > > Below is an untested patch. Anyone willing to test it for me? > > I'll test this out on our RELENG_8 system tonight. RELENG_8 system in question rebuilt with patch; works fine! (Tested both single-user, and multi-user with getty) If solves Oliver's issue, I'd say commit it. :-) -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Serial console problems with stable/8
On Mon, Sep 13, 2010 at 08:44:02PM +0200, Ed Schouten wrote: > Maybe we should just implement /dev/console in such a way that it can > never get stuck on dcd. I've seen this break too many times. > > Below is an untested patch. Anyone willing to test it for me? I'll test this out on our RELENG_8 system tonight. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Serial console problems with stable/8
* Oliver Fromme wrote: > @ Jeremy: Thank you for the detailed response! I will > make sure to bring a multimeter with me and check the > pin connections on my nullmodem cable. I'm still curious > why this cable worked with 7.x with the same configuration. I seem to remember some of the drivers enforced CLOCAL when the device is used as a boot device. Maybe sio(4) does this, while uart(4) does not? An advantage of the patch is that it makes this construct superfluous. -- Ed Schouten WWW: http://80386.nl/ pgpEAKnJjfUKU.pgp Description: PGP signature
Re: Serial console problems with stable/8
Ed Schouten wrote: > Just replying to a random message in this thread. > > Maybe we should just implement /dev/console in such a way that it can > never get stuck on dcd. I've seen this break too many times. > > Below is an untested patch. Anyone willing to test it for me? Thank you! I will gladly test it on Friday. I'm sorry I can't test it earlier, but I'm reluctant to test things like this remotely. @ Jeremy: Thank you for the detailed response! I will make sure to bring a multimeter with me and check the pin connections on my nullmodem cable. I'm still curious why this cable worked with 7.x with the same configuration. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "The scanf() function is a large and complex beast that often does something almost but not quite entirely unlike what you desired." -- Chris Torek ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Serial console problems with stable/8
Just replying to a random message in this thread.
Maybe we should just implement /dev/console in such a way that it can
never get stuck on dcd. I've seen this break too many times.
Below is an untested patch. Anyone willing to test it for me?
As Jeremy did point out, FreeBSD's TTY/serial/etc code really lacks a
true console device which multiplexes both input and output to all
serial devices.
%%%
Index: tty.c
===
--- tty.c (revision 212549)
+++ tty.c (working copy)
@@ -282,7 +282,8 @@
/* Wait for Carrier Detect. */
if (!TTY_CALLOUT(tp, dev) && (oflags & O_NONBLOCK) == 0 &&
- (tp->t_termios.c_cflag & CLOCAL) == 0) {
+ (tp->t_termios.c_cflag & CLOCAL) == 0 &&
+ dev != dev_console) {
while ((ttydevsw_modem(tp, 0, 0) & SER_DCD) == 0) {
error = tty_wait(tp, &tp->t_dcdwait);
if (error != 0)
%%%
--
Ed Schouten
WWW: http://80386.nl/
pgp5bVOCevFGN.pgp
Description: PGP signature
Re: Serial console problems with stable/8
On Mon, Sep 13, 2010 at 06:59:58PM +0200, Oliver Fromme wrote: > > John Baldwin wrote: > > On Monday, September 13, 2010 11:55:27 am Oliver Fromme wrote: > > > I think the boot.config stuff might be a red herring. > > > The console breaks (i.e. freezes) as soon as I try to run > > > a getty process on it -- That seems to indicate that getty > > > does *something* to the console device which causes the > > > problem. The wchan "ttydcd" seems to indicate is has > > > something to do with carrier detection or flow control. > > > This points to the uart driver as the culprit which > > > replaced sio. > > > > Well, /dev/ttyXX have always waited for carrier detect, whereas > > /dev/cuaXX (the call-out devices) have not. > > Well, before the update I had ttyd0 in /etc/ttys (this is > the default in FreeBSD 7.x), so it should have waited for > carrier detect, too. Re-adding ed@ to the CC list. I hope he can shed some light on this. I believe FreeBSD expects DCD to be raised on both sio(4) and uart(4) when /dev/ttyuX devices are used -- however, see item 3 below. We've upgraded numerous servers of ours from RELENG_6 and RELENG_7, to RELENG_8, with no serial console issues (we still have some RELENG_6 and RELENG_7 boxes in use as well, using sio(4), so we can provide details from those too if need be). Our cabling/hardware differs from yours though. > > That was so that you could hook a modem up to a serial port and getty > > would not return from open(2) and print a login banner until someone > > dialed the modem and connected. I think Jeremy has already given you > > some good things to try (such as 3wire.9600) to debug this instead. > > Yes, I will try that ... But with the 3wire entry I won't > have any flow control at all, so output can be lost, right? > Doesn't sound like a good solution. 1) gettytab(5) mentions the "mb" capability, which tells it to do flow control based on DCD, I believe. This defaults to off, and isn't defined for the std.XXX nor 3wire.XXX entries. 2) However, I imagine some null modem adapters or cables might wire RTS and CTS to DCD. Check out Table 26-2 for DB9 to DB9 null modem cable wiring, and be sure to check out the paragraph *after* "Note:" in Table 26-3. http://www.freebsd.org/doc/handbook/serial.html#SERIAL-CABLES-PORTS 3) But here's the fun part! The adapters I use in our co-location (DB9 serial ports on PCs wired to a MRV unit), pin 1 (DCD) on the DB9 serial port *is not* wired -- it literally hangs loose. The adapters use hardware flow control (CTS/RTS), and all equipment is configured to use it as well. We use the following line in /etc/ttys reliably (without any character loss[1]): ttyu0 "/usr/libexec/getty std.115200" xterm on secure The exact pinout is below: RJ45 DB9 Female Female === === (CTS) 1 <> 7 (RTS) (DTR) 2 <> 6 (DSR) (TxD) 3 <> 2 (RxD) (TxD GND) 4 <> 5 (GND) (RxD GND) 5 <> 5 (GND) (RxD) 6 <> 3 (TxD) (DSR/DCD) 7 <> 4 (DTR) (RTS) 8 <> 8 (CTS) I can provide stty -a -f /dev/ttyuX output on one of these machines if folks would find it useful as a comparison model to what Oliver's seeing. Is it possible the null modem adapter, cables, or jacks been slightly jostled or anything like that? Hrm, actually I guess that's pointless to ask since you can restore proper behaviour rolling back to RELENG_7. [1]: Prior to logging in, there is no flow control -- this happens on sio(4) as well as uart(4). This problem dates back to at least the FreeBSD 4.x days and is easily detectable by hitting enter repetitively at the "login:" prompt on a serial console; occasionally the output will get messed up. Once you log in, however, flow control works fine. When I chatted with Marcel Moolenaar about this, he assured me this is expected. This isn't the problem you're seeing, but I thought I'd mention it in passing anyway. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Serial console problems with stable/8
John Baldwin wrote: > On Monday, September 13, 2010 11:55:27 am Oliver Fromme wrote: > > I think the boot.config stuff might be a red herring. > > The console breaks (i.e. freezes) as soon as I try to run > > a getty process on it -- That seems to indicate that getty > > does *something* to the console device which causes the > > problem. The wchan "ttydcd" seems to indicate is has > > something to do with carrier detection or flow control. > > This points to the uart driver as the culprit which > > replaced sio. > > Well, /dev/ttyXX have always waited for carrier detect, whereas > /dev/cuaXX (the call-out devices) have not. Well, before the update I had ttyd0 in /etc/ttys (this is the default in FreeBSD 7.x), so it should have waited for carrier detect, too. > That was so that you could hook a modem up to a serial port and getty > would not return from open(2) and print a login banner until someone > dialed the modem and connected. I think Jeremy has already given you > some good things to try (such as 3wire.9600) to debug this instead. Yes, I will try that ... But with the 3wire entry I won't have any flow control at all, so output can be lost, right? Doesn't sound like a good solution. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Documentation is like sex; when it's good, it's very, very good, and when it's bad, it's better than nothing." -- Dick Brandon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Serial console problems with stable/8
On Monday, September 13, 2010 11:55:27 am Oliver Fromme wrote: > John Baldwin wrote: > > On Monday, September 13, 2010 8:49:48 am Oliver Fromme wrote: > > > Now I get your point ... Yes, -P does probe the keyboard > > > first. That's probably why I see the boot0/boot2 on the > > > VGA console, not on the serial port. As far as I know, > > > /boot.config is read by the boot0/boot2 stage, not by > > > loader(8). > > > > But loader inherits the settings from boot2, so if you set it in > > /boot.config you do not need to set anything in loader.conf. Also, > > having boot2 use serial is good in that you can boot loader.old if > > you ever get a broken /boot/loader. Using '-Dh' in /boot.config is > > what I do on all the boxes where I use a serial console. > > Makes sense. I'll change -P to -Dh. > > But having console="comconsole" in loader.conf should also > enable the serial console, except that it happens a little > later (in loader instead of boot2), right? Correct. > I think the boot.config stuff might be a red herring. > The console breaks (i.e. freezes) as soon as I try to run > a getty process on it -- That seems to indicate that getty > does *something* to the console device which causes the > problem. The wchan "ttydcd" seems to indicate is has > something to do with carrier detection or flow control. > This points to the uart driver as the culprit which > replaced sio. Well, /dev/ttyXX have always waited for carrier detect, whereas /dev/cuaXX (the call-out devices) have not. That was so that you could hook a modem up to a serial port and getty would not return from open(2) and print a login banner until someone dialed the modem and connected. I think Jeremy has already given you some good things to try (such as 3wire.9600) to debug this instead. > > > Anyway, I don't care too much for boot0/boot2; I've never > > > had to interact with them on that machine. The important > > > thing for me is that loader(8) and the kernel use the > > > serial port for the console, and that I can login on it > > > (i.e. there must be a getty running). All of that seemed > > > to be accomplished with the console="comconsole" entry in > > > /boot/loader.conf ... At least it worked when I first > > > installed that machine in September 2000 (yeah, exactly 10 > > > years ago) with FreeBSD 4.1, then updated it roughly every > > > two years ... And it stopped working in 8.x. > > > > Did you update your hints to rename the 'sio' hints to 'uart'? > > Yes, mergemaster did that for me. I double-checked it. > > hint.uart.0.at="isa" > hint.uart.0.port="0x3F8" > hint.uart.0.flags="0x10" > hint.uart.0.irq="4" Ok. I know that for machines I have at work that run 7, if I boot a 8.x kernel have to explicitly unset the sio hints and set the uart hints for the serial console to work in 8. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Serial console problems with stable/8
John Baldwin wrote: > On Monday, September 13, 2010 8:49:48 am Oliver Fromme wrote: > > Now I get your point ... Yes, -P does probe the keyboard > > first. That's probably why I see the boot0/boot2 on the > > VGA console, not on the serial port. As far as I know, > > /boot.config is read by the boot0/boot2 stage, not by > > loader(8). > > But loader inherits the settings from boot2, so if you set it in > /boot.config you do not need to set anything in loader.conf. Also, > having boot2 use serial is good in that you can boot loader.old if > you ever get a broken /boot/loader. Using '-Dh' in /boot.config is > what I do on all the boxes where I use a serial console. Makes sense. I'll change -P to -Dh. But having console="comconsole" in loader.conf should also enable the serial console, except that it happens a little later (in loader instead of boot2), right? I think the boot.config stuff might be a red herring. The console breaks (i.e. freezes) as soon as I try to run a getty process on it -- That seems to indicate that getty does *something* to the console device which causes the problem. The wchan "ttydcd" seems to indicate is has something to do with carrier detection or flow control. This points to the uart driver as the culprit which replaced sio. > > Anyway, I don't care too much for boot0/boot2; I've never > > had to interact with them on that machine. The important > > thing for me is that loader(8) and the kernel use the > > serial port for the console, and that I can login on it > > (i.e. there must be a getty running). All of that seemed > > to be accomplished with the console="comconsole" entry in > > /boot/loader.conf ... At least it worked when I first > > installed that machine in September 2000 (yeah, exactly 10 > > years ago) with FreeBSD 4.1, then updated it roughly every > > two years ... And it stopped working in 8.x. > > Did you update your hints to rename the 'sio' hints to 'uart'? Yes, mergemaster did that for me. I double-checked it. hint.uart.0.at="isa" hint.uart.0.port="0x3F8" hint.uart.0.flags="0x10" hint.uart.0.irq="4" Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "C is quirky, flawed, and an enormous success." -- Dennis M. Ritchie. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Serial console problems with stable/8
On Monday, September 13, 2010 8:49:48 am Oliver Fromme wrote: > Jeremy Chadwick wrote: > > On Mon, Sep 13, 2010 at 09:21:21AM +0200, Oliver Fromme wrote: > > > Jeremy Chadwick wrote: > > > > Is there a PS/2 keyboard hooked up to this machine when you're > > > > attempting to get serial console output? > > > > > > Kind of. It's connected to a local KVM switch. > > > > Does the KVM switch provide power to a PS/2 port which isn't currently > > selected? (E.g. on an A/B/C/D KVM switch, if the FreeBSD box is wired > > to port A, and the KVM switch has port C selected, does port A still get > > power?) Some KVMs do this, others do not. > > Yes, it does. > > Now I get your point ... Yes, -P does probe the keyboard > first. That's probably why I see the boot0/boot2 on the > VGA console, not on the serial port. As far as I know, > /boot.config is read by the boot0/boot2 stage, not by > loader(8). But loader inherits the settings from boot2, so if you set it in /boot.config you do not need to set anything in loader.conf. Also, having boot2 use serial is good in that you can boot loader.old if you ever get a broken /boot/loader. Using '-Dh' in /boot.config is what I do on all the boxes where I use a serial console. > Anyway, I don't care too much for boot0/boot2; I've never > had to interact with them on that machine. The important > thing for me is that loader(8) and the kernel use the > serial port for the console, and that I can login on it > (i.e. there must be a getty running). All of that seemed > to be accomplished with the console="comconsole" entry in > /boot/loader.conf ... At least it worked when I first > installed that machine in September 2000 (yeah, exactly 10 > years ago) with FreeBSD 4.1, then updated it roughly every > two years ... And it stopped working in 8.x. Did you update your hints to rename the 'sio' hints to 'uart'? -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Serial console problems with stable/8
Jeremy Chadwick wrote: > On Mon, Sep 13, 2010 at 09:21:21AM +0200, Oliver Fromme wrote: > > Jeremy Chadwick wrote: > > > Is there a PS/2 keyboard hooked up to this machine when you're > > > attempting to get serial console output? > > > > Kind of. It's connected to a local KVM switch. > > Does the KVM switch provide power to a PS/2 port which isn't currently > selected? (E.g. on an A/B/C/D KVM switch, if the FreeBSD box is wired > to port A, and the KVM switch has port C selected, does port A still get > power?) Some KVMs do this, others do not. Yes, it does. Now I get your point ... Yes, -P does probe the keyboard first. That's probably why I see the boot0/boot2 on the VGA console, not on the serial port. As far as I know, /boot.config is read by the boot0/boot2 stage, not by loader(8). Anyway, I don't care too much for boot0/boot2; I've never had to interact with them on that machine. The important thing for me is that loader(8) and the kernel use the serial port for the console, and that I can login on it (i.e. there must be a getty running). All of that seemed to be accomplished with the console="comconsole" entry in /boot/loader.conf ... At least it worked when I first installed that machine in September 2000 (yeah, exactly 10 years ago) with FreeBSD 4.1, then updated it roughly every two years ... And it stopped working in 8.x. I will try your suggestion of replacing -P with -Dh, next time I'm at the site (probably Friday). It's too risky to try that remotely, given that I had to press the hard reset button several times yesterday during my attempts of getting the serial console to work as it should. Fortunately the machine has a small disk, so fsck finishes in only two or three minutes ... However, I fear that it won't improve things. I don't see how it could change the symptoms I'm seeing. The serial console _is_ activated (through the loader.conf entry), but it just doesn't work correctly. > > the boot.config(5) manpage is in urgent need of a fix. > > Quote: > > > > > The command: > > > > > > # echo "-P" > /boot.config > > > > > > will activate the serial console of FreeBSD. > > That's a highly misleading description, and should probably be removed. > It's better to read boot(8). Agreed. > http://www.freebsd.org/doc/handbook/serialconsole-setup.html I did have exactly the settings listed in section 26.6.2: console="comconsole" in loader.conf and the getty turned on in /etc/ttys. And specifically, section 26.6.6.1 states: | You can easily specify the boot loader and the kernel | to use the serial console by writing just one line in | /boot/loader.conf: | | set console="comconsole" | This will take effect regardless of the settings in the | boot block discussed in the previous section. So, it's pretty much irrelevant whether I have -P or -Dh or anything else (or nothing at all) in /boot.config. > You'll find that FreeBSD does not offer a "true" dual console setup. > DragonflyBSD does offer this. True. I'm aware of that. I don't need dual console. > > Also, with that flag it has worked fine for ages, until > > I updated to 8.1-stable. There must be a regression > > somewhere. > > I don't know if the regression is with PS/2 keyboard probing or with the > introduction of uart(4) as the default serial port driver. I'm CC'ing > ed@ since he's worked heavily on uart(4) and can assist here. I'm guessing it is uart's fault, but I haven't dug deeply enough to be certain. > > BTW, the interesting thing is that all processes that try to access > > the console hang in "ttydcd". I'm not familiar with the tty code ... > > Does anyone have an idea what this means? > > I imagine it means the tty driver (thus uart(4)) is waiting for the DCD > line on the serial port to either go low or high (not sure which), but I > could be completely wrong. > > One more thing to try: can you replace "std.9600" in your /etc/ttys > with "3wire.9600" and then do "init q" and see if things improve? This > should remove carrier detection (DCD) from the mix. That sounds like a very good suggestion! Will try that. > If using 3wire.9600 works, can you provide a description of the wiring > of your serial console setup? Specifically what DB9 pin is connected to > what on the remote end, and what the remote end actually is (Xyplex > unit, another PC, etc.)? The remote end is another PC running FreeBSD (still 7.x). I use tip(1) running inside a screen(1) session on that remote PC to connect to my serial console. The cable is a standard nullmodem cable, not selfmade. It's a DB9-to-DB9 cable labelled "nullmodem", so I guess it's correctly wired including carrier / handshake, i.e. not just a 3-wire cable. (And it did work fine from FreeBSD 4.x to 7.x ... sorry for repeating myself.) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Mu
Re: Serial console problems with stable/8
Am 13.09.2010 um 13:04 schrieb David Evans: > I can confirm there is much weirdness with the uart on 8-STABLE. OTOH, I have real hardware where things are working just fine: $ grep uart /var/run/dmesg.boot uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart0: console (115200,n,8,1) $ grep ttyu0 /etc/ttys ttyu0 "/usr/libexec/getty std.115200" vt100 on secure This is -stable from July 15th. The other end of the serial line is an uftdi USB adapter: uftdi0: on usbus0 Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Serial console problems with stable/8
I can confirm there is much weirdness with the uart on 8-STABLE. I'm using FBSD in several virtual machines on Parallels Desktop. It is possible to set the serial port on the VM to output to a file on the host OS I try something like 'cat file > /dev/cuad0 on FBSD 7 and 8. This works on 7 but hangs after the first few kB on 8. Next I try a login on the guest OS. I set one VM to be a server and the other a client. I connect the two VM's serial ports together via a socket on the host OS. I also start a login on the server VM's serial port. With both VMs running 7, I can login using kermit on the client. No amount of trying gets flow control of any type to work, but at least it does not hang. The lack of flow control means that much output is lost. With both VMs running 8, I can login, just about, but attempting to edit a file or do a long ls listing results in a hang. Flow control does not work in either the RTS/CTS or XON/XOFF modes. Next, I try kernel debugging using kgdb via serial link between two VMs running 8. I'm surprised to find that it works quite well with no hangs. Presumably this is because the kgdb protocol only sends small amounts of data at a time or perhaps it runs at a low level, as mentioned earlier in this thread. I have not tried this with 7. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Serial console problems with stable/8
Am 12.09.2010 um 17:26 schrieb Oliver Fromme: > I cannot even su(1) to root because it tries to print > a message to the console, so it hangs, too. For the same > reason I can't use shutdown(8) either. :-( > > This is what a hanging su(1) command looks like in ps -alxww: > UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND >0 1533 1532 0 76 0 3392 3180 ttydcd I+ 00:00.05 su (zsh) > > Interestingly, the KDB sequences CR ~ ^B/^P/^R/ do work, > which use the "low-level" console. So only the "high-level" > console is frozen. Looking at the WCHAN, I'd speculate that it's waiting for DCD to become active. Are you using a proper cable with handshaking, or a three-wire cable? See what stty thinks the port is set to. It probably has clocal set, but shouldn't. See if you can unwedge it by setting -clocal with stty, then pick a proper cable or gettytab entry. Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Serial console problems with stable/8
On Mon, Sep 13, 2010 at 09:21:21AM +0200, Oliver Fromme wrote: > Jeremy Chadwick wrote: > > Is there a PS/2 keyboard hooked up to this machine when you're > > attempting to get serial console output? > > Kind of. It's connected to a local KVM switch. Does the KVM switch provide power to a PS/2 port which isn't currently selected? (E.g. on an A/B/C/D KVM switch, if the FreeBSD box is wired to port A, and the KVM switch has port C selected, does port A still get power?) Some KVMs do this, others do not. > > If so, I'm not too surprised it doesn't work (re: -P flag). > > If -P is not supposed to activate the serial console, then > the boot.config(5) manpage is in urgent need of a fix. > Quote: > > > The command: > > > > # echo "-P" > /boot.config > > > > will activate the serial console of FreeBSD. That's a highly misleading description, and should probably be removed. It's better to read boot(8). -P does not activate serial console. -P probes for a PS/2 keyboard. If one is attached, the system behaves like it would with a VGA console attached. Otherwise, if there is no PS/2 keyboard attached, it behaves identically to the -D -h flags being set. I do not know how -P internally works. I imagine it speaks to the PIC internal to the keyboard, or through a BIOS interrupt (0x10). This is why I asked what I did about the KVM switch above. The -D and -h flags are somewhat confusing, so see the "table" in the handbook for what does what (note the handbook which still references sio(4) flags/bits, but those also apply to uart(4)): http://www.freebsd.org/doc/handbook/serialconsole-setup.html You'll find that FreeBSD does not offer a "true" dual console setup. DragonflyBSD does offer this. > Also, with that flag it has worked fine for ages, until > I updated to 8.1-stable. There must be a regression > somewhere. I don't know if the regression is with PS/2 keyboard probing or with the introduction of uart(4) as the default serial port driver. I'm CC'ing ed@ since he's worked heavily on uart(4) and can assist here. > > Can you try the following? > > > > 1) Removing kernel_options and console from loader.conf > > 2) Place "-P" in /boot.config instead > > > > If this doesn't change the behaviour, please replace -P and with -D -h > > and see if there's any improvement. > I already have tried all kinds of different combinations when I sat in > front of the box yesterday. I'm not sure if I have tried the exact > combination that you suggest, though. I also don't understand why > those changes should improve anything. Hopefully the reason why I'm asking you to try this makes more sense with my above explanation of what -P actually does. > BTW, the interesting thing is that all processes that try to access > the console hang in "ttydcd". I'm not familiar with the tty code ... > Does anyone have an idea what this means? I imagine it means the tty driver (thus uart(4)) is waiting for the DCD line on the serial port to either go low or high (not sure which), but I could be completely wrong. One more thing to try: can you replace "std.9600" in your /etc/ttys with "3wire.9600" and then do "init q" and see if things improve? This should remove carrier detection (DCD) from the mix. If using 3wire.9600 works, can you provide a description of the wiring of your serial console setup? Specifically what DB9 pin is connected to what on the remote end, and what the remote end actually is (Xyplex unit, another PC, etc.)? Thanks! -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Serial console problems with stable/8
Jeremy Chadwick wrote: > Is there a PS/2 keyboard hooked up to this machine when you're > attempting to get serial console output? Kind of. It's connected to a local KVM switch. > If so, I'm not too surprised it doesn't work (re: -P flag). If -P is not supposed to activate the serial console, then the boot.config(5) manpage is in urgent need of a fix. Quote: > The command: > > # echo "-P" > /boot.config > > will activate the serial console of FreeBSD. Also, with that flag it has worked fine for ages, until I updated to 8.1-stable. There must be a regression somewhere. > Can you try the following? > > 1) Removing kernel_options and console from loader.conf > 2) Place "-P" in /boot.config instead > > If this doesn't change the behaviour, please replace -P and with -D -h > and see if there's any improvement. I already have tried all kinds of different combinations when I sat in front of the box yesterday. I'm not sure if I have tried the exact combination that you suggest, though. I also don't understand why those changes should improve anything. Anyway, I will try next time I'm near the machine (it's a three hours ride) which will probably be on Friday. If it won't work then I'll downgrade it to 7.1 the same day. BTW, the interesting thing is that all processes that try to access the console hang in "ttydcd". I'm not familiar with the tty code ... Does anyone have an idea what this means? Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd With Perl you can manipulate text, interact with programs, talk over networks, drive Web pages, perform arbitrary precision arithmetic, and write programs that look like Snoopy swearing. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Serial console problems with stable/8
On Mon, Sep 13, 2010 at 08:37:24AM +0200, Oliver Fromme wrote: > Greg Byshenk wrote: > > On Sun, Sep 12, 2010 at 05:26:12PM +0200, Oliver Fromme wrote: > > > > > On Friday I have updated a machine from 7.1 to stable/8. > > > It is connected to a serial console. With 7.1 everything > > > worked fine, but with stable/8 things seem to break. > > > > [...] > > > > > Here's my setup (which worked perfectly fine with 7.1): > > > > > > /boot.config: > > > -P > > > > > > /boot/loader.conf: > > > kernel_options="-P" > > > console="comconsole" > > > > > > /etc/ttys: > > > ttyu0 "/usr/libexec/getty std.9600" vt100 off secure > > > > Shouldn't this: ^^^ > > be 'on'...? > > Yes, of course it *was* on (which caused the symptoms > I described). As I explained, I had to turn it off so > I could at least use su(1) and shutdown(8) without > freezing the whole thing. Is there a PS/2 keyboard hooked up to this machine when you're attempting to get serial console output? If so, I'm not too surprised it doesn't work (re: -P flag). Can you try the following? 1) Removing kernel_options and console from loader.conf 2) Place "-P" in /boot.config instead If this doesn't change the behaviour, please replace -P and with -D -h and see if there's any improvement. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Serial console problems with stable/8
Greg Byshenk wrote: > On Sun, Sep 12, 2010 at 05:26:12PM +0200, Oliver Fromme wrote: > > > On Friday I have updated a machine from 7.1 to stable/8. > > It is connected to a serial console. With 7.1 everything > > worked fine, but with stable/8 things seem to break. > > [...] > > > Here's my setup (which worked perfectly fine with 7.1): > > > > /boot.config: > > -P > > > > /boot/loader.conf: > > kernel_options="-P" > > console="comconsole" > > > > /etc/ttys: > > ttyu0 "/usr/libexec/getty std.9600" vt100 off secure > > Shouldn't this: ^^^ > be 'on'...? Yes, of course it *was* on (which caused the symptoms I described). As I explained, I had to turn it off so I could at least use su(1) and shutdown(8) without freezing the whole thing. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd > Can the denizens of this group enlighten me about what the > advantages of Python are, versus Perl ? "python" is more likely to pass unharmed through your spelling checker than "perl". -- An unknown poster and Fredrik Lundh ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Serial console problems with stable/8
On Sun, Sep 12, 2010 at 05:26:12PM +0200, Oliver Fromme wrote: > On Friday I have updated a machine from 7.1 to stable/8. > It is connected to a serial console. With 7.1 everything > worked fine, but with stable/8 things seem to break. [...] > Here's my setup (which worked perfectly fine with 7.1): > > /boot.config: > -P > > /boot/loader.conf: > kernel_options="-P" > console="comconsole" > > /etc/ttys: > ttyu0 "/usr/libexec/getty std.9600" vt100 off secure Shouldn't this: ^^^ be 'on'...? -- greg byshenk - gbysh...@byshenk.net - Leiden, NL > /boot/device.hints: > hint.uart.0.at="isa" > hint.uart.0.port="0x3F8" > hint.uart.0.flags="0x10" > hint.uart.0.irq="4" > > /var/run/dmesg.boot: > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > uart0: [FILTER] > uart0: console (9600,n,8,1) > > The serial port is connected to another PC that runs tip(1) > in a screen(1) session, using a 9-pin nullmodem cable. > That setup hasn't changed in ages; that other PC is running > an older version of FreeBSD. > > I need this issue to be resolved, because the serial console > is required for remote management (the machine is a 3-hours > ride away from home). If it can't be resolved, I will have > to downgrade it to 7.x. > > Best regards >Oliver > > -- > Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. > Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: > secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- > chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart > > FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd > > I suggested holding a "Python Object Oriented Programming Seminar", > but the acronym was unpopular. > -- Joseph Strout > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Serial console problems with stable/8
Hi, On Friday I have updated a machine from 7.1 to stable/8. It is connected to a serial console. With 7.1 everything worked fine, but with stable/8 things seem to break. When the machine boots, everything appears normal, i.e. I get all of the boot output, but then the console freezes. The last thing that appears on the console is the time stamp from the date(1) command at the very end of /etc/rc. I do not get a login prompt, even though I see a getty process on ttyu0. No further output to the console happens, commands like "echo foo > /dev/console" freeze, too. According to ps -alx they hang in "ttydcd". I cannot even su(1) to root because it tries to print a message to the console, so it hangs, too. For the same reason I can't use shutdown(8) either. :-( This is what a hanging su(1) command looks like in ps -alxww: UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 1533 1532 0 76 0 3392 3180 ttydcd I+ 00:00.05 su (zsh) Interestingly, the KDB sequences CR ~ ^B/^P/^R/ do work, which use the "low-level" console. So only the "high-level" console is frozen. When I boot with the getty on ttyu0 switched off in /etc/ttys, the console does *not* freeze, and output to /dev/console works normal (I don't get a login prompt, of course). I can use su(1), shutdown(8) and so on. But as soon as I try to start a getty on ttyu0, the darn thing ceases to work. Here's my setup (which worked perfectly fine with 7.1): /boot.config: -P /boot/loader.conf: kernel_options="-P" console="comconsole" /etc/ttys: ttyu0 "/usr/libexec/getty std.9600" vt100 off secure /boot/device.hints: hint.uart.0.at="isa" hint.uart.0.port="0x3F8" hint.uart.0.flags="0x10" hint.uart.0.irq="4" /var/run/dmesg.boot: uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart0: console (9600,n,8,1) The serial port is connected to another PC that runs tip(1) in a screen(1) session, using a 9-pin nullmodem cable. That setup hasn't changed in ages; that other PC is running an older version of FreeBSD. I need this issue to be resolved, because the serial console is required for remote management (the machine is a 3-hours ride away from home). If it can't be resolved, I will have to downgrade it to 7.x. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd I suggested holding a "Python Object Oriented Programming Seminar", but the acronym was unpopular. -- Joseph Strout ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
