Port-macppc archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: kernel trap



Hi,

On Fri, 23 May 2008, Michael Lorenz wrote:
> On May 23, 2008, at 02:10, Al - image hosting services wrote:
>
> > trap: kernel read DSI trap @ 0xde3a5784 by 0x2e6e1c (DSISR 0x40000000,
> > err=
> >
> > I can't get to the debugger either. I don't know if that will be
> > enough
> > information to figure out what went wrong.
>
> That's not really useful until we find out where the trap really came
> from - the panic message states the address but that can vary
> depending on the kernel image used.
>
> To find out where it happened do this:
> - - load the kernel you ran when the panic happened into gdb ( gdb /
> netbsd.whatever )
> - - disassemble what's at the trap address ( disassemble 0x2e6e1c )
> gdb's assembly output should then tell you which function the code at
> 0x2e6e1c belongs to.

I think that I still have that kernel, but really I think that I have some
bad source or something. I can't understand how the kernels that I am
building now are a different size with the same config. I guess it could
have caused another problem. I used the same source to build userland as I
did on other boxes. Most notably an i386 and I started with a
sparc64. I would just move it from computer to computer. What I noticed is
that the example that I was using includes a -u, so it doesn't do a clean
first. I could have some binaries built with another processor. I am
wondering what is the best way to be sure I am rid of them? I could
install the binaries again and rebuild everything. Although, maybe I need
to start all over again.

Now I use:
./build.sh -O /usr/obj -T /usr/tools tools
./build.sh -D -O /usr/obj -T /usr/tools build
./build.sh -D -O /usr/obj -T /usr/tools install=/

I just can't believe that I made that mistake. I should know better.


> > Anyway, the system is a Blue & White 450 Mhz G3 with an ATTO UL3D
> > with 3 drives.
>
> Hmm, maybe torture it a bit more and see if it panics again, if it
> does see if it happens at the same address. The machine is pretty
> much loaded and I'm not sure what kind of power supply the b&w G3's
> use - might be a little bit too weak for all that stuff.
> So, if it traps again, always at the same address it's either a bug
> or flaky memory. If it traps again but the trap addresses appear to
> be random it might be the power supply. If it's the power supply that
> shouldn't be such a big deal - it's standard ATX but the one Apple
> used is likely only 200W.

This is true. It does only have a 200W power supply. I thought that it
would have a little bigger one because this was the model with the adaptec
scsi. I would have thought with the upgrades this thing had in it they
would have included a larger power supply.

I installed a kernel that I built a while ago and it seems fine.  It has
been running for several days with this kernel and not panicked.

Thanks,
Al





Home | Main Index | Thread Index | Old Index