2.6.32.x dom0 kernel

[M A Young]

I have built another 2.6.32.x based kernel (2.6.32.25-172.xendom0.fc12) at 
http://koji.fedoraproject.org/koji/taskinfo?taskID=2583536 and the 
repository http://repos.fedorapeople.org/repos/myoung/dom0-kernel/ . This 
updates the kernel from 2.6.32.25-rc1 to 2.6.32.25 (which may not actually 
change anything), and uses a later version of xen/stable-2.6.3.32.x which 
adds a couple of xen fixes.

 	Michael Young

[Virgil]

(Xen) Platform timer appears to have unexpectedly wrapped 10 or more times

Kaboom! Zzzzzz.....

2.6.32.25-172.xendom0.fc12
FC14 everything else.

Cheers
V


On Mon, 8 Nov 2010 07:43:36 am M A Young wrote:
>  I have built another 2.6.32.x based kernel
> (2.6.32.25-172.xendom0.fc12) at
>  http://koji.fedoraproject.org/koji/taskinfo?taskID=2583536 and the
>  repository http://repos.fedorapeople.org/repos/myoung/dom0-kernel/ . This
>  updates the kernel from 2.6.32.25-rc1 to 2.6.32.25 (which may not actually
>  change anything), and uses a later version of xen/stable-2.6.3.32.x which
>  adds a couple of xen fixes.
>  
>   	Michael Young
>  --
>  xen mailing list
>  xen(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/xen

[Virgil]

Host crashed. Running HVM fc14-32.

Skipping 86000 seconds.
Skipping 86000 seconds.
Skipping 86000 seconds.
Skipping 86000 seconds.
Skipping 86000 seconds.
Skipping 86000 seconds.
Skipping 86000 seconds.
...
...
...
...
Kaboom

Cheers
V

On Mon, 8 Nov 2010 07:43:36 am M A Young wrote:
>  I have built another 2.6.32.x based kernel
> (2.6.32.25-172.xendom0.fc12) at
>  http://koji.fedoraproject.org/koji/taskinfo?taskID=2583536 and the
>  repository http://repos.fedorapeople.org/repos/myoung/dom0-kernel/ . This
>  updates the kernel from 2.6.32.25-rc1 to 2.6.32.25 (which may not actually
>  change anything), and uses a later version of xen/stable-2.6.3.32.x which
>  adds a couple of xen fixes.
>  
>   	Michael Young
>  --
>  xen mailing list
>  xen(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/xen

[Virgil]

Found this in /var/log/messages as the last thing prior to death.

Clocksource tsc unstable

Did some Googling and found some people changed the dom0 clocksource.

Added clocksource=jiffies to the kernel commandline.

Will see if it does anything.....

V

On Wed, 17 Nov 2010 12:00:01 pm Virgil wrote:
>  Host crashed. Running HVM fc14-32.
>  
>  Skipping 86000 seconds.
>  Skipping 86000 seconds.
>  Skipping 86000 seconds.
>  Skipping 86000 seconds.
>  Skipping 86000 seconds.
>  Skipping 86000 seconds.
>  Skipping 86000 seconds.
>  ...
>  ...
>  ...
>  ...
>  Kaboom
>  
>  Cheers
>  V
>  
>  On Mon, 8 Nov 2010 07:43:36 am M A Young wrote:
>  > I have built another 2.6.32.x based kernel (2.6.32.25-172.xendom0.fc12)
>  > at http://koji.fedoraproject.org/koji/taskinfo?taskID=2583536 and the
>  > repository http://repos.fedorapeople.org/repos/myoung/dom0-kernel/ .
>  > This updates the kernel from 2.6.32.25-rc1 to 2.6.32.25 (which may not
>  > actually change anything), and uses a later version of
>  > xen/stable-2.6.3.32.x which adds a couple of xen fixes.
>  > 
>  >  	Michael Young
>  > 
>  > --
>  > xen mailing list
>  > xen(a)lists.fedoraproject.org
>  > https://admin.fedoraproject.org/mailman/listinfo/xen
>  
>  --
>  xen mailing list
>  xen(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/xen

[Pasi Kärkkäinen]

On Mon, Dec 13, 2010 at 11:30:35AM +1100, Virgil wrote:
>  Found this in /var/log/messages as the last thing prior to death.
>  
>  Clocksource tsc unstable
>  
>  Did some Googling and found some people changed the dom0 clocksource.
>  
>  Added clocksource=jiffies to the kernel commandline.
>   
I believe jiffies is not a very good clocksource..

-- Pasi

>  Will see if it does anything.....
>  
>  V
>  
>  On Wed, 17 Nov 2010 12:00:01 pm Virgil wrote:
>  > Host crashed. Running HVM fc14-32.
>  > 
>  > Skipping 86000 seconds.
>  > Skipping 86000 seconds.
>  > Skipping 86000 seconds.
>  > Skipping 86000 seconds.
>  > Skipping 86000 seconds.
>  > Skipping 86000 seconds.
>  > Skipping 86000 seconds.
>  > ...
>  > ...
>  > ...
>  > ...
>  > Kaboom
>  > 
>  > Cheers
>  > V
>  > 
>  > On Mon, 8 Nov 2010 07:43:36 am M A Young wrote:
>  > > I have built another 2.6.32.x based kernel (2.6.32.25-172.xendom0.fc12)
>  > > at http://koji.fedoraproject.org/koji/taskinfo?taskID=2583536 and the
>  > > repository http://repos.fedorapeople.org/repos/myoung/dom0-kernel/ .
>  > > This updates the kernel from 2.6.32.25-rc1 to 2.6.32.25 (which may not
>  > > actually change anything), and uses a later version of
>  > > xen/stable-2.6.3.32.x which adds a couple of xen fixes.
>  > > 
>  > >  	Michael Young
>  > > 
>  > > --
>  > > xen mailing list
>  > > xen(a)lists.fedoraproject.org
>  > > https://admin.fedoraproject.org/mailman/listinfo/xen
>  > 
>  > --
>  > xen mailing list
>  > xen(a)lists.fedoraproject.org
>  > https://admin.fedoraproject.org/mailman/listinfo/xen
>  --
>  xen mailing list
>  xen(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/xen

[Virgil]

Hi Pasi,

I gave up on the idea of using jiffies as the clocksource.

I was unable to get ntpd to lock onto any time sources with clocksource set to 
jiffies. The jitter and offsets just went crazy.

I'm now turning off all power saving in the bios and reverting to the default 
clocksource. I read that the xen time source attempts to do "stuff" if it 
reckons some ticks went missing. Apparently a cause of missing TSC ticks can 
be going to sleep on some CPUs.... who knows. Something to do with the 
max_cstate.

Cheers
V

On Tue, 14 Dec 2010 06:07:57 am Pasi Kärkkäinen wrote:
>  On Mon, Dec 13, 2010 at 11:30:35AM +1100, Virgil wrote:
>  > Found this in /var/log/messages as the last thing prior to death.
>  > 
>  > Clocksource tsc unstable
>  > 
>  > Did some Googling and found some people changed the dom0 clocksource.
>  > 
>  > Added clocksource=jiffies to the kernel commandline.
>  
>  I believe jiffies is not a very good clocksource..
>  
>  -- Pasi
>  
>  > Will see if it does anything.....
>  > 
>  > V
>  > 
>  > On Wed, 17 Nov 2010 12:00:01 pm Virgil wrote:
>  > > Host crashed. Running HVM fc14-32.
>  > > 
>  > > Skipping 86000 seconds.
>  > > Skipping 86000 seconds.
>  > > Skipping 86000 seconds.
>  > > Skipping 86000 seconds.
>  > > Skipping 86000 seconds.
>  > > Skipping 86000 seconds.
>  > > Skipping 86000 seconds.
>  > > ...
>  > > ...
>  > > ...
>  > > ...
>  > > Kaboom
>  > > 
>  > > Cheers
>  > > V
>  > > 
>  > > On Mon, 8 Nov 2010 07:43:36 am M A Young wrote:
>  > > > I have built another 2.6.32.x based kernel
>  > > > (2.6.32.25-172.xendom0.fc12) at
>  > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=2583536 and the
>  > > > repository http://repos.fedorapeople.org/repos/myoung/dom0-kernel/ .
>  > > > This updates the kernel from 2.6.32.25-rc1 to 2.6.32.25 (which may
>  > > > not actually change anything), and uses a later version of
>  > > > xen/stable-2.6.3.32.x which adds a couple of xen fixes.
>  > > > 
>  > > >  	Michael Young
>  > > > 
>  > > > --
>  > > > xen mailing list
>  > > > xen(a)lists.fedoraproject.org
>  > > > https://admin.fedoraproject.org/mailman/listinfo/xen
>  > > 
>  > > --
>  > > xen mailing list
>  > > xen(a)lists.fedoraproject.org
>  > > https://admin.fedoraproject.org/mailman/listinfo/xen
>  > 
>  > --
>  > xen mailing list
>  > xen(a)lists.fedoraproject.org
>  > https://admin.fedoraproject.org/mailman/listinfo/xen

[Virgil]

Just a quick pre-xmas report:

Since turning off all power saving in the BIOS, everything has worked flawlessly 
(now that I've emailed this I'm sure the entire system will blow up....).

So far so good.

Cheers and merry Xmas
V.
 
On Wed, 15 Dec 2010 01:56:31 pm Virgil wrote:
>  Hi Pasi,
>  
>  I gave up on the idea of using jiffies as the clocksource.
>  
>  I was unable to get ntpd to lock onto any time sources with clocksource set
>  to jiffies. The jitter and offsets just went crazy.
>  
>  I'm now turning off all power saving in the bios and reverting to the
>  default clocksource. I read that the xen time source attempts to do
>  "stuff" if it reckons some ticks went missing. Apparently a cause of
>  missing TSC ticks can be going to sleep on some CPUs.... who knows.
>  Something to do with the max_cstate.
>  
>  Cheers
>  V
>  
>  On Tue, 14 Dec 2010 06:07:57 am Pasi Kärkkäinen wrote:
>  > On Mon, Dec 13, 2010 at 11:30:35AM +1100, Virgil wrote:
>  > > Found this in /var/log/messages as the last thing prior to death.
>  > > 
>  > > Clocksource tsc unstable
>  > > 
>  > > Did some Googling and found some people changed the dom0 clocksource.
>  > > 
>  > > Added clocksource=jiffies to the kernel commandline.
>  > 
>  > I believe jiffies is not a very good clocksource..
>  > 
>  > -- Pasi
>  > 
>  > > Will see if it does anything.....
>  > > 
>  > > V
>  > > 
>  > > On Wed, 17 Nov 2010 12:00:01 pm Virgil wrote:
>  > > > Host crashed. Running HVM fc14-32.
>  > > > 
>  > > > Skipping 86000 seconds.
>  > > > Skipping 86000 seconds.
>  > > > Skipping 86000 seconds.
>  > > > Skipping 86000 seconds.
>  > > > Skipping 86000 seconds.
>  > > > Skipping 86000 seconds.
>  > > > Skipping 86000 seconds.
>  > > > ...
>  > > > ...
>  > > > ...
>  > > > ...
>  > > > Kaboom
>  > > > 
>  > > > Cheers
>  > > > V
>  > > > 
>  > > > On Mon, 8 Nov 2010 07:43:36 am M A Young wrote:
>  > > > > I have built another 2.6.32.x based kernel
>  > > > > (2.6.32.25-172.xendom0.fc12) at
>  > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=2583536 and the
>  > > > > repository http://repos.fedorapeople.org/repos/myoung/dom0-kernel/
>  > > > > . This updates the kernel from 2.6.32.25-rc1 to 2.6.32.25 (which
>  > > > > may not actually change anything), and uses a later version of
>  > > > > xen/stable-2.6.3.32.x which adds a couple of xen fixes.
>  > > > > 
>  > > > >  	Michael Young
>  > > > > 
>  > > > > --
>  > > > > xen mailing list
>  > > > > xen(a)lists.fedoraproject.org
>  > > > > https://admin.fedoraproject.org/mailman/listinfo/xen
>  > > > 
>  > > > --
>  > > > xen mailing list
>  > > > xen(a)lists.fedoraproject.org
>  > > > https://admin.fedoraproject.org/mailman/listinfo/xen
>  > > 
>  > > --
>  > > xen mailing list
>  > > xen(a)lists.fedoraproject.org
>  > > https://admin.fedoraproject.org/mailman/listinfo/xen
>  
>  --
>  xen mailing list
>  xen(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/xen

[Virgil]

Feb 23rd here in Australia.

The system is still running flawlessly since turning off all power saving in 
the BIOS. Looks like the power saving stuff in the BIOS for AMD processors 
could be the issue with the clocksource.

Cheers
V

On Fri, 24 Dec 2010 02:10:54 pm Virgil wrote:
>  Just a quick pre-xmas report:
>  
>  Since turning off all power saving in the BIOS, everything has worked
>  flawlessly (now that I've emailed this I'm sure the entire system will
>  blow up....).
>  
>  So far so good.
>  
>  Cheers and merry Xmas
>  V.
>  
>  On Wed, 15 Dec 2010 01:56:31 pm Virgil wrote:
>  > Hi Pasi,
>  > 
>  > I gave up on the idea of using jiffies as the clocksource.
>  > 
>  > I was unable to get ntpd to lock onto any time sources with clocksource
>  > set to jiffies. The jitter and offsets just went crazy.
>  > 
>  > I'm now turning off all power saving in the bios and reverting to the
>  > default clocksource. I read that the xen time source attempts to do
>  > "stuff" if it reckons some ticks went missing. Apparently a cause of
>  > missing TSC ticks can be going to sleep on some CPUs.... who knows.
>  > Something to do with the max_cstate.
>  > 
>  > Cheers
>  > V
>  > 
>  > On Tue, 14 Dec 2010 06:07:57 am Pasi Kärkkäinen wrote:
>  > > On Mon, Dec 13, 2010 at 11:30:35AM +1100, Virgil wrote:
>  > > > Found this in /var/log/messages as the last thing prior to death.
>  > > > 
>  > > > Clocksource tsc unstable
>  > > > 
>  > > > Did some Googling and found some people changed the dom0 clocksource.
>  > > > 
>  > > > Added clocksource=jiffies to the kernel commandline.
>  > > 
>  > > I believe jiffies is not a very good clocksource..
>  > > 
>  > > -- Pasi
>  > > 
>  > > > Will see if it does anything.....
>  > > > 
>  > > > V
>  > > > 
>  > > > On Wed, 17 Nov 2010 12:00:01 pm Virgil wrote:
>  > > > > Host crashed. Running HVM fc14-32.
>  > > > > 
>  > > > > Skipping 86000 seconds.
>  > > > > Skipping 86000 seconds.
>  > > > > Skipping 86000 seconds.
>  > > > > Skipping 86000 seconds.
>  > > > > Skipping 86000 seconds.
>  > > > > Skipping 86000 seconds.
>  > > > > Skipping 86000 seconds.
>  > > > > ...
>  > > > > ...
>  > > > > ...
>  > > > > ...
>  > > > > Kaboom
>  > > > > 
>  > > > > Cheers
>  > > > > V
>  > > > > 
>  > > > > On Mon, 8 Nov 2010 07:43:36 am M A Young wrote:
>  > > > > > I have built another 2.6.32.x based kernel
>  > > > > > (2.6.32.25-172.xendom0.fc12) at
>  > > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=2583536 and
>  > > > > > the repository
>  > > > > > http://repos.fedorapeople.org/repos/myoung/dom0-kernel/ . This
>  > > > > > updates the kernel from 2.6.32.25-rc1 to 2.6.32.25 (which may
>  > > > > > not actually change anything), and uses a later version of
>  > > > > > xen/stable-2.6.3.32.x which adds a couple of xen fixes.
>  > > > > > 
>  > > > > >  	Michael Young
>  > > > > > 
>  > > > > > --
>  > > > > > xen mailing list
>  > > > > > xen(a)lists.fedoraproject.org
>  > > > > > https://admin.fedoraproject.org/mailman/listinfo/xen
>  > > > > 
>  > > > > --
>  > > > > xen mailing list
>  > > > > xen(a)lists.fedoraproject.org
>  > > > > https://admin.fedoraproject.org/mailman/listinfo/xen
>  > > > 
>  > > > --
>  > > > xen mailing list
>  > > > xen(a)lists.fedoraproject.org
>  > > > https://admin.fedoraproject.org/mailman/listinfo/xen
>  > 
>  > --
>  > xen mailing list
>  > xen(a)lists.fedoraproject.org
>  > https://admin.fedoraproject.org/mailman/listinfo/xen
>  
>  --
>  xen mailing list
>  xen(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/xen

[M A Young]

I have built another 2.6.32.x based kernel (2.6.32.26-174.xendom0.fc12) at
http://koji.fedoraproject.org/koji/taskinfo?taskID=2618746 and the 
repository http://repos.fedorapeople.org/repos/myoung/dom0-kernel/ which 
updates to 2.6.32.26 and a later version of xen/stable-2.6.3.32.x.

 	Michael Young

Final F12 2.6.32.x dom0 kernel and vanilla 2.6.37-rc4

[M A Young]

I have built what may be my last Fedora 12 kernel 
(2.6.32.26-174.2.xendom0.fc12) as Fedora 12 EOLs today (this is the same 
Fedora patch level as the official 2.6.32.26-175.fc12 kernel which has 
just been released). It is available at 
http://koji.fedoraproject.org/koji/taskinfo?taskID=2637740 and the
repository http://repos.fedorapeople.org/repos/myoung/dom0-kernel/
and includes a crash on exit fix. I haven't decided whether I am going to 
build any more 2.6.32.x kernels, I am going to continue building 2.6.37 
kernels but these aren't ready for full dom0 use yet.

For those of you that are trying 2.6.37, I have built a vanilla 2.6.37-rc4 
kernel (no additional xen patches) at 
http://koji.fedoraproject.org/koji/taskinfo?taskID=2635700

 	Michael Young

Final F12 2.6.32.x dom0 kernel and vanilla 2.6.37-rc4

[W. Michael Petullo]

>  I have built what may be my last Fedora 12 kernel 
>  (2.6.32.26-174.2.xendom0.fc12) as Fedora 12 EOLs today (this is the same 
>  Fedora patch level as the official 2.6.32.26-175.fc12 kernel which has 
>  just been released). It is available at 
>  http://koji.fedoraproject.org/koji/taskinfo?taskID=2637740 and the
>  repository http://repos.fedorapeople.org/repos/myoung/dom0-kernel/
>  and includes a crash on exit fix. I haven't decided whether I am going to 
>  build any more 2.6.32.x kernels, I am going to continue building 2.6.37 
>  kernels but these aren't ready for full dom0 use yet. 
Moving forward and for the purposes of Fedora 15 development, can we get
both patched 2.7.37/38 kernels that support DomU and raw upstream
kernels? Or does xen/next-2.6.27 not have the requisite features yet
anyway?

This kernel works as expected with one exception. The exception has been
a nagging problem, but I have not reported it because 1) we are using
a research OS in DomU and 2) we are not clear if the problem is in our
code, Linux or Xen. But, here are the symptoms:

Occasionally (this seems to correlate to network activity between Dom0
and DomU), the system becomes unresponsive. I am running the Michael
Young kernel at runlevel 3 within Dom0 (very little memory used by
applications). Our OS runs in DomU and is constrained to 128MB of
memory. When the system is unresponsive, typing a character into a
Dom0 console take 2-5 seconds to appear on the screen. Likewise, other
activity is extremely slow. As I mentioned, we have not been able to
isolate where the problem is. Running, for example, an OpenWrt Linux
build in DomU does not have this problem.

>  For those of you that are trying 2.6.37, I have built a vanilla
> 2.6.37-rc4
>  kernel (no additional xen patches) at
>  http://koji.fedoraproject.org/koji/taskinfo?taskID=2635700 
This kernel is the first from the 37/38 series that I have tested since
I tested the initial upstream Xen accept. This seems to work within my
expectations with two exceptions:

1. There are some warning related to nouveaufb. When I have time I will
investigate a bit more, but 2.6.32 never really worked right for me with
the nouveau drivers either.

2. On the positive side, it seems that the console back-end driver
works. When I booted a DomU OS I received console messages. This surprised
me. Soon after, Xen was unable to set up the networking for DomU, which
is what I expected.

Dom0 continued to operate fine even though loading an OS in DomU failed.

-- 
Mike

:wq

Final F12 2.6.32.x dom0 kernel and vanilla 2.6.37-rc4

[M A Young]

On Thu, 2 Dec 2010, W. Michael Petullo wrote:

>  Moving forward and for the purposes of Fedora 15 development, can we
> get
>  both patched 2.7.37/38 kernels that support DomU and raw upstream
>  kernels? Or does xen/next-2.6.27 not have the requisite features yet
>  anyway? 
xen/next-2.6.37 doesn't currently have kernel drivers for either block or 
network backends. Userspace block or network backends may be possible but 
I don't know how to get them to work, though it is supposed to be 
possible.

>  This kernel works as expected with one exception. The exception has
> been
>  a nagging problem, but I have not reported it because 1) we are using
>  a research OS in DomU and 2) we are not clear if the problem is in our
>  code, Linux or Xen. But, here are the symptoms:
>
>  Occasionally (this seems to correlate to network activity between Dom0
>  and DomU), the system becomes unresponsive. I am running the Michael
>  Young kernel at runlevel 3 within Dom0 (very little memory used by
>  applications). Our OS runs in DomU and is constrained to 128MB of
>  memory. When the system is unresponsive, typing a character into a
>  Dom0 console take 2-5 seconds to appear on the screen. Likewise, other
>  activity is extremely slow. As I mentioned, we have not been able to
>  isolate where the problem is. Running, for example, an OpenWrt Linux
>  build in DomU does not have this problem. 
I have seen something similar, though I don't know where the fault 
lies either.

 	Michael Young

Final F12 2.6.32.x dom0 kernel and vanilla 2.6.37-rc4

[W. Michael Petullo]

> > This kernel works as expected with one exception. The exception
> has been
> > a nagging problem, but I have not reported it because 1) we are using
> > a research OS in DomU and 2) we are not clear if the problem is in our
> > code, Linux or Xen. But, here are the symptoms: 
> > Occasionally (this seems to correlate to network activity between
> Dom0
> > and DomU), the system becomes unresponsive. I am running the Michael
> > Young kernel at runlevel 3 within Dom0 (very little memory used by
> > applications). Our OS runs in DomU and is constrained to 128MB of
> > memory. When the system is unresponsive, typing a character into a
> > Dom0 console take 2-5 seconds to appear on the screen. Likewise, other
> > activity is extremely slow. As I mentioned, we have not been able to
> > isolate where the problem is. Running, for example, an OpenWrt Linux
> > build in DomU does not have this problem. 
 
