Date: Thu, 5 Sep 1996 09:34:05 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: rv@groa.uct.ac.za (Russell Vincent) Cc: smp@freebsd.org Subject: Re: SMP on Intel XXpress Message-ID: <199609051634.JAA09371@phaeton.artisoft.com> In-Reply-To: <m0uyaeS-0004vdC@groa.uct.ac.za> from "Russell Vincent" at Sep 5, 96 11:23:06 am
next in thread | previous in thread | raw e-mail | index | archive | help
> After adding that code, the console prints out the 'point' > lines, with what appear to be acceptable values. What was even > more interesting, was that the machine then became responsive, > albeit a little sluggish. [ ... ] > Increasing 'PP_PASSES' for pp1() and pp2() makes the 'point' lines > print out a lot slower, this in turn made the machine even more > sluggish. > > This, to me, sounds as if the machine is no longer handling interrupts > when the second processor is enabled with sysctl. What increases my > suspicion is that I can adjust the ping reponse times to the machine > by adjusting 'PP_PASSES' and hence the frequency that the printf > statements are called. i.e: It looks like the call to 'printf' is > enabling the interrupts temporaily. The amount that is actually > printed in the printf also makes a difference. By default, the ASUS and other boards do not initialize to a default of "virtual wire mode". >From your extended boot messages, it's clear that your machine is starting in virtual wire mode. This is probably the source of your interrupt problem, since it would (I think) require a rewrite of the interrupt handler to make it operate correctly in this mode. There are also a number of cache coherency issues for DMA devices once virtual wire mode is in effect; specifically, I think a bus master result might fail on some systems where the DMA completion interrupt is delivered to a processor that did not initiate the I/O. This is further bourne out by the fact that only one processor is allowed to be "in the kernel" (not in the scheduler and not in user space -- ie: for interrupt handling) at one time. This implies that a virtual wire interupt delivery to one processor may be triggered while the other processor is in in progress on handling a prior interrupt. Right now, I believe this could cause a freeze by exercising race conditions at equivalent or lower SPL on the second processor. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609051634.JAA09371>