In article <E12uDoD-000369-00@the-village.bc.nu>,
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
>Different sort of flood. When the resume kicks in the IRQ line is locked
>solid and the box hangs. If I disable that IRQ line before suspend and
>put it back on resume after setting the controller up its happier but not
>perfect.
I suspect the right behaviour is to have something like
/*
* Sleep sequence for ACPI/APM/whatever
*/
pm_callback(PM_SLEEP);
cli();
/* real sleep here */
pm_callback(PM_WAKEUP);
sti();
so that we have all interrupts disabled until _all_ devices have been
re-initialized again. Otherwise we get tons of strange ordering things.
The reason I don't like disable/enable_irq here is that if each device
driver does a "disable_irq()"/"enable_irq()", then you cannot know in
your sleep routines whether interrupts are enabled or not. Imagine that
you have a disk controller and a mouse sharing the same irq. Depending
on which order they happen to have in the PM callback list, either of
the two will run with interrupts disabled before it goes to sleep, and
they won't be enabled until both have woken up. So wakeup behaviour is
repeatable, but the behaviour on sleep is dependent on random factors.
Imagine that the harddisk needs its interrupts in order to go to sleep
nicely (for example, doing a internal "sync everything" and needing the
interrupt to tell when it's all done). And imagine that the mouse
disabled the irq before we even get to the harddisk driver sleep
function.. BAD.
With my suggested "global" irq setup above, you at least have totally
repeatable behaviour. It will work the same whether there are shared
interrupts or not. Which will make it less likely that we'll have
problems that only happen on certain machines - the nasty kind to
debug.. We may have other problems (it requires that all devices can be
re-initialized without interrupts, but that should be fine), but at
least they'll be more repeatable.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue May 23 2000 - 21:00:24 EST