On Tue, 27 Nov 2007, Luis R. Rodriguez wrote: > > root@OpenWrt:/# iwlist eth1 scanning > > Data bus error, epc == c011518c, ra == c01146cc > > Oops[#1]: > > Cpu 0 > > $ 0 : 00000000 1000b800 abad0000 00000032 > > $ 4 : 00000001 c00c8000 00000013 00000001 > > $ 8 : 0000003c 80102bd4 ffffffff 81e2101c > > $12 : ffffffff 00000580 2ab8af24 00000498 > > $16 : 81e21680 000000fa 81339380 0000004a > > $20 : 81339380 00000000 a1e80000 81339000 > > $24 : 00000000 2abd55e0 > > $28 : 813b4000 813b5cc8 00000019 c01146cc > > Hi : 00000000 > > Lo : 00000580 > > epc : c011518c Not tainted > > ra : c01146cc Status: 1000b803 KERNEL EXL IE > > Cause : 0000001c > > PrId : 00029007 > > I can see that this comes from arch/mips/kernel/traps.c do_be() but I > fail to see when this is triggered. Perhaps someone from linux-mips > might be able to help shed some light here. I tried looking into the > stack trace before but I couldn't find any code that made me suspect > of a possible big endian problem (it seems that may be the problem?). > The stack trace used to look like this: [...] > > Code: 10800014 24020002 3c02abad <8ca30010> 3442face 1462000f > > 24020008 08045470 00000000 > > Segmentation fault Well, a data bus error is caused by external hardware signalling a transaction error on a data read operation (there is an instruction bus error counterpart). A possible reason is a data parity or irrecoverable ECC error or a bus timeout when accessing an unpopulated location. In this case the faulting instruction is 8ca30010, which is lw v1,16(a1) and a1 is 0xc00c8000 above. I guess you need to find out where the mapping for this virtual address is established and what physical address and thus device (if any at all) it corresponds to. Maciej
