Fwd: Activating Suspend/Resume on FreeBSD 10.1

[Kevin Oberman]

On Thu, Jan 29, 2015 at 12:16 PM, Anthony Jenkins <Anthony.B.Jenkins at att.net
> wrote:

> Ahhh... good ol' VESA driver:
>
>     Jan 29 23:06:57 MyBSD kernel: Fatal trap 12: page fault while in
>     kernel mode
>     Jan 29 23:06:57 MyBSD kernel: cpuid = 0; apic id = 00
>     Jan 29 23:06:57 MyBSD kernel: fault virtual address    = 0x378
>     Jan 29 23:06:57 MyBSD kernel: fault code        = supervisor read
>     data, page not present
>     Jan 29 23:06:57 MyBSD kernel: instruction pointer    =
>     0x20:0xffffffff809149e1
>     Jan 29 23:06:57 MyBSD kernel: stack pointer            =
>     0x28:0xfffffe011b3b9480
>     Jan 29 23:06:57 MyBSD kernel: frame pointer            =
>     0x28:0xfffffe011b3b9500
>     Jan 29 23:06:57 MyBSD kernel: code segment        = base 0x0, limit
>     0xfffff, type 0x1b
>     Jan 29 23:06:57 MyBSD kernel: = DPL 0, pres 1, long 1, def32 0, gran 1
>     Jan 29 23:06:57 MyBSD kernel: processor eflags    = interrupt
>     enabled, resume, IOPL = 0
>     Jan 29 23:06:57 MyBSD kernel: current process        = 996 (acpiconf)
>     Jan 29 23:06:57 MyBSD kernel: trap number        = 12
>     Jan 29 23:06:57 MyBSD kernel: panic: page fault
>     Jan 29 23:06:57 MyBSD kernel: cpuid = 0
>     Jan 29 23:06:57 MyBSD kernel: KDB: stack backtrace:
>     Jan 29 23:06:57 MyBSD kernel: #0 0xffffffff80963000 at
>     kdb_backtrace+0x60
>     Jan 29 23:06:57 MyBSD kernel: #1 0xffffffff80928125 at panic+0x155
>     Jan 29 23:06:57 MyBSD kernel: #2 0xffffffff80d24f1f at trap_fatal+0x38f
>     Jan 29 23:06:57 MyBSD kernel: #3 0xffffffff80d25238 at
> trap_pfault+0x308
>     Jan 29 23:06:57 MyBSD kernel: #4 0xffffffff80d2489a at trap+0x47a
>     Jan 29 23:06:57 MyBSD kernel: #5 0xffffffff80d0a782 at calltrap+0x8
>     Jan 29 23:06:57 MyBSD kernel: #6 0xffffffff80d96ed5 at
>     vesa_bios_save_restore+0x95
>     Jan 29 23:06:57 MyBSD kernel: #7 0xffffffff80e02296 at vga_suspend+0xa6
>     Jan 29 23:06:57 MyBSD kernel: #8 0xffffffff80e0258d at
>     isavga_suspend+0x1d
>     Jan 29 23:06:57 MyBSD kernel: #9 0xffffffff8095b204 at
>     bus_generic_suspend+0x64
>     Jan 29 23:06:57 MyBSD kernel: #10 0xffffffff8095b204 at
>     bus_generic_suspend+0x64
>     Jan 29 23:06:57 MyBSD kernel: #11 0xffffffff8095b204 at
>     bus_generic_suspend+0x64
>     Jan 29 23:06:57 MyBSD kernel: #12 0xffffffff8067e97d at
> pci_suspend+0x5d
>     Jan 29 23:06:57 MyBSD kernel: #13 0xffffffff8095b204 at
>     bus_generic_suspend+0x64
>     Jan 29 23:06:57 MyBSD kernel: #14 0xffffffff8095b204 at
>     bus_generic_suspend+0x64
>     Jan 29 23:06:57 MyBSD kernel: #15 0xffffffff8035bc7f at
> acpi_suspend+0xf
>     Jan 29 23:06:57 MyBSD kernel: #16 0xffffffff8095b204 at
>     bus_generic_suspend+0x64
>     Jan 29 23:06:57 MyBSD kernel: #17 0xffffffff8095b204 at
>     bus_generic_suspend+0x64
>     Jan 29 23:06:57 MyBSD kernel: Uptime: 1m7s
>
>
> A frequent recommendation I see is to remove VESA support from your
> kernel, apparently it has suspend/resume issues.  I don't think
> FreeBSD-10.1 uses the KMS graphics drivers by default, and I /thought/
> the recommendation was for KMS systems.  Shouldn't hurt to build a
> kernel without 'options VESA' and see what happens...
>
> Anthony


My experience is the opposite.  With KMS I could run with VESA and without
it I needed to pull VESA from my kernel.

As of today I am running fine with KMS, i915, and vt(4) with a standard
GENERIC 10-STABLE kernel. I was running KMS and vt(4) well before they were
MFCed, so I don't remember when I stopped adding "nooptions VESA", but I
definitely used to need it to make suspect/resume work and don't any longer.

In any case, trying  kernel without VESA is a good idea.
--
Kevin Oberman, Network Engineer, Retired
E-mail: rkoberman at gmail.com