Saturday, February 9, 2008


Hello all,

For the uninitiated, git-bisect is a tool for identifying the patch that caused a particular bug. It works on the principle of binary search. Its a really cool thing to use, but it takes a long time to complete (not so much with make -j16 on my new Core 2 Quad!!). I identified that v2.6.24 was good and the current one was bad. (v2.6.24 was released around 15 days ago.) And within those 15 days some 4K odd patches had accumulated and I had to bisect the big pile! But thankfully it was successful and it pointed me to the right commit and hence I was able to fix the problem. Here's the patch -

Thursday, February 7, 2008

My new Intel DG33FB

Hello all!

I decided to go for a upgrade from my Core 2 Duo + 1G RAM to Core 2 Quad + 4G RAM. My dealer gave me a Intel original Motherboard DG33FB for it. The problems with the new motherboard began right at the dealer's place. I have listed them out one by one, along with the way I was able to overcome the it

  1. Linux wouldn't boot, nor does Windows!
    • The first thing I did on my new machine was trying to get Linux up and running. But it wouldn't work! Then I had to reluctantly try booting windows, which didn't work either. Thinking that this could be a problem with BIOS settings, I just wandered around in the BIOS setup utility and came across an option called 'SATA MODE' which had AHCI and IDE as its two options, of which AHCI was selected by default. I tried changing it to IDE and it could boot windows now.
    • I could boot only the default Fedora 8 kernel, but none of the vanilla kernels. Surprisingly all of them hung when they tried to scan the PCI root bus.
  2. Vanilla kernels wouldn't boot.
    • My next objective was to boot vanilla kernels which i mentioned were hanging when they tried accessing the PCI bus. Since ACPI was famous for causing such failures, I tried booting with acpi=off kernel parameter. The kernel booted normally, but sadly it did use only one processor (out of the four in Core 2 Quad) which is no way acceptable!

    • I decided to debug this problem and started inserting printk()s in the source to find out the exact reason for the hang. During this process, I came across a kernel parameter called pci=conf1 and I decided to give it a try. To my surprise, the kernel (2.6.24-rc5) booted perfectly fine. Later i found out an option in menuconfig called 'PCI ACCESS' which allowed me to select the 'direct' method of probing PCI devices, and enabling this made me avoid passing the extra 'pci=conf1' parameter to the kernel.
  3. linux-2.6.git does come up, but I see a lot of PCI noise in dmesg and X doesn't come up
    • Is this a regression ? Yes, it is! Everything worked perfectly with 2.6.24-rc5, but not with linux-2.6.git i.e, 2.6.24. I decided to git-bisect to find the faulty commit. I was doing my first git-bisect in my life! I bisected it and found the commit that caused this. Deciding to debug this, I began looking at the code. It was fairly easy to fix this, and I came out with a patch to LKML hoping to see it included in linux-2.6.git soon..
      Incidentally, the bug was reported already and a fix for it was committed yesterday! You can read the whole thread here on LKML Archive(