Bug 223561

try something: time with your watch how long a "sleep 30" takes

(In reply to comment #1)
> try something: time with your watch how long a "sleep 30" takes
> 

30 seconds.  
No fast clock symptoms seen on this machine, but then with ntpd running I wouldn't expect to notice it.

xset q outputs?

Any pointers where other users describe the problem?

And if you had a timer problem, you would notice even with ntp - the clock != timers.

See thread:
http://lists.opensuse.org/opensuse/2006-11/msg03716.html
-------------------------

xset q said this

Keyboard Control:
  auto repeat:  on    key click percent:  0    LED mask:  00000000
  auto repeat delay:  1224    repeat rate:  20
  auto repeating keys:  00ffffffdffffbbf
                        fadfffdfffdfe5ef
                        ffffffffffffffff
                        ffffffffffffffff
  bell percent:  50    bell pitch:  400    bell duration:  100
Pointer Control:
  acceleration:  20/10    threshold:  4
Screen Saver:
  prefer blanking:  no    allow exposures:  yes
  timeout:  250    cycle:  600
Colors:
  default colormap:  0x20    BlackPixel:  0    WhitePixel:  16777215
Font Path:
  /usr/X11R6/lib/X11/fonts/misc:unscaled,/usr/X11R6/lib/X11/fonts/75dpi:unscaled,/usr/X11R6/lib/X11/fonts/100dp          i:unscaled,/usr/X11R6/lib/X11/fonts/Type1,/usr/X11R6/lib/X11/fonts/URW,/usr/X11R6/lib/X11/fonts/cyrillic,/usr/X          11R6/lib/X11/fonts/baekmuk:unscaled,/usr/X11R6/lib/X11/fonts/japanese:unscaled,/usr/X11R6/lib/X11/fonts/truetyp          e,/usr/X11R6/lib/X11/fonts/uni:unscaled,/usr/X11R6/lib/X11/fonts/misc/sgi:unscaled,/opt/kde3/share/fonts
Bug Mode: compatibility mode is disabled
DPMS (Energy Star):
  Standby: 600    Suspend: 1200    Off: 1800
  DPMS is Enabled
  Monitor is On
File paths:
  Config file:  /etc/X11/xorg.conf
  Modules path: /usr/X11R6/lib64/modules/updates,/usr/X11R6/lib64/modules
  Log file:     /var/log/Xorg.0.log

ok, so KDE didn't set anything unusual. delay 1224 should be almost off :)

(In reply to comment #6)
> ok, so KDE didn't set anything unusual. delay 1224 should be almost off :)
> 

Yeah, but even WITH those settings, I typed xssssset qqq   ;-)

Even after setting the same values I cannot reproduce this problem.

# xset q
Keyboard Control:
  auto repeat:  on    key click percent:  0    LED mask:  00000002
  auto repeat delay:  1224    repeat rate:  20
  auto repeating keys:  00ffffffdffffbbf
                        fadfffdfffdfe5ef
                        ffffffffffffffff
                        ffffffffffffffff
  bell percent:  0    bell pitch:  400    bell duration:  100

Looks like a Race condition to me. 
Perhaps get someone from the kernel team into that?

I have the same issue whenever I re-boot my machine. it is caused by ntp adjtimex() adjusting the time too fast, which causes x to think it should do keyboard repeat events. 

its a generic kernel bug, and goes away after a while when the system time is in sync with the ntp source. 

No, it is not a ntp problem, and your suggestion doesn't even explain half the situations documented above.

My tests were with the machine running for several hours.  NTP would have been synced long before then.

My tests CLEARLY indicated this key duplicating does not occur when dual processor is turned off.  It did not happen with other distros: I tested Kubuntu 601, 610, and Mepis.  It does not happen in run level 3.

I performed further tests:  I booted up for the day, and immediately shut down ntpd.  The problem persisted.  

Just how generic could this kernel bug be when it does not occur on 10.0 but does on 10.1?

(In reply to comment #9)
> Looks like a Race condition to me. 
> Perhaps get someone from the kernel team into that?
> 

If I knew exactly which process is responsible for KDE keyboard input, perhaps I could set affinity for that pid, since this does not occur when smp is suppressed via the bios.  
Any clues as to what handles this function?

Reassigning to the kernel team.

I can verify exactly the same behaviour as John is reporting.  I'm running an
AMD X2 3800+ with the SUSE 10.1 SMP 32 bit kernel.  When I install any kernel
(provided by official SUSE updates) that is newer than the one provided on the
SUSE 10.1 DVD, I get keyboard repeats in KDE.  I've also experimented with
disabling ntp.  The problem persists for hours - basically until I reinstall
and boot the original kernel from the SUSE 10.1 DVD.

It is also worth noting that I run several other distributions on this same
machine (Xandros, (K)Ubuntu 6.10 etc) and theya re all able to run kernels
based on newer sources and do not exhibit this keyboard repeat behaviour.

I have this same issue on 3 AMD based systems all with i386 installs.  2 AMD64 X2 4200+ chips and one AMD Opteron 2212 (all 3 chips are dual core).

I am running GNOME.

I have tried both PS/2 and USB keyboards.

I do not have NTP configured on any of the systems.

Does this happen on the 10.2 RC releases?

>Does this happen on the 10.2 RC releases?

Unfortunately, I was unable to get a successful install of 10.2 due to unavailability of ATI drivers for that version of Xorg.  (X.Org 7.2rc2)
Best I could get was 1024x768, so I decided to hold off on 10.2 until 
ATI ex-digitates.

If there were a liveCD torrent of 10.2 available I'd be game to test it even
without ATI drivers.

Additional point of interest, perhaps unrelated....

Even with keyboard autorepeat turned off in KDE, I was seeing massive auto-repeat in Vmware virtual machines.  To the point of being unusable.

By watching top, I found that the repeats happened in conjunction with vmware or vmware-vmx being migrated to the opposite processor.

I found that by restraining vmware and its children to one processor solved the problem completely in Vmware:   taskset 0x00000001 /usr/bin/vmware 

I wonder if the duplication in KDE occurs in conjunction with one or more processes migrating from one cpu to the other?  Which ones? 

let me clarify the situation a little: There is nothing in KDE that does anything with keyboard repeat. the false keyboard repeat events come from Xorg, which does the keyboard repeat simulation. you can clearly see that with e.g. "xev". 

The problem is caused whenever , from the view of the Xorg process, the system time goes backwards. This usually happens when either adjtimex() is in effect (there seems to be a genuine kernel bug that causes time to jump around randomly when adjtimex is in effect) or when processes are migrated between cpu's of a hyperthreading or smp cpu. This could be because the time is slightly different between the two cpu's. 

In any case, this is a kernel bug that can be triggered for example by acpi changes (ACPI is known to hang the kernel time for unusually long intervals). 

if you can not reproduce it between the original 10.1 kernel but reproduce it with a later 10.1 kernel, then diffing the rpm -q --changelog might help to track down which patch causes the problem for you. 

I have the issue as well, it is reproduceable with any kernel older than 10.1, but it usually goes away after a while. But as I'm forced to run the NVIDIA binary driver I can not report the bug. 

>The problem is caused whenever , from the view of the Xorg process, the
>system time goes backwards.

But that does not explain why so do many of the reports indicate this duplication does not happen in other desktop systems (not running kde, and not running kde apps) under say, twm?

Would it be instructive if I booted to runlevel 3 and hacked a way to start X with CPU affinity? 

>if you can not reproduce it between the original 10.1 kernel but reproduce it
>with a later 10.1 kernel, then diffing the rpm -q --changelog might help to
>track down which patch causes the problem for you. 

>I have the issue as well, it is reproduceable with any kernel older than
> 10.1,

Actually, I believe all the reports state that 10.1 first kernel is the beginning of the problem, and nobody reports this in 10.0, and nobody reports it in any other distro.

> I have the issue as well, it is reproduceable with any kernel older than
> 10.1,but it usually goes away after a while. But as I'm forced to run the
> NVIDIA binary driver I can not report the bug. 

In my case, and many of the other reports it is not reproduceable on anthing but 10.1, and it never goes away.  (Well, not true, I experience brief periods of non-duplicating characters, intermingled with totally unusable duplication, but this does not "go away after a while".)

Unsolicited pontification: 
As for being forced to run Nvidia blobs, I would like to point out that market statistics indicate that Nvidia accounts for 25% of the video chipset market, ATI accounts for another 25%, and Intel, (also non-open source) about 30% of the low end market.  One can quickly see that declining bug reports from 50 to 80% of the market is not good.  Especially when your distro is the only one reporting these problems.

does it go away after a "dcop kded kded unloadModule kmilod" ? I don't say that it is not triggered by a KDE environment, I only say that it can not be KDE's fault, as it doesn't do anything with keyboard repeat. 

There are actually reports about this problem from other distributions as well. 

>does it go away after a "dcop kded kded unloadModule kmilod"

No, I got duplication of the enter key on that command, and the next command typed.  (It spit back the word "true".

However something you said 
  "The problem is caused whenever , from the view of the Xorg process, the
   system time goes backwards."
piqued my interest and tried to get the machine loaded up a bit (which is hard, because I don't have a lot on it till I get this problem solved) innn  order to ggggeeeeet the xorg process bouncing frommm cpu to cpu.
    (drat, there it goes again)


Then I looked up the pid of X and issued this command in a shell as root:
  taskset -p 0x00000002  3565      (3565 is X pid)

That stopped all unwanted key repeats.  Just to be cautious, I switched it back to 0x00000003 and so on back and forth a few times.  In each case, I saw NO DUPLICATION while X was limited to a single cpu, and a re-occurance of duplication as soon as I set the process free to run on any CPU.

While this is not an ideal way to operate, its provides one possible  workaround. 

So is it a kernel bug, or an Xorg bug?

assuming that it is the same problem I have, the jumping system time bug, it is a kernel bug. 

I just installed Suse 10.1 plus updates on my Dell 820 Duo 2.  I not only see the key repeat problem, but mouse events seem to be getting lost and/or delayed.  For example, when use the mouse to scroll, the scrolling is often delayed.  Sometimes I have to click several times in order to get a mouse click to take effect.

The severity of both problems have varied quite a bit, from unusable to more or less tolerable.

After significant frustation, I turned off dual headed mod in the bios.  After that, both problems went away.

So this looks like an smp problem.  I suspect that the keyboard and mouse problems, though seemingly separate, both result from not handling multiple processors correctly.  Could something be getting built as single-processor code?

Correction:  I mean of course dual core (2 cpus) and not dual head (2 screens).

One more note.  My Dell D600 (single CPU), also running Suse 10.1, doesn't show either problem.  I only started seeing this after upgrading to a D820 (x86_64 dual core 2).

I have an athlon x2 4400+ and it was exhibiting this same problem.  I ran taskset to set the affinity of X to a single CPU, and that fixed it for me.  Running 10.1 and nvidia proprietary drivers, plus lots of updates, kernel version 2.6.16.21-0.25-smp.  I did confirm it had the same behaviour even with initlevel 3.  Took me forever to track down the solution to this annoying problem, and its still just a hack (manually setting X affinity).  I am a new linux user.

I have the problem, but it is not limited to KDE applications since I run Gnome.  In fact, I do not use KDE.  Athlon64 x2 running 10.1 as i386.  Keyboard repeat is very annoying.  It occurs in all applications that I have tested, including Firefox, gnome-terminal, and scientific software that I use.

Taking John Andrson's suggestion, I tried the taskset command and the repeats have stopped.  Will this have any negative consequences?  From everything I have read, it looks like only dual core/cpu systems or those with hyperthreading are affected.

I suggest the title of the thread/bug should be altered to reflect that the probelm is not limited to KDE.

> From everything I have read, it looks like only dual core/cpu systems or
> those with hyperthreading are affected.

I've only seen this in dual core or dual CPU machines of x86_64 arch.  It does not show up on my 10.1 Dual 32bit Celeron machine.

I've never seen duplication at runlevel 3 or in a console (such as ctrl-alt-f3).  Only in X applications of one sort or another, and,
interestingly, not in OpenOffice Writer.  Go Figure.

(In reply to comment #16)
> Does this happen on the 10.2 RC releases?
> 

No.  At least not for me.

I have upgraded to 10.2, fresh install, on the same hardware where this bug was first reported and I am not seeing this problem at all.

*** Bug 231422 has been marked as a duplicate of this bug. ***

I also have this problem on my workstation boltzmann.suse.de here in the office.

Kernel: 2.6.18.2-34-default

Processor:
vendor_id       : GenuineIntel
cpu family      : 15
model           : 3
model name      : Genuine Intel(R) CPU 2.80GHz

I already tried to bind the X server to one CPU but that didn't help. Also switching off xntpd didn't help (these both dmueller suggested in irc).

For me these ugly multiple characters not only happen for a while after booting. My machine is now up for 4 days and it still happens.

Ok, I have same problemmmmmmmmmmmmmmmmm running on a new maccccccchine.. I have am                       runnnnnnng a semperon 2800+ on a new Gigabyte MB.  I get regular raaaaaaaapid repeats all the time.  Here is the kicker... I get it on just a console install as  wwwwwwwell as any GUI innnnnnnnnnnnstallation of 10.2.  It              also did the same tttttttttttttttttttttthing with Ubuntu 7.04 alpha 4, as well as Ubuntu 6.10.  The repeat is very predictabllllllle.  It seems as though it is a clock issue of sssssssssssssssssssome kind. The interval between bursts is nearly ccccconstant.  There is also a slighhhhhhhhhhhhhhhhhht pause juuuuuuust before the burst.  I don't think it has anything to do with the GUIs... more likely something to do with timing int he kernel.  I will putz around with it and see what I can find.

-Josh Murphy
Computer Science PhD Student
University of Maine

(In reply to comment #33)
> Ok, I have same problemmmmmmmmmmmmmmmmm running on a new maccccccchine.. I have
> am                       runnnnnnng a semperon 2800+ on a new Gigabyte MB.  I
> get regular raaaaaaaapid repeats all the time.  Here is the kicker... I get it
> on just a console install as  wwwwwwwell as any GUI innnnnnnnnnnnstallation of
> 10.2.  It              also did the same tttttttttttttttttttttthing with Ubuntu
> 7.04 alpha 4, as well as Ubuntu 6.10.  The repeat is very predictabllllllle. 
> It seems as though it is a clock issue of sssssssssssssssssssome kind. The
> interval between bursts is nearly ccccconstant.  There is also a
> slighhhhhhhhhhhhhhhhhht pause juuuuuuust before the burst.  I don't think it
> has anything to do with the GUIs... more likely something to do with timing int
> he kernel.  I will putz around with it and see what I can find.
> 
> -Josh Murphy
> Computer Science PhD Student
> University of Maine
> 

I should add that, of the 10 machines I am running, I only have a problem on thisssssss one. (the others are all intel Pentium D dual core, Q965 chipset) The 
nVidia chipset Single core semperon is the only one showing the problem. (will post back with exact chipset later)

Does this still happen in 10.2?

If yes please post /var/log/boot.msg

As I posted in #30, this was solved in 10.2 for me on Core 2 Duo processor x86_64.

For those still experiencing this you might try this kernel boot parameter:
  nohpet   (if running x86_64)
  npet=disable  (if running anything else).

I'm leaving this in Info Needed state, because I can't answer for everyone who reported on this thread.  

Can you post the boot.msg without nohpet of 10.2?

I have tracked down the problem on my machine to a USB problem... the USB subsystem keeps erroring out and resetting.  The repeat in characters coincides with this. (it is a USB keyboard).  I am no longer certain this is a bug in 10.2... it may be a hardware failure.  I will keep you posted.

Sorry Joshua, but I doubt that is the problem.  The keyboard repeat problem occurs on non-USB keyboards too.

I had enough of this issue and upgraded to 10.2.  No problems so far.

Responding to #37
It would not be a useful exercise. 
Keyboard repeat disappeared as soon as I installed 10.2.

I suggested the hpet switch just because it solved other problems
for me (vmware lockups) and since this keyboard issue is timer 
related it was a cheap and easy suggestion to test.

I assume this is fixed according to comment #40.

same story with 11.0 beta1

Not sure why this one has been reassigned to X.Org component. It has been assigned against Kernel component before. So as long as nobody explains to me why this is out of a sudden became a X.Org issue I'm reassigning this back to the Kernel.

it is only a problem when using X - console keyboard repeat is not affected

This doesn't necessarily mean that the problem is caused by X.Org itself.

it is not KDE specific at least :)

And it's not kernel specific either.

As it can't be duplicated, except under X, I'm saying it's not a kernel issue, unless it can be proven otherwise :)

It's a bug in our SMP kernel. See comment #14 by Clayton. Others confirmed it.

Comment #6 was from 2006, a while ago :)

I'd like to think that if this was a common problem in the kernel than more than one user over the past 2 years would have seen it in the kernel.

It's also been noted that upgrading to 10.2 solved the issue here, yet someone else (Dirk) said the issue is happening in 11.0 beta 1.

As it's not anything that anyone on the kernel team can reproduce, I shall just mark this UNREPRODUCIBLE.  If anyone can reproduce this on 11.0 Beta2 or newer, please reopen.

And if they can reproduce it, can someone get one of the machines with the problem to someone on the kernel team (Dirk?)