udelay

udelay

[Pete Popov]

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.

Pete

Re: udelay

[Kumba]

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

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.

--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: 
small hands do them because they must, while the eyes of the great are 
elsewhere."  --Elrond

Re: udelay

[Geert Uytterhoeven]

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

Re: udelay

[Kumba]

Geert Uytterhoeven wrote:

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

None that I can see.  If I'm using SSH, input/output just stops cold. 
In some cases, I have noticed that if you send a single character (like 
you were in a text editor when input/output died), and you wait a minute 
or so, it will appear.  This seems to mean the interface hasn't died 
completely, but seems to havce slowed down to the point of complete 
unsuability, like >1bps would be my guess.

Restarting the interface fixes it for several seconds until it drops 
again.  I usually disconnect from the serial console before trying any 
SSH activity, as serial console work + network activity can halt the 
kernel (which I have confirmed does occur in 2.4.21 CVS).

As an experiment, I did try replacing the udelay(1000) line in the 
cobalt patch with mdelay(1) to see if this udelay() brokeness was the 
issue, but it still drops out after several seconds.

--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: 
small hands do them because they must, while the eyes of the great are 
elsewhere."  --Elrond

Re: udelay

[Ralf Baechle]

On Fri, Aug 01, 2003 at 06:49:08PM -0700, 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.

That just doesn't make sense.  Mdelay is based on udelay so if udelay
is broken mdelay should be broken, too.

  Ralf

Re: udelay

[Pete Popov]

On Sun, 2003-08-03 at 18:41, Ralf Baechle wrote:
> On Fri, Aug 01, 2003 at 06:49:08PM -0700, 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.
> 
> That just doesn't make sense.  Mdelay is based on udelay so if udelay
> is broken mdelay should be broken, too.

I think the problem may be occurring when udelay is used with very large
values, like 10000. I've told the developer that that's not recommended
and to use mdelays in that case.

Pete

Re: udelay

[Ralf Baechle]

On Mon, Aug 04, 2003 at 10:29:20AM -0700, 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.
> > 
> > That just doesn't make sense.  Mdelay is based on udelay so if udelay
> > is broken mdelay should be broken, too.
> 
> I think the problem may be occurring when udelay is used with very large
> values, like 10000. I've told the developer that that's not recommended
> and to use mdelays in that case.

Any bug report for udelay arguments larger than 1000 will probably be
ignored ...

  Ralf

Re: udelay

[Pete Popov]

On Mon, 2003-08-04 at 14:38, Ralf Baechle wrote:
> On Mon, Aug 04, 2003 at 10:29:20AM -0700, 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.
> > > 
> > > That just doesn't make sense.  Mdelay is based on udelay so if udelay
> > > is broken mdelay should be broken, too.
> > 
> > I think the problem may be occurring when udelay is used with very large
> > values, like 10000. I've told the developer that that's not recommended
> > and to use mdelays in that case.
> 
> Any bug report for udelay arguments larger than 1000 will probably be
> ignored ...

I found the 'bug' before I saw your udelay comment ;)

Pete