All of lore.kernel.org
 help / color / mirror / Atom feed
* BUG: unable to handle kernel paging request at 0000000000003360 RIP: e030:[<ffffffff817bf0f6>] [<ffffffff817bf0f6>] xenvif_free+0x76/0x130
@ 2014-06-06  9:18 Sander Eikelenboom
  2014-06-06  9:33 ` Zoltan Kiss
  0 siblings, 1 reply; 8+ messages in thread
From: Sander Eikelenboom @ 2014-06-06  9:18 UTC (permalink / raw)
  To: ian.campbell, Wei Liu; +Cc: xen-devel@lists.xenproject.org

While trying to do some more testing around another crash .. i stumbled upon 
this one:

[  345.470718] BUG: unable to handle kernel paging request at 0000000000003360
[  345.499053] IP: [<ffffffff817bf0f6>] xenvif_free+0x76/0x130
[  345.522732] PGD 358f2067 PUD 37e24067 PMD 0
[  345.542478] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
[  345.563071] Modules linked in:
[  345.579180] CPU: 3 PID: 45 Comm: xenwatch Not tainted 3.15.0-rc8-20140602-net-xendev-bt-mq+ #1
[  345.612170] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640)  , BIOS V1.8B1 09/13/2010
[  345.643065] task: ffff8800593b5ff0 ti: ffff8800593bc000 task.ti: ffff8800593bc000
[  345.672641] RIP: e030:[<ffffffff817bf0f6>]  [<ffffffff817bf0f6>] xenvif_free+0x76/0x130
[  345.703852] RSP: e02b:ffff8800593bfc28  EFLAGS: 00010246
[  345.727076] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006
[  345.755788] RDX: 0000000000000006 RSI: ffff8800593b6810 RDI: ffff8800259238c8
[  345.784424] RBP: ffff8800593bfc68 R08: 0000000000000000 R09: 0000000000000000
[  345.812987] R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
[  345.841582] R13: 000000000000001e R14: 0000000000000000 R15: 0000000000000000
[  345.870065] FS:  00007f4d54a57700(0000) GS:ffff88005f6c0000(0000) knlGS:0000000000000000
[  345.901412] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[  345.925621] CR2: 0000000000003360 CR3: 0000000036d9f000 CR4: 0000000000000660
[  345.954129] Stack:
[  345.967337]  0000000000145980 ffff880025923d20 ffff88002595ef28 ffff8800258767a8
[  345.996573]  ffff88002595eee8 ffff88002595ef28 ffff88002595ef28 0000000000000000
[  346.025715]  ffff8800593bfc98 ffffffff817bd9d2 ffff8800593bfc98 ffff88002595ef28
[  346.054781] Call Trace:
[  346.069218]  [<ffffffff817bd9d2>] netback_remove+0x72/0xa0
[  346.093003]  [<ffffffff815813ad>] xenbus_dev_remove+0x3d/0x70
[  346.117571]  [<ffffffff816e9d39>] __device_release_driver+0x69/0xd0
[  346.143518]  [<ffffffff816e9dce>] device_release_driver+0x2e/0x40
[  346.168761]  [<ffffffff816e984b>] bus_remove_device+0x11b/0x160
[  346.193630]  [<ffffffff816e6bdf>] device_del+0x12f/0x1c0
[  346.216612]  [<ffffffff816e6c86>] device_unregister+0x16/0x30
[  346.240830]  [<ffffffff817bdab6>] frontend_changed+0xb6/0x100
[  346.264969]  [<ffffffff81581320>] xenbus_otherend_changed+0xb0/0xc0
[  346.290657]  [<ffffffff8157fe40>] ? xenbus_thread+0x2a0/0x2a0
[  346.314756]  [<ffffffff81581c20>] frontend_changed+0x10/0x20
[  346.338585]  [<ffffffff8157fe85>] xenwatch_thread+0x45/0x130
[  346.362334]  [<ffffffff8110cac0>] ? __init_waitqueue_head+0x60/0x60
[  346.387798]  [<ffffffff810ee3b4>] kthread+0xe4/0x100
[  346.409261]  [<ffffffff810ee2d0>] ? __init_kthread_worker+0x70/0x70
[  346.434570]  [<ffffffff81b9e4fc>] ret_from_fork+0x7c/0xb0
[  346.457333]  [<ffffffff810ee2d0>] ? __init_kthread_worker+0x70/0x70
[  346.482846] Code: 48 83 c0 01 48 69 c0 40 64 03 00 48 89 45 c0 66 0f 1f 44 00 00 48 8b 45 c8 31 db 4c 8b 60 20 4d 01 f4 0f 1f 00 45 31 ff 49 63 c7 <41> 83 bc 84 60 33 00 00 ff 74 3f bf e8 03 00 00 83 c3 01 e8 92
[  346.552521] RIP  [<ffffffff817bf0f6>] xenvif_free+0x76/0x130
[  346.576381]  RSP <ffff8800593bfc28>
[  346.593562] CR2: 0000000000003360
[  346.610384] ---[ end trace 83c5864024a0a3c4 ]---

That's on a kernel with xen 3.16 dev pulled in and the netback multiqueue series 
applied, haven't seen it before while using this kernel .. so i don't know if i 
can reproduce.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: BUG: unable to handle kernel paging request at 0000000000003360 RIP: e030:[<ffffffff817bf0f6>] [<ffffffff817bf0f6>] xenvif_free+0x76/0x130
  2014-06-06  9:18 BUG: unable to handle kernel paging request at 0000000000003360 RIP: e030:[<ffffffff817bf0f6>] [<ffffffff817bf0f6>] xenvif_free+0x76/0x130 Sander Eikelenboom
@ 2014-06-06  9:33 ` Zoltan Kiss
  2014-06-06  9:57   ` Sander Eikelenboom
  0 siblings, 1 reply; 8+ messages in thread
From: Zoltan Kiss @ 2014-06-06  9:33 UTC (permalink / raw)
  To: Sander Eikelenboom, ian.campbell, Wei Liu; +Cc: xen-devel@lists.xenproject.org

Hi,

Can you please do an "addr2line -e [your vmlinuz] ffffffff817bf0f6" to 
figure out which line is causing the issue?

Thanks,

Zoli

On 06/06/14 10:18, Sander Eikelenboom wrote:
> While trying to do some more testing around another crash .. i stumbled upon
> this one:
>
> [  345.470718] BUG: unable to handle kernel paging request at 0000000000003360
> [  345.499053] IP: [<ffffffff817bf0f6>] xenvif_free+0x76/0x130
> [  345.522732] PGD 358f2067 PUD 37e24067 PMD 0
> [  345.542478] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
> [  345.563071] Modules linked in:
> [  345.579180] CPU: 3 PID: 45 Comm: xenwatch Not tainted 3.15.0-rc8-20140602-net-xendev-bt-mq+ #1
> [  345.612170] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640)  , BIOS V1.8B1 09/13/2010
> [  345.643065] task: ffff8800593b5ff0 ti: ffff8800593bc000 task.ti: ffff8800593bc000
> [  345.672641] RIP: e030:[<ffffffff817bf0f6>]  [<ffffffff817bf0f6>] xenvif_free+0x76/0x130
> [  345.703852] RSP: e02b:ffff8800593bfc28  EFLAGS: 00010246
> [  345.727076] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006
> [  345.755788] RDX: 0000000000000006 RSI: ffff8800593b6810 RDI: ffff8800259238c8
> [  345.784424] RBP: ffff8800593bfc68 R08: 0000000000000000 R09: 0000000000000000
> [  345.812987] R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
> [  345.841582] R13: 000000000000001e R14: 0000000000000000 R15: 0000000000000000
> [  345.870065] FS:  00007f4d54a57700(0000) GS:ffff88005f6c0000(0000) knlGS:0000000000000000
> [  345.901412] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> [  345.925621] CR2: 0000000000003360 CR3: 0000000036d9f000 CR4: 0000000000000660
> [  345.954129] Stack:
> [  345.967337]  0000000000145980 ffff880025923d20 ffff88002595ef28 ffff8800258767a8
> [  345.996573]  ffff88002595eee8 ffff88002595ef28 ffff88002595ef28 0000000000000000
> [  346.025715]  ffff8800593bfc98 ffffffff817bd9d2 ffff8800593bfc98 ffff88002595ef28
> [  346.054781] Call Trace:
> [  346.069218]  [<ffffffff817bd9d2>] netback_remove+0x72/0xa0
> [  346.093003]  [<ffffffff815813ad>] xenbus_dev_remove+0x3d/0x70
> [  346.117571]  [<ffffffff816e9d39>] __device_release_driver+0x69/0xd0
> [  346.143518]  [<ffffffff816e9dce>] device_release_driver+0x2e/0x40
> [  346.168761]  [<ffffffff816e984b>] bus_remove_device+0x11b/0x160
> [  346.193630]  [<ffffffff816e6bdf>] device_del+0x12f/0x1c0
> [  346.216612]  [<ffffffff816e6c86>] device_unregister+0x16/0x30
> [  346.240830]  [<ffffffff817bdab6>] frontend_changed+0xb6/0x100
> [  346.264969]  [<ffffffff81581320>] xenbus_otherend_changed+0xb0/0xc0
> [  346.290657]  [<ffffffff8157fe40>] ? xenbus_thread+0x2a0/0x2a0
> [  346.314756]  [<ffffffff81581c20>] frontend_changed+0x10/0x20
> [  346.338585]  [<ffffffff8157fe85>] xenwatch_thread+0x45/0x130
> [  346.362334]  [<ffffffff8110cac0>] ? __init_waitqueue_head+0x60/0x60
> [  346.387798]  [<ffffffff810ee3b4>] kthread+0xe4/0x100
> [  346.409261]  [<ffffffff810ee2d0>] ? __init_kthread_worker+0x70/0x70
> [  346.434570]  [<ffffffff81b9e4fc>] ret_from_fork+0x7c/0xb0
> [  346.457333]  [<ffffffff810ee2d0>] ? __init_kthread_worker+0x70/0x70
> [  346.482846] Code: 48 83 c0 01 48 69 c0 40 64 03 00 48 89 45 c0 66 0f 1f 44 00 00 48 8b 45 c8 31 db 4c 8b 60 20 4d 01 f4 0f 1f 00 45 31 ff 49 63 c7 <41> 83 bc 84 60 33 00 00 ff 74 3f bf e8 03 00 00 83 c3 01 e8 92
> [  346.552521] RIP  [<ffffffff817bf0f6>] xenvif_free+0x76/0x130
> [  346.576381]  RSP <ffff8800593bfc28>
> [  346.593562] CR2: 0000000000003360
> [  346.610384] ---[ end trace 83c5864024a0a3c4 ]---
>
> That's on a kernel with xen 3.16 dev pulled in and the netback multiqueue series
> applied, haven't seen it before while using this kernel .. so i don't know if i
> can reproduce.
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: BUG: unable to handle kernel paging request at 0000000000003360 RIP: e030:[<ffffffff817bf0f6>] [<ffffffff817bf0f6>] xenvif_free+0x76/0x130
  2014-06-06  9:33 ` Zoltan Kiss
