System hung when changing the time

Asterisk Asterisk Support
1

Hi All,

I’m setting up a test system with other Linux servers so we can run thru disaster recovery testing. While I was setting up I changed the time on the AsteriskNOW system, nothing amazing, I just typed date 08260859.30 and the system hung.

Checking the logs showed up the message below.

I changed run level to 1 and it did the same thing so I rebooted and used the s flag to boot single user and was able to change the time ok. The system is otherwise stable.

I’ve done a quick search and cannot find anything. I dont think it’s the hardware as the other Centos 5.3 systems I’m building are all fine.

Anyone else out there had the same issue? I’ve never had problems changing the time before!

The PC’s being used at the moment are all HP/Compaq DC7600 Towers.

Can anyone shed any light on this? Anyone willing to give it a try?

Aug 26 08:53:59 pbx kernel: Pid: 8523, comm:                 bash
Aug 26 08:53:59 pbx kernel: EIP: 0060:[<c0610550>] CPU: 0
Aug 26 08:53:59 pbx kernel: EIP is at _spin_unlock_irqrestore+0x8/0x9
Aug 26 08:53:59 pbx kernel:  EFLAGS: 00000202    Tainted: G       (2.6.18-128.4.1.el5 #1)
Aug 26 08:53:59 pbx kernel: EAX: f8ca7bf0 EBX: 00000002 ECX: 00000202 EDX: 00000200
Aug 26 08:53:59 pbx kernel: ESI: 00000001 EDI: f8cbde00 EBP: 00000000 DS: 007b ES: 007b
Aug 26 08:53:59 pbx kernel: CR0: 8005003b CR2: 09767904 CR3: 28980000 CR4: 000006d0
Aug 26 08:53:59 pbx kernel:  [<f8c9d8ed>] process_masterspan+0x4c6/0x4e3 [dahdi]
Aug 26 08:53:59 pbx kernel:  [<f8c9db95>] dahdi_receive+0x28b/0x295 [dahdi]
Aug 26 08:53:59 pbx kernel:  [<f8ca007b>] dahdi_ioctl+0x773/0x16ac [dahdi]
Aug 26 08:53:59 pbx kernel:  [<f8cef26b>] dahdi_dummy_timer+0x8b/0xcc [dahdi_dummy]
Aug 26 08:53:59 pbx kernel:  [<f8cef1e0>] dahdi_dummy_timer+0x0/0xcc [dahdi_dummy]
Aug 26 08:53:59 pbx kernel:  [<c042c179>] run_timer_softirq+0xfb/0x151
Aug 26 08:53:59 pbx kernel:  [<c0428c0f>] __do_softirq+0x87/0x114
Aug 26 08:53:59 pbx kernel:  [<c04073eb>] do_softirq+0x52/0x9c
Aug 26 08:53:59 pbx kernel:  [<c04059d7>] apic_timer_interrupt+0x1f/0x24
Aug 26 08:54:00 pbx kernel:  [<c0415d11>] flush_tlb_page+0x36/0x77
Aug 26 08:54:00 pbx kernel:  [<c04612fb>] do_wp_page+0x185/0x40a
Aug 26 08:54:00 pbx kernel:  [<c042c886>] recalc_sigpending+0xe/0x20
Aug 26 08:54:00 pbx kernel:  [<c0462988>] __handle_mm_fault+0x886/0x8e6
Aug 26 08:54:00 pbx kernel:  [<c042dcdc>] do_sigaction+0xb5/0x155
Aug 26 08:54:00 pbx kernel:  [<c061159c>] do_page_fault+0x22b/0x4d9
Aug 26 08:54:00 pbx kernel:  [<c0611371>] do_page_fault+0x0/0x4d9
Aug 26 08:54:00 pbx kernel:  [<c0405a89>] error_code+0x39/0x40
Aug 26 08:54:00 pbx kernel:  =======================
Aug 26 08:54:09 pbx kernel: BUG: soft lockup - CPU#0 stuck for 10s! [bash:8523]
2

This is the wrong forum for AsteriskNow.

However, dahdi dummy is the device driver that provides timing for Asterisk when there are no real dahdi devices, and it has been confused by the time step.

It is reasonable for it to complain in this case, but if it has then stopped working, there is a bug. You should check that it hasn’t been fixed in the latest version of dahdi, and, if not raise a bug report on issues.asterisk.org/

It is possible that people will argue that it is unreasonable to step the system time once a system has started. Certainly normal best practice is to set the time at bootup and then keep it in step with NTP. NTP can end up stepping, but the steps will be much less than 10s.

3

A couple of other points:

As RTP depends on accurate timestamps, stepping the clock is likely to cause some, temporary, disruption to any audio streams being timed by Asterisk.

Although NTP can step under adverse conditions, any such conditions should be addressed on a VoIP system, as you need smooth and accurate timing.