"TLB parity error in virtual array; TLB error 'instruction"?

Ant wrote in part:
On 3/12/2010 11:14 PM PT, Ant typed:
Wait a minute.
# dpkg -l | grep ^ii |grep cpu
ii cpufrequtils 006-2 utilities to deal with the cpufreq Linux kernel
feature
ii cpulimit 1.1-13 tool for limiting the CPU usage of a process
ii libcpufreq0 006-2 shared library to deal with the cpufreq Linux
kernel fe

I don't think I am supposed to have these even though I disabled
cool'n'quiet and don't have powernow module. I will try removing them
and see if I still have problems.

Also:

# lsmod |grep cpu
cpufreq_powersave 602 0
cpufreq_userspace 1444 0
cpufreq_stats 1940 0
cpufreq_conservative 4018 0
xt_tcpudp 1743 92
x_tables 8335 6
xt_tcpudp,xt_limit,xt_state,ipt_LOG,ipt_REJECT,ip_ tables

Not sure if those are bad or not if I don't use AMD's Cool'n'Quiet and .


IIRC, there are some errata out on AMD CnQ.

I wouldn't worry too much about lib* and other userspace tools.
OTOH, I would rmmod cpufreq* because they get loaded in kernel space.

Although perhaps justified for laptop battery dispair, I'm skeptical of
CPU frequency savings. Idle at HLT ought to be enough, and base leakage
is more significant. This business of clocks eating 10% of power might
apply at HLT, but looks like poor design if true at full load.


-- Robert

On 3/13/2010 7:32 AM PT, Yousuf Khan typed:

No, the TLB is inside the processor, not in RAM. It's part of the
processor's caching system. So if there was a Memtest equivalent for the
caching system, then this is the sort of test that would probably catch
it. Though the caching system caches your RAM, they are not directly
related otherwise. A problem with your RAM will not result in a problem
with your cache, or vice-versa.

If you look at the functional hierarchy in a system, it usually goes
like this: Core - Cache - Memory Controller - RAM. So as you can see,
the cache is sitting two levels up from the RAM. These days, everything
from the Core to the Memory Controller sits inside the processor, and
RAM remains outside. In the olden days, even the Memory Controller was
outside the processor, it used to be part of the chipset.

Basically, it's not a problem with your memory, it's problem with your
processor. At what point will you just simply decide to replace the
processor? I'm sure you can get a Socket 939 Athlon X2 relatively cheap
these days used.

Ah! Now if I could find a way to test the processor in my old Debian OS
and outside (KNOPPIX v6.2.1 LiveCD and memtest86+ boot disk). However, I
have not been able to reproduce the problems except wait and mostly idle
in my old Debian. I even wonder if my old Debian is causing it. Hence,
why I researched my Cool'n'Quiet stuff which appear to be disabled and
not in used.

Actually, I did look at their prices recently and they're not cheap.
--
"I got this aunt... Carpenter ant." --Girl and Crow
/\___/\
/ /\ /\ \ Phil./Ant @ http://antfarm.ma.cx (Personal Web Site)
| |o o| | Ant's Quality Foraged Links: http://aqfl.net
\ _ / Nuke ANT from e-mail address: NT
( ) or
Ant is currently not listening to any songs on his home computer.

On 3/13/2010 8:32 AM PT, Robert Redelmeier typed:

# dpkg -l | grep ^ii |grep cpu
ii cpufrequtils 006-2 utilities to deal with the cpufreq Linux kernel
feature
ii cpulimit 1.1-13 tool for limiting the CPU usage of a process
ii libcpufreq0 006-2 shared library to deal with the cpufreq Linux
kernel fe

I don't think I am supposed to have these even though I disabled
cool'n'quiet and don't have powernow module. I will try removing them
and see if I still have problems.

Also:

# lsmod |grep cpu
cpufreq_powersave 602 0
cpufreq_userspace 1444 0
cpufreq_stats 1940 0
cpufreq_conservative 4018 0
xt_tcpudp 1743 92
x_tables 8335 6
xt_tcpudp,xt_limit,xt_state,ipt_LOG,ipt_REJECT,ip_ tables

Not sure if those are bad or not if I don't use AMD's Cool'n'Quiet and .

IIRC, there are some errata out on AMD CnQ.

I think it is currently disabled especially CMOS, so they shouldn't even
been in used, right?


I wouldn't worry too much about lib* and other userspace tools.
OTOH, I would rmmod cpufreq* because they get loaded in kernel space.

Delete all these including in Kernels?
$ locate cpufreq
/etc/cpufreqd.conf
/etc/default/cpufreqd
/etc/init.d/cpufreqd
/etc/init.d/cpufrequtils
/etc/init.d/loadcpufreq
/etc/rc0.d/K20cpufreqd
/etc/rc1.d/K20cpufreqd
/etc/rc2.d/S05loadcpufreq
/etc/rc2.d/S19cpufrequtils
/etc/rc2.d/S20cpufreqd
/etc/rc3.d/S05loadcpufreq
/etc/rc3.d/S19cpufrequtils
/etc/rc3.d/S20cpufreqd
/etc/rc4.d/S05loadcpufreq
/etc/rc4.d/S19cpufrequtils
/etc/rc4.d/S20cpufreqd
/etc/rc5.d/S05loadcpufreq
/etc/rc5.d/S19cpufrequtils
/etc/rc5.d/S20cpufreqd
/etc/rc6.d/K20cpufreqd
/lib/modules/2.6.30-2-686/kernel/arch/x86/kernel/cpu/cpufreq
/lib/modules/2.6.30-2-686/kernel/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.ko
/lib/modules/2.6.30-2-686/kernel/arch/x86/kernel/cpu/cpufreq/cpufreq-nforce2.ko
/lib/modules/2.6.30-2-686/kernel/arch/x86/kernel/cpu/cpufreq/e_powersaver.ko
/lib/modules/2.6.30-2-686/kernel/arch/x86/kernel/cpu/cpufreq/gx-suspmod.ko
/lib/modules/2.6.30-2-686/kernel/arch/x86/kernel/cpu/cpufreq/longhaul.ko
/lib/modules/2.6.30-2-686/kernel/arch/x86/kernel/cpu/cpufreq/longrun.ko
/lib/modules/2.6.30-2-686/kernel/arch/x86/kernel/cpu/cpufreq/p4-clockmod.ko
/lib/modules/2.6.30-2-686/kernel/arch/x86/kernel/cpu/cpufreq/powernow-k6.ko
/lib/modules/2.6.30-2-686/kernel/arch/x86/kernel/cpu/cpufreq/powernow-k7.ko
/lib/modules/2.6.30-2-686/kernel/arch/x86/kernel/cpu/cpufreq/powernow-k8.ko
/lib/modules/2.6.30-2-686/kernel/arch/x86/kernel/cpu/cpufreq/speedstep-centrino.ko
/lib/modules/2.6.30-2-686/kernel/arch/x86/kernel/cpu/cpufreq/speedstep-ich.ko
/lib/modules/2.6.30-2-686/kernel/arch/x86/kernel/cpu/cpufreq/speedstep-lib.ko
/lib/modules/2.6.30-2-686/kernel/arch/x86/kernel/cpu/cpufreq/speedstep-smi.ko
/lib/modules/2.6.30-2-686/kernel/drivers/cpufreq
/lib/modules/2.6.30-2-686/kernel/drivers/cpufreq/cpufreq_conservative.ko
/lib/modules/2.6.30-2-686/kernel/drivers/cpufreq/cpufreq_powersave.ko
/lib/modules/2.6.30-2-686/kernel/drivers/cpufreq/cpufreq_stats.ko
/lib/modules/2.6.30-2-686/kernel/drivers/cpufreq/cpufreq_userspace.ko
/lib/modules/2.6.32-trunk-686/kernel/arch/x86/kernel/cpu/cpufreq
/lib/modules/2.6.32-trunk-686/kernel/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.ko
/lib/modules/2.6.32-trunk-686/kernel/arch/x86/kernel/cpu/cpufreq/cpufreq-nforce2.ko
/lib/modules/2.6.32-trunk-686/kernel/arch/x86/kernel/cpu/cpufreq/e_powersaver.ko
/lib/modules/2.6.32-trunk-686/kernel/arch/x86/kernel/cpu/cpufreq/gx-suspmod.ko
/lib/modules/2.6.32-trunk-686/kernel/arch/x86/kernel/cpu/cpufreq/longhaul.ko
/lib/modules/2.6.32-trunk-686/kernel/arch/x86/kernel/cpu/cpufreq/longrun.ko
/lib/modules/2.6.32-trunk-686/kernel/arch/x86/kernel/cpu/cpufreq/p4-clockmod.ko
/lib/modules/2.6.32-trunk-686/kernel/arch/x86/kernel/cpu/cpufreq/powernow-k6.ko
/lib/modules/2.6.32-trunk-686/kernel/arch/x86/kernel/cpu/cpufreq/powernow-k7.ko
/lib/modules/2.6.32-trunk-686/kernel/arch/x86/kernel/cpu/cpufreq/powernow-k8.ko
/lib/modules/2.6.32-trunk-686/kernel/arch/x86/kernel/cpu/cpufreq/speedstep-centrino.ko
/lib/modules/2.6.32-trunk-686/kernel/arch/x86/kernel/cpu/cpufreq/speedstep-ich.ko
/lib/modules/2.6.32-trunk-686/kernel/arch/x86/kernel/cpu/cpufreq/speedstep-lib.ko
/lib/modules/2.6.32-trunk-686/kernel/arch/x86/kernel/cpu/cpufreq/speedstep-smi.ko
/lib/modules/2.6.32-trunk-686/kernel/drivers/cpufreq
/lib/modules/2.6.32-trunk-686/kernel/drivers/cpufreq/cpufreq_conservative.ko
/lib/modules/2.6.32-trunk-686/kernel/drivers/cpufreq/cpufreq_powersave.ko
/lib/modules/2.6.32-trunk-686/kernel/drivers/cpufreq/cpufreq_stats.ko
/lib/modules/2.6.32-trunk-686/kernel/drivers/cpufreq/cpufreq_userspace.ko
/usr/bin/cpufreq-selector
/usr/lib/libcpufreq.so.0
/usr/lib/libcpufreq.so.0.0.0
/usr/lib/gnome-applets/cpufreq-applet
/usr/lib/hal/hald-addon-cpufreq
/usr/lib/pm-utils/sleep.d/94cpufreq
/usr/share/doc/libcpufreq0
/usr/share/doc/libcpufreq0/changelog.Debian.gz
/usr/share/doc/libcpufreq0/copyright
/usr/share/dstat/dstat_cpufreq.py
/usr/share/dstat/dstat_cpufreq.pyc
/usr/share/gconf/schemas/cpufreq-applet.schemas
/usr/share/gnome/help/cpufreq-applet
/usr/share/gnome/help/cpufreq-applet/C
/usr/share/gnome/help/cpufreq-applet/en_GB
/usr/share/gnome/help/cpufreq-applet/C/cpufreq-applet.xml
/usr/share/gnome/help/cpufreq-applet/C/figures
/usr/share/gnome/help/cpufreq-applet/C/legal.xml
/usr/share/gnome/help/cpufreq-applet/C/figures/cpufreq-100.png
/usr/share/gnome/help/cpufreq-applet/C/figures/cpufreq-25.png
/usr/share/gnome/help/cpufreq-applet/C/figures/cpufreq-50.png
/usr/share/gnome/help/cpufreq-applet/C/figures/cpufreq-75.png
/usr/share/gnome/help/cpufreq-applet/C/figures/cpufreq-applet-preferences-smp.png
/usr/share/gnome/help/cpufreq-applet/C/figures/cpufreq-applet-preferences.png
/usr/share/gnome/help/cpufreq-applet/C/figures/cpufreq-applet-selector-both.png
/usr/share/gnome/help/cpufreq-applet/C/figures/cpufreq-applet-selector.png
/usr/share/gnome/help/cpufreq-applet/C/figures/cpufreq-applet.png
/usr/share/gnome/help/cpufreq-applet/en_GB/figures
/usr/share/gnome-applets/builder/cpufreq-preferences.ui
/usr/share/hal/fdi/policy/10osvendor/10-cpufreq.fdi
/usr/share/man/man1/cpufreq-selector.1.gz
/usr/share/omf/cpufreq-applet
/usr/share/omf/cpufreq-applet/cpufreq-applet-C.omf
/usr/share/pixmaps/cpufreq-applet
/usr/share/pixmaps/cpufreq-applet/cpufreq-100.png
/usr/share/pixmaps/cpufreq-applet/cpufreq-25.png
/usr/share/pixmaps/cpufreq-applet/cpufreq-50.png
/usr/share/pixmaps/cpufreq-applet/cpufreq-75.png
/usr/share/pixmaps/cpufreq-applet/cpufreq-na.png
/usr/share/polkit-1/actions/org.gnome.cpufreqselector.policy
/usr/src/linux-headers-2.6.30-2-686/include/config/x86/cpufreq
/usr/src/linux-headers-2.6.30-2-686/include/config/x86/acpi/cpufreq.h
/usr/src/linux-headers-2.6.30-2-686/include/config/x86/cpufreq/nforce2.h
/usr/src/linux-headers-2.6.30-2-common/include/linux/cpufreq.h
/usr/src/linux-headers-2.6.32-trunk-686/include/config/x86/cpufreq
/usr/src/linux-headers-2.6.32-trunk-686/include/config/x86/acpi/cpufreq.h
/usr/src/linux-headers-2.6.32-trunk-686/include/config/x86/cpufreq/nforce2.h
/usr/src/linux-headers-2.6.32-trunk-common/include/linux/cpufreq.h
/var/lib/dpkg/info/cpufreqd.list
/var/lib/dpkg/info/cpufreqd.postrm
/var/lib/dpkg/info/cpufrequtils.list
/var/lib/dpkg/info/cpufrequtils.postrm
/var/lib/dpkg/info/libcpufreq0.list
/var/lib/dpkg/info/libcpufreq0.md5sums
/var/lib/dpkg/info/libcpufreq0.postinst
/var/lib/dpkg/info/libcpufreq0.postrm
/var/lib/dpkg/info/libcpufreq0.shlibs
/var/lib/dpkg/info/libcpufreq0.symbols
/var/lib/update-rc.d/cpufreqd
/var/lib/update-rc.d/cpufrequtils
/var/lib/update-rc.d/loadcpufreq

