pv_ops dom0 kernel crashes

pv_ops dom0 kernel crashes

[Pasi Kärkkäinen]

Hello.

I got serial console working (still haven't figured out how to get VGA
console to work), so now I managed to capture the pv_ops dom0 kernel
crashes.

http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-1.txt
http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-2.txt

Two logs.. they seem to be a bit different from each other.

Other one ends with "xen: disable pci device 0000:00:1f.1" and the other one
has "Disabling IRQ #12" in addition to that.. 

After the crash hitting ctrl-alt-del seems to reboot the box, so it's not
totally dead.

Hardware is some years old Supermicro P8SCI motherboard with Intel P4 3,2 GHz CPU 
and 2 GB of RAM. I have only one IDE HDD attached to onboard ICH6 IDE controller,
although the motherboard also has ICH6 SATA (AHCI) controller, and also some
additional Promise IDE/SATA controllers, which are currently not used at all.

Xen hypervisor (3.3.0-2 from Fedora rawhide) is 32 bit PAE. Dom0 kernel is
32 bit PAE aswell. Same kernel works just fine on baremetal without Xen.

Is there something I should try to solve the problem? Need more information? 

logs when the same kernel is booted on baremetal (without Xen):

http://pasik.reaktio.net/xen/pv_ops-dom0-debug/baremetal-dmesg.txt
http://pasik.reaktio.net/xen/pv_ops-dom0-debug/baremetal-lspci.txt
http://pasik.reaktio.net/xen/pv_ops-dom0-debug/baremetal-lspci-vv.txt

-- Pasi

Re: pv_ops dom0 kernel crashes

[Pasi Kärkkäinen]

On Tue, Dec 30, 2008 at 04:34:40PM +0200, Pasi Kärkkäinen wrote:
> Hello.
> 
> I got serial console working (still haven't figured out how to get VGA
> console to work), so now I managed to capture the pv_ops dom0 kernel
> crashes.
> 
> http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-1.txt
> http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-2.txt
> 
> Two logs.. they seem to be a bit different from each other.
> 
> Other one ends with "xen: disable pci device 0000:00:1f.1" and the other one
> has "Disabling IRQ #12" in addition to that.. 
> 

So it seems the problem is IDE/PATA disk/controller is not detected at all with 
the pv_ops dom0 kernel:

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

-- Pasi

Re: pv_ops dom0 kernel crashes

[Todd Deshane]

On Tue, Dec 30, 2008 at 9:44 AM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> On Tue, Dec 30, 2008 at 04:34:40PM +0200, Pasi Kärkkäinen wrote:
>> Hello.
>>
>> I got serial console working (still haven't figured out how to get VGA
>> console to work), so now I managed to capture the pv_ops dom0 kernel
>> crashes.
>>
>> http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-1.txt
>> http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-2.txt
>>
>> Two logs.. they seem to be a bit different from each other.
>>
>> Other one ends with "xen: disable pci device 0000:00:1f.1" and the other one
>> has "Disabling IRQ #12" in addition to that..
>>
>
> So it seems the problem is IDE/PATA disk/controller is not detected at all with
> the pv_ops dom0 kernel:
>
> 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
>
> -- Pasi

Try changing the SATA mode of the disk in the BIOS to either legacy or
ATA, depending
on what you bios supports.

There is still a known issue with some of the AHCI stuff.

We have also been successful in using a USB key as the hard drive and booting
from that.

Cheers,
Todd

-- 
Todd Deshane
http://todddeshane.net
http://runningxen.com

Re: pv_ops dom0 kernel crashes

[Pasi Kärkkäinen]

On Tue, Dec 30, 2008 at 11:03:28AM -0500, Todd Deshane wrote:
> On Tue, Dec 30, 2008 at 9:44 AM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> > On Tue, Dec 30, 2008 at 04:34:40PM +0200, Pasi Kärkkäinen wrote:
> >> Hello.
> >>
> >> I got serial console working (still haven't figured out how to get VGA
> >> console to work), so now I managed to capture the pv_ops dom0 kernel
> >> crashes.
> >>
> >> http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-1.txt
> >> http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-2.txt
> >>
> >> Two logs.. they seem to be a bit different from each other.
> >>
> >> Other one ends with "xen: disable pci device 0000:00:1f.1" and the other one
> >> has "Disabling IRQ #12" in addition to that..
> >>
> >
> > So it seems the problem is IDE/PATA disk/controller is not detected at all with
> > the pv_ops dom0 kernel:
> >
> > 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
> >
> > -- Pasi
> 
> Try changing the SATA mode of the disk in the BIOS to either legacy or
> ATA, depending
> on what you bios supports.
> 
> There is still a known issue with some of the AHCI stuff.
>

I'm not using AHCI at all.. AHCI (SATA) controller does not have any disks
plugged in.

My (only) disk is attached to IDE/PATA ICH6 controller.. 
 
> We have also been successful in using a USB key as the hard drive and booting
> from that.
> 

OK..

-- Pasi

Re: pv_ops dom0 kernel crashes

[Pasi Kärkkäinen]

On Tue, Dec 30, 2008 at 06:19:39PM +0200, Pasi Kärkkäinen wrote:
> On Tue, Dec 30, 2008 at 11:03:28AM -0500, Todd Deshane wrote:
> > On Tue, Dec 30, 2008 at 9:44 AM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> > > On Tue, Dec 30, 2008 at 04:34:40PM +0200, Pasi Kärkkäinen wrote:
> > >> Hello.
> > >>
> > >> I got serial console working (still haven't figured out how to get VGA
> > >> console to work), so now I managed to capture the pv_ops dom0 kernel
> > >> crashes.
> > >>
> > >> http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-1.txt
> > >> http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-2.txt
> > >>
> > >> Two logs.. they seem to be a bit different from each other.
> > >>
> > >> Other one ends with "xen: disable pci device 0000:00:1f.1" and the other one
> > >> has "Disabling IRQ #12" in addition to that..
> > >>
> > >
> > > So it seems the problem is IDE/PATA disk/controller is not detected at all with
> > > the pv_ops dom0 kernel:
> > >
> > > 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
> > >
> > > -- Pasi
> > 
> > Try changing the SATA mode of the disk in the BIOS to either legacy or
> > ATA, depending
> > on what you bios supports.
> > 
> > There is still a known issue with some of the AHCI stuff.
> >
> 
> I'm not using AHCI at all.. AHCI (SATA) controller does not have any disks
> plugged in.
> 
> My (only) disk is attached to IDE/PATA ICH6 controller.. 
>  

I tried disabling AHCI anyway (even when I'm not using the AHCI SATA
controller), but it didn't help. 

Booting the pv_ops dom0 kernel still fails.. because the IDE/PATA controller
still gets disabled (just like in the logs above) for some unknown reason.

-- Pasi

Re: pv_ops dom0 kernel crashes

[Todd Deshane]

On Tue, Dec 30, 2008 at 11:28 AM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> > > Try changing the SATA mode of the disk in the BIOS to either legacy or
> > > ATA, depending
> > > on what you bios supports.
> > >
> > > There is still a known issue with some of the AHCI stuff.
> > >
> >
> > I'm not using AHCI at all.. AHCI (SATA) controller does not have any disks
> > plugged in.
> >
> > My (only) disk is attached to IDE/PATA ICH6 controller..
> >
>
> I tried disabling AHCI anyway (even when I'm not using the AHCI SATA
> controller), but it didn't help.
>
> Booting the pv_ops dom0 kernel still fails.. because the IDE/PATA controller
> still gets disabled (just like in the logs above) for some unknown reason.
>
> -- Pasi

So from the log it looks like you are getting a hard crash?

Did you try adding noreboot to the xen command line and then trying
to get any more information with sysreq stuff?

Another thing that I noticed in the log is:

irq 12: nobody cared (try booting with the "irqpoll" option)

Is it an smp kernel? I had some weird problems when passing nosmp at
one point.

I don't recognize this crash, those module traces, at least for me were
non-fatal and didn't cause a crash. I was normally just dropped to a
initramfs prompt in the case when the disk was not detected properly.

I was then able to at least look around and check that modules were
loaded correctly etc.

--
Todd Deshane
http://todddeshane.net
http://runningxen.com

Re: pv_ops dom0 kernel crashes

[Pasi Kärkkäinen]

On Tue, Dec 30, 2008 at 11:47:40AM -0500, Todd Deshane wrote:
> On Tue, Dec 30, 2008 at 11:28 AM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> > > > Try changing the SATA mode of the disk in the BIOS to either legacy or
> > > > ATA, depending
> > > > on what you bios supports.
> > > >
> > > > There is still a known issue with some of the AHCI stuff.
> > > >
> > >
> > > I'm not using AHCI at all.. AHCI (SATA) controller does not have any disks
> > > plugged in.
> > >
> > > My (only) disk is attached to IDE/PATA ICH6 controller..
> > >
> >
> > I tried disabling AHCI anyway (even when I'm not using the AHCI SATA
> > controller), but it didn't help.
> >
> > Booting the pv_ops dom0 kernel still fails.. because the IDE/PATA controller
> > still gets disabled (just like in the logs above) for some unknown reason.
> >
> > -- Pasi
> 
> So from the log it looks like you are getting a hard crash?
> 

No, it's not a hard crash.. I'm able to reboot the box with ctrl-alt-del. 

> Did you try adding noreboot to the xen command line and then trying
> to get any more information with sysreq stuff?
> 
> Another thing that I noticed in the log is:
> 
> irq 12: nobody cared (try booting with the "irqpoll" option)
> 
> Is it an smp kernel? I had some weird problems when passing nosmp at
> one point.
>

Yep, it is SMP kernel.. 
 
> I don't recognize this crash, those module traces, at least for me were
> non-fatal and didn't cause a crash. I was normally just dropped to a
> initramfs prompt in the case when the disk was not detected properly.
> 
> I was then able to at least look around and check that modules were
> loaded correctly etc.
> 

The problem seems to be the IDE controller/disk is not detected at all..
because the device gets disabled for some reason during ata_piix
loading/probing.. 

That is the only disk I have, so the root partition is on it.

Same kernel works just fine on baremetal without Xen.

-- Pasi

Re: pv_ops dom0 kernel failure with ata_piix

[Pasi Kärkkäinen]

On Tue, Dec 30, 2008 at 06:52:11PM +0200, Pasi Kärkkäinen wrote:
> On Tue, Dec 30, 2008 at 11:47:40AM -0500, Todd Deshane wrote:
> > On Tue, Dec 30, 2008 at 11:28 AM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> > > > > Try changing the SATA mode of the disk in the BIOS to either legacy or
> > > > > ATA, depending
> > > > > on what you bios supports.
> > > > >
> > > > > There is still a known issue with some of the AHCI stuff.
> > > > >
> > > >
> > > > I'm not using AHCI at all.. AHCI (SATA) controller does not have any disks
> > > > plugged in.
> > > >
> > > > My (only) disk is attached to IDE/PATA ICH6 controller..
> > > >
> > >
> > > I tried disabling AHCI anyway (even when I'm not using the AHCI SATA
> > > controller), but it didn't help.
> > >
> > > Booting the pv_ops dom0 kernel still fails.. because the IDE/PATA controller
> > > still gets disabled (just like in the logs above) for some unknown reason.
> > >
> > > -- Pasi
> > 
> > So from the log it looks like you are getting a hard crash?
> > 
> 
> No, it's not a hard crash.. I'm able to reboot the box with ctrl-alt-del. 
> 
> > Did you try adding noreboot to the xen command line and then trying
> > to get any more information with sysreq stuff?
> > 
> > Another thing that I noticed in the log is:
> > 
> > irq 12: nobody cared (try booting with the "irqpoll" option)
> > 
> > Is it an smp kernel? I had some weird problems when passing nosmp at
> > one point.
> >
> 
> Yep, it is SMP kernel.. 
>  
> > I don't recognize this crash, those module traces, at least for me were
> > non-fatal and didn't cause a crash. I was normally just dropped to a
> > initramfs prompt in the case when the disk was not detected properly.
> > 
> > I was then able to at least look around and check that modules were
> > loaded correctly etc.
> > 
> 
> The problem seems to be the IDE controller/disk is not detected at all..
> because the device gets disabled for some reason during ata_piix
> loading/probing.. 
> 
> That is the only disk I have, so the root partition is on it.
> 
> Same kernel works just fine on baremetal without Xen.
> 

