checkdirty:
ifneq ( $(shell git ls-files -m | wc -l), 0 )
    @echo Detected modifed files.
    @exit 2 ;
endif

Basically, if any files were found changed the error would be printed. However, this would never work. I verified that git ls-files -m | wc -l returned 0 but the code would always execute. I eventually found the solution in the GNU Make documentation. From the page

Conditional directives are parsed immediately. This means, for example, that automatic variables cannot be used in conditional directives, as automatic variables are not set until the recipe for that rule is invoked. If you need to use automatic variables in a conditional directive you must move the condition into the recipe and use shell conditional syntax instead.

So essentially the shell command was never run when the ifneq was being parsed. I assume the strings were being compared which would explain always failing the equal test. The correct way to implement this test is then:

checkdirty:
    @if [ $(shell git ls-files -m | wc -l) -ne 0 ] ; \
    then \
        echo Detected modifed files. \
        exit 2 ; \
    fi

okteta

:set filetype=make

In this example it sets the file type to a Makefile file type. Replace the type as appropriate.

http://www.decompile.com/cpp/faq/file_and_line_error_string.htm

This was a bit of a problem as neither of my machines had a serial port. Well the desktop has the hardware on the motherboard, but no physical port actually connected to it. So the first step was to add a PCI-serial card. I linked the port to ttyS2 with the following line in /etc/serial.conf

/dev/ttyS2 uart 16550A port 0xe480 irq 16 baud_base 115200 spd_normal skip_test

Using a USB-Serial dongle allowed me to verify a connection with my laptop. Now I was ready to try making the kgdb connection. I verified that kgdb is enabled in the generic ubuntu kernel, then added a boot item in grub with the following options.

kgdbwait kgdboc=ttyS2,115200

I followed this process to connect but unfortunately at boot time ttyS2 is not linked properly.  So I changed the kernel options to

kgdbwait

After booting the machine I had to manually enable kgdboc.

$ sudo -s

$ echo ttyS2,115200 > /sys/module/kgdboc/parameters/kgdboc

At this point the machine totally freezes waiting for the debugger to connect. So I started gdb as noted before and the connection was made. I issued continue on gdb and the desktop started responding again.  To break again I press Alt+SysRq g on the desktop.

Now that the connection is there I need debug symbols. To make sure I had symbols for the kernel I built my own kernel image.  The process for building on ubuntu is found here with special information for karmic here.  I ended up making a new sub-flavour as described here. Once the kernel was installed and booting I turned to getting symbols for my kernel module.  I compiled my module with CONFIG_DEBUG_INFO=y to ensure it contained the symbols. Then I had to make gdb load the symbols. That process is detailed on pages 100-101 of Linux Device Drivers chapter 4(PDF).  It’s also available here.

Now I could set a breakpoint in my module and step through it.  However when it came to setting a breakpoint in the kernel code I also got this error:

Cannot insert breakpoint 5.
Error accessing memory address 0xffffffff813a40fb: Unknown error 18446744073709551615.

I disabled CONFIG_DEBUG_RODATA in my kernel compile and was able to set breakpoints. I’m not certain that this was the fix as there were some other changes in the process I was using to debug at the same time as this change. But it’s worth a try if you’re getting this error.

typedef int (__stdcall *MYFUNC) (int, int);

Medibuntu

This device is not configured correctly (code 1).

The official Microsoft documentation on the errors is seriously useless. However, I had much more luck on OSR. This thread informed me that I could get further details on what caused the failure by looking at the file C:\WINDOWS\setupapi.log (C:\WINDOWS\inf\setupapi.dev.log on Vista). Indeed, there is a nice log of the setup process that was followed for the install and the error that eventually killed it. The error I was having was something like this:

#E279 Add Service: Failed to create service “somename”. Error 1078: The name is already in use as either a service name or a service display name.

It pointed to the service in my inf file that was failing to install. With some pointers from this thread I realized what the problem was. I had gone through a full renaming of my driver and had installed the previous version on the failing machine. In the inf the service to be installed had a different key, but was using the same description. To get the install working again I removed all entries for both driver names from HKLM\SYSTEM\* in the registry, then rebooted to updated Windows copy of the driver database.  Installed again and success!

WDF – Framework for a driver that handles most of the ugly PNP for you.

OSR – The place to go for answers on driver development. The mailing list has been a lifeline. Microsoft developers even hang out there.