I know. But _the current kernel_ oopses, so thats a bug wether SMP is well
defined or not.
> Also hoving APM support enabled under SMP will be disabling interrupts
> every second while the BIOS is called - something that (I think) should
> not be done with SMP.
Oh. Than I had good luck ;)
Anyway, the _ideal_ solution (for me) would have been to disable APM on SMP,
_except_ for pweroff or other functions that really _are_ well defined.
> > - APM poweroff causes an oops with the current apm.c
>
> This has always been true when apm support is enabled in the kernel
> but no APM BIOS exists - which is what you effectively have on all
Well, there certainly exists an APM BIOS on my SMP system ;)
> SMP systems. I am currently fixing this.
It would be great if you could somehow save the functions that work. In any
case, blidnly disabling APM on SMP (with no way to forcefully enable it)
punishes all people using the "working portions" of APM on SMP.
> read the printk - it is correct ...
Obviously, thats not the whole story, asit is quite SMP safe here (and I
suspect poweroff is safe everywhere) ;)
> You will have to try another way to do auto power off. The current code
> is correct (except for the OOPS at shutdown which I am currently fixing).
You mean you will "fix" it by simply disabling it at all times? I don't
consider this the linux way. The same logic could be applied to most parts
of the kernel (why unmask irq? why use some broken adapter c ards when
everybody knows they don't work everywhere?).
I'm absolutely not opposed to be forced to add a new commandline switch (I'd
even write the code), I just don't see the point of disabling a perfectly
fine feature just because "in theory" it does not work on all systems.
I hope we share that opinion ;)
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@goof.com |e|
-=====/_/_//_/\_,_/ /_/\_\ --+
The choice of a GNU generation |
|
-
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/