>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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |