Re: pv_ops dom0 kernel failure with ata_piix / irq problems

[Jeremy Fitzhardinge <jeremy@goop.org>]

Pasi Kärkkäinen wrote:
> On Mon, Feb 02, 2009 at 10:42:30AM +0200, Pasi Kärkkäinen wrote:
>   
>> On Fri, Jan 30, 2009 at 10:50:51AM -0800, Jeremy Fitzhardinge wrote:
>>     
>>> Ian Campbell wrote:
>>>       
>>>> On Fri, 2009-01-30 at 18:12 +0000, Ian Campbell wrote:
>>>>  
>>>>         
>>>>> Possibly the correct fix might be to use xen_register_gsi() here
>>>>> instead of xen_allocate_pirq() and get rid of the special case for IRQ
>>>>> 14 and 15 in xen_pci_pirq_enable(). Maybe only 14 and 15 need this
>>>>> special treatment.
>>>>>    
>>>>>           
>>>> FWIW this also Works For Me.
>>>>  
>>>>         
>>> OK.  I'd noticed that the native code just sets up all the legacy 
>>> interrupts at once.  I guess we should follow the lead to avoid these 
>>> kinds of init order problems.
>>>
>>>       
>> OK.
>>
>> I've been busy, and haven't yet had time to try the patch.
>>
>> Hopefully I can try it later today!
>>
>>     
>
> And now I tried the latest bits. 
>
> I also applied Ian's legacy irq fix/patch. 
>
> bootlog:
> http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-8-xen331-linux-2.6.29-rc3.txt
>
> Now my (IDE) disk is detected, but it ata_piix still seems to fail..
>
> I guess I'll compile new kernel again with libata debug enabled.. 
>
> Important parts of the dom0 kernel bootlog below.
>
> -- Pasi
>
> xen_allocate_pirq: returning irq 30 for gsi 18
> xen_set_ioapic_routing: irq 30 gsi 18 vector 160 ioapic 0 pin 18 triggering
> 0 polarity 1
> ata_piix 0000:00:1f.1: PCI INT A -> GSI 18 (level, low) -> IRQ 30
> xen: PCI device 0000:00:1f.1 pin 1 -> irq 30
> scsi4 : ata_piix
> scsi5 : ata_piix
> ata5: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xf000 irq 14
> ata6: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xf008 irq 15
> ata5.00: qc timeout (cmd 0x27)
> ata5.00: failed to read native max address (err_mask=0x4)
> ata5.00: HPA support seems broken, skipping HPA handling
> ata5.00: configured for UDMA/100
> scsi 4:0:0:0: Direct-Access     ATA      ST3120022A       3.06 PQ: 0 ANSI: 5
> sd 4:0:0:0: [sda] 234441648 512-byte hardware sectors: (120 GB/111 GiB)
> sd 4:0:0:0: [sda] Write Protect is off
> sd 4:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support
> DPO or FUA
> sd 4:0:0:0: [sda] 234441648 512-byte hardware sectors: (120 GB/111 GiB)
> sd 4:0:0:0: [sda] Write Protect is off
> sd 4:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support
> DPO or FUA
>  sda:<3>ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
> ata5.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in
>          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> ata5.00: status: { DRDY }
> ata5: soft resetting link
>   

Interesting.  That's similar to what I see with AHCI.  I don't know if 
there's any deeper connection...

    J