Opened 11 years ago

Closed 11 years ago

#10433 closed bug (fixed)

KDL Pagefault after scheduler merge during work

Reported by: kallisti5 Owned by: pdziepak
Priority: high Milestone: R1
Component: System/Kernel Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

Got the attached KDL while doing some compile work on hrev46699

Attachments (1)

IMG_20140118_103741.jpg (1.4 MB ) - added by kallisti5 11 years ago.

Download all attachments as: .zip

Change History (9)

by kallisti5, 11 years ago

Attachment: IMG_20140118_103741.jpg added

comment:1 by pdziepak, 11 years ago

Owner: changed from axeld to pdziepak
Status: newassigned

comment:2 by vidrep, 11 years ago

hrev46699 KDL when rebooting. Sorry, did not capture output.

in reply to:  2 comment:3 by anevilyak, 11 years ago

Replying to vidrep:

hrev46699 KDL when rebooting. Sorry, did not capture output.

Probably a different issue, I just saw a panic during shutdown here, which has a very different backtrace from the above.

comment:4 by vidrep, 11 years ago

Sorry, I should have been more clear in my description. Installed hrev46699. Hit "reboot" and it went into kernel panic while shutting down. Is there any method to capture this info other than using the serial output or a camera to take a shot if the screen?

comment:5 by anevilyak, 11 years ago

The options are somewhat limited since if a KDL hits, the overall state of the system can no longer really be trusted, i.e. attempting to write it to disk or anywhere else persistent might corrupt said disk.

There is one option for capturing the in-memory syslog buffer, but I'm uncertain if the KDL session will be written to that or not: If you have a FAT32 USB stick available, plug it in, and then soft reboot from the panic (either by typing 'reboot' at the KDL prompt, or hitting the reset button, but not by powering off/on), and then hold left shift at the very earliest moment of the boot process. This should get you into the boot loader menu, which, if it can a) find the previous syslog buffer, and b) recognize the stick, will present you with an option to write that buffer to it as a file.

Edit: In any case, I've filed ticket #10436 for the shutdown/reboot panic I'm seeing over here, in case the backtrace from that matches yours if you encounter the problem again.

Last edited 11 years ago by anevilyak (previous) (diff)

comment:6 by bonefish, 11 years ago

Yes, the in-memory debug syslog buffer contains the latest output (including the "reboot" command you might type in KDL). As of hrev46707 the buffer is written to the file /var/log/previous_syslog during the next boot. So as long as Haiku can still boot (may even be a different installation), this should now be a relatively convenient way to retrieve it.

comment:7 by pdziepak, 11 years ago

Should be fixed in hrev46711. Please confirm.

comment:8 by kallisti5, 11 years ago

Resolution: fixed
Status: assignedclosed

seems resolved, now getting #10446 Thanks!

Note: See TracTickets for help on using tickets.