* crash binary for latest unreleased kernel @ 2018-01-26 20:52 Joe Smith 2018-01-27 4:32 ` Mike Galbraith 0 siblings, 1 reply; 10+ messages in thread From: Joe Smith @ 2018-01-26 20:52 UTC (permalink / raw) To: linux-kernel Hi, I am doing development on the latest unreleased kernel on a system running ubuntu 16.04. I can not get crash dump to be saved or use crash on the live system. I have tried compiling crash on the system. What is the trick to do development on the latest kernel using a system installed with old release. Thanks, -- JS ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: crash binary for latest unreleased kernel 2018-01-26 20:52 crash binary for latest unreleased kernel Joe Smith @ 2018-01-27 4:32 ` Mike Galbraith 2018-01-27 4:38 ` Randy Dunlap 0 siblings, 1 reply; 10+ messages in thread From: Mike Galbraith @ 2018-01-27 4:32 UTC (permalink / raw) To: Joe Smith, linux-kernel On Fri, 2018-01-26 at 12:52 -0800, Joe Smith wrote: > Hi, > > I am doing development on the latest unreleased kernel on a system > running ubuntu 16.04. I can not get crash dump to be saved or use > crash on the live system. I have tried compiling crash on the system. > > What is the trick to do development on the latest kernel using a > system installed with old release. You have to either be motivated enough to fix crash and friends up as they get busted, or lazy enough to wait for maintainers to do so for you. I've done a bit of both, but the later is my favorite :) -Mike ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: crash binary for latest unreleased kernel 2018-01-27 4:32 ` Mike Galbraith @ 2018-01-27 4:38 ` Randy Dunlap 2018-01-27 4:48 ` Mike Galbraith 0 siblings, 1 reply; 10+ messages in thread From: Randy Dunlap @ 2018-01-27 4:38 UTC (permalink / raw) To: Mike Galbraith, Joe Smith, linux-kernel On 01/26/2018 08:32 PM, Mike Galbraith wrote: > On Fri, 2018-01-26 at 12:52 -0800, Joe Smith wrote: >> Hi, >> >> I am doing development on the latest unreleased kernel on a system >> running ubuntu 16.04. I can not get crash dump to be saved or use >> crash on the live system. I have tried compiling crash on the system. >> >> What is the trick to do development on the latest kernel using a >> system installed with old release. > > You have to either be motivated enough to fix crash and friends up as > they get busted, or lazy enough to wait for maintainers to do so for > you. I've done a bit of both, but the later is my favorite :) :) Is it mostly structure updates or is it partly randomized layout of structs? or something totally different? thanks, -- ~Randy ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: crash binary for latest unreleased kernel 2018-01-27 4:38 ` Randy Dunlap @ 2018-01-27 4:48 ` Mike Galbraith 2018-01-28 8:37 ` Joe Smith 0 siblings, 1 reply; 10+ messages in thread From: Mike Galbraith @ 2018-01-27 4:48 UTC (permalink / raw) To: Randy Dunlap, Joe Smith, linux-kernel On Fri, 2018-01-26 at 20:38 -0800, Randy Dunlap wrote: > On 01/26/2018 08:32 PM, Mike Galbraith wrote: > > On Fri, 2018-01-26 at 12:52 -0800, Joe Smith wrote: > >> Hi, > >> > >> I am doing development on the latest unreleased kernel on a system > >> running ubuntu 16.04. I can not get crash dump to be saved or use > >> crash on the live system. I have tried compiling crash on the system. > >> > >> What is the trick to do development on the latest kernel using a > >> system installed with old release. > > > > You have to either be motivated enough to fix crash and friends up as > > they get busted, or lazy enough to wait for maintainers to do so for > > you. I've done a bit of both, but the later is my favorite :) > > :) > > Is it mostly structure updates or is it partly randomized layout of > structs? or something totally different? The stuff I've fixed up has been trivial renames and whatnot, operative word being trivial, easy to find based on gripage. If I don't find it quickly, I usually decide to not need it _that_ badly, go with plan B. -Mike ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: crash binary for latest unreleased kernel 2018-01-27 4:48 ` Mike Galbraith @ 2018-01-28 8:37 ` Joe Smith 2018-01-28 9:20 ` Mike Galbraith 0 siblings, 1 reply; 10+ messages in thread From: Joe Smith @ 2018-01-28 8:37 UTC (permalink / raw) To: Mike Galbraith; +Cc: Randy Dunlap, linux-kernel I happen to look at the patches for the crash binary and came across this log entry from Jan 19. I am also using 4.15-rc kernel. Not knowing anything about crash it is hard to even attempt to fix it. Initial pass for support of kernel page table isolation. The x86_64 "bt" command may indicate "bt: cannot transition from exception stack to current process stack" if the crash callback NMI occurred while an active task was running on the new entry trampoline stack. This has only been tested on the RHEL7 backport of the upstream patch because as of this commit, crash does not run on 4.15-rc kernels. Further changes may be required for upstream kernels, and distributions that implement the kernel changes differently than upstream. (anderson@redhat.com) On Fri, Jan 26, 2018 at 8:48 PM, Mike Galbraith <efault@gmx.de> wrote: > On Fri, 2018-01-26 at 20:38 -0800, Randy Dunlap wrote: >> On 01/26/2018 08:32 PM, Mike Galbraith wrote: >> > On Fri, 2018-01-26 at 12:52 -0800, Joe Smith wrote: >> >> Hi, >> >> >> >> I am doing development on the latest unreleased kernel on a system >> >> running ubuntu 16.04. I can not get crash dump to be saved or use >> >> crash on the live system. I have tried compiling crash on the system. >> >> >> >> What is the trick to do development on the latest kernel using a >> >> system installed with old release. >> > >> > You have to either be motivated enough to fix crash and friends up as >> > they get busted, or lazy enough to wait for maintainers to do so for >> > you. I've done a bit of both, but the later is my favorite :) >> >> :) >> >> Is it mostly structure updates or is it partly randomized layout of >> structs? or something totally different? > > The stuff I've fixed up has been trivial renames and whatnot, operative > word being trivial, easy to find based on gripage. If I don't find it > quickly, I usually decide to not need it _that_ badly, go with plan B. > > -Mike -- JS ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: crash binary for latest unreleased kernel 2018-01-28 8:37 ` Joe Smith @ 2018-01-28 9:20 ` Mike Galbraith 2018-01-28 10:00 ` Mike Galbraith 0 siblings, 1 reply; 10+ messages in thread From: Mike Galbraith @ 2018-01-28 9:20 UTC (permalink / raw) To: Joe Smith; +Cc: Randy Dunlap, linux-kernel On Sun, 2018-01-28 at 00:37 -0800, Joe Smith wrote: > I happen to look at the patches for the crash binary and came across > this log entry from Jan 19. I am also using 4.15-rc kernel. Not > knowing anything about crash it is hard to even attempt to fix it. It may not work all that well if box does something new/creative, but mundane manual crash, and live rummaging seem to work well enough. KERNEL: vmlinux-4.15.0.gc4e0ca7-master.gz DUMPFILE: vmcore CPUS: 8 DATE: Sun Jan 28 10:00:17 2018 UPTIME: 00:02:29 LOAD AVERAGE: 1.72, 1.12, 0.45 TASKS: 445 NODENAME: homer RELEASE: 4.15.0.gc4e0ca7-master VERSION: #563 SMP Sun Jan 28 04:07:36 CET 2018 MACHINE: x86_64 (3591 Mhz) MEMORY: 16 GB PANIC: "sysrq: SysRq : Trigger a crash" PID: 0 COMMAND: "swapper/2" TASK: ffff880187fd2940 (1 of 8) [THREAD_INFO: ffff880187fd2940] CPU: 2 STATE: TASK_RUNNING (SYSRQ) crash> bt PID: 0 TASK: ffff880187fd2940 CPU: 2 COMMAND: "swapper/2" #0 [ffff88041ec83880] machine_kexec at ffffffff81041079 #1 [ffff88041ec838d0] __crash_kexec at ffffffff810deede #2 [ffff88041ec83988] crash_kexec at ffffffff810dfbbd #3 [ffff88041ec839a0] oops_end at ffffffff8101c36e #4 [ffff88041ec839c0] no_context at ffffffff8104f94d #5 [ffff88041ec83a18] __do_page_fault at ffffffff81050068 #6 [ffff88041ec83a80] do_page_fault at ffffffff81050492 #7 [ffff88041ec83ab0] page_fault at ffffffff8160148c [exception RIP: sysrq_handle_crash+18] RIP: ffffffff81390892 RSP: ffff88041ec83b60 RFLAGS: 00010096 RAX: ffffffff81390880 RBX: 0000000000000063 RCX: 000000000000083f RDX: 0000000000000000 RSI: 00000000000000f6 RDI: 0000000000000063 RBP: ffffffff81e91960 R8: 000000000000036c R9: 0000000000aaaaaa R10: ffffea000fe45bc0 R11: 00000000ffffffff R12: 0000000000000001 R13: 0000000000000001 R14: ffff8803f4c521e0 R15: ffff8803f4c521f8 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #8 [ffff88041ec83b60] __handle_sysrq at ffffffff81390f28 #9 [ffff88041ec83b88] sysrq_filter at ffffffff81391097 #10 [ffff88041ec83bb8] input_to_handler at ffffffff81419ceb #11 [ffff88041ec83bf0] input_pass_values at ffffffff8141ae1d #12 [ffff88041ec83c18] input_handle_event at ffffffff8141cdf4 #13 [ffff88041ec83c48] input_event at ffffffff8141d2da #14 [ffff88041ec83c80] hidinput_report_event at ffffffff81466e93 #15 [ffff88041ec83c98] hid_report_raw_event at ffffffff81464826 #16 [ffff88041ec83d20] hid_input_report at ffffffff81464b29 #17 [ffff88041ec83d60] hid_irq_in at ffffffffa01b88bc [usbhid] #18 [ffff88041ec83d80] __usb_hcd_giveback_urb at ffffffffa02c297f [usbcore] #19 [ffff88041ec83da0] xhci_giveback_urb_in_irq at ffffffffa03c064f [xhci_hcd] #20 [ffff88041ec83dd8] xhci_td_cleanup at ffffffffa03c0cc7 [xhci_hcd] #21 [ffff88041ec83e08] handle_tx_event at ffffffffa03c4b87 [xhci_hcd] #22 [ffff88041ec83ea8] xhci_irq at ffffffffa03c5d69 [xhci_hcd] #23 [ffff88041ec83f20] __handle_irq_event_percpu at ffffffff810ac1f0 #24 [ffff88041ec83f60] handle_irq_event_percpu at ffffffff810ac370 #25 [ffff88041ec83f80] handle_irq_event at ffffffff810ac3d6 #26 [ffff88041ec83fa0] handle_edge_irq at ffffffff810af607 #27 [ffff88041ec83fb8] handle_irq at ffffffff8101bc0c #28 [ffff88041ec83fc0] do_IRQ at ffffffff816024d1 --- <IRQ stack> --- #29 [ffff880187fe7df0] ret_from_intr at ffffffff81600a62 [exception RIP: unknown or invalid address] RIP: 000000000000001f RSP: 0000000000000000 RFLAGS: fffffffb9171170b RAX: 00000022cf699c5c RBX: 00000022cee600c9 RCX: 0000000000009b53 RDX: ffff880187fe7ea8 RSI: 00000000000067a5 RDI: 0000000000007519 RBP: 0000000000000040 R8: ffff88041eca7668 R9: 0000000000000005 R10: ffffffff81e8c5b8 R11: 0000000000000000 R12: ffff88041ec95000 R13: 00000022d0532d00 R14: ffffffff810c45be R15: ffffffff81021630 ORIG_RAX: ffff88041ec9fec0 CS: 22cf699c5c SS: ffffffffffffffdd bt: WARNING: possibly bogus exception frame #30 [ffff880187fe7e98] cpuidle_enter_state at ffffffff8145a032 #31 [ffff880187fe7f08] do_idle at ffffffff8109c50b #32 [ffff880187fe7f30] cpu_startup_entry at ffffffff8109c6b9 #33 [ffff880187fe7f40] start_secondary at ffffffff810377ce #34 [ffff880187fe7f50] secondary_startup_64 at ffffffff810000d5 crash> (rummage rummage...) ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: crash binary for latest unreleased kernel 2018-01-28 9:20 ` Mike Galbraith @ 2018-01-28 10:00 ` Mike Galbraith 2018-01-28 20:19 ` Joe Smith 0 siblings, 1 reply; 10+ messages in thread From: Mike Galbraith @ 2018-01-28 10:00 UTC (permalink / raw) To: Joe Smith; +Cc: Randy Dunlap, linux-kernel On Sun, 2018-01-28 at 10:20 +0100, Mike Galbraith wrote: > On Sun, 2018-01-28 at 00:37 -0800, Joe Smith wrote: > > I happen to look at the patches for the crash binary and came across > > this log entry from Jan 19. I am also using 4.15-rc kernel. Not > > knowing anything about crash it is hard to even attempt to fix it. > > It may not work all that well if box does something new/creative, but > mundane manual crash, and live rummaging seem to work well enough. And looking through my modified makedumpfile package, looks like I've replaced everything I had ever done do it with backports from newer versions, so you should be able to get kdump working with nothing more than an update to makefumpfile, plus virgin upstream crash source. -Mike ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: crash binary for latest unreleased kernel 2018-01-28 10:00 ` Mike Galbraith @ 2018-01-28 20:19 ` Joe Smith 2018-01-31 3:51 ` Mike Galbraith 0 siblings, 1 reply; 10+ messages in thread From: Joe Smith @ 2018-01-28 20:19 UTC (permalink / raw) To: Mike Galbraith; +Cc: Randy Dunlap, linux-kernel Thanks a lot, Mike. Following your suggestions worked !!!! Regards, On Sun, Jan 28, 2018 at 2:00 AM, Mike Galbraith <efault@gmx.de> wrote: > On Sun, 2018-01-28 at 10:20 +0100, Mike Galbraith wrote: >> On Sun, 2018-01-28 at 00:37 -0800, Joe Smith wrote: >> > I happen to look at the patches for the crash binary and came across >> > this log entry from Jan 19. I am also using 4.15-rc kernel. Not >> > knowing anything about crash it is hard to even attempt to fix it. >> >> It may not work all that well if box does something new/creative, but >> mundane manual crash, and live rummaging seem to work well enough. > > And looking through my modified makedumpfile package, looks like I've > replaced everything I had ever done do it with backports from newer > versions, so you should be able to get kdump working with nothing more > than an update to makefumpfile, plus virgin upstream crash source. > > -Mike -- JS ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: crash binary for latest unreleased kernel 2018-01-28 20:19 ` Joe Smith @ 2018-01-31 3:51 ` Mike Galbraith 2018-01-31 16:03 ` Mike Galbraith 0 siblings, 1 reply; 10+ messages in thread From: Mike Galbraith @ 2018-01-31 3:51 UTC (permalink / raw) To: Joe Smith; +Cc: Randy Dunlap, linux-kernel On Sun, 2018-01-28 at 12:19 -0800, Joe Smith wrote: > Thanks a lot, Mike. Following your suggestions worked !!!! Until Monday happened :) -Mike ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: crash binary for latest unreleased kernel 2018-01-31 3:51 ` Mike Galbraith @ 2018-01-31 16:03 ` Mike Galbraith 0 siblings, 0 replies; 10+ messages in thread From: Mike Galbraith @ 2018-01-31 16:03 UTC (permalink / raw) To: Joe Smith; +Cc: Randy Dunlap, linux-kernel On Wed, 2018-01-31 at 04:51 +0100, Mike Galbraith wrote: > On Sun, 2018-01-28 at 12:19 -0800, Joe Smith wrote: > > Thanks a lot, Mike. Following your suggestions worked !!!! > > Until Monday happened :) And during a rare non-lazy-sod moment... --- task.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) --- a/task.c +++ b/task.c @@ -438,8 +438,21 @@ task_init(void) len = SIZE(task_union)); machdep->stacksize = len; } else if (VALID_SIZE(thread_union) && - ((len = SIZE(thread_union)) != STACKSIZE())) + ((len = SIZE(thread_union)) != STACKSIZE())) { machdep->stacksize = len; + } else { + /* + * Post kernel commit 0500871f21b2, init_thread_union size + * became zero. Use __end_init_task - __start_init_task. + */ + if (kernel_symbol_exists("__start_init_task") && + kernel_symbol_exists("__end_init_task")) { + len = symbol_value("__end_init_task"); + len -= symbol_value("__start_init_task"); + ASSIGN_SIZE(thread_union) = len; + machdep->stacksize = len; + } + } MEMBER_OFFSET_INIT(pid_namespace_idr, "pid_namespace", "idr"); MEMBER_OFFSET_INIT(idr_idr_rt, "idr", "idr_rt"); ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2018-01-31 16:04 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-01-26 20:52 crash binary for latest unreleased kernel Joe Smith 2018-01-27 4:32 ` Mike Galbraith 2018-01-27 4:38 ` Randy Dunlap 2018-01-27 4:48 ` Mike Galbraith 2018-01-28 8:37 ` Joe Smith 2018-01-28 9:20 ` Mike Galbraith 2018-01-28 10:00 ` Mike Galbraith 2018-01-28 20:19 ` Joe Smith 2018-01-31 3:51 ` Mike Galbraith 2018-01-31 16:03 ` Mike Galbraith
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox