[lkml]   [2008]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: acpi_evaluate_integer broken by design

    > > Now I know why I had strange "scheduling in atomic" problems:
    > > acpi_evaluate_integer() does malloc(..., irqs_disabled() ? GFP_ATOMIC
    > > : GFP_KERNEL)... which is (of course) broken.
    > That is kinda weird. When did this all start happening?

    > > There's no way to reliably tell if we need GFP_ATOMIC or not from
    > > code, this one for example fails to detect spinlocks held.

    > Len, this looks like 2.6.28 material. But given the poor quality of
    > the changelog it is hard to be sure about this. Why isn't everyone
    > seeing these warnings? What did Pavel do to provoke these alleged
    > warnings? Nobody knows...

    I don't know know why pavel sees this and nobody else --
    maybe something unusual he's doing with suspend?

    The reason that the ACPI code is littered with bogus
    irqs_disabled() ? GFP_ATOMIC : GFP_KERNEL)
    is because, like boot, resume starts life with interrupts off.

    I would prefer that resume and boot handle this the same way,
    with system_state. However, a few years ago when I suggested
    using system_state for resume, Andrew thought that was a very
    bad idea. Andrew, do you still feel that way?


    ps. I'll put this particular fix in my tree now.

     \ /
      Last update: 2008-11-26 23:41    [W:0.024 / U:0.284 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site