Ok, I think I understand why this regression has appeared. It looks very much that the hardy kernels are not correctly finding and booting the second cpus on AMD x2. This appears to have been separatly reported under bug #213011, which was FIX_COMMITTED _only_ in Intrepid.
In the window between Ubuntu-2.6.24-19.33 and Ubuntu-2.6.24-21.43 the commit below was added which triggers these new sysfs files, and it appears that this code in combination with the failure to start the second CPU leads to a non-booting system:
create sysfs link from acpi device to sysdev for cpu
Bug: #248509
Sys I/F under acpi device node and sysdev device node are both
needed for cpu hot-removal. User space need this link so that
they know they are poking the sys I/F for the same cpu. http://bugzilla.kernel.org/show_bug.cgi?id=9772
We can confirm this with the cpu counts as reported by the good hardy kernel, and by the good intrepid kernel, which I have already requested. If that confirms, then the fix for this bug will be to prevent the panic on creation of these sysfs files. Will spin a patch for the latter.
Ok, I think I understand why this regression has appeared. It looks very much that the hardy kernels are not correctly finding and booting the second cpus on AMD x2. This appears to have been separatly reported under bug #213011, which was FIX_COMMITTED _only_ in Intrepid.
In the window between Ubuntu-2.6.24-19.33 and Ubuntu-2.6.24-21.43 the commit below was added which triggers these new sysfs files, and it appears that this code in combination with the failure to start the second CPU leads to a non-booting system:
commit c1d87cd9e086138 b3d2326b75ae6d4 d000d7c041
Author: Zhang Rui <email address hidden>
Date: Tue Apr 29 02:36:07 2008 -0400
create sysfs link from acpi device to sysdev for cpu
Bug: #248509
Sys I/F under acpi device node and sysdev device node are both bugzilla. kernel. org/show_ bug.cgi? id=9772
needed for cpu hot-removal. User space need this link so that
they know they are poking the sys I/F for the same cpu.
http://
We can confirm this with the cpu counts as reported by the good hardy kernel, and by the good intrepid kernel, which I have already requested. If that confirms, then the fix for this bug will be to prevent the panic on creation of these sysfs files. Will spin a patch for the latter.