No, it shouldn't. There must of been a bug in the new sysrq code merged
in. Personally, I would just enable sysrq support for now.
> I tried doing a build of 2.4.9-ac15 plus
> patch-rml-2.4.10-pre12-preempt-kernel-1 (which did apply nicely with
> only one hunk moved only one line), but my build failed with:
Btw, this isn't the preemption patches fault, although I would recommend
you use the patches I make explicitly for Alan's tree. 2.4.9-ac14 will
apply cleanly and is at http://tech9.net/rml/linux
> arch/i386/kernel/kernel.o: In function `apm':
> arch/i386/kernel/kernel.o(.text+0xbd35): undefined reference to `__sysrq_lock_table'
> arch/i386/kernel/kernel.o(.text+0xbd3c): undefined reference to `__sysrq_get_key_op'
> arch/i386/kernel/kernel.o(.text+0xbd4d): undefined reference to `__sysrq_put_key_op'
> arch/i386/kernel/kernel.o(.text+0xbd54): undefined reference to `__sysrq_unlock_table'
>
> Which is apm.c failing on the likes of:
>
> register_sysrq_key('o',&sysrq_poweroff_op);
>
> and:
>
> unregister_sysrq_key('o',&sysrq_poweroff_op);
>
> If I turn on CONFIG_MAGIC_SYSRQ, it builds happily.
I am not familar with the code, but either apm.c needs to wrap its sysrq
calls with ifdefs or the sysrq code needs to optimize away via defines
its various sysrq functions if it is not enabled.
The maintainer (Crutcher?) should see this.
> Previously 2.4.9-ac12 with the same rml preemption patch was happy to
> compile for me. I have been using it on my Sony Vaio PCG-Z505LE
> happily.
>
> 2.4.10 is also happy to compile without CONFIG_MAGIC_SYSRQ.
-- Robert M. Love rml at ufl.edu rml at tech9.net- 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/