thr3ads.net - Xen users - [Xen-users] 3.0.0 and gplpv [Jul 2011]

If this information is useful, please help other people find it:
Share via:

jim burns

2011-Jul-23 18:26 UTC

[Xen-users] 3.0.0 and gplpv

Pls cc: me, as I am not subscribed.

I''ve noticed that 3.0.0 as a backend is very slow, which is to be
expected
since the drivers were stated as being unoptimized, particularly xen-netback. 
I''m getting speeds between 10-20 Mb/s with iperf and gplpv.

However, I''ve noticed that the gplpv driver in my winxp domu quits
operating
after a while. I can provoke it with iperf - it will stop operating shortly 
afterwards.

Booting with /nogplpv is not an option. It took 45 min. to bring up my 
desktop, and an hour before qemu-dm stopped using 100% of one cpu on dom0. 
Iperf speeds were in the 2-5 Mb/s range. I even seem to be losing keystrokes 
(all of them).

James - have you tested with 3.0.0 yet, or is it too premature?

Using same config file on pvops 2.6.32 (myoung). everything works fine.
I''m
using xen 4.1.1 and ''xm create''. xl still has too many
problems - see today''s
post on the secondary fork of the related thread ''Failure to create HVM
DomU
at Xen 4.1 ( kernel 3.0.0-5-generic) Ubuntu 11.10 (alpha 2)''

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

James Harper

2011-Jul-24 00:40 UTC

head link

RE: [Xen-users] 3.0.0 and gplpv

> 
> I''ve noticed that 3.0.0 as a backend is very slow, which is to be
expected> since the drivers were stated as being unoptimized, particularly
xen-netback.> I''m getting speeds between 10-20 Mb/s with iperf and gplpv.
> 
> However, I''ve noticed that the gplpv driver in my winxp domu quits
operating> after a while. I can provoke it with iperf - it will stop operating
shortly> afterwards.
> 
> Booting with /nogplpv is not an option. It took 45 min. to bring up my
> desktop, and an hour before qemu-dm stopped using 100% of one cpu on
dom0.> Iperf speeds were in the 2-5 Mb/s range. I even seem to be losing
keystrokes> (all of them).
> 
> James - have you tested with 3.0.0 yet, or is it too premature?
> 
> Using same config file on pvops 2.6.32 (myoung). everything works
fine. I''m> using xen 4.1.1 and ''xm create''. xl still has too many
problems - see
today''s> post on the secondary fork of the related thread ''Failure to
create
HVM DomU> at Xen 4.1 ( kernel 3.0.0-5-generic) Ubuntu 11.10 (alpha 2)''
> 
I haven''t tested 3.0.0. When I first read that I thought you were
referring to Xen 3.0.0 :)

What version of GPLPV are you using?

When network performance goes bad after a backend change the cause is
often the network offload (tcp checksum / large send), so you could try
and disable that and see what difference it makes.

If you use the debug version of GPLPV, is there anything interesting in
/var/log/xen/qemu-dm-<domu name>.log?

James

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

jim burns

2011-Jul-24 01:31 UTC

head link

Re: [Xen-users] 3.0.0 and gplpv

On Sat July 23 2011 8:40:09 PM you wrote:> I haven''t tested 3.0.0. When I first read that I thought you were
> referring to Xen 3.0.0 :)
He he - that *would* be ancient!
> What version of GPLPV are you using?
The latest at meadowcourt - 0.11.0.308
> When network performance goes bad after a backend change the cause is
> often the network offload (tcp checksum / large send), so you could try
> and disable that and see what difference it makes.
In the Advanced tab of Xen Net Device Driver Properties, the first 4 items 
are:

Check Checksum on RX Packets - Enabled
Checksum Offload - Disabled
Don''t fix the blank checksum on offload - Disabled
Large Send Offload - 8192

If I understand you correctly, ''Checksum Offload'' is already
disabled, and I
just need to disable ''Large Send Offload'', right? My
dom0''s peth0 is too old
for ethtool to be useful. I''ll try this tomorrow, if I don''t
hear further from
you.
> If you use the debug version of GPLPV, is there anything interesting in
> /var/log/xen/qemu-dm-<domu name>.log?
I use the non-debug version.

Thanx.

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

jim burns

2011-Jul-24 15:40 UTC

head link

Re: [Xen-users] 3.0.0 and gplpv

On Sat July 23 2011 9:31:26 PM you wrote:> In the Advanced tab of Xen Net Device Driver Properties, the first 4 items 
> are:
> 
> Check Checksum on RX Packets - Enabled
> Checksum Offload - Disabled
> Don''t fix the blank checksum on offload - Disabled
> Large Send Offload - 8192
> 
> If I understand you correctly, ''Checksum Offload'' is
already disabled, and
> I  just need to disable ''Large Send Offload'', right? My
dom0''s peth0 is
> too old for ethtool to be useful. I''ll try this tomorrow, if I
don''t hear
> further from you.
No difference. With gplpv, the domu network hung just downloading the latest 
flash installer. I had to login to the vnc console to regain control. (I was 
using rdp.) With /nogplpv, it''s still mondo slow. (not that I would
expect
changing the above settings would affect that.)

I''m not expecting any quick fix. 2.6.32 works quite well for me. I just
wanted
to give you a heads up on possible problems with 3.0.0 (the kernel :) )

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

James Harper

2011-Jul-25 01:01 UTC

head link

RE: [Xen-users] 3.0.0 and gplpv

> 
> On Sat July 23 2011 9:31:26 PM you wrote:
> > In the Advanced tab of Xen Net Device Driver Properties, the first 4
items> > are:
> >
> > Check Checksum on RX Packets - Enabled
> > Checksum Offload - Disabled
> > Don''t fix the blank checksum on offload - Disabled
> > Large Send Offload - 8192
> >
> > If I understand you correctly, ''Checksum Offload'' is
already
disabled, and> > I  just need to disable ''Large Send Offload'', right?
My dom0''s peth0
is> > too old for ethtool to be useful. I''ll try this tomorrow, if
I don''t
hear> > further from you.
> 
> No difference. With gplpv, the domu network hung just downloading the
latest> flash installer. I had to login to the vnc console to regain control.
(I was> using rdp.) With /nogplpv, it''s still mondo slow. (not that I
would
expect> changing the above settings would affect that.)
> 
> I''m not expecting any quick fix. 2.6.32 works quite well for me. I
just wanted> to give you a heads up on possible problems with 3.0.0 (the kernel :))

I''m still keep to identify the problem. Have you done a TCP dump
looking
for bad packets or anything?

tcpdump -s0 -v -n -i vifX.0

where vifX.0 is the interface for your DomU

James

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

Pasi Kärkkäinen

2011-Jul-25 19:31 UTC

head link

Re: [Xen-users] 3.0.0 and gplpv

On Sat, Jul 23, 2011 at 02:26:56PM -0400, jim burns
wrote:> Pls cc: me, as I am not subscribed.
> 
Hello,
> I''ve noticed that 3.0.0 as a backend is very slow, which is to be
expected
> since the drivers were stated as being unoptimized, particularly
xen-netback.
> I''m getting speeds between 10-20 Mb/s with iperf and gplpv.
> 
Something is definitely broken - even with the "unoptimized"
xen-netback
in upstream Linux 3.0.0 you should get at least a gigabit per second (on a
current hardware).
> However, I''ve noticed that the gplpv driver in my winxp domu quits
operating
> after a while. I can provoke it with iperf - it will stop operating shortly
> afterwards.
> 
> Booting with /nogplpv is not an option. It took 45 min. to bring up my 
> desktop, and an hour before qemu-dm stopped using 100% of one cpu on dom0. 
> Iperf speeds were in the 2-5 Mb/s range. I even seem to be losing
keystrokes
> (all of them).
> 
> James - have you tested with 3.0.0 yet, or is it too premature?
> 
3.0.0 should work! (It does for many).
> Using same config file on pvops 2.6.32 (myoung). everything works fine.
I''m
> using xen 4.1.1 and ''xm create''. xl still has too many
problems - see today''s
> post on the secondary fork of the related thread ''Failure to
create HVM DomU
> at Xen 4.1 ( kernel 3.0.0-5-generic) Ubuntu 11.10 (alpha 2)''
> 
Did you check/verify eth stats? errors/drops? anything in kernel logs?

Keep in mind there are *many* non-xen related changes aswell between 2.6.32 and
3.0.0.

-- Pasi


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

jim burns

2011-Jul-25 19:48 UTC

head link

Re: [Xen-users] 3.0.0 and gplpv

On Mon July 25 2011 3:31:22 PM Pasi wrote:> On Sat, Jul 23, 2011 at 02:26:56PM -0400, jim burns wrote:
> > Pls cc: me, as I am not subscribed.
> 
> Hello,
Hi, Pasi! Long time no ''see''.
> > I''ve noticed that 3.0.0 as a backend is very slow, which is
to be
> > expected since the drivers were stated as being unoptimized,
> > particularly xen-netback. I''m getting speeds between 10-20
Mb/s with
> > iperf and gplpv.
> 
> Something is definitely broken - even with the "unoptimized"
xen-netback
> in upstream Linux 3.0.0 you should get at least a gigabit per second (on a
> current hardware).
I''m not even close to being on ''current'' hardware. On
2.6.32, I get about
120Mb/s recv rate to the domu, which is fine with me. We had this discussion a 
couple of years ago, when I was subscribed. Same hardware as then.
> [...]
> Did you check/verify eth stats? errors/drops? anything in kernel logs?
> 
> Keep in mind there are *many* non-xen related changes aswell between 2.6.32
> and 3.0.0.
I don''t remember anything jumping out at me in
''ifconfig'', but I''ll look at it
more closely when I provide James the tcpdump he asked for, in a few days. 
Definitely nothing in the dom0 kernel or qemu-dm logs.

Thanx.

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

Pasi Kärkkäinen

2011-Jul-25 19:57 UTC

head link

Re: [Xen-users] 3.0.0 and gplpv

On Mon, Jul 25, 2011 at 03:48:18PM -0400, jim burns
wrote:> On Mon July 25 2011 3:31:22 PM Pasi wrote:
> > On Sat, Jul 23, 2011 at 02:26:56PM -0400, jim burns wrote:
> > > Pls cc: me, as I am not subscribed.
> > 
> > Hello,
> 
> Hi, Pasi! Long time no ''see''.
> 
indeed! If you''re going to XenSummit next week we can see for real! :)

> > > I''ve noticed that 3.0.0 as a backend is very slow, which
is to be
> > > expected since the drivers were stated as being unoptimized,
> > > particularly xen-netback. I''m getting speeds between
10-20 Mb/s with
> > > iperf and gplpv.
> > 
> > Something is definitely broken - even with the "unoptimized"
xen-netback
> > in upstream Linux 3.0.0 you should get at least a gigabit per second
(on a
> > current hardware).
> 
> I''m not even close to being on ''current''
hardware. On 2.6.32, I get about
> 120Mb/s recv rate to the domu, which is fine with me. We had this
discussion a
> couple of years ago, when I was subscribed. Same hardware as then.
> 
Just to verify.. you mean 120 Mbit/sec? (which is pretty slow..)

> > [...]
> > Did you check/verify eth stats? errors/drops? anything in kernel logs?
> > 
> > Keep in mind there are *many* non-xen related changes aswell between
2.6.32
> > and 3.0.0.
> 
> I don''t remember anything jumping out at me in
''ifconfig'', but I''ll look at it
> more closely when I provide James the tcpdump he asked for, in a few days. 
> Definitely nothing in the dom0 kernel or qemu-dm logs.
> 
Ok.

-- Pasi


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

jim burns

2011-Jul-25 20:24 UTC

head link

Re: [Xen-users] 3.0.0 and gplpv

On Mon July 25 2011 3:57:23 PM Pasi wrote:> On Mon, Jul 25, 2011 at 03:48:18PM -0400, jim burns wrote:
> > Hi, Pasi! Long time no ''see''.
> indeed! If you''re going to XenSummit next week we can see for
real! :)
I wasn''t even paying attention this year to where it''s being
held. I got
discouraged in previous years at it being held in european locations, which is 
well beyond  my means. :)
> > I''m not even close to being on ''current''
hardware. On 2.6.32, I get
> > about  120Mb/s recv rate to the domu, which is fine with me. We had
this
> > discussion a couple of years ago, when I was subscribed. Same hardware
> > as then.
 > Just to verify.. you mean 120 Mbit/sec? (which is pretty slow..)
 Yep! That''s what you get with an Intel Core2 T5600  @ 1.83GHz. We
talked at
length about my performance when I was providing benchmarks for each early 
version of James'' gplpv drivers, and how performance was definitely
software
limited. I''m only interested in relative differences between one
platfom and
another, changing one thing at a time. In this case, gplpv, and my winxp 
config, are the same, but the dom0 is different. Going from 120Mb/s (2.6.32) 
to 20-40 Mb/s (3.0.0), and then hanging is a definite *relative* difference! 
I''m not even concerned about the speed slowdown - just the hang. Hence,
I''ll
provide James with the tcpdump when I get more time in a few days.

Talk to you later.

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

Pasi Kärkkäinen

2011-Jul-25 20:30 UTC

head link

Re: [Xen-users] 3.0.0 and gplpv

On Mon, Jul 25, 2011 at 04:24:10PM -0400, jim burns
wrote:> On Mon July 25 2011 3:57:23 PM Pasi wrote:
> > On Mon, Jul 25, 2011 at 03:48:18PM -0400, jim burns wrote:
> > > Hi, Pasi! Long time no ''see''.
> > indeed! If you''re going to XenSummit next week we can see for
real! :)
> 
> I wasn''t even paying attention this year to where it''s
being held. I got
> discouraged in previous years at it being held in european locations, which
is
> well beyond  my means. :)
> 
Yeah XenSummit 2011 NA is in Santa Clara, CA, USA:
http://xen.org/community/xensummit.html
I think usually XenSummit has been either in North America or in Asia.
> > > I''m not even close to being on
''current'' hardware. On 2.6.32, I get
> > > about  120Mb/s recv rate to the domu, which is fine with me. We
had this
> > > discussion a couple of years ago, when I was subscribed. Same
hardware
> > > as then.
>  
> > Just to verify.. you mean 120 Mbit/sec? (which is pretty slow..)
> 
>  Yep! That''s what you get with an Intel Core2 T5600  @ 1.83GHz. We
talked at
> length about my performance when I was providing benchmarks for each early 
> version of James'' gplpv drivers, and how performance was
definitely software
> limited. I''m only interested in relative differences between one
platfom and
> another, changing one thing at a time. In this case, gplpv, and my winxp 
> config, are the same, but the dom0 is different. Going from 120Mb/s
(2.6.32)
> to 20-40 Mb/s (3.0.0), and then hanging is a definite *relative*
difference!
> I''m not even concerned about the speed slowdown - just the hang.
Hence, I''ll
> provide James with the tcpdump when I get more time in a few days.
> 
> Talk to you later.
Ok. I''m curious to track down why you get such a slow performance..
Your hardware seems decent. It could be some offloading setting 
in dom0 causing trouble.. (buggy nic driver perhaps?)

If you''re willing to investigate more, let me/us know :)

-- Pasi


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

jim burns

2011-Jul-25 20:39 UTC

head link

Re: [Xen-users] 3.0.0 and gplpv

On Mon July 25 2011 3:57:23 PM Pasi wrote:> On Mon, Jul 25, 2011 at 03:48:18PM -0400, jim burns wrote:
> > On Mon July 25 2011 3:31:22 PM Pasi wrote:
> > > On Sat, Jul 23, 2011 at 02:26:56PM -0400, jim burns wrote:
> > > > Pls cc: me, as I am not subscribed.
> > > Hello,
> > Hi, Pasi! Long time no ''see''.
Btw, maybe you were following the thread ''[Xen-devel] Failure to create
HVM
DomU at Xen 4.1 ( kernel 3.0.0-5-generic) Ubuntu 11.10 (alpha 2)''.  In
my fork
of that thread, I summarized many other threads over the last month of people 
having problems starting an hvm domu under xen 4.1.x. Konrad finally provided 
the solution - 4.1.x requires the pv style vfb= line, not the indidvidual 
variables.

Which brings up my pet peev about documentation. Even something as simple as 
updating the xmexample files in the /etc/xen tree would have avoided this 
problem for so many people. Since you lurk around in Xen Devel, maybe you can 
make people aware of the problem?

Thanx.

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

jim burns

2011-Jul-25 20:45 UTC

head link

Re: [Xen-users] 3.0.0 and gplpv

On Mon July 25 2011 4:30:38 PM you wrote:> Ok. I''m curious to track down why you get such a slow
performance..
> Your hardware seems decent. It could be some offloading setting 
> in dom0 causing trouble.. (buggy nic driver perhaps?)
> 
> If you''re willing to investigate more, let me/us know :)
And the posts come fast and furious! :)

I''m grateful for the offer, but no. That''s exactly what we did
two years ago,
including looking at the offloading. I''m convinced that I need to
spring for
more ''current hardware'' to get better performance. And,
really, I really don''t
xfer around gigabyte files much. ;)

Later. (Or sooner, at this rate!)

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

jim burns

2011-Jul-25 21:02 UTC

head link

Re: [Xen-users] 3.0.0 and gplpv

On Mon July 25 2011 4:24:10 PM jim burns wrote:> Yep! That''s what you get with an Intel Core2 T5600  @ 1.83GHz.
Technical note:

The T5600 came out near the end of 2006. It was meant as a socket compatible 
upgrade to a 32 bit processor, giving you a 64 bit system. My Dell motherboard 
probably isn''t optimized for that data path. I even had to get a bios
upgrade
at the time. Eg, as a guess, the motherboard may be multiplexing 64 bits on 
32, or something else equally silly!

Later.

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

Pasi Kärkkäinen

2011-Jul-25 21:03 UTC

head link

Re: [Xen-users] 3.0.0 and gplpv

On Mon, Jul 25, 2011 at 04:45:39PM -0400, jim burns
wrote:> On Mon July 25 2011 4:30:38 PM you wrote:
> > Ok. I''m curious to track down why you get such a slow
performance..
> > Your hardware seems decent. It could be some offloading setting 
> > in dom0 causing trouble.. (buggy nic driver perhaps?)
> > 
> > If you''re willing to investigate more, let me/us know :)
> 
> And the posts come fast and furious! :)
> 
> I''m grateful for the offer, but no. That''s exactly what
we did two years ago,
> including looking at the offloading. I''m convinced that I need to
spring for
> more ''current hardware'' to get better performance. And,
really, I really don''t
> xfer around gigabyte files much. ;)
> 
Well.. I''m able to get full gigabit per second on *multiple*
generations older hardware!
so my network performance numbers are around 10x faster on a way *slower*
machine..

so you definitely have something weird going on there..
> Later. (Or sooner, at this rate!)
:)

-- Pasi


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

Pasi Kärkkäinen

2011-Jul-25 21:05 UTC

head link

[Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

On Mon, Jul 25, 2011 at 04:39:16PM -0400, jim burns
wrote:> On Mon July 25 2011 3:57:23 PM Pasi wrote:
> > On Mon, Jul 25, 2011 at 03:48:18PM -0400, jim burns wrote:
> > > On Mon July 25 2011 3:31:22 PM Pasi wrote:
> > > > On Sat, Jul 23, 2011 at 02:26:56PM -0400, jim burns wrote:
> > > > > Pls cc: me, as I am not subscribed.
> 
> > > > Hello,
> 
> > > Hi, Pasi! Long time no ''see''.
> 
> Btw, maybe you were following the thread ''[Xen-devel] Failure to
create HVM
> DomU at Xen 4.1 ( kernel 3.0.0-5-generic) Ubuntu 11.10 (alpha 2)''.
In my fork
> of that thread, I summarized many other threads over the last month of
people
> having problems starting an hvm domu under xen 4.1.x. Konrad finally
provided
> the solution - 4.1.x requires the pv style vfb= line, not the indidvidual 
> variables.
> 
> Which brings up my pet peev about documentation. Even something as simple
as
> updating the xmexample files in the /etc/xen tree would have avoided this 
> problem for so many people. Since you lurk around in Xen Devel, maybe you
can
> make people aware of the problem?
> 
> Thanx.
Thanks!

Added xen-devel to CC list..

-- Pasi


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

Ian Campbell

2011-Jul-26 15:39 UTC

head link

Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

On Mon, 2011-07-25 at 17:05 -0400, Pasi Kärkkäinen
wrote:> On Mon, Jul 25, 2011 at 04:39:16PM -0400, jim burns wrote:
> > On Mon July 25 2011 3:57:23 PM Pasi wrote:
> > > On Mon, Jul 25, 2011 at 03:48:18PM -0400, jim burns wrote:
> > > > On Mon July 25 2011 3:31:22 PM Pasi wrote:
> > > > > On Sat, Jul 23, 2011 at 02:26:56PM -0400, jim burns
wrote:
> > > > > > Pls cc: me, as I am not subscribed.
> > 
> > > > > Hello,
> > 
> > > > Hi, Pasi! Long time no ''see''.
> > 
> > Btw, maybe you were following the thread ''[Xen-devel] Failure
to create HVM
> > DomU at Xen 4.1 ( kernel 3.0.0-5-generic) Ubuntu 11.10 (alpha
2)''.  In my fork
> > of that thread, I summarized many other threads over the last month of
people
> > having problems starting an hvm domu under xen 4.1.x. Konrad finally
provided
> > the solution - 4.1.x requires the pv style vfb= line, not the
indidvidual
> > variables.
Perhaps I misunderstand this stuff but AIUI the vfb= line configures a
Xen PV framebuffer device whereas the individual vnc*/sdl*/etc variables
configure the backend for the emulated VGA device. IOW they are pretty
much orthogonal and (for an HVM guest) both should work (dependent on
the required in-guest support being available). Also I''m not sure if
they can be used simultaneously, I expect they can.
> > Which brings up my pet peev about documentation. Even something as
simple as
> > updating the xmexample files in the /etc/xen tree would have avoided
this
> > problem for so many people. Since you lurk around in Xen Devel, maybe
you can
> > make people aware of the problem?
If you find areas where xm* are not accurate than patches would be very
much appreciated.
> > 
> > Thanx.
> 
> Thanks!
> 
> Added xen-devel to CC list..
> 
> -- 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

Pasi Kärkkäinen

2011-Jul-26 17:00 UTC

head link

Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

On Tue, Jul 26, 2011 at 04:39:41PM +0100, Ian Campbell
wrote:> On Mon, 2011-07-25 at 17:05 -0400, Pasi Kärkkäinen wrote:
> > On Mon, Jul 25, 2011 at 04:39:16PM -0400, jim burns wrote:
> > > On Mon July 25 2011 3:57:23 PM Pasi wrote:
> > > > On Mon, Jul 25, 2011 at 03:48:18PM -0400, jim burns wrote:
> > > > > On Mon July 25 2011 3:31:22 PM Pasi wrote:
> > > > > > On Sat, Jul 23, 2011 at 02:26:56PM -0400, jim
burns wrote:
> > > > > > > Pls cc: me, as I am not subscribed.
> > > 
> > > > > > Hello,
> > > 
> > > > > Hi, Pasi! Long time no ''see''.
> > > 
> > > Btw, maybe you were following the thread ''[Xen-devel]
Failure to create HVM
> > > DomU at Xen 4.1 ( kernel 3.0.0-5-generic) Ubuntu 11.10 (alpha
2)''.  In my fork
> > > of that thread, I summarized many other threads over the last
month of people
> > > having problems starting an hvm domu under xen 4.1.x. Konrad
finally provided
> > > the solution - 4.1.x requires the pv style vfb= line, not the
indidvidual
> > > variables.
> 
> Perhaps I misunderstand this stuff but AIUI the vfb= line configures a
> Xen PV framebuffer device whereas the individual vnc*/sdl*/etc variables
> configure the backend for the emulated VGA device. IOW they are pretty
> much orthogonal and (for an HVM guest) both should work (dependent on
> the required in-guest support being available). Also I''m not sure
if
> they can be used simultaneously, I expect they can.
>
Jim: Can you please post full example of working HVM cfgfile and not-working HVM
cfgfile.
(including any errors you get with the latter).

> > > Which brings up my pet peev about documentation. Even something
as simple as
> > > updating the xmexample files in the /etc/xen tree would have
avoided this
> > > problem for so many people. Since you lurk around in Xen Devel,
maybe you can
> > > make people aware of the problem?
> 
> If you find areas where xm* are not accurate than patches would be very
> much appreciated.
> 
Thanks!

-- Pasi


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

jim burns

2011-Jul-26 22:20 UTC

head link

[Xen-users] Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

On Tue July 26 2011 1:00:27 PM Pasi Kärkkäinen wrote:> On Tue, Jul 26, 2011 at 04:39:41PM +0100, Ian Campbell wrote:
> > On Mon, 2011-07-25 at 17:05 -0400, Pasi Kärkkäinen wrote:
> > > On Mon, Jul 25, 2011 at 04:39:16PM -0400, jim burns wrote:
> > > > On Mon July 25 2011 3:57:23 PM Pasi wrote:
> > > > 
> > > > Btw, maybe you were following the thread
''[Xen-devel] Failure to
> > > > create HVM DomU at Xen 4.1 ( kernel 3.0.0-5-generic) Ubuntu
11.10
> > > > (alpha 2)''.  In my fork of that thread, I
summarized many other
> > > > threads over the last month of people having problems
starting an
> > > > hvm domu under xen 4.1.x. Konrad finally provided the
solution -
> > > > 4.1.x requires the pv style vfb= line, not the indidvidual
> > > > variables.
> > 
> > Perhaps I misunderstand this stuff but AIUI the vfb= line configures a
> > Xen PV framebuffer device whereas the individual vnc*/sdl*/etc
variables
> > configure the backend for the emulated VGA device. IOW they are pretty
> > much orthogonal and (for an HVM guest) both should work (dependent on
> > the required in-guest support being available). Also I''m not
sure if
> > they can be used simultaneously, I expect they can.
> Jim: Can you please post full example of working HVM cfgfile and
> not-working HVM cfgfile. (including any errors you get with the latter).
> > > > Which brings up my pet peev about documentation. Even
something as
> > > > simple as updating the xmexample files in the /etc/xen tree
would
> > > > have avoided this problem for so many people. Since you lurk
around
> > > > in Xen Devel, maybe you can make people aware of the
problem?
> > 
> > If you find areas where xm* are not accurate than patches would be
very
> > much appreciated.
Sure, thanx. The following worked from xen 3.2.x to 4.0.1. w/o the vfb= line. 
Starting with xen 4.1.x, w/o the vfb= line, the vnc window immediately exits 
without even displaying the bochs bios, and qemu-dm exits also. Not till 
adding the vfb= line does qemu-dm come up properly, as in previous xen 
versions. The qemu-dm-winxp.log file is not very informative, as it basically 
doesn''t change w/ or w/o the vfb= line. (Except a full guest boot adds
lines
that start with ''Unknown PV product 2'' (gplpv) and end with
''Time offset''.)

The ''xen be: console-0:'' errors only occur when you use
''xm create'', not ''xl
create''. You''ll notice I''ve gone back to using a
xenbr0 bridge, setup by the
fedora (15) ifcfg- files. Xl won''t put tapn.0 on the eth0 bridge, so
the guest
comes up w/o a functioning network, even tho'' the vif= line previously 
explicitly set bridge=eth0. Now it specifies bridge=xenbr0. The error with
''xl
create'' and no vfb= line is even less informative. With ''xm
create'', xend.log
properly reports that xen refused to restart the guest to prevent loops - 
guest is restarting too fast. With ''xl create'' xl just goes
into an infinite
loop, spawning child xls and qemu-dms that immediately exit.

No where in the xmexample.hvm and similar files is vfb= mentioned. Lots of 
people over the last month have been having trouble starting their hvm 
domains, until Konrad mentioned in the thread mentioned above to add the vfb= 
line.

winxp config file: (python code commented out to keep xl happy)

#import os, re
#arch = os.uname()[4]
#if re.search(''64'', arch):
#    arch_libdir = ''lib64''
#else:
#    arch_libdir = ''lib''

name = "winxp"
builder=''hvm''
memory = "512"
uuid = "6c7de04e-df10-caa8-bb2a-8368246225c1"
#ostype = "hvm" (no longer needed?)
on_reboot = "restart"
on_crash = "restart"
on_poweroff = "destroy"
vcpus = "2"
viridian=1
#
#kernel = "/usr/lib/xen/boot/hvmloader"
kernel = "hvmloader"
acpi=1
apic=1
boot= "cda"
# New stuff
#device_model = ''/usr/'' + arch_libdir +
''/xen/bin/qemu-dm''
#device_model = ''/usr/lib/xen/bin/qemu-dm''
device_model = ''qemu-dm''
#
keymap=''en-us''
localtime=1
#rtc_timeoffset=-14400
#rtc_timeoffset=-18000
pae=1
serial=''pty''
#serial = "/dev/ttyS0"
#   enable sound card support, [sb16|es1370|all|..,..], default none
soundhw=''es1370''
# enable stdvga, default = 0 (use cirrus logic device model)
#stdvga=1
videoram=4  # also necessary to keep xl happy, even tho the default is 8
stdvga=0
#usbdevice="mouse"
usbdevice="tablet"
xen_extended_power_mgmt = 0
#
#disk=[ ''tap2:aio:/var/lib/xen/images/winxp,hda,w'', 
''phy:/dev/cdrom,hdc:cdrom,r'' ]
disk=[ ''phy:/dev/disk/by-path/ip-192.168.1.101:3260-iscsi-
iqn.2001-04.com.Dell4550-iqn.2009-09.net.bellsouth.sda:041b7d3f-b008-4367-
b1f2-b4799d15e4cd-lun-1,hda,w'',
''phy:/dev/cdrom,hdc:cdrom,r'' ]
#
#vif = [ ''mac=00:16:3e:23:1d:36, script=vif-bridge, bridge =
eth0'' ]
vif = [ ''mac=00:16:3e:23:1d:36, type=ioemu, script=vif-bridge, bridge =
xenbr0'' ]
#
sdl=0
vfb = [ ''vnc=1, vnclisten=0.0.0.0, vncunused=0, vncdisplay=3,
vncpasswd= '']
vnc=1
vnclisten="0.0.0.0"
#vnclisten="192.168.1.0" ( is there any way to do this? use to work in
xen
3.2)
# set VNC display number, default = domid
vncdisplay=3
# try to find an unused port for the VNC server, default = 1
vncunused=0
vncviewer=1
vncconsole=1
monitor=1
vncpasswd=""

qemu-dm-winxp.log:

domid: 1
config qemu network with xen bridge for  tap1.0 xenbr0
Using file /dev/disk/by-path/ip-192.168.1.101:3260-iscsi-
iqn.2001-04.com.Dell4550-iqn.2009-09.net.bellsouth.sda:041b7d3f-b008-4367-
b1f2-b4799d15e4cd-lun-1 in read-write mode
Using file /dev/cdrom in read-only mode
Watching /local/domain/0/device-model/1/logdirty/cmd
Watching /local/domain/0/device-model/1/command
Watching /local/domain/1/cpu
char device redirected to /dev/pts/5
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = 6c7de04e-df10-caa8-bb2a-8368246225c1
Time offset set 72000
char device redirected to /dev/pts/6
xen be: console-0: xen be: console-0: initialise() failed
initialise() failed
populating video RAM at ff000000
mapping video RAM from ff000000
Register xen platform.
Done register platform.
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw 
state.
xs_read(/local/domain/0/device-model/1/xen_extended_power_mgmt): read error
xs_read(): vncpasswd get error. /vm/6c7de04e-df10-caa8-
bb2a-8368246225c1/vncpasswd.
medium change watch on `hdc'' (index: 1): /dev/cdrom
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
Log-dirty: no command yet.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xen be: console-0: xen be: console-0: initialise() failed
initialise() failed
vcpu-set: watch node error.
xen be: console-0: xen be: console-0: initialise() failed
initialise() failed
xs_read(/local/domain/1/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/1/log-throttling''
medium change watch on `/local/domain/1/log-throttling'' - unknown
device,
ignored
xen be: console-0: xen be: console-0: initialise() failed
initialise() failed
cirrus vga map change while on lfb mode
mapping vram to f0000000 - f0400000
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw 
state.
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is ro 
state.
Unknown PV product 2 loaded in guest
PV driver build 1
region type 1 at [c100,c200).
region type 0 at [f3001000,f3001100).
squash iomem [f3001000, f3001100).
Time offset set -14400, added offset -86400
Time offset set -14398, added offset 2
Time offset set 2, added offset 14400
Time offset set 1, added offset -1

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

jim burns

2011-Jul-30 20:58 UTC

head link

Re: RE: [Xen-users] 3.0.0 and gplpv

> I''m still keep to identify the problem. Have you done a TCP dump
looking
> for bad packets or anything?
> tcpdump -s0 -v -n -i vifX.0
> where vifX.0 is the interface for your DomU
Well, this has been a fun week. A few days ago, I got a major kmail update. 
It''s now fully converted over to using akonadi (ugh!). I thought I had 
everything converted over after a couple of days, but I just looked at my 
converted saved mails, and they are nothing but headers! Fortunately, kmail 
still keeps track of the originals.

Then yesterday, fedora rawhide put out kernel-3.1.0-0.rc0, and I got all 
excited. Hmm - it doesn''t boot under the hypervisor. And when I tried
to boot
bare metal, it couldn''t find modules.dep, or any kernel modules. Turns
out
dmesg and uname are advertising the kernel as 3.0.1-0.rc0. And yet, the new 
kernel config options are there:

4394a4423,4424> CONFIG_XEN_SELFBALLOONING=y
> CONFIG_XEN_BALLOON_MEMORY_HOTPLUG=y
4405a4436,4437> CONFIG_XEN_TMEM=y
> CONFIG_XEN_PCIDEV_BACKEND=m
that you would expect from kernel 3.1. A simple soft link in /lib/modules 
from:

3.0.1-0.rc0.git9.1.fc17.x86_64 -> 3.1.0-0.rc0.git9.1.fc17.x86_64

solved the bare metal boot problem. I just got another kernel-3.1.0-0.rc0 
update (from git9.1 to git11.2). Hopefully, fedora has sorted out it''s
kernel
identity crisis!

Anyway, as promised, I did the tcpdump under dom0 3.0.0-1 on my winxp domu. 
The gplpv network interface died while I was asleep. What''s interesting
about
it is it appears only tcp died. You''ll see udp packets on 6646 (mcafee)
and
smb, but no responses to arp. The ifconfig output appears uninteresting. dom0 
syslog had two things of interest. My dom0 is setup as a local browser in 
smb.conf, but my winxp domu (inspxpvm) kept announcing itself as the local 
browser, as if it couldn''t hear anyone else on the network. Finally,
earlier
(shortly after booting the domu), syslog reported a kmalloc poisoning.

I''ll continue to try to get a dump closer to when xennet actually
froze, and
post that. Hope this was of interest.

tcpdump -s0 -v -n -i vif1.0 :

    192.168.1.102.6646 > 192.168.1.255.6646: UDP, length 1147
15:50:02.842410 IP (tos 0x0, ttl 128, id 401, offset 0, flags [none], proto 
UDP (17), length 255)
    192.168.1.102.netbios-dgm > 192.168.1.255.netbios-dgm: NBT UDP
PACKET(138)
15:50:26.036034 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 
192.168.1.1 tell 192.168.1.102, length 28
15:50:30.029020 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 
192.168.1.1 tell 192.168.1.102, length 28
15:50:34.028941 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 
192.168.1.1 tell 192.168.1.102, length 28
15:50:41.040211 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 
192.168.1.1 tell 192.168.1.102, length 28
15:50:44.091453 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 
192.168.1.1 tell 192.168.1.102, length 28
15:50:50.106342 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 
192.168.1.1 tell 192.168.1.102, length 28
15:50:53.687827 IP (tos 0x0, ttl 128, id 414, offset 0, flags [none], proto 
UDP (17), length 198)
    192.168.1.102.6646 > 192.168.1.255.6646: UDP, length 170
15:50:55.522504 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 
192.168.1.1 tell 192.168.1.102, length 28
^C
196319 packets captured
375563 packets received by filter
179244 packets dropped by kernel
root@insp6400 07/30/11  3:51PM:~
[507] > (ifconfig vif1.0)
vif1.0    Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF
          inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:9000  Metric:1
          RX packets:184519 errors:0 dropped:0 overruns:0 frame:0
          TX packets:191061 errors:0 dropped:3 overruns:0 carrier:0
          collisions:0 txqueuelen:32
          RX bytes:150101405 (143.1 MiB)  TX bytes:211552022 (201.7 MiB)

two snippets from syslog:

Jul 30 16:26:05 Insp6400 nmbd[3035]: [2011/07/30 16:26:05.918094,  0] 
nmbd/nmbd_incomingdgrams.c:308(process_local_master_announce)
Jul 30 16:26:05 Insp6400 nmbd[3035]:   process_local_master_announce: Server 
INSPXPVM at IP 192.168.1.102 is announcing itself as a local master browser 
for workgroup LINKSYS and we think we are master. Forcing election.
Jul 30 16:26:05 Insp6400 nmbd[3035]: [2011/07/30 16:26:05.994876,  0] 
nmbd/nmbd_become_lmb.c:148(unbecome_local_master_success)
Jul 30 16:26:05 Insp6400 nmbd[3035]:   *****
Jul 30 16:26:05 Insp6400 nmbd[3035]:
Jul 30 16:26:05 Insp6400 nmbd[3035]:   Samba name server INSP6400 has stopped 
being a local master browser for workgroup LINKSYS on subnet 192.168.1.100
Jul 30 16:26:05 Insp6400 nmbd[3035]:
Jul 30 16:26:05 Insp6400 nmbd[3035]:   *****
Jul 30 16:26:23 Insp6400 nmbd[3035]: [2011/07/30 16:26:23.219147,  0] 
nmbd/nmbd_become_lmb.c:395(become_local_master_stage2)
Jul 30 16:26:23 Insp6400 nmbd[3035]:   *****
Jul 30 16:26:23 Insp6400 nmbd[3035]:
Jul 30 16:26:23 Insp6400 nmbd[3035]:   Samba name server INSP6400 is now a 
local master browser for workgroup LINKSYS on subnet 192.168.1.100
Jul 30 16:26:23 Insp6400 nmbd[3035]:
Jul 30 16:26:23 Insp6400 nmbd[3035]:   *****


Jul 29 23:15:43 Insp6400 kernel: [ 2254.454064] FIX kmalloc-2048: Restoring 
0xffff88005e584ac8-0xffff88005e5850cb=0x6b
Jul 29 23:15:43 Insp6400 kernel: [ 2254.454064]
Jul 29 23:15:43 Insp6400 kernel: [ 2254.454064] FIX kmalloc-2048: Marking all 
objects used
Jul 29 23:15:43 Insp6400 kernel: [ 2254.454064] 
============================================================================Jul
29 23:15:43 Insp6400 kernel: [ 2254.454064] BUG kmalloc-2048 (Not
tainted): Poison overwritten
Jul 29 23:15:43 Insp6400 kernel: [ 2254.454064] 
-----------------------------------------------------------------------------
Jul 29 23:15:43 Insp6400 kernel: [ 2254.454064]
Jul 29 23:15:43 Insp6400 kernel: [ 2254.454064] INFO: 
0xffff88005a37a160-0xffff88005a37a763. First byte 0xe6 instead of 0x6b
Jul 29 23:15:43 Insp6400 kernel: [ 2254.454064] INFO: Allocated in 
__netdev_alloc_skb+0x1f/0x3c age=418 cpu=0 pid=5224
Jul 29 23:15:43 Insp6400 kernel: [ 2254.454064] INFO: Freed in 
skb_release_data+0xa5/0xaa age=225 cpu=0 pid=5224
Jul 29 23:15:43 Insp6400 kernel: [ 2254.454064] INFO: Slab 0xffffea00013bc240 
objects=15 used=14 fp=0xffff88005a37a120 flags=0x200000000040c1
Jul 29 23:15:43 Insp6400 kernel: [ 2254.454064] INFO: Object 
0xffff88005a37a120 @offset=8480 fp=0x          (null)


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

jim burns

2011-Jul-30 22:28 UTC

head link

RE: [Xen-users] 3.0.0 and gplpv

> solved the bare metal boot problem. I just got another kernel-3.1.0-0.rc0 
> update (from git9.1 to git11.2). Hopefully, fedora has sorted out
it''s
>kernel identity crisis!
Rawhide kernel 3.1.0-0.rc0.git11.2.fc17.x86_64 boots correctly bare metal. It 
still reboots after the hypervisor output, tho''. It''s around
the time drm
should kick in, but putting ''nomodeset'' on the
kernel''s ''module'' line has no
effect.
> I''ll continue to try to get a dump closer to when xennet actually
froze, and
> post that. Hope this was of interest.
Well, that was fast. xennet hung shortly after I logged in thru rdp, while 
mcafee was still looking for updates. 192.168.1.101 is the rdp client, 
192.168.1.102 is the winxp domu. After a few rdp updates, and responses from 
the client rdp, and some internet responses, the conversation becomes one 
sided, with only the domu talking rdp, and then degenerates into a bunch of 
dns lookups.

Is any of this helping?

    192.168.1.101.35386 > 192.168.1.102.ms-wbt-server: Flags [P.], cksum 
0x48bd (correct), seq 133006:133067, ack 14902799, win 2838, options 
[nop,nop,TS val 1923626537 ecr 10749], length 61
18:05:36.081175 IP (tos 0x0, ttl 54, id 57835, offset 0, flags [DF], proto TCP 
(6), length 1492)
    69.31.132.113.http > 192.168.1.102.startron: Flags [.], cksum 0x3515 
(correct), seq 233773:235225, ack 477, win 6432, length 1452
18:05:36.081214 IP (tos 0x0, ttl 64, id 4693, offset 0, flags [DF], proto TCP 
(6), length 113)
    192.168.1.101.35386 > 192.168.1.102.ms-wbt-server: Flags [P.], cksum 
0x9d22 (correct), seq 133067:133128, ack 14902799, win 2838, options 
[nop,nop,TS val 1923626540 ecr 10749], length 61
18:05:36.081293 IP (tos 0x0, ttl 54, id 57836, offset 0, flags [DF], proto TCP 
(6), length 1492)
    69.31.132.113.http > 192.168.1.102.startron: Flags [.], cksum 0xa0ac 
(correct), seq 235225:236677, ack 477, win 6432, length 1452
18:05:36.081358 IP (tos 0x0, ttl 54, id 57837, offset 0, flags [DF], proto TCP 
(6), length 1492)
    69.31.132.113.http > 192.168.1.102.startron: Flags [.], cksum 0xceb7 
(correct), seq 236677:238129, ack 477, win 6432, length 1452
18:05:36.081396 IP (tos 0x0, ttl 64, id 4694, offset 0, flags [DF], proto TCP 
(6), length 113)
    192.168.1.101.35386 > 192.168.1.102.ms-wbt-server: Flags [P.], cksum 
0x0b30 (correct), seq 133128:133189, ack 14902799, win 2838, options 
[nop,nop,TS val 1923626542 ecr 10749], length 61
18:05:36.081456 IP (tos 0x0, ttl 54, id 57838, offset 0, flags [DF], proto TCP 
(6), length 1492)
    69.31.132.113.http > 192.168.1.102.startron: Flags [.], cksum 0xfcdb 
(correct), seq 238129:239581, ack 477, win 6432, length 1452
18:05:36.081520 IP (tos 0x0, ttl 54, id 57839, offset 0, flags [DF], proto TCP 
(6), length 1492)
    69.31.132.113.http > 192.168.1.102.startron: Flags [.], cksum 0xb58b 
(correct), seq 239581:241033, ack 477, win 6432, length 1452
18:05:36.081581 IP (tos 0x0, ttl 54, id 57840, offset 0, flags [DF], proto TCP 
(6), length 1492)
    69.31.132.113.http > 192.168.1.102.startron: Flags [.], cksum 0x713b 
(correct), seq 241033:242485, ack 477, win 6432, length 1452
18:05:36.081642 IP (tos 0x0, ttl 54, id 57841, offset 0, flags [DF], proto TCP 
(6), length 1492)
    69.31.132.113.http > 192.168.1.102.startron: Flags [.], cksum 0xb004 
(correct), seq 242485:243937, ack 477, win 6432, length 1452
18:05:36.081704 IP (tos 0x0, ttl 54, id 57842, offset 0, flags [DF], proto TCP 
(6), length 1492)
    69.31.132.113.http > 192.168.1.102.startron: Flags [.], cksum 0x180c 
(correct), seq 243937:245389, ack 477, win 6432, length 1452
18:05:36.081768 IP (tos 0x0, ttl 54, id 57843, offset 0, flags [DF], proto TCP 
(6), length 1492)
    69.31.132.113.http > 192.168.1.102.startron: Flags [.], cksum 0x8288 
(correct), seq 245389:246841, ack 477, win 6432, length 1452
18:05:36.081831 IP (tos 0x0, ttl 54, id 57844, offset 0, flags [DF], proto TCP 
(6), length 1492)
    69.31.132.113.http > 192.168.1.102.startron: Flags [.], cksum 0x074e 
(correct), seq 246841:248293, ack 477, win 6432, length 1452
18:05:36.081891 IP (tos 0x0, ttl 54, id 57845, offset 0, flags [DF], proto TCP 
(6), length 1492)
    69.31.132.113.http > 192.168.1.102.startron: Flags [.], cksum 0x23c9 
(correct), seq 248293:249745, ack 477, win 6432, length 1452
18:05:36.081948 IP (tos 0x0, ttl 54, id 57846, offset 0, flags [DF], proto TCP 
(6), length 1492)
    69.31.132.113.http > 192.168.1.102.startron: Flags [.], cksum 0x0a7d 
(correct), seq 249745:251197, ack 477, win 6432, length 1452
18:05:36.082009 IP (tos 0x0, ttl 54, id 57847, offset 0, flags [DF], proto TCP 
(6), length 1492)
    69.31.132.113.http > 192.168.1.102.startron: Flags [.], cksum 0xdf24 
(correct), seq 251197:252649, ack 477, win 6432, length 1452
18:05:36.083419 IP (tos 0x0, ttl 54, id 57848, offset 0, flags [DF], proto TCP 
(6), length 1492)
    69.31.132.113.http > 192.168.1.102.startron: Flags [.], cksum 0xff83 
(correct), seq 252649:254101, ack 477, win 6432, length 1452
18:05:36.084004 IP (tos 0x0, ttl 128, id 13308, offset 0, flags [DF], proto 
TCP (6), length 52)
    192.168.1.102.ms-wbt-server > 192.168.1.101.35386: Flags [.], cksum
0xe395
(correct), ack 133006, win 65394, options [nop,nop,TS val 10750 ecr 
1923626534], length 0
18:05:36.090636 IP (tos 0x0, ttl 64, id 4695, offset 0, flags [DF], proto TCP 
(6), length 113)
    192.168.1.101.35386 > 192.168.1.102.ms-wbt-server: Flags [P.], cksum 
0xe2fe (correct), seq 133189:133250, ack 14902799, win 2838, options 
[nop,nop,TS val 1923626552 ecr 10750], length 61
18:05:36.090943 IP (tos 0x0, ttl 54, id 57849, offset 0, flags [DF], proto TCP 
(6), length 1492)
    69.31.132.113.http > 192.168.1.102.startron: Flags [.], cksum 0xc636 
(correct), seq 254101:255553, ack 477, win 6432, length 1452
18:05:36.190084 IP (tos 0x0, ttl 128, id 13309, offset 0, flags [DF], proto 
TCP (6), length 40)
    192.168.1.102.startron > 69.31.132.113.http: Flags [.], cksum 0xcadc 
(correct), ack 235225, win 65535, length 0
18:05:36.190166 IP (tos 0x0, ttl 128, id 13310, offset 0, flags [DF], proto 
TCP (6), length 52)
    192.168.1.102.ms-wbt-server > 192.168.1.101.35386: Flags [.], cksum
0xe392
(correct), ack 133128, win 65272, options [nop,nop,TS val 10750 ecr 
1923626537], length 0
18:05:36.190325 IP (tos 0x0, ttl 128, id 13311, offset 0, flags [DF], proto 
TCP (6), length 40)
    192.168.1.102.startron > 69.31.132.113.http: Flags [.], cksum 0xbf84 
(correct), ack 238129, win 65535, length 0
18:05:36.190371 IP (tos 0x0, ttl 128, id 13312, offset 0, flags [DF], proto 
TCP (6), length 40)
    192.168.1.102.startron > 69.31.132.113.http: Flags [.], cksum 0xb42c 
(correct), ack 241033, win 65535, length 0
18:05:36.190471 IP (tos 0x0, ttl 128, id 13313, offset 0, flags [DF], proto 
TCP (6), length 40)
    192.168.1.102.startron > 69.31.132.113.http: Flags [.], cksum 0xa8d4 
(correct), ack 243937, win 65535, length 0
18:05:36.190516 IP (tos 0x0, ttl 128, id 13314, offset 0, flags [DF], proto 
TCP (6), length 40)
    192.168.1.102.startron > 69.31.132.113.http: Flags [.], cksum 0x9d7c 
(correct), ack 246841, win 65535, length 0
18:05:36.190617 IP (tos 0x0, ttl 128, id 13315, offset 0, flags [DF], proto 
TCP (6), length 40)
    192.168.1.102.startron > 69.31.132.113.http: Flags [.], cksum 0x9224 
(correct), ack 249745, win 65535, length 0
18:05:36.190663 IP (tos 0x0, ttl 128, id 13316, offset 0, flags [DF], proto 
TCP (6), length 40)
    192.168.1.102.startron > 69.31.132.113.http: Flags [.], cksum 0x86cc 
(correct), ack 252649, win 65535, length 0
18:05:36.190763 IP (tos 0x0, ttl 128, id 13317, offset 0, flags [DF], proto 
TCP (6), length 52)
    192.168.1.102.ms-wbt-server > 192.168.1.101.35386: Flags [.], cksum
0xe38d
(correct), ack 133250, win 65150, options [nop,nop,TS val 10750 ecr 
1923626542], length 0
18:05:36.190808 IP (tos 0x0, ttl 128, id 13318, offset 0, flags [DF], proto 
TCP (6), length 40)
    192.168.1.102.startron > 69.31.132.113.http: Flags [.], cksum 0x7b74 
(correct), ack 255553, win 65535, length 0
18:05:36.202555 IP (tos 0x0, ttl 54, id 57850, offset 0, flags [DF], proto TCP 
(6), length 1492)
    69.31.132.113.http > 192.168.1.102.startron: Flags [.], cksum 0xf9e6 
(correct), seq 255553:257005, ack 477, win 6432, length 1452
18:05:36.217909 IP (tos 0x0, ttl 54, id 57851, offset 0, flags [DF], proto TCP 
(6), length 1492)
    69.31.132.113.http > 192.168.1.102.startron: Flags [.], cksum 0x63e5 
(correct), seq 257005:258457, ack 477, win 6432, length 1452
18:05:36.221558 IP (tos 0x0, ttl 128, id 13319, offset 0, flags [DF], proto 
TCP (6), length 40)
    192.168.1.102.startron > 69.31.132.113.http: Flags [.], cksum 0x701c 
(correct), ack 258457, win 65535, length 0
18:05:37.398408 IP (tos 0x0, ttl 128, id 13320, offset 0, flags [DF], proto 
TCP (6), length 314)
    192.168.1.102.ms-wbt-server > 192.168.1.101.35386: Flags [P.], cksum 
0xd3d4 (correct), seq 14902799:14903061, ack 133250, win 65150, options 
[nop,nop,TS val 10764 ecr 1923626542], length 262
18:05:37.507430 IP (tos 0x0, ttl 128, id 13321, offset 0, flags [DF], proto 
TCP (6), length 1492)
    192.168.1.102.ms-wbt-server > 192.168.1.101.35386: Flags [.], cksum
0xe069
(correct), seq 14903061:14904501, ack 133250, win 65150, options [nop,nop,TS 
val 10765 ecr 1923626542], length 1440
18:05:37.508853 IP (tos 0x0, ttl 128, id 13322, offset 0, flags [DF], proto 
TCP (6), length 1492)
    192.168.1.102.ms-wbt-server > 192.168.1.101.35386: Flags [.], cksum
0x8d9f
(correct), seq 14904501:14905941, ack 133250, win 65150, options [nop,nop,TS 
val 10765 ecr 1923626542], length 1440
18:05:37.508935 IP (tos 0x0, ttl 128, id 13323, offset 0, flags [DF], proto 
TCP (6), length 205)
    192.168.1.102.ms-wbt-server > 192.168.1.101.35386: Flags [P.], cksum 
0x58b7 (correct), seq 14905941:14906094, ack 133250, win 65150, options 
[nop,nop,TS val 10765 ecr 1923626542], length 153
18:05:37.532285 IP (tos 0x0, ttl 128, id 13324, offset 0, flags [none], proto 
UDP (17), length 198)
    192.168.1.102.6646 > 192.168.1.255.6646: UDP, length 170
18:05:37.671338 IP (tos 0x0, ttl 128, id 13325, offset 0, flags [DF], proto 
TCP (6), length 1492)
    192.168.1.102.ms-wbt-server > 192.168.1.101.35386: Flags [P.], cksum 
0x8387 (correct), seq 14902799:14904239, ack 133250, win 65150, options 
[nop,nop,TS val 10767 ecr 1923626542], length 1440
18:05:38.361374 IP (tos 0x0, ttl 128, id 13326, offset 0, flags [DF], proto 
TCP (6), length 1492)
    192.168.1.102.ms-wbt-server > 192.168.1.101.35386: Flags [P.], cksum 
0x8380 (correct), seq 14902799:14904239, ack 133250, win 65150, options 
[nop,nop,TS val 10774 ecr 1923626542], length 1440
18:05:39.179147 IP (tos 0x0, ttl 128, id 13327, offset 0, flags [none], proto 
UDP (17), length 255)
    192.168.1.102.netbios-dgm > 192.168.1.255.netbios-dgm: NBT UDP
PACKET(138)
18:05:39.562201 IP (tos 0x0, ttl 128, id 13328, offset 0, flags [none], proto 
TCP (6), length 576)
    192.168.1.102.ms-wbt-server > 192.168.1.101.35386: Flags [P.], cksum 
0x773b (correct), seq 14902799:14903323, ack 133250, win 65150, options 
[nop,nop,TS val 10786 ecr 1923626542], length 524
18:05:40.766390 IP (tos 0x0, ttl 128, id 13329, offset 0, flags [none], proto 
TCP (6), length 576)
    192.168.1.102.ms-wbt-server > 192.168.1.101.35386: Flags [P.], cksum 
0x772f (correct), seq 14902799:14903323, ack 133250, win 65150, options 
[nop,nop,TS val 10798 ecr 1923626542], length 524
18:05:41.968668 IP (tos 0x0, ttl 128, id 13340, offset 0, flags [DF], proto 
TCP (6), length 1492)
    192.168.1.102.ms-wbt-server > 192.168.1.101.35386: Flags [P.], cksum 
0x835c (correct), seq 14902799:14904239, ack 133250, win 65150, options 
[nop,nop,TS val 10810 ecr 1923626542], length 1440
18:05:44.374822 IP (tos 0x0, ttl 128, id 13341, offset 0, flags [DF], proto 
TCP (6), length 1492)
    192.168.1.102.ms-wbt-server > 192.168.1.101.35386: Flags [P.], cksum 
0x8344 (correct), seq 14902799:14904239, ack 133250, win 65150, options 
[nop,nop,TS val 10834 ecr 1923626542], length 1440
18:05:49.220577 IP (tos 0x0, ttl 128, id 13342, offset 0, flags [DF], proto 
TCP (6), length 1492)
    192.168.1.102.ms-wbt-server > 192.168.1.101.35386: Flags [P.], cksum 
0x8314 (correct), seq 14902799:14904239, ack 133250, win 65150, options 
[nop,nop,TS val 10882 ecr 1923626542], length 1440
18:05:54.203613 IP (tos 0x0, ttl 128, id 13343, offset 0, flags [DF], proto 
TCP (6), length 64)
    192.168.1.102.ms-wbt-server > 192.168.1.101.35386: Flags [.], cksum
0xe40c
(correct), seq 14904239:14904251, ack 133250, win 65150, options [nop,nop,TS 
val 10932 ecr 1923626542], length 12
18:05:56.370283 IP (tos 0x0, ttl 128, id 13344, offset 0, flags [none], proto 
UDP (17), length 129)
    192.168.1.102.64894 > 205.152.37.23.domain: 32816+ A? 
0.11-25073459.60001.1518.1916.3ea1.210.0.wpwqc6kfi72bqtw3sd3puh129b.avqs.mcafee.com.
(101)
18:05:57.370581 IP (tos 0x0, ttl 128, id 13345, offset 0, flags [none], proto 
UDP (17), length 129)
    192.168.1.102.64894 > 205.152.144.23.domain: 32816+ A? 
0.11-25073459.60001.1518.1916.3ea1.210.0.wpwqc6kfi72bqtw3sd3puh129b.avqs.mcafee.com.
(101)
18:05:58.615170 IP (tos 0x0, ttl 128, id 13346, offset 0, flags [none], proto 
UDP (17), length 129)
    192.168.1.102.64894 > 205.152.132.23.domain: 32816+ A? 
0.11-25073459.60001.1518.1916.3ea1.210.0.wpwqc6kfi72bqtw3sd3puh129b.avqs.mcafee.com.
(101)
18:06:00.610955 IP (tos 0x0, ttl 128, id 13347, offset 0, flags [none], proto 
UDP (17), length 129)
    192.168.1.102.64894 > 205.152.37.23.domain: 32816+ A? 
0.11-25073459.60001.1518.1916.3ea1.210.0.wpwqc6kfi72bqtw3sd3puh129b.avqs.mcafee.com.
(101)
18:06:00.611134 IP (tos 0x0, ttl 128, id 13348, offset 0, flags [none], proto 
UDP (17), length 129)
    192.168.1.102.64894 > 205.152.144.23.domain: 32816+ A? 
0.11-25073459.60001.1518.1916.3ea1.210.0.wpwqc6kfi72bqtw3sd3puh129b.avqs.mcafee.com.
(101)
18:06:00.611364 IP (tos 0x0, ttl 128, id 13349, offset 0, flags [none], proto 
UDP (17), length 129)
    192.168.1.102.64894 > 205.152.132.23.domain: 32816+ A? 
0.11-25073459.60001.1518.1916.3ea1.210.0.wpwqc6kfi72bqtw3sd3puh129b.avqs.mcafee.com.
(101)
18:06:04.618776 IP (tos 0x0, ttl 128, id 13350, offset 0, flags [none], proto 
UDP (17), length 129)
    192.168.1.102.64894 > 205.152.37.23.domain: 32816+ A? 
0.11-25073459.60001.1518.1916.3ea1.210.0.wpwqc6kfi72bqtw3sd3puh129b.avqs.mcafee.com.
(101)
18:06:04.618913 IP (tos 0x0, ttl 128, id 13351, offset 0, flags [none], proto 
UDP (17), length 129)
    192.168.1.102.64894 > 205.152.144.23.domain: 32816+ A? 
0.11-25073459.60001.1518.1916.3ea1.210.0.wpwqc6kfi72bqtw3sd3puh129b.avqs.mcafee.com.
(101)
18:06:04.619105 IP (tos 0x0, ttl 128, id 13352, offset 0, flags [none], proto 
UDP (17), length 129)
    192.168.1.102.64894 > 205.152.132.23.domain: 32816+ A? 
0.11-25073459.60001.1518.1916.3ea1.210.0.wpwqc6kfi72bqtw3sd3puh129b.avqs.mcafee.com.
(101)
18:06:09.335743 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 
192.168.1.100 tell 192.168.1.102, length 28
18:06:09.335939 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 
192.168.1.107 tell 192.168.1.102, length 28
18:06:11.708384 IP (tos 0x0, ttl 128, id 13353, offset 0, flags [none], proto 
UDP (17), length 129)
    192.168.1.102.52912 > 205.152.132.23.domain: 31175+ A? 
0.11-25073408.60081.1518.1916.3ea1.210.0.gqqknwwjjp6hcul5fw56mms3vq.avqs.mcafee.com.
(101)
18:06:12.706527 IP (tos 0x0, ttl 128, id 13354, offset 0, flags [none], proto 
UDP (17), length 129)
    192.168.1.102.52912 > 205.152.37.23.domain: 31175+ A? 
0.11-25073408.60081.1518.1916.3ea1.210.0.gqqknwwjjp6hcul5fw56mms3vq.avqs.mcafee.com.
(101)
18:06:13.706924 IP (tos 0x0, ttl 128, id 13355, offset 0, flags [none], proto 
UDP (17), length 129)
    192.168.1.102.52912 > 205.152.144.23.domain: 31175+ A? 
0.11-25073408.60081.1518.1916.3ea1.210.0.gqqknwwjjp6hcul5fw56mms3vq.avqs.mcafee.com.
(101)
18:06:15.704524 IP (tos 0x0, ttl 128, id 13356, offset 0, flags [none], proto 
UDP (17), length 129)
    192.168.1.102.52912 > 205.152.37.23.domain: 31175+ A? 
0.11-25073408.60081.1518.1916.3ea1.210.0.gqqknwwjjp6hcul5fw56mms3vq.avqs.mcafee.com.
(101)
18:06:15.704611 IP (tos 0x0, ttl 128, id 13357, offset 0, flags [none], proto 
UDP (17), length 129)
    192.168.1.102.52912 > 205.152.144.23.domain: 31175+ A? 
0.11-25073408.60081.1518.1916.3ea1.210.0.gqqknwwjjp6hcul5fw56mms3vq.avqs.mcafee.com.
(101)
18:06:15.704714 IP (tos 0x0, ttl 128, id 13358, offset 0, flags [none], proto 
UDP (17), length 129)
    192.168.1.102.52912 > 205.152.132.23.domain: 31175+ A? 
0.11-25073408.60081.1518.1916.3ea1.210.0.gqqknwwjjp6hcul5fw56mms3vq.avqs.mcafee.com.
(101)
18:06:19.703699 IP (tos 0x0, ttl 128, id 13359, offset 0, flags [none], proto 
UDP (17), length 129)
    192.168.1.102.52912 > 205.152.37.23.domain: 31175+ A? 
0.11-25073408.60081.1518.1916.3ea1.210.0.gqqknwwjjp6hcul5fw56mms3vq.avqs.mcafee.com.
(101)
18:06:19.704439 IP (tos 0x0, ttl 128, id 13360, offset 0, flags [none], proto 
UDP (17), length 129)
    192.168.1.102.52912 > 205.152.144.23.domain: 31175+ A? 
0.11-25073408.60081.1518.1916.3ea1.210.0.gqqknwwjjp6hcul5fw56mms3vq.avqs.mcafee.com.
(101)
18:06:19.704488 IP (tos 0x0, ttl 128, id 13361, offset 0, flags [none], proto 
UDP (17), length 129)
    192.168.1.102.52912 > 205.152.132.23.domain: 31175+ A? 
0.11-25073408.60081.1518.1916.3ea1.210.0.gqqknwwjjp6hcul5fw56mms3vq.avqs.mcafee.com.
(101)
18:06:37.630415 IP (tos 0x0, ttl 128, id 13362, offset 0, flags [none], proto 
UDP (17), length 131)
    192.168.1.102.64885 > 205.152.144.23.domain: 19168+ A? 
0.11-2509e051.d9f0083.1518.1916.3ea1.210.0.g32e53kra3tara52awnb4shh7t.avqs.mcafee.com.
(103)
18:06:37.659563 IP (tos 0x0, ttl 128, id 13363, offset 0, flags [none], proto 
UDP (17), length 198)
    192.168.1.102.6646 > 192.168.1.255.6646: UDP, length 170
18:06:38.628308 IP (tos 0x0, ttl 128, id 13364, offset 0, flags [none], proto 
UDP (17), length 131)
    192.168.1.102.64885 > 205.152.132.23.domain: 19168+ A? 
0.11-2509e051.d9f0083.1518.1916.3ea1.210.0.g32e53kra3tara52awnb4shh7t.avqs.mcafee.com.
(103)
18:06:39.629140 IP (tos 0x0, ttl 128, id 13368, offset 0, flags [none], proto 
UDP (17), length 131)
    192.168.1.102.64885 > 205.152.37.23.domain: 19168+ A? 
0.11-2509e051.d9f0083.1518.1916.3ea1.210.0.g32e53kra3tara52awnb4shh7t.avqs.mcafee.com.
(103)
18:06:41.625285 IP (tos 0x0, ttl 128, id 13375, offset 0, flags [none], proto 
UDP (17), length 131)
    192.168.1.102.64885 > 205.152.37.23.domain: 19168+ A? 
0.11-2509e051.d9f0083.1518.1916.3ea1.210.0.g32e53kra3tara52awnb4shh7t.avqs.mcafee.com.
(103)
18:06:41.626170 IP (tos 0x0, ttl 128, id 13376, offset 0, flags [none], proto 
UDP (17), length 131)
    192.168.1.102.64885 > 205.152.144.23.domain: 19168+ A? 
0.11-2509e051.d9f0083.1518.1916.3ea1.210.0.g32e53kra3tara52awnb4shh7t.avqs.mcafee.com.
(103)
18:06:41.626239 IP (tos 0x0, ttl 128, id 13377, offset 0, flags [none], proto 
UDP (17), length 131)
    192.168.1.102.64885 > 205.152.132.23.domain: 19168+ A? 
0.11-2509e051.d9f0083.1518.1916.3ea1.210.0.g32e53kra3tara52awnb4shh7t.avqs.mcafee.com.
(103)
18:06:45.625308 IP (tos 0x0, ttl 128, id 13378, offset 0, flags [none], proto 
UDP (17), length 131)
    192.168.1.102.64885 > 205.152.37.23.domain: 19168+ A? 
0.11-2509e051.d9f0083.1518.1916.3ea1.210.0.g32e53kra3tara52awnb4shh7t.avqs.mcafee.com.
(103)
18:06:45.626257 IP (tos 0x0, ttl 128, id 13379, offset 0, flags [none], proto 
UDP (17), length 131)
    192.168.1.102.64885 > 205.152.144.23.domain: 19168+ A? 
0.11-2509e051.d9f0083.1518.1916.3ea1.210.0.g32e53kra3tara52awnb4shh7t.avqs.mcafee.com.
(103)
18:06:45.626404 IP (tos 0x0, ttl 128, id 13380, offset 0, flags [none], proto 
UDP (17), length 131)
    192.168.1.102.64885 > 205.152.132.23.domain: 19168+ A? 
0.11-2509e051.d9f0083.1518.1916.3ea1.210.0.g32e53kra3tara52awnb4shh7t.avqs.mcafee.com.
(103)
18:06:53.015786 IP (tos 0x0, ttl 128, id 13381, offset 0, flags [none], proto 
UDP (17), length 131)
    192.168.1.102.59223 > 205.152.37.23.domain: 15713+ A? 
0.11-2507e459.d9f0083.1518.1916.3ea1.210.0.g32e53kra3tara52awnb4shh7t.avqs.mcafee.com.
(103)
18:06:54.019697 IP (tos 0x0, ttl 128, id 13382, offset 0, flags [none], proto 
UDP (17), length 131)
    192.168.1.102.59223 > 205.152.144.23.domain: 15713+ A? 
0.11-2507e459.d9f0083.1518.1916.3ea1.210.0.g32e53kra3tara52awnb4shh7t.avqs.mcafee.com.
(103)
18:06:55.019099 IP (tos 0x0, ttl 128, id 13383, offset 0, flags [none], proto 
UDP (17), length 131)
    192.168.1.102.59223 > 205.152.132.23.domain: 15713+ A? 
0.11-2507e459.d9f0083.1518.1916.3ea1.210.0.g32e53kra3tara52awnb4shh7t.avqs.mcafee.com.
(103)
18:06:57.015969 IP (tos 0x0, ttl 128, id 13384, offset 0, flags [none], proto 
UDP (17), length 131)
    192.168.1.102.59223 > 205.152.37.23.domain: 15713+ A? 
0.11-2507e459.d9f0083.1518.1916.3ea1.210.0.g32e53kra3tara52awnb4shh7t.avqs.mcafee.com.
(103)
18:06:57.016868 IP (tos 0x0, ttl 128, id 13385, offset 0, flags [none], proto 
UDP (17), length 131)
    192.168.1.102.59223 > 205.152.144.23.domain: 15713+ A? 
0.11-2507e459.d9f0083.1518.1916.3ea1.210.0.g32e53kra3tara52awnb4shh7t.avqs.mcafee.com.
(103)
18:06:57.017031 IP (tos 0x0, ttl 128, id 13386, offset 0, flags [none], proto 
UDP (17), length 131)


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

Pasi Kärkkäinen

2011-Aug-01 21:12 UTC

head link

Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

On Tue, Jul 26, 2011 at 06:20:43PM -0400, jim burns
wrote:> On Tue July 26 2011 1:00:27 PM Pasi Kärkkäinen wrote:
> > On Tue, Jul 26, 2011 at 04:39:41PM +0100, Ian Campbell wrote:
> > > On Mon, 2011-07-25 at 17:05 -0400, Pasi Kärkkäinen wrote:
> > > > On Mon, Jul 25, 2011 at 04:39:16PM -0400, jim burns wrote:
> > > > > On Mon July 25 2011 3:57:23 PM Pasi wrote:
> > > > > 
> > > > > Btw, maybe you were following the thread
''[Xen-devel] Failure to
> > > > > create HVM DomU at Xen 4.1 ( kernel 3.0.0-5-generic)
Ubuntu 11.10
> > > > > (alpha 2)''.  In my fork of that thread, I
summarized many other
> > > > > threads over the last month of people having problems
starting an
> > > > > hvm domu under xen 4.1.x. Konrad finally provided the
solution -
> > > > > 4.1.x requires the pv style vfb= line, not the
indidvidual
> > > > > variables.
> > > 
> > > Perhaps I misunderstand this stuff but AIUI the vfb= line
configures a
> > > Xen PV framebuffer device whereas the individual vnc*/sdl*/etc
variables
> > > configure the backend for the emulated VGA device. IOW they are
pretty
> > > much orthogonal and (for an HVM guest) both should work
(dependent on
> > > the required in-guest support being available). Also I''m
not sure if
> > > they can be used simultaneously, I expect they can.
> 
> > Jim: Can you please post full example of working HVM cfgfile and
> > not-working HVM cfgfile. (including any errors you get with the
latter).
> 
> > > > > Which brings up my pet peev about documentation. Even
something as
> > > > > simple as updating the xmexample files in the /etc/xen
tree would
> > > > > have avoided this problem for so many people. Since you
lurk around
> > > > > in Xen Devel, maybe you can make people aware of the
problem?
> > > 
> > > If you find areas where xm* are not accurate than patches would
be very
> > > much appreciated.
> 
> Sure, thanx. The following worked from xen 3.2.x to 4.0.1. w/o the vfb=
line.
> Starting with xen 4.1.x, w/o the vfb= line, the vnc window immediately
exits
> without even displaying the bochs bios, and qemu-dm exits also. Not till 
> adding the vfb= line does qemu-dm come up properly, as in previous xen 
> versions. The qemu-dm-winxp.log file is not very informative, as it
basically
> doesn''t change w/ or w/o the vfb= line. (Except a full guest boot
adds lines
> that start with ''Unknown PV product 2'' (gplpv) and end
with ''Time offset''.)
> 
Interesting. Have others seen this problem? 

I don''t think vfb-line is supposed to be needed with HVM guests..

> The ''xen be: console-0:'' errors only occur when you use
''xm create'', not ''xl
> create''. You''ll notice I''ve gone back to using a
xenbr0 bridge, setup by the
> fedora (15) ifcfg- files. Xl won''t put tapn.0 on the eth0 bridge,
so the guest
> comes up w/o a functioning network, even tho'' the vif= line
previously
> explicitly set bridge=eth0. Now it specifies bridge=xenbr0. The error with
''xl
> create'' and no vfb= line is even less informative. With
''xm create'', xend.log
> properly reports that xen refused to restart the guest to prevent loops - 
> guest is restarting too fast. With ''xl create'' xl just
goes into an infinite
> loop, spawning child xls and qemu-dms that immediately exit.
> 
> No where in the xmexample.hvm and similar files is vfb= mentioned. Lots of 
> people over the last month have been having trouble starting their hvm 
> domains, until Konrad mentioned in the thread mentioned above to add the
vfb=
> line.
> 
Yep.


-- Pasi

> winxp config file: (python code commented out to keep xl happy)
> 
> #import os, re
> #arch = os.uname()[4]
> #if re.search(''64'', arch):
> #    arch_libdir = ''lib64''
> #else:
> #    arch_libdir = ''lib''
> 
> name = "winxp"
> builder=''hvm''
> memory = "512"
> uuid = "6c7de04e-df10-caa8-bb2a-8368246225c1"
> #ostype = "hvm" (no longer needed?)
> on_reboot = "restart"
> on_crash = "restart"
> on_poweroff = "destroy"
> vcpus = "2"
> viridian=1
> #
> #kernel = "/usr/lib/xen/boot/hvmloader"
> kernel = "hvmloader"
> acpi=1
> apic=1
> boot= "cda"
> # New stuff
> #device_model = ''/usr/'' + arch_libdir +
''/xen/bin/qemu-dm''
> #device_model = ''/usr/lib/xen/bin/qemu-dm''
> device_model = ''qemu-dm''
> #
> keymap=''en-us''
> localtime=1
> #rtc_timeoffset=-14400
> #rtc_timeoffset=-18000
> pae=1
> serial=''pty''
> #serial = "/dev/ttyS0"
> #   enable sound card support, [sb16|es1370|all|..,..], default none
> soundhw=''es1370''
> # enable stdvga, default = 0 (use cirrus logic device model)
> #stdvga=1
> videoram=4  # also necessary to keep xl happy, even tho the default is 8
> stdvga=0
> #usbdevice="mouse"
> usbdevice="tablet"
> xen_extended_power_mgmt = 0
> #
> #disk=[ ''tap2:aio:/var/lib/xen/images/winxp,hda,w'', 
> ''phy:/dev/cdrom,hdc:cdrom,r'' ]
> disk=[ ''phy:/dev/disk/by-path/ip-192.168.1.101:3260-iscsi-
> iqn.2001-04.com.Dell4550-iqn.2009-09.net.bellsouth.sda:041b7d3f-b008-4367-
> b1f2-b4799d15e4cd-lun-1,hda,w'',
''phy:/dev/cdrom,hdc:cdrom,r'' ]
> #
> #vif = [ ''mac=00:16:3e:23:1d:36, script=vif-bridge, bridge =
eth0'' ]
> vif = [ ''mac=00:16:3e:23:1d:36, type=ioemu, script=vif-bridge,
bridge =
> xenbr0'' ]
> #
> sdl=0
> vfb = [ ''vnc=1, vnclisten=0.0.0.0, vncunused=0, vncdisplay=3,
vncpasswd= '']
> vnc=1
> vnclisten="0.0.0.0"
> #vnclisten="192.168.1.0" ( is there any way to do this? use to
work in xen
> 3.2)
> # set VNC display number, default = domid
> vncdisplay=3
> # try to find an unused port for the VNC server, default = 1
> vncunused=0
> vncviewer=1
> vncconsole=1
> monitor=1
> vncpasswd=""
> 
> qemu-dm-winxp.log:
> 
> domid: 1
> config qemu network with xen bridge for  tap1.0 xenbr0
> Using file /dev/disk/by-path/ip-192.168.1.101:3260-iscsi-
> iqn.2001-04.com.Dell4550-iqn.2009-09.net.bellsouth.sda:041b7d3f-b008-4367-
> b1f2-b4799d15e4cd-lun-1 in read-write mode
> Using file /dev/cdrom in read-only mode
> Watching /local/domain/0/device-model/1/logdirty/cmd
> Watching /local/domain/0/device-model/1/command
> Watching /local/domain/1/cpu
> char device redirected to /dev/pts/5
> qemu_map_cache_init nr_buckets = 10000 size 4194304
> shared page at pfn feffd
> buffered io page at pfn feffb
> Guest uuid = 6c7de04e-df10-caa8-bb2a-8368246225c1
> Time offset set 72000
> char device redirected to /dev/pts/6
> xen be: console-0: xen be: console-0: initialise() failed
> initialise() failed
> populating video RAM at ff000000
> mapping video RAM from ff000000
> Register xen platform.
> Done register platform.
> platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw 
> state.
> xs_read(/local/domain/0/device-model/1/xen_extended_power_mgmt): read error
> xs_read(): vncpasswd get error. /vm/6c7de04e-df10-caa8-
> bb2a-8368246225c1/vncpasswd.
> medium change watch on `hdc'' (index: 1): /dev/cdrom
> I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
> Log-dirty: no command yet.
> I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
> xen be: console-0: xen be: console-0: initialise() failed
> initialise() failed
> vcpu-set: watch node error.
> xen be: console-0: xen be: console-0: initialise() failed
> initialise() failed
> xs_read(/local/domain/1/log-throttling): read error
> qemu: ignoring not-understood drive
`/local/domain/1/log-throttling''
> medium change watch on `/local/domain/1/log-throttling'' - unknown
device,
> ignored
> xen be: console-0: xen be: console-0: initialise() failed
> initialise() failed
> cirrus vga map change while on lfb mode
> mapping vram to f0000000 - f0400000
> platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw 
> state.
> platform_fixed_ioport: changed ro/rw state of ROM memory area. now is ro 
> state.
> Unknown PV product 2 loaded in guest
> PV driver build 1
> region type 1 at [c100,c200).
> region type 0 at [f3001000,f3001100).
> squash iomem [f3001000, f3001100).
> Time offset set -14400, added offset -86400
> Time offset set -14398, added offset 2
> Time offset set 2, added offset 14400
> Time offset set 1, added offset -1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

jim burns

2011-Aug-01 23:06 UTC

head link

[Xen-users] Re: Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

Pasi said:
(sorry - my new kmail is having trouble quoting text)> Interesting. Have others seen this problem? 
In the thread I mention at the head of this thread - ''[Xen-devel]
Failure to
create HVM DomU at Xen 4.1 ( kernel 3.0.0-5-generic) Ubuntu 11.10 (alpha
2)'' -
I summarize several threads from people that have had problems starting hvm 
domu''s on xen 4.1.x. They all have similar log output to mine, namely:

qemu-dm:

xen be: console-0: xen be: console-0: initialise() failed

& hypervisor.log (xm dmesg) reports an MMIO error. The fix was either to 
upgrade to xen 4.2 unstable, or downgrade to 4.0.x - at least until Konrad 
proposed adding the vfb= line, in that same thread in Xen-users. This made  
4.1.x usable, and made the MMIO error go away (but not the ''xen
be:'' error).
Thus, there is only one other person I know benefited from that advice - 	
bderzhavets. However, I''ll repeat the list of other threads in
Xen-users of
people with hvm problems:
> According to several threads, such as mine last month -
''[Xen-users]
> Working with Fedora 15 & systemd'' - and  ''[Xen-users]
Problems
> with HVM after upgrade from 4.0.1 to 4.1.1'', and a private
communication
with > t.wagner in ''[Xen-users] XEN-4.1.1 and linux kernel
3.0-rc5'', and finally
> ''[Xen-users] Re: Trouble starting HVM domU with Linux 3.0.0 and
Xen 4.1.1'',
and one I omitted, from the beginning of July: ''[Xen-users] Starting
basic HVM
-- where am I going wrong?'' from Sam Mulvey.
> I don''t think vfb-line is supposed to be needed with HVM guests..
It hasn''t been needed since xen 3.2.x (maybe even 3.0.x) until 4.1.x,
and
again reportedly not needed for 4.2 unstable ( I haven''t worked with
it, yet).

Thank you for continuing to take an interest in this.

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

Boris Derzhavets

2011-Aug-02 05:04 UTC

head link

Re: [Xen-users] Re: Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

> Thus, there is only one other person I know benefited from that advice -
   
> bderzhavets. However, I''ll repeat the list of other threads in
Xen-users of
> people with hvm problems:
No i didn''t. There was long thread regarding GCC 4.6 problem when
building "hvmloader" ( F15, U 11.10 both has 4.6)

1. Stefano noticed that problem was GCC 4.6 when building "hvmloader"
2. Official fix was in the same thread
   http://xenbits.xen.org/hg/staging/xen-4.1-testing.hg/rev/1976adbf2b80.
Been back ported to 4.1.1 is resolves the issue.

There is build (PPA on Oneiric) and i believe xen-4.1.1-(X).fc16.src.rpm
already has this patch as well. Pasi knows it better. 
Regarding Ubuntu 11.10 :-

https://launchpad.net/~bderzhavets/+archive/xen-4.1.1

Boris

--- On Mon, 8/1/11, jim burns <jim_burn@bellsouth.net> wrote:

From: jim burns <jim_burn@bellsouth.net>
Subject: [Xen-users] Re: Re: [Xen-devel] Updating Xen 4.1.x xmexamples files
(vfb line required for HVM guests)
To: "Pasi Kärkkäinen" <pasik@iki.fi>
Cc: "xen-devel@lists.xensource.com"
<xen-devel@lists.xensource.com>, "Ian Campbell"
<Ian.Campbell@citrix.com>, "xen-users@lists.xensource.com"
<xen-users@lists.xensource.com>
Date: Monday, August 1, 2011, 7:06 PM

Pasi said:
(sorry - my new kmail is having trouble quoting text)> Interesting. Have others seen this problem? 
In the thread I mention at the head of this thread - ''[Xen-devel]
Failure to
create HVM DomU at Xen 4.1 ( kernel 3.0.0-5-generic) Ubuntu 11.10 (alpha
2)'' -
I summarize several threads from people that have had problems starting hvm 
domu''s on xen 4.1.x. They all have similar log output to mine, namely:

qemu-dm:

xen be: console-0: xen be: console-0: initialise() failed

& hypervisor.log (xm dmesg) reports an MMIO error. The fix was either to 
upgrade to xen 4.2 unstable, or downgrade to 4.0.x - at least until Konrad 
proposed adding the vfb= line, in that same thread in Xen-users. This made  
4.1.x usable, and made the MMIO error go away (but not the ''xen
be:'' error).
Thus, there is only one other person I know benefited from that advice -     
bderzhavets. However, I''ll repeat the list of other threads in
Xen-users of
people with hvm problems:
> According to several threads, such as mine last month -
''[Xen-users]
> Working with Fedora 15 & systemd'' - and  ''[Xen-users]
Problems
> with HVM after upgrade from 4.0.1 to 4.1.1'', and a private
communication
with > t.wagner in ''[Xen-users] XEN-4.1.1 and linux kernel
3.0-rc5'', and finally
> ''[Xen-users] Re: Trouble starting HVM domU with Linux 3.0.0 and
Xen 4.1.1'',
and one I omitted, from the beginning of July: ''[Xen-users] Starting
basic HVM
-- where am I going wrong?'' from Sam Mulvey.
> I don''t think vfb-line is supposed to be needed with HVM guests..
It hasn''t been needed since xen 3.2.x (maybe even 3.0.x) until 4.1.x,
and
again reportedly not needed for 4.2 unstable ( I haven''t worked with
it, yet).

Thank you for continuing to take an interest in this.

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


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

jim burns

2011-Aug-02 09:38 UTC

head link

Re: [Xen-users] Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

> Thus, there is only one other person I know benefited from that advice -
> bderzhavets. However, I''ll repeat the list of other threads in
Xen-users of
> people with hvm problems:
No i didn''t. There was long thread regarding GCC 4.6 problem when
building "hvmloader" ( F15, U 11.10 both has 4.6)

1. Stefano noticed that problem was GCC 4.6 when building "hvmloader"
2. Official fix was in the same thread
   http://xenbits.xen.org/hg/staging/xen-4.1-testing.hg/rev/1976adbf2b80.
Been back ported to 4.1.1 is resolves the issue.

There is build (PPA on Oneiric) and i believe xen-4.1.1-(X).fc16.src.rpm
already has this patch as well. Pasi knows it better. 
Regarding Ubuntu 11.10 :-

https://launchpad.net/~bderzhavets/+archive/xen-4.1.1
----------------------------------------------------------

Ok - thanx for letting us know. I''m a little surprised at fedora - they
are
usually very good at back-porting stuff.

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

Boris Derzhavets

2011-Aug-02 13:07 UTC

head link

Re: [Xen-users] Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

I''ve installed  xen-4.1.1-1.fc16.src.rpm.  It doesn''t contain
mentioned patch.
Added patch as raw content of 

   http://xenbits.xen.org/hg/staging/xen-4.1-testing.hg/rev/1976adbf2b80 

and rebuilt xen-4.1.1-2.fc15.src.rpm.

It''s ptetty much standard procedure , if that''s the only one
issue in place.
But , i don''t have kernel 3.0 on F15 so i cannot test.

This back port works on on Ubuntu 11.10 with 3.0.0-7-generic.

Boris.

--- On Tue, 8/2/11, jim burns <jim_burn@bellsouth.net> wrote:

From: jim burns <jim_burn@bellsouth.net>
Subject: Re: [Xen-users] Re: [Xen-devel] Updating Xen 4.1.x xmexamples files
(vfb line required for HVM guests)
To: "Boris Derzhavets" <bderzhavets@yahoo.com>
Cc: "xen-devel@lists.xensource.com"
<xen-devel@lists.xensource.com>, "Ian Campbell"
<Ian.Campbell@citrix.com>, "Pasi Kärkkäinen"
<pasik@iki.fi>, "xen-users@lists.xensource.com"
<xen-users@lists.xensource.com>
Date: Tuesday, August 2, 2011, 5:38 AM
> Thus, there is only one other person I know benefited from that advice - 

> bderzhavets. However, I''ll repeat the list of other threads in
Xen-users of
> people with hvm problems:
No i didn''t. There was long thread regarding GCC 4.6 problem when
building "hvmloader" ( F15, U 11.10 both has 4.6)

1. Stefano noticed that problem was GCC 4.6 when building "hvmloader"
2. Official fix was in the same thread
   http://xenbits.xen.org/hg/staging/xen-4.1-testing.hg/rev/1976adbf2b80.
Been back ported to 4.1.1 is resolves the issue.

There is build (PPA on Oneiric) and i believe xen-4.1.1-(X).fc16.src.rpm
already has this patch as well. Pasi knows it better. 
Regarding Ubuntu 11.10 :-

https://launchpad.net/~bderzhavets/+archive/xen-4.1.1
----------------------------------------------------------

Ok - thanx for letting us know. I''m a little surprised at fedora - they
are
usually very good at back-porting stuff.

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

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

Pasi Kärkkäinen

2011-Aug-02 17:13 UTC

head link

Re: [Xen-users] Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

On Tue, Aug 02, 2011 at 05:38:18AM -0400, jim burns
wrote:> > Thus, there is only one other person I know benefited from that advice
-
> > bderzhavets. However, I''ll repeat the list of other threads
in Xen-users of
> > people with hvm problems:
> 
> No i didn''t. There was long thread regarding GCC 4.6 problem when
> building "hvmloader" ( F15, U 11.10 both has 4.6)
> 
> 1. Stefano noticed that problem was GCC 4.6 when building
"hvmloader"
> 2. Official fix was in the same thread
>    http://xenbits.xen.org/hg/staging/xen-4.1-testing.hg/rev/1976adbf2b80.
> Been back ported to 4.1.1 is resolves the issue.
> 
> There is build (PPA on Oneiric) and i believe xen-4.1.1-(X).fc16.src.rpm
> already has this patch as well. Pasi knows it better. 
> Regarding Ubuntu 11.10 :-
> 
> https://launchpad.net/~bderzhavets/+archive/xen-4.1.1
> ----------------------------------------------------------
> 
> Ok - thanx for letting us know. I''m a little surprised at fedora -
they are
> usually very good at back-porting stuff.
>
Yep, Fedora already has gcc 4.6 patched Xen, it''s version 4.1.1-2.fc15
in fedora 15 updates.

(for example
ftp://ftp.funet.fi/pub/mirrors/fedora.redhat.com/pub/fedora/linux/updates/15/SRPMS/xen-4.1.1-2.fc15.src.rpm)

-- Pasi


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

Pasi Kärkkäinen

2011-Aug-02 17:13 UTC

head link

Re: [Xen-users] Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

On Tue, Aug 02, 2011 at 06:07:39AM -0700, Boris Derzhavets
wrote:>   I''ve installed  xen-4.1.1-1.fc16.src.rpm.  It doesn''t
contain mentioned patch.
>   Added patch as raw content of
> 
Fedora 15 updates has xen-4.1.1-2.fc15 which has the cgc 4.6 bugfix patch
included.

-- Pasi
>     
[1]http://xenbits.xen.org/hg/staging/xen-4.1-testing.hg/rev/1976adbf2b80
> 
>   and rebuilt xen-4.1.1-2.fc15.src.rpm.
> 
>   It''s ptetty much standard procedure , if that''s the
only one issue in place.
>   But , i don''t have kernel 3.0 on F15 so i cannot test.
> 
>   This back port works on on Ubuntu 11.10 with 3.0.0-7-generic.
> 
>   Boris.
> 
>   --- On Tue, 8/2/11, jim burns <jim_burn@bellsouth.net> wrote:
> 
>     From: jim burns <jim_burn@bellsouth.net>
>     Subject: Re: [Xen-users] Re: [Xen-devel] Updating Xen 4.1.x xmexamples
files
>     (vfb line required for HVM guests)
>     To: "Boris Derzhavets" <bderzhavets@yahoo.com>
>     Cc: "xen-devel@lists.xensource.com"
<xen-devel@lists.xensource.com>, "Ian
>     Campbell" <Ian.Campbell@citrix.com>, "Pasi
Kärkkäinen" <pasik@iki.fi>,
>     "xen-users@lists.xensource.com"
<xen-users@lists.xensource.com>
>     Date: Tuesday, August 2, 2011, 5:38 AM
> 
>     > Thus, there is only one other person I know benefited from that
advice -
> 
>     > bderzhavets. However, I''ll repeat the list of other
threads in Xen-users
>     of
>     > people with hvm problems:
> 
>     No i didn''t. There was long thread regarding GCC 4.6 problem
when
>     building "hvmloader" ( F15, U 11.10 both has 4.6)
> 
>     1. Stefano noticed that problem was GCC 4.6 when building
"hvmloader"
>     2. Official fix was in the same thread
>       
[2]http://xenbits.xen.org/hg/staging/xen-4.1-testing.hg/rev/1976adbf2b80.
>     Been back ported to 4.1.1 is resolves the issue.
> 
>     There is build (PPA on Oneiric) and i believe
xen-4.1.1-(X).fc16.src.rpm
>     already has this patch as well. Pasi knows it better.
>     Regarding Ubuntu 11.10 :-
> 
>     [3]https://launchpad.net/~bderzhavets/+archive/xen-4.1.1
>     ----------------------------------------------------------
> 
>     Ok - thanx for letting us know. I''m a little surprised at
fedora - they are
>     usually very good at back-porting stuff.
> 
>     _______________________________________________
>     Xen-users mailing list
>     [4]Xen-users@lists.xensource.com
>     [5]http://lists.xensource.com/xen-users
> 
> References
> 
>    Visible links
>    1. http://xenbits.xen.org/hg/staging/xen-4.1-testing.hg/rev/1976adbf2b80
>    2. http://xenbits.xen.org/hg/staging/xen-4.1-testing.hg/rev/1976adbf2b80
>    3. https://launchpad.net/%7Ebderzhavets/+archive/xen-4.1.1
>    4. file:///mc/compose?to=Xen-users@lists.xensource.com
>    5. http://lists.xensource.com/xen-users
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Konrad Rzeszutek Wilk

2011-Aug-02 17:17 UTC

head link

Re: [Xen-users] Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

On Tue, Aug 02, 2011 at 06:07:39AM -0700, Boris Derzhavets
wrote:> I''ve installed  xen-4.1.1-1.fc16.src.rpm.  It doesn''t
contain mentioned patch.
> Added patch as raw content of 
> 
>    http://xenbits.xen.org/hg/staging/xen-4.1-testing.hg/rev/1976adbf2b80 
> 
> and rebuilt xen-4.1.1-2.fc15.src.rpm.
> 
> It''s ptetty much standard procedure , if that''s the only
one issue in place.
> But , i don''t have kernel 3.0 on F15 so i cannot test.
> 
> This back port works on on Ubuntu 11.10 with 3.0.0-7-generic.
> 
> Boris.
> Hey M A,

Could you backport that patch in your src rpm, please?

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

M A Young

2011-Aug-02 17:37 UTC

head link

Re: [Xen-users] Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

On Tue, 2 Aug 2011, Konrad Rzeszutek Wilk wrote:
> On Tue, Aug 02, 2011 at 06:07:39AM -0700, Boris Derzhavets wrote:
>> I''ve installed  xen-4.1.1-1.fc16.src.rpm.  It doesn''t
contain mentioned patch.
>> Added patch as raw content of
>>
>>   
http://xenbits.xen.org/hg/staging/xen-4.1-testing.hg/rev/1976adbf2b80
It already is in xen-4.1.1-2.fc16 and xen-4.1.1-2.fc15 .

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

M A Young

2011-Aug-02 17:42 UTC

head link

Re: [Xen-users] Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

On Tue, 2 Aug 2011, Konrad Rzeszutek Wilk wrote:
> On Tue, Aug 02, 2011 at 06:07:39AM -0700, Boris Derzhavets wrote:
>> I''ve installed  xen-4.1.1-1.fc16.src.rpm.  It doesn''t
contain mentioned patch.
>> Added patch as raw content of
>>
>>   
http://xenbits.xen.org/hg/staging/xen-4.1-testing.hg/rev/1976adbf2b80
>>
>> and rebuilt xen-4.1.1-2.fc15.src.rpm.
>>
>> It''s ptetty much standard procedure , if that''s the
only one issue in place.
>> But , i don''t have kernel 3.0 on F15 so i cannot test.
F15 has just released a 2.6.40 kernel, which is a rebadged 3.0 kernel that 
has been renamed to avoid problems caused by the the change of naming 
scheme in a released version of Fedora.

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

Boris Derzhavets

2011-Aug-02 18:34 UTC

head link

Re: [Xen-users] Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

After yum install xen my environment :-

[root@fedora15 ~]# uname -a
Linux fedora15 2.6.40-4.fc15.x86_64 #1 SMP Fri Jul 29 18:46:53 UTC 2011 x86_64
x86_64 x86_64 GNU/Linux

[root@fedora15 ~]# rpm -qa|grep xen
xen-runtime-4.1.1-2.fc15.x86_64
xen-libs-4.1.1-2.fc15.x86_64
xen-4.1.1-2.fc15.x86_64
xen-licenses-4.1.1-2.fc15.x86_64
xen-hypervisor-4.1.1-2.fc15.x86_64

Attempt to load via grub entry :-

title Xen 4.1.1 Fedora (2.6.40-4.fc15.x86_64)
        root (hd1,0)
        kernel  /xen-4.1.1.gz
        module  /vmlinuz-2.6.40-4.fc15.x86_64 ro
root=/dev/mapper/vg_fedora15-lv_root nomodeset  LANG=en_US.UTF-8
SYSFONT=latarcyrheb-sun16 KEYTABLE=us rhgb
        module  /initramfs-2.6.40-4.fc15.x86_64.img

is just the same as with rebuilt   kernel 3.0.0-1.fc15.x86_64 (I''ve
already did it).
Black screen and login screen.

Boris.






--- On Tue, 8/2/11, M A Young <m.a.young@durham.ac.uk> wrote:

From: M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-users] Re: [Xen-devel] Updating Xen 4.1.x xmexamples files
(vfb line required for HVM guests)
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
Cc: "Boris Derzhavets" <bderzhavets@yahoo.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
"Ian Campbell" <Ian.Campbell@citrix.com>, "jim burns"
<jim_burn@bellsouth.net>
Date: Tuesday, August 2, 2011, 1:42 PM

On Tue, 2 Aug 2011, Konrad Rzeszutek Wilk wrote:
> On Tue, Aug 02, 2011 at 06:07:39AM -0700, Boris Derzhavets wrote:
>> I''ve installed  xen-4.1.1-1.fc16.src.rpm.  It doesn''t
contain mentioned patch.
>> Added patch as raw content of
>>
>>   
http://xenbits.xen.org/hg/staging/xen-4.1-testing.hg/rev/1976adbf2b80
>>
>> and rebuilt xen-4.1.1-2.fc15.src.rpm.
>>
>> It''s ptetty much standard procedure , if that''s the
only one issue in place.
>> But , i don''t have kernel 3.0 on F15 so i cannot test.
F15 has just released a 2.6.40 kernel, which is a rebadged 3.0 kernel that 
has been renamed to avoid problems caused by the the change of naming 
scheme in a released version of Fedora.

     Michael Young
-----Inline Attachment Follows-----

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

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

Boris Derzhavets

2011-Aug-02 18:39 UTC

head link

Re: [Xen-users] Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

Sorry,

Black screen and  NO GDM login 

Boris

--- On Tue, 8/2/11, Boris Derzhavets <bderzhavets@yahoo.com> wrote:

From: Boris Derzhavets <bderzhavets@yahoo.com>
Subject: Re: [Xen-users] Re: [Xen-devel] Updating Xen 4.1.x xmexamples files
(vfb line required for HVM guests)
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>, "M A
Young" <m.a.young@durham.ac.uk>
Cc: "jim burns" <jim_burn@bellsouth.net>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
"Ian Campbell" <Ian.Campbell@citrix.com>
Date: Tuesday, August 2, 2011, 2:34 PM

After yum install xen my environment :-

[root@fedora15 ~]# uname -a
Linux fedora15 2.6.40-4.fc15.x86_64 #1 SMP Fri Jul 29 18:46:53 UTC 2011 x86_64
x86_64 x86_64 GNU/Linux

[root@fedora15 ~]# rpm -qa|grep xen
xen-runtime-4.1.1-2.fc15.x86_64
xen-libs-4.1.1-2.fc15.x86_64
xen-4.1.1-2.fc15.x86_64
xen-licenses-4.1.1-2.fc15.x86_64
xen-hypervisor-4.1.1-2.fc15.x86_64

Attempt to load via grub entry :-

title Xen 4.1.1 Fedora (2.6.40-4.fc15.x86_64)
        root (hd1,0)
        kernel  /xen-4.1.1.gz
        module  /vmlinuz-2.6.40-4.fc15.x86_64 ro
root=/dev/mapper/vg_fedora15-lv_root nomodeset  LANG=en_US.UTF-8
SYSFONT=latarcyrheb-sun16 KEYTABLE=us rhgb
       
 module  /initramfs-2.6.40-4.fc15.x86_64.img

is just the same as with rebuilt   kernel 3.0.0-1.fc15.x86_64 (I''ve
already did it).
Black screen and login screen.

Boris.






--- On Tue, 8/2/11, M A Young <m.a.young@durham.ac.uk> wrote:

From: M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-users] Re: [Xen-devel] Updating Xen 4.1.x xmexamples files
(vfb line required for HVM guests)
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
Cc: "Boris Derzhavets" <bderzhavets@yahoo.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
"Ian Campbell" <Ian.Campbell@citrix.com>, "jim burns"
<jim_burn@bellsouth.net>
Date:
 Tuesday, August 2, 2011, 1:42 PM

On Tue, 2 Aug 2011, Konrad Rzeszutek Wilk wrote:
> On Tue, Aug 02, 2011 at 06:07:39AM -0700, Boris Derzhavets wrote:
>> I''ve installed  xen-4.1.1-1.fc16.src.rpm.  It doesn''t
contain mentioned patch.
>> Added patch as raw content of
>>
>>   
http://xenbits.xen.org/hg/staging/xen-4.1-testing.hg/rev/1976adbf2b80
>>
>> and rebuilt xen-4.1.1-2.fc15.src.rpm.
>>
>> It''s ptetty much standard procedure , if that''s the
only one issue in place.
>> But , i don''t have kernel 3.0 on F15 so i cannot test.
F15 has just released a 2.6.40 kernel, which is a rebadged 3.0 kernel that 
has been renamed to avoid problems caused by the the change of naming 
scheme in a released version of
 Fedora.

     Michael Young
-----Inline Attachment Follows-----

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
-----Inline Attachment Follows-----

_______________________________________________
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

Konrad Rzeszutek Wilk

2011-Aug-02 19:03 UTC

head link

Re: [Xen-users] Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

On Tue, Aug 02, 2011 at 11:39:44AM -0700, Boris Derzhavets
wrote:> Sorry,
> 
> Black screen and  NO GDM login 
What does all of this have to do with the title? Is this your guest? If this is
for dom0
issue please create a new email thread.

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

Boris Derzhavets

2011-Aug-02 19:37 UTC

head link

[Xen-devel] Attempt to load kernel 2.6.40-4.fc15.x86_64 under Xen 4.1.1 on Fedora 15

After yum install xen my environment on F15 is :-

[root@fedora15 ~]# uname -a
Linux fedora15 2.6.40-4.fc15.x86_64 #1 SMP Fri Jul 29 18:46:53 UTC 2011 x86_64
x86_64 x86_64 GNU/Linux

[root@fedora15 ~]# rpm -qa|grep xen
xen-runtime-4.1.1-2.fc15.x86_64
xen-libs-4.1.1-2.fc15.x86_64
xen-4.1.1-2.fc15.x86_64
xen-licenses-4.1.1-2.fc15.x86_64
xen-hypervisor-4.1.1-2.fc15.x86_64

Attempt to load via grub entry :-

title Xen 4.1.1 Fedora (2.6.40-4.fc15.x86_64)
        root (hd1,0)
        kernel  /xen-4.1.1.gz
        module  /vmlinuz-2.6.40-4.fc15.x86_64 ro
root=/dev/mapper/vg_fedora15-lv_root nomodeset  LANG=en_US.UTF-8
SYSFONT=latarcyrheb-sun16 KEYTABLE=us rhgb
        module  /initramfs-2.6.40-4.fc15.x86_64.img

is just the same as with rebuilt  kernel 3.0.0-1.fc15.x86_64 . I''ve
already done it.

Black screen and no GDM login screen.

Boris.




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

Pasi Kärkkäinen

2011-Aug-02 19:55 UTC

head link

Re: [Xen-devel] Attempt to load kernel 2.6.40-4.fc15.x86_64 under Xen 4.1.1 on Fedora 15

On Tue, Aug 02, 2011 at 12:37:19PM -0700, Boris Derzhavets
wrote:>    After yum install xen my environment on F15 is :-
> 
>    [root@fedora15 ~]# uname -a
>    Linux fedora15 2.6.40-4.fc15.x86_64 #1 SMP Fri Jul 29 18:46:53 UTC 2011
>    x86_64 x86_64 x86_64 GNU/Linux
> 
>    [root@fedora15 ~]# rpm -qa|grep xen
>    xen-runtime-4.1.1-2.fc15.x86_64
>    xen-libs-4.1.1-2.fc15.x86_64
>    xen-4.1.1-2.fc15.x86_64
>    xen-licenses-4.1.1-2.fc15.x86_64
>    xen-hypervisor-4.1.1-2.fc15.x86_64
> 
>    Attempt to load via grub entry :-
> 
>    title Xen 4.1.1 Fedora (2.6.40-4.fc15.x86_64)
>            root (hd1,0)
>            kernel  /xen-4.1.1.gz
>            module  /vmlinuz-2.6.40-4.fc15.x86_64 ro
>    root=/dev/mapper/vg_fedora15-lv_root nomodeset  LANG=en_US.UTF-8
>    SYSFONT=latarcyrheb-sun16 KEYTABLE=us rhgb
>            module  /initramfs-2.6.40-4.fc15.x86_64.img
> 
>    is just the same as with rebuilt  kernel 3.0.0-1.fc15.x86_64 .
I''ve
>    already done it.
> 
>    Black screen and no GDM login screen.
> 
3.0.0 does not yet have vga text console support, 
although kms should work at least on some graphics cards.

Try setting up a serial console and see where it fails / what it''s
doing.

-- Pasi


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

jim burns

2011-Aug-02 21:57 UTC

head link

Re: Re: [Xen-users] Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

M A Young said:> On Tue, 2 Aug 2011, Konrad Rzeszutek Wilk wrote:
>> On Tue, Aug 02, 2011 at 06:07:39AM -0700, Boris Derzhavets wrote:
>>> I''ve installed  xen-4.1.1-1.fc16.src.rpm.  It
doesn''t contain mentioned
patch.>>> Added patch as raw content of
>>>
>>>   
http://xenbits.xen.org/hg/staging/xen-4.1-testing.hg/rev/1976adbf2b80
> It already is in xen-4.1.1-2.fc16 and xen-4.1.1-2.fc15 .
>         Michael Young
[516] > rpm -q --last xen 
xen-4.1.1-2.fc16                              Fri 22 Jul 2011 10:24:57 PM EDT

Huh!!! I guess I never tried removing the vfb= line since I got this update. I 
can verify that the vfb= line is no longer necessary. Sorry for making so much 
noise about this problem. (Also odd that the vfb= line was a temporary fix!)

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

Boris Derzhavets

2011-Aug-03 00:55 UTC

head link

[Xen-users] Re: [Xen-devel] Attempt to load kernel 2.6.40-4.fc15.x86_64 under Xen 4.1.1 on Fedora 15

1. Ubuntu''s 11.10 kernel 3.0.0-7-generic  under stock Xen 4.1.1
(Ubuntu) works fine on the same box. ( miltibooting)


2. Video Radeon HD4650.  Xen 4.0.1 & 2.6.32.X worked fine also.


Boris.


--- On Tue, 8/2/11, Pasi Kärkkäinen <pasik@iki.fi> wrote:

From: Pasi Kärkkäinen <pasik@iki.fi>
Subject: Re: [Xen-devel] Attempt to load kernel 2.6.40-4.fc15.x86_64 under Xen
4.1.1 on Fedora 15
To: "Boris Derzhavets" <bderzhavets@yahoo.com>
Cc: "xen-devel@lists.xensource.com"
<xen-devel@lists.xensource.com>, "Ian Campbell"
<Ian.Campbell@citrix.com>, "jim burns"
<jim_burn@bellsouth.net>, "Konrad Rzeszutek Wilk"
<konrad.wilk@oracle.com>, "M A Young"
<m.a.young@durham.ac.uk>, "xen-users@lists.xensource.com"
<xen-users@lists.xensource.com>
Date: Tuesday, August 2, 2011, 3:55 PM

On Tue, Aug 02, 2011 at 12:37:19PM -0700, Boris Derzhavets
wrote:>    After yum install xen my environment on F15 is :-
> 
>    [root@fedora15 ~]# uname -a
>    Linux fedora15 2.6.40-4.fc15.x86_64 #1 SMP Fri Jul 29 18:46:53 UTC 2011
>    x86_64 x86_64 x86_64 GNU/Linux
> 
>    [root@fedora15 ~]# rpm -qa|grep xen
>    xen-runtime-4.1.1-2.fc15.x86_64
>    xen-libs-4.1.1-2.fc15.x86_64
>    xen-4.1.1-2.fc15.x86_64
>    xen-licenses-4.1.1-2.fc15.x86_64
>    xen-hypervisor-4.1.1-2.fc15.x86_64
> 
>    Attempt to load via grub entry :-
> 
>    title Xen 4.1.1 Fedora (2.6.40-4.fc15.x86_64)
>            root (hd1,0)
>            kernel  /xen-4.1.1.gz
>            module  /vmlinuz-2.6.40-4.fc15.x86_64 ro
>    root=/dev/mapper/vg_fedora15-lv_root nomodeset  LANG=en_US.UTF-8
>    SYSFONT=latarcyrheb-sun16 KEYTABLE=us rhgb
>            module  /initramfs-2.6.40-4.fc15.x86_64.img
> 
>    is just the same as with rebuilt  kernel 3.0.0-1.fc15.x86_64 .
I''ve
>    already done it.
> 
>    Black screen and no GDM login screen.
> 
3.0.0 does not yet have vga text console support, 
although kms should work at least on some graphics cards.

Try setting up a serial console and see where it fails / what it''s
doing.

-- Pasi


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


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

Boris Derzhavets

2011-Aug-03 01:05 UTC

head link

Re: Re: [Xen-users] Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

What kernel are you running ?

Boris.

--- On Tue, 8/2/11, jim burns <jim_burn@bellsouth.net> wrote:

From: jim burns <jim_burn@bellsouth.net>
Subject: Re: Re: [Xen-users] Re: [Xen-devel] Updating Xen 4.1.x xmexamples files
(vfb line required for HVM guests)
To: "M A Young" <m.a.young@durham.ac.uk>
Cc: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
"Boris Derzhavets" <bderzhavets@yahoo.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"Ian Campbell" <Ian.Campbell@citrix.com>,
"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
"Pasi Kärkkäinen" <pasik@iki.fi>
Date: Tuesday, August 2, 2011, 5:57 PM

M A Young said:> On Tue, 2 Aug 2011, Konrad Rzeszutek Wilk wrote:
>> On Tue, Aug 02, 2011 at 06:07:39AM -0700, Boris Derzhavets wrote:
>>> I''ve installed  xen-4.1.1-1.fc16.src.rpm.  It
doesn''t contain mentioned
patch.>>> Added patch as raw content of
>>>
>>>   
http://xenbits.xen.org/hg/staging/xen-4.1-testing.hg/rev/1976adbf2b80
> It already is in xen-4.1.1-2.fc16 and xen-4.1.1-2.fc15 .
>         Michael Young
[516] > rpm -q --last xen 
xen-4.1.1-2.fc16                              Fri 22 Jul 2011 10:24:57 PM EDT

Huh!!! I guess I never tried removing the vfb= line since I got this update. I 
can verify that the vfb= line is no longer necessary. Sorry for making so much 
noise about this problem. (Also odd that the vfb= line was a temporary fix!)


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

jim burns

2011-Aug-03 01:33 UTC

head link

Re: Re: Re: [Xen-users] Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

> What kernel are you running ?
> Boris.
Doesn''t matter. With xen 4.1.1-1 on fedora, I needed the vfb= line
under both
3.0.0 from fedora rawhide (now f16), and myoung''s 2.6.32. It was a xen
issue,
not a dom0 issue. Now, I apparently don''t need the vfb= line with
fedora''s xen
4.1.1-2, with the gcc 4.6 patch.

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

Boris Derzhavets

2011-Aug-03 06:37 UTC

head link

Re: Re: Re: [Xen-users] Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

I cannot get login prompt with Xen 4.1.1-2 and rebuilt kernel 3.0.0 -1 from f16
( or 2.6.40 current on F15 ).
Could you share grub entry for Xen ?

Boris.

--- On Tue, 8/2/11, jim burns <jim_burn@bellsouth.net> wrote:

From: jim burns <jim_burn@bellsouth.net>
Subject: Re: Re: Re: [Xen-users] Re: [Xen-devel] Updating Xen 4.1.x xmexamples
files (vfb line required for HVM guests)
To: "Boris Derzhavets" <bderzhavets@yahoo.com>
Cc: "xen-devel@lists.xensource.com"
<xen-devel@lists.xensource.com>, "Ian Campbell"
<Ian.Campbell@citrix.com>, "Konrad Rzeszutek Wilk"
<konrad.wilk@oracle.com>, "Pasi Kärkkäinen"
<pasik@iki.fi>, "M A Young" <m.a.young@durham.ac.uk>,
"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>
Date: Tuesday, August 2, 2011, 9:33 PM
> What kernel are you running ?
> Boris.
Doesn''t matter. With xen 4.1.1-1 on fedora, I needed the vfb= line
under both
3.0.0 from fedora rawhide (now f16), and myoung''s 2.6.32. It was a xen
issue,
not a dom0 issue. Now, I apparently don''t need the vfb= line with
fedora''s xen
4.1.1-2, with the gcc 4.6 patch.

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


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

jim burns

2011-Aug-03 07:36 UTC

head link

Re: [Xen-users] Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

> I cannot get login prompt with Xen 4.1.1-2 and rebuilt kernel 3.0.0 -1 from
> f16 ( or 2.6.40 current on F15 ).
> Could you share grub entry for Xen ?
> Boris.
jimb@insp6400 08/03/11  3:22AM:~
[504] > lspci
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 
945GT Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 
943/940GML Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML 
Express Integrated Graphics Controller (rev 03)
[...]

title Fedora (3.0.0-1.fc16.x86_64)
        root (hd0,1)
        kernel /vmlinuz-3.0.0-1.fc16.x86_64 ro root=/dev/mapper/vg_insp6400-
lv_root SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
        initrd /initramfs-3.0.0-1.fc16.x86_64.img

title Xen Dom0 (3.0.0-1.fc16.x86_64)
        root (hd0,1)
        kernel /xen.gz cpufreq=xen
        module /vmlinuz-3.0.0-1.fc16.x86_64 ro root=/dev/mapper/vg_insp6400-
lv_root SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us xen-
pciback.permissive xen-pciback.hide=(0b:00.0)
        module /initramfs-3.0.0-1.fc16.x86_64.img


Pretty stright forward. The pciback stuff isn''t necessary, since fedora
builds
it as a module (not that 3.0.0 has a pciback, anyway) - it''s just 
documentation to remind me how it is done. With f15''s 2.6.38, I had to
add ''3''
to the end of the ''vmlinuz'' line in the xen stanza. You might
try that, just
to see if you can get a text login. (And there is always
''nomodeset'' to try.)

Since 3.0.0 doesn''t have the vga text patch, the screen will go briefly
blank
between the xen hypervisor output, and when drm kicks in the kernel output.

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

Boris Derzhavets

2011-Aug-03 09:39 UTC

head link

Re: [Xen-users] Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

kernel    /xen.gz    cpufreq=xen

Thank you very much.
I logged into Xen Host. 

Boris.

--- On Wed, 8/3/11, jim burns <jim_burn@bellsouth.net> wrote:

From: jim burns <jim_burn@bellsouth.net>
Subject: Re: [Xen-users] Re: [Xen-devel] Updating Xen 4.1.x xmexamples files
(vfb line required for HVM guests)
To: "Boris Derzhavets" <bderzhavets@yahoo.com>
Cc: "xen-users@lists.xensource.com"
<xen-users@lists.xensource.com>
Date: Wednesday, August 3, 2011, 3:36 AM
> I cannot get login prompt with Xen 4.1.1-2 and rebuilt kernel 3.0.0 -1 from
> f16 ( or 2.6.40 current on F15 ).
> Could you share grub entry for Xen ?
> Boris.
jimb@insp6400 08/03/11  3:22AM:~
[504] > lspci
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 
945GT Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 
943/940GML Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML 
Express Integrated Graphics Controller (rev 03)
[...]

title Fedora (3.0.0-1.fc16.x86_64)
        root (hd0,1)
        kernel /vmlinuz-3.0.0-1.fc16.x86_64 ro root=/dev/mapper/vg_insp6400-
lv_root SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
        initrd /initramfs-3.0.0-1.fc16.x86_64.img

title Xen Dom0 (3.0.0-1.fc16.x86_64)
        root (hd0,1)
        kernel /xen.gz cpufreq=xen
        module /vmlinuz-3.0.0-1.fc16.x86_64 ro root=/dev/mapper/vg_insp6400-
lv_root SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us xen-
pciback.permissive xen-pciback.hide=(0b:00.0)
        module /initramfs-3.0.0-1.fc16.x86_64.img


Pretty stright forward. The pciback stuff isn''t necessary, since fedora
builds
it as a module (not that 3.0.0 has a pciback, anyway) - it''s just 
documentation to remind me how it is done. With f15''s 2.6.38, I had to
add ''3''
to the end of the ''vmlinuz'' line in the xen stanza. You might
try that, just
to see if you can get a text login. (And there is always
''nomodeset'' to try.)

Since 3.0.0 doesn''t have the vga text patch, the screen will go briefly
blank
between the xen hypervisor output, and when drm kicks in the kernel output.

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


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

jim burns

2011-Aug-03 20:16 UTC

head link

Re: [Xen-users] 3.0.0 and gplpv

I said:> Rawhide kernel 3.1.0-0.rc0.git11.2.fc17.x86_64 boots correctly bare metal.
> It still reboots after the hypervisor output, tho''. It''s
around the time drm
> should kick in, but putting ''nomodeset'' on the
kernel''s ''module'' line has no
> effect.
>> I''ll continue to try to get a dump closer to when xennet
actually froze,
>> and post that. Hope this was of interest.
> Well, that was fast. xennet hung shortly after I logged in thru rdp, while 
> mcafee was still looking for updates. 192.168.1.101 is the rdp client, 
> 192.168.1.102 is the winxp domu. After a few rdp updates, and responses
from
> the client rdp, and some internet responses, the conversation becomes one
> sided, with only the domu talking rdp, and then degenerates into a bunch of
> dns lookups.
I think the problem is solved. I tried f15''s new 2.6.40-4 (renamed
3.0.0), and
the performance problems are gone. Comparing the two config files, 3.0.0 has 
lots of DEBUG options (and NR_CPUS=512, instead of 256). I should have known 
that would be what rawhide (now f16) would put out. I''ll continue to
stress
test with iperf a few more times, but it looks like this will be ok.

Thanx for your initial interest.

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

jim burns

2011-Aug-15 08:04 UTC

head link

Summary: Experiences setting up a debug serial port (was Re: [Xen-users] 3.1.0-rc0 git snapshot crashes as dom0 (private mail))

Pls cc me with responses, as I''m not subscribed.

On Tue August 2 2011, 12:36:26 AM, Pasi Kärkkäinen
wrote:> On Sat, Jul 30, 2011 at 06:28:26PM -0400, jim burns wrote:
> > > solved the bare metal boot problem. I just got another
> > > kernel-3.1.0-0.rc0 update (from git9.1 to git11.2). Hopefully,
> > > fedora has sorted out it''s kernel identity crisis!
> > 
> > Rawhide kernel 3.1.0-0.rc0.git11.2.fc17.x86_64 boots correctly bare
> > metal. It still reboots after the hypervisor output, tho''.
It''s around
> > the time drm should kick in, but putting ''nomodeset''
on the kernel''s
> > ''module'' line has no effect.
> 
> Konrad: Do you know if this is a known problem?
> 
> -- Pasi
On Mon August 15 2011, 1:43:23 AM, Konrad Rzeszutek Wilk
wrote:> On Sun, Aug 14, 2011 at 06:41:37PM -0400, jim burns wrote:
> > On Sun August 14 2011, 6:38:34 PM, jim burns wrote:
> > > OK - replacing ''debug loglevel=8
video.allow_duplicates=1 nomodeset''
> > > with ''nomodeset initcall_debug debug
loglevel=10''. (The video
> > > option was left over  from a separate debug problem.) Log
included
> > > - looks the same to me.> 
> > Ahem! And the log:
> Yeah, this is the bug introduced by Andi. 3.1-rc2 has the fix. You are
> looking for this git commit 06e727d2a5d9d889fabad35223ad77205a9bebb9
> 
> Hm, I thought I had mentioned it to you which one I thought it was.. but
> maybe I forgot - in which I am sorry for you having to do this extra
> run-around.
>  [Log at end of post]
On Sun August 7 2011, 2:48:31 PM, Pasi Kärkkäinen wrote:
(Yes, I finally learned how to setup a kmail quoting
template!)> On Sat, Aug 06, 2011 at 07:13:46PM -0400, jim burns wrote:
> > Konrad said:
> > > For your issue we need to get the output from the bootup. Try to
use
> > > a
> > > serial console (The pvops wiki explains how to do that) or use
the
> > > VGA
> > > output to get some idea.
> > 
> > I read the links that Pasi provided - thanx. Turns out I
don''t have a
> > serial port, and no options that I know of for SOL. My system is a
> > laptop.
> For a laptop you can get a Expresscard serial card.. it works in the same
> way as PCI serial cards for desktops.
> 
> Like this:
>http://www.newegg.com/Product/Product.aspx?Item=N82E16839328018&Tpk=SDEXP15005
[See also the link - http://wiki.xensource.com/xenwiki/XenSerialConsole ]

I got that card - thanx for the recommendation. Then I looked in my box of 
cables and found I didn''t have the right gender adapter, so I had to
wait for
that as well!

Getting the card has been an education in kernel drivers - builtin vs. 
modules. I first had to realize that ''serial'' is a builtin, so
lspci -s [...]
-k for my wifi card may say:

0b:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] 
Network Connection (rev 02)
        Subsystem: Intel Corporation Device 1020
        Kernel driver in use: iwl3945
        Kernel modules: iwl3945

but the serial port only says:

0c:00.0 Serial controller: NetMos Technology Device 9922
        Subsystem: Device a000:1000
        Kernel driver in use: serial

None the less, the serial port is a pci device, so it is found in 
/sys/bus/pci, not /sys/bus/platform.

With that realization, the nagging suspicion that the card was not being 
initialized on all kernels was confirmed. I booted under pvops 2.6.32 
(myoung), f15''s 2.6.40, f16''s 3.0.0-1, and rawhide''s
3.1.0-0.rc1.git6.1, all
of them as dom0 and baremetal (except the offending 3.1.0 can''t boot as
dom0),
and the latter, baremetal, was the only one that initialized the card. Under 
all other systems, dmesg said:

Aug 12 17:58:02 Insp6400 kernel: [    0.735416] Serial: 8250/16550 driver, 4 
ports, IRQ sharing enabled
Aug 12 17:58:02 Insp6400 kernel: [    0.756915] serial 0000:0c:00.0: PCI INT A 
-> GSI 19 (level, low) -> IRQ 19
Aug 12 17:58:02 Insp6400 kernel: [    0.758492] serial 0000:0c:00.0: PCI INT A 
disabled

but 3.1.0 said:

Aug 12 18:06:45 Insp6400 kernel: [    5.421588] Serial: 8250/16550 driver, 4 
ports, IRQ sharing enabled
Aug 12 18:06:45 Insp6400 kernel: [    5.457800] serial 0000:0c:00.0: PCI INT A 
-> GSI 19 (level, low) -> IRQ 19
Aug 12 18:06:45 Insp6400 kernel: [    5.481880] 0000:0c:00.0: ttyS0 at I/O 
0xdff8 (irq = 19) is a ST16650V2

Similarly, on 3.1.0, the contents of /sys/bus/pci/drivers/serial is:

drwxr-xr-x.  2 root root    0 Aug 14 16:51 ./
drwxr-xr-x. 28 root root    0 Aug 14 16:51 ../
lrwxrwxrwx.  1 root root    0 Aug 14 16:52 0000:0c:00.0 -> 
../../../../devices/pci0000:00/0000:00:1c.3/0000:0c:00.0/
--w-------.  1 root root 4096 Aug 14 17:21 bind
--w-------.  1 root root 4096 Aug 14 17:21 new_id
--w-------.  1 root root 4096 Aug 14 17:21 remove_id
--w-------.  1 root root 4096 Aug 14 16:51 uevent
--w-------.  1 root root 4096 Aug 14 17:21 unbind

where as all other kernels did not have the soft link. All attempts to do late 
binding on these other kernels:

if [ -d /sys/bus/pci/devices/0000:0c:00.0/ ]; then #pci-e serial port
  if [ ! -d /sys/bus/pci/drivers/serial/0000:0c:00.0 ]; then # not bound
    echo -n "9710 9922" > /sys/bus/pci/drivers/serial/new_id
    echo -n "0000:0c:00.0" > /sys/bus/pci/drivers/serial/bind
  fi
fi

resulted ''write: no such device'', or some such error, after
the last echo.

Well, at least I had one system to debug my connections with - baremetal 
3.1.0. So I fired up ''screen /dev/ttyS0 38400,cs8'' on both my
fedora 3.1.0,
and another client, and everything worked fine.

With this grub stanza:

title Xen Dom0 w/debug console (3.1.0-0.rcx.gity.z.fc17.x86_64)
        root (hd0,1)
        #kernel /xen.gz cpufreq=xen loglvl=all guest_loglvl=all sync_console 
console_to_ring noreboot console=vga
        kernel /xen.gz cpufreq=xen loglvl=all guest_loglvl=all sync_console 
console_to_ring noreboot com1=115200,8n1,0xdff8,19 console=com1
        module /vmlinuz ro root=/dev/mapper/vg_insp6400-lv_root 
SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us console=hvc0 
earlyprintk=xen debug loglevel=8 video.allow_duplicates=1 nomodeset
        module /initramfs

where x,y,z = 3.1.0-0.rc1.git6.1.fc17.x86_64, and ''vmlinuz''
and ''initramfs''
are soft links to that kernel, I got the following serial console log. Hope it 
helps:

> >  __  __            _  _    _   _   ____     __      _  __
> >  \ \/ /___ _ __   | || |  / | / | |___ \   / _| ___/ |/ /_
> >  
> >   \  // _ \ ''_ \  | || |_ | | | |__ __) | | |_ / __| |
''_ \
> >   /  \  __/ | | | |__   _|| |_| |__/ __/ _|  _| (__| | (_) |
> >  
> >  /_/\_\___|_| |_|    |_|(_)_(_)_| |_____(_)_|  \___|_|\___/
> > 
> > (XEN) Xen version 4.1.1 (mockbuild@phx2.fedoraproject.org) (gcc
version
> > 4.6.1 20110715 (Red Hat 4.6.1-3) (GCC) ) Wed Jul 20 18:47:22 UTC 2011
> > (XEN) Latest ChangeSet: unavailable
> > (XEN) Console output is synchronous.
> > (XEN) Bootloader: GNU GRUB 0.97-71.fc15
> > (XEN) Command line: cpufreq=xen loglvl=all guest_loglvl=all
sync_console
> > console_to_ring noreboot com1=115200,8n1,0xdff8,19 console=com1
> > (XEN) Video information:
> > (XEN)  VGA is text mode 80x25, font 8x16
> > (XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
> > (XEN) Disc information:
> > (XEN)  Found 1 MBR signatures
> > (XEN)  Found 1 EDD information structures
> > (XEN) Xen-e820 RAM map:
> > (XEN)  0000000000000000 - 000000000009f000 (usable)
> > (XEN)  000000000009f000 - 00000000000a0000 (reserved)
> > (XEN)  0000000000100000 - 000000007f6d3400 (usable)
> > (XEN)  000000007f6d3400 - 0000000080000000 (reserved)
> > (XEN)  00000000f0000000 - 00000000f4007000 (reserved)
> > (XEN)  00000000f4008000 - 00000000f400c000 (reserved)
> > (XEN)  00000000fec00000 - 00000000fec10000 (reserved)
> > (XEN)  00000000fed20000 - 00000000feda0000 (reserved)
> > (XEN)  00000000fee00000 - 00000000fee10000 (reserved)
> > (XEN)  00000000ffb00000 - 0000000100000000 (reserved)
> > (XEN) System RAM: 2038MB (2087368kB)
> > (XEN) ACPI: RSDP 000FC1D0, 0014 (r0 DELL  )
> > (XEN) ACPI: RSDT 7F6D3A0F, 0040 (r1 DELL    M07     27D7060D ASL
> > 61) (XEN) ACPI: FACP 7F6D4800, 0074 (r1 DELL    M07     27D7060D ASL
> >     61) (XEN) ACPI: DSDT 7F6D5400, 4766 (r1 INT430 SYSFexxx     1001
> > INTL 20050624) (XEN) ACPI: FACS 7F6E3C00, 0040
> > (XEN) ACPI: HPET 7F6D4F00, 0038 (r1 DELL    M07            1 ASL
> > 61) (XEN) ACPI: APIC 7F6D5000, 0068 (r1 DELL    M07     27D7060D ASL
> >     47) (XEN) ACPI: MCFG 7F6D4FC0, 003E (r16 DELL    M07     27D7060D
> > ASL        61) (XEN) ACPI: SLIC 7F6D509C, 0176 (r1 DELL    M07    
> > 27D7060D ASL        61) (XEN) ACPI: BOOT 7F6D4BC0, 0028 (r1 DELL   
M07
> >     27D7060D ASL        61) (XEN) ACPI: SSDT 7F6D3A4F, 04DC (r1  PmRef
> >   CpuPm     3000 INTL 20050624) (XEN) No NUMA configuration found
> > (XEN) Faking a node at 0000000000000000-000000007f6d3000
> > (XEN) Domain heap initialised
> > (XEN) DMI 2.4 present.
> > (XEN) Using APIC driver default
> > (XEN) ACPI: PM-Timer IO Port: 0x1008
> > (XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[1004,0], pm1x_evt[1000,0]
> > (XEN) ACPI:                  wakeup_vec[7f6e3c0c], vec_size[20]
> > (XEN) ACPI: Local APIC address 0xfee00000
> > (XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
> > (XEN) Processor #0 6:15 APIC version 20
> > (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
> > (XEN) Processor #1 6:15 APIC version 20
> > (XEN) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
> > (XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
> > (XEN) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
> > (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
> > (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
> > (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
> > (XEN) ACPI: IRQ0 used by override.
> > (XEN) ACPI: IRQ2 used by override.
> > (XEN) ACPI: IRQ9 used by override.
> > (XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
> > (XEN) ACPI: HPET id: 0x8086a201 base: 0xfed00000
> > (XEN) PCI: MCFG configuration 0: base f0000000 segment 0 buses 0 - 63
> > (XEN) PCI: MCFG area at f0000000 reserved in E820
> > (XEN) Table is not found!
> > (XEN) Using ACPI (MADT) for SMP configuration information
> > (XEN) IRQ limits: 24 GSI, 376 MSI/MSI-X
> > (XEN) Using scheduler: SMP Credit Scheduler (credit)
> > (XEN) Detected 1828.780 MHz processor.
> > (XEN) Initing memory sharing.
> > (XEN) mce_intel.c:1162: MCA Capability: BCAST 1 SER 0 CMCI 0 firstbank
1
> > extended MCE MSR 0
> > (XEN) Intel machine check reporting enabled
> > (XEN) I/O virtualisation disabled
> > (XEN) ENABLING IO-APIC IRQs
> > (XEN)  -> Using new ACK method
> > (XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
> > (XEN) Platform timer is 14.318MHz HPET
> > �(XEN) Allocated console ring of 16 KiB.
> > (XEN) VMX: Supported advanced features:
> > (XEN)  - APIC TPR shadow
> > (XEN)  - MSR direct-access bitmap
> > (XEN) HVM: ASIDs disabled.
> > (XEN) HVM: VMX enabled
> > (XEN) Brought up 2 CPUs
> > (XEN) HPET: 3 timers in total, 0 timers will be used for broadcast
> > (XEN) ACPI sleep modes: S3
> > (XEN) mcheck_poll: Machine check polling timer started.
> > (XEN) *** LOADING DOMAIN 0 ***
> > (XEN)  Xen  kernel: 64-bit, lsb, compat32
> > (XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x2ae1000
> > (XEN) PHYSICAL MEMORY ARRANGEMENT:
> > (XEN)  Dom0 alloc.:   0000000074000000->0000000078000000 (456560
pages
> > to be allocated)
> > (XEN)  Init. ramdisk: 000000007c9a6000->000000007f1ff400
> > (XEN) VIRTUAL MEMORY ARRANGEMENT:
> > (XEN)  Loaded kernel: ffffffff81000000->ffffffff82ae1000
> > (XEN)  Init. ramdisk: ffffffff82ae1000->ffffffff8533a400
> > (XEN)  Phys-Mach map: ffffffff8533b000->ffffffff856eae50
> > (XEN)  Start info:    ffffffff856eb000->ffffffff856eb4b4
> > (XEN)  Page tables:   ffffffff856ec000->ffffffff8571b000
> > (XEN)  Boot stack:    ffffffff8571b000->ffffffff8571c000
> > (XEN)  TOTAL:         ffffffff80000000->ffffffff85800000
> > (XEN)  ENTRY ADDRESS: ffffffff81d4f200
> > (XEN) Dom0 has maximum 2 VCPUs
> > (XEN) Scrubbing Free RAM: .done.
> > (XEN) Xen trace buffers: disabled
> > (XEN) Std. Loglevel: All
> > (XEN) Guest Loglevel: All
> > (XEN) **********************************************
> > (XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS
> > (XEN) ******* This option is intended to aid debugging of Xen by
> > ensuring
> > (XEN) ******* that all output is synchronously delivered on the serial
> > line. (XEN) ******* However it can introduce SIGNIFICANT latencies and
> > affect (XEN) ******* timekeeping. It is NOT recommended for production
> > use! (XEN) **********************************************
> > (XEN) 3... 2... 1...
> > (XEN) *** Serial input -> DOM0 (type ''CTRL-a''
three times to switch
> > input to Xen)
> > (XEN) Freed 224kB init memory.
> > mapping kernel into physical memory
> > Xen: setup ISA identity maps
> > about to get started...
> > [    0.000000] Initializing cgroup subsys cpuset
> > [    0.000000] Initializing cgroup subsys cpu
> > [    0.000000] Linux version 3.1.0-0.rc1.git6.1.fc17.x86_64
> > (mockbuild@x86-16.phx2.fedoraproject.org) (gcc version 4.6.1 20110715
> > (Red Hat 4.6.1-3) (GCC) ) #1 SMP Fri Aug 12 02:44:07 UTC 2011
> > [    0.000000] Command line: ro root=/dev/mapper/vg_insp6400-lv_root
> > SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us console=hvc0
> > earlyprintk=xen nomodeset initcall_debug debug loglevel=10
> > [    0.000000] released 0 pages of unused memory
> > [    0.000000] Set 526733 page(s) to 1-1 mapping.
> > [    0.000000] BIOS-provided physical RAM map:
> > [    0.000000]  Xen: 0000000000000000 - 000000000009f000 (usable)
> > [    0.000000]  Xen: 000000000009f000 - 0000000000100000 (reserved)
> > [    0.000000]  Xen: 0000000000100000 - 0000000075fca000 (usable)
> > [    0.000000]  Xen: 0000000075fca000 - 000000007f6d3000 (unusable)
> > [    0.000000]  Xen: 000000007f6d3400 - 0000000080000000 (reserved)
> > [    0.000000]  Xen: 00000000f0000000 - 00000000f4007000 (reserved)
> > [    0.000000]  Xen: 00000000f4008000 - 00000000f400c000 (reserved)
> > [    0.000000]  Xen: 00000000fec00000 - 00000000fec10000 (reserved)
> > [    0.000000]  Xen: 00000000fed20000 - 00000000feda0000 (reserved)
> > [    0.000000]  Xen: 00000000fee00000 - 00000000fee10000 (reserved)
> > [    0.000000]  Xen: 00000000ffb00000 - 0000000100000000 (reserved)
> > [    0.000000]  Xen: 0000000100000000 - 0000000109709000 (usable)
> > [    0.000000] bootconsole [xenboot0] enabled
> > [    0.000000] NX (Execute Disable) protection: active
> > [    0.000000] DMI 2.4 present.
> > [    0.000000] DMI: Dell Inc. MM061                           /0KD882,
> > BIOS A17 06/13/2007
> > [    0.000000] e820 update range: 0000000000000000 - 0000000000010000
> > (usable) ==> (reserved)
> > [    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000
> > (usable) [    0.000000] No AGP bridge found
> > [    0.000000] last_pfn = 0x109709 max_arch_pfn = 0x400000000
> > [    0.000000] last_pfn = 0x75fca max_arch_pfn = 0x400000000
> > [    0.000000] initial memory mapped : 0 - 0533b000
> > [    0.000000] Base memory trampoline at [ffff88000009a000] 9a000 size
> > 20480 [    0.000000] init_memory_mapping:
> > 0000000000000000-0000000075fca000 [    0.000000]  0000000000 -
> > 0075fca000 page 4k
> > [    0.000000] kernel direct mapping tables up to 75fca000 @
> > 75c17000-75fca000 [    0.000000] xen: setting RW the range 75f98000 -
> > 75fca000
> > [    0.000000] init_memory_mapping: 0000000100000000-0000000109709000
> > [    0.000000]  0100000000 - 0109709000 page 4k
> > [    0.000000] kernel direct mapping tables up to 109709000 @
> > 753c5000-75c17000
> > [    0.000000] xen: setting RW the range 75412000 - 75c17000
> > [    0.000000] RAMDISK: 02ae1000 - 0533b000
> > [    0.000000] ACPI: RSDP 00000000000fc1d0 00014 (v00 DELL  )
> > [    0.000000] ACPI: RSDT 000000007f6d3a0f 00040 (v01 DELL    M07    
> > 27D7060D ASL  00000061)
> > [    0.000000] ACPI: FACP 000000007f6d4800 00074 (v01 DELL    M07    
> > 27D7060D ASL  00000061)
> > [    0.000000] ACPI: DSDT 000000007f6d5400 04766 (v01 INT430 SYSFexxx
> > 00001001 INTL 20050624)
> > [    0.000000] ACPI: FACS 000000007f6e3c00 00040
> > [    0.000000] ACPI: HPET 000000007f6d4f00 00038 (v01 DELL    M07    
> > 00000001 ASL  00000061)
> > [    0.000000] ACPI: APIC 000000007f6d5000 00068 (v01 DELL    M07    
> > 27D7060D ASL  00000047)
> > [    0.000000] ACPI: MCFG 000000007f6d4fc0 0003E (v16 DELL    M07    
> > 27D7060D ASL  00000061)
> > [    0.000000] ACPI: SLIC 000000007f6d509c 00176 (v01 DELL    M07    
> > 27D7060D ASL  00000061)
> > [    0.000000] ACPI: BOOT 000000007f6d4bc0 00028 (v01 DELL    M07    
> > 27D7060D ASL  00000061)
> > [    0.000000] ACPI: SSDT 000000007f6d3a4f 004DC (v01  PmRef    CpuPm
> > 00003000 INTL 20050624)
> > [    0.000000] ACPI: Local APIC address 0xfee00000
> > [    0.000000] No NUMA configuration found
> > [    0.000000] Faking a node at 0000000000000000-0000000109709000
> > [    0.000000] Initmem setup node 0 0000000000000000-0000000109709000
> > [    0.000000]   NODE_DATA [0000000075fb5000 - 0000000075fc9fff]
> > [    0.000000] Zone PFN ranges:
> > [    0.000000]   DMA      0x00000010 -> 0x00001000
> > [    0.000000]   DMA32    0x00001000 -> 0x00100000
> > [    0.000000]   Normal   0x00100000 -> 0x00109709
> > [    0.000000] Movable zone start PFN for each node
> > [    0.000000] early_node_map[3] active PFN ranges
> > [    0.000000]     0: 0x00000010 -> 0x0000009f
> > [    0.000000]     0: 0x00000100 -> 0x00075fca
> > [    0.000000]     0: 0x00100000 -> 0x00109709
> > [    0.000000] On node 0 totalpages: 521826
> > [    0.000000]   DMA zone: 64 pages used for memmap
> > [    0.000000]   DMA zone: 5 pages reserved
> > [    0.000000]   DMA zone: 3914 pages, LIFO batch:0
> > [    0.000000]   DMA32 zone: 16320 pages used for memmap
> > [    0.000000]   DMA32 zone: 462858 pages, LIFO batch:31
> > [    0.000000]   Normal zone: 605 pages used for memmap
> > [    0.000000]   Normal zone: 38060 pages, LIFO batch:7
> > (XEN) mm.c:907:d0 Error getting mfn 1b79 (pfn 5555555555555555) from
L1
> > entry 8000000001b79465 for l1e_owner=0, pg_owner=0
> > (XEN) mm.c:4967:d0 ptwr_emulate: could not get_page_from_l1e()
> > [    0.000000] BUG: unable to handle kernel NULL pointer dereference
at
> > (null)
> > [    0.000000] IP: [<ffffffff8100643d>] __xen_set_pte+0x51/0x5b
> > [    0.000000] PGD 0
> > [    0.000000] Oops: 0003 [#1] SMP
> > [    0.000000] CPU 0
> > [    0.000000] Modules linked in:
> > [    0.000000]
> > [    0.000000] Pid: 0, comm: swapper Not tainted
> > 3.1.0-0.rc1.git6.1.fc17.x86_64 #1 Dell Inc. MM061
> > /0KD882
> > [    0.000000] RIP: e030:[<ffffffff8100643d>] 
[<ffffffff8100643d>]
> > __xen_set_pte+0x51/0x5b
> > [    0.000000] RSP: e02b:ffffffff81a01da8  EFLAGS: 00010096
> > [    0.000000] RAX: 00000000ffffffff RBX: ffff880001e38ff8 RCX:
> > ffffffff829ad000
> > [    0.000000] RDX: 0000000010000001 RSI: 8000000001b79465 RDI:
> > ffff880001e38ff8
> > [    0.000000] RBP: ffffffff81a01dc8 R08: 0000000000000000 R09:
> > 0000000000007ff0
> > [    0.000000] R10: 0000000000007ff0 R11: 0000000000007ff0 R12:
> > 8000000001b79465
> > [    0.000000] R13: 0000000075fca000 R14: ffffffffffffffff R15:
> > 0000000000000000
> > [    0.000000] FS:  0000000000000000(0000) GS:ffffffff81b7a000(0000)
> > knlGS:0000000000000000
> > [    0.000000] CS:  e033 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [    0.000000] CR2: 0000000000000000 CR3: 0000000001a04000 CR4:
> > 0000000000002660
> > [    0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> > 0000000000000000
> > [    0.000000] DR3: 0000000000000000 DR6: 0000000000000000 DR7:
> > 0000000000000000
> > [    0.000000] Process swapper (pid: 0, threadinfo ffffffff81a00000,
> > task
> > ffffffff81a0c020)
> > [    0.000000] Stack:
> > [    0.000000]  ffffffff829ad000 ffffffff829ad000 ffff880001e38ff8
> > 8000000001b79465
> > [    0.000000]  ffffffff81a01df8 ffffffff81006562 0000000000007ff0
> > ffffffffff5ff000
> > [    0.000000]  8000000001b79465 0000000075fca000 ffffffff81a01e08
> > ffffffff81032db4
> > [    0.000000] Call Trace:
> > [    0.000000]  [<ffffffff81006562>] xen_set_pte+0x75/0x95
> > [    0.000000]  [<ffffffff81032db4>] set_pte+0x10/0x12
> > [    0.000000]  [<ffffffff810332dd>] set_pte_vaddr_pud+0x3c/0x4b
> > [    0.000000]  [<ffffffff81033361>] set_pte_vaddr+0x75/0x7a
> > [    0.000000]  [<ffffffff810367ef>]
__native_set_fixmap+0x27/0x2f
> > [    0.000000]  [<ffffffff81005119>] xen_set_fixmap+0x8c/0xbb
> > [    0.000000]  [<ffffffff81d55315>] map_vsyscall+0x50/0x55
> > [    0.000000]  [<ffffffff81d54a63>] setup_arch+0xa7e/0xb2f
> > [    0.000000]  [<ffffffff814ee065>] ? printk+0x51/0x53
> > [    0.000000]  [<ffffffff81d4f8a3>] start_kernel+0xe1/0x3ea
> > [    0.000000]  [<ffffffff81d4f2c4>]
x86_64_start_reservations+0xaf/0xb3
> > [    0.000000]  [<ffffffff81d51f0f>]
xen_start_kernel+0x57f/0x586
> > [    0.000000] Code: df e8 18 04 03 00 48 89 c7 e8 7c ee ff ff 48 8d
7d
> > e0 48 89 45 e0 4c 89 65 e8 e8 fd f4 ff ff bf 01 00 00 00 e8 a4 f7 ff
ff
> > eb 03 <4c> 89 23 58 5a 5b 41 5c 5d c3 55 48 89 e5 41 57 41 56 41
55 41
> > [    0.000000] RIP  [<ffffffff8100643d>] __xen_set_pte+0x51/0x5b
> > [    0.000000]  RSP <ffffffff81a01da8>
> > [    0.000000] CR2: 0000000000000000
> > [    0.000000] ---[ end trace a7919e7f17c0a725 ]---
> > [    0.000000] Kernel panic - not syncing: Attempted to kill the idle
> > task! [    0.000000] Pid: 0, comm: swapper Tainted: G      D
> > 3.1.0-0.rc1.git6.1.fc17.x86_64 #1
> > [    0.000000] Call Trace:
> > [    0.000000]  [<ffffffff814edefb>] panic+0xa0/0x1b9
> > [    0.000000]  [<ffffffff8105febd>] do_exit+0x9e/0x82c
> > [    0.000000]  [<ffffffff8105de36>] ? kmsg_dump+0x131/0x14f
> > [    0.000000]  [<ffffffff8105dd8e>] ? kmsg_dump+0x89/0x14f
> > [    0.000000]  [<ffffffff814fa181>] oops_end+0xbc/0xc5
> > [    0.000000]  [<ffffffff814ed7aa>] no_context+0x208/0x217
> > [    0.000000]  [<ffffffff814ed952>]
__bad_area_nosemaphore+0x199/0x1bc
> > [    0.000000]  [<ffffffff81007667>] ?
> > __raw_callee_save_xen_restore_fl+0x11/0x1e
> > [    0.000000]  [<ffffffff814ed988>]
bad_area_nosemaphore+0x13/0x15
> > [    0.000000]  [<ffffffff814fc28b>] do_page_fault+0x1b1/0x3a2
> > [    0.000000]  [<ffffffff81007649>] ?
> > __raw_callee_save_xen_save_fl+0x11/0x1e [    0.000000] 
> > [<ffffffff814f9736>] ? error_sti+0x5/0x6
> > [    0.000000]  [<ffffffff814f92a4>] ? restore_args+0x30/0x30
> > [    0.000000]  [<ffffffff8108ace7>] ?
arch_local_save_flags+0xb/0xd
> > [    0.000000]  [<ffffffff8108b7db>] ?
> > trace_hardirqs_off_caller+0x33/0x90 [    0.000000] 
> > [<ffffffff81252ecd>] ? trace_hardirqs_off_thunk+0x3a/0x3c [   
> > 0.000000]  [<ffffffff814f94f5>] page_fault+0x25/0x30
> > [    0.000000]  [<ffffffff8100643d>] ? __xen_set_pte+0x51/0x5b
> > [    0.000000]  [<ffffffff81006407>] ? __xen_set_pte+0x1b/0x5b
> > [    0.000000]  [<ffffffff81006562>] xen_set_pte+0x75/0x95
> > [    0.000000]  [<ffffffff81032db4>] set_pte+0x10/0x12
> > [    0.000000]  [<ffffffff810332dd>] set_pte_vaddr_pud+0x3c/0x4b
> > [    0.000000]  [<ffffffff81033361>] set_pte_vaddr+0x75/0x7a
> > [    0.000000]  [<ffffffff810367ef>]
__native_set_fixmap+0x27/0x2f
> > [    0.000000]  [<ffffffff81005119>] xen_set_fixmap+0x8c/0xbb
> > [    0.000000]  [<ffffffff81d55315>] map_vsyscall+0x50/0x55
> > [    0.000000]  [<ffffffff81d54a63>] setup_arch+0xa7e/0xb2f
> > [    0.000000]  [<ffffffff814ee065>] ? printk+0x51/0x53
> > [    0.000000]  [<ffffffff81d4f8a3>] start_kernel+0xe1/0x3ea
> > [    0.000000]  [<ffffffff81d4f2c4>]
x86_64_start_reservations+0xaf/0xb3
> > [    0.000000]  [<ffffffff81d51f0f>]
xen_start_kernel+0x57f/0x586
> > (XEN) Domain 0 crashed: ''noreboot'' set - not
rebooting.

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

jim burns

2011-Aug-16 23:46 UTC

head link

Re: Summary: Experiences setting up a debug serial port (was Re: [Xen-users] 3.1.0-rc0 git snapshot crashes as dom0 (private mail))

On Mon August 15 2011, 4:04:20 AM, jim burns wrote:> Pls cc me with responses, as I''m not subscribed.
> 
> On Tue August 2 2011, 12:36:26 AM, Pasi Kärkkäinen wrote:
> > On Sat, Jul 30, 2011 at 06:28:26PM -0400, jim burns wrote:
> > > > solved the bare metal boot problem. I just got another
> > > > kernel-3.1.0-0.rc0 update (from git9.1 to git11.2).
Hopefully,
> > > > fedora has sorted out it''s kernel identity crisis!
> > >
> > > 
> > >
> > > Rawhide kernel 3.1.0-0.rc0.git11.2.fc17.x86_64 boots correctly
bare
> > > metal. It still reboots after the hypervisor output,
tho''. It''s
> > > around
> > > the time drm should kick in, but putting
''nomodeset'' on the kernel''s
> > > ''module'' line has no effect.
> >
> > 
> >
> > Konrad: Do you know if this is a known problem?
> >
> > 
> >
> > -- Pasi
> 
> On Mon August 15 2011, 1:43:23 AM, Konrad Rzeszutek Wilk wrote:
> > On Sun, Aug 14, 2011 at 06:41:37PM -0400, jim burns wrote:
> > > On Sun August 14 2011, 6:38:34 PM, jim burns wrote:
> > > > OK - replacing ''debug loglevel=8
video.allow_duplicates=1
> > > > nomodeset''
> > > > with ''nomodeset initcall_debug debug
loglevel=10''. (The video
> > > > option was left over  from a separate debug problem.) Log
> > > > included
> > > > - looks the same to me.> 
> > > 
> > > Ahem! And the log:
> > Yeah, this is the bug introduced by Andi. 3.1-rc2 has the fix. You are
> > looking for this git commit 06e727d2a5d9d889fabad35223ad77205a9bebb9
Yay! After a string of fedora rawhide 3.1.0-rc0 and -rc1''s that did not
boot
under xen, 3.1.0-0.rc2.git0.1.fc17.x86_64 boots under xen, it has the vga 
patch, and xen-pciback correctly siezes my wireless device. Unfortunately, 
while a baremetal boot is clean, a xen boot has several BUG:''s of the
form:

Aug 16 19:18:50 Insp6400 kernel: [   54.177011] BUG: scheduling while atomic: 
modprobe/519/0x10000002
Aug 16 19:18:50 Insp6400 kernel: [   54.177011] 3 locks held by modprobe/519:
Aug 16 19:18:50 Insp6400 kernel: [   54.177011]  #0:  
(&__lockdep_no_validate__){......}, at: [<ffffffff8131605c>] 
__driver_attach+0x3b/0x82
Aug 16 19:18:50 Insp6400 kernel: [   54.177011]  #1:  
(&__lockdep_no_validate__){......}, at: [<ffffffff8131606a>] 
__driver_attach+0x49/0x82
Aug 16 19:18:50 Insp6400 kernel: [   54.177011]  #2:  
(irq_mapping_update_lock){+.+.+.}, at: [<ffffffff812d90be>] 
xen_bind_pirq_msi_to_irq+0x31/0xda
Aug 16 19:18:50 Insp6400 kernel: [   54.177011] Modules linked in: snd_pcm(+) 
iwl3945(+) iwl_legacy dell_laptop microcode(+) r852 dcdbas mac80211 sm_common 
nand nand_ids b44 nand_ecc ssb r592 i2c_i801 snd_timer mtd memstick joydev mii 
cfg80211 snd iTCO_wdt rfkill soundcore iTCO_vendor_support snd_page_alloc tun 
xen_gntalloc xen_netback xen_blkback xen_gntdev xen_evtchn binfmt_misc xenfs 
sdhci_pci sdhci mmc_core firewire_ohci firewire_core crc_itu_t wmi i915 
drm_kms_helper drm i2c_algo_bit i2c_core video
Aug 16 19:18:50 Insp6400 kernel: [   54.177011] Pid: 519, comm: modprobe Not 
tainted 3.1.0-0.rc2.git0.1.fc17.x86_64 #1
Aug 16 19:18:50 Insp6400 kernel: [   54.177011] Call Trace:
--
Aug 16 19:18:50 Insp6400 kernel: [   56.075632] BUG: sleeping function called 
from invalid context at kernel/mutex.c:271
Aug 16 19:18:50 Insp6400 kernel: [   56.076126] in_atomic(): 1, 
irqs_disabled(): 0, pid: 506, name: modprobe
Aug 16 19:18:50 Insp6400 kernel: [   56.076126] 3 locks held by modprobe/506:
Aug 16 19:18:50 Insp6400 kernel: [   56.076126]  #0:  
(&__lockdep_no_validate__){......}, at: [<ffffffff8131605c>] 
__driver_attach+0x3b/0x82
Aug 16 19:18:50 Insp6400 kernel: [   56.076126]  #1:  
(&__lockdep_no_validate__){......}, at: [<ffffffff8131606a>] 
__driver_attach+0x49/0x82
Aug 16 19:18:50 Insp6400 kernel: [   56.076126]  #2:  
(irq_mapping_update_lock){+.+.+.}, at: [<ffffffff812d90be>] 
xen_bind_pirq_msi_to_irq+0x31/0xda
Aug 16 19:18:50 Insp6400 kernel: [   56.076126] Pid: 506, comm: modprobe Not 
tainted 3.1.0-0.rc2.git0.1.fc17.x86_64 #1
Aug 16 19:18:50 Insp6400 kernel: [   56.076126] Call Trace:

(and xenstored also is one of the ''comm:''s involved)

and INFO: errors of the form:

Aug 16 18:59:03 Insp6400 kernel: [   84.717079] [ INFO: HARDIRQ-safe -> 
HARDIRQ-unsafe lock order detected ]
Aug 16 18:59:03 Insp6400 kernel: [   84.717079] 3.1.0-0.rc2.git0.1.fc17.x86_64 
#1
Aug 16 18:59:03 Insp6400 kernel: [   84.717079] 
------------------------------------------------------
Aug 16 18:59:03 Insp6400 kernel: [   84.717079] make/1668 
[HC0[0]:SC1[3]:HE0:SE0] is trying to acquire:
Aug 16 18:59:03 Insp6400 kernel: [   84.727071]  (nf_conntrack_lock){+.-...}, 
at: [<ffffffffa03427b7>] destroy_conntrack+0x70/0xec [nf_conntrack]
Aug 16 18:59:03 Insp6400 kernel: [   84.727071] 
Aug 16 18:59:03 Insp6400 kernel: [   84.727071] and this task is already 
holding:
Aug 16 18:59:03 Insp6400 kernel: [   84.727071] 
(&(&bp->lock)->rlock)
{-.-...}, at: [<ffffffffa01efa6a>] b44_poll+0x28/0x3ec [b44]
--
Aug 16 18:59:38 Insp6400 kernel: [  119.749236] INFO: lockdep is turned off.
Aug 16 18:59:38 Insp6400 kernel: [  119.749236] Pid: 2999, comm: rc.local 
Tainted: G        W   3.1.0-0.rc2.git0.1.fc17.x86_64 #1
Aug 16 18:59:38 Insp6400 kernel: [  119.749236] Call Trace:
Aug 16 18:59:38 Insp6400 kernel: [  119.749236]  [<ffffffff8104f7bb>] 
__might_sleep+0x103/0x108
Aug 16 18:59:38 Insp6400 kernel: [  119.749236]  [<ffffffff814f7744>] 
mutex_lock_nested+0x25/0x45
Aug 16 18:59:38 Insp6400 kernel: [  119.749236]  [<ffffffff810c1f3e>] 
free_desc+0x30/0x64
Aug 16 18:59:38 Insp6400 kernel: [  119.749236]  [<ffffffff810c1fab>] 
irq_free_descs+0x39/0x72
Aug 16 18:59:38 Insp6400 kernel: [  119.749236]  [<ffffffff812d8424>] 
xen_free_irq+0x49/0x4e

so it still has a way to go to being stable.

I did bring up an hvm (winxp) domain as far as grub, and got more ''BUG:
sleeping function''s, so I ''xm destroy''-ed it, and
rebooted back into f15''s
2.6.40.

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

jim burns

2011-Aug-23 21:12 UTC

head link

Re: Re: Summary: Experiences setting up a debug serial port (was Re: [Xen-users] 3.1.0-rc0 git snapshot crashes as dom0 (private mail))

On Tue August 16 2011, 7:46:33 PM, jim burns wrote:> On Mon August 15 2011, 4:04:20 AM, jim burns wrote:
>> Pls cc me with responses, as I''m not subscribed.
> Yay! After a string of fedora rawhide 3.1.0-rc0 and -rc1''s that
did not
> boot  under xen, 3.1.0-0.rc2.git0.1.fc17.x86_64 boots under xen, it has the
> vga patch, and xen-pciback correctly siezes my wireless device.
> Unfortunately, while a baremetal boot is clean, a xen boot has several
> BUG:''s of the form:
Rawhide is up to 3.1.0-0.rc3.git0.0.fc17.x86_64 , and it still has the same 
BUGS: of the form:

BUG: scheduling while atomic: modprobe/493/0x10000002

BUG: sleeping function called from invalid context at kernel/mutex.c:271

BUG: scheduling while atomic: xenstored/3184/0x10000002

both while booting up under xen, and when starting and stopping a(n hvm) 
guest.

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

jim burns

2011-Aug-30 21:17 UTC

head link

Re: Summary: Experiences setting up a debug serial port (was Re: [Xen-users] 3.1.0-rc0 git snapshot crashes as dom0 (private mail))

On Tue August 23 2011, 5:12:52 PM, jim burns wrote:> On Tue August 16 2011, 7:46:33 PM, jim burns wrote:
> > On Mon August 15 2011, 4:04:20 AM, jim burns wrote:
> >> Pls cc me with responses, as I''m not subscribed.
> > 
> > Yay! After a string of fedora rawhide 3.1.0-rc0 and -rc1''s
that did not
> > boot  under xen, 3.1.0-0.rc2.git0.1.fc17.x86_64 boots under xen, it
has
> > the vga patch, and xen-pciback correctly siezes my wireless device.
> > Unfortunately, while a baremetal boot is clean, a xen boot has several
> 
> > BUG:''s of the form:
> Rawhide is up to 3.1.0-0.rc3.git0.0.fc17.x86_64 , and it still has the same
> BUGS: of the form:
> 
> BUG: scheduling while atomic: modprobe/493/0x10000002
> 
> BUG: sleeping function called from invalid context at kernel/mutex.c:271
> 
> BUG: scheduling while atomic: xenstored/3184/0x10000002
> 
> both while booting up under xen, and when starting and stopping a(n hvm)
> guest.
Rawhide is up to 3.1.0-0.rc4.git0.0.fc17 , and still the same bugs, plus the 
new one ''spinlock wrong CPU'':

Aug 30 17:07:13 Insp6400 kernel: [    9.657492] BUG: sleeping function called 
from invalid context at kernel/mutex.c:271
Aug 30 17:07:13 Insp6400 kernel: [    9.657553] in_atomic(): 1, 
irqs_disabled(): 0, pid: 254, name: modprobe
--
Aug 30 17:07:13 Insp6400 kernel: [    9.714251] BUG: scheduling while atomic: 
modprobe/254/0x10000002
Aug 30 17:07:13 Insp6400 kernel: [    9.715224] 3 locks held by modprobe/254:
--
Aug 30 17:07:13 Insp6400 kernel: [   52.675476] BUG: sleeping function called 
from invalid context at kernel/mutex.c:271
Aug 30 17:07:13 Insp6400 kernel: [   52.676191] in_atomic(): 1, 
irqs_disabled(): 0, pid: 511, name: modprobe
--
Aug 30 17:07:13 Insp6400 kernel: [   52.682754] BUG: scheduling while atomic: 
modprobe/511/0x10000002
Aug 30 17:07:13 Insp6400 kernel: [   52.682754] 3 locks held by modprobe/511:
--
Aug 30 17:07:13 Insp6400 kernel: [   52.867221] BUG: spinlock wrong CPU on 
CPU#1, modprobe/511
Aug 30 17:07:13 Insp6400 kernel: [   52.868082]  lock: ffffffff81a7de60, 
.magic: dead4ead, .owner: modprobe/511, .owner_cpu: 0
--
Aug 30 17:07:13 Insp6400 kernel: [   55.038559] BUG: sleeping function called 
from invalid context at kernel/mutex.c:271
Aug 30 17:07:13 Insp6400 kernel: [   55.039487] in_atomic(): 1, 
irqs_disabled(): 0, pid: 508, name: modprobe
--
Aug 30 17:07:13 Insp6400 kernel: [   55.039487] BUG: scheduling while atomic: 
modprobe/508/0x10000002
Aug 30 17:07:13 Insp6400 kernel: [   55.039487] INFO: lockdep is turned off.
--
Aug 30 17:07:13 Insp6400 kernel: [   55.153964] BUG: scheduling while atomic: 
modprobe/508/0x10000002
Aug 30 17:07:13 Insp6400 kernel: [   55.154664] INFO: lockdep is turned off.
--
Aug 30 17:08:04 Insp6400 kernel: [  117.158477] BUG: sleeping function called 
from invalid context at kernel/mutex.c:271
Aug 30 17:08:04 Insp6400 kernel: [  117.159068] in_atomic(): 1, 
irqs_disabled(): 0, pid: 3204, name: xenstored


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

Todd Deshane

2011-Aug-31 03:20 UTC

head link

Re: Summary: Experiences setting up a debug serial port (was Re: [Xen-users] 3.1.0-rc0 git snapshot crashes as dom0 (private mail))

(adding fedora-xen to the CC)

On Tue, Aug 30, 2011 at 5:17 PM, jim burns <jim_burn@bellsouth.net>
wrote:> On Tue August 23 2011, 5:12:52 PM, jim burns wrote:
>> On Tue August 16 2011, 7:46:33 PM, jim burns wrote:
>> > On Mon August 15 2011, 4:04:20 AM, jim burns wrote:
>> >> Pls cc me with responses, as I''m not subscribed.
>> >
>> > Yay! After a string of fedora rawhide 3.1.0-rc0 and
-rc1''s that did not
>> > boot  under xen, 3.1.0-0.rc2.git0.1.fc17.x86_64 boots under xen,
it has
>> > the vga patch, and xen-pciback correctly siezes my wireless
device.
>> > Unfortunately, while a baremetal boot is clean, a xen boot has
several
>>
>> > BUG:''s of the form:
>> Rawhide is up to 3.1.0-0.rc3.git0.0.fc17.x86_64 , and it still has the
same
>> BUGS: of the form:
>>
>> BUG: scheduling while atomic: modprobe/493/0x10000002
>>
>> BUG: sleeping function called from invalid context at
kernel/mutex.c:271
>>
>> BUG: scheduling while atomic: xenstored/3184/0x10000002
>>
>> both while booting up under xen, and when starting and stopping a(n
hvm)
>> guest.
>
> Rawhide is up to 3.1.0-0.rc4.git0.0.fc17 , and still the same bugs, plus
the
> new one ''spinlock wrong CPU'':
>
> Aug 30 17:07:13 Insp6400 kernel: [    9.657492] BUG: sleeping function
called
> from invalid context at kernel/mutex.c:271
> Aug 30 17:07:13 Insp6400 kernel: [    9.657553] in_atomic(): 1,
> irqs_disabled(): 0, pid: 254, name: modprobe
> --
> Aug 30 17:07:13 Insp6400 kernel: [    9.714251] BUG: scheduling while
atomic:
> modprobe/254/0x10000002
> Aug 30 17:07:13 Insp6400 kernel: [    9.715224] 3 locks held by
modprobe/254:
> --
> Aug 30 17:07:13 Insp6400 kernel: [   52.675476] BUG: sleeping function
called
> from invalid context at kernel/mutex.c:271
> Aug 30 17:07:13 Insp6400 kernel: [   52.676191] in_atomic(): 1,
> irqs_disabled(): 0, pid: 511, name: modprobe
> --
> Aug 30 17:07:13 Insp6400 kernel: [   52.682754] BUG: scheduling while
atomic:
> modprobe/511/0x10000002
> Aug 30 17:07:13 Insp6400 kernel: [   52.682754] 3 locks held by
modprobe/511:
> --
> Aug 30 17:07:13 Insp6400 kernel: [   52.867221] BUG: spinlock wrong CPU on
> CPU#1, modprobe/511
> Aug 30 17:07:13 Insp6400 kernel: [   52.868082]  lock: ffffffff81a7de60,
> .magic: dead4ead, .owner: modprobe/511, .owner_cpu: 0
> --
> Aug 30 17:07:13 Insp6400 kernel: [   55.038559] BUG: sleeping function
called
> from invalid context at kernel/mutex.c:271
> Aug 30 17:07:13 Insp6400 kernel: [   55.039487] in_atomic(): 1,
> irqs_disabled(): 0, pid: 508, name: modprobe
> --
> Aug 30 17:07:13 Insp6400 kernel: [   55.039487] BUG: scheduling while
atomic:
> modprobe/508/0x10000002
> Aug 30 17:07:13 Insp6400 kernel: [   55.039487] INFO: lockdep is turned
off.
> --
> Aug 30 17:07:13 Insp6400 kernel: [   55.153964] BUG: scheduling while
atomic:
> modprobe/508/0x10000002
> Aug 30 17:07:13 Insp6400 kernel: [   55.154664] INFO: lockdep is turned
off.
> --
> Aug 30 17:08:04 Insp6400 kernel: [  117.158477] BUG: sleeping function
called
> from invalid context at kernel/mutex.c:271
> Aug 30 17:08:04 Insp6400 kernel: [  117.159068] in_atomic(): 1,
> irqs_disabled(): 0, pid: 3204, name: xenstored
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
>


-- 
Todd Deshane
http://www.linkedin.com/in/deshantm
http://www.xen.org/products/cloudxen.html
http://runningxen.com/

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

jim burns

2011-Sep-09 00:36 UTC

head link

[Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

On Tue August 30 2011, 11:20:45 PM, Todd Deshane wrote:> (adding fedora-xen to the CC)
> 
> On Tue, Aug 30, 2011 at 5:17 PM, jim burns <jim_burn@bellsouth.net>
wrote:
> > On Tue August 23 2011, 5:12:52 PM, jim burns wrote:
> >> On Tue August 16 2011, 7:46:33 PM, jim burns wrote:
> >> > On Mon August 15 2011, 4:04:20 AM, jim burns wrote:
> >> >> Pls cc me with responses, as I''m not subscribed.
> >> > 
> >> > Yay! After a string of fedora rawhide 3.1.0-rc0 and
-rc1''s that
> >> > did not boot  under xen, 3.1.0-0.rc2.git0.1.fc17.x86_64 boots
> >> > under xen, it has the vga patch, and xen-pciback correctly
siezes
> >> > my wireless device. Unfortunately, while a baremetal boot is
> >> > clean, a xen boot has several BUG:''s of the form:
> >> Rawhide is up to 3.1.0-0.rc3.git0.0.fc17.x86_64 , and it still has
the
> >> same BUGS: of the form:
> >> 
> >> BUG: scheduling while atomic: modprobe/493/0x10000002
> >> 
> >> BUG: sleeping function called from invalid context at
> >> kernel/mutex.c:271
> >> 
> >> BUG: scheduling while atomic: xenstored/3184/0x10000002
> >> 
> >> both while booting up under xen, and when starting and stopping
a(n
> >> hvm) guest.
> > 
> > Rawhide is up to 3.1.0-0.rc4.git0.0.fc17 , and still the same bugs,
plus
> > the new one ''spinlock wrong CPU'':
> > 
> > Aug 30 17:07:13 Insp6400 kernel: [    9.657492] BUG: sleeping function
> > called from invalid context at kernel/mutex.c:271
> > Aug 30 17:07:13 Insp6400 kernel: [    9.657553] in_atomic(): 1,
> > irqs_disabled(): 0, pid: 254, name: modprobe
> > --
> > Aug 30 17:07:13 Insp6400 kernel: [    9.714251] BUG: scheduling while
> > atomic: modprobe/254/0x10000002
> > Aug 30 17:07:13 Insp6400 kernel: [    9.715224] 3 locks held by
> > modprobe/254:
> > --
> > Aug 30 17:07:13 Insp6400 kernel: [   52.675476] BUG: sleeping function
> > called from invalid context at kernel/mutex.c:271
> > Aug 30 17:07:13 Insp6400 kernel: [   52.676191] in_atomic(): 1,
> > irqs_disabled(): 0, pid: 511, name: modprobe
> > --
> > Aug 30 17:07:13 Insp6400 kernel: [   52.682754] BUG: scheduling while
> > atomic: modprobe/511/0x10000002
> > Aug 30 17:07:13 Insp6400 kernel: [   52.682754] 3 locks held by
> > modprobe/511:
> > --
> > Aug 30 17:07:13 Insp6400 kernel: [   52.867221] BUG: spinlock wrong
CPU
> > on CPU#1, modprobe/511
> > Aug 30 17:07:13 Insp6400 kernel: [   52.868082]  lock:
ffffffff81a7de60,
> > .magic: dead4ead, .owner: modprobe/511, .owner_cpu: 0
> > --
> > Aug 30 17:07:13 Insp6400 kernel: [   55.038559] BUG: sleeping function
> > called from invalid context at kernel/mutex.c:271
> > Aug 30 17:07:13 Insp6400 kernel: [   55.039487] in_atomic(): 1,
> > irqs_disabled(): 0, pid: 508, name: modprobe
> > --
> > Aug 30 17:07:13 Insp6400 kernel: [   55.039487] BUG: scheduling while
> > atomic: modprobe/508/0x10000002
> > Aug 30 17:07:13 Insp6400 kernel: [   55.039487] INFO: lockdep is
turned
> > off.
> > --
> > Aug 30 17:07:13 Insp6400 kernel: [   55.153964] BUG: scheduling while
> > atomic: modprobe/508/0x10000002
> > Aug 30 17:07:13 Insp6400 kernel: [   55.154664] INFO: lockdep is
turned
> > off.
> > --
> > Aug 30 17:08:04 Insp6400 kernel: [  117.158477] BUG: sleeping function
> > called from invalid context at kernel/mutex.c:271
> > Aug 30 17:08:04 Insp6400 kernel: [  117.159068] in_atomic(): 1,
> > irqs_disabled(): 0, pid: 3204, name: xenstored
Rawhide is up to 3.1.0-0.rc5.git0.0.fc17 , and still the same dom0 boot bugs 
as in rc4.

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

Pasi Kärkkäinen

2011-Sep-09 13:14 UTC

head link

[Xen-devel] Re: Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

Hello,

Added xen-devel to CC..

On Thu, Sep 08, 2011 at 08:36:04PM -0400, jim burns
wrote:> 
> Rawhide is up to 3.1.0-0.rc5.git0.0.fc17 , and still the same dom0 boot
bugs
> as in rc4.
Can you please post the full Xen + 3.1-rc5 dom0 boot logs again..

-- Pasi


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

jim burns

2011-Sep-09 13:52 UTC

head link

[Xen-devel] Re: Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

On Fri September 9 2011, 4:14:38 PM, Pasi Kärkkäinen
wrote:> Hello,
> 
> Added xen-devel to CC..
> 
> On Thu, Sep 08, 2011 at 08:36:04PM -0400, jim burns wrote:
> > Rawhide is up to 3.1.0-0.rc5.git0.0.fc17 , and still the same dom0
boot
> > bugs as in rc4.
> 
> Can you please post the full Xen + 3.1-rc5 dom0 boot logs again..
> 
> -- Pasi
Sure, thanx, attached. Do you need a debug log also (initcall_debug debug 
loglevel=10)?

The last four BUG:s (from Sep  8 17:12:20 on) were from starting a winxp domu 
(first 3 BUG:s), and destroying it at grub (the last BUG:).


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

Pasi Kärkkäinen

2011-Sep-12 07:36 UTC

head link

[Xen-devel] Re: Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

On Fri, Sep 09, 2011 at 09:52:41AM -0400, jim burns
wrote:> On Fri September 9 2011, 4:14:38 PM, Pasi Kärkkäinen wrote:
> > Hello,
> > 
> > Added xen-devel to CC..
> > 
> > On Thu, Sep 08, 2011 at 08:36:04PM -0400, jim burns wrote:
> > > Rawhide is up to 3.1.0-0.rc5.git0.0.fc17 , and still the same
dom0 boot
> > > bugs as in rc4.
> > 
> > Can you please post the full Xen + 3.1-rc5 dom0 boot logs again..
> > 
> > -- Pasi
> 
> Sure, thanx, attached. Do you need a debug log also (initcall_debug debug 
> loglevel=10)?
> 
Sure, it doesn''t hurt..

> The last four BUG:s (from Sep  8 17:12:20 on) were from starting a winxp
domu
> (first 3 BUG:s), and destroying it at grub (the last BUG:).
>
Ok, so there are BUGs when booting up, and also when starting HVM guests.

-- Pasi

> Sep  8 16:59:12 Insp6400 kernel: imklog 5.8.2, log source = /proc/kmsg
started.
> Sep  8 16:59:12 Insp6400 rsyslogd: [origin software="rsyslogd"
swVersion="5.8.2" x-pid="789"
x-info="http://www.rsyslog.com"] start
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] Initializing cgroup subsys
cpuset
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] Initializing cgroup subsys
cpu
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] Linux version
3.1.0-0.rc5.git0.0.fc17.x86_64 (mockbuild@x86-06.phx2.fedoraproject.org) (gcc
version 4.6.1 20110804 (Red Hat 4.6.1-7) (GCC) ) #1 SMP Wed Sep 7 20:28:26 UTC
2011
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] Command line: ro
root=/dev/mapper/vg_insp6400-lv_root SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8
KEYTABLE=us xen-pciback.permissive xen-pciback.hide=(0b:00.0)
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] released 0 pages of unused
memory
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] Set 526733 page(s) to 1-1
mapping.
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] BIOS-provided physical RAM
map:
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000]  Xen: 0000000000000000 -
000000000009f000 (usable)
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000]  Xen: 000000000009f000 -
0000000000100000 (reserved)
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000]  Xen: 0000000000100000 -
0000000075fce000 (usable)
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000]  Xen: 0000000075fce000 -
000000007f6d3000 (unusable)
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000]  Xen: 000000007f6d3400 -
0000000080000000 (reserved)
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000]  Xen: 00000000f0000000 -
00000000f4007000 (reserved)
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000]  Xen: 00000000f4008000 -
00000000f400c000 (reserved)
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000]  Xen: 00000000fec00000 -
00000000fec10000 (reserved)
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000]  Xen: 00000000fed20000 -
00000000feda0000 (reserved)
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000]  Xen: 00000000fee00000 -
00000000fee10000 (reserved)
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000]  Xen: 00000000ffb00000 -
0000000100000000 (reserved)
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000]  Xen: 0000000100000000 -
0000000109705000 (usable)
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] NX (Execute Disable)
protection: active
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] DMI 2.4 present.
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] No AGP bridge found
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] last_pfn = 0x109705
max_arch_pfn = 0x400000000
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] last_pfn = 0x75fce
max_arch_pfn = 0x400000000
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] init_memory_mapping:
0000000000000000-0000000075fce000
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] init_memory_mapping:
0000000100000000-0000000109705000
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] RAMDISK: 02ae5000 -
0533f000
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] ACPI: RSDP 00000000000fc1d0
00014 (v00 DELL  )
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] ACPI: RSDT 000000007f6d3a0f
00040 (v01 DELL    M07     27D7060D ASL  00000061)
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] ACPI: FACP 000000007f6d4800
00074 (v01 DELL    M07     27D7060D ASL  00000061)
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] ACPI: DSDT 000000007f6d5400
04766 (v01 INT430 SYSFexxx 00001001 INTL 20050624)
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] ACPI: FACS 000000007f6e3c00
00040
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] ACPI: HPET 000000007f6d4f00
00038 (v01 DELL    M07     00000001 ASL  00000061)
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] ACPI: APIC 000000007f6d5000
00068 (v01 DELL    M07     27D7060D ASL  00000047)
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] ACPI: MCFG 000000007f6d4fc0
0003E (v16 DELL    M07     27D7060D ASL  00000061)
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] ACPI: SLIC 000000007f6d509c
00176 (v01 DELL    M07     27D7060D ASL  00000061)
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] ACPI: BOOT 000000007f6d4bc0
00028 (v01 DELL    M07     27D7060D ASL  00000061)
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] ACPI: SSDT 000000007f6d3a4f
004DC (v01  PmRef    CpuPm 00003000 INTL 20050624)
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] No NUMA configuration found
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] Faking a node at
0000000000000000-0000000109705000
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] Initmem setup node 0
0000000000000000-0000000109705000
> Sep  8 16:59:10 Insp6400 avahi-daemon[755]: Found user
''avahi'' (UID 498) and group ''avahi'' (GID
491).
> Sep  8 16:59:10 Insp6400 avahi-daemon[755]: Successfully dropped root
privileges.
> Sep  8 16:59:10 Insp6400 avahi-daemon[755]: avahi-daemon 0.6.30 starting
up.
> Sep  8 16:59:10 Insp6400 avahi-daemon[755]: WARNING: No NSS support for
mDNS detected, consider installing nss-mdns!
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000]   NODE_DATA
[0000000075fb9000 - 0000000075fcdfff]
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] Zone PFN ranges:
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000]   DMA      0x00000010 ->
0x00001000
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000]   DMA32    0x00001000 ->
0x00100000
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000]   Normal   0x00100000 ->
0x00109705
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] Movable zone start PFN for
each node
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] early_node_map[3] active
PFN ranges
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000]     0: 0x00000010 ->
0x0000009f
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000]     0: 0x00000100 ->
0x00075fce
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000]     0: 0x00100000 ->
0x00109705
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] ACPI: PM-Timer IO Port:
0x1008
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] ACPI: LAPIC (acpi_id[0x00]
lapic_id[0x00] enabled)
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] BIOS bug: APIC version is 0
for CPU 0/0x0, fixing up to 0x10
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] ACPI: LAPIC (acpi_id[0x01]
lapic_id[0x01] enabled)
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] ACPI: LAPIC_NMI
(acpi_id[0x00] high edge lint[0x1])
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] ACPI: LAPIC_NMI
(acpi_id[0x01] high edge lint[0x1])
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] ACPI: IOAPIC (id[0x02]
address[0xfec00000] gsi_base[0])
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] IOAPIC[0]: apic_id 2,
version 255, address 0xfec00000, GSI 0-255
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] ACPI: INT_SRC_OVR (bus 0
bus_irq 0 global_irq 2 dfl dfl)
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] ACPI: INT_SRC_OVR (bus 0
bus_irq 9 global_irq 9 high level)
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] Using ACPI (MADT) for SMP
configuration information
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] ACPI: HPET id: 0x8086a201
base: 0xfed00000
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] SMP: Allowing 2 CPUs, 0
hotplug CPUs
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] PM: Registered nosave
memory: 000000000009f000 - 0000000000100000
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] PM: Registered nosave
memory: 0000000075fce000 - 000000007f6d3000
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] PM: Registered nosave
memory: 000000007f6d3000 - 000000007f6d4000
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] PM: Registered nosave
memory: 000000007f6d4000 - 0000000080000000
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] PM: Registered nosave
memory: 0000000080000000 - 00000000f0000000
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] PM: Registered nosave
memory: 00000000f0000000 - 00000000f4007000
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] PM: Registered nosave
memory: 00000000f4007000 - 00000000f4008000
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] PM: Registered nosave
memory: 00000000f4008000 - 00000000f400c000
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] PM: Registered nosave
memory: 00000000f400c000 - 00000000fec00000
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] PM: Registered nosave
memory: 00000000fec00000 - 00000000fec10000
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] PM: Registered nosave
memory: 00000000fec10000 - 00000000fed20000
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] PM: Registered nosave
memory: 00000000fed20000 - 00000000feda0000
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] PM: Registered nosave
memory: 00000000feda0000 - 00000000fee00000
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] PM: Registered nosave
memory: 00000000fee00000 - 00000000fee10000
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] PM: Registered nosave
memory: 00000000fee10000 - 00000000ffb00000
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] PM: Registered nosave
memory: 00000000ffb00000 - 0000000100000000
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] Allocating PCI resources
starting at 80000000 (gap: 80000000:70000000)
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] Booting paravirtualized
kernel on Xen
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] Xen version: 4.1.1
(preserve-AD)
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] setup_percpu: NR_CPUS:512
nr_cpumask_bits:512 nr_cpu_ids:2 nr_node_ids:1
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] PERCPU: Embedded 476
pages/cpu @ffff88007575b000 s1918464 r8192 d23040 u1949696
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] Built 1 zonelists in Node
order, mobility grouping on.  Total pages: 504832
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] Policy zone: Normal
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] Kernel command line: ro
root=/dev/mapper/vg_insp6400-lv_root SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8
KEYTABLE=us xen-pciback.permissive xen-pciback.hide=(0b:00.0)
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] PID hash table entries:
4096 (order: 3, 32768 bytes)
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] Placing 64MB software IO
TLB between ffff88006f000000 - ffff880073000000
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] software IO TLB at phys
0x6f000000 - 0x73000000
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] Memory: 1751204k/4348948k
available (5185k kernel code, 2261644k absent, 336100k reserved, 6577k data,
2780k init)
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] SLUB: Genslabs=15,
HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] Hierarchical RCU
implementation.
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] 	RCU dyntick-idle
grace-period acceleration is enabled.
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] 	RCU lockdep checking is
enabled.
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] NR_IRQS:33024 nr_irqs:512
16
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] xen: sci override:
global_irq=9 trigger=0 polarity=0
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] xen: acpi sci 9
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] xen_map_pirq_gsi: returning
irq 9 for gsi 9
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] Console: colour VGA+ 80x25
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] console [tty0] enabled
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] Lock dependency validator:
Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] ... MAX_LOCKDEP_SUBCLASSES:
8
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] ... MAX_LOCK_DEPTH:        
48
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] ... MAX_LOCKDEP_KEYS:      
8191
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] ... CLASSHASH_SIZE:        
4096
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] ... MAX_LOCKDEP_ENTRIES:   
16384
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] ... MAX_LOCKDEP_CHAINS:    
32768
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] ... CHAINHASH_SIZE:        
16384
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000]  memory used by lock
dependency info: 6367 kB
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000]  per task-struct memory
footprint: 2688 bytes
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] allocated 17825792 bytes of
page_cgroup
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] please try
''cgroup_disable=memory'' option if you don''t want
memory cgroups
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] installing Xen timer for
CPU 0
> Sep  8 16:59:12 Insp6400 kernel: [    0.000000] Detected 1828.796 MHz
processor.
> Sep  8 16:59:12 Insp6400 kernel: [    0.000999] Calibrating delay loop
(skipped), value calculated using timer frequency.. 3657.59 BogoMIPS
(lpj=1828796)
> Sep  8 16:59:12 Insp6400 kernel: [    0.000999] pid_max: default: 32768
minimum: 301
> Sep  8 16:59:12 Insp6400 kernel: [    0.000999] Security Framework
initialized
> Sep  8 16:59:12 Insp6400 kernel: [    0.000999] SELinux:  Initializing.
> Sep  8 16:59:12 Insp6400 kernel: [    0.002648] Dentry cache hash table
entries: 262144 (order: 9, 2097152 bytes)
> Sep  8 16:59:12 Insp6400 kernel: [    0.005103] Inode-cache hash table
entries: 131072 (order: 8, 1048576 bytes)
> Sep  8 16:59:12 Insp6400 kernel: [    0.005999] Mount-cache hash table
entries: 256
> Sep  8 16:59:12 Insp6400 kernel: [    0.009803] Initializing cgroup subsys
cpuacct
> Sep  8 16:59:12 Insp6400 kernel: [    0.009974] Initializing cgroup subsys
memory
> Sep  8 16:59:12 Insp6400 kernel: [    0.010283] Initializing cgroup subsys
devices
> Sep  8 16:59:12 Insp6400 kernel: [    0.010428] Initializing cgroup subsys
freezer
> Sep  8 16:59:12 Insp6400 kernel: [    0.010561] Initializing cgroup subsys
net_cls
> Sep  8 16:59:12 Insp6400 kernel: [    0.010696] Initializing cgroup subsys
blkio
> Sep  8 16:59:12 Insp6400 kernel: [    0.010979] Initializing cgroup subsys
perf_event
> Sep  8 16:59:12 Insp6400 kernel: [    0.011518] CPU: Physical Processor ID:
0
> Sep  8 16:59:12 Insp6400 kernel: [    0.011639] CPU: Processor Core ID: 0
> Sep  8 16:59:12 Insp6400 kernel: [    0.012814] ACPI: Core revision
20110623
> Sep  8 16:59:12 Insp6400 kernel: [    0.072895] ftrace: allocating 25821
entries in 102 pages
> Sep  8 16:59:12 Insp6400 kernel: [    0.075083] Performance Events:
unsupported p6 CPU model 15 no PMU driver, software events only.
> Sep  8 16:59:12 Insp6400 kernel: [    0.076993] NMI watchdog disabled
(cpu0): hardware events not enabled
> Sep  8 16:59:12 Insp6400 kernel: [    0.078517] installing Xen timer for
CPU 1
> Sep  8 16:59:12 Insp6400 kernel: [    0.078827] lockdep: fixing up
alternatives.
> Sep  8 16:59:12 Insp6400 kernel: [    0.079572] NMI watchdog disabled
(cpu1): hardware events not enabled
> Sep  8 16:59:12 Insp6400 kernel: [    0.079944] Brought up 2 CPUs
> Sep  8 16:59:12 Insp6400 kernel: [    0.083384] devtmpfs: initialized
> Sep  8 16:59:12 Insp6400 kernel: [    0.098213] atomic64 test passed for
x86-64 platform with CX8 and with SSE
> Sep  8 16:59:12 Insp6400 kernel: [    0.098681] Grant table initialized
> Sep  8 16:59:12 Insp6400 kernel: [    0.098839] RTC time: 20:58:03, date:
09/08/11
> Sep  8 16:59:12 Insp6400 kernel: [    0.099810] NET: Registered protocol
family 16
> Sep  8 16:59:12 Insp6400 kernel: [    0.106273] ACPI: bus type pci
registered
> Sep  8 16:59:12 Insp6400 kernel: [    0.107787] PCI: MMCONFIG for domain
0000 [bus 00-3f] at [mem 0xf0000000-0xf3ffffff] (base 0xf0000000)
> Sep  8 16:59:12 Insp6400 kernel: [    0.107988] PCI: MMCONFIG at [mem
0xf0000000-0xf3ffffff] reserved in E820
> Sep  8 16:59:12 Insp6400 kernel: [    0.131441] PCI: Using configuration
type 1 for base access
> Sep  8 16:59:12 Insp6400 kernel: [    0.131566] dmi type 0xB1 record -
unknown flag
> Sep  8 16:59:12 Insp6400 kernel: [    0.156193] bio: create slab
<bio-0> at 0
> Sep  8 16:59:12 Insp6400 kernel: [    0.157763] ACPI: Added _OSI(Module
Device)
> Sep  8 16:59:12 Insp6400 kernel: [    0.157905] ACPI: Added _OSI(Processor
Device)
> Sep  8 16:59:12 Insp6400 kernel: [    0.157984] ACPI: Added _OSI(3.0 _SCP
Extensions)
> Sep  8 16:59:12 Insp6400 kernel: [    0.157984] ACPI: Added _OSI(Processor
Aggregator Device)
> Sep  8 16:59:12 Insp6400 kernel: [    0.198978] ACPI: SSDT 000000007f6d4176
00202 (v01  PmRef  Cpu0Ist 00003000 INTL 20050624)
> Sep  8 16:59:12 Insp6400 kernel: [    0.198978] ACPI: Dynamic OEM Table
Load:
> Sep  8 16:59:12 Insp6400 kernel: [    0.198978] ACPI: SSDT           (null)
00202 (v01  PmRef  Cpu0Ist 00003000 INTL 20050624)
> Sep  8 16:59:12 Insp6400 kernel: [    0.198978] ACPI: SSDT 000000007f6d3f2b
001C6 (v01  PmRef  Cpu0Cst 00003001 INTL 20050624)
> Sep  8 16:59:12 Insp6400 kernel: [    0.198978] ACPI: Dynamic OEM Table
Load:
> Sep  8 16:59:12 Insp6400 kernel: [    0.198978] ACPI: SSDT           (null)
001C6 (v01  PmRef  Cpu0Cst 00003001 INTL 20050624)
> Sep  8 16:59:12 Insp6400 kernel: [    0.198978] ACPI: SSDT 000000007f6d4378
000C4 (v01  PmRef  Cpu1Ist 00003000 INTL 20050624)
> Sep  8 16:59:12 Insp6400 kernel: [    0.198978] ACPI: Dynamic OEM Table
Load:
> Sep  8 16:59:12 Insp6400 kernel: [    0.198978] ACPI: SSDT           (null)
000C4 (v01  PmRef  Cpu1Ist 00003000 INTL 20050624)
> Sep  8 16:59:12 Insp6400 kernel: [    0.200036] ACPI: SSDT 000000007f6d40f1
00085 (v01  PmRef  Cpu1Cst 00003000 INTL 20050624)
> Sep  8 16:59:12 Insp6400 kernel: [    0.200978] ACPI: Dynamic OEM Table
Load:
> Sep  8 16:59:12 Insp6400 kernel: [    0.200978] ACPI: SSDT           (null)
00085 (v01  PmRef  Cpu1Cst 00003000 INTL 20050624)
> Sep  8 16:59:12 Insp6400 kernel: [    0.200978] ACPI: Interpreter enabled
> Sep  8 16:59:12 Insp6400 kernel: [    0.200978] ACPI: (supports S0 S3 S4
S5)
> Sep  8 16:59:12 Insp6400 kernel: [    0.200978] ACPI: Using IOAPIC for
interrupt routing
> Sep  8 16:59:12 Insp6400 kernel: [    0.482935] ACPI: No dock devices
found.
> Sep  8 16:59:12 Insp6400 kernel: [    0.482935] HEST: Table not found.
> Sep  8 16:59:12 Insp6400 kernel: [    0.482935] PCI: Ignoring host bridge
windows from ACPI; if necessary, use "pci=use_crs" and report a bug
> Sep  8 16:59:12 Insp6400 kernel: [    0.503932] ACPI: PCI Root Bridge
[PCI0] (domain 0000 [bus 00-ff])
> Sep  8 16:59:12 Insp6400 kernel: [    0.553924] pci 0000:00:1f.0: quirk:
[io  0x1000-0x107f] claimed by ICH6 ACPI/GPIO/TCO
> Sep  8 16:59:12 Insp6400 kernel: [    0.553924] pci 0000:00:1f.0: quirk:
[io  0x1080-0x10bf] claimed by ICH6 GPIO
> Sep  8 16:59:12 Insp6400 kernel: [    0.553924] pci 0000:00:1f.0: ICH7 LPC
Generic IO decode 1 PIO at 0900 (mask 007f)
> Sep  8 16:59:12 Insp6400 kernel: [    0.553924] pci 0000:00:1f.0: ICH7 LPC
Generic IO decode 3 PIO at 0c80 (mask 003f)
> Sep  8 16:59:12 Insp6400 kernel: [    0.556351] pci 0000:0b:00.0: disabling
ASPM on pre-1.1 PCIe device.  You can enable it with
''pcie_aspm=force''
> Sep  8 16:59:12 Insp6400 kernel: [    0.556718] pci 0000:00:1c.0: PCI
bridge to [bus 0b-0b]
> Sep  8 16:59:12 Insp6400 kernel: [    0.557827] pci 0000:00:1c.3: PCI
bridge to [bus 0c-0d]
> Sep  8 16:59:12 Insp6400 kernel: [    0.560923] pci 0000:00:1e.0: PCI
bridge to [bus 03-03] (subtractive decode)
> Sep  8 16:59:12 Insp6400 kernel: [    0.560923] pci 0000:00:1c.0: Dev MPS
128 MPSS 128 MRRS 128
> Sep  8 16:59:12 Insp6400 kernel: [    0.560923] pci 0000:00:1c.0: Dev MPS
128 MPSS 128 MRRS 128
> Sep  8 16:59:12 Insp6400 kernel: [    0.560923] pci 0000:0b:00.0: Dev MPS
128 MPSS 128 MRRS 128
> Sep  8 16:59:12 Insp6400 kernel: [    0.560923] pci 0000:0b:00.0: Dev MPS
128 MPSS 128 MRRS 128
> Sep  8 16:59:12 Insp6400 kernel: [    0.560923] pci 0000:00:1c.3: Dev MPS
128 MPSS 128 MRRS 128
> Sep  8 16:59:12 Insp6400 kernel: [    0.560923] pci 0000:00:1c.3: Dev MPS
128 MPSS 128 MRRS 128
> Sep  8 16:59:12 Insp6400 kernel: [    0.560923] pci 0000:0c:00.0: Dev MPS
128 MPSS 128 MRRS 512
> Sep  8 16:59:12 Insp6400 kernel: [    0.560923] pci 0000:0c:00.0: Dev MPS
128 MPSS 128 MRRS 128
> Sep  8 16:59:12 Insp6400 kernel: [    0.563923]  pci0000:00: Requesting
ACPI _OSC control (0x1d)
> Sep  8 16:59:12 Insp6400 kernel: [    0.563923]  pci0000:00: ACPI _OSC
request failed (AE_NOT_FOUND), returned control mask: 0x1d
> Sep  8 16:59:12 Insp6400 kernel: [    0.563923] ACPI _OSC control for PCIe
not granted, disabling ASPM
> Sep  8 16:59:12 Insp6400 kernel: [    0.596918] ACPI: PCI Interrupt Link
[LNKA] (IRQs 9 10 *11)
> Sep  8 16:59:12 Insp6400 kernel: [    0.597918] ACPI: PCI Interrupt Link
[LNKB] (IRQs 5 7) *4
> Sep  8 16:59:12 Insp6400 kernel: [    0.598917] ACPI: PCI Interrupt Link
[LNKC] (IRQs 9 10 *11)
> Sep  8 16:59:12 Insp6400 kernel: [    0.599917] ACPI: PCI Interrupt Link
[LNKD] (IRQs 5 7 9 10 11) *3
> Sep  8 16:59:12 Insp6400 kernel: [    0.601917] ACPI: PCI Interrupt Link
[LNKE] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
> Sep  8 16:59:12 Insp6400 kernel: [    0.602917] ACPI: PCI Interrupt Link
[LNKF] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
> Sep  8 16:59:12 Insp6400 kernel: [    0.603917] ACPI: PCI Interrupt Link
[LNKG] (IRQs 3 4 5 6 *7 9 10 11 12 14 15)
> Sep  8 16:59:12 Insp6400 kernel: [    0.604917] ACPI: PCI Interrupt Link
[LNKH] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
> Sep  8 16:59:12 Insp6400 kernel: [    0.605055] xen/balloon: Initialising
balloon driver.
> Sep  8 16:59:12 Insp6400 kernel: [    0.605209] last_pfn = 0x109705
max_arch_pfn = 0x400000000
> Sep  8 16:59:12 Insp6400 kernel: [    0.607009] xen-balloon: Initialising
balloon driver.
> Sep  8 16:59:12 Insp6400 kernel: [    0.607682] xen/balloon: Xen
selfballooning driver disabled for domain0.
> Sep  8 16:59:12 Insp6400 kernel: [    0.608752] vgaarb: device added:
PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none
> Sep  8 16:59:12 Insp6400 kernel: [    0.608916] vgaarb: loaded
> Sep  8 16:59:12 Insp6400 kernel: [    0.608916] vgaarb: bridge control
possible 0000:00:02.0
> Sep  8 16:59:12 Insp6400 kernel: [    0.611750] SCSI subsystem initialized
> Sep  8 16:59:12 Insp6400 kernel: [    0.613519] usbcore: registered new
interface driver usbfs
> Sep  8 16:59:12 Insp6400 kernel: [    0.613915] usbcore: registered new
interface driver hub
> Sep  8 16:59:12 Insp6400 kernel: [    0.614163] usbcore: registered new
device driver usb
> Sep  8 16:59:12 Insp6400 kernel: [    0.615756] PCI: Using ACPI for IRQ
routing
> Sep  8 16:59:12 Insp6400 kernel: [    0.618444] NetLabel: Initializing
> Sep  8 16:59:12 Insp6400 kernel: [    0.618560] NetLabel:  domain hash size
= 128
> Sep  8 16:59:12 Insp6400 kernel: [    0.618677] NetLabel:  protocols =
UNLABELED CIPSOv4
> Sep  8 16:59:12 Insp6400 kernel: [    0.618914] NetLabel:  unlabeled
traffic allowed by default
> Sep  8 16:59:12 Insp6400 kernel: [    0.618914] Switching to clocksource
xen
> Sep  8 16:59:12 Insp6400 kernel: [    0.619312] Switched to NOHz mode on
CPU #1
> Sep  8 16:59:12 Insp6400 kernel: [    0.620099] Switched to NOHz mode on
CPU #0
> Sep  8 16:59:12 Insp6400 kernel: [    0.989037] pnp: PnP ACPI init
> Sep  8 16:59:12 Insp6400 kernel: [    0.989190] ACPI: bus type pnp
registered
> Sep  8 16:59:12 Insp6400 kernel: [    1.456722] system 00:00: [mem
0x00000000-0x0009fbff] could not be reserved
> Sep  8 16:59:12 Insp6400 kernel: [    1.456898] system 00:00: [mem
0x0009fc00-0x0009ffff] could not be reserved
> Sep  8 16:59:12 Insp6400 kernel: [    1.457013] system 00:00: [mem
0x000c0000-0x000cffff] could not be reserved
> Sep  8 16:59:12 Insp6400 kernel: [    1.457013] system 00:00: [mem
0x000e0000-0x000fffff] could not be reserved
> Sep  8 16:59:12 Insp6400 kernel: [    1.457013] system 00:00: [mem
0x00100000-0x7f6d33ff] could not be reserved
> Sep  8 16:59:12 Insp6400 kernel: [    1.457013] system 00:00: [mem
0x7f6d3400-0x7f6fffff] has been reserved
> Sep  8 16:59:12 Insp6400 kernel: [    1.457013] system 00:00: [mem
0x7f700000-0x7f7fffff] has been reserved
> Sep  8 16:59:12 Insp6400 kernel: [    1.457013] system 00:00: [mem
0x7f700000-0x7fefffff] could not be reserved
> Sep  8 16:59:12 Insp6400 kernel: [    1.457013] system 00:00: [mem
0xffb00000-0xffffffff] has been reserved
> Sep  8 16:59:12 Insp6400 kernel: [    1.457013] system 00:00: [mem
0xfec00000-0xfec0ffff] could not be reserved
> Sep  8 16:59:12 Insp6400 kernel: [    1.457013] system 00:00: [mem
0xfee00000-0xfee0ffff] has been reserved
> Sep  8 16:59:12 Insp6400 kernel: [    1.457013] system 00:00: [mem
0xfed20000-0xfed9ffff] has been reserved
> Sep  8 16:59:12 Insp6400 kernel: [    1.457013] system 00:00: [mem
0xffa80000-0xffa83fff] could not be reserved
> Sep  8 16:59:12 Insp6400 kernel: [    1.457013] system 00:00: [mem
0xf4000000-0xf4003fff] has been reserved
> Sep  8 16:59:12 Insp6400 kernel: [    1.457013] system 00:00: [mem
0xf4004000-0xf4004fff] has been reserved
> Sep  8 16:59:12 Insp6400 kernel: [    1.459154] system 00:00: [mem
0xf4005000-0xf4005fff] has been reserved
> Sep  8 16:59:12 Insp6400 kernel: [    1.459308] system 00:00: [mem
0xf4006000-0xf4006fff] has been reserved
> Sep  8 16:59:12 Insp6400 kernel: [    1.459460] system 00:00: [mem
0xf4008000-0xf400bfff] has been reserved
> Sep  8 16:59:12 Insp6400 kernel: [    1.459612] system 00:00: [mem
0xf0000000-0xf3ffffff] has been reserved
> Sep  8 16:59:12 Insp6400 kernel: [    1.807294] pnp 00:02: disabling [io 
0x1000-0x1005] because it overlaps 0000:00:1f.0 BAR 13 [io  0x1000-0x107f]
> Sep  8 16:59:12 Insp6400 kernel: [    1.807294] pnp 00:02: disabling [io 
0x1008-0x100f] because it overlaps 0000:00:1f.0 BAR 13 [io  0x1000-0x107f]
> Sep  8 16:59:12 Insp6400 kernel: [    1.808907] system 00:02: [io 
0x04d0-0x04d1] has been reserved
> Sep  8 16:59:12 Insp6400 kernel: [    1.810282] pnp 00:03: disabling [io 
0x1006-0x1007] because it overlaps 0000:00:1f.0 BAR 13 [io  0x1000-0x107f]
> Sep  8 16:59:12 Insp6400 kernel: [    1.810485] pnp 00:03: disabling [io 
0x100a-0x1059] because it overlaps 0000:00:1f.0 BAR 13 [io  0x1000-0x107f]
> Sep  8 16:59:12 Insp6400 kernel: [    1.810687] pnp 00:03: disabling [io 
0x1060-0x107f] because it overlaps 0000:00:1f.0 BAR 13 [io  0x1000-0x107f]
> Sep  8 16:59:12 Insp6400 kernel: [    1.810888] pnp 00:03: disabling [io 
0x1010-0x102f] because it overlaps 0000:00:1f.0 BAR 13 [io  0x1000-0x107f]
> Sep  8 16:59:12 Insp6400 kernel: [    1.812279] system 00:03: [io 
0xf400-0xf4fe] has been reserved
> Sep  8 16:59:12 Insp6400 kernel: [    1.812427] system 00:03: [io 
0x1080-0x10bf] has been reserved
> Sep  8 16:59:12 Insp6400 kernel: [    1.812573] system 00:03: [io 
0x10c0-0x10df] has been reserved
> Sep  8 16:59:12 Insp6400 kernel: [    1.812720] system 00:03: [io  0x0809]
has been reserved
> Sep  8 16:59:12 Insp6400 kernel: [    1.813570] xen_map_pirq_gsi: returning
irq 12 for gsi 12
> Sep  8 16:59:12 Insp6400 kernel: [    1.815255] xen_map_pirq_gsi: returning
irq 1 for gsi 1
> Sep  8 16:59:12 Insp6400 kernel: [    1.816800] xen_map_pirq_gsi: returning
irq 8 for gsi 8
> Sep  8 16:59:12 Insp6400 kernel: [    1.821590] system 00:08: [io 
0x0c80-0x0cff] could not be reserved
> Sep  8 16:59:12 Insp6400 kernel: [    1.821740] system 00:08: [io 
0x0910-0x091f] has been reserved
> Sep  8 16:59:12 Insp6400 kernel: [    1.821886] system 00:08: [io 
0x0920-0x092f] has been reserved
> Sep  8 16:59:12 Insp6400 kernel: [    1.822034] system 00:08: [io 
0x0cb0-0x0cbf] has been reserved
> Sep  8 16:59:12 Insp6400 kernel: [    1.822220] system 00:08: [io 
0x0930-0x097f] has been reserved
> Sep  8 16:59:12 Insp6400 kernel: [    1.824669] xen_map_pirq_gsi: returning
irq 13 for gsi 13
> Sep  8 16:59:12 Insp6400 kernel: [    1.829472] system 00:0b: [mem
0xfed00000-0xfed003ff] has been reserved
> Sep  8 16:59:12 Insp6400 kernel: [    1.830351] pnp: PnP ACPI: found 12
devices
> Sep  8 16:59:12 Insp6400 kernel: [    1.830351] ACPI: ACPI bus type pnp
unregistered
> Sep  8 16:59:12 Insp6400 kernel: [    1.917290] PM-Timer failed consistency
check  (0x0xffffff) - aborting.
> Sep  8 16:59:12 Insp6400 kernel: [    1.918064] pci 0000:00:1c.0: BAR 15:
assigned [mem 0x80000000-0x801fffff 64bit pref]
> Sep  8 16:59:12 Insp6400 kernel: [    1.918064] pci 0000:00:1c.0: BAR 13:
assigned [io  0x2000-0x2fff]
> Sep  8 16:59:12 Insp6400 kernel: [    1.918064] pci 0000:00:1c.0: PCI
bridge to [bus 0b-0b]
> Sep  8 16:59:12 Insp6400 kernel: [    1.918064] pci 0000:00:1c.0:   bridge
window [io  0x2000-0x2fff]
> Sep  8 16:59:12 Insp6400 kernel: [    1.918064] pci 0000:00:1c.0:   bridge
window [mem 0xefd00000-0xefdfffff]
> Sep  8 16:59:12 Insp6400 kernel: [    1.918064] pci 0000:00:1c.0:   bridge
window [mem 0x80000000-0x801fffff 64bit pref]
> Sep  8 16:59:12 Insp6400 kernel: [    1.918064] pci 0000:00:1c.3: PCI
bridge to [bus 0c-0d]
> Sep  8 16:59:12 Insp6400 kernel: [    1.918064] pci 0000:00:1c.3:   bridge
window [io  0xd000-0xdfff]
> Sep  8 16:59:12 Insp6400 kernel: [    1.918064] pci 0000:00:1c.3:   bridge
window [mem 0xefb00000-0xefcfffff]
> Sep  8 16:59:12 Insp6400 kernel: [    1.918064] pci 0000:00:1c.3:   bridge
window [mem 0xe0000000-0xe01fffff 64bit pref]
> Sep  8 16:59:12 Insp6400 kernel: [    1.918064] pci 0000:00:1e.0: PCI
bridge to [bus 03-03]
> Sep  8 16:59:12 Insp6400 kernel: [    1.918064] pci 0000:00:1e.0:   bridge
window [mem 0xefa00000-0xefafffff]
> Sep  8 16:59:12 Insp6400 kernel: [    1.920218] pci 0000:00:1c.0: PCI INT A
-> GSI 16 (level, low) -> IRQ 16
> Sep  8 16:59:12 Insp6400 kernel: [    1.920458] pci 0000:00:1c.3: PCI INT D
-> GSI 19 (level, low) -> IRQ 19
> Sep  8 16:59:12 Insp6400 kernel: [    1.921279] NET: Registered protocol
family 2
> Sep  8 16:59:12 Insp6400 kernel: [    1.923153] IP route cache hash table
entries: 65536 (order: 7, 524288 bytes)
> Sep  8 16:59:12 Insp6400 kernel: [    1.931845] TCP established hash table
entries: 262144 (order: 10, 4194304 bytes)
> Sep  8 16:59:12 Insp6400 kernel: [    1.940386] TCP bind hash table
entries: 65536 (order: 10, 5242880 bytes)
> Sep  8 16:59:12 Insp6400 kernel: [    1.954064] TCP: Hash tables configured
(established 262144 bind 65536)
> Sep  8 16:59:12 Insp6400 kernel: [    1.954064] TCP reno registered
> Sep  8 16:59:12 Insp6400 kernel: [    1.956489] UDP hash table entries:
1024 (order: 5, 196608 bytes)
> Sep  8 16:59:12 Insp6400 kernel: [    1.957465] UDP-Lite hash table
entries: 1024 (order: 5, 196608 bytes)
> Sep  8 16:59:12 Insp6400 kernel: [    1.959559] NET: Registered protocol
family 1
> Sep  8 16:59:12 Insp6400 kernel: [    1.962217] Unpacking initramfs...
> Sep  8 16:59:12 Insp6400 kernel: [    2.873066] Freeing initrd memory:
41320k freed
> Sep  8 16:59:12 Insp6400 kernel: [    3.259725] DMA-API: preallocated 32768
debug entries
> Sep  8 16:59:12 Insp6400 kernel: [    3.259856] DMA-API: debugging enabled
by kernel config
> Sep  8 16:59:12 Insp6400 kernel: [    3.260062] Simple Boot Flag at 0x79
set to 0x80
> Sep  8 16:59:12 Insp6400 kernel: [    3.271644] Intel AES-NI instructions
are not detected.
> Sep  8 16:59:12 Insp6400 kernel: [    3.271653] cryptomgr_test used
greatest stack depth: 6088 bytes left
> Sep  8 16:59:12 Insp6400 kernel: [    3.274831] audit: initializing netlink
socket (disabled)
> Sep  8 16:59:12 Insp6400 kernel: [    3.275128] type=2000
audit(1315515487.194:1): initialized
> Sep  8 16:59:12 Insp6400 kernel: [    3.311148] HugeTLB registered 2 MB
page size, pre-allocated 0 pages
> Sep  8 16:59:12 Insp6400 kernel: [    3.397870] VFS: Disk quotas
dquot_6.5.2
> Sep  8 16:59:12 Insp6400 kernel: [    3.399100] Dquot-cache hash table
entries: 512 (order 0, 4096 bytes)
> Sep  8 16:59:12 Insp6400 kernel: [    3.413418] msgmni has been set to 3501
> Sep  8 16:59:12 Insp6400 kernel: [    3.420261] cryptomgr_test used
greatest stack depth: 5512 bytes left
> Sep  8 16:59:12 Insp6400 kernel: [    3.422194] cryptomgr_test used
greatest stack depth: 5448 bytes left
> Sep  8 16:59:12 Insp6400 kernel: [    3.422470] alg: No test for stdrng
(krng)
> Sep  8 16:59:12 Insp6400 kernel: [    3.422652] NET: Registered protocol
family 38
> Sep  8 16:59:12 Insp6400 kernel: [    3.423923] Block layer SCSI generic
(bsg) driver version 0.4 loaded (major 253)
> Sep  8 16:59:12 Insp6400 kernel: [    3.424491] io scheduler noop
registered
> Sep  8 16:59:12 Insp6400 kernel: [    3.424610] io scheduler deadline
registered
> Sep  8 16:59:12 Insp6400 kernel: [    3.426320] io scheduler cfq registered
(default)
> Sep  8 16:59:12 Insp6400 kernel: [    3.426438] start plist test
> Sep  8 16:59:12 Insp6400 kernel: [    3.427727] end plist test
> Sep  8 16:59:12 Insp6400 kernel: [    3.443402] BUG: scheduling while
atomic: swapper/1/0x10000002
> Sep  8 16:59:12 Insp6400 kernel: [    3.443521] 3 locks held by swapper/1:
> Sep  8 16:59:12 Insp6400 kernel: [    3.443632]  #0: 
(&__lockdep_no_validate__){......}, at: [<ffffffff813171f0>]
__driver_attach+0x3b/0x82
> Sep  8 16:59:12 Insp6400 kernel: [    3.443945]  #1: 
(&__lockdep_no_validate__){......}, at: [<ffffffff813171fe>]
__driver_attach+0x49/0x82
> Sep  8 16:59:12 Insp6400 kernel: [    3.444258]  #2: 
(irq_mapping_update_lock){+.+.+.}, at: [<ffffffff812da206>]
xen_bind_pirq_msi_to_irq+0x31/0xda
> Sep  8 16:59:12 Insp6400 kernel: [    3.444371] Modules linked in:
> Sep  8 16:59:12 Insp6400 kernel: [    3.444371] Pid: 1, comm: swapper Not
tainted 3.1.0-0.rc5.git0.0.fc17.x86_64 #1
> Sep  8 16:59:12 Insp6400 kernel: [    3.444371] Call Trace:
> Sep  8 16:59:12 Insp6400 kernel: [    3.444371]  [<ffffffff814f9930>]
__schedule_bug+0x75/0x7a
> Sep  8 16:59:12 Insp6400 kernel: [    3.444371]  [<ffffffff81501bf5>]
schedule+0x95/0x7bb
> Sep  8 16:59:12 Insp6400 kernel: [    3.444371]  [<ffffffff81007746>]
? xen_force_evtchn_callback+0xd/0xf
> Sep  8 16:59:12 Insp6400 kernel: [    3.444371]  [<ffffffff81007746>]
? xen_force_evtchn_callback+0xd/0xf
> Sep  8 16:59:12 Insp6400 kernel: [    3.444371]  [<ffffffff81056c1e>]
__cond_resched+0x28/0x34
> Sep  8 16:59:12 Insp6400 kernel: [    3.444371]  [<ffffffff81502533>]
_cond_resched+0x19/0x22
> Sep  8 16:59:12 Insp6400 kernel: [    3.444371]  [<ffffffff81503139>]
mutex_lock_nested+0x2a/0x45
> Sep  8 16:59:12 Insp6400 kernel: [    3.444371]  [<ffffffff814e0ebd>]
__irq_alloc_descs+0x50/0x18b
> Sep  8 16:59:12 Insp6400 kernel: [    3.444371]  [<ffffffff812d0206>]
? kzalloc.constprop.1+0x2/0x15
> Sep  8 16:59:12 Insp6400 kernel: [    3.444371]  [<ffffffff812d972e>]
xen_allocate_irq_dynamic+0x49/0x58
> Sep  8 16:59:12 Insp6400 kernel: [    3.444371]  [<ffffffff812da20b>]
xen_bind_pirq_msi_to_irq+0x36/0xda
> Sep  8 16:59:12 Insp6400 kernel: [    3.444371]  [<ffffffff813ffcd3>]
xen_initdom_setup_msi_irqs+0x129/0x15d
> Sep  8 16:59:12 Insp6400 kernel: [    3.444371]  [<ffffffff8127cd38>]
pci_enable_msi_block+0x1c0/0x225
> Sep  8 16:59:12 Insp6400 kernel: [    3.444371]  [<ffffffff81273bbd>]
pcie_port_device_register+0x308/0x464
> Sep  8 16:59:12 Insp6400 kernel: [    3.444371]  [<ffffffff81007d72>]
? check_events+0x12/0x20
> Sep  8 16:59:12 Insp6400 kernel: [    3.444371]  [<ffffffff81007d5f>]
? xen_restore_fl_direct_reloc+0x4/0x4
> Sep  8 16:59:12 Insp6400 kernel: [    3.444371]  [<ffffffff814e654c>]
pcie_portdrv_probe+0x57/0x6e
> Sep  8 16:59:12 Insp6400 kernel: [    3.444371]  [<ffffffff8126cb6f>]
local_pci_probe+0x44/0x75
> Sep  8 16:59:12 Insp6400 kernel: [    3.444371]  [<ffffffff8126d6f5>]
pci_device_probe+0xd0/0xff
> Sep  8 16:59:12 Insp6400 kernel: [    3.444371]  [<ffffffff813170d3>]
driver_probe_device+0x131/0x213
> Sep  8 16:59:12 Insp6400 kernel: [    3.444371]  [<ffffffff81317213>]
__driver_attach+0x5e/0x82
> Sep  8 16:59:12 Insp6400 kernel: [    3.444371]  [<ffffffff813171b5>]
? driver_probe_device+0x213/0x213
> Sep  8 16:59:12 Insp6400 kernel: [    3.444371]  [<ffffffff81316114>]
bus_for_each_dev+0x59/0x8f
> Sep  8 16:59:12 Insp6400 kernel: [    3.444371]  [<ffffffff81316ca7>]
driver_attach+0x1e/0x20
> Sep  8 16:59:12 Insp6400 kernel: [    3.444371]  [<ffffffff813168bf>]
bus_add_driver+0xd4/0x22a
> Sep  8 16:59:12 Insp6400 kernel: [    3.444371]  [<ffffffff81d806dc>]
? dmi_pcie_pme_disable_msi+0x21/0x21
> Sep  8 16:59:12 Insp6400 kernel: [    3.444371]  [<ffffffff813176d6>]
driver_register+0x98/0x105
> Sep  8 16:59:12 Insp6400 kernel: [    3.444371]  [<ffffffff81d806dc>]
? dmi_pcie_pme_disable_msi+0x21/0x21
> Sep  8 16:59:12 Insp6400 kernel: [    3.444371]  [<ffffffff8126dfc8>]
__pci_register_driver+0x66/0xd2
> Sep  8 16:59:12 Insp6400 kernel: [    3.444371]  [<ffffffff81d806dc>]
? dmi_pcie_pme_disable_msi+0x21/0x21
> Sep  8 16:59:12 Insp6400 kernel: [    3.444371]  [<ffffffff81d80742>]
pcie_portdrv_init+0x66/0x77
> Sep  8 16:59:12 Insp6400 kernel: [    3.444371]  [<ffffffff81002099>]
do_one_initcall+0x7f/0x13a
> Sep  8 16:59:12 Insp6400 kernel: [    3.444371]  [<ffffffff81d53c8b>]
kernel_init+0xdf/0x159
> Sep  8 16:59:12 Insp6400 kernel: [    3.444371]  [<ffffffff8150d9c4>]
kernel_thread_helper+0x4/0x10
> Sep  8 16:59:12 Insp6400 kernel: [    3.444371]  [<ffffffff81504e34>]
? retint_restore_args+0x13/0x13
> Sep  8 16:59:12 Insp6400 kernel: [    3.444371]  [<ffffffff8150d9c0>]
? gs_change+0x13/0x13
> Sep  8 16:59:12 Insp6400 kernel: [    3.454101] pci_hotplug: PCI Hot Plug
PCI Core version: 0.5
> Sep  8 16:59:12 Insp6400 kernel: [    3.455760] pciehp: PCI Express Hot
Plug Controller Driver version: 0.4
> Sep  8 16:59:12 Insp6400 kernel: [    3.455881] acpiphp: ACPI Hot Plug PCI
Controller Driver version: 0.5
> Sep  8 16:59:12 Insp6400 kernel: [    3.466064] acpiphp: Slot [1]
registered
> Sep  8 16:59:12 Insp6400 kernel: [    3.473115] ACPI: Deprecated procfs I/F
for AC is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared
> Sep  8 16:59:12 Insp6400 kernel: [    3.478671] ACPI: AC Adapter [AC]
(on-line)
> Sep  8 16:59:12 Insp6400 kernel: [    3.484582] input: Lid Switch as
/devices/LNXSYSTM:00/device:00/PNP0C0D:00/input/input0
> Sep  8 16:59:12 Insp6400 kernel: [    3.491334] ACPI: Lid Switch [LID]
> Sep  8 16:59:12 Insp6400 kernel: [    3.492686] input: Power Button as
/devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input1
> Sep  8 16:59:12 Insp6400 kernel: [    3.492984] ACPI: Power Button [PBTN]
> Sep  8 16:59:12 Insp6400 kernel: [    3.494386] input: Sleep Button as
/devices/LNXSYSTM:00/device:00/PNP0C0E:00/input/input2
> Sep  8 16:59:12 Insp6400 kernel: [    3.494619] ACPI: Sleep Button [SBTN]
> Sep  8 16:59:12 Insp6400 kernel: [    3.677074] thermal LNXTHERM:00:
registered as thermal_zone0
> Sep  8 16:59:12 Insp6400 kernel: [    3.677074] ACPI: Thermal Zone [THM]
(67 C)
> Sep  8 16:59:12 Insp6400 kernel: [    3.677074] ERST: Table is not found!
> Sep  8 16:59:12 Insp6400 kernel: [    3.677074] GHES: HEST is not enabled!
> Sep  8 16:59:12 Insp6400 kernel: [    3.697940] Serial: 8250/16550 driver,
4 ports, IRQ sharing enabled
> Sep  8 16:59:12 Insp6400 kernel: [    4.212769] hpet_acpi_add: no address
or irqs in _CRS
> Sep  8 16:59:12 Insp6400 kernel: [    4.214384] Non-volatile memory driver
v1.3
> Sep  8 16:59:12 Insp6400 kernel: [    4.214500] Linux agpgart interface
v0.103
> Sep  8 16:59:12 Insp6400 kernel: [    4.216385] agpgart-intel 0000:00:00.0:
Intel 945GM Chipset
> Sep  8 16:59:12 Insp6400 kernel: [    4.223021] agpgart-intel 0000:00:00.0:
detected gtt size: 262144K total, 262144K mappable
> Sep  8 16:59:12 Insp6400 kernel: [    4.224301] agpgart-intel 0000:00:00.0:
detected 8192K stolen memory
> Sep  8 16:59:12 Insp6400 kernel: [    4.228213] agpgart-intel 0000:00:00.0:
AGP aperture is 256M @ 0xd0000000
> Sep  8 16:59:12 Insp6400 kernel: [    4.254675] loop: module loaded
> Sep  8 16:59:12 Insp6400 kernel: [    4.258041] ata_piix 0000:00:1f.2: PCI
INT B -> GSI 17 (level, low) -> IRQ 17
> Sep  8 16:59:12 Insp6400 kernel: [    4.258195] ata_piix 0000:00:1f.2: MAP
[ P0 P2 IDE IDE ]
> Sep  8 16:59:12 Insp6400 kernel: [    4.271431] scsi0 : ata_piix
> Sep  8 16:59:12 Insp6400 kernel: [    4.276528] scsi1 : ata_piix
> Sep  8 16:59:12 Insp6400 kernel: [    4.392230] ACPI: Deprecated procfs I/F
for battery is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared
> Sep  8 16:59:12 Insp6400 kernel: [    4.392657] ACPI: Battery Slot [BAT0]
(battery present)
> Sep  8 16:59:12 Insp6400 kernel: [    4.393060] ata1: SATA max UDMA/133 cmd
0x1f0 ctl 0x3f6 bmdma 0xbfa0 irq 14
> Sep  8 16:59:12 Insp6400 kernel: [    4.393060] ata2: PATA max UDMA/100 cmd
0x170 ctl 0x376 bmdma 0xbfa8 irq 15
> Sep  8 16:59:12 Insp6400 kernel: [    4.424981] Fixed MDIO Bus: probed
> Sep  8 16:59:12 Insp6400 kernel: [    4.426586] ehci_hcd: USB 2.0
''Enhanced'' Host Controller (EHCI) Driver
> Sep  8 16:59:12 Insp6400 kernel: [    4.427023] ehci_hcd 0000:00:1d.7: PCI
INT A -> GSI 20 (level, low) -> IRQ 20
> Sep  8 16:59:12 Insp6400 kernel: [    4.427370] ehci_hcd 0000:00:1d.7: EHCI
Host Controller
> Sep  8 16:59:12 Insp6400 kernel: [    4.430277] ehci_hcd 0000:00:1d.7: new
USB bus registered, assigned bus number 1
> Sep  8 16:59:12 Insp6400 kernel: [    4.430996] ehci_hcd 0000:00:1d.7:
using broken periodic workaround
> Sep  8 16:59:12 Insp6400 kernel: [    4.431157] ehci_hcd 0000:00:1d.7:
debug port 1
> Sep  8 16:59:12 Insp6400 kernel: [    4.435644] ehci_hcd 0000:00:1d.7: irq
20, io mem 0xffa80000
> Sep  8 16:59:12 Insp6400 kernel: [    4.445141] ehci_hcd 0000:00:1d.7: USB
2.0 started, EHCI 1.00
> Sep  8 16:59:12 Insp6400 kernel: [    4.446274] usb usb1: New USB device
found, idVendor=1d6b, idProduct=0002
> Sep  8 16:59:12 Insp6400 kernel: [    4.446395] usb usb1: New USB device
strings: Mfr=3, Product=2, SerialNumber=1
> Sep  8 16:59:12 Insp6400 kernel: [    4.446594] usb usb1: Product: EHCI
Host Controller
> Sep  8 16:59:12 Insp6400 kernel: [    4.446709] usb usb1: Manufacturer:
Linux 3.1.0-0.rc5.git0.0.fc17.x86_64 ehci_hcd
> Sep  8 16:59:12 Insp6400 kernel: [    4.446910] usb usb1: SerialNumber:
0000:00:1d.7
> Sep  8 16:59:12 Insp6400 kernel: [    4.451034] hub 1-0:1.0: USB hub found
> Sep  8 16:59:12 Insp6400 kernel: [    4.451501] hub 1-0:1.0: 8 ports
detected
> Sep  8 16:59:12 Insp6400 kernel: [    4.455464] ohci_hcd: USB 1.1
''Open'' Host Controller (OHCI) Driver
> Sep  8 16:59:12 Insp6400 kernel: [    4.455903] uhci_hcd: USB Universal
Host Controller Interface driver
> Sep  8 16:59:12 Insp6400 kernel: [    4.457042] xen_map_pirq_gsi: returning
irq 20 for gsi 20
> Sep  8 16:59:12 Insp6400 kernel: [    4.457197] Already setup the GSI :20
> Sep  8 16:59:12 Insp6400 kernel: [    4.457312] uhci_hcd 0000:00:1d.0: PCI
INT A -> GSI 20 (level, low) -> IRQ 20
> Sep  8 16:59:12 Insp6400 kernel: [    4.457556] uhci_hcd 0000:00:1d.0: UHCI
Host Controller
> Sep  8 16:59:12 Insp6400 kernel: [    4.459067] uhci_hcd 0000:00:1d.0: new
USB bus registered, assigned bus number 2
> Sep  8 16:59:12 Insp6400 kernel: [    4.459582] uhci_hcd 0000:00:1d.0: irq
20, io base 0x0000bf80
> Sep  8 16:59:12 Insp6400 kernel: [    4.460826] usb usb2: New USB device
found, idVendor=1d6b, idProduct=0001
> Sep  8 16:59:12 Insp6400 kernel: [    4.460946] usb usb2: New USB device
strings: Mfr=3, Product=2, SerialNumber=1
> Sep  8 16:59:12 Insp6400 kernel: [    4.461107] usb usb2: Product: UHCI
Host Controller
> Sep  8 16:59:12 Insp6400 kernel: [    4.461107] usb usb2: Manufacturer:
Linux 3.1.0-0.rc5.git0.0.fc17.x86_64 uhci_hcd
> Sep  8 16:59:12 Insp6400 kernel: [    4.461107] usb usb2: SerialNumber:
0000:00:1d.0
> Sep  8 16:59:12 Insp6400 kernel: [    4.464642] hub 2-0:1.0: USB hub found
> Sep  8 16:59:12 Insp6400 kernel: [    4.465008] hub 2-0:1.0: 2 ports
detected
> Sep  8 16:59:12 Insp6400 kernel: [    4.467877] uhci_hcd 0000:00:1d.1: PCI
INT B -> GSI 21 (level, low) -> IRQ 21
> Sep  8 16:59:12 Insp6400 kernel: [    4.468100] uhci_hcd 0000:00:1d.1: UHCI
Host Controller
> Sep  8 16:59:12 Insp6400 kernel: [    4.469667] uhci_hcd 0000:00:1d.1: new
USB bus registered, assigned bus number 3
> Sep  8 16:59:12 Insp6400 kernel: [    4.470616] uhci_hcd 0000:00:1d.1: irq
21, io base 0x0000bf60
> Sep  8 16:59:12 Insp6400 kernel: [    4.471789] usb usb3: New USB device
found, idVendor=1d6b, idProduct=0001
> Sep  8 16:59:12 Insp6400 kernel: [    4.471906] usb usb3: New USB device
strings: Mfr=3, Product=2, SerialNumber=1
> Sep  8 16:59:12 Insp6400 kernel: [    4.472067] usb usb3: Product: UHCI
Host Controller
> Sep  8 16:59:12 Insp6400 kernel: [    4.472067] usb usb3: Manufacturer:
Linux 3.1.0-0.rc5.git0.0.fc17.x86_64 uhci_hcd
> Sep  8 16:59:12 Insp6400 kernel: [    4.472067] usb usb3: SerialNumber:
0000:00:1d.1
> Sep  8 16:59:12 Insp6400 kernel: [    4.475616] hub 3-0:1.0: USB hub found
> Sep  8 16:59:12 Insp6400 kernel: [    4.475997] hub 3-0:1.0: 2 ports
detected
> Sep  8 16:59:12 Insp6400 kernel: [    4.478904] uhci_hcd 0000:00:1d.2: PCI
INT C -> GSI 22 (level, low) -> IRQ 22
> Sep  8 16:59:12 Insp6400 kernel: [    4.479125] uhci_hcd 0000:00:1d.2: UHCI
Host Controller
> Sep  8 16:59:12 Insp6400 kernel: [    4.480689] uhci_hcd 0000:00:1d.2: new
USB bus registered, assigned bus number 4
> Sep  8 16:59:12 Insp6400 kernel: [    4.481497] uhci_hcd 0000:00:1d.2: irq
22, io base 0x0000bf40
> Sep  8 16:59:12 Insp6400 kernel: [    4.482727] usb usb4: New USB device
found, idVendor=1d6b, idProduct=0001
> Sep  8 16:59:12 Insp6400 kernel: [    4.482847] usb usb4: New USB device
strings: Mfr=3, Product=2, SerialNumber=1
> Sep  8 16:59:12 Insp6400 kernel: [    4.483045] usb usb4: Product: UHCI
Host Controller
> Sep  8 16:59:12 Insp6400 kernel: [    4.483112] usb usb4: Manufacturer:
Linux 3.1.0-0.rc5.git0.0.fc17.x86_64 uhci_hcd
> Sep  8 16:59:12 Insp6400 kernel: [    4.483112] usb usb4: SerialNumber:
0000:00:1d.2
> Sep  8 16:59:12 Insp6400 kernel: [    4.487100] hub 4-0:1.0: USB hub found
> Sep  8 16:59:12 Insp6400 kernel: [    4.487448] hub 4-0:1.0: 2 ports
detected
> Sep  8 16:59:12 Insp6400 kernel: [    4.490377] uhci_hcd 0000:00:1d.3: PCI
INT D -> GSI 23 (level, low) -> IRQ 23
> Sep  8 16:59:12 Insp6400 kernel: [    4.490603] uhci_hcd 0000:00:1d.3: UHCI
Host Controller
> Sep  8 16:59:12 Insp6400 kernel: [    4.492088] uhci_hcd 0000:00:1d.3: new
USB bus registered, assigned bus number 5
> Sep  8 16:59:12 Insp6400 kernel: [    4.492944] uhci_hcd 0000:00:1d.3: irq
23, io base 0x0000bf20
> Sep  8 16:59:12 Insp6400 kernel: [    4.494309] usb usb5: New USB device
found, idVendor=1d6b, idProduct=0001
> Sep  8 16:59:12 Insp6400 kernel: [    4.494428] usb usb5: New USB device
strings: Mfr=3, Product=2, SerialNumber=1
> Sep  8 16:59:12 Insp6400 kernel: [    4.494624] usb usb5: Product: UHCI
Host Controller
> Sep  8 16:59:12 Insp6400 kernel: [    4.494738] usb usb5: Manufacturer:
Linux 3.1.0-0.rc5.git0.0.fc17.x86_64 uhci_hcd
> Sep  8 16:59:12 Insp6400 kernel: [    4.494932] usb usb5: SerialNumber:
0000:00:1d.3
> Sep  8 16:59:12 Insp6400 kernel: [    4.497976] hub 5-0:1.0: USB hub found
> Sep  8 16:59:12 Insp6400 kernel: [    4.498443] hub 5-0:1.0: 2 ports
detected
> Sep  8 16:59:12 Insp6400 kernel: [    4.502842] usbcore: registered new
interface driver usbserial
> Sep  8 16:59:12 Insp6400 kernel: [    4.503371] USB Serial support
registered for generic
> Sep  8 16:59:12 Insp6400 kernel: [    4.503830] usbcore: registered new
interface driver usbserial_generic
> Sep  8 16:59:12 Insp6400 kernel: [    4.503946] usbserial: USB Serial
Driver core
> Sep  8 16:59:12 Insp6400 kernel: [    4.504766] i8042: PNP: PS/2 Controller
[PNP0303:KBC,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
> Sep  8 16:59:12 Insp6400 kernel: [    4.508443] serio: i8042 KBD port at
0x60,0x64 irq 1
> Sep  8 16:59:12 Insp6400 kernel: [    4.508800] serio: i8042 AUX port at
0x60,0x64 irq 12
> Sep  8 16:59:12 Insp6400 kernel: [    4.511728] mousedev: PS/2 mouse device
common for all mice
> Sep  8 16:59:12 Insp6400 kernel: [    4.516800] rtc_cmos 00:06: RTC can
wake from S4
> Sep  8 16:59:12 Insp6400 kernel: [    4.519077] rtc_cmos 00:06: rtc core:
registered rtc_cmos as rtc0
> Sep  8 16:59:12 Insp6400 kernel: [    4.519522] rtc0: alarms up to one
month, y3k, 114 bytes nvram
> Sep  8 16:59:12 Insp6400 kernel: [    4.522072] input: AT Translated Set 2
keyboard as /devices/platform/i8042/serio0/input/input3
> Sep  8 16:59:12 Insp6400 kernel: [    4.526931] device-mapper: uevent:
version 1.0.3
> Sep  8 16:59:12 Insp6400 kernel: [    4.530694] device-mapper: ioctl:
4.21.0-ioctl (2011-07-06) initialised: dm-devel@redhat.com
> Sep  8 16:59:12 Insp6400 kernel: [    4.542007] EFI Variables Facility
v0.08 2004-May-17
> Sep  8 16:59:12 Insp6400 kernel: [    4.547159] usbcore: registered new
interface driver usbhid
> Sep  8 16:59:12 Insp6400 kernel: [    4.547280] usbhid: USB HID core driver
> Sep  8 16:59:12 Insp6400 kernel: [    4.554367] ip_tables: (C) 2000-2006
Netfilter Core Team
> Sep  8 16:59:12 Insp6400 kernel: [    4.554688] TCP cubic registered
> Sep  8 16:59:12 Insp6400 kernel: [    4.554804] Initializing XFRM netlink
socket
> Sep  8 16:59:12 Insp6400 kernel: [    4.559769] NET: Registered protocol
family 10
> Sep  8 16:59:12 Insp6400 kernel: [    4.574100] Mobile IPv6
> Sep  8 16:59:12 Insp6400 kernel: [    4.574591] NET: Registered protocol
family 17
> Sep  8 16:59:12 Insp6400 kernel: [    4.575116] Registering the
dns_resolver key type
> Sep  8 16:59:12 Insp6400 kernel: [    4.578852] ata1.00: HPA detected:
current 75200265, native 78140160
> Sep  8 16:59:12 Insp6400 kernel: [    4.578978] ata1.00: ATA-6: TOSHIBA
MK4032GSX, AS212D, max UDMA/100
> Sep  8 16:59:12 Insp6400 kernel: [    4.579098] ata1.00: 75200265 sectors,
multi 8: LBA48 NCQ (depth 0/32)
> Sep  8 16:59:12 Insp6400 kernel: [    4.580054] registered taskstats
version 1
> Sep  8 16:59:12 Insp6400 kernel: [    4.581431] IMA: No TPM chip found,
activating TPM-bypass!
> Sep  8 16:59:12 Insp6400 kernel: [    4.587959] ata1.00: configured for
UDMA/100
> Sep  8 16:59:12 Insp6400 kernel: [    4.590949] scsi 0:0:0:0: Direct-Access
ATA      TOSHIBA MK4032GS AS21 PQ: 0 ANSI: 5
> Sep  8 16:59:12 Insp6400 kernel: [    4.593951] ata2.00: ATAPI:
TSSTcorpCD-RW/DVD-ROM TSL462C, DE01, max UDMA/33
> Sep  8 16:59:12 Insp6400 kernel: [    4.595845]   Magic number: 11:184:1003
> Sep  8 16:59:12 Insp6400 kernel: [    4.596143] input input0: hash matches
> Sep  8 16:59:12 Insp6400 kernel: [    4.596301] vc vcs: hash matches
> Sep  8 16:59:12 Insp6400 kernel: [    4.596421] i8042 kbd 00:05: hash
matches
> Sep  8 16:59:12 Insp6400 kernel: [    4.597332] rtc_cmos 00:06: setting
system clock to 2011-09-08 20:58:10 UTC (1315515490)
> Sep  8 16:59:12 Insp6400 kernel: [    4.605886] sd 0:0:0:0: [sda] 75200265
512-byte logical blocks: (38.5 GB/35.8 GiB)
> Sep  8 16:59:12 Insp6400 kernel: [    4.607916] sd 0:0:0:0: [sda] Write
Protect is off
> Sep  8 16:59:12 Insp6400 kernel: [    4.608795] sd 0:0:0:0: [sda] Write
cache: enabled, read cache: enabled, doesn''t support DPO or FUA
> Sep  8 16:59:12 Insp6400 kernel: [    4.613095] sd 0:0:0:0: Attached scsi
generic sg0 type 0
> Sep  8 16:59:12 Insp6400 kernel: [    4.616777] ata2.00: configured for
UDMA/33
> Sep  8 16:59:12 Insp6400 kernel: [    4.622502] scsi 1:0:0:0: CD-ROM       
TSSTcorp CDRW/DVD TSL462C DE01 PQ: 0 ANSI: 5
> Sep  8 16:59:12 Insp6400 kernel: [    4.625298] Initializing network drop
monitor service
> Sep  8 16:59:12 Insp6400 kernel: [    4.627200] sr0: scsi3-mmc drive:
24x/24x writer cd/rw xa/form2 cdda tray
> Sep  8 16:59:12 Insp6400 kernel: [    4.627339] cdrom: Uniform CD-ROM
driver Revision: 3.20
> Sep  8 16:59:12 Insp6400 kernel: [    4.634936] sr 1:0:0:0: Attached scsi
generic sg1 type 5
> Sep  8 16:59:12 Insp6400 kernel: [    4.659570]  sda: sda1 sda2 sda3
> Sep  8 16:59:12 Insp6400 kernel: [    4.668851] sd 0:0:0:0: [sda] Attached
SCSI disk
> Sep  8 16:59:12 Insp6400 kernel: [    4.674686] Freeing unused kernel
memory: 2780k freed
> Sep  8 16:59:12 Insp6400 kernel: [    4.676066] Write protecting the kernel
read-only data: 10240k
> Sep  8 16:59:12 Insp6400 kernel: [    4.698892] Freeing unused kernel
memory: 940k freed
> Sep  8 16:59:12 Insp6400 kernel: [    4.703360] Freeing unused kernel
memory: 1424k freed
> Sep  8 16:59:12 Insp6400 kernel: [    4.727089] mknod used greatest stack
depth: 5120 bytes left
> Sep  8 16:59:12 Insp6400 kernel: [    4.895081] mount used greatest stack
depth: 4968 bytes left
> Sep  8 16:59:12 Insp6400 kernel: [    5.214678] Synaptics Touchpad, model:
1, fw: 6.2, id: 0x180b1, caps: 0xa04713/0x200000/0x0
> Sep  8 16:59:12 Insp6400 kernel: [    5.253303] input: SynPS/2 Synaptics
TouchPad as /devices/platform/i8042/serio1/input/input4
> Sep  8 16:59:12 Insp6400 kernel: [    5.676103] udevadm used greatest stack
depth: 4904 bytes left
> Sep  8 16:59:12 Insp6400 kernel: [    6.138176] console_init used greatest
stack depth: 4848 bytes left
> Sep  8 16:59:12 Insp6400 kernel: [    6.342404] acpi device:28: registered
as cooling_device2
> Sep  8 16:59:12 Insp6400 kernel: [    6.350194] input: Video Bus as
/devices/LNXSYSTM:00/device:00/PNP0A03:00/LNXVIDEO:01/input/input5
> Sep  8 16:59:12 Insp6400 kernel: [    6.352172] ACPI: Video Device [VID1]
(multi-head: yes  rom: no  post: no)
> Sep  8 16:59:12 Insp6400 kernel: [    6.352796] [Firmware Bug]: Duplicate
ACPI video bus devices for the same VGA controller, please try module parameter
"video.allow_duplicates=1"if the current driver doesn''t work.
> Sep  8 16:59:12 Insp6400 kernel: [    6.386874] [drm] Initialized drm 1.1.0
20060810
> Sep  8 16:59:12 Insp6400 kernel: [    6.424884] xen_map_pirq_gsi: returning
irq 16 for gsi 16
> Sep  8 16:59:12 Insp6400 kernel: [    6.425012] Already setup the GSI :16
> Sep  8 16:59:12 Insp6400 kernel: [    6.425068] i915 0000:00:02.0: PCI INT
A -> GSI 16 (level, low) -> IRQ 16
> Sep  8 16:59:12 Insp6400 kernel: [    6.859099] [drm] MTRR allocation
failed.  Graphics performance may suffer.
> Sep  8 16:59:12 Insp6400 kernel: [    6.882694] [drm] Supports vblank
timestamp caching Rev 1 (10.10.2010).
> Sep  8 16:59:12 Insp6400 kernel: [    6.882817] [drm] Driver supports
precise vblank timestamp query.
> Sep  8 16:59:12 Insp6400 kernel: [    6.884526] vgaarb: device changed
decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
> Sep  8 16:59:12 Insp6400 kernel: [    7.201153] [drm] initialized overlay
support
> Sep  8 16:59:12 Insp6400 kernel: [    7.483956] fbcon: inteldrmfb (fb0) is
primary device
> Sep  8 16:59:12 Insp6400 kernel: [    7.671279] Console: switching to
colour frame buffer device 160x50
> Sep  8 16:59:12 Insp6400 kernel: [    7.676066] fb0: inteldrmfb frame
buffer device
> Sep  8 16:59:12 Insp6400 kernel: [    7.676066] drm: registered panic
notifier
> Sep  8 16:59:12 Insp6400 kernel: [    7.676415] [drm] Initialized i915
1.6.0 20080730 for 0000:00:02.0 on minor 0
> Sep  8 16:59:12 Insp6400 kernel: [    7.682068] modprobe used greatest
stack depth: 2800 bytes left
> Sep  8 16:59:12 Insp6400 kernel: [    9.301111] wmi: Mapper loaded
> Sep  8 16:59:12 Insp6400 kernel: [    9.665528] xen_map_pirq_gsi: returning
irq 19 for gsi 19
> Sep  8 16:59:12 Insp6400 kernel: [    9.665588] Already setup the GSI :19
> Sep  8 16:59:12 Insp6400 kernel: [    9.665622] firewire_ohci 0000:03:01.0:
PCI INT A -> GSI 19 (level, low) -> IRQ 19
> Sep  8 16:59:12 Insp6400 kernel: [    9.696404] sdhci: Secure Digital Host
Controller Interface driver
> Sep  8 16:59:12 Insp6400 kernel: [    9.696465] sdhci: Copyright(c) Pierre
Ossman
> Sep  8 16:59:12 Insp6400 kernel: [    9.727406] firewire_ohci: Added
fw-ohci device 0000:03:01.0, OHCI v1.10, 4 IR + 4 IT contexts, quirks 0x1
> Sep  8 16:59:12 Insp6400 kernel: [    9.732408] sdhci-pci 0000:03:01.1:
SDHCI controller found [1180:0822] (rev 19)
> Sep  8 16:59:12 Insp6400 kernel: [    9.732532] BUG: sleeping function
called from invalid context at kernel/mutex.c:271
> Sep  8 16:59:12 Insp6400 kernel: [    9.732592] in_atomic(): 1,
irqs_disabled(): 0, pid: 245, name: modprobe
> Sep  8 16:59:12 Insp6400 kernel: [    9.732645] 3 locks held by
modprobe/245:
> Sep  8 16:59:12 Insp6400 kernel: [    9.732679]  #0: 
(&__lockdep_no_validate__){......}, at: [<ffffffff813171f0>]
__driver_attach+0x3b/0x82
> Sep  8 16:59:12 Insp6400 kernel: [    9.732784]  #1: 
(&__lockdep_no_validate__){......}, at: [<ffffffff813171fe>]
__driver_attach+0x49/0x82
> Sep  8 16:59:12 Insp6400 kernel: [    9.732885]  #2: 
(irq_mapping_update_lock){+.+.+.}, at: [<ffffffff812d9ffa>]
xen_bind_pirq_gsi_to_irq+0x2e/0x1a2
> Sep  8 16:59:12 Insp6400 kernel: [    9.732988] Pid: 245, comm: modprobe
Not tainted 3.1.0-0.rc5.git0.0.fc17.x86_64 #1
> Sep  8 16:59:12 Insp6400 kernel: [    9.733046] Call Trace:
> Sep  8 16:59:12 Insp6400 kernel: [    9.733067]  [<ffffffff8104f6cb>]
__might_sleep+0x103/0x108
> Sep  8 16:59:12 Insp6400 kernel: [    9.733067]  [<ffffffff81503134>]
mutex_lock_nested+0x25/0x45
> Sep  8 16:59:12 Insp6400 kernel: [    9.733067]  [<ffffffff814e0ebd>]
__irq_alloc_descs+0x50/0x18b
> Sep  8 16:59:12 Insp6400 kernel: [    9.733067]  [<ffffffff812da07e>]
xen_bind_pirq_gsi_to_irq+0xb2/0x1a2
> Sep  8 16:59:12 Insp6400 kernel: [    9.733067]  [<ffffffff8108ad74>]
? arch_local_irq_restore+0xb/0xd
> Sep  8 16:59:12 Insp6400 kernel: [    9.733067]  [<ffffffff813ffb5c>]
xen_register_pirq+0x8b/0xb7
> Sep  8 16:59:12 Insp6400 kernel: [    9.733067]  [<ffffffff813ffd48>]
xen_register_gsi.part.2+0x41/0x9f
> Sep  8 16:59:12 Insp6400 kernel: [    9.733067]  [<ffffffff813ffdc4>]
acpi_register_gsi_xen+0x1e/0x20
> Sep  8 16:59:12 Insp6400 kernel: [    9.733067]  [<ffffffff810256bf>]
acpi_register_gsi+0xf/0x18
> Sep  8 16:59:12 Insp6400 kernel: [    9.733067]  [<ffffffff812a03ac>]
acpi_pci_irq_enable+0x172/0x246
> Sep  8 16:59:12 Insp6400 kernel: [    9.733067]  [<ffffffff81401472>]
pcibios_enable_device+0x2b/0x30
> Sep  8 16:59:12 Insp6400 kernel: [    9.733067]  [<ffffffff8126bbd3>]
do_pci_enable_device+0x30/0x48
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff8126bc62>]
__pci_enable_device_flags+0x77/0x8a
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff8126bc88>]
pci_enable_device+0x13/0x15
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffffa00deb1b>]
sdhci_pci_probe+0xf0/0x416 [sdhci_pci]
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff81007d5f>]
? xen_restore_fl_direct_reloc+0x4/0x4
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff81095773>]
? arch_local_irq_restore+0xb/0xd
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff815049bf>]
? _raw_spin_unlock_irqrestore+0x4d/0x61
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff8126cb6f>]
local_pci_probe+0x44/0x75
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff8126d6f5>]
pci_device_probe+0xd0/0xff
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff813170d3>]
driver_probe_device+0x131/0x213
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff81317213>]
__driver_attach+0x5e/0x82
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff813171b5>]
? driver_probe_device+0x213/0x213
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff81316114>]
bus_for_each_dev+0x59/0x8f
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff81316ca7>]
driver_attach+0x1e/0x20
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff813168bf>]
bus_add_driver+0xd4/0x22a
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffffa00fc000>]
? 0xffffffffa00fbfff
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff813176d6>]
driver_register+0x98/0x105
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffffa00fc000>]
? 0xffffffffa00fbfff
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff8126dfc8>]
__pci_register_driver+0x66/0xd2
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffffa00fc000>]
? 0xffffffffa00fbfff
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffffa00fc01e>]
sdhci_drv_init+0x1e/0x1000 [sdhci_pci]
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff81002099>]
do_one_initcall+0x7f/0x13a
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffffa00fc000>]
? 0xffffffffa00fbfff
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff8109a60c>]
sys_init_module+0x114/0x267
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff8150b7c2>]
system_call_fastpath+0x16/0x1b
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832] BUG: scheduling while
atomic: modprobe/245/0x10000002
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832] 3 locks held by
modprobe/245:
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  #0: 
(&__lockdep_no_validate__){......}, at: [<ffffffff813171f0>]
__driver_attach+0x3b/0x82
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  #1: 
(&__lockdep_no_validate__){......}, at: [<ffffffff813171fe>]
__driver_attach+0x49/0x82
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  #2: 
(irq_mapping_update_lock){+.+.+.}, at: [<ffffffff812d9ffa>]
xen_bind_pirq_gsi_to_irq+0x2e/0x1a2
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832] Modules linked in:
sdhci_pci(+) sdhci mmc_core firewire_ohci firewire_core crc_itu_t wmi i915
drm_kms_helper drm i2c_algo_bit i2c_core video
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832] Pid: 245, comm: modprobe
Not tainted 3.1.0-0.rc5.git0.0.fc17.x86_64 #1
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832] Call Trace:
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff814f9930>]
__schedule_bug+0x75/0x7a
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff81501bf5>]
schedule+0x95/0x7bb
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff81011e17>]
? show_trace_log_lvl+0x54/0x5d
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff81011e35>]
? show_trace+0x15/0x17
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff81056c1e>]
__cond_resched+0x28/0x34
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff81502533>]
_cond_resched+0x19/0x22
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff81503139>]
mutex_lock_nested+0x2a/0x45
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff814e0ebd>]
__irq_alloc_descs+0x50/0x18b
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff812da07e>]
xen_bind_pirq_gsi_to_irq+0xb2/0x1a2
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff8108ad74>]
? arch_local_irq_restore+0xb/0xd
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff813ffb5c>]
xen_register_pirq+0x8b/0xb7
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff813ffd48>]
xen_register_gsi.part.2+0x41/0x9f
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff813ffdc4>]
acpi_register_gsi_xen+0x1e/0x20
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff810256bf>]
acpi_register_gsi+0xf/0x18
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff812a03ac>]
acpi_pci_irq_enable+0x172/0x246
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff81401472>]
pcibios_enable_device+0x2b/0x30
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff8126bbd3>]
do_pci_enable_device+0x30/0x48
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff8126bc62>]
__pci_enable_device_flags+0x77/0x8a
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff8126bc88>]
pci_enable_device+0x13/0x15
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffffa00deb1b>]
sdhci_pci_probe+0xf0/0x416 [sdhci_pci]
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff81007d5f>]
? xen_restore_fl_direct_reloc+0x4/0x4
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff81095773>]
? arch_local_irq_restore+0xb/0xd
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff815049bf>]
? _raw_spin_unlock_irqrestore+0x4d/0x61
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff8126cb6f>]
local_pci_probe+0x44/0x75
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff8126d6f5>]
pci_device_probe+0xd0/0xff
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff813170d3>]
driver_probe_device+0x131/0x213
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff81317213>]
__driver_attach+0x5e/0x82
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff813171b5>]
? driver_probe_device+0x213/0x213
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff81316114>]
bus_for_each_dev+0x59/0x8f
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff81316ca7>]
driver_attach+0x1e/0x20
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff813168bf>]
bus_add_driver+0xd4/0x22a
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffffa00fc000>]
? 0xffffffffa00fbfff
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff813176d6>]
driver_register+0x98/0x105
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffffa00fc000>]
? 0xffffffffa00fbfff
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff8126dfc8>]
__pci_register_driver+0x66/0xd2
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffffa00fc000>]
? 0xffffffffa00fbfff
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffffa00fc01e>]
sdhci_drv_init+0x1e/0x1000 [sdhci_pci]
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff81002099>]
do_one_initcall+0x7f/0x13a
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffffa00fc000>]
? 0xffffffffa00fbfff
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff8109a60c>]
sys_init_module+0x114/0x267
> Sep  8 16:59:12 Insp6400 kernel: [    9.749832]  [<ffffffff8150b7c2>]
system_call_fastpath+0x16/0x1b
> Sep  8 16:59:12 Insp6400 kernel: [    9.935093] sdhci-pci 0000:03:01.1: PCI
INT B -> GSI 18 (level, low) -> IRQ 18
> Sep  8 16:59:12 Insp6400 kernel: [    9.949666] mmc0: SDHCI controller on
PCI [0000:03:01.1] using DMA
> Sep  8 16:59:12 Insp6400 kernel: [   10.232950] firewire_core: created
device fw0: GUID 444fc0000e8ad921, S400
> Sep  8 16:59:12 Insp6400 kernel: [   17.102941] EXT4-fs (dm-0): mounted
filesystem with ordered data mode. Opts: (null)
> Sep  8 16:59:12 Insp6400 kernel: [   17.489192] EXT4-fs (dm-0): mounted
filesystem with ordered data mode. Opts: (null)
> Sep  8 16:59:12 Insp6400 kernel: [   38.466327] type=1403
audit(1315515524.369:2): policy loaded auid=4294967295 ses=4294967295
> Sep  8 16:59:12 Insp6400 kernel: [   47.240444] EXT4-fs (dm-0): re-mounted.
Opts: (null)
> Sep  8 16:59:12 Insp6400 kernel: [   48.864074] Event-channel device
installed.
> Sep  8 16:59:12 Insp6400 kernel: [   50.134162] tun: Universal TUN/TAP
device driver, 1.6
> Sep  8 16:59:12 Insp6400 kernel: [   50.135064] tun: (C) 1999-2004 Max
Krasnyansky <maxk@qualcomm.com>
> Sep  8 16:59:12 Insp6400 kernel: [   52.495009] intel_rng: FWH not detected
> Sep  8 16:59:12 Insp6400 kernel: [   52.664154] iTCO_vendor_support:
vendor-support=0
> Sep  8 16:59:12 Insp6400 kernel: [   52.789276] iTCO_wdt: Intel TCO
WatchDog Timer Driver v1.06
> Sep  8 16:59:12 Insp6400 kernel: [   52.825541] iTCO_wdt: Found a ICH7-M or
ICH7-U TCO device (Version=2, TCOBASE=0x1060)
> Sep  8 16:59:12 Insp6400 kernel: [   52.945236] iTCO_wdt: initialized.
heartbeat=30 sec (nowayout=0)
> Sep  8 16:59:12 Insp6400 kernel: [   52.954853] r8169 Gigabit Ethernet
driver 2.3LK-NAPI loaded
> Sep  8 16:59:12 Insp6400 kernel: [   52.959351] xen_map_pirq_gsi: returning
irq 19 for gsi 19
> Sep  8 16:59:12 Insp6400 kernel: [   52.960876] Already setup the GSI :19
> Sep  8 16:59:12 Insp6400 kernel: [   52.961768] r8169 0000:0c:00.0: PCI INT
A -> GSI 19 (level, low) -> IRQ 19
> Sep  8 16:59:12 Insp6400 kernel: [   52.971581] BUG: sleeping function
called from invalid context at kernel/mutex.c:271
> Sep  8 16:59:12 Insp6400 kernel: [   52.972086] in_atomic(): 1,
irqs_disabled(): 0, pid: 510, name: modprobe
> Sep  8 16:59:12 Insp6400 kernel: [   52.972086] 3 locks held by
modprobe/510:
> Sep  8 16:59:12 Insp6400 kernel: [   52.972086]  #0: 
(&__lockdep_no_validate__){......}, at: [<ffffffff813171f0>]
__driver_attach+0x3b/0x82
> Sep  8 16:59:12 Insp6400 kernel: [   52.972086]  #1: 
(&__lockdep_no_validate__){......}, at: [<ffffffff813171fe>]
__driver_attach+0x49/0x82
> Sep  8 16:59:12 Insp6400 kernel: [   52.972086]  #2: 
(irq_mapping_update_lock){+.+.+.}, at: [<ffffffff812da206>]
xen_bind_pirq_msi_to_irq+0x31/0xda
> Sep  8 16:59:12 Insp6400 kernel: [   52.972086] Pid: 510, comm: modprobe
Not tainted 3.1.0-0.rc5.git0.0.fc17.x86_64 #1
> Sep  8 16:59:12 Insp6400 kernel: [   52.972086] Call Trace:
> Sep  8 16:59:12 Insp6400 kernel: [   52.972086]  [<ffffffff8104f6cb>]
__might_sleep+0x103/0x108
> Sep  8 16:59:12 Insp6400 kernel: [   52.972086]  [<ffffffff81503134>]
mutex_lock_nested+0x25/0x45
> Sep  8 16:59:12 Insp6400 kernel: [   52.972086]  [<ffffffff814e0ebd>]
__irq_alloc_descs+0x50/0x18b
> Sep  8 16:59:12 Insp6400 kernel: [   52.972086]  [<ffffffff812d0206>]
? kzalloc.constprop.1+0x2/0x15
> Sep  8 16:59:12 Insp6400 kernel: [   52.972086]  [<ffffffff812d972e>]
xen_allocate_irq_dynamic+0x49/0x58
> Sep  8 16:59:12 Insp6400 kernel: [   52.972086]  [<ffffffff812da20b>]
xen_bind_pirq_msi_to_irq+0x36/0xda
> Sep  8 16:59:12 Insp6400 kernel: [   52.972086]  [<ffffffff813ffcd3>]
xen_initdom_setup_msi_irqs+0x129/0x15d
> Sep  8 16:59:12 Insp6400 kernel: [   52.972086]  [<ffffffff8127cd38>]
pci_enable_msi_block+0x1c0/0x225
> Sep  8 16:59:12 Insp6400 kernel: [   52.972086]  [<ffffffffa01b760a>]
rtl8169_init_one+0x515/0x85c [r8169]
> Sep  8 16:59:12 Insp6400 kernel: [   52.972086]  [<ffffffff81007d5f>]
? xen_restore_fl_direct_reloc+0x4/0x4
> Sep  8 16:59:12 Insp6400 kernel: [   52.972086]  [<ffffffff81095773>]
? arch_local_irq_restore+0xb/0xd
> Sep  8 16:59:12 Insp6400 kernel: [   52.972086]  [<ffffffff8126cb6f>]
local_pci_probe+0x44/0x75
> Sep  8 16:59:12 Insp6400 kernel: [   52.972086]  [<ffffffff8126d6f5>]
pci_device_probe+0xd0/0xff
> Sep  8 16:59:12 Insp6400 kernel: [   52.972086]  [<ffffffff813170d3>]
driver_probe_device+0x131/0x213
> Sep  8 16:59:12 Insp6400 kernel: [   52.972086]  [<ffffffff81317213>]
__driver_attach+0x5e/0x82
> Sep  8 16:59:12 Insp6400 kernel: [   52.972086]  [<ffffffff813171b5>]
? driver_probe_device+0x213/0x213
> Sep  8 16:59:12 Insp6400 kernel: [   52.972086]  [<ffffffff81316114>]
bus_for_each_dev+0x59/0x8f
> Sep  8 16:59:12 Insp6400 kernel: [   52.972086]  [<ffffffff81316ca7>]
driver_attach+0x1e/0x20
> Sep  8 16:59:12 Insp6400 kernel: [   52.972086]  [<ffffffff813168bf>]
bus_add_driver+0xd4/0x22a
> Sep  8 16:59:12 Insp6400 kernel: [   52.972086]  [<ffffffffa01bf000>]
? 0xffffffffa01befff
> Sep  8 16:59:12 Insp6400 kernel: [   52.972086]  [<ffffffff813176d6>]
driver_register+0x98/0x105
> Sep  8 16:59:12 Insp6400 kernel: [   52.972086]  [<ffffffffa01bf000>]
? 0xffffffffa01befff
> Sep  8 16:59:12 Insp6400 kernel: [   52.972086]  [<ffffffff8126dfc8>]
__pci_register_driver+0x66/0xd2
> Sep  8 16:59:12 Insp6400 kernel: [   52.972086]  [<ffffffffa01bf000>]
? 0xffffffffa01befff
> Sep  8 16:59:12 Insp6400 kernel: [   52.972086]  [<ffffffffa01bf01e>]
rtl8169_init_module+0x1e/0x1000 [r8169]
> Sep  8 16:59:12 Insp6400 kernel: [   52.972086]  [<ffffffff81002099>]
do_one_initcall+0x7f/0x13a
> Sep  8 16:59:12 Insp6400 kernel: [   52.972086]  [<ffffffffa01bf000>]
? 0xffffffffa01befff
> Sep  8 16:59:12 Insp6400 kernel: [   52.972086]  [<ffffffff8109a60c>]
sys_init_module+0x114/0x267
> Sep  8 16:59:12 Insp6400 kernel: [   52.972086]  [<ffffffff8150b7c2>]
system_call_fastpath+0x16/0x1b
> Sep  8 16:59:12 Insp6400 kernel: [   53.125576] cfg80211: Calling CRDA to
update world regulatory domain
> Sep  8 16:59:12 Insp6400 kernel: [   53.225315] microcode: CPU0 sig=0x6f6,
pf=0x20, revision=0xc7
> Sep  8 16:59:12 Insp6400 kernel: [   53.390418] r8169 0000:0c:00.0: eth0:
RTL8168d/8111d at 0xffffc90000378000, 00:e0:4c:68:23:0d, XID 081000c0 IRQ 286
> Sep  8 16:59:12 Insp6400 kernel: [   53.457417] dcdbas dcdbas: Dell Systems
Management Base Driver (version 5.6.0-3.2)
> Sep  8 16:59:12 Insp6400 kernel: [   53.463253] xen_map_pirq_gsi: returning
irq 17 for gsi 17
> Sep  8 16:59:12 Insp6400 kernel: [   53.465100] Already setup the GSI :17
> Sep  8 16:59:12 Insp6400 kernel: [   53.466083] i801_smbus 0000:00:1f.3:
PCI INT B -> GSI 17 (level, low) -> IRQ 17
> Sep  8 16:59:12 Insp6400 kernel: [   53.675021] xen_map_pirq_gsi: returning
irq 17 for gsi 17
> Sep  8 16:59:12 Insp6400 kernel: [   53.676759] Already setup the GSI :17
> Sep  8 16:59:12 Insp6400 kernel: [   53.677696] b44 0000:03:00.0: PCI INT A
-> GSI 17 (level, low) -> IRQ 17
> Sep  8 16:59:12 Insp6400 kernel: [   53.799234] ssb: Sonics Silicon
Backplane found on PCI device 0000:03:00.0
> Sep  8 16:59:12 Insp6400 kernel: [   53.952106] b44: Broadcom 44xx/47xx
10/100 PCI ethernet driver version 2.0
> Sep  8 16:59:12 Insp6400 kernel: [   54.034482] xen_map_pirq_gsi: returning
irq 18 for gsi 18
> Sep  8 16:59:12 Insp6400 kernel: [   54.036108] Already setup the GSI :18
> Sep  8 16:59:12 Insp6400 kernel: [   54.037461] r592 0000:03:01.2: PCI INT
B -> GSI 18 (level, low) -> IRQ 18
> Sep  8 16:59:12 Insp6400 kernel: [   54.051070] b44 ssb0:0: eth1: Broadcom
44xx/47xx 10/100 PCI ethernet driver 00:15:c5:04:7d:4f
> Sep  8 16:59:12 Insp6400 kernel: [   54.058267] r592: driver successfully
loaded
> Sep  8 16:59:12 Insp6400 kernel: [   54.301138] leds_ss4200: no LED devices
found
> Sep  8 16:59:12 Insp6400 kernel: [   54.361679] xen_map_pirq_gsi: returning
irq 18 for gsi 18
> Sep  8 16:59:12 Insp6400 kernel: [   54.363448] Already setup the GSI :18
> Sep  8 16:59:12 Insp6400 kernel: [   54.364263] r852 0000:03:01.3: PCI INT
B -> GSI 18 (level, low) -> IRQ 18
> Sep  8 16:59:12 Insp6400 kernel: [   54.444011] r852: Non dma capable
device detected, dma disabled
> Sep  8 16:59:12 Insp6400 kernel: [   54.445864] r852: driver loaded
successfully
> Sep  8 16:59:12 Insp6400 kernel: [   55.004011] microcode: CPU0 update to
revision 0xd1 failed
> Sep  8 16:59:12 Insp6400 kernel: [   55.006025] microcode: CPU1 sig=0x6f6,
pf=0x20, revision=0xc7
> Sep  8 16:59:12 Insp6400 kernel: [   55.009410] iwl3945: Intel(R)
PRO/Wireless 3945ABG/BG Network Connection driver for Linux, in-tree:ds
> Sep  8 16:59:12 Insp6400 kernel: [   55.010066] iwl3945: Copyright(c)
2003-2011 Intel Corporation
> Sep  8 16:59:12 Insp6400 kernel: [   55.013555] xen_map_pirq_gsi: returning
irq 16 for gsi 16
> Sep  8 16:59:12 Insp6400 kernel: [   55.015264] Already setup the GSI :16
> Sep  8 16:59:12 Insp6400 kernel: [   55.016248] iwl3945 0000:0b:00.0: PCI
INT A -> GSI 16 (level, low) -> IRQ 16
> Sep  8 16:59:12 Insp6400 kernel: [   55.070827] microcode: CPU1 update to
revision 0xd1 failed
> Sep  8 16:59:12 Insp6400 kernel: [   55.080017] microcode: Microcode Update
Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
> Sep  8 16:59:12 Insp6400 kernel: [   55.087930] iwl3945 0000:0b:00.0:
Tunable channels: 11 802.11bg, 13 802.11a channels
> Sep  8 16:59:12 Insp6400 kernel: [   55.088151] iwl3945 0000:0b:00.0:
Detected Intel Wireless WiFi Link 3945ABG
> Sep  8 16:59:12 Insp6400 kernel: [   55.092221] BUG: sleeping function
called from invalid context at kernel/mutex.c:271
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017] in_atomic(): 1,
irqs_disabled(): 0, pid: 516, name: modprobe
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017] 3 locks held by
modprobe/516:
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  #0: 
(&__lockdep_no_validate__){......}, at: [<ffffffff813171f0>]
__driver_attach+0x3b/0x82
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  #1: 
(&__lockdep_no_validate__){......}, at: [<ffffffff813171fe>]
__driver_attach+0x49/0x82
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  #2: 
(irq_mapping_update_lock){+.+.+.}, at: [<ffffffff812da206>]
xen_bind_pirq_msi_to_irq+0x31/0xda
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017] Pid: 516, comm: modprobe
Not tainted 3.1.0-0.rc5.git0.0.fc17.x86_64 #1
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017] Call Trace:
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  [<ffffffff8104f6cb>]
__might_sleep+0x103/0x108
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  [<ffffffff81503134>]
mutex_lock_nested+0x25/0x45
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  [<ffffffff814e0ebd>]
__irq_alloc_descs+0x50/0x18b
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  [<ffffffff812d0206>]
? kzalloc.constprop.1+0x2/0x15
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  [<ffffffff812d972e>]
xen_allocate_irq_dynamic+0x49/0x58
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  [<ffffffff812da20b>]
xen_bind_pirq_msi_to_irq+0x36/0xda
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  [<ffffffff813ffcd3>]
xen_initdom_setup_msi_irqs+0x129/0x15d
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  [<ffffffff8127cd38>]
pci_enable_msi_block+0x1c0/0x225
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  [<ffffffffa02c5519>]
iwl3945_pci_probe+0x6b7/0xc51 [iwl3945]
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  [<ffffffff8126cb6f>]
local_pci_probe+0x44/0x75
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  [<ffffffff8126d6f5>]
pci_device_probe+0xd0/0xff
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  [<ffffffff813170d3>]
driver_probe_device+0x131/0x213
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  [<ffffffff81317213>]
__driver_attach+0x5e/0x82
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  [<ffffffff813171b5>]
? driver_probe_device+0x213/0x213
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  [<ffffffff81316114>]
bus_for_each_dev+0x59/0x8f
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  [<ffffffff81316ca7>]
driver_attach+0x1e/0x20
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  [<ffffffff813168bf>]
bus_add_driver+0xd4/0x22a
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  [<ffffffffa0288000>]
? 0xffffffffa0287fff
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  [<ffffffff813176d6>]
driver_register+0x98/0x105
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  [<ffffffffa0288000>]
? 0xffffffffa0287fff
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  [<ffffffff8126dfc8>]
__pci_register_driver+0x66/0xd2
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  [<ffffffffa0288000>]
? 0xffffffffa0287fff
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  [<ffffffffa0288059>]
iwl3945_init+0x59/0x1000 [iwl3945]
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  [<ffffffff81002099>]
do_one_initcall+0x7f/0x13a
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  [<ffffffffa0288000>]
? 0xffffffffa0287fff
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  [<ffffffff8109a60c>]
sys_init_module+0x114/0x267
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  [<ffffffff8150b7c2>]
system_call_fastpath+0x16/0x1b
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017] BUG: scheduling while
atomic: modprobe/516/0x10000002
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017] 3 locks held by
modprobe/516:
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  #0: 
(&__lockdep_no_validate__){......}, at: [<ffffffff813171f0>]
__driver_attach+0x3b/0x82
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  #1: 
(&__lockdep_no_validate__){......}, at: [<ffffffff813171fe>]
__driver_attach+0x49/0x82
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  #2: 
(irq_mapping_update_lock){+.+.+.}, at: [<ffffffff812da206>]
xen_bind_pirq_msi_to_irq+0x31/0xda
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017] Modules linked in:
sparse_keymap iwl3945(+) iwl_legacy snd_timer mac80211 r852 sm_common nand snd
r592 nand_ids memstick dell_laptop nand_ecc mtd b44 soundcore joydev i2c_i801
dcdbas snd_page_alloc microcode r8169 ssb cfg80211 iTCO_wdt iTCO_vendor_support
mii rfkill tun xen_gntalloc xen_netback xen_blkback xen_gntdev xen_evtchn xenfs
binfmt_misc sdhci_pci sdhci mmc_core firewire_ohci firewire_core crc_itu_t wmi
i915 drm_kms_helper drm i2c_algo_bit i2c_core video
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017] Pid: 516, comm: modprobe
Not tainted 3.1.0-0.rc5.git0.0.fc17.x86_64 #1
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017] Call Trace:
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  [<ffffffff814f9930>]
__schedule_bug+0x75/0x7a
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  [<ffffffff81501bf5>]
schedule+0x95/0x7bb
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  [<ffffffff81011e17>]
? show_trace_log_lvl+0x54/0x5d
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  [<ffffffff81011e35>]
? show_trace+0x15/0x17
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  [<ffffffff81056c1e>]
__cond_resched+0x28/0x34
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  [<ffffffff81502533>]
_cond_resched+0x19/0x22
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  [<ffffffff81503139>]
mutex_lock_nested+0x2a/0x45
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  [<ffffffff814e0ebd>]
__irq_alloc_descs+0x50/0x18b
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  [<ffffffff812d0206>]
? kzalloc.constprop.1+0x2/0x15
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  [<ffffffff812d972e>]
xen_allocate_irq_dynamic+0x49/0x58
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  [<ffffffff812da20b>]
xen_bind_pirq_msi_to_irq+0x36/0xda
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  [<ffffffff813ffcd3>]
xen_initdom_setup_msi_irqs+0x129/0x15d
> Sep  8 16:59:12 Insp6400 kernel: [   55.093017]  [<ffffffff8127cd38>]
pci_enable_msi_block+0x1c0/0x225
> Sep  8 16:59:12 Insp6400 kernel: [   55.195564]  [<ffffffffa02c5519>]
iwl3945_pci_probe+0x6b7/0xc51 [iwl3945]
> Sep  8 16:59:12 Insp6400 kernel: [   55.195564]  [<ffffffff8126cb6f>]
local_pci_probe+0x44/0x75
> Sep  8 16:59:12 Insp6400 kernel: [   55.195564]  [<ffffffff8126d6f5>]
pci_device_probe+0xd0/0xff
> Sep  8 16:59:12 Insp6400 kernel: [   55.195564]  [<ffffffff813170d3>]
driver_probe_device+0x131/0x213
> Sep  8 16:59:12 Insp6400 kernel: [   55.195564]  [<ffffffff81317213>]
__driver_attach+0x5e/0x82
> Sep  8 16:59:12 Insp6400 kernel: [   55.195564]  [<ffffffff813171b5>]
? driver_probe_device+0x213/0x213
> Sep  8 16:59:12 Insp6400 kernel: [   55.195564]  [<ffffffff81316114>]
bus_for_each_dev+0x59/0x8f
> Sep  8 16:59:12 Insp6400 kernel: [   55.195564]  [<ffffffff81316ca7>]
driver_attach+0x1e/0x20
> Sep  8 16:59:12 Insp6400 kernel: [   55.195564]  [<ffffffff813168bf>]
bus_add_driver+0xd4/0x22a
> Sep  8 16:59:12 Insp6400 kernel: [   55.195564]  [<ffffffffa0288000>]
? 0xffffffffa0287fff
> Sep  8 16:59:12 Insp6400 kernel: [   55.195564]  [<ffffffff813176d6>]
driver_register+0x98/0x105
> Sep  8 16:59:12 Insp6400 kernel: [   55.195564]  [<ffffffffa0288000>]
? 0xffffffffa0287fff
> Sep  8 16:59:12 Insp6400 kernel: [   55.195564]  [<ffffffff8126dfc8>]
__pci_register_driver+0x66/0xd2
> Sep  8 16:59:12 Insp6400 kernel: [   55.195564]  [<ffffffffa0288000>]
? 0xffffffffa0287fff
> Sep  8 16:59:12 Insp6400 kernel: [   55.195564]  [<ffffffffa0288059>]
iwl3945_init+0x59/0x1000 [iwl3945]
> Sep  8 16:59:12 Insp6400 kernel: [   55.195564]  [<ffffffff81002099>]
do_one_initcall+0x7f/0x13a
> Sep  8 16:59:12 Insp6400 kernel: [   55.195564]  [<ffffffffa0288000>]
? 0xffffffffa0287fff
> Sep  8 16:59:12 Insp6400 kernel: [   55.195564]  [<ffffffff8109a60c>]
sys_init_module+0x114/0x267
> Sep  8 16:59:12 Insp6400 kernel: [   55.195564]  [<ffffffff8150b7c2>]
system_call_fastpath+0x16/0x1b
> Sep  8 16:59:12 Insp6400 kernel: [   55.548175] input: Dell WMI hotkeys as
/devices/virtual/input/input6
> Sep  8 16:59:12 Insp6400 kernel: [   56.324005] Adding 4063228k swap on
/dev/mapper/vg_insp6400-lv_swap.  Priority:0 extents:1 across:4063228k
> Sep  8 16:59:12 Insp6400 kernel: [   56.817354] cfg80211: World regulatory
domain updated:
> Sep  8 16:59:12 Insp6400 kernel: [   56.818070] cfg80211:     (start_freq -
end_freq @ bandwidth), (max_antenna_gain, max_eirp)
> Sep  8 16:59:12 Insp6400 kernel: [   56.818070] cfg80211:     (2402000 KHz
- 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> Sep  8 16:59:12 Insp6400 kernel: [   56.818070] cfg80211:     (2457000 KHz
- 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
> Sep  8 16:59:12 Insp6400 kernel: [   56.818070] cfg80211:     (2474000 KHz
- 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
> Sep  8 16:59:12 Insp6400 kernel: [   56.818070] cfg80211:     (5170000 KHz
- 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> Sep  8 16:59:12 Insp6400 kernel: [   56.818070] cfg80211:     (5735000 KHz
- 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> Sep  8 16:59:12 Insp6400 kernel: [   57.216613] cfg80211: Calling CRDA for
country: US
> Sep  8 16:59:12 Insp6400 kernel: [   57.268160] xen_map_pirq_gsi: returning
irq 21 for gsi 21
> Sep  8 16:59:12 Insp6400 kernel: [   57.269571] Already setup the GSI :21
> Sep  8 16:59:12 Insp6400 kernel: [   57.270549] snd_hda_intel 0000:00:1b.0:
PCI INT A -> GSI 21 (level, low) -> IRQ 21
> Sep  8 16:59:12 Insp6400 kernel: [   57.273449] BUG: sleeping function
called from invalid context at kernel/mutex.c:271
> Sep  8 16:59:12 Insp6400 kernel: [   57.274153] in_atomic(): 1,
irqs_disabled(): 0, pid: 505, name: modprobe
> Sep  8 16:59:12 Insp6400 kernel: [   57.274153] 3 locks held by
modprobe/505:
> Sep  8 16:59:12 Insp6400 kernel: [   57.274153]  #0: 
(&__lockdep_no_validate__){......}, at: [<ffffffff813171f0>]
__driver_attach+0x3b/0x82
> Sep  8 16:59:12 Insp6400 kernel: [   57.274153]  #1: 
(&__lockdep_no_validate__){......}, at: [<ffffffff813171fe>]
__driver_attach+0x49/0x82
> Sep  8 16:59:12 Insp6400 kernel: [   57.274153]  #2: 
(irq_mapping_update_lock){+.+.+.}, at: [<ffffffff812da206>]
xen_bind_pirq_msi_to_irq+0x31/0xda
> Sep  8 16:59:12 Insp6400 kernel: [   57.274153] Pid: 505, comm: modprobe
Not tainted 3.1.0-0.rc5.git0.0.fc17.x86_64 #1
> Sep  8 16:59:12 Insp6400 kernel: [   57.274153] Call Trace:
> Sep  8 16:59:12 Insp6400 kernel: [   57.274153]  [<ffffffff8104f6cb>]
__might_sleep+0x103/0x108
> Sep  8 16:59:12 Insp6400 kernel: [   57.274153]  [<ffffffff81503134>]
mutex_lock_nested+0x25/0x45
> Sep  8 16:59:12 Insp6400 kernel: [   57.274153]  [<ffffffff814e0ebd>]
__irq_alloc_descs+0x50/0x18b
> Sep  8 16:59:12 Insp6400 kernel: [   57.274153]  [<ffffffff812d0206>]
? kzalloc.constprop.1+0x2/0x15
> Sep  8 16:59:12 Insp6400 kernel: [   57.291640]  [<ffffffff812d972e>]
xen_allocate_irq_dynamic+0x49/0x58
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffff812da20b>]
xen_bind_pirq_msi_to_irq+0x36/0xda
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffff813ffcd3>]
xen_initdom_setup_msi_irqs+0x129/0x15d
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffff8127cd38>]
pci_enable_msi_block+0x1c0/0x225
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffffa03208da>]
azx_probe+0x437/0x982 [snd_hda_intel]
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffff8126cb6f>]
local_pci_probe+0x44/0x75
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffff8126d6f5>]
pci_device_probe+0xd0/0xff
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffff813170d3>]
driver_probe_device+0x131/0x213
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffff81317213>]
__driver_attach+0x5e/0x82
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffff813171b5>]
? driver_probe_device+0x213/0x213
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffff81316114>]
bus_for_each_dev+0x59/0x8f
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffff81316ca7>]
driver_attach+0x1e/0x20
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffff813168bf>]
bus_add_driver+0xd4/0x22a
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffffa0327000>]
? 0xffffffffa0326fff
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffff813176d6>]
driver_register+0x98/0x105
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffffa0327000>]
? 0xffffffffa0326fff
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffff8126dfc8>]
__pci_register_driver+0x66/0xd2
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffffa0327000>]
? 0xffffffffa0326fff
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffffa032701e>]
alsa_card_azx_init+0x1e/0x1000 [snd_hda_intel]
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffff81002099>]
do_one_initcall+0x7f/0x13a
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffffa0327000>]
? 0xffffffffa0326fff
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffff8109a60c>]
sys_init_module+0x114/0x267
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffff8150b7c2>]
system_call_fastpath+0x16/0x1b
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557] BUG: scheduling while
atomic: modprobe/505/0x10000002
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557] 3 locks held by
modprobe/505:
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  #0: 
(&__lockdep_no_validate__){......}, at: [<ffffffff813171f0>]
__driver_attach+0x3b/0x82
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  #1: 
(&__lockdep_no_validate__){......}, at: [<ffffffff813171fe>]
__driver_attach+0x49/0x82
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  #2: 
(irq_mapping_update_lock){+.+.+.}, at: [<ffffffff812da206>]
xen_bind_pirq_msi_to_irq+0x31/0xda
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557] Modules linked in:
snd_hda_intel(+) snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm dell_wmi
arc4 sparse_keymap iwl3945 iwl_legacy snd_timer mac80211 r852 sm_common nand snd
r592 nand_ids memstick dell_laptop nand_ecc mtd b44 soundcore joydev i2c_i801
dcdbas snd_page_alloc microcode r8169 ssb cfg80211 iTCO_wdt iTCO_vendor_support
mii rfkill tun xen_gntalloc xen_netback xen_blkback xen_gntdev xen_evtchn xenfs
binfmt_misc sdhci_pci sdhci mmc_core firewire_ohci firewire_core crc_itu_t wmi
i915 drm_kms_helper drm i2c_algo_bit i2c_core video
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557] Pid: 505, comm: modprobe
Not tainted 3.1.0-0.rc5.git0.0.fc17.x86_64 #1
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557] Call Trace:
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffff814f9930>]
__schedule_bug+0x75/0x7a
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffff81501bf5>]
schedule+0x95/0x7bb
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffff81011e17>]
? show_trace_log_lvl+0x54/0x5d
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffff81011e35>]
? show_trace+0x15/0x17
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffff81056c1e>]
__cond_resched+0x28/0x34
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffff81502533>]
_cond_resched+0x19/0x22
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffff81503139>]
mutex_lock_nested+0x2a/0x45
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffff814e0ebd>]
__irq_alloc_descs+0x50/0x18b
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffff812d0206>]
? kzalloc.constprop.1+0x2/0x15
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffff812d972e>]
xen_allocate_irq_dynamic+0x49/0x58
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffff812da20b>]
xen_bind_pirq_msi_to_irq+0x36/0xda
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffff813ffcd3>]
xen_initdom_setup_msi_irqs+0x129/0x15d
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffff8127cd38>]
pci_enable_msi_block+0x1c0/0x225
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffffa03208da>]
azx_probe+0x437/0x982 [snd_hda_intel]
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffff8126cb6f>]
local_pci_probe+0x44/0x75
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffff8126d6f5>]
pci_device_probe+0xd0/0xff
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffff813170d3>]
driver_probe_device+0x131/0x213
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffff81317213>]
__driver_attach+0x5e/0x82
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffff813171b5>]
? driver_probe_device+0x213/0x213
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffff81316114>]
bus_for_each_dev+0x59/0x8f
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffff81316ca7>]
driver_attach+0x1e/0x20
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffff813168bf>]
bus_add_driver+0xd4/0x22a
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffffa0327000>]
? 0xffffffffa0326fff
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffff813176d6>]
driver_register+0x98/0x105
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffffa0327000>]
? 0xffffffffa0326fff
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffff8126dfc8>]
__pci_register_driver+0x66/0xd2
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffffa0327000>]
? 0xffffffffa0326fff
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffffa032701e>]
alsa_card_azx_init+0x1e/0x1000 [snd_hda_intel]
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffff81002099>]
do_one_initcall+0x7f/0x13a
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffffa0327000>]
? 0xffffffffa0326fff
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffff8109a60c>]
sys_init_module+0x114/0x267
> Sep  8 16:59:12 Insp6400 kernel: [   57.292557]  [<ffffffff8150b7c2>]
system_call_fastpath+0x16/0x1b
> Sep  8 16:59:12 Insp6400 kernel: [   57.394726] BUG: spinlock wrong CPU on
CPU#1, modprobe/505
> Sep  8 16:59:12 Insp6400 kernel: [   57.395079]  lock: ffffffff81a7de60,
.magic: dead4ead, .owner: modprobe/505, .owner_cpu: 0
> Sep  8 16:59:12 Insp6400 kernel: [   57.395079] Pid: 505, comm: modprobe
Not tainted 3.1.0-0.rc5.git0.0.fc17.x86_64 #1
> Sep  8 16:59:12 Insp6400 kernel: [   57.395079] Call Trace:
> Sep  8 16:59:12 Insp6400 kernel: [   57.395079]  [<ffffffff814fe556>]
spin_bug+0xa3/0xab
> Sep  8 16:59:12 Insp6400 kernel: [   57.395079]  [<ffffffff812581ee>]
do_raw_spin_unlock+0x75/0x8b
> Sep  8 16:59:12 Insp6400 kernel: [   57.395079]  [<ffffffff815049fb>]
_raw_spin_unlock+0x28/0x3b
> Sep  8 16:59:12 Insp6400 kernel: [   57.395079]  [<ffffffff812da283>]
xen_bind_pirq_msi_to_irq+0xae/0xda
> Sep  8 16:59:12 Insp6400 kernel: [   57.395079]  [<ffffffff813ffcd3>]
xen_initdom_setup_msi_irqs+0x129/0x15d
> Sep  8 16:59:12 Insp6400 kernel: [   57.409377]  [<ffffffff8127cd38>]
pci_enable_msi_block+0x1c0/0x225
> Sep  8 16:59:12 Insp6400 kernel: [   57.409377]  [<ffffffffa03208da>]
azx_probe+0x437/0x982 [snd_hda_intel]
> Sep  8 16:59:12 Insp6400 kernel: [   57.409377]  [<ffffffff8126cb6f>]
local_pci_probe+0x44/0x75
> Sep  8 16:59:12 Insp6400 kernel: [   57.409377]  [<ffffffff8126d6f5>]
pci_device_probe+0xd0/0xff
> Sep  8 16:59:12 Insp6400 kernel: [   57.409377]  [<ffffffff813170d3>]
driver_probe_device+0x131/0x213
> Sep  8 16:59:12 Insp6400 kernel: [   57.409377]  [<ffffffff81317213>]
__driver_attach+0x5e/0x82
> Sep  8 16:59:12 Insp6400 kernel: [   57.409377]  [<ffffffff813171b5>]
? driver_probe_device+0x213/0x213
> Sep  8 16:59:12 Insp6400 kernel: [   57.409377]  [<ffffffff81316114>]
bus_for_each_dev+0x59/0x8f
> Sep  8 16:59:12 Insp6400 kernel: [   57.419915] cfg80211: Regulatory domain
changed to country: US
> Sep  8 16:59:12 Insp6400 kernel: [   57.419919] cfg80211:     (start_freq -
end_freq @ bandwidth), (max_antenna_gain, max_eirp)
> Sep  8 16:59:12 Insp6400 kernel: [   57.419924] cfg80211:     (2402000 KHz
- 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm)
> Sep  8 16:59:12 Insp6400 kernel: [   57.419927] cfg80211:     (5170000 KHz
- 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
> Sep  8 16:59:12 Insp6400 kernel: [   57.419931] cfg80211:     (5250000 KHz
- 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> Sep  8 16:59:12 Insp6400 kernel: [   57.419935] cfg80211:     (5490000 KHz
- 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> Sep  8 16:59:12 Insp6400 kernel: [   57.419939] cfg80211:     (5650000 KHz
- 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> Sep  8 16:59:12 Insp6400 kernel: [   57.419942] cfg80211:     (5735000 KHz
- 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
> Sep  8 16:59:12 Insp6400 kernel: [   57.409377]  [<ffffffff81316ca7>]
driver_attach+0x1e/0x20
> Sep  8 16:59:12 Insp6400 kernel: [   57.409377]  [<ffffffff813168bf>]
bus_add_driver+0xd4/0x22a
> Sep  8 16:59:12 Insp6400 kernel: [   57.409377]  [<ffffffffa0327000>]
? 0xffffffffa0326fff
> Sep  8 16:59:12 Insp6400 kernel: [   57.409377]  [<ffffffff813176d6>]
driver_register+0x98/0x105
> Sep  8 16:59:12 Insp6400 kernel: [   57.409377]  [<ffffffffa0327000>]
? 0xffffffffa0326fff
> Sep  8 16:59:12 Insp6400 kernel: [   57.409377]  [<ffffffff8126dfc8>]
__pci_register_driver+0x66/0xd2
> Sep  8 16:59:12 Insp6400 kernel: [   57.409377]  [<ffffffffa0327000>]
? 0xffffffffa0326fff
> Sep  8 16:59:12 Insp6400 kernel: [   57.409377]  [<ffffffffa032701e>]
alsa_card_azx_init+0x1e/0x1000 [snd_hda_intel]
> Sep  8 16:59:12 Insp6400 kernel: [   57.409377]  [<ffffffff81002099>]
do_one_initcall+0x7f/0x13a
> Sep  8 16:59:12 Insp6400 kernel: [   57.409377]  [<ffffffffa0327000>]
? 0xffffffffa0326fff
> Sep  8 16:59:12 Insp6400 kernel: [   57.409377]  [<ffffffff8109a60c>]
sys_init_module+0x114/0x267
> Sep  8 16:59:12 Insp6400 kernel: [   57.409377]  [<ffffffff8150b7c2>]
system_call_fastpath+0x16/0x1b
> Sep  8 16:59:12 Insp6400 kernel: [   57.621754] input: HDA Intel Mic at Ext
Right Jack as /devices/pci0000:00/0000:00:1b.0/sound/card0/input7
> Sep  8 16:59:12 Insp6400 kernel: [   57.636306] input: HDA Intel HP Out at
Ext Right Jack as /devices/pci0000:00/0000:00:1b.0/sound/card0/input8
> Sep  8 16:59:12 Insp6400 kernel: [   58.445701] EXT4-fs (sda2): mounting
ext3 file system using the ext4 subsystem
> Sep  8 16:59:12 Insp6400 kernel: [   58.497772] EXT4-fs (sda2): mounted
filesystem with ordered data mode. Opts: (null)
> Sep  8 16:59:12 Insp6400 kernel: [   64.030601] ip6_tables: (C) 2000-2006
Netfilter Core Team
> Sep  8 16:59:12 Insp6400 kernel: [   65.208998] Loading iSCSI transport
class v2.0-870.
> Sep  8 16:59:12 Insp6400 kernel: [   65.232872] nf_conntrack version 0.5.0
(16384 buckets, 65536 max)
> Sep  8 16:59:12 Insp6400 kernel: [   65.862081] iscsi: registered transport
(tcp)
> Sep  8 16:59:13 Insp6400 kernel: [   67.636361] iscsi: registered transport
(iser)
> Sep  8 16:59:15 Insp6400 dbus: avc:  netlink poll: error 4
> Sep  8 16:59:16 Insp6400 abrtd: Init complete, entering main loop
> Sep  8 16:59:16 Insp6400 avahi-daemon[755]: Successfully called chroot().
> Sep  8 16:59:16 Insp6400 avahi-daemon[755]: Successfully dropped remaining
capabilities.
> Sep  8 16:59:16 Insp6400 avahi-daemon[755]: Loading service file
/services/ssh.service.
> Sep  8 16:59:16 Insp6400 kernel: [   70.153389]
libcxgbi:libcxgbi_init_module: tag itt 0x1fff, 13 bits, age 0xf, 4 bits.
> Sep  8 16:59:16 Insp6400 kernel: [   70.154133]
libcxgbi:ddp_setup_host_page_size: system PAGE 4096, ddp idx 0.
> Sep  8 16:59:16 Insp6400 avahi-daemon[755]: Loading service file
/services/udisks.service.
> Sep  8 16:59:16 Insp6400 avahi-daemon[755]: Network interface enumeration
completed.
> Sep  8 16:59:16 Insp6400 avahi-daemon[755]: Registering HINFO record with
values ''X86_64''/''LINUX''.
> Sep  8 16:59:16 Insp6400 avahi-daemon[755]: Server startup complete. Host
name is insp6400.local. Local service cookie is 1645585705.
> Sep  8 16:59:16 Insp6400 avahi-daemon[755]: Service "insp6400"
(/services/udisks.service) successfully established.
> Sep  8 16:59:16 Insp6400 avahi-daemon[755]: Service "insp6400"
(/services/ssh.service) successfully established.
> Sep  8 16:59:16 Insp6400 kernel: [   70.277955] Chelsio T3 iSCSI Driver
cxgb3i v2.0.0 (Jun. 2010)
> Sep  8 16:59:16 Insp6400 kernel: [   70.280171] iscsi: registered transport
(cxgb3i)
> Sep  8 16:59:16 Insp6400 kernel: [   70.533004] cnic: Broadcom NetXtreme II
CNIC Driver cnic v2.5.7 (July 20, 2011)
> Sep  8 16:59:16 Insp6400 kernel: [   70.597280] Broadcom NetXtreme II iSCSI
Driver bnx2i v2.7.0.3 (Jun 15, 2011)
> Sep  8 16:59:16 Insp6400 kernel: [   70.616921] iscsi: registered transport
(bnx2i)
> Sep  8 16:59:16 Insp6400 kernel: [   70.807620] iscsi: registered transport
(be2iscsi)
> Sep  8 16:59:17 Insp6400 iscsid: iSCSI logger with pid=908 started!
> Sep  8 16:59:17 Insp6400 kernel: [   71.418730] iscsid (909):
/proc/909/oom_adj is deprecated, please use /proc/909/oom_score_adj instead.
> Sep  8 16:59:18 Insp6400 iscsid: transport class version 2.0-870. iscsid
version 2.0-872
> Sep  8 16:59:18 Insp6400 iscsid: iSCSI daemon with pid=909 started!
> Sep  8 16:59:21 Insp6400 kernel: [   75.137582] bonding: Ethernet Channel
Bonding Driver: v3.7.1 (April 27, 2011)
> Sep  8 16:59:21 Insp6400 kernel: [   75.181503] bonding: bond0 is being
created...
> Sep  8 16:59:21 Insp6400 kernel: [   75.184019] bonding: bond0 already
exists.
> Sep  8 16:59:21 Insp6400 kernel: [   75.470879] bonding: bond0: setting
mode to balance-tlb (5).
> Sep  8 16:59:21 Insp6400 kernel: [   75.473430] bonding: bond0: Setting MII
monitoring interval to 5.
> Sep  8 16:59:21 Insp6400 kernel: [   75.475896] bonding: bond0: Setting
down delay to 2000.
> Sep  8 16:59:21 Insp6400 kernel: [   75.494222] ADDRCONF(NETDEV_UP): bond0:
link is not ready
> Sep  8 16:59:21 Insp6400 kernel: [   75.832493] bonding: bond0: Adding
slave eth0.
> Sep  8 16:59:21 Insp6400 kernel: [   75.848342] bonding: bond0: enslaving
eth0 as an active interface with a down link.
> Sep  8 16:59:22 Insp6400 kernel: [   76.117901] bonding: bond0: Adding
slave eth1.
> Sep  8 16:59:22 Insp6400 kernel: [   76.250834] r8169 0000:0c:00.0: eth1:
link down
> Sep  8 16:59:22 Insp6400 kernel: [   76.251060] r8169 0000:0c:00.0: eth1:
link down
> Sep  8 16:59:22 Insp6400 kernel: [   76.257039] bonding: bond0: enslaving
eth1 as an active interface with a down link.
> Sep  8 16:59:22 Insp6400 kernel: [   76.460299] Bridge firewalling
registered
> Sep  8 16:59:22 Insp6400 kernel: [   76.535875] device bond0 entered
promiscuous mode
> Sep  8 16:59:23 Insp6400 kernel: [   77.187656] ADDRCONF(NETDEV_UP):
xenbr0: link is not ready
> Sep  8 16:59:24 Insp6400 kernel: [   78.680876] r8169 0000:0c:00.0: eth1:
link up
> Sep  8 16:59:24 Insp6400 kernel: [   78.685920] bonding: bond0: link status
definitely up for interface eth1, 1000 Mbps full duplex.
> Sep  8 16:59:24 Insp6400 kernel: [   78.686063] bonding: bond0: making
interface eth1 the new active one.
> Sep  8 16:59:24 Insp6400 kernel: [   78.686063] device eth1 entered
promiscuous mode
> Sep  8 16:59:24 Insp6400 kernel: [   78.692304] bonding: bond0: first
active interface up!
> Sep  8 16:59:24 Insp6400 kernel: [   78.694863] ADDRCONF(NETDEV_CHANGE):
bond0: link becomes ready
> Sep  8 16:59:24 Insp6400 kernel: [   78.697756] xenbr0: port 1(bond0)
entering forwarding state
> Sep  8 16:59:24 Insp6400 kernel: [   78.698140] xenbr0: port 1(bond0)
entering forwarding state
> Sep  8 16:59:24 Insp6400 kernel: [   78.702807] ADDRCONF(NETDEV_CHANGE):
xenbr0: link becomes ready
> Sep  8 16:59:24 Insp6400 kernel: [   78.704820] b44 ssb0:0: eth0: Link is
up at 100 Mbps, full duplex
> Sep  8 16:59:24 Insp6400 kernel: [   78.705626] b44 ssb0:0: eth0: Flow
control is off for TX and off for RX
> Sep  8 16:59:24 Insp6400 kernel: [   78.709983] bonding: bond0: link status
definitely up for interface eth0, 100 Mbps full duplex.
> Sep  8 16:59:25 Insp6400 avahi-daemon[755]: Registering new address record
for fe80::215:c5ff:fe04:7d4f on bond0.*.
> Sep  8 16:59:26 Insp6400 dhclient[1579]: DHCPREQUEST on xenbr0 to
255.255.255.255 port 67
> Sep  8 16:59:26 Insp6400 dhclient[1579]: DHCPACK from 192.168.1.1
> Sep  8 16:59:26 Insp6400 avahi-daemon[755]: Joining mDNS multicast group on
interface xenbr0.IPv4 with address 192.168.1.100.
> Sep  8 16:59:26 Insp6400 avahi-daemon[755]: New relevant interface
xenbr0.IPv4 for mDNS.
> Sep  8 16:59:26 Insp6400 avahi-daemon[755]: Registering new address record
for 192.168.1.100 on xenbr0.IPv4.
> Sep  8 16:59:26 Insp6400 avahi-daemon[755]: Registering new address record
for fe80::215:c5ff:fe04:7d4f on xenbr0.*.
> Sep  8 16:59:26 Insp6400 NET[1788]: /sbin/dhclient-script : updated
/etc/resolv.conf
> Sep  8 16:59:27 Insp6400 dhclient[1579]: bound to 192.168.1.100 -- renewal
in 65745 seconds.
> Sep  8 16:59:28 Insp6400 kernel: [   82.661777] FS-Cache: Loaded
> Sep  8 16:59:28 Insp6400 kernel: [   82.758652] FS-Cache: Netfs
''cifs'' registered for caching
> Sep  8 16:59:28 Insp6400 kernel: [   82.867310] CIFS VFS: default security
mechanism requested.  The default security mechanism will be upgraded from ntlm
to ntlmv2 in kernel release 3.1
> Sep  8 16:59:34 Insp6400 ntpdate[1977]: step time server 67.18.208.240
offset 0.453408 sec
> Sep  8 16:59:34 Insp6400 ntpd[2153]: ntpd 4.2.6p3@1.2290-o Fri May  6
16:26:49 UTC 2011 (1)
> Sep  8 16:59:34 Insp6400 ntpd[2153]: proto: precision = 1.720 usec
> Sep  8 16:59:34 Insp6400 ntpd[2153]: 0.0.0.0 c01d 0d kern kernel time sync
enabled
> Sep  8 16:59:34 Insp6400 ntpd[2153]: Listen and drop on 0 v4wildcard
0.0.0.0 UDP 123
> Sep  8 16:59:34 Insp6400 ntpd[2153]: Listen and drop on 1 v6wildcard :: UDP
123
> Sep  8 16:59:34 Insp6400 ntpd[2153]: Listen normally on 2 lo 127.0.0.1 UDP
123
> Sep  8 16:59:34 Insp6400 ntpd[2153]: Listen normally on 3 xenbr0
192.168.1.100 UDP 123
> Sep  8 16:59:34 Insp6400 ntpd[2153]: Listen normally on 4 xenbr0
fe80::215:c5ff:fe04:7d4f UDP 123
> Sep  8 16:59:34 Insp6400 ntpd[2153]: Listen normally on 5 bond0
fe80::215:c5ff:fe04:7d4f UDP 123
> Sep  8 16:59:34 Insp6400 ntpd[2153]: Listen normally on 6 lo ::1 UDP 123
> Sep  8 16:59:34 Insp6400 ntpd[2153]: peers refreshed
> Sep  8 16:59:34 Insp6400 ntpd[2153]: Listening on routing socket on fd #23
for interface updates
> Sep  8 16:59:36 Insp6400 ntpd[2153]: 0.0.0.0 c016 06 restart
> Sep  8 16:59:36 Insp6400 ntpd[2153]: 0.0.0.0 c012 02 freq_set kernel 1.500
PPM
> Sep  8 16:59:50 Insp6400 auditd[2741]: Started dispatcher: /sbin/audispd
pid: 2743
> Sep  8 16:59:50 Insp6400 auditd[2741]: Init complete, auditd 2.1.3
listening for events (startup state enable)
> Sep  8 16:59:50 Insp6400 audispd: audispd initialized with q_depth=120 and
1 active plugins
> Sep  8 16:59:51 Insp6400 kernel: [  104.683571] scsi2 : iSCSI Initiator
over TCP/IP
> Sep  8 16:59:51 Insp6400 kernel: [  105.119216] scsi 2:0:0:0: RAID         
IET      Controller       0001 PQ: 0 ANSI: 5
> Sep  8 16:59:51 Insp6400 kernel: [  105.163374] scsi 2:0:0:0: Attached scsi
generic sg2 type 12
> Sep  8 16:59:51 Insp6400 kernel: [  105.182535] scsi 2:0:0:1: Direct-Access
IET      VIRTUAL-DISK     0001 PQ: 0 ANSI: 5
> Sep  8 16:59:51 Insp6400 kernel: [  105.195288] sd 2:0:0:1: [sdb] 312581808
512-byte logical blocks: (160 GB/149 GiB)
> Sep  8 16:59:51 Insp6400 kernel: [  105.201707] sd 2:0:0:1: [sdb] Write
Protect is off
> Sep  8 16:59:51 Insp6400 kernel: [  105.213193] sd 2:0:0:1: Attached scsi
generic sg3 type 0
> Sep  8 16:59:51 Insp6400 kernel: [  105.219746] sd 2:0:0:1: [sdb] Write
cache: enabled, read cache: enabled, doesn''t support DPO or FUA
> Sep  8 16:59:51 Insp6400 iscsid: Connection1:0 to [target:
iqn.2001-04.com.Dell4550-iqn.2009-09.net.bellsouth.sda:041b7d3f-b008-4367-b1f2-b4799d15e4cd,
portal: 192.168.1.101,3260] through [iface: default] is operational now
> Sep  8 16:59:51 Insp6400 kernel: [  105.266929]  sdb: sdb1 sdb2 sdb3
> Sep  8 16:59:51 Insp6400 kernel: [  105.280033] sd 2:0:0:1: [sdb] Attached
SCSI disk
> Sep  8 16:59:52 Insp6400 kernel: [  106.571909] iwl3945 0000:0b:00.0:
loaded firmware version 15.32.2.9
> Sep  8 16:59:53 Insp6400 kernel: [  106.794916] ADDRCONF(NETDEV_UP): wlan0:
link is not ready
> Sep  8 16:59:53 Insp6400 rpc.statd[2928]: Version 1.2.4 starting
> Sep  8 16:59:54 Insp6400 sm-notify[2933]: Version 1.2.4 starting
> Sep  8 16:59:55 Insp6400 kernel: [  108.705060] RPC: Registered named UNIX
socket transport module.
> Sep  8 16:59:55 Insp6400 kernel: [  108.705060] RPC: Registered udp
transport module.
> Sep  8 16:59:55 Insp6400 kernel: [  108.705060] RPC: Registered tcp
transport module.
> Sep  8 16:59:55 Insp6400 kernel: [  108.705060] RPC: Registered tcp NFSv4.1
backchannel transport module.
> Sep  8 16:59:55 Insp6400 kernel: [  108.933995] Installing knfsd (copyright
(C) 1996 okir@monad.swb.de).
> Sep  8 16:59:56 Insp6400 kernel: [  109.739661] ADDRCONF(NETDEV_CHANGE):
wlan0: link becomes ready
> Sep  8 16:59:56 Insp6400 kernel: [  109.896771] NFSD: Using
/var/lib/nfs/v4recovery as the NFSv4 state recovery directory
> Sep  8 16:59:56 Insp6400 kernel: [  109.916136] NFSD: starting 90-second
grace period
> Sep  8 16:59:56 Insp6400 rpc.mountd[3018]: Version 1.2.4 starting
> Sep  8 16:59:57 Insp6400 avahi-daemon[755]: Registering new address record
for fe80::213:2ff:fe1a:f185 on wlan0.*.
> Sep  8 16:59:57 Insp6400 systemd[1]: avguard.service: control process
exited, code=exited status=2
> Sep  8 16:59:57 Insp6400 systemd[1]: Unit avguard.service entered failed
state.
> Sep  8 16:59:58 Insp6400 ntpd[2153]: Listen normally on 7 wlan0
fe80::213:2ff:fe1a:f185 UDP 123
> Sep  8 16:59:58 Insp6400 ntpd[2153]: peers refreshed
> Sep  8 17:00:02 Insp6400 kernel: [  116.591656] xen-pciback: backend is
vpci
> Sep  8 17:00:03 Insp6400 xenstored: Checking store ...
> Sep  8 17:00:03 Insp6400 xenstored: Checking store complete.
> Sep  8 17:00:03 Insp6400 kernel: [  116.911469] BUG: sleeping function
called from invalid context at kernel/mutex.c:271
> Sep  8 17:00:03 Insp6400 kernel: [  116.912065] in_atomic(): 1,
irqs_disabled(): 0, pid: 3208, name: xenstored
> Sep  8 17:00:03 Insp6400 kernel: [  116.912065] INFO: lockdep is turned
off.
> Sep  8 17:00:03 Insp6400 kernel: [  116.912065] Pid: 3208, comm: xenstored
Not tainted 3.1.0-0.rc5.git0.0.fc17.x86_64 #1
> Sep  8 17:00:03 Insp6400 kernel: [  116.912065] Call Trace:
> Sep  8 17:00:03 Insp6400 kernel: [  116.912065]  [<ffffffff8104f6cb>]
__might_sleep+0x103/0x108
> Sep  8 17:00:03 Insp6400 kernel: [  116.912065]  [<ffffffff81503134>]
mutex_lock_nested+0x25/0x45
> Sep  8 17:00:03 Insp6400 kernel: [  116.912065]  [<ffffffff814e0ebd>]
__irq_alloc_descs+0x50/0x18b
> Sep  8 17:00:03 Insp6400 kernel: [  116.912065]  [<ffffffff812d027f>]
? pnp_register_protocol+0x39/0xb4
> Sep  8 17:00:03 Insp6400 kernel: [  116.912065]  [<ffffffff812d972e>]
xen_allocate_irq_dynamic+0x49/0x58
> Sep  8 17:00:03 Insp6400 kernel: [  116.912065]  [<ffffffff812d9e96>]
bind_evtchn_to_irq+0x32/0x82
> Sep  8 17:00:03 Insp6400 kernel: [  116.912065]  [<ffffffff812d9f8e>]
bind_evtchn_to_irqhandler+0x25/0x63
> Sep  8 17:00:03 Insp6400 kernel: [  116.912065]  [<ffffffffa011c4f8>]
? set_port_enabled+0x31/0x31 [xen_evtchn]
> Sep  8 17:00:03 Insp6400 kernel: [  116.912065]  [<ffffffffa011c6a2>]
evtchn_bind_to_user+0x56/0x64 [xen_evtchn]
> Sep  8 17:00:03 Insp6400 kernel: [  116.912065]  [<ffffffffa011c80a>]
evtchn_ioctl+0x129/0x2ef [xen_evtchn]
> Sep  8 17:00:03 Insp6400 kernel: [  116.912065]  [<ffffffff81151e6d>]
do_vfs_ioctl+0x472/0x4b3
> Sep  8 17:00:03 Insp6400 kernel: [  116.912065]  [<ffffffff81151f04>]
sys_ioctl+0x56/0x7a
> Sep  8 17:00:03 Insp6400 kernel: [  116.912065]  [<ffffffff8150b7c2>]
system_call_fastpath+0x16/0x1b
> Sep  8 17:00:03 Insp6400 kernel: [  116.946247] XENBUS: Unable to read cpu
state
> Sep  8 17:00:03 Insp6400 kernel: [  116.949075] XENBUS: Unable to read cpu
state
> Sep  8 17:00:03 Insp6400 kernel: [  116.966668] cfg80211: Calling CRDA to
update world regulatory domain
> Sep  8 17:00:03 Insp6400 avahi-daemon[755]: Withdrawing address record for
fe80::213:2ff:fe1a:f185 on wlan0.
> Sep  8 17:00:03 Insp6400 avahi-daemon[755]: Withdrawing workstation service
for wlan0.
> Sep  8 17:00:03 Insp6400 kernel: [  117.137705] iwl3945 0000:0b:00.0: PCI
INT A disabled
> Sep  8 17:00:03 Insp6400 kernel: [  117.142092] pciback 0000:0b:00.0:
seizing device
> Sep  8 17:00:03 Insp6400 kernel: [  117.146295] xen_map_pirq_gsi: returning
irq 16 for gsi 16
> Sep  8 17:00:03 Insp6400 kernel: [  117.149952] Already setup the GSI :16
> Sep  8 17:00:03 Insp6400 kernel: [  117.150936] pciback 0000:0b:00.0: PCI
INT A -> GSI 16 (level, low) -> IRQ 16
> Sep  8 17:00:03 Insp6400 kernel: [  117.150936] pciback 0000:0b:00.0: PCI
INT A disabled
> Sep  8 17:00:03 Insp6400 smbd[3172]: [2011/09/08 17:00:03.572080,  0]
smbd/server.c:501(smbd_open_one_socket)
> Sep  8 17:00:03 Insp6400 smbd[3172]:   smbd_open_once_socket:
open_socket_in: Address already in use
> Sep  8 17:00:03 Insp6400 smbd[3172]: [2011/09/08 17:00:03.581039,  0]
smbd/server.c:501(smbd_open_one_socket)
> Sep  8 17:00:03 Insp6400 smbd[3172]:   smbd_open_once_socket:
open_socket_in: Address already in use
> Sep  8 17:00:03 Insp6400 kernel: [  117.385355] cfg80211: World regulatory
domain updated:
> Sep  8 17:00:03 Insp6400 kernel: [  117.386066] cfg80211:     (start_freq -
end_freq @ bandwidth), (max_antenna_gain, max_eirp)
> Sep  8 17:00:03 Insp6400 kernel: [  117.386066] cfg80211:     (2402000 KHz
- 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> Sep  8 17:00:03 Insp6400 kernel: [  117.386066] cfg80211:     (2457000 KHz
- 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
> Sep  8 17:00:03 Insp6400 kernel: [  117.386066] cfg80211:     (2474000 KHz
- 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
> Sep  8 17:00:03 Insp6400 kernel: [  117.386066] cfg80211:     (5170000 KHz
- 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> Sep  8 17:00:03 Insp6400 kernel: [  117.386066] cfg80211:     (5735000 KHz
- 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> Sep  8 17:00:03 Insp6400 kernel: [  117.398125] cfg80211: Calling CRDA for
country: US
> Sep  8 17:00:03 Insp6400 kernel: [  117.529792] cfg80211: Regulatory domain
changed to country: US
> Sep  8 17:00:03 Insp6400 kernel: [  117.530194] cfg80211:     (start_freq -
end_freq @ bandwidth), (max_antenna_gain, max_eirp)
> Sep  8 17:00:03 Insp6400 kernel: [  117.530194] cfg80211:     (2402000 KHz
- 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm)
> Sep  8 17:00:03 Insp6400 kernel: [  117.530194] cfg80211:     (5170000 KHz
- 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
> Sep  8 17:00:03 Insp6400 kernel: [  117.530194] cfg80211:     (5250000 KHz
- 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> Sep  8 17:00:03 Insp6400 kernel: [  117.530194] cfg80211:     (5490000 KHz
- 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> Sep  8 17:00:03 Insp6400 kernel: [  117.530194] cfg80211:     (5650000 KHz
- 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> Sep  8 17:00:03 Insp6400 kernel: [  117.530194] cfg80211:     (5735000 KHz
- 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
> Sep  8 17:00:04 Insp6400 ntpd[2153]: Deleting interface #7 wlan0,
fe80::213:2ff:fe1a:f185#123, interface stats: received=0, sent=0, dropped=0,
active_time=6 secs
> Sep  8 17:00:04 Insp6400 ntpd[2153]: peers refreshed
> Sep  8 17:00:07 Insp6400 systemd[1]: vncserver.service: control process
exited, code=exited status=2
> Sep  8 17:00:08 Insp6400 systemd[1]: Unit vncserver.service entered failed
state.
> Sep  8 17:00:15 Insp6400 dbus: [system] Activating via systemd: service
name=''org.freedesktop.ConsoleKit''
unit=''console-kit-daemon.service''
> Sep  8 17:00:16 Insp6400 dbus: [system] Activating service
name=''org.freedesktop.PolicyKit1'' (using servicehelper)
> Sep  8 17:00:16 Insp6400 polkitd[3467]: started daemon version 0.101 using
authority implementation `local'' version `0.101''
> Sep  8 17:00:16 Insp6400 dbus: [system] Successfully activated service
''org.freedesktop.PolicyKit1''
> Sep  8 17:00:16 Insp6400 dbus: [system] Successfully activated service
''org.freedesktop.ConsoleKit''
> Sep  8 17:00:25 Insp6400 nmbd[3169]: [2011/09/08 17:00:25.301440,  0]
nmbd/nmbd_become_lmb.c:395(become_local_master_stage2)
> Sep  8 17:00:25 Insp6400 nmbd[3169]:   *****
> Sep  8 17:00:25 Insp6400 nmbd[3169]:   
> Sep  8 17:00:25 Insp6400 nmbd[3169]:   Samba name server INSP6400 is now a
local master browser for workgroup LINKSYS on subnet 192.168.1.100
> Sep  8 17:00:25 Insp6400 nmbd[3169]:   
> Sep  8 17:00:25 Insp6400 nmbd[3169]:   *****
> Sep  8 17:00:25 Insp6400 systemd[1]: Startup finished in 4s 787ms 508us
(kernel) + 35s 406ms 337us (initrd) + 1min 39s 39ms 614us (userspace) = 2min 19s
233ms 459us.
> Sep  8 17:00:27 Insp6400 avahi-daemon[755]: Joining mDNS multicast group on
interface virbr0.IPv4 with address 192.168.122.1.
> Sep  8 17:00:27 Insp6400 avahi-daemon[755]: New relevant interface
virbr0.IPv4 for mDNS.
> Sep  8 17:00:27 Insp6400 avahi-daemon[755]: Registering new address record
for 192.168.122.1 on virbr0.IPv4.
> Sep  8 17:00:27 Insp6400 kernel: [  140.751611] ADDRCONF(NETDEV_UP):
virbr0: link is not ready
> Sep  8 17:00:27 Insp6400 dnsmasq[3670]: started, version 2.52 cachesize 150
> Sep  8 17:00:27 Insp6400 dnsmasq[3670]: compile time options: IPv6
GNU-getopt DBus no-I18N DHCP TFTP
> Sep  8 17:00:27 Insp6400 dnsmasq-dhcp[3670]: DHCP, IP range 192.168.122.2
-- 192.168.122.254, lease time 1h
> Sep  8 17:00:27 Insp6400 dnsmasq[3670]: reading /etc/resolv.conf
> Sep  8 17:00:27 Insp6400 dnsmasq[3670]: using nameserver 205.152.132.23#53
> Sep  8 17:00:27 Insp6400 dnsmasq[3670]: using nameserver 205.152.144.23#53
> Sep  8 17:00:27 Insp6400 dnsmasq[3670]: using nameserver 205.152.37.23#53
> Sep  8 17:00:27 Insp6400 dnsmasq[3670]: read /etc/hosts - 4855 addresses
> Sep  8 17:00:28 Insp6400 ntpd[2153]: Listen normally on 8 virbr0
192.168.122.1 UDP 123
> Sep  8 17:00:28 Insp6400 ntpd[2153]: peers refreshed
> Sep  8 17:00:29 Insp6400 kernel: [  143.253210] Ebtables v2.0 registered
> Sep  8 17:00:29 Insp6400 dbus: [system] Activating via systemd: service
name=''org.freedesktop.RealtimeKit1''
unit=''rtkit-daemon.service''
> Sep  8 17:00:30 Insp6400 dbus: [system] Successfully activated service
''org.freedesktop.RealtimeKit1''
> Sep  8 21:00:31 Insp6400 rtkit-daemon[3702]: Successfully made thread 3699
of process 3699 (/usr/bin/pulseaudio) owned by ''42'' high
priority at nice level -11.
> Sep  8 21:00:33 Insp6400 rtkit-daemon[3702]: Failed to make thread 3713 RT:
Operation not permitted
> Sep  8 21:00:33 Insp6400 rtkit-daemon[3702]: Failed to make thread 3713 RT:
Operation not permitted
> Sep  8 21:00:33 Insp6400 rtkit-daemon[3702]: Failed to make thread 3716 RT:
Operation not permitted
> Sep  8 21:00:33 Insp6400 rtkit-daemon[3702]: Failed to make thread 3716 RT:
Operation not permitted
> Sep  8 17:00:33 Insp6400 kernel: [  146.796609] hda-intel: Invalid position
buffer, using LPIB read method instead.
> Sep  8 17:00:35 Insp6400 dbus: [system] Activating service
name=''org.freedesktop.UDisks'' (using servicehelper)
> Sep  8 17:00:36 Insp6400 dbus: [system] Successfully activated service
''org.freedesktop.UDisks''
> Sep  8 17:00:36 Insp6400 dbus: [system] Activating service
name=''org.freedesktop.UPower'' (using servicehelper)
> Sep  8 17:00:36 Insp6400 dbus: [system] Successfully activated service
''org.freedesktop.UPower''
> Sep  8 17:00:39 Insp6400 gdm-simple-greeter[3726]: Gtk-WARNING:
gtkwidget.c:6796: widget not within a GtkWindow
> Sep  8 17:00:39 Insp6400 gdm-simple-greeter[3726]: Gtk-WARNING:
gtk_widget_size_allocate(): attempt to allocate widget with width -47 and height
-47
> Sep  8 17:00:40 Insp6400 dbus: [system] Activating via systemd: service
name=''org.freedesktop.Accounts''
unit=''accounts-daemon.service''
> Sep  8 17:00:40 Insp6400 dbus: [system] Successfully activated service
''org.freedesktop.Accounts''
> Sep  8 17:00:40 Insp6400 accounts-daemon[3808]: started daemon version
0.6.10
> Sep  8 17:02:38 Insp6400 nmbd[3169]: [2011/09/08 17:02:38.529251,  0]
nmbd/nmbd_become_lmb.c:395(become_local_master_stage2)
> Sep  8 17:02:38 Insp6400 nmbd[3169]:   *****
> Sep  8 17:02:38 Insp6400 nmbd[3169]:   
> Sep  8 17:02:38 Insp6400 nmbd[3169]:   Samba name server INSP6400 is now a
local master browser for workgroup LINKSYS on subnet 192.168.122.1
> Sep  8 17:02:38 Insp6400 nmbd[3169]:   
> Sep  8 17:02:38 Insp6400 nmbd[3169]:   *****
> Sep  8 17:02:53 Insp6400 ntpd[2153]: 0.0.0.0 c615 05 clock_sync
> Sep  8 17:12:20 Insp6400 dbus: [system] Activating service
name=''net.reactivated.Fprint'' (using servicehelper)
> Sep  8 17:12:21 Insp6400 dbus: [system] Successfully activated service
''net.reactivated.Fprint''
> Sep  8 17:12:33 Insp6400 kernel: [  867.118180] BUG: sleeping function
called from invalid context at kernel/mutex.c:271
> Sep  8 17:12:33 Insp6400 kernel: [  867.118188] in_atomic(): 1,
irqs_disabled(): 0, pid: 3208, name: xenstored
> Sep  8 17:12:33 Insp6400 kernel: [  867.118193] INFO: lockdep is turned
off.
> Sep  8 17:12:33 Insp6400 kernel: [  867.118199] Pid: 3208, comm: xenstored
Not tainted 3.1.0-0.rc5.git0.0.fc17.x86_64 #1
> Sep  8 17:12:33 Insp6400 kernel: [  867.118203] Call Trace:
> Sep  8 17:12:33 Insp6400 kernel: [  867.118215]  [<ffffffff8104f6cb>]
__might_sleep+0x103/0x108
> Sep  8 17:12:33 Insp6400 kernel: [  867.118224]  [<ffffffff81503134>]
mutex_lock_nested+0x25/0x45
> Sep  8 17:12:33 Insp6400 kernel: [  867.118232]  [<ffffffff814e0ebd>]
__irq_alloc_descs+0x50/0x18b
> Sep  8 17:12:33 Insp6400 kernel: [  867.118240]  [<ffffffff812d027f>]
? pnp_register_protocol+0x39/0xb4
> Sep  8 17:12:33 Insp6400 kernel: [  867.118248]  [<ffffffff812d972e>]
xen_allocate_irq_dynamic+0x49/0x58
> Sep  8 17:12:33 Insp6400 kernel: [  867.118254]  [<ffffffff812d9e96>]
bind_evtchn_to_irq+0x32/0x82
> Sep  8 17:12:33 Insp6400 kernel: [  867.118260]  [<ffffffff812d9f8e>]
bind_evtchn_to_irqhandler+0x25/0x63
> Sep  8 17:12:33 Insp6400 kernel: [  867.118292]  [<ffffffffa011c4f8>]
? set_port_enabled+0x31/0x31 [xen_evtchn]
> Sep  8 17:12:33 Insp6400 kernel: [  867.118302]  [<ffffffffa011c6a2>]
evtchn_bind_to_user+0x56/0x64 [xen_evtchn]
> Sep  8 17:12:33 Insp6400 kernel: [  867.118313]  [<ffffffffa011c80a>]
evtchn_ioctl+0x129/0x2ef [xen_evtchn]
> Sep  8 17:12:33 Insp6400 kernel: [  867.118321]  [<ffffffff81151e6d>]
do_vfs_ioctl+0x472/0x4b3
> Sep  8 17:12:33 Insp6400 kernel: [  867.118327]  [<ffffffff81151f04>]
sys_ioctl+0x56/0x7a
> Sep  8 17:12:33 Insp6400 kernel: [  867.118335]  [<ffffffff8150b7c2>]
system_call_fastpath+0x16/0x1b
> Sep  8 17:12:34 Insp6400 kernel: [  868.191636] device tap1.0 entered
promiscuous mode
> Sep  8 17:12:34 Insp6400 kernel: [  868.192285] xenbr0: port 2(tap1.0)
entering forwarding state
> Sep  8 17:12:34 Insp6400 kernel: [  868.192341] xenbr0: port 2(tap1.0)
entering forwarding state
> Sep  8 17:12:34 Insp6400 kernel: [  868.353440] BUG: sleeping function
called from invalid context at kernel/mutex.c:271
> Sep  8 17:12:34 Insp6400 kernel: [  868.353448] in_atomic(): 1,
irqs_disabled(): 0, pid: 4171, name: qemu-dm
> Sep  8 17:12:34 Insp6400 kernel: [  868.353452] INFO: lockdep is turned
off.
> Sep  8 17:12:34 Insp6400 kernel: [  868.353458] Pid: 4171, comm: qemu-dm
Not tainted 3.1.0-0.rc5.git0.0.fc17.x86_64 #1
> Sep  8 17:12:34 Insp6400 kernel: [  868.353462] Call Trace:
> Sep  8 17:12:34 Insp6400 kernel: [  868.353474]  [<ffffffff8104f6cb>]
__might_sleep+0x103/0x108
> Sep  8 17:12:34 Insp6400 kernel: [  868.353483]  [<ffffffff81503134>]
mutex_lock_nested+0x25/0x45
> Sep  8 17:12:34 Insp6400 kernel: [  868.353491]  [<ffffffff814e0ebd>]
__irq_alloc_descs+0x50/0x18b
> Sep  8 17:12:34 Insp6400 kernel: [  868.353499]  [<ffffffff812d027f>]
? pnp_register_protocol+0x39/0xb4
> Sep  8 17:12:34 Insp6400 kernel: [  868.353507]  [<ffffffff812d972e>]
xen_allocate_irq_dynamic+0x49/0x58
> Sep  8 17:12:34 Insp6400 kernel: [  868.353513]  [<ffffffff812d9e96>]
bind_evtchn_to_irq+0x32/0x82
> Sep  8 17:12:34 Insp6400 kernel: [  868.353519]  [<ffffffff812d9f8e>]
bind_evtchn_to_irqhandler+0x25/0x63
> Sep  8 17:12:34 Insp6400 kernel: [  868.353532]  [<ffffffffa011c4f8>]
? set_port_enabled+0x31/0x31 [xen_evtchn]
> Sep  8 17:12:34 Insp6400 kernel: [  868.353543]  [<ffffffffa011c6a2>]
evtchn_bind_to_user+0x56/0x64 [xen_evtchn]
> Sep  8 17:12:34 Insp6400 kernel: [  868.353553]  [<ffffffffa011c80a>]
evtchn_ioctl+0x129/0x2ef [xen_evtchn]
> Sep  8 17:12:34 Insp6400 kernel: [  868.353561]  [<ffffffff81151e6d>]
do_vfs_ioctl+0x472/0x4b3
> Sep  8 17:12:34 Insp6400 kernel: [  868.353568]  [<ffffffff81151f04>]
sys_ioctl+0x56/0x7a
> Sep  8 17:12:34 Insp6400 kernel: [  868.353576]  [<ffffffff8150b7c2>]
system_call_fastpath+0x16/0x1b
> Sep  8 17:12:35 Insp6400 kernel: [  869.241732] xenbr0: port 2(tap1.0)
entering forwarding state
> Sep  8 17:12:35 Insp6400 kernel: [  869.336479] xenbr0: port 2(tap1.0)
entering forwarding state
> Sep  8 17:12:35 Insp6400 kernel: [  869.336566] xenbr0: port 2(tap1.0)
entering forwarding state
> Sep  8 17:12:36 Insp6400 /etc/sysconfig/network-scripts/ifup-aliases:
Missing config file tap1.0.
> Sep  8 17:12:36 Insp6400 kernel: [  870.457363] device vif1.0 entered
promiscuous mode
> Sep  8 17:12:36 Insp6400 kernel: [  870.471816] ADDRCONF(NETDEV_UP):
vif1.0: link is not ready
> Sep  8 17:12:36 Insp6400 avahi-daemon[755]: Registering new address record
for fe80::fcff:ffff:feff:ffff on tap1.0.*.
> Sep  8 17:12:38 Insp6400 ntpd[2153]: Listen normally on 9 tap1.0
fe80::fcff:ffff:feff:ffff UDP 123
> Sep  8 17:12:38 Insp6400 ntpd[2153]: peers refreshed
> Sep  8 17:15:36 Insp6400 kernel: [ 1049.819851] BUG: sleeping function
called from invalid context at kernel/mutex.c:271
> Sep  8 17:15:36 Insp6400 kernel: [ 1049.819859] in_atomic(): 1,
irqs_disabled(): 0, pid: 3208, name: xenstored
> Sep  8 17:15:36 Insp6400 kernel: [ 1049.819864] INFO: lockdep is turned
off.
> Sep  8 17:15:36 Insp6400 kernel: [ 1049.819869] Pid: 3208, comm: xenstored
Not tainted 3.1.0-0.rc5.git0.0.fc17.x86_64 #1
> Sep  8 17:15:36 Insp6400 kernel: [ 1049.819873] Call Trace:
> Sep  8 17:15:36 Insp6400 kernel: [ 1049.819886]  [<ffffffff8104f6cb>]
__might_sleep+0x103/0x108
> Sep  8 17:15:36 Insp6400 kernel: [ 1049.819894]  [<ffffffff81503134>]
mutex_lock_nested+0x25/0x45
> Sep  8 17:15:36 Insp6400 kernel: [ 1049.819902]  [<ffffffff810c22b5>]
free_desc+0x30/0x64
> Sep  8 17:15:36 Insp6400 kernel: [ 1049.819908]  [<ffffffff810c2322>]
irq_free_descs+0x39/0x72
> Sep  8 17:15:36 Insp6400 kernel: [ 1049.819917]  [<ffffffff812d9564>]
xen_free_irq+0x49/0x4e
> Sep  8 17:15:36 Insp6400 kernel: [ 1049.819923]  [<ffffffff812d9af8>]
unbind_from_irq+0xde/0xf5
> Sep  8 17:15:36 Insp6400 kernel: [ 1049.819929]  [<ffffffff812d9b28>]
unbind_from_irqhandler+0x19/0x1d
> Sep  8 17:15:36 Insp6400 kernel: [ 1049.819940]  [<ffffffffa011c0ae>]
evtchn_unbind_from_user+0x1e/0x32 [xen_evtchn]
> Sep  8 17:15:36 Insp6400 kernel: [ 1049.819950]  [<ffffffffa011c90a>]
evtchn_ioctl+0x229/0x2ef [xen_evtchn]
> Sep  8 17:15:36 Insp6400 kernel: [ 1049.819959]  [<ffffffff81151e6d>]
do_vfs_ioctl+0x472/0x4b3
> Sep  8 17:15:36 Insp6400 kernel: [ 1049.819965]  [<ffffffff81151f04>]
sys_ioctl+0x56/0x7a
> Sep  8 17:15:36 Insp6400 kernel: [ 1049.819973]  [<ffffffff8150b7c2>]
system_call_fastpath+0x16/0x1b
> Sep  8 17:15:36 Insp6400 kernel: [ 1049.878662] xenbr0: port 2(tap1.0)
entering forwarding state
> Sep  8 17:15:36 Insp6400 avahi-daemon[755]: Withdrawing address record for
fe80::fcff:ffff:feff:ffff on tap1.0.
> Sep  8 17:15:36 Insp6400 kernel: [ 1049.882314] xenbr0: port 2(tap1.0)
entering disabled state
> Sep  8 17:15:36 Insp6400 kernel: [ 1049.883411] xenbr0: port 2(tap1.0)
entering disabled state
> Sep  8 17:15:36 Insp6400 avahi-daemon[755]: Withdrawing workstation service
for tap1.0.
> Sep  8 17:15:36 Insp6400 kernel: [ 1050.510285] xenbr0: port 3(vif1.0)
entering disabled state
> Sep  8 17:15:36 Insp6400 kernel: [ 1050.511039] xenbr0: port 3(vif1.0)
entering disabled state
> Sep  8 17:15:36 Insp6400 avahi-daemon[755]: Withdrawing workstation service
for vif1.0.
> Sep  8 17:15:37 Insp6400 ntpd[2153]: Deleting interface #9 tap1.0,
fe80::fcff:ffff:feff:ffff#123, interface stats: received=0, sent=0, dropped=0,
active_time=179 secs
> Sep  8 17:15:37 Insp6400 ntpd[2153]: peers refreshed
> Sep  8 17:17:37 Insp6400 kernel: [ 1171.421852] BUG: sleeping function
called from invalid context at kernel/mutex.c:271
> Sep  8 17:17:37 Insp6400 kernel: [ 1171.421860] in_atomic(): 1,
irqs_disabled(): 0, pid: 3230, name: xenconsoled
> Sep  8 17:17:37 Insp6400 kernel: [ 1171.421864] INFO: lockdep is turned
off.
> Sep  8 17:17:37 Insp6400 kernel: [ 1171.421870] Pid: 3230, comm:
xenconsoled Not tainted 3.1.0-0.rc5.git0.0.fc17.x86_64 #1
> Sep  8 17:17:37 Insp6400 kernel: [ 1171.421874] Call Trace:
> Sep  8 17:17:37 Insp6400 kernel: [ 1171.421886]  [<ffffffff8104f6cb>]
__might_sleep+0x103/0x108
> Sep  8 17:17:37 Insp6400 kernel: [ 1171.421895]  [<ffffffff81503134>]
mutex_lock_nested+0x25/0x45
> Sep  8 17:17:37 Insp6400 kernel: [ 1171.421903]  [<ffffffff810c22b5>]
free_desc+0x30/0x64
> Sep  8 17:17:37 Insp6400 kernel: [ 1171.421909]  [<ffffffff810c2322>]
irq_free_descs+0x39/0x72
> Sep  8 17:17:37 Insp6400 kernel: [ 1171.421918]  [<ffffffff812d9564>]
xen_free_irq+0x49/0x4e
> Sep  8 17:17:37 Insp6400 kernel: [ 1171.421924]  [<ffffffff812d9af8>]
unbind_from_irq+0xde/0xf5
> Sep  8 17:17:37 Insp6400 kernel: [ 1171.421930]  [<ffffffff812d9b28>]
unbind_from_irqhandler+0x19/0x1d
> Sep  8 17:17:37 Insp6400 kernel: [ 1171.421942]  [<ffffffffa011c0ae>]
evtchn_unbind_from_user+0x1e/0x32 [xen_evtchn]
> Sep  8 17:17:37 Insp6400 kernel: [ 1171.421952]  [<ffffffffa011c146>]
evtchn_release+0x84/0xab [xen_evtchn]
> Sep  8 17:17:37 Insp6400 kernel: [ 1171.421960]  [<ffffffff811443c1>]
fput+0x127/0x1f5
> Sep  8 17:17:37 Insp6400 kernel: [ 1171.421966]  [<ffffffff811413af>]
filp_close+0x70/0x7b
> Sep  8 17:17:37 Insp6400 kernel: [ 1171.421974]  [<ffffffff8105f926>]
put_files_struct+0xca/0x18d
> Sep  8 17:17:37 Insp6400 kernel: [ 1171.421980]  [<ffffffff8105fa83>]
exit_files+0x48/0x50
> Sep  8 17:17:37 Insp6400 kernel: [ 1171.421987]  [<ffffffff81060043>]
do_exit+0x2d0/0x82c
> Sep  8 17:17:37 Insp6400 kernel: [ 1171.421995]  [<ffffffff81007d5f>]
? xen_restore_fl_direct_reloc+0x4/0x4
> Sep  8 17:17:37 Insp6400 kernel: [ 1171.422003]  [<ffffffff8108ad74>]
? arch_local_irq_restore+0xb/0xd
> Sep  8 17:17:37 Insp6400 kernel: [ 1171.422010]  [<ffffffff81060840>]
do_group_exit+0x88/0xb6
> Sep  8 17:17:37 Insp6400 kernel: [ 1171.422017]  [<ffffffff8106f0a2>]
get_signal_to_deliver+0x528/0x57d
> Sep  8 17:17:37 Insp6400 kernel: [ 1171.422025]  [<ffffffff8100ef50>]
do_signal+0x3e/0x629
> Sep  8 17:17:37 Insp6400 kernel: [ 1171.422033]  [<ffffffff81201c6d>]
? security_file_permission+0x2e/0x33
> Sep  8 17:17:37 Insp6400 kernel: [ 1171.422040]  [<ffffffff811428e0>]
? rw_verify_area+0xb6/0xd3
> Sep  8 17:17:37 Insp6400 kernel: [ 1171.422046]  [<ffffffff8100f57c>]
do_notify_resume+0x28/0x83
> Sep  8 17:17:37 Insp6400 kernel: [ 1171.422055]  [<ffffffff8150bb13>]
int_signal+0x12/0x17
> Sep  8 17:17:38 Insp6400 systemd[1]: xenstored.service: control process
exited, code=exited status=1
> Sep  8 17:17:38 Insp6400 systemd[1]: Unit xenstored.service entered failed
state.
> Sep  8 17:17:47 Insp6400 kernel: Kernel logging (proc) stopped.
> Sep  8 17:17:47 Insp6400 rsyslogd: [origin software="rsyslogd"
swVersion="5.8.2" x-pid="789"
x-info="http://www.rsyslog.com"] exiting on signal 15.

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

jim burns

2011-Sep-12 20:07 UTC

head link

[Xen-users] Re: Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

On Mon September 12 2011, 10:36:23 AM, Pasi Kärkkäinen
wrote:> > Sure, thanx, attached. Do you need a debug log also (initcall_debug
> > debug  loglevel=10)?
> >
> 
> Sure, it doesn''t hurt..
I''ll get it to you in a couple of days.
> > The last four BUG:s (from Sep  8 17:12:20 on) were from starting a
winxp
> > domu  (first 3 BUG:s), and destroying it at grub (the last BUG:).
> 
> Ok, so there are BUGs when booting up, and also when starting HVM guests.
Right, from Sep 8, 17:12 on. The ''comm:''s referenced are
xenstored (2x) and
qemu-dm (1x) when starting the guest (as far as grub), and xenconsoled when 
''xm destroy''-ing it.

Thanx for your interest.

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

Pasi Kärkkäinen

2011-Sep-13 08:55 UTC

head link

[Xen-devel] Re: [Xen-users] Re: Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

On Mon, Sep 12, 2011 at 04:07:21PM -0400, jim burns
wrote:> On Mon September 12 2011, 10:36:23 AM, Pasi Kärkkäinen wrote:
> > > Sure, thanx, attached. Do you need a debug log also
(initcall_debug
> > > debug  loglevel=10)?
> > >
> > 
> > Sure, it doesn''t hurt..
> 
> I''ll get it to you in a couple of days.
> 
Ok, thanks!

also: I assume you won''t get any BUGs when booting the same kernel
on baremetal/native?

> > > The last four BUG:s (from Sep  8 17:12:20 on) were from starting
a winxp
> > > domu  (first 3 BUG:s), and destroying it at grub (the last BUG:).
> > 
> > Ok, so there are BUGs when booting up, and also when starting HVM
guests.
> 
> Right, from Sep 8, 17:12 on. The ''comm:''s referenced are
xenstored (2x) and
> qemu-dm (1x) when starting the guest (as far as grub), and xenconsoled when
> ''xm destroy''-ing it.
> 
> Thanx for your interest.
> 
-- Pasi


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

jim burns

2011-Sep-13 23:50 UTC

head link

[Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

On Tue September 13 2011, 11:55:59 AM, Pasi Kärkkäinen
wrote:> On Mon, Sep 12, 2011 at 04:07:21PM -0400, jim burns wrote:
> > On Mon September 12 2011, 10:36:23 AM, Pasi Kärkkäinen wrote:
> > > > Sure, thanx, attached. Do you need a debug log also
> > > > (initcall_debug
> > > > debug  loglevel=10)?
> > >
> > > 
> > >
> > > Sure, it doesn''t hurt..
> >
> > 
> >
> > I''ll get it to you in a couple of days.
> >
> > 
> 
> Ok, thanks!
Rawhide just came out with 3.1.0-0.rc6.git0.0.fc17.x86_64 , and the BUG:s are 
still the same as in the last log I sent. However, as promised I have attached 
the initcall_debug log, but for rc6.

I had an interesting problem with my grub stanza that made me fear that it was 
back to not booting at all under xen. It looked just like the same problem 
that rc0 and rc1 had. The problem was that the xen option 
''serial_tx_buffer=64k'' was too small, and was causing the boot
to stall. I
upped the buffer to 256k. I''m including the output from the too small
buffer
below, merely for amusement - it was my problem, not xen''s.

Using the following grub stanza:

title Xen Dom0 w/debug console (3.1.0-0.rcx.gity.z.fc17.x86_64)
        root (hd0,1)
        kernel /xen.gz cpufreq=xen loglvl=all guest_loglvl=all 
serial_tx_buffer=256k console_to_ring noreboot com1=115200,8n1,0xdff8,19 
console=com1
        module /vmlinuz ro root=/dev/mapper/vg_insp6400-lv_root 
SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us console=hvc0 
earlyprintk=xen nomodeset initcall_debug debug loglevel=10
        module /initramfs

where vmlinuz and initramfs are soft links, and x,y,z is rc5.git0.0 for the 
attached file with ''initcall_debug'', and rc6.git0.0 for the
(unimportant)
crash shown below (with the 64k buffer).
> also: I assume you won''t get any BUGs when booting the same kernel
> on baremetal/native?
That has been correct for rc2 - rc6. From an earlier post in the original 
''Summary: Experiences setting up a debug serial port'' thread:
> On Mon August 15 2011, 4:04:20 AM, jim burns wrote:
>> Pls cc me with responses, as I''m not subscribed.
> Yay! After a string of fedora rawhide 3.1.0-rc0 and -rc1''s that
did not
> boot  under xen, 3.1.0-0.rc2.git0.1.fc17.x86_64 boots under xen, it has the
> vga patch, and xen-pciback correctly siezes my wireless device.
> Unfortunately, while a baremetal boot is clean, a xen boot has several
> BUG:''s of the form:
The (unimportant) rc6 crash:

 __  __            _  _    _   _   _____   __      _ _____ 
 \ \/ /___ _ __   | || |  / | / | |___ /  / _| ___/ |___  |
  \  // _ \ ''_ \  | || |_ | | | |__ |_ \ | |_ / __| |  / / 
  /  \  __/ | | | |__   _|| |_| |__|__) ||  _| (__| | / /  
 /_/\_\___|_| |_|    |_|(_)_(_)_| |____(_)_|  \___|_|/_/   
                                                           
(XEN) Xen version 4.1.1 (mockbuild@phx2.fedoraproject.org) (gcc version 4.6.1 
20110715 (Red Hat 4.6.1-3) (GCC) ) Sun Aug 14 14:14:02 UTC 2011
(XEN) Latest ChangeSet: unavailable
(XEN) Bootloader: GNU GRUB 0.97-71.fc15
(XEN) Command line: cpufreq=xen loglvl=all guest_loglvl=all 
serial_tx_buffer=64k console_to_ring noreboot com1=115200,8n1,0xdff8,19 
console=com1
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009f000 (usable)
(XEN)  000000000009f000 - 00000000000a0000 (reserved)
(XEN)  0000000000100000 - 000000007f6d3400 (usable)
(XEN)  000000007f6d3400 - 0000000080000000 (reserved)
(XEN)  00000000f0000000 - 00000000f4007000 (reserved)
(XEN)  00000000f4008000 - 00000000f400c000 (reserved)
(XEN)  00000000fec00000 - 00000000fec10000 (reserved)
(XEN)  00000000fed20000 - 00000000feda0000 (reserved)
(XEN)  00000000fee00000 - 00000000fee10000 (reserved)
(XEN)  00000000ffb00000 - 0000000100000000 (reserved)
(XEN) System RAM: 2038MB (2087368kB)
(XEN) ACPI: RSDP 000FC1D0, 0014 (r0 DELL  )
(XEN) ACPI: RSDT 7F6D3A0F, 0040 (r1 DELL    M07     27D7060D ASL        61)
(XEN) ACPI: FACP 7F6D4800, 0074 (r1 DELL    M07     27D7060D ASL        61)
(XEN) ACPI: DSDT 7F6D5400, 4766 (r1 INT430 SYSFexxx     1001 INTL 20050624)
(XEN) ACPI: FACS 7F6E3C00, 0040
(XEN) ACPI: HPET 7F6D4F00, 0038 (r1 DELL    M07            1 ASL        61)
(XEN) ACPI: APIC 7F6D5000, 0068 (r1 DELL    M07     27D7060D ASL        47)
(XEN) ACPI: MCFG 7F6D4FC0, 003E (r16 DELL    M07     27D7060D ASL        61)
(XEN) ACPI: SLIC 7F6D509C, 0176 (r1 DELL    M07     27D7060D ASL        61)
(XEN) ACPI: BOOT 7F6D4BC0, 0028 (r1 DELL    M07     27D7060D ASL        61)
(XEN) ACPI: SSDT 7F6D3A4F, 04DC (r1  PmRef    CpuPm     3000 INTL 20050624)
(XEN) No NUMA configuration found
(XEN) Faking a node at 0000000000000000-000000007f6d3000
(XEN) Domain heap initialised
(XEN) DMI 2.4 present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x1008
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[1004,0], pm1x_evt[1000,0]
(XEN) ACPI:                  wakeup_vec[7f6e3c0c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
(XEN) Processor #0 6:15 APIC version 20
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
(XEN) Processor #1 6:15 APIC version 20
(XEN) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
(XEN) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
(XEN) ACPI: HPET id: 0x8086a201 base: 0xfed00000
(XEN) PCI: MCFG configuration 0: base f0000000 segment 0 buses 0 - 63
(XEN) PCI: MCFG area at f0000000 reserved in E820
(XEN) Table is not found!
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) IRQ limits: 24 GSI, 376 MSI/MSI-X
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 1828.797 MHz processor.
(XEN) Initing memory sharing.
(XEN) mce_intel.c:1162: MCA Capability: BCAST 1 SER 0 CMCI 0 firstbank 1 
extended MCE MSR 0
(XEN) Intel machine check reporting enabled
(XEN) I/O virtualisation disabled
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using new ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) Platform timer is 14.318MHz HPET
�(XEN) Allocated console ring of 16 KiB.
(XEN) VMX: Supported advanced features:
(XEN)  - APIC TPR shadow
(XEN)  - MSR direct-access bitmap
(XEN) HVM: ASIDs disabled.
(XEN) HVM: VMX enabled
(XEN) Brought up 2 CPUs
(XEN) HPET: 3 timers in total, 0 timers will be used for broadcast
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x2ae6000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000074000000->0000000078000000 (456574 pages to be 
allocated)
(XEN)  Init. ramdisk: 000000007c9bf000->000000007f1ff200
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff82ae6000
(XEN)  Init. ramdisk: ffffffff82ae6000->ffffffff85326200
(XEN)  Phys-Mach map: ffffffff85327000->ffffffff856d6df8
(XEN)  Start info:    ffffffff856d7000->ffffffff856d74b4
(XEN)  Page tables:   ffffffff856d8000->ffffffff85707000
(XEN)  Boot stack:    ffffffff85707000->ffffffff85708000
(XEN)  TOTAL:         ffffffff80000000->ffffffff85800000
(XEN)  ENTRY ADDRESS: ffffffff81d53200
(XEN) Dom0 has maximum 2 VCPUs
(XEN) Scrubbing Free RAM: .done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) *** Serial input -> DOM0 (type ''CTRL-a'' three times
to switch input to
Xen)
(XEN) Freed 224kB init memory.
mapping kernel into physical memory
Xen: setup ISA identity maps
about to get started...
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.1.0-0.rc6.git0.0.fc17.x86_64 
(mockbuild@x86-02.phx2.fedoraproject.org) (gcc version 4.6.1 20110824 (Red Hat 
4.6.1-8) (GCC) ) #1 SMP Mon Sep 12 22:56:38 UTC 2011
[    0.000000] Command line: ro root=/dev/mapper/vg_insp6400-lv_root 
SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us console=hvc0 
earlyprintk=xen nomodeset initcall_debug debug loglevel=10
[    0.000000] released 0 pages of unused memory
[    0.000000] Set 526733 page(s) to 1-1 mapping.
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  Xen: 0000000000000000 - 000000000009f000 (usable)
[    0.000000]  Xen: 000000000009f000 - 0000000000100000 (reserved)
[    0.000000]  Xen: 0000000000100000 - 0000000075fbf000 (usable)
[    0.000000]  Xen: 0000000075fbf000 - 000000007f6d3000 (unusable)
[    0.000000]  Xen: 000000007f6d3400 - 0000000080000000 (reserved)
[    0.000000]  Xen: 00000000f0000000 - 00000000f4007000 (reserved)
[    0.000000]  Xen: 00000000f4008000 - 00000000f400c000 (reserved)
[    0.000000]  Xen: 00000000fec00000 - 00000000fec10000 (reserved)
[    0.000000]  Xen: 00000000fed20000 - 00000000feda0000 (reserved)
[    0.000000]  Xen: 00000000fee00000 - 00000000fee10000 (reserved)
[    0.000000]  Xen: 00000000ffb00000 - 0000000100000000 (reserved)
[    0.000000]  Xen: 0000000100000000 - 0000000525db7000 (usable)
[    0.000000] bootconsole [xenboot0] enabled
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI 2.4 present.
[    0.000000] DMI: Dell Inc. MM061                           /0KD882, BIOS 
A17 06/13/2007
[    0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) 
==> (reserved)
[    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
[    0.000000] No AGP bridge found
[    0.000000] last_pfn = 0x525db7 max_arch_pfn = 0x400000000
[    0.000000] last_pfn = 0x75fbf max_arch_pfn = 0x400000000
[    0.000000] initial memory mapped : 0 - 05327000
[    0.000000] Base memory trampoline at [ffff88000009a000] 9a000 size 20480
[    0.000000] init_memory_mapping: 0000000000000000-0000000075fbf000
[    0.000000]  0000000000 - 0075fbf000 page 4k
[    0.000000] kernel direct mapping tables up to 75fbf000 @ 75c0c000-75fbf000
[    0.000000] xen: setting RW the range 75f8d000 - 75fbf000
[    0.000000] init_memory_mapping: 0000000100000000-0000000525db7000
[    0.000000]  0100000000 - 0525db7000 page 4k
[    0.000000] kernel direct mapping tables up to 525db7000 @ 
732c7000-75c0c000
[    0.000000] xen: setting RW the range 75407000 - 75c0c000
[    0.000000] RAMDISK: 02ae6000 - 05327000
[    0.000000] ACPI: RSDP 00000000000fc1d0 00014 (v00 DELL  )
[    0.000000] ACPI: RSDT 000000007f6d3a0f 00040 (v01 DELL    M07     27D7060D 
ASL  00000061)
[    0.000000] ACPI: FACP 000000007f6d4800 00074 (v01 DELL    M07     27D7060D 
ASL  00000061)
[    0.000000] ACPI: DSDT 000000007f6d5400 04766 (v01 INT430 SYSFexxx 00001001 
INTL 20050624)
[    0.000000] ACPI: FACS 000000007f6e3c00 00040
[    0.000000] ACPI: HPET 000000007f6d4f00 00038 (v01 DELL    M07     00000001 
ASL  00000061)
[    0.000000] ACPI: APIC 000000007f6d5000 00068 (v01 DELL    M07     27D7060D 
ASL  00000047)
[    0.000000] ACPI: MCFG 000000007f6d4fc0 0003E (v16 DELL    M07     27D7060D 
ASL  00000061)
[    0.000000] ACPI: SLIC 000000007f6d509c 00176 (v01 DELL    M07     27D7060D 
ASL  00000061)
[    0.000000] ACPI: BOOT 000000007f6d4bc0 00028 (v01 DELL    M07     27D7060D 
ASL  00000061)
[    0.000000] ACPI: SSDT 000000007f6d3a4f 004DC (v01  PmRef    CpuPm 00003000 
INTL 20050624)
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] No NUMA configuration found
[    0.000000] Faking a node at 0000000000000000-0000000525db7000
[    0.000000] Initmem setup node 0 0000000000000000-0000000525db7000
[    0.000000]   NODE_DATA [0000000075faa000 - 0000000075fbefff]
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA      0x00000010 -> 0x00001000
[    0.000000]   DMA32    0x00001000 -> 0x00100000
[    0.000000]   Normal   0x00100000 -> 0x00525db7
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[3] active PFN ranges
[    0.000000]     0: 0x00000010 -> 0x0000009f
[    0.000000]     0: 0x00000100 -> 0x00075fbf
[    0.000000]     0: 0x00100000 -> 0x00525db7
[    0.000000] On node 0 totalpages: 4832517
[    0.000000]   DMA zone: 64 pages used for memmap
[    0.000000]   DMA zone: 5 pages reserved
[    0.000000]   DMA zone: 3914 pages, LIFO batch:0
[    0.000000]   DMA32 zone: 16320 pages used for memmap
[    0.000000]   DMA32 zone: 462847 pages, LIFO batch:31
[    0.000000]   Normal zone: 67959 pages used for memmap
[    0.000000]   Normal zone: 4281408 pages, LIFO batch:31
[    0.000000] BUG: unable to handle kernel NULL pointer dereference at
(null)
[    0.000000] IP: [<ffffffff81006437>] __xen_set_pte+0x51/0x5b
[    0.000000] PGD 0 
[    0.000000] Oops: 0003 [#1] SMP 
[    0.000000] CPU 0 
[    0.000000] Modules linked in:
[    0.000000] 
[    0.000000] Pid: 0, comm: swapper Not tainted 
3.1.0-0.rc6.git0.0.fc17.x86_64 #1 Dell Inc. MM061                           
/0KD882
[    0.000000] RIP: e030:[<ffffffff81006437>]  [<ffffffff81006437>] 
__xen_set_pte+0x51/0x5b
[    0.000000] RSP: e02b:ffffffff81a01dc8  EFLAGS: 00010096
[    0.000000] RAX: 00000000ffffffff RBX: ffff880075b01000 RCX: 
ffffffff829b2000
[    0.000000] RDX: 0000000010000001 RSI: 8000000075a02065 RDI: 
ffff880075b01000
[    0.000000] RBP: ffffffff81a01de8 R08: 0000000000000000 R09: 
0000000000007ff0
[    0.000000] R10: 0000000000007ff0 R11: 0000000000007ff0 R12: 
8000000075a02065
[    0.000000] R13: 0000000001a02000 R14: ffffffffffffffff R15: 
0000000000000000
[    0.000000] FS:  0000000000000000(0000) GS:ffffffff81b7e000(0000) 
knlGS:0000000000000000
[    0.000000] CS:  e033 DS: 0000 ES: 0000 CR0: 0000000080050033
[    0.000000] CR2: 0000000000000000 CR3: 0000000001a05000 CR4: 
0000000000002660
[    0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 
0000000000000000
[    0.000000] DR3: 0000000000000000 DR6: 0000000000000000 DR7: 
0000000000000000
[    0.000000] Process swapper (pid: 0, threadinfo ffffffff81a00000, task 
ffffffff81a0d020)
[    0.000000] Stack:
[    0.000000]  00003ffffffff000 ffffffff829b2000 ffff880075b01000 
8000000075a02065
[    0.000000]  ffffffff81a01e18 ffffffff8100655c 0000000000007ff0 
ffffffffff600000
[    0.000000]  8000000075a02065 0000000001a02000 ffffffff81a01e28 
ffffffff81032ddc
[    0.000000] Call Trace:
[    0.000000]  [<ffffffff8100655c>] xen_set_pte+0x75/0x95
[    0.000000]  [<ffffffff81032ddc>] set_pte+0x10/0x12
[    0.000000]  [<ffffffff81033305>] set_pte_vaddr_pud+0x3c/0x4b
[    0.000000]  [<ffffffff81005141>] xen_set_fixmap+0xb4/0xbb
[    0.000000]  [<ffffffff81d593d5>] map_vsyscall+0x50/0x69
[    0.000000]  [<ffffffff81d58aab>] setup_arch+0xa7e/0xb2f
[    0.000000]  [<ffffffff814fa131>] ? printk+0x51/0x53
[    0.000000]  [<ffffffff81d538a3>] start_kernel+0xe1/0x3ea
[    0.000000]  [<ffffffff81d532c4>] x86_64_start_reservations+0xaf/0xb3
[    0.000000]  [<ffffffff81d55f18>] xen_start_kernel+0x588/0x58f
[    0.000000] Code: df e8 4a 04 03 00 48 89 c7 e8 82 ee ff ff 48 8d 7d e0 48 
89 45 e0 4c 89 65 e8 e8 fd f4 ff ff bf 01 00 00 00 e8 a4 f7 ff ff eb 03
<4c>
89 23 58 5a 5b 41 5c 5d c3 55 48 89 e5 41 57 41 56 41 55 41 
[    0.000000] RIP  [<ffffffff81006437>] __xen_set_pte+0x51/0x5b
[    0.000000]  RSP <ffffffff81a01dc8>
[    0.000000] CR2: 0000000000000000
[    0.000000] ---[ end trace a7919e7f17c0a725 ]---
[    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
[    0.000000] Pid: 0, comm: swapper Tainted: G      D     
3.1.0-0.rc6.git0.0.fc17.x86_64 #1
[    0.000000] Call Trace:
[    0.000000]  [<ffffffff814f9fc7>] panic+0xa0/0x1b9
[    0.000000]  [<ffffffff8105fe6d>] do_exit+0x9e/0x82c
[    0.000000]  [<ffffffff8105dde6>] ? kmsg_dump+0x131/0x14f
[    0.000000]  [<ffffffff8105dd3e>] ? kmsg_dump+0x89/0x14f
[    0.000000]  [<ffffffff81506201>] oops_end+0xbc/0xc5
[    0.000000]  [<ffffffff814f9841>] no_context+0x208/0x217
[    0.000000]  [<ffffffff8108eb05>] ? __lock_acquire+0xc5d/0xd0c
[    0.000000]  [<ffffffff814f9a20>] __bad_area_nosemaphore+0x1d0/0x1f1
[    0.000000]  [<ffffffff8100765f>] ? 
__raw_callee_save_xen_restore_fl+0x11/0x1e
[    0.000000]  [<ffffffff81007641>] ?
__raw_callee_save_xen_save_fl+0x11/0x1e
[    0.000000]  [<ffffffff814f9a54>] bad_area_nosemaphore+0x13/0x15
[    0.000000]  [<ffffffff8150830b>] do_page_fault+0x1b1/0x3a2
[    0.000000]  [<ffffffff81007641>] ?
__raw_callee_save_xen_save_fl+0x11/0x1e
[    0.000000]  [<ffffffff815057b6>] ? error_sti+0x5/0x6
[    0.000000]  [<ffffffff81505324>] ? restore_args+0x30/0x30
[    0.000000]  [<ffffffff8108adcb>] ? arch_local_save_flags+0xb/0xd
[    0.000000]  [<ffffffff8108b8bf>] ? trace_hardirqs_off_caller+0x33/0x90
[    0.000000]  [<ffffffff81253dcd>] ? trace_hardirqs_off_thunk+0x3a/0x3c
[    0.000000]  [<ffffffff81505575>] page_fault+0x25/0x30
[    0.000000]  [<ffffffff81006437>] ? __xen_set_pte+0x51/0x5b
[    0.000000]  [<ffffffff81006401>] ? __xen_set_pte+0x1b/0x5b
[    0.000000]  [<ffffffff8100655c>] xen_set_pte+0x75/0x95
[    0.000000]  [<ffffffff81032ddc>] set_pte+0x10/0x12
[    0.000000]  [<ffffffff81033305>] set_pte_vaddr_pud+0x3c/0x4b
[    0.000000]  [<ffffffff81005141>] xen_set_fixmap+0xb4/0xbb
[    0.000000]  [<ffffffff81d593d5>] map_vsyscall+0x50/0x69
[    0.000000]  [<ffffffff81d58aab>] setup_arch+0xa7e/0xb2f
[    0.000000]  [<ffffffff814fa131>] ? printk+0x51/0x53
[    0.000000]  [<ffffffff81d538a3>] start_kernel+0xe1/0x3ea
[    0.000000]  [<ffffffff81d532c4>] x86_64_start_reservations+0xaf/0xb3
[    0.000000]  [<ffffffff81d55f18>] xen_start_kernel+0x588/0x58f
(XEN) Domain 0 crashed: ''noreboot'' set - not rebooting.



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

jim burns

2011-Sep-14 01:44 UTC

head link

[Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

On Tue September 13 2011, 7:50:55 PM, jim burns wrote:> where vmlinuz and initramfs are soft links, and x,y,z is rc5.git0.0 for the
> attached file with ''initcall_debug'', and rc6.git0.0 for
the (unimportant)
> crash shown below (with the 64k buffer).
Sorry - both the attached file, and the (unimportant) crash file were for rc6.

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

Konrad Rzeszutek Wilk

2011-Sep-14 09:08 UTC

head link

Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

> Rawhide just came out with 3.1.0-0.rc6.git0.0.fc17.x86_64 , and the BUG:s
are
> still the same as in the last log I sent. However, as promised I have
attached
> the initcall_debug log, but for rc6.
Hey Jim,

We are quite sure we know the cause of this. I was wondering if you would be
up for beta-testing a patch for this?

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

Konrad Rzeszutek Wilk

2011-Sep-14 10:57 UTC

head link

Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

On Wed, Sep 14, 2011 at 05:08:06AM -0400, Konrad Rzeszutek Wilk
wrote:> > Rawhide just came out with 3.1.0-0.rc6.git0.0.fc17.x86_64 , and the
BUG:s are
> > still the same as in the last log I sent. However, as promised I have
attached
> > the initcall_debug log, but for rc6.
> 
> Hey Jim,
> 
> We are quite sure we know the cause of this. I was wondering if you would
be
> up for beta-testing a patch for this?
Specifically this patch seems to fix it for me:


commit 690dc11498b192db25762de77988224753517c96
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Wed Sep 14 05:10:00 2011 -0400

    xen/irq: Alter the locking to be a mutex.
    
    When we allocate/change the IRQ informations, we do not
    need to use a psinlock. We can use a mutex (which is
    what the generic IRQ code does for allocations/changes.
    
    Suggested-by: Ian Campbell <ian.campbell@citrix.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index da70f5c..7523719 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -54,7 +54,7 @@
  * This lock protects updates to the following mapping and reference-count
  * arrays. The lock does not need to be acquired to read the mapping tables.
  */
-static DEFINE_SPINLOCK(irq_mapping_update_lock);
+static DEFINE_MUTEX(irq_mapping_update_lock);
 
 static LIST_HEAD(xen_irq_list_head);
 
@@ -631,7 +631,7 @@ int xen_bind_pirq_gsi_to_irq(unsigned gsi,
 	int irq = -1;
 	struct physdev_irq irq_op;
 
-	spin_lock(&irq_mapping_update_lock);
+	mutex_lock(&irq_mapping_update_lock);
 
 	irq = find_irq_by_gsi(gsi);
 	if (irq != -1) {
@@ -684,7 +684,7 @@ int xen_bind_pirq_gsi_to_irq(unsigned gsi,
 				handle_edge_irq, name);
 
 out:
-	spin_unlock(&irq_mapping_update_lock);
+	mutex_unlock(&irq_mapping_update_lock);
 
 	return irq;
 }
@@ -710,7 +710,7 @@ int xen_bind_pirq_msi_to_irq(struct pci_dev *dev, struct
msi_desc *msidesc,
 {
 	int irq, ret;
 
-	spin_lock(&irq_mapping_update_lock);
+	mutex_lock(&irq_mapping_update_lock);
 
 	irq = xen_allocate_irq_dynamic();
 	if (irq == -1)
@@ -724,10 +724,10 @@ int xen_bind_pirq_msi_to_irq(struct pci_dev *dev, struct
msi_desc *msidesc,
 	if (ret < 0)
 		goto error_irq;
 out:
-	spin_unlock(&irq_mapping_update_lock);
+	mutex_unlock(&irq_mapping_update_lock);
 	return irq;
 error_irq:
-	spin_unlock(&irq_mapping_update_lock);
+	mutex_unlock(&irq_mapping_update_lock);
 	xen_free_irq(irq);
 	return -1;
 }
@@ -740,7 +740,7 @@ int xen_destroy_irq(int irq)
 	struct irq_info *info = info_for_irq(irq);
 	int rc = -ENOENT;
 
-	spin_lock(&irq_mapping_update_lock);
+	mutex_lock(&irq_mapping_update_lock);
 
 	desc = irq_to_desc(irq);
 	if (!desc)
@@ -766,7 +766,7 @@ int xen_destroy_irq(int irq)
 	xen_free_irq(irq);
 
 out:
-	spin_unlock(&irq_mapping_update_lock);
+	mutex_unlock(&irq_mapping_update_lock);
 	return rc;
 }
 
@@ -776,7 +776,7 @@ int xen_irq_from_pirq(unsigned pirq)
 
 	struct irq_info *info;
 
-	spin_lock(&irq_mapping_update_lock);
+	mutex_lock(&irq_mapping_update_lock);
 
 	list_for_each_entry(info, &xen_irq_list_head, list) {
 		if (info == NULL || info->type != IRQT_PIRQ)
@@ -787,7 +787,7 @@ int xen_irq_from_pirq(unsigned pirq)
 	}
 	irq = -1;
 out:
-	spin_unlock(&irq_mapping_update_lock);
+	mutex_unlock(&irq_mapping_update_lock);
 
 	return irq;
 }
@@ -802,7 +802,7 @@ int bind_evtchn_to_irq(unsigned int evtchn)
 {
 	int irq;
 
-	spin_lock(&irq_mapping_update_lock);
+	mutex_lock(&irq_mapping_update_lock);
 
 	irq = evtchn_to_irq[evtchn];
 
@@ -818,7 +818,7 @@ int bind_evtchn_to_irq(unsigned int evtchn)
 	}
 
 out:
-	spin_unlock(&irq_mapping_update_lock);
+	mutex_unlock(&irq_mapping_update_lock);
 
 	return irq;
 }
@@ -829,7 +829,7 @@ static int bind_ipi_to_irq(unsigned int ipi, unsigned int
cpu)
 	struct evtchn_bind_ipi bind_ipi;
 	int evtchn, irq;
 
-	spin_lock(&irq_mapping_update_lock);
+	mutex_lock(&irq_mapping_update_lock);
 
 	irq = per_cpu(ipi_to_irq, cpu)[ipi];
 
@@ -853,7 +853,7 @@ static int bind_ipi_to_irq(unsigned int ipi, unsigned int
cpu)
 	}
 
  out:
-	spin_unlock(&irq_mapping_update_lock);
+	mutex_unlock(&irq_mapping_update_lock);
 	return irq;
 }
 
@@ -878,7 +878,7 @@ int bind_virq_to_irq(unsigned int virq, unsigned int cpu)
 	struct evtchn_bind_virq bind_virq;
 	int evtchn, irq;
 
-	spin_lock(&irq_mapping_update_lock);
+	mutex_lock(&irq_mapping_update_lock);
 
 	irq = per_cpu(virq_to_irq, cpu)[virq];
 
@@ -903,7 +903,7 @@ int bind_virq_to_irq(unsigned int virq, unsigned int cpu)
 	}
 
 out:
-	spin_unlock(&irq_mapping_update_lock);
+	mutex_unlock(&irq_mapping_update_lock);
 
 	return irq;
 }
@@ -913,7 +913,7 @@ static void unbind_from_irq(unsigned int irq)
 	struct evtchn_close close;
 	int evtchn = evtchn_from_irq(irq);
 
-	spin_lock(&irq_mapping_update_lock);
+	mutex_lock(&irq_mapping_update_lock);
 
 	if (VALID_EVTCHN(evtchn)) {
 		close.port = evtchn;
@@ -943,7 +943,7 @@ static void unbind_from_irq(unsigned int irq)
 
 	xen_free_irq(irq);
 
-	spin_unlock(&irq_mapping_update_lock);
+	mutex_unlock(&irq_mapping_update_lock);
 }
 
 int bind_evtchn_to_irqhandler(unsigned int evtchn,
@@ -1279,7 +1279,7 @@ void rebind_evtchn_irq(int evtchn, int irq)
 	   will also be masked. */
 	disable_irq(irq);
 
-	spin_lock(&irq_mapping_update_lock);
+	mutex_lock(&irq_mapping_update_lock);
 
 	/* After resume the irq<->evtchn mappings are all cleared out */
 	BUG_ON(evtchn_to_irq[evtchn] != -1);
@@ -1289,7 +1289,7 @@ void rebind_evtchn_irq(int evtchn, int irq)
 
 	xen_irq_info_evtchn_init(irq, evtchn);
 
-	spin_unlock(&irq_mapping_update_lock);
+	mutex_unlock(&irq_mapping_update_lock);
 
 	/* new event channels are always bound to cpu 0 */
 	irq_set_affinity(irq, cpumask_of(0));


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

Andy Burns

2011-Sep-14 20:18 UTC

head link

Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

On 14 September 2011 11:57, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com>wrote:

> > We are quite sure we know the cause of this. I was wondering if you
would
> be
> > up for beta-testing a patch for this?
>
> Specifically this patch seems to fix it for me:
>
> commit 690dc11498b192db25762de77988224753517c96
> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date:   Wed Sep 14 05:10:00 2011 -0400
>
>I''ll try to give that a go tomorrow night, I''m bumping into
the same sort of
BUGs (scheduling while atomic, sleeping function called from invalid
context) with FC16 dom0, they don''t seem to bring the system to its
knees
though they do stop it shutting down cleanly, havent fired up any domU yet.


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

jim burns

2011-Sep-14 21:07 UTC

head link

Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

On Wed September 14 2011, 6:57:11 AM, Konrad Rzeszutek Wilk
wrote:> On Wed, Sep 14, 2011 at 05:08:06AM -0400, Konrad Rzeszutek Wilk wrote:
> > > Rawhide just came out with 3.1.0-0.rc6.git0.0.fc17.x86_64 , and
the
> > > BUG:s are  still the same as in the last log I sent. However, as
> > > promised I have attached the initcall_debug log, but for rc6.
> >
> > 
> >
> > Hey Jim,
> >
> > 
> >
> > We are quite sure we know the cause of this. I was wondering if you
> > would be up for beta-testing a patch for this?
> 
> Specifically this patch seems to fix it for me:
> 
> 
> commit 690dc11498b192db25762de77988224753517c96
> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date:   Wed Sep 14 05:10:00 2011 -0400
>     xen/irq: Alter the locking to be a mutex.
I''ll try to apply this to fedora''s xen src rpm over the
weekend. In case it
doesn''t apply, would you remind me of the git commands for the code you
applied this patch to? Thanx.

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

Konrad Rzeszutek Wilk

2011-Sep-14 22:12 UTC

head link

Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

On Wed, Sep 14, 2011 at 05:07:28PM -0400, jim burns
wrote:> On Wed September 14 2011, 6:57:11 AM, Konrad Rzeszutek Wilk wrote:
> > On Wed, Sep 14, 2011 at 05:08:06AM -0400, Konrad Rzeszutek Wilk wrote:
> > > > Rawhide just came out with 3.1.0-0.rc6.git0.0.fc17.x86_64 ,
and the
> > > > BUG:s are  still the same as in the last log I sent.
However, as
> > > > promised I have attached the initcall_debug log, but for
rc6.
> > >
> > > 
> > >
> > > Hey Jim,
> > >
> > > 
> > >
> > > We are quite sure we know the cause of this. I was wondering if
you
> > > would be up for beta-testing a patch for this?
> > 
> > Specifically this patch seems to fix it for me:
> > 
> > 
> > commit 690dc11498b192db25762de77988224753517c96
> > Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > Date:   Wed Sep 14 05:10:00 2011 -0400
> >     xen/irq: Alter the locking to be a mutex.
> 
> I''ll try to apply this to fedora''s xen src rpm over the
weekend. In case it
> doesn''t apply, would you remind me of the git commands for the
code you
> applied this patch to? Thanx.
I just save the email in some mbox file and then do
git am < <the saved mbox file> and it should automatically add it.

Or you can just do patch -p1 <the saved mbox file> and it will apply it
too.


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

jim burns

2011-Sep-14 23:05 UTC

head link

Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

On Wed September 14 2011, 6:12:54 PM, Konrad Rzeszutek Wilk
wrote:> > I''ll try to apply this to fedora''s xen src rpm over
the weekend. In case
> > it  doesn''t apply, would you remind me of the git commands
for the code
> > you applied this patch to? Thanx.
> 
> I just save the email in some mbox file and then do
> git am < <the saved mbox file> and it should automatically add it.
> 
> Or you can just do patch -p1 <the saved mbox file> and it will apply
it too.
No - I understand patching. I meant what version of the xen code did you 
patch? Something like:

 $ cd /usr/src
 $ hg clone http://bits.xensource.com/xen-unstable.hg xen-unstable.hg
 $ cd xen-unstable.hg
 $ sudo make xen
 $ sudo make tools
 $ sudo make install-xen
 $ sudo make install-tools

or some other version? (Again, if I can''t get it to apply to the fedora
src
rpm cleanly.) Thanx.

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

M A Young

2011-Sep-14 23:38 UTC

head link

Re: [Fedora-xen] [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

On Wed, 14 Sep 2011, Konrad Rzeszutek Wilk wrote:
> On Wed, Sep 14, 2011 at 05:07:28PM -0400, jim burns wrote:
>> On Wed September 14 2011, 6:57:11 AM, Konrad Rzeszutek Wilk wrote:
>>> On Wed, Sep 14, 2011 at 05:08:06AM -0400, Konrad Rzeszutek Wilk
wrote:
>>>
>>> commit 690dc11498b192db25762de77988224753517c96
>>> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>> Date:   Wed Sep 14 05:10:00 2011 -0400
>>>     xen/irq: Alter the locking to be a mutex.
>>
>> I''ll try to apply this to fedora''s xen src rpm over
the weekend. In case it
>> doesn''t apply, would you remind me of the git commands for the
code you
>> applied this patch to? Thanx.
>
> I just save the email in some mbox file and then do
> git am < <the saved mbox file> and it should automatically add it.
>
> Or you can just do patch -p1 <the saved mbox file> and it will apply
it too.
I have a (temporary) F17 kernel with the patch from 
http://oss.oracle.com/git/kwilk/xen.git/?p=kwilk/xen.git;a=commit;h=a7079a6404ed2106315327fff6be3464d10814e7
(which I assume is the same patch) applied building at 
http://koji.fedoraproject.org/koji/taskinfo?taskID=3352367
if you want to test it.

 	Michael Young

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

jim burns

2011-Sep-15 01:18 UTC

head link

Re: [Fedora-xen] [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

On Thu September 15 2011, 12:38:26 AM, M A Young wrote:> I have a (temporary) F17 kernel with the patch from 
>
http://oss.oracle.com/git/kwilk/xen.git/?p=kwilk/xen.git;a=commit;h=a7079a64
> 04ed2106315327fff6be3464d10814e7  (which I assume is the same patch)
applied
> building at
> http://koji.fedoraproject.org/koji/taskinfo?taskID=3352367
> if you want to test it.
Oh - the patch is to the kernel, not to xen. I misread it.

Ok - I downloaded 
http://koji.fedoraproject.org/koji/getfile?taskID=3352368&name=kernel-3.1.0-0.rc6.git0.0.xendom0.fc17.x86_64.rpm

I hope that''s right. I''ll try it tomorrow. Thanx.

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

Konrad Rzeszutek Wilk

2011-Sep-15 07:53 UTC

head link

Re: [Fedora-xen] [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

On Thu, Sep 15, 2011 at 12:38:26AM +0100, M A Young
wrote:> On Wed, 14 Sep 2011, Konrad Rzeszutek Wilk wrote:
> 
> >On Wed, Sep 14, 2011 at 05:07:28PM -0400, jim burns wrote:
> >>On Wed September 14 2011, 6:57:11 AM, Konrad Rzeszutek Wilk wrote:
> >>>On Wed, Sep 14, 2011 at 05:08:06AM -0400, Konrad Rzeszutek Wilk
wrote:
> >>>
> >>>commit 690dc11498b192db25762de77988224753517c96
> >>>Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >>>Date:   Wed Sep 14 05:10:00 2011 -0400
> >>>    xen/irq: Alter the locking to be a mutex.
> >>
> >>I''ll try to apply this to fedora''s xen src rpm
over the weekend. In case it
> >>doesn''t apply, would you remind me of the git commands for
the code you
> >>applied this patch to? Thanx.
> >
> >I just save the email in some mbox file and then do
> >git am < <the saved mbox file> and it should automatically add
it.
> >
> >Or you can just do patch -p1 <the saved mbox file> and it will
apply it too.
> 
> I have a (temporary) F17 kernel with the patch from
http://oss.oracle.com/git/kwilk/xen.git/?p=kwilk/xen.git;a=commit;h=a7079a6404ed2106315327fff6be3464d10814e7
> (which I assume is the same patch) applied building at
Yup!
> http://koji.fedoraproject.org/koji/taskinfo?taskID=3352367
> if you want to test it.
Great! Thanks for doing this.> 
> 	Michael Young
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Konrad Rzeszutek Wilk

2011-Sep-15 15:20 UTC

head link

Re: [Fedora-xen] [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

On Wed, Sep 14, 2011 at 09:18:25PM -0400, jim burns
wrote:> On Thu September 15 2011, 12:38:26 AM, M A Young wrote:
> > I have a (temporary) F17 kernel with the patch from 
> >
http://oss.oracle.com/git/kwilk/xen.git/?p=kwilk/xen.git;a=commit;h=a7079a64
> > 04ed2106315327fff6be3464d10814e7  (which I assume is the same patch)
applied
> > building at
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=3352367
> > if you want to test it.
> 
> Oh - the patch is to the kernel, not to xen. I misread it.
> 
> Ok - I downloaded 
>
http://koji.fedoraproject.org/koji/getfile?taskID=3352368&name=kernel-3.1.0-0.rc6.git0.0.xendom0.fc17.x86_64.rpm
> 
> I hope that''s right. I''ll try it tomorrow. Thanx.
ping?

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

jim burns

2011-Sep-16 14:55 UTC

head link

Re: [Fedora-xen] [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

On Thu September 15 2011, 3:53:58 AM, Konrad Rzeszutek Wilk
wrote:> On Wed, Sep 14, 2011 at 09:18:25PM -0400, jim burns wrote:
> > On Thu September 15 2011, 12:38:26 AM, M A Young wrote:
> > > I have a (temporary) F17 kernel with the patch from 
> > > 
http://oss.oracle.com/git/kwilk/xen.git/?p=kwilk/xen.git;a=commit;h=a7079a64> > > 04ed2106315327fff6be3464d10814e7  (which I assume is the same
patch)
> > > applied building at
> > > http://koji.fedoraproject.org/koji/taskinfo?taskID=3352367
> > > if you want to test it.
> > 
> > Oh - the patch is to the kernel, not to xen. I misread it.
> > 
> > Ok - I downloaded 
> > 
http://koji.fedoraproject.org/koji/getfile?taskID=3352368&name=kernel-3.1.0-0.rc6.git0.0.xendom0.fc17.x86_64.rpm> > 
> > I hope that''s right. I''ll try it tomorrow. Thanx.
> 
> ping?
Echo reply - router congestion.

Testing out myoung''s 3.1.0 was not as straight forward as I had hoped.
It did
boot up without any BUG:s, but I did get the occasional Lock Order message. 
Log snippet at the end of the post. It doesn''t seem to be directly
related to
starting guests.

The real problem comes in starting up guests. Performance is very bad. I knew 
from working with rawhide 3.0.0 (long since replaced) that performance would 
suffer - rawhide kernels are debug kernels:

jimb@insp6400 09/16/11 10:16AM:~
[511] > grep DEBUG /boot/config-3.1.0-0.rc6.git0.0.xendom0.fc17.x86_64|grep
-v
''is not set''|wc -l
91
jimb@insp6400 09/16/11 10:16AM:~
[512] > grep DEBUG /boot/config-2.6.40.4-5.fc15.x86_64|grep -v ''is
not set''|wc
-l           
54
jimb@insp6400 09/16/11 10:18AM:~
[513] > grep DEBUG /boot/config-3.0.1-3.fc16.x86_64|grep -v ''is not
set''|wc -l
90

Starting guests is much slower under myoung''s 3.1.0 than under
rawhide''s 3.1.0
or 3.0.{0,1}. A cifs backed pv domu took 6 min. for ''xm
create'' to exit,
during most of which, dom0 was totally unresponsive, and another 2 min. to get 
to the login screen. The 2nd attempt took 4 min. to get to the login screen - 
presumably the cifs file backed domu was still partially cached. (When I say 
unresponsive, I mean userland. I have a client computer with an iscsi target, 
and cifs/nfs connections to the dom0, and I was still getting slow traffic 
(presumably interrupt based, keep alive signals), and the dom0 hard disk light 
was constantly blinking.)

Starting a winxp domu was much worse. ''xm create'' totally
locked up my dom0,
so that I had to reboot. One time, I took a nap after starting the domu, and 
got up 4 hrs. later, and dom0 was still locked up.

''xm create'' did not  provide any diagnostic information.
''xl create'' was a
little more chatty:

root@insp6400 09/16/11 12:09AM:~
[544] > xl create Documents/winxp; brctl show;  ps -A|grep qemu; netstat
-tlp|
grep 59; renice -11 `pidof qemu-dm`;  ps -A|grep vncv; ifconfig vif1.0 mtu 
9000
Parsing config file Documents/winxp
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->000000000017b270
  TOTAL:         0000000000000000->000000003fc00000
  ENTRY ADDRESS: 00000000001015a0
xc: error: Could not allocate memory for HVM guest. (16 = Device or resource 
busy): Internal error
libxl: error: libxl_dom.c:284:libxl__build_hvm hvm building failed

and my serial debug log had several:

(XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (1 of 
4)
(XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 
4)
(XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 
4)
(XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 
4)
(XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 
4)
(XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 
4)
(XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 
4)
(XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 
4)
(XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 
4)
(XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 
4)
(XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 
4)
(XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 
4)
(XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 
4)
(XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 
4)
(XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 
4)
(XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 
4)
(XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 
4)
(XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 
4)
(XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 
4)
(XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 
4)
(XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 
4)
(XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 
4)
(XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 
4)
(XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0 of 
4)
(XEN) memory.c:133:d0 Could not allocate order=0 extent: id=1 memflags=0 (439 
of 2048)

Then I remembered that I recently upped the memory allocation for my winxp 
domu, from 512 to 768. This works fine under 2.6.40, the f15 non-debug 
production kernel. None the less, I knocked the allocation back down to 512, 
and my winxp domu did start up, getting to the qemu splash screen in about 2 - 
3 min., during part of which dom0 was unresponsive. However, I''m still
getting
the ''(XEN) memory.c'' errors, and some frequent GPF errors (a
few a min.) in my
serial debug log:

(XEN) traps.c:2956: GPF (0060): ffff82c48015354a -> ffff82c480200131

Then, rawhide and gplpv don''t get along. Specifically, the xennet
receive side
driver stops working, and I have to fall back to qemu emulation. It takes 
about an hour for the winxp desktop to finish initializing, with dom0 cpu load 
on one cpu core at 72% - yum! But I''ll just have to live with it -
it''s not
your problem. I''ll leave it up for at least a day to see if any other
messages
pop up.

Hope this was of some help.

Lock Order /var/log/messages snippet:

Sep 16 01:10:19 Insp6400 kernel: [  473.537933] 
=====================================================Sep 16 01:10:19 Insp6400
kernel: [  473.537933] [ INFO: HARDIRQ-safe ->
HARDIRQ-unsafe lock order detected ]
Sep 16 01:10:19 Insp6400 kernel: [  473.537933] 
3.1.0-0.rc6.git0.0.xendom0.fc17.x86_64 #1
Sep 16 01:10:19 Insp6400 kernel: [  473.537933] 
------------------------------------------------------
Sep 16 01:10:19 Insp6400 kernel: [  473.537933] swapper/0 
[HC0[0]:SC1[3]:HE0:SE0] is trying to acquire:
Sep 16 01:10:19 Insp6400 kernel: [  473.537933]  (nf_conntrack_lock){+.-...}, 
at: [<ffffffffa036a7b7>] destroy_conntrack+0x70/0xec [nf_conntrack]
Sep 16 01:10:19 Insp6400 kernel: [  473.537933] 
Sep 16 01:10:19 Insp6400 kernel: [  473.537933] and this task is already 
holding:
Sep 16 01:10:19 Insp6400 kernel: [  473.537933] 
(&(&bp->lock)->rlock)
{-.-.-.}, at: [<ffffffffa0287a6a>] b44_poll+0x28/0x3ec [b44]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] which would create a new lock 
dependency:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] 
(&(&bp->lock)->rlock){-.-.-.}
-> (nf_conntrack_lock){+.-...}
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] 
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] but this new dependency 
connects a HARDIRQ-irq-safe lock:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] 
(&(&bp->lock)->rlock){-.-.-.}
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] ... which became HARDIRQ-irq-
safe at:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff8108e176>] 
__lock_acquire+0x2ce/0xd0c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff8108f0b7>] 
lock_acquire+0xf3/0x13e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff815044fd>] 
_raw_spin_lock+0x45/0x79
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffffa0285725>] 
b44_interrupt+0x25/0xd9 [b44]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff810c2958>] 
handle_irq_event_percpu+0xb4/0x271
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff810c2b5c>] 
handle_irq_event+0x47/0x67
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff810c4ef0>] 
handle_fasteoi_irq+0x8a/0xb0
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff812d986f>] 
__xen_evtchn_do_upcall+0x15e/0x203
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff812daf65>] 
xen_evtchn_do_upcall+0x2c/0x3e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff8150dfce>] 
xen_do_hypervisor_callback+0x1e/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] 
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] to a HARDIRQ-irq-unsafe lock:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  (nf_conntrack_lock){+.-...}
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] ... which became HARDIRQ-irq-
unsafe at:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] ...  [<ffffffff8108e1ed>] 
__lock_acquire+0x345/0xd0c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff8108f0b7>] 
lock_acquire+0xf3/0x13e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff81504846>] 
_raw_spin_lock_bh+0x4a/0x7e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffffa036bf48>] 
nf_conntrack_in+0x461/0x7dc [nf_conntrack]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffffa03985ff>] 
ipv4_conntrack_in+0x21/0x23 [nf_conntrack_ipv4]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff8143c97d>] 
nf_iterate+0x4c/0x8c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff8143ca39>] 
nf_hook_slow+0x7c/0x123
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff8144621f>] 
NF_HOOK.constprop.4+0x46/0x5a
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff814468d9>] 
ip_rcv+0x239/0x264
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff81415df5>] 
__netif_receive_skb+0x4af/0x508
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff81415ed8>] 
process_backlog+0x8a/0x151
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff81417c0a>] 
net_rx_action+0xae/0x21c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff81062b2e>] 
__do_softirq+0x112/0x25a
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff8150df7c>] 
call_softirq+0x1c/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff81010bfd>] 
do_softirq+0x4b/0xa2
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff81062edd>] 
irq_exit+0x5d/0xcf
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff812daf6a>] 
xen_evtchn_do_upcall+0x31/0x3e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff8150dfce>] 
xen_do_hypervisor_callback+0x1e/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] 
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] other info that might help us 
debug this:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] 
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  Possible interrupt unsafe 
locking scenario:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] 
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]        CPU0                    
CPU1
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]        ----                    
----
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   lock(nf_conntrack_lock);
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]                                
local_irq_disable();
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]                                
lock(&(&bp->lock)->rlock);
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]                                
lock(nf_conntrack_lock);
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   <Interrupt>
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    
lock(&(&bp->lock)->rlock);
Sep 16 01:10:19 Insp6400 kernel: [  473.537933] 
Sep 16 01:10:19 Insp6400 kernel: [  473.537933] 
=====================================================Sep 16 01:10:19 Insp6400
kernel: [  473.537933] [ INFO: HARDIRQ-safe ->
HARDIRQ-unsafe lock order detected ]
Sep 16 01:10:19 Insp6400 kernel: [  473.537933] 
3.1.0-0.rc6.git0.0.xendom0.fc17.x86_64 #1
Sep 16 01:10:19 Insp6400 kernel: [  473.537933] 
------------------------------------------------------
Sep 16 01:10:19 Insp6400 kernel: [  473.537933] swapper/0 
[HC0[0]:SC1[3]:HE0:SE0] is trying to acquire:
Sep 16 01:10:19 Insp6400 kernel: [  473.537933]  (nf_conntrack_lock){+.-...}, 
at: [<ffffffffa036a7b7>] destroy_conntrack+0x70/0xec [nf_conntrack]
Sep 16 01:10:19 Insp6400 kernel: [  473.537933] 
Sep 16 01:10:19 Insp6400 kernel: [  473.537933] and this task is already 
holding:
Sep 16 01:10:19 Insp6400 kernel: [  473.537933] 
(&(&bp->lock)->rlock)
{-.-.-.}, at: [<ffffffffa0287a6a>] b44_poll+0x28/0x3ec [b44]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] which would create a new lock 
dependency:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] 
(&(&bp->lock)->rlock){-.-.-.}
-> (nf_conntrack_lock){+.-...}
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] 
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] but this new dependency 
connects a HARDIRQ-irq-safe lock:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] 
(&(&bp->lock)->rlock){-.-.-.}
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] ... which became HARDIRQ-irq-
safe at:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff8108e176>] 
__lock_acquire+0x2ce/0xd0c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff8108f0b7>] 
lock_acquire+0xf3/0x13e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff815044fd>] 
_raw_spin_lock+0x45/0x79
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffffa0285725>] 
b44_interrupt+0x25/0xd9 [b44]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff810c2958>] 
handle_irq_event_percpu+0xb4/0x271
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff810c2b5c>] 
handle_irq_event+0x47/0x67
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff810c4ef0>] 
handle_fasteoi_irq+0x8a/0xb0
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff812d986f>] 
__xen_evtchn_do_upcall+0x15e/0x203
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff812daf65>] 
xen_evtchn_do_upcall+0x2c/0x3e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff8150dfce>] 
xen_do_hypervisor_callback+0x1e/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] 
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] to a HARDIRQ-irq-unsafe lock:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  (nf_conntrack_lock){+.-...}
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] ... which became HARDIRQ-irq-
unsafe at:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] ...  [<ffffffff8108e1ed>] 
__lock_acquire+0x345/0xd0c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff8108f0b7>] 
lock_acquire+0xf3/0x13e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff81504846>] 
_raw_spin_lock_bh+0x4a/0x7e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffffa036bf48>] 
nf_conntrack_in+0x461/0x7dc [nf_conntrack]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffffa03985ff>] 
ipv4_conntrack_in+0x21/0x23 [nf_conntrack_ipv4]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff8143c97d>] 
nf_iterate+0x4c/0x8c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff8143ca39>] 
nf_hook_slow+0x7c/0x123
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff8144621f>] 
NF_HOOK.constprop.4+0x46/0x5a
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff814468d9>] 
ip_rcv+0x239/0x264
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff81415df5>] 
__netif_receive_skb+0x4af/0x508
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff81415ed8>] 
process_backlog+0x8a/0x151
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff81417c0a>] 
net_rx_action+0xae/0x21c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff81062b2e>] 
__do_softirq+0x112/0x25a
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff8150df7c>] 
call_softirq+0x1c/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff81010bfd>] 
do_softirq+0x4b/0xa2
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff81062edd>] 
irq_exit+0x5d/0xcf
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff812daf6a>] 
xen_evtchn_do_upcall+0x31/0x3e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff8150dfce>] 
xen_do_hypervisor_callback+0x1e/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] 
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] other info that might help us 
debug this:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] 
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  Possible interrupt unsafe 
locking scenario:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] 
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]        CPU0                    
CPU1
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]        ----                    
----
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   lock(nf_conntrack_lock);
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]                                
local_irq_disable();
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]                                
lock(&(&bp->lock)->rlock);
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]                                
lock(nf_conntrack_lock);
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   <Interrupt>
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    
lock(&(&bp->lock)->rlock);
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] 
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  *** DEADLOCK ***
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] 
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] 2 locks held by swapper/0:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  #0: 
(&(&bp->lock)->rlock)
{-.-.-.}, at: [<ffffffffa0287a6a>] b44_poll+0x28/0x3ec [b44]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  #1:  (rcu_read_lock){.+.+..}, 
at: [<ffffffff8143c558>] rcu_read_lock+0x0/0x44
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] 
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] the dependencies between 
HARDIRQ-irq-safe lock and the holding lock:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] ->
(&(&bp->lock)->rlock)
{-.-.-.} ops: 27161 {
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    IN-HARDIRQ-W at:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8108e176>] __lock_acquire+0x2ce/0xd0c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8108f0b7>] lock_acquire+0xf3/0x13e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff815044fd>] _raw_spin_lock+0x45/0x79
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffffa0285725>] b44_interrupt+0x25/0xd9 [b44]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff810c2958>] handle_irq_event_percpu+0xb4/0x271
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff810c2b5c>] handle_irq_event+0x47/0x67
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff810c4ef0>] handle_fasteoi_irq+0x8a/0xb0
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff812d986f>] __xen_evtchn_do_upcall+0x15e/0x203
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff812daf65>] xen_evtchn_do_upcall+0x2c/0x3e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8150dfce>] xen_do_hypervisor_callback+0x1e/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    IN-SOFTIRQ-W at:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8108e19d>] __lock_acquire+0x2f5/0xd0c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8108f0b7>] lock_acquire+0xf3/0x13e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81504612>] _raw_spin_lock_irq+0x4f/0x82
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffffa02868a2>] b44_timer+0x13/0x51 [b44]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8106a83c>] run_timer_softirq+0x218/0x372
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81062b2e>] __do_softirq+0x112/0x25a
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8150df7c>] call_softirq+0x1c/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81010bfd>] do_softirq+0x4b/0xa2
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81062edd>] irq_exit+0x5d/0xcf
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff812daf6a>] xen_evtchn_do_upcall+0x31/0x3e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8150dfce>] xen_do_hypervisor_callback+0x1e/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    IN-RECLAIM_FS-W at:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8108e24a>] __lock_acquire+0x3a2/0xd0c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8108f0b7>] lock_acquire+0xf3/0x13e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff815044fd>] _raw_spin_lock+0x45/0x79
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffffa0285725>] b44_interrupt+0x25/0xd9 [b44]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff810c2958>] handle_irq_event_percpu+0xb4/0x271
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff810c2b5c>] handle_irq_event+0x47/0x67
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff810c4ef0>] handle_fasteoi_irq+0x8a/0xb0
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff812d986f>] __xen_evtchn_do_upcall+0x15e/0x203
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff812daf65>] xen_evtchn_do_upcall+0x2c/0x3e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8150dfce>] xen_do_hypervisor_callback+0x1e/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    INITIAL USE at:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8108e262>] __lock_acquire+0x3ba/0xd0c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8108f0b7>] lock_acquire+0xf3/0x13e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81504612>] _raw_spin_lock_irq+0x4f/0x82
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffffa0286637>] b44_set_mac_addr+0x5a/0x82 [b44]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8141488d>] dev_set_mac_address+0x3e/0x58
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffffa04a6985>] bond_enslave+0x3e6/0xa48 [bonding]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffffa04ad458>] bonding_store_slaves+0x106/0x174 [bonding]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff813138c4>] dev_attr_store+0x20/0x22
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff811a0d5d>] sysfs_write_file+0x108/0x144
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81142bda>] vfs_write+0xaf/0xf6
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81142dd5>] sys_write+0x4d/0x74
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8150bc82>] system_call_fastpath+0x16/0x1b
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  }
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  ... key      at: 
[<ffffffffa028b448>] __key.37034+0x0/0xffffffffffffdbb8 [b44]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  ... acquired at:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8108db7c>] 
check_irq_usage+0x42/0x88
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8108e8fa>] 
__lock_acquire+0xa52/0xd0c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8108f0b7>] 
lock_acquire+0xf3/0x13e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff81504846>] 
_raw_spin_lock_bh+0x4a/0x7e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffffa036a7b7>] 
destroy_conntrack+0x70/0xec [nf_conntrack]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8143c85c>] 
nf_conntrack_destroy+0x5a/0x64
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8140d88d>] 
skb_release_head_state+0xa7/0xef
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8140d530>] 
__kfree_skb+0x13/0x83
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8140d645>] 
consume_skb+0xa5/0xd1
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffffa0287af1>] 
b44_poll+0xaf/0x3ec [b44]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff81417c0a>] 
net_rx_action+0xae/0x21c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff81062b2e>] 
__do_softirq+0x112/0x25a
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8150df7c>] 
call_softirq+0x1c/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff81010bfd>] 
do_softirq+0x4b/0xa2
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff81062edd>] 
irq_exit+0x5d/0xcf
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff812daf6a>] 
xen_evtchn_do_upcall+0x31/0x3e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8150dfce>] 
xen_do_hypervisor_callback+0x1e/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] 
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] 
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] the dependencies between the 
lock to be acquired and HARDIRQ-irq-unsafe lock:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] ->
(nf_conntrack_lock){+.-...}
ops: 255 {
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    HARDIRQ-ON-W at:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8108e1ed>] __lock_acquire+0x345/0xd0c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8108f0b7>] lock_acquire+0xf3/0x13e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81504846>] _raw_spin_lock_bh+0x4a/0x7e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffffa036bf48>] nf_conntrack_in+0x461/0x7dc [nf_conntrack]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffffa03985ff>] ipv4_conntrack_in+0x21/0x23 [nf_conntrack_ipv4]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8143c97d>] nf_iterate+0x4c/0x8c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8143ca39>] nf_hook_slow+0x7c/0x123
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8144621f>] NF_HOOK.constprop.4+0x46/0x5a
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff814468d9>] ip_rcv+0x239/0x264
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81415df5>] __netif_receive_skb+0x4af/0x508
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81415ed8>] process_backlog+0x8a/0x151
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81417c0a>] net_rx_action+0xae/0x21c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81062b2e>] __do_softirq+0x112/0x25a
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8150df7c>] call_softirq+0x1c/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81010bfd>] do_softirq+0x4b/0xa2
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81062edd>] irq_exit+0x5d/0xcf
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff812daf6a>] xen_evtchn_do_upcall+0x31/0x3e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8150dfce>] xen_do_hypervisor_callback+0x1e/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    IN-SOFTIRQ-W at:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8108e19d>] __lock_acquire+0x2f5/0xd0c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8108f0b7>] lock_acquire+0xf3/0x13e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81504846>] _raw_spin_lock_bh+0x4a/0x7e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffffa036bf48>] nf_conntrack_in+0x461/0x7dc [nf_conntrack]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffffa03985ff>] ipv4_conntrack_in+0x21/0x23 [nf_conntrack_ipv4]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8143c97d>] nf_iterate+0x4c/0x8c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8143ca39>] nf_hook_slow+0x7c/0x123
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8144621f>] NF_HOOK.constprop.4+0x46/0x5a
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff814468d9>] ip_rcv+0x239/0x264
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81415df5>] __netif_receive_skb+0x4af/0x508
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81415ed8>] process_backlog+0x8a/0x151
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81417c0a>] net_rx_action+0xae/0x21c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81062b2e>] __do_softirq+0x112/0x25a
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8150df7c>] call_softirq+0x1c/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81010bfd>] do_softirq+0x4b/0xa2
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81062edd>] irq_exit+0x5d/0xcf
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff812daf6a>] xen_evtchn_do_upcall+0x31/0x3e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8150dfce>] xen_do_hypervisor_callback+0x1e/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    INITIAL USE at:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8108e262>] __lock_acquire+0x3ba/0xd0c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8108f0b7>] lock_acquire+0xf3/0x13e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81504846>] _raw_spin_lock_bh+0x4a/0x7e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffffa036bf48>] nf_conntrack_in+0x461/0x7dc [nf_conntrack]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffffa03985ff>] ipv4_conntrack_in+0x21/0x23 [nf_conntrack_ipv4]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8143c97d>] nf_iterate+0x4c/0x8c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8143ca39>] nf_hook_slow+0x7c/0x123
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8144621f>] NF_HOOK.constprop.4+0x46/0x5a
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff814468d9>] ip_rcv+0x239/0x264
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81415df5>] __netif_receive_skb+0x4af/0x508
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81415ed8>] process_backlog+0x8a/0x151
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81417c0a>] net_rx_action+0xae/0x21c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81062b2e>] __do_softirq+0x112/0x25a
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8150df7c>] call_softirq+0x1c/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81010bfd>] do_softirq+0x4b/0xa2
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81062edd>] irq_exit+0x5d/0xcf
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff812daf6a>] xen_evtchn_do_upcall+0x31/0x3e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8150dfce>] xen_do_hypervisor_callback+0x1e/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  }
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  ... key      at: 
[<ffffffffa0376018>] nf_conntrack_lock+0x18/0xffffffffffffd000
[nf_conntrack]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  ... acquired at:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8108db7c>] 
check_irq_usage+0x42/0x88
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8108e8fa>] 
__lock_acquire+0xa52/0xd0c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8108f0b7>] 
lock_acquire+0xf3/0x13e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff81504846>] 
_raw_spin_lock_bh+0x4a/0x7e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffffa036a7b7>] 
destroy_conntrack+0x70/0xec [nf_conntrack]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8143c85c>] 
nf_conntrack_destroy+0x5a/0x64
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8140d88d>] 
skb_release_head_state+0xa7/0xef
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8140d530>] 
__kfree_skb+0x13/0x83
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8140d645>] 
consume_skb+0xa5/0xd1
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffffa0287af1>] 
b44_poll+0xaf/0x3ec [b44]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff81417c0a>] 
net_rx_action+0xae/0x21c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff81062b2e>] 
__do_softirq+0x112/0x25a
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8150df7c>] 
call_softirq+0x1c/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff81010bfd>] 
do_softirq+0x4b/0xa2
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff81062edd>] 
irq_exit+0x5d/0xcf
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff812daf6a>] 
xen_evtchn_do_upcall+0x31/0x3e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8150dfce>] 
xen_do_hypervisor_callback+0x1e/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] 
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] 
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] stack backtrace:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] Pid: 0, comm: swapper Not 
tainted 3.1.0-0.rc6.git0.0.xendom0.fc17.x86_64 #1
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] Call Trace:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  <IRQ> 
[<ffffffff8108db25>]
check_usage+0x37f/0x394
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81007d72>] ? 
check_events+0x12/0x20
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff8108db7c>] 
check_irq_usage+0x42/0x88
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff8108e8fa>] 
__lock_acquire+0xa52/0xd0c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffffa036a45d>] ? 
rcu_read_lock+0x44/0x44 [nf_conntrack]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81007746>] ? 
xen_force_evtchn_callback+0xd/0xf
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81007d72>] ? 
check_events+0x12/0x20
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81007746>] ? 
xen_force_evtchn_callback+0xd/0xf
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffffa036a7b7>] ? 
destroy_conntrack+0x70/0xec [nf_conntrack]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff8108f0b7>] 
lock_acquire+0xf3/0x13e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffffa036a7b7>] ? 
destroy_conntrack+0x70/0xec [nf_conntrack]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81007d5f>] ? 
xen_restore_fl_direct_reloc+0x4/0x4
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81504846>] 
_raw_spin_lock_bh+0x4a/0x7e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff812daf6a>] xen_evtchn_do_upcall+0x31/0x3e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8150dfce>] xen_do_hypervisor_callback+0x1e/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    INITIAL USE at:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8108e262>] __lock_acquire+0x3ba/0xd0c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8108f0b7>] lock_acquire+0xf3/0x13e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81504846>] _raw_spin_lock_bh+0x4a/0x7e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffffa036bf48>] nf_conntrack_in+0x461/0x7dc [nf_conntrack]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffffa03985ff>] ipv4_conntrack_in+0x21/0x23 [nf_conntrack_ipv4]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8143c97d>] nf_iterate+0x4c/0x8c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8143ca39>] nf_hook_slow+0x7c/0x123
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8144621f>] NF_HOOK.constprop.4+0x46/0x5a
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff814468d9>] ip_rcv+0x239/0x264
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81415df5>] __netif_receive_skb+0x4af/0x508
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81415ed8>] process_backlog+0x8a/0x151
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81417c0a>] net_rx_action+0xae/0x21c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81062b2e>] __do_softirq+0x112/0x25a
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8150df7c>] call_softirq+0x1c/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81010bfd>] do_softirq+0x4b/0xa2
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81062edd>] irq_exit+0x5d/0xcf
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff812daf6a>] xen_evtchn_do_upcall+0x31/0x3e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8150dfce>] xen_do_hypervisor_callback+0x1e/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  }
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  ... key      at: 
[<ffffffffa0376018>] nf_conntrack_lock+0x18/0xffffffffffffd000
[nf_conntrack]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  ... acquired at:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8108db7c>] 
check_irq_usage+0x42/0x88
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8108e8fa>] 
__lock_acquire+0xa52/0xd0c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8108f0b7>] 
lock_acquire+0xf3/0x13e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff81504846>] 
_raw_spin_lock_bh+0x4a/0x7e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffffa036a7b7>] 
destroy_conntrack+0x70/0xec [nf_conntrack]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8143c85c>] 
nf_conntrack_destroy+0x5a/0x64
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8140d88d>] 
skb_release_head_state+0xa7/0xef
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8140d530>] 
__kfree_skb+0x13/0x83
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8140d645>] 
consume_skb+0xa5/0xd1
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffffa0287af1>] 
b44_poll+0xaf/0x3ec [b44]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff81417c0a>] 
net_rx_action+0xae/0x21c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff81062b2e>] 
__do_softirq+0x112/0x25a
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8150df7c>] 
call_softirq+0x1c/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff81010bfd>] 
do_softirq+0x4b/0xa2
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff81062edd>] 
irq_exit+0x5d/0xcf
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff812daf6a>] 
xen_evtchn_do_upcall+0x31/0x3e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8150dfce>] 
xen_do_hypervisor_callback+0x1e/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] 
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] 
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] stack backtrace:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] Pid: 0, comm: swapper Not 
tainted 3.1.0-0.rc6.git0.0.xendom0.fc17.x86_64 #1
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] Call Trace:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  <IRQ> 
[<ffffffff8108db25>]
check_usage+0x37f/0x394
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81007d72>] ? 
check_events+0x12/0x20
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff8108db7c>] 
check_irq_usage+0x42/0x88
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff8108e8fa>] 
__lock_acquire+0xa52/0xd0c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffffa036a45d>] ? 
rcu_read_lock+0x44/0x44 [nf_conntrack]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81007746>] ? 
xen_force_evtchn_callback+0xd/0xf
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81007d72>] ? 
check_events+0x12/0x20
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81007746>] ? 
xen_force_evtchn_callback+0xd/0xf
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffffa036a7b7>] ? 
destroy_conntrack+0x70/0xec [nf_conntrack]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff8108f0b7>] 
lock_acquire+0xf3/0x13e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffffa036a7b7>] ? 
destroy_conntrack+0x70/0xec [nf_conntrack]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81007d5f>] ? 
xen_restore_fl_direct_reloc+0x4/0x4
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81504846>] 
_raw_spin_lock_bh+0x4a/0x7e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffffa036a7b7>] ? 
destroy_conntrack+0x70/0xec [nf_conntrack]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffffa036a7b7>] 
destroy_conntrack+0x70/0xec [nf_conntrack]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffffa036a747>] ? 
nf_conntrack_free+0x58/0x58 [nf_conntrack]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff8143c85c>] 
nf_conntrack_destroy+0x5a/0x64
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff8140d88d>] 
skb_release_head_state+0xa7/0xef
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff8140d530>] 
__kfree_skb+0x13/0x83
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff8140d645>] 
consume_skb+0xa5/0xd1
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffffa0287af1>] 
b44_poll+0xaf/0x3ec [b44]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81417c0a>] 
net_rx_action+0xae/0x21c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81062a9a>] ? 
__do_softirq+0x7e/0x25a
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81062b2e>] 
__do_softirq+0x112/0x25a
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff8150df7c>] 
call_softirq+0x1c/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81010bfd>] 
do_softirq+0x4b/0xa2
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81062edd>] 
irq_exit+0x5d/0xcf
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff812daf6a>] 
xen_evtchn_do_upcall+0x31/0x3e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff8150dfce>] 
xen_do_hypervisor_callback+0x1e/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  <EOI> 
[<ffffffff810013aa>] ?
hypercall_page+0x3aa/0x1000
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff810013aa>] ? 
hypercall_page+0x3aa/0x1000
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81007701>] ? 
xen_safe_halt+0x10/0x18
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff8101601e>] ? 
default_idle+0x53/0x90
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff8100e2f9>] ? 
cpu_idle+0xb5/0x101
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff814e0318>] ? 
rest_init+0xdc/0xe3
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff814e023c>] ? 
csum_partial_copy_generic+0x16c/0x16c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81d53b9f>] ? 
start_kernel+0x3dd/0x3ea
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81d532c4>] ? 
x86_64_start_reservations+0xaf/0xb3
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81d55f18>] ? 
xen_start_kernel+0x588/0x58f
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] ------------[ cut here 
]------------
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] WARNING: at 
kernel/softirq.c:159 _local_bh_enable_ip+0x49/0xce()
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] Hardware name: MM061
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] Modules linked in: fuse 
ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat xt_CHECKSUM 
iptable_mangle xen_pciback nfsd lockd nfs_acl auth_rpcgss sunrpc des_generic 
md4 nls_utf8 cifs fscache bridge stp llc bonding be2iscsi iscsi_boot_sysfs 
bnx2i cnic uio cxgb3i libcxgbi iw_cxgb3 cxgb3 mdio ib_iser rdma_cm ib_cm iw_cm 
xt_comment ib_sa ib_mad ib_core ip6t_REJECT ib_addr nf_conntrack_ipv4 
nf_defrag_ipv4 nf_conntrack_ipv6 nf_defrag_ipv6 iscsi_tcp xt_state 
libiscsi_tcp nf_conntrack libiscsi ip6table_filter ipt_LOG 
scsi_transport_iscsi ip6_tables xt_physdev dell_wmi sparse_keymap 
snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device 
arc4 r852 sm_common nand snd_pcm dell_laptop microcode dcdbas b44 nand_ids 
r592 nand_ecc iwl3945 ssb memstick mtd mii iwl_legacy iTCO_wdt mac80211 
iTCO_vendor_support i2c_i801 joydev cfg80211 snd_timer rfkill snd soundcore 
snd_page_alloc tun xen_gntalloc xen_netback xen_blkback xen_gntdev xen_evtchn 
xenfs binfmt_misc
Sep 16 01:10:19 Insp6400 kernel: sdhci_pci sdhci mmc_core firewire_ohci 
firewire_core crc_itu_t wmi i915 drm_kms_helper drm i2c_algo_bit i2c_core 
video [last unloaded: scsi_wait_scan]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] Pid: 0, comm: swapper Not 
tainted 3.1.0-0.rc6.git0.0.xendom0.fc17.x86_64 #1
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] Call Trace:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  <IRQ> 
[<ffffffff8105c4a0>]
warn_slowpath_common+0x83/0x9b
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffffa036a7f4>] ? 
destroy_conntrack+0xad/0xec [nf_conntrack]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff8105c4d2>] 
warn_slowpath_null+0x1a/0x1c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81062598>] 
_local_bh_enable_ip+0x49/0xce
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff8106262b>] 
local_bh_enable_ip+0xe/0x10
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81504df9>] 
_raw_spin_unlock_bh+0x40/0x44
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffffa036a7f4>] 
destroy_conntrack+0xad/0xec [nf_conntrack]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffffa036a747>] ? 
nf_conntrack_free+0x58/0x58 [nf_conntrack]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff8143c85c>] 
nf_conntrack_destroy+0x5a/0x64
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff8140d88d>] 
skb_release_head_state+0xa7/0xef
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff8140d530>] 
__kfree_skb+0x13/0x83
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff8140d645>] 
consume_skb+0xa5/0xd1
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffffa0287af1>] 
b44_poll+0xaf/0x3ec [b44]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81417c0a>] 
net_rx_action+0xae/0x21c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81062a9a>] ? 
__do_softirq+0x7e/0x25a
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81062b2e>] 
__do_softirq+0x112/0x25a
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff8150df7c>] 
call_softirq+0x1c/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81010bfd>] 
do_softirq+0x4b/0xa2
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81062edd>] 
irq_exit+0x5d/0xcf
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff812daf6a>] 
xen_evtchn_do_upcall+0x31/0x3e
Sep 16 01:10:19 Insp6400 kernel: [  473.537933] 
Sep 16 01:10:19 Insp6400 kernel: [  473.537933] 
=====================================================Sep 16 01:10:19 Insp6400
kernel: [  473.537933] [ INFO: HARDIRQ-safe ->
HARDIRQ-unsafe lock order detected ]
Sep 16 01:10:19 Insp6400 kernel: [  473.537933] 
3.1.0-0.rc6.git0.0.xendom0.fc17.x86_64 #1
Sep 16 01:10:19 Insp6400 kernel: [  473.537933] 
------------------------------------------------------
Sep 16 01:10:19 Insp6400 kernel: [  473.537933] swapper/0 
[HC0[0]:SC1[3]:HE0:SE0] is trying to acquire:
Sep 16 01:10:19 Insp6400 kernel: [  473.537933]  (nf_conntrack_lock){+.-...}, 
at: [<ffffffffa036a7b7>] destroy_conntrack+0x70/0xec [nf_conntrack]
Sep 16 01:10:19 Insp6400 kernel: [  473.537933] 
Sep 16 01:10:19 Insp6400 kernel: [  473.537933] and this task is already 
holding:
Sep 16 01:10:19 Insp6400 kernel: [  473.537933] 
(&(&bp->lock)->rlock)
{-.-.-.}, at: [<ffffffffa0287a6a>] b44_poll+0x28/0x3ec [b44]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] which would create a new lock 
dependency:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] 
(&(&bp->lock)->rlock){-.-.-.}
-> (nf_conntrack_lock){+.-...}
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] 
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] but this new dependency 
connects a HARDIRQ-irq-safe lock:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] 
(&(&bp->lock)->rlock){-.-.-.}
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] ... which became HARDIRQ-irq-
safe at:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff8108e176>] 
__lock_acquire+0x2ce/0xd0c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff8108f0b7>] 
lock_acquire+0xf3/0x13e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff815044fd>] 
_raw_spin_lock+0x45/0x79
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffffa0285725>] 
b44_interrupt+0x25/0xd9 [b44]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff810c2958>] 
handle_irq_event_percpu+0xb4/0x271
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff810c2b5c>] 
handle_irq_event+0x47/0x67
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff810c4ef0>] 
handle_fasteoi_irq+0x8a/0xb0
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff812d986f>] 
__xen_evtchn_do_upcall+0x15e/0x203
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff812daf65>] 
xen_evtchn_do_upcall+0x2c/0x3e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff8150dfce>] 
xen_do_hypervisor_callback+0x1e/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] 
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] to a HARDIRQ-irq-unsafe lock:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  (nf_conntrack_lock){+.-...}
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] ... which became HARDIRQ-irq-
unsafe at:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] ...  [<ffffffff8108e1ed>] 
__lock_acquire+0x345/0xd0c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff8108f0b7>] 
lock_acquire+0xf3/0x13e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff81504846>] 
_raw_spin_lock_bh+0x4a/0x7e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffffa036bf48>] 
nf_conntrack_in+0x461/0x7dc [nf_conntrack]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffffa03985ff>] 
ipv4_conntrack_in+0x21/0x23 [nf_conntrack_ipv4]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff8143c97d>] 
nf_iterate+0x4c/0x8c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff8143ca39>] 
nf_hook_slow+0x7c/0x123
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff8144621f>] 
NF_HOOK.constprop.4+0x46/0x5a
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff814468d9>] 
ip_rcv+0x239/0x264
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff81415df5>] 
__netif_receive_skb+0x4af/0x508
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff81415ed8>] 
process_backlog+0x8a/0x151
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff81417c0a>] 
net_rx_action+0xae/0x21c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff81062b2e>] 
__do_softirq+0x112/0x25a
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff8150df7c>] 
call_softirq+0x1c/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff81010bfd>] 
do_softirq+0x4b/0xa2
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff81062edd>] 
irq_exit+0x5d/0xcf
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff812daf6a>] 
xen_evtchn_do_upcall+0x31/0x3e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   [<ffffffff8150dfce>] 
xen_do_hypervisor_callback+0x1e/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] 
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] other info that might help us 
debug this:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] 
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  Possible interrupt unsafe 
locking scenario:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] 
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]        CPU0                    
CPU1
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]        ----                    
----
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   lock(nf_conntrack_lock);
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]                                
local_irq_disable();
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]                                
lock(&(&bp->lock)->rlock);
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]                                
lock(nf_conntrack_lock);
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]   <Interrupt>
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    
lock(&(&bp->lock)->rlock);
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] 
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  *** DEADLOCK ***
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] 
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] 2 locks held by swapper/0:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  #0: 
(&(&bp->lock)->rlock)
{-.-.-.}, at: [<ffffffffa0287a6a>] b44_poll+0x28/0x3ec [b44]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  #1:  (rcu_read_lock){.+.+..}, 
at: [<ffffffff8143c558>] rcu_read_lock+0x0/0x44
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] 
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] the dependencies between 
HARDIRQ-irq-safe lock and the holding lock:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] ->
(&(&bp->lock)->rlock)
{-.-.-.} ops: 27161 {
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    IN-HARDIRQ-W at:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8108e176>] __lock_acquire+0x2ce/0xd0c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8108f0b7>] lock_acquire+0xf3/0x13e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff815044fd>] _raw_spin_lock+0x45/0x79
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffffa0285725>] b44_interrupt+0x25/0xd9 [b44]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff810c2958>] handle_irq_event_percpu+0xb4/0x271
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff810c2b5c>] handle_irq_event+0x47/0x67
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff810c4ef0>] handle_fasteoi_irq+0x8a/0xb0
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff812d986f>] __xen_evtchn_do_upcall+0x15e/0x203
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff812daf65>] xen_evtchn_do_upcall+0x2c/0x3e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8150dfce>] xen_do_hypervisor_callback+0x1e/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    IN-SOFTIRQ-W at:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8108e19d>] __lock_acquire+0x2f5/0xd0c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8108f0b7>] lock_acquire+0xf3/0x13e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81504612>] _raw_spin_lock_irq+0x4f/0x82
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffffa02868a2>] b44_timer+0x13/0x51 [b44]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8106a83c>] run_timer_softirq+0x218/0x372
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81062b2e>] __do_softirq+0x112/0x25a
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8150df7c>] call_softirq+0x1c/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81010bfd>] do_softirq+0x4b/0xa2
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81062edd>] irq_exit+0x5d/0xcf
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff812daf6a>] xen_evtchn_do_upcall+0x31/0x3e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8150dfce>] xen_do_hypervisor_callback+0x1e/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    IN-RECLAIM_FS-W at:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8108e24a>] __lock_acquire+0x3a2/0xd0c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8108f0b7>] lock_acquire+0xf3/0x13e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff815044fd>] _raw_spin_lock+0x45/0x79
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffffa0285725>] b44_interrupt+0x25/0xd9 [b44]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff810c2958>] handle_irq_event_percpu+0xb4/0x271
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff810c2b5c>] handle_irq_event+0x47/0x67
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff810c4ef0>] handle_fasteoi_irq+0x8a/0xb0
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff812d986f>] __xen_evtchn_do_upcall+0x15e/0x203
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff812daf65>] xen_evtchn_do_upcall+0x2c/0x3e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8150dfce>] xen_do_hypervisor_callback+0x1e/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    INITIAL USE at:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8108e262>] __lock_acquire+0x3ba/0xd0c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8108f0b7>] lock_acquire+0xf3/0x13e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81504612>] _raw_spin_lock_irq+0x4f/0x82
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffffa0286637>] b44_set_mac_addr+0x5a/0x82 [b44]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8141488d>] dev_set_mac_address+0x3e/0x58
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffffa04a6985>] bond_enslave+0x3e6/0xa48 [bonding]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffffa04ad458>] bonding_store_slaves+0x106/0x174 [bonding]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff813138c4>] dev_attr_store+0x20/0x22
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff811a0d5d>] sysfs_write_file+0x108/0x144
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81142bda>] vfs_write+0xaf/0xf6
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81142dd5>] sys_write+0x4d/0x74
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8150bc82>] system_call_fastpath+0x16/0x1b
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  }
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  ... key      at: 
[<ffffffffa028b448>] __key.37034+0x0/0xffffffffffffdbb8 [b44]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  ... acquired at:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8108db7c>] 
check_irq_usage+0x42/0x88
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8108e8fa>] 
__lock_acquire+0xa52/0xd0c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8108f0b7>] 
lock_acquire+0xf3/0x13e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff81504846>] 
_raw_spin_lock_bh+0x4a/0x7e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffffa036a7b7>] 
destroy_conntrack+0x70/0xec [nf_conntrack]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8143c85c>] 
nf_conntrack_destroy+0x5a/0x64
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8140d88d>] 
skb_release_head_state+0xa7/0xef
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8140d530>] 
__kfree_skb+0x13/0x83
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8140d645>] 
consume_skb+0xa5/0xd1
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffffa0287af1>] 
b44_poll+0xaf/0x3ec [b44]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff81417c0a>] 
net_rx_action+0xae/0x21c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff81062b2e>] 
__do_softirq+0x112/0x25a
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8150df7c>] 
call_softirq+0x1c/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff81010bfd>] 
do_softirq+0x4b/0xa2
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff81062edd>] 
irq_exit+0x5d/0xcf
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff812daf6a>] 
xen_evtchn_do_upcall+0x31/0x3e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8150dfce>] 
xen_do_hypervisor_callback+0x1e/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] 
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] 
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] the dependencies between the 
lock to be acquired and HARDIRQ-irq-unsafe lock:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] ->
(nf_conntrack_lock){+.-...}
ops: 255 {
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    HARDIRQ-ON-W at:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8108e1ed>] __lock_acquire+0x345/0xd0c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8108f0b7>] lock_acquire+0xf3/0x13e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81504846>] _raw_spin_lock_bh+0x4a/0x7e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffffa036bf48>] nf_conntrack_in+0x461/0x7dc [nf_conntrack]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffffa03985ff>] ipv4_conntrack_in+0x21/0x23 [nf_conntrack_ipv4]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8143c97d>] nf_iterate+0x4c/0x8c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8143ca39>] nf_hook_slow+0x7c/0x123
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8144621f>] NF_HOOK.constprop.4+0x46/0x5a
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff814468d9>] ip_rcv+0x239/0x264
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81415df5>] __netif_receive_skb+0x4af/0x508
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81415ed8>] process_backlog+0x8a/0x151
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81417c0a>] net_rx_action+0xae/0x21c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81062b2e>] __do_softirq+0x112/0x25a
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8150df7c>] call_softirq+0x1c/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81010bfd>] do_softirq+0x4b/0xa2
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81062edd>] irq_exit+0x5d/0xcf
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff812daf6a>] xen_evtchn_do_upcall+0x31/0x3e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8150dfce>] xen_do_hypervisor_callback+0x1e/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    IN-SOFTIRQ-W at:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8108e19d>] __lock_acquire+0x2f5/0xd0c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8108f0b7>] lock_acquire+0xf3/0x13e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81504846>] _raw_spin_lock_bh+0x4a/0x7e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffffa036bf48>] nf_conntrack_in+0x461/0x7dc [nf_conntrack]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffffa03985ff>] ipv4_conntrack_in+0x21/0x23 [nf_conntrack_ipv4]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8143c97d>] nf_iterate+0x4c/0x8c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8143ca39>] nf_hook_slow+0x7c/0x123
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8144621f>] NF_HOOK.constprop.4+0x46/0x5a
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff814468d9>] ip_rcv+0x239/0x264
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81415df5>] __netif_receive_skb+0x4af/0x508
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81415ed8>] process_backlog+0x8a/0x151
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81417c0a>] net_rx_action+0xae/0x21c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81062b2e>] __do_softirq+0x112/0x25a
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8150df7c>] call_softirq+0x1c/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81010bfd>] do_softirq+0x4b/0xa2
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81062edd>] irq_exit+0x5d/0xcf
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff812daf6a>] xen_evtchn_do_upcall+0x31/0x3e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8150dfce>] xen_do_hypervisor_callback+0x1e/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    INITIAL USE at:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8108e262>] __lock_acquire+0x3ba/0xd0c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8108f0b7>] lock_acquire+0xf3/0x13e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81504846>] _raw_spin_lock_bh+0x4a/0x7e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffffa036bf48>] nf_conntrack_in+0x461/0x7dc [nf_conntrack]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffffa03985ff>] ipv4_conntrack_in+0x21/0x23 [nf_conntrack_ipv4]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8143c97d>] nf_iterate+0x4c/0x8c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8143ca39>] nf_hook_slow+0x7c/0x123
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8144621f>] NF_HOOK.constprop.4+0x46/0x5a
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff814468d9>] ip_rcv+0x239/0x264
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81415df5>] __netif_receive_skb+0x4af/0x508
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81415ed8>] process_backlog+0x8a/0x151
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81417c0a>] net_rx_action+0xae/0x21c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81062b2e>] __do_softirq+0x112/0x25a
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8150df7c>] call_softirq+0x1c/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81010bfd>] do_softirq+0x4b/0xa2
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff81062edd>] irq_exit+0x5d/0xcf
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff812daf6a>] xen_evtchn_do_upcall+0x31/0x3e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]
[<ffffffff8150dfce>] xen_do_hypervisor_callback+0x1e/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  }
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  ... key      at: 
[<ffffffffa0376018>] nf_conntrack_lock+0x18/0xffffffffffffd000
[nf_conntrack]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  ... acquired at:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8108db7c>] 
check_irq_usage+0x42/0x88
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8108e8fa>] 
__lock_acquire+0xa52/0xd0c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8108f0b7>] 
lock_acquire+0xf3/0x13e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff81504846>] 
_raw_spin_lock_bh+0x4a/0x7e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffffa036a7b7>] 
destroy_conntrack+0x70/0xec [nf_conntrack]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8143c85c>] 
nf_conntrack_destroy+0x5a/0x64
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8140d88d>] 
skb_release_head_state+0xa7/0xef
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8140d530>] 
__kfree_skb+0x13/0x83
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8140d645>] 
consume_skb+0xa5/0xd1
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffffa0287af1>] 
b44_poll+0xaf/0x3ec [b44]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff81417c0a>] 
net_rx_action+0xae/0x21c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff81062b2e>] 
__do_softirq+0x112/0x25a
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8150df7c>] 
call_softirq+0x1c/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff81010bfd>] 
do_softirq+0x4b/0xa2
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff81062edd>] 
irq_exit+0x5d/0xcf
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff812daf6a>] 
xen_evtchn_do_upcall+0x31/0x3e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]    [<ffffffff8150dfce>] 
xen_do_hypervisor_callback+0x1e/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] 
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] 
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] stack backtrace:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] Pid: 0, comm: swapper Not 
tainted 3.1.0-0.rc6.git0.0.xendom0.fc17.x86_64 #1
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] Call Trace:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  <IRQ> 
[<ffffffff8108db25>]
check_usage+0x37f/0x394
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81007d72>] ? 
check_events+0x12/0x20
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff8108db7c>] 
check_irq_usage+0x42/0x88
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff8108e8fa>] 
__lock_acquire+0xa52/0xd0c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffffa036a45d>] ? 
rcu_read_lock+0x44/0x44 [nf_conntrack]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81007746>] ? 
xen_force_evtchn_callback+0xd/0xf
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81007d72>] ? 
check_events+0x12/0x20
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81007746>] ? 
xen_force_evtchn_callback+0xd/0xf
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffffa036a7b7>] ? 
destroy_conntrack+0x70/0xec [nf_conntrack]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff8108f0b7>] 
lock_acquire+0xf3/0x13e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffffa036a7b7>] ? 
destroy_conntrack+0x70/0xec [nf_conntrack]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81007d5f>] ? 
xen_restore_fl_direct_reloc+0x4/0x4
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81504846>] 
_raw_spin_lock_bh+0x4a/0x7e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffffa036a7b7>] ? 
destroy_conntrack+0x70/0xec [nf_conntrack]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffffa036a7b7>] 
destroy_conntrack+0x70/0xec [nf_conntrack]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffffa036a747>] ? 
nf_conntrack_free+0x58/0x58 [nf_conntrack]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff8143c85c>] 
nf_conntrack_destroy+0x5a/0x64
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff8140d88d>] 
skb_release_head_state+0xa7/0xef
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff8140d530>] 
__kfree_skb+0x13/0x83
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff8140d645>] 
consume_skb+0xa5/0xd1
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffffa0287af1>] 
b44_poll+0xaf/0x3ec [b44]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81417c0a>] 
net_rx_action+0xae/0x21c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81062a9a>] ? 
__do_softirq+0x7e/0x25a
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81062b2e>] 
__do_softirq+0x112/0x25a
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff8150df7c>] 
call_softirq+0x1c/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81010bfd>] 
do_softirq+0x4b/0xa2
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81062edd>] 
irq_exit+0x5d/0xcf
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff812daf6a>] 
xen_evtchn_do_upcall+0x31/0x3e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff8150dfce>] 
xen_do_hypervisor_callback+0x1e/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  <EOI> 
[<ffffffff810013aa>] ?
hypercall_page+0x3aa/0x1000
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff810013aa>] ? 
hypercall_page+0x3aa/0x1000
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81007701>] ? 
xen_safe_halt+0x10/0x18
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff8101601e>] ? 
default_idle+0x53/0x90
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff8100e2f9>] ? 
cpu_idle+0xb5/0x101
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff814e0318>] ? 
rest_init+0xdc/0xe3
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff814e023c>] ? 
csum_partial_copy_generic+0x16c/0x16c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81d53b9f>] ? 
start_kernel+0x3dd/0x3ea
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81d532c4>] ? 
x86_64_start_reservations+0xaf/0xb3
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81d55f18>] ? 
xen_start_kernel+0x588/0x58f
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] ------------[ cut here 
]------------
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] WARNING: at 
kernel/softirq.c:159 _local_bh_enable_ip+0x49/0xce()
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] Hardware name: MM061
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] Modules linked in: fuse 
ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat xt_CHECKSUM 
iptable_mangle xen_pciback nfsd lockd nfs_acl auth_rpcgss sunrpc des_generic 
md4 nls_utf8 cifs fscache bridge stp llc bonding be2iscsi iscsi_boot_sysfs 
bnx2i cnic uio cxgb3i libcxgbi iw_cxgb3 cxgb3 mdio ib_iser rdma_cm ib_cm iw_cm 
xt_comment ib_sa ib_mad ib_core ip6t_REJECT ib_addr nf_conntrack_ipv4 
nf_defrag_ipv4 nf_conntrack_ipv6 nf_defrag_ipv6 iscsi_tcp xt_state 
libiscsi_tcp nf_conntrack libiscsi ip6table_filter ipt_LOG 
scsi_transport_iscsi ip6_tables xt_physdev dell_wmi sparse_keymap 
snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device 
arc4 r852 sm_common nand snd_pcm dell_laptop microcode dcdbas b44 nand_ids 
r592 nand_ecc iwl3945 ssb memstick mtd mii iwl_legacy iTCO_wdt mac80211 
iTCO_vendor_support i2c_i801 joydev cfg80211 snd_timer rfkill snd soundcore 
snd_page_alloc tun xen_gntalloc xen_netback xen_blkback xen_gntdev xen_evtchn 
xenfs binfmt_misc
Sep 16 01:10:19 Insp6400 kernel: sdhci_pci sdhci mmc_core firewire_ohci 
firewire_core crc_itu_t wmi i915 drm_kms_helper drm i2c_algo_bit i2c_core 
video [last unloaded: scsi_wait_scan]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] Pid: 0, comm: swapper Not 
tainted 3.1.0-0.rc6.git0.0.xendom0.fc17.x86_64 #1
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] Call Trace:
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  <IRQ> 
[<ffffffff8105c4a0>]
warn_slowpath_common+0x83/0x9b
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffffa036a7f4>] ? 
destroy_conntrack+0xad/0xec [nf_conntrack]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff8105c4d2>] 
warn_slowpath_null+0x1a/0x1c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81062598>] 
_local_bh_enable_ip+0x49/0xce
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff8106262b>] 
local_bh_enable_ip+0xe/0x10
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81504df9>] 
_raw_spin_unlock_bh+0x40/0x44
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffffa036a7f4>] 
destroy_conntrack+0xad/0xec [nf_conntrack]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffffa036a747>] ? 
nf_conntrack_free+0x58/0x58 [nf_conntrack]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff8143c85c>] 
nf_conntrack_destroy+0x5a/0x64
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff8140d88d>] 
skb_release_head_state+0xa7/0xef
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff8140d530>] 
__kfree_skb+0x13/0x83
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff8140d645>] 
consume_skb+0xa5/0xd1
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffffa0287af1>] 
b44_poll+0xaf/0x3ec [b44]
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81417c0a>] 
net_rx_action+0xae/0x21c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81062a9a>] ? 
__do_softirq+0x7e/0x25a
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81062b2e>] 
__do_softirq+0x112/0x25a
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff8150df7c>] 
call_softirq+0x1c/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81010bfd>] 
do_softirq+0x4b/0xa2
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81062edd>] 
irq_exit+0x5d/0xcf
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff812daf6a>] 
xen_evtchn_do_upcall+0x31/0x3e
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff8150dfce>] 
xen_do_hypervisor_callback+0x1e/0x30
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  <EOI> 
[<ffffffff810013aa>] ?
hypercall_page+0x3aa/0x1000
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff810013aa>] ? 
hypercall_page+0x3aa/0x1000
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81007701>] ? 
xen_safe_halt+0x10/0x18
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff8101601e>] ? 
default_idle+0x53/0x90
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff8100e2f9>] ? 
cpu_idle+0xb5/0x101
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff814e0318>] ? 
rest_init+0xdc/0xe3
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff814e023c>] ? 
csum_partial_copy_generic+0x16c/0x16c
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81d53b9f>] ? 
start_kernel+0x3dd/0x3ea
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81d532c4>] ? 
x86_64_start_reservations+0xaf/0xb3
Sep 16 01:10:19 Insp6400 kernel: [  473.541175]  [<ffffffff81d55f18>] ? 
xen_start_kernel+0x588/0x58f
Sep 16 01:10:19 Insp6400 kernel: [  473.541175] ---[ end trace 
dfe23b483fd11a0c ]---

 

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

Konrad Rzeszutek Wilk

2011-Sep-16 17:38 UTC

head link

Re: [Fedora-xen] [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

> Testing out myoung''s 3.1.0 was not as straight forward as I had
hoped. It did
> boot up without any BUG:s, but I did get the occasional Lock Order message.
> Log snippet at the end of the post. It doesn''t seem to be directly
related to
> starting guests.
Yeah, those look like the network card (b44 driver) is at
fault.> 
> The real problem comes in starting up guests. Performance is very bad. I
knew
> from working with rawhide 3.0.0 (long since replaced) that performance
would
> suffer - rawhide kernels are debug kernels:
Right. They are horrendously slow.
> 
> jimb@insp6400 09/16/11 10:16AM:~
> [511] > grep DEBUG
/boot/config-3.1.0-0.rc6.git0.0.xendom0.fc17.x86_64|grep -v
> ''is not set''|wc -l
> 91
> jimb@insp6400 09/16/11 10:16AM:~
> [512] > grep DEBUG /boot/config-2.6.40.4-5.fc15.x86_64|grep -v
''is not set''|wc
> -l           
> 54
> jimb@insp6400 09/16/11 10:18AM:~
> [513] > grep DEBUG /boot/config-3.0.1-3.fc16.x86_64|grep -v ''is
not set''|wc -l
> 90
> 
> Starting guests is much slower under myoung''s 3.1.0 than under
rawhide''s 3.1.0
> or 3.0.{0,1}. A cifs backed pv domu took 6 min. for ''xm
create'' to exit,
a debug kernel which will indeed be quite slow.
> root@insp6400 09/16/11 12:09AM:~
> [544] > xl create Documents/winxp; brctl show;  ps -A|grep qemu; netstat
-tlp|
> grep 59; renice -11 `pidof qemu-dm`;  ps -A|grep vncv; ifconfig vif1.0 mtu 
> 9000
> Parsing config file Documents/winxp
> xc: info: VIRTUAL MEMORY ARRANGEMENT:
>   Loader:        0000000000100000->000000000017b270
>   TOTAL:         0000000000000000->000000003fc00000
>   ENTRY ADDRESS: 00000000001015a0
> xc: error: Could not allocate memory for HVM guest. (16 = Device or
resource
> busy): Internal error
> libxl: error: libxl_dom.c:284:libxl__build_hvm hvm building failed
How much memory do you have used for your dom0/domU?> 
> and my serial debug log had several:
> 
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (1
of
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0
of
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0
of
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0
of
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0
of
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0
of
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0
of
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0
of
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0
of
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0
of
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0
of
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0
of
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0
of
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0
of
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0
of
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0
of
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0
of
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0
of
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0
of
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0
of
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0
of
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0
of
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0
of
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1 memflags=0 (0
of
> 4)
> (XEN) memory.c:133:d0 Could not allocate order=0 extent: id=1 memflags=0
(439
> of 2048)
> 
> Then I remembered that I recently upped the memory allocation for my winxp 
> domu, from 512 to 768. This works fine under 2.6.40, the f15 non-debug 
> production kernel. None the less, I knocked the allocation back down to
512,
> and my winxp domu did start up, getting to the qemu splash screen in about
2 -
> 3 min., during part of which dom0 was unresponsive. However, I''m
still getting
> the ''(XEN) memory.c'' errors, and some frequent GPF errors
(a few a min.) in my
> serial debug log:
> 
> (XEN) traps.c:2956: GPF (0060): ffff82c48015354a -> ffff82c480200131
> 
> Then, rawhide and gplpv don''t get along. Specifically, the xennet
receive side
> driver stops working, and I have to fall back to qemu emulation. It takes 
> about an hour for the winxp desktop to finish initializing, with dom0 cpu
load
> on one cpu core at 72% - yum! But I''ll just have to live with it -
it''s not
> your problem. I''ll leave it up for at least a day to see if any
other messages
> pop up.
Keep in mind that the patch for the <title> is going in 3.1, so it will
show
up in FC16 at some point.

You can also rebuild your kernel without the debug options..

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

jim burns

2011-Sep-16 20:06 UTC

head link

Re: [Fedora-xen] [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

On Fri September 16 2011, 1:38:14 PM, Konrad Rzeszutek Wilk
wrote:> > Testing out myoung''s 3.1.0 was not as straight forward as I
had hoped.
> > It did boot up without any BUG:s, but I did get the occasional Lock
> > Order message. Log snippet at the end of the post. It doesn''t
seem to
> > be directly related to starting guests.
> 
> Yeah, those look like the network card (b44 driver) is at fault.
Yeah, I see that now, plus references to nf_conntrack and bonding. These 
components don''t present problems under 2.6.40, so I''ll just
assume that this
is a timing problem introduced by the debug kernel.
> > The real problem comes in starting up guests. Performance is very bad.
I
> > knew from working with rawhide 3.0.0 (long since replaced) that
> > performance would suffer - rawhide kernels are debug kernels:
> 
> Right. They are horrendously slow.
> 
> > jimb@insp6400 09/16/11 10:16AM:~
> > [511] > grep DEBUG
> > /boot/config-3.1.0-0.rc6.git0.0.xendom0.fc17.x86_64|grep -v
''is not
> > set''|wc -l
> > 91
> > jimb@insp6400 09/16/11 10:16AM:~
> > [512] > grep DEBUG /boot/config-2.6.40.4-5.fc15.x86_64|grep -v
''is not
> > set''|wc -l
> > 54
> > jimb@insp6400 09/16/11 10:18AM:~
> > [513] > grep DEBUG /boot/config-3.0.1-3.fc16.x86_64|grep -v
''is not
> > set''|wc -l 90
> > 
> > Starting guests is much slower under myoung''s 3.1.0 than
under rawhide''s
> > 3.1.0 or 3.0.{0,1}. A cifs backed pv domu took 6 min. for ''xm
create''
> > to exit,
> 
> a debug kernel which will indeed be quite slow.
But the point I was emphasizing was that myoung''s 3.1.0 is slower than
even
rawhide''s 3.1.0. The ''(XEN) memory.c'' errors have
stopped, but I''m still
getting a few ''(XEN) traps.c:2956: GPF'' errors a min. with a
winxp domu up,
also something that did not happen under previous rawhide kernels. (I assume 
GPF=General Protection Fault, which would really slow things down to trap.)
> > root@insp6400 09/16/11 12:09AM:~
> > [544] > xl create Documents/winxp; brctl show;  ps -A|grep qemu;
netstat
> > -tlp| grep 59; renice -11 `pidof qemu-dm`;  ps -A|grep vncv; ifconfig
> > vif1.0 mtu 9000
> > Parsing config file Documents/winxp
> > 
> > xc: info: VIRTUAL MEMORY ARRANGEMENT:
> >   Loader:        0000000000100000->000000000017b270
> >   TOTAL:         0000000000000000->000000003fc00000
> >   ENTRY ADDRESS: 00000000001015a0
> > 
> > xc: error: Could not allocate memory for HVM guest. (16 = Device or
> > resource busy): Internal error
> > libxl: error: libxl_dom.c:284:libxl__build_hvm hvm building failed
> 
> How much memory do you have used for your dom0/domU?
Dom0 has 2 GB, which is enough to run one domu at a time (which usually has 
512 MB). (One of these days I''ll spring for a multi GB, IOMMU machine.)
> > and my serial debug log had several:
> > 
> > (XEN) memory.c:133:d0 Could not allocate order=9 extent: id=1
memflags=0
> > (1 of 4)
> > [snip]
> > Then I remembered that I recently upped the memory allocation for my
> > winxp domu, from 512 to 768. This works fine under 2.6.40, the f15
> > non-debug production kernel. None the less, I knocked the allocation
> > back down to 512, and my winxp domu did start up, getting to the qemu
> > splash screen in about 2 - 3 min., during part of which dom0 was
> > unresponsive. However, I''m still getting the ''(XEN)
memory.c'' errors,
> > and some frequent GPF errors (a few a min.) in my serial debug log:
> > 
> > (XEN) traps.c:2956: GPF (0060): ffff82c48015354a ->
ffff82c480200131
> > 
> > Then, rawhide and gplpv don''t get along. Specifically, the
xennet
> > receive side driver stops working, and I have to fall back to qemu
> > emulation. It takes about an hour for the winxp desktop to finish
> > initializing, with dom0 cpu load on one cpu core at 72% - yum! But
I''ll
> > just have to live with it - it''s not your problem.
I''ll leave it up for
> > at least a day to see if any other messages pop up.
> 
> Keep in mind that the patch for the <title> is going in 3.1, so it
will show
> up in FC16 at some point.
The patch for who? What''s <title>? Plus I have no interest in
updating to an
alpha release. I''ll wait till the final release. (And I REALLY have no 
interest in upgrading to grub2 :-) )
> You can also rebuild your kernel without the debug options..
Yeah - what''s the fastest way to do that? 2.6.40 has 54 active DEBUG
options,
3.1.0 has 91. Short of deactivating 37 DEBUG options, is there a master DEBUG 
option that will do the trick?

Not that it''s important. 2.6.40 has what I need for now. I can do
without pci
passthrough for awhile. Just curious about the fastest way to turn off the 
extra 37 DEBUG options, or at least the most time consuming culprits.

OK, if your confident that these problems will go away in a production kernel, 
especially the GPF error, I can wait. If you don''t need anything else,
I''ll
bring down the system, and retreat to 2.6.40 in a couple of hours. Thanx for 
you attention.

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

jim burns

2011-Sep-16 22:42 UTC

head link

Re: [Fedora-xen] [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

On Fri September 16 2011, 4:06:30 PM, jim burns wrote:> OK, if your confident that these problems will go away in a production
> kernel,  especially the GPF error, I can wait. If you don''t need
anything
> else, I''ll bring down the system, and retreat to 2.6.40 in a
couple of
> hours. Thanx for you attention.
Sorry, I take it back. Just rebooted back into 2.6.40, and I''m still
getting
GPF errors - just not very frequently.

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

Andy Burns

2011-Sep-18 08:08 UTC

head link

Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

Andy Burns <xen.lists@burns.me.uk> wrote:
> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>
>> We are quite sure we know the cause of this. I was wondering if you
>> would be up for beta-testing a patch for this?
>
> I''ll try to give that a go tomorrow night, I''m bumping
into the same sort of
> BUGs (scheduling while atomic, sleeping function called from invalid
> context) with FC16 dom0
OK, sorry it took a bit longer to get round to it ....

I upgraded to 3.1.0-rc6, then booted to baremetal (didn''t want
bugchecks during the build to corrupt the kernel I was building)

Instaleld kernel source and development tools, hacked the spec file to
tweak the buildid and insert Patch and ApplyPatch lines for your mutex
instead of spinlock patch, built the kernel, installed and booted the
resulting 3.1.0-rc6.andy kernel as baremetal to make sure it was OK,
which it was, then booted it under Xen, unfortunately it crashes ...

Log from serial console attached, any further infor required, just let
me know ...

(XEN) Xen version 4.1.1 (mockbuild@phx2.fedoraproject.org) (gcc
version 4.6.1 20110715 (Red Hat 4.6.1-3) (GCC) ) Sun Aug 14 14:29:37
UTC 2011
(XEN) Latest ChangeSet: unavailable
(XEN) Bootloader: GRUB 1.99~rc1
(XEN) Command line: com1=115200,8n1 console=com1 loglvl=all guest_loglvl=all
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 2 seconds
(XEN) Disc information:
(XEN)  Found 0 MBR signatures
(XEN)  Found 6 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009cc00 (usable)
(XEN)  000000000009cc00 - 00000000000a0000 (reserved)
(XEN)  00000000000e5000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000cff80000 (usable)
(XEN)  00000000cff80000 - 00000000cff8e000 (ACPI data)
(XEN)  00000000cff8e000 - 00000000cffe0000 (ACPI NVS)
(XEN)  00000000cffe0000 - 00000000d0000000 (reserved)
(XEN)  00000000e0000000 - 00000000f0000000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000ffe00000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000230000000 (usable)
(XEN) ACPI: RSDP 000FAFF0, 0024 (r2 ACPIAM)
(XEN) ACPI: XSDT CFF80100, 0054 (r1 A_M_I_ OEMXSDT   2000913 MSFT       97)
(XEN) ACPI: FACP CFF80290, 00F4 (r3 A_M_I_ OEMFACP   2000913 MSFT       97)
(XEN) ACPI: DSDT CFF80450, 86FF (r1  A0863 A0863001        1 INTL 20060113)
(XEN) ACPI: FACS CFF8E000, 0040
(XEN) ACPI: APIC CFF80390, 0078 (r1 A_M_I_ OEMAPIC   2000913 MSFT       97)
(XEN) ACPI: MCFG CFF80410, 003C (r1 A_M_I_ OEMMCFG   2000913 MSFT       97)
(XEN) ACPI: OEMB CFF8E040, 0081 (r1 A_M_I_ AMI_OEM   2000913 MSFT       97)
(XEN) ACPI: HPET CFF88B50, 0038 (r1 A_M_I_ OEMHPET   2000913 MSFT       97)
(XEN) ACPI: OSFR CFF88B90, 00B0 (r1 A_M_I_ OEMOSFR   2000913 MSFT       97)
(XEN) System RAM: 8191MB (8387696kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at 0000000000000000-0000000230000000
(XEN) Domain heap initialised
(XEN) found SMP MP-table at 000ff780
(XEN) DMI 2.4 present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x808
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[804,0], pm1x_evt[800,0]
(XEN) ACPI:                  wakeup_vec[cff8e00c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) Processor #0 7:7 APIC version 20
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
(XEN) Processor #1 7:7 APIC version 20
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
(XEN) Processor #2 7:7 APIC version 20
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
(XEN) Processor #3 7:7 APIC version 20
(XEN) ACPI: IOAPIC (id[0x04] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 4, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: IOAPIC (id[0x05] address[0xfec10000] gsi_base[24])
(XEN) IOAPIC[1]: apic_id 5, version 255, address 0xfec10000, GSI 24-279
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode:  Flat.  Using 2 I/O APICs
(XEN) ACPI: HPET id: 0x8086a301 base: 0xfed00000
(XEN) PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
(XEN) PCI: MCFG area at e0000000 reserved in E820
(XEN) Table is not found!
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) IRQ limits: 280 GSI, 1960 MSI/MSI-X
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2671.658 MHz processor.
(XEN) Initing memory sharing.
(XEN) mce_intel.c:1162: MCA Capability: BCAST 1 SER 0 CMCI 0 firstbank
1 extended MCE MSR 0
(XEN) Intel machine check reporting enabled
(XEN) I/O virtualisation disabled
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using new ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) Platform timer is 14.318MHz HPET
ÿ(XEN) Allocated console ring of 32 KiB.
(XEN) VMX: Supported advanced features:
(XEN)  - APIC MMIO access virtualisation
(XEN)  - APIC TPR shadow
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN) HVM: ASIDs disabled.
(XEN) HVM: VMX enabled
(XEN) Brought up 4 CPUs
(XEN) HPET: 4 timers in total, 0 timers will be used for broadcast
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1ee8000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000220000000->0000000224000000 (2012517
pages to be allocated)
(XEN)  Init. ramdisk: 000000022d5e9000->000000022ffff200
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff81ee8000
(XEN)  Init. ramdisk: ffffffff81ee8000->ffffffff848fe200
(XEN)  Phys-Mach map: ffffffff848ff000->ffffffff8588ebe0
(XEN)  Start info:    ffffffff8588f000->ffffffff8588f4b4
(XEN)  Page tables:   ffffffff85890000->ffffffff858c1000
(XEN)  Boot stack:    ffffffff858c1000->ffffffff858c2000
(XEN)  TOTAL:         ffffffff80000000->ffffffff85c00000
(XEN)  ENTRY ADDRESS: ffffffff81b76200
(XEN) Dom0 has maximum 4 VCPUs
(XEN) Scrubbing Free RAM: .done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) *** Serial input -> DOM0 (type ''CTRL-a'' three times
to switch
input to Xen)
(XEN) Freed 224kB init memory.
mapping kernel into physical memory
Xen: setup ISA identity maps
about to get started...
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.1.0-0.rc6.git0.0.andy.fc16.x86_64
(root@xen.lan) (gcc version 4.6.1 20110908 (Red Hat 4.6.1-9) (GCC) )
#1 SMP Sat Sep 17 20:49:28 BST 2011
[    0.000000] Command line: placeholder
root=/dev/mapper/vgr1-fc16_root ro console=hvc0
[    0.000000] Freeing  d0000-e0000 pfn range: 65536 pages freed
[    0.000000] Freeing  f0000-fec00 pfn range: 60416 pages freed
[    0.000000] Freeing  fec01-fec10 pfn range: 15 pages freed
[    0.000000] Freeing  fec11-fee00 pfn range: 495 pages freed
[    0.000000] Freeing  fee01-ffe00 pfn range: 4095 pages freed
[    0.000000] released 130557 pages of unused memory
[    0.000000] Set 196835 page(s) to 1-1 mapping.
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  Xen: 0000000000000000 - 000000000009c000 (usable)
[    0.000000]  Xen: 000000000009cc00 - 0000000000100000 (reserved)
[    0.000000]  Xen: 0000000000100000 - 00000000cff80000 (usable)
[    0.000000]  Xen: 00000000cff80000 - 00000000cff8e000 (ACPI data)
[    0.000000]  Xen: 00000000cff8e000 - 00000000cffe0000 (ACPI NVS)
[    0.000000]  Xen: 00000000cffe0000 - 00000000d0000000 (reserved)
[    0.000000]  Xen: 00000000e0000000 - 00000000f0000000 (reserved)
[    0.000000]  Xen: 00000000fec00000 - 00000000fec01000 (reserved)
[    0.000000]  Xen: 00000000fec10000 - 00000000fec11000 (reserved)
[    0.000000]  Xen: 00000000fee00000 - 00000000fee01000 (reserved)
[    0.000000]  Xen: 00000000ffe00000 - 0000000100000000 (reserved)
[    0.000000]  Xen: 0000000100000000 - 0000001373ad8000 (usable)
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI 2.4 present.
[    0.000000] No AGP bridge found
[    0.000000] last_pfn = 0x1373ad8 max_arch_pfn = 0x400000000
[    0.000000] last_pfn = 0xcff80 max_arch_pfn = 0x400000000
[    0.000000] found SMP MP-table at [ffff8800000ff780] ff780
[    0.000000] init_memory_mapping: 0000000000000000-00000000cff80000
[    0.000000] init_memory_mapping: 0000000100000000-0000001373ad8000
[    0.000000] RAMDISK: 01ee8000 - 048ff000
[    0.000000] ACPI: RSDP 00000000000faff0 00024 (v02 ACPIAM)
[    0.000000] ACPI: XSDT 00000000cff80100 00054 (v01 A_M_I_ OEMXSDT
02000913 MSFT 00000097)
[    0.000000] ACPI: FACP 00000000cff80290 000F4 (v03 A_M_I_ OEMFACP
02000913 MSFT 00000097)
[    0.000000] ACPI: DSDT 00000000cff80450 086FF (v01  A0863 A0863001
00000001 INTL 20060113)
[    0.000000] ACPI: FACS 00000000cff8e000 00040
[    0.000000] ACPI: APIC 00000000cff80390 00078 (v01 A_M_I_ OEMAPIC
02000913 MSFT 00000097)
[    0.000000] ACPI: MCFG 00000000cff80410 0003C (v01 A_M_I_ OEMMCFG
02000913 MSFT 00000097)
[    0.000000] ACPI: OEMB 00000000cff8e040 00081 (v01 A_M_I_ AMI_OEM
02000913 MSFT 00000097)
[    0.000000] ACPI: HPET 00000000cff88b50 00038 (v01 A_M_I_ OEMHPET
02000913 MSFT 00000097)
[    0.000000] ACPI: OSFR 00000000cff88b90 000B0 (v01 A_M_I_ OEMOSFR
02000913 MSFT 00000097)
[    0.000000] No NUMA configuration found
[    0.000000] Faking a node at 0000000000000000-0000001373ad8000
[    0.000000] Initmem setup node 0 0000000000000000-0000001373ad8000
[    0.000000]   NODE_DATA [00000001f1f68000 - 00000001f1f7bfff]
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA      0x00000010 -> 0x00001000
[    0.000000]   DMA32    0x00001000 -> 0x00100000
[    0.000000]   Normal   0x00100000 -> 0x01373ad8
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[3] active PFN ranges
[    0.000000]     0: 0x00000010 -> 0x0000009c
[    0.000000]     0: 0x00000100 -> 0x000cff80
[    0.000000]     0: 0x00100000 -> 0x01373ad8
[    0.000000] ACPI: PM-Timer IO Port: 0x808
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[    0.000000] BIOS bug: APIC version is 0 for CPU 0/0x0, fixing up to 0x10
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
[    0.000000] ACPI: IOAPIC (id[0x04] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 4, version 255, address 0xfec00000, GSI 0-255
[    0.000000] ACPI: IOAPIC (id[0x05] address[0xfec10000] gsi_base[24])
[    0.000000] IOAPIC[1]: apic_id 5, version 255, address 0xfec10000, GSI 24-279
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a301 base: 0xfed00000
[    0.000000] SMP: Allowing 4 CPUs, 0 hotplug CPUs
[    0.000000] PM: Registered nosave memory: 000000000009c000 - 000000000009d000
[    0.000000] PM: Registered nosave memory: 000000000009d000 - 0000000000100000
[    0.000000] PM: Registered nosave memory: 00000000cff80000 - 00000000cff8e000
[    0.000000] PM: Registered nosave memory: 00000000cff8e000 - 00000000cffe0000
[    0.000000] PM: Registered nosave memory: 00000000cffe0000 - 00000000d0000000
[    0.000000] PM: Registered nosave memory: 00000000d0000000 - 00000000e0000000
[    0.000000] PM: Registered nosave memory: 00000000e0000000 - 00000000f0000000
[    0.000000] PM: Registered nosave memory: 00000000f0000000 - 00000000fec00000
[    0.000000] PM: Registered nosave memory: 00000000fec00000 - 00000000fec01000
[    0.000000] PM: Registered nosave memory: 00000000fec01000 - 00000000fec10000
[    0.000000] PM: Registered nosave memory: 00000000fec10000 - 00000000fec11000
[    0.000000] PM: Registered nosave memory: 00000000fec11000 - 00000000fee00000
[    0.000000] PM: Registered nosave memory: 00000000fee00000 - 00000000fee01000
[    0.000000] PM: Registered nosave memory: 00000000fee01000 - 00000000ffe00000
[    0.000000] PM: Registered nosave memory: 00000000ffe00000 - 0000000100000000
[    0.000000] Allocating PCI resources starting at d0000000 (gap:
d0000000:10000000)
[    0.000000] Booting paravirtualized kernel on Xen
[    0.000000] Xen version: 4.1.1 (preserve-AD)
[    0.000000] setup_percpu: NR_CPUS:256 nr_cpumask_bits:256
nr_cpu_ids:4 nr_node_ids:1
[    0.000000] PERCPU: Embedded 27 pages/cpu @ffff8801f1ea8000 s81024
r8192 d21376 u110592
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 19881203
[    0.000000] Policy zone: Normal
[    0.000000] Kernel command line: placeholder
root=/dev/mapper/vgr1-fc16_root ro console=hvc0
[    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    0.000000] Placing 64MB software IO TLB between ffff880196c00000 -
ffff88019ac00000
[    0.000000] software IO TLB at phys 0x196c00000 - 0x19ac00000
[    0.000000] Memory: 5807024k/81587040k available (4866k kernel
code, 787408k absent, 74992608k reserved, 6783k data, 940k init)
[    0.000000] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0,
CPUs=4, Nodes=1
[    0.000000] Hierarchical RCU implementation.
[    0.000000]  RCU dyntick-idle grace-period acceleration is enabled.
[    0.000000] NR_IRQS:16640 nr_irqs:1024 16
[    0.000000] xen: sci override: global_irq=9 trigger=0 polarity=0
[    0.000000] xen: acpi sci 9
[    0.000000] xen_map_pirq_gsi: returning irq 9 for gsi 9
[    0.000000] Console: colour VGA+ 80x25
[    0.000000] console [hvc0] enabled
[    0.000000] allocated 646971392 bytes of page_cgroup
[    0.000000] please try ''cgroup_disable=memory'' option if
you don''t
want memory cgroups
[    0.000000] installing Xen timer for CPU 0
[    0.000000] Detected 2671.658 MHz processor.
[    0.000999] Calibrating delay loop (skipped), value calculated
using timer frequency.. 5343.31 BogoMIPS (lpj=2671658)
[    0.000999] pid_max: default: 32768 minimum: 301
[    0.000999] Security Framework initialized
[    0.000999] SELinux:  Initializing.
[    0.033997] Dentry cache hash table entries: 16777216 (order: 15,
134217728 bytes)
[    0.090663] Inode-cache hash table entries: 8388608 (order: 14,
67108864 bytes)
[    0.111596] Mount-cache hash table entries: 256
[    0.111823] Initializing cgroup subsys cpuacct
[    0.111832] Initializing cgroup subsys memory
[    0.111869] Initializing cgroup subsys devices
[    0.111874] Initializing cgroup subsys freezer
[    0.111878] Initializing cgroup subsys net_cls
[    0.111883] Initializing cgroup subsys blkio
[    0.111898] Initializing cgroup subsys perf_event
[    0.111962] CPU: Physical Processor ID: 0
[    0.111966] CPU: Processor Core ID: 0
[    0.112567] ACPI: Core revision 20110623
[    0.120005] ftrace: allocating 25203 entries in 99 pages
[    0.121082] Performance Events: unsupported p6 CPU model 23 no PMU
driver, software events only.
[    0.121451] NMI watchdog disabled (cpu0): hardware events not enabled
[    0.121555] installing Xen timer for CPU 1
[    0.121692] NMI watchdog disabled (cpu1): hardware events not enabled
[    0.121820] installing Xen timer for CPU 2
[    0.121963] NMI watchdog disabled (cpu2): hardware events not enabled
[    0.122018] installing Xen timer for CPU 3
[    0.122148] NMI watchdog disabled (cpu3): hardware events not enabled
[    0.122184] Brought up 4 CPUs
[    0.122282] devtmpfs: initialized
[    0.134984] PM: Registering ACPI NVS region at cff8e000 (335872 bytes)
[    0.135572] atomic64 test passed for x86-64 platform with CX8 and with SSE
[    0.135595] Grant table initialized
[    0.135624] RTC time:  7:52:55, date: 09/18/11
[    0.135663] NET: Registered protocol family 16
[    0.135751] ACPI: bus type pci registered
[    0.135751] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem
0xe0000000-0xefffffff] (base 0xe0000000)
[    0.135751] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E820
[    0.205629] PCI: Using configuration type 1 for base access
[    0.211294] bio: create slab <bio-0> at 0
[    0.211294] ACPI: Added _OSI(Module Device)
[    0.211294] ACPI: Added _OSI(Processor Device)
[    0.211294] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.211294] ACPI: Added _OSI(Processor Aggregator Device)
[    0.216698] ACPI: Executed 1 blocks of module-level executable AML code
[    0.223169] ACPI: SSDT 00000000cff8e0d0 001D2 (v01    AMI   CPU1PM
00000001 INTL 20060113)
[    0.223858] ACPI: Dynamic OEM Table Load:
[    0.223865] ACPI: SSDT           (null) 001D2 (v01    AMI   CPU1PM
00000001 INTL 20060113)
[    0.224041] ACPI: SSDT 00000000cff8e2b0 00143 (v01    AMI   CPU2PM
00000001 INTL 20060113)
[    0.224706] ACPI: Dynamic OEM Table Load:
[    0.224712] ACPI: SSDT           (null) 00143 (v01    AMI   CPU2PM
00000001 INTL 20060113)
[    0.224974] ACPI: SSDT 00000000cff8e400 00143 (v01    AMI   CPU3PM
00000001 INTL 20060113)
[    0.225598] ACPI: Dynamic OEM Table Load:
[    0.225604] ACPI: SSDT           (null) 00143 (v01    AMI   CPU3PM
00000001 INTL 20060113)
[    0.225850] ACPI: SSDT 00000000cff8e550 00143 (v01    AMI   CPU4PM
00000001 INTL 20060113)
[    0.226474] ACPI: Dynamic OEM Table Load:
[    0.226480] ACPI: SSDT           (null) 00143 (v01    AMI   CPU4PM
00000001 INTL 20060113)
[    0.226698] ACPI: Interpreter enabled
[    0.226704] ACPI: (supports S0 S1 S3 S4 S5)
[    0.226730] ACPI: Using IOAPIC for interrupt routing
[    0.234461] ACPI: No dock devices found.
[    0.234465] HEST: Table not found.
[    0.234469] PCI: Using host bridge windows from ACPI; if necessary,
use "pci=nocrs" and report a bug
[    0.234567] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[    0.234734] pci_root PNP0A08:00: host bridge window [io  0x0000-0x0cf7]
[    0.234740] pci_root PNP0A08:00: host bridge window [io  0x0d00-0xffff]
[    0.234744] pci_root PNP0A08:00: host bridge window [mem
0x000a0000-0x000bffff]
[    0.234749] pci_root PNP0A08:00: host bridge window [mem
0x000d0000-0x000dffff]
[    0.234754] pci_root PNP0A08:00: host bridge window [mem
0xd0000000-0xffffffff]
[    0.237146] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at
0294 (mask 0003)
[    0.237972] pci 0000:01:00.0: disabling ASPM on pre-1.1 PCIe
device.  You can enable it with ''pcie_aspm=force''
[    0.237972] pci 0000:00:01.0: PCI bridge to [bus 01-01]
[    0.238409] pci 0000:05:00.0: disabling ASPM on pre-1.1 PCIe
device.  You can enable it with ''pcie_aspm=force''
[    0.238418] pci 0000:00:1c.0: PCI bridge to [bus 05-07]
[    0.238831] pci 0000:05:00.0: PCI bridge to [bus 07-07]
[    0.238972] pci 0000:05:00.1: PCI bridge to [bus 06-06]
[    0.241006] pci 0000:00:1c.2: PCI bridge to [bus 04-04]
[    0.243005] pci 0000:00:1c.3: PCI bridge to [bus 03-03]
[    0.243411] pci 0000:02:00.0: disabling ASPM on pre-1.1 PCIe
device.  You can enable it with ''pcie_aspm=force''
[    0.243419] pci 0000:00:1c.4: PCI bridge to [bus 02-02]
[    0.243972] pci 0000:00:1e.0: PCI bridge to [bus 08-08] (subtractive decode)
[    0.244414]  pci0000:00: Requesting ACPI _OSC control (0x1d)
[    0.244419]  pci0000:00: ACPI _OSC request failed (AE_NOT_FOUND),
returned control mask: 0x1d
[    0.244424] ACPI _OSC control for PCIe not granted, disabling ASPM
(XEN) PCI add device 00:00.0
(XEN) PCI add device 00:01.0
(XEN) PCI add device 00:1a.0
(XEN) PCI add device 00:1a.1
(XEN) PCI add device 00:1a.2
(XEN) PCI add device 00:1a.7
(XEN) PCI add device 00:1b.0
(XEN) PCI add device 00:1c.0
(XEN) PCI add device 00:1c.2
(XEN) PCI add device 00:1c.3
(XEN) PCI add device 00:1c.4
(XEN) PCI add device 00:1d.0
(XEN) PCI add device 00:1d.1
(XEN) PCI add device 00:1d.2
(XEN) PCI add device 00:1d.7
(XEN) PCI add device 00:1e.0
(XEN) PCI add device 00:1f.0
(XEN) PCI add device 00:1f.2
(XEN) PCI add device 00:1f.3
(XEN) PCI add device 01:00.0
(XEN) PCI add device 01:00.1
(XEN) PCI add device 05:00.0
(XEN) PCI add device 05:00.1
(XEN) PCI add device 07:01.0
(XEN) PCI add device 04:00.0
(XEN) PCI add device 03:00.0
(XEN) PCI add device 02:00.0
(XEN) PCI add device 08:00.0
(XEN) PCI add device 08:01.0
(XEN) PCI add device 08:03.0
[    0.254926] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 10 *11 12 14 15)
[    0.254970] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 *10 11 12 14 15)
[    0.254994] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 10 11 12 14 15)
[    0.255065] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 10 11 12 14 *15)
[    0.255136] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11
12 14 15) *0, disabled.
[    0.255208] ACPI: PCI Interrupt Link [LNKF] (IRQs *3 4 5 6 7 10 11 12 14 15)
[    0.255278] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 *7 10 11 12 14 15)
[    0.255348] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 10 11 12 *14 15)
[    0.255401] xen/balloon: Initialising balloon driver.
[    0.255406] last_pfn = 0x1373ad8 max_arch_pfn = 0x400000000
[    0.615498] xen-balloon: Initialising balloon driver.
[    0.615522] xen/balloon: Xen selfballooning driver disabled for domain0.
[    0.615589] vgaarb: device added:
PCI:0000:01:00.0,decodes=io+mem,owns=io+mem,locks=none
[    0.615589] vgaarb: loaded
[    0.615589] vgaarb: bridge control possible 0000:01:00.0
[    0.615589] SCSI subsystem initialized
[    0.615589] usbcore: registered new interface driver usbfs
[    0.615589] usbcore: registered new interface driver hub
[    0.615589] usbcore: registered new device driver usb
[    0.615948] PCI: Using ACPI for IRQ routing
(XEN) mm.c:4976:d0 Global bit is set to kernel page fffff81b8e
(XEN) mm.c:4976:d0 Global bit is set to kernel page fffff81b8e
(XEN) mm.c:4976:d0 Global bit is set to kernel page fffff81118
(XEN) mm.c:4976:d0 Global bit is set to kernel page fffff81117
(XEN) domain_crash_sync called from entry.S
(XEN) Domain 0 (vcpu#0) crashed on cpu#0:
(XEN) ----[ Xen-4.1.1  x86_64  debug=n  Not tainted ]----
(XEN) CPU:    0
(XEN) RIP:    e033:[<ffffffff81118d96>]
(XEN) RFLAGS: 0000000000010282   EM: 0   CONTEXT: pv guest
(XEN) rax: 0000000000000080   rbx: ffff880163985480   rcx: 0000000000000040
(XEN) rdx: 0040000000000080   rsi: ffff880163985480   rdi: ffff880163985480
(XEN) rbp: ffff880163dfaff0   rsp: ffff880163dfafd0   r8:  0000001373ffffff
(XEN) r9:  ffffffff81b8e7fd   r10: 0000ffff00066c0a   r11: 0000000080000000
(XEN) r12: ffffffff81a1cbd0   r13: ffffffff81b8e7fd   r14: 0000001000000000
(XEN) r15: ffffffff81a1cbd0   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000221a05000   cr2: 000000137400002f
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b   cs: e033
(XEN) Guest stack trace from rsp=ffff880163dfafd0:
(XEN)    ffffffff81a1cbd0 0000001373ffffff ffffffff81a1cbd0 ffffffff817a86d7
(XEN)    ffff880163dfb040 ffffffff81b8e7fd ffff880163dfb010 ffff880163985480
(XEN)    ffff880163dfb040 0000001373ffffff ffffffff81a1cbd0 ffffffff817a86d7
(XEN)    0000001000000000 ffffffff81a1cbd0 ffff880163dfb090 ffffffff81b8e838
(XEN)    ffff880163dfb060 ffff880163985480 ffff880163dfb090 0000001373ffffff
(XEN)    ffffffff81a1cbd0 ffffffff817a86d7 0000001000000000 ffffffff81a1cbd0
(XEN)    ffff880163dfb0e0 ffffffff81b8e838 ffff880163dfb0b0 ffff880163985480
(XEN)    ffff880163dfb0e0 0000001373ffffff ffffffff81a1cbd0 ffffffff817a86d7
(XEN)    0000001000000000 ffffffff81a1cbd0 ffff880163dfb130 ffffffff81b8e838
(XEN)    ffff880163dfb100 ffff880163985480 ffff880163dfb130 0000001373ffffff
(XEN)    ffffffff81a1cbd0 ffffffff817a86d7 0000001000000000 ffffffff81a1cbd0
(XEN)    ffff880163dfb180 ffffffff81b8e838 ffff880163dfb150 ffff880163985480
(XEN)    ffff880163dfb180 0000001373ffffff ffffffff81a1cbd0 ffffffff817a86d7
(XEN)    0000001000000000 ffffffff81a1cbd0 ffff880163dfb1d0 ffffffff81b8e838
(XEN)    ffff880163dfb1a0 ffff880163985480 ffff880163dfb1d0 0000001373ffffff
(XEN)    ffffffff81a1cbd0 ffffffff817a86d7 0000001000000000 ffffffff81a1cbd0
(XEN)    ffff880163dfb220 ffffffff81b8e838 ffff880163dfb1f0 ffff880163985480
(XEN)    ffff880163dfb220 0000001373ffffff ffffffff81a1cbd0 ffffffff817a86d7
(XEN)    0000001000000000 ffffffff81a1cbd0 ffff880163dfb270 ffffffff81b8e838
(XEN)    ffff880163dfb240 ffff880163985480 ffff880163dfb270 0000001373ffffff
(XEN) Domain 0 crashed: rebooting machine in 5 seconds.

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

Andy Burns

2011-Sep-18 10:33 UTC

head link

Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

On 18 September 2011 09:08, Andy Burns <xen.lists@burns.me.uk> wrote:
> I upgraded to 3.1.0-rc6, then booted to baremetal (didn''t want
> bugchecks during the build to corrupt the kernel I was building)
>
> Instaleld kernel source and development tools, hacked the spec file to
> tweak the buildid and insert Patch and ApplyPatch lines for your mutex
> instead of spinlock patch, built the kernel, installed and booted the
> resulting 3.1.0-rc6.andy kernel as baremetal to make sure it was OK,
> which it was, then booted it under Xen, unfortunately it crashes ...
Doh!

I realised I hadn''t checked the stock FC16 3.1.0-rc6 kernel as dom0,
booted it under Xen and it crahes in exactly the same way, so it wan''t
Konrad''s mutex patch that did it at all, I''ll revert to rc5
and try
your patch on that, meanhile I''ve logged a bug

https://bugzilla.redhat.com/show_bug.cgi?id=739372

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

Andy Burns

2011-Sep-18 10:46 UTC

head link

Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

On 18 September 2011 11:33, Andy Burns <xen.lists@burns.me.uk> wrote:
> I''ll revert to rc5 and try your patch on that
Oh dear, -rc5 rpm and srpm have been flushed from the mirrors, so I''m
stumped for now :-(

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

Andy Burns

2011-Sep-18 14:03 UTC

head link

Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

On 18 September 2011 11:46, Andy Burns <xen.lists@burns.me.uk> wrote:
> rc5 rpm and srpm have been flushed from the mirrors
Remembered I could download the SRPM from koji, did that, built a
3.1.0-rc5 kernel including the mutex patch and can confirm it boots
cleanly as dom0, no errors from xen or kernel to serial console, I
haven''t started any domUs yet...

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

Andy Burns

2011-Sep-18 14:54 UTC

head link

Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

On 18 September 2011 15:03, Andy Burns <xen.lists@burns.me.uk> wrote:
> I haven''t started any domUs yet...
I can confirm I''ve started a pre-existing FC15 domU with PCI
passthrough of two DVB-T tuners (and a Fireweire port which needs to
be co-assigned due to sharing a common PCI bridge).

It''s been a long journey from FC8 to FC16, but it does feel *GOOD* to
be running pvops xen, with an alpha fedora dom0 and a current fedora
domU, thanks to everyone who worked hard to get to this point ...

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

Konrad Rzeszutek Wilk

2011-Sep-21 18:03 UTC

head link

Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

> [    0.615589] usbcore: registered new interface driver hub
> [    0.615589] usbcore: registered new device driver usb
> [    0.615948] PCI: Using ACPI for IRQ routing
> (XEN) mm.c:4976:d0 Global bit is set to kernel page fffff81b8e
> (XEN) mm.c:4976:d0 Global bit is set to kernel page fffff81b8e
> (XEN) mm.c:4976:d0 Global bit is set to kernel page fffff81118
> (XEN) mm.c:4976:d0 Global bit is set to kernel page fffff81117
> (XEN) domain_crash_sync called from entry.S
> (XEN) Domain 0 (vcpu#0) crashed on cpu#0:
> (XEN) ----[ Xen-4.1.1  x86_64  debug=n  Not tainted ]----
> (XEN) CPU:    0
> (XEN) RIP:    e033:[<ffffffff81118d96>]
> (XEN) RFLAGS: 0000000000010282   EM: 0   CONTEXT: pv guest
> (XEN) rax: 0000000000000080   rbx: ffff880163985480   rcx: 0000000000000040
> (XEN) rdx: 0040000000000080   rsi: ffff880163985480   rdi: ffff880163985480
> (XEN) rbp: ffff880163dfaff0   rsp: ffff880163dfafd0   r8:  0000001373ffffff
> (XEN) r9:  ffffffff81b8e7fd   r10: 0000ffff00066c0a   r11: 0000000080000000
> (XEN) r12: ffffffff81a1cbd0   r13: ffffffff81b8e7fd   r14: 0000001000000000
> (XEN) r15: ffffffff81a1cbd0   cr0: 000000008005003b   cr4: 00000000000026f0
> (XEN) cr3: 0000000221a05000   cr2: 000000137400002f
> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b   cs: e033
That is fixed in the latest Linus tree. You might need this patch as well:
(also attached)

commit e3b73c4a25e9a5705b4ef28b91676caf01f9bc9f
Author: David Vrabel <david.vrabel@citrix.com>
Date:   Tue Sep 13 10:17:32 2011 -0400

    xen/e820: if there is no dom0_mem=, don''t tweak extra_pages.
    
    The patch "xen: use maximum reservation to limit amount of usable
RAM"
    (d312ae878b6aed3912e1acaaf5d0b2a9d08a4f11) breaks machines that
    do not use ''dom0_mem='' argument with:
    
    reserve RAM buffer: 000000133f2e2000 - 000000133fffffff
    (XEN) mm.c:4976:d0 Global bit is set to kernel page fffff8117e
    (XEN) domain_crash_sync called from entry.S
    (XEN) Domain 0 (vcpu#0) crashed on cpu#0:
    ...
    
    The reason being that the last E820 entry is created using the
    ''extra_pages'' (which is based on how many pages have been
freed).
    The mentioned git commit sets the initial value of
''extra_pages''
    using a hypercall which returns the number of pages (if dom0_mem
    has been used) or -1 otherwise. If the later we return with
    MAX_DOMAIN_PAGES as basis for calculation:
    
        return min(max_pages, MAX_DOMAIN_PAGES);
    
    and use it:
    
         extra_limit = xen_get_max_pages();
         if (extra_limit >= max_pfn)
                 extra_pages = extra_limit - max_pfn;
         else
                 extra_pages = 0;
    
    which means we end up with extra_pages = 128GB in PFNs (33554432)
    - 8GB in PFNs (2097152, on this specific box, can be larger or smaller),
    and then we add that value to the E820 making it:
    
      Xen: 00000000ff000000 - 0000000100000000 (reserved)
      Xen: 0000000100000000 - 000000133f2e2000 (usable)
    
    which is clearly wrong. It should look as so:
    
      Xen: 00000000ff000000 - 0000000100000000 (reserved)
      Xen: 0000000100000000 - 000000027fbda000 (usable)
    
    Naturally this problem does not present itself if dom0_mem=max:X
    is used.
    
    CC: stable@kernel.org
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index ff3dfa1..09688eb 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -305,10 +305,12 @@ char * __init xen_memory_setup(void)
 	sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map);
 
 	extra_limit = xen_get_max_pages();
-	if (extra_limit >= max_pfn)
-		extra_pages = extra_limit - max_pfn;
-	else
-		extra_pages = 0;
+	if (max_pfn + extra_pages > extra_limit) {
+		if (extra_limit > max_pfn)
+			extra_pages = extra_limit - max_pfn;
+		else
+			extra_pages = 0;
+	}
 
 	extra_pages += xen_return_unused_memory(xen_start_info->nr_pages,
&e820);
 


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

Andy Burns

2011-Sep-21 19:43 UTC

head link

Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

On 21 September 2011 19:03, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
>> [    0.615589] usbcore: registered new interface driver hub
>> [    0.615589] usbcore: registered new device driver usb
>> [    0.615948] PCI: Using ACPI for IRQ routing
>> (XEN) mm.c:4976:d0 Global bit is set to kernel page fffff81b8e
>> (XEN) mm.c:4976:d0 Global bit is set to kernel page fffff81b8e
>> (XEN) mm.c:4976:d0 Global bit is set to kernel page fffff81118
>> (XEN) mm.c:4976:d0 Global bit is set to kernel page fffff81117
>> (XEN) domain_crash_sync called from entry.S
>> (XEN) Domain 0 (vcpu#0) crashed on cpu#0:
>> (XEN) ----[ Xen-4.1.1  x86_64  debug=n  Not tainted ]----
>> (XEN) CPU:    0
>> (XEN) RIP:    e033:[<ffffffff81118d96>]
>> (XEN) RFLAGS: 0000000000010282   EM: 0   CONTEXT: pv guest
>> (XEN) rax: 0000000000000080   rbx: ffff880163985480   rcx:
0000000000000040
>> (XEN) rdx: 0040000000000080   rsi: ffff880163985480   rdi:
ffff880163985480
>> (XEN) rbp: ffff880163dfaff0   rsp: ffff880163dfafd0   r8:
 0000001373ffffff
>> (XEN) r9:  ffffffff81b8e7fd   r10: 0000ffff00066c0a   r11:
0000000080000000
>> (XEN) r12: ffffffff81a1cbd0   r13: ffffffff81b8e7fd   r14:
0000001000000000
>> (XEN) r15: ffffffff81a1cbd0   cr0: 000000008005003b   cr4:
00000000000026f0
>> (XEN) cr3: 0000000221a05000   cr2: 000000137400002f
>> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b   cs: e033
>
> That is fixed in the latest Linus tree. You might need this patch as well:
>    xen/e820: if there is no dom0_mem=, don''t tweak extra_pages.
Yep, can confirm that adding a dom0_mem= limit prevents the crash,
will build an -rc6  kernel with both the mutex patch and the don''t
tweak extra pages patch later just to double check .

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

Andy Burns

2011-Sep-22 20:15 UTC

head link

Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

On 21 September 2011 20:43, Andy Burns <xen.lists@burns.me.uk> wrote:
> Yep, can confirm that adding a dom0_mem= limit prevents the crash,
> will build an -rc6  kernel with both the mutex patch and the don''t
> tweak extra pages patch later
Oh look, 3.1.0-rc7 beat me to it, just tested from koji and it boots
fine as dom0 and baremetal.

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

Konrad Rzeszutek Wilk

2011-Sep-22 20:21 UTC

head link

Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

On Thu, Sep 22, 2011 at 09:15:56PM +0100, Andy Burns
wrote:> On 21 September 2011 20:43, Andy Burns <xen.lists@burns.me.uk> wrote:
> 
> > Yep, can confirm that adding a dom0_mem= limit prevents the crash,
> > will build an -rc6  kernel with both the mutex patch and the
don''t
> > tweak extra pages patch later
> 
> Oh look, 3.1.0-rc7 beat me to it, just tested from koji and it boots
> fine as dom0 and baremetal.
Great! Thanks for testing and confirming!

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

jim burns

2011-Sep-23 17:33 UTC

head link

Re: [Fedora-xen] [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

On Fri September 16 2011, 6:42:32 PM, jim burns wrote:> On Fri September 16 2011, 4:06:30 PM, jim burns wrote:
> > OK, if your confident that these problems will go away in a production
> > kernel,  especially the GPF error, I can wait. If you don''t
need
> > anything
> > else, I''ll bring down the system, and retreat to 2.6.40 in a
couple of
> > hours. Thanx for you attention.
> 
> Sorry, I take it back. Just rebooted back into 2.6.40, and I''m
still getting
> GPF errors - just not very frequently.
Yayyy! Fedora rawhide just came out with 3.1.0-0.rc7.git0.2.fc17. It boots up 
without any BUG:s. I assume your '' Alter the locking to be a
mutex.'' patch
made it into rc7. It starts my winxp domu, w/512 MB, reasonably fast, for a 
rawhide kernel. ''time xm create'' reports:

xm create winxp  0.21s user 0.48s system 3% cpu 17.738 total

This is a far cry from the 3-6 min. under rc6.

When I up the memory to 768 MB, ''xm create'' does not hang,
like in rc6, but
does take longer to complete:

xm create winxp  0.18s user 0.64s system 0% cpu 2:48.65 total

Also, tmem (I''m guessing) is cooperating with dom0''s
''free'' a lot better.
Starting up rc7, before starting any guests:

jimb@insp6400 09/23/11 11:07AM:~
[503] > free
             total       used       free     shared    buffers     cached
Mem:       1797668    1702884      94784          0      82784     490104
-/+ buffers/cache:    1129996     667672
Swap:      4063228          0    4063228

After starting one 512 MB guest:

root@insp6400 09/23/11 11:23AM:~
[504] > free
             total       used       free     shared    buffers     cached
Mem:       1387244    1352212      35032          0      23660     178560
-/+ buffers/cache:    1149992     237252
Swap:      4063228        104    4063124

After stopping the 512 MB guest, and starting a 768 MB guest:

root@insp6400 09/23/11 11:38AM:~
[510] > free 
             total       used       free     shared    buffers     cached
Mem:       1073900    1058108      15792          0       2564      66488
-/+ buffers/cache:     989056      84844
Swap:      4063228     141368    3921860

However, on 3.1.0-0.rc6.git0.0.xendom0.fc17 (myoung''s temp build),
before any
guests:

[506] > free
             total       used       free     shared    buffers     cached
Mem:       1495104    1407388      87716          0      14780     116976
-/+ buffers/cache:    1275632     219472
Swap:      4063228       8508    4054720

which is 300 MB less than rc7. After starting up a 512 MB guest:

root@insp6400 09/23/11  1:17PM:/boot/grub
[510] > free
             total       used       free     shared    buffers     cached
Mem:       1084680    1000164      84516          0       2580      75724
-/+ buffers/cache:     921860     162820
Swap:      4063228     388032    3675196

which is still 300 MB less than rc7. In all cases, ''xm list''
does report the
correct amount of memory. I''m saying the cooperation with
dom0''s ''free'' is
better in rc7.

All in all, you''re heading in the right direction. Thanx a lot.

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

Andy Burns

2011-Sep-26 07:22 UTC

head link

Re: [Fedora-xen] [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

On 23 September 2011 18:33, jim burns <jim_burn@bellsouth.net> wrote:
> All in all, you''re heading in the right direction. Thanx a lot.
I ran into a couple of issues trying to install a FC16betaRC2 domU

https://bugzilla.redhat.com/show_bug.cgi?id=708267

DIssapointing to read in the comments that the domU installation
release blocker criteria might be dropped from Fedora :-(

Even after I "hand-crafted" a domU (copied partitions from a baremetal
FC16 install into an LVM PV) it wouldn''t boot due to pygrub expecting
/boot/grub/menu.lst rather than /boot/grub2/grub.cfg, so I
hand-crafted one of those too, it boots but udev seems to dislike some
USB devices embedded on the PCIe card I''ve passed through to the domU
(PCI cards seem happy).

Also the dom0 is very slow to reboot or poweroff, seems systemd
related, it appears to want to unmount a sys/xen (?or similar?)
mountpoint and keeps attempting this in with all the other closedown
actions.

I also found a few ways of triggering bugchecks when using PCI
passthrough, I''ll log BZs later for these when I have a serial console
hooked up again (not forgotten about upstreaming my grub2 helper patch
either)

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

Konrad Rzeszutek Wilk

2011-Sep-26 14:42 UTC

head link

Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

On Tue, Jul 26, 2011 at 04:39:41PM +0100, Ian Campbell
wrote:> On Mon, 2011-07-25 at 17:05 -0400, Pasi Kärkkäinen wrote:
> > On Mon, Jul 25, 2011 at 04:39:16PM -0400, jim burns wrote:
> > > On Mon July 25 2011 3:57:23 PM Pasi wrote:
> > > > On Mon, Jul 25, 2011 at 03:48:18PM -0400, jim burns wrote:
> > > > > On Mon July 25 2011 3:31:22 PM Pasi wrote:
> > > > > > On Sat, Jul 23, 2011 at 02:26:56PM -0400, jim
burns wrote:
> > > > > > > Pls cc: me, as I am not subscribed.
> > > 
> > > > > > Hello,
> > > 
> > > > > Hi, Pasi! Long time no ''see''.
> > > 
> > > Btw, maybe you were following the thread ''[Xen-devel]
Failure to create HVM
> > > DomU at Xen 4.1 ( kernel 3.0.0-5-generic) Ubuntu 11.10 (alpha
2)''.  In my fork
> > > of that thread, I summarized many other threads over the last
month of people
> > > having problems starting an hvm domu under xen 4.1.x. Konrad
finally provided
> > > the solution - 4.1.x requires the pv style vfb= line, not the
indidvidual
> > > variables.
> 
> Perhaps I misunderstand this stuff but AIUI the vfb= line configures a
> Xen PV framebuffer device whereas the individual vnc*/sdl*/etc variables
> configure the backend for the emulated VGA device. IOW they are pretty
> much orthogonal and (for an HVM guest) both should work (dependent on
> the required in-guest support being available). Also I''m not sure
if
> they can be used simultaneously, I expect they can.
Seems you can (mix them both). I honestly had no idea and just used either one
figuring it was ''xl'' "bug". As in
''xm'' it used to work with just individual
''vfb''
lines.

Hmm, should have reported this at some point - sorry about that.

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

Xen users - Jul 2011 - 3.0.0 and gplpv

[Xen-users] 3.0.0 and gplpv

RE: [Xen-users] 3.0.0 and gplpv

Re: [Xen-users] 3.0.0 and gplpv

Re: [Xen-users] 3.0.0 and gplpv

RE: [Xen-users] 3.0.0 and gplpv

Re: [Xen-users] 3.0.0 and gplpv

Re: [Xen-users] 3.0.0 and gplpv

Re: [Xen-users] 3.0.0 and gplpv

Re: [Xen-users] 3.0.0 and gplpv

Re: [Xen-users] 3.0.0 and gplpv

Re: [Xen-users] 3.0.0 and gplpv

Re: [Xen-users] 3.0.0 and gplpv

Re: [Xen-users] 3.0.0 and gplpv

Re: [Xen-users] 3.0.0 and gplpv

[Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

[Xen-users] Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

Re: RE: [Xen-users] 3.0.0 and gplpv

RE: [Xen-users] 3.0.0 and gplpv

Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

[Xen-users] Re: Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

Re: [Xen-users] Re: Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

Re: [Xen-users] Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

Re: [Xen-users] Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

Re: [Xen-users] Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

Re: [Xen-users] Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

Re: [Xen-users] Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

Re: [Xen-users] Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

Re: [Xen-users] Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

Re: [Xen-users] Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

Re: [Xen-users] Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

Re: [Xen-users] Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

[Xen-devel] Attempt to load kernel 2.6.40-4.fc15.x86_64 under Xen 4.1.1 on Fedora 15

Re: [Xen-devel] Attempt to load kernel 2.6.40-4.fc15.x86_64 under Xen 4.1.1 on Fedora 15

Re: Re: [Xen-users] Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

[Xen-users] Re: [Xen-devel] Attempt to load kernel 2.6.40-4.fc15.x86_64 under Xen 4.1.1 on Fedora 15

Re: Re: [Xen-users] Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

Re: Re: Re: [Xen-users] Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

Re: Re: Re: [Xen-users] Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

Re: [Xen-users] Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

Re: [Xen-users] Re: [Xen-devel] Updating Xen 4.1.x xmexamples files (vfb line required for HVM guests)

Re: [Xen-users] 3.0.0 and gplpv

Summary: Experiences setting up a debug serial port (was Re: [Xen-users] 3.1.0-rc0 git snapshot crashes as dom0 (private mail))

Re: Summary: Experiences setting up a debug serial port (was Re: [Xen-users] 3.1.0-rc0 git snapshot crashes as dom0 (private mail))

Re: Re: Summary: Experiences setting up a debug serial port (was Re: [Xen-users] 3.1.0-rc0 git snapshot crashes as dom0 (private mail))

Re: Summary: Experiences setting up a debug serial port (was Re: [Xen-users] 3.1.0-rc0 git snapshot crashes as dom0 (private mail))

Re: Summary: Experiences setting up a debug serial port (was Re: [Xen-users] 3.1.0-rc0 git snapshot crashes as dom0 (private mail))

[Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

[Xen-devel] Re: Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

[Xen-devel] Re: Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

[Xen-devel] Re: Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

[Xen-users] Re: Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

[Xen-devel] Re: [Xen-users] Re: Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

[Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

[Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

Re: [Fedora-xen] [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

Re: [Fedora-xen] [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

Re: [Fedora-xen] [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

Re: [Fedora-xen] [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

Re: [Fedora-xen] [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

Re: [Fedora-xen] [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

Re: [Fedora-xen] [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

Re: [Fedora-xen] [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)

Re: [Xen-devel] Re: [Xen-users] Continuing BUG:-iness booting Fedora Rawhide 3.1.0-rc''s (was Summary: Experiences setting up a debug serial port)