WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

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