#
# patch < (this file)
#
--- xmbmon.c.old_bug	Tue Aug 28 00:23:35 2001
+++ xmbmon.c	Thu Aug 30 02:41:57 2001
@@ -29,6 +29,10 @@
  *     New SMBus access method without "intpm" driver!
  *     VIA VT82C686A/B's HWM chip supported.
  *
+ * ver.1.06p1, 2001.08.30
+ *     A serious bug of alarm-signal handler fixed
+ *     by replacing signal(3) to XtAppAddTimeOut(3Xt).
+ *
  * xmbmon  --- X mother board monitor
  *
  *
@@ -44,7 +48,7 @@
  *
  */
 
-#define XMBMON_VERSION "1.06"
+#define XMBMON_VERSION "1.06p1"
 
 #ifdef HAVE_CONFIG_H
 #include "config.h"
@@ -53,7 +57,6 @@
 #include <stdio.h>
 #include <stdlib.h>
 #include <sys/time.h>
-#include <signal.h>
 
 /* debug flag used in InitMBInfo() */
 int debug_flag = 0;
@@ -118,8 +121,7 @@
 int w_counter = 0;
 int w_range;
 
-int t_sec, t_usec;
-struct itimerval itv;
+unsigned long t_sec, t_msec;
 
 typedef struct ring_data {
 	float val;
@@ -167,8 +169,8 @@
 void repaint_proc(void);
 void quit_proc(void);
 void draw_values(void);
-sig_t alarm_handler(int);
 int ColorPix(Display *, char *, unsigned long *);
+void alarm_handler(void);
 
 /*---------- definitions of static data for X Toolkits ----------*/
 
@@ -373,12 +375,13 @@
 	XMBMON_VERSION, DEFAULT_METHOD);
 	exit(1);
 }
+
+/* Xt Application Context, global */
+	XtAppContext app_con;
 	
 int main(int argc, char *argv[])
 {
 
-	XtAppContext app_con;
-
 	get_args(argc, argv);
 
 	wgt = XtVaAppInitialize(&app_con, RES_NAME,
@@ -392,6 +395,7 @@
 	get_res();
 	init_dt();
 
+	XtAppAddTimeOut(app_con, t_msec, (XtTimerCallbackProc) alarm_handler, NULL);
 	XtAppMainLoop(app_con);
 }
 
@@ -579,8 +583,6 @@
 
 void init_dt(void)
 {
-	extern sig_t alarm_handler();
-	struct itimerval *itp = &itv;
 	ring_d *p;
 	int n, i;
 	float d;
@@ -722,28 +724,14 @@
 	scale[3] = vscl;
 # endif
 
-	if (signal(SIGALRM, SIG_IGN) != SIG_IGN)
-		signal(SIGALRM, (sig_t) alarm_handler);
-
 	t_sec = interval_sec / n_count;
-	t_usec = (interval_sec % n_count) * 1000000 / n_count;
-
-	itp->it_interval.tv_sec = t_sec;
-	itp->it_interval.tv_usec = t_usec;
-	itp->it_value.tv_sec = t_sec;
-	itp->it_value.tv_usec = t_usec;
-
-	setitimer(ITIMER_REAL, itp, (struct itimerval *) 0);
+	t_msec = 1000 * t_sec;
 }
-
-sig_t alarm_handler(int sig)
+void alarm_handler(void)
 {
-	struct itimerval *itp = &itv;
 	float d, *p;
 	int i, n;
 
-	signal(sig, SIG_IGN);
-
 # ifdef NO_TEMP3
 	getTemp(&cur_val[0], &cur_val[1], &d);
 	getVolt(&cur_val[2], &d, &d, &d, &d, &d, &d);
@@ -776,14 +764,7 @@
 		}
 		repaint_proc();
 	}
-
-	itp->it_interval.tv_sec = t_sec;
-	itp->it_interval.tv_usec = t_usec;
-	itp->it_value.tv_sec = t_sec;
-	itp->it_value.tv_usec = t_usec;
-
-	setitimer(ITIMER_REAL, itp, (struct itimerval *) 0);
-	signal(SIGALRM, (sig_t) alarm_handler);
+	XtAppAddTimeOut(app_con, t_msec, (XtTimerCallbackProc) alarm_handler, NULL);
 }
 
 void draw_values(void)
--- 00README.txt.old	Thu Aug 30 03:20:52 2001
+++ 00README.txt	Thu Aug 30 03:20:52 2001
@@ -1,7 +1,7 @@
  *********************************************************
     Mother Board Monitor Program for X Window System
 
-        XMBmon ver.1.06
+        XMBmon ver.1.06pl1
 
     for FreeBSD (and possibly Linux, but not checked).
  *********************************************************
@@ -298,54 +298,10 @@
 
 << 7. Bugs >>
 
