On Mon, 8 Oct 2012 23:59:07 -0700 Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > Feng Tang wrote: > > Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > > >> What would go wrong if the threshold were just increased to 20 on all > >> models? > > > > Then some other platform will stop to work. > > https://bugzilla.kernel.org/show_bug.cgi?id=11892 > > > > The 26/30 and 27/30 patches are bound together to fix one bug. Some > > quote from description from the 26th patch: > > > > ACPI_EC_STORM_THRESHOLD was initially 20 when it's created, and > > was changed to 8 in 2.6.28 commit 06cf7d3c7 "ACPI: EC: lower interrupt storm > > threshold" to fix kernel bug 11892 by forcing the laptop in that bug to > > work in polling mode. > > > > Hope this answers your question. > > Thanks much. Yes, that clarifies. > > The magic numbers are not too thrilling. If the polling mode just > doesn't work on the Clevo M720, why isn't the appropriate storm > threshold 999999 or infinity rather than 20? Do we know why the > polling mode doesn't work? I don't know why it doesn't work, if you check the https://bugzilla.kernel.org/show_bug.cgi?id=45151 you'll see the debugging model is test result --> patch --> 1-2 weeks + result --> patch --> 1-2 weeks + result ... over and over, which makes it difficult to root cause it but provide a workaround. And frankly speaking, I'm not sure if I can figure it out 100% even if I had that HW at hand. As per my understanding, EC is very tricky, as OS, ACPI FW, EC FW, BIOS will all access it without a global lock (in most cases), which makes it hard to work properly without race condition. Not mentioning its hardware may be broken. Thanks, Feng -- 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
