HPA and failed opcode was: 0x37 ?

HPA and failed opcode was: 0x37 ?

[Steven Scholz]

Hi all,

I get the following lines when starting my ide driver:

Probing IDE interface ide0...
hda: probing with STATUS(0x50) instead of ALTSTATUS(0xff)
hda: ST940813AM, ATA DISK drive
ide0 at 0xc3866000-0xc3866007,0xc3866010 on irq 30
hda: max request size: 1024KiB
hda: Host Protected Area detected.
        current capacity is 78140160 sectors (40007 MB)
        native  capacity is 185074430006016 sectors (94758108163 MB)
hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
hda: task_no_data_intr: error=0x04 { DriveStatusError }
ide: failed opcode was: 0x37
hda: 78140160 sectors (40007 MB) w/8192KiB Cache, CHS=16383/255/63
hda: cache flushes supported
 hda: hda1


My quetsions are:

1. what's that 185074430006016 sectors native capacity about?
2. Opcode 0x37 seems to be WIN_SET_MAX_EXT.
   What does it mean if it fails?

Thanks a million.

(I am uisng linux 2.6.14 on an embedded ARM9 system.)

Steven

Re: HPA and failed opcode was: 0x37 ?

[Steven Scholz]

Steven Scholz wrote:
> Hi all,
> 
> I get the following lines when starting my ide driver:
> 
> Probing IDE interface ide0...
> hda: probing with STATUS(0x50) instead of ALTSTATUS(0xff)
> hda: ST940813AM, ATA DISK drive
> ide0 at 0xc3866000-0xc3866007,0xc3866010 on irq 30
> hda: max request size: 1024KiB
> hda: Host Protected Area detected.
>         current capacity is 78140160 sectors (40007 MB)
>         native  capacity is 185074430006016 sectors (94758108163 MB)
> hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: task_no_data_intr: error=0x04 { DriveStatusError }
> ide: failed opcode was: 0x37
> hda: 78140160 sectors (40007 MB) w/8192KiB Cache, CHS=16383/255/63
> hda: cache flushes supported
>  hda: hda1
> 
> 
> My quetsions are:
> 
> 1. what's that 185074430006016 sectors native capacity about?

Sectors written in hex:
current capacity is 78140160 sectors would be		0x000004A85300
native  capacity is 185074430006016 sectors would be	0xA852FFA85300

Any clues?

--
Steven

Re: HPA and failed opcode was: 0x37 ?

[Eric D. Mudama]

On 1/30/07, Steven Scholz <steven.scholz@imc-berlin.de> wrote:
> > hda: Host Protected Area detected.
> >         current capacity is 78140160 sectors (40007 MB)
> >         native  capacity is 185074430006016 sectors (94758108163 MB)
> > hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
> > hda: task_no_data_intr: error=0x04 { DriveStatusError }
> > ide: failed opcode was: 0x37
> > hda: 78140160 sectors (40007 MB) w/8192KiB Cache, CHS=16383/255/63
> >
> > My quetsions are:
> >
> > 1. what's that 185074430006016 sectors native capacity about?
>
> Sectors written in hex:
> current capacity is 78140160 sectors would be           0x000004A85300
> native  capacity is 185074430006016 sectors would be    0xA852FFA85300

0x37 is READ NATIVE MAX ADDRESS EXT, which is the 48-bit version of
the command to figure out how big the drive "really" is.  It appears
that model of drive indicated support for 48-bit commands, but then
aborted the 48-bit version of READ NATIVE MAX ADDRESS.

Is it really a 40GB drive?

--eric

Re: HPA and failed opcode was: 0x37 ?

[Eric D. Mudama]

On 1/30/07, Eric D. Mudama <edmudama@gmail.com> wrote:
> 0x37 is READ NATIVE MAX ADDRESS EXT, which is the 48-bit version of
> the command to figure out how big the drive "really" is.  It appears
> that model of drive indicated support for 48-bit commands, but then
> aborted the 48-bit version of READ NATIVE MAX ADDRESS.

Er, oops, 0x27 is the read.  0x37 is the "SET MAX ADDRESS EXT" ...
would appear your drive has a host-protected area or is in the
set_max_locked/set_max_frozen state.

There's nothing functionally to worry about, but maybe your BIOS has
decided to protect part of the drive?

Re: HPA and failed opcode was: 0x37 ?

[Steven Scholz]

Eric D. Mudama wrote:
> On 1/30/07, Eric D. Mudama <edmudama@gmail.com> wrote:
>> 0x37 is READ NATIVE MAX ADDRESS EXT, which is the 48-bit version of
>> the command to figure out how big the drive "really" is.  It appears
>> that model of drive indicated support for 48-bit commands, but then
>> aborted the 48-bit version of READ NATIVE MAX ADDRESS.
> 
> Er, oops, 0x27 is the read.  0x37 is the "SET MAX ADDRESS EXT" ...
> would appear your drive has a host-protected area or is in the
> set_max_locked/set_max_frozen state.

Well as the kernel log mentioned there is a HPA:

hda: Host Protected Area detected.
        current capacity is 78140160 sectors (40007 MB)
        native  capacity is 185074430006016 sectors (94758108163 MB)

> There's nothing functionally to worry about, but maybe your BIOS has
> decided to protect part of the drive?

What is the "SET MAX ADDRESS EXT" used for?

Steven

Re: HPA and failed opcode was: 0x37 ?

[Steven Scholz]

Eric,
 D. Mudama wrote:
> On 1/30/07, Steven Scholz <steven.scholz@imc-berlin.de> wrote:
>> > hda: Host Protected Area detected.
>> >         current capacity is 78140160 sectors (40007 MB)
>> >         native  capacity is 185074430006016 sectors (94758108163 MB)
>> > hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
>> > hda: task_no_data_intr: error=0x04 { DriveStatusError }
>> > ide: failed opcode was: 0x37
>> > hda: 78140160 sectors (40007 MB) w/8192KiB Cache, CHS=16383/255/63
> 
> 0x37 is READ NATIVE MAX ADDRESS EXT, which is the 48-bit version of
> the command to figure out how big the drive "really" is.  It appears
> that model of drive indicated support for 48-bit commands, but then
> aborted the 48-bit version of READ NATIVE MAX ADDRESS.
> 
> Is it really a 40GB drive?

Well. It's a pretty new Seagate ST940813AM  (2.5") with "40GB" printed on it.

Steven

Re: HPA and failed opcode was: 0x37 ?

[Alan]

> hda: max request size: 1024KiB

Sane so far, LBA48 disk

> hda: Host Protected Area detected.
>         current capacity is 78140160 sectors (40007 MB)
>         native  capacity is 185074430006016 sectors (94758108163 MB)

This comes from the identify data (bit 10 of the
cfs_enable_1/command_set_1 fields in drivers ide) indicate the drive has
an HPA so we try and read it. As there is no error report it seems the
drive replied fine and we turn it into a rather bizarre value, but all our
endian and the like code appears correct here.

Is your IDE controller LBA48 capable ?

> hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: task_no_data_intr: error=0x04 { DriveStatusError }
> ide: failed opcode was: 0x37

We try and set the disk size to 185074430006016 sectors.. it objects
unsuprisingly to this proposal.

Alan

Re: HPA and failed opcode was: 0x37 ?

[Steven Scholz]

Alan,

>> hda: Host Protected Area detected.
>>         current capacity is 78140160 sectors (40007 MB)
>>         native  capacity is 185074430006016 sectors (94758108163 MB)
> 
> This comes from the identify data (bit 10 of the
> cfs_enable_1/command_set_1 fields in drivers ide) indicate the drive has
> an HPA so we try and read it. As there is no error report it seems the
> drive replied fine and we turn it into a rather bizarre value, but all our
> endian and the like code appears correct here.
> 
> Is your IDE controller LBA48 capable ?

Well TBH I have no contoller. As I said I am using an embedded ARM board.
The HDD is connected via a FPGA. The internal HDD registers simply memory
mapped. Works fine. Usually. By now we seem to have trouble with that
Seagate drive...

So I don't see any problems with LBA48 ...

>> hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
>> hda: task_no_data_intr: error=0x04 { DriveStatusError }
>> ide: failed opcode was: 0x37
> 
> We try and set the disk size to 185074430006016 sectors.. it objects
> unsuprisingly to this proposal.
;-)

Steven

Re: HPA and failed opcode was: 0x37 ?

[Alan]

