Re: [Qemu-devel] unable to boot systemrescuecd with tcg only?

[Aurelien Jarno]

On Wed, Apr 17, 2013 at 09:37:54AM +0200, Richard Henderson wrote:
> On 2013-04-16 00:32, Aurelien Jarno wrote:
> >On Tue, Apr 16, 2013 at 12:03:10AM +0200, Aurelien Jarno wrote:
> >>On Tue, Apr 16, 2013 at 12:36:36AM +0300, Michael S. Tsirkin wrote:
> >>>On Mon, Apr 15, 2013 at 06:17:18PM +0200, Paolo Bonzini wrote:
> >>>>Il 15/04/2013 17:02, Paolo Bonzini ha scritto:
> >>>>>Il 15/04/2013 11:18, Michael S. Tsirkin ha scritto:
> >>>>>>On Mon, Apr 15, 2013 at 11:53:12AM +0300, Michael S. Tsirkin wrote:
> >>>>>>>Get system rescue CD version 2.8.0 here:
> >>>>>>>http://www.sysresccd.org/Sysresccd-versions
> >>>>>>>
> >>>>>>>Verify md5 checksum: 450305b2c3ac12d5c97ff849ca178586
> >>>>>>
> >>>>>>Note: tried version 2.1.0, that boots fine.
> >>>>>>Tried version 3.5.0, that hangs on boot
> >>>>>>(or maybe it's just too slow? gave up after 15 min).
> >>>>>>In all cases -enable-kvm makes it work fine.
> >>>>>
> >>>>>Reproduced it too (by chance :)) with Fedora 16.  Trying to bisect now.
> >>>>
> >>>>Hmm, no, must be a different thing.  It was in a "seemingly innocuous"
> >>>>patch at the top of my tree, and system rescue CD works for me.
> >>>
> >>>2.0.8?
> >>>
> >>>Hmm maybe the issue is I'm on a 32 bit host ...
> >>>
> >>
> >>It's an important information. With it I am able to reproduce the issue.
> >>
> >
> >I have bisected the issue to:
> >
> >| f437d0a3c24e471a855da33a086fe529e09a06af is the first bad commit
> >| commit f437d0a3c24e471a855da33a086fe529e09a06af
> >| Author: Richard Henderson <address@hidden>
> >| Date:   Tue Feb 19 21:06:31 2013 -0800
> >|
> >|     target-i386: Use movcond to implement shiftd.
> >|
> >|     With this being all straight-line code, it can get deleted
> >|     when the cc variables die.
> >|
> >|     Signed-off-by: Richard Henderson <address@hidden>
> >
> 
> Ah.  I'll see what I can do.  Downloading 350M might not be possible
> while I'm traveling though, so any help producing a reduced test
> case would be appreciated.
> 

I'll try to work on that. For now I have determined the problem is on
the gen_shiftd_rm_T1 side, the gen_shift_rm_T1 part is fine (at least
it's not the one triggering the issue).

-- 
Aurelien Jarno                          GPG: 1024D/F1BCDB73
address@hidden                 http://www.aurel32.net