2.4.23 can run with HZ==0!

2.4.23 can run with HZ==0!

[Frank van Maarseveen]

[-- Attachment #1: Type: text/plain, Size: 1674 bytes --]

The first thing I noticed was that a select for .2 seconds seemed to
hang in a python script I was working on that time. I didn't believe it
so I tried some other things including "sleep 1", "usleep 1", stracing
them and it all came down to one conclusion

	the clock has stopped

/proc/interrupts confirmed that the clock has stopped:

$ cat /proc/interrupts 
           CPU0       
  0:    7745428          XT-PIC  timer
  1:          2          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  8:          1          XT-PIC  rtc
  9:          0          XT-PIC  via82cxxx, usb-uhci
 11:      12106          XT-PIC  usb-uhci, usb-uhci, eth0
 12:      12079          XT-PIC  eth1
 14:       8582          XT-PIC  ide0
 15:       8623          XT-PIC  ide1
NMI:          0 
LOC:          0 
ERR:          0
MIS:          0
$ cat /proc/interrupts 
           CPU0       
  0:    7745428          XT-PIC  timer
  1:          2          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  8:          1          XT-PIC  rtc
  9:          0          XT-PIC  via82cxxx, usb-uhci
 11:      12116          XT-PIC  usb-uhci, usb-uhci, eth0
 12:      12079          XT-PIC  eth1
 14:       8582          XT-PIC  ide0
 15:       8623          XT-PIC  ide1

notice that network irqs are taking place for eth0 but no timer irqs.

halt, reboot (-f) etc didn't work because they all wanted to sleep. I
had to power cycle. Now HZ is ok (1000) again.  HZ has been patched but
that's an unlikely cause (patch attached in case you wonder).

Hardware: VIA CL6000

At the time this happened I was also playing with /dev/ttyS3 lines on
the mobo (static discharge?)

-- 
Frank

[-- Attachment #2: hz.patch --]
[-- Type: text/plain, Size: 3616 bytes --]

--- linux/include/asm-i386/param.h.hz	Mon Aug 18 12:15:42 2003
+++ linux/include/asm-i386/param.h	Mon Aug 18 12:26:26 2003
@@ -2,8 +2,9 @@
 #define _ASMi386_PARAM_H
 
 #ifndef HZ
-#define HZ 100
+#define HZ 1000
 #endif
+#define jiffies_to_clock_t(x) ((x) / (HZ / 100))
 
 #define EXEC_PAGESIZE	4096
 
--- linux/kernel/sys.c.hz	Mon Aug 18 12:15:36 2003
+++ linux/kernel/sys.c	Mon Aug 18 12:26:20 2003
@@ -807,10 +807,16 @@
 	 *	atomically safe type this is just fine. Conceptually its
 	 *	as if the syscall took an instant longer to occur.
 	 */
-	if (tbuf)
-		if (copy_to_user(tbuf, &current->times, sizeof(struct tms)))
+	if (tbuf) {
+		struct tms tmp;
+		tmp.tms_utime = jiffies_to_clock_t(current->times.tms_utime);
+		tmp.tms_stime = jiffies_to_clock_t(current->times.tms_stime);
+		tmp.tms_cutime = jiffies_to_clock_t(current->times.tms_cutime);
+		tmp.tms_cstime = jiffies_to_clock_t(current->times.tms_cstime);
+		if (copy_to_user(tbuf, &tmp, sizeof(struct tms)))
 			return -EFAULT;
-	return jiffies;
+	}
+	return jiffies_to_clock_t(jiffies);
 }
 
 /*
--- linux/kernel/timer.c.hz	Wed Dec  4 11:01:40 2002
+++ linux/kernel/timer.c	Mon Aug 18 12:15:42 2003
@@ -472,6 +472,15 @@
     else
 	time_adj += (time_adj >> 2) + (time_adj >> 5);
 #endif
+#if HZ == 1000
+    /* Compensate for (HZ==1000) != (1 << SHIFT_HZ).
+     * Add 1.5625% and 0.78125% to get 1023.4375; => only 0.05% error (p. 14)
+     */
+    if (time_adj < 0)
+	time_adj -= (-time_adj >> 6) + (-time_adj >> 7);
+    else
+	time_adj += (time_adj >> 6) + (time_adj >> 7);
+#endif
 }
 
 /* in the NTP reference this is called "hardclock()" */
--- linux/fs/proc/array.c.hz	2003-11-30 21:52:24.000000000 +0100
+++ linux/fs/proc/array.c	2003-11-30 21:52:26.000000000 +0100
@@ -362,15 +362,15 @@
 		task->cmin_flt,
 		task->maj_flt,
 		task->cmaj_flt,
-		task->times.tms_utime,
-		task->times.tms_stime,
-		task->times.tms_cutime,
-		task->times.tms_cstime,
+		jiffies_to_clock_t(task->times.tms_utime),
+		jiffies_to_clock_t(task->times.tms_stime),
+		jiffies_to_clock_t(task->times.tms_cutime),
+		jiffies_to_clock_t(task->times.tms_cstime),
 		priority,
 		nice,
 		0UL /* removed */,
 		task->it_real_value,
-		task->start_time,
+		jiffies_to_clock_t(task->start_time),
 		vsize,
 		mm ? mm->rss : 0, /* you might want to shift this left 3 */
 		task->rlim[RLIMIT_RSS].rlim_cur,
--- linux/fs/proc/proc_misc.c.hz	Mon Aug 18 12:15:26 2003
+++ linux/fs/proc/proc_misc.c	Mon Aug 18 13:35:59 2003
@@ -325,18 +325,21 @@
 	}
 
 	proc_sprintf(page, &off, &len,
-		      "cpu  %u %u %u %lu\n", user, nice, system,
-		      jif * smp_num_cpus - (user + nice + system));
+		      "cpu  %u %u %u %lu\n",
+			jiffies_to_clock_t(user),
+			jiffies_to_clock_t(nice),
+			jiffies_to_clock_t(system),
+			jiffies_to_clock_t(jif * smp_num_cpus - (user + nice + system)));
 	for (i = 0 ; i < smp_num_cpus; i++)
 		proc_sprintf(page, &off, &len,
 			"cpu%d %u %u %u %lu\n",
 			i,
-			kstat.per_cpu_user[cpu_logical_map(i)],
-			kstat.per_cpu_nice[cpu_logical_map(i)],
-			kstat.per_cpu_system[cpu_logical_map(i)],
-			jif - (  kstat.per_cpu_user[cpu_logical_map(i)] \
+			jiffies_to_clock_t(kstat.per_cpu_user[cpu_logical_map(i)]),
+			jiffies_to_clock_t(kstat.per_cpu_nice[cpu_logical_map(i)]),
+			jiffies_to_clock_t(kstat.per_cpu_system[cpu_logical_map(i)]),
+			jiffies_to_clock_t(jif - (  kstat.per_cpu_user[cpu_logical_map(i)] \
 				   + kstat.per_cpu_nice[cpu_logical_map(i)] \
-				   + kstat.per_cpu_system[cpu_logical_map(i)]));
+				   + kstat.per_cpu_system[cpu_logical_map(i)])));
 	proc_sprintf(page, &off, &len,
 		"page %u %u\n"
 		"swap %u %u\n"

Re: 2.4.23 can run with HZ==0!

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 514 bytes --]

On Mon, 2003-12-29 at 00:05, Frank van Maarseveen wrote:

> halt, reboot (-f) etc didn't work because they all wanted to sleep. I
> had to power cycle. Now HZ is ok (1000) again.  HZ has been patched but
> that's an unlikely cause

not all motherboards can deal with HZ=1000.... seems yours is one of
thise.

>
> (patch attached in case you wonder).
> 

your patch is *highly* inadequate to get HZ=1000 working well in 2.4....
it needs to be about 10x bigger with fixing more userspace api's...



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: 2.4.23 can run with HZ==0!

[Frank van Maarseveen]

On Mon, Dec 29, 2003 at 10:45:27AM +0100, Arjan van de Ven wrote:
> 
> not all motherboards can deal with HZ=1000.... seems yours is one of
> thise.

