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+ 0 0: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
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 secureShouldn't this: ^^^ be 'on'...? -- greg byshenk - gbyshenk@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-unsubscribe@freebsd.org"
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+ 0 0: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 Bethke <stb@lassitu.de> Fon +49 151 14070811
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.
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: <usb serial converter> on usbus0 Stefan -- Stefan Bethke <stb@lassitu.de> Fon +49 151 14070811