On Thu, Dec 11, 1997 at 06:12:24AM -0500, Michael Hill wrote:
> Got a bus error IRQ, shouldn't happen yet
> $0 : 00000000 00000000 0007c000 8007d000
> $4 : 00000080 89f7d000 1000fc01 8007cfe0
> $8 : 80000000 00000000 00009f7c 8813de68
> $12: 00000001 00000001 00000001 fffffffc
> $16: 09f7c000 89f7c000 00000000 00000000
> $20: a87ffc20 a8746d60 9fc556d4 00000000
> $24: 1000fc01 0000000f
> $28: eb3b6f7f 89f81d90 00000001 880f2890
> epc : 88026918
> Status: 1000fc03
> Cause : 00004000
Ok, I did some further analysis. Dissassembling shows that Benjamin's
report doesn't really contain useful data. His machine took the
bus error interrupt while processing some other exception. Michael's
machine took the bus error at the end of r4k_flush_page_to_ram_d32i32_r4600()
which is being called during sgiwd33.c:sgiwd93_detect().c.
Since the R4600 v2.0 is running rocksolid - my RM200 is up for over two
weeks - the problem seems to be in the SGI specific code in the function
that handles the Indy style l2 caches.
Hmm... I just noticed in Benjamin's startup messages that his machine
doesn't print a message (``Enabling R4600 SCACHE'') about activating the
second level cache. I bet both your and Benjamin's machines don't have
second level caches. Could you check the hinv output, please?
William: would an attempt to manipulate the R4600 second level cache on
a Indy without such a cache result in a bus error interrupt?