We are pleased to announce the next update to our new preempt-rt
series. It contains only one new patch:
- port forward to 2.6.29-rc7
- disable CONFIG_MAXCPUS for now (undebugged runtime bug)
- fix CONFIG_HIGHMEM problems
- fix netfilter problems
- make debugobjects -rt safe
- various build fixes
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.29-rc7-rt1 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.29-rc7.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29-rc7-rt1.bz2
The broken out patches are also available at the same download
locations.
Enjoy !
tglx
Hi
It is great to see that the -rt patchset is moving again.
> http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29-rc7-rt1.bz2
This should be
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29-rc7-rt1.patch.bz2
As far as i understand this is again for x86. I tried some patches to get the
ARM platform working as the platform i am working on (phytec i.mx31) is not
supported by the stable 2.6.26-rt release. The attached patches are for
reference only as i think some of them are on their way via the pengutronix
git tree and others are just hacks to get this thing compile. These patches
enable rt functionality as tested with cyclictest but the kernel is not
stable, so some pieces are missing.
So my question is, what pieces are missing on the ARM platform to get it working?
Regards
Tim
The following patches are against the 2.6.29-rc4-rt2 in an attempt to get ARM working.
Subject: [PATCH] add compile fixes to rt patchset for arm
---
arch/arm/Kconfig | 13 +------------
arch/arm/include/asm/thread_info.h | 3 ++-
arch/arm/plat-mxc/include/mach/memory.h | 2 ++
include/linux/spinlock.h | 3 ++-
4 files changed, 7 insertions(+), 14 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index dbfdf87..ceb2e01 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -838,18 +838,7 @@ config LOCAL_TIMERS
accounting to be spread across the timer interval, preventing a
"thundering herd" at every timer tick.
-config PREEMPT
- bool "Preemptible Kernel (EXPERIMENTAL)"
- depends on EXPERIMENTAL
- help
- This option reduces the latency of the kernel when reacting to
- real-time or interactive events by allowing a low priority process to
- be preempted even if it is in kernel mode executing a system call.
- This allows applications to run more reliably even when the system is
- under load.
-
- Say Y here if you are building a kernel for a desktop, embedded
- or real-time system. Say N if you are unsure.
+source kernel/Kconfig.preempt
config HZ
int
diff --git a/arch/arm/include/asm/thread_info.h b/arch/arm/include/asm/thread_info.h
index 68b9ec8..b501541 100644
--- a/arch/arm/include/asm/thread_info.h
+++ b/arch/arm/include/asm/thread_info.h
@@ -119,7 +119,8 @@ extern void iwmmxt_task_switch(struct thread_info *);
* We use bit 30 of the preempt_count to indicate that kernel
* preemption is occurring. See <asm/hardirq.h>.
*/
-#define PREEMPT_ACTIVE 0x40000000
+#define PREEMPT_ACTIVE 0x10000000
+/*FIXME TIM #define PREEMPT_ACTIVE 0x40000000*/
/*
* thread information flags:
diff --git a/arch/arm/plat-mxc/include/mach/memory.h
b/arch/arm/plat-mxc/include/mach/memory.h
index 0b80839..b43a536 100644
--- a/arch/arm/plat-mxc/include/mach/memory.h
+++ b/arch/arm/plat-mxc/include/mach/memory.h
@@ -19,4 +19,6 @@
#define PHYS_OFFSET UL(0x80000000)
#endif
+#define arch_is_coherent() 1
+
#endif /* __ASM_ARCH_MXC_MEMORY_H__ */
diff --git a/include/linux/spinlock.h b/include/linux/spinlock.h
index c11b3a2..6c9b9b9 100644
--- a/include/linux/spinlock.h
+++ b/include/linux/spinlock.h
@@ -560,7 +560,8 @@ static inline void bit_spin_unlock(int bitnum, unsigned long *addr)
# ifdef CONFIG_DEBUG_SPINLOCK
BUG_ON(!test_bit(bitnum, addr));
# endif
- clear_bit_unlock(bitnum, addr);
+ //FIXME TIM clear_bit_unlock(bitnum, addr);
+ clear_bit(bitnum,addr);
#endif
__release(bitlock);
}
--
1.5.6.5
-- ---
arch/arm/kernel/process.c | 2 +-
include/linux/spinlock.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index d3ea6fa..8fbf03b 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -167,7 +167,7 @@ void cpu_idle(void)
idle();
leds_event(led_idle_end);
tick_nohz_restart_sched_tick();
- preempt_enable_no_resched();
+ __preempt_enable_no_resched();
schedule();
preempt_disable();
}
diff --git a/include/linux/spinlock.h b/include/linux/spinlock.h
index 6c9b9b9..130fbdd 100644
--- a/include/linux/spinlock.h
+++ b/include/linux/spinlock.h
@@ -93,6 +93,7 @@
#include <linux/bottom_half.h>
#include <linux/irqflags.h>
#include <linux/pickop.h>
+#include <asm/memory.h>
#include <asm/system.h>
@@ -560,8 +561,7 @@ static inline void bit_spin_unlock(int bitnum, unsigned long *addr)
# ifdef CONFIG_DEBUG_SPINLOCK
BUG_ON(!test_bit(bitnum, addr));
# endif
- //FIXME TIM clear_bit_unlock(bitnum, addr);
- clear_bit(bitnum,addr);
+ clear_bit_unlock(bitnum, addr);
#endif
__release(bitlock);
}
--
1.5.6.5
''=~('(?{'.('._@@[~'^'^-)./^').'"'.('}@@~-]@_^__'^'))-^~<.;;-}').',$/})')
Hello Tim,
On Thu, Mar 12, 2009 at 09:43:33PM +0100, Tim Sander wrote:
> So my question is, what pieces are missing on the ARM platform to get
> it working?
See the follow up mail I will write on Thomas announcement for my
current status.
> diff --git a/arch/arm/include/asm/thread_info.h b/arch/arm/include/asm/thread_info.h
> index 68b9ec8..b501541 100644
> --- a/arch/arm/include/asm/thread_info.h
> +++ b/arch/arm/include/asm/thread_info.h
> @@ -119,7 +119,8 @@ extern void iwmmxt_task_switch(struct thread_info *);
> * We use bit 30 of the preempt_count to indicate that kernel
> * preemption is occurring. See <asm/hardirq.h>.
> */
> -#define PREEMPT_ACTIVE 0x40000000
> +#define PREEMPT_ACTIVE 0x10000000
> +/*FIXME TIM #define PREEMPT_ACTIVE 0x40000000*/
I didn't need this anymore for -rc7-rt1.
> /*
> * thread information flags:
> diff --git a/arch/arm/plat-mxc/include/mach/memory.h
> b/arch/arm/plat-mxc/include/mach/memory.h
> index 0b80839..b43a536 100644
> --- a/arch/arm/plat-mxc/include/mach/memory.h
> +++ b/arch/arm/plat-mxc/include/mach/memory.h
> @@ -19,4 +19,6 @@
> #define PHYS_OFFSET UL(0x80000000)
> #endif
>
> +#define arch_is_coherent() 1
> +
I suggested a better fix already last time. Moreover I think imx isn't
coherent.
> diff --git a/include/linux/spinlock.h b/include/linux/spinlock.h
> index 6c9b9b9..130fbdd 100644
> --- a/include/linux/spinlock.h
> +++ b/include/linux/spinlock.h
> @@ -93,6 +93,7 @@
> #include <linux/bottom_half.h>
> #include <linux/irqflags.h>
> #include <linux/pickop.h>
> +#include <asm/memory.h>
Doing this in arch/arm/include/asm/bitops.h is less intrusive and it
seems to me the better place. See my patch stack.
> @@ -560,8 +561,7 @@ static inline void bit_spin_unlock(int bitnum, unsigned long *addr)
> # ifdef CONFIG_DEBUG_SPINLOCK
> BUG_ON(!test_bit(bitnum, addr));
> # endif
> - //FIXME TIM clear_bit_unlock(bitnum, addr);
> - clear_bit(bitnum,addr);
> + clear_bit_unlock(bitnum, addr);
It would be easier to check your patch if it didn't contain reverts of
earlier changes.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Hello,
On Thu, Mar 12, 2009 at 08:17:50PM +0100, Thomas Gleixner wrote:
> We are pleased to announce the next update to our new preempt-rt
> series. It contains only one new patch:
>
> - port forward to 2.6.29-rc7
> - disable CONFIG_MAXCPUS for now (undebugged runtime bug)
> - fix CONFIG_HIGHMEM problems
> - fix netfilter problems
> - make debugobjects -rt safe
> - various build fixes
on top of 2.6.29-rc7-rc1 I did some ARM related fixes that you can find
at
git://git.pengutronix.de/git/ukl/linux-2.6.git v2.6.29-rc7-rt1-pu
The top commit currently isn't pretty as it contains several independant
fixes. Some of them are netX specific so you probably don't need them,
but they shouldn't hurt you either.
I will update this branch as I continue working in a non-fast-forward
manner. I use TopGit to manage this branch, you might want to use it,
too, if you intend to follow my work.
My status quo is:
Testing tracer sched_switch: PASSED
Testing tracer function: PASSED
Testing tracer irqsoff: .. no entries found ..FAILED!
Testing tracer preemptoff: .. no entries found ..FAILED!
Testing tracer preemptirqsoff: .. no entries found ..<4>------------[ cut here ]------------
WARNING: at /ptx/work/octopus/WORK_2_A/ukl/gsrc/linux-2.6/kernel/trace/trace.c:683 warn_slowpath+0x18/0xa0()
Modules linked in:
[<c0244d40>] (dump_stack+0x0/0x18) from [<c003787c>] (warn_slowpath+0x6c/0xa0)
[<c0037810>] (warn_slowpath+0x0/0xa0) from [<c00750d0>] (tracing_start+0x60/0xdc)
r3:ffffffff r2:00000000
r7:c074aaf0 r6:c0748a0c r5:60000013 r4:c074aac8
[<c0075070>] (tracing_start+0x0/0xdc) from [<c0076430>] (trace_selftest_startup_preemptirqsoff+0x1ac/0x1d8)
r5:c1c1a000 r4:ffffffff
[<c0076284>] (trace_selftest_startup_preemptirqsoff+0x0/0x1d8) from [<c00760c4>] (register_tracer+0x118/0x240)
[<c0075fac>] (register_tracer+0x0/0x240) from [<c000ebbc>] (init_irqsoff_tracer+0x24/0x38)
r7:c000eb98 r6:00000000 r5:c001c44c r4:c001c2b8
[<c000eb98>] (init_irqsoff_tracer+0x0/0x38) from [<c00232c4>] (__exception_text_end+0x5c/0x1a4)
[<c0023268>] (__exception_text_end+0x0/0x1a4) from [<c00085a4>] (kernel_init+0x90/0x1c0)
r8:00000000 r7:00000000 r6:00000000 r5:c001c44c r4:c001c2b8
[<c0008514>] (kernel_init+0x0/0x1c0) from [<c003aebc>] (do_exit+0x0/0x798)
r5:00000000 r4:00000000
---[ end trace da227214a82491b7 ]---
FAILED!
The warning is triggered here because tracing_start is called twice in
trace_selftest_startup_preemptirqsoff's error path[1].
I researched for some time now why the tracers doesn't pass the
self-tests, but without success. It's bed time and any hints are
welcome.
Other than that my machine boots and reports from time to time
scheduling while atomic
and
sleeping function called from invalid context at kernel/rtmutex.c:683
Both errors probably happen because some spin_locks need to be converted
to raw_spin_locks. Will look later.
I provide this uncooked state to prevent duplicate work, so please
excuse the bad code and commit history. If it upsets you, please send
patches :-)
Best regards
Uwe
[1] if trace_test_buffer sets count = 0 or returns != 0 in
kernel/trace/trace_selftest.c:440, the code flow is:
tracing_start()
goto out;
...
out:
trace->reset(tr);
tracing_start();
I think the last tracing_start is wrong, but I didn't check deeply.
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
After a quick test some BUG's on boot (on a quad core intel machine),
I'm just attaching the whole dmesg output as that might provide more
clues...
In short, two types, one BUG and another WARNING:
BUG: sleeping function called from invalid context at
kernel/rtmutex.c:683
WARNING: at fs/sysfs/group.c:138 sysfs_remove_group+0x3e/0xa8()
Thanks again for all the hard work!
(and looking forward to the next rt patch!)
-- Fernando
On Fri, 13 Mar 2009, Fernando Lopez-Lezcano wrote:
> After a quick test some BUG's on boot (on a quad core intel machine),
> I'm just attaching the whole dmesg output as that might provide more
> clues...
>
> In short, two types, one BUG and another WARNING:
>
> BUG: sleeping function called from invalid context at
> kernel/rtmutex.c:683
> WARNING: at fs/sysfs/group.c:138 sysfs_remove_group+0x3e/0xa8()
Yep. I got another report already. Looking into it.
> Thanks again for all the hard work!
> (and looking forward to the next rt patch!)
Thansk for testing !
tglx
Hello,
On Fri, Mar 13, 2009 at 02:04:58AM +0100, Uwe Kleine-K?nig wrote:
> on top of 2.6.29-rc7-rc1 I did some ARM related fixes that you can find
> at
>
> git://git.pengutronix.de/git/ukl/linux-2.6.git v2.6.29-rc7-rt1-pu
>
> The top commit currently isn't pretty as it contains several independant
> fixes. Some of them are netX specific so you probably don't need them,
> but they shouldn't hurt you either.
>
> I will update this branch as I continue working in a non-fast-forward
> manner. I use TopGit to manage this branch, you might want to use it,
> too, if you intend to follow my work.
>
> My status quo is:
>
> Testing tracer sched_switch: PASSED
> Testing tracer function: PASSED
> Testing tracer irqsoff: .. no entries found ..FAILED!
> Testing tracer preemptoff: .. no entries found ..FAILED!
> Testing tracer preemptirqsoff: .. no entries found ..
[removed stack dump]
> FAILED!
I still have this problem. I digged into irqsoff without finding the reason.
Looking at trace_selftest_startup_irqsoff I saw that
trace_buffer_lock_reserve is called thrice successfully.
Steven (or someone else of course), do you can give me a hint?
> Other than that my machine boots and reports from time to time
>
> scheduling while atomic
>
> and
>
> sleeping function called from invalid context at kernel/rtmutex.c:683
>
> Both errors probably happen because some spin_locks need to be converted
> to raw_spin_locks. Will look later.
Up to now I didn't try to do much with my system, but just booting
doesn't yield such BUGs or Warnings anymore.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
We are pleased to announce the next update to our new preempt-rt
series.
- port forward to 2.6.29-rc8
- disable -rt conflicting config options
- hotplug cpu fixes (peterz)
- slab/pagealloc lock breaks (peterz / tglx)
- sigqueue caching for -rt tasks
- posixtimer thread avoid useless wakeups
- various build fixes (mingo, frank ....)
- lots of tracer updates from -tip (check the tip git logs)
The outstanding improvement is the slab/pagealloc change which breaks
and splits locking and brought down worst case latencies in
problematic use cases from >500us to <100us.
As a side note:
There seems to be a wide spread underestimation of the problem spots
exposed by preempt-rt. The usual shrug off answer is:
"I don't care about -rt. Come back if you can expose the same
problem in the mainline kernel."
This is a fundamentally wrong answer.
preempt-rt mostly exposes existing latency spots and magnifies
them
Reducing latencies in -rt by a factor 5 will be not that
prominent in a non-rt setup, but the problematic code area
will still produce measureable latency problems.
I'm well aware of the tradeoff between determinitic behaviour and
throughput, but problematic spots (e.g. lock contentions) hurt
both.
So can we please put down the stupid "I don't care about -rt"
attitudes and accept that we have to think about the mutual
benefits of deterministic and throughput aspects without hurting
each other ?
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.29-rc8-rt1 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.29-rc8.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29-rc8-rt1.bz2
The broken out patches are also available at the same download
locations.
Enjoy !
tglx
P.S.: ARM/PowerPC support is in the pipeline and will be available
with -rt2 (hopefully :)
On Thu, Mar 19, 2009 at 8:31 PM, Thomas Gleixner <[email protected]> wrote:
> We are pleased to announce the next update to our new preempt-rt
> series.
> P.S.: ARM/PowerPC support is in the pipeline and will be available
> ? ? ?with -rt2 (hopefully :)
Do you have a time estimate for -rt2/ARM support, and is there
anything that can be done to help (testing, etc).
Thanks,
Cliff
--
=======================
Cliff Brake
http://bec-systems.com
We are pleased to announce the next update to our new preempt-rt
series.
- resurrected ARM and PowerPC support
- tracing fixes for ARM (Uwe Kleine-Koenig)
The support for ARM/PowerPC has only been lightly tested. It might
crash and burn your system, make your hair curl, frigthen your cat and
give you sleepless nights. You have been warned !
On PowerPC watch out for the following warning:
__do_IRQ called for irq X. PREEMPT_RT will crash your system soon.
__do_IRQ is deprecated and -rt does not support it anymore. Most of
the PowerPC subarchitectures do not longer use it, but you might be
unlucky and hit one of the remaining users. RT will spit out the
message above and then do what it said. :)
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.29-rc8-rt1 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.29-rc8.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29-rc8-rt2.bz2
The broken out patches are also available at the same download
locations.
Enjoy !
tglx
On Fri, 20 Mar 2009, Cliff Brake wrote:
> On Thu, Mar 19, 2009 at 8:31 PM, Thomas Gleixner <[email protected]> wrote:
> > We are pleased to announce the next update to our new preempt-rt
> > series.
>
> > P.S.: ARM/PowerPC support is in the pipeline and will be available
> > with -rt2 (hopefully :)
>
> Do you have a time estimate for -rt2/ARM support, and is there
Time estimate is about: now minus 20sec :)
> anything that can be done to help (testing, etc).
Yup, the patches need full testing.
Thanks,
tglx
On Fri, 2009-03-20 at 18:45 +0100, Thomas Gleixner wrote:
> We are pleased to announce the next update to our new preempt-rt
> series.
>
> - resurrected ARM and PowerPC support
> - tracing fixes for ARM (Uwe Kleine-Koenig)
>
> The support for ARM/PowerPC has only been lightly tested. It might
> crash and burn your system, make your hair curl, frigthen your cat and
> give you sleepless nights. You have been warned !
During a build attempt on powerpc, I am seeing:
In file included from include/linux/mmzone.h:776,
from include/linux/gfp.h:5,
from include/linux/slab.h:13,
from include/linux/percpu.h:6,
from include/linux/rcupdate.h:40,
from include/linux/rculist.h:11,
from include/linux/dcache.h:7,
from include/linux/fs.h:299,
from init/do_mounts_rd.c:4:
/root/linux-2.6.29-rc8/arch/powerpc/include/asm/mmzone.h:32: error:
expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before
‘numa_cpumask_lookup_table’
In file included from include/linux/topology.h:35,
from include/linux/gfp.h:8,
from include/linux/slab.h:13,
from include/linux/percpu.h:6,
from include/linux/rcupdate.h:40,
from include/linux/rculist.h:11,
from include/linux/dcache.h:7,
from include/linux/fs.h:299,
from init/do_mounts_rd.c:4:
/root/linux-2.6.29-rc8/arch/powerpc/include/asm/topology.h: In function
‘node_to_cpumask’:
/root/linux-2.6.29-rc8/arch/powerpc/include/asm/topology.h:22: error:
‘numa_cpumask_lookup_table’ undeclared (first use in this function)
/root/linux-2.6.29-rc8/arch/powerpc/include/asm/topology.h:22: error:
(Each undeclared identifier is reported only once
/root/linux-2.6.29-rc8/arch/powerpc/include/asm/topology.h:22: error:
for each function it appears in.)
/root/linux-2.6.29-rc8/arch/powerpc/include/asm/topology.h: In function
‘node_to_first_cpu’:
/root/linux-2.6.29-rc8/arch/powerpc/include/asm/topology.h:29: error:
‘numa_cpumask_lookup_table’ undeclared (first use in this function)
make[1]: *** [init/do_mounts_rd.o] Error 1
make[1]: *** Waiting for unfinished jobs....
I have locally fixed by adding an include just above the cpumask_t
reference. The include may belong elsewhere, but in case I got it
right,.. :-)
Signed-Off-By: Will Schmidt <[email protected]>
--
diff --git a/arch/powerpc/include/asm/mmzone.h
b/arch/powerpc/include/asm/mmzone.h
index 19f299b..530fa41 100644
--- a/arch/powerpc/include/asm/mmzone.h
+++ b/arch/powerpc/include/asm/mmzone.h
@@ -28,6 +28,8 @@ extern struct pglist_data *node_data[];
* Following are specific to this numa platform.
*/
+#include <linux/cpumask.h>
+
extern int numa_cpu_lookup_table[];
extern cpumask_t numa_cpumask_lookup_table[];
#ifdef CONFIG_MEMORY_HOTPLUG
Thanks,
-Will
>
> On PowerPC watch out for the following warning:
>
> __do_IRQ called for irq X. PREEMPT_RT will crash your system soon.
>
> __do_IRQ is deprecated and -rt does not support it anymore. Most of
> the PowerPC subarchitectures do not longer use it, but you might be
> unlucky and hit one of the remaining users. RT will spit out the
> message above and then do what it said. :)
>
> Download locations:
>
> http://rt.et.redhat.com/download/
> http://www.kernel.org/pub/linux/kernel/projects/rt/
>
> Information on the RT patch can be found at:
>
> http://rt.wiki.kernel.org/index.php/Main_Page
>
> to build the 2.6.29-rc8-rt1 tree, the following patches should be
> applied:
>
> http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.29-rc8.tar.bz2
> http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29-rc8-rt2.bz2
>
> The broken out patches are also available at the same download
> locations.
>
> Enjoy !
>
> tglx
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
* Will Schmidt <[email protected]> wrote:
> On Fri, 2009-03-20 at 18:45 +0100, Thomas Gleixner wrote:
> > We are pleased to announce the next update to our new preempt-rt
> > series.
> >
> > - resurrected ARM and PowerPC support
> > - tracing fixes for ARM (Uwe Kleine-Koenig)
> >
> > The support for ARM/PowerPC has only been lightly tested. It might
> > crash and burn your system, make your hair curl, frigthen your cat and
> > give you sleepless nights. You have been warned !
>
> During a build attempt on powerpc, I am seeing:
>
> In file included from include/linux/mmzone.h:776,
> from include/linux/gfp.h:5,
> from include/linux/slab.h:13,
> from include/linux/percpu.h:6,
> from include/linux/rcupdate.h:40,
> from include/linux/rculist.h:11,
> from include/linux/dcache.h:7,
> from include/linux/fs.h:299,
> from init/do_mounts_rd.c:4:
> /root/linux-2.6.29-rc8/arch/powerpc/include/asm/mmzone.h:32: error:
> expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before
> ‘numa_cpumask_lookup_table’
> In file included from include/linux/topology.h:35,
> from include/linux/gfp.h:8,
> from include/linux/slab.h:13,
> from include/linux/percpu.h:6,
> from include/linux/rcupdate.h:40,
> from include/linux/rculist.h:11,
> from include/linux/dcache.h:7,
> from include/linux/fs.h:299,
> from init/do_mounts_rd.c:4:
> /root/linux-2.6.29-rc8/arch/powerpc/include/asm/topology.h: In function
> ‘node_to_cpumask’:
> /root/linux-2.6.29-rc8/arch/powerpc/include/asm/topology.h:22: error:
> ‘numa_cpumask_lookup_table’ undeclared (first use in this function)
> /root/linux-2.6.29-rc8/arch/powerpc/include/asm/topology.h:22: error:
> (Each undeclared identifier is reported only once
> /root/linux-2.6.29-rc8/arch/powerpc/include/asm/topology.h:22: error:
> for each function it appears in.)
> /root/linux-2.6.29-rc8/arch/powerpc/include/asm/topology.h: In function
> ‘node_to_first_cpu’:
> /root/linux-2.6.29-rc8/arch/powerpc/include/asm/topology.h:29: error:
> ‘numa_cpumask_lookup_table’ undeclared (first use in this function)
> make[1]: *** [init/do_mounts_rd.o] Error 1
> make[1]: *** Waiting for unfinished jobs....
>
>
>
> I have locally fixed by adding an include just above the cpumask_t
> reference. The include may belong elsewhere, but in case I got it
> right,.. :-)
>
> Signed-Off-By: Will Schmidt <[email protected]>
you got it right :-) The full fix (the bug also affects sparc) is
already queued up - see it below.
Ingo
-------------->
>From 0c7e5b187fc599a40c1e6392926424d26cd0cf41 Mon Sep 17 00:00:00 2001
From: Stephen Rothwell <[email protected]>
Date: Thu, 19 Mar 2009 22:03:22 +1100
Subject: [PATCH] numa, cpumask: move numa_node_id default implementation to topology.h, fix
Impact: build fix for powerpc and sparc
Today's linux-next build (powerpc allyesconfig) failed like this:
> In file included from include/linux/mmzone.h:776,
> from include/linux/gfp.h:5,
> from include/linux/kmod.h:23,
> from include/linux/module.h:14,
> from init/version.c:11:
> arch/powerpc/include/asm/mmzone.h:32: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'numa_cpumask_lookup_table'
Caused by commit 082edb7bf443eb8eda15b482d16ad9dd8137ad24 ("numa,
cpumask: move numa_node_id default implementation to topology.h") from
the cpus4096 tree which removed the include of linux/topology.h from
linux/mmzone.h.
Same for sparc64 defconfig.
Signed-off-by: Stephen Rothwell <[email protected]>
Acked-b: Rusty Russell <[email protected]>
Cc: ppc-dev <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
---
arch/powerpc/include/asm/mmzone.h | 1 +
arch/sparc/include/asm/mmzone.h | 2 ++
2 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/mmzone.h b/arch/powerpc/include/asm/mmzone.h
index 19f299b..35acac9 100644
--- a/arch/powerpc/include/asm/mmzone.h
+++ b/arch/powerpc/include/asm/mmzone.h
@@ -8,6 +8,7 @@
#define _ASM_MMZONE_H_
#ifdef __KERNEL__
+#include <linux/cpumask.h>
/*
* generic non-linear memory support:
diff --git a/arch/sparc/include/asm/mmzone.h b/arch/sparc/include/asm/mmzone.h
index ebf5986..e8c6487 100644
--- a/arch/sparc/include/asm/mmzone.h
+++ b/arch/sparc/include/asm/mmzone.h
@@ -3,6 +3,8 @@
#ifdef CONFIG_NEED_MULTIPLE_NODES
+#include <linux/cpumask.h>
+
extern struct pglist_data *node_data[];
#define NODE_DATA(nid) (node_data[nid])
On Sat, 2009-03-14 at 08:46 +0100, Thomas Gleixner wrote:
> On Fri, 13 Mar 2009, Fernando Lopez-Lezcano wrote:
> > After a quick test some BUG's on boot (on a quad core intel machine),
> > I'm just attaching the whole dmesg output as that might provide more
> > clues...
> >
> > In short, two types, one BUG and another WARNING:
> >
> > BUG: sleeping function called from invalid context at
> > kernel/rtmutex.c:683
> > WARNING: at fs/sysfs/group.c:138 sysfs_remove_group+0x3e/0xa8()
>
> Yep. I got another report already. Looking into it.
>
> > Thanks again for all the hard work!
> > (and looking forward to the next rt patch!)
>
> Thansk for testing !
More testing and an Oops that prevents booting... maybe unrelated to rt?
(this is with 2.6.29-rc8 plus additional patches from Fedora's koji
build 61 for fc10). First time my laptop does not boot with the new
kernels on a long time.
See below.
-- Fernando
Mar 21 10:47:43 localhost kernel: kernel tried to execute NX-protected
page - exploit attempt? (uid: 0)
Mar 21 10:47:43 localhost kernel: BUG: unable to handle kernel paging
request at f6400800
Mar 21 10:47:43 localhost kernel: IP: [<f6400800>] 0xf6400800
Mar 21 10:47:43 localhost kernel: *pdpt = 0000000000922001 *pde =
000000003087f063 *pte = 8000000036400163
Mar 21 10:47:43 localhost kernel: Oops: 0011 [#1] PREEMPT SMP
Mar 21 10:47:43 localhost kernel: last sysfs
file: /sys/devices/pci0000:00/0000:00:19.0/irq
Mar 21 10:47:43 localhost kernel: Modules linked in: sunrpc ip6t_REJECT
nf_conntrack_ipv6 ip6table_filter ip6_tables cpufreq_ondemand
acpi_cpufreq dm_multipath i915 drm i2c_algo_bit ipv6
snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep thinkpad_acpi
hwmon arc4 snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq joydev
ecb sdhci_pci snd_seq_device yenta_socket ricoh_mmc i2c_i801 sdhci
i2c_core pcspkr snd_pcm_oss snd_mixer_oss snd_pcm mmc_core
rsrc_nonstatic iwl3945 ohci1394 snd_timer iTCO_wdt iTCO_vendor_support
snd video output soundcore rfkill btusb snd_page_alloc mac80211 lib80211
e1000e bluetooth cfg80211 ata_generic pata_acpi uhci_hcd ohci_hcd
ehci_hcd [last unloaded: microcode]
Mar 21 10:47:43 localhost kernel:
Mar 21 10:47:43 localhost kernel: Pid: 9, comm: sirq-tasklet/0 Not
tainted (2.6.29-0.2.rt2.1.rc8.fc9.ccrma.i686.rtPAE #1) 6463CTO
Mar 21 10:47:43 localhost kernel: EIP: 0060:[<f6400800>] EFLAGS:
00010246 CPU: 0
Mar 21 10:47:43 localhost kernel: EIP is at 0xf6400800
Mar 21 10:47:43 localhost kernel: EAX: f3858f20 EBX: 00000000 ECX:
000000ff EDX: f38598b4
Mar 21 10:47:43 localhost kernel: ESI: f3858f20 EDI: 000000ff EBP:
f7073f84 ESP: f7073f20
Mar 21 10:47:43 localhost kernel: DS: 007b ES: 007b FS: 00d8 GS: 0000
SS: 0068 preempt:00000001
Mar 21 10:47:43 localhost kernel: Process sirq-tasklet/0 (pid: 9,
ti=f7073000 task=f7088e30 task.ti=f7073000)
Mar 21 10:47:43 localhost kernel: Stack:
Mar 21 10:47:43 localhost kernel: f82adb93 f3859494 00000000 00010000
00000008 00ccd272 00000000 00000000
Mar 21 10:47:43 localhost kernel: 00000002 ea427004 f38598b4 f385b5cc
f385b5d8 2a427004 00000000 f385b7f4
Mar 21 10:47:43 localhost kernel: f385cf70 f3859880 f41a3a40 80000008
2a9ae004 00000006 f385d020 f385d024
Mar 21 10:47:43 localhost kernel: Call Trace:
Mar 21 10:47:43 localhost kernel: [<f82adb93>] ? iwl3945_irq_tasklet
+0x421/0x80f [iwl3945]
Mar 21 10:47:43 localhost kernel: [<c043d0e2>] ? __tasklet_action
+0x81/0xe4
Mar 21 10:47:43 localhost kernel: [<c043d1c5>] ? tasklet_action
+0x3e/0x42
Mar 21 10:47:43 localhost kernel: [<c043ceb7>] ? ksoftirqd+0x131/0x221
Mar 21 10:47:43 localhost kernel: [<c043cd86>] ? ksoftirqd+0x0/0x221
Mar 21 10:47:43 localhost kernel: [<c0449949>] ? kthread+0x3b/0x61
Mar 21 10:47:43 localhost kernel: [<c044990e>] ? kthread+0x0/0x61
Mar 21 10:47:43 localhost kernel: [<c0409207>] ? kernel_thread_helper
+0x7/0x10
Mar 21 10:47:43 localhost kernel: Code: 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 <00> 00 00 00 6c 09 14 00 01 00 00 00 00 00 00
00 06 00 00 00 0f
Mar 21 10:47:43 localhost kernel: EIP: [<f6400800>] 0xf6400800 SS:ESP
0068:f7073f20
Mar 21 10:47:43 localhost kernel: CR2: 00000000f6400800
Mar 21 10:47:43 localhost kernel: ---[ end trace 8e8838dc83c2350d ]---
* Fernando Lopez-Lezcano <[email protected]> wrote:
> Mar 21 10:47:43 localhost kernel: kernel tried to execute NX-protected
> page - exploit attempt? (uid: 0)
> Mar 21 10:47:43 localhost kernel: BUG: unable to handle kernel paging
> request at f6400800
kernel tried to execute some really weird address, probably via a
function pointer.
> ehci_hcd [last unloaded: microcode]
perhaps try excluding the microcode module for now - maybe it messed
up something?
> Mar 21 10:47:43 localhost kernel: EIP: 0060:[<f6400800>] EFLAGS:
> Mar 21 10:47:43 localhost kernel: Call Trace:
> Mar 21 10:47:43 localhost kernel: [<f82adb93>] ? iwl3945_irq_tasklet
> Mar 21 10:47:43 localhost kernel: [<c043d0e2>] ? __tasklet_action
> Mar 21 10:47:43 localhost kernel: [<c043d1c5>] ? tasklet_action
> Mar 21 10:47:43 localhost kernel: [<c043ceb7>] ? ksoftirqd+0x131/0x221
> Mar 21 10:47:43 localhost kernel: [<c043cd86>] ? ksoftirqd+0x0/0x221
> Mar 21 10:47:43 localhost kernel: [<c0449949>] ? kthread+0x3b/0x61
> Mar 21 10:47:43 localhost kernel: [<c044990e>] ? kthread+0x0/0x61
> Mar 21 10:47:43 localhost kernel: [<c0409207>] ? kernel_thread_helper
does any of the Fedora patches you have applied involve wireless
changes? I'd suggest undoing those first.
Ingo
On Sat, 2009-03-21 at 19:49 +0100, Ingo Molnar wrote:
> * Fernando Lopez-Lezcano <[email protected]> wrote:
>
> > Mar 21 10:47:43 localhost kernel: kernel tried to execute NX-protected
> > page - exploit attempt? (uid: 0)
> > Mar 21 10:47:43 localhost kernel: BUG: unable to handle kernel paging
> > request at f6400800
>
> kernel tried to execute some really weird address, probably via a
> function pointer.
Strangely enough rc8-rt1 boots (almost). _Exact_ same build with the
exception of the change from rt1 -> rt2.
Haldaemon does not start on boot (fails), if I login as root and start
the haldaemon service manually it starts. And then things seem to work
fine (I'm writing this email from that machine). Still investigating...
-- Fernando
> > ehci_hcd [last unloaded: microcode]
>
> perhaps try excluding the microcode module for now - maybe it messed
> up something?
>
> > Mar 21 10:47:43 localhost kernel: EIP: 0060:[<f6400800>] EFLAGS:
>
> > Mar 21 10:47:43 localhost kernel: Call Trace:
> > Mar 21 10:47:43 localhost kernel: [<f82adb93>] ? iwl3945_irq_tasklet
> > Mar 21 10:47:43 localhost kernel: [<c043d0e2>] ? __tasklet_action
> > Mar 21 10:47:43 localhost kernel: [<c043d1c5>] ? tasklet_action
> > Mar 21 10:47:43 localhost kernel: [<c043ceb7>] ? ksoftirqd+0x131/0x221
> > Mar 21 10:47:43 localhost kernel: [<c043cd86>] ? ksoftirqd+0x0/0x221
> > Mar 21 10:47:43 localhost kernel: [<c0449949>] ? kthread+0x3b/0x61
> > Mar 21 10:47:43 localhost kernel: [<c044990e>] ? kthread+0x0/0x61
> > Mar 21 10:47:43 localhost kernel: [<c0409207>] ? kernel_thread_helper
>
> does any of the Fedora patches you have applied involve wireless
> changes? I'd suggest undoing those first.
On Sat, 2009-03-21 at 12:06 -0700, Fernando Lopez-Lezcano wrote:
> On Sat, 2009-03-21 at 19:49 +0100, Ingo Molnar wrote:
> > * Fernando Lopez-Lezcano <[email protected]> wrote:
> >
> > > Mar 21 10:47:43 localhost kernel: kernel tried to execute NX-protected
> > > page - exploit attempt? (uid: 0)
> > > Mar 21 10:47:43 localhost kernel: BUG: unable to handle kernel paging
> > > request at f6400800
> >
> > kernel tried to execute some really weird address, probably via a
> > function pointer.
>
> Strangely enough rc8-rt1 boots (almost). _Exact_ same build with the
> exception of the change from rt1 -> rt2.
>
> Haldaemon does not start on boot (fails), if I login as root and start
> the haldaemon service manually it starts. And then things seem to work
> fine (I'm writing this email from that machine). Still investigating...
First problem was due to old firmware for the iwl3945 hardware. I
updated to the latest and hal started fine (this is on fc9).
Now another one related to xorg/drm...
Oh well...
-- Fernando
Mar 21 12:17:51 localhost kernel: ------------[ cut here ]------------
Mar 21 12:17:51 localhost kernel: kernel BUG at
drivers/gpu/drm/drm_fops.c:146!
Mar 21 12:17:51 localhost kernel: invalid opcode: 0000 [#1] PREEMPT SMP
Mar 21 12:17:51 localhost kernel: last sysfs
file: /sys/devices/pci0000:00/0000:00:02.0/drm/card0/dri_library_name
Mar 21 12:17:51 localhost kernel: Modules linked in: i915 drm
i2c_algo_bit bridge stp bnep rfcomm l2cap sunrpc ip6t_REJECT
nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 cpufreq_ondemand
acpi_cpufreq dm_multipath snd_hda_codec_analog snd_hda_intel
snd_hda_codec snd_hwdep thinkpad_acpi snd_seq_dummy snd_seq_oss
snd_seq_midi_event hwmon snd_seq sdhci_pci arc4 snd_seq_device sdhci
pcspkr joydev mmc_core snd_pcm_oss ecb i2c_i801 yenta_socket
snd_mixer_oss rsrc_nonstatic ricoh_mmc ohci1394 iTCO_wdt
iTCO_vendor_support i2c_core iwl3945 snd_pcm video snd_timer snd rfkill
output soundcore e1000e mac80211 btusb snd_page_alloc lib80211 bluetooth
cfg80211 ata_generic pata_acpi uhci_hcd ohci_hcd ehci_hcd [last
unloaded: microcode]
Mar 21 12:17:51 localhost kernel:
Mar 21 12:17:51 localhost kernel: Pid: 2809, comm: Xorg Not tainted
(2.6.29-0.2.rt1.1.rc8.fc9.ccrma.i686.rtPAE #1) 6463CTO
Mar 21 12:17:51 localhost kernel: EIP: 0060:[<f85a7471>] EFLAGS:
00013216 CPU: 0
Mar 21 12:17:51 localhost kernel: EIP is at drm_open+0x442/0x48d [drm]
Mar 21 12:17:51 localhost kernel: EAX: f59339a4 EBX: f45a582c ECX:
f4584564 EDX: f45a5800
Mar 21 12:17:51 localhost kernel: ESI: 00000000 EDI: f45a582c EBP:
f4570e64 ESP: f4570e40
Mar 21 12:17:51 localhost kernel: DS: 007b ES: 007b FS: 00d8 GS: 0033
SS: 0068 preempt:00000001
Mar 21 12:17:51 localhost kernel: Process Xorg (pid: 2809, ti=f4570000
task=f44e6d70 task.ti=f4570000)
Mar 21 12:17:51 localhost kernel: Stack:
Mar 21 12:17:51 localhost kernel: f4955e00 f4584564 f45a5800 f5883400
00000000 f45ca394 ffffffed f85b2338
Mar 21 12:17:51 localhost kernel: f4955e00 f4570e7c f85a6fe4 f4584564
00000000 f45433c0 f45433c0 f4570ea0
Mar 21 12:17:51 localhost kernel: c04ae3bd f4955e00 f4584564 00000000
00000000 f4955e00 00000000 f4584564
Mar 21 12:17:51 localhost kernel: Call Trace:
Mar 21 12:17:51 localhost kernel: [<f85a6fe4>] ? drm_stub_open+0xa5/0xf0
[drm]
Mar 21 12:17:51 localhost kernel: [<c04ae3bd>] ? chrdev_open+0x112/0x129
Mar 21 12:17:51 localhost kernel: [<c04aa8a5>] ? __dentry_open
+0x146/0x23a
Mar 21 12:17:51 localhost kernel: [<c04aaa33>] ? nameidata_to_filp
+0x2c/0x43
Mar 21 12:17:51 localhost kernel: [<c04ae2ab>] ? chrdev_open+0x0/0x129
Mar 21 12:17:51 localhost kernel: [<c04b489c>] ? do_filp_open
+0x35d/0x677
Mar 21 12:17:51 localhost kernel: [<c0456d82>] ? rt_spin_lock_fastlock
+0x27/0x5e
Mar 21 12:17:51 localhost kernel: [<c0456d82>] ? rt_spin_lock_fastlock
+0x27/0x5e
Mar 21 12:17:51 localhost kernel: [<c04aa68b>] ? do_sys_open+0x42/0xb7
Mar 21 12:17:51 localhost kernel: [<c04aa742>] ? sys_open+0x1e/0x26
Mar 21 12:17:51 localhost kernel: [<c0408720>] ? sysenter_do_call
+0x12/0x28
Mar 21 12:17:51 localhost kernel: Code: 83 c3 2c 89 d8 e8 a5 ea 13 c8 8b
4d e8 83 79 04 01 75 2e 8b 55 e4 8b 82 d4 02 00 00 85 c0 74 0f 8b 4d e0
3b 81 e0 00 00 00 74 16 <0f> 0b eb fe 8b 55 e0 8b 4d e4 8b 82 e0 00 00
00 89 81 d4 02 00
Mar 21 12:17:51 localhost kernel: EIP: [<f85a7471>] drm_open+0x442/0x48d
[drm] SS:ESP 0068:f4570e40
Mar 21 12:17:51 localhost kernel: ---[ end trace ebf0ba7e33809de9 ]---
On Sat, 2009-03-21 at 12:27 -0700, Fernando Lopez-Lezcano wrote:
> On Sat, 2009-03-21 at 12:06 -0700, Fernando Lopez-Lezcano wrote:
> > On Sat, 2009-03-21 at 19:49 +0100, Ingo Molnar wrote:
> > > * Fernando Lopez-Lezcano <[email protected]> wrote:
> > >
> > > > Mar 21 10:47:43 localhost kernel: kernel tried to execute NX-protected
> > > > page - exploit attempt? (uid: 0)
> > > > Mar 21 10:47:43 localhost kernel: BUG: unable to handle kernel paging
> > > > request at f6400800
> > >
> > > kernel tried to execute some really weird address, probably via a
> > > function pointer.
> >
> > Strangely enough rc8-rt1 boots (almost). _Exact_ same build with the
> > exception of the change from rt1 -> rt2.
> >
> > Haldaemon does not start on boot (fails), if I login as root and start
> > the haldaemon service manually it starts. And then things seem to work
> > fine (I'm writing this email from that machine). Still investigating...
>
> First problem was due to old firmware for the iwl3945 hardware. I
> updated to the latest and hal started fine (this is on fc9).
>
> Now another one related to xorg/drm...
Scratch that, I had an old version of xorg/drm installed in this
particular machine and the new kernel did not like it. Seems to boot
fine now... sorry for the noise.
-- Fernando
* Fernando Lopez-Lezcano <[email protected]> wrote:
> On Sat, 2009-03-21 at 12:27 -0700, Fernando Lopez-Lezcano wrote:
> > On Sat, 2009-03-21 at 12:06 -0700, Fernando Lopez-Lezcano wrote:
> > > On Sat, 2009-03-21 at 19:49 +0100, Ingo Molnar wrote:
> > > > * Fernando Lopez-Lezcano <[email protected]> wrote:
> > > >
> > > > > Mar 21 10:47:43 localhost kernel: kernel tried to execute NX-protected
> > > > > page - exploit attempt? (uid: 0)
> > > > > Mar 21 10:47:43 localhost kernel: BUG: unable to handle kernel paging
> > > > > request at f6400800
> > > >
> > > > kernel tried to execute some really weird address, probably via a
> > > > function pointer.
> > >
> > > Strangely enough rc8-rt1 boots (almost). _Exact_ same build with the
> > > exception of the change from rt1 -> rt2.
> > >
> > > Haldaemon does not start on boot (fails), if I login as root and start
> > > the haldaemon service manually it starts. And then things seem to work
> > > fine (I'm writing this email from that machine). Still investigating...
> >
> > First problem was due to old firmware for the iwl3945 hardware. I
> > updated to the latest and hal started fine (this is on fc9).
> >
> > Now another one related to xorg/drm...
>
> Scratch that, I had an old version of xorg/drm installed in this
> particular machine and the new kernel did not like it. Seems to
> boot fine now... sorry for the noise.
No problem :-)
I'm wondering, do you have any theory about how the old firmware
cause that weird NX-fault kernel crash? For a few minutes i took it
for an x86 crash.
Ingo
On Sun, 2009-03-22 at 14:09 +0100, Ingo Molnar wrote:
> * Fernando Lopez-Lezcano <[email protected]> wrote:
>
> > On Sat, 2009-03-21 at 12:27 -0700, Fernando Lopez-Lezcano wrote:
> > > On Sat, 2009-03-21 at 12:06 -0700, Fernando Lopez-Lezcano wrote:
> > > > On Sat, 2009-03-21 at 19:49 +0100, Ingo Molnar wrote:
> > > > > * Fernando Lopez-Lezcano <[email protected]> wrote:
> > > > >
> > > > > > Mar 21 10:47:43 localhost kernel: kernel tried to execute NX-protected
> > > > > > page - exploit attempt? (uid: 0)
> > > > > > Mar 21 10:47:43 localhost kernel: BUG: unable to handle kernel paging
> > > > > > request at f6400800
> > > > >
> > > > > kernel tried to execute some really weird address, probably via a
> > > > > function pointer.
> > > >
> > > > Strangely enough rc8-rt1 boots (almost). _Exact_ same build with the
> > > > exception of the change from rt1 -> rt2.
> > > >
> > > > Haldaemon does not start on boot (fails), if I login as root and start
> > > > the haldaemon service manually it starts. And then things seem to work
> > > > fine (I'm writing this email from that machine). Still investigating...
> > >
> > > First problem was due to old firmware for the iwl3945 hardware. I
> > > updated to the latest and hal started fine (this is on fc9).
> > >
> > > Now another one related to xorg/drm...
> >
> > Scratch that, I had an old version of xorg/drm installed in this
> > particular machine and the new kernel did not like it. Seems to
> > boot fine now... sorry for the noise.
>
> No problem :-)
>
> I'm wondering, do you have any theory about how the old firmware
> cause that weird NX-fault kernel crash? For a few minutes i took it
> for an x86 crash.
Sorry, no theories at all - I would have to be a kernel guru for that. I
was surprised the whole thing went away with the firmware upgrade (I saw
some message in /var/log/messages telling me the firmware was old) - it
did seem like something more serious.
I hit another problem. On a quad code intel machine here at home there
is a problem during shutdown. The final shutdown dies with a traceback
(something like "rc0 was killed by SIGSEGV" or similar words at the very
end). Then I have to push the power button for x+ seconds to force a
power off.
Should I post a picture of the screen as it is at that point, or just
send that to you and Thomas?
-- Fernando
* Fernando Lopez-Lezcano <[email protected]> wrote:
> On Sun, 2009-03-22 at 14:09 +0100, Ingo Molnar wrote:
> > * Fernando Lopez-Lezcano <[email protected]> wrote:
> >
> > > On Sat, 2009-03-21 at 12:27 -0700, Fernando Lopez-Lezcano wrote:
> > > > On Sat, 2009-03-21 at 12:06 -0700, Fernando Lopez-Lezcano wrote:
> > > > > On Sat, 2009-03-21 at 19:49 +0100, Ingo Molnar wrote:
> > > > > > * Fernando Lopez-Lezcano <[email protected]> wrote:
> > > > > >
> > > > > > > Mar 21 10:47:43 localhost kernel: kernel tried to execute NX-protected
> > > > > > > page - exploit attempt? (uid: 0)
> > > > > > > Mar 21 10:47:43 localhost kernel: BUG: unable to handle kernel paging
> > > > > > > request at f6400800
> > > > > >
> > > > > > kernel tried to execute some really weird address, probably via a
> > > > > > function pointer.
> > > > >
> > > > > Strangely enough rc8-rt1 boots (almost). _Exact_ same build with the
> > > > > exception of the change from rt1 -> rt2.
> > > > >
> > > > > Haldaemon does not start on boot (fails), if I login as root and start
> > > > > the haldaemon service manually it starts. And then things seem to work
> > > > > fine (I'm writing this email from that machine). Still investigating...
> > > >
> > > > First problem was due to old firmware for the iwl3945 hardware. I
> > > > updated to the latest and hal started fine (this is on fc9).
> > > >
> > > > Now another one related to xorg/drm...
> > >
> > > Scratch that, I had an old version of xorg/drm installed in this
> > > particular machine and the new kernel did not like it. Seems to
> > > boot fine now... sorry for the noise.
> >
> > No problem :-)
> >
> > I'm wondering, do you have any theory about how the old firmware
> > cause that weird NX-fault kernel crash? For a few minutes i took it
> > for an x86 crash.
>
> Sorry, no theories at all - I would have to be a kernel guru for that. I
> was surprised the whole thing went away with the firmware upgrade (I saw
> some message in /var/log/messages telling me the firmware was old) - it
> did seem like something more serious.
>
> I hit another problem. On a quad code intel machine here at home there
> is a problem during shutdown. The final shutdown dies with a traceback
> (something like "rc0 was killed by SIGSEGV" or similar words at the very
> end). Then I have to push the power button for x+ seconds to force a
> power off.
>
> Should I post a picture of the screen as it is at that point, or just
> send that to you and Thomas?
any kernel stack dump in that?
You could try to do this before shutting down:
echo 1 > /proc/sys/kernel/print-fatal-signals
dmesg -n 8
that way there's a (hopefully helpful) stack dump done of the
SIGSEGV itself.
Ingo
We are pleased to announce the next update to our new preempt-rt
series.
- fix a x86 32bit PAE pagetable corruption caused by a hard to
trigger race.
- update to latest linus and tip
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.29-rc8-rt3 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.29-rc8.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29-rc8-rt3.bz2
The broken out patches are also available at the same download
locations.
Enjoy !
tglx
On Mon, 2009-03-23 at 09:07 +0100, Ingo Molnar wrote:
> * Fernando Lopez-Lezcano <[email protected]> wrote:
> > On Sun, 2009-03-22 at 14:09 +0100, Ingo Molnar wrote:
> > > * Fernando Lopez-Lezcano <[email protected]> wrote:
> > I hit another problem. On a quad code intel machine here at home there
> > is a problem during shutdown. The final shutdown dies with a traceback
> > (something like "rc0 was killed by SIGSEGV" or similar words at the very
> > end). Then I have to push the power button for x+ seconds to force a
> > power off.
> >
> > Should I post a picture of the screen as it is at that point, or just
> > send that to you and Thomas?
>
> any kernel stack dump in that?
The tail end of it.
(still happening in rc8-rt4)
> You could try to do this before shutting down:
>
> echo 1 > /proc/sys/kernel/print-fatal-signals
> dmesg -n 8
>
> that way there's a (hopefully helpful) stack dump done of the
> SIGSEGV itself.
without all the funny numbers this is what remains on screen:
native_cpu_die
_cpu_down
disable_nonboot_cpus
kernel_power_off
sys_reboot
__hrtimer_start_range_ns
default_spin_lock_flags
__spin_lock_irqsave
__spin_lock_irqrestore
hrtimer_try_to_cancel
hrtimer_cancel
do_nanosleep
hrtimer_nanosleep
hrtimer_wakeup
path_put
audit_syscall_entry
audit_syscall_exit
sysenter_do_call
Code: 00 00 6a 00 ff 15 08 49 85 c0 58 etc etc etc
EIP [<c06f2549>] text_poke+0x163/0x181 SS:ESP 0068:f4567ddc
-- [end trace db3e80122adba82c ]---
init: rc0 main process (3047) killed by SEGV signal
(I can take a picture if that would help - I don't have a second machine
with a serial port to try to capture the whole thing)
BTW, the hard disk powers down and everything else seems to complete.
-- Fernando
On Mon, 23 Mar 2009, Fernando Lopez-Lezcano wrote:
> without all the funny numbers this is what remains on screen:
>
> native_cpu_die
> _cpu_down
> disable_nonboot_cpus
> kernel_power_off
> sys_reboot
> __hrtimer_start_range_ns
> default_spin_lock_flags
> __spin_lock_irqsave
> __spin_lock_irqrestore
> hrtimer_try_to_cancel
> hrtimer_cancel
> do_nanosleep
> hrtimer_nanosleep
> hrtimer_wakeup
> path_put
> audit_syscall_entry
> audit_syscall_exit
> sysenter_do_call
> Code: 00 00 6a 00 ff 15 08 49 85 c0 58 etc etc etc
> EIP [<c06f2549>] text_poke+0x163/0x181 SS:ESP 0068:f4567ddc
Hmm. Do you have CONFIG_HAVE_DYNAMIC_FTRACE=y in your config ? If yes,
can you please disable it ?
> -- [end trace db3e80122adba82c ]---
> init: rc0 main process (3047) killed by SEGV signal
>
> (I can take a picture if that would help - I don't have a second machine
> with a serial port to try to capture the whole thing)
That'd be very helpful.
Thanks,
tglx
On Tue, 24 Mar 2009, Thomas Gleixner wrote:
> On Mon, 23 Mar 2009, Fernando Lopez-Lezcano wrote:
> > without all the funny numbers this is what remains on screen:
> >
> > native_cpu_die
> > _cpu_down
> > disable_nonboot_cpus
> > kernel_power_off
> > sys_reboot
> > __hrtimer_start_range_ns
> > default_spin_lock_flags
> > __spin_lock_irqsave
> > __spin_lock_irqrestore
> > hrtimer_try_to_cancel
> > hrtimer_cancel
> > do_nanosleep
> > hrtimer_nanosleep
> > hrtimer_wakeup
> > path_put
> > audit_syscall_entry
> > audit_syscall_exit
> > sysenter_do_call
> > Code: 00 00 6a 00 ff 15 08 49 85 c0 58 etc etc etc
> > EIP [<c06f2549>] text_poke+0x163/0x181 SS:ESP 0068:f4567ddc
>
> Hmm. Do you have CONFIG_HAVE_DYNAMIC_FTRACE=y in your config ? If yes,
CONFIG_DYNAMIC_FTRACE=y of course.
> can you please disable it ?
>
> > -- [end trace db3e80122adba82c ]---
> > init: rc0 main process (3047) killed by SEGV signal
> >
> > (I can take a picture if that would help - I don't have a second machine
> > with a serial port to try to capture the whole thing)
>
> That'd be very helpful.
>
> Thanks,
>
> tglx
>
On Mon, Mar 23, 2009 at 05:26:52PM +0100, Thomas Gleixner wrote:
> We are pleased to announce the next update to our new preempt-rt
> series.
>
> - fix a x86 32bit PAE pagetable corruption caused by a hard to
> trigger race.
>
> - update to latest linus and tip
>
> Download locations:
>
> http://rt.et.redhat.com/download/
> http://www.kernel.org/pub/linux/kernel/projects/rt/
>
> Information on the RT patch can be found at:
>
> http://rt.wiki.kernel.org/index.php/Main_Page
>
> to build the 2.6.29-rc8-rt3 tree, the following patches should be
> applied:
>
> http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.29-rc8.tar.bz2
> http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29-rc8-rt3.bz2
Hi,
It doesn't seem to be available (404).
But I can see a 2.6.29-rc8-rt4.bz2 downloadable.
Thanks.
> The broken out patches are also available at the same download
> locations.
>
> Enjoy !
>
> tglx
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi,
> > http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.29-rc8.tar.bz2
> > http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29-rc8-rt3.bz2
>
>
> Hi,
>
> It doesn't seem to be available (404).
> But I can see a 2.6.29-rc8-rt4.bz2 downloadable.
>
> Thanks.
This is a channel log from #linux-rt
19:57 < clark|w> tglx, just how small was the -rt3 window (which I hit btw)?
19:58 < tglx> you mean how long -rt3 was up on the web ?
19:58 < clark|w> yeah
19:58 < tglx> half an hour or so
19:59 < clark|w> because I got it, built/booted it (64-bit) and was running it
up til thismorning when I saw that you'd released -rt4 :)
19:59 < tglx> 64bit was fine
19:59 < tglx> I fixed a 32bit PAE bug in -rt2 and when I pushed out -rt3 I did
not notice that half of the fix was lost
20:00 < tglx> so I zapped it and pushed out rt4
20:00 < clark|w> cool
20:00 < clark|w> good think I'm 64bit clean :)
20:00 < tglx> but I was too tired to send out another mail
Just FYI
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
On Tue, 2009-03-24 at 09:12 +0100, Thomas Gleixner wrote:
> On Tue, 24 Mar 2009, Thomas Gleixner wrote:
>
> > On Mon, 23 Mar 2009, Fernando Lopez-Lezcano wrote:
> > > without all the funny numbers this is what remains on screen:
> > >
> > > native_cpu_die
> > > _cpu_down
> > > disable_nonboot_cpus
> > > kernel_power_off
> > > sys_reboot
> > > __hrtimer_start_range_ns
> > > default_spin_lock_flags
> > > __spin_lock_irqsave
> > > __spin_lock_irqrestore
> > > hrtimer_try_to_cancel
> > > hrtimer_cancel
> > > do_nanosleep
> > > hrtimer_nanosleep
> > > hrtimer_wakeup
> > > path_put
> > > audit_syscall_entry
> > > audit_syscall_exit
> > > sysenter_do_call
> > > Code: 00 00 6a 00 ff 15 08 49 85 c0 58 etc etc etc
> > > EIP [<c06f2549>] text_poke+0x163/0x181 SS:ESP 0068:f4567ddc
> >
> > Hmm. Do you have CONFIG_HAVE_DYNAMIC_FTRACE=y in your config ? If yes,
>
> CONFIG_DYNAMIC_FTRACE=y of course.
>
> > can you please disable it ?
First try failed, something else must be requiring it...
> > > -- [end trace db3e80122adba82c ]---
> > > init: rc0 main process (3047) killed by SEGV signal
> > >
> > > (I can take a picture if that would help - I don't have a second machine
> > > with a serial port to try to capture the whole thing)
> >
> > That'd be very helpful.
Snapshot attached... (on my t61 laptop)
-- Fernando
On Wed, 25 Mar 2009, Fernando Lopez-Lezcano wrote:
> > >
> > > That'd be very helpful.
>
> Snapshot attached... (on my t61 laptop)
The crash happens in alternatives_smp_switch(). Can you check whether
adding "noreplace-smp" to the kernel command line helps ? I boot your
config on my own T61. Hopefully I can reproduce.
Thanks,
tglx
* Thomas Gleixner <[email protected]> wrote:
> On Wed, 25 Mar 2009, Fernando Lopez-Lezcano wrote:
> > > >
> > > > That'd be very helpful.
> >
> > Snapshot attached... (on my t61 laptop)
>
> The crash happens in alternatives_smp_switch(). Can you check
> whether adding "noreplace-smp" to the kernel command line helps ?
> I boot your config on my own T61. Hopefully I can reproduce.
>
> Thanks,
candidate bad commits would be:
f80d2d7: tracing, Text Edit Lock: Fix one sparse warning in kernel/extable.c
505f2b9: tracing, Text Edit Lock - kprobes architecture independent support, nommu fix
3945dab: tracing, Text Edit Lock - SMP alternatives support
4460fda: tracing, Text Edit Lock - kprobes architecture independent support
0e39ac4: tracing, Text Edit Lock - Architecture Independent Code
Ingo
On Wed, 2009-03-25 at 08:27 +0100, Thomas Gleixner wrote:
> On Wed, 25 Mar 2009, Fernando Lopez-Lezcano wrote:
> > > >
> > > > That'd be very helpful.
> >
> > Snapshot attached... (on my t61 laptop)
>
> The crash happens in alternatives_smp_switch(). Can you check whether
> adding "noreplace-smp" to the kernel command line helps ? I boot your
> config on my own T61. Hopefully I can reproduce.
Booting with noreplace-smp fixes the problem in my case, I can shutdown
with no problems.
-- Fernando
We are pleased to announce the next update to our new preempt-rt
series.
- port forward to 2.6.29 final
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.29-rt1 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.29.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29-rt1.bz2
The broken out patches are also available at the same download
locations.
Enjoy !
tglx
On Wed, 2009-03-25 at 21:59 +0100, Thomas Gleixner wrote:
> We are pleased to announce the next update to our new preempt-rt
> series.
>
> - port forward to 2.6.29 final
>
> Download locations:
>
> http://rt.et.redhat.com/download/
> http://www.kernel.org/pub/linux/kernel/projects/rt/
>
> Information on the RT patch can be found at:
>
> http://rt.wiki.kernel.org/index.php/Main_Page
>
> to build the 2.6.29-rt1 tree, the following patches should be
> applied:
>
> http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.29.tar.bz2
Is this valid ?
--
JSR
On Thu, 26 Mar 2009, Jaswinder Singh Rajput wrote:
> On Wed, 2009-03-25 at 21:59 +0100, Thomas Gleixner wrote:
> > We are pleased to announce the next update to our new preempt-rt
> > series.
> >
> > - port forward to 2.6.29 final
> >
> > Download locations:
> >
> > http://rt.et.redhat.com/download/
> > http://www.kernel.org/pub/linux/kernel/projects/rt/
> >
> > Information on the RT patch can be found at:
> >
> > http://rt.wiki.kernel.org/index.php/Main_Page
> >
> > to build the 2.6.29-rt1 tree, the following patches should be
> > applied:
> >
> > http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.29.tar.bz2
>
> Is this valid ?
If we remove the testing/ it should work better :)
tglx
On Wed, 2009-03-25 at 11:45 -0700, Fernando Lopez-Lezcano wrote:
> On Wed, 2009-03-25 at 08:27 +0100, Thomas Gleixner wrote:
> > On Wed, 25 Mar 2009, Fernando Lopez-Lezcano wrote:
> > > > >
> > > > > That'd be very helpful.
> > >
> > > Snapshot attached... (on my t61 laptop)
> >
> > The crash happens in alternatives_smp_switch(). Can you check whether
> > adding "noreplace-smp" to the kernel command line helps ? I boot your
> > config on my own T61. Hopefully I can reproduce.
>
> Booting with noreplace-smp fixes the problem in my case, I can shutdown
> with no problems.
The problem is still there in 2.6.29-rt1...
Booting it I got this, but not all the time (I'm writing from the T61
having booted successfully...):
Mar 25 20:09:04 localhost kernel: BUG: unable to handle kernel paging
request at f5891000
Mar 25 20:09:04 localhost kernel: IP: [<f5891000>] 0xf5891000
Mar 25 20:09:04 localhost kernel: *pdpt = 0000000000945001 *pde =
80000000358001e3
Mar 25 20:09:04 localhost kernel: Oops: 0011 [#1] PREEMPT SMP
Mar 25 20:09:04 localhost kernel: last sysfs
file: /sys/devices/pci0000:00/0000:00:19.0/irq
Mar 25 20:09:04 localhost kernel: Modules linked in: l2cap sunrpc
ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6
cpufreq_ondemand acpi_cpufreq dm_multipath uinput snd_hda_codec_analog
snd_hda_intel snd_hda_codec snd_hwdep snd_seq_dummy arc4 snd_seq_oss
snd_seq_midi_event ecb snd_seq snd_seq_device thinkpad_acpi iwl3945
snd_pcm_oss snd_mixer_oss snd_pcm rfkill sdhci_pci hwmon btusb snd_timer
mac80211 ohci1394 i2c_i801 snd sdhci ricoh_mmc mmc_core yenta_socket
i2c_core iTCO_wdt rsrc_nonstatic pcspkr video soundcore lib80211 e1000e
snd_page_alloc cfg80211 bluetooth iTCO_vendor_support joydev output
ata_generic pata_acpi [last unloaded: microcode]
Mar 25 20:09:04 localhost kernel:
Mar 25 20:09:04 localhost kernel: Pid: 9, comm: sirq-tasklet/0 Not
tainted (2.6.29-1.rt1.1.fc10.ccrma.i686.rtPAE #1) 6463CTO
Mar 25 20:09:04 localhost kernel: EIP: 0060:[<f5891000>] EFLAGS:
00010246 CPU: 0
Mar 25 20:09:04 localhost kernel: EIP is at 0xf5891000
Mar 25 20:09:04 localhost kernel: EAX: f73c0f20 EBX: 00000000 ECX:
000000ff EDX: f73c18b4
Mar 25 20:09:04 localhost kernel: ESI: f73c0f20 EDI: 000000ff EBP:
f7073f84 ESP: f7073f20
Mar 25 20:09:04 localhost kernel: DS: 007b ES: 007b FS: 00d8 GS: 0000
SS: 0068 preempt:00000001
Mar 25 20:09:04 localhost kernel: Process sirq-tasklet/0 (pid: 9,
ti=f7073000 task=f7088e40 task.ti=f7073000)
Mar 25 20:09:04 localhost kernel: Stack:
Mar 25 20:09:04 localhost kernel: f8357bde f73c1494 00000000 00010000
00000008 00000005 00000000 00000000
Mar 25 20:09:04 localhost kernel: 00000002 f45c0004 f73c18b4 f73c35cc
f73c35d8 345c0004 00000000 f73c37f4
Mar 25 20:09:04 localhost kernel: f73c4f70 f73c1880 fffffffd 80000008
34940004 00000006 f73c5020 f73c5024
Mar 25 20:09:04 localhost kernel: Call Trace:
Mar 25 20:09:04 localhost kernel: [<f8357bde>] ? iwl3945_irq_tasklet
+0x421/0x80f [iwl3945]
Mar 25 20:09:04 localhost kernel: [<c043d707>] ? __tasklet_action
+0x81/0xe4
Mar 25 20:09:04 localhost kernel: [<c043d7ea>] ? tasklet_action
+0x3e/0x42
Mar 25 20:09:04 localhost kernel: [<c043d4e6>] ? ksoftirqd+0x130/0x216
Mar 25 20:09:04 localhost kernel: [<c043d3b6>] ? ksoftirqd+0x0/0x216
Mar 25 20:09:04 localhost kernel: [<c044a18d>] ? kthread+0x3b/0x61
Mar 25 20:09:04 localhost kernel: [<c044a152>] ? kthread+0x0/0x61
Mar 25 20:09:04 localhost kernel: [<c0409267>] ? kernel_thread_helper
+0x7/0x10
Mar 25 20:09:04 localhost kernel: Code: 00 00 00 00 00 00 00 00 00 00 00
fc 00 00 00 24 04 0a b8 73 00 00 00 46 02 00 00 dc e6 c9 bf 7b 00 00 00
00 00 00 00 00 00 00 00 <00> 00 00 00 6c 09 14 00 01 00 00 00 00 00 00
00 06 00 00 00 0f
Mar 25 20:09:04 localhost kernel: EIP: [<f5891000>] 0xf5891000 SS:ESP
0068:f7073f20
Mar 25 20:09:04 localhost kernel: CR2: 00000000f5891000
Mar 25 20:09:04 localhost kernel: ---[ end trace bf9fc42e701e26d1 ]---
-- Fernando
And before that this one, looks even weirder...
I think this was a warm boot from
kernel-PAE-2.6.27.19-170.2.35.fc10.i686
Mar 25 20:02:23 localhost kernel: iwl3945 0000:03:00.0: PCI INT A -> GSI
17 (level, low) -> IRQ 17
Mar 25 20:02:25 localhost kernel: iwl3945: Microcode SW error detected.
Restarting 0x82000008.
Mar 25 20:02:25 localhost kernel: ------------[ cut here ]------------
Mar 25 20:02:25 localhost kernel: kernel BUG at
drivers/net/wireless/iwlwifi/iwl3945-base.c:3352!
Mar 25 20:02:25 localhost kernel: invalid opcode: 0000 [#1] PREEMPT SMP
Mar 25 20:02:25 localhost kernel: last sysfs
file: /sys/devices/pci0000:00/0000:00:19.0/irq
Mar 25 20:02:25 localhost kernel: Modules linked in: sunrpc ip6t_REJECT
nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 cpufreq_ondemand
acpi_cpufreq dm_multipath uinput snd_hda_codec_analog snd_hda_intel
snd_hda_codec snd_hwdep snd_seq_dummy snd_seq_oss snd_seq_midi_event
arc4 snd_seq snd_seq_device ecb sdhci_pci snd_pcm_oss snd_mixer_oss
snd_pcm sdhci thinkpad_acpi hwmon iwl3945 rfkill mac80211 ohci1394
i2c_i801 btusb snd_timer ricoh_mmc mmc_core snd yenta_socket i2c_core
video rsrc_nonstatic pcspkr soundcore lib80211 bluetooth iTCO_wdt e1000e
snd_page_alloc cfg80211 joydev iTCO_vendor_support output ata_generic
pata_acpi [last unloaded: microcode]
Mar 25 20:02:25 localhost kernel:
Mar 25 20:02:25 localhost kernel: Pid: 23, comm: sirq-tasklet/1 Not
tainted (2.6.29-1.rt1.1.fc10.ccrma.i686.rtPAE #1) 6463CTO
Mar 25 20:02:25 localhost kernel: EIP: 0060:[<f832bc52>] EFLAGS:
00010297 CPU: 1
Mar 25 20:02:25 localhost kernel: EIP is at iwl3945_irq_tasklet
+0x495/0x80f [iwl3945]
Mar 25 20:02:25 localhost kernel: EAX: 00000000 EBX: 00000000 ECX:
f44ab380 EDX: f73a0000
Mar 25 20:02:25 localhost kernel: ESI: f73a8f20 EDI: 00000000 EBP:
f70abf84 ESP: f70abf24
Mar 25 20:02:25 localhost kernel: DS: 007b ES: 007b FS: 00d8 GS: 0000
SS: 0068 preempt:00000001
Mar 25 20:02:25 localhost kernel: Process sirq-tasklet/1 (pid: 23,
ti=f70ab000 task=f70bf000 task.ti=f70ab000)
Mar 25 20:02:25 localhost kernel: Stack:
Mar 25 20:02:25 localhost kernel: f73a9494 02000000 00010000 00000008
00000005 00000001 00000000 00000003
Mar 25 20:02:25 localhost kernel: f44bb004 f73a98b4 f73ab5cc f73ab5d8
344bb004 00000000 f73ab7f4 f73acf70
Mar 25 20:02:25 localhost kernel: f73a9880 00000000 82000008 349ad004
00000006 f73ad020 f73ad024 000f4240
Mar 25 20:02:25 localhost kernel: Call Trace:
Mar 25 20:02:25 localhost kernel: [<c043d707>] ? __tasklet_action
+0x81/0xe4
Mar 25 20:02:25 localhost kernel: [<c043d7ea>] ? tasklet_action
+0x3e/0x42
Mar 25 20:02:25 localhost kernel: [<c043d4e6>] ? ksoftirqd+0x130/0x216
Mar 25 20:02:25 localhost kernel: [<c043d3b6>] ? ksoftirqd+0x0/0x216
Mar 25 20:02:25 localhost kernel: [<c044a18d>] ? kthread+0x3b/0x61
Mar 25 20:02:25 localhost kernel: [<c044a152>] ? kthread+0x0/0x61
Mar 25 20:02:25 localhost kernel: [<c0409267>] ? kernel_thread_helper
+0x7/0x10
Mar 25 20:02:25 localhost kernel: Code: 0f 84 44 01 00 00 8b 45 c4 8b 48
08 85 c9 0f 84 2b 01 00 00 8b 81 ac 00 00 00 66 8b 50 06 0f b6 c6 25 bf
00 00 00 83 f8 04 74 04 <0f> 0b eb fe 88 55 e7 80 e6 40 8b 86 e8 27 00
00 75 04 48 22 45
Mar 25 20:02:25 localhost kernel: EIP: [<f832bc52>] iwl3945_irq_tasklet
+0x495/0x80f [iwl3945] SS:ESP 0068:f70abf24
Mar 25 20:02:25 localhost kernel: ---[ end trace 173bbf32758a5321 ]---
Hi,
I understood statement that Thosmas explained about invalid access of
2.6.29-rt1 soruces.
In general,
We remeber rc directory (./v2.6/testing/ and release directory
(./v2.6/) certainly.
Release Version is located in http://www.kernel.org/pub/linux/kernel/v2.6/ site.
RC Version is located in
http://www.kernel.org/pub/linux/kernel/v2.6/testing/ site.
I summarized quick howto per notice of "2.6.* rt patch" file.
fc9#> wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.tar.bz2
(If linux version is RC[release candidate] version,
use "wget http://www.kernel.org/pub/linux/kernel/v2.6/testing/***" command.)
fc9#> wget http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29-rt1.bz2
fc9#> tar xjf ./linux-2.6.29.tar.bz2
fc9#> tar xvjf ./patch-2.6.29-rt1-broken-out.tar.bz2
fc9#> cd ./linux-2.6.29
fc9#> for i in `cat ../patches/series | grep patch | grep -v "#" `;do
echo "+++ patching $i"; patch -p1 <
../patches/$i;done
fc9#> cp ./arch/x86/configs/i386_defconfig ./.config
fc9#> make menuconfig
..... Below Omission .....
Regards,
GeunSik Lim
2009/3/26 Thomas Gleixner <[email protected]>:
> On Thu, 26 Mar 2009, Jaswinder Singh Rajput wrote:
>
>> On Wed, 2009-03-25 at 21:59 +0100, Thomas Gleixner wrote:
>> > We are pleased to announce the next update to our new preempt-rt
>> > series.
>> >
>> > - port forward to 2.6.29 final
>> >
>> > Download locations:
>> >
>> > http://rt.et.redhat.com/download/
>> > http://www.kernel.org/pub/linux/kernel/projects/rt/
>> >
>> > Information on the RT patch can be found at:
>> >
>> > http://rt.wiki.kernel.org/index.php/Main_Page
>> >
>> > to build the 2.6.29-rt1 tree, the following patches should be
>> > applied:
>> >
>> > http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.29.tar.bz2
>>
>> Is this valid ?
>
> If we remove the testing/ it should work better :)
>
> tglx
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Regards,
GeunSik Lim
Hi,
I understood statement that Thosmas explained about invalid access of
2.6.29-rt1 soruces.
In general,
We remeber rc directory (./v2.6/testing/ and release directory
(./v2.6/) certainly.
Release Version is located in http://www.kernel.org/pub/linux/kernel/v2.6/ site.
RC Version is located in
http://www.kernel.org/pub/linux/kernel/v2.6/testing/ site.
I summarized quick howto per notice of "2.6.* rt patch" file.
fc9#> wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.tar.bz2
(If linux version is RC[release candidate] version,
use "wget http://www.kernel.org/pub/linux/kernel/v2.6/testing/***" command.)
fc9#> wget http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29-rt1.bz2
fc9#> tar xjf ./linux-2.6.29.tar.bz2
fc9#> tar xvjf ./patch-2.6.29-rt1-broken-out.tar.bz2
fc9#> cd ./linux-2.6.29
fc9#> for i in `cat ../patches/series | grep patch | grep -v "#" `;do
echo "+++ patching $i"; patch -p1 <
../patches/$i;done
fc9#> cp ./arch/x86/configs/i386_defconfig ./.config
fc9#> make menuconfig
..... Below Omission .....
Regards,
GeunSik Lim
2009/3/26 Thomas Gleixner <[email protected]>:
> On Thu, 26 Mar 2009, Jaswinder Singh Rajput wrote:
>
>> On Wed, 2009-03-25 at 21:59 +0100, Thomas Gleixner wrote:
>> > We are pleased to announce the next update to our new preempt-rt
>> > series.
>> >
>> > - port forward to 2.6.29 final
>> >
>> > Download locations:
>> >
>> > http://rt.et.redhat.com/download/
>> > http://www.kernel.org/pub/linux/kernel/projects/rt/
>> >
>> > Information on the RT patch can be found at:
>> >
>> > http://rt.wiki.kernel.org/index.php/Main_Page
>> >
>> > to build the 2.6.29-rt1 tree, the following patches should be
>> > applied:
>> >
>> > http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.29.tar.bz2
>>
>> Is this valid ?
>
> If we remove the testing/ it should work better :)
>
> tglx
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Hi,
I understood statement that Thosmas explained about invalid access of
2.6.29-rt1 soruces.
In general,
We remeber rc directory (./v2.6/testing/ and release directory
(./v2.6/) certainly.
Release Version is located in http://www.kernel.org/pub/linux/kernel/v2.6/ site.
RC Version is located in
http://www.kernel.org/pub/linux/kernel/v2.6/testing/ site.
I summarized quick howto per notice of "2.6.* rt patch" file.
fc9#> wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.tar.bz2
(If linux version is RC[release candidate] version,
use "wget http://www.kernel.org/pub/linux/kernel/v2.6/testing/***" command.)
fc9#> wget http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29-rt1.bz2
fc9#> tar xjf ./linux-2.6.29.tar.bz2
fc9#> tar xvjf ./patch-2.6.29-rt1-broken-out.tar.bz2
fc9#> cd ./linux-2.6.29
fc9#> for i in `cat ../patches/series | grep patch | grep -v "#" `;do
echo "+++ patching $i"; patch -p1 <
../patches/$i;done
fc9#> cp ./arch/x86/configs/i386_defconfig ./.config
fc9#> make menuconfig
..... Below Omission .....
Regards,
GeunSik Lim
----- Original Message -----
From: "Thomas Gleixner" <[email protected]>
To: "Jaswinder Singh Rajput" <[email protected]>
Cc: "LKML" <[email protected]>; "rt-users"
<[email protected]>; "Ingo Molnar" <[email protected]>;
"Steven Rostedt" <[email protected]>; "Peter Zijlstra"
<[email protected]>; "Carsten Emde" <[email protected]>; "Clark Williams"
<[email protected]>; "Frank Rowand" <[email protected]>
Sent: Thursday, March 26, 2009 6:09 AM
Subject: Re: [Announce] 2.6.29-rt1
> On Thu, 26 Mar 2009, Jaswinder Singh Rajput wrote:
>
>> On Wed, 2009-03-25 at 21:59 +0100, Thomas Gleixner wrote:
>> > We are pleased to announce the next update to our new preempt-rt
>> > series.
>> >
>> > - port forward to 2.6.29 final
>> >
>> > Download locations:
>> >
>> > http://rt.et.redhat.com/download/
>> > http://www.kernel.org/pub/linux/kernel/projects/rt/
>> >
>> > Information on the RT patch can be found at:
>> >
>> > http://rt.wiki.kernel.org/index.php/Main_Page
>> >
>> > to build the 2.6.29-rt1 tree, the following patches should be
>> > applied:
>> >
>> > http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.29.tar.bz2
>>
>> Is this valid ?
>
> If we remove the testing/ it should work better :)
>
> tglx
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
>
>
Hi
I've got crashes when I run an app with thread with RT priority.
This crash could happen on any comman, here some log of crashes :
First one :
server calling Oops: Exception in kernel mode, sig: 5 [#1]
PREEMPT MPC837x RR605
Modules linked in:
NIP: c0075b08 LR: c0075a50 CTR: c00d7d90
REGS: dbb6dcb0 TRAP: 0700 Not tainted (2.6.29-rt1)
MSR: 00029032 <EE,ME,CE,IR,DR> CR: 24002488 XER: 00000000
TASK = dddea1e0[1769] 'vsftpd' THREAD: dbb6c000
GPR00: 00000001 dbb6dd60 dddea1e0 df803e24 df803e10 df803e08 00000000
ddc72020
GPR08: 00000000 0000001b dddea1e0 df803e24 24000482 100bf094 00000000
c04aa6fc
GPR16: 00200200 00100100 c04e5958 c04e595c dbb6dd68 c04e0000 c04e0000
c04aa6bc
GPR24: 00000020 dbb6ddd8 00000010 df80ae00 00000000 dbb6de38 df816800
df803e00
NIP [c0075b08] cache_alloc_refill+0x180/0x62c
LR [c0075a50] cache_alloc_refill+0xc8/0x62c
Call Trace:
[dbb6dd60] [c038878c] preempt_schedule_irq+0x5c/0x80 (unreliable)
[dbb6ddd0] [c00761a0] kmem_cache_alloc+0x6c/0x140
[dbb6de00] [c002ddb4] __sigqueue_do_alloc+0xa0/0xec
[dbb6de10] [c002e2f8] send_signal+0xa4/0x224
[dbb6de30] [c002f680] do_notify_parent+0x1a8/0x1d4
[dbb6ded0] [c0025608] do_exit+0x584/0x69c
[dbb6df10] [c00257a0] do_group_exit+0x80/0xac
[dbb6df30] [c00257e0] sys_exit_group+0x14/0x28
[dbb6df40] [c00117f4] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xfef463c
LR = 0xffa5884
Instruction dump:
7f87f800 40be0018 80ff0010 38000001 901f0048 7f872000 419e00e8 80070010
813b001c 7c090010 38000000 7c000114 <0f000000> 381a0001 38c7001c 7c0903a6
---[ end trace 99200bd45c29aa91 ]---
Fixing recursive fault but reboot is needed!
Second one :
I've run my app, and after just run a simple "ifconfig"
-sh-2.05b# ifconfig
eth0 Link eOops: Exception in kernel mode, sig: 5 [#1]
PREEMPT MPC837x RR605
Modules linked in:
NIP: c0075b08 LR: c0075a50 CTR: c02cf170
REGS: dab41cb0 TRAP: 0700 Not tainted (2.6.29-rt1)
MSR: 00029032 <EE,ME,CE,IR,DR> CR: 24002488 XER: 00000000
TASK = df8be100[1756] 'ifconfig' THREAD: dab40000
GPR00: 00000001 dab41d60 df8be100 df803e24 df803e10 df803e08 00000000
dddcc000
GPR08: 00000000 0000001b df8be100 df803e24 24000482 10023370 00000000
c04aa6fc
GPR16: 00200200 00100100 c04e5958 c04e595c dab41d68 c04e0000 c04e0000
c04aa6bc
GPR24: 00000020 dab41dd8 00000010 df80ae00 00000000 dab41e38 df816800
df803e00
NIP [c0075b08] cache_alloc_refill+0x180/0x62c
LR [c0075a50] cache_alloc_refill+0xc8/0x62c
Call Trace:
[dab41d60] [00000001] 0x1 (unreliable)
[dab41dd0] [c00761a0] kmem_cache_alloc+0x6c/0x140
[dab41e00] [c002ddb4] __sigqueue_do_alloc+0xa0/0xec
[dab41e10] [c002e2f8] send_signal+0xa4/0x224
[dab41e30] [c002f680] do_notify_parent+0x1a8/0x1d4
[dab41ed0] [c0025608] do_exit+0x584/0x69c
[dab41f10] [c00257a0] do_group_exit+0x80/0xac
[dab41f30] [c00257e0] sys_exit_group+0x14/0x28
[dab41f40] [c00117f4] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xff3b63c
LR = 0xffec884
Instruction dump:
7f87f800 40be0018 80ff0010 38000001 901f0048 7f872000 419e00e8 80070010
813b001c 7c090010 38000000 7c000114 <0f000000> 381a0001 38c7001c 7c0903a6
---[ end trace f43c24570097662c ]---
Fixing recursive fault but reboot is needed!
The kernel is a 2.6.29-rt1 compiled with ltib for powerpc (mpc8377E).
Philippe
Le Thu, 26 Mar 2009 19:54:25 +0900, GeunSik Lim a écrit :
> Hi,
>
> I understood statement that Thosmas explained about invalid access of
> 2.6.29-rt1 soruces.
> In general,
> We remeber rc directory (./v2.6/testing/ and release directory (./v2.6/)
> certainly.
>
> Release Version is located in
> http://www.kernel.org/pub/linux/kernel/v2.6/ site. RC Version is
> located in
> http://www.kernel.org/pub/linux/kernel/v2.6/testing/ site.
>
> I summarized quick howto per notice of "2.6.* rt patch" file. fc9#> wget
> http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.tar.bz2
> (If linux version is RC[release candidate] version,
> use "wget http://www.kernel.org/pub/linux/kernel/v2.6/testing/***"
> command.)
> fc9#> wget
> http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29-rt1.bz2
> fc9#> tar xjf ./linux-2.6.29.tar.bz2
> fc9#> tar xvjf ./patch-2.6.29-rt1-broken-out.tar.bz2 fc9#> cd
> ./linux-2.6.29
> fc9#> for i in `cat ../patches/series | grep patch | grep -v "#" `;do
> echo "+++ patching $i"; patch -p1 <
>
> ../patches/$i;done
> fc9#> cp ./arch/x86/configs/i386_defconfig ./.config fc9#> make
> menuconfig
> ..... Below Omission .....
>
>
> Regards,
> GeunSik Lim
>
> ----- Original Message -----
> From: "Thomas Gleixner" <[email protected]> To: "Jaswinder Singh
> Rajput" <[email protected]> Cc: "LKML"
> <[email protected]>; "rt-users"
> <[email protected]>; "Ingo Molnar" <[email protected]>; "Steven
> Rostedt" <[email protected]>; "Peter Zijlstra" <[email protected]>;
> "Carsten Emde" <[email protected]>; "Clark Williams" <[email protected]>;
> "Frank Rowand" <[email protected]> Sent: Thursday, March 26, 2009
> 6:09 AM Subject: Re: [Announce] 2.6.29-rt1
>
>
>> On Thu, 26 Mar 2009, Jaswinder Singh Rajput wrote:
>>
>>> On Wed, 2009-03-25 at 21:59 +0100, Thomas Gleixner wrote:
>>> > We are pleased to announce the next update to our new preempt-rt
>>> > series.
>>> >
>>> > - port forward to 2.6.29 final
>>> >
>>> > Download locations:
>>> >
>>> > http://rt.et.redhat.com/download/
>>> > http://www.kernel.org/pub/linux/kernel/projects/rt/
>>> >
>>> > Information on the RT patch can be found at:
>>> >
>>> > http://rt.wiki.kernel.org/index.php/Main_Page
>>> >
>>> > to build the 2.6.29-rt1 tree, the following patches should be
>>> > applied:
>>> >
>>> > http://www.kernel.org/pub/linux/kernel/v2.6/testing/
linux-2.6.29.tar.bz2
>>>
>>> Is this valid ?
>>
>> If we remove the testing/ it should work better :)
>>
>> tglx
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
>> in the body of a message to [email protected] More majordomo
>> info at http://vger.kernel.org/majordomo-info.html Please read the FAQ
>> at http://www.tux.org/lkml/
>>
>>
>>
>>
On Fri, 27 Mar 2009, Philippe Reynes wrote:
> Hi all
>
> I've tried to remove the mlockall(MCL_CURRENT|MCL_FUTURE)
> and now, the kernel don't crash. But a data corruption
> appear in the data saved by the application. Such corruption
> never occurs with other kernel (2.6.28 and 2.6.29). I'll
> investigate if it could be an application bug.
I don't think that mlockall or the application is the culprit. The bug
happens in the middle of the slab cache code.
> > server calling Oops: Exception in kernel mode, sig: 5 [#1] PREEMPT
> > MPC837x RR605
> > Modules linked in:
> > NIP: c0075b08 LR: c0075a50 CTR: c00d7d90 REGS: dbb6dcb0 TRAP: 0700 Not
> > tainted (2.6.29-rt1) MSR: 00029032 <EE,ME,CE,IR,DR> CR: 24002488 XER:
> > 00000000 TASK = dddea1e0[1769] 'vsftpd' THREAD: dbb6c000 GPR00: 00000001
> > dbb6dd60 dddea1e0 df803e24 df803e10 df803e08 00000000 ddc72020
> > GPR08: 00000000 0000001b dddea1e0 df803e24 24000482 100bf094 00000000
> > c04aa6fc
> > GPR16: 00200200 00100100 c04e5958 c04e595c dbb6dd68 c04e0000 c04e0000
> > c04aa6bc
> > GPR24: 00000020 dbb6ddd8 00000010 df80ae00 00000000 dbb6de38 df816800
> > df803e00
> > NIP [c0075b08] cache_alloc_refill+0x180/0x62c
addr2line -e vmlinux c0075b08
linux-2.6.29/mm/slab.c:3150
That's BUG_ON(slabp->inuse >= cachep->num);
> > LR [c0075a50] cache_alloc_refill+0xc8/0x62c
> > Call Trace:
> > [dbb6dd60] [c038878c] preempt_schedule_irq+0x5c/0x80 (unreliable)
Hmm. This one is interesting. Might be we got preempted here - which
should be fine, but who knows what we missed when we reworked the
locking.
Thanks,
tglx
I've activated ftrace, and I've got this trace :
Oops: Exception in kernel mode, sig: 5 [#1]
PREEMPT MPC837x RR605
Modules linked in:
NIP: c0095fd0 LR: c0095f18 CTR: c03f402c
REGS: ddcb7b50 TRAP: 0700 Not tainted (2.6.29-rt1)
MSR: 00029032 <EE,ME,CE,IR,DR> CR: 24042088 XER: 00000000
TASK = df89c4c0[901] 'IRQ-16' THREAD: ddcb6000
GPR00: 00000001 ddcb7c00 df89c4c0 df803e24 df803e10 df803e08 00000000
ddc8b020
GPR08: 00000000 0000001b df89c4c0 ddcb7c00 4224a620 100a0878 c052bb94
00200200
GPR16: 00100100 c058aed8 c058aedc ddcb7c08 c0590000 c0590000 c052bb54
00000020
GPR24: ddcb7c78 00000010 df80ae00 00000000 df816800 00000000 df803e00
ddcb7c00
NIP [c0095fd0] cache_alloc_refill+0x194/0x644
LR [c0095f18] cache_alloc_refill+0xdc/0x644
Call Trace:
[ddcb7c00] [c0095f18] cache_alloc_refill+0xdc/0x644 (unreliable)
[ddcb7c70] [c009670c] kmem_cache_alloc+0x80/0x1d4
[ddcb7cb0] [c003456c] __sigqueue_do_alloc+0xb0/0xfc
[ddcb7cd0] [c0034b4c] send_signal+0x128/0x2a8
[ddcb7d00] [c00350d0] __group_send_sig_info+0x2c/0x34
[ddcb7d10] [c0035140] group_send_sig_info+0x68/0x84
[ddcb7d40] [c00351c0] __kill_pgrp_info+0x64/0x90
[ddcb7d60] [c003523c] kill_pgrp+0x50/0x68
[ddcb7d80] [c025e808] n_tty_receive_buf+0x420/0xe98
[ddcb7e60] [c0262450] flush_to_ldisc+0x10c/0x188
[ddcb7e90] [c0262520] tty_flip_buffer_push+0x54/0x5c
[ddcb7eb0] [c026a814] serial8250_handle_port+0x27c/0x2ac
[ddcb7ef0] [c026a8ac] serial8250_interrupt+0x68/0xd8
[ddcb7f10] [c0057238] handle_IRQ_event+0xe8/0x1d4
[ddcb7f50] [c0057bec] thread_simple_irq+0x7c/0xd8
[ddcb7f80] [c0057d38] do_irqd+0xf0/0x33c
[ddcb7fd0] [c003fd00] kthread+0x5c/0x8c
[ddcb7ff0] [c00131c0] kernel_thread+0x4c/0x68
Instruction dump:
7f87f000 40be0018 80fe0010 38000001 901e0048 7f872000 419e00e8 80070010
813a001c 7c090010 38000000 7c000114 <0f000000> 38190001 38c7001c 7c0903a6
---[ end trace b6da798bf0ad8dcb ]---
------------[ cut here ]------------
kernel BUG at kernel/rtmutex.c:806!
Oops: Exception in kernel mode, sig: 5 [#2]
PREEMPT MPC837x RR605
Modules linked in:
NIP: c03f3b64 LR: c03f41d0 CTR: c03f3af4
REGS: ddcb7890 TRAP: 0700 Tainted: G D (2.6.29-rt1)
MSR: 00021032 <ME,CE,IR,DR> CR: 84042028 XER: 20000000
TASK = df89c4c0[901] 'IRQ-16' THREAD: ddcb6000
GPR00: 00000001 ddcb7940 df89c4c0 c055e748 00000000 00001032 00000000
00004000
GPR08: df89c4c0 00000001 df89c4c0 ddcb6000 4c592aa0 100a0878 c052bb94
00200200
GPR16: 00100100 c058aed8 c058aedc ddcb7c08 c0590000 c0590000 c052bb54
00000020
GPR24: 00000001 00000010 ddcb7a38 df89c4c0 c055e748 00000005 ddcb6000
ddcb7940
NIP [c03f3b64] rt_spin_lock_slowlock+0x7c/0x284
LR [c03f41d0] __rt_spin_lock+0x7c/0x84
Call Trace:
[ddcb7940] [00001032] 0x1032 (unreliable)
[ddcb79b0] [c03f41d0] __rt_spin_lock+0x7c/0x84
[ddcb79c0] [c03f4440] rt_write_lock+0x28/0x30
[ddcb79d0] [c002a3a4] do_exit+0x208/0x710
[ddcb7a10] [c0010e18] kernel_bad_stack+0x0/0x54
[ddcb7a30] [c0011010] _exception+0x68/0x174
[ddcb7b20] [c0011838] program_check_exception+0x520/0x530
[ddcb7b40] [c00139e8] ret_from_except_full+0x0/0x4c
--- Exception: 700 at cache_alloc_refill+0x194/0x644
LR = cache_alloc_refill+0xdc/0x644
[ddcb7c70] [c009670c] kmem_cache_alloc+0x80/0x1d4
[ddcb7cb0] [c003456c] __sigqueue_do_alloc+0xb0/0xfc
[ddcb7cd0] [c0034b4c] send_signal+0x128/0x2a8
[ddcb7d00] [c00350d0] __group_send_sig_info+0x2c/0x34
[ddcb7d10] [c0035140] group_send_sig_info+0x68/0x84
[ddcb7d40] [c00351c0] __kill_pgrp_info+0x64/0x90
[ddcb7d60] [c003523c] kill_pgrp+0x50/0x68
[ddcb7d80] [c025e808] n_tty_receive_buf+0x420/0xe98
[ddcb7e60] [c0262450] flush_to_ldisc+0x10c/0x188
[ddcb7e90] [c0262520] tty_flip_buffer_push+0x54/0x5c
[ddcb7eb0] [c026a814] serial8250_handle_port+0x27c/0x2ac
[ddcb7ef0] [c026a8ac] serial8250_interrupt+0x68/0xd8
[ddcb7f10] [c0057238] handle_IRQ_event+0xe8/0x1d4
[ddcb7f50] [c0057bec] thread_simple_irq+0x7c/0xd8
[ddcb7f80] [c0057d38] do_irqd+0xf0/0x33c
[ddcb7fd0] [c003fd00] kthread+0x5c/0x8c
[ddcb7ff0] [c00131c0] kernel_thread+0x4c/0x68
Instruction dump:
2f800000 40be0018 39230008 907c0004 907c0000 91290004 91230008 801c0010
5400003a 7c001278 7c000034 5400d97e <0f000000> 81420000 69490002 3129ffff
---[ end trace b6da798bf0ad8dcc ]---
Fixing recursive fault but reboot is needed!
BUG: scheduling while atomic: IRQ-16/0x00000001/901, CPU#0
Modules linked in:
Call Trace:
[ddcb7680] [c000840c] show_stack+0xa4/0x158 (unreliable)
[ddcb76c0] [c00084f0] dump_stack+0x30/0x38
[ddcb76d0] [c00206f0] __schedule_bug+0x6c/0x74
[ddcb76e0] [c03f2050] __schedule+0x68/0x3c4
[ddcb7700] [c03f2668] schedule+0x34/0x54
[ddcb7710] [c002a254] do_exit+0xb8/0x710
[ddcb7750] [c0010e18] kernel_bad_stack+0x0/0x54
[ddcb7770] [c0011010] _exception+0x68/0x174
[ddcb7860] [c0011838] program_check_exception+0x520/0x530
[ddcb7880] [c00139e8] ret_from_except_full+0x0/0x4c
--- Exception: 700 at rt_spin_lock_slowlock+0x7c/0x284
LR = __rt_spin_lock+0x7c/0x84
[ddcb7940] [00001032] 0x1032 (unreliable)
[ddcb79b0] [c03f41d0] __rt_spin_lock+0x7c/0x84
[ddcb79c0] [c03f4440] rt_write_lock+0x28/0x30
[ddcb79d0] [c002a3a4] do_exit+0x208/0x710
[ddcb7a10] [c0010e18] kernel_bad_stack+0x0/0x54
[ddcb7a30] [c0011010] _exception+0x68/0x174
[ddcb7b20] [c0011838] program_check_exception+0x520/0x530
[ddcb7b40] [c00139e8] ret_from_except_full+0x0/0x4c
--- Exception: 700 at cache_alloc_refill+0x194/0x644
LR = cache_alloc_refill+0xdc/0x644
[ddcb7c70] [c009670c] kmem_cache_alloc+0x80/0x1d4
[ddcb7cb0] [c003456c] __sigqueue_do_alloc+0xb0/0xfc
[ddcb7cd0] [c0034b4c] send_signal+0x128/0x2a8
[ddcb7d00] [c00350d0] __group_send_sig_info+0x2c/0x34
[ddcb7d10] [c0035140] group_send_sig_info+0x68/0x84
[ddcb7d40] [c00351c0] __kill_pgrp_info+0x64/0x90
[ddcb7d60] [c003523c] kill_pgrp+0x50/0x68
[ddcb7d80] [c025e808] n_tty_receive_buf+0x420/0xe98
[ddcb7e60] [c0262450] flush_to_ldisc+0x10c/0x188
[ddcb7e90] [c0262520] tty_flip_buffer_push+0x54/0x5c
[ddcb7eb0] [c026a814] serial8250_handle_port+0x27c/0x2ac
[ddcb7ef0] [c026a8ac] serial8250_interrupt+0x68/0xd8
[ddcb7f10] [c0057238] handle_IRQ_event+0xe8/0x1d4
[ddcb7f50] [c0057bec] thread_simple_irq+0x7c/0xd8
[ddcb7f80] [c0057d38] do_irqd+0xf0/0x33c
[ddcb7fd0] [c003fd00] kthread+0x5c/0x8c
[ddcb7ff0] [c00131c0] kernel_thread+0x4c/0x68
Le Fri, 27 Mar 2009 13:04:14 +0100, Thomas Gleixner a écrit :
> On Fri, 27 Mar 2009, Philippe Reynes wrote:
>
>> Hi all
>>
>> I've tried to remove the mlockall(MCL_CURRENT|MCL_FUTURE) and now, the
>> kernel don't crash. But a data corruption appear in the data saved by
>> the application. Such corruption never occurs with other kernel (2.6.28
>> and 2.6.29). I'll investigate if it could be an application bug.
>
> I don't think that mlockall or the application is the culprit. The bug
> happens in the middle of the slab cache code.
>
>> > server calling Oops: Exception in kernel mode, sig: 5 [#1] PREEMPT
>> > MPC837x RR605
>> > Modules linked in:
>> > NIP: c0075b08 LR: c0075a50 CTR: c00d7d90 REGS: dbb6dcb0 TRAP: 0700
>> > Not tainted (2.6.29-rt1) MSR: 00029032 <EE,ME,CE,IR,DR> CR:
>> > 24002488 XER: 00000000 TASK = dddea1e0[1769] 'vsftpd' THREAD:
>> > dbb6c000 GPR00: 00000001 dbb6dd60 dddea1e0 df803e24 df803e10 df803e08
>> > 00000000 ddc72020 GPR08: 00000000 0000001b dddea1e0 df803e24 24000482
>> > 100bf094 00000000 c04aa6fc
>> > GPR16: 00200200 00100100 c04e5958 c04e595c dbb6dd68 c04e0000 c04e0000
>> > c04aa6bc
>> > GPR24: 00000020 dbb6ddd8 00000010 df80ae00 00000000 dbb6de38 df816800
>> > df803e00
>> > NIP [c0075b08] cache_alloc_refill+0x180/0x62c
>
> addr2line -e vmlinux c0075b08
> linux-2.6.29/mm/slab.c:3150
>
> That's BUG_ON(slabp->inuse >= cachep->num);
>
>> > LR [c0075a50] cache_alloc_refill+0xc8/0x62c Call Trace:
>> > [dbb6dd60] [c038878c] preempt_schedule_irq+0x5c/0x80 (unreliable)
>
> Hmm. This one is interesting. Might be we got preempted here - which
> should be fine, but who knows what we missed when we reworked the
> locking.
>
> Thanks,
>
> tglx
may be this trace is better ....
sirq-timer/0-4 [000] 97.737264: finish_task_switch <-__schedule
sirq-timer/0-4 [000] 97.737267: run_timer_softirq <-ksoftirqd
sirq-timer/0-4 [000] 97.737269: printk_tick <-run_timer_softirq
sirq-timer/0-4 [000] 97.737271: hrtimer_run_pending <-
run_timer_softirq
sirq-timer/0-4 [000] 97.737273: rt_spin_lock <-
run_timer_softirq
sirq-timer/0-4 [000] 97.737275: __wake_up <-run_timer_softirq
sirq-timer/0-4 [000] 97.737277: rt_spin_lock <-__wake_up
hwclock-1740 [000] 121.298710: free_page_and_swap_cache <-
unmap_vmas
hwclock-1740 [000] 121.298712: put_page <-
free_page_and_swap_cache
hwclock-1740 [000] 121.298713: vm_normal_page <-unmap_vmas
hwclock-1740 [000] 121.298715: page_remove_rmap <-unmap_vmas
hwclock-1740 [000] 121.298716: free_page_and_swap_cache <-
unmap_vmas
hwclock-1740 [000] 121.298718: put_page <-
free_page_and_swap_cache
hwclock-1740 [000] 121.298719: vm_normal_page <-unmap_vmas
hwclock-1740 [000] 121.298721: page_remove_rmap <-unmap_vmas
hwclock-1740 [000] 121.298722: free_page_and_swap_cache <-
unmap_vmas
hwclock-1740 [000] 121.298724: put_page <-
free_page_and_swap_cache
hwclock-1740 [000] 121.298726: vm_normal_page <-unmap_vmas
hwclock-1740 [000] 121.298727: page_remove_rmap <-unmap_vmas
hwclock-1740 [000] 121.298729: free_page_and_swap_cache <-
unmap_vmas
hwclock-1740 [000] 121.298730: put_page <-
free_page_and_swap_cache
hwclock-1740 [000] 121.298732: vm_normal_page <-unmap_vmas
hwclock-1740 [000] 121.298733: page_remove_rmap <-unmap_vmas
hwclock-1740 [000] 121.298735: free_page_and_swap_cache <-
unmap_vmas
hwclock-1740 [000] 121.298736: put_page <-
free_page_and_swap_cache
hwclock-1740 [000] 121.298738: vm_normal_page <-unmap_vmas
hwclock-1740 [000] 121.298739: page_remove_rmap <-unmap_vmas
hwclock-1740 [000] 121.298741: free_page_and_swap_cache <-
unmap_vmas
hwclock-1740 [000] 121.298742: put_page <-
free_page_and_swap_cache
hwclock-1740 [000] 121.298744: vm_normal_page <-unmap_vmas
hwclock-1740 [000] 121.298746: page_remove_rmap <-unmap_vmas
hwclock-1740 [000] 121.298747: free_page_and_swap_cache <-
unmap_vmas
hwclock-1740 [000] 121.298749: put_page <-
free_page_and_swap_cache
hwclock-1740 [000] 121.298750: vm_normal_page <-unmap_vmas
hwclock-1740 [000] 121.298752: page_remove_rmap <-unmap_vmas
hwclock-1740 [000] 121.298753: free_page_and_swap_cache <-
unmap_vmas
hwclock-1740 [000] 121.298755: put_page <-
free_page_and_swap_cache
hwclock-1740 [000] 121.298756: vm_normal_page <-unmap_vmas
hwclock-1740 [000] 121.298758: page_remove_rmap <-unmap_vmas
hwclock-1740 [000] 121.298759: free_page_and_swap_cache <-
unmap_vmas
hwclock-1740 [000] 121.298761: put_page <-
free_page_and_swap_cache
hwclock-1740 [000] 121.298762: vm_normal_page <-unmap_vmas
hwclock-1740 [000] 121.298764: page_remove_rmap <-unmap_vmas
hwclock-1740 [000] 121.298766: free_page_and_swap_cache <-
unmap_vmas
hwclock-1740 [000] 121.298767: put_page <-
free_page_and_swap_cache
hwclock-1740 [000] 121.298769: vm_normal_page <-unmap_vmas
hwclock-1740 [000] 121.298770: page_remove_rmap <-unmap_vmas
hwclock-1740 [000] 121.298772: free_page_and_swap_cache <-
unmap_vmas
hwclock-1740 [000] 121.298773: put_page <-
free_page_and_swap_cache
hwclock-1740 [000] 121.298775: vm_normal_page <-unmap_vmas
hwclock-1740 [000] 121.298776: page_remove_rmap <-unmap_vmas
hwclock-1740 [000] 121.298778: free_page_and_swap_cache <-
unmap_vmas
hwclock-1740 [000] 121.298779: put_page <-
free_page_and_swap_cache
hwclock-1740 [000] 12PHY: 0:0a - Link is Up1.298781:
vm_normal_page <-unmap_vmas
hwclock-1740 [000] 121.298782: page_remove_rm - 1000/Fullap <-
unmap_vmas
hwclock-1740 [000] 121.298784: free_page_and_swap_cache <-
unmap_vmas
hwclock-1740 [000] 121.298785: put_page <-
free_page_and_swap_cache
hwclock-1740 [000] 121.298787: vm_normal_page <-unmap_vmas
hwclock-1740 [000] 121.298789: page_remove_rmap <-unmap_vmas
hwclock-1740 [000] 121.298790: free_page_and_swap_cache <-
unmap_vmas
hwclock-1740 [000] 121.298792: put_page <-
free_page_and_swap_cache
hwclock-1740 [000] 121.298793: vm_normal_page <-unmap_vmas
hwclock-1740 [000] 121.298795: page_remove_rmap <-unmap_vmas
hwclock-1740 [000] 121.2987Oops: Exception in kernel mode,
sig: 5 [#1]
PREEMPT MPC837x RR605
Modules linked in:
NIP: c0095550 LR: c00956f0 CTR: c00954d8
REGS: df89fe00 TRAP: 0700 Not tainted (2.6.29-rt1)
MSR: 00029032 <EE,ME,CE,IR,DR> CR: 24044028 XER: 20000000
TASK = df89da00[15] 'events/0' THREAD: df89e000
GPR00: 00000001 df89feb0 df89da00 df80ae00 c0b821a0 00000000 00000000
df89fee8
GPR08: 00000000 003821a0 dc10d918 c0800000 777db820 00000000 1ffcd000
00000000
GPR16: 1ffc300e 1ffc6f20 00000000 1ffc8600 c0471623 c047165a c0560000
00000002
GPR24: df89fee8 df80ae00 00100100 00200200 00000000 df816828 df80ae00
df89feb0
NIP [c0095550] free_block+0x84/0x160
LR [c00956f0] drain_array+0xc4/0x194
Call Trace:
[df89feb0] [c0013d88] ftrace_call+0x4/0x48 (unreliable)
[df89fee0] [c00956f0] drain_array+0xc4/0x194
[df89ff20] [c0097374] cache_reap+0x68/0x148
[df89ff50] [c003aa8c] run_workqueue+0x14c/0x1b8
[df89ff90] [c003b51c] worker_thread+0xfc/0x10c
[df89ffd0] [c003fd00] kthread+0x5c/0x8c
[df89fff0] [c00131c0] kernel_thread+0x4c/0x68
Instruction dump:
815d0000 8176b248 3d2a4000 5529c9f4 7c09582e 7c895a14 70054000 41a20008
8084000c 80040000 68000080 5400cffe <0f000000> 8084001c 80f9004c 81640004
---[ end trace 8fa1185748d94493 ]---
------------[ cut here ]------------
kernel BUG at kernel/rtmutex.c:806!
Oops: Exception in kernel mode, sig: 5 [#2]
PREEMPT MPC837x RR605
Modules linked in:
NIP: c03f3b64 LR: c03f409c CTR: c03f3af4
REGS: df89fab0 TRAP: 0700 Tainted: G D (2.6.29-rt1)
MSR: 00021032 <ME,CE,IR,DR> CR: 84044048 XER: 20000000
TASK = df89da00[15] 'events/0' THREAD: df89e000
GPR00: 00000001 df89fb60 df89da00 c052bb7c df87b580 00001032 00017fff
c051cc6c
GPR08: df89da00 00000001 df89da00 df89e000 7e6ec050 00000000 1ffcd000
00000000
GPR16: 1ffc300e 1ffc6f20 00000000 1ffc8600 c0471623 c0028780 c055e748
c0520000
GPR24: c0560000 00200200 c0023edc df87b580 c052bb7c df89fc08 df85a240
df89fb60
NIP [c03f3b64] rt_spin_lock_slowlock+0x7c/0x284
LR [c03f409c] rt_spin_lock+0x7c/0x84
Call Trace:
[df89fb60] [00001032] 0x1032 (unreliable)
[df89fbd0] [c03f409c] rt_spin_lock+0x7c/0x84
[df89fbe0] [c0094e40] _slab_irq_disable+0x34/0x44
[df89fc00] [c009531c] kmem_cache_free+0x38/0x15c
[df89fc30] [c0023edc] __cleanup_sighand+0x4c/0x54
[df89fc40] [c0029114] release_task+0x2d0/0x3a8
[df89fc80] [c002a7f8] do_exit+0x65c/0x710
[df89fcc0] [c0010e18] kernel_bad_stack+0x0/0x54
[df89fce0] [c0011010] _exception+0x68/0x174
[df89fdd0] [c0011838] program_check_exception+0x520/0x530
[df89fdf0] [c00139e8] ret_from_except_full+0x0/0x4c
--- Exception: 700 at free_block+0x84/0x160
LR = drain_array+0xc4/0x194
[df89feb0] [c0013d88] ftrace_call+0x4/0x48 (unreliable)
[df89fee0] [c00956f0] drain_array+0xc4/0x194
[df89ff20] [c0097374] cache_reap+0x68/0x148
[df89ff50] [c003aa8c] run_workqueue+0x14c/0x1b8
[df89ff90] [c003b51c] worker_thread+0xfc/0x10c
[df89ffd0] [c003fd00] kthread+0x5c/0x8c
[df89fff0] [c00131c0] kernel_thread+0x4c/0x68
Instruction dump:
2f800000 40be0018 39230008 907c0004 907c0000 91290004 91230008 801c0010
5400003a 7c001278 7c000034 5400d97e <0f000000> 81420000 69490002 3129ffff
---[ end trace 8fa1185748d94494 ]---
Fixing recursive fault but reboot is needed!
96: free_page_and_swap_cache <-unmap_vmas
hwclock-1740 [000] 121.298798: put_page <-
free_page_and_swap_cache
hwclock-1740 [000] 121.298799: vm_normal_page <-unmap_vmas
hwclock-1740 [000] 121.298801: page_remove_rmap <-unmap_vmas
hwclock-1740 [000] 121.298802: free_page_and_swap_cache <-
unmap_vmas
hwclock-1740 [000] 121.298804: put_page <-
free_page_and_swap_cache
hwclock-1740 [000] 121.298805: vm_normal_page <-unmap_vmas
hwclock-1740 [000] 121.298807: page_remove_rmap <-unmap_vmas
hwclock-1740 [000] 121.298809: free_page_and_swap_cache <-
unmap_vmas
hwclock-1740 [000] 121.298810: put_page <-
free_page_and_swap_cache
hwclock-1740 [000] 121.298812: vm_normal_page <-unmap_vmas
hwclock-1740 [000] 121.298813: page_remove_rmap <-unmap_vmas
hwclock-1740 [000] 121.298815: free_page_and_swap_cache <-
unmap_vmas
hwclock-1740 [000] 121.298816: put_page <-
free_page_and_swap_cache
hwclock-1740 [000] 121.298818: vm_normal_page <-unmap_vmas
hwclock-1740 [000] 121.298819: page_remove_rmap <-unmap_vmas
hwclock-1740 [000] 121.298821: free_page_and_swap_cache <-
unmap_vmas
hwclock-1740 [000] 121.298822: put_page <-
free_page_and_swap_cache
hwclock-1740 [000] 121.298824: vm_normal_page <-unmap_vmas
hwclock-1740 [000] 121.298825: page_remove_rmap <-unmap_vmas
hwclock-1740 [000] 121.298827: free_page_and_swap_cache <-
unmap_vmas
hwclock-1740 [000] 121.298828: put_page <-
free_page_and_swap_cache
hwclock-1740 [000] 121.298830: vm_normal_page <-unmap_vmas
hwclock-1740 [000] 121.298832: page_remove_rmap <-unmap_vmas
hwclock-1740 [000] 121.298833: free_page_and_swap_cache <-
unmap_vmas
hwclock-1740 [000] 121.298835: put_page <-
free_page_and_swap_cache
hwclock-1740 [000] 121.298836: vm_normal_page <-unmap_vmas
hwclock-1740 [000] 121.298838: page_remove_rmap <-unmap_vmas
hwclock-1740 [000] 121.298839: free_page_and_swap_cache <-
unmap_vmas
hwclock-1740 [000] 121.298841: put_page <-
free_page_and_swap_cache
hwclock-1740 [000] 121.298842: vm_normal_page <-unmap_vmas
hwclock-1740 [000] 121.298844: page_remove_rmap <-unmap_vmas
hwclock-1740 [000] 121.298845: free_page_and_swap_cache <-
unmap_vmas
hwclock-1740 [000] 121.298847: put_page <-
free_page_and_swap_cache
hwclock-1740 [000] 121.298849: vm_normal_page <-unmap_vmas
hwclock-1740 [000] 121.298850: page_remove_rmap <-unmap_vmas
hwclock-1740 [000] 121.298852: free_page_and_swap_cache <-
unmap_vmas
hwclock-1740 [000] 121.298853: put_page <-
free_page_and_swap_cache
hwclock-1740 [000] 121.298855: vm_normal_page <-unmap_vmas
hwclock-1740 [000] 121.298856: page_remove_rmap <-unmap_vmas
hwclock-1740 [000] 121.298858: free_page_and_swap_cache <-
unmap_vmas
We are pleased to announce the next update to our new preempt-rt
series.
- fix a fork/exit bug in the signal per task cache (/me puts on
a huge brown paper bag - Thanks to Phillipe Reynes and Will
Schmidt for reporting and testing)
- fix a group scheduling migration accounting bug (decoded with
and fixed by Peter Zijlstra - reported by Robin Gareus)
- tlb gather rework by Peter Zijlstra - Thanks Peter !
- the usual fixlets
The tlb rework might be incomplete on some of the uncountable
incarnations of PowerPC and ARM platforms, so look out for wreckage
and keep the usual tools (fire-extinguishers, brooms, buckets etc.)
handy.
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.29-rt2 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29-rt2.bz2
The broken out patches are also available at the same download
locations.
Enjoy !
tglx
On Thu, 2009-04-02 at 02:17 +0200, Thomas Gleixner wrote:
> We are pleased to announce the next update to our new preempt-rt
> series.
>
> - fix a fork/exit bug in the signal per task cache (/me puts on
> a huge brown paper bag - Thanks to Phillipe Reynes and Will
> Schmidt for reporting and testing)
>
> - fix a group scheduling migration accounting bug (decoded with
> and fixed by Peter Zijlstra - reported by Robin Gareus)
>
> - tlb gather rework by Peter Zijlstra - Thanks Peter !
>
> - the usual fixlets
>
> The tlb rework might be incomplete on some of the uncountable
> incarnations of PowerPC and ARM platforms, so look out for wreckage
> and keep the usual tools (fire-extinguishers, brooms, buckets etc.)
> handy.
I can confirm that the tlb rework does appear to be missing some parts
for Power. (Using 2.6.29-rt3 on pseries ppc64)
arch/powerpc/kernel/built-in.o:(.toc1+0x4d0): undefined reference to
`per_cpu__ppc64_tlb_batch'
<...>
mm/built-in.o:(.toc1+0xed0): more undefined references to
`per_cpu__ppc64_tlb_batch' follow
Not clear to me if this is just missing a "DEFINE_PER_CPU_LOCKED" to
replace the removed "DEFINE_PER_CPU", (similar to the prior RT patches),
or if the tlb rework is more involved. So, I will patiently remain
tuned in. :-)
Thanks,
-Will
On Thu, 2 Apr 2009, Will Schmidt wrote:
> On Thu, 2009-04-02 at 02:17 +0200, Thomas Gleixner wrote:
> > We are pleased to announce the next update to our new preempt-rt
> > series.
> >
> > - fix a fork/exit bug in the signal per task cache (/me puts on
> > a huge brown paper bag - Thanks to Phillipe Reynes and Will
> > Schmidt for reporting and testing)
> >
> > - fix a group scheduling migration accounting bug (decoded with
> > and fixed by Peter Zijlstra - reported by Robin Gareus)
> >
> > - tlb gather rework by Peter Zijlstra - Thanks Peter !
> >
> > - the usual fixlets
> >
> > The tlb rework might be incomplete on some of the uncountable
> > incarnations of PowerPC and ARM platforms, so look out for wreckage
> > and keep the usual tools (fire-extinguishers, brooms, buckets etc.)
> > handy.
>
> I can confirm that the tlb rework does appear to be missing some parts
> for Power. (Using 2.6.29-rt3 on pseries ppc64)
>
> arch/powerpc/kernel/built-in.o:(.toc1+0x4d0): undefined reference to
> `per_cpu__ppc64_tlb_batch'
> <...>
> mm/built-in.o:(.toc1+0xed0): more undefined references to
> `per_cpu__ppc64_tlb_batch' follow
>
> Not clear to me if this is just missing a "DEFINE_PER_CPU_LOCKED" to
> replace the removed "DEFINE_PER_CPU", (similar to the prior RT patches),
> or if the tlb rework is more involved. So, I will patiently remain
> tuned in. :-)
No, the DEFINE_PER_CPU was removed accidentaly. Should have stayed there
Thanks,
tglx
--------
Index: linux-2.6-tip/arch/powerpc/mm/tlb_hash64.c
===================================================================
--- linux-2.6-tip.orig/arch/powerpc/mm/tlb_hash64.c
+++ linux-2.6-tip/arch/powerpc/mm/tlb_hash64.c
@@ -32,6 +32,8 @@
#include <asm/bug.h>
#include <asm/machdep.h>
+DEFINE_PER_CPU(struct ppc64_tlb_batch, ppc64_tlb_batch);
+
/*
* A linux PTE was changed and the corresponding hash table entry
* neesd to be flushed. This function will either perform the flush
On Thu, 2009-04-02 at 18:45 +0200, Thomas Gleixner wrote:
> On Thu, 2 Apr 2009, Will Schmidt wrote:
>
> > On Thu, 2009-04-02 at 02:17 +0200, Thomas Gleixner wrote:
> > > We are pleased to announce the next update to our new preempt-rt
> > > series.
> > >
> > > - fix a fork/exit bug in the signal per task cache (/me puts on
> > > a huge brown paper bag - Thanks to Phillipe Reynes and Will
> > > Schmidt for reporting and testing)
> > >
> > > - fix a group scheduling migration accounting bug (decoded with
> > > and fixed by Peter Zijlstra - reported by Robin Gareus)
> > >
> > > - tlb gather rework by Peter Zijlstra - Thanks Peter !
> > >
> > > - the usual fixlets
> > >
> > > The tlb rework might be incomplete on some of the uncountable
> > > incarnations of PowerPC and ARM platforms, so look out for wreckage
> > > and keep the usual tools (fire-extinguishers, brooms, buckets etc.)
> > > handy.
> >
> > I can confirm that the tlb rework does appear to be missing some parts
> > for Power. (Using 2.6.29-rt3 on pseries ppc64)
> >
> > arch/powerpc/kernel/built-in.o:(.toc1+0x4d0): undefined reference to
> > `per_cpu__ppc64_tlb_batch'
> > <...>
> > mm/built-in.o:(.toc1+0xed0): more undefined references to
> > `per_cpu__ppc64_tlb_batch' follow
> >
> > Not clear to me if this is just missing a "DEFINE_PER_CPU_LOCKED" to
> > replace the removed "DEFINE_PER_CPU", (similar to the prior RT patches),
> > or if the tlb rework is more involved. So, I will patiently remain
> > tuned in. :-)
>
> No, the DEFINE_PER_CPU was removed accidentaly. Should have stayed there
>
> Thanks,
>
> tglx
Thanks for the quick respin.
Panic during boot:
<snip>
Uniform Multi-Platform E-IDE driver
ide-gd driver 1.18
ide-cd driver 5.00
mice: PS/2 mouse device common for all mice
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 17
Freeing unused kernel memory: 292k freed
Red Hat nash version 5.1.19.6 starting
Mounting proc filesystem
Mounting sysfs filesystem
Creating /dev
Unable to handle kernel paging request for instruction fetch
Faulting instruction address: 0x00000c30
cpu 0x3: Vector: 400 (Instruction Access) at [c0000000e8203b00]
pc: 0000000000000c30
lr: c0000000000b7d24: .rcu_process_callbacks+0xc0/0xec
sp: c0000000e8203d80
msr: 8000000040009032
current = 0xc0000000e81ff0f0
paca = 0xc000000000663800
pid = 53, comm = sirq-rcu/3
enter ? for help
[c0000000e8203d80] c0000000000b7d24 .rcu_process_callbacks+0xc0/0xec
(unreliable)
[c0000000e8203e10] c000000000070f48 .ksoftirqd+0x208/0x39c
[c0000000e8203f00] c000000000085a34 .kthread+0x78/0xc4
[c0000000e8203f90] c000000000029818 .kernel_thread+0x54/0x70
3:mon>
3:mon> r
R00 = c0000000e8480100 R16 = c000000000467280
R01 = c0000000e8203d80 R17 = c000000000465980
R02 = 000000000014ff97 R18 = 0000000000000000
R03 = c0000000e6b6b880 R19 = c0000000e8200000
R04 = 0000000000000001 R20 = c00000000065be58
R05 = c000000000663800 R21 = 0000000000000000
R06 = c0000000e8203cc8 R22 = 0000000000000003
R07 = 0000000000200200 R23 = 0000000000000003
R08 = 0000000000000001 R24 = c000000000663800
R09 = c0000000e6b60eb0 R25 = c000000000696f00
R10 = c000000000538280 R26 = c00000000079e620
R11 = 0000000000000001 R27 = 0000000000000100
R12 = 0000000084000082 R28 = 0000000000000001
R13 = c000000000663800 R29 = c00000000079ea28
R14 = 0000000000000000 R30 = c0000000005d1538
R15 = 0000000002100000 R31 = c0000000e8480100
pc = 0000000000000c30
lr = c0000000000b7d24 .rcu_process_callbacks+0xc0/0xec
msr = 8000000040009032 cr = 24000088
ctr = 0000000000000c31 xer = 0000000020000004 trap = 400
>
> --------
>
> Index: linux-2.6-tip/arch/powerpc/mm/tlb_hash64.c
> ===================================================================
> --- linux-2.6-tip.orig/arch/powerpc/mm/tlb_hash64.c
> +++ linux-2.6-tip/arch/powerpc/mm/tlb_hash64.c
> @@ -32,6 +32,8 @@
> #include <asm/bug.h>
> #include <asm/machdep.h>
>
> +DEFINE_PER_CPU(struct ppc64_tlb_batch, ppc64_tlb_batch);
> +
> /*
> * A linux PTE was changed and the corresponding hash table entry
> * neesd to be flushed. This function will either perform the flush
On Thu, 2009-04-02 at 12:24 -0500, Will Schmidt wrote:
> > --------
> >
> > Index: linux-2.6-tip/arch/powerpc/mm/tlb_hash64.c
> > ===================================================================
> > --- linux-2.6-tip.orig/arch/powerpc/mm/tlb_hash64.c
> > +++ linux-2.6-tip/arch/powerpc/mm/tlb_hash64.c
> > @@ -32,6 +32,8 @@
> > #include <asm/bug.h>
> > #include <asm/machdep.h>
> >
> > +DEFINE_PER_CPU(struct ppc64_tlb_batch, ppc64_tlb_batch);
> > +
> > /*
> > * A linux PTE was changed and the corresponding hash table entry
> > * neesd to be flushed. This function will either perform the flush
Will, could you see if the below makes your splat go away?
diff --git a/arch/powerpc/include/asm/tlb.h b/arch/powerpc/include/asm/tlb.h
index ec82dac..3ddc8f6 100644
--- a/arch/powerpc/include/asm/tlb.h
+++ b/arch/powerpc/include/asm/tlb.h
@@ -38,6 +38,8 @@ struct arch_mmu_gather {
struct pte_freelist_batch *batch;
};
+#define ARCH_MMU_GATHER_INIT (struct arch_mmu_gather){ .batch = NULL, }
+
#if !defined(CONFIG_PPC_STD_MMU)
#define tlb_flush(tlb) flush_tlb_mm((tlb)->mm)
diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h
index 7f2167e..50a09de 100644
--- a/include/asm-generic/tlb.h
+++ b/include/asm-generic/tlb.h
@@ -71,6 +71,10 @@ tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, unsigned int full_m
tlb->nr = ~0U;
tlb->fullmm = full_mm_flush;
+
+#ifdef HAVE_ARCH_MMU_GATHER
+ tlb->arch = ARCH_MMU_GATHER_INIT;
+#endif
}
static inline void
On Fri, 2009-04-03 at 11:43 +0200, Peter Zijlstra wrote:
> On Thu, 2009-04-02 at 12:24 -0500, Will Schmidt wrote:
>
> > > --------
> > >
> > > Index: linux-2.6-tip/arch/powerpc/mm/tlb_hash64.c
> > > ===================================================================
> > > --- linux-2.6-tip.orig/arch/powerpc/mm/tlb_hash64.c
> > > +++ linux-2.6-tip/arch/powerpc/mm/tlb_hash64.c
> > > @@ -32,6 +32,8 @@
> > > #include <asm/bug.h>
> > > #include <asm/machdep.h>
> > >
> > > +DEFINE_PER_CPU(struct ppc64_tlb_batch, ppc64_tlb_batch);
> > > +
> > > /*
> > > * A linux PTE was changed and the corresponding hash table entry
> > > * neesd to be flushed. This function will either perform the flush
>
> Will, could you see if the below makes your splat go away?
It does.. booted clean on a power6 blade with this patch applied.
Thanks. :-)
-Will
>
> diff --git a/arch/powerpc/include/asm/tlb.h b/arch/powerpc/include/asm/tlb.h
> index ec82dac..3ddc8f6 100644
> --- a/arch/powerpc/include/asm/tlb.h
> +++ b/arch/powerpc/include/asm/tlb.h
> @@ -38,6 +38,8 @@ struct arch_mmu_gather {
> struct pte_freelist_batch *batch;
> };
>
> +#define ARCH_MMU_GATHER_INIT (struct arch_mmu_gather){ .batch = NULL, }
> +
> #if !defined(CONFIG_PPC_STD_MMU)
>
> #define tlb_flush(tlb) flush_tlb_mm((tlb)->mm)
> diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h
> index 7f2167e..50a09de 100644
> --- a/include/asm-generic/tlb.h
> +++ b/include/asm-generic/tlb.h
> @@ -71,6 +71,10 @@ tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, unsigned int full_m
> tlb->nr = ~0U;
>
> tlb->fullmm = full_mm_flush;
> +
> +#ifdef HAVE_ARCH_MMU_GATHER
> + tlb->arch = ARCH_MMU_GATHER_INIT;
> +#endif
> }
>
> static inline void
>
We are pleased to announce the next update to our new preempt-rt
series.
- rebased to 2.6.29.1
- powerpc64 tlb rework fix by Peter
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.29.1-rt4 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.1.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29.1-rt4.bz2
The broken out patches are also available at the same download
locations.
Enjoy !
tglx
On Fri, 2009-04-03 at 19:21 +0200, Thomas Gleixner wrote:
> We are pleased to announce the next update to our new preempt-rt
> series.
>
> - rebased to 2.6.29.1
>
> - powerpc64 tlb rework fix by Peter
Thanks for cc'ing me...
Just a heads up. I'm still having shutdown/suspend problems with this
release as before (I had not reported the suspend problem, I think -
machine hangs and has to be power cycled). Booting with "noreplace-smp"
fixes both. Is this something I could disable through configuration
options?
I was also seeing a hard hang when running a java program (with the
Fedora 10 open source java) - the swingosc gui component of
SuperCollider 3 (a computer music synthesis program). Impossible to know
what had failed, machine completely catatonic and nothing left on the
logs.
I managed to start the same program _once_ (have not tested again) with
2.6.29.1/rt4 + some patches & config from fc10' koji 2.6.29.1-15. The
mouse seemed to pause a couple of times and then I killed the program.
Restarting it again was successful. Sorry to not have more hard info...
-- Fernando
On Fri, 3 Apr 2009, Fernando Lopez-Lezcano wrote:
> On Fri, 2009-04-03 at 19:21 +0200, Thomas Gleixner wrote:
> > We are pleased to announce the next update to our new preempt-rt
> > series.
> >
> > - rebased to 2.6.29.1
> >
> > - powerpc64 tlb rework fix by Peter
>
> Thanks for cc'ing me...
>
> Just a heads up. I'm still having shutdown/suspend problems with this
> release as before (I had not reported the suspend problem, I think -
> machine hangs and has to be power cycled). Booting with "noreplace-smp"
> fixes both. Is this something I could disable through configuration
> options?
No. I have this shutdown/suspend thing on my todo list. Can you send
me your .config please ? This happens with the stock -rt kernel or do
you have other patches on top of it ?
> I was also seeing a hard hang when running a java program (with the
> Fedora 10 open source java) - the swingosc gui component of
> SuperCollider 3 (a computer music synthesis program). Impossible to know
> what had failed, machine completely catatonic and nothing left on the
> logs.
>
> I managed to start the same program _once_ (have not tested again) with
> 2.6.29.1/rt4 + some patches & config from fc10' koji 2.6.29.1-15. The
> mouse seemed to pause a couple of times and then I killed the program.
> Restarting it again was successful. Sorry to not have more hard info...
Too bad that I can't find my crystal ball :)
Thanks,
tglx
On Sat, 2009-04-04 at 06:30 +0200, Thomas Gleixner wrote:
> On Fri, 3 Apr 2009, Fernando Lopez-Lezcano wrote:
> > On Fri, 2009-04-03 at 19:21 +0200, Thomas Gleixner wrote:
> > > We are pleased to announce the next update to our new preempt-rt
> > > series.
> > >
> > > - rebased to 2.6.29.1
> > >
> > > - powerpc64 tlb rework fix by Peter
> >
> > Thanks for cc'ing me...
> >
> > Just a heads up. I'm still having shutdown/suspend problems with this
> > release as before (I had not reported the suspend problem, I think -
> > machine hangs and has to be power cycled). Booting with "noreplace-smp"
> > fixes both. Is this something I could disable through configuration
> > options?
>
> No. I have this shutdown/suspend thing on my todo list.
Ah, ok. No problem. If it were not for this feature I'd probably release
a test version for Planet CCRMA.
> Can you send me your .config please ?
Attached.
> This happens with the stock -rt kernel or do
> you have other patches on top of it ?
Other patches on top of it. I'm building rpm packages merging the latest
Fedora .src.rpm's with rt (as I have been doing for a long long time). I
have to have as close a kernel as possible to the Fedora kernels
(drivers + configs, within reason - some of the stuff does not patch
cleanly of course[*]). The kernel I'm testing is merged with
2.6.29.1-15 / fc10.
Sigh, I know, I know, I have to try to test with the vanilla tree. I
don't anticipate having time to do that soon (concert tomorrow, trip
starting next week).
> > I was also seeing a hard hang when running a java program (with the
> > Fedora 10 open source java) - the swingosc gui component of
> > SuperCollider 3 (a computer music synthesis program). Impossible to know
> > what had failed, machine completely catatonic and nothing left on the
> > logs.
> >
> > I managed to start the same program _once_ (have not tested again) with
> > 2.6.29.1/rt4 + some patches & config from fc10' koji 2.6.29.1-15. The
> > mouse seemed to pause a couple of times and then I killed the program.
> > Restarting it again was successful. Sorry to not have more hard info...
>
> Too bad that I can't find my crystal ball :)
You __have__ one?? Wow. Anyway, it seems that the java problem is gone
or something else killed it (another software upgrade perhaps?). Which
is good.
Thanks again, looking forward to the next release!
-- Fernando
[*] over the years I have tried different approaches and this is the one
that has given me kernels that work and are most compatible with the
rest of Fedora.
Dear Thomas,
>
>The broken out patches are also available at the same download
>locations.
>
>Enjoy !
Thank you for new release announce.
I am using new version ( linux-2.6.29.1-rt4 ) now .
config file is http://leemgs1.googlecode.com/files/i386.2.6.29.1-rt4.ftrace.config.20090404
I have one question. What is "broken-out" 's meaning for rt patch file?
When I opened realtime patch files for vanilla kernel,
I always checked 2 files like belows.
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29.1-rt4-broken-out.tar.bz2
<-- collection of seperate files for each patch.
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29.1-rt4.bz2
<-- only one patch file.
What is difference meaning of file-name format
between "patch-2.6.29.1-rt4-broken-out.tar.bz2" and "patch-2.6.29.1-rt4.bz2" ?
I have always wondered that.
I am sorry for sending this stupid and easy question.
Thanks,
GeunSik Lim,
2009/4/4 Thomas Gleixner <[email protected]>:
> We are pleased to announce the next update to our new preempt-rt
> series.
>
> - rebased to 2.6.29.1
>
> - powerpc64 tlb rework fix by Peter
>
> Download locations:
>
> http://rt.et.redhat.com/download/
> http://www.kernel.org/pub/linux/kernel/projects/rt/
>
> Information on the RT patch can be found at:
>
> http://rt.wiki.kernel.org/index.php/Main_Page
>
> to build the 2.6.29.1-rt4 tree, the following patches should be
> applied:
>
> http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.1.tar.bz2
> http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29.1-rt4.bz2
>
> The broken out patches are also available at the same download
> locations.
>
> Enjoy !
>
> tglx
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Regards,
GeunSik Lim
GeunSik,
On Sun, 5 Apr 2009, GeunSik Lim wrote:
> I have one question. What is "broken-out" 's meaning for rt patch file?
The broken out tar ball contains a patch series of smaller patches,
which need to be applied in a give order. The order is determined from
the series file. It's a "quilt" series. quilt is a patch series
management tool. "man script"
We keep those smaller patches for various reasons:
- It's way easier to move forward to the next kernel version with
smaller patches than with a huge all in one patch.
- It's easier to split out functionality from the patches and rework
that particular issue and replace the patches in the series
The broken out series is provided for people who want to look into the
details of the patches and for preempt-rt developers.
patch-2.6.X-rtY.bz2 is the combination of all patches from the series
applied. We provide this as a conveniance for users and testers so
they just have to apply one big patch.
Thanks,
tglx
On Sun, 5 Apr 2009, Thomas Gleixner wrote:
> GeunSik,
>
> On Sun, 5 Apr 2009, GeunSik Lim wrote:
> > I have one question. What is "broken-out" 's meaning for rt patch file?
>
> The broken out tar ball contains a patch series of smaller patches,
> which need to be applied in a give order. The order is determined from
> the series file. It's a "quilt" series. quilt is a patch series
> management tool. "man script"
Of course I meant: man quilt
tglx
On Fri, 3 Apr 2009, Fernando Lopez-Lezcano wrote:
> > > Just a heads up. I'm still having shutdown/suspend problems with this
> > > release as before (I had not reported the suspend problem, I think -
> > > machine hangs and has to be power cycled). Booting with "noreplace-smp"
> > > fixes both. Is this something I could disable through configuration
> > > options?
> >
> > No. I have this shutdown/suspend thing on my todo list.
>
> Ah, ok. No problem. If it were not for this feature I'd probably release
> a test version for Planet CCRMA.
Happens this shutdown/suspend problem every time or is this sporadic ?
Thanks,
tglx
On Sun, 2009-04-05 at 15:53 +0200, Thomas Gleixner wrote:
> On Fri, 3 Apr 2009, Fernando Lopez-Lezcano wrote:
> > > > Just a heads up. I'm still having shutdown/suspend problems with this
> > > > release as before (I had not reported the suspend problem, I think -
> > > > machine hangs and has to be power cycled). Booting with "noreplace-smp"
> > > > fixes both. Is this something I could disable through configuration
> > > > options?
> > >
> > > No. I have this shutdown/suspend thing on my todo list.
> >
> > Ah, ok. No problem. If it were not for this feature I'd probably release
> > a test version for Planet CCRMA.
>
> Happens this shutdown/suspend problem every time or is this sporadic ?
For me it is repeatable (on both a laptop and a desktop machine so it
does not appear to be very hardware specific). It might be of course an
interaction with the Fedora patches I use.
In the category of "I wish I had a crystal ball" reports with no hard
data, I can confirm that my build of rt4 does hang. I was trying
2.6.29.1-rt4 during a rehearsal for a concert yesterday[*] and after a
hard hang I reverted to the vanilla Fedora kernel (which is what I had
been using because of that problem - no clues left behind in logs).
-- Fernando
[*] a T61 lenovo laptop with intel graphics running jack 1.9.1,
linuxsampler, supercollider with two instances of the synthesis engine
doing both audio and midi processing, a convolution reverb using jconv,
ambisonics decoding through two instances of ambdec and the java based
swingosc supercollider gui. Very loaded.
On Sun, 5 Apr 2009, Fernando Lopez-Lezcano wrote:
> On Sun, 2009-04-05 at 15:53 +0200, Thomas Gleixner wrote:
> > On Fri, 3 Apr 2009, Fernando Lopez-Lezcano wrote:
> > > > > Just a heads up. I'm still having shutdown/suspend problems with this
> > > > > release as before (I had not reported the suspend problem, I think -
> > > > > machine hangs and has to be power cycled). Booting with "noreplace-smp"
> > > > > fixes both. Is this something I could disable through configuration
> > > > > options?
> > > >
> > > > No. I have this shutdown/suspend thing on my todo list.
> > >
> > > Ah, ok. No problem. If it were not for this feature I'd probably release
> > > a test version for Planet CCRMA.
> >
> > Happens this shutdown/suspend problem every time or is this sporadic ?
>
> For me it is repeatable (on both a laptop and a desktop machine so it
> does not appear to be very hardware specific). It might be of course an
> interaction with the Fedora patches I use.
>
> In the category of "I wish I had a crystal ball" reports with no hard
> data, I can confirm that my build of rt4 does hang. I was trying
> 2.6.29.1-rt4 during a rehearsal for a concert yesterday[*] and after a
> hard hang I reverted to the vanilla Fedora kernel (which is what I had
> been using because of that problem - no clues left behind in logs).
Hmm. Can you upload your full patch queue and the binary rpm so I can
give it a test ride ?
Thanks,
tglx
On Mon, 2009-04-06 at 00:02 +0200, Thomas Gleixner wrote:
> On Sun, 5 Apr 2009, Fernando Lopez-Lezcano wrote:
> > On Sun, 2009-04-05 at 15:53 +0200, Thomas Gleixner wrote:
> > > On Fri, 3 Apr 2009, Fernando Lopez-Lezcano wrote:
> > > > > > Just a heads up. I'm still having shutdown/suspend problems with this
> > > > > > release as before (I had not reported the suspend problem, I think -
> > > > > > machine hangs and has to be power cycled). Booting with "noreplace-smp"
> > > > > > fixes both. Is this something I could disable through configuration
> > > > > > options?
> > > > >
> > > > > No. I have this shutdown/suspend thing on my todo list.
> > > >
> > > > Ah, ok. No problem. If it were not for this feature I'd probably release
> > > > a test version for Planet CCRMA.
> > >
> > > Happens this shutdown/suspend problem every time or is this sporadic ?
> >
> > For me it is repeatable (on both a laptop and a desktop machine so it
> > does not appear to be very hardware specific). It might be of course an
> > interaction with the Fedora patches I use.
> >
> > In the category of "I wish I had a crystal ball" reports with no hard
> > data, I can confirm that my build of rt4 does hang. I was trying
> > 2.6.29.1-rt4 during a rehearsal for a concert yesterday[*] and after a
> > hard hang I reverted to the vanilla Fedora kernel (which is what I had
> > been using because of that problem - no clues left behind in logs).
>
> Hmm. Can you upload your full patch queue and the binary rpm so I can
> give it a test ride ?
Sure, no problem. I just did a release to planetcore-testing repo (with
a warning to the planetccrma list), you can find it here:
http://ccrma.stanford.edu/planetccrma/mirror/fedora/linux/planetcore/testing/10/i386/repoview/index.html
http://ccrma.stanford.edu/planetccrma/mirror/fedora/linux/planetcore/testing/10/x86_64/repoview/index.html
(the one I have tested and hangs is the i386 PAE version)
Source here:
http://ccrma.stanford.edu/planetccrma/mirror/fedora/linux/planetcore/testing/10/SRPMS/
(if you don't want to figure out the .src.rpm - I would not blame you -
I can give you a list of the patches that were actually applied - of the
ones that are included in the package)
-- Fernando
Fernando,
On Sun, 5 Apr 2009, Fernando Lopez-Lezcano wrote:
> > Hmm. Can you upload your full patch queue and the binary rpm so I can
> > give it a test ride ?
>
> Sure, no problem. I just did a release to planetcore-testing repo (with
> a warning to the planetccrma list), you can find it here:
>
> http://ccrma.stanford.edu/planetccrma/mirror/fedora/linux/planetcore/testing/10/i386/repoview/index.html
> http://ccrma.stanford.edu/planetccrma/mirror/fedora/linux/planetcore/testing/10/x86_64/repoview/index.html
>
> (the one I have tested and hangs is the i386 PAE version)
> Source here:
>
> http://ccrma.stanford.edu/planetccrma/mirror/fedora/linux/planetcore/testing/10/SRPMS/
>
> (if you don't want to figure out the .src.rpm - I would not blame you -
> I can give you a list of the patches that were actually applied - of the
> ones that are included in the package)
No problem. I know how to distangle those beasts.
Still I have no reproducer yet. One of my 32bit test machines survived
a 200 cycle test w/o showing it.
Is there anything special what you run, load ... ?
Looks like I need to add a 32bit install to my T61 in the hope to
reproduce.
Thanks,
tglx
On Mon, 2009-04-06 at 21:54 +0200, Thomas Gleixner wrote:
> Fernando,
>
> On Sun, 5 Apr 2009, Fernando Lopez-Lezcano wrote:
> > > Hmm. Can you upload your full patch queue and the binary rpm so I can
> > > give it a test ride ?
> >
> > Sure, no problem. I just did a release to planetcore-testing repo (with
> > a warning to the planetccrma list), you can find it here:
> >
> > http://ccrma.stanford.edu/planetccrma/mirror/fedora/linux/planetcore/testing/10/i386/repoview/index.html
> > http://ccrma.stanford.edu/planetccrma/mirror/fedora/linux/planetcore/testing/10/x86_64/repoview/index.html
> >
> > (the one I have tested and hangs is the i386 PAE version)
> > Source here:
> >
> > http://ccrma.stanford.edu/planetccrma/mirror/fedora/linux/planetcore/testing/10/SRPMS/
> >
> > (if you don't want to figure out the .src.rpm - I would not blame you -
> > I can give you a list of the patches that were actually applied - of the
> > ones that are included in the package)
>
> No problem. I know how to distangle those beasts.
>
> Still I have no reproducer yet. One of my 32bit test machines survived
> a 200 cycle test w/o showing it.
Arghh, I don't know what it could be then. You mean 200 power cycles??
Wow... it only takes one here. Thanks for testing.
> Is there anything special what you run, load ... ?
Not that I can think of right now. This happens on 32 bit installs on
both Fedora 9 and Fedora 10. Nothing special installed, of course I have
the Planet CCRMA packages but they don't involve additional kernel
modules or anything that (I think) deals with startup or shutdown.
> Looks like I need to add a 32bit install to my T61 in the hope to
> reproduce.
Sorry for the inconvenience. Additional installs, argh (BTW, I won't be
reading email for at least a week, of to LAC2009 tomorrow with a week of
R&R before - please keep cc'ing me on rt stuff).
Thanks!!!
-- Fernando
Fernando,
On Tue, 7 Apr 2009, Fernando Lopez-Lezcano wrote:
> On Mon, 2009-04-06 at 21:54 +0200, Thomas Gleixner wrote:
> > Fernando,
> >
> > On Sun, 5 Apr 2009, Fernando Lopez-Lezcano wrote:
> > > > Hmm. Can you upload your full patch queue and the binary rpm so I can
> > > > give it a test ride ?
> > >
> > > Sure, no problem. I just did a release to planetcore-testing repo (with
> > > a warning to the planetccrma list), you can find it here:
> > >
> > > http://ccrma.stanford.edu/planetccrma/mirror/fedora/linux/planetcore/testing/10/i386/repoview/index.html
> > > http://ccrma.stanford.edu/planetccrma/mirror/fedora/linux/planetcore/testing/10/x86_64/repoview/index.html
> > >
> > > (the one I have tested and hangs is the i386 PAE version)
> > > Source here:
> > >
> > > http://ccrma.stanford.edu/planetccrma/mirror/fedora/linux/planetcore/testing/10/SRPMS/
> > >
> > > (if you don't want to figure out the .src.rpm - I would not blame you -
> > > I can give you a list of the patches that were actually applied - of the
> > > ones that are included in the package)
> >
> > No problem. I know how to distangle those beasts.
> >
> > Still I have no reproducer yet. One of my 32bit test machines survived
> > a 200 cycle test w/o showing it.
>
> Arghh, I don't know what it could be then. You mean 200 power cycles??
> Wow... it only takes one here. Thanks for testing.
Does it trigger when you just boot up and the immediately shut down
w/o doing any work on it ?
Could you try whether the following triggers the bug as well: Boot up,
do work or whatever. Make sure your data is sycned to disk. :)
# echo 0 >/sys/devices/system/cpu/cpu1/online
If that does not trigger, then check whether it survives the
shutdown/reboot. If it does we look further.
> > Is there anything special what you run, load ... ?
>
> Not that I can think of right now. This happens on 32 bit installs on
> both Fedora 9 and Fedora 10. Nothing special installed, of course I have
> the Planet CCRMA packages but they don't involve additional kernel
> modules or anything that (I think) deals with startup or shutdown.
Can you provide the list of modules loaded ?
Thanks,
tglx
On Tue, 2009-04-07 at 09:52 -0700, Fernando Lopez-Lezcano wrote:
> On Mon, 2009-04-06 at 21:54 +0200, Thomas Gleixner wrote:
> > Fernando,
> >
> > On Sun, 5 Apr 2009, Fernando Lopez-Lezcano wrote:
> > > > Hmm. Can you upload your full patch queue and the binary rpm so I can
> > > > give it a test ride ?
> > >
> > > Sure, no problem. I just did a release to planetcore-testing repo (with
> > > a warning to the planetccrma list)
> >
> > No problem. I know how to distangle those beasts.
> >
> > Still I have no reproducer yet. One of my 32bit test machines survived
> > a 200 cycle test w/o showing it.
>
> Arghh, I don't know what it could be then. You mean 200 power cycles??
> Wow... it only takes one here. Thanks for testing.
>
> > Is there anything special what you run, load ... ?
>
> Not that I can think of right now. This happens on 32 bit installs on
> both Fedora 9 and Fedora 10. Nothing special installed, of course I have
> the Planet CCRMA packages but they don't involve additional kernel
> modules or anything that (I think) deals with startup or shutdown.
Maybe I am a special case, somehow:
-------- Forwarded Message --------
From: Timo Sivula
To: [email protected]
Subject: Re: [PlanetCCRMA] for brave users only, kernel 2.6.29.1-rt4 for
fc10
Date: Tue, 07 Apr 2009 12:46:41 +0300
ma, 2009-04-06 kello 12:00 -0700, [email protected]
kirjoitti:
> I just pushed a new build of 2.6.29.1-rt4 (Thomas Gleixner, one of the
> gurus working on the rt patches would like to give it a whirl and the
> easiest way is to put it in planetcore-testing) even though it is not
> "stable" for me.
Starts and closes fine here with my system. Also has not made my mouse
slow, yet. However, neither ndiswrapper 1.53 nor 1.54 does compile with
this kernel.
On Tue, 2009-04-07 at 18:58 +0200, Thomas Gleixner wrote:
> Fernando,
>
> On Tue, 7 Apr 2009, Fernando Lopez-Lezcano wrote:
>
> > On Mon, 2009-04-06 at 21:54 +0200, Thomas Gleixner wrote:
> > > Fernando,
> > >
> > > On Sun, 5 Apr 2009, Fernando Lopez-Lezcano wrote:
> > > > > Hmm. Can you upload your full patch queue and the binary rpm so I can
> > > > > give it a test ride ?
> > > >
> > > > Sure, no problem. I just did a release to planetcore-testing repo (with
> > > > a warning to the planetccrma list), you can find it here:
> > > >
> > > > http://ccrma.stanford.edu/planetccrma/mirror/fedora/linux/planetcore/testing/10/i386/repoview/index.html
> > > > http://ccrma.stanford.edu/planetccrma/mirror/fedora/linux/planetcore/testing/10/x86_64/repoview/index.html
> > > >
> > > > (the one I have tested and hangs is the i386 PAE version)
> > > > Source here:
> > > >
> > > > http://ccrma.stanford.edu/planetccrma/mirror/fedora/linux/planetcore/testing/10/SRPMS/
> > > >
> > > > (if you don't want to figure out the .src.rpm - I would not blame you -
> > > > I can give you a list of the patches that were actually applied - of the
> > > > ones that are included in the package)
> > >
> > > No problem. I know how to distangle those beasts.
> > >
> > > Still I have no reproducer yet. One of my 32bit test machines survived
> > > a 200 cycle test w/o showing it.
> >
> > Arghh, I don't know what it could be then. You mean 200 power cycles??
> > Wow... it only takes one here. Thanks for testing.
>
> Does it trigger when you just boot up and the immediately shut down
> w/o doing any work on it ?
Yes. Just tried again. Clarification: triggers on a "halt -p", _not_ on
a reboot.
> Could you try whether the following triggers the bug as well: Boot up,
> do work or whatever. Make sure your data is sycned to disk. :)
>
> # echo 0 >/sys/devices/system/cpu/cpu1/online
>
> If that does not trigger, then check whether it survives the
> shutdown/reboot. If it does we look further.
It triggers it immediately (in my laptop), I tried from a text console
and it spews things and at the bottom a poke_text thing like before
(after a while I got a couple of messages from iwl3945 about a timeout
and somehow it started to reboot, either when I pressed the power button
or when I did <ctrl><alt><del>)
> > > Is there anything special what you run, load ... ?
> >
> > Not that I can think of right now. This happens on 32 bit installs on
> > both Fedora 9 and Fedora 10. Nothing special installed, of course I have
> > the Planet CCRMA packages but they don't involve additional kernel
> > modules or anything that (I think) deals with startup or shutdown.
>
> Can you provide the list of modules loaded ?
Three lists attached, first all modules after I login, then modules
after a single user boot and then two more after I removed bluetooth and
80211* modules on a hunch, fails to power off in all cases (I first saw
a ref to blue something at the very top of the dump, so removed that,
then saw a reference to 80211 at the top, removed that, then I gave
up :-)
-- Fernando
We are pleased to announce the next update to our new preempt-rt
series.
- include the futex rework + requeue_pi support (Darren Hart)
The futex changes need profound testing. As we know from prior futex
work the best stress tests for the futex interface are RT-Java-VMs
especially with enterprise work loads on larger machines. Can the
folks who have access to such monstrosities please unleash the beasts
and give the futex code a good work out ? Please tell your sysadmin
upfront that he should be stand by to fix up the resulting wreckage
which might vary from harmless to system replacement.
Unfortunately I was not able to track down the weird 32bit PAE
shutdown crash, so the affected users need to stick to the
nosmp-alternatives work around for now.
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.29.1-rt5 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.1.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29.1-rt5.bz2
The broken out patches are also available at the same download
locations.
Enjoy !
tglx
We are pleased to announce the next update to our new preempt-rt
series.
- rt locks fixes (Jan Blunck, tglx)
- kvm vs. -rt fixes (Jan Blunck)
- hpet interrupt fix (tglx, reported and tested by Hans Peter Bock)
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.29.1-rt6 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.1.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29.1-rt6.bz2
The broken out patches are also available at the same download
locations.
Enjoy !
tglx
Dear Thomas
Thank you for your notice about new rt patch.
I am running linux-2.6.29.1-rt6 on Q9300 with fedora 9 distribution
normally like belows. So I changed version from linux-2.6.29-rt2 to
linux-2.6.29.1-rt6.
I will test about a various case with linux-2.6.29.1-rt6 version.
[invain@fedora9 invain]$ uname -a
Linux fedora9 2.6.29.1-rt6-lgs #1 SMP PREEMPT RT Fri Apr 10 10:02:20
KST 2009 i686 i686 i386 GNU/Linux
[invain@fedora9 invain]$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz
stepping : 7
cpu MHz : 2494.087
cache size : 3072 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm
constant_tsc arch_perfmon pebs bts pni dtes64 monitor ds_cpl vmx smx
est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm tpr_shadow vnmi
flexpriority
bogomips : 4988.17
clflush size : 64
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz
stepping : 7
cpu MHz : 2494.087
cache size : 3072 KB
physical id : 0
siblings : 1
core id : 1
cpu cores : 4
apicid : 1
initial apicid : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm
constant_tsc arch_perfmon pebs bts pni dtes64 monitor ds_cpl vmx smx
est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm tpr_shadow vnmi
flexpriority
bogomips : 4987.23
clflush size : 64
power management:
processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz
stepping : 7
cpu MHz : 2494.087
cache size : 3072 KB
physical id : 0
siblings : 1
core id : 2
cpu cores : 4
apicid : 2
initial apicid : 2
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm
constant_tsc arch_perfmon pebs bts pni dtes64 monitor ds_cpl vmx smx
est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm tpr_shadow vnmi
flexpriority
bogomips : 4987.24
clflush size : 64
power management:
processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz
stepping : 7
cpu MHz : 2494.087
cache size : 3072 KB
physical id : 0
siblings : 1
core id : 3
cpu cores : 4
apicid : 3
initial apicid : 3
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm
constant_tsc arch_perfmon pebs bts pni dtes64 monitor ds_cpl vmx smx
est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm tpr_shadow vnmi
flexpriority
bogomips : 4987.28
clflush size : 64
power management:
[invain@fedora9 invain]$ cat /proc/meminfo
MemTotal: 3075816 kB
MemFree: 904416 kB
Buffers: 196168 kB
Cached: 1573864 kB
SwapCached: 0 kB
Active: 1079948 kB
Inactive: 990804 kB
Active(anon): 313180 kB
Inactive(anon): 0 kB
Active(file): 766768 kB
Inactive(file): 990804 kB
Unevictable: 2468 kB
Mlocked: 2468 kB
HighTotal: 2222408 kB
HighFree: 327460 kB
LowTotal: 853408 kB
LowFree: 576956 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 300 kB
Writeback: 0 kB
AnonPages: 303200 kB
Mapped: 86460 kB
Slab: 65668 kB
SReclaimable: 51816 kB
SUnreclaim: 13852 kB
PageTables: 4568 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 1537908 kB
Committed_AS: 719312 kB
VmallocTotal: 122880 kB
VmallocUsed: 45324 kB
VmallocChunk: 50164 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 4096 kB
DirectMap4k: 81912 kB
DirectMap4M: 823296 kB
[invain@fedora9 invain]$ sudo lspci
[sudo] password for invain:
00:00.0 Host bridge: Intel Corporation 82Q35 Express DRAM Controller (rev 02)
00:01.0 PCI bridge: Intel Corporation 82Q35 Express PCI Express Root
Port (rev 02)
00:03.0 Communication controller: Intel Corporation 82Q35 Express MEI
Controller (rev 02)
00:03.2 IDE interface: Intel Corporation 82Q35 Express PT IDER
Controller (rev 02)
00:03.3 Serial controller: Intel Corporation 82Q35 Express Serial KT
Controller (rev 02)
00:19.0 Ethernet controller: Intel Corporation 82566DM-2 Gigabit
Network Connection (rev 02)
00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB
UHCI Controller #4 (rev 02)
00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB
UHCI Controller #5 (rev 02)
00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB
UHCI Controller #6 (rev 02)
00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2
EHCI Controller #2 (rev 02)
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio
Controller (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB
UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB
UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB
UHCI Controller #3 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2
EHCI Controller #1 (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 92)
00:1f.0 ISA bridge: Intel Corporation 82801IO (ICH9DO) LPC Interface
Controller (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 4
port SATA IDE Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 02)
00:1f.5 IDE interface: Intel Corporation 82801I (ICH9 Family) 2 port
SATA IDE Controller (rev 02)
01:00.0 VGA compatible controller: nVidia Corporation GeForce 8500 GT (rev a1)
11:07.0 Ethernet controller: Intel Corporation 82557/8/9/0/1 Ethernet
Pro 100 (rev 10)
[invain@fedora9 invain]$
[invain@fedora9 invain]$
[invain@fedora9 tracing]$
[invain@fedora9 tracing]$ cd /
[invain@fedora9 /]$ ls /debug/tracing/ -al
합계 0
drwxr-xr-x 6 root root 0 2009-04-10 15:09 .
drwxr-xr-x 8 root root 0 2009-04-10 15:09 ..
-rw-r--r-- 1 root root 0 2009-04-10 15:09 README
-r--r--r-- 1 root root 0 2009-04-10 15:09 available_events
-r--r--r-- 1 root root 0 2009-04-10 15:09 available_filter_functions
-r--r--r-- 1 root root 0 2009-04-10 15:09 available_tracers
-rw-r--r-- 1 root root 0 2009-04-10 15:09 buffer_size_kb
-r--r--r-- 1 root root 0 2009-04-10 15:09 current_tracer
-r--r--r-- 1 root root 0 2009-04-10 15:09 dyn_ftrace_total_info
drwxr-xr-x 5 root root 0 2009-04-10 15:09 events
-r--r--r-- 1 root root 0 2009-04-10 15:09 failures
drwxr-xr-x 2 root root 0 2009-04-10 15:09 options
drwxr-xr-x 6 root root 0 2009-04-10 15:09 per_cpu
-r--r--r-- 1 root root 0 2009-04-10 15:09 printk_formats
-rw-r--r-- 1 root root 0 2009-04-10 15:09 set_event
-rw-r--r-- 1 root root 0 2009-04-10 15:09 set_ftrace_filter
-rw-r--r-- 1 root root 0 2009-04-10 15:09 set_ftrace_notrace
-rw-r--r-- 1 root root 0 2009-04-10 15:09 set_ftrace_pid
-r--r--r-- 1 root root 0 2009-04-10 15:09 set_graph_function
-rw-r--r-- 1 root root 0 2009-04-10 15:09 stack_max_size
-r--r--r-- 1 root root 0 2009-04-10 15:09 stack_trace
-rw-r--r-- 1 root root 0 2009-04-10 15:09 sysprof_sample_period
-rw-r--r-- 1 root root 0 2009-04-10 15:09 trace
--w--w---- 1 root root 0 2009-04-10 15:09 trace_marker
-rw-r--r-- 1 root root 0 2009-04-10 15:09 trace_options
-r--r--r-- 1 root root 0 2009-04-10 15:09 trace_pipe
drwxr-xr-x 2 root root 0 2009-04-10 15:09 trace_stat
-rw-r--r-- 1 root root 0 2009-04-10 15:09 tracing_cpumask
-rw-r--r-- 1 root root 0 2009-04-10 15:09 tracing_enabled
-rw-r--r-- 1 root root 0 2009-04-10 15:09 tracing_max_latency
-rw-r--r-- 1 root root 0 2009-04-10 15:09 tracing_on
-rw-r--r-- 1 root root 0 2009-04-10 15:09 tracing_thresh
[invain@fedora9 /]$
[invain@fedora9 /]$
[invain@fedora9 /]$ cat /debug/tracing/available_tracers
syscall blk kmemtrace power branch function_graph mmiotrace wakeup_rt
wakeup irqsoff function sched_switch initcall nop
[invain@fedora9 /]$
[invain@fedora9 tracing]$
[invain@fedora9 tracing]$
[invain@fedora9 tracing]$
[invain@fedora9 tracing]$ sudo cyclictest -t 10 -b 1000000 --context -D 10
could not set latency_hist/wakeup_latency/reset to 1
0.16 0.20 0.20 1/331 4338
T: 0 ( 4328) P: 0 I:1000 C: 8984 Min: 17 Act:13017 Avg: 8675 Max: 13498
T: 1 ( 4329) P: 0 I:1500 C: 5994 Min: 17 Act: 6048 Avg: 3982 Max: 6190
T: 2 ( 4330) P: 0 I:2000 C: 4498 Min: 17 Act: 2028 Avg: 1196 Max: 2759
T: 3 ( 4331) P: 0 I:2500 C: 3598 Min: 17 Act: 2517 Avg: 1494 Max: 2786
T: 4 ( 4332) P: 0 I:3000 C: 2999 Min: 17 Act: 18 Avg: 25 Max: 514
T: 5 ( 4333) P: 0 I:3500 C: 2571 Min: 17 Act: 18 Avg: 22 Max: 654
T: 6 ( 4334) P: 0 I:4000 C: 2249 Min: 17 Act: 25 Avg: 23 Max: 466
T: 7 ( 4335) P: 0 I:4500 C: 1993 Min: 17 Act:31521 Avg:19809 Max: 33231
T: 8 ( 4336) P: 0 I:5000 C: 1800 Min: 17 Act: 36 Avg: 29 Max: 1095
T: 9 ( 4337) P: 0 I:5500 C: 1636 Min: 17 Act: 29 Avg: 21 Max: 385
[invain@fedora9 tracing]$ tail trace
gedit-4093 [003] 4154503193.109679: 4093:120:D ==> [003]
3003:120:R Xorg
Xorg-3003 [003] 4154503193.109728: 3003:120:D ==> [003]
0:140:R <idle>
<idle>-0 [003] 4154503193.110171: 0:140:R + [003]
4327:120:D cyclictest
<idle>-0 [003] 4154503193.110176: 0:140:R ==> [003]
4327:120:R cyclictest
<idle>-0 [002] 4154503193.110217: 0:140:R + [002]
32: 49:D sirq-timer/2
<idle>-0 [002] 4154503193.110222: 0:140:R ==> [002]
32: 49:R sirq-timer/2
sirq-timer/2-32 [002] 4154503193.110230: 32: 49:D ==> [002]
0:140:R <idle>
cyclictest-4327 [003] 4154503193.110344: 4327:120:R + [003]
45: 49:D sirq-timer/3
cyclictest-4327 [003] 4154503193.110349: 4327:120:R ==> [003]
45: 49:R sirq-timer/3
sirq-timer/3-45 [003] 4154503193.110355: 45: 49:D ==> [003]
4327:120:R cyclictest
[invain@fedora9 tracing]$
Regards,
GeunSik Lim.
2009/4/10 Thomas Gleixner <[email protected]>:
> We are pleased to announce the next update to our new preempt-rt
> series.
>
> - rt locks fixes (Jan Blunck, tglx)
> - kvm vs. -rt fixes (Jan Blunck)
> - hpet interrupt fix (tglx, reported and tested by Hans Peter Bock)
>
> Download locations:
>
> http://rt.et.redhat.com/download/
> http://www.kernel.org/pub/linux/kernel/projects/rt/
>
> Information on the RT patch can be found at:
>
> http://rt.wiki.kernel.org/index.php/Main_Page
>
> to build the 2.6.29.1-rt6 tree, the following patches should be
> applied:
>
> http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.1.tar.bz2
> http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29.1-rt6.bz2
>
> The broken out patches are also available at the same download
> locations.
>
> Enjoy !
>
> tglx
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Regards,
GeunSik Lim
We are pleased to announce the next update to our new preempt-rt
series.
- futex testing fallout fix (Darren Hart)
- kvm vs. -rt fix resurrected (tglx)
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.29.1-rt7 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.1.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29.1-rt7.bz2
The broken out patches are also available at the same download
locations.
Enjoy !
tglx
We are pleased to announce the next update to our new preempt-rt
series.
- 32bit PAE SMP alternatives crash fixed (mainline fix)
- hrtimer UP deadlock fix (tglx)
- missing fixlets picked from -24/26 (clarkw, acme)
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.29.1-rt8 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.1.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29.1-rt8.bz2
The broken out patches are also available at the same download
locations.
Enjoy !
tglx
With PREEMPT_RT and HIGHMEM on ppc32 (8572ds eval board), there is a
lot of coredumps (data access, 0x300) very early in the boot
process. There is no problem when using only one of PREEMPT_RT or
HIGHMEM.
I also tried rt1 and rt7 and it's the same behavior.
Ccing linuxppc-dev in case someone already tried this configuration.
backtrace and registers dump:
(no debugging symbols found)
(no debugging symbols found)
Core was generated by `sed s/\/.*//'.
Program terminated with signal 11, Segmentation fault.
[New process 2189]
#0 0x10089fa8 in ?? ()
(gdb) bt
#0 0x10089fa8 in ?? ()
#1 0x10089f90 in ?? ()
#2 0x1006975c in ?? ()
#3 0x1005ceec in ?? ()
#4 0x1005d190 in ?? ()
#5 0x1005dd64 in ?? ()
#6 0x10000560 in ?? ()
#7 0x10000590 in ?? ()
#8 0x10000888 in ?? ()
#9 0x1009894c in ?? ()
#10 0x00000000 in ?? ()
(gdb) info register
r0 0x1 1
r1 0xbfc609e0 3217426912
r2 0x0 0
r3 0xd 13
r4 0x1009a0bc 269066428
r5 0x20082044 537403460
r6 0xd 13
r7 0x1007ccd4 268946644
r8 0x2d000 184320
r9 0x0 0
r10 0x0 0
r11 0xeee1df40 4007780160
r12 0xeee1c000 4007772160
r13 0x100cf11c 269283612
r14 0xbfd9cdb0 3218722224
r15 0xbfd9cda0 3218722208
r16 0x0 0
r17 0x0 0
r18 0x100aa854 269133908
r19 0x100a3aed 269105901
r20 0x0 0
r21 0x100d61ac 269312428
r22 0xbfd9c1c8 3218719176
r23 0x10000824 268437540
r24 0x0 0
r25 0xbfc60a38 3217427000
r26 0x0 0
r27 0x0 0
r28 0x0 0
r29 0x100c69a8 269248936
r30 0x100c7110 269250832
r31 0x100c69a8 269248936
pc 0x10089fa8 0x10089fa8
msr 0x2d900 186624
cr 0x40082044 1074274372
lr 0x10089f90 0x10089f90
ctr 0xc00feff0 3222269936
xer 0x20000000 536870912
orig_r3 0x0 0
trap 0x300 768
Thanks.
when using patch-2.6.29.1-rt8 with CONFIG_PREEMPT_SOFTIRQS=y, but not
enable PREEMPT_RT, there will be an error when linking kernel:
undefined reference to hrtimer_wait_for_timer
I found that, hrtimer_wait_for_timer is only defined when PREEMPT_RT is
enabled, but in include/linux/hrtimer.h, the source code is like this:
#ifdef CONFIG_PREEMPT_SOFTIRQS
extern void hrtimer_wait_for_timer(const struct hrtimer *timer);
#else
# define hrtimer_wait_for_timer(timer) do { cpu_relax(); } while (0)
a possible fix should be:
diff --git a/include/linux/hrtimer.h b/include/linux/hrtimer.h
index 8bafa35..1c1cdf3 100644
--- a/include/linux/hrtimer.h
+++ b/include/linux/hrtimer.h
@@ -366,7 +366,7 @@ static inline int hrtimer_restart(struct hrtimer
*timer)
}
/* Softirq preemption could deadlock timer removal */
-#ifdef CONFIG_PREEMPT_SOFTIRQS
+#if defined(CONFIG_PREEMPT_SOFTIRQS) && defined(CONFIG_PREEMPT_RT)
extern void hrtimer_wait_for_timer(const struct hrtimer *timer);
#else
# define hrtimer_wait_for_timer(timer) do { cpu_relax(); } while (0)
--
Wu Zhangjin
DSLab, Lanzhou University, China
http://www.lemote.com, Jiangsu Province, China
We are pleased to announce the next update to our new preempt-rt
series.
- hrtimer fix softirq handling
- x86/64 build fix for empty sections
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.29.1-rt9 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.1.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29.1-rt9.bz2
The broken out patches are also available at the same download
locations.
Enjoy !
tglx
We are pleased to announce the next update to our new preempt-rt
series.
- update to 2.6.29.2
- HPET/IOAPIC mainline fix
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.29.2-rt10 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.2.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29.2-rt10.bz2
The broken out patches are also available at the same download
locations.
Enjoy !
tglx