Add Linux 5.4.21

[pmenzel]

Enable X2APIC support to not crash on a Dell PowerEdge T640 with x2APIC enabled in the firmware.

Build and add EDAC and USB serial drivers as modules, disable the deprecated legacy IDE driver, and enable the Intel IOMMU driver.

Tested on hactar.

[thomas]

I propose to disable the SUSPEND setting, since this option alone doesn't help a lot. (We also have this freeze issues...) Another one would be the support for another USB serial gadget USB_SERIAL_PL2303 As for the Nvidia driver, there are some fixes conerning OpenCL pending. Cheers, Thomas

…

On February 21, 2020 3:52:37 PM GMT+01:00, Paul Menzel ***@***.***> wrote: Enable X2APIC support to not crash on a Dell PowerEdge T640 with x2APIC enabled in the firmware. Build the EDAC drivers as modules, disable the deprecated legacy IDE driver, and enable the Intel IOMMU driver. Tested on *hactar*. You can view, comment on, or merge this pull request online at: #1714 -- Commit Summary -- * linux: Add LTS version 5.4.21 * linux-5.4.21-323: Convert EDAC drivers to modules * linux-5.4.21-323: Select EDAC driver for Intel Skylake server Integrated MC * linux-5.4.21-323: Disable deprecated legacy IDE driver * linux-5.4.21-323: Select *Basic module for enforcing kernel lockdown* * linux-5.4.21-323: Select X2APIC * linux-5.4.21-323: Support Intel IOMMU using DMA Remapping Devices * linux-5.4.21-323: Select *AMD IOMMU Version 2 driver* * nvidia_linux: Build 440.44 for Linux 5.4.21-323 -- File Changes -- A linux-5.4.21-323.bee (900) A nvidia_linux-5.4.21-323-440.44-0.bee (60) -- Patch Links -- https://github.molgen.mpg.de/mariux64/bee-files/pull/1714.patch https://github.molgen.mpg.de/mariux64/bee-files/pull/1714.diff

-- Thomas Kreitler - Information Retrieval kreitler@molgen.mpg.de 49/30/8413 1702

[pmenzel]

I propose to disable the SUSPEND setting, since this option alone doesn't help a lot. (We also have this freeze issues...)

Besides the freezing issue having nothing to do with this, MarIuX can also be used on laptops.

Another one would be the support for another USB serial gadget USB_SERIAL_PL2303

Done.

As for the Nvidia driver, there are some fixes conerning OpenCL pending.

Unrelated to this merge/pull request.

[wwwutz]

MarIuX can also be used on laptops.

nope, it cannot.

[pmenzel]

MarIuX can also be used on laptops.

nope, it cannot.

Either I dreamt it, or you did use it on a Dell laptop.

[wwwutz]

My answer was exactly as specific as your objection. The Laptops we run mariux on do not SUSPEND.

so we're not talking about mariux and laptops, we're talking about mariux and suspend. And there was never and there will be no suspend support on mariux.

[thomas]

Some thoughts about the new kernel - Part 1

Concerning CONFIG_SUSPEND

Listed are the PM options used in mariux and from a decent distro (Slackware in this case, the other major players are similar). My conclusions follow below.

