| Summary: |
crownbay: s3 problems when booting off of live image on usb flash drive |
| Product: |
[Build System, Metadata & Runtime] BSPs
|
Reporter: |
Tom Zanussi <tom.zanussi> |
| Component: |
bsps-meta-intel | Assignee: |
Saul Wold <sgw> |
| Status: |
RESOLVED
OBSOLETE
|
QA Contact: |
|
| Severity: |
normal
|
|
|
| Priority: |
Low
|
CC: |
dvhart, sgw, tom.zanussi
|
| Version: |
1.4 | |
|
| Target Milestone: |
Future | |
|
| Hardware: |
TunnelCreek | |
|
| OS: |
x86 | |
|
| Whiteboard: |
|
|
OS type for building Yocto:
|
---
|
Type of Regression:
|
---
|
|---|
|
Verified:
|
|
Documentation change:
|
No (bug/feature does not impact docs)
|
|---|
| Attachments: |
|
Created attachment 929 [details] s3 test for danny on crownbay, system booted off of hdd When booting off of a live image on a usb flash drive, 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. Note that the most important use case of a normally installed system works fine however.