I built 2.6.24-git15 this morning and seem to have picked up a little

“funny” along the way – occasionally what should be a single key stroke

ends up spraying multiple characters on to my screen.
By this I mean I type “w” and get “wwwwwwwww” or whatever. 
This has happened a number of times with random keys so I don't think

that it is a sticky key and I did not see this on previous builds.
Has anyone else had this happen to them?  While they were sober that

is.    
--

This or similar has been going on for over a year now. At least on SuSE distros.
See https://bugzilla.novell.com/show_bug.cgi?id=223561
Comment 22 in particular.
Regards

Mark

--

What keyboard is that? (USB/PS2?).
--

Jiri Kosina

--

Thank you for your response, Jiri - 
On this system I am using a PS2 Keyboard - and let me stress that it is

only occasionaly that it happens - I have had 2.6.24-git15 up for about

2 hours now and have only seen it about a dozen times.
I also note one other thing - although my system is lightly loaded - at

this time of day I am pretty much just using email on an AMD 64 X2 4600+

with 2 gigs of of memory - I have noticed several times that I will be

typing away and nothing is appearing on the screen - and a few seconds

later - boom - there it all is.
There is no way an old fella like me should be able to out type a system

like this.
Chris
--

It could be some timing problem. Does this happen also in console, or

only when running X?
Could you please try to
- boot with 'nohpet' kernel parameter

- taskset -p 0x00000002 <pid_of_Xserver> if this is a multi-CPU/core

  machine and you are experiencing the problems only in X
Thanks,
--

Jiri Kosina

--

Jiri - 
I have several hours of running aith nohpet and X's affinity set to 2

