Tuesday Apr 22, 2008

Good Morning Build 87

On arriving back from my well earned holiday (yes I had a very relaxing time thank you) I see that not only is there a nice new Solaris release on our server but the server itself is no longer a power hungry SunFire box but an Eco friendly Niagra based T5220 and today is Earth Day. It's almost like we planned it!

: enoexec.eu FSS 1 $; uname -a
SunOS enoexec 5.11 snv_87 sun4v sparc SUNW,SPARC-Enterprise-T5220
: enoexec.eu FSS 2 $; 

We have actually been here before with respect to the Huron server as we tried one out for a few weeks around the time of build 83. I left the blogging of it to a colleague as it was not 100% successful or was 100% successful depending on your point of view. The system would crash regularly and finally a bug (which unfortunately is not published as it contains the way to panic an un-patched system running nevada so is marked as a “security” issue. I think this is a bit harsh) was filed and rapidly fixed. So if you are using a system to shake out bugs, which is why I use a nevada Sun Ray server at work, then this was 100% successful.

The performance of the system is well good enough. That is to say the only clue I had that something was “up” was that the performance meter I run, I know I should not but I do, get over it, looks “inverted”. We are not making a dent on the threads.

Monday Mar 03, 2008

Good Morning Build 84

Always nice to “arrive” at work and find your server running a shiny new build:

: enoexec.eu FSS 1 $; uname -a
SunOS enoexec 5.11 snv_84 sun4u sparc SUNW,Sun-Fire
: enoexec.eu FSS 2 $; 

Even as I type this I noticed that there are still issues in the world of gnome with gnome-panel dumping core:

Mar  3 08:27:16 enoexec genunix: [ID 603404 kern.notice] NOTICE: core_log: gnome-panel[11701] core dumped: /var/cores/usr/bin/gnome-panel.global.14442
: enoexec.eu FSS 7 $; pstack core-enoexec-gnome-panel.11701
core 'core-enoexec-gnome-panel.11701' of 11701:	gnome-panel --sm-config-prefix /gnome-panel-GZaWDp/ --sm-client-id 118
 00000000 ???????? (847f98, 3, a87e20, 0, a48cd8, 0)
 bb7a2ac4 invoke_notifies (a7a0c0, 3, 8ce808, 0, 148a0, bb7b7300) + 68
 bb7a2b50 emit_events_in_idle (a40f18, bb7b7ac0, bb7b7300, 7c0, 14814, 400) + 68
 c3dc0010 g_main_dispatch (127f00, 0, 0, 0, c3e63eb4, 127f08) + 1e4
 c3dc16b8 g_main_context_dispatch (1, 1, c3e65ea4, 2, c3e65ea8, 127f00) + c8
 c3dc1bd8 g_main_context_iterate (1, 1, 1, 127f00, 1f, 1f) + 49c
 c3dc24dc g_main_loop_run (5a9390, 0, 0, f9fc8, 5a9398, 1) + 3e4
 c05a6b34 gtk_main (0, 0, 0, be5c, c07f1538, 5a9390) + d8
 00037e70 main     (7, 163c58, 80000, 803e0, 803f8, 8040c) + 190
 00033740 _start   (0, 0, 0, 0, 0, 0) + 108
: enoexec.eu FSS 8 $; 

Time to find or file a bug...found it is 6666675. Given that number it would be rude not to check out bug 6666666, alas it turns out to be an “internal” bug and not surprisingly has no special significance. It should have been the uber bug of doom bwahahahahah.

Tuesday Feb 05, 2008

Good Morning Build 81, or not.

I did not even get a chance to login to the Sun Ray server running build 82 before it had crashed twice. So all was not well. A bit of digging and it was looking like a problem somewhere in portfs with kmem corruption. Since the problem was easily reproducible (boot system login and use for a few hours) I got the lab staff to set kmem_flags to 0xf in /etc/system and boot again.

Sure enough this morning there were two more crash dumps with variations of this in the message buffers:

kernel memory allocator: 
duplicate free: buffer freed twice
buffer=60063bfed60  bufctl=300f08886b8  cache: kmem_alloc_32
previous transaction on buffer 60063bfed60:
thread=300f43dac60  time=T-0.000269600  slab=300f08761e0  cache: kmem_alloc_32

