Re: Very old IDE hard drive (240 MB) detected as 1.1 TB

Re: Very old IDE hard drive (240 MB) detected as 1.1 TB

[Robert Hancock]

(ccing linux-ide)

Hanno Böck wrote:
> I was about to shred some old hard drives. On one Hard drive, identified as:
> Conner Peripherals 240MB - CP30254
> 
> it was detected as 1.1 TB (!) and obviously throwing lots of errors after 
> getting over 240 MB.
> 
> Is this issue worth investigating further? System is ubuntu 8.10. If anyone 
> wants to have a deeper look, I can obviously donate that harddrive if you pay 
> me shipping costs.

That would be worth investigating, yes.. If you can provide the dmesg 
output from bootup, as well as the output of hdparm --Istdout on the 
disk device, that would be useful..

Re: Very old IDE hard drive (240 MB) detected as 1.1 TB

[Hanno Böck]

[-- Attachment #1: Type: text/plain, Size: 485 bytes --]

Am Freitag 13 Februar 2009 schrieb Robert Hancock:
> That would be worth investigating, yes.. If you can provide the dmesg
> output from bootup, as well as the output of hdparm --Istdout on the
> disk device, that would be useful..

That (and a bit more, normal hdparm output, smartctl output) here:
http://files.hboeck.de/conner/

(please forward to potentially interested lists)

-- 
Hanno Böck		Blog:		http://www.hboeck.de/
GPG: 3DBD3B20		Jabber/Mail:	hanno@hboeck.de

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Very old IDE hard drive (240 MB) detected as 1.1 TB

[Sergei Shtylyov]

Hello.

Hanno Böck wrote:

>> That would be worth investigating, yes.. If you can provide the dmesg
>> output from bootup, as well as the output of hdparm --Istdout on the
>> disk device, that would be useful..
>>     
>
> That (and a bit more, normal hdparm output, smartctl output) here:
> http://files.hboeck.de/conner/
>   

   It has the current capacity in words 57-58 swapped:

/dev/sdb:
0c5a 037f 0000 000a 8723 0275 0037 0030
000a 0000 2020 2020 2020 2020 2020 424d
3948 4d31 5020 2020 0003 0040 0004 302e
3336 2020 2020 436f 6e6e 6572 2050 6572
6970 6865 7261 6c73 2032 3430 4d42 202d
2043 5033 3032 3534 2020 2020 2020 8010
0000 0001 0000 0200 0202 0001 037f 000a
0037 0007 82da 0000 0000 0000 0000 0000


   It must be 82da 0007, not 0007 82da.
   IIRC, the IDE core doesn't trust the value reported in these words 
(and I have knowledge of some other old disks reporting a bogus value 
there), but liabata does (naively :-).

MBR, Sergei

Re: Very old IDE hard drive (240 MB) detected as 1.1 TB

[Mark Lord]

Sergei Shtylyov wrote:
> Hello.
> 
> Hanno Böck wrote:
> 
>>> That would be worth investigating, yes.. If you can provide the dmesg
>>> output from bootup, as well as the output of hdparm --Istdout on the
>>> disk device, that would be useful..
>>>     
>>
>> That (and a bit more, normal hdparm output, smartctl output) here:
>> http://files.hboeck.de/conner/
>>   
> 
>   It has the current capacity in words 57-58 swapped:
> 
> /dev/sdb:
> 0c5a 037f 0000 000a 8723 0275 0037 0030
> 000a 0000 2020 2020 2020 2020 2020 424d
> 3948 4d31 5020 2020 0003 0040 0004 302e
> 3336 2020 2020 436f 6e6e 6572 2050 6572
> 6970 6865 7261 6c73 2032 3430 4d42 202d
> 2043 5033 3032 3534 2020 2020 2020 8010
> 0000 0001 0000 0200 0202 0001 037f 000a
> 0037 0007 82da 0000 0000 0000 0000 0000
> 
> 
>   It must be 82da 0007, not 0007 82da.
>   IIRC, the IDE core doesn't trust the value reported in these words 
..

That's right.  I wrote the IDE code that way
*specifically* due to a (different) Conner drive
I had here at the time.

Cheers

Re: Very old IDE hard drive (240 MB) detected as 1.1 TB

[Maciej W. Rozycki]

On Sat, 14 Feb 2009, Mark Lord wrote:

> >   It has the current capacity in words 57-58 swapped:
> > 
> > /dev/sdb:
> > 0c5a 037f 0000 000a 8723 0275 0037 0030
> > 000a 0000 2020 2020 2020 2020 2020 424d
> > 3948 4d31 5020 2020 0003 0040 0004 302e
> > 3336 2020 2020 436f 6e6e 6572 2050 6572
> > 6970 6865 7261 6c73 2032 3430 4d42 202d
> > 2043 5033 3032 3534 2020 2020 2020 8010
> > 0000 0001 0000 0200 0202 0001 037f 000a
> > 0037 0007 82da 0000 0000 0000 0000 0000
> > 
> > 
> >   It must be 82da 0007, not 0007 82da.
> >   IIRC, the IDE core doesn't trust the value reported in these words 
> ..
> 
> That's right.  I wrote the IDE code that way
> *specifically* due to a (different) Conner drive
> I had here at the time.

 It happened for some Maxtor drives too.  The reason is the ATA-1 spec was 
not explicit about how words 57 and 58 were meant to be ordered and some 
manufacturers interpreted it one and some the other way.  It looks like 
libata needs to be fixed.

  Maciej

Re: Very old IDE hard drive (240 MB) detected as 1.1 TB

[Sergei Shtylyov]

Hello.

Maciej W. Rozycki wrote:

>>>   It has the current capacity in words 57-58 swapped:
>>>
>>> /dev/sdb:
>>> 0c5a 037f 0000 000a 8723 0275 0037 0030
>>> 000a 0000 2020 2020 2020 2020 2020 424d
>>> 3948 4d31 5020 2020 0003 0040 0004 302e
>>> 3336 2020 2020 436f 6e6e 6572 2050 6572
>>> 6970 6865 7261 6c73 2032 3430 4d42 202d
>>> 2043 5033 3032 3534 2020 2020 2020 8010
>>> 0000 0001 0000 0200 0202 0001 037f 000a
>>> 0037 0007 82da 0000 0000 0000 0000 0000
>>>
>>>
>>>   It must be 82da 0007, not 0007 82da.
>>>   IIRC, the IDE core doesn't trust the value reported in these words 
>>>       
>> ..
>>
>> That's right.  I wrote the IDE code that way
>> *specifically* due to a (different) Conner drive
>> I had here at the time.
>>     
>
>  It happened for some Maxtor drives too.  The reason is the ATA-1 spec was 
>   

   And with Fujitsu ones too. IIRC, the one I encountered (10+ years 
ago) had something like 0000 c000 there -- which in no way was related 
to its real capacity.

> not explicit about how words 57 and 58 were meant to be ordered and some 
>   
> manufacturers interpreted it one and some the other way.

   However, the drive vendors should've really thought better before 
reporting capacity in *middle-endian* format. :-)

