Date: Wed, 5 Jun 2013 13:09:14 -0700 From: Jeremy Chadwick <jdc@koitsu.org> To: Alban Hertroys <haramrae@gmail.com> Cc: "freebsd-stable@freebsd.org" <freebsd-stable@freebsd.org> Subject: Re: Serial terminal issues Message-ID: <20130605200914.GA19604@icarus.home.lan> In-Reply-To: <93196E06-1775-46A4-A3E9-1C8A3B8C4E94@gmail.com> References: <383C78B1-4F16-408F-8144-63B470D0C129@gmail.com> <20130605005918.GA5709@icarus.home.lan> <93196E06-1775-46A4-A3E9-1C8A3B8C4E94@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 05, 2013 at 09:29:56PM +0200, Alban Hertroys wrote:
> {sniping stuff that is pending or has been acknowledged}
> On Jun 5, 2013, at 2:59, Jeremy Chadwick <jdc@koitsu.org> wrote:
> > Serial port speed settings in a BIOS pertain to BIOS-level console
> > redirection -- that redirection is lost the instant anything (boot
> > loader, kernel, etc.) touches SMI and/or interrupts and starts
> > "fiddling" with the serial port.
>
> That's the bit I wasn't entirely certain of - that there is no possible interaction from having a BIOS console to the point where the OS takes over. That's why I mentioned it.
>
> I assumed that if the BIOS had set up the serial port to 19200 baud and the OS didn't specify it, that it would be possible that the speed set up in the BIOS would still be in effect and that the serial terminal just incidentally worked for the last 10 years because of that. Far-fetched, I know.
Not far-fetched. Some system BIOSes with BIOS-level serial console
redirection offer what you describe -- on Supermicro systems, you can
toggle this capability in the BIOS, it's called "Continue CR After POST"
(CR stands for Console Redirection).
This is hard to explain without getting into the technicalities, so bear
with me here. Get coffee, etc..
What this BIOS feature does is "retain" the SMI/interrupt mapping stuff,
so that certain calls to interrupt 0x10 (the BIOS interrupt) for things
like cursor movement, writing text/strings, etc. are done on the native
console (ex. VGA) *as well* as sent to the serial port (and converted
into escape sequences of your choice -- another BIOS option, "Console
Type", lets you pick between things like vt100, ANSI, ASCII, etc.).
This option is useful for things like option ROMs or HBAs (SCSI/SAS
controllers, etc.) which print stuff *after* POST. I'm sure you've seen
this. With "Continue CR After POST" disabled, those types of messages
are only seen on the VGA console.
However, regardless of the setting of "Continue CR After POST", the
instant any x86 code starts tinkering with the SMI/interrupt stuff, that
functionality is lost (and cannot be restored). In FreeBSD, this
definitely happens when the kernel starts, but AFAIR not during the
bootstraps.
Instead, the bootstraps (that is: boot0, as well as boot2/loader) have
the ability to speak to the serial port *directly*, rather than relying
on interrupt 0x10.
The -S19200 parameter in /boot.config causes the bootstraps **very**
early on to set the serial port speed to 19200 baud. This could cause
a problem if you have BIOS-level serial redirect set up and set to a
different speed (ex. 57600), so naturally you need to make sure
everything uses the same speed at all "stages".
The -Dh parameter in /boot.config causes the bootstraps **very** early
on to tell FreeBSD to write data to the VGA console/text console, in
addition to the serial port (directly, not via interrupt 0x10). For how
all that works (meaning how -D vs. -Dh behaves and at what ""stages""
of the FreeBSD boot process), please see the FreeBSD Handbook
section 27.6.4.1:
http://www.freebsd.org/doc/en/books/handbook/serialconsole-setup.html
The handbook here is also outdated/wrong; it's talking about sio0 when
it means to refer to uart0. flags for uart0 in this case will be
0x00010 (meaning uart0 is a potential serial console).
Finally, the important/key part: the -Dh capability when used in
/boot.config gets ""passed on"" to boot2/loader (so it knows to output
data to the serial port as a console), and boot2/loader **ALSO** passes
that information on to the kernel when it starts so that it knows to
print data to the serial port too.
Make sense? :-)
This is why I advocate using /boot.config (or you can use /boot/config
if you wish -- both in 9.1-RELEASE work (thanks des@ !)) rather than
mucking about with /boot/loader.conf -- the added advantage is that you
can actually get serial output at an earlier phase/stage, in case some
of your boot blocks don't work. More specifically, with /boot.config
you can actually get this on the serial port (if you bang on Escape or
Enter repeatedly VERY early on in the boot process):
>> FreeBSD/i386 BOOT
Default: 0:ad(0,a)/boot/loader
boot:
But if you don't bang on keys, you won't ever see this.
Anyway, sorry for the long ramble there, but the above is how it works.
(I'm sure readers will go "My god, that is one of the best write-ups
I've seen of how the serial console/boot process stuff works, why isn't
this in the handbook!?" to which I will opt out/not respond to).
> > What you're adjusting in FreeBSD is 1) the FreeBSD boot loader touching
> > the serial port, and 2) the FreeBSD kernel outputting to a serial port
> > (it also initialises/sets the serial port), and 3) getty et al spawning
> > a login prompt on the serial port.
>
> Regarding 2). I found some references on the internet pertaining settings in the kernel config file to adjust serial console settings. Could that be what I'm missing?
You're referring to either BOOT_COMCONSOLE_SPEED in /etc/make.conf or
"options CONSPEED" in the kernel config.
You do not need either of these **if** you use /boot.config with the
-Sxxx flag. That has been the case since the late FreeBSD 7.x releases
(some bugs were fixed in the bootloader code to help improve serial
initialisation).
If you want to try the "classic method" of using BOOT_COMCONSOLE_SPEED
and "options CONSPEED" in your kernel config, you can read section
27.6.5.1 in the handbook:
http://www.freebsd.org/doc/en/books/handbook/serialconsole-setup.html
BOOT_COMCONSOLE_SPEED will require you to rewrite your boot blocks on
your boot disk using gpart for the change to take effect. The CONSPEED
parameter in your kernel config naturally just requires a kernel
rebuild/reinstall.
> I'm fairly certain the last kernel I used on the old PC was the GENERIC i386 kernel. I don't think there are any significant differences regarding serial console between STABLE-i386 (of a few months ago) and STABLE-amd64?
No, there is no difference in this regard. You will experience the same
problem on i386 as amd64.
The only "known" problem with uart(4) has to do with ACPI -- SOMETIMES.
Some people -- and they are in the minority -- have found that the
uart(4) binding to acpi(4) causes problems (almost certainly with some
ACPI tables, i.e. the motherboard/BIOS vendor is stupid/has bugs), and
that by forcing uart to tie to the classic ISA (or is it PCI? I would
need to find the thread where this was discussed) bus, suddenly uart0
begins working correctly for them.
So, you can try booting with ACPI disabled as a test, but that might not
be sufficient. Again, I can't remember and would need to dig up that
thread.
> > I would point you to my "FreeBSD via serial console and PXE" document,
> > except there are one-offs specific to the PXE portions that are not
> > relevant to your situation. The important part is that I've used
> > FreeBSD serial console for almost 16 years and have a very good
> > understanding of what works (including vs. what some developers say
> > "should" work; i.e. reality vs. pragmatism).
>
> True, but there's relatively much interaction between the different parts that you need to get right before a serial console works at all. Such as having everything on the same baud-rate, for an obvious example.
>
> My guess is that the problem is indeed the connection from the motherboard header to the bracket on the case. I'll verify the cabling of that part sometime this weekend.
There are a myriad of possibilities. This kind of thing I can diagnose
within an hour or two in person, but will take me days or weeks to
figure out via Email. Lots of PC things are like this, I'm sorry to
say.
In the meantime, one recommendation: please try to find a wiring diagram
for the cable you're using (DB9 <--> Bull TWSH004/A terminal). I can't
stress this enough. It may be that your cable doesn't actually tie DCD
high (or is it low?) correctly and thus the uart(4) layer never thinks
there's carrier detect.
I do not generally recommend futzing about with stty against /dev/ttyu0
while getty is in operation. I have tried this on many occasions and
either broke/wedged things or caused anomalous behaviour.
If you think DCD might be a problem, try using "3wire.19200" instead of
"std.19200" in /etc/ttys and run "init q" (to reload the config). If
that works, then your cable is wired "undesirably", and will also lack
flow control. See /etc/gettytab's comments about the 3wire entries for
what they actually do/represent/how they differ from the std ones.
Let us know what transpires. :-)
--
| Jeremy Chadwick jdc@koitsu.org |
| UNIX Systems Administrator http://jdc.koitsu.org/ |
| Making life hard for others since 1977. PGP 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130605200914.GA19604>