[lkml]   [2009]   [Feb]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: PCI PM: Restore standard config registers of all devices early
    On Mon, 2009-02-02 at 14:15 -0800, Linus Torvalds wrote:
    > On Mon, 2 Feb 2009, Rafael J. Wysocki wrote:
    > >
    > > I think it would be easier to make ACPI allow us to run AML with interrupts
    > > off.
    > Well, I'd agree, except I have this strong memory of us having known bugs
    > with ACPI turning hard-interrupts on again. Similarly, it uses mutexes etc
    > that simply don't work with interrupts off and/or may turn them on again
    > thanks to scheduling.
    > "Fixing" that seems not very easy. ACPI has a bad habit of being _really_
    > hard to fix in this area.
    > I do agree that _if_ we can just fix ACPI, we wouldn't have these issues,
    > and we should just call it with interrupts disabled with our existing
    > code. But my previous email was a "maybe we can do it like this" kind of
    > thing, which might allow us to use ACPI with none of the irq-off issues.

    Len, what's your take here ? How much of that stuff is burried deep and
    how much is nicely split in a "helper" layer we could more easily fix ?

    I'm adding Ingo to the CC as he might have more ideas on how best to
    just make the mutexes work & not complain rather than touching ACPI
    itself... again, just like boot, might just be a matter of instructing
    the mutexes/lockdep to shut up and ignore in_atomic() in those "special"
    phases such as late suspend and early resume().

    That would help me for something else that broke recently too ... I have
    a special "hook" in radeonfb that my arch calls to resume it -very-
    early (interrupts off, I haven't even re-enabled the L2 cache). This is
    very useful to help debugging problems at resume since without that you
    basically don't see a thing and we have no serial port on most of these

    However, that started breaking recently due to fb_set_suspend() calling
    into various bits of infrastructure that is no longer safe to call in
    atomic context.

    Here too, in fact, those -would- be safe since it's mostly a matter of
    teaching things like mutex of kmalloc that we are not in standard
    SYSTEM_RUNNING state, and thus mutex can just pretty much ignore the
    problem of being in atomic state and kmalloc/gfp could automatically
    degrade to GFP_ATOMIC (*)

    So it might just all be a matter of making might_sleep() shut up in
    late suspend/early resume, and possibly msleep() silently turn into
    mdelay or something like that. Just make sure we don't actually try to
    schedule (and possibly BUG_ON if we actually end up blocking on a mutex,
    we should not).

    Len, do you think that would work with ACPI or it's more convoluted than
    that ?

    (*) There are reasons to think that kmalloc/gfp should both silently
    turn into GFP_NOIO always while the suspend process is started, but
    that's somewhat a different subject. Rafael, did we ever act on that ?
    It's an old discussion we had but I don't know if we actually
    implemented anything.

    IE. Without that, afaik, a driver that hasn't suspend yet might end up
    being blocked in some allocation somewhere due to an attempt to page
    things out on to an already sleeping device. That driver might be in
    such blockage while holding one of its internal mutexes or other thing
    that will cause it's own suspend routine later on to screw up. etc etc
    etc... In general, best to avoid having to teach drivers that in
    suspend-land, non-atomic, allocations may block for ever. Better to make
    them all atomic magically.


     \ /
      Last update: 2009-02-03 00:01    [W:0.023 / U:5.076 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site