In particular, compare below to what happens in a normal non access
fault:
nadtlb_miss_11:
get_pgd spc,ptp
space_check spc,t0,nadtlb_fault
L2_ptep ptp,pte,t0,va,nadtlb_check_alias_11
update_ptep ptp,pte,t0,t1
make_insert_tlb_11 spc,pte,prot
mfsp %sr1,t0 /* Save sr1 so we can use it in tlb
inserts */
mtsp spc,%sr1
idtlba pte,(%sr1,va)
idtlbp prot,(%sr1,va)
mtsp t0, %sr1 /* Restore sr1 */
rfir
nop
On 14-May-12, at 6:38 PM, 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.
Dave
--
John David Anglin dave.anglin@xxxxxxxx
--
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
--
John David Anglin dave.anglin@xxxxxxxx
--
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