lkml.org 
[lkml]   [2007]   [Jan]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Linux 2.6.20-rc6 - sky2 resume breakage
    Date
    Hi,

    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.
    >
    > http://www.linuxfirmwarekit.org/ 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:
    > http://lists.osdl.org/pipermail/linux-pm/2006-December/004233.html

    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:

    pm-change-code-ordering-in-mainc.patch
    swsusp-change-code-ordering-in-diskc.patch
    swsusp-change-code-order-in-diskc-fix.patch
    swsusp-change-code-ordering-in-userc.patch
    swsusp-change-code-ordering-in-userc-sanity.patch
    swsusp-change-pm_ops-handling-by-userland-interface.patch

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

    Greetings,
    Rafael


    --
    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 majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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