Re: Oopses with 2.1.8

Philippe Strauss (
Tue, 12 Nov 1996 19:51:48 +0100 (MET)

Thanks for your help, God :)

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++

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 Belmont

Email: <> Homepage: