* pata_it821x completely broken @ 2008-07-04 19:53 Ondrej Zary 2008-07-04 20:22 ` Alan Cox 0 siblings, 1 reply; 26+ messages in thread From: Ondrej Zary @ 2008-07-04 19:53 UTC (permalink / raw) To: alan; +Cc: LKML, linux-ide 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: pata_it821x completely broken 2008-07-04 19:53 pata_it821x completely broken Ondrej Zary @ 2008-07-04 20:22 ` Alan Cox 2008-07-04 21:39 ` Ondrej Zary 0 siblings, 1 reply; 26+ messages in thread From: Alan Cox @ 2008-07-04 20:22 UTC (permalink / raw) To: Ondrej Zary; +Cc: alan, LKML, linux-ide > 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: pata_it821x completely broken 2008-07-04 20:22 ` Alan Cox @ 2008-07-04 21:39 ` Ondrej Zary 2008-07-04 21:46 ` Alan Cox 0 siblings, 1 reply; 26+ messages in thread From: Ondrej Zary @ 2008-07-04 21:39 UTC (permalink / raw) To: Alan Cox; +Cc: alan, LKML, linux-ide 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: pata_it821x completely broken 2008-07-04 21:39 ` Ondrej Zary @ 2008-07-04 21:46 ` Alan Cox 2008-07-05 10:41 ` Ondrej Zary 0 siblings, 1 reply; 26+ messages in thread From: Alan Cox @ 2008-07-04 21:46 UTC (permalink / raw) To: Ondrej Zary; +Cc: alan, LKML, linux-ide > 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: pata_it821x completely broken 2008-07-04 21:46 ` Alan Cox @ 2008-07-05 10:41 ` Ondrej Zary 2008-07-05 15:49 ` Alan Cox 2008-07-06 19:37 ` Alan Cox 0 siblings, 2 replies; 26+ messages in thread From: Ondrej Zary @ 2008-07-05 10:41 UTC (permalink / raw) To: Alan Cox; +Cc: alan, LKML, linux-ide 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: pata_it821x completely broken 2008-07-05 10:41 ` Ondrej Zary @ 2008-07-05 15:49 ` Alan Cox 2008-07-06 21:03 ` Ondrej Zary 2008-07-06 19:37 ` Alan Cox 1 sibling, 1 reply; 26+ messages in thread From: Alan Cox @ 2008-07-05 15:49 UTC (permalink / raw) To: Ondrej Zary; +Cc: Alan Cox, alan, LKML, linux-ide 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: pata_it821x completely broken 2008-07-05 15:49 ` Alan Cox @ 2008-07-06 21:03 ` Ondrej Zary 2008-07-06 20:51 ` Alan Cox 0 siblings, 1 reply; 26+ messages in thread From: Ondrej Zary @ 2008-07-06 21:03 UTC (permalink / raw) To: Alan Cox; +Cc: Alan Cox, LKML, linux-ide 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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Ondrej Zary ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: pata_it821x completely broken 2008-07-06 21:03 ` Ondrej Zary @ 2008-07-06 20:51 ` Alan Cox 2008-07-06 21:46 ` Ondrej Zary 0 siblings, 1 reply; 26+ messages in thread From: Alan Cox @ 2008-07-06 20:51 UTC (permalink / raw) To: Ondrej Zary; +Cc: Alan Cox, LKML, linux-ide > 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: pata_it821x completely broken 2008-07-06 20:51 ` Alan Cox @ 2008-07-06 21:46 ` Ondrej Zary 0 siblings, 0 replies; 26+ messages in thread From: Ondrej Zary @ 2008-07-06 21:46 UTC (permalink / raw) To: Alan Cox; +Cc: Alan Cox, LKML, linux-ide 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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Ondrej Zary ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: pata_it821x completely broken 2008-07-05 10:41 ` Ondrej Zary 2008-07-05 15:49 ` Alan Cox @ 2008-07-06 19:37 ` Alan Cox 2008-07-06 21:50 ` Ondrej Zary 1 sibling, 1 reply; 26+ messages in thread From: Alan Cox @ 2008-07-06 19:37 UTC (permalink / raw) To: Ondrej Zary; +Cc: alan, LKML, linux-ide > 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 <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); } ^ permalink raw reply related [flat|nested] 26+ messages in thread
* Re: pata_it821x completely broken 2008-07-06 19:37 ` Alan Cox @ 2008-07-06 21:50 ` Ondrej Zary 2008-07-06 23:01 ` Alan Cox 0 siblings, 1 reply; 26+ messages in thread From: Ondrej Zary @ 2008-07-06 21:50 UTC (permalink / raw) To: Alan Cox; +Cc: alan, LKML, linux-ide 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 <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); > } -- Ondrej Zary ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: pata_it821x completely broken 2008-07-06 21:50 ` Ondrej Zary @ 2008-07-06 23:01 ` Alan Cox 2008-07-07 18:07 ` Ondrej Zary 2008-07-10 20:35 ` Ondrej Zary 0 siblings, 2 replies; 26+ messages in thread From: Alan Cox @ 2008-07-06 23:01 UTC (permalink / raw) To: Ondrej Zary; +Cc: Alan Cox, alan, LKML, linux-ide 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: pata_it821x completely broken 2008-07-06 23:01 ` Alan Cox @ 2008-07-07 18:07 ` Ondrej Zary 2008-07-10 20:35 ` Ondrej Zary 1 sibling, 0 replies; 26+ messages in thread From: Ondrej Zary @ 2008-07-07 18:07 UTC (permalink / raw) To: Alan Cox; +Cc: Alan Cox, LKML, linux-ide 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: pata_it821x completely broken 2008-07-06 23:01 ` Alan Cox 2008-07-07 18:07 ` Ondrej Zary @ 2008-07-10 20:35 ` Ondrej Zary 2008-07-11 18:43 ` Ondrej Zary 1 sibling, 1 reply; 26+ messages in thread From: Ondrej Zary @ 2008-07-10 20:35 UTC (permalink / raw) To: Alan Cox; +Cc: Alan Cox, LKML, linux-ide 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: pata_it821x completely broken 2008-07-10 20:35 ` Ondrej Zary @ 2008-07-11 18:43 ` Ondrej Zary 2008-07-11 20:14 ` Alan Cox 0 siblings, 1 reply; 26+ messages in thread From: Ondrej Zary @ 2008-07-11 18:43 UTC (permalink / raw) To: Alan Cox; +Cc: Alan Cox, LKML, linux-ide 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: pata_it821x completely broken 2008-07-11 18:43 ` Ondrej Zary @ 2008-07-11 20:14 ` Alan Cox 2008-07-12 21:42 ` Ondrej Zary 0 siblings, 1 reply; 26+ messages in thread From: Alan Cox @ 2008-07-11 20:14 UTC (permalink / raw) To: Ondrej Zary; +Cc: Alan Cox, LKML, linux-ide > > 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: pata_it821x completely broken 2008-07-11 20:14 ` Alan Cox @ 2008-07-12 21:42 ` Ondrej Zary 2008-07-13 11:47 ` Ondrej Zary 0 siblings, 1 reply; 26+ messages in thread From: Ondrej Zary @ 2008-07-12 21:42 UTC (permalink / raw) To: Alan Cox; +Cc: Alan Cox, LKML, linux-ide 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: pata_it821x completely broken 2008-07-12 21:42 ` Ondrej Zary @ 2008-07-13 11:47 ` Ondrej Zary 2008-07-13 11:35 ` Alan Cox 2008-07-22 17:59 ` Ondrej Zary 0 siblings, 2 replies; 26+ messages in thread From: Ondrej Zary @ 2008-07-13 11:47 UTC (permalink / raw) To: Alan Cox; +Cc: Alan Cox, LKML, linux-ide 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: pata_it821x completely broken 2008-07-13 11:47 ` Ondrej Zary @ 2008-07-13 11:35 ` Alan Cox 2008-07-13 12:10 ` Ondrej Zary 2008-07-22 17:59 ` Ondrej Zary 1 sibling, 1 reply; 26+ messages in thread From: Alan Cox @ 2008-07-13 11:35 UTC (permalink / raw) To: Ondrej Zary; +Cc: Alan Cox, LKML, linux-ide > 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: pata_it821x completely broken 2008-07-13 11:35 ` Alan Cox @ 2008-07-13 12:10 ` Ondrej Zary 2008-07-13 14:08 ` Alan Cox 0 siblings, 1 reply; 26+ messages in thread From: Ondrej Zary @ 2008-07-13 12:10 UTC (permalink / raw) To: Alan Cox; +Cc: Alan Cox, LKML, linux-ide 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: pata_it821x completely broken 2008-07-13 12:10 ` Ondrej Zary @ 2008-07-13 14:08 ` Alan Cox 0 siblings, 0 replies; 26+ messages in thread From: Alan Cox @ 2008-07-13 14:08 UTC (permalink / raw) To: Ondrej Zary; +Cc: Alan Cox, LKML, linux-ide On Sun, 13 Jul 2008 14:10:14 +0200 Ondrej Zary <linux@rainbow-software.org> 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: pata_it821x completely broken 2008-07-13 11:47 ` Ondrej Zary 2008-07-13 11:35 ` Alan Cox @ 2008-07-22 17:59 ` Ondrej Zary 2008-07-22 18:10 ` Alan Cox 1 sibling, 1 reply; 26+ messages in thread From: Ondrej Zary @ 2008-07-22 17:59 UTC (permalink / raw) To: Alan Cox; +Cc: Alan Cox, LKML, linux-ide 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: pata_it821x completely broken 2008-07-22 17:59 ` Ondrej Zary @ 2008-07-22 18:10 ` Alan Cox 2008-07-22 19:16 ` Ondrej Zary 0 siblings, 1 reply; 26+ messages in thread From: Alan Cox @ 2008-07-22 18:10 UTC (permalink / raw) To: Ondrej Zary; +Cc: Alan Cox, LKML, linux-ide > 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: pata_it821x completely broken 2008-07-22 18:10 ` Alan Cox @ 2008-07-22 19:16 ` Ondrej Zary 2008-07-22 19:35 ` Rene Herman 0 siblings, 1 reply; 26+ messages in thread From: Ondrej Zary @ 2008-07-22 19:16 UTC (permalink / raw) To: Alan Cox; +Cc: Alan Cox, LKML, linux-ide 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: pata_it821x completely broken 2008-07-22 19:16 ` Ondrej Zary @ 2008-07-22 19:35 ` Rene Herman 2008-07-22 20:39 ` Alan Cox 0 siblings, 1 reply; 26+ messages in thread From: Rene Herman @ 2008-07-22 19:35 UTC (permalink / raw) To: Ondrej Zary; +Cc: Alan Cox, Alan Cox, LKML, linux-ide 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: pata_it821x completely broken 2008-07-22 19:35 ` Rene Herman @ 2008-07-22 20:39 ` Alan Cox 0 siblings, 0 replies; 26+ messages in thread From: Alan Cox @ 2008-07-22 20:39 UTC (permalink / raw) To: Rene Herman; +Cc: Ondrej Zary, Alan Cox, LKML, linux-ide > 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) ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2008-07-22 20:57 UTC | newest] Thread overview: 26+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-07-04 19:53 pata_it821x completely broken Ondrej Zary 2008-07-04 20:22 ` Alan Cox 2008-07-04 21:39 ` Ondrej Zary 2008-07-04 21:46 ` Alan Cox 2008-07-05 10:41 ` Ondrej Zary 2008-07-05 15:49 ` Alan Cox 2008-07-06 21:03 ` Ondrej Zary 2008-07-06 20:51 ` Alan Cox 2008-07-06 21:46 ` Ondrej Zary 2008-07-06 19:37 ` Alan Cox 2008-07-06 21:50 ` Ondrej Zary 2008-07-06 23:01 ` Alan Cox 2008-07-07 18:07 ` Ondrej Zary 2008-07-10 20:35 ` Ondrej Zary 2008-07-11 18:43 ` Ondrej Zary 2008-07-11 20:14 ` Alan Cox 2008-07-12 21:42 ` Ondrej Zary 2008-07-13 11:47 ` Ondrej Zary 2008-07-13 11:35 ` Alan Cox 2008-07-13 12:10 ` Ondrej Zary 2008-07-13 14:08 ` Alan Cox 2008-07-22 17:59 ` Ondrej Zary 2008-07-22 18:10 ` Alan Cox 2008-07-22 19:16 ` Ondrej Zary 2008-07-22 19:35 ` Rene Herman 2008-07-22 20:39 ` Alan Cox
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).