sysctl causes kernel panic

Dennis Chang

Dennis Chang

Hi all,
This is my first post.

I'm trying to troubleshoot my issues with booting from the FreeBSD 10.3 ISO FreeBSD-10.3-RELEASE-i386-disc1.iso. I've traced the issue to sysctl(8). Whenever I perform the following commands:
sysctl -a
sysctl dev

I get a kernel panic. I'm booting the CD off of a Dell Latitude C600. Whenever I boot the same CD off of a Dell Inspiron 8100 I'm ok.

Note: from my C600 I can only boot in single-user mode to run the sysctl(8) command.

When I read /usr/src/sys/sys/sysctl.h I notice that the dev top-level namespace is not defined but declared?

Any idea how dev gets populated?

Thanks,
Dennis
 
Issue I believe is at smist.c
Thanks

Code: 
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address    = 0x302
fault code        = supervisor read, page not present
instruction pointer    = 0x20:0xc1075f45
stack pointer           = 0x28:0xc378d9b0
frame pointer           = 0x28:0xc378d9e8
code segment        = base 0x0, limit 0xfffff, type 0x1b
            = DPL 0, pres 1, def32 1, gran 1
processor eflags    = interrupt enabled, resume, IOPL = 0
current process        = 331 (sysctl)
trap number        = 12
panic: page fault
cpuid = 0
KDB: stack backtrace:
#0 0xc0b7be92 at kdb_backtrace+0x52
#1 0xc0b3c1db at vpanic+0x11b
#2 0xc0b3c0bb at panic+0x1b
#3 0xc10650cb at trap_fatal+0x30b
#4 0xc1065435 at trap_pfault+0x355
#5 0xc1064b04 at trap+0x674
#6 0xc104f96a at calltrap+0x6
#7 0xc0ae676c at cf_levels_method+0x27c
#8 0xc0ae738b at cpufreq_levels_sysctl+0x9b
#9 0xc0b48e1d at sysctl_root+0x26d
#10 0xc0b493fa at userland_sysctl+0x1da
#11 0xc0b491d8 at sys___sysctl+0x98
#12 0xc1065cb9 at syscall+0x5c9
#13 0xc104fa1f at Xint0x80_syscall+0x2f
Uptime: 12s
Physical memory: 231 MB
Dumping 43 MB: 28 12

#0  doadump (textdump=-1012638464) at pcpu.h:233
233    pcpu.h: No such file or directory.
    in pcpu.h
(kgdb) backtrace
#0  doadump (textdump=-1012638464) at pcpu.h:233
#1  0xc0b3be2d in kern_reboot (howto=260)
    at /usr/src/sys/kern/kern_shutdown.c:486
#2  0xc0b3c219 in vpanic (fmt=<value optimized out>, ap=<value optimized out>)
    at /usr/src/sys/kern/kern_shutdown.c:889
#3  0xc0b3c0bb in panic (fmt=0xc116b838 "%s")
    at /usr/src/sys/kern/kern_shutdown.c:818
#4  0xc10650cb in trap_fatal (frame=<value optimized out>, 
    eva=<value optimized out>) at /usr/src/sys/i386/i386/trap.c:1019
#5  0xc1065435 in trap_pfault (frame=0x0, usermode=<value optimized out>, 
    eva=0) at /usr/src/sys/i386/i386/trap.c:835
#6  0xc1064b04 in trap (frame=0xc378d970) at /usr/src/sys/i386/i386/trap.c:532
#7  0xc104f96a in calltrap () at /usr/src/sys/i386/i386/exception.s:173
#8  0xc1075f45 in smist_settings (dev=<value optimized out>, 
    sets=<value optimized out>, count=<value optimized out>)
    at /usr/src/sys/x86/cpufreq/smist.c:494
#9  0xc0ae676c in cf_levels_method (dev=<value optimized out>, 
    count=<value optimized out>) at cpufreq_if.h:95
#10 0xc0ae738b in cpufreq_levels_sysctl (oidp=<value optimized out>, arg1=0x1, 
    arg2=<value optimized out>) at cpufreq_if.h:57
#11 0xc0b48e1d in sysctl_root (arg1=<value optimized out>, 
    arg2=<value optimized out>) at /usr/src/sys/kern/kern_sysctl.c:1531
#12 0xc0b493fa in userland_sysctl (td=0x4, old=<value optimized out>, 
    oldlenp=<value optimized out>, inkernel=<value optimized out>, 
---Type <return> to continue, or q <return> to quit---[B
    new=<value optimized out>, newlen=<value optimized out>, 
    retval=<value optimized out>, flags=<value optimized out>)
    at /usr/src/sys/kern/kern_sysctl.c:1641
#13 0xc0b491d8 in sys___sysctl (uap=0xc378dca8)
    at /usr/src/sys/kern/kern_sysctl.c:1567
