On 17-Jul-2002 Bruce Evans wrote:
On Tue, 16 Jul 2002, John Baldwin wrote:
On 17-Jul-2002 Bruce Evans wrote:
mtx_lock_spin(sched_lock);
if (cold || panicstr) {
/*
* After a panic, or during autoconfiguration,
* just
Dag-Erling Smorgrav writes:
Andrew Gallatin [EMAIL PROTECTED] writes:
Welcome to hell.
Thanks, it sure looks cozy in here :)
If you clear panicstr, you have a chance of getting a dump.
How do I do that?
Just clear panicstr (w panicstr 0) when you drop into
the debugger
Andrew Gallatin [EMAIL PROTECTED] writes:
Just clear panicstr (w panicstr 0) when you drop into
the debugger on a panic.
No luck. However, I added an ASSERT_VOP_LOCKED() to vn_statfile(),
and confirmed that vn_lock() fails to lock the vnode. Unfortunately,
without a dump it's hard to tell
Hi!
On Tue, Jul 16, 2002 at 02:45:11PM +0200, Dag-Erling Smorgrav wrote:
The following panic is 100% reproducable - it happens whenever I boot
a recent kernel on Alpha, just before init(8) starts getty(8) on the
console:
sorry, kernel from today's sources at 17:38 works just fine.
Yet
On 16 Jul, Dag-Erling Smorgrav wrote:
Andrew Gallatin [EMAIL PROTECTED] writes:
Just clear panicstr (w panicstr 0) when you drop into
the debugger on a panic.
No luck. However, I added an ASSERT_VOP_LOCKED() to vn_statfile(),
and confirmed that vn_lock() fails to lock the vnode.
Andrew Kolchoogin [EMAIL PROTECTED] writes:
sorry, kernel from today's sources at 17:38 works just fine.
Try with DEBUG_VFS_LOCKS.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Andrew Kolchoogin writes:
Hi!
On Tue, Jul 16, 2002 at 02:45:11PM +0200, Dag-Erling Smorgrav wrote:
The following panic is 100% reproducable - it happens whenever I boot
a recent kernel on Alpha, just before init(8) starts getty(8) on the
console:
sorry, kernel from today's
Hi!
On Tue, Jul 16, 2002 at 05:59:16PM +0200, Dag-Erling Smorgrav wrote:
sorry, kernel from today's sources at 17:38 works just fine.
Try with DEBUG_VFS_LOCKS.
Well. Say that me is the lamest programmer at the world. :)
My Alpha DOESN'T go to debugger.
Instead it hungs in the internals of
Andrew,
On Tue, Jul 16, 2002 at 01:46:16PM -0400, Andrew Gallatin wrote:
PS: I was trying to make crashdumps fail on x86 by increasing HZ. But
I cannot. I have no idea why this only happens on alpha.
have you any ideas what we should to test?-)
Andrew.
To Unsubscribe: send mail to [EMAIL
On 16-Jul-2002 Andrew Gallatin wrote:
Andrew Kolchoogin writes:
Hi!
On Tue, Jul 16, 2002 at 02:45:11PM +0200, Dag-Erling Smorgrav wrote:
The following panic is 100% reproducable - it happens whenever I boot
a recent kernel on Alpha, just before init(8) starts getty(8) on
On 16-Jul-2002 Andrew Gallatin wrote:
Alfred Perlstein writes:
We need to somehow let only interrupt threads and the panic'ed process
run after a panic. I have no idea how to do this in a clean,
low-impact way.
Drew
PS: I was trying to make crashdumps fail on
John Baldwin writes:
We need to somehow let only interrupt threads and the panic'ed process
run after a panic. I have no idea how to do this in a clean,
low-impact way.
It's probably preemption. However, the problem may be that you can't
switch to the ithread if you just
On 16-Jul-2002 Andrew Gallatin wrote:
John Baldwin writes:
We need to somehow let only interrupt threads and the panic'ed process
run after a panic. I have no idea how to do this in a clean,
low-impact way.
It's probably preemption. However, the problem may be that
John Baldwin writes:
So its still stuck in msleep. How is it supposed to get back to
the panic'ed thread if a system thread wakes up and is not allowed to
go back to sleep???
Hm. Surprised we don't see this on other archs then (or maybe
we do...). Probably when we
On 16-Jul-2002 Andrew Gallatin wrote:
John Baldwin writes:
So its still stuck in msleep. How is it supposed to get back to
the panic'ed thread if a system thread wakes up and is not allowed to
go back to sleep???
Hm. Surprised we don't see this on other archs
John Baldwin writes:
I like my second, it is easier, just add this to choosethread:
Don't all these compares in the critical path add up?
if (panicstr
((td-td_proc-p_flag P_SYSTEM) == 0
(td-td_flags TDF_INPANIC) == 0))
goto top;
On Tue, 16 Jul 2002, Andrew Gallatin wrote:
Andrew Kolchoogin writes:
Why panic from debugger on i386 gives core dump and reboots the system
and panic from debugger on Alpha does not?
Because, as BDE says, that crashdumps work at all is mosty accidental.
Er, I meant that working of
On 17-Jul-2002 Bruce Evans wrote:
This could also be just a driver problem. I know the old wddump routine
worked right but am not sure about any of the current ones. Maybe dumps
are broken on the alpha only due to driver problems. Note that the
splhigh() didn't actually lock out
18 matches
Mail list logo
