WIN_READ_NATIVE_MAX_EXT returns incomplete result

WIN_READ_NATIVE_MAX_EXT returns incomplete result

[Martin Habets]

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

Hi,

I've been trying to get "Host Protected Area" to work with my 80GB
Samsung SP0802N, as I have an old BIOS.
The max LBA capacity is 156368016 sectors (0x951FC90), but I've set
that to 66055248 with the setmax utility. Without this, or a 32GB clip,
I never get past the BIOS.

Initially idedisk_check_hpa() failed to detect the difference. It
turned out that idedisk_read_native_max_address_ext() returns
0x51FC90, i.e. the first '9' is missing!

When I use idedisk_read_native_max_address() it returns the right
number.
But I'm at a loss why the _ext() version does not work.

I'm on kernel 2.6.8 and in my BIOS I have 16383/16/63 for the disk.
My IDE controller:
0000:00:0f.0 IDE interface: ALi Corporation M5229 IDE (rev 20)

Attached are parts of dmesg output, which includes some printk's I
put in. The "hob ..." lines come from this code in
idedisk_read_native_max_address_ext():
		printk(KERN_INFO "%s: max_address_ext: high=0x%x low=0x%x\n",
				        drive->name, high, low);
		for(i=0;i<IDE_NR_PORTS;i++) {
			printk(KERN_INFO "hob %d: 0x%x, tf %d: 0x%x\n",
				         i, args.hobRegister[i],
					 i, args.tfRegister[i]);
	 	}

The 2nd attachment is dmesg output with a hack to use the non-lba48 code,
which works ok.

Any clues?

Thanks,
-- 
Martin
---------------------------------------------------------------------------
30 years from now GNU/Linux will be as redundant a term as UNIX/MERT is 
today. - Martin Habets
---------------------------------------------------------------------------

