Bug 1029634

the mentioned "steps to reproduce" are incomplete. I crosschecked and the steps to reproduce (verified 3x) are:

* put system to STR in the docking station
* wait for system to be in STR
* close lid
* remove from dock
* open lid (system starts up)
* call `xrandr --outpxrandr --output eDP1 --primary --auto --output DP1-1 --off; xrandr --output eDP1 --primary --auto --output DP1-1 --auto --left-of eDP1`
* close lid (system goes to STR)
* put it back to dock
* open lid (system starts up)
* call `xrandr --outpxrandr --output eDP1 --primary --auto --output DP1-1 --off; xrandr --output eDP1 --primary --auto --output DP1-1 --auto --left-of eDP1`
* wait some seconds
* observe the problem (blinking caps lock led, system does not react anymore)

it takes about 10 seconds from "the system does not react anymore" to "caps lock led blinks".

With the help of logging I found out that the step `xrandr --output eDP1 --primary --auto --output DP1-1 --auto --left-of eDP1` might be the problem, not the line before switching external ones off.

4.4.27-2.1 can not reproduce the problem, supporting H1.1

ACCEPT H1
REJECT H2
REJECT H3

4.4.36-8.1 can not reproduce the problem

REJECT H1.1 4.4.27-2.1 -> 4.4.49-16
REJECT H1.2 4.4.36-5.1 -> 4.4.49-16
SUPPORT H1.3, H1.4

4.4.46-11 can reproduce the problem

REJECT H1.3 4.4.36-8.1 -> 4.4.49-16
ACCEPT H1.4 4.4.46-11.1 -> 4.4.49-16

problem can also be reproduced if I just call a single line of xrandr, i.e. switch off external screen after undocking, switching on external screen after docking. It can not be reproduced leaving out the STR step it seems.

previously reproduced in awesome, now in lxde. Trying to simplify reproduction and gather some data, e.g. skip the STR part and/or docking/undocking.

Now in icewm because even simpler, no locking screen, etc. Looks like in icewm there is some automated screen detection so it might be it detects the external screen and activates when it didn't in before. 

## E1
* SKIP put system to STR in the docking station
* SKIP wait for system to be in STR
* SKIP close lid
* remove from dock
* open lid (system starts up)
* call `xrandr --outpxrandr --output eDP1 --primary --auto --output DP1-1 --off; xrandr --output eDP1 --primary --auto --output DP1-1 --auto --left-of eDP1`
* close lid (system goes to STR)
* put it back to dock
* open lid (system starts up)
* call `xrandr --outpxrandr --output eDP1 --primary --auto --output DP1-1 --off; xrandr --output eDP1 --primary --auto --output DP1-1 --auto --left-of eDP1`
* wait some seconds
* observe the problem (blinking caps lock led, system does not react anymore)

--> not successful, so need to put to STR first from docking

## E2
* put system to STR in the docking station
* wait for system to be in STR
* close lid
* remove from dock
* open lid (system starts up)
* call `xrandr --outpxrandr --output eDP1 --primary --auto --output DP1-1 --off; xrandr --output eDP1 --primary --auto --output DP1-1 --auto --left-of eDP1`
* SKIP close lid (system goes to STR)
* put it back to dock
* SKIP open lid (system starts up)
* call `xrandr --outpxrandr --output eDP1 --primary --auto --output DP1-1 --off; xrandr --output eDP1 --primary --auto --output DP1-1 --auto --left-of eDP1`
* wait some seconds
* observe the problem (blinking caps lock led, system does not react anymore)

--> already panicked after putting it live back to dock

## E3

* put system to STR in the docking station
* wait for system to be in STR
* SKIP close lid
* remove from dock
* SKIP open lid (system starts up) -> start
* SKIP call `xrandr --outpxrandr --output eDP1 --primary --auto --output DP1-1 --off; xrandr --output eDP1 --primary --auto --output DP1-1 --auto --left-of eDP1`
* put it back to dock
* observe the problem (blinking caps lock led, system does not react anymore)

--> panicked

After bootup into icewm the two displays were configured to clone with same resolution. I did not tweak that and did not call `xrandr` in the process at all and could still reproduce the same kernel panic so the issue is not related to the `xrandr` call.

## E4

* put system to STR in the docking station with `sudo systemctl suspend`
* wait for system to be in STR
* remove from dock
* start
* put it back to dock
* observe the problem (blinking caps lock led, system does not react anymore)

--> panicked

## E5

