2010-07-23 03:25:19

by Qian Cai

[permalink] [raw]
Subject: 2.6.35-rc5 panic at __br_deliver+0x64/0xe0 with kvm bridge networking

I met consistently host panic when operated under kvm guest with bridge networking. I got a vmcore (unfortunately, the crash utility had some problems to analyse it fully), and full panic log is attached.

general protection fault: 0000 [#1] SMP
last sysfs file: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/PNP0C09:00/PNP0C0A:00/power_supply/BAT0/energy_full
CPU 0
Modules linked in: xfs exportfs sit tunnel4 fuse ebtable_nat ebtables rfcomm sco bridge stp llc bnep l2cap autofs4 sunrpc xt_physdev ipt_MASQUERADE iptable_nat nf_nat ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 cpufreq_ondemand acpi_cpufreq freq_table mperf dm_mirror dm_region_hash dm_log vhost_net macvtap macvlan tun kvm_intel kvm uinput usb_storage sr_mod cdrom pcspkr xhci_hcd ext4 mbcache jbd2 cryptd aes_x86_64 aes_generic xts gf128mul dm_crypt sg sd_mod crc_t10dif i2c_i801 ahci libahci arc4 iTCO_wdt ecb iTCO_vendor_support iwlagn iwlcore mac80211 cfg80211 snd_hda_codec_conexant snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd_page_alloc thinkpad_acpi hwmon snd soundcore wmi e1000e btusb bluetooth rfkill i915 drm_kms_helper drm i2c_algo_bit i2c_core video output dm_mod [last unloaded: microcode]

Pid: 1604, comm: cups-polld Not tainted 2.6.35-rc5 #1 7459H94/7459H94
RIP: 0010:[<ffffffffa061cb54>] [<ffffffffa061cb54>] __br_deliver+0x64/0xe0 [bridge]
RSP: 0018:ffff880134cbb778 EFLAGS: 00010296
RAX: 5a5a5a5a5a5a5a5a RBX: ffff880035d2c980 RCX: 0000000000000003
RDX: 0000000000001c70 RSI: ffff880125154c98 RDI: 0000000000000000
RBP: ffff880134cbb798 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: ffff88012331c288
R13: ffff88012331c2b0 R14: ffff88012e252c16 R15: ffff880035d2c000
FS: 00007ffa879807c0(0000) GS:ffff88000b000000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f99ba6c5020 CR3: 0000000125c6d000 CR4: 00000000000426f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process cups-polld (pid: 1604, threadinfo ffff880134cba000, task ffff8801251542d0)
Stack:
ffff880180000000 ffffffff81098ebd ffff88012331c288 ffff880035d2c980
<0> ffff880134cbb7a8 ffffffffa061cc05 ffff880134cbb7d8 ffffffffa061b7b4
<0> ffff88012331c288 ffffffff81c3e5c0 ffff88012331cac8 ffffffff81c3e600
Call Trace:
[<ffffffff81098ebd>] ? lock_release_holdtime+0x3d/0x190
[<ffffffffa061cc05>] br_deliver+0x35/0x40 [bridge]
[<ffffffffa061b7b4>] br_dev_xmit+0xb4/0x160 [bridge]
[<ffffffff814105bd>] dev_hard_start_xmit+0x2fd/0x450
[<ffffffff81410329>] ? dev_hard_start_xmit+0x69/0x450
[<ffffffff81050931>] ? get_parent_ip+0x11/0x50
[<ffffffff81413046>] dev_queue_xmit+0x4f6/0x7b0
[<ffffffff81412b9f>] ? dev_queue_xmit+0x4f/0x7b0
[<ffffffff810997ed>] ? trace_hardirqs_on+0xd/0x10
[<ffffffff8106a247>] ? local_bh_enable_ip+0x97/0x100
[<ffffffff8141bc63>] neigh_resolve_output+0x113/0x3f0
[<ffffffff81454e74>] ip_finish_output+0x1a4/0x4b0
[<ffffffff8145550b>] ip_output+0xbb/0x110
[<ffffffff81453e6d>] ip_local_out+0x2d/0x80
[<ffffffff81454762>] ip_queue_xmit+0x1c2/0x500
[<ffffffff814545a0>] ? ip_queue_xmit+0x0/0x500
[<ffffffff8114db77>] ? __kmalloc_node_track_caller+0x87/0x110
[<ffffffff8114d9eb>] ? kmem_cache_alloc_node_notrace+0x10b/0x210
[<ffffffff8114db77>] ? __kmalloc_node_track_caller+0x87/0x110
[<ffffffff8146a308>] tcp_transmit_skb+0x3f8/0x8a0
[<ffffffff8146bf0d>] tcp_send_ack+0xdd/0x130
[<ffffffff8145c666>] tcp_cleanup_rbuf+0x76/0x110
[<ffffffff8145ee90>] tcp_recvmsg+0x450/0xd10
[<ffffffff814837fd>] inet_recvmsg+0xcd/0xf0
[<ffffffff813fbb8d>] sock_recvmsg+0xfd/0x130
[<ffffffff813fb853>] ? sock_sendmsg+0xf3/0x130
[<ffffffff810127b9>] ? sched_clock+0x9/0x10
[<ffffffff81089435>] ? sched_clock_local+0x25/0x90
[<ffffffff81089558>] ? sched_clock_cpu+0xb8/0x110
[<ffffffff810956fd>] ? trace_hardirqs_off+0xd/0x10
[<ffffffff8108961f>] ? cpu_clock+0x6f/0x80
[<ffffffff8109979d>] ? trace_hardirqs_on_caller+0x14d/0x190
[<ffffffff810997ed>] ? trace_hardirqs_on+0xd/0x10
[<ffffffff813fbd01>] sys_recvfrom+0xe1/0x170
[<ffffffff81087662>] ? hrtimer_nanosleep+0x132/0x190
[<ffffffff8100b06a>] ? sysret_check+0x2e/0x69
[<ffffffff8109979d>] ? trace_hardirqs_on_caller+0x14d/0x190
[<ffffffff814e4ef2>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[<ffffffff8100b032>] system_call_fastpath+0x16/0x1b
Code: c9 49 c7 c1 90 ca 61 a0 4c 89 e2 be 03 00 00 00 bf 07 00 00 00 c7 04 24 00 00 00 80 e8 96 c6 e1 e0 83 f8 01 74 31 49 8b 44 24 20 <48> 8b 80 08 05 00 00 48 85 c0 74 0e 48 8b 80 d0 01 00 00 48 8b
RIP [<ffffffffa061cb54>] __br_deliver+0x64/0xe0 [bridge]
RSP <ffff880134cbb778>


Attachments:
log (89.38 kB)

2010-07-23 19:20:31

by Maciej Rutecki

[permalink] [raw]
Subject: Re: 2.6.35-rc5 panic at __br_deliver+0x64/0xe0 with kvm bridge networking

On piÄ…tek, 23 lipca 2010 o 05:25:15 [email protected] wrote:
> I met consistently host panic when operated under kvm guest with bridge
> networking. I got a vmcore (unfortunately, the crash utility had some
> problems to analyse it fully), and full panic log is attached.
>

I created a Bugzilla entry at
https://bugzilla.kernel.org/show_bug.cgi?id=16448
for your bug report, please add your address to the CC list in there, thanks!

--
Maciej Rutecki
http://www.maciek.unixy.pl