kernel heap corruption detected

> $c
vpanic(12ac480, 5, 2c8, 1, 18de000, 12ac400)
kmem_error+0x4e8(18de000, 3000005ae08, 60063bfed60, 12ac400, 12ac478, 
port_associate_fop+0x408(16, 7, 4a330, 16, 4a330, 2a10424d968)
portfs+0x2c8(1, 0, 7, 2a0, 0, 4a330)
syscall_trap32+0xcc(1, a, 7, 4a330, 10000006, 4a330)

Looking at the code it appears that if port_pfp_setup encounters an error it frees the some kernel memory twice. Specifically it frees the memory pointed to by the cname local variable in port_associate_fop twice. Hence the random panics. The diffs for the fix are:

\*\*\* port_fop.c  Fri Oct 26 08:58:01 2007
--- /tmp/cg13442/port_fop.c     Tue Feb  5 14:04:21 2008
\*\*\* 1306,1311 \*\*\*\*
--- 1306,1312 ----
                if (error = port_pfp_setup(&pfp, pp, vp, pfcp, object,
                    events, user, cname, clen, dvp)) {
+                       cname = NULL;
                        goto errout;

I have just files this bug:

6659309: port_associate_fop frees a buffer twice if port_pfp_setup returns an error.

What I don't know is why we suddenly started seeing the bug. Is it that build 82 exercise event ports more or that the bug has been revealed by some other change? Either way it make me nervous for my home server running, you guessed it, build 82! At least next time someone asks why we bother running a Sun Ray server on the latest greatest nevada bits I have a preprepared place to send them. It is here.

Monday Dec 10, 2007

Good Morning Build 79

Another fortnight another build hits our Sun Ray server:

: estale.eu FSS 1 $; uname -a
SunOS estale 5.11 snv_79 sun4u sparc SUNW,Sun-Fire
: estale.eu FSS 2 $; 

All seems well so far.

Wednesday Oct 31, 2007

Good Morning Build 76

It is coming to something that I was too busy to check to see if build 76 had been installed on our Sun Ray server yesterday. Lets face it it is not hard to type “ssh estale uname”. Anyway it is here now:

: estale.eu FSS 1 $; uname -a
SunOS estale 5.11 snv_76 sun4u sparc SUNW,Sun-Fire
: estale.eu FSS 2 $;

Had I done so I could have had 24 hours less of the deskbar applet being missing, as it was in build 75. Although I'm not sure I like the new one as it seems to have become more of a stand alone window, which displays at the top left hand side of my screen when I have the applet on the bottom right.

Wednesday Oct 17, 2007

Good Morning Build 75

Build 75 is now installed on enoexec one of our SPARC servers which means I can now use the latest and greatest build and not run thunderbird remotely. The reason I had to run a remote thunderbird when using x86 is due to thunderbird keeping it's extensions in your home directory but without taking into account the architecture of the extenstion. IE they all go in ~/.thunderbird/\*.default/extensions. If you install an extension for SPARC that clearly won't work on x86 and visa versa. I filed bug 6613224 for this.

Anyway I am now back on a SPARC system.

: enoexec.eu FSS 1 $; uname -a
SunOS enoexec 5.11 snv_75 sun4u sparc SUNW,Sun-Fire
: enoexec.eu FSS 2 $;

The only problem so far is that pidgin is unable to join any rooms that have the auto-join property set. Curiously this bug was seen when pdigin was called gaim but went away when it was renamed. Again a bug has been filed: 6617918 (it is not in bugs.opensolaris.org at the time of writing but should turn up there soon)

Monday Sep 24, 2007

Good Morning Build 73

The Lab engineer who used to upgrade our Sun Rays moved onto pastures new and so there has been a slight glitch in the upgrades for a few weeks. Thankfully the pastures new are actually within Sun and in the same lab team but in a different country, well continent actually, however that allows him to continue doing the upgrades and now he is back on line I can say:

Good morning build 73:

: estale.eu FSS 1 $; uname -a
SunOS estale 5.11 snv_73 sun4u sparc SUNW,Sun-Fire
: estale.eu FSS 2 $; 

One thing I noticed on my home system was that I did not seem to be getting the latest developer tools installed and the same appears to be true here. Live upgrade is correctly upgrading Solaris but not upgrading the developer tools.

On my home system I ran:


Now I have all the tools installed. Need to get the same done in in my “finish” script before the Boot Environment is live.

Monday Aug 20, 2007

Good Morning Build 71

Arriving back in the office, well initially in my home office, our Sun Ray server is now running build 71:

: enoexec.eu FSS 1 $; uname -a
SunOS enoexec 5.11 snv_71 sun4u sparc SUNW,Sun-Fire
: enoexec.eu FSS 2 $; 

All seems to be well. While I don't think it turned up in this release we now have the Off the Record plugin for pidgin and pidgin also works with Jabber/XMPP out of the box. Pidgin is still missing the gaim-remote/purple-remote (bug 6578100) which messes with my script for setting my status using the utaction on my Sun Ray so one step forward and one step back for pidgin.

Monday Jul 23, 2007

Good Morning build 68

Build 68 has hit our Sun Ray server last week. Which was good news and bad news. The good news is that this gets us the new “pidgin” IM client. The bad news is that the build of pidgin does not contain the XMPP (aka jabber) plugins which renders it as much use as a chocolate Tea pot. The bug id is: 6577264. Not fixed in build 69.

Luckily it took seconds for some bright spark to have a version built from source. The config options are “CC=cc -disable-perl --disable-tcl –prefix=/blah”. Disabling perl is obviously goodness, but TCL is a pity but with it it just dumps core. Alas this version is not aware of the gnome-keyring.

Apart from that the build is good.

: estale.eu FSS 1 $; uname -a

SunOS estale 5.11 snv_68 sun4u sparc SUNW,Sun-Fire

: estale.eu FSS 2 $; 

Update: For those who are close to GMP I have built both SPARC and x86 copies of pidgin for Nevada. They can be found here ~cg13442/pidgin/$(uname -p)/bin

If you use the c-shell you have my deepest sympathies but they don't run to me giving a c-shell friendly path.

As with the one mentioned above they don't understand how to talk to the gnome keyring

Monday Jun 25, 2007

Good Morning Build 67

Build 67 of nevada to play with this morning.

: enoexec.eu FSS 1 $; uname -a
SunOS enoexec 5.11 snv_67 sun4u sparc SUNW,Sun-Fire
: enoexec.eu FSS 2 $; 

One slight issue is the gnome terminal keeps having bits of font left on it. Turns out to be bug 65663321. Apart from that all is well.

1Internally to Sun we apparently no longer have bugs but instead they are “Change Requests” or “CRs” but I never noticed until today that that bit of doublespeak has not been applied to the community where a bug is referred to as a bug.

Wednesday May 09, 2007

Good Morning Build 63

Build 63 has hit our Sun Ray server, and my Sun Ray server at home:

: estale.eu FSS 1 $; uname -a
SunOS estale 5.11 snv_63 sun4u sparc SUNW,Sun-Fire
: estale.eu FSS 2 $; 

All is well, except the main menu now has a “shutdown” button on it:

Which is a bit off putting as this is a Sun Ray used by lots of other people. (It did not stop me trying though. Since it calls gnome-sys-suspend which then checks /etc/default/sys-suspend to see if you are allowed to shut the system down there is no harm apart from the wasted real estate on the screen).

More worryingly the upgrade has undone the edit of /etc/default/sys-suspend that the Sun Ray software does so that the user on the console can't shutdown the system.

Monday Nov 27, 2006

Good Morning Build 53

: enoexec.eu IA 1 $; uname -a
SunOS enoexec 5.11 snv_53 sun4u sparc SUNW,Sun-Fire
: enoexec.eu IA 2 $; echo $DISPLAY

The new version of the GUI is obviously the most noticeable thing, not least as while writing this I have an in browser spell checker. All seems fine so far.

tags: , ,


This is the old blog of Chris Gerhard. It has mostly moved to http://chrisgerhard.wordpress.com


« July 2016