Re: [Xen-devel] pv_ops dom0 kernel failure with ata_piix / irq problems

[Pasi Kärkkäinen <pasik@xxxxxx>]

On Mon, Feb 02, 2009 at 09:32:57PM -0800, Jeremy Fitzhardinge wrote:
> 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...
> 

Ok.. good to hear it's not only me or my testbox:)

Let me know if you have some tips about debugging.. I can do some debugging
later today.

-- Pasi

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel