From owner-freebsd-smp Mon Apr 30 15:58:27 2001 Delivered-To: freebsd-smp@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id BDACD37B423; Mon, 30 Apr 2001 15:58:17 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f3UMw1G81213; Mon, 30 Apr 2001 15:58:01 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200104302231.PAA12638@usr01.primenet.com> Date: Mon, 30 Apr 2001 15:57:23 -0700 (PDT) From: John Baldwin To: Terry Lambert Subject: Re: Spontanous reboot of SMP system and FBSD 4.3 Cc: ((Hartmann O.)) Cc: ((Hartmann O.)) , freebsd-stable@FreeBSD.org, freebsd-smp@FreeBSD.org Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 30-Apr-01 Terry Lambert wrote: >> > On some of the Tyan Tiger boards I've fought withm the system >> > becomes extremely unstable because the invltlb() call after >> > switching to 4M pages is not correctly communicated to the I/O >> > APIC, and unless you have enough memory allocations to force all >> > 8 4M entries out, it can lose its mind, relative to the TLB of >> > one or more of the main CPUs. >> >> Ummm, what the heck are you talking about? The I/O APIC routes interrupts, >> it >> doesn't access memory. > > I thought all APICs participated in the MESI coherency protocol, > and all had the TLB caches? APIC != cache. APIC routes interrupts including device interrupts from the 8259 (in virtual wire mode) or from the I/O APIC (symmetric I/O mode used with MP) as well as IPI's. It communicates over a separate ICC bus. It does not use the same bus that the CPU cache's use. > The system I fought with was "SMP capable", but did not have a > second CPU installed. The only things that could get out of > date would be the TLB contents in the cache lines. If I grab > enough resources to cause age-based TLB shootdown, I don't have > the problem. Otherwise I fault in the I/O path, when paging in. > > Supermicro motherboards don't have the problem. > > Setting the "DISABLE_PSE" option makes everything happy again; I > suspect forcing a shootdown via a reload of CR3, or explicitly > invalidating the GDT, would fix my problem. Right now, I just up > my initial resource consumption and ignore it. > > Without this, I get similar symptoms to what he's reporting. I'm not sure why you are having a problem with this. The AP's all sit in a holding pen until the page tables have more or less stabilized at which point they flush their local TLB in ap_init() just before their first context switch. %cr3 is then reloaded on subsequent context switches. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message