bug hunt

I received some help with qemu on the NetBSD mailing lists, if I add -monitor stdio to the qemu command line then I get the monitor command line in the xterm where I started qemu. This allows me to send key events to the running emulation. I wanted this so I could drop NetBSD to ddb in qemu so I could tweak variables in the kernel. With the added command args I can now do this.

I wanted ddb so I could turn on the UVM history printing, I tried running with the history printing on as a default but this produces so much output it has a severe performance impact and I was never sure what was happening because everything scrolled up the screen so fast. So, I thought that I could disable the printing by default and just enable it before I run my tests. Hence the need for ddb. Unfortunately, even enabling the UVM history printing just prior to running my tests still produces so much output that it does not help. So, I will try just enabling the printing in the veriexec page routines to try and keep the amount of information manageable.

assaulted battery

Bleh. The batter(y|ies) in my UPS ha(s|ve) decided to finally die. Of course, this does not happen at a convenient time so that I could wander on down the road to "The Battery Bloke" and order some new ones, oh no, here we are in the middle of some craziness to do with the shortest day of the year in the Northern Hemisphere (longest day of the year where I am) so everyone has shut down for some rampant consumerism. Fortunately, the power is pretty reliable where I am so the UPS is really more for comfort value in the face of storms and the like. I can plug everything direct into the mains and soldier on until the new year.

Another day, another kenel panic

Been trying to get verified exec on NetBSD to work correctly at the page level. I have worked on this off and on for quite a while. I did have it working fine but, unfortunately, it relied on all the filesystems calling genfs_getpages() which does not happen. I have shifted the code into the uvm getpages call but now when I force a modified page detection and try to repeat the test things seem to fall apart, pages get flagged as being modified when they are not and sometimes the kernel panics in genfs_putpages(), unfortunately the kernel core from this panic does not show much, I suspect that the cause of the panic is well in the past and it is just UVM tripping over something bad I have done to it or something I have omitted to do.

I managed to clean up some bugs by compiling with DIAGNOSTIC set in the kernel config. I wanted to use UVMHIST and UVMHIST_PRINT but the output they produce is way too verbose. I disabled the uvm history printing by tweaking the controlling variable with the idea that I would do the setup for my tests, tweak the uvm log printing on and then run the test. This plan has fallen apart somewhat because I am using the qemu machine emulator to provide me with a crashbox machine without requiring extra hardware which is always an advantage when you try hacking code during your daily commute to work on the train.

Qemu has actually worked very well for me, saved a lot of time by allowing me to keep my development environment running while the kernels panic in their qemu sandbox, it also means I don't put my file systems at risk when the kernel crashes. Making a backup of the qemu hard disk is a simple copy and I can just copy back the backup if the machine gets trashed. I can manipulate the qemu hard disk by using the vnd file-as-a-disk-image driver thing (vnode disk driver) to copy files to and from the qemu disk image so installing a new kernel or retrieving the kernel core dumps is quite easy, just a matter of a few short scripts to make life convenient. The only problem I have is that the keystrokes for generating keyboard events for "special" keys like dropping to ddb or changing virtual consoles are a mystery to me - the documented ones don't work - for example, ctrl-alt is supposed to release the focus from the qemu window after it has been locked there by clicking in the window. This does not seem to work and the quick look at the code for qemu I cannot see how they events can be generated in the sdl input handling code - just trying to use a special key combo like ctrl-alt-f1 changes the virtual console on the host machine not in qemu. I have put the question about this up on current-users@n.o, we shall see if there is an answer otherwise I shall just hack something in to qemu that will do what I want... ahhh the joys of having the source.

Introduction

I suppose I will have to make the assumption that someone apart from myself will read this one day...you poor sod, taking an interest in my inane ramblings.

My day job is sysadmin'ing a bunch of Solaris machines for a local arm of a multinational company.

Outside of work, part of my "copious" spare time is spent hacking on NetBSD. I am a NetBSD developer and originally was made a developer to work on curses after submitting a patch that added the SYSV style keypad functionality to BSD curses. I have added more bits and pieces to curses and have done complete reimplementations of the ETI (Extended Terminal Interface) libraries libmenu and libform. Lately, I have turned into a wannabe kernel hacker by implementinging verified exec (veriexec) which is a unique security feature that of all the open source OS's, only NetBSD has - it prevents trojans and other executables from running and ensures what you do run is what you expect you are running... along with a bunch of other features. I am currently trying to clean up some patches that extend veriexec to the executable page level. I had this working fine but, unfortunately, only for filesystems that used the generic get pages function (genfs_getpages()). Making the feature available at a more universal level is causing some interesting times as I grapple with more of UVM's guts.

Initial Revision

I suppose it's official now, I have joined the 21st century and have a blog like all the other cool internet kids. Wow.

I never was good at keeping a diary, it will be an interesting experiment to see how long this blog lasts before it withers and dies.