/usr/bin/cpufreq-selector seems to be from gnome-applets, but
uninstalling this package wants to uninstall Gnome:
# apt-get remove gnome-applets
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer
required:
libmono-addins-gui0.2-cil mono-2.0-gac geoclue-localnet libempathy30
geoclue tomboy
telepathy-salut libevent-1.4-2 libgtk-vnc-1.0-0 libgnomepanel2.24-cil
libglade2.0-cil
libglib2.0-cil python-software-properties cheese evolution-exchange
libgconf2.0-cil
python-aptdaemon-gtk gnome-codec-install python-aptdaemon cli-common
gnome-screensaver
w3c-dtd-xhtml libnm-util1 system-config-printer libart2.0-cil
libjs-jquery
epiphany-extensions seahorse empathy python-apt libempathy-common
libempathy-gtk28
gvfs-bin vinagre swfdec-gnome libgnome2.24-cil libndesk-dbus1.0-cil
seahorse-plugins
libgeoclue0 libmono-cairo2.0-cil gedit-plugins libgmime2.4-cil
software-center
libmono-i18n-west2.0-cil libcryptui0 libgdu-gtk0
libmono-addins0.2-cil arj python-webkit
libmono-posix2.0-cil libmono-security2.0-cil gnome-disk-utility
libgtk2.0-cil mono-gac
python-vte libnm-glib2 unattended-upgrades python-xapian
geoclue-hostip aptdaemon
python-gnupginterface telepathy-mission-control-5 python-cupsutils
libswfdec-0.8-0
libmono-sharpzip2.84-cil libmono-corlib2.0-cil libchamplain-0.4-0
libchamplain-gtk-0.4-0
mono-runtime python-cups python-evolution libndesk-dbus-glib1.0-cil
libempathy-gtk-common
hamster-applet binfmt-support libgnome-vfs2.0-cil libavahi-ui0
transmission-common
gstreamer0.10-tools lsb-release libmono-system2.0-cil transmission-gtk
Use 'apt-get autoremove' to remove them.
The following packages will be REMOVED:
gnome gnome-applets gnome-core gnome-desktop-environment
0 upgraded, 0 newly installed, 4 to remove and 126 not upgraded.
After this operation, 958kB disk space will be freed.
Do you want to continue [Y/n]? n


