Finding kernel modication that caused the boot failure using git-bisect?
Back in the days when Debian repo had the linux-image-2.6.30-bpo.2-686_2.6.30-8~bpo50+2_i386.deb kernel, I had installed on my PC. Now I have installed the current kernel package from lenny-backports -- linux-image-2.6.32-bpo.5-686_2.6.32-29~bpo50+1_i386.deb.
The problem is that the old 2.6.30 kernel use to boot fine on my PC but the new 2.6.32 kernel hangs during PCI enumeration stage of the kernel boot phase..
[ 0.472235] ACPI: PCI Interrupt Link [LNKH] (IRQs 10 11 15) *0, disabled.
[ 0.478536] vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none
[ 0.480017] vgaarb: loaded
[ 0.484078] PCI: Using ACPI for IRQ routing
[ 0.488278] Switching to clocksource tsc
[ 0.494208] pnp: PnP ACPI init
[ 0.497298] ACPI: bus type pnp registered
[ 0.502819] pnp: PnP ACPI: found 7 devices
[ 0.506912] ACPI: ACPI bus type pnp unregistered
[ 0.511524] PnPBIOS: Disabled by ACPI PNP
[ 0.550571] pci 0000:01:00.0: PCI bridge, secondary bus 0000:02
[ 0.556480] pci 0000:01:00.0: IO window: disabled
[ 0.561354] pci 0000:01:00.0: MEM window: disabled
[ 0.566312] pci 0000:01:00.0: PREFETCH window: disabled
[ 0.571706] pci 0000:00:1c.0: PCI bridge, secondary bus 0000:01
[ 0.577615] pci 0000:00:1c.0: IO window: 0x1000-0x1fff
[ 0.582918] pci 0000:00:1c.0: MEM window: 0x80000000-0x801fffff
[ 0.588999] pci 0000:00:1c.0: PREFETCH window: 0x80200000-0x803fffff
[ 0.595518] pci 0000:00:1c.1: PCI bridge, secondary bus 0000:03
[ 0.601425] pci 0000:00:1c.1: IO window: 0xf000-0xffff
[ 0.606729] pci 0000:00:1c.1: MEM window: 0xdff00000-0xdfffffff
[ 0.612812] pci 0000:00:1c.1: PREFETCH window: 0x80400000-0x805fffff
[ 0.619341] pci 0000:00:1c.0: enabling device (0004 -> 0007)
-----the kernel hangs at this point------
Before reporting this bug to the kernel community I would like to find out what kernel commit between 2.6.30 and 2.6.32 made the later unbootable. Any ideas how can I use git tools like git-bisect to find out the culprit? A step-by-step tutorial would be really helpful. I have been able to reproduce this issue with the vanilla kernel from kernel.org