From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59129) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THJMh-00018y-Sj for qemu-devel@nongnu.org; Thu, 27 Sep 2012 15:03:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1THJMd-00056U-8u for qemu-devel@nongnu.org; Thu, 27 Sep 2012 15:03:15 -0400 Received: from goliath.siemens.de ([192.35.17.28]:31691) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THJMc-00056H-UV for qemu-devel@nongnu.org; Thu, 27 Sep 2012 15:03:11 -0400 Message-ID: <5064A2E9.201@siemens.com> Date: Thu, 27 Sep 2012 21:03:05 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <20120927142751.28864.67471.reportbug@gimli.ponomarevs.fi> <50646F5F.7080703@msgid.tls.msk.ru> <50647E08.7050606@gmail.com> <506489CD.8080605@msgid.tls.msk.ru> <50649ABA.8020104@siemens.com> <50649E6D.4050102@msgid.tls.msk.ru> In-Reply-To: <50649E6D.4050102@msgid.tls.msk.ru> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Bug#688964: qemu-kvm: Fedora 17 guest hangs on boot with soft lockup in udevd List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Tokarev Cc: "Michael S. Tsirkin" , Gerd Hoffmann , "688964@bugs.debian.org" <688964@bugs.debian.org>, Nikolai Kondrashov , qemu-devel On 2012-09-27 20:43, Michael Tokarev wrote: > On 27.09.2012 22:28, Jan Kiszka wrote: > [] >>> --- a/hw/intel-hda.c >>> +++ b/hw/intel-hda.c >>> @@ -1107,6 +1107,9 @@ static void intel_hda_reset(DeviceState *dev) >>> DeviceState *qdev; >>> HDACodecDevice *cdev; >>> >>> + if (d->msi) { >>> + msi_reset(&d->pci); >>> + } >>> intel_hda_regs_reset(d); >>> d->wall_base_ns = qemu_get_clock_ns(vm_clock); >>> >>> which is exactly about this hda thing. I'm CC'ing relevant >>> people here. >> >> I suppose we are resetting the MSI configuration also in cases here >> where only the HDA internals are supposed to be reset (when called from >> intel_hda_set_g_ctl). > > Hmm. I was looking at this code already (but i don't know the machinery > anyway). Here it is (I addedd two printfs in obvious places): > > in intel_hda_reset > calling intel_hda_reset from intel_hda_set_g_ctl > in intel_hda_reset > (at this time it hangs in guest). > > The following patch fixes it. Is it correct? :) > It looks ok to me. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux