Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 22 Jul 2016 14:42:51 -0700
From:      John Baldwin <jhb@freebsd.org>
To:        Roger Pau =?ISO-8859-1?Q?Monn=E9?= <royger@freebsd.org>
Cc:        src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   Re: svn commit: r303076 - head/sys/dev/fb
Message-ID:  <3203650.y8tuqEfyUM@ralph.baldwin.cx>
In-Reply-To: <201607200929.u6K9Td8S040645@repo.freebsd.org>
References:  <201607200929.u6K9Td8S040645@repo.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, July 20, 2016 09:29:39 AM Roger Pau Monn=E9 wrote:
> Author: royger
> Date: Wed Jul 20 09:29:39 2016
> New Revision: 303076
> URL: https://svnweb.freebsd.org/changeset/base/303076
>=20
> Log:
>   vesa: fix panic on suspend
>  =20
>   Fix the following panic seen when migrating a FreeBSD guest on Xen:=

>  =20
>   panic: mtx_lock() of destroyed mutex @ /usr/src/sys/dev/fb/vesa.c:5=
41
>   cpuid =3D 0
>   KDB: stack backtrace:
>   db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffff=
e001d2fa4f0
>   vpanic() at vpanic+0x182/frame 0xfffffe001d2fa570
>   kassert_panic() at kassert_panic+0x126/frame 0xfffffe001d2fa5e0
>   __mtx_lock_flags() at __mtx_lock_flags+0x15b/frame 0xfffffe001d2fa6=
30
>   vesa_bios_save_restore() at vesa_bios_save_restore+0x78/frame 0xfff=
ffe001d2fa680
>   vga_suspend() at vga_suspend+0xa3/frame 0xfffffe001d2fa6b0
>   isavga_suspend() at isavga_suspend+0x1d/frame 0xfffffe001d2fa6d0
>   bus_generic_suspend_child() at bus_generic_suspend_child+0x44/frame=

>   [...]
>  =20
>   This is caused because vga_sub_configure (which is called if the VG=
A adapter
>   is attached after VESA tried to initialize), points to vesa_configu=
re, which
>   doesn't initialize the VESA mutex. In order to fix it, make sure
>   vga_sub_configure points to vesa_load, so that all the needed vesa
>   components are properly initialized.

This panics a box without VESA (a dumb VGA) since vesa_init_done doesn'=
t get set
to true if VESA fails to find anything during its probe, so the mutex c=
an be
initialized twice.  I think it is better to just revert this change and=
 use
MTX_SYSINIT to initialize the mutex instead.

vga0: <Generic ISA VGA> at port 0x3d0-0x3db iomem 0xb8000-0xbffff on is=
a0
panic: lock "VESA lock" 0xffffffff81c64af0 already initialized
cpuid =3D 0
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffffff8=
24ec7a0
kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffffff824ec850
vpanic() at vpanic+0x181/frame 0xffffffff824ec8d0
kassert_panic() at kassert_panic+0x17d/frame 0xffffffff824ec960
lock_init() at lock_init+0x186/frame 0xffffffff824ec9a0
_mtx_init() at _mtx_init+0x90/frame 0xffffffff824ec9e0
vesa_late_load() at vesa_late_load+0x2d/frame 0xffffffff824eca00
vga_init() at vga_init+0x65/frame 0xffffffff824eca20
vga_attach_unit() at vga_attach_unit+0x4b/frame 0xffffffff824eca50
isavga_attach() at isavga_attach+0x6c/frame 0xffffffff824eca90
DEVICE_ATTACH() at DEVICE_ATTACH+0x44/frame 0xffffffff824ecab0

https://reviews.freebsd.org/D7290 is a suggested patch that works in my=

test case.

--=20
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3203650.y8tuqEfyUM>