Dear RT folks!
I'm pleased to announce the v4.0.4-rt1 patch set.
Changes since v3.18.13-rt10
- Rebase to v4.0.
- David Hildenbrand's series of decouple of preempt_disable from
pagefault_disable is part of the series.
While doing the v4.0 I stumbled upon a few things. Therefore I plan to
reorder the -RT queue and merge patches where possible. Also I intend to
drop PREEMPT_RTB and PREEMPT_RT_BASE unless there is need for it…
Known issues:
- My AMD box throws a lot of "cpufreq_stat_notifier_trans: No
policy found" warnings after boot. It is gone after manually
setting the policy (to something else than reported).
- bcache is disabled.
- CPU hotplug works in general. Steven's test script however
deadlocks usually on the second invocation.
- xor / raid_pq
I had max latency jumping up to 67563us on one CPU while the next
lower max was 58us. I tracked it down to module's init code of
xor and raid_pq. Both disable preemption while measuring the
performance of the individual implementation.
The RT patch against 4.0.4 can be found here:
https://www.kernel.org/pub/linux/kernel/projects/rt/4.0/patch-4.0.4-rt1.patch.xz
The split quilt queue is available at:
https://www.kernel.org/pub/linux/kernel/projects/rt/4.0/patches-4.0.4-rt1.tar.xz
Sebastian
Hi Sebastian,
> I'm pleased to announce the v4.0.4-rt1 patch set.
First smoke test on an Intel Gulftown 980X: Compiled and booted without
problem, no regression of real-time capabilities so far.
> [..]
> Known issues:
> - My AMD box throws a lot of "cpufreq_stat_notifier_trans: No
> policy found" warnings after boot. It is gone after manually
> setting the policy (to something else than reported).
Same here, probably a minor issue. The messages disappear after setting
cpufreq to performance, but they reappear when setting cpufreq back to
ondemand.
On a side note: We need teach cyclictest 4.0 - right now, it says:
WARN: Running on unknown kernel version...YMMV
Thanks, Sebastian, for the good work!
-Carsten.
20.05.2015 00:39, Sebastian Andrzej Siewior пишет:
> Dear RT folks!
>
> I'm pleased to announce the v4.0.4-rt1 patch set.
Patch worked with 4.1.0-rc2, exclude at91rm9200_time.c
--- cut ---
can't find file to patch at input line 700
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/arch/arm/mach-at91/at91rm9200_time.c
b/arch/arm/mach-at91/at91rm9200_time.c
|index b00d09555f2b..cc873c12181d 100644
|--- a/arch/arm/mach-at91/at91rm9200_time.c
|+++ b/arch/arm/mach-at91/at91rm9200_time.c
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.
1 out of 1 hunk ignored
--- cut ---
--
Pavel.
20.05.2015 01:33, Carsten Emde пишет:
> Hi Sebastian,
>
>> I'm pleased to announce the v4.0.4-rt1 patch set.
> First smoke test on an Intel Gulftown 980X: Compiled and booted without
> problem, no regression of real-time capabilities so far.
>
Maybe soon rebase to 4.1.0. By the time we will release our patches will also be
tested?
--
Pavel.
On Tue, 2015-05-19 at 23:39 +0200, Sebastian Andrzej Siewior wrote:
> Dear RT folks!
>
> I'm pleased to announce the v4.0.4-rt1 patch set.
Goody. As soon as I have time to assemble the real deal 4.0-rt, I'll
submit some little fixlets.
-Mike
On 05/20/2015 12:33 AM, Carsten Emde wrote:
> Hi Sebastian,
Hi Carsten,
>> Known issues:
>> - My AMD box throws a lot of "cpufreq_stat_notifier_trans: No
>> policy found" warnings after boot. It is gone after manually
>> setting the policy (to something else than reported).
> Same here, probably a minor issue. The messages disappear after setting
> cpufreq to performance, but they reappear when setting cpufreq back to
> ondemand.
Okay. Didn't try to set it back but yes, the messages gets back here,
too.
> On a side note: We need teach cyclictest 4.0 - right now, it says:
> WARN: Running on unknown kernel version...YMMV
Ah. Just posted a patch. I had in my rt-tests repo and forgot about it…
> Thanks, Sebastian, for the good work!
Thank you.
>
> -Carsten.
Sebastian
20.05.2015 00:39, Sebastian Andrzej Siewior пишет:
> Dear RT folks!
>
> I'm pleased to announce the v4.0.4-rt1 patch set.
While work stable. \m/
TYAN S8225
2 x AMD Opteron(tm) Processor 4386
16Gb DDR3 ECC Reg.
Nvidia GeForce GT740 (blob driver)
CONFIG_NO_HZ_COMMON=y
CONFIG_NO_HZ_FULL=y
CONFIG_NO_HZ_FULL_ALL=y
...
# cyclictest -S -c 1 -m -p 99 --latency=0 --policy=fifo
# /dev/cpu_dma_latency set to 0us
WARN: Running on unknown kernel version...YMMV
policy: fifo: loadavg: 1.57 1.70 1.55 1/557 19347
T: 0 (18369) P:99 I:1000 C: 26617 Min: 6 Act: 13 Avg: 12 Max: 1614
T: 1 (18370) P:99 I:1500 C: 17742 Min: 6 Act: 18 Avg: 19 Max: 1700
T: 2 (18371) P:99 I:2000 C: 13304 Min: 8 Act: 19 Avg: 20 Max: 1620
T: 3 (18372) P:99 I:2500 C: 10642 Min: 6 Act: 16 Avg: 17 Max: 73
T: 4 (18373) P:99 I:3000 C: 8867 Min: 8 Act: 20 Avg: 20 Max: 1497
T: 5 (18374) P:99 I:3500 C: 7599 Min: 8 Act: 20 Avg: 20 Max: 90
T: 6 (18375) P:99 I:4000 C: 6648 Min: 6 Act: 18 Avg: 19 Max: 94
T: 7 (18376) P:99 I:4500 C: 5908 Min: 9 Act: 18 Avg: 19 Max: 1172
T: 8 (18377) P:99 I:5000 C: 5317 Min: 6 Act: 17 Avg: 20 Max: 66
T: 9 (18378) P:99 I:5500 C: 4832 Min: 7 Act: 24 Avg: 19 Max: 100
T:10 (18379) P:99 I:6000 C: 4429 Min: 7 Act: 14 Avg: 19 Max: 1216
T:11 (18380) P:99 I:6500 C: 4088 Min: 8 Act: 14 Avg: 20 Max: 827
T:12 (18381) P:99 I:7000 C: 3795 Min: 7 Act: 17 Avg: 18 Max: 77
T:13 (18382) P:99 I:7500 C: 3542 Min: 6 Act: 18 Avg: 20 Max: 71
T:14 (18383) P:99 I:8000 C: 3320 Min: 8 Act: 19 Avg: 20 Max: 73
T:15 (18384) P:99 I:8500 C: 3124 Min: 6 Act: 23 Avg: 19 Max: 75
--
Pavel.
On 05/20/2015 12:33 AM, Carsten Emde wrote:
>> I'm pleased to announce the v4.0.4-rt1 patch set.
> First smoke test on an Intel Gulftown 980X: Compiled and booted without
> problem, no regression of real-time capabilities so far.
>
>> [..]
>> Known issues:
>> - My AMD box throws a lot of "cpufreq_stat_notifier_trans: No
>> policy found" warnings after boot. It is gone after manually
>> setting the policy (to something else than reported).
> Same here, probably a minor issue. The messages disappear after setting
> cpufreq to performance, but they reappear when setting cpufreq back to
> ondemand.
>
> On a side note: We need teach cyclictest 4.0 - right now, it says:
> WARN: Running on unknown kernel version...YMMV
>
> Thanks, Sebastian, for the good work!
Yay, great work! Also I'd like to thank the OSADL members for funding
this activity!
cheers,
daniel
20.05.2015 00:39, Sebastian Andrzej Siewior пишет:
> Dear RT folks!
>
> I'm pleased to announce the v4.0.4-rt1 patch set.
Guys, 4.0.4-rt1 freezing after
# sysctl -w vm.drop_caches=3 && memhog `free -k | grep Mem | awk '{print
$4"k"}'` 2>&1 >/dev/null;
- CONFIG_PREEMPT_RT_BASE or CONFIG_PREEMPT_RT_FULL
- Debian 8
- Nvidia blob 346.47 (GeForce GT 740)
- Google Chrome 43.0.2357.65 (64-bit)
--
Pavel.
On 05/19/2015 02:39 PM, Sebastian Andrzej Siewior wrote:
> Dear RT folks!
>
> I'm pleased to announce the v4.0.4-rt1 patch set.
Great!!
> Changes since v3.18.13-rt10
>
> - Rebase to v4.0.
>
> - David Hildenbrand's series of decouple of preempt_disable from
> pagefault_disable is part of the series.
>
> While doing the v4.0 I stumbled upon a few things. Therefore I plan to
> reorder the -RT queue and merge patches where possible. Also I intend to
> drop PREEMPT_RTB and PREEMPT_RT_BASE unless there is need for it…
...
I had to do this to get it to build (looks like it is not rt specific,
probably just a typo in mainline):
--------
--- linux-4.0/sound/soc/intel/sst/sst.c~ 2015-04-12 15:12:50.000000000 -0700
+++ linux-4.0/sound/soc/intel/sst/sst.c 2015-05-23 21:51:46.000000000 -0700
@@ -368,8 +368,8 @@
* initialize by FW or driver when firmware is loaded
*/
spin_lock_irqsave(&ctx->ipc_spin_lock, irq_flags);
- sst_shim_write64(shim, SST_IMRX, shim_regs->imrx),
- sst_shim_write64(shim, SST_CSR, shim_regs->csr),
+ sst_shim_write64(shim, SST_IMRX, shim_regs->imrx);
+ sst_shim_write64(shim, SST_CSR, shim_regs->csr);
spin_unlock_irqrestore(&ctx->ipc_spin_lock, irq_flags);
}
--------
On a desktop with an i7-3770k it seems to run fine (but I have not have
time to test for latency problems).
On my laptop, a lenovo w540, I get this continuously - so it is not
really usable at this point:
--------
May 24 13:51:41 localhost kernel: ------------[ cut here ]------------
May 24 13:51:41 localhost kernel: WARNING: CPU: 5 PID: 361 at
drivers/gpu/drm/i915/intel_display.c:9748
intel_check_page_flip+0xaa/0xf0 [i915]()
May 24 13:51:41 localhost kernel: WARN_ON(!in_interrupt())
May 24 13:51:41 localhost kernel: Modules linked in:
May 24 13:51:41 localhost kernel: rfcomm fuse ccm xt_CHECKSUM
ipt_MASQUERADE nf_nat_masquerade_ipv4 nf_conntrack_netbios_ns
nf_conntrack_broadcast ip6t_rpfilter ip6t_REJ\
ECT nf_reject_ipv6 xt_conntrack ebtable_nat ebtable_broute bridge stp
llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6
nf_defrag_ipv6 nf_nat_ipv6 ip6table_mang\
le ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat
nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack
iptable_mangle iptable_security\
iptable_raw bnep bbswitch(OE) vfat fat iTCO_wdt iTCO_vendor_support
arc4 intel_rapl iosf_mbi coretemp kvm_intel kvm uvcvideo
crct10dif_pclmul videobuf2_vmalloc videobuf\
2_core crc32_pclmul crc32c_intel videobuf2_memops ghash_clmulni_intel
v4l2_common videodev media iwlmvm btusb serio_raw mac80211 bluetooth
snd_hda_codec_realtek
May 24 13:51:41 localhost kernel: snd_hda_codec_hdmi
snd_hda_codec_generic iwlwifi snd_hda_intel sdhci_pci snd_hda_controller
cfg80211 sdhci snd_hda_codec mmc_core snd_h\
wdep lpc_ich snd_seq mei_me i2c_i801 mfd_core snd_seq_device mei snd_pcm
thinkpad_acpi snd_timer ie31200_edac snd shpchp edac_core soundcore
tpm_tis rfkill tpm nfsd auth\
_rpcgss nfs_acl lockd grace sunrpc i915 i2c_algo_bit e1000e
drm_kms_helper ptp drm pps_core wmi video
May 24 13:51:41 localhost kernel: CPU: 5 PID: 361 Comm: irq/30-i915
Tainted: G W OE 4.0.4-201.rt1.2.fc21.ccrma.x86_64+rt #1
May 24 13:51:41 localhost kernel: Hardware name: LENOVO
20BGCTO1WW/20BGCTO1WW, BIOS GNET65WW (2.13 ) 06/20/2014
May 24 13:51:41 localhost kernel: 0000000000000000 000000001f35af7b
ffff8804651afc78 ffffffff8179c0b9
May 24 13:51:41 localhost kernel: 0000000000000000 ffff8804651afcd0
ffff8804651afcb8 ffffffff8109ee1a
May 24 13:51:41 localhost kernel: ffff8804651afcb8 ffff88046638c000
ffff880469dd7800 0000000000000001
May 24 13:51:41 localhost kernel: Call Trace:
May 24 13:51:41 localhost kernel: [<ffffffff8179c0b9>] dump_stack+0x4c/0x81
May 24 13:51:41 localhost kernel: [<ffffffff8109ee1a>]
warn_slowpath_common+0x8a/0xe0
May 24 13:51:41 localhost kernel: [<ffffffff8109eec5>]
warn_slowpath_fmt+0x55/0x70
May 24 13:51:41 localhost kernel: [<ffffffffa0186dda>]
intel_check_page_flip+0xaa/0xf0 [i915]
May 24 13:51:41 localhost kernel: [<ffffffffa0152018>]
ironlake_irq_handler+0x2e8/0x1000 [i915]
May 24 13:51:41 localhost kernel: [<ffffffff81014610>] ?
__switch_to+0x150/0x610
May 24 13:51:41 localhost kernel: [<ffffffff810fb040>] ?
irq_thread_fn+0x50/0x50
May 24 13:51:41 localhost kernel: [<ffffffff810fb067>]
irq_forced_thread_fn+0x27/0x80
May 24 13:51:41 localhost kernel: [<ffffffff810fb61f>]
irq_thread+0x12f/0x180
May 24 13:51:41 localhost kernel: [<ffffffff810fb0f0>] ?
wake_threads_waitq+0x30/0x30
May 24 13:51:41 localhost kernel: [<ffffffff810fb4f0>] ?
irq_thread_check_affinity+0x90/0x90
May 24 13:51:41 localhost kernel: [<ffffffff810bf4ba>] kthread+0xca/0xe0
May 24 13:51:41 localhost kernel: [<ffffffff810bf3f0>] ?
kthread_worker_fn+0x180/0x180
May 24 13:51:41 localhost kernel: [<ffffffff817a2098>]
ret_from_fork+0x58/0x90
May 24 13:51:41 localhost kernel: [<ffffffff810bf3f0>] ?
kthread_worker_fn+0x180/0x180
May 24 13:51:41 localhost kernel: ---[ end trace 00000000000005fe ]---
May 24 13:51:41 localhost kernel: ------------[ cut here ]------------
--------
Any patches I could try to fix this?
-- Fernando
On Tue, 19 May 2015 23:39:23 +0200
Sebastian Andrzej Siewior <[email protected]> wrote:
> Dear RT folks!
>
> I'm pleased to announce the v4.0.4-rt1 patch set.
>
Sebastian,
The i915 driver has a 'WARN_ON(!in_interrupt())' in the display
handler, which whines constantly on the RT kernel (since the interrupt
is actually handled in a threaded handler and not actual interrupt
context).
Ifdef it out for PREEMPT_RT_FULL.
Signed-off-by: Clark Williams <[email protected]>
---
drivers/gpu/drm/i915/intel_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index f75173c20f47..f532b22f56ba 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9745,7 +9745,9 @@ void intel_check_page_flip(struct drm_device *dev, int pipe)
struct drm_crtc *crtc = dev_priv->pipe_to_crtc_mapping[pipe];
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+#ifndef CONFIG_PREEMPT_RT_FULL
WARN_ON(!in_interrupt());
+#endif
if (crtc == NULL)
return;
On Tue, 26 May 2015 08:34:49 -0500
Clark Williams <[email protected]> wrote:
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index f75173c20f47..f532b22f56ba 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -9745,7 +9745,9 @@ void intel_check_page_flip(struct drm_device *dev, int pipe)
> struct drm_crtc *crtc = dev_priv->pipe_to_crtc_mapping[pipe];
> struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>
> +#ifndef CONFIG_PREEMPT_RT_FULL
> WARN_ON(!in_interrupt());
> +#endif
Or just use our special WARN_ON() functions...
WARN_ON_NONRT(!in_interrupt());
-- Steve
>
> if (crtc == NULL)
> return;
On Tue, 26 May 2015 09:38:32 -0400
Steven Rostedt <[email protected]> wrote:
> On Tue, 26 May 2015 08:34:49 -0500
> Clark Williams <[email protected]> wrote:
>
> > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> > index f75173c20f47..f532b22f56ba 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -9745,7 +9745,9 @@ void intel_check_page_flip(struct drm_device *dev, int pipe)
> > struct drm_crtc *crtc = dev_priv->pipe_to_crtc_mapping[pipe];
> > struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> >
> > +#ifndef CONFIG_PREEMPT_RT_FULL
> > WARN_ON(!in_interrupt());
> > +#endif
>
> Or just use our special WARN_ON() functions...
>
>
> WARN_ON_NONRT(!in_interrupt());
>
> -- Steve
good point. Updated patch:
From: Clark Williams <[email protected]>
Date: Thu, 21 May 2015 12:51:53 -0500
Subject: [PATCH] [rt] i915: bogus warning from i915 when running on PREEMPT_RT
The i915 driver has a 'WARN_ON(!in_interrupt())' in the display
handler, which whines constanly on the RT kernel (since the interrupt
is actually handled in a threaded handler and not actual interrupt
context).
Change the WARN_ON to WARN_ON_NORT
Signed-off-by: Clark Williams <[email protected]>
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index f75173c20f47..b21e3a334e4e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9745,7 +9745,7 @@ void intel_check_page_flip(struct drm_device *dev, int pipe)
struct drm_crtc *crtc = dev_priv->pipe_to_crtc_mapping[pipe];
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- WARN_ON(!in_interrupt());
+ WARN_ON_NORT(!in_interrupt());
if (crtc == NULL)
return;
--
2.1.0
On Tue, 2015-05-26 at 08:48 -0500, Clark Williams wrote:
> On Tue, 26 May 2015 09:38:32 -0400
> Steven Rostedt <[email protected]> wrote:
>
> > On Tue, 26 May 2015 08:34:49 -0500
> > Clark Williams <[email protected]> wrote:
> >
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> > > index f75173c20f47..f532b22f56ba 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -9745,7 +9745,9 @@ void intel_check_page_flip(struct drm_device *dev, int pipe)
> > > struct drm_crtc *crtc = dev_priv->pipe_to_crtc_mapping[pipe];
> > > struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> > >
> > > +#ifndef CONFIG_PREEMPT_RT_FULL
> > > WARN_ON(!in_interrupt());
> > > +#endif
> >
> > Or just use our special WARN_ON() functions...
> >
> >
> > WARN_ON_NONRT(!in_interrupt());
> >
> > -- Steve
>
> good point. Updated patch:
That's one down.
# pending fixes
drm-i915-intel_check_page_flip-WARN_ON_NONRT-for-not-in_irq.patch
net-netpoll-WARN_ONCE_NONRT-for-irqs-non-disabled.patch
workqueue-fix-rescuer_thread-blocking-ops-while-not-TASK_RUNNING-splat.patch
There are a couple more little splats. Been meaning to post them now
that 4.0-rt is out, but between the (alleged) 9->5 thing and whatnot...
-Mike
On Tue, 26 May 2015 08:48:02 -0500
Clark Williams <[email protected]> wrote:
> Change the WARN_ON to WARN_ON_NORT
Do we have a WARN_ON_NORT? I see a WARN_ON_NONRT, but not a
WARN_ON_NORT. Does this compile?
-- Steve
>
> Signed-off-by: Clark Williams <[email protected]>
> ---
> drivers/gpu/drm/i915/intel_display.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index f75173c20f47..b21e3a334e4e 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -9745,7 +9745,7 @@ void intel_check_page_flip(struct drm_device *dev, int pipe)
> struct drm_crtc *crtc = dev_priv->pipe_to_crtc_mapping[pipe];
> struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>
> - WARN_ON(!in_interrupt());
> + WARN_ON_NORT(!in_interrupt());
>
> if (crtc == NULL)
> return;
On Tue, 26 May 2015 11:19:24 -0400
Steven Rostedt <[email protected]> wrote:
> On Tue, 26 May 2015 08:48:02 -0500
> Clark Williams <[email protected]> wrote:
>
>
> > Change the WARN_ON to WARN_ON_NORT
>
> Do we have a WARN_ON_NORT? I see a WARN_ON_NONRT, but not a
> WARN_ON_NORT. Does this compile?
>
> -- Steve
Sigh. Of course not. Reupdated patch (and yes this one compiles):
From: Clark Williams <[email protected]>
Date: Thu, 21 May 2015 12:51:53 -0500
Subject: [PATCH] [rt] i915: bogus warning from i915 when running on PREEMPT_RT
The i915 driver has a 'WARN_ON(!in_interrupt())' in the display
handler, which whines constanly on the RT kernel (since the interrupt
is actually handled in a threaded handler and not actual interrupt
context).
Change the WARN_ON to WARN_ON_NORT
Signed-off-by: Clark Williams <[email protected]>
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index f75173c20f47..30b1d16caa0d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9745,7 +9745,7 @@ void intel_check_page_flip(struct drm_device *dev, int pipe)
struct drm_crtc *crtc = dev_priv->pipe_to_crtc_mapping[pipe];
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- WARN_ON(!in_interrupt());
+ WARN_ON_NONRT(!in_interrupt());
if (crtc == NULL)
return;
--
2.1.0
On 05/26/2015 08:43 AM, Clark Williams wrote:
> On Tue, 26 May 2015 11:19:24 -0400
> Steven Rostedt <[email protected]> wrote:
>
>> On Tue, 26 May 2015 08:48:02 -0500
>> Clark Williams <[email protected]> wrote:
>>
>>
>>> Change the WARN_ON to WARN_ON_NORT
>>
>> Do we have a WARN_ON_NORT? I see a WARN_ON_NONRT, but not a
>> WARN_ON_NORT. Does this compile?
>>
>> -- Steve
>
> Sigh. Of course not. Reupdated patch (and yes this one compiles):
Thanks! Seems to have fixed the problem (of course!)
So far so good and nothing weird in the output of dmesg....
-- Fernando
> From: Clark Williams <[email protected]>
> Date: Thu, 21 May 2015 12:51:53 -0500
> Subject: [PATCH] [rt] i915: bogus warning from i915 when running on PREEMPT_RT
>
> The i915 driver has a 'WARN_ON(!in_interrupt())' in the display
> handler, which whines constanly on the RT kernel (since the interrupt
> is actually handled in a threaded handler and not actual interrupt
> context).
>
> Change the WARN_ON to WARN_ON_NORT
>
> Signed-off-by: Clark Williams <[email protected]>
> ---
> drivers/gpu/drm/i915/intel_display.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index f75173c20f47..30b1d16caa0d 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -9745,7 +9745,7 @@ void intel_check_page_flip(struct drm_device *dev, int pipe)
> struct drm_crtc *crtc = dev_priv->pipe_to_crtc_mapping[pipe];
> struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>
> - WARN_ON(!in_interrupt());
> + WARN_ON_NONRT(!in_interrupt());
>
> if (crtc == NULL)
> return;
>
On 05/28/2015 06:56 PM, Fernando Lopez-Lezcano wrote:
> Oh well. Second time the machine hangs in two days in the same way
> (otherwise very stable running 3.18.x-rty)
>
> (this is a bumblebee + bbswitch graphics laptop - argh, if I had known
> better...)
>
> ----
> May 28 18:49:21 localhost kernel: ------------[ cut here ]------------
> May 28 18:49:21 localhost kernel: kernel BUG at mm/memcontrol.c:5848!
> May 28 18:49:21 localhost kernel: invalid opcode: 0000 [#1] PREEMPT SMP
...
> ----
This is still happening, about once a day. John Dulaney help me set up a
crash kernel dump (thanks!) so now I have a kernel core dump for this
one, I'll try to post more details tomorrow. Let me know if there is
anything in particular I should look at.
I'm attaching another backtrace on a different machine (older desktop),
slightly different but same end result.
-- Fernando
09.06.2015 19:45, Fernando Lopez-Lezcano пишет:
> This is still happening, about once a day. John Dulaney help me set up a
> crash kernel dump (thanks!) so now I have a kernel core dump for this
> one,
Asus,Fedora,CGROUPS, iptables,snd_ac97,radeon,raid1,kvm - this realtime system? :D
--
Pavel.
09.06.2015 19:45, Fernando Lopez-Lezcano пишет:
> This is still happening, about once a day. John Dulaney help me set up a
> crash kernel dump (thanks!) so now I have a kernel core dump for this
> one,
Asus,Fedora,CGROUPS, iptables,snd_ac97,radeon,raid1,kvm - this realtime system? :D
--
Pavel.
On Wed, 2015-06-10 at 01:05 +0300, Pavel Vasilyev wrote:
> 09.06.2015 19:45, Fernando Lopez-Lezcano пишет:
>
> > This is still happening, about once a day. John Dulaney help me set up a
> > crash kernel dump (thanks!) so now I have a kernel core dump for this
> > one,
>
> Asus,Fedora,CGROUPS, iptables,snd_ac97,radeon,raid1,kvm - this realtime system? :D
So? Distro kernels have all that and more, yet manage to power video
games that would say "Game over, insert bucket of gold doubloons" if
they had coin slots^Wchutes. There's more to the rt world than skinny
little boxen, rt sumo exists.
-Mike
On 06/09/2015 03:05 PM, Pavel Vasilyev wrote:
> 09.06.2015 19:45, Fernando Lopez-Lezcano пишет:
>
>> This is still happening, about once a day. John Dulaney help me set up a
>> crash kernel dump (thanks!) so now I have a kernel core dump for this
>> one,
>
> Asus,Fedora,CGROUPS, iptables,snd_ac97,radeon,raid1,kvm - this realtime
> system? :D
:-P
Yup. I have been using rt for many years - and packaging it - for (very)
low latency sound processing. Linux + rt + jackd + rtirq + threaded irqs
+ jack clients, everything with the right priorities. Runs very nicely
unless you hit an issue like the one I'm asking about[*]. Usually
running snd_hdspm with RME hardware when in concert situations (this one
with Asus mobo is my - quite old by now - desktop at work, but I'm also
having the same problem in my Lenovo laptop).
-- Fernando
[*] for example a whole concert for a 24.8 3D sound system with a remote
ethernet driven D/A and running all the time with 64 frame x 2 buffers
at 48KHz.
* Pavel Vasilyev | 2015-05-23 14:57:48 [+0300]:
>20.05.2015 00:39, Sebastian Andrzej Siewior пишет:
>>Dear RT folks!
>>
>>I'm pleased to announce the v4.0.4-rt1 patch set.
>
>Guys, 4.0.4-rt1 freezing after
>
># sysctl -w vm.drop_caches=3 && memhog `free -k | grep Mem | awk
>'{print $4"k"}'` 2>&1 >/dev/null;
it might be related to the part where it runs into the BUG_ON() in the
swap code. Try my patch from "[RFC][PATCH] mm: ifdef out VM_BUG_ON check
on PREEMPT_RT_FULL" thread, disable swap or wait for new -RT to verify.
Sebastian
* Pavel Vasilyev | 2015-05-20 13:06:22 [+0300]:
>Nvidia GeForce GT740 (blob driver)
If you worry but the >1ms spikes I suggest to remove that blob first.
># cyclictest -S -c 1 -m -p 99 --latency=0 --policy=fifo
>
># /dev/cpu_dma_latency set to 0us
>WARN: Running on unknown kernel version...YMMV
>policy: fifo: loadavg: 1.57 1.70 1.55 1/557 19347
>
>T: 0 (18369) P:99 I:1000 C: 26617 Min: 6 Act: 13 Avg: 12 Max: 1614
Sebastian
This was spotted by Fernando Lopez-Lezcano <[email protected]>
while he tried to compile a -RT kernel with this driver enabled.
"make C=2" would also warn about this. This is is based on his patch.
Reported-by: Fernando Lopez-Lezcano <[email protected]>
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
---
sound/soc/intel/atom/sst/sst.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/intel/atom/sst/sst.c b/sound/soc/intel/atom/sst/sst.c
index 96c2e420cce6..b0c3e0e56302 100644
--- a/sound/soc/intel/atom/sst/sst.c
+++ b/sound/soc/intel/atom/sst/sst.c
@@ -368,8 +368,8 @@ static inline void sst_restore_shim64(struct intel_sst_drv *ctx,
* initialize by FW or driver when firmware is loaded
*/
spin_lock_irqsave(&ctx->ipc_spin_lock, irq_flags);
- sst_shim_write64(shim, SST_IMRX, shim_regs->imrx),
- sst_shim_write64(shim, SST_CSR, shim_regs->csr),
+ sst_shim_write64(shim, SST_IMRX, shim_regs->imrx):
+ sst_shim_write64(shim, SST_CSR, shim_regs->csr);
spin_unlock_irqrestore(&ctx->ipc_spin_lock, irq_flags);
}
--
2.1.4
* Clark Williams | 2015-05-26 10:43:43 [-0500]:
>From: Clark Williams <[email protected]>
>Date: Thu, 21 May 2015 12:51:53 -0500
>Subject: [PATCH] [rt] i915: bogus warning from i915 when running on PREEMPT_RT
>
>The i915 driver has a 'WARN_ON(!in_interrupt())' in the display
>handler, which whines constanly on the RT kernel (since the interrupt
>is actually handled in a threaded handler and not actual interrupt
>context).
>
>Change the WARN_ON to WARN_ON_NORT
>
>Signed-off-by: Clark Williams <[email protected]>
Applied, thanks.
Sebastian
* Fernando Lopez-Lezcano | 2015-05-28 18:56:17 [-0700]:
>On 05/26/2015 12:41 PM, Fernando Lopez-Lezcano wrote:
>Oh well. Second time the machine hangs in two days in the same way
>(otherwise very stable running 3.18.x-rty)
http://marc.info/?l=linux-rt-users&m=143402285006570&w=2
In future
>May 28 18:49:21 localhost kernel: Call Trace:
>May 28 18:49:21 localhost kernel: [<ffffffff811b8d8f>]
>__remove_mapping+0x12f/0x1a0
>May 28 18:49:21 localhost kernel: [<ffffffff811bba3f>]
>shrink_page_list+0x5ef/0xc30
>May 28 18:49:21 localhost kernel: [<ffffffff811bc709>]
>shrink_inactive_list+0x1e9/0x630
Please make sure you client does not end the line for you. It is hard to
read. And I may not want to…
Sebastian
On 2015-06-11 14:22, Sebastian Andrzej Siewior wrote:
> This was spotted by Fernando Lopez-Lezcano <[email protected]>
> while he tried to compile a -RT kernel with this driver enabled.
> "make C=2" would also warn about this. This is is based on his patch.
>
> Reported-by: Fernando Lopez-Lezcano <[email protected]>
> Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
> ---
> sound/soc/intel/atom/sst/sst.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/sound/soc/intel/atom/sst/sst.c b/sound/soc/intel/atom/sst/sst.c
> index 96c2e420cce6..b0c3e0e56302 100644
> --- a/sound/soc/intel/atom/sst/sst.c
> +++ b/sound/soc/intel/atom/sst/sst.c
> @@ -368,8 +368,8 @@ static inline void sst_restore_shim64(struct intel_sst_drv *ctx,
> * initialize by FW or driver when firmware is loaded
> */
> spin_lock_irqsave(&ctx->ipc_spin_lock, irq_flags);
> - sst_shim_write64(shim, SST_IMRX, shim_regs->imrx),
> - sst_shim_write64(shim, SST_CSR, shim_regs->csr),
> + sst_shim_write64(shim, SST_IMRX, shim_regs->imrx):
Don't you mean ';' and not ':'?
> + sst_shim_write64(shim, SST_CSR, shim_regs->csr);
> spin_unlock_irqrestore(&ctx->ipc_spin_lock, irq_flags);
> }
>
This was spotted by Fernando Lopez-Lezcano <[email protected]>
while he tried to compile a -RT kernel with this driver enabled.
"make C=2" would also warn about this. This is is based on his patch.
Reported-by: Fernando Lopez-Lezcano <[email protected]>
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
---
* Mats Karrman | 2015-06-11 15:04:25 [+0200]:
>>+ sst_shim_write64(shim, SST_IMRX, shim_regs->imrx):
>Don't you mean ';' and not ':'?
Interresting, yes I do. Thanks.
sound/soc/intel/atom/sst/sst.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/intel/atom/sst/sst.c b/sound/soc/intel/atom/sst/sst.c
index 96c2e420cce6..a4b458e77089 100644
--- a/sound/soc/intel/atom/sst/sst.c
+++ b/sound/soc/intel/atom/sst/sst.c
@@ -368,8 +368,8 @@ static inline void sst_restore_shim64(struct intel_sst_drv *ctx,
* initialize by FW or driver when firmware is loaded
*/
spin_lock_irqsave(&ctx->ipc_spin_lock, irq_flags);
- sst_shim_write64(shim, SST_IMRX, shim_regs->imrx),
- sst_shim_write64(shim, SST_CSR, shim_regs->csr),
+ sst_shim_write64(shim, SST_IMRX, shim_regs->imrx);
+ sst_shim_write64(shim, SST_CSR, shim_regs->csr);
spin_unlock_irqrestore(&ctx->ipc_spin_lock, irq_flags);
}
--
2.1.4
On Thu, Jun 11, 2015 at 03:14:34PM +0200, Sebastian Andrzej Siewior wrote:
> This was spotted by Fernando Lopez-Lezcano <[email protected]>
> while he tried to compile a -RT kernel with this driver enabled.
> "make C=2" would also warn about this. This is is based on his patch.
>
> Reported-by: Fernando Lopez-Lezcano <[email protected]>
> Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
Acked-by: Vinod Koul <[email protected]>
--
~Vinod
> ---
> * Mats Karrman | 2015-06-11 15:04:25 [+0200]:
>
> >>+ sst_shim_write64(shim, SST_IMRX, shim_regs->imrx):
> >Don't you mean ';' and not ':'?
> Interresting, yes I do. Thanks.
>
> sound/soc/intel/atom/sst/sst.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/sound/soc/intel/atom/sst/sst.c b/sound/soc/intel/atom/sst/sst.c
> index 96c2e420cce6..a4b458e77089 100644
> --- a/sound/soc/intel/atom/sst/sst.c
> +++ b/sound/soc/intel/atom/sst/sst.c
> @@ -368,8 +368,8 @@ static inline void sst_restore_shim64(struct intel_sst_drv *ctx,
> * initialize by FW or driver when firmware is loaded
> */
> spin_lock_irqsave(&ctx->ipc_spin_lock, irq_flags);
> - sst_shim_write64(shim, SST_IMRX, shim_regs->imrx),
> - sst_shim_write64(shim, SST_CSR, shim_regs->csr),
> + sst_shim_write64(shim, SST_IMRX, shim_regs->imrx);
> + sst_shim_write64(shim, SST_CSR, shim_regs->csr);
> spin_unlock_irqrestore(&ctx->ipc_spin_lock, irq_flags);
> }
>
> --
> 2.1.4
--
On Thu, Jun 11, 2015 at 03:14:34PM +0200, Sebastian Andrzej Siewior wrote:
> This was spotted by Fernando Lopez-Lezcano <[email protected]>
> while he tried to compile a -RT kernel with this driver enabled.
> "make C=2" would also warn about this. This is is based on his patch.
Applied, thanks.