Opened 8 years ago

Closed 8 years ago

#9842 closed bug (fixed)

x86-64 panics early in boot when built with KDEBUG_LEVEL 0

Reported by: anevilyak Owned by: xyzzy
Priority: normal Milestone: R1
Component: System/Kernel Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: x86-64


This only seems to occur with level 0 specifically ; levels 1 and 2 boot normally here.

A screenshot of the panic screen is attached, along with a readelf dump of the corresponding kernel image. As best as I can tell, the backtrace leading up to the page fault itself was:

 9 ffffffff81004e10 (+ 192) ffffffff80133568 memcpy_generic
10 ffffffff81004ed0 (+  64) ffffffff800fe02e _ZL15write_to_bufferP11ri
11 ffffffff81004f10 (+  16) ffffffff800fe324 ring_buffer_write
12 ffffffff81004f20 (+  48) ffffffff8008dfa6 syslog_write
13 ffffffff81004f50 (+ 128) ffffffff8008ed4f debug_init_post_settings
14 ffffffff81004fd0 (+  32) ffffffff8005d0d3 _start

This seems somewhat puzzling though, since debug_init_post_settings doesn't in fact call syslog_write that I can see, so I may have done something wrong on that front. This panic is 100% reproducible, so please let me know if I can enable anything else to help get more information.

Attachments (3)

IMG_20130629_135445.jpg (1.5 MB ) - added by anevilyak 8 years ago.
kernel_symbols.text (952.4 KB ) - added by anevilyak 8 years ago. (2.5 MB ) - added by anevilyak 8 years ago.
objdump -d output as requested

Change History (7)

by anevilyak, 8 years ago

Attachment: IMG_20130629_135445.jpg added


by anevilyak, 8 years ago

Attachment: kernel_symbols.text added

by anevilyak, 8 years ago

Attachment: added

objdump -d output as requested

comment:1 by korli, 8 years ago

Just a guess, syslog_init_post_vm() could be inlined in debug_init_post_settings(). The first syslog_write() happening there is of variable size and comes from kernel_args. The screenshot indicates a length of 0x321c aka 12828, which should be OK given the size of the syslog ring buffer. What I don't understand is that %rsi should be the source address of the memcpy and happens to be the page fault address too...

comment:2 by xyzzy, 8 years ago

It appears to be reading the debug_output pointer from kernel_args incorrectly. I'm trying to investigate, but GCC has decided it doesn't want to work properly on OS X since I updated buildtools to the latest revision, so I need to fix that first.

comment:3 by xyzzy, 8 years ago

Fixed in hrev45820

comment:4 by xyzzy, 8 years ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.