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,
>> >>
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 give interrupts a cha
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 interr
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 work
On 16-Jul-2002 Andrew Gallatin wrote:
>
> 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?
Well, we will end up trading a panicstr test in runq_choose for ones
in msleep and cv's. It probab
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))
>
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
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 w
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 prob
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 y
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
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) sta
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 x86 by increasing HZ. But
> > I can
* Andrew Gallatin <[EMAIL PROTECTED]> [020716 10:46] 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, ju
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 [EMAI
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 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
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
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 ano
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 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
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
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?
BTW, I've looked at the code in vn_statfile():
vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, td);
erro
Dag-Erling Smorgrav writes:
> 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:
>
> VOP_GETATTR: 0xfe00019e7220 is not locked but should be
> Lock violation.
>
> Stopped at Deb
24 matches
Mail list logo
