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

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

[Roy Tam]

2010/3/8 Roy Tam <roytam@gmail.com>:
> 2010/3/8 Keen Shoes <keenshoes@yahoo.com.cn>:
>> Hi all,
>>
>> I found some regression bugs that seems relate to SeaBIOS and I hope
>> we can add back booting with Bochs BIOS in git so that we can further
>> testing that the bug is in SeaBIOS or in QEMU 0.12.
>>
>> ======
>>  Try test the bios.bin-0.5.0 (Morn.localdomain) of seabios homepage,  Or disable smbios will solve your problem.
>>    The bios.bin-0.5.0 is the only one version to boot my juniper router from Qemu 0.12.
>>    Also the bios.bin-0.5.0 (codemonkey.ws) shipped with qemu 0.12 doesn't work.
>>
>>    Now Kevin Conner and Gleb knew this problem and are working for the solution.
>>
>> Download from here.
>> http://linuxtogo.org/~kevin/SeaBIOS/
>>
>
> Tested, for my test cases are giving same result as mentioned before.
>
> add one more regression:
> - Windows NT 4.0 BSoD (STOP 0x3E) when booting to first stage setup from CD-ROM
> (tried both bios.bin-0.5.0 (Morn.localdomain) and latest seabios in git)
>

(resent to mail list)

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

[Alain Ribière]

[-- Attachment #1: Type: text/plain, Size: 640 bytes --]

Hello,

I'm reacting a bit later but I have a trouble with an old DOS OS from Digital Research called Concurrent DOS.
It worked fine till Qemu v0.11.1.
I tried it with a lot of versions from 0.12.0 to 1.0.1 and it boot correctly. But after a key pressed, I can't use the keyboard any more. The system is not freezed (there is a clock in the bottom side of the screen which is running) but I can't use the keyboard any more.
It worked also with 0.12.0-rc1 and the PC-BIOS. It seems that with Seabios it doesn't work any more but PC-BIOS is no longer supported by QEMU (from v0.12.0).

Do you know what can I do ?

Thanks,

Alain

[-- Attachment #2: Type: text/html, Size: 915 bytes --]

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

[Kevin O'Connor]

On Tue, Mar 06, 2012 at 09:00:55AM -0800, Alain Ribière wrote:
> Hello,
> 
> I'm reacting a bit later but I have a trouble with an old DOS OS from Digital Research called Concurrent DOS.
> It worked fine till Qemu v0.11.1.
> I tried it with a lot of versions from 0.12.0 to 1.0.1 and it boot correctly. But after a key pressed, I can't use the keyboard any more. The system is not freezed (there is a clock in the bottom side of the screen which is running) but I can't use the keyboard any more.
> It worked also with 0.12.0-rc1 and the PC-BIOS. It seems that with Seabios it doesn't work any more but PC-BIOS is no longer supported by QEMU (from v0.12.0).
> 
> Do you know what can I do ?

You can help debug the issue so it can be fixed in SeaBIOS.  Start
with producing a log from SeaBIOS by adding (on a recent qemu) the
following to the command-line:

-chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios

Also, if there is an image available for download, other developers
can take a look at it as well.

-Kevin

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

[Roy Tam]

Hi all,

I found some regression bugs that seems relate to SeaBIOS and I hope
we can add back booting with Bochs BIOS in git so that we can further
testing that the bug is in SeaBIOS or in QEMU 0.12.
Following list is the regression that I encountered and which works in 0.11.1:

- Windows NT 3.51/4.0 freezes when booting to first stage setup, after
switch screen to 80x50 text mode
- freeze after pressing Enter when booting PC/MS-DOS  1.10 - 1.25
- freeze when booting Enhanced DR-DOS 7.01.08 WIP (23.7.2009) (
http://www.drdosprojects.de/cgi-bin/download.cgi/d090723b.zip )
- can't type correctly in GW-BASIC from DOS 2.0 - 3.31
- keyboard input is ignored when booting Korean edition of MS-DOS 6.20
- can't type correctly in FreeDOS/V (Ver 0138,
http://homepage1.nifty.com/bible/dos/fdos0138.lzh ), getting Illegal
Instruction error when you type something in short period.
- after the termination of qbasic run session, you can't press a key
to go back to editor in "press a key to continue" prompt, you have to
type something not just "press a key". When I modify the program and
press Shift-F5 to start the program, after execution and then exit
qbasic, Shift key modifier still activating, instead of deactivated
after I release Shift key.

If you have another (seems to be SeaBIOS related) 0.12 regression,
please post it here.

Best regards,
Roy

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

[Jamie Lokier]

Roy Tam wrote:
> - can't type correctly in GW-BASIC from DOS 2.0 - 3.31
> - keyboard input is ignored when booting Korean edition of MS-DOS 6.20
> - can't type correctly in FreeDOS/V (Ver 0138,
> http://homepage1.nifty.com/bible/dos/fdos0138.lzh ), getting Illegal
> Instruction error when you type something in short period.
> - after the termination of qbasic run session, you can't press a key
> to go back to editor in "press a key to continue" prompt, you have to
> type something not just "press a key". When I modify the program and
> press Shift-F5 to start the program, after execution and then exit
> qbasic, Shift key modifier still activating, instead of deactivated
> after I release Shift key.

I think there was a change to one of the keyboard heuristics
to solve a problem with another DOS program.  That might
explain all these keyboard thingies.

-- Jamie

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

[Roy Tam]

2010/3/8 Jamie Lokier <jamie@shareable.org>:
> Roy Tam wrote:
>> - can't type correctly in GW-BASIC from DOS 2.0 - 3.31
>> - keyboard input is ignored when booting Korean edition of MS-DOS 6.20
>> - can't type correctly in FreeDOS/V (Ver 0138,
>> http://homepage1.nifty.com/bible/dos/fdos0138.lzh ), getting Illegal
>> Instruction error when you type something in short period.
>> - after the termination of qbasic run session, you can't press a key
>> to go back to editor in "press a key to continue" prompt, you have to
>> type something not just "press a key". When I modify the program and
>> press Shift-F5 to start the program, after execution and then exit
>> qbasic, Shift key modifier still activating, instead of deactivated
>> after I release Shift key.
>
> I think there was a change to one of the keyboard heuristics
> to solve a problem with another DOS program.  That might
> explain all these keyboard thingies.
>

seems so.

the following hack reenables QEMU/Bochs BIOS booting with -vga std
(for both pc and isapc):
--
diff --git a/hw/vga-isa.c b/hw/vga-isa.c
index 7937144..071134a 100644
--- a/hw/vga-isa.c
+++ b/hw/vga-isa.c
@@ -45,5 +45,8 @@ int isa_vga_init(void)
     vga_init_vbe(s);
     /* ROM BIOS */
     rom_add_vga(VGABIOS_FILENAME);
+#ifdef TARGET_I386
+    rom_add_file(VGABIOS_FILENAME,NULL,0xc0000);
+#endif
     return 0;
 }
diff --git a/hw/vga-pci.c b/hw/vga-pci.c
index eef78ed..f083110 100644
--- a/hw/vga-pci.c
+++ b/hw/vga-pci.c
@@ -109,6 +109,9 @@ static int pci_vga_initfn(PCIDevice *dev)
     vga_init_vbe(s);
      /* ROM BIOS */
      rom_add_vga(VGABIOS_FILENAME);
+#ifdef TARGET_I386
+     rom_add_file(VGABIOS_FILENAME,NULL,0xc0000);
+#endif
      return 0;
 }

--

and the STOP 0x3e when CD-ROM booting NT 4.0 seems to be QEMU issue(I
tested with latest git today).
for DOS-based NT installations, NT 4.0 still gets STOP 0x3e, and NT
3.51 still freezes after switching to 80x50 text mode.

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

[Roy Tam]

2010/3/8 Roy Tam <roytam@gmail.com>:
> the following hack reenables QEMU/Bochs BIOS booting with -vga std
> (for both pc and isapc):

a more complete hack, cirrus vga will work too:
---
diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
index 9f61a01..3a12eaa 100644
--- a/hw/cirrus_vga.c
+++ b/hw/cirrus_vga.c
@@ -3131,6 +3131,11 @@ void isa_cirrus_vga_init(void)
                                      &s->vga);
     vmstate_register(0, &vmstate_cirrus_vga, s);
     rom_add_vga(VGABIOS_CIRRUS_FILENAME);
+
+    /* XXX Bochs BIOS re-enable hack */
+#ifdef TARGET_I386
+    rom_add_file_fixed(VGABIOS_CIRRUS_FILENAME, 0xc0000);
+#endif
     /* XXX ISA-LFB support */
 }

