qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Maciek Bieszczad" <mbiesz@gmail.com>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] Towards Vista RTM compatibility
Date: Mon, 27 Nov 2006 01:46:12 -0000	[thread overview]
Message-ID: <000001c711c5$e1416fa0$a3c44ee0$@com> (raw)

Beginning with at least the later Beta 2 builds of Windows Vista, any
attempt to boot from the installation DVD comes with an instant blue-screen
in the form:

Stop error: 0xA5 (0x1000B, [addr], addr, 0)

where "addr" points to the signature of the FADT (which is "FACP"). The
origin of the error seems to be the HalpAcpiValidateAcpiTable function in
hal.dll, which basically does the following:

if header[signature] != "FACP"
	return 0
if header[revision] == 0
	return STATUS_ACPI_INVALID_DATA
else if header[revision] == 1
	length = 0x74
else if header[revision] == 2
	length = 0x81
else if header[revision] >= 3
	length = 0xF4
if header[length] >= length
	return 0
else
	return STATUS_ACPI_INVALID_DATA

Looking into the BOCHS BIOS code, the revision field was indeed set to 0.
After changing the value to 1, the boot process gets much further, even past
the default boot screen with the green scrolling bar. 

However, once the video mode changes a final time before what presumably
would be the setup GUI, another stop error immediately shows up with the
following vital data:

PAGE_FAULT_IN_NONPAGED_AREA
*** STOP: 0x00000050 (0x85DDDF66, 0x00000001, 0x8624AFFA, 0x00000002)
*** win32k.sys - Address 8624AFFA base at 86200000, DateStamp 4549aea2

The first error parameter corresponds to the invalid memory accessed, the
"1" indicates it was a write operation, and the third refers to the address
of the fatal instruction. This is extremely strange, considering 0x85DDDF66
seems to be a perfectly plausible address for the driver's relocated data
segment.

Unfortunately, the WinDbg/serial-pipe patches out there seem to be broken
ATM, and I can't get the debugger to connect (after hitting F8, and
selecting "Debugging mode" which should open a session with the highest
enumerated serial port). Disassembly of win32k.sys doesn't help much, other
than indicating the write takes place in a function involved with the SDPVTL
TrueType instruction.

For the record, I am currently testing with the final Vista RTM build and a
fresh CVS checkout of QEMU and BOCHS BIOS (other than the fix I mentioned).

Any ideas?

Maciek

             reply	other threads:[~2006-11-27  1:46 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-27  1:46 Maciek Bieszczad [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-11-27  4:07 [Qemu-devel] Towards Vista RTM compatibility Maciek Bieszczad

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='000001c711c5$e1416fa0$a3c44ee0$@com' \
    --to=mbiesz@gmail.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).