[lkml]   [2003]   [Mar]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: ide-problem still with 2.4.21-pre5-ac1
    On Sat, Mar 08, 2003 at 05:28:10PM -0500, Bill Davidsen wrote:
    > On Thu, 6 Mar 2003 wrote:
    > > * 1. CHS value set by user (whatever user sets will be trusted)
    > > * 2. LBA value from target drive (require new ATA feature)
    > > * 3. LBA value from system BIOS (new one is OK, old one may break)
    > > * 4. CHS value from system BIOS (traditional style)
    > >
    > > I think that the priority of LBA from BIOS has to be raised to 2 and the
    > > priority of LBA from drive should be lowered to 3.
    > > The mapping-problem only appreared with very new drives in some
    > > brand-computers using a 240-head mapping from the bios.
    > I think the chances of a drive knowing its own correct LBA info is far
    > better than the BIOS getting it right. Many BIOS versions don't understand
    > large drives.

    Maybe time for some preaching again.

    The above sounds like nonsense,
    "its own correct LBA info" does not refer to anything.

    A disk that is less than twelve years old does not have a geometry.
    All disks that can handle LBA (that is, all disks less than
    twelve years old) use LBA under Linux.
    Thus, the disk has nothing to tell use except for its total capacity.

    Some silly legacy stuff is interested in a geometry.
    It does not exist, but everybody can invent something,
    Why would one do such a silly thing? Well, the DOS-type partition
    table has fields that are expressed in terms of cyl/heads/secs,
    and these are used by DOS. If one really uses DOS on the same
    disk, then one needs the BIOS values, since DOS uses the BIOS.

    On a Linux-only system there is never any problem, provided
    one can boot. Don't panic if some ancient fdisk version
    mumbles about unexpected things.

    Usually people that complain only think they have a problem,
    while in fact all is well. Or they have a problem: the BIOS
    cannot handle the disk and does not boot, but that is not a
    Linux problem.

    Now what about Harald.Schaefer's problem? I asked Google
    for his complaint and find

    "We create fdisk partitions with linux and run later DOS
    from one of these partitions. DOS gets confused about the
    linux mapping of the partition that is different from the
    BIOS supplied values."

    Now guessing what the BIOS will do is a black art,
    and if "kernel 2.2.22 was running fine" it was lucky.
    I see that 2.4.21-pre5 overrides in many cases what
    the BIOS said, so it will be lucky less often.
    But one can always specify an explicit geometry to fdisk.
    (And find out what to say by inspecting the BIOS setup
    screen under "autodetecting hard disks".)

    Finally, on the shown hdparm output:

    and a bad disk, which is recognized with "bit shift"-mapping from the BIOS:

    hdparm -i /dev/hda
    Model=Maxtor 6E040L0, FwRev=NAR61590, SerialNo=E11G00EE
    RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
    CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=78165360

    hdparm -I /dev/hda
    CurCHS=65535/1/63, CurSects=4128705, LBA=yes, LBAsects=78165360

    another disk that doesn't work

    hdparm -i /dev/hda
    Model=FUJITSU MHR2030AT, FwRev=53BB, SerialNo=NJ36T2813MYW
    RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
    CurCHS=17475/15/63, CurSects=16513875, LBA=yes, LBAsects=58605120

    hdparm -I /dev/hda
    Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
    RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
    CurCHS=65535/1/63, CurSects=4128705, LBA=yes, LBAsects=58605120

    Really strange values, as if someone wanted to force a H=255.
    Must read current 2.4 source some time. What does hdparm say
    under 2.2.22?


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:33    [W:0.060 / U:6.128 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site