PATA failure with piix, works with libata

PATA failure with piix, works with libata

[Matthew Garrett]

Hi,

I'm playing with an Intel Mac. Pretty much everything works to some 
extent (though it seems very unhappy with MSI), but I'm having some 
trouble with the built-in PATA controller. Using ata_piix (with PATA 
mode enabled), I get the following:

[4294851.590000] ata_piix 0000:00:1f.1: version 1.05
[4294851.590000] ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 201
[4294851.590000] PCI: Setting latency timer of device 0000:00:1f.1 to 64
[4294851.590000] ata7: PATA max UDMA/100 cmd 0x30E8 ctl 0x30FE bmdma 0x30C0 irq 201
[4294851.590000] ata8: PATA max UDMA/100 cmd 0x30E0 ctl 0x30FA bmdma 0x30C8 irq 201
[4294851.898000] ata7: dev 0 cfg 49:0f00 82:0000 83:0000 84:0000 85:0000 86:0000 87:0000 88:101f
[4294851.898000] ata7: dev 0 ATAPI, max UDMA/66
[4294851.898000] ata7: dev 0 configured for UDMA/66
[4294851.898000] scsi7 : ata_piix
[4294852.057000] ATA: abnormal status 0x7F on port 0x30E7
[4294852.057000] ata8: disabling port
[4294852.058000] scsi8 : ata_piix
[4294852.062000]   Vendor: MATSHITA  Model: DVD-R   UJ-846    Rev: FB2U
[4294852.062000]   Type:   CD-ROM                             ANSI SCSI revision: 05
[4294852.094000] sr0: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda tray
[4294852.094000] sr 7:0:0:0: Attached scsi CD-ROM sr0
[4294852.094000] sr 7:0:0:0: Attached scsi generic sg2 type 5

and everything is fine, including CD access. Loading piix gives me the 
following:

[4294929.054000] ICH7: IDE controller at PCI slot 0000:00:1f.1
[4294929.054000] ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 201
[4294929.054000] ICH7: chipset revision 2
[4294929.054000] ICH7: 100% native mode on irq 201
[4294929.054000] PCI: Setting latency timer of device 0000:00:1f.1 to 64
[4294929.054000]     ide0: BM-DMA at 0x30c0-0x30c7, BIOS settings: hda:DMA, hdb:pio
[4294929.054000]     ide1: BM-DMA at 0x30c8-0x30cf, BIOS settings: hdc:pio, hdd:pio
[4294929.054000] Probing IDE interface ide0...
[4294929.722000] hda: MATSHITADVD-R UJ-846, ATAPI CD/DVD-ROM drive
[4294930.057000] ide0 at 0x30e8-0x30ef,0x30fe on irq 201
[4294930.057000] Probing IDE interface ide1...

which seems ok. However, loading ide-cd gives:

[4294983.732000] hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
[4294983.732000] ide: failed opcode was: unknown
[4294983.732000] hda: drive not ready for command
[4294983.735000] hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
[4294983.735000] ide: failed opcode was: unknown
[4294983.735000] hda: drive not ready for command
[4294983.738000] hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
[4294983.738000] ide: failed opcode was: unknown
[4294983.738000] hda: drive not ready for command
[4294983.741000] hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
[4294983.741000] ide: failed opcode was: unknown
[4294983.741000] hda: DMA disabled
[4294983.741000] hda: drive not ready for command
[4294983.791000] hda: ATAPI reset complete
[4294983.793000] hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
[4294983.793000] ide: failed opcode was: unknown
[4294983.793000] hda: drive not ready for command
[4294983.796000] hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
[4294983.796000] ide: failed opcode was: unknown
[4294983.796000] hda: drive not ready for command
[4294983.799000] hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
[4294983.799000] ide: failed opcode was: unknown
[4294983.799000] hda: drive not ready for command
[4294983.802000] hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
[4294983.802000] ide: failed opcode was: unknown
[4294983.802000] hda: drive not ready for command
[4294983.852000] hda: ATAPI reset complete
[4294983.852000] hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
[4294983.852000] ide: failed opcode was: unknown
[4294983.852000] hda: drive not ready for command
[4294983.852000] hda: ATAPI CD-ROM drive, 0kB Cache
[4294983.853000] hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
[4294983.853000] ide: failed opcode was: unknown
[4294983.853000] hda: drive not ready for command

