Bug 6104 - repeated characters from keypress with AMD64 and SMP kernel
repeated characters from keypress with AMD64 and SMP kernel
Status: REJECTED INVALID
Product: Timers
Classification: Unclassified
Component: Interval Timers
i386 Linux
: P2 normal
Assigned To: timers_interval-timers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-19 09:35 UTC by widu wittekindt
Modified: 2006-02-21 03:02 UTC (History)
4 users (show)

See Also:
Kernel Version: 2.6.16-rc4
Tree: Mainline
Regression: ---


Attachments

Description widu wittekindt 2006-02-19 09:35:01 UTC
Most recent kernel where this bug did not occur: None. I've tested 2.6.14,
2.6.15 and 2.6.16-rc3 and 2.6.16-rc4
Distribution: gentoo
Hardware Environment: athlon64 X2 
Software Environment:x-windows
Problem Description: 
If I run the SMP kernel,
then I get repeated characters under X from (single) keypresses. running non-smp
kernel solves the problem. I could also solve the problem by running a
smp-kernel and booting with the additional parameters clock=pmtmr notsc. I'm
only having this problem under X it never occured on a VT
Steps to reproduce:
1. boot without additional parameters
2. startx
3. type
Comment 1 Daniel Drake 2006-02-20 02:52:42 UTC
Original downstream report is at http://bugs.gentoo.org/120362

A workaround is known (clock=pmtmr notsc), so if this is one of those things
that just can't be fixed by default please close this bug.

However, it would obviously be nice if this could work out of the box.
Comment 2 Andi Kleen 2006-02-20 03:08:15 UTC
clock=pmtmr doesn't exist on the 64bit kernel and notsc should
be automatically selected on the X2. Please give full boot log
without any options.

It was broken on the -mm* kernels, but linus kernels should be 
ok. Can you double check you're not using an -mm* kernel?
Comment 3 Daniel Drake 2006-02-20 04:26:35 UTC
Andi,

It's not a complete log and it is not from a boot with no added parameters, but
maybe this helps (taken from downstream bug):

Kernel command line: ro root=/dev/sda6 video=vesafb:mtrr,ywrap,1024x768-32@85
clock=pmtmr notsc
notsc: Kernel compiled with CONFIG_X86_TSC, cannot disable TSC.
mapped APIC to ffffd000 (fee00000)
mapped IOAPIC to ffffc000 (fec00000)
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 65536 bytes)
Warning: clock= override failed. Defaulting to PIT
Detected 2010.493 MHz processor.
Using pit for high-res timesource

It looks like you are correct in saying that notsc has no effect and pmtmr is
not available -- however it looks like the invalid "clock=" argument is causing
the kernel to fall back on PIT, maybe it defaults to some other source when no
argument is given?

Widu, please attach a "dmesg" log from a 2.6.16-rc4 boot with no additional
parameters when convenient.
Comment 4 Andi Kleen 2006-02-20 04:47:52 UTC
No i need the full log without any options (clock=.... notsc)
The point is to find out why notsc isn't used by default on this
machine as it should.

Also can you confirm this is really a vanilla linus kernel without 
any additional patches?
Comment 5 john stultz 2006-02-20 10:23:34 UTC
It appears you're running a 32bit i386-arch kernel, is that correct?  
 
Comment 6 Andi Kleen 2006-02-20 10:58:42 UTC
Yes john is right. Sorry my earlier comments only applied to 64bit kernels
(which should do this correctly)

But it looks like 32bit needs fixing.
Comment 7 widu wittekindt 2006-02-20 11:08:37 UTC
hi,
sorry for being late with additional information, but the machine serves as a
ltsp-server in our workshop, so I don't "play around" with it during daytime.
so:
yes the kernel (2.6.16-rc4) is pure vanilla without any patches.
and yes I'm running a 32bit i386-arch kernel.
because bootloging doesn't work right on that machine, I can only provide you
the full output of dmesg, directly after reboot without any additional kernel
parameters. And because that's a bit long, I did put it here:
http://www.radgeber-freiburg.de/widu/dmesg.log
If that's not usable, I have to collect some info first of how to make
bootlogging work.
Comment 8 john stultz 2006-02-20 11:15:48 UTC
Could you ensure that CONFIG_X86_PM_TIMER is enabled in your config? 
Comment 9 Andi Kleen 2006-02-20 11:18:52 UTC
Are you sure you have CONFIG_X86_PM_TIMER enabled?

It doesn't look like it from the boot log. 

I took a look at the 32bit code
and it should definitely try the pmtmr before the tsc timer (that's a bit
inefficient, but should have correct results)
Comment 10 widu wittekindt 2006-02-20 11:28:43 UTC
>> Could you ensure that CONFIG_X86_PM_TIMER is enabled in your config?
no, indeed its not set. Should it be set?, If so I could recompile the kernel,
but could test it only tomorrow, cause I only have ssh acces for now. 

Comment 11 Andi Kleen 2006-02-20 11:45:25 UTC
Yes it should.

Also your clock=pmtmr thing couldn't have possibly worked. Most
likely you fell back to PIT timer because of the notsc.

John - in the 64bit kernel i made it an CONFIG_EMBEDDED option. 
would be probably a good idea for 32bit too. Can you perhaps
send akpm a patch for that for 2.6.16?
The only people left in the rain would be those that compile without
CONFIG_ACPI then, but these tend to be real oddballs.
Comment 12 widu wittekindt 2006-02-21 00:03:13 UTC
now I enabled CONFIG_X86_PM_TIMER and it seems to work. Since the machine is a
desktop system I didn't care much about acpi, and there's nothing in the help
text, that tells me I should enable it if I'm building an SMP kernel. maybe you
could add something like that.
thanks a lot for your help
widu
Comment 13 Andi Kleen 2006-02-21 02:59:38 UTC
You have ACPI already enabled.

I don't have rights to close the bug,  but someone should set it to INVALID
Comment 14 Daniel Drake 2006-02-21 03:02:51 UTC
Thanks.

Note You need to log in before you can comment on or make changes to this bug.