From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MlM56-0006CG-T0 for qemu-devel@nongnu.org; Wed, 09 Sep 2009 08:15:24 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MlM51-000694-77 for qemu-devel@nongnu.org; Wed, 09 Sep 2009 08:15:23 -0400 Received: from [199.232.76.173] (port=51204 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MlM50-00068x-Ry for qemu-devel@nongnu.org; Wed, 09 Sep 2009 08:15:18 -0400 Received: from os.inf.tu-dresden.de ([141.76.48.99]:53193) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MlM4y-0006SJ-H1 for qemu-devel@nongnu.org; Wed, 09 Sep 2009 08:15:17 -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 1MlM4t-0007Xy-I1 for qemu-devel@nongnu.org; Wed, 09 Sep 2009 14:15:11 +0200 Received: from kauer by chrom.inf.tu-dresden.de with local (Exim 4.69) (envelope-from ) id 1MlM7t-0007h6-BR for qemu-devel@nongnu.org; Wed, 09 Sep 2009 14:18:17 +0200 Date: Wed, 9 Sep 2009 14:18:17 +0200 From: Bernhard Kauer Subject: [Qemu-devel] [PATCH] [RESEND2] Qemu unmaintained? Message-ID: <20090909121817.GA21997@chrom.inf.tu-dresden.de> References: <20090902074905.GB25711@chrom.inf.tu-dresden.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090902074905.GB25711@chrom.inf.tu-dresden.de> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Its wednesday again, time to resend a patch to the list. Until today the following happened in this endless story: 1. I wrote an RTC driver according to the manual which works on real hardware but not on Qemu. 2. I traced the bug back to the first public version of Bochs. Its seems to be also present in all derived version: Qemu, KVM, Xen, VBox... 3. I send a patch to the Qemu list at least 4 times. 4. I never got a single response to my patch. Thus I have to assume that device models in Qemu are unmaintained: further resending does not make any sense in this case. I still hope somebody will step up and take a stake in this story. Otherwise Qemu will be more and more unusable. For me and probably others. Greetings, Bernhard Kauer On Wed, Sep 02, 2009 at 09:49:05AM +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 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 */ > > >