http://bugzilla.opensuse.org/show_bug.cgi?id=1188954 http://bugzilla.opensuse.org/show_bug.cgi?id=1188954#c13 Felix Miata <mrmazda@earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|black screen on initial X |black screen on initial per |open on Kaveri Radeon R7, |boot X open |/dev/dri/card0: No such |"/dev/dri/card0: No such |file or directory with |file or directory" |radeon.cik_support=0 | |amdgpu.cik_support=1 | --- Comment #13 from Felix Miata <mrmazda@earthlink.net> --- (In reply to Stefan Dirsch from comment #7)
Ok. If it fails only during initial X startup, this looks like a timing issue, i.e. kernel module is not being initialized in time before X gets started.
As previously noted, this has turned out *not* to be limited to AMD. After reproducing this on a second Kaby Lake (gb250) I did some experimenting. This is typical content of my grub.cfg linu lines where this reproduces: mitigations=auto consoleblank=0 video=1440x900@60 5 Changing it on gb250 to: mitigations=auto video=1440x900@60 5 *sometimes* avoids "(EE) open /dev/dri/card0: No such file or directory", resulting in expected startup. Other times, the screen is black as noted in comment 0, while other times, focus returns to the login prompt on tty1. I switched back to the comment #12 Kaby Lake (host ab250), tried the same things, and cannot get X to start on first try no matter what. There's also this: # systemd-analyze Startup finished in 17.795s (firmware) + 5.243s (loader) + 1.458s (kernel) + 1.406s (initrd) + 2.985s (userspace) = 28.889s graphical.target reached after 2.961s in userspace It seems consoleblank=0 on kernel command line *can* somehow affect timing of the KMS kernel module loading, whether it be i915, amdgpu or radeon, but the real or main problem must be that each KMS module simply is not getting loaded soon enough. Is there anything that can advance KMS module loading? -- You are receiving this mail because: You are on the CC list for the bug.