Return to BSD News archive
Xref: sserve comp.os.386bsd.questions:2543 comp.os.386bsd.bugs:767
Newsgroups: comp.os.386bsd.questions,comp.os.386bsd.bugs
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!usc!sol.ctr.columbia.edu!hamblin.math.byu.edu!news.byu.edu!cwis.isu.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: [NetBSD] 3Com ethernet problems, misc bugs, and debugging kernels
Message-ID: <1993May18.194023.10698@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <1t69ec$bau@eagle.lerc.nasa.gov> <1t8qbr$k4a@eagle.lerc.nasa.gov>
Date: Tue, 18 May 93 19:40:23 GMT
Lines: 73
In article <1t8qbr$k4a@eagle.lerc.nasa.gov> mikef@sarah.lerc.nasa.gov writes:
[ ... trap 12 crashing ... ]
>I suppose it could help if the boot program has changed and the problem had
>to do with how things get initialized. A message from the boot program
>which I had noticed before, but hadn't really thought much about, reads
>something like this:
>
>386bsd BOOT @0x90000 639/7168K [20/9/92]
>...
>Warning: Base memory 639K, assuming 640K.
>
>Could this be the source of all my problems?
No, it couldn't be.
This message is the result of my patch for AT&T 6386 WGS and HP Vectra
systems. These machines use an option base of 0 when counting base memory,
so you end up with 0-639k rather than 1-640k. It's still 640k of memory
if it says 639. The other possibility is reservation of 4k of memory
for IDE geometry tables used by DOS (and you're not running DOS, so
trashing it is OK). This is part of the init after the kernel has
loaded, *not* part of the boot.
The default behaviour before the patch was to set the amount of memory
to -1. This gave a "ptdiXXXX>" error and the boot failed as the kernel
attempted to use non-existant memory. This was otherwise known as the
"flashing multicolor columns of characters" bug. There's an interesting
story associated with how I built a kernel when it wouldn't boot in
the first place that I won't go into right now.
The assumption is more general than necessary; a cannonical fix would
actually probe the memory on a failure so that an assumption would be
unnecessary. The very worst result of this is that the 640k of base
memory is always assumed, even if the base memory is 512k. This isn't
as bad as it seems, since 512k of base memory will result in a crash,
and that crash is not superior in any way to the crash that will come
from an invalid assumption (basically, a crash is a crash). I didn't
code a probe because of the comments in the init that said a real probe
killed some hardware, and that was the reason the CMOS was being read
in the first place.
The other thing the code does is warn you and make you hit return if you
have less than 2M of memory total, unless you set an option and recompile
the kernel. This is to warn people to not expect resonable behaviour on
crippled machines (although I have successfully run 386BSD without X in
640K on several machines without real problems).
In any case, this won't cause trap 12's normally; you are more likely
to get one of:
Trap 10 Invalid Task State Segment
Trap 11 Segment Not Present
Trap 14 Page Fault
As a result of a memory-expected-to-be-there-is-not-there error. I suggest
you look at disabling your internal or external caches (or both) to track
down the error.
If you have > 16M of memory and are using a bus mastering disk controller
in an ISA (not EISA) machine, then you will probably have to pull out enough
memory to drop yourself to 16M for the DMA to work. Adaptec and other
drivers using Julians SCSI system don't yet use bounce buffers, and thus
can have bad problems with some caching chipsets (L2 cache problems).
Terry Lambert
terry@icarus.weber.edu
---
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