opteron 170, part 2
[Yesterday]{20060802210126}, I wrote about how my Opteron 170 was crashing at random times. Today I have a working system.
opteron 170
My new shiny Opteron 170 just came in. I used to say that Opteron 1xx line was a waste of money because it was basically the Athlon64 but more expensive because of the Opteron branding. Recently AMD made the choice easier by dropping dual-core Athlon64 processors with 2M of L2 cache. The last line of Athlon64 S939 will have a 512k L2 cache. That’s a mere 256k per core. And isn’t that only twice the size of the L1 cache? yuck! So, I blew the extra $300 on the extra 1.5M of L2 cache.
OLS keysigning / 2006
I think this year’s key post-keysigning-party work was the least effort ever. I wanted to write down the procedure for anyone interested. First a few assumptions: you have been given a file that contains the fingerprints and names of everyone that attended the keysigning party, you verified the file’s sha1 sum at the event, this file’s sha1 sum was verified at the event by everyone whose keys you want to sign, you trust that the people whose keys you are signing did not lie about checking the sha1 sum of the file. A tool that make sthings easier is caff and gpg-agent.
git-find findings
So I have a simple git-find working, and now I want to use it to rip out some patches I am interested in. The repository I am working on has a lot of uninteresting deltas in it that I don’t care about. I am actually only interesting in backporting an interface change in one file from the klipsng branch: $ git-find klipsng --file linux/net/ipsec/ipsec_sa.c ... This works as advertised, I get a list of revisions that altered that file. The current git command line parsing does not allow me to do much with this however.
starting on git-find
So I am giving myself some time to write a git-find script that I can use to feed commits to another tool, like git-graft (or git-cherry-pick). I don’t really know what I am doing yet, so I want to survey what is available in git-* tools and reuse as much of the available features.
git-graft and git-find brainstorm
I want to be able to take a bunch of patches that were applied to one semi-related branch and appened them to the current branch, or better yet a new branch of the current. The bunch of patches will be selected by what they change; I should be able to graft all patches that modify some file, or modify some regular expression. Here is what I mean: ,-----X---X---X---X--- ... --- "historical" branch o `--------------------Y "current" branch \ `---Z---Z---... "working" branch You start off at current branch and run something like: git-find historical --file some_file.c --or --re 'some pattern' \ | git-graft --new-branch working - This will let me take the interesting subset of X commits and apply them at some point Y. Should the patches X cause conflicts with the current branch, then git-graft needs to let the user resolve those conflicts a patch at a time. The default is to apply onto the current branch, however if desired it should be possible to create the changes on a new, working, branch. The result is a new set of Z commits, as shown above.
pretty function tracing
I wanted to see how different functions got used in a block of code that I was new to… and was having a hard time understanding. My UML instance was acting flaky and didn’t cooperate with gdb, so I could not single step the code. I added a small chunk of C code to generate pretty tracing that looks like this: ,-< ipsec_sa_wipe:946 | ,-< ipsec_sa_put:549 | `-> ipsec_sa_put:561 = 0 `-> ipsec_sa_wipe:1054 = 0 Functions can nest upto 25 times (arbitrary max) and after that it stops indenting nicely. The code has to be modified so that at the entry of each block there is a call to the IN macro, and on the exit to the OUT macro. Here is an example:
uml and multiple network segments
I am doing a lot of network testing and require multiple virtual networks created for my UML’s. Debian’s uml-utilities package does not currently support bringing up multiple network segments, although the uml_switch daemon can be ran multiple times. In such a setup each uml_switch is associated with it’s own tapX device and maintains one network segment. I modified two files: /etc/init.d/uml-utilities /etc/default/uml-utilities And filed bug 378166.
lastfm artist and title to clipboard
Sharing your current [last.fm]{tag/lastfm} track on irc in realtime is very important. :) Here is a ion3 binding that will use xclip to copy the current track info into the X clipboard. defbindings("WScreen", { kpress("Mod4+grave", "ioncore.exec('echo player/currentlyPlaying | nc localhost 32213 | xclip -i')"), }) Put it in ~/.ion3/cfg_user.lua.
reverting a git changeset
I accidentally committed a changeset without a description and wanted to fix it. As I was pushing enter I realized that I didn’t want to commit yet. I have not pushed anywhere – an important requirement for this kind of revert. I basically want to do a bk fix -c (if I recall my bk correctly). Since git revert pollutes the history, it is not the right thing to do here since the bad changeset was not pushed. But it would be the right thing to do had I pushed my change.