From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MgefS-0002x0-Nx for qemu-devel@nongnu.org; Thu, 27 Aug 2009 09:05:30 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MgefN-0002u3-7V for qemu-devel@nongnu.org; Thu, 27 Aug 2009 09:05:30 -0400 Received: from [199.232.76.173] (port=57505 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MgefM-0002tY-UZ for qemu-devel@nongnu.org; Thu, 27 Aug 2009 09:05:25 -0400 Received: from os.inf.tu-dresden.de ([141.76.48.99]:52916) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MgefM-000814-7m for qemu-devel@nongnu.org; Thu, 27 Aug 2009 09:05:24 -0400 Received: from erwin.inf.tu-dresden.de ([141.76.48.80] helo=chrom.inf.tu-dresden.de) by os.inf.tu-dresden.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) id 1MgefK-0002Pp-ST for qemu-devel@nongnu.org; Thu, 27 Aug 2009 15:05:22 +0200 Received: from kauer by chrom.inf.tu-dresden.de with local (Exim 4.69) (envelope-from ) id 1MgeiB-0002Up-SJ for qemu-devel@nongnu.org; Thu, 27 Aug 2009 15:08:19 +0200 Date: Thu, 27 Aug 2009 15:08:19 +0200 From: Bernhard Kauer Message-ID: <20090827130819.GB9586@chrom.inf.tu-dresden.de> References: <20090715105043.GA26311@chrom.inf.tu-dresden.de> <20090827111803.GA7329@ramdisk> <20090827123330.GO30093@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090827123330.GO30093@redhat.com> Subject: [Qemu-devel] [PATCH] Re: RTC polling mode broken List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Thu, Aug 27, 2009 at 03:33:30PM +0300, Gleb Natapov wrote: > On Thu, Aug 27, 2009 at 01:18:03PM +0200, Bernhard Kauer wrote: > > Suppose I have some software that does not run with Qemu > > and I have done the following steps: > > > > 1. found that it is bug in Qemu and not in my software > > 2. produced a patch that fixed the problem for my test-case > > 3. send the patch with an explanation to the mailinglist > > 4. waited 6 weeks for comments or inclusion in Qemu > > > > Now what should I do, to get the bug fixed? > > > Resend the patch? (no need to what for 6 week to do that BTW) How often? Bernhard > > On Wed, Jul 15, 2009 at 12:50:43PM +0200, Bernhard Kauer wrote: > > > The RTC emulation does not set the IRQ flags independent of the IRQ enable bits. > > > > > > The original MC146818A datasheet from 1984 notes: > > > "flag bits in Register C [...] are set independent of the > > > state of the corresponding enable bits in Register B" > > > Similar sections can be found in newer documentation e.g. in rtc82885. > > > > > > Qemu and Bochs set the IRQ flags only if they are enabled, > > > which breaks drivers polling on them. > > > > > > The following patch corrects this for the update-ended-flag in Qemu only. > > > It currently does not fix the handling of the other flags. > > > > > > > > > Signed-off-by: Bernhard Kauer > > > > > > > > > diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c > > > index 2022548..2b040a7 100644 > > > --- a/hw/mc146818rtc.c > > > +++ b/hw/mc146818rtc.c > > > @@ -421,9 +421,10 @@ static void rtc_update_second2(void *opaque) > > > } > > > > > > /* update ended interrupt */ > > > + s->cmos_data[RTC_REG_C] |= REG_C_UF; > > > if (s->cmos_data[RTC_REG_B] & REG_B_UIE) { > > > - s->cmos_data[RTC_REG_C] |= 0x90; > > > - rtc_irq_raise(s->irq); > > > + s->cmos_data[RTC_REG_C] |= REG_C_IRQF; > > > + rtc_irq_raise(s->irq); > > > } > > > > > > /* clear update in progress bit */ > >