[SOLVED] My Dell D620 laptop hangs/freezes randomly on slackware64 14.2

abga · 11-01-2019, 04:27 PM

@Twigster

Before trying a new kernel, try what's suggested in post #48 first (if you haven't already).

If you're running the 64bit Slackware 14.2 now, then the correct folder for the 64bit -current kernel is:
https://mirror.de.leaseweb.net/slack...slackware64/a/

Code:

# create a working directory in /tmp
mkdir /tmp/work && cd /tmp/work
# then download the kernel and kernel modules packages, together with the associated asc files:
wget https://mirror.de.leaseweb.net/slackware/slackware64-current/slackware64/a/kernel-huge-4.19.81-x86_64-1.txz
wget https://mirror.de.leaseweb.net/slackware/slackware64-current/slackware64/a/kernel-huge-4.19.81-x86_64-1.txz.asc
wget https://mirror.de.leaseweb.net/slackware/slackware64-current/slackware64/a/kernel-modules-4.19.81-x86_64-1.txz
wget https://mirror.de.leaseweb.net/slackware/slackware64-current/slackware64/a/kernel-modules-4.19.81-x86_64-1.txz.asc
#then download and import the Slackware official GPG signature:
wget http://www.slackware.com/gpg-key -O slack-gpg-key
gpg --import slack-gpg-key
rm slack-gpg-key
#Now verify the integrity of the kernel-huge-4.19.81-x86_64-1.txz and kernel-modules-4.19.81-x86_64-1.txz packages:
gpg --verify kernel-huge-4.19.81-x86_64-1.txz.asc
gpg --verify kernel-modules-4.19.81-x86_64-1.txz.asc
# in the outputs you should see a line containing:
 Good signature from "Slackware Linux Project <security@slackware.com>"
# move (backup) the actual symlinks from /boot
mkdir /boot/back
mv /boot/System.map /boot/back
mv /boot/vmlinuz-huge /boot/back
# install the new kernel & modules packages from -current
installpkg kernel-huge-4.19.81-x86_64-1.txz
installpkg kernel-modules-4.19.81-x86_64-1.txz
# backup your actual /etc/lilo.conf file
cp /etc/lilo.conf /etc/lilo.conf.bak
# edit your /etc/lilo.conf file, point the original image to the old kernel (and not the symlink)
# Linux bootable partition config begins
image = /boot/vmlinuz-huge-4.4.190
root = /dev/sda1
label = Slack-Old
read-only
# create a new image section, pointing to the new kernel:
image = /boot/vmlinuz-huge-4.19.81
root = /dev/sda1
label = Slack-New
read-only
# then execute /sbin/lilo to update the boot loader
###################################################
# to clean up the mess, revert to original state
# remove the -current kernel & modules
removepkg kernel-huge-4.19.81-x86_64-1
removepkg kernel-modules-4.19.81-x86_64-1
# restore the original symlinks
mv /boot/back/System.map /boot/
mv /boot/back/vmlinuz-huge /boot/
rm -rf /boot/back/
# restore the original /etc/lilo.conf file
rm -f /etc/lilo.conf
mv /etc/lilo.conf.bak /etc/lilo.conf
# then execute /sbin/lilo to update the boot loader

Twigster · 11-02-2019, 10:23 AM

Thank you, those were very helpful instructions :>

I did as you said and unfortunately I was able to reproduce the hang

dmesg notifies me that with kernel 4.19.81, I have i915 1.6.0 20180719.

With the 4.4.190 kernel, dmesg says I have i915 1.6.0 20151010.

Therefore, I would assume that i915.ko is the same for both kernels, and only the build date differs.

I went to linus' github but was unable to find a tag, or a version number somewhere to figure out what changed in i915.

So at this point, my options look limited : throw the laptop, build a new i915.ko (to use with either 4.4.190 or 4.19.81), or build a 5.x kernel

abga · 11-02-2019, 12:32 PM

You can get the driver version info from the header file of the driver - given you have the source code.
This is for master:
https://github.com/torvalds/linux/bl...915/i915_drv.h
- first you get a section:

Code:

#define DRIVER_NAME		"i915"
#define DRIVER_DESC		"Intel Graphics"
#define DRIVER_DATE		"20190822"
#define DRIVER_TIMESTAMP	1566477988

-and the version info:

Code:

#define DRIVER_MAJOR		1
#define DRIVER_MINOR		6
#define DRIVER_PATCHLEVEL	0

For browsing the source files for the stable kernel releases, you can click on the [browse] link corresponding to the version you want to check:
https://www.kernel.org/