* put system to STR in the docking station with `sudo systemctl suspend`
* wait for system to be in STR
* disconnected external display
* start
* reconnected external display
* observe the problem (blinking caps lock led, system does not react anymore)

--> panicked


## E6

* disconnected external display
* wait 2 seconds
* reconnected external display
* observe the problem (blinking caps lock led, system does not react anymore)

--> does not panic, so I need the STR step


back to E5 but because in icewm there is automatic detection I can stay on a text terminal and record at least some information.

Created attachment 717861 [details]
screenshot showing kernel panic stack trace

updated the screenshot, much better readable

Looking at the changelog of kernel-default I can find the following changes which sound related:

```
* Wed Feb 01 2017 tiwai@suse.de
- drm/i915/gen9: Fix PCODE polling during CDCLK change
  notification (bsc#1015367).
- drm/i915: Mark CPU cache as dirty when used for rendering
  (bsc#1015367).
- commit 68975cf

* Wed Feb 01 2017 tiwai@suse.de
- drm/i915: Don't init hpd polling for vlv and chv from
  runtime_suspend() (bsc#1014120).
- drm/i915/vlv: Prevent enabling hpd polling in late suspend
  (bsc#1014120).
- drm/i915: Mark i915_hpd_poll_init_work as static (bsc#1014120).
- drm/i915: Fix watermarks for VLV/CHV (bsc#1011176).
- commit 3fb681b

* Wed Feb 01 2017 tiwai@suse.de
- Delete previous two fixes for i915 (bsc#1019061).
  These upstream fixes brought some regressions, so better to revert for now.
- patches.drivers/drm-i915-Prevent-PPS-stealing-from-a-normal-DP-port
- patches.drivers/drm-i915-dp-Restore-PPS-HW-state-from-the-encoder-re
- commit ac2223d

* Wed Feb 01 2017 tiwai@suse.de
- drm/i915: Workaround for DP DPMS D3 on Dell monitor
  (bsc#1019061).
- drm/i915: Prevent PPS stealing from a normal DP port on VLV/CHV
  (bsc#1019061).
- drm/i915/dp: Restore PPS HW state from the encoder resume hook
  (bsc#1019061).
- commit 005222b
```

Do any of these sound related to you?

After the update includes several severe security-fixes, we will not retract the update for now, but we'll start an follow-up update as soon as a fix is ready.

As a workaround, you can downgrade to the previous version 4.4.46-11.1.

Thank you very much for the report and the analysis!

Created attachment 717883 [details]
additional error messages on text terminal

Additional messages I see before the kernel panic on text terminal
"Kernel panic - not syncing: Timeout: Not all CPUs entered broadcast exception handler"

and also the ones showing up in the screenshot, e.g.

"Out of memory: Kill process 76 (haveged) score 49 or sacrifice child"

The stack trace related i915 might be a red herring in this case.

Could you try with kernel-vanilla 4.4.49 to check whether the issue is reproducible or not?  If it's about our own patches, I can give a kernel with the recent i915 changes reverted later.