@ 2014-06-06  9:57   ` Sander Eikelenboom
  2014-06-06 10:28     ` Wei Liu
  0 siblings, 1 reply; 8+ messages in thread
From: Sander Eikelenboom @ 2014-06-06  9:57 UTC (permalink / raw)
  To: Zoltan Kiss; +Cc: xen-devel@lists.xenproject.org, Wei Liu, ian.campbell


Friday, June 6, 2014, 11:33:56 AM, you wrote:

> Hi,

> Can you please do an "addr2line -e [your vmlinuz] ffffffff817bf0f6" to 
> figure out which line is causing the issue?

> Thanks,

> Zoli

addr2line doesn't work on vmlinuz (only on a uncompressed vmlinux), and 
unfortunately i don't have the build tree of that build anymore AND ./scripts/extract-vmlinux also doesn't seem to work for some reason 
:S *sigh*


> On 06/06/14 10:18, Sander Eikelenboom wrote:
>> While trying to do some more testing around another crash .. i stumbled upon
>> this one:
>>
>> [  345.470718] BUG: unable to handle kernel paging request at 0000000000003360
>> [  345.499053] IP: [<ffffffff817bf0f6>] xenvif_free+0x76/0x130
>> [  345.522732] PGD 358f2067 PUD 37e24067 PMD 0
>> [  345.542478] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
>> [  345.563071] Modules linked in:
>> [  345.579180] CPU: 3 PID: 45 Comm: xenwatch Not tainted 3.15.0-rc8-20140602-net-xendev-bt-mq+ #1
>> [  345.612170] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640)  , BIOS V1.8B1 09/13/2010
>> [  345.643065] task: ffff8800593b5ff0 ti: ffff8800593bc000 task.ti: ffff8800593bc000
>> [  345.672641] RIP: e030:[<ffffffff817bf0f6>]  [<ffffffff817bf0f6>] xenvif_free+0x76/0x130
>> [  345.703852] RSP: e02b:ffff8800593bfc28  EFLAGS: 00010246
>> [  345.727076] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006
>> [  345.755788] RDX: 0000000000000006 RSI: ffff8800593b6810 RDI: ffff8800259238c8
>> [  345.784424] RBP: ffff8800593bfc68 R08: 0000000000000000 R09: 0000000000000000
>> [  345.812987] R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
>> [  345.841582] R13: 000000000000001e R14: 0000000000000000 R15: 0000000000000000
>> [  345.870065] FS:  00007f4d54a57700(0000) GS:ffff88005f6c0000(0000) knlGS:0000000000000000
>> [  345.901412] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
>> [  345.925621] CR2: 0000000000003360 CR3: 0000000036d9f000 CR4: 0000000000000660
>> [  345.954129] Stack:
>> [  345.967337]  0000000000145980 ffff880025923d20 ffff88002595ef28 ffff8800258767a8
>> [  345.996573]  ffff88002595eee8 ffff88002595ef28 ffff88002595ef28 0000000000000000
>> [  346.025715]  ffff8800593bfc98 ffffffff817bd9d2 ffff8800593bfc98 ffff88002595ef28
>> [  346.054781] Call Trace:
>> [  346.069218]  [<ffffffff817bd9d2>] netback_remove+0x72/0xa0
>> [  346.093003]  [<ffffffff815813ad>] xenbus_dev_remove+0x3d/0x70
>> [  346.117571]  [<ffffffff816e9d39>] __device_release_driver+0x69/0xd0
>> [  346.143518]  [<ffffffff816e9dce>] device_release_driver+0x2e/0x40
>> [  346.168761]  [<ffffffff816e984b>] bus_remove_device+0x11b/0x160
>> [  346.193630]  [<ffffffff816e6bdf>] device_del+0x12f/0x1c0
>> [  346.216612]  [<ffffffff816e6c86>] device_unregister+0x16/0x30
>> [  346.240830]  [<ffffffff817bdab6>] frontend_changed+0xb6/0x100
>> [  346.264969]  [<ffffffff81581320>] xenbus_otherend_changed+0xb0/0xc0
>> [  346.290657]  [<ffffffff8157fe40>] ? xenbus_thread+0x2a0/0x2a0
>> [  346.314756]  [<ffffffff81581c20>] frontend_changed+0x10/0x20
>> [  346.338585]  [<ffffffff8157fe85>] xenwatch_thread+0x45/0x130
>> [  346.362334]  [<ffffffff8110cac0>] ? __init_waitqueue_head+0x60/0x60
>> [  346.387798]  [<ffffffff810ee3b4>] kthread+0xe4/0x100
>> [  346.409261]  [<ffffffff810ee2d0>] ? __init_kthread_worker+0x70/0x70
>> [  346.434570]  [<ffffffff81b9e4fc>] ret_from_fork+0x7c/0xb0
>> [  346.457333]  [<ffffffff810ee2d0>] ? __init_kthread_worker+0x70/0x70
>> [  346.482846] Code: 48 83 c0 01 48 69 c0 40 64 03 00 48 89 45 c0 66 0f 1f 44 00 00 48 8b 45 c8 31 db 4c 8b 60 20 4d 01 f4 0f 1f 00 45 31 ff 49 63 c7 <41> 83 bc 84 60 33 00 00 ff 74 3f bf e8 03 00 00 83 c3 01 e8 92
>> [  346.552521] RIP  [<ffffffff817bf0f6>] xenvif_free+0x76/0x130
>> [  346.576381]  RSP <ffff8800593bfc28>
>> [  346.593562] CR2: 0000000000003360
>> [  346.610384] ---[ end trace 83c5864024a0a3c4 ]---
>>
>> That's on a kernel with xen 3.16 dev pulled in and the netback multiqueue series
>> applied, haven't seen it before while using this kernel .. so i don't know if i
>> can reproduce.
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: BUG: unable to handle kernel paging request at 0000000000003360 RIP: e030:[<ffffffff817bf0f6>] [<ffffffff817bf0f6>] xenvif_free+0x76/0x130
  2014-06-06  9:57   ` Sander Eikelenboom
@ 2014-06-06 10:28     ` Wei Liu
  2014-06-06 10:37       ` Sander Eikelenboom
  0 siblings, 1 reply; 8+ messages in thread
From: Wei Liu @ 2014-06-06 10:28 UTC (permalink / raw)
  To: Sander Eikelenboom
  Cc: xen-devel@lists.xenproject.org, Wei Liu, ian.campbell,
	Zoltan Kiss

On Fri, Jun 06, 2014 at 11:57:14AM +0200, Sander Eikelenboom wrote:
> 
> Friday, June 6, 2014, 11:33:56 AM, you wrote:
> 
> > Hi,
> 
> > Can you please do an "addr2line -e [your vmlinuz] ffffffff817bf0f6" to 
> > figure out which line is causing the issue?
> 
> > Thanks,
> 
> > Zoli
> 
> addr2line doesn't work on vmlinuz (only on a uncompressed vmlinux), and 
> unfortunately i don't have the build tree of that build anymore AND ./scripts/extract-vmlinux also doesn't seem to work for some reason 
> :S *sigh*
> 
> 

Can you obtain .config and rebuild?

If you don't have .config anymore, another method is to boot into your
Dom0 and check if there's /proc/config.gz. If so, zcat /proc/config.gz
will give you back the .config file used to build this kernel.

Wei.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: BUG: unable to handle kernel paging request at 0000000000003360 RIP: e030:[<ffffffff817bf0f6>] [<ffffffff817bf0f6>] xenvif_free+0x76/0x130
  2014-06-06 10:28     ` Wei Liu
