7.0 broken on e4500

[John Baldwin]

On Saturday 06 October 2007 09:26:20 am Marius Strobl wrote:
> On Sat, Oct 06, 2007 at 02:22:30AM -0400, John Baldwin wrote:
> > On Wednesday 03 October 2007 09:29:44 am Marius Strobl wrote:
> > > On Sat, Sep 29, 2007 at 09:56:45PM +0200, Kris Kennaway wrote:
> > > > I get this early during boot with a CVS kernel (updated from last 
> > December):
> > > > 
> > > > > FreeBSD/SMP: Multiprocessor System Detected: 10 CPUs
> > > > > panic: tsb_tte_enter: replacing valid kernel mapping
> > > > > cpuid = 0
> > > > > KDB: enter: panic
> > > > > [thread pid 0 tid 0 ]
> > > > > Stopped at      kdb_enter+0x68: ta              %xcc, 1
> > > > > db> wh
> > > > > Tracing pid 0 tid 0 td 0xc0744f80
> > > > > panic() at panic+0x204
> > > > > tsb_tte_enter() at tsb_tte_enter+0xdc
> > > > > pmap_enter_locked() at pmap_enter_locked+0x2d0
> > > > > pmap_enter() at pmap_enter+0x64
> > > > > kmem_malloc() at kmem_malloc+0x6e0
> > > > > page_alloc() at page_alloc+0x28
> > > > > uma_large_malloc() at uma_large_malloc+0x44
> > > > > malloc() at malloc+0x1b0
> > > > > sf_buf_init() at sf_buf_init+0xf8
> > > > > mi_startup() at mi_startup+0x18c
> > > > > btext() at btext+0x34
> > > > 
> > > 
> > > Do you by chance load the new kernel manually via the loader
> > > prompt, with the old kernel being <= 8MB in size and the new
> > > one > 8MB?
> > 
> > I get this panic on an E220R at work, but my "new" kernel is smaller.
> > 
> 
> If the actual panic string is "vm_phys_paddr_to_vm_page: paddr <foo>
> is not in any segment" than that's the problem I had in mind when
> replying to Kris but unfortunately failed to describe the right
> way around.

No, I get a page fault type panic:

lock order reversal:
 1st 0xfffff800bff00208 system map (system map) @ vm/vm_kern.c:295
 2nd 0xc048cb58 pmap (pmap) @ sparc64/sparc64/pmap.c:1270
 3rd 0xfffff800bff000d8 system map (system map) @ vm/vm_map.c:3073
KDB: stack backtrace:
witness_checkorder() at witness_checkorder+0x9e8
_mtx_lock_flags() at _mtx_lock_flags+0x110
_vm_map_lock_read() at _vm_map_lock_read+0x1c
vm_map_lookup() at vm_map_lookup+0x2c
vm_fault() at vm_fault+0x7c
trap_pfault() at trap_pfault+0x238
trap() at trap+0x388
-- fast data access mmu miss tar=0 %o7=0xc031f418 --
pmap_remove_tte() at pmap_remove_tte+0x104
pmap_enter_locked() at pmap_enter_locked+0x380
pmap_enter() at pmap_enter+0x64
kmem_malloc() at kmem_malloc+0x47c
page_alloc() at page_alloc+0x28
uma_large_malloc() at uma_large_malloc+0x44
malloc() at malloc+0x1a0
sf_buf_init() at sf_buf_init+0xe8
mi_startup() at mi_startup+0x1e8
btext() at btext+0x34
panic: trap: fast data access mmu miss

> Correct, the immediate problem (which I had a patch for somewhere)
> is that in case the "old" kernel required more TLB slots to be used
> than the "new" one one can't use the kernel end in order to determine
> how many slots are used for the kernel map. As you describe the real
> problem lies within the loader though. The funny thing is that no
> arch except sparc64 and sun4v seems to rely on the kernel end
> provided by the loader.

x86 just use _end I think?  I don't think there is an easy way to fix the 
loader FWIW, but if we could at least get the kernel to toss out the TLB 
slots that aren't being used by the current kernel + modules perhaps that 
would be a good start?

-- 
John Baldwin