| Summary: | [Sandybridge] regression: FC16 Beta very slow display restore after resume vs FC15 | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Craig Ringer <craig> | ||||||||
| Component: | xorg-x11-drv-ati | Assignee: | Jérôme Glisse <jglisse> | ||||||||
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | medium | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 16 | CC: | ajax, mcepl, xgl-maint | ||||||||
| Target Milestone: | --- | Keywords: | Triaged | ||||||||
| Target Release: | --- | ||||||||||
| Hardware: | x86_64 | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | [cat:modesetting] | ||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2012-05-09 09:01:39 UTC | Type: | --- | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Attachments: |
|
||||||||||
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue. Please add drm.debug=0x04 to the kernel command line, restart computer, and attach * your X server config file (/etc/X11/xorg.conf, if available), * X server log file (/var/log/Xorg.*.log*; check with grep Backtrace /var/log/Xorg* which logs might be the most interesting ones, send us at least Xorg.0.log) * output of the dmesg command, and * system log (/var/log/messages) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above. We will review this issue again once you've had a chance to attach this information. Thanks in advance. After a `yum update' to the latest from the FC16 dev branch I'm seeing a reliable resume every time, it just takes 10 seconds or two at a text-console prompt before it switches back to graphical mode. I'll collect the requested info along with an Xorg log with "-verbose" set. Created attachment 528490 [details] dmesg output. Note acpi_call invocation where radeon is turned off. I've attached dmesg output. In the process I've identified part of the issue, which has changed somewhat with updates applied since the original FC16 beta. This bug is no longer reproducible on a stock FC16 beta system as of the latest updates. What stopped me noticing that earlier was a step I was taking to disable the onboard radeon secondary video card. It didn't make a difference before the updates; resume was always slow. After the latest updates, resume is quick unless the radeon is turned off. The radeon was being disabled using acpi_call (see http://linux-hybrid-graphics.blogspot.com/) with the ACPI call \_SB.PCI0.PEG0.PEGP._OFF . In case it's of any interest, I've attached dmesg output showing a few suspend/resume cycles with drm.debug=0x04 set. The onboard radeon was disabled at t=224.33; prior to that suspend/resume cycles were fast, after it they were reliable but took an extra 5-10s. The log entries after the radeon is disabled are interesting: [ 238.692874] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting [ 238.692878] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing CCB4 (len 62, WS 0, PS 0) @ 0xCCD0 [ 238.692881] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing B9C8 (len 1036, WS 4, PS 0) @ 0xBAC5 [ 238.692884] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing B95E (len 76, WS 0, PS 8) @ 0xB966 [ 238.804962] radeon 0000:01:00.0: Wait for MC idle timedout ! [ 238.917016] radeon 0000:01:00.0: Wait for MC idle timedout ! ... [ 239.059410] [drm:r600_ring_test] *ERROR* radeon: ring test failed (scratch(0x8504)=0xFFFFFFFF) [ 239.059412] [drm:evergreen_resume] *ERROR* evergreen startup failed on resume [ 243.869188] [drm:intel_ironlake_crt_detect_hotplug], trigger hotplug detect cycle: adpa=0xf40000 [ 243.879182] [drm:intel_ironlake_crt_detect_hotplug], ironlake hotplug adpa=0xf40000, result 0 [ 243.879185] [drm:intel_crt_detect], CRT not detected via hotplug [ 243.879187] [drm:output_poll_execute], [CONNECTOR:12:VGA-1] status updated from 2 to 2 [ 243.890871] [drm:output_poll_execute], [CONNECTOR:15:HDMI-A-1] status updated from 2 to 2 [ 243.891385] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5143003e [ 243.893685] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5143003e [ 243.895682] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5143003e [ 243.897172] [drm:intel_dp_detect], DPCD: 0000000000000000 [ 243.897177] [drm:output_poll_execute], [CONNECTOR:18:DP-1] status updated from 2 to 2 [ 244.058077] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting [ 244.058080] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing CCB4 (len 62, WS 0, PS 0) @ 0xCCD0 [ 249.056473] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting [ 249.056484] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing CCB4 (len 62, WS 0, PS 0) @ 0xCCD0 [ 254.054869] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting [ 254.054879] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing CCB4 (len 62, WS 0, PS 0) @ 0xCCD0 [ 259.053266] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting [ 259.053270] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing CCB4 (len 62, WS 0, PS 0) @ 0xCCD0 [ 264.051663] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting [ 264.051674] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing CCB4 (len 62, WS 0, PS 0) @ 0xCCD0 [ 269.050057] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting [ 269.050067] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing CCB4 (len 62, WS 0, PS 0) @ 0xCCD0 ... and suggest that maybe the dumb acpi_call approach for turning the radeon off isn't the greatest idea, not least because the kernel module for it remains loaded. I'll follow this up with people interested in hybrid graphics specifically, as I can no longer reproduce the original issue after updating to the latest post-beta release. Created attachment 528491 [details]
Xorg.0.log
For anyone else who finds this bug on Google because of matches to the log output above; just rmmod or blacklist the `radeon' drm driver and you should find your machine no longer minds the hardware vanishing. Simply: rmmod radeon ... or to prevent its loading on boot: echo "blacklist radeon" | sudo tee /etc/modprobe.d/radeon.conf Of course you'll have to remember you've blacklisted the driver if/when hybrid graphics support starts turning up in Xorg but combined with acpi_call this'll keep your power use sane while preserving decent suspend/resume in the mean time. I no longer have access to this machine so I won't be able to follow up on this. BTW, you can use the acpi_call module to power-down the Radeon hardware. https://github.com/mkottman/acpi_call See eg: http://cisight.com/switch-off-ati-vga-in-dual-vga-with-intel-on-ubuntu-to-solve-overheat-problem/ Just suppressing the loading of the radeon module isn't enough to stop it running full-bore and hogging power. You have to shut it off. By default the BIOS inits it. |
Created attachment 528365 [details] PCI, ACPI and DMI data from Vostro 3550 BIOS rev A06 Description of problem: In FC15, when this Dell Vostro 3550 laptop with hybrid Intel/ATI video was resumed from S3 sleep the display became available within a second or two. On FC16 Beta, it seems like the display doesn't resume properly until open and close the lid again to trigger the lid switch; this seems to get the machine to resume OK. Before I do this, the display backlight comes on and sometimes a non-X11 VT with a login prompt is shown, but there's no response to keyboard input (including CTL-ALT-Fx VT switch sequences) and video resume doesn't seem to proceed. Moving the mouse doesn't help; it's not just a locked display. Version-Release number of selected component (if applicable): xorg-x11-server-Xorg-1.11.1-1.fc16.x86_64 xorg-x11-drv-intel-2.16.0-2.fc16.x86_64 How reproducible: Every resume Steps to Reproduce: 1. Suspend laptop 2. Press power or open lid to resume laptop Actual results: Display backlight turns on but LCD remains blank or displays a text vt login prompt. No response to keyboard input, power button, etc, until lid switch is tripped again. Expected results: Display powers on and displays screen lock image I'll attach a debug xorg log after a reboot and test cycle. I've attached a DMI dump, some ACPI info the xorg-intel devs ask for in reports, and `lspci -vvvnnn' output.