r223378 panic [Re: sparc64 r228561 panic: kmem_suballoc: bad status return of 3]

Marius Strobl marius at alchemy.franken.de
Wed Jan 11 19:41:52 UTC 2012


On Tue, Jan 10, 2012 at 01:46:01PM +0000, Anton Shterenlikht wrote:
> On Fri, Jan 06, 2012 at 11:21:27AM +0000, Anton Shterenlikht wrote:
> > On Fri, Dec 16, 2011 at 05:10:31PM +0100, Marius Strobl wrote:
> > > On Fri, Dec 16, 2011 at 11:19:22AM +0000, Anton Shterenlikht wrote:
> > > > On Fri, Dec 16, 2011 at 11:37:20AM +0100, Marius Strobl wrote:
> > > > > On Fri, Dec 16, 2011 at 08:40:48AM +0000, Anton Shterenlikht wrote:
> > > > > > Updating from r216048 to r228561 on sparc64,
> > > > > > with sys/conf/newvers.sh changed to REVISION="9.9".
> > > > > > 
> > > > > > Trinscribed by hand:
> > > > > > 
> > > > > > FreeBSD 9.9-CURRENT #3 r228561M:
> > > > > > 
> > > > > > panic: kmem_suballoc: bad status return of 3
> > > > > > KDB: enter: panic
> > > > > > [ thread pid 0 tid 0 ]
> > > > > > Stopped at 0x02937e0:   ta    %xcc,1
> > > > > > db>
> > > > > > 
> > > > > > The keyboard froze, couldn't get a bt,
> > > > > > required a cold reboot.
> > > > > > 
> > > > > > My /etc/make.conf and kernel config files are below.
> > > > > > 
> > > > > > Any advice?
> > > > > > 
> > > > > 
> > > > > Hrm, doesn't look like I can reproduce this. What machine model is
> > > > > that and how much RAM does it have?
> > > > 
> > > > >From dmesg:
> > > > 
> > > > real memory  = 2147483648 (2048 MB)
> > > > avail memory = 2079449088 (1983 MB)
> > > > cpu0: Sun Microsystems UltraSparc-IIIi Processor (1503.00 MHz CPU)
> > > > 
> > > > > Do you use any loader tuneables?
> > > > 
> > > > I don't think so. You mean like /boot/loader.conf?
> > > > I haven't got this file at all.
> > > > 
> > > 
> > > Even with a Blade 1500, which is the closest match to your machine
> > > that I have, and a kernel built with your configuration file I can't
> > > reproduce this using r228583. I'd suggest to test with a kernel built
> > > using an empty object directory and without any local modifications.
> > > If that still doesn't solve the problem given that there isn't even
> > > a backtrace I just can suggest to do a binary search for the offending
> > > commit, probably accounting especially for the changes to the VM
> > > within the window of revisions in question.
> > 
> > It took a while.
> > 
> > 223377 - ok
> > 223378 - panic
> > 
> > # svn up -r 223378
> > Updating '.':
> > U    sys/sparc64/include/tsb.h
> > U    sys/sparc64/include/vmparam.h
> > Updated to revision 223378.
> > 
> > # svn diff -c 223378
> > Index: sys/sparc64/include/tsb.h
> > ===================================================================
> > --- sys/sparc64/include/tsb.h	(revision 223377)
> > +++ sys/sparc64/include/tsb.h	(revision 223378)
> > @@ -50,7 +50,6 @@
> >  extern vm_size_t tsb_kernel_mask;
> >  extern vm_size_t tsb_kernel_size;
> >  extern vm_paddr_t tsb_kernel_phys;
> > -extern u_int tsb_kernel_ldd_phys;
> >  
> >  static __inline struct tte *
> >  tsb_vpntobucket(pmap_t pm, vm_offset_t vpn)
> > Index: sys/sparc64/include/vmparam.h
> > ===================================================================
> > --- sys/sparc64/include/vmparam.h	(revision 223377)
> > +++ sys/sparc64/include/vmparam.h	(revision 223378)
> > @@ -218,7 +218,7 @@
> >   * is the total KVA space allocated for kmem_map.
> >   */
> >  #ifndef VM_KMEM_SIZE_SCALE
> > -#define	VM_KMEM_SIZE_SCALE	(3)
> > +#define	VM_KMEM_SIZE_SCALE	(tsb_kernel_ldd_phys == 0 ? 3 : 1)
> >  #endif
> >  
> >  /*
> > @@ -238,6 +238,7 @@
> >  
> >  #define	UMA_MD_SMALL_ALLOC
> >  
> > +extern u_int tsb_kernel_ldd_phys;
> >  extern vm_offset_t vm_max_kernel_address;
> >  
> >  /*
> > 
> 
> I just realised that I have another blade 1500 silver,
> which runs 226827:
> 
> FreeBSD 9.0-RC1 #2 r226827: Thu Oct 27 15:51:42 BST 2011
>     root at mech-as222.men.bris.ac.uk:/usr/obj/usr/src/sys/DALET sparc64
> WARNING: WITNESS option enabled, expect reduced performance.
> real memory  = 5368709120 (5120 MB)
> avail memory = 5230305280 (4988 MB)
> cpu0: Sun Microsystems UltraSparc-IIIi Processor (1503.00 MHz CPU)
> 
> However, if I try to use that revision on the
> problem box, I still get this panic. What's going on?
> 

So far I didn't have time to look into this. I suspect the issue
has to do with the holes USIIIi machines tend to have in their
physical memory layout. For a b1k5 with 2GB RAM such a hole might
be large enough to trigger some bug in the VM but not trigger
with 4GB or as in my case with 1GB.

Marius



More information about the freebsd-sparc64 mailing list