3.0.0 and gplpv

[jim burns]

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)'

[James Harper]

>
> 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

[jim burns]

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.

[jim burns]

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 :) )

[James Harper]

>
> 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

[jim burns]

> 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
***@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)

[jim burns]

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

[jim burns]

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.

[jim burns]

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 (***@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
> > (***@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.

[jim burns]

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.

[jim burns]

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.

[jim burns]

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

[Todd Deshane]

(adding fedora-xen to the CC)

On Tue, Aug 30, 2011 at 5:17 PM, jim burns <***@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-***@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/

[jim burns]

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 <***@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.

[Pasi Kärkkäinen]

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

[jim burns]

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:).

[Pasi Kärkkäinen]

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 (***@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-***@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 <***@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 <***@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 ***@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 ***@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.

[jim burns]

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.

[Pasi Kärkkäinen]

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

[jim burns]

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 (***@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
(***@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.

[jim burns]

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.

[Konrad Rzeszutek Wilk]

> 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?

[Konrad Rzeszutek Wilk]

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 <***@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 <***@citrix.com>
Signed-off-by: Konrad Rzeszutek 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));

[jim burns]

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 <***@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.

[Konrad Rzeszutek Wilk]

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 <***@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.

[jim burns]

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.

[M A Young]

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 <***@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

[jim burns]

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.

[Konrad Rzeszutek Wilk]

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?

[Konrad Rzeszutek Wilk]

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 <***@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

[jim burns]

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:

***@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
***@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
***@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:

***@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 ]---

[Konrad Rzeszutek Wilk]

> 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.

>
> ***@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
> ***@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
> ***@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.

> ***@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..

[jim burns]

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.
>
> > ***@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
> > ***@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
> > ***@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.)

> > ***@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.

[jim burns]

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.

[jim burns]

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:

***@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:

***@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:

***@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:

***@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.

[Pasi Kärkkäinen]

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

[jim burns]

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.

[Pasi Kärkkäinen]

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

[jim burns]

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.

[Pasi Kärkkäinen]

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

[jim burns]

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!)

[Pasi Kärkkäinen]

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

[jim burns]

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.

[jim burns]

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.

[Pasi Kärkkäinen]

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

[Ian Campbell]

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-***@lists.xensource.com
> http://lists.xensource.com/xen-devel

[Pasi Kärkkäinen]

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

[jim burns]

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

[Pasi Kärkkäinen]

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

[jim burns]

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.

[Boris Derzhavets]

> 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 <***@bellsouth.net> wrote:

From: jim burns <***@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" <***@iki.fi>
Cc: "xen-***@lists.xensource.com" <xen-***@lists.xensource.com>, "Ian Campbell" <***@citrix.com>, "xen-***@lists.xensource.com" <xen-***@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.

[jim burns]

> 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.

[Boris Derzhavets]

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 <***@bellsouth.net> wrote:

From: jim burns <***@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" <***@yahoo.com>
Cc: "xen-***@lists.xensource.com" <xen-***@lists.xensource.com>, "Ian Campbell" <***@citrix.com>, "Pasi Kärkkäinen" <***@iki.fi>, "xen-***@lists.xensource.com" <xen-***@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.

[Pasi Kärkkäinen]

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 <***@bellsouth.net> wrote:
>
> From: jim burns <***@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" <***@yahoo.com>
> Cc: "xen-***@lists.xensource.com" <xen-***@lists.xensource.com>, "Ian
> Campbell" <***@citrix.com>, "Pasi Kärkkäinen" <***@iki.fi>,
> "xen-***@lists.xensource.com" <xen-***@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-***@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-***@lists.xensource.com
> 5. http://lists.xensource.com/xen-users

[Konrad Rzeszutek Wilk]

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?

[M A Young]

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

[jim burns]

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!)

[Boris Derzhavets]

What kernel are you running ?

Boris.

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

From: jim burns <***@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" <***@durham.ac.uk>
Cc: "Konrad Rzeszutek Wilk" <***@oracle.com>, "Boris Derzhavets" <***@yahoo.com>, "xen-***@lists.xensource.com" <xen-***@lists.xensource.com>, "Ian Campbell" <***@citrix.com>, "xen-***@lists.xensource.com" <xen-***@lists.xensource.com>, "Pasi Kärkkäinen" <***@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!)

[jim burns]

> 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.

[Boris Derzhavets]

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 <***@bellsouth.net> wrote:

From: jim burns <***@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" <***@yahoo.com>
Cc: "xen-***@lists.xensource.com" <xen-***@lists.xensource.com>, "Ian Campbell" <***@citrix.com>, "Konrad Rzeszutek Wilk" <***@oracle.com>, "Pasi Kärkkäinen" <***@iki.fi>, "M A Young" <***@durham.ac.uk>, "xen-***@lists.xensource.com" <xen-***@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.

[jim burns]

> 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.

***@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.

[Boris Derzhavets]

kernel    /xen.gz    cpufreq=xen

Thank you very much.
I logged into Xen Host.

Boris.

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

From: jim burns <***@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" <***@yahoo.com>
Cc: "xen-***@lists.xensource.com" <xen-***@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.

***@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.

[M A Young]

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

[Boris Derzhavets]

After yum install xen my environment :-

[***@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

[***@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 <***@durham.ac.uk> wrote:

From: 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" <***@oracle.com>
Cc: "Boris Derzhavets" <***@yahoo.com>, "xen-***@lists.xensource.com" <xen-***@lists.xensource.com>, "xen-***@lists.xensource.com" <xen-***@lists.xensource.com>, "Ian Campbell" <***@citrix.com>, "jim burns" <***@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-----

[Boris Derzhavets]

Sorry,

Black screen and  NO GDM login

Boris

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

From: Boris Derzhavets <***@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" <***@oracle.com>, "M A Young" <***@durham.ac.uk>
Cc: "jim burns" <***@bellsouth.net>, "xen-***@lists.xensource.com" <xen-***@lists.xensource.com>, "xen-***@lists.xensource.com" <xen-***@lists.xensource.com>, "Ian Campbell" <***@citrix.com>
Date: Tuesday, August 2, 2011, 2:34 PM

After yum install xen my environment :-

[***@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

[***@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 <***@durham.ac.uk> wrote:

From: 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" <***@oracle.com>
Cc: "Boris Derzhavets" <***@yahoo.com>, "xen-***@lists.xensource.com" <xen-***@lists.xensource.com>, "xen-***@lists.xensource.com" <xen-***@lists.xensource.com>, "Ian Campbell" <***@citrix.com>, "jim burns" <***@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-***@lists.xensource.com
http://lists.xensource.com/xen-users
-----Inline Attachment Follows-----

[Konrad Rzeszutek Wilk]

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.

[Boris Derzhavets]

After yum install xen my environment on F15 is :-

[***@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

[***@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.

[Pasi Kärkkäinen]

On Tue, Aug 02, 2011 at 12:37:19PM -0700, Boris Derzhavets wrote:
> After yum install xen my environment on F15 is :-
>
> [***@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
>
> [***@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

[Boris Derzhavets]

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 <***@iki.fi> wrote:

From: Pasi Kärkkäinen <***@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" <***@yahoo.com>
Cc: "xen-***@lists.xensource.com" <xen-***@lists.xensource.com>, "Ian Campbell" <***@citrix.com>, "jim burns" <***@bellsouth.net>, "Konrad Rzeszutek Wilk" <***@oracle.com>, "M A Young" <***@durham.ac.uk>, "xen-***@lists.xensource.com" <xen-***@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 :-
>
>    [***@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
>
>    [***@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

[Pasi Kärkkäinen]

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