So I guess the subject should be 'failure with ata_piix' instead of 'crash'.. 

Anyway, there seems to be problems with ata_piix too.. in addition to AHCI.

Jeremy: Can you think of anything to try? 

-- Pasi

Re: pv_ops dom0 kernel failure with ata_piix

[Pasi Kärkkäinen]

On Tue, Dec 30, 2008 at 08:18:45PM +0200, Pasi Kärkkäinen wrote:
> On Tue, Dec 30, 2008 at 06:52:11PM +0200, Pasi Kärkkäinen wrote:
> > On Tue, Dec 30, 2008 at 11:47:40AM -0500, Todd Deshane wrote:
> > > On Tue, Dec 30, 2008 at 11:28 AM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> > > > > > Try changing the SATA mode of the disk in the BIOS to either legacy or
> > > > > > ATA, depending
> > > > > > on what you bios supports.
> > > > > >
> > > > > > There is still a known issue with some of the AHCI stuff.
> > > > > >
> > > > >
> > > > > I'm not using AHCI at all.. AHCI (SATA) controller does not have any disks
> > > > > plugged in.
> > > > >
> > > > > My (only) disk is attached to IDE/PATA ICH6 controller..
> > > > >
> > > >
> > > > I tried disabling AHCI anyway (even when I'm not using the AHCI SATA
> > > > controller), but it didn't help.
> > > >
> > > > Booting the pv_ops dom0 kernel still fails.. because the IDE/PATA controller
> > > > still gets disabled (just like in the logs above) for some unknown reason.
> > > >
> > > > -- Pasi
> > > 
> > > So from the log it looks like you are getting a hard crash?
> > > 
> > 
> > No, it's not a hard crash.. I'm able to reboot the box with ctrl-alt-del. 
> > 
> > > Did you try adding noreboot to the xen command line and then trying
> > > to get any more information with sysreq stuff?
> > > 
> > > Another thing that I noticed in the log is:
> > > 
> > > irq 12: nobody cared (try booting with the "irqpoll" option)
> > > 
> > > Is it an smp kernel? I had some weird problems when passing nosmp at
> > > one point.
> > >
> > 
> > Yep, it is SMP kernel.. 
> >  
> > > I don't recognize this crash, those module traces, at least for me were
> > > non-fatal and didn't cause a crash. I was normally just dropped to a
> > > initramfs prompt in the case when the disk was not detected properly.
> > > 
> > > I was then able to at least look around and check that modules were
> > > loaded correctly etc.
> > > 
> > 
> > The problem seems to be the IDE controller/disk is not detected at all..
> > because the device gets disabled for some reason during ata_piix
> > loading/probing.. 
> > 
> > That is the only disk I have, so the root partition is on it.
> > 
> > Same kernel works just fine on baremetal without Xen.
> > 
> 
> So I guess the subject should be 'failure with ata_piix' instead of 'crash'.. 
> 
> Anyway, there seems to be problems with ata_piix too.. in addition to AHCI.
> 
> Jeremy: Can you think of anything to try? 
> 

I tried booting with "nosmp" dom0 kernel parameter:

and now the failing part is like this:

xen_allocate_pirq: returning irq 5 for gsi 5
ERROR: Unable to locate IOAPIC for GSI 5
xen_set_ioapic_routing: irq 5 gsi 5 ioapic -1
ata_piix 0000:00:1f.1: PCI INT A -> Link[LNKC] -> GSI 5 (level, low) -> IRQ 5
xen: PCI device 0000:00:1f.1 pin 1 -> irq 5
xen: disable pci device 0000:00:1f.1

Whole log with "nosmp":
http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-3-nosmp.txt

Earlier logs I posted are SMP enabled.

-- Pasi

Re: pv_ops dom0 kernel failure with ata_piix

[Jeremy Fitzhardinge]

Pasi Kärkkäinen wrote:
> On Tue, Dec 30, 2008 at 08:18:45PM +0200, Pasi Kärkkäinen wrote:
>   
>> On Tue, Dec 30, 2008 at 06:52:11PM +0200, Pasi Kärkkäinen wrote:
>>     
>>> On Tue, Dec 30, 2008 at 11:47:40AM -0500, Todd Deshane wrote:
>>>       
>>>> On Tue, Dec 30, 2008 at 11:28 AM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
>>>>         
>>>>>>> Try changing the SATA mode of the disk in the BIOS to either legacy or
>>>>>>> ATA, depending
>>>>>>> on what you bios supports.
>>>>>>>
>>>>>>> There is still a known issue with some of the AHCI stuff.
>>>>>>>
>>>>>>>               
>>>>>> I'm not using AHCI at all.. AHCI (SATA) controller does not have any disks
>>>>>> plugged in.
>>>>>>
>>>>>> My (only) disk is attached to IDE/PATA ICH6 controller..
>>>>>>
>>>>>>             
>>>>> I tried disabling AHCI anyway (even when I'm not using the AHCI SATA
>>>>> controller), but it didn't help.
>>>>>
>>>>> Booting the pv_ops dom0 kernel still fails.. because the IDE/PATA controller
>>>>> still gets disabled (just like in the logs above) for some unknown reason.
>>>>>
>>>>> -- Pasi
>>>>>           
>>>> So from the log it looks like you are getting a hard crash?
>>>>
>>>>         
>>> No, it's not a hard crash.. I'm able to reboot the box with ctrl-alt-del. 
>>>
>>>       
>>>> Did you try adding noreboot to the xen command line and then trying
>>>> to get any more information with sysreq stuff?
>>>>
>>>> Another thing that I noticed in the log is:
>>>>
>>>> irq 12: nobody cared (try booting with the "irqpoll" option)
>>>>
>>>> Is it an smp kernel? I had some weird problems when passing nosmp at
>>>> one point.
>>>>
>>>>         
>>> Yep, it is SMP kernel.. 
>>>  
>>>       
>>>> I don't recognize this crash, those module traces, at least for me were
>>>> non-fatal and didn't cause a crash. I was normally just dropped to a
>>>> initramfs prompt in the case when the disk was not detected properly.
>>>>
>>>> I was then able to at least look around and check that modules were
>>>> loaded correctly etc.
>>>>
>>>>         
>>> The problem seems to be the IDE controller/disk is not detected at all..
>>> because the device gets disabled for some reason during ata_piix
>>> loading/probing.. 
>>>
>>> That is the only disk I have, so the root partition is on it.
>>>
>>> Same kernel works just fine on baremetal without Xen.
>>>
>>>       
>> So I guess the subject should be 'failure with ata_piix' instead of 'crash'.. 
>>
>> Anyway, there seems to be problems with ata_piix too.. in addition to AHCI.
>>
>> Jeremy: Can you think of anything to try? 
>>
>>     
>
> I tried booting with "nosmp" dom0 kernel parameter:
>   

Yes, nosmp is known to make things worse.  It has the side-effect of 
disabling io_apic support, so all the interrupt stuff fails in the way 
you've noticed.

    J

Re: pv_ops dom0 kernel failure with ata_piix

[Pasi Kärkkäinen]

On Thu, Jan 01, 2009 at 08:36:33AM +1100, Jeremy Fitzhardinge wrote:
> Pasi Kärkkäinen wrote:
> >On Tue, Dec 30, 2008 at 08:18:45PM +0200, Pasi Kärkkäinen wrote:
> >  
> >>On Tue, Dec 30, 2008 at 06:52:11PM +0200, Pasi Kärkkäinen wrote:
> >>    
> >>>On Tue, Dec 30, 2008 at 11:47:40AM -0500, Todd Deshane wrote:
> >>>      
> >>>>On Tue, Dec 30, 2008 at 11:28 AM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> >>>>        
> >>>>>>>Try changing the SATA mode of the disk in the BIOS to either legacy 
> >>>>>>>or
> >>>>>>>ATA, depending
> >>>>>>>on what you bios supports.
> >>>>>>>
> >>>>>>>There is still a known issue with some of the AHCI stuff.
> >>>>>>>
> >>>>>>>              
> >>>>>>I'm not using AHCI at all.. AHCI (SATA) controller does not have any 
> >>>>>>disks
> >>>>>>plugged in.
> >>>>>>
> >>>>>>My (only) disk is attached to IDE/PATA ICH6 controller..
> >>>>>>
> >>>>>>            
> >>>>>I tried disabling AHCI anyway (even when I'm not using the AHCI SATA
> >>>>>controller), but it didn't help.
> >>>>>
> >>>>>Booting the pv_ops dom0 kernel still fails.. because the IDE/PATA 
> >>>>>controller
> >>>>>still gets disabled (just like in the logs above) for some unknown 
> >>>>>reason.
> >>>>>
> >>>>>-- Pasi
> >>>>>          
> >>>>So from the log it looks like you are getting a hard crash?
> >>>>
> >>>>        
> >>>No, it's not a hard crash.. I'm able to reboot the box with 
> >>>ctrl-alt-del. 
> >>>      
> >>>>Did you try adding noreboot to the xen command line and then trying
> >>>>to get any more information with sysreq stuff?
> >>>>
> >>>>Another thing that I noticed in the log is:
> >>>>
> >>>>irq 12: nobody cared (try booting with the "irqpoll" option)
> >>>>
> >>>>Is it an smp kernel? I had some weird problems when passing nosmp at
> >>>>one point.
> >>>>
> >>>>        
> >>>Yep, it is SMP kernel.. 
> >>> 
> >>>      
> >>>>I don't recognize this crash, those module traces, at least for me were
> >>>>non-fatal and didn't cause a crash. I was normally just dropped to a
> >>>>initramfs prompt in the case when the disk was not detected properly.
> >>>>
> >>>>I was then able to at least look around and check that modules were
> >>>>loaded correctly etc.
> >>>>
> >>>>        
> >>>The problem seems to be the IDE controller/disk is not detected at all..
> >>>because the device gets disabled for some reason during ata_piix
> >>>loading/probing.. 
> >>>
> >>>That is the only disk I have, so the root partition is on it.
> >>>
> >>>Same kernel works just fine on baremetal without Xen.
> >>>
> >>>      
> >>So I guess the subject should be 'failure with ata_piix' instead of 
> >>'crash'.. 
> >>Anyway, there seems to be problems with ata_piix too.. in addition to 
> >>AHCI.
> >>
> >>Jeremy: Can you think of anything to try? 
> >>
> >>    
> >
> >I tried booting with "nosmp" dom0 kernel parameter:
> >  
> 
> Yes, nosmp is known to make things worse.  It has the side-effect of 
> disabling io_apic support, so all the interrupt stuff fails in the way 
> you've noticed.
> 

Yep. "nosmp" was just something I tried to see if it makes any difference.
It didn't help.

Anyway, have you seen/heard of this problem with ata_piix earlier? 

http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-1.txt
http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-2.txt

Same kernel on baremetal without Xen:
http://pasik.reaktio.net/xen/pv_ops-dom0-debug/baremetal-dmesg.txt