[-- Attachment #2: msg --]
[-- Type: text/plain, Size: 2428 bytes --]

Nov 16 15:57:28 palantir8 kernel: Linux version 2.6.8 (opendev@palantir8) (gcc version 3.3.4 (Debian 1:3.3.4-13)) #8 Tue Nov 16 15:46:38 GMT 2004
...
Nov 16 15:57:28 palantir8 kernel: Kernel command line: BOOT_IMAGE=lin68 ro root=305 pci=usepirqmask hda=stroke
Nov 16 15:57:28 palantir8 kernel: ide_setup: hda=stroke
...
Nov 16 15:57:28 palantir8 kernel: ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
Nov 16 15:57:28 palantir8 kernel: ALI15X3: IDE controller at PCI slot 0000:00:0f.0
Nov 16 15:57:28 palantir8 kernel: PCI: Assigned IRQ 5 for device 0000:00:0f.0
Nov 16 15:57:28 palantir8 kernel: ALI15X3: chipset revision 32
Nov 16 15:57:28 palantir8 kernel: ALI15X3: not 100%% native mode: will probe irqs later
Nov 16 15:57:28 palantir8 kernel:     ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:pio
Nov 16 15:57:28 palantir8 kernel:     ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio
Nov 16 15:57:28 palantir8 kernel: hda: SAMSUNG SP0802N, ATA DISK drive
Nov 16 15:57:28 palantir8 kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Nov 16 15:57:28 palantir8 kernel: hdc: EPO CD-ROM CR-836S, ATAPI CD/DVD-ROM drive
Nov 16 15:57:28 palantir8 kernel: hdd: Maxtor 90845D4, ATA DISK drive
Nov 16 15:57:28 palantir8 kernel: ide1 at 0x170-0x177,0x376 on irq 15
Nov 16 15:57:28 palantir8 kernel: hda: max request size: 128KiB
Nov 16 15:57:28 palantir8 kernel: SAMSUNG SP0802N: hpa=1, cmd_set_1=0x346b, cfs_en_1=0x3c69
Nov 16 15:57:28 palantir8 kernel: hda capacity: lba=66055248, lba_2=66055248, lba48=1.
Nov 16 15:57:28 palantir8 kernel: hda: max_address_ext: high=0 low=51fc8f
Nov 16 15:57:28 palantir8 kernel: hob 0: 0, tf 0: 0
Nov 16 15:57:28 palantir8 kernel: hob 1: 0, tf 1: 0
Nov 16 15:57:28 palantir8 kernel: hob 2: 0, tf 2: 0
Nov 16 15:57:28 palantir8 kernel: hob 3: 0, tf 3: 8f
Nov 16 15:57:28 palantir8 kernel: hob 4: 0, tf 4: fc
Nov 16 15:57:28 palantir8 kernel: hob 5: 0, tf 5: 51
Nov 16 15:57:28 palantir8 kernel: hob 6: 0, tf 6: e0
Nov 16 15:57:28 palantir8 kernel: hob 7: 0, tf 7: 50
Nov 16 15:57:28 palantir8 kernel: hob 8: 0, tf 8: 0
Nov 16 15:57:28 palantir8 kernel: hob 9: 0, tf 9: 0
Nov 16 15:57:28 palantir8 kernel: hda check_hpa: max 5373072 vs. capacity 66055248.
Nov 16 15:57:28 palantir8 kernel: hda: 66055248 sectors (33820 MB) w/2048KiB Cache, CHS=16383/255/63, (U)DMA
Nov 16 15:57:28 palantir8 kernel:  hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 hda8 >


[-- Attachment #3: msg2 --]
[-- Type: text/plain, Size: 538 bytes --]

hda: max request size: 128KiB
SAMSUNG SP0802N: hpa=1, cmd_set_1=0x346b, cfs_en_1=0x3c69
hda capacity: lba=66055248, lba_2=66055248, lba48=1.
hda check_hpa: max 156368016 vs. capacity 66055248.
hda: Host Protected Area detected.
        current capacity is 66055248 sectors (33820 MB)
        native  capacity is 156368016 sectors (80060 MB)
hda: Host Protected Area disabled.
hda: 156368016 sectors (80060 MB) w/2048KiB Cache, CHS=16383/255/63, (U)DMA
 hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 hda8 hda9 hda10 hda11 hda12 hda13 hda14 >

Re: WIN_READ_NATIVE_MAX_EXT returns incomplete result

[Bartlomiej Zolnierkiewicz]

Hi,

On Tue, 16 Nov 2004 17:34:44 +0000, Martin Habets
<errandir_news@mph.eclipse.co.uk> wrote:
> Hi,
> 
> I've been trying to get "Host Protected Area" to work with my 80GB
> Samsung SP0802N, as I have an old BIOS.
> The max LBA capacity is 156368016 sectors (0x951FC90), but I've set
> that to 66055248 with the setmax utility. Without this, or a 32GB clip,
> I never get past the BIOS.
> 
> Initially idedisk_check_hpa() failed to detect the difference. It
> turned out that idedisk_read_native_max_address_ext() returns
> 0x51FC90, i.e. the first '9' is missing!
> 
> When I use idedisk_read_native_max_address() it returns the right
> number.
> But I'm at a loss why the _ext() version does not work.
> 
> I'm on kernel 2.6.8 and in my BIOS I have 16383/16/63 for the disk.
> My IDE controller:
> 0000:00:0f.0 IDE interface: ALi Corporation M5229 IDE (rev 20)
> 
> Attached are parts of dmesg output, which includes some printk's I
> put in. The "hob ..." lines come from this code in
> idedisk_read_native_max_address_ext():
>                 printk(KERN_INFO "%s: max_address_ext: high=0x%x low=0x%x\n",
>                                         drive->name, high, low);
>                 for(i=0;i<IDE_NR_PORTS;i++) {
>                         printk(KERN_INFO "hob %d: 0x%x, tf %d: 0x%x\n",
>                                          i, args.hobRegister[i],
>                                          i, args.tfRegister[i]);
>                 }
> 
> The 2nd attachment is dmesg output with a hack to use the non-lba48 code,
> which works ok.
> 
> Any clues?

In kernel 2.6.8 LBA48 support is disabled for ALi chipsets with revisions
<= 0xC4 (drive->addressing is set to zero) but idedisk_check_hpa()
incorrectly uses drive->id directly which results in this bug (because
do_rw_taskfile() and ide_end_drive_cmd() rely on drive->addressing).

This patch should fix it:

--- ide-disk.c.orig	2004-11-05 23:24:41.000000000 +0100
+++ ide-disk.c	2004-11-16 19:24:17.321273832 +0100
@@ -625,7 +625,7 @@
 static inline void idedisk_check_hpa(ide_drive_t *drive)
 {
 	unsigned long long capacity, set_max;
-	int lba48 = idedisk_supports_lba48(drive->id);
+	unsigned int lba48 = drive->addressing;
 
 	capacity = drive->capacity64;
 	if (lba48)

Moreover you shouldn't hit this bug in current kernels because they
use LBA48 (with some limitations: no DMA for LBA48 area) for ALi
chipsets revs <= 0xC4.

Bartlomiej

Re: WIN_READ_NATIVE_MAX_EXT returns incomplete result

[Martin Habets]

On Tue, Nov 16, 2004 at 07:29:31PM +0100, Bartlomiej Zolnierkiewicz wrote:
> In kernel 2.6.8 LBA48 support is disabled for ALi chipsets with revisions
> <= 0xC4 (drive->addressing is set to zero) but idedisk_check_hpa()
> incorrectly uses drive->id directly which results in this bug (because
> do_rw_taskfile() and ide_end_drive_cmd() rely on drive->addressing).
> 
> This patch should fix it:

Thanks, works like a charm!

> --- ide-disk.c.orig	2004-11-05 23:24:41.000000000 +0100
> +++ ide-disk.c	2004-11-16 19:24:17.321273832 +0100
> @@ -625,7 +625,7 @@
>  static inline void idedisk_check_hpa(ide_drive_t *drive)
>  {
>  	unsigned long long capacity, set_max;
> -	int lba48 = idedisk_supports_lba48(drive->id);
> +	unsigned int lba48 = drive->addressing;
>  
>  	capacity = drive->capacity64;
>  	if (lba48)
> 
> Moreover you shouldn't hit this bug in current kernels because they
> use LBA48 (with some limitations: no DMA for LBA48 area) for ALi
> chipsets revs <= 0xC4.

Was planning to stay on 2.6.8 for a while.

-- 
Martin