System freeze with "Clocksource tsc unstable" reported *after* freeze

[Ian Macintosh]

Jul 16 09:36:23 pvmh01 kernel: [1266749.547022] Clocksource tsc unstable (delta = 515402906059 ns)

The system froze up for the indicated 8.59 minutes as accurately as I can tell.

I've done some research on this through other bug reports but find a seemingly opposite issue to those with 'tsc unstable' who report that the message occurs before the system freezes up. But that might be an incorrect observation on their part?

A more completely relevant /var/log/messages extract:

Jul 16 08:55:56 pvmh01 -- MARK --
Jul 16 09:15:56 pvmh01 -- MARK --
Jul 16 09:35:56 pvmh01 -- MARK --
Jul 16 09:36:23 pvmh01 kernel: [1266749.547022] Clocksource tsc unstable (delta = 515402906059 ns)
Jul 16 09:55:56 pvmh01 -- MARK --
Jul 16 10:15:56 pvmh01 -- MARK --
Jul 16 10:35:56 pvmh01 -- MARK --

I need to elaborate on the freeze as it wasn't a complete freeze. I logged in via SSH on a session about 6 minutes into the freeze, but couldn't open a second session. The second and subsequent SSH connection attempts hung for another 2 1/2 minutes when suddenly everything unfroze and the other 5 sessions I was trying to establish connected.

In previous instances where this and other servers had frozen (all running Ubuntu 8.04.4) I had often succeeded in logging on once, but it seemed that any attempt to execute a command that resulted in disk access would freeze and leave the SSH session locked and unusable, not even able to background the stalled task. Where I had been fortunate enough to get more than one SSH session logged in, even killing the PID with -TERM wouldn't unfreeze the other terminal.

This is however the first time I have suddenly had the server unfreeze on me and everything returned to normal with the only blip on the radar being the 'tsc unstable' report.

This is not caused by dirty_background_ratio hitting ceiling and freezing the system while it writes hundreds of thousands of blocks to the disk. /proc/vmstat nr_dirty and nr_writeback were normal. I've double-crossed that bridge before.

I'm very suspicious that it has _something_ to do with the software disk subsystem, but I could be cherry picking because I don't trust the new 'improved' cache system that replaced the simple old Linus elevator.

[penalvch (penalvch)]

Ian Macintosh, thank you for reporting this and helping make Ubuntu better. This bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? Can you try with the latest development release of Ubuntu? ISO CD images are available from http://cdimage.ubuntu.com/releases/ .

If it remains an issue, could you run the following command from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p linux <replace-with-bug-number>

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

[Ian Macintosh (ian-macintosh)]

The affected servers were migrated to an alternative due to these issues. As 8.04.4 is now retired, I think it has become irrelevant.

In summary, I am no longer in a position to perform upstream testing.

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]