> Hi Nick,
>
> Thanks again for testing this. The issue with Solaris not detecting the
> disks is a known one - the following guide should point you in the right
> direction:
>
> http://virtuallyfun.blogspot.com/2010/10/formatting-disks-for-solaris.html
>
> Also don't forget the "set scsi_options" part from Artyom's SPARC/QEMU
> howto here: http://tyom.blogspot.com/2009/12/solaris-under-qemu-how-to.html
>
> I think it may actually be possible to come up with a patch for OpenBIOS
> so that the scsi_options change isn't required - let me know how you get
> on with the above links, and if it all seems to work I'll look at
> creating the patch for you.
>
>
Okay, I got passed the issue with formatting the root filesystem.
Apparently there are some limitations on the C/H/S parameters you use
for the disk that correspond with how UFS wants to format a new
filesystem. I'm not sure what exactly those limitations are at this
point, but, by adjusting a couple of the C/H/S settings when using
format to set up the disk I was able to get it to work correctly. So, I
now have Solaris 9 installed on qemu-system-sparc with OpenBIOS! I'll
probably go back to Solaris 8 as that one has a free binary license
while Solaris 9 is a commercial license, IIRC. I do own a Solaris 9
commercial license, but I like the free idea, better.
Anyway, now I'm on to an issue with networking - I've used the following
two qemu network parameter combinations:
-net nic -net tap,ifname=tap0
-net nic -net user
In the first instance, tap0 was configured on my Linux box and added to
my bridge br0. In both cases the Solaris system is unable to obtain a
DHCP address - the DHCP client times out. Not sure if I should be using
a different parameter set, or if this is another area that needs some
work either for OpenBIOS or qemu?
-Nick
--------
This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.
Greetings,
I'm unsure whether the issue I'm running into is related to
OpenBios, qemu, something buggy in this solaris distribution, or some
combination thereof. Feel free to redirect me as appropriate.
I'm able to install Solaris 8 (02/04) from the "Solaris 8 Software
disk 1" disk. I see a few different behaviors depending on what I
try:
1) boot from disk0:a without any special options:
After specifying a root password, it says "Starting Web Start
Launcher in Command Line Mode" and shortly thereafter says "The
Webstart launcher has terminated unexpectedly." with no further
details, except to say the machine will reboot after pressing enter.
2) Do the same thing, but with -v:
The result doesn't seem predictable. Sometimes it just hangs after
the "Starting ..." line, other times it dies with a variety of errors.
I'll try to summarize below:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Starting Web Start Launcher in Command Line Mode.
SIGSEGV 11 segmentation violation
si_signo [11]: SEGV
si_errno [0]:
si_code [1]: SEGV_MAPPER [addr: 0x1000100
stackpointer=EE73E578
Inconsistent thread : best efforts attempt (may fail)
"Thread-1" (TID:0x34c470, sys_thread_t:0x34c3a8, state:R, thread_t:
t@12, threadID:0xee74098, stack_bottom:0xee740d98, stack_size:0x1fd98)
prio=5 *current thread*
[1] java.util.ResourceBundle.getBundle(ResourceBundle.java:346)
[2] java.awt.Toolkit$3.run(Toolkit.java:887)
[3] java.security.AccessController.doPriveleged(Native Method)
[4] java.awt.Toolkit.<clinit>(Toolkit.java:882)
[5] java.awt.Component.<clinit>(Component.java:336)
[6] com.sun.wizards.core.WizardTreeManager.createWizardPanel(WizardTreeManager.java:801)
[7] com.sun.wizards.core.WizardTreeManager.<init>(WizardTreeManager.java:265)
[8] com.sun.wizards.core.CommandLineConsole.java:78)
[9] java.lang.Thread.run(Thread.java:479)
------------------------------
Inconsistent thread : best efforts attempt (may fail)
"process reaper" (TID:0x2c4600, sys_thread_t:0x2c4538, state:R,
thread_t: t@10, threadID:0xee7b0d98, stack_bottom:0xee7b0d98,
stack_size:0x1fd98) prio=5
[1] java.lang.UNIXProcess.waitForProcessExit(Native Method)
[2] java.lang.UNIXProcess.access$10(UNIXProcess.java:30)
[3] java.lang.UNIXProcess$3.run(UNIXProcess.java:74)
--------------------------
Inconsistent thread : best efforts attempt (may fail)
"Finalizer" (TID:0x156d80, sys_thread_t:0x156cb8, state:CW, thread_t:
t&2, threadID:0xee890d98, stack_bottom:0xee890d98, stack_size:0x1fd98)
prio=8
[1] java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:145)
[2] java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:167)
[3] java.lang.ref.Finalizer$FinalizerWorker$FinalizerThread.run(Finalizer.java:117)
-------------------------
Inconsistent thread : best efforts attempt (may fail)
"Reference Handler" (TID:0x155e20, sys_thread_t:0x155d58, state:CW,
thread_t: t@6, threadID:0xee8c0d98, stack_bottom:0xee8c0d98,
stack_size:0x1fd98) prio=10
[1] java.lang.Object.wait(Object.java:417)
[2] java.lang.ref.Reference$ReferenceHandler.run(Reference.java:129)
-------------------------
Inconsistent thread : best efforts attempt (may fail)
"Signal dispatcher" (TID:0x135278, sys_thread_t:0x1351b0, state:MW,
thread_t: t@5, threadID:0xee8f0d98, stack_bottom:0xee8f0d98,
stack_size:0x1fd98) prio=10
(note the lack of stack trace here)
------------------------
Inconsistent thread : best efforts attempt (may fail)
"main" (TID:0x390d0, sys_thread_t:0x39008, state:R, thread_t: t@1,
threadID:0x251d0, stack_bottom:0xf0000000, stack_size:0x800000) prio=5
[1] java.io.ObjectInputStream.loadClassO(Native Method)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
... after which the VM stopped responding.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Starting Web Start Launcher in Command Line Mode.
signal fault in critical section
signal number: 11, signal code: 1,
fault address: 0xe9ff0de8, pc: 0xef40d4a8, sp: 0xee7a2c78
libthread panic: fault in libthread critical section : dumping core
(PID: 327 LWP 10)
stacktrace:
ef40d49c
ef40f134
ef408c48
0
Abort - core dumped
The Webstart launcher has terminated unexpectedly.
(some stuff about the machine rebooting on <enter>)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
As a side-note, seemingly at random I see the following message a lot
(including during that last bit I quoted):
Assertion failed: MUTEX_HELD(&svc_thr_mutex), file ../rpc/svc_run.c, line 757
3) Boot in single-user mode
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Starting Web Start Launcher in Command Line Mode.
signal fault in critical section
signal number: 11, signal code: 1,
fault address: 0xee82005c, pc: 0xef7c7248, sp: 0xee73e198
libthread panic: fault in libthread critical section : dumping core
(PID: 330 LWP 9)
stacktrace:
(...)
Segmentation Fault - core dumped
(terminated unexpectedly, yada yada)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
... where (...) is a huge stack trace. I have to copy this by hand
... ya, I really hope you don't need that. Lemme know if you do,
though.
I was able to get the exact same error & stack trace as the sig11 one
from (2) above. Addresses were the same, only diferences were the
PID, LWP, and sp (330, 9, 0xee752c78)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Starting Web Start Launcher in Command Line Mode.
Fri May 27 15:29:19 2011 fatal: mounting of "/vol" failed
signal fault in critical section
signal number: 11, signal code: 1,
fault address: 0xee780de8, pc: 0xef40d4a8, sp: 0xeb1b2c78
libthread panic: fault in libthread critical section : dumping core
(PID: 330 LWP 12)
stacktrace:
ef40d49c
ef40f134
ef408c48
0
Abort - core dumped
(blahdy blah)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
For reference, I'm using a 3g qcow2 image. I originally formatted it
as a "SUN2.9G" in the format utility, but I let it autoconfigure the
partitions. partition '0' is root (1.18G), '1' is swap (149m), '2' is
backup (2.71g), and '7' is home (1.39g). There's overlap in the
cylinder ranges specified and the total size between those partitions
is larger than 3g ... but, I have no idea whether that's just a
Sun-ism, or whether I need to partition manually.
I don't think it's my partitions, though. The 'vol' directory doesn't
exist in my root before I try to get the webstart stuff to run, so I
think it's creating that directory and trying to mount an image to it.
Additionally, I'm starting qemu with:
./qemu_system_sparc -nographic -bios
/imgpath/openbios-sparc32_artyom.bin -hda
/imgpath/solaris2.8-img3.qcow2 -m 256 -net nic -net user -cdrom
/imgpath/solaris2.8/software_1of2.iso prom-env 'auto-boot?=false'
-snapshot
If anyone has a good idea, I'm all ears ... (or is it eyes?)
-Brian
>
> Nick - do you think you could do a quick test on this one?
>
This patch for the scsi_options seems to work fine - system boots with
the patch applied and with the line removed from /etc/system.
-Nick
--------
This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.
Author: afaerber
Date: Mon May 23 00:29:33 2011
New Revision: 1041
URL: http://tracker.coreboot.org/trac/openbios/changeset/1041
Log:
ppc64: Don't set Kp bit on SLB
Since QEMU 81762d6dd0d430d87024f2c83e9c4dcc4329fb7d (Clean up
PowerPC SLB handling code) we never got to the ppc64 OpenBIOS banner.
According to Alex' debugging this is due to the Kp bit being set.
The code was supposed to be a 1:1 translation of the old mtsrin
code, which did not set Kp bit. So don't set Kp bit with slbmte.
Introduce a define for the shift, suggested by Alex.
Signed-off-by: Andreas Färber <andreas.faerber(a)web.de>
Acked-by: Alexander Graf <agraf(a)suse.de>
Modified:
trunk/openbios-devel/arch/ppc/qemu/ofmem.c
Modified: trunk/openbios-devel/arch/ppc/qemu/ofmem.c
==============================================================================
--- trunk/openbios-devel/arch/ppc/qemu/ofmem.c Sun May 22 18:39:48 2011 (r1040)
+++ trunk/openbios-devel/arch/ppc/qemu/ofmem.c Mon May 23 00:29:33 2011 (r1041)
@@ -25,6 +25,8 @@
#define BIT(n) (1U << (31 - (n)))
+#define SLB_VSID_SHIFT 12
+
/* called from assembly */
extern void dsi_exception(void);
extern void isi_exception(void);
@@ -497,7 +499,7 @@
slbia(); /* Invalidate all SLBs except SLB 0 */
for (i = 0; i < 16; i++) {
- unsigned long rs = ((0x400 + i) << 12) | (0x10 << 7);
+ unsigned long rs = (0x400 + i) << SLB_VSID_SHIFT;
unsigned long rb = ((unsigned long)i << 28) | (1 << 27) | i;
slbmte(rs, rb);
}
Since QEMU 81762d6dd0d430d87024f2c83e9c4dcc4329fb7d (Clean up
PowerPC SLB handling code) we never got to the ppc64 OpenBIOS banner.
According to Alex' debugging this is due to the Kp bit being set.
The code was supposed to be a 1:1 translation of the old mtsrin
code, which did not set Kp bit. So don't set Kp bit with slbmte.
Cc: Alexander Graf <agraf(a)suse.de>
Cc: David Gibson <david(a)gibson.dropbear.id.au>
Signed-off-by: Andreas Färber <andreas.faerber(a)web.de>
---
arch/ppc/qemu/ofmem.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/ppc/qemu/ofmem.c b/arch/ppc/qemu/ofmem.c
index 297e685..514d129 100644
--- a/arch/ppc/qemu/ofmem.c
+++ b/arch/ppc/qemu/ofmem.c
@@ -497,7 +497,7 @@ setup_mmu(unsigned long ramsize)
slbia(); /* Invalidate all SLBs except SLB 0 */
for (i = 0; i < 16; i++) {
- unsigned long rs = ((0x400 + i) << 12) | (0x10 << 7);
+ unsigned long rs = ((0x400 + i) << 12) | (0x0 << 7);
unsigned long rb = ((unsigned long)i << 28) | (1 << 27) | i;
slbmte(rs, rb);
}
--
1.7.3.4
Author: blueswirl
Date: Sun May 22 18:39:48 2011
New Revision: 1040
URL: http://tracker.coreboot.org/trac/openbios/changeset/1040
Log:
switch-arch: remove non-standard "local" keyword
Remove the non-standard "local" keyword from within the crosscflags()
function. This was not necessary since the variables "host" and "target"
were not clobbered anywhere outside of the function, but the real
motivation is to support shells such as ksh93 that do not have the
"local" builtin like bash.
Signed-off-by: Kenneth Salerno <kennethsalerno(a)yahoo.com>
Signed-off-by: Blue Swirl <blauwirbel(a)gmail.com>
Modified:
trunk/openbios-devel/config/scripts/switch-arch
Modified: trunk/openbios-devel/config/scripts/switch-arch
==============================================================================
--- trunk/openbios-devel/config/scripts/switch-arch Sun May 8 17:36:59 2011 (r1039)
+++ trunk/openbios-devel/config/scripts/switch-arch Sun May 22 18:39:48 2011 (r1040)
@@ -19,8 +19,8 @@
crosscflags()
{
- local host=$1
- local target=$2
+ host=$1
+ target=$2
if test "$host" = "powerpc" -o "$host" = "ppc" \
-o "$host" = "mips" -o "$host" = "s390" \
QEMU HEAD still uses a 32-bit binary for both 32-bit and 64-bit. That one uses mtsrin so will need the compatibility, it seemed affected, too.
OpenBIOS SVN HEAD (blob) uses slb* as linked to. We're in the preparation of 1.1 and I need to test it before we can update the QEMU binary. ;)
Sorry for top-posting, Android sucks.
Andreas
David Gibson <david(a)gibson.dropbear.id.au> schrieb:
>On Thu, May 19, 2011 at 08:00:53AM +0200, Andreas Färber wrote:
>> Am 19.05.2011 um 07:39 schrieb David Gibson:
>>
>> >On Thu, May 19, 2011 at 07:35:30AM +0200, Andreas Färber wrote:
>> >>Am 25.03.2011 um 04:21 schrieb David Gibson:
>> >>
>> >>>Currently the SLB information when emulating a PowerPC 970 is
>> >>>storeed in a structure with the unhelpfully named fields 'tmp'
>> >>>and 'tmp64'. While the layout in these fields does match the
>> >>>description of the SLB in the architecture document, it is not
>> >>>convenient either for looking up the SLB, or for emulating the
>> >>>slbmte instruction.
>> >>>
>> >>>This patch, therefore, reorganizes the SLB entry structure to be
>> >>>divided in the the "ESID related" and "VSID related" fields as
>> >>>they are divided in instructions accessing the SLB.
>> >>>
>> >>>In addition to making the code smaller and more readable, this will
>> >>>make it easier to implement for the 1TB segments used in more
>> >>>recent PowerPC chips.
>> >>>
>> >>>Signed-off-by: David Gibson <dwg(a)au1.ibm.com>
>> >>
>> >>According to my bisect, this patch broke ppc64 OpenBIOS.
>> >>
>> >>David, would you please take a look?
>> >
>> >Uh, sure. can you describe the symptoms of the breakage, and the
>> >exact qemu setup you've observed the problem with?
>>
>> $ uname -a
>> Darwin PMG5-3.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15
>> 16:57:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_PPC Power Macintosh
>> # Mac OS X 10.5.8 on dual-core G5
>>
>> $ gcc-4.2 --version
>> powerpc-apple-darwin9-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5577)
>> Copyright (C) 2007 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions. There
>> is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
>> PURPOSE.
>>
>> ../qemu/configure --prefix=/Users/andreas/QEMU/latest64 \
>> --target-list=ppc-softmmu,ppc64-softmmu \
>> --extra-cflags="-arch ppc64" --extra-ldflags="-arch ppc64" --cc=gcc-4.2
>> --host-cc=gcc-4.2 \
>> --enable-cocoa --disable-kvm --disable-strip --disable-docs
>> --enable-io-thread $*
>> # I/O thread doesn't matter
>>
>> /Users/andreas/QEMU/qemu64/ppc64-softmmu/qemu-system-ppc64 -boot d -cdrom
>> /Users/andreas/QEMU/AIX/dvd.1022A4_OBETA_710.iso \
>> -bios /Users/andreas/QEMU/OpenBIOS/openbios/obj-ppc64/openbios-qemu.elf
>> -m 1024 \
>> -M mac99 -prom-env 'auto-boot?=false' -nographic
>>
>> CD should be irrelevant, -boot c -hda /dev/null should work the same.
>
>Um, yeah, I thought putting an AIX dvd into a Mac was a bit odd.
>
>> Expected: OpenBIOS banner and > prompt
>> Observed: DSI exception on mtmsrd, no serial output
>
>Does this happen only with your openbios image, or does it also happen
>with the one included in qemu?
>
>My working theory is that openbios is using the old 32-64 bridge stuff
>where segment register accesses are emulated to populate certain SLB
>slots. I have a vague recollection that I saw the code implementing
>that when I was doing the cleanup and convinced myself it was not
>necessary. More information as I investigate further.
>
>> (The regression on ppc32 AIX observed by Kenneth seems to be a
>> different issue, introduced earlier.)
>
>I don't know what that regression is; I don't read qemu-devel
>exhaustively. If you want my attention, best to CC me directly.
>
>--
>David Gibson | I'll have my music baroque, and my code
>david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
> | _way_ _around_!
>http://www.ozlabs.org/~dgibson