>Len, ACPI people - can we fix this regression, please? > >Rafael even pinpoints exactly which patches are causing the >problem, so why didn't they get reverted before sending them off to me?
Linus, I'm sorry it was in '-rc3' -- that is as soon as I could muster the bk->git transition. Now that I'm running on git, I expect I'll be able to get the development/testing/push pipeline moving and back on schedule. Yes, we discovered both of these regressions in mm. Yes, Rafael has been a sport in filing good bug reports, and his Asus L5D has been an interesting case. Although we broke this system, I do believe that there is significant value in keeping these changes in the mainline, as I believe that it is the fastest path to improved support for all systems. Specifically... Re: the EC burst mode regression. This is an extremely important fix that has been nagging many systems for years. It has been reported to us by distros as well as on kernel.org: http://bugzilla.kernel.org/show_bug.cgi?id=3851 There has been a lot of discussion about this on the mailing list and there have been several generations of patches. We are confident that this approach is the correct solution, but clearly there are some snags. It is probable that the snags are model specific. Ironically, it would be a benefit if more machines broke like the Asus L5D because we've had a heck of a time trying to reproduce this. Indeed, I purchased an AMD laptop as similar to that model as I could find and shipped it to China explicitly for Luming to debug this very issue. Alas, that model, only slightly different, works perfectly... Re: pci_link.c regression on suspend/resume This is the issue that Patrick was trying to describe in the KS -- that we're knowingly breaking some drivers on suspend/resume. http://bugzilla.kernel.org/show_bug.cgi?id=3469 We intentionally removed a hack we put in to blindly restore PCI interrupt links. The hack can never be reliable because the AML interpreter must run to restore PCI links and it must run arbitrary AML code. But it can sleep on memory allocation and semaphores, and thus can't reliably run before we have interrupts enabled. We discussed this on linux-pm and at the PM-summit, and the consensus was that making the interrupt restoring process on resume more like boot will lead to a more robust design. The down-side is that drivers that worked before will break, and it is not a quick fix as we work our way through it. thanks, -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
