Package Details: atlas-lapack 3.10.3-1

Git Clone URL: (read-only)
Package Base: atlas-lapack
Description: Complete LAPACK and BLAS implementation using optimised ATLAS routines
Upstream URL:
Licenses: custom:blas, custom:lapack, custom:atlas
Conflicts: atlas-lapack-base, blas, cblas, lapack
Provides: atlas-lapack-base, blas, cblas, lapack=3.6.1
Submitter: ilpianista
Maintainer: giniu
Last Packager: giniu
Votes: 88
Popularity: 1.678104
First Submitted: 2008-04-24 01:36
Last Updated: 2016-07-30 16:48

Required by (193)

Sources (6)

Latest Comments

jerryjiahaha commented on 2017-06-21 18:12

After disabling intel_pstate and setting performance, my `scaling_cur_freq` is still always smaller than `cpuinfo_max_freq` and configure failed at checking cpu throttle.
Solution: `echo 1 > /sys/module/processor/parameters/ignore_ppc` Then set `/sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq` works for me.


p.s. I think my broadwell cpu (with model 0x3D) should be checked as IntCorei3 in CONFIG/src/backend/archinfo_x86.c (At present it will be checked as MACHOther)

phcerdan commented on 2017-06-08 06:48

Hey I just installed, and make these notes, that might be useful for somebody else:
Good explanation in atlas site:

Follow this, the governor set by cpupower knows shit about CPU without this:

Permanent disable intel_pstate:
Edit: /etc/default/grub
and update grub:
grub-mkconfig -o /boot/grub/grub.cfg

And then enable acpi-cpufreq module:
su root
echo "acpi-cpufreq" > /etc/modules-load.d/acpi-cpufreq.conf


Now cpupower can set frequencies properly.

To disable throtling
sudo pacman -S cpupower
sudo cpupower frequency-set -g performance
It should apply to all cores, but if it only apply to the first one: copy files to the other (4 in laptop)
sudo cp /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor

To restore:
sudo cpupower frequency-set -g ondemand
If not all cores are set:
sudo cp /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor

This stuff is only required at build time.

paulkerry commented on 2017-06-07 09:37

In case it helps anyone, to build this package I had to disable hyperthreading in BIOS to stop the "throttling error" and then set the cpu governor to performance (cpupower frequency-set -g governor).

tindzk commented on 2017-01-12 13:45

I encountered the same compilation problem and could fix it by adding the patch from

ArchangeGabriel commented on 2016-09-06 21:09

@mamstriz: atlas-lapack-base didn’t complain at all, because it wasn’t optimized for your specific setup.

That’s said, I don’t know why it was removed from the repo, but you still have the option to install blas, cblas and/or lapack instead for python2-numpy and the likes. ;)

marmistrz commented on 2016-09-02 20:44

Ok, this seems to be the reason why I failed to compile it without intel-pstate. My CPU uses Intel Turbo Boost.

Is it possible to install this without such tricks? Many common packages need this, e.g. python2-numpy, r.

The old package atlas-lapack-base didn't complain at all.

nTia89 commented on 2016-08-19 15:59

today I give it another try, since I noticed about this bug (

at this time, I was successful by booting with `intel-pstate=disable` kernel parameter AND, together with, disabling the SpeedStep intel feature from the bios of my laptop

now, is there a way to check out the performance, in order to compare the performance increase of the compiled package versus the pre-compiled one?

EDIT: I was successful (compilation starts) even with the combination of: disabling intel_pstate, disabling ppc through kernel parameters and forcing the performance governor using cpupower tool

EDIT2: I added a little section in our archwiki ( in order to help fellows.
This is a very preliminary draft version, so every edit is welcome

EDIT3: how does the compilation should handle intel TurboBoost technology, since this is disabled when disabling pstate?

marmistrz commented on 2016-08-18 18:08

Have problems too, using TLP. Have the same lines in dmesg:

[ 0.033503] ENERGY_PERF_BIAS: Set to 'normal', was 'performance'
[ 0.033503] ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8)

bartus commented on 2016-08-11 11:59

A neat solution would be to add 'wait' function beside the prompt - and gave user a chance to change cpu-governor before starting the build procedure.

Similar solution can be found in Slic3r-git PKGBUILD which allow user to tune the branch before starting the build.

nTia89 commented on 2016-07-31 09:27

I've already tried it

PS: my CPU is an Intel Broadwell

EDIT: maybe related to these lines found with dmesg?
[ 0.027339] ENERGY_PERF_BIAS: Set to 'normal', was 'performance'
[ 0.027339] ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8)

All comments