From: Nix <ni...@es...> - 2008-04-15 19:47:31
|
On 14 Apr 2008, Jeff Dike spake thusly: > Below is another patch for you to try. I spent most of last week > chasing this one. The symptoms are somewhat similar to yours - > intermittent UML hangs, although not with UML spinning, and it still > pings. Having not quite the same symptoms is interesting. I added instrumentation to spot huge offsets on the offchance that it was going negative... whereupon it ceased to hang for an entire week after a week of dying multiple times a day :/ > The problem is NTP adjusting the multiplier part of the clock-provided > cycles-to-ns conversion function. UML pretended to have a ns clock, > with a multiplier of 1. When NTP adjusted that down in order to slow > down the clock, that became 0, and time stopped. Oh, I didn't think that clock_interval might be *variable*. So much for my instrumentation hack then. :) ... hang on, wouldn't this only happen if you had NTP running on your guest? (I don't. For that matter, *why* would you have NTP running on your guest? The guest just gets the time of day from the host anyway!) (And why does the clocksource system allow NTP to reduce the clock interval so far that it becomes zero anyway? Shouldn't this be barred? What am I missing?) > The fix below is to switch to a usec clock, with a multiplier of 1000, > which can be adjusted with much more granualarity. OK, trying that. (I'll extend the instrumentation patch to watch for zero cycle_interval as well, and see what happens. With luck nothing will happen except that the crashes will stop... except that they already *have* stopped for me. Annoying.) -- `The rest is a tale of post and counter-post.' --- Ian Rawlings describes USENET |