Date: Fri, 19 Jul 1996 23:33:28 -0700 (PDT) From: Doug White <dwhite@riley-net170-164.uoregon.edu> To: Jim Dennis <jim@starshine.org> Cc: questions@FreeBSD.ORG Subject: Re: text = 0xe3000 - -- and locks: Why? Message-ID: <Pine.BSI.3.94.960719232825.245M-100000@gdi.uoregon.edu> In-Reply-To: <199607192242.PAA00328@starshine>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 19 Jul 1996, Jim Dennis wrote: > I did figure out at least part of the problem. All I had > to do was change this machine's CMOS setup value for > "Scratch RAM" (which I guess was AMI's term for XBDA or EBDA -- > "extended BIOS data area" back in '90). Hm. Your explanation of this reminds me of a discussion a while back that touched on the same idea, where a BIOS would suck up 1k of system RAM to store the IDE data. I think it as Dave and Jordan talking about the biosboot system, but it's interesting that FreeBSD trips on it. File that one away... > This allowed me to install "Minimal" on the wd0 drive and > boot successfully off of it. Cool. > I still can't boot sd(1,a) or sd(0,a) or hd(1,a) in any > variation. I haven't tried a fresh install over there > although I might, later. Interesting. They may just need to be reinstalled from scratch. Note that some BIOSs will only map the first two disks in the system and only allow you to boot from those disks. That is a BIOS limitation on the number of disks (0x80 and 0x81). > > Anyway. It looks like FreeBSD didn't like this machine's > default way of dealing with the XBDA (info about 2nd LPT > ports and 3rd and 4th serial ports IIRC). The options were > "use the BIOS stack area at 0000:0030" (???) -- the default, > or "use 1K of address space in 'conventional' memory" > (the option that works). That would be it. The BIOS Stack data bit was also mentioned in the above discussion as the real way the IDE data should have been placed. It all comes back :) > I haven't had to think about an XBDA in years. My guess > is that the system boot loader was overwriting part of > the XBDA while the processor was still in real mode (and > the software is dependant on the BIOS to drive the DMA) -- > and this was causing the lock up. Booting off the floppy > was probably overwriting the same area -- but that HD's > DMA was affected, not the floppy's -- by the time the > HD was needed the processor was in protected mode -- and > the kernel's 32-bit drivers are responsible for all I/O. I think it was that biosboot couldn't read the disk data, and so couldn't read the disk data to boot off of. Putting it at 1k is the old PC way and the way FreeBSD expects it. > Maybe I pick a different hobby. Collecting stamps? Spelunking? > ... Nah! :-) PCs: it isn't just a job, it's an adventure. :-) Glad you got it resolved. Doug White | University of Oregon Internet: dwhite@resnet.uoregon.edu | Residence Networking Assistant http://gladstone.uoregon.edu/~dwhite | Computer Science Major
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSI.3.94.960719232825.245M-100000>