Date: Sat, 21 Jan 95 16:21:05 MST From: terry@cs.weber.edu (Terry Lambert) To: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes) Cc: freebsd-hackers@FreeBSD.org Subject: Re: More serial console stuff... Message-ID: <9501212321.AA00703@cs.weber.edu> In-Reply-To: <199501210716.XAA02826@gndrsh.aac.dev.com> from "Rodney W. Grimes" at Jan 20, 95 11:16:27 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > How can the SCSI disk be accessed, unless it has installed its bios, in > > which case the IDE disk BIOS is not active? > > IDE disks do not require any special BIOS support. We can not boot from > a disk that has not had BIOS support installed via int 13 hooking. This is not true. There *must* be code to actually *do* something when you do an int-13 call. Even if this is the *default* code, the int-13 vector is hooked in order to instantiate the code. That you can only have one hook or the other is the whole crux of the problem. > > The one scenario I can see this failing is on a boot to a device that > > DOS thinks is device 0 but BSD thinks is device 1 because it probes > > both controllers regardless of which BIOS is active. > > Take a system with 1 IDE drive and n SCSI drives. > DOS drive BSD drive BSD unit rootdev(maj,min) > 0x80 wd0 0 0,0 > 0x81 sd0 0 4,0 > 0x82 sd1 1 4,1 > ... > > Now make it more complicated, 2 IDE drives, n SCSI drives: > 0x80 wd0 0 0,0 > 0x81 wd1 1 0,1 > 0x82 sd0 0 4,0 > 0x83 sd1 1 4,1 > > The current code can handle booting from either wd0 or sd0 in > the first case. It can only boot from wd0 or wd1 in the second > case. OK, I definitely agree with most of this, only your first example is flawed... 1) The BIOS does the boot by making INT 13 calls following the POST. 2) The INT 13 hook active is *either* the wd0/1 hook *or* the sd0/1 hook. 3) In the first case, you can *only* boot from the wd controller *or* the sd controller. Both BIOS hooks to INT 13 can *not* be active simultaneously. 4) Your DOS drive numbering is invalid, unless the post-boot OS hacks the INT 13 vector with something more than simple BIOS code -- specifically, an INT 13 redirector that does DOS drive number translation before calling the previous-to-load POST initialized INT 13 vector, if the drive number is less than or equal to 0x80 OR'ed with the number of drives (option base 0). Admittedly, the Adaptec supplied drivers for use in the config.sys file will do this, but they require that you disable the Adaptec BIOS and load DOS first from the wd controller. > The current code is broken in some respects, and the above change > also breaks some things. I think the break is a result of device probe precedence. The issue is determining which controller is the one that had the INT 13 that loaded the boot code hooked. If you look at the pfdisk code, the day to do this is to probably ask for the actual drive geometry instead of the translated geometry, and then start comparing geometries post kernel load (in the kernel code itself) to determine which if the controllers that probed as present was in fact the controller that acted as the boot device. The failure mode introduced by this is when you have multiple SCSI controllers, only one with BIOS enabled, with identical drives in the drive position order of the boot device on one of the controllers. This is a failure to identify the boot device, and once again becomes an issue of probe order (although that issue is then a soft-probe issue and has more to do with which controller line is first in the kernel configuration. The controller with the BIOS enabled should be probed first. A potential outside possibility also exists that you will configure the DOS drive numbers 0x80 and 0x81 to other than the sequentially first and second devices on a particular SCSI controller. I suppose you could argue that one might want to do this to get around the BIOS drive limits to cause more than two possible boot devices. One would think, in that case, that the boot device disklabel would encode its own SCSI ID to help guard against the possiblity, and to allow for user modification of the data, if all else fails. Most of the above consist of fallback options for a user who is hell bent on confusing the code and will go to any lengths to achieve that goal. 8-). > > If this is the case, I thoght that it had been taken care of already > > by causing the SCSI controller to probe prior to the WD controller? > > It is not a matter of probe order, it is a matter of what value gets > passed to locore.s as the bootdev. Well, I think probe order has something to do with which device the kernel gets when it dereferences the drive table using that device ID. 8-). > > Which do you mean? > > Seems like a probe order problem. > > The real crux of the problem is how to map BIOS unit numbers to > rootdev/bootdev devices numbers for the kernel. The current code does > not work quite right, nor does the above proposed hack really fix the > problem. I can agree with this statement, and would probably go further and say that there *will* be some cases that are impossible to resove, simply because the user has out clevered themself. To do this, they will have had to overcome the safeties by understanding them and actively subverting them, or by trying to pack too much complexity into their system configuration, resulting in more portential boot devices and a more complex kernel configuration than is even possible without using custom kernels (in which case it was their responsibility to deal with the problem in their kernel config). Now if we could only replace the hardware boot loader... 8-). Terry Lambert terry@cs.weber.edu --- 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?9501212321.AA00703>