ron minnich wrote:
> Ah,the A5 BSOD, the bane of my life.
> This is an ACPI issue.
> That last paramter, 494e495f, is a *CLUE*. It is ASCII. It is _INI. No
> idea if that helps.
> There is more info available ... just google Windows A5 Stop.
Excerpt from KB 314830 :
(0x00000003, Parameter2, Parameter3, Parameter4):
This error is defined as "ACPI failed must succeed method."
This error occurs if ACPI cannot build a control method to
reference the ACPI namespace. Other arguments for this error
reference the ACPI object that was being run and the name of
the control method. One greatly simplified explanation (which
might not be completely accurate) is that the system cannot
find a way to get to the ACPI tables that define the Plug and
Play and Power Management capabilities of the system.
This patch series reduces the overall stack usage of the 16bit code.
The biggest change is the enhancment of the "extra stack" in the
e-segment to be re-entrant. The "extra stack" was previously used
only by the resume code and disk code. It has been made more flexible
so that it can be used by other callers. After this series, SeaBIOS
will never expose the extra stack to any external code - on any irq
enable or external call point SeaBIOS will jump back to the original
stack first. Because the extra stack is only used by SeaBIOS code
now, the stack space in use can be tracked and re-entrant callers can
be handled safely.
All of the hardware irq handlers have been updated to jump into the
extra stack upon being called. This makes the stack space used by
SeaBIOS based hardware irq handlers virtually zero.
Kevin O'Connor (13):
Rename wait_irq to yield_toirq.
Don't restrict VISIBLEx C functions to only x mode.
Rename call16 to farcall16.
Move farcall16 code from util.c to stacks.c and reorg stacks.c.
Replace 32bit->16bit farcall system with regular calls.
Make the extra stack re-entrant and "hop back" to check for irqs.
Automatically hop off the extra stack when far calling 16bit code.
Run all hardware irq handlers on the extra stack.
Use the extra stack for 16bit USB and PS2 keyboard/mouse commands.
Remove "noinline" declarations from keyboard/mouse driver code.
Set noinline on kbd.c interface functions that take stack variable
Make sure to set dependency to segment registers in inline asm.
Rework disk.c:fillLCHS to avoid using pointer parameters.
src/apm.c | 15 +--
src/asm-offsets.c | 1 +
src/boot.c | 6 +-
src/clock.c | 22 +++--
src/disk.c | 40 ++++----
src/disk.h | 1 +
src/floppy.c | 8 +-
src/kbd.c | 30 +++---
src/misc.c | 14 ++-
src/mouse.c | 63 ++++++-----
src/optionroms.c | 2 +-
src/output.c | 9 --
src/post.c | 3 +
src/ps2port.c | 8 +-
src/resume.c | 2 +-
src/romlayout.S | 153 ++++++++++++++++++---------
src/stacks.c | 285 ++++++++++++++++++++++++++++++++++-----------------
src/system.c | 6 +-
src/types.h | 16 ++--
src/usb-hid.c | 2 +-
src/usb.c | 2 +-
src/util.c | 62 ++----------
src/util.h | 47 +++------
tools/checkstack.py | 2 +-
24 files changed, 439 insertions(+), 360 deletions(-)
Le 26/05/2012 14:06, Fred . a écrit :
> Is there any x86 operating system that SeaBIOS can not boot?
> SeaBIOS mailing list
SeaBIOS is not currently (1.6.3) fully able to boot W98SE.
That is just for information, I am in fact quite happy to be able to use
a new box with W98SE.
I am currently upgrading from a quite old and deceased box with W98SE on
it to a QEMU/SeaBIOS brand new box.
After some expected difficulties mostly linked to get proper
information, I am now trying to assess the interaction between
QEMU/Seabios and W98SE. I can say that during the upgrade process, W98SE
recognize SeaBIOS as "BIOS Plug-and-Play", something new to install but
W98SE consider it as not functioning properly. If you let W98SE try to
install it, it crash with no progress at reboot. If you don't let it
install it, it does not crash and at the end of the upgrade it is able
to reboot, but not exactly normally, even if you are able to use it. I
will commit a full report.
So, for me, SeaBIOS is not currently (1.6.3) fully able to boot W98SE.
Can SeaBIOS be used with VirtualBox?
Why isn't SeaBIOS the default BIOS in VirtualBox?
Since VirtualBox is open source, can or does the SeaBIOS project look
at the source code
of the BIOS implementation in VirtualBox for hints how things are done?
Can SeaBIOS be used with VMware?