hi,

I'm not sure why this change would cause this problem.  
from what I can tell, all the callers of MachTLBUpdate()
should be ok if it doesn't create a TLB entry.  also,
all of those paths allow interrupts before any new TLB entry
could actually be used, and the interrupt processing could touch
enough pages to result in the TLB entry being recycled, so the
TLB entry might be gone before it does any good anyway.
if there any cases that depend on MachTLBUpdate() creating a
TLB entry then they need to be fixed, since MachTLBUpdate()
cannot guarantee anything.

I see the same behavior as in PR 30590 on a mobilepro 880,
but when I use rev. 1.15 it still crashes when starting init with:
init: trying /sbin/init
trap: reserved instruction in kernel mode
status=0x803, cause=0x428, epc=0x8024cb48, vaddr=0xc0036c38
curlwp == NULL ksp=0xc4185858
Stopped at      0x8024cb48:     lw      s0,56(a0)
db> 

this kinda looks like one of those things where a nested exception is
being reported in a confusing way.

the 2.0.2 GENERIC binary doesn't work for me either, so maybe something
more basic is wrong.  I'm using the hpcboot.exe from the latest 3.x snapshot,
will that work for 2.x and later kernels?


you could try changing the MIPS3 MachTLBUpdate() to do the same work that
the TLB-miss handler does, ie. fetch both PTEs and insert the appropriate
TLB entry if either page is valid.  if that works then I guess we'll have
to do it that way for now.

-Chuck



On Sat, Aug 27, 2005 at 02:08:51PM +0900, Izumi Tsutsui wrote:
> Today I'm working to update Uchiyama-san's NetBSD/ews4800mips port
> (see http://mail-index.netbsd.org/port-mips/2004/06/27/0000.html),
> but it seems this mipsX_subr.S rev 1.16 change causes kernel panic
> right after cpu_configure(9) is finished:
> 
> ---
>  :
> NetBSD 3.99.8 (CEDIA) #69: Sat Aug 27 13:53:22 JST 2005
>  :
> NEC EWS4800/360AD (TR2A) 150MHz
> total memory = 32768 KB
> avail memory = 29208 KB
> mainbus0 (root)
> cpu0 at mainbus0: MIPS R4400 CPU (0x450) Rev. 5.0 with MIPS R4010 FPC Rev. 0.0
> cpu0: 16KB/32B direct-mapped L1 Instruction cache, 48 TLB entries
> cpu0: 16KB/16B direct-mapped write-back L1 Data cache
> cpu0: 1024KB/128B direct-mapped write-back L2 Unified cache
> sbd0 at mainbus0
>  :
> fb0 at sbd0 at 0xf0000000, 0xf5f00000
> wsdisplay0 at fb0 kbdmux 1: console (std, vt100 emulation), using wskbd0
> wsmux1: connecting to wsdisplay0
> trap: TLB miss (load or instr. fetch) in kernel mode
> status=0x2004ff02, cause=0x8008, epc=0x8019b55c, vaddr=0x0
> pid=0 cmd=swapper usp=0x0 ksp=0x802f6bc0
> Stopped in pid0.1 (swapper) at netbsd:uvm_pageidlezero+0x280:   beq     s0,v0,<uvm_pageidlezero+33c>    [addr:0x8019b618]
>         bdslot: sw      s1,0(a1)
> db>
> 
> ("scsibus0: waiting 2 seconds for devices to settle..." should
>  appear after wsmux1 line)
> ---
> The actual function where panic happens is inline uvm_pageinsert_after().
> 
> Furthermore, pmap_kenter_pa(9) (which is used to map framebuffer VRAM)
> shows some strange behavior. The VRAM (at paddr 0xf0000000) is mapped
> by pmap_kenter_pa(9) to VA allocated by uvm_km_alloc() with
> UVM_KMF_VAONLY flag, and on my 4800/360AD the VA is 0xc3029000.
> But when the fb driver tries to write data to top of VRAM via
> the VA 0xc3029000, the data is written VRAM at PA 0xf0029000.
> 
> Reverting mipsX_subr.S 1.16 solves both problems.
> (There is another PR (kern/30590) on hpcmips about this change)
> 
> Any thoughts?
> A new TLB entry need be created in MIPS3 MachTLBUpdate() on some case?
> 
> Note arc (Express5800/230, R4400, 256MB), sgimips (O2, R5000, 192MB)
> and cobalt (RaQ2, Rm5200, 256MB) have no problem with rev 1.16.
> ---
> Izumi Tsutsui