Xen devel - Dec 2008 - pv_ops dom0 kernel crashes

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

Port names ("print_id") are given in ata_host_register() function,
which
never gets called for ata_piix..

ata_host_register() is supposed to be called from
ata_pci_sff_activate_host(), but in that function some error happens in 

rc = devm_request_irq(dev, ATA_PRIMARY_IRQ(pdev), irq_handler, IRQF_SHARED,
drv_name, host);
if (rc)
	goto out;

and ports names never get assigned because that "goto out;" is
executed.

So.. Any ideas why devm_request_irq() fails? 

-- Pasi

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

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

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

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

I added prints everywhere..

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

OK.. so first this:

piix_init: pci_register_driver
piix_init_one: ENTER
piix_init_one: DEBUG1
piix_init_one: pcim_enable_device(pdev);
xen_allocate_pirq: returning irq 30 for gsi 18
xen_set_ioapic_routing: irq 30 gsi 18 vector 160 ioapic 0 pin 18 triggering 0
polarity 1
ata_piix 0000:00:1f.1: PCI INT A -> GSI 18 (level, low) -> IRQ 30
xen: PCI device 0000:00:1f.1 pin 1 -> irq 30

And then later:

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

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

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

-- Pasi

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

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

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

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

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

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


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

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

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

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);
 }



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

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);
 }



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

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

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

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





      

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

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

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

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

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

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

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

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

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

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



      

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

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

  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



      

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

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

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

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


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

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

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

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

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

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
> 
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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



      

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

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

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

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

  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



      

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

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



      

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

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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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

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