keyboard.c: Stop flooding dmesg with useless warnings

keyboard.c: Stop flooding dmesg with useless warnings

[Parag Warudkar]

I use  Apple keyboard and mouse which seem to generate events with 
keycode==0.

keyboard.c floods dmesg endlessly with below messages. This happens at a 
very fast rate and never stops, leaving the dmesg unusable.

[46591.960000] keyboard.c: can't emulate rawmode for keycode 0
[46591.996000] keyboard.c: can't emulate rawmode for keycode 0
[46592.032000] keyboard.c: can't emulate rawmode for keycode 0
[46592.068000] keyboard.c: can't emulate rawmode for keycode 0
[46592.104000] keyboard.c: can't emulate rawmode for keycode 0
[46592.140000] keyboard.c: can't emulate rawmode for keycode 0
[46592.176000] keyboard.c: can't emulate rawmode for keycode 0
[46592.212000] keyboard.c: can't emulate rawmode for keycode 0
[46592.248000] keyboard.c: can't emulate rawmode for keycode 0

The patch below avoids printing the warning if keycode == KEY_RESERVED.

If a more correct fix is possible please let me know and I will redo this.
(I suspect avoiding call to emulate_raw() with value ranges it cannot 
emulate might be a better fix?)

Otherwise please consider applying.

Signed-off-by: Parag Warudkar <parag.warudkar@gmail.com>

--- linux-2.6-wk/drivers/char/keyboard.c	2007-03-24 23:01:19.000000000 -0400
+++ linux-2.6/drivers/char/keyboard.c	2007-03-24 21:43:58.000000000 -0400
@@ -1161,7 +1161,7 @@

  	if ((raw_mode = (kbd->kbdmode == VC_RAW)) && !hw_raw)
  		if (emulate_raw(vc, keycode, !down << 7))
-			if (keycode < BTN_MISC && keycode != KEY_RESERVED)
+			if (keycode < BTN_MISC)
  				printk(KERN_WARNING "keyboard.c: can't emulate rawmode for keycode %d\n", keycode);

  #ifdef CONFIG_MAGIC_SYSRQ	       /* Handle the SysRq Hack */

Re: keyboard.c: Stop flooding dmesg with useless warnings

[Parag Warudkar]

>
> Signed-off-by: Parag Warudkar <parag.warudkar@gmail.com>
>
> --- linux-2.6-wk/drivers/char/keyboard.c	2007-03-24 23:01:19.000000000 
> -0400
> +++ linux-2.6/drivers/char/keyboard.c	2007-03-24 21:43:58.000000000 -0400
> @@ -1161,7 +1161,7 @@
>
> 	if ((raw_mode = (kbd->kbdmode == VC_RAW)) && !hw_raw)
> 		if (emulate_raw(vc, keycode, !down << 7))
> -			if (keycode < BTN_MISC && keycode != KEY_RESERVED)
> +			if (keycode < BTN_MISC)
> 				printk(KERN_WARNING "keyboard.c: can't 
> emulate rawmode for keycode %d\n", keycode);
>
> #ifdef CONFIG_MAGIC_SYSRQ	       /* Handle the SysRq Hack */
>

Yikes. Wrong one above. Right one below. Against latest git.

I use  Apple keyboard and mouse which seem to generate events with
keycode==0.

keyboard.c floods dmesg endlessly with below messages. This happens at a
very fast rate and never stops, leaving the dmesg unusable.

[46591.960000] keyboard.c: can't emulate rawmode for keycode 0
[46591.996000] keyboard.c: can't emulate rawmode for keycode 0
[46592.032000] keyboard.c: can't emulate rawmode for keycode 0
[46592.068000] keyboard.c: can't emulate rawmode for keycode 0
[46592.104000] keyboard.c: can't emulate rawmode for keycode 0
[46592.140000] keyboard.c: can't emulate rawmode for keycode 0
[46592.176000] keyboard.c: can't emulate rawmode for keycode 0
[46592.212000] keyboard.c: can't emulate rawmode for keycode 0
[46592.248000] keyboard.c: can't emulate rawmode for keycode 0

The patch below avoids printing the warning if keycode == KEY_RESERVED.

If a more correct fix is possible please let me know and I will redo this.
(I suspect avoiding call to emulate_raw() with value ranges it cannot
emulate might be a better fix?)

Signed-off-by: Parag Warudkar <parag.warudkar@gmail.com>

--- linux-2.6/drivers/char/keyboard.c	2007-03-24 21:43:58.000000000 -0400
+++ linux-2.6-wk/drivers/char/keyboard.c	2007-03-24 23:01:19.000000000 -0400
@@ -1161,7 +1161,7 @@

  	if ((raw_mode = (kbd->kbdmode == VC_RAW)) && !hw_raw)
  		if (emulate_raw(vc, keycode, !down << 7))
-			if (keycode < BTN_MISC)
+			if (keycode < BTN_MISC && keycode != KEY_RESERVED)
  				printk(KERN_WARNING "keyboard.c: can't emulate rawmode for keycode %d\n", keycode);

  #ifdef CONFIG_MAGIC_SYSRQ	       /* Handle the SysRq Hack */

Re: About GCC4 Optimization

[Linus Torvalds]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=gb2312, Size: 1345 bytes --]



On Sun, 25 Mar 2007, yuan cooper wrote:
>  
> during my work, I found there is a bug with GCC4 O2 optimization.

Technically, it's a misfeature fo gcc4, not a bug.

The C language allows for type-based alias detection, and gcc notices that 
a "float *" cannot ever alias with a "unsigned long *", so it decides to 
not even do the loads and stores..

Now, there's two things wrong with this picture:

 - gcc is being an ass. type-based alias detection should happen only as a 
   last resort, and gcc should know and notice that *despite* the types 
   being different, they definitely alias.

   So what gcc does may be technically legal, but it's still a horribly 
   bad thing to do. Sadly, some gcc people seem to care more about "letter 
   of the law" than "sanity and quality of implementation".

 - as a result, you should always compile any kernel stuff with 
   "-fno-strict-aliasing", which should turn this off. If it *still* 
   happens with that flag, then it is indeed a compiler bug.

> float ftmp;
> unsigned long tmp;
> ftmp = 1.0/1024.0;
> tmp  = *(unsigned long *)(&ftmp);
> tmp  = (tmp >> 11) && 0xFFF;
>  
> if optimization level is O2, gcc will MOV eax to tmp, but current eax has a random value.
> -O is ok and gcc3 with O2 is ok too.

That said, you really _really_ shouldn't be doing FP in the kernel anyway.

		Linus

RE: About GCC4 Optimization

[David Schwartz]

> So what gcc does may be technically legal, but it's still a horribly
> bad thing to do. Sadly, some gcc people seem to care more
> about "letter
> of the law" than "sanity and quality of implementation".

You know, it would be one thing if they were consistent. A policy that, by
default, you get all the optimizations the relevant standards allow wouldn't
be a problem. But they do this when they feel like it, and they disable
significant optimizations even where the standards allow them when they feel
like that.

See, for example:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20099

"You cannot create code that works with this option and doesn't work without
it except by violating the POSIX standard. So POSIX code should not have
this option enabled by default -- it's a pure pessimization." Yet the option
is on by default when -pthreads is specified.

DS

PS: Yes, I'm still pissed about this. ;)

Re: About GCC4 Optimization

[Andrew Morton]

On Sun, 25 Mar 2007 03:42:25 +0000 "yuan cooper" <yuanxjtu@hotmail.com> wrote:

> Hi all:
>  
> during my work, I found there is a bug with GCC4 O2 optimization.
>  
> ---------------------
> float ftmp;
> unsigned long tmp;
> ftmp = 1.0/1024.0;
> tmp  = *(unsigned long *)(&ftmp);
> tmp  = (tmp >> 11) && 0xFFF;
> --------------------- 
>  
> if optimization level is O2, gcc will MOV eax to tmp, but current eax has a random value.
> -O is ok and gcc3 with O2 is ok too.
>  
>  
> I am a kernel newbie, I don't know how to make contributions to janitors, who will help me? It's my first post, any suggestion will be appreciated.

Don't use floating point in kernel code.  At all.

Re: keyboard.c: Stop flooding dmesg with useless warnings

[Dmitry Torokhov]

