Subject: udelay

From: Pete Popov <[email-masked]>
Date: 01 Aug 2003 18:49:08 -0700

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

---

From: Kumba <[email-masked]>
Date: Fri, 01 Aug 2003 22:42:41 -0400

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

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

---

From: Geert Uytterhoeven <[email-masked]>
Date: Sat, 2 Aug 2003 14:01:48 +0200 (MEST)

> 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 -- [email-masked]

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

---

From: Kumba <[email-masked]>
Date: Sat, 02 Aug 2003 16:41:59 -0400

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

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

---

From: Ralf Baechle <[email-masked]>
Date: Mon, 4 Aug 2003 03:41:32 +0200

> 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

---

From: Pete Popov <[email-masked]>
Date: 04 Aug 2003 10:29:20 -0700

> 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

---

From: Ralf Baechle <[email-masked]>
Date: Mon, 4 Aug 2003 23:38:12 +0200

> and to use mdelays in that case.

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

  Ralf

---

From: Pete Popov <[email-masked]>
Date: 04 Aug 2003 15:04:27 -0700

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

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

Pete