684 2011-01-28 01:54:19 +0000 On qemuarm, the command 'poweroff/shutdown' can't close the qemu completely and exit to host console with Laverne build 20110121 2014-11-12 07:20:19 +0000 1 1 7 Build System, Metadata & Runtime OE-Core core 1.3 x86 Multiple RESOLVED WONTFIX http://bugzilla.pokylinux.org/show_bug.cgi?id=100 (Scheduled) Medium normal 1.7 1 liangliang.wang Qi.Chen ada-mihaela.solcan alexandru.c.georgescu amy.fong corneliux.stoicescu dvhart jessica.zhang jiajun.xu liang.li2 liangliang.wang liezhi.yang meta.mr.watcher meta.watcher richard.purdie sgw song.liu venkatarg yi.zhao yi.zhao --- --- Don't know oldest_to_newest 11563 0 liangliang.wang 2011-01-28 01:54:19 +0000 Testing Environment =============================== Host: qemuarm sato/sdk Kernel: Image location: http://autobuilder.pokylinux.org/nightly/20110121-1/qemu/qemuarm/ Steps =============================== 1. Boot up the qemuarm with sato/sdk image 2. Open a Terminal and run 'poweroff/shutdown -h now' Observed Result =============================== 1. The command 'poweroff/shutdown' can't close the qemu completely and exit to host console. 2. The 'Shutdown' icon on desktop can close the qemu completely and exit to host console. 11570 1 jiajun.xu 2011-01-28 05:50:11 +0000 Pls. be noted that the bug is for laverne build (20110121), not for master. 11665 2 sgw 2011-02-02 08:30:37 +0000 This is related to bug 100, and shutdown still needs to be addressed for Qemuarm which may require kernel or qemu changes. 12260 3 bruce.ashfield 2011-03-03 17:54:03 +0000 I put this as an enhancement, since this is actually consistent with the hardware behaviour! 13488 4 bruce.ashfield 2011-04-28 19:22:27 +0000 There are no plans to fix this, since it is behaving consistent with the hardware, it's a low value fix and definitely not needed for 1.0.1, so moving out the milestone on this. 17681 5 richard.purdie 2011-12-15 15:20:38 +0000 I think this can be closed as WONTFIX. We can make these systems halt at reboot and that's about as good as it can get and is consistent with the real hardware they emulate. 17682 6 richard.purdie 2011-12-15 15:21:31 +0000 Actually, can we make the poweroff/shutdown commands reboot these machines? Is there some way we can indicate to those commands to reboot? 17701 7 bruce.ashfield 2011-12-16 07:13:24 +0000 Josh had a suggestion for just mapping the poweroff/shutdown to reboot (both command line and sato) and it met with luke warm comments. I support the mapping, but others who probably didn't realize that even the hardware wouldn't support that, proposed fixing the problem. Which with a lot of digging we could do, but isn't a great use of time or value add. So if we want to just go ahead with mapping these commands, I have no issue with it. 17785 8 bruce.ashfield 2011-12-21 09:05:52 +0000 Hmm. I take that back, I was running the sysroot git. > which git /home/bruce/poky/build/tmp/sysroots/x86_64-linux/usr/bin/git yow-bashfiel-l1 [/home/bruc...8-r2/linux]> git --version git version 1.7.7 I'll check to see if for some reason the host git is being run by the kgit* scripts. 20937 9 jessica.zhang 2012-05-01 16:30:06 +0000 Any update from last comments? 20969 10 bruce.ashfield 2012-05-01 21:48:46 +0000 The last comment was from the wrong bug. There still are no plans to fix this, since we match hardware. If we update to a new emulated platform (i.e. the vexpress), we can fix this in the kernel. If we want to map the buttons to different commands, that's another question and someone that works on sato would want to do that. 21388 11 dvhart 2012-05-16 21:37:27 +0000 Bruce, moved to 1.3 M2, can you please provide an Estimate? 21391 12 bruce.ashfield 2012-05-16 22:05:40 +0000 10d days is the estimate for updating the BSP. 23182 13 bruce.ashfield 2012-07-18 01:41:48 +0000 Moving this to future. The qemuarm A9+ BSPs that are supported out of the yocto version of qemu do not support disk boot, and hence are not valid options. For yocto 1.3+ we can update the machine and resolve this issue, but fixing it on the existing machine is very low value for the time it will take. 26347 14 corneliux.stoicescu 2012-10-08 15:43:45 +0000 Reproduced on branch "danny": commit 86c9aa8081f107420cd3763d0566d779daddc2b1 Date: Wed Oct 3 11:01:51 2012 -0700 Last message from console: "System halted" 26908 15 sgw 2012-10-25 14:56:37 +0000 *** Bug 3335 has been marked as a duplicate of this bug. *** 40171 16 ada-mihaela.solcan 2014-02-04 09:33:06 +0000 Reproduced on master: Commit 1a9226f140f578f11696abf1a3c989fae1d4c14a Date: Thu Jan 23 12:10:01 2014 +0000 Host: Ubuntu 13.10 & Fedora 20 Last message from console: "System halted" This issue does not reproduce with the previous commit: e4c23f7bcb79072ea6028fbdf8f3f0dc17a63371 from Jan 14 40172 17 alexandru.c.georgescu 2014-02-04 09:38:04 +0000 Actually, this happens with NFS and with an *.ext3 image, like: http://autobuilder.yoctoproject.org/pub/nightly/20140123-3/machines/qemu/qemuarm/core-image-sato-qemuarm.ext3 46805 18 richard.purdie 2014-11-06 15:57:08 +0000 Since this matches the hardware and has low value, marking as WONTFIX (or really CANTFIX). 46932 19 alexandru.c.georgescu 2014-11-12 07:20:19 +0000 Adding Yi. Yi, I think we can keep the test case but stop attaching this bug to our qemuarm test runs. Also, please update the test case by attaching the bug link and also the test case should reflect the bug's resolution.