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 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 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
22 matches
Mail list logo
