[ANNOUNCE] 4.0.4-rt1

[ANNOUNCE] 4.0.4-rt1

[Sebastian Andrzej Siewior]

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

Re: [ANNOUNCE] 4.0.4-rt1

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

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

Re: [ANNOUNCE] 4.0.4-rt1

[Pavel Vasilyev]

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.

Re: [ANNOUNCE] 4.0.4-rt1

[Sebastian Andrzej Siewior]

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

Re: [ANNOUNCE] 4.0.4-rt1

[Daniel Wagner]

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

Re: [ANNOUNCE] 4.0.4-rt1

[Pavel Vasilyev]

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.

Re: [ANNOUNCE] 4.0.4-rt1

[Mike Galbraith]

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

Re: [ANNOUNCE] 4.0.4-rt1

[Pavel Vasilyev]

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.

Re: [ANNOUNCE] 4.0.4-rt1

[Sebastian Andrzej Siewior]

* 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

Re: [ANNOUNCE] 4.0.4-rt1

[Pavel Vasilyev]

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.

Re: [ANNOUNCE] 4.0.4-rt1

[Sebastian Andrzej Siewior]

* 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

Re: [ANNOUNCE] 4.0.4-rt1

[Fernando Lopez-Lezcano]

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

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

[Sebastian Andrzej Siewior]

This was spotted by Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU>
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 <nando@ccrma.Stanford.EDU>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
 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

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

[Mats Karrman]

On 2015-06-11 14:22, Sebastian Andrzej Siewior wrote:
> This was spotted by Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU>
> 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 <nando@ccrma.Stanford.EDU>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
>   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);
>   }
>   

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

[Sebastian Andrzej Siewior]

This was spotted by Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU>
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 <nando@ccrma.Stanford.EDU>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
* 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

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

[Vinod Koul]

On Thu, Jun 11, 2015 at 03:14:34PM +0200, Sebastian Andrzej Siewior wrote:
> This was spotted by Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU>
> 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 <nando@ccrma.Stanford.EDU>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: Vinod Koul <vinod.koul@intel.com>

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

-- 

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 304 bytes --]

On Thu, Jun 11, 2015 at 03:14:34PM +0200, Sebastian Andrzej Siewior wrote:
> This was spotted by Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU>
> 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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [ANNOUNCE] 4.0.4-rt1

[Clark Williams]

On Tue, 19 May 2015 23:39:23 +0200
Sebastian Andrzej Siewior <bigeasy@linutronix.de> 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 <williams@redhat.com>
---
 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;

Re: [ANNOUNCE] 4.0.4-rt1

[Steven Rostedt]

On Tue, 26 May 2015 08:34:49 -0500
Clark Williams <williams@redhat.com> 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;

Re: [ANNOUNCE] 4.0.4-rt1

[Clark Williams]

On Tue, 26 May 2015 09:38:32 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> On Tue, 26 May 2015 08:34:49 -0500
> Clark Williams <williams@redhat.com> 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 <williams@redhat.com>
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 <williams@redhat.com>
---
 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

Re: [ANNOUNCE] 4.0.4-rt1

[Mike Galbraith]

On Tue, 2015-05-26 at 08:48 -0500, Clark Williams wrote:
> On Tue, 26 May 2015 09:38:32 -0400
> Steven Rostedt <rostedt@goodmis.org> wrote:
> 
> > On Tue, 26 May 2015 08:34:49 -0500
> > Clark Williams <williams@redhat.com> 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

Re: [ANNOUNCE] 4.0.4-rt1

[Steven Rostedt]

On Tue, 26 May 2015 08:48:02 -0500
Clark Williams <williams@redhat.com> 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 <williams@redhat.com>
> ---
>  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;

Re: [ANNOUNCE] 4.0.4-rt1

[Clark Williams]

On Tue, 26 May 2015 11:19:24 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> On Tue, 26 May 2015 08:48:02 -0500
> Clark Williams <williams@redhat.com> 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 <williams@redhat.com>
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 <williams@redhat.com>
---
 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

