Date: Thu, 05 Sep 1996 14:09:03 -0600 From: Steve Passe <smp@csn.net> To: Terry Lambert <terry@lambert.org> Cc: rv@groa.uct.ac.za (Russell Vincent), smp@freebsd.org Subject: Re: SMP on Intel XXpress Message-ID: <199609052009.OAA27675@clem.systemsix.com> In-Reply-To: Your message of "Thu, 05 Sep 1996 09:34:05 PDT." <199609051634.JAA09371@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, Terry Lambert said: > ... > 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. my gigabyte GA586DX (2x133 P5, MP sepc 1.1) also starts in virtual wirw mode and has no problems. > 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. MP spec 1.4, 3.6.2.2 says: Virtual Wire Mode provides a uniprocessor hardware environment capable of booting and running all DOS shrink-wrapped software. In virtual wire mode ... the 8259A PIC fields all interrupts ... figure 3-3 clearly shows a setup where the 1st CPU is the only one fielding INT requests. it is the symmetric I/O mode (3.6.2.3) which allows INTs to go to all processors. b4 the "sysctl kern.smp_active=2" the 2nd CPU is running a busy loop in mp_begin, polling smp_active. at this point in time it has the EI bit OFF, ie 'cli', but all the other setup has been done, ie it is in protected mode, paging, etc. after the "sysctl kern.smp_active=2" the 2nd CPU calls secondary_main() which merely prints an info message, then calls cpu_switch(), from which it never returns (thats a good thing, it shouldn't). but from this point on we have the INT loss problem. I'm totally confused... -- Steve Passe | powered by smp@csn.net | FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609052009.OAA27675>