Xen devel - Apr 2009 - NX related build failure in latest pv_ops dom0 hackery tree

Hello!

Latest tree (as of today) doesn''t seem to build for me:

  CC      arch/x86/xen/enlighten.o
arch/x86/xen/enlighten.c: In function ''xen_start_kernel'':
arch/x86/xen/enlighten.c:1009: error: implicit declaration of function
''set_nx''
make[1]: *** [arch/x86/xen/enlighten.o] Error 1
make: *** [arch/x86/xen] Error 2

Known problem? 

-- Pasi

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

Pasi Kärkkäinen wrote:
> Hello!
>
> Latest tree (as of today) doesn''t seem to build for me:
>
>   CC      arch/x86/xen/enlighten.o
> arch/x86/xen/enlighten.c: In function ''xen_start_kernel'':
> arch/x86/xen/enlighten.c:1009: error: implicit declaration of function
''set_nx''
> make[1]: *** [arch/x86/xen/enlighten.o] Error 1
> make: *** [arch/x86/xen] Error 2
>
> Known problem? 
>   
Yes, sorry.   I haven''t been updating hackery much lately during the 
merge window.  When we see what actually got merged next week, I''ll be 
rebuilding the xen.git branch structure into something a bit cleaner to 
go on with.  I think push2/xen/dom0/master is in a workable state.

    J

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

Hi Pasi,
> > Latest tree (as of today) doesn''t seem to build for me:
> > [...]
> >
> > Known problem? 
>
> [written by Jeremy Fitzhardine:]
> 
> Yes, sorry.   I haven''t been updating hackery much lately during
the
> merge window.  When we see what actually got merged next week,
I''ll be
> rebuilding the xen.git branch structure into something a bit cleaner to 
> go on with.  I think push2/xen/dom0/master is in a workable state.
In the meantime, you can try to use that tree:

http://git.saout.de/gitweb/?p=linux-dom0-pvops.git;a=summary

It''s the latest tip.git merged with one of the push branches from
Jeremy''s git repo and cherry-picked commits from the backend, blkback
and netback trees plus minor merge conflict and compile problem fixups.
It seems feature-complete to me, stable and is able to run DomU domains
without problems.

	Christophe



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

What branch to check out ?

Boris

--- On Sun, 4/12/09, Christophe Saout <christophe@saout.de> wrote:
From: Christophe Saout <christophe@saout.de>
Subject: Re: [Xen-devel] Re: NX related build failure in latest pv_ops dom0
hackery tree
To: "Jeremy Fitzhardinge" <jeremy@goop.org>
Cc: xen-devel@lists.xensource.com
Date: Sunday, April 12, 2009, 12:55 PM

Hi Pasi,
> > Latest tree (as of today) doesn''t seem to build for me:
> > [...]
> >
> > Known problem? 
>
> [written by Jeremy Fitzhardine:]
> 
> Yes, sorry.   I haven''t been updating hackery much lately during
the
> merge window.  When we see what actually got merged next week,
I''ll be
> rebuilding the xen.git branch structure into something a bit cleaner to 
> go on with.  I think push2/xen/dom0/master is in a workable state.
In the meantime, you can try to use that tree:

http://git.saout.de/gitweb/?p=linux-dom0-pvops.git;a=summary

It''s the latest tip.git merged with one of the push branches from
Jeremy''s git repo and cherry-picked commits from the backend, blkback
and netback trees plus minor merge conflict and compile problem fixups.
It seems feature-complete to me, stable and is able to run DomU domains
without problems.

	Christophe



_______________________________________________
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

Understood.

--- On Sun, 4/12/09, Boris Derzhavets <bderzhavets@yahoo.com> wrote:
From: Boris Derzhavets <bderzhavets@yahoo.com>
Subject: Re: [Xen-devel] Re: NX related build failure in latest pv_ops dom0
hackery tree
To: "Jeremy Fitzhardinge" <jeremy@goop.org>, "Christophe
Saout" <christophe@saout.de>
Cc: xen-devel@lists.xensource.com
Date: Sunday, April 12, 2009, 2:57 PM

What branch to check out ?

Boris

--- On Sun, 4/12/09, Christophe Saout <christophe@saout.de> wrote:
From: Christophe Saout <christophe@saout.de>
Subject: Re: [Xen-devel] Re: NX related build failure in latest pv_ops dom0
hackery tree
To: "Jeremy Fitzhardinge" <jeremy@goop.org>
Cc: xen-devel@lists.xensource.com
Date: Sunday, April 12, 2009, 12:55 PM

Hi Pasi,
> > Latest tree (as of today) doesn''t seem to build for me:
> > [...]
> >
> > Known problem? 
>
> [written by Jeremy Fitzhardine:]
> 
> Yes, sorry.   I haven''t been updating hackery much lately during
the
> merge window.  When we see what actually got merged next week,
 I''ll be
> rebuilding the xen.git branch structure into something a bit cleaner to 
> go on with.  I think push2/xen/dom0/master is in a workable state.
In the meantime, you can try to use that tree:

http://git.saout.de/gitweb/?p=linux-dom0-pvops.git;a=summary

It''s the latest tip.git merged with one of the push branches from
Jeremy''s git repo and cherry-picked commits from the backend, blkback
and netback trees plus minor merge conflict and compile problem fixups.
It seems feature-complete to me, stable and is able to run DomU domains
without problems.

	Christophe



_______________________________________________
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

Hi Boris,
> Understood.
> 
> --- On Sun, 4/12/09, Boris Derzhavets <bderzhavets@yahoo.com> wrote:
> 
>         What branch to check out ?
Yes, there is only the one. :-)

There is something weird with netback.  The last time as I was using
netback from the hackery tree (around 2.6.29-rc8), I got extremely poor
network performance (like 2MB/sec), now I''m getting about 60-100
MB/sec,
which is a lot better.  These numbers are obtained from just running
ttcp between the dom0 and a domU (the domU I tried was both with an only
non-pv 2.6.18 and a recent 2.6.29 pv domU kernel).  It still only uses a
very small amount of CPU and I didn''t see any changes mentioning
performance issues.

	Christophe



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

On Sun, Apr 12, 2009 at 06:55:58PM +0200, Christophe Saout
wrote:
> Hi Pasi,
> 
> > > Latest tree (as of today) doesn''t seem to build for me:
> > > [...]
> > >
> > > Known problem? 
> >
> > [written by Jeremy Fitzhardine:]
> > 
> > Yes, sorry.   I haven''t been updating hackery much lately
during the
> > merge window.  When we see what actually got merged next week,
I''ll be
> > rebuilding the xen.git branch structure into something a bit cleaner
to
> > go on with.  I think push2/xen/dom0/master is in a workable state.
> 
> In the meantime, you can try to use that tree:
> 
> http://git.saout.de/gitweb/?p=linux-dom0-pvops.git;a=summary
> 
> It''s the latest tip.git merged with one of the push branches from
> Jeremy''s git repo and cherry-picked commits from the backend,
blkback
> and netback trees plus minor merge conflict and compile problem fixups.
> It seems feature-complete to me, stable and is able to run DomU domains
> without problems.
> 
Nice! I''ll give it a try when I get back home from my easter trip :) 

Thanks!

-- Pasi

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

Kernel been built appears to be 2.6.30-rc1-tip.
Works fine so far ( under the Xen 3.4-rc2-pre ).
I haven''t tested network troughput between Dom0 and DomUs
 
Boris.

--- On Mon, 4/13/09, Pasi Kärkkäinen <pasik@iki.fi> wrote:

From: Pasi Kärkkäinen <pasik@iki.fi>
Subject: Re: [Xen-devel] Re: NX related build failure in latest pv_ops dom0
hackery tree
To: "Christophe Saout" <christophe@saout.de>
Cc: "Jeremy Fitzhardinge" <jeremy@goop.org>,
xen-devel@lists.xensource.com
Date: Monday, April 13, 2009, 6:18 AM

On Sun, Apr 12, 2009 at 06:55:58PM +0200, Christophe Saout
wrote:
> Hi Pasi,
> 
> > > Latest tree (as of today) doesn''t seem to build for me:
> > > [...]
> > >
> > > Known problem? 
> >
> > [written by Jeremy Fitzhardine:]
> > 
> > Yes, sorry.   I haven''t been updating hackery much lately
during
the 
> > merge window.  When we see what actually got merged next week,
I''ll be 
> > rebuilding the xen.git branch structure into something a bit cleaner
to 
> > go on with.  I think push2/xen/dom0/master is in a workable state.
> 
> In the meantime, you can try to use that tree:
> 
> http://git.saout.de/gitweb/?p=linux-dom0-pvops.git;a=summary
> 
> It''s the latest tip.git merged with one of the push branches from
> Jeremy''s git repo and cherry-picked commits from the backend,
blkback
> and netback trees plus minor merge conflict and compile problem fixups.
> It seems feature-complete to me, stable and is able to run DomU domains
> without problems.
> 
Nice! I''ll give it a try when I get back home from my easter trip :) 

