linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* RE: eepro100/e100 drivers fragment heavily
@ 2002-09-23 20:03 Feldman, Scott
  2002-09-24 16:06 ` AW: " Todor Todorov
  0 siblings, 1 reply; 3+ messages in thread
From: Feldman, Scott @ 2002-09-23 20:03 UTC (permalink / raw)
  To: 'Todor Todorov', linux-kernel

Todor Todorov wrote:

> The computer is a 
> Dell Inspiron 8000 laptop with an internal Actiontec 
> modem/nic combo pci card based on the Intel Pro chip, running 
> Debian. I observed this behaviour with the eepro100 drivers 
> in 2.4.19, 2.4.20-pre6 and 2.4.20-pre7 and e100 drivers in 
> 2.4.20-pre6 and -pre7. Pulling data from the network is fine 
> and fast though, only sending is a problem. The only hint I 
> have of what migh be causing the problem is something I read 
> in the specs of my NWAY SOHO switch - it would allow 
> full-duplex 100 MBit/sec only based on auto negotiation, if a 
> nic is in forced mode (say 100 MBit full-duplex), the swith 
> will allow only 100 MBit half-duplex. I tried other high 
> quality switches too, but the result was the same. 

Please confirm that the switch and nic are both set to auto-neg, or both the
switch and the nic forced to the same settings (i.e. 100/half).  We need to
make sure both ends of the wire match.

-scott

^ permalink raw reply	[flat|nested] 3+ messages in thread

* AW: eepro100/e100 drivers fragment heavily
  2002-09-23 20:03 eepro100/e100 drivers fragment heavily Feldman, Scott
@ 2002-09-24 16:06 ` Todor Todorov
  0 siblings, 0 replies; 3+ messages in thread
From: Todor Todorov @ 2002-09-24 16:06 UTC (permalink / raw)
  To: 'Feldman, Scott', linux-kernel

Hi everyone,

I can confirm that the nic is set to auto-sensing/auto-negotiation.
There is no way for me to change the behaviour of the switch, it's
always auto-negotiation. Also, I cannot say to what state a port on the
switch is set at one time - if it is half- or full-duplex etc.

But it would seem that I have some sort of hardware problem, my guess
would be the motherboard. Some problems with my cd/dvd drive occurred,
besides this the I installed win xp on the same machine as dual boot to
check it out and the network behaviour is exactly the same. Sorry, it
seems to be false alarm.

Cheers,
Todor

-----Ursprüngliche Nachricht-----
Von: Feldman, Scott [mailto:scott.feldman@intel.com] 
Gesendet: Montag, 23. September 2002 22:04
An: 'Todor Todorov'; linux-kernel@vger.kernel.org
Betreff: RE: eepro100/e100 drivers fragment heavily

Todor Todorov wrote:

> The computer is a 
> Dell Inspiron 8000 laptop with an internal Actiontec 
> modem/nic combo pci card based on the Intel Pro chip, running 
> Debian. I observed this behaviour with the eepro100 drivers 
> in 2.4.19, 2.4.20-pre6 and 2.4.20-pre7 and e100 drivers in 
> 2.4.20-pre6 and -pre7. Pulling data from the network is fine 
> and fast though, only sending is a problem. The only hint I 
> have of what migh be causing the problem is something I read 
> in the specs of my NWAY SOHO switch - it would allow 
> full-duplex 100 MBit/sec only based on auto negotiation, if a 
> nic is in forced mode (say 100 MBit full-duplex), the swith 
> will allow only 100 MBit half-duplex. I tried other high 
> quality switches too, but the result was the same. 

Please confirm that the switch and nic are both set to auto-neg, or both
the
switch and the nic forced to the same settings (i.e. 100/half).  We need
to
make sure both ends of the wire match.

-scott




^ permalink raw reply	[flat|nested] 3+ messages in thread

* eepro100/e100 drivers fragment heavily
@ 2002-09-21 17:11 Todor Todorov
  0 siblings, 0 replies; 3+ messages in thread
From: Todor Todorov @ 2002-09-21 17:11 UTC (permalink / raw)
  To: linux-kernel

Hello everyone,

I have a bit of a problem with my Intel based 10/100 pci NIC and kernel 2.4.19, 2.4.20-pre6 and 2.4.20-pre7. I noticed heavy tcp fragmentation when sending data to the network from my linux box. The transfers always stall. The computer is a Dell Inspiron 8000 laptop with an internal Actiontec modem/nic combo pci card based on the Intel Pro chip, running Debian. I observed this behaviour with the eepro100 drivers in 2.4.19, 2.4.20-pre6 and 2.4.20-pre7 and e100 drivers in 2.4.20-pre6 and -pre7. Pulling data from the network is fine and fast though, only sending is a problem.
The only hint I have of what migh be causing the problem is something I read in the specs of my NWAY SOHO switch - it would allow full-duplex 100 MBit/sec only based on auto negotiation, if a nic is in forced mode (say 100 MBit full-duplex), the swith will allow only 100 MBit half-duplex. I tried other high quality switches too, but the result was the same. The other thing worth mentioning is that I have two other servers on the network with pci NICs based on the Realtek RTL 8139 B/D chips and when booting them I always see the message "Setting 100 MBit/sec full-duplex based on auto-negotiation ability". They never have this problem with fragmentation, both pulling and sending data from them is always fast and without any problems. (except when the Dell laptop is involved ;)

So do the eepro100 and e100 drivers have any problem with auto-negotiation? Or does anyone have any other ideas? I'd be glad to run any test you want me to and provide any other information you need, in order to solve this problem.

Thanks in advance.
T.Todorov

______________________________________________________________________________
Jetzt testen für 1 Euro! Ihr All-in-one-Paket! 
https://digitaledienste.web.de/Club/?mc=021106


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2002-09-24 15:56 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-09-23 20:03 eepro100/e100 drivers fragment heavily Feldman, Scott
2002-09-24 16:06 ` AW: " Todor Todorov
  -- strict thread matches above, loose matches on Subject: below --
2002-09-21 17:11 Todor Todorov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).