Lockups related to (possibly IDE issues) ?
dillon at apollo.backplane.com
Sat Sep 9 10:48:48 PDT 2006
:if I set BIOS to "autodetect" and it finds a geometry that is obviously
:incorrect, is there any danger of having the physical device damaged? (is the
:microcode in a hard drive smart enough to avoid doing things that are
:physically dangerous?) If I can be sure of this, I'd try different settings
:there and see what happens.
:Does dragonflybsd pay attention to BIOS's idea of the hard drive geometry, even
:after the booting stage? It's getting well past the bootblocks.
DragonFly uses 'packet mode' BIOS commands, which are independant of the
The problem is that the BIOS still screws up even packet mode requests,
and if you leave it in 'Auto' mode it seems to be able to put the disk
into some sort of crazy mode that BSDs can't seem to get it out of,
resulting in an inability to access the whole disk.
Basically you need to program the BIOS to access the disk in LBA or LARGE
mode. If you leave it in Auto the BIOS will mess everything up.
I would love to know how to 'fix' our ATA controller to fix the
access problem when the BIOS misprograms the drive. A RESET doesn't
seem to do it.
Insofar as cabling goes, you basically must be sure that the hard drive
is set up as the IDE master and that the CDROM is set up as the IDE
slave. If you have a twisty-cable, then things get more complicated
because the two device connectors on the cable act differently (sometimes
even if the drive or CDRom is jumpered explicitly for master/slave).
I recommend *NOT* using a twisty cable. Just use a straight-through
cable (both connectors on the cable act the same) and jumper the drive
as a master and the CDROM as a slave. Put the drive on the END of the
cable, not the middle (this is because IDE hard drives almost always
terminate the cable properly while many CDROM drives do not, and this
is important at higher IDE speeds).
:How come Dragonfly uses vixiecron instead of Dillon Cron? :-) (I always remembered
:you as "that cron guy" before this, the cron that does cron and ONLY cron.)
Someone else posted the exerpt from a posting I made a while ago, which
is still essentially true today. Users depend on the environment variable
support, shell specification, and boot-time job specifications that
DCron does not have. If someone were to add those features to DCron and
we made some minor adjustments to the spool directories, we could use
dcron in the base system instead of vixiecron.
More information about the Bugs