The i915 looks to be constantly updated, maybe you can catch something interesting related to your issue:
https://github.com/torvalds/linux/co...s/gpu/drm/i915

If you want to compile your own 5.x.x kernel, here you have a how-to:
https://www.linuxquestions.org/quest...8/#post6052734
I'd suggest to go for the stable 5.3.x (the latest is 5.3.8) and avoid the development version 5.4.
I could provide you with the kernel config file I used for building the kernel for the Atom Acer Aspire One, but you'll need to change the CPU type, enable 64 bit and also enable PCMCIA ... and remove an AcerPM driver. It's tailored for that system and my specific needs, plenty of DVB adapters enabled, almost the whole (advanced) networking stuff enabled, etc.
Note that if you follow the compilation instructions I presented, you won't build a package and with the last two make install commands:

Code:

make modules_install
make install

- you'll get the modules installed in /lib/modules/5.3.1/
- and the kernel vmlinuz & System.map in /boot
- to preserve the original vmlinuz & System.map symlinks, just follow the /boot/back section from post #76
- add the new compiled kernel vmlinuz (you could rename it in vmlinuz-5-3-x) in your /etc/lilo.conf in the way presented in post #76
------------------
- to clean up 5.3.x , remove vmlinuz & System.map from /boot, restore the originals from /boot/back and delete the /lib/modules/5.3.1/ folder
- update /etc/lilo.conf and remove the 5.3.x references

Good Luck!

abga · 11-02-2019, 12:45 PM

Forgot about this one:

Quote:

Therefore, I would assume that i915.ko is the same for both kernels, and only the build date differs.

It's not the same, always inspect the source code - diff between v4.19.81 & v4.4.190:
https://git.kernel.org/pub/scm/linux...1&id2=v4.4.190

Twigster · 11-02-2019, 01:09 PM

Alright I will process this tomorrow; Are you aware of any problems that might arise between a 5.3 kernel and slackware 14.2 (made for kernel 4.4)?

Quote:

It's not the same, always inspect the source code - diff between v4.19.81 & v4.4.190:
https://git.kernel.org/pub/scm/linux...1&id2=v4.4.190

Quite misleading then to have a version number with a patchlevel digit that does not change despite code changes

abga · 11-02-2019, 02:26 PM

There shouldn't be an issue running a newer kernel on Slackware 14.2
It's been some weeks now since I'm running the 5.3.1 on the Acer Atom notebook (which runs Slackware 14.2) and I'm planning to move the 5.3.1 kernel on all other systems I own (all of them running Slackware 14.2).
You should only use the kernel-headers package that is provided by Slackware (through updates), as those headers are important for the toolchain.

abga · 11-02-2019, 04:43 PM

Just checked, in one of your initial posts you provided some info about your CPU:
https://pastebin.com/jxxURSL5

Code:

model name  : Intel(R) Core(TM)2 CPU         T5500  @ 1.66GHz
microcode   : 0x57

That info was provided before the BIOS update (which usually contains also a microcode).
According to this link, your CPU ID/signature should be 06F2h
http://www.cpu-world.com/sspec/SL/SL9U4.html
If I'm about to take that ID as correct, there is a newer microcode available for your CPU:

Code:

 iucode_tool -L /lib/firmware/intel-ucode/06-0f-02
microcode bundle 1: /lib/firmware/intel-ucode/06-0f-02
  001/001: sig 0x000006f2, pf_mask 0x01, 2010-10-02, rev 0x005d, size 4096
  001/002: sig 0x000006f2, pf_mask 0x20, 2010-10-02, rev 0x005c, size 4096

