I get the following crash while booting a kernel built with the latest version of xen/dom0/hackery (booting without xen, but booting with xen also crashes in a similar way but I haven''t managed to capture the crash from that) Reverting bd4a7874716d1b1f69cacfef4adf9f94050ecd82 and cfb667260eb7f6dd26ceb6d49da818978396757d allows it to boot. Michael Young general protection fault: 0000 [#1] SMP last sysfs file: CPU 0 Modules linked in: Pid: 1, comm: swapper Tainted: G W 2.6.29-1.2.15.fc11.x86_64 #1 RIP: 0010:[<ffffffff810bb7c4>] [<ffffffff810bb7c4>] put_page+0x16/0xb5 RSP: 0018:ffff88003f67ba80 EFLAGS: 00010282 RAX: 0000000000006b6b RBX: ffff88003f569a30 RCX: 00000000001d0006 RDX: ffff88003f569df8 RSI: ffffffff810e05b6 RDI: 6b6b6b6b6b6b6b6b RBP: ffff88003f67bab0 R08: ffffffff81612690 R09: 000000000000005a R10: ffffe200019bb240 R11: 0000000000000000 R12: 0000000000000001 R13: ffff88003f569a40 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff880003200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: 0000000000000000 CR3: 0000000000201000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process swapper (pid: 1, threadinfo ffff88003f67a000, task ffff88003f680000) Stack: 0000000000000000 ffff88003f569a30 0000000000000001 ffff88003f569a40 0000000000000000 0000000000000000 ffff88003f67bae0 ffffffff813001e3 ffff88003f67bae0 ffff88003f712000 0000000000000000 ffff88003f712000 Call Trace: [<ffffffff813001e3>] skb_release_data+0x8c/0xd5 [<ffffffff812ffefa>] __kfree_skb+0x1e/0x87 [<ffffffff812fff93>] kfree_skb+0x30/0x32 [<ffffffff81321b42>] netlink_broadcast+0x22c/0x276 [<ffffffff8119ee06>] kobject_uevent_env+0x2bc/0x366 [<ffffffff8119eebb>] kobject_uevent+0xb/0xd [<ffffffff8119e503>] kset_register+0x35/0x3c [<ffffffff81249584>] __class_register+0xe0/0x171 [<ffffffff8164eec0>] ? kobject_uevent_init+0x0/0x46 [<ffffffff8164f797>] ? pcibus_class_init+0x0/0x19 [<ffffffff8164f7ae>] pcibus_class_init+0x17/0x19 [<ffffffff8100a080>] do_one_initcall+0x75/0x18a [<ffffffff810de897>] ? check_object+0x175/0x1af [<ffffffff810dfe39>] ? __slab_free+0x238/0x265 [<ffffffff810717d3>] ? trace_hardirqs_on_caller+0x1f/0x152 [<ffffffff81071913>] ? trace_hardirqs_on+0xd/0xf [<ffffffff81073030>] ? print_lock_contention_bug+0x1b/0xe1 [<ffffffff811335ca>] ? proc_register+0x123/0x1a2 [<ffffffff811a7cf2>] ? _raw_spin_unlock+0x8f/0x98 [<ffffffff813a2f48>] ? _spin_unlock+0x2b/0x30 [<ffffffff81133633>] ? proc_register+0x18c/0x1a2 [<ffffffff81133767>] ? create_proc_entry+0x79/0x91 [<ffffffff8109bf9a>] ? register_irq_proc+0xb3/0xcf [<ffffffff81130000>] ? proc_pid_syscall+0x88/0xb7 [<ffffffff8162b710>] kernel_init+0x1d9/0x22f [<ffffffff81012d8a>] child_rip+0xa/0x20 [<ffffffff813a2ebb>] ? _spin_unlock_irq+0x30/0x3c [<ffffffff81012750>] ? restore_args+0x0/0x30 [<ffffffff8162b537>] ? kernel_init+0x0/0x22f [<ffffffff81012d80>] ? child_rip+0x0/0x20 Code: 89 e5 0f 1f 44 00 00 48 c7 c7 12 b5 0b 81 e8 b0 3e fa ff c9 c3 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 08 0f 1f 44 00 00 <48> f7 07 00 60 00 00 48 89 fb 74 07 e8 b6 f4 ff ff eb 7f 8b 47 RIP [<ffffffff810bb7c4>] put_page+0x16/0xb5 RSP <ffff88003f67ba80> ---[ end trace 4eaa2a86a8e2da23 ]--- swapper used greatest stack depth: 4384 bytes left Kernel panic - not syncing: Attempted to kill init! Pid: 1, comm: swapper Tainted: G D W 2.6.29-1.2.15.fc11.x86_64 #1 Call Trace: [<ffffffff813a01ec>] panic+0x7a/0x131 [<ffffffff810717d3>] ? trace_hardirqs_on_caller+0x1f/0x152 [<ffffffff813a2cf9>] ? _write_unlock_irq+0x30/0x3b [<ffffffff8105153f>] ? do_exit+0x363/0x890 [<ffffffff8105125b>] do_exit+0x7f/0x890 [<ffffffff813a44f6>] oops_end+0xbf/0xc7 [<ffffffff810154a9>] die+0x5a/0x63 [<ffffffff813a40da>] do_general_protection+0x11e/0x126 [<ffffffff813a38f5>] general_protection+0x25/0x30 [<ffffffff810e05b6>] ? kfree+0xf7/0x110 [<ffffffff810bb7c4>] ? put_page+0x16/0xb5 [<ffffffff813001e3>] skb_release_data+0x8c/0xd5 [<ffffffff812ffefa>] __kfree_skb+0x1e/0x87 [<ffffffff812fff93>] kfree_skb+0x30/0x32 [<ffffffff81321b42>] netlink_broadcast+0x22c/0x276 [<ffffffff8119ee06>] kobject_uevent_env+0x2bc/0x366 [<ffffffff8119eebb>] kobject_uevent+0xb/0xd [<ffffffff8119e503>] kset_register+0x35/0x3c [<ffffffff81249584>] __class_register+0xe0/0x171 [<ffffffff8164eec0>] ? kobject_uevent_init+0x0/0x46 [<ffffffff8164f797>] ? pcibus_class_init+0x0/0x19 [<ffffffff8164f7ae>] pcibus_class_init+0x17/0x19 [<ffffffff8100a080>] do_one_initcall+0x75/0x18a [<ffffffff810de897>] ? check_object+0x175/0x1af [<ffffffff810dfe39>] ? __slab_free+0x238/0x265 [<ffffffff810717d3>] ? trace_hardirqs_on_caller+0x1f/0x152 [<ffffffff81071913>] ? trace_hardirqs_on+0xd/0xf [<ffffffff81073030>] ? print_lock_contention_bug+0x1b/0xe1 [<ffffffff811335ca>] ? proc_register+0x123/0x1a2 [<ffffffff811a7cf2>] ? _raw_spin_unlock+0x8f/0x98 [<ffffffff813a2f48>] ? _spin_unlock+0x2b/0x30 [<ffffffff81133633>] ? proc_register+0x18c/0x1a2 [<ffffffff81133767>] ? create_proc_entry+0x79/0x91 [<ffffffff8109bf9a>] ? register_irq_proc+0xb3/0xcf [<ffffffff81130000>] ? proc_pid_syscall+0x88/0xb7 [<ffffffff8162b710>] kernel_init+0x1d9/0x22f [<ffffffff81012d8a>] child_rip+0xa/0x20 [<ffffffff813a2ebb>] ? _spin_unlock_irq+0x30/0x3c [<ffffffff81012750>] ? restore_args+0x0/0x30 [<ffffffff8162b537>] ? kernel_init+0x0/0x22f [<ffffffff81012d80>] ? child_rip+0x0/0x20 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2009-Mar-29 20:54 UTC
Re: [Xen-devel] crash while booting latest hackery kernel
M A Young wrote:> I get the following crash while booting a kernel built with the latest > version of xen/dom0/hackery (booting without xen, but booting with xen > also crashes in a similar way but I haven''t managed to capture the > crash from that) Reverting bd4a7874716d1b1f69cacfef4adf9f94050ecd82 > and cfb667260eb7f6dd26ceb6d49da818978396757d allows it to boot.Yes, those changes are troublesome; I shouldn''t have pushed them out yet. But at the moment push2/xen/dom0/master is probably a more stable base for experimenting, since its close to what I''m proposing for the current merge window (though it includes backend support which I have not yet pushed). One the merge window has finished, I''ll probably restructure the xen.git branches a fair amount anyway. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel