Aren
/
NetBSD
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

always call lockdebug_dismiss() from DDB -- there are always some 

minimal lockdebug checks in place, even without LOCKDEBUG.

adjust lockdebug_abort() to ignore problems after ld_panic is set
so that there's a chance of this working.

this fixes ddb 'reboot' on softiron od1000.
This commit is contained in:
mrg 2018-09-13 01:55:16 +00:00
parent 26f83385d3
commit 60b1eff445
2 changed files with 18 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
sys/ddb/db_command.c
View File

@ -1,4 +1,4 @@
/* $NetBSD: db_command.c,v 1.156 2018/08/13 03:20:19 mrg Exp $ */
/* $NetBSD: db_command.c,v 1.157 2018/09/13 01:55:16 mrg Exp $ */
/*
* Copyright (c) 1996, 1997, 1998, 1999, 2002, 2009 The NetBSD Foundation, Inc.
@ -60,7 +60,7 @@
*/
#include <sys/cdefs.h>
__KERNEL_RCSID(0, "$NetBSD: db_command.c,v 1.156 2018/08/13 03:20:19 mrg Exp $");
__KERNEL_RCSID(0, "$NetBSD: db_command.c,v 1.157 2018/09/13 01:55:16 mrg Exp $");
#ifdef _KERNEL_OPT
#include "opt_aio.h"
@ -1353,9 +1353,7 @@ db_reboot_cmd(db_expr_t addr, bool have_addr,
*/
db_recover = 0;
/* Avoid all mutex errors */
#ifdef LOCKDEBUG
lockdebug_dismiss();
#endif
panicstr = "reboot forced via kernel debugger";
cpu_reboot((int)bootflags, NULL);
#else /* _KERNEL */

31
sys/kern/subr_lockdebug.c
View File

@ -1,4 +1,4 @@
/* $NetBSD: subr_lockdebug.c,v 1.66 2018/09/03 16:29:35 riastradh Exp $ */
/* $NetBSD: subr_lockdebug.c,v 1.67 2018/09/13 01:55:16 mrg Exp $ */
/*-
* Copyright (c) 2006, 2007, 2008 The NetBSD Foundation, Inc.
@ -34,7 +34,7 @@
*/
#include <sys/cdefs.h>
__KERNEL_RCSID(0, "$NetBSD: subr_lockdebug.c,v 1.66 2018/09/03 16:29:35 riastradh Exp $");
__KERNEL_RCSID(0, "$NetBSD: subr_lockdebug.c,v 1.67 2018/09/13 01:55:16 mrg Exp $");
#ifdef _KERNEL_OPT
#include "opt_ddb.h"
@ -1016,20 +1016,21 @@ lockdebug_abort(const char *func, size_t line, const volatile void *lock,
#endif /* LOCKDEBUG */
/*
* Complain first on the occurrance only. Otherwise proceeed to
* panic where we will `rendezvous' with other CPUs if the machine
* is going down in flames.
* Don't make the situation worse if the system is already going
* down in flames. Once a panic is triggered, lockdebug state
* becomes stale and cannot be trusted.
*/
if (atomic_inc_uint_nv(&ld_panic) == 1) {
printf_nolog("%s error: %s,%zu: %s\n\n"
"lock address : %#018lx\n"
"current cpu : %18d\n"
"current lwp : %#018lx\n",
ops->lo_name, func, line, msg, (long)lock,
(int)cpu_index(curcpu()), (long)curlwp);
(*ops->lo_dump)(lock);
printf_nolog("\n");
}
if (atomic_inc_uint_nv(&ld_panic) > 1)
return;
printf_nolog("%s error: %s,%zu: %s\n\n"
"lock address : %#018lx\n"
"current cpu : %18d\n"
"current lwp : %#018lx\n",
ops->lo_name, func, line, msg, (long)lock,
(int)cpu_index(curcpu()), (long)curlwp);
(*ops->lo_dump)(lock);
printf_nolog("\n");
panic("lock error: %s: %s,%zu: %s: lock %p cpu %d lwp %p",
ops->lo_name, func, line, msg, lock, cpu_index(curcpu()), curlwp);