linux-mips
[Top] [All Lists]

Re: udelay

To: Kumba <kumba@gentoo.org>
Subject: Re: udelay
From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: Sat, 2 Aug 2003 14:01:48 +0200 (MEST)
Cc: Linux/MIPS Development <linux-mips@linux-mips.org>
In-reply-to: <3F2B2521.2060508@gentoo.org>
Original-recipient: rfc822;linux-mips@linux-mips.org
Sender: linux-mips-bounce@linux-mips.org
On Fri, 1 Aug 2003, Kumba wrote:
> Pete Popov wrote:
> > Looks like the latest udelay in 2.4 is borked. Anyway else notice that
> > problem?  I did a 10 sec test: mdelay works, udelay is broken, at least
> > for the CPU and toolchain I'm using.
> 
> What's one way of testing this brokeness?  I've been trying to find some 
> explanation for a bug of some sort in a cobalt RaQ2 in which the tulip 
> driver (eth0) just stops dead after several minutes of use.  One of the 
> notable features of the tulip driver patch needed to work on the RaQ2 
> adds a "udelay(1000)" into the tulip source.  Without it, the eth0 on 
> the RaQ2 is dead, so I wonder if these are related.
> 
> If they are related, then this behavior has been slowly getting worse it 
> seems, as eth0 on the RaQ2 apparently has had smaller and smaller 
> amounts of time needed before the interface died.  2.4.18, it took most 
> of a day, by 2.4.21, it happens within seconds.

Any kernel messages (e.g. transmit timed out) from the tulip driver when it
dies?

Gr{oetje,eeting}s,

                                                Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                                            -- Linus Torvalds


<Prev in Thread] Current Thread [Next in Thread>