I thought the following bug might be caused by PIT:
ifconfig eth1 showed UP and RUNNING even though traffic did not work.
The following lines in dmesg look suspicious:
[ 83.017954] Clocksource tsc unstable (delta = 111864067 ns)
[ 83.018930] Time: pit clocksource has been installed.
I thought the following bug might be caused by PIT:
ifconfig eth1 showed UP and RUNNING even though traffic did not work.
The following lines in dmesg look suspicious:
[ 83.017954] Clocksource tsc unstable (delta = 111864067 ns)
[ 83.018930] Time: pit clocksource has been installed.
>I also didn't do a whole lot of digging to see what the problems this
>bug can cause in practice, but after the PIT clocksource was installed,
>I tried 'sleep 1' and this did not wake up.
i`m using clock=pit on many of our virtual servers for accurate time
syncronization. (as recommended by
I also didn't do a whole lot of digging to see what the problems this
bug can cause in practice, but after the PIT clocksource was installed,
I tried 'sleep 1' and this did not wake up.
i`m using clock=pit on many of our virtual servers for accurate time
syncronization. (as recommended by
On 01/04/2008 12:18 PM, john stultz wrote:
On Thu, 2008-01-03 at 15:52 -0800, Dan Hecht wrote:
Looking at pit_read() in arch/x86/kernel/i8253.c, it seems that the PIT
clocksource code assumes that the PIT CH0 is in periodic mode. With
clockevents, this assumption is no longer valid. There
On Thu, 2008-01-03 at 15:52 -0800, Dan Hecht wrote:
> Looking at pit_read() in arch/x86/kernel/i8253.c, it seems that the PIT
> clocksource code assumes that the PIT CH0 is in periodic mode. With
> clockevents, this assumption is no longer valid. There are at least two
> places that make
On Thu, 3 Jan 2008, Dan Hecht wrote:
> Seems these problems can happen when the PIT is used as the clocksource or
> even just the clocksource watchdog. It looks like there is some code in
> clocksource.c that checks for CLOCK_SOURCE_IS_CONTINUOUS, which is not set for
> the PIT clocksource, but
On Thu, 3 Jan 2008, Dan Hecht wrote:
Seems these problems can happen when the PIT is used as the clocksource or
even just the clocksource watchdog. It looks like there is some code in
clocksource.c that checks for CLOCK_SOURCE_IS_CONTINUOUS, which is not set for
the PIT clocksource, but it
On Thu, 2008-01-03 at 15:52 -0800, Dan Hecht wrote:
Looking at pit_read() in arch/x86/kernel/i8253.c, it seems that the PIT
clocksource code assumes that the PIT CH0 is in periodic mode. With
clockevents, this assumption is no longer valid. There are at least two
places that make this
On 01/04/2008 12:18 PM, john stultz wrote:
On Thu, 2008-01-03 at 15:52 -0800, Dan Hecht wrote:
Looking at pit_read() in arch/x86/kernel/i8253.c, it seems that the PIT
clocksource code assumes that the PIT CH0 is in periodic mode. With
clockevents, this assumption is no longer valid. There
Looking at pit_read() in arch/x86/kernel/i8253.c, it seems that the PIT
clocksource code assumes that the PIT CH0 is in periodic mode. With
clockevents, this assumption is no longer valid. There are at least two
places that make this assumption:
1) The calculation at the end of pit_read()
Looking at pit_read() in arch/x86/kernel/i8253.c, it seems that the PIT
clocksource code assumes that the PIT CH0 is in periodic mode. With
clockevents, this assumption is no longer valid. There are at least two
places that make this assumption:
1) The calculation at the end of pit_read()
12 matches
Mail list logo