On Saturday 24 March 2007 23:38, Parag Warudkar wrote:
> 
> >
> > Signed-off-by: Parag Warudkar <parag.warudkar@gmail.com>
> >
> > --- linux-2.6-wk/drivers/char/keyboard.c	2007-03-24 23:01:19.000000000 
> > -0400
> > +++ linux-2.6/drivers/char/keyboard.c	2007-03-24 21:43:58.000000000 -0400
> > @@ -1161,7 +1161,7 @@
> >
> > 	if ((raw_mode = (kbd->kbdmode == VC_RAW)) && !hw_raw)
> > 		if (emulate_raw(vc, keycode, !down << 7))
> > -			if (keycode < BTN_MISC && keycode != KEY_RESERVED)
> > +			if (keycode < BTN_MISC)
> > 				printk(KERN_WARNING "keyboard.c: can't 
> > emulate rawmode for keycode %d\n", keycode);
> >
> > #ifdef CONFIG_MAGIC_SYSRQ	       /* Handle the SysRq Hack */
> >
> 
> Yikes. Wrong one above. Right one below. Against latest git.
> 
> I use  Apple keyboard and mouse which seem to generate events with
> keycode==0.
> 
> keyboard.c floods dmesg endlessly with below messages. This happens at a
> very fast rate and never stops, leaving the dmesg unusable.
> 
> [46591.960000] keyboard.c: can't emulate rawmode for keycode 0
> [46591.996000] keyboard.c: can't emulate rawmode for keycode 0
> [46592.032000] keyboard.c: can't emulate rawmode for keycode 0
> [46592.068000] keyboard.c: can't emulate rawmode for keycode 0
> [46592.104000] keyboard.c: can't emulate rawmode for keycode 0
> [46592.140000] keyboard.c: can't emulate rawmode for keycode 0
> [46592.176000] keyboard.c: can't emulate rawmode for keycode 0
> [46592.212000] keyboard.c: can't emulate rawmode for keycode 0
> [46592.248000] keyboard.c: can't emulate rawmode for keycode 0
> 
> The patch below avoids printing the warning if keycode == KEY_RESERVED.
> 
> If a more correct fix is possible please let me know and I will redo this.
> (I suspect avoiding call to emulate_raw() with value ranges it cannot
> emulate might be a better fix?)

Actually the keyboard driver should not emit input events for that key code.
Is this a USB keyboard?

-- 
Dmitry

Re: keyboard.c: Stop flooding dmesg with useless warnings

[Parag Warudkar]

>
> Actually the keyboard driver should not emit input events for that key code.
> Is this a USB keyboard?
>
> --
> Dmitry
>

Yes this is a USB keyboard.

Any hint as to where I should start looking to make the driver not
emit input event for keycode==0?

Parag

Re: keyboard.c: Stop flooding dmesg with useless warnings

[Dmitry Torokhov]

On Sunday 25 March 2007 01:27, Parag Warudkar wrote:
> >
> > Actually the keyboard driver should not emit input events for that key code.
> > Is this a USB keyboard?
> >
> > --
> > Dmitry
> >
> 
> Yes this is a USB keyboard.
> 
> Any hint as to where I should start looking to make the driver not
> emit input event for keycode==0?
>

Was it always doing that? I'll add Jiri Kosina to the CC list as he's
involved with HID now.

-- 
Dmitry

Re: keyboard.c: Stop flooding dmesg with useless warnings

[Parag Warudkar]

On 3/25/07, Dmitry Torokhov <dtor@insightbb.com> wrote:
> On Sunday 25 March 2007 01:27, Parag Warudkar wrote:
> > >
> > > Actually the keyboard driver should not emit input events for that key code.
> > > Is this a USB keyboard?
> > >
> > > --
> > > Dmitry
> > >
> >
> > Yes this is a USB keyboard.
> >
> > Any hint as to where I should start looking to make the driver not
> > emit input event for keycode==0?
> >
>
> Was it always doing that? I'll add Jiri Kosina to the CC list as he's
> involved with HID now.
>

Something (some keypress?) triggers it (by default it doesn't happen
immediately after a boot) - but once it starts it doesn't seem to stop
printing.

Parag

Re: keyboard.c: Stop flooding dmesg with useless warnings

[Jiri Kosina]

On Sun, 25 Mar 2007, Parag Warudkar wrote:

> > > Yes this is a USB keyboard. Any hint as to where I should start 
> > > looking to make the driver not emit input event for keycode==0?
> > Was it always doing that? I'll add Jiri Kosina to the CC list as he's 
> > involved with HID now.
> Something (some keypress?) triggers it (by default it doesn't happen 
> immediately after a boot) - but once it starts it doesn't seem to stop 
> printing.

First, is there any specific kernel version where this started to happen 
to you, or is this long-standing bug you have been experiencing with older 
kernels too?

It would be useful if you could compile your kernel with CONFIG_HID_DEBUG 
and send the output both from the time the keyboard is connected and also 
when things go wild.

-- 
Jiri Kosina

Re: keyboard.c: Stop flooding dmesg with useless warnings

[Parag Warudkar]

On 3/25/07, Jiri Kosina <jkosina@suse.cz> wrote:
> First, is there any specific kernel version where this started to happen
> to you, or is this long-standing bug you have been experiencing with older
> kernels too?

I am not sure about specific kernel version but I think this (2.6.20)
is the first kernel which gives me problems. It had not happened with
any previous versions.
I am compiling latest git to see if I have the problem with it - will
let you know how that goes.

>
> It would be useful if you could compile your kernel with CONFIG_HID_DEBUG
> and send the output both from the time the keyboard is connected and also
> when things go wild.

Yes, trying that out - will post the output soon.

Thanks!

Parag