(In reply to Takashi Iwai from comment #10)
> Could you try with kernel-vanilla 4.4.49 to check whether the issue is
> reproducible or not?

good idea. It is *not* reproducible with kernel-vanilla-4.4.49 -> SUSE patches.

> If it's about our own patches, I can give a kernel
> with the recent i915 changes reverted later.

I would appreciate that.

(In reply to Oliver Kurz from comment #11)
> > If it's about our own patches, I can give a kernel
> > with the recent i915 changes reverted later.
> 
> I would appreciate that.

Would it be more efficient if I build the kernel on my own to bisect? But for that probably I would a little hint where to start. I guess building a package from OBS locally and systematically commenting/uncommenting in a spec file might work?

I'm building a kernel with a few i915 patches reverted in IBS home:tiwai:test:bnc1029634 repo.  Could you give it a try later?

(In reply to Takashi Iwai from comment #13)
> I'm building a kernel with a few i915 patches reverted in IBS
> home:tiwai:test:bnc1029634 repo.  Could you give it a try later?

tested, FAILED. same symptoms.

Looking through the whole description, I'm a bit confused.  In comment 3,

(In reply to Oliver Kurz from comment #3)
> 4.4.36-8.1 can not reproduce the problem
> 
> REJECT H1.1 4.4.27-2.1 -> 4.4.49-16
> REJECT H1.2 4.4.36-5.1 -> 4.4.49-16
> SUPPORT H1.3, H1.4
> 
> 4.4.46-11 can reproduce the problem
> 
> REJECT H1.3 4.4.36-8.1 -> 4.4.49-16
> ACCEPT H1.4 4.4.46-11.1 -> 4.4.49-16

... but the subject states it's a regression from 4.4.46 to 4.4.49.
Which is the correct information?

If 4.4.46 works, the range is much narrower than 4.4.36.

right, something is wrong there. Ok, I will crosscheck tomorrow again when I am at my docking station. Thank you for your diligence :-)

I crosschecked multiple versions and 4.4.46-11 can reproduce the problem as previously stated but the hypothesis and summary were wrong.

Update to

ACCEPT H1.3 4.4.36-8.1 -> 4.4.49-16

If you like you can give me more versions to bisect or again a version with patches disabled as vanilla works but in this cases probably patches in the range 4.4.36-4.4.49 disabled I assume

OK, thanks for confirmation.  I'm building again a test kernel disabling the i915 patches since 4.4.36 in the same repo, IBS home:tiwai:test:bnc1029634.
Give it a try later.

Scratch that kernel.  It seems that we have another regression in the recent 4.4.x stable updates and my test machine reboots at S3 resume.  Sigh...

I'll check the S3 regression at first, then will check this issue after that.

The another S3 regression is tracked in boo#1030698.

BTW, I got a Dell SKL machine and I could reproduce the problem locally, so it's easier for me now to debug :)

cool, so I shall just wait for your findings?

I managed to bisect and found the culprit patch.  Ironically, it's a fix for S3 resume with SKL MST (bsc#1015359).

The test kernel is being built with just a revert of this in IBS home:tiwai:test:bnc1029634.  The repo may contain a leftover package from the previous build.  The latest one should have git 0b839dbaf.

(In reply to Takashi Iwai from comment #22)
> I managed to bisect and found the culprit patch.  Ironically, it's a fix for
> S3 resume with SKL MST (bsc#1015359).

funny ;-)

linux-4.4.56-2.1.g0b839db-default PASSED -> no crash

(crosschecked that the crash still appears with kernel-default-4.4.49)

so I confirm your revert of the patch fixes the problem for me.

Now it's getting more interesting.  I could reproduce the same kernel panic on the 4.10-rc2 kernel I had.  And the bug doesn't appear on 4.10.6.  So there was a fix somewhere between them.  A good hope.

Hrm, the problem looks deeper than I thought.  Now the hang is reproduced even with 4.11-rc3 kernel.  No idea why it worked sometimes.

But it indicates that the issue is unresolved in upstream code, so it's time to report this to upstream.

Adding Patrik to Cc.  Let me know if you have any hints.

Hi! Someone here CCd me seeing if I could provide any tips and I'd be happy to try.

So unfortunately I've had no luck reproducing this on my Skylake machines using plain MST displays, but I don't have the same Dell machine that you guys are mentioning here (I'm going to see if we possibly have one at the office, but no guarantees). Do you think I could get a little more information from you guys:

A full dmesg from when you reproduced the issue, along with adding "drm.debug=0x6" to your kernel commandline to get the kernel to give me a bit more debugging info. If you guys have any trouble getting this let me know, I've got some tricks up my sleeves to get debugging logs out of machines.

As well, the full output from running dmidecode? This doesn't smell too badly of bad firmware, but since Dell's got some of the worst firmware I've ever run into I'd like to just make sure :).

As an extra, if anyone could actually get me access to one of these machines having this issue over ssh, that would be extremely helpful.

Thanks for joining!

Below is the kernel output (taken from journalctl) with drm.debug=0x06.  
Also the dmidecode output is attached, too.
Unfortunately, the logs after running xrandr leading to a crash couldn't be recorded, so it's up to the state just before executing xrandr, I guess.

Currently I have no idea what went wrong.  When the crash happens, it stops the whole, and even jamming the Ethernet.  A similar symptom (Ethernet segment jammed) was found when SKL chip went crazy with intel_idle or intel_pstate did something wrong with C-state in the past, so it might be some SKL-specific hardware problem.

Created attachment 719148 [details]
journalctl -k output of the crasshed session with drm.debug=0x06 option

Created attachment 719149 [details]
dmidecode output on Dell Latitiude E7270

The remote access to the machine is a bit difficult for now since it's in the company's intranet, sorry.  And I think it doesn't help much because of the nature of the problem (S3 and the hard crash).  I can try any patch, though.

It seems that splitting the resume procedure in intel_dp_mst_resume() to apply before and after intel_display_resume() makes the crash away.  Not sure why it fixes yet, though :)

A tentative fix patch is below.

Created attachment 719161 [details]
A tentative fix patch for 4.11-rc4

After further checking, it seems sufficient just to skip the call of intel_dp_check_mst_status() in intel_dp_mst_resume().
The revised patch is below.

However, unfortunately, this doesn't fix the crash with 4.4.x kernel with the S3 fix backport, by some reason.  It works for 4.11-rc4.  Still investigating...

Created attachment 719189 [details]
A test fix patch for 4.11-rc4 (revised)

(In reply to Takashi Iwai from comment #34)
> However, unfortunately, this doesn't fix the crash with 4.4.x kernel with
> the S3 fix backport, by some reason.  It works for 4.11-rc4.  Still
> investigating...

It turned out that I overlooked the stray update module.  The fix itself works with 4.4.x backport, too, but the second patch seems not triggering the intel_dp_check_mst_status(), so the first patch would be needed for 4.4.x.

Oliver, could you check whether the kernel in IBS home:tiwai:test:bnc1029634-2 repo works?

(In reply to Takashi Iwai from comment #36)
> Oliver, could you check whether the kernel in IBS
> home:tiwai:test:bnc1029634-2 repo works?

problem reproduced with 4.4.56-2.g0b839db-default

Hrm, strange.  Just to be sure, please test with openSUSE-42.2 KOTD that has already the candidate fix.

I think I checked the wrong kernel version. home:tiwai:test:bnc1029634-2 has 4.4.56-1.g9036908-default

checked again:

* boot to system
* log into LXDE
* change to tty1
* log in as root
* systemctl suspend
* disconnect DP1
* wakeup
* reconnect DP1
* wait for kernel panic

4.4.56-1.g9036908-default works, PASSED

Good to hear!  The fix was already merged in the main branch, so we can close this one now.

Created attachment 721808 [details]
distortions on screen

while 4.4.56-1.g9036908-default worked, vmlinuz-4.4.57-18.3-default did *not* work. vmlinuz-4.4.57-18.3-vanilla works though. So maybe another patch that came in after your fixes broke it again?

See screenshot for the error (hard to read, sorry).

see comment 41

Conducted experiment as described in comment 39 again with
* 4.4.49-16-vanilla: PASSED
* 4.4.57-18.3-vanilla: PASSED
* 4.4.57-18.3-default: FAILED
* 4.4.56-1.g9036908-default: PASSED
* 4.4.62-1.g5191057-default (KOTD): PASSED

--> Fix is not in yet in currently. KOTD confirmed it's ok but it is not in the product yet. Where can I see a SR and the status of it?

OK, good to hear that KOTD works at least.
I'm going to send a SR, but maybe tomorrow, after all fixes get merged into SP2 and synced with openSUSE-42.2 branch in today.

This is an autogenerated message for OBS integration:
This bug (1029634) was mentioned in
https://build.opensuse.org/request/show/489960 42.2 / kernel-source

Unfortunately I have to report that the *initial* problem is not solved with 4.4.62-1.g5191057-default but the one reproduced with the steps as described in comment 39 *is* solved. So I guess there is still some problem persisting. I will need to try the original "steps to reproduce" but it will take me some time to find a time slot where I don't actively need my work notebook. Investigation on the side of anyone else would be highly appreciated - kernel bug investigations using the work environment is rather expensive ;-)

As the originally mentioned problem persists I am reconducting experiments with the steps to reproduce as described in comment 1.

Additionally, to simplify `pkill -f slock` in before initial suspend

4.4.36-8-default: PASSED (was INCOMPLETE with hang during initial request to suspend, tried again)
4.4.49-16-vanilla: PASSED
4.4.49-16-default: FAILED
4.4.57-18.3-vanilla: PASSED (but then panic'ed during reboot with what looks like the same symptoms)
4.4.62-5.g2c1de65-vanilla: PASSED (again panic'ed during reboot)
4.4.62-5.g2c1de65-default: PASSED

the last one was unexpected. I guessed the problem would be easily reproducible. I will reconduct the extended experiment in my normal setup with autostarting all other applications which is way more annoying and takes more time but maybe the have an influence?
-> Reconducted wit 4.4.62-5.g2c1de65-default with all applications enabled. Problem seems to be gone for good.

I expect it to be done with https://build.opensuse.org/request/show/489960 but want to verify with a new kernel version release in the update channel.

openSUSE-SU-2017:1140-1: An update that solves 10 vulnerabilities and has 49 fixes is now available.

Category: security (important)
Bug References: 1010032,1012452,1012829,1013887,1014136,1017461,1019614,1021424,1021762,1022340,1023287,1027153,1027512,1027616,1027974,1028027,1028217,1028415,1028883,1029514,1029634,1030070,1030118,1030213,1031003,1031052,1031147,1031200,1031206,1031208,1031440,1031512,1031555,1031579,1031662,1031717,1031831,1032006,1032141,1032345,1032400,1032581,1032673,1032681,1032803,1033117,1033281,1033336,1033340,1033885,1034048,1034419,1034671,1034902,970083,986362,986365,988065,993832
CVE References: CVE-2016-4997,CVE-2016-4998,CVE-2017-2671,CVE-2017-7187,CVE-2017-7261,CVE-2017-7294,CVE-2017-7308,CVE-2017-7374,CVE-2017-7616,CVE-2017-7618
Sources used:
openSUSE Leap 42.2 (src):    kernel-debug-4.4.62-18.6.1, kernel-default-4.4.62-18.6.1, kernel-docs-4.4.62-18.6.2, kernel-obs-build-4.4.62-18.6.1, kernel-obs-qa-4.4.62-18.6.1, kernel-source-4.4.62-18.6.1, kernel-syms-4.4.62-18.6.1, kernel-vanilla-4.4.62-18.6.1

SUSE-SU-2017:1183-1: An update that solves 16 vulnerabilities and has 69 fixes is now available.

Category: security (important)
Bug References: 1007959,1007962,1008842,1010032,1011913,1012382,1012910,1013994,1014136,1015609,1017461,1017641,1018263,1018419,1019163,1019614,1019618,1020048,1021762,1022340,1022785,1023866,1024015,1025683,1026024,1026405,1026462,1026505,1026509,1026692,1026722,1027054,1027066,1027153,1027179,1027189,1027190,1027195,1027273,1027616,1028017,1028027,1028041,1028158,1028217,1028325,1028415,1028819,1028895,1029220,1029514,1029634,1029986,1030118,1030213,1031003,1031052,1031200,1031206,1031208,1031440,1031481,1031579,1031660,1031662,1031717,1031831,1032006,1032673,1032681,897662,951844,968697,969755,970083,977572,977860,978056,980892,981634,982783,987899,988281,991173,998106
CVE References: CVE-2016-10200,CVE-2016-2117,CVE-2016-9191,CVE-2017-2596,CVE-2017-2671,CVE-2017-6074,CVE-2017-6214,CVE-2017-6345,CVE-2017-6346,CVE-2017-6347,CVE-2017-6353,CVE-2017-7187,CVE-2017-7261,CVE-2017-7294,CVE-2017-7308,CVE-2017-7374
Sources used:
SUSE Linux Enterprise Workstation Extension 12-SP2 (src):    kernel-default-4.4.59-92.17.3
SUSE Linux Enterprise Software Development Kit 12-SP2 (src):    kernel-docs-4.4.59-92.17.8, kernel-obs-build-4.4.59-92.17.3
SUSE Linux Enterprise Server for Raspberry Pi 12-SP2 (src):    kernel-default-4.4.59-92.17.3, kernel-source-4.4.59-92.17.2, kernel-syms-4.4.59-92.17.2
SUSE Linux Enterprise Server 12-SP2 (src):    kernel-default-4.4.59-92.17.3, kernel-source-4.4.59-92.17.2, kernel-syms-4.4.59-92.17.2
SUSE Linux Enterprise Live Patching 12 (src):    kgraft-patch-SLE12-SP2_Update_7-1-2.3
SUSE Linux Enterprise High Availability 12-SP2 (src):    kernel-default-4.4.59-92.17.3
SUSE Linux Enterprise Desktop 12-SP2 (src):    kernel-default-4.4.59-92.17.3, kernel-source-4.4.59-92.17.2, kernel-syms-4.4.59-92.17.2
OpenStack Cloud Magnum Orchestration 7 (src):    kernel-default-4.4.59-92.17.3

Now verified by running kernel-default from openSUSE:Leap:42.2:Update and reproducing the steps as described in comment 1.

@tiwai thank you very much

SUSE-SU-2017:1990-1: An update that solves 43 vulnerabilities and has 282 fixes is now available.

Category: security (important)
Bug References: 1000092,1003077,1003581,1004003,1007729,1007959,1007962,1008842,1009674,1009718,1010032,1010612,1010690,1011044,1011176,1011913,1012060,1012382,1012422,1012452,1012829,1012910,1012985,1013001,1013561,1013792,1013887,1013994,1014120,1014136,1015342,1015367,1015452,1015609,1016403,1017164,1017170,1017410,1017461,1017641,1018100,1018263,1018358,1018385,1018419,1018446,1018813,1018885,1018913,1019061,1019148,1019163,1019168,1019260,1019351,1019594,1019614,1019618,1019630,1019631,1019784,1019851,1020048,1020214,1020412,1020488,1020602,1020685,1020817,1020945,1020975,1021082,1021248,1021251,1021258,1021260,1021294,1021424,1021455,1021474,1021762,1022181,1022266,1022304,1022340,1022429,1022476,1022547,1022559,1022595,1022785,1022971,1023101,1023175,1023287,1023762,1023866,1023884,1023888,1024015,1024081,1024234,1024508,1024938,1025039,1025235,1025461,1025683,1026024,1026405,1026462,1026505,1026509,1026570,1026692,1026722,1027054,1027066,1027101,1027153,1027179,1027189,1027190,1027195,1027273,1027512,1027565,1027616,1027974,1028017,1028027,1028041,1028158,1028217,1028310,1028325,1028340,1028372,1028415,1028819,1028883,1028895,1029220,1029514,1029607,1029634,1029986,1030057,1030070,1030118,1030213,1030573,1031003,1031040,1031052,1031142,1031147,1031200,1031206,1031208,1031440,1031470,1031500,1031512,1031555,1031579,1031662,1031717,1031796,1031831,1032006,1032141,1032339,1032345,1032400,1032581,1032673,1032681,1032803,1033117,1033281,1033287,1033336,1033340,1033885,1034048,1034419,1034635,1034670,1034671,1034762,1034902,1034995,1035024,1035866,1035887,1035920,1035922,1036214,1036638,1036752,1036763,1037177,1037186,1037384,1037483,1037669,1037840,1037871,1037969,1038033,1038043,1038085,1038142,1038143,1038297,1038458,1038544,1038842,1038843,1038846,1038847,1038848,1038879,1038981,1038982,1039348,1039354,1039700,1039864,1039882,1039883,1039885,1039900,1040069,1040125,1040182,1040279,1040351,1040364,1040395,1040425,1040463,1040567,1040609,1040855,1040929,1040941,1041087,1041160,1041168,1041242,1041431,1041810,1042200,1042286,1042356,1042421,1042517,1042535,1042536,1042863,1042886,1043014,1043231,1043236,1043347,1043371,1043467,1043488,1043598,1043912,1043935,1043990,1044015,1044082,1044120,1044125,1044532,1044767,1044772,1044854,1044880,1044912,1045154,1045235,1045286,1045307,1045340,1045467,1045568,1046105,1046434,1046589,799133,863764,870618,922871,951844,966170,966172,966191,966321,966339,968697,969479,969755,970083,971975,982783,985561,986362,986365,987192,987576,988065,989056,989311,990058,990682,991273,993832,995542,995968,998106
CVE References: CVE-2016-10200,CVE-2016-2117,CVE-2016-4997,CVE-2016-4998,CVE-2016-7117,CVE-2016-9191,CVE-2017-1000364,CVE-2017-1000365,CVE-2017-1000380,CVE-2017-2583,CVE-2017-2584,CVE-2017-2596,CVE-2017-2636,CVE-2017-2671,CVE-2017-5551,CVE-2017-5576,CVE-2017-5577,CVE-2017-5897,CVE-2017-5970,CVE-2017-5986,CVE-2017-6074,CVE-2017-6214,CVE-2017-6345,CVE-2017-6346,CVE-2017-6347,CVE-2017-6353,CVE-2017-7184,CVE-2017-7187,CVE-2017-7261,CVE-2017-7294,CVE-2017-7308,CVE-2017-7346,CVE-2017-7374,CVE-2017-7487,CVE-2017-7616,CVE-2017-7618,CVE-2017-8890,CVE-2017-9074,CVE-2017-9075,CVE-2017-9076,CVE-2017-9077,CVE-2017-9150,CVE-2017-9242
Sources used:
SUSE Linux Enterprise Real Time Extension 12-SP2 (src):    kernel-rt-4.4.74-7.10.1, kernel-rt_debug-4.4.74-7.10.1, kernel-source-rt-4.4.74-7.10.1, kernel-syms-rt-4.4.74-7.10.1