Just a note that I have rediffed for 2.5.55 the patches that use the 64
bit jiffies value to avoid uptime and process start time wrap after
49.5 days. I will push them Linus-wards when he's back.
They can be retrieved from
http://www.physik3.uni-rostock.de/tim/kernel/2.5/jiffies64-33a.patch.gz
(1/3: infrastructure)
http://www.physik3.uni-rostock.de/tim/kernel/2.5/jiffies64-33b.patch.gz
(2/3: fix uptime wrap)
http://www.physik3.uni-rostock.de/tim/kernel/2.5/jiffies64-33c.patch.gz
(3/3: 64 bit process start time)
For discussion see
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0211.1/0471.html
and
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0211.1/0847.html
Tim
On 3 February 2003 00:55, Tim Schmielau wrote:
> Just a note that I have rediffed for 2.5.55 the patches that use the
> 64 bit jiffies value to avoid uptime and process start time wrap
> after 49.5 days. I will push them Linus-wards when he's back.
> They can be retrieved from
>
>
> http://www.physik3.uni-rostock.de/tim/kernel/2.5/jiffies64-33a.patch.
>gz (1/3: infrastructure)
>
> http://www.physik3.uni-rostock.de/tim/kernel/2.5/jiffies64-33b.patch.
>gz (2/3: fix uptime wrap)
>
> http://www.physik3.uni-rostock.de/tim/kernel/2.5/jiffies64-33c.patch.
>gz (3/3: 64 bit process start time)
>
> For discussion see
> http://www.uwsg.indiana.edu/hypermail/linux/kernel/0211.1/0471.html
> and
> http://www.uwsg.indiana.edu/hypermail/linux/kernel/0211.1/0847.html
Wow... your patches are STILL not included??
My 2.4 based server approaches 250 days uptime, it would be a shame
to be unable to have uptime < 50 days with 2.5
--
vda
On Mon, Feb 03, 2003 at 08:42:59AM +0200, Denis Vlasenko wrote:
> On 3 February 2003 00:55, Tim Schmielau wrote:
> > Just a note that I have rediffed for 2.5.55 the patches that use the
> > 64 bit jiffies value to avoid uptime and process start time wrap
> > after 49.5 days. I will push them Linus-wards when he's back.
> > They can be retrieved from
....
> Wow... your patches are STILL not included??
> My 2.4 based server approaches 250 days uptime, it would be a shame
> to be unable to have uptime < 50 days with 2.5
You don't need to have 64-bit jiffy for things like internal
timers, nor for uptime tracking.
Timers have well behaving constructs to use 32-bit jiffy quite
successfully, and 64-bit values, especially atomicish, in 32-bit
register-poor machines (i386) are damn difficult.
I do have a number of machines with 100 to 300 day uptimes, all
with "mere" 32-bit jiffy. With 1000 Hz clock that means at least
one full wrap-around of jiffy.
> --
> vda
/Matti Aarnio
On Mon, 3 Feb 2003, Matti Aarnio wrote:
> I do have a number of machines with 100 to 300 day uptimes, all
> with "mere" 32-bit jiffy. With 1000 Hz clock that means at least
> one full wrap-around of jiffy.
Are these 2.5 machines? If so I'd really like to know whether or not
ps shows old processes as having started in the future.
With a simulated uptime it does, but I might have overlooked something.
Tim
On Mon, Feb 03, 2003 at 09:47:00AM +0100, Tim Schmielau wrote:
> On Mon, 3 Feb 2003, Matti Aarnio wrote:
> > I do have a number of machines with 100 to 300 day uptimes, all
> > with "mere" 32-bit jiffy. With 1000 Hz clock that means at least
> > one full wrap-around of jiffy.
>
> Are these 2.5 machines? If so I'd really like to know whether or not
> ps shows old processes as having started in the future.
> With a simulated uptime it does, but I might have overlooked something.
300 day uptime with 2.5 ? Do think again.
These are 2.4 series kernels. 2.4.17, 2.4.18, 2.4.20
With updated 'ps' tools the processes are definitely in the past,
although seeing mere "2002" does not tell all that detailed about
"when". A "apr17" would be more usefull. Any date in "future"
means it is of previous year.
> Tim
/Matti Aarnio
On 3 February 2003 10:28, Matti Aarnio wrote:
> On Mon, Feb 03, 2003 at 08:42:59AM +0200, Denis Vlasenko wrote:
> > On 3 February 2003 00:55, Tim Schmielau wrote:
> > > Just a note that I have rediffed for 2.5.55 the patches that use
> > > the 64 bit jiffies value to avoid uptime and process start time
> > > wrap after 49.5 days. I will push them Linus-wards when he's
> > > back. They can be retrieved from
>
> ....
>
> > Wow... your patches are STILL not included??
> > My 2.4 based server approaches 250 days uptime, it would be a shame
> > to be unable to have uptime < 50 days with 2.5
>
> You don't need to have 64-bit jiffy for things like internal
> timers, nor for uptime tracking.
>
> Timers have well behaving constructs to use 32-bit jiffy quite
> successfully, and 64-bit values, especially atomicish, in 32-bit
> register-poor machines (i386) are damn difficult.
>
> I do have a number of machines with 100 to 300 day uptimes, all
> with "mere" 32-bit jiffy. With 1000 Hz clock that means at least
> one full wrap-around of jiffy.
Your processes will show strange start times, CPU times etc.
This will happen in 2.5 pretty soon (after 50 days uptime).
However, this is a bit cosmetic. There is a much more serious problem:
Jiffy Wrap Bugs
There were reports of machines hanging on jiffy wrap.
This is typically a result of incorrect jiffy use in some driver.
Ask Tim - he is hunting those problems regularly, but he is outnumbered
by buggy driver authors. :(
There is a better solution to ensure correct jiffy wrap handling in
*ALL* kernel code: make jiffy wrap in first five minutes of uptime.
Tim has a patch for such config option. This is almost right.
This MUST NOT be a config option, it MUST be mandatory in every
kernel. Driver writers would be bitten by their own bugs and will
fix it themself. Tim, what do you think?
--
vda
On Tue, 4 Feb 2003, Denis Vlasenko wrote:
> Jiffy Wrap Bugs
>
> There were reports of machines hanging on jiffy wrap.
> This is typically a result of incorrect jiffy use in some driver.
> Ask Tim - he is hunting those problems regularly, but he is outnumbered
> by buggy driver authors. :(
>
> There is a better solution to ensure correct jiffy wrap handling in
> *ALL* kernel code: make jiffy wrap in first five minutes of uptime.
> Tim has a patch for such config option. This is almost right.
> This MUST NOT be a config option, it MUST be mandatory in every
> kernel. Driver writers would be bitten by their own bugs and will
> fix it themself. Tim, what do you think?
How about an option, either the jiffy timer wraps at 5 minutes or
process 1 gets sent a SIGINT after 24 hours ? That way a driver
with an MIA author can still be used even if it's buggy, just not
for very long.
Okay ... perhaps it should be just an option of jiffy wrap at 5 mins
or 24 hours, but I still think reboot is better :-) :-P
--
Rob. (Robert de Bath <robert$ @ debath.co.uk>)
<http://www.cix.co.uk/~mayday>
Google Homepage: http://www.google.com/search?btnI&q=Robert+de+Bath
On 4 February 2003 10:27, Robert de Bath wrote:
> On Tue, 4 Feb 2003, Denis Vlasenko wrote:
> > Jiffy Wrap Bugs
> >
> > There were reports of machines hanging on jiffy wrap.
> > This is typically a result of incorrect jiffy use in some driver.
> > Ask Tim - he is hunting those problems regularly, but he is
> > outnumbered by buggy driver authors. :(
> >
> > There is a better solution to ensure correct jiffy wrap handling in
> > *ALL* kernel code: make jiffy wrap in first five minutes of uptime.
> > Tim has a patch for such config option. This is almost right.
> > This MUST NOT be a config option, it MUST be mandatory in every
> > kernel. Driver writers would be bitten by their own bugs and will
> > fix it themself. Tim, what do you think?
>
> How about an option, either the jiffy timer wraps at 5 minutes or
> process 1 gets sent a SIGINT after 24 hours ? That way a driver
> with an MIA author can still be used even if it's buggy, just not
> for very long.
I prefer buggy driver be fixed ASAP. The first step is to know
that there *is* a (jiffywize-) buggy driver or something.
Jiffie wrap at 5 mins is done this way: jiffies is initialized to -5*60*HZ
instead of zero at boot. Accounting code is adjusted e.g. not to show 400+
days uptime (it subtracts -5*60*HZ from jiffies).
Jiffies wraps to zero in five minutes. Box should survive with no probs.
If it instead hangs, oops or otherwise feeling bad, you have a jiffy wrap
bug somewhere.
Today you need to wait 400 or so days before you can test what will happen.
Production servers' admins getting a bit nervous close to that date ;)
A nice printk "Timer code check..." at jiffies = -30*HZ
and "...timer code check passed" at jiffies = 30*HZ will let us have
good bug reports ("what was your last log message?") and would not
scare people. "A jiffie would wrap in 5 seconds!" is not that good -
please do not unnecessarily scare new users ;)
--
vda
On Tue, 4 February 2003 08:41:13 +0200, Denis Vlasenko wrote:
>
> Jiffy Wrap Bugs
>
> There is a better solution to ensure correct jiffy wrap handling in
> *ALL* kernel code: make jiffy wrap in first five minutes of uptime.
> Tim has a patch for such config option. This is almost right.
This sounds very interesting. Is this patch availlable somewhere? If
not, could you send a copy to me, Tim?
J?rn
--
When people work hard for you for a pat on the back, you've got
to give them that pat.
-- Robert Heinlein
On Mon, 3 Feb 2003, Matti Aarnio wrote:
> On Mon, Feb 03, 2003 at 09:47:00AM +0100, Tim Schmielau wrote:
> > On Mon, 3 Feb 2003, Matti Aarnio wrote:
> > > I do have a number of machines with 100 to 300 day uptimes, all
> > > with "mere" 32-bit jiffy. With 1000 Hz clock that means at least
> > > one full wrap-around of jiffy.
> >
> > Are these 2.5 machines? If so I'd really like to know whether or not
> > ps shows old processes as having started in the future.
> > With a simulated uptime it does, but I might have overlooked something.
>
> 300 day uptime with 2.5 ? Do think again.
Well, 100 days of uptime could be around 2.5.40.
>
> These are 2.4 series kernels. 2.4.17, 2.4.18, 2.4.20
>
> With updated 'ps' tools the processes are definitely in the past,
> although seeing mere "2002" does not tell all that detailed about
> "when". A "apr17" would be more usefull. Any date in "future"
> means it is of previous year.
Ok, so on these machines jifies haven't wrapped yet (if you haven't
changed HZ).
Thanks anyways,
Tim
On Tue, 4 Feb 2003, [iso-8859-1] J?rn Engel wrote:
> On Tue, 4 February 2003 08:41:13 +0200, Denis Vlasenko wrote:
> >
> > Jiffy Wrap Bugs
> >
> > There is a better solution to ensure correct jiffy wrap handling in
> > *ALL* kernel code: make jiffy wrap in first five minutes of uptime.
> > Tim has a patch for such config option. This is almost right.
>
> This sounds very interesting. Is this patch availlable somewhere? If
> not, could you send a copy to me, Tim?
A patch for 2.4.20-pre7 (and maybe later) is at
http://www.physik3.uni-rostock.de/tim/kernel/2.4/
I still need to forward port it to 2.5 (which should be easy).
Tim
On Tue, 4 Feb 2003, Denis Vlasenko wrote:
| On 3 February 2003 10:28, Matti Aarnio wrote:
| >
| > You don't need to have 64-bit jiffy for things like internal
| > timers, nor for uptime tracking.
| >
| > Timers have well behaving constructs to use 32-bit jiffy quite
| > successfully, and 64-bit values, especially atomicish, in 32-bit
| > register-poor machines (i386) are damn difficult.
| >
| > I do have a number of machines with 100 to 300 day uptimes, all
| > with "mere" 32-bit jiffy. With 1000 Hz clock that means at least
| > one full wrap-around of jiffy.
|
| Your processes will show strange start times, CPU times etc.
| This will happen in 2.5 pretty soon (after 50 days uptime).
|
| However, this is a bit cosmetic. There is a much more serious problem:
|
| Jiffy Wrap Bugs
|
| There were reports of machines hanging on jiffy wrap.
| This is typically a result of incorrect jiffy use in some driver.
| Ask Tim - he is hunting those problems regularly, but he is outnumbered
| by buggy driver authors. :(
|
| There is a better solution to ensure correct jiffy wrap handling in
| *ALL* kernel code: make jiffy wrap in first five minutes of uptime.
| Tim has a patch for such config option. This is almost right.
| This MUST NOT be a config option, it MUST be mandatory in every
| kernel. Driver writers would be bitten by their own bugs and will
| fix it themself. Tim, what do you think?
I like it too. We should take advantage of easy-to-force/find/fix
problems like this.
--
~Randy
Hello!
On Sun, Feb 02, 2003 at 11:55:40PM +0100, Tim Schmielau wrote:
> Just a note that I have rediffed for 2.5.55 the patches that use the 64
> bit jiffies value to avoid uptime and process start time wrap after
> 49.5 days. I will push them Linus-wards when he's back.
> They can be retrieved from
> http://www.physik3.uni-rostock.de/tim/kernel/2.5/jiffies64-33a.patch.gz
> (1/3: infrastructure)
> http://www.physik3.uni-rostock.de/tim/kernel/2.5/jiffies64-33b.patch.gz
> (2/3: fix uptime wrap)
> http://www.physik3.uni-rostock.de/tim/kernel/2.5/jiffies64-33c.patch.gz
> (3/3: 64 bit process start time)
Unfortunatelly your changes in fs/proc/proc_misc.c broke every arch that
still uses HZ=100 (e.g. UML), because there is no "times" field in task
struct.
See this part:
+ {
+ unsigned long idle = init_task.times.tms_utime
+ + init_task.times.tms_stime;
In order to get UML to compile again (and pretty much any other HZ=100 arch)
I need to apply this patch below:
===== fs/proc/proc_misc.c 1.63 vs edited =====
--- 1.63/fs/proc/proc_misc.c Tue Nov 12 12:37:55 2002
+++ edited/fs/proc/proc_misc.c Wed Feb 5 14:28:50 2003
@@ -121,8 +121,7 @@
}
#else
{
- unsigned long idle = init_task.times.tms_utime
- + init_task.times.tms_stime;
+ unsigned long idle = init_task.utime + init_task.stime;
len = sprintf(page,"%lu.%02lu %lu.%02lu\n",
(unsigned long) uptime,
Bye,
Oleg
On Wed, 5 Feb 2003, Oleg Drokin wrote:
> In order to get UML to compile again (and pretty much any other HZ=100 arch)
> I need to apply this patch below:
>
[ further '>'s removed to allow direkt feeding to 'patch']
===== fs/proc/proc_misc.c 1.63 vs edited =====
--- 1.63/fs/proc/proc_misc.c Tue Nov 12 12:37:55 2002
+++ edited/fs/proc/proc_misc.c Wed Feb 5 14:28:50 2003
@@ -121,8 +121,7 @@
}
#else
{
- unsigned long idle = init_task.times.tms_utime
- + init_task.times.tms_stime;
+ unsigned long idle = init_task.utime + init_task.stime;
len = sprintf(page,"%lu.%02lu %lu.%02lu\n",
(unsigned long) uptime,
>
>
Yep. Unfortunately I tested HZ=100 only with the original patch and missed
these when rediffing. Thanks for spotting this.
Linus, please apply.
Tim
On Tue, 4 Feb 2003, Denis Vlasenko wrote:
> However, this is a bit cosmetic. There is a much more serious problem:
>
> Jiffy Wrap Bugs
>
> There were reports of machines hanging on jiffy wrap.
> This is typically a result of incorrect jiffy use in some driver.
> Ask Tim - he is hunting those problems regularly, but he is outnumbered
> by buggy driver authors. :(
Speaking of which - here are my fixes for 2.5.60.
Will take some sleep (and maybe even try to compile them) before feeding
the patch monkey.
Tim
--- linux-2.5.60/arch/cris/drivers/usb-host.c Fri Jan 17 03:21:51 2003
+++ linux-2.5.60-jfix/arch/cris/drivers/usb-host.c Mon Feb 10 23:07:11 2003
@@ -459,7 +459,7 @@
*R_DMA_CH8_SUB2_CMD = IO_STATE(R_DMA_CH8_SUB2_CMD, cmd, stop);
/* Somehow wait for the DMA to finish current activities */
i = jiffies + 100;
- while (jiffies < i);
+ while (time_before(jiffies, i));
first_ep = &TxIntrEPList[0];
tmp_ep = first_ep;
--- linux-2.5.60/arch/mips/baget/vacserial.c Fri Jan 17 03:22:22 2003
+++ linux-2.5.60-jfix/arch/mips/baget/vacserial.c Mon Feb 10 23:09:26 2003
@@ -1785,7 +1785,7 @@
schedule_timeout(char_time);
if (signal_pending(current))
break;
- if (timeout && ((orig_jiffies + timeout) < jiffies))
+ if (timeout && time_after(jiffies, orig_jiffies + timeout))
break;
}
current->state = TASK_RUNNING;
--- linux-2.5.60/drivers/char/moxa.c Fri Jan 17 03:22:44 2003
+++ linux-2.5.60-jfix/drivers/char/moxa.c Mon Feb 10 23:01:59 2003
@@ -2832,7 +2832,7 @@
st = jiffies;
et = st + tick;
- while (jiffies < et);
+ while (time_before(jiffies, et));
}
static void moxafunc(unsigned long ofsAddr, int cmd, ushort arg)
--- linux-2.5.60/drivers/char/mxser.c Fri Jan 17 03:22:23 2003
+++ linux-2.5.60-jfix/drivers/char/mxser.c Mon Feb 10 23:01:02 2003
@@ -857,7 +857,7 @@
while (!(inb(info->base + UART_LSR) & UART_LSR_TEMT)) {
set_current_state(TASK_INTERRUPTIBLE);
schedule_timeout(5);
- if (jiffies > timeout)
+ if (time_after(jiffies, timeout))
break;
}
}
--- linux-2.5.60/drivers/i2c/i2c-adap-ite.c Fri Jan 17 03:21:44 2003
+++ linux-2.5.60-jfix/drivers/i2c/i2c-adap-ite.c Mon Feb 10 23:04:16 2003
@@ -78,7 +78,7 @@
unsigned long j = jiffies + 10;
DEB3(printk(" Write 0x%02x to 0x%x\n",(unsigned short)val, ctl&0xff));
- DEB3({while (jiffies < j) schedule();})
+ DEB3({while (time_before(jiffies, j)) schedule();})
outw(val,ctl);
}
--- linux-2.5.60/drivers/i2c/i2c-algo-ibm_ocp.c Fri Jan 17 03:22:22 2003
+++ linux-2.5.60-jfix/drivers/i2c/i2c-algo-ibm_ocp.c Mon Feb 10 23:05:06 2003
@@ -84,7 +84,7 @@
/* respectively. This makes sure that the algorithm works. Some chips */
/* might not like this, as they have an internal timeout of some mils */
/*
-#define SLO_IO jif=jiffies;while(jiffies<=jif+i2c_table[minor].veryslow)\
+#define SLO_IO jif=jiffies;while(time_before_eq(jiffies,jif+i2c_table[minor].veryslow))\
if (need_resched) schedule();
*/
--- linux-2.5.60/drivers/isdn/hardware/eicon/i4l_idi.c Fri Jan 17 03:22:09 2003
+++ linux-2.5.60-jfix/drivers/isdn/hardware/eicon/i4l_idi.c Mon Feb 10 22:56:22 2003
@@ -3057,7 +3057,7 @@
}
timeout = jiffies + 50;
- while (timeout > jiffies) {
+ while (time_before(jiffies, timeout)) {
if (chan->e.B2Id) break;
SLEEP(10);
}
@@ -3119,7 +3119,7 @@
eicon_tx_request(card);
timeout = jiffies + 50;
- while (timeout > jiffies) {
+ while (time_before(jiffies, timeout)) {
if (chan->fsm_state) break;
SLEEP(10);
}
--- linux-2.5.60/drivers/net/hamradio/yam.c Tue Feb 11 21:28:17 2003
+++ linux-2.5.60-jfix/drivers/net/hamradio/yam.c Mon Feb 10 22:52:09 2003
@@ -350,7 +350,7 @@
wrd <<= 1;
outb(0xfc, THR(iobase));
while ((inb(LSR(iobase)) & LSR_TSRE) == 0)
- if (jiffies > timeout)
+ if (time_after(jiffies, timeout))
return -1;
}
--- linux-2.5.60/drivers/net/pcmcia/xirc2ps_cs.c Tue Feb 11 21:28:18 2003
+++ linux-2.5.60-jfix/drivers/net/pcmcia/xirc2ps_cs.c Mon Feb 10 22:42:28 2003
@@ -447,7 +447,7 @@
u_long flags;
save_flags(flags);
sti();
- while (timeout >= jiffies)
+ while (time_before_eq(jiffies, timeout))
;
restore_flags(flags);
} else {
--- linux-2.5.60/drivers/net/sis900.c Tue Feb 11 21:28:18 2003
+++ linux-2.5.60-jfix/drivers/net/sis900.c Mon Feb 10 22:54:50 2003
@@ -591,7 +591,7 @@
yield();
poll_bit ^= (mdio_read(net_dev, sis_priv->cur_phy, MII_STATUS) & poll_bit);
- if (jiffies >= timeout) {
+ if (time_after_eq(jiffies, timeout)) {
printk(KERN_WARNING "%s: reset phy and link down now\n", net_dev->name);
return -ETIME;
}
--- linux-2.5.60/drivers/net/wan/comx-hw-comx.c Fri Jan 17 03:21:38 2003
+++ linux-2.5.60-jfix/drivers/net/wan/comx-hw-comx.c Mon Feb 10 22:46:08 2003
@@ -492,11 +492,11 @@
COMX_CMD(dev, COMX_CMD_INIT);
jiffs = jiffies;
- while (COMX_readw(dev, OFF_A_L2_LINKUP) != 1 && jiffies < jiffs + HZ) {
+ while (COMX_readw(dev, OFF_A_L2_LINKUP) != 1 && time_before(jiffies, jiffs + HZ)) {
schedule_timeout(1);
}
- if (jiffies >= jiffs + HZ) {
+ if (time_after_eq(jiffies, jiffs + HZ)) {
printk(KERN_ERR "%s: board timeout on INIT command\n", dev->name);
ch->HW_release_board(dev, savep);
retval=-EIO;
@@ -507,11 +507,11 @@
COMX_CMD(dev, COMX_CMD_OPEN);
jiffs = jiffies;
- while (COMX_readw(dev, OFF_A_L2_LINKUP) != 3 && jiffies < jiffs + HZ) {
+ while (COMX_readw(dev, OFF_A_L2_LINKUP) != 3 && time_before(jiffies, jiffs + HZ)) {
schedule_timeout(1);
}
- if (jiffies >= jiffs + HZ) {
+ if (time_after_eq(jiffies, jiffs + HZ)) {
printk(KERN_ERR "%s: board timeout on OPEN command\n", dev->name);
ch->HW_release_board(dev, savep);
retval=-EIO;
--- linux-2.5.60/drivers/net/wan/comx-hw-mixcom.c Fri Jan 17 03:22:49 2003
+++ linux-2.5.60-jfix/drivers/net/wan/comx-hw-mixcom.c Mon Feb 10 22:46:53 2003
@@ -104,7 +104,7 @@
unsigned delay = 0;
while ((cec = (rd_hscx(dev, HSCX_STAR) & HSCX_CEC) != 0) &&
- (jiffs + HZ > jiffies)) {
+ time_before(jiffies, jiffs + HZ)) {
udelay(1);
if (++delay > (100000 / HZ)) break;
}
--- linux-2.5.60/drivers/scsi/sym53c416.c Fri Jan 17 03:21:39 2003
+++ linux-2.5.60-jfix/drivers/scsi/sym53c416.c Mon Feb 10 23:06:31 2003
@@ -272,7 +272,7 @@
{
i = jiffies + timeout;
spin_unlock_irqrestore(&sym53c416_lock, flags);
- while(jiffies < i && (inb(base + PIO_INT_REG) & EMPTY) && timeout)
+ while(time_before(jiffies, i) && (inb(base + PIO_INT_REG) & EMPTY) && timeout)
if(inb(base + PIO_INT_REG) & SCI)
timeout = 0;
spin_lock_irqsave(&sym53c416_lock, flags);
@@ -316,7 +316,7 @@
{
i = jiffies + timeout;
spin_unlock_irqrestore(&sym53c416_lock, flags);
- while(jiffies < i && (inb(base + PIO_INT_REG) & FULL) && timeout)
+ while(time_before(jiffies, i) && (inb(base + PIO_INT_REG) & FULL) && timeout)
;
spin_lock_irqsave(&sym53c416_lock, flags);
if(inb(base + PIO_INT_REG) & FULL)
@@ -552,7 +552,7 @@
outb(0x00, base + DEST_BUS_ID);
/* Wait for interrupt to occur */
i = jiffies + 20;
- while(i > jiffies && !(inb(base + STATUS_REG) & SCI))
+ while(time_before(jiffies, i) && !(inb(base + STATUS_REG) & SCI))
barrier();
if(time_before_eq(i, jiffies)) /* timed out */
return 0;
--- linux-2.5.60/sound/oss/vwsnd.c Fri Jan 17 03:22:16 2003
+++ linux-2.5.60-jfix/sound/oss/vwsnd.c Mon Feb 10 23:10:57 2003
@@ -3260,7 +3260,7 @@
li_writel(&lith, LI_HOST_CONTROLLER, LI_HC_LINK_ENABLE);
do {
w = li_readl(&lith, LI_HOST_CONTROLLER);
- } while (w == LI_HC_LINK_ENABLE && jiffies < later);
+ } while (w == LI_HC_LINK_ENABLE && time_before(jiffies, later));
li_destroy(&lith);
--- linux-2.5.60/sound/pci/ens1370.c Tue Feb 11 21:28:31 2003
+++ linux-2.5.60-jfix/sound/pci/ens1370.c Mon Feb 10 23:12:38 2003
@@ -1664,7 +1664,7 @@
if (!request_region(ensoniq->gameport.io, 8, "ens137x: gameport")) {
#define ES___GAMEPORT_LOG_DELAY (30*HZ)
// avoid log pollution: limit to 2 infos per minute
- if (jiffies > last_jiffies + ES___GAMEPORT_LOG_DELAY) {
+ if (time_after(jiffies, last_jiffies + ES___GAMEPORT_LOG_DELAY)) {
last_jiffies = jiffies;
snd_printk("gameport io port 0x%03x in use", ensoniq->gameport.io);
}
--- linux-2.5.60/sound/pci/korg1212/korg1212.c Tue Feb 11 21:28:31 2003
+++ linux-2.5.60-jfix/sound/pci/korg1212/korg1212.c Mon Feb 10 23:11:33 2003
@@ -598,7 +598,7 @@
return;
if (!korg1212->inIRQ)
schedule();
- } while (jiffies < endtime);
+ } while (time_before(jiffies, endtime));
writel(0, &korg1212->sharedBufferPtr->cardCommand);
}
On Tuesday 11 February 2003 21:50, Tim Schmielau wrote:
> On Tue, 4 Feb 2003, Denis Vlasenko wrote:
>
> > However, this is a bit cosmetic. There is a much more serious problem:
> >
> > Jiffy Wrap Bugs
> >
> > There were reports of machines hanging on jiffy wrap.
> > This is typically a result of incorrect jiffy use in some driver.
> > Ask Tim - he is hunting those problems regularly, but he is outnumbered
> > by buggy driver authors. :(
>
> Speaking of which - here are my fixes for 2.5.60.
> Will take some sleep (and maybe even try to compile them) before feeding
> the patch monkey.
>
> Tim
>
>
> --- linux-2.5.60/arch/cris/drivers/usb-host.c Fri Jan 17 03:21:51 2003
> +++ linux-2.5.60-jfix/arch/cris/drivers/usb-host.c Mon Feb 10 23:07:11 2003
> @@ -459,7 +459,7 @@
> *R_DMA_CH8_SUB2_CMD = IO_STATE(R_DMA_CH8_SUB2_CMD, cmd, stop);
> /* Somehow wait for the DMA to finish current activities */
> i = jiffies + 100;
> - while (jiffies < i);
> + while (time_before(jiffies, i));
Busy wait? For several jiffies! Please...
I hope that interrupts are not disabled.
> --- linux-2.5.60/drivers/char/moxa.c Fri Jan 17 03:22:44 2003
> +++ linux-2.5.60-jfix/drivers/char/moxa.c Mon Feb 10 23:01:59 2003
> @@ -2832,7 +2832,7 @@
>
> st = jiffies;
> et = st + tick;
> - while (jiffies < et);
> + while (time_before(jiffies, et));
> }
This is the function before the patch:
/*
* moxadelay - delays a specified number ticks
*/
static void moxadelay(int tick)
{
unsigned long st, et;
st = jiffies;
et = st + tick;
while (jiffies < et);
}
And this is how it is used. In several places...
moxadelay(1); /* delay 10 ms */
Either the parameter or the comment are wrong - probably both... :-)
Since this does not guarantee anything! Jiffies might tick on the first
check...
But even worse useage is:
void MoxaPortSendBreak(int port, int ms100)
{
unsigned long ofsAddr;
ofsAddr = moxaTableAddr[port];
if (ms100) {
moxafunc(ofsAddr, FC_SendBreak, Magic_code);
moxadelay(ms100 * (HZ / 10));
} else {
moxafunc(ofsAddr, FC_SendBreak, Magic_code);
moxadelay(HZ / 4); /* 250 ms */
}
moxafunc(ofsAddr, FC_StopBreak, Magic_code);
}
And this is not enough - the parameter comes from user space...
(it is said to be in units between 250 ... 500 ms, the code above uses
100 ms...)
And there are more uses like this...
/RogerL
--
Roger Larsson
Skellefte?
Sweden
> > --- linux-2.5.60/arch/cris/drivers/usb-host.c Fri Jan 17 03:21:51 2003
> > +++ linux-2.5.60-jfix/arch/cris/drivers/usb-host.c Mon Feb 10 23:07:11 2003
> > @@ -459,7 +459,7 @@
> > *R_DMA_CH8_SUB2_CMD = IO_STATE(R_DMA_CH8_SUB2_CMD, cmd, stop);
> > /* Somehow wait for the DMA to finish current activities */
> > i = jiffies + 100;
> > - while (jiffies < i);
> > + while (time_before(jiffies, i));
>
> Busy wait? For several jiffies! Please...
> I hope that interrupts are not disabled.
>
>
> > --- linux-2.5.60/drivers/char/moxa.c Fri Jan 17 03:22:44 2003
> > +++ linux-2.5.60-jfix/drivers/char/moxa.c Mon Feb 10 23:01:59 2003
[...]
>
> But even worse useage is:
>
> void MoxaPortSendBreak(int port, int ms100)
[...]
>
> And there are more uses like this...
I completely agree this is very bad practice. Still I prefer several
miliseconds of busy-waiting to a potential 49 days busy wait.
Tim
> | There is a better solution to ensure correct jiffy wrap handling in
> | *ALL* kernel code: make jiffy wrap in first five minutes of uptime.
> | Tim has a patch for such config option. This is almost right.
> | This MUST NOT be a config option, it MUST be mandatory in every
> | kernel. Driver writers would be bitten by their own bugs and will
> | fix it themself. Tim, what do you think?
>
> I like it too. We should take advantage of easy-to-force/find/fix
> problems like this.
Ok, I've forward-ported the patch to 2.5. Since 2.5 isn't supposed to be
stable anyways, I made it unconditional.
Note that it is completely transparent to the user.
Tim
--- linux-2.5.61/include/linux/time.h Sat Feb 15 11:53:48 2003
+++ linux-2.5.61-jdbg/include/linux/time.h Sun Feb 16 01:42:26 2003
@@ -28,6 +28,12 @@
#include <linux/seqlock.h>
/*
+ * Have the 32 bit jiffies value wrap 5 minutes after boot
+ * so jiffies wrap bugs show up earlier.
+ */
+#define INITIAL_JIFFIES (0xffffffffUL & (unsigned long)(-300*HZ))
+
+/*
* Change timeval to jiffies, trying to avoid the
* most obvious overflows..
*
--- linux-2.5.61/kernel/timer.c Sat Feb 15 11:53:49 2003
+++ linux-2.5.61-jdbg/kernel/timer.c Sun Feb 16 02:05:38 2003
@@ -755,7 +755,7 @@
}
/* jiffies at the most recent update of wall time */
-unsigned long wall_jiffies;
+unsigned long wall_jiffies = INITIAL_JIFFIES;
/*
* This read-write spinlock protects us from races in SMP while
@@ -1098,7 +1098,7 @@
do {
seq = read_seqbegin(&xtime_lock);
- uptime = jiffies_64;
+ uptime = jiffies_64 - INITIAL_JIFFIES;
do_div(uptime, HZ);
val.uptime = (unsigned long) uptime;
@@ -1174,6 +1174,13 @@
}
for (j = 0; j < TVR_SIZE; j++)
INIT_LIST_HEAD(base->tv1.vec + j);
+
+ base->timer_jiffies = INITIAL_JIFFIES;
+ base->tv1.index = INITIAL_JIFFIES & TVR_MASK;
+ base->tv2.index = (INITIAL_JIFFIES >> TVR_BITS) & TVN_MASK;
+ base->tv3.index = (INITIAL_JIFFIES >> (TVR_BITS+TVN_BITS)) & TVN_MASK;
+ base->tv4.index = (INITIAL_JIFFIES >> (TVR_BITS+2*TVN_BITS)) & TVN_MASK;
+ base->tv5.index = (INITIAL_JIFFIES >> (TVR_BITS+3*TVN_BITS)) & TVN_MASK;
}
static int __devinit timer_cpu_notify(struct notifier_block *self,
--- linux-2.5.61/fs/proc/array.c Sat Feb 15 11:54:54 2003
+++ linux-2.5.61-jdbg/fs/proc/array.c Sun Feb 16 01:58:26 2003
@@ -327,7 +327,8 @@
nice,
0UL /* removed */,
jiffies_to_clock_t(task->it_real_value),
- (unsigned long long) jiffies_64_to_clock_t(task->start_time),
+ (unsigned long long)
+ jiffies_64_to_clock_t(task->start_time - INITIAL_JIFFIES),
vsize,
mm ? mm->rss : 0, /* you might want to shift this left 3 */
task->rlim[RLIMIT_RSS].rlim_cur,
--- linux-2.5.61/fs/proc/proc_misc.c Sat Feb 15 11:53:47 2003
+++ linux-2.5.61-jdbg/fs/proc/proc_misc.c Sun Feb 16 02:01:17 2003
@@ -104,7 +104,7 @@
unsigned long uptime_remainder;
int len;
- uptime = get_jiffies_64();
+ uptime = get_jiffies_64() - INITIAL_JIFFIES;
uptime_remainder = (unsigned long) do_div(uptime, HZ);
#if HZ!=100
@@ -320,7 +320,7 @@
{
int i, len;
extern unsigned long total_forks;
- u64 jif = get_jiffies_64();
+ u64 jif = get_jiffies_64() - INITIAL_JIFFIES;
unsigned int sum = 0, user = 0, nice = 0, system = 0, idle = 0, iowait = 0;
for (i = 0 ; i < NR_CPUS; i++) {
--- linux-2.5.61/arch/alpha/kernel/time.c Sat Feb 15 11:53:34 2003
+++ linux-2.5.61-jdbg/arch/alpha/kernel/time.c Sun Feb 16 01:42:26 2003
@@ -50,7 +50,7 @@
#include "proto.h"
#include "irq_impl.h"
-u64 jiffies_64;
+u64 jiffies_64 = INITIAL_JIFFIES;
extern unsigned long wall_jiffies; /* kernel/timer.c */
--- linux-2.5.61/arch/arm/kernel/time.c Sat Feb 15 11:53:34 2003
+++ linux-2.5.61-jdbg/arch/arm/kernel/time.c Sun Feb 16 01:42:26 2003
@@ -32,7 +32,7 @@
#include <asm/irq.h>
#include <asm/leds.h>
-u64 jiffies_64;
+u64 jiffies_64 = INITIAL_JIFFIES;
extern unsigned long wall_jiffies;
--- linux-2.5.61/arch/cris/kernel/time.c Fri Jan 17 03:22:16 2003
+++ linux-2.5.61-jdbg/arch/cris/kernel/time.c Sun Feb 16 01:42:26 2003
@@ -45,7 +45,7 @@
#include <asm/svinto.h>
-u64 jiffies_64;
+u64 jiffies_64 = INITIAL_JIFFIES;
static int have_rtc; /* used to remember if we have an RTC or not */
--- linux-2.5.61/arch/i386/kernel/time.c Sat Feb 15 11:53:34 2003
+++ linux-2.5.61-jdbg/arch/i386/kernel/time.c Sun Feb 16 01:42:26 2003
@@ -66,7 +66,7 @@
#include "do_timer.h"
-u64 jiffies_64;
+u64 jiffies_64 = INITIAL_JIFFIES;
unsigned long cpu_khz; /* Detected as we calibrate the TSC */
--- linux-2.5.61/arch/ia64/kernel/time.c Sat Feb 15 11:53:35 2003
+++ linux-2.5.61-jdbg/arch/ia64/kernel/time.c Sun Feb 16 01:42:26 2003
@@ -27,7 +27,7 @@
extern unsigned long wall_jiffies;
extern unsigned long last_time_offset;
-u64 jiffies_64;
+u64 jiffies_64 = INITIAL_JIFFIES;
#ifdef CONFIG_IA64_DEBUG_IRQ
--- linux-2.5.61/arch/m68k/kernel/time.c Sat Feb 15 11:53:35 2003
+++ linux-2.5.61-jdbg/arch/m68k/kernel/time.c Sun Feb 16 01:42:26 2003
@@ -26,7 +26,7 @@
#include <linux/timex.h>
#include <linux/profile.h>
-u64 jiffies_64;
+u64 jiffies_64 = INITIAL_JIFFIES;
static inline int set_rtc_mmss(unsigned long nowtime)
{
--- linux-2.5.61/arch/m68knommu/kernel/time.c Sat Feb 15 11:53:35 2003
+++ linux-2.5.61-jdbg/arch/m68knommu/kernel/time.c Sun Feb 16 01:42:26 2003
@@ -26,7 +26,7 @@
#define TICK_SIZE (tick_nsec / 1000)
-u64 jiffies_64;
+u64 jiffies_64 = INITIAL_JIFFIES;
static inline int set_rtc_mmss(unsigned long nowtime)
{
--- linux-2.5.61/arch/mips/kernel/time.c Sat Feb 15 11:53:35 2003
+++ linux-2.5.61-jdbg/arch/mips/kernel/time.c Sun Feb 16 01:42:26 2003
@@ -32,7 +32,7 @@
#define USECS_PER_JIFFY (1000000/HZ)
#define USECS_PER_JIFFY_FRAC ((1000000ULL << 32) / HZ & 0xffffffff)
-u64 jiffies_64;
+u64 jiffies_64 = INITIAL_JIFFIES;
/*
* forward reference
--- linux-2.5.61/arch/parisc/kernel/time.c Sat Feb 15 11:53:35 2003
+++ linux-2.5.61-jdbg/arch/parisc/kernel/time.c Sun Feb 16 01:42:26 2003
@@ -32,7 +32,7 @@
#include <linux/timex.h>
-u64 jiffies_64;
+u64 jiffies_64 = INITIAL_JIFFIES;
/* xtime and wall_jiffies keep wall-clock time */
extern unsigned long wall_jiffies;
--- linux-2.5.61/arch/ppc/kernel/time.c Sat Feb 15 11:53:35 2003
+++ linux-2.5.61-jdbg/arch/ppc/kernel/time.c Sun Feb 16 01:42:26 2003
@@ -68,7 +68,7 @@
#include <asm/time.h>
/* XXX false sharing with below? */
-u64 jiffies_64;
+u64 jiffies_64 = INITIAL_JIFFIES;
unsigned long disarm_decr[NR_CPUS];
--- linux-2.5.61/arch/ppc64/kernel/time.c Sat Feb 15 11:53:36 2003
+++ linux-2.5.61-jdbg/arch/ppc64/kernel/time.c Sun Feb 16 01:42:26 2003
@@ -65,7 +65,7 @@
void smp_local_timer_interrupt(struct pt_regs *);
-u64 jiffies_64;
+u64 jiffies_64 = INITIAL_JIFFIES;
/* keep track of when we need to update the rtc */
time_t last_rtc_update;
--- linux-2.5.61/arch/s390/kernel/time.c Sat Feb 15 11:53:36 2003
+++ linux-2.5.61-jdbg/arch/s390/kernel/time.c Sun Feb 16 01:42:26 2003
@@ -46,7 +46,7 @@
#define TICK_SIZE tick
-u64 jiffies_64;
+u64 jiffies_64 = INITIAL_JIFFIES;
static ext_int_info_t ext_int_info_timer;
static uint64_t xtime_cc;
--- linux-2.5.61/arch/s390x/kernel/time.c Sat Feb 15 11:53:36 2003
+++ linux-2.5.61-jdbg/arch/s390x/kernel/time.c Sun Feb 16 01:42:26 2003
@@ -45,7 +45,7 @@
#define TICK_SIZE tick
-u64 jiffies_64;
+u64 jiffies_64 = INITIAL_JIFFIES;
static ext_int_info_t ext_int_info_timer;
static uint64_t xtime_cc;
--- linux-2.5.61/arch/sh/kernel/time.c Sat Feb 15 11:53:36 2003
+++ linux-2.5.61-jdbg/arch/sh/kernel/time.c Sun Feb 16 01:42:26 2003
@@ -70,7 +70,7 @@
#endif /* CONFIG_CPU_SUBTYPE_ST40STB1 */
#endif /* __sh3__ or __SH4__ */
-u64 jiffies_64;
+u64 jiffies_64 = INITIAL_JIFFIES;
extern unsigned long wall_jiffies;
#define TICK_SIZE tick
--- linux-2.5.61/arch/sparc/kernel/time.c Sat Feb 15 11:53:36 2003
+++ linux-2.5.61-jdbg/arch/sparc/kernel/time.c Sun Feb 16 01:42:26 2003
@@ -45,7 +45,7 @@
extern unsigned long wall_jiffies;
-u64 jiffies_64;
+u64 jiffies_64 = INITIAL_JIFFIES;
enum sparc_clock_type sp_clock_typ;
spinlock_t mostek_lock = SPIN_LOCK_UNLOCKED;
--- linux-2.5.61/arch/sparc64/kernel/time.c Sat Feb 15 11:53:36 2003
+++ linux-2.5.61-jdbg/arch/sparc64/kernel/time.c Sun Feb 16 01:42:26 2003
@@ -47,7 +47,7 @@
extern unsigned long wall_jiffies;
-u64 jiffies_64;
+u64 jiffies_64 = INITIAL_JIFFIES;
static unsigned long mstk48t08_regs = 0UL;
static unsigned long mstk48t59_regs = 0UL;
--- linux-2.5.61/arch/v850/kernel/time.c Sat Feb 15 11:53:37 2003
+++ linux-2.5.61-jdbg/arch/v850/kernel/time.c Sun Feb 16 01:42:26 2003
@@ -25,7 +25,7 @@
#include "mach.h"
-u64 jiffies_64;
+u64 jiffies_64 = INITIAL_JIFFIES;
#define TICK_SIZE (tick_nsec / 1000)
--- linux-2.5.61/arch/x86_64/kernel/time.c Sat Feb 15 11:54:51 2003
+++ linux-2.5.61-jdbg/arch/x86_64/kernel/time.c Sun Feb 16 01:42:26 2003
@@ -30,7 +30,7 @@
#include <asm/apic.h>
#endif
-u64 jiffies_64;
+u64 jiffies_64 = INITIAL_JIFFIES;
extern int using_apic_timer;
Hi,
> +#define INITIAL_JIFFIES (0xffffffffUL & (unsigned long)(-300*HZ))
In order to make 64bit arches wrap too, you might want to use -1UL here.
Not that jiffies should wrap on a 64bit machine...
Anton
At some point in the past, someone else wrote:
>> +#define INITIAL_JIFFIES (0xffffffffUL & (unsigned long)(-300*HZ))
On Sun, Feb 16, 2003 at 01:08:08PM +1100, Anton Blanchard wrote:
> In order to make 64bit arches wrap too, you might want to use -1UL here.
> Not that jiffies should wrap on a 64bit machine...
Can I get a vote for ~0UL instead of -1UL?
-- wli
sure.
rdgs
Michael V
Sent: Sunday, February 16, 2003 3:43 AM
Subject: Re: [PATCH] make jiffies wrap 5 min after boot
> At some point in the past, someone else wrote:
> >> +#define INITIAL_JIFFIES (0xffffffffUL & (unsigned long)(-300*HZ))
>
> On Sun, Feb 16, 2003 at 01:08:08PM +1100, Anton Blanchard wrote:
> > In order to make 64bit arches wrap too, you might want to use -1UL here.
> > Not that jiffies should wrap on a 64bit machine...
>
> Can I get a vote for ~0UL instead of -1UL?
>
> -- wli
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Sat, 2003-02-15 at 21:43, William Lee Irwin III wrote:
> Can I get a vote for ~0UL instead of -1UL?
OK, I bite. What is the difference? Aren't both equivalent?
Robert Love
Anton Blanchard <[email protected]> writes:
> Hi,
>
> > +#define INITIAL_JIFFIES (0xffffffffUL & (unsigned long)(-300*HZ))
>
> In order to make 64bit arches wrap too, you might want to use -1UL here.
> Not that jiffies should wrap on a 64bit machine...
Seems somewhat pointless.
(2^64-1) / (1000 * 3600 * 24 * 365)
~584942417.35507203243911719939
I doubt any system ever will have an uptime of > 584 million years
(assuming HZ=1000) and if jiffies wrap will be the least of their
problems.
-Andi
> But the point of this patch is to catch jiffy wrap bugs in generic code as
> well as in platform-specific code.
>
> Doing it for 64-bit platforms as well will give us just that bit more testing
> coverage, and has no cost. (Well, 8 more bytes of kernel image...)
The 64bit platforms already have enough problems due to 64bit unclean
code. No need to add a new unnecessary ones.
Jiffie wrap is purely a 32bit problem, just like highmem. Please keep
problems where they belong.
-Andi
Andi Kleen <[email protected]> wrote:
>
> Anton Blanchard <[email protected]> writes:
>
> > Hi,
> >
> > > +#define INITIAL_JIFFIES (0xffffffffUL & (unsigned long)(-300*HZ))
> >
> > In order to make 64bit arches wrap too, you might want to use -1UL here.
> > Not that jiffies should wrap on a 64bit machine...
>
> Seems somewhat pointless.
>
> (2^64-1) / (1000 * 3600 * 24 * 365)
> ~584942417.35507203243911719939
>
> I doubt any system ever will have an uptime of > 584 million years
> (assuming HZ=1000) and if jiffies wrap will be the least of their
> problems.
>
But the point of this patch is to catch jiffy wrap bugs in generic code as
well as in platform-specific code.
Doing it for 64-bit platforms as well will give us just that bit more testing
coverage, and has no cost. (Well, 8 more bytes of kernel image...)
On Sun, Feb 16, 2003 at 01:37:40AM -0500, Robert Love wrote:
> On Sat, 2003-02-15 at 21:43, William Lee Irwin III wrote:
>
> > Can I get a vote for ~0UL instead of -1UL?
>
> OK, I bite. What is the difference? Aren't both equivalent?
I have no idea if that's what wli meant, but -1UL is only "all ones"
in a 2's complement binary representation.
--
Muli Ben-Yehuda
http://www.mulix.org
http://syscalltrack.sf.net
Anton Blanchard <[email protected]> writes:
> Hi,
>
> > +#define INITIAL_JIFFIES (0xffffffffUL & (unsigned long)(-300*HZ))
>
> In order to make 64bit arches wrap too, you might want to use -1UL here.
> Not that jiffies should wrap on a 64bit machine...
The whole point of the "0xffffffffUL &" is not to test 64 bit arches,
because I know Andi doesn't take jiffies wrap patches. And-ing with -1UL
is a no-op, as it is with ~0UL.
Tim
Muli Ben-Yehuda <[email protected]> writes:
> On Sun, Feb 16, 2003 at 01:37:40AM -0500, Robert Love wrote:
> > On Sat, 2003-02-15 at 21:43, William Lee Irwin III wrote:
> >
> > > Can I get a vote for ~0UL instead of -1UL?
> >
> > OK, I bite. What is the difference? Aren't both equivalent?
>
> I have no idea if that's what wli meant, but -1UL is only "all ones"
> in a 2's complement binary representation.
No. Wraparound of unsigned types is well-defined. -1UL must be the
largest possible unsigned long value, which must consist of only 1
bits (except for possible padding bits).
Of course, no machines with ones-complement (or padding bits, or
integer trap representations, or any of the other ISO braindamages)
exist, so this is mostly irrelevant anyway.
--
Falk
Muli Ben-Yehuda <[email protected]> writes:
>> I have no idea if that's what wli meant, but -1UL is only "all ones"
>> in a 2's complement binary representation.
On Sun, Feb 16, 2003 at 12:50:34PM +0100, Falk Hueffner wrote:
> No. Wraparound of unsigned types is well-defined. -1UL must be the
> largest possible unsigned long value, which must consist of only 1
> bits (except for possible padding bits).
> Of course, no machines with ones-complement (or padding bits, or
> integer trap representations, or any of the other ISO braindamages)
> exist, so this is mostly irrelevant anyway.
In the "obvious" sense, -1UL is an oxymoron, as -1 is inherently signed,
and the "UL" says "unsigned".
It's aesthetic. It's a violation of what I consider good taste to
do signed bit twiddling on an unsigned value and/or vice-versa.
Regardless of what ISO and/or Linux may or may not support, the habits
ingrained in me wrt. portability say the assumption must not be made.
YMMV.
-- wli
On Tue, 4 February 2003 14:04:38 +0100, Tim Schmielau wrote:
>
> A patch for 2.4.20-pre7 (and maybe later) is at
> http://www.physik3.uni-rostock.de/tim/kernel/2.4/
Some of the architectures appear to be untested. This fixes arm and
beautifies m68k.
( At least, I hope so. I didn't test it either :)
Tim, is the inline patch fine with you?
J?rn
--
There's nothing better for promoting creativity in a medium than
making an audience feel "Hmm ? I could do better than that!"
-- Douglas Adams in a slashdot interview
--- linux-2.4.20-pre7-j64/include/linux/timex.h Thu Nov 22 20:46:18 2001
+++ linux-2.4.20-pre7-j64-dbg/include/linux/timex.h Wed Sep 25 19:11:51 2002
@@ -53,6 +53,13 @@
#include <asm/param.h>
+#ifdef CONFIG_DEBUG_JIFFIESWRAP
+ /* Make the jiffies counter wrap around sooner. */
+# define INITIAL_JIFFIES ((unsigned long)(-300*HZ))
+#else
+# define INITIAL_JIFFIES 0
+#endif
+
/*
* The following defines establish the engineering parameters of the PLL
* model. The HZ variable establishes the timer interrupt frequency, 100 Hz
--- linux-2.4.20-pre7-j64/kernel/timer.c Wed Sep 25 18:38:36 2002
+++ linux-2.4.20-pre7-j64-dbg/kernel/timer.c Wed Sep 25 19:11:51 2002
@@ -65,9 +65,10 @@
extern int do_setitimer(int, struct itimerval *, struct itimerval *);
-unsigned long volatile jiffies;
+unsigned long volatile jiffies = INITIAL_JIFFIES;
#ifdef NEEDS_JIFFIES_64
-static unsigned int volatile jiffies_msb_flips;
+static unsigned int volatile
+ jiffies_msb_flips = INITIAL_JIFFIES>>(BITS_PER_LONG-1);
#endif
unsigned int * prof_buffer;
@@ -123,10 +124,21 @@
for (i = 0; i < TVR_SIZE; i++)
INIT_LIST_HEAD(tv1.vec + i);
+#ifdef CONFIG_DEBUG_JIFFIESWRAP
+ tv1.index = INITIAL_JIFFIES & TVR_MASK;
+ tv2.index = (INITIAL_JIFFIES >> TVR_BITS) & TVN_MASK;
+ tv3.index = (INITIAL_JIFFIES >> (TVR_BITS + TVN_BITS)) & TVN_MASK;
+ tv4.index = (INITIAL_JIFFIES >> (TVR_BITS + 2*TVN_BITS)) & TVN_MASK;
+ tv5.index = (INITIAL_JIFFIES >> (TVR_BITS + 3*TVN_BITS)) & TVN_MASK;
+
+ printk(KERN_NOTICE "Set up jiffies counter to wrap in %ld seconds.\n",
+ (-(long)jiffies)/HZ);
+#endif
+
init_jiffieswrap_timer();
}
-static unsigned long timer_jiffies;
+static unsigned long timer_jiffies = INITIAL_JIFFIES;
static inline void internal_add_timer(struct timer_list *timer)
{
@@ -668,7 +680,7 @@
}
/* jiffies at the most recent update of wall time */
-unsigned long wall_jiffies;
+unsigned long wall_jiffies = INITIAL_JIFFIES;
/*
* This spinlock protect us from races in SMP while playing with xtime. -arca
--- linux-2.4.20-pre7-j64/fs/proc/array.c Wed Sep 25 18:38:36 2002
+++ linux-2.4.20-pre7-j64-dbg/fs/proc/array.c Wed Sep 25 19:11:51 2002
@@ -369,7 +369,7 @@
nice,
0UL /* removed */,
task->it_real_value,
- (unsigned long long)(task->start_time),
+ (unsigned long long)(task->start_time) - INITIAL_JIFFIES,
vsize,
mm ? mm->rss : 0, /* you might want to shift this left 3 */
task->rlim[RLIMIT_RSS].rlim_cur,
--- linux-2.4.20-pre7-j64/fs/proc/proc_misc.c Wed Sep 25 18:53:38 2002
+++ linux-2.4.20-pre7-j64-dbg/fs/proc/proc_misc.c Wed Sep 25 19:11:51 2002
@@ -208,7 +208,7 @@
unsigned long uptime_remainder, idle_remainder;
int len;
- uptime = get_jiffies_64();
+ uptime = get_jiffies_64() - INITIAL_JIFFIES;
uptime_remainder = (unsigned long) do_div(uptime, HZ);
idle = get_sidle_64() + get_uidle_64();
idle_remainder = (unsigned long) do_div(idle, HZ);
@@ -386,7 +386,8 @@
int i, len = 0;
extern unsigned long total_forks;
unsigned int sum = 0;
- u64 jif = get_jiffies_64(), user = 0, nice = 0, system = 0;
+ u64 jif = get_jiffies_64() - INITIAL_JIFFIES;
+ u64 user = 0, nice = 0, system = 0;
int major, disk;
for (i = 0 ; i < smp_num_cpus; i++) {
--- linux-2.4.20-pre7-j64/kernel/info.c Wed Sep 25 18:38:36 2002
+++ linux-2.4.20-pre7-j64-dbg/kernel/info.c Wed Sep 25 19:11:51 2002
@@ -22,7 +22,7 @@
memset((char *)&val, 0, sizeof(struct sysinfo));
cli();
- uptime = get_jiffies_64();
+ uptime = get_jiffies_64() - INITIAL_JIFFIES;
do_div(uptime, HZ);
val.uptime = (unsigned long) uptime;
--- linux-2.4.20-pre7-j64/Documentation/Configure.help Wed Sep 25 18:33:43 2002
+++ linux-2.4.20-pre7-j64-dbg/Documentation/Configure.help Wed Sep 25 19:11:51 2002
@@ -25244,6 +25244,14 @@
of the BUG call as well as the EIP and oops trace. This aids
debugging but costs about 70-100K of memory.
+Debug jiffies counter wraparound (DANGEROUS)
+CONFIG_DEBUG_JIFFIESWRAP
+ Say Y here to initialize the jiffies counter to a value 5 minutes
+ before wraparound. This may make your system UNSTABLE and its
+ only use is to hunt down the causes of this instability.
+ If you don't know what the jiffies counter is or if you want
+ a stable system, say N.
+
Include kgdb kernel debugger
CONFIG_KGDB
Include in-kernel hooks for kgdb, the Linux kernel source level
--- linux-2.4.20-pre7-j64/arch/arm/config.in Wed Sep 25 18:33:43 2002
+++ linux-2.4.20-pre7-j64-dbg/arch/arm/config.in Wed Sep 25 19:11:51 2002
@@ -649,6 +649,7 @@
dep_bool ' Morse code panics' CONFIG_PANIC_MORSE $CONFIG_DEBUG_KERNEL $CONFIG_PC_KEYB
dep_bool ' Spinlock debugging' CONFIG_DEBUG_SPINLOCK $CONFIG_DEBUG_KERNEL
dep_bool ' Wait queue debugging' CONFIG_DEBUG_WAITQ $CONFIG_DEBUG_KERNEL
+dep_bool ' Debug jiffies counter wraparound (DANGEROUS)' CONFIG_DEBUG_JIFFIESWRAP $CONFIG_DEBUG_KERNEL
dep_bool ' Verbose BUG() reporting (adds 70K)' CONFIG_DEBUG_BUGVERBOSE $CONFIG_DEBUG_KERNEL
dep_bool ' Verbose kernel error messages' CONFIG_DEBUG_ERRORS $CONFIG_DEBUG_KERNEL
# These options are only for real kernel hackers who want to get their hands dirty.
--- linux-2.4.20-pre7-j64/arch/cris/config.in Wed Sep 25 18:33:43 2002
+++ linux-2.4.20-pre7-j64-dbg/arch/cris/config.in Wed Sep 25 19:11:51 2002
@@ -243,6 +243,7 @@
if [ "$CONFIG_SOUND" != "n" ]; then
source drivers/sound/Config.in
fi
+bool 'Debug jiffies counter wraparound (DANGEROUS)' CONFIG_DEBUG_JIFFIESWRAP
endmenu
source drivers/usb/Config.in
--- linux-2.4.20-pre7-j64/arch/i386/config.in Wed Sep 25 18:33:43 2002
+++ linux-2.4.20-pre7-j64-dbg/arch/i386/config.in Wed Sep 25 19:11:51 2002
@@ -451,6 +451,7 @@
bool ' Magic SysRq key' CONFIG_MAGIC_SYSRQ
bool ' Spinlock debugging' CONFIG_DEBUG_SPINLOCK
bool ' Compile the kernel with frame pointers' CONFIG_FRAME_POINTER
+ bool ' Debug jiffies counter wraparound (DANGEROUS)' CONFIG_DEBUG_JIFFIESWRAP
fi
endmenu
--- linux-2.4.20-pre7-j64/arch/m68k/config.in Wed Sep 25 18:33:43 2002
+++ linux-2.4.20-pre7-j64-dbg/arch/m68k/config.in Wed Sep 25 19:11:51 2002
@@ -552,6 +552,7 @@
if [ "$CONFIG_DEBUG_KERNEL" != "n" ]; then
bool ' Magic SysRq key' CONFIG_MAGIC_SYSRQ
bool ' Debug memory allocations' CONFIG_DEBUG_SLAB
+ bool ' Debug jiffies counter wraparound (DANGEROUS)' CONFIG_DEBUG_JIFFIESWRAP
bool ' Verbose BUG() reporting' CONFIG_DEBUG_BUGVERBOSE
fi
--- linux-2.4.20-pre7/arch/mips/config-shared.in Wed Sep 25 19:27:11 2002
+++ linux-2.4.20-pre7-j64/arch/mips/config-shared.in Wed Sep 25 19:15:30 2002
@@ -798,6 +798,7 @@
if [ "$CONFIG_SMP" != "y" ]; then
bool 'Run uncached' CONFIG_MIPS_UNCACHED
fi
+dep_bool 'Debug jiffies counter wraparound (DANGEROUS)' CONFIG_DEBUG_JIFFIESWRAP $CONFIG_MIPS32
endmenu
source lib/Config.in
--- linux-2.4.20-pre7-j64/arch/parisc/config.in Wed Sep 25 18:33:45 2002
+++ linux-2.4.20-pre7-j64-dbg/arch/parisc/config.in Wed Sep 25 19:11:51 2002
@@ -194,6 +194,7 @@
#bool 'Debug kmalloc/kfree' CONFIG_DEBUG_MALLOC
bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+bool 'Debug jiffies counter wraparound (DANGEROUS)' CONFIG_DEBUG_JIFFIESWRAP
endmenu
source lib/Config.in
--- linux-2.4.20-pre7-j64/arch/ppc/config.in Wed Sep 25 18:33:45 2002
+++ linux-2.4.20-pre7-j64-dbg/arch/ppc/config.in Wed Sep 25 19:17:13 2002
@@ -423,5 +423,6 @@
string ' Additional compile arguments' CONFIG_COMPILE_OPTIONS "-g -ggdb"
fi
fi
+ bool 'Debug jiffies counter wraparound (DANGEROUS)' CONFIG_DEBUG_JIFFIESWRAP
fi
endmenu
--- linux-2.4.20-pre7-j64/arch/sh/config.in Wed Sep 25 18:33:46 2002
+++ linux-2.4.20-pre7-j64-dbg/arch/sh/config.in Wed Sep 25 19:11:51 2002
@@ -385,6 +385,7 @@
if [ "$CONFIG_SH_STANDARD_BIOS" = "y" ]; then
bool 'Early printk support' CONFIG_SH_EARLY_PRINTK
fi
+bool 'Debug jiffies counter wraparound (DANGEROUS)' CONFIG_DEBUG_JIFFIESWRAP
endmenu
source lib/Config.in
--- linux-2.4.20-pre7-j64/arch/sparc/config.in Wed Sep 25 18:33:47 2002
+++ linux-2.4.20-pre7-j64-dbg/arch/sparc/config.in Wed Sep 25 19:11:51 2002
@@ -265,6 +265,7 @@
comment 'Kernel hacking'
bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+bool 'Debug jiffies counter wraparound (DANGEROUS)' CONFIG_DEBUG_JIFFIESWRAP
endmenu
source lib/Config.in
> > A patch for 2.4.20-pre7 (and maybe later) is at
> > http://www.physik3.uni-rostock.de/tim/kernel/2.4/
>
> Some of the architectures appear to be untested. This fixes arm and
> beautifies m68k.
> ( At least, I hope so. I didn't test it either :)
>
> Tim, is the inline patch fine with you?
looks good. Thanks,
Tim
(actually all arches except i386 and alpha were untestet...)
On Mon, Feb 17, 2003 at 02:55:05PM +0100, J?rn Engel wrote:
With:
> +#ifdef CONFIG_DEBUG_JIFFIESWRAP
> + /* Make the jiffies counter wrap around sooner. */
> +# define INITIAL_JIFFIES ((unsigned long)(-300*HZ))
> +#else
> +# define INITIAL_JIFFIES 0
> +#endif
This will store constants into jiffies_msb_flips:
("1" for DEBUG_JIFFIESWRAP, "0" otherwise.)
Wouldn't zero be what will always be needed ?
> -unsigned long volatile jiffies;
> +unsigned long volatile jiffies = INITIAL_JIFFIES;
> #ifdef NEEDS_JIFFIES_64
> -static unsigned int volatile jiffies_msb_flips;
> +static unsigned int volatile
> + jiffies_msb_flips = INITIAL_JIFFIES>>(BITS_PER_LONG-1);
> #endif
/Matti Aarnio
On Mon, 17 Feb 2003, Matti Aarnio wrote:
> This will store constants into jiffies_msb_flips:
> ("1" for DEBUG_JIFFIESWRAP, "0" otherwise.)
> Wouldn't zero be what will always be needed ?
No - this is exactly what is intended. Note that jiffies_msb_flips counts
flips of the MSB of jiffies, i.e., it's LSB should always be equal to the
MSB of jiffies.
We use it as a measure of whether jiffies_msb_flips is still up to date -
when the msb of jiffies flip, we have 2^31/HZ seconds to detect that
in the timer routine.
Tim