--
"If someone makes you angry, I think the thing to do is tie them down to
the ground, cover them in honey, and then release a swarm of killer ants
on them. That way, you can hit them over and over again and say, 'Hey!
I'm just trying to help!' and they can't really get mad at you." --R.M.
Weiner
/\___/\
/ /\ /\ \ Phil./Ant @ http://antfarm.ma.cx (Personal Web Site)
| |o o| | Ant's Quality Foraged Links: http://aqfl.net
\ _ / Nuke ANT from e-mail address: NT
( ) or
Ant is currently not listening to any songs on his home computer.

On 3/13/2010 7:16 AM PT, Yousuf Khan typed:

Error always on CPU 1? Maybe try to disable that core?

No, there was a 0 and some interesting parts:

Mar 11 00:17:55 foobar mcelog: CPU 0 1 instruction cache
Mar 11 00:17:55 foobar mcelog: memory/cache error 'evict mem
transaction, instruction transaction, level 1'
Mar 11 00:29:19 foobar kernel: [ 0.008322] Checking 'hlt'
instruction... OK.
Mar 12 05:45:36 foobar kernel: [ 0.004322] Checking 'hlt'
instruction... OK.
Mar 12 14:45:16 foobar mcelog: CPU 1 1 instruction cache
Mar 12 14:45:16 foobar mcelog: TLB error 'instruction transaction,
level 1'
Mar 12 22:02:46 foobar mcelog: CPU 1 1 instruction cache
Mar 12 22:02:46 foobar mcelog: TLB error 'instruction transaction,
level 1'

