--==_Exmh_-1754755835P
Content-Type: text/plain; charset=us-ascii

In message <20030625115651.GA5356@rezrov.net>, Chris Sekiya writes: 

-> On Tue, Jun 24, 2003 at 04:54:34PM -0400, Rafal Boni wrote:
-> 
-> > 	* Most PCI NICs and probably some chunk of other PCI cards
-> > 	  for which there are MI drivers in NetBSD
-> 
-> I've personally tested:
-> 
-> 	* fxp (Intel EtherExpress Pro).  No issues.
-> 	* ex (3com 3c509b).  Somewhat frequent PCI overruns, but I think the
-> 	  card may be bad.
-> 	* rtk (no-name Realtek 8139 card).  Lousy performance, but that's
-> 	  par for this particular chip.
-> 	* url (USB next-generation Realtek NIC).  USB 1.1, but throughput
-> 	  is pretty decent.

ITYM s/509/905/... My 905C-TXM worked with no problems last I tried it,
other than occasional pcierr panics when rebooting after a particularly
nasty crash.  When I've not been trying to figure out the issues with my
Intel GigE card in the O2, this is the card I've used the most (my fxp
is in an old beater PC box which I've been too lazy to disassemble, and
the rtk got borrowed for some other short-term duty :-); I've beat on
the network fairly heavily using it and not had any problems.

As for the `rtk', the performance wasn't actually that bad, at least 
in my setup (all switched network either via a GigE switch or 100TX
switch).  I was kinda surprised after all the issues we had with these
things in machines at work at the one in the O2 worked fairly well
and even performed fairly well (I haven't benchmarked, but it was
good enough that I didn't notice differences pushing around lots
of data with it vs. the 3c905c).  

-> > The L2 cache stuff on R5k requires me to clean up some changes I have
-> > had sitting around for the MIPS pmap and check them in (conceptually,
-> > all the hard work is done, but I've had other stuff going on), but I
-> > have not had a lot of free time recently...
-> 
-> Rafal's cache hacks work very well for me (r5ksc).  In fact, they actually
-> address the cache deficiencies in the ip22 port as well -- with them, one
-> no longer needs to define L2_CACHE_ABSENT in the kernel configuration.  
-> I'd very much like to see them committed once Rafal is happy with them.

Yeah, in fact, the L2_CACHE_ABSENT option should die a fiery death.  I 
have changes somewhere to make that so as well (IIRC, it's not used out-
side of the limited use in the sgimips L2-setup code or in places where
it simply ifdefs out code that's otherwise protected by runtime tests).

--rafal

----
Rafal Boni                                              rafal.boni@eDial.com
 PGP key C7D3024C, print EA49 160D F5E4 C46A 9E91  524E 11E0 7133 C7D3 024C


--==_Exmh_-1754755835P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Exmh version 2.4 06/23/2000

iD8DBQE++dlDEeBxM8fTAkwRAnKOAJ9E7l/sTyfPVMygYjU6qtuohWEBogCfQ38o
TS2DPvWjq9GxGn9jUZsa29g=
=t+6i
-----END PGP SIGNATURE-----

--==_Exmh_-1754755835P--