|
Bugzilla – Full Text Bug Listing |
| Summary: | Boot hangs during kernel initialization due to hybrid graphics on 7700HQ | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Mikhail Krutov <nekoxmachina> |
| Component: | Installation | Assignee: | openSUSE Kernel Bugs <kernel-bugs> |
| Status: | REOPENED --- | QA Contact: | Jiri Srain <jsrain> |
| Severity: | Critical | ||
| Priority: | P5 - None | CC: | bpetkov, jreidinger, nekoxmachina, tiwai |
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Mikhail Krutov
2017-12-27 09:04:03 UTC
For me it looks like kernel issue with ACPI. Please kernel guys look and reassign if needed. Does the nouveau driver still work properly with acpi_osi boot option? Or it just disables that? In other words, is acpi_osi option equivalent with nouveau.modeset=0 in your case? Takashi Iwai, yes, with nouveau.modeset=0 it boots fine. I'm not using nouveau as my day-to-day driver, so tested that on install media only, and install media has booted normally using that option. So it's a breakage in nouveau. Could you also try to install the old kernel such as Leap 42.2/42.3, and test without any extra boot options? I'd like to know whether it's a regression. Kernel from 42.3 doesn't boot on my machine, regardless of options. Hm, Kabylake should be bootable with 42.3 although the graphics isn't supported as is. Did you try to boot with nomodeset option? Yes, i did. On TW installation any option combination resulted in unreadable bootlog (if i press esc during bootsplash, i see garbage instead of text). There was some error which i couldn't read due to this, I've waited around 5 minutes and it didn't boot. Leap livecd on other hand boots fine (I've used nightly kde livecd with leap backend) - in that case I've had to supply acpi_osi options. Without acpi_osi with nouveau.modeset it froze during boot. Looks forgotten. Feel free to reopen if still of interest. . Surely not forgotten on my side. I can retest on current OpenSuSE leap closer to the weekend. However, I'm having 2 options (acpi_osi) from first message set on this machine for more then 2 years and with those 2 options it boots and works fine. Not sure of your standard issue workflow, please keep in it a desired state; I'll reopen or post something on Sunday/Saturday if it still is happening. (In reply to Mikhail Krutov from comment #10) > Surely not forgotten on my side. I can retest on current OpenSuSE leap > closer to the weekend. Ok, please retest with leap 15.1 and make sure to update to the latest kernel. You can use the daily snapshots here, they should be pretty stable: https://kernel.suse.com/packages/openSUSE-15.1 and upload full dmesg. Thx. (clear stale NEEDINFO). I've had a chance to test this machine on modern OpenSuSE live images. 1) 15.1 live from september 2019 does behave, as described in first comment: no acpi_osi parameter -> hard lock during boot, no response from machine to anything. with acpi_osi=! acpi_osi="Windows 2010" it boots properly. 2) 15.2 live from last few days does behave differently: it boots, tries to launch X for display manager, which fails (displays tty for a few seconds), it tries to launch X yet again, fails again, then finally shuts down with no chance at grabbing logs or anything on my side. I'll take a look at more recent kernels on top of 15.1 install a bit later on. In the meantime, please do tell if I should open another issue for 15.2 (as far as I understand, its currently in alpha stage); and if so - which information should I provide in such a bugreport (and how as well, since machine is shutting down, taking all the logs with it). Thanks! (In reply to Mikhail Krutov from comment #12) > In the meantime, please do tell if I should open another issue for 15.2 (as > far as I understand, its currently in alpha stage); and if so - which > information should I provide in such a bugreport (and how as well, since > machine is shutting down, taking all the logs with it). Thanks! You can try logging to another machine using netconsole: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/netconsole.txt it might work. Unfortunately, collecting debugging output from laptops has always been a PITA because the vendors don't think that having serial out is useful. :-\ HTH. |