Bug 1101711 - Can not install Leap 15.0 due system freeze
Can not install Leap 15.0 due system freeze
Status: NEW
Classification: openSUSE
Product: openSUSE Distribution
Classification: openSUSE
Component: Installation
Leap 15.0
x86-64 Other
: P5 - None : Critical (vote)
: ---
Assigned To: openSUSE Kernel Bugs
Jiri Srain
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-07-18 16:39 UTC by Dr. Werner Fink
Modified: 2020-10-05 15:59 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
output of hwinfo (1.08 MB, text/plain)
2018-07-18 16:39 UTC, Dr. Werner Fink
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dr. Werner Fink 2018-07-18 16:39:18 UTC
Created attachment 777337 [details]
output of hwinfo

the system does freeze if I try to boot withe default kernel as well as with secure boot options. In last case the freeze happens at first screen of yast where I do not have mouse nore keyboard.

This system is a Tuxedo (TUXEDO N15_17RD,RD2) and I'm using fo Leap 42.3 

resume=/dev/nvme0n1p1 splash=silent i915.preliminary_hw_support=1 rcutree.rcu_idle_gp_delay=1 plymouth.enable=0 systemd.show_status=true acpi_os_name=Linux acpi_backlight=vendor "acpi_osi=!Windows 2012" usbcore.autosuspend=-1 acpi=force acpi_sleep=s3_bios libata.force=5.00:noncq elevator=bfq video=DP-0:1920x1080@60

I've tried to add some of the options above

 i915.preliminary_hw_support=1
 rcutree.rcu_idle_gp_delay=1
 acpi_os_name=Linux
 "acpi_osi=!Windows 2012"
 usbcore.autosuspend=-1
 acpi=force
 acpi_sleep=s3_bios
 libata.force=5.00:noncq
 video=DP-0:1920x1080@60

but this had not worked at all.
Comment 1 Dr. Werner Fink 2018-07-18 16:40:18 UTC
could be belong to Kernel instead of Installation but it happens at installation
Comment 3 Steffen Winterfeldt 2018-07-19 10:03:07 UTC
I've seen quite a number of reports where leap 15 freezes trying to load the
nouveau driver. Does 'nomodeset' help?

I'll move the bug to kernel.
Comment 4 Takashi Iwai 2018-07-19 10:11:31 UTC
Yes, nouveau module on Leap 15.0 kernel is buggy, especially for Intel + Nouveau hybrid graphics.  It's already mentioned in the release notes.

