Re: panic after resume, triggered by vt_switch_timer() ?

2014-03-10 Thread John Baldwin
On Sunday, March 09, 2014 9:39:36 pm Glen Barber wrote:
 I think I have hit a panic in the code path for vt_switch_timer() when
 resuming from suspend.
 
 In both cases it happened, the laptop was suspended for 2 hours.
 
 In both cases, c_func is vt_switch_timer(), and c_arg is a negative
 value (both times it is -2133611368).  I am not sure if these are valid
 values for vt_switch_timer(), but it caught my eye.
 
 The amount of time the laptop has been suspended may be unrelated, but
 so far has been the only constant in numerous attempts to reproduce the
 crash.
 
 The machine is running 11.0-CURRENT #202 r262562, and the only recent
 change to the kernel configuration is switching from sc(4) to vt(4)
 a few weeks ago.  Prior to this, I could leave the machine suspended for
 several hours (sometimes up to 4 when traveling), without issue.
 
 
 Script started on Sun Mar  9 20:22:44 2014
 command: /bin/sh
 # kgdb ./kernel.debug /var/crash/vmcore.last
 GNU gdb 6.1.1 [FreeBSD]
 Copyright 2004 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you are
 welcome to change it and/or distribute copies of it under certain conditions.
 Type show copying to see the conditions.
 There is absolutely no warranty for GDB.  Type show warranty for details.
 This GDB was configured as amd64-marcel-freebsd...
 
 Unread portion of the kernel message buffer:
 
 
 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:0x8064378f
 stack pointer   = 0x28:0xfe01e47b98f0
 frame pointer   = 0x28:0xfe01e47b99b0
 code segment= base 0x0, limit 0xf, type 0x1b
 = DPL 0, pres 1, long 1, def32 0, gran 1
 processor eflags= interrupt enabled, resume, IOPL = 0
 current process = 12 (swi4: clock (0))
 trap number = 12
 panic: page fault
 cpuid = 0
 KDB: stack backtrace:
 #0 0x8066c280 at kdb_backtrace+0x60
 #1 0x8062bc65 at panic+0x155
 #2 0x8095a78f at trap_fatal+0x38f
 #3 0x8095aac1 at trap_pfault+0x321
 #4 0x8095a160 at trap+0x4a0
 #5 0x8093f682 at calltrap+0x8
 #6 0x80643b94 at softclock+0x94
 #7 0x805f6aa8 at intr_event_execute_handlers+0x1b8
 #8 0x805f6ea6 at ithread_loop+0x96
 #9 0x805f3c9a at fork_exit+0x9a
 #10 0x8093fbbe at fork_trampoline+0xe
 Uptime: 6h12m9s
 Dumping 3121 out of 7951 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
 
 Reading symbols from /boot/kernel/zfs.ko.symbols...done.
 Loaded symbols for /boot/kernel/zfs.ko.symbols
 Reading symbols from /boot/kernel/opensolaris.ko.symbols...done.
 Loaded symbols for /boot/kernel/opensolaris.ko.symbols
 Reading symbols from /boot/kernel/i915kms.ko.symbols...done.
 Loaded symbols for /boot/kernel/i915kms.ko.symbols
 Reading symbols from /boot/kernel/drm2.ko.symbols...done.
 Loaded symbols for /boot/kernel/drm2.ko.symbols
 #0  doadump (textdump=value optimized out) at pcpu.h:219
 219 __asm(movq %%gs:%1,%0 : =r (td)
 (kgdb) bt
 #0  doadump (textdump=value optimized out) at pcpu.h:219
 #1  0x8062b808 in kern_reboot (howto=260) at 
 /usr/src/sys/kern/kern_shutdown.c:452
 #2  0x8062bca4 in panic (fmt=value optimized out)
 at /usr/src/sys/kern/kern_shutdown.c:759
 #3  0x8095a78f in trap_fatal (frame=value optimized out, eva=value 
 optimized out)
 at /usr/src/sys/amd64/amd64/trap.c:874
 #4  0x8095aac1 in trap_pfault (frame=0xfe01e47b9840, 
 usermode=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:691
 #5  0x8095a160 in trap (frame=0xfe01e47b9840)
 at /usr/src/sys/amd64/amd64/trap.c:455
 #6  0x8093f682 in calltrap () at 
 /usr/src/sys/amd64/amd64/exception.S:231
 #7  0x8064378f in softclock_call_cc (c=0x80d3ae78, 
 cc=0x80eace80, 
 direct=0) at /usr/src/sys/kern/kern_timeout.c:703
 #8  0x80643b94 in softclock (arg=0x80eace80)
 at /usr/src/sys/kern/kern_timeout.c:812
 #9  0x805f6aa8 in intr_event_execute_handlers (p=value optimized 
 out, 
 ie=0xf800031f3a00) at /usr/src/sys/kern/kern_intr.c:1263
 #10 0x805f6ea6 in ithread_loop (arg=0xf8000323cf80)
 at /usr/src/sys/kern/kern_intr.c:1276
 #11 0x805f3c9a in fork_exit (callout=0x805f6e10 
 ithread_loop, 
 arg=0xf8000323cf80, frame=0xfe01e47b9ac0) at 
 /usr/src/sys/kern/kern_fork.c:977
 #12 0x8093fbbe in fork_trampoline () at 
 /usr/src/sys/amd64/amd64/exception.S:605
 #13 0x in ?? ()
 Current language:  auto; currently minimal
 (kgdb) frame 7
 #7  0x8064378f in softclock_call_cc (c=0x80d3ae78, 
 cc=0x80eace80, 
 direct=0) at /usr/src/sys/kern/kern_timeout.c:703
 703 

Re: panic after resume, triggered by vt_switch_timer() ?

2014-03-10 Thread Glen Barber
On Mon, Mar 10, 2014 at 02:35:50PM -0400, John Baldwin wrote:
 On Sunday, March 09, 2014 9:39:36 pm Glen Barber wrote:
  I think I have hit a panic in the code path for vt_switch_timer() when
  resuming from suspend.
  
  [...]
 
 This has been reported multiple times by both adrian@ and myself.  I would try
 disabling vt switching during suspend as a workaround for now.  I found that
 only ttyv0's timer object is zero'd when this happens.  The timers for the
 other VTY's are all fine.
 

Hmm, I do not remember seeing it reported.  Sorry for the additional
noise.

I'll disable vt switching as you suggest.

Thanks.

Glen



pgpAhJY8C1miq.pgp
Description: PGP signature