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

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

<Prev in Thread] Current Thread [Next in Thread>