Thanks!

-- 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 Mon, Apr 13, 2009 at 11:18 AM, Pasi Kärkkäinen <pasik@iki.fi>
wrote:
> On Sun, Apr 12, 2009 at 06:55:58PM +0200, Christophe Saout wrote:
>> Hi Pasi,
>>
>> > > Latest tree (as of today) doesn''t seem to build for
me:
>> > > [...]
>> > >
>> > > Known problem?
>> >
>> > [written by Jeremy Fitzhardine:]
>> >
>> > Yes, sorry.   I haven''t been updating hackery much lately
during the
>> > merge window.  When we see what actually got merged next week,
I''ll be
>> > rebuilding the xen.git branch structure into something a bit
cleaner to
>> > go on with.  I think push2/xen/dom0/master is in a workable state.
>>
>> In the meantime, you can try to use that tree:
>>
>> http://git.saout.de/gitweb/?p=linux-dom0-pvops.git;a=summary
>>
>> It''s the latest tip.git merged with one of the push branches
from
>> Jeremy''s git repo and cherry-picked commits from the backend,
blkback
>> and netback trees plus minor merge conflict and compile problem fixups.
>> It seems feature-complete to me, stable and is able to run DomU domains
>> without problems.

Can it run hvm domU?
>>
>
> Nice! I''ll give it a try when I get back home from my easter trip
:)
>
> Thanks!
>
> -- 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

No.

--- On Mon, 4/13/09, Andrew Lyon <andrew.lyon@gmail.com> wrote:
From: Andrew Lyon <andrew.lyon@gmail.com>
Subject: Re: [Xen-devel] Re: NX related build failure in latest pv_ops dom0 
hackery tree
To: "Pasi Kärkkäinen" <pasik@iki.fi>
Cc: "Jeremy Fitzhardinge" <jeremy@goop.org>,
xen-devel@lists.xensource.com, "Christophe Saout"
<christophe@saout.de>
Date: Monday, April 13, 2009, 9:28 AM

On Mon, Apr 13, 2009 at 11:18 AM, Pasi Kärkkäinen <pasik@iki.fi>
wrote:
> On Sun, Apr 12, 2009 at 06:55:58PM +0200, Christophe Saout wrote:
>> Hi Pasi,
>>
>> > > Latest tree (as of today) doesn''t seem to build for
me:
>> > > [...]
>> > >
>> > > Known problem?
>> >
>> > [written by Jeremy Fitzhardine:]
>> >
>> > Yes, sorry.   I haven''t been updating hackery much lately
during the
>> > merge window.  When we see what actually got merged next week,
I''ll be
>> > rebuilding the xen.git branch structure into something a bit
cleaner to
>> > go on with.  I think push2/xen/dom0/master is in a workable
state.
>>
>> In the meantime, you can try to use that tree:
>>
>> http://git.saout.de/gitweb/?p=linux-dom0-pvops.git;a=summary
>>
>> It''s the latest tip.git merged with one of the push branches
from
>> Jeremy''s git repo and cherry-picked commits from the backend,
blkback
>> and netback trees plus minor merge conflict and compile problem
fixups.
>> It seems feature-complete to me, stable and is able to run DomU
domains
>> without problems.

Can it run hvm domU?
>>
>
> Nice! I''ll give it a try when I get back home from my easter trip
:)
>
> Thanks!
>
> -- 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



      

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

Christophe Saout wrote:
> Hi Pasi,
>
>   
>>> Latest tree (as of today) doesn''t seem to build for me:
>>> [...]
>>>
>>> Known problem? 
>>>       
>> [written by Jeremy Fitzhardine:]
>>
>> Yes, sorry.   I haven''t been updating hackery much lately
during the
>> merge window.  When we see what actually got merged next week,
I''ll be
>> rebuilding the xen.git branch structure into something a bit cleaner to
>> go on with.  I think push2/xen/dom0/master is in a workable state.
>>     
>
> In the meantime, you can try to use that tree:
>
> http://git.saout.de/gitweb/?p=linux-dom0-pvops.git;a=summary
>
> It''s the latest tip.git merged with one of the push branches from
> Jeremy''s git repo and cherry-picked commits from the backend,
blkback
> and netback trees plus minor merge conflict and compile problem fixups.
> It seems feature-complete to me, stable and is able to run DomU domains
> without problems.
Thanks Chris.  I should have a tidied set of branches ready later today, 
along with a great pruning.

    J


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

Christophe Saout wrote:
> In the meantime, you can try to use that tree:
>
> http://git.saout.de/gitweb/?p=linux-dom0-pvops.git;a=summary
>
> It''s the latest tip.git merged with one of the push branches from
> Jeremy''s git repo and cherry-picked commits from the backend,
blkback
> and netback trees plus minor merge conflict and compile problem fixups.
> It seems feature-complete to me, stable and is able to run DomU domains
> without problems.
>   
Does it work with AHCI drives for you?  It isn''t for me (nor my
remerge,
so I''m not sure what has broken in the meantime...).

    J

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

> Christophe Saout wrote:
>>
>> In the meantime, you can try to use that tree:
>>
>> http://git.saout.de/gitweb/?p=linux-dom0-pvops.git;a=summary
>>
>> It''s the latest tip.git merged with one of the push branches
from
>> Jeremy''s git repo and cherry-picked commits from the backend,
blkback
>> and netback trees plus minor merge conflict and compile problem fixups.
>> It seems feature-complete to me, stable and is able to run DomU domains
>> without problems.
>>
>
> Does it work with AHCI drives for you?  It isn''t for me (nor my
remerge, so
> I''m not sure what has broken in the meantime...).
For what its worth, this kernel "works" for me but I had to fix some
build errors and is extremely unstable - my Thinkpad T61 reboots after
a couple minutes.

Also in my logs, in the middle of bootup I see this:

------------[ cut here ]------------
WARNING: at kernel/smp.c:369 smp_call_function_many+0xc9/0x270()
Hardware name: 6465CTO
Modules linked in: i2c_i801(+) ehci_hcd(+) snd_pcsp iTCO_wdt
iTCO_vendor_support usbcore
snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss
snd_mixer_oss e1000e r
Pid: 1337, comm: modprobe Not tainted 2.6.30-rc1-tip-g17a8dea #4
Call Trace:
 [<ffffffff8024f57a>] ? warn_slowpath+0xea/0x160
 [<ffffffff8020f1ef>] ? xen_restore_fl_direct_end+0x0/0x1
 [<ffffffff8025aaaa>] ? try_to_del_timer_sync+0x5a/0x70
 [<ffffffff8020e8b9>] ? xen_force_evtchn_callback+0x9/0x10
 [<ffffffff8020f202>] ? check_events+0x12/0x20
 [<ffffffff8023e1d0>] ? do_flush_tlb_all+0x0/0x70
 [<ffffffff8020f1ef>] ? xen_restore_fl_direct_end+0x0/0x1
 [<ffffffff80468bd9>] ? acpi_ec_transaction+0x49c/0x4c9
 [<ffffffff80267a20>] ? autoremove_wake_function+0x0/0x30
 [<ffffffff8020e8b9>] ? xen_force_evtchn_callback+0x9/0x10
 [<ffffffff8020bca9>] ? __raw_callee_save_xen_pmd_val+0x11/0x1e
 [<ffffffff8023e1d0>] ? do_flush_tlb_all+0x0/0x70
 [<ffffffff8027b929>] ? smp_call_function_many+0xc9/0x270
 [<ffffffff8023e1d0>] ? do_flush_tlb_all+0x0/0x70
 [<ffffffff8023e1d0>] ? do_flush_tlb_all+0x0/0x70
 [<ffffffff8027bb00>] ? smp_call_function+0x30/0x70
 [<ffffffff8025523d>] ? on_each_cpu+0x2d/0x90
 [<ffffffff802dae95>] ? __purge_vmap_area_lazy+0x175/0x1f0
 [<ffffffff802dcab6>] ? vm_unmap_aliases+0x1c6/0x1e0
 [<ffffffff8020d4e8>] ? xen_create_contiguous_region+0x68/0x120
 [<ffffffff80448738>] ? xen_alloc_coherent+0x88/0x130
 [<ffffffff802e1dcf>] ? dma_pool_alloc+0x29f/0x340
 [<ffffffffa00a900a>] ? hub_probe+0xfa/0x960 [usbcore]
 [<ffffffff8020f1ef>] ? xen_restore_fl_direct_end+0x0/0x1
 [<ffffffff802e6dcd>] ? kmem_cache_alloc+0x8d/0x160
 [<ffffffffa00a9199>] ? hub_probe+0x289/0x960 [usbcore]
 [<ffffffff8020f1ef>] ? xen_restore_fl_direct_end+0x0/0x1
 [<ffffffff806d22e4>] ? __mutex_unlock_slowpath+0xc4/0x180
 [<ffffffffa00b1a59>] ? usb_probe_interface+0xc9/0x1a0 [usbcore]
 [<ffffffff80506588>] ? driver_probe_device+0x98/0x1b0
 [<ffffffff80506740>] ? __device_attach+0x0/0x60
 [<ffffffff805059eb>] ? bus_for_each_drv+0x5b/0x80
 [<ffffffff8020f1ef>] ? xen_restore_fl_direct_end+0x0/0x1
 [<ffffffff80506865>] ? device_attach+0x85/0x90
 [<ffffffff805057d5>] ? bus_attach_device+0x55/0xa0
 [<ffffffff80503fb5>] ? device_add+0x435/0x640
 [<ffffffffa00b0015>] ? usb_set_configuration+0x595/0x7a0 [usbcore]
 [<ffffffffa00b0058>] ? usb_set_configuration+0x5d8/0x7a0 [usbcore]
 [<ffffffff8034d9ad>] ? sysfs_add_one+0x2d/0x170
 [<ffffffffa00b9b3a>] ? generic_probe+0x3a/0xc0 [usbcore]
 [<ffffffff80506588>] ? driver_probe_device+0x98/0x1b0
 [<ffffffff80506740>] ? __device_attach+0x0/0x60
 [<ffffffff805059eb>] ? bus_for_each_drv+0x5b/0x80
 [<ffffffff8020f1ef>] ? xen_restore_fl_direct_end+0x0/0x1
 [<ffffffff80506865>] ? device_attach+0x85/0x90
 [<ffffffff805057d5>] ? bus_attach_device+0x55/0xa0
 [<ffffffff80503fb5>] ? device_add+0x435/0x640
 [<ffffffffa00a8b32>] ? usb_new_device+0x72/0xf0 [usbcore]
 [<ffffffffa00ac3c8>] ? usb_add_hcd+0x418/0x630 [usbcore]
 [<ffffffffa00ba135>] ? usb_hcd_pci_probe+0x175/0x2f0 [usbcore]
 [<ffffffff8043f7f2>] ? local_pci_probe+0x12/0x20
 [<ffffffff80440969>] ? pci_device_probe+0x89/0xb0
 [<ffffffff80506588>] ? driver_probe_device+0x98/0x1b0
 [<ffffffff8050673b>] ? __driver_attach+0x9b/0xa0
 [<ffffffff805066a0>] ? __driver_attach+0x0/0xa0
 [<ffffffff80505d3b>] ? bus_for_each_dev+0x5b/0x80
 [<ffffffff8050559d>] ? bus_add_driver+0x1cd/0x2e0
 [<ffffffffa00ed000>] ? ehci_hcd_init+0x0/0x81 [ehci_hcd]
 [<ffffffff805069f9>] ? driver_register+0x79/0x170
 [<ffffffffa00ed000>] ? ehci_hcd_init+0x0/0x81 [ehci_hcd]
 [<ffffffff80440e48>] ? __pci_register_driver+0x58/0xe0
 [<ffffffffa00ed000>] ? ehci_hcd_init+0x0/0x81 [ehci_hcd]
 [<ffffffffa00ed071>] ? ehci_hcd_init+0x71/0x81 [ehci_hcd]
 [<ffffffff8020a04b>] ? do_one_initcall+0x3b/0x180
 [<ffffffff8020f1ef>] ? xen_restore_fl_direct_end+0x0/0x1
 [<ffffffff806d4326>] ? _spin_unlock_irqrestore+0x26/0x80
 [<ffffffff8026c6b5>] ? __blocking_notifier_call_chain+0x65/0x90
 [<ffffffff80280255>] ? sys_init_module+0xb5/0x200
 [<ffffffff80213082>] ? system_call_fastpath+0x16/0x1b
---[ end trace 5cfe942adf5cb18f ]---
------------[ cut here ]------------
WARNING: at kernel/smp.c:289 smp_call_function_single+0x117/0x1b0()
Hardware name: 6465CTO
Modules linked in: i2c_i801(+) ehci_hcd(+) snd_pcsp iTCO_wdt
iTCO_vendor_support usbcore
snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss
snd_mixer_oss e1000e r
Pid: 1337, comm: modprobe Tainted: G        W  2.6.30-rc1-tip-g17a8dea #4
Call Trace:
 [<ffffffff8024f57a>] ? warn_slowpath+0xea/0x160
 [<ffffffff8020f1ef>] ? xen_restore_fl_direct_end+0x0/0x1
 [<ffffffff8025aaaa>] ? try_to_del_timer_sync+0x5a/0x70
 [<ffffffff8020e8b9>] ? xen_force_evtchn_callback+0x9/0x10
 [<ffffffff8020f202>] ? check_events+0x12/0x20
 [<ffffffff8020f1ef>] ? xen_restore_fl_direct_end+0x0/0x1
 [<ffffffff80468bd9>] ? acpi_ec_transaction+0x49c/0x4c9
 [<ffffffff80267a20>] ? autoremove_wake_function+0x0/0x30
 [<ffffffff8020e8b9>] ? xen_force_evtchn_callback+0x9/0x10
 [<ffffffff8020bca9>] ? __raw_callee_save_xen_pmd_val+0x11/0x1e
 [<ffffffff8023e1d0>] ? do_flush_tlb_all+0x0/0x70
 [<ffffffff8027b7c7>] ? smp_call_function_single+0x117/0x1b0
 [<ffffffff8023e1d0>] ? do_flush_tlb_all+0x0/0x70
 [<ffffffff8027bb00>] ? smp_call_function+0x30/0x70
 [<ffffffff8025523d>] ? on_each_cpu+0x2d/0x90
 [<ffffffff802dae95>] ? __purge_vmap_area_lazy+0x175/0x1f0
 [<ffffffff802dcab6>] ? vm_unmap_aliases+0x1c6/0x1e0
 [<ffffffff8020d4e8>] ? xen_create_contiguous_region+0x68/0x120
 [<ffffffff80448738>] ? xen_alloc_coherent+0x88/0x130
 [<ffffffff802e1dcf>] ? dma_pool_alloc+0x29f/0x340
 [<ffffffffa00a900a>] ? hub_probe+0xfa/0x960 [usbcore]
 [<ffffffff8020f1ef>] ? xen_restore_fl_direct_end+0x0/0x1
 [<ffffffff802e6dcd>] ? kmem_cache_alloc+0x8d/0x160
 [<ffffffffa00a9199>] ? hub_probe+0x289/0x960 [usbcore]
 [<ffffffff8020f1ef>] ? xen_restore_fl_direct_end+0x0/0x1
 [<ffffffff806d22e4>] ? __mutex_unlock_slowpath+0xc4/0x180
 [<ffffffffa00b1a59>] ? usb_probe_interface+0xc9/0x1a0 [usbcore]
 [<ffffffff80506588>] ? driver_probe_device+0x98/0x1b0
 [<ffffffff80506740>] ? __device_attach+0x0/0x60
 [<ffffffff805059eb>] ? bus_for_each_drv+0x5b/0x80
 [<ffffffff8020f1ef>] ? xen_restore_fl_direct_end+0x0/0x1
 [<ffffffff80506865>] ? device_attach+0x85/0x90
 [<ffffffff805057d5>] ? bus_attach_device+0x55/0xa0
 [<ffffffff80503fb5>] ? device_add+0x435/0x640
 [<ffffffffa00b0015>] ? usb_set_configuration+0x595/0x7a0 [usbcore]
 [<ffffffffa00b0058>] ? usb_set_configuration+0x5d8/0x7a0 [usbcore]
 [<ffffffff8034d9ad>] ? sysfs_add_one+0x2d/0x170
 [<ffffffffa00b9b3a>] ? generic_probe+0x3a/0xc0 [usbcore]
 [<ffffffff80506588>] ? driver_probe_device+0x98/0x1b0
 [<ffffffff80506740>] ? __device_attach+0x0/0x60
 [<ffffffff805059eb>] ? bus_for_each_drv+0x5b/0x80
 [<ffffffff8020f1ef>] ? xen_restore_fl_direct_end+0x0/0x1
 [<ffffffff80506865>] ? device_attach+0x85/0x90
 [<ffffffff805057d5>] ? bus_attach_device+0x55/0xa0
 [<ffffffff80503fb5>] ? device_add+0x435/0x640
 [<ffffffffa00a8b32>] ? usb_new_device+0x72/0xf0 [usbcore]
 [<ffffffffa00ac3c8>] ? usb_add_hcd+0x418/0x630 [usbcore]
 [<ffffffffa00ba135>] ? usb_hcd_pci_probe+0x175/0x2f0 [usbcore]
 [<ffffffff8043f7f2>] ? local_pci_probe+0x12/0x20
 [<ffffffff80440969>] ? pci_device_probe+0x89/0xb0
 [<ffffffff80506588>] ? driver_probe_device+0x98/0x1b0
 [<ffffffff8050673b>] ? __driver_attach+0x9b/0xa0
 [<ffffffff805066a0>] ? __driver_attach+0x0/0xa0
 [<ffffffff80505d3b>] ? bus_for_each_dev+0x5b/0x80
 [<ffffffff8050559d>] ? bus_add_driver+0x1cd/0x2e0
 [<ffffffffa00ed000>] ? ehci_hcd_init+0x0/0x81 [ehci_hcd]
 [<ffffffff805069f9>] ? driver_register+0x79/0x170
 [<ffffffffa00ed000>] ? ehci_hcd_init+0x0/0x81 [ehci_hcd]
 [<ffffffff80440e48>] ? __pci_register_driver+0x58/0xe0
 [<ffffffffa00ed000>] ? ehci_hcd_init+0x0/0x81 [ehci_hcd]
 [<ffffffffa00ed071>] ? ehci_hcd_init+0x71/0x81 [ehci_hcd]
 [<ffffffff8020a04b>] ? do_one_initcall+0x3b/0x180
 [<ffffffff8020f1ef>] ? xen_restore_fl_direct_end+0x0/0x1
 [<ffffffff806d4326>] ? _spin_unlock_irqrestore+0x26/0x80
 [<ffffffff8026c6b5>] ? __blocking_notifier_call_chain+0x65/0x90
 [<ffffffff80280255>] ? sys_init_module+0xb5/0x200
 [<ffffffff80213082>] ? system_call_fastpath+0x16/0x1b
