Image used: http://autobuilder03.jf.intel.com/pub/nightly-meta-intel/20120712-1/machines/crownbay/core-image-sato-sdk-crownbay-20120712020904.iso STEPS TO REPRODUCE: 1. Image installed on the Crownbay BSP 2. Put the BSP to sleeP: echo "mem" > /sys/power/state 3. wake up ACTUAL RESULT: X fails to start
This may be similar to bug 1258. Please provide the following so we know what hardware we're dealing with: cat /proc/cpuinfo cat /proc/interrupts lspci -v Xorg.0.log dmesg output after system boot dmesg output after suspend/resume
Created attachment 648 [details] logs Hi Tom, Please find the information in the attachment. Thanks, Alex.
I have set the status back to New
Hi, I have tested on the following version: 201208090703 and it seems that the bsp could resume successfully from standby.
I reproduced this in branch danny, commit: 86c9aa8081f107420cd3763d0566d779daddc2b1 image: core-image-sato-sdk-crownbay
Furthermore, the system's video output is not working. The screen is blank. It may be that the video output is not restored after standby or the output is blank. Also this can also be the reason why the X server does not restart and why the CPU meter is at 50% for xorg process (see bug 1258).
When booting off of a live image, it took 55 seconds to restore the screen, but it did come back. This may have made it appear that video wasn't restored if you didn't wait long enough. The other thing to note was that the rootfs was remounted as read-only in this case (dmesg attached as minicom.cap.danny.crownbay.ro). On another occasion, video came back immediately and the rootfs was mounted rw as expected (dmesg attached as minicom.cap.denzil.mem.quick.and.no.ro). The behavior was the same for denzil, so this is not a regression in danny (dmesg attached as minicom.cap.denzil.crownbay.power.mem). Installing the image to hdd, everything worked perfectly - video came back immediately, the rootfs was writable and no other problems were noted (dmesg attached as minicom.cap.danny.crownbay.hdd) In all cases, top showed normal cpu usage for Xorg (<10%) so that was not an issue either. Considering that the important use case of a normally installed system works fine, I'd suggest closing this bug as well as [Bug 1258 - [crownbay] Xorg eats lots of CPU time after standby] since they don't appear to be a problem on normally installed and configured systems, and opening a new bug saying that s3 on live images takes a long time to restore X and may come back with ro rootfs, all of which may be due to some kind of USB restore problem. As mentioned in bug 1258 the difference between the QA systems and the systems that work is the microcode revision (104 vs 105) so until the systems with 104 are upgraded, they shouldn't be used for verification or opening new bugs.
Created attachment 917 [details] s3 test for danny on crownbay, system booted off of hdd
Created attachment 918 [details] s3 test for danny on crownbay, system booted off of usb stick
Created attachment 919 [details] s3 test for danny on crownbay, system booted off of usb stick, came back ro
Created attachment 920 [details] s3 test for danny on crownbay, system booted off of usb stick, came back rw
This is obviously due to hardware differences that we haven't isolated yet. It works perfectly well on my test system with the same image that fails on QA systems. Moving to 1.4. For reference: poky/danny: commit 27af23e65f63b41962a7cfddba9e9372d5212396 meta-intel/master: commit 62aa4ca25a943c864838b2910c5b506cca0c9323 I also use the power button to resume.
If there's any more work to be done for this bug, it's to figure out why QA's system is broken. My system and Nitin's system work fine, except for the case of booting off of a live image, which has been addressed as a new bug [Bug 3381].
Verified.
This issue is present in danny for core-image-sato-sdk-noemgd.
Please note that this issue does not occur on "emgd" images, only on "noemgd" ones. This is valid for all my comments from 2012-10-09 11:51:49 UTC untill now. I am sorry for the confusion.
Same issue (X fails to start) on noemgd image on denzil: 3456295898bf157e40ea1f8c335f0b7285d3d8a7
Because this only happens in the vesa 'noemgd' case, and the more important 'emgd' case works fine, I'm not too concerned about this. We will be changing the 'noemgd' case to use the gma500 driver instead of vesa for 1.4, which may fix the problem. We should retest once that happens.
seems that this doesn't happen anymore with 1.6 M1-rc1 build. Will close it after the next fullpass just to make sure.
We no longer support crownbay and emgd, therefore closing this bug
obsolete