I wonder how I can output more sections of those errors instead of
lines. Is there really a way to disable a core? I don't know how nor
saw one in CMOS (yes, latest BIOS).

Vast majority seem to be on CPU 1, rather than CPU 0. The error on CPU 0
is also slightly different from that on CPU 1. It seems like CPU 0's
error might be related to some kind of bad cache transfer from CPU 1.

As for disabling the core, I'm not sure where to look for it in BIOS. My
own BIOS has a feature called Advanced Clock Calibration (ACC), which
allows me to change how many cores come up on my Phenom II X3. I can
enable upto 4 cores, or change which cores are enabled, theoretically.
However, in my case, doing anything but the default results in a hang.

Interesting. I recall seeing those. FYI,
http://www.msi.com/index.php?func=do...17&type=manual for
the PDF manuals of my motherboard.
--
"Ants live safely till they have gotten wings." --unknown
/\___/\
/ /\ /\ \ Phil./Ant @ http://antfarm.ma.cx (Personal Web Site)
| |o o| | Ant's Quality Foraged Links: http://aqfl.net
\ _ / Nuke ANT from e-mail address: NT
( ) or
Ant is currently not listening to any songs on his home computer.

Ant wrote in part:
On 3/13/2010 8:32 AM PT, Robert Redelmeier typed:
OTOH, I would rmmod cpufreq* because they get loaded in kernel space.

