Dear RT folks!
I'm pleased to announce the v3.12.8-rt11 patch set.
Changes since v3.12.8-rt10
- The "do not to raise the timer softirq unconditionally" resulted a few
boot lockups on a few boxes. Steven found the problem and sent a fix.
Thank you Steven.
- A compile fix to "do not to raise the timer softirq unconditionally"
patch to compile without RT enabled.
- Brian Silverman reported a BUG (Debian #723180) where gdb's
record command does something nasty and causes a double fault on
x86-64 kernel with 32bit userland (the debugged application).
The problem was a RT specific patch which has been reverted
- Sami Pietikäinen reported a crash in __ip_make_skb(). Nicholas
Mc Guire posted a patch for it, thank you Nicholas.
- A patch from Steven to document why we need a spinlock in struct
hotplug_pcp
- Don't unwind on ARM if called from irq_disabled() regions. This may
cause a lockup with debug object enabled while loading a module.
There is also a patch in the queue from Paul E. McKenney to move RCU
processing from softirq into its own thread. After Mike Galbraith
reported a few RCU stalls I decided to keep it disabled for now.
Steven's fix may have fixed the problem. If nothing else comes up I will
try to enable it in the next release.
Known issues:
- bcache is disabled.
The delta patch against v3.12.8-rt11 is appended below and can be found
here:
https://www.kernel.org/pub/linux/kernel/projects/rt/3.12/incr/patch-3.12.8-rt10-rt11.patch.xz
The RT patch against 3.12.8 can be found here:
https://www.kernel.org/pub/linux/kernel/projects/rt/3.12/patch-3.12.8-rt11.patch.xz
The split quilt queue is available at:
https://www.kernel.org/pub/linux/kernel/projects/rt/3.12/patches-3.12.8-rt11.tar.xz
Sebastian
diff --git a/arch/arm/kernel/unwind.c b/arch/arm/kernel/unwind.c
index 00df012..2af232d 100644
--- a/arch/arm/kernel/unwind.c
+++ b/arch/arm/kernel/unwind.c
@@ -195,6 +195,11 @@ static const struct unwind_idx *unwind_find_idx(unsigned long addr)
/* module unwind tables */
struct unwind_table *table;
+#ifdef CONFIG_PREEMPT_RT_FULL
+ if (irqs_disabled())
+ goto out;
+#endif
+
spin_lock_irqsave(&unwind_lock, flags);
list_for_each_entry(table, &unwind_tables, list) {
if (addr >= table->begin_addr &&
@@ -211,6 +216,7 @@ static const struct unwind_idx *unwind_find_idx(unsigned long addr)
}
pr_debug("%s: idx = %p\n", __func__, idx);
+out:
return idx;
}
@@ -345,7 +351,9 @@ int unwind_frame(struct stackframe *frame)
idx = unwind_find_idx(frame->pc);
if (!idx) {
+#ifndef CONFIG_PREEMPT_RT_FULL
pr_warning("unwind: Index not found %08lx\n", frame->pc);
+#endif
return -URC_FAILURE;
}
diff --git a/arch/x86/include/asm/page_64_types.h b/arch/x86/include/asm/page_64_types.h
index 695e04d..43dcd80 100644
--- a/arch/x86/include/asm/page_64_types.h
+++ b/arch/x86/include/asm/page_64_types.h
@@ -14,21 +14,12 @@
#define IRQ_STACK_ORDER 2
#define IRQ_STACK_SIZE (PAGE_SIZE << IRQ_STACK_ORDER)
-#ifdef CONFIG_PREEMPT_RT_FULL
-# define STACKFAULT_STACK 0
-# define DOUBLEFAULT_STACK 1
-# define NMI_STACK 2
-# define DEBUG_STACK 0
-# define MCE_STACK 3
-# define N_EXCEPTION_STACKS 3 /* hw limit: 7 */
-#else
-# define STACKFAULT_STACK 1
-# define DOUBLEFAULT_STACK 2
-# define NMI_STACK 3
-# define DEBUG_STACK 4
-# define MCE_STACK 5
-# define N_EXCEPTION_STACKS 5 /* hw limit: 7 */
-#endif
+#define STACKFAULT_STACK 1
+#define DOUBLEFAULT_STACK 2
+#define NMI_STACK 3
+#define DEBUG_STACK 4
+#define MCE_STACK 5
+#define N_EXCEPTION_STACKS 5 /* hw limit: 7 */
#define PUD_PAGE_SIZE (_AC(1, UL) << PUD_SHIFT)
#define PUD_PAGE_MASK (~(PUD_PAGE_SIZE-1))
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index c0dcf06..2793d1f 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1105,9 +1105,7 @@ DEFINE_PER_CPU(struct task_struct *, fpu_owner_task);
*/
static const unsigned int exception_stack_sizes[N_EXCEPTION_STACKS] = {
[0 ... N_EXCEPTION_STACKS - 1] = EXCEPTION_STKSZ,
-#if DEBUG_STACK > 0
[DEBUG_STACK - 1] = DEBUG_STKSZ
-#endif
};
static DEFINE_PER_CPU_PAGE_ALIGNED(char, exception_stacks
diff --git a/arch/x86/kernel/dumpstack_64.c b/arch/x86/kernel/dumpstack_64.c
index 52b4bcd..addb207 100644
--- a/arch/x86/kernel/dumpstack_64.c
+++ b/arch/x86/kernel/dumpstack_64.c
@@ -21,14 +21,10 @@
(N_EXCEPTION_STACKS + DEBUG_STKSZ/EXCEPTION_STKSZ - 2)
static char x86_stack_ids[][8] = {
-#if DEBUG_STACK > 0
[ DEBUG_STACK-1 ] = "#DB",
-#endif
[ NMI_STACK-1 ] = "NMI",
[ DOUBLEFAULT_STACK-1 ] = "#DF",
-#if STACKFAULT_STACK > 0
[ STACKFAULT_STACK-1 ] = "#SS",
-#endif
[ MCE_STACK-1 ] = "#MC",
#if DEBUG_STKSZ > EXCEPTION_STKSZ
[ N_EXCEPTION_STACKS ...
diff --git a/kernel/cpu.c b/kernel/cpu.c
index c36b075..ba7416b 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -85,6 +85,14 @@ struct hotplug_pcp {
struct completion synced;
struct completion unplug_wait;
#ifdef CONFIG_PREEMPT_RT_FULL
+ /*
+ * Note, on PREEMPT_RT, the hotplug lock must save the state of
+ * the task, otherwise the mutex will cause the task to fail
+ * to sleep when required. (Because it's called from migrate_disable())
+ *
+ * The spinlock_t on PREEMPT_RT is a mutex that saves the task's
+ * state.
+ */
spinlock_t lock;
#else
struct mutex mutex;
diff --git a/kernel/timer.c b/kernel/timer.c
index 46467be..106968f 100644
--- a/kernel/timer.c
+++ b/kernel/timer.c
@@ -1460,19 +1460,29 @@ void run_local_timers(void)
* interrupt. If there are no timers queued, nothing to do in
* the timer softirq.
*/
+#ifdef CONFIG_PREEMPT_RT_FULL
if (!spin_do_trylock(&base->lock)) {
raise_softirq(TIMER_SOFTIRQ);
return;
}
- if (!base->active_timers)
- goto out;
+#endif
+ if (!base->active_timers) {
+#ifdef CONFIG_PREEMPT_RT_FULL
+ /* On RT, irq work runs from softirq */
+ if (!irq_work_needs_cpu())
+#endif
+ goto out;
+ }
/* Check whether the next pending timer has expired */
if (time_before_eq(base->next_timer, jiffies))
raise_softirq(TIMER_SOFTIRQ);
out:
+#ifdef CONFIG_PREEMPT_RT_FULL
rt_spin_unlock_after_trylock_in_irq(&base->lock);
-
+#endif
+ /* The ; ensures that gcc won't complain in the !RT case */
+ ;
}
#ifdef __ARCH_WANT_SYS_ALARM
diff --git a/localversion-rt b/localversion-rt
index d79dde6..05c35cb 100644
--- a/localversion-rt
+++ b/localversion-rt
@@ -1 +1 @@
--rt10
+-rt11
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index e9fa68c..8bb3b4a 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -79,6 +79,7 @@
#include <linux/mroute.h>
#include <linux/netlink.h>
#include <linux/tcp.h>
+#include <linux/locallock.h>
int sysctl_ip_default_ttl __read_mostly = IPDEFTTL;
EXPORT_SYMBOL(sysctl_ip_default_ttl);
@@ -1468,6 +1469,9 @@ static DEFINE_PER_CPU(struct inet_sock, unicast_sock) = {
.uc_ttl = -1,
};
+/* serialize concurrent calls on the same CPU to ip_send_unicast_reply */
+static DEFINE_LOCAL_IRQ_LOCK(unicast_lock);
+
void ip_send_unicast_reply(struct net *net, struct sk_buff *skb, __be32 daddr,
__be32 saddr, const struct ip_reply_arg *arg,
unsigned int len)
@@ -1505,8 +1509,7 @@ void ip_send_unicast_reply(struct net *net, struct sk_buff *skb, __be32 daddr,
if (IS_ERR(rt))
return;
- get_cpu_light();
- inet = &__get_cpu_var(unicast_sock);
+ inet = &get_locked_var(unicast_lock, unicast_sock);
inet->tos = arg->tos;
sk = &inet->sk;
@@ -1530,7 +1533,7 @@ void ip_send_unicast_reply(struct net *net, struct sk_buff *skb, __be32 daddr,
ip_push_pending_frames(sk, &fl4);
}
- put_cpu_light();
+ put_locked_var(unicast_lock, unicast_sock);
ip_rt_put(rt);
}
On Sat, 2014-01-25 at 14:45 +0100, Sebastian Andrzej Siewior wrote:
> Dear RT folks!
>
> I'm pleased to announce the v3.12.8-rt11 patch set.
>
> Changes since v3.12.8-rt10
> - The "do not to raise the timer softirq unconditionally" resulted a few
> boot lockups on a few boxes. Steven found the problem and sent a fix.
> Thank you Steven.
That fix _appears_ to have fixed up the runtime lockups I was hitting on
64 core box as well. I don't have nohz_full enabled atm, but the nmi
watchdog was reliably barking either way, and while box could remain up
for quite a while, it should have died by now. I'll let it grind away
for the rest of the weekend.
-Mike
25.01.2014 17:45, Sebastian Andrzej Siewior пишет:
> I'm pleased to announce the v3.12.8-rt11 patch set.
Nothing has changed, it does not boot from September, and will not boot.
3.2-54-rt77 - works perfectly. Same hardware, same config.
--
Pavel.
25.01.2014 17:45, Sebastian Andrzej Siewior пишет:
> Dear RT folks!
Gentlemen, let's have a month of stress testing!
Divide tasks testing subsystem: USB, NET, MM, ACPI, AUDIO, VIDEO
By CPUs: ARM/PPC/X86/X86_64...
Purely on observations noted that in September 2013, the quality and stability
of the code has deteriorated dramatically.
--
Pavel.
On 01/25/2014 02:45 PM, Sebastian Andrzej Siewior wrote:
> Dear RT folks!
>
> I'm pleased to announce the v3.12.8-rt11 patch set.
> [..]
Thanks a lot, Sebastian, excellent work!
I have upgraded about 40 different QA Farm systems (x86: 32-bit, 64-bit,
single-core, multi-core 2 to 32, single-socket, dual-socket; ARM:
single-core, multi-core), and they all boot and run without any problem.
I didn't see any crash of unknown origin so far. Most systems use the
original kernel besides some unimportant farm patches. Several systems
have a worst-case latency below 20 microseconds (e.g.
https://www.osadl.org/?id=1420 and https://www.osadl.org/?id=1805). Even
Raspberry Pi and BeagleBone-Black work like a charm and have reasonably
low real-time latency (https://www.osadl.org/?id=1663 and
https://www.osadl.org/?id=1601), although they still are not 100%
mainline. It is well conceivable that this or one of the next 3.12.X-rtY
versions will remind us of the legendary 2.6.33 RT kernel.
Seems that an important milestone is being reached.
Thanks,
-Carsten.
On 01/26/2014 10:25 PM, Pavel Vasilyev wrote:
> 25.01.2014 17:45, Sebastian Andrzej Siewior пишет:
>> Dear RT folks!
>
>
> Gentlemen, let's have a month of stress testing! Divide tasks
> testing subsystem: USB, NET, MM, ACPI, AUDIO, VIDEO By CPUs:
> ARM/PPC/X86/X86_64...
>
> Purely on observations noted that in September 2013, the quality
> and stability of the code has deteriorated dramatically.
By September 2k13, do you mean a specific v3.10-RT release?
Sebastian
On Mon, 2014-01-27 at 05:54 +0100, Carsten Emde wrote:
> It is well conceivable that this or one of the next 3.12.X-rtY
> versions will remind us of the legendary 2.6.33 RT kernel.
Hm. I wonder if HRTIMER_SOFTIRQ being processed alone, and at maxed out
priority wouldn't beat 2.6.33-rt on your boxen. My 64 core box running
-rt9 (minus nohz_full patches) does beat it.
Two hacks attached if you're curious too, one to optionally resurrect
sirq threads, another to kick obnoxious idle_balance().. below the belt.
-Mike
27.01.2014 12:44, Sebastian Andrzej Siewior пишет:
> On 01/26/2014 10:25 PM, Pavel Vasilyev wrote:
>> 25.01.2014 17:45, Sebastian Andrzej Siewior пишет:
>>> Dear RT folks!
>>
>>
>> Gentlemen, let's have a month of stress testing! Divide tasks
>> testing subsystem: USB, NET, MM, ACPI, AUDIO, VIDEO By CPUs:
>> ARM/PPC/X86/X86_64...
>>
>> Purely on observations noted that in September 2013, the quality
>> and stability of the code has deteriorated dramatically.
>
> By September 2k13, do you mean a specific v3.10-RT release?
>
Any after 3.2.x-rt
Maybe I'm doing something wrong, but:
1) All kernels (3.2, 3.8, 3.12, 3.13,...) are working normally without patches;
2) 3.2 works fine in CONFIG_PREEMPT_RT_BASE or CONFIG_PREEMPT_RT_FULL modes;
3) 3.10 not works at all, even without -RT patches;
4) 3.12 work only as CONFIG_PREEMPT_RT_BASE or CONFIG_PREEMPT_RT_FULL in
uniprocessor mode (maxcpus=0, nosmp). Newer patches (Oct.-Dec.) did not work,
even in RT_BASE mode.
Varia hardware: One Opteron 285, 2-cpus (4 cores). Six Intel Atoms devices
kernels compiled as x86_32.
I have my patches, but I tested both with them and without them.
---
Behold! 3.12.8-rt11, RT_FULL mode, kernel cmdline: init=/bin/bash
1.
bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell
2.
in single mode: After 2 minutes timeout: see screenshot
http://i59.fastpic.ru/big/2014/0127/bc/0f9e04536181286f820ecaae5a8481bc.jpg
3.
command killall -15 freezed system!
Kernel compiled with debug information starts to work normally, but of course
slower. :D
--
Pavel.
On Mon, 27 Jan 2014 13:42:29 +0400
Pavel Vasilyev <[email protected]> wrote:
> 27.01.2014 12:44, Sebastian Andrzej Siewior пишет:
> > On 01/26/2014 10:25 PM, Pavel Vasilyev wrote:
> >> 25.01.2014 17:45, Sebastian Andrzej Siewior пишет:
> >>> Dear RT folks!
> >>
> >>
> >> Gentlemen, let's have a month of stress testing! Divide tasks
> >> testing subsystem: USB, NET, MM, ACPI, AUDIO, VIDEO By CPUs:
> >> ARM/PPC/X86/X86_64...
> >>
> >> Purely on observations noted that in September 2013, the quality
> >> and stability of the code has deteriorated dramatically.
> >
> > By September 2k13, do you mean a specific v3.10-RT release?
> >
>
> Any after 3.2.x-rt
>
> Maybe I'm doing something wrong, but:
>
> 1) All kernels (3.2, 3.8, 3.12, 3.13,...) are working normally without patches;
>
> 2) 3.2 works fine in CONFIG_PREEMPT_RT_BASE or CONFIG_PREEMPT_RT_FULL modes;
>
> 3) 3.10 not works at all, even without -RT patches;
Please report the problems here to LKML ([email protected])
to the appropriate maintainers. As well as the [email protected]
mailing list.
>
> 4) 3.12 work only as CONFIG_PREEMPT_RT_BASE or CONFIG_PREEMPT_RT_FULL in
> uniprocessor mode (maxcpus=0, nosmp). Newer patches (Oct.-Dec.) did not work,
> even in RT_BASE mode.
Does 3.12 work without the -rt patches?
>
> Varia hardware: One Opteron 285, 2-cpus (4 cores). Six Intel Atoms devices
> kernels compiled as x86_32.
I have an intel atom dev board hanging around somewhere. I'll see if I
can test this. Can you send me your config privately.
Thanks,
-- Steve
>
> I have my patches, but I tested both with them and without them.
> ---
>
> Behold! 3.12.8-rt11, RT_FULL mode, kernel cmdline: init=/bin/bash
>
> 1.
> bash: cannot set terminal process group (-1): Inappropriate ioctl for device
> bash: no job control in this shell
>
> 2.
> in single mode: After 2 minutes timeout: see screenshot
> http://i59.fastpic.ru/big/2014/0127/bc/0f9e04536181286f820ecaae5a8481bc.jpg
>
> 3.
> command killall -15 freezed system!
>
>
> Kernel compiled with debug information starts to work normally, but of course
> slower. :D
>
On 01/27/2014 07:24 PM, Steven Rostedt wrote:
> On Mon, 27 Jan 2014 13:42:29 +0400
> Pavel Vasilyev <[email protected]> wrote:
>
>> 27.01.2014 12:44, Sebastian Andrzej Siewior пишет:
>>> On 01/26/2014 10:25 PM, Pavel Vasilyev wrote:
>>>> 25.01.2014 17:45, Sebastian Andrzej Siewior пишет:
>>>>> Dear RT folks!
>>>>
>>>>
>>>> Gentlemen, let's have a month of stress testing! Divide tasks
>>>> testing subsystem: USB, NET, MM, ACPI, AUDIO, VIDEO By CPUs:
>>>> ARM/PPC/X86/X86_64...
>>>>
>>>> Purely on observations noted that in September 2013, the quality
>>>> and stability of the code has deteriorated dramatically.
>>>
>>> By September 2k13, do you mean a specific v3.10-RT release?
>>>
>>
>> Any after 3.2.x-rt
>>
>> Maybe I'm doing something wrong, but:
>>
>> 1) All kernels (3.2, 3.8, 3.12, 3.13,...) are working normally without patches;
>>
>> 2) 3.2 works fine in CONFIG_PREEMPT_RT_BASE or CONFIG_PREEMPT_RT_FULL modes;
>>
>> 3) 3.10 not works at all, even without -RT patches;
>
> Please report the problems here to LKML ([email protected])
> to the appropriate maintainers. As well as the [email protected]
> mailing list.
>
>>
>> 4) 3.12 work only as CONFIG_PREEMPT_RT_BASE or CONFIG_PREEMPT_RT_FULL in
>> uniprocessor mode (maxcpus=0, nosmp). Newer patches (Oct.-Dec.) did not work,
>> even in RT_BASE mode.
>
> Does 3.12 work without the -rt patches?
>
>>
>> Varia hardware: One Opteron 285, 2-cpus (4 cores). Six Intel Atoms devices
>> kernels compiled as x86_32.
>
> I have an intel atom dev board hanging around somewhere. I'll see if I
> can test this. Can you send me your config privately.
I can offer help as well. And I am most curious to learn what prevents
your systems from booting. Please send me your config as well - I'll run
(or at least try to run) it on a couple of spare farm systems.
-Carsten.
On Sat, 25 Jan 2014 14:45:19 +0100
Sebastian Andrzej Siewior <[email protected]> wrote:
> Dear RT folks!
>
> I'm pleased to announce the v3.12.8-rt11 patch set.
So far the only thing seen in the kernel buffer on this 64b system are a
smattering of "NOHZ: local_softirq_pending 40" and this warning:
[23102.607632] ------------[ cut here ]------------
[23102.607645] WARNING: CPU: 4 PID: 59 at kernel/time/tick-sched.c:161
can_stop_full_tick+0x26b/0x280() [23102.607646] Modules linked in:
snd_seq_midi snd_seq_midi_event snd_seq_dummy msr ipt_REJECT xt_tcpudp
nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack
iptable_filter ip_tables x_tables nct6775 hwmon_vid
x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm
crct10dif_pclmul crct10dif_common crc32_pclmul crc32c_intel
ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper
ablk_helper cryptd usblp joydev eeepc_wmi asus_wmi sparse_keymap
iTCO_wdt iTCO_vendor_support mxm_wmi rfkill psmouse serio_raw snd_hdsp
e1000e snd_rawmidi snd_hda_codec_hdmi ptp thermal fan
snd_hda_codec_realtek pcspkr evdev snd_hda_intel snd_hda_codec wmi
mei_me mei shpchp snd_hwdep lpc_ich i2c_i801 pps_core processor
microcode nfs lockd sunrpc fscache fuse tun snd_aloop snd_pcm
snd_page_alloc snd_seq [23102.607669] snd_seq_device [23102.607670]
snd_timer [23102.607670] snd [23102.607670] soundcore [23102.607671]
ext4 [23102.607671] crc16 [23102.607671] mbcache [23102.607672] jbd2
[23102.607672] hid_generic [23102.607673] usbhid [23102.607673] hid
[23102.607673] sd_mod [23102.607674] ahci [23102.607674] libahci
[23102.607675] firewire_ohci [23102.607675] libata [23102.607675]
ehci_pci [23102.607676] firewire_core [23102.607676] xhci_hcd
[23102.607676] ehci_hcd
[23102.607677] crc_itu_t
[23102.607677] scsi_mod
[23102.607678] usbcore
[23102.607678] usb_common
[23102.607678] i915
[23102.607679] video
[23102.607679] button
[23102.607679] i2c_algo_bit
[23102.607680] intel_agp
[23102.607680] intel_gtt
[23102.607681] drm_kms_helper
[23102.607681] drm
[23102.607681] i2c_core
[23102.607690] CPU: 4 PID: 59 Comm: ksoftirqd/4 Not tainted
3.12.8-rt11-1-rt #1 [23102.607690] Hardware name: System manufacturer
System Product Name/P8Z68-V PRO GEN3, BIOS 3402 05/07/2012
[23102.607692] 0000000000000009 ffff8803fdbd3ca0 ffffffff814f991c
0000000000000000 [23102.607694] ffff8803fdbd3cd8 ffffffff81062cfd
ffff88040fa0ee80 0000000000000002 [23102.607695] 0000000000000003
0000000000000000 00000000fffffffd ffff8803fdbd3ce8 [23102.607695] Call
Trace: [23102.607699] [<ffffffff814f991c>] dump_stack+0x54/0x9a
[23102.607701] [<ffffffff81062cfd>] warn_slowpath_common+0x7d/0xc0
[23102.607703] [<ffffffff81062dfa>] warn_slowpath_null+0x1a/0x20
[23102.607704] [<ffffffff810ccf8b>] can_stop_full_tick+0x26b/0x280
[23102.607706] [<ffffffff810cdddb>] __tick_nohz_full_check+0x6b/0xb0
[23102.607707] [<ffffffff810cde2e>] nohz_full_kick_work_func+0xe/0x10
[23102.607709] [<ffffffff8112de6f>] __irq_work_run+0x5f/0x80
[23102.607710] [<ffffffff8112de99>] irq_work_run+0x9/0x10
[23102.607712] [<ffffffff81070fa4>] run_timer_softirq+0x24/0x2c0
[23102.607714] [<ffffffff8109c8f5>] ? __vtime_account_system+0x35/0x40
[23102.607715] [<ffffffff81068487>] do_current_softirqs+0x1a7/0x390
[23102.607716] [<ffffffff810688d0>] run_ksoftirqd+0x30/0x50
[23102.607718] [<ffffffff81090623>] smpboot_thread_fn+0x213/0x390
[23102.607719] [<ffffffff814fccaa>] ? schedule+0x2a/0x90
[23102.607720] [<ffffffff81090410>] ? lg_local_unlock+0x30/0x30
[23102.607722] [<ffffffff810873e2>] kthread+0xb2/0xc0 [23102.607723]
[<ffffffff81087330>] ? kthread_worker_fn+0x1a0/0x1a0 [23102.607724]
[<ffffffff81506f7c>] ret_from_fork+0x7c/0xb0 [23102.607725]
[<ffffffff81087330>] ? kthread_worker_fn+0x1a0/0x1a0 [23102.607726]
---[ end trace 0000000000000002 ]---
Kernel config file attached:
--
Joakim
* Joakim Hernberg | 2014-01-29 15:30:43 [+0100]:
>On Sat, 25 Jan 2014 14:45:19 +0100
>Sebastian Andrzej Siewior <[email protected]> wrote:
>
>> Dear RT folks!
>>
>> I'm pleased to announce the v3.12.8-rt11 patch set.
>
>So far the only thing seen in the kernel buffer on this 64b system are a
>smattering of "NOHZ: local_softirq_pending 40" and this warning:
>
>[23102.607632] ------------[ cut here ]------------
>[23102.607645] WARNING: CPU: 4 PID: 59 at kernel/time/tick-sched.c:161
>can_stop_full_tick+0x26b/0x280()
This should be fixed by "irq_work: allow certain work in hard irq
context" I posted to the list today.
>Kernel config file attached:
>
Sebastian
* Pavel Vasilyev | 2014-01-27 13:42:29 [+0400]:
>3) 3.10 not works at all, even without -RT patches;
I bootet 3.10.20-rt17 some time ago on an Intel Atom with EG20T chipset
(with those pch driver like pch_udc for usb gadget, pch_uart for serial
and so on). That on _was_ working. I can share the config with you from
back then if you wish.
Sebastian
