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
>
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
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 proble
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 eepro
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
main
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
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
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. O
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.
> > * C
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
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
> > e1
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
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 expec
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 watchdog
> into workqueue.
Hmmm, I don't think moving it around is worth the trouble
(neverthel
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
> 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
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, y
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 pe
18 matches
Mail list logo
