Project

General

Profile

Actions

Bug #817

closed

page fault during boot on latest -HEAD

Added by rumcic about 17 years ago. Updated about 17 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

Description

While booting, the machine panics (before mounting everything), pictures are:
http://www.rumko.net/dragonfly/DSC00156.JPG
http://www.rumko.net/dragonfly/DSC00157.JPG
http://www.rumko.net/dragonfly/DSC00158.JPG

I can't seem to be able to get a dump, so ... I can't provide it (nor "panic"
nor "call dumpsys" make a dump).
--
Regards,
Rumko

Actions #1

Updated by joerg1 about 17 years ago

Hi,

I'm experiencing the very same effect after I upgraded to latest HEAD
yesterday, the machine panics right before fsck'ing/mounting. I also
cannot produce dump files...

--j

On Mon, 01 Oct 2007 01:54:49 +0200, Rumko <> wrote:

Actions #2

Updated by dillon about 17 years ago

:Hi,
:
:I'm experiencing the very same effect after I upgraded to latest HEAD
:yesterday, the machine panics right before fsck'ing/mounting. I also
:cannot produce dump files...
:
:--j

Ok, on both reports it looks like some recent sysctl work must have
broken sysctl. The kernel does a sysctl -a while booting in order
to help seed the random number generator.
Rumko, could you do a 'nm -n /kernel' (or wherever that kernel binary
resides) and track down the function containing the address 0xc045d724 ?
I'm guessing is related to the recent network/polling work.
-Matt
Matthew Dillon
&lt;&gt;
Actions #3

Updated by rumcic about 17 years ago

Interesting ... "nm -n /kernel | grep -i c045d724" returns ... nothing. A
function is missing?

Actions #4

Updated by dillon about 17 years ago

:Interesting ... "nm -n /kernel | grep -i c045d724" returns ... nothing. A
:function is missing?

No, it's not the start of a function, its in the middle of a function
so you have to find the address which comes before that one.
-Matt
Actions #5

Updated by rumcic about 17 years ago

nm -n /kernel | grep -i c045d7
c045d71c T strlen
c045d740 T strncmp
c045d790 T strncpy
c045d7d0 T strtol

strlen?

Actions #6

Updated by joerg about 17 years ago

For a debug kernel, addr2line is very helpful.

Joerg

Actions #7

Updated by dillon about 17 years ago

:c045d740 T strncmp
:c045d790 T strncpy
:c045d7d0 T strtol
:
:strlen?

Yah, we'll need a stack backtrace to see who called it.  It's probably
a sysctl somewhere. Can you get to a DDB prompt ?
-Matt
Actions #9

Updated by dillon about 17 years ago

:http://www.rumko.net/dragonfly/DSC00156.JPG
:http://www.rumko.net/dragonfly/DSC00157.JPG
:http://www.rumko.net/dragonfly/DSC00158.JPG
:
:this enough?
:
:Matthew Dillon wrote:

No good, it looks like it can't trace back from the fault
frame.
Hmm.  Can you boot into single-user mode and set the dump device
manually? Then exit out of the single-user shell to complete a
normal boot and hopefully get a kernel core dump out of it.
-Matt
Actions #10

Updated by rumcic about 17 years ago

Also, seems that this issue has been split a bit ... check issue821 and issue820

Seems to be working now.

Thank you Matt.

Actions

Also available in: Atom PDF