From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NptVy-0006YA-VM for qemu-devel@nongnu.org; Thu, 11 Mar 2010 20:18:11 -0500 Received: from [199.232.76.173] (port=45326 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NptVy-0006Y0-MQ for qemu-devel@nongnu.org; Thu, 11 Mar 2010 20:18:10 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NptVx-0001zJ-A6 for qemu-devel@nongnu.org; Thu, 11 Mar 2010 20:18:10 -0500 Received: from mail-pw0-f45.google.com ([209.85.160.45]:52834) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NptVw-0001z0-IT for qemu-devel@nongnu.org; Thu, 11 Mar 2010 20:18:09 -0500 Received: by pwi9 with SMTP id 9so356846pwi.4 for ; Thu, 11 Mar 2010 17:18:03 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20100312005754.GA3327@morn.localdomain> References: <473191351003071804x62acae0bk3f967b6be1f22a54@mail.gmail.com> <20100310021220.GB29054@morn.localdomain> <473191351003091949j6f3fbf98jadc87405876db214@mail.gmail.com> <20100310045942.GC29054@morn.localdomain> <473191351003092124o382bddc8m80df4676c048ec0a@mail.gmail.com> <20100311030742.GA26752@morn.localdomain> <473191351003102342x1f25f281l77a3b325726a602c@mail.gmail.com> <20100312005754.GA3327@morn.localdomain> From: Roy Tam Date: Fri, 12 Mar 2010 09:17:43 +0800 Message-ID: <473191351003111717o48ef902ch2c4518a907415c8f@mail.gmail.com> Subject: Re: [Qemu-devel] Regression: more 0.12 regression (SeaBIOS related?) Content-Type: text/plain; charset=ISO-8859-1 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin O'Connor Cc: seabios@seabios.org, qemu-devel 2010/3/12 Kevin O'Connor : > On Thu, Mar 11, 2010 at 03:42:28PM +0800, Roy Tam wrote: >> Sorry I can't find documentation on this usage. But instead I have >> lots of old programs written with this usage. >> Using undocumented features from BIOS/DOS is very usual in that time. > > Can you confirm these other programs fail in the same way (no keyboard > input, and "ps2 irq but no data." messages in log when using > bios.bin-0.5.1-debug-20100228)? > >> > It's broken because it causes key presses to be lost and corrupted. >> > The ps2 port hardware just doesn't work the way that software is >> > trying to use it. >> > >> >> You said that "it causes key presses to be lost and corrupted" but I >> haven't heard any complain about this. >> Real BIOSes (Award BIOS, AMI BIOS, Phoenix BIOS) handle this usage >> very well and no key press are lost or corrupted. > > Under qemu-0.11 normal typing lead to lots of keyboard errors for me. > It's possible real hardware would be less susceptible to this error, > but there is nothing that a BIOS inside qemu can do to stop the > corruption. > >> Any key press should generate 4 IRQs, for example when I press [Tab] >> key, it should have IRQs like this: >> ps2: data f (status=1d) >> ps2: data f (status=1c) >> ps2: data 8f (status=1d) >> ps2: data 8f (status=1c) > > There is one irq on key press and one irq on key release. Your > debugging output is in a loop and you're reporting the same event > twice. > >> The following patch help people to see irq status and data change: > > The current SeaBIOS flow is effectively: > > // Read ps2 port status > u8 status = inb(PORT_PS2_STATUS); > if (!(status & I8042_STR_OBF)) > // No event in queue - nothing can be dequeued. > return; > // Event in queue - dequeue it > u8 data = inb(PORT_PS2_DATA); > // Process the event. > process_ps2byte(status, data); > > Your debugging patch is not correct becuase it performs the event > dequeue before the check to see if there is an event in the queue. > I don't care about it. As mentioned in OSDEV wiki ( http://wiki.osdev.org/PS2_Keyboard ): Note that if you repeatedly read the port 0x60 without waiting for another IRQ, you'll read the same byte again. That's the 'normal' behaviour of keyboard controller, [...]