@@ -3217,6 +3222,11 @@ static int pci_cirrus_vga_initfn(PCIDevice *dev)
 void pci_cirrus_vga_init(PCIBus *bus)
 {
     pci_create_simple(bus, -1, "cirrus-vga");
+
+    /* XXX Bochs BIOS re-enable hack */
+#ifdef TARGET_I386
+    rom_add_file_fixed(VGABIOS_CIRRUS_FILENAME, 0xc0000);
+#endif
 }

 static PCIDeviceInfo cirrus_vga_info = {
diff --git a/hw/vga-isa.c b/hw/vga-isa.c
index 7937144..5ef91a6 100644
--- a/hw/vga-isa.c
+++ b/hw/vga-isa.c
@@ -45,5 +45,10 @@ int isa_vga_init(void)
     vga_init_vbe(s);
     /* ROM BIOS */
     rom_add_vga(VGABIOS_FILENAME);
+
+    /* XXX Bochs BIOS re-enable hack */
+#ifdef TARGET_I386
+    rom_add_file_fixed(VGABIOS_FILENAME, 0xc0000);
+#endif
     return 0;
 }
diff --git a/hw/vga-pci.c b/hw/vga-pci.c
index eef78ed..105a277 100644
--- a/hw/vga-pci.c
+++ b/hw/vga-pci.c
@@ -109,6 +109,11 @@ static int pci_vga_initfn(PCIDevice *dev)
     vga_init_vbe(s);
      /* ROM BIOS */
      rom_add_vga(VGABIOS_FILENAME);
+
+    /* XXX Bochs BIOS re-enable hack */
+#ifdef TARGET_I386
+     rom_add_file_fixed(VGABIOS_FILENAME, 0xc0000);
+#endif
      return 0;
 }

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

[Roy Tam]

2010/3/8 Roy Tam <roytam@gmail.com>:
> 2010/3/8 Roy Tam <roytam@gmail.com>:
>> the following hack reenables QEMU/Bochs BIOS booting with -vga std
>> (for both pc and isapc):
>
> a more complete hack, cirrus vga will work too:

instead of hacking each vga source, adding new option seems better.
---
diff --git a/hw/pc.c b/hw/pc.c
index e50a488..d32ad85 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -53,6 +53,9 @@

 #define PC_MAX_BIOS_SIZE (4 * 1024 * 1024)

+#define VGABIOS_FILENAME "vgabios.bin"
+#define VGABIOS_CIRRUS_FILENAME "vgabios-cirrus.bin"
+
 /* Leave a chunk of memory at the top of RAM for the BIOS ACPI tables.  */
 #define ACPI_DATA_SIZE       0x10000
 #define BIOS_CFG_IOPORT 0x510
@@ -929,17 +932,26 @@ static void pc_init1(ram_addr_t ram_size,
         } else {
             isa_cirrus_vga_init();
         }
+        if (old_bios_support) {
+            rom_add_file_fixed(VGABIOS_CIRRUS_FILENAME, 0xc0000);
+        }
     } else if (vmsvga_enabled) {
         if (pci_enabled)
             pci_vmsvga_init(pci_bus);
         else
             fprintf(stderr, "%s: vmware_vga: no PCI bus\n", __FUNCTION__);
+        if (old_bios_support) {
+            rom_add_file_fixed(VGABIOS_FILENAME, 0xc0000);
+        }
     } else if (std_vga_enabled) {
         if (pci_enabled) {
             pci_vga_init(pci_bus, 0, 0);
         } else {
             isa_vga_init();
         }
+        if (old_bios_support) {
+            rom_add_file_fixed(VGABIOS_FILENAME, 0xc0000);
+        }
     }

     rtc_state = rtc_init(2000);
diff --git a/hw/pc.h b/hw/pc.h
index d54959a..d318ddd 100644
--- a/hw/pc.h
+++ b/hw/pc.h
@@ -91,6 +91,7 @@ void cmos_set_s3_resume(void);

 /* pc.c */
 extern int fd_bootchk;
+extern int old_bios_support;

 void ioport_set_a20(int enable);
 int ioport_get_a20(void);
diff --git a/qemu-options.hx b/qemu-options.hx
index fd50add..afe2545 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -769,6 +769,16 @@ slows down the IDE transfers).
 ETEXI

 #ifdef TARGET_I386
+DEF("old-bios", 0, QEMU_OPTION_old_bios,
+    "-old-bios       use it for Bochs/QEMU BIOS\n")
+#endif
+STEXI
+@item -old-bios
+@findex -old-bios
+Use it when combine with old Bochs/QEMU BIOS for debugging.
+ETEXI
+
+#ifdef TARGET_I386
 HXCOMM Deprecated by -rtc
 DEF("rtc-td-hack", 0, QEMU_OPTION_rtc_td_hack, "")
 #endif
diff --git a/vl.c b/vl.c
index d8328c7..0d7ec83 100644
--- a/vl.c
+++ b/vl.c
@@ -217,6 +217,7 @@ CharDriverState *virtcon_hds[MAX_VIRTIO_CONSOLES];
 #ifdef TARGET_I386
 int win2k_install_hack = 0;
 int rtc_td_hack = 0;
+int old_bios_support = 0;
 #endif
 int usb_enabled = 0;
 int singlestep = 0;
@@ -5180,6 +5181,9 @@ int main(int argc, char **argv, char **envp)
             case QEMU_OPTION_no_fd_bootchk:
                 fd_bootchk = 0;
                 break;
