First, I am an engineer.  I go for solutions that work and can be 
improved.  I'd sooner have something that is 99% than wait for
perfection.

Second, I've learned something already, and will get Ralph Brown's
book and think about how to use BIOS interrupts/services for our
geometry problems.

Third, I do appreciate discussion and correction.

"Charles M. Hannum" <root@ihack.net> writes:

> Um, before you folks go off and implement something weird, let me
> introduce some reality here:
No one is implementing anything wierd yet.  I thought I sent the
relevant suggestion only to you ahd Manuel to think about and discuss.

> 
> 1) ATA-4 IS NOT A STANDARD.  There is a DRAFT (available from the
>    usual location on fission.dt.wdc.com in PDF format) but it is NOT a
>    standard.
OK

> 
> 2) There are no hard disks which do not support CHS translation.  So
>    for the moment, ignore anything related to such disks.
According to ATA-4 (when it becomes a standard) disk with greater than
16Meg sectors do not have to do CHS.  So its coming.

> 
> 3) Some of the features you mention (e.g. all of wdp_cur*) do not
>    exist before ATA-2 or ATA-3, and therefore cannot just be used on
>    all devices.
We need a heuristic to tell when disk are > 8gig and then need to 
have the internals fudge a geometry that equals the capacity of the
drive.

> 
> 4) There is no standard -- or even particularly reliable -- way to
>    detect what ATA revision a device supports.  And please don't start
>    throwing suggestions at me; I asked on the ATA mailing list and
>    that was the answer I got.  (I did get a suggestion for a klugy
>    heuristic, though, which I can probably dig up.)
Good

> 
> 5) Regarding the code I `turned off': it caused a divide-by-0 fault
>    when accessing a *SCSI* disk with no MBR (which I believe I
>    documented).
I can look again too, but I didn't see anything in the log or code.
I have several machines I test on: laptops, a desktop with dual IDE drives,
a desktop with IDE and SCSI, a new dell with 10Gig IDE drive.  I did not
see problems in my test cases.  And I more than agree that any "perfect"
solution we come up with will break on some machines.  So direct feed
back to the developer is most necessary.

So this argues that the changes should be in the ATA code path not the
disklabel.  That's fine.  But putting the code there means that all
platforms that share the code get the change.  This means more
testing.

I just took a look at the scsi _get_params/getdefaultlabel/getlabel.
That is pretty wierd stuff.  I don't see how a 0 geometry parameter
could escape.  But I find the:
         if (lp->d_secpercyl == 0) {
                lp->d_secpercyl = 100;
                /* as long as it's not 0 - readdisklabel divides by it (?) */
        }
really amusing.  If I had a scsi machine with the problem, I'd look for it.
I presume that my error (0/divice) was in this part of the change to
disklabel (calculating the >8Gig geommetry), because the other code
should not be called w/o an MBR present.

> 
> The reason the wd driver always uses LBA mode when available is
> precisely to avoid the strange CHS semantics with large disks.
Right and it certainly is the way to go.