[lkml]   [2007]   [Jan]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Linux 2.6.20-rc6 - sky2 resume breakage

On Tuesday, 30 January 2007 09:57, Len Brown wrote:
> On Monday 29 January 2007 19:12, Linus Torvalds wrote:
> >
> > On Mon, 29 Jan 2007, Stephen Hemminger wrote:
> > >
> > > Why do you insist on maintaining the wrong initialization order
> > > on resume? When I raised the issue, Len brought up that the resume
> > > order did not match spec, but then there has been slow progress
> > > in fixing it (it's buried in -mm tree).
> >
> > It's not getting merged, SINCE IT DOESN'T WORK. It causes all sorts of
> > problems, because ACPI requires all kinds of things to be up and running
> > in order to actually work, and that in turn breaks all the devices that
> > have different ordering constraints.
> >
> > ACPI is a piece of sh*t. It asks the OS to do impossible things, like
> > running it early in the config sequence when it then at the same time
> > wants to depend on stuff that are there *late* in the sequence. It's not
> > the first time this insane situation has happened, either.
> And it will not be the last:-)
> There are really two cases, one is easy, one hard:
> 1. The ACPI spec and our knowledge of how the HW and talking to our own BIOS
> folks tells us quite a bit about how things are supposed to work.
> 2. "Windows Bug Compatibility" (tm)
> When OEMs build systems and test them only with Windows, then
> the implementation quirks of Windows get ingrained in the platforms.
> Linux then tries to run on the same platform and wonders why
> the BIOS does "unusual" things. The answer is because it has been
> only tested on Windows and BIOS quirks slip through Windows testing.
> To be fair, the exact same thing would happen in reverse to Windows
> if vendors only tested with Linux.
> is intended to help mitigate some of this
> problem. So at least vendors that care about Linux can make sure that
> they minimize the curve balls they throw us.
> An example of a recent curve ball is when the BIOS supplies two APIC (MADT)
> tables. Well, the spec says there should be only one... We have proof
> that Windows doesn't use the 1st for enumerating processors because
> Windows works on a box with a garbled 1st table.
> If we prove that Windows doesn't use the second either then it means
> they enumerate processors via the DSDT -- which means bringing up
> the ACPI interpreter before bringing up SMP -- and that would require
> a significant change to Linux boot sequence...
> > But we'll try to merge the patch that totally switches around the whole
> > initialization order hopefully early after 2.6.20. But no way in hell do
> > we do it now, and I personally suspect we'll end reverting it when we do
> > try it just because it will probably break other things. But we'll see.
> I agree with this plan, and I concur with your outlook.
> I think Rafel is holding the ball here as we wait for an SMP-safe freezer:

Well, no longer. :-)

The freezer in 2.6.20-rc6 should be SMP-safe and the patches to change
the suspend-resume code ordering are in -mm:


I have no problems whatsoever with these patches on SMP boxes and if anyone
has, please let me know.


If you don't have the time to read,
you don't have the time or the tools to write.
- Stephen King
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-01-30 17:03    [W:0.167 / U:1.156 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site