Date: Fri, 19 Jul 1996 15:42:53 -0700 (PDT) From: Jim Dennis <jim@starshine.org> To: jim@starshine.org (Jim Dennis) Cc: dwhite@resnet.uoregon.edu, jim@starshine.org, questions@FreeBSD.ORG Subject: Re: text = 0xe3000 - -- and locks: Why? Message-ID: <199607192242.PAA00328@starshine> In-Reply-To: <199607190807.BAA00642@starshine> from "Jim Dennis" at Jul 19, 96 01:07:06 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > Ugh. This is ugly. Put on the long rubber gloves and dig in... 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). This allowed me to install "Minimal" on the wd0 drive and boot successfully off of it. I was also able to mount my /dev/sd0s2a and other partitions (with "Everything" installed). However I decided that I don't really want to manually fuddle everything together on that side of the house (I was tempted to just mount and symlink the /usr/local tree but decided that I have no idea what side effects that might have). I realize that I shouldn't have to treat FreeBSD like a big monolithic system -- that it's not "all or nothing." However, I really need to see how everything fits together coming from a "clean" install before I'll feel comfortable trying to patch it all together by hand myself. 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. 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). 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. Maybe one of the kernel hacks, or David G. or Jordan H., could clarify this. I think I'll concoct a new plan for transitioning this box off of the buggy old Slackware -- where in I'll install Debian (Linux) 1.1 -- mount up my slackware partitions, xfer my data accross; blow them away -- and *then* try another install of FreeBSD. (I like to keep these system multi-boot since my machines and equipment at home are use primarily as a "lab" -- a place for me to play with OS' and freeware/shareware packages so I'll know what I'm stepping in when I recommend these to employers, clients, customers, and friends). This will work better than having to tar everything over to that little 32M DOS partition, and hope that FreeBSD doesn't have a problem getting it back from there (there doesn't seem to be an ext2fs or even a minix filesystem driver around for FreeBSD -- and my old Slackware doesn't have a ufs driver). Hopefully, I can get the Linux ufs driver running and make it "see" the FreeBSD side of the house (once I have *both* OS installed). My other working desktop system is basically busy -- so I don't want to bring it into the equation just yet. My new Pentium desktop isn't built yet (although I do have it close enough that I can boot from floppy -- so now I starting installing OS' on it starting with the obligatory little DOS partition, and adding NT 4.0 beta and then Debian and then FreeBSD). (The laptop is not an experimental/lab machine -- that's where I actually keep "work"). Maybe I pick a different hobby. Collecting stamps? Spelunking? ... Nah! Jim Dennis, Starshine Technical Services
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607192242.PAA00328>