Large backwards time steps panic 2.5.73
I've got one of those fun machines with a failing bios batter that always boots up with the BIOS clock about a year into the future.
2.5.73 always panics around the time ntpdate sets the clock back to its normal value with:
kernel BUG at kernel/timer.c:377!
Kernel addresses on the stack:
[<10129510>] .L1641+0x0/0x38 [<10105be4>] dump_stack+0x18/0x24 [<101309fc>] .L996+0x0/0x58 [<10147e7c>] .L1188+0x18/0x48 [<10131130>] run_timer_softirq+0x15c/0x1b8 [<10131210>] do_timer+0x68/0x118 [<1012ccec>] __crc_scsi_put_command+0x8d/0xe9 [<101738cc>] locate_fd+0xd0/0x15c [<1010737c>] do_cpu_irq_mask+0x90/0xf0 [<10334f24>] start_kernel+0x4/0x1fc [<1010a068>] intr_return+0x0/0x14 [<10161a7c>] get_empty_filp+0x64/0xfc [<101107a8>] .L894+0x14/0x18 [<10161a7c>] get_empty_filp+0x64/0xfc [<10160044>] .L1853+0x94/0xcc [<101738cc>] locate_fd+0xd0/0x15c [<10334f24>] start_kernel+0x4/0x1fc [<1011077c>] .L892+0x0/0x18 [<103350dc>] start_kernel+0x1bc/0x1fc
Reverting the patch
ChangeSet 1.1348.6.16 2003/06/20 22:13:39 [email protected]
[PATCH] revert adjtimex changes
From: John Stultz, George Anzinger, Eric Piel
Fixes the problem for me.
The above trace is from a HP PA-RISC machine running 2.5.73-pa1.
James
Quoted 8 lines · James Bottomley
I've got one of those fun machines with a failing bios batter that always boots up with the BIOS clock about a year into the future.
2.5.73 always panics around the time ntpdate sets the clock back to its normal value with:
kernel BUG at
kernel/timer.c:377!
Kernel addresses on the stack:
[snip]
Quoted 10 lines
Reverting the patch
ChangeSet 1.1348.6.16 2003/06/20 22:13:39 [email protected]
[PATCH] revert adjtimex changesFrom: John Stultz, George Anzinger, Eric Piel
Fixes the problem for me.
The above trace is from a HP PA-RISC machine running 2.5.73-pa1.
Hmm. Odd. What is the HZ frequency on this machine?
thanks
-john
Quoted 4 lines · john stultz
Quoted 1 line · James Bottomley
The above trace is from a HP PA-RISC machine running 2.5.73-pa1.
Hmm. Odd. What is the HZ frequency on this machine?
On the kernel with the panic, 100. If I build a 64 bit kernel (which I haven't done for .73 yet) I'll get 1000
James
Quoted 8 lines · James Bottomley
Quoted 4 lines · john stultz
Quoted 1 line · James Bottomley
The above trace is from a HP PA-RISC machine running 2.5.73-pa1.
Hmm. Odd. What is the HZ frequency on this machine?
On the kernel with the panic, 100. If I build a 64 bit kernel (which I haven't done for .73 yet) I'll get 1000
Ok I'd be curious if it occurs there as well
The only bits the patch should touch are used in adjtimex, and adjtimex is very limited on how much it can adjust time. If you're a year off or whatever, its more likely ntpdate is calling stime/settimeofday.
Could you boot w/o ntp starting up, then manually run "ntpdate -b <server>" to see if that causes it as well?
thanks
-john
Quoted 6 lines · john stultz
The only bits the patch should touch are used in adjtimex, and adjtimex is very limited on how much it can adjust time. If you're a year off or whatever, its more likely ntpdate is calling stime/settimeofday.
Could you boot w/o ntp starting up, then manually run "ntpdate -b <server>" to see if that causes it as well?
I can't seem to reproduce this with any sort of regularity. The only data points I have are
- It doesn't occur when the adjtimex reversion is backed out
- It seems to occur shortly after the machine is rebooted with the clock set to the future.
- it reproduces much more readily if ntpd is running
I've stuck some debugging code in there and find that the ->base for the timer is NULL and the timer function is igmp_ifc_timer_expire.
I'll continue looking at this.
James