---[ end trace 5cfe942adf5cb190 ]---

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

Please,view dmesg.system and xm dmesg reports for AHCI box.
Kernel has been built via :-
git://git.saout.de/gitweb/linux-dom0-pvops.git
First report contains one stack trace ( exactly as it happened with 2.6.29-tip
on Q9550 ) . I will check it on C2D AHCI box shortly. 

Boris.

--- On Tue, 4/14/09, Jeremy Fitzhardinge <jeremy@goop.org> wrote:
From: Jeremy Fitzhardinge <jeremy@goop.org>
Subject: Re: [Xen-devel] Re: NX related build failure in latest pv_ops dom0
hackery tree
To: "Christophe Saout" <christophe@saout.de>
Cc: xen-devel@lists.xensource.com
Date: Tuesday, April 14, 2009, 12:53 PM

Christophe Saout wrote:
> In the meantime, you can try to use that tree:
>
> http://git.saout.de/gitweb/?p=linux-dom0-pvops.git;a=summary
>
> It''s the latest tip.git merged with one of the push branches from
> Jeremy''s git repo and cherry-picked commits from the backend,
blkback
> and netback trees plus minor merge conflict and compile problem fixups.
> It seems feature-complete to me, stable and is able to run DomU domains
> without problems.
>   
Does it work with AHCI drives for you?  It isn''t for me (nor my
remerge,
so I''m not sure what has broken in the meantime...).

    J

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
d with 2.6.29-tip
on Q9550 ) .

Boris.

--- On Tue, 4/14/09, Jeremy Fitzhardinge <jeremy@goop.org> wrote:
From: Jeremy Fitzhardinge <jeremy@goop.org>
Subject: Re: [Xen-devel] Re: NX related build failure in latest pv_ops dom0
hackery tree
To: "Christophe Saout" <christophe@saout.de>
Cc: xen-devel@lists.xensource.com
Date: Tuesday, April 14, 2009, 12:53 PM

Christophe Saout wrote:
> In the meantime, you can try to use that tree:
>
> http://git.saout.de/gitweb/?p=linux-dom0-pvops.git;a=summary
>
> It''s the latest tip.git merged with one of the push branches from
> Jeremy''s git repo and cherry-picked commits from the backend,
blkback
> and netback trees plus minor merge conflict and compile problem fixups.
> It seems feature-complete to me, stable and is able to run DomU domains
> without problems.
>   
Does it work with AHCI drives for you?  It isn''t for me (nor my
remerge,
so I''m not sure what has broken in the meantime...).

    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

Yes , same two stack traces on C2D E8400 AHCI box.
I believe it happened to me about 2 months ago.
That time patches were suggested by you pretty fast.
Kernel 2.6.30-rc1-tip behaves stable on both AHCI boxes (8 GB RAM)
I''ve just built CentOS 5.3 PV DomU on Q9550 box with no trouble
get dmesg reports and send first message to you. I also reinstalled
Xen Unstable 3.4-rc2-pre from scratch, trying to get stubdom working.
All mentioned stuff has been performed via remote VNC session , which took about
2.5 -3  hr with no interruptions.
Boris



--- On Tue, 4/14/09, Jeremy Fitzhardinge <jeremy@goop.org> wrote:
From: Jeremy Fitzhardinge <jeremy@goop.org>
Subject: Re: [Xen-devel] Re: NX related build failure in latest pv_ops dom0
hackery tree
To: "Christophe Saout" <christophe@saout.de>
Cc: xen-devel@lists.xensource.com
Date: Tuesday, April 14, 2009, 12:53 PM

Christophe Saout wrote:
> In the meantime, you can try to use that tree:
>
> http://git.saout.de/gitweb/?p=linux-dom0-pvops.git;a=summary
>
> It''s the latest tip.git merged with one of the push branches from
> Jeremy''s git repo and cherry-picked commits from the backend,
blkback
> and netback trees plus minor merge conflict and compile problem fixups.
> It seems feature-complete to me, stable and is able to run DomU domains
> without problems.
>   
Does it work with AHCI drives for you?  It isn''t for me (nor my
remerge,
so I''m not sure what has broken in the meantime...).

    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

Thomas DuBuisson wrote:
> For what its worth, this kernel "works" for me but I had to fix
some
> build errors and is extremely unstable - my Thinkpad T61 reboots after
> a couple minutes.
>   
Do you have any symptoms, or does it just spontaneously reboot?
> Also in my logs, in the middle of bootup I see this:
>   
OK, I have some fixes for those.

    J
