My HP EliteBook 840 G1 refuses to resume from suspend. When I press the power button to turn it back on after suspend, I hear the hard drive spin up and the keyboard back light turns on but the screen remains blank. I'm guessing the machine is waking up ok but something goes wrong with the video leaving me without a working screen and my only option then is to do a hard power down. I initially took this issue up with burakkucat from the ElRepo team and after analyzing my logs, his conclusion was that the kernel was erring with the i915 driver and suggested that I should open this bug. The complete log of my ticket with El Repo is found here: http://elrepo.org/bugs/view.php?id=468 Specific information for this bug: (a) the relevant line from the lspci command output that refers to my video controller [quote] 00:02.0 VGA compatible controller [0300]: Intel Corporation Haswell-ULT Integrated Graphics Controller [8086:0a16] (rev 0b) [/quote] (b) the defined section from dmesg which shows the call trace [quote] ------------[ cut here ]------------ WARNING: CPU: 3 PID: 35 at drivers/gpu/drm/i915/intel_pm.c:5331 i915_request_power_well+0x39/0x40 [i915]() Modules linked in: snd_hda_intel(+) snd_hda_codec snd_hwdep snd_seq iwlmvm(+) mac80211 snd_seq_device snd_pcm snd_timer snd soundcore iwlwifi cfg80211 rfkill ext4 jbd2 mbcache sd_mod crc_t10dif crct10dif_common ahci libahci xhci_hcd wmi i915 drm_kms_helper video dm_mirror dm_region_hash dm_log dm_mod CPU: 3 PID: 35 Comm: kworker/3:1 Not tainted 3.14.0-1.el6.elrepo.x86_64 #1 Hardware name: Hewlett-Packard HP EliteBook 840 G1/198F, BIOS L71 Ver. 01.07 02/09/2014 Workqueue: events azx_probe_work [snd_hda_intel] 00000000000014d3 ffff8802338bdd48 ffffffff816328e7 00000000000014d3 0000000000000000 ffff8802338bdd88 ffffffff8106ceac ffffffffa00d8080 ffff8802309f5800 0000000000000000 0000000000000000 ffff880233900000 Call Trace: [<ffffffff816328e7>] dump_stack+0x49/0x62 [<ffffffff8106ceac>] warn_slowpath_common+0x8c/0xc0 [<ffffffff8106cefa>] warn_slowpath_null+0x1a/0x20 [<ffffffffa00b6509>] i915_request_power_well+0x39/0x40 [i915] [<ffffffffa0408a42>] hda_display_power+0x42/0x50 [snd_hda_intel] [<ffffffffa040717b>] azx_probe_continue+0x4b/0x2a0 [snd_hda_intel] [<ffffffffa04073e5>] azx_probe_work+0x15/0x20 [snd_hda_intel] [<ffffffff810898fc>] process_one_work+0x17c/0x420 [<ffffffff8108b043>] worker_thread+0x123/0x400 [<ffffffff8108af20>] ? manage_workers+0x170/0x170 [<ffffffff81090b0e>] kthread+0xce/0xf0 [<ffffffff81090a40>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8164003c>] ret_from_fork+0x7c/0xb0 [<ffffffff81090a40>] ? kthread_freezable_should_stop+0x70/0x70 ---[ end trace 843af60ca0d6ae5a ]--- [/quote]
The backtrace you've linked shouldn't result in resume failures. Can you please test with latest drm-intel-fixes branch from http://cgit.freedesktop.org/drm-intel That has a fix for the WARNING. For the resume issue, is this a regression? If so can you please try to bisect the issue (only using resume failures as y/n, not any other kind of backtraces).
I'm not sure if it's a regression or not. I have two data points: - 2.6.32-431.11.2.el6.x86_64 - 3.14.0-1.el6.elrepo.x86_64 In both cases the behavior is identical. Can you suggest a range of kernel versions that you would like me to try? And again, I just want to reiterate so we're clear, I believe the machine is coming up ok from resume with the exception that I can't see anything on the display. The failure to resume seems to be limited to the video (as near as I can tell).
(In reply to Denis Leclair from comment #2) > I'm not sure if it's a regression or not. I have two data points: > - 2.6.32-431.11.2.el6.x86_64 > - 3.14.0-1.el6.elrepo.x86_64 > > In both cases the behavior is identical. > > Can you suggest a range of kernel versions that you would like me to try? > > And again, I just want to reiterate so we're clear, I believe the machine is > coming up ok from resume with the exception that I can't see anything on the > display. The failure to resume seems to be limited to the video (as near as > I can tell). (1) A kernel-ml-3.14.0-2.drm_intel_fixes_2014_04_11.el6.elrepo rpmpackage set is now available to download from http://elrepo.org/people/ajb/devel/kernel-testing/el6/ Please test and then report back to Daniel if it fixes/does not fix the WARNING/backtrace. (2) Please choose a convenient ELRepo Project mirror site [1] that carries the archive. From the kernel archive, select the earliest kernel-ml package that is available. Test for resume failure - ACK/NACK. If the earliest kernel-ml does resume correctly, perform a classic binary chop to determine the last working and first that fails. If the earliest kernel-ml does not resume correctly, try with the earliest kernel-lt package that is available. [1] http://elrepo.org/tiki/Download
will do. I will get started and report back with my findings.
Tested the kernel-ml-4.14 with intel-fixes-2014-04-11. - no change in behavior re: resume from suspend - no change in xrandr output i.e. no detection of VGA port - no change in WARNING/backtrace. kernel warning: http://pastebin.centos.org/8931/ full dmesg log: http://pastebin.centos.org/8926/ I will start on binary searching the historical kernels and will report back with my findings.
I tried the following 3 kernels and none of them came back up properly out of suspend (screen remained blank). kernel-lt-3.10.25-1.el6.elrepo.x86_64.rpm kernel-ml-3.12.6-1.el6.elrepo.x86_64.rpm kernel-ml-3.13.2-1.el6.elrepo.x86_64.rpm Interestingly, the kernel-lt-3.10.25 version did not show the WARNING/backtrace in the dmesg log but my USB mouse didn't work and the suspend/resume did not work either. What are the next steps on this?
Daniel, Any thoughts on where we go next with this? I'm happy to help work through the issue using this machine as a test case if there are things that you want to investigate. But if you think we're at a dead end then I'd like to know because I'll have to make tough decisions around what to do with the hardware and/or OS. I'd appreciate getting your perspective on it. Thanks for all your help so far. Denis
I have reviewed all the information relating to this bug report and it is my understanding that Denis has never had a suspend/resume process to operate correctly with this hardware. So rather than classifying this bug as a regression, I would suggest that it be viewed in the "never worked" category. Daniel -- Time permitting, I will be willing (on behalf of the ELRepo Project) to build appropriate test kernels for Denis to use.
I concur with Daniel - I don't think the WARNING has anything to do with the resume. There are a few things that could be tried. Please boot without loading i915. Suspend/resume and see if it works. If it works, load i915 and try again. If it fails, it confirms if the problem really is in i915. Please enable drm.debug=0xe module parameter. Do a suspend/resume with i915. See if the machine responds to ping. Ssh into the machine and grab the dmesg and attach here.
You will have to bear with me as I am near the boundaries of my Linux knowledge. I tried removing i915 using 'modeprobe -r i915' but it was complaining that the module is in use. According to lsmod, the i915 module is also used by 'drm_kms_helper' and 'video'. I tried remove all 3 modules in various orders but in all cases the error came back saying they are in use. I tried adding i915 to blacklist.conf but that didn't seem to have any effect. Then I added i915, drm_kms_helper, and video to blacklist.conf but still no effect. I rebooted the laptop for each of these attempts. I don't know what to try next to get rid of it. While I wait for your answer on that I'll see if I can try the test of adding the drm.debug=0xe parameter and grabbing the dmesg.
I guess I'm blocked on the second test also since I cannot add a module parameter without first unloading the module which I can't do as per my comment 10.
One other note...Even though the suspend/resume issue was the first thing I found which led me to raise this bug, afterwards I found that the external VGA port on this laptop is not being detected which is preventing me from connecting an external monitor. Actually, the inability to use an external monitor is my biggest concern for the time being. I can work around the suspend issue by always using hibernate but not being able to put my screen up on projectors in meetings or desktop monitors is a much harder problem for me. I've hesitated opening a separate bug for the VGA port issue on the basis that the suspend/resume issue also appears to be related to video so it's possible that they're both tied to the same root cause. That said, if you prefer that I open a separate bug to track the two issues separately I can do that.
This pastebin has the dmesg output from a reboot with 'drm.debug=0x6' http://pastebin.centos.org/8981/
Ok, here is more data on the suspend/resume issue. This dmesg was taken after a normal boot with drm.debug=0xe: http://pastebin.centos.org/8986/ This second dmesg was taken from ssh into the laptop while it had the blank screen during the attempt to resume: http://pastebin.centos.org/8991/ In this second one, we see two more errors with backtraces on top of the first one. - The first one is in i915_request_power_well() - The second one is in i915_release_power_well() - The third one is in i915_request_power_well() It seems like all three of these step from the hda_display_power() function which if I understand correctly is related to the HD audio controller so I'm not sure how that would relate to the display not turning on but it doesn't seem right. I also pulled down the latest drm-intel source code and started looking around in there. I came across a comment for 810 driver which essentially said that the BIOS may keep VGA ports powered down unless there is a monitor present at power-up. I haven't had a monitor present in any of my testing so could that be part of the problem? I've simply been looking to see that the display port shows up in xrandr. If the activation of the port is dependent on the monitor being there then that's not good because I don't want to have to reboot every time I want the monitor to be detected.
The status of this bug is showing as 'NEEDINFO'. Please let me know what other information is required to give the bug a proper disposition. I also need guidance for whether the missing VGA port detection should be raised as a separate bug or if it is most likely tied the same root cause as this bug. Thanks.
Remove nomodeset from kernel command line and try again.
Here are the results: I had the laptop plugged into the docking stations with two external monitors connected to 2 display ports on the back of the dock. The lid of the laptop remained open during the tests: Test #1: On boot up without nomodeset on the kernel line, I saw the graphical CentOS 6.5 splash screen instead of the terminal based blue lines scrolling from left to right as I normally do. I also found that the splash screen was displayed on all 3 displays simultaneously (the laptop screen + 2 external screens via DisplayPort). Then I saw the following line show up: [quote] tpm_tis 00:0a: A TPM error (7) occurred attempting to read a pcr value [/quote] At this point the boot sequence halted and I had to power down the computer. Test #2: Again with the laptop plugged into the dock with the same two monitors connected to the DisplayPorts and nomodeset removed from the kernel launch line. This time I saw: [quote] tsc: Fast calibration failed tpm_tis 00:0a: a TPM error (7) occurred attempting to read a pcr value [/quote] The boot sequence stopped there. Note: I see the 'tsc: Fast calibration failed' line randomly from boot to boot whether or not the nomodeset is on the kernel launch line. Test #3: I removed the laptop from the docking station and kept the nomodeset removed from the kernel launch line. I again saw the 'tpm_tis' error line and the boot sequence stopped. Test #4: I replaced the laptop back on the docking station and I re-added the nomodeset to the kernel launch line. The boot sequence did not show the graphical splash and instead had the blue bars scrolling from left to right. The boot sequence completed successfully on the laptop screen and the two external monitors never turned on.
I don't think you're going to like the news. First, i915 does not support your hardware with nomodeset. Only KMS is supported. Second, we don't have proper support for DP hubs either, that means your dock with two DP monitors. Third, the TPM errors have nothing to do with i915 (or at least I can't think of how they could have). We need to reduce the scope to test #3. What does it mean you saw tmp_tis error? Is that the last thing you see? Where does the boot stop? Does a GUI come up? What does a hang mean? Does the machine respond to ping? Can you ssh into it?
Ok, in the spirit of reducing the scope of the problem, I will stick with testing off the dock. I will remove the nomodeset parameter and I will try booting into init level 3 and I'll observe what happens. I will try to validate whether it responds to ping and/or ssh but that is harder for me to do with my setup so it might take me a bit longer to do that.
ok, when I boot into init level 3 with "nomodeset" removed from the kernel line, the system boots up and I get my command prompt. After logging in I found that the system services were up (networking stack, etc...). From there, I tried to launch into runlevel 5 by calling "startx" or "telinit 5" or "startxfce4" and what I got was: [quote] Fatal server error: no screens found [/quote] Next question...you mentioned that the dock hardware won't work due to the DP hub not being supported. That's a pain. However, the laptop has a VGA port and a DP port port built right into the side of it. If there's any way that I can use either of those ports for my displays combined with the dock for power and USB keyboard/mouse then that might be a workable setup for me.
(In reply to Denis Leclair from comment #20) > ok, when I boot into init level 3 with "nomodeset" removed from the kernel > line, the system boots up and I get my command prompt. After logging in I > found that the system services were up (networking stack, etc...). > > From there, I tried to launch into runlevel 5 by calling "startx" or > "telinit 5" or "startxfce4" and what I got was: > > [quote] > Fatal server error: > no screens found > [/quote] Please attach dmesg from early boot to the problem, with drm.debug=0xe module parameter set. (Specifically please use the "Add an attachment" feature on bugzilla instead of linking to pastebin, thanks.) > Next question...you mentioned that the dock hardware won't work due to the > DP hub not being supported. That's a pain. I didn't say it won't work, I said we don't have proper support for it. ;) It might work, particularly with a one monitor setup, but no guarantees. > However, the laptop has a VGA > port and a DP port port built right into the side of it. If there's any way > that I can use either of those ports for my displays combined with the dock > for power and USB keyboard/mouse then that might be a workable setup for me. That's probably all right - but let's focus on getting your setup working without nomodeset and external monitors first. Otherwise there are just too many variables.
Completely agree about keeping the problem space constrained until the basic setup is working. I'm very thankful for the support I've been getting from the intel-gfx and elrepo maintainers. I'm posting the attachments now.
Created attachment 133361 [details] dmesg from boot without nomodeset runlevel 3. Captured after attempting to launch startx. This includes the attempt to launch startx where I get the error message: [quote] Fatal server error no screens found [/quote]
Created attachment 133371 [details] Xorg log file taken at the same time as the previous dmesg.
(In reply to Denis Leclair from comment #24) > Created attachment 133371 [details] > Xorg log file taken at the same time as the previous dmesg. AFAICT you don't have the Intel X driver installed.
I'll do some searching online but if you have a package name or something to point me in the right direction that will help.
It looks like I have version 2.21.12 installed. The next attachment shows the yum info for this package plus all the other related packages that I could find. In summary: xorg-x11-drv-intel: v2.21.12 installed xorg-x11-drv-intel-devel: v2.21.12 not installed (available) libdrm: v2.4.45 installed libdrm-devel: v2.4.45 installed drm-utils: No matching Packages to list intel-gpu-tools: v2.21.12 not installed (available) Could it be that intel-gpu-tools is the package I need to have for whatever problem you are seeing in the log?
Created attachment 133381 [details] yum info for packages related to xorg-x11-drv-intel
Nope, xorg-x11-drv-intel is all you need to have the right driver. No idea why that doesn't work for your distro.
Can you clarify for me what you are seeing in the dmesg or Xorg logs that point to the xorg-x11-drv-intel driver not working? I could try reinstalling that package if you think that might help.
Chris suggests you have misconfigured xorg.conf. Please attach.
Created attachment 133421 [details] xorg.conf My default xorg.conf file. Unmodified by me.
great news...everything is now working. For the record: I booted into runlevel 3 without nomodeset. The idea was to reinstall Xorg in case the previous installation with nomodeset on the kernel line affected something. The re-installation made no difference. the behavior from startx was the same and the xorg.conf file was also the same. I then did some searching on the web and found that we should run "Xorg -configure" to auto-scan the hardware and generate a proper xorg.conf file. So I went back into runlevel 3 without nomodeset and ran the "Xorg -configure" command. I will attach the xorg.conf file that it generated right after I post this comment. I rebooted with the new xorg.conf file and thankfully everything is now working. I can now suspend and resume without problem, all the function keys (volume, brightness, etc...) are working. I even plugged an external monitor to my VGA port and it was automatically detected and my desktop was extended. The only thing I haven't tried yet is putting the laptop on the docking station to see how it behaves there. I will try that when I return to the office tomorrow morning. So it seems to me the root cause of all of this came down to two things: 1. the CentOS installer added nomodeset to the kernel line even though the i915 driver does not support it. 2. (perhaps due to problem #1) the CentOS installer did not automatically setup the xorg.conf file by running an "Xorg -configure" scan. Do you see anything incorrect with my conclusions? I'm thinking I should file this as a bug with the CentOS maintainers so that other people don't fall into the same trap but I'd like your perspective before doing that.
Created attachment 133501 [details] new xorg.conf file after running Xorg -configure
(In reply to Denis Leclair from comment #33) > great news...everything is now working. \o/ > So it seems to me the root cause of all of this came down to two things: > 1. the CentOS installer added nomodeset to the kernel line even though the > i915 driver does not support it. > > 2. (perhaps due to problem #1) the CentOS installer did not automatically > setup the xorg.conf file by running an "Xorg -configure" scan. > > Do you see anything incorrect with my conclusions? Sounds about right. Would be interesting to hear their reasons for adding nomodeset. > I'm thinking I should file this as a bug with the CentOS maintainers so that > other people don't fall into the same trap but I'd like your perspective > before doing that. Please do. At least figure out what the rationale is. Thanks for the report, resolving as invalid.
I don't know of a case in which nomodeset is added to the kernel option by the installer with RHEL/CentOS/Scientific Linux. Denis, are you sure that really happened? If so, it may be worth filing a bug report. My understanding is that nomodeset will not be available in the upcoming RHEL-7.
toracat, I am as sure as I can be about this. I definitely did not add the nomodeset myself. In fact, when Jani suggested that I try removing the nomodeset, that was the first time I ever saw the graphical CentOS splash screen on bootup. The only boot screens I had seen prior to that were text based. Ideally I would wipe this system out and repeat the installation procedure again to be extra sure but it's taken me more than 2 weeks to get a machine that basically works and I don't want to start over at this point. I could try in a VM environment but my concern is that the virtualization of the hardware would not be a good comparison to my installation on bare metal. What I recall is that I selected "Desktop" in the list of available installation configurations and ever since then the nomodeset was present on the kernel line.
Jani, Daniel, As you predicted, the DP hub in the docking station does not work very well. The computer only detects one of the two external displays as being present. I've resigned myself to just make use of one of the external monitors. That combined with the laptop display should be adequate for most of what I need for now at least. Is there a roadmap of upcoming feature enhancements to the i915 driver? If so then does support for broader Display Port configurations show up on the roadmap?
I'm trying to remember how I did the initial install (it was a long time ago). I think I used an application like pendrivelinux to create a bootable USB key and I'm pretty sure I loaded it with the CentOS minimal ISO because my USB stick was quite limited in memory. From there, I mounted a separate drive that had the full ISO for completing the installation. It could very well be that the nomodeset flag was "inherited" from the initial minimal boot image generated from pendrivelinux. I've requested a temporary computer (similar model) from my IT department to try the procedure out again to confirm where the problem came from.
I am puzzled as to how an xorg.conf file came to be present in the /etc/X11/ directory. A standard install of RHEL 6 / CentOS 6 / Scientfic Linux 6 does not install nor generate such a file, as the version built into the X-server is considered to be sufficient. The fact that there was one (as attached above -- the file of 68 bytes), which referenced the vesa driver, make me suspicious of the original installation. As toracat has previously mentioned, the kernel command line flag "nomodeset" has never been seen as an installer generated parameter. Thus there were two abnormallities in this particular EL6 installation: (1) the "nomodeset" flag on the kernel command line (2) the generation of an /etc/X11/xorg.conf
(In reply to Denis Leclair from comment #38) > As you predicted, the DP hub in the docking station does not work very well. > The computer only detects one of the two external displays as being present. This is unfortunate, but expected. > Is there a roadmap of upcoming feature enhancements to the i915 driver? If > so then does support for broader Display Port configurations show up on the > roadmap? It's on the roadmap, but I can't share details about the schedule etc. We generally do not track feature requests via bugzilla, but there's one for DP MST at https://bugs.freedesktop.org/show_bug.cgi?id=72795 (no need to add your "me too" on the bug).
(In reply to Alan Bartlett from comment #40) > Thus there were two abnormallities in this particular EL6 installation: > > (1) the "nomodeset" flag on the kernel command line > (2) the generation of an /etc/X11/xorg.conf Please file a new bug on the appropriate tracker, wherever that is, as this one is resolved from the drm/i915 perspective. Please add links between the bugs for reference for others hitting the issue. Thanks.
Hello, I'd like to report that I've had the exact same problem with my no-name laptop. I made a clean install of CentOS 6 (from DVD), and then installed kernel-ml (because it had a wifi driver that I wanted, over the normal kernel). Interestingly, suspend/resume does not work as per original poster of the bug, the boot sequence always used text-mode, the /etc/X11/xorg.conf only has one section with a "vesa" driver and my /etc/grub.conf has "nomodeset" set to both kernel & kernel-ml lines. Linux laptop 3.15.2-1.el6.elrepo.x86_64 #1 SMP Thu Jun 26 22:40:56 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller]) 01:00.0 VGA compatible controller: NVIDIA Corporation GK107M [GeForce GTX 660M] (rev a1) (prog-if 00 [VGA controller])
I forgot to mention a few more things: - After removing "nomodeset" from the kernel-ml parameters, on first boot X11 wouldn't load due to the broken /etc/X11/xorg.conf. This was easily fixed by just erasing the file! This allows X11 to auto-detect everything and boot normally. - Suspend/resume works fine. - LCD brightness works fine, before the system couldn't lower/raise brightness based on mouse movements. BEFORE (/sys/): ./module/i915/parameters/invert_brightness ./module/video/parameters/brightness_switch_enabled AFTER (/sys/): ./devices/pci0000:00/0000:00:02.0/backlight/acpi_video0/brightness ./devices/pci0000:00/0000:00:02.0/backlight/acpi_video0/max_brightness ./devices/pci0000:00/0000:00:02.0/backlight/acpi_video0/actual_brightness ./module/i915/parameters/invert_brightness ./module/video/parameters/brightness_switch_enabled
(In reply to Dimitris from comment #44) > I forgot to mention a few more things: > > - After removing "nomodeset" from the kernel-ml parameters, on first boot > X11 wouldn't load due to the broken /etc/X11/xorg.conf. This was easily > fixed by just erasing the file! This allows X11 to auto-detect everything > and boot normally. > > - Suspend/resume works fine. > > - LCD brightness works fine, before the system couldn't lower/raise > brightness based on mouse movements. My interpretation of the above is that you no longer have issues with the graphics drivers. If you still have problems, please file a *new* bug. Thanks.