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. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
