With current git head (v2.6.27-rc5-319-g7686ad5) I'm seeing repeated occurrences of the following on my HP Compaq 2510p laptop. Not seen with earlier kernels, including 2.6.27-rc5. CE: __tick_program_event of hpet is stuck 1468f1b3c9 1468f1c751 CE: increasing min_delta_ns 5000 to 10000 nsec ------------[ cut here ]------------ WARNING: at kernel/time/tick-oneshot.c:52 tick_dev_program_event+0x9c/0xd0 () Modules linked in: tcp_diag inet_diag i915 drm ipv6 ext2 coretemp acpi_cpufreq loop joydev snd_hda_intel snd_pcm_oss arc4 snd_pcm ecb snd_mixer_oss snd_seq_dummy snd_seq_oss iwlagn snd_seq_midi iwlcore snd_rawmidi snd_seq_midi_event snd_seq pcmcia rfkill snd_timer snd_seq_device led_class mac80211 snd wmi video yenta_socket rsrc_nonstatic cfg80211 intel_agp soundcore ac psmouse serio_raw output container iTCO_wdt pcspkr pcmcia_core evdev battery button snd_page_alloc ext3 jbd mbcache sha256_generic aes_x86_64 aes_generic cbc dm_crypt crypto_blkcipher dm_mirror dm_log dm_snapshot dm_mod sg sr_mod cdrom sd_mod piix ide_pci_generic ide_core ata_piix ohci1394 sdhci_pci sdhci ricoh_mmc mmc_core ieee1394 ata_generic ehci_hcd libata scsi_mod uhci_hcd dock e1000e thermal processor fan thermal_sys Pid: 0, comm: swapper Not tainted 2.6.27-rc5 #74 Call Trace: [<ffffffff802375d2>] warn_on_slowpath+0x58/0x7f [<ffffffff80434a10>] ? printk+0x67/0x6f [<ffffffff8024f2e7>] ? getnstimeofday+0x3a/0x96 [<ffffffff8024f2e7>] ? getnstimeofday+0x3a/0x96 [<ffffffff8024d35f>] ? ktime_get_ts+0x49/0x4e [<ffffffff80252c9f>] tick_dev_program_event+0x9c/0xd0 [<ffffffff80252756>] tick_broadcast_oneshot_control+0xa3/0xfd [<ffffffff80251fe7>] tick_notify+0x22f/0x385 [<ffffffff8024dc5b>] notifier_call_chain+0x33/0x5b [<ffffffff8024dd17>] raw_notifier_call_chain+0xf/0x11 [<ffffffff80251a62>] clockevents_notify+0x2b/0x7a [<ffffffffa000a00a>] acpi_state_timer_broadcast+0x41/0x43 [processor] [<ffffffffa000a6cd>] acpi_idle_enter_simple+0x8c/0x172 [processor] [<ffffffff803b5036>] ...
I meant repeated as in "after different boots", but I now also see repeats when I leave the system on for some time. It keeps increasing the min_delta_ns to ever higher values. CE: __tick_program_event of hpet is stuck 1468f1b3c9 1468f1c751 CE: increasing min_delta_ns 5000 to 10000 nsec [...] CE: __tick_program_event of hpet is stuck 33576032f74 33576035684 CE: increasing min_delta_ns 10000 to 20000 nsec [...] CE: __tick_program_event of hpet is stuck 63242b30d28 63242b35b48 CE: increasing min_delta_ns 20000 to 40000 nsec The call trace is basically the same each time. --
Exactly the same problem here. This is a Lenovo Thinkpad R61 with current git head (7686ad56). Cheers, Stefan Hellermann --
Can you both please provide the full dmesg output and the out put from lspci -vvv please ? Thanks, tglx --
The same thing is happening on my MacBookPro 3.2 (with nVidia binary driver sorry). Cheers. -- Guillaume
Frans, what's the highest value which you have seen ? Thanks, tglx --
These are the highest I've seen, but that's possibly because I haven't left the system running for longer. There's just under an hour between the messages (kern.log has 00:59:17, 01:56:38, 02:51:23 for the three increases listed above) with the first fairly shortly after boot. I've just awakened the laptop from suspend and will let it sit for the rest of the day. If I get any higher values I'll let you know. --
It's nothing to worry about. I out the WARN_ON() there to get some information about the validation of min_delta_ns and to see in which range this happens. I'm going to remove the WARN_ON() and just keep the information that we need to increase the min_delta_ns value for safe operation. Thanks, tglx --
Ah, OK. A WARN_ON is perhaps a bit heavy for that, unless you actually want to be flooded with reports :-) In my case it prevented me from running the kernel on other boxes than the laptop because I feared some possibly important issue. Also, a single line can easily be filtered out from logcheck reports while Sounds like a plan; have already done so locally. Here are some results I've got so far. You can see reboots and supend to RAMs. Maximum observed value on the HP 2510p is now 80000 with the system mostly idle or in light use. Sep 8 00:58:29 aragorn kernel: Linux version 2.6.27-rc5 (root@faramir) ... Sep 8 00:59:17 aragorn kernel: CE: increasing min_delta_ns 5000 to 10000 nsec Sep 8 01:56:38 aragorn kernel: CE: increasing min_delta_ns 10000 to 20000 nsec Sep 8 02:51:23 aragorn kernel: CE: increasing min_delta_ns 20000 to 40000 nsec Sep 8 05:11:10 aragorn kernel: Back to C! Sep 9 00:04:16 aragorn kernel: Linux version 2.6.27-rc5 (root@faramir) ... Sep 9 00:09:04 aragorn kernel: CE: increasing min_delta_ns 5000 to 10000 nsec Sep 9 14:31:49 aragorn kernel: Back to C! Sep 9 14:39:41 aragorn kernel: CE: increasing min_delta_ns 10000 to 20000 nsec Sep 9 14:39:51 aragorn kernel: CE: increasing min_delta_ns 20000 to 40000 nsec Sep 9 16:59:22 aragorn kernel: Linux version 2.6.27-rc5 (root@faramir) ... Sep 9 16:59:22 aragorn kernel: CE: increasing min_delta_ns 5000 to 10000 nsec Sep 9 17:02:18 aragorn kernel: Linux version 2.6.27-rc5 (root@faramir) ... Sep 9 17:15:10 aragorn kernel: CE: increasing min_delta_ns 5000 to 10000 nsec Sep 9 17:38:34 aragorn kernel: CE: increasing min_delta_ns 10000 to 20000 nsec Sep 9 17:57:21 aragorn kernel: CE: increasing min_delta_ns 20000 to 40000 nsec Sep 9 18:57:26 aragorn kernel: Back to C! Sep 9 19:06:25 aragorn kernel: Back to C! Sep 9 19:20:19 aragorn kernel: CE: increasing min_delta_ns 40000 to 80000 nsec I also tried getting these on my desktop by switching the clocksource from tsc to hpet, but that did not ...
Yes, I wanted that. Some new debug outputs are usually I have not a single machine where this shows up, but I really wanted to get some data. It worked :) Thanks, tglx --
