Kernel oops while duming user core.

[Nathan Lynch]

Scott Wood wrote:
> On Thu, Jan 31, 2008 at 11:40:04AM -0600, Rune Torgersen wrote:
> > Unable to handle kernel paging request for data at address 0x48024000
> > Faulting instruction address: 0xc000f0a0
> > Oops: Kernel access of bad area, sig: 11 [#1]
> > PREEMPT Innovative Systems ApMax
> 
> Does it happen without preempt?
> 
> > Modules linked in: drv_wd(P) drv_scc devcom drv_pcir tipc drv_ss7
> > drv_auxcpu drv_leds(P) drv_ethsw proc_sysinfo(P) i2c_8266(P)
> > NIP: c000f0a0 LR: c0011fec CTR: 00000080
> > REGS: eebe9b70 TRAP: 0300   Tainted: P         (2.6.24-test)
> 
> Does it happen without the modules?

I doubt the modules are the problem; there was a practically identical
report from someone with an untainted 2.6.24-rc kernel a few weeks ago
(see my first reply to Rune).

> 
> > MSR: 00009032 <EE,ME,IR,DR>  CR: 24004442  XER: 00000000
> > DAR: 48024000, DSISR: 20000000
> 
> Hmm, this doesn't look like a valid DSISR, so I'm guessing this was a TLB
> miss that got redirected to DataAccess (or is there something that causes
> DSRISR[2] to be set on 8280?  I didn't see anything in the manual...). 
> However, SRR1 in that case seems to indicate a store, which dcbst shouldn't
> generate (except on 8xx, according to the comment in update_mmu_cache).
> 
> Do you have a simple test case that we could try to reproduce?  I tried a
> simple core dump on an 8280, and it worked.

Is the crashing program multithreaded?  The first report had firefox
triggering the oops.