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
- 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.
- 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.
- 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(http://lkml.org/lkml/2008/2/7/55).