Date: Fri, 11 Jan 2002 11:33:49 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Leo Bicknell <bicknell@ufp.org> Cc: Lyndon Nerenberg <lyndon@atg.aciworldwide.com>, John Baldwin <jhb@FreeBSD.ORG>, freebsd-hackers@FreeBSD.ORG, Alfred Perlstein <bright@mu.org> Subject: Re: serial console + boot blip Message-ID: <3C3F3E1D.F23F9BD7@mindspring.com> References: <bicknell@ufp.org> <20020111042439.GA24433@ussenterprise.ufp.org> <200201111648.g0BGmA2I047791@atg.aciworldwide.com> <20020111165416.GA36184@ussenterprise.ufp.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Leo Bicknell wrote: > The software is clearly lowering DTR on the console briefly between > the kernel probes and init running. That is the issue here. Yes, > it can be hacked around, breaking other things in the process. > I'd like to zero in on why the software is doing this and fix it > though. You are likely SOL. The problem is that, with no opens on it, the natural state of the serial driver is "DTR not asserted". I'm guessing that, even though you are not saying it, that the DTR drop occurs *immediately* after the probe and attach, and not some short time after the init scripts have fully rung, and the getty's are started, initiating "first opens" (this is an educated guess from looking at the code). The answer is, as you stated before: you have the source. The magic incantation you want is to modify the serial driver to attach the serial device with the DTR and hardware flow control signals left held high, until the first final close after the first open of the associated tty. This would make the console not drop DTR until after a getty had opened it, and then a final close. You could test it by connecting, and then typing "foo<CR>" at the login prompt and "foo<CR>" at the password prompt, which gets you to the point where getty has exec'ed login. Then at the next "login: " prompt (assuming you have no account "foo" with password "foo", of course... 8-)), type ^D, and this will cause the login program to exit, which will be a final close, and then the init program will reexec getty on the port, but not after the DTR drop. Note that you will still have to connect during the boot stage, since the normal state of a POST'ed COM1: port is "DTR low", until the boot code initializes the serial console. One of the idiotic things a number of people have wanted in the past is the ability to disable FreeBSD and BIOS boot messages, but still put out boot indications on the serial "console", which was not in fact the OS console. The answer to this is that when you are running the BIOS POST memory test, the only way to achieve this is with a BIOS hack, since the memory test is going to take a comparatively huge amount of time, even if you manage to hack every kernel printf into submission (not a good idea, IMO, since this is exactly what you will want to see, as an engineer, from a failed device in the field in order to diagnose the failure). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C3F3E1D.F23F9BD7>