From owner-freebsd-ports Tue Mar 27 14:10: 9 2001 Delivered-To: freebsd-ports@hub.freebsd.org Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 930AB37B71B for ; Tue, 27 Mar 2001 14:10:06 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.1/8.11.1) id f2RMA6G48020; Tue, 27 Mar 2001 14:10:06 -0800 (PST) (envelope-from gnats) Date: Tue, 27 Mar 2001 14:10:06 -0800 (PST) Message-Id: <200103272210.f2RMA6G48020@freefall.freebsd.org> To: freebsd-ports@FreeBSD.org Cc: From: natedac@kscable.com Subject: Re: ports/25958: Xfree86's savage and vesa drivers%2 Reply-To: natedac@kscable.com Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR ports/25958; it has been noted by GNATS. From: natedac@kscable.com To: freebsd-gnats-submit@FreeBSD.org, natedac@kscable.com Cc: Subject: Re: ports/25958: Xfree86's savage and vesa drivers%2 Date: Tue, 27 Mar 2001 16:02:52 -0600 (CST) Problem has been solved by a workaround in the kernel source. Thanks to the help of some of the guys on #BSDcode on EFnet (hi BigSpoon!). Apparently MTRR doesn't work on this paricular processor, an AMD 550 MHz Athlon, or the kernel is somehow detecting it wrong. XFree86 4.4.x obviously is trying to use this feature somehow, and that was causing a kernel panic. Temporary Workaround: At line 572 of /sys/i386/i386/i686_mem.c, comment out the commands that attempt to detect the MTRR facility, like this: ---- snip ---- static void i686_mem_drvinit(void *unused) { /* Try for i686 MTRRs */ /* if ((cpu_feature & CPUID_MTRR) && ((cpu_id & 0xf00) == 0x600) && ((strcmp(cpu_vendor, "GenuineIntel") == 0) || (strcmp(cpu_vendor, "AuthenticAMD") == 0))) { mem_range_softc.mr_op = &i686_mrops; } */ } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message