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

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

On Sun, Jan 25, 2009 at 01:49:20AM +0200, Pasi Kärkkäinen wrote:
> On Sat, Jan 24, 2009 at 10:17:02PM +0200, Pasi Kärkkäinen wrote:
> > On Sat, Jan 24, 2009 at 10:58:00AM -0800, Jeremy Fitzhardinge wrote:
> > > Pasi Kärkkäinen wrote:
> > > >On Sat, Jan 24, 2009 at 04:09:30PM +0200, Pasi Kärkkäinen wrote:
> > > >  
> > > >>On Thu, Jan 22, 2009 at 12:23:26PM -0800, Jeremy Fitzhardinge wrote:
> > > >>    
> > > >>>Pasi Kärkkäinen wrote:
> > > >>>      
> > > >>>>On Fri, Jan 09, 2009 at 09:01:59PM +0000, Andrew Lyon wrote:
> > > >>>> 
> > > >>>>        
> > > >>>>>>I just upgraded to newly released Xen 3.3.1 hypervisor but 
> > > >>>>>>unfortunately it
> > > >>>>>>didn't seem to help with my problem.. I still get the exact same 
> > > >>>>>>errors with
> > > >>>>>>ata_piix module:
> > > >>>>>>
> > > >>>>>>http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-4-xen331.txt
> > > >>>>>>
> > > >>>>>>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
> > > >>>>>>xen: disable pci device 0000:00:1f.1
> > > >>>>>>ata_piix: probe of 0000:00:1f.1 failed with error -38
> > > >>>>>>     
> > > >>>>>>            
> > > >>>>>I don't think the problem is ata_piix, I've tried the pv_ops dom0
> > > >>>>>kernel on a Dell Optiplex 755 and unbranded system with gigabyte
> > > >>>>>motherboard, on both systems none of the storage devices worked,
> > > >>>>>including ahci, ata_piix, I even tried putting the root filesystem on
> > > >>>>>a usb storage device but that too is broken, I think interrupt 
> > > >>>>>routing
> > > >>>>>is not working at all perhaps?
> > > >>>>>
> > > >>>>>I'm going to do more testing this weekend...
> > > >>>>>
> > > >>>>>   
> > > >>>>>          
> > > >>>>Hello.
> > > >>>>
> > > >>>>I just did some more testing too..
> > > >>>>
> > > >>>>I upgraded to the latest patches for Linux 2.6.29-rc1-tip
> > > >>>>
> > > >>>>log of xen+kernel from serial console:
> > > >>>>http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-5-xen331-linux-2.6.29-rc1.txt
> > > >>>>
> > > >>>>(XEN) Command line: dom0_mem=1024M loglvl=all guest_loglvl=all 
> > > >>>>com1=19200,8n1 console=com1
> > > >>>>Kernel command line: ro root=/dev/vg00/lv01 console=hvc0 
> > > >>>>earlyprintk=xen pci=nomsi
> > > >>>>
> > > >>>>And the failing part of the log is here:
> > > >>>>
> > > >>>>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
> > > >>>>xen: disable pci device 0000:00:1f.1
> > > >>>>Pid: 1, comm: swapper Not tainted 2.6.29-rc1-tip #3
> > > >>>> 
> > > >>>>        
> > > >>>That means that the ata-piix driver decided it was unhappy for some 
> > > >>>reason, and decided to fali with ENODEV.  It would be very interesting 
> > > >>>to know what part of the device probe failed.  From the Xen 
> > > >>>perspective, 
> > > >>>it looks like everything went OK.
> > > >>>
> > > >>>      
> > > >>I just did
> > > >>
> > > >>#define ATA_DEBUG
> > > >>#define ATA_VERBOSE_DEBUG
> > > >>#define ATA_IRQ_TRAP
> > > >>
> > > >>in include/linux/libata.h
> > > >>
> > > >>and recompiling now.. let's see if that helps.
> > > >>
> > > >>    
> > > >
> > > >Here we go:
> > > >http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-6-xen331-linux-2.6.29-rc1-atadebug.txt
> > > >
> > > >piix_init: pci_register_driver
> > > >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
> > > >ata_host_alloc: ENTER
> > > >ata_port_alloc: ENTER
> > > >ata_port_alloc: ENTER
> > > >__ata_port_freeze: ata4294967295 port frozen
> > > >__ata_port_freeze: ata4294967295 port frozen
> > > >  
> > > 
> > > I don't know whether being "frozen" is good, bad or indifferent, but 
> > > that's a might strange ata interface number.  I don't suppose you have 4 
> > > billion ata interfaces on your machine?
> > > 
> > 
> > Heh. Yeah, that's weird.. I wonder what's going on. 
> > 
> > I'll try to debug that.
> > 
> 
> Ok, it seems ports are supposed to be frozen during initialization in
> ata_host_start() function. Correct port names are only assigned after that. 
> So those "port frozen" messages with -1 as the name are OK at that point.
> 
> Port names ("print_id") are given in ata_host_register() function, which
> never gets called for ata_piix..
> 
> ata_host_register() is supposed to be called from
> ata_pci_sff_activate_host(), but in that function some error happens in 
> 
> rc = devm_request_irq(dev, ATA_PRIMARY_IRQ(pdev), irq_handler, IRQF_SHARED, 
> drv_name, host);
> if (rc)
>       goto out;
> 
> and ports names never get assigned because that "goto out;" is executed.
> 
> So.. Any ideas why devm_request_irq() fails? 
> 

Log with a lot of debugging information:
http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-7-xen331-linux-2.6.29-rc1-atadebug2.txt

I added prints everywhere..

If you search for "piix_init: pci_register_driver" in that log, that's where
ata_piix module loading starts.. and it ends at "piix_init: done".

OK.. so first this:

piix_init: pci_register_driver
piix_init_one: ENTER
piix_init_one: DEBUG1
piix_init_one: pcim_enable_device(pdev);
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

And then later:

ata_pci_sff_activate_host: legacy_mode
ata_pci_sff_activate_host: port 0 not dummy: devm_request_irq()
ata_pci_sff_activate_host: non-legacy-mode irq: 30
ata_pci_sff_activate_host: requesting ATA_PRIMARY_IRQ(pdev) irq: 14
ata_pci_sff_activate_host: devm_request_irq() returned != 0, goto out
ata_pci_sff_activate_host: out
ata_pci_sff_activate_host: devres_release_group()
ata_pci_sff_activate_host: end, returning
xen: disable pci device 0000:00:1f.1

Is that ATA_PRIMARY_IRQ() problematic somehow? the driver is requesting IRQ
14 instead of 30 allocated earlier.. 

I'm not very familiar with this stuff.. hopefully someone else has ideas
about this. 

-- Pasi

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