Re: [ANNOUNCE] 4.0.4-rt1

[Fernando Lopez-Lezcano]

On 05/26/2015 08:43 AM, Clark Williams wrote:
> On Tue, 26 May 2015 11:19:24 -0400
> Steven Rostedt <rostedt@goodmis.org> wrote:
>
>> On Tue, 26 May 2015 08:48:02 -0500
>> Clark Williams <williams@redhat.com> 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 <williams@redhat.com>
> 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 <williams@redhat.com>
> ---
>   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;
>

Re: [ANNOUNCE] 4.0.4-rt1

[Fernando Lopez-Lezcano]

On 05/26/2015 12:41 PM, Fernando Lopez-Lezcano wrote:
> On 05/26/2015 08:43 AM, Clark Williams wrote:
>> On Tue, 26 May 2015 11:19:24 -0400
>> Steven Rostedt <rostedt@goodmis.org> wrote:
>>
>>> On Tue, 26 May 2015 08:48:02 -0500
>>> Clark Williams <williams@redhat.com> 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....

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

Re: [ANNOUNCE] 4.0.4-rt1

[Fernando Lopez-Lezcano]

[-- Attachment #1: Type: text/plain, Size: 879 bytes --]

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

[-- Attachment #2: trace.txt --]
[-- Type: text/plain, Size: 7638 bytes --]

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

Re: [ANNOUNCE] 4.0.4-rt1

[Pavel Vasilyev]

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.

Re: [ANNOUNCE] 4.0.4-rt1

[Mike Galbraith]

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

Re: [ANNOUNCE] 4.0.4-rt1

[Fernando Lopez-Lezcano]

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.

Re: [ANNOUNCE] 4.0.4-rt1

[Pavel Vasilyev]

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.

Re: [ANNOUNCE] 4.0.4-rt1

[Sebastian Andrzej Siewior]

* 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

Re: [ANNOUNCE] 4.0.4-rt1

[Joakim Hernberg]

On Tue, 26 May 2015 10:43:43 -0500
Clark Williams <williams@redhat.com> wrote:

> On Tue, 26 May 2015 11:19:24 -0400
> Steven Rostedt <rostedt@goodmis.org> wrote:
> 
> > On Tue, 26 May 2015 08:48:02 -0500
> > Clark Williams <williams@redhat.com> 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 <williams@redhat.com>
> 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 <williams@redhat.com>
> ---
>  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;

You can add my Tested-by: Joakim Hernberg <jhernberg@alchemy.lu>.
Seems to fix the problem on my systems too.

-- 

   Joakim

Re: [ANNOUNCE] 4.0.4-rt1

[Sebastian Andrzej Siewior]

* Clark Williams | 2015-05-26 10:43:43 [-0500]:

>From: Clark Williams <williams@redhat.com>
>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 <williams@redhat.com>

Applied, thanks.

Sebastian

Re: [ANNOUNCE] 4.0.4-rt1

[Joakim Hernberg]

On Tue, 19 May 2015 23:39:23 +0200
Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:

> 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

-- 

   Joakim

Re: [ANNOUNCE] 4.0.4-rt1

[Jeremy Jongepier]

[-- Attachment #1: Type: text/plain, Size: 2645 bytes --]

On 05/27/2015 11:44 AM, Joakim Hernberg wrote:
> On Tue, 19 May 2015 23:39:23 +0200
> Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
> 
>> 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
> 

Hello Joakim,

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

Jeremy


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [ANNOUNCE] 4.0.4-rt1

[Joakim Hernberg]

On Wed, 27 May 2015 12:19:00 +0200
Jeremy Jongepier <jeremy@autostatic.com> wrote:

> On 05/27/2015 11:44 AM, Joakim Hernberg wrote:
> > On Tue, 19 May 2015 23:39:23 +0200
> > Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
> > 
> >> 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
> > 
> 
> 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.

-- 

   Joakim