From: Thomas Gleixner <hidden> Date: 2011-07-24 10:33:42
Dear RT Folks,
I'm pleased to announce the 3.0-rt3 release.
Changes versus 3.0-rt2:
* Fix earlyprintk really
* AMD NB fix for allocation in smp function call, reported by Ed
* Disabled a few config options on RT which have known issues
Patch against 3.0 can be found here:
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-3.0-rt3.patch.bz2
The split quilt queue is available at:
http://www.kernel.org/pub/linux/kernel/projects/rt/patches-3.0-rt3.tar.bz2
Delta patch below.
Thanks,
tglx
----
arch/x86/include/asm/amd_nb.h | 6 +
arch/x86/kernel/cpu/intel_cacheinfo.c | 121 +++++++++++-----------------------
arch/x86/kernel/early_printk.c | 2
drivers/net/Kconfig | 1
localversion-rt | 2
mm/Kconfig | 2
6 files changed, 51 insertions(+), 83 deletions(-)
Index: linux-2.6/arch/x86/kernel/early_printk.c
===================================================================
@@ -333,33 +323,16 @@ static void __cpuinit amd_calc_l3_indicestaticvoid__cpuinitamd_init_l3_cache(struct_cpuid4_info_regs*this_leaf,intindex){-staticstructamd_l3_cache*__cpuinitdatal3_caches;intnode;/* only for L3, and not in virtualized environments */-if(index<3||amd_nb_num()==0)+if(index<3)return;-/*-*Strictlyspeaking,theamountin@sizebelowisleakedsinceitis-*neverfreedbutthisisdoneonlyonshutdownsoitdoesn'tmatter.-*/-if(!l3_caches){-intsize=amd_nb_num()*sizeof(structamd_l3_cache);--l3_caches=kzalloc(size,GFP_ATOMIC);-if(!l3_caches)-return;-}-node=amd_get_nb_id(smp_processor_id());--if(!l3_caches[node].nb){-l3_caches[node].nb=node_to_amd_nb(node);-amd_calc_l3_indices(&l3_caches[node]);-}--this_leaf->l3=&l3_caches[node];+this_leaf->nb=node_to_amd_nb(node);+if(this_leaf->nb&&!this_leaf->nb->l3_cache.indices)+amd_calc_l3_indices(this_leaf->nb);}/*
@@ -369,11 +342,11 @@ static void __cpuinit amd_init_l3_cache(**@returns:thedisabledindexifusedornegativevalueifslotfree.*/-intamd_get_l3_disable_slot(structamd_l3_cache*l3,unsignedslot)+intamd_get_l3_disable_slot(structamd_northbridge*nb,unsignedslot){unsignedintreg=0;-pci_read_config_dword(l3->nb->misc,0x1BC+slot*4,®);+pci_read_config_dword(nb->misc,0x1BC+slot*4,®);/* check whether this slot is activated already */if(reg&(3UL<<30))
@@ -448,24 +420,24 @@ static void amd_l3_disable_index(struct **@return:0onsuccess,errorstatusonfailure*/-intamd_set_l3_disable_slot(structamd_l3_cache*l3,intcpu,unsignedslot,+intamd_set_l3_disable_slot(structamd_northbridge*nb,intcpu,unsignedslot,unsignedlongindex){intret=0;/* check if @slot is already used or the index is already disabled */-ret=amd_get_l3_disable_slot(l3,slot);+ret=amd_get_l3_disable_slot(nb,slot);if(ret>=0)return-EINVAL;-if(index>l3->indices)+if(index>nb->l3_cache.indices)return-EINVAL;/* check whether the other slot has disabled the same index already */-if(index==amd_get_l3_disable_slot(l3,!slot))+if(index==amd_get_l3_disable_slot(nb,!slot))return-EINVAL;-amd_l3_disable_index(l3,cpu,slot,index);+amd_l3_disable_index(nb,cpu,slot,index);return0;}
@@ -820,29 +791,19 @@ static void __cpuinit free_cache_attribufor(i=0;i<num_cache_leaves;i++)cache_remove_shared_cpu_map(cpu,i);-kfree(per_cpu(ici_cpuid4_info,cpu)->l3);kfree(per_cpu(ici_cpuid4_info,cpu));per_cpu(ici_cpuid4_info,cpu)=NULL;}-staticint-__cpuinitcpuid4_cache_lookup(intindex,struct_cpuid4_info*this_leaf)-{-struct_cpuid4_info_regs*leaf_regs=-(struct_cpuid4_info_regs*)this_leaf;--returncpuid4_cache_lookup_regs(index,leaf_regs);-}-staticvoid__cpuinitget_cpu_leaves(void*_retval){intj,*retval=_retval,cpu=smp_processor_id();/* Do cpuid and store the results */for(j=0;j<num_cache_leaves;j++){-struct_cpuid4_info*this_leaf;-this_leaf=CPUID4_INFO_IDX(cpu,j);-*retval=cpuid4_cache_lookup(j,this_leaf);+struct_cpuid4_info*this_leaf=CPUID4_INFO_IDX(cpu,j);++*retval=cpuid4_cache_lookup_regs(j,&this_leaf->base);if(unlikely(*retval<0)){inti;
Dear RT Folks,
I'm pleased to announce the 3.0-rt3 release.
Changes versus 3.0-rt2:
* Fix earlyprintk really
Hi
I still have some trouble with rt1 - rt3.
During boot, the kernel is absolutely silent, sometimes it hangs on boot,
sometimes it hangs on login, sometimes it freeze without any known reason
during session (no heavy load or some thing like that).
I cant find any meaningful log, so I just can report it as it is here.
rc7-rt0 works very well here, I build 3.0-rt1 - rt3 with the same config
then rt0.
regards
hermann
From: Thomas Gleixner <hidden> Date: 2011-07-24 16:44:21
On Sun, 24 Jul 2011, hermann wrote:
I still have some trouble with rt1 - rt3.
During boot, the kernel is absolutely silent, sometimes it hangs on boot,
sometimes it hangs on login, sometimes it freeze without any known reason
during session (no heavy load or some thing like that).
I cant find any meaningful log, so I just can report it as it is here.
rc7-rt0 works very well here, I build 3.0-rt1 - rt3 with the same config
then rt0.
Hmm, can you please provide your .config and a demsg from a rc7-rt0 boot?
Thanks,
tglx
Am Sonntag, den 24.07.2011, 18:44 +0200 schrieb Thomas Gleixner:
On Sun, 24 Jul 2011, hermann wrote:
quoted
I still have some trouble with rt1 - rt3.
During boot, the kernel is absolutely silent, sometimes it hangs on boot,
sometimes it hangs on login, sometimes it freeze without any known reason
during session (no heavy load or some thing like that).
I cant find any meaningful log, so I just can report it as it is here.
rc7-rt0 works very well here, I build 3.0-rt1 - rt3 with the same config
then rt0.
Hmm, can you please provide your .config and a demsg from a rc7-rt0 boot?
Thanks,
tglx
On 2011-07-24 18:42 +0200, hermann wrote Thomas Gleixner:
Hi, I confirm it too - random freezes during normal work, no load, no logs too, sometimes
while starting X, sometimes after X started and worked, also randome freezes
while suspend-resume то ram aka ACPI S3 state.
h> schrieb Thomas Gleixner:
h>
h>> Dear RT Folks,
h>>
h>> I'm pleased to announce the 3.0-rt3 release.
h>>
h>> Changes versus 3.0-rt2:
h>>
h>> * Fix earlyprintk really
h>>
h>
h>Hi
h>
h>I still have some trouble with rt1 - rt3.
h>During boot, the kernel is absolutely silent, sometimes it hangs on boot,
h>sometimes it hangs on login, sometimes it freeze without any known reason
h>during session (no heavy load or some thing like that).
h>I cant find any meaningful log, so I just can report it as it is here.
h>rc7-rt0 works very well here, I build 3.0-rt1 - rt3 with the same config
h>then rt0.
h>
h>regards
h>hermann
h>
h>--
h>To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
h>the body of a message to majordomo@vger.kernel.org
h>More majordomo info at http://vger.kernel.org/majordomo-info.html
h>
C уважением With Best Regards
Георгиевский Юрий. Georgiewskiy Yuriy
+7 4872 711666 +7 4872 711666
факс +7 4872 711143 fax +7 4872 711143
Компания ООО "Ай Ти Сервис" IT Service Ltd
http://nkoort.ruhttp://nkoort.ru
JID: GHhost@icf.org.ru JID: GHhost@icf.org.ru
YG129-RIPE YG129-RIPE
From: Darren Hart <hidden> Date: 2011-07-25 22:20:05
On 07/24/2011 09:12 AM, Thomas Gleixner wrote:
On Sun, 24 Jul 2011, Maarten Lankhorst wrote:
...
quoted
Also not sure where this one came from:
[ 37.456688] BUG: spinlock bad magic on CPU#3, threaded-ml/1619
[ 37.456690] lock: ffff8801fdc74d50, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
[ 37.456692] Pid: 1619, comm: threaded-ml Tainted: G C 3.0.0-rt3-patser+ #39
[ 37.456693] Call Trace:
[ 37.456697] [<ffffffff81607a78>] spin_bug+0xa0/0xa8
[ 37.456699] [<ffffffff8132b412>] do_raw_spin_lock+0xa2/0x170
[ 37.456702] [<ffffffff8104a201>] ? get_parent_ip+0x11/0x50
[ 37.456704] [<ffffffff8160d783>] _raw_spin_lock+0x23/0x30
[ 37.456706] [<ffffffff810931ce>] rt_mutex_start_proxy_lock+0x2e/0xd0
[ 37.456708] [<ffffffff8109093a>] futex_requeue+0x47a/0x850
[ 37.456710] [<ffffffff8109138e>] do_futex+0xae/0xb00
[ 37.456712] [<ffffffff81157dcd>] ? fget_light+0x6d/0x110
[ 37.456714] [<ffffffff810b77b7>] ? audit_syscall_entry+0x2e7/0x310
[ 37.456715] [<ffffffff814c9375>] ? sys_recvmsg+0x75/0x90
[ 37.456717] [<ffffffff810923e6>] compat_sys_futex+0xf6/0x190
[ 37.456719] [<ffffffff8100e864>] ? syscall_trace_enter+0x184/0x210
[ 37.456721] [<ffffffff816158b3>] ia32_do_call+0x13/0x13
Urrgh, that's not a good one. Darren, can you please have a look at that?
Will do.
Maarten, what are you running when you hit this?
rt_mutex_start_proxy_lock() is only called by the requeue_pi code and
there is no libc support for that yet, so I'm surprised to see that in
the stack trace (unless you're running my futextest suite).
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
From: Frank Rowand <hidden> Date: 2011-07-26 03:12:42
On 07/24/11 03:33, Thomas Gleixner wrote:
Dear RT Folks,
I'm pleased to announce the 3.0-rt3 release.
ARM panda board boots for PREEMPT_RT_FULL, with a BUG:
Freeing init memory: 308K
BUG: sleeping function called from invalid context at kernel/rtmutex.c:645
in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper
1 lock held by swapper/0:
#0: (&irq_desc_lock_class){-.....}, at: [<c00ed470>] handle_fasteoi_irq+0x14/0x10c
irq event stamp: 21292
hardirqs last enabled at (21291): [<c0061ee0>] default_idle+0x2c/0x3c
hardirqs last disabled at (21292): [<c0484bb4>] __irq_svc+0x34/0x138
softirqs last enabled at (0): [< (null)>] (null)
softirqs last disabled at (0): [< (null)>] (null)
[<c00681b8>] (unwind_backtrace+0x0/0xf0) from [<c0483d20>] (rt_spin_lock+0x24/0x5c)
[<c0483d20>] (rt_spin_lock+0x24/0x5c) from [<c006df74>] (gic_mask_irq+0x28/0x7c)
[<c006df74>] (gic_mask_irq+0x28/0x7c) from [<c00ece20>] (mask_irq+0x1c/0x2c)
[<c00ece20>] (mask_irq+0x1c/0x2c) from [<c00ed514>] (handle_fasteoi_irq+0xb8/0x10c)
[<c00ed514>] (handle_fasteoi_irq+0xb8/0x10c) from [<c00ea724>] (generic_handle_irq+0x34/0x50)
[<c00ea724>] (generic_handle_irq+0x34/0x50) from [<c0055048>] (asm_do_IRQ+0x48/0xa8)
[<c0055048>] (asm_do_IRQ+0x48/0xa8) from [<c0484bd0>] (__irq_svc+0x50/0x138)
Exception stack(0xc0629f60 to 0xc0629fa8)
9f60: 00000001 00000001 00000000 0000532b c0628000 c06b6908 c048f7a0 00000000
9f80: c0649268 411fc092 c0649448 00000000 00000000 c0629fa8 c00d7750 c0061ee4
9fa0: 20000013 ffffffff
[<c0484bd0>] (__irq_svc+0x50/0x138) from [<c0061ee4>] (default_idle+0x30/0x3c)
[<c0061ee4>] (default_idle+0x30/0x3c) from [<c006253c>] (cpu_idle+0xc0/0x104)
[<c006253c>] (cpu_idle+0xc0/0x104) from [<c0008980>] (start_kernel+0x278/0x31c)
[<c0008980>] (start_kernel+0x278/0x31c) from [<80008040>] (0x80008040)
.config is attached or use this recipe:
make omap2plus_defconfig
Then additional config changes:
# this allows USB thumb drive
# Device Drivers -> USB support -> EHCI HCD (USB 2.0) support
CONFIG_USB_EHCI_HCD=y
# Device Drivers -> USB support -> EHCI support for OMAP3 and later chips
CONFIG_USB_EHCI_HCD_OMAP=y
# ethernet device
# Device Drivers -> Network device support -> USB Network Adapters ->
# Multi-purpose USB Networking Framework ->
# SMSC LAN95XX based USB 2.0 10/100 ethernet devices
CONFIG_USB_NET_SMSC95XX=y
# Kernel Features -> Preemption Model -> Fully Preemptible Kernel (RT)
-Frank
From: Frank Rowand <hidden> Date: 2011-07-26 03:14:12
On 07/24/11 03:33, Thomas Gleixner wrote:
Dear RT Folks,
I'm pleased to announce the 3.0-rt3 release.
ARM panda board boots for PREEMPT_NONE.
New compile warning for ARM pandaboard, PREEMPT_NONE:
kernel/softirq.c: In function 'softirq_check_pending_idle':
kernel/softirq.c:119: warning: format '%02lx' expects type 'long unsigned int', but argument 2 has type 'unsigned int'
.config is attached or use this recipe:
make omap2plus_defconfig
Then additional config changes:
# this allows USB thumb drive
# Device Drivers -> USB support -> EHCI HCD (USB 2.0) support
CONFIG_USB_EHCI_HCD=y
# Device Drivers -> USB support -> EHCI support for OMAP3 and later chips
CONFIG_USB_EHCI_HCD_OMAP=y
# ethernet device
# Device Drivers -> Network device support -> USB Network Adapters ->
# Multi-purpose USB Networking Framework ->
# SMSC LAN95XX based USB 2.0 10/100 ethernet devices
CONFIG_USB_NET_SMSC95XX=y
-Frank
From: Frank Rowand <hidden> Date: 2011-07-26 03:30:17
On 07/24/11 03:33, Thomas Gleixner wrote:
Dear RT Folks,
I'm pleased to announce the 3.0-rt3 release.
ARM panda board for PREEMPT_RT_FULL, new compile warnings:
kernel/softirq.c:105: warning: format '%02lx' expects type 'long unsigned int', but argument 2 has type 'u32'
kernel/trace/ring_buffer.c: In function 'trace_recursive_fail':
kernel/trace/ring_buffer.c:2217: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'int'
kernel/lockdep.c: In function 'print_bad_irq_dependency':
kernel/lockdep.c:1476: warning: format '%lu' expects type 'long unsigned int', but argument 7 has type 'int'
kernel/lockdep.c: In function 'print_usage_bug':
kernel/lockdep.c:2193: warning: format '%lu' expects type 'long unsigned int', but argument 7 has type 'int'
drivers/tty/serial/8250.c: In function 'serial8250_interrupt':
drivers/tty/serial/8250.c:1642: warning: unused variable 'pass_counter'
.config is attached or use this recipe:
make omap2plus_defconfig
Then additional config changes:
# this allows USB thumb drive
# Device Drivers -> USB support -> EHCI HCD (USB 2.0) support
CONFIG_USB_EHCI_HCD=y
# Device Drivers -> USB support -> EHCI support for OMAP3 and later chips
CONFIG_USB_EHCI_HCD_OMAP=y
# ethernet device
# Device Drivers -> Network device support -> USB Network Adapters ->
# Multi-purpose USB Networking Framework ->
# SMSC LAN95XX based USB 2.0 10/100 ethernet devices
CONFIG_USB_NET_SMSC95XX=y
# Kernel Features -> Preemption Model -> Fully Preemptible Kernel (RT)
-Frank
From: Darren Hart <hidden> Date: 2011-07-26 03:49:39
On 07/24/2011 03:33 AM, Thomas Gleixner wrote:
Dear RT Folks,
I'm pleased to announce the 3.0-rt3 release.
Changes versus 3.0-rt2:
* Fix earlyprintk really
Confirmed. The following kernel boot parameters now work correctly together:
"console=tty0 console=ttyS1,115200n8 earlyprintk=ttyS1,115200"
Thanks Thomas,
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
From: Darren Hart <hidden> Date: 2011-07-26 06:00:36
On 07/25/2011 03:20 PM, Darren Hart wrote:
On 07/24/2011 09:12 AM, Thomas Gleixner wrote:
quoted
On Sun, 24 Jul 2011, Maarten Lankhorst wrote:
...
quoted
quoted
Also not sure where this one came from:
[ 37.456688] BUG: spinlock bad magic on CPU#3, threaded-ml/1619
[ 37.456690] lock: ffff8801fdc74d50, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
[ 37.456692] Pid: 1619, comm: threaded-ml Tainted: G C 3.0.0-rt3-patser+ #39
[ 37.456693] Call Trace:
[ 37.456697] [<ffffffff81607a78>] spin_bug+0xa0/0xa8
[ 37.456699] [<ffffffff8132b412>] do_raw_spin_lock+0xa2/0x170
[ 37.456702] [<ffffffff8104a201>] ? get_parent_ip+0x11/0x50
[ 37.456704] [<ffffffff8160d783>] _raw_spin_lock+0x23/0x30
[ 37.456706] [<ffffffff810931ce>] rt_mutex_start_proxy_lock+0x2e/0xd0
[ 37.456708] [<ffffffff8109093a>] futex_requeue+0x47a/0x850
[ 37.456710] [<ffffffff8109138e>] do_futex+0xae/0xb00
[ 37.456712] [<ffffffff81157dcd>] ? fget_light+0x6d/0x110
[ 37.456714] [<ffffffff810b77b7>] ? audit_syscall_entry+0x2e7/0x310
[ 37.456715] [<ffffffff814c9375>] ? sys_recvmsg+0x75/0x90
[ 37.456717] [<ffffffff810923e6>] compat_sys_futex+0xf6/0x190
[ 37.456719] [<ffffffff8100e864>] ? syscall_trace_enter+0x184/0x210
[ 37.456721] [<ffffffff816158b3>] ia32_do_call+0x13/0x13
Urrgh, that's not a good one. Darren, can you please have a look at that?
Will do.
Maarten, what are you running when you hit this?
rt_mutex_start_proxy_lock() is only called by the requeue_pi code and
there is no libc support for that yet, so I'm surprised to see that in
the stack trace (unless you're running my futextest suite).
I've run a couple iterations of functional/run.sh from futextest which
exercises the requeue_pi code with no errors. I also wrote a new test to
improperly use the requeue_pi path, and the kernel properly detects the
abuse and kicks the user back with -EINVAL.
Could you try running futextest on your system to see if you can
reproduce the above? Specifically the functional/run.sh script (no need
to run the performance bits).
http://git.kernel.org/?p=linux/kernel/git/dvhart/futextest.git;a=summary
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
From: Thomas Gleixner <hidden> Date: 2011-07-26 09:01:52
On Mon, 25 Jul 2011, Darren Hart wrote:
On 07/24/2011 09:12 AM, Thomas Gleixner wrote:
quoted
On Sun, 24 Jul 2011, Maarten Lankhorst wrote:
...
quoted
quoted
Also not sure where this one came from:
[ 37.456688] BUG: spinlock bad magic on CPU#3, threaded-ml/1619
[ 37.456690] lock: ffff8801fdc74d50, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
[ 37.456692] Pid: 1619, comm: threaded-ml Tainted: G C 3.0.0-rt3-patser+ #39
[ 37.456693] Call Trace:
[ 37.456697] [<ffffffff81607a78>] spin_bug+0xa0/0xa8
[ 37.456699] [<ffffffff8132b412>] do_raw_spin_lock+0xa2/0x170
[ 37.456702] [<ffffffff8104a201>] ? get_parent_ip+0x11/0x50
[ 37.456704] [<ffffffff8160d783>] _raw_spin_lock+0x23/0x30
[ 37.456706] [<ffffffff810931ce>] rt_mutex_start_proxy_lock+0x2e/0xd0
[ 37.456708] [<ffffffff8109093a>] futex_requeue+0x47a/0x850
[ 37.456710] [<ffffffff8109138e>] do_futex+0xae/0xb00
[ 37.456712] [<ffffffff81157dcd>] ? fget_light+0x6d/0x110
[ 37.456714] [<ffffffff810b77b7>] ? audit_syscall_entry+0x2e7/0x310
[ 37.456715] [<ffffffff814c9375>] ? sys_recvmsg+0x75/0x90
[ 37.456717] [<ffffffff810923e6>] compat_sys_futex+0xf6/0x190
[ 37.456719] [<ffffffff8100e864>] ? syscall_trace_enter+0x184/0x210
[ 37.456721] [<ffffffff816158b3>] ia32_do_call+0x13/0x13
Urrgh, that's not a good one. Darren, can you please have a look at that?
Will do.
Maarten, what are you running when you hit this?
rt_mutex_start_proxy_lock() is only called by the requeue_pi code and
there is no libc support for that yet, so I'm surprised to see that in
the stack trace (unless you're running my futextest suite).
threaded-ml, whatever that is. I suspect that the changes to the futex
code, which I ported forward from 33-rt have some wreckage in it.
On Mon, Jul 25, 2011 at 03:55:21PM -0700, Fernando Lopez-Lezcano wrote:
On 07/24/2011 03:33 AM, Thomas Gleixner wrote:
quoted
Dear RT Folks,
I'm pleased to announce the 3.0-rt3 release.
Thanks!!... testing on a dual core laptop, fedora 15, 32 bit:
[ 32.169727] BUG: MAX_LOCKDEP_ENTRIES too low!
[ 32.169730] turning off the locking correctness validator.
(where do I change this?)
I'd guess you need to increase MAX_LOCKDEP_ENTRIES which is defined in
kernel/lockdep_internals.h.
BTW, I hit that, too.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
On Mon, Jul 25, 2011 at 08:12:09PM -0700, Frank Rowand wrote:
On 07/24/11 03:33, Thomas Gleixner wrote:
quoted
Dear RT Folks,
I'm pleased to announce the 3.0-rt3 release.
ARM panda board boots for PREEMPT_RT_FULL, with a BUG:
Freeing init memory: 308K
BUG: sleeping function called from invalid context at kernel/rtmutex.c:645
in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper
1 lock held by swapper/0:
#0: (&irq_desc_lock_class){-.....}, at: [<c00ed470>] handle_fasteoi_irq+0x14/0x10c
irq event stamp: 21292
hardirqs last enabled at (21291): [<c0061ee0>] default_idle+0x2c/0x3c
hardirqs last disabled at (21292): [<c0484bb4>] __irq_svc+0x34/0x138
softirqs last enabled at (0): [< (null)>] (null)
softirqs last disabled at (0): [< (null)>] (null)
[<c00681b8>] (unwind_backtrace+0x0/0xf0) from [<c0483d20>] (rt_spin_lock+0x24/0x5c)
[<c0483d20>] (rt_spin_lock+0x24/0x5c) from [<c006df74>] (gic_mask_irq+0x28/0x7c)
[<c006df74>] (gic_mask_irq+0x28/0x7c) from [<c00ece20>] (mask_irq+0x1c/0x2c)
[<c00ece20>] (mask_irq+0x1c/0x2c) from [<c00ed514>] (handle_fasteoi_irq+0xb8/0x10c)
[<c00ed514>] (handle_fasteoi_irq+0xb8/0x10c) from [<c00ea724>] (generic_handle_irq+0x34/0x50)
[<c00ea724>] (generic_handle_irq+0x34/0x50) from [<c0055048>] (asm_do_IRQ+0x48/0xa8)
[<c0055048>] (asm_do_IRQ+0x48/0xa8) from [<c0484bd0>] (__irq_svc+0x50/0x138)
I guess you need something like the patch below.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Thomas Gleixner <hidden> Date: 2011-07-26 09:25:08
On Tue, 26 Jul 2011, Uwe Kleine-König wrote:
On Mon, Jul 25, 2011 at 08:12:09PM -0700, Frank Rowand wrote:
quoted
On 07/24/11 03:33, Thomas Gleixner wrote:
quoted
Dear RT Folks,
I'm pleased to announce the 3.0-rt3 release.
ARM panda board boots for PREEMPT_RT_FULL, with a BUG:
Freeing init memory: 308K
BUG: sleeping function called from invalid context at kernel/rtmutex.c:645
in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper
1 lock held by swapper/0:
#0: (&irq_desc_lock_class){-.....}, at: [<c00ed470>] handle_fasteoi_irq+0x14/0x10c
irq event stamp: 21292
hardirqs last enabled at (21291): [<c0061ee0>] default_idle+0x2c/0x3c
hardirqs last disabled at (21292): [<c0484bb4>] __irq_svc+0x34/0x138
softirqs last enabled at (0): [< (null)>] (null)
softirqs last disabled at (0): [< (null)>] (null)
[<c00681b8>] (unwind_backtrace+0x0/0xf0) from [<c0483d20>] (rt_spin_lock+0x24/0x5c)
[<c0483d20>] (rt_spin_lock+0x24/0x5c) from [<c006df74>] (gic_mask_irq+0x28/0x7c)
[<c006df74>] (gic_mask_irq+0x28/0x7c) from [<c00ece20>] (mask_irq+0x1c/0x2c)
[<c00ece20>] (mask_irq+0x1c/0x2c) from [<c00ed514>] (handle_fasteoi_irq+0xb8/0x10c)
[<c00ed514>] (handle_fasteoi_irq+0xb8/0x10c) from [<c00ea724>] (generic_handle_irq+0x34/0x50)
[<c00ea724>] (generic_handle_irq+0x34/0x50) from [<c0055048>] (asm_do_IRQ+0x48/0xa8)
[<c0055048>] (asm_do_IRQ+0x48/0xa8) from [<c0484bd0>] (__irq_svc+0x50/0x138)
I guess you need something like the patch below.
Yep. Will add it to the other pile of ARM lock conversions.
On Mon, Jul 25, 2011 at 08:11:38PM -0700, Frank Rowand wrote:
On 07/24/11 03:33, Thomas Gleixner wrote:
quoted
Dear RT Folks,
I'm pleased to announce the 3.0-rt3 release.
ARM panda board boots for PREEMPT_NONE.
New compile warning for ARM pandaboard, PREEMPT_NONE:
kernel/softirq.c: In function 'softirq_check_pending_idle':
kernel/softirq.c:119: warning: format '%02lx' expects type 'long unsigned int', but argument 2 has type 'unsigned int'
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Also not sure where this one came from:
[ 37.456688] BUG: spinlock bad magic on CPU#3, threaded-ml/1619
[ 37.456690] lock: ffff8801fdc74d50, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
[ 37.456692] Pid: 1619, comm: threaded-ml Tainted: G C 3.0.0-rt3-patser+ #39
[ 37.456693] Call Trace:
[ 37.456697] [<ffffffff81607a78>] spin_bug+0xa0/0xa8
[ 37.456699] [<ffffffff8132b412>] do_raw_spin_lock+0xa2/0x170
[ 37.456702] [<ffffffff8104a201>] ? get_parent_ip+0x11/0x50
[ 37.456704] [<ffffffff8160d783>] _raw_spin_lock+0x23/0x30
[ 37.456706] [<ffffffff810931ce>] rt_mutex_start_proxy_lock+0x2e/0xd0
[ 37.456708] [<ffffffff8109093a>] futex_requeue+0x47a/0x850
[ 37.456710] [<ffffffff8109138e>] do_futex+0xae/0xb00
[ 37.456712] [<ffffffff81157dcd>] ? fget_light+0x6d/0x110
[ 37.456714] [<ffffffff810b77b7>] ? audit_syscall_entry+0x2e7/0x310
[ 37.456715] [<ffffffff814c9375>] ? sys_recvmsg+0x75/0x90
[ 37.456717] [<ffffffff810923e6>] compat_sys_futex+0xf6/0x190
[ 37.456719] [<ffffffff8100e864>] ? syscall_trace_enter+0x184/0x210
[ 37.456721] [<ffffffff816158b3>] ia32_do_call+0x13/0x13
Urrgh, that's not a good one. Darren, can you please have a look at that?
Will do.
Maarten, what are you running when you hit this?
rt_mutex_start_proxy_lock() is only called by the requeue_pi code and
there is no libc support for that yet, so I'm surprised to see that in
the stack trace (unless you're running my futextest suite).
I've run a couple iterations of functional/run.sh from futextest which
exercises the requeue_pi code with no errors. I also wrote a new test to
improperly use the requeue_pi path, and the kernel properly detects the
abuse and kicks the user back with -EINVAL.
Could you try running futextest on your system to see if you can
reproduce the above? Specifically the functional/run.sh script (no need
to run the performance bits).
http://git.kernel.org/?p=linux/kernel/git/dvhart/futextest.git;a=summary
Same bug if I just call run.sh, it happens in futex_requeue_pi -b
I attached my kernel config file in case it's needed to trigger.
It only happens once, after that I have to reboot to trigger it again.
The tid matches the waker thread. You probably have to run it before
pulseaudio is started because sometimes I get that error on that one
too.
~Maarten
From: Darren Hart <hidden> Date: 2011-07-26 17:02:04
On 07/26/2011 04:44 AM, Maarten Lankhorst wrote:
On 07/26/2011 08:00 AM, Darren Hart wrote:
quoted
On 07/25/2011 03:20 PM, Darren Hart wrote:
quoted
On 07/24/2011 09:12 AM, Thomas Gleixner wrote:
quoted
On Sun, 24 Jul 2011, Maarten Lankhorst wrote:
...
quoted
quoted
Also not sure where this one came from:
[ 37.456688] BUG: spinlock bad magic on CPU#3, threaded-ml/1619
[ 37.456690] lock: ffff8801fdc74d50, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
[ 37.456692] Pid: 1619, comm: threaded-ml Tainted: G C 3.0.0-rt3-patser+ #39
Maarten, I'm finding fairly little out there on what threaded-ml might
be. What I do find suggests 3D visualization and real-time audio
playback. Are you working with something like this? If so, which
libraries are you using? If not, any idea what this is?
Maarten, could you provide the addr2line of the addresses from do_futex
to spin_bug ? This will help me trace the path.
Thanks,
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
Also not sure where this one came from:
[ 37.456688] BUG: spinlock bad magic on CPU#3, threaded-ml/1619
[ 37.456690] lock: ffff8801fdc74d50, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
[ 37.456692] Pid: 1619, comm: threaded-ml Tainted: G C 3.0.0-rt3-patser+ #39
Maarten, I'm finding fairly little out there on what threaded-ml might
be. What I do find suggests 3D visualization and real-time audio
playback. Are you working with something like this? If so, which
libraries are you using? If not, any idea what this is?
threaded ml = from pulseaudio,
src/pulse/thread-mainloop.c to be exact. But like I said it occurs with the functional broadcast test too, on the waker thread.
From: Fernando Lopez-Lezcano <hidden> Date: 2011-07-26 23:52:41
On 07/26/2011 02:13 AM, Uwe Kleine-König wrote:
On Mon, Jul 25, 2011 at 03:55:21PM -0700, Fernando Lopez-Lezcano wrote:
quoted
On 07/24/2011 03:33 AM, Thomas Gleixner wrote:
quoted
Dear RT Folks,
I'm pleased to announce the 3.0-rt3 release.
Thanks!!... testing on a dual core laptop, fedora 15, 32 bit:
[ 32.169727] BUG: MAX_LOCKDEP_ENTRIES too low!
[ 32.169730] turning off the locking correctness validator.
(where do I change this?)
I'd guess you need to increase MAX_LOCKDEP_ENTRIES which is defined in
kernel/lockdep_internals.h.
BTW, I hit that, too.
Thanks, I upped that to 32768 (16384) but on boot I got another
complaint about MAX_LOCKDEP_CHAINS so I changed MAX_LOCKDEP_CHAIN_BITS
from 15 to 31 and, well, the kernel build complains about "size of array
'local_chains' is too large" (chain_hlocks as well) and does not build...
Oh well...
-- Fernando
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Fernando Lopez-Lezcano <hidden> Date: 2011-07-26 23:58:04
On 07/26/2011 04:52 PM, Fernando Lopez-Lezcano wrote:
On 07/26/2011 02:13 AM, Uwe Kleine-König wrote:
quoted
On Mon, Jul 25, 2011 at 03:55:21PM -0700, Fernando Lopez-Lezcano wrote:
quoted
On 07/24/2011 03:33 AM, Thomas Gleixner wrote:
quoted
Dear RT Folks,
I'm pleased to announce the 3.0-rt3 release.
Thanks!!... testing on a dual core laptop, fedora 15, 32 bit:
[ 32.169727] BUG: MAX_LOCKDEP_ENTRIES too low!
[ 32.169730] turning off the locking correctness validator.
(where do I change this?)
I'd guess you need to increase MAX_LOCKDEP_ENTRIES which is defined in
kernel/lockdep_internals.h.
BTW, I hit that, too.
Thanks, I upped that to 32768 (16384) but on boot I got another
complaint about MAX_LOCKDEP_CHAINS so I changed MAX_LOCKDEP_CHAIN_BITS
from 15 to 31 and, well, the kernel build complains about "size of array
'local_chains' is too large" (chain_hlocks as well) and does not build...
Oh well...
(I meant to myself - of COURSE, _think_ before changing things and
meditate about the implications of power mathematical operations).
:-)
-- Fernando
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Darren Hart <hidden> Date: 2011-07-27 01:57:58
On 07/26/2011 10:11 AM, Maarten Lankhorst wrote:
On 07/26/2011 07:01 PM, Darren Hart wrote:
quoted
On 07/26/2011 04:44 AM, Maarten Lankhorst wrote:
quoted
On 07/26/2011 08:00 AM, Darren Hart wrote:
quoted
On 07/25/2011 03:20 PM, Darren Hart wrote:
quoted
On 07/24/2011 09:12 AM, Thomas Gleixner wrote:
quoted
On Sun, 24 Jul 2011, Maarten Lankhorst wrote:
...
quoted
quoted
Also not sure where this one came from:
[ 37.456688] BUG: spinlock bad magic on CPU#3, threaded-ml/1619
[ 37.456690] lock: ffff8801fdc74d50, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
[ 37.456692] Pid: 1619, comm: threaded-ml Tainted: G C 3.0.0-rt3-patser+ #39
Maarten, I'm finding fairly little out there on what threaded-ml might
be. What I do find suggests 3D visualization and real-time audio
playback. Are you working with something like this? If so, which
libraries are you using? If not, any idea what this is?
threaded ml = from pulseaudio,
src/pulse/thread-mainloop.c to be exact. But like I said it occurs with the functional broadcast test too, on the waker thread.
Maarten, could you provide the addr2line of the addresses from do_futex
to spin_bug ? This will help me trace the path.
decodes to:
linux/lib/spinlock_debug.c:72
linux/lib/spinlock_debug.c:79
linux/kernel/sched.c:4114
linux/kernel/spinlock.c:141
linux/kernel/rtmutex.c:100
linux/kernel/futex.c:1378
linux/kernel/futex.c:2662
OK, so we're entering with a FUTEX_CMP_REQUEUE op (not FUTEX_CMP_REQUEUE_PI),
and land inside an "if (requeue_pi)" block in the futex_requeue() function -
that should never happen. The interesting thing about this is pulse is only
using the non PI pthread_cond calls, and thus FUTEX_CMP_REQUEUE,
(http://gitorious.org/~elmarco/pulseaudio/pa-work/blobs/1ca76031092ab07682843fd70607696f6af7216f/src/pulsecore/mutex-posix.c). I have not been able reproduce this path.
My best guess at the moment is that we are somehow stomping on the requeue_pi
value causing the waker to enter the wrong code paths. A simple test would be to
print the value of requeue_pi throughout futex_requeue() and see if it changes
(it shouldn't) and if it is something other than 0 or 1 (which it should never
be). Are you able to reliably reproduce the pulse audio failure?
The futex_requeue_pi test is of course using FUTEX_CMP_REQUEUE_PI, and it will
reproduce a similar path (except via the FUTEX_CMP_REQUEUE_PI demux path as it
should be) on the first time run, as Maarten observed. I have seen this with
and without the -b (broadcast) option to the test.
I was able to reproduce this on my system by adding the following to my config:
+CONFIG_DEBUG_RT_MUTEXES=y
+CONFIG_DEBUG_PI_LIST=y
+CONFIG_DEBUG_SPINLOCK=y
With a similar config, this does not occur on 2.6.33.9-rt31. Nothing jumps out
as obviously wrong in the futex delta from 33-rt to now.
I tried with 3.0.0 (non rt) with a similar .config and the problem is not
reproducible. I'll continue to try and isolate the problem, focusing mainly on
the futex delta from 3.0.0. Right after I get the kids to bed...
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
From: Darren Hart <hidden> Date: 2011-07-27 08:25:21
On 07/26/2011 06:57 PM, Darren Hart wrote:
On 07/26/2011 10:11 AM, Maarten Lankhorst wrote:
quoted
On 07/26/2011 07:01 PM, Darren Hart wrote:
quoted
On 07/26/2011 04:44 AM, Maarten Lankhorst wrote:
quoted
On 07/26/2011 08:00 AM, Darren Hart wrote:
quoted
On 07/25/2011 03:20 PM, Darren Hart wrote:
quoted
On 07/24/2011 09:12 AM, Thomas Gleixner wrote:
quoted
On Sun, 24 Jul 2011, Maarten Lankhorst wrote:
...
quoted
quoted
Also not sure where this one came from:
[ 37.456688] BUG: spinlock bad magic on CPU#3, threaded-ml/1619
[ 37.456690] lock: ffff8801fdc74d50, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
[ 37.456692] Pid: 1619, comm: threaded-ml Tainted: G C 3.0.0-rt3-patser+ #39
Maarten, I'm finding fairly little out there on what threaded-ml might
be. What I do find suggests 3D visualization and real-time audio
playback. Are you working with something like this? If so, which
libraries are you using? If not, any idea what this is?
threaded ml = from pulseaudio,
src/pulse/thread-mainloop.c to be exact. But like I said it occurs with the functional broadcast test too, on the waker thread.
Maarten, could you provide the addr2line of the addresses from do_futex
to spin_bug ? This will help me trace the path.
decodes to:
linux/lib/spinlock_debug.c:72
linux/lib/spinlock_debug.c:79
linux/kernel/sched.c:4114
linux/kernel/spinlock.c:141
linux/kernel/rtmutex.c:100
linux/kernel/futex.c:1378
linux/kernel/futex.c:2662
OK, so we're entering with a FUTEX_CMP_REQUEUE op (not FUTEX_CMP_REQUEUE_PI),
and land inside an "if (requeue_pi)" block in the futex_requeue() function -
that should never happen. The interesting thing about this is pulse is only
using the non PI pthread_cond calls, and thus FUTEX_CMP_REQUEUE,
(http://gitorious.org/~elmarco/pulseaudio/pa-work/blobs/1ca76031092ab07682843fd70607696f6af7216f/src/pulsecore/mutex-posix.c). I have not been able reproduce this path.
My best guess at the moment is that we are somehow stomping on the requeue_pi
value causing the waker to enter the wrong code paths. A simple test would be to
print the value of requeue_pi throughout futex_requeue() and see if it changes
(it shouldn't) and if it is something other than 0 or 1 (which it should never
be). Are you able to reliably reproduce the pulse audio failure?
The futex_requeue_pi test is of course using FUTEX_CMP_REQUEUE_PI, and it will
reproduce a similar path (except via the FUTEX_CMP_REQUEUE_PI demux path as it
should be) on the first time run, as Maarten observed. I have seen this with
and without the -b (broadcast) option to the test.
I was able to reproduce this on my system by adding the following to my config:
+CONFIG_DEBUG_RT_MUTEXES=y
+CONFIG_DEBUG_PI_LIST=y
+CONFIG_DEBUG_SPINLOCK=y
With a similar config, this does not occur on 2.6.33.9-rt31. Nothing jumps out
as obviously wrong in the futex delta from 33-rt to now.
I tried with 3.0.0 (non rt) with a similar .config and the problem is not
reproducible. I'll continue to try and isolate the problem, focusing mainly on
the futex delta from 3.0.0. Right after I get the kids to bed...
I believe this is now fixed with:
https://lkml.org/lkml/2011/7/27/74
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
From: Sebastian Ohl <hidden> Date: 2011-07-27 17:00:51
Hey folks,
i just tried to compile the new rt patch and i was wondering why i
cannot select 4GB or 64GB of memory if i am selecting full preemption?
in my old rt kernel (2.6.33.1) this hasn't been a problem.
what are the implications if i am using only the basic RT option?
Regards
Sebastian Ohl
--
Dipl.-Inform. Sebastian Ohl
Institut für Regelungstechnik | Tel.(BS): (0531) 391-3824
Lehrstuhl für el. Fahrzeugsysteme | Tel.(WOB): (0531) 391-63057
TU Braunschweig | Fax: (0531) 391-5194
http://www.ifr.ing.tu-bs.de | Email: ohl@ifr.ing.tu-bs.de
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
@@ -333,33 +323,16 @@ static void __cpuinit amd_calc_l3_indicestaticvoid__cpuinitamd_init_l3_cache(struct_cpuid4_info_regs*this_leaf,intindex){-staticstructamd_l3_cache*__cpuinitdatal3_caches;intnode;/* only for L3, and not in virtualized environments */-if(index<3||amd_nb_num()==0)+if(index<3)return;-/*-*Strictlyspeaking,theamountin@sizebelowisleakedsinceitis-*neverfreedbutthisisdoneonlyonshutdownsoitdoesn'tmatter.-*/-if(!l3_caches){-intsize=amd_nb_num()*sizeof(structamd_l3_cache);--l3_caches=kzalloc(size,GFP_ATOMIC);-if(!l3_caches)-return;-}-node=amd_get_nb_id(smp_processor_id());--if(!l3_caches[node].nb){-l3_caches[node].nb=node_to_amd_nb(node);-amd_calc_l3_indices(&l3_caches[node]);-}--this_leaf->l3=&l3_caches[node];+this_leaf->nb=node_to_amd_nb(node);+if(this_leaf->nb&&!this_leaf->nb->l3_cache.indices)+amd_calc_l3_indices(this_leaf->nb);}/*
@@ -369,11 +342,11 @@ static void __cpuinit amd_init_l3_cache(**@returns:thedisabledindexifusedornegativevalueifslotfree.*/-intamd_get_l3_disable_slot(structamd_l3_cache*l3,unsignedslot)+intamd_get_l3_disable_slot(structamd_northbridge*nb,unsignedslot){unsignedintreg=0;-pci_read_config_dword(l3->nb->misc,0x1BC+slot*4,®);+pci_read_config_dword(nb->misc,0x1BC+slot*4,®);/* check whether this slot is activated already */if(reg&(3UL<<30))
@@ -448,24 +420,24 @@ static void amd_l3_disable_index(struct**@return:0onsuccess,errorstatusonfailure*/-intamd_set_l3_disable_slot(structamd_l3_cache*l3,intcpu,unsignedslot,+intamd_set_l3_disable_slot(structamd_northbridge*nb,intcpu,unsignedslot,unsignedlongindex){intret=0;/* check if @slot is already used or the index is already disabled */-ret=amd_get_l3_disable_slot(l3,slot);+ret=amd_get_l3_disable_slot(nb,slot);if(ret>=0)return-EINVAL;-if(index>l3->indices)+if(index>nb->l3_cache.indices)return-EINVAL;/* check whether the other slot has disabled the same index already */-if(index==amd_get_l3_disable_slot(l3,!slot))+if(index==amd_get_l3_disable_slot(nb,!slot))return-EINVAL;-amd_l3_disable_index(l3,cpu,slot,index);+amd_l3_disable_index(nb,cpu,slot,index);return0;}
@@ -820,29 +791,19 @@ static void __cpuinit free_cache_attribufor(i=0;i<num_cache_leaves;i++)cache_remove_shared_cpu_map(cpu,i);-kfree(per_cpu(ici_cpuid4_info,cpu)->l3);kfree(per_cpu(ici_cpuid4_info,cpu));per_cpu(ici_cpuid4_info,cpu)=NULL;}-staticint-__cpuinitcpuid4_cache_lookup(intindex,struct_cpuid4_info*this_leaf)-{-struct_cpuid4_info_regs*leaf_regs=-(struct_cpuid4_info_regs*)this_leaf;--returncpuid4_cache_lookup_regs(index,leaf_regs);-}-staticvoid__cpuinitget_cpu_leaves(void*_retval){intj,*retval=_retval,cpu=smp_processor_id();/* Do cpuid and store the results */for(j=0;j<num_cache_leaves;j++){-struct_cpuid4_info*this_leaf;-this_leaf=CPUID4_INFO_IDX(cpu,j);-*retval=cpuid4_cache_lookup(j,this_leaf);+struct_cpuid4_info*this_leaf=CPUID4_INFO_IDX(cpu,j);++*retval=cpuid4_cache_lookup_regs(j,&this_leaf->base);if(unlikely(*retval<0)){inti;
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Thomas Gleixner <hidden> Date: 2011-07-27 18:32:44
On Wed, 27 Jul 2011, N, Mugunthan V wrote:
Please do not top post.
I am testing 3.0-rt3 on AM3517 - Arm Cortex A8. As the kernel from the
mainline is not booting I am using a patch to boot AM3517 kernel on top of
the mainline kernel. Its crashing when I start hackbench and cyclictest.
There were two warnings while starting the test and then the kernel crashes.
Attaching the patch and the rt-config file.
[ 266.001220] BUG: sleeping function called from invalid context at
kernel/rtmutex.c:645
That should be fixed by the patch below.
[ 267.494995] ------------[ cut here ]------------
[ 267.495086] WARNING: at kernel/lockdep.c:939 __bfs+0x1f8/0x254()
Could you please disable CONFIG_RCU_BOOST ?
Thanks,
tglx
Index: linux-2.6/arch/arm/include/asm/mmu.h
===================================================================
From: Thomas Gleixner <hidden> Date: 2011-07-27 21:50:01
On Wed, 27 Jul 2011, Sebastian Ohl wrote:
Hey folks,
i just tried to compile the new rt patch and i was wondering why i
cannot select 4GB or 64GB of memory if i am selecting full preemption?
in my old rt kernel (2.6.33.1) this hasn't been a problem.
As I sadi elsewhere I dropped highmem support for now as the 33-rt
hackery to make it work is just ugly as hell and anything above 4G is
even in mainline a complete disaster.
If possible, just run a 64bit kernel on your machine (you can still
use 32bit userspace) or you have to wait until someone comes up with a
reasonable fix for that problem, unless you are the one tackling it :)
Thanks,
tglx