Here is the call trace in symbolic form. This particular oops
came very early (while booting), sometime i am able to use
2.1.8 for 5 - 10 minutes.
ksymoops is suposed to give the call trace automagically,
but mine don't :( (libg++2.7.2.1)
c01259a5 - unlock_buffer
c01a6313 - end_scsi_request
c01a67e9 - rw_intr
c01a2ac4 - scsi_done
c01ae685 - ncr_complete
c01ae6aa - ncr_complete
c01ae70f - ncr_wakeup
c0111680 - timer_bh
c01ad621 - ncr_intr
c01b1753 - ncr53c8xx_intr
c010c8ca - do_fast_IRQ
c010c391 - fast_IRQ12_interrupt
c0109654 - sys_idle
c010a7e8 - system_call
c0109348 - init
c01091c3 - start_kernel
c01c5e5d - _etext
c0116c08 - it_real_fn
Lots of ncrBsd stuff, I didn't supposed ncrBsd to be guilty since
I was using the same version (1.14b) with 2.1.7 without any problem..
I change my mind. On one of my 2.1.8 compile, I had applied the
patch 1.14b -> 1.14c, but it still oops & crash.
>
> However, the "funny" thing is that the same pointer should have been used
> at the top of the for() loop that the test is inside, so the exception
> should have happened much earlier. That's why I'd like to see the
> symbolic version of the call trace, because I suspect the panic comes
> from something jumping through a corrupt pointer, and I'd like to know
> who the jumper is..
>
> > What are thos nop'ses replacing the movl?? Self modifying code? Shitty DRAM?
> > Something in kernel space writing stuff around?
>
> No, it's just that the kernel panic doesn't give more than 20 bytes of
> instructions, and the disassembler will give bogus disassembly for the
> last bytes due to incomplete partial instructions.
Ok ok, i will sleep better :)
> Oh, and you might just try out 2.1.9, which has some fixes to the
> networking code, maybe it makes a difference..
>
> Linus
>
Sure i will, but first i will recompile 2.1.8 with ncrBsd trimmed down
(5MHz sync, 4 tag/queue)
Regards, Philippe
-- Philippe Strauss, CH-1092 BelmontEmail: <philippe.strauss@urbanet.ch> Homepage: http://sicel-home-1-4.urbanet.ch