Delete all these including in Kernels?
$ locate cpufreq
/etc/cpufreqd.conf
/etc/default/cpufreqd
/etc/init.d/cpufreqd


[snip] there is no need to remove files nor
to `apt-get remove` anything.

Just make sure they're not running. Look at the
module dependences with depmod or moddep, then
rmmod them in the correct order.

If gnome is not run, why would cpufreq* get loaded? Even then,
it would only be by some [obscure] config option. FWIW, I gave up
on gnome long ago, and recently on KDE as being MS-level bloatware.
Mostly I run naked X, or xfce/fvwm2 when I need a wdm.


-- Robert

On 3/13/2010 9:50 AM PT, Robert Redelmeier typed:

wrote in part:
On 3/13/2010 8:32 AM PT, Robert Redelmeier typed:
OTOH, I would rmmod cpufreq* because they get loaded in kernel space.

Delete all these including in Kernels?
$ locate cpufreq
/etc/cpufreqd.conf
/etc/default/cpufreqd
/etc/init.d/cpufreqd

[snip] there is no need to remove files nor
to `apt-get remove` anything.

Just make sure they're not running. Look at the
module dependences with depmod or moddep, then
rmmod them in the correct order.

# moddep
bash: moddep: command not found

# lsmod |grep cpufreq
cpufreq_powersave 602 0
cpufreq_userspace 1444 0
cpufreq_stats 1940 0
cpufreq_conservative 4018 0

For kicks, I removed these four cpufreq modules in that order to see if
I still get errors and/or kernel panics.

FYI (never used this command):
# depmod cpufreq
FATAL: modules must be specified using absolute paths.
"cpufreq" is a relative path
# locate cpufreq_powersave
/lib/modules/2.6.30-2-686/kernel/drivers/cpufreq/cpufreq_powersave.ko
/lib/modules/2.6.32-trunk-686/kernel/drivers/cpufreq/cpufreq_powersave.ko
# depmod
/lib/modules/2.6.32-trunk-686/kernel/drivers/cpufreq/cpufreq_powersave.ko
# locate cpufreq_userspace
/lib/modules/2.6.30-2-686/kernel/drivers/cpufreq/cpufreq_userspace.ko
/lib/modules/2.6.32-trunk-686/kernel/drivers/cpufreq/cpufreq_userspace.ko
# depmod
/lib/modules/2.6.32-trunk-686/kernel/drivers/cpufreq/cpufreq_userspace.ko
# locate cpufreq_stats
/lib/modules/2.6.30-2-686/kernel/drivers/cpufreq/cpufreq_stats.ko
/lib/modules/2.6.32-trunk-686/kernel/drivers/cpufreq/cpufreq_stats.ko
# depmod
/lib/modules/2.6.32-trunk-686/kernel/drivers/cpufreq/cpufreq_stats.ko
# locate cpufreq_statscpufreq_conservative
# locate cpufreq_stats
/lib/modules/2.6.30-2-686/kernel/drivers/cpufreq/cpufreq_stats.ko
/lib/modules/2.6.32-trunk-686/kernel/drivers/cpufreq/cpufreq_stats.ko
# depmod
/lib/modules/2.6.32-trunk-686/kernel/drivers/cpufreq/cpufreq_stats.ko

Is Kernel autoloading these modules even if I don't use AMD's
Cool'n'Quiet and powernow?
--
"At high tide the fish eat ants; at low tide the ants eat fish." --Thai
Proverb
/\___/\
/ /\ /\ \ Phil./Ant @ http://antfarm.ma.cx (Personal Web Site)
| |o o| | Ant's Quality Foraged Links: http://aqfl.net
\ _ / Nuke ANT from e-mail address: NT
( ) or
Ant is currently not listening to any songs on his home computer.

