All I am going to try to reset the box to factory defaults and try to make it crash again today . I’ll update you with my outcome .
--- Mark Saad | nones...@longcount.org > On Jun 11, 2019, at 1:15 AM, Kubilay Kocak <ko...@freebsd.org> wrote: > >> On 6/06/2019 5:04 am, Mark Saad wrote: >>> On Wed, Jun 5, 2019 at 2:42 PM Mark Saad <nones...@longcount.org> wrote: >>> >>>> On Wed, Jun 5, 2019 at 12:29 PM Mark Saad <nones...@longcount.org> wrote: >>>> >>>> All >>>> I was wondering if anyone could shed some light on this boot panic I >>>> saw yesterday. This is on a Dell R630 with Bios 2.9.1 booting >>>> 12.0-STABLE-r348203 amd64. >>>> I reverted this back to 12.0-RELEASE-p4 and its fine . >>>> >>>> The only custom options I had were in loader.conf >>>> >>>> kern.geom.label.gptid.enable="0" >>>> ipmi_load="YES" >>>> boot_multicons="YES" >>>> boot_serial="YES" >>>> console="comconsole,vidconsole" >>>> net.inet.tcp.tso="0" >>>> cc_htcp_load="YES" >>>> autoboot_delay="5" >>>> hw.mfi.mrsas_enable="1" >>>> hw.usb.no_pf="1" # Disable USB packet filtering >>>> hw.usb.no_shutdown_wait="1" >>>> hw.vga.textmode="1" # Text mode >>>> machdep.hyperthreading_allowed="0" >>>> >>>> Any ideas ? >>>> >>>> Screen shot here >>>> https://imgur.com/a/nGvHtIs >>>> >>>> -- >>>> mark saad | nones...@longcount.org >>> >>> Plain text version of the crash >>> >>> Loading kernel... >>> /boot/kernel/kernel text=0x168d811 data=0x1cf968+0x768c80 >>> syms=[0x8+0x1778e8+0x8 / >>> +0x194f1d] >>> Loading configured modules... >>> /boot/kernel/ipmi.ko size 0x11e10 at 0x2645000 >>> loading required module 'smbus' >>> /boot/kernel/smbus.ko size 0x2ef0 at 0x2657000 >>> /boot/entropy size=0x1000 >>> /boot/kernel/cc_httcp.ko size 0x2330 at 0x265b000 >>> ---<<BOOT>>---c_hmodule 'smbus' >>> Copyright (c) 1992-2019 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 12.0-STABLE r348693 GENERIC amd64 >>> FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on >>> LLVM 8.0.0) >>> panic: UMA zone "UMA Zones": Increase vm.boot_pages >>> cpuid = 0 >>> time = 1 >>> KDB: stack backtrace: >>> #0 0xffffffff80c16df7 at ??+0 >>> #1 0xffffffff80bcaccd at ??+0 >>> #2 0xffffffff80bcab23 at ??+0 >>> #3 0xffffffff80f0b03c at ??+0 >>> #4 0xffffffff80f08d8d at ??+0 >>> #5 0xffffffff80f0bb3d at ??+0 >>> #6 0xffffffff80f0b301 at ??+0 >>> #7 0xffffffff80f0b3d1 at ??+0 >>> #8 0xffffffff80f066c4 at ??+0 >>> #9 0xffffffff80f0543f at ??+0 >>> #10 0xffffffff80f23aef at ??+0 >>> #11 0xffffffff80f1133b at ??+0 >>> #12 0xffffffff80b619c8 at ??+0 >>> #13 0xffffffff8036a02c at ??+0 >>> Uptime: 1s >>> >>> >>> Also increasing the vm.boot_pages to 128 in the loader works. Anyone >>> know why ? This box has 64G ram. >>> >>> -- >>> mark saad | nones...@longcount.org >> So after some poking in the bios this has to do with how the Dell NUMA >> options are set. If the system is set Cluster On Die mode, you get a >> kernel panic >> Home Snoop or Early Snoop no issue. > > Hi Mark, > > Could you report this bug (Bugzilla) if you haven't already, providing: > > - exact freebsd version(s) reproducible with > - panic/backtrace output as an attachment. Ideally with a debug kernel > - /var/run/dmesg.boot output (as an attachment) in a verbose boot > - if you can test a current snapshot, that would be great > - any other system information you believe might be helpful in isolating root > cause(s) or potential fixes > > Thanks! > Feel free to CC me on it _______________________________________________ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
