On 2018-10-25 4:37 PM, John David Anglin wrote:
On 2018-10-25 11:58 AM, John David Anglin wrote:
parisc_kernel_start() doesn't seem to whack TLB. This suggests that
__flush_tlb_range() call in set_kernel_text_rw() didn't work as
expected.
Yes, seems so.
This system has only one CPU, so one flush_tlb_all_local() should
have been sufficient.
Yes, I believe only one CPU is up at this point.
On a SMP system, more may be up, but in a waiting loop...
I tested using flush_tlb_all_local() on my c8000 (SMP with four CPUs)
and it booted okay a couple of times.
I think if we see this bug using flush_tlb_all_local() then the
problem must be with map_pages().
The possibility that sr1 is being corrupted seems unlikely.
On further consideration, I think this must be a cache issue - a form of
inequivalent aliasing. The TLB
handler loads page table entries using absolute addressing while
map_pages() is using virtual addressing.
I think on reboot we must sometimes end up with stale cache entries for
the page table. As a result,
the TLB handler loads the wrong value causing the fault. Probably, some
additional flushing is needed
to fix this.
Dave
--
John David Anglin dave.anglin@xxxxxxxx