> > Is your IDE controller LBA48 capable ?
> 
> Well TBH I have no contoller. As I said I am using an embedded ARM board.
> The HDD is connected via a FPGA. The internal HDD registers simply memory
> mapped. Works fine. Usually. By now we seem to have trouble with that
> Seagate drive...

The reason I ask is that the stuff which is going wrong is the stuff
which requires two fetches from the drive registers. Could that be a
caching bug (eg caching it, prefetching and thus reading a register too
many times etc) - it seems more likely than the drive given that nobody
else is seeing anything like this.

Alan

Re: HPA and failed opcode was: 0x37 ?

[Steven Scholz]

Alan wrote:
>>> Is your IDE controller LBA48 capable ?
>> Well TBH I have no contoller. As I said I am using an embedded ARM board.
>> The HDD is connected via a FPGA. The internal HDD registers simply memory
>> mapped. Works fine. Usually. By now we seem to have trouble with that
>> Seagate drive...
> 
> The reason I ask is that the stuff which is going wrong is the stuff
> which requires two fetches from the drive registers. Could that be a
> caching bug (eg caching it, prefetching and thus reading a register too
> many times etc) - it seems more likely than the drive given that nobody
> else is seeing anything like this.

Hmm. Don't think so. Since the use of ioremap() I think the MMU treats the
area as none-cacheable, right?

Steven

Re: HPA and failed opcode was: 0x37 ?

[Alan]

> Hmm. Don't think so. Since the use of ioremap() I think the MMU treats the
> area as none-cacheable, right?

Thats only the first half of the story. If you don't decode byte level
fetches in the FPGA or the code is doing something like


		read 16 bit value
		shift 8
		return half

for 8 bit reads you'll get wrong answers.

Alan

Re: HPA and failed opcode was: 0x37 ?

[Steven Scholz]

Alan wrote:
>> Hmm. Don't think so. Since the use of ioremap() I think the MMU treats the
>> area as none-cacheable, right?
> 
> Thats only the first half of the story. If you don't decode byte level
> fetches in the FPGA or the code is doing something like
> 
> 
> 		read 16 bit value
> 		shift 8
> 		return half
> 
> for 8 bit reads you'll get wrong answers.

I have connected HDD's A[2..0] to CPU's A[3..1] and do something like

        for (i = IDE_DATA_OFFSET; i <= IDE_STATUS_OFFSET; i++) {
                hw.io_ports[i] = ide_virt_base + (i << 1);
        }

thus all HDD registers are accessed on a 16bit aligned address. Thus
ide_inb() should return the correct value.
And btw are things like identify driver use 8bit transfers?

How could one then explain

current capacity is 78140160 sectors would be           0x000004A85300
native  capacity is 185074430006016 sectors would be    0xA852FFA85300

? First three bytes ok, then the other three bytes rubbish?

Steven

Re: HPA and failed opcode was: 0x37 ?

[Eric D. Mudama]

On 1/30/07, Steven Scholz <steven.scholz@imc-berlin.de> wrote:
> I have connected HDD's A[2..0] to CPU's A[3..1] and do something like
>
>         for (i = IDE_DATA_OFFSET; i <= IDE_STATUS_OFFSET; i++) {
>                 hw.io_ports[i] = ide_virt_base + (i << 1);
>         }
>
> thus all HDD registers are accessed on a 16bit aligned address. Thus
> ide_inb() should return the correct value.
> And btw are things like identify driver use 8bit transfers?
>
> How could one then explain
>
> current capacity is 78140160 sectors would be           0x000004A85300
> native  capacity is 185074430006016 sectors would be    0xA852FFA85300
>
> ? First three bytes ok, then the other three bytes rubbish?
>
> Steven

Maybe I am misunderstanding the issue, but the upper 3 bytes (and in
fact all the extended registers) of a 48-bit LBA address are found by
re-reading the taskfile registers after setting the HOB bit (bit 7) in
the device control register.  If your FPGA is simulating a taskfile
for the generic driver to read, then your FPGA will need to perform
this access on the device to simulate the extended taskfile registers.
 In the above log, your upper 3 bytes appear to be garbage.

This is documented in the description of the "48-bit Address Feature
Set" in recent ATA specifications.  Recent working draft
specifications are available from www.t13.org for anyone to browse and
download.

