From: John Ronciak
Can we try a couple of things? 1) just comment out all the check for
link code in the e100 driver and give that a try and 2) just comment
out the update stats call and see if that works. These seem to be the
differences and we need to know which one is causing the problem.
On Mon, 23 Jan 2006, kus Kusche Klaus wrote:
From: John Ronciak
Can we try a couple of things? 1) just comment out all the check for
link code in the e100 driver and give that a try and 2) just comment
out the update stats call and see if that works. These seem to be the
differences and we
From: Jesse Brandeburg
On Mon, 23 Jan 2006, kus Kusche Klaus wrote:
Here are my results:
If the watchdog doesn't get interrupted, preempted, or whatever,
it spends 340 us in its body:
* 303 us in the mii code
* 36 us in the following code up to e100_adjust_adaptive_ifs
* 1 us in
From: John Ronciak
During the watchdog the e100 driver reads all of the status registers
from the actual hardware. There are 26 (worst case) register reads.
There is also a spin lock for another check in the watchdog. It would
still surprise me that all of this would take 500 usec. If you
On Fri, Jan 20, 2006 at 10:37:43AM +0100, kus Kusche Klaus ([EMAIL PROTECTED])
wrote:
From: John Ronciak
During the watchdog the e100 driver reads all of the status registers
from the actual hardware. There are 26 (worst case) register reads.
There is also a spin lock for another check
From: Evgeniy Polyakov [mailto:[EMAIL PROTECTED]
Each MDIO read can take upto 2 msecs (!) and at least 20
usecs in e100,
and this runs in timer handler.
Concider attaching (only compile tested) patch which moves
e100 watchdog
into workqueue.
Tested the patch. Works and has the expected
On Fri, Jan 20, 2006 at 11:51:23AM +0100, kus Kusche Klaus ([EMAIL PROTECTED])
wrote:
From: Evgeniy Polyakov [mailto:[EMAIL PROTECTED]
Each MDIO read can take upto 2 msecs (!) and at least 20
usecs in e100,
and this runs in timer handler.
Concider attaching (only compile tested) patch
On Fri, Jan 20, 2006 at 11:19:20AM +0100, kus Kusche Klaus ([EMAIL PROTECTED])
wrote:
From: Evgeniy Polyakov
Each MDIO read can take upto 2 msecs (!) and at least 20
usecs in e100,
and this runs in timer handler.
Concider attaching (only compile tested) patch which moves
e100
From: Evgeniy Polyakov
Just a hack:
--- drivers/net/e100.c.1 2006-01-20 13:39:19.0 +0300
+++ drivers/net/e100.c2006-01-20 14:15:40.0 +0300
@@ -879,8 +879,8 @@
writel((reg 16) | (addr 21) | dir | data,
nic-csr-mdi_ctrl);
- for(i = 0; i 100;
On Fri, 2006-01-20 at 12:55 +0300, Evgeniy Polyakov wrote:
Analysis of e100:
* If I comment out the whole body of e100_watchdog except for the
timer re-registration, the delays are gone (so it is really the
body of e100_watchdog). However, this makes eth0 non-functional.
* Commenting
On Fri, 2006-01-20 at 11:19 +0100, kus Kusche Klaus wrote:
For a non-full preemption kernel, your patch moves the 500 us
piece of code from kernel to thread context, so it really
improves things. But is 500 us something to worry about in a
non-full preemption kernel?
Yes, absolutely. Once
On 1/20/06, Lee Revell [EMAIL PROTECTED] wrote:
Seems like the important question is, why does e100 need a watchdog if
eepro100 works fine without one? Isn't the point of a watchdog in this
context to work around other bugs in the driver (or the hardware)?
There are a number of things that the
On Fri, 2006-01-20 at 17:19 -0800, John Ronciak wrote:
On 1/20/06, Lee Revell [EMAIL PROTECTED] wrote:
Seems like the important question is, why does e100 need a watchdog if
eepro100 works fine without one? Isn't the point of a watchdog in this
context to work around other bugs in the
On 1/20/06, Lee Revell [EMAIL PROTECTED] wrote:
Why don't these cause excessive scheduling delays in eepro100 then?
Can't we just copy the eepro100 behavior?
Reports still float around from time to time about hangs with the
eepro100 which go away when the e100 driver is used. We don't
maintain
On Fri, 2006-01-20 at 18:01 -0800, John Ronciak wrote:
There is a timer routine in the eepro100 driver which does the check
for link as well as a check for on of the hang conditions (with
work-around). It does the check for link in a different way than
e100. e100 uses mii call where eepro100
On Thu, Jan 19, 2006 at 11:26:51AM +0100, kus Kusche Klaus wrote:
From: Lee Revell
On Thu, 2006-01-19 at 08:19 +0100, kus Kusche Klaus wrote:
Last time I tested (around 2.6.12), eepro100 worked much better
in -rt kernels w.r.t. latencies than e100:
e100 caused a periodic latency
During the watchdog the e100 driver reads all of the status registers
from the actual hardware. There are 26 (worst case) register reads.
There is also a spin lock for another check in the watchdog. It would
still surprise me that all of this would take 500 usec. If you are
seeing this delay,
17 matches
Mail list logo
