Kernel Bug Tracker – Bug 6104
repeated characters from keypress with AMD64 and SMP kernel
Last modified: 2006-02-21 03:02:51 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
Hardware Environment: athlon64 X2
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
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.
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?
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
notsc: Kernel compiled with CONFIG_X86_TSC, cannot disable TSC.
mapped APIC to ffffd000 (fee00000)
mapped IOAPIC to ffffc000 (fec00000)
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.
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?
It appears you're running a 32bit i386-arch kernel, is that correct?
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.
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.
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:
If that's not usable, I have to collect some info first of how to make
Could you ensure that CONFIG_X86_PM_TIMER is enabled in your config?
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)
>> 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.
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.
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
You have ACPI already enabled.
I don't have rights to close the bug, but someone should set it to INVALID