You could try loading it (it's not persistent, needs to be loaded on every boot) by first compiling and installing:
http://www.slackbuilds.org/repositor...m/iucode_tool/
Then:
http://www.slackbuilds.org/repositor...tel-microcode/
Finally, use the early loading method, add to your /etc/lilo.conf, in the image section for the kernel you want to boot:

Code:

initrd=/boot/intel-ucode.cpio

Run lilo to update the boot loader and restart. After the next boot, to check the details about the microcode, run:

Code:

dmesg | grep micro

baumei · 11-03-2019, 07:52 AM

Hi Twigster,

I have one computer which is running Slackware 14.2, and the 4.19.68 kernel from Slackware-current (ASUS 1005HAB). Installing the foreign kernel was easy: I downloaded the set of 4.19.68 kernel packages, and ran 'upgradepkg' on the packages I wanted installed --- the next few steps depend upon whether one runs the huge kernel or the generic kernel.

(Many people will say that one should _not_ upgrade a kernel in the manner I do. However, I have been using this method for about two decades on a small flock of computers running 'Slackware-stable', and have been pleased with the results. In only one instance have I wanted to revert to the previous kernel, and this was when the 4.4.172 kernel brought the blank-screen video problem to the ASUS 1005HAB; after I downloaded a copy of the previous kernel, re-installing it was easy.)

During the time I have been running this ASUS 1005HAB it has had two video problems. The blank-screen problem was entirely fixed by installing kernels of the 4.19.x series. The other problem (which sounds like what your Dell D620 is doing) was not changed in any way that I can detect; as far as I can tell, this problem is related to one or more of: the i915 module, the Intel video 'card' [1], and the ACPI system.

1. So far, these Intel video cards are known to be associated with the problem: GMA 950, GMA 3100, GMA X3000.

abga · 11-03-2019, 02:01 PM

@Twigster

If you go for you own kernel compilation, there are some details to consider:
- just stumbled upon this gentoo wiki page containing a lot of useful info about the Intel driver (how to enable it & compile the kernel):
https://wiki.gentoo.org/wiki/Intel
- you should maybe inspect the .config files from the Slackware kernel (both 14.2 and - current) and check if the i915 options are enabled in the way presented by the gentoo wiki page
- the .config for -current is here:
https://mirror.de.leaseweb.net/slack...ernel-configs/
- and the .config for 14.2 is here:
https://mirror.de.leaseweb.net/slack...config-x86_64/
EDIT>
- for the latest Slackware 14.2 kernel (4.4.190) you should already have the config file in your /boot directory. You can also extract it from:
https://mirror.de.leaseweb.net/slack...linux-4.4.190/
- file:
kernel-huge-4.4.190-x86_64-1.txz
- containing:
boot\config-huge-4.4.190.x64
<EDIT

- this page is also rich in details about the GMA950
https://www.thinkwiki.org/wiki/Intel...ccelerator_950

- this is the official page where Intel develops the driver and all the necessary system components (stack). It appears that all the modifications they make are updated upstream (kernel.org)
https://01.org/linuxgraphics
- they do present their own Linux Kernel - 4.16. - looks dated 02 Apr 2018, downloaded it and ran " make defconfig", inspected the .config and CONFIG_DRM_I915 (+ other related options) looks enabled
https://01.org/linuxgraphics/downloa...s-stack-recipe

Twigster · 11-03-2019, 03:14 PM

@abga Could you explain why there seems to exist a 5c and a 5d microcode for the same cpu? Just for culture

Code:

~# dmesg | grep micro
[    0.000000] microcode: microcode updated early to revision 0x5c, date = 2010-10-02
[    0.694212] MDS: Vulnerable: Clear CPU buffers attempted, no microcode
[    1.252514] microcode: sig=0x6f2, pf=0x20, revision=0x5c
[    1.252679] microcode: Microcode Update Driver: v2.2.

@baumei : Thanks for the instructions. You could very well be right about the cause being i915 or ACPI related. I will report once I manage to use a 5.3 kernel (didn't have time today)

abga · 11-03-2019, 04:05 PM

Quote:

Originally Posted by Twigster

@abga Could you explain why there seems to exist a 5c and a 5d microcode for the same cpu? Just for culture

Code:

~# dmesg | grep micro
[    0.000000] microcode: microcode updated early to revision 0x5c, date = 2010-10-02
[    0.694212] MDS: Vulnerable: Clear CPU buffers attempted, no microcode
[    1.252514] microcode: sig=0x6f2, pf=0x20, revision=0x5c
[    1.252679] microcode: Microcode Update Driver: v2.2.

It appears that your CPU came in 2 "flavors" Merom and Merom-2M and I guess the "pf=" or "pf_mask" - processor flag, which is part of the CPU signature, is used to differentiate them.
https://en.wikipedia.org/wiki/List_o...ook_processors
https://en.wikipedia.org/wiki/Merom_...ssor)#Merom-2M

From the doc of the iucode-tool you're using now:
https://gitlab.com/iucode-tool/iucod...ngelog_Example

Quote:

There is no publicly available documentation on the processor flags.

Twigster · 11-04-2019, 08:34 AM

Ok, so if I understood correctly :
- i915 developments made on 01.org/linuxgraphics are available only through the intel graphics stack kernel or through kernel.org;
- despite i915 being a module, it needs to be built with the whole kernel (make modules_install)
- i915 version/patchlevel in i915_drv.h might not change even if i915 code evolves
- what is shown in linux/drivers/gpu/i915 is copied from the (private?)01.org/linuxgraphics repository where driver development happens and there is no other release made for the i915 driver
- some specific options detailed in the gentoo link are required to make i915 work properly when building from kernel.org

Sorry if I ask stupid things but I'm discovering all this

Quote:

you should maybe inspect the .config files from the Slackware kernel (both 14.2 and - current) and check if the i915 options are enabled in the way presented by the gentoo wiki page

We're told :

Quote:

Since kernel version 4.4 the driver has been moved and the legacy fbdev support is now CONFIG_DRM_FBDEV_EMULATION=y.

kernel 4.4.190 :

Code:

~# cat /boot/config-huge-4.4.190.x64 | grep FBDEV
CONFIG_DRM_FBDEV_EMULATION=y

4.19.81 :

Code:

~# cat /boot/config-huge-4.19.81.x64 | grep FBDEV
CONFIG_DRM_FBDEV_EMULATION=y
CONFIG_DRM_FBDEV_OVERALLOC=100
# CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM is not set

Edit : I can't find the "High memory support" option in make xconfig and make menuconfig : when I search for 'HIGHMEM' I do find an option, but it's not on the menu

enorbet · 11-04-2019, 11:57 AM

IIRC isn't there a "master option" that states something like "Show all Options"? I don't know if that is relevant here but it seems a good one to check off.

abga · 11-04-2019, 07:24 PM

Quote:

Originally Posted by Twigster

Ok, so if I understood correctly :
1. - i915 developments made on 01.org/linuxgraphics are available only through the intel graphics stack kernel or through kernel.org;
2. - despite i915 being a module, it needs to be built with the whole kernel (make modules_install)
3. - i915 version/patchlevel in i915_drv.h might not change even if i915 code evolves
4. - what is shown in linux/drivers/gpu/i915 is copied from the (private?)01.org/linuxgraphics repository where driver development happens and there is no other release made for the i915 driver
5. - some specific options detailed in the gentoo link are required to make i915 work properly when building from kernel.org

Sorry if I ask stupid things but I'm discovering all this

1. As far as I understood it, 01.org is the home of the Intel devs and all their developements are merged upstream into the kernel (kernel .org) Now, how this is done - through kernel commits - how actual the updates are - ask them...
https://unix.stackexchange.com/quest...rs-from-01-org
2. Yes, it's part of the kernel. You could change the code, update it yourself, without breaking it and only compile & install it. It's easier to get an updated kernel and build it together with the modules (incl. i915).
3. Again, address this with the kernel devs / 01.org devs (they should be the same)
4. Good question. I have no clue how actual the code from kernel.org is. At least at kernel.org you can see the commits and follow the code change on the i915 driver. 01.org has a github presence, but it doesn't look to contain anything related to the driver.
https://github.com/01org
Again, you should address this question with the kernel folks / 01.org folks.
5. Yes, the gentoo article is focusing on the upstream kernel.org code. I just provided you the link for the knowledge that is shared there. I also advised you to compare those instructions with the way the Slackware kernel is built, because there could be some differences. I don't say that the Slackware kernel isn't properly built, it works well for most of us, but there could be some differences that might resolve your issue. (I haven't got time to check it myself...)

Quote:

Originally Posted by Twigster

Edit : I can't find the "High memory support" option in make xconfig and make menuconfig : when I search for 'HIGHMEM' I do find an option, but it's not on the menu

I don't have the 4.19.81 kernel source available but looked into 5.3.1:
https://cateee.net/lkddb/web-lkddb/HIGHMEM.html

Code:

/linux-5.3.1# grep CONFIG_HIGHMEM .config
CONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not set
CONFIG_HIGHMEM=y

Twigster · 11-05-2019, 04:21 AM

Code:

:/usr/src/linux-5.3.8# make defconfig
*** Default configuration is based on 'x86_64_defconfig'
#
# No change to .config
#
/usr/src/linux-5.3.8# cat .config | grep HIGHMEM
/usr/src/linux-5.3.8#

@enorbet : you were right you can enable 'show all options', my bad. Now I can't click any of the High memory options

Code:

CONFIG_HIGHMEM4G:

Select this if you have a 32-bit processor and between 1 and 4
gigabytes of physical RAM.

Defined at arch/x86/Kconfig:1410

So maybe because make defconfig detected my x64 CPU it decided this setting was irrelevant?

EDIT : can I use the slackware 4.19 .config file as a basis for 5.3.8? I noticed that I had a ton more modules in /lib/modules/4* than I got with my 5.3.8 compile result, those are probably enabled in Slackware for a reason.

EDIT 2 : Would the option ACPI_HMAT help you diagnose my problem?

EDIT 3 : there is also the option CONFIG_CPU_FREQ. None of the configurators let me answer 'n' there, I wonder if I should try editing manually the .config to try without that?