xfce4-appfinder: Add version 4.10.1 #1
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Copy the files from the directory `/src/mariux/beeroot/bee-files`, change the permissions, run `git init` to create a repository with all the bee files.
Logging out from an XFCE session, the app finder terminates with the segmentation fault below. ``` [87035.640468] xfce4-appfinder[1210]: segfault at 31 ip 000000000040c7c0 sp 00007ffd6b3092f0 error 4 in xfce4-appfinder[400000+1d000] ``` Updating from version 4.10.0 to 4.10.1 fixes the problem [1]. > 4.10.1 > ====== > - Use new glib 2.32 api. > - Autotools updates. > - Detatch from icon theme to avoid segfault (bug #9730). > - Protect against possible null pointers (bug #9109). > - Translation updates: Arabic, Bulgarian, Croatian, Indonesian, Dutch > (Flemish), Serbian, Swedish, Turkish, Uyghur [1] https://bugzilla.xfce.org/show_bug.cgi?id=9730
|
I only installed it locally. After merge, I’d install it on deinemuddah. |
|
ich darf nicht reopenen |
pmenzel
added a commit
that referenced
this pull request
Jun 14, 2016
Run the command below to create an initial bee file. ``` > bee init https://github.com/JuliaLang/julia/releases/download/v0.4.5/julia-0.4.5.tar.gz creating julia-0.4.5-0.bee from template '/etc/default/bee/templates/fallback' ``` Adapt it, to download and build the full archive, which includes several libraries, most of them not yet packaged in Mariux. For example, the Julia archive ships FFTW 3.3.4, while there is only FFTW 3.3.3 in Mariux. Note, that the architecture has to be explicitly set by passing `MARCH=x86-64` when calling `make`. Otherwise, Julia optimizes its image to the native architecture of the build machine, so a binary built on the server *shutupandtakemymoney* does not run on the machine *keineahnung*. [1] ``` > julia Target architecture mismatch. Please delete or regenerate sys.{so,dll,dylib}. ``` For whatever reason, `MARCH=x86-64` also needs to be passed to `make install`. Tested on *keineahnung*. ``` > sudo bee install julia installing /src/mariux/beeroot/packages/julia-0.4.5-0.x86_64.bee.tar.bz2 .. gtk-update-icon-cache: Cache file created successfully. > julia --version julia version 0.4.5 > julia _ _ _ _(_)_ | A fresh approach to technical computing (_) | (_) (_) | Documentation: http://docs.julialang.org _ _ _| |_ __ _ | Type "?help" for help. | | | | | | |/ _` | | | | |_| | | | (_| | | Version 0.4.5 (2016-03-18 00:58 UTC) _/ |\__'_|_|_|\__'_| | |__/ | x86_64-unknown-linux-gnu julia> versioninfo(true) Julia Version 0.4.5 Commit 2ac304d (2016-03-18 00:58 UTC) Platform Info: System: Linux (x86_64-unknown-linux-gnu) CPU: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz WORD_SIZE: 64 uname: Linux 4.4.11.mx64.88 #1 SMP Sat May 21 18:23:51 CEST 2016 x86_64 unknown Memory: 7.414115905761719 GB (85.7734375 MB free) Uptime: 705950.0 sec Load Avg: 0.216796875 2.275390625 3.595703125 Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz: speed user nice sys idle irq BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell) LAPACK: libopenblas64_ LIBM: libopenlibm LLVM: libLLVM-3.3 [...] ``` [1] https://github.com/JuliaLang/julia/blob/master/DISTRIBUTING.md#target-architectures
pmenzel
added a commit
that referenced
this pull request
Aug 18, 2016
Description [1]: > Userspace helper for kernel EDAC drivers (Error Detection and > Correction) README [2]: > EDAC (Error Detection and Correction) is a set of Linux kernel modules > that handle reporting of hardware-related errors. Currently these > modules mainly handle detection of ECC memory errors for many x86 and > x86-64 chipsets and PCI bus parity errors. > > The edac-utils project currently has three components: libedac, > edac-util, and edac-ctl. The libedac library presents a standard API > for reading EDAC error counts and other information from sysfs, and > edac-util uses this API to generate standard reports from the > commandline. The edac-ctl utility is a perl script which uses config > files to load the appropriate EDAC driver for a given chipset and > register motherboard DIMM labels if they are configured. An init > script is also provided which uses edac-ctl to initialize EDAC at > system startup. ``` pmenzel@rofl:~> lspci -nn -s 0:18.2 00:18.2 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 10h Processor DRAM Controller [1022:1202] pmenzel@rofl:~> dmesg | grep -i edac [ 0.491844] EDAC MC: Ver: 3.0.0 [ 2.612648] AMD64 EDAC driver v3.4.0 [ 2.615980] EDAC amd64: DRAM ECC enabled. [ 2.619301] EDAC amd64: F10h detected (node 0). [ 2.622555] EDAC MC: DCT0 chip selects: [ 2.622556] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 2.625799] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 2.628966] EDAC amd64: MC: 4: 2048MB 5: 2048MB [ 2.632103] EDAC amd64: MC: 6: 2048MB 7: 2048MB [ 2.635204] EDAC MC: DCT1 chip selects: [ 2.635205] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 2.638225] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 2.641248] EDAC amd64: MC: 4: 2048MB 5: 2048MB [ 2.644186] EDAC amd64: MC: 6: 2048MB 7: 2048MB [ 2.647033] EDAC amd64: using x8 syndromes. [ 2.649872] EDAC amd64: MCT channel count: 2 [ 2.653182] EDAC MC0: Giving out device to module amd64_edac controller F10h: DEV 0000:00:18.2 (INTERRUPT) [ 2.656156] EDAC amd64: DRAM ECC enabled. [ 2.659151] EDAC amd64: F10h detected (node 1). [ 2.662099] EDAC MC: DCT0 chip selects: [ 2.662101] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 2.665027] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 2.667925] EDAC amd64: MC: 4: 2048MB 5: 2048MB [ 2.670778] EDAC amd64: MC: 6: 2048MB 7: 2048MB [ 2.673560] EDAC MC: DCT1 chip selects: [ 2.673562] EDAC amd64: MC: 0: 2048MB 1: 2048MB [ 2.676284] EDAC amd64: MC: 2: 2048MB 3: 2048MB [ 2.678945] EDAC amd64: MC: 4: 2048MB 5: 2048MB [ 2.681579] EDAC amd64: MC: 6: 2048MB 7: 2048MB [ 2.684144] EDAC amd64: using x8 syndromes. [ 2.686686] EDAC amd64: MCT channel count: 2 [ 2.689611] EDAC MC1: Giving out device to module amd64_edac controller F10h: DEV 0000:00:19.2 (INTERRUPT) [ 2.692381] EDAC PCI0: Giving out device to module amd64_edac controller EDAC PCI controller: DEV 0000:00:18.2 (POLLED) pmenzel@rofl:~> uname -a # Six-Core AMD Opteron(tm) Processor 2439 SE Linux rofl.molgen.mpg.de 4.4.14.mx64.90 #1 SMP Mon Jun 27 17:52:58 CEST 2016 x86_64 GNU/Linux pmenzel@rofl:~> sudo edac-util --status --verbose edac-util: EDAC drivers are loaded. 2 MCs detected: mc0:F10h mc1:F10h pmenzel@rofl:~> sudo edac-util edac-util: No errors to report. ``` ``` pmenzel@keineahnung:~> uname -a Linux heulsuse.molgen.mpg.de 4.8.0-rc2.mx64.95 #1 SMP Mon Aug 15 17:49:16 CEST 2016 x86_64 GNU/Linux pmenzel@heulsuse:~> lspci -nn -s 0:0.0 # unsupported 00:00.0 Host bridge [0600]: Intel Corporation Xeon E7 v3/Xeon E5 v3/Core i7 DMI2 [8086:2f00] (rev 02) pmenzel@heulsuse:~> dmesg | grep -i edac [ 5.650704] EDAC MC: Ver: 3.0.0 pmenzel@heulsuse:~> sudo edac-util --status --verbose edac-util: EDAC drivers loaded. No memory controllers found pmenzel@heulsuse:~> sudo edac-util edac-util: Error: No memory controller data found. ``` [1] https://github.com/grondo/edac-utils/releases [2] https://github.com/grondo/edac-utils/blob/master/README
pmenzel
added a commit
that referenced
this pull request
Aug 23, 2016
1. Use faster cdn.kernel.org over www.kernel.org (14 MiB/s vs. 300 KiB/s) 2. Enable EDAC driver for Intel Sandy Bridge, Ivy Bridge, and Haswell * Select *PCI_MMCONFIG* (Support mmconfig PCI config space access) * Select *EDAC_SBRIDGE* (Support for error detection and correction the Intel Sandy Bridge, Ivy Bridge and Haswell Integrated Memory Controllers.) `EDAC_SBRIDGE` depends on `PCI_MMCONFIG` to be selected. Now, the EDAC driver finds the memory controllers, and the utilities can be used as expected. ``` $ uname -a Linux heulsuse.molgen.mpg.de 4.7.2.mx64.99 #1 SMP Tue Aug 23 10:10:21 CEST 2016 x86_64 GNU/Linux $ dmesg | grep EDAC [ 5.640338] EDAC MC: Ver: 3.0.0 [ 8.850635] EDAC sbridge: Seeking for: PCI ID 8086:2fa0 [ 8.850641] EDAC sbridge: Seeking for: PCI ID 8086:2fa0 [ 8.850645] EDAC sbridge: Seeking for: PCI ID 8086:2fa0 [ 8.850647] EDAC sbridge: Seeking for: PCI ID 8086:2ffc [ 8.850650] EDAC sbridge: Seeking for: PCI ID 8086:2ffc [ 8.850654] EDAC sbridge: Seeking for: PCI ID 8086:2ffc [ 8.850656] EDAC sbridge: Seeking for: PCI ID 8086:2ffd [ 8.850659] EDAC sbridge: Seeking for: PCI ID 8086:2ffd [ 8.850663] EDAC sbridge: Seeking for: PCI ID 8086:2ffd [ 8.850665] EDAC sbridge: Seeking for: PCI ID 8086:2f60 [ 8.850669] EDAC sbridge: Seeking for: PCI ID 8086:2f60 [ 8.850673] EDAC sbridge: Seeking for: PCI ID 8086:2f60 [ 8.850674] EDAC sbridge: Seeking for: PCI ID 8086:2fa8 [ 8.850678] EDAC sbridge: Seeking for: PCI ID 8086:2fa8 [ 8.850682] EDAC sbridge: Seeking for: PCI ID 8086:2fa8 [ 8.850684] EDAC sbridge: Seeking for: PCI ID 8086:2f71 [ 8.850687] EDAC sbridge: Seeking for: PCI ID 8086:2f71 [ 8.850691] EDAC sbridge: Seeking for: PCI ID 8086:2f71 [ 8.850693] EDAC sbridge: Seeking for: PCI ID 8086:2faa [ 8.850696] EDAC sbridge: Seeking for: PCI ID 8086:2faa [ 8.850700] EDAC sbridge: Seeking for: PCI ID 8086:2faa [ 8.850702] EDAC sbridge: Seeking for: PCI ID 8086:2fab [ 8.850705] EDAC sbridge: Seeking for: PCI ID 8086:2fab [ 8.850709] EDAC sbridge: Seeking for: PCI ID 8086:2fab [ 8.850711] EDAC sbridge: Seeking for: PCI ID 8086:2fac [ 8.850717] EDAC sbridge: Seeking for: PCI ID 8086:2fad [ 8.850724] EDAC sbridge: Seeking for: PCI ID 8086:2fbd [ 8.850728] EDAC sbridge: Seeking for: PCI ID 8086:2fbd [ 8.850732] EDAC sbridge: Seeking for: PCI ID 8086:2fbd [ 8.850733] EDAC sbridge: Seeking for: PCI ID 8086:2fbf [ 8.850737] EDAC sbridge: Seeking for: PCI ID 8086:2fbf [ 8.850741] EDAC sbridge: Seeking for: PCI ID 8086:2fbf [ 8.850742] EDAC sbridge: Seeking for: PCI ID 8086:2fb9 [ 8.850746] EDAC sbridge: Seeking for: PCI ID 8086:2fb9 [ 8.850750] EDAC sbridge: Seeking for: PCI ID 8086:2fb9 [ 8.850751] EDAC sbridge: Seeking for: PCI ID 8086:2fbb [ 8.850755] EDAC sbridge: Seeking for: PCI ID 8086:2fbb [ 8.850759] EDAC sbridge: Seeking for: PCI ID 8086:2fbb [ 8.850760] EDAC sbridge: Seeking for: PCI ID 8086:2f68 [ 8.850764] EDAC sbridge: Seeking for: PCI ID 8086:2f68 [ 8.850768] EDAC sbridge: Seeking for: PCI ID 8086:2f68 [ 8.850769] EDAC sbridge: Seeking for: PCI ID 8086:2f79 [ 8.850773] EDAC sbridge: Seeking for: PCI ID 8086:2f79 [ 8.850777] EDAC sbridge: Seeking for: PCI ID 8086:2f79 [ 8.850778] EDAC sbridge: Seeking for: PCI ID 8086:2f6a [ 8.850782] EDAC sbridge: Seeking for: PCI ID 8086:2f6a [ 8.850786] EDAC sbridge: Seeking for: PCI ID 8086:2f6a [ 8.850787] EDAC sbridge: Seeking for: PCI ID 8086:2f6b [ 8.850791] EDAC sbridge: Seeking for: PCI ID 8086:2f6b [ 8.850795] EDAC sbridge: Seeking for: PCI ID 8086:2f6b [ 8.850796] EDAC sbridge: Seeking for: PCI ID 8086:2f6c [ 8.850803] EDAC sbridge: Seeking for: PCI ID 8086:2f6d [ 8.851065] EDAC MC0: Giving out device to module sbridge_edac.c controller Haswell Socket#0: DEV 0000:7f:12.0 (INTERRUPT) [ 8.851306] EDAC MC1: Giving out device to module sbridge_edac.c controller Haswell Socket#1: DEV 0000:ff:12.0 (INTERRUPT) [ 8.851306] EDAC sbridge: Ver: 1.1.1 $ edac-util --status edac-util: EDAC drivers are loaded. 2 MCs detected $ edac-util --report=full mc0:csrow0:CPU_SrcID#0_Ha#0_Chan#0_DIMM#0:CE:0 mc0:csrow0:CPU_SrcID#0_Ha#0_Chan#1_DIMM#0:CE:0 mc0:csrow0:CPU_SrcID#0_Ha#1_Chan#0_DIMM#0:CE:0 mc0:csrow0:CPU_SrcID#0_Ha#1_Chan#1_DIMM#0:CE:0 mc0:csrow1:CPU_SrcID#0_Ha#0_Chan#0_DIMM#1:CE:0 mc0:csrow1:CPU_SrcID#0_Ha#0_Chan#1_DIMM#1:CE:0 mc0:csrow1:CPU_SrcID#0_Ha#1_Chan#0_DIMM#1:CE:0 mc0:csrow1:CPU_SrcID#0_Ha#1_Chan#1_DIMM#1:CE:0 mc0:csrow2:CPU_SrcID#0_Ha#0_Chan#0_DIMM#2:CE:0 mc0:csrow2:CPU_SrcID#0_Ha#0_Chan#1_DIMM#2:CE:0 mc0:csrow2:CPU_SrcID#0_Ha#1_Chan#0_DIMM#2:CE:0 mc0:csrow2:CPU_SrcID#0_Ha#1_Chan#1_DIMM#2:CE:0 mc0:noinfo:all:UE:0 mc0:noinfo:all:CE:0 mc1:csrow0:CPU_SrcID#1_Ha#0_Chan#0_DIMM#0:CE:0 mc1:csrow0:CPU_SrcID#1_Ha#0_Chan#1_DIMM#0:CE:0 mc1:csrow0:CPU_SrcID#1_Ha#1_Chan#0_DIMM#0:CE:0 mc1:csrow0:CPU_SrcID#1_Ha#1_Chan#1_DIMM#0:CE:0 mc1:csrow1:CPU_SrcID#1_Ha#0_Chan#0_DIMM#1:CE:0 mc1:csrow1:CPU_SrcID#1_Ha#0_Chan#1_DIMM#1:CE:0 mc1:csrow1:CPU_SrcID#1_Ha#1_Chan#0_DIMM#1:CE:0 mc1:csrow1:CPU_SrcID#1_Ha#1_Chan#1_DIMM#1:CE:0 mc1:csrow2:CPU_SrcID#1_Ha#0_Chan#0_DIMM#2:CE:0 mc1:csrow2:CPU_SrcID#1_Ha#0_Chan#1_DIMM#2:CE:0 mc1:csrow2:CPU_SrcID#1_Ha#1_Chan#0_DIMM#2:CE:0 mc1:csrow2:CPU_SrcID#1_Ha#1_Chan#1_DIMM#2:CE:0 mc1:noinfo:all:UE:0 mc1:noinfo:all:CE:0 $ grep ^ /sys/devices/system/edac/mc/mc0/* 2>/dev/null /sys/devices/system/edac/mc/mc0/ce_count:0 /sys/devices/system/edac/mc/mc0/ce_noinfo_count:0 /sys/devices/system/edac/mc/mc0/max_location:channel 7 slot 2 /sys/devices/system/edac/mc/mc0/mc_name:Haswell Socket#0 /sys/devices/system/edac/mc/mc0/seconds_since_reset:4804 /sys/devices/system/edac/mc/mc0/size_mb:196608 /sys/devices/system/edac/mc/mc0/ue_count:0 /sys/devices/system/edac/mc/mc0/ue_noinfo_count:0 ``` Thanks a lot for the help of Sven Ulland [1]. [1] http://lists.us.dell.com/pipermail/linux-poweredge/2016-August/050706.html (my and his reply were not forwarded)
pmenzel
added a commit
that referenced
this pull request
Sep 19, 2016
From *Intel Graphics Firmware* [1]: > ### Description ### > > New generations of Intel® Graphics for Linux requires below Firmware > components to be integreated in KMD. > > ### GuC ### > > GuC is designed to perform graphics workload scheduling on the various > graphics parallel engines. In this scheduling model, host software > submits work through one of the 256 graphics doorbells and this > invokes the scheduling operation on the appropriate graphics engine. > Scheduling operations include determining which workload to run next, > submitting a workload to a command streamer, pre-empting existing > workloads running on an engine, monitoring progress and notifying host > SW when work is done. > > ### DMC ### > > DMC provides additional graphics low-power idle states. It provides > capability to save and restore display registers across these > low-power states independently from the OS/Kernel. This addresses the Linux warnings below on an Intel Sky Lake system. ``` $ uname -a Linux keineahnung.molgen.mpg.de 4.8.0-rc7.mx64.104 #1 SMP Mon Sep 19 14:46:16 CEST 2016 x86_64 GNU/Linux $ lspci -nn -s 0:02.0 00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 530 [8086:1912] (rev 06) $ dmesg | grep i915 [ 2.459587] snd_hda_intel 0000:00:1f.3: failed to add i915 component master (-19) [ 2.482612] snd_hda_codec_hdmi hdaudioC0D2: No i915 binding for Intel HDMI/DP codec [ 15.109279] i915 0000:00:02.0: Direct firmware load for i915/skl_dmc_ver1_26.bin failed with error -2 [ 15.109284] i915 0000:00:02.0: Failed to load DMC firmware [https://01.org/linuxgraphics/intel-linux-graphics-firmwares], disabling runtime power management. [ 15.516406] [drm] Initialized i915 1.6.0 20160711 for 0000:00:02.0 on minor 0 [ 15.838483] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device ``` I don’t know, why `-x` is passed to the `cp` calls, but copied it for uniformity. [1] https://01.org/linuxgraphics/intel-linux-graphics-firmwares
pmenzel
added a commit
that referenced
this pull request
Oct 25, 2016
Linux 4.7.2-97 is superseded by Linux 4.7.10, and Linux 4.8.4. Also, it has the “[Dirty Cow](https://dirtycow.ninja/)” vulnerability. So remove it. ``` $ pssh -i -H "`hostconfig --list mx64`" uname -a | grep "4.7" Linux cu.molgen.mpg.de 4.7.2.mx64.99 #1 SMP Tue Aug 23 10:10:21 CEST 2016 x86_64 GNU/Linux Linux vitricophobie.molgen.mpg.de 4.7.2.mx64.99 #1 SMP Tue Aug 23 10:10:21 CEST 2016 x86_64 GNU/Linux ```
donald
added a commit
that referenced
this pull request
May 29, 2017
Update to latest available version before investigating further
into the heap corruption problem.
#1 0x00007f7685167748 in __GI_abort () at abort.c:89
#2 0x00007f76851a967d in __malloc_assert (assertion=assertion@entry=0x7f7685299470 "(unsigned long) (size) >= (unsigned long) (nb)",
file=file@entry=0x7f7685295065 "malloc.c", line=line@entry=3692, function=function@entry=0x7f76852953ed <__func__.11515> "_int_malloc")
at malloc.c:293
#3 0x00007f76851ac51a in _int_malloc (av=av@entry=0x7f7648000020, bytes=bytes@entry=2049) at malloc.c:3692
#4 0x00007f76851acbe1 in _int_realloc (av=av@entry=0x7f7648000020, oldp=oldp@entry=0x7f76480019a0, oldsize=oldsize@entry=1040,
nb=nb@entry=2064) at malloc.c:4283
#5 0x00007f76851add19 in __GI___libc_realloc (oldmem=0x7f76480019b0, bytes=2049) at malloc.c:3026
#6 0x000055a920baef28 in set_tsd_user_vars ()
#7 0x000055a920b9d2b4 in ?? ()
#8 0x00007f76863a9191 in start_thread (arg=0x7f767c1de700) at pthread_create.c:309
#9 0x00007f768521930d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
pmenzel
added a commit
that referenced
this pull request
Dec 19, 2017
From [1]: > Optional patch: > http://www.linuxfromscratch.org/patches/blfs/7.10/wireshark-2.0.5-lua_5_3_1-1.patch > (allows building the LUA bindings if Lua-5.3.3 is installed and LUA is > not disabled by passing --without-lua to configure) Applies with a little offset. ``` [BEE] patch -N -p1 -i /dev/shm/bee-root/wireshark/files/wireshark-2.0.5-lua_5_3_1-1.patch patching file configure Hunk #1 succeeded at 38870 (offset 1275 lines). Hunk #2 succeeded at 38974 (offset 1275 lines). Hunk #3 succeeded at 38998 (offset 1275 lines). Hunk #4 succeeded at 39022 (offset 1275 lines). patching file epan/wslua/lua_bitop.c patching file epan/wslua/wslua_byte_array.c patching file epan/wslua/wslua_file.c Hunk #1 succeeded at 347 (offset 10 lines). patching file epan/wslua/wslua.h patching file epan/wslua/wslua_int64.c patching file epan/wslua/wslua_internals.c patching file epan/wslua/wslua_listener.c patching file epan/wslua/wslua_nstime.c patching file epan/wslua/wslua_struct.c patching file epan/wslua/wslua_tvb.c Hunk #3 succeeded at 223 (offset -1 lines). Hunk #4 succeeded at 241 (offset -1 lines). Hunk #5 succeeded at 836 (offset -1 lines). Hunk #6 succeeded at 917 (offset -1 lines). Hunk #7 succeeded at 961 (offset -1 lines). Hunk #8 succeeded at 1008 (offset -1 lines). Hunk #9 succeeded at 1108 (offset -1 lines). ``` With this patch, `Use Lua library : yes` is seen in the configure option summary. [1] http://www.linuxfromscratch.org/blfs/view/7.10/basicnet/wireshark.html
pmenzel
added a commit
that referenced
this pull request
Dec 21, 2017
According to the developer asynchronous mode is supported in Linux 4.14. As the external driver fails to build, do not do that, and use the shipped version. ``` $ uname -a Linux mrtorgue.molgen.mpg.de 4.14.8.mx64.197 #1 SMP Thu Dec 21 17:35:49 CET 2017 x86_64 GNU/Linux $ dmesg | grep -i aac [ 0.000000] ACPI: MSCT 0x000000007BAAC000 000090 (v01 DELL PE_SC3 00000001 DELL 00000001) [ 171.387352] Adaptec aacraid driver 1.2.1[50834]-custom [ 171.387427] aacraid 0000:84:00.0: can't disable ASPM; OS doesn't have ASPM control [ 171.387960] aacraid: Comm Interface type3 enabled [ 171.391800] AAC0: kernel 3.52-0[0] Sep 7 2017 [ 171.391802] AAC0: monitor 0.0-0[0] [ 171.391803] AAC0: bios 0.13-209[32000] [ 171.391804] AAC0: serial 10F447 [ 171.391805] AAC0: Non-DASD support enabled. [ 171.391806] AAC0: 64bit support enabled. [ 171.391807] aacraid 0000:84:00.0: 64 Bit DAC enabled [ 171.393542] scsi host11: aacraid ```
pmenzel
added a commit
that referenced
this pull request
Dec 22, 2017
According to the developer asynchronous mode is supported in Linux 4.14. As the external driver fails to build, do not do that, and use the shipped version. ``` $ uname -a Linux mrtorgue.molgen.mpg.de 4.14.8.mx64.197 #1 SMP Thu Dec 21 17:35:49 CET 2017 x86_64 GNU/Linux $ dmesg | grep -i aac [ 0.000000] ACPI: MSCT 0x000000007BAAC000 000090 (v01 DELL PE_SC3 00000001 DELL 00000001) [ 171.387352] Adaptec aacraid driver 1.2.1[50834]-custom [ 171.387427] aacraid 0000:84:00.0: can't disable ASPM; OS doesn't have ASPM control [ 171.387960] aacraid: Comm Interface type3 enabled [ 171.391800] AAC0: kernel 3.52-0[0] Sep 7 2017 [ 171.391802] AAC0: monitor 0.0-0[0] [ 171.391803] AAC0: bios 0.13-209[32000] [ 171.391804] AAC0: serial 10F447 [ 171.391805] AAC0: Non-DASD support enabled. [ 171.391806] AAC0: 64bit support enabled. [ 171.391807] aacraid 0000:84:00.0: 64 Bit DAC enabled [ 171.393542] scsi host11: aacraid ```
donald
pushed a commit
that referenced
this pull request
Jan 8, 2018
According to the developer asynchronous mode is supported in Linux 4.14. As the external driver fails to build, do not do that, and use the shipped version. ``` $ uname -a Linux mrtorgue.molgen.mpg.de 4.14.8.mx64.197 #1 SMP Thu Dec 21 17:35:49 CET 2017 x86_64 GNU/Linux $ dmesg | grep -i aac [ 0.000000] ACPI: MSCT 0x000000007BAAC000 000090 (v01 DELL PE_SC3 00000001 DELL 00000001) [ 171.387352] Adaptec aacraid driver 1.2.1[50834]-custom [ 171.387427] aacraid 0000:84:00.0: can't disable ASPM; OS doesn't have ASPM control [ 171.387960] aacraid: Comm Interface type3 enabled [ 171.391800] AAC0: kernel 3.52-0[0] Sep 7 2017 [ 171.391802] AAC0: monitor 0.0-0[0] [ 171.391803] AAC0: bios 0.13-209[32000] [ 171.391804] AAC0: serial 10F447 [ 171.391805] AAC0: Non-DASD support enabled. [ 171.391806] AAC0: 64bit support enabled. [ 171.391807] aacraid 0000:84:00.0: 64 Bit DAC enabled [ 171.393542] scsi host11: aacraid ```
pmenzel
added a commit
that referenced
this pull request
Jan 8, 2018
According to the developer asynchronous mode is supported in Linux 4.14. As the external driver fails to build, do not do that, and use the shipped version. ``` $ uname -a Linux mrtorgue.molgen.mpg.de 4.14.8.mx64.197 #1 SMP Thu Dec 21 17:35:49 CET 2017 x86_64 GNU/Linux $ dmesg | grep -i aac [ 0.000000] ACPI: MSCT 0x000000007BAAC000 000090 (v01 DELL PE_SC3 00000001 DELL 00000001) [ 171.387352] Adaptec aacraid driver 1.2.1[50834]-custom [ 171.387427] aacraid 0000:84:00.0: can't disable ASPM; OS doesn't have ASPM control [ 171.387960] aacraid: Comm Interface type3 enabled [ 171.391800] AAC0: kernel 3.52-0[0] Sep 7 2017 [ 171.391802] AAC0: monitor 0.0-0[0] [ 171.391803] AAC0: bios 0.13-209[32000] [ 171.391804] AAC0: serial 10F447 [ 171.391805] AAC0: Non-DASD support enabled. [ 171.391806] AAC0: 64bit support enabled. [ 171.391807] aacraid 0000:84:00.0: 64 Bit DAC enabled [ 171.393542] scsi host11: aacraid ```
pmenzel
added a commit
that referenced
this pull request
Jan 8, 2018
According to the developer asynchronous mode is supported in Linux 4.14. As the external driver fails to build, do not do that, and use the shipped version. ``` $ uname -a Linux mrtorgue.molgen.mpg.de 4.14.8.mx64.197 #1 SMP Thu Dec 21 17:35:49 CET 2017 x86_64 GNU/Linux $ dmesg | grep -i aac [ 0.000000] ACPI: MSCT 0x000000007BAAC000 000090 (v01 DELL PE_SC3 00000001 DELL 00000001) [ 171.387352] Adaptec aacraid driver 1.2.1[50834]-custom [ 171.387427] aacraid 0000:84:00.0: can't disable ASPM; OS doesn't have ASPM control [ 171.387960] aacraid: Comm Interface type3 enabled [ 171.391800] AAC0: kernel 3.52-0[0] Sep 7 2017 [ 171.391802] AAC0: monitor 0.0-0[0] [ 171.391803] AAC0: bios 0.13-209[32000] [ 171.391804] AAC0: serial 10F447 [ 171.391805] AAC0: Non-DASD support enabled. [ 171.391806] AAC0: 64bit support enabled. [ 171.391807] aacraid 0000:84:00.0: 64 Bit DAC enabled [ 171.393542] scsi host11: aacraid ```
pmenzel
added a commit
that referenced
this pull request
Jun 18, 2019
This fixes *Linux and FreeBSD Kernel: Multiple TCP-based remote denial of service issues* [1]. > Netflix has identified several TCP networking vulnerabilities in FreeBSD > and Linux kernels. > > The vulnerabilities specifically relate to the minimum segment size (MSS) > and TCP Selective Acknowledgement (SACK) capabilities. The most serious, > dubbed “SACK Panic,” allows a remotely-triggered kernel panic on recent > Linux kernels. > > There are patches that address most of these vulnerabilities. If patches > can not be applied, certain mitigations will be effective. We recommend > that affected parties enact one of those described below, based on their > environment. > > #1: CVE-2019-11477: SACK Panic (Linux >= 2.6.29) > > Description: A sequence of SACKs may be crafted such that one can trigger > an integer overflow, leading to a kernel panic. > > Fix: Apply the attached patch (“PATCH_net_1_4.patch”). Additionally, > versions of the Linux kernel up to, and including, 4.14 require a second > patch (“PATCH_net_1a.patch”). > > Workaround #1: Block connections with a low MSS using one of the attached > filters. (The values in the filters are examples. You can apply a higher or > lower limit, as appropriate for your environment.) Note that these filters > may break legitimate connections which rely on a low MSS. Also, note that > this mitigation is only effective if TCP probing is disabled (that is, the > net.ipv4.tcp_mtu_probing sysctl is set to 0, which appears to be the > default value for that sysctl). > > Workaround #2: Disable SACK processing (/proc/sys/net/ipv4/tcp_sack set to > 0). > > (Note that either workaround should be sufficient on its own. It is not > necessary to apply both workarounds.) > > > #2: CVE-2019-11478: SACK Slowness (Linux < 4.15) or Excess Resource Usage > (all Linux versions) > > Description: It is possible to send a crafted sequence of SACKs which will > fragment the TCP retransmission queue. On Linux kernels prior to 4.15, an > attacker may be able to further exploit the fragmented queue to cause an > expensive linked-list walk for subsequent SACKs received for that same TCP > connection. > > Fix: Apply the attached patch (“PATCH_net_2_4.patch”) > > Workaround #1: Block connections with a low MSS using one of the attached > filters. (The values in the filters are examples. You can apply a higher or > lower limit, as appropriate for your environment.) Note that these filters > may break legitimate connections which rely on a low MSS. Also, note that > this mitigation is only effective if TCP probing is disabled (that is, the > net.ipv4.tcp_mtu_probing sysctl is set to 0, which appears to be the > default value for that sysctl). > > Workaround #2: Disable SACK processing (/proc/sys/net/ipv4/tcp_sack set to > 0). > > (Note that either workaround should be sufficient on its own. It is not > necessary to apply both workarounds.) > > > #3: CVE-2019-5599: SACK Slowness (FreeBSD 12 using the RACK TCP Stack) > > Description: It is possible to send a crafted sequence of SACKs which will > fragment the RACK send map. An attacker may be able to further exploit the > fragmented send map to cause an expensive linked-list walk for subsequent > SACKs received for that same TCP connection. > > Workaround #1: Apply the attached patch (“split_limit.patch”) and set the > net.inet.tcp.rack.split_limit sysctl to a reasonable value to limit the > size of the SACK table. > > Workaround #2: Temporarily disable the RACK TCP stack. > > (Note that either workaround should be sufficient on its own. It is not > necessary to apply both workarounds.) > > > #4: CVE-2019-11479: Excess Resource Consumption Due to Low MSS Values (all > Linux versions) > > Description: An attacker can force the Linux kernel to segment its > responses into multiple TCP segments, each of which contains only 8 bytes > of data. This drastically increases the bandwidth required to deliver the > same amount of data. Further, it consumes additional resources (CPU and NIC > processing power). This attack requires continued effort from the attacker > and the impacts will end shortly after the attacker stops sending traffic. > > Fix: Two attached patches (“PATCH_net_3_4.patch” and “PATCH_net_4_4.patch”) > add a sysctl which enforces a minimum MSS, set by the > net.ipv4.tcp_min_snd_mss sysctl. This lets an administrator enforce a > minimum MSS appropriate for their applications. > > Workaround: Block connections with a low MSS using one of the attached > filters. (The values in the filters are examples. You can apply a higher or > lower limit, as appropriate for your environment.) Note that these filters > may break legitimate connections which rely on a low MSS. Also, note that > this mitigation is only effective if TCP probing is disabled (that is, the > net.ipv4.tcp_mtu_probing sysctl is set to 0, which appears to be the > default value for that sysctl). > > > Note: Good system and application coding and configuration practices > (limiting write buffers to the necessary level, monitoring connection > memory consumption via SO_MEMINFO, and aggressively closing misbehaving > connections) can help to limit the impact of attacks against these kinds of > vulnerabilities. > > An advisory has been published > at https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001.md > > Acknowledgments: > Originally reported by Jonathan Looney. > We thank Eric Dumazet for providing Linux fixes and support. > We thank Bruce Curtis for providing the Linux filters. > We thank Jonathan Lemon and Alexey Kodanev for helping to improve the Linux > patches. > We gratefully acknowledge the assistance of Tyler Hicks in testing fixes, > refining the information about vulnerable versions, and providing > assistance during the disclosure process. > > Regards, > Netflix Information Security [1]: https://www.openwall.com/lists/oss-security/2019/06/17/5
pmenzel
added a commit
that referenced
this pull request
Jun 18, 2019
This fixes *Linux and FreeBSD Kernel: Multiple TCP-based remote denial of service issues* [1]. > Netflix has identified several TCP networking vulnerabilities in FreeBSD > and Linux kernels. > > The vulnerabilities specifically relate to the minimum segment size (MSS) > and TCP Selective Acknowledgement (SACK) capabilities. The most serious, > dubbed “SACK Panic,” allows a remotely-triggered kernel panic on recent > Linux kernels. > > There are patches that address most of these vulnerabilities. If patches > can not be applied, certain mitigations will be effective. We recommend > that affected parties enact one of those described below, based on their > environment. > > #1: CVE-2019-11477: SACK Panic (Linux >= 2.6.29) > > Description: A sequence of SACKs may be crafted such that one can trigger > an integer overflow, leading to a kernel panic. > > Fix: Apply the attached patch (“PATCH_net_1_4.patch”). Additionally, > versions of the Linux kernel up to, and including, 4.14 require a second > patch (“PATCH_net_1a.patch”). > > Workaround #1: Block connections with a low MSS using one of the attached > filters. (The values in the filters are examples. You can apply a higher or > lower limit, as appropriate for your environment.) Note that these filters > may break legitimate connections which rely on a low MSS. Also, note that > this mitigation is only effective if TCP probing is disabled (that is, the > net.ipv4.tcp_mtu_probing sysctl is set to 0, which appears to be the > default value for that sysctl). > > Workaround #2: Disable SACK processing (/proc/sys/net/ipv4/tcp_sack set to > 0). > > (Note that either workaround should be sufficient on its own. It is not > necessary to apply both workarounds.) > > > #2: CVE-2019-11478: SACK Slowness (Linux < 4.15) or Excess Resource Usage > (all Linux versions) > > Description: It is possible to send a crafted sequence of SACKs which will > fragment the TCP retransmission queue. On Linux kernels prior to 4.15, an > attacker may be able to further exploit the fragmented queue to cause an > expensive linked-list walk for subsequent SACKs received for that same TCP > connection. > > Fix: Apply the attached patch (“PATCH_net_2_4.patch”) > > Workaround #1: Block connections with a low MSS using one of the attached > filters. (The values in the filters are examples. You can apply a higher or > lower limit, as appropriate for your environment.) Note that these filters > may break legitimate connections which rely on a low MSS. Also, note that > this mitigation is only effective if TCP probing is disabled (that is, the > net.ipv4.tcp_mtu_probing sysctl is set to 0, which appears to be the > default value for that sysctl). > > Workaround #2: Disable SACK processing (/proc/sys/net/ipv4/tcp_sack set to > 0). > > (Note that either workaround should be sufficient on its own. It is not > necessary to apply both workarounds.) > > > #3: CVE-2019-5599: SACK Slowness (FreeBSD 12 using the RACK TCP Stack) > > Description: It is possible to send a crafted sequence of SACKs which will > fragment the RACK send map. An attacker may be able to further exploit the > fragmented send map to cause an expensive linked-list walk for subsequent > SACKs received for that same TCP connection. > > Workaround #1: Apply the attached patch (“split_limit.patch”) and set the > net.inet.tcp.rack.split_limit sysctl to a reasonable value to limit the > size of the SACK table. > > Workaround #2: Temporarily disable the RACK TCP stack. > > (Note that either workaround should be sufficient on its own. It is not > necessary to apply both workarounds.) > > > #4: CVE-2019-11479: Excess Resource Consumption Due to Low MSS Values (all > Linux versions) > > Description: An attacker can force the Linux kernel to segment its > responses into multiple TCP segments, each of which contains only 8 bytes > of data. This drastically increases the bandwidth required to deliver the > same amount of data. Further, it consumes additional resources (CPU and NIC > processing power). This attack requires continued effort from the attacker > and the impacts will end shortly after the attacker stops sending traffic. > > Fix: Two attached patches (“PATCH_net_3_4.patch” and “PATCH_net_4_4.patch”) > add a sysctl which enforces a minimum MSS, set by the > net.ipv4.tcp_min_snd_mss sysctl. This lets an administrator enforce a > minimum MSS appropriate for their applications. > > Workaround: Block connections with a low MSS using one of the attached > filters. (The values in the filters are examples. You can apply a higher or > lower limit, as appropriate for your environment.) Note that these filters > may break legitimate connections which rely on a low MSS. Also, note that > this mitigation is only effective if TCP probing is disabled (that is, the > net.ipv4.tcp_mtu_probing sysctl is set to 0, which appears to be the > default value for that sysctl). > > > Note: Good system and application coding and configuration practices > (limiting write buffers to the necessary level, monitoring connection > memory consumption via SO_MEMINFO, and aggressively closing misbehaving > connections) can help to limit the impact of attacks against these kinds of > vulnerabilities. > > An advisory has been published > at https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001.md > > Acknowledgments: > Originally reported by Jonathan Looney. > We thank Eric Dumazet for providing Linux fixes and support. > We thank Bruce Curtis for providing the Linux filters. > We thank Jonathan Lemon and Alexey Kodanev for helping to improve the Linux > patches. > We gratefully acknowledge the assistance of Tyler Hicks in testing fixes, > refining the information about vulnerable versions, and providing > assistance during the disclosure process. > > Regards, > Netflix Information Security The other commits between 4.19.40 and 4.19.52 can be found in the [git repository][2]. [1]: https://www.openwall.com/lists/oss-security/2019/06/17/5 [2]: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=linux-4.19.y
pmenzel
added a commit
that referenced
this pull request
Feb 21, 2020
On the Dell PowerEdge T640/04WYPY, BIOS 2.4.8 11/27/2019, Linux crashes on start-up.
[ 3.862327] ACPI: Core revision 20190816
[ 3.869551] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635855245 ns
[ 3.878797] APIC: Switch to symmetric I/O mode setup
[ 3.883893] Switched APIC routing to physical flat.
[ 3.888904] ------------[ cut here ]------------
[ 3.893641] kernel BUG at arch/x86/kernel/apic/apic.c:1616!
[ 3.899347] invalid opcode: 0000 [#1] SMP NOPTI
[ 3.903990] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.4.14.mx64.317 #1
[ 3.910803] Hardware name: Dell Inc. PowerEdge T640/04WYPY, BIOS 2.4.8 11/27/2019
[ 3.918448] RIP: 0010:setup_local_APIC+0x32e/0x390
[ 3.923356] Code: 68 70 2e 01 be 00 07 01 00 bf 50 03 00 00 48 8b 40 10 e8 15 9e db 00 eb a9 be 00 04 01 00 bf 60 03 00 00 e8 04 9e db 00 eb bb <0f> 0b e8 5b 3a 00 00
[ 3.942300] RSP: 0000:ffffffff82403e88 EFLAGS: 00010246
[ 3.947641] RAX: 0000000000000000 RBX: 00000000000000ff RCX: ffffffff82454128
[ 3.955787] RDX: 0000000000000000 RSI: 00000000fffffeff RDI: 0000000000000020
[ 3.963031] RBP: ffffffffffffffff R08: 00000000000001c4 R09: 0734073407370739
[ 3.970277] R10: ffffffff82573000 R11: 0720072007730765 R12: ffffffff82a4a920
[ 3.977522] R13: 0000000000000000 R14: ffff88c07fff0e80 R15: 0000000000000000
[ 3.984766] FS: 0000000000000000(0000) GS:ffff889fffc00000(0000) knlGS:0000000000000000
[ 3.993014] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 3.998876] CR2: ffff88c07ffff000 CR3: 000000000240a001 CR4: 00000000000606b0
[ 4.006121] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 4.013365] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 4.020611] Call Trace:
[ 4.023184] apic_intr_mode_init+0x1d2/0x1ec
[ 4.027573] x86_late_time_init+0x17/0x1c
[ 4.031706] start_kernel+0x41f/0x4d3
[ 4.035491] secondary_startup_64+0xa4/0xb0
[ 4.039797] Modules linked in:
[ 4.042997] ---[ end trace c3629ce2e87a638c ]---
[ 4.047746] RIP: 0010:setup_local_APIC+0x32e/0x390
[ 4.052663] Code: 68 70 2e 01 be 00 07 01 00 bf 50 03 00 00 48 8b 40 10 e8 15 9e db 00 eb a9 be 00 04 01 00 bf 60 03 00 00 e8 04 9e db 00 eb bb <0f> 0b e8 5b 3a 00 00
[ 4.071617] RSP: 0000:ffffffff82403e88 EFLAGS: 00010246
[ 4.076966] RAX: 0000000000000000 RBX: 00000000000000ff RCX: ffffffff82454128
[ 4.084219] RDX: 0000000000000000 RSI: 00000000fffffeff RDI: 0000000000000020
[ 4.091475] RBP: ffffffffffffffff R08: 00000000000001c4 R09: 0734073407370739
[ 4.098738] R10: ffffffff82573000 R11: 0720072007730765 R12: ffffffff82a4a920
[ 4.106000] R13: 0000000000000000 R14: ffff88c07fff0e80 R15: 0000000000000000
[ 4.113252] FS: 0000000000000000(0000) GS:ffff889fffc00000(0000) knlGS:0000000000000000
[ 4.121509] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 4.127380] CR2: ffff88c07ffff000 CR3: 000000000240a001 CR4: 00000000000606b0
[ 4.134632] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 4.141887] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 4.149142] Kernel panic - not syncing: Attempted to kill the idle task!
[ 4.155968] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---
The reason is the code below in `arch/x86/kernel/apic/apic.c`.
/*
* Double-check whether this APIC is really registered.
* This is meaningless in clustered apic mode, so we skip it.
*/
BUG_ON(!apic->apic_id_registered());
Selecting X2APIC should fix this.
With `acpi=off noapic` the panic below is shown.
[ 2.577272] Kernel panic - not syncing: BIOS has enabled x2apic but kernel doesn't support x2apic, please disable x2apic in BIOS.
With `nosmp` it also crashes at the same spot.
[ 3.705437] APIC: SMP mode deactivated
[ 3.709189] APIC: Switch to symmetric I/O mode setup in no SMP routine
[ 3.715712] ------------[ cut here ]------------
[ 3.720320] kernel BUG at arch/x86/kernel/apic/apic.c:1616!
pmenzel
added a commit
that referenced
this pull request
Feb 21, 2020
> CONFIG_X86_X2APIC:
>
> This enables x2apic support on CPUs that have this feature.
>
> This allows 32-bit apic IDs (so it can support very large systems),
> and accesses the local apic via MSRs not via mmio.
On the Dell PowerEdge T640/04WYPY, BIOS 2.4.8 11/27/2019, Linux crashes on start-up.
[ 3.862327] ACPI: Core revision 20190816
[ 3.869551] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635855245 ns
[ 3.878797] APIC: Switch to symmetric I/O mode setup
[ 3.883893] Switched APIC routing to physical flat.
[ 3.888904] ------------[ cut here ]------------
[ 3.893641] kernel BUG at arch/x86/kernel/apic/apic.c:1616!
[ 3.899347] invalid opcode: 0000 [#1] SMP NOPTI
[ 3.903990] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.4.14.mx64.317 #1
[ 3.910803] Hardware name: Dell Inc. PowerEdge T640/04WYPY, BIOS 2.4.8 11/27/2019
[ 3.918448] RIP: 0010:setup_local_APIC+0x32e/0x390
[ 3.923356] Code: 68 70 2e 01 be 00 07 01 00 bf 50 03 00 00 48 8b 40 10 e8 15 9e db 00 eb a9 be 00 04 01 00 bf 60 03 00 00 e8 04 9e db 00 eb bb <0f> 0b e8 5b 3a 00 00
[ 3.942300] RSP: 0000:ffffffff82403e88 EFLAGS: 00010246
[ 3.947641] RAX: 0000000000000000 RBX: 00000000000000ff RCX: ffffffff82454128
[ 3.955787] RDX: 0000000000000000 RSI: 00000000fffffeff RDI: 0000000000000020
[ 3.963031] RBP: ffffffffffffffff R08: 00000000000001c4 R09: 0734073407370739
[ 3.970277] R10: ffffffff82573000 R11: 0720072007730765 R12: ffffffff82a4a920
[ 3.977522] R13: 0000000000000000 R14: ffff88c07fff0e80 R15: 0000000000000000
[ 3.984766] FS: 0000000000000000(0000) GS:ffff889fffc00000(0000) knlGS:0000000000000000
[ 3.993014] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 3.998876] CR2: ffff88c07ffff000 CR3: 000000000240a001 CR4: 00000000000606b0
[ 4.006121] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 4.013365] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 4.020611] Call Trace:
[ 4.023184] apic_intr_mode_init+0x1d2/0x1ec
[ 4.027573] x86_late_time_init+0x17/0x1c
[ 4.031706] start_kernel+0x41f/0x4d3
[ 4.035491] secondary_startup_64+0xa4/0xb0
[ 4.039797] Modules linked in:
[ 4.042997] ---[ end trace c3629ce2e87a638c ]---
[ 4.047746] RIP: 0010:setup_local_APIC+0x32e/0x390
[ 4.052663] Code: 68 70 2e 01 be 00 07 01 00 bf 50 03 00 00 48 8b 40 10 e8 15 9e db 00 eb a9 be 00 04 01 00 bf 60 03 00 00 e8 04 9e db 00 eb bb <0f> 0b e8 5b 3a 00 00
[ 4.071617] RSP: 0000:ffffffff82403e88 EFLAGS: 00010246
[ 4.076966] RAX: 0000000000000000 RBX: 00000000000000ff RCX: ffffffff82454128
[ 4.084219] RDX: 0000000000000000 RSI: 00000000fffffeff RDI: 0000000000000020
[ 4.091475] RBP: ffffffffffffffff R08: 00000000000001c4 R09: 0734073407370739
[ 4.098738] R10: ffffffff82573000 R11: 0720072007730765 R12: ffffffff82a4a920
[ 4.106000] R13: 0000000000000000 R14: ffff88c07fff0e80 R15: 0000000000000000
[ 4.113252] FS: 0000000000000000(0000) GS:ffff889fffc00000(0000) knlGS:0000000000000000
[ 4.121509] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 4.127380] CR2: ffff88c07ffff000 CR3: 000000000240a001 CR4: 00000000000606b0
[ 4.134632] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 4.141887] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 4.149142] Kernel panic - not syncing: Attempted to kill the idle task!
[ 4.155968] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---
The reason is the code below in `arch/x86/kernel/apic/apic.c`.
/*
* Double-check whether this APIC is really registered.
* This is meaningless in clustered apic mode, so we skip it.
*/
BUG_ON(!apic->apic_id_registered());
With `acpi=off noapic` the panic below is shown.
[ 2.577272] Kernel panic - not syncing: BIOS has enabled x2apic but kernel doesn't support x2apic, please disable x2apic in BIOS.
With `nosmp` it also crashes at the same spot.
[ 3.705437] APIC: SMP mode deactivated
[ 3.709189] APIC: Switch to symmetric I/O mode setup in no SMP routine
[ 3.715712] ------------[ cut here ]------------
[ 3.720320] kernel BUG at arch/x86/kernel/apic/apic.c:1616!
Selecting X2APIC support in Linux fixes the crashes/panics.
Disabling x2APIC in the Dell firmware also get the Linux kernel with no
X2APIC support to boot, but some posts on the Web claim, that X2APIC is
more efficient [1].
[1]: https://serverfault.com/questions/873664/when-to-use-x2apic-mode
pmenzel
added a commit
that referenced
this pull request
Jul 28, 2020
The IPMI drivers are not needed on all systems, and we try to avoid
that interface. This also resolves a conflict with other watchdog
timers.
handsomejack:~$ dmesg --level=err
[ 11.618887] watchdog: iTCO_wdt: cannot register miscdev on minor=130 (err=-16).
[ 11.627956] watchdog: iTCO_wdt: a legacy watchdog module is probably present.
handsomejack:~$ dmesg | grep -e iTCO -e watchdog
[ 11.603138] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[ 11.609888] iTCO_wdt: Found a Wellsburg TCO device (Version=2, TCOBASE=0x0460)
[ 11.618887] watchdog: iTCO_wdt: cannot register miscdev on minor=130 (err=-16).
[ 11.627956] watchdog: iTCO_wdt: a legacy watchdog module is probably present.
[ 11.636462] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[ 11.643679] iTCO_vendor_support: vendor-support=0
The Linux error when shutting down *sympathyforthedevil* – not in the logs,
only on the monitor or the serial console – is also gone now, as the drivers
are not automatically loaded.
[ 189.063113] reboot: Power down
[ 189.068549] IPMI poweroff: Powering down via IPMI chassis control command
[ 189.075498] ------------[ cut here ]------------
[ 189.080259] sched: Unexpected reschedule of offline CPU#8!
[ 189.085898] WARNING: CPU: 0 PID: 1 at arch/x86/kernel/apic/ipi.c:67 native_smp_send_reschedule+0x34/0x40
[ 189.095605] Modules linked in: 8021q garp stp mrp llc amd64_edac_mod edac_mce_amd kvm_amd kvm input_leds led_class irqbypass ixgbe crc32c_intel acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables x_tables unix ipv6 nf_defrag_ipv6 autofs4
[ 189.118332] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 5.4.39.mx64.334 #1
[ 189.125774] Hardware name: Supermicro Super Server/H11DSU-iN, BIOS 1.3 01/30/2020
[ 189.133482] RIP: 0010:native_smp_send_reschedule+0x34/0x40
[ 189.139114] Code: 05 31 9c 52 01 73 15 48 8b 05 a8 7f 2d 01 be fd 00 00 00 48 8b 40 30 e9 6a 8b db 00 89 fe 48 c7 c7 20 9e 21 82 e8 5c 1d 02 00 <0f> 0b c3 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 8b 05 74 7f
[ 189.158198] RSP: 0018:ffffc9001892fbc8 EFLAGS: 00010086
[ 189.163571] RAX: 0000000000000000 RBX: ffff889faa6f5200 RCX: ffffffff82454348
[ 189.170858] RDX: 0000000000000001 RSI: 0000000000000092 RDI: ffffffff82b2cbec
[ 189.178139] RBP: 0000000000028b00 R08: 0000000000000796 R09: 0000000000000000
[ 189.185420] R10: ffffc9001892fbb8 R11: 00000000000000f0 R12: 0000000000000008
[ 189.192706] R13: 0000000000000000 R14: ffff889faa6f589c R15: 0000000000000046
[ 189.199988] FS: 00007f7a26e6f800(0000) GS:ffff889faec00000(0000) knlGS:0000000000000000
[ 189.208299] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 189.214192] CR2: 00007f950950c8a0 CR3: 000000ff9f3b4000 CR4: 00000000003406f0
[ 189.221473] Call Trace:
[ 189.224068] try_to_wake_up+0x3bd/0x5a0
[ 189.228045] check_start_timer_thread.part.12+0x2a/0x50
[ 189.233418] sender+0x65/0x70
[ 189.236527] i_ipmi_request+0x2de/0x9d0
[ 189.240507] ipmi_request_supply_msgs+0x102/0x130
[ 189.245358] ipmi_request_in_rc_mode+0x2f/0x80
[ 189.249944] ipmi_poweroff_chassis+0xa0/0x110
[ 189.254452] __do_sys_reboot+0x150/0x1e0
[ 189.258517] ? do_writev+0xd8/0x120
[ 189.262146] ? do_writev+0xd8/0x120
[ 189.265779] do_syscall_64+0x48/0x130
[ 189.269586] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 189.274782] RIP: 0033:0x7f7a2662a2a3
[ 189.278501] Code: 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 89 fa be 69 19 12 28 bf ad de e1 fe b8 a9 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 05 f3 c3 0f 1f 00 48 8b 15 b1 4b 2c 00 f7 d8
[ 189.297584] RSP: 002b:00007ffed7660078 EFLAGS: 00000206 ORIG_RAX: 00000000000000a9
[ 189.305376] RAX: ffffffffffffffda RBX: 000000004321fedc RCX: 00007f7a2662a2a3
[ 189.312663] RDX: 000000004321fedc RSI: 0000000028121969 RDI: 00000000fee1dead
[ 189.319944] RBP: 0000000000000000 R08: 0000000000000040 R09: 0000000000000005
[ 189.327224] R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000000
[ 189.334512] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 189.341794] ---[ end trace 4c38720b40d3b851 ]---
pmenzel
added a commit
that referenced
this pull request
Jul 28, 2020
Building ipmi_msghandler as a module causes – as always – problems with
the proprietary Nvidia driver. For whatever reasons, it depends on
functions from the module, and is unable to load the module itself –
probably because of our mxgfx indirection.
2020-06-17T13:56:09.272068+02:00 sigchld kernel: [ 0.000000] Linux version 5.4.46.mx64.337 (root@invidia.molgen.mpg.de) (gcc version 7.5.0 (GCC)) #1 SMP Tue Jun 16 23:32:15 CEST 2020
[…]
2020-06-17T13:56:09.322119+02:00 sigchld kernel: [ 3.907200] nvidia: loading out-of-tree module taints kernel.
2020-06-17T13:56:09.322140+02:00 sigchld kernel: [ 3.911716] nvidia: module license 'NVIDIA' taints kernel.
2020-06-17T13:56:09.333611+02:00 sigchld kernel: [ 3.923028] nvidia: module verification failed: signature and/or required key missing - tainting kernel
2020-06-17T13:56:09.333620+02:00 sigchld kernel: [ 3.926029] nvidia: Unknown symbol ipmi_create_user (err -2)
2020-06-17T13:56:09.335472+02:00 sigchld kernel: [ 3.927879] nvidia: Unknown symbol ipmi_destroy_user (err -2)
2020-06-17T13:56:09.337338+02:00 sigchld kernel: [ 3.929720] nvidia: Unknown symbol ipmi_validate_addr (err -2)
2020-06-17T13:56:09.337342+02:00 sigchld kernel: [ 3.931552] nvidia: Unknown symbol ipmi_free_recv_msg (err -2)
2020-06-17T13:56:09.339180+02:00 sigchld kernel: [ 3.933377] nvidia: Unknown symbol ipmi_set_my_address (err -2)
2020-06-17T13:56:09.341000+02:00 sigchld kernel: [ 3.935221] nvidia: Unknown symbol ipmi_request_settime (err -2)
2020-06-17T13:56:09.342899+02:00 sigchld kernel: [ 3.937102] nvidia: Unknown symbol ipmi_set_gets_events (err -2)
2020-06-17T13:56:09.385602+02:00 sigchld kernel: [ 3.975577] nvidia_uvm: Unknown symbol nvUvmInterfaceDisableAccessCntr (err -2)
2020-06-17T13:56:09.385614+02:00 sigchld kernel: [ 3.977740] nvidia_uvm: Unknown symbol nvUvmInterfaceChannelDestroy (err -2)
2020-06-17T13:56:09.385615+02:00 sigchld kernel: [ 3.979796] nvidia_uvm: Unknown symbol nvUvmInterfaceQueryCaps (err -2)
2020-06-17T13:56:09.387549+02:00 sigchld kernel: [ 3.981756] nvidia_uvm: Unknown symbol nvUvmInterfaceUnsetPageDirectory (err -2)
2020-06-17T13:56:09.389361+02:00 sigchld kernel: [ 3.983558] nvidia_uvm: Unknown symbol nvUvmInterfaceInitAccessCntrInfo (err -2)
2020-06-17T13:56:09.391153+02:00 sigchld kernel: [ 3.985352] nvidia_uvm: Unknown symbol nvUvmInterfaceReleaseChannel (err -2)
2020-06-17T13:56:09.392781+02:00 sigchld kernel: [ 3.986986] nvidia_uvm: Unknown symbol nvUvmInterfaceMemoryAllocSys (err -2)
2020-06-17T13:56:09.394816+02:00 sigchld kernel: [ 3.989018] nvidia_uvm: Unknown symbol nvUvmInterfaceMemoryCpuMap (err -2)
2020-06-17T13:56:09.398324+02:00 sigchld kernel: [ 3.992539] nvidia_uvm: Unknown symbol nvUvmInterfaceRetainChannelResources (err -2)
2020-06-17T13:56:09.403240+02:00 sigchld kernel: [ 3.997423] nvidia_uvm: Unknown symbol nvUvmInterfacePmaFreePages (err -2)
[…]
So partly revert commit 32c9443 (linux-5.4.46: Build IPMI drivers as
modules), and build impi_msghandler into the Linux kernel.
pmenzel
added a commit
that referenced
this pull request
Jul 21, 2023
Add the userspace part for driver version 510.108.03.
Created with the command below and adapting the source URL:
$ cp -a nvidia_current-510.60.02-1.bee nvidia_current-510.108.03-0.bee
Tested on *sigusr2*:
$ dmesg | grep -e "Linux version" -e "DMI:" ; dmesg --level=crit,alert,err,warn
[ 0.000000] Linux version 6.1.39.mx64.450 (root@holidayincambodia.molgen.mpg.de) (gcc (GCC) 10.4.0, GNU ld (GNU Binutils) 2.40) #1 SMP PREEMPT_DYNAMIC Wed Jul 19 20:07:19 CEST 2023
[ 0.000000] DMI: Dell Inc. OptiPlex 7071/097YXY, BIOS 1.1.2 08/29/2019
[ 1.428282] Spectre V2 : WARNING: Unprivileged eBPF is enabled with eIBRS on, data leaks possible via Spectre v2 BHB attacks!
[ 1.468459] ENERGY_PERF_BIAS: Set to 'normal', was 'performance'
[ 2.645812] hpet_acpi_add: no address or irqs in _CRS
[ 2.894418] usb: port power management may be unreliable
[ 4.099489] wmi_bus wmi_bus-PNP0C14:04: WQBC data block query control method not found
[ 14.880380] nvidia: loading out-of-tree module taints kernel.
[ 14.886176] nvidia: module license 'NVIDIA' taints kernel.
[ 14.891713] Disabling lock debugging due to kernel taint
[ 15.273921] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 510.108.03 Thu Oct 20 05:10:45 UTC 2022
[ 15.302831] nvidia_uvm: module uses symbols nvUvmInterfaceDisableAccessCntr from proprietary module nvidia, inheriting taint.
$ glxinfo | grep info
server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
OpenGL core profile version string: 4.6.0 NVIDIA 510.108.03
OpenGL core profile shading language version string: 4.60 NVIDIA
OpenGL version string: 4.6.0 NVIDIA 510.108.03
OpenGL shading language version string: 4.60 NVIDIA
OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 510.108.03
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
GL_EXT_shader_group_vote, GL_EXT_shader_implicit_conversions,
pmenzel
added a commit
that referenced
this pull request
Jul 21, 2023
Add the userspace part for driver version 510.108.03.
Created with the command below and adapting the source URL:
$ cp -a nvidia_current-510.60.02-1.bee nvidia_current-510.108.03-0.bee
Tested on *sigusr2*:
$ dmesg | grep -e "Linux version" -e "DMI:" ; dmesg --level=crit,alert,err,warn
[ 0.000000] Linux version 6.1.39.mx64.450 (root@holidayincambodia.molgen.mpg.de) (gcc (GCC) 10.4.0, GNU ld (GNU Binutils) 2.40) #1 SMP PREEMPT_DYNAMIC Wed Jul 19 20:07:19 CEST 2023
[ 0.000000] DMI: Dell Inc. OptiPlex 7071/097YXY, BIOS 1.1.2 08/29/2019
[ 1.428282] Spectre V2 : WARNING: Unprivileged eBPF is enabled with eIBRS on, data leaks possible via Spectre v2 BHB attacks!
[ 1.468459] ENERGY_PERF_BIAS: Set to 'normal', was 'performance'
[ 2.645812] hpet_acpi_add: no address or irqs in _CRS
[ 2.894418] usb: port power management may be unreliable
[ 4.099489] wmi_bus wmi_bus-PNP0C14:04: WQBC data block query control method not found
[ 14.880380] nvidia: loading out-of-tree module taints kernel.
[ 14.886176] nvidia: module license 'NVIDIA' taints kernel.
[ 14.891713] Disabling lock debugging due to kernel taint
[ 15.273921] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 510.108.03 Thu Oct 20 05:10:45 UTC 2022
[ 15.302831] nvidia_uvm: module uses symbols nvUvmInterfaceDisableAccessCntr from proprietary module nvidia, inheriting taint.
$ glxinfo | grep info
server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
OpenGL core profile version string: 4.6.0 NVIDIA 510.108.03
OpenGL core profile shading language version string: 4.60 NVIDIA
OpenGL version string: 4.6.0 NVIDIA 510.108.03
OpenGL shading language version string: 4.60 NVIDIA
OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 510.108.03
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
GL_EXT_shader_group_vote, GL_EXT_shader_implicit_conversions,
Sign in
to join this conversation on GitHub.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.