collisions with 1.09t

[Stephen Williams]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrey,

First, I left off a "0" in my original message. In fact the hub is
100baseTX, half-duplex only (it cannot support 10baseT).

Now, MII-DIAG reports the hub as advertising "0081". From the page:

http://cesdis.gsfc.nasa.gov/linux/diag/mii-status.html

I read that to mean "0x0080  100baseTx supported" and "0x001F  Protocol
selection bits, always 0x0001 for Ethernet". Have I made a mistake? This is
what I would expect.

Now, given the above, is there any way that the NIC could be operating in
full-duplex mode?

Is it worth my testing this? (I presume that I would use the option 0x20?)

I have since confirmed that I am getting similar errors on other
computers -- just not quite as bad. To give you an idea of how bad this is:

eth0      Link encap:Ethernet  HWaddr 00:90:27:BB:18:3E
          inet addr:192.168.11.10  Bcast:192.168.11.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:500571 errors:0 dropped:0 overruns:0 frame:0
          TX packets:587848 errors:0 dropped:0 overruns:0 carrier:0
          collisions:213150 txqueuelen:100
          Interrupt:11 Base address:0x2000

When the same NIC is operated under Win2000 on the same hub I might get 1
collision with 500,000 packets.

All the best,

S.

> -----Original Message-----
> From: Andrey Savochkin [mailto:saw@saw.sw.com.sg]
> Sent: Saturday, 18 March 2000 04:28
> To: Stephen Williams
> Subject: Re: collisions with 1.09t
>
>
> On Sat, Mar 18, 2000 at 04:09:45AM -0000, Stephen Williams wrote:
> > In fact, just as you wrote I had finished playing with
> MII-DIAG. Here is
> > what I got:
> >
> > Using the default interface 'eth0'.
> > Basic registers of MII PHY #1:  3000 782d 02a8 0154 05e1
> 0081 0000 0000.
> >  Basic mode control register 0x3000: Auto-negotiation enabled.
> >  You have link beat, and everything is working OK.
> >  Your link partner is generating 100baseTx link beat  (no
> autonegotiation).
>
> That's a bogus report.
>
> >
> > Since the partner is being read as "0081" I would think
> that the NIC would
> > negotiate 10baseTX half-duplex so I have come to the
> conclusion that that is
> > not the problem.
>
> Yeah, it's truly 10Mbit/s half-duplex.
>
> >
> > But in any case, I looked at the info page on the eepro100
> and it does not
> > list explcitly the code for half-duplex -- just for full duplex.
>
> Zero bit for full-duplex bit means half-duplex.
> So just pass zero options.
>
> > With Intel's drivers for Windows there is an advanced option called
> > "Adaptive Inter-Frame Spacing" which the help file defines as:
> [snip]
> > I looked at the source to see if there was any way of
> performing the same
> > function with the eepro100 driver but could not see it. Is
> it possible??
>
> No, it isn't.  Introducing such an option may create
> different problems
> without any good reason.  Such an option isn't ever needed.
> For your case
> isn't it better to fix the origin of the problem (duplex
> setting of the card)
> instead of introducing such stupid delays?
>
> Best regards
> 					Andrey V.
> 					Savochkin
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.3

iQA/AwUBONNGKh7BrDcuaQTEEQKKYgCfSJnwh+noZn9NhBe5PUG/wspr3vkAoOaU
gawLIGfNDVG748KVD9eOOP+d
=4fWs
-----END PGP SIGNATURE-----

-------------------------------------------------------------------
To unsubscribe send a message body containing "unsubscribe"
to linux-eepro100-request@beowulf.org