I've rewrote this module using workqueue instead of timers and it works perfectly now on blackbird (to be tested on lappy soon).
An additional feature is that I now flip the leds twice so the original state is restored and also the blink is not missed if all leds were originally on.
Code is here
Wednesday, April 29, 2009
Monday, April 27, 2009
BTrace Rocks!
At work we're using a maven based build process. On the build machine it takes a while to finish the complete build (about 2 hours).
One of the final parts of the build is to generate the mvn:site. This stage takes, in my opinion, longer than it would seem necessary. Looking at #top, the machine is almost idle and there are 14 processes listed in #ps, where the last one keeps changing (I guess it finishes a directory and a new is spawned for the next one).
Due to bad design, there's no logging whatsoever in this stage and the machine seems stuck. I wanted to debug this on the build machine but didn't want to distrupt the running build (so can't start in debug mode).
To the rescue comes BTrace. A DTrace clone for java, allowing you to write small java scripts that can monitor and profile running java code. BTrace allows you to attach to an existing JVM process, without requiring any special switches to be added a priori to its command line (although it does support an -agent scenario).
That was so cool! Just downloaded one of the examples on the BTrace site, found the process pid using #jps so I can attach to it, and voila. I get printouts of all file accesses done by maven.
The BTrace examples page is full of actuall useful scripts. For example there's a script to print stacktraces for all threads (similar to #jstack).
One of the final parts of the build is to generate the mvn:site. This stage takes, in my opinion, longer than it would seem necessary. Looking at #top, the machine is almost idle and there are 14 processes listed in #ps, where the last one keeps changing (I guess it finishes a directory and a new is spawned for the next one).
Due to bad design, there's no logging whatsoever in this stage and the machine seems stuck. I wanted to debug this on the build machine but didn't want to distrupt the running build (so can't start in debug mode).
To the rescue comes BTrace. A DTrace clone for java, allowing you to write small java scripts that can monitor and profile running java code. BTrace allows you to attach to an existing JVM process, without requiring any special switches to be added a priori to its command line (although it does support an -agent scenario).
That was so cool! Just downloaded one of the examples on the BTrace site, found the process pid using #jps so I can attach to it, and voila. I get printouts of all file accesses done by maven.
The BTrace examples page is full of actuall useful scripts. For example there's a script to print stacktraces for all threads (similar to #jstack).
Sunday, April 26, 2009
Magic SysRq enhancement
I really love the Magic SysRq key. It's always nice to know that you can do some emergency actions even when the system is 99% locked up. What's my favorite sequence? Probably 'subo'. I'm still figuring it out.
One of my beefs with MSRK is that sometimes I can't be sure if it is responding (am I pressing the right sequence?). This usually happens when I get a crash while in X, not seeing the console.
I wrote a small kernel module to add a new action to the Magic SysRq key. The new action's, "Visualize", only purpose is to give back a cue that it's listening.
I copied from some kernel hacking example code for blinking the keyboard leds (should be possible if the kernel still reads commands from the keyboard) and for beeping (although I haven't got that working yet).
First try is using timers ('add_timer'). This seems to be working nicely on lappy but inconsistently on blackbird (sometimes the leds don't light up and sometime they light up but don't go off). I'm pretty sure that the timer function gets called because I can see the printk's. I guess this means that the IOCTL is failing. I'll try replacing the timer with work queue, see if that helps.
P.S.: Another difference between lappy and blackbird: On blackbird the 'v' from the Alt-SysRq-V sequence gets swallowed, whily on lappy it gets printed. Strange.
One of my beefs with MSRK is that sometimes I can't be sure if it is responding (am I pressing the right sequence?). This usually happens when I get a crash while in X, not seeing the console.
I wrote a small kernel module to add a new action to the Magic SysRq key. The new action's, "Visualize", only purpose is to give back a cue that it's listening.
I copied from some kernel hacking example code for blinking the keyboard leds (should be possible if the kernel still reads commands from the keyboard) and for beeping (although I haven't got that working yet).
First try is using timers ('add_timer'). This seems to be working nicely on lappy but inconsistently on blackbird (sometimes the leds don't light up and sometime they light up but don't go off). I'm pretty sure that the timer function gets called because I can see the printk's. I guess this means that the IOCTL is failing. I'll try replacing the timer with work queue, see if that helps.
P.S.: Another difference between lappy and blackbird: On blackbird the 'v' from the Alt-SysRq-V sequence gets swallowed, whily on lappy it gets printed. Strange.
Wednesday, April 22, 2009
Googling myself again...
My name comes up a few times in the internet, in various bug reports and forum posts. I found out today it also appears in the hibernate-annotations changelog (quite undeservingly since someone else did all the heavy lifting). Nice.
Profiling Java Applications
A new beta of simon 2 is out. Also, btrace (https://btrace.dev.java.net/source/browse/btrace/docs/usersguide.html?rev=1.6) looks like an interesting alternative to JIP. It even has a visualvm plugin.
Tomcat Logging, Another Rant
For integration with another application I need the logs comming out of tomcat to have predictable names. This is not a problem for my webapp log which is created by log4j. Apparently this can be done with java logging as well. However, the tomcat main log uses JULI by default, which always creates log files with the date embedded in the file name.
There doesn't seem to be a way to configure it otherwise (except to change the logging to use a different mechanism).
There doesn't seem to be a way to configure it otherwise (except to change the logging to use a different mechanism).
Friday, April 10, 2009
ALSA, oh, ALSA
A week a two ago a hal update broke alsa on blackbird. After a few reboots I managed to get sound back, I believe it was fixed by downgrading hal-info to 20080508.
Yesterday I upgraded the kernel to 2.6.29-r1, and after the first reboot, again no sound (I also got the messages about /etc/modules.d in the boot messages as I got the last time this was b0rked).
So, I tried upgrading hal-info back to 20081219 (latest stable) and rebooted. Now it works (and no warning messages).
I'm assuming it's hal-info (maybe there is some dependency between the new hal version and new kernel version?) but maybe it has something to do with the reboot itself. We'll see next time.
Yesterday I upgraded the kernel to 2.6.29-r1, and after the first reboot, again no sound (I also got the messages about /etc/modules.d in the boot messages as I got the last time this was b0rked).
So, I tried upgrading hal-info back to 20081219 (latest stable) and rebooted. Now it works (and no warning messages).
I'm assuming it's hal-info (maybe there is some dependency between the new hal version and new kernel version?) but maybe it has something to do with the reboot itself. We'll see next time.
Tuesday, April 7, 2009
GCC 4.3.2
GCC 4.3.2 just got stable on Gentoo a few days ago. For a full, clean, upgrade I need to recompile the whole system. Maybe this weekend (a long one).
I'm wondering, if I'm already recompiling everything, I should consider installing from scratch in 64bit instead of 32bit. Flash has had a 64 bit plugin for a while already, and it seems that sun's JDK is also now sporting a 64 bit plugin. That doesn't leave a lot of remaining objections to 64 bit since the last time I tried.
What about wine, does it work well in 64bit? What other binary blobs do I have that I should worry about?
I recently switched my wireless driver to net-wireless/broadcom-sta, which should work with 64bit.
Let's see... what else... I guess I would need to reinstall oracle-xe. Wait, let's just see what's in my /opt and /usr/local:
VMware, googleearth, sqldeveloper, ...
hmmm... need to think about it some more.
Update: Arrgrggg... Oracle Express doesn't come in 64 bit... Will need multilib after all.
I'm wondering, if I'm already recompiling everything, I should consider installing from scratch in 64bit instead of 32bit. Flash has had a 64 bit plugin for a while already, and it seems that sun's JDK is also now sporting a 64 bit plugin. That doesn't leave a lot of remaining objections to 64 bit since the last time I tried.
What about wine, does it work well in 64bit? What other binary blobs do I have that I should worry about?
I recently switched my wireless driver to net-wireless/broadcom-sta, which should work with 64bit.
Let's see... what else... I guess I would need to reinstall oracle-xe. Wait, let's just see what's in my /opt and /usr/local:
VMware, googleearth, sqldeveloper, ...
hmmm... need to think about it some more.
Update: Arrgrggg... Oracle Express doesn't come in 64 bit... Will need multilib after all.
Eclipse Java Execution Environment Description Files
At work I'm working on a java project that needs some command line arguments passed to the JRE to work correctly (maximum allowed memory, etc.).
I have these set in the Installed JREs section in Eclipse's preferences which is all good. However, it gets real frustrating because whenever I upgrade my JDK these get lost. This is because the JDK I had is no longer there an is automatically removed by eclipse, and the new one is detected and added without any customizations.
So I tried to tell my project to use an "Execution Environment" instead of a specific JRE. However eclipse (3.4) doesn't let you modify it's list of execution enviroments (or customize the command line arguments). You can, however, define a new JRE using an Execution Environment Description file.
It was hard to find documentation about this so called .ee file. I found just one page that described the possible settings that can be put in the file, with a short description, but I had to reverse engineer the values for these settings.
Finally I came up with this, which actually works:
Notice the ${ee.home} in the paths. It seems that this is the only variable that can be used in the ee file. It get's replaced with the path to the ee file, so for this to work the ee file must be placed in the JDK's base directory.
The reason I'm using this variable instead of absolute paths is that on the next JDK upgrade I'll just need to copy the file to the new JDK's directory and it will continue working (soft linking the jdk directory doesn't work - eclipse follows the links and creates a broken JRE).
Of course you could generate a new ee file for each JDK version.
I also created another variant of this ee file with JIP command line arguments, so I have two JREs defined. This way when ever I want to profile my project, I don't need to create a special runtime configuration, but just choose a the other JRE. To make things even easier, I have two Server (tomcat) definitions, one with each JRE. Starting tomcat with JIP is just a matter of starting the second server instead of the first. Pretty nifty.
BTW, the extra setting for JIP is:
P.S.: It would be great to see this file coming from the upstream package. Maybe sun can include it in their JDK distrubtion, or maybe it could be added to gentoo's package (possibly with an eclipse/OSGi use flag?)
I have these set in the Installed JREs section in Eclipse's preferences which is all good. However, it gets real frustrating because whenever I upgrade my JDK these get lost. This is because the JDK I had is no longer there an is automatically removed by eclipse, and the new one is detected and added without any customizations.
So I tried to tell my project to use an "Execution Environment" instead of a specific JRE. However eclipse (3.4) doesn't let you modify it's list of execution enviroments (or customize the command line arguments). You can, however, define a new JRE using an Execution Environment Description file.
It was hard to find documentation about this so called .ee file. I found just one page that described the possible settings that can be put in the file, with a short description, but I had to reverse engineer the values for these settings.
Finally I came up with this, which actually works:
## Execution Environment description file for MyProject
-Dee.name=MyProject_EE
-Djava.home=${ee.home}/jre
-Dee.executable=${ee.home}/jre/bin/java
-Dee.executable.console=${ee.home}/jre/bin/java
-Dee.bootclasspath=${ee.home}/jre/lib/resources.jar:${ee.home}/jre/lib/rt.jar:${ee.home}/jre/lib/jsse.jar:${ee.home}/jre/lib/jce.jar:${ee.hom$
-Dee.language.level=1.6
-Dee.library.path=${ee.home}/jre/lib/i386:${ee.home}/jre/lib/i386/server
-Dee.src=${ee.home}/src.zip
-Dee.javadoc.http://java.sun.com/javase/6/docs/api/index.html
-Dee.ext.dirs=${ee.home}/jre/lib/ext
-Dee.vm.library=${ee.home}/jre/lib/i386/server/libjvm.so
-server
-Xmx768m
-XX:MaxNewSize=384m
-XX:MaxPermSize=144m
-XX:+UseConcMarkSweepGC
-XX:+CMSClassUnloadingEnabled
-Dcom.sun.management.jmxremote=true
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
Notice the ${ee.home} in the paths. It seems that this is the only variable that can be used in the ee file. It get's replaced with the path to the ee file, so for this to work the ee file must be placed in the JDK's base directory.
The reason I'm using this variable instead of absolute paths is that on the next JDK upgrade I'll just need to copy the file to the new JDK's directory and it will continue working (soft linking the jdk directory doesn't work - eclipse follows the links and creates a broken JRE).
Of course you could generate a new ee file for each JDK version.
I also created another variant of this ee file with JIP command line arguments, so I have two JREs defined. This way when ever I want to profile my project, I don't need to create a special runtime configuration, but just choose a the other JRE. To make things even easier, I have two Server (tomcat) definitions, one with each JRE. Starting tomcat with JIP is just a matter of starting the second server instead of the first. Pretty nifty.
BTW, the extra setting for JIP is:
-javaagent:/usr/local/jip-1.1.1/profile/profile.jar -Dprofile.properties=/var/proj/MyProject/webapp.profile.properties
P.S.: It would be great to see this file coming from the upstream package. Maybe sun can include it in their JDK distrubtion, or maybe it could be added to gentoo's package (possibly with an eclipse/OSGi use flag?)
First Post
This blog is dedicated to any kind of interesting stuff I encounter while developing software, fiddling with linux or anything computer related.
I figure I can just blog it instead of emailing it to myself (for example when I come up with a new script).
I figure I can just blog it instead of emailing it to myself (for example when I come up with a new script).
Subscribe to:
Posts (Atom)