The problem of year 2010

Looks like the Solaris versions prior to the version 2.6 (SunOS 5.6) have a problem of year 2010.

Surprise, surprise! If the current date is specified, they just don't boot in a single user mode, hanging after detection of serial ports (zs1 is /obio/zs@0,0), when /devices directory should be configured.

At least the version 2.5.1 hangs when the system date is > 2009.12.20.

Weird, huh?

Going to update the howto....

hsfs_putpage:birthday gift

I think I've fixed the problem with the dirty pages. This is my birthday gift to me.
The bug is really simple: if we fail before modifying a RAM page, we don't really get the page dirty.

Submitted the patch upstream.

Solaris 7 (aka SunOS 5.7)

Actually I didn't tell the truth as I wrote that I didn't have anything up my sleeve. People who read this blog noticed, that I claimed I could boot Solaris 7, but the how-to explicitly says it is not possible with the vanilla qemu.

Yes, I have a hack which would allow booting Solaris 7, but re-writing it properly would take some time.

The question is what do you think is more important: enabling Solaris 7 (~ 2 weekends), or fixing existing issues with Solaris 2.{4-6} (no time estimates, research necessary)?

Does Solaris 7 have something useful what 2.x didn't have?

OpenSolaris sources are beautiful

Trying to find the roots of the "hsfs_putpage: dirty HSFS page" error, I looked in the OpenSolaris source.

High Sierra is a pretty old and stable stuff, so it is possible that the code is similar to OpenSolaris.
I looked in debugger, and the function calls hierarchy looks pretty similar.

Now in the OpenSolaris source code there is a nice comment:

/*
* Normally pvn_getdirty() should return 0, which
* impies that it has done the job for us.
* The shouldn't-happen scenario is when it returns 1.
* This means that the page has been modified and
* needs to be put back.
* Since we can't write on a CD, we fake a failed
* I/O and force pvn_write_done() to destroy the page.
*/
if (pvn_getdirty(pp, flags) == 1) {
               cmn_err(CE_NOTE,
                           "hsfs_putpage: dirty HSFS page");

The bright side: I don't know any other open source project which would be so nicely documented. The description confirms the suspect I had: it's the problem with MMU emulation.

The dark side:  it's not just the problem with hsfs. Other file systems will have this bug too, and there it must be even more dramatic: they must be constantly writing cache data back to disk.

The 100% mmu & mxcc emulation in qemu would make the memory access very slow. I still hope we can avoid this, but don't know how.

MMU & irq fixes

Submitted mmu and irq fixes upstream and updated the solaris/sparc under qemu howto. Now all the fixes I had are in the vanilla qemu (git). Don't have anything else up my sleeve.

So please test everything you can and please send reports. Here and to the qemu-devel mailing list.

Happy 2010

I'm back from skiing. Happy 2010 everyone!

Updated the Solaris under qemu how-to, added launching instructions for the Solaris versions prior 2.6.

Meanwhile I'm working on the MMU emulation problems. It's harder than it looked. There is a documentation on the SuperSPARC Multi Cache Controller, which describes, what MMU does in a case of a double fault differently than it is currently implemented in qemu. Unfortunately it looks like either it describes it wrong, or I don't get what is written there (yes, I've seen it says "Subject to Change Without Notice" in the footer). At least I can not confirm the described behavior on the real SS-20.

So, there are 3 variants of the MMU behavior: qemu's, described, and the correct one. I'm exploring the last two to fix the first one.