--eric

Re: HPA and failed opcode was: 0x37 ?

[Sergei Shtylyov]

Hello.

Steven Scholz wrote:

>>>Hmm. Don't think so. Since the use of ioremap() I think the MMU treats the
>>>area as none-cacheable, right?

>>Thats only the first half of the story. If you don't decode byte level
>>fetches in the FPGA or the code is doing something like

>>		read 16 bit value
>>		shift 8
>>		return half

>>for 8 bit reads you'll get wrong answers.

> I have connected HDD's A[2..0] to CPU's A[3..1] and do something like

>         for (i = IDE_DATA_OFFSET; i <= IDE_STATUS_OFFSET; i++) {
>                 hw.io_ports[i] = ide_virt_base + (i << 1);
>         }

> thus all HDD registers are accessed on a 16bit aligned address. Thus
> ide_inb() should return the correct value.
> And btw are things like identify driver use 8bit transfers?

    No, 8-bit transfers are used only for taskfile access. The data register 
is accessed as 16-bit.

> How could one then explain

> current capacity is 78140160 sectors would be           0x000004A85300
> native  capacity is 185074430006016 sectors would be    0xA852FFA85300
> 
> ? First three bytes ok, then the other three bytes rubbish?

    Note that they're not complete garbage but equal the value of the lower 3 
bytes minus 1. What is clear is that Read Native Max Address Ext command must 
be mistreating the HOB bit... :-)

> Steven

MBR, Sergei

Re: HPA and failed opcode was: 0x37 ?

[Eric D. Mudama]

On 1/30/07, Sergei Shtylyov <sshtylyov@ru.mvista.com> wrote:
> Steven Scholz wrote:
> > How could one then explain
>
> > current capacity is 78140160 sectors would be           0x000004A85300
> > native  capacity is 185074430006016 sectors would be    0xA852FFA85300
> >
> > ? First three bytes ok, then the other three bytes rubbish?
>
>     Note that they're not complete garbage but equal the value of the lower 3
> bytes minus 1. What is clear is that Read Native Max Address Ext command must
> be mistreating the HOB bit... :-)

These commands all just use ide_raw_taskfile(), there's nothing
special about READ NATIVE MAX ADDRESS EXT or SET MAX ADDRESS EXT.  I
still suspect the FPGA is misusing the HOB bit.

The driver (for example) does a READ MAX ADDRESS EXT and stored that
value (0x000004A852FF is what is returned), then somehow only wrote to
the lower 3 bytes of the LBA for the SET MAX command, the "previous
contents" would shift into those upper bytes as shown.

Maybe the FPGA is discarding the taskfile writes once the HOB bit is
set?  It wouldn't affect the READ NATIVE MAX ADDRESS EXT command being
issued since the only the command register matters for that, but it
would affect SET MAX ADDRESS EXT working properly.

Without a device > 137GB to test with, and without errors on the
device, you might not see any odd behavior in normal usage.

It's *really* unlikely the drive doesn't have a working taskfile.
--eric

Re: HPA and failed opcode was: 0x37 ?

[Eric D. Mudama]

On 1/30/07, Eric D. Mudama <edmudama@gmail.com> wrote:
> It's *really* unlikely the drive doesn't have a working taskfile.

One other thing is that these registers in the drive are pretty dumb,
at least on the stuff I've worked with.  However, it allows for some
neat optimizations...

For example, you don't technically need to rewrite the task file to
set the drive to max capacity.

Simply writing the command register with 0x27 for READ NATIVE MAX
ADDRESS EXT, followed immediately by a write to the command register
with 0x37, would (in theory) set the drive to the proper size, since
the contents of both regular and HOB registers would be setup already
inside the device.

Another trick is when doing sequential DMA reads, since most drives
stuff the taskfile with the next sequential block when a DMA command
completes, you could save the taskfile writes and just issue another
write to the command register for the next sequential chunk of data.
On older PATA chipsets, this can buy you a few percent performance
when using smaller block sizes.

Granted these are all benchmarking hacks, and the behavior isn't
guaranteed I don't think, but I've seen this stuff done in driver
implementations before.

--eric

Re: HPA and failed opcode was: 0x37 ?

[Steven Scholz]

Eric,

