slaballocation panic on boot

[Galen Sampson]

This one is somewhat interesting.  The kernel didn't panic, but this was the
result.

mkdir -p /tmp/install.38
for prog in [ awk cap_mkdb cat chflags chmod chown  date echo egrep find grep 
ln make makewhatis mkdir mtree mv perl pwd_mkdb rm sed sh sysctl  test true
uname wc zic; do  cp `which $prog` /tmp/install.38;  done
Profiling timer expired
*** Error code 155
 
Stop in /devel/dragonfly/src.
*** Error code 1
 
Stop in /devel/dragonfly/src.

I'm giving up on it for the moment.

regards,
Galen

--- Matthew Dillon <dillon at xxxxxxxxxxxxxxxxxxxx> wrote:
> :--0-380570306-1064544578=:782
> :Content-Type: text/plain; charset=us-ascii
> :Content-Id: 
> :Content-Disposition: inline
> :
> :I would like to bring good news but unfortunately that is not the case.  I
> have
> :updated to sources with todays (9/25) fixes.  The machine running 4.8-p10 is
> :rebooted into the dragonfly kernel so make installworld can be performed.  
> :'make installworld 2>&1 | tee /devel/dragonfly/buildlog/installworld.log'
> does
> :not get written, but on the console only the first shell script 'for _x in [
> :cp....' is printed.  The system always fails here.  Sometimes with ddb,
> :sometimes without.  The panics I have seen have been double faults.  The
> core
> :dumps I have collected yield useless information (see attached).
> :
> :Notes:
> :kernel config is attacted (no slaballoc, no memap)
> :useless crashdump attached
>     
>     Well, at least we know it isn't the slab allocator. 
> 
>     The 4.x gdb will not be able to debug a dragonfly crash dump, but a 
>     dragonfly gdb should.
> 
>     I am somewhat at a loss for the moment.  I suggest putting the crash
>     dump and the dragonfly kernel.debug up on a web or ftp server where
>     I can fetch them.  I'll see if I can garner any information from it.
> 
> 					    -Matt
> 


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com