From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mgeqq-0004bJ-Rg for qemu-devel@nongnu.org; Thu, 27 Aug 2009 09:17:17 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mgeqk-0004XZ-8T for qemu-devel@nongnu.org; Thu, 27 Aug 2009 09:17:14 -0400 Received: from [199.232.76.173] (port=48988 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mgeqj-0004XB-WC for qemu-devel@nongnu.org; Thu, 27 Aug 2009 09:17:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:12685) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mgeqj-0001rg-Ef for qemu-devel@nongnu.org; Thu, 27 Aug 2009 09:17:09 -0400 Date: Thu, 27 Aug 2009 16:17:06 +0300 From: Gleb Natapov Subject: Re: [Qemu-devel] [PATCH] Re: RTC polling mode broken Message-ID: <20090827131706.GP30093@redhat.com> References: <20090715105043.GA26311@chrom.inf.tu-dresden.de> <20090827111803.GA7329@ramdisk> <20090827123330.GO30093@redhat.com> <20090827130819.GB9586@chrom.inf.tu-dresden.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090827130819.GB9586@chrom.inf.tu-dresden.de> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Bernhard Kauer Cc: qemu-devel@nongnu.org On Thu, Aug 27, 2009 at 03:08:19PM +0200, Bernhard Kauer wrote: > 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? > > Once a week till maintainers notice :) > > > > 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 */ > > > > -- Gleb.