Date: Thu, 02 Oct 1997 04:15:29 -0700 From: David Greenman <dg@root.com> To: "Mike Durian" <durian@plutotech.com> Cc: hackers@FreeBSD.ORG Subject: Re: strange interaction with Pentium and fxp Message-ID: <199710021115.EAA19164@implode.root.com> In-Reply-To: Your message of "Wed, 01 Oct 1997 17:06:05 MDT." <199710012306.RAA25757@pluto.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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? I'm not able to reproduce the problem here. I added a bunch of code to FreeBSD to set aside the lower few pages specifically for mbufs, carefully tuned so that the page at 0x3000 was the first page to be used in DMA with the fxp card. The DMAs started at the following addresses at startup: 0x3f56 0x3f56 0x3eb6 0x4056 0x409e 0x419e 0x411e 0x429e 0x3e1e 0x439e (...) This was tested on both a 430VX (P5) chipset MB and a 440FX (P6/Natoma), with both 32MB of RAM and 64MB of RAM, and both -stable and -current. There were no hangs or any other problems. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710021115.EAA19164>