Tree/Branch : Poky/1.1_M2 Poky Commit : fa4bcfdb73167f8159b88e5a4d711c0d37627a70 Meta Branch : 1.1_M2 Meta Commit : 738d2bc6d1a0d7ff6589000893c1c8b4f983d76f image location: http://autobuilder03.jf.intel.com/crownbay-1.1_M2/nightly/20110717-1/machines/crownbay/x86_32/core-image-sato-sdk-live-crownbay-20110717223745.hddimg.bz2 After the X server issue is resolved for crownbay, with Yocto 1.1 M2 RC3 image of crownbay emgd, we find after standby, Xorg costs a lot of CPU time. Before standby, Xorg costs less than 1% CPU time. After standby, if user is working in Xserver, Xorg costs more than 50% CPU time. Detailed log could be found in attachment. Call trace is printed in dmesg for Xorg at the same time: ####### Pid: 397, comm: Xorg Not tainted 2.6.37.6-yocto-standard+ #1 Call Trace: [<c14d1b5b>] __report_bad_irq.isra.3+0x3f/0x87 [<c14dbc89>] ? sub_preempt_count+0x9/0xb0 [<c1085b8a>] note_interrupt+0x15a/0x1a0 [<c101a2bf>] ? ack_apic_level+0x6f/0x1c0 [<c1087969>] ? move_native_irq+0x19/0x60 [<c1086813>] handle_fasteoi_irq+0xc3/0xf0 [<c1086750>] ? handle_fasteoi_irq+0x0/0xf0 <IRQ> [<c1086750>] ? handle_fasteoi_irq+0x0/0xf0 [<c14ded44>] ? do_IRQ+0x54/0xc0 [<c14dee35>] ? smp_apic_timer_interrupt+0x85/0x183 [<c14d00d8>] ? percpu_counter_hotcpu_callback+0x6e/0x85 [<c10033e9>] ? common_interrupt+0x29/0x30 handlers: [<c12f3150>] (usb_hcd_irq+0x0/0x60) [<c12f3150>] (usb_hcd_irq+0x0/0x60) [<c12f3150>] (usb_hcd_irq+0x0/0x60) [<c12f3150>] (usb_hcd_irq+0x0/0x60) [<c12eae60>] (pch_gbe_intr+0x0/0x220) [<c1401c80>] (azx_interrupt+0x0/0x180) [<f81de150>] (SystemISRWrapper+0x0/0x50 [emgd]) Disabling IRQ #16 #######
Created attachment 188 [details] top output before S3
Created attachment 189 [details] top output after S3
Created attachment 190 [details] dmesg log with Xorg call trace
Tom, can you report this to your emgd contacts and see if they have any suggestions?
I have checked this with the new EMGD 1.8 and saw no oopses or XServer degradation in top. Once I'm able to commit the crownbay changes, I'll close this out.
This issue still exist in Yocto1.1 20110824 build, but other Intel BSPs didn't find this issue. Commit information: Tree/Branch: Poky/Master Poky Commit id: 9ca6806de9d9df9d901774c1b23a14f28f10a844 Meta Branch: Master Meta commit id: fb15cc4e1c4be75c81acaf6a1dd33675a9142975 Image location: http://autobuilder03.jf.intel.com/crownbay-master/nightly/20110824-1/machines/crownbay/x86_32/core-image-sato-sdk-crownbay-20110825040624.hddimg.bz2
Fixed by meta-intel commit d40a58a2d2329e329c93461baf697fe27b4cd3fb.
(In reply to comment #7) > Fixed by meta-intel commit d40a58a2d2329e329c93461baf697fe27b4cd3fb. Using top command to check CPU's status, we still found this issue exist against below information. Maybe the fixed code didn't merged into meta-intel, I should follow it base on newer image. Commit information: Tree/Branch: Poky/1.1_M4 Commit id: bb4a5c44da23a1bb363f1f081cf1644fd7975957 Meta Branch: 1.1_M4 Commit id: 49277afd9e5e510f7b1f82fd8cd10732e3bf2633 Image location: http://autobuilder03.jf.intel.com/pub/emenlow/20110916-1/machines/emenlow/core-image-sato-sdk-emenlow-20110916085642.hddimg
(In reply to comment #8) > (In reply to comment #7) > > Fixed by meta-intel commit d40a58a2d2329e329c93461baf697fe27b4cd3fb. > > Using top command to check CPU's status, we still found this issue exist > against below information. Maybe the fixed code didn't merged into meta-intel, > I should follow it base on newer image. > > Commit information: > > Tree/Branch: Poky/1.1_M4 > Commit id: bb4a5c44da23a1bb363f1f081cf1644fd7975957 > Meta Branch: 1.1_M4 > Commit id: 49277afd9e5e510f7b1f82fd8cd10732e3bf2633 > > Image location: > > http://autobuilder03.jf.intel.com/pub/emenlow/20110916-1/machines/emenlow/core-image-sato-sdk-emenlow-20110916085642.hddimg This is the emenlow image - the bug is for crownbay.
Sorry for this big mistake, the image as below: http://autobuilder03.jf.intel.com/pub/crownbay/20110916-1/machines/crownbay/core-image-sato-sdk-crownbay-20110916104031.hddimg
Created attachment 243 [details] dmesg of successful suspend/resume
Using the image you pointed me to, I didn't see any problems - no oops in dmesg (attached) and no change in top output. It must be a hardware difference - which reference board are you using?
(In reply to comment #12) > Using the image you pointed me to, I didn't see any problems - no oops in dmesg > (attached) and no change in top output. It must be a hardware difference - > which reference board are you using? Hi Tom, It's a B0 board. Another information is that, if I run top in X window, the Xorg cpu time is high, but if run it via ssh, it won't be high. Hi Wenhua, Could you check if the image you send to Tom has call trace for Xorg?
(In reply to comment #13) > (In reply to comment #12) > > Using the image you pointed me to, I didn't see any problems - no oops in dmesg > > (attached) and no change in top output. It must be a hardware difference - > > which reference board are you using? > > Hi Tom, > It's a B0 board. Another information is that, if I run top in X window, the > Xorg cpu time is high, but if run it via ssh, it won't be high. > > Hi Wenhua, > Could you check if the image you send to Tom has call trace for Xorg? Mine is also B0. I just tried again, running top in the terminal, no change before and after S3. Do you see a kernel oops like before? There isn't one here.
(In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #12) > > > Using the image you pointed me to, I didn't see any problems - no oops in dmesg > > > (attached) and no change in top output. It must be a hardware difference - > > > which reference board are you using? > > > > Hi Tom, > > It's a B0 board. Another information is that, if I run top in X window, the > > Xorg cpu time is high, but if run it via ssh, it won't be high. > > > > Hi Wenhua, > > Could you check if the image you send to Tom has call trace for Xorg? > Mine is also B0. I just tried again, running top in the terminal, no change > before and after S3. > Do you see a kernel oops like before? There isn't one here. Standby does not work on crownbay before. We find the issue just after standby is enabled. We still meet such issue with the image Wenhua mentioned.
Created attachment 245 [details] complete boot up log for crownbay standby
Could you try suspending and resuming without X and see if you get the kernel oops? Also, could you send the output of lspci -v, lsusb, and /proc/interrupts and could you tell me your BIOS and VBIOS versions? Also, can you tell me what hardware you have attached to the system and what kind of display you're using?
Created attachment 246 [details] lspci -v output on crownbay
Created attachment 247 [details] lsusb output of crownbay
(In reply to comment #17) > Could you try suspending and resuming without X and see if you get the kernel > oops? Without X, I could still see the kernel oops. > Also, could you send the output of lspci -v, lsusb, and /proc/interrupts and > could you tell me your BIOS and VBIOS versions? lscpi and lsusb outputs as attachment. /proc/interrupts outputs as below: ###### CPU0 CPU1 0: 295984 0 IO-APIC-edge timer 1: 4 0 IO-APIC-edge i8042 4: 13 0 IO-APIC-edge serial 9: 0 0 IO-APIC-fasteoi acpi 12: 7 0 IO-APIC-edge i8042 16: 404453 0 IO-APIC-fasteoi ehci_hcd:usb2, ohci_hcd:usb6, ohci_hcd:usb7, ohci_hcd:usb8, hda_intel, eth0, PowerVR 17: 2632 0 IO-APIC-fasteoi ahci 18: 0 0 IO-APIC-fasteoi pch-dma, i2c_eg20t, mmc0, mmc1, spi_topcliff_pch 19: 200008 0 IO-APIC-fasteoi pch-dma, ehci_hcd:usb1, ohci_hcd:usb3, ohci_hcd:usb4, ohci_hcd:usb5, pch_udc NMI: 0 0 Non-maskable interrupts LOC: 31868 173846 Local timer interrupts SPU: 0 0 Spurious interrupts PMI: 0 0 Performance monitoring interrupts IWI: 0 0 IRQ work interrupts RES: 2495 2907 Rescheduling interrupts CAL: 195 1930 Function call interrupts TLB: 29 35 TLB shootdowns ERR: 0 MIS: 0 ###### The Core Version of BIOS is "4.6.3.7" and Build date is "03/18/2011". The vBIOS version is "1816". > Also, can you tell me what hardware you have attached to the system and what > kind of display you're using? I do not attach extra devices to the board. The display is a LVDS panel.
BTW, we have the crownbay up now, ip address is 10.239.47.144. Maybe you could have a look into it if you could not reproduce the issue on your side. The machine is already run with suspend/resume. So you could ssh it and start a x11vnc session "x11vnc -display :0.0" and use vnc to connect it. Then you will find the high cpu time used by Xorg with "top".
Hi, I tried sshing to the crownbay box, but was unable to connect (output below). Anyway, when you did the suspend/resume without X, was that a case where X had already been started and you killed it, or was that a fresh boot that had never been in X? If you'd already started X, the emgd driver would still be loaded and could still be the culprit or not. So could you try a couple things - from a fresh boot, kill X and rmmod emgd (make sure no emgd in lsmod), then try and see if there's a kernel oops. Also it would be nice if you could try the same thing but with the minimal image for comparison. trz@elmorro:/usr/local/src/yocto$ ssh -l root 10.239.47.144 ERROR: Got error response: 91: 'request rejected or failed'. FATAL: failed to begin relaying via SOCKS. ssh_exchange_identification: Connection closed by remote host
(In reply to comment #22) > Hi, I tried sshing to the crownbay box, but was unable to connect (output > below). > > Anyway, when you did the suspend/resume without X, was that a case where X had > already been started and you killed it, or was that a fresh boot that had never > been in X? If you'd already started X, the emgd driver would still be loaded > and could still be the culprit or not. > > So could you try a couple things - from a fresh boot, kill X and rmmod emgd > (make sure no emgd in lsmod), then try and see if there's a kernel oops. Also > it would be nice if you could try the same thing but with the minimal image for > comparison. > > > > > trz@elmorro:/usr/local/src/yocto$ ssh -l root 10.239.47.144 > ERROR: Got error response: 91: 'request rejected or failed'. > FATAL: failed to begin relaying via SOCKS. > ssh_exchange_identification: Connection closed by remote host Hi Tom, I did two things on Crownbay as below: 1. Enter S3 model after kill X and remove emgd module, I didn't find kernel oops issue. 2. Install minimal image on Crownbay, but I could't enter Yocto after S3 operation, the display was black. Then I try to access Crownbay by ssh but connection refused.
(In reply to comment #23) > (In reply to comment #22) > > Hi, I tried sshing to the crownbay box, but was unable to connect (output > > below). > > > > Anyway, when you did the suspend/resume without X, was that a case where X had > > already been started and you killed it, or was that a fresh boot that had never > > been in X? If you'd already started X, the emgd driver would still be loaded > > and could still be the culprit or not. > > > > So could you try a couple things - from a fresh boot, kill X and rmmod emgd > > (make sure no emgd in lsmod), then try and see if there's a kernel oops. Also > > it would be nice if you could try the same thing but with the minimal image for > > comparison. > > > > > > > > > > trz@elmorro:/usr/local/src/yocto$ ssh -l root 10.239.47.144 > > ERROR: Got error response: 91: 'request rejected or failed'. > > FATAL: failed to begin relaying via SOCKS. > > ssh_exchange_identification: Connection closed by remote host > > Hi Tom, I did two things on Crownbay as below: > > 1. Enter S3 model after kill X and remove emgd module, I didn't find kernel > oops issue. > This seems to point to emgd, but can you do one other test to verify: try the same test using the crownbay-noemgd sato or sato-sdk image? Also, Jiajun mentioned my being able to access this over a serial connection - I will probably want to to reboot with some test kernels soon...
Hi Tom, I get the environment ready today. You could get serial connection by ssh on 10.239.47.20 with username "build". Password is "hello123". Then you could just type "minicom" to connect to the crownbay. BTW, I write a sleep.sh under /home/root/ on crownbay for auto suspend/resume. It uses /proc/acpi/alarm, which is a quite old interface for 2.6.21 kernel. Due to that, seems sometimes the script could work - auto alarm system and make it resume from S3, but sometimes it could not work.
BTW, the kernel oops is not related to Xorg I think. Wenhua did a mistake when he tried S3. I re-do it and still could find kernel oops after S3 even X and Xorg is removed. We have no chance to try no-emgd image since autobuilder is building a emgd image for no-emgd build also.
Reopen the bug since we still meet the issue on RPC B0 board.
(In reply to comment #27) > Reopen the bug since we still meet the issue on RPC B0 board. OK, I apparently have exactly the same B0 hardware, and am not able to see this. The only difference would be BIOS settings so could you please reset the BIOS to all defaults? I'll have to boot some custom kernels to try to isolate the problem to one of the drivers on IRQ18 - Jiajun mentioned he would set things up for that once testing was finished. Can you please do that and let me know when things are ready again? Thanks.
(In reply to comment #28) > (In reply to comment #27) > > Reopen the bug since we still meet the issue on RPC B0 board. > OK, I apparently have exactly the same B0 hardware, and am not able to see > this. The only difference would be BIOS settings so could you please reset the > BIOS to all defaults? > I'll have to boot some custom kernels to try to isolate the problem to one of > the drivers on IRQ18 - Jiajun mentioned he would set things up for that once > testing was finished. Can you please do that and let me know when things are > ready again? Thanks. I tried restore BIOS option before but has no difference for the issue. I am not in office today and may need to set up the environment for you tomorrow.
Hi Tom, I reconfigure the environment today against latest edison build. You could get serial connection by ssh on 10.239.47.24 with username "build". Password is "hello123". Then you could just type "minicom" to connect to the crownbay. And I have to enable the WOL option in BIOS then I could make the box auto resume from S3.
I was unable to reproduce the issue on my crownbay with the latest denzil poky and master meta-intel. I'll need to be able to access the remote crownbay that does show the problem and instrument and upload kernels to try, and be able to put the remote machine into sleep, and wakeup, and reboot. I'll also need it like that for an extended period of time i.e. all week. Can you please set that up next week so I can investigate further, thanks.
(In reply to comment #31) > I was unable to reproduce the issue on my crownbay with the latest denzil > poky and master meta-intel. I'll need to be able to access the remote > crownbay that does show the problem and instrument and upload kernels to > try, and be able to put the remote machine into sleep, and wakeup, and > reboot. I'll also need it like that for an extended period of time i.e. all > week. Can you please set that up next week so I can investigate further, > thanks. Hi Tom, I reconfigure the environment today against latest master build, with commit 12b4543ac9f54c0db0ee4a7ee546a71946a051f8. You could get serial connection by ssh on 10.239.47.206 with username "root". Password is "123456". Then you could just type "minicom" to connect to the crownbay. And I have to enable the WOL option in BIOS then I could make the box auto resume from S3. My suggestion is that you could start "x11vnc" and connect to the crownbay with vncviewer and make it into S3 to reproduce the bug.
(In reply to comment #32) > (In reply to comment #31) > > I was unable to reproduce the issue on my crownbay with the latest denzil > > poky and master meta-intel. > > I'll need to be able to access the remote > > crownbay that does show the problem and instrument and upload kernels to > > try, and be able to put the remote machine into sleep, and wakeup, and > > reboot. I'll also need it like that for an extended period of time i.e. all > > week. > > Can you please set that up next week so I can investigate further, > > thanks. > > Hi Tom, > I reconfigure the environment today against latest master build, with commit > 12b4543ac9f54c0db0ee4a7ee546a71946a051f8. You could get serial connection > by ssh on 10.239.47.206 with username "root". Password is "123456". > > Then you could just type "minicom" to connect to the crownbay. > > And I have to enable the WOL option in BIOS then I could make the box auto > resume from S3. > > My suggestion is that you could start "x11vnc" and connect to the crownbay > with vncviewer and make it into S3 to reproduce the bug. It seems the crownbay is not powered on - no prompt on minicom. How do I power it on remotely?
(In reply to comment #33) > (In reply to comment #32) > > (In reply to comment #31) > > > I was unable to reproduce the issue on my crownbay with the latest denzil > > > poky and master meta-intel. > > > > I'll need to be able to access the remote > > > crownbay that does show the problem and instrument and upload kernels to > > > try, and be able to put the remote machine into sleep, and wakeup, and > > > reboot. I'll also need it like that for an extended period of time i.e. all > > > week. > > > > Can you please set that up next week so I can investigate further, > > > thanks. > > > > Hi Tom, > > I reconfigure the environment today against latest master build, with commit > > 12b4543ac9f54c0db0ee4a7ee546a71946a051f8. You could get serial connection > > by ssh on 10.239.47.206 with username "root". Password is "123456". > > > > Then you could just type "minicom" to connect to the crownbay. > > > > And I have to enable the WOL option in BIOS then I could make the box auto > > resume from S3. > > > > My suggestion is that you could start "x11vnc" and connect to the crownbay > > with vncviewer and make it into S3 to reproduce the bug. > > It seems the crownbay is not powered on - no prompt on minicom. > > How do I power it on remotely? Now I can't even access the 10.239.47.206: trz@elmorro:~$ ssh -l root 10.239.47.206 ssh_exchange_identification: Connection closed by remote host
Just to note that these aren't actually identical systems, in fact the PRC system doesn't show the E660 model name and at least the microcode version is lower: root@crownbay:~# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 38 model name : Genuine Intel(R) CPU @ 1.50GHz stepping : 1 microcode : 0x104 cpu MHz : 1500.000 cache size : 512 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx est ssse3 cx16 xtpr pdcm movbe lahf_lm dts tpr_shadow vnmi bogomips : 2999.99 clflush size : 64 cache_alignment : 64 address sizes : 32 bits physical, 48 bits virtual power management: My system: root@crownbay:~# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 38 model name : Intel(R) Atom(TM) CPU E660 @ 1.30GHz stepping : 1 microcode : 0x105 cpu MHz : 600.000 cache size : 512 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm dts tpr_shadow vnmi bogomips : 2600.18 clflush size : 64 cache_alignment : 64 address sizes : 32 bits physical, 48 bits virtual power management: root@crownbay:~# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 38 model name : Genuine Intel(R) CPU @ 1.50GHz stepping : 1 microcode : 0x104 cpu MHz : 1500.000 cache size : 512 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx est ssse3 cx16 xtpr pdcm movbe lahf_lm dts tpr_shadow vnmi bogomips : 2999.99 clflush size : 64 cache_alignment : 64 address sizes : 32 bits physical, 48 bits virtual power management:
(In reply to comment #35) > Just to note that these aren't actually identical systems, in fact the PRC > system doesn't show the E660 model name and at least the microcode version > is lower: > > root@crownbay:~# cat /proc/cpuinfo > processor : 0 > vendor_id : GenuineIntel > cpu family : 6 > model : 38 > model name : Genuine Intel(R) CPU @ 1.50GHz > stepping : 1 > microcode : 0x104 > cpu MHz : 1500.000 > cache size : 512 KB > physical id : 0 > siblings : 2 > core id : 0 > cpu cores : 1 > apicid : 0 > initial apicid : 0 > fdiv_bug : no > hlt_bug : no > f00f_bug : no > coma_bug : no > fpu : yes > fpu_exception : yes > cpuid level : 10 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca > cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht pbe nx lm constant_tsc > arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx est ssse3 > cx16 xtpr pdcm movbe lahf_lm dts tpr_shadow vnmi > bogomips : 2999.99 > clflush size : 64 > cache_alignment : 64 > address sizes : 32 bits physical, 48 bits virtual > power management: > > > My system: > > root@crownbay:~# cat /proc/cpuinfo > processor : 0 > vendor_id : GenuineIntel > cpu family : 6 > model : 38 > model name : Intel(R) Atom(TM) CPU E660 @ 1.30GHz > stepping : 1 > microcode : 0x105 > cpu MHz : 600.000 > cache size : 512 KB > physical id : 0 > siblings : 2 > core id : 0 > cpu cores : 1 > apicid : 0 > initial apicid : 0 > fdiv_bug : no > hlt_bug : no > f00f_bug : no > coma_bug : no > fpu : yes > fpu_exception : yes > cpuid level : 10 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca > cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc > arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 > cx16 xtpr pdcm movbe lahf_lm dts tpr_shadow vnmi > bogomips : 2600.18 > clflush size : 64 > cache_alignment : 64 > address sizes : 32 bits physical, 48 bits virtual > power management: > Note that the below should be ignored - it's not part of my system - copy and paste error... > root@crownbay:~# cat /proc/cpuinfo > processor : 0 > vendor_id : GenuineIntel > cpu family : 6 > model : 38 > model name : Genuine Intel(R) CPU @ 1.50GHz > stepping : 1 > microcode : 0x104 > cpu MHz : 1500.000 > cache size : 512 KB > physical id : 0 > siblings : 2 > core id : 0 > cpu cores : 1 > apicid : 0 > initial apicid : 0 > fdiv_bug : no > hlt_bug : no > f00f_bug : no > coma_bug : no > fpu : yes > fpu_exception : yes > cpuid level : 10 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca > cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht pbe nx lm constant_tsc > arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx est ssse3 > cx16 xtpr pdcm movbe lahf_lm dts tpr_shadow vnmi > bogomips : 2999.99 > clflush size : 64 > cache_alignment : 64 > address sizes : 32 bits physical, 48 bits virtual > power management:
I'll be getting a new crownbay system in the next day or so, which will allow me to either reproduce this locally or see that it works ok just as it does on my box.
Just got my new hardware a moment ago, and tried a quick 'echo mem > /sys/power/state' and resume - no oops or large Xorg CPU usage after standby, so I suspect PRC hardware. I'll do some more verification and add more details later, but for now am deferring this to 1.3.
After doing some more testing, many repetitions show no kernel oops and normal Xorg CPU usage (about 10%) after resume. dmesg output of successful suspend/resume on this second successful system attached. Some more information on the new system: Tunnel Creek Version 02 (B1 Stepping) PUNIT Build Date May 24 2011 BIOS Core version 4.6.3.7 Build Date 8/24/11 vBIOS version 2032 cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 38 model name : Intel(R) Atom(TM) CPU E660 @ 1.30GHz stepping : 1 microcode : 0x105 cpu MHz : 600.000 cache size : 512 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm dts tpr_shadow vnmi bogomips : 2600.44 clflush size : 64 cache_alignment : 64 address sizes : 32 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 38 model name : Intel(R) Atom(TM) CPU E660 @ 1.30GHz stepping : 1 microcode : 0x105 cpu MHz : 600.000 cache size : 512 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 1 apicid : 1 initial apicid : 1 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm dts tpr_shadow vnmi bogomips : 2599.94 clflush size : 64 cache_alignment : 64 address sizes : 32 bits physical, 48 bits virtual power management:
Created attachment 596 [details] output of suspend/resume on second different successful system
The difference between the systems that show the problem and the systems that don't seem to be in the microcode. The systems that are broken all have: microcode : 0x104 While the systems that work fine all have: microcode : 0x105 So please update your microcode so we're all on the same page.
I reproduced this in branch danny, commit: 86c9aa8081f107420cd3763d0566d779daddc2b1 image: core-image-sato-sdk-crownbay
This is the same text as for Bug 2792 - X fails to start after standby on Crownbay - see that bug for attachments mentioned. Basically all is fine on an installed and updated system... 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 923 [details] cpuinfo I reproduced this on both danny and denzil. The images are both installed, not live images. My microcode is 0x105. branch: denzil commit: 846b7c388738f382e83576e77b705aa547c1dd9b branch: danny commit: 27af23e65f63b41962a7cfddba9e9372d5212396 See attached text file for CPU informations.
Note 1: Xorg takes 100% of one CPU, that is 50% of total Note 2: After issue occurs, as you can see in the attachement, one core has 1300 Mhz and the other 600 Mhz.
Note 3: Resume does not work when pressing keyboard or mouse buttons. I am using the power button to resume.
For reference: poky/danny: commit 27af23e65f63b41962a7cfddba9e9372d5212396 meta-intel/master: commit 62aa4ca25a943c864838b2910c5b506cca0c9323 I also use the power button to resume.
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.
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].
Beacuse WOL could resolve the standby resume bug, maby there are other BIOS settings that could cause this. I will attach my BIOS settings and you can compare them to yours.
This issue is present in danny for crownbay 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 and consumes more than 50% of CPU) on noemgd image for denzil 1.2.2: 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.
This is older hardware, we have not heard of any issues with current hardware