From mboxrd@z Thu Jan  1 00:00:00 1970
From: jmk@plan9.bell-labs.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] problems with 3c905
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-Id: <20011113234902.AA45019A4A@mail.cse.psu.edu>
Date: Tue, 13 Nov 2001 18:48:56 -0500
Topicbox-Message-UUID: 21e5fdd2-eaca-11e9-9e20-41e7f4b1d025

The plain 905 had some bugs, we may not be dealing with them properly.
Is it on a 10Mbps or 100Mbps network? There is a receive threshold problem
with the 905 at 10Mbps. The code is supposed to deal with it but perhaps
doesn't. Look for the comment
		 * 10MUpldBug.
in etherelnk3reset().

The 905 (if I remember correctly, I don't have the manual handy) has 3
ways it can be used - via the FIFO like the 509, simple busmastering like
the 595 and full busmastering like, well, the 905. You can try forcing the
card to use one of the other methods (it will defualt to full busmastering)
by playing with the code which switches on the device id in the
etherelnk3reset() routine.

On Tue Nov 13 17:22:23 EST 2001, martin@Princeton.EDU wrote:
> I'm having some odd problems with what appears to be a 3C905-TX ethernet
> interface (PCI ID 9050) as supplied built in to the system board on a
> Dell Optiplex GXi.  Plan 9 is installed as a stand-alone terminal with a
> kfs on the local disk.
>
> After entering the user name and passwd I get the error message "#l0:
> sataus 0x803, diag 0x2000" (presumably this is the first time the system
> touches the network hardware.)  Perusal of the code indicates that this
> is an "rxUnderrun" and "shouldn't happen."  I also see this error if I
> disconnect the network cable during a boot.
>
> The hardware seems to be in order.  It certainly worked when I had NT
> installed on the system in question.  I see link lights at both ends,
> and the activity light on the system indicates that the hardware is
> seeing traffic on the network.
>
> If I try to ping, I see the activity light on the corresponding port on
> the hub flash about once a second, as one might expect.  But the
> interface doesn't appear to receive anything; the arp cache shows that
> it is WAITing to resolve the address of the system that I am trying to
> ping to.
>
> I've applied all the patches except the last two (which I don't believe
> contain any ethernet updates.)
>
> Any ideas???
>
> Martin