>  I have seen something similar, though I don't know where the
> fault
>  lies either. 
That is somewhat good to hear. I have today solved this problem by running
"xm vcpu-set Domain-0 1." By default, Xen assigned Dom0 all of my cores
(two). Reducing this to one solves the problem for me. I am working on
a better write up that I'll send to fedora-xen and possibly the upstream
Xen mailing list. I have not decided if this is a bug and am having some
discussions locally that may help me formulate a better inquiry.

-- 
Mike

:wq

Final F12 2.6.32.x dom0 kernel and vanilla 2.6.37-rc4

[Pasi Kärkkäinen]

On Thu, Dec 02, 2010 at 03:27:42PM -0600, W. Michael Petullo wrote:
>  >> This kernel works as expected with one exception. The
> exception has been
>  >> a nagging problem, but I have not reported it because 1) we are using
>  >> a research OS in DomU and 2) we are not clear if the problem is in our
>  >> code, Linux or Xen. But, here are the symptoms:
>  
>  >> Occasionally (this seems to correlate to network activity between Dom0
>  >> and DomU), the system becomes unresponsive. I am running the Michael
>  >> Young kernel at runlevel 3 within Dom0 (very little memory used by
>  >> applications). Our OS runs in DomU and is constrained to 128MB of
>  >> memory. When the system is unresponsive, typing a character into a
>  >> Dom0 console take 2-5 seconds to appear on the screen. Likewise, other
>  >> activity is extremely slow. As I mentioned, we have not been able to
>  >> isolate where the problem is. Running, for example, an OpenWrt Linux
>  >> build in DomU does not have this problem.
>   
>  > I have seen something similar, though I don't know where the fault
>  > lies either.
>  
>  That is somewhat good to hear. I have today solved this problem by running
>  "xm vcpu-set Domain-0 1." By default, Xen assigned Dom0 all of my cores
>  (two). Reducing this to one solves the problem for me. I am working on
>  a better write up that I'll send to fedora-xen and possibly the upstream
>  Xen mailing list. I have not decided if this is a bug and am having some
>  discussions locally that may help me formulate a better inquiry.
>   
Usually it's better to use dom0_max_vcpus=1 on the grub xen.gz line.