Ant wrote in part:
# lsmod |grep cpufreq
cpufreq_powersave 602 0
cpufreq_userspace 1444 0
cpufreq_stats 1940 0
cpufreq_conservative 4018 0

The 0 is good because these modules are independant

Is Kernel autoloading these modules even if I don't use
AMD's Cool'n'Quiet and powernow?

I don't think so -- such dependencies should show on the right
(iso 0) for some other mod. But daemons do strange things,
and acpid is one of the strangest.

-- Robert

On 3/13/2010 10:51 AM PT, Ant typed:

OTOH, I would rmmod cpufreq* because they get loaded in kernel space.

Just make sure they're not running. Look at the
module dependences with depmod or moddep, then
rmmod them in the correct order.

# lsmod |grep cpufreq
cpufreq_powersave 602 0
cpufreq_userspace 1444 0
cpufreq_stats 1940 0
cpufreq_conservative 4018 0

For kicks, I removed these four cpufreq modules in that order to see if
I still get errors and/or kernel panics.

NOPE! Still happening:
Mar 13 12:36:53 foobar mcelog: HARDWARE ERROR. This is *NOT* a software
problem!
Mar 13 12:36:53 foobar mcelog: Please contact your hardware vendor
Mar 13 12:36:53 foobar mcelog: MCE 0
Mar 13 12:36:53 foobar mcelog: CPU 1 1 instruction cache
Mar 13 12:36:53 foobar mcelog: ADDR c11b6ff0
Mar 13 12:36:53 foobar mcelog: TIME 1268512613 Sat Mar 13 12:36:53 2010
Mar 13 12:36:53 foobar mcelog: TLB parity error in virtual array
Mar 13 12:36:53 foobar mcelog: TLB error 'instruction transaction,
level 1'
Mar 13 12:36:53 foobar mcelog: STATUS 9400000000010011 MCGSTATUS 0
Mar 13 12:36:53 foobar mcelog: MCGCAP 105 APICID 1 SOCKETID 0
Mar 13 12:36:53 foobar mcelog: CPUID Vendor AMD Family 15 Model 43
Mar 13 12:36:53 foobar kernel: [45599.988029] Machine check events logged


--
"Don't be no Ant-Man. An Ant-Man has very low horizons." --Forrest Gump
/\___/\
/ /\ /\ \ Phil./Ant @ http://antfarm.ma.cx (Personal Web Site)
| |o o| | Ant's Quality Foraged Links: http://aqfl.net
\ _ / Nuke ANT from e-mail address: NT
( ) or
Ant is currently not listening to any songs on his home computer.

On 3/13/2010 1:32 PM PT, Robert Redelmeier typed:

# lsmod |grep cpufreq
cpufreq_powersave 602 0
cpufreq_userspace 1444 0
cpufreq_stats 1940 0
cpufreq_conservative 4018 0

The 0 is good because these modules are independant

OK cool.


Is Kernel autoloading these modules even if I don't use
AMD's Cool'n'Quiet and powernow?

I don't think so -- such dependencies should show on the right
(iso 0) for some other mod. But daemons do strange things,
and acpid is one of the strangest.

Hmm, lsmod |grep acpid showed nothing.
--
"The antics begin!" --SimAnt Game
/\___/\
/ /\ /\ \ Phil./Ant @ http://antfarm.ma.cx (Personal Web Site)
| |o o| | Ant's Quality Foraged Links: http://aqfl.net
\ _ / Nuke ANT from e-mail address: NT
( ) or
Ant is currently not listening to any songs on his home computer.

Ant wrote in part:
Hmm, lsmod |grep acpid showed nothing.

It won't -- acpid is a daemon, not a module.
It shows on the process taks list (ps/top), not lsmod .

But it is unlikely to be the cause if cpufreq modules
aren't loaded.

-- Robert