4.0.4-rt1

ANNOUNCE Superseded Sebastian Andrzej Siewior 14 participants 37 messages May 19, 2015 – Jun 12, 2015

Subsystems (5)

DRM drivers Sound Intel i915 ASoC +1 more subsystems

lore

Share & tools

lore

Sebastian Andrzej Siewior

author

2015-05-19 21:39 UTC #0 lore raw

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

Carsten Emde

2015-05-19 22:35 UTC #1 lore raw

Hi Sebastian,

Quoted 1 line

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.

Quoted 5 lines

[..]
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.

Pavel Vasilyev

2015-05-19 22:51 UTC #2 lore raw

20.05.2015 01:33, Carsten Emde пишет:

Quoted 6 lines

Hi Sebastian,
Quoted 1 line
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?

Signature · 1 line

                                                         Pavel.

Sebastian Andrzej Siewior

author

2015-05-20 07:12 UTC #3 lore raw

In reply to Carsten Emde

Quoted 1 line · Carsten Emde

Hi Sebastian,

Hi Carsten,

Quoted 7 lines

Quoted 4 lines
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.

Quoted 2 lines

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…

Quoted 1 line

Thanks, Sebastian, for the good work!

Thank you.

Quoted 2 lines

-Carsten.

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Daniel Wagner

2015-05-20 13:18 UTC #4 lore raw

In reply to Carsten Emde

Quoted 9 lines · Carsten Emde

Quoted 1 line
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.
Quoted 5 lines
[..]
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).

Quoted 8 lines

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

Pavel Vasilyev

2015-05-19 22:48 UTC #5 lore raw

In reply to Sebastian Andrzej Siewior

20.05.2015 00:39, Sebastian Andrzej Siewior пишет:

Quoted 3 lines

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 ---

Signature · 1 line

                                                         Pavel.

Mike Galbraith

2015-05-20 03:14 UTC #6 lore raw

In reply to Sebastian Andrzej Siewior

Quoted 3 lines · Sebastian Andrzej Siewior

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

Pavel Vasilyev

2015-05-20 10:06 UTC #7 lore raw

In reply to Sebastian Andrzej Siewior

20.05.2015 00:39, Sebastian Andrzej Siewior пишет:

Quoted 3 lines

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

Signature · 1 line

                                                         Pavel.

Sebastian Andrzej Siewior

author

2015-06-11 12:09 UTC #8 lore raw

Quoted 1 line · * 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.

Quoted 7 lines

# 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

Pavel Vasilyev

2015-05-23 11:57 UTC #9 lore raw

In reply to Sebastian Andrzej Siewior

20.05.2015 00:39, Sebastian Andrzej Siewior пишет:

Quoted 3 lines

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)

Signature · 1 line

                                                         Pavel.

Sebastian Andrzej Siewior

author

2015-06-11 12:08 UTC #10 lore raw

Quoted 9 lines · * Pavel Vasilyev | 2015-05-23 14:57:48 [+0300]:

20.05.2015 00:39, Sebastian Andrzej Siewior пишет:
Quoted 3 lines
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

Fernando Lopez-Lezcano

2015-05-24 20:59 UTC #11 lore raw

In reply to Sebastian Andrzej Siewior

Quoted 3 lines · Sebastian Andrzej Siewior

Dear RT folks!
I'm pleased to announce the v4.0.4-rt1 patch set.

Great!!

Quoted 10 lines

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):

--------

sound/soc/intel/sst/sst.c renamed from sound/soc/intel/sst/sst.c~ +2 -2

@@ -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

Sebastian Andrzej Siewior

author

2015-06-11 12:22 UTC #12 lore raw

PATCH 1/1 ASoC: Intel: sst: use ; instead of , at the of a C statement

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(-)

sound/soc/intel/atom/sst/sst.c +2 -2

index 96c2e420cce6..b0c3e0e56302 100644
@@ -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);
 }

Signature · 1 line

2.1.4

Mats Karrman

2015-06-11 13:04 UTC #13 lore raw

Re: [PATCH] ASoC: Intel: sst: use ; instead of , at the of a C statement

Quoted 15 lines · Sebastian Andrzej Siewior

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(-)
sound/soc/intel/atom/sst/sst.c +0 -0
index 96c2e420cce6..b0c3e0e56302 100644

sound/soc/intel/atom/sst/sst.c static inline void sst_restore_shim64(struct intel_sst_drv *ctx, · line 371

Quoted 6 lines

sound/soc/intel/atom/sst/sst.c +1 -2

@@ -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 ':'?

Quoted 4 lines

sound/soc/intel/atom/sst/sst.c +1 -0

+	sst_shim_write64(shim, SST_CSR, shim_regs->csr);
  	spin_unlock_irqrestore(&ctx->ipc_spin_lock, irq_flags);
  }

Sebastian Andrzej Siewior

author

2015-06-11 13:14 UTC #14 lore raw