#14 0xc1065cb9 in syscall (frame=<value optimized out>) at subr_syscall.c:141
#15 0xc104fa1f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:279
#16 0x00000033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
Current language:  auto; currently minimal
(kgdb) [A backtrace
#0  doadump (textdump=-1012638464) at pcpu.h:233
#1  0xc0b3be2d in kern_reboot (howto=260)
    at /usr/src/sys/kern/kern_shutdown.c:486
#2  0xc0b3c219 in vpanic (fmt=<value optimized out>, ap=<value optimized out>)
    at /usr/src/sys/kern/kern_shutdown.c:889
#3  0xc0b3c0bb in panic (fmt=0xc116b838 "%s")
    at /usr/src/sys/kern/kern_shutdown.c:818
#4  0xc10650cb in trap_fatal (frame=<value optimized out>, 
    eva=<value optimized out>) at /usr/src/sys/i386/i386/trap.c:1019
#5  0xc1065435 in trap_pfault (frame=0x0, usermode=<value optimized out>, 
    eva=0) at /usr/src/sys/i386/i386/trap.c:835
#6  0xc1064b04 in trap (frame=0xc378d970) at /usr/src/sys/i386/i386/trap.c:532
#7  0xc104f96a in calltrap () at /usr/src/sys/i386/i386/exception.s:173
#8  0xc1075f45 in smist_settings (dev=<value optimized out>, 
    sets=<value optimized out>, count=<value optimized out>)
    at /usr/src/sys/x86/cpufreq/smist.c:494
#9  0xc0ae676c in cf_levels_method (dev=<value optimized out>, 
    count=<value optimized out>) at cpufreq_if.h:95
#10 0xc0ae738b in cpufreq_levels_sysctl (oidp=<value optimized out>, arg1=0x1, 
    arg2=<value optimized out>) at cpufreq_if.h:57
#11 0xc0b48e1d in sysctl_root (arg1=<value optimized out>, 
    arg2=<value optimized out>) at /usr/src/sys/kern/kern_sysctl.c:1531
#12 0xc0b493fa in userland_sysctl (td=0x4, old=<value optimized out>, 
    oldlenp=<value optimized out>, inkernel=<value optimized out>, 
---Type <return> to continue, or q <return> to quit---
    new=<value optimized out>, newlen=<value optimized out>, 
    retval=<value optimized out>, flags=<value optimized out>)
    at /usr/src/sys/kern/kern_sysctl.c:1641
#13 0xc0b491d8 in sys___sysctl (uap=0xc378dca8)
    at /usr/src/sys/kern/kern_sysctl.c:1567
#14 0xc1065cb9 in syscall (frame=<value optimized out>) at subr_syscall.c:141
#15 0xc104fa1f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:279
#16 0x00000033 in ?? ()
(kgdb) quit
 
This is just a bit of a guess, and without digging into the kernel source for specifics. It looks like it is choking when trying to enumerate the CPU's speed control / power saving features. You might want to take a look at any available BIOS settings related to that, and try carefully turning things on/off to see if it makes any difference. You could also check if there is a BIOS update available, as potentially something buggy/bad in the BIOS around CPU power saving could be responsible.
 
Thanks Murph.

I disabled "Intel SpeedStep(tm)" setting and it now boots into multi-user mode.
I thought I went over the BIOS settings but I guess I was wrong.

sysctl now returns a full listing and dev.smist is in that listing.

So question:
Where is the fault?
Is it the BIOS or FreeBSD code?

P.s. It's an old Dell C600 and I have the last BIOS update (A23).
 
Oh BTW, I consider this issue closed but I would like to continue to investigate this as I am interested in hardware and device driver development. Thanks for everyones help.
 
Dennis Chang said:
Where is the fault?
Is it the BIOS or FreeBSD code?
Click to expand...

Arguably, there's probably 2 faults here. First the BIOS (probably), for providing a bad response, possibly a bad ACPI implementation/code/data. Second, FreeBSD's kernel for not handling the bad response cleanly (i.e. it should ideally detect the bad response and just log an error, instead of a panic). I could be wrong about the BIOS giving a bad response, it just seems quite likely.

Depending on exactly what was failing, you may possibly be able to patch the BIOS problem via acpidump(8), iasl(8), and something like the following in /boot/loader.conf:
Code: 
##############################################################
###  ACPI settings  ##########################################
##############################################################

acpi_dsdt_load="YES"            # DSDT Overriding
acpi_dsdt_type="acpi_dsdt"      # Don't change this
acpi_dsdt_name="/boot/acpi_dsdt.aml"
                                # Override DSDT in BIOS by this file
If the problem is somewhere other than the ACPI DSDT, that probably won't help. Fairly advanced stuff, so approach with appropriate caution. That's assuming that the system does actually have ACPI — it looks like it was produced right around the time that ACPI was introduced.
 
You must log in or register to reply here.
Back
Top