Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel.anu.edu.au!munnari.oz.au!sgiblab!sdd.hp.com!caen!destroyer!sol.ctr.columbia.edu!hamblin.math.byu.edu!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: Solution to vectra hang problem.
Message-ID: <1992Oct16.195206.21028@fcom.cc.utah.edu>
Keywords: HP, Vectra, boot, hang, copyright
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <1992Oct16.110720.12533@chx400.switch.ch>
Date: Fri, 16 Oct 92 19:52:06 GMT
Lines: 65
In article <1992Oct16.110720.12533@chx400.switch.ch> klarenbe@chx400.switch.ch (Paul Klarenberg) writes for Reinier Kleipool (Reinier.Kleipoo@HPITCB.hp.hp.400net.nl):
>The solution to the Vectra 386/20N hang after copyright.
>
> I tracked it down to a problem in pcprobe, the probe routine
>for the console. As Terry Lambert pointed out in his reply to
>my first posting a fix for the 'hang after copyright' is in the beta
>testkit. As I only have the alfa-3 version (2-sep 92) I do not know
>exactly what the fix in the beta-kit is..
> But placing a DELAY(1000) inbetween outb(KBOUTP, CMDBYTE); and
>kbd_CMD(KBC_RESET); in pcprobe (file ..../isa/pccons.c) solves the
>problem. Ok but now the *why*!
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.
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.
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.
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.
Terry Lambert
terry@icarus.weber.edu
terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
"I have an 8 user poetic license" - me
Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------