Bug detailed description:
doing reliability tests on HuronRiver with the command: echo disk > /sys/power/state, resume from suspend to disk fails after 3 suspend/resume cycles. The issue can be reproduced whatever starting X or not. However, resume from suspend to mem can pass after many suspend/resume cycles.
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)
> 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
(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]
Created attachment 49547 [details]
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?
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.