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 w
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.
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 t
>
> > 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
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 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.
>
> > OK
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. n
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 bo
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 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 with
> > C1E"
> > patch and my collection of suspend patches
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 with C1E"
> patch and my collection of suspend patches applied, the box doesn't boot
> (the suspend patches don't even thouch the bo
Thomas,
On Tuesday, 25 September 2007 23:24, Thomas Gleixner wrote:
> Rafael,
>
> On Tue, 2007-09-25 at 23:28 +0200, Rafael J. Wysocki wrote:
> > > I'm a bit confused by your earlier confirmation, that mainline w/o the
> > > -hrt patches boots fine, when you add "apicmaintimer" to the kernel
> >
Rafael,
On Tue, 2007-09-25 at 23:28 +0200, Rafael J. Wysocki wrote:
> > I'm a bit confused by your earlier confirmation, that mainline w/o the
> > -hrt patches boots fine, when you add "apicmaintimer" to the kernel
> > command line. "apicmaintimer" stops the PIT like we do in -hrt and we
> > just
Thomas,
On Tuesday, 25 September 2007 22:46, Thomas Gleixner wrote:
> Rafael,
>
> On Tue, 2007-09-25 at 22:07 +0200, Rafael J. Wysocki wrote:
> > On Tuesday, 25 September 2007 15:17, Thomas Gleixner wrote:
> > > On Tue, 2007-09-25 at 15:16 +0200, Rafael J. Wysocki wrote:
> > [--snip--]
> > >
> >
Rafael,
On Tue, 2007-09-25 at 22:07 +0200, Rafael J. Wysocki wrote:
> On Tuesday, 25 September 2007 15:17, Thomas Gleixner wrote:
> > On Tue, 2007-09-25 at 15:16 +0200, Rafael J. Wysocki wrote:
> [--snip--]
> >
> > I start to get desperate. Below is a patch, which moves the apic timer
> > disable
On Tuesday, 25 September 2007 15:17, Thomas Gleixner wrote:
> On Tue, 2007-09-25 at 15:16 +0200, Rafael J. Wysocki wrote:
[--snip--]
>
> I start to get desperate. Below is a patch, which moves the apic timer
> disable check after the calibration routine. Can you please apply on top
> of -hrt and a
On Tue, 2007-09-25 at 15:16 +0200, Rafael J. Wysocki wrote:
> > > There seems to be a history effect in the box, to make things more
> > > "interesting".
> >
> > Did you connect this box to Andrews VAIO during KS ?
>
> No, but it's famous for being interestingly broken nevertheless.
:)
> > > I
On Monday, 24 September 2007 21:13, Thomas Gleixner wrote:
> On Mon, 2007-09-24 at 21:11 +0200, Rafael J. Wysocki wrote:
> > > /me scratches head
> >
> > Retested.
> >
> > > We know, that
> > > - disabling local apic timers work
> >
> > This works reproducibly accross the board.
>
> Ok
>
> > >
On Tuesday, 25 September 2007 14:52, Rafael J. Wysocki wrote:
> On Tuesday, 25 September 2007 14:28, Thomas Gleixner wrote:
> > On Tue, 2007-09-25 at 14:20 +0200, Rafael J. Wysocki wrote:
> > > > > > As i can see from the log, you are booting on computer with
> > > > > > dualcore AMD
> > > > > > p
On Tuesday, 25 September 2007 14:28, Thomas Gleixner wrote:
> On Tue, 2007-09-25 at 14:20 +0200, Rafael J. Wysocki wrote:
> > > > > As i can see from the log, you are booting on computer with dualcore
> > > > > AMD
> > > > > processor. Do you have C1E feature enabled?
> >
> > That's possible, ho
On Tue, 2007-09-25 at 14:20 +0200, Rafael J. Wysocki wrote:
> > > > As i can see from the log, you are booting on computer with dualcore AMD
> > > > processor. Do you have C1E feature enabled?
>
> That's possible, how to check?
>
> > > > i386 kernel disable lapic on dualcore AMD with C1E support
Thomas,
On Tuesday, 25 September 2007 11:30, Thomas Gleixner wrote:
> Rafael,
>
> On Tue, 2007-09-25 at 10:07 +0200, Thomas Gleixner wrote:
> > On Tue, 2007-09-25 at 10:14 +0400, Mikhail Kshevetskiy wrote:
> > > Hello Thomas, Rafael
> > >
> > > > We know, that
> > > > - disabling local apic time
Rafael,
On Tue, 2007-09-25 at 10:07 +0200, Thomas Gleixner wrote:
> On Tue, 2007-09-25 at 10:14 +0400, Mikhail Kshevetskiy wrote:
> > Hello Thomas, Rafael
> >
> > > We know, that
> > > - disabling local apic timers work
> >
> > As i can see from the log, you are booting on computer with dualcore
On Tue, 2007-09-25 at 10:14 +0400, Mikhail Kshevetskiy wrote:
> Hello Thomas, Rafael
>
> > We know, that
> > - disabling local apic timers work
>
> As i can see from the log, you are booting on computer with dualcore AMD
> processor. Do you have C1E feature enabled?
>
> i386 kernel disable lapi
On Mon, 2007-09-24 at 21:11 +0200, Rafael J. Wysocki wrote:
> > /me scratches head
>
> Retested.
>
> > We know, that
> > - disabling local apic timers work
>
> This works reproducibly accross the board.
Ok
> > - local apic timers (which turn off PIT) work. when noacpiFSCKEDPARSING
>
> This st
On Monday, 24 September 2007 18:46, Thomas Gleixner wrote:
> On Mon, 2007-09-24 at 17:18 +0200, Rafael J. Wysocki wrote:
> > > > Well, "noacpi" seems to be a synonym for "pci=noacpi".
> > > >
> > > > Anyway, it causes acpi_disable_pci() to be executed, which according to
> > > > Documentation/kern
On Mon, 2007-09-24 at 17:18 +0200, Rafael J. Wysocki wrote:
> > > Well, "noacpi" seems to be a synonym for "pci=noacpi".
> > >
> > > Anyway, it causes acpi_disable_pci() to be executed, which according to
> > > Documentation/kernel-parameters.txt means "Do not use ACPI for IRQ
> > > routing or
>
On Monday, 24 September 2007 16:23, Thomas Gleixner wrote:
> On Mon, 2007-09-24 at 15:52 +0200, Rafael J. Wysocki wrote:
> > > > > So I really wonder, why noacpitimer on the kernel command line makes
> > > > > any
> > > > > difference. I'm confused.
> > > >
> > > > \metoo
> > > >
> > > > Well, i
On Mon, 2007-09-24 at 15:52 +0200, Rafael J. Wysocki wrote:
> > > > So I really wonder, why noacpitimer on the kernel command line makes any
> > > > difference. I'm confused.
> > >
> > > \metoo
> > >
> > > Well, it was probably read as "noacpi". :-)
> >
> > Hmm, ACPI is in the log all over the p
On Monday, 24 September 2007 15:05, Thomas Gleixner wrote:
> On Mon, 2007-09-24 at 14:57 +0200, Rafael J. Wysocki wrote:
> > > > http://tglx.de/projects/hrtimers/2.6.23-rc4/patch-2.6.23-rc4-hrt1.patches.tar.bz2
> > > >
> > > > applied. I also have the 2.6.23-rc6-mm1 dmesg output ready, but
> > >
On Mon, 2007-09-24 at 14:57 +0200, Rafael J. Wysocki wrote:
> > > http://tglx.de/projects/hrtimers/2.6.23-rc4/patch-2.6.23-rc4-hrt1.patches.tar.bz2
> > >
> > > applied. I also have the 2.6.23-rc6-mm1 dmesg output ready, but there's
> > > some
> > > -mm-specific noise in it. Please let me know i
On Monday, 24 September 2007 10:07, Thomas Gleixner wrote:
> On Sun, 2007-09-23 at 22:52 +0200, Rafael J. Wysocki wrote:
> > > > Second, noacpitimer added to the command line makes all of the kernels,
> > > > up to
> > > > and including 2.6.23-rc6-mm1, boot (this seems to be 100% reproducible).
>
On Sun, 2007-09-23 at 22:52 +0200, Rafael J. Wysocki wrote:
> > > Second, noacpitimer added to the command line makes all of the kernels,
> > > up to
> > > and including 2.6.23-rc6-mm1, boot (this seems to be 100% reproducible).
> >
> > That's valuable information. Can you please provide a boot l
On Sunday, 23 September 2007 21:59, Thomas Gleixner wrote:
> On Sun, 2007-09-23 at 22:08 +0200, Rafael J. Wysocki wrote:
> > > > Since the boot fails very early, before any messages reach the (VGA)
> > > > console,
> > > > I have no idea what to do next, except for digging in the code.
> > >
> >
On Sun, 2007-09-23 at 22:08 +0200, Rafael J. Wysocki wrote:
> > > Since the boot fails very early, before any messages reach the (VGA)
> > > console,
> > > I have no idea what to do next, except for digging in the code.
> >
> > Ok, lets track it down. Is there any difference when you add:
> >
>
On Sunday, 23 September 2007 21:10, Thomas Gleixner wrote:
> On Sun, 2007-09-23 at 12:57 +0200, Rafael J. Wysocki wrote:
> > Hi Thomas,
> >
> > Unfortunately, my observation that the patch series:
> >
> > http://tglx.de/projects/hrtimers/2.6.23-rc4/patch-2.6.23-rc4-hrt1.patches.tar.bz2
> >
> > w
On Sun, 2007-09-23 at 12:57 +0200, Rafael J. Wysocki wrote:
> Hi Thomas,
>
> Unfortunately, my observation that the patch series:
>
> http://tglx.de/projects/hrtimers/2.6.23-rc4/patch-2.6.23-rc4-hrt1.patches.tar.bz2
>
> worked with 2.6.23-rc4 was wrong. It _sometimes_ works, but usually doesn't
39 matches
Mail list logo