-- Pasi

Re: pv_ops dom0 kernel failure with ata_piix

[Pasi Kärkkäinen]

On Fri, Jan 02, 2009 at 08:44:44AM +0200, Pasi Kärkkäinen wrote:
> On Thu, Jan 01, 2009 at 08:36:33AM +1100, Jeremy Fitzhardinge wrote:
> > Pasi Kärkkäinen wrote:
> > >On Tue, Dec 30, 2008 at 08:18:45PM +0200, Pasi Kärkkäinen wrote:
> > >  
> > >>On Tue, Dec 30, 2008 at 06:52:11PM +0200, Pasi Kärkkäinen wrote:
> > >>    
> > >>>On Tue, Dec 30, 2008 at 11:47:40AM -0500, Todd Deshane wrote:
> > >>>      
> > >>>>On Tue, Dec 30, 2008 at 11:28 AM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> > >>>>        
> > >>>>>>>Try changing the SATA mode of the disk in the BIOS to either legacy 
> > >>>>>>>or
> > >>>>>>>ATA, depending
> > >>>>>>>on what you bios supports.
> > >>>>>>>
> > >>>>>>>There is still a known issue with some of the AHCI stuff.
> > >>>>>>>
> > >>>>>>>              
> > >>>>>>I'm not using AHCI at all.. AHCI (SATA) controller does not have any 
> > >>>>>>disks
> > >>>>>>plugged in.
> > >>>>>>
> > >>>>>>My (only) disk is attached to IDE/PATA ICH6 controller..
> > >>>>>>
> > >>>>>>            
> > >>>>>I tried disabling AHCI anyway (even when I'm not using the AHCI SATA
> > >>>>>controller), but it didn't help.
> > >>>>>
> > >>>>>Booting the pv_ops dom0 kernel still fails.. because the IDE/PATA 
> > >>>>>controller
> > >>>>>still gets disabled (just like in the logs above) for some unknown 
> > >>>>>reason.
> > >>>>>
> > >>>>>-- Pasi
> > >>>>>          
> > >>>>So from the log it looks like you are getting a hard crash?
> > >>>>
> > >>>>        
> > >>>No, it's not a hard crash.. I'm able to reboot the box with 
> > >>>ctrl-alt-del. 
> > >>>      
> > >>>>Did you try adding noreboot to the xen command line and then trying
> > >>>>to get any more information with sysreq stuff?
> > >>>>
> > >>>>Another thing that I noticed in the log is:
> > >>>>
> > >>>>irq 12: nobody cared (try booting with the "irqpoll" option)
> > >>>>
> > >>>>Is it an smp kernel? I had some weird problems when passing nosmp at
> > >>>>one point.
> > >>>>
> > >>>>        
> > >>>Yep, it is SMP kernel.. 
> > >>> 
> > >>>      
> > >>>>I don't recognize this crash, those module traces, at least for me were
> > >>>>non-fatal and didn't cause a crash. I was normally just dropped to a
> > >>>>initramfs prompt in the case when the disk was not detected properly.
> > >>>>
> > >>>>I was then able to at least look around and check that modules were
> > >>>>loaded correctly etc.
> > >>>>
> > >>>>        
> > >>>The problem seems to be the IDE controller/disk is not detected at all..
> > >>>because the device gets disabled for some reason during ata_piix
> > >>>loading/probing.. 
> > >>>
> > >>>That is the only disk I have, so the root partition is on it.
> > >>>
> > >>>Same kernel works just fine on baremetal without Xen.
> > >>>
> > >>>      
> > >>So I guess the subject should be 'failure with ata_piix' instead of 
> > >>'crash'.. 
> > >>Anyway, there seems to be problems with ata_piix too.. in addition to 
> > >>AHCI.
> > >>
> > >>Jeremy: Can you think of anything to try? 
> > >>
> > >>    
> > >
> > >I tried booting with "nosmp" dom0 kernel parameter:
> > >  
> > 
> > Yes, nosmp is known to make things worse.  It has the side-effect of 
> > disabling io_apic support, so all the interrupt stuff fails in the way 
> > you've noticed.
> > 
> 
> Yep. "nosmp" was just something I tried to see if it makes any difference.
> It didn't help.
> 
> Anyway, have you seen/heard of this problem with ata_piix earlier? 
> 
> http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-1.txt
> http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-2.txt
> 
> Same kernel on baremetal without Xen:
> http://pasik.reaktio.net/xen/pv_ops-dom0-debug/baremetal-dmesg.txt
> 

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

-- Pasi

Re: pv_ops dom0 kernel failure with ata_piix

[Andrew Lyon]

On Fri, Jan 9, 2009 at 5:40 PM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
> On Fri, Jan 02, 2009 at 08:44:44AM +0200, Pasi Kärkkäinen wrote:
>> On Thu, Jan 01, 2009 at 08:36:33AM +1100, Jeremy Fitzhardinge wrote:
>> > Pasi Kärkkäinen wrote:
>> > >On Tue, Dec 30, 2008 at 08:18:45PM +0200, Pasi Kärkkäinen wrote:
>> > >
>> > >>On Tue, Dec 30, 2008 at 06:52:11PM +0200, Pasi Kärkkäinen wrote:
>> > >>
>> > >>>On Tue, Dec 30, 2008 at 11:47:40AM -0500, Todd Deshane wrote:
>> > >>>
>> > >>>>On Tue, Dec 30, 2008 at 11:28 AM, Pasi Kärkkäinen <pasik@iki.fi> wrote:
>> > >>>>
>> > >>>>>>>Try changing the SATA mode of the disk in the BIOS to either legacy
>> > >>>>>>>or
>> > >>>>>>>ATA, depending
>> > >>>>>>>on what you bios supports.
>> > >>>>>>>
>> > >>>>>>>There is still a known issue with some of the AHCI stuff.
>> > >>>>>>>
>> > >>>>>>>
>> > >>>>>>I'm not using AHCI at all.. AHCI (SATA) controller does not have any
>> > >>>>>>disks
>> > >>>>>>plugged in.
>> > >>>>>>
>> > >>>>>>My (only) disk is attached to IDE/PATA ICH6 controller..
>> > >>>>>>
>> > >>>>>>
>> > >>>>>I tried disabling AHCI anyway (even when I'm not using the AHCI SATA
>> > >>>>>controller), but it didn't help.
>> > >>>>>
>> > >>>>>Booting the pv_ops dom0 kernel still fails.. because the IDE/PATA
>> > >>>>>controller
>> > >>>>>still gets disabled (just like in the logs above) for some unknown
>> > >>>>>reason.
>> > >>>>>
>> > >>>>>-- Pasi
>> > >>>>>
>> > >>>>So from the log it looks like you are getting a hard crash?
>> > >>>>
>> > >>>>
>> > >>>No, it's not a hard crash.. I'm able to reboot the box with
>> > >>>ctrl-alt-del.
>> > >>>
>> > >>>>Did you try adding noreboot to the xen command line and then trying
>> > >>>>to get any more information with sysreq stuff?
>> > >>>>
>> > >>>>Another thing that I noticed in the log is:
>> > >>>>
>> > >>>>irq 12: nobody cared (try booting with the "irqpoll" option)
>> > >>>>
>> > >>>>Is it an smp kernel? I had some weird problems when passing nosmp at
>> > >>>>one point.
>> > >>>>
>> > >>>>
>> > >>>Yep, it is SMP kernel..
>> > >>>
>> > >>>
>> > >>>>I don't recognize this crash, those module traces, at least for me were
>> > >>>>non-fatal and didn't cause a crash. I was normally just dropped to a
>> > >>>>initramfs prompt in the case when the disk was not detected properly.
>> > >>>>
>> > >>>>I was then able to at least look around and check that modules were
>> > >>>>loaded correctly etc.
>> > >>>>
>> > >>>>
>> > >>>The problem seems to be the IDE controller/disk is not detected at all..
>> > >>>because the device gets disabled for some reason during ata_piix
>> > >>>loading/probing..
>> > >>>
>> > >>>That is the only disk I have, so the root partition is on it.
>> > >>>
>> > >>>Same kernel works just fine on baremetal without Xen.
>> > >>>
>> > >>>
>> > >>So I guess the subject should be 'failure with ata_piix' instead of
>> > >>'crash'..
>> > >>Anyway, there seems to be problems with ata_piix too.. in addition to
>> > >>AHCI.
>> > >>
>> > >>Jeremy: Can you think of anything to try?
>> > >>
>> > >>
>> > >
>> > >I tried booting with "nosmp" dom0 kernel parameter:
>> > >
>> >
>> > Yes, nosmp is known to make things worse.  It has the side-effect of
>> > disabling io_apic support, so all the interrupt stuff fails in the way
>> > you've noticed.
>> >
>>
>> Yep. "nosmp" was just something I tried to see if it makes any difference.
>> It didn't help.
>>
>> Anyway, have you seen/heard of this problem with ata_piix earlier?
>>
>> http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-1.txt
>> http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-2.txt
>>
>> Same kernel on baremetal without Xen:
>> http://pasik.reaktio.net/xen/pv_ops-dom0-debug/baremetal-dmesg.txt
>>
>
> 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...

Andy

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

Re: pv_ops dom0 kernel failure with ata_piix / irq problems

[Pasi Kärkkäinen]

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
Call Trace:
 [<c06dd32e>] ? printk+0xf/0x11
 [<c04079bc>] xen_pci_pirq_disable+0x18/0x1c
 [<c0656930>] pcibios_disable_device+0x18/0x1a
 [<c0543303>] do_pci_disable_device+0x4b/0x50
 [<c054345d>] pci_disable_device+0x3f/0x4b
 [<c05437c1>] pcim_release+0x6f/0x74
 [<c05c18ce>] release_nodes+0x14a/0x165
 [<c05c19a4>] devres_release_all+0x25/0x2a
 [<c05bfeb4>] driver_probe_device+0xb7/0x12f
 [<c05bff78>] __driver_attach+0x4c/0x6b
 [<c05bf8da>] bus_for_each_dev+0x3b/0x63
 [<c05bfd42>] driver_attach+0x14/0x16
 [<c05bff2c>] ? __driver_attach+0x0/0x6b
 [<c05bf34d>] bus_add_driver+0x9d/0x1ba
 [<c05c00ff>] driver_register+0x81/0xe1
 [<c0545bff>] __pci_register_driver+0x35/0x62
 [<c089f54e>] piix_init+0x14/0x24
 [<c040304a>] do_one_initcall+0x4a/0x122
 [<c089f53a>] ? piix_init+0x0/0x24
 [<c046ffd9>] ? register_irq_proc+0x7f/0x9b
 [<c0470048>] ? init_irq_proc+0x53/0x60
 [<c0877319>] kernel_init+0x104/0x155
 [<c0877215>] ? kernel_init+0x0/0x155
 [<c0409ed3>] kernel_thread_helper+0x7/0x10
ata_piix: probe of 0000:00:1f.1 failed with error -38

-- Pasi

Re: pv_ops dom0 kernel failure with ata_piix / irq problems

[Jeremy Fitzhardinge]

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.

> Call Trace:
>  [<c06dd32e>] ? printk+0xf/0x11
>  [<c04079bc>] xen_pci_pirq_disable+0x18/0x1c
>   
(This is just a reminder to me to implement this function; it only got 
called because ata-piix had already decided to fail and was 
unregistering its resources.)

    J

Re: pv_ops dom0 kernel failure with ata_piix / irq problems

[Pasi Kärkkäinen]

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.

-- Pasi

Re: pv_ops dom0 kernel failure with ata_piix / irq problems