PATCH v2 1/1 ASoC: Intel: sst: use ; instead of , at the of a C statement

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]>

---

Quoted 2 lines · * Mats Karrman | 2015-06-11 15:04:25 [+0200]:

Review
Quoted 1 line
(quoted diff) +1 -0
+	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(-)

sound/soc/intel/atom/sst/sst.c +2 -2

index 96c2e420cce6..a4b458e77089 100644
@@ -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);
 }

Signature · 1 line

2.1.4

Vinod Koul

Acked-by on v2 1/1

2015-06-12 07:21 UTC #15 lore raw

Re: [PATCH v2] ASoC: Intel: sst: use ; instead of , at the of a C statement

Quoted 6 lines · Sebastian Andrzej Siewior

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]>

Signature · 1 line

~Vinod

Quoted 27 lines

---

Quoted 2 lines · * Mats Karrman | 2015-06-11 15:04:25 [+0200]:

Review
Quoted 1 line
(quoted diff) +1 -0
+	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(-)

sound/soc/intel/atom/sst/sst.c +2 -2

index 96c2e420cce6..a4b458e77089 100644
@@ -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);
 }

Signature · 1 line

2.1.4

Mark Brown

maintainer Applied

2015-06-12 10:37 UTC #16 lore raw

Re: [PATCH v2] ASoC: Intel: sst: use ; instead of , at the of a C statement

In reply to Sebastian Andrzej Siewior

Quoted 3 lines · Sebastian Andrzej Siewior

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.

Clark Williams

2015-05-26 13:34 UTC #17 lore raw

In reply to Sebastian Andrzej Siewior

Quoted 4 lines · On Tue, 19 May 2015 23:39:23 +0200 Sebastian Andrzej Siewior…

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(+)

drivers/gpu/drm/i915/intel_display.c +2 -0

index f75173c20f47..f532b22f56ba 100644
@@ -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;

Steven Rostedt

2015-05-26 13:38 UTC #18 lore raw

drivers/gpu/drm/i915/intel_display.c void intel_check_page_flip(struct drm_device *dev, int pipe) · line 9750

Quoted 11 lines · On Tue, 26 May 2015 08:34:49 -0500 Clark Williams <[email protected]> wrote:

drivers/gpu/drm/i915/intel_display.c +2 -0

index f75173c20f47..f532b22f56ba 100644
@@ -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

Quoted 3 lines

drivers/gpu/drm/i915/intel_display.c +0 -0
 	if (crtc == NULL)
 		return;

Clark Williams

2015-05-26 13:48 UTC #19 lore raw

Quoted 18 lines · On Tue, 26 May 2015 09:38:32 -0400 Steven Rostedt <[email protected]> wrote:

drivers/gpu/drm/i915/intel_display.c void intel_check_page_flip(struct drm_device *dev, int pipe) · line 9750
Quoted 11 lines · On Tue, 26 May 2015 08:34:49 -0500 Clark Williams <[email protected]> wrote:
drivers/gpu/drm/i915/intel_display.c +2 -0
index f75173c20f47..f532b22f56ba 100644
@@ -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...

Quoted 3 lines

	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(-)

drivers/gpu/drm/i915/intel_display.c +1 -1

index f75173c20f47..b21e3a334e4e 100644
@@ -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;

Signature · 1 line

2.1.0

Mike Galbraith

2015-05-26 14:49 UTC #20 lore raw

Quoted 21 lines · Clark Williams

Quoted 18 lines · On Tue, 26 May 2015 09:38:32 -0400 Steven Rostedt <[email protected]> wrote:
drivers/gpu/drm/i915/intel_display.c void intel_check_page_flip(struct drm_device *dev, int pipe) · line 9750
Quoted 11 lines · On Tue, 26 May 2015 08:34:49 -0500 Clark Williams <[email protected]> wrote:
drivers/gpu/drm/i915/intel_display.c +2 -0
index f75173c20f47..f532b22f56ba 100644
@@ -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...

Quoted 5 lines

Quoted 3 lines
	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

Steven Rostedt

2015-05-26 15:19 UTC #21 lore raw

In reply to Clark Williams

Quoted 1 line · 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

Quoted 19 lines

Signed-off-by Clark Williams <[email protected]>

---
 drivers/gpu/drm/i915/intel_display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/gpu/drm/i915/intel_display.c +1 -1

index f75173c20f47..b21e3a334e4e 100644
@@ -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;

Clark Williams

2015-05-26 15:43 UTC #22 lore raw

Quoted 10 lines · On Tue, 26 May 2015 11:19:24 -0400 Steven Rostedt <[email protected]> wrote:

Quoted 1 line · 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

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(-)

drivers/gpu/drm/i915/intel_display.c +1 -1

index f75173c20f47..30b1d16caa0d 100644
@@ -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;

Signature · 1 line

2.1.0

Fernando Lopez-Lezcano

2015-05-26 19:41 UTC #23 lore raw

Quoted 7 lines · Clark Williams

