Re: ide-driver does not recognise "FUJITSU MPB3032ATU" correctly

Guest section DW (dwguest@win.tue.nl)
Wed, 27 Oct 1999 21:51:03 +0200 (MET DST)


From M.Hunold@t-online.de Wed Oct 27 20:07:26 1999

Sorry for the inconvenience. I=B4m using 2.2.10.

Good. (And also Quoted Unreadable, I see. Not so good.)

> This disk has jumpers.
> The default is 6704/15/63 but you can jumper it to 4092/16/63,
> as you probably did. The jumper settings are:

Nope. I jumpered it to 1.., just like the documentation proposes.
122

> What are the kernel boot messages? (dmesg | grep hdc)

ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio
hdc: FUJITSU MPB3032ATU, ATA DISK drive
hdc: FUJITSU MPB3032ATU, 2014MB w/0kB Cache, CHS=3D4092/16/63, (U)DMA
hdc: hdc1

> (And when you give hdparm output, give both hdparm -i and hdparm -I;
> in some kernel versions the kernel itself fiddles with the hdparm -i
> report, so that it no longer represents what the disk said.)

michael:/home/michael # hdparm -i /dev/hdc

/dev/hdc:

Model=3DFUJITSU MPB3032ATU, FwRev=3D2009, SerialNo=3D01138683
RawCHS=3D4092/16/63, TrkSize=3D0, SectSize=3D0, ECCbytes=3D4
CurCHS=3D4092/16/63, CurSects=3D4124736, LBA=3Dyes, LBAsects=3D4124736

Ok, now have a look at this. I don=B4t know why the "-I" =
parameter screws things up like this:

michael:/home/michael # hdparm -I /dev/hdc

/dev/hdc:

Model=3DUFIJST UPM3B30A2UT , FwRev=3D0290 ,
RawCHS=3D4092/16/63, TrkSize=3D0, SectSize=3D0, ECCbytes=3D4
CurCHS=3D4364/15/63, CurSects=3D4123980, LBA=3Dyes, LBAsects=3D4124736

The same in both cases, except that the model is given in BigEndian order
and -i corrects for that but -I doesnt.

And by now it is completely clear what happens on the Linux side.

The drive reports LBAsects=4124736, so it says that its total capacity
is 2.11 GB, a standard clipped capacity. Most disks only clip the CHS info
and let the operating system know the truth via LBAcapacity, but this disk
cheats on all fronts so that Linux has no way of knowing total capacity.

So, you'll have to boot with boot parameter hdc=6704,15,63.

Now this is precisely the behaviour one would expect with jumpers
set to `clip'. I am surprised that this disk still does this with
jumpers in default position.
So, I understand the Linux side but not the disk side of things.

Andries

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/