and insmod never returns. After this, the IDE interrupt is firing about 
80000 times a second. This is 2.6.15 - nothing jumps out at me in the 
changes since then. Anyone have any ideas? I'm not entirely convinced 
that interrupts are being set up correctly on this hardware, but it 
works fine with ata_piix...

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: PATA failure with piix, works with libata

[Alan Cox]

On Gwe, 2006-03-03 at 18:39 +0000, Matthew Garrett wrote:
> and everything is fine, including CD access. Loading piix gives me the 
> following:

> which seems ok. However, loading ide-cd gives:
> 
> [4294983.732000] hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }
> [4294983.732000] ide: failed opcode was: unknown
> [4294983.732000] hda: drive not ready for command

No suprise. Bits of ide/pci/piix.c only work because the BIOS setup did
some stuff we needed and in places with CD and DMA through luck alone.

> and insmod never returns. After this, the IDE interrupt is firing about 
> 80000 times a second. 

Make sure the IRQ is setup properly. Legacy mode IRQs are level
triggered which might fit this description.

Re: PATA failure with piix, works with libata

[Matthew Garrett]

Ok, it /seems/ that things are happier (though still not entirely happy) 
if I explicitly acknowledge the interrupt by writing the dma status 
register back again. This doesn't seem to be done anywhere in the IDE 
interrupt routine, but is in the libata one. I'm afraid I don't 
understand IDE well enough to have any idea what's going on here - is it 
possible that a piix in native mode (rather than legacy mode) and 
sharing an interrupt needs some special handling?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: PATA failure with piix, works with libata

[Jeff Garzik]

Matthew Garrett wrote:
> Ok, it /seems/ that things are happier (though still not entirely happy) 
> if I explicitly acknowledge the interrupt by writing the dma status 
> register back again. This doesn't seem to be done anywhere in the IDE 
> interrupt routine, but is in the libata one. I'm afraid I don't 
> understand IDE well enough to have any idea what's going on here - is it 
> possible that a piix in native mode (rather than legacy mode) and 
> sharing an interrupt needs some special handling?

ICH definitely needs that irq ack...

	Jeff

Re: PATA failure with piix, works with libata

[Matthew Garrett]

On Sun, Mar 05, 2006 at 06:40:58PM -0500, Jeff Garzik wrote:
> Matthew Garrett wrote:
> >Ok, it /seems/ that things are happier (though still not entirely happy) 
> >if I explicitly acknowledge the interrupt by writing the dma status 
> >register back again. This doesn't seem to be done anywhere in the IDE 
> >interrupt routine, but is in the libata one. I'm afraid I don't 
> >understand IDE well enough to have any idea what's going on here - is it 
> >possible that a piix in native mode (rather than legacy mode) and 
> >sharing an interrupt needs some special handling?
> 
> ICH definitely needs that irq ack...

Yeah, this is an ICH7. I can't find anything in drivers/ide that would 
result in it being done, which is why I'm kind of confused. ide_ack_intr 
seems to be defined to do nothing on x86 since IDE_ARCH_ACK_INTR isn't 
defined there?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: PATA failure with piix, works with libata

[Jeff Garzik]

