----- Original Message ----- > Hello Dave, > > Thanks for the answers. I'll check your suggestions. > > More answers in the text... > ... > > > I'm curious as to how the bash task was related to the module crash? > > Did the bash task write to a procfs interface that the module created > > to then generate the "write 0 to 0xFFFFFFFF"? Does the crash utility > > indicate that the bash task is the panic task? And if so, what does > > its "bt" show? (i.e., the kernel-mode backtrace) > That's correct. > I wrote a kernel module (timecrash.ko) to do the page fault after a timeout elapsed. > The timer is triggered by: echo <timeout_in_second> > /proc/tocrashme > > The 'bt' command shows following: > PID: 892 TASK: c274e550 CPU: 0 COMMAND: "bash" > #0 [c2699d20] crash_kexec at c0492ecc > #1 [c2699d78] oops_end at c07ebbb2 > #2 [c2699d90] no_context at c042d389 > #3 [c2699db8] __bad_area_nosemaphore at c042d4b3 > #4 [c2699df8] bad_area_nosemaphore at c042d57d > #5 [c2699e04] __do_page_fault at c042da5c > #6 [c2699e88] do_page_fault at c07ed531 > #7 [c2699ea4] error_code (via page_fault) at c07eaf3d > EAX: 00000028 EBX: 00000003 ECX: c09e6514 EDX: 00000000 EBP: c2699f20 > DS: 007b ESI: 00000000 ES: 007b EDI: 094a5408 GS: 00e0 > CS: 0060 EIP: f87ad1c6 ERR: ffffffff EFLAGS: 00010296 > #8 [c2699ed8] proc_crash_setdelay at f87ad1c6 [timecrash] > #9 [c2699f24] proc_file_write at c0572856 > #10 [c2699f44] proc_reg_write at c056d5dd > #11 [c2699f68] vfs_write at c051f637 > #12 [c2699f90] sys_write at c051ff38 > #13 [c2699fb0] system_call at c07ea7ad > EAX: 00000004 EBX: 00000001 ECX: 094a5408 EDX: 00000003 > DS: 007b ESI: 00000003 ES: 007b EDI: 094a5408 > SS: 007b ESP: bfd1b6d8 EBP: bfd1b704 GS: 0033 > CS: 0073 EIP: b776a416 ERR: 00000004 EFLAGS: 00000246 > OK, that's good, but you didn't answer the query below: > >> | > >> Disassemble Try: EIP@0xb76312b5 > >> <---------------------------------------------| > >> (gdb) disassemble 0xb7631200, 0xb7631300 > >> Dump of assembler code from 0xb7631200 to 0xb7631300: > >> 0xb7631200: Cannot access memory at address 0xb7631200 > >> (gdb) > >> ---------- > > Anyway, I'm guessing that the 0xb76312b5 IP address is in some > > library, probably libc? If you do a "vm" on the active bash task > > from within the crash utility, you will see where it comes from. > > Try reading the user-space address from the crash utility to see > > if it was available to copy to the core.<pid>.bash file, i.e., > > try this command: > > > > crash> rd -u 0xb76312b5 > > > > The command above presumes that you are in the context of the > > "bash" task while running crash. (i.e., if you enter "set" alone, > > it shows that particular task) > > > > Dave -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility