[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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? 

-- Pasi

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.