But it seems to work. I would expect it to fail quite soon right at or after
boot, not after a day once every few weeks (assuming it was the cause).

> your patch is *highly* inadequate to get HZ=1000 working well in 2.4....
> it needs to be about 10x bigger with fixing more userspace api's...

Can you give me an example?

HZ for x386 is 100 by definition and there aren't that many system calls
and /proc files which expose jiffies to userspace.

The uptime will be rather limited with 32 bits jiffies ;-) but I can live with that.

-- 
Frank

Re: 2.4.23 can run with HZ==0!

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 864 bytes --]

On Mon, Dec 29, 2003 at 01:52:40PM +0100, Frank van Maarseveen wrote:
> On Mon, Dec 29, 2003 at 10:45:27AM +0100, Arjan van de Ven wrote:
> > 
> > not all motherboards can deal with HZ=1000.... seems yours is one of
> > thise.
> 
> But it seems to work. I would expect it to fail quite soon right at or after
> boot, not after a day once every few weeks (assuming it was the cause).
> 
> > your patch is *highly* inadequate to get HZ=1000 working well in 2.4....
> > it needs to be about 10x bigger with fixing more userspace api's...
> 
> Can you give me an example?
> 
> HZ for x386 is 100 by definition and there aren't that many system calls
> and /proc files which expose jiffies to userspace.

there are quite a few you missed; scsi ioctls is one, firewall rules are
another.... there's a long list (2.6 has most if not all of them fixed)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: 2.4.23 can run with HZ==0!

[Rob Love]

On Mon, 2003-12-29 at 07:52, Frank van Maarseveen wrote:

> Can you give me an example?

Sure, as this has already been done:

	http://www.kernel.org/pub/linux/kernel/people/rml/variable-HZ/v2.4/

As you see, that has a ton of fixups, primarily to ensure that
user-space is always exported jiffies in terms of USER_HZ==100.

> The uptime will be rather limited with 32 bits jiffies ;-) but I can live with that.

There is a patch at that same place that adds 64-bit jiffies.

	Rob Love

Re: 2.4.23 can run with HZ==0!

[Frank van Maarseveen]

On Mon, Dec 29, 2003 at 10:26:25AM -0500, Rob Love wrote:
> On Mon, 2003-12-29 at 07:52, Frank van Maarseveen wrote:
> 
> > Can you give me an example?
> 
> Sure, as this has already been done:
> 
> 	http://www.kernel.org/pub/linux/kernel/people/rml/variable-HZ/v2.4/

That looks more complete and its cleaner. When I needed the HZ patch I
deliberately didn't care about #ifdef __KERNEL__ in the header files. It
was a tmp hack anyway.

it doesn't contain the #if HZ==1000 fix in timer.c. I'm not sure if it
is that important and this one is broke since it fixes yet another HZ
value instead of all.

> 
> As you see, that has a ton of fixups, primarily to ensure that
> user-space is always exported jiffies in terms of USER_HZ==100.

I missed a two or three cases. Hoever, no sign of the tenfold size increase
or any fixes inside SCSI ioctls or firewall rules (netfilter code I presume).

Arjan, are you sure?

-- 
Frank

Re: 2.4.23 can run with HZ==0!

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 303 bytes --]

On Mon, Dec 29, 2003 at 04:54:33PM +0100, Frank van Maarseveen wrote:
> I missed a two or three cases. Hoever, no sign of the tenfold size increase
> or any fixes inside SCSI ioctls or firewall rules (netfilter code I presume).

Robert's patchkit is quite incomplete too.

> Arjan, are you sure?

Yes.


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: 2.4.23 can run with HZ==0!

[Rob Love]

On Mon, 2003-12-29 at 10:54, Frank van Maarseveen wrote:

> I missed a two or three cases. Hoever, no sign of the tenfold size increase
> or any fixes inside SCSI ioctls or firewall rules (netfilter code I presume).
> 
> Arjan, are you sure?

I am probably missing places, too.  There are quite a bit.

	Rob Love