Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 15 Mar 2014 12:44:46 -0700
From:      Kevin Oberman <rkoberman@gmail.com>
To:        FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>
Subject:   Clock issues and crash on resume on 10-Stable r263062M
Message-ID:  <CAN6yY1seOSacdXY3RKOgEdY_v%2BzD=vqMAfnsXH96Ft8w%2BOoJew@mail.gmail.com>

next in thread | raw e-mail | index | archive | help
I am seeing clock related issues when resuming from a suspended state on my
laptop running r263062M. I've seen two failures, but both appear to be
dealing with updating the system time after resuming.
FreeBSD rogue.local 10.0-STABLE FreeBSD 10.0-STABLE #0 r263062M: Tue Mar 11
22:14:07 PDT 2014     root@rogue.local:/usr/obj/usr/src/sys/VT  amd64

1. The time does not update after resume. The time on the system simply
starts counting again from the time of the suspend. 'ntpq -p' shows no sync
to any clock and a rather large offset to them once there has been  poll of
that server. It is possible that, if I waited long enough, that NTP would
correct the time, but with polling at 1024 seconds and several polls needed
for the time to try to reset, I simply forced the time to within a second
and went on.

2. The time does not update after resume. After about 2 seconds, ehe system
crashes.
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x30
fault code              = supervisor read data, page not present
instruction pointer     = 0x20:0xffffffff808c9ef3
stack pointer           = 0x28:0xfffffe00f13548e0
frame pointer           = 0x28:0xfffffe00f13549b0
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 12 (swi4: clock)
trap number             = 12
panic: page fault
cpuid = 0
KDB: stack backtrace:
#0 0xffffffff808ed460 at kdb_backtrace+0x60
#1 0xffffffff808b4e35 at panic+0x155
#2 0xffffffff80c97022 at trap_fatal+0x3a2
#3 0xffffffff80c972f9 at trap_pfault+0x2c9
#4 0xffffffff80c96a8b at trap+0x5bb
#5 0xffffffff80c7dd42 at calltrap+0x8
#6 0xffffffff808ca304 at softclock+0x94
#7 0xffffffff8088929b at intr_event_execute_handlers+0xab
#8 0xffffffff808896e6 at ithread_loop+0x96
#9 0xffffffff80886f4a at fork_exit+0x9a
#10 0xffffffff80c7e27e at fork_trampoline+0xe
[...]
#0  doadump (textdump=<value optimized out>) at pcpu.h:219
219     pcpu.h: No such file or directory.
        in pcpu.h
(kgdb) #0  doadump (textdump=<value optimized out>) at pcpu.h:219
#1  0xffffffff808b4ab0 in kern_reboot (howto=260)
    at /usr/src/sys/kern/kern_shutdown.c:452
#2  0xffffffff808b4e74 in panic (fmt=<value optimized out>)
    at /usr/src/sys/kern/kern_shutdown.c:759
#3  0xffffffff80c97022 in trap_fatal (frame=<value optimized out>,
    eva=<value optimized out>) at /usr/src/sys/amd64/amd64/trap.c:875
#4  0xffffffff80c972f9 in trap_pfault (frame=0xfffffe00f1354830, usermode=0)
    at /usr/src/sys/amd64/amd64/trap.c:692
#5  0xffffffff80c96a8b in trap (frame=0xfffffe00f1354830)
    at /usr/src/sys/amd64/amd64/trap.c:456
#6  0xffffffff80c7dd42 in calltrap ()
    at /usr/src/sys/amd64/amd64/exception.S:232
#7  0xffffffff808c9ef3 in softclock_call_cc (c=0xffffffff813834b8,
    cc=0xffffffff81527680, direct=0) at /usr/src/sys/kern/kern_timeout.c:701
#8  0xffffffff808ca304 in softclock (arg=0xffffffff81527680)
    at /usr/src/sys/kern/kern_timeout.c:810
#9  0xffffffff8088929b in intr_event_execute_handlers (
    p=<value optimized out>, ie=0xfffff800027b0900)
    at /usr/src/sys/kern/kern_intr.c:1263
#10 0xffffffff808896e6 in ithread_loop (arg=0xfffff8000292ac60)
    at /usr/src/sys/kern/kern_intr.c:1276
#11 0xffffffff80886f4a in fork_exit (
    callout=0xffffffff80889650 <ithread_loop>, arg=0xfffff8000292ac60,
    frame=0xfffffe00f1354ac0) at /usr/src/sys/kern/kern_fork.c:995
#12 0xffffffff80c7e27e in fork_trampoline ()
    at /usr/src/sys/amd64/amd64/exception.S:606
#13 0x0000000000000000 in ?? ()
Current language:  auto; currently minimal

One of these failures has occurred on over half of the resume operations I
have tried since about March 3rd, though I have had only one crash, earlier
today. N.B. I failed to remove VESA from my kernel on March 3, so was
unable to resume until I added VT and removed VESA on March 11. Resume
worked fine with my kernel at r261581.
-- 
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkoberman@gmail.com



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAN6yY1seOSacdXY3RKOgEdY_v%2BzD=vqMAfnsXH96Ft8w%2BOoJew>