5.4.14.mx64.317

     1	#
     2	# Power management and ACPI options
     3	#
     4	CONFIG_SUSPEND=y
     5	CONFIG_SUSPEND_FREEZER=y
     6	# CONFIG_HIBERNATION is not set
     7	CONFIG_PM_SLEEP=y
     8	CONFIG_PM_SLEEP_SMP=y
     9	# CONFIG_PM_AUTOSLEEP is not set
    10	# CONFIG_PM_WAKELOCKS is not set
    11	CONFIG_PM=y
    12	# CONFIG_PM_DEBUG is not set
    13	CONFIG_PM_CLK=y
    14	# CONFIG_WQ_POWER_EFFICIENT_DEFAULT is not set
    15	# CONFIG_ENERGY_MODEL is not set
    16	CONFIG_ARCH_SUPPORTS_ACPI=y
    17	CONFIG_ACPI=y
    18	CONFIG_ACPI_LEGACY_TABLES_LOOKUP=y
    19	CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC=y
    20	CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT=y
    21	# CONFIG_ACPI_DEBUGGER is not set
    22	CONFIG_ACPI_SPCR_TABLE=y
    23	CONFIG_ACPI_LPIT=y
    24	CONFIG_ACPI_SLEEP=y
    25	# CONFIG_ACPI_PROCFS_POWER is not set
    26	CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y
    27	# CONFIG_ACPI_EC_DEBUGFS is not set
    28	# CONFIG_ACPI_AC is not set
    29	# CONFIG_ACPI_BATTERY is not set
    30	CONFIG_ACPI_BUTTON=y
    31	CONFIG_ACPI_VIDEO=m
    32	CONFIG_ACPI_FAN=y
    33	# CONFIG_ACPI_TAD is not set
    34	CONFIG_ACPI_DOCK=y
    35	CONFIG_ACPI_CPU_FREQ_PSS=y
    36	CONFIG_ACPI_PROCESSOR_CSTATE=y
    37	CONFIG_ACPI_PROCESSOR_IDLE=y
    38	CONFIG_ACPI_CPPC_LIB=y
    39	CONFIG_ACPI_PROCESSOR=y
    40	# CONFIG_ACPI_IPMI is not set
    41	CONFIG_ACPI_HOTPLUG_CPU=y
    42	# CONFIG_ACPI_PROCESSOR_AGGREGATOR is not set
    43	CONFIG_ACPI_THERMAL=y
    44	CONFIG_ACPI_NUMA=y
    45	CONFIG_ARCH_HAS_ACPI_TABLE_UPGRADE=y
    46	CONFIG_ACPI_TABLE_UPGRADE=y
    47	# CONFIG_ACPI_DEBUG is not set
    48	# CONFIG_ACPI_PCI_SLOT is not set
    49	CONFIG_ACPI_CONTAINER=y
    50	CONFIG_ACPI_HOTPLUG_IOAPIC=y
    51	# CONFIG_ACPI_SBS is not set
    52	# CONFIG_ACPI_HED is not set
    53	# CONFIG_ACPI_CUSTOM_METHOD is not set
    54	# CONFIG_ACPI_BGRT is not set
    55	# CONFIG_ACPI_NFIT is not set
    56	# CONFIG_ACPI_HMAT is not set
    57	CONFIG_HAVE_ACPI_APEI=y
    58	CONFIG_HAVE_ACPI_APEI_NMI=y
    59	# CONFIG_ACPI_APEI is not set
    60	# CONFIG_DPTF_POWER is not set
    61	# CONFIG_ACPI_EXTLOG is not set
    62	# CONFIG_PMIC_OPREGION is not set
    63	# CONFIG_ACPI_CONFIGFS is not set
    64	CONFIG_X86_PM_TIMER=y
    65	# CONFIG_SFI is not set

config-huge-5.4.13.x64 from slackware

     1	#
     2	# Power management and ACPI options
     3	#
     4	CONFIG_ARCH_HIBERNATION_HEADER=y
     5	CONFIG_SUSPEND=y
     6	CONFIG_SUSPEND_FREEZER=y
     7	# CONFIG_SUSPEND_SKIP_SYNC is not set
     8	CONFIG_HIBERNATE_CALLBACKS=y
     9	CONFIG_HIBERNATION=y
    10	CONFIG_PM_STD_PARTITION="\"\""
    11	CONFIG_PM_SLEEP=y
    12	CONFIG_PM_SLEEP_SMP=y
    13	# CONFIG_PM_AUTOSLEEP is not set
    14	CONFIG_PM_WAKELOCKS=y
    15	CONFIG_PM_WAKELOCKS_LIMIT=100
    16	CONFIG_PM_WAKELOCKS_GC=y
    17	CONFIG_PM=y
    18	# CONFIG_PM_DEBUG is not set
    19	CONFIG_PM_CLK=y
    20	CONFIG_PM_GENERIC_DOMAINS=y
    21	# CONFIG_WQ_POWER_EFFICIENT_DEFAULT is not set
    22	CONFIG_PM_GENERIC_DOMAINS_SLEEP=y
    23	# CONFIG_ENERGY_MODEL is not set
    24	CONFIG_ARCH_SUPPORTS_ACPI=y
    25	CONFIG_ACPI=y
    26	CONFIG_ACPI_LEGACY_TABLES_LOOKUP=y
    27	CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC=y
    28	CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT=y
    29	# CONFIG_ACPI_DEBUGGER is not set
    30	CONFIG_ACPI_SPCR_TABLE=y
    31	CONFIG_ACPI_LPIT=y
    32	CONFIG_ACPI_SLEEP=y
    33	CONFIG_ACPI_PROCFS_POWER=y
    34	CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y
    35	CONFIG_ACPI_EC_DEBUGFS=m
    36	CONFIG_ACPI_AC=m
    37	CONFIG_ACPI_BATTERY=m
    38	CONFIG_ACPI_BUTTON=m
    39	CONFIG_ACPI_VIDEO=m
    40	CONFIG_ACPI_FAN=m
    41	CONFIG_ACPI_TAD=m
    42	CONFIG_ACPI_DOCK=y
    43	CONFIG_ACPI_CPU_FREQ_PSS=y
    44	CONFIG_ACPI_PROCESSOR_CSTATE=y
    45	CONFIG_ACPI_PROCESSOR_IDLE=y
    46	CONFIG_ACPI_CPPC_LIB=y
    47	CONFIG_ACPI_PROCESSOR=y
    48	CONFIG_ACPI_IPMI=m
    49	CONFIG_ACPI_HOTPLUG_CPU=y
    50	CONFIG_ACPI_PROCESSOR_AGGREGATOR=m
    51	CONFIG_ACPI_THERMAL=m
    52	CONFIG_ACPI_NUMA=y
    53	CONFIG_ARCH_HAS_ACPI_TABLE_UPGRADE=y
    54	CONFIG_ACPI_TABLE_UPGRADE=y
    55	# CONFIG_ACPI_DEBUG is not set
    56	CONFIG_ACPI_PCI_SLOT=y
    57	CONFIG_ACPI_CONTAINER=y
    58	CONFIG_ACPI_HOTPLUG_MEMORY=y
    59	CONFIG_ACPI_HOTPLUG_IOAPIC=y
    60	CONFIG_ACPI_SBS=m
    61	CONFIG_ACPI_HED=y
    62	# CONFIG_ACPI_CUSTOM_METHOD is not set
    63	CONFIG_ACPI_BGRT=y
    64	# CONFIG_ACPI_REDUCED_HARDWARE_ONLY is not set
    65	CONFIG_ACPI_NFIT=m
    66	# CONFIG_NFIT_SECURITY_DEBUG is not set
    67	CONFIG_ACPI_HMAT=y
    68	CONFIG_HAVE_ACPI_APEI=y
    69	CONFIG_HAVE_ACPI_APEI_NMI=y
    70	CONFIG_ACPI_APEI=y
    71	CONFIG_ACPI_APEI_GHES=y
    72	CONFIG_ACPI_APEI_PCIEAER=y
    73	CONFIG_ACPI_APEI_MEMORY_FAILURE=y
    74	CONFIG_ACPI_APEI_EINJ=m
    75	CONFIG_ACPI_APEI_ERST_DEBUG=m
    76	CONFIG_DPTF_POWER=m
    77	CONFIG_ACPI_WATCHDOG=y
    78	CONFIG_ACPI_EXTLOG=m
    79	CONFIG_ACPI_ADXL=y
    80	CONFIG_PMIC_OPREGION=y
    81	CONFIG_BXT_WC_PMIC_OPREGION=y
    82	CONFIG_CHT_DC_TI_PMIC_OPREGION=y
    83	CONFIG_ACPI_CONFIGFS=m
    84	CONFIG_X86_PM_TIMER=y
    85	CONFIG_SFI=y

On mariux it's mainly CONFIG_SUSPEND set to YES in the top level, all the other features are not considered. I doubt that this will yield an usable and stable configuration for the whole power-saving scenario. To me this is more like pushing one out of ten buttons and see what will happen.

Also this mainly applies for laptops, in no case for our servers, and for the workstations I don't see a real reason (N.B. is there a 'Wake-On-Dist' functionality?).
Back to laptops, there are still reports/observations that suspend under linux drains the batteries quicker than the competitors OS. My interpretation of this is that these features are still somewhat experimental; read: sometimes it works, sometime it doesn't.

So shortly CONFIG_SUSPEND -> No

[thomas]

Some thoughts about the new kernel - Part 2&3

2. New Features

CONFIG_USB_SERIAL_PL2303, ACK :)

Peter and me intend to take a look on ceph-fs in the near future, from the kernel side the necessary options are already set. So no changes needed.

3. The beloved Nvidia-Driver

There are problems with the OpenCl support, but these issues need to be fixed in nvidia_current-440.44/nvidia-mxlinks, so the kernel module build is unaffected.

[donald]

On mariux it's mainly CONFIG_SUSPEND set to YES in the top level, all the other features are not considered.

Not really. CONFIG_SUSPEND is set, because it is default.

Dec 2017 we changed from implicitly inheriting the configuration from previous builds into explicitly enumerating them in the bee file.

The configuration in the bee file is the output from "make savedefconfig", so these are the lines where we deviate from the defaults. Our idea since then is, that ideally each line there should have some justification, which is documented in the commit which changed the line. We started from a inherited configuration jam, where nobody knew, where the individual options came from and why they were set the way they were ("Kettenmaß") . We might not yet have a commit for each and every line, but we do have a commit for every line which was touched since then, and I'd guess these are most of them.

The procedure to get the change and the implied changes of the change and the implied changes of any kernel upgrade into the bee file in the correct format, is not really trivial, and maybe I should write a cookbook for it.

Anyway: Is it agreed, that we shouldn't change from the Linux defaults without good reason? If so, I'd ask for an argument to override CONFIG_SUSPEND from the default "yes" to "no". We don't need an argument to not touch it.

"We think, that the workstations freezes may have something to do with it, and by disabling it, we might avoid freezing workstations" would certainly be a valid argument. But is it true, do we really think, the workstation might be trying to go into suspend mode? Do we have any indication for that?

Another possible argument (as an example) would be "If we don't include the SUSPEND code, we'd save so and so many GB of memory which the user could use."

However, these statements are not valid arguments for me:

• The option doesn't help a lot
• decent distro, slackware have this or that configuration
• other features are not considered

And

I doubt that this will yield an usable and stable configuration for the whole power-saving scenario.

I'd say, that the Linux default configuration has the best chance of being usable and coherent.

To me this is more like pushing one out of ten buttons and see what will happen.

Right, but considering that CONFIG_SUSPEND=yes is the default, this argument goes more to the other side, doesn't it?

[pmenzel]

@donald, thank you for writing the elaborate explanation. That was my thinking too.

I propose to accept this merge/pull request, as it’s already running on hactar, and kindly ask you to open an issue for disabling suspend, if somebody still thinks it would be useful for MarIuX.

[thomas]

Sure, CONFIG_SUSPEND=y is the default, but if you compare the config state after several rounds of 'savedefconfig', and a plain 'make defconfig'

#diff -U0 default.conf hactar.conf | gr -v '@'
--- default.conf        2020-02-27 15:15:48.411855643 +0100
+++ hactar.conf 2020-02-27 15:15:58.467878212 +0100
-CONFIG_ARCH_HIBERNATION_HEADER=y
-CONFIG_HIBERNATE_CALLBACKS=y
-CONFIG_HIBERNATION=y
-CONFIG_PM_STD_PARTITION=""
+# CONFIG_HIBERNATION is not set
-CONFIG_PM_DEBUG=y
-# CONFIG_PM_ADVANCED_DEBUG is not set
-# CONFIG_PM_TEST_SUSPEND is not set
-CONFIG_PM_SLEEP_DEBUG=y
-CONFIG_PM_TRACE=y
-CONFIG_PM_TRACE_RTC=y
+# CONFIG_PM_DEBUG is not set
-CONFIG_ACPI_AC=y
-CONFIG_ACPI_BATTERY=y
+# CONFIG_ACPI_AC is not set
+# CONFIG_ACPI_BATTERY is not set
-CONFIG_ACPI_VIDEO=y
+CONFIG_ACPI_VIDEO=m
+# CONFIG_ACPI_IPMI is not set
-CONFIG_ACPI_BGRT=y
+# CONFIG_ACPI_BGRT is not set
+CONFIG_ACPI_ADXL=y

Then I might state, 'yes we are using a default option', but we simply ignore other defaults from the same context.

I'd say, that the Linux default configuration has the best chance of being usable and coherent.

If it comes to chances, personally I wouldn't bet too much in this case, since it is not the 'Linux default-configuration' it's a config using defaults.

[donald]

but if you compare the config state after several rounds of 'savedefconfig', and a plain 'make defconfig'

I think, this is because, make defconfig applies architecture defaults (and compiler-depend defaults?) , too, while make savedefconfig doesn't. There is a make alldefconfig, which doesn't apply architecture defaults and better compares to make savedefconfig

buczek@theinternet:/scratch/local/bee-buczek/linux/linux-5.4.21-323/build$ make alldefconfig
scripts/kconfig/conf  --alldefconfig Kconfig
# 
# configuration written to .config
#
buczek@theinternet:/scratch/local/bee-buczek/linux/linux-5.4.21-323/build$ make savedefconfig
scripts/kconfig/conf  --savedefconfig=defconfig Kconfig
buczek@theinternet:/scratch/local/bee-buczek/linux/linux-5.4.21-323/build$ ls -l defconfig
-rw-rw---- 1 buczek buczek 0 Feb 27 16:42 defconfig

Maybe it would be more logical to base our settings in the bee file on top of the defconfig for x86_64 and not on top of the architecture independent alldefconfig, although I'm not yet sure, how this could be done. The system is really difficult to understand and use.

It doesn't make a difference for SUSPEND, though, which is "yes" after make defconfig as well as after make alldefconfig.

If it comes to chances, personally I wouldn't bet too much in this case, since it is not the 'Linux default-configuration' it's a config using defaults.

Is there a difference between "the 'Linux default-configuration' " and "a config using defaults" when the defaults come from Linux and there is no other source aside from that?

[thomas]

Is there a difference between "the 'Linux default-configuration' " and "a config using defaults" when the defaults come from Linux and there is no other source aside from that?

I don't see that we reach an agreement here. Your argumentation goes
CONFIG_XXX has default A, so we need a reason to change it.
I doubt that keeping a single setting and ignoring the others (default or not) from the whole context makes sense.

And yes, there is a difference. I would recheck/readjust the current stage of the evolved config (ie ours) and the current default set (kernel, distros) -- at least from time to time.