On Mon, Feb 02, 2009 at 10:16:32PM -0800, Boris Derzhavets wrote:
> 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 .
>
You need to set up serial console to capture the boot logs.
See http://wiki.xensource.com/xenwiki/XenParavirtOps for more information
about setting it up.
-- Pasi
> 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
|
Home