| Summary: | [SNB/IVB]Resume from suspend to disk cause restart | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | Ouping Zhang <ouping.zhang> | ||||||||||
| Component: | DRM/Intel | Assignee: | Chris Wilson <chris> | ||||||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||||||
| Severity: | critical | ||||||||||||
| Priority: | high | CC: | bojan, eugeni, jbarnes, jrnieder, nicolas.mb.francois, przanoni | ||||||||||
| Version: | unspecified | ||||||||||||
| Hardware: | x86 (IA32) | ||||||||||||
| OS: | Linux (All) | ||||||||||||
| Whiteboard: | |||||||||||||
| i915 platform: | i915 features: | ||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Ouping Zhang
2011-04-08 02:07:42 UTC
Ouping, what's the symptom of "fail"? Can you attach dmesg? does this only happen on drm-intel-backport? does this happen on x-hnr1 (rev08) or x-hnr3 (rev09)? Created attachment 45470 [details]
dmesg in text mode
Created attachment 45471 [details]
dmesg in X mode
The issue isn't an regression, which can be reproduced on both x-hnr3(rev09) and x-hnr1(rev08). It also happens on the former kernel versions, which is more easily reproduced on the latest kernel version. The symptoms of "fail" are as follows: when testing on HuronRiver again and again with the commamd: echo disk > /sys/power/state. After 2 suspend/resume circles, I found that the test machine can't resume to the former mode from suspend and it would restart by checking /var/log/messages. If in GNOME mode(compiz is disable), the test machine would return to the text mode after 2 suspend/resume circles, because something cause it restart. The same issue happens both HuronRiver and SugarBay. (In reply to comment #1) > Ouping, > what's the symptom of "fail"? Can you attach dmesg? > does this only happen on drm-intel-backport? > does this happen on x-hnr1 (rev08) or x-hnr3 (rev09)? Chris, any idea? Can you reproduce it? Does netconsole give you anything more interesting on the failed resume? Setting no_console_suspend may get more info out... The problem also exists on our IvyBridge . This is another one where the SNB S4 errata seems relevant. Jesse, after resuming from suspend to disk about 40 times, this issue can be reproduced. Setting no_console_suspend in /boot/grub/grub.conf, I get more info on the failed resume, please check the attached Setting no_console_suspend.log System Environment: -------------------------- Libdrm: (master)2.4.26-2-gce317a6d09bb93cff73703b06e5a5bc3cc0b1c6a Mesa: (master)4c84acc86fce5eda0aabcb8aa362fd6b5e6a28f6 Xserver: (master)xorg-server-1.10.99.901-115-g73864a87aacbce85b520ccaa6e360b82c0e99716 Xf86_video_intel: (master)2.15.0-205-g6dbbb74bde034f5f00aee0396ccd1e03a6625fbd Kernel: (drm-intel-next)df7976797fa9af161690dbf4dee81ed92cdc150f (In reply to comment #6) > Does netconsole give you anything more interesting on the failed resume? > Setting no_console_suspend may get more info out... Created attachment 49546 [details]
Setting no_console_suspend
Created attachment 49547 [details]
Setting no_console_suspend
The attached can be read by vi. (In reply to comment #11) > Created an attachment (id=49547) [details] > Setting no_console_suspend (In reply to comment #8) > This is another one where the SNB S4 errata seems relevant. Chris, when does Intel plan to address this issue? Can you give us more details about this known SNB S4 errata? Hi, Could you please check if those issues happen if you disable modesetting (e.g., boot with 'nomodeset' kernel parameter)? This was fixed on SNB with latest kernel according to testing by Xun Fang, so closing. Please reopen if it is still alive or affects any other system. |
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.