holy cow.
of all the times NOT to post a dmesg!  (and fdisk output).  It
probably wouldn't help diagnose the problem, but it would be cool to
see. :)  Obviously, you got a PIII machine with ISA slots, not the
most common of beasts (though they certainly exist).  (actually, the
dmesg would probably just show "wdc0 at ... ", but it would be kinda
cool to know that it was REALLY a wdc, not a low-end IDE interface
pretending it was an AT controller).

Heh. It does. I'll have to remember to save copies when I finally get all this working. :)

And the machine is a Dell Dimension with one PCI/ISA shared slot.

I think you need to go back to a P1 (or maybe some PII?) system before
you will find one with manual drive parameter selections.  That will
lead to another problem, very, very very few of those will allow you
to directly boot from the secondary controller.  HOWEVER, you may be
able to set the primary controller to the IDE, and put your MFM
controller as secondary (many of the original ones had such a jumper)
and be set, or install a SCSI controller and drive and use a boot
floppy to boot from hd1a:/bsd...

Yeah, I found it rather odd that it would do that in the first place. I think what's happening is the BIOS can tell there's a controller there, but then it doesn't recognize the drive as something bootable, so it goes to the next hd. The 90 MHz Pentium I tried was, well, highly bizarre. For example, the IDE jumpers were labeled 'PCI IDE' and 'ISA IDE'... and even with the IDE turned off in the BIOS, and a drive attached to the 'ISA IDE', it attempted to boot from that drive, which gave me a dmesg including wdc0 @ pci0.

Oh, and I have no docs on the controller, and haven't found any online, and the (many) jumpers are unlabeled. So unfortunately... Yeah. Plus, the controller is physically HUGE (lengthwise). Not all of the machines I've tried can even get it into a slot.

(Just found this... Looks pretty similar. http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=250157575469 )

As you have probably (re)discovered, the OS takes its cues on the
drive geometry from the BIOS.  On modern IDE drives, it just doesn't
matter, but on an MFM drive, head 3 was really head 3, cylinder 138
was really cylinder 138, and there were 17 sectors on each track, and
where the OS requested is where the controller placed the drive and

Yes. 615/4/17, although I've also seen 616 mentioned (it's an ST225 with no values on the label). The partition ends at 613 (i.e. 614th cyl), and I think the last track is the landing zone, so I'm going to go with 615 if I can get to that point...

where the data came off, so yes, it really needs to be "right".  Yes,
source could probably be modified to hard-code this in the OS, but
getting it right would be "interesting"...and very much in untested
code paths, I suspect.

Well, on the one hand this seems like something you should be able to shoot yourself in the foot with if you really want, not to mention another way to be BIOS-agnostic. On the other, this is about the only time it would ever matter, so I guess the kernel doesn't need the added complexity of a way to change it...

good luck, I'm curious how it all works out...

Well, I can post the dmesg and fdisk when I get there. :)

Thanks.

Reply via email to