Bug 5158

Summary: ps/2 keyboard on x86_64 does not work as module in 2.6.13-rc6
Product: Other Reporter: Erik Quaeghebeur (bugzilla.kernel.org)
Component: ConfigurationAssignee: Roman Zippel (zippel)
Status: REJECTED DOCUMENTED    
Severity: blocking CC: akpm, bunk, protasnb, vojtech
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: 2.6.13-rc6 Subsystem:
Regression: --- Bisected commit-id:
Attachments: dmesg when booting with atkbd built in
dmesg when booting with atkbd as module
diff dmesg-atkbd-built-in.txt dmesg-atkbd-as-module.txt
.config used for 2.6.13-rc6 compilation (of course atkbd changes)

Description Erik Quaeghebeur 2005-08-30 11:29:39 UTC
Most recent kernel where this bug did not occur: 2.6.11
Distribution: Gentoo
Hardware Environment: x86_64 (athlon64 3200 Win. on Asus a8v-deluxe)
Software Environment: Gentoo-linux
Problem Description: 
When upgrading kernel from 2.6.11 to 2.6.12 and later 2.6.13-rc6, my ps/2
keyboard does not work (after grub booted); this is with 'atkbd' compiled as a
module (module did load).  When 'atkbd' is compiled in, everything works fine. 
On another x86_64 system, 'atkbd' as module is reported to work fine. Further
references: <http://bugs.gentoo.org/show_bug.cgi?id=101906>.

Steps to reproduce: compile 2.6.12+ kernel with 'atkbd' as module, boot with
this kernel.
Comment 1 Erik Quaeghebeur 2005-08-30 11:32:07 UTC
Created attachment 5814 [details]
dmesg when booting with atkbd built in
Comment 2 Erik Quaeghebeur 2005-08-30 11:32:47 UTC
Created attachment 5815 [details]
dmesg when booting with atkbd as module
Comment 3 Erik Quaeghebeur 2005-08-30 11:33:34 UTC
Created attachment 5816 [details]
diff dmesg-atkbd-built-in.txt dmesg-atkbd-as-module.txt
Comment 4 Erik Quaeghebeur 2005-08-30 11:35:08 UTC
Created attachment 5817 [details]
.config used for 2.6.13-rc6 compilation (of course atkbd changes)
Comment 5 Dmitry Torokhov 2005-08-30 11:48:47 UTC
I don't think that the following config is allowed:

#
# Hardware I/O ports
#
CONFIG_SERIO=m
CONFIG_SERIO_I8042=y

Did you edit your .config by hand?
Comment 6 Adrian Bunk 2005-08-30 12:02:17 UTC
Unfortunately, his .config is allowed by the rules in the Kconfig file.

I'll attach a patch for this bug.
Comment 7 Adrian Bunk 2005-08-30 12:15:41 UTC
I think I see where the problem is, but the fix I had in mind doesn't work due
to the following that looks like a kconfig bug:


config FOO
        tristate
        default m

config BAR
        tristate
        default y
        depends on FOO


CONFIG_FOO=m
CONFIG_BAR=y


Comment 8 Adrian Bunk 2005-08-30 12:26:34 UTC
And a second kconfig bug involved in this issue:

config FOO
        tristate
        default m
        select BAR

config BAR
        tristate
        default y


CONFIG_FOO=m
CONFIG_BAR=m


A select mustn't _lower_ the value of the select'ed variable.
Comment 9 Dmitry Torokhov 2005-08-30 12:32:10 UTC
kconfig issues aside I still don't quite understand how the kernel could 
possibly link if serio is a module and i8042 which uses serio interface is 
built in. 
Comment 10 Adrian Bunk 2005-08-30 12:54:41 UTC
The kernel could link because i8042 was built as if it was included statically,
but it was not linked into the kernel.

drivers/Makefile contains:
  obj-$(CONFIG_SERIO)             += input/serio/

