https://wiki.archlinux.org/api.php?action=feedcontributions&user=Swiftie&feedformat=atomArchWiki - User contributions [en]2024-03-29T11:49:15ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Intel_C%2B%2B&diff=327950Intel C++2014-08-01T13:38:57Z<p>Swiftie: /* Software compiled with Intel C / C++ */</p>
<hr />
<div>[[Category:Development]]<br />
[[it:Intel C++]]<br />
[[zh-CN:Intel C++]]<br />
{{Related articles start}}<br />
{{Related|ABS}}<br />
{{Related|Creating packages}}<br />
{{Related|Makepkg}}<br />
{{Related articles end}}<br />
<br />
Installation and basic usage of Intel® C++ Composer XE (formerly Intel® C++ Compiler Professional Edition) for Linux on Arch.<br />
<br />
== Before you begin ==<br />
<br />
{{Note|Packages that have been compiled by icc will depend on the associated libs contained in the '''intel-openmp''' package in order to run. Since '''intel-openmp''' depends on '''intel-compiler-base''', users MUST have both packages installed at all times!}}<br />
<br />
== Setup and installation ==<br />
<br />
{{AUR|intel-parallel-studio-xe}} are available in the [[AUR]]. To build the package, one needs a license file which is free for personal and for non-commercial use. The requisite license file is emailed to users upon [[https://registrationcenter.intel.com/RegCenter/AutoGen.aspx?ProductID=1517&AccountID=&EmailID=&ProgramID=&RequestDt=&rm=NCOM&lang= registration]] and should be copied into the $startdir prior to running makepkg. The current PKGBUILD assembles 7 or 8 packages:<br />
<br />
* '''intel-compiler-base''' - Intel C/C++ compiler and base libs<br />
* '''intel-fortran-compiler''' - Intel fortran compiler and base libs (only Parallel Studio XE)<br />
* '''intel-openmp''' - Intel OpenMP Library<br />
* intel-idb- Intel C/C++ debugger<br />
* intel-ipp - Intel Integrated Performance Primitives<br />
* intel-mkl - Intel Math Kernel Library (Intel® MKL)<br />
* intel-sourcechecker - Intel Source Checker<br />
* intel-tbb - Intel Threading Building Blocks (TBB)<br />
<br />
{{Note|A minimal working environment requires the '''intel-compiler-base''' and '''intel-openmp''' packages; if you want also the fortran compiler you must install '''intel-fortran-compiler'''.}}<br />
<br />
== Using icc with makepkg ==<br />
<br />
{{Note|Not every package will successfully compile with icc without heavy modifications to the underlying source.}}<br />
<br />
There is currently no official guide to using icc with makepkg. This section is meant to capture various methods suggested by users. Please make a new sub-section with your suggested method titled as such.<br />
<br />
=== Method 1 (12/08/2012) ===<br />
<br />
Modify {{ic|/etc/makepkg.conf}} inserting the following code ''under'' the existing line defining '''CXXFLAGS''' to enable makepkg to use icc. No special switches are needed when calling makepkg to build.<br />
<br />
{{bc|1=_CC=icc<br />
if [ $_CC = "icc" ]; then<br />
export CC="icc"<br />
export CXX="icpc"<br />
export CFLAGS="-march=native -O3 -no-prec-div -fno-alias -pipe"<br />
export CXXFLAGS="${CFLAGS}"<br />
export LDFLAGS="-Wl,-O1,--sort-common,--as-needed"<br />
export AR="xiar"<br />
export LD="xild"<br />
fi}}<br />
<br />
{{Note|<br />
* To toggle between the native gcc and icc, simple comment or uncomment the newly created '''_CC''' variable.<br />
* In some case the compilation method described above fails and the compilation will be performed with ''gcc'', so you should test if yours application has been effectively compiled with ''icc''.}}<br />
<br />
To test if your package has been really compiled with icc:<br />
<br />
* Type the command '''ldd [your_app] | grep intel''' If the application is linked to a shared object located in the directory '''/opt/intel/lib/''' it's mind that has been complied with icc.<br />
<br />
* Another method is to observe the build output and watch if it's using the ''icc'' or ''icpc'' command.<br />
<br />
* The last method is to watch if the warnings are in ''icc'' style or not.<br />
<br />
== icc CFLAGS ==<br />
<br />
In general, icc supports many of the same CFLAGS gcc supports and is also pretty tolerant to gcc flags it cannot use. In most cases it will happily ignore the flag warning the user and moving on. For an exhaustive list and explanation of available compiler flags, consult the icc manpage or better yet by invoking the compiler with the help flag:<br />
icc --help<br />
<br />
=== -xX ===<br />
<br />
Use to generate specialized code to run exclusively on processors supporting it. If unsure which option to use, simply inspect the '''flags''' section of {{ic|/proc/cpuinfo}}. In the example below, '''SSE4.1''' would be the correct selection:<br />
<br />
{{hc|$ grep -m 1 flags /proc/cpuinfo|<br />
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush <br />
dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs <br />
bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr<br />
pdcm sse4_1 lahf_lm dts tpr_shadow vnmi flexpriority<br />
}}<br />
<br />
* -xHost<br />
* -xSSE2<br />
* -xSSE3<br />
* -xSSSE3<br />
* -xSSE4.1<br />
* -xSSE4.2<br />
* -xAVX<br />
* -xCORE-AVX-I<br />
* -xSSSE3_ATOM<br />
<br />
{{Tip|Use the '''-xHost''' flag if unsure what your specific processor supports.}}<br />
<br />
=== -Ox ===<br />
<br />
Same behavior as gcc. x is one of the following options:<br />
* 0 - disables optimizations<br />
* 1 - optimize for maximum speed, but disable some optimizations which increase code size for a small speed benefit<br />
* 2 - optimize for maximum speed (DEFAULT)<br />
* 3 - optimize for maximum speed and enable more aggressive optimizations that may not improve performance on some programs (recommended for math intensive looping programs)<br />
<br />
=== -w ===<br />
<br />
Similar to the gcc:<br />
* -w - disable all warnings (recommended for the package compilation)<br />
* -Wbrief - print brief one-line diagnostics<br />
* -Wall - enable all warnings<br />
* -Werror - force warnings to be reported as errors<br />
<br />
== Software compiled with Intel C / C++ ==<br />
<br />
In the following table we report a list of packages from the officials repository that we have tried to compile with the intel C/C++ compiler. The compilation should be done by using the PKGBUILD from ABS.<br />
<br />
<br />
{| class="wikitable sortable collapsible" border="1" border="1"<br />
|-style="background: #ffdead;" <br />
! Application || Compile || Comments<br />
<br />
|-<br />
| '''xvidcore''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''kdebase''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''conky 1.9.0''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''nginx 1.4.2''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''gzip 1.6''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''xz''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''lz4''' || style="background: GreenYellow" | OK || We must edit the PKGBUILD.<br />
|-<br />
| '''minetest''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''opus''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''zlib 1.2.8''' || style="background: yellow" | Not recommended || Works with the [[Intel_C++#Method_1 | Method 1]], but caused bugs in some apps, like tightvnc<br />
|-<br />
| '''Gimp 2.8 / 2.9 ''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''Pacman 4.0.3''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''x264''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''MySql''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''SqlLite''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''lame''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''xaos''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''gegl''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''VLC''' || style="background: Tomato" | Unsuccessful || There's some problem with the compiler flags<br />
|-<br />
| '''bzip2''' || style="background: Tomato" | Unsuccessful || There's some problem with the compiler flags<br />
|-<br />
| '''mplayer''' || style="background: pink" | Out of date || It don't recognize the Intel compiler<br />
|-<br />
| '''optipng''' || style="background: GreenYellow" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]. Comment out LD=xild in makepkg.conf<br />
|-<br />
| '''python-numpy''' || style="background: GreenYellow" | OK || We must edit the PKGBUILD. {{AUR|python-numpy-mkl}}<br />
|-<br />
| '''python-scipy''' || style="background: GreenYellow" | OK || We must edit the PKGBUILD. {{AUR|python-scipy-mkl}}<br />
|-<br />
| '''Qt''' || style="background: GreenYellow" | OK || We must add the option ''-platform linux-icc-64 (or 32)'' in the configure command <br />
|-<br />
| '''systemd''' || style="background: red" | Fail ||undefined reference to `server_dispatch_message'<br />
|}<br />
<br />
'''Legend:'''<br />
{|<br />
|-<br />
| style="background: Lime" | OK || The compilation with ICC works!<br />
|-<br />
| style="background: GreenYellow" | OK || The compilation works but is needed an editing of the PKGBUILD<br />
|-<br />
| style="background: Tomato" | Unsuccessful || The compilation may work, but there are some compilations errors.<br />
|-<br />
| style="background: yellow" | Not recommended || The compilation works, but is not recommended <br />
|-<br />
| style="background: red" | Fail || It's impossible to compile the PKG with ICC.<br />
|-<br />
| style="background: pink" | Out of date || It's unsuccessful or fails with older CFLAGS. You can try compiling it with new [[Intel_C++#Method_1 | Method 1]].(Don't forget to paste your result here!)<br />
|}</div>Swiftiehttps://wiki.archlinux.org/index.php?title=DSDT&diff=290948DSDT2013-12-30T17:17:08Z<p>Swiftie: /* Using modified code */</p>
<hr />
<div>[[Category:Boot process]]<br />
[[Category:Kernel]]<br />
[[Category:Power management]]<br />
{{Related articles start}}<br />
{{Related|ACPI modules}}<br />
{{Related|acpid}}<br />
{{Related articles end}}<br />
DSDT (Differentiated System Description Table) is a part of the [[Wikipedia:Advanced Configuration and Power Interface|ACPI]] specification. It supplies information about supported power events in a given system. ACPI tables are provided in firmware from the manufacturer. A common Linux problem is missing ACPI functionality, such as: fans not running, screens not turning off when the lid is closed, etc. This can stem from DSDTs made with Windows specifically in mind, which can be patched after installation. The goal of this article is to analyze and rebuild a faulty DSDT, so that the kernel can override the default one.<br />
<br />
Basically a DSDT table is the code run on ACPI (Power Management) events.<br />
<br />
{{Note|The goal of the [http://www.lesswatts.org/projects/acpi/ Linux ACPI]{{Linkrot|2013|10|26}} project is that Linux should work on unmodified firmware. If you still find this type of workaround necessary on modern kernels then you should consider [[Reporting Bug Guidelines|submiting a bug report]]. }}<br />
<br />
==Before you start...==<br />
* It is possible that the hardware manufacturer has released an updated firmware which fixes ACPI related problems. Installing an updated firmware is often preferred over this method because it would avoid duplication of effort.<br />
* This process does tamper with some fairly fundamental code on your installation. You will want to be absolutely sure of the changes you make. You might also wish to [[Disk cloning | clone your disk]] beforehand.<br />
* Even before attempting to fix your DSDT yourself, you can attempt a couple of different shortcuts: <br />
<br />
===Tell the kernel to report a version of Windows===<br />
<br />
Use the variable '''acpi_os_name''' as a kernel parameter. For example:<br />
<br />
acpi_os_name="Microsoft Windows NT"<br />
<br />
Or<br />
<br />
acpi_osi="!Windows2012"<br />
appended to the kernel line in grub legacy configuration<br />
<br />
other strings to test:<br />
* "Microsoft Windows XP"<br />
* "Microsoft Windows 2000"<br />
* "Microsoft Windows 2000.1"<br />
* "Microsoft Windows ME: Millennium Edition"<br />
* "Windows 2001"<br />
* "Windows 2006"<br />
* "Windows 2009"<br />
* "Windows 2012"<br />
* when all that fails, you can even try "Linux"<br />
<br />
Out of curiousity, you can follow the steps below to extract your DSDT and search the .dsl file. Just grep for "Windows" and see what pops up.<br />
<br />
===Find a fixed DSDT===<br />
A DSDT file is originally written in ACPI Source language (an .asl/.dsl file). Using a compiler this can produce an 'ACPI Machine Language' file (.aml) or a hex table (.hex). To incorporate the file in your Arch install, you will need to get hold of a compiled .aml file. - whether this means compiling it yourself or trusting some stranger on the Internet is at your discretion. If you do download a file from the world wide web, it will most likely be a compressed .asl file. So you will need to unzip it and compile it. The upside to this is that you won't have to research specific code fixes yourself.<br />
<br />
Arch users with the same laptop as you are: a minority of a minority of a minority. Try browsing other distro/linux forums for talk about the same model. Likelihood is that they have the same problems and either because there is a lot of them, or because they're tech savvy -- someone there has produced a working DSDT and maybe even provides a precompiled version (again, use at your own risk).<br />
Search engines are your best tools. Try keeping it short: 'model name' + 'dsdt' will probably produce results.<br />
<br />
== Recompiling it yourself ==<br />
Your best resources in this endeavor are going to be [http://en.gentoo-wiki.com/wiki/ACPI/Fix_common_problems The Gentoo wiki article], [http://www.acpi.info ACPI Spec homepage], and [http://www.lesswatts.org/projects/acpi/ Linux ACPI Project] which supercedes the activity that occurred at ''acpi.sourceforge.net''.<br />
In a nutshell, you can use Intel's ASL compiler to turn your systems DSDT table into source code, locate/fix the errors, and recompile. This process is detailed more comprehensively at the [http://en.gentoo-wiki.com/wiki/ACPI/Fix_common_problems Gentoo wiki].<br />
You'll need to install {{Pkg|iasl}} to modify code, and be familiar with [[Kernel_Compilation#Compilation]] to install it.<br />
<br />
'''What compiled the original code?'''<br />
Check if your system's DSDT was compiled using Intel or Microsoft compiler:<br />
{{hc|<nowiki> $ dmesg|grep DSDT</nowiki> |<br />
ACPI: DSDT 00000000bf7e5000 0A35F (v02 Intel CALPELLA 06040000 INTL 20060912)<br />
ACPI: EC: Look up EC in DSDT<br />
}}<br />
In case Microsoft's compiler had been used, abbreviation INTL would instead be MSFT.<br />
In the example, there were 5 errors on decompiling/recompiling the DSDT. Two of them were easy to fix after a bit of googling and delving into the ACPI specification. Three of them were due to different versions of compiler used and are, as later discovered, handled by the ACPICA at boot-time. The ACPICA component of the kernel can handle most of the trivial errors you get while compiling the DSDT. So do not fret yourself over compile errors if your system is ''working the way it should''.<br />
<br />
1.) Extract ACPI tables (as root): {{ic|# cat /sys/firmware/acpi/tables/DSDT > dsdt.dat}}<br />
<br />
2.) Decompile: {{ic|iasl -d dsdt.dat}}<br />
<br />
3.) Recompile: {{ic|iasl -tc dsdt.dsl}}<br />
<br />
4.) Examine errors and fix. e.g.:{{bc|<br />
dsdt.dsl 6727: Name (_PLD, Buffer (0x10) <br />
Error 4105 - Invalid object type for reserved name ^ (found BUFFER, requires Package) }}<br />
{{hc| nano +6727 dsdt.dsl|<br />
(_PLD, Package(1) {Buffer (0x10)...}}<br />
<br />
5.) Compile fixed code: {{ic|iasl -tc dsdt.dsl}} (Might want to try option -ic for C include file to insert into kernel source)<br />
<br />
If it says no errors and no warnings you should be good to go.<br />
<br />
== Using modified code ==<br />
{{Expansion| Detail each method}}<br />
<br />
There are 2 ways to use a custom DSDT Table:<br />
* compiling the custom DSDT into the kernel<br />
* loading the custom DSDT at runtime (not supported)<br />
<br />
=== Compile into kernel ===<br />
{{Warning|After each BIOS update you need to fix DSDT again and compile it into kernel again}}<br />
You'll want to be familiar with [[Kernels | compiling your own kernel]]. The most straightforward way is with the "traditional" approach.<br />
After compiling DSDT, iasl produce two files: {{ic|dsdt.hex}} and {{ic|dsdt.aml}}.<br />
<br />
'''Using {{ic|menuconfig}}:'''<br />
* Disable "Select only drivers that don't need compile-time external firmware". Located in "Device Drivers -> Generic Driver Options".<br />
* Enable "Include Custom DSDT" and specify the absolute path of your fixed DSDT file ({{ic|dsdt.hex}}, not {{ic|dsdt.aml}}). Located in "Power management and ACPI options -> ACPI (Advanced Configuration and Power Interface) Support".<br />
<br />
<br />
'''Check if you running custom DSDT'''<br />
<br />
Simply type<br />
{{ic|<nowiki>dmesg | grep DSDT</nowiki>}}<br />
<br />
You will see something like that:<br />
{{bc|<nowiki>[ 0.000000] ACPI: Override [DSDT- A M I], this is unsafe: tainting kernel<br />
[ 0.000000] ACPI: DSDT 00000000be9b1190 Logical table override, new table: ffffffff81865af0<br />
[ 0.000000] ACPI: DSDT ffffffff81865af0 0BBA3 (v02 ALASKA A M I 000000F3 INTL 20130517)</nowiki>}}<br />
If you see {{ic|...ACPI: Override...}}, you're running custom DSDT.<br />
<br />
<br />
=== Loading at runtime ===<br />
{{Warning|Loading at runtime don't supports. DSDT hook removed due to bug, see [https://bugs.archlinux.org/task/27906 FS#27906 bug]}}<br />
Luckily the Arch stock kernel supports using a custom DSDT so, first copy the '''.aml''' file compiled by iasl to:<br />
/boot/dsdt.aml<br />
<br />
The bootloader will replace the DSDT so we need a method to include our custom DSDT table into the bootloader image.<br />
Copy the following to '''/etc/grub.d/01_acpi'''<br />
<br />
#!/bin/sh<br />
set -e<br />
<br />
# Uncomment to load custom ACPI table<br />
GRUB_CUSTOM_ACPI="/boot/dsdt.aml"<br />
<br />
<br />
# DON'T MODIFY ANYTHING BELOW THIS LINE!<br />
<br />
<br />
prefix=/usr<br />
exec_prefix=${prefix}<br />
libdir=${exec_prefix}/lib<br />
<br />
<br />
. /usr/share/grub/grub-mkconfig_lib<br />
#. ${libdir}/grub/grub-mkconfig_lib<br />
<br />
<br />
# Load custom ACPI table<br />
if [ x${GRUB_CUSTOM_ACPI} != x ] && [ -f ${GRUB_CUSTOM_ACPI} ] \<br />
&& is_path_readable_by_grub ${GRUB_CUSTOM_ACPI}; then<br />
echo "Found custom ACPI table: ${GRUB_CUSTOM_ACPI}" >&2<br />
prepare_grub_to_access_device `${grub_probe} --target=device ${GRUB_CUSTOM_ACPI}` | sed -e "s/^/ /"<br />
cat << EOF<br />
acpi (\$root)`make_system_path_relative_to_its_root ${GRUB_CUSTOM_ACPI}`<br />
EOF<br />
fi<br />
<br />
Make sure to make this file executable, or it will be ignored by '''grub-mkconfig'''<br />
chmod +x /etc/grub.d/01_acpi<br />
<br />
This will tell GRUB to include the DSDT into its core.img (change GRUB_CUSTOM_ACPI to reflect the path to your .aml file).<br />
Next you will need a new boot image. If you use GRUB run:<br />
grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
Lastly, recreate your initrd<br />
mkinitcpio -p linux<br />
and reboot. Done!<br />
<br />
To check if you are really using your own DSDT read your table again {{ic|# cat /sys/firmware/acpi/tables/DSDT > dsdt.dat}}<br />
and decompile it with {{ic|iasl -d dsdt.dat}}</div>Swiftiehttps://wiki.archlinux.org/index.php?title=Intel_C%2B%2B&diff=280121Intel C++2013-10-28T10:56:52Z<p>Swiftie: /* Software compiled with Intel C / C++ */</p>
<hr />
<div>[[Category:Development]]<br />
[[it:Intel C++]]<br />
[[zh-CN:Intel C++]]<br />
{{Article summary start}}<br />
{{Article summary text|Installation and basic usage of Intel® C++ Composer XE (formerly Intel® C++ Compiler Professional Edition) for Linux on Arch.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|ABS}}<br />
{{Article summary wiki|Creating Packages}}<br />
{{Article summary wiki|Makepkg}}<br />
{{Article summary end}}<br />
<br />
== Before you begin ==<br />
<br />
{{Note|Packages that have been compiled by icc will depend on the associated libs contained in the '''intel-openmp''' package in order to run. Since '''intel-openmp''' depends on '''intel-compiler-base''', users MUST have both packages installed at all times!}}<br />
<br />
== Setup and installation ==<br />
<br />
{{AUR|intel-parallel-studio-xe}} are available in the [[AUR]]. To build the package, one needs a license file which is free for personal and for non-commercial use. The requisite license file is emailed to users upon [[https://registrationcenter.intel.com/RegCenter/AutoGen.aspx?ProductID=1517&AccountID=&EmailID=&ProgramID=&RequestDt=&rm=NCOM&lang= registration]] and should be copied into the $startdir prior to running makepkg. The current PKGBUILD assembles 7 or 8 packages:<br />
<br />
* '''intel-compiler-base''' - Intel C/C++ compiler and base libs<br />
* '''intel-fortran-compiler''' - Intel fortran compiler and base libs (only Parallel Studio XE)<br />
* '''intel-openmp''' - Intel OpenMP Library<br />
* intel-idb- Intel C/C++ debugger<br />
* intel-ipp - Intel Integrated Performance Primitives<br />
* intel-mkl - Intel Math Kernel Library (Intel® MKL)<br />
* intel-sourcechecker - Intel Source Checker<br />
* intel-tbb - Intel Threading Building Blocks (TBB)<br />
<br />
{{Note|A minimal working environment requires the '''intel-compiler-base''' and '''intel-openmp''' packages; if you want also the fortran compiler you must install '''intel-fortran-compiler'''.}}<br />
<br />
== Using icc with makepkg ==<br />
<br />
{{Note|Not every package will successfully compile with icc without heavy modifications to the underlying source.}}<br />
<br />
There is currently no official guide to using icc with makepkg. This section is meant to capture various methods suggested by users. Please make a new sub-section with your suggested method titled as such.<br />
<br />
=== Method 1 (12/08/2012) ===<br />
<br />
Modify {{ic|/etc/makepkg.conf}} inserting the following code ''under'' the existing line defining '''CXXFLAGS''' to enable makepkg to use icc. No special switches are needed when calling makepkg to build.<br />
<br />
{{bc|1=_CC=icc<br />
if [ $_CC = "icc" ]; then<br />
export CC="icc"<br />
export CXX="icpc"<br />
export CFLAGS="-march=native -O3 -no-prec-div -fno-alias -pipe"<br />
export CXXFLAGS="${CFLAGS}"<br />
export LDFLAGS="-Wl,-O1,--sort-common,--as-needed"<br />
export AR="xiar"<br />
export LD="xild"<br />
fi}}<br />
<br />
{{Note|<br />
* To toggle between the native gcc and icc, simple comment or uncomment the newly created '''_CC''' variable.<br />
* In some case the compilation method described above fails and the compilation will be performed with ''gcc'', so you should test if yours application has been effectively compiled with ''icc''.}}<br />
<br />
To test if your package has been really compiled with icc:<br />
<br />
* Type the command '''ldd [your_app] | grep intel''' If the application is linked to a shared object located in the directory '''/opt/intel/lib/''' it's mind that has been complied with icc.<br />
<br />
* Another method is to observe the build output and watch if it's using the ''icc'' or ''icpc'' command.<br />
<br />
* The last method is to watch if the warnings are in ''icc'' style or not.<br />
<br />
== icc CFLAGS ==<br />
<br />
In general, icc supports many of the same CFLAGS gcc supports and is also pretty tolerant to gcc flags it cannot use. In most cases it will happily ignore the flag warning the user and moving on. For an exhaustive list and explanation of available compiler flags, consult the icc manpage or better yet by invoking the compiler with the help flag:<br />
icc --help<br />
<br />
=== -xX ===<br />
<br />
Use to generate specialized code to run exclusively on processors supporting it. If unsure which option to use, simply inspect the '''flags''' section of {{ic|/proc/cpuinfo}}. In the example below, '''SSE4.1''' would be the correct selection:<br />
<br />
{{hc|$ grep -m 1 flags /proc/cpuinfo|<br />
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush <br />
dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs <br />
bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr<br />
pdcm sse4_1 lahf_lm dts tpr_shadow vnmi flexpriority<br />
}}<br />
<br />
* -xHost<br />
* -xSSE2<br />
* -xSSE3<br />
* -xSSSE3<br />
* -xSSE4.1<br />
* -xSSE4.2<br />
* -xAVX<br />
* -xCORE-AVX-I<br />
* -xSSSE3_ATOM<br />
<br />
{{Tip|Use the '''-xHost''' flag if unsure what your specific processor supports.}}<br />
<br />
=== -Ox ===<br />
<br />
Same behavior as gcc. x is one of the following options:<br />
* 0 - disables optimizations<br />
* 1 - optimize for maximum speed, but disable some optimizations which increase code size for a small speed benefit<br />
* 2 - optimize for maximum speed (DEFAULT)<br />
* 3 - optimize for maximum speed and enable more aggressive optimizations that may not improve performance on some programs (recommended for math intensive looping programs)<br />
<br />
=== -w ===<br />
<br />
Similar to the gcc:<br />
* -w - disable all warnings (recommended for the package compilation)<br />
* -Wbrief - print brief one-line diagnostics<br />
* -Wall - enable all warnings<br />
* -Werror - force warnings to be reported as errors<br />
<br />
== Software compiled with Intel C / C++ ==<br />
<br />
In the following table we report a list of packages from the officials repository that we have tried to compile with the intel C/C++ compiler. The compilation should be done by using the PKGBUILD from ABS.<br />
<br />
<br />
{| class="wikitable sortable collapsible" border="1" border="1"<br />
|-style="background: #ffdead;" <br />
! Application || Compile || Comments<br />
<br />
|-<br />
| '''xvidcore''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''kdebase''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''conky 1.9.0''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''nginx 1.4.2''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''gzip 1.6''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''xz''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''lz4''' || style="background: GreenYellow" | OK || We must edit the PKGBUILD.<br />
|-<br />
| '''minetest''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''opus''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''zlib 1.2.8''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''Gimp 2.8''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''Pacman 4.0.3''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''x264''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''MySql''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''SqlLite''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''lame''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''xaos''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''VLC''' || style="background: Tomato" | Unsuccessful || There's some problem with the compiler flags<br />
|-<br />
| '''bzip2''' || style="background: Tomato" | Unsuccessful || There's some problem with the compiler flags<br />
|-<br />
| '''mplayer''' || style="background: pink" | Out of date || It don't recognize the Intel compiler<br />
|-<br />
| '''optipng''' || style="background: GreenYellow" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]. Comment out LD=xild in makepkg.conf<br />
|-<br />
| '''python-numpy''' || style="background: GreenYellow" | OK || We must edit the PKGBUILD. {{AUR|python-numpy-mkl}}<br />
|-<br />
| '''python-scipy''' || style="background: GreenYellow" | OK || We must edit the PKGBUILD. {{AUR|python-scipy-mkl}}<br />
|-<br />
| '''Qt''' || style="background: GreenYellow" | OK || We must add the option ''-platform linux-icc-64 (or 32)'' in the configure command <br />
|-<br />
| '''systemd''' || style="background: red" | Fail ||undefined reference to `server_dispatch_message'<br />
|}<br />
<br />
'''Legend:'''<br />
{|<br />
|-<br />
| style="background: Lime" | OK || The compilation with ICC works!<br />
|-<br />
| style="background: GreenYellow" | OK || The compilation works but is needed an editing of the PKGBUILD<br />
|-<br />
| style="background: Tomato" | Unsuccessful || The compilation may work, but there are some compilations errors.<br />
|-<br />
| style="background: yellow" | Not recommended || The compilation works, but is not recommended <br />
|-<br />
| style="background: red" | Fail || It's impossible to compile the PKG with ICC.<br />
|-<br />
| style="background: pink" | Out of date || It's unsuccessful or fails with older CFLAGS. You can try compiling it with new [[Intel_C++#Method_1 | Method 1]].(Don't forget to paste your result here!)<br />
|}</div>Swiftiehttps://wiki.archlinux.org/index.php?title=Intel_C%2B%2B&diff=280120Intel C++2013-10-28T10:55:13Z<p>Swiftie: /* Software compiled with Intel C / C++ */</p>
<hr />
<div>[[Category:Development]]<br />
[[it:Intel C++]]<br />
[[zh-CN:Intel C++]]<br />
{{Article summary start}}<br />
{{Article summary text|Installation and basic usage of Intel® C++ Composer XE (formerly Intel® C++ Compiler Professional Edition) for Linux on Arch.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|ABS}}<br />
{{Article summary wiki|Creating Packages}}<br />
{{Article summary wiki|Makepkg}}<br />
{{Article summary end}}<br />
<br />
== Before you begin ==<br />
<br />
{{Note|Packages that have been compiled by icc will depend on the associated libs contained in the '''intel-openmp''' package in order to run. Since '''intel-openmp''' depends on '''intel-compiler-base''', users MUST have both packages installed at all times!}}<br />
<br />
== Setup and installation ==<br />
<br />
{{AUR|intel-parallel-studio-xe}} are available in the [[AUR]]. To build the package, one needs a license file which is free for personal and for non-commercial use. The requisite license file is emailed to users upon [[https://registrationcenter.intel.com/RegCenter/AutoGen.aspx?ProductID=1517&AccountID=&EmailID=&ProgramID=&RequestDt=&rm=NCOM&lang= registration]] and should be copied into the $startdir prior to running makepkg. The current PKGBUILD assembles 7 or 8 packages:<br />
<br />
* '''intel-compiler-base''' - Intel C/C++ compiler and base libs<br />
* '''intel-fortran-compiler''' - Intel fortran compiler and base libs (only Parallel Studio XE)<br />
* '''intel-openmp''' - Intel OpenMP Library<br />
* intel-idb- Intel C/C++ debugger<br />
* intel-ipp - Intel Integrated Performance Primitives<br />
* intel-mkl - Intel Math Kernel Library (Intel® MKL)<br />
* intel-sourcechecker - Intel Source Checker<br />
* intel-tbb - Intel Threading Building Blocks (TBB)<br />
<br />
{{Note|A minimal working environment requires the '''intel-compiler-base''' and '''intel-openmp''' packages; if you want also the fortran compiler you must install '''intel-fortran-compiler'''.}}<br />
<br />
== Using icc with makepkg ==<br />
<br />
{{Note|Not every package will successfully compile with icc without heavy modifications to the underlying source.}}<br />
<br />
There is currently no official guide to using icc with makepkg. This section is meant to capture various methods suggested by users. Please make a new sub-section with your suggested method titled as such.<br />
<br />
=== Method 1 (12/08/2012) ===<br />
<br />
Modify {{ic|/etc/makepkg.conf}} inserting the following code ''under'' the existing line defining '''CXXFLAGS''' to enable makepkg to use icc. No special switches are needed when calling makepkg to build.<br />
<br />
{{bc|1=_CC=icc<br />
if [ $_CC = "icc" ]; then<br />
export CC="icc"<br />
export CXX="icpc"<br />
export CFLAGS="-march=native -O3 -no-prec-div -fno-alias -pipe"<br />
export CXXFLAGS="${CFLAGS}"<br />
export LDFLAGS="-Wl,-O1,--sort-common,--as-needed"<br />
export AR="xiar"<br />
export LD="xild"<br />
fi}}<br />
<br />
{{Note|<br />
* To toggle between the native gcc and icc, simple comment or uncomment the newly created '''_CC''' variable.<br />
* In some case the compilation method described above fails and the compilation will be performed with ''gcc'', so you should test if yours application has been effectively compiled with ''icc''.}}<br />
<br />
To test if your package has been really compiled with icc:<br />
<br />
* Type the command '''ldd [your_app] | grep intel''' If the application is linked to a shared object located in the directory '''/opt/intel/lib/''' it's mind that has been complied with icc.<br />
<br />
* Another method is to observe the build output and watch if it's using the ''icc'' or ''icpc'' command.<br />
<br />
* The last method is to watch if the warnings are in ''icc'' style or not.<br />
<br />
== icc CFLAGS ==<br />
<br />
In general, icc supports many of the same CFLAGS gcc supports and is also pretty tolerant to gcc flags it cannot use. In most cases it will happily ignore the flag warning the user and moving on. For an exhaustive list and explanation of available compiler flags, consult the icc manpage or better yet by invoking the compiler with the help flag:<br />
icc --help<br />
<br />
=== -xX ===<br />
<br />
Use to generate specialized code to run exclusively on processors supporting it. If unsure which option to use, simply inspect the '''flags''' section of {{ic|/proc/cpuinfo}}. In the example below, '''SSE4.1''' would be the correct selection:<br />
<br />
{{hc|$ grep -m 1 flags /proc/cpuinfo|<br />
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush <br />
dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs <br />
bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr<br />
pdcm sse4_1 lahf_lm dts tpr_shadow vnmi flexpriority<br />
}}<br />
<br />
* -xHost<br />
* -xSSE2<br />
* -xSSE3<br />
* -xSSSE3<br />
* -xSSE4.1<br />
* -xSSE4.2<br />
* -xAVX<br />
* -xCORE-AVX-I<br />
* -xSSSE3_ATOM<br />
<br />
{{Tip|Use the '''-xHost''' flag if unsure what your specific processor supports.}}<br />
<br />
=== -Ox ===<br />
<br />
Same behavior as gcc. x is one of the following options:<br />
* 0 - disables optimizations<br />
* 1 - optimize for maximum speed, but disable some optimizations which increase code size for a small speed benefit<br />
* 2 - optimize for maximum speed (DEFAULT)<br />
* 3 - optimize for maximum speed and enable more aggressive optimizations that may not improve performance on some programs (recommended for math intensive looping programs)<br />
<br />
=== -w ===<br />
<br />
Similar to the gcc:<br />
* -w - disable all warnings (recommended for the package compilation)<br />
* -Wbrief - print brief one-line diagnostics<br />
* -Wall - enable all warnings<br />
* -Werror - force warnings to be reported as errors<br />
<br />
== Software compiled with Intel C / C++ ==<br />
<br />
In the following table we report a list of packages from the officials repository that we have tried to compile with the intel C/C++ compiler. The compilation should be done by using the PKGBUILD from ABS.<br />
<br />
<br />
{| class="wikitable sortable collapsible" border="1" border="1"<br />
|-style="background: #ffdead;" <br />
! Application || Compile || Comments<br />
<br />
|-<br />
| '''xvidcore''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''kdebase''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''conky 1.9.0''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''nginx 1.4.2''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''gzip 1.6''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''xz''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''lz4''' || style="background: GreenYellow" | OK || We must edit the makefile<br />
|-<br />
| '''minetest''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''opus''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''zlib 1.2.8''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''Gimp 2.8''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''Pacman 4.0.3''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''x264''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''MySql''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''SqlLite''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''lame''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''xaos''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''VLC''' || style="background: Tomato" | Unsuccessful || There's some problem with the compiler flags<br />
|-<br />
| '''bzip2''' || style="background: Tomato" | Unsuccessful || There's some problem with the compiler flags<br />
|-<br />
| '''mplayer''' || style="background: pink" | Out of date || It don't recognize the Intel compiler<br />
|-<br />
| '''optipng''' || style="background: GreenYellow" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]. Comment out LD=xild in makepkg.conf<br />
|-<br />
| '''python-numpy''' || style="background: GreenYellow" | OK || We must edit the PKGBUILD. {{AUR|python-numpy-mkl}}<br />
|-<br />
| '''python-scipy''' || style="background: GreenYellow" | OK || We must edit the PKGBUILD. {{AUR|python-scipy-mkl}}<br />
|-<br />
| '''Qt''' || style="background: GreenYellow" | OK || We must add the option ''-platform linux-icc-64 (or 32)'' in the configure command <br />
|-<br />
| '''systemd''' || style="background: red" | Fail ||undefined reference to `server_dispatch_message'<br />
|}<br />
<br />
'''Legend:'''<br />
{|<br />
|-<br />
| style="background: Lime" | OK || The compilation with ICC works!<br />
|-<br />
| style="background: GreenYellow" | OK || The compilation works but is needed an editing of the PKGBUILD<br />
|-<br />
| style="background: Tomato" | Unsuccessful || The compilation may work, but there are some compilations errors.<br />
|-<br />
| style="background: yellow" | Not recommended || The compilation works, but is not recommended <br />
|-<br />
| style="background: red" | Fail || It's impossible to compile the PKG with ICC.<br />
|-<br />
| style="background: pink" | Out of date || It's unsuccessful or fails with older CFLAGS. You can try compiling it with new [[Intel_C++#Method_1 | Method 1]].(Don't forget to paste your result here!)<br />
|}</div>Swiftiehttps://wiki.archlinux.org/index.php?title=Intel_C%2B%2B&diff=280119Intel C++2013-10-28T10:51:43Z<p>Swiftie: /* Software compiled with Intel C / C++ */</p>
<hr />
<div>[[Category:Development]]<br />
[[it:Intel C++]]<br />
[[zh-CN:Intel C++]]<br />
{{Article summary start}}<br />
{{Article summary text|Installation and basic usage of Intel® C++ Composer XE (formerly Intel® C++ Compiler Professional Edition) for Linux on Arch.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|ABS}}<br />
{{Article summary wiki|Creating Packages}}<br />
{{Article summary wiki|Makepkg}}<br />
{{Article summary end}}<br />
<br />
== Before you begin ==<br />
<br />
{{Note|Packages that have been compiled by icc will depend on the associated libs contained in the '''intel-openmp''' package in order to run. Since '''intel-openmp''' depends on '''intel-compiler-base''', users MUST have both packages installed at all times!}}<br />
<br />
== Setup and installation ==<br />
<br />
{{AUR|intel-parallel-studio-xe}} are available in the [[AUR]]. To build the package, one needs a license file which is free for personal and for non-commercial use. The requisite license file is emailed to users upon [[https://registrationcenter.intel.com/RegCenter/AutoGen.aspx?ProductID=1517&AccountID=&EmailID=&ProgramID=&RequestDt=&rm=NCOM&lang= registration]] and should be copied into the $startdir prior to running makepkg. The current PKGBUILD assembles 7 or 8 packages:<br />
<br />
* '''intel-compiler-base''' - Intel C/C++ compiler and base libs<br />
* '''intel-fortran-compiler''' - Intel fortran compiler and base libs (only Parallel Studio XE)<br />
* '''intel-openmp''' - Intel OpenMP Library<br />
* intel-idb- Intel C/C++ debugger<br />
* intel-ipp - Intel Integrated Performance Primitives<br />
* intel-mkl - Intel Math Kernel Library (Intel® MKL)<br />
* intel-sourcechecker - Intel Source Checker<br />
* intel-tbb - Intel Threading Building Blocks (TBB)<br />
<br />
{{Note|A minimal working environment requires the '''intel-compiler-base''' and '''intel-openmp''' packages; if you want also the fortran compiler you must install '''intel-fortran-compiler'''.}}<br />
<br />
== Using icc with makepkg ==<br />
<br />
{{Note|Not every package will successfully compile with icc without heavy modifications to the underlying source.}}<br />
<br />
There is currently no official guide to using icc with makepkg. This section is meant to capture various methods suggested by users. Please make a new sub-section with your suggested method titled as such.<br />
<br />
=== Method 1 (12/08/2012) ===<br />
<br />
Modify {{ic|/etc/makepkg.conf}} inserting the following code ''under'' the existing line defining '''CXXFLAGS''' to enable makepkg to use icc. No special switches are needed when calling makepkg to build.<br />
<br />
{{bc|1=_CC=icc<br />
if [ $_CC = "icc" ]; then<br />
export CC="icc"<br />
export CXX="icpc"<br />
export CFLAGS="-march=native -O3 -no-prec-div -fno-alias -pipe"<br />
export CXXFLAGS="${CFLAGS}"<br />
export LDFLAGS="-Wl,-O1,--sort-common,--as-needed"<br />
export AR="xiar"<br />
export LD="xild"<br />
fi}}<br />
<br />
{{Note|<br />
* To toggle between the native gcc and icc, simple comment or uncomment the newly created '''_CC''' variable.<br />
* In some case the compilation method described above fails and the compilation will be performed with ''gcc'', so you should test if yours application has been effectively compiled with ''icc''.}}<br />
<br />
To test if your package has been really compiled with icc:<br />
<br />
* Type the command '''ldd [your_app] | grep intel''' If the application is linked to a shared object located in the directory '''/opt/intel/lib/''' it's mind that has been complied with icc.<br />
<br />
* Another method is to observe the build output and watch if it's using the ''icc'' or ''icpc'' command.<br />
<br />
* The last method is to watch if the warnings are in ''icc'' style or not.<br />
<br />
== icc CFLAGS ==<br />
<br />
In general, icc supports many of the same CFLAGS gcc supports and is also pretty tolerant to gcc flags it cannot use. In most cases it will happily ignore the flag warning the user and moving on. For an exhaustive list and explanation of available compiler flags, consult the icc manpage or better yet by invoking the compiler with the help flag:<br />
icc --help<br />
<br />
=== -xX ===<br />
<br />
Use to generate specialized code to run exclusively on processors supporting it. If unsure which option to use, simply inspect the '''flags''' section of {{ic|/proc/cpuinfo}}. In the example below, '''SSE4.1''' would be the correct selection:<br />
<br />
{{hc|$ grep -m 1 flags /proc/cpuinfo|<br />
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush <br />
dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs <br />
bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr<br />
pdcm sse4_1 lahf_lm dts tpr_shadow vnmi flexpriority<br />
}}<br />
<br />
* -xHost<br />
* -xSSE2<br />
* -xSSE3<br />
* -xSSSE3<br />
* -xSSE4.1<br />
* -xSSE4.2<br />
* -xAVX<br />
* -xCORE-AVX-I<br />
* -xSSSE3_ATOM<br />
<br />
{{Tip|Use the '''-xHost''' flag if unsure what your specific processor supports.}}<br />
<br />
=== -Ox ===<br />
<br />
Same behavior as gcc. x is one of the following options:<br />
* 0 - disables optimizations<br />
* 1 - optimize for maximum speed, but disable some optimizations which increase code size for a small speed benefit<br />
* 2 - optimize for maximum speed (DEFAULT)<br />
* 3 - optimize for maximum speed and enable more aggressive optimizations that may not improve performance on some programs (recommended for math intensive looping programs)<br />
<br />
=== -w ===<br />
<br />
Similar to the gcc:<br />
* -w - disable all warnings (recommended for the package compilation)<br />
* -Wbrief - print brief one-line diagnostics<br />
* -Wall - enable all warnings<br />
* -Werror - force warnings to be reported as errors<br />
<br />
== Software compiled with Intel C / C++ ==<br />
<br />
In the following table we report a list of packages from the officials repository that we have tried to compile with the intel C/C++ compiler. The compilation should be done by using the PKGBUILD from ABS.<br />
<br />
<br />
{| class="wikitable sortable collapsible" border="1" border="1"<br />
|-style="background: #ffdead;" <br />
! Application || Compile || Comments<br />
<br />
|-<br />
| '''xvidcore''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''kdebase''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''conky 1.9.0''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''nginx 1.4.2''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''gzip 1.6''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''xz''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''lz4''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''minetest''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''opus''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''zlib 1.2.8''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''Gimp 2.8''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''Pacman 4.0.3''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''x264''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''MySql''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''SqlLite''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''lame''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''xaos''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''VLC''' || style="background: Tomato" | Unsuccessful || There's some problem with the compiler flags<br />
|-<br />
| '''bzip2''' || style="background: Tomato" | Unsuccessful || There's some problem with the compiler flags<br />
|-<br />
| '''mplayer''' || style="background: pink" | Out of date || It don't recognize the Intel compiler<br />
|-<br />
| '''optipng''' || style="background: GreenYellow" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]. Comment out LD=xild in makepkg.conf<br />
|-<br />
| '''python-numpy''' || style="background: GreenYellow" | OK || We must edit the PKGBUILD. {{AUR|python-numpy-mkl}}<br />
|-<br />
| '''python-scipy''' || style="background: GreenYellow" | OK || We must edit the PKGBUILD. {{AUR|python-scipy-mkl}}<br />
|-<br />
| '''Qt''' || style="background: GreenYellow" | OK || We must add the option ''-platform linux-icc-64 (or 32)'' in the configure command <br />
|-<br />
| '''systemd''' || style="background: red" | Fail ||undefined reference to `server_dispatch_message'<br />
|}<br />
<br />
'''Legend:'''<br />
{|<br />
|-<br />
| style="background: Lime" | OK || The compilation with ICC works!<br />
|-<br />
| style="background: GreenYellow" | OK || The compilation works but is needed an editing of the PKGBUILD<br />
|-<br />
| style="background: Tomato" | Unsuccessful || The compilation may work, but there are some compilations errors.<br />
|-<br />
| style="background: yellow" | Not recommended || The compilation works, but is not recommended <br />
|-<br />
| style="background: red" | Fail || It's impossible to compile the PKG with ICC.<br />
|-<br />
| style="background: pink" | Out of date || It's unsuccessful or fails with older CFLAGS. You can try compiling it with new [[Intel_C++#Method_1 | Method 1]].(Don't forget to paste your result here!)<br />
|}</div>Swiftiehttps://wiki.archlinux.org/index.php?title=Intel_C%2B%2B&diff=280118Intel C++2013-10-28T10:49:26Z<p>Swiftie: /* Software compiled with Intel C / C++ */</p>
<hr />
<div>[[Category:Development]]<br />
[[it:Intel C++]]<br />
[[zh-CN:Intel C++]]<br />
{{Article summary start}}<br />
{{Article summary text|Installation and basic usage of Intel® C++ Composer XE (formerly Intel® C++ Compiler Professional Edition) for Linux on Arch.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|ABS}}<br />
{{Article summary wiki|Creating Packages}}<br />
{{Article summary wiki|Makepkg}}<br />
{{Article summary end}}<br />
<br />
== Before you begin ==<br />
<br />
{{Note|Packages that have been compiled by icc will depend on the associated libs contained in the '''intel-openmp''' package in order to run. Since '''intel-openmp''' depends on '''intel-compiler-base''', users MUST have both packages installed at all times!}}<br />
<br />
== Setup and installation ==<br />
<br />
{{AUR|intel-parallel-studio-xe}} are available in the [[AUR]]. To build the package, one needs a license file which is free for personal and for non-commercial use. The requisite license file is emailed to users upon [[https://registrationcenter.intel.com/RegCenter/AutoGen.aspx?ProductID=1517&AccountID=&EmailID=&ProgramID=&RequestDt=&rm=NCOM&lang= registration]] and should be copied into the $startdir prior to running makepkg. The current PKGBUILD assembles 7 or 8 packages:<br />
<br />
* '''intel-compiler-base''' - Intel C/C++ compiler and base libs<br />
* '''intel-fortran-compiler''' - Intel fortran compiler and base libs (only Parallel Studio XE)<br />
* '''intel-openmp''' - Intel OpenMP Library<br />
* intel-idb- Intel C/C++ debugger<br />
* intel-ipp - Intel Integrated Performance Primitives<br />
* intel-mkl - Intel Math Kernel Library (Intel® MKL)<br />
* intel-sourcechecker - Intel Source Checker<br />
* intel-tbb - Intel Threading Building Blocks (TBB)<br />
<br />
{{Note|A minimal working environment requires the '''intel-compiler-base''' and '''intel-openmp''' packages; if you want also the fortran compiler you must install '''intel-fortran-compiler'''.}}<br />
<br />
== Using icc with makepkg ==<br />
<br />
{{Note|Not every package will successfully compile with icc without heavy modifications to the underlying source.}}<br />
<br />
There is currently no official guide to using icc with makepkg. This section is meant to capture various methods suggested by users. Please make a new sub-section with your suggested method titled as such.<br />
<br />
=== Method 1 (12/08/2012) ===<br />
<br />
Modify {{ic|/etc/makepkg.conf}} inserting the following code ''under'' the existing line defining '''CXXFLAGS''' to enable makepkg to use icc. No special switches are needed when calling makepkg to build.<br />
<br />
{{bc|1=_CC=icc<br />
if [ $_CC = "icc" ]; then<br />
export CC="icc"<br />
export CXX="icpc"<br />
export CFLAGS="-march=native -O3 -no-prec-div -fno-alias -pipe"<br />
export CXXFLAGS="${CFLAGS}"<br />
export LDFLAGS="-Wl,-O1,--sort-common,--as-needed"<br />
export AR="xiar"<br />
export LD="xild"<br />
fi}}<br />
<br />
{{Note|<br />
* To toggle between the native gcc and icc, simple comment or uncomment the newly created '''_CC''' variable.<br />
* In some case the compilation method described above fails and the compilation will be performed with ''gcc'', so you should test if yours application has been effectively compiled with ''icc''.}}<br />
<br />
To test if your package has been really compiled with icc:<br />
<br />
* Type the command '''ldd [your_app] | grep intel''' If the application is linked to a shared object located in the directory '''/opt/intel/lib/''' it's mind that has been complied with icc.<br />
<br />
* Another method is to observe the build output and watch if it's using the ''icc'' or ''icpc'' command.<br />
<br />
* The last method is to watch if the warnings are in ''icc'' style or not.<br />
<br />
== icc CFLAGS ==<br />
<br />
In general, icc supports many of the same CFLAGS gcc supports and is also pretty tolerant to gcc flags it cannot use. In most cases it will happily ignore the flag warning the user and moving on. For an exhaustive list and explanation of available compiler flags, consult the icc manpage or better yet by invoking the compiler with the help flag:<br />
icc --help<br />
<br />
=== -xX ===<br />
<br />
Use to generate specialized code to run exclusively on processors supporting it. If unsure which option to use, simply inspect the '''flags''' section of {{ic|/proc/cpuinfo}}. In the example below, '''SSE4.1''' would be the correct selection:<br />
<br />
{{hc|$ grep -m 1 flags /proc/cpuinfo|<br />
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush <br />
dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs <br />
bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr<br />
pdcm sse4_1 lahf_lm dts tpr_shadow vnmi flexpriority<br />
}}<br />
<br />
* -xHost<br />
* -xSSE2<br />
* -xSSE3<br />
* -xSSSE3<br />
* -xSSE4.1<br />
* -xSSE4.2<br />
* -xAVX<br />
* -xCORE-AVX-I<br />
* -xSSSE3_ATOM<br />
<br />
{{Tip|Use the '''-xHost''' flag if unsure what your specific processor supports.}}<br />
<br />
=== -Ox ===<br />
<br />
Same behavior as gcc. x is one of the following options:<br />
* 0 - disables optimizations<br />
* 1 - optimize for maximum speed, but disable some optimizations which increase code size for a small speed benefit<br />
* 2 - optimize for maximum speed (DEFAULT)<br />
* 3 - optimize for maximum speed and enable more aggressive optimizations that may not improve performance on some programs (recommended for math intensive looping programs)<br />
<br />
=== -w ===<br />
<br />
Similar to the gcc:<br />
* -w - disable all warnings (recommended for the package compilation)<br />
* -Wbrief - print brief one-line diagnostics<br />
* -Wall - enable all warnings<br />
* -Werror - force warnings to be reported as errors<br />
<br />
== Software compiled with Intel C / C++ ==<br />
<br />
In the following table we report a list of packages from the officials repository that we have tried to compile with the intel C/C++ compiler. The compilation should be done by using the PKGBUILD from ABS.<br />
<br />
<br />
{| class="wikitable sortable collapsible" border="1" border="1"<br />
|-style="background: #ffdead;" <br />
! Application || Compile || Comments<br />
<br />
|-<br />
| '''kdebase''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''conky 1.9.0''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''nginx 1.4.2''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''gzip 1.6''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''xz''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''lz4''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''minetest''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''opus''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''zlib 1.2.8''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''Gimp 2.8''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''Pacman 4.0.3''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''x264''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''MySql''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''SqlLite''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''lame''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''xaos''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''VLC''' || style="background: Tomato" | Unsuccessful || There's some problem with the compiler flags<br />
|-<br />
| '''bzip2''' || style="background: Tomato" | Unsuccessful || There's some problem with the compiler flags<br />
|-<br />
| '''mplayer''' || style="background: pink" | Out of date || It don't recognize the Intel compiler<br />
|-<br />
| '''optipng''' || style="background: GreenYellow" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]. Comment out LD=xild in makepkg.conf<br />
|-<br />
| '''python-numpy''' || style="background: GreenYellow" | OK || We must edit the PKGBUILD. {{AUR|python-numpy-mkl}}<br />
|-<br />
| '''python-scipy''' || style="background: GreenYellow" | OK || We must edit the PKGBUILD. {{AUR|python-scipy-mkl}}<br />
|-<br />
| '''Qt''' || style="background: GreenYellow" | OK || We must add the option ''-platform linux-icc-64 (or 32)'' in the configure command <br />
|-<br />
| '''systemd''' || style="background: red" | Fail ||undefined reference to `server_dispatch_message'<br />
|}<br />
<br />
'''Legend:'''<br />
{|<br />
|-<br />
| style="background: Lime" | OK || The compilation with ICC works!<br />
|-<br />
| style="background: GreenYellow" | OK || The compilation works but is needed an editing of the PKGBUILD<br />
|-<br />
| style="background: Tomato" | Unsuccessful || The compilation may work, but there are some compilations errors.<br />
|-<br />
| style="background: yellow" | Not recommended || The compilation works, but is not recommended <br />
|-<br />
| style="background: red" | Fail || It's impossible to compile the PKG with ICC.<br />
|-<br />
| style="background: pink" | Out of date || It's unsuccessful or fails with older CFLAGS. You can try compiling it with new [[Intel_C++#Method_1 | Method 1]].(Don't forget to paste your result here!)<br />
|}</div>Swiftiehttps://wiki.archlinux.org/index.php?title=Intel_C%2B%2B&diff=280117Intel C++2013-10-28T10:43:11Z<p>Swiftie: /* Software compiled with Intel C / C++ */</p>
<hr />
<div>[[Category:Development]]<br />
[[it:Intel C++]]<br />
[[zh-CN:Intel C++]]<br />
{{Article summary start}}<br />
{{Article summary text|Installation and basic usage of Intel® C++ Composer XE (formerly Intel® C++ Compiler Professional Edition) for Linux on Arch.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|ABS}}<br />
{{Article summary wiki|Creating Packages}}<br />
{{Article summary wiki|Makepkg}}<br />
{{Article summary end}}<br />
<br />
== Before you begin ==<br />
<br />
{{Note|Packages that have been compiled by icc will depend on the associated libs contained in the '''intel-openmp''' package in order to run. Since '''intel-openmp''' depends on '''intel-compiler-base''', users MUST have both packages installed at all times!}}<br />
<br />
== Setup and installation ==<br />
<br />
{{AUR|intel-parallel-studio-xe}} are available in the [[AUR]]. To build the package, one needs a license file which is free for personal and for non-commercial use. The requisite license file is emailed to users upon [[https://registrationcenter.intel.com/RegCenter/AutoGen.aspx?ProductID=1517&AccountID=&EmailID=&ProgramID=&RequestDt=&rm=NCOM&lang= registration]] and should be copied into the $startdir prior to running makepkg. The current PKGBUILD assembles 7 or 8 packages:<br />
<br />
* '''intel-compiler-base''' - Intel C/C++ compiler and base libs<br />
* '''intel-fortran-compiler''' - Intel fortran compiler and base libs (only Parallel Studio XE)<br />
* '''intel-openmp''' - Intel OpenMP Library<br />
* intel-idb- Intel C/C++ debugger<br />
* intel-ipp - Intel Integrated Performance Primitives<br />
* intel-mkl - Intel Math Kernel Library (Intel® MKL)<br />
* intel-sourcechecker - Intel Source Checker<br />
* intel-tbb - Intel Threading Building Blocks (TBB)<br />
<br />
{{Note|A minimal working environment requires the '''intel-compiler-base''' and '''intel-openmp''' packages; if you want also the fortran compiler you must install '''intel-fortran-compiler'''.}}<br />
<br />
== Using icc with makepkg ==<br />
<br />
{{Note|Not every package will successfully compile with icc without heavy modifications to the underlying source.}}<br />
<br />
There is currently no official guide to using icc with makepkg. This section is meant to capture various methods suggested by users. Please make a new sub-section with your suggested method titled as such.<br />
<br />
=== Method 1 (12/08/2012) ===<br />
<br />
Modify {{ic|/etc/makepkg.conf}} inserting the following code ''under'' the existing line defining '''CXXFLAGS''' to enable makepkg to use icc. No special switches are needed when calling makepkg to build.<br />
<br />
{{bc|1=_CC=icc<br />
if [ $_CC = "icc" ]; then<br />
export CC="icc"<br />
export CXX="icpc"<br />
export CFLAGS="-march=native -O3 -no-prec-div -fno-alias -pipe"<br />
export CXXFLAGS="${CFLAGS}"<br />
export LDFLAGS="-Wl,-O1,--sort-common,--as-needed"<br />
export AR="xiar"<br />
export LD="xild"<br />
fi}}<br />
<br />
{{Note|<br />
* To toggle between the native gcc and icc, simple comment or uncomment the newly created '''_CC''' variable.<br />
* In some case the compilation method described above fails and the compilation will be performed with ''gcc'', so you should test if yours application has been effectively compiled with ''icc''.}}<br />
<br />
To test if your package has been really compiled with icc:<br />
<br />
* Type the command '''ldd [your_app] | grep intel''' If the application is linked to a shared object located in the directory '''/opt/intel/lib/''' it's mind that has been complied with icc.<br />
<br />
* Another method is to observe the build output and watch if it's using the ''icc'' or ''icpc'' command.<br />
<br />
* The last method is to watch if the warnings are in ''icc'' style or not.<br />
<br />
== icc CFLAGS ==<br />
<br />
In general, icc supports many of the same CFLAGS gcc supports and is also pretty tolerant to gcc flags it cannot use. In most cases it will happily ignore the flag warning the user and moving on. For an exhaustive list and explanation of available compiler flags, consult the icc manpage or better yet by invoking the compiler with the help flag:<br />
icc --help<br />
<br />
=== -xX ===<br />
<br />
Use to generate specialized code to run exclusively on processors supporting it. If unsure which option to use, simply inspect the '''flags''' section of {{ic|/proc/cpuinfo}}. In the example below, '''SSE4.1''' would be the correct selection:<br />
<br />
{{hc|$ grep -m 1 flags /proc/cpuinfo|<br />
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush <br />
dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs <br />
bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr<br />
pdcm sse4_1 lahf_lm dts tpr_shadow vnmi flexpriority<br />
}}<br />
<br />
* -xHost<br />
* -xSSE2<br />
* -xSSE3<br />
* -xSSSE3<br />
* -xSSE4.1<br />
* -xSSE4.2<br />
* -xAVX<br />
* -xCORE-AVX-I<br />
* -xSSSE3_ATOM<br />
<br />
{{Tip|Use the '''-xHost''' flag if unsure what your specific processor supports.}}<br />
<br />
=== -Ox ===<br />
<br />
Same behavior as gcc. x is one of the following options:<br />
* 0 - disables optimizations<br />
* 1 - optimize for maximum speed, but disable some optimizations which increase code size for a small speed benefit<br />
* 2 - optimize for maximum speed (DEFAULT)<br />
* 3 - optimize for maximum speed and enable more aggressive optimizations that may not improve performance on some programs (recommended for math intensive looping programs)<br />
<br />
=== -w ===<br />
<br />
Similar to the gcc:<br />
* -w - disable all warnings (recommended for the package compilation)<br />
* -Wbrief - print brief one-line diagnostics<br />
* -Wall - enable all warnings<br />
* -Werror - force warnings to be reported as errors<br />
<br />
== Software compiled with Intel C / C++ ==<br />
<br />
In the following table we report a list of packages from the officials repository that we have tried to compile with the intel C/C++ compiler. The compilation should be done by using the PKGBUILD from ABS.<br />
<br />
<br />
{| class="wikitable sortable collapsible" border="1" border="1"<br />
|-style="background: #ffdead;" <br />
! Application || Compile || Comments<br />
<br />
|-<br />
| '''kdebase''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''conky 1.9.0''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''nginx 1.4.2''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''gzip 1.6''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''xz''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''lz4''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''minetest''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''opus''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''zlib''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''Gimp 2.8''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''Pacman 4.0.3''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''x264''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''MySql''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''SqlLite''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''lame''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''xaos''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''VLC''' || style="background: Tomato" | Unsuccessful || There's some problem with the compiler flags<br />
|-<br />
| '''bzip2''' || style="background: Tomato" | Unsuccessful || There's some problem with the compiler flags<br />
|-<br />
| '''mplayer''' || style="background: pink" | Out of date || It don't recognize the Intel compiler<br />
|-<br />
| '''optipng''' || style="background: GreenYellow" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]. Comment out LD=xild in makepkg.conf<br />
|-<br />
| '''python-numpy''' || style="background: GreenYellow" | OK || We must edit the PKGBUILD. {{AUR|python-numpy-mkl}}<br />
|-<br />
| '''python-scipy''' || style="background: GreenYellow" | OK || We must edit the PKGBUILD. {{AUR|python-scipy-mkl}}<br />
|-<br />
| '''Qt''' || style="background: GreenYellow" | OK || We must add the option ''-platform linux-icc-64 (or 32)'' in the configure command <br />
|-<br />
| '''systemd''' || style="background: red" | Fail ||undefined reference to `server_dispatch_message'<br />
|}<br />
<br />
'''Legend:'''<br />
{|<br />
|-<br />
| style="background: Lime" | OK || The compilation with ICC works!<br />
|-<br />
| style="background: GreenYellow" | OK || The compilation works but is needed an editing of the PKGBUILD<br />
|-<br />
| style="background: Tomato" | Unsuccessful || The compilation may work, but there are some compilations errors.<br />
|-<br />
| style="background: yellow" | Not recommended || The compilation works, but is not recommended <br />
|-<br />
| style="background: red" | Fail || It's impossible to compile the PKG with ICC.<br />
|-<br />
| style="background: pink" | Out of date || It's unsuccessful or fails with older CFLAGS. You can try compiling it with new [[Intel_C++#Method_1 | Method 1]].(Don't forget to paste your result here!)<br />
|}</div>Swiftiehttps://wiki.archlinux.org/index.php?title=Intel_C%2B%2B&diff=277479Intel C++2013-10-03T21:09:35Z<p>Swiftie: /* Software compiled with Intel C / C++ */</p>
<hr />
<div>[[Category:Development]]<br />
[[it:Intel C++]]<br />
[[zh-CN:Intel C++]]<br />
{{Article summary start}}<br />
{{Article summary text|Installation and basic usage of Intel® C++ Composer XE (formerly Intel® C++ Compiler Professional Edition) for Linux on Arch.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|ABS}}<br />
{{Article summary wiki|Creating Packages}}<br />
{{Article summary wiki|Makepkg}}<br />
{{Article summary end}}<br />
<br />
== Before you begin ==<br />
<br />
{{Note|Packages that have been compiled by icc will depend on the associated libs contained in the '''intel-openmp''' package in order to run. Since '''intel-openmp''' depends on '''intel-compiler-base''', users MUST have both packages installed at all times!}}<br />
<br />
== Setup and installation ==<br />
<br />
{{AUR|intel-parallel-studio-xe}} are available in the [[AUR]]. To build the package, one needs a license file which is free for personal and for non-commercial use. The requisite license file is emailed to users upon [[https://registrationcenter.intel.com/RegCenter/AutoGen.aspx?ProductID=1517&AccountID=&EmailID=&ProgramID=&RequestDt=&rm=NCOM&lang= registration]] and should be copied into the $startdir prior to running makepkg. The current PKGBUILD assembles 7 or 8 packages:<br />
<br />
* '''intel-compiler-base''' - Intel C/C++ compiler and base libs<br />
* '''intel-fortran-compiler''' - Intel fortran compiler and base libs (only Parallel Studio XE)<br />
* '''intel-openmp''' - Intel OpenMP Library<br />
* intel-idb- Intel C/C++ debugger<br />
* intel-ipp - Intel Integrated Performance Primitives<br />
* intel-mkl - Intel Math Kernel Library (Intel® MKL)<br />
* intel-sourcechecker - Intel Source Checker<br />
* intel-tbb - Intel Threading Building Blocks (TBB)<br />
<br />
{{Note|A minimal working environment requires the '''intel-compiler-base''' and '''intel-openmp''' packages; if you want also the fortran compiler you must install '''intel-fortran-compiler'''.}}<br />
<br />
== Using icc with makepkg ==<br />
<br />
{{Note|Not every package will successfully compile with icc without heavy modifications to the underlying source.}}<br />
<br />
There is currently no official guide to using icc with makepkg. This section is meant to capture various methods suggested by users. Please make a new sub-section with your suggested method titled as such.<br />
<br />
=== Method 1 (12/08/2012) ===<br />
<br />
Modify {{ic|/etc/makepkg.conf}} inserting the following code ''under'' the existing line defining '''CXXFLAGS''' to enable makepkg to use icc. No special switches are needed when calling makepkg to build.<br />
<br />
{{bc|1=_CC=icc<br />
if [ $_CC = "icc" ]; then<br />
export CC="icc"<br />
export CXX="icpc"<br />
export CFLAGS="-march=native -O3 -no-prec-div -fno-alias -pipe"<br />
export CXXFLAGS="${CFLAGS}"<br />
export LDFLAGS="-Wl,-O1,--sort-common,--as-needed"<br />
export AR="xiar"<br />
export LD="xild"<br />
fi}}<br />
<br />
{{Note|<br />
* To toggle between the native gcc and icc, simple comment or uncomment the newly created '''_CC''' variable.<br />
* In some case the compilation method described above fails and the compilation will be performed with ''gcc'', so you should test if yours application has been effectively compiled with ''icc''.}}<br />
<br />
To test if your package has been really compiled with icc:<br />
<br />
* Type the command '''ldd [your_app] | grep intel''' If the application is linked to a shared object located in the directory '''/opt/intel/lib/''' it's mind that has been complied with icc.<br />
<br />
* Another method is to observe the build output and watch if it's using the ''icc'' or ''icpc'' command.<br />
<br />
* The last method is to watch if the warnings are in ''icc'' style or not.<br />
<br />
== icc CFLAGS ==<br />
<br />
In general, icc supports many of the same CFLAGS gcc supports and is also pretty tolerant to gcc flags it cannot use. In most cases it will happily ignore the flag warning the user and moving on. For an exhaustive list and explanation of available compiler flags, consult the icc manpage or better yet by invoking the compiler with the help flag:<br />
icc --help<br />
<br />
=== -xX ===<br />
<br />
Use to generate specialized code to run exclusively on processors supporting it. If unsure which option to use, simply inspect the '''flags''' section of {{ic|/proc/cpuinfo}}. In the example below, '''SSE4.1''' would be the correct selection:<br />
<br />
{{hc|$ grep -m 1 flags /proc/cpuinfo|<br />
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush <br />
dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs <br />
bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr<br />
pdcm sse4_1 lahf_lm dts tpr_shadow vnmi flexpriority<br />
}}<br />
<br />
* -xHost<br />
* -xSSE2<br />
* -xSSE3<br />
* -xSSSE3<br />
* -xSSE4.1<br />
* -xSSE4.2<br />
* -xAVX<br />
* -xCORE-AVX-I<br />
* -xSSSE3_ATOM<br />
<br />
{{Tip|Use the '''-xHost''' flag if unsure what your specific processor supports.}}<br />
<br />
=== -Ox ===<br />
<br />
Same behavior as gcc. x is one of the following options:<br />
* 0 - disables optimizations<br />
* 1 - optimize for maximum speed, but disable some optimizations which increase code size for a small speed benefit<br />
* 2 - optimize for maximum speed (DEFAULT)<br />
* 3 - optimize for maximum speed and enable more aggressive optimizations that may not improve performance on some programs (recommended for math intensive looping programs)<br />
<br />
=== -w ===<br />
<br />
Similar to the gcc:<br />
* -w - disable all warnings (recommended for the package compilation)<br />
* -Wbrief - print brief one-line diagnostics<br />
* -Wall - enable all warnings<br />
* -Werror - force warnings to be reported as errors<br />
<br />
== Software compiled with Intel C / C++ ==<br />
<br />
In the following table we report a list of packages from the officials repository that we have tried to compile with the intel C/C++ compiler. The compilation should be done by using the PKGBUILD from ABS.<br />
<br />
<br />
{| class="wikitable sortable collapsible" border="1" border="1"<br />
|-style="background: #ffdead;" <br />
! Application || Compile || Comments<br />
<br />
|-<br />
| '''conky 1.9.0''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''nginx 1.4.2''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''gzip 1.6''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''xz''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''lz4''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''minetest''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''opus''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''zlib''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''Gimp 2.8''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''Pacman 4.0.3''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''x264''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''MySql''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''SqlLite''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''lame''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''xaos''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''VLC''' || style="background: Tomato" | Unsuccessful || There's some problem with the compiler flags<br />
|-<br />
| '''bzip2''' || style="background: Tomato" | Unsuccessful || There's some problem with the compiler flags<br />
|-<br />
| '''mplayer''' || style="background: pink" | Out of date || It don't recognize the Intel compiler<br />
|-<br />
| '''optipng''' || style="background: GreenYellow" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]. Comment out LD=xild in makepkg.conf<br />
|-<br />
| '''python-numpy''' || style="background: GreenYellow" | OK || We must edit the PKGBUILD. {{AUR|python-numpy-mkl}}<br />
|-<br />
| '''python-scipy''' || style="background: GreenYellow" | OK || We must edit the PKGBUILD. {{AUR|python-scipy-mkl}}<br />
|-<br />
| '''Qt''' || style="background: GreenYellow" | OK || We must add the option ''-platform linux-icc-64 (or 32)'' in the configure command <br />
|-<br />
| '''systemd''' || style="background: red" | Fail ||undefined reference to `server_dispatch_message'<br />
|}<br />
<br />
'''Legend:'''<br />
{|<br />
|-<br />
| style="background: Lime" | OK || The compilation with ICC works!<br />
|-<br />
| style="background: GreenYellow" | OK || The compilation works but is needed an editing of the PKGBUILD<br />
|-<br />
| style="background: Tomato" | Unsuccessful || The compilation may work, but there are some compilations errors.<br />
|-<br />
| style="background: yellow" | Not recommended || The compilation works, but is not recommended <br />
|-<br />
| style="background: red" | Fail || It's impossible to compile the PKG with ICC.<br />
|-<br />
| style="background: pink" | Out of date || It's unsuccessful or fails with older CFLAGS. You can try compiling it with new [[Intel_C++#Method_1 | Method 1]].(Don't forget to paste your result here!)<br />
|}</div>Swiftiehttps://wiki.archlinux.org/index.php?title=Intel_C%2B%2B&diff=277026Intel C++2013-09-29T10:40:03Z<p>Swiftie: /* Software compiled with Intel C / C++ */</p>
<hr />
<div>[[Category:Development]]<br />
[[it:Intel C++]]<br />
[[zh-CN:Intel C++]]<br />
{{Article summary start}}<br />
{{Article summary text|Installation and basic usage of Intel® C++ Composer XE (formerly Intel® C++ Compiler Professional Edition) for Linux on Arch.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|ABS}}<br />
{{Article summary wiki|Creating Packages}}<br />
{{Article summary wiki|Makepkg}}<br />
{{Article summary end}}<br />
<br />
== Before you begin ==<br />
<br />
{{Note|Packages that have been compiled by icc will depend on the associated libs contained in the '''intel-openmp''' package in order to run. Since '''intel-openmp''' depends on '''intel-compiler-base''', users MUST have both packages installed at all times!}}<br />
<br />
== Setup and installation ==<br />
<br />
{{AUR|intel-parallel-studio-xe}} are available in the [[AUR]]. To build the package, one needs a license file which is free for personal and for non-commercial use. The requisite license file is emailed to users upon [[https://registrationcenter.intel.com/RegCenter/AutoGen.aspx?ProductID=1517&AccountID=&EmailID=&ProgramID=&RequestDt=&rm=NCOM&lang= registration]] and should be copied into the $startdir prior to running makepkg. The current PKGBUILD assembles 7 or 8 packages:<br />
<br />
* '''intel-compiler-base''' - Intel C/C++ compiler and base libs<br />
* '''intel-fortran-compiler''' - Intel fortran compiler and base libs (only Parallel Studio XE)<br />
* '''intel-openmp''' - Intel OpenMP Library<br />
* intel-idb- Intel C/C++ debugger<br />
* intel-ipp - Intel Integrated Performance Primitives<br />
* intel-mkl - Intel Math Kernel Library (Intel® MKL)<br />
* intel-sourcechecker - Intel Source Checker<br />
* intel-tbb - Intel Threading Building Blocks (TBB)<br />
<br />
{{Note|A minimal working environment requires the '''intel-compiler-base''' and '''intel-openmp''' packages; if you want also the fortran compiler you must install '''intel-fortran-compiler'''.}}<br />
<br />
== Using icc with makepkg ==<br />
<br />
{{Note|Not every package will successfully compile with icc without heavy modifications to the underlying source.}}<br />
<br />
There is currently no official guide to using icc with makepkg. This section is meant to capture various methods suggested by users. Please make a new sub-section with your suggested method titled as such.<br />
<br />
=== Method 1 (12/08/2012) ===<br />
<br />
Modify {{ic|/etc/makepkg.conf}} inserting the following code ''under'' the existing line defining '''CXXFLAGS''' to enable makepkg to use icc. No special switches are needed when calling makepkg to build.<br />
<br />
{{bc|1=_CC=icc<br />
if [ $_CC = "icc" ]; then<br />
export CC="icc"<br />
export CXX="icpc"<br />
export CFLAGS="-march=native -O3 -no-prec-div -fno-alias -pipe"<br />
export CXXFLAGS="${CFLAGS}"<br />
export LDFLAGS="-Wl,-O1,--sort-common,--as-needed"<br />
export AR="xiar"<br />
export LD="xild"<br />
fi}}<br />
<br />
{{Note|<br />
* To toggle between the native gcc and icc, simple comment or uncomment the newly created '''_CC''' variable.<br />
* In some case the compilation method described above fails and the compilation will be performed with ''gcc'', so you should test if yours application has been effectively compiled with ''icc''.}}<br />
<br />
To test if your package has been really compiled with icc:<br />
<br />
* Type the command '''ldd [your_app] | grep intel''' If the application is linked to a shared object located in the directory '''/opt/intel/lib/''' it's mind that has been complied with icc.<br />
<br />
* Another method is to observe the build output and watch if it's using the ''icc'' or ''icpc'' command.<br />
<br />
* The last method is to watch if the warnings are in ''icc'' style or not.<br />
<br />
== icc CFLAGS ==<br />
<br />
In general, icc supports many of the same CFLAGS gcc supports and is also pretty tolerant to gcc flags it cannot use. In most cases it will happily ignore the flag warning the user and moving on. For an exhaustive list and explanation of available compiler flags, consult the icc manpage or better yet by invoking the compiler with the help flag:<br />
icc --help<br />
<br />
=== -xX ===<br />
<br />
Use to generate specialized code to run exclusively on processors supporting it. If unsure which option to use, simply inspect the '''flags''' section of {{ic|/proc/cpuinfo}}. In the example below, '''SSE4.1''' would be the correct selection:<br />
<br />
{{hc|$ grep -m 1 flags /proc/cpuinfo|<br />
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush <br />
dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs <br />
bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr<br />
pdcm sse4_1 lahf_lm dts tpr_shadow vnmi flexpriority<br />
}}<br />
<br />
* -xHost<br />
* -xSSE2<br />
* -xSSE3<br />
* -xSSSE3<br />
* -xSSE4.1<br />
* -xSSE4.2<br />
* -xAVX<br />
* -xCORE-AVX-I<br />
* -xSSSE3_ATOM<br />
<br />
{{Tip|Use the '''-xHost''' flag if unsure what your specific processor supports.}}<br />
<br />
=== -Ox ===<br />
<br />
Same behavior as gcc. x is one of the following options:<br />
* 0 - disables optimizations<br />
* 1 - optimize for maximum speed, but disable some optimizations which increase code size for a small speed benefit<br />
* 2 - optimize for maximum speed (DEFAULT)<br />
* 3 - optimize for maximum speed and enable more aggressive optimizations that may not improve performance on some programs (recommended for math intensive looping programs)<br />
<br />
=== -w ===<br />
<br />
Similar to the gcc:<br />
* -w - disable all warnings (recommended for the package compilation)<br />
* -Wbrief - print brief one-line diagnostics<br />
* -Wall - enable all warnings<br />
* -Werror - force warnings to be reported as errors<br />
<br />
== Software compiled with Intel C / C++ ==<br />
<br />
In the following table we report a list of packages from the officials repository that we have tried to compile with the intel C/C++ compiler. The compilation should be done by using the PKGBUILD from ABS.<br />
<br />
<br />
{| class="wikitable sortable collapsible" border="1" border="1"<br />
|-style="background: #ffdead;" <br />
! Application || Compile || Comments<br />
<br />
|-<br />
| '''conky 1.9.0''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''xz''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''minetest''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''opus''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''zlib''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''Gimp 2.8''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''Pacman 4.0.3''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''x264''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''MySql''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''SqlLite''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''lame''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''xaos''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''VLC''' || style="background: Tomato" | Unsuccessful || There's some problem with the compiler flags<br />
|-<br />
| '''bzip2''' || style="background: Tomato" | Unsuccessful || There's some problem with the compiler flags<br />
|-<br />
| '''mplayer''' || style="background: pink" | Out of date || It don't recognize the Intel compiler<br />
|-<br />
| '''optipng''' || style="background: GreenYellow" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]. Comment out LD=xild in makepkg.conf<br />
|-<br />
| '''python-numpy''' || style="background: GreenYellow" | OK || We must edit the PKGBUILD. {{AUR|python-numpy-mkl}}<br />
|-<br />
| '''python-scipy''' || style="background: GreenYellow" | OK || We must edit the PKGBUILD. {{AUR|python-scipy-mkl}}<br />
|-<br />
| '''Qt''' || style="background: GreenYellow" | OK || We must add the option ''-platform linux-icc-64 (or 32)'' in the configure command <br />
|-<br />
| '''systemd''' || style="background: red" | Fail ||undefined reference to `server_dispatch_message'<br />
|}<br />
<br />
'''Legend:'''<br />
{|<br />
|-<br />
| style="background: Lime" | OK || The compilation with ICC works!<br />
|-<br />
| style="background: GreenYellow" | OK || The compilation works but is needed an editing of the PKGBUILD<br />
|-<br />
| style="background: Tomato" | Unsuccessful || The compilation may work, but there are some compilations errors.<br />
|-<br />
| style="background: yellow" | Not recommended || The compilation works, but is not recommended <br />
|-<br />
| style="background: red" | Fail || It's impossible to compile the PKG with ICC.<br />
|-<br />
| style="background: pink" | Out of date || It's unsuccessful or fails with older CFLAGS. You can try compiling it with new [[Intel_C++#Method_1 | Method 1]].(Don't forget to paste your result here!)<br />
|}</div>Swiftiehttps://wiki.archlinux.org/index.php?title=DSDT&diff=268049DSDT2013-07-26T12:35:13Z<p>Swiftie: </p>
<hr />
<div>[[Category:Boot process]]<br />
[[Category:Kernel]]<br />
[[Category:Power management]]<br />
DSDT (Differentiated System Description Table) is a part of the [[Wikipedia:ACPI|ACPI]] specification. It supplies information about supported power events in a given system. ACPI tables are provided in firmware from the manufacturer. A common Linux problems are missing ACPI functionality, such as: fans not running, screens not turning off when the lid is closed, etc. This can stem from DSDTs made with Windows specifically in mind, which can be patched after installation. The goal of this article is to analyze and rebuild a faulty DSDT, so that the kernel can override the default one.<br />
<br />
Basically a DSDT table is the code run on ACPI (Power Management) events.<br />
<br />
{{Note|The goal of the [http://www.lesswatts.org/projects/acpi/ Linux ACPI] project is that Linux should work on unmodified firmware. If you still find this type of workaround necessary on modern kernels then you should consider [[Reporting Bug Guidelines|submiting a bug report]]. }}<br />
<br />
==Before you start...==<br />
* It is possible that the hardware manufacturer has released an updated firmware which fixes ACPI related problems. Installing an updated firmware is often preferred over this method because it would avoid duplication of effort.<br />
* This process does tamper with some fairly fundamental code on your installation. You will want to be absolutely sure of the changes you make. You might also wish to [[Disk cloning | clone your disk]] beforehand.<br />
* Even before attempting to fix your DSDT yourself, you can attempt a couple of different shortcuts: <br />
<br />
===Tell the kernel to report a version of Windows===<br />
<br />
Use the variable '''acpi_os_name''' as a kernel parameter. For example:<br />
<br />
acpi_os_name="Microsoft Windows NT"<br />
<br />
Or<br />
<br />
acpi_osi="!Windows2012"<br />
appended to the kernel line in grub legacy configuration<br />
<br />
other strings to test:<br />
* "Microsoft Windows XP"<br />
* "Microsoft Windows 2000"<br />
* "Microsoft Windows 2000.1"<br />
* "Microsoft Windows ME: Millennium Edition"<br />
* "Windows 2001"<br />
* "Windows 2006"<br />
* "Windows 2009"<br />
* "Windows 2012"<br />
* when all that fails, you can even try "Linux"<br />
<br />
Out of curiousity, you can follow the steps below to extract your DSDT and search the .dsl file. Just grep for "Windows" and see what pops up.<br />
<br />
===Find a fixed DSDT===<br />
A DSDT file is originally written in ACPI Source language (an .asl/.dsl file). Using a compiler this can produce an 'ACPI Machine Language' file (.aml) or a hex table (.hex). To incorporate the file in your Arch install, you will need to get hold of a compiled .aml file. - whether this means compiling it yourself or trusting some stranger on the Internet is at your discretion. If you do download a file from the world wide web, it will most likely be a compressed .asl file. So you will need to unzip it and compile it. The upside to this is that you won't have to research specific code fixes yourself.<br />
<br />
Arch users with the same laptop as you are: a minority of a minority of a minority. Try browsing other distro/linux forums for talk about the same model. Likelihood is that they have the same problems and either because there is a lot of them, or because they're tech savvy -- someone there has produced a working DSDT and maybe even provides a precompiled version (again, use at your own risk).<br />
Search engines are your best tools. Try keeping it short: 'model name' + 'dsdt' will probably produce results.<br />
<br />
== Recompiling it yourself ==<br />
Your best resources in this endeavor are going to be [http://en.gentoo-wiki.com/wiki/ACPI/Fix_common_problems The Gentoo wiki article], [http://www.acpi.info ACPI Spec homepage], and [http://www.lesswatts.org/projects/acpi/ Linux ACPI Project] which supercedes the activity that occurred at ''acpi.sourceforge.net''.<br />
In a nutshell, you can use Intel's ASL compiler to turn your systems DSDT table into source code, locate/fix the errors, and recompile. This process is detailed more comprehensively at the [http://en.gentoo-wiki.com/wiki/ACPI/Fix_common_problems Gentoo wiki].<br />
You'll need to install {{Pkg|iasl}} to modify code, and be familiar with [[Kernel_Compilation#Compilation]] to install it.<br />
<br />
'''What compiled the original code?'''<br />
Check if your system's DSDT was compiled using Intel or Microsoft compiler:<br />
{{hc|<nowiki> $ dmesg|grep DSDT</nowiki> |<br />
ACPI: DSDT 00000000bf7e5000 0A35F (v02 Intel CALPELLA 06040000 INTL 20060912)<br />
ACPI: EC: Look up EC in DSDT<br />
}}<br />
In case Microsoft's compiler had been used, abbreviation INTL would instead be MSFT.<br />
In the example, there were 5 errors on decompiling/recompiling the DSDT. Two of them were easy to fix after a bit of googling and delving into the ACPI specification. Three of them were due to different versions of compiler used and are, as later discovered, handled by the ACPICA at boot-time. The ACPICA component of the kernel can handle most of the trivial errors you get while compiling the DSDT. So do not fret yourself over compile errors if your system is ''working the way it should''.<br />
<br />
1.) Extract ACPI tables (as root): {{ic|# cat /sys/firmware/acpi/tables/DSDT > dsdt.dat}}<br />
<br />
2.) Decompile: {{ic|iasl -d dsdt.dat}}<br />
<br />
3.) Recompile: {{ic|iasl -tc dsdt.dsl}}<br />
<br />
4.) Examine errors and fix. e.g.:{{bc|<br />
dsdt.dsl 6727: Name (_PLD, Buffer (0x10) <br />
Error 4105 - Invalid object type for reserved name ^ (found BUFFER, requires Package) }}<br />
{{hc| nano +6727 dsdt.dsl|<br />
(_PLD, Package(1) {Buffer (0x10)...}}<br />
<br />
5.) Compile fixed code: {{ic|iasl -tc dsdt.dsl}} (Might want to try option -ic for C include file to insert into kernel source)<br />
<br />
If it says no errors and no warnings you should be good to go.<br />
<br />
== Using modified code ==<br />
{{Expansion| Detail each method}}<br />
<br />
There are 2 ways to use a custom DSDT Table:<br />
* compiling the custom DSDT into the kernel<br />
* loading the custom DSDT at runtime (not supported)<br />
<br />
=== Compile into kernel ===<br />
You'll want to be familiar with [[Kernels | compiling your own kernel]]. The most straightforward way is with the "traditional" approach.<br />
After compiling DSDT, iasl produce two files: {{ic|dsdt.hex}} and {{ic|dsdt.aml}}.<br />
<br />
'''Using {{ic|menuconfig}}:'''<br />
* Disable "Select only drivers that don't need compile-time external firmware". Located in "Device Drivers -> Generic Driver Options".<br />
* Enable "Include Custom DSDT" and specify the absolute path of your fixed DSDT file ({{ic|dsdt.hex}}, not {{ic|dsdt.aml}}). Located in "Power management and ACPI options -> ACPI (Advanced Configuration and Power Interface) Support".<br />
<br />
<br />
'''Check if you running custom DSDT'''<br />
<br />
Simply type<br />
{{ic|<nowiki>dmesg | grep DSDT</nowiki>}}<br />
<br />
You will see something like that:<br />
{{bc|<nowiki>[ 0.000000] ACPI: Override [DSDT- A M I], this is unsafe: tainting kernel<br />
[ 0.000000] ACPI: DSDT 00000000be9b1190 Logical table override, new table: ffffffff81865af0<br />
[ 0.000000] ACPI: DSDT ffffffff81865af0 0BBA3 (v02 ALASKA A M I 000000F3 INTL 20130517)</nowiki>}}<br />
If you see {{ic|...ACPI: Override...}}, you're running custom DSDT.<br />
<br />
<br />
=== Loading at runtime ===<br />
{{Warning|Loading at runtime don't supports. DSDT hook removed due to bug, see [https://bugs.archlinux.org/task/27906 FS#27906 bug]}}<br />
Luckily the Arch stock kernel supports using a custom DSDT so, first copy the '''.aml''' file compiled by iasl to:<br />
/boot/dsdt.aml<br />
<br />
The bootloader will replace the DSDT so we need a method to include our custom DSDT table into the bootloader image.<br />
Copy the following to '''/etc/grub.d/01_acpi'''<br />
<br />
#!/bin/sh<br />
set -e<br />
<br />
# Uncomment to load custom ACPI table<br />
GRUB_CUSTOM_ACPI="/boot/dsdt.aml"<br />
<br />
<br />
# DON'T MODIFY ANYTHING BELOW THIS LINE!<br />
<br />
<br />
prefix=/usr<br />
exec_prefix=${prefix}<br />
libdir=${exec_prefix}/lib<br />
<br />
<br />
. /usr/share/grub/grub-mkconfig_lib<br />
#. ${libdir}/grub/grub-mkconfig_lib<br />
<br />
<br />
# Load custom ACPI table<br />
if [ x${GRUB_CUSTOM_ACPI} != x ] && [ -f ${GRUB_CUSTOM_ACPI} ] \<br />
&& is_path_readable_by_grub ${GRUB_CUSTOM_ACPI}; then<br />
echo "Found custom ACPI table: ${GRUB_CUSTOM_ACPI}" >&2<br />
prepare_grub_to_access_device `${grub_probe} --target=device ${GRUB_CUSTOM_ACPI}` | sed -e "s/^/ /"<br />
cat << EOF<br />
acpi (\$root)`make_system_path_relative_to_its_root ${GRUB_CUSTOM_ACPI}`<br />
EOF<br />
fi<br />
<br />
Make sure to make this file executable, or it will be ignored by '''grub-mkconfig'''<br />
chmod +x /etc/grub.d/01_acpi<br />
<br />
This will tell GRUB to include the DSDT into its core.img (change GRUB_CUSTOM_ACPI to reflect the path to your .aml file).<br />
Next you will need a new boot image. If you use GRUB run:<br />
grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
Lastly, recreate your initrd<br />
mkinitcpio -p linux<br />
and reboot. Done!<br />
<br />
To check if you are really using your own DSDT read your table again {{ic|# cat /sys/firmware/acpi/tables/DSDT > dsdt.dat}}<br />
and decompile it with {{ic|iasl -d dsdt.dat}}</div>Swiftiehttps://wiki.archlinux.org/index.php?title=DSDT&diff=268048DSDT2013-07-26T12:32:24Z<p>Swiftie: /* Using modified code */</p>
<hr />
<div>[[Category:Boot process]]<br />
[[Category:Kernel]]<br />
[[Category:Power management]]<br />
DSDT (Differentiated System Description Table) is a part of the [[Wikipedia:ACPI|ACPI]] specification. It supplies information about supported power events in a given system. ACPI tables are provided in firmware from the manufacturer. A common Linux problems are missing ACPI functionality, such as: fans not running, screens not turning off when the lid is closed, etc. This can stem from DSDTs made with Windows specifically in mind, which can be patched after installation. The goal of this article is to analyze and rebuild a faulty DSDT, so that the kernel can override the default one.<br />
<br />
Basically a DSDT table is the code run on ACPI (Power Management) events.<br />
<br />
{{Note|The goal of the [http://www.lesswatts.org/projects/acpi/ Linux ACPI] project is that Linux should work on unmodified firmware. If you still find this type of workaround necessary on modern kernels then you should consider [[Reporting Bug Guidelines|submiting a bug report]]. }}<br />
<br />
==Before you start...==<br />
* It is possible that the hardware manufacturer has released an updated firmware which fixes ACPI related problems. Installing an updated firmware is often preferred over this method because it would avoid duplication of effort.<br />
* This process does tamper with some fairly fundamental code on your installation. You will want to be absolutely sure of the changes you make. You might also wish to [[Disk cloning | clone your disk]] beforehand.<br />
* Even before attempting to fix your DSDT yourself, you can attempt a couple of different shortcuts: <br />
<br />
===Tell the kernel to report a version of Windows===<br />
<br />
Use the variable '''acpi_os_name''' as a kernel parameter. For example:<br />
<br />
acpi_os_name="Microsoft Windows NT"<br />
<br />
Or<br />
<br />
acpi_osi="!Windows2012"<br />
appended to the kernel line in grub legacy configuration<br />
<br />
other strings to test:<br />
* "Microsoft Windows XP"<br />
* "Microsoft Windows 2000"<br />
* "Microsoft Windows 2000.1"<br />
* "Microsoft Windows ME: Millennium Edition"<br />
* "Windows 2001"<br />
* "Windows 2006"<br />
* "Windows 2009"<br />
* "Windows 2012"<br />
* when all that fails, you can even try "Linux"<br />
<br />
Out of curiousity, you can follow the steps below to extract your DSDT and search the .dsl file. Just grep for "Windows" and see what pops up.<br />
<br />
===Find a fixed DSDT===<br />
A DSDT file is originally written in ACPI Source language (an .asl/.dsl file). Using a compiler this can produce an 'ACPI Machine Language' file (.aml) or a hex table (.hex). To incorporate the file in your Arch install, you will need to get hold of a compiled .aml file. - whether this means compiling it yourself or trusting some stranger on the Internet is at your discretion. If you do download a file from the world wide web, it will most likely be a compressed .asl file. So you will need to unzip it and compile it. The upside to this is that you won't have to research specific code fixes yourself.<br />
<br />
Arch users with the same laptop as you are: a minority of a minority of a minority. Try browsing other distro/linux forums for talk about the same model. Likelihood is that they have the same problems and either because there is a lot of them, or because they're tech savvy -- someone there has produced a working DSDT and maybe even provides a precompiled version (again, use at your own risk).<br />
Search engines are your best tools. Try keeping it short: 'model name' + 'dsdt' will probably produce results.<br />
<br />
== Recompiling it yourself ==<br />
Your best resources in this endeavor are going to be [http://en.gentoo-wiki.com/wiki/ACPI/Fix_common_problems The Gentoo wiki article], [http://www.acpi.info ACPI Spec homepage], and [http://www.lesswatts.org/projects/acpi/ Linux ACPI Project] which supercedes the activity that occurred at ''acpi.sourceforge.net''.<br />
In a nutshell, you can use Intel's ASL compiler to turn your systems DSDT table into source code, locate/fix the errors, and recompile. This process is detailed more comprehensively at the [http://en.gentoo-wiki.com/wiki/ACPI/Fix_common_problems Gentoo wiki].<br />
You'll need to install {{Pkg|iasl}} to modify code, and be familiar with [[Kernel_Compilation#Compilation]] to install it.<br />
<br />
'''What compiled the original code?'''<br />
Check if your system's DSDT was compiled using Intel or Microsoft compiler:<br />
{{hc|<nowiki> $ dmesg|grep DSDT</nowiki> |<br />
ACPI: DSDT 00000000bf7e5000 0A35F (v02 Intel CALPELLA 06040000 INTL 20060912)<br />
ACPI: EC: Look up EC in DSDT<br />
}}<br />
In case Microsoft's compiler had been used, abbreviation INTL would instead be MSFT.<br />
In the example, there were 5 errors on decompiling/recompiling the DSDT. Two of them were easy to fix after a bit of googling and delving into the ACPI specification. Three of them were due to different versions of compiler used and are, as later discovered, handled by the ACPICA at boot-time. The ACPICA component of the kernel can handle most of the trivial errors you get while compiling the DSDT. So do not fret yourself over compile errors if your system is ''working the way it should''.<br />
<br />
1.) Extract ACPI tables (as root): {{ic|# cat /sys/firmware/acpi/tables/DSDT > dsdt.dat}}<br />
<br />
2.) Decompile: {{ic|iasl -d dsdt.dat}}<br />
<br />
3.) Recompile: {{ic|iasl -tc dsdt.dsl}}<br />
<br />
4.) Examine errors and fix. e.g.:{{bc|<br />
dsdt.dsl 6727: Name (_PLD, Buffer (0x10) <br />
Error 4105 - Invalid object type for reserved name ^ (found BUFFER, requires Package) }}<br />
{{hc| nano +6727 dsdt.dsl|<br />
(_PLD, Package(1) {Buffer (0x10)...}}<br />
<br />
5.) Compile fixed code: {{ic|iasl -tc dsdt.dsl}} (Might want to try option -ic for C include file to insert into kernel source)<br />
<br />
If it says no errors and no warnings you should be good to go.<br />
<br />
== Using modified code ==<br />
{{Expansion| Detail each method}}<br />
<br />
There are 2 ways to use a custom DSDT Table:<br />
* compiling the custom DSDT into the kernel<br />
* loading the custom DSDT at runtime (not supported)<br />
<br />
=== Loading at runtime ===<br />
{{Warning|Loading at runtime don't supports. DSDT hook removed due to bug, see [https://bugs.archlinux.org/task/27906 FS#27906 bug]}}<br />
Luckily the Arch stock kernel supports using a custom DSDT so, first copy the '''.aml''' file compiled by iasl to:<br />
/boot/dsdt.aml<br />
<br />
The bootloader will replace the DSDT so we need a method to include our custom DSDT table into the bootloader image.<br />
Copy the following to '''/etc/grub.d/01_acpi'''<br />
<br />
#!/bin/sh<br />
set -e<br />
<br />
# Uncomment to load custom ACPI table<br />
GRUB_CUSTOM_ACPI="/boot/dsdt.aml"<br />
<br />
<br />
# DON'T MODIFY ANYTHING BELOW THIS LINE!<br />
<br />
<br />
prefix=/usr<br />
exec_prefix=${prefix}<br />
libdir=${exec_prefix}/lib<br />
<br />
<br />
. /usr/share/grub/grub-mkconfig_lib<br />
#. ${libdir}/grub/grub-mkconfig_lib<br />
<br />
<br />
# Load custom ACPI table<br />
if [ x${GRUB_CUSTOM_ACPI} != x ] && [ -f ${GRUB_CUSTOM_ACPI} ] \<br />
&& is_path_readable_by_grub ${GRUB_CUSTOM_ACPI}; then<br />
echo "Found custom ACPI table: ${GRUB_CUSTOM_ACPI}" >&2<br />
prepare_grub_to_access_device `${grub_probe} --target=device ${GRUB_CUSTOM_ACPI}` | sed -e "s/^/ /"<br />
cat << EOF<br />
acpi (\$root)`make_system_path_relative_to_its_root ${GRUB_CUSTOM_ACPI}`<br />
EOF<br />
fi<br />
<br />
Make sure to make this file executable, or it will be ignored by '''grub-mkconfig'''<br />
chmod +x /etc/grub.d/01_acpi<br />
<br />
This will tell GRUB to include the DSDT into its core.img (change GRUB_CUSTOM_ACPI to reflect the path to your .aml file).<br />
Next you will need a new boot image. If you use GRUB run:<br />
grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
Lastly, recreate your initrd<br />
mkinitcpio -p linux<br />
and reboot. Done!<br />
<br />
To check if you are really using your own DSDT read your table again {{ic|# cat /sys/firmware/acpi/tables/DSDT > dsdt.dat}}<br />
and decompile it with {{ic|iasl -d dsdt.dat}}<br />
<br />
=== Compile into kernel ===<br />
You'll want to be familiar with [[Kernels | compiling your own kernel]]. The most straightforward way is with the "traditional" approach.<br />
After compiling DSDT, iasl produce two files: {{ic|dsdt.hex}} and {{ic|dsdt.aml}}.<br />
<br />
'''Using {{ic|menuconfig}}:'''<br />
* Disable "Select only drivers that don't need compile-time external firmware". Located in "Device Drivers -> Generic Driver Options".<br />
* Enable "Include Custom DSDT" and specify the absolute path of your fixed DSDT file ({{ic|dsdt.hex}}, not {{ic|dsdt.aml}}). Located in "Power management and ACPI options -> ACPI (Advanced Configuration and Power Interface) Support".<br />
<br />
<br />
'''Check if you running custom DSDT'''<br />
<br />
Simply type<br />
{{ic|<nowiki>dmesg | grep DSDT</nowiki>}}<br />
<br />
You will see something like that:<br />
{{bc|<nowiki>[ 0.000000] ACPI: Override [DSDT- A M I], this is unsafe: tainting kernel<br />
[ 0.000000] ACPI: DSDT 00000000be9b1190 Logical table override, new table: ffffffff81865af0<br />
[ 0.000000] ACPI: DSDT ffffffff81865af0 0BBA3 (v02 ALASKA A M I 000000F3 INTL 20130517)</nowiki>}}<br />
If you see {{ic|...ACPI: Override...}}, you're running custom DSDT.</div>Swiftiehttps://wiki.archlinux.org/index.php?title=DSDT&diff=268047DSDT2013-07-26T12:31:15Z<p>Swiftie: /* Compile into kernel */</p>
<hr />
<div>[[Category:Boot process]]<br />
[[Category:Kernel]]<br />
[[Category:Power management]]<br />
DSDT (Differentiated System Description Table) is a part of the [[Wikipedia:ACPI|ACPI]] specification. It supplies information about supported power events in a given system. ACPI tables are provided in firmware from the manufacturer. A common Linux problems are missing ACPI functionality, such as: fans not running, screens not turning off when the lid is closed, etc. This can stem from DSDTs made with Windows specifically in mind, which can be patched after installation. The goal of this article is to analyze and rebuild a faulty DSDT, so that the kernel can override the default one.<br />
<br />
Basically a DSDT table is the code run on ACPI (Power Management) events.<br />
<br />
{{Note|The goal of the [http://www.lesswatts.org/projects/acpi/ Linux ACPI] project is that Linux should work on unmodified firmware. If you still find this type of workaround necessary on modern kernels then you should consider [[Reporting Bug Guidelines|submiting a bug report]]. }}<br />
<br />
==Before you start...==<br />
* It is possible that the hardware manufacturer has released an updated firmware which fixes ACPI related problems. Installing an updated firmware is often preferred over this method because it would avoid duplication of effort.<br />
* This process does tamper with some fairly fundamental code on your installation. You will want to be absolutely sure of the changes you make. You might also wish to [[Disk cloning | clone your disk]] beforehand.<br />
* Even before attempting to fix your DSDT yourself, you can attempt a couple of different shortcuts: <br />
<br />
===Tell the kernel to report a version of Windows===<br />
<br />
Use the variable '''acpi_os_name''' as a kernel parameter. For example:<br />
<br />
acpi_os_name="Microsoft Windows NT"<br />
<br />
Or<br />
<br />
acpi_osi="!Windows2012"<br />
appended to the kernel line in grub legacy configuration<br />
<br />
other strings to test:<br />
* "Microsoft Windows XP"<br />
* "Microsoft Windows 2000"<br />
* "Microsoft Windows 2000.1"<br />
* "Microsoft Windows ME: Millennium Edition"<br />
* "Windows 2001"<br />
* "Windows 2006"<br />
* "Windows 2009"<br />
* "Windows 2012"<br />
* when all that fails, you can even try "Linux"<br />
<br />
Out of curiousity, you can follow the steps below to extract your DSDT and search the .dsl file. Just grep for "Windows" and see what pops up.<br />
<br />
===Find a fixed DSDT===<br />
A DSDT file is originally written in ACPI Source language (an .asl/.dsl file). Using a compiler this can produce an 'ACPI Machine Language' file (.aml) or a hex table (.hex). To incorporate the file in your Arch install, you will need to get hold of a compiled .aml file. - whether this means compiling it yourself or trusting some stranger on the Internet is at your discretion. If you do download a file from the world wide web, it will most likely be a compressed .asl file. So you will need to unzip it and compile it. The upside to this is that you won't have to research specific code fixes yourself.<br />
<br />
Arch users with the same laptop as you are: a minority of a minority of a minority. Try browsing other distro/linux forums for talk about the same model. Likelihood is that they have the same problems and either because there is a lot of them, or because they're tech savvy -- someone there has produced a working DSDT and maybe even provides a precompiled version (again, use at your own risk).<br />
Search engines are your best tools. Try keeping it short: 'model name' + 'dsdt' will probably produce results.<br />
<br />
== Recompiling it yourself ==<br />
Your best resources in this endeavor are going to be [http://en.gentoo-wiki.com/wiki/ACPI/Fix_common_problems The Gentoo wiki article], [http://www.acpi.info ACPI Spec homepage], and [http://www.lesswatts.org/projects/acpi/ Linux ACPI Project] which supercedes the activity that occurred at ''acpi.sourceforge.net''.<br />
In a nutshell, you can use Intel's ASL compiler to turn your systems DSDT table into source code, locate/fix the errors, and recompile. This process is detailed more comprehensively at the [http://en.gentoo-wiki.com/wiki/ACPI/Fix_common_problems Gentoo wiki].<br />
You'll need to install {{Pkg|iasl}} to modify code, and be familiar with [[Kernel_Compilation#Compilation]] to install it.<br />
<br />
'''What compiled the original code?'''<br />
Check if your system's DSDT was compiled using Intel or Microsoft compiler:<br />
{{hc|<nowiki> $ dmesg|grep DSDT</nowiki> |<br />
ACPI: DSDT 00000000bf7e5000 0A35F (v02 Intel CALPELLA 06040000 INTL 20060912)<br />
ACPI: EC: Look up EC in DSDT<br />
}}<br />
In case Microsoft's compiler had been used, abbreviation INTL would instead be MSFT.<br />
In the example, there were 5 errors on decompiling/recompiling the DSDT. Two of them were easy to fix after a bit of googling and delving into the ACPI specification. Three of them were due to different versions of compiler used and are, as later discovered, handled by the ACPICA at boot-time. The ACPICA component of the kernel can handle most of the trivial errors you get while compiling the DSDT. So do not fret yourself over compile errors if your system is ''working the way it should''.<br />
<br />
1.) Extract ACPI tables (as root): {{ic|# cat /sys/firmware/acpi/tables/DSDT > dsdt.dat}}<br />
<br />
2.) Decompile: {{ic|iasl -d dsdt.dat}}<br />
<br />
3.) Recompile: {{ic|iasl -tc dsdt.dsl}}<br />
<br />
4.) Examine errors and fix. e.g.:{{bc|<br />
dsdt.dsl 6727: Name (_PLD, Buffer (0x10) <br />
Error 4105 - Invalid object type for reserved name ^ (found BUFFER, requires Package) }}<br />
{{hc| nano +6727 dsdt.dsl|<br />
(_PLD, Package(1) {Buffer (0x10)...}}<br />
<br />
5.) Compile fixed code: {{ic|iasl -tc dsdt.dsl}} (Might want to try option -ic for C include file to insert into kernel source)<br />
<br />
If it says no errors and no warnings you should be good to go.<br />
<br />
== Using modified code ==<br />
{{Expansion| Detail each method}}<br />
<br />
There are 2 ways to use a custom DSDT Table:<br />
* loading the custom DSDT at runtime (not supported)<br />
* compiling the custom DSDT into the kernel<br />
<br />
=== Loading at runtime ===<br />
{{Warning|Loading at runtime don't supports. DSDT hook removed due to bug, see [https://bugs.archlinux.org/task/27906 FS#27906 bug]}}<br />
Luckily the Arch stock kernel supports using a custom DSDT so, first copy the '''.aml''' file compiled by iasl to:<br />
/boot/dsdt.aml<br />
<br />
The bootloader will replace the DSDT so we need a method to include our custom DSDT table into the bootloader image.<br />
Copy the following to '''/etc/grub.d/01_acpi'''<br />
<br />
#!/bin/sh<br />
set -e<br />
<br />
# Uncomment to load custom ACPI table<br />
GRUB_CUSTOM_ACPI="/boot/dsdt.aml"<br />
<br />
<br />
# DON'T MODIFY ANYTHING BELOW THIS LINE!<br />
<br />
<br />
prefix=/usr<br />
exec_prefix=${prefix}<br />
libdir=${exec_prefix}/lib<br />
<br />
<br />
. /usr/share/grub/grub-mkconfig_lib<br />
#. ${libdir}/grub/grub-mkconfig_lib<br />
<br />
<br />
# Load custom ACPI table<br />
if [ x${GRUB_CUSTOM_ACPI} != x ] && [ -f ${GRUB_CUSTOM_ACPI} ] \<br />
&& is_path_readable_by_grub ${GRUB_CUSTOM_ACPI}; then<br />
echo "Found custom ACPI table: ${GRUB_CUSTOM_ACPI}" >&2<br />
prepare_grub_to_access_device `${grub_probe} --target=device ${GRUB_CUSTOM_ACPI}` | sed -e "s/^/ /"<br />
cat << EOF<br />
acpi (\$root)`make_system_path_relative_to_its_root ${GRUB_CUSTOM_ACPI}`<br />
EOF<br />
fi<br />
<br />
Make sure to make this file executable, or it will be ignored by '''grub-mkconfig'''<br />
chmod +x /etc/grub.d/01_acpi<br />
<br />
This will tell GRUB to include the DSDT into its core.img (change GRUB_CUSTOM_ACPI to reflect the path to your .aml file).<br />
Next you will need a new boot image. If you use GRUB run:<br />
grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
Lastly, recreate your initrd<br />
mkinitcpio -p linux<br />
and reboot. Done!<br />
<br />
To check if you are really using your own DSDT read your table again {{ic|# cat /sys/firmware/acpi/tables/DSDT > dsdt.dat}}<br />
and decompile it with {{ic|iasl -d dsdt.dat}}<br />
<br />
=== Compile into kernel ===<br />
You'll want to be familiar with [[Kernels | compiling your own kernel]]. The most straightforward way is with the "traditional" approach.<br />
After compiling DSDT, iasl produce two files: {{ic|dsdt.hex}} and {{ic|dsdt.aml}}.<br />
<br />
'''Using {{ic|menuconfig}}:'''<br />
* Disable "Select only drivers that don't need compile-time external firmware". Located in "Device Drivers -> Generic Driver Options".<br />
* Enable "Include Custom DSDT" and specify the absolute path of your fixed DSDT file ({{ic|dsdt.hex}}, not {{ic|dsdt.aml}}). Located in "Power management and ACPI options -> ACPI (Advanced Configuration and Power Interface) Support".<br />
<br />
<br />
'''Check if you running custom DSDT'''<br />
<br />
Simply type<br />
{{ic|<nowiki>dmesg | grep DSDT</nowiki>}}<br />
<br />
You will see something like that:<br />
{{bc|<nowiki>[ 0.000000] ACPI: Override [DSDT- A M I], this is unsafe: tainting kernel<br />
[ 0.000000] ACPI: DSDT 00000000be9b1190 Logical table override, new table: ffffffff81865af0<br />
[ 0.000000] ACPI: DSDT ffffffff81865af0 0BBA3 (v02 ALASKA A M I 000000F3 INTL 20130517)</nowiki>}}<br />
If you see {{ic|...ACPI: Override...}}, you're running custom DSDT.</div>Swiftiehttps://wiki.archlinux.org/index.php?title=DSDT&diff=268046DSDT2013-07-26T12:12:00Z<p>Swiftie: /* Using modified code */</p>
<hr />
<div>[[Category:Boot process]]<br />
[[Category:Kernel]]<br />
[[Category:Power management]]<br />
DSDT (Differentiated System Description Table) is a part of the [[Wikipedia:ACPI|ACPI]] specification. It supplies information about supported power events in a given system. ACPI tables are provided in firmware from the manufacturer. A common Linux problems are missing ACPI functionality, such as: fans not running, screens not turning off when the lid is closed, etc. This can stem from DSDTs made with Windows specifically in mind, which can be patched after installation. The goal of this article is to analyze and rebuild a faulty DSDT, so that the kernel can override the default one.<br />
<br />
Basically a DSDT table is the code run on ACPI (Power Management) events.<br />
<br />
{{Note|The goal of the [http://www.lesswatts.org/projects/acpi/ Linux ACPI] project is that Linux should work on unmodified firmware. If you still find this type of workaround necessary on modern kernels then you should consider [[Reporting Bug Guidelines|submiting a bug report]]. }}<br />
<br />
==Before you start...==<br />
* It is possible that the hardware manufacturer has released an updated firmware which fixes ACPI related problems. Installing an updated firmware is often preferred over this method because it would avoid duplication of effort.<br />
* This process does tamper with some fairly fundamental code on your installation. You will want to be absolutely sure of the changes you make. You might also wish to [[Disk cloning | clone your disk]] beforehand.<br />
* Even before attempting to fix your DSDT yourself, you can attempt a couple of different shortcuts: <br />
<br />
===Tell the kernel to report a version of Windows===<br />
<br />
Use the variable '''acpi_os_name''' as a kernel parameter. For example:<br />
<br />
acpi_os_name="Microsoft Windows NT"<br />
<br />
Or<br />
<br />
acpi_osi="!Windows2012"<br />
appended to the kernel line in grub legacy configuration<br />
<br />
other strings to test:<br />
* "Microsoft Windows XP"<br />
* "Microsoft Windows 2000"<br />
* "Microsoft Windows 2000.1"<br />
* "Microsoft Windows ME: Millennium Edition"<br />
* "Windows 2001"<br />
* "Windows 2006"<br />
* "Windows 2009"<br />
* "Windows 2012"<br />
* when all that fails, you can even try "Linux"<br />
<br />
Out of curiousity, you can follow the steps below to extract your DSDT and search the .dsl file. Just grep for "Windows" and see what pops up.<br />
<br />
===Find a fixed DSDT===<br />
A DSDT file is originally written in ACPI Source language (an .asl/.dsl file). Using a compiler this can produce an 'ACPI Machine Language' file (.aml) or a hex table (.hex). To incorporate the file in your Arch install, you will need to get hold of a compiled .aml file. - whether this means compiling it yourself or trusting some stranger on the Internet is at your discretion. If you do download a file from the world wide web, it will most likely be a compressed .asl file. So you will need to unzip it and compile it. The upside to this is that you won't have to research specific code fixes yourself.<br />
<br />
Arch users with the same laptop as you are: a minority of a minority of a minority. Try browsing other distro/linux forums for talk about the same model. Likelihood is that they have the same problems and either because there is a lot of them, or because they're tech savvy -- someone there has produced a working DSDT and maybe even provides a precompiled version (again, use at your own risk).<br />
Search engines are your best tools. Try keeping it short: 'model name' + 'dsdt' will probably produce results.<br />
<br />
== Recompiling it yourself ==<br />
Your best resources in this endeavor are going to be [http://en.gentoo-wiki.com/wiki/ACPI/Fix_common_problems The Gentoo wiki article], [http://www.acpi.info ACPI Spec homepage], and [http://www.lesswatts.org/projects/acpi/ Linux ACPI Project] which supercedes the activity that occurred at ''acpi.sourceforge.net''.<br />
In a nutshell, you can use Intel's ASL compiler to turn your systems DSDT table into source code, locate/fix the errors, and recompile. This process is detailed more comprehensively at the [http://en.gentoo-wiki.com/wiki/ACPI/Fix_common_problems Gentoo wiki].<br />
You'll need to install {{Pkg|iasl}} to modify code, and be familiar with [[Kernel_Compilation#Compilation]] to install it.<br />
<br />
'''What compiled the original code?'''<br />
Check if your system's DSDT was compiled using Intel or Microsoft compiler:<br />
{{hc|<nowiki> $ dmesg|grep DSDT</nowiki> |<br />
ACPI: DSDT 00000000bf7e5000 0A35F (v02 Intel CALPELLA 06040000 INTL 20060912)<br />
ACPI: EC: Look up EC in DSDT<br />
}}<br />
In case Microsoft's compiler had been used, abbreviation INTL would instead be MSFT.<br />
In the example, there were 5 errors on decompiling/recompiling the DSDT. Two of them were easy to fix after a bit of googling and delving into the ACPI specification. Three of them were due to different versions of compiler used and are, as later discovered, handled by the ACPICA at boot-time. The ACPICA component of the kernel can handle most of the trivial errors you get while compiling the DSDT. So do not fret yourself over compile errors if your system is ''working the way it should''.<br />
<br />
1.) Extract ACPI tables (as root): {{ic|# cat /sys/firmware/acpi/tables/DSDT > dsdt.dat}}<br />
<br />
2.) Decompile: {{ic|iasl -d dsdt.dat}}<br />
<br />
3.) Recompile: {{ic|iasl -tc dsdt.dsl}}<br />
<br />
4.) Examine errors and fix. e.g.:{{bc|<br />
dsdt.dsl 6727: Name (_PLD, Buffer (0x10) <br />
Error 4105 - Invalid object type for reserved name ^ (found BUFFER, requires Package) }}<br />
{{hc| nano +6727 dsdt.dsl|<br />
(_PLD, Package(1) {Buffer (0x10)...}}<br />
<br />
5.) Compile fixed code: {{ic|iasl -tc dsdt.dsl}} (Might want to try option -ic for C include file to insert into kernel source)<br />
<br />
If it says no errors and no warnings you should be good to go.<br />
<br />
== Using modified code ==<br />
{{Expansion| Detail each method}}<br />
<br />
There are 2 ways to use a custom DSDT Table:<br />
* loading the custom DSDT at runtime (not supported)<br />
* compiling the custom DSDT into the kernel<br />
<br />
=== Loading at runtime ===<br />
{{Warning|Loading at runtime don't supports. DSDT hook removed due to bug, see [https://bugs.archlinux.org/task/27906 FS#27906 bug]}}<br />
Luckily the Arch stock kernel supports using a custom DSDT so, first copy the '''.aml''' file compiled by iasl to:<br />
/boot/dsdt.aml<br />
<br />
The bootloader will replace the DSDT so we need a method to include our custom DSDT table into the bootloader image.<br />
Copy the following to '''/etc/grub.d/01_acpi'''<br />
<br />
#!/bin/sh<br />
set -e<br />
<br />
# Uncomment to load custom ACPI table<br />
GRUB_CUSTOM_ACPI="/boot/dsdt.aml"<br />
<br />
<br />
# DON'T MODIFY ANYTHING BELOW THIS LINE!<br />
<br />
<br />
prefix=/usr<br />
exec_prefix=${prefix}<br />
libdir=${exec_prefix}/lib<br />
<br />
<br />
. /usr/share/grub/grub-mkconfig_lib<br />
#. ${libdir}/grub/grub-mkconfig_lib<br />
<br />
<br />
# Load custom ACPI table<br />
if [ x${GRUB_CUSTOM_ACPI} != x ] && [ -f ${GRUB_CUSTOM_ACPI} ] \<br />
&& is_path_readable_by_grub ${GRUB_CUSTOM_ACPI}; then<br />
echo "Found custom ACPI table: ${GRUB_CUSTOM_ACPI}" >&2<br />
prepare_grub_to_access_device `${grub_probe} --target=device ${GRUB_CUSTOM_ACPI}` | sed -e "s/^/ /"<br />
cat << EOF<br />
acpi (\$root)`make_system_path_relative_to_its_root ${GRUB_CUSTOM_ACPI}`<br />
EOF<br />
fi<br />
<br />
Make sure to make this file executable, or it will be ignored by '''grub-mkconfig'''<br />
chmod +x /etc/grub.d/01_acpi<br />
<br />
This will tell GRUB to include the DSDT into its core.img (change GRUB_CUSTOM_ACPI to reflect the path to your .aml file).<br />
Next you will need a new boot image. If you use GRUB run:<br />
grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
Lastly, recreate your initrd<br />
mkinitcpio -p linux<br />
and reboot. Done!<br />
<br />
To check if you are really using your own DSDT read your table again {{ic|# cat /sys/firmware/acpi/tables/DSDT > dsdt.dat}}<br />
and decompile it with {{ic|iasl -d dsdt.dat}}<br />
<br />
=== Compile into kernel ===<br />
You'll want to be familiar with [[Kernels | compiling your own kernel]]. The most straightforward way is with the "traditional" approach.<br />
<br />
'''Using {{ic|menuconfig}}:'''<br />
* Disable "Select only drivers that don't need compile-time external firmware".<br />
* Enable "Include Custom DSDT" and specify the absolute path of your fixed DSDT file.</div>Swiftiehttps://wiki.archlinux.org/index.php?title=DSDT&diff=268045DSDT2013-07-26T12:08:32Z<p>Swiftie: /* Loading at runtime */</p>
<hr />
<div>[[Category:Boot process]]<br />
[[Category:Kernel]]<br />
[[Category:Power management]]<br />
DSDT (Differentiated System Description Table) is a part of the [[Wikipedia:ACPI|ACPI]] specification. It supplies information about supported power events in a given system. ACPI tables are provided in firmware from the manufacturer. A common Linux problems are missing ACPI functionality, such as: fans not running, screens not turning off when the lid is closed, etc. This can stem from DSDTs made with Windows specifically in mind, which can be patched after installation. The goal of this article is to analyze and rebuild a faulty DSDT, so that the kernel can override the default one.<br />
<br />
Basically a DSDT table is the code run on ACPI (Power Management) events.<br />
<br />
{{Note|The goal of the [http://www.lesswatts.org/projects/acpi/ Linux ACPI] project is that Linux should work on unmodified firmware. If you still find this type of workaround necessary on modern kernels then you should consider [[Reporting Bug Guidelines|submiting a bug report]]. }}<br />
<br />
==Before you start...==<br />
* It is possible that the hardware manufacturer has released an updated firmware which fixes ACPI related problems. Installing an updated firmware is often preferred over this method because it would avoid duplication of effort.<br />
* This process does tamper with some fairly fundamental code on your installation. You will want to be absolutely sure of the changes you make. You might also wish to [[Disk cloning | clone your disk]] beforehand.<br />
* Even before attempting to fix your DSDT yourself, you can attempt a couple of different shortcuts: <br />
<br />
===Tell the kernel to report a version of Windows===<br />
<br />
Use the variable '''acpi_os_name''' as a kernel parameter. For example:<br />
<br />
acpi_os_name="Microsoft Windows NT"<br />
<br />
Or<br />
<br />
acpi_osi="!Windows2012"<br />
appended to the kernel line in grub legacy configuration<br />
<br />
other strings to test:<br />
* "Microsoft Windows XP"<br />
* "Microsoft Windows 2000"<br />
* "Microsoft Windows 2000.1"<br />
* "Microsoft Windows ME: Millennium Edition"<br />
* "Windows 2001"<br />
* "Windows 2006"<br />
* "Windows 2009"<br />
* "Windows 2012"<br />
* when all that fails, you can even try "Linux"<br />
<br />
Out of curiousity, you can follow the steps below to extract your DSDT and search the .dsl file. Just grep for "Windows" and see what pops up.<br />
<br />
===Find a fixed DSDT===<br />
A DSDT file is originally written in ACPI Source language (an .asl/.dsl file). Using a compiler this can produce an 'ACPI Machine Language' file (.aml) or a hex table (.hex). To incorporate the file in your Arch install, you will need to get hold of a compiled .aml file. - whether this means compiling it yourself or trusting some stranger on the Internet is at your discretion. If you do download a file from the world wide web, it will most likely be a compressed .asl file. So you will need to unzip it and compile it. The upside to this is that you won't have to research specific code fixes yourself.<br />
<br />
Arch users with the same laptop as you are: a minority of a minority of a minority. Try browsing other distro/linux forums for talk about the same model. Likelihood is that they have the same problems and either because there is a lot of them, or because they're tech savvy -- someone there has produced a working DSDT and maybe even provides a precompiled version (again, use at your own risk).<br />
Search engines are your best tools. Try keeping it short: 'model name' + 'dsdt' will probably produce results.<br />
<br />
== Recompiling it yourself ==<br />
Your best resources in this endeavor are going to be [http://en.gentoo-wiki.com/wiki/ACPI/Fix_common_problems The Gentoo wiki article], [http://www.acpi.info ACPI Spec homepage], and [http://www.lesswatts.org/projects/acpi/ Linux ACPI Project] which supercedes the activity that occurred at ''acpi.sourceforge.net''.<br />
In a nutshell, you can use Intel's ASL compiler to turn your systems DSDT table into source code, locate/fix the errors, and recompile. This process is detailed more comprehensively at the [http://en.gentoo-wiki.com/wiki/ACPI/Fix_common_problems Gentoo wiki].<br />
You'll need to install {{Pkg|iasl}} to modify code, and be familiar with [[Kernel_Compilation#Compilation]] to install it.<br />
<br />
'''What compiled the original code?'''<br />
Check if your system's DSDT was compiled using Intel or Microsoft compiler:<br />
{{hc|<nowiki> $ dmesg|grep DSDT</nowiki> |<br />
ACPI: DSDT 00000000bf7e5000 0A35F (v02 Intel CALPELLA 06040000 INTL 20060912)<br />
ACPI: EC: Look up EC in DSDT<br />
}}<br />
In case Microsoft's compiler had been used, abbreviation INTL would instead be MSFT.<br />
In the example, there were 5 errors on decompiling/recompiling the DSDT. Two of them were easy to fix after a bit of googling and delving into the ACPI specification. Three of them were due to different versions of compiler used and are, as later discovered, handled by the ACPICA at boot-time. The ACPICA component of the kernel can handle most of the trivial errors you get while compiling the DSDT. So do not fret yourself over compile errors if your system is ''working the way it should''.<br />
<br />
1.) Extract ACPI tables (as root): {{ic|# cat /sys/firmware/acpi/tables/DSDT > dsdt.dat}}<br />
<br />
2.) Decompile: {{ic|iasl -d dsdt.dat}}<br />
<br />
3.) Recompile: {{ic|iasl -tc dsdt.dsl}}<br />
<br />
4.) Examine errors and fix. e.g.:{{bc|<br />
dsdt.dsl 6727: Name (_PLD, Buffer (0x10) <br />
Error 4105 - Invalid object type for reserved name ^ (found BUFFER, requires Package) }}<br />
{{hc| nano +6727 dsdt.dsl|<br />
(_PLD, Package(1) {Buffer (0x10)...}}<br />
<br />
5.) Compile fixed code: {{ic|iasl -tc dsdt.dsl}} (Might want to try option -ic for C include file to insert into kernel source)<br />
<br />
If it says no errors and no warnings you should be good to go.<br />
<br />
== Using modified code ==<br />
{{Expansion| Detail each method}}<br />
<br />
There are 2 ways to use a custom DSDT Table:<br />
* loading the custom DSDT at runtime (recommended, since easier)<br />
* compiling the custom DSDT into the kernel<br />
<br />
=== Loading at runtime ===<br />
{{Warning|Loading at runtime don't supports. DSDT hook removed due to bug, see [https://bugs.archlinux.org/task/27906 FS#27906 bug]}}<br />
Luckily the Arch stock kernel supports using a custom DSDT so, first copy the '''.aml''' file compiled by iasl to:<br />
/boot/dsdt.aml<br />
<br />
The bootloader will replace the DSDT so we need a method to include our custom DSDT table into the bootloader image.<br />
Copy the following to '''/etc/grub.d/01_acpi'''<br />
<br />
#!/bin/sh<br />
set -e<br />
<br />
# Uncomment to load custom ACPI table<br />
GRUB_CUSTOM_ACPI="/boot/dsdt.aml"<br />
<br />
<br />
# DON'T MODIFY ANYTHING BELOW THIS LINE!<br />
<br />
<br />
prefix=/usr<br />
exec_prefix=${prefix}<br />
libdir=${exec_prefix}/lib<br />
<br />
<br />
. /usr/share/grub/grub-mkconfig_lib<br />
#. ${libdir}/grub/grub-mkconfig_lib<br />
<br />
<br />
# Load custom ACPI table<br />
if [ x${GRUB_CUSTOM_ACPI} != x ] && [ -f ${GRUB_CUSTOM_ACPI} ] \<br />
&& is_path_readable_by_grub ${GRUB_CUSTOM_ACPI}; then<br />
echo "Found custom ACPI table: ${GRUB_CUSTOM_ACPI}" >&2<br />
prepare_grub_to_access_device `${grub_probe} --target=device ${GRUB_CUSTOM_ACPI}` | sed -e "s/^/ /"<br />
cat << EOF<br />
acpi (\$root)`make_system_path_relative_to_its_root ${GRUB_CUSTOM_ACPI}`<br />
EOF<br />
fi<br />
<br />
Make sure to make this file executable, or it will be ignored by '''grub-mkconfig'''<br />
chmod +x /etc/grub.d/01_acpi<br />
<br />
This will tell GRUB to include the DSDT into its core.img (change GRUB_CUSTOM_ACPI to reflect the path to your .aml file).<br />
Next you will need a new boot image. If you use GRUB run:<br />
grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
Lastly, recreate your initrd<br />
mkinitcpio -p linux<br />
and reboot. Done!<br />
<br />
To check if you are really using your own DSDT read your table again {{ic|# cat /sys/firmware/acpi/tables/DSDT > dsdt.dat}}<br />
and decompile it with {{ic|iasl -d dsdt.dat}}<br />
<br />
=== Compile into kernel ===<br />
You'll want to be familiar with [[Kernels | compiling your own kernel]]. The most straightforward way is with the "traditional" approach.<br />
<br />
'''Using {{ic|menuconfig}}:'''<br />
* Disable "Select only drivers that don't need compile-time external firmware".<br />
* Enable "Include Custom DSDT" and specify the absolute path of your fixed DSDT file.</div>Swiftiehttps://wiki.archlinux.org/index.php?title=DSDT&diff=268039DSDT2013-07-26T11:32:58Z<p>Swiftie: /* Loading at runtime */</p>
<hr />
<div>[[Category:Boot process]]<br />
[[Category:Kernel]]<br />
[[Category:Power management]]<br />
DSDT (Differentiated System Description Table) is a part of the [[Wikipedia:ACPI|ACPI]] specification. It supplies information about supported power events in a given system. ACPI tables are provided in firmware from the manufacturer. A common Linux problems are missing ACPI functionality, such as: fans not running, screens not turning off when the lid is closed, etc. This can stem from DSDTs made with Windows specifically in mind, which can be patched after installation. The goal of this article is to analyze and rebuild a faulty DSDT, so that the kernel can override the default one.<br />
<br />
Basically a DSDT table is the code run on ACPI (Power Management) events.<br />
<br />
{{Note|The goal of the [http://www.lesswatts.org/projects/acpi/ Linux ACPI] project is that Linux should work on unmodified firmware. If you still find this type of workaround necessary on modern kernels then you should consider [[Reporting Bug Guidelines|submiting a bug report]]. }}<br />
<br />
==Before you start...==<br />
* It is possible that the hardware manufacturer has released an updated firmware which fixes ACPI related problems. Installing an updated firmware is often preferred over this method because it would avoid duplication of effort.<br />
* This process does tamper with some fairly fundamental code on your installation. You will want to be absolutely sure of the changes you make. You might also wish to [[Disk cloning | clone your disk]] beforehand.<br />
* Even before attempting to fix your DSDT yourself, you can attempt a couple of different shortcuts: <br />
<br />
===Tell the kernel to report a version of Windows===<br />
<br />
Use the variable '''acpi_os_name''' as a kernel parameter. For example:<br />
<br />
acpi_os_name="Microsoft Windows NT"<br />
<br />
Or<br />
<br />
acpi_osi="!Windows2012"<br />
appended to the kernel line in grub legacy configuration<br />
<br />
other strings to test:<br />
* "Microsoft Windows XP"<br />
* "Microsoft Windows 2000"<br />
* "Microsoft Windows 2000.1"<br />
* "Microsoft Windows ME: Millennium Edition"<br />
* "Windows 2001"<br />
* "Windows 2006"<br />
* "Windows 2009"<br />
* "Windows 2012"<br />
* when all that fails, you can even try "Linux"<br />
<br />
Out of curiousity, you can follow the steps below to extract your DSDT and search the .dsl file. Just grep for "Windows" and see what pops up.<br />
<br />
===Find a fixed DSDT===<br />
A DSDT file is originally written in ACPI Source language (an .asl/.dsl file). Using a compiler this can produce an 'ACPI Machine Language' file (.aml) or a hex table (.hex). To incorporate the file in your Arch install, you will need to get hold of a compiled .aml file. - whether this means compiling it yourself or trusting some stranger on the Internet is at your discretion. If you do download a file from the world wide web, it will most likely be a compressed .asl file. So you will need to unzip it and compile it. The upside to this is that you won't have to research specific code fixes yourself.<br />
<br />
Arch users with the same laptop as you are: a minority of a minority of a minority. Try browsing other distro/linux forums for talk about the same model. Likelihood is that they have the same problems and either because there is a lot of them, or because they're tech savvy -- someone there has produced a working DSDT and maybe even provides a precompiled version (again, use at your own risk).<br />
Search engines are your best tools. Try keeping it short: 'model name' + 'dsdt' will probably produce results.<br />
<br />
== Recompiling it yourself ==<br />
Your best resources in this endeavor are going to be [http://en.gentoo-wiki.com/wiki/ACPI/Fix_common_problems The Gentoo wiki article], [http://www.acpi.info ACPI Spec homepage], and [http://www.lesswatts.org/projects/acpi/ Linux ACPI Project] which supercedes the activity that occurred at ''acpi.sourceforge.net''.<br />
In a nutshell, you can use Intel's ASL compiler to turn your systems DSDT table into source code, locate/fix the errors, and recompile. This process is detailed more comprehensively at the [http://en.gentoo-wiki.com/wiki/ACPI/Fix_common_problems Gentoo wiki].<br />
You'll need to install {{Pkg|iasl}} to modify code, and be familiar with [[Kernel_Compilation#Compilation]] to install it.<br />
<br />
'''What compiled the original code?'''<br />
Check if your system's DSDT was compiled using Intel or Microsoft compiler:<br />
{{hc|<nowiki> $ dmesg|grep DSDT</nowiki> |<br />
ACPI: DSDT 00000000bf7e5000 0A35F (v02 Intel CALPELLA 06040000 INTL 20060912)<br />
ACPI: EC: Look up EC in DSDT<br />
}}<br />
In case Microsoft's compiler had been used, abbreviation INTL would instead be MSFT.<br />
In the example, there were 5 errors on decompiling/recompiling the DSDT. Two of them were easy to fix after a bit of googling and delving into the ACPI specification. Three of them were due to different versions of compiler used and are, as later discovered, handled by the ACPICA at boot-time. The ACPICA component of the kernel can handle most of the trivial errors you get while compiling the DSDT. So do not fret yourself over compile errors if your system is ''working the way it should''.<br />
<br />
1.) Extract ACPI tables (as root): {{ic|# cat /sys/firmware/acpi/tables/DSDT > dsdt.dat}}<br />
<br />
2.) Decompile: {{ic|iasl -d dsdt.dat}}<br />
<br />
3.) Recompile: {{ic|iasl -tc dsdt.dsl}}<br />
<br />
4.) Examine errors and fix. e.g.:{{bc|<br />
dsdt.dsl 6727: Name (_PLD, Buffer (0x10) <br />
Error 4105 - Invalid object type for reserved name ^ (found BUFFER, requires Package) }}<br />
{{hc| nano +6727 dsdt.dsl|<br />
(_PLD, Package(1) {Buffer (0x10)...}}<br />
<br />
5.) Compile fixed code: {{ic|iasl -tc dsdt.dsl}} (Might want to try option -ic for C include file to insert into kernel source)<br />
<br />
If it says no errors and no warnings you should be good to go.<br />
<br />
== Using modified code ==<br />
{{Expansion| Detail each method}}<br />
<br />
There are 2 ways to use a custom DSDT Table:<br />
* loading the custom DSDT at runtime (recommended, since easier)<br />
* compiling the custom DSDT into the kernel<br />
<br />
=== Loading at runtime ===<br />
{{Warning|Loading at runtime don't supports. DSDT hook removed due to bug see FS#27906 bug}}<br />
Luckily the Arch stock kernel supports using a custom DSDT so, first copy the '''.aml''' file compiled by iasl to:<br />
/boot/dsdt.aml<br />
<br />
The bootloader will replace the DSDT so we need a method to include our custom DSDT table into the bootloader image.<br />
Copy the following to '''/etc/grub.d/01_acpi'''<br />
<br />
#!/bin/sh<br />
set -e<br />
<br />
# Uncomment to load custom ACPI table<br />
GRUB_CUSTOM_ACPI="/boot/dsdt.aml"<br />
<br />
<br />
# DON'T MODIFY ANYTHING BELOW THIS LINE!<br />
<br />
<br />
prefix=/usr<br />
exec_prefix=${prefix}<br />
libdir=${exec_prefix}/lib<br />
<br />
<br />
. /usr/share/grub/grub-mkconfig_lib<br />
#. ${libdir}/grub/grub-mkconfig_lib<br />
<br />
<br />
# Load custom ACPI table<br />
if [ x${GRUB_CUSTOM_ACPI} != x ] && [ -f ${GRUB_CUSTOM_ACPI} ] \<br />
&& is_path_readable_by_grub ${GRUB_CUSTOM_ACPI}; then<br />
echo "Found custom ACPI table: ${GRUB_CUSTOM_ACPI}" >&2<br />
prepare_grub_to_access_device `${grub_probe} --target=device ${GRUB_CUSTOM_ACPI}` | sed -e "s/^/ /"<br />
cat << EOF<br />
acpi (\$root)`make_system_path_relative_to_its_root ${GRUB_CUSTOM_ACPI}`<br />
EOF<br />
fi<br />
<br />
Make sure to make this file executable, or it will be ignored by '''grub-mkconfig'''<br />
chmod +x /etc/grub.d/01_acpi<br />
<br />
This will tell GRUB to include the DSDT into its core.img (change GRUB_CUSTOM_ACPI to reflect the path to your .aml file).<br />
Next you will need a new boot image. If you use GRUB run:<br />
grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
Lastly, recreate your initrd<br />
mkinitcpio -p linux<br />
and reboot. Done!<br />
<br />
To check if you are really using your own DSDT read your table again {{ic|# cat /sys/firmware/acpi/tables/DSDT > dsdt.dat}}<br />
and decompile it with {{ic|iasl -d dsdt.dat}}<br />
<br />
=== Compile into kernel ===<br />
You'll want to be familiar with [[Kernels | compiling your own kernel]]. The most straightforward way is with the "traditional" approach.<br />
<br />
'''Using {{ic|menuconfig}}:'''<br />
* Disable "Select only drivers that don't need compile-time external firmware".<br />
* Enable "Include Custom DSDT" and specify the absolute path of your fixed DSDT file.</div>Swiftiehttps://wiki.archlinux.org/index.php?title=DSDT&diff=268038DSDT2013-07-26T11:27:01Z<p>Swiftie: /* Tell the kernel to report a version of Windows */</p>
<hr />
<div>[[Category:Boot process]]<br />
[[Category:Kernel]]<br />
[[Category:Power management]]<br />
DSDT (Differentiated System Description Table) is a part of the [[Wikipedia:ACPI|ACPI]] specification. It supplies information about supported power events in a given system. ACPI tables are provided in firmware from the manufacturer. A common Linux problems are missing ACPI functionality, such as: fans not running, screens not turning off when the lid is closed, etc. This can stem from DSDTs made with Windows specifically in mind, which can be patched after installation. The goal of this article is to analyze and rebuild a faulty DSDT, so that the kernel can override the default one.<br />
<br />
Basically a DSDT table is the code run on ACPI (Power Management) events.<br />
<br />
{{Note|The goal of the [http://www.lesswatts.org/projects/acpi/ Linux ACPI] project is that Linux should work on unmodified firmware. If you still find this type of workaround necessary on modern kernels then you should consider [[Reporting Bug Guidelines|submiting a bug report]]. }}<br />
<br />
==Before you start...==<br />
* It is possible that the hardware manufacturer has released an updated firmware which fixes ACPI related problems. Installing an updated firmware is often preferred over this method because it would avoid duplication of effort.<br />
* This process does tamper with some fairly fundamental code on your installation. You will want to be absolutely sure of the changes you make. You might also wish to [[Disk cloning | clone your disk]] beforehand.<br />
* Even before attempting to fix your DSDT yourself, you can attempt a couple of different shortcuts: <br />
<br />
===Tell the kernel to report a version of Windows===<br />
<br />
Use the variable '''acpi_os_name''' as a kernel parameter. For example:<br />
<br />
acpi_os_name="Microsoft Windows NT"<br />
<br />
Or<br />
<br />
acpi_osi="!Windows2012"<br />
appended to the kernel line in grub legacy configuration<br />
<br />
other strings to test:<br />
* "Microsoft Windows XP"<br />
* "Microsoft Windows 2000"<br />
* "Microsoft Windows 2000.1"<br />
* "Microsoft Windows ME: Millennium Edition"<br />
* "Windows 2001"<br />
* "Windows 2006"<br />
* "Windows 2009"<br />
* "Windows 2012"<br />
* when all that fails, you can even try "Linux"<br />
<br />
Out of curiousity, you can follow the steps below to extract your DSDT and search the .dsl file. Just grep for "Windows" and see what pops up.<br />
<br />
===Find a fixed DSDT===<br />
A DSDT file is originally written in ACPI Source language (an .asl/.dsl file). Using a compiler this can produce an 'ACPI Machine Language' file (.aml) or a hex table (.hex). To incorporate the file in your Arch install, you will need to get hold of a compiled .aml file. - whether this means compiling it yourself or trusting some stranger on the Internet is at your discretion. If you do download a file from the world wide web, it will most likely be a compressed .asl file. So you will need to unzip it and compile it. The upside to this is that you won't have to research specific code fixes yourself.<br />
<br />
Arch users with the same laptop as you are: a minority of a minority of a minority. Try browsing other distro/linux forums for talk about the same model. Likelihood is that they have the same problems and either because there is a lot of them, or because they're tech savvy -- someone there has produced a working DSDT and maybe even provides a precompiled version (again, use at your own risk).<br />
Search engines are your best tools. Try keeping it short: 'model name' + 'dsdt' will probably produce results.<br />
<br />
== Recompiling it yourself ==<br />
Your best resources in this endeavor are going to be [http://en.gentoo-wiki.com/wiki/ACPI/Fix_common_problems The Gentoo wiki article], [http://www.acpi.info ACPI Spec homepage], and [http://www.lesswatts.org/projects/acpi/ Linux ACPI Project] which supercedes the activity that occurred at ''acpi.sourceforge.net''.<br />
In a nutshell, you can use Intel's ASL compiler to turn your systems DSDT table into source code, locate/fix the errors, and recompile. This process is detailed more comprehensively at the [http://en.gentoo-wiki.com/wiki/ACPI/Fix_common_problems Gentoo wiki].<br />
You'll need to install {{Pkg|iasl}} to modify code, and be familiar with [[Kernel_Compilation#Compilation]] to install it.<br />
<br />
'''What compiled the original code?'''<br />
Check if your system's DSDT was compiled using Intel or Microsoft compiler:<br />
{{hc|<nowiki> $ dmesg|grep DSDT</nowiki> |<br />
ACPI: DSDT 00000000bf7e5000 0A35F (v02 Intel CALPELLA 06040000 INTL 20060912)<br />
ACPI: EC: Look up EC in DSDT<br />
}}<br />
In case Microsoft's compiler had been used, abbreviation INTL would instead be MSFT.<br />
In the example, there were 5 errors on decompiling/recompiling the DSDT. Two of them were easy to fix after a bit of googling and delving into the ACPI specification. Three of them were due to different versions of compiler used and are, as later discovered, handled by the ACPICA at boot-time. The ACPICA component of the kernel can handle most of the trivial errors you get while compiling the DSDT. So do not fret yourself over compile errors if your system is ''working the way it should''.<br />
<br />
1.) Extract ACPI tables (as root): {{ic|# cat /sys/firmware/acpi/tables/DSDT > dsdt.dat}}<br />
<br />
2.) Decompile: {{ic|iasl -d dsdt.dat}}<br />
<br />
3.) Recompile: {{ic|iasl -tc dsdt.dsl}}<br />
<br />
4.) Examine errors and fix. e.g.:{{bc|<br />
dsdt.dsl 6727: Name (_PLD, Buffer (0x10) <br />
Error 4105 - Invalid object type for reserved name ^ (found BUFFER, requires Package) }}<br />
{{hc| nano +6727 dsdt.dsl|<br />
(_PLD, Package(1) {Buffer (0x10)...}}<br />
<br />
5.) Compile fixed code: {{ic|iasl -tc dsdt.dsl}} (Might want to try option -ic for C include file to insert into kernel source)<br />
<br />
If it says no errors and no warnings you should be good to go.<br />
<br />
== Using modified code ==<br />
{{Expansion| Detail each method}}<br />
<br />
There are 2 ways to use a custom DSDT Table:<br />
* loading the custom DSDT at runtime (recommended, since easier)<br />
* compiling the custom DSDT into the kernel<br />
<br />
=== Loading at runtime ===<br />
Luckily the Arch stock kernel supports using a custom DSDT so, first copy the '''.aml''' file compiled by iasl to:<br />
/boot/dsdt.aml<br />
<br />
The bootloader will replace the DSDT so we need a method to include our custom DSDT table into the bootloader image.<br />
Copy the following to '''/etc/grub.d/01_acpi'''<br />
<br />
#!/bin/sh<br />
set -e<br />
<br />
# Uncomment to load custom ACPI table<br />
GRUB_CUSTOM_ACPI="/boot/dsdt.aml"<br />
<br />
<br />
# DON'T MODIFY ANYTHING BELOW THIS LINE!<br />
<br />
<br />
prefix=/usr<br />
exec_prefix=${prefix}<br />
libdir=${exec_prefix}/lib<br />
<br />
<br />
. /usr/share/grub/grub-mkconfig_lib<br />
#. ${libdir}/grub/grub-mkconfig_lib<br />
<br />
<br />
# Load custom ACPI table<br />
if [ x${GRUB_CUSTOM_ACPI} != x ] && [ -f ${GRUB_CUSTOM_ACPI} ] \<br />
&& is_path_readable_by_grub ${GRUB_CUSTOM_ACPI}; then<br />
echo "Found custom ACPI table: ${GRUB_CUSTOM_ACPI}" >&2<br />
prepare_grub_to_access_device `${grub_probe} --target=device ${GRUB_CUSTOM_ACPI}` | sed -e "s/^/ /"<br />
cat << EOF<br />
acpi (\$root)`make_system_path_relative_to_its_root ${GRUB_CUSTOM_ACPI}`<br />
EOF<br />
fi<br />
<br />
Make sure to make this file executable, or it will be ignored by '''grub-mkconfig'''<br />
chmod +x /etc/grub.d/01_acpi<br />
<br />
This will tell GRUB to include the DSDT into its core.img (change GRUB_CUSTOM_ACPI to reflect the path to your .aml file).<br />
Next you will need a new boot image. If you use GRUB run:<br />
grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
Lastly, recreate your initrd<br />
mkinitcpio -p linux<br />
and reboot. Done!<br />
<br />
To check if you are really using your own DSDT read your table again {{ic|# cat /sys/firmware/acpi/tables/DSDT > dsdt.dat}}<br />
and decompile it with {{ic|iasl -d dsdt.dat}}<br />
<br />
=== Compile into kernel ===<br />
You'll want to be familiar with [[Kernels | compiling your own kernel]]. The most straightforward way is with the "traditional" approach.<br />
<br />
'''Using {{ic|menuconfig}}:'''<br />
* Disable "Select only drivers that don't need compile-time external firmware".<br />
* Enable "Include Custom DSDT" and specify the absolute path of your fixed DSDT file.</div>Swiftiehttps://wiki.archlinux.org/index.php?title=Backlight&diff=267107Backlight2013-07-19T22:50:02Z<p>Swiftie: </p>
<hr />
<div>[[Category:Laptops]]<br />
[[Category:Power management]]<br />
Screen brightness can often be tricky to control. On many machines, physical hardware switches are missing and software solutions may or may not work well. Make sure to find a working method for your hardware! Too bright screens can cause eye strain.<br />
<br />
There are many ways to adjust the screen backlight of a monitor, laptop or integrated panel (such as the iMac) using software, but depending on hardware and model, sometimes only some options are available. This article aims to summarize all possible ways to adjust the backlight.<br />
<br />
==Overview==<br />
There are many ways to control brightness. According to this discussion[https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/397617] and this wiki page [https://wiki.ubuntu.com/Kernel/Debugging/Backlight], the control method could be divided into these categories:<br />
* brightness is controlled by vendor specified hotkey. And there is no interface for OS to adjust brightness. <br />
* brightness is controlled by OS:<br />
** brightness could be controlled by ACPI<br />
** brightness could be controlled by graphic driver.<br />
All methods expose themselves to the user by /sys/class/brightness. And xrandr/xbacklight could use this folder and choose one method to control brightness. But it is still not very clear which one xbacklight prefers by default.<br />
''See FS#27677 for xbacklight, if you get "No outputs have backlight property."'' There is a temporary fix if xrandr/xbacklight does not choose the right directory in /sys/class/brightness: You can specify the one you want in xorg.conf by setting the "Backlight" option of the Device section to the name of that directory (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=651741 at the bottom of the page for details).<br />
* brightness is controlled by HW register throught setpci<br />
<br />
==ACPI==<br />
It is often possible to adjust the backlight by ACPI. This controls the actual LEDs or cathodes of the screen. When this ACPI option is available, the illumination is controllable using a GUI slider in the Display/Screen system settings or by simple commands on the CLI.<br />
<br />
Different cards might manage this differently. Check {{ic|/sys/class/backlight}} to find out:<br />
{{hc|# ls /sys/class/backlight/|<br />
intel_backlight<br />
}}<br />
<br />
So this particular backlight is managed by an Intel card. It is called {{ic|acpi_video0}} on an ATI card. In the following example, acpi_video0 is used.<br />
<br />
The directory contains the following files and folders:<br />
<br />
actual_brightness brightness max_brightness subsystem/ uevent <br />
bl_power device/ power/ type<br />
<br />
The maximum brightness (often 15) can be found by running {{ic|cat}}:<br />
<br />
# cat /sys/class/backlight/acpi_video0/max_brightness<br />
15<br />
<br />
Brightness can then be set (as root) with {{ic|echo}}. Obviously you cannot go any higher than your screen's maximum brightness. The values for maximum brightness and brightness in general vary wildly among cards. <br />
<br />
# echo 5 > /sys/class/backlight/acpi_video0/brightness<br />
<br />
Sometimes ACPI does not work well due to different motherboard implementations and ACPI quirks. This include some models with dual graphics (e.g. Nvidia-optimus/Radeon with intel (i915)) and some examples with this problem in notebooks such as Dell Studio, Dell XPS 14/15/17 and some Lenovo series, Kamal Mostafa kernel developer make [https://launchpad.net/~kamalmostafa/+archive/linux-kamal-mjgbacklight patches] for solved this problem included after 3.1 kernel version. You can try adding the following kernel parameters in your bootloader(grub, syslinux...) to adjust ACPI model:<br />
<br />
acpi_osi=Linux acpi_backlight=vendor<br />
<br />
or<br />
<br />
acpi_osi=Linux acpi_backlight=legacy<br />
''acpi_backlight=vendor will prefer vendor specific driver (e.g. thinkpad_acpi, sony_acpi, etc.) instead of the ACPI video.ko driver.''<br />
<br />
<br />
{{Tip|On some new laptops with pre-installed Windows 8 and/or hybrid graphics<br />
You need to add kernel flag to control backlight:<br />
<nowiki>acpi_osi="!Windows2012" </nowiki><br />
}}<br />
<br />
==Switching off the backlight==<br />
<br />
Switching off the backlight (for example when one locks the notebook) can be useful to conserve battery energy. Ideally the following command inside of a graphical session should work:<br />
sleep 1 && xset dpms force off<br />
The backlight should switch on again on mouse movement or keyboard input. If the previous command does not work, there is a chance that {{ic|vbetool}} works. Note, however, that in this case the backlight must be manually activated again. The command is as follows:<br />
vbetool dpms off<br />
To activate the backlight again:<br />
vbetool dpms on<br />
<br />
For example, this can be put to use when closing the notebook lid as outlined in the entry for [[Acpid#Laptop_Monitor_Power_Off|Acipd]].<br />
<br />
<br />
==Backlight utilities==<br />
===xbacklight===<br />
You can adjust the backlight through the xorg-server command {{ic|xbacklight}}. The utility is provided by the {{Pkg|xorg-xbacklight}} package in [extra].<br />
<br />
A useful demonstration was posted by [http://www.youtube.com/watch?v=_pi3iKMAJcY gotbletu on YouTube]. He suggests the following commands to adjust the backlight:<br />
<br />
* brighten up:<br />
xbacklight -inc 40<br />
<br />
* dim down:<br />
xbacklight -dec 40<br />
<br />
===xcalib===<br />
The program [http://xcalib.sourceforge.net/ xcalib] can be downloaded from [https://aur.archlinux.org/packages.php?ID=10969 AUR] and used to dim the screen. Again, the user gotbletu posted a demonstration on [http://www.youtube.com/watch?v=A9xsvntT6i4 Youtube]. This program can correct gamma, invert colors and reduce contrast, the latter of which we use in this case:<br />
<br />
* dim down:<br />
xcalib -co 40 -a<br />
<br />
This program uses ICC technology to interact with X11 and while the screen is dimmed, you may find that the mouse cursor is just as bright as before.<br />
<br />
===redshift===<br />
The program [http://jonls.dk/redshift/ redshift] in the community repository uses {{ic|randr}} to adjust the screen brightness depending on the time of day and your geographic position. It can also do RGB gamma corrections and set color temperatures. As with {{ic|xcalib}}, this is very much a software solution and the look of the mouse cursor is unaffected. To execute a single quick adjustment of the brightness, try something like this:<br />
<br />
redshift -o -l 0:0 -b 0.8 -t 6500:6500<br />
<br />
{{Tip|If your longitude is west or your latitude is south, you should input it as negative.<br />
Example for Berkeley, CA: <br />
gtk-redshift -l 37.8717:-122.2728 <br />
}}<br />
<br />
===relight===<br />
[http://xyne.archlinux.ca/projects/relight relight] is available in [http://xyne.archlinux.ca/repos Xyne's repos] and [https://aur.archlinux.org/packages.php?ID=66487 the AUR]. The package provides a service to automatically restore previous backlight settings during reboot along using the ACPI method explained above. The package also contains a dialog-based menu for selecting and configuring backlights for different screens.<br />
<br />
===setpci (use with great care)===<br />
It is possible to set the register of the graphic card to adjust the backlight. It means you adjust the backlight by manipulating the hardware directly, which can be risky and generally is not a good idea. Not all of the graphic cards support this method.<br />
<br />
When using this method, you need to use {{ic|lspci}} first to find out where your graphic card is.<br />
# setpci -s 00:02.0 F4.B=0<br />
<br />
===Calise===<br />
The software [http://calise.sourceforge.net/wordpress/ calise] can be found in AUR.<br />
* Stable version: {{AUR|calise}}<br />
* Development version: {{AUR|calise-git}} <br />
<br />
It basically computes ambient brightness, and set screen's correct backlight, simply making captures from the webcam, for laptop without light sensor.<br />
For more information, calise has its own wiki: [http://calise.sourceforge.net/mediawiki/index.php/Main_Page Calise wiki].<br />
<br />
The main features of this program are that it's very precise, very light on resource usage, and with the daemon version (.service file for systemd users available too), it has practically no impact on battery life.<br />
<br />
===brightd===<br />
Macbook-inspired {{AUR|brightd}} automatically dims (but doesn't put to standby) the screen when there is no user input for some time. A good companion of [[Display Power Management Signaling]] so that the screen doesn't blank out in a sudden.<br />
<br />
== KDE ==<br />
[[KDE]] users can adjust the backlight via System Settings -> Power Management -> Power Profiles.<br />
If you want set backlight before kdm just put in /usr/share/config/kdm/Xsetup :<br />
<br />
xbacklight -inc 10<br />
<br />
== NVIDIA Settings ==<br />
Users of [[NVIDIA|NVIDIA's proprietary drivers]] users can change display brightness via the nvidia-settings utility under "X Server Color Correction." However, note that this has absolutely nothing to do with backlight (intensity), it merely adjusts the color output. (Reducing brightness this way is a power-inefficient last resort when all other options fail; increasing brightness spoils your color output completely, in a way similar to overexposed photos.)<br />
<br />
== Backlight PWM modulation frequency (Intel i915 only) ==<br />
Laptops with LED backlight are known to have screen flicker sometimes. The reason for this, is that it is hard enough to dim LEDs by limiting direct current flowing through. It is easier to control brightness by switching LEDs on and off fast enough.<br />
<br />
However, frequency of the switching (so-called PWM modulation frequency) is not high enough actually, and some people may notice flicker either explicitly or by feeling headache and eyestrain.<br />
<br />
If you have an Intel i915 GPU, then it may be possible to adjust PWM modulation frequency to eliminate flicker.<br />
<br />
Install intel-gpu-tools from community repo<br />
<br />
# pacman -S intel-gpu-tools<br />
<br />
Get value of the register, that determines PWM modulation frequency<br />
<br />
# intel_reg_read 0xC8254<br />
0xC8254 : 0x12281228<br />
<br />
The value returned represents period of PWM modulation. So to increase PWM modulation frequency, value of the register has to be reduced. For example, to double frequency from the previous listing, execute<br />
<br />
# intel_reg_write 0xC8254 0x09140914<br />
<br />
You can use online calculator to calculate desired value http://devbraindom.blogspot.com/2013/03/eliminate-led-screen-flicker-with-intel.html<br />
<br />
Refer to dedicated topic for details https://bbs.archlinux.org/viewtopic.php?pid=1245913</div>Swiftiehttps://wiki.archlinux.org/index.php?title=DSDT&diff=267105DSDT2013-07-19T22:35:37Z<p>Swiftie: /* Tell the kernel to report a version of Windows */</p>
<hr />
<div>[[Category:Boot process]]<br />
[[Category:Kernel]]<br />
[[Category:Power management]]<br />
DSDT (Differentiated System Description Table) is a part of the [[Wikipedia:ACPI|ACPI]] specification. It supplies information about supported power events in a given system. ACPI tables are provided in firmware from the manufacturer. A common Linux problems are missing ACPI functionality, such as: fans not running, screens not turning off when the lid is closed, etc. This can stem from DSDTs made with Windows specifically in mind, which can be patched after installation. The goal of this article is to analyze and rebuild a faulty DSDT, so that the kernel can override the default one.<br />
<br />
Basically a DSDT table is the code run on ACPI (Power Management) events.<br />
<br />
{{Note|The goal of the [http://www.lesswatts.org/projects/acpi/ Linux ACPI] project is that Linux should work on unmodified firmware. If you still find this type of workaround necessary on modern kernels then you should consider [[Reporting Bug Guidelines|submiting a bug report]]. }}<br />
<br />
==Before you start...==<br />
* It is possible that the hardware manufacturer has released an updated firmware which fixes ACPI related problems. Installing an updated firmware is often preferred over this method because it would avoid duplication of effort.<br />
* This process does tamper with some fairly fundamental code on your installation. You will want to be absolutely sure of the changes you make. You might also wish to [[Disk cloning | clone your disk]] beforehand.<br />
* Even before attempting to fix your DSDT yourself, you can attempt a couple of different shortcuts: <br />
<br />
===Tell the kernel to report a version of Windows===<br />
<br />
Use the variable '''acpi_os_name''' as a kernel parameter. For example:<br />
<br />
acpi_os_name="Microsoft Windows NT"<br />
appended to the kernel line in grub legacy configuration<br />
<br />
other strings to test:<br />
* "Microsoft Windows XP"<br />
* "Microsoft Windows 2000"<br />
* "Microsoft Windows 2000.1"<br />
* "Microsoft Windows ME: Millennium Edition"<br />
* "Windows 2001"<br />
* "Windows 2006"<br />
* "Windows 2009"<br />
* "Windows 2012"<br />
* when all that fails, you can even try "Linux"<br />
<br />
Out of curiousity, you can follow the steps below to extract your DSDT and search the .dsl file. Just grep for "Windows" and see what pops up.<br />
<br />
===Find a fixed DSDT===<br />
A DSDT file is originally written in ACPI Source language (an .asl/.dsl file). Using a compiler this can produce an 'ACPI Machine Language' file (.aml) or a hex table (.hex). To incorporate the file in your Arch install, you will need to get hold of a compiled .aml file. - whether this means compiling it yourself or trusting some stranger on the Internet is at your discretion. If you do download a file from the world wide web, it will most likely be a compressed .asl file. So you will need to unzip it and compile it. The upside to this is that you won't have to research specific code fixes yourself.<br />
<br />
Arch users with the same laptop as you are: a minority of a minority of a minority. Try browsing other distro/linux forums for talk about the same model. Likelihood is that they have the same problems and either because there is a lot of them, or because they're tech savvy -- someone there has produced a working DSDT and maybe even provides a precompiled version (again, use at your own risk).<br />
Search engines are your best tools. Try keeping it short: 'model name' + 'dsdt' will probably produce results.<br />
<br />
== Recompiling it yourself ==<br />
Your best resources in this endeavor are going to be [http://en.gentoo-wiki.com/wiki/ACPI/Fix_common_problems The Gentoo wiki article], [http://www.acpi.info ACPI Spec homepage], and [http://www.lesswatts.org/projects/acpi/ Linux ACPI Project] which supercedes the activity that occurred at ''acpi.sourceforge.net''.<br />
In a nutshell, you can use Intel's ASL compiler to turn your systems DSDT table into source code, locate/fix the errors, and recompile. This process is detailed more comprehensively at the [http://en.gentoo-wiki.com/wiki/ACPI/Fix_common_problems Gentoo wiki].<br />
You'll need to install {{Pkg|iasl}} to modify code, and be familiar with [[Kernel_Compilation#Compilation]] to install it.<br />
<br />
'''What compiled the original code?'''<br />
Check if your system's DSDT was compiled using Intel or Microsoft compiler:<br />
{{hc|<nowiki> $ dmesg|grep DSDT</nowiki> |<br />
ACPI: DSDT 00000000bf7e5000 0A35F (v02 Intel CALPELLA 06040000 INTL 20060912)<br />
ACPI: EC: Look up EC in DSDT<br />
}}<br />
In case Microsoft's compiler had been used, abbreviation INTL would instead be MSFT.<br />
In the example, there were 5 errors on decompiling/recompiling the DSDT. Two of them were easy to fix after a bit of googling and delving into the ACPI specification. Three of them were due to different versions of compiler used and are, as later discovered, handled by the ACPICA at boot-time. The ACPICA component of the kernel can handle most of the trivial errors you get while compiling the DSDT. So do not fret yourself over compile errors if your system is ''working the way it should''.<br />
<br />
1.) Extract ACPI tables (as root): {{ic|# cat /sys/firmware/acpi/tables/DSDT > dsdt.dat}}<br />
<br />
2.) Decompile: {{ic|iasl -d dsdt.dat}}<br />
<br />
3.) Recompile: {{ic|iasl -tc dsdt.dsl}}<br />
<br />
4.) Examine errors and fix. e.g.:{{bc|<br />
dsdt.dsl 6727: Name (_PLD, Buffer (0x10) <br />
Error 4105 - Invalid object type for reserved name ^ (found BUFFER, requires Package) }}<br />
{{hc| nano +6727 dsdt.dsl|<br />
(_PLD, Package(1) {Buffer (0x10)...}}<br />
<br />
5.) Compile fixed code: {{ic|iasl -tc dsdt.dsl}} (Might want to try option -ic for C include file to insert into kernel source)<br />
<br />
If it says no errors and no warnings you should be good to go.<br />
<br />
== Using modified code ==<br />
{{Expansion| Detail each method}}<br />
<br />
There are 2 ways to use a custom DSDT Table:<br />
* loading the custom DSDT at runtime (recommended, since easier)<br />
* compiling the custom DSDT into the kernel<br />
<br />
=== Loading at runtime ===<br />
Luckily the Arch stock kernel supports using a custom DSDT so, first copy the '''.aml''' file compiled by iasl to:<br />
/boot/dsdt.aml<br />
<br />
The bootloader will replace the DSDT so we need a method to include our custom DSDT table into the bootloader image.<br />
Copy the following to '''/etc/grub.d/01_acpi'''<br />
<br />
#!/bin/sh<br />
set -e<br />
<br />
# Uncomment to load custom ACPI table<br />
GRUB_CUSTOM_ACPI="/boot/dsdt.aml"<br />
<br />
<br />
# DON'T MODIFY ANYTHING BELOW THIS LINE!<br />
<br />
<br />
prefix=/usr<br />
exec_prefix=${prefix}<br />
libdir=${exec_prefix}/lib<br />
<br />
<br />
. /usr/share/grub/grub-mkconfig_lib<br />
#. ${libdir}/grub/grub-mkconfig_lib<br />
<br />
<br />
# Load custom ACPI table<br />
if [ x${GRUB_CUSTOM_ACPI} != x ] && [ -f ${GRUB_CUSTOM_ACPI} ] \<br />
&& is_path_readable_by_grub ${GRUB_CUSTOM_ACPI}; then<br />
echo "Found custom ACPI table: ${GRUB_CUSTOM_ACPI}" >&2<br />
prepare_grub_to_access_device `${grub_probe} --target=device ${GRUB_CUSTOM_ACPI}` | sed -e "s/^/ /"<br />
cat << EOF<br />
acpi (\$root)`make_system_path_relative_to_its_root ${GRUB_CUSTOM_ACPI}`<br />
EOF<br />
fi<br />
<br />
Make sure to make this file executable, or it will be ignored by '''grub-mkconfig'''<br />
chmod +x /etc/grub.d/01_acpi<br />
<br />
This will tell GRUB to include the DSDT into its core.img (change GRUB_CUSTOM_ACPI to reflect the path to your .aml file).<br />
Next you will need a new boot image. If you use GRUB run:<br />
grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
Lastly, recreate your initrd<br />
mkinitcpio -p linux<br />
and reboot. Done!<br />
<br />
To check if you are really using your own DSDT read your table again {{ic|# cat /sys/firmware/acpi/tables/DSDT > dsdt.dat}}<br />
and decompile it with {{ic|iasl -d dsdt.dat}}<br />
<br />
=== Compile into kernel ===<br />
You'll want to be familiar with [[Kernels | compiling your own kernel]]. The most straightforward way is with the "traditional" approach.<br />
<br />
'''Using {{ic|menuconfig}}:'''<br />
* Disable "Select only drivers that don't need compile-time external firmware".<br />
* Enable "Include Custom DSDT" and specify the absolute path of your fixed DSDT file.</div>Swiftiehttps://wiki.archlinux.org/index.php?title=DSDT&diff=267104DSDT2013-07-19T22:35:15Z<p>Swiftie: /* Tell the kernel to report a version of Windows */</p>
<hr />
<div>[[Category:Boot process]]<br />
[[Category:Kernel]]<br />
[[Category:Power management]]<br />
DSDT (Differentiated System Description Table) is a part of the [[Wikipedia:ACPI|ACPI]] specification. It supplies information about supported power events in a given system. ACPI tables are provided in firmware from the manufacturer. A common Linux problems are missing ACPI functionality, such as: fans not running, screens not turning off when the lid is closed, etc. This can stem from DSDTs made with Windows specifically in mind, which can be patched after installation. The goal of this article is to analyze and rebuild a faulty DSDT, so that the kernel can override the default one.<br />
<br />
Basically a DSDT table is the code run on ACPI (Power Management) events.<br />
<br />
{{Note|The goal of the [http://www.lesswatts.org/projects/acpi/ Linux ACPI] project is that Linux should work on unmodified firmware. If you still find this type of workaround necessary on modern kernels then you should consider [[Reporting Bug Guidelines|submiting a bug report]]. }}<br />
<br />
==Before you start...==<br />
* It is possible that the hardware manufacturer has released an updated firmware which fixes ACPI related problems. Installing an updated firmware is often preferred over this method because it would avoid duplication of effort.<br />
* This process does tamper with some fairly fundamental code on your installation. You will want to be absolutely sure of the changes you make. You might also wish to [[Disk cloning | clone your disk]] beforehand.<br />
* Even before attempting to fix your DSDT yourself, you can attempt a couple of different shortcuts: <br />
<br />
===Tell the kernel to report a version of Windows===<br />
<br />
Use the variable '''acpi_os_name''' as a kernel parameter. For example:<br />
<br />
acpi_os_name="Microsoft Windows NT"<br />
appended to the kernel line in grub legacy configuration<br />
<br />
other strings to test:<br />
* "Microsoft Windows XP"<br />
* "Microsoft Windows 2000"<br />
* "Microsoft Windows 2000.1"<br />
* "Microsoft Windows ME: Millennium Edition"<br />
* "Windows 2001"<br />
* "Windows 2006"<br />
* "Windows 2009"<br />
* "!Windows 2012"<br />
* when all that fails, you can even try "Linux"<br />
<br />
Out of curiousity, you can follow the steps below to extract your DSDT and search the .dsl file. Just grep for "Windows" and see what pops up.<br />
<br />
===Find a fixed DSDT===<br />
A DSDT file is originally written in ACPI Source language (an .asl/.dsl file). Using a compiler this can produce an 'ACPI Machine Language' file (.aml) or a hex table (.hex). To incorporate the file in your Arch install, you will need to get hold of a compiled .aml file. - whether this means compiling it yourself or trusting some stranger on the Internet is at your discretion. If you do download a file from the world wide web, it will most likely be a compressed .asl file. So you will need to unzip it and compile it. The upside to this is that you won't have to research specific code fixes yourself.<br />
<br />
Arch users with the same laptop as you are: a minority of a minority of a minority. Try browsing other distro/linux forums for talk about the same model. Likelihood is that they have the same problems and either because there is a lot of them, or because they're tech savvy -- someone there has produced a working DSDT and maybe even provides a precompiled version (again, use at your own risk).<br />
Search engines are your best tools. Try keeping it short: 'model name' + 'dsdt' will probably produce results.<br />
<br />
== Recompiling it yourself ==<br />
Your best resources in this endeavor are going to be [http://en.gentoo-wiki.com/wiki/ACPI/Fix_common_problems The Gentoo wiki article], [http://www.acpi.info ACPI Spec homepage], and [http://www.lesswatts.org/projects/acpi/ Linux ACPI Project] which supercedes the activity that occurred at ''acpi.sourceforge.net''.<br />
In a nutshell, you can use Intel's ASL compiler to turn your systems DSDT table into source code, locate/fix the errors, and recompile. This process is detailed more comprehensively at the [http://en.gentoo-wiki.com/wiki/ACPI/Fix_common_problems Gentoo wiki].<br />
You'll need to install {{Pkg|iasl}} to modify code, and be familiar with [[Kernel_Compilation#Compilation]] to install it.<br />
<br />
'''What compiled the original code?'''<br />
Check if your system's DSDT was compiled using Intel or Microsoft compiler:<br />
{{hc|<nowiki> $ dmesg|grep DSDT</nowiki> |<br />
ACPI: DSDT 00000000bf7e5000 0A35F (v02 Intel CALPELLA 06040000 INTL 20060912)<br />
ACPI: EC: Look up EC in DSDT<br />
}}<br />
In case Microsoft's compiler had been used, abbreviation INTL would instead be MSFT.<br />
In the example, there were 5 errors on decompiling/recompiling the DSDT. Two of them were easy to fix after a bit of googling and delving into the ACPI specification. Three of them were due to different versions of compiler used and are, as later discovered, handled by the ACPICA at boot-time. The ACPICA component of the kernel can handle most of the trivial errors you get while compiling the DSDT. So do not fret yourself over compile errors if your system is ''working the way it should''.<br />
<br />
1.) Extract ACPI tables (as root): {{ic|# cat /sys/firmware/acpi/tables/DSDT > dsdt.dat}}<br />
<br />
2.) Decompile: {{ic|iasl -d dsdt.dat}}<br />
<br />
3.) Recompile: {{ic|iasl -tc dsdt.dsl}}<br />
<br />
4.) Examine errors and fix. e.g.:{{bc|<br />
dsdt.dsl 6727: Name (_PLD, Buffer (0x10) <br />
Error 4105 - Invalid object type for reserved name ^ (found BUFFER, requires Package) }}<br />
{{hc| nano +6727 dsdt.dsl|<br />
(_PLD, Package(1) {Buffer (0x10)...}}<br />
<br />
5.) Compile fixed code: {{ic|iasl -tc dsdt.dsl}} (Might want to try option -ic for C include file to insert into kernel source)<br />
<br />
If it says no errors and no warnings you should be good to go.<br />
<br />
== Using modified code ==<br />
{{Expansion| Detail each method}}<br />
<br />
There are 2 ways to use a custom DSDT Table:<br />
* loading the custom DSDT at runtime (recommended, since easier)<br />
* compiling the custom DSDT into the kernel<br />
<br />
=== Loading at runtime ===<br />
Luckily the Arch stock kernel supports using a custom DSDT so, first copy the '''.aml''' file compiled by iasl to:<br />
/boot/dsdt.aml<br />
<br />
The bootloader will replace the DSDT so we need a method to include our custom DSDT table into the bootloader image.<br />
Copy the following to '''/etc/grub.d/01_acpi'''<br />
<br />
#!/bin/sh<br />
set -e<br />
<br />
# Uncomment to load custom ACPI table<br />
GRUB_CUSTOM_ACPI="/boot/dsdt.aml"<br />
<br />
<br />
# DON'T MODIFY ANYTHING BELOW THIS LINE!<br />
<br />
<br />
prefix=/usr<br />
exec_prefix=${prefix}<br />
libdir=${exec_prefix}/lib<br />
<br />
<br />
. /usr/share/grub/grub-mkconfig_lib<br />
#. ${libdir}/grub/grub-mkconfig_lib<br />
<br />
<br />
# Load custom ACPI table<br />
if [ x${GRUB_CUSTOM_ACPI} != x ] && [ -f ${GRUB_CUSTOM_ACPI} ] \<br />
&& is_path_readable_by_grub ${GRUB_CUSTOM_ACPI}; then<br />
echo "Found custom ACPI table: ${GRUB_CUSTOM_ACPI}" >&2<br />
prepare_grub_to_access_device `${grub_probe} --target=device ${GRUB_CUSTOM_ACPI}` | sed -e "s/^/ /"<br />
cat << EOF<br />
acpi (\$root)`make_system_path_relative_to_its_root ${GRUB_CUSTOM_ACPI}`<br />
EOF<br />
fi<br />
<br />
Make sure to make this file executable, or it will be ignored by '''grub-mkconfig'''<br />
chmod +x /etc/grub.d/01_acpi<br />
<br />
This will tell GRUB to include the DSDT into its core.img (change GRUB_CUSTOM_ACPI to reflect the path to your .aml file).<br />
Next you will need a new boot image. If you use GRUB run:<br />
grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
Lastly, recreate your initrd<br />
mkinitcpio -p linux<br />
and reboot. Done!<br />
<br />
To check if you are really using your own DSDT read your table again {{ic|# cat /sys/firmware/acpi/tables/DSDT > dsdt.dat}}<br />
and decompile it with {{ic|iasl -d dsdt.dat}}<br />
<br />
=== Compile into kernel ===<br />
You'll want to be familiar with [[Kernels | compiling your own kernel]]. The most straightforward way is with the "traditional" approach.<br />
<br />
'''Using {{ic|menuconfig}}:'''<br />
* Disable "Select only drivers that don't need compile-time external firmware".<br />
* Enable "Include Custom DSDT" and specify the absolute path of your fixed DSDT file.</div>Swiftiehttps://wiki.archlinux.org/index.php?title=Intel_C%2B%2B&diff=257053Intel C++2013-05-14T17:22:29Z<p>Swiftie: /* Software compiled with Intel C / C++ */</p>
<hr />
<div>[[Category:Development]]<br />
[[it:Intel C++]]<br />
[[zh-CN:Intel C++]]<br />
{{Article summary start}}<br />
{{Article summary text|Installation and basic usage of Intel® C++ Composer XE (formerly Intel® C++ Compiler Professional Edition) for Linux on Arch.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|ABS}}<br />
{{Article summary wiki|Creating Packages}}<br />
{{Article summary wiki|Makepkg}}<br />
{{Article summary end}}<br />
<br />
==Before You Begin==<br />
{{Note|Packages that have been compiled by icc will depend on the associated libs contained in the '''intel-openmp''' package in order to run. Since '''intel-openmp''' depends on '''intel-compiler-base''', users MUST have both packages installed at all times!}}<br />
<br />
==Setup and Installation==<br />
{{AUR|intel-parallel-studio-xe}} are available in the [[AUR]]. To build the package, one needs a license file which is free for personal and for non-commercial use. The requisite license file is emailed to users upon [[https://registrationcenter.intel.com/RegCenter/AutoGen.aspx?ProductID=1517&AccountID=&EmailID=&ProgramID=&RequestDt=&rm=NCOM&lang= registration]] and should be copied into the $startdir prior to running makepkg. The current PKGBUILD assembles 7 or 8 packages:<br />
<br />
*'''intel-compiler-base''' - Intel C/C++ compiler and base libs<br />
*'''intel-fortran-compiler''' - Intel fortran compiler and base libs (only Parallel Studio XE)<br />
*'''intel-openmp''' - Intel OpenMP Library<br />
*intel-idb- Intel C/C++ debugger<br />
*intel-ipp - Intel Integrated Performance Primitives<br />
*intel-mkl - Intel Math Kernel Library (Intel® MKL)<br />
*intel-sourcechecker - Intel Source Checker<br />
*intel-tbb - Intel Threading Building Blocks (TBB)<br />
<br />
{{Note|A minimal working environment requires the '''intel-compiler-base''' and '''intel-openmp''' packages; if you want also the fortran compiler you must install '''intel-fortran-compiler'''.}}<br />
<br />
==Using icc with makepkg==<br />
{{Note|Not every package will successfully compile with icc without heavy modifications to the underlying source.}}<br />
<br />
There is currently no official guide to using icc with makepkg. This section is meant to capture various methods suggested by users. Please make a new sub-section with your suggested method titled as such.<br />
<br />
=== Method 1 (12/08/2012) ===<br />
Modify {{ic|/etc/makepkg.conf}} inserting the following code ''under'' the existing line defining '''CXXFLAGS''' to enable makepkg to use icc. No special switches are needed when calling makepkg to build.<br />
<br />
{{bc|1=_CC=icc<br />
if [ $_CC = "icc" ]; then<br />
export CC="icc"<br />
export CXX="icpc"<br />
export CFLAGS="-march=native -O3 -no-prec-div -fno-alias -pipe"<br />
export CXXFLAGS="${CFLAGS}"<br />
export LDFLAGS="-Wl,-O1,--sort-common,--as-needed"<br />
export AR="xiar"<br />
export LD="xild"<br />
fi}}<br />
<br />
{{Note|To toggle between the native gcc and icc, simple comment or uncomment the newly created '''_CC''' variable.}}<br />
<br />
{{Note|Is some case the compilation method described above fails and the compilation will be performed with ''gcc'', so you should test if yours application has been effectively compiled with ''icc'' }}<br />
<br />
To test if your package has been really compiled with icc:<br />
<br />
* Type the command '''ldd [your_app] | grep intel''' If the application is linked to a shared object located in the directory '''/opt/intel/lib/''' it's mind that has been complied with icc.<br />
<br />
* Another method is to observe the build output and watch if it's using the ''icc'' or ''icpc'' command.<br />
<br />
* The last method is to watch if the warnings are in ''icc'' style or not.<br />
<br />
==icc CFLAGS==<br />
In general, icc supports many of the same CFLAGS gcc supports and is also pretty tolerant to gcc flags it cannot use. In most cases it will happily ignore the flag warning the user and moving on. For an exhaustive list and explanation of available compiler flags, consult the icc manpage or better yet by invoking the compiler with the help flag:<br />
icc --help<br />
<br />
=== -xX ===<br />
Use to generate specialized code to run exclusively on processors supporting it. If unsure which option to use, simply inspect the '''flags''' section of {{ic|/proc/cpuinfo}}. In the example below, '''SSE4.1''' would be the correct selection:<br />
<br />
{{bc|<nowiki>$ cat /proc/cpuinfo | grep -m 1 flags<br />
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush <br />
dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs <br />
bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr<br />
pdcm sse4_1 lahf_lm dts tpr_shadow vnmi flexpriority</nowiki>}}<br />
<br />
*-xHost<br />
*-xSSE2<br />
*-xSSE3<br />
*-xSSSE3<br />
*-xSSE4.1<br />
*-xSSE4.2<br />
*-xAVX<br />
*-xCORE-AVX-I<br />
*-xSSSE3_ATOM<br />
<br />
{{Tip|Use the '''-xHost''' flag if unsure what your specific processor supports.}}<br />
<br />
=== -Ox ===<br />
Same behavior as gcc. x is one of the following options:<br />
*0 - disables optimizations<br />
*1 - optimize for maximum speed, but disable some optimizations which increase code size for a small speed benefit<br />
*2 - optimize for maximum speed (DEFAULT)<br />
*3 - optimize for maximum speed and enable more aggressive optimizations that may not improve performance on some programs (recommended for math intensive looping programs)<br />
<br />
=== -w ===<br />
Similar to the gcc:<br />
*-w - disable all warnings (recommended for the package compilation)<br />
*-Wbrief - print brief one-line diagnostics<br />
*-Wall - enable all warnings<br />
*-Werror - force warnings to be reported as errors<br />
<br />
== Software compiled with Intel C / C++ ==<br />
<br />
In the following table we report a list of packages from the officials repository that we have tried to compile with the intel C/C++ compiler. The compilation should be done by using the PKGBUILD from ABS.<br />
<br />
<br />
{| class="wikitable sortable collapsible" border="1" border="1"<br />
|-style="background: #ffdead;" <br />
! Application || Compile || Comments<br />
<br />
|-<br />
| '''conky 1.9.0''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''xz''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''minetest''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''opus''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''zlib''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''Gimp 2.8''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''Pacman 4.0.3''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''x264''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''MySql''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''SqlLite''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''lame''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''xaos''' || style="background: Lime" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]<br />
|-<br />
| '''VLC''' || style="background: Tomato" | Unsuccessful || There's some problem with the compiler flags<br />
|-<br />
| '''mplayer''' || style="background: pink" | Out of date || It don't recognize the Intel compiler<br />
|-<br />
| '''optipng''' || style="background: GreenYellow" | OK || Works with the [[Intel_C++#Method_1 | Method 1]]. Comment out LD=xild in makepkg.conf<br />
|-<br />
| '''python-numpy''' || style="background: GreenYellow" | OK || We must edit the PKGBUILD. {{AUR|python-numpy-mkl}}<br />
|-<br />
| '''python-scipy''' || style="background: GreenYellow" | OK || We must edit the PKGBUILD. {{AUR|python-scipy-mkl}}<br />
|-<br />
| '''Qt''' || style="background: GreenYellow" | OK || We must add the option ''-platform linux-icc-64 (or 32)'' in the configure command <br />
|-<br />
| '''systemd''' || style="background: red" | Fail ||undefined reference to `server_dispatch_message'<br />
|}<br />
<br />
<br />
<br />
'''Legend:'''<br />
{|<br />
|-<br />
| style="background: Lime" | OK || The compilation with ICC works!<br />
|-<br />
| style="background: GreenYellow" | OK || The compilation works but is needed an editing of the PKGBUILD<br />
|-<br />
| style="background: Tomato" | Unsuccessful || The compilation may work, but there are some compilations errors.<br />
|-<br />
| style="background: yellow" | Not recommended || The compilation works, but is not recommended <br />
|-<br />
| style="background: red" | Fail || It's impossible to compile the PKG with ICC.<br />
|-<br />
| style="background: pink" | Out of date || It's unsuccessful or fails with older CFLAGS. You can try compiling it with new [[Intel_C++#Method_1 | Method 1]].(Don't forget to paste your result here!)<br />
|}</div>Swiftie