Lockups related to (possibly IDE issues) ?

[Matthew Dillon]

:...
: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
    drive geometry.

    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).


:Totally unrelated...
:
: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.)
:
:Jamie

    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.

						-Matt