Hi Ingo... just a heads up. I've been running 2.6.14-rt21 for a few days
and the timing issues seem to be gone on my X2 machine, as the main
timing is no longer derived from the TSC's. Very good! It should work
great with a patched Jack (that does not use TSC for its internal timing
measurements).
But I'm seeing a recurrent problem that so far I can only blame -rt21
for. When I start evolution (on a fully patched 32 bit fc4 system) it
eventually dies. I'm sorry I don't have more information on exactly what
is happening and I know this report is not very useful. The crash seems
related to reading email (when there's a lot of it) at the same as it is
storing folders and doing other things. After starting it again a couple
of times it keeps working fine for the rest of the day. I'm now at home
with a cold so I have not been able to reboot into the previous kernel
to double check but I wanted to warn you anyway... (I don't see anything
on the logs).
The kernel I was running successfully before (by setting the clock
source manually to acpi_pm) was 2.6.14-rt13.
-- Fernando
On Sat, 2005-12-03 at 12:47 -0800, Fernando Lopez-Lezcano wrote:
> Hi Ingo... just a heads up. I've been running 2.6.14-rt21 for a few days
> and the timing issues seem to be gone on my X2 machine, as the main
> timing is no longer derived from the TSC's. Very good! It should work
> great with a patched Jack (that does not use TSC for its internal timing
> measurements).
>
> But I'm seeing a recurrent problem that so far I can only blame -rt21
> for. When I start evolution (on a fully patched 32 bit fc4 system) it
> eventually dies.
I was seeing exactly the same problem here. I don't think it's related
to -rt21, I think someome posted a malformed message to LKML or one of
the other lists that we are both on and Evo is choking on it. It starts
to download the mail then you get "Storing folder" for like 5 minutes
then it crashes.
I finally managed to get into my mail by (carefully) deleting ALL
metadata - all the .index, .index.data, .cmeta, and .ev-summary files
from .evolution.
Lee
On Sat, 2005-12-03 at 17:08 -0500, Lee Revell wrote:
> On Sat, 2005-12-03 at 12:47 -0800, Fernando Lopez-Lezcano wrote:
> > Hi Ingo... just a heads up. I've been running 2.6.14-rt21 for a few days
> > and the timing issues seem to be gone on my X2 machine, as the main
> > timing is no longer derived from the TSC's. Very good! It should work
> > great with a patched Jack (that does not use TSC for its internal timing
> > measurements).
> >
> > But I'm seeing a recurrent problem that so far I can only blame -rt21
> > for. When I start evolution (on a fully patched 32 bit fc4 system) it
> > eventually dies.
>
> I was seeing exactly the same problem here. I don't think it's related
> to -rt21, I think someome posted a malformed message to LKML or one of
> the other lists that we are both on and Evo is choking on it. It starts
> to download the mail then you get "Storing folder" for like 5 minutes
> then it crashes.
It is not the exact same behavior I'm seeing, I get the crashes usually
in the middle of the new message download process the first time I start
evo in the morning. If I let it idle after startup, evo does all the
"storing folder" stuff and eventually dies when getting the new email
(or so I think).
But you could of course be right and there is some message it is choking
on - it is strange that this is happening to you as well. I think this
first happened to me on Wed Nov 30.
To tell the truth this does not seem like a -rt related problem except
that it started happening the day I booted into -rt21.
> I finally managed to get into my mail by (carefully) deleting ALL
> metadata - all the .index, .index.data, .cmeta, and .ev-summary files
> from .evolution.
I can get it to start after two or three tries (so far) without touching
anything in evo's files. And then it runs fine. The behavior
_subjectively_ gives me the impression that it is related to downloading
large number of messages, or doing many things at once at startup
(threading).
-- Fernando
On Sat, Dec 03, 2005 at 03:48:16PM -0800, Fernando Lopez-Lezcano wrote:
>
> To tell the truth this does not seem like a -rt related problem except
> that it started happening the day I booted into -rt21.
>
Can you try this patch below. Ingo has already included it in his tree
and will probably show up in -rt22.
This was changed in -rt14 and returns spurious -ETIMEDOUT from
FUTEX_WAIT calls which I just checked that evo does a lot of
-Dinakar
On Sun, 2005-12-04 at 20:28 +0530, Dinakar Guniguntala wrote:
> On Sat, Dec 03, 2005 at 03:48:16PM -0800, Fernando Lopez-Lezcano wrote:
> >
> > To tell the truth this does not seem like a -rt related problem except
> > that it started happening the day I booted into -rt21.
> >
>
> Can you try this patch below. Ingo has already included it in his tree
> and will probably show up in -rt22.
>
> This was changed in -rt14 and returns spurious -ETIMEDOUT from
> FUTEX_WAIT calls which I just checked that evo does a lot of
I'll definitely try this and report back. Thanks!
I just double checked, and had no trouble starting evolution with a
previous kernel on a different machine (after several days of having the
same problem running on -rt21).
-- Fernando
On Sun, 2005-12-04 at 20:28 +0530, Dinakar Guniguntala wrote:
> On Sat, Dec 03, 2005 at 03:48:16PM -0800, Fernando Lopez-Lezcano wrote:
> >
> > To tell the truth this does not seem like a -rt related problem except
> > that it started happening the day I booted into -rt21.
> >
>
> Can you try this patch below. Ingo has already included it in his tree
> and will probably show up in -rt22.
>
> This was changed in -rt14 and returns spurious -ETIMEDOUT from
> FUTEX_WAIT calls which I just checked that evo does a lot of
Good news. I tried it and seems to be working. Not conclusive as this
was just one evolution startup in the morning but there were no crashes
(and I was consistently getting them with plain -rt21).
Woohoo!
Thanks!
-- Fernando
* Fernando Lopez-Lezcano <[email protected]> wrote:
> > Can you try this patch below. Ingo has already included it in his tree
> > and will probably show up in -rt22.
> >
> > This was changed in -rt14 and returns spurious -ETIMEDOUT from
> > FUTEX_WAIT calls which I just checked that evo does a lot of
>
> Good news. I tried it and seems to be working. Not conclusive as this
> was just one evolution startup in the morning but there were no
> crashes (and I was consistently getting them with plain -rt21).
thanks for the testing - i've released -rt22 with this fix included.
Ingo
For some strange reason I couldn't get 2.6.15-rc5-rt2 to compile. Kconfig
keeped setting CONFIG_RWSEM_XCHGADD_ALGORITHM=y in my .config even though
I had CONFIG_PREEMPT_RT=y.
I don't know much about Kconfig but to me it is odd that the
RWSEM_XCHGADD_ALGORITHM option is both in arch/i386/Kconfig and
arch/i386/Kconfig.cpu with different dependencies.
When I removed it from Kconfig.cpu my problem disappeared and I could
compile. But I have no clue what else this change does to the config
system....
Esben
--- linux-2.6-rt/arch/i386/Kconfig.orig 2005-12-16 22:38:26.000000000 +0100
+++ linux-2.6-rt/arch/i386/Kconfig 2005-12-20 02:11:41.000000000 +0100
@@ -245,7 +245,7 @@
config RWSEM_XCHGADD_ALGORITHM
bool
- depends on !RWSEM_GENERIC_SPINLOCK && !PREEMPT_RT
+ depends on !RWSEM_GENERIC_SPINLOCK && !PREEMPT_RT && !M386
default y
config X86_UP_APIC
--- linux-2.6-rt/arch/i386/Kconfig.cpu.orig 2005-12-1300:02:19.000000000 +0100
+++ linux-2.6-rt/arch/i386/Kconfig.cpu 2005-12-20 02:11:47.000000000 +0100
@@ -229,11 +229,6 @@
depends on M386
default y
-config RWSEM_XCHGADD_ALGORITHM
- bool
- depends on !M386
- default y
-
config GENERIC_CALIBRATE_DELAY
bool
default y