sysctl dev.cpu.0 endet in panic: page fault

emmh

Member
Nach dem Update von 10.0-RELEASE auf 10.1-RELEASE endet ein "$ sysctl dev.cpu.0" in einem panic: page fault. Besonders blöd, da es beim Start durch /etc/rc.d/power_profile aufgerufen wird.

power_profile habe ich auskommentiert und so startet die Kiste wenigstens - aber sysctl in Verbindung mit Abfragen der cpu lasse ich vorerst.

Auffällig ist auch, das nach jedem Panic der nächste Reboot bei 'pccard0' hängen beibt. Ich weiß nicht, ob sich das auf den Kerneldump auswirkt.

LG
emmh

Info:
Hardware: (BIOS Defaults):
IBM ThinkPad T20 (Ja, ist alt - aber 10.0 klappte...)

$ uname -a
FreeBSD arthur 10.1-RELEASE FreeBSD 10.1-RELEASE #0 r274401: Tue Nov 11 22:51:51 UTC 2014 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC i386

$ /var/log/messages
-> log_messages.txt

$ pciconf -l
-> pciconf.txt

$ dmesg
-> dmesg.txt

$ /var/crash/*
(zu groß...)

LG,
emmh
 

Anhänge

  • log_messages.txt
    42,5 KB · Aufrufe: 227
  • pciconf.txt
    996 Bytes · Aufrufe: 209
  • dmesg.txt
    4,8 KB · Aufrufe: 225
Führe mal kgdb aus und gib das Kommando bt ein.

Den resultierenden Backtrace solltest Du hier posten können.
 
(kgdb) bt
#0 sched_switch (td=0xc1545ef0, newtd=<value optimized out>)
at /usr/src/sys/kern/sched_ule.c:1945
#1 0xc0b20f12 in mi_switch (flags=<value optimized out>, newtd=0xc1545ef0)
at /usr/src/sys/kern/kern_synch.c:494
#2 0xc0b5f65b in sleepq_switch (wchan=<value optimized out>,
pri=<value optimized out>) at /usr/src/sys/kern/subr_sleepqueue.c:538
#3 0xc0b5fd8f in sleepq_timedwait (wchan=0xc1545bf4, pri=84)
at /usr/src/sys/kern/subr_sleepqueue.c:652
#4 0xc0b20822 in _sleep (ident=0xc140ab01, lock=<value optimized out>,
priority=<value optimized out>, sbt=42949670000, pr=0,
flags=<value optimized out>) at /usr/src/sys/kern/kern_synch.c:252
#5 0xc0dbe6a0 in swapper () at /usr/src/sys/vm/vm_glue.c:750
#6 0xc04b2e77 in begin () at /usr/src/sys/i386/i386/locore.s:327
Current language: auto; currently minimal
(kgdb)
 
Hier nun auch die /var/crash/core.txt(.0)
(Nicht die Größe, sondern die Berechtigung auf dem nfs-Server war Schuld - mein Fehler.)
 

Anhänge

  • core.txt
    130,8 KB · Aufrufe: 321
Anmerkung zu core.txt(.0)
Die Einträge 'HIGH' und 'NONE' (Zeilen 1344 und 1345) resultieren aus der geänderten /etc/rc.d/power_profile
 
Hey, ich hatte gerade eben einen in der gleichen Funktion beim Aufwachen aus dem Suspend unter stable/10.
 
Na super - andere Institutionen brauchen Jahre um Viren und Trojaner zu entwickeln, ich schaffe es mit nur einem Post! Aber danke für die Info, dann brauche ich stable/10 nicht zu testen.
 
Zurück
Oben