*BSD News Article 2597


Return to BSD News archive

Newsgroups: comp.unix.bsd
Path: sserve!manuel!munnari.oz.au!uunet!europa.asd.contel.com!darwin.sura.net!wupost!sdd.hp.com!zaphod.mps.ohio-state.edu!uwm.edu!rpi!greg
From: greg@ecse.rpi.edu (Greg)
Subject: Re: 386bsd-0.1: primary bootstrap (wdbootblk.c) problem & fix.
Message-ID: <greg.712267214@hibp1.ecse.rpi.edu>
Keywords: 386bsd boot bootstrap wdbootblk.c
Nntp-Posting-Host: hibp0.ecse.rpi.edu
References: <greg.712111605@hibp1.ecse.rpi.edu> <1992Jul27.172708.3363@gateway.novell.com> <greg.712261295@hibp1.ecse.rpi.edu> <1992Jul27.192502.15727@gateway.novell.com>
Date: Mon, 27 Jul 1992 20:00:14 GMT
Lines: 29

terry@npd.Novell.COM (Terry Lambert) writes:

>In article <greg.712261295@hibp1.ecse.rpi.edu> greg@ecse.rpi.edu (Greg) writes:
[ stuff deleted ]
>however, the status register being polled after the delay is wd_status,
>and I still believe that a canonical fix would be looking at wd_altsts
>instead.

  When I first read about the other patch, I did try checking wd_alsts
rather than wd_status. Not knowing didley about the disk controller,
I'm not sure what the difference between these two registers are. 
But, being a shameless hacker, I tried it anyway. Alas, this was no 
help. It was at this point that I resorted to my ugly hack.
  It may be that the wrong register is checked. If so, then there is also
another problem. I'm sure someone more knowledgeble than I will shed some light on this situation soon.   

>	The confusion seems to have originated from the various paths in
>the boot and non-boot sections of the kernel which lead to files of the
>same name.  I would suggest that any future patches refrain from the use
>of relative paths to identify the file being patched.  In particular, it
>would be nice if they contained the full path from the root of the volume
>("/") rather than something like "./xxx/yyy/zzz.c", which assumes they are
>starting in the same directory that patch poster did.

  Point well taken. In the future I will use full paths, in order to
avoid confusion. This sounds like a policy that everyone should follow.

            -Greg               greg@megas.ecse.rpi.edu