[opensuse-factory] Don't upgrade to a 5.0.x Kernel with a Dell Precision 5530
Hi list, yesterday I applied the update to the most recent kernel and unfortunately now my laptop will no longer boot into a graphical session. So if you have a Dell Precision 5530, don't reboot into the 5.0.1 or 5.0.2 kernel. If you did and it runs well, please tell me how you have configured your system, as I currently cannot even get the Tumbleweed rescue disk to boot (exactly the same symptoms: blank screen). Cheers, Dan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 3/18/19 2:53 PM, Dan Cermak wrote:
Hi list,
yesterday I applied the update to the most recent kernel and unfortunately now my laptop will no longer boot into a graphical session. So if you have a Dell Precision 5530, don't reboot into the 5.0.1 or 5.0.2 kernel. If you did and it runs well, please tell me how you have configured your system, as I currently cannot even get the Tumbleweed rescue disk to boot (exactly the same symptoms: blank screen).
Cheers,
Dan
Do you have the NVIDIA proprietary driver installed via the openSUSE DKMS package ? if so that could be it where it failed to rebuild. It can be fixed by rebooting in runlevel 3 (single user) and installing the nvidia-gfxG05-kmp-default module -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Nope, I have blacklisted everything from Nvidia & Nouveau, so only the Intel driver should be running. Also, I tried the Tumbleweed rescue disk: that one will start booting, but at some point the laptop screen just turns off and that's it.
Michael Pujos <pujos.michael@gmail.com> 03/18/19 3:03 PM >>> On 3/18/19 2:53 PM, Dan Cermak wrote: Hi list,
yesterday I applied the update to the most recent kernel and unfortunately now my laptop will no longer boot into a graphical session. So if you have a Dell Precision 5530, don't reboot into the 5.0.1 or 5.0.2 kernel. If you did and it runs well, please tell me how you have configured your system, as I currently cannot even get the Tumbleweed rescue disk to boot (exactly the same symptoms: blank screen).
Cheers,
Dan
Do you have the NVIDIA proprietary driver installed via the openSUSE DKMS package ? if so that could be it where it failed to rebuild. It can be fixed by rebooting in runlevel 3 (single user) and installing the nvidia-gfxG05-kmp-default module -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 3/18/19 3:11 PM, Dan Cermak wrote:
Nope, I have blacklisted everything from Nvidia & Nouveau, so only the Intel driver should be running.
Also, I tried the Tumbleweed rescue disk: that one will start booting, but at some point the laptop screen just turns off and that's it.
Can you boot into single user mode (in GRUB edit the kernel line and append " 3" without the quotes at the end), login, and post your /var/log/Xorg.log.0 ? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 3/18/19 9:11 AM, Dan Cermak wrote:
Nope, I have blacklisted everything from Nvidia & Nouveau, so only the Intel driver should be running.
Also, I tried the Tumbleweed rescue disk: that one will start booting, but at some point the laptop screen just turns off and that's it.
If you force the kernel to not load any graphics accelerator, does it boot? When at the GRUB line, select the Advanced option and the 5.0.1 kernel. Then press E to edit the line. Find the line that starts with "linuxefi" or "linux", press the END key to get to the end of the line, and append " nomodeset". Then press the F10 key to boot. Do you get a desktop this way? If so, it will have no acceleration and limited resolution, but we will have isolated the graphics driver as the problem. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Larry, thanks for the tip, appending nomodeset did indeed work. Now I have a tty again! X is currently not starting, due to this error: [ 473.385] intel: waited 2020 ms for i915.ko driver to load which I suspect is due to the nomodeset parameter. Is there somewhere an up to date guide for building a custom kernel? I have the linux kernel sources checked out and could try to bisect the issue. Cheers, Dan
Larry Finger <Larry.Finger@lwfinger.net> 03/18/19 3:25 PM >>> On 3/18/19 9:11 AM, Dan Cermak wrote: Nope, I have blacklisted everything from Nvidia & Nouveau, so only the Intel driver should be running.
Also, I tried the Tumbleweed rescue disk: that one will start booting, but at some point the laptop screen just turns off and that's it.
If you force the kernel to not load any graphics accelerator, does it boot? When at the GRUB line, select the Advanced option and the 5.0.1 kernel. Then press E to edit the line. Find the line that starts with "linuxefi" or "linux", press the END key to get to the end of the line, and append " nomodeset". Then press the F10 key to boot. Do you get a desktop this way? If so, it will have no acceleration and limited resolution, but we will have isolated the graphics driver as the problem. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, On 3/18/19 4:55 PM, Dan Cermak wrote:
Hi Larry,
thanks for the tip, appending nomodeset did indeed work. Now I have a tty again!
X is currently not starting, due to this error: [ 473.385] intel: waited 2020 ms for i915.ko driver to load
which I suspect is due to the nomodeset parameter.
Is there somewhere an up to date guide for building a custom kernel? I have the linux kernel sources checked out and could try to bisect the issue.
Dan, I have the same problem. I managed to boot the previous kernel (using grub) and did not need to rebuild it. Snapshot rollback was not needed either.
Cheers,
Dan
Cheers, ferenc
On 3/18/19 9:55 AM, Dan Cermak wrote:
Hi Larry,
thanks for the tip, appending nomodeset did indeed work. Now I have a tty again!
X is currently not starting, due to this error: [ 473.385] intel: waited 2020 ms for i915.ko driver to load
which I suspect is due to the nomodeset parameter.
Is there somewhere an up to date guide for building a custom kernel? I have the linux kernel sources checked out and could try to bisect the issue.
It is quite simple. Run the following steps from your kernel source directory: cp /boot/config-5.0.1-1-default .config make -j9 sudo make modules_install install Then reboot into the new kernel. The latest kernel is now at 5.1-rc1 and there is a possibility that the problem is fixed. In the "make" step, you may need to answer some questions about the configuration. Just use the default option. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Unfortunately, the issues is also present on 5.1-rc1. I am now building 4.20 and will try to bisect it from there.
Larry Finger <Larry.Finger@lwfinger.net> 03/18/19 4:14 PM >>> On 3/18/19 9:55 AM, Dan Cermak wrote: Hi Larry,
thanks for the tip, appending nomodeset did indeed work. Now I have a tty again!
X is currently not starting, due to this error: [ 473.385] intel: waited 2020 ms for i915.ko driver to load
which I suspect is due to the nomodeset parameter.
Is there somewhere an up to date guide for building a custom kernel? I have the linux kernel sources checked out and could try to bisect the issue.
It is quite simple. Run the following steps from your kernel source directory: cp /boot/config-5.0.1-1-default .config make -j9 sudo make modules_install install Then reboot into the new kernel. The latest kernel is now at 5.1-rc1 and there is a possibility that the problem is fixed. In the "make" step, you may need to answer some questions about the configuration. Just use the default option. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
I unfortunately wasn't able to finish the git bisect yesterday, but finished it just now: 7769db5883841b03de544a35a71ff528d4131c17 is the first bad commit Could someone who also got hit by the issue do the following: - checkout the kernel git repository - checkout the above commit - build the kernel as Larry described below - boot it and try out if it breaks - reboot and checkout HEAD~1 - rebuild the kernel, reboot and test whether it works Thanks in advance, Dan
Larry Finger <Larry.Finger@lwfinger.net> 03/18/19 4:14 PM >>> On 3/18/19 9:55 AM, Dan Cermak wrote: Hi Larry,
thanks for the tip, appending nomodeset did indeed work. Now I have a tty again!
X is currently not starting, due to this error: [ 473.385] intel: waited 2020 ms for i915.ko driver to load
which I suspect is due to the nomodeset parameter.
Is there somewhere an up to date guide for building a custom kernel? I have the linux kernel sources checked out and could try to bisect the issue.
It is quite simple. Run the following steps from your kernel source directory: cp /boot/config-5.0.1-1-default .config make -j9 sudo make modules_install install Then reboot into the new kernel. The latest kernel is now at 5.1-rc1 and there is a possibility that the problem is fixed. In the "make" step, you may need to answer some questions about the configuration. Just use the default option. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 19. 03. 19, 8:05, Dan Cermak wrote:
I unfortunately wasn't able to finish the git bisect yesterday, but finished it just now:
7769db5883841b03de544a35a71ff528d4131c17 is the first bad commit
So does it also work when you revert only the commit on the top of 5.0.x? Like: git checkout v5.0.2 git revert 7769db5883841b03de544a35a71ff528d4131c17 make et al thanks, -- js suse labs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jiri Slaby <jslaby@suse.cz> writes:
On 19. 03. 19, 8:05, Dan Cermak wrote:
I unfortunately wasn't able to finish the git bisect yesterday, but finished it just now:
7769db5883841b03de544a35a71ff528d4131c17 is the first bad commit
So does it also work when you revert only the commit on the top of 5.0.x? Like: git checkout v5.0.2 git revert 7769db5883841b03de544a35a71ff528d4131c17 make et al
That is unfortunately not possible, that commit was part of a huge number of patches that changed a lot in the i915 subsystem. I tried reverting it on top of v5.0 (there is no v5.0.2 tag upstream), but that failed with the following conflict (which I really don't feel even remotely competent enough to resolve): diff --cc drivers/gpu/drm/i915/intel_dp.c index 22a74608c6e4,e59edab5786c..000000000000 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@@ -1845,152 -1921,9 +1845,155 @@@ intel_dp_compute_link_config_wide(struc return false; } ++<<<<<<< HEAD +/* Optimize link config in order: max bpp, min lanes, min clock */ +static bool +intel_dp_compute_link_config_fast(struct intel_dp *intel_dp, + struct intel_crtc_state *pipe_config, + const struct link_config_limits *limits) +{ + struct drm_display_mode *adjusted_mode = &pipe_config->base.adjusted_mode; + int bpp, clock, lane_count; + int mode_rate, link_clock, link_avail; + + for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) { + mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock, + bpp); + + for (lane_count = limits->min_lane_count; + lane_count <= limits->max_lane_count; + lane_count <<= 1) { + for (clock = limits->min_clock; clock <= limits->max_clock; clock++) { + link_clock = intel_dp->common_rates[clock]; + link_avail = intel_dp_max_data_rate(link_clock, + lane_count); + + if (mode_rate <= link_avail) { + pipe_config->lane_count = lane_count; + pipe_config->pipe_bpp = bpp; + pipe_config->port_clock = link_clock; + + return true; + } + } + } + } + + return false; +} + +static int intel_dp_dsc_compute_bpp(struct intel_dp *intel_dp, u8 dsc_max_bpc) +{ + int i, num_bpc; + u8 dsc_bpc[3] = {0}; + + num_bpc = drm_dp_dsc_sink_supported_input_bpcs(intel_dp->dsc_dpcd, + dsc_bpc); + for (i = 0; i < num_bpc; i++) { + if (dsc_max_bpc >= dsc_bpc[i]) + return dsc_bpc[i] * 3; + } + + return 0; +} + +static bool intel_dp_dsc_compute_config(struct intel_dp *intel_dp, + struct intel_crtc_state *pipe_config, + struct drm_connector_state *conn_state, + struct link_config_limits *limits) +{ + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp); + struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev); + struct drm_display_mode *adjusted_mode = &pipe_config->base.adjusted_mode; + u8 dsc_max_bpc; + int pipe_bpp; + + if (!intel_dp_supports_dsc(intel_dp, pipe_config)) + return false; + + dsc_max_bpc = min_t(u8, DP_DSC_MAX_SUPPORTED_BPC, + conn_state->max_requested_bpc); + + pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp, dsc_max_bpc); + if (pipe_bpp < DP_DSC_MIN_SUPPORTED_BPC * 3) { + DRM_DEBUG_KMS("No DSC support for less than 8bpc\n"); + return false; + } + + /* + * For now enable DSC for max bpp, max link rate, max lane count. + * Optimize this later for the minimum possible link rate/lane count + * with DSC enabled for the requested mode. + */ + pipe_config->pipe_bpp = pipe_bpp; + pipe_config->port_clock = intel_dp->common_rates[limits->max_clock]; + pipe_config->lane_count = limits->max_lane_count; + + if (intel_dp_is_edp(intel_dp)) { + pipe_config->dsc_params.compressed_bpp = + min_t(u16, drm_edp_dsc_sink_output_bpp(intel_dp->dsc_dpcd) >> 4, + pipe_config->pipe_bpp); + pipe_config->dsc_params.slice_count = + drm_dp_dsc_sink_max_slice_count(intel_dp->dsc_dpcd, + true); + } else { + u16 dsc_max_output_bpp; + u8 dsc_dp_slice_count; + + dsc_max_output_bpp = + intel_dp_dsc_get_output_bpp(pipe_config->port_clock, + pipe_config->lane_count, + adjusted_mode->crtc_clock, + adjusted_mode->crtc_hdisplay); + dsc_dp_slice_count = + intel_dp_dsc_get_slice_count(intel_dp, + adjusted_mode->crtc_clock, + adjusted_mode->crtc_hdisplay); + if (!dsc_max_output_bpp || !dsc_dp_slice_count) { + DRM_DEBUG_KMS("Compressed BPP/Slice Count not supported\n"); + return false; + } + pipe_config->dsc_params.compressed_bpp = min_t(u16, + dsc_max_output_bpp >> 4, + pipe_config->pipe_bpp); + pipe_config->dsc_params.slice_count = dsc_dp_slice_count; + } + /* + * VDSC engine operates at 1 Pixel per clock, so if peak pixel rate + * is greater than the maximum Cdclock and if slice count is even + * then we need to use 2 VDSC instances. + */ + if (adjusted_mode->crtc_clock > dev_priv->max_cdclk_freq) { + if (pipe_config->dsc_params.slice_count > 1) { + pipe_config->dsc_params.dsc_split = true; + } else { + DRM_DEBUG_KMS("Cannot split stream to use 2 VDSC instances\n"); + return false; + } + } + if (intel_dp_compute_dsc_params(intel_dp, pipe_config) < 0) { + DRM_DEBUG_KMS("Cannot compute valid DSC parameters for Input Bpp = %d " + "Compressed BPP = %d\n", + pipe_config->pipe_bpp, + pipe_config->dsc_params.compressed_bpp); + return false; + } + pipe_config->dsc_params.compression_enable = true; + DRM_DEBUG_KMS("DP DSC computed with Input Bpp = %d " + "Compressed Bpp = %d Slice Count = %d\n", + pipe_config->pipe_bpp, + pipe_config->dsc_params.compressed_bpp, + pipe_config->dsc_params.slice_count); + + return true; +} + ++======= ++>>>>>>> parent of 7769db588384... drm/i915/dp: optimize eDP 1.4+ link config fast and narrow static bool intel_dp_compute_link_config(struct intel_encoder *encoder, - struct intel_crtc_state *pipe_config) + struct intel_crtc_state *pipe_config, + struct drm_connector_state *conn_state) { struct drm_display_mode *adjusted_mode = &pipe_config->base.adjusted_mode; struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base); @@@ -2035,52 -1965,23 +2036,61 @@@ intel_dp->common_rates[limits.max_clock], limits.max_bpp, adjusted_mode->crtc_clock); ++<<<<<<< HEAD + if (intel_dp_is_edp(intel_dp)) + /* + * Optimize for fast and narrow. eDP 1.3 section 3.3 and eDP 1.4 + * section A.1: "It is recommended that the minimum number of + * lanes be used, using the minimum link rate allowed for that + * lane configuration." + * + * Note that we use the max clock and lane count for eDP 1.3 and + * earlier, and fast vs. wide is irrelevant. + */ + ret = intel_dp_compute_link_config_fast(intel_dp, pipe_config, + &limits); + else + /* Optimize for slow and wide. */ + ret = intel_dp_compute_link_config_wide(intel_dp, pipe_config, + &limits); + + /* enable compression if the mode doesn't fit available BW */ + if (!ret) { + if (!intel_dp_dsc_compute_config(intel_dp, pipe_config, + conn_state, &limits)) + return false; + } ++======= + /* + * Optimize for slow and wide. This is the place to add alternative + * optimization policy. + */ + if (!intel_dp_compute_link_config_wide(intel_dp, pipe_config, &limits)) + return false; ++>>>>>>> parent of 7769db588384... drm/i915/dp: optimize eDP 1.4+ link config fast and narrow - DRM_DEBUG_KMS("DP lane count %d clock %d bpp %d\n", - pipe_config->lane_count, pipe_config->port_clock, - pipe_config->pipe_bpp); + if (pipe_config->dsc_params.compression_enable) { + DRM_DEBUG_KMS("DP lane count %d clock %d Input bpp %d Compressed bpp %d\n", + pipe_config->lane_count, pipe_config->port_clock, + pipe_config->pipe_bpp, + pipe_config->dsc_params.compressed_bpp); - DRM_DEBUG_KMS("DP link rate required %i available %i\n", - intel_dp_link_required(adjusted_mode->crtc_clock, - pipe_config->pipe_bpp), - intel_dp_max_data_rate(pipe_config->port_clock, - pipe_config->lane_count)); + DRM_DEBUG_KMS("DP link rate required %i available %i\n", + intel_dp_link_required(adjusted_mode->crtc_clock, + pipe_config->dsc_params.compressed_bpp), + intel_dp_max_data_rate(pipe_config->port_clock, + pipe_config->lane_count)); + } else { + DRM_DEBUG_KMS("DP lane count %d clock %d bpp %d\n", + pipe_config->lane_count, pipe_config->port_clock, + pipe_config->pipe_bpp); + DRM_DEBUG_KMS("DP link rate required %i available %i\n", + intel_dp_link_required(adjusted_mode->crtc_clock, + pipe_config->pipe_bpp), + intel_dp_max_data_rate(pipe_config->port_clock, + pipe_config->lane_count)); + } return true; }
thanks, -- js suse labs
On 19. 03. 19, 11:18, Dan Čermák wrote:
Jiri Slaby <jslaby@suse.cz> writes:
On 19. 03. 19, 8:05, Dan Cermak wrote:
I unfortunately wasn't able to finish the git bisect yesterday, but finished it just now:
7769db5883841b03de544a35a71ff528d4131c17 is the first bad commit
So does it also work when you revert only the commit on the top of 5.0.x? Like: git checkout v5.0.2 git revert 7769db5883841b03de544a35a71ff528d4131c17 make et al
That is unfortunately not possible, that commit was part of a huge number of patches that changed a lot in the i915 subsystem. I tried reverting it on top of v5.0 (there is no v5.0.2 tag upstream), but that failed with the following conflict (which I really don't feel even remotely competent enough to resolve):
OK, that happens. Then could you create a bug report with your findings at: https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel product=DRI component=DRM/Intel and paste the URL here? thanks, -- js suse labs
Jiri Slaby <jslaby@suse.cz> writes:
On 19. 03. 19, 11:18, Dan Čermák wrote:
Jiri Slaby <jslaby@suse.cz> writes:
On 19. 03. 19, 8:05, Dan Cermak wrote:
I unfortunately wasn't able to finish the git bisect yesterday, but finished it just now:
7769db5883841b03de544a35a71ff528d4131c17 is the first bad commit
So does it also work when you revert only the commit on the top of 5.0.x? Like: git checkout v5.0.2 git revert 7769db5883841b03de544a35a71ff528d4131c17 make et al
That is unfortunately not possible, that commit was part of a huge number of patches that changed a lot in the i915 subsystem. I tried reverting it on top of v5.0 (there is no v5.0.2 tag upstream), but that failed with the following conflict (which I really don't feel even remotely competent enough to resolve):
OK, that happens.
Then could you create a bug report with your findings at: https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel
product=DRI component=DRM/Intel
and paste the URL here?
Here you go: https://bugs.freedesktop.org/show_bug.cgi?id=110193 Thanks, Dan
thanks, -- js suse labs
-- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nürnberg Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
On 3/19/19 2:05 AM, Dan Cermak wrote:
I unfortunately wasn't able to finish the git bisect yesterday, but finished it just now:
7769db5883841b03de544a35a71ff528d4131c17 is the first bad commit
Could someone who also got hit by the issue do the following: - checkout the kernel git repository - checkout the above commit - build the kernel as Larry described below - boot it and try out if it breaks - reboot and checkout HEAD~1 - rebuild the kernel, reboot and test whether it works
Good job. Unfortunately, my i915 does not show this problem along with 99+% of them. If this problem hit very many people, it would have been fixed already. My experience is that the bug report you filed should get you a fix soon. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Op 18-03-19 om 15:11 schreef Dan Cermak:
Nope, I have blacklisted everything from Nvidia & Nouveau, so only the Intel driver should be running.
Did you try the intel driver? Modesettings has a bug with a few GPUs of Intel. See: https://bugzilla.opensuse.org/show_bug.cgi?id=1129027 Kind regards, Cor -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Dan Cermak composed on 2019-03-18 15:11 (UTC+0100):
Nope, I have blacklisted everything from Nvidia & Nouveau, so only the Intel driver should be running.
Actually it likely shouldn't. Intel pays its Linux driver writers to put most of their effort into the FOSS modesetting DDX driver. The xf86-video-intel DDX is in maintenance mode, having had no official release since 2015.
Also, I tried the Tumbleweed rescue disk: that one will start booting, but at some point the laptop screen just turns off and that's it.
Exactly how did you "blacklist" nouveau? Do it wrong, and you might block all DDX drivers. Precision 5530 is a model line, not a model. Which do you have? Better yet, what is output from 'inxi -Gxx' (which reports both kernel and DDX drivers, among other useful video info if X is running)? What does cat /proc/cmdline report? Xorg.0.log? -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Felix Miata <mrmazda@earthlink.net> 03/18/19 3:55 PM >>> Dan Cermak composed on 2019-03-18 15:11 (UTC+0100):
Nope, I have blacklisted everything from Nvidia & Nouveau, so only the Intel driver should be running.
Actually it likely shouldn't. Intel pays its Linux driver writers to put most of their effort into the FOSS modesetting DDX driver. The xf86-video-intel DDX is in maintenance mode, having had no official release since 2015.
Sorry, wrong wording: there are only Intel kernel modules loaded and no Nvidia/Nouveau kernel modules.
Also, I tried the Tumbleweed rescue disk: that one will start booting, but at some point the laptop screen just turns off and that's it.
Exactly how did you "blacklist" nouveau? Do it wrong, and you might block all DDX drivers.
Like this: $ cat /etc/modprobe.d/99-blacklist-nvidia.conf blacklist nouveau blacklist nvidia blacklist nvidia_drm blacklist nvidia_modeset
Precision 5530 is a model line, not a model. Which do you have? Better yet, what is output from 'inxi -Gxx' (which reports both kernel and DDX drivers, among other useful video info if X is running)? What does cat /proc/cmdline report? Xorg.0.log?
inxi -Gxx reports: Graphics: Device-1: Intel UHD Graphics 630 vendor: Dell driver: N/A bus ID: 00:02.0 chip ID: 8086:3e9b Device-2: NVIDIA GP107GLM [Quadro P1000 Mobile] vendor: Dell driver: N/A bus ID: 01:00.0 chip ID: 10de:1cbb Display: tty server: X.org 1.20.4 driver: N/A tty: 227x82 Message: Advanced graphics data unavailable in console. Try -G --display /proc/cmdline: BOOT_IMAGE=/boot/vmlinuz-5.0.2-2.gd1f1d19-default root=/dev/mapper/system-root splash=silent resume=/dev/system/swap quiet mem_sleep_default=deep nomodeset I have added the nomodeset parameter myself as Larry recomended, that gets me to at least to a tty. There is no Xorg.0.log, as I don't automatically start X on boot. However when launching it with nomodeset added, startx fails with not being able to load the i915.ko kernel module. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Dan Cermak composed on 2019-03-18 16:10 (UTC+0100):
There is no Xorg.0.log, as I don't automatically start X on boot.
I usually don't start X at boot either. All my TW installations with AMD, Intel & NVidia gfx generate /var/log/Xorg.#.log for every X session. Are you a Gnome user? None of mine have Gnome installed, or ever use Wayland.
However when launching it with nomodeset added, startx fails with not being able to load the i915.ko kernel module.
nomodeset disables kernel mode setting (KMS). i915.ko depends on KMS enabled. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Felix Miata <mrmazda@earthlink.net> writes:
Dan Cermak composed on 2019-03-18 16:10 (UTC+0100):
There is no Xorg.0.log, as I don't automatically start X on boot.
I usually don't start X at boot either. All my TW installations with AMD, Intel & NVidia gfx generate /var/log/Xorg.#.log for every X session. Are you a Gnome user? None of mine have Gnome installed, or ever use Wayland.
Not really: I use i3, which I start via ~/.xinitrc as the user that logs in, so the Xorg.log is generated after I logged in via a tty. My problem is though, that the tty simply doesn't show up with the 5.0.x kernel series (the screen stays blank).
However when launching it with nomodeset added, startx fails with not being able to load the i915.ko kernel module.
nomodeset disables kernel mode setting (KMS). i915.ko depends on KMS enabled. -- Evolution as taught in public schools is religion, not science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Dne pondělí 18. března 2019 15:11:05 CET, Dan Cermak napsal(a):
Nope, I have blacklisted everything from Nvidia & Nouveau, so only the Intel
On 3/18/19 2:53 PM, Dan Cermak wrote:
now my laptop will no longer boot into a graphical session. So if you have a Dell Precision 5530, don't reboot into the 5.0.1 or 5.0.2 kernel. If you did and it runs well, please tell me how you have configured your system, as I currently cannot even get the Tumbleweed rescue disk to boot
I have Dell Latitude E5570 uname -a Linux tilia 5.0.1-1-default #1 SMP Mon Mar 11 06:36:03 UTC 2019 (8c6a826) x86_64 x86_64 x86_64 GNU/Linux sudo lspci | grep VGA 00:02.0 VGA compatible controller: Intel Corporation Skylake GT2 [HD Graphics 520] (rev 07) sudo lsmod | grep i915 i915 2158592 29 drm_kms_helper 204800 1 i915 drm 499712 30 drm_kms_helper,i915 i2c_algo_bit 16384 1 i915 video 49152 3 dell_wmi,dell_laptop,i915 And everything is working fine as usually, so in Your case I'd indeed blame NVIDIA or so.
Do you have the NVIDIA proprietary driver installed via the openSUSE DKMS package ? -- Vojtěch Zeisek
Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/ https://trapa.cz/
On Mon, 18 Mar 2019 14:53:55 +0100, "Dan Cermak" <dcermak@suse.com> wrote:
Hi list,
yesterday I applied the update to the most recent kernel and unfortunately now my laptop will no longer boot into a graphical session. So if you have a Dell Precision 5530, don't reboot into the 5.0.1 or 5.0.2 kernel. If you did and it runs well, please tell me how you have configured your system, as I currently cannot even get the Tumbleweed rescue disk to boot (exactly the same symptoms: blank screen).
It has nothing to do with the Dell as such, but with the fact that it has an nVidia graphics card. Those problems have been mentioned a few time already on this list. This is exactly the reason I only choose laptops that do *not* have nVidia graphics hardware. Living on the edge with TumbleWeed and the lagging nVidia support makes the chance on a non-functional laptop too big for my comfort. Of course this all depends on how you use the laptop. I need a lot of power and do not really care about high performance graphics. I never play games Linux 5.0.1-1-default [openSUSE Tumbleweed 20190314] HP ZBook 15G3 Core(TM) i7-6820HQ CPU @ 2.70GHz/2986(8 cores) x86_64 15958 Mb Graphics: Device-1: AMD Venus XTX [Radeon HD 8890M / R9 M275X/M375X] driver: radeon v: kernel Display: tty server: X.Org 1.18.3 driver: radeon FAILED: ati unloaded: fbdev,modesetting,vesa resolution: 1920x1200~60Hz, 1920x1200~60Hz OpenGL: renderer: llvmpipe (LLVM 7.0 256 bits) v: 3.3 Mesa 18.3.4
Dan
-- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.29 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
On lundi, 18 mars 2019 15.09:39 h CET H.Merijn Brand wrote:
On Mon, 18 Mar 2019 14:53:55 +0100, "Dan Cermak" <dcermak@suse.com>
It has nothing to do with the Dell as such, but with the fact that it has an nVidia graphics card. Those problems have been mentioned a few time already on this list.
This is exactly the reason I only choose laptops that do *not* have nVidia graphics hardware. Living on the edge with TumbleWeed and the lagging nVidia support makes the chance on a non-functional laptop too big for my comfort.
Funky I have the total inverse experience, but I admit I'm not using the optimus things and this since more than 14 years of Dell/Nvidia couple. openSUSE Tumbleweed - 20190314 on Dell Precision 7510 Linux 5.0.1-1-default x86_64 GNU/Linux, nvidia: 418.43 Qt: 5.12.0, KDE Frameworks: 5.55.0, Plasma: 5.15.2, kmail2 5.10.3 just for the record. -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe supporter GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* H.Merijn Brand <h.m.brand@xs4all.nl> [03-18-19 10:11]:
On Mon, 18 Mar 2019 14:53:55 +0100, "Dan Cermak" <dcermak@suse.com> wrote:
Hi list,
yesterday I applied the update to the most recent kernel and unfortunately now my laptop will no longer boot into a graphical session. So if you have a Dell Precision 5530, don't reboot into the 5.0.1 or 5.0.2 kernel. If you did and it runs well, please tell me how you have configured your system, as I currently cannot even get the Tumbleweed rescue disk to boot (exactly the same symptoms: blank screen).
It has nothing to do with the Dell as such, but with the fact that it has an nVidia graphics card. Those problems have been mentioned a few time already on this list.
This is exactly the reason I only choose laptops that do *not* have nVidia graphics hardware. Living on the edge with TumbleWeed and the lagging nVidia support makes the chance on a non-functional laptop too big for my comfort.
is it *usually* simple to boot to an earlier version kernel and nvidia still has the best support for working graphic images. so all depends on one's expectations. I do not buy only nvidia but do buy nvidia for video intensive work. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (12)
-
Bruno Friedmann -
Cor Blom -
Dan Cermak -
Dan Čermák
-
Felix Miata -
Ferenc Szekely -
H.Merijn Brand -
Jiri Slaby -
Larry Finger -
Michael Pujos -
Patrick Shanahan -
Vojtěch Zeisek