13.06.2013 11:51, Michael Tokarev wrote:
I tried to bisect this. It turns out that solaris x86 does not boot in qemu/kvm for quite long time already, namely, starting from this commit:
commit 6b034aa138716a515c88f7894940d5d0aff2f3ed Author: Gerd Hoffmann kraxel@redhat.com Date: Tue Apr 17 10:51:41 2012 +0200
seabios: update to 1.7.0
Update roms/seabios and pc-bios/bios.bin to the 1.7.0 release. Most noticable new feature is virtio-scsi support.
Signed-off-by: Gerd Hoffmann kraxel@redhat.com
So I went on and tried to bisect seabios (previous version in qemu was 1.6.3.2, and it worked).
So seabios bisection with qemu-1.1 points to this commit:
commit 9d3d7cb4b163d3fbcba64a01c4fa42eb6bc53128 Author: Kevin O'Connor kevin@koconnor.net Date: Wed Sep 21 21:19:51 2011 -0400
Move code from PCI hotplug DSDT macros to methods.
Simplify the hotplug code by moving the bulk of the logic out of the macros and into static method definitions. This also reduces the ACPI DSDT code size.
Signed-off-by: Kevin O'Connor kevin@koconnor.net
Now, I don't really understand what's going on there... ;)
And since this is DSDT, using seabios 1.6 with recent qemu does not solve the problem, since DSDT is now external/separate.
Thanks,
/mjt
On Fri, Jun 14, 2013 at 12:32:22AM +0400, Michael Tokarev wrote:
Can you try with the latest seabios release (v1.7.2.2)? There have been other changes to the dsdt that may have corrected your issue.
-Kevin
14.06.2013 03:47, Kevin O'Connor wrote:
It's not exactly trivial to switch bioses after splitting out the tables. But I tried the same thing in current qemu git master, which includes 1.7.2.2, and where solaris guest behaves exactly the same -- it stalls with 100% CPU usage somewhere at the beginning of kernel booting.
Hmm. Speaking of the splitting. Does the current bios include the the tables which were split into separate files? I mean, what about compatibility between new bios and old qemu and vise versa, where "old" = "before split" and "new" = "after split" ?
Thanks!
/mjt
Hi,
Hmm. Speaking of the splitting. Does the current bios include the the tables which were split into separate files?
Yes, they are in out/ too after building seabios. Use "qemu -L /path/to/seabios/out" to make sure qemu picks up matching bios.bin and dsdt.
cheers, Gerd
14.06.2013 16:36, Gerd Hoffmann wrote:
Yes I know they're built in seabios/out, and I know one may use -L option here. So that, for example, -bios option of qemu makes less sense now than it was before.
But my question was about something different.
Can I use current seabios with old qemu which does not provide the separate ACPI tables? For example, does current bios contain these tables too, so they're both separate and embedded?
And the reverse, can I use old bios with new qemu which do provide the separate tables?
Which tables will be used in each case?
Thanks,
/mjt
On Fri, Jun 14, 2013 at 06:14:00PM +0400, Michael Tokarev wrote:
Yes.
And the reverse, can I use old bios with new qemu which do provide the separate tables?
Yes. The only limitation is that one can not use the q35 machine type without also having a new version of seabios.
Which tables will be used in each case?
SeaBIOS has the "piix4" acpi tables compiled into it, and it will use those if it doesn't receive a dsdt from qemu.
-Kevin
Hi,
Yes. The i440fx acpi tables are compiled in and will be used as fallback in case qemu doesn't provide acpi tables.
And the reverse, can I use old bios with new qemu which do provide the separate tables?
Yes. Old seabios will simply ignore the qemu-provides tables and use the compiled-in ones. That is limited to the 'pc' machine type though, q35 will not work this way. q35 needs other tables and this was the reason to let qemu provide the tables in the first place.
cheers, Gerd
14.06.2013 03:47, Kevin O'Connor wrote:
So, with the knowlege that current 1.7.2.2 does not change this, can we guess what's going on there? I don't really know solaris kernel internals (is the source available to start with?), but maybe this particular commit may give some hint?
Thanks!
/mjt
On Sun, Jun 16, 2013 at 02:07:39PM +0400, Michael Tokarev wrote:
Unfortunately not. There was nothing special about the DSDT changes in that commit. Likely the AML interpretter in Solaris is quirky and one of the clauses in that commit (or some arrangement of clauses) is confusing Solaris. This is one of the unfortunate parts of ACPI - despite the lengthy specification each implementation of ACPI is different and it's painful to come up with AML code that runs on multiple platforms.
You could try disabling acpi entirely.
You could also try iterating through the parts of that commit and commenting out various DSDT entries until you find which one is aggravating Solaris.
-Kevin
On 06/16/13 17:30, Kevin O'Connor wrote:
Also, "Solaris ACPICA" is googleable; two examples:
https://blogs.oracle.com/danasblog/entry/configuring_solaris_acpi_at_boot https://blogs.oracle.com/danasblog/entry/solaris_acpi_ca_debug_output
Laszlo