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

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

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