Re: Clock running at half speed in 2.6.20?
On Fri, 16 Feb 2007 08:24:54 -0800, Daniel Walker wrote: >On Fri, 2007-02-16 at 22:28 +0800, Adam J. Richter wrote: >> My system clock runs at approximately half speed in >> linux-2.6.20, 2.6.20-git10 and 2.6.20-git11. [...] >cat /sys/devices/system/clocksource/clocksource0/current_clocksource tsc >cat /sys/devices/system/clocksource/clocksource0/available_clocksource acpi_pm jiffies tsc When I rebooted with "max_cpus=1", available_clocksource included a fourth option "pit". I have some bad news. The problem is sporadic. Here are the logs of the tests that I have made, in the order in which I recall making them: 2.6.20-git11problem occurred 2.6.20-git10problem occurred 2.6.20 problem occurred 2.6.18.1no problem [At this point, I made my original posting.] 2.6.20-git11 maxcpus=1 no problem ...checked current_clocksource, was tsc 2.6.18.1no problem ...checked current_clocksource, was tsc 2.6.20-git11no problem (this is bad!) checked current_clocksource, was tsc set clocksource=acpi_pm, still no problem set clocksource=jiffies, still no problem power cycled computer, unplugging power supply and powered down monitor 2.6.20-git11no problem (this is bad!) checked current_clocksource, was tsc At first, I was very happy to see the problem disappear after rebooting 2.6.20-git11 with "max_cpus=1", as this would tend to indicate some mistake related to hyperthreading, but, after that I have been unable to reproduce the problem, so I really don't know that booting with maxcpus=1 fixed it. Perhaps the previous boot to 2.6.18.1 did. I should also mention, that around the time that I first noticed the problem, I observed audio stuttering under 2.6.20-git11 regularly, in intervals of perhaps 300 milliseconds, which I suspect is a symptom of the slow system clock causing the audio driver not to fill output buffers in time. Now, when I cannot reproduce the clock slowdown problem, audio is playing fine under the same 2.6.20-git11 kernel. I have observed the audio stuttering a few times in the past week or so. The next time it happens, I'll see if the clock slowdown has returned and I'll record and experiment with the other clock sources. I'll let you know when I have more useful information or mske other progress related to this problem. Thank you for your help! Adam Richter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Clock running at half speed in 2.6.20?
On Fri, 2007-02-16 at 22:28 +0800, Adam J. Richter wrote: > My system clock runs at approximately half speed in > linux-2.6.20, 2.6.20-git10 and 2.6.20-git11. That is, it takes about > two hours for "date" to report that one hour has elapsed. "hwclock" > returns the correct time, of course. > > I do not have this problem in linuux 2.6.18.1. I will try to > narrow down the kernel version where this problem began. > > The motherboard in question is an asus p4v8000-x, running a > 2.8GHz Pentium 4 that has two hyperthreads, which I suspect may be the > problem. I am just guessing, but perhaps some piece of code thinks > the two hyperthreads are separate CPU's receving twice as many clock > interrupts total. I expect to try to some experimentation to check > this theory. > > For what it's worth, I am running CONFIG_PREEMPT=y, > CONFIG_PREEMPT_BKL=y, CONFIG_HZ=1000. if you run, cat /sys/devices/system/clocksource/clocksource0/current_clocksource it will tell you which hardware clock is being used by the kernel. You can also run, cat /sys/devices/system/clocksource/clocksource0/available_clocksource which will tell you which clocks are available on your system. You switch clocks by echoing the name of a clock into "current_clocksource" As an example, the following switches to the acpi_pm clocksource, echo "acpi_pm"> /sys/devices/system/clocksource/clocksource0/current_clocksource The hardware clock that your using could be running to slow. I would recommend switching the hardware clock and re-check if the time is still half speed. Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Clock running at half speed in 2.6.20?
My system clock runs at approximately half speed in linux-2.6.20, 2.6.20-git10 and 2.6.20-git11. That is, it takes about two hours for "date" to report that one hour has elapsed. "hwclock" returns the correct time, of course. I do not have this problem in linuux 2.6.18.1. I will try to narrow down the kernel version where this problem began. The motherboard in question is an asus p4v8000-x, running a 2.8GHz Pentium 4 that has two hyperthreads, which I suspect may be the problem. I am just guessing, but perhaps some piece of code thinks the two hyperthreads are separate CPU's receving twice as many clock interrupts total. I expect to try to some experimentation to check this theory. For what it's worth, I am running CONFIG_PREEMPT=y, CONFIG_PREEMPT_BKL=y, CONFIG_HZ=1000. If there is a more specific mailing list for discussing this problem, I would be interested in knowning about it. The MAINTAINERS file lists several components with the word "clock" in them, but I believe that all are for drivers for hardware clocks or high resolution timer extensions. I tried a quick search of the linux-kernel mailing list for "clock" in the subject line, and did not notice anything that seemed like a match to this problem. I will post more information as I collect it, but I am posting this bug report now in case this problem rings a bell for anyone. Adam Richter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Clock running at half speed in 2.6.20?
My system clock runs at approximately half speed in linux-2.6.20, 2.6.20-git10 and 2.6.20-git11. That is, it takes about two hours for date to report that one hour has elapsed. hwclock returns the correct time, of course. I do not have this problem in linuux 2.6.18.1. I will try to narrow down the kernel version where this problem began. The motherboard in question is an asus p4v8000-x, running a 2.8GHz Pentium 4 that has two hyperthreads, which I suspect may be the problem. I am just guessing, but perhaps some piece of code thinks the two hyperthreads are separate CPU's receving twice as many clock interrupts total. I expect to try to some experimentation to check this theory. For what it's worth, I am running CONFIG_PREEMPT=y, CONFIG_PREEMPT_BKL=y, CONFIG_HZ=1000. If there is a more specific mailing list for discussing this problem, I would be interested in knowning about it. The MAINTAINERS file lists several components with the word clock in them, but I believe that all are for drivers for hardware clocks or high resolution timer extensions. I tried a quick search of the linux-kernel mailing list for clock in the subject line, and did not notice anything that seemed like a match to this problem. I will post more information as I collect it, but I am posting this bug report now in case this problem rings a bell for anyone. Adam Richter - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Clock running at half speed in 2.6.20?
On Fri, 2007-02-16 at 22:28 +0800, Adam J. Richter wrote: My system clock runs at approximately half speed in linux-2.6.20, 2.6.20-git10 and 2.6.20-git11. That is, it takes about two hours for date to report that one hour has elapsed. hwclock returns the correct time, of course. I do not have this problem in linuux 2.6.18.1. I will try to narrow down the kernel version where this problem began. The motherboard in question is an asus p4v8000-x, running a 2.8GHz Pentium 4 that has two hyperthreads, which I suspect may be the problem. I am just guessing, but perhaps some piece of code thinks the two hyperthreads are separate CPU's receving twice as many clock interrupts total. I expect to try to some experimentation to check this theory. For what it's worth, I am running CONFIG_PREEMPT=y, CONFIG_PREEMPT_BKL=y, CONFIG_HZ=1000. if you run, cat /sys/devices/system/clocksource/clocksource0/current_clocksource it will tell you which hardware clock is being used by the kernel. You can also run, cat /sys/devices/system/clocksource/clocksource0/available_clocksource which will tell you which clocks are available on your system. You switch clocks by echoing the name of a clock into current_clocksource As an example, the following switches to the acpi_pm clocksource, echo acpi_pm /sys/devices/system/clocksource/clocksource0/current_clocksource The hardware clock that your using could be running to slow. I would recommend switching the hardware clock and re-check if the time is still half speed. Daniel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Clock running at half speed in 2.6.20?
On Fri, 16 Feb 2007 08:24:54 -0800, Daniel Walker wrote: On Fri, 2007-02-16 at 22:28 +0800, Adam J. Richter wrote: My system clock runs at approximately half speed in linux-2.6.20, 2.6.20-git10 and 2.6.20-git11. [...] cat /sys/devices/system/clocksource/clocksource0/current_clocksource tsc cat /sys/devices/system/clocksource/clocksource0/available_clocksource acpi_pm jiffies tsc When I rebooted with max_cpus=1, available_clocksource included a fourth option pit. I have some bad news. The problem is sporadic. Here are the logs of the tests that I have made, in the order in which I recall making them: 2.6.20-git11problem occurred 2.6.20-git10problem occurred 2.6.20 problem occurred 2.6.18.1no problem [At this point, I made my original posting.] 2.6.20-git11 maxcpus=1 no problem ...checked current_clocksource, was tsc 2.6.18.1no problem ...checked current_clocksource, was tsc 2.6.20-git11no problem (this is bad!) checked current_clocksource, was tsc set clocksource=acpi_pm, still no problem set clocksource=jiffies, still no problem power cycled computer, unplugging power supply and powered down monitor 2.6.20-git11no problem (this is bad!) checked current_clocksource, was tsc At first, I was very happy to see the problem disappear after rebooting 2.6.20-git11 with max_cpus=1, as this would tend to indicate some mistake related to hyperthreading, but, after that I have been unable to reproduce the problem, so I really don't know that booting with maxcpus=1 fixed it. Perhaps the previous boot to 2.6.18.1 did. I should also mention, that around the time that I first noticed the problem, I observed audio stuttering under 2.6.20-git11 regularly, in intervals of perhaps 300 milliseconds, which I suspect is a symptom of the slow system clock causing the audio driver not to fill output buffers in time. Now, when I cannot reproduce the clock slowdown problem, audio is playing fine under the same 2.6.20-git11 kernel. I have observed the audio stuttering a few times in the past week or so. The next time it happens, I'll see if the clock slowdown has returned and I'll record and experiment with the other clock sources. I'll let you know when I have more useful information or mske other progress related to this problem. Thank you for your help! Adam Richter - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