@ 2014-06-06 10:37       ` Sander Eikelenboom
  2014-06-06 10:38         ` Ian Campbell
  0 siblings, 1 reply; 8+ messages in thread
From: Sander Eikelenboom @ 2014-06-06 10:37 UTC (permalink / raw)
  To: Wei Liu; +Cc: xen-devel@lists.xenproject.org, ian.campbell, Zoltan Kiss


Friday, June 6, 2014, 12:28:02 PM, you wrote:

> On Fri, Jun 06, 2014 at 11:57:14AM +0200, Sander Eikelenboom wrote:
>> 
>> Friday, June 6, 2014, 11:33:56 AM, you wrote:
>> 
>> > Hi,
>> 
>> > Can you please do an "addr2line -e [your vmlinuz] ffffffff817bf0f6" to 
>> > figure out which line is causing the issue?
>> 
>> > Thanks,
>> 
>> > Zoli
>> 
>> addr2line doesn't work on vmlinuz (only on a uncompressed vmlinux), and 
>> unfortunately i don't have the build tree of that build anymore AND ./scripts/extract-vmlinux also doesn't seem to work for some reason 
>> :S *sigh*
>> 
>> 

> Can you obtain .config and rebuild?

> If you don't have .config anymore, another method is to boot into your
> Dom0 and check if there's /proc/config.gz. If so, zcat /proc/config.gz
> will give you back the .config file used to build this kernel.

