Summary: | [boot] Can't boot 9.0-RELEASE/sparc64 on Blade 1500 | ||
---|---|---|---|
Product: | Base System | Reporter: | cpghost |
Component: | sparc64 | Assignee: | freebsd-sparc64 (Nobody) <sparc64> |
Status: | Closed FIXED | ||
Severity: | Affects Only Me | CC: | mmoll |
Priority: | Normal | ||
Version: | 9.0-RELEASE | ||
Hardware: | Any | ||
OS: | Any |
Description
cpghost
2012-01-17 00:50:09 UTC
On 2012-Jan-17 00:47:14 +0000, "C. P. Ghost" <cpghost@cordula.ws> wrote: >Booting a FreeBSD-9.0-RELEASE kernel on a Blade 1500 panics with: > >panic: kmem_suballoc: bad status return of 3 >cpuid = 0 >KDB: stack backtrace: > #0 0xc079841c at ??+0 > #1 0xc04ca59c at ??+0 > #2 0xc0487f90 at ??+0 > #3 0xc0098028 at ??+0 > >This is on a Blade 1500 with 2 GB of RAM. I can reproduce this on my SB1500 but only with 2GB RAM (4x512MB DIMMs) installed. When I install 1GB RAM (4x256MB) or 4GB RAM (4x1GB), FreeBSD-9.0-RELEASE-sparc64-disc1.iso boots successfully. The problem is still present in 10-current: ok boot freebsd Boot device: /pci@1e,600000/ide@d/disk@1,0 File and args: >> FreeBSD/sparc64 boot block Boot path: /pci@1e,600000/ide@d/disk@1,0:a Boot loader: /boot/loader Consoles: Open Firmware console FreeBSD/sparc64 bootstrap loader, Revision 1.0 (root@sb1500.vk2pj.dyndns.org, Fri Jan 6 14:29:31 EST 2012) bootpath="/pci@1e,600000/ide@d/disk@1,0:a" Loading /boot/defaults/loader.conf /boot/kernel/kernel data=0x576f58+0x1fbea8 syms=[0x8+0x7db80+0x8+0x72981] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... jumping to kernel entry at 0xc0070000. KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #4 r229481M: Tue Jan 10 15:54:52 EST 2012 root@sb1500.vk2pj.dyndns.org:/usr/obj/usr/src/sys/sb1500 sparc64 WARNING: WITNESS option enabled, expect reduced performance. panic: kmem_suballoc: bad status return of 3 KDB: stack backtrace: (null)() at 0xc02a0330 (null)() at 0xc04526fc (null)() at 0xc028a894 (null)() at 0xc024da70 (null)() at 0xc0070028 KDB: enter: panic [ thread pid 0 tid 0 ] Stopped at 0xc02d5dc0: ta %xcc, 1 db> bt Tracing pid 0 tid 0 td 0xc0587890 (null)() at 0xc02a0374 (null)() at 0xc04526fc (null)() at 0xc028a894 (null)() at 0xc024da70 (null)() at 0xc0070028 db> Since DDB isn't seeing the symbols, I didn't go further but expanded those addresses later via kgdb: 0x00000000c02a0330 <panic+336>: call 0xc02d6340 <kdb_backtrace> 0x00000000c02a0374 <panic+404>: call 0xc02d5d40 <kdb_enter> 0x00000000c04526fc <kmem_suballoc+124>: call 0xc02a01e0 <panic> 0x00000000c028a894 <kmeminit+756>: call 0xc0452680 <kmem_suballoc> 0x00000000c024da70 <mi_startup+464>: call %g1 0x00000000c0070028 <btext+40>: call 0xc024d8a0 <mi_startup> Overall, this suggests that Marius is correct in his suspicion that this is related to strangeness in the RAM layout. -- Peter Jeremy Author: marius Date: Fri Jan 27 22:25:46 2012 New Revision: 230630 URL: http://svn.freebsd.org/changeset/base/230630 Log: For machines where the kernel address space is unrestricted increase VM_KMEM_SIZE_SCALE to 2, awaiting more insight from alc@. As it turns out, the VM apparently has problems with machines that have large holes in the physical address space, causing the kmem_suballoc() call in kmeminit() to fail with a VM_KMEM_SIZE_SCALE of 1. Using a value of 2 allows these, namely Blade 1500 with 2GB of RAM, to boot. PR: 164227 Modified: head/sys/sparc64/include/vmparam.h Modified: head/sys/sparc64/include/vmparam.h ============================================================================== --- head/sys/sparc64/include/vmparam.h Fri Jan 27 22:24:03 2012 (r230629) +++ head/sys/sparc64/include/vmparam.h Fri Jan 27 22:25:46 2012 (r230630) @@ -218,7 +218,7 @@ * is the total KVA space allocated for kmem_map. */ #ifndef VM_KMEM_SIZE_SCALE -#define VM_KMEM_SIZE_SCALE (tsb_kernel_ldd_phys == 0 ? 3 : 1) +#define VM_KMEM_SIZE_SCALE (tsb_kernel_ldd_phys == 0 ? 3 : 2) #endif /* _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" Author: marius Date: Wed Feb 1 21:09:59 2012 New Revision: 230882 URL: http://svn.freebsd.org/changeset/base/230882 Log: MFC: r230630 For machines where the kernel address space is unrestricted increase VM_KMEM_SIZE_SCALE to 2, awaiting more insight from alc@. As it turns out, the VM apparently has problems with machines that have large holes in the physical address space, causing the kmem_suballoc() call in kmeminit() to fail with a VM_KMEM_SIZE_SCALE of 1. Using a value of 2 allows these, namely Blade 1500 with 2GB of RAM, to boot. PR: 164227 Modified: stable/9/sys/sparc64/include/vmparam.h Directory Properties: stable/9/sys/ (props changed) stable/9/sys/amd64/include/xen/ (props changed) stable/9/sys/boot/ (props changed) stable/9/sys/boot/i386/efi/ (props changed) stable/9/sys/boot/ia64/efi/ (props changed) stable/9/sys/boot/ia64/ski/ (props changed) stable/9/sys/boot/powerpc/boot1.chrp/ (props changed) stable/9/sys/boot/powerpc/ofw/ (props changed) stable/9/sys/cddl/contrib/opensolaris/ (props changed) stable/9/sys/conf/ (props changed) stable/9/sys/contrib/dev/acpica/ (props changed) stable/9/sys/contrib/octeon-sdk/ (props changed) stable/9/sys/contrib/pf/ (props changed) stable/9/sys/contrib/x86emu/ (props changed) Modified: stable/9/sys/sparc64/include/vmparam.h ============================================================================== --- stable/9/sys/sparc64/include/vmparam.h Wed Feb 1 21:08:35 2012 (r230881) +++ stable/9/sys/sparc64/include/vmparam.h Wed Feb 1 21:09:59 2012 (r230882) @@ -218,7 +218,7 @@ * is the total KVA space allocated for kmem_map. */ #ifndef VM_KMEM_SIZE_SCALE -#define VM_KMEM_SIZE_SCALE (tsb_kernel_ldd_phys == 0 ? 3 : 1) +#define VM_KMEM_SIZE_SCALE (tsb_kernel_ldd_phys == 0 ? 3 : 2) #endif /* _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" Author: marius Date: Wed Feb 1 21:10:00 2012 New Revision: 230883 URL: http://svn.freebsd.org/changeset/base/230883 Log: MFC: r230630 For machines where the kernel address space is unrestricted increase VM_KMEM_SIZE_SCALE to 2, awaiting more insight from alc@. As it turns out, the VM apparently has problems with machines that have large holes in the physical address space, causing the kmem_suballoc() call in kmeminit() to fail with a VM_KMEM_SIZE_SCALE of 1. Using a value of 2 allows these, namely Blade 1500 with 2GB of RAM, to boot. PR: 164227 Modified: stable/8/sys/sparc64/include/vmparam.h Directory Properties: stable/8/sys/ (props changed) stable/8/sys/amd64/include/xen/ (props changed) stable/8/sys/cddl/contrib/opensolaris/ (props changed) stable/8/sys/contrib/dev/acpica/ (props changed) stable/8/sys/contrib/pf/ (props changed) stable/8/sys/dev/e1000/ (props changed) Modified: stable/8/sys/sparc64/include/vmparam.h ============================================================================== --- stable/8/sys/sparc64/include/vmparam.h Wed Feb 1 21:09:59 2012 (r230882) +++ stable/8/sys/sparc64/include/vmparam.h Wed Feb 1 21:10:00 2012 (r230883) @@ -222,7 +222,7 @@ * is the total KVA space allocated for kmem_map. */ #ifndef VM_KMEM_SIZE_SCALE -#define VM_KMEM_SIZE_SCALE (tsb_kernel_ldd_phys == 0 ? 3 : 1) +#define VM_KMEM_SIZE_SCALE (tsb_kernel_ldd_phys == 0 ? 3 : 2) #endif /* _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" this got fixed, closing... |