URGENT: WPC54G / Toshiba / FC3 (Forget it!)

[Dave Jones]

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