Hi,
On 2021/4/30 上午2:04, Thomas Bogendoerfer wrote:
On Mon, Apr 26, 2021 at 09:11:47PM +0800, Huang Pei wrote:
[ 40.873779] Cause : 4080800c (ExcCode 03)
[ 40.877775] BadVA : 77e23000
[ 40.880645] PrId : 00d00100 (Ingenic XBurst)
[ 40.884989] Modules linked in:
[ 40.888034] Process Xsession (pid: 1370, threadinfo=ca5ce8d6,
task=61c8f3ad, tls=77e28690)
!!! This is my first time debug MIPS32 kernel, I think both threadinfo
and task should be at KSEG0, instead of KSEG2 or USEG
don't print pointers with %p they will be garbled for security reasons.
see Documentation/core-api/printk-formats.rst
"A raw pointer value may be printed with %p which will hash the address
before printing."
[ 41.233877] Index: 27 pgmask=4kb va=77e22000 asid=5c
[ 41.233877] [pa=06a17000 c=3 d=0 v=0 g=0] [pa=2017a000 c=0 d=0 v=0
g=0]
!!! TLB entry is loading a SWAP entry(C=0, pa=swap) at BADV, the pte_buddy point to a valid
PFN(C=3, pa seem ok), but it is impossible, since line 116 must flush the tlb and
replaced swap entry with new page
Am I missing something?
not sure, if I'm on the right track, but with the _PAGE_VALID bit set in
the new pte local_r4k_flush_cache_page() will do
if ((mm == current->active_mm) && (pte_val(*ptep) & _PAGE_VALID))
vaddr = NULL;
and then
vaddr ? r4k_blast_dcache_page(addr) :
r4k_blast_dcache_user_page(addr);
flush the address directly instead with r4k_blast_dcache_user_page().
But the TLB will be updated after the cache flush (which is correct IMHO).
So setting the VALID bit too early destroys the logic of flushing
cache aliases. Do you agree ?
I think it is indeed the problem here.
After I tried to drop the _PAGE_VALID mark in the PVA (change it to
"#define PVA(p) PM(_PAGE_ACCESSED | (p))"), the kernel no longer panic.
Thanks and best regards!
Thomas.