-- Pasi

Final F12 2.6.32.x dom0 kernel and vanilla 2.6.37-rc4

[Pasi Kärkkäinen]

On Thu, Dec 02, 2010 at 09:17:41PM +0000, M A Young wrote:
>  On Thu, 2 Dec 2010, W. Michael Petullo wrote:
>  
>  > Moving forward and for the purposes of Fedora 15 development, can we get
>  > both patched 2.7.37/38 kernels that support DomU and raw upstream
>  > kernels? Or does xen/next-2.6.27 not have the requisite features yet
>  > anyway?
>  
>  xen/next-2.6.37 doesn't currently have kernel drivers for either block or 
>  network backends. Userspace block or network backends may be possible but 
>  I don't know how to get them to work, though it is supposed to be 
>  possible.
>   
Userspace qemu xen_blkback is included in current xen-unstable (4.1), afaik.

-- Pasi

>  > This kernel works as expected with one exception. The exception
> has been
>  > a nagging problem, but I have not reported it because 1) we are using
>  > a research OS in DomU and 2) we are not clear if the problem is in our
>  > code, Linux or Xen. But, here are the symptoms:
>  >
>  > Occasionally (this seems to correlate to network activity between Dom0
>  > and DomU), the system becomes unresponsive. I am running the Michael
>  > Young kernel at runlevel 3 within Dom0 (very little memory used by
>  > applications). Our OS runs in DomU and is constrained to 128MB of
>  > memory. When the system is unresponsive, typing a character into a
>  > Dom0 console take 2-5 seconds to appear on the screen. Likewise, other
>  > activity is extremely slow. As I mentioned, we have not been able to
>  > isolate where the problem is. Running, for example, an OpenWrt Linux
>  > build in DomU does not have this problem.
>  
>  I have seen something similar, though I don't know where the fault 
>  lies either.
>  
>   	Michael Young
>  --
>  xen mailing list
>  xen(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/xen

Final F12 2.6.32.x dom0 kernel and vanilla 2.6.37-rc4

[Bill McGonigle]

On 12/02/2010 06:03 AM, M A Young wrote:
>  I have built what may be my last Fedora 12 kernel
>  (2.6.32.26-174.2.xendom0.fc12) as Fedora 12 EOLs today (this is the same
>  Fedora patch level as the official 2.6.32.26-175.fc12 kernel which has
>  just been released). It is available at
>  http://koji.fedoraproject.org/koji/taskinfo?taskID=2637740  and the
>  repositoryhttp://repos.fedorapeople.org/repos/myoung/dom0-kernel/
>  and includes a crash on exit fix. I haven't decided whether I am going to
>  build any more 2.6.32.x kernels, I am going to continue building 2.6.37
>  kernels but these aren't ready for full dom0 use yet. 
This e-mail started out as a problem report with LSI storage (mptsas) on 
modern Xen kernels, but it was one of those where as you explain the 
problem you finally get it.  So, a public service announcement for the 
archives instead.

The moral of the story was that ACPI and APCI APIC needed to be turned 
_on_ in my BIOS (new ASUS AMD board) and I had acpi=off on my linux 
'module' line from days long past, which needed to go.  It looks like 
Xen can handle ACPI properly now and relies on it.  Hurray.

With any other combination of settings, I'd see errors like:

   mptbase: ioc0: ERROR - didn't initialize properly! (-16)

A healthy non-Xen kernel with this card looks like:

   Fusion MPT base driver 3.04.12
   Copyright (c) 1999-2008 LSI Corporation
   Fusion MPT SAS Host driver 3.04.12
   mptsas 0000:02:00.0: PCI->APIC IRQ transform: INT A -> IRQ 18
   mptbase: ioc0: Initiating bringup
   ioc0: LSISAS1068E B3: Capabilities={Initiator}
   mptsas 0000:02:00.0: setting latency timer to 64

and a healthy Xen Dom0 kernel looks like:

   Fusion MPT base driver 3.04.12
   Copyright (c) 1999-2008 LSI Corporation
   Fusion MPT SAS Host driver 3.04.12
   xen: registering gsi 18 triggering 0 polarity 1
   xen_allocate_pirq: returning irq 18 for gsi 18
   xen: --> irq=18
   Already setup the GSI :18
   mptsas 0000:02:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
   mptbase: ioc0: Initiating bringup
   ioc0: LSISAS1068E B3: Capabilities={Initiator}
   mptsas 0000:02:00.0: setting latency timer to 64

Thanks as always, Michael.

-Bill

-- 
Bill McGonigle, Owner
BFC Computing, LLC
http://bfccomputing.com/
Telephone: [phone]
Email, IM, VOIP: bill(a)bfccomputing.com
VCard: http://bfccomputing.com/vcard/bill.vcf
Social networks: bill_mcgonigle/bill.mcgonigle

Final F12 2.6.32.x dom0 kernel and vanilla 2.6.37-rc4

[Bill McGonigle]

Hi, folks,

Has anybody had luck using phy: disks with this version?  I'm trying to 
create a new OpenSolaris DomU (nexenta 3.0.4) with two phy: devices, and 
instead of the expected behavior I'm seeing two disks show up, one as 
0GB and one as 64510.04GB.

file: devices seem to work OK.

Disks are declared like:

   'phy:/dev/disk/by-id/scsi-SATA_ST31500341AS_9VS41HND,xvda,w',

Thanks,
-Bill

-- 
Bill McGonigle, Owner
BFC Computing, LLC
http://bfccomputing.com/
Telephone: [phone]
Email, IM, VOIP: bill(a)bfccomputing.com
VCard: http://bfccomputing.com/vcard/bill.vcf
Social networks: bill_mcgonigle/bill.mcgonigle

Final F12 2.6.32.x dom0 kernel and vanilla 2.6.37-rc4

[Pasi Kärkkäinen]

On Thu, Feb 10, 2011 at 01:55:57AM -0500, Bill McGonigle wrote:
>  Hi, folks,
>  
>  Has anybody had luck using phy: disks with this version?
>  
With *what* version? :)