> Maybe the FPGA is discarding the taskfile writes once the HOB bit is
> set?  It wouldn't affect the READ NATIVE MAX ADDRESS EXT command being
> issued since the only the command register matters for that, but it
> would affect SET MAX ADDRESS EXT working properly.
> 
> Without a device > 137GB to test with, and without errors on the
> device, you might not see any odd behavior in normal usage.
> 
> It's *really* unlikely the drive doesn't have a working taskfile.

I am sorry. But I don't understand what a "working taskfile" means.
I don't have CONFIG_IDE_TASK_IOCTL enabled if that means anything.

The FPGA does nothing except decoding adresseses from the ARM cpu,
controlling the A[2..0], CS[1..0], IOR, IOW lines of the HDD.

In linux all I do is setting up some hw_regs_t struct (with hw.io_ports[])
according to my memory map and call ide_register_hw() ...

So looks like I need to find out more about that taskfile stuff.

The reason I started the this thread is that after working with Hitatchi and
Toshiba HDDs in the same mannor we suddenly have problems with new Seagate
drives.

After the kernel reported problems when writing to the disk I used
smartctl to look at the attributes:

Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   100   253   006         0
  3 Spin_Up_Time            0x0003   096   096   000         0
  4 Start_Stop_Count        0x0032   100   100   020        21
  5 Reallocated_Sector_Ct   0x0033   100   100   036         0
  7 Seek_Error_Rate         0x000f   061   060   030   1368871
  9 Power_On_Hours          0x0032   100   100   000        76
 10 Spin_Retry_Count        0x0013   100   100   034         0
 12 Power_Cycle_Count       0x0032   100   100   020        27
187 Unknown_Attribute       0x0032   100   100   000         0
189 Unknown_Attribute       0x003a   100   100   000         0
190 Temperature_Celsius     0x0022   069   025   045 538705951
192 Power-Off_Retract_Count 0x0032   100   100   000        25
193 Load_Cycle_Count        0x0032   100   100   000       363
194 Temperature_Celsius     0x0022   031   075   000        31
195 Hardware_ECC_Recovered  0x001a   078   066   000  23105720
197 Current_Pending_Sector  0x0012   100   100   000         0
198 Offline_Uncorrectable   0x0010   100   100   000         0
199 UDMA_CRC_Error_Count    0x003e   200   200   000         0
200 Multi_Zone_Error_Rate   0x0000   100   253   000         0
202 TA_Increase_Count       0x0032   100   253   000         0

And I am kind of concerned about Seek_Error_Rate, Temperature_Celsius and
Hardware_ECC_Recovered ...

So now I wonder if all the Seagate drives we have are broken or if this
might be a problem with our hardware ...

Thanks a million!

Steven

Re: HPA and failed opcode was: 0x37 ?

[Sergei Shtylyov]

Hello.

Steven Scholz wrote:

>>Maybe the FPGA is discarding the taskfile writes once the HOB bit is
>>set?  It wouldn't affect the READ NATIVE MAX ADDRESS EXT command being
>>issued since the only the command register matters for that, but it
>>would affect SET MAX ADDRESS EXT working properly.

>>Without a device > 137GB to test with, and without errors on the
>>device, you might not see any odd behavior in normal usage.

>>It's *really* unlikely the drive doesn't have a working taskfile.

> I am sorry. But I don't understand what a "working taskfile" means.
> I don't have CONFIG_IDE_TASK_IOCTL enabled if that means anything.

> The FPGA does nothing except decoding adresseses from the ARM cpu,
> controlling the A[2..0], CS[1..0], IOR, IOW lines of the HDD.

    I've not seen you quoting the code that sets ofsset for the 
IDE_CONTROL_REG, BTW... Without this register, LBA48 is completely broken

> In linux all I do is setting up some hw_regs_t struct (with hw.io_ports[])
> according to my memory map and call ide_register_hw() ...

> So looks like I need to find out more about that taskfile stuff.

    Taskfile is another (and probably an older one) anme for the IDE command 
block registers.

> Steven

MBR, Sergei

Re: HPA and failed opcode was: 0x37 ?

[Steven Scholz]

Sergei,