> ------------[ cut here ]------------
> WARNING: at kernel/smp.c:369 smp_call_function_many+0xc9/0x270()
> Hardware name: 6465CTO
> Modules linked in: i2c_i801(+) ehci_hcd(+) snd_pcsp iTCO_wdt
> iTCO_vendor_support usbcore
> snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss
> snd_mixer_oss e1000e r
> Pid: 1337, comm: modprobe Not tainted 2.6.30-rc1-tip-g17a8dea #4
> Call Trace:
>  [<ffffffff8024f57a>] ? warn_slowpath+0xea/0x160
>  [<ffffffff8020f1ef>] ? xen_restore_fl_direct_end+0x0/0x1
>  [<ffffffff8025aaaa>] ? try_to_del_timer_sync+0x5a/0x70
>  [<ffffffff8020e8b9>] ? xen_force_evtchn_callback+0x9/0x10
>  [<ffffffff8020f202>] ? check_events+0x12/0x20
>  [<ffffffff8023e1d0>] ? do_flush_tlb_all+0x0/0x70
>  [<ffffffff8020f1ef>] ? xen_restore_fl_direct_end+0x0/0x1
>  [<ffffffff80468bd9>] ? acpi_ec_transaction+0x49c/0x4c9
>  [<ffffffff80267a20>] ? autoremove_wake_function+0x0/0x30
>  [<ffffffff8020e8b9>] ? xen_force_evtchn_callback+0x9/0x10
>  [<ffffffff8020bca9>] ? __raw_callee_save_xen_pmd_val+0x11/0x1e
>  [<ffffffff8023e1d0>] ? do_flush_tlb_all+0x0/0x70
>  [<ffffffff8027b929>] ? smp_call_function_many+0xc9/0x270
>  [<ffffffff8023e1d0>] ? do_flush_tlb_all+0x0/0x70
>  [<ffffffff8023e1d0>] ? do_flush_tlb_all+0x0/0x70
>  [<ffffffff8027bb00>] ? smp_call_function+0x30/0x70
>  [<ffffffff8025523d>] ? on_each_cpu+0x2d/0x90
>  [<ffffffff802dae95>] ? __purge_vmap_area_lazy+0x175/0x1f0
>  [<ffffffff802dcab6>] ? vm_unmap_aliases+0x1c6/0x1e0
>  [<ffffffff8020d4e8>] ? xen_create_contiguous_region+0x68/0x120
>  [<ffffffff80448738>] ? xen_alloc_coherent+0x88/0x130
>  [<ffffffff802e1dcf>] ? dma_pool_alloc+0x29f/0x340
>  [<ffffffffa00a900a>] ? hub_probe+0xfa/0x960 [usbcore]
>  [<ffffffff8020f1ef>] ? xen_restore_fl_direct_end+0x0/0x1
>  [<ffffffff802e6dcd>] ? kmem_cache_alloc+0x8d/0x160
>  [<ffffffffa00a9199>] ? hub_probe+0x289/0x960 [usbcore]
>  [<ffffffff8020f1ef>] ? xen_restore_fl_direct_end+0x0/0x1
>  [<ffffffff806d22e4>] ? __mutex_unlock_slowpath+0xc4/0x180
>  [<ffffffffa00b1a59>] ? usb_probe_interface+0xc9/0x1a0 [usbcore]
>  [<ffffffff80506588>] ? driver_probe_device+0x98/0x1b0
>  [<ffffffff80506740>] ? __device_attach+0x0/0x60
>  [<ffffffff805059eb>] ? bus_for_each_drv+0x5b/0x80
>  [<ffffffff8020f1ef>] ? xen_restore_fl_direct_end+0x0/0x1
>  [<ffffffff80506865>] ? device_attach+0x85/0x90
>  [<ffffffff805057d5>] ? bus_attach_device+0x55/0xa0
>  [<ffffffff80503fb5>] ? device_add+0x435/0x640
>  [<ffffffffa00b0015>] ? usb_set_configuration+0x595/0x7a0 [usbcore]
>  [<ffffffffa00b0058>] ? usb_set_configuration+0x5d8/0x7a0 [usbcore]
>  [<ffffffff8034d9ad>] ? sysfs_add_one+0x2d/0x170
>  [<ffffffffa00b9b3a>] ? generic_probe+0x3a/0xc0 [usbcore]
>  [<ffffffff80506588>] ? driver_probe_device+0x98/0x1b0
>  [<ffffffff80506740>] ? __device_attach+0x0/0x60
>  [<ffffffff805059eb>] ? bus_for_each_drv+0x5b/0x80
>  [<ffffffff8020f1ef>] ? xen_restore_fl_direct_end+0x0/0x1
>  [<ffffffff80506865>] ? device_attach+0x85/0x90
>  [<ffffffff805057d5>] ? bus_attach_device+0x55/0xa0
>  [<ffffffff80503fb5>] ? device_add+0x435/0x640
>  [<ffffffffa00a8b32>] ? usb_new_device+0x72/0xf0 [usbcore]
>  [<ffffffffa00ac3c8>] ? usb_add_hcd+0x418/0x630 [usbcore]
>  [<ffffffffa00ba135>] ? usb_hcd_pci_probe+0x175/0x2f0 [usbcore]
>  [<ffffffff8043f7f2>] ? local_pci_probe+0x12/0x20
>  [<ffffffff80440969>] ? pci_device_probe+0x89/0xb0
>  [<ffffffff80506588>] ? driver_probe_device+0x98/0x1b0
>  [<ffffffff8050673b>] ? __driver_attach+0x9b/0xa0
>  [<ffffffff805066a0>] ? __driver_attach+0x0/0xa0
>  [<ffffffff80505d3b>] ? bus_for_each_dev+0x5b/0x80
>  [<ffffffff8050559d>] ? bus_add_driver+0x1cd/0x2e0
>  [<ffffffffa00ed000>] ? ehci_hcd_init+0x0/0x81 [ehci_hcd]
>  [<ffffffff805069f9>] ? driver_register+0x79/0x170
>  [<ffffffffa00ed000>] ? ehci_hcd_init+0x0/0x81 [ehci_hcd]
>  [<ffffffff80440e48>] ? __pci_register_driver+0x58/0xe0
>  [<ffffffffa00ed000>] ? ehci_hcd_init+0x0/0x81 [ehci_hcd]
>  [<ffffffffa00ed071>] ? ehci_hcd_init+0x71/0x81 [ehci_hcd]
>  [<ffffffff8020a04b>] ? do_one_initcall+0x3b/0x180
>  [<ffffffff8020f1ef>] ? xen_restore_fl_direct_end+0x0/0x1
>  [<ffffffff806d4326>] ? _spin_unlock_irqrestore+0x26/0x80
>  [<ffffffff8026c6b5>] ? __blocking_notifier_call_chain+0x65/0x90
>  [<ffffffff80280255>] ? sys_init_module+0xb5/0x200
>  [<ffffffff80213082>] ? system_call_fastpath+0x16/0x1b
> ---[ end trace 5cfe942adf5cb18f ]---
> ------------[ cut here ]------------
> WARNING: at kernel/smp.c:289 smp_call_function_single+0x117/0x1b0()
> Hardware name: 6465CTO
> Modules linked in: i2c_i801(+) ehci_hcd(+) snd_pcsp iTCO_wdt
> iTCO_vendor_support usbcore
> snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss
> snd_mixer_oss e1000e r
> Pid: 1337, comm: modprobe Tainted: G        W  2.6.30-rc1-tip-g17a8dea #4
> Call Trace:
>  [<ffffffff8024f57a>] ? warn_slowpath+0xea/0x160
>  [<ffffffff8020f1ef>] ? xen_restore_fl_direct_end+0x0/0x1
>  [<ffffffff8025aaaa>] ? try_to_del_timer_sync+0x5a/0x70
>  [<ffffffff8020e8b9>] ? xen_force_evtchn_callback+0x9/0x10
>  [<ffffffff8020f202>] ? check_events+0x12/0x20
>  [<ffffffff8020f1ef>] ? xen_restore_fl_direct_end+0x0/0x1
>  [<ffffffff80468bd9>] ? acpi_ec_transaction+0x49c/0x4c9
>  [<ffffffff80267a20>] ? autoremove_wake_function+0x0/0x30
>  [<ffffffff8020e8b9>] ? xen_force_evtchn_callback+0x9/0x10
>  [<ffffffff8020bca9>] ? __raw_callee_save_xen_pmd_val+0x11/0x1e
>  [<ffffffff8023e1d0>] ? do_flush_tlb_all+0x0/0x70
>  [<ffffffff8027b7c7>] ? smp_call_function_single+0x117/0x1b0
>  [<ffffffff8023e1d0>] ? do_flush_tlb_all+0x0/0x70
>  [<ffffffff8027bb00>] ? smp_call_function+0x30/0x70
>  [<ffffffff8025523d>] ? on_each_cpu+0x2d/0x90
>  [<ffffffff802dae95>] ? __purge_vmap_area_lazy+0x175/0x1f0
>  [<ffffffff802dcab6>] ? vm_unmap_aliases+0x1c6/0x1e0
>  [<ffffffff8020d4e8>] ? xen_create_contiguous_region+0x68/0x120
>  [<ffffffff80448738>] ? xen_alloc_coherent+0x88/0x130
>  [<ffffffff802e1dcf>] ? dma_pool_alloc+0x29f/0x340
>  [<ffffffffa00a900a>] ? hub_probe+0xfa/0x960 [usbcore]
>  [<ffffffff8020f1ef>] ? xen_restore_fl_direct_end+0x0/0x1
>  [<ffffffff802e6dcd>] ? kmem_cache_alloc+0x8d/0x160
>  [<ffffffffa00a9199>] ? hub_probe+0x289/0x960 [usbcore]
>  [<ffffffff8020f1ef>] ? xen_restore_fl_direct_end+0x0/0x1
>  [<ffffffff806d22e4>] ? __mutex_unlock_slowpath+0xc4/0x180
>  [<ffffffffa00b1a59>] ? usb_probe_interface+0xc9/0x1a0 [usbcore]
>  [<ffffffff80506588>] ? driver_probe_device+0x98/0x1b0
>  [<ffffffff80506740>] ? __device_attach+0x0/0x60
>  [<ffffffff805059eb>] ? bus_for_each_drv+0x5b/0x80
>  [<ffffffff8020f1ef>] ? xen_restore_fl_direct_end+0x0/0x1
>  [<ffffffff80506865>] ? device_attach+0x85/0x90
>  [<ffffffff805057d5>] ? bus_attach_device+0x55/0xa0
>  [<ffffffff80503fb5>] ? device_add+0x435/0x640
>  [<ffffffffa00b0015>] ? usb_set_configuration+0x595/0x7a0 [usbcore]
>  [<ffffffffa00b0058>] ? usb_set_configuration+0x5d8/0x7a0 [usbcore]
>  [<ffffffff8034d9ad>] ? sysfs_add_one+0x2d/0x170
>  [<ffffffffa00b9b3a>] ? generic_probe+0x3a/0xc0 [usbcore]
>  [<ffffffff80506588>] ? driver_probe_device+0x98/0x1b0
>  [<ffffffff80506740>] ? __device_attach+0x0/0x60
>  [<ffffffff805059eb>] ? bus_for_each_drv+0x5b/0x80
>  [<ffffffff8020f1ef>] ? xen_restore_fl_direct_end+0x0/0x1
>  [<ffffffff80506865>] ? device_attach+0x85/0x90
>  [<ffffffff805057d5>] ? bus_attach_device+0x55/0xa0
>  [<ffffffff80503fb5>] ? device_add+0x435/0x640
>  [<ffffffffa00a8b32>] ? usb_new_device+0x72/0xf0 [usbcore]
>  [<ffffffffa00ac3c8>] ? usb_add_hcd+0x418/0x630 [usbcore]
>  [<ffffffffa00ba135>] ? usb_hcd_pci_probe+0x175/0x2f0 [usbcore]
>  [<ffffffff8043f7f2>] ? local_pci_probe+0x12/0x20
>  [<ffffffff80440969>] ? pci_device_probe+0x89/0xb0
>  [<ffffffff80506588>] ? driver_probe_device+0x98/0x1b0
>  [<ffffffff8050673b>] ? __driver_attach+0x9b/0xa0
>  [<ffffffff805066a0>] ? __driver_attach+0x0/0xa0
>  [<ffffffff80505d3b>] ? bus_for_each_dev+0x5b/0x80
>  [<ffffffff8050559d>] ? bus_add_driver+0x1cd/0x2e0
>  [<ffffffffa00ed000>] ? ehci_hcd_init+0x0/0x81 [ehci_hcd]
>  [<ffffffff805069f9>] ? driver_register+0x79/0x170
>  [<ffffffffa00ed000>] ? ehci_hcd_init+0x0/0x81 [ehci_hcd]
>  [<ffffffff80440e48>] ? __pci_register_driver+0x58/0xe0
>  [<ffffffffa00ed000>] ? ehci_hcd_init+0x0/0x81 [ehci_hcd]
>  [<ffffffffa00ed071>] ? ehci_hcd_init+0x71/0x81 [ehci_hcd]
>  [<ffffffff8020a04b>] ? do_one_initcall+0x3b/0x180
>  [<ffffffff8020f1ef>] ? xen_restore_fl_direct_end+0x0/0x1
>  [<ffffffff806d4326>] ? _spin_unlock_irqrestore+0x26/0x80
>  [<ffffffff8026c6b5>] ? __blocking_notifier_call_chain+0x65/0x90
>  [<ffffffff80280255>] ? sys_init_module+0xb5/0x200
>  [<ffffffff80213082>] ? system_call_fastpath+0x16/0x1b
> ---[ end trace 5cfe942adf5cb190 ]---
>   

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

On Tue, Apr 14, 2009 at 12:58 PM, Jeremy Fitzhardinge <jeremy@goop.org>
wrote:
> Thomas DuBuisson wrote:
>>
>> For what its worth, this kernel "works" for me but I had to
fix some
>> build errors and is extremely unstable - my Thinkpad T61 reboots after
>> a couple minutes.
>>
>
> Do you have any symptoms, or does it just spontaneously reboot?
It just reboots with no other misbehavior or logs.  I''m rebuilding now
without power management and will run that when I get the chance.  If
you''re wondering, I wasn''t doing any xen-specific operations;
for
example I was just compiling misc projects in dom0 and it reboots.

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

Thomas DuBuisson wrote:
> On Tue, Apr 14, 2009 at 12:58 PM, Jeremy Fitzhardinge
<jeremy@goop.org> wrote:
>   
>> Thomas DuBuisson wrote:
>>     
>>> For what its worth, this kernel "works" for me but I had
to fix some
>>> build errors and is extremely unstable - my Thinkpad T61 reboots
after
>>> a couple minutes.
>>>
>>>       
>> Do you have any symptoms, or does it just spontaneously reboot?
>>     
>
> It just reboots with no other misbehavior or logs.  I''m rebuilding
now
> without power management and will run that when I get the chance.  If
> you''re wondering, I wasn''t doing any xen-specific
operations; for
> example I was just compiling misc projects in dom0 and it reboots.
>   
32 or 64-bit?

    J


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

Hi Jeremy,
> > http://git.saout.de/gitweb/?p=linux-dom0-pvops.git;a=summary
> >
> > It''s the latest tip.git merged with one of the push branches
from
> > Jeremy''s git repo and cherry-picked commits from the backend,
blkback
> > and netback trees plus minor merge conflict and compile problem
fixups.
> > It seems feature-complete to me, stable and is able to run DomU
domains
> > without problems.
> >   
> 
> Does it work with AHCI drives for you?  It isn''t for me (nor my
remerge,
> so I''m not sure what has broken in the meantime...).
Yes, it does.  I didn''t notice anything unusual (this is 64 bit here).
But then I only ran it for only like 15 minutes.

	Christophe



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

On Tue, Apr 14, 2009 at 01:30:51PM -0700, Thomas DuBuisson
wrote:
> On Tue, Apr 14, 2009 at 12:58 PM, Jeremy Fitzhardinge
<jeremy@goop.org> wrote:
> > Thomas DuBuisson wrote:
> >>
> >> For what its worth, this kernel "works" for me but I had
to fix some
> >> build errors and is extremely unstable - my Thinkpad T61 reboots
after
> >> a couple minutes.
> >>
> >
> > Do you have any symptoms, or does it just spontaneously reboot?
> 
> It just reboots with no other misbehavior or logs.  I''m rebuilding
now
> without power management and will run that when I get the chance.  If
> you''re wondering, I wasn''t doing any xen-specific
operations; for
> example I was just compiling misc projects in dom0 and it reboots.
> 
Do you have CONFIG_HIGHPTE=y ? It seems to be broken for me on 32 bit PAE
pv_os dom0 kernel..

CONFIG_HIGHPTE=n works for me.

-- Pasi

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

Pasi Kärkkäinen wrote:
> Do you have CONFIG_HIGHPTE=y ? It seems to be broken for me on 32 bit PAE
> pv_os dom0 kernel..
>
> CONFIG_HIGHPTE=n works for me.
>   
He''s running a 64-bit kernel, so that''s a non-issue.

    J

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

Sorry for the double Jeremy, this was ment for the list of coarse.

On Wed, Apr 15, 2009 at 9:08 AM, Jeremy Fitzhardinge <jeremy@goop.org>
wrote:
> Pasi Kärkkäinen wrote:
>>
>> Do you have CONFIG_HIGHPTE=y ? It seems to be broken for me on 32 bit
PAE
>> pv_os dom0 kernel..
>>
>> CONFIG_HIGHPTE=n works for me.
>>
>
> He''s running a 64-bit kernel, so that''s a non-issue.
Yes, I''m running 64bit; basically the same config as ARCH linux
default (plus the xen options).  Had to turn off a few modules due to
build issues and I''m using xen-3.4.0-rc2-pre.  I''m actually
running a
cleaned and rebuilt kernel from that repo right now... no issues yet.
I''ll start compiling some CPU hungry processes and see what happens
(thats what I was doing last time).

Thomas

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

>  I''m using xen-3.4.0-rc2-pre.  I''m actually running a
> cleaned and rebuilt kernel from that repo right now... no issues yet.
> I''ll start compiling some CPU hungry processes and see what
happens
> (thats what I was doing last time).
For the above-mentioned run of xen-3.4.0-rc2-pre I had noreboot -
_when_ it locked up, the X display remained but there was no response
/ no mouse etc.  I didn''t check if it was responding to network
activity.

I''ve been running with xen-3.3.2-rc1-pre for about an hour now and
haven''t had issues.  The work load is the same as when I was using
xen-3.4 so the explainations that come to mind are 1) I''m lucky 2) The
issue is xen-unstable 3) Its still a kernel issue but isn''t triggered
by xen 3.3.

Thomas

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

Hi Jeremy,
> > In the meantime, you can try to use that tree:
> >
> > http://git.saout.de/gitweb/?p=linux-dom0-pvops.git;a=summary
> >
> > It''s the latest tip.git merged with one of the push branches
from
> > Jeremy''s git repo and cherry-picked commits from the backend,
blkback
> > and netback trees plus minor merge conflict and compile problem
fixups.
> > It seems feature-complete to me, stable and is able to run DomU
domains
> > without problems.
> >   
> 
> Does it work with AHCI drives for you?  It isn''t for me (nor my
remerge,
> so I''m not sure what has broken in the meantime...).
What kind of machine is this?  I have a Thinkpad here (Intel) and it is
working.  However, I have tried booting into the same kernel on a remote
maching (unfortunately, no physical access to the machine) and the exact
same kernel that works on my notebook natively and under Xen as Dom0
does not boot the kernel under Xen on that remote machine (but runs
natively).  I can''t tell why, but I suspect it might be AHCI related,
because the machine also uses AHCI, but a different controller.  It is
an AMD machine with this controller:

00:12.0 SATA controller: ATI Technologies Inc SB600 Non-Raid-5 SATA

I could try to compile netconsole and the NIC driver into the kernel to
capture the kernel messages if that would help.

	Christophe



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

Christophe Saout wrote:
> Hi Jeremy,
>
>   
>>> In the meantime, you can try to use that tree:
>>>
>>> http://git.saout.de/gitweb/?p=linux-dom0-pvops.git;a=summary
>>>
>>> It''s the latest tip.git merged with one of the push
branches from
>>> Jeremy''s git repo and cherry-picked commits from the
backend, blkback
>>> and netback trees plus minor merge conflict and compile problem
fixups.
>>> It seems feature-complete to me, stable and is able to run DomU
domains
>>> without problems.
>>>   
>>>       
>> Does it work with AHCI drives for you?  It isn''t for me (nor
my remerge,
>> so I''m not sure what has broken in the meantime...).
>>     
>
> What kind of machine is this?  I have a Thinkpad here (Intel) and it is
> working.  However, I have tried booting into the same kernel on a remote
> maching (unfortunately, no physical access to the machine) and the exact
> same kernel that works on my notebook natively and under Xen as Dom0
> does not boot the kernel under Xen on that remote machine (but runs
> natively).  I can''t tell why, but I suspect it might be AHCI
related,
> because the machine also uses AHCI, but a different controller.  It is
> an AMD machine with this controller:
>
> 00:12.0 SATA controller: ATI Technologies Inc SB600 Non-Raid-5 SATA
>
> I could try to compile netconsole and the NIC driver into the kernel to
> capture the kernel messages if that would help.
Well, I''ve tried it on a newish Intel mobo machine with on-board ahci, 
and that fails.  Another, older, Dell machine using a scsi controller 
works fine.  I haven''t tried my laptop yet.

