Kernel patch needed for Dell Precision 5520

Hey everybody,

Well, that last update was so bad for me that now my work machine is running openSUSE Tumbleweed. Let me recap:

A month ago, my company gave me a new laptop on which I attempted to install Manjaro, which resulted in this thread, which ultimately resulted in this thread. At the time, I was able to use the Manjaro-Architect installer to get Manjaro installed without MHWD trying to do anything automatic.

After the install, I installed but disabled bumblebee and bbswitch and the nonfree nvidia drivers. Why? If I enabled bumblebee at boot, the system would lock. If, however, I let X load and then started bumblebee, everything was fine. Nouveau would lock the machine, so that was not an option.

After the last stable update, I had no working X configuration. It would just exit. I spent 2 hours trying and failing to figure out why X was dead. I removed the modesetting driver configuration, but then X would just exit automatically. I had none of the problems people posted about–my update had gone smoothly and everything installed that needed to be installed.

Because this is my work machine, I determined 2 hours of work time lost was enough to attempt a reinstall. On another machine, I downloaded the 17.0.1 ISO, but it has the same problems the earlier one did: it never made it to X because of MHWD. I then attempted the Manjaro-Architect installer, but now when it’s installing its base config it also installs MHWD and the Nouveau driver, which locks the machine.

After that, I tried the Arch Anywhere installer, and it does the same thing: it tries to load Nouveau and locks the machine. Not wanting to go through a full-blown Arch install and have it fail on X again, I started doing research, and I found this:

http://ubuntu.5.x6.nabble.com/PATCH-xenial-ACPI-blacklist-fix-Dell-Precision-5520-amp-3520-freeze-td5145981.html

Presumably, this is the patch Dell uses to support Linux on this machine. Being a KDE guy, I didn’t want to install Ubuntu (or Kubuntu; been down that road), so I tried openSUSE, which I know tracks hardware closely. Everything, including Bumblebee running at boot, works flawlessly as it does on any other system, so I can only assume they have also integrated this patch.

I am guessing at this point that Arch-based distros simply don’t have this patch in their kernels. I know Manjaro produces its own kernels. Would it be possible to integrate this patch into the Manjaro kernel?

Here’s the hardware I’m working with. Unfortunately, since this is my work machine, I can’t simply reinstall a bunch of times; I have to be able to get work done. :slight_smile:

System:    Host: enterprise Kernel: 4.10.5-1-default x86_64 (64 bit) Desktop: KDE Plasma 5.9.4
       Distro: openSUSE Tumbleweed
Machine:   Device: laptop System: Dell product: Precision 5520
       Mobo: Dell model: 06X96V v: A00 UEFI: Dell v: 1.1.3 date: 01/18/2017
Battery    BAT0: charge: 85.1 Wh 110.9% condition: 76.7/85.1 Wh (90%)
CPU:       Quad core Intel Xeon E3-1505M v6 (-HT-MCP-) cache: 8192 KB 
       clock speeds: max: 4000 MHz 1: 799 MHz 2: 799 MHz 3: 799 MHz 4: 799 MHz 5: 799 MHz 6: 799 MHz
       7: 799 MHz 8: 799 MHz
Graphics:  Card-1: Intel Device 591d
       Card-2: NVIDIA GM107GLM [Quadro M1200 Mobile]
       Display Server: X.org 1.19.3 drivers: modesetting (unloaded: fbdev,vesa) Resolution: 120x33
Audio:     Card Intel Device a171 driver: snd_hda_intel Sound: ALSA v: k4.10.5-1-default
Network:   Card: Intel Wireless 8265 / 8275 driver: iwlwifi
       IF: wlp2s0 state: up mac: 00:28:f8:24:96:f4
Drives:    HDD Total Size: NA (-)
       ID-1: /dev/nvme0n1 model: N/A size: 1024.2GB
Partition: ID-1: / size: 98G used: 9.3G (10%) fs: ext4 dev: /dev/nvme0n1p2
       ID-2: /home size: 792G used: 330G (44%) fs: ext4 dev: /dev/nvme0n1p5
       ID-3: swap-1 size: 34.36GB used: 0.00GB (0%) fs: swap dev: /dev/nvme0n1p3
Sensors:   None detected - is lm-sensors installed and configured?
Info:      Processes: 290 Uptime: 5:47 Memory: 5704.0/31899.1MB Init: systemd runlevel: 5
       Client: Shell (bash) inxi: 2.3.8 

Thanks!

1 Like

in the link you posted they said the patches have been taken from main kernel and backported to ubuntu.

Okay, well, then I’m stumped. The problem is consistent on Arch-based distros, at least with the three installers I tried (Manjaro Plasma 5 ISO, Manjaro-Architect, Arch Anywhere).

Looking at my current X configuration on openSUSE, it has no configuration. The config files are blank or all commented out. Bumblebee is running. Discrete card is off:

 $ cat /proc/acpi/bbswitch
0000:01:00.0 OFF

Nouveau is blacklisted according to openSUSE’s instructions here.

If there’s any other information I can supply, please let me know. I would love to get this machine back on Manjaro.

Thanks!

I got some problem on my old macbook pro mid 2010, because it’s impossible to install nvidia drivers. and the nouveau drivers needed to be loaded early then needed to be put in mkinitcpio…
the only way I found at that time to boot manjaro live. was to use vesa drivers. (then I got no X and started it manualy to have the default x desktop) installed the system. and made all the necessary change in the installed system manualy in chroot (unistall hybrid drivers, installed nouveau etc. etc).

mhwd put some config files. you can try to remove them and black list nouveau etc from the live cd you use to install before to reboot (manjaro-architect or the one you can use)

after I’m really not an expert at all in the graphic stack on linux.
there is other members with much more knowlage than me.

The patch is part of v4.9.17. Please try Manjaro v17.0.1 as install media.

1 Like

@philm tried it already. It hangs at the MHWD LiveMedia script. It also hangs if I add the systemd mask kernel parameter.

Then some is off with the hardware detection. Did you try to add the kernel cmd xdriver=vesa yet?

According to the bottom post in this thread that parameter is ineffective if you’re using UEFI (which I am). Instead, you’re supposed to use systemd.mask=mhwd-live.service, which stopped the MHWD LiveMedia script from hanging, but then the machine locked when trying to load X. Interestingly, this didn’t happen on the regular v17.0 ISO. On that one, I can start the install with Calameres, but then it hangs later in the install when it runs MHWD to configure the hardware.

I don’t know exactly all what mhwdcfg do in the installation process…
maybe @phil can say if it’s safe to remove it from calamares conf file.
(but you may need to do you adjustement in the installation system, install nouveau, etc)

openSUSE uses fbdev instead of vesa from memory, it will then switch to nouveau/nvidia after initial boot with fbdev iirc. Manjaro doesn’t provide that by default(you can download the package xf86-video-fbdev with pacman, but it requires some manual config to use iirc). You can disable the mhwd script from running with the mask param and also try add a 3 at the very end of the kernel params line by itself(separated by a space), this should boot into text mode only.

If that still doesn’t work then you can try disable nouveau with params nouveau.modeset=0 nouveau.blacklist=1 modprobe.blacklist=nouveau rd.driver.blacklist=nouveau, one of those should work, else can also try nomodeset.

Useful posts I’ve made on the topic: [1], [2], [3], [4], [5] (all posts from me on the same thread). [6] suggesting to use iGPU if available instead of nvidia gpu for install.

If you’re able to get a terminal working (alt+ctrl+f2 or the text boot described above with 3) then you should at least be able to get some log info about what’s going wrong when it does. In the links above I think describe useful commands to get relevant log info.

1 Like

Thank you, @kwhali! I am sort of desperate to make up for lost work time on this machine (my employer still expects my job to get done), so I may not be able to try these options until next week, but I definitely want to give them a try. I’ll report back on my results. Hopefully we can get this ironed out for future users who have these same hardware problems as indicated from the multiple threads on this topic (some of which you linked to, and some of which I did as well).

Thank you for your help!

@kwhali, @scachemaille, and @philm:

I am very happy to report success! Using all of the above kernel parameters, (:slight_smile:), I got Manjaro installed. The basic issue is, as expected, that this hardware really, really hates Nouveau.