>> The FPGA does nothing except decoding adresseses from the ARM cpu,
>> controlling the A[2..0], CS[1..0], IOR, IOW lines of the HDD.
> 
>    I've not seen you quoting the code that sets ofsset for the
> IDE_CONTROL_REG, BTW... Without this register, LBA48 is completely broken

        for (i = IDE_DATA_OFFSET; i <= IDE_STATUS_OFFSET; i++) {
                hw.io_ports[i] = ide_virt_base + (i << 1);
        }

        hw.io_ports[IDE_CONTROL_OFFSET] = ide_virt_base + 0x10;

Thus it has an offset 0x10 from the base address.

ide0 at 0xc3856000-0xc3856007,0xc3856010 on irq 27

But I just noticed that A[2..0] should look like "110" when accessing the
"Device Control Register". Thus the offset should be 0x16 instead! Right?

--
Steven

Re: HPA and failed opcode was: 0x37 ?

[Sergei Shtylyov]

Hello.

Steven Scholz wrote:
> Sergei,

>>>The FPGA does nothing except decoding adresseses from the ARM cpu,
>>>controlling the A[2..0], CS[1..0], IOR, IOW lines of the HDD.

>>   I've not seen you quoting the code that sets ofsset for the
>>IDE_CONTROL_REG, BTW... Without this register, LBA48 is completely broken

>         for (i = IDE_DATA_OFFSET; i <= IDE_STATUS_OFFSET; i++) {
>                 hw.io_ports[i] = ide_virt_base + (i << 1);
>         }

>         hw.io_ports[IDE_CONTROL_OFFSET] = ide_virt_base + 0x10;

> Thus it has an offset 0x10 from the base address.

> ide0 at 0xc3856000-0xc3856007,0xc3856010 on irq 27

> But I just noticed that A[2..0] should look like "110" when accessing the
> "Device Control Register". Thus the offset should be 0x16 instead! Right?

    If your FPGA passes A[2..0] untouched to the IDE bus, it's certainly 
wrong. It must pass 110.

> --
> Steven

MBR, Sergei

Re: HPA and failed opcode was: 0x37 ?

[Steven Scholz]

Hi,

>>         for (i = IDE_DATA_OFFSET; i <= IDE_STATUS_OFFSET; i++) {
>>                 hw.io_ports[i] = ide_virt_base + (i << 1);
>>         }
> 
>>         hw.io_ports[IDE_CONTROL_OFFSET] = ide_virt_base + 0x10;
> 
>> Thus it has an offset 0x10 from the base address.
> 
>> ide0 at 0xc3856000-0xc3856007,0xc3856010 on irq 27
> 
>> But I just noticed that A[2..0] should look like "110" when accessing the
>> "Device Control Register". Thus the offset should be 0x16 instead! Right?
> 
>    If your FPGA passes A[2..0] untouched to the IDE bus, it's certainly
> wrong. It must pass 110.

Stupid me. As I mentioned earlier CPU's A[3..1] are connected to HDD's
A[2..0]. And CPU's A4 is used for HDD's CS1 (inverted of course). Thus the
offset for IDE_CONTROL_OFFSET must be 0x1C (=0x10 + 0x6 << 1).

And volá

ide0 at 0xc3856000-0xc3856007,0xc385601c on irq 27
hda: max request size: 1024KiB
idedisk_supports_hpa(): cfs_enable_1=346b, cfs_enable_1=3469
idedisk_read_native_max_address_ext(): addr = 000004a852ff
idedisk_read_native_max_address_ext(): addr = 000004a852ff
idedisk_read_native_max_address_ext(): addr = 000004a85300
idedisk_read_native_max_address_ext(): addr = 000004a85300
hda: 78140160 sectors (40007 MB) w/8192KiB Cache, CHS=16383/255/63
hda: cache flushes supported
 hda: hda1

idedisk_read_native_max_address_ext() works now. No HPA reported anymore!

Thanks a million to everyone!!!!

PS: Still I don't know why ARM reports "max request size: 1024KiB" and y86
reports only "max request size: 512KiB" ...

Steven

Re: HPA and failed opcode was: 0x37 ?

[Steven Scholz]

Sergei,

