On Sunday 30 September 2007 16:06:59 Thomas Gleixner wrote:
> On Sun, 30 Sep 2007, Andi Kleen wrote:
>
> >>> OK, this explains 2) and 3). I just looked into the code and the logic
> >>> vs. noapictimer on SMP is completely broken.
> >
> > noapictimer really doesn't make any sense on non SMP imho
On Sun, 30 Sep 2007, Andi Kleen wrote:
OK, this explains 2) and 3). I just looked into the code and the logic
vs. noapictimer on SMP is completely broken.
noapictimer really doesn't make any sense on non SMP imho with the old
timer architecture. That is why I never bothered to implement it.
>
> PIT keeps jiffies (and the system) running, but the local APIC timer
> interrupts can get out of sync due to this C1E effect.
The way C1e works on AMD is that even when one core is woken up
by the PIT the APIC timer resumes on the other core on the socket too because
the deep power saving
>
> > OK, this explains 2) and 3). I just looked into the code and the logic
> > vs. noapictimer on SMP is completely broken.
noapictimer really doesn't make any sense on non SMP imho with the old
timer architecture. That is why I never bothered to implement it.
It's purely a UP hack.
> ..and
OK, this explains 2) and 3). I just looked into the code and the logic
vs. noapictimer on SMP is completely broken.
noapictimer really doesn't make any sense on non SMP imho with the old
timer architecture. That is why I never bothered to implement it.
It's purely a UP hack.
..and
PIT keeps jiffies (and the system) running, but the local APIC timer
interrupts can get out of sync due to this C1E effect.
The way C1e works on AMD is that even when one core is woken up
by the PIT the APIC timer resumes on the other core on the socket too because
the deep power saving
On Sun, 30 Sep 2007, Andi Kleen wrote:
OK, this explains 2) and 3). I just looked into the code and the logic
vs. noapictimer on SMP is completely broken.
noapictimer really doesn't make any sense on non SMP imho with the old
timer architecture. That is why I never bothered to implement it.
On Sunday 30 September 2007 16:06:59 Thomas Gleixner wrote:
On Sun, 30 Sep 2007, Andi Kleen wrote:
OK, this explains 2) and 3). I just looked into the code and the logic
vs. noapictimer on SMP is completely broken.
noapictimer really doesn't make any sense on non SMP imho with the old
On Fri, 2007-09-28 at 11:07 -0400, Chuck Ebbert wrote:
> On 09/26/2007 06:35 PM, Thomas Gleixner wrote:
> > It's even worse than I thought on the first check:
> >
> > "noapictimer" on the command line of an SMP box prevents _ONLY_ the boot
> > CPU apic timer from being used. But the secondary CPU
On 09/26/2007 06:35 PM, Thomas Gleixner wrote:
> It's even worse than I thought on the first check:
>
> "noapictimer" on the command line of an SMP box prevents _ONLY_ the boot
> CPU apic timer from being used. But the secondary CPU is still
> unconditionally setting up the APIC timer and uses
On 09/26/2007 06:35 PM, Thomas Gleixner wrote:
It's even worse than I thought on the first check:
noapictimer on the command line of an SMP box prevents _ONLY_ the boot
CPU apic timer from being used. But the secondary CPU is still
unconditionally setting up the APIC timer and uses the non
On Fri, 2007-09-28 at 11:07 -0400, Chuck Ebbert wrote:
On 09/26/2007 06:35 PM, Thomas Gleixner wrote:
It's even worse than I thought on the first check:
noapictimer on the command line of an SMP box prevents _ONLY_ the boot
CPU apic timer from being used. But the secondary CPU is still
On Thursday, 27 September 2007 01:21, Thomas Gleixner wrote:
> On Thu, 2007-09-27 at 01:30 +0200, Rafael J. Wysocki wrote:
> > > > Tested for a couple of times with each kernel, the results seem to be
> > > > reproducible 100% of the time.
> > >
> > > Thanks for going through this debug marathon.
On Thursday, 27 September 2007 01:21, Thomas Gleixner wrote:
On Thu, 2007-09-27 at 01:30 +0200, Rafael J. Wysocki wrote:
Tested for a couple of times with each kernel, the results seem to be
reproducible 100% of the time.
Thanks for going through this debug marathon.
No big
On 09/26/2007 06:35 PM, Thomas Gleixner wrote:
>
> It's even worse than I thought on the first check:
>
> "noapictimer" on the command line of an SMP box prevents _ONLY_ the boot
> CPU apic timer from being used. But the secondary CPU is still
> unconditionally setting up the APIC timer and uses
On Thu, 2007-09-27 at 01:30 +0200, Rafael J. Wysocki wrote:
> > > Tested for a couple of times with each kernel, the results seem to be
> > > reproducible 100% of the time.
> >
> > Thanks for going through this debug marathon.
>
> No big deal. I'm glad that you've found what's up.
>
> Well, we
Thomas,
On Wednesday, 26 September 2007 23:34, Thomas Gleixner wrote:
> Rafael,
>
> On Wed, 2007-09-26 at 23:00 +0200, Rafael J. Wysocki wrote:
> > > > > First, with the "x86-64: Disable local APIC timer use on AMD systems
> > > > > with C1E"
> > > > > patch and my collection of suspend patches
On Wed, 2007-09-26 at 15:22 -0700, Linus Torvalds wrote:
>
> On Wed, 26 Sep 2007, Thomas Gleixner wrote:
> > >
> > > 1) current Linus' tree doesn't boot with any command line (regression)
> > >
> > > [ Linus, please revert commit e66485d747505e9d960b864fc6c37f8b2afafaf0
>
> Reverted.
>
> >
On Wed, 26 Sep 2007, Thomas Gleixner wrote:
> >
> > 1) current Linus' tree doesn't boot with any command line (regression)
> >
> > [ Linus, please revert commit e66485d747505e9d960b864fc6c37f8b2afafaf0
Reverted.
> OK, this explains 2) and 3). I just looked into the code and the logic
> vs.
Rafael,
On Wed, 2007-09-26 at 23:00 +0200, Rafael J. Wysocki wrote:
> > > > First, with the "x86-64: Disable local APIC timer use on AMD systems
> > > > with C1E"
> > > > patch and my collection of suspend patches applied, the box doesn't boot
> > > > (the suspend patches don't even thouch the
On Wednesday, 26 September 2007 21:49, Rafael J. Wysocki wrote:
> On Wednesday, 26 September 2007 20:51, Thomas Gleixner wrote:
> > On Wed, 2007-09-26 at 17:25 +0200, Rafael J. Wysocki wrote:
> > > There still are some oddities.
> > >
> > > First, with the "x86-64: Disable local APIC timer use on
On Wednesday, 26 September 2007 21:49, Rafael J. Wysocki wrote:
On Wednesday, 26 September 2007 20:51, Thomas Gleixner wrote:
On Wed, 2007-09-26 at 17:25 +0200, Rafael J. Wysocki wrote:
There still are some oddities.
First, with the x86-64: Disable local APIC timer use on AMD systems
Rafael,
On Wed, 2007-09-26 at 23:00 +0200, Rafael J. Wysocki wrote:
First, with the x86-64: Disable local APIC timer use on AMD systems
with C1E
patch and my collection of suspend patches applied, the box doesn't boot
(the suspend patches don't even thouch the boot code, so they
On Wed, 26 Sep 2007, Thomas Gleixner wrote:
1) current Linus' tree doesn't boot with any command line (regression)
[ Linus, please revert commit e66485d747505e9d960b864fc6c37f8b2afafaf0
Reverted.
OK, this explains 2) and 3). I just looked into the code and the logic
vs.
On Wed, 2007-09-26 at 15:22 -0700, Linus Torvalds wrote:
On Wed, 26 Sep 2007, Thomas Gleixner wrote:
1) current Linus' tree doesn't boot with any command line (regression)
[ Linus, please revert commit e66485d747505e9d960b864fc6c37f8b2afafaf0
Reverted.
OK, this explains 2)
Thomas,
On Wednesday, 26 September 2007 23:34, Thomas Gleixner wrote:
Rafael,
On Wed, 2007-09-26 at 23:00 +0200, Rafael J. Wysocki wrote:
First, with the x86-64: Disable local APIC timer use on AMD systems
with C1E
patch and my collection of suspend patches applied, the box
On Thu, 2007-09-27 at 01:30 +0200, Rafael J. Wysocki wrote:
Tested for a couple of times with each kernel, the results seem to be
reproducible 100% of the time.
Thanks for going through this debug marathon.
No big deal. I'm glad that you've found what's up.
Well, we still have
On 09/26/2007 06:35 PM, Thomas Gleixner wrote:
It's even worse than I thought on the first check:
noapictimer on the command line of an SMP box prevents _ONLY_ the boot
CPU apic timer from being used. But the secondary CPU is still
unconditionally setting up the APIC timer and uses the non
28 matches
Mail list logo
