Date: Fri, 20 Jan 1995 23:16:27 -0800 (PST) From: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com> To: terry@cs.weber.edu (Terry Lambert) Cc: freebsd-hackers@FreeBSD.org Subject: Re: More serial console stuff... Message-ID: <199501210716.XAA02826@gndrsh.aac.dev.com> In-Reply-To: <9501210532.AA14456@cs.weber.edu> from "Terry Lambert" at Jan 20, 95 10:32:44 pm
next in thread | previous in thread | raw e-mail | index | archive | help
[CC list trimmed back to hackers] > > > >> part = 0; > > > >> unit = (drive & 0x7F); > > [ ... ] > > > I haven't actually looked, but the one that may fail is the case of hd(1,a) > > when a SCSI disk is co-configured with an IDE disk. > > in this case it needs to pass a 1 to the bios to boot, but a 0 to the > > kernel (it's sd0 after all isn't it). > > If that still works, then sure.. make the change.. > > 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. > 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. The current code is broken in some respects, and the above change also breaks some things. The special nomenclature hd(N,p) was meant to fix some of this, but falls short. > This is actually the opposite of the case you made. > > THis setup would require the user to explicitly go into the SCSI setup > and tell it whether or not to hook the INT 13 vectors on POST. For > an Adaptec controller, this is equivalent to explicitly enabling and > disabling the SCSI BIOS between boots. We can only boot from INT 13 devices, that should remain the same, otherwise you have to start putting drivers into the boot blocks and that gets ugly in a hurry. > 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. > One might also see it happening when you have multiple SCSI, one without > BIOS -- say a normal controller and a sound card. Multiple scsi controllers gets even more complicated. > 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 think we can fix this by making the way hd(X,y) works slightly different, and using something like the above change. The hd(X,y) device should be biased by 2 on the unit number for units >=2. > Terry Lambert > terry@cs.weber.edu -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199501210716.XAA02826>