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: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_masl=0x80)
ata3: failed to recover some devices, retrying in 5 secs
I'm going to start debugging, suggestions are welcome.
--
Ondrej Zary
> When I don't have any RAID array created, both drives are detected but it
> appears to work only in MWDMA2 mode:
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
video capture boxes) in non RAID mode ;)
> ata3: PATA max MWDMA2 cmd 0x6800 ctl 0x6c00 bmdma 0x7800 irq 11
> ata4: PATA max MWDMA2 cmd 0x7000 ctl 0x7400 bmdma 0x7808 irq 11
I'll have a poke at that, see if I can make it lie more meaningfully
> ata4.00: configured for DMA
as it does here.
> Also I get some errors about HPA when rebooting but haven't captured them yet.
IT821x does not support the HPA in 'raid' mode, only in non RAID mode so
it would complain about the HPA.
> But the more interesting thing is that once I create a RAID1 array (and run
> background rebuild), the driver does not work anymore:
Ok that is a bug I've not met. What firmware revision is this and does it
work after the rebuild is done ?
> 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: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_masl=0x80)
> ata3: failed to recover some devices, retrying in 5 secs
It seems to have decided to be indefinitely busy from that.
Alan
On Friday 04 July 2008 22:22:04 Alan Cox wrote:
> > When I don't have any RAID array created, both drives are detected but it
> > appears to work only in MWDMA2 mode:
>
> 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
> video capture boxes) in non RAID mode ;)
>
> > ata3: PATA max MWDMA2 cmd 0x6800 ctl 0x6c00 bmdma 0x7800 irq 11
> > ata4: PATA max MWDMA2 cmd 0x7000 ctl 0x7400 bmdma 0x7808 irq 11
>
> I'll have a poke at that, see if I can make it lie more meaningfully
>
> > ata4.00: configured for DMA
>
> as it does here.
OK, so it's not a bug, it's a (missing) feature.
>
> > Also I get some errors about HPA when rebooting but haven't captured them
> > yet.
>
> IT821x does not support the HPA in 'raid' mode, only in non RAID mode so
> it would complain about the HPA.
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
don't know libata internals).
>
> > But the more interesting thing is that once I create a RAID1 array (and
> > run background rebuild), the driver does not work anymore:
>
> Ok that is a bug I've not met. What firmware revision is this and does it
> work after the rebuild is done ?
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
much smaller drives (something <1GB).
>
> > 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: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_masl=0x80)
> > ata3: failed to recover some devices, retrying in 5 secs
>
> It seems to have decided to be indefinitely busy from that.
>
> Alan
--
Ondrej Zary
> It complains pretty loudly - something like 3 screens (with framebuffer at
> 1024x768) of errors like this:
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
the command through.
> 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
> much smaller drives (something <1GB).
Thanks
On Friday 04 July 2008 23:46:36 Alan Cox wrote:
> > It complains pretty loudly - something like 3 screens (with framebuffer
> > at 1024x768) of errors like this:
>
> 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
> the command through.
>
> > 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 much smaller drives (something <1GB).
>
> 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, multi 0: LBA48
ata3.01: ATA-4: ST36531A, 3.11, max UDMA/33
ata3.01: 12706470 sectors, multi 0: LBA
ata3.00: configured for UDMA/100
ata3.01: configured for UDMA/33
ata4.00: ATA-7: SAMSUNG HD400LD, WQ100-15, max UDMA/100
ata4.00: 781422768 sectors, multi 0: LBA48
ata4.01: ATA-4: QUANTUM FIREBALL EL2.5A, A08.1100, max UDMA/33
ata4.01: 5008500 sectors, multi 0: LBA
ata4.00: limited to UDMA/33 due to 40-wire cable
ata4.00: configured for UDMA/33
ata4.01: configured for UDMA/33
Then I created RAID 1 from the Seagate and Quantum drives. No matter if the
rebuild process is running or not, the result is the same - the drives that
form RAID aren't accessible, the other drives work:
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
(the secondary slave is missing - interesting)
--
Ondrej Zary
On Sat, Jul 05, 2008 at 12:41:58PM +0200, Ondrej Zary wrote:
> 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
I've no idea if the BIOS firmware mode can do MWDMA to the drives. The actual
interface between the card and the kernel has no mode stuff at all.
> 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:
Interesting and definitely sounds like a bug.
>
> Then I created RAID 1 from the Seagate and Quantum drives. No matter if the
> rebuild process is running or not, the result is the same - the drives that
> form RAID aren't accessible, the other drives work:
I would imagine the controller fakes a hotplug event when the rebuild finishes
but that is guessing. The firmware mode is pretty minimally documented.
> 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:
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 <[email protected]>
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);
}
On Saturday 05 July 2008 17:49:51 Alan Cox wrote:
> On Sat, Jul 05, 2008 at 12:41:58PM +0200, Ondrej Zary wrote:
> > 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
>
> I've no idea if the BIOS firmware mode can do MWDMA to the drives. The
> actual interface between the card and the kernel has no mode stuff at all.
>
> > 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:
>
> Interesting and definitely sounds like a bug.
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 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 PIO3
ata4: EH complete
sd 3:0:0:0: [sdc] Write Protect is off
ata4.01: limiting speed to PIO2
ata4.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
ata4.01: cmd 20/00:08:00:00:00/00:00:00:00:00/f0 tag 0 pio 4096 in
res 51/04:08:00:00:00/00:00:00:00:00/f0 Emask 0x1 (device error)
ata4.01: status: { DRDY ERR }
ata4.01: error: { ABRT }
ata4: soft resetting link
ata4.00: configured for UDMA/100
ata4.01: configured for PIO2
ata4: EH complete
ata4.01: limiting speed to PIO0
ata4.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
ata4.01: cmd 20/00:08:00:00:00/00:00:00:00:00/f0 tag 0 pio 4096 in
res 51/04:08:00:00:00/00:00:00:00:00/f0 Emask 0x1 (device error)
ata4.01: status: { DRDY ERR }
ata4.01: error: { ABRT }
ata4: soft resetting link
ata4.00: configured for UDMA/100
ata4.01: configured for PIO0
ata4: EH complete
sd 3:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support
DPO or FUA
ata4.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata4.01: cmd 20/00:08:00:00:00/00:00:00:00:00/f0 tag 0 pio 4096 in
res 51/04:08:00:00:00/00:00:00:00:00/f0 Emask 0x1 (device error)
ata4.01: status: { DRDY ERR }
ata4.01: error: { ABRT }
ata4.00: configured for UDMA/100
ata4.01: configured for PIO0
sd 3:0:1:0: [sdd] Result: hostbyte=0x00 driverbyte=0x08
sd 3:0:1:0: [sdd] Sense Key : 0xb [current] [descriptor]
Descriptor sense data with sense descriptors (in hex):
72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00
00 00 00 00
sd 3:0:1:0: [sdd] ASC=0x0 ASCQ=0x0
...
Maxtor 7270 AV - is detected by firmware but oopses in Linux:
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
irq 11: nobody cared (try booting with the "irqpoll" option)
Pid: 1, comm: swapper Not tainted 2.6.25.3-pentium #5
[<c012f48f>] __report_bad_irq+0x24/0x69
[<c012f496>] __report_bad_irq+0x2b/0x69
[<c012f680>] note_interrupt+0x1ac/0x1e4
[<c012ee21>] handle_IRQ_event+0x1a/0x3f
[<c012fcda>] handle_level_irq+0x0/0x8a
[<c012fd27>] handle_level_irq+0x4d/0x8a
[<c01051bb>] do_IRQ+0x78/0x9e
[<c0103c53>] common_interrupt+0x23/0x30
[<c013007b>] init_irq_proc+0x6/0x27
[<c0115f59>] __do_softirq+0x2f/0x75
[<c0105111>] do_softirq+0x3b/0x6d
[<c012fcda>] handle_level_irq+0x0/0x8a
[<c0115efc>] irq_exit+0x25/0x53
[<c01051ce>] do_IRQ+0x8b/0x9e
[<c0103c53>] common_interrupt+0x23/0x30
[<c012f214>] setup_irq+0x11f/0x149
[<c0120060>] cpu_clock_sample_group_locked+0x2/0xd3
[<c023ce84>] ata_interrupt+0x0/0x1cc
[<c012f2b5>] request_irq+0x77/0x93
[<c023ce84>] ata_interrupt+0x0/0x1cc
[<c012fe0c>] devm_request_irq+0x42/0x6e
[<c02403a6>] ata_pci_activate_sff_host+0xb4/0x19f
[<c023ce84>] ata_interrupt+0x0/0x1cc
[<c0240850>] ata_pci_init_one+0x8c/0xd5
[<c02475b5>] it821x_init_one+0x87/0x8c
[<c01c632b>] pci_device_probe+0x36/0x55
[<c021f6ce>] driver_probe_device+0x9c/0x112
[<c021f824>] __driver_attach+0x50/0x83
[<c021ed53>] bus_for_each_dev+0x31/0x52
[<c021f582>] driver_attach+0x11/0x13
[<c021f7d4>] __driver_attach+0x0/0x83
[<c021f3c2>] bus_add_driver+0x91/0x193
[<c021f9bd>] driver_register+0x45/0x9a
[<c01c64bf>] __pci_register_driver+0x2b/0x58
[<c0397600>] kernel_init+0x92/0x1d0
[<c010fe52>] schedule_tail+0xe/0x39
[<c01038a6>] ret_from_fork+0x6/0x20
[<c039756e>] kernel_init+0x0/0x1d0
[<c039756e>] kernel_init+0x0/0x1d0
[<c0103d77>] kernel_thread_helper+0x7/0x10
=======================
handlers:
[<c023ce84>] (ata_interrupt+0x0/0x1cc)
Disabling 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
>
> > Then I created RAID 1 from the Seagate and Quantum drives. No matter if
> > the rebuild process is running or not, the result is the same - the
> > drives that form RAID aren't accessible, the other drives work:
>
> I would imagine the controller fakes a hotplug event when the rebuild
> finishes but that is guessing. The firmware mode is pretty minimally
> documented.
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Ondrej Zary
> Maxtor 7270 AV - is detected by firmware but oopses in Linux:
>
> 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
> irq 11: nobody cared (try booting with the "irqpoll" option)
> Pid: 1, comm: swapper Not tainted 2.6.25.3-pentium #5
> [<c012f48f>] __report_bad_irq+0x24/0x69
> [<c012f496>] __report_bad_irq+0x2b/0x69
Please file a bug for this - that's upsetting the core libata code
somewhere, perhaps from a left over floating interrupt.
Alan
On Sunday 06 July 2008 22:51:46 Alan Cox wrote:
> > Maxtor 7270 AV - is detected by firmware but oopses in Linux:
> >
> > 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
> > irq 11: nobody cared (try booting with the "irqpoll" option)
> > Pid: 1, comm: swapper Not tainted 2.6.25.3-pentium #5
> > [<c012f48f>] __report_bad_irq+0x24/0x69
> > [<c012f496>] __report_bad_irq+0x2b/0x69
>
> Please file a bug for this - that's upsetting the core libata code
> somewhere, perhaps from a left over floating interrupt.
Here it is: http://bugzilla.kernel.org/show_bug.cgi?id=11047
>
> Alan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Ondrej Zary
On Sunday 06 July 2008 21:37:16 Alan Cox wrote:
> > 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:
>
> Couldn't reproduce that yet but the HPA case should be fixed by the
> following patch:
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 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
ata3.00: limiting speed to UDMA/133:PIO6
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
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: soft resetting link
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 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
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: limiting speed to UDMA/33:PIO6
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
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: soft resetting link
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 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] Result: hostbyte=0x00 driverbyte=0x08
sd 2:0:0:0: [sdb] Sense Key : 0xb [current] [descriptor]
sd 2:0:0:0: [sdb] ASC=0x0 ASCQ=0x0
Restarting system.
machine restart
>
> pata_it821x: With newer firmware we see HPA flags
>
> From: Alan Cox <[email protected]>
>
> 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);
> }
--
Ondrej Zary
On Sun, Jul 06, 2008 at 11:50:33PM +0200, Ondrej Zary wrote:
> 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:
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
On Monday 07 July 2008 01:01:18 Alan Cox wrote:
> On Sun, Jul 06, 2008 at 11:50:33PM +0200, Ondrej Zary wrote:
> > 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:
>
> 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.
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 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
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 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
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/33: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 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: 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
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 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
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 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 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
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 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] Result: hostbyte=0x00 driverbyte=0x08
sd 2:0:0:0: [sdb] Sense Key : 0xb [current] [descriptor]
sd 2:0:0:0: [sdb] ASC=0x0 ASCQ=0x0
Restarting system.
machine restart
>
> Alan
--
Ondrej Zary
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 scsi generic sg3 type 0
(0 is too big for the kernel, interesting :)
--
Ondrej Zary
On Thursday 10 July 2008 22:35:20 Ondrej Zary wrote:
> 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 scsi generic sg3 type 0
>
>
> (0 is too big for the kernel, interesting :)
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 00 21 00 21 00 01 05 05 00 05 05 00 00 00 00 05 .!.!............
0x00000120 00 05 00 05 00 40 00 00 00 00 00 00 00 00 00 00 .....@..........
0x00000130 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 ................
0x00000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x00000150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x00000160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x00000170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x00000180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x00000190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x000001A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x000001B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x000001C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x000001D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x000001E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x000001F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
I've also looked at the driver source from ITE
http://www.ite.com.tw/product_info/file/pc/LinuxDriver_it8212_092005-09.zip
It contains some interesting structs and also one line of interesting text:
* Extra IDE commands supported by Accusys
--
Ondrej Zary
> > 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:
If you don't read the ID then it wouldn't.
> 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).
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.
On Friday 11 July 2008 22:14:09 Alan Cox wrote:
> > > 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:
>
> If you don't read the ID then it wouldn't.
>
> > 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).
>
> 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
On Saturday 12 July 2008 23:42:10 Ondrej Zary wrote:
> On Friday 11 July 2008 22:14:09 Alan Cox wrote:
> > > > 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:
> >
> > If you don't read the ID then it wouldn't.
> >
> > > 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).
> >
> > 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.
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), /* cbl det validity bit bugs */
ATA_HORKAGE_STUCK_ERR = (1 << 9), /* stuck ERR on next PACKET */
+ ATA_HORKAGE_LBA48_FORCE = (1 << 10), /* Has hidden LBA48 */
/* DMA mask for user DMA control: User visible values; DO NOT
renumber */
--
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?
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
the driver where they belong.
> + /* Has LBA48 but advertises neither LBA nor LBA48 */
> + { "Integrated Technology Express Inc", NULL, ATA_HORKAGE_LBA48_FORCE, },
That depends on the firmware revision it seems. Mine are fine
On Sunday 13 July 2008 13:35:10 Alan Cox wrote:
> > 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?
>
> 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
> the driver where they belong.
That would be great but it requires some deeper libata and kernel programming
knowledge.
>
> > + /* Has LBA48 but advertises neither LBA nor LBA48 */
> > + { "Integrated Technology Express Inc", NULL, ATA_HORKAGE_LBA48_FORCE,
> > },
>
> That depends on the firmware revision it seems. Mine are fine
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
Ondrej Zary <[email protected]> wrote:
> On Sunday 13 July 2008 13:35:10 Alan Cox wrote:
> > > 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?
> >
> > 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
> > the driver where they belong.
>
> That would be great but it requires some deeper libata and kernel programming
> knowledge.
Not a lot I think so I've added it to my todo list if nobody else does it.
On Sunday 13 July 2008 13:47:12 Ondrej Zary wrote:
> On Saturday 12 July 2008 23:42:10 Ondrej Zary wrote:
> > On Friday 11 July 2008 22:14:09 Alan Cox wrote:
> > > > > 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:
> > >
> > > If you don't read the ID then it wouldn't.
> > >
> > > > 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).
> > >
> > > 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.
>
> 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?
>
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
+++ linux-2.6.26-pentium/drivers/ata/pata_it821x.c 2008-07-22 19:56:14.000000000 +0200
@@ -462,15 +462,19 @@
static int it821x_smart_set_mode(struct ata_link *link, struct ata_device **unused)
{
struct ata_device *dev;
+ unsigned char model_num[ATA_ID_PROD_LEN + 1];
ata_link_for_each_dev(dev, link) {
if (ata_dev_enabled(dev)) {
/* We don't really care */
dev->pio_mode = XFER_PIO_0;
dev->dma_mode = XFER_MW_DMA_0;
+ ata_id_c_string(dev->id, model_num, ATA_ID_PROD,
+ sizeof(model_num));
/* We do need the right mode information for DMA or PIO
and this comes from the current configuration flags */
- if (ata_id_has_dma(dev->id)) {
+ if (ata_id_has_dma(dev->id) ||
+ strstr(model_num, "Integrated Technology Express")) {
ata_dev_printk(dev, KERN_INFO, "configured for DMA\n");
dev->xfer_mode = XFER_MW_DMA_0;
dev->xfer_shift = ATA_SHIFT_MWDMA;
diff -ur linux-2.6.26/include/linux/libata.h linux-2.6.26-pentium/include/linux/libata.h
--- linux-2.6.26/include/linux/libata.h 2008-07-13 23:51:29.000000000 +0200
+++ linux-2.6.26-pentium/include/linux/libata.h 2008-07-16 20:50:33.000000000 +0200
@@ -353,6 +353,7 @@
ATA_HORKAGE_IPM = (1 << 7), /* Link PM problems */
ATA_HORKAGE_IVB = (1 << 8), /* cbl det validity bit bugs */
ATA_HORKAGE_STUCK_ERR = (1 << 9), /* stuck ERR on next PACKET */
+ ATA_HORKAGE_LBA48_FORCE = (1 << 10), /* Has hidden LBA48 */
/* DMA mask for user DMA control: User visible values; DO NOT
renumber */
--
Ondrej Zary
> New patch below, this time with DMA forced on RAID volumes - as my firmware
> does not identify the RAID arrays as DMA capable :(
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
On Tuesday 22 July 2008 20:10:22 Alan Cox wrote:
> > New patch below, this time with DMA forced on RAID volumes - as my
> > firmware does not identify the RAID arrays as DMA capable :(
>
> 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.
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
typing this.
>
> On the bright side that also allows us to implement a pata_mfm/rll
> driver at last.
>
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
working) so no testing fun for me.
> Alan
--
Ondrej Zary
On 22-07-08 21:16, Ondrej Zary wrote:
> On Tuesday 22 July 2008 20:10:22 Alan Cox wrote:
>> On the bright side that also allows us to implement a pata_mfm/rll
>> driver at last.
>
> 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 working) so no testing fun for me.
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.
> 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)"
xt driver should support that including DMA 8)