Date: Tue, 12 Jun 2001 23:33:38 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: wilko@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG, jhb@FreeBSD.ORG Subject: Re: followup on 8 way SMP pani Message-ID: <Pine.BSF.4.21.0106122331460.39150-100000@beppo.feral.com> In-Reply-To: <Pine.BSF.4.21.0106121858250.39150-100000@beppo.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
No, I likely *won't* be able to fix this today, as kernels built with the
latest panic with:
recursed on non-recursive lock (sleep mutex) mbuf free list lock @
../../kern/uipc_mbuf.c:582
first acquired @ ../../kern/uipc_socket.c:875
panic: recurse
cpuid = 0; panic
Stopped at Debugger+0x34: zapnot v0,#0xf,a0 <v0=0x0,a0=0x6>
db> t
Debugger() at Debugger+0x34
panic() at panic+0x178
witness_lock() at witness_lock+0x488
m_freem() at m_freem+0x4e8
soreceive() at soreceive+0x19dc
recvit() at recvit+0x1a4
recvfrom() at recvfrom+0x9c
syscall() at syscall+0x708
XentSys() at XentSys+0x64
--- syscall (29, FreeBSD ELF, recvfrom) ---
--- user mode ---
What I needed to fix for turbolaser is to clear the timer interrupt for all
CPUs but the primary CPU- this is the TLINTRMASK{0,1} registers. But, stupid
me, I upgraded my source first.
-matt
On Tue, 12 Jun 2001, Matthew Jacob wrote:
>
> Oh! I was really snoozing- many other things happening (mostly personal)!
>
> This should be easy to fix- let me look at this tomorrow.
>
> On Tue, 12 Jun 2001, Andrew Gallatin wrote:
>
> >
> > Wilko Bulte writes:
> > > On Mon, Jun 11, 2001 at 10:06:56AM +0000, Wilko Bulte wrote:
> > >
> > > Does this make any sense to anybody? Drew, you asked for a traceback?
> >
> > <...>
> >
> > > > trap entry = 0x2 (memory management fault)
> > > > cpuid = 0
> > > > faulting va = 0x78
> > > > type = access violation
> > > > cause = load instructon
> > > > pc = 0xfffffc0000491ae4
> > > > ra = 0xfffffc0000491ba8
> > > > sp = 0xfffffc00008d9b90
> > > > usp = 0x0
> > > > curproc = 0xfffffc0000831288
> > > > pid = 0, comm = swapper
> > > >
> > > > Stopped at sync_other_counter+0x24: ldq s1,0x78(s0) <0x78>
> > > > <s1=0xfffffc0000785138,s0=0x0>
> > > > db> trace
> > > > sync_other_counter() at sync_other_counter+0x24
> > > > tc_windup() at tc_windup+0x28
> > > > hardclock() at hardclock+0x1e8
> > > > handleclock() at handleclock+0x22c
> > > > alpha_clock_interrupt() at alpha_clock_interrupt+0x68
> > > > interrupt() at interrupt+0xb8
> > > > XentIntlgp() at XentIntlgp+0x14
> > > > db> halt
> > > >
> >
> > Yes, sorry I never replied. According to Matt, the turbolaser doesn't
> > have an i8254 timecounter. And the alpha timecounter is never
> > initialized in alpha/alpha/clock.c if ncpus>1, so you're taking a
> > clock interrupt with no timecounter. Oops. No MP for TurboLasers
> > right now, I guess.
> >
> > Here's the code in question:
> >
> > /*
> > * XXX: TurboLaser doesn't have an i8254 counter.
> > * XXX: A replacement is needed, and another method
> > * XXX: of determining this would be nice.
> > */
> > if (hwrpb->rpb_type != ST_DEC_21000) {
> > tc_init(&i8254_timecounter);
> > }
> >
> > if (ncpus == 1) {
> > alpha_timecounter.tc_frequency = freq;
> > tc_init(&alpha_timecounter);
> > }
> >
> > I think there are bigger fish to fry right now, but this needs to be
> > fixed. I'm not at all sure what to do, since I don't think that
> > the cycle counters on multiple cpus are in sync..
> >
> > Drew
> >
> > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > with "unsubscribe freebsd-alpha" in the body of the message
> >
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-alpha" in the body of the message
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0106122331460.39150-100000>