Matthew Garrett wrote:
> On Sun, Mar 05, 2006 at 06:40:58PM -0500, Jeff Garzik wrote:
> 
>>Matthew Garrett wrote:
>>
>>>Ok, it /seems/ that things are happier (though still not entirely happy) 
>>>if I explicitly acknowledge the interrupt by writing the dma status 
>>>register back again. This doesn't seem to be done anywhere in the IDE 
>>>interrupt routine, but is in the libata one. I'm afraid I don't 
>>>understand IDE well enough to have any idea what's going on here - is it 
>>>possible that a piix in native mode (rather than legacy mode) and 
>>>sharing an interrupt needs some special handling?
>>
>>ICH definitely needs that irq ack...
> 
> 
> Yeah, this is an ICH7. I can't find anything in drivers/ide that would 
> result in it being done, which is why I'm kind of confused. ide_ack_intr 
> seems to be defined to do nothing on x86 since IDE_ARCH_ACK_INTR isn't 
> defined there?

This is more a piix-specific behavior than an arch-specific behavior.

	Jeff

Re: PATA failure with piix, works with libata

[Matthew Garrett]

On Sun, Mar 05, 2006 at 07:58:09PM -0500, Jeff Garzik wrote:
> Matthew Garrett wrote:
> >Yeah, this is an ICH7. I can't find anything in drivers/ide that would 
> >result in it being done, which is why I'm kind of confused. ide_ack_intr 
> >seems to be defined to do nothing on x86 since IDE_ARCH_ACK_INTR isn't 
> >defined there?
> 
> This is more a piix-specific behavior than an arch-specific behavior.

Joy. So it works by accident in legacy mode? Does anything need to be 
done other than just writing the DMA status register back? I'm not 
finding anything terribly helpful in the ICH7 docs, but I may just be 
being blind.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: PATA failure with piix, works with libata

[Jeff Garzik]

Matthew Garrett wrote:
> On Sun, Mar 05, 2006 at 07:58:09PM -0500, Jeff Garzik wrote:
> 
>>Matthew Garrett wrote:
>>
>>>Yeah, this is an ICH7. I can't find anything in drivers/ide that would 
>>>result in it being done, which is why I'm kind of confused. ide_ack_intr 
>>>seems to be defined to do nothing on x86 since IDE_ARCH_ACK_INTR isn't 
>>>defined there?
>>
>>This is more a piix-specific behavior than an arch-specific behavior.
> 
> 
> Joy. So it works by accident in legacy mode? Does anything need to be 
> done other than just writing the DMA status register back? I'm not 
> finding anything terribly helpful in the ICH7 docs, but I may just be 
> being blind.

Honestly I'm quite surprised that there is a difference between legacy 
and native mode (more joy :)).  ICH seems to want an ack to the bmdma 
status register even on non-DMA commands, since it directly reflects the 
IDE INTRQ line.  Perhaps pounding on the Status register will clear that 
condition, thus enabling legacy software to continue successfully 
without worry about this ICH-specific detail.  </speculation>

	Jeff

Re: PATA failure with piix, works with libata

[Matthew Garrett]

On Sun, Mar 05, 2006 at 08:07:05PM -0500, Jeff Garzik wrote:

> Honestly I'm quite surprised that there is a difference between legacy 
> and native mode (more joy :)).  ICH seems to want an ack to the bmdma 
> status register even on non-DMA commands, since it directly reflects the 
> IDE INTRQ line.  Perhaps pounding on the Status register will clear that 
> condition, thus enabling legacy software to continue successfully 
> without worry about this ICH-specific detail.  </speculation>

Yeah, that seems to work. Thanks! I'll see if I can clean this up...
-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: PATA failure with piix, works with libata

[Matthew Garrett]

On Sat, Mar 04, 2006 at 02:11:46PM +0000, Alan Cox wrote:

> Make sure the IRQ is setup properly. Legacy mode IRQs are level
> triggered which might fit this description.

It's a shared PCI interrupt, so yeah, it's level. As I mentioned to 
Jeff, explicitly writing back the DMA status register while 
acknowledging interrupts works (and is what ata_piix does in PATA mode)

-- 
Matthew Garrett | mjg59@srcf.ucam.org