instead of 3 and so far everything is running flawlessly.
Even though Mark Hounschell pointed me at this old Suse issue 
(https://bugzilla.novell.com/show_bug.cgi?id=223561)
which has the same suggestion (taskset) as you made, for me this was

something new starting with 2.6.24-git15 - maybe something made a timing

issue fall a little closer to the edge.  
Would you like me to try and further isolate things for you here by

either running with just nohpet OR just the taskset to change X's

affinity?
Once again thank you for your prompt (and effective) support on this

issue.
Chris
--

Great, so this definitely is some kind of timing issue, thanks for 
Yes, could be some scheduler update that made the problem more visible. If

you'd had time to use git-bisect to find the exact commit that exposes

your problem, that might be interesting. But as you said that this is not 
Yes, that would help. Especially knowing whether running with 'nohpet'

fixes the problem would be nice.
--

Jiri Kosina

SUSE Labs

--

Jiri - 
I have been up and running now for about a half hour – since I did not

hear your preference I stayed with git15 instead of jumping up to git16

in an attempt to avoid introducing any unwanted changes.
The only non-standard thing I did was to use the nohpet directive at

boot time - I did NOT enter the previously used taskset command to alter

X's affinity. 
I have been banging away on my keyboard for about a half hour now with

no problems. While this is not conclusive on a 'soft' problem, from what

I experienced yesterday I would have expected to have seen the problem

by now.
Please let me know if there are any other items you would like to do or

options you would like me to try.
Chris
--

Thanks. So this clearly indicates that you are hitting either hardware

bug, or some bug in our HPET handling code.
Adding Ingo and Thomas to CC. Short summary -- Chris (and apparently other

people) are sometimes seeing repeated keypressess when HPET timer is used.

This doesn't happen when alternative clocksource is used.
Full thread: http://lkml.org/lkml/2008/2/6/100
--

Jiri Kosina

SUSE Labs

--

Now, it would be interesting to know what the detailed difference is,

when the system is booted with and without nohpet.
Chris, can you please provide the dmesg output and the output of

/proc/timer_list for each bootup ?
.config file would be interesting as well.
Thanks,

	tglx

--

OK - I think that this is wat you are looking for.   If there is

anything else I can proivde or if I have mucked up this simple cut and

paste just let me know.
Chris
/proc/timer_list after a "standard" boot up:
Timer List Version: v0.3

HRTIMER_MAX_CLOCK_BASES: 2

now at 145975685977 nsecs
cpu: 0

 clock 0:

  .index:      0

  .resolution: 1 nsecs

  .get_time:   ktime_get_real

  .offset:     1202395158972331114 nsecs

active timers:

 clock 1:

  .index:      1

  .resolution: 1 nsecs

  .get_time:   ktime_get

  .offset:     0 nsecs

active timers:

 #0: <f731fee0>, tick_sched_timer, S:01

 # expires at 145976000000 nsecs [in 314023 nsecs]

 #1: <f731fee0>, it_real_fn, S:01

 # expires at 145992695933 nsecs [in 17009956 nsecs]

 #2: <f731fee0>, it_real_fn, S:01

 # expires at 146449411457 nsecs [in 473725480 nsecs]

 #3: <f731fee0>, it_real_fn, S:01

 # expires at 147127669217 nsecs [in 1151983240 nsecs]

 #4: <f731fee0>, hrtimer_wakeup, S:01

 # expires at 148894085562 nsecs [in 2918399585 nsecs]

 #5: <f731fee0>, hrtimer_wakeup, S:01

 # expires at 149298827121 nsecs [in 3323141144 nsecs]

 #6: <f731fee0>, hrtimer_wakeup, S:01

 # expires at 162723437247 nsecs [in 16747751270 nsecs]

 #7: <f731fee0>, hrtimer_wakeup, S:01

 # expires at 168492312121 nsecs [in 22516626144 nsecs]

 #8: <f731fee0>, it_real_fn, S:01

 # expires at 170611081082 nsecs [in 24635395105 nsecs]

 #9: <f731fee0>, hrtimer_wakeup, S:01

 # expires at 326651677345 nsecs [in 180675991368 nsecs]

 #10: <f731fee0>, hrtimer_wakeup, S:01

 # expires at 3659678299700 nsecs [in 3513702613723 nsecs]

 #11: <f731fee0>, it_real_fn, S:01

 # expires at 28835194687544 nsecs [in 28689219001567 nsecs]

  .expires_next   : 145976000000 nsecs

  .hres_active    : 1

  .nr_events      : 37758

  .nohz_mode      : 0

  .idle_tick      : 0 nsecs

  .tick_stopped   : 0

  .idle_jiffies   : 0

  .idle_calls     : 0

  .idle_sleeps    : 0

  .idle_entrytime : 0 nsecs

 ...
[ message continues ]

Both boots use acpi_pm clocksource and there is nowhere a sign of HPET

in the logs except the "nohpet" on the command line.
/me is confused 
How does "nohpet" on the command line influence the behaviour, when

there is no hpet available at all.
Thanks,

	tglx
--

Thomas - 
I hope that, from at least my perspective, your question is rhetorical.

I am fully willing to publicly admit that I don't have a clue. About

much of anything. I will even admit that until prompted by Jiri

yesterday I had never even heard of the nohpet directive for the boot

line. 
I am willing to do whatever I can to help isolate and or resolve this

issue, but to do so I need one of you experts to firmly grab hold of

some portion of my anatomy and guide me in the right direction.
Chris
--

Chris,
Can you please apply the following patch, boot w/o nohpet and provide

the dmesg output ?
Thanks,

	tglx
diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c

index 429d084..4e98241 100644

--- a/arch/x86/kernel/hpet.c

+++ b/arch/x86/kernel/hpet.c

@@ -375,8 +375,10 @@ int __init hpet_enable(void)

 {

 	unsigned long id;
-	if (!is_hpet_capable())

+	if (!is_hpet_capable()) {

+		printk(KERN_INFO "HPET not available\n");

 		return 0;

+	}
 	hpet_set_mapping();
@@ -392,6 +394,7 @@ int __init hpet_enable(void)

 	 * information and the number of channels

 	 */

 	id = hpet_readl(HPET_ID);

+	printk(KERN_INFO "HPET available. ID = %lx\n", id);
 #ifdef CONFIG_HPET_EMULATE_RTC

 	/*

@@ -412,6 +415,7 @@ int __init hpet_enable(void)

 	return 0;
 out_nohpet:

+	printk(KERN_INFO "HPET disabled\n");

 	hpet_clear_mapping();

 	boot_hpet_disable = 1;

 	return 0;

--

Actually, I have no idea :) I am right now confused too, I am quite

surprised that 'nohpet' fixes the problem for you, Chris, even though your

system doesn't have HPET at all :)
Could you please double-check that 'nohpet' really reliably fixes the

issue?
I suggested using nohpet as I have already seen reports about such kinds

of problems on machines that had hpet, but this one seems to be more

confusing :)
Also, output of the kernel with the patch Thomas provided would be

interesting.
Thanks,
--

Jiri Kosina

SUSE Labs

--

And of course I forgot to mention -- if this started happening only

recently, and wasn't hapenning with older kernels, doing git-bisect might

help here (assuming that are able to see whether the problem is present or

not) to find the exact commit that causes the behavior you are seeing.
--

Jiri Kosina

SUSE Labs

--

Thomas - 
I believe that the following is the output you are looking for - sorry

for the delay - between doctors and grandkids I was ready for a few pain

pills and a long nap.  
I suspect you often feel the same way after dealing with some who post

here.
Thank you for your support
Chris
[    0.000000] Linux version 2.6.24-git15-ch2 (root@popeye) (gcc version

4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)) #3 SMP PREEMPT Thu

Feb 7 22:00:10 CST 2008

[    0.000000] BIOS-provided physical RAM map:

[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009f400 (usable)

[    0.000000]  BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved)

[    0.000000]  BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)

[    0.000000]  BIOS-e820: 0000000000100000 - 000000007fff0000 (usable)

[    0.000000]  BIOS-e820: 000000007fff0000 - 000000007fff3000 (ACPI NVS)

[    0.000000]  BIOS-e820: 000000007fff3000 - 0000000080000000 (ACPI data)

[    0.000000]  BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)

[    0.000000]  BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)

[    0.000000] 1151MB HIGHMEM available.

[    0.000000] 896MB LOWMEM available.

[    0.000000] Scan SMP from c0000000 for 1024 bytes.

[    0.000000] Scan SMP from c009fc00 for 1024 bytes.

[    0.000000] Scan SMP from c00f0000 for 65536 bytes.

[    0.000000] found SMP MP-table at [c00f5380] 000f5380

[    0.000000] Entering add_active_range(0, 0, 524272) 0 entries of 256 used

[    0.000000] Zone PFN ranges:

[    0.000000]   DMA             0 ->     4096

[    0.000000]   Normal       4096 ->   229376

[    0.000000]   HighMem    229376 ->   524272

[    0.000000] Movable zone start PFN for each node

[    0.000000] early_node_map[1] active PFN ranges

[    0.000000]     0:        0 ->   524272

[    0.000000] On node 0 totalpages: 524272

[    0.000000]   DMA zone: 32 pages used for memmap

[    0.000000]   DMA zone: 0 pages reserved

[    0.000000]   DMA zone: 4064 pages, LIFO batch:0

[ ...
[ message continues ]

Which is expected, as we have "nohpet" on the kernel command line.
Can you provide the output without the "nohpet" on the kernel command

line please ?
Thanks,

	tglx

--

Thomas - 
Attached is the output I believe you requested (standard boot - ommiting

the NOHPET directive)
Unless you want to try something else i will run in this configuration

today to try and verify that the problem is still with us.
Thanks for th good wishes - it is going to be a while - I had an open

heart procedure about two weeks ago and they are not subtle  when they

split your chest open.
This is why I said that I would be more than happy to do the bisect

thing if it comes to that - since I can't go out and chase the ladies I

might as well do something useful.
However, as previously stated I would need a little instruction on how

to accoomplish this.
Chris
By the way - the big gap in timestamps in the dmesg output is because

several "routine" fsck operations were performed during this boot cycle.
[    0.000000] Linux version 2.6.24-git15-ch2 (root@popeye) (gcc version

4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)) #3 SMP PREEMPT Thu

Feb 7 22:00:10 CST 2008

[    0.000000] BIOS-provided physical RAM map:

[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009f400 (usable)

[    0.000000]  BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved)

[    0.000000]  BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)

[    0.000000]  BIOS-e820: 0000000000100000 - 000000007fff0000 (usable)

[    0.000000]  BIOS-e820: 000000007fff0000 - 000000007fff3000 (ACPI NVS)

[    0.000000]  BIOS-e820: 000000007fff3000 - 0000000080000000 (ACPI data)

[    0.000000]  BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)

[    0.000000]  BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)

[    0.000000] 1151MB HIGHMEM available.

[    0.000000] 896MB LOWMEM available.

[    0.000000] Scan SMP from c0000000 for 1024 bytes.

[    0.000000] Scan SMP from c009fc00 for 1024 bytes.

[    0.000000] Scan SMP from c00f0000 for 65536 bytes.

[    0.000000] found SMP MP-table at [c00f5380] 000f5380

[    0.000000] Entering add_active_range(0, 0, 524272) 0 entries of 256...
[ message continues ]

Linus gave instructions here:
http://marc.info/?l=linux-kernel&m=118408208816556&w=2
Ok. That confirms, that we never even try to touch hpet at all. So the

mystery why "nohpet" on the kernel command line makes your problem go

away is yet more mysterious.
Thanks,

	tglx

--

Thomas - 
I have not see the problem with "repeating keys" for a while now - since

it was a "soft" failure I can not specify exactly which build was the

last I saw it on.
I am currently running 2.6.25-rc7-git2
If you have questions abount the configuration of my kernel my config

file is attached.
Thank you for your efforts on this issue.
Chris

Hi,
I think that this was one of the issues that were caused by

CONFIG_GROUP_SCHED, which were fixed a few weeks ago.
Still, the real issue is in Xorg, that their autorepeat code is very

unhappy when X process doesn't get scheduled often enough.
Thanks,
--

Jiri Kosina

SUSE Labs

--

Juri - 
I think that you are correct - and have one - small - piece of subtle

evidence to support that position.  
While it has been a while since I have seen the repeating key issue,

from time to time I have noted that there is a lag of a few seconds

between the keyboard and the screen.
There is no way an old man lke myself is out-typeing his hardware.  This

is on a lightly loaded, dual core system with a few gig of memory.
Thanks
Chris
--

Jiri - 
I have just started the build on the 2.6.24-git16 product and when it is

done I will come up with just the nohpet parameter - forgoing the

previouosly used taskset command.
Do you want me to do this using the git15 kernel I built yesterday, or

the new git16 kernel?
(I was not sure if you wanted me to introduce the variable of a new

kernel into the process while you are trying to diagnose the failure)
On the topic of doing a git bisect - I am recovering from heart surgery

last week and other than keeping up with the never ending stream of

email from the office, I am pretty much confined to the house - so I

have nothing but time on my hands.
However, I do my daily builds from the main tarball merged with the

daily git patch and don't have the infrustructure set up to do a git

bisect.  If you can point me to a "how to" on how to set up and use git

I am more than willing to give it a shot.
Chris
--

On Wed, 6 Feb 2008 14:54:21 +0100 (CET)
--