This module induces a soft lockup on one or more processors. That sounds crazy, you say, why on earth would I want to do that? Well if you run in an enterprise environment, it's useful to be able to not only detect soft lockups (where a CPU is stuck in kernel mode for a long time), but also to panic the machine so that the kernel core file can be captured for debugging. There is a sysctl parameter which enables this (/proc/sys/kernel/softlockup_panic) and this module will allow you to test that it's working.
On Tuesday, 12th August, we had a baby boy who we are calling Owen George Malley (not "Olaf" as previously advertised :-). He was born at 7:33am and weighed 3.73kg (8lb 3.5oz); there are a couple of early photos on Facebook if you're one of my "friends". Thanks for all the good wishes, we really appreciate it.
At the moment I'm working on cleaning up the recently-GPL'd VMware-tools kernel modules (see the open-vm-tools project) that have been added to linux-staging, to see if I can get them into a suitable state for inclusion in mainline. I've started with vmblock, the virtual filesystem needed for drag-and-drop, which now that I've looked at it in detail may not be suitable anyway (it has some design shortcomings which the kernel massive may not find acceptable). Still, I've chopped out two-thirds of the code, most of which was just there for backwards compatibility or operating-system-agnostic reasons, and there are no checkpatch or sparse warnings. The result is here. The individual commits (about 200 of 'em so far) are in the git repository here (branch staging-cjm).
For once the weather has been clear for the last few nights, so I've been able to continue indulging my latest obsessional hobby of astronomy. Currently learning my way around the constellations and finding as many deep sky objects as conditions and my old 10x50 binoculars will allow. Normally I only have to contend with our neighbours' ridiculously unnecessary patio lighting rig, a couple of street lights and a 500W security lamp opposite (as well as the general orange haze from the town). Now there's a gibbous moon high overhead as well, so as nothing much else is visible at the moment I thought I might as well have a look at that.
Last night it was in Gemini, only 8° from Mars, so I tried to capture them on my (compact Fuji) digital camera.
Had to overexpose the moon somewhat in order to get a decent image, but here it is (click to zoom):
You can just about make out that Mars is gibbous as well (illuminated from the right in this picture). Here's the equivalent view in the excellent Your Sky Virtual Telescope.
Season five of LugRadio started today, so if you are into Linux and Open Source, and have a sense of humour, then do yourself a favour and download the first episode.
Thanks to Jorge Bernal who highlighted a cool new technique for resizing images to different aspect ratios without the relevant bits looking strangely squished. I tried out the GIMP plugin for Feisty and it turns out to be really easy to use.
Just open your image, create a new transparent layer and roughly paint over the parts of the photo that you don't want to be altered. Then select the original layer and choose Layer->Liquid rescale.... Choose the new size, select "Activate feature preservation" and select your mask layer. Hit OK and watch the magic!
Here's an example before and after shot. I masked out myself in the foreground (but not the park bench), the couple above my head, the flowerpots and the signs, and the tree in the background. In the scaled image the path has a visible line down the middle, but there are some heavy shadows and busy areas so I think it's done a pretty good job. With some extra fiddling of options I could probably make it more subtle, and from the demo video it seems to work really well on photos that have reasonably large areas of flat colour like beaches and sky.
For comparison purposes, here is a version that is simply scaled without the liquid algorithm, and one using the plugin but with no areas masked.
In the hope that it might be vaguely useful to somebody I'm posting the results of my next attempt at a device driver, this time a morse code generator. Morse purists will no doubt tell me that it's not valid to translate into a written form (rather than audible), and that it should be "dit" and "dah" rather than "dot" and "dash", but hey it's only a programming exercise.
The basic premise is that there is a character device called "/dev/morse" into which you can write plain text (only upper case characters, numerals and spaces will be encoded though, everything else will be ignored), and if you read from the same file you will get the morse-code version. For example:
# insmod ./morse.ko (udev or some other mechanism creates /dev/morse at this point) # echo "TO BE OR NOT TO BE" > /dev/morse # cat /dev/morse - --- / -... . / --- .-. / -. --- - / - --- / -... .
The read (cat) will block by default, waiting for more input to be fed into the buffer. The other night I had it piped into another process which made an external LED flash in sympathy, and you could imagine it driving a buzzer or the PC speaker etc.
Here is the code and the Makefile. I've tested it against 2.6.23-rc6 and 2.6.22.6, but it may well work with older kernels with minor tweaking. I've run it against the style checker and it came up clean, and I'd welcome any comments or suggestions.
From a thread on LinuxQuestions.org I spent a little time today digging around in the kernel sources for an answer to "how do I get my module to automatically create nodes in /dev without having to manually run mknod every time the module is loaded?".
I'm sure I read about this in Greg Kroah-Hartman et al's excellent Linux Device Drivers but I think maybe it's a bit out of date because it mentions writing init scripts to run mknod. The current fashion seems to be to let sysfs and udev do all the hard work. This example (cobbled together from various modules in the 2.6.20 kernel) demonstrates the basic premise:
$ ls Makefile mymodule.c $ make make -C /lib/modules/2.6.20-16-generic/build M=/home/chris3/example modules make[1]: Entering directory `/usr/src/linux-headers-2.6.20-16-generic' CC [M] /home/chris3/example/mymodule.o Building modules, stage 2. MODPOST 1 modules CC /home/chris3/example/mymodule.mod.o LD [M] /home/chris3/example/mymodule.ko make[1]: Leaving directory `/usr/src/linux-headers-2.6.20-16-generic' $ ls -l /dev/mym* ls: /dev/mym*: No such file or directory $ sudo insmod ./mymodule.ko Password: $ ls -l /dev/mym* crw-rw---- 1 root root 248, 0 2007-06-29 17:39 /dev/mymod0 $ cat /sys/class/mymodule/mymod0/dev 248:0 $ sudo rmmod mymodule $ ls -l /dev/mym* ls: /dev/mym*: No such file or directory
UPDATE: Having dug out my copy of LDD3 it does actually mention the above technique later in the book, once sysfs has been explained.
Am I the only one to notice the similarity between Current Car (top) and Dream Car (bottom)?
One day it will be mine...
For those people who haven't found the option yet, it's buried in the Options dialog:
Tools->Options->OpenOffice.org->Memory->Enable systray quickstarter
Anyway, I digress. Much to my annoyance, the first time I went to copy some content from my laptop I wasn't able to mount the filesystem. I'm currently running Ubuntu Dapper (6.06) with the latest kernel (2.6.15-28-686). The message log was full of SCSI errors:
[17182606.828000] usb 4-4: new high speed USB device using ehci_hcd and address 2 [17182607.168000] Initializing USB Mass Storage driver... [17182607.168000] scsi0 : SCSI emulation for USB Mass Storage devices [17182607.168000] usb-storage: device found at 2 [17182607.168000] usb-storage: waiting for device to settle before scanning [17182607.168000] usbcore: registered new driver usb-storage [17182607.168000] USB Mass Storage support registered. [17182612.172000] Vendor: USB 2.0 Model: Storage Device Rev: 0100 [17182612.172000] Type: Direct-Access ANSI SCSI revision: 00 [17182612.176000] Vendor: USB 2.0 Model: Storage Device Rev: 0100 [17182612.176000] Type: Direct-Access ANSI SCSI revision: 00 [17182612.180000] Vendor: USB 2.0 Model: Storage Device Rev: 0100 [17182612.180000] Type: Direct-Access ANSI SCSI revision: 00 [17182612.184000] Vendor: USB 2.0 Model: Storage Device Rev: 0100 [17182612.184000] Type: Direct-Access ANSI SCSI revision: 00 [17182612.184000] Vendor: USB 2.0 Model: Storage Device Rev: 0100 [17182612.184000] Type: Direct-Access ANSI SCSI revision: 00 [17182612.244000] Driver 'sd' needs updating - please use bus_type methods [17182612.304000] usb 4-4: reset high speed USB device using ehci_hcd and address 2 [17182612.556000] usb 4-4: reset high speed USB device using ehci_hcd and address 2 [17182612.696000] SCSI device sda: 97692174 512-byte hdwr sectors (50018 MB) [17182612.696000] sda: assuming drive cache: write through [17182612.816000] usb 4-4: reset high speed USB device using ehci_hcd and address 2 [17182612.964000] SCSI device sda: 97692174 512-byte hdwr sectors (50018 MB) [17182612.964000] sda: assuming drive cache: write through [17182612.964000] sda: sda1 [17182612.992000] sd 0:0:0:0: Attached scsi disk sda [17182613.236000] usb-storage: device scan complete [17182613.616000] sdb : READ CAPACITY failed. [17182613.616000] sdb : status=1, message=00, host=0, driver=08 [17182613.616000] sd: Current: sense key: No Sense [17182613.616000] Additional sense: No additional sense information [17182613.616000] sdb: assuming drive cache: write through [17182614.232000] sdb : READ CAPACITY failed. [17182614.232000] sdb : status=1, message=00, host=0, driver=08 [17182614.232000] sd: Current: sense key: No Sense [17182614.232000] Additional sense: No additional sense information [17182614.232000] sdb: assuming drive cache: write through [17182614.232000] sdb:<6>usb 4-4: reset high speed USB device using ehci_hcd and address 2 [17182676.376000] usb 4-4: reset high speed USB device using ehci_hcd and address 2 [17182708.388000] usb 4-4: reset high speed USB device using ehci_hcd and address 2 [17182740.388000] usb 4-4: reset high speed USB device using ehci_hcd and address 2 [17182772.400000] usb 4-4: reset high speed USB device using ehci_hcd and address 2 [17182774.280000] sd 0:0:0:1: SCSI error: return code = 0x50000 [17182774.280000] end_request: I/O error, dev sdb, sector 0 [17182774.280000] Buffer I/O error on device sdb, logical block 0 [17182804.652000] usb 4-4: reset high speed USB device using ehci_hcd and address 2 [17182836.652000] usb 4-4: reset high speed USB device using ehci_hcd and address 2 [17182868.892000] usb 4-4: reset high speed USB device using ehci_hcd and address 2 [17182900.892000] usb 4-4: reset high speed USB device using ehci_hcd and address 2
I tried out a number of different kernels (minimal builds of the mainstream kernel) from 2.6.15 to 2.6.20.3. The problem seems to have been fixed in 2.6.19.
The patch that fixes it seems to be this one. Apparently it changes the default capacity of disabled read-only devices from some random number (as in previous kernels) to zero, which seems like a more sensible value to me anyway. It's in drivers/scsi/sd.c on line 1217 of the 2.6.19 kernel, or line 1170 in the Dapper 2.6.15-28 source.
Follow the instructions on the Ubuntu wiki if you want to build a fixed kernel, making the same change as in the above patch.
UPDATE
Hmm. Seems like it's more complicated than I thought; even though the filesystems mount I'm getting loads of 0x70000 SCSI errors, and the file on the USB drive ends up corrupted. Back to the drawing board....
A while ago I got an automated email from the One Laptop Per Child development team to let me know that the patch had made it into their kernel. I'm not sure how many children in developing nations will be needing support for the modem :-) but nevertheless it's a great project and it's cool to think that my tiny contribution will make it onto potentially millions of computers worldwide.
kernel: drivers/usb/class/cdc-acm.c: Zero length descriptor references kernel: cdc_acm: probe of 1-1.2:1.0 failed with error -22I've submitted a patch to the kernel guys to fix this and I'm happy to say that it's almost found it's way into a released version (all things being well it'll be released in 2.6.19). It's really simple so if you can't wait for the new kernel, then you can try patching your own module - I'll post some instructions when I get a chance.