From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by mail.openembedded.org (Postfix) with ESMTP id A6AE2605B3 for ; Wed, 2 Dec 2015 10:28:18 +0000 (UTC) Received: from ALA-HCB.corp.ad.wrs.com (ala-hcb.corp.ad.wrs.com [147.11.189.41]) by mail.windriver.com (8.15.2/8.15.1) with ESMTPS id tB2ASIwT010510 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Dec 2015 02:28:18 -0800 (PST) Received: from [128.224.162.159] (128.224.162.159) by ALA-HCB.corp.ad.wrs.com (147.11.189.41) with Microsoft SMTP Server id 14.3.248.2; Wed, 2 Dec 2015 02:28:18 -0800 Message-ID: <565EC7BE.6060105@windriver.com> Date: Wed, 2 Dec 2015 18:28:14 +0800 From: Hongxu Jia User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: "Burton, Ross" References: <8e3c76d86f19c59b63908de6d7d9c2cc24858858.1449032673.git.hongxu.jia@windriver.com> <565EBF04.6050509@windriver.com> In-Reply-To: Cc: OE-core Subject: Re: [PATCH 1/1] python: gcc optimization level 2 X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2015 10:28:20 -0000 Content-Type: multipart/alternative; boundary="------------050808080204020408060809" --------------050808080204020408060809 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit On 12/02/2015 05:57 PM, Burton, Ross wrote: > > On 2 December 2015 at 09:51, Hongxu Jia > wrote: > > The root cause is the qemu didn't support gcc optimization level 3 > very well. > > > Oh, so the problem only appears in qemu if you enable tuning that is > known to be broken in qemu? Yes, since I tested qemux86/qemux86-64 with default tune, and everything is ok. > I don't think we should apply the Python workaround to oe-core as > everyone will suffer for a configuration that is known to be broken > (and isn't enabled in oe-core). Trace the issue costs a lot of time, the original failure was invoking 'smart update' in qemu, and found out the python md5/sha checksum output incorrect, and then found out qemu86-64 with corei7-64 did not support gcc optimization level 3 '-O3' very well [YOCTO #8748] BTW, boot the same image with virtualbox, everything is ok //Hongxu > > Ross --------------050808080204020408060809 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit
On 12/02/2015 05:57 PM, Burton, Ross wrote:

On 2 December 2015 at 09:51, Hongxu Jia <hongxu.jia@windriver.com> wrote:
The root cause is the qemu didn't support gcc optimization level 3 very well.

Oh, so the problem only appears in qemu if you enable tuning that is known to be broken in qemu? 

Yes, since I tested qemux86/qemux86-64 with default tune, and everything is ok.

I don't think we should apply the Python workaround to oe-core as everyone will suffer for a configuration that is known to be broken (and isn't enabled in oe-core).

Trace the issue costs a lot of time,  the original failure was invoking
'smart update' in qemu, and found out the python md5/sha checksum
output incorrect, and then found out qemu86-64 with corei7-64 did
not support gcc optimization level 3 '-O3' very well [YOCTO #8748]

BTW, boot the same image with virtualbox, everything is ok

//Hongxu


Ross

--------------050808080204020408060809--