In theory AHCI is ACHI, so the controller vendor shouldn''t matter.   It
may have more to do with interrupt controller configuration or memory 
layout.

On your failing machine, does it work any better if you switch the 
controller to compat/legacy mode?

    J


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

Hi Jeremy,
> > I could try to compile netconsole and the NIC driver into the kernel
to
> > capture the kernel messages if that would help.
> 
> Well, I''ve tried it on a newish Intel mobo machine with on-board
ahci,
> and that fails.  Another, older, Dell machine using a scsi controller 
> works fine.  I haven''t tried my laptop yet.
> 
> In theory AHCI is ACHI, so the controller vendor shouldn''t matter.
It
> may have more to do with interrupt controller configuration or memory 
> layout.
> 
> On your failing machine, does it work any better if you switch the 
> controller to compat/legacy mode?
I only have network and remote reset possibility and to boot from a
network rescue system, so sorry, can''t test that.

I will try to get some kernel messages and also check if the latest
hackery kernel boots.

	Christophe



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

Christophe Saout wrote:
> Hi Jeremy,
>
>   
>>> I could try to compile netconsole and the NIC driver into the
kernel to
>>> capture the kernel messages if that would help.
>>>       
>> Well, I''ve tried it on a newish Intel mobo machine with
on-board ahci,
>> and that fails.  Another, older, Dell machine using a scsi controller 
>> works fine.  I haven''t tried my laptop yet.
>>
>> In theory AHCI is ACHI, so the controller vendor shouldn''t
matter.   It
>> may have more to do with interrupt controller configuration or memory 
>> layout.
>>
>> On your failing machine, does it work any better if you switch the 
>> controller to compat/legacy mode?
>>     
>
> I only have network and remote reset possibility and to boot from a
> network rescue system, so sorry, can''t test that.
>
> I will try to get some kernel messages and also check if the latest
> hackery kernel boots.
>   
Actually, the kernel to test is xen-tip/next.  That''s going to be the 
base for ongoing development, and I''ll cull all the rest of the
branches
once all their nutritious changesets have been extracted.  Oh, and it 
actually works.

    J

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

Christophe Saout wrote:
> I will try to get some kernel messages and also check if the latest
> hackery kernel boots.
>
>   
But yes, comparing hackery vs xen-tip is a useful exercise.

    J

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

Hi Jeremy,
> > I will try to get some kernel messages and also check if the latest
> > hackery kernel boots.
>
> Actually, the kernel to test is xen-tip/next.
Yes, I''m aware of that.  I just wanted to cross-check if the failure
that I am seeing is a regression or not.  The hackery kernel was the one
that seemed to work well for many people.

	Christophe



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

Hi Jeremy,

just got the netconsole output from the machine, and yes, it''s the AHCI
initialisation problem.  The older "hackery" kernel didn''t
boot either
(didn''t check if it''s the same problem).

I''ve put the log up here:
http://www.saout.de/assets/xen-next-tip-boot-1-log.txt

(ignore the crash at the end, it somehow does that if the initramfs
fails to find the root filesystem)

Also, what I haven''t seen before are slowpath warnings in
xan_apic_write.

The
	ata1: softreset failed (device not ready)
	ata1: failed due to HW bug, retry pmp=0

also appear during the regular boot process, but the IDENTIFY afterworks
then succeeds.

Otherwise the kernel messages from native and Xen kernel are practically
identical (except for the fundamental differences in the setup of
course).

	Christophe



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

Christophe Saout wrote:
> Hi Jeremy,
>
> just got the netconsole output from the machine, and yes, it''s the
AHCI
> initialisation problem.  The older "hackery" kernel
didn''t boot either
> (didn''t check if it''s the same problem).
>   
That would be interesting to know.  push2/xen/dom0/master would also be 
an interesting result.
> I''ve put the log up here:
> http://www.saout.de/assets/xen-next-tip-boot-1-log.txt
>
> (ignore the crash at the end, it somehow does that if the initramfs
> fails to find the root filesystem)
>
> Also, what I haven''t seen before are slowpath warnings in
> xan_apic_write.
>
> The
> 	ata1: softreset failed (device not ready)
> 	ata1: failed due to HW bug, retry pmp=0
>
> also appear during the regular boot process, but the IDENTIFY afterworks
> then succeeds.
>
> Otherwise the kernel messages from native and Xen kernel are practically
> identical (except for the fundamental differences in the setup of
> course).
>   
OK, thanks.  I''m tending towards some kind of interrupt setup.  I
wonder
if there''s any difference in how we''re trying to set things
up.
Certainly there''s been lots of changes in mainline in that area.

    J

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

Hi Jeremy,
> > just got the netconsole output from the machine, and yes,
it''s the AHCI
> > initialisation problem.  The older "hackery" kernel
didn''t boot either
> > (didn''t check if it''s the same problem).
>
> That would be interesting to know.  push2/xen/dom0/master would also be 
> an interesting result.
Ok, you are right.  The hackery kernel sees a different issue.  The AHCI
setup actually works and hard disks are detected, but then it crashes in
my initrd:

Write protecting the kernel read-only data: 5868k
init[1] general protection ip:ffffe42f sp:ffc5cfa4 error:0

(the init process is a bash in this case)

Note that this probably has to do with the fact that my initrd is 32 bit
and hence runs in 32 bit compat mode (I was just to lazy to make me a
new one when I initially bought my first 64 machine).

The funny thing is that I also see this when running the kernel under
qemu but just assumed a problem in qemu and never investigated.  qemu is
emulating an AMD CPU I think, so maybe it''s something related to
sysenter vs. syscall or something. (?)  Because 32 bit compat mode under
XEN works on my Intel notebook.

So I guess if I redo the initramfs as 64 bit the hackery kernel would
boot.  Maybe someone else who has the kernel running on an AMD machine
can test 32 bit compat mode to confirm this observation?

Ok, back to the AHCI issue, test push2/xen/dom0/master is ongoing.

	Christophe



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

Christophe Saout wrote:
> Ok, you are right.  The hackery kernel sees a different issue.  The AHCI
> setup actually works and hard disks are detected, but then it crashes in
> my initrd:
>
> Write protecting the kernel read-only data: 5868k
> init[1] general protection ip:ffffe42f sp:ffc5cfa4 error:0
>
> (the init process is a bash in this case)
>
> Note that this probably has to do with the fact that my initrd is 32 bit
> and hence runs in 32 bit compat mode (I was just to lazy to make me a
> new one when I initially bought my first 64 machine).
>
> The funny thing is that I also see this when running the kernel under
> qemu but just assumed a problem in qemu and never investigated.  qemu is
> emulating an AMD CPU I think, so maybe it''s something related to
> sysenter vs. syscall or something. (?)  Because 32 bit compat mode under
> XEN works on my Intel notebook.
>   
Yes, likely.  There''s an outstanding bug in 32-bit compat on AMD 
systems, but I haven''t got around to setting up a system to repro+debug
on.  The workaround is vdso32=0 on the kernel command line.
> So I guess if I redo the initramfs as 64 bit the hackery kernel would
> boot.  Maybe someone else who has the kernel running on an AMD machine
> can test 32 bit compat mode to confirm this observation?
>
> Ok, back to the AHCI issue, test push2/xen/dom0/master is ongoing.
>   
Thanks,
    J

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

Hi,
> Ok, back to the AHCI issue, test push2/xen/dom0/master is ongoing.
Ok, AHCI detection works with that kernel.
(but my 32 bit LVM setup initramfs also segfaults, so it doesn''t get
up)

	Christophe



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

Christophe Saout wrote:
> Hi,
>
>   
>> Ok, back to the AHCI issue, test push2/xen/dom0/master is ongoing.
>>     
>
> Ok, AHCI detection works with that kernel.
> (but my 32 bit LVM setup initramfs also segfaults, so it doesn''t
get up)
>   
vdso32=0

    J

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

Hi,

Does anyone know when dom0 support is coming to linux kernel? Is it 
already on 2.6.30?

- Valtteri

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

Hi,
> > Ok, AHCI detection works with that kernel.
> > (but my 32 bit LVM setup initramfs also segfaults, so it
doesn''t get up)
>
> vdso32=0
Ok, that seems to help.  Also, there was an unfortunate mixup of the
kernels.  The xen-tip/next kernel actually works fine as well (it''s
just
my merged one that didn''t).  Sorry about that.

