Bug #817

page fault during boot on latest -HEAD

Added by rumcic almost 7 years ago. Updated almost 7 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

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

History

#1 Updated by joerg1 almost 7 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:

#2 Updated by dillon almost 7 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
<>

#3 Updated by rumcic almost 7 years ago

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

#4 Updated by dillon almost 7 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

#5 Updated by rumcic almost 7 years ago

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

strlen?

#6 Updated by joerg almost 7 years ago

For a debug kernel, addr2line is very helpful.

Joerg

#7 Updated by dillon almost 7 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

#9 Updated by dillon almost 7 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

#10 Updated by rumcic almost 7 years ago

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

Seems to be working now.

Thank you Matt.

Also available in: Atom PDF