Date: Fri, 25 Jul 2008 16:26:14 -0700 From: "Peter Wemm" <peter@wemm.org> To: "Peter Jeremy" <peterjeremy@optushome.com.au> Cc: gavin@freebsd.org, "Marvin Malkowski Jr." <marv@linuxgames.com>, freebsd-amd64@freebsd.org Subject: Re: amd64/125943: Serial Consoles do not work on amd64 freebsd Message-ID: <e7db6d980807251626h5afa1ee0r22e993466138d7@mail.gmail.com> In-Reply-To: <20080725210950.GE74748@server.vk2pj.dyndns.org> References: <200807251126.m6PBQ9Ww085651@freefall.freebsd.org> <11AB7428-134A-446D-AD68-4A7BFDC8E1C2@linuxgames.com> <20080725210950.GE74748@server.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jul 25, 2008 at 2:09 PM, Peter Jeremy <peterjeremy@optushome.com.au> wrote: > On 2008-Jul-25 09:58:49 -0700, "Marvin Malkowski Jr." <marv@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@wemm.org; peter@FreeBSD.org; peter@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e7db6d980807251626h5afa1ee0r22e993466138d7>