LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Software (https://www.linuxquestions.org/questions/linux-software-2/)
-   -   Problem after enabling SMP on dual core amd64 (https://www.linuxquestions.org/questions/linux-software-2/problem-after-enabling-smp-on-dual-core-amd64-359430/)

walmartshopper 09-02-2005 04:47 AM

Problem after enabling SMP on dual core amd64
 
I recently upgraded from an athlon64 3500+ to a dual core 3800+. I'm running my own custom 2.6.11.12 kernel. Everything worked fine after the switch. Then I recompiled my kernel with the same config, but with SMP support turned on. After installing it and rebooting, I started having problems. Every time the CPU was used, everything would pause for about half a second. For example, if i was playing music and then grabbed a window and moved it, the music would keep pausing until I let go of the window. And my keyboard input got screwed up too. Every time I pressed a letter on the keyboard, it would print the letter 5 or 6 times. But this only happened when the CPU was being used by another process. Everything else seemed to work ok. So the problem has something to do with enabling SMP support on a dual core athlon64. I'm wondering if there are some other kernel options that I should enable or disable that might be causing this. I have Preemptible Kernel turned on and also Preempt The Big Kernel Lock. I'll try the 2.6.13 kernel and maybe try turning off preemption... Any other ideas on what might be causing the pausing?

edit: after running the smp kernel again, the problem seems to be that the system clock is speeding way up. The gkrellm graphs move a lot faster, and the keyboard repeat rate increases to the point where a quick tap on the keyboard prints the letter 3 times. The cursor also flashes very quickly. BTW... i dual boot, and it doesn't happen on windoze.

Thanks.

nomind 09-02-2005 10:59 PM

A few proposed solutions:

1) Upgrade to a bleeding-edge kernel and keep system utilities (e.x. pci-utils) updated.
2) Try various combos of HPET, HPET_TIMER, HPET_EMULATE_RTC, X86_MCE, X86_PM_TIMER, and RTC options in the kernel.
3) Passing some or all of these options to the kernel at boot:
no_timer_check (most important)
pci=biosirq
pci=noacpi
pci=irqroute
clock=pmtmr
notsc
noapic
noapictimer

Enjoy

P.S: I myself don't own an amd64 (one can wish though :p ), and your proc is __SICK__!

walmartshopper 09-04-2005 04:03 PM

Thanks for the reply! I got the problem fixed. Although the above solutions did not work, you pointed me in the right direction. I needed the Athlon64 powernow driver, which is available from http://amd.com. This driver is also built into the kernel starting with the recent 2.6.13. I was already running 2.6.13, so I just recompiled it with the powernow driver and left the HPET and RTC stuff enabled. It's worked perfectly ever since. Now it's running 2 instances of glxgears at 3200fps each :)

larslynch 09-26-2005 11:56 AM

Adding the kernel option: clock=pmtmr to my GRUB conf fixed a similar problem with the following setup:

NVidia Geforce4 MX4000
MSI K8T-Neo2-F V2.0 (bios revision 3.2)
Athlon64 X2 3800+

With smp kernel 2.6.11.7 and nvidia driver version 1.0-7667, anytime I used multiple xv overlay ports(mplayer -vo xv) in XWindows, the windows would get all confused and mix the video.

A tail of the /var/log/Xorg.0.log would show a ton of the following warnings from the NVIDIA kernel module:
(WW) NVIDIA(0): WAIT (0, 6, 0x8000, 0x00004818, 0x00004818, 0)

This post:
http://www.uwsg.iu.edu/hypermail/lin...03.3/0834.html

sheds some light on the difference between the three timers available in linux: clock=pit, clock=tsc, and clock=pmtmr

Using the pit or pmtmr timers fixes my problem, though getting the time is a bit more computationally expensive. So something about SMP and the tsc timer mixes up the clock.


All times are GMT -5. The time now is 04:13 AM.