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

[Boris Derzhavets <bderzhavets@xxxxxxxxx>]

Pasi,
 
  I saw similar output on the console during booting up.
Could you advise to what logfile this data has been sent
by system at boot time .

Boris.

--- On Tue, 2/3/09, Jeremy Fitzhardinge <jeremy@xxxxxxxx> wrote:

From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: Re: [Xen-devel] pv_ops dom0 kernel failure with ata_piix / irq problems
To: "Pasi Kärkkäinen" <pasik@xxxxxx>
Cc: "Todd Deshane" <deshantm@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, "Andrew Lyon" <andrew.lyon@xxxxxxxxx>, "Ian Campbell" <Ian.Campbell@xxxxxxxxxx>
Date: Tuesday, February 3, 2009, 12:32 AM

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

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