Quoting Len Brown (lenb@xxxxxxxxxx): > Also, please test with CONFIG_X86_ACPI_CPUFREQ=n > to remove the acpi-cpufreq driver (and thus this patch) > from your kernel. If it still fails, then we know > that this driver (and this patch) are not related > to the failure. It wasn't enabled in any of the kernels i ran: # grep X86_ACPI ../configs/config* ../configs/config-2.6.22-git14-c3-via5000-firewall:# CONFIG_X86_ACPI_CPUFREQ is not set ../configs/config-2.6.22-git17-c3-via5000-firewall:# CONFIG_X86_ACPI_CPUFREQ is not set ../configs/config-2.6.23-rc1-git5:# CONFIG_X86_ACPI_CPUFREQ is not set ../configs/config-2.6.23-rc1-git6:# CONFIG_X86_ACPI_CPUFREQ is not set ../configs/config-2.6.23-rc1-git9:# CONFIG_X86_ACPI_CPUFREQ is not set ../configs/config-2.6.23-rc1-mm1-c3-firewall:# CONFIG_X86_ACPI_CPUFREQ is not set > Hmmm, okay, the "big hammer" works. Please see > if any of these smaller hammers work: > > pnpacpi=off > acpi=noirq > notsc _none_ of these options will work. The machine locks up solid. And that's what i'm the most surprised about. The last time i withnessed a solid kernel lockup without any panic/notification is _years_ ago. I also tried a kernel without "CPU Frequency scaling", so it is not the scaling up/down in Mhz of the cpu. I've even just compiled/run a kernel with libata and even that one still locks up. New round of git bisects i guess (this time powercycle instead of reboot and wait few hours before ginving it "bisect good" ) Will report back. Danny -- - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
