login
Search
Hello, after a total hard disk failure, I decided to build RAID1 using a cheap card with it8212 chip and two Samsung HD400LD drives. I thought that the pata_it821x driver is mature and should work fine (it does not depend on EXPERIMENTAL). However, it seems to be broken in several ways (in 2.6.25.3). When I don't have any RAID array created, both drives are detected but it appears to work only in MWDMA2 mode: pata_it821x: controller in smart mode. ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11 ACPI: PCI Interrupt 0000:00:12.0[A] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11 PCI: Setting latency timer of device 0000:00:12.0 to 64 scsi2 : pata_it821x scsi3 : pata_it821x ata3: PATA max MWDMA2 cmd 0x6800 ctl 0x6c00 bmdma 0x7800 irq 11 ata4: PATA max MWDMA2 cmd 0x7000 ctl 0x7400 bmdma 0x7808 irq 11 ata3.00: ATA-7: SAMSUNG HD400LD, WQ100-15, max UDMA/100 ata3.00: 781422768 sectors, multi 0: LBA48 ata3.00: configured for DMA ata4.00: ATA-7: SAMSUNG HD400LD, WQ100-15, max UDMA/100 ata4.00: 781422768 sectors, multi 0: LBA48 ata4.00: configured for DMA But in fact, it's running faster: hdparm --direct -t /dev/sdc /dev/sdc: Timing O_DIRECT disk reads: 188 MB in 3.01 seconds = 62.48 MB/sec Also I get some errors about HPA when rebooting but haven't captured them yet. But the more interesting thing is that once I create a RAID1 array (and run background rebuild), the driver does not work anymore: ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11 ACPI: PCI Interrupt 0000:00:12.0[A] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11 scsi2 : pata_it821x scsi3 : pata_it821x ata3: PATA max MWDMA2 cmd 0x6800 ctl 0x6c00 bmdma 0x7800 irq 11 ata4: PATA max MWDMA2 cmd 0x7000 ctl 0x7400 bmdma 0x7808 irq 11 ata3.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_masl=0x80) ata3: failed to recover some devices, retrying in 5 secs ata3.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_masl=0x80) ata3: failed to recover some devices, retrying in 5 secs ata3.00: ...
The speed is meaningless in hardware RAID mode. Its also btw usually faster (except for some cases of RAID1 with high PCI bus utilisation like IT821x does not support the HPA in 'raid' mode, only in non RAID mode so Ok that is a bug I've not met. What firmware revision is this and does it It seems to have decided to be indefinitely busy from that. Alan --
It complains pretty loudly - something like 3 screens (with framebuffer at
1024x768) of errors like this:
sd 3:0:0:0: [sdc] Synchronizing SCSI cache
ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata4.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0
res 50/00:01:01:00:00/00:00:00:00:00/00 Emask 0x1 (device error)
ata4.00: status: { DRDY }
ata4.00: failed to read native max address (err_mask=0x1)
ata4.00: HPA support seems broken, skipping HPA handling
ata4.00: revalidation failed (errno=-5)
ata4: failed to recover some devices, retrying in 5 secs
Maybe it should just not do anything with HPA if it's not supported (but I
It's BIOS v1.7.1.94, firmware 02093030. Haven't tried waiting for the rebuild
to complete. It will probably take ages for 400GB drives. I'll try with some
--
Ondrej Zary
--
Interesting. I need to have a poke at that - it used to work fine but I've not tested the 821x recently and the HPA code has changed. It shouldn't be issuing HPA commands in the first place. Added to the TODO list. The HPA is supposed to be cleared by the driver setup code but if the newer firmware is faking it then I wonder what it does if we allow Thanks --
Tested with various drives connected as slaves (in addidion to the two 400GB Samsungs). Seems like any drive that can't do UDMA fails (looks like MWDMA is broken). The controller BIOS creates the array fine but it doesn't work in Linux. In smart mode, it fails to identify (this is probably the same problem as with any other RAID array): pata_it821x: controller in smart mode. ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11 ACPI: PCI Interrupt 0000:00:12.0[A] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11 PCI: Setting latency timer of device 0000:00:12.0 to 64 scsi2 : pata_it821x scsi3 : pata_it821x ata3: PATA max MWDMA2 cmd 0x6800 ctl 0x6c00 bmdma 0x7800 irq 11 ata4: PATA max MWDMA2 cmd 0x7000 ctl 0x7400 bmdma 0x7808 irq 11 ata3.01: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x80) ata3: failed to recover some devices, retrying in 5 secs ata3.01: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x80) ata3: failed to recover some devices, retrying in 5 secs ata3.01: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x80) ata3: failed to recover some devices, retrying in 5 secs ata3.00: ATA-7: SAMSUNG HD400LD, WQ100-15, max UDMA/100 ata3.00: 781422768 sectors, multi 0: LBA48 ata3.00: configured for DMA ata4.00: ATA-7: SAMSUNG HD400LD, WQ100-15, max UDMA/100 ata4.00: 781422768 sectors, multi 0: LBA48 ata4.00: configured for DMA When I force the pass-through mode, it oopses (haven't captured it yet as it's too long). Forcing pass-through mode works fine with UDMA-capable drives: pata_it821x: forcing bypass mode. pata_it821x: controller in pass through mode. ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11 ACPI: PCI Interrupt 0000:00:12.0[A] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11 scsi2 : pata_it821x scsi3 : pata_it821x ata3: PATA max UDMA/133 cmd 0x6800 ctl 0x6c00 bmdma 0x7800 irq 11 ata4: PATA max UDMA/133 cmd 0x7000 ctl 0x7400 bmdma 0x7808 irq 11 ata3.00: ATA-7: SAMSUNG HD400LD, WQ100-15, max UDMA/100 ata3.00: 781422768 sectors, ...
I've no idea if the BIOS firmware mode can do MWDMA to the drives. The actual I would imagine the controller fakes a hotplug event when the rebuild finishes but that is guessing. The firmware mode is pretty minimally documented. --
Did some testing with older drives (and netconsole), everything in
pass-through mode. Looks like the controller firmware does not like some of
them (<1GB ones).
IBM H3256-A3 - firmware hangs (BIOS displays that the firmware is not ready)
Maxtor 7120AT - firmware hangs
WD Caviar 2850 - firmware does not detect it but works in Linux
WD Caviar 1425 - firmware does not detect it but works in Linux
WD Caviar 1270 - firmware does not detect it and fails in Linux - detected as
8860MB instead of 270MB and is unreadable:
scsi 3:0:1:0: Direct-Access ATA WDC AC1270G ! ! 12/0 PQ: 0 ANSI: 5
sd 3:0:1:0: [sdd] 17305408 512-byte hardware sectors (8860 MB)
sd 3:0:1:0: [sdd] Write Protect is off
sd 3:0:1:0: [sdd] Write cache: disabled, read cache: enabled, doesn't support
DPO or FUA
sd 3:0:1:0: [sdd] 17305408 512-byte hardware sectors (8860 MB)
sd 3:0:1:0: [sdd] Write Protect is off
sd 3:0:1:0: [sdd] Write cache: disabled, read cache: enabled, doesn't support
DPO or FUA
sdd:<3>ata4.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata4.01: BMDMA stat 0x4
ata4.01: cmd c8/00:08:00:00:00/00:00:00:00:00/f0 tag 0 dma 4096 in
res 59/04:08:00:00:00/00:00:00:00:00/f0 Emask 0x2 (HSM violation)
ata4.01: status: { DRDY DRQ ERR }
ata4.01: error: { ABRT }
ata4: soft resetting link
ata4.00: configured for UDMA/100
ata4.01: configured for MWDMA1 (device error ignored)
ata4: EH complete
ata4.01: limiting speed to MWDMA0:PIO3
ata4.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata4.01: BMDMA stat 0x4
ata4.01: cmd c8/00:08:00:00:00/00:00:00:00:00/f0 tag 0 dma 4096 in
res 59/04:08:00:00:00/00:00:00:00:00/f0 Emask 0x2 (HSM violation)
ata4.01: status: { DRDY DRQ ERR }
ata4.01: error: { ABRT }
ata4: soft resetting link
ata4.00: configured for UDMA/100
ata4.01: configured for MWDMA0 (device error ignored)
ata4: EH complete
sd 3:0:0:0: [sdc] 781422768 512-byte hardware sectors (400088 MB)
ata4.01: limiting speed to PIO3
ata4.01: exception ...Please file a bug for this - that's upsetting the core libata code somewhere, perhaps from a left over floating interrupt. Alan --
Couldn't reproduce that yet but the HPA case should be fixed by the
following patch:
pata_it821x: With newer firmware we see HPA flags
From: Alan Cox <alan@redhat.com>
We don't want HPA flags set at this point as we don't allow the issuing of
HPA operations via the 'smart' firmware interface. It could be 1.7 firmware
supports this but for the moment the blunt hammer is appealing (one reason
being right now we don't actually know how to peek at the firmware rev!)
---
drivers/ata/pata_it821x.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/pata_it821x.c b/drivers/ata/pata_it821x.c
index e108169..977e5f8 100644
--- a/drivers/ata/pata_it821x.c
+++ b/drivers/ata/pata_it821x.c
@@ -80,7 +80,7 @@
#define DRV_NAME "pata_it821x"
-#define DRV_VERSION "0.3.8"
+#define DRV_VERSION "0.3.9"
struct it821x_dev
{
@@ -519,6 +519,8 @@ static void it821x_dev_config(struct ata_device *adev)
/* This is a controller firmware triggered funny, don't
report the drive faulty! */
adev->horkage &= ~ATA_HORKAGE_DIAGNOSTIC;
+ /* No HPA in 'smart' mode */
+ adev->horkage |= ATA_HORKAGE_BROKEN_HPA;
}
/**
@@ -546,7 +548,9 @@ static int it821x_ident_hack(struct ata_port *ap)
adev->id[76] = 0; /* No NCQ/AN etc */
}
}
- return ata_cable_unknown(ap);
+ /* This is actually meaningless, but reporting 80 wire avoids
+ warnings about cable types */
+ return ata_cable_80wire(ap);
}
--
Thanks, it does not complain about HPA anymore. However, there are some error
messages left. I thought that they were connected with the HPA, but obviously
they aren't:
sd 2:0:0:0: [sdb] Synchronizing SCSI cache
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata3.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0
res 50/00:01:01:00:00/00:00:00:00:00/00 Emask 0x1 (device error)
ata3.00: status: { DRDY }
ata3.00: configured for DMA
ata3: EH complete
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata3.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0
res 50/00:01:01:00:00/00:00:00:00:00/00 Emask 0x1 (device error)
ata3.00: status: { DRDY }
ata3.00: configured for DMA
ata3: EH complete
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata3.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0
res 50/00:01:01:00:00/00:00:00:00:00/00 Emask 0x1 (device error)
ata3.00: status: { DRDY }
ata3.00: configured for DMA
ata3: EH complete
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata3.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0
res 50/00:01:01:00:00/00:00:00:00:00/00 Emask 0x1 (device error)
ata3.00: status: { DRDY }
ata3.00: configured for DMA
ata3: EH complete
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata3.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0
res 50/00:01:01:00:00/00:00:00:00:00/00 Emask 0x1 (device error)
ata3.00: status: { DRDY }
ata3.00: configured for DMA
ata3: EH complete
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata3.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0
res 50/00:01:01:00:00/00:00:00:00:00/00 Emask 0x1 (device error)
ata3.00: status: { DRDY }
ata3.00: configured for DMA
ata3: EH complete
sd 2:0:0:0: [sdb] 781422768 512-byte hardware sectors (400088 MB)
sd 2:0:0:0: [sdb] Write Protect is off
sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support
DPO or FUA
sd 2:0:0:0: [sdb] 781422768 ...FLUSH_CACHE .. I would hope the firmware supports that if advertised. If so then adding it to the switch in it821x_smart_qc_issue might do the trick (ATA_CMD_FLUSH and ATA_CMD_FLUSH_EXT). I'd be interested to know if your firmware seems to support that or whether the entire thing goes castors up if it gets through. Alan --
It breaks - I get more errors and it takes ages to reboot. Looks like the
firmware does not like that command. I don't believe that it's so stupid - is
it even possible to safely turn off the machine when neither FLUSH nor STOP
command can be issued?
sd 2:0:0:0: [sdb] Synchronizing SCSI cache
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata3.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata3.00: status: { DRDY }
ata3: port is slow to respond, please be patient (Status 0xd0)
ata3: device not ready (errno=-16), forcing hardreset
ata3: soft resetting link
ata3.00: configured for DMA
ata3: EH complete
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata3.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata3.00: status: { DRDY }
ata3: port is slow to respond, please be patient (Status 0xd0)
ata3: device not ready (errno=-16), forcing hardreset
ata3: soft resetting link
ata3.00: configured for DMA
ata3: EH complete
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata3.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata3.00: status: { DRDY }
ata3: port is slow to respond, please be patient (Status 0xd0)
ata3: device not ready (errno=-16), forcing hardreset
ata3: soft resetting link
ata3.00: configured for DMA
ata3: EH complete
ata3.00: limiting speed to UDMA/133:PIO6
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata3.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata3.00: status: { DRDY }
ata3: port is slow to respond, please be patient (Status 0xd0)
ata3: device not ready (errno=-16), forcing hardreset
ata3: soft resetting link
ata3.00: configured for DMA
ata3: EH complete
ata3.00: exception Emask 0x0 SAct 0x0 SErr ...Hello, commenting out the error check after ata_dev_init_params() call in ata_dev_read_id() function (libata-core.c), I got at least the device name. The capacity is 0 so it doesn't work, obviously: pata_it821x: controller in smart mode. ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11 ACPI: PCI Interrupt 0000:00:12.0[A] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11 PCI: Setting latency timer of device 0000:00:12.0 to 64 scsi2 : pata_it821x scsi3 : pata_it821x ata3: PATA max MWDMA2 cmd 0x6800 ctl 0x6c00 bmdma 0x7800 irq 11 ata4: PATA max MWDMA2 cmd 0x7000 ctl 0x7400 bmdma 0x7808 irq 11 ata3.00: ATA-7: SAMSUNG HD400LD, WQ100-15, max UDMA/100 ata3.00: 781422768 sectors, multi 0: LBA48 ata3.01: ATA-0: Integrated Technology Express Inc, , max MWDMA2 ata3.01: 0 sectors, multi 0, CHS 0/0/0 IT821x RAID1 volume. ata3.00: configured for DMA ata3.01: configured for PIO scsi 2:0:0:0: Direct-Access ATA SAMSUNG HD400LD WQ10 PQ: 0 ANSI: 5 sd 2:0:0:0: [sdb] 781422768 512-byte hardware sectors (400088 MB) sd 2:0:0:0: [sdb] Write Protect is off sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00 sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 2:0:0:0: [sdb] 781422768 512-byte hardware sectors (400088 MB) sd 2:0:0:0: [sdb] Write Protect is off sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00 sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdb: sdb1 sdb2 sdb3 sdb4 sd 2:0:0:0: [sdb] Attached SCSI disk sd 2:0:0:0: Attached scsi generic sg2 type 0 scsi 2:0:1:0: Direct-Access ATA Integrated Techn n/a PQ: 0 ANSI: 5 sd 2:0:1:0: [sdc] Too big for this kernel. Use a kernel compiled with support for large block devices. sd 2:0:1:0: [sdc] 0 512-byte hardware sectors (0 MB) sd 2:0:1:0: [sdc] Write Protect is off sd 2:0:1:0: [sdc] Mode Sense: 00 3a 00 00 sd 2:0:1:0: [sdc] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA sd 2:0:1:0: [sdc] Attached SCSI disk sd 2:0:1:0: Attached ...
Some more details: ata_dev_read_id() is calling ata_dev_init_params with 0 heads and 0 sectors. Also ata_id_n_sectors returns 0 (through the last return statement (return id[1] * id[3] * id[6]). I captured the IDENTIFY data from the virtual device. I'm not ATA guru but looking at the data, there are zeros at many places where something should be. That number starting at 0x78 looks like size of the array in sectors (0x4C726C or 0x4C6C72 - the array is built from 2.5GB and 6.4GB drives). ADDRESS 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F ASCII ------------------------------------------------------------------------------- 0x00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0x00000010 00 00 00 00 20 08 11 07 18 06 17 05 01 01 00 0A .... ........... 0x00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0x00000030 00 00 00 00 00 00 49 6E 74 65 67 72 61 74 65 64 ......Integrated 0x00000040 20 54 65 63 68 6E 6F 6C 6F 67 79 20 45 78 70 72 Technology Expr 0x00000050 65 73 73 20 49 6E 63 20 20 20 20 20 20 20 00 00 ess Inc .. 0x00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0x00000070 00 00 00 00 00 00 00 00 6C 72 00 4C 00 00 00 07 ........lr.L.... 0x00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0x00000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0x000000A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0x000000B0 00 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0x000000C0 00 00 00 00 00 00 00 00 6C 72 00 4C 00 00 00 00 ........lr.L.... 0x000000D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0x000000E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0x000000F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0x00000100 00 00 00 01 00 0C 31 33 21 21 91 11 00 91 32 66 ......13!!....2f 0x00000110 ...
The Ident data for the virtual device is fairly sparse but the specs don't require a lot of the field are filled in and only the LBA really matters. --
The problem is that ata_id_n_sectors() function:
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];
}
}
fails to retrieve the LBA48 value.
This is because the ata_id_has_lba() test
#define ata_id_has_lba(id) ((id)[49] & (1 << 9))
fails as the identify data contains only zeros at word 49 (byte 0x62).
Another problem is that ata_id_has_lba48() would fail too - that will break
array over 2TB (if the controller BIOS and firmware can do it).
Looks like this needs to force LBA48 with these virtual drives.
--
Ondrej Zary
--
The patch below fixes the IDENTIFY problem for me and makes the RAID array accessible.
Is it OK or is there a better way to do it?
--- linux-2.6.25.3-orig/drivers/ata/libata-core.c 2008-07-13 12:27:56.000000000 +0200
+++ linux-2.6.25.3-pentium/drivers/ata/libata-core.c 2008-07-13 13:30:51.000000000 +0200
@@ -2217,7 +2217,8 @@
* Note that ATA4 says lba is mandatory so the second check
* shoud never trigger.
*/
- if (ata_id_major_version(id) < 4 || !ata_id_has_lba(id)) {
+ if ((ata_id_major_version(id) < 4 || !ata_id_has_lba(id)) &&
+ id[3] != 0 && id[6] != 0) {
err_mask = ata_dev_init_params(dev, id[3], id[6]);
if (err_mask) {
rc = -EIO;
@@ -2375,18 +2376,23 @@
"not be fully accessable.\n");
}
- dev->n_sectors = ata_id_n_sectors(id);
+ if (dev->horkage & ATA_HORKAGE_LBA48_FORCE)
+ dev->n_sectors = ata_id_u64(id, 100);
+ else
+ dev->n_sectors = ata_id_n_sectors(id);
if (dev->id[59] & 0x100)
dev->multi_count = dev->id[59] & 0xff;
- if (ata_id_has_lba(id)) {
+ if (ata_id_has_lba(id) ||
+ dev->horkage & ATA_HORKAGE_LBA48_FORCE) {
const char *lba_desc;
char ncq_desc[20];
lba_desc = "LBA";
dev->flags |= ATA_DFLAG_LBA;
- if (ata_id_has_lba48(id)) {
+ if (ata_id_has_lba48(id) ||
+ dev->horkage & ATA_HORKAGE_LBA48_FORCE) {
dev->flags |= ATA_DFLAG_LBA48;
lba_desc = "LBA48";
@@ -4452,6 +4458,9 @@
{ "TSSTcorp CDDVDW SH-S202N", "SB00", ATA_HORKAGE_IVB, },
{ "TSSTcorp CDDVDW SH-S202N", "SB01", ATA_HORKAGE_IVB, },
+ /* Has LBA48 but advertises neither LBA nor LBA48 */
+ { "Integrated Technology Express Inc", NULL, ATA_HORKAGE_LBA48_FORCE, },
+
/* End Marker */
{ }
};
--- linux-2.6.25.3-orig/include/linux/libata.h 2008-07-13 12:28:50.000000000 +0200
+++ linux-2.6.25.3-pentium/include/linux/libata.h 2008-07-13 11:29:39.000000000 +0200
@@ -339,6 +339,7 @@
ATA_HORKAGE_IPM = (1 << 7), /* Link PM problems */
ATA_HORKAGE_IVB = (1 << 8), /* ...Probably better to fix it in driver. Right now we don't have a way to override the identify reading or post process it cleanly at it821x hacks around that but if that was fixed then the special cases can all hide in That depends on the firmware revision it seems. Mine are fine --
That would be great but it requires some deeper libata and kernel programming Too bad it doesn't report any firmware revision :( I think that this should not harm a working IT8212 controller. -- Ondrej Zary --
On Sun, 13 Jul 2008 14:10:14 +0200 Not a lot I think so I've added it to my todo list if nobody else does it. --
New patch below, this time with DMA forced on RAID volumes - as my firmware
does not identify the RAID arrays as DMA capable :(
diff -ur linux-2.6.26/drivers/ata/libata-core.c linux-2.6.26-pentium/drivers/ata/libata-core.c
--- linux-2.6.26/drivers/ata/libata-core.c 2008-07-13 23:51:29.000000000 +0200
+++ linux-2.6.26-pentium/drivers/ata/libata-core.c 2008-07-16 20:50:33.000000000 +0200
@@ -2030,7 +2030,8 @@
* Note that ATA4 says lba is mandatory so the second check
* shoud never trigger.
*/
- if (ata_id_major_version(id) < 4 || !ata_id_has_lba(id)) {
+ if ((ata_id_major_version(id) < 4 || !ata_id_has_lba(id)) &&
+ id[3] != 0 && id[6] != 0) {
err_mask = ata_dev_init_params(dev, id[3], id[6]);
if (err_mask) {
rc = -EIO;
@@ -2195,18 +2196,23 @@
"not be fully accessable.\n");
}
- dev->n_sectors = ata_id_n_sectors(id);
+ if (dev->horkage & ATA_HORKAGE_LBA48_FORCE)
+ dev->n_sectors = ata_id_u64(id, 100);
+ else
+ dev->n_sectors = ata_id_n_sectors(id);
if (dev->id[59] & 0x100)
dev->multi_count = dev->id[59] & 0xff;
- if (ata_id_has_lba(id)) {
+ if (ata_id_has_lba(id) ||
+ dev->horkage & ATA_HORKAGE_LBA48_FORCE) {
const char *lba_desc;
char ncq_desc[20];
lba_desc = "LBA";
dev->flags |= ATA_DFLAG_LBA;
- if (ata_id_has_lba48(id)) {
+ if (ata_id_has_lba48(id) ||
+ dev->horkage & ATA_HORKAGE_LBA48_FORCE) {
dev->flags |= ATA_DFLAG_LBA48;
lba_desc = "LBA48";
@@ -3946,6 +3952,9 @@
{ "TSSTcorp CDDVDW SH-S202N", "SB00", ATA_HORKAGE_IVB, },
{ "TSSTcorp CDDVDW SH-S202N", "SB01", ATA_HORKAGE_IVB, },
+ /* Has LBA48 but advertises neither LBA nor LBA48 */
+ { "Integrated Technology Express Inc", NULL, ATA_HORKAGE_LBA48_FORCE, },
+
/* End Marker */
{ }
};
diff -ur linux-2.6.26/drivers/ata/pata_it821x.c linux-2.6.26-pentium/drivers/ata/pata_it821x.c
--- linux-2.6.26/drivers/ata/pata_it821x.c 2008-07-13 23:51:29.000000000 +0200
+++ ...The underlying problem is that the newer libata rewrites the dev->id data in ways that we can't then patch up. I've actually been hacking on this a bit today. The existing it821x code was working fine and it does the needed patching, it just needs to do it in a different place, and that in turn needs a new ap->ops->read_id() method so it can be hooked. On the bright side that also allows us to implement a pata_mfm/rll driver at last. Alan --
I can test the code once it's done. I just moved my / to the RAID1 provided by IT8212. The controller has a great feature that allows converting a drive between RAID1/standalone without data loss (haven't seen anything like this yet). Also the background rebuild is nice (as seen on much more expensive RAID controllers), it's running as I'm I used to have an old drive that was something like that - 5.25" Seagate 40MB drive. I sold it including the controller a couple of years ago (it was still -- Ondrej Zary --
Looking at a Western Digital "FileCard 30" consisting of a Seagate ST-125 and WDQC16 8-bit ISA controller. MFM I believe. I put a sticker on it with: "io=0x320, irq=5, dma=3 615/4/26 (or 614)" The thing has its own BIOS and if If I'm not mistaken it could only live in an AT+ with all other drives in the BIOS turned of. This might mean I'd be capable of testing it from a boot-floppy only but if you desperately want a tester, I'll try to volunteer ;-) I remember using DOS "debug" to jump into its BIOS low-level format routine so I did get it doing something... Rene. --
