From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:59444) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QLzRE-0003XM-EX for qemu-devel@nongnu.org; Mon, 16 May 2011 11:10:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QLzRC-0005ne-Ul for qemu-devel@nongnu.org; Mon, 16 May 2011 11:10:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:30714) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QLzRC-0005mV-MH for qemu-devel@nongnu.org; Mon, 16 May 2011 11:10:26 -0400 Message-ID: <4DD13EFF.80000@redhat.com> Date: Mon, 16 May 2011 17:13:03 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <1288876539-8300-1-git-send-email-kwolf@redhat.com> <1288876539-8300-4-git-send-email-kwolf@redhat.com> <20110516111926.GA7928@elie> In-Reply-To: <20110516111926.GA7928@elie> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [regression] qemu-system-arm: segfault in lsi_do_command List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jonathan Nieder Cc: qemu@vger.kernel.org, Stefan Hajnoczi , qemu-devel@nongnu.org Hi Jonathan, Am 16.05.2011 13:23, schrieb Jonathan Nieder: > Hi, > > Kevin Wolf wrote: > >> This pulls the request completion for error cases from the caller to >> scsi_disk_emulate_command. This should not change semantics, but allows to >> reuse scsi_handle_write_error() for flushes in the next patch. > > Today I tried out qemu-system-arm for the first time. It's faster > than I expected; very neat. Unfortunately it segfaults. > > Reproducible with "master" (077030d11). Bisects to v0.14.0-rc0~489 > (scsi-disk: Complete failed requests in scsi_disk_emulate_command, > 2010-10-25). Your instructions seemed clear enough, so I tried to reproduce your problem. Now I have an ARM VM with a Debian installation that works just fine and I have no idea what to use it for. ;-) I also reviewed the patch that you mentioned and I can't find anything suspicious there. I'm afraid you'll have to bite the bullet and run it with some debugging code yourself (if it's really related to that patch, you'll want to enable DPRINTF in hw/scsi-disk.c as a first step) Kevin