-  As I explained, the programs use their own direct SMBus access
-functions, which are newly included in this version.  Therefore,
-if with default compiling option, the programs solely rely on the
-IO port access to get the information from the hardware monitor chip,
-i.e., in FreeBSD, they open the device file /dev/io and perform
-input/output for this purpose.  This may be the reason, but if
-"xmbmon" tries to get information from /dev/io after waiting
-the timer signal interrupt, while other program is opening the same
-/dev/io file, "xmbmon" goes out of control.  Namely, it seems to
-go into infinite loops inside the kernel or at some place in shared
-library.  In any case, "xmbmon"'s display stops and it keeps in a RUN
-state forever eating CPU resources.  If such a situation happens,
-just kill the process of "xmbmon" quickly.  It seems to causes no
-serious problems on the system; no system-crashes, no reboot.
-
-  For example, you can easily check it by runing the following small
-program:
-
-#include <fcntl.h>
-#include <stdio.h>
-main()
-{
-    int io, i;
-    if ((io = open("/dev/io",000)) < 0) return -1;
-    scanf("%d", i);
-    close(io);
-}   
-
-If you just wait at the input of scanf() function for a while,
-you will find that "xmbmon" goes to "heaven".
-
-  This bug has been sitting from the very first verion of this program
-(first opened to the public at version 1.04), but quit recently
-recognized by the author.  If one uses the SMBus ioctl call method,
-there is no problem.  So I think that the bug is certainly related
-to the direct IO port access (opening /dev/io).  But the thing is
-not so simple: another program "mbmon" has no problem what's so ever!
-I suspect that this bug is related to the problematic signal
-handling of the timer interrupt in the code of "xmbmon".  I believe
-that there are not many programs which use /dev/io keeping it open
-for long time, so this bug might not be a real problem.  But if you
-have to use such kind of programs, then please give up to use "xmbmon",
-or if your mother board allows the power management device driver
-(like "intpm" or "viapm"), then use the binary compiled with the
--DSMBUS_IOCTL option.
-
-  I hope someone fixes this bug in near future.  I would greatly
-appreciate for letting me know how to fix it (Sorry I couldn't).
+  A serious bug of version 1.06, xmbmon goes out of control while 
+other processes keep opening /dev/io device file, is fixed by
+version pl1 (patch level 1).  I hope there are no more serious
+bugs (but maybe there are!).
 
 
 << 8. Those who want to support other hardware monitor chips >>
--- 00READMEj.txt.old	Thu Aug 30 03:20:53 2001
+++ 00READMEj.txt	Thu Aug 30 03:20:53 2001
@@ -1,7 +1,7 @@
  *********************************************************
     Mother Board Monitor Program for X Window System
 
-        XMBmon ver.1.06
+        XMBmon ver.1.06pl1
 
     for FreeBSD (and possibly Linux, but not checked).
  *********************************************************
@@ -287,46 +287,9 @@
 
 << 7. バグ >>
 
-　今回のヴァージョンでは自前の SMBus アクセス機能を実装したので、
-デフォルトのコンパイルオプションで作ったバイナリでは全面的に
-IO port への直接アクセスで温度等の情報を得ています。すなわち、
-FreeBSD では /dev/io を open してこの device file に IO を行なって
-います。このため、他のプログラムが /dev/io を open したまま xmbmon
-がタイマー割り込みでアイドル状態から復帰して温度等の情報を得るため
-に同じく /dev/io にアクセスしようとすると xmbmon が暴走します。
-そのような状態(xmbmon の表示が止まり、xmbmon が RUN 状態でCPU資源
-を食う)になった場合は、xmbmon を速やかに kill してください。ただし、
-システムに何らかの悪影響を及ぼすことはないようです。
-
-　例えば、
-
-#include <fcntl.h>
-#include <stdio.h>
-main()
-{
-	int io, i;
-	if ((io = open("/dev/io",000)) < 0) return -1;
-	scanf("%d", i);
-	close(io);
-}
-
-のようなプログラムを動かして、scanf() の入力をせずに待っている
-と xmbmon が暴走します。
-
-　このバグは xmbmon の最初のヴァージョン(公開は ver.1.04より)
-からあるものですが、ごく最近認識されました。ver.1.05 の intpm
-device driver を用いた ioctl による SMBus アクセスではこの問題
-は起きません。IO port への直接アクセスを行なうことによる問題の
-ようです。ただし、コマンドライン版の mbmon では問題が起きない
-ので、xmbmon のタイマー割り込みの signal handling の仕方に問題
-があるのかもしれません。普通、/dev/io device file を open した
-まま、長い時間放って置くことないと思いますが、もし、そのような
-プログラムを用いる人は使用はあきらめるか、または、新しい power
-management driver を入れて、-DSMBUS_IOCTL マクロを付けて作った
-プログラムを使用するようにしてください。
-
-　どなたかこのバグを fix できた方がいれば作者に御一報いただけ
-れば幸いです(私自身が fix できなくて残念です)。
+　verion 1.06 であった、他のプログラムが /dev/io を open したまま
+でいると xmbmon が暴走する、というバグは pl1 (patch level 1)で fix
+されました。今のところこの他に致命的なバグはないと思います。
 
 
 << 8. 他のハードウエアモニタチップに対応させたい人へ >>