Comment 46 for bug 89746

I checked out the ubuntu-gutsy kernel tree using git. I compiled a kernel using the make-kpkg method, installed the resulting .deb, and verified that it required noapic to boot correctly. This was done by roughly following the instructions here for a git build:
  https://help.ubuntu.com/community/Kernel/Compile
After getting the tools installed, this was roughly:
  add my user to the "src" group
  logout/login again for this change to take effect
  cd /usr/src
  git clone git://kernel.ubuntu.com/ubuntu/ubuntu-gutsy.git ubuntu-gutsy
  ln -s linux ubuntu-gutsy
  cd ubuntu-gutsy
  cp /boot/config-2.6.22-11-generic .config
  make menuconfig
  remove kernel debugging from options (in kernel hacking)
  save new .config (by exiting menuconfig)
  # the build command procedure using AUTOBUILD=1 didn't seem to work for me.
  export CONCURRENCY_LEVEL=4
  make-kpkg --rootcmd fakeroot --initrd --append-to-version=-test kernel-image kernel-headers
  cd ..
  sudo dpkg -i linux-image-blah-blah-blah.deb
attempt to boot new kernel without noapic
  Since I am able to verify whether the kernel boots correctly without using all the restricted modules, I didn't bother trying to compile them. My plan is that when I get a kernel to boot without noapic, I will also run powertop to verify that the ehci interrupts are under control. After rebooting back into my stock gutsy kernel, I did this:
  cd /usr/src/ubuntu-gutsy
  git bisect start
  git bisect bad
Then I tried to build 2.6.15, since that kernel seemed to boot ok without noapic from the SimplyMEPIS liveCD:
  git checkout v2.6.15
  # git complained about some file being modified or something, so I did this...
  git checkout -f v2.6.15
  added -fno-stack-protector to CFLAGS in top-level build Makefile
  cp /boot/config-2.6.22-11-generic .config
  make menuconfig
  removed kernel debug symbols and saved .config again
  # Unfortunately, trying to build with make-kpkg immediately failed. The only way I could build was like this:
  make clean
  make
  sudo make modules_install
  cd /boot
  sudo cp /usr/src/ubuntu-gutsy/arch/x86_64/boot/bzImage vmlinuz-2.6.15
  sudo update-initramfs -c -k 2.6.15
  # Unfortunately, update-initramfs complained that udev hooks needs kernel 2.6.17.
  # So I was unable to try booting 2.6.15. I decided to see if 2.6.17 would work.
  cd /usr/src/ubuntu-gutsy
  git checkout v2.6.17
  added -fno-stack-protector to CFLAGS in top-level Makefile
  cp /boot/config-2.6.22-11-generic .config
  make menuconfig
  removed kernel debug symbols from build
  # make-kpkg still failed immediately, so reverted to old-school style:
  make clean
  make
  sudo make modules_install
  cd /boot
  sudo cp /usr/src/ubuntu-gutsy/arch/x86_64/boot/bzImage vmlinuz-2.6.17
  sudo update-initramfs -c -k 2.6.17
  sudo vi grub/menu.lst
  added lines for 2.6.17 above "BEGIN AUTOMAGIC KERNELS LIST"
  rebooted into 2.6.17 kernel without "quiet splash noapic noirqdebug" boot flags

Unfortunately, the 2.6.17 boot consistently just hung shortly after initializing USB, although the keyboard was still responsive. Sometimes the last message was about "Uniform CD-ROM driver" and other times it was from the USB subsystem. I tried booting with "noapic noirqdebug" and this did not work either. I was hoping that by this procedure I could boot an old kernel without "noapic" and then begin bisecting the kernel changesets (with the help of git bisect) to find what change made "noapic" necessary on my system. Then some low-level guru might be able to get it fixed once that "smoking gun" change was found.

When I get some time again I will try to replicate this procedure with some other kernel versions to see if I can find one that boots without noapic, and thus initiate my bisection process.

Can anyone else try to reproduce my findings so far? Was my build procedure for 2.6.17 valid?