> Wei.


Well it's not the .config i'm worried about .. it's the tree it self :)
 .. it was not a pristine upstream tree .. but a concoction of
linuses tree + bluetooth fixes + xen-devel + xen-multi-queue etc.

So i consider it impossible to recreate that at this point.

And unfortunately due to some space limitations, it's build without also building
the source .debs

I have now something out of vmlinuz that readelf recognizes but addr2line still 
doesn't give any lines back on any address from that stacktrace :-(

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: BUG: unable to handle kernel paging request at 0000000000003360 RIP: e030:[<ffffffff817bf0f6>] [<ffffffff817bf0f6>] xenvif_free+0x76/0x130
  2014-06-06 10:37       ` Sander Eikelenboom
@ 2014-06-06 10:38         ` Ian Campbell
  2014-06-06 10:48           ` Sander Eikelenboom
  0 siblings, 1 reply; 8+ messages in thread
From: Ian Campbell @ 2014-06-06 10:38 UTC (permalink / raw)
  To: Sander Eikelenboom; +Cc: xen-devel@lists.xenproject.org, Wei Liu, Zoltan Kiss

On Fri, 2014-06-06 at 12:37 +0200, Sander Eikelenboom wrote:
> it was not a pristine upstream tree .. but a concoction of
> linuses tree + bluetooth fixes + xen-devel + xen-multi-queue etc.
> 
> So i consider it impossible to recreate that at this point.

Hrm, can you repro with any one of those?

> I have now something out of vmlinuz that readelf recognizes but addr2line still 
> doesn't give any lines back on any address from that stacktrace :-(

The bzImage payload ELF is stripped I'm afraid.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: BUG: unable to handle kernel paging request at 0000000000003360 RIP: e030:[<ffffffff817bf0f6>] [<ffffffff817bf0f6>] xenvif_free+0x76/0x130
  2014-06-06 10:38         ` Ian Campbell
