David Miller <[EMAIL PROTECTED]> writes:
>
> BTW, sparc64 always did the trick where the do_timer() work was done
> by one of the per-cpu local timer interrupts, I'm glad the idea gained
> traction generically. :-)))
It was already implemented before for x86-64, but disabled
by default because i
Thomas Gleixner <[EMAIL PROTECTED]> writes:
> >
> > Interrupt 0 is stuck at 114 (the number is consistent across reboots). I
> > don't experience any problem, time is running fine. Still it's strange
> > that the timer is doing nothing; maybe something other than the PIT is
> > used for time keepi
David,
On Fri, 2007-02-23 at 01:25 -0800, David Miller wrote:
> > Yes, all you need is to omit the CLOCK_EVT_FEAT_PERIODIC flag when you
> > register your device.
>
> Thanks a lot Thomas.
>
> I noticed while doing this work that the generic clock code is
> incompatible with the time interpolat
From: Thomas Gleixner <[EMAIL PROTECTED]>
Date: Thu, 22 Feb 2007 18:39:19 +0100
> On Thu, 2007-02-22 at 09:26 -0800, David Miller wrote:
> > BTW, I'm adding support for sparc64, and before I get much further
> > will the code handle a oneshot-only device? That's basically what I
> > have (sparc64
Arjan van de Ven wrote:
> if it's something built in the last year or two you have the hw.
>
>
I have an ICH4-M, and from Intel's datasheets it looks like I got the
short straw..
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer
On Thu, 2007-02-22 at 22:07 +0100, Pierre Ossman wrote:
> Arjan van de Ven wrote:
> > no; c3 saves a TON more power.
> >
> > you can try enabling HPET in your BIOS...
> >
> >
>
> Hah, I wish! This is a laptop, so the BIOS is as brain dead and broken
> as is humanly possible.
>
> Can I determi
Hi,
On Thu, Feb 22, 2007 at 10:07:19PM +0100, Pierre Ossman wrote:
> Arjan van de Ven wrote:
> > no; c3 saves a TON more power.
> >
> > you can try enabling HPET in your BIOS...
> >
> >
>
> Hah, I wish! This is a laptop, so the BIOS is as brain dead and broken
> as is humanly possible.
>
> C
Arjan van de Ven wrote:
> no; c3 saves a TON more power.
>
> you can try enabling HPET in your BIOS...
>
>
Hah, I wish! This is a laptop, so the BIOS is as brain dead and broken
as is humanly possible.
Can I determine if I have the required hardware? So I can tell if I'm
permanently screwed,
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of
>Thomas Gleixner
>Sent: Thursday, February 22, 2007 8:00 AM
>To: Pierre Ossman
>Cc: Arjan van de Ven; Jan Engelhardt; Luca Tettamanti;
>linux-kernel@vger.kernel.org
&g
On Thu, 2007-02-22 at 09:26 -0800, David Miller wrote:
> BTW, I'm adding support for sparc64, and before I get much further
> will the code handle a oneshot-only device? That's basically what I
> have (sparc64 basically has a TSC and a "comparison" register, you
> write the "comparison" register w
From: Thomas Gleixner <[EMAIL PROTECTED]>
Date: Thu, 22 Feb 2007 16:51:41 +0100
> PIT and local APIC timer are used to provide either periodic or one shot
> programmable timer events.
>
> Up to now the kernel started PIT and local APIC timer in parallel with
> the same period where PIT incremente
On Thu, 2007-02-22 at 17:27 +0100, Pierre Ossman wrote:
> Thomas Gleixner wrote:
> >
> > Here is the reason. The local APIC stops working in C3 state and we fall
> > back to the PIT in that case. Not really exciting for dynticks, but the
> > only way to keep the system alive. There is a patch comin
Thomas Gleixner wrote:
>
> Here is the reason. The local APIC stops working in C3 state and we fall
> back to the PIT in that case. Not really exciting for dynticks, but the
> only way to keep the system alive. There is a patch coming up from
> Intel, which finds out how to use HPET even if it is n
On Thu, 2007-02-22 at 16:13 +0100, Pierre Ossman wrote:
> > Sure. My dmesg is full of mmc debug crud right now, but I'll just reboot
> > and I'll have a clean one for you.
> >
>
> Here we go.
> [ 44.498253] ACPI: Lid Switch [C136]
> [ 44.577672] No dock devices found.
> [ 44.714156] ACPI:
On Thu, 2007-02-22 at 13:36 +0100, Jan Engelhardt wrote:
> >
> >Yes, we switch away from PIT and use the local APIC timer. (LOC)
>
> What's the benefit of doing so - and why has not it been done before?
> I mean, I run a regular 2.6.18.6,
> /sys/devices/system/clocksource/clocksource0/current_cloc
Arjan van de Ven wrote:
> On Thu, 2007-02-22 at 15:10 +0100, Pierre Ossman wrote:
>
>>
>> So with a local apic, and acpi_pm as clocksource, I shouldn't be getting
>> timer
>> interrupts?
>>
>
> timer interrupts as in "irq0"?
>
>
Yes:
0:9786349XT-PIC-XTtimer
> you s
On Thu, 2007-02-22 at 15:10 +0100, Pierre Ossman wrote:
> Arjan van de Ven wrote:
> >
> > some can be used for both (PIT), but on a concept level the uses are
> > independent. The advantage of local apic over PIT is that local apic is
> > cheap to do "one shot" future events with, while the PIT wi
Arjan van de Ven wrote:
>
> some can be used for both (PIT), but on a concept level the uses are
> independent. The advantage of local apic over PIT is that local apic is
> cheap to do "one shot" future events with, while the PIT will tick
> periodic at a fixed frequency. With tickless idle.. that
> What's the benefit of doing so - and why has not it been done before?
> I mean, I run a regular 2.6.18.6,
> /sys/devices/system/clocksource/clocksource0/current_clocksource (is this
> related?) shows "acpi_pm", but the IRQ0 counter increases at HZ. Maybe I
> am confusing things, but why the need
On Feb 22 2007 00:17, Thomas Gleixner wrote:
>On Thu, 2007-02-22 at 00:04 +0100, Luca Tettamanti wrote:
>>
>> Interrupt 0 is stuck at 114 (the number is consistent across reboots). I
>> don't experience any problem, time is running fine. Still it's strange
>> that the timer is doing nothing; mayb
On 2/22/07, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
On Thu, 2007-02-22 at 00:04 +0100, Luca Tettamanti wrote:
> Hi Thomas,
> I'm testing NO_HZ on my machines. On the laptop I see that the timer
> interrupt counter is incremented (though slower than HZ). This machine
> is running UP kernel.
>
>
On Thu, 2007-02-22 at 00:04 +0100, Luca Tettamanti wrote:
> Hi Thomas,
> I'm testing NO_HZ on my machines. On the laptop I see that the timer
> interrupt counter is incremented (though slower than HZ). This machine
> is running UP kernel.
>
> On my desktop I see this:
>
>CPU0 CP
22 matches
Mail list logo