With CONFIG_SERIO=m and CONFIG_SERIO_I8042=y, the build system doesn't go into
input/serio/ when linking the kernel.
Comment 11 Adrian Bunk 2005-08-30 12:58:25 UTC
Looking deeper into this issue, it seems the two kconfig problems I've described
are the complete problem, and the SERIO* dependencies seem to be correct.
Comment 12 Erik Quaeghebeur 2005-08-30 13:00:14 UTC
I use "make menuconfig" and "make oldconfig" sequences only, no direct editing
of ".config" was done.

I can't seem to directly change the SERIO and SERIO_I8042 settings.  These are
determined by my other choices.

If you want me to try something (such as recompiling and booting with other
settings), feel free to ask.
Comment 13 Adrian Bunk 2005-08-30 13:06:50 UTC
@Erik:
That's not required.
The two kconfig issues I've described should cover the problems leading to your
problem.
Comment 14 Roman Zippel 2005-08-30 16:39:56 UTC
The first example is not a bug, the dependency simply enables the default and
the symbol will have the value of the default. Change it into this to get the
intended result:

config BAR
        tristate
        default FOO

I have to look closer into the second example, you get into unspecified area
here, but it sort of makes sense. :)
Comment 15 Adrian Bunk 2005-08-30 17:09:19 UTC
The real world example resulting in this bug is:

<--  snip  -->

if SERIO

config SERIO_I8042
        tristate "i8042 PC Keyboard controller" if EMBEDDED || !X86
        default y
        depends on !PARISC && (!ARM || ARCH_SHARK || FOOTBRIDGE_HOST) && !M68K
...

<--  snip  -->

If me must in this case duplicate all dependencies (including SERIO) in the
default line, this will be very error-prone (your proposed alternative solution
doesn't work in the case when the question is user-visible).

My first example works as I'd intuitively expect it if the question is
user-visible, but it doesn't work if it isn't user-visible.
That is _very_ confusing, especially here where the question might or might not
be user-visible.

Documentation/kbuild/kconfig-language.txt says:
"normal dependencies reduce the upper limit of a symbol"

Could kconfig please follow this specification in all cases (with the exception
of select's)?
Comment 16 Adrian Bunk 2005-08-30 17:20:32 UTC
Let me try to make it clearer:

If I modify my first example making BAR user-visible:

config FOO
        tristate
        default m

config BAR
        tristate "bar"
        default y
        depends on FOO

"make oldconfig" asks me:
  bar (BAR) [M/n] (NEW)

This is exactly the semantics I'd expect:
- maximum "m"
- default "m"

Why is the semantics different if the variable is not user-visible?
Comment 17 Roman Zippel 2005-08-30 18:00:34 UTC
It does follow the spec, you missed the "(see below)" part.
Dependencies define the visibility of a default or prompt and the input range,
they don't have any influence on the value of a default. This is a design
decision I'm not going to discuss in this context.

In this case you don't need to duplicate the complete dependencies, you only
need to change it to SERIO.
Comment 18 Adrian Bunk 2005-09-04 08:45:39 UTC
That the duplication of dependencies except for SERIO is not required in this
case is only true because we are in the special case where all other symbols are
booleans.

You said in your last comment "dependencies [...] don't have any influence on
the value of a default". This is not true in your current implementation. If you
look at my example from Comment 16, dependencies _do_ change the default value
if a question is user-visible.

From a user's point of view, dependencies have a different semantics depending
on whether a variable is user-visible or not. That's bad. And even worse in
cases where a variable might or might not be user-visible like in the
SERIO_I8042 case.

Yes, we can always workaround this kconfig "feature". But this problem will bite
us again and again and I don't see the big gain from your design decision.
Comment 19 Natalie Protasevich 2007-06-22 23:38:02 UTC
It looks like you guys found a solution, in the recent git tree dependencies look right.
Is that correct? The bug can be closed then.
Thanks.
Comment 20 Natalie Protasevich 2008-03-10 20:40:31 UTC
Closing the bug, works as designed.
If there are still concerns about configuration issues please reopen.