On Tue, 28 Jun 2005, Markus Dahms wrote: > | CPU revision is: 00000430 > | FPU revision is: 00000500 > | ... > | Checking for the multiply/shift bug... yes, workaround... no. > | kernel panic - not syncing: Reliable operation impossible! > | Configure for R4000 to enable the workaround. > > I configured the kernel for R4X00. There are a few references to > CONFIG_CPU_R4000 in the source which doesn't seem to be a config > option anymore, but I couldn't find a workaround somewhere... Well, yesterday evening I realized you mentioned the R4000 which has currently no way to run in the 64-bit mode with upstream Linux as there are grave errata in the CPU (in a couple of 64-bit instructions) that prevent reliable operation. And I mean it -- with no workarounds enabled all I observed with my R4000 in my DECstation were random lock-ups, sometimes even before reaching userland (depending on stuff like cache alignment of some code with a given compilation). I implemented all the necessary workarounds and this includes Linux, GCC and binutils (further bits are needed for handcoded assembly programs if you want to run n32 or (n)64 userland; so far I've identified and fixed glibc and gmp). If you'd like to use this system in the 64-bit mode you are most welcomed. For this you can get toolchain bits from my site and I can supply you with a patch for Linux 2.4; I'll work on porting it to 2.6 and actually applying upstream soon. As you may not be interested in binary RPM packages, you may just pull the necessary patches, which are all called "*-mips-nodaddi-*" and you have to make sure to rebuild all 64-bit binaries to be run on the R4000 with either "-march=r4000" or "-mfix-r4000". Unfortunately at the current state of affairs the GCC patch is not going to be accepted for inclusion upstream which means all the others have to live outside their respective official sources as well. I have successfully run 64-bit Linux on my R4000SC and early R4400SC which are both affected by these errata (but not exactly the same for both ;-) ) for quite some time now. I have actually forgotten to mention you might indeed want to try a 32-bit kernel as some low level bits differ and this is especially true given the above -- sorry about that. > >> I'll also try the said patch (you're referring to "blast_scache nop ...", > >> do you?). > > Precisely. > > doesn't change anything, neither for R4000PC nor for R4600PC. Well, the R4600 case was easy -- proofreading revealed the bug. There is a cp0 hazard between updating a TLB entry and using it for an instruction fetch and for the R4600 it requires two instructions to clear. Unfortunately our handlers currently only execute a lone "eret" after TLB update instructions, which for TLB faults on instruction fetches triggers this hazard. For data transfers there is no hazard in the R4600 and this is why your system has been able to progress through `init'; otherwise you would not see any output from it. Here's a patch. I'm inclined to apply it as obviously correct but I'll resist for a while to let you provide some feedback. The same hazard conditions are present for the R4700 and the R5000. I've included the R5000A as well which, given the name, I've assumed was just a minor update to the R5000; anyone please correct me if I am wrong (but we don't ever use this CPU ID in Linux, so that would be for documentation only). Maciej patch-mips-2.6.12-rc4-20050526-tlbex-r4600-0 diff -up --recursive --new-file linux-mips-2.6.12-rc4-20050526.macro/arch/mips/mm/tlbex.c linux-mips-2.6.12-rc4-20050526/arch/mips/mm/tlbex.c --- linux-mips-2.6.12-rc4-20050526.macro/arch/mips/mm/tlbex.c 2005-04-29 04:56:05.000000000 +0000 +++ linux-mips-2.6.12-rc4-20050526/arch/mips/mm/tlbex.c 2005-06-28 01:14:39.000000000 +0000 @@ -828,11 +828,16 @@ static __init void build_tlb_write_entry i_nop(p); break; - case CPU_R4300: case CPU_R4600: case CPU_R4700: case CPU_R5000: case CPU_R5000A: + i_nop(p); + tlbw(p); + i_nop(p); + break; + + case CPU_R4300: case CPU_5KC: case CPU_TX49XX: case CPU_AU1000:
