On kernel version *4.15.0-sabayon*, the only way to load X is with the kernel options: acpi_osi=! acpi_osi='Windows 2009' (and acpi=off but that's radical and leaves me with no sensors). Otherwise I get unresponsive black screen and no obvious error in the X.org log. The problem with this option is that it turns off the *Elan 1200 touchpad* (not only for me, other people complain about it as well). So I'm looking for other (if possible tested) kernel options which might work on my laptop (or similar). I've tested already many permutations of different windows versions and modeset and acpi_rev_override=5 and pcie_port_pm=off, but obviously I can't cover them all so if anyone had success with this, please share.

Trying to permanently change some vm kernel parameters, I created /etc/sysctl.d/01-custom.conf config file as it described in Red Hat knowledgebase article. Here is its content: # cat /etc/sysctl.d/01-custom.conf vm.swappiness=10 vm.dirty_ratio=20 vm.vfs_cache_pressure=200 But after reboot only vm.vfs_cache_pressure is changed and swappines and dirty_ratio have previous values. # sysctl vm.swappiness vm.swappiness = 30 # sysctl vm.dirty_ratio vm.dirty_ratio = 30 In /etc/sysctl.conf file there is no changes for vm.dirty_ratio parameter and vm.swappines is set to 10 as well. Does it mean that the system takes these values from somewhere else? There are no any config files under /etc/sysctl.d besides mine and link to /etc/sysctl.conf: # ll /etc/sysctl.d/ total 4 -rw-r--r-- 1 root root 147 May 30 04:40 01-custom.conf lrwxrwxrwx. 1 root root 14 Apr 3 15:00 99-sysctl.conf -> ../sysctl.conf **Update:** sysctl --system shows that values from my config were taken. Nothing for vm.swappines and vm.dirty_ratio are set to 30.

I am trying to enable KASAN in my Manjaro distribution for a project, but I have no idea how to. The documentation here (https://www.kernel.org/doc/html/v4.14/dev-tools/kasan.html) says just to CONFIG_KASAN = y but I have no idea where to do and what steps should I take before that, I haven't configured the kernel before, I am a beginner. So far I have found out that I can see what configurations are done by looking at /proc/config.gz Here it says that KASAN is not enabled, but I don't know where to go from here. Should I just do an echo CONFIG_KASAN= y, or do I have to rebuild the Kernel and such? Please help me.

I got an IBM x3850 type 8864 machine, I can successfully boot using a 2.6.32 kernel but when I try to use a 3.10 kernel or newer the kernel fails to initialize all PCI slots (I can fix this (manually), see below): pci 0000:19:00.0: BAR 14: can't assign mem (size 0x1a00000) pci 0000:19:00.0: BAR 13: can't assign io (size 0x3000) pci 0000:19:00.0: BAR 14: can't assign mem (size 0x1600000) pci 0000:19:00.0: BAR 13: can't assign io (size 0x3000) pci 0000:1a:00.0: BAR 14: can't assign mem (size 0x1600000) pci 0000:1a:00.0: BAR 13: assigned [io 0x7000-0x8fff] pci 0000:1b:02.0: BAR 14: can't assign mem (size 0xa00000) pci 0000:1b:04.0: BAR 14: can't assign mem (size 0xa00000) pci 0000:1b:02.0: BAR 13: assigned [io 0x7000-0x7fff] pci 0000:1b:04.0: BAR 13: assigned [io 0x8000-0x8fff] ... Which causes that my network card is not successfully loaded as the PCI bus is obviously not correctly instantiated. lspci yields the following: 00:00.0 Host bridge: IBM Calgary PCI-X Host Bridge (rev 04) 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV100 [Radeon 7000 / Radeon VE] 00:03.0 USB controller: NEC Corporation OHCI USB Controller (rev 43) 00:03.1 USB controller: NEC Corporation OHCI USB Controller (rev 43) 00:03.2 USB controller: NEC Corporation uPD72010x USB 2.0 Controller (rev 04) 00:0f.0 Host bridge: Broadcom CSB6 South Bridge (rev a0) 00:0f.1 IDE interface: Broadcom CSB6 RAID/IDE Controller (rev a0) 00:0f.3 ISA bridge: Broadcom GCLE-2 Host Bridge 01:00.0 Host bridge: IBM Calgary PCI-X Host Bridge (rev 04) 01:01.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet (rev 10) 01:01.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet (rev 10) 01:02.0 RAID bus controller: Adaptec AAC-RAID (rev 02) 02:00.0 Host bridge: IBM Calgary PCI-X Host Bridge (rev 04) 06:00.0 Host bridge: IBM Calgary PCI-X Host Bridge (rev 04) 0a:00.0 PCI bridge: IBM CalIOC2 PCI-E Root Port (rev 01) 0f:00.0 PCI bridge: IBM CalIOC2 PCI-E Root Port (rev 01) 14:00.0 PCI bridge: IBM CalIOC2 PCI-E Root Port (rev 01) 19:00.0 PCI bridge: IBM CalIOC2 PCI-E Root Port (rev 01) 1a:00.0 PCI bridge: Integrated Device Technology, Inc. [IDT] PES12N3A PCI Express Switch (rev 0c) 1b:02.0 PCI bridge: Integrated Device Technology, Inc. [IDT] PES12N3A PCI Express Switch (rev 0c) 1b:04.0 PCI bridge: Integrated Device Technology, Inc. [IDT] PES12N3A PCI Express Switch (rev 0c) 1c:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01) 1c:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01) 1d:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01) 1d:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01) # FIX # I can actually fix it by removing the root PCI bus 19:00.0 PCI bridge: IBM CalIOC2 PCI-E Root Port (rev 01) via echo 1 > /sys/bus/pci/devices/0000\:19\:00.0/remove and a rescan afterwards: echo 1 > /sys/bus/pci/rescan which causes the following output: pci _bus 0000:1c: busn_res: [bus 1c] is released pci _bus 0000:1d: busn_res: [bus 1d] is released pci _bus 0000:1b: busn_res: [bus 1b-1d] is released pci _bus 0000:1a: busn_res: [bus 1a-1d] is released pci 0000:19:00.0: [1014:0308] type 01 class 0x060401 pci 0000:19:00.0: supports D1 D2 pci 0000:19:00.0: PME# supported from D0 D1 D2 D3hot D3cold pci 0000:1a:00.0: [111d:8018] type 01 class 0x060400 pci 0000:1a:00.0: PME# supported from D0 D3hot D3cold pci 0000:19:00.0: pci bridge to [bus 1a-1d] (subtractive decode) pci 0000:19:00.0: bridge window [mem 0xea800000-0xea9fffff 64bit pref] pci 0000:19:00.0: bridge window [mem 0xea800000-0xebcfffff] (subtractive decode) pci 0000:19:00.0: bridge window [io 0x7000-0x8fff] (subtractive decode) pci 0000:1b:02.0: [111d:8018] type 01 class 0x060400 pci 0000:1b:02.0: PME# supported from D0 D3hot D3cold pci 0000:1b:04.0: [111d:8018] type 01 class 0x060400 pci 0000:1b:04.0: PME# supported from D0 D3hot D3cold pci 0000:1a:00.0: pci bridge to [bus 1b-1d] pci 0000:1a:00.0: bridge window [io 0x7000-0x8fff] pci 0000:1a:00.0: bridge window [mem 0xea800000-0xea9fffff 64bit pref] .... pci 0000:1b:04.0: bridge window [mem 0xea900000-0xea9fffff 64bit pref] pci 0000:1b:02.0: bridge window [mem 0x00100000-0x001fffff 64bit pref] to [bus 1c] add_size 100000 pci 0000:1b:04.0: bridge window [mem 0x00100000-0x001fffff 64bit pref] to [bus 1d] add_size 100000 pci 0000:1b:02.0: res=[mem 0x00100000-0x001fffff 64bit pref] get_res_add_size add_size 100000 pci 0000:1b:04.0: res=[mem 0x00100000-0x001fffff 64bit pref] get_res_add_size add_size 100000 pci 0000:1a:00.0: bridge window [mem 0x00100000-0x002fffff 64bit pref] to [bus 1b-1d] add_size 200000 pci 0000:19:00.0: bridge window [io 0x1000-0x2fff] to [bus 1a-1d] add_size 1000 pci 0000:1a:00.0: res=[mem 0x00100000-0x002fffff 64bit pref] get_res_add_size add_size 200000 pci 0000:19:00.0: bridge window [mem 0x00100000-0x002fffff 64bit pref] to [bus 1a-1d] add_size 200000 pci 0000:19:00.0: bridge window [mem 0x00200000-0x015fffff] to [bus 1a-1d] add_size 200000 pci 0000:19:00.0: res=[mem 0x00200000-0x015fffff] get_res_add_size add_size 200000 pci 0000:19:00.0: res=[mem 0x00100000-0x002fffff 64bit pref] get_res_add_size add_size 200000 pci 0000:19:00.0: res=[io 0x1000-0x2fff] get_res_add_size add_size 1000 pci 0000:19:00.0: BAR 14: can't assign mem (size 0x1600000) pci 0000:19:00.0: BAR 15: assigned [mem 0xea800000-0xeabfffff 64bit pref] pci 0000:19:00.0: BAR 13: can't assign io (size 0x3000) pci 0000:19:00.0: BAR 14: assigned [mem 0xea800000-0xebbfffff] pci 0000:19:00.0: BAR 15: can't assign mem pref (size 0x200000) pci 0000:19:00.0: BAR 13: assigned [io 0x7000-0x8fff] pci 0000:19:00.0: BAR 14: can't assign mem (size 0x1400000) pci 0000:19:00.0: failed to add 200000 res=[mem 0xea800000-0xebbfffff] pci 0000:19:00.0: BAR 13: can't assign io (size 0x2000) pci 0000:19:00.0: failed to add 1000 res=[io 0x7000-0x8fff] pci 0000:1a:00.0: res=[mem 0x00100000-0x002fffff 64bit pref] get_res_add_size add_size 200000 pci 0000:1a:00.0: BAR 14: assigned [mem 0xea800000-0xebbfffff] pci 0000:1a:00.0: BAR 15: can't assign mem pref (size 0x400000) pci 0000:1a:00.0: BAR 13: assigned [io 0x7000-0x8fff] pci 0000:1a:00.0: BAR 14: assigned [mem 0xea800000-0xebbfffff] pci 0000:1a:00.0: BAR 15: can't assign mem pref (size 0x200000) pci 0000:1b:02.0: res=[mem 0x00100000-0x001fffff 64bit pref] get_res_add_size add_size 100000 pci 0000:1b:04.0: res=[mem 0x00100000-0x001fffff 64bit pref] get_res_add_size add_size 100000 pci 0000:1b:02.0: BAR 14: assigned [mem 0xea800000-0xeb1fffff] pci 0000:1b:04.0: BAR 14: assigned [mem 0xeb200000-0xebbfffff] pci 0000:1b:02.0: BAR 15: can't assign mem pref (size 0x200000) pci 0000:1b:04.0: BAR 15: can't assign mem pref (size 0x200000) pci 0000:1b:02.0: BAR 13: assigned [io 0x7000-0x7fff] pci 0000:1b:04.0: BAR 13: assigned [io 0x8000-0x8fff] pci 0000:1b:02.0: BAR 14: assigned [mem 0xea800000-0xeb1fffff] pci 0000:1b:04.0: BAR 14: assigned [mem 0xeb200000-0xebbfffff] pci 0000:1b:02.0: BAR 15: can't assign mem pref (size 0x100000) pci 0000:1b:04.0: BAR 15: can't assign mem pref (size 0x100000) pci 0000:1c:00.0: reg 184: [mem 0xea800000-0xea803fff 64bit pref] pci 0000:1c:00.0: reg 190: [mem 0xea820000-0xea823fff 64bit pref] pci 0000:1c:00.0: reg 184: [mem 0xea800000-0xea803fff 64bit pref] pci 0000:1c:00.0: reg 184: [mem 0xea800000-0xea803fff 64bit pref] pci 0000:1c:00.0: reg 190: [mem 0xea820000-0xea823fff 64bit pref] pci 0000:1c:00.0: reg 184: [mem 0xea800000-0xea803fff 64bit pref] pci 0000:1c:00.0: reg 190: [mem 0xea820000-0xea823fff 64bit pref] pci 0000:1c:00.1: reg 184: [mem 0xea840000-0xea843fff 64bit pref] pci 0000:1c:00.0: reg 184: [mem 0xea800000-0xea803fff 64bit pref] pci 0000:1c:00.0: reg 190: [mem 0xea820000-0xea823fff 64bit pref] pci 0000:1c:00.1: reg 190: [mem 0xea860000-0xea863fff 64bit pref] pci 0000:1c:00.0: reg 184: [mem 0xea800000-0xea803fff 64bit pref] pci 0000:1c:00.0: reg 190: [mem 0xea820000-0xea823fff 64bit pref] pci 0000:1c:00.1: reg 184: [mem 0xea840000-0xea843fff 64bit pref] pci 0000:1c:00.0: res=[mem 0xea800000-0xea7fffff 64bit pref] get_res_add_size add_size 20000 pci 0000:1c:00.0: res=[mem 0xea820000-0xea81ffff 64bit pref] get_res_add_size add_size 20000 pci 0000:1c:00.1: res=[mem 0xea840000-0xea83ffff 64bit pref] get_res_add_size add_size 20000 pci 0000:1c:00.1: res=[mem 0xea860000-0xea85ffff 64bit pref] get_res_add_size add_size 20000 pci 0000:1c:00.0: BAR 1: assigned [mem 0xea800000-0xeabfffff] pci 0000:1c:00.1: BAR 1: assigned [mem 0xeac00000-0xeaffffff] pci 0000:1c:00.0: BAR 0: assigned [mem 0xeb000000-0xeb01ffff] pci 0000:1c:00.1: BAR 0: assigned [mem 0xeb020000-0xeb03ffff] pci 0000:1c:00.0: BAR 3: assigned [mem 0xeb040000-0xeb043fff] pci 0000:1c:00.0: reg 184: [mem 0xea800000-0xea803fff 64bit pref] pci 0000:1c:00.0: BAR 7: assigned [mem 0xeb044000-0xeb063fff 64bit pref] pci 0000:1c:00.0: reg 190: [mem 0xea820000-0xea823fff 64bit pref] pci 0000:1c:00.0: BAR 10: assigned [mem 0xeb064000-0xeb083fff 64bit pref] pci 0000:1c:00.1: BAR 3: assigned [mem 0xeb084000-0xeb087fff] pci 0000:1c:00.1: reg 184: [mem 0xea840000-0xea843fff 64bit pref] pci 0000:1c:00.1: BAR 7: assigned [mem 0xeb088000-0xeb0a7fff 64bit pref] pci 0000:1c:00.1: reg 190: [mem 0xea860000-0xea863fff 64bit pref] pci 0000:1c:00.1: BAR 10: assigned [mem 0xeb0a8000-0xeb0c7fff 64bit pref] pci 0000:1c:00.0: BAR 2: assigned [io 0x7000-0x701f] pci 0000:1c:00.1: BAR 2: assigned [io 0x7020-0x703f] pci 0000:1b:02.0: pci bridge to [bus 1c] pci 0000:1b:02.0: bridge window [io 0x7000-0x7fff] pci 0000:1b:02.0: bridge window [mem 0xea800000-0xeb1fffff] pci 0000:1d:00.0: reg 184: [mem 0xea900000-0xea903fff 64bit pref] pci 0000:1d:00.0: reg 190: [mem 0xea920000-0xea923fff 64bit pref] pci 0000:1d:00.0: reg 184: [mem 0xea900000-0xea903fff 64bit pref] pci 0000:1d:00.0: reg 184: [mem 0xea900000-0xea903fff 64bit pref] pci 0000:1d:00.0: reg 190: [mem 0xea920000-0xea923fff 64bit pref] pci 0000:1d:00.0: reg 184: [mem 0xea900000-0xea903fff 64bit pref] pci 0000:1d:00.0: reg 190: [mem 0xea920000-0xea923fff 64bit pref] pci 0000:1d:00.1: reg 184: [mem 0xea940000-0xea943fff 64bit pref] pci 0000:1d:00.0: reg 184: [mem 0xea900000-0xea903fff 64bit pref] pci 0000:1d:00.0: reg 190: [mem 0xea920000-0xea923fff 64bit pref] pci 0000:1d:00.1: reg 190: [mem 0xea960000-0xea963fff 64bit pref] pci 0000:1d:00.0: reg 184: [mem 0xea900000-0xea903fff 64bit pref] pci 0000:1d:00.0: reg 190: [mem 0xea920000-0xea923fff 64bit pref] pci 0000:1d:00.1: reg 184: [mem 0xea940000-0xea943fff 64bit pref] pci 0000:1d:00.0: res=[mem 0xea900000-0xea8fffff 64bit pref] get_res_add_size add_size 20000 pci 0000:1d:00.0: res=[mem 0xea920000-0xea91ffff 64bit pref] get_res_add_size add_size 20000 pci 0000:1d:00.1: res=[mem 0xea940000-0xea93ffff 64bit pref] get_res_add_size add_size 20000 pci 0000:1d:00.1: res=[mem 0xea960000-0xea95ffff 64bit pref] get_res_add_size add_size 20000 pci 0000:1d:00.0: BAR 1: assigned [mem 0xeb400000-0xeb7fffff] pci 0000:1d:00.1: BAR 1: assigned [mem 0xeb800000-0xebbfffff] pci 0000:1d:00.0: BAR 0: assigned [mem 0xeb200000-0xeb21ffff] pci 0000:1d:00.1: BAR 0: assigned [mem 0xeb220000-0xeb23ffff] pci 0000:1d:00.0: BAR 3: assigned [mem 0xeb240000-0xeb243fff] pci 0000:1d:00.0: reg 184: [mem 0xea900000-0xea903fff 64bit pref] pci 0000:1d:00.0: BAR 7: assigned [mem 0xeb244000-0xeb263fff 64bit pref] pci 0000:1d:00.0: reg 190: [mem 0xea920000-0xea923fff 64bit pref] pci 0000:1d:00.0: BAR 10: assigned [mem 0xeb264000-0xeb283fff 64bit pref] pci 0000:1d:00.1: BAR 3: assigned [mem 0xeb284000-0xeb287fff] pci 0000:1d:00.1: reg 184: [mem 0xea940000-0xea943fff 64bit pref] pci 0000:1d:00.1: BAR 7: assigned [mem 0xeb288000-0xeb2a7fff 64bit pref] pci 0000:1d:00.1: reg 190: [mem 0xea960000-0xea963fff 64bit pref] pci 0000:1d:00.1: BAR 10: assigned [mem 0xeb2a8000-0xeb2c7fff 64bit pref] pci 0000:1d:00.0: BAR 2: assigned [io 0x8000-0x801f] pci 0000:1d:00.1: BAR 2: assigned [io 0x8020-0x803f] pci 0000:1b:04.0: pci bridge to [bus 1d] pci 0000:1b:04.0: bridge window [io 0x8000-0x8fff] pci 0000:1b:04.0: bridge window [mem 0xeb200000-0xebbfffff] pci 0000:1a:00.0: pci bridge to [bus 1b-1d] pci 0000:1a:00.0: bridge window [io 0x7000-0x8fff] pci 0000:1a:00.0: bridge window [mem 0xea800000-0xebbfffff] pci 0000:19:00.0: pci bridge to [bus 1a-1d] pci 0000:19:00.0: bridge window [io 0x7000-0x8fff] pci 0000:19:00.0: bridge window [mem 0xea800000-0xebbfffff] # QUESTION # Is it somehow possible to tell the kernel (e.g. via a parameter) to automatically do this? What is causing this issue in the first place? Thank you in advance! ## Update ## As the described fix fails on a 4.x system (actually starting with 3.12 I suppose), I had a look at the kernel and found that if I disable PCI ASPM (which was already disabled by ACPI (t can also be forced by pcie_aspm=off in kernel boot parameter)), the following small fix (on a 4.4.0) resolves a kernel null pointer dereference: --- a/drivers/pci/pcie/aspm.c +++ b/drivers/pci/pcie/aspm.c @@ -552,11 +552,12 @@ static struct pcie_link_state *alloc_pcie_link_state(struct pci_dev *pdev) void pcie_aspm_init_link_state(struct pci_dev *pdev) { struct pcie_link_state *link; - int blacklist = !!pcie_aspm_sanity_check(pdev); - + int blacklist; if (!aspm_support_enabled) return; + blacklist = !!pcie_aspm_sanity_check(pdev); + if (pdev->link_state) return; Kind of odd that a sanity check is performed if the feature itself is deactivated, the actual null pointer dereference happend in pcie_aspm_sanity_check in this line list_for_each_entry(child, &pdev->subordinate->devices, bus_list) {. Is this a kernel bug?

I bought this second hand laptop one month ago (Lenovo X1 carbon gen7) and I started installing Arch Linux on it and I noticed there was a problem with the touch pad. The touchpad works at the end but lags something and the feeling is not smooth as it has to be normally, I cannot explain my issue better than this. So now I tried another OS, I'm trying NixOS and I still have the same issue.I also tried to change battery cause maybe the old battery could cause some issues but nothing. So I decided to ask you that maybe you know what can be the problem. From the dmesg --level=err,warn I got the following:

[    0.281813] Transient Scheduler Attacks: MMIO Stale Data CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/processor_mmio_stale_data.html  for more details.
[    0.700594] pnp 00:09: disabling [mem 0x000c0000-0x000c3fff] because it overlaps 0000:00:02.0 BAR 6 [mem 0x000c0000-0x000dffff]
[    0.700601] pnp 00:09: disabling [mem 0x000c8000-0x000cbfff] because it overlaps 0000:00:02.0 BAR 6 [mem 0x000c0000-0x000dffff]
[    0.700605] pnp 00:09: disabling [mem 0x000d0000-0x000d3fff] because it overlaps 0000:00:02.0 BAR 6 [mem 0x000c0000-0x000dffff]
[    0.700608] pnp 00:09: disabling [mem 0x000d8000-0x000dbfff] because it overlaps 0000:00:02.0 BAR 6 [mem 0x000c0000-0x000dffff]
[    0.847790] hpet_acpi_add: no address or irqs in _CRS
[    0.881477] ENERGY_PERF_BIAS: Set to 'normal', was 'performance'
[    3.262763] booting system configuration /nix/store/rh1r691mrs6v1hzrz7vdiwr7jscr6965-nixos-system-nixos-25.05.806427.32a4e8794210
[    4.637919] resource: resource sanity check: requesting [mem 0x00000000fed10000-0x00000000fed15fff], which spans more than pnp 00:06 [mem 0xfed10000-0xfed13fff]
[    4.637923] caller snb_uncore_imc_init_box+0x86/0xe0 [intel_uncore] mapping multiple BARs
[    4.944104] i801_smbus 0000:00:1f.4: SMBus is busy, can't use it!
[    5.125487] iwlwifi 0000:00:14.3: WRT: Overriding region id 0
[    5.125492] iwlwifi 0000:00:14.3: WRT: Overriding region id 1
[    5.125494] iwlwifi 0000:00:14.3: WRT: Overriding region id 2
[    5.125496] iwlwifi 0000:00:14.3: WRT: Overriding region id 3
[    5.125498] iwlwifi 0000:00:14.3: WRT: Overriding region id 4
[    5.125500] iwlwifi 0000:00:14.3: WRT: Overriding region id 6
[    5.125502] iwlwifi 0000:00:14.3: WRT: Overriding region id 8
[    5.125504] iwlwifi 0000:00:14.3: WRT: Overriding region id 9
[    5.125506] iwlwifi 0000:00:14.3: WRT: Overriding region id 10
[    5.125508] iwlwifi 0000:00:14.3: WRT: Overriding region id 11
[    5.125510] iwlwifi 0000:00:14.3: WRT: Overriding region id 15
[    5.125512] iwlwifi 0000:00:14.3: WRT: Overriding region id 16
[    5.125514] iwlwifi 0000:00:14.3: WRT: Overriding region id 18
[    5.125516] iwlwifi 0000:00:14.3: WRT: Overriding region id 19
[    5.125518] iwlwifi 0000:00:14.3: WRT: Overriding region id 20
[    5.125519] iwlwifi 0000:00:14.3: WRT: Overriding region id 21
[    5.125522] iwlwifi 0000:00:14.3: WRT: Overriding region id 28
[    5.223140] spi-nor spi0.0: supply vcc not found, using dummy regulator
[    5.781228] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: Parent card not yet available, widget card binding deferred
[    6.890891] Bluetooth: hci0: HCI LE Coded PHY feature bit is set, but its usage is not supported.
[    7.941680] nvme nvme0: using unchecked data buffer
[   51.874573] intel_pch_thermal 0000:00:12.0: CPU-PCH current temp [58C] higher than the threshold temp [50C], S0ix might fail. Start cooling...
[   60.615650] intel_pch_thermal 0000:00:12.0: Wakeup event detected, abort cooling
[  153.163522] intel_pch_thermal 0000:00:12.0: CPU-PCH current temp [50C] higher than the threshold temp [50C], S0ix might fail. Start cooling...
[ 2611.805595] warning: `ThreadPoolForeg' uses wireless extensions which will stop working for Wi-Fi 7 hardware; use nl80211

Where the error is just:

[    4.944104] i801_smbus 0000:00:1f.4: SMBus is busy, can't use it!

If you can help me also to understand how to diagnose and solve these problems it would be really nice, thanks in advance. --- I also tried to blacklisted the i2c_i801 module and the error doesn't appear anymore but the lag of the touchpad still persist. --- After three days of work I realize that maybe the problem of SMBus has nothing to do with the touchpad. And the problem with the touchpad is another one but I really cannot solve it. I can show you the journalctl -p 3 results:

lug 22 19:11:28 nixos kernel: i801_smbus 0000:00:1f.4: SMBus is busy, can't use it!
lug 22 19:13:17 nixos kwin_wayland: kwin_libinput: Libinput: event12 - SYNA8005:00 06CB:CD8C Touchpad: kernel bug: Touch jump detected and discarded.
                                          See https://wayland.freedesktop.org/libinput/doc/1.27.1/touchpad-jumping-cursors.html  for details
lug 22 19:13:25 nixos kwin_wayland: kwin_libinput: Libinput: event12 - SYNA8005:00 06CB:CD8C Touchpad: kernel bug: Touch jump detected and discarded.
                                          See https://wayland.freedesktop.org/libinput/doc/1.27.1/touchpad-jumping-cursors.html  for details
lug 22 19:13:26 nixos kwin_wayland: kwin_libinput: Libinput: event12 - SYNA8005:00 06CB:CD8C Touchpad: kernel bug: Touch jump detected and discarded.
                                          See https://wayland.freedesktop.org/libinput/doc/1.27.1/touchpad-jumping-cursors.html  for details
lug 22 19:15:44 nixos kwin_wayland: kwin_libinput: Libinput: event12 - SYNA8005:00 06CB:CD8C Touchpad: kernel bug: Touch jump detected and discarded.
                                          See https://wayland.freedesktop.org/libinput/doc/1.27.1/touchpad-jumping-cursors.html  for details
lug 22 19:17:01 nixos kwin_wayland: kwin_libinput: Libinput: event12 - SYNA8005:00 06CB:CD8C Touchpad: kernel bug: Touch jump detected and discarded.
                                          See https://wayland.freedesktop.org/libinput/doc/1.27.1/touchpad-jumping-cursors.html  for details
lug 22 19:17:01 nixos kwin_wayland: kwin_libinput: Libinput: event12 - SYNA8005:00 06CB:CD8C Touchpad: WARNING: log rate limit exceeded (5 msgs per 24h). Discarding future messages.

So, there is this problem with libinput that maybe makes the touchpad lagging. Please help me :(.

I am having a conflict with third party moxa driver mxupcie and the default linux 8250_moxa which is compiled in. I have been following [this](https://unix.stackexchange.com/questions/276392/how-to-block-drivers-built-into-kernel-i-e-drivers-who-are-not-a-module) thread but still having issues. -bash-4.2$ lspci -vvv -s8a:00.0 8a:00.0 Serial controller: Moxa Technologies Co Ltd CP-118EL-A (8-port RS-232/422/485 PCI Express Serial Board) (prog-if 02 ) Subsystem: Moxa Technologies Co Ltd CP-118EL-A (8-port RS-232/422/485 PCI Express Serial Board) Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel modules: 8250_moxa, mxupcie There are quite a few symbols containing 8250 but looking through the source it appears that serial8250_init is the __init function for multiple serial drivers. I added the initcall_blacklist entry to my kernel parameters using the command below and rebooted but I am still seeing the same thing. grubby --update-kernel=ALL --args="initcall_blacklist=serial8250_init" After reboot I still see the same behavior -bash-4.2$ cat /proc/cmdline BOOT_IMAGE=/vmlinuz-4.9.220-rt143-RedHawk-7.5.5-trace root=/dev/mapper/vg00-root ro crashkernel=auto rd.md.uuid=2bc7cf35:ce34a47b:9688d2a0:1c0ea085 rd.lvm.lv=vg00/root rd.lvm.lv=vg00/swap rhgb quiet initcall_blacklist=serial8250_init I initially assumed that I chose the wrong __init function, which I guess I still might have, but looking at the System.map I can see that the symbol is still there, which I don't believe it should be. -bash-4.2$ cat /boot/System.map-uname -r |grep serial8250_init ffffffff813d81e0 T serial8250_init_port ffffffff81a0bc70 r __ksymtab_serial8250_init_port ffffffff81a288db r __kstrtab_serial8250_init_port ffffffff8202a6d2 t serial8250_init ffffffff820d4a20 t __initcall_serial8250_init6 I've never done this before, so I assume I am missing a step. What else do I need to do?

I'm trying to add a kernel option "xxx" by adding it to the existing GRUB_CMDLINE_LINUX="xxxx crashkernel=auto rhgb quiet" line in /etc/default/grub, but after doing so, when I run grub2-mkconfig –o /boot/grub2/grub.cfg it produces exactly the same grub.cfg file as before (confirmed with diff). What am I missing? I'm running CentOS Linux release 7.6.1810 (Core)

I am working on an embedded Linux (kernel-5.10.24), and I enabled the early_printk in kernel configuration to help my debugging kernel. Normally, the kernel command line has set console=ttyS0,115200 ...., and I can see the early printk logs in kernel. But today, I changed the command line to console=ttyS1,115200 .... by mistake, and I assumed I would NOT see any kernel logs during kernel bootup. And to my surprise, I can still see the first part of kernel log done by early printk, there is NO other logs afterwards. So my question is how early printk output kernel logs to the right console, even the console= is set to a non-existing device (or wrong serial console) ?

Similar question was asked here . I have a SATA disk connected to a SAS2308 HBA and there is backplane. Is there any way i can make the linux system ignore the disk at boot.

# lsscsi -v

[0:0:3:0]    disk    ATA      WDC WD10EFRX-68J 1A01  /dev/sda 
  dir: /sys/bus/scsi/devices/0:0:3:0  [/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:09.0/0000:04:00.0/host0/port-0:3/end_device-0:3/target0:0:3/0:0:3:0]

The HBA is this,

# lspci -nn -v -s 04:00.0
04:00.0 Serial Attached SCSI controller : Broadcom / LSI SAS2308 PCI-Express Fusion-MPT SAS-2 [1000:0087] (rev 05)
        Subsystem: Hewlett Packard Enterprise H220i [1590:0041]
        Flags: bus master, fast devsel, latency 0, IRQ 17
        I/O ports at c000 [size=256]
        Memory at dd540000 (64-bit, non-prefetchable) [size=64K]
        Memory at dd500000 (64-bit, non-prefetchable) [size=256K]
        Expansion ROM at dd400000 [disabled] [size=1M]
        Capabilities:  Power Management version 3
        Capabilities:  Express Endpoint, IntMsgNum 0
        Capabilities: [d0] Vital Product Data
        Capabilities: [a8] MSI: Enable- Count=1/1 Maskable- 64bit+
        Capabilities: [c0] MSI-X: Enable+ Count=16 Masked-
        Capabilities:  Advanced Error Reporting
        Capabilities: [1e0] Secondary PCI Express
        Capabilities: [1c0] Power Budgeting 
        Capabilities:  Dynamic Power Allocation 
        Capabilities:  Alternative Routing-ID Interpretation (ARI)
        Kernel driver in use: mpt3sas
        Kernel modules: mpt3sas

The error in dmesg is like so,

[  235.126718] mpt2sas_cm0: log_info(0x31110d00): originator(PL), code(0x11), sub_code(0x0d00)
[  235.126738] sd 0:0:3:0: [sda] tag#4233 FAILED Result: hostbyte=DID_SOFT_ERROR driverbyte=DRIVER_OK cmd_age=3s
[  235.126751] sd 0:0:3:0: [sda] tag#4233 CDB: Read(10) 28 00 00 44 d0 00 00 00 08 00
[  235.126757] I/O error, dev sda, sector 4509696 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 2
[  235.126787] sd 0:0:3:0: [sda] tag#4227 FAILED Result: hostbyte=DID_SOFT_ERROR driverbyte=DRIVER_OK cmd_age=3s
[  235.129288] sd 0:0:3:0: [sda] tag#4227 CDB: Read(10) 28 00 1c 6d 3a 00 00 00 08 00
[  235.129293] I/O error, dev sda, sector 476920320 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 2
[  235.474711] sd 0:0:3:0: Power-on or device reset occurred
[  238.716033] mpt2sas_cm0: log_info(0x31110d00): originator(PL), code(0x11), sub_code(0x0d00)

First off, this question is not a duplicate of https://unix.stackexchange.com/q/543219/126755 because instead of asking what is causing this kernel warning, I directly ask how to solve it, or do some work-around. In something about a straight hour of writing and then reading from/to my **newly connected USB disk device** Crucial P3 PCIe 3.0 x4 NVMe M.2 2280 SSD of size 4TB with model number CT4000P3SSD8, which I have put inside an AXAGON EEM2-SG2 SuperSpeed+ USB-C M.2 disk enclosure , and connected it to a **Thunderbolt 3 ** USB-C connector in my oldish Dell Inspiron 15 Gaming 7577 laptop. I immediatelly noticed such **BadDLLP warnings (Correctable PCIe Bus Error)** as this one (the time was removed for short):

kernel: pcieport 0000:00:1c.0: AER: Correctable error message received from 0000:02:00.0
kernel: pcieport 0000:02:00.0: PCIe Bus Error: severity=Correctable, type=Data Link Layer, (Receiver ID)
kernel: pcieport 0000:02:00.0:   device [8086:15da] error status/mask=00000080/00002000
kernel: pcieport 0000:02:00.0:    [ 7] BadDLLP

In just about an hour, kernel generated almost 300,000 of these warnings/correctable errors:

# journalctl --boot -1 --no-pager --no-hostname | grep BadDLLP | wc --lines

292727

Is there anything I can do *with relative safey* to mitigate these warnings/correctable errors? *** OS: Linux Mint 22 (wilma) with kernel version 6.8.0-51-generic.

### Question In GRUB one can use the [cryptomount](https://www.gnu.org/software/grub/manual/grub/grub.html#cryptomount) command to mount a LUKS partition. Is there a way to pass this decrypted partition to linux such that it appears as a device mapper (/dev/mapper/xxx) entry without having to run [cryptsetup luksOpen](https://man7.org/linux/man-pages/man8/cryptsetup-open.8.html) ? If it's not possible with GRUB, are there other bootloaders that support this? ### Notes Some distributions support [cryptdevice/cryptkey](https://wiki.archlinux.org/title/Dm-crypt/System_configuration#Using_encrypt_hook) parameters, however this [doesn't appear to be a standard linux kernel parameter](https://www.kernel.org/doc/html/latest/search.html?q=cryptdevice) (and isn't supported by the distribution I use). There is also the [dm-mod.create](https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/dm-init.html) kernel parameter but it appears that it only supports cleartext passphrase (viewable from /proc/cmdline) or use a linux keyring entry. Both of these methods would need to decrypt the partition again in order for linux to mount it though, right? Or else why would they need the key?

I have a pair of CentOS 7 servers (7.9.2009) with 8 physical CPUs each. Out of those, I'm trying to isolate cores 4-8 (so 3-7 as the OS sees them). I added the tag isolcpus=3-7 to /etc/default/grub after the GRUB_CMDLINE_LINUX parameter, ran grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg to generate a new configuration file and rebooted. Both servers respected the setting, as seen in /sys/devices/system/cpu/isolated - it shows cores 3-7 as I specified. However, on *one* of the servers, only one of the supposedly cores has system processes running on it (systemd,lvmetad and such) - despite several restarts, the OS does not seem to respect the core isolation in practice. I use the numactl command to see which cores are isolated as well, and output does differ between the servers (command is numactl -s | grep physcpubind: Server 1 (respects isolation): physcpubind: 0 1 2 3 Server 2 (does not respect isolation): physcpubind: 4 5 6 7 I'm quite lost as to what could be causing this and how to resolve this - any tips would be greatly appreciated. Thank you!

I'm trying to redirect the console to ttyUSB0, with the idea of later disable tty1, but I'm not getting anywhere.... I've added

GRUB_CMDLINE_LINUX="console=tty1 console=ttyUSB0,19200n8r"

To /etc/default/grub and ran update-grub, confirms it work from looking at /proc/cmdline. But nothing appears on the console, and /proc/consoles only includes:

tty1                 -WU (EC p  )    4:1

Note that if I'm able to run agetty -t10 -8 -h ttyUSB0 19200 and it works fine, I can log in from the other end (with GTKTerm). I've also added to /etc/initramfs-tools/modules (and ran update-initramfs -u)

usbserial
ftdi_sio

Thinking that the USB device is loaded too late, but that made no difference. Any idea? Anybody managed to get this working? Thanks.

According to the documenation of the kernel parameters kexec_load_disabled , > This value defaults to 0 (false: kexec_load enabled), but can be set > to 1 (true: kexec_load disabled). Once true, kexec can no longer be > used, and the toggle cannot be set back to false. What this documentation says is that if this parameter is set to true, i.e. 1, then once the kernel is loaded it cannot be unloaded at runtime and a new kernel loaded in its place. So if kernel 6.10.13 is installed on the machine with the kernel parameter kexec_load_disabled set to 1, will it impact the upgrade of the kernel to ver 6.11.2? Will it prevent it even after a reboot? Also this parameter if set to true does not prevent entries being manipulated in the boot loader like GRUB. So in GRUB an entry can be made to load some other kernel version. Is my understanding correct?

When I add the "**badram**" pattern that **64bit Memtest86+** v6.10/v6.20 gave me, **GRUB 2** hangs completely on boot. Q: * Why is the badram pattern address different from the "Error Address" displayed (0x0ac... vs 0x62c...)? What is the reason for this apparent offset? * Why does GRUB hang on passing a 64bit badram pattern? ---- This is my GRUB...

# grub-mkimage --version
grub-mkimage (GRUB) 2.06-3~deb11u5

sleeping on the job... Beyond the "**Welcome to GRUB!**" message, nothing. No reboot, no reaction to key inputs, no rescue shell. System completely "*bricked*" - I had to build a rescue USB UEFI boot stick to to recover from this. (Btw, no secure-boot hardware, no signed grub install, so no excuse.) Anyway. I don't have too much knowledge about system memory and really can't tell much from Memtests' hex numbers. But I don't think I can just trim the leading zeros and pass these like 32-bit numbers to GRUB, or can I? ...Some person on reddit seems to have done just that , but, like me, couldn't afterwards verify if those numbers actually worked as expected, and masked out the correct memory regions. Why might GRUB crap itself on this? Is this a bad mem region to mask? Is the region too small, should it be a certain size (like 4K page size) or alignment? Is GRUB badram just broken, perhaps? Or is the hardware? (I don't think so, but you never know with these ACPI tables, right?) In any case, I dug up quite a few instances of other people reporting the same problem with GRUB + 64bit addresses (clearly my GRUB is not the only lazy worker out there): > Upon issuing this command (either via grub.cfg or interactively on the command line) my system hangs and becomes unresponsive. > badram 0x000000008c4e0800,0xffffffffffffcfe0 (They got no response from GRUB devs ) > GRUB_BADRAM="0x00000000b3a9feec,0xfffffffffffffffc" > > And after that change, I don't even get to Grub boot screen. When it's supposed to show up, computer just hangs and shows the black screen. (They didn't manage to fix it, either ) > I did all that, but the Computer that is perfectly fine and has no errors refused to boot after that GRUB_BADRAM= line addition. it never boots and gives no menu at al. (The GRUB badram argument failed on two different computers for them ...) ... I can't tell if there might be any relation between these patterns that make them bad, or if GRUB badram just plain doesn't work with 64bit addresses, since I couldn't find any *positive* "works for me" reports. (Those all boiled down to people using Linux memmap= format or Linux memtest= kernel parameters, instead.) Finally, I found one more person who seems to have had success with badram... using 32bit address notations (on a 64bit machine) ? So I'm going to try that next.

I'm trying to understand the “memmap” parameter from the Linux kernel (see The kernel’s command-line parameters ), in particular, the following options: memmap=nn[KMG]$ss[KMG] [KNL,ACPI] Mark specific memory as reserved. Region of memory to be reserved is from ss to ss+nn. Example: Exclude memory from 0x18690000-0x1869ffff memmap=64K$0x18690000 or memmap=0x10000$0x18690000 Some bootloaders may need an escape character before '$', like Grub2, otherwise '$' and the following number will be eaten. memmap=nn[KMG]!ss[KMG] [KNL,X86] Mark specific memory as protected. Region of memory to be used, from ss to ss+nn. The memory region may be marked as e820 type 12 (0xc) and is NVDIMM or ADR memory. As per the documentation, I fail to grasp the differences of those options or the ultimate goals. While question https://unix.stackexchange.com/questions/746114/linux-kernel-difference-between-protected-and-reserved-memory-memmap-parameter states the differences, I still do not understand the output of top and dmesg generate with different memmap options as detailed below. I'm using Ubuntu 24.04 through QEMU to experiment with the options and see the effects. The QEMU is running an x86_64 with 2 GB of memory and 1 hotplug memory stick (the one used to play with the parameters). This is the command line to launch the guest: ./qemu-system-x86_64 -M pc -m 2G,slots=4,maxmem=16G -object memory-backend-file,size=1G,id=mem0,mem-path=./test_ram -device pc-dimm,memdev=mem0,id=dimm0 -drive file=ubuntu_24.04.raw,format=raw -net nic -net user -nographic -serial mon:stdio **No memmap set:** # cat /proc/cmdline BOOT_IMAGE=/vmlinuz-6.8.0-31-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro console=ttyS0 nokaslr Top reports: GiB Mem : 2.9 total, 2.5 free, 0.4 used, 0.2 buff/cache GiB Swap: 1.6 total, 1.6 free, 0.0 used. 2.5 avail Mem **Memmap set to 1G$2G** # cat /proc/cmdline BOOT_IMAGE=/vmlinuz-6.8.0-31-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro console=ttyS0 nokaslr memmap=1G$2G Top reports: GiB Mem : 2.9 total, 2.5 free, 0.4 used, 0.2 buff/cache GiB Swap: 1.6 total, 1.6 free, 0.0 used. 2.5 avail Mem **Memmap set to 1G!2G**: # cat /proc/cmdline BOOT_IMAGE=/vmlinuz-6.8.0-31-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro console=ttyS0 nokaslr memmap=1G\\!2G Top reports: GiB Mem : 1.9 total, 1.6 free, 0.4 used, 0.2 buff/cache GiB Swap: 1.6 total, 1.6 free, 0.0 used. 1.5 avail Mem dmesg for all three options: [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable [ 0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000007ffdffff] usable [ 0.000000] BIOS-e820: [mem 0x000000007ffe0000-0x000000007fffffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved [ 0.000000] BIOS-e820: [mem 0x000000fd00000000-0x000000ffffffffff] reserved Seeing this, multiple questions: 1. Why is the physical RAM map the same for all of them? 2. The usable RAM is from 0x100000 to 0x7ffdffff, which is roughly 2 GB.  Where does this number come from?  Why not from 0x100000 to 0x80100000 (exactly 2 GB)? 3. Why for option "Memmap set to 1G$2G" does Linux top report almost 3 GB of memory?  We reserved 1 GB. 4. For options "Memmap set to 1G$2G" and "Memmap set to 1G!2G", where exactly in the physical RAM map is the 1 G reserved? 5. Why would I want to use the "$" option over the "!" option for memmap?

I am wanted to build a custom kernel image in which macro CONFIG_BLK_CGROUP is not defined. After researching a little bit I found we can do such configurations in .config file. To be more precise I am building custom kernel image in CentOS8-Stream and the only documentation available is at https://wiki.centos.org/HowTos(2f)Custom_Kernel.html Following the documentation as mentioned in above link I started building custom kernel kernel-4.18.0-448.el8.src.rpm. In step 2 configuring the kernel I copied the config to root kernel source tree as:

# cp configs/kernel-4.18.0-uname -m.config .config

Then did: # make oldconfig Then edited the config and unset CONFIG_BLK_CGROUP using menuconfig: # make menuconfig CONFIG_BLK_CGROUP setting is available in menuconfig under: General setup -> Control Group support -> IO controller as I found by searching for CONFIG_BLK_CGROUP in menuconfig UI. I changed the check box from [*] to empty [ ] and saved the changes. Then when I verified the file .config I could see line: # CONFIG_BLK_CGROUP is not set in .config file. Then followed the rest steps and issued the build as below:

# rpmbuild -bb --without debug --target=uname -m kernel.spec 2> build-err.log | tee build-out.log

Now what I notice after build is that, 1. the file include/generated/autoconf.h still has line #define CONFIG_BLK_CGROUP 1 2. Even after installing the custom kernel and re-booting into it I could see CONFIG_BLK_CGROUP=y in config file under /boot/config Then later I also tried multiple attempts to do the steps as mentioned in CentOS guide again but in a little different way like by changing all the config files under configs dir manually by updating CONFIG_BLK_CGROUP=y to # CONFIG_BLK_CGROUP is not set on step 2 after doing make menuconfig Then just followed next steps as in guide still no luck I still line #define CONFIG_BLK_CGROUP 1 in autoconf.h. Any insights on this, need a way such that my kernel compiles without defining CONFIG_BLK_CGROUP. Basically I don't want the linux kernel source code falling under #ifdef CONFIG_BLK_CGROUP to be executed.

I tried to turn off the tcp timestamp but it didn't work. The step i performed are the following: $ sysctl -w net.ipv4.tcp_timestamps=0 $ sysctl -p $ sysctl net.ipv4.tcp_timestamps (=> to be sure that it has been set to 0) $ hping3 www.google.com -S -c 1 -p 443 --tcp-timestamp and i obtained: TCP timestamp: tcpts=2513557362 I also tried to sniff the traffic through wireshark and i saw that every tcp packet contains the value in the timestamps field. I'm using Linux Debian 4.9.13. What I'm doing wrong?

Both files are being used to pass parameters to the kernel. so what exacly is the difference between the two? What is the purpose of each file?

I want to reinstall my VPS with the debian's official repository, instead of with the image provided by the VPS operator(I don't trust the VPS operator). On original system I installed debian-installer by apt install debian-installer debian-installer-12-netboot-amd64, and taked the kernel that comes with debian-installer as a new grub booting entry. When I reboot the VPS, it can automatically begin a fresh installing session, just like boot from a USB stick, so I can erase everything that offered by the operator. Now I want to do more perfectly, i.e. to boot with expert install mode of the debian installer. I guess the only way I can control the booting process of the installer's kernel, is to offer some kernel parameters in grub entry. But I don't know what parameter I should specify, because these are **NOT** common kernel parameters those we can refer to the standard Linux docs. What name and value of kernel parameters, can make the debian installer to boot into exert mode? Or Where to find docs of this? Thanks!