>> How could one then explain
> 
>> current capacity is 78140160 sectors would be           0x000004A85300
>> native  capacity is 185074430006016 sectors would be    0xA852FFA85300
>>
>> ? First three bytes ok, then the other three bytes rubbish?
> 
>    Note that they're not complete garbage but equal the value of the
> lower 3 bytes minus 1. What is clear is that Read Native Max Address Ext
> command must be mistreating the HOB bit... :-)

Well this results from

	addr++;	/* since the return value is (maxlba - 1), we add 1 */

in idedisk_read_native_max_address_ext().

Apparently on my system

		u32 high = (args.hobRegister[IDE_HCYL_OFFSET] << 16) |
			   (args.hobRegister[IDE_LCYL_OFFSET] <<  8) |
			    args.hobRegister[IDE_SECTOR_OFFSET];
		u32 low  = ((args.tfRegister[IDE_HCYL_OFFSET])<<16) |
			   ((args.tfRegister[IDE_LCYL_OFFSET])<<8) |
			    (args.tfRegister[IDE_SECTOR_OFFSET]);

high and low contain the same values! :-(

I "hardcoded" set_max = capacity, now I get

hda: Host Protected Area detected.
        current capacity is 78140160 sectors (40007 MB)
        native  capacity is 78140160 sectors (40007 MB)
hda: Host Protected Area disabled.
hda: 4289221376 sectors (2196081 MB) w/8192KiB Cache, CHS=65535/255/63

;-)

But still something must go terribly wrong.

smartctl shows

  7 Seek_Error_Rate         0x000f   061   060   030     -       1513926
195 Hardware_ECC_Recovered  0x001a   100   066   000     -       104721680

And after just doing a "mke2fs /dev/hda1" I see

  7 Seek_Error_Rate         0x000f   061   060   030     -       1516919
195 Hardware_ECC_Recovered  0x001a   095   066   000     -       104791382

:-(

--
Steven

Re: HPA and failed opcode was: 0x37 ?

[Sergei Shtylyov]

Hello.

Steven Scholz wrote:

>>>How could one then explain

>>>current capacity is 78140160 sectors would be           0x000004A85300
>>>native  capacity is 185074430006016 sectors would be    0xA852FFA85300

>>>? First three bytes ok, then the other three bytes rubbish?

>>   Note that they're not complete garbage but equal the value of the
>>lower 3 bytes minus 1. What is clear is that Read Native Max Address Ext
>>command must be mistreating the HOB bit... :-)

> Well this results from

> 	addr++;	/* since the return value is (maxlba - 1), we add 1 */

> in idedisk_read_native_max_address_ext().

> Apparently on my system
> 
> 		u32 high = (args.hobRegister[IDE_HCYL_OFFSET] << 16) |
> 			   (args.hobRegister[IDE_LCYL_OFFSET] <<  8) |
> 			    args.hobRegister[IDE_SECTOR_OFFSET];
> 		u32 low  = ((args.tfRegister[IDE_HCYL_OFFSET])<<16) |
> 			   ((args.tfRegister[IDE_LCYL_OFFSET])<<8) |
> 			    (args.tfRegister[IDE_SECTOR_OFFSET]);
> 
> high and low contain the same values! :-(

    Right.
    I also have doubts about IDE_CONTROL_REG being properly decoded/handled in 
your FPGA.

> I "hardcoded" set_max = capacity, now I get

> hda: Host Protected Area detected.
>         current capacity is 78140160 sectors (40007 MB)
>         native  capacity is 78140160 sectors (40007 MB)
> hda: Host Protected Area disabled.
> hda: 4289221376 sectors (2196081 MB) w/8192KiB Cache, CHS=65535/255/63

> ;-)

> But still something must go terribly wrong.

    Erm, the resulting capacity still seems wrong, so you need to also change 
idedisk_set_max_address_ext().

> smartctl shows

>   7 Seek_Error_Rate         0x000f   061   060   030     -       1513926
> 195 Hardware_ECC_Recovered  0x001a   100   066   000     -       104721680

> And after just doing a "mke2fs /dev/hda1" I see

>   7 Seek_Error_Rate         0x000f   061   060   030     -       1516919
> 195 Hardware_ECC_Recovered  0x001a   095   066   000     -       104791382

> :-(

    I'm not sure smartctl names these attributes corectly -- they're vendor 
specific, after all... :-)

> --
> Steven

MBR, Sergei

Re: HPA and failed opcode was: 0x37 ?

