Hello,
I've compiled SeaBIOS on FreeBSD with gcc48, and although the build process succeeds, the resulting binary doesn't fully work. Most functions seem to work fine but there are some int15h functions that don't work properly (ie: they return invalid values).
I've compiled SeaBIOS with CONFIG_DEBUG_LEVEL=10 and got the following output (this is from the Xen console):
[...] (d4) enter handle_1a: (d4) a=00000200 b=00000000 c=00001725 d=00003400 ds=4cf0 es=9eb8 ss=dd00 (d4) si=00000004 di=00000000 bp=00000000 sp=0000fe66 cs=0000 ip=9336 f=0242 (d4) enter handle_1a: (d4) a=00000200 b=00000000 c=00001725 d=00003400 ds=4cf0 es=9eb8 ss=dd00 (d4) si=00000004 di=00000000 bp=00000000 sp=0000fe66 cs=0000 ip=9336 f=0242 (d4) enter handle_1a: (d4) a=00000200 b=00000000 c=00001725 d=00003400 ds=4cf0 es=9eb8 (XEN) irq.c:386: Dom4 callback via changed to Direct Vector 0x93 (XEN) irq.c:276: Dom4 PCI link 0 changed 5 -> 0 (XEN) irq.c:276: Dom4 PCI link 1 changed 10 -> 0 (XEN) irq.c:276: Dom4 PCI link 2 changed 11 -> 0 (XEN) irq.c:276: Dom4 PCI link 3 changed 5 -> 0 (d4) enter handle_15:
And that's all, there's no line containing the register values. I'm quite lost at figuring what's going on, so any help about how to proceed in order to debug this is highly appreciated.
Thanks, Roger.
El 15/04/15 a les 19.31, Roger Pau Monné ha escrit:
Hello,
I've compiled SeaBIOS on FreeBSD with gcc48, and although the build process succeeds, the resulting binary doesn't fully work. Most functions seem to work fine but there are some int15h functions that don't work properly (ie: they return invalid values).
I've compiled SeaBIOS with CONFIG_DEBUG_LEVEL=10 and got the following output (this is from the Xen console):
[...] (d4) enter handle_1a: (d4) a=00000200 b=00000000 c=00001725 d=00003400 ds=4cf0 es=9eb8 ss=dd00 (d4) si=00000004 di=00000000 bp=00000000 sp=0000fe66 cs=0000 ip=9336 f=0242 (d4) enter handle_1a: (d4) a=00000200 b=00000000 c=00001725 d=00003400 ds=4cf0 es=9eb8 ss=dd00 (d4) si=00000004 di=00000000 bp=00000000 sp=0000fe66 cs=0000 ip=9336 f=0242 (d4) enter handle_1a: (d4) a=00000200 b=00000000 c=00001725 d=00003400 ds=4cf0 es=9eb8 (XEN) irq.c:386: Dom4 callback via changed to Direct Vector 0x93 (XEN) irq.c:276: Dom4 PCI link 0 changed 5 -> 0 (XEN) irq.c:276: Dom4 PCI link 1 changed 10 -> 0 (XEN) irq.c:276: Dom4 PCI link 2 changed 11 -> 0 (XEN) irq.c:276: Dom4 PCI link 3 changed 5 -> 0 (d4) enter handle_15:
And that's all, there's no line containing the register values. I'm quite lost at figuring what's going on, so any help about how to proceed in order to debug this is highly appreciated.
Forgot to add that using the SeaBIOS binary built on FreeBSD on Linux shows the same behaviour, while using a SeaBIOS built on Linux on FreeBSD works perfectly fine.
Roger.
2015-04-15 19:31 GMT+02:00 Roger Pau Monné roger.pau@citrix.com:
Hello,
I've compiled SeaBIOS on FreeBSD with gcc48
This would mean you override CC with CC=gcc48. Perhaps you overlooked base's ld ( /usr/bin/ld ) with /usr/local/bin/ld ?
Idwer
2015-04-15 19:31 GMT+02:00 Roger Pau Monné roger.pau@citrix.com:
Hello,
I've compiled SeaBIOS on FreeBSD with gcc48
_or_ build and use coreboot's crossgcc toolchain: PATH=/path/to/coreboot_git_dir/util/crossgcc/xgcc/bin:$PATH gmake CROSS_PREFIX=i386-elf-
On Wed, Apr 15, 2015 at 07:31:21PM +0200, Roger Pau Monné wrote:
Hello,
I've compiled SeaBIOS on FreeBSD with gcc48, and although the build process succeeds, the resulting binary doesn't fully work. Most functions seem to work fine but there are some int15h functions that don't work properly (ie: they return invalid values).
I've compiled SeaBIOS with CONFIG_DEBUG_LEVEL=10 and got the following output (this is from the Xen console):
I'd be careful with debug level 10 - I've seen the high debugging cause issues. I usually don't go above 8. Alternatively, you can decrease the individual debug levels in src/config.h .
[...] (d4) enter handle_1a: (d4) a=00000200 b=00000000 c=00001725 d=00003400 ds=4cf0 es=9eb8 ss=dd00 (d4) si=00000004 di=00000000 bp=00000000 sp=0000fe66 cs=0000 ip=9336 f=0242 (d4) enter handle_1a: (d4) a=00000200 b=00000000 c=00001725 d=00003400 ds=4cf0 es=9eb8 ss=dd00 (d4) si=00000004 di=00000000 bp=00000000 sp=0000fe66 cs=0000 ip=9336 f=0242 (d4) enter handle_1a: (d4) a=00000200 b=00000000 c=00001725 d=00003400 ds=4cf0 es=9eb8 (XEN) irq.c:386: Dom4 callback via changed to Direct Vector 0x93 (XEN) irq.c:276: Dom4 PCI link 0 changed 5 -> 0 (XEN) irq.c:276: Dom4 PCI link 1 changed 10 -> 0 (XEN) irq.c:276: Dom4 PCI link 2 changed 11 -> 0 (XEN) irq.c:276: Dom4 PCI link 3 changed 5 -> 0 (d4) enter handle_15:
And that's all, there's no line containing the register values. I'm quite lost at figuring what's going on, so any help about how to proceed in order to debug this is highly appreciated.
In situations like the above, I run qemu with "-d in_asm,int,exec,cpu" and redirect the output to some log file. I then look through the log to see where things went wrong.
If you know which "int 15h" is returning bogus values, you can also use gdb with qemu and set a break point. See http://seabios.org/Debugging .
Let me know what you find or if you need help. -Kevin
Hello,
Thanks for the hints.
El 16/04/15 a les 3.43, Kevin O'Connor ha escrit:
On Wed, Apr 15, 2015 at 07:31:21PM +0200, Roger Pau Monné wrote:
Hello,
I've compiled SeaBIOS on FreeBSD with gcc48, and although the build process succeeds, the resulting binary doesn't fully work. Most functions seem to work fine but there are some int15h functions that don't work properly (ie: they return invalid values).
I've compiled SeaBIOS with CONFIG_DEBUG_LEVEL=10 and got the following output (this is from the Xen console):
I'd be careful with debug level 10 - I've seen the high debugging cause issues. I usually don't go above 8. Alternatively, you can decrease the individual debug levels in src/config.h .
Instead of setting debug level to 10, I've set it to 2 and lowered DEBUG_HDL_15 to 1 also, but I still get the same bogus output:
[...] (d8) enter handle_15: (d8) a=00008600 b=00000000 c=00000000 d=0000c350 ds=4cf0 es=9eb8 ss=df80 (d8) si=00000004 di=00000000 bp=00000000 sp=0000fa06 cs=0000 ip=9336 f=0242 (d8) enter handle_15: (d8) a=00008600 b=00000000 c=00000000 d=0000c350 ds=4cf0 es=9eb8 ss=df80 (d8) si=00000004 di=00000000 bp=00000000 sp=0000fa06 cs=0000 ip=9336 f=0242 (XEN) irq.c:386: Dom8 callback via changed to Direct Vector 0x93 (XEN) irq.c:276: Dom8 PCI link 0 changed 5 -> 0 (XEN) irq.c:276: Dom8 PCI link 1 changed 10 -> 0 (XEN) irq.c:276: Dom8 PCI link 2 changed 11 -> 0 (XEN) irq.c:276: Dom8 PCI link 3 changed 5 -> 0 (d8) enter handle_15:
[...] (d4) enter handle_1a: (d4) a=00000200 b=00000000 c=00001725 d=00003400 ds=4cf0 es=9eb8 ss=dd00 (d4) si=00000004 di=00000000 bp=00000000 sp=0000fe66 cs=0000 ip=9336 f=0242 (d4) enter handle_1a: (d4) a=00000200 b=00000000 c=00001725 d=00003400 ds=4cf0 es=9eb8 ss=dd00 (d4) si=00000004 di=00000000 bp=00000000 sp=0000fe66 cs=0000 ip=9336 f=0242 (d4) enter handle_1a: (d4) a=00000200 b=00000000 c=00001725 d=00003400 ds=4cf0 es=9eb8 (XEN) irq.c:386: Dom4 callback via changed to Direct Vector 0x93 (XEN) irq.c:276: Dom4 PCI link 0 changed 5 -> 0 (XEN) irq.c:276: Dom4 PCI link 1 changed 10 -> 0 (XEN) irq.c:276: Dom4 PCI link 2 changed 11 -> 0 (XEN) irq.c:276: Dom4 PCI link 3 changed 5 -> 0 (d4) enter handle_15:
And that's all, there's no line containing the register values. I'm quite lost at figuring what's going on, so any help about how to proceed in order to debug this is highly appreciated.
In situations like the above, I run qemu with "-d in_asm,int,exec,cpu" and redirect the output to some log file. I then look through the log to see where things went wrong.
If you know which "int 15h" is returning bogus values, you can also use gdb with qemu and set a break point. See http://seabios.org/Debugging .
I've tried this, the function is handle_15c0. This happens quite late in the boot process, the FreeBSD code that triggers this issue is at:
http://fxr.watson.org/fxr/source/dev/atkbdc/atkbd.c#L1163
I've tried to run gdb against SeaBIOS, but it seems like breakpoints are not correctly working. I've launched Qemu with:
# qemu-system-x86_64 -bios out/bios.bin -nographic /dev/zvol/tank/freebsd -s -S
And then:
# gdb782 out/rom16.o GNU gdb (GDB) 7.8.2 [GDB v7.8.2 for FreeBSD] Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-portbld-freebsd11.0". Type "show configuration" for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from out/rom16.o...done. (gdb) set architecture i8086 warning: A handler for the OS ABI "FreeBSD ELF" is not built into this configuration of GDB. Attempting to continue with the default i8086 settings.
The target architecture is assumed to be i8086 (gdb) add-symbol-file out/rom16.o 0xf0000 add symbol table from file "out/rom16.o" at .text_addr = 0xf0000 (y or n) y Reading symbols from out/rom16.o...warning: section .text not found in /root/xen/seabios/out/rom16.o done. (gdb) break handle_15c0 Breakpoint 1 at 0xf16f: file ./src/system.c, line 247. (gdb) break handle_15 Breakpoint 2 at 0xf0fc: file ./src/system.c, line 336. (gdb) target remote localhost:1234 Remote debugging using localhost:1234 ?? () at src/romlayout.S:651 651 ljmpw $SEG_BIOS, $entry_post (gdb) c Continuing.
And nothing more, FreeBSD boots but breakpoints don't trigger at all. I've tried this both with the working and non-working versions of SeaBIOS, and the behaviour is always the same.
Roger.
On Thu, Apr 16, 2015 at 01:46:41PM +0200, Roger Pau Monné wrote:
El 16/04/15 a les 3.43, Kevin O'Connor ha escrit:
If you know which "int 15h" is returning bogus values, you can also use gdb with qemu and set a break point. See http://seabios.org/Debugging .
I've tried this, the function is handle_15c0. This happens quite late in the boot process, the FreeBSD code that triggers this issue is at:
http://fxr.watson.org/fxr/source/dev/atkbdc/atkbd.c#L1163
I've tried to run gdb against SeaBIOS, but it seems like breakpoints are not correctly working. I've launched Qemu with:
# qemu-system-x86_64 -bios out/bios.bin -nographic /dev/zvol/tank/freebsd -s -S
And then:
# gdb782 out/rom16.o
Looks like this broke in gdb at some point. It definitely used to work. You can use this sequence instead:
$ objcopy --adjust-vma 0xf0000 out/rom16.o rom16offset.o $ gdb out/rom16.o (gdb) target remote localhost:1234 (gdb) set architecture i8086 (gdb) symbol-file rom16offset.o (gdb) break handle_15 (gdb) continue
-Kevin
El 16/04/15 a les 15.43, Kevin O'Connor ha escrit:
On Thu, Apr 16, 2015 at 01:46:41PM +0200, Roger Pau Monné wrote:
El 16/04/15 a les 3.43, Kevin O'Connor ha escrit:
If you know which "int 15h" is returning bogus values, you can also use gdb with qemu and set a break point. See http://seabios.org/Debugging .
I've tried this, the function is handle_15c0. This happens quite late in the boot process, the FreeBSD code that triggers this issue is at:
http://fxr.watson.org/fxr/source/dev/atkbdc/atkbd.c#L1163
I've tried to run gdb against SeaBIOS, but it seems like breakpoints are not correctly working. I've launched Qemu with:
# qemu-system-x86_64 -bios out/bios.bin -nographic /dev/zvol/tank/freebsd -s -S
And then:
# gdb782 out/rom16.o
Looks like this broke in gdb at some point. It definitely used to work. You can use this sequence instead:
Thanks, this indeed seems to be better than the previous procedure. All the steps detailed here have been done using the SeaBIOS build with crossgcc from coreboot, which works fine.
$ objcopy --adjust-vma 0xf0000 out/rom16.o rom16offset.o
While doing this I get:
BFD: rom16offset.o: section .text.set_a20 lma 0xf74f8 adjusted to 0xf783c BFD: rom16offset.o: section .text.pic_eoi2 lma 0xf7525 adjusted to 0xf7869 BFD: rom16offset.o: section .text.call32_smm_prep lma 0xf752d adjusted to 0xf7871 BFD: rom16offset.o: section .text.call32_smm_post lma 0xf7558 adjusted to 0xf789c BFD: rom16offset.o: section .text.call32_sloppy_prep lma 0xf757e adjusted to 0xf78c2 BFD: rom16offset.o: section .text.call32_sloppy_post lma 0xf75f6 adjusted to 0xf793a BFD: rom16offset.o: section .text.on_extra_stack lma 0xf7665 adjusted to 0xf79a9 BFD: rom16offset.o: section .text.memset lma 0xf7689 adjusted to 0xf79cd BFD: rom16offset.o: section .text.memcpy lma 0xf7698 adjusted to 0xf79dc BFD: rom16offset.o: section .text.enqueue_key lma 0xf76ca adjusted to 0xf7a0e BFD: rom16offset.o: section .text.ehci_reset_pipe lma 0xf7738 adjusted to 0xf7a7c BFD: rom16offset.o: section .text.lba2chs lma 0xf777f adjusted to 0xf7ac3 BFD: rom16offset.o: section .text.stack_hop_back lma 0xf77c8 adjusted to 0xf7b0c BFD: rom16offset.o: section .text.getLCHS lma 0xf782a adjusted to 0xf7b6e BFD: rom16offset.o: section .text.putsinglehex.isra.41 lma 0xf78a8 adjusted to 0xf7bec BFD: rom16offset.o: section .text.puthex.isra.42 lma 0xf78c3 adjusted to 0xf7c07 BFD: rom16offset.o: section .text.puts_cs.isra.45 lma 0xf796d adjusted to 0xf7cb1 BFD: rom16offset.o: section .text.vring_get_buf.constprop.83 lma 0xf7984 adjusted to 0xf7cc8 BFD: rom16offset.o: section .text.clear_usertimer lma 0xf7a84 adjusted to 0xf7dc8 BFD: rom16offset.o: section .text.set_code_success lma 0xf7acb adjusted to 0xf7e0f BFD: rom16offset.o: section .text.getComAddr lma 0xf7ad7 adjusted to 0xf7e1b BFD: rom16offset.o: section .text.getLptAddr lma 0xf7b09 adjusted to 0xf7e4d BFD: rom16offset.o: section .text.__disk_ret_unimplemented.isra.8 lma 0xf7b3c adjusted to 0xf7e80 BFD: rom16offset.o: section .text.__disk_ret.isra.7 lma 0xf7b64 adjusted to 0xf7ea8 BFD: rom16offset.o: section .text.basic_access lma 0xf7b93 adjusted to 0xf7ed7 BFD: rom16offset.o: section .text.extended_access lma 0xf7cce adjusted to 0xf8012 BFD: rom16offset.o: section .text.disk_1300 lma 0xf7d96 adjusted to 0xf80da BFD: rom16offset.o: section .text.disk_1308 lma 0xf7dd2 adjusted to 0xf8116 BFD: rom16offset.o: section .text.disk_1310 lma 0xf7ef9 adjusted to 0xf823d BFD: rom16offset.o: section .text.floppy_disable_controller lma 0xf7f38 adjusted to 0xf827c BFD: rom16offset.o: section .text.pci_next lma 0xf7f50 adjusted to 0xf8294 BFD: rom16offset.o: section .text.timer_read lma 0xf7fdb adjusted to 0xf831f BFD: rom16offset.o: section .text.timer_check lma 0xf808c adjusted to 0xf83d0 BFD: rom16offset.o: section .text.timer_delay lma 0xf80a8 adjusted to 0xf83ec BFD: rom16offset.o: section .text.udelay lma 0xf80cc adjusted to 0xf8410 BFD: rom16offset.o: section .text.ndelay.constprop.76 lma 0xf80eb adjusted to 0xf842f BFD: rom16offset.o: section .text.putuint.isra.44 lma 0xf810c adjusted to 0xf8450 BFD: rom16offset.o: section .text.fill_generic_edd lma 0xf8153 adjusted to 0xf8497 BFD: rom16offset.o: section .text.fill_edd lma 0xf84b7 adjusted to 0xf87fb BFD: rom16offset.o: section .text.__dprintf lma 0xf86c2 adjusted to 0xf8a06 BFD: rom16offset.o: section .text.dump_regs lma 0xf86d6 adjusted to 0xf8a1a BFD: rom16offset.o: section .text.__warn_timeout lma 0xf876d adjusted to 0xf8ab1 BFD: rom16offset.o: section .text.i8042_wait_write lma 0xf8783 adjusted to 0xf8ac7 BFD: rom16offset.o: section .text.__i8042_command lma 0xf87c0 adjusted to 0xf8b04 BFD: rom16offset.o: section .text.disk_1305 lma 0xf8876 adjusted to 0xf8bba BFD: rom16offset.o: section .text.panic lma 0xf8984 adjusted to 0xf8cc8 BFD: rom16offset.o: section .text.vring_add_buf.constprop.81 lma 0xf899a adjusted to 0xf8cde BFD: rom16offset.o: section .text.handle_12 lma 0xf8bf6 adjusted to 0xf8f3a BFD: rom16offset.o: section .text.handle_11 lma 0xf8c09 adjusted to 0xf8f4d BFD: rom16offset.o: section .text.handle_05 lma 0xf8c1c adjusted to 0xf8f60 BFD: rom16offset.o: section .text.handle_02 lma 0xf8c42 adjusted to 0xf8f86 BFD: rom16offset.o: section .text.call16_smm_helper lma 0xf8c58 adjusted to 0xf8f9c BFD: rom16offset.o: section .text.call16_sloppy_helper lma 0xf8c98 adjusted to 0xf8fdc BFD: rom16offset.o: section .text.call32 lma 0xf8cd8 adjusted to 0xf901c BFD: rom16offset.o: section .text.call32_params.constprop.91 lma 0xf8d95 adjusted to 0xf90d9 BFD: rom16offset.o: section .text.usb_poll_intr lma 0xf8ddd adjusted to 0xf9121 BFD: rom16offset.o: section .text._farcall16 lma 0xf90f4 adjusted to 0xf9438 BFD: rom16offset.o: section .text.__call16_int lma 0xf9135 adjusted to 0xf9479 BFD: rom16offset.o: section .text.handle_75 lma 0xf9146 adjusted to 0xf948a BFD: rom16offset.o: section .text.disk_1346.isra.52 lma 0xf91a1 adjusted to 0xf94e5 BFD: rom16offset.o: section .text.disk_13 lma 0xf923b adjusted to 0xf957f BFD: rom16offset.o: section .text.handle_legacy_disk lma 0xf9577 adjusted to 0xf98bb BFD: rom16offset.o: section .text.process_key lma 0xf95f7 adjusted to 0xf993b BFD: rom16offset.o: section .text.prockeys lma 0xf994c adjusted to 0xf9c90 BFD: rom16offset.o: section .text.procmodkey lma 0xf9997 adjusted to 0xf9cdb BFD: rom16offset.o: section .text.procscankey lma 0xf99ed adjusted to 0xf9d31 BFD: rom16offset.o: section .text.check_irqs lma 0xf9a0a adjusted to 0xf9d4e BFD: rom16offset.o: section .text.virtio_blk_op lma 0xf9a2c adjusted to 0xf9d70 BFD: rom16offset.o: section .text.rtc_updating lma 0xf9b6a adjusted to 0xf9eae BFD: rom16offset.o: section .text.ps2_recvbyte lma 0xf9bb7 adjusted to 0xf9efb BFD: rom16offset.o: section .text.ps2_sendbyte lma 0xf9c7e adjusted to 0xf9fc2 BFD: rom16offset.o: section .text.__ps2_command lma 0xf9d08 adjusted to 0xfa04c BFD: rom16offset.o: section .text.mouse_command lma 0xf9f5e adjusted to 0xfa2a2 BFD: rom16offset.o: section .text.mouse_15c201 lma 0xfa037 adjusted to 0xfa37b BFD: rom16offset.o: section .text.handle_160a lma 0xfa082 adjusted to 0xfa3c6 BFD: rom16offset.o: section .text.uhci_waittick lma 0xfa0e2 adjusted to 0xfa426 BFD: rom16offset.o: section .text.ehci_send_pipe.constprop.80 lma 0xfa13e adjusted to 0xfa482 BFD: rom16offset.o: section .text.floppy_wait_irq lma 0xfa43a adjusted to 0xfa77e BFD: rom16offset.o: section .text.floppy_enable_controller lma 0xfa4ab adjusted to 0xfa7ef BFD: rom16offset.o: section .text.floppy_drive_pio lma 0xfa4f2 adjusted to 0xfa836 BFD: rom16offset.o: section .text.floppy_drive_readid.constprop.75 lma 0xfa58f adjusted to 0xfa8d3 BFD: rom16offset.o: section .text.floppy_read lma 0xfa5d5 adjusted to 0xfa919 BFD: rom16offset.o: section .text.floppy_write lma 0xfa693 adjusted to 0xfa9d7 BFD: rom16offset.o: section .text.await_ide.constprop.77 lma 0xfa751 adjusted to 0xfaa95 BFD: rom16offset.o: section .text.await_not_bsy lma 0xfa7c4 adjusted to 0xfab08 BFD: rom16offset.o: section .text.send_cmd lma 0xfa7d4 adjusted to 0xfab18 BFD: rom16offset.o: section .text.ata_pio_transfer lma 0xfa8db adjusted to 0xfac1f BFD: rom16offset.o: section .text.ata_wait_data lma 0xfaa22 adjusted to 0xfad66 BFD: rom16offset.o: section .text.ata_readwrite lma 0xfaa5b adjusted to 0xfad9f BFD: rom16offset.o: section .text.atapi_cmd_data lma 0xfabe4 adjusted to 0xfaf28 BFD: rom16offset.o: section .text.uhci_send_pipe.constprop.79 lma 0xfad28 adjusted to 0xfb06c BFD: rom16offset.o: section .text.usb_send_pipe.constprop.78 lma 0xfb095 adjusted to 0xfb3d9 BFD: rom16offset.o: section .text.usb_cmd_data lma 0xfb0e2 adjusted to 0xfb426 BFD: rom16offset.o: section .text.uas_cmd_data lma 0xfb26b adjusted to 0xfb5af BFD: rom16offset.o: section .text.cdb_cmd_data lma 0xfb471 adjusted to 0xfb7b5 BFD: rom16offset.o: section .text.cdb_read lma 0xfb96c adjusted to 0xfbcb0 BFD: rom16offset.o: section .text.cdb_write lma 0xfb9cd adjusted to 0xfbd11 BFD: rom16offset.o: section .text.process_op lma 0xfba2e adjusted to 0xfbd72 BFD: rom16offset.o: section .text.cdemu_read lma 0xfbe2b adjusted to 0xfc16f BFD: rom16offset.o: section .text.wait_irq lma 0xfc059 adjusted to 0xfc39d BFD: rom16offset.o: section .text.handle_1553 lma 0xfc079 adjusted to 0xfc3bd BFD: rom16offset.o: section .text.handle_40 lma 0xfc1ec adjusted to 0xfc530 BFD: rom16offset.o: section .text.handle_13 lma 0xfc21e adjusted to 0xfc562 BFD: rom16offset.o: section .text.handle_76 lma 0xfc2ce adjusted to 0xfc612 BFD: rom16offset.o: section .text.invoke_mouse_handler lma 0xfc2df adjusted to 0xfc623 BFD: rom16offset.o: section .text.process_mouse lma 0xfc358 adjusted to 0xfc69c BFD: rom16offset.o: section .text.handle_16 lma 0xfc3b3 adjusted to 0xfc6f7 BFD: rom16offset.o: section .text.handle_1589 lma 0xfc4bc adjusted to 0xfc800 BFD: rom16offset.o: section .text.handle_14 lma 0xfc556 adjusted to 0xfc89a BFD: rom16offset.o: section .text.handle_17 lma 0xfc77a adjusted to 0xfcabe BFD: rom16offset.o: section .text.handle_1a lma 0xfc8df adjusted to 0xfcc23 BFD: rom16offset.o: section .text.handle_70 lma 0xfcb41 adjusted to 0xfce85 BFD: rom16offset.o: section .text.handle_resume lma 0xfcc39 adjusted to 0xfcf7d BFD: rom16offset.o: section .text.handle_pnp lma 0xfcd04 adjusted to 0xfd048 BFD: rom16offset.o: section .text.handle_pcibios lma 0xfcd4d adjusted to 0xfd091 BFD: rom16offset.o: section .text.handle_74 lma 0xfd0c2 adjusted to 0xfd406 BFD: rom16offset.o: section .text.handle_09 lma 0xfd0fd adjusted to 0xfd441 BFD: rom16offset.o: section .text.handle_0e lma 0xfd146 adjusted to 0xfd48a BFD: rom16offset.o: section .text.asm.transition32 lma 0xfd162 adjusted to 0xfd4a6 BFD: rom16offset.o: section .text.asm.transition16 lma 0xfd1ad adjusted to 0xfd4f1 BFD: rom16offset.o: section .text.asm.__farcall16 lma 0xfd202 adjusted to 0xfd546 BFD: rom16offset.o: section .text.asm.irq_trampoline_0x02 lma 0xfd28f adjusted to 0xfd5d3 BFD: rom16offset.o: section .text.asm.irq_trampoline_0x10 lma 0xfd292 adjusted to 0xfd5d6 BFD: rom16offset.o: section .text.asm.irq_trampoline_0x13 lma 0xfd295 adjusted to 0xfd5d9 BFD: rom16offset.o: section .text.asm.irq_trampoline_0x15 lma 0xfd298 adjusted to 0xfd5dc BFD: rom16offset.o: section .text.asm.entry_smi lma 0xfd29b adjusted to 0xfd5df BFD: rom16offset.o: section .text.asm.entry_smp lma 0xfd2b0 adjusted to 0xfd5f4 BFD: rom16offset.o: section .text.asm.entry_resume lma 0xfd2e0 adjusted to 0xfd624 BFD: rom16offset.o: section .text.asm.entry_pmm lma 0xfd2f5 adjusted to 0xfd639 BFD: rom16offset.o: section .text.asm.entry_pnp_real lma 0xfd353 adjusted to 0xfd697 BFD: rom16offset.o: section .text.asm.entry_apm16 lma 0xfd39b adjusted to 0xfd6df BFD: rom16offset.o: section .text.asm.entry_apm32 lma 0xfd3dc adjusted to 0xfd720 BFD: rom16offset.o: section .text.asm.entry_pcibios32 lma 0xfd40e adjusted to 0xfd752 BFD: rom16offset.o: section .text.asm.entry_pcibios16 lma 0xfd43c adjusted to 0xfd780 BFD: rom16offset.o: section .text.asm.entry_1589 lma 0xfd476 adjusted to 0xfd7ba BFD: rom16offset.o: section .text.asm.entry_bios32 lma 0xfd4b0 adjusted to 0xfd7f4 BFD: rom16offset.o: section .text.asm.irqentry_extrastack lma 0xfd4cf adjusted to 0xfd813 BFD: rom16offset.o: section .text.asm.irqentry_arg_extrastack lma 0xfd55c adjusted to 0xfd8a0 BFD: rom16offset.o: section .text.asm.entry_13 lma 0xfd5fe adjusted to 0xfd942 BFD: rom16offset.o: section .text.asm.entry_76 lma 0xfd607 adjusted to 0xfd94b BFD: rom16offset.o: section .text.asm.entry_70 lma 0xfd610 adjusted to 0xfd954 BFD: rom16offset.o: section .text.asm.entry_74 lma 0xfd619 adjusted to 0xfd95d BFD: rom16offset.o: section .text.asm.entry_75 lma 0xfd622 adjusted to 0xfd966 BFD: rom16offset.o: section .text.asm.entry_hwpic1 lma 0xfd62b adjusted to 0xfd96f BFD: rom16offset.o: section .text.asm.entry_19 lma 0xfd634 adjusted to 0xfd978 BFD: rom16offset.o: section .text.asm.entry_18 lma 0xfd647 adjusted to 0xfd98b BFD: rom16offset.o: section .rodata lma 0xfd65a adjusted to 0xfd99e BFD: rom16offset.o: section .rodata.__func__.10501 lma 0xfdaf4 adjusted to 0xfde37 BFD: rom16offset.o: section .rodata.__func__.9961 lma 0xfdb08 adjusted to 0xfde48 BFD: rom16offset.o: section .rodata.__func__.9285 lma 0xfdb18 adjusted to 0xfde56 BFD: rom16offset.o: section .rodata.__func__.9243 lma 0xfdb24 adjusted to 0xfde60 BFD: rom16offset.o: section .rodata.__func__.8917 lma 0xfdb30 adjusted to 0xfde6a BFD: rom16offset.o: section .rodata.__func__.8897 lma 0xfdb3c adjusted to 0xfde75 BFD: rom16offset.o: section .rodata.__func__.8122 lma 0xfdb4c adjusted to 0xfde85 BFD: rom16offset.o: section .rodata.__func__.8164 lma 0xfdb5c adjusted to 0xfde92 BFD: rom16offset.o: section .rodata.__func__.7497 lma 0xfdb6c adjusted to 0xfdea1 BFD: rom16offset.o: section .rodata.__func__.7521 lma 0xfdb78 adjusted to 0xfdeab BFD: rom16offset.o: section .rodata.__func__.7388 lma 0xfdb80 adjusted to 0xfdeb3 BFD: rom16offset.o: section .rodata.__func__.6574 lma 0xfdb90 adjusted to 0xfdec1 BFD: rom16offset.o: section .rodata.__func__.6635 lma 0xfdba0 adjusted to 0xfded1 BFD: rom16offset.o: section .rodata.__func__.6583 lma 0xfdbb0 adjusted to 0xfdede BFD: rom16offset.o: section .rodata.__func__.4214 lma 0xfdbc4 adjusted to 0xfdeef BFD: rom16offset.o: section .rodata.__func__.4529 lma 0xfdbd0 adjusted to 0xfdef9 BFD: rom16offset.o: section .rodata.__func__.1830 lma 0xfdbdc adjusted to 0xfdf03 BFD: rom16offset.o: section .rodata.__func__.1817 lma 0xfdbe8 adjusted to 0xfdf0d BFD: rom16offset.o: section .rodata.__func__.1809 lma 0xfdbf4 adjusted to 0xfdf17 BFD: rom16offset.o: section `.rodata.__func__.1830' can't be allocated in segment 0 LOAD: .text.set_a20 .text.pic_eoi2 .text.call32_smm_prep .text.call32_smm_post .text.call32_sloppy_prep .text.call32_sloppy_post .text.on_extra_stack .text.memset .text.memcpy .text.enqueue_key .text.ehci_reset_pipe .text.lba2chs .text.stack_hop_back .text.getLCHS .text.putsinglehex.isra.41 .text.puthex.isra.42 .text.puts_cs.isra.45 .text.vring_get_buf.constprop.83 .text.clear_usertimer .text.set_code_success .text.getComAddr .text.getLptAddr .text.__disk_ret_unimplemented.isra.8 .text.__disk_ret.isra.7 .text.basic_access .text.extended_access .text.disk_1300 .text.disk_1308 .text.disk_1310 .text.floppy_disable_controller .text.pci_next .text.timer_read .text.timer_check .text.timer_delay .text.udelay .text.ndelay.constprop.76 .text.putuint.isra.44 .text.fill_generic_edd .text.fill_edd .text.__dprintf .text.dump_regs .text.__warn_timeout .text.i8042_wait_write .text.__i8042_command .text.disk_1305 .text.panic .text.vring_add_buf.constprop.81 .text.handle_12 .text.handle_11 .text.handl e_05 .text.handle_02 .text.call16_smm_helper .text.call16_sloppy_helper .text.call32 .text.call32_params.constprop.91 .text.usb_poll_intr .text._farcall16 .text.__call16_int .text.handle_75 .text.disk_1346.isra.52 .text.disk_13 .text.handle_legacy_disk .text.process_key .text.prockeys .text.procmodkey .text.procscankey .text.check_irqs .text.virtio_blk_op .text.rtc_updating .text.ps2_recvbyte .text.ps2_sendbyte .text.__ps2_command .text.mouse_command .text.mouse_15c201 .text.handle_160a .text.uhci_waittick .text.ehci_send_pipe.constprop.80 .text.floppy_wait_irq .text.floppy_enable_controller .text.floppy_drive_pio .text.floppy_drive_readid.constprop.75 .text.floppy_read .text.floppy_write .text.await_ide.constprop.77 .text.await_not_bsy .text.send_cmd .text.ata_pio_transfer .text.ata_wait_data .text.ata_readwrite .text.atapi_cmd_data .text.uhci_send_pipe.constprop.79 .text.usb_send_pipe.constprop.78 .text.usb_cmd_data .text.uas_cmd_data .text.cdb_cmd_data .text.cdb_read .text.cdb_writ e .text.process_op .text.cdemu_read .text.wait_irq .text.handle_1553 .text.handle_40 .text.handle_13 .text.handle_76 .text.invoke_mouse_handler .text.process_mouse .text.handle_16 .text.handle_1589 .text.handle_14 .text.handle_17 .text.handle_1a .text.handle_70 .text.handle_resume .text.handle_pnp .text.handle_pcibios .text.handle_74 .text.handle_09 .text.handle_0e .text.asm.transition32 .text.asm.transition16 .text.asm.__farcall16 .text.asm.irq_trampoline_0x02 .text.asm.irq_trampoline_0x10 .text.asm.irq_trampoline_0x13 .text.asm.irq_trampoline_0x15 .text.asm.entry_smi .text.asm.entry_smp .text.asm.entry_resume .text.asm.entry_pmm .text.asm.entry_pnp_real .text.asm.entry_apm16 .text.asm.entry_apm32 .text.asm.entry_pcibios32 .text.asm.entry_pcibios16 .text.asm.entry_1589 .text.asm.entry_bios32 .text.asm.irqentry_extrastack .text.asm.irqentry_arg_extrastack .text.asm.entry_13 .text.asm.entry_76 .text.asm.entry_70 .text.asm.entry_74 .text.asm.entry_75 .text.asm.entry_hwpic1 .text.asm.ent ry_19 .text.asm.entry_18 .rodata .rodata.__func__.10501 .rodata.__func__.9961 .rodata.__func__.9285 .rodata.__func__.9243 .rodata.__func__.8917 .rodata.__func__.8897 .rodata.__func__.8122 .rodata.__func__.8164 .rodata.__func__.7497 .rodata.__func__.7521 .rodata.__func__.7388 .rodata.__func__.6574 .rodata.__func__.6635 .rodata.__func__.6583 .rodata.__func__.4214 .rodata.__func__.4529 .rodata.__func__.1830 .rodata.__func__.1817 .rodata.__func__.1809 BFD: rom16offset.o: section `.rodata.__func__.1817' can't be allocated in segment 0 LOAD: .text.set_a20 .text.pic_eoi2 .text.call32_smm_prep .text.call32_smm_post .text.call32_sloppy_prep .text.call32_sloppy_post .text.on_extra_stack .text.memset .text.memcpy .text.enqueue_key .text.ehci_reset_pipe .text.lba2chs .text.stack_hop_back .text.getLCHS .text.putsinglehex.isra.41 .text.puthex.isra.42 .text.puts_cs.isra.45 .text.vring_get_buf.constprop.83 .text.clear_usertimer .text.set_code_success .text.getComAddr .text.getLptAddr .text.__disk_ret_unimplemented.isra.8 .text.__disk_ret.isra.7 .text.basic_access .text.extended_access .text.disk_1300 .text.disk_1308 .text.disk_1310 .text.floppy_disable_controller .text.pci_next .text.timer_read .text.timer_check .text.timer_delay .text.udelay .text.ndelay.constprop.76 .text.putuint.isra.44 .text.fill_generic_edd .text.fill_edd .text.__dprintf .text.dump_regs .text.__warn_timeout .text.i8042_wait_write .text.__i8042_command .text.disk_1305 .text.panic .text.vring_add_buf.constprop.81 .text.handle_12 .text.handle_11 .text.handl e_05 .text.handle_02 .text.call16_smm_helper .text.call16_sloppy_helper .text.call32 .text.call32_params.constprop.91 .text.usb_poll_intr .text._farcall16 .text.__call16_int .text.handle_75 .text.disk_1346.isra.52 .text.disk_13 .text.handle_legacy_disk .text.process_key .text.prockeys .text.procmodkey .text.procscankey .text.check_irqs .text.virtio_blk_op .text.rtc_updating .text.ps2_recvbyte .text.ps2_sendbyte .text.__ps2_command .text.mouse_command .text.mouse_15c201 .text.handle_160a .text.uhci_waittick .text.ehci_send_pipe.constprop.80 .text.floppy_wait_irq .text.floppy_enable_controller .text.floppy_drive_pio .text.floppy_drive_readid.constprop.75 .text.floppy_read .text.floppy_write .text.await_ide.constprop.77 .text.await_not_bsy .text.send_cmd .text.ata_pio_transfer .text.ata_wait_data .text.ata_readwrite .text.atapi_cmd_data .text.uhci_send_pipe.constprop.79 .text.usb_send_pipe.constprop.78 .text.usb_cmd_data .text.uas_cmd_data .text.cdb_cmd_data .text.cdb_read .text.cdb_writ e .text.process_op .text.cdemu_read .text.wait_irq .text.handle_1553 .text.handle_40 .text.handle_13 .text.handle_76 .text.invoke_mouse_handler .text.process_mouse .text.handle_16 .text.handle_1589 .text.handle_14 .text.handle_17 .text.handle_1a .text.handle_70 .text.handle_resume .text.handle_pnp .text.handle_pcibios .text.handle_74 .text.handle_09 .text.handle_0e .text.asm.transition32 .text.asm.transition16 .text.asm.__farcall16 .text.asm.irq_trampoline_0x02 .text.asm.irq_trampoline_0x10 .text.asm.irq_trampoline_0x13 .text.asm.irq_trampoline_0x15 .text.asm.entry_smi .text.asm.entry_smp .text.asm.entry_resume .text.asm.entry_pmm .text.asm.entry_pnp_real .text.asm.entry_apm16 .text.asm.entry_apm32 .text.asm.entry_pcibios32 .text.asm.entry_pcibios16 .text.asm.entry_1589 .text.asm.entry_bios32 .text.asm.irqentry_extrastack .text.asm.irqentry_arg_extrastack .text.asm.entry_13 .text.asm.entry_76 .text.asm.entry_70 .text.asm.entry_74 .text.asm.entry_75 .text.asm.entry_hwpic1 .text.asm.ent ry_19 .text.asm.entry_18 .rodata .rodata.__func__.10501 .rodata.__func__.9961 .rodata.__func__.9285 .rodata.__func__.9243 .rodata.__func__.8917 .rodata.__func__.8897 .rodata.__func__.8122 .rodata.__func__.8164 .rodata.__func__.7497 .rodata.__func__.7521 .rodata.__func__.7388 .rodata.__func__.6574 .rodata.__func__.6635 .rodata.__func__.6583 .rodata.__func__.4214 .rodata.__func__.4529 .rodata.__func__.1830 .rodata.__func__.1817 .rodata.__func__.1809 BFD: rom16offset.o: section `.rodata.__func__.1809' can't be allocated in segment 0 LOAD: .text.set_a20 .text.pic_eoi2 .text.call32_smm_prep .text.call32_smm_post .text.call32_sloppy_prep .text.call32_sloppy_post .text.on_extra_stack .text.memset .text.memcpy .text.enqueue_key .text.ehci_reset_pipe .text.lba2chs .text.stack_hop_back .text.getLCHS .text.putsinglehex.isra.41 .text.puthex.isra.42 .text.puts_cs.isra.45 .text.vring_get_buf.constprop.83 .text.clear_usertimer .text.set_code_success .text.getComAddr .text.getLptAddr .text.__disk_ret_unimplemented.isra.8 .text.__disk_ret.isra.7 .text.basic_access .text.extended_access .text.disk_1300 .text.disk_1308 .text.disk_1310 .text.floppy_disable_controller .text.pci_next .text.timer_read .text.timer_check .text.timer_delay .text.udelay .text.ndelay.constprop.76 .text.putuint.isra.44 .text.fill_generic_edd .text.fill_edd .text.__dprintf .text.dump_regs .text.__warn_timeout .text.i8042_wait_write .text.__i8042_command .text.disk_1305 .text.panic .text.vring_add_buf.constprop.81 .text.handle_12 .text.handle_11 .text.handl e_05 .text.handle_02 .text.call16_smm_helper .text.call16_sloppy_helper .text.call32 .text.call32_params.constprop.91 .text.usb_poll_intr .text._farcall16 .text.__call16_int .text.handle_75 .text.disk_1346.isra.52 .text.disk_13 .text.handle_legacy_disk .text.process_key .text.prockeys .text.procmodkey .text.procscankey .text.check_irqs .text.virtio_blk_op .text.rtc_updating .text.ps2_recvbyte .text.ps2_sendbyte .text.__ps2_command .text.mouse_command .text.mouse_15c201 .text.handle_160a .text.uhci_waittick .text.ehci_send_pipe.constprop.80 .text.floppy_wait_irq .text.floppy_enable_controller .text.floppy_drive_pio .text.floppy_drive_readid.constprop.75 .text.floppy_read .text.floppy_write .text.await_ide.constprop.77 .text.await_not_bsy .text.send_cmd .text.ata_pio_transfer .text.ata_wait_data .text.ata_readwrite .text.atapi_cmd_data .text.uhci_send_pipe.constprop.79 .text.usb_send_pipe.constprop.78 .text.usb_cmd_data .text.uas_cmd_data .text.cdb_cmd_data .text.cdb_read .text.cdb_writ e .text.process_op .text.cdemu_read .text.wait_irq .text.handle_1553 .text.handle_40 .text.handle_13 .text.handle_76 .text.invoke_mouse_handler .text.process_mouse .text.handle_16 .text.handle_1589 .text.handle_14 .text.handle_17 .text.handle_1a .text.handle_70 .text.handle_resume .text.handle_pnp .text.handle_pcibios .text.handle_74 .text.handle_09 .text.handle_0e .text.asm.transition32 .text.asm.transition16 .text.asm.__farcall16 .text.asm.irq_trampoline_0x02 .text.asm.irq_trampoline_0x10 .text.asm.irq_trampoline_0x13 .text.asm.irq_trampoline_0x15 .text.asm.entry_smi .text.asm.entry_smp .text.asm.entry_resume .text.asm.entry_pmm .text.asm.entry_pnp_real .text.asm.entry_apm16 .text.asm.entry_apm32 .text.asm.entry_pcibios32 .text.asm.entry_pcibios16 .text.asm.entry_1589 .text.asm.entry_bios32 .text.asm.irqentry_extrastack .text.asm.irqentry_arg_extrastack .text.asm.entry_13 .text.asm.entry_76 .text.asm.entry_70 .text.asm.entry_74 .text.asm.entry_75 .text.asm.entry_hwpic1 .text.asm.ent ry_19 .text.asm.entry_18 .rodata .rodata.__func__.10501 .rodata.__func__.9961 .rodata.__func__.9285 .rodata.__func__.9243 .rodata.__func__.8917 .rodata.__func__.8897 .rodata.__func__.8122 .rodata.__func__.8164 .rodata.__func__.7497 .rodata.__func__.7521 .rodata.__func__.7388 .rodata.__func__.6574 .rodata.__func__.6635 .rodata.__func__.6583 .rodata.__func__.4214 .rodata.__func__.4529 .rodata.__func__.1830 .rodata.__func__.1817 .rodata.__func__.1809
AFAICT it contains some errors about not being able to relocate certain symbols.
$ gdb out/rom16.o (gdb) target remote localhost:1234 (gdb) set architecture i8086 (gdb) symbol-file rom16offset.o
gdb seems to complain a bit about this too:
Load new symbol table from "rom16offset.o"? (y or n) y Reading symbols from rom16offset.o...warning: Loadable section ".rodata.__func__.1817" outside of ELF segments warning: Loadable section ".rodata.__func__.1809" outside of ELF segments done.
(gdb) break handle_15 (gdb) continue
This seems to work fine while running the bootloader, I can see the breakpoint triggering. But once the FreeBSD kernel is running the breakpoint no longer triggers, although I'm sure handle_15 is being called (at least the debug output from SeaBIOS shows it being called).
Roger.
On Thu, Apr 16, 2015 at 01:46:41PM +0200, Roger Pau Monné wrote:
I've tried this, the function is handle_15c0. This happens quite late in the boot process, the FreeBSD code that triggers this issue is at:
Is it possible you are running into:
http://lists.nongnu.org/archive/html/qemu-devel/2013-03/msg01311.html
If freebsd is using x86emu to interpret the bios, then I'm not surprised it is having problems. In a previous mail, you indicated a freebsd compiled seabios caused crashes under Linux - can you confirm it crashes on non-freebsd guests (ie, linux, windows, dos, etc)?
-Kevin
Hello,
El 16/04/15 a les 15.56, Kevin O'Connor ha escrit:
On Thu, Apr 16, 2015 at 01:46:41PM +0200, Roger Pau Monné wrote:
I've tried this, the function is handle_15c0. This happens quite late in the boot process, the FreeBSD code that triggers this issue is at:
Is it possible you are running into:
http://lists.nongnu.org/archive/html/qemu-devel/2013-03/msg01311.html
Might be... I'm not familiar with this code at all, but I will try to see if I can figure out what's going on.
If freebsd is using x86emu to interpret the bios, then I'm not surprised it is having problems. In a previous mail, you indicated a freebsd compiled seabios caused crashes under Linux - can you confirm it crashes on non-freebsd guests (ie, linux, windows, dos, etc)?
I've tried booting Ubuntu using the _broken_ SeaBIOS, and it seems to work fine, I can see calls to handle_15c0 succeeding:
(d10) enter handle_15c0: (d10) a=0000c000 b=00000000 c=00000000 d=00000000 ds=1000 es=1000 ss=df80 (d10) si=00000000 di=00000000 bp=00000000 sp=0000f9f6 cs=1000 ip=02fd f=0003
So it seems like the problem is only triggered when booting FreeBSD guests with this specific SeaBIOS build.
Roger.
On Thu, Apr 16, 2015 at 05:23:20PM +0200, Roger Pau Monné wrote:
Hello,
El 16/04/15 a les 15.56, Kevin O'Connor ha escrit:
On Thu, Apr 16, 2015 at 01:46:41PM +0200, Roger Pau Monné wrote:
I've tried this, the function is handle_15c0. This happens quite late in the boot process, the FreeBSD code that triggers this issue is at:
Is it possible you are running into:
http://lists.nongnu.org/archive/html/qemu-devel/2013-03/msg01311.html
Might be... I'm not familiar with this code at all, but I will try to see if I can figure out what's going on.
If freebsd is using x86emu to interpret the bios, then I'm not surprised it is having problems. In a previous mail, you indicated a freebsd compiled seabios caused crashes under Linux - can you confirm it crashes on non-freebsd guests (ie, linux, windows, dos, etc)?
I've tried booting Ubuntu using the _broken_ SeaBIOS, and it seems to work fine, I can see calls to handle_15c0 succeeding:
(d10) enter handle_15c0: (d10) a=0000c000 b=00000000 c=00000000 d=00000000 ds=1000 es=1000 ss=df80 (d10) si=00000000 di=00000000 bp=00000000 sp=0000f9f6 cs=1000 ip=02fd f=0003
So it seems like the problem is only triggered when booting FreeBSD guests with this specific SeaBIOS build.
Seems like the same problem. You wont be able to set a gdb breakpoint for the freebsd call because freebsd isn't calling the bios - it's attempting to interpret the bios code.
Does the seabios patch below fix the problem for you?
-Kevin
--- a/src/system.c +++ b/src/system.c @@ -334,6 +334,7 @@ handle_15XX(struct bregs *regs) void VISIBLE16 handle_15(struct bregs *regs) { + trap_x86emu(); debug_enter(regs, DEBUG_HDL_15); switch (regs->ah) { case 0x24: handle_1524(regs); break; diff --git a/src/x86.h b/src/x86.h index 14ebb7d..865dcbe 100644 --- a/src/x86.h +++ b/src/x86.h @@ -75,6 +75,18 @@ static inline void __cpuid(u32 index, u32 *eax, u32 *ebx, u32 *ecx, u32 *edx) : "0" (index)); }
+static inline void trap_x86emu(void) { + // Force a fault if running on x86emu (enterl insn not working properly) + asm volatile ( + "movl %%esp, %%ecx\n" + "enterl $0, $0\n" + "popl %%ebp\n" + "cmpl %%ecx, %%esp\n" + "je 1f\n" + "hlt\n" + "1:" : : : "ecx", "cc"); +} + static inline u32 getcr0(void) { u32 cr0; asm("movl %%cr0, %0" : "=r"(cr0));
El 16/04/15 a les 17.52, Kevin O'Connor ha escrit:
Seems like the same problem. You wont be able to set a gdb breakpoint for the freebsd call because freebsd isn't calling the bios - it's attempting to interpret the bios code.
Does the seabios patch below fix the problem for you?
Seems to kind of fix it, but it's hard to tell.
Most of the time the original SeaBIOS binary works without problems. There's sometimes were the int 0x15 call with ah=0xc0 returns what seem to be valid values in ah and flg, but the values in es and bx are corrupted so when freebsd tries to access this region (es << 4 + bx) it gets a page fault.
This is what I see now with the patch applied:
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0 atkbd0: <AT Keyboard> irq 1 on atkbdc0 Calling INT 0x15 (ax=0xc000 bx=0x0000 cx=0x0000 dx=0x0000 es=0x0000 di=0x0000) Exiting INT 0x15 (ax=0xf9c0 bx=0xf9c0 cx=0xf99e dx=0xdf80 es=0x0000 di=0x0000) kbd0 at atkbd0 atkbd0: [GIANT-LOCKED]
Without the patch:
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0 atkbd0: <AT Keyboard> irq 1 on atkbdc0 Calling INT 0x15 (ax=0xc000 bx=0x0000 cx=0x0000 dx=0x0000 es=0x0000 di=0x0000) Exiting INT 0x15 (ax=0x2018 bx=0x2073 cx=0xdb0d dx=0x00e9 es=0x0000 di=0x0004) kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: <PS/2 Mouse> irq 12 on at
Roger.
On Thu, Apr 16, 2015 at 06:37:29PM +0200, Roger Pau Monné wrote:
El 16/04/15 a les 17.52, Kevin O'Connor ha escrit:
Seems like the same problem. You wont be able to set a gdb breakpoint for the freebsd call because freebsd isn't calling the bios - it's attempting to interpret the bios code.
Does the seabios patch below fix the problem for you?
Seems to kind of fix it, but it's hard to tell.
Most of the time the original SeaBIOS binary works without problems. There's sometimes were the int 0x15 call with ah=0xc0 returns what seem to be valid values in ah and flg, but the values in es and bx are corrupted so when freebsd tries to access this region (es << 4 + bx) it gets a page fault.
This is what I see now with the patch applied:
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0 atkbd0: <AT Keyboard> irq 1 on atkbdc0 Calling INT 0x15 (ax=0xc000 bx=0x0000 cx=0x0000 dx=0x0000 es=0x0000 di=0x0000) Exiting INT 0x15 (ax=0xf9c0 bx=0xf9c0 cx=0xf99e dx=0xdf80 es=0x0000 di=0x0000) kbd0 at atkbd0 atkbd0: [GIANT-LOCKED]
Ah, looks like the freebsd code isn't even checking if x86emu exited abnormally.
To summarize, this looks to be the same problem that I investigated two years ago:
http://lists.nongnu.org/archive/html/qemu-devel/2013-03/msg01311.html
Basically, freebsd is attempting to interpret the x86 bios code, but it is using an incomplete interpreter that misinterprets some x86 instructions. That broken interpreter could cause page faults, loop forever, or return bogus values.
Ironically, all this is done to find out the BIOS "keyboard repeat rate" - I don't know why anyone would even care what the BIOS set the keyboard rate to.
I think this needs to be fixed in the freebsd kernel. Until it is fixed, minor changes to the seabios code layout could lead to random crashes in the freebsd kernel.
-Kevin
Hello,
El 16/04/15 a les 19.51, Kevin O'Connor ha escrit:
On Thu, Apr 16, 2015 at 06:37:29PM +0200, Roger Pau Monné wrote:
El 16/04/15 a les 17.52, Kevin O'Connor ha escrit:
Seems like the same problem. You wont be able to set a gdb breakpoint for the freebsd call because freebsd isn't calling the bios - it's attempting to interpret the bios code.
Does the seabios patch below fix the problem for you?
Seems to kind of fix it, but it's hard to tell.
Most of the time the original SeaBIOS binary works without problems. There's sometimes were the int 0x15 call with ah=0xc0 returns what seem to be valid values in ah and flg, but the values in es and bx are corrupted so when freebsd tries to access this region (es << 4 + bx) it gets a page fault.
This is what I see now with the patch applied:
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0 atkbd0: <AT Keyboard> irq 1 on atkbdc0 Calling INT 0x15 (ax=0xc000 bx=0x0000 cx=0x0000 dx=0x0000 es=0x0000 di=0x0000) Exiting INT 0x15 (ax=0xf9c0 bx=0xf9c0 cx=0xf99e dx=0xdf80 es=0x0000 di=0x0000) kbd0 at atkbd0 atkbd0: [GIANT-LOCKED]
Ah, looks like the freebsd code isn't even checking if x86emu exited abnormally.
Yes, this is something that can be solved without much work AFAICT, so that we know if the emulator exited correctly or not. However this is only a side-effect of what's actually happening.
To summarize, this looks to be the same problem that I investigated two years ago:
http://lists.nongnu.org/archive/html/qemu-devel/2013-03/msg01311.html
Basically, freebsd is attempting to interpret the x86 bios code, but it is using an incomplete interpreter that misinterprets some x86 instructions. That broken interpreter could cause page faults, loop forever, or return bogus values.
I've added a little bit more debug to the FreeBSD kernel and x86emu in order to see what's going on. It seems like SeaBIOS contains VERR/VERW instructions (or x86emu in FreeBSD thinks so, but maybe this is just the fail over of some badly emulated instructions), which x86emu doesn't know how to handle, can this be the case?
I've added a instruction trace to know what's going on, here is the output:
atkbd0: <AT Keyboard> irq 1 on atkbdc0 Calling INT 0x15 (ax=0xc000 bx=0x0000 cx=0x0000 dx=0x0000 es=0x0000 di=0x0000) Exec one byte: 0x80 Exec one byte: 0xf Exec two byte: 0x84 Exec one byte: 0x66 Exec one byte: 0x68 Exec one byte: 0xe9 Exec one byte: 0xfa Exec one byte: 0xfc Exec one byte: 0x1e Exec one byte: 0x66 Exec one byte: 0x50 Exec one byte: 0x66 Exec one byte: 0xb8 Exec one byte: 0x8e Exec one byte: 0x66 Exec one byte: 0xa1 Exec one byte: 0x66 Exec one byte: 0x83 Exec one byte: 0x67 Exec one byte: 0x66 Exec one byte: 0x8f Exec one byte: 0x67 Exec one byte: 0x8f Exec one byte: 0x67 Exec one byte: 0x66 Exec one byte: 0x89 Exec one byte: 0x67 Exec one byte: 0x66 Exec one byte: 0x89 Exec one byte: 0x67 Exec one byte: 0x66 Exec one byte: 0x89 Exec one byte: 0x67 Exec one byte: 0x66 Exec one byte: 0x89 Exec one byte: 0x67 Exec one byte: 0x66 Exec one byte: 0x89 Exec one byte: 0x67 Exec one byte: 0x66 Exec one byte: 0x89 Exec one byte: 0x67 Exec one byte: 0x8c Exec one byte: 0x66 Exec one byte: 0x59 Exec one byte: 0x67 Exec one byte: 0x66 Exec one byte: 0x89 Exec one byte: 0x67 Exec one byte: 0x8c Exec one byte: 0x67 Exec one byte: 0x66 Exec one byte: 0x8f Exec one byte: 0x67 Exec one byte: 0x8f Exec one byte: 0x8c Exec one byte: 0x8e Exec one byte: 0x66 Exec one byte: 0x89 Exec one byte: 0x66 Exec one byte: 0xff Exec one byte: 0x66 Exec one byte: 0x55 Exec one byte: 0x66 Exec one byte: 0x57 Exec one byte: 0x66 Exec one byte: 0x56 Exec one byte: 0x66 Exec one byte: 0x53 Exec one byte: 0x66 Exec one byte: 0x83 Exec one byte: 0x66 Exec one byte: 0x89 Exec one byte: 0x66 Exec one byte: 0xba Exec one byte: 0x66 Exec one byte: 0xe8 Exec one byte: 0x66 Exec one byte: 0x83 Exec one byte: 0x67 Exec one byte: 0x66 Exec one byte: 0x89 Exec one byte: 0x67 Exec one byte: 0x66 Exec one byte: 0x89 Exec one byte: 0x67 Exec one byte: 0x66 Exec one byte: 0xc7 Exec one byte: 0x66 Exec one byte: 0xe8 Exec one byte: 0x67 Exec one byte: 0x66 Exec one byte: 0x8d Exec one byte: 0x67 Exec one byte: 0x66 Exec one byte: 0x8b Exec one byte: 0x66 Exec one byte: 0xe8 Exec one byte: 0x66 Exec one byte: 0x55 Exec one byte: 0x66 Exec one byte: 0x57 Exec one byte: 0x66 Exec one byte: 0x56 Exec one byte: 0x66 Exec one byte: 0x53 Exec one byte: 0x66 Exec one byte: 0x51 Exec one byte: 0x66 Exec one byte: 0x89 Exec one byte: 0x66 Exec one byte: 0x89 Exec one byte: 0x2e Exec one byte: 0x67 Exec one byte: 0x8a Exec one byte: 0x84 Exec one byte: 0xf Exec two byte: 0x84 Exec one byte: 0x3c Exec one byte: 0x74 Exec one byte: 0x2e Exec one byte: 0x8b Exec one byte: 0xe9 Exec one byte: 0xee Exec one byte: 0x66 Exec one byte: 0x89 Exec one byte: 0x67 Exec one byte: 0x66 Exec one byte: 0x8d Exec one byte: 0xe9 Exec one byte: 0x2e Exec one byte: 0x67 Exec one byte: 0x8a Exec one byte: 0x84 Exec one byte: 0xf Exec two byte: 0x84 Exec one byte: 0x3c Exec one byte: 0x74 Exec one byte: 0x2e Exec one byte: 0x8b Exec one byte: 0xe9 Exec one byte: 0xee Exec one byte: 0x66 Exec one byte: 0x89 Exec one byte: 0x67 Exec one byte: 0x66 Exec one byte: 0x8d Exec one byte: 0xe9 Exec one byte: 0x2e Exec one byte: 0x67 Exec one byte: 0x8a Exec one byte: 0x84 Exec one byte: 0xf Exec two byte: 0x84 Exec one byte: 0x3c Exec one byte: 0x74 Exec one byte: 0x2e Exec one byte: 0x8b Exec one byte: 0xe9 Exec one byte: 0xee Exec one byte: 0x66 Exec one byte: 0x89 Exec one byte: 0x67 Exec one byte: 0x66 Exec one byte: 0x8d Exec one byte: 0xe9 Exec one byte: 0x2e Exec one byte: 0x67 Exec one byte: 0x8a Exec one byte: 0x84 Exec one byte: 0xf Exec two byte: 0x84 Exec one byte: 0x3c Exec one byte: 0x74 Exec one byte: 0x2e Exec one byte: 0x8b Exec one byte: 0xe9 Exec one byte: 0xee Exec one byte: 0x66 Exec one byte: 0x89 Exec one byte: 0x67 Exec one byte: 0x66 Exec one byte: 0x8d Exec one byte: 0xe9 Exec one byte: 0x2e Exec one byte: 0x67 Exec one byte: 0x8a Exec one byte: 0x84 Exec one byte: 0xf Exec two byte: 0x84 Exec one byte: 0x3c Exec one byte: 0x74 Exec one byte: 0x2e Exec one byte: 0x8b Exec one byte: 0xe9 Exec one byte: 0xee Exec one byte: 0x66 Exec one byte: 0x89 Exec one byte: 0x67 Exec one byte: 0x66 Exec one byte: 0x8d Exec one byte: 0xe9 Exec one byte: 0x2e Exec one byte: 0x67 Exec one byte: 0x8a Exec one byte: 0x84 Exec one byte: 0xf Exec two byte: 0x84 Exec one byte: 0x3c Exec one byte: 0x74 Exec one byte: 0x2e Exec one byte: 0x8b Exec one byte: 0xe9 Exec one byte: 0xee Exec one byte: 0x66 Exec one byte: 0x89 Exec one byte: 0x67 Exec one byte: 0x66 Exec one byte: 0x8d Exec one byte: 0xe9 Exec one byte: 0x2e Exec one byte: 0x67 Exec one byte: 0x8a Exec one byte: 0x84 Exec one byte: 0xf Exec two byte: 0x84 Exec one byte: 0x3c Exec one byte: 0x74 Exec one byte: 0x67 Exec one byte: 0x66 Exec one byte: 0x8d Exec one byte: 0x67 Exec one byte: 0xc6 x86emuOp_mov_byte_RM_IMM: CS 0xf000 IP 0xf896 x86emuOp_mov_byte_RM_IMM: mod 0x1 rl 0x4 rh 0x0 Exec one byte: 0x66 Exec one byte: 0x31 Exec one byte: 0x2e Exec one byte: 0x67 Exec one byte: 0x8a Exec one byte: 0x67 Exec one byte: 0x88 Exec one byte: 0x88 Exec one byte: 0x67 Exec one byte: 0x66 Exec one byte: 0x8d Exec one byte: 0x66 Exec one byte: 0x89 Exec one byte: 0x3c Exec one byte: 0x77 Exec one byte: 0x66 Exec one byte: 0x89 Exec one byte: 0x66 Exec one byte: 0x31 Exec one byte: 0x80 Exec one byte: 0x75 Exec one byte: 0x80 Exec one byte: 0x74 Exec one byte: 0x7f Exec one byte: 0x80 Exec one byte: 0xf Exec two byte: 0x84 Exec one byte: 0x67 Exec one byte: 0x66 Exec one byte: 0x8d Exec one byte: 0x67 Exec one byte: 0x66 Exec one byte: 0x8b Exec one byte: 0x66 Exec one byte: 0xe8 Exec one byte: 0x66 Exec one byte: 0x89 Exec one byte: 0x2e Exec one byte: 0x67 Exec one byte: 0x8a Exec one byte: 0x84 Exec one byte: 0x74 Exec one byte: 0x2e Exec one byte: 0x8b Exec one byte: 0xee Exec one byte: 0x66 Exec one byte: 0x41 Exec one byte: 0xeb Exec one byte: 0x2e Exec one byte: 0x67 Exec one byte: 0x8a Exec one byte: 0x84 Exec one byte: 0x74 Exec one byte: 0x2e Exec one byte: 0x8b Exec one byte: 0xee Exec one byte: 0x66 Exec one byte: 0x41 Exec one byte: 0xeb Exec one byte: 0x2e Exec one byte: 0x67 Exec one byte: 0x8a Exec one byte: 0x84 Exec one byte: 0x74 Exec one byte: 0x2e Exec one byte: 0x8b Exec one byte: 0xee Exec one byte: 0x66 Exec one byte: 0x41 Exec one byte: 0xeb Exec one byte: 0x2e Exec one byte: 0x67 Exec one byte: 0x8a Exec one byte: 0x84 Exec one byte: 0x74 Exec one byte: 0x2e Exec one byte: 0x8b Exec one byte: 0xee Exec one byte: 0x66 Exec one byte: 0x41 Exec one byte: 0xeb Exec one byte: 0x2e Exec one byte: 0x67 Exec one byte: 0x8a Exec one byte: 0x84 Exec one byte: 0x74 Exec one byte: 0x2e Exec one byte: 0x8b Exec one byte: 0xee Exec one byte: 0x66 Exec one byte: 0x41 Exec one byte: 0xeb Exec one byte: 0x2e Exec one byte: 0x67 Exec one byte: 0x8a Exec one byte: 0x84 Exec one byte: 0x74 Exec one byte: 0x2e Exec one byte: 0x8b Exec one byte: 0xee Exec one byte: 0x66 Exec one byte: 0x41 Exec one byte: 0xeb Exec one byte: 0x2e Exec one byte: 0x67 Exec one byte: 0x8a Exec one byte: 0x84 Exec one byte: 0x74 Exec one byte: 0x2e Exec one byte: 0x8b Exec one byte: 0xee Exec one byte: 0x66 Exec one byte: 0x41 Exec one byte: 0xeb Exec one byte: 0x2e Exec one byte: 0x67 Exec one byte: 0x8a Exec one byte: 0x84 Exec one byte: 0x74 Exec one byte: 0x2e Exec one byte: 0x8b Exec one byte: 0xee Exec one byte: 0x66 Exec one byte: 0x41 Exec one byte: 0xeb Exec one byte: 0x2e Exec one byte: 0x67 Exec one byte: 0x8a Exec one byte: 0x84 Exec one byte: 0x74 Exec one byte: 0x2e Exec one byte: 0x8b Exec one byte: 0xee Exec one byte: 0x66 Exec one byte: 0x41 Exec one byte: 0xeb Exec one byte: 0x2e Exec one byte: 0x67 Exec one byte: 0x8a Exec one byte: 0x84 Exec one byte: 0x74 Exec one byte: 0x66 Exec one byte: 0xc3 Exec one byte: 0x66 Exec one byte: 0x89 Exec one byte: 0xeb Exec one byte: 0x67 Exec one byte: 0x66 Exec one byte: 0x8d Exec one byte: 0xe9 Exec one byte: 0x2e Exec one byte: 0x67 Exec one byte: 0x8a Exec one byte: 0x84 Exec one byte: 0xf Exec two byte: 0x84 Exec one byte: 0x3c Exec one byte: 0x74 Exec one byte: 0x2e Exec one byte: 0x8b Exec one byte: 0xe9 Exec one byte: 0xee Exec one byte: 0x66 Exec one byte: 0x89 Exec one byte: 0x67 Exec one byte: 0x66 Exec one byte: 0x8d Exec one byte: 0xe9 Exec one byte: 0x2e Exec one byte: 0x67 Exec one byte: 0x8a Exec one byte: 0x84 Exec one byte: 0xf Exec two byte: 0x84 Exec one byte: 0x3c Exec one byte: 0x74 Exec one byte: 0x2e Exec one byte: 0x8b Exec one byte: 0xe9 Exec one byte: 0xee Exec one byte: 0x66 Exec one byte: 0x89 Exec one byte: 0x67 Exec one byte: 0x66 Exec one byte: 0x8d Exec one byte: 0xe9 Exec one byte: 0x2e Exec one byte: 0x67 Exec one byte: 0x8a Exec one byte: 0x84 Exec one byte: 0xf Exec two byte: 0x84 Exec one byte: 0x66 Exec one byte: 0x58 Exec one byte: 0x66 Exec one byte: 0x5b Exec one byte: 0x66 Exec one byte: 0x5e Exec one byte: 0x66 Exec one byte: 0x5f Exec one byte: 0x66 Exec one byte: 0x5d Exec one byte: 0x66 Exec one byte: 0xc3 Exec one byte: 0xf0 Exec one byte: 0xee Exec one byte: 0xb0 Exec one byte: 0xee Exec one byte: 0x8d Exec one byte: 0x14 Exec one byte: 0xda Exec one byte: 0xf Exec two byte: 0x0 Unknown 2byte op 0x0 Halting system: /usr/src/sys/contrib/x86emu/x86emu.c:5959 System halted! Exiting INT 0x15 (ax=0x00a9 bx=0x2073 cx=0x0024 dx=0x00e9 es=0x0000 di=0x0000)
Roger.
On Mon, Apr 20, 2015 at 04:28:03PM +0200, Roger Pau Monné wrote:
Hello,
El 16/04/15 a les 19.51, Kevin O'Connor ha escrit:
On Thu, Apr 16, 2015 at 06:37:29PM +0200, Roger Pau Monné wrote:
El 16/04/15 a les 17.52, Kevin O'Connor ha escrit:
Seems like the same problem. You wont be able to set a gdb breakpoint for the freebsd call because freebsd isn't calling the bios - it's attempting to interpret the bios code.
Does the seabios patch below fix the problem for you?
Seems to kind of fix it, but it's hard to tell.
Most of the time the original SeaBIOS binary works without problems. There's sometimes were the int 0x15 call with ah=0xc0 returns what seem to be valid values in ah and flg, but the values in es and bx are corrupted so when freebsd tries to access this region (es << 4 + bx) it gets a page fault.
This is what I see now with the patch applied:
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0 atkbd0: <AT Keyboard> irq 1 on atkbdc0 Calling INT 0x15 (ax=0xc000 bx=0x0000 cx=0x0000 dx=0x0000 es=0x0000 di=0x0000) Exiting INT 0x15 (ax=0xf9c0 bx=0xf9c0 cx=0xf99e dx=0xdf80 es=0x0000 di=0x0000) kbd0 at atkbd0 atkbd0: [GIANT-LOCKED]
Ah, looks like the freebsd code isn't even checking if x86emu exited abnormally.
Yes, this is something that can be solved without much work AFAICT, so that we know if the emulator exited correctly or not. However this is only a side-effect of what's actually happening.
If changing freebsd code, I would change it to set the repeat rate to a standard default irrespective of what the bios uses, and thus not call the bios at all.
To summarize, this looks to be the same problem that I investigated two years ago:
http://lists.nongnu.org/archive/html/qemu-devel/2013-03/msg01311.html
Basically, freebsd is attempting to interpret the x86 bios code, but it is using an incomplete interpreter that misinterprets some x86 instructions. That broken interpreter could cause page faults, loop forever, or return bogus values.
I've added a little bit more debug to the FreeBSD kernel and x86emu in order to see what's going on. It seems like SeaBIOS contains VERR/VERW instructions (or x86emu in FreeBSD thinks so, but maybe this is just the fail over of some badly emulated instructions), which x86emu doesn't know how to handle, can this be the case?
Yes. It is known that x86emu does not properly emulate the calll, retl, leavel, and leal instructions (32bit forms of call, ret, leave and lea). There are other unsupported instructions as well (eg, smsww, outsb, enterl), but these are less problamatic because gcc doesn't emit them.
Because x86emu is used so frequently with vga bios, SeaVGABIOS has code to fixup the gcc assembler to avoid the above instructions - see scripts/vgafixup.py .
-Kevin
Hello,
El 20/04/15 a les 17.20, Kevin O'Connor ha escrit:
On Mon, Apr 20, 2015 at 04:28:03PM +0200, Roger Pau Monné wrote:
Hello,
El 16/04/15 a les 19.51, Kevin O'Connor ha escrit:
On Thu, Apr 16, 2015 at 06:37:29PM +0200, Roger Pau Monné wrote:
El 16/04/15 a les 17.52, Kevin O'Connor ha escrit:
Seems like the same problem. You wont be able to set a gdb breakpoint for the freebsd call because freebsd isn't calling the bios - it's attempting to interpret the bios code.
Does the seabios patch below fix the problem for you?
Seems to kind of fix it, but it's hard to tell.
Most of the time the original SeaBIOS binary works without problems. There's sometimes were the int 0x15 call with ah=0xc0 returns what seem to be valid values in ah and flg, but the values in es and bx are corrupted so when freebsd tries to access this region (es << 4 + bx) it gets a page fault.
This is what I see now with the patch applied:
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0 atkbd0: <AT Keyboard> irq 1 on atkbdc0 Calling INT 0x15 (ax=0xc000 bx=0x0000 cx=0x0000 dx=0x0000 es=0x0000 di=0x0000) Exiting INT 0x15 (ax=0xf9c0 bx=0xf9c0 cx=0xf99e dx=0xdf80 es=0x0000 di=0x0000) kbd0 at atkbd0 atkbd0: [GIANT-LOCKED]
Ah, looks like the freebsd code isn't even checking if x86emu exited abnormally.
Yes, this is something that can be solved without much work AFAICT, so that we know if the emulator exited correctly or not. However this is only a side-effect of what's actually happening.
If changing freebsd code, I would change it to set the repeat rate to a standard default irrespective of what the bios uses, and thus not call the bios at all.
Following commit gets rid of the usage of the BIOS from atkbd:
https://svnweb.freebsd.org/base?view=revision&revision=282269
The remaining usage of x86emu should be fine AFAICT because it's only used with int10h. I will backport it to stable branches in two weeks, so next FreeBSD releases should be fine.
Roger.
On Thu, Apr 30, 2015 at 09:06:37AM +0200, Roger Pau Monné wrote:
El 20/04/15 a les 17.20, Kevin O'Connor ha escrit:
If changing freebsd code, I would change it to set the repeat rate to a standard default irrespective of what the bios uses, and thus not call the bios at all.
Following commit gets rid of the usage of the BIOS from atkbd:
https://svnweb.freebsd.org/base?view=revision&revision=282269
The remaining usage of x86emu should be fine AFAICT because it's only used with int10h. I will backport it to stable branches in two weeks, so next FreeBSD releases should be fine.
Thanks!
-Kevin
-
Idwer Vollering -
Kevin O'Connor -
Roger Pau Monné