From owner-freebsd-hackers  Fri Sep 25 11:09:01 1998
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id LAA11938
          for freebsd-hackers-outgoing; Fri, 25 Sep 1998 11:09:01 -0700 (PDT)
          (envelope-from owner-freebsd-hackers@FreeBSD.ORG)
Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA11933
          for <hackers@freebsd.org>; Fri, 25 Sep 1998 11:08:56 -0700 (PDT)
          (envelope-from thorpej@lestat.nas.nasa.gov)
Received: from localhost (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with SMTP id KAA23227; Fri, 25 Sep 1998 10:50:25 -0700 (PDT)
Message-Id: <199809251750.KAA23227@lestat.nas.nasa.gov>
X-Authentication-Warning: lestat.nas.nasa.gov: localhost [127.0.0.1] didn't use HELO protocol
To: Bill Paul <wpaul@skynet.ctr.columbia.edu>
Cc: hackers@FreeBSD.ORG
Subject: Re: RealTek + memory mapped registers + SMP == ?*%^(#!! 
Reply-To: Jason Thorpe <thorpej@nas.nasa.gov>
From: Jason Thorpe <thorpej@nas.nasa.gov>
Date: Fri, 25 Sep 1998 10:50:24 -0700
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Fri, 25 Sep 1998 12:56:42 -0400 (EDT) 
 Bill Paul <wpaul@skynet.ctr.columbia.edu> wrote:

 > Can anyone think of a reason why this would happen? The machine also
 > has two Intel EtherExpress Pro 100B adapters, and the fxp driver, which
 > also uses memory mapped access, works fine. I suspect that there's
 > just something bogus about the RealTek chip that's causing it, but I
 > don't know what.

What can I say?  PC hardware sucks!  :-)

Seriously, though, some chips just don't do memory-mapped access properly,
or sometimes have problems when used with some PCI-Host bridges or some
PCI-PCI bridges.  (E.g. on my main NetBSD development system, I have a PCI
expansion backplane which uses DC21050s; memory-mapped access behind that
bridge simply Loses on my system, a PPro w/ a 82441 PCI-Host bridge.  It
works fine on an Alpha and on a PPro system w/ an 82454 PCI-Host bridge.)

What we (NetBSD) do in the case of the device losing (i.e. TI ThunderLAN
in TI laptop docking stations) is just quirk the device and say - "Ok,
you get to use i/o-mapped access.  Sorry!"  In the case of a bridge
losing, we quirk the chipset and disable either memory- or i/o-mapped
access via flags in the PCI device attach args.

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                            Home: +1 408 866 1912
NAS: M/S 258-5                                       Work: +1 650 604 0935
Moffett Field, CA 94035                             Pager: +1 650 940 5942

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message