Comment 53 for bug 1093217

I did a bisection and found the point where the long boot started happening:

ca2281b Prevent interface errors with Seagate FreeAgent GoFlex {BAD}
cf1ed4a Fix a dead loop in async_synchronize_full() {GOOD}

There are a couple of puzzling things.

First this good to bad point is between Ubuntu-3.2.0-32.51 and Ubuntu-3.2.0-33.52. Either Ubuntu 3.2.0-30 is not affected or there are multiple places that would go from good to bad and the bisect methodology caused them to be skipped over.

When bisection started hovering around the "Fix a dead loop in async_synchronize_full()" commit I thought it would be the culprit since the stack traces in dmesg show it is stuck in/near this code. However, the version with this change works and it is the one right after it that fails.

The messages about AE_AML_INFINITE_LOOP start appearing at a different point. When they start occurring the boot time is still normal. The INIFINITE_LOOP messages show up in dmesg a couple minutes after boot. I did not fully bisect this but did make 3 kernels near a point where it went from no INFINITE_LOOP message to one.

3001d0d mm: mmu_notifier: fix freed page still mapped in secondary MMU {has INIFINITE_LOOP}
fef5d62 mm: setup pageblock_order before it's used by sparsemem
6c9bb2e mm/page_alloc.c: remove pageblock_default_order()
f00167c ASoC: wm8962: Allow VMID time to fully ramp {no INF_LOOP}
661696d USB: echi-dbgp: increase the controller wait time to come out of halt.
426561c ARM: Fix undefined instruction exception handling
310f418 ARM: 7478/1: errata: extend workaround for erratum #720789 {no INF_LOOP}

But the funny thing is the kernel at commit cf1ed4a ({GOOD} above) does has neither the long timeout problem nor the INIFINITE_LOOP problem.