Quoted 4 lines · 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:

Quoted 8 lines

Quoted 6 lines
Quoted 1 line
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

Quoted 30 lines

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(-)
drivers/gpu/drm/i915/intel_display.c +1 -1
index f75173c20f47..30b1d16caa0d 100644
@@ -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;

Fernando Lopez-Lezcano

2015-05-29 01:56 UTC #24 lore raw

Quoted 13 lines · Fernando Lopez-Lezcano

Quoted 12 lines · Clark Williams
Quoted 9 lines · On Tue, 26 May 2015 11:19:24 -0400 Steven Rostedt <[email protected]> wrote:
Quoted 1 line · 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?

Quoted 6 lines

Quoted 3 lines
Quoted 1 line
-- 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....

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
May 28 18:49:21 localhost kernel: Modules linked in: ccm rfcomm fuse xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 tun nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter ip6t_REJECT nf_reje\

ct_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_mangle ip6table_security ip6table_raw ip6table_fi\
lter 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 crc32_pclmul crc32c_intel videobuf2_core videobuf2_memops ghash_clmulni_intel v4l2_common iwlmvm videodev media mac80211 \
btusb bluetooth iwlwifi

May 28 18:49:21 localhost kernel: snd_hda_codec_realtek snd_hda_codec_hdmi lpc_ich snd_hda_codec_generic cfg80211 mfd_core i2c_i801 snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_seq snd_se\
q_device snd_pcm thinkpad_acpi snd_timer rfkill tpm_tis snd mei_me ie31200_edac tpm mei edac_core soundcore shpchp nfsd auth_rpcgss nfs_acl lockd grace sunrpc serio_raw i915 sdhci_pci i2c_algo_bit sdhci \
e1000e drm_kms_helper mmc_core ptp drm pps_core wmi video
May 28 18:49:21 localhost kernel: CPU: 4 PID: 134 Comm: kswapd0 Tainted: G           OE   4.0.4-201.rt1.3.fc21.ccrma.x86_64+rt #1
May 28 18:49:21 localhost kernel: Hardware name: LENOVO 20BGCTO1WW/20BGCTO1WW, BIOS GNET65WW (2.13 ) 06/20/2014
May 28 18:49:21 localhost kernel: task: ffff88046650e9a0 ti: ffff88046657c000 task.ti: ffff88046657c000
May 28 18:49:21 localhost kernel: RIP: 0010:[<ffffffff812164b8>] [<ffffffff812164b8>] mem_cgroup_swapout+0x118/0x120
May 28 18:49:21 localhost kernel: RSP: 0018:ffff88046657f998  EFLAGS: 00010202
May 28 18:49:21 localhost kernel: RAX: 0000000000000246 RBX: ffffea0011150e80 RCX: 0000000000000000
May 28 18:49:21 localhost kernel: RDX: 000000000006a980 RSI: 0000000000000001 RDI: ffff88046d413800
May 28 18:49:21 localhost kernel: RBP: ffff88046657f9a8 R08: ffffffff81c68700 R09: ffff88046657fba8
May 28 18:49:21 localhost kernel: R10: 000000000000000a R11: ffff88046657ffd8 R12: ffff88046d413800
May 28 18:49:21 localhost kernel: R13: ffffffff81c68718 R14: 0000000000000001 R15: ffff88046657faa8
May 28 18:49:21 localhost kernel: FS:  0000000000000000(0000) GS:ffff88046da00000(0000) knlGS:0000000000000000
May 28 18:49:21 localhost kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
May 28 18:49:21 localhost kernel: CR2: 00007efd07eb8000 CR3: 0000000001c0e000 CR4: 00000000001407e0
May 28 18:49:21 localhost kernel: Stack:
May 28 18:49:21 localhost kernel: ffffea0011150e80 0000000000196218 ffff88046657f9e8 ffffffff811b8d8f
May 28 18:49:21 localhost kernel: 0000000000000000 ffff88046657fe48 ffffea0011150e80 ffff88046657fbc0
May 28 18:49:21 localhost kernel: ffffea0011150ea0 ffff88046657faa8 ffff88046657fb28 ffffffff811bba3f
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
May 28 18:49:21 localhost kernel: [<ffffffff811bd50c>] shrink_lruvec+0x62c/0x830
May 28 18:49:21 localhost kernel: [<ffffffff81014610>] ? __switch_to+0x150/0x610
May 28 18:49:21 localhost kernel: [<ffffffff811bd804>] shrink_zone+0xf4/0x2d0
May 28 18:49:21 localhost kernel: [<ffffffff811bec37>] kswapd+0x587/0xa80
May 28 18:49:21 localhost kernel: [<ffffffff811be6b0>] ? mem_cgroup_shrink_node_zone+0x1f0/0x1f0
May 28 18:49:21 localhost kernel: [<ffffffff810bf4ba>] kthread+0xca/0xe0
May 28 18:49:21 localhost kernel: [<ffffffff810bf3f0>] ? kthread_worker_fn+0x180/0x180
May 28 18:49:21 localhost kernel: [<ffffffff817a2098>] ret_from_fork+0x58/0x90
May 28 18:49:21 localhost kernel: [<ffffffff810bf3f0>] ? kthread_worker_fn+0x180/0x180
May 28 18:49:21 localhost kernel: Code: a6 81 48 89 df e8 a9 ce fb ff 0f 0b 0f 1f 80 00 00 00 00 48 c7 c6 f3 b7 a6 81 48 89 df e8 91 ce fb ff 0f 0b 0f 1f 80 00 00 00 00 <0f> 0b 66 0f 1f 44 00 00 0f 1f 44\
 00 00 8b 05 f5 c2 b0 00 85 c0