With vdso32=0 I could now get the hackery kernel to boot up completely.
For some reason the xen-tip/next also gets past the initramfs stage and
I can see it mount the root filesystem, but doesn''t come up further
than
that (the network never comes up and the last thing I see is netconsole
telling me the rootfs got mounted)

Maybe I mixed something up again.  Possible, it''s quite late,
I''ll
follow up on this another time.

	Christophe



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

Christophe Saout wrote:
> Ok, that seems to help.  Also, there was an unfortunate mixup of the
> kernels.  The xen-tip/next kernel actually works fine as well
(it''s just
> my merged one that didn''t).  Sorry about that.
>   
!?  When I diffed them, there were hardly any differences, and nothing 
which seemed relevant...
> With vdso32=0 I could now get the hackery kernel to boot up completely.
> For some reason the xen-tip/next also gets past the initramfs stage and
> I can see it mount the root filesystem, but doesn''t come up
further than
> that (the network never comes up and the last thing I see is netconsole
> telling me the rootfs got mounted)
>
> Maybe I mixed something up again.  Possible, it''s quite late,
I''ll
> follow up on this another time.
>   
OK, thanks for looking at this.

    J

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

Hi Jeremy,
> Christophe Saout wrote:
> > Ok, that seems to help.  Also, there was an unfortunate mixup of the
> > kernels.  The xen-tip/next kernel actually works fine as well
(it''s just
> > my merged one that didn''t).  Sorry about that.
> >   
> 
> !?  When I diffed them, there were hardly any differences, and nothing 
> which seemed relevant...
Ok, my mistake again.  Clearly I lost track of all my kernel versions
yesterday night.

Yes, the xen-tip/next fails in exactly the same way (AHCI "IDENTIFY
failed") as my merge (on top of 2.6.30-rc1-tip).  I also merged in the
latest tip (2.6.30-rc2-tip) with the same result.

	Christophe



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

Hi again,
> > With vdso32=0 I could now get the hackery kernel to boot up
completely.
> > For some reason the xen-tip/next also gets past the initramfs stage
and
> > I can see it mount the root filesystem, but doesn''t come up
further than
> > that (the network never comes up and the last thing I see is
netconsole
> > telling me the rootfs got mounted)
> >
> > Maybe I mixed something up again.  Possible, it''s quite late,
I''ll
> > follow up on this another time.
>
> OK, thanks for looking at this.
Ok, yes, also victim of my state of mind yesterday.  I got the
2.6.29-tip (push2/xen/dom0/master) fully booted up.  Everything with a
more recent version of tip fails with the AHCI problem.

	Christophe



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

Christophe Saout wrote:
> Hi again,
>
>   
>>> With vdso32=0 I could now get the hackery kernel to boot up
completely.
>>> For some reason the xen-tip/next also gets past the initramfs stage
and
>>> I can see it mount the root filesystem, but doesn''t come
up further than
>>> that (the network never comes up and the last thing I see is
netconsole
>>> telling me the rootfs got mounted)
>>>
>>> Maybe I mixed something up again.  Possible, it''s quite
late, I''ll
>>> follow up on this another time.
>>>       
>> OK, thanks for looking at this.
>>     
>
> Ok, yes, also victim of my state of mind yesterday.  I got the
> 2.6.29-tip (push2/xen/dom0/master) fully booted up.  Everything with a
> more recent version of tip fails with the AHCI problem.
OK, that''s a good baseline.  I''ll start looking into
what''s changed
between the two.

    J


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

Hi,

 We can hope it will be on the Linux 2.6.31, it will certainly have dom0
support... The code is almost there!  :-D

Regards,
Thiago

2009/4/16 Valtteri Kiviniemi <valtteri.kiviniemi@dataproof.fi>
> Hi,
>
> Does anyone know when dom0 support is coming to linux kernel? Is it already
> on 2.6.30?
>
> - Valtteri
>
> _______________________________________________
> 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

It is very interesting watch closely the work of these geek scientists!

Thiago

2009/4/18 Thiago Camargo Martins Cordeiro <thiagocmartinsc@gmail.com>
> Hi,
>
>  We can hope it will be on the Linux 2.6.31, it will certainly have dom0
> support... The code is almost there!  :-D
>
> Regards,
> Thiago
>
> 2009/4/16 Valtteri Kiviniemi <valtteri.kiviniemi@dataproof.fi>
>
> Hi,
>>
>> Does anyone know when dom0 support is coming to linux kernel? Is it
>> already on 2.6.30?
>>
>> - Valtteri
>>
>> _______________________________________________
>> 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 saw:-

http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-04/msg05020.html

There was anything else ?

Boris.

--- On Sat, 4/18/09, Thiago Camargo Martins Cordeiro
<thiagocmartinsc@gmail.com> wrote:
From: Thiago Camargo Martins Cordeiro <thiagocmartinsc@gmail.com>
Subject: Re: [Xen-devel] Mainline kernel dom0 support
To: "Valtteri Kiviniemi" <valtteri.kiviniemi@dataproof.fi>
Cc: xen-devel@lists.xensource.com
Date: Saturday, April 18, 2009, 12:44 PM

Hi,

 We can hope it will be on the Linux 2.6.31, it will certainly have dom0
support... The code is almost there!  :-D

Regards,
Thiago

2009/4/16 Valtteri Kiviniemi <valtteri.kiviniemi@dataproof.fi>

Hi,



Does anyone know when dom0 support is coming to linux kernel? Is it already on
2.6.30?



- Valtteri



_______________________________________________

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 Sat, 18 Apr 2009, Boris Derzhavets wrote:
> I saw:-
> 
> http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-04/msg05020.html
> 
> There was anything else ?
A subset of these (bugfixes and cleanups for xen stuff already in the 
kernel) went in shortly before v2.6.30-rc2
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2e1c63b7ed36532b68f0eddd6a184d7ba1013b89

 	Michael Young

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

Hello Jeremy,


did a fresh clone of your repo and got some warning from git:

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
linux-2.6-xen
Initialized empty Git repository in linux-2.6-xen2/.git/
remote: Counting objects: 1294968, done.
remote: Compressing objects: 100% (225881/225881), done.
remote: Total 1294968 (delta 1084032), reused 1271909 (delta 1061619)
Receiving objects: 100% (1294968/1294968), 306.19 MiB | 671 KiB/s, done.
Resolving deltas: 100% (1084032/1084032), done.
warning: remote HEAD refers to nonexistent ref, unable to checkout.

something broken here?

The chechout worked:
$ cd linux-2.6-xen
$ git checkout origin/xen-tip/next -b xen-tip/next
warning: You appear to be on a branch yet to be born.
warning: Forcing checkout of origin/xen-tip/next.
Checking out files: 100% (27906/27906), done.
Branch xen-tip/next set up to track remote branch
refs/remotes/origin/xen-tip/next.
Switched to a new branch "xen-tip/next"


But this time, it doesn''t build without CONFIG_NUMA.
This is a i686 PAE build.
Didn''t test tip itself for presence of this error:

$ make
  HOSTLD  scripts/kconfig/conf
scripts/kconfig/conf -s arch/x86/Kconfig
  CHK     include/linux/version.h
  UPD     include/linux/version.h
  CHK     include/linux/utsrelease.h
  UPD     include/linux/utsrelease.h
  SYMLINK include/asm -> include/asm-x86
  CC      kernel/bounds.s
  GEN     include/linux/bounds.h
  CC      arch/x86/kernel/asm-offsets.s
In file included from include/linux/suspend.h:8,
                 from arch/x86/kernel/asm-offsets_32.c:11,
                 from arch/x86/kernel/asm-offsets.c:2:
include/linux/mm.h:495:2: error: #error SECTIONS_WIDTH+NODES_WIDTH
+ZONES_WIDTH > BITS_PER_LONG - NR_PAGEFLAGS
make[1]: *** [arch/x86/kernel/asm-offsets.s] Error 1
make: *** [prepare0] Error 2

Am Donnerstag, den 16.04.2009, 09:34 -0700 schrieb Jeremy
Fitzhardinge:
> 
> Actually, the kernel to test is xen-tip/next.  That''s going to be
the
> base for ongoing development, and I''ll cull all the rest of the
branches
> once all their nutritious changesets have been extracted.  Oh, and it 
> actually works.
> 
>     J

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

Marc - A. Dahlhaus [ Administration | Westermann GmbH ]
wrote:
> Hello Jeremy,
>
>
> did a fresh clone of your repo and got some warning from git:
>
> $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
> linux-2.6-xen
> Initialized empty Git repository in linux-2.6-xen2/.git/
> remote: Counting objects: 1294968, done.
> remote: Compressing objects: 100% (225881/225881), done.
> remote: Total 1294968 (delta 1084032), reused 1271909 (delta 1061619)
> Receiving objects: 100% (1294968/1294968), 306.19 MiB | 671 KiB/s, done.
> Resolving deltas: 100% (1084032/1084032), done.
> warning: remote HEAD refers to nonexistent ref, unable to checkout.
>
> something broken here?
>   
I just re-pushed, so try again.

Also, the AHCI problem should be fixed.

    J

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