On Mon, Dec 13, 2004 at 10:49:06PM +0000, James Wilkinson wrote: > And Fedora, by its "charter" from Red Hat, is supposed to be close to > these changes. This is a two-way street, however: it is worth > bugzilla-ing, because bugzilla notes are at least read by people who can > do something about it once they spot what's wrong. Not only Red Hat folks, but also the upstream ACPI maintainers at Intel pay attention to ACPI related bugs in bugzilla. It's not that they're being ignored, half the time is spent scratching heads wondering what the hell happened. See the acpi_power_off bug for example - I've tried about a dozen patches from the upstream maintainers, all to no avail. For some folks, moving to an upstream 2.6.10-rc kernel has 'fixed' this issue for them. Indeed, the latest upstream snapshot makes my laptop power off at shutdown now too. Unfortunatly, it also _introduces_ the problem for some folks who aren't seeing it yet, so there's still ground to cover on this issue. (Sometimes just a kernel rebuild causes such heisenbugs to disappear. As I was trying to debug this problem, I added some printk's, and the problem 'went away', hrmph). People sometimes wonder why acpi suspend doesn't work so well. The biggest reason attributed is that the maintainers spend so much time on all the other bits and pieces ACPI does. In the 2.4 era kernels (RHL9 etc), we never shipped ACPI enabled kernels. Even FC1 had it disabled unless you booted with an explicit acpi=on. There are many reasons the 2.6 era kernels have it on. - The code has actually improved. ACPI works on a lot more boxes than most people think. - Without exposure to broken BIOSes, these issues will never get fixed. - There exist machines now that won't boot without ACPI enabled. They simply lack the legacy tables that we once relied upon. - Ultimately, things are converging on 'better' from a power management point of view. There's still a lot of work to be done in this area, but we're seeing incremental improvements over time. > And if it didn't happen with an FC2 kernel, but does with FC3, then if > you can pinpoint the patch that broke it, you've given them a good hint > to fix it for everyone else. FC2 -> FC3 was a quantum leap from 2.6.5 -> 2.6.9 (or at the least 2.6.8 -> 2.6.9 if updates were applied up until the recent 2.6.9 updates -- which is still a huge amount of code). I'd not suspect the additional patches added by the Fedora kernel to affect this problem, the problem is more likely a regression introduced upstream. Dave