May 28 18:49:21 localhost kernel: RIP  [<ffffffff812164b8>] mem_cgroup_swapout+0x118/0x120
May 28 18:49:21 localhost kernel: RSP <ffff88046657f998>
May 28 18:49:21 localhost kernel: ---[ end trace 0000000000000002 ]---

----

-- Fernando

Fernando Lopez-Lezcano

2015-06-09 16:45 UTC #25 lore raw

Quoted 10 lines · Fernando Lopez-Lezcano

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

...

Quoted 1 line

----

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

Jun  9 03:49:19 localhost kernel: ------------[ cut here ]------------
Jun  9 03:49:19 localhost kernel: kernel BUG at mm/memcontrol.c:5848!
Jun  9 03:49:19 localhost kernel: invalid opcode: 0000 [#1] PREEMPT SMP 
Jun  9 03:49:19 localhost kernel: Modules linked in: bnep bluetooth rfkill fuse tun act_police cls_basic cls_flow cls_fw cls_u32 sch_tbf sch_prio sch_htb sch_hfsc sch_ingress sch_sfq xt_CHECKSUM ipt_rpfilter xt_statistic xt_CT nf_log_ipv4 nf_log_common xt_LOG xt_connlimit xt_realm xt_addrtype xt_comment xt_recent xt_nat ipt_MASQUERADE nf_nat_masquerade_ipv4 ipt_ECN ipt_CLUSTERIP ipt_ah xt_set ip_set nf_nat_tftp nf_nat_snmp_basic nf_conntrack_snmp nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_amanda nf_conntrack_sane ebtable_nat nf_conntrack_tftp ebtables nf_conntrack_sip nf_conntrack_proto_udplite nf_conntrack_proto_sctp nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_netbios_ns nf_conntrack_broadcast 
 nf_conntrack_irc nf_conntrack_h323
Jun  9 03:49:19 localhost kernel: nf_conntrack_ftp xt_TPROXY xt_time xt_TCPMSS xt_tcpmss xt_sctp xt_policy xt_pkttype xt_physdev br_netfilter bridge stp llc xt_owner xt_NFQUEUE xt_NFLOG nfnetlink_log xt_multiport xt_mark xt_mac xt_limit xt_length xt_iprange xt_helper xt_hashlimit xt_DSCP xt_dscp xt_dccp xt_connmark xt_CLASSIFY xt_AUDIT xt_state iptable_raw iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 iptable_mangle nfnetlink nfsv3 nfs_acl auth_rpcgss nfsv4 dns_resolver nfs lockd grace sunrpc fscache ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack nf_conntrack ip6table_filter ip6_tables w83627ehf hwmon_vid iTCO_wdt iTCO_vendor_support gpio_ich raid1 coretemp kvm_intel kvm hid_logitech_hidpp serio_raw snd_ice1712 snd_cs8427 snd_i2c snd_ice17xx_ak4x
 xx snd_ak4xxx_adda snd_mpu401_uart
Jun  9 03:49:19 localhost kernel: snd_rawmidi snd_ac97_codec ac97_bus snd_seq snd_seq_device snd_pcm snd_timer snd lpc_ich soundcore i2c_i801 mfd_core shpchp acpi_cpufreq binfmt_misc hid_logitech_dj ata_generic firewire_ohci radeon pata_acpi firewire_core crc_itu_t sata_sil24 i2c_algo_bit drm_kms_helper sky2 r8169 pata_marvell mii ttm drm
Jun  9 03:49:19 localhost kernel: CPU: 2 PID: 10424 Comm: prelink Not tainted 4.0.4-100.rt1.3.fc20.ccrma.x86_64+rt #1
Jun  9 03:49:19 localhost kernel: Hardware name: System manufacturer P5K/EPU/P5K/EPU, BIOS 0604    06/19/2008
Jun  9 03:49:19 localhost kernel: task: ffff8802225e1520 ti: ffff8801256c8000 task.ti: ffff8801256c8000
Jun  9 03:49:19 localhost kernel: RIP: 0010:[<ffffffff812112c2>]  [<ffffffff812112c2>] mem_cgroup_swapout+0x102/0x110
Jun  9 03:49:19 localhost kernel: RSP: 0018:ffff8801256cb288  EFLAGS: 00010202
Jun  9 03:49:19 localhost kernel: RAX: 0000000000000246 RBX: ffffea0008be7ec0 RCX: 0000000000000000
Jun  9 03:49:19 localhost kernel: RDX: 0000000000000000 RSI: ffff8801256cb248 RDI: ffffffff820236d0
Jun  9 03:49:19 localhost kernel: RBP: ffff8801256cb298 R08: ffffea0008be7ee0 R09: ffff8801256cb498
Jun  9 03:49:19 localhost kernel: R10: ffff8801256cbfd8 R11: 0000000000000002 R12: ffff880227013800
Jun  9 03:49:19 localhost kernel: R13: ffffffff81c652b8 R14: 0000000000000001 R15: ffffffff81c652a0
Jun  9 03:49:19 localhost kernel: FS:  0000000001ad8900(0063) GS:ffff88022fd00000(0000) knlGS:0000000000000000
Jun  9 03:49:19 localhost kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jun  9 03:49:19 localhost kernel: CR2: 0000000002131878 CR3: 000000014a4f3000 CR4: 00000000000007e0
Jun  9 03:49:19 localhost kernel: Stack:
Jun  9 03:49:19 localhost kernel: ffffea0008be7ec0 00000000000c2a0d ffff8801256cb2d8 ffffffff811b60c7
Jun  9 03:49:19 localhost kernel: 0000000000000000 ffff8801256cb738 ffffea0008be7ec0 ffff8801256cb4b0
Jun  9 03:49:19 localhost kernel: ffffea0008be7ee0 ffffffff81c652a0 ffff8801256cb418 ffffffff811b924f
Jun  9 03:49:19 localhost kernel: Call Trace:
Jun  9 03:49:19 localhost kernel: [<ffffffff811b60c7>] __remove_mapping+0x107/0x180
Jun  9 03:49:19 localhost kernel: [<ffffffff811b924f>] shrink_page_list+0x7df/0xb50
Jun  9 03:49:19 localhost kernel: [<ffffffff811b9bd1>] shrink_inactive_list+0x1e1/0x620
Jun  9 03:49:19 localhost kernel: [<ffffffff811ba9d5>] shrink_lruvec+0x635/0x840
Jun  9 03:49:19 localhost kernel: [<ffffffff811bacd0>] shrink_zone+0xf0/0x2f0
Jun  9 03:49:19 localhost kernel: [<ffffffff811bb265>] do_try_to_free_pages+0x175/0x450
Jun  9 03:49:19 localhost kernel: [<ffffffff811b65e8>] ? throttle_direct_reclaim+0x168/0x260
Jun  9 03:49:19 localhost kernel: [<ffffffff811bb61a>] try_to_free_pages+0xda/0x1d0
Jun  9 03:49:19 localhost kernel: [<ffffffff811adce1>] __alloc_pages_nodemask+0x531/0x980
Jun  9 03:49:19 localhost kernel: [<ffffffff811f6821>] alloc_pages_current+0x91/0x100
Jun  9 03:49:19 localhost kernel: [<ffffffff81201a87>] new_slab+0x397/0x4c0
Jun  9 03:49:19 localhost kernel: [<ffffffff8178c848>] __slab_alloc+0x429/0x54e
Jun  9 03:49:19 localhost kernel: [<ffffffff812c0efd>] ? ext4_alloc_inode+0x1d/0x280
Jun  9 03:49:19 localhost kernel: [<ffffffff812acbb7>] ? ext4_map_blocks+0x2e7/0x520
Jun  9 03:49:19 localhost kernel: [<ffffffff81201da3>] kmem_cache_alloc+0x1f3/0x270
Jun  9 03:49:19 localhost kernel: [<ffffffff812c0efd>] ext4_alloc_inode+0x1d/0x280
Jun  9 03:49:19 localhost kernel: [<ffffffff8123731d>] alloc_inode+0x1d/0xa0
Jun  9 03:49:19 localhost kernel: [<ffffffff8123856b>] iget_locked+0xdb/0x1b0
Jun  9 03:49:19 localhost kernel: [<ffffffff812adc32>] ext4_iget+0x42/0xb10
Jun  9 03:49:19 localhost kernel: [<ffffffff812ae735>] ext4_iget_normal+0x35/0x40
Jun  9 03:49:19 localhost kernel: [<ffffffff812b8977>] ext4_lookup+0x107/0x170
Jun  9 03:49:19 localhost kernel: [<ffffffff812253dd>] lookup_real+0x1d/0x50
Jun  9 03:49:19 localhost kernel: [<ffffffff81225d42>] __lookup_hash+0x42/0x60
Jun  9 03:49:19 localhost kernel: [<ffffffff8178cc17>] lookup_slow+0x45/0xab
Jun  9 03:49:19 localhost kernel: [<ffffffff81229a88>] path_lookupat+0x6d8/0x700
Jun  9 03:49:19 localhost kernel: [<ffffffff810e3a19>] ? __wake_up+0x49/0x60
Jun  9 03:49:19 localhost kernel: [<ffffffff812fc065>] ? jbd2_journal_stop+0x1e5/0x400
Jun  9 03:49:19 localhost kernel: [<ffffffff81229adb>] filename_lookup+0x2b/0xc0
Jun  9 03:49:19 localhost kernel: [<ffffffff8122ce03>] user_path_at_empty+0x63/0xc0
Jun  9 03:49:19 localhost kernel: [<ffffffff81249c82>] ? __mark_inode_dirty+0x352/0x460
Jun  9 03:49:19 localhost kernel: [<ffffffff8122ce71>] user_path_at+0x11/0x20
Jun  9 03:49:19 localhost kernel: [<ffffffff81220363>] vfs_fstatat+0x63/0xc0
Jun  9 03:49:19 localhost kernel: [<ffffffff81220984>] SYSC_newfstatat+0x24/0x60
Jun  9 03:49:19 localhost kernel: [<ffffffff8102597c>] ? do_audit_syscall_entry+0x6c/0x70
Jun  9 03:49:19 localhost kernel: [<ffffffff81027343>] ? syscall_trace_enter_phase1+0x143/0x1a0
Jun  9 03:49:19 localhost kernel: [<ffffffff810276b6>] ? syscall_trace_leave+0xc6/0x130
Jun  9 03:49:19 localhost kernel: [<ffffffff8179500a>] ? int_check_syscall_exit_work+0x34/0x3d
Jun  9 03:49:19 localhost kernel: [<ffffffff81220bee>] SyS_newfstatat+0xe/0x10
Jun  9 03:49:19 localhost kernel: [<ffffffff81794dc9>] system_call_fastpath+0x12/0x17
Jun  9 03:49:19 localhost kernel: Code: 80 e6 80 48 0f 44 c3 e9 49 ff ff ff 48 c7 c6 7f 3e a6 81 e8 81 f6 fb ff 0f 0b 48 c7 c6 cb 67 a6 81 48 89 df e8 70 f6 fb ff 0f 0b <0f> 0b 66 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 8b 05 
Jun  9 03:49:19 localhost kernel: RIP  [<ffffffff812112c2>] mem_cgroup_swapout+0x102/0x110
Jun  9 03:49:19 localhost kernel: RSP <ffff8801256cb288>
Jun  9 03:49:19 localhost kernel: ---[ end trace 0000000000000002 ]---

Pavel Vasilyev

2015-06-09 22:05 UTC #26 lore raw

09.06.2015 19:45, Fernando Lopez-Lezcano пишет:

Quoted 3 lines

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

Signature · 1 line

                                                         Pavel.

Mike Galbraith

2015-06-10 02:41 UTC #27 lore raw

Quoted 7 lines · Pavel Vasilyev

09.06.2015 19:45, Fernando Lopez-Lezcano пишет:
Quoted 3 lines
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

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Fernando Lopez-Lezcano

2015-06-10 03:10 UTC #28 lore raw

In reply to Pavel Vasilyev

Quoted 8 lines · Pavel Vasilyev

09.06.2015 19:45, Fernando Lopez-Lezcano пишет:
Quoted 3 lines
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.

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Pavel Vasilyev

2015-06-09 22:14 UTC #29 lore raw

In reply to Fernando Lopez-Lezcano

09.06.2015 19:45, Fernando Lopez-Lezcano пишет:

Quoted 3 lines

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

Signature · 5 lines

                                                          Pavel.
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Sebastian Andrzej Siewior

author

2015-06-11 12:38 UTC #30 lore raw

In reply to Fernando Lopez-Lezcano

Quoted 3 lines · * 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

Quoted 7 lines

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
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Joakim Hernberg

2015-05-28 08:41 UTC #31 lore raw

In reply to Clark Williams

Quoted 41 lines · On Tue, 26 May 2015 10:43:43 -0500 Clark Williams <[email protected]> wrote:

Quoted 10 lines · On Tue, 26 May 2015 11:19:24 -0400 Steven Rostedt <[email protected]> wrote:
Quoted 1 line · 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(-)
(quoted diff) +0 -0
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);

drivers/gpu/drm/i915/intel_display.c void intel_check_page_flip(struct drm_device *dev, int pipe) · line 9751

Quoted 5 lines

drivers/gpu/drm/i915/intel_display.c +1 -1

-	WARN_ON(!in_interrupt());
+	WARN_ON_NONRT(!in_interrupt());
 
 	if (crtc == NULL)
 		return;

You can add my Tested-by: Joakim Hernberg <[email protected]>. Seems to fix the problem on my systems too.

Signature · 1 line

   Joakim

Sebastian Andrzej Siewior

author Applied

2015-06-11 12:34 UTC #32 lore raw

In reply to Clark Williams

Quoted 4 lines · * 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

Quoted 8 lines

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

Joakim Hernberg

2015-05-27 09:44 UTC #33 lore raw

In reply to Sebastian Andrzej Siewior

Quoted 3 lines · On Tue, 19 May 2015 23:39:23 +0200 Sebastian Andrzej Siewior…

Dear RT folks!
I'm pleased to announce the v4.0.4-rt1 patch set.

I see the following trying to build based on archlinux' default config:

jack@balder /home/jack/archaudio/linux-rt-new/src/linux-4.0 $ make

  CHK     include/config/kernel.release
  CHK     include/generated/uapi/linux/version.h
  CHK     include/generated/utsrelease.h
  CALL    scripts/checksyscalls.sh
  CHK     include/generated/compile.h
