amd64/125943: Serial Consoles do not work on amd64 freebsd

[Peter Wemm]

On Fri, Jul 25, 2008 at 2:09 PM, Peter Jeremy
<peterjeremy at optushome.com.au> wrote:
> On 2008-Jul-25 09:58:49 -0700, "Marvin Malkowski Jr." <marv at linuxgames.com> wrote:
> [dmesg & init output trimmed]
>>FreeBSD/amd64 (bigconvoy.telefragged.com) (ttyd0)
>>
>>login:
>
> OK, this is somewhat different to what I expected.  The output you are
> receiving means that the kernel has recognised and is using a serial
> console.
>
>>I cannot enter any input at this point
>
> This implies that the console input path is not working,

There is a race somewhere in the sio code that interacts badly with
the 16550 emulation in the dell servers.  I can reproduce this at will
on the freebsd.org cluster.  Usually just pressing 'enter' on the
serial console will break it.  Sometimes it takes pressing it two or
three times.

I "solved" it for some of the machines by adding a few 'usleep(10000)'
calls in getty in a few strategic places.  It reduced the problem, but
not entirely.

Interestingly, simply logging into the machine on the video console
and killing the getty or login process on the serial console almost
always revived it.

What is most amusing is that it seems that just the output path is
busted.  When the console is hosed like this on our machines, you can
log in and issue commands - just can't see the output.

The machines I saw this on were from the 2950 series.  1.86GHz and 2.00GHz.

I do not know if the sio driver is getting messed up, or if the
*emulated* serial hardware is getting confused.  There is no real
16550-style hardware on these machines.  It is virtual hardware, so
that it can be encapsulated in IPMI / serial-over-lan protocol via the
bmc.

>>sio0: configured irq 4 not in bitmap of probed irqs 0
>>sio0: port may not be enabled
>>sio0: configured irq 4 not in bitmap of probed irqs 0
>>sio0: port may not be enabled
>
> This is definitely not correct and is likely to be the associated with
> the problem.  I don't understand why the SIO ports are probed twice.

I don't think this is the cause.  It attaches once.  The 'not in
bitmap' thing is expected for amd64 kernels though.  It is harmless.
It is because I didn't implement the isa-specific shared-interrupt
detection code.  Remember the old ISA slots where you could plug in
serial cards on shared interrupts?  Since there are (theoretically) no
physical-isa-bus amd64 class machines in existence, I didn't see the
need to add code to support this.

BTW; please try the uart(4) driver instead of sio as well.
-- 
Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com; KI6FJV
"All of this is for nothing if we don't go to the stars" - JMS/B5
"If Java had true garbage collection, most programs would delete
themselves upon execution." -- Robert Sewell