[SeaBIOS] [Qemu-devel] Regression: more 0.12 regression (SeaBIOS related?)

[Kevin O'Connor]

On Wed, Mar 10, 2010 at 11:49:48AM +0800, Roy Tam wrote:
> 2010/3/10 Kevin O'Connor <kevin at koconnor.net>:
> > SeaBIOS has a wealth of debugging information that could help solve
> > these issues.
> 
> Tried this this BIOS and 2 debug logs generated.
> seabios-debug.log is booting fdos0138.img and closes QEMU after boots to prompt.
> seabios-debug-2.log is booting fdos0138.img and type something and
> Illegal Instruction occurred.

I don't see an "Illegal Instruction" message.  Instead, I see the
keyboard just not working.  What qemu version and what command line
did you use?

I've tracked down why keys are lost on SeaBIOS and not lost on Bochs
BIOS.  The fdos0138.img code is taking over the irq handler for the
ps2 port hardware irq.  When the irq fires, it reads the ps2 port for
the key data and then calls the bios irq handler assuming it will
reread the key and process it.  However, SeaBIOS reads the ps2 port
status indicator and finds that there is no data pending (because the
key was already read by the fdos0138.img irq handler).

Bochs BIOS just reads the data from the ps2 port and assumes it is for
the keyboard.  SeaBIOS verifies the data being read and wont process
random data from the port.

What the fdos0138.img image is doing is broken - once it reads the key
from the ps2 port, nothing stops a new key from being read the next
time something reads from the port.  Indeed, although the keyboard
works in qemu-0.11 for fdos0138.img, if one types fast they'll see
duplicate and lost keys.

> >> http://www.drdosprojects.de/cgi-bin/download.cgi/d090723b.zip

This image fails in the same way on both qemu-0.11 and qemu-0.12, so I
don't think it's a seabios issue.

-Kevin