Dave, could you please set debug level (set debug 3) and run again backtrace for core-files: 1. which generate segmentation violations 2. which contain repetitive `apic_timer_interrupt` frames and send output to me. On Tue, Jul 30, 2013 at 04:17:52PM -0400, Dave Anderson wrote: ... > Of the 160, only 32 generated a backtrace. 115 of them just > printed 2 or more "." characters and nothing else. What does > that mean? This mean that error occured while obtaining frames info. > 2 of them generated "gdb request failed" failures trying to print > tss_struct fields. And I should note that at first I tried "bt -aH", > but almost every time I would get the same type of gdb request failures > on the other active, non-crashing, cpus. So then I decided to just > test it with a "bt -H". `tss_struct` problem was fixed. > And is there a reason for the special case for panic()? They all > seem to show this: > > # 0: [RSP: 0xffff88001fb1dc10, RIP: 0xffffffff814c7be0] panic ( ... ) > < Argument list for symbol: panic > RDI: 0xffffffff81644a6b, RSI: 0xffff88001fb1dd68, RDX: 0x9 > RCX: 0x30001, R8: 0x73, R9: 0x0 It is not case for panic() only, but for functions with a varying number of arguments. > Since you've already followed my original suggestion and segregated > the code into its own file, can you take it one step further and transform > it into an extension module? If you did that, then I could host it > on the crash extensions web page for people to test/use. Will do it a bit later. > Thanks, > Dave Alexandr -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility