Bug 684

Summary:	On qemuarm, the command 'poweroff/shutdown' can't close the qemu completely and exit to host console with Laverne build 20110121
Product:	[Build System, Metadata & Runtime] OE-Core	Reporter:	Liang Wang <liangliang.wang>
Component:	core	Assignee:	Chen Qi <Qi.Chen>
Status:	RESOLVED WONTFIX	QA Contact:	Yi Zhao <yi.zhao>
Severity:	normal
Priority:	Medium	CC:	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
Version:	1.3
Target Milestone:	1.7
Hardware:	x86
OS:	Multiple
See Also:	http://bugzilla.pokylinux.org/show_bug.cgi?id=100
Whiteboard:	(Scheduled)
OS type for building Yocto:	---	Type of Regression:	---
Verified:		Documentation change:	Don't know

Description Liang Wang 2011-01-28 01:54:19 UTC

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.

Comment 1 Jiajun Xu 2011-01-28 05:50:11 UTC

Pls. be noted that the bug is for laverne build (20110121), not for master.

Comment 2 Saul Wold 2011-02-02 08:30:37 UTC

This is related to bug 100, and shutdown still needs to be addressed for Qemuarm which may require kernel or qemu changes.

Comment 3 Bruce Ashfield 2011-03-03 17:54:03 UTC

I put this as an enhancement, since this is actually consistent with the hardware behaviour!

Comment 4 Bruce Ashfield 2011-04-28 19:22:27 UTC

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.

Comment 5 Richard Purdie 2011-12-15 15:20:38 UTC

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.

Comment 6 Richard Purdie 2011-12-15 15:21:31 UTC

Actually, can we make the poweroff/shutdown commands reboot these machines? Is there some way we can indicate to those commands to reboot?

Comment 7 Bruce Ashfield 2011-12-16 07:13:24 UTC

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.

Comment 8 Bruce Ashfield 2011-12-21 09:05:52 UTC

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.

Comment 9 Jessica 2012-05-01 16:30:06 UTC

Any update from last comments?

Comment 10 Bruce Ashfield 2012-05-01 21:48:46 UTC

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.

Comment 11 Darren Hart 2012-05-16 21:37:27 UTC

Bruce, moved to 1.3 M2, can you please provide an Estimate?

Comment 12 Bruce Ashfield 2012-05-16 22:05:40 UTC

10d days is the estimate for updating the BSP.

Comment 13 Bruce Ashfield 2012-07-18 01:41:48 UTC

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.

Comment 14 Stoicescu Cornel 2012-10-08 15:43:45 UTC

Reproduced on branch "danny":
commit 86c9aa8081f107420cd3763d0566d779daddc2b1
Date:   Wed Oct 3 11:01:51 2012 -0700

Last message from console: "System halted"

Comment 15 Saul Wold 2012-10-25 14:56:37 UTC

*** Bug 3335 has been marked as a duplicate of this bug. ***

Comment 16 Ada Solcan 2014-02-04 09:33:06 UTC

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

Comment 17 Alexandru Georgescu 2014-02-04 09:38:04 UTC

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

Comment 18 Richard Purdie 2014-11-06 15:57:08 UTC

Since this matches the hardware and has low value, marking as WONTFIX (or really CANTFIX).

Comment 19 Alexandru Georgescu 2014-11-12 07:20:19 UTC

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.