Slackware64 and Ryzen

cwizardone · 11-28-2018, 08:47 AM

Quote:

Originally Posted by slackerDude

Just upgraded my GTX 950 to a GTX 960.

Then you shouldn't have any problems with the 4.19.x kernel and the most recent Nvidia drivers.

BTW, I always install the matching headers when installing a new kernel. Why would someone
not do this?

slackerDude · 11-28-2018, 09:24 AM

Thanks. I may wait until the ext4 issues with 4.19 get resolved - I use ext4 + SSD. Or just grab a 4.18.

As far as headers, I was trying to remember if I should or not. If I'm understanding this correctly: https://www.linuxquestions.org/quest...rs-4175615412/

(which is the one I read when I was trying to figure it out, IIRC), then you should NOT update headers until you update glibc. This is my dilemma - I'm getting conflicting answers. My memory says, always update headers when updating kernel. This page says no... So, are they confused too?

cwizardone · 11-28-2018, 09:32 AM

Just read that link, thank you, and that does confuse things, doesn't it.

I'll wait to hear, hopefully, from someone we know to be an expert.

BTW, I have not had any problems with 4.19.3/4/5 with -current and the latest Nvidia "Long lived" or "short lived" drivers.

bassmadrigal · 11-28-2018, 11:00 AM

Quote:

Originally Posted by cwizardone

BTW, I always install the matching headers when installing a new kernel. Why would someone
not do this?

Back in the 10.0 through 11.0 era, when Slackware came with the 2.4 kernel and had the 2.6 kernel available in testing/ there was this warning.

Code:

...As a general rule, installing kernel headers
that are newer than the kernel glibc was compiled with *may* cause problems,
so unless you need these for a particular reason it's best to stick with the
2.4.x kernel-headers package for now.

...

However, Pat always updates his kernel headers and hasn't run into issues.

I think upgrading headers has the slight possibility of issues, but it isn't very common. I think most compiling will use the headers in /usr/src/linux-$VERSION/ (which is strictly from the kernel source), but if you compile glibc, it uses /usr/include/, which is where the kernel-headers package places its files. But I'm certainly no authority on the matter.

That being said, I've done a mix of both. When I use pre-compiled kernel packages, I'll update kernel-headers, but when I build my own, the old ones stay in place. I've never run into any compatibility issues with either method. This included upgrading the headers when I ran the 2.6 kernel when Slackware was default with the 2.4.

cwizardone · 11-28-2018, 11:18 AM

@bassmadrigal,
Many thanks.
Greatly appreciated.

andrew.46 · 01-09-2019, 02:20 AM

Quote:

Originally Posted by Paulo2

About IOMMU and message

Code:

[    9.374585] AMD-Vi: Event logged [
[    9.374586] IO_PAGE_FAULT device=0e:00.0 domain=0x0003 address=0x000000f4001f48c0 flags=0x0010]

I had problems with that in my new machine FX-8320E/Gigabyte 970A-DS3P (not so 'new'

) I assembled in September last year.
Boot was stuck for ~20 seconds at those messages. I found the solution was adding iommu=soft at the append line in lilo.conf.
Also, there is an option in BIOS 'IOMMU Controller', it must be enabled.

Thanks, this solved my own issue perfectly!! Same motherboard but USB 3 working and USB 2 failed...

timsoft · 01-10-2019, 02:43 PM

I have a ryzen5 2400G as well, on an asus B350 board. (with 32g 2400mhz ram), a 1TB evo970 M.2 nvme ssd, 1TB SATA SSD, 2G SATA SSD and 8TB spinning drive. I'm running slackware 14.2 (64bit) but with 4.19.10 kernel (huge, modules, source, and 20181218 firmware) taken from current. I have root on the 1tb sata ssd to avoid having to run the "current" installer for the nvme drive, and am booting in legacy mode rather than uefi mode.

I have a peculiar problem in that although if I reboot the system, it reboots just fine, if I run

Code:

shutdown -h now

it appears to shutdown linux/slackware, but the pc (PSU) and cpu fan continues to run. I have to press the physical power button, or reset to start up, but it is concerning that shutdown doesn't work properly.
(I also have some issues with A8 9700 am4 cpus on asrock A320M-HDV boards as well, but that that is off the ryzen topic)

akimmet · 01-10-2019, 11:09 PM

Quote:

Originally Posted by timsoft

I have a ryzen5 2400G as well, on an asus B350 board. (with 32g 2400mhz ram), a 1TB evo970 M.2 nvme ssd, 1TB SATA SSD, 2G SATA SSD and 8TB spinning drive. I'm running slackware 14.2 (64bit) but with 4.19.10 kernel (huge, modules, source, and 20181218 firmware) taken from current. I have root on the 1tb sata ssd to avoid having to run the "current" installer for the nvme drive, and am booting in legacy mode rather than uefi mode.

I have a peculiar problem in that although if I reboot the system, it reboots just fine, if I run

Code:

shutdown -h now

it appears to shutdown linux/slackware, but the pc (PSU) and cpu fan continues to run. I have to press the physical power button, or reset to start up, but it is concerning that shutdown doesn't work properly.
(I also have some issues with A8 9700 am4 cpus on asrock A320M-HDV boards as well, but that that is off the ryzen topic)

I had a similar problem on my system (Asus B350M-A and Ryzen 2400G). It appeared when 4.19.0 first came out, 4.18 was fine.
I found if I disabled the AMDGPU drivers from loading, my system would then then power off properly. Unfortunately I haven't bothered to troubleshoot any further, since 4.19.2 and newer appeared to fix things for my system.
Do you have the latest BIOS for your boards? Most AM4 motherboards got an update about a month ago.

MarcT · 01-11-2019, 04:10 AM

Quote:

Originally Posted by timsoft

4.19.10 kernel

I have a peculiar problem in that although if I reboot the system, it reboots just fine, if I run

Code:

shutdown -h now

it appears to shutdown linux/slackware, but the pc (PSU) and cpu fan continues to run. I have to press the physical power button, or reset to start up, but it is concerning that shutdown doesn't work properly.

I had the "no power-off" issue also for a while on 4.18 & early 4.19. I don't recall which one, but a later 4.19 kernel update fixed it. 4.19.13 & 4.19.14 work fine for me.

MarcT · 01-11-2019, 04:43 AM

Quote:

Originally Posted by Paulo2

About IOMMU and message

Code:

[    9.374585] AMD-Vi: Event logged [
[    9.374586] IO_PAGE_FAULT device=0e:00.0 domain=0x0003 address=0x000000f4001f48c0 flags=0x0010]

I had problems with that in my new machine FX-8320E/Gigabyte 970A-DS3P (not so 'new'

) I assembled in September last year.
Boot was stuck for ~20 seconds at those messages. I found the solution was adding iommu=soft at the append line in lilo.conf.
Also, there is an option in BIOS 'IOMMU Controller', it must be enabled.

Try "iommu=pt" (if your kernel supports it), which might give better performance - particularly with Virtualisation. pt = passthrough
As I understand it; this allows for some hardware acceleration, rather than using the pure software (SWIOTLB) iommu.

timsoft · 01-11-2019, 07:27 AM

the latest bios is 4207 (13th dec 2018 )which I have already, and my kernel is more recent than 19.2. I've raise a tech support query with asus and will report back what they have to say. how did you disable amdgpu drivers from loading?
te output of lsmod is

Code:

Module                  Size  Used by
ipv6                  487424  46
fuse                  118784  1
amdkfd                167936  1
amd_iommu_v2           20480  1 amdkfd
eeepc_wmi              16384  0
asus_wmi               32768  1 eeepc_wmi
sparse_keymap          16384  1 asus_wmi
rfkill                 28672  1 asus_wmi
i2c_dev                16384  0
amdgpu               3239936  0
wmi_bmof               16384  0
snd_hda_codec_realtek   110592  1
snd_hda_codec_generic    81920  1 snd_hda_codec_realtek
evdev                  24576  9
snd_hda_codec_hdmi     57344  1
snd_hda_intel          45056  0
chash                  16384  1 amdgpu
gpu_sched              28672  1 amdgpu
snd_hda_codec         147456  4 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec_realtek
ttm                   114688  1 amdgpu
edac_mce_amd           28672  0
snd_hda_core           94208  5 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek
drm_kms_helper        196608  1 amdgpu
snd_hwdep              16384  1 snd_hda_codec
ccp                    86016  0
drm                   475136  5 gpu_sched,drm_kms_helper,amdgpu,ttm
snd_pcm               114688  4 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_core
kvm                   729088  0
snd_timer              36864  1 snd_pcm
agpgart                49152  2 ttm,drm
i2c_algo_bit           16384  1 amdgpu
irqbypass              16384  1 kvm
snd                    90112  8 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek,snd_timer,snd_pcm
r8169                  90112  0
fb_sys_fops            16384  1 drm_kms_helper
xhci_pci               16384  0
i2c_piix4              24576  0
syscopyarea            16384  1 drm_kms_helper
sysfillrect            16384  1 drm_kms_helper
sysimgblt              16384  1 drm_kms_helper
crct10dif_pclmul       16384  0
soundcore              16384  1 snd
crc32_pclmul           16384  0
crc32c_intel           24576  3
ghash_clmulni_intel    16384  0
k10temp                16384  0
libphy                 73728  2 r8169
i2c_core               77824  6 drm_kms_helper,i2c_algo_bit,amdgpu,i2c_piix4,i2c_dev,drm
xhci_hcd              241664  1 xhci_pci
hwmon                  20480  3 k10temp,asus_wmi,amdgpu
wmi                    28672  2 asus_wmi,wmi_bmof
gpio_amdpt             16384  0
video                  45056  1 asus_wmi
gpio_generic           20480  1 gpio_amdpt
pcc_cpufreq            16384  0
button                 16384  0
acpi_cpufreq           16384  0
loop                   32768  0

timsoft · 01-11-2019, 07:36 AM

sorry, I didn't see the other 2 posts before I'd finished replying. I'll try the most recent current huge kernel (4.19.14) and see how it goes.

Paulo2 · 01-11-2019, 08:11 AM

Quote:

Originally Posted by MarcT

Try "iommu=pt" (if your kernel supports it), which might give better performance - particularly with Virtualisation. pt = passthrough
As I understand it; this allows for some hardware acceleration, rather than using the pure software (SWIOTLB) iommu.

Thanks for the hint. I tested it but couldn't see any difference, maybe it does difference
in a more heavy loaded system than mine.

I think that for passthrough works it should be enable in kernel, or not?

Code:

zgrep IOMMU /proc/config.gz 
CONFIG_GART_IOMMU=y
# CONFIG_CALGARY_IOMMU is not set
CONFIG_VFIO_IOMMU_TYPE1=m
# CONFIG_VFIO_NOIOMMU is not set
CONFIG_IOMMU_API=y
CONFIG_IOMMU_SUPPORT=y
# Generic IOMMU Pagetable Support
# CONFIG_IOMMU_DEBUGFS is not set
# CONFIG_IOMMU_DEFAULT_PASSTHROUGH is not set
CONFIG_IOMMU_IOVA=y
CONFIG_AMD_IOMMU=y
CONFIG_AMD_IOMMU_V2=m
CONFIG_INTEL_IOMMU=y
CONFIG_INTEL_IOMMU_SVM=y
# CONFIG_INTEL_IOMMU_DEFAULT_ON is not set
CONFIG_INTEL_IOMMU_FLOPPY_WA=y
CONFIG_IOMMU_HELPER=y
# CONFIG_IOMMU_DEBUG is not set

(from current -current kernel 4.19.14)

akimmet · 01-11-2019, 09:59 AM

Quote:

Originally Posted by timsoft

how did you disable amdgpu drivers from loading?

I added nomodeset to the kernel command line options.

timsoft · 01-11-2019, 03:45 PM

asus recommended the following..

Quote:

In this case I recommend you make a CMOS reset of the BIOS by taking out the CMOS battery for 3-5 minutes while the PSU is unplugged. While the power cord from the PSU is still unplugged, press the power button down for 30 seconds to power discharge the unit. Then place the CMOS battery back in, plug in the PSU and try again.
After this go into the BIOS > Advanced Menu > APM Configuration, from here set the ERP Ready to Enabled S4 + S5 or Enabled S5 and set the Restore AC Power Loss to Last State and test the motherboard again.

I won't get access to the machine till monday, so will report how it works.