My first attempt failed again at the MHWD config portion of the Calameres install. The system just locked up tight (no caps lock light). In my second attempt, I used the Manjaro-Architect ISO, but before I started the install I created an /etc/modprobe.d/blacklist-nouveau.conf file:

blacklist nouveau

I then ran through the install and even let it automatically set up the proprietary video drivers. Everything went flawlessly. I’m betting that if I had used the 17.0.1 ISO and had created the blacklist file, it would have gone equally flawlessly, but I’m not about to test it now. :slight_smile:

Interestingly enough, after the install, I made a change that required me to log out and back in again. When I logged out, the system locked up again hard. After shutting the system off and on again, I had to create a blacklist file for Nouveau on the installed system as well. It seems that various things (SDDM?) attempt to load that Nouveau module automatically.

It seems a shame that one buggy module causes so much pain and trouble for the Manjaro install routines. I’m not sure if there’s a way to make it more generic so that Nouveau never loads unless specifically requested, but I wanted to make sure you guys were informed about it at the very least.

In any case, I’m very happy to be back on Manjaro!

1 Like

had same problem with new XPS 15 9560 i7 FHD
used M-A (great tool for installation), at video selection I’ve used Intel, not Free or Non-Free
now is installed and running, some glitches to take care (ath10k) in AUR but not compiling, waiting for kernel 4.11…
most the things I need they work, no use of NVidia

seems not working with my hw
I can install bumblebee, is working, made also the blacklist-nouveau.conf, but if I log out it freeze in konsole, suspend works

with only intel installed log out and suspend worked fine

Agreed. I have the same problem. I guess I don’t have a lot of reason to log out and back in; I tend to just put the machine to sleep and reboot only on updates. With that said, after the update this morning I had trouble booting up my system. It would lock when trying to load X. After about the 7th time trying to boot, it finally showed SDDM. Not sure what’s going on.

bumblebee was not working after resuming from suspend
now I came back to Intel driver only but switched to unstable (I can use this machine for testing for sometime, my daily machine being a Precision M4800) kernel 4.11 made my wifi working
I may try again to install bumbleebee and see what will happen…

EDIT: there is not yet linux411-nividia in unstable

Yeah; I’m limping along on 4.10. For now, suspend with bumblebee works reliably when I can get the machine to boot into X. I did some experimenting yesterday with disabling Bumblebee, but I had the dreaded black screen when SDDM loaded. Ctrl-Alt-F2 got me to a console where I could look at the Xorg.0.log file, but it looked normal.

openSUSE Tumbleweed never gave me any of these problems, but I have no clue now as to whether it’s something they do to their kernel, something in their X config, or what. Manjaro/Arch with the AUR is so much more elegant that I have no desire to reinstall openSUSE, though: plus I have scripts that help me get going quickly on a new Manjaro/Arch system.

@philm saw this and checked the Manjaro kernel, and it’s also not compiled in. Is it possible to make this change, or is there some reason we don’t use it?

Okay; possibly more information here. Updated today, rebooted, had many lockups. Had to boot into runlevel 3, stop bumblebeed, start sddm, log in, then start bumblebeed to get X to load. Related to my post above asking @philm to enable the CONFIG_ACPI_REV_OVERRIDE_POSSIBLE option in the Manjaro kernel, I’ve been noticing these errors upon every boot up:

Since it’s an ACPI exception, that does seem to confirm there may be a problem with ACPI on this machine, and enabling that kernel parameter could help. I got a new kernel with this update, but the option still isn’t there:

zcat /proc/config.gz | grep CONFIG_ACPI_REV_OVERRIDE_POSSIBLE
# CONFIG_ACPI_REV_OVERRIDE_POSSIBLE is not set

I have built kernels before, but on other distros. I didn’t see anything in Manjaro’s wiki about it, and Arch’s wiki mentions a package called abs which isn’t available in Manjaro’s repositories. Can anybody help me with that, or @philm do you think you could enable this option in the official kernel in the next update?

Thanks!

Yeah I have Inspiron 7537 and battery is not detected. According to this https://bugzilla.kernel.org/show_bug.cgi?id=105721 when enabled battery is visible again. So please acticate that option in next release.


edit
fixed Kernel config request

Thanks