I just ran into the crash below, and I wonder why the ASSERT in __trace_var() is there anyway? Shouldnt the value of extra_word just be truncated to TRACE_EXTRA_MAX without crashing the hypervisor?? Olaf (XEN) Assertion ''extra_word <= TRACE_EXTRA_MAX'' failed at trace.c:687 (XEN) Debugging connection not set up. (XEN) ----[ Xen-4.2.23658-20110711.092126 x86_64 debug=y Not tainted ]---- (XEN) CPU: 1 (XEN) RIP: e008:[<ffff82c480128783>] __trace_var+0x4d/0x3b8 (XEN) RFLAGS: 0000000000010006 CONTEXT: hypervisor (XEN) rax: 0000000000000000 rbx: ffff83083ffbfcc8 rcx: ffff83083ffbfc58 (XEN) rdx: 0000000000000028 rsi: 0000000000000001 rdi: 0000000000802006 (XEN) rbp: ffff83083ffbfc48 rsp: ffff83083ffbfbe8 r8: 0000000000000000 (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: ffffffff801b5760 (XEN) r12: 000000000000000a r13: 0000000000802006 r14: 0000000000000001 (XEN) r15: ffff83083ffbfc58 cr0: 000000008005003b cr4: 00000000000026f0 (XEN) cr3: 000000084ea89000 cr2: ffff882f64213db0 (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008 (XEN) Xen stack trace from rsp=ffff83083ffbfbe8: (XEN) ffff82c480127959 0000000000000086 0000000000000000 ffff83083ffbfd10 (XEN) 01ff82c4802d7f80 0000000000028004 ffff832da72db000 ffff83083ffbfcc8 (XEN) 0000000000000022 0000000000000002 0000000000000068 ffff830839c02090 (XEN) ffff83083ffbfc88 ffff82c480162172 0000002200000068 0000000020000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 ffff82c4803063e8 (XEN) ffff83083ffbfd18 ffff82c4801631ae ffff82c480128a9b ffff82c480306360 (XEN) ffff82c480306360 ffff83083ffbfcc8 0000001d00000098 ffff83083ffbfdf8 (XEN) 0000000020000000 0000000000000000 0000000000000000 0000000000000000 (XEN) 0000000000000002 0000000000000068 0000000000000002 ffff83083ffbfdf8 (XEN) ffff830839806880 0000000000000000 ffff83083ffbfd88 ffff82c48015d813 (XEN) ffff832da72db000 ffff830839c02090 ffff832daaea3000 0000000000000246 (XEN) ffff83083ffe06e0 ffff83083ffbfd60 ffff82c480122a11 ffff830839806880 (XEN) ffff830843621390 ffff8308398068e0 ffff83083ffbff18 0000000000000000 (XEN) ffff83083ffbfde8 ffff82c480160708 ffff830839c02090 000000000000000c (XEN) 000000000020f101 0000000000000018 ffff83083ffbfe68 ffff830839806880 (XEN) 0000000000000068 ffff8308398068e0 ffff83083ffbff18 0000000000000000 (XEN) ffff83083ffbfe38 ffff82c480162938 0000000020000000 0000000000000000 (XEN) 0000000000000000 0000000000000000 ffff83083ffbff18 ffff830839806880 (XEN) 0000000000000068 0000000000000068 ffff83083ffbfe58 ffff82c4801629a7 (XEN) 0000000000000068 0000000000006800 ffff83083ffbfe88 ffff82c48015d969 (XEN) Xen call trace: (XEN) [<ffff82c480128783>] __trace_var+0x4d/0x3b8 (XEN) [<ffff82c480162172>] trace_irq_mask+0x49/0x4b (XEN) [<ffff82c4801631ae>] __assign_irq_vector+0x241/0x374 (XEN) [<ffff82c48015d813>] set_desc_affinity+0x5d/0xd4 (XEN) [<ffff82c480160708>] set_msi_affinity+0x44/0x1c1 (XEN) [<ffff82c480162938>] move_masked_irq+0x9c/0xcd (XEN) [<ffff82c4801629a7>] move_native_irq+0x3e/0x53 (XEN) [<ffff82c48015d969>] ack_msi_irq+0x2c/0x6e (XEN) [<ffff82c4801622e3>] do_IRQ+0x16f/0x66d (XEN) (XEN) (XEN) **************************************** (XEN) Panic on CPU 1: (XEN) Assertion ''extra_word <= TRACE_EXTRA_MAX'' failed at trace.c:687 (XEN) **************************************** (XEN) (XEN) Reboot in five seconds... (XEN) Debugging connection not set up. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
George Dunlap
2011-Jul-11 14:35 UTC
Re: [Xen-devel] crash in trace.c with large extra_data
The general idea is that callers of trace_var() *shouldn''t* be calling with extra_words > TRACE_EXTRA_MAX. It''s an assert so that it breaks on debug builds, allowing programmers to fix the mistake (obviously mine in this case), but not on production builds. I suppose it could be changed into a warning of some kind instead. -George On Mon, Jul 11, 2011 at 3:02 PM, Olaf Hering <olaf@aepfle.de> wrote:> > I just ran into the crash below, and I wonder why the ASSERT in > __trace_var() is there anyway? Shouldnt the value of extra_word just > be truncated to TRACE_EXTRA_MAX without crashing the hypervisor?? > > Olaf > > > (XEN) Assertion ''extra_word <= TRACE_EXTRA_MAX'' failed at trace.c:687 > (XEN) Debugging connection not set up. > (XEN) ----[ Xen-4.2.23658-20110711.092126 x86_64 debug=y Not tainted ]---- > (XEN) CPU: 1 > (XEN) RIP: e008:[<ffff82c480128783>] __trace_var+0x4d/0x3b8 > (XEN) RFLAGS: 0000000000010006 CONTEXT: hypervisor > (XEN) rax: 0000000000000000 rbx: ffff83083ffbfcc8 rcx: ffff83083ffbfc58 > (XEN) rdx: 0000000000000028 rsi: 0000000000000001 rdi: 0000000000802006 > (XEN) rbp: ffff83083ffbfc48 rsp: ffff83083ffbfbe8 r8: 0000000000000000 > (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: ffffffff801b5760 > (XEN) r12: 000000000000000a r13: 0000000000802006 r14: 0000000000000001 > (XEN) r15: ffff83083ffbfc58 cr0: 000000008005003b cr4: 00000000000026f0 > (XEN) cr3: 000000084ea89000 cr2: ffff882f64213db0 > (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008 > (XEN) Xen stack trace from rsp=ffff83083ffbfbe8: > (XEN) ffff82c480127959 0000000000000086 0000000000000000 ffff83083ffbfd10 > (XEN) 01ff82c4802d7f80 0000000000028004 ffff832da72db000 ffff83083ffbfcc8 > (XEN) 0000000000000022 0000000000000002 0000000000000068 ffff830839c02090 > (XEN) ffff83083ffbfc88 ffff82c480162172 0000002200000068 0000000020000000 > (XEN) 0000000000000000 0000000000000000 0000000000000000 ffff82c4803063e8 > (XEN) ffff83083ffbfd18 ffff82c4801631ae ffff82c480128a9b ffff82c480306360 > (XEN) ffff82c480306360 ffff83083ffbfcc8 0000001d00000098 ffff83083ffbfdf8 > (XEN) 0000000020000000 0000000000000000 0000000000000000 0000000000000000 > (XEN) 0000000000000002 0000000000000068 0000000000000002 ffff83083ffbfdf8 > (XEN) ffff830839806880 0000000000000000 ffff83083ffbfd88 ffff82c48015d813 > (XEN) ffff832da72db000 ffff830839c02090 ffff832daaea3000 0000000000000246 > (XEN) ffff83083ffe06e0 ffff83083ffbfd60 ffff82c480122a11 ffff830839806880 > (XEN) ffff830843621390 ffff8308398068e0 ffff83083ffbff18 0000000000000000 > (XEN) ffff83083ffbfde8 ffff82c480160708 ffff830839c02090 000000000000000c > (XEN) 000000000020f101 0000000000000018 ffff83083ffbfe68 ffff830839806880 > (XEN) 0000000000000068 ffff8308398068e0 ffff83083ffbff18 0000000000000000 > (XEN) ffff83083ffbfe38 ffff82c480162938 0000000020000000 0000000000000000 > (XEN) 0000000000000000 0000000000000000 ffff83083ffbff18 ffff830839806880 > (XEN) 0000000000000068 0000000000000068 ffff83083ffbfe58 ffff82c4801629a7 > (XEN) 0000000000000068 0000000000006800 ffff83083ffbfe88 ffff82c48015d969 > (XEN) Xen call trace: > (XEN) [<ffff82c480128783>] __trace_var+0x4d/0x3b8 > (XEN) [<ffff82c480162172>] trace_irq_mask+0x49/0x4b > (XEN) [<ffff82c4801631ae>] __assign_irq_vector+0x241/0x374 > (XEN) [<ffff82c48015d813>] set_desc_affinity+0x5d/0xd4 > (XEN) [<ffff82c480160708>] set_msi_affinity+0x44/0x1c1 > (XEN) [<ffff82c480162938>] move_masked_irq+0x9c/0xcd > (XEN) [<ffff82c4801629a7>] move_native_irq+0x3e/0x53 > (XEN) [<ffff82c48015d969>] ack_msi_irq+0x2c/0x6e > (XEN) [<ffff82c4801622e3>] do_IRQ+0x16f/0x66d > (XEN) > (XEN) > (XEN) **************************************** > (XEN) Panic on CPU 1: > (XEN) Assertion ''extra_word <= TRACE_EXTRA_MAX'' failed at trace.c:687 > (XEN) **************************************** > (XEN) > (XEN) Reboot in five seconds... > (XEN) Debugging connection not set up. > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Mon, Jul 11, George Dunlap wrote:> The general idea is that callers of trace_var() *shouldn''t* be calling > with extra_words > TRACE_EXTRA_MAX. It''s an assert so that it breaks > on debug builds, allowing programmers to fix the mistake (obviously > mine in this case), but not on production builds. > > I suppose it could be changed into a warning of some kind instead.George, a simple printk() would do it I think. In this unfortunate case the system does not even reboot, need to find someone to power cycle the box.. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel