Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel.anu.edu.au!munnari.oz.au!spool.mu.edu!agate!dog.ee.lbl.gov!news!nosc!crash!fpm
From: fpm@crash.cts.com (Frank Maclachlan)
Subject: Re: Solution to vectra hang problem.
Organization: CTS Network Services (crash, ctsnet), El Cajon, CA
Date: 18 Oct 92 18:48:30 PDT
Message-ID: <1992Oct18.184830.5845@crash>
Keywords: HP, Vectra, boot, hang, copyright
References: <1992Oct16.110720.12533@chx400.switch.ch> <1992Oct16.195206.21028@fcom.cc.utah.edu>
Lines: 89
In article <1992Oct16.195206.21028@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
>I've speculated on this in the past, so no loss of grace for speculating
>again...
>
>I think it isn't the problem at all. I think that the delay buys you the
>time necessary for the disk controller to come ready, and the lack of
>a check for the appropriate status register in the original code is
>causing the problem. The "fix" appears to "repair" a problem in the
>keyboard code, when in reality, it's giving some more time for the
>drive controller to come ready after bus reset.
Not in the case of my system (AMD 386/40 Hong Kong clone MB, OPTi chip set,
64 kb cache). The hangup occurs in the while loop in the following
snippet of code from pcprobe() in /sys/i386/isa/pccons.c (line 175):
/* Start keyboard stuff RESET */
kbd_cmd(KBC_RESET);
while((c = inb(KBDATAP)) != KBR_ACK) {
if ((c == KBR_RESEND) || (c == KBR_OVERRUN)) {
if(!again)printf("KEYBOARD disconnected: RECONNECT \n");
kbd_cmd(KBC_RESET);
again = 1;
}
}
When I boot the system w/ the stock pcprobe() code, I see the copyright
message and nothing else. The next thing that should be displayed (but
isn't) is something like:
pc0<color> at 0x60 irq 1 on isa
The above message is printed by config_isadev() (in /sys/i386/isa/isa.c)
right after calling pcprobe(). Just to be sure, I added a printf after
the while loop and never saw its output. If you see the copyright message,
but don't see the pc0<... message, you are almost certainly stuck in the
above while loop. No disk I/O is going on here!
>For evidence of this, I'll point out that when a controller doesn't have
>to worry about the floppies, (ie: install 386BSD and unplug your floppy
>drives from the controller) the boot appears to work normally.
You may correct in this case. My system doesn't boot w/ the original
keyboard reset code no matter how much I fiddle w/ the hardware.
>This is not to say that the keyboard code isn't bogus, especially with
>the older keyboard design.
>
>There are two keyboard hardware configurations: one has a controller chip
>in the keyboard itself and the other has the chip living on the motherboard.
>That's why new keyboards don't work with old old boces.
Hmmm... Every AT clone I've looked at has a keyboard controller chip
(usually an 8042) on the motherboard and every AT compatible keyboard
I've opened up (quite a few) has also had a microcontroller. In any
case, I haven't seen any problems when using new keyboards w/ a vintage
1984 IBM AT.
>The code to fix the "bogus" reset/attach was posted here about a week ago,
>and it should probably replace the delay code. If you didn't save the
>posting, Reinier, I can mail it to you. No one has responded to the
>suggestion that this should be tried as a replacement for the delay code on
>a machine that boots only with the delay code in place, and the experiment
>needs to be done (unfortunately, all my hardware now works, so I have a
>hard time reproducing bugs like this).
>
>> The routines kbc_8042cmd() and kbd_cmd() in pccons.c only test if the
>>command has been removed from the inputregister of the controller. They do
>>not test that the command finished executing inside the controller. So I
>>think the problem is that the keyboard controller locks up because two
>>commands are given too soon after each other.
>
>I believe the newer attach code addresses exactly this problem. If so, it is
>undoubtedly more elegant than the patch I put in the patch kit. I put the
>workaround in the kit rather than wait for the "real fix" because, as
>several people correctly pointed out, a workaround is better than nothing
>if you have a problem.
I replaced the reset code w/ the above-mentioned "real fix", recompiled
the kernel, copied the new kernel onto a bootable 386BSD floppy, rebooted
from the floppy, saw the copyright message (no pc0... message), and waited,
and waited, and then hit the reset button. If someone can suggest where
I can obtain *good* information on how AT keyboard controllers work, I'll
gladly take a whack at rewriting pcprobe(). I have the IBM AT Technical
Reference Manual, but find the description therein singularly opaque.
--
UUCP: {hplabs!hp-sdd ucsd nosc}!crash!fpm
ARPA: crash!fpm@nosc.mil
INET: fpm@crash.cts.com