+            case QEMU_OPTION_old_bios:
+                old_bios_support = 1;
+                break;
 #endif
             case QEMU_OPTION_netdev:
                 if (net_client_parse(&qemu_netdev_opts, optarg) == -1) {

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

[Natalia Portillo]

*NeXTStep/OpenStep bootloader hangs (Darwin not tested but may be also).
*ScanDisk does not receive keypresses (any at all).
*Windows Me's DOS Microsoft Mouse driver hangs the machine.
*PS/2 mouse not working under Windows Me installation.
*Windows Me blue screens after installation.
A good couple of XFree86 versions do not work as expected with PS/2  
mouse (mouse moves randomly, clicks randomly or is dead at all),  
tested with all PS/2 protocol variants.
qemu-system-sparc64 does a segment violation if you enable Realtek  
RTL8139.

These of course do not have anything to do (but the scandisk one) with  
SeaBIOS, however I marked with * the ones that can be a BIOS conflict.

El 08/03/2010, a las 02:04, Roy Tam escribió:

> Hi all,
>
> I found some regression bugs that seems relate to SeaBIOS and I hope
> we can add back booting with Bochs BIOS in git so that we can further
> testing that the bug is in SeaBIOS or in QEMU 0.12.
> Following list is the regression that I encountered and which works  
> in 0.11.1:
>
> - Windows NT 3.51/4.0 freezes when booting to first stage setup, after
> switch screen to 80x50 text mode
> - freeze after pressing Enter when booting PC/MS-DOS  1.10 - 1.25
> - freeze when booting Enhanced DR-DOS 7.01.08 WIP (23.7.2009) (
> http://www.drdosprojects.de/cgi-bin/download.cgi/d090723b.zip )
> - can't type correctly in GW-BASIC from DOS 2.0 - 3.31
> - keyboard input is ignored when booting Korean edition of MS-DOS 6.20
> - can't type correctly in FreeDOS/V (Ver 0138,
> http://homepage1.nifty.com/bible/dos/fdos0138.lzh ), getting Illegal
> Instruction error when you type something in short period.
> - after the termination of qbasic run session, you can't press a key
> to go back to editor in "press a key to continue" prompt, you have to
> type something not just "press a key". When I modify the program and
> press Shift-F5 to start the program, after execution and then exit
> qbasic, Shift key modifier still activating, instead of deactivated
> after I release Shift key.
>
> If you have another (seems to be SeaBIOS related) 0.12 regression,
> please post it here.
>
> Best regards,
> Roy
>
>

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

[Natalia Portillo]

Sorry, rephrasing:

These of course do not have anything to do (but the scandisk one) with  
KEYBOARD, however I marked with * the ones that can be a BIOS conflict.

El 09/03/2010, a las 15:41, Natalia Portillo escribió:

> *NeXTStep/OpenStep bootloader hangs (Darwin not tested but may be  
> also).
> *ScanDisk does not receive keypresses (any at all).
> *Windows Me's DOS Microsoft Mouse driver hangs the machine.
> *PS/2 mouse not working under Windows Me installation.
> *Windows Me blue screens after installation.
> A good couple of XFree86 versions do not work as expected with PS/2  
> mouse (mouse moves randomly, clicks randomly or is dead at all),  
> tested with all PS/2 protocol variants.
> qemu-system-sparc64 does a segment violation if you enable Realtek  
> RTL8139.
>
> These of course do not have anything to do (but the scandisk one)  
> with SeaBIOS, however I marked with * the ones that can be a BIOS  
> conflict.
>
> El 08/03/2010, a las 02:04, Roy Tam escribió:
>
>> Hi all,
>>
>> I found some regression bugs that seems relate to SeaBIOS and I hope
>> we can add back booting with Bochs BIOS in git so that we can further
>> testing that the bug is in SeaBIOS or in QEMU 0.12.
>> Following list is the regression that I encountered and which works  
>> in 0.11.1:
>>
>> - Windows NT 3.51/4.0 freezes when booting to first stage setup,  
>> after
>> switch screen to 80x50 text mode
>> - freeze after pressing Enter when booting PC/MS-DOS  1.10 - 1.25
>> - freeze when booting Enhanced DR-DOS 7.01.08 WIP (23.7.2009) (
>> http://www.drdosprojects.de/cgi-bin/download.cgi/d090723b.zip )
>> - can't type correctly in GW-BASIC from DOS 2.0 - 3.31
>> - keyboard input is ignored when booting Korean edition of MS-DOS  
>> 6.20
>> - can't type correctly in FreeDOS/V (Ver 0138,
>> http://homepage1.nifty.com/bible/dos/fdos0138.lzh ), getting Illegal
>> Instruction error when you type something in short period.
>> - after the termination of qbasic run session, you can't press a key
>> to go back to editor in "press a key to continue" prompt, you have to
>> type something not just "press a key". When I modify the program and
>> press Shift-F5 to start the program, after execution and then exit
>> qbasic, Shift key modifier still activating, instead of deactivated
>> after I release Shift key.
>>
>> If you have another (seems to be SeaBIOS related) 0.12 regression,
>> please post it here.
>>
>> Best regards,
>> Roy
>>
>>
>
>
>

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

[Kevin O'Connor]

On Mon, Mar 08, 2010 at 10:04:57AM +0800, Roy Tam wrote:
> Hi all,
> 
> I found some regression bugs that seems relate to SeaBIOS and I hope
> we can add back booting with Bochs BIOS in git so that we can further
> testing that the bug is in SeaBIOS or in QEMU 0.12.
> Following list is the regression that I encountered and which works in 0.11.1:

Thanks for the report.

It would help quite a bit if you could gather some additional
debugging information from SeaBIOS.  The simplest way is to grab:

http://linuxtogo.org/~kevin/SeaBIOS/test/bios.bin-0.5.1-debug-20100228

and replace the standard bios.bin with this file.  Then launch qemu
with the additional parameter "-serial file:mylog".  Then forward the
"mylog" file back.

SeaBIOS has a wealth of debugging information that could help solve
these issues.

> http://www.drdosprojects.de/cgi-bin/download.cgi/d090723b.zip
[...]
> http://homepage1.nifty.com/bible/dos/fdos0138.lzh

I'll take a look.

-Kevin

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

[Roy Tam]

[-- Attachment #1: Type: text/plain, Size: 1283 bytes --]

2010/3/10 Kevin O'Connor <kevin@koconnor.net>:
> On Mon, Mar 08, 2010 at 10:04:57AM +0800, Roy Tam wrote:
>> Hi all,
>>
>> I found some regression bugs that seems relate to SeaBIOS and I hope
>> we can add back booting with Bochs BIOS in git so that we can further
>> testing that the bug is in SeaBIOS or in QEMU 0.12.
>> Following list is the regression that I encountered and which works in 0.11.1:
>
> Thanks for the report.
>
> It would help quite a bit if you could gather some additional
> debugging information from SeaBIOS.  The simplest way is to grab:
>
> http://linuxtogo.org/~kevin/SeaBIOS/test/bios.bin-0.5.1-debug-20100228
>
> and replace the standard bios.bin with this file.  Then launch qemu
> with the additional parameter "-serial file:mylog".  Then forward the
> "mylog" file back.
>
> 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.

>
>> http://www.drdosprojects.de/cgi-bin/download.cgi/d090723b.zip
> [...]
>> http://homepage1.nifty.com/bible/dos/fdos0138.lzh
>
> I'll take a look.
>
> -Kevin
>

[-- Attachment #2: seabios-debug.log --]
[-- Type: application/octet-stream, Size: 10583 bytes --]

Changing serial settings was 0/0 now 3/0
Start bios (version 0.5.1-20100228_144514-morn.localdomain)
enabling shadow ram
init ivt
init bda
Find memory size
Add to e820 map: 00000000 08000000 1
Add to e820 map: 00000000 00000000 1
Add to e820 map: fffc0000 00040000 2
Add to e820 map: 000a0000 00050000 -1
Add to e820 map: 0009f400 00000c00 2
Add to e820 map: 000f0000 00010000 2
Ram Size=0x08000000 (0x0000000000000000 high)
malloc setup
Add to e820 map: 07ff0000 00010000 2
init pic
init timer
tsc calibrate start=25006874 end=29865801 diff=4858927
CPU Mhz=2830
math cp init
qemu_cfg_present=1
Found 1 cpu(s) max supported 1 cpu(s)
pci setup
PIIX3/PIIX4 init: elcr=00 0c
PCI: bus=0 devfn=0x00: vendor_id=0x8086 device_id=0x1237
PCI: bus=0 devfn=0x08: vendor_id=0x8086 device_id=0x7000
PCI: bus=0 devfn=0x09: vendor_id=0x8086 device_id=0x7010
region 4: 0x0000c000
PCI: bus=0 devfn=0x0b: vendor_id=0x8086 device_id=0x7113
PCI: bus=0 devfn=0x10: vendor_id=0x1013 device_id=0x00b8
region 0: 0xf0000000
region 1: 0xf2000000
region 6: 0xf2010000
PCI: bus=0 devfn=0x18: vendor_id=0x8086 device_id=0x100e
region 0: 0xf2020000
region 1: 0x0000c040
init smm
init bios32
init PMM
init PNPBIOS table
init keyboard
init mouse
init PIR table
init MPTable
pmm_malloc zone=0x000f6204 handle=ffffffff size=32768 align=10 ret=0x07fe7fe0 (info=0x07feffe0)
pmm_malloc zone=0x000f61ec handle=ffffffff size=224 align=10 ret=0x000f7da0 (info=0x07fe7fc0)
pmm_malloc zone=0x000f61ec handle=ffffffff size=16 align=10 ret=0x000f7d90 (info=0x07fe7fa0)
pmm_free data=0x07fe7fe0 olddata=0x07feffe0 oldallocdata=0x07ff0000 info=0x07feffe0
MP table addr=0x000f7d90 MPC table addr=0x000f7da0 size=224
init SMBIOS tables
pmm_malloc zone=0x000f6204 handle=ffffffff size=32768 align=10 ret=0x07fdff80 (info=0x07fe7f80)
pmm_malloc zone=0x000f61ec handle=ffffffff size=31 align=10 ret=0x000f7d70 (info=0x07fdff60)
pmm_malloc zone=0x000f61e0 handle=ffffffff size=263 align=10 ret=0x07fffef0 (info=0x07fdff40)
SMBIOS ptr=0x000f7d70 table=0x07fffef0
pmm_free data=0x07fdff80 olddata=0x07fe7f80 oldallocdata=0x07fe7fa0 info=0x07fe7f80
init ACPI tables
pmm_malloc zone=0x000f61ec handle=ffffffff size=36 align=10 ret=0x000f7d40 (info=0x07fdff20)
pmm_malloc zone=0x000f61e0 handle=ffffffff size=116 align=10 ret=0x07fffe70 (info=0x07fdff00)
pmm_malloc zone=0x000f61e0 handle=ffffffff size=64 align=40 ret=0x07fffe00 (info=0x07fdfee0)
pmm_malloc zone=0x000f61e0 handle=ffffffff size=7714 align=10 ret=0x07ffdfd0 (info=0x07fdfec0)
pmm_malloc zone=0x000f61e0 handle=ffffffff size=56 align=10 ret=0x07ffdf90 (info=0x07fdfea0)
pmm_malloc zone=0x000f61e0 handle=ffffffff size=224 align=10 ret=0x07ffdeb0 (info=0x07fdfe80)
pmm_malloc zone=0x000f61e0 handle=ffffffff size=56 align=10 ret=0x07ffde70 (info=0x07fdfe60)
pmm_malloc zone=0x000f61e0 handle=ffffffff size=52 align=10 ret=0x07ffde30 (info=0x07fdfe40)
ACPI tables: RSDP=0x000f7d40 RSDT=0x07ffde30
Scan for VGA option rom
Attempting to init PCI bdf 00:02.0 (dev/ven 00b81013)
Attempting to map option rom on dev 00:02.0
Option rom sizing returned f2010000 ffff0000
Inspecting possible rom at 0xf2010000 (dv=00b81013 bdf=10)
Copying option rom (size 35840) from 0xf2010000 to c0000
Checking rom 0x000c0000 (sig aa55 size 70)
Running option rom at c000:0003
Turning on vga console
Starting SeaBIOS (version 0.5.1-20100228_144514-morn.localdomain)

init usb
init ps2port
pmm_malloc zone=0x000f6204 handle=ffffffff size=4096 align=1000 ret=0x07fde000 (info=0x07fdfe20)
/07fde000\ Start thread
|07fde000| i8042_flush
|07fde000| i8042_command cmd=1aa
|07fde000| i8042_wait_write
|07fde000| i8042_wait_read
|07fde000| i8042 param=55
|07fde000| i8042_command cmd=1ab
|07fde000| i8042_wait_write
|07fde000| i8042_wait_read
|07fde000| i8042 param=0
|07fde000| i8042_command cmd=ae
|07fde000| i8042_wait_write
|07fde000| i8042_command cmd=a8
|07fde000| i8042_wait_write
|07fde000| kbd_command cmd=2ff
|07fde000| i8042 ctr old=0 new=20
|07fde000| i8042_command cmd=1060
|07fde000| i8042_wait_write
|07fde000| i8042_wait_write
|07fde000| ps2_sendbyte aux=0 cmd=ff
|07fde000| i8042_kbd_write c=255
|07fde000| i8042_wait_write
|07fde000| ps2 read fa
|07fde000| ps2 read aa
init lpt
Found 1 lpt ports
init serial
Found 1 serial ports
init boot device ordering
init floppy drives
Mapping floppy drive 0x000f7418
init hard drives
ATA controller 0 at 1f0/3f4/c000 (irq 14 dev 9)
pmm_malloc zone=0x000f6204 handle=ffffffff size=4096 align=1000 ret=0x07fdc000 (info=0x07fddfe0)
/07fdc000\ Start thread
|07fdc000| powerup iobase=1f0 st=0
|07fdc000| powerup iobase=1f0 st=0
|07fdc000| ata_detect ataid=0 sc=0 sn=0 dh=0
|07fdc000| powerup iobase=1f0 st=0
|07fdc000| powerup iobase=1f0 st=0
|07fdc000| ata_detect ataid=1 sc=0 sn=0 dh=0
|07fde000| pmm_free data=0x07fdc000 olddata=0x07fddfe0 oldallocdata=0x07fde000 info=0x07fddfe0
\07fdc000/ End thread
ATA controller 1 at 170/374/c008 (irq 15 dev 9)
pmm_malloc zone=0x000f6204 handle=ffffffff size=4096 align=1000 ret=0x07fdc000 (info=0x07fddfe0)
/07fdc000\ Start thread
|07fdc000| powerup iobase=170 st=50
|07fdc000| powerup iobase=170 st=50
|07fdc000| ata_detect ataid=2 sc=55 sn=aa dh=a0
|07fdc000| ata_reset drive=0x07fdcfa0
ps2 irq but no data.
|07fdc000| ata_reset exit status=0
|07fdc000| Identify w0=85c0 w2=0
|07fdc000| Mapping cd drive 0x000f7464
|07fdc000| ata_detect resetresult=0000
|07fdc000| powerup iobase=170 st=50
|07fdc000| powerup iobase=170 st=0
|07fdc000| ata_detect ataid=3 sc=55 sn=aa dh=b0
|07fdc000| send_cmd : DRQ not set (status 00)
|07fde000| pmm_free data=0x07fdc000 olddata=0x07fddfe0 oldallocdata=0x07fde000 info=0x07fddfe0
\07fdc000/ End thread
|07fde000| ps2_recvbyte timeout
|07fde000| i8042_command cmd=1060
|07fde000| i8042_wait_write
|07fde000| i8042_wait_write
|07fde000| kbd_command cmd=f5
|07fde000| i8042 ctr old=0 new=20
|07fde000| i8042_command cmd=1060
|07fde000| i8042_wait_write
|07fde000| i8042_wait_write
|07fde000| ps2_sendbyte aux=0 cmd=f5
|07fde000| i8042_kbd_write c=245
|07fde000| i8042_wait_write
|07fde000| ps2 read fa
|07fde000| i8042_command cmd=1060
|07fde000| i8042_wait_write
|07fde000| i8042_wait_write
|07fde000| kbd_command cmd=10f0
|07fde000| i8042 ctr old=0 new=20
|07fde000| i8042_command cmd=1060
|07fde000| i8042_wait_write
|07fde000| i8042_wait_write
|07fde000| ps2_sendbyte aux=0 cmd=f0
|07fde000| i8042_kbd_write c=240
|07fde000| i8042_wait_write
|07fde000| ps2 read fa
|07fde000| ps2_sendbyte aux=0 cmd=2
|07fde000| i8042_kbd_write c=2
|07fde000| i8042_wait_write
|07fde000| ps2 read fa
|07fde000| i8042_command cmd=1060
|07fde000| i8042_wait_write
|07fde000| i8042_wait_write
|07fde000| kbd_command cmd=f4
|07fde000| i8042 ctr old=61 new=60
|07fde000| i8042_command cmd=1060
|07fde000| i8042_wait_write
|07fde000| i8042_wait_write
|07fde000| ps2_sendbyte aux=0 cmd=f4
|07fde000| i8042_kbd_write c=244
|07fde000| i8042_wait_write
|07fde000| ps2 read fa
|07fde000| i8042_command cmd=1060
|07fde000| i8042_wait_write
|07fde000| i8042_wait_write
|07fde000| keyboard initialized
pmm_free data=0x07fde000 olddata=0x07fdfe20 oldallocdata=0x07fdfe40 info=0x07fdfe20
\07fde000/ End thread
Scan for option roms
Attempting to init PCI bdf 00:00.0 (dev/ven 12378086)
Attempting to map option rom on dev 00:00.0
Option rom sizing returned 0 0
Attempting to init PCI bdf 00:01.0 (dev/ven 70008086)
Attempting to map option rom on dev 00:01.0
Option rom sizing returned 0 0
Attempting to init PCI bdf 00:01.3 (dev/ven 71138086)
Attempting to map option rom on dev 00:01.3
Option rom sizing returned 0 0
Attempting to init PCI bdf 00:03.0 (dev/ven 100e8086)
Attempting to map option rom on dev 00:03.0
Option rom sizing returned 0 0
finalize PMM
malloc finalize
zone 0: 00007000-00090000 used=0 (0%)
zone 1: 000a0000-000a0000 used=0 (0%)
zone 2: 000f7680-000f7e80 used=320 (15%)
zone 3: 00100000-07ff0000 used=65984 (0%)
zone 4: 07ff0000-08000000 used=8656 (13%)
Add to e820 map: 0009f400 00000c00 2
Add to e820 map: 07ff0000 0000d000 1
Returned 53248 bytes of ZoneHigh
e820 map has 6 items:
  0: 0000000000000000 - 000000000009f400 = 1
  1: 000000000009f400 - 00000000000a0000 = 2
  2: 00000000000f0000 - 0000000000100000 = 2
  3: 0000000000100000 - 0000000007ffd000 = 1
  4: 0000000007ffd000 - 0000000008000000 = 2
  5: 00000000fffc0000 - 0000000100000000 = 2
locking shadow ram
Jump to int19
enter handle_19:
  NULL
Booting from Hard Disk...
invalid handle_legacy_disk:809:
   a=00000201  b=00000000  c=00000001  d=00000080 ds=0000 es=07c0 ss=0000
  si=00000000 di=00000000 bp=00000000 sp=00006f2c cs=f000 ip=e985  f=0202
Boot failed: could not read the boot disk

enter handle_18:
  NULL
Booting from Floppy...
Booting from 0000:7c00
enter handle_12:
   a=0000102c  b=00000062  c=00000000  d=0000006f ds=0060 es=0060 ss=102c
  si=00000d2c di=0000fefa bp=00000060 sp=000021b6 cs=0235 ip=a577  f=0096
enter handle_12:
   a=000000cf  b=0000fffe  c=0000fffe  d=00000000 ds=0a01 es=abd7 ss=9d23
  si=000005a2 di=0000cd3a bp=000021b6 sp=0000217c cs=8f2c ip=a64e  f=0202
enter handle_11:
   a=0000c924  b=00002192  c=00000000  d=00000000 ds=fffe es=0574 ss=9d23
  si=00000070 di=000021b6 bp=00000070 sp=00002176 cs=8f2c ip=a64e  f=0212
enter handle_17:
   a=00000100  b=00002192  c=00000000  d=00000000 ds=fffe es=0574 ss=9d23
  si=00000070 di=000021b6 bp=00000070 sp=00002176 cs=8f2c ip=a64e  f=0297
enter handle_11:
   a=00009000  b=00002192  c=00000000  d=00000000 ds=fffe es=0574 ss=9d23
  si=00000070 di=000021b6 bp=00000070 sp=00002176 cs=8f2c ip=a64e  f=0212
enter handle_14:
   a=000000a3  b=00002192  c=00000000  d=00000000 ds=fffe es=0574 ss=9d23
  si=00000070 di=000021b6 bp=00000070 sp=00002176 cs=8f2c ip=a64e  f=0297
invalid handle_legacy_disk:809:
   a=00000000  b=000021ac  c=0000032d  d=00002180 ds=0000 es=0000 ss=9d23
  si=000000cf di=0000fffe bp=0000fffe sp=0000217a cs=8f2c ip=a64e  f=0282
enter handle_11:
   a=00000000  b=00000000  c=00000000  d=00000000 ds=0000 es=0000 ss=9d23
  si=00000000 di=00000000 bp=00000000 sp=000020ea cs=8f2c ip=a64e  f=0246
invalid handle_legacy_disk:809:
   a=0000089e  b=0000d3ed  c=00000088  d=00002180 ds=0070 es=2100 ss=9d23
  si=00009d23 di=0000219e bp=0000d3ed sp=000020ce cs=8f2c ip=a64e  f=0206
unimplemented handle_16XX:219:
   a=00001402  b=00002130  c=00000001  d=00000d5d ds=cf41 es=9d23 ss=9d23
  si=00000000 di=00000008 bp=00002124 sp=00002108 cs=cf41 ip=0093  f=3246

[-- Attachment #3: seabios-debug-2.log --]
[-- Type: application/octet-stream, Size: 11001 bytes --]

Changing serial settings was 0/0 now 3/0
Start bios (version 0.5.1-20100228_144514-morn.localdomain)
enabling shadow ram
init ivt
init bda
Find memory size
Add to e820 map: 00000000 08000000 1
Add to e820 map: 00000000 00000000 1
Add to e820 map: fffc0000 00040000 2
Add to e820 map: 000a0000 00050000 -1
Add to e820 map: 0009f400 00000c00 2
Add to e820 map: 000f0000 00010000 2
Ram Size=0x08000000 (0x0000000000000000 high)
malloc setup
Add to e820 map: 07ff0000 00010000 2
init pic
init timer
tsc calibrate start=23772399 end=28632639 diff=4860240
CPU Mhz=2831
math cp init
qemu_cfg_present=1
Found 1 cpu(s) max supported 1 cpu(s)
pci setup
PIIX3/PIIX4 init: elcr=00 0c
PCI: bus=0 devfn=0x00: vendor_id=0x8086 device_id=0x1237
PCI: bus=0 devfn=0x08: vendor_id=0x8086 device_id=0x7000
PCI: bus=0 devfn=0x09: vendor_id=0x8086 device_id=0x7010
region 4: 0x0000c000
PCI: bus=0 devfn=0x0b: vendor_id=0x8086 device_id=0x7113
PCI: bus=0 devfn=0x10: vendor_id=0x1013 device_id=0x00b8
region 0: 0xf0000000
region 1: 0xf2000000
region 6: 0xf2010000
PCI: bus=0 devfn=0x18: vendor_id=0x8086 device_id=0x100e
region 0: 0xf2020000
region 1: 0x0000c040
init smm
init bios32
init PMM
init PNPBIOS table
init keyboard
init mouse
init PIR table
init MPTable
pmm_malloc zone=0x000f6204 handle=ffffffff size=32768 align=10 ret=0x07fe7fe0 (info=0x07feffe0)
pmm_malloc zone=0x000f61ec handle=ffffffff size=224 align=10 ret=0x000f7da0 (info=0x07fe7fc0)
pmm_malloc zone=0x000f61ec handle=ffffffff size=16 align=10 ret=0x000f7d90 (info=0x07fe7fa0)
pmm_free data=0x07fe7fe0 olddata=0x07feffe0 oldallocdata=0x07ff0000 info=0x07feffe0
MP table addr=0x000f7d90 MPC table addr=0x000f7da0 size=224
init SMBIOS tables
pmm_malloc zone=0x000f6204 handle=ffffffff size=32768 align=10 ret=0x07fdff80 (info=0x07fe7f80)
pmm_malloc zone=0x000f61ec handle=ffffffff size=31 align=10 ret=0x000f7d70 (info=0x07fdff60)
pmm_malloc zone=0x000f61e0 handle=ffffffff size=263 align=10 ret=0x07fffef0 (info=0x07fdff40)
SMBIOS ptr=0x000f7d70 table=0x07fffef0
pmm_free data=0x07fdff80 olddata=0x07fe7f80 oldallocdata=0x07fe7fa0 info=0x07fe7f80
init ACPI tables
pmm_malloc zone=0x000f61ec handle=ffffffff size=36 align=10 ret=0x000f7d40 (info=0x07fdff20)
pmm_malloc zone=0x000f61e0 handle=ffffffff size=116 align=10 ret=0x07fffe70 (info=0x07fdff00)
pmm_malloc zone=0x000f61e0 handle=ffffffff size=64 align=40 ret=0x07fffe00 (info=0x07fdfee0)
pmm_malloc zone=0x000f61e0 handle=ffffffff size=7714 align=10 ret=0x07ffdfd0 (info=0x07fdfec0)
pmm_malloc zone=0x000f61e0 handle=ffffffff size=56 align=10 ret=0x07ffdf90 (info=0x07fdfea0)
pmm_malloc zone=0x000f61e0 handle=ffffffff size=224 align=10 ret=0x07ffdeb0 (info=0x07fdfe80)
pmm_malloc zone=0x000f61e0 handle=ffffffff size=56 align=10 ret=0x07ffde70 (info=0x07fdfe60)
pmm_malloc zone=0x000f61e0 handle=ffffffff size=52 align=10 ret=0x07ffde30 (info=0x07fdfe40)
ACPI tables: RSDP=0x000f7d40 RSDT=0x07ffde30
Scan for VGA option rom
Attempting to init PCI bdf 00:02.0 (dev/ven 00b81013)
Attempting to map option rom on dev 00:02.0
Option rom sizing returned f2010000 ffff0000
Inspecting possible rom at 0xf2010000 (dv=00b81013 bdf=10)
Copying option rom (size 35840) from 0xf2010000 to c0000
Checking rom 0x000c0000 (sig aa55 size 70)
Running option rom at c000:0003
Turning on vga console
Starting SeaBIOS (version 0.5.1-20100228_144514-morn.localdomain)

init usb
init ps2port
pmm_malloc zone=0x000f6204 handle=ffffffff size=4096 align=1000 ret=0x07fde000 (info=0x07fdfe20)
/07fde000\ Start thread
|07fde000| i8042_flush
|07fde000| i8042_command cmd=1aa
|07fde000| i8042_wait_write
|07fde000| i8042_wait_read
|07fde000| i8042 param=55
|07fde000| i8042_command cmd=1ab
|07fde000| i8042_wait_write
|07fde000| i8042_wait_read
|07fde000| i8042 param=0
|07fde000| i8042_command cmd=ae
|07fde000| i8042_wait_write
|07fde000| i8042_command cmd=a8
|07fde000| i8042_wait_write
|07fde000| kbd_command cmd=2ff
|07fde000| i8042 ctr old=0 new=20
|07fde000| i8042_command cmd=1060
|07fde000| i8042_wait_write
|07fde000| i8042_wait_write
|07fde000| ps2_sendbyte aux=0 cmd=ff
|07fde000| i8042_kbd_write c=255
|07fde000| i8042_wait_write
|07fde000| ps2 read fa
|07fde000| ps2 read aa
init lpt
Found 1 lpt ports
init serial
Found 1 serial ports
init boot device ordering
init floppy drives
Mapping floppy drive 0x000f7418
init hard drives
ATA controller 0 at 1f0/3f4/c000 (irq 14 dev 9)
pmm_malloc zone=0x000f6204 handle=ffffffff size=4096 align=1000 ret=0x07fdc000 (info=0x07fddfe0)
/07fdc000\ Start thread
|07fdc000| powerup iobase=1f0 st=0
|07fdc000| powerup iobase=1f0 st=0
|07fdc000| ata_detect ataid=0 sc=0 sn=0 dh=0
|07fdc000| powerup iobase=1f0 st=0
|07fdc000| powerup iobase=1f0 st=0
|07fdc000| ata_detect ataid=1 sc=0 sn=0 dh=0
|07fde000| pmm_free data=0x07fdc000 olddata=0x07fddfe0 oldallocdata=0x07fde000 info=0x07fddfe0
\07fdc000/ End thread
ATA controller 1 at 170/374/c008 (irq 15 dev 9)
pmm_malloc zone=0x000f6204 handle=ffffffff size=4096 align=1000 ret=0x07fdc000 (info=0x07fddfe0)
/07fdc000\ Start thread
|07fdc000| powerup iobase=170 st=50
|07fdc000| powerup iobase=170 st=50
|07fdc000| ata_detect ataid=2 sc=55 sn=aa dh=a0
|07fdc000| ata_reset drive=0x07fdcfa0
ps2 irq but no data.
|07fdc000| ata_reset exit status=0
|07fdc000| Identify w0=85c0 w2=0
|07fdc000| Mapping cd drive 0x000f7464
|07fdc000| ata_detect resetresult=0000
|07fdc000| powerup iobase=170 st=50
|07fdc000| powerup iobase=170 st=0
|07fdc000| ata_detect ataid=3 sc=55 sn=aa dh=b0
|07fdc000| send_cmd : DRQ not set (status 00)
|07fde000| pmm_free data=0x07fdc000 olddata=0x07fddfe0 oldallocdata=0x07fde000 info=0x07fddfe0
\07fdc000/ End thread
|07fde000| ps2_recvbyte timeout
|07fde000| i8042_command cmd=1060
|07fde000| i8042_wait_write
|07fde000| i8042_wait_write
|07fde000| kbd_command cmd=f5
|07fde000| i8042 ctr old=0 new=20
|07fde000| i8042_command cmd=1060
|07fde000| i8042_wait_write
|07fde000| i8042_wait_write
|07fde000| ps2_sendbyte aux=0 cmd=f5
|07fde000| i8042_kbd_write c=245
|07fde000| i8042_wait_write
|07fde000| ps2 read fa
|07fde000| i8042_command cmd=1060
|07fde000| i8042_wait_write
|07fde000| i8042_wait_write
|07fde000| kbd_command cmd=10f0
|07fde000| i8042 ctr old=0 new=20
|07fde000| i8042_command cmd=1060
|07fde000| i8042_wait_write
|07fde000| i8042_wait_write
|07fde000| ps2_sendbyte aux=0 cmd=f0
|07fde000| i8042_kbd_write c=240
|07fde000| i8042_wait_write
|07fde000| ps2 read fa
|07fde000| ps2_sendbyte aux=0 cmd=2
|07fde000| i8042_kbd_write c=2
|07fde000| i8042_wait_write
|07fde000| ps2 read fa
|07fde000| i8042_command cmd=1060
|07fde000| i8042_wait_write
|07fde000| i8042_wait_write
|07fde000| kbd_command cmd=f4
|07fde000| i8042 ctr old=61 new=60
|07fde000| i8042_command cmd=1060
|07fde000| i8042_wait_write
|07fde000| i8042_wait_write
|07fde000| ps2_sendbyte aux=0 cmd=f4
|07fde000| i8042_kbd_write c=244
|07fde000| i8042_wait_write
|07fde000| ps2 read fa
|07fde000| i8042_command cmd=1060
|07fde000| i8042_wait_write
|07fde000| i8042_wait_write
|07fde000| keyboard initialized
pmm_free data=0x07fde000 olddata=0x07fdfe20 oldallocdata=0x07fdfe40 info=0x07fdfe20
\07fde000/ End thread
Scan for option roms
Attempting to init PCI bdf 00:00.0 (dev/ven 12378086)
Attempting to map option rom on dev 00:00.0
Option rom sizing returned 0 0
Attempting to init PCI bdf 00:01.0 (dev/ven 70008086)
Attempting to map option rom on dev 00:01.0
Option rom sizing returned 0 0
Attempting to init PCI bdf 00:01.3 (dev/ven 71138086)
Attempting to map option rom on dev 00:01.3
Option rom sizing returned 0 0
Attempting to init PCI bdf 00:03.0 (dev/ven 100e8086)
Attempting to map option rom on dev 00:03.0
Option rom sizing returned 0 0
finalize PMM
malloc finalize
zone 0: 00007000-00090000 used=0 (0%)
zone 1: 000a0000-000a0000 used=0 (0%)
zone 2: 000f7680-000f7e80 used=320 (15%)
zone 3: 00100000-07ff0000 used=65984 (0%)
zone 4: 07ff0000-08000000 used=8656 (13%)
Add to e820 map: 0009f400 00000c00 2
Add to e820 map: 07ff0000 0000d000 1
Returned 53248 bytes of ZoneHigh
e820 map has 6 items:
  0: 0000000000000000 - 000000000009f400 = 1
  1: 000000000009f400 - 00000000000a0000 = 2
  2: 00000000000f0000 - 0000000000100000 = 2
  3: 0000000000100000 - 0000000007ffd000 = 1
  4: 0000000007ffd000 - 0000000008000000 = 2
  5: 00000000fffc0000 - 0000000100000000 = 2
locking shadow ram
Jump to int19
enter handle_19:
  NULL
Booting from Hard Disk...
invalid handle_legacy_disk:809:
   a=00000201  b=00000000  c=00000001  d=00000080 ds=0000 es=07c0 ss=0000
  si=00000000 di=00000000 bp=00000000 sp=00006f2c cs=f000 ip=e985  f=0202
Boot failed: could not read the boot disk

enter handle_18:
  NULL
Booting from Floppy...
Booting from 0000:7c00
enter handle_12:
   a=0000102c  b=00000062  c=00000000  d=0000006f ds=0060 es=0060 ss=102c
  si=00000d2c di=0000fefa bp=00000060 sp=000021b6 cs=0235 ip=a577  f=0096
enter handle_12:
   a=000000cf  b=0000fffe  c=0000fffe  d=00000000 ds=0a01 es=abd7 ss=9d23
  si=000005a2 di=0000cd3a bp=000021b6 sp=0000217c cs=8f2c ip=a64e  f=0202
enter handle_11:
   a=0000c924  b=00002192  c=00000000  d=00000000 ds=fffe es=0574 ss=9d23
  si=00000070 di=000021b6 bp=00000070 sp=00002176 cs=8f2c ip=a64e  f=0212
enter handle_17:
   a=00000100  b=00002192  c=00000000  d=00000000 ds=fffe es=0574 ss=9d23
  si=00000070 di=000021b6 bp=00000070 sp=00002176 cs=8f2c ip=a64e  f=0297
enter handle_11:
   a=00009000  b=00002192  c=00000000  d=00000000 ds=fffe es=0574 ss=9d23
  si=00000070 di=000021b6 bp=00000070 sp=00002176 cs=8f2c ip=a64e  f=0212
enter handle_14:
   a=000000a3  b=00002192  c=00000000  d=00000000 ds=fffe es=0574 ss=9d23
  si=00000070 di=000021b6 bp=00000070 sp=00002176 cs=8f2c ip=a64e  f=0297
invalid handle_legacy_disk:809:
   a=00000000  b=000021ac  c=0000032c  d=00002180 ds=0000 es=0000 ss=9d23
  si=000000cf di=0000fffe bp=0000fffe sp=0000217a cs=8f2c ip=a64e  f=0282
enter handle_11:
   a=00000000  b=00000000  c=00000000  d=00000000 ds=0000 es=0000 ss=9d23
  si=00000000 di=00000000 bp=00000000 sp=000020ea cs=8f2c ip=a64e  f=0246
invalid handle_legacy_disk:809:
   a=0000089e  b=0000d3ed  c=00000088  d=00002180 ds=0070 es=2100 ss=9d23
  si=00009d23 di=0000219e bp=0000d3ed sp=000020ce cs=8f2c ip=a64e  f=0206
unimplemented handle_16XX:219:
   a=00001402  b=00002130  c=00000001  d=00000d5d ds=cf41 es=9d23 ss=9d23
  si=00000000 di=00000008 bp=00002124 sp=00002108 cs=cf41 ip=0093  f=3246
ps2 irq but no data.
ps2 irq but no data.
ps2 irq but no data.
ps2 irq but no data.
ps2 irq but no data.
ps2 irq but no data.
ps2 irq but no data.
ps2 irq but no data.
ps2 irq but no data.
ps2 irq but no data.
ps2 irq but no data.
ps2 irq but no data.
ps2 irq but no data.
ps2 irq but no data.
ps2 irq but no data.
ps2 irq but no data.
ps2 irq but no data.
ps2 irq but no data.
ps2 irq but no data.

Re: [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@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

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

[Roy Tam]

2010/3/10 Kevin O'Connor <kevin@koconnor.net>:
> On Wed, Mar 10, 2010 at 11:49:48AM +0800, Roy Tam wrote:
>> 2010/3/10 Kevin O'Connor <kevin@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.

You have to use MAKEBOOT.BAT to create a boot floppy (you can do it
inside QEMU to write it into an image too.)

>
> -Kevin
>

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

[Kevin O'Connor]

On Wed, Mar 10, 2010 at 01:05:38PM +0800, Roy Tam wrote:
> 2010/3/10 Kevin O'Connor <kevin@koconnor.net>:
> > On Wed, Mar 10, 2010 at 11:49:48AM +0800, Roy Tam wrote:
> >> >> 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.
> 
> You have to use MAKEBOOT.BAT to create a boot floppy (you can do it
> inside QEMU to write it into an image too.)

Okay - this one is interesting.  The code in that image is calling
int_1601 (check key) and int_1a00 (check timer) in a tight loop with
irqs disabled.  Bochs BIOS explicitly turns on irqs during int_16 and
int_1a processing, while SeaBIOS does not.  Since SeaBIOS doesn't
enable irqs and the caller doesn't enable irqs, key events and timer
irqs don't trigger and the code never exits the tight loop.

I'll have to investigate this one further - I'd like to look for
documentation on calls where the bios is obligated to temporarily
enable interrupts.

-Kevin

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

[Roy Tam]

2010/3/10 Kevin O'Connor <kevin@koconnor.net>:
> On Wed, Mar 10, 2010 at 11:49:48AM +0800, Roy Tam wrote:
>> 2010/3/10 Kevin O'Connor <kevin@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?

latest git today. when you type fast.

>
> 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.
>

But it is how programs(Chinese/Japanese/Korean Display Systems,
GW-BASIC, etc.) in the past get input from keyboard.
"Consider" legacy as "broken" is wrong IMHO.

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

[Kevin O'Connor]

On Wed, Mar 10, 2010 at 01:24:27PM +0800, Roy Tam wrote:
> 2010/3/10 Kevin O'Connor <kevin@koconnor.net>:
> > 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?
> 
> latest git today. when you type fast.

Bleh.  That image defines an int15 wrapper which corrupts %edi.
SeaBIOS calls int154f from the keyboard irq, and it is not prepared to
handle a corrupted edi.  In contrast, Bochs BIOS doesn't care if the
registers change.

> > 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.
> >
> 
> But it is how programs(Chinese/Japanese/Korean Display Systems,
> GW-BASIC, etc.) in the past get input from keyboard.

Can you point me to documentation on this usage?

> "Consider" legacy as "broken" is wrong IMHO.

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.

-Kevin

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

[Roy Tam]

2010/3/11 Kevin O'Connor <kevin@koconnor.net>:
> On Wed, Mar 10, 2010 at 01:24:27PM +0800, Roy Tam wrote:
>> 2010/3/10 Kevin O'Connor <kevin@koconnor.net>:
>> > 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?
>>
>> latest git today. when you type fast.
>
> Bleh.  That image defines an int15 wrapper which corrupts %edi.
> SeaBIOS calls int154f from the keyboard irq, and it is not prepared to
> handle a corrupted edi.  In contrast, Bochs BIOS doesn't care if the
> registers change.
>
>> > 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.
>> >
>>
>> But it is how programs(Chinese/Japanese/Korean Display Systems,
>> GW-BASIC, etc.) in the past get input from keyboard.
>
> Can you point me to documentation on this usage?
>

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.

>> "Consider" legacy as "broken" is wrong IMHO.
>
> 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.
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)

Even if status&1==1 is handled by the program itself, status==0x1c is
still handled by BIOS.
Programs in the past will try to get data from BIOS in this moment to
ensure two scancodes are the same.

On the contrary *NOT* sending keycode in this moment cause bigger problem.

The following patch help people to see irq status and data change:
---
diff --git a/src/ps2port.c b/src/ps2port.c
index 49bf551..48d940f 100644
--- a/src/ps2port.c
+++ b/src/ps2port.c
@@ -154,11 +154,19 @@ process_ps2byte(u8 status, u8 data)
 static void
 process_ps2bytes(void)
 {
+    u8 status = 0;
+    u8 data = 0;
+    u8 old_status = 0;
+    u8 old_data = 0;
     for (;;) {
-        u8 status = inb(PORT_PS2_STATUS);
+        old_status = status;
+        old_data = data;
+        status = inb(PORT_PS2_STATUS);
+        data = inb(PORT_PS2_DATA);
+        if ((data != old_data)||(status!=old_status))
+            dprintf(1, "ps2: data %x (status=%x)\n", data, status);
         if (!(status & I8042_STR_OBF))
             return;
-        u8 data = inb(PORT_PS2_DATA);
         process_ps2byte(status, data);
     }
 }

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

[Natalia Portillo]

El 11/03/2010, a las 07:42, Roy Tam escribió:

> 2010/3/11 Kevin O'Connor <kevin@koconnor.net>:
>> On Wed, Mar 10, 2010 at 01:24:27PM +0800, Roy Tam wrote:
>>> 2010/3/10 Kevin O'Connor <kevin@koconnor.net>:
>>>> 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?
>>>
>>> latest git today. when you type fast.
>>
>> Bleh.  That image defines an int15 wrapper which corrupts %edi.
>> SeaBIOS calls int154f from the keyboard irq, and it is not prepared  
>> to
>> handle a corrupted edi.  In contrast, Bochs BIOS doesn't care if the
>> registers change.
>>
>>>> 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.
>>>>
>>>
>>> But it is how programs(Chinese/Japanese/Korean Display Systems,
>>> GW-BASIC, etc.) in the past get input from keyboard.
>>
>> Can you point me to documentation on this usage?
>>
>
> 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.

I cannot check it out right now but I remember to have read that this  
is the usual behaviour, not for Asian display systems (that use  
combinational character recognition in software (pressing K and A with  
a japanese IME writes the KA kana), but for modifiers (CTRL, ALT, so  
on).

If you just press A the scancode is just A, then nothing (two reads).
If you press CTRL-A, the scancode is CTRL, then A (two reads).

Anyway this can be tested in real hardware easily. Norton Utilities  
diagnostics shown the scancodes.

>>> "Consider" legacy as "broken" is wrong IMHO.
>>
>> 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.
> 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)
>
> Even if status&1==1 is handled by the program itself, status==0x1c is
> still handled by BIOS.
> Programs in the past will try to get data from BIOS in this moment to
> ensure two scancodes are the same.
>
> On the contrary *NOT* sending keycode in this moment cause bigger  
> problem.
>
> The following patch help people to see irq status and data change:
> ---
> diff --git a/src/ps2port.c b/src/ps2port.c
> index 49bf551..48d940f 100644
> --- a/src/ps2port.c
> +++ b/src/ps2port.c
> @@ -154,11 +154,19 @@ process_ps2byte(u8 status, u8 data)
> static void
> process_ps2bytes(void)
> {
> +    u8 status = 0;
> +    u8 data = 0;
> +    u8 old_status = 0;
> +    u8 old_data = 0;
>     for (;;) {
> -        u8 status = inb(PORT_PS2_STATUS);
> +        old_status = status;
> +        old_data = data;
> +        status = inb(PORT_PS2_STATUS);
> +        data = inb(PORT_PS2_DATA);
> +        if ((data != old_data)||(status!=old_status))
> +            dprintf(1, "ps2: data %x (status=%x)\n", data, status);
>         if (!(status & I8042_STR_OBF))
>             return;
> -        u8 data = inb(PORT_PS2_DATA);
>         process_ps2byte(status, data);
>     }
> }
>
>

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

[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.

-Kevin

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

[Roy Tam]

2010/3/12 Kevin O'Connor <kevin@koconnor.net>:
> 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, [...]

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

[Roy Tam]

2010/3/12 Kevin O'Connor <kevin@koconnor.net>:
> 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.
>

and Norton GHOST for DOS (all versions, 8.0/8.2/8.3/11.5 tested) are
affected too.
for me having corrupted/incomplete scancodes is far better than having null.

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

[Kevin O'Connor]

On Sat, Mar 13, 2010 at 12:13:04AM +0800, Roy Tam wrote:
> 2010/3/12 Kevin O'Connor <kevin@koconnor.net>:
> > 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.
> >
> 
> and Norton GHOST for DOS (all versions, 8.0/8.2/8.3/11.5 tested) are
> affected too.
> for me having corrupted/incomplete scancodes is far better than having null.

Can you confirm GHOST keyboard fails in the same way - keyboard does
not work at all, and log fills with "ps2 irq but no data." when using
bios.bin-0.5.1-debug-20100311?

-Kevin

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

[Roy Tam]

2010/3/13 Kevin O'Connor <kevin@koconnor.net>:
> On Sat, Mar 13, 2010 at 12:13:04AM +0800, Roy Tam wrote:
>> 2010/3/12 Kevin O'Connor <kevin@koconnor.net>:
>> > 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.
>> >
>>
>> and Norton GHOST for DOS (all versions, 8.0/8.2/8.3/11.5 tested) are
>> affected too.
>> for me having corrupted/incomplete scancodes is far better than having null.
>
> Can you confirm GHOST keyboard fails in the same way - keyboard does
> not work at all, and log fills with "ps2 irq but no data." when using
> bios.bin-0.5.1-debug-20100311?
>

with debug 0228: yes
with debug 0311: no, but same issue occurs.