On Fri, May 08, 2015 at 20:28 +0200, Mark Kettenis wrote:
Date: Fri, 8 May 2015 20:15:58 +0200
From: Mike Belopuhov m...@belopuhov.com
On Fri, May 08, 2015 at 12:34 +0200, Mike Belopuhov wrote:
I think tsleep(9) and msleep(9) need to release and re-acquire the
kernel lock in the
Date: Mon, 11 May 2015 16:54:54 +0200
From: Mike Belopuhov m...@belopuhov.com
On Fri, May 08, 2015 at 20:28 +0200, Mark Kettenis wrote:
Date: Fri, 8 May 2015 20:15:58 +0200
From: Mike Belopuhov m...@belopuhov.com
On Fri, May 08, 2015 at 12:34 +0200, Mike Belopuhov wrote:
I
Date: Thu, 7 May 2015 20:58:53 +0200
From: Mike Belopuhov m...@belopuhov.com
As I've pointed out before, on panic we can be running on any
CPU and our disk controller's interrupts can interrupt on the
other one. Since we'll most likely be holding a kernel lock,
dealing with unlocking it
On 07/05/15(Thu) 20:58, Mike Belopuhov wrote:
As I've pointed out before, on panic we can be running on any
CPU and our disk controller's interrupts can interrupt on the
other one. Since we'll most likely be holding a kernel lock,
dealing with unlocking it might get hairy very fast. Instead
On 8 May 2015 at 11:43, Mark Kettenis mark.kette...@xs4all.nl wrote:
Date: Thu, 7 May 2015 20:58:53 +0200
From: Mike Belopuhov m...@belopuhov.com
As I've pointed out before, on panic we can be running on any
CPU and our disk controller's interrupts can interrupt on the
other one. Since
On Fri, May 08, 2015 at 12:34 +0200, Mike Belopuhov wrote:
I think tsleep(9) and msleep(9) need to release and re-acquire the
kernel lock in the cold || panicstr case.
Well, it's not hard to do really, but...
We might need this for
handling interrupts during autoconf as soon as we
Date: Fri, 8 May 2015 20:15:58 +0200
From: Mike Belopuhov m...@belopuhov.com
On Fri, May 08, 2015 at 12:34 +0200, Mike Belopuhov wrote:
I think tsleep(9) and msleep(9) need to release and re-acquire the
kernel lock in the cold || panicstr case.
Well, it's not hard to do really,
From: Mike Belopuhov m...@belopuhov.com
Date: Fri, 8 May 2015 13:53:56 +0200
On 8 May 2015 at 12:37, Martin Pieuchot m...@openbsd.org wrote:
On 07/05/15(Thu) 20:58, Mike Belopuhov wrote:
As I've pointed out before, on panic we can be running on any
CPU and our disk controller's
On 8 May 2015 at 04:51, Masao Uebayashi uebay...@tombiinc.com wrote:
By doing complex VFS shutdown operation, the system's memory image will
be modified a lot since a panic was triggered. I'd totally skip
vfs_shutdown() after a panic [1], then do the best to dump a kernel core
for analysis.
As I've pointed out before, on panic we can be running on any
CPU and our disk controller's interrupts can interrupt on the
other one. Since we'll most likely be holding a kernel lock,
dealing with unlocking it might get hairy very fast. Instead
what we could do to improve the chances of a clean
By doing complex VFS shutdown operation, the system's memory image will
be modified a lot since a panic was triggered. I'd totally skip
vfs_shutdown() after a panic [1], then do the best to dump a kernel core
for analysis.
[1] OpenBSD's panic(9) sets RB_NOSYNC only when panicstr is already set
11 matches
Mail list logo
