Date: Wed, 6 Mar 1996 11:07:25 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jerry@border.com (Jerry Kendall) Cc: pattersonj@vncgate1.vnc.aetc.af.mil, questions@freebsd.org Subject: Re: SCSI Controller suupport Message-ID: <199603061807.LAA11393@phaeton.artisoft.com> In-Reply-To: <96Mar6.092205est.20481-1@janus.border.com> from "Jerry Kendall" at Mar 6, 96 09:10:50 am
next in thread | previous in thread | raw e-mail | index | archive | help
> I have the 1520 controller at home and it works great.... > > However, I added it to an existing system and my system > boots of an IDE 'C' drive..... > > FWIW. > > On Wed, 6 Mar 1996 pattersonj@vncgate1.vnc.aetc.af.mil wrote: > > > > > > > I purchased a copy of the Free BSD 2.0 from Walnut Creek. > > > > I'm having a little trouble installing it. Does this release support the > > Adaptec 1520h series of SCSI controllers. I have an old Unisys PW2 > > box that has this controller built-in on the motherboard. > > > > When trying to intall, it can't get past the boot disk. The system panics > > and begins > > writing the number 27 across the screen. I think it's the controller. These controllers are typically on things that don't have INT 13 BIOS ROMs and so are not usable as boot devices (since BIOS POST uses INT 13 to load the master boot record or "MBR"). Most likely, the motherboard you have has an INT 13 BIOS capable of driving this controller (only choice if it's the only controller and the thing is capable of booting DOS at all). I suspect that one of three things is going wrong: 1) You have the IRQ, I/O, or base address wrong on the card; it doesn't match the kernel. This is likely because the default boot device is usually on IRQ 13 or 14, and the controller is searched as if it were an auillary controller, not a primary device. If you know all the controller settings for the 1520h on the board, then you can boot FreeBSD "-c" and set up the driver settings to make the controller happy. Be sure and disable other disk controllers, since there may also be a probe conflict (as before, this is not a typical boot device, so its health was not a consideration in writing the probe code for controllers that *are* typical). 2) The boot sequence loads a BIOS image or otherwise uses a memory area for the controller that the BSD boot bloack loads on top of, destroying the BIOS's ability to talk to the controller before it gets the kernel all the way in If this is happening, you would have to hack the first and second stage boots and the BSD load address (ie: you would need an already working controller and system on which to build releases to retry them). 3) The probe code does not expect the controller to be active (after all, it isn't a traditional bootable device), and so the probe code fails to find the controller, even though all of the criteria in #1 (above) have been met correctly. If this is the case, you will need to install an alternate controller in the system and modify the probe until it works; this will be a messy process and will require programming information about the controller and motherboard. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603061807.LAA11393>