On Tue, 2012-05-15 at 20:50 +0200, Helge Deller wrote: > On 05/15/2012 08:23 PM, John David Anglin wrote: > > On 5/15/2012 5:13 AM, James Bottomley wrote: > >> On Tue, 2012-05-15 at 09:09 +0100, James Bottomley wrote: > >>> On Mon, 2012-05-14 at 18:38 -0400, John David Anglin wrote: > >>>> On 14-May-12, at 6:11 PM, Helge Deller wrote: > >>>> > >>>>> The B160L and the 715/64 (both 32bit-only PA1.X machines) crashed > >>>>> with the following trace. > >>>>> All logs attached. > >>>>> > >>>>> Any ideas? > >>>> This is exactly the same failure as reported by Vincent. > >>>> > >>>> The most likely problem is the PA 1.1 tmpalias support in entry.S is > >>>> broken. For example, > >>>> the cache stride that is loaded in flush_dcache_page_asm to register > >>>> r1 is wrong. Probably, > >>>> the do_alias macro is wrong for PA 1.1. This is hunk of code that > >>>> should be executed > >>>> when a fdc non access fault occurs. > >>>> > >>>> nadtlb_check_alias_11: > >>>> do_alias spc,t0,t1,va,pte,prot,nadtlb_emulate > >>>> > >>>> idtlba pte,(va) > >>>> idtlbp prot,(va) > >>>> > >>>> rfir > >>>> nop > >>>> > >>>> The TLB insert instructions on PA 1.1 have a different format than on > >>>> PA 2.0. I'm not sure > >>>> how this would corrupt r1. > >>>> > >>>> On the other hand, I had asked Vincent to put a "b,n ." instruction > >>>> just before the fdc loop, > >>>> boot, hit the TOC button, and capture the setup registers for the > >>>> flush operation. It's possible > >>>> the stride variable has been clobbered. > >>> Actually, I don't think it's that. I built a PA 1.1 only kernel and > >>> booted it successfully on the C360. That exercises all the _11 paths, > >>> so I don't think there's a code fault. I do think there's a non PA1.1 > >>> instruction in there somewhere that the C360 wouldn't notice. > >> OK, I think this is the problem. We have a depd instruction in do_alias > >> which is now in the _11 fault paths. > >> > >> This should be the fix, if someone wants to test it before I can get > >> around to building it. > >> > >> James > >> > >> --- > >> > >> diff --git a/arch/parisc/kernel/entry.S b/arch/parisc/kernel/entry.S > >> index 6f05944..5350342 100644 > >> --- a/arch/parisc/kernel/entry.S > >> +++ b/arch/parisc/kernel/entry.S > >> @@ -581,7 +581,11 @@ > >> */ > >> cmpiclr,= 0x01,\tmp,%r0 > >> ldi (_PAGE_DIRTY|_PAGE_READ|_PAGE_WRITE),\prot > >> +#ifdef CONFIG_64BIT > >> depd,z \prot,8,7,\prot > >> +#else > >> + depw,z \prot,8,7,\prot > >> +#endif > >> /* > >> * OK, it is in the temp alias region, check whether "from" or > >> "to". > >> * Check "subtle" note in pacache.S re: r23/r26. > > Better check that this fix doesn't break 32-bit PA 2.0 as the seven > > bit are now being deposited > > in a different place. > > > James & Dave - good catches! > > James patch now let my 715/64 boot, but still crashes on my B160L: > > swapper (pid 1): Illegal instruction (code 8) > > YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI > PSW: 00000000000001001110000100001111 Not tainted > r00-03 0004e10f 00000020 101198cc 17c245c0 > r04-07 ffeff000 17ec05f8 007d4000 17e60260 > r08-11 17c5100b fffff000 17e60310 00020000 > r12-15 00000ffc 0000000b 00000000 ffeff000 > r16-19 007d4000 10768020 10000000 17c22db8 > r20-23 17c245c8 108fc000 00000001 00000020 > r24-27 000007d4 0f2fffe0 0000fa80 106e2020 > r28-31 0f2ff000 000074ee 17c24640 000072e6 > sr00-03 00000000 00000001 00000000 00000000 > sr04-07 00000000 00000000 00000000 00000000 > > IASQ: 00000000 00000000 IAOQ: 1010118c 10101190 > IIR: 078113e0 ISR: 00000000 IOR: 0f2ff000 > CPU: 0 CR30: 17c24000 CR31: f0102978 > ORIG_R28: 17ebbe40 > IAOQ[0]: flush_icache_page_asm+0x28/0x7c > IAOQ[1]: flush_icache_page_asm+0x2c/0x7c > RP(r2): flush_cache_page+0x90/0xb0 > Backtrace: OK, so I assume one (the 715) has a shared D and I TLB and the b160 doesn't? James -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