[Pasi Kärkkäinen]

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
xen: disable pci device 0000:00:1f.1
Pid: 1, comm: swapper Not tainted 2.6.29-rc1-tip #4
Call Trace:
 [<c06dde84>] ? printk+0xf/0x13
 [<c04079bc>] xen_pci_pirq_disable+0x18/0x1c
 [<c0657468>] pcibios_disable_device+0x18/0x1a
 [<c0543303>] do_pci_disable_device+0x4b/0x50
 [<c054345d>] pci_disable_device+0x3f/0x4b
 [<c05437c1>] pcim_release+0x6f/0x74
 [<c05c18ce>] release_nodes+0x14a/0x165
 [<c05c19a4>] devres_release_all+0x25/0x2a
 [<c05bfeb4>] driver_probe_device+0xb7/0x12f
 [<c05bff78>] __driver_attach+0x4c/0x6b
 [<c05bf8da>] bus_for_each_dev+0x3b/0x63
 [<c05bfd42>] driver_attach+0x14/0x16
 [<c05bff2c>] ? __driver_attach+0x0/0x6b
 [<c05bf34d>] bus_add_driver+0x9d/0x1ba
 [<c05c00ff>] driver_register+0x81/0xe1
 [<c04e107e>] ? sysfs_add_file+0xe/0x13
 [<c0545bff>] __pci_register_driver+0x35/0x62
 [<c08a155e>] piix_init+0x24/0x4e
 [<c040304a>] do_one_initcall+0x4a/0x122
 [<c08a153a>] ? piix_init+0x0/0x4e
 [<c046ffd9>] ? register_irq_proc+0x7f/0x9b
 [<c0470048>] ? init_irq_proc+0x53/0x60
 [<c0879319>] kernel_init+0x104/0x155
 [<c0879215>] ? kernel_init+0x0/0x155
 [<c0409ed3>] kernel_thread_helper+0x7/0x10
ata_piix: probe of 0000:00:1f.1 failed with error -38
piix_init: done


I guess I have to start reading the source to figure out why the port is
'frozen'.. 

-- Pasi

Re: pv_ops dom0 kernel failure with ata_piix / irq problems

[Jeremy Fitzhardinge]

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?

    J

Re: pv_ops dom0 kernel failure with ata_piix / irq problems

[Pasi Kärkkäinen]

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.

-- Pasi

Re: pv_ops dom0 kernel failure with ata_piix / irq problems

[Pasi Kärkkäinen]

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

Re: pv_ops dom0 kernel failure with ata_piix / irq problems

[Pasi Kärkkäinen]

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

Re: pv_ops dom0 kernel failure with ata_piix / irq problems

[Jeremy Fitzhardinge]

Pasi Kärkkäinen wrote:
> 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? 


Good question.  Will need to pick through

Hm, wonder if its something to do with the handling of the legacy irqs:

ata_pci_sff_activate_host: pci_read_config_byte()
ata_pci_sff_activate_host: if (!devres_open_group(dev, NULL, GFP_KERNEL))
ata_pci_sff_activate_host: if (!legacy_mode && pdev->irq)
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


    J

Re: pv_ops dom0 kernel failure with ata_piix / irq problems

[Pasi Kärkkäinen]

On Sat, Jan 24, 2009 at 04:59:48PM -0800, Jeremy Fitzhardinge wrote:
> Pasi Kärkkäinen wrote:
> >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? 
> 
> 
> Good question.  Will need to pick through
> 
> Hm, wonder if its something to do with the handling of the legacy irqs:
> 
> ata_pci_sff_activate_host: pci_read_config_byte()
> ata_pci_sff_activate_host: if (!devres_open_group(dev, NULL, GFP_KERNEL))
> ata_pci_sff_activate_host: if (!legacy_mode && pdev->irq)
> 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
> 
> 

Yeah, there seems to be something wrong with the legacy irq handling.

PS/2 stuff also confirms that:

PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice

irq 12: nobody cared (try booting with the "irqpoll" option)
Pid: 0, comm: swapper Not tainted 2.6.29-rc1-tip #13
Call Trace:
 [<c046f0da>] __report_bad_irq+0x2e/0x6f
 [<c046f20b>] note_interrupt+0xf0/0x149
 [<c046f7e2>] handle_level_irq+0x7a/0xaf
 [<c046f768>] ? handle_level_irq+0x0/0xaf
 <IRQ>  [<c0590976>] ? xen_evtchn_do_upcall+0xc0/0x139
 [<c0409f27>] ? xen_do_upcall+0x7/0xc
 [<c0402227>] ? _stext+0x227/0x1000
 [<c040656b>] ? xen_force_evtchn_callback+0xf/0x14
 [<c0406cc6>] ? check_events+0x8/0xe
 [<c0406bf7>] ? xen_irq_enable_direct_end+0x0/0x1
 [<c0433759>] ? finish_task_switch+0x63/0xe5
 [<c06defa0>] ? __schedule+0x756/0x7c0
 [<c05909de>] ? xen_evtchn_do_upcall+0x128/0x139
 [<c04096ab>] ? restore_nocheck_notrace+0x0/0xe
 [<c045007b>] ? clocksource_register+0x3e/0x175
 [<c06df007>] ? __schedule+0x7bd/0x7c0
 [<c06df012>] ? schedule+0x8/0x17
 [<c04086bf>] ? cpu_idle+0x9b/0xa0
 [<c06cea46>] ? rest_init+0x4e/0x50
handlers:
[<c061c971>] (i8042_interrupt+0x0/0x1e7)
Disabling IRQ #12

-- Pasi

Re: pv_ops dom0 kernel failure with ata_piix / irq problems

[Ian Campbell]

On Sat, 2009-01-24 at 16:59 -0800, Jeremy Fitzhardinge wrote:
> Pasi Kärkkäinen wrote:
> > 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? 
> 
> 
> Good question.  Will need to pick through
> 
> Hm, wonder if its something to do with the handling of the legacy irqs:
> 
> ata_pci_sff_activate_host: pci_read_config_byte()
> ata_pci_sff_activate_host: if (!devres_open_group(dev, NULL, GFP_KERNEL))
> ata_pci_sff_activate_host: if (!legacy_mode && pdev->irq)
> 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

I see a similar failure to allocate IRQ 14 although in my case some
other driver comes along and makes it work so I hadn't noticed until
just now.

In my case request_irq() was being called direct rather than via
devm_request_irq and the return was -ENOSYS (it'd be interesting to know
what != 0 value was seen here). I followed this down to __setup_irq()
which has:
	if (desc->chip == &no_irq_chip)
		return -ENOSYS;

So it looks like something expects there to already be a chip present
for the legacy IRQ. For non-legacy IRQs I think we setup the chip
through xen_pci_pirq_enable() -> xen_register_gsi() ->
xen_allocate_pirq() -> set_irq_chip_and_handler_name(). Perhaps legacy
IRQs do not (always) get explicitly enabled?

This little hack made things work for me. 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.

--- a/arch/x86/xen/pci.c	Fri Jan 30 17:39:54 2009 +0000
+++ b/arch/x86/xen/pci.c	Fri Jan 30 18:08:36 2009 +0000
@@ -133,4 +133,7 @@
 	/* Blerk. */
 	acpi_gbl_FADT.sci_interrupt = irq;
 #endif
+
+	for (irq = 0 ; irq < 16 ; irq ++)
+		xen_allocate_pirq(irq);
 }

Re: pv_ops dom0 kernel failure with ata_piix / irq problems

[Ian Campbell]

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.

--- a/arch/x86/xen/pci.c	Fri Jan 30 17:39:54 2009 +0000
+++ b/arch/x86/xen/pci.c	Fri Jan 30 18:16:34 2009 +0000
@@ -75,15 +75,6 @@
 
 		printk(KERN_INFO "xen: PCI device %s pin %d -> irq %d\n",
 		       pci_name(dev), dev->pin, irq);
-	} else if (((dev->class >> 8) == PCI_CLASS_STORAGE_IDE) &&
-		    (dev->class & 0x05) == 0) {
-		/* Legacy IDE devices have hard-coded irq 14/15 */
-		printk(KERN_INFO "xen: %s: legacy IDE\n", pci_name(dev));
-
-		xen_register_gsi(14, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW);
-		xen_register_gsi(15, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW);
-
-		rc = 0;
 	} else {
 		printk(KERN_INFO "xen: irq enable for %s failed: rc=%d pin=%d irq=%d\n",
 			pci_name(dev), rc, dev->pin, dev->irq);
@@ -133,4 +124,6 @@
 	/* Blerk. */
 	acpi_gbl_FADT.sci_interrupt = irq;
 #endif
+	xen_register_gsi(14, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW);
+	xen_register_gsi(15, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW);
 }

Re: pv_ops dom0 kernel failure with ata_piix / irq problems

[Jeremy Fitzhardinge]

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.

    J

Re: pv_ops dom0 kernel failure with ata_piix / irq problems

[Pasi Kärkkäinen]

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!

-- Pasi

Re: pv_ops dom0 kernel failure with ata_piix / irq problems

[Pasi Kärkkäinen]

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
ata5.00: configured for UDMA/100
ata5: EH complete
ata5.00: limiting speed to UDMA/66:PIO4
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
ata5.00: configured for UDMA/66
ata5: EH complete
ata5.00: limiting speed to UDMA/33:PIO4
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
ata5.00: configured for UDMA/33
ata5: EH complete
ata5.00: limiting speed to PIO4
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
ata5.00: configured for PIO4
ata5: EH complete
ata5.00: limiting speed to PIO3
ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
ata5.00: cmd c4/00:08:00:00:00/00:00:00:00:00/e0 tag 0 pio 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
ata5.00: configured for PIO3
ata5: EH complete
ata5.00: limiting speed to PIO0
ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
ata5.00: cmd c4/00:08:00:00:00/00:00:00:00:00/e0 tag 0 pio 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
ata5.00: configured for PIO0
sd 4:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
sd 4:0:0:0: [sda] Sense Key : Aborted Command [current] [descriptor]
Descriptor sense data with sense descriptors (in hex):
        72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00 
        00 00 00 00 
sd 4:0:0:0: [sda] Add. Sense: No additional sense information
end_request: I/O error, dev sda, sector 0
Buffer I/O error on device sda, logical block 0
ata5: EH complete
ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
ata5.00: cmd c4/00:08:00:00:00/00:00:00:00:00/e0 tag 0 pio 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
ata5.00: configured for PIO0
ata5: EH complete
ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
ata5.00: cmd c4/00:08:00:00:00/00:00:00:00:00/e0 tag 0 pio 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
ata5.00: configured for PIO0
ata5: EH complete
ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
ata5.00: cmd c4/00:08:00:00:00/00:00:00:00:00/e0 tag 0 pio 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
ata5.00: configured for PIO0
ata5: EH complete

Re: pv_ops dom0 kernel failure with ata_piix / irq problems

[Pasi Kärkkäinen]

On Mon, Feb 02, 2009 at 09:22:17PM +0200, 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.. 
> 

I enabled the following in include/linux/libata.h:

#define ATA_DEBUG
#define ATA_VERBOSE_DEBUG
#define ATA_IRQ_TRAP

And here's dom0 bootlog with those debugging options enabled:
http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-9-xen331-linux-2.6.29-rc3-atadebug.txt

Is there something you'd like me to try/test? 

-- Pasi

Re: pv_ops dom0 kernel failure with ata_piix / irq problems

[Pasi Kärkkäinen]

On Mon, Feb 02, 2009 at 10:11:13PM +0200, Pasi Kärkkäinen wrote:
> On Mon, Feb 02, 2009 at 09:22:17PM +0200, 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.. 
> > 
> 
> I enabled the following in include/linux/libata.h:
> 
> #define ATA_DEBUG
> #define ATA_VERBOSE_DEBUG
> #define ATA_IRQ_TRAP
> 
> And here's dom0 bootlog with those debugging options enabled:
> http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-9-xen331-linux-2.6.29-rc3-atadebug.txt
> 
> Is there something you'd like me to try/test? 
> 

Hmm.. I was using this patch, which looks different from what was committed
to the patches.hg repository 2 hours ago..


--- a/arch/x86/xen/pci.c        Fri Jan 30 17:39:54 2009 +0000                                                                                                
+++ b/arch/x86/xen/pci.c        Fri Jan 30 18:16:34 2009 +0000                                                                                                
@@ -75,15 +75,6 @@                                                                                                                                            
                                                                                                                                                              
                printk(KERN_INFO "xen: PCI device %s pin %d -> irq %d\n",                                                                                     
                       pci_name(dev), dev->pin, irq);                                                                                                         
-       } else if (((dev->class >> 8) == PCI_CLASS_STORAGE_IDE) &&                                                                                            
-                   (dev->class & 0x05) == 0) {                                                                                                               
-               /* Legacy IDE devices have hard-coded irq 14/15 */                                                                                            
-               printk(KERN_INFO "xen: %s: legacy IDE\n", pci_name(dev));                                                                                     
-                                                                                                                                                             
-               xen_register_gsi(14, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW);                                                                                  
-               xen_register_gsi(15, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW);                                                                                  
-                                                                                                                                                             
-               rc = 0;                                                                                                                                       
        } else {                                                                                                                                              
                printk(KERN_INFO "xen: irq enable for %s failed: rc=%d pin=%d irq=%d\n",                                                                      
                        pci_name(dev), rc, dev->pin, dev->irq);                                                                                               
@@ -133,4 +124,6 @@                                                                                                                                           
        /* Blerk. */                                                                                                                                          
        acpi_gbl_FADT.sci_interrupt = irq;                                                                                                                    
 #endif                                                                                                                                                       
+       xen_register_gsi(14, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW);                                                                                          
+       xen_register_gsi(15, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW);                                                                                          
 }        


-- Pasi

Re: pv_ops dom0 kernel failure with ata_piix / irq problems

[Pasi Kärkkäinen]

On Mon, Feb 02, 2009 at 10:34:55PM +0200, Pasi Kärkkäinen wrote:
> On Mon, Feb 02, 2009 at 10:11:13PM +0200, Pasi Kärkkäinen wrote:
> > On Mon, Feb 02, 2009 at 09:22:17PM +0200, 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.. 
> > > 
> > 
> > I enabled the following in include/linux/libata.h:
> > 
> > #define ATA_DEBUG
> > #define ATA_VERBOSE_DEBUG
> > #define ATA_IRQ_TRAP
> > 
> > And here's dom0 bootlog with those debugging options enabled:
> > http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-9-xen331-linux-2.6.29-rc3-atadebug.txt
> > 
> > Is there something you'd like me to try/test? 
> > 
> 
> Hmm.. I was using this patch, which looks different from what was committed
> to the patches.hg repository 2 hours ago..
> 

I just tried updating to the latest patches repository, which has the legacy
irqs patches. 

It didn't unfortunately help.. I'm still seeing the same problems with
ata_piix.

-- Pasi

> 
> --- a/arch/x86/xen/pci.c        Fri Jan 30 17:39:54 2009 +0000                                                                                                
> +++ b/arch/x86/xen/pci.c        Fri Jan 30 18:16:34 2009 +0000                                                                                                
> @@ -75,15 +75,6 @@                                                                                                                                            
>                                                                                                                                                               
>                 printk(KERN_INFO "xen: PCI device %s pin %d -> irq %d\n",                                                                                     
>                        pci_name(dev), dev->pin, irq);                                                                                                         
> -       } else if (((dev->class >> 8) == PCI_CLASS_STORAGE_IDE) &&                                                                                            
> -                   (dev->class & 0x05) == 0) {                                                                                                               
> -               /* Legacy IDE devices have hard-coded irq 14/15 */                                                                                            
> -               printk(KERN_INFO "xen: %s: legacy IDE\n", pci_name(dev));                                                                                     
> -                                                                                                                                                             
> -               xen_register_gsi(14, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW);                                                                                  
> -               xen_register_gsi(15, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW);                                                                                  
> -                                                                                                                                                             
> -               rc = 0;                                                                                                                                       
>         } else {                                                                                                                                              
>                 printk(KERN_INFO "xen: irq enable for %s failed: rc=%d pin=%d irq=%d\n",                                                                      
>                         pci_name(dev), rc, dev->pin, dev->irq);                                                                                               
> @@ -133,4 +124,6 @@                                                                                                                                           
>         /* Blerk. */                                                                                                                                          
>         acpi_gbl_FADT.sci_interrupt = irq;                                                                                                                    
>  #endif                                                                                                                                                       
> +       xen_register_gsi(14, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW);                                                                                          
> +       xen_register_gsi(15, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW);                                                                                          
>  }        
> 
> 
> -- Pasi
> 

Re: pv_ops dom0 kernel failure with ata_piix / irq problems

[Jeremy Fitzhardinge]

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

Re: pv_ops dom0 kernel failure with ata_piix / irq problems

[Boris Derzhavets]