@ 2014-06-06 10:48           ` Sander Eikelenboom
  2014-06-06 12:09             ` Ian Campbell
  0 siblings, 1 reply; 8+ messages in thread
From: Sander Eikelenboom @ 2014-06-06 10:48 UTC (permalink / raw)
  To: Ian Campbell; +Cc: xen-devel@lists.xenproject.org, Wei Liu, Zoltan Kiss


Friday, June 6, 2014, 12:38:43 PM, you wrote:

> On Fri, 2014-06-06 at 12:37 +0200, Sander Eikelenboom wrote:
>> it was not a pristine upstream tree .. but a concoction of
>> linuses tree + bluetooth fixes + xen-devel + xen-multi-queue etc.
>> 
>> So i consider it impossible to recreate that at this point.

> Hrm, can you repro with any one of those?

Nope it just happened by accident .. don't know what triggered it unfortunately.

>> I have now something out of vmlinuz that readelf recognizes but addr2line still 
>> doesn't give any lines back on any address from that stacktrace :-(

> The bzImage payload ELF is stripped I'm afraid.

Yeah i just figured that out .. 

Ah kernel-pkg.cfg has an option to store the vmlinux .. and i guess i still have
to build the source package (so it would be possible to see what the line 
actually as .. in case are applied to that source file which shift the lines)

