Skip to contentSkip to conversation

Make sleep shell command is reliable for all architectures

PATCH New Jason McMullan 4 participants 5 messages May 20, 2008

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 Make sleep shell command is reliable for all architectures

On some architectures (MIPS is a good example), the timebase rolls over every few seconds. This patch alters the 'sleep' shell command to use a total counter of the udelay(100) sleeps instead of an end time marker to determine the end of the sleep, making the 'sleep' command capable of sleeping for any number of seconds on all architectures.

---
 common/cmd_misc.c |   10 +++++++---
 1 files changed, 7 insertions(+), 3 deletions(-)
common/cmd_misc.c +7 -3
index 126b538..2b84896 100644
@@ -29,7 +29,6 @@
 
 int do_sleep (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 {
-	ulong start = get_timer(0);
 	ulong delay;
 
 	if (argc != 2) {
@@ -37,13 +36,18 @@ int do_sleep (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 		return 1;
 	}
 
-	delay = simple_strtoul(argv[1], NULL, 10) * CFG_HZ;
+	/* Sleep in 100ms increments, as some the time base of
+	 * some architectures can roll over after only a few
+	 * seconds (MIPS is a good example of this)
+	 */
+	delay = simple_strtoul(argv[1], NULL, 10) * 10;
 
-	while (get_timer(start) < delay) {
+	while (delay > 0) {
 		if (ctrlc ()) {
 			return (-1);
 		}
 		udelay (100);
+		delay--;
 	}
 
 	return 0;
Signature · 1 line
1.5.4.3
#1 lore raw

PATCH 1/1 Make sleep shell command is reliable for all architectures

Quoted 2 lines · In message <[email protected]> you wrote:

On some architectures (MIPS is a good example), the timebase rolls over every few seconds. This patch alters the 'sleep'

Well, even if this happens, it should not cause get_timer() to show such problems. get_timer() returns an "unsigned long" and is counting in milliseconds, so a wrap-around should take about 50 days.

Quoted 4 lines

shell command to use a total counter of the udelay(100) sleeps instead of an end time marker to determine the end of the sleep, making the 'sleep' command capable of sleeping for any number of seconds on all architectures.

I tend to reject this patch because I think we should fix the cause of the problems rather than the symptoms - there are more areas in the code that rely on sane behaviour of the get_timer() functione.

Best regards,

Wolfgang Denk

Signature · 5 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The goal of science is to build better mousetraps. The goal of nature
is to build better mice.
#2 lore raw

PATCH 1/1 Make sleep shell command is reliablefor all architectures

Quoted 3 lines · Wolfgang Denk

Well, even if this happens, it should not cause get_timer() to show such problems. get_timer() returns an "unsigned long" and is counting in milliseconds, so a wrap-around should take about 50 days.

Yes, but get_timer() is not guaranteed to return 0 to MAX_ULONG, as far as I can tell.

On MIPS (even after my CFG_HZ patch), get_timer() will only return 0 to 14316 on a 300MHZ machine, as the 32-bit MIPS tick timer that forms the MIPS time base wraps to 0 after 14.316 seconds.

Quoted 3 lines

I tend to reject this patch because I think we should fix the cause of the problems rather than the symptoms - there are more areas in the code that rely on sane behaviour of the get_timer() functione.

Well, then we've got a big problem on MIPS.

Jason McMullan
MTS SW
System Firmware

NetApp

724.741.5011    Fax
724.741.5166    Direct
412.656.3519    Mobile

jason.mcmullan at netapp.com
www.netapp.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080520/7a74a3a1/attachment.pgp

#3 lore raw

PATCH 1/1 Make sleep shell command is reliablefor all architectures

Quoted 12 lines · Jason
Quoted 3 lines · Wolfgang Denk

Well, even if this happens, it should not cause get_timer() to show such problems. get_timer() returns an "unsigned long" and is counting in milliseconds, so a wrap-around should take about 50 days.

Yes, but get_timer() is not guaranteed to return 0 to MAX_ULONG, as far as I can tell.

On MIPS (even after my CFG_HZ patch), get_timer() will only return 0 to 14316 on a 300MHZ machine, as the 32-bit MIPS tick timer that forms the MIPS time base wraps to 0 after 14.316 seconds.

Quoted 5 lines
Quoted 3 lines

I tend to reject this patch because I think we should fix the cause of the problems rather than the symptoms - there are more areas in the code that rely on sane behaviour of the get_timer() functione.

Well, then we've got a big problem on MIPS.

This can be fixed by maintaining the upper bits of the timebase in software, as long we can guarantee that get_timer() is called at least once per wraparound. That is, remember the last value, and if the new value is less than the old value, increment the upper word.

-Scott

#4 lore raw

PATCH 1/1 Make sleep shell command is reliablefor all architectures

In reply to McMullan
Quoted 3 lines · In message <[email protected]> you…

Yes, but get_timer() is not guaranteed to return 0 to MAX_ULONG, as far as I can tell.

I'm not sure what you mean by that statement.

Quoted 3 lines

On MIPS (even after my CFG_HZ patch), get_timer() will only return 0 to 14316 on a 300MHZ machine, as the 32-bit MIPS tick timer that forms the MIPS time base wraps to 0 after 14.316 seconds.

That's a bug in the MIPS implementation, then.

Quoted 1 line

Well, then we've got a big problem on MIPS.

A fixable one, I hope.

Best regards,

Wolfgang Denk

Signature · 5 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The nice thing about  standards  is that there are  so many to choose
from.                                           - Andrew S. Tanenbaum