kernel/Makefile:133: *** No X.509 certificates found ***
  CHK     kernel/config_data.h
  CC [M]  sound/soc/intel/sst/sst.o
  CC [M]  sound/soc/intel/sst/sst_ipc.o
In file included from include/linux/spinlock.h:300:0,
                 from include/linux/seqlock.h:35,
                 from include/linux/time.h:5,
                 from include/linux/stat.h:18,
                 from include/linux/module.h:10,
                 from sound/soc/intel/sst/sst.c:22:

sound/soc/intel/sst/sst.c: In function ‘sst_restore_shim64’:
include/linux/spinlock_rt.h:137:2: error: expected expression before ‘do’
do { \
^
sound/soc/intel/sst/sst.c:373:2: note: in expansion of macro ‘spin_unlock_irqrestore’
spin_unlock_irqrestore(&ctx->ipc_spin_lock, irq_flags);
^
scripts/Makefile.build:258: recipe for target 'sound/soc/intel/sst/sst.o' failed make[4]: *** [sound/soc/intel/sst/sst.o] Error 1
make[4]: *** Waiting for unfinished jobs....
LD sound/soc/rockchip/built-in.o
scripts/Makefile.build:403: recipe for target 'sound/soc/intel/sst' failed make[3]: *** [sound/soc/intel/sst] Error 2
scripts/Makefile.build:403: recipe for target 'sound/soc/intel' failed make[2]: *** [sound/soc/intel] Error 2
make[2]: *** Waiting for unfinished jobs.... scripts/Makefile.build:403: recipe for target 'sound/soc' failed make[1]: *** [sound/soc] Error 2
make[1]: *** Waiting for unfinished jobs....
Makefile:947: recipe for target 'sound' failed
make: *** [sound] Error 2
make: *** Waiting for unfinished jobs....

It wasn't enough to disable CONFIG_SND_SOC_INTEL_SST, I had to disable all of CONFIG_SND_SOC to be able to build it, here is a link to the archlinux config changes for CONFIG_SND_SOC: https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/linux&id=bd0bf646b706838518f1d104803495806249865e

Signature · 1 line

   Joakim

Jeremy Jongepier

2015-05-27 10:19 UTC #34 lore raw

Quoted 48 lines · Joakim Hernberg

Quoted 3 lines · On Tue, 19 May 2015 23:39:23 +0200 Sebastian Andrzej Siewior…
Dear RT folks!
I'm pleased to announce the v4.0.4-rt1 patch set.
I see the following trying to build based on archlinux' default config:
jack@balder /home/jack/archaudio/linux-rt-new/src/linux-4.0 $ make
  CHK     include/config/kernel.release
  CHK     include/generated/uapi/linux/version.h
  CHK     include/generated/utsrelease.h
  CALL    scripts/checksyscalls.sh
  CHK     include/generated/compile.h
kernel/Makefile:133: *** No X.509 certificates found ***
  CHK     kernel/config_data.h
  CC [M]  sound/soc/intel/sst/sst.o
  CC [M]  sound/soc/intel/sst/sst_ipc.o
In file included from include/linux/spinlock.h:300:0,
                 from include/linux/seqlock.h:35,
                 from include/linux/time.h:5,
                 from include/linux/stat.h:18,
                 from include/linux/module.h:10,
                 from sound/soc/intel/sst/sst.c:22:
sound/soc/intel/sst/sst.c: In function ‘sst_restore_shim64’:
include/linux/spinlock_rt.h:137:2: error: expected expression before ‘do’
do { \
^
sound/soc/intel/sst/sst.c:373:2: note: in expansion of macro ‘spin_unlock_irqrestore’
spin_unlock_irqrestore(&ctx->ipc_spin_lock, irq_flags);
^
scripts/Makefile.build:258: recipe for target 'sound/soc/intel/sst/sst.o' failed make[4]: *** [sound/soc/intel/sst/sst.o] Error 1
make[4]: *** Waiting for unfinished jobs....
LD sound/soc/rockchip/built-in.o
scripts/Makefile.build:403: recipe for target 'sound/soc/intel/sst' failed make[3]: *** [sound/soc/intel/sst] Error 2
scripts/Makefile.build:403: recipe for target 'sound/soc/intel' failed make[2]: *** [sound/soc/intel] Error 2
make[2]: *** Waiting for unfinished jobs.... scripts/Makefile.build:403: recipe for target 'sound/soc' failed make[1]: *** [sound/soc] Error 2
make[1]: *** Waiting for unfinished jobs....
Makefile:947: recipe for target 'sound' failed
make: *** [sound] Error 2
make: *** Waiting for unfinished jobs....

Quoted 2 lines

It wasn't enough to disable CONFIG_SND_SOC_INTEL_SST, I had to disable all of CONFIG_SND_SOC to be able to build it, here is a link to the archlinux config changes for CONFIG_SND_SOC: https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/linux&id=bd0bf646b706838518f1d104803495806249865e

Hello Joakim,

Looks a lot like: http://www.spinics.net/lists/linux-rt-users/msg13403.html

Jeremy

Joakim Hernberg

2015-05-28 08:43 UTC #35 lore raw

Quoted 56 lines · On Wed, 27 May 2015 12:19:00 +0200 Jeremy Jongepier <[email protected]>…

Quoted 49 lines · Joakim Hernberg
Quoted 3 lines · On Tue, 19 May 2015 23:39:23 +0200 Sebastian Andrzej Siewior…
Dear RT folks!
I'm pleased to announce the v4.0.4-rt1 patch set.
I see the following trying to build based on archlinux' default config:
jack@balder /home/jack/archaudio/linux-rt-new/src/linux-4.0 $ make
  CHK     include/config/kernel.release
  CHK     include/generated/uapi/linux/version.h
  CHK     include/generated/utsrelease.h
  CALL    scripts/checksyscalls.sh
  CHK     include/generated/compile.h
kernel/Makefile:133: *** No X.509 certificates found ***
  CHK     kernel/config_data.h
  CC [M]  sound/soc/intel/sst/sst.o
  CC [M]  sound/soc/intel/sst/sst_ipc.o
In file included from include/linux/spinlock.h:300:0,
                 from include/linux/seqlock.h:35,
                 from include/linux/time.h:5,
                 from include/linux/stat.h:18,
                 from include/linux/module.h:10,
                 from sound/soc/intel/sst/sst.c:22:
sound/soc/intel/sst/sst.c: In function ‘sst_restore_shim64’:
include/linux/spinlock_rt.h:137:2: error: expected expression
before ‘do’ do { \
^
sound/soc/intel/sst/sst.c:373:2: note: in expansion of macro ‘spin_unlock_irqrestore’ spin_unlock_irqrestore(&ctx->ipc_spin_lock, irq_flags); ^ scripts/Makefile.build:258: recipe for target 'sound/soc/intel/sst/sst.o' failed make[4]: *** [sound/soc/intel/sst/sst.o] Error 1 make[4]: *** Waiting for
unfinished jobs.... LD sound/soc/rockchip/built-in.o
scripts/Makefile.build:403: recipe for target 'sound/soc/intel/sst' failed make[3]: *** [sound/soc/intel/sst] Error 2 scripts/Makefile.build:403: recipe for target 'sound/soc/intel' failed make[2]: *** [sound/soc/intel] Error 2
make[2]: *** Waiting for unfinished jobs.... scripts/Makefile.build:403: recipe for target 'sound/soc' failed make[1]: *** [sound/soc] Error 2
make[1]: *** Waiting for unfinished jobs.... Makefile:947: recipe for target 'sound' failed
make: *** [sound] Error 2
make: *** Waiting for unfinished jobs....
Quoted 5 lines
It wasn't enough to disable CONFIG_SND_SOC_INTEL_SST, I had to disable all of CONFIG_SND_SOC to be able to build it, here is a link to the archlinux config changes for CONFIG_SND_SOC:
https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/linux&id=bd0bf646b706838518f1d104803495806249865e

Quoted 7 lines

Hello Joakim,
Looks a lot like:
http://www.spinics.net/lists/linux-rt-users/msg13403.html
Jeremy

Yeah, fixing the typos allows it to build. Strange that it built on vanilla without fix though, but that's not important. Thanks.

Signature · 5 lines

   Joakim
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Ralf Mardorf

2015-05-27 16:01 UTC #36 lore raw

In reply to Joakim Hernberg

Quoted 1 line · Joakim Hernberg

I see the following trying to build based on archlinux' default config:

Hi Joakim,

I'll test if I need to build with
# CONFIG_X86_POWERNOW_K8 is not set
resp. if I need to remove the k8 module from /lib/modules/.*/drivers/cpufreq/ as soon as a PKGBUILD for kernel 4 is available.

The last kernel I tested was

$ pacman -Q linux-rt
linux-rt 3.18.9_rt5-2
perhaps you remember that I needed to disable CONFIG_X86_POWERNOW_K8.

I wonder how many AMD machines suffer from this issue.

Regards,
Ralf