So i guess i will also have to keep an eye open for this one ;-)

--
Sander

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: BUG: unable to handle kernel paging request at 0000000000003360 RIP: e030:[<ffffffff817bf0f6>] [<ffffffff817bf0f6>] xenvif_free+0x76/0x130
  2014-06-06 10:48           ` Sander Eikelenboom
@ 2014-06-06 12:09             ` Ian Campbell
  0 siblings, 0 replies; 8+ messages in thread
From: Ian Campbell @ 2014-06-06 12:09 UTC (permalink / raw)
  To: Sander Eikelenboom; +Cc: xen-devel@lists.xenproject.org, Wei Liu, Zoltan Kiss

On Fri, 2014-06-06 at 12:48 +0200, Sander Eikelenboom wrote:
> Friday, June 6, 2014, 12:38:43 PM, you wrote:
> 
> > On Fri, 2014-06-06 at 12:37 +0200, Sander Eikelenboom wrote:
> >> it was not a pristine upstream tree .. but a concoction of
> >> linuses tree + bluetooth fixes + xen-devel + xen-multi-queue etc.
> >> 
> >> So i consider it impossible to recreate that at this point.
> 
> > Hrm, can you repro with any one of those?
> 
> Nope it just happened by accident .. don't know what triggered it unfortunately.
> 
> >> I have now something out of vmlinuz that readelf recognizes but addr2line still 
> >> doesn't give any lines back on any address from that stacktrace :-(
> 
> > The bzImage payload ELF is stripped I'm afraid.
> 
> Yeah i just figured that out .. 
> 
> Ah kernel-pkg.cfg has an option to store the vmlinux .. and i guess i still have
> to build the source package (so it would be possible to see what the line 
> actually as .. in case are applied to that source file which shift the lines)
> 
> So i guess i will also have to keep an eye open for this one ;-)

Yes, I think without knowing exactly what combination of code lead to
this plus not having the binaries etc available there isn't much point
pursuing this further until it happens again and we can gather more
information.

Ian.

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2014-06-06 12:10 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-06-06  9:18 BUG: unable to handle kernel paging request at 0000000000003360 RIP: e030:[<ffffffff817bf0f6>] [<ffffffff817bf0f6>] xenvif_free+0x76/0x130 Sander Eikelenboom
2014-06-06  9:33 ` Zoltan Kiss
2014-06-06  9:57   ` Sander Eikelenboom
2014-06-06 10:28     ` Wei Liu
2014-06-06 10:37       ` Sander Eikelenboom
2014-06-06 10:38         ` Ian Campbell
2014-06-06 10:48           ` Sander Eikelenboom
2014-06-06 12:09             ` Ian Campbell

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.