Date: Mon, 23 Jan 95 9:37:28 MST From: terry@cs.weber.edu (Terry Lambert) To: bde@zeta.org.au (Bruce Evans) Cc: rgrimes@gndrsh.aac.dev.com, freebsd-hackers@FreeBSD.org Subject: Re: More serial console stuff... Message-ID: <9501231637.AA08367@cs.weber.edu> In-Reply-To: <199501220547.QAA31999@godzilla.zeta.org.au> from "Bruce Evans" at Jan 22, 95 04:47:34 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> I thought the example was a real one. It's easy for the sd driver to > make it work, e.g.: > > unit = drive & 0x7f; > if (unit > max_sd_unit) /* max_sd_unit = min_sd_unit > * + nr_sd_units - 1 */ > return ERROR; > if (unit < min_sd_unit) /* min_sd_unit = number of drives > * at the time we hooked */ > jumpto(saved_vector); /* restore regs and continue with > * the driver that owned INT 0x13 > * at the time we hooked */ > unit -= min_sd_unit; /* actual SCSI unit number */ > > Whether the bootstrap can determine all the mappings done by all the > hooked drivers is another question. Begging your and Rods pardon, but the issue is not where the current code works, it's where it doesn't. The installations that are falling flat are the ones that need fixed. Generally, this has fallen into two categories: the first is the case of multiple controllers, where it is still possible to misinterpret the drive ID passed from the boot blocks because the probe order does not match the chain order (if the BIOS on the second device even supports chaining, and yes, many apparently do). The second is where the geometry is guessed wrong and incorrect disklabel information is generated, either because it isn't passed correctly, or because of LCF used in the calculation (the latter is the EIDE problem). > >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 > > DOS is not involved, except for the special version of the bootstrap > that boots from DOS. Complicated redirections are just more likely > if DOS has been used to load special drivers. I should have said "BIOS" or "no protected mode OS" drive numbering instead of singling out DOS... unless you see some way to determine the BIOS chaining order that was used to generate the drive ID so that that ID may be interpreted unambiguously by the kernel's protected mode driver. For example, say I have no built in controller in the system and two SCSI controllers that support chaining. Each SCSI controller has two identical drives on it. The kernel is loaded via BIOS and is passed drive ID 0x82. On which controller does this drive reside? The actual residence of the drive is determined by BIOS chaining order. The apparent-to-the-kernel residence of the drive is dependent on the controller probe order. Now do you see what I mean? 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?9501231637.AA08367>