From owner-freebsd-hackers Wed Oct 1 16:06:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA15212 for hackers-outgoing; Wed, 1 Oct 1997 16:06:21 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA15188; Wed, 1 Oct 1997 16:06:07 -0700 (PDT) Received: from shane.plutotech.com (shane.plutotech.com [206.168.67.149]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id RAA25757; Wed, 1 Oct 1997 17:06:06 -0600 (MDT) Message-Id: <199710012306.RAA25757@pluto.plutotech.com> From: "Mike Durian" To: hackers@FreeBSD.ORG cc: dg@root.com, dyson@FreeBSD.ORG Subject: Re: strange interaction with Pentium and fxp In-reply-to: Your message of "Wed, 01 Oct 1997 12:45:27 MDT." Date: Wed, 01 Oct 1997 17:06:05 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 01 Oct 1997 12:45:27 MDT, "Mike Durian" wrote: >The only difference >I can detect is that the old kernel stores the mbuf at >a physical address like 0x2bxx54 and the new one has the >mbuf at 0x3f54 - a much lower memory address. > I should also mention that this problem does not occur >on a Pentium Pro system. I have not stuck my PCI bus >analyzer on the P6 machine, so I'm not positive it uses >the same addresses, but I'm assuming it would. This could >very well be a 430FX chipset bug, but I still need a work >around. I'm got a better grasp on the problem now. I tried running the new kernel on another P6 system and when I experienced the same problem, I knew it wasn't a chipset bug. The only difference between the two P6's was the amount of memory. The one that worked had 64MB and the one that failed on 32MB. When I put 64MB in the one that failed, it started working. Then I put 64MB in the Pentium machine and it too started working. Here's what I know: Machine Mem kernel mbuf Phys Addr. result P6 64MB new NA OK P6 32MB new NA fail P5 32MB new 0x00003f54 fail P5 32MB old 0x002b9f54 OK P5 64MB new 0x0009bf54 OK Apparently, there is a problem with the EtherExpress card DMAing data out of host memory at physical address 0x3f54 using the memory read multiple PCI transaction. Does anyone know why 0x3f54 would be an unacceptable address, and does anyone have a fix? mike