>   Maciej
>   

MBR, Sergei

Re: Very old IDE hard drive (240 MB) detected as 1.1 TB

[Maciej W. Rozycki]

Hi Sergei,

> > not explicit about how words 57 and 58 were meant to be ordered and some
> > manufacturers interpreted it one and some the other way.
> 
>   However, the drive vendors should've really thought better before reporting
> capacity in *middle-endian* format. :-)

 Oh, come on!  Don't accuse everyone of thinking.  Besides, someone had to 
try that reverse-pdp-endian mode, didn't they? ;)

  Maciej

Re: Very old IDE hard drive (240 MB) detected as 1.1 TB

[Robert Hancock]

Maciej W. Rozycki wrote:
> On Sat, 14 Feb 2009, Mark Lord wrote:
> 
>>>   It has the current capacity in words 57-58 swapped:
>>>
>>> /dev/sdb:
>>> 0c5a 037f 0000 000a 8723 0275 0037 0030
>>> 000a 0000 2020 2020 2020 2020 2020 424d
>>> 3948 4d31 5020 2020 0003 0040 0004 302e
>>> 3336 2020 2020 436f 6e6e 6572 2050 6572
>>> 6970 6865 7261 6c73 2032 3430 4d42 202d
>>> 2043 5033 3032 3534 2020 2020 2020 8010
>>> 0000 0001 0000 0200 0202 0001 037f 000a
>>> 0037 0007 82da 0000 0000 0000 0000 0000
>>>
>>>
>>>   It must be 82da 0007, not 0007 82da.
>>>   IIRC, the IDE core doesn't trust the value reported in these words 
>> ..
>>
>> That's right.  I wrote the IDE code that way
>> *specifically* due to a (different) Conner drive
>> I had here at the time.
> 
>  It happened for some Maxtor drives too.  The reason is the ATA-1 spec was 
> not explicit about how words 57 and 58 were meant to be ordered and some 
> manufacturers interpreted it one and some the other way.  It looks like 
> libata needs to be fixed.

Here's the relevant code, it appears (drivers/ata/libata-core.c at line 
1321):

static u64 ata_id_n_sectors(const u16 *id)
{
	if (ata_id_has_lba(id)) {
		if (ata_id_has_lba48(id))
			return ata_id_u64(id, 100);
		else
			return ata_id_u32(id, 60);
	} else {
		if (ata_id_current_chs_valid(id))
			return ata_id_u32(id, 57);
		else
			return id[1] * id[3] * id[6];
	}
}

It looks like it's getting into the ata_id_current_chs_valid(id) path, 
since all the values that function checks are indeed valid, but the 
values in words 57-58 are not. There seems to be no real reason to use 
those values since the same can be calculated from the reported CHS, so 
you could change that code to:

		if (ata_id_current_chs_valid(id))
			return id[54] * id[55] * id[56];
		else
			return id[1] * id[3] * id[6];

Hanno, would you be able to try building a kernel with a modified 
drivers/ata/libata-core.c as above (in current -git it would be changing 
line 1330) and see if that resolves the problem?