[-- Attachment #1.1: Type: text/plain, Size: 3650 bytes --]

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@goop.org> wrote:
From: Jeremy Fitzhardinge <jeremy@goop.org>
Subject: Re: [Xen-devel] pv_ops dom0 kernel failure with ata_piix / irq problems
To: "Pasi Kärkkäinen" <pasik@iki.fi>
Cc: "Todd Deshane" <deshantm@gmail.com>, xen-devel@lists.xensource.com, "Andrew Lyon" <andrew.lyon@gmail.com>, "Ian Campbell" <Ian.Campbell@citrix.com>
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@lists.xensource.com
http://lists.xensource.com/xen-devel



      

[-- Attachment #1.2: Type: text/html, Size: 4527 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: pv_ops dom0 kernel failure with ata_piix / irq problems

[Pasi Kärkkäinen]

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@goop.org> wrote:
> From: Jeremy Fitzhardinge <jeremy@goop.org>
> Subject: Re: [Xen-devel] pv_ops dom0 kernel failure with ata_piix / irq problems
> To: "Pasi Kärkkäinen" <pasik@iki.fi>
> Cc: "Todd Deshane" <deshantm@gmail.com>, xen-devel@lists.xensource.com, "Andrew Lyon" <andrew.lyon@gmail.com>, "Ian Campbell" <Ian.Campbell@citrix.com>
> 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@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: pv_ops dom0 kernel failure with ata_piix / irq problems

[Pasi Kärkkäinen]

On Mon, Feb 02, 2009 at 09:32:57PM -0800, Jeremy Fitzhardinge wrote:
> 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...
> 

Ok.. good to hear it's not only me or my testbox:)

Let me know if you have some tips about debugging.. I can do some debugging
later today.

-- Pasi

Attempt to compile 2.6.29-rc3 with pv_ops suppot for Dom0

[Boris Derzhavets]

[-- Attachment #1.1: Type: text/plain, Size: 1375 bytes --]


Follow http://wiki.xensource.com/xenwiki/XenParavirtOps on Ubuntu 8.10 Server

To get a working tree:

   1. hg clone http://www.kernel.org/hg/linux-2.6
   2. cd linux-2.6/.hg
   3. hg clone http://xenbits.xensource.com/paravirt_ops/patches.hg patches
   4. cd ..
   5. ln -s .hg/patches . # for convenience
   6. hg update `cat patches/KERNEL_VERSION`
   7. hg qpush -a

Get the recent patch,in particular :-

root@ServerUbuntu:/usr/src/linux-2.6/.hg/patches# ls -l xen-netback-porting.patch
-rw-r--r-- 1 root src 28228 2009-01-31 08:18 xen-netback-porting.patch


make menuconfig
as suggested for pv_ops

make
. . . . . . .

drivers/xen/blkback/xenbus.c: In function ‘update_blkif_status’:
drivers/xen/blkback/xenbus.c:89: warning: format not a string literal and no format arguments
  CC      drivers/xen/blkback/interface.o
  CC      drivers/xen/blkback/vbd.o
  LD      drivers/xen/blkback/blkbk.o
  LD      drivers/xen/blkback/built-in.o
  CC      drivers/xen/netback/netback.o
drivers/xen/netback/netback.c: In function ‘netbk_copy_skb’:
drivers/xen/netback/netback.c:207: error: invalid operands to binary - (have ‘sk_buff_data_t’ and ‘unsigned char *’)
make[3]: *** [drivers/xen/netback/netback.o] Error 1
make[2]: *** [drivers/xen/netback] Error 2
make[1]: *** [drivers/xen] Error 2
make: *** [drivers] Error 2





      

[-- Attachment #1.2: Type: text/html, Size: 1796 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: Attempt to compile 2.6.29-rc3 with pv_ops suppot for Dom0

[Jeremy Fitzhardinge]

Boris Derzhavets wrote:
>
> Follow http://wiki.xensource.com/xenwiki/XenParavirtOps on Ubuntu 8.10 
> Server
>
> To get a working tree:
>
>    1. hg clone http://www.kernel.org/hg/linux-2.6
>    2. cd linux-2.6/.hg
>    3. hg clone http://xenbits.xensource.com/paravirt_ops/patches.hg 
> patches
>    4. cd ..
>    5. ln -s .hg/patches . # for convenience
>    6. hg update `cat patches/KERNEL_VERSION`
>    7. hg qpush -a
>
> Get the recent patch,in particular :-
>
> root@ServerUbuntu:/usr/src/linux-2.6/.hg/patches# ls -l 
> xen-netback-porting.patch
> -rw-r--r-- 1 root src 28228 2009-01-31 08:18 xen-netback-porting.patch
>

Netback support was just added, and it didn't compile for me last time I 
tried.  I think Ian has a fix, but I'm not sure if he's committed it yet.

    J

Re: Attempt to compile 2.6.29-rc3 with pv_ops suppot for Dom0

[Ian Campbell]

On Sun, 2009-02-01 at 17:14 -0800, Jeremy Fitzhardinge wrote:
> Boris Derzhavets wrote:
> >
> > Follow http://wiki.xensource.com/xenwiki/XenParavirtOps on Ubuntu 8.10 
> > Server
> >
> > To get a working tree:
> >
> >    1. hg clone http://www.kernel.org/hg/linux-2.6
> >    2. cd linux-2.6/.hg
> >    3. hg clone http://xenbits.xensource.com/paravirt_ops/patches.hg 
> > patches
> >    4. cd ..
> >    5. ln -s .hg/patches . # for convenience
> >    6. hg update `cat patches/KERNEL_VERSION`
> >    7. hg qpush -a
> >
> > Get the recent patch,in particular :-
> >
> > root@ServerUbuntu:/usr/src/linux-2.6/.hg/patches# ls -l 
> > xen-netback-porting.patch
> > -rw-r--r-- 1 root src 28228 2009-01-31 08:18 xen-netback-porting.patch
> >
> 
> Netback support was just added, and it didn't compile for me last time I 
> tried.  I think Ian has a fix, but I'm not sure if he's committed it yet.

It was compiling and working for me on 32 bit. I hadn't tried 64 bit
(which I guess you both are using).  netback.c:207 is "headlen =
nskb->end - nskb->data" and the type of ->end is sk_buff_data_t which
differs with 32 vs 64 bitness. Will investigate.


Ian.

Re: Attempt to compile 2.6.29-rc3 with pv_ops suppot for Dom0

[Boris Derzhavets]

[-- Attachment #1.1: Type: text/plain, Size: 2485 bytes --]

That's right i've tried to compile on 64-bit Ubuntu 8.10 Server.

root@ServerUbuntu:~# gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.2-1ubuntu11' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11) 

Boris
--- On Mon, 2/2/09, Ian Campbell <Ian.Campbell@citrix.com> wrote:
From: Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Attempt to compile 2.6.29-rc3 with pv_ops suppot for Dom0
To: "Jeremy Fitzhardinge" <jeremy@goop.org>
Cc: "Todd Deshane" <deshantm@gmail.com>, bderzhavets@yahoo.com, xen-devel@lists.xensource.com, "Andrew Lyon" <andrew.lyon@gmail.com>
Date: Monday, February 2, 2009, 4:53 AM

On Sun, 2009-02-01 at 17:14 -0800, Jeremy Fitzhardinge wrote:
> Boris Derzhavets wrote:
> >
> > Follow http://wiki.xensource.com/xenwiki/XenParavirtOps on Ubuntu
8.10 
> > Server
> >
> > To get a working tree:
> >
> >    1. hg clone http://www.kernel.org/hg/linux-2.6
> >    2. cd linux-2.6/.hg
> >    3. hg clone http://xenbits.xensource.com/paravirt_ops/patches.hg 
> > patches
> >    4. cd ..
> >    5. ln -s .hg/patches . # for convenience
> >    6. hg update `cat patches/KERNEL_VERSION`
> >    7. hg qpush -a
> >
> > Get the recent patch,in particular :-
> >
> > root@ServerUbuntu:/usr/src/linux-2.6/.hg/patches# ls -l 
> > xen-netback-porting.patch
> > -rw-r--r-- 1 root src 28228 2009-01-31 08:18
xen-netback-porting.patch
> >
> 
> Netback support was just added, and it didn't compile for me last time
I 
> tried.  I think Ian has a fix, but I'm not sure if he's committed
it yet.

It was compiling and working for me on 32 bit. I hadn't tried 64 bit
(which I guess you both are using).  netback.c:207 is "headlen =
nskb->end - nskb->data" and the type of ->end is sk_buff_data_t
which
differs with 32 vs 64 bitness. Will investigate.


Ian.



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



      

[-- Attachment #1.2: Type: text/html, Size: 3112 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: Attempt to compile 2.6.29-rc3 with pv_ops suppot for Dom0

[Ian Campbell]

I pushed a fix this morning, could you try it again please ?

Ian.

On Mon, 2009-02-02 at 04:32 -0800, Boris Derzhavets wrote:
> That's right i've tried to compile on 64-bit Ubuntu 8.10 Server.
> 
> root@ServerUbuntu:~# gcc -v
> Using built-in specs.
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Ubuntu
> 4.3.2-1ubuntu11'
> --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
> --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
> --enable-shared --with-system-zlib --libexecdir=/usr/lib
> --without-included-gettext --enable-threads=posix --enable-nls
> --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3
> --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
> --enable-mpfr --enable-checking=release --build=x86_64-linux-gnu
> --host=x86_64-linux-gnu --target=x86_64-linux-gnu
> Thread model: posix
> gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11) 
> 
> Boris
> --- On Mon, 2/2/09, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>         From: Ian Campbell <Ian.Campbell@citrix.com>
>         Subject: Re: [Xen-devel] Attempt to compile 2.6.29-rc3 with
>         pv_ops suppot for Dom0
>         To: "Jeremy Fitzhardinge" <jeremy@goop.org>
>         Cc: "Todd Deshane" <deshantm@gmail.com>,
>         bderzhavets@yahoo.com, xen-devel@lists.xensource.com, "Andrew
>         Lyon" <andrew.lyon@gmail.com>
>         Date: Monday, February 2, 2009, 4:53 AM
>         
>         On Sun, 2009-02-01 at 17:14 -0800, Jeremy Fitzhardinge wrote:
>         > Boris Derzhavets wrote:
>         > >
>         > > Follow http://wiki.xensource.com/xenwiki/XenParavirtOps on Ubuntu
>         8.10 
>         > > Server
>         > >
>         > > To get a working tree:
>         > >
>         > >    1. hg clone http://www.kernel.org/hg/linux-2.6
>         > >    2. cd linux-2.6/.hg
>         > >    3. hg clone
>          http://xenbits.xensource.com/paravirt_ops/patches.hg 
>         > > patches
>         > >    4. cd ..
>         > >    5. ln -s .hg/patches . # for convenience
>         > >    6. hg update `cat patches/KERNEL_VERSION`
>         > >    7. hg qpush -a
>         > >
>         > > Get the recent patch,in particular :-
>         > >
>         > > root@ServerUbuntu:/usr/src/linux-2.6/.hg/patches# ls -l 
>         > > xen-netback-porting.patch
>         > > -rw-r--r-- 1 root src 28228 2009-01-31 08:18
>         xen-netback-porting.patch
>         > >
>         > 
>         > Netback support was just added, and it didn't compile for me last time
>         I 
>         > tried.  I think Ian has a fix, but I'm not sure if he's committed
>         it yet.
>         
>         It was compiling and working for me on 32 bit. I hadn't tried 64 bit
>         (which I guess you both are using).  netback.c:207 is "headlen =
>         nskb->end - nskb->data" and the type of ->end is sk_buff_data_t
>         which
>         differs with 32 vs 64
>          bitness. Will investigate.
>         
>         
>         Ian.
>         
>         
>         
>         _______________________________________________
>         Xen-devel mailing list
>         Xen-devel@lists.xensource.com
>         http://lists.xensource.com/xen-devel
> 

Re: Attempt to compile 2.6.29-rc3 with pv_ops suppot for Dom0

[Boris Derzhavets]

[-- Attachment #1.1: Type: text/plain, Size: 4062 bytes --]

Build is currently running. However, modules bellow gets compiled OK :-
root@ServerUbuntu:/usr/src/linux-2.6/drivers/xen/netback# ls -l *.o
-rw-r--r-- 1 root src 727940 2009-02-02 08:15 built-in.o
-rw-r--r-- 1 root src 195560 2009-02-02 08:15 interface.o
-rw-r--r-- 1 root src 350464 2009-02-02 08:15 netback.o
-rw-r--r-- 1 root src 727940 2009-02-02 08:15 netbk.o
-rw-r--r-- 1 root src 188416 2009-02-02 08:15 xenbus.o


--- On Mon, 2/2/09, Ian Campbell <Ian.Campbell@citrix.com> wrote:
From: Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Attempt to compile 2.6.29-rc3 with pv_ops suppot for Dom0
To: bderzhavets@yahoo.com
Cc: "Jeremy Fitzhardinge" <jeremy@goop.org>, "Todd Deshane" <deshantm@gmail.com>, xen-devel@lists.xensource.com, "Andrew Lyon" <andrew.lyon@gmail.com>
Date: Monday, February 2, 2009, 7:42 AM

I pushed a fix this morning, could you try it again please ?

Ian.

On Mon, 2009-02-02 at 04:32 -0800, Boris Derzhavets wrote:
> That's right i've tried to compile on 64-bit Ubuntu 8.10 Server.
> 
> root@ServerUbuntu:~# gcc -v
> Using built-in specs.
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Ubuntu
> 4.3.2-1ubuntu11'
> --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
> --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
> --enable-shared --with-system-zlib --libexecdir=/usr/lib
> --without-included-gettext --enable-threads=posix --enable-nls
> --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3
> --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
> --enable-mpfr --enable-checking=release --build=x86_64-linux-gnu
> --host=x86_64-linux-gnu --target=x86_64-linux-gnu
> Thread model: posix
> gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11) 
> 
> Boris
> --- On Mon, 2/2/09, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>         From: Ian Campbell <Ian.Campbell@citrix.com>
>         Subject: Re: [Xen-devel] Attempt to compile 2.6.29-rc3 with
>         pv_ops suppot for Dom0
>         To: "Jeremy Fitzhardinge" <jeremy@goop.org>
>         Cc: "Todd Deshane" <deshantm@gmail.com>,
>         bderzhavets@yahoo.com, xen-devel@lists.xensource.com, "Andrew
>         Lyon" <andrew.lyon@gmail.com>
>         Date: Monday, February 2, 2009, 4:53 AM
>         
>         On Sun, 2009-02-01 at 17:14 -0800, Jeremy Fitzhardinge wrote:
>         > Boris Derzhavets wrote:
>         > >
>         > > Follow http://wiki.xensource.com/xenwiki/XenParavirtOps
on Ubuntu
>         8.10 
>         > > Server
>         > >
>         > > To get a working tree:
>         > >
>         > >    1. hg clone http://www.kernel.org/hg/linux-2.6
>         > >    2. cd linux-2.6/.hg
>         > >    3. hg clone
>          http://xenbits.xensource.com/paravirt_ops/patches.hg 
>         > > patches
>         > >    4. cd ..
>         > >    5. ln -s .hg/patches . # for convenience
>         > >    6. hg update `cat patches/KERNEL_VERSION`
>         > >    7. hg qpush -a
>         > >
>         > > Get the recent patch,in particular :-
>         > >
>         > > root@ServerUbuntu:/usr/src/linux-2.6/.hg/patches# ls -l 
>         > > xen-netback-porting.patch
>         > > -rw-r--r-- 1 root src 28228 2009-01-31 08:18
>         xen-netback-porting.patch
>         > >
>         > 
>         > Netback support was just added, and it didn't compile for
me last time
>         I 
>         > tried.  I think Ian has a fix, but I'm not sure if
he's committed
>         it yet.
>         
>         It was compiling and working for me on 32 bit. I hadn't tried
64 bit
>         (which I guess you both are using).  netback.c:207 is
"headlen =
>         nskb->end - nskb->data" and the type of ->end is
sk_buff_data_t
>         which
>         differs with 32 vs 64
>          bitness. Will investigate.
>         
>         
>         Ian.
>         
>         
>         
>         _______________________________________________
>         Xen-devel mailing list
>         Xen-devel@lists.xensource.com
>         http://lists.xensource.com/xen-devel
> 




      

[-- Attachment #1.2: Type: text/html, Size: 5090 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Attempt to load 2.6.29-rc3 with pv_ops suppot for Dom0 under Xen 3.3.1 Hypervisor

[Boris Derzhavets]

[-- Attachment #1.1: Type: text/plain, Size: 5752 bytes --]

Kernel compilation:-

cd linux-2.6
hg qpop -a
hg -R .hg/patches pull -u
hg qpush -a
make menuconfig # per Wiki
make
make modules_install install
ls /lib/modules
depmod 2.6.29-rc3-tip
mkinitramfs -o /boot/initrd-2.6.29-rc3-tip.img 2.6.29-rc3-tip


vi /boot/grub/menu.lst

title Xen 3.3.1 / Ubuntu 8.10, kernel 2.6.29-tip (added to test)
uuid   c841c5e9-8eb2-4e47-b36e-6796e5ce6ce6
kernel /boot/xen-3.3.1.gz
module /boot/vmlinuz-2.6.29-rc3-tip root=/dev/sdb1 ro console=tty0
module /boot/initrd-2.6.29-rc3-tip.img

title Xen 3.3.1 / Ubuntu 8.10, kernel 2.6.27-xen (currently working)
uuid   c841c5e9-8eb2-4e47-b36e-6796e5ce6ce6
kernel /boot/xen-3.3.gz
module /boot/vmlinuz-2.6.27.5 root=/dev/sdb1 ro console=tty0
module /boot/initrd-2.6.27.5.img


Loading  with first entry:-

Loading Dom0
**************************
elf_init: not an ELF binary
Panic on CPU0
Couldn't set up Dom0 guest OS
**************************
Reboot in 5 sec.

--- On Mon, 2/2/09, Boris Derzhavets <bderzhavets@yahoo.com> wrote:
From: Boris Derzhavets <bderzhavets@yahoo.com>
Subject: Re: [Xen-devel] Attempt to compile 2.6.29-rc3 with pv_ops suppot for Dom0
To: "Ian Campbell" <Ian.Campbell@citrix.com>
Cc: "Todd Deshane" <deshantm@gmail.com>, "Jeremy Fitzhardinge" <jeremy@goop.org>, xen-devel@lists.xensource.com, "Andrew Lyon" <andrew.lyon@gmail.com>
Date: Monday, February 2, 2009, 8:22 AM

Build is currently running. However, modules bellow gets compiled OK :-
root@ServerUbuntu:/usr/src/linux-2.6/drivers/xen/netback# ls -l *.o
-rw-r--r-- 1 root src 727940 2009-02-02 08:15 built-in.o
-rw-r--r-- 1 root src 195560 2009-02-02 08:15 interface.o
-rw-r--r-- 1 root src 350464 2009-02-02 08:15 netback.o
-rw-r--r-- 1 root src 727940 2009-02-02 08:15 netbk.o
-rw-r--r-- 1 root src 188416 2009-02-02 08:15 xenbus.o


--- On Mon, 2/2/09, Ian Campbell <Ian.Campbell@citrix.com> wrote:
From: Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Attempt to compile 2.6.29-rc3 with pv_ops suppot for Dom0
To: bderzhavets@yahoo.com
Cc: "Jeremy Fitzhardinge" <jeremy@goop.org>, "Todd Deshane"
 <deshantm@gmail.com>, xen-devel@lists.xensource.com, "Andrew Lyon" <andrew.lyon@gmail.com>
Date: Monday, February 2, 2009, 7:42 AM

I pushed a fix this morning, could you try it again please ?

Ian.

On Mon, 2009-02-02 at 04:32 -0800, Boris Derzhavets wrote:
> That's right i've tried to compile on 64-bit Ubuntu 8.10 Server.
> 
> root@ServerUbuntu:~# gcc -v
> Using built-in specs.
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Ubuntu
> 4.3.2-1ubuntu11'
> --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
> --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
> --enable-shared --with-system-zlib --libexecdir=/usr/lib
> --without-included-gettext --enable-threads=posix --enable-nls
> --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3
> --enable-clocale=gnu
 --enable-libstdcxx-debug --enable-objc-gc
> --enable-mpfr --enable-checking=release --build=x86_64-linux-gnu
> --host=x86_64-linux-gnu --target=x86_64-linux-gnu
> Thread model: posix
> gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11) 
> 
> Boris
> --- On Mon, 2/2/09, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>         From: Ian Campbell <Ian.Campbell@citrix.com>
>         Subject: Re: [Xen-devel] Attempt to compile 2.6.29-rc3 with
>         pv_ops suppot for Dom0
>         To: "Jeremy Fitzhardinge" <jeremy@goop.org>
>         Cc: "Todd Deshane" <deshantm@gmail.com>,
>         bderzhavets@yahoo.com, xen-devel@lists.xensource.com, "Andrew
>         Lyon" <andrew.lyon@gmail.com>
>         Date: Monday, February 2, 2009, 4:53 AM
>         
>         On Sun, 2009-02-01 at 17:14 -0800, Jeremy Fitzhardinge wrote:
>        
 > Boris Derzhavets wrote:
>         > >
>         > > Follow http://wiki.xensource.com/xenwiki/XenParavirtOps
on Ubuntu
>         8.10 
>         > > Server
>         > >
>         > > To get a working tree:
>         > >
>         > >    1. hg clone http://www.kernel.org/hg/linux-2.6
>         > >    2. cd linux-2.6/.hg
>         > >    3. hg clone
>          http://xenbits.xensource.com/paravirt_ops/patches.hg 
>         > > patches
>         > >    4. cd ..
>         > >    5. ln -s .hg/patches . # for convenience
>         > >    6. hg update `cat patches/KERNEL_VERSION`
>         > >    7. hg qpush -a
>         > >
>         > > Get the recent patch,in particular :-
>         > >
>         > >
 root@ServerUbuntu:/usr/src/linux-2.6/.hg/patches# ls -l 
>         > > xen-netback-porting.patch
>         > > -rw-r--r-- 1 root src 28228 2009-01-31 08:18
>         xen-netback-porting.patch
>         > >
>         > 
>         > Netback support was just added, and it didn't compile for
me last time
>         I 
>         > tried.  I think Ian has a fix, but I'm not sure if
he's committed
>         it yet.
>         
>         It was compiling and working for me on 32 bit. I hadn't tried
64 bit
>         (which I guess you both are using).  netback.c:207 is
"headlen =
>         nskb->end - nskb->data" and the type of ->end is
sk_buff_data_t
>         which
>         differs with 32 vs 64
>          bitness. Will investigate.
>         
>         
>         Ian.
>         
>     
    
>         
>         _______________________________________________
>         Xen-devel mailing list
>         Xen-devel@lists.xensource.com
>         http://lists.xensource.com/xen-devel
> 






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



      

[-- Attachment #1.2: Type: text/html, Size: 7320 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: Attempt to load 2.6.29-rc3 with pv_ops suppot for Dom0 under Xen 3.3.1 Hypervisor

[Ian Campbell]

On Mon, 2009-02-02 at 06:04 -0800, Boris Derzhavets wrote:
> make modules_install install
> [...]
> Loading Dom0
> **************************
> elf_init: not an ELF binary
> 

Only extremely recent xen-unstable hypervisors (circa last week) can
load a bzImage format kernel for dom0 (which is what "make install" will
have given you) -- you need to use the vmlinux file from the toplevel of
the kernel build directly (optionally stripped+gzipped) or upgrade your
hypervisor.

Ian.

Re: Re: Attempt to load 2.6.29-rc3 with pv_ops suppot for Dom0 under Xen 3.3.1 Hypervisor

[Boris Derzhavets]

[-- Attachment #1.1: Type: text/plain, Size: 2282 bytes --]

  I've removed Xen 3.3.1 and installed the most recent unstable Xen Hypervisor. 

# cd /usr/src/xen-3.3.1
# make uninstall
# cd ..
# hg clone http://xenbits.xensource.com/xen-unstable.hg
# cd xen-unstable.hg
# make xen
# make install-xen
# make tools
# make install-tools

Tried following two options:-

title Xen 3.4 / Ubuntu 8.10, kernel 2.6.29-tip
uuid   c841c5e9-8eb2-4e47-b36e-6796e5ce6ce6
kernel /boot/xen-3.4.gz
module /boot/vmlinuz-2.6.29-rc3-tip root=/dev/sdb1 ro console=tty0 earlyprintk=xen pci=nomsi
module /boot/initrd-2.6.29-rc3-tip.img

******************************************************************
Loading starts up and drops to stack trace immediately after 
SATA link up ..
SATA link up .. 
*******************************************************************


title Xen 3.4 / Ubuntu 8.10, kernel 2.6.27-xen
uuid   c841c5e9-8eb2-4e47-b36e-6796e5ce6ce6
kernel /boot/xen-3.4.gz
module /boot/vmlinuz-2.6.27.5 root=/dev/sdb1 ro console=tty0
module /boot/initrd-2.6.27.5.img

***************************************************
Seems to work OK with Novell's Xen-ified kernel
***************************************************

--- On Mon, 2/2/09, Ian Campbell <Ian.Campbell@citrix.com> wrote:
From: Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] Re: Attempt to load 2.6.29-rc3 with pv_ops suppot for Dom0 under Xen 3.3.1 Hypervisor
To: bderzhavets@yahoo.com
Cc: "Todd Deshane" <deshantm@gmail.com>, "Jeremy Fitzhardinge" <jeremy@goop.org>, xen-devel@lists.xensource.com, "Andrew Lyon" <andrew.lyon@gmail.com>
Date: Monday, February 2, 2009, 9:40 AM

On Mon, 2009-02-02 at 06:04 -0800, Boris Derzhavets wrote:
> make modules_install install
> [...]
> Loading Dom0
> **************************
> elf_init: not an ELF binary
> 

Only extremely recent xen-unstable hypervisors (circa last week) can
load a bzImage format kernel for dom0 (which is what "make install"
will
have given you) -- you need to use the vmlinux file from the toplevel of
the kernel build directly (optionally stripped+gzipped) or upgrade your
hypervisor.

Ian.


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



      

[-- Attachment #1.2: Type: text/html, Size: 2744 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: Re: Attempt to load 2.6.29-rc3 with pv_ops suppot for Dom0 under Xen 3.3.1 Hypervisor

[Jeremy Fitzhardinge]

Boris Derzhavets wrote:
>
> title Xen 3.4 / Ubuntu 8.10, kernel 2.6.29-tip
> uuid   c841c5e9-8eb2-4e47-b36e-6796e5ce6ce6
> kernel /boot/xen-3.4.gz
> module /boot/vmlinuz-2.6.29-rc3-tip root=/dev/sdb1 ro console=tty0 
> earlyprintk=xen pci=nomsi
> module /boot/initrd-2.6.29-rc3-tip.img
>
> ******************************************************************
> Loading starts up and drops to stack trace immediately after
> SATA link up ..
> SATA link up ..
> *******************************************************************
>

Can you transcribe a bit more detail here?  Are you trying o use AHCI or 
legacy mode?  Or some other controller?

(Ian: did you commit that legacy IRQ fix?  If not I'll do it shortly.)

    J

Re: Re: Attempt to load 2.6.29-rc3 with pv_ops suppot for Dom0 under Xen 3.3.1 Hypervisor

[Boris Derzhavets]

[-- Attachment #1.1: Type: text/plain, Size: 2505 bytes --]


Hardware config :-
CPU C2D E8400
ASUS P5K Premium/WIFI (P35 (Noth Bridge)+Intel ICH9R (South Bridge))
8 GB RAM
2 x SATA II 250 GB Seagate Barracuda ( no RAID, just /dev/sda and /dev/sdb)

Bios setup for South Bridge is AHCI. Works fine for :-

1. Xen 3.3.1 port to CentOS 5.2 (2.6.18-xen)
2. Xen 3.3.1 port Ubuntu 8.10 Server with Novell's Kernel 2.6.27.5
3. Xen Unstable port Ubuntu 8.10 Server with Novell's Kernel 2.6.27.5
4. Solaris Nevada build 106 (xvm 3.1.4)

All OS multiboot via Nevada Grub installed in MBR.

Each one has it's own grub installed into /boot or / partitions
referenced from main grub's menu as :-

title ......
rootnoverify (hdX,Y)
chainloader +1

I never turned  Intel ICH9R into IDE emulation mode (legacy mode),
due to significant performance degradation of SATA drives.
NCQ would be killed immediately

I don't mind to test new kernel (under Xen)  with ICH9R in legacy mode.
However, i believe that handling Intel Chips ICH9(10)R in AHCI mode
is very important for flagman linux kernels,supporting pv_ops in Dom0.
Legacy mode ( through my comrehension) would disable NCQ on SATA II
drives.
Boris.
--- On Mon, 2/2/09, Jeremy Fitzhardinge <jeremy@goop.org> wrote:
From: Jeremy Fitzhardinge <jeremy@goop.org>
Subject: Re: [Xen-devel] Re: Attempt to load 2.6.29-rc3 with pv_ops suppot for Dom0 under Xen 3.3.1 Hypervisor
To: bderzhavets@yahoo.com
Cc: "Todd Deshane" <deshantm@gmail.com>, xen-devel@lists.xensource.com, "Andrew Lyon" <andrew.lyon@gmail.com>, "Ian Campbell" <Ian.Campbell@citrix.com>
Date: Monday, February 2, 2009, 12:32 PM

Boris Derzhavets wrote:
> 
> title Xen 3.4 / Ubuntu 8.10, kernel 2.6.29-tip
> uuid   c841c5e9-8eb2-4e47-b36e-6796e5ce6ce6
> kernel /boot/xen-3.4.gz
> module /boot/vmlinuz-2.6.29-rc3-tip root=/dev/sdb1 ro console=tty0
earlyprintk=xen pci=nomsi
> module /boot/initrd-2.6.29-rc3-tip.img
> 
> ******************************************************************
> Loading starts up and drops to stack trace immediately after
> SATA link up ..
> SATA link up ..
> *******************************************************************
> 

Can you transcribe a bit more detail here?  Are you trying o use AHCI or legacy
mode?  Or some other controller?

(Ian: did you commit that legacy IRQ fix?  If not I'll do it shortly.)

   J

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



      

[-- Attachment #1.2: Type: text/html, Size: 2976 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: Re: Attempt to load 2.6.29-rc3 with pv_ops suppot for Dom0 under Xen 3.3.1 Hypervisor

[Boris Derzhavets]

[-- Attachment #1.1: Type: text/plain, Size: 3643 bytes --]

I just tried to load kernel with the most recent patches under Xen Unstable
 
 South bridge Intel ICH9R. 
 
 1. AHCI mode - same picture. Drops to stack trace after messages
     SATA Link down ( exactly down)

 2. IDE Emulation. Doesn't drop to stack trace, but drops 
     to (initramfs) prompt continue to boot slowly.
     Seems to activate ata_piix for both drives, but hangs 
     attempting to load CDROM driver (sr0) or detecting CDROM. 
     Press enter brings to prompt  (initramfs) 

--- On Mon, 2/2/09, Boris Derzhavets <bderzhavets@yahoo.com> wrote:
From: Boris Derzhavets <bderzhavets@yahoo.com>
Subject: Re: [Xen-devel] Re: Attempt to load 2.6.29-rc3 with pv_ops suppot for Dom0 under Xen 3.3.1 Hypervisor
To: "Jeremy Fitzhardinge" <jeremy@goop.org>
Cc: "Todd Deshane" <deshantm@gmail.com>, xen-devel@lists.xensource.com, "Andrew Lyon" <andrew.lyon@gmail.com>, "Ian Campbell" <Ian.Campbell@citrix.com>
Date: Monday, February 2, 2009, 1:08 PM


Hardware config :-
CPU C2D E8400
ASUS P5K Premium/WIFI (P35 (Noth Bridge)+Intel ICH9R (South Bridge))
8 GB RAM
2 x SATA II 250 GB Seagate Barracuda ( no RAID, just /dev/sda and /dev/sdb)

Bios setup for South Bridge is AHCI. Works fine for :-

1. Xen 3.3.1 port to CentOS 5.2 (2.6.18-xen)
2. Xen 3.3.1 port Ubuntu 8.10 Server with Novell's Kernel 2.6.27.5
3. Xen Unstable port Ubuntu 8.10 Server with Novell's Kernel 2.6.27.5
4. Solaris Nevada build 106 (xvm 3.1.4)

All OS multiboot via Nevada Grub installed in MBR.

Each one has it's own grub installed into /boot or / partitions
referenced from main grub's menu as :-

title ......
rootnoverify (hdX,Y)
chainloader +1

I never turned  Intel ICH9R into IDE emulation mode (legacy mode),
due to significant performance degradation of SATA
 drives.
NCQ would be killed immediately

I don't mind to test new kernel (under Xen)  with ICH9R in legacy mode.
However, i believe that handling Intel Chips ICH9(10)R in AHCI mode
is very important for flagman linux kernels,supporting pv_ops in Dom0.
Legacy mode ( through my comrehension) would disable NCQ on SATA II
drives.
Boris.
--- On Mon, 2/2/09, Jeremy Fitzhardinge <jeremy@goop.org> wrote:
From: Jeremy Fitzhardinge <jeremy@goop.org>
Subject: Re: [Xen-devel] Re: Attempt to load 2.6.29-rc3 with pv_ops suppot for Dom0 under Xen 3.3.1 Hypervisor
To: bderzhavets@yahoo.com
Cc: "Todd Deshane" <deshantm@gmail.com>, xen-devel@lists.xensource.com, "Andrew Lyon" <andrew.lyon@gmail.com>, "Ian Campbell" <Ian.Campbell@citrix.com>
Date: Monday, February 2, 2009, 12:32
 PM

Boris Derzhavets wrote:
> 
> title Xen 3.4 / Ubuntu 8.10, kernel 2.6.29-tip
> uuid   c841c5e9-8eb2-4e47-b36e-6796e5ce6ce6
> kernel /boot/xen-3.4.gz
> module /boot/vmlinuz-2.6.29-rc3-tip root=/dev/sdb1 ro console=tty0
earlyprintk=xen pci=nomsi
> module /boot/initrd-2.6.29-rc3-tip.img
> 
> ******************************************************************
> Loading starts up and drops to stack trace immediately after
> SATA link up ..
> SATA link up ..
> *******************************************************************
> 

Can you transcribe a bit more detail here?  Are you trying o use AHCI or legacy
mode?  Or some other controller?

(Ian: did you commit that legacy IRQ fix?  If not I'll do it shortly.)

   J

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



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



      

[-- Attachment #1.2: Type: text/html, Size: 4795 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: Re: Attempt to load 2.6.29-rc3 with pv_ops suppot for Dom0 under Xen 3.3.1 Hypervisor

[Jeremy Fitzhardinge]

Boris Derzhavets wrote:
> I just tried to load kernel with the most recent patches under Xen 
> Unstable
>  
>  South bridge Intel ICH9R.
>  
>  1. AHCI mode - same picture. Drops to stack trace after messages
>      SATA Link down ( exactly down)
>

Yeah.  AHCI doesn't work, but I don't know why yet. 

>
>  2. IDE Emulation. Doesn't drop to stack trace, but drops
>      to (initramfs) prompt continue to boot slowly.
>      Seems to activate ata_piix for both drives, but hangs
>      attempting to load CDROM driver (sr0) or detecting CDROM.
>      Press enter brings to prompt  (initramfs)
>

Hm...  I have had PIIX working pretty well in the past.

    J

Re: Re: Attempt to load 2.6.29-rc3 with pv_ops suppot for Dom0 under Xen 3.3.1 Hypervisor

[Boris Derzhavets]

[-- Attachment #1.1: Type: text/plain, Size: 1721 bytes --]

  What was the spec for South Bridge (and board in general)  you succeeded with ?  It might be hardware or even BIOS release dependent issue.
  
  PIIX would be also loaded for pretty old ULTRA DMA (IDE) controllers
as well and for any Intel ICH(X) (X=6,7,8) without "R" extension chip.
  
  The last ones actually don't support AHCI at all, no matter of BIOS
setup. View Intel Storage Matrix for details.
     My guess  would be to address Intel with this kind of problems.
   
  How behaves 2.6.29-rc3 (pv_ops Dom0) under Xen on SAS/SCSI controllers ( Dell PowerEdge 2900) ?

--- On Mon, 2/2/09, Jeremy Fitzhardinge <jeremy@goop.org> wrote:
From: Jeremy Fitzhardinge <jeremy@goop.org>
Subject: Re: [Xen-devel] Re: Attempt to load 2.6.29-rc3 with pv_ops suppot for Dom0 under Xen 3.3.1 Hypervisor
To: bderzhavets@yahoo.com
Cc: "Todd Deshane" <deshantm@gmail.com>, xen-devel@lists.xensource.com, "Andrew Lyon" <andrew.lyon@gmail.com>, "Ian Campbell" <Ian.Campbell@citrix.com>
Date: Monday, February 2, 2009, 6:11 PM

Boris Derzhavets wrote:
> I just tried to load kernel with the most recent patches under Xen
Unstable
>   South bridge Intel ICH9R.
>   1. AHCI mode - same picture. Drops to stack trace after messages
>      SATA Link down ( exactly down)
> 

Yeah.  AHCI doesn't work, but I don't know why yet. 
> 
>  2. IDE Emulation. Doesn't drop to stack trace, but drops
>      to (initramfs) prompt continue to boot slowly.
>      Seems to activate ata_piix for both drives, but hangs
>      attempting to load CDROM driver (sr0) or detecting CDROM.
>      Press enter brings to prompt  (initramfs)
> 

Hm...  I have had PIIX working pretty well in the past.

   J



      

[-- Attachment #1.2: Type: text/html, Size: 2190 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: pv_ops dom0 kernel failure with ata_piix / irq problems

[Gerd Hoffmann]

Jeremy Fitzhardinge wrote:
>> __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?

Looks like caller ignores -Esomething return value somewhere ...

cheers,
  Gerd

Re: pv_ops dom0 kernel failure with ata_piix / irq problems

[Pasi Kärkkäinen]

On Mon, Jan 26, 2009 at 11:54:47AM +0100, Gerd Hoffmann wrote:
> Jeremy Fitzhardinge wrote:
> >> __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?
> 
> Looks like caller ignores -Esomething return value somewhere ...
> 

Actually this "port frozen" thing was already resolved.. it's supposed to be
like that. 

Port names are initialized with -1 as a default, and only given real
numbers/names later in the initialization process.

That initialization never happens in ata_piix driver because
devm_request_irq() fails and initialization is skipped with pv_ops dom0
kernel.. 

-- Pasi

Re: pv_ops dom0 kernel failure with ata_piix / irq problems

[Christophe Saout]

Hi Pasi,

> ata_port_alloc: ENTER
> __ata_port_freeze: ata4294967295 port frozen
>
> I guess I have to start reading the source to figure out why the port is
> 'frozen'.. 

Just checked.  It is frozen after a bad error that put the port into a
bad state (in order to avoid corruption or any sort of mess I guess).
It is unfrozen after a successful reset.

The code initially freezes a port before probing.  That's why it doesn't
even have an id assigned (hence -1 or 4294967295 if you interpret is as
unsigned).  Haven't checked, but this message should also appear if
everything works as it should.  It starts the probing only after that
message.

So I guess we need a better lead.  Would start debugging myself, but I
don't have time...

Cheers,
	Christophe

Re: pv_ops dom0 kernel failure with ata_piix / irq problems

[Pasi Kärkkäinen]

On Sun, Jan 25, 2009 at 12:10:27AM +0100, Christophe Saout wrote:
> Hi Pasi,
> 
> > ata_port_alloc: ENTER
> > __ata_port_freeze: ata4294967295 port frozen
> >
> > I guess I have to start reading the source to figure out why the port is
> > 'frozen'.. 
> 
> Just checked.  It is frozen after a bad error that put the port into a
> bad state (in order to avoid corruption or any sort of mess I guess).
> It is unfrozen after a successful reset.
> 
> The code initially freezes a port before probing.  That's why it doesn't
> even have an id assigned (hence -1 or 4294967295 if you interpret is as
> unsigned).  Haven't checked, but this message should also appear if
> everything works as it should.  It starts the probing only after that
> message.
>

Yeah, I also just figured this out :) 
 
> So I guess we need a better lead.  Would start debugging myself, but I
> don't have time...
> 

Failing function is devm_request_irq() in ata_pci_sff_activate_host() 
at least for me with ata_piix.. 

-- Pasi