I'm using a Debian distribution kernel, the version of the Linux kernel is 3.12-rc1. If I booted the kernel with nomodeset, then the system can not resume from a s2ram. I didn't try old distributions, so I didn't know if there is a kernel version can work. Please find the distribution kernel config attached.
Created attachment 104400 [details] The default Kconfig of Debian (3.16-rc1 x86-64)
(In reply to comment #1) > Created attachment 104400 [details] > The default Kconfig of Debian (3.16-rc1 x86-64) 3.16-rc1 x86-64 should be 3.12-rc1 x86-64. Sorry for the mistake.
Please provide dmesg (with drm.debug=6), and if possible dmesg from the failed resume using e.g. netconsole, for the most recent kernel you can test (should be based on 3.16 now).
Created attachment 104471 [details] Log achieved from remote after resuming Hi, I can ssh to the machine after resume.
Created attachment 104472 [details] Successful resuming without nomodeset This might be useful. Without nomodeset, the screen can successfully light up after resuming.
(In reply to comment #5) > Created attachment 104472 [details] > Successful resuming without nomodeset > > This might be useful. > Without nomodeset, the screen can successfully light up after resuming. Wait... Are you saying that it actually works when you use the driver for your hardware?
I didn't say this. Please check the bug title. This bug is: 1. When the kernel is booted with "nomodeset", resuming ended with black screen. 2. I didn't say that the kernel cannot resume when it is booted without "nomodeset". Do you mean: If I passed "nomodeset" to the kernel, I wasn't using the i915 driver? The story is: I need this platform to perform s2ram test using the mainline kernel. While currently I cannot boot it without "nomodeset" after 3.16-rc5, see this bug: https://bugs.freedesktop.org/show_bug.cgi?id=82439 And if I passed "nomodeset" to the kernel, I couldn't resume, see this bug. So actually, i915 is totally broken on this platform. I cannot perform any test using this platform I need to perform since 3.16-rc5.
(In reply to comment #5) > Created attachment 104472 [details] > Successful resuming without nomodeset > > This might be useful. > Without nomodeset, the screen can successfully light up after resuming. Please explain then since that contradicts the entire bug.
Hi, The title is: Dell Latitude 6430u failed to resume with nomodeset ^^^^^^^^^^^^^^ The attachment 104471 [details] (resume failed), the command line is: [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-3.12-1-amd64 root=UUID=ea5199dd-bbf4-42c1-831f-a8b4a78fac8d ro nomodeset drm.debug=6 ^^^^^^^^^ There is nomodeset in the command line. In attachment 104472 [details] (resume succeeded), the command line is: [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-3.12-1-amd64 root=UUID=ea5199dd-bbf4-42c1-831f-a8b4a78fac8d ro drm.debug=6 There is no "nomodeset" in the command line. So this log is not directly related to this bug. I just posted a successful resuming log for one who want to do a comparison. If you think attachment 104472 [details] is useless, please ignore it.
Please use KMS, your hardware is not supported with nomodeset.
(In reply to comment #10) > Please use KMS, your hardware is not supported with nomodeset. So you simply think this is a BIOS bug? I do want to use KMS, but currently I cannot boot the kernel without "nomodeset", unless someone here can help to solve this bug: https://bugs.freedesktop.org/show_bug.cgi?id=82439
(In reply to comment #11) > (In reply to comment #10) > > Please use KMS, your hardware is not supported with nomodeset. > > So you simply think this is a BIOS bug? No, I'm saying I don't care about bugs related to UMS on your hardware. > I do want to use KMS, but currently I cannot boot the kernel without > "nomodeset", unless someone here can help to solve this bug: > https://bugs.freedesktop.org/show_bug.cgi?id=82439 Sure, we need to focus on that one.
(In reply to comment #12) > (In reply to comment #11) > > (In reply to comment #10) > > > Please use KMS, your hardware is not supported with nomodeset. > > > > So you simply think this is a BIOS bug? > > No, I'm saying I don't care about bugs related to UMS on your hardware. But some developers may care. :-( If our test machines don't want to be affected by wrong graphics changes, we need to be able to perform tests without graphics driver loaded. Why we can uninstall the graphics driver on Windows and still can "sleep" and resume again? Whom should I report this bug to? Thanks and best regards -Lv > > > I do want to use KMS, but currently I cannot boot the kernel without > > "nomodeset", unless someone here can help to solve this bug: > > https://bugs.freedesktop.org/show_bug.cgi?id=82439 > > Sure, we need to focus on that one.
(In reply to comment #13) > If our test machines don't want to be affected by wrong graphics changes, we > need to be able to perform tests without graphics driver loaded. Ah, but you did have i915.ko loaded! nomodeset only disables kernel modesetting as the name implies. You can try modprobe.blacklist=i915 to prevent i915 from loading. (Although beware that some userspaces use insmod or modprobe directly to override that.)
(In reply to comment #14) > (In reply to comment #13) > > If our test machines don't want to be affected by wrong graphics changes, we > > need to be able to perform tests without graphics driver loaded. > > Ah, but you did have i915.ko loaded! nomodeset only disables kernel > modesetting as the name implies. You can try modprobe.blacklist=i915 to > prevent i915 from loading. (Although beware that some userspaces use insmod > or modprobe directly to override that.) I realized you were talking about this: without graphics driver loaded. :-) Sorry for my wording. Let me re-word. I wonder if I can still perform STR test with the graphics driver loaded but the specific functionalities bypassed. Kernel STR should still working for the kernel with kernel modesetting disabled, right? As we learned from 82439, by using nomodeset, we are able to bypass the affection of the bisected commit. But I just don't know why I cannot perform a successful STR by booting such a kernel.
(In reply to comment #15) > I wonder if I can still perform STR test with the graphics driver loaded but > the specific functionalities bypassed. > Kernel STR should still working for the kernel with kernel modesetting > disabled, right? What is STR? As I said many times, we do not support use cases that involve nomodeset on the hardware you have. If it works, great, but if it doesn't, we're not going to fix it.
(In reply to comment #16) > (In reply to comment #15) > > I wonder if I can still perform STR test with the graphics driver loaded but > > the specific functionalities bypassed. > > Kernel STR should still working for the kernel with kernel modesetting > > disabled, right? > > What is STR? I mean "suspend to ram" here. > > As I said many times, we do not support use cases that involve nomodeset on > the hardware you have. If it works, great, but if it doesn't, we're not > going to fix it. OK. I see. Thanks and best regards -Lv
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.