[Steven Scholz]

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

Sergei,

>    I also have doubts about IDE_CONTROL_REG being properly
> decoded/handled in your FPGA.
Hmm. We just verified and are convinced to do it the right way. ;-)

>> hda: Host Protected Area detected.
>>         current capacity is 78140160 sectors (40007 MB)
>>         native  capacity is 78140160 sectors (40007 MB)
>> hda: Host Protected Area disabled.
>> hda: 4289221376 sectors (2196081 MB) w/8192KiB Cache, CHS=65535/255/63
> 
>    Erm, the resulting capacity still seems wrong, so you need to also
> change idedisk_set_max_address_ext().

I noticed as well.

I just connected the HDD in question to a PC and the kernel there DID NOT
detect a HPA! Funny enough the output of cat /proc/ide/hdb/identify is
different. Shouldn't it be the same!?
I'll attach them.

Thanks for any hints!

Steven


[-- Attachment #2: identify.arm --]
[-- Type: text/plain, Size: 1281 bytes --]

0c5a 3fff c837 0010 0000 0000 003f 0000
0000 0000 2020 2020 2020 2020 2020 2020
3551 4230 3052 4d30 0000 4000 0004 332e
3032 2020 2020 5354 3934 3038 3133 414d
2020 2020 2020 2020 2020 2020 2020 2020
2020 2020 2020 2020 2020 2020 2020 8010
0000 2f00 4000 0200 0200 0007 ffff 0001
003f ffc1 003e 0110 5300 04a8 0000 0407
0003 0078 0078 00f0 0078 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
007e 001b 346b 7d09 6003 3469 3c09 6003
003f 0000 0000 8080 fffe 604d fe00 0000
0000 0000 0000 0000 5300 04a8 0000 0000
0000 0000 4000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0100 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0001 5300 04a8 5300 04a8 2020 0002 82b6
0000 008a 01ff 3cff ffff 07c6 0100 0800
0f0f 1800 0002 0080 0000 0000 60a0 0000
0000 0000 0000 0000 0000 0000 0900 000b
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0001 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 15a5


[-- Attachment #3: identify.x86 --]
[-- Type: text/plain, Size: 1281 bytes --]

0c5a 3fff c837 0010 0000 0000 003f 0000
0000 0000 2020 2020 2020 2020 2020 2020
3551 4230 3052 4d30 0000 4000 0004 332e
3032 2020 2020 5354 3934 3038 3133 414d
2020 2020 2020 2020 2020 2020 2020 2020
2020 2020 2020 2020 2020 2020 2020 8010
0000 2f00 4000 0200 0200 0007 ffff 0001
003f ffc1 003e 0110 5300 04a8 0000 0007
0003 0078 0078 00f0 0078 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
007e 001b 346b 7d09 6003 3469 3c09 6003
043f 0000 0000 8080 fffe 6d00 fe00 0000
0000 0000 0000 0000 5300 04a8 0000 0000
0000 0000 4000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0100 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0009 5300 04a8 5300 04a8 2020 0002 82b6
0000 008a 01ff 3cff ffff 07c6 0100 0800
0f0f 1800 0002 0080 0000 0000 60a0 0000
0000 0000 0000 0000 0000 0000 0900 000b
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0001 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 4da5

Re: HPA and failed opcode was: 0x37 ?

[Alan]

> I just connected the HDD in question to a PC and the kernel there DID NOT
> detect a HPA! Funny enough the output of cat /proc/ide/hdb/identify is
> different. Shouldn't it be the same!?

No they will be different because the PC hardware works properly. We'll
read both sizes realize they are the same and thus not report an HPA.

This essentially confirms your hardware or driver is bust.

Alan

Re: HPA and failed opcode was: 0x37 ?

[Steven Scholz]

Alan wrote:
>> I just connected the HDD in question to a PC and the kernel there DID NOT
>> detect a HPA! Funny enough the output of cat /proc/ide/hdb/identify is
>> different. Shouldn't it be the same!?
>
> No they will be different because the PC hardware works properly. We'll
> read both sizes realize they are the same and thus not report an HPA.

Ah. I see.

> This essentially confirms your hardware or driver is bust.
Ok. So the mean problem is that reading the HOB registers does not work ...
Hmmm.

--
Steven