* Linux x86 guest panics in skb_copy_bits
@ 2009-05-03 18:40 Justin Dossey
2009-05-04 22:40 ` Marcelo Tosatti
0 siblings, 1 reply; 5+ messages in thread
From: Justin Dossey @ 2009-05-03 18:40 UTC (permalink / raw)
To: kvm
Hi all,
I have a pretty straightforward setup.
Hypervisor:
dual xeon e5205 running Gentoo Linux
kernel 2.6.27 with virtio devices enabled
kvm 84
libvirt 0.5.1
Guest:
32-bit, virtio for nic and disk, qcow2.
Linux 2.6.28.
Network is bridged using tap and brctl.
I'm running Apache on the guest. Whenever I send enough data through
the virtual NIC, I get a panic in skb_copy_bits. I've tried using the
e1000 driver instead of the virtio one, but that makes no difference.
Has anyone else seen this behavior before? I got this on 2.6.27 and 2.6.28.
Here's a snippet:
[280204.340016] [<c02253e2>] panic+0x4e/0xea
[280204.340016] [<c05906b9>] oops_end+0x8f/0xa3
[280204.340016] [<c0204e94>] die+0x57/0x5f
[280204.340016] [<c0592192>] do_page_fault+0x605/0x6bc
[280204.340016] [<c059010d>] ? _spin_lock+0x15/0x18
[280204.340016] [<c04bfad8>] ? __qdisc_run+0xe6/0x1a7
[280204.340016] [<c0591b8d>] ? do_page_fault+0x0/0x6bc
[280204.340016] [<c0590482>] error_code+0x72/0x78
[280204.340016] [<c04ace8c>] ? skb_copy_bits+0x4f/0x1c4
[280204.340016] [<c0215864>] ? kvm_set_pte+0x26/0x29
[280204.340016] [<c054889c>] xdr_skb_read_bits+0x1f/0x37
[280204.340016] [<c054872b>] xdr_partial_copy_from_skb+
0x117/0x16c
[280204.340016] [<c0549ec4>] xs_tcp_data_recv+0x245/0x3de
[280204.340016] [<c054887d>] ? xdr_skb_read_bits+0x0/0x37
[280204.340016] [<c04e07d6>] tcp_read_sock+0x8c/0x1e2
[280204.340016] [<c0549c7f>] ? xs_tcp_data_recv+0x0/0x3de
[280204.340016] [<c054a5d1>] xs_tcp_data_ready+0x54/0x64
[280204.340016] [<c04e9469>] tcp_rcv_established+0x524/0x7b7
[280204.340016] [<c04ee4b2>] tcp_v4_do_rcv+0x173/0x2dc
--
Justin Dossey
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Linux x86 guest panics in skb_copy_bits
2009-05-03 18:40 Linux x86 guest panics in skb_copy_bits Justin Dossey
@ 2009-05-04 22:40 ` Marcelo Tosatti
[not found] ` <ce02da610905051529w23a72a54m33218d998a36e5d0@mail.gmail.com>
0 siblings, 1 reply; 5+ messages in thread
From: Marcelo Tosatti @ 2009-05-04 22:40 UTC (permalink / raw)
To: Justin Dossey; +Cc: kvm
Justin,
On Sun, May 03, 2009 at 11:40:47AM -0700, Justin Dossey wrote:
> Hi all,
>
> I have a pretty straightforward setup.
>
> Hypervisor:
> dual xeon e5205 running Gentoo Linux
> kernel 2.6.27 with virtio devices enabled
> kvm 84
> libvirt 0.5.1
>
> Guest:
> 32-bit, virtio for nic and disk, qcow2.
> Linux 2.6.28.
>
> Network is bridged using tap and brctl.
>
> I'm running Apache on the guest. Whenever I send enough data through
> the virtual NIC, I get a panic in skb_copy_bits. I've tried using the
> e1000 driver instead of the virtio one, but that makes no difference.
>
> Has anyone else seen this behavior before? I got this on 2.6.27 and 2.6.28.
>
> Here's a snippet:
>
> [280204.340016] [<c02253e2>] panic+0x4e/0xea
> [280204.340016] [<c05906b9>] oops_end+0x8f/0xa3
> [280204.340016] [<c0204e94>] die+0x57/0x5f
> [280204.340016] [<c0592192>] do_page_fault+0x605/0x6bc
> [280204.340016] [<c059010d>] ? _spin_lock+0x15/0x18
> [280204.340016] [<c04bfad8>] ? __qdisc_run+0xe6/0x1a7
> [280204.340016] [<c0591b8d>] ? do_page_fault+0x0/0x6bc
> [280204.340016] [<c0590482>] error_code+0x72/0x78
> [280204.340016] [<c04ace8c>] ? skb_copy_bits+0x4f/0x1c4
> [280204.340016] [<c0215864>] ? kvm_set_pte+0x26/0x29
> [280204.340016] [<c054889c>] xdr_skb_read_bits+0x1f/0x37
> [280204.340016] [<c054872b>] xdr_partial_copy_from_skb+
> 0x117/0x16c
> [280204.340016] [<c0549ec4>] xs_tcp_data_recv+0x245/0x3de
> [280204.340016] [<c054887d>] ? xdr_skb_read_bits+0x0/0x37
> [280204.340016] [<c04e07d6>] tcp_read_sock+0x8c/0x1e2
> [280204.340016] [<c0549c7f>] ? xs_tcp_data_recv+0x0/0x3de
> [280204.340016] [<c054a5d1>] xs_tcp_data_ready+0x54/0x64
> [280204.340016] [<c04e9469>] tcp_rcv_established+0x524/0x7b7
> [280204.340016] [<c04ee4b2>] tcp_v4_do_rcv+0x173/0x2dc
Seems to be an issue with paravirt mmu. Do you happen to have
CONFIG_DEBUG_PAGEALLOC turned on your guests?
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Linux x86 guest panics in skb_copy_bits
[not found] ` <ce02da610905051529w23a72a54m33218d998a36e5d0@mail.gmail.com>
@ 2009-05-06 23:35 ` Justin Dossey
2009-05-07 0:16 ` Marcelo Tosatti
0 siblings, 1 reply; 5+ messages in thread
From: Justin Dossey @ 2009-05-06 23:35 UTC (permalink / raw)
To: Marcelo Tosatti, kvm
On Tue, May 5, 2009 at 3:29 PM, Justin Dossey <jbd@justindossey.com> wrote:
> On Mon, May 4, 2009 at 3:40 PM, Marcelo Tosatti <mtosatti@redhat.com> wrote:
>> Justin,
>>
>> On Sun, May 03, 2009 at 11:40:47AM -0700, Justin Dossey wrote:
> [snip]
>>
>> Seems to be an issue with paravirt mmu. Do you happen to have
>> CONFIG_DEBUG_PAGEALLOC turned on your guests?
>
> I don't, as my VMs are in production use. To find the source of this
> issue, I can turn it on though.
>
> While I'm at it, are there any other kernel features I should enable?
>
I went ahead and recompiled with CONFIG_DEBUG_PAGEALLOC enabled.
Here's the panic (77 seconds after boot!)
[ 76.911884] BUG: unable to handle kernel paging request at f4d17000
[ 76.915076] IP: [<c02856a9>] __slab_alloc+0x217/0x42f
[ 76.917161] Oops: 0002 [#1] SMP DEBUG_PAGEALLOC
[ 76.919309] last sysfs file: /sys/kernel/uevent_seqnum
[ 76.920015] Modules linked in:
[ 76.920015]
[ 76.920015] Pid: 4632, comm: ruby18 Not tainted (2.6.28-gentoo-r4 #2)
[ 76.920015] EIP: 0060:[<c02856a9>] EFLAGS: 00210086 CPU: 0
[ 76.920015] EIP is at __slab_alloc+0x217/0x42f
[ 76.920015] EAX: c0761564 EBX: c1abb740 ECX: c0761564 EDX: 00000000
[ 76.920015] ESI: f4d17800 EDI: f4d17000 EBP: f72e9b8c ESP: f72e9b6c
[ 76.920015] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[ 76.920015] Process ruby18 (pid: 4632, ti=f72e8000 task=f721d8e0
task.ti=f72e8000)
[ 76.920015] Stack:
[ 76.920015] ffffffff 00000020 c0761564 00000000 f4d10000 00000000
00200282 c0761564
[ 76.920015] f72e9bb4 c02867a5 c04b6782 c2a202a8 c04b6782 00000020
00000800 f70583c0
[ 76.920015] 00000600 f70583c0 f72e9bd4 c04b5948 00000000 00000020
c0760f58 00000020
[ 76.920015] Call Trace:
[ 76.920015] [<c02867a5>] ? __kmalloc_track_caller+0x89/0xda
[ 76.920015] [<c04b6782>] ? __netdev_alloc_skb+0x17/0x34
[ 76.920015] [<c04b6782>] ? __netdev_alloc_skb+0x17/0x34
[ 76.920015] [<c04b5948>] ? __alloc_skb+0x4f/0xfb
[ 76.920015] [<c04b6782>] ? __netdev_alloc_skb+0x17/0x34
[ 76.920015] [<c0452583>] ? try_fill_recv+0x30/0x177
[ 76.920015] [<c04b37a1>] ? sock_def_readable+0x5e/0x63
[ 76.920015] [<c0453237>] ? virtnet_poll+0x25c/0x309
[ 76.920015] [<c04bc32e>] ? net_rx_action+0xbd/0x1ea
[ 76.920015] [<c022b2ed>] ? __do_softirq+0x83/0x12e
[ 76.920015] [<c022b3e0>] ? do_softirq+0x48/0x57
[ 76.920015] [<c022b6fa>] ? irq_exit+0x38/0x6d
[ 76.920015] [<c0205868>] ? do_IRQ+0x96/0xae
[ 76.920015] [<c020471b>] ? common_interrupt+0x23/0x28
[ 76.920015] [<c0274379>] ? copy_page_range+0x25c/0x51e
[ 76.920015] [<c0225731>] ? dup_mm+0x22a/0x30c
[ 76.920015] [<c0226141>] ? copy_process+0x906/0x1026
[ 76.920015] [<c02269a0>] ? do_fork+0xd6/0x21f
[ 76.920015] [<c03ae3e0>] ? copy_to_user+0x2a/0x36
[ 76.920015] [<c0202236>] ? sys_clone+0x25/0x2a
[ 76.920015] [<c0203bd2>] ? syscall_call+0x7/0xb
[ 76.920015] Code: c1 e9 02 f3 ab f6 c2 02 74 02 66 ab f6 c2 01 74
01 aa 8b 7d f0 89 fe eb 19 8b 45 e8 89 f9 89 da e8 4d ee ff ff 8b 4d
e8 03 79 0c <89> 37 89 f7 03 71 04 8b 55 e8 0f b7 43 0a 0f af 42 04 03
45f0
[ 76.920015] EIP: [<c02856a9>] __slab_alloc+0x217/0x42f SS:ESP 0068:f72e9b6c
[ 76.920015] Kernel panic - not syncing: Fatal exception in interrupt
[ 76.920015] ------------[ cut here ]------------
[ 76.920015] WARNING: at kernel/smp.c:333 smp_call_function_mask+0x33/0x185()
[ 76.920015] Modules linked in:
[ 76.920015] Pid: 4632, comm: ruby18 Tainted: G D 2.6.28-gentoo-r4 #2
[ 76.920015] Call Trace:
[ 76.920015] [<c022735a>] warn_on_slowpath+0x41/0x5b
[ 76.920015] [<c03ada5e>] ? __delay+0x9/0xb
[ 76.920015] [<c0405af6>] ? serial8250_console_write+0xd6/0xea
[ 76.920015] [<c03b12f7>] ? _raw_spin_unlock+0x8e/0x92
[ 76.920015] [<c0586f9c>] ? _spin_unlock+0x1d/0x20
[ 76.920015] [<c03b1457>] ? _raw_spin_lock+0x60/0xf5
[ 76.920015] [<c023af8e>] ? up+0x2b/0x2f
[ 76.920015] [<c03b12f7>] ? _raw_spin_unlock+0x8e/0x92
[ 76.920015] [<c022797f>] ? release_console_sem+0x185/0x198
[ 76.920015] [<c03b12f7>] ? _raw_spin_unlock+0x8e/0x92
[ 76.920015] [<c022798a>] ? release_console_sem+0x190/0x198
[ 76.920015] [<c0246630>] smp_call_function_mask+0x33/0x185
[ 76.920015] [<c02100e4>] ? stop_this_cpu+0x0/0x50
[ 76.920015] [<c0585ca3>] ? mutex_unlock+0x8/0xa
[ 76.920015] [<c0585ca3>] ? mutex_unlock+0x8/0xa
[ 76.920015] [<c024f4cd>] ? crash_kexec+0x9f/0xa7
[ 76.920015] [<c0585ca3>] ? mutex_unlock+0x8/0xa
[ 76.920015] [<c024f4cd>] ? crash_kexec+0x9f/0xa7
[ 76.920015] [<c0246794>] smp_call_function+0x12/0x14
[ 76.920015] [<c0210183>] native_smp_send_stop+0x1b/0x45
[ 76.920015] [<c02273d0>] panic+0x4e/0xef
[ 76.920015] [<c0587e2e>] oops_end+0x8f/0xa3
[ 76.920015] [<c0205c87>] die+0x57/0x5f
[ 76.920015] [<c0589477>] do_page_fault+0x63e/0x6fa
[ 76.920015] [<c0268c84>] ? __alloc_pages_internal+0xad/0x33a
[ 76.920015] [<c0588e39>] ? do_page_fault+0x0/0x6fa
[ 76.920015] [<c05874fa>] error_code+0x72/0x78
[ 76.920015] [<c02856a9>] ? __slab_alloc+0x217/0x42f
[ 76.920015] [<c02867a5>] __kmalloc_track_caller+0x89/0xda
[ 76.920015] [<c04b6782>] ? __netdev_alloc_skb+0x17/0x34
[ 76.920015] [<c04b6782>] ? __netdev_alloc_skb+0x17/0x34
[ 76.920015] [<c04b5948>] __alloc_skb+0x4f/0xfb
[ 76.920015] [<c04b6782>] __netdev_alloc_skb+0x17/0x34
[ 76.920015] [<c0452583>] try_fill_recv+0x30/0x177
[ 76.920015] [<c04b37a1>] ? sock_def_readable+0x5e/0x63
[ 76.920015] [<c0453237>] virtnet_poll+0x25c/0x309
[ 76.920015] [<c04bc32e>] net_rx_action+0xbd/0x1ea
[ 76.920015] [<c022b2ed>] __do_softirq+0x83/0x12e
[ 76.920015] [<c022b3e0>] do_softirq+0x48/0x57
[ 76.920015] [<c022b6fa>] irq_exit+0x38/0x6d
[ 76.920015] [<c0205868>] do_IRQ+0x96/0xae
[ 76.920015] [<c020471b>] common_interrupt+0x23/0x28
[ 76.920015] [<c0274379>] ? copy_page_range+0x25c/0x51e
[ 76.920015] [<c0225731>] dup_mm+0x22a/0x30c
[ 76.920015] [<c0226141>] copy_process+0x906/0x1026
[ 76.920015] [<c02269a0>] do_fork+0xd6/0x21f
[ 76.920015] [<c03ae3e0>] ? copy_to_user+0x2a/0x36
[ 76.920015] [<c0202236>] sys_clone+0x25/0x2a
[ 76.920015] [<c0203bd2>] syscall_call+0x7/0xb
[ 76.920015] ---[ end trace 4656f6f379527461 ]---
--
Justin Dossey
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Linux x86 guest panics in skb_copy_bits
2009-05-06 23:35 ` Justin Dossey
@ 2009-05-07 0:16 ` Marcelo Tosatti
2009-05-11 17:57 ` Justin Dossey
0 siblings, 1 reply; 5+ messages in thread
From: Marcelo Tosatti @ 2009-05-07 0:16 UTC (permalink / raw)
To: Justin Dossey; +Cc: kvm
Justin,
On Wed, May 06, 2009 at 04:35:24PM -0700, Justin Dossey wrote:
> On Tue, May 5, 2009 at 3:29 PM, Justin Dossey <jbd@justindossey.com> wrote:
> > On Mon, May 4, 2009 at 3:40 PM, Marcelo Tosatti <mtosatti@redhat.com> wrote:
> >> Justin,
> >>
> >> On Sun, May 03, 2009 at 11:40:47AM -0700, Justin Dossey wrote:
> > [snip]
> >>
> >> Seems to be an issue with paravirt mmu. Do you happen to have
> >> CONFIG_DEBUG_PAGEALLOC turned on your guests?
> >
> > I don't, as my VMs are in production use. To find the source of this
> > issue, I can turn it on though.
> >
> > While I'm at it, are there any other kernel features I should enable?
> >
>
> I went ahead and recompiled with CONFIG_DEBUG_PAGEALLOC enabled.
> Here's the panic (77 seconds after boot!)
>
> [ 76.911884] BUG: unable to handle kernel paging request at f4d17000
> [ 76.915076] IP: [<c02856a9>] __slab_alloc+0x217/0x42f
> [ 76.917161] Oops: 0002 [#1] SMP DEBUG_PAGEALLOC
> [ 76.919309] last sysfs file: /sys/kernel/uevent_seqnum
> [ 76.920015] Modules linked in:
> [ 76.920015]
> [ 76.920015] Pid: 4632, comm: ruby18 Not tainted (2.6.28-gentoo-r4 #2)
> [ 76.920015] EIP: 0060:[<c02856a9>] EFLAGS: 00210086 CPU: 0
> [ 76.920015] EIP is at __slab_alloc+0x217/0x42f
> [ 76.920015] EAX: c0761564 EBX: c1abb740 ECX: c0761564 EDX: 00000000
> [ 76.920015] ESI: f4d17800 EDI: f4d17000 EBP: f72e9b8c ESP: f72e9b6c
> [ 76.920015] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
> [ 76.920015] Process ruby18 (pid: 4632, ti=f72e8000 task=f721d8e0
> task.ti=f72e8000)
> [ 76.920015] Stack:
> [ 76.920015] ffffffff 00000020 c0761564 00000000 f4d10000 00000000
> 00200282 c0761564
> [ 76.920015] f72e9bb4 c02867a5 c04b6782 c2a202a8 c04b6782 00000020
> 00000800 f70583c0
> [ 76.920015] 00000600 f70583c0 f72e9bd4 c04b5948 00000000 00000020
> c0760f58 00000020
> [ 76.920015] Call Trace:
> [ 76.920015] [<c02867a5>] ? __kmalloc_track_caller+0x89/0xda
> [ 76.920015] [<c04b6782>] ? __netdev_alloc_skb+0x17/0x34
> [ 76.920015] [<c04b6782>] ? __netdev_alloc_skb+0x17/0x34
> [ 76.920015] [<c04b5948>] ? __alloc_skb+0x4f/0xfb
> [ 76.920015] [<c04b6782>] ? __netdev_alloc_skb+0x17/0x34
> [ 76.920015] [<c0452583>] ? try_fill_recv+0x30/0x177
> [ 76.920015] [<c04b37a1>] ? sock_def_readable+0x5e/0x63
> [ 76.920015] [<c0453237>] ? virtnet_poll+0x25c/0x309
> [ 76.920015] [<c04bc32e>] ? net_rx_action+0xbd/0x1ea
> [ 76.920015] [<c022b2ed>] ? __do_softirq+0x83/0x12e
> [ 76.920015] [<c022b3e0>] ? do_softirq+0x48/0x57
> [ 76.920015] [<c022b6fa>] ? irq_exit+0x38/0x6d
> [ 76.920015] [<c0205868>] ? do_IRQ+0x96/0xae
> [ 76.920015] [<c020471b>] ? common_interrupt+0x23/0x28
> [ 76.920015] [<c0274379>] ? copy_page_range+0x25c/0x51e
> [ 76.920015] [<c0225731>] ? dup_mm+0x22a/0x30c
> [ 76.920015] [<c0226141>] ? copy_process+0x906/0x1026
> [ 76.920015] [<c02269a0>] ? do_fork+0xd6/0x21f
> [ 76.920015] [<c03ae3e0>] ? copy_to_user+0x2a/0x36
> [ 76.920015] [<c0202236>] ? sys_clone+0x25/0x2a
> [ 76.920015] [<c0203bd2>] ? syscall_call+0x7/0xb
> [ 76.920015] Code: c1 e9 02 f3 ab f6 c2 02 74 02 66 ab f6 c2 01 74
> 01 aa 8b 7d f0 89 fe eb 19 8b 45 e8 89 f9 89 da e8 4d ee ff ff 8b 4d
> e8 03 79 0c <89> 37 89 f7 03 71 04 8b 55 e8 0f b7 43 0a 0f af 42 04 03
> 45f0
OK, so you're original report contains a different bug. You can disable
CONFIG_KVM_GUEST in the meantime as a workaround, until the bug is
fixed.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Linux x86 guest panics in skb_copy_bits
2009-05-07 0:16 ` Marcelo Tosatti
@ 2009-05-11 17:57 ` Justin Dossey
0 siblings, 0 replies; 5+ messages in thread
From: Justin Dossey @ 2009-05-11 17:57 UTC (permalink / raw)
To: Marcelo Tosatti, kvm
On Wed, May 6, 2009 at 5:16 PM, Marcelo Tosatti <mtosatti@redhat.com> wrote:
> Justin,
[snip]
> OK, so you're original report contains a different bug. You can disable
> CONFIG_KVM_GUEST in the meantime as a workaround, until the bug is
> fixed.
>
Disabling CONFIG_KVM_GUEST gives me a new panic. I'm going to try
disabling SMP.
[ 71.470022] ------------[ cut here ]------------
[ 71.470022] WARNING: at kernel/smp.c:333 smp_call_function_mask+0x33/0x185()
[ 71.470022] Modules linked in:
[ 71.470022] Pid: 4618, comm: ruby18 Tainted: G D 2.6.28-gentoo-r4 #3
[ 71.470022] Call Trace:
[ 71.470022] [<c022735a>] warn_on_slowpath+0x41/0x5b
[ 71.470022] [<c03ada5e>] ? __delay+0x9/0xb
[ 71.470022] [<c0405af6>] ? serial8250_console_write+0xd6/0xea
[ 71.470022] [<c03b12f7>] ? _raw_spin_unlock+0x8e/0x92
[ 71.470022] [<c0586f9c>] ? _spin_unlock+0x1d/0x20
[ 71.470022] [<c03b1457>] ? _raw_spin_lock+0x60/0xf5
[ 71.470022] [<c023af8e>] ? up+0x2b/0x2f
[ 71.470022] [<c03b12f7>] ? _raw_spin_unlock+0x8e/0x92
[ 71.470022] [<c022797f>] ? release_console_sem+0x185/0x198
[ 71.470022] [<c03b12f7>] ? _raw_spin_unlock+0x8e/0x92
[ 71.470022] [<c022798a>] ? release_console_sem+0x190/0x198
[ 71.470022] [<c0246630>] smp_call_function_mask+0x33/0x185
[ 71.470022] [<c02100e4>] ? stop_this_cpu+0x0/0x50
[ 71.470022] [<c0585ca3>] ? mutex_unlock+0x8/0xa
[ 71.470022] [<c0585ca3>] ? mutex_unlock+0x8/0xa
[ 71.470022] [<c024f4cd>] ? crash_kexec+0x9f/0xa7
[ 71.470022] [<c0585ca3>] ? mutex_unlock+0x8/0xa
[ 71.470022] [<c024f4cd>] ? crash_kexec+0x9f/0xa7
[ 71.470022] [<c0246794>] smp_call_function+0x12/0x14
[ 71.470022] [<c0210183>] native_smp_send_stop+0x1b/0x45
[ 71.470022] [<c02273d0>] panic+0x4e/0xef
[ 71.470022] [<c0587e2e>] oops_end+0x8f/0xa3
[ 71.470022] [<c0205c87>] die+0x57/0x5f
[ 71.470022] [<c0589477>] do_page_fault+0x63e/0x6fa
[ 71.470022] [<c0268c84>] ? __alloc_pages_internal+0xad/0x33a
[ 71.470022] [<c0588e39>] ? do_page_fault+0x0/0x6fa
[ 71.470022] [<c05874fa>] error_code+0x72/0x78
[ 71.470022] [<c02856a9>] ? __slab_alloc+0x217/0x42f
[ 71.470022] [<c02867a5>] __kmalloc_track_caller+0x89/0xda
[ 71.470022] [<c04b6782>] ? __netdev_alloc_skb+0x17/0x34
[ 71.470022] [<c04b6782>] ? __netdev_alloc_skb+0x17/0x34
[ 71.470022] [<c04b5948>] __alloc_skb+0x4f/0xfb
[ 71.470022] [<c04b6782>] __netdev_alloc_skb+0x17/0x34
[ 71.470022] [<c0452583>] try_fill_recv+0x30/0x177
[ 71.470022] [<c0221a45>] ? try_to_wake_up+0x200/0x20b
[ 71.470022] [<c0453237>] virtnet_poll+0x25c/0x309
[ 71.470022] [<c04bc32e>] net_rx_action+0xbd/0x1ea
[ 71.470022] [<c022b2ed>] __do_softirq+0x83/0x12e
[ 71.470022] [<c022b3e0>] do_softirq+0x48/0x57
[ 71.470022] [<c022b6fa>] irq_exit+0x38/0x6d
[ 71.470022] [<c0205868>] do_IRQ+0x96/0xae
[ 71.470022] [<c020471b>] common_interrupt+0x23/0x28
[ 71.470022] [<c03b00d8>] ? sg_miter_start+0x14/0x3b
[ 71.470022] [<c02681a1>] ? free_hot_cold_page+0x12f/0x1ef
[ 71.470022] [<c0268298>] free_hot_page+0xa/0xc
[ 71.470022] [<c026b6ef>] put_page+0xd2/0xd7
[ 71.470022] [<c027bd56>] free_page_and_swap_cache+0x32/0x38
[ 71.470022] [<c0271dfc>] unmap_vmas+0x3fd/0x698
[ 71.470022] [<c03b1457>] ? _raw_spin_lock+0x60/0xf5
[ 71.470022] [<c02758f4>] unmap_region+0x8e/0xf5
[ 71.470022] [<c02762ad>] do_munmap+0x188/0x1de
[ 71.470022] [<c02771b5>] sys_munmap+0x30/0x3f
[ 71.470022] [<c0203bd2>] syscall_call+0x7/0xb
[ 71.470022] ---[ end trace 7e1609da76631ce2 ]---
--
Justin Dossey
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2009-05-11 17:57 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-05-03 18:40 Linux x86 guest panics in skb_copy_bits Justin Dossey
2009-05-04 22:40 ` Marcelo Tosatti
[not found] ` <ce02da610905051529w23a72a54m33218d998a36e5d0@mail.gmail.com>
2009-05-06 23:35 ` Justin Dossey
2009-05-07 0:16 ` Marcelo Tosatti
2009-05-11 17:57 ` Justin Dossey
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.