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 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
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
> >
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
command
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 boot
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 applied, 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 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
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
> >
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
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
> > > > > >
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,
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
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
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
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
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 lapic on
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 AMD
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 timers work
As
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 (see
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, how to check?
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
processor. Do you
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
- local apic timers
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 think the only
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 add
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 check
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--]
I start to
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 use the
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
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
> > > >
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,
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
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
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
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 log of one of
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).
That's
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 if you want it,
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
there's some
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 place.
Well, noacpi
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, it was probably read as noacpi.
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
for PCI scanning
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/kernel-parameters.txt
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 stopped working,
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
> >
> >
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
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
boot, just like 2.6.23-rc4-mm1, 2.6.23-rc6-mm1 and everything in between
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
boot, just like 2.6.23-rc4-mm1, 2.6.23-rc6-mm1 and everything in between
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
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
worked with
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:
nohz=off
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.
Ok, lets track
80 matches
Mail list logo
