LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Len Brown <len.brown@intel.com>
To: Robert Fendt <fendt@physik.uni-dortmund.de>,
	Jeff Garzik <jgarzik@pobox.com>
Cc: linux-kernel@vger.kernel.org,
	James P Ketrenos <james.p.ketrenos@intel.com>
Subject: Re: peculiar problem with 2.6, 8139too + ACPI
Date: 17 May 2004 14:24:42 -0400	[thread overview]
Message-ID: <1084818282.12349.334.camel@dhcppc4> (raw)
In-Reply-To: <20040517123011.7e12d297.fendt@physik.uni-dortmund.de>

On Mon, 2004-05-17 at 06:30, Robert Fendt wrote:
> On 14 May 2004 21:36:38 -0400
> Len Brown <len.brown@intel.com> wrote:
> 
> > If the 8139too has statistics counters showing if it gets
> > RX buffer over-runs, that would be interseting to observe.
> 

> a) with 'processor' loaded
> 
> robert@betazed:~$ wget http://download.sourcemage.org/iso/smgl-i386-2.6.5-20040414.iso.bz2
> --12:27:16--  http://download.sourcemage.org/iso/smgl-i386-2.6.5-20040414.iso.bz2
>            => `smgl-i386-2.6.5-20040414.iso.bz2'
> Resolving download.sourcemage.org... 152.2.210.81
> Connecting to download.sourcemage.org[152.2.210.81]:80... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 142,065,569 [text/plain]
> 
>  0% [                                     ] 202,609        2.30K/s ETA 10:17:41
> 
> 
> robert@betazed:~$ /sbin/ifconfig
> eth0      Link encap:Ethernet  HWaddr 00:0C:6E:8A:DD:BA  
>           inet addr:129.217.168.125  Bcast:129.217.168.255  Mask:255.255.255.0
>           inet6 addr: fe80::20c:6eff:fe8a:ddba/64 Scope:Link
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:933 errors:117 dropped:212 overruns:117 frame:0

BINGO

There may be a way to get more detailed stats out of the driver with
netstat or something, Jeff would know.

>           TX packets:638 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000 
>           RX bytes:622241 (607.6 KiB)  TX bytes:54355 (53.0 KiB)
>           Interrupt:5 Base address:0xc800 
> 
> 
> b) without 'processor' loaded
> 
> robert@betazed:~$ wget http://download.sourcemage.org/iso/smgl-i386-2.6.5-20040414.iso.bz2
> --11:29:17--  http://download.sourcemage.org/iso/smgl-i386-2.6.5-20040414.iso.bz2
>            => `smgl-i386-2.6.5-20040414.iso.bz2.2'
> Resolving download.sourcemage.org... 152.2.210.81
> Connecting to download.sourcemage.org[152.2.210.81]:80... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 142,065,569 [text/plain]
> 
>  3% [=>                                                  ] 5,526,132    514.93K/s
> 
> robert@betazed:~$ /sbin/ifconfig
> eth0      Link encap:Ethernet  HWaddr 00:0C:6E:8A:DD:BA  
>           inet addr:129.217.168.125  Bcast:129.217.168.255  Mask:255.255.255.0
>           inet6 addr: fe80::20c:6eff:fe8a:ddba/64 Scope:Link
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:4187 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:2313 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000 
>           RX bytes:5904292 (5.6 MiB)  TX bytes:149285 (145.7 KiB)
>           Interrupt:5 Base address:0xc800 
> 
> 
> One additional problem in debugging this is that it seems to be
> depending on the local network topology, since I somehow cannot
> reproduce it when downloading from machines on the LAN or when I have a
> slow downstream connection (e.g. DSL).

Probably something to do with packet arrival time and the ability of the
system to think it is idle.  What topology does it fail with?

> > It would also be interesting to know if you see the problem
> > more frequently when running on battery power, since some
> > systems have higher c-state exit latency when on battery.
> 
> Hmmm, I cannot see a difference between battery and ac. I will look into
> it a bit more, though.

Does
cat /proc/acpi/processor/CPU0/power
show any C3 usage?

This could be either an ACPI issue -- we may enter C3 when there really
isn't enough time to enter and exit C3 w/o thrashing the system; AND/OR
a NIC problem where the driver/device is prone to over-run errors
when the latency to memory is high.

I think we're having a similar problem with the ipw2100.  it would
be interesting if you plugged an e100 into the failing config if
it fails the same way.

-Len



  reply	other threads:[~2004-05-17 18:26 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <A6974D8E5F98D511BB910002A50A6647615FB5FE@hdsmsx403.hd.intel.com>
2004-05-15  1:36 ` Len Brown
2004-05-15 23:30   ` Robert Fendt
2004-05-17 10:30   ` Robert Fendt
2004-05-17 18:24     ` Len Brown [this message]
2004-05-17 19:10       ` Jeff Garzik
2004-05-20 23:53       ` Robert Fendt
2004-05-21  1:16         ` Len Brown
2004-05-27 13:45           ` Robert Fendt
2004-05-14 13:28 Robert Fendt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1084818282.12349.334.camel@dhcppc4 \
    --to=len.brown@intel.com \
    --cc=fendt@physik.uni-dortmund.de \
    --cc=james.p.ketrenos@intel.com \
    --cc=jgarzik@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: peculiar problem with 2.6, 8139too + ACPI' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).