>  I'm trying to create a new OpenSolaris DomU (nexenta 3.0.4) with
> two phy: devices, and 
>  instead of the expected behavior I'm seeing two disks show up, one as 
>  0GB and one as 64510.04GB.
>  
>  file: devices seem to work OK.
>  
>  Disks are declared like:
>  
>     'phy:/dev/disk/by-id/scsi-SATA_ST31500341AS_9VS41HND,xvda,w',
>   
Did you try with /dev/sdX ? That shouldn't change the behaviour but you never know..

-- Pasi

>  Thanks,
>  -Bill
>  
>  -- 
>  Bill McGonigle, Owner
>  BFC Computing, LLC
>  http://bfccomputing.com/
>  Telephone: [phone]
>  Email, IM, VOIP: bill(a)bfccomputing.com
>  VCard: http://bfccomputing.com/vcard/bill.vcf
>  Social networks: bill_mcgonigle/bill.mcgonigle
>  --
>  xen mailing list
>  xen(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/xen

Final F12 2.6.32.x dom0 kernel and vanilla 2.6.37-rc4

[Bill McGonigle]

My apologies for not closing the loop on this one.  For the archives...

On 02/10/2011 03:11 AM, Pasi Kärkkäinen wrote:
>  On Thu, Feb 10, 2011 at 01:55:57AM -0500, Bill McGonigle wrote:
> > >  Hi, folks,
> > >
> > >  Has anybody had luck using phy: disks with this version?
> > >
>  With*what*  version?:) 
This was(is) 2.6.32

> > >  I'm trying to create a new OpenSolaris DomU (nexenta
> 3.0.4) with two phy: devices, and
> > >  instead of the expected behavior I'm seeing two disks show up, one as
> > >  0GB and one as 64510.04GB.
> > >
> > >  file: devices seem to work OK.
> > >
> > >  Disks are declared like:
> > >
> > >      'phy:/dev/disk/by-id/scsi-SATA_ST31500341AS_9VS41HND,xvda,w',
> > >
>  Did you try with /dev/sdX ? That shouldn't change the behaviour but you never know..
It turns out this was due to the inability of the 32-bit Solaris kernel 
to handle disks of modern size.  Forcing the 64-bit Solaris kernel 
cleared up the issue.

-Bill

-- 
Bill McGonigle, Owner
BFC Computing, LLC
http://bfccomputing.com/
Telephone: [phone]
Email, IM, VOIP: bill(a)bfccomputing.com
VCard: http://bfccomputing.com/vcard/bill.vcf
Social networks: bill_mcgonigle/bill.mcgonigle