kernel losing printk messages?

kernel losing printk messages?

[Szekeres István]

Hello,

in 2.6.25-rc3 I'm trying to add support for an usb keyboard. While the
hid-input driver dumps a lot of debugging messages, lines seem to be
lost. Please see the lines shorter/longer than the average.

 Feb 26 21:57:20 rusalka kernel: [82279.097414]
drivers/hid/hid-input.c: Mapping: Keyboard.0000 ---> IGNORED
Feb 26 21:57:20 rusalka kernel: [82279.097419]
drivers/hid/hid-input.c: Mapping: Keyboard.0001 ---> IGNORED
 Feb 26 21:57:20 rusalka kernel: [82279.097425]
drivers/hid/hid-input.c: Mapping: Keyboard.0002 ---> IGNORED
Feb 26 21:57:20 rusalka kernel: [82279.097430] d7>[82279.234078]
drivers/hid/hid-input.c: Mapping: Consumer.01fc ---> IGNORED
 Feb 26 21:57:20 rusalka kernel: [82279.234083]
drivers/hid/hid-input.c: Mapping: Consumer.01fd ---> IGNORED
Feb 26 21:57:20 rusalka kernel: [82279.234088]
drivers/hid/hid-input.c: Mapping: Consumer.01fe ---> IGNORED
 Feb 26 21:57:20 rusalka kernel: [82279.234094]
drivers/hid/hid-input.c: Mapping: Consumer.01ff ---> IGNORED
...

Feb 26 21:57:20 rusalka kernel: [82279.234370]
drivers/hid/hid-input.c: Mapping: Consumer.0215 ---> IGNORED
 Feb 26 21:57:20 rusalka kernel: [82279.234376]
drivers/hid/hid-input.c: Mapping: Consumer.0216 ---> IGNORED
Feb 26 21:57:20 rusalka kernel: [82279.234381]
drivers/hid/hid-input.c: Mapping: Consumer.0217 ---> IGNORED
 Feb 26 21:57:20 rusalka kernel: <7Consumer.0227 ---> Key.Refresh
Feb 26 21:57:20 rusalka kernel: [82279.234480]
drivers/hid/hid-input.c: Mapping: Consumer.0228 ---> IGNORED
Feb 26 21:57:20 rusalka kernel: [82279.234485]
drivers/hid/hid-input.c: Mapping: Consumer.0229 ---> IGNORED
 Feb 26 21:57:20 rusalka kernel: [82279.234490]
drivers/hid/hid-input.c: Mapping: Consumer.022a ---> Key.Bookmarks

This is directly copied from /var/log/kern.log.

Is this a bug or a feature? :)

Thanks,
 Istvan

Re: kernel losing printk messages?

[Jiri Kosina]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 661 bytes --]

On Tue, 26 Feb 2008, Szekeres István wrote:

> in 2.6.25-rc3 I'm trying to add support for an usb keyboard. While the 
> hid-input driver dumps a lot of debugging messages, lines seem to be 
> lost. Please see the lines shorter/longer than the average.

Hi,

I don't see this on 2.6.25-rc3. Does this happen only on boot? What if you 
do

	rmmod usbhid
	rmmod hid
	modprobe hid debug=1
	modprobe usbhid

on already booted system?

> This is directly copied from /var/log/kern.log.

I guess in dmesg the output is also corrupted, right?

> Is this a bug or a feature? :)

It would be a sad feature indeed :)

-- 
Jiri Kosina
SUSE Labs

Re: kernel losing printk messages?

[Szekeres István]

Hi,

>  I don't see this on 2.6.25-rc3. Does this happen only on boot? What if you
>  do
>
>         rmmod usbhid
>         rmmod hid
>         modprobe hid debug=1
>         modprobe usbhid
>
>  on already booted system?

Actually I did it the same way. I have no info about the output on boot.

>  I guess in dmesg the output is also corrupted, right?

Interesting. Even after a dmesg -c -s 1000000 it contains only the end
of the story. This is the beginning of the dmesg output:

rusalka:~% dmesg | head
input.c: Mapping: Consumer.0230 ---> IGNORED
[85080.775297] drivers/hid/hid-input.c: Mapping: Consumer.0231 ---> IGNORED
[85080.775302] drivers/hid/hid-input.c: Mapping: Consumer.0232 ---> IGNORED
[85080.775308] drivers/hid/hid-input.c: Mapping: Consumer.0233 ---> Key.ScrollUp
[85080.775314] drivers/hid/hid-input.c: Mapping: Consumer.0234 --->
Key.ScrollDown

So the first line is corrupted. In the remaining of the output
(total=220 lines) I cannot see the evidence of corruption.

Regards,
Istvan

Re: kernel losing printk messages?

[Jiri Kosina]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1163 bytes --]

On Tue, 26 Feb 2008, Szekeres István wrote:

> >  I guess in dmesg the output is also corrupted, right?
> Interesting. Even after a dmesg -c -s 1000000 it contains only the end
> of the story. This is the beginning of the dmesg output:

Probably your kernel ring buffer is too small (log_buf_len boot 
parameter).

> rusalka:~% dmesg | head
> input.c: Mapping: Consumer.0230 ---> IGNORED
> [85080.775297] drivers/hid/hid-input.c: Mapping: Consumer.0231 ---> IGNORED
> [85080.775302] drivers/hid/hid-input.c: Mapping: Consumer.0232 ---> IGNORED
> [85080.775308] drivers/hid/hid-input.c: Mapping: Consumer.0233 ---> Key.ScrollUp
> [85080.775314] drivers/hid/hid-input.c: Mapping: Consumer.0234 --->
> Key.ScrollDown
> So the first line is corrupted. 

It is very probably just because it didn't fit into the ring buffer.

> In the remaining of the output (total=220 lines) I cannot see the 
> evidence of corruption.

So the corruption you see in your /var/log is probably just userspace 
issue (syslogd/klogd not grabbing lines coming too fast for too long?). 
Still, it seems to work for me here.

Thanks,

-- 
Jiri Kosina
SUSE Labs