The update kernel (maybe not yet released) already contains the fix.  So please install / upgrade with nomodeset option, and remove it after updating to the latest kernel in OBS Kernel:openSUSE-15.0 repo.
Comment 5 Dr. Werner Fink 2018-07-20 09:50:29 UTC
(In reply to Takashi Iwai from comment #4)
> Yes, nouveau module on Leap 15.0 kernel is buggy, especially for Intel +
> Nouveau hybrid graphics.  It's already mentioned in the release notes.
> 
> The update kernel (maybe not yet released) already contains the fix.  So
> please install / upgrade with nomodeset option, and remove it after updating
> to the latest kernel in OBS Kernel:openSUSE-15.0 repo.

Indeed nomodeset helps a lot yes.  Nevertheless without latest haveged from Factory booting is slow at switch root.  Btw: it is *not* slow with the older kernel from Leap 42.3 ... My guess is that newer kernel do cause lesser entropy then older kernels.  Also I had to reset the passwords for root and the users in rescue mode as I run into the problem that the encrypted password for root had not worked in emergency mode (md5???).  Also I run into the problem that the r8169 does not work and never had worked with my book and without plugged ethernet it is not possible to install r8168 from packman.  Last but not least I lost the louder/lesser keys (Fn+F6 and Fn+F5) whereas backlight for screen and keyboard do work.

I do not use nouveau but nvidia and this works as usual with xrand in Xsetup to switch from Intel to Nvidia.
Comment 6 Takashi Iwai 2018-07-23 10:35:55 UTC
(In reply to Dr. Werner Fink from comment #5)
> Last but not least I lost the louder/lesser keys (Fn+F6
> and Fn+F5) whereas backlight for screen and keyboard do work.

Please check whether it's a kernel problem or not.  e.g. run evtest on Linux console (VT1), and see whether the audio key emits an event.
If the key event is generated, it's an issue in the desktop.  If no key event is generated on any input devices, it's a kernel regression.
Comment 7 Dr. Werner Fink 2018-07-24 16:08:34 UTC
(In reply to Takashi Iwai from comment #6)
> (In reply to Dr. Werner Fink from comment #5)
> > Last but not least I lost the louder/lesser keys (Fn+F6
> > and Fn+F5) whereas backlight for screen and keyboard do work.
> 
> Please check whether it's a kernel problem or not.  e.g. run evtest on Linux
> console (VT1), and see whether the audio key emits an event.
> If the key event is generated, it's an issue in the desktop.  If no key
> event is generated on any input devices, it's a kernel regression.

Seems to be code 114 and 115

Testing ... (interrupt to exit)
Event: time 1532448315.715973, type 4 (EV_MSC), code 4 (MSC_SCAN), value 1c
Event: time 1532448315.715973, type 1 (EV_KEY), code 28 (KEY_ENTER), value 0
Event: time 1532448315.715973, -------------- SYN_REPORT ------------
Event: time 1532448321.126268, type 4 (EV_MSC), code 4 (MSC_SCAN), value ae
Event: time 1532448321.126268, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 1
Event: time 1532448321.126268, -------------- SYN_REPORT ------------
Event: time 1532448321.168896, type 4 (EV_MSC), code 4 (MSC_SCAN), value ae
Event: time 1532448321.168896, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 0
Event: time 1532448321.168896, -------------- SYN_REPORT ------------
Event: time 1532448322.396439, type 4 (EV_MSC), code 4 (MSC_SCAN), value b0
Event: time 1532448322.396439, type 1 (EV_KEY), code 115 (KEY_VOLUMEUP), value 1
Event: time 1532448322.396439, -------------- SYN_REPORT ------------
Event: time 1532448322.448322, type 4 (EV_MSC), code 4 (MSC_SCAN), value b0
Event: time 1532448322.448322, type 1 (EV_KEY), code 115 (KEY_VOLUMEUP), value 0
Event: time 1532448322.448322, -------------- SYN_REPORT ------------
Event: time 1532448324.093792, type 4 (EV_MSC), code 4 (MSC_SCAN), value 3e
Event: time 1532448324.093792, type 1 (EV_KEY), code 62 (KEY_F4), value 1
Event: time 1532448324.093792, -------------- SYN_REPORT ------------
Event: time 1532448324.169310, type 4 (EV_MSC), code 4 (MSC_SCAN), value 3e
Event: time 1532448324.169310, type 1 (EV_KEY), code 62 (KEY_F4), value 0
Event: time 1532448324.169310, -------------- SYN_REPORT ------------
Event: time 1532448324.748597, type 4 (EV_MSC), code 4 (MSC_SCAN), value 3f
Event: time 1532448324.748597, type 1 (EV_KEY), code 63 (KEY_F5), value 1
Event: time 1532448324.748597, -------------- SYN_REPORT ------------
Event: time 1532448324.813787, type 4 (EV_MSC), code 4 (MSC_SCAN), value 3f
Event: time 1532448324.813787, type 1 (EV_KEY), code 63 (KEY_F5), value 0
Comment 8 Takashi Iwai 2018-07-24 16:12:12 UTC
(In reply to Dr. Werner Fink from comment #7)
> (In reply to Takashi Iwai from comment #6)
> > (In reply to Dr. Werner Fink from comment #5)
> > > Last but not least I lost the louder/lesser keys (Fn+F6
> > > and Fn+F5) whereas backlight for screen and keyboard do work.
> > 
> > Please check whether it's a kernel problem or not.  e.g. run evtest on Linux
> > console (VT1), and see whether the audio key emits an event.
> > If the key event is generated, it's an issue in the desktop.  If no key
> > event is generated on any input devices, it's a kernel regression.
> 
> Seems to be code 114 and 115

Then please report this specific one to a different bug report for the desktop.
It's neither kernel nor installer problem, per se.
Comment 9 Dr. Werner Fink 2018-07-24 17:48:27 UTC
Hmm ... X seems to know

KeyPress event, serial 36, synthetic NO, window 0x4e00001,
    root 0x4dc, subw 0x4e00002, time 55657086, (53,59), root:(1724,181),
    state 0x10, keycode 122 (keysym 0x1008ff11, XF86AudioLowerVolume), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x4e00001,
    root 0x4dc, subw 0x4e00002, time 55657163, (53,59), root:(1724,181),
    state 0x10, keycode 122 (keysym 0x1008ff11, XF86AudioLowerVolume), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 36, synthetic NO, window 0x4e00001,
    root 0x4dc, subw 0x4e00002, time 55658659, (53,59), root:(1724,181),
    state 0x10, keycode 123 (keysym 0x1008ff13, XF86AudioRaiseVolume), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x4e00001,
    root 0x4dc, subw 0x4e00002, time 55658705, (53,59), root:(1724,181),
    state 0x10, keycode 123 (keysym 0x1008ff13, XF86AudioRaiseVolume), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False
Comment 10 Dr. Werner Fink 2018-07-24 17:54:22 UTC
The working function keys  (Fn+FX) are not seen by evtest nor xev therefore I guess the kernel does control e.g. the  backlight in direct way?
Comment 11 Takashi Iwai 2018-07-24 18:30:16 UTC
(In reply to Dr. Werner Fink from comment #9)
> Hmm ... X seems to know

It's desktop-envrionment specific issue, not a lowlevel system like X or kernel.
Usually some desktop daemon catches such events and handles properly.
In the case of XFCE, e.g. it's xfce4-panel-plugin-pulse or such.
Comment 12 Takashi Iwai 2018-07-24 18:32:15 UTC
(In reply to Dr. Werner Fink from comment #10)
> The working function keys  (Fn+FX) are not seen by evtest nor xev therefore
> I guess the kernel does control e.g. the  backlight in direct way?

It's possible that kernel handles via ACPI backlight event, but it's pretty rare nowadays.  Are you sure that you've tested all event devices via evtest?
(xev is often difficult as the user daemon may take the even already away.)

But, since the backlight control seems working on your system, it's not that important...