The Latest Kernel Release.

PROBLEMCHYLD · 10-24-2018, 01:25 PM

What does this error mean?

modprobe: ERROR: could not insert 'crc32c_intel': No such device"

volkerdi · 10-24-2018, 01:53 PM

Quote:

Originally Posted by PROBLEMCHYLD

What does this error mean?

modprobe: ERROR: could not insert 'crc32c_intel': No such device"

Are you using btrfs?

That will try to load crc32c_intel if it detects an Intel CPU, but if that CPU doesn't support the required extended opcodes, then the module load will fail and crc32c_generic will be loaded instead. Other than the error message from modprobe there shouldn't be any ill effects (you can check lsmod output to see that the crc32c_generic module was loaded instead).

Something should probably be a bit smarter about this so that perhaps it's just a warning rather than an error message, but given that it involves userspace module loading I'm not sure how they would go about that, or which "they" would be considered responsible.

Lysander666 · 10-24-2018, 01:56 PM

This may help.

https://github.com/NixOS/nixpkgs/issues/25734

slackware_platypus · 10-24-2018, 02:13 PM

Hello folks,

I have a Slackware64-current qemu-kvm guest under Centos 6.10(*).
After slackpkg update to Tue Oct 23 05:11:47 UTC 2018 (kernel 4.19.0), VM reboots after loading initrd.img
Reverted to older set of kernel txz files using upgradepkg, boots cleanly again.

Well, okay.

Tried booting slackware64-current-install-dvd.iso based on Tue Oct 23 05:11:47 UTC 2018, same problem.
Tried booting slackware64-current-16_Oct_2018-DVD.iso, all is well.

Sadly, it has been a long time since I have built a custom kernel. Maybe it's a KVM thing. Any ideas?
Thanks, Rob Clark

(*) The last of the V8 Interceptors; shame they blew it up.

PROBLEMCHYLD · 10-24-2018, 04:54 PM

Quote:

Originally Posted by volkerdi

Are you using btrfs?

No I am not. Here is my lsmod

Code:

[problemchyld@darkstar:Desktop] $ lsmod
Module                  Size  Used by
rfcomm                 40960  14
xt_CHECKSUM            16384  1
iptable_mangle         16384  1
ipt_MASQUERADE         16384  3
iptable_nat            16384  1
nf_nat_ipv4            16384  2 ipt_MASQUERADE,iptable_nat
nf_nat                 32768  1 nf_nat_ipv4
ipt_REJECT             16384  2
nf_reject_ipv4         16384  1 ipt_REJECT
bridge                139264  0
stp                    16384  1 bridge
llc                    16384  2 bridge,stp
ebtable_filter         16384  0
ebtables               24576  1 ebtable_filter
ip6table_filter        16384  0
ip6_tables             20480  1 ip6table_filter
vhba                   20480  0
vhost_net              24576  0
vhost                  36864  1 vhost_net
tap                    24576  1 vhost_net
tun                    36864  2 vhost_net
nf_log_ipv4            16384  16
nf_log_common          16384  1 nf_log_ipv4
xt_LOG                 16384  16
xt_tcpudp              16384  45
xt_conntrack           16384  28
nf_conntrack          106496  4 ipt_MASQUERADE,xt_conntrack,nf_nat_ipv4,nf_nat
nf_defrag_ipv6         20480  1 nf_conntrack
nf_defrag_ipv4         16384  1 nf_conntrack
iptable_filter         16384  1
ipv6                  376832  64 bridge
ip_tables              20480  4 iptable_mangle,iptable_filter,iptable_nat
x_tables               28672  12 xt_LOG,ipt_REJECT,iptable_mangle,ip_tables,ebtables,iptable_filter,xt_tcpudp,ipt_MASQUERADE,xt_CHECKSUM,ip6table_filter,xt_conntrack,ip6_tables
cmac                   16384  1
bnep                   20480  2
fuse                   90112  3
btusb                  40960  0
btrtl                  16384  1 btusb
btbcm                  16384  1 btusb
btintel                16384  1 btusb
bluetooth             311296  41 btrtl,btintel,bnep,btbcm,rfcomm,btusb
ecdh_generic           28672  2 bluetooth
joydev                 20480  0
gpio_ich               16384  0
hp_wmi                 16384  0
sparse_keymap          16384  1 hp_wmi
i2c_dev                16384  0
wmi_bmof               16384  0
i915                 1359872  6
ath5k                 139264  0
cec                    45056  1 i915
ath                    28672  1 ath5k
evdev                  20480  17
rc_core                36864  1 cec
coretemp               16384  0
mac80211              606208  1 ath5k
psmouse               118784  0
8139too                24576  0
serio_raw              16384  0
hwmon                  16384  1 coretemp
drm_kms_helper        147456  1 i915
uhci_hcd               28672  0
drm                   356352  8 i915,drm_kms_helper
mii                    16384  1 8139too
snd_hda_codec_conexant    24576  1
cfg80211              548864  3 mac80211,ath,ath5k
rfkill                 24576  6 bluetooth,hp_wmi,cfg80211
snd_hda_codec_generic    69632  1 snd_hda_codec_conexant
snd_hda_intel          36864  3
i2c_algo_bit           16384  1 i915
i2c_i801               28672  0
lpc_ich                24576  0
wmi                    20480  2 wmi_bmof,hp_wmi
thermal                20480  0
fb_sys_fops            16384  1 drm_kms_helper
syscopyarea            16384  1 drm_kms_helper
sysfillrect            16384  1 drm_kms_helper
sysimgblt              16384  1 drm_kms_helper
i2c_core               57344  7 i2c_algo_bit,i2c_i801,psmouse,i915,i2c_dev,drm_kms_helper,drm
snd_hda_codec         106496  3 snd_hda_intel,snd_hda_codec_conexant,snd_hda_codec_generic
video                  40960  1 i915
battery                20480  0
ehci_pci               16384  0
ac                     16384  0
ehci_hcd               53248  1 ehci_pci
intel_agp              16384  0
intel_gtt              20480  2 intel_agp,i915
agpgart                36864  3 intel_agp,intel_gtt,drm
snd_hda_core           65536  4 snd_hda_intel,snd_hda_codec_conexant,snd_hda_codec,snd_hda_codec_generic
snd_hwdep              16384  1 snd_hda_codec
snd_pcm                81920  3 snd_hda_intel,snd_hda_codec,snd_hda_core
snd_timer              28672  1 snd_pcm
snd                    61440  13 snd_hda_intel,snd_hwdep,snd_hda_codec_conexant,snd_hda_codec,snd_timer,snd_hda_codec_generic,snd_pcm
soundcore              16384  1 snd
button                 16384  0
pcc_cpufreq            16384  0
acpi_cpufreq           16384  0
loop                   28672  0
ext4                  569344  1
mbcache                16384  1 ext4
jbd2                   98304  1 ext4

alex14641 · 10-24-2018, 06:25 PM

4.19 is not working for me:

In 4.19, when I close the laptop lid, the screen turns off, the fan does not spin down; on opening the lid, the screen does not turn back on, and the laptop is pingable, but I can't SSH in. With 4.18, there are no problems. I'm running Slackware current. I have KDE configured to put the laptop to sleep when the lid is closed. Going to do some digging.

orbea · 10-24-2018, 06:46 PM

Quote:

Originally Posted by alex14641

4.19 is not working for me:

In 4.19, when I close the laptop lid, the screen turns off, the fan does not spin down; on opening the lid, the screen does not turn back on, and the laptop is pingable, but I can't SSH in. With 4.18, there are no problems. I'm running Slackware current. I have KDE configured to put the laptop to sleep when the lid is closed. Going to do some digging.

I would ssh in before you close the lid and then run 'dmesg -w'. Then when you reproduce the issue you hopefully will be able to see some helpful debugging output.

alex14641 · 10-24-2018, 09:25 PM

Quote:

Originally Posted by orbea

I would ssh in before you close the lid and then run 'dmesg -w'. Then when you reproduce the issue you hopefully will be able to see some helpful debugging output.

Ran dmesg -w with 4.18 and 4.19: among the differences were

Code:

  PM: suspend entry (deep)
  PM: Syncing filesystems ... done.
  PM: Saving platform NVS memory
  PM: Restoring platform NVS memory
  PM: suspend exit

The above appears only in the dmesg for 4.18: this is when the lid is closed.

Onward and upward.

orbea · 10-25-2018, 08:34 AM

That unfortunately doesn't look as helpful as I hoped... I'm personally sticking with 4.18.x until 4.19 matures more since everything seems to be working at the moment.

alex14641 · 10-25-2018, 05:58 PM

Quote:

Originally Posted by alex14641

Ran dmesg -w with 4.18 and 4.19: among the differences were

Code:

  PM: suspend entry (deep)
  PM: Syncing filesystems ... done.
  PM: Saving platform NVS memory
  PM: Restoring platform NVS memory
  PM: suspend exit

The above appears only in the dmesg for 4.18: this is when the lid is closed.

Onward and upward.

As I believe this is a kernel issue, I will post a bug report on bugzilla, and revert to 4.18

Skaendo · 10-27-2018, 10:10 AM

Just want to say thanks to idlemoor for his DUSK kernels.

4.19 kernels are playing hell with my Intel GM965 chipset. This is a well known bug and no one upstream seems to care about it because apparently it's too old (circa 1997/8 here).

The 4.18 kernels that previously came with -current were not quite as bad, but with the 4.19 I think that the drm_kms_helper going "flip_done timeout" is the culprit and has slowed my boot down to ~10 minutes from cold boot to desktop.

I have dropped back to 4.4.162 and now it's flying again. I am going to be testing out newer versions of DUSK this weekend. Maybe try to mod one of the scripts for 4.9.x and that'll give me a extra year of LTS.

But I am worried about breakage. Is there anything that I should be concerned with running the 4.4.x kernels on -current? This is not a "production" machine.

Didier Spaier · 10-27-2018, 02:04 PM

Quote:

Originally Posted by Skaendo

But I am worried about breakage. Is there anything that I should be concerned with running the 4.4.x kernels on -current?

I assume that you don't, as long as your hardware is happy with it and it's not declared EOL.

EDIT: not all bug fixes are back ported, for instance I am aware of one that is already submitted for inclusion but will probably only make it in 4.21 thus won't be applied in Slackware 15.0.

But if you are not suffering of a bug you consider annoying enough to upgrade you kernel to get a fix, that's OK.

cwizardone · 10-30-2018, 10:06 AM

This was originally posted in the "Request for -current" thread, but I thought it would be more appropriate to post it here. (Yeah, I know, I have too much time on my hands. I need to go back to work and get out of the house

) All but the first sentence has been removed from the post in the -current thread. This has been edited, a little, to bring it up to date.

************
The 4.19 kernel has been running on this box for 8-1/2 days now without so much as a hiccup or a sneeze.
First, I used the dusk-4.19-generic kernel with an initrd, of course, and when it became available, Mr. Volkerding's 4.19-huge kernel. There have been no problems with VirtualBox, WINE, dosemu, VLC, SMPlayer, LibreOffice, VeraCrypt, XnView MP, Adobe Reader, google-earth, streaming video in Firefox or Vivaldi, browsing the 'Net with Pale Moon and it hasn't been necessary to rebuild any SlackBuilds. (edit in, Oh, and PulseAudio works just as advertised

).

This is with -current, updates were installed as they became available, and the Nivida-410.66 and then the 410.73 drivers. There were no problems with either Nvidia driver.
*******************

All the rest is new text.

This has been the smoothest upgrade to a new LTS kernel that I can remember, but, then, at my age, I can barely remember my name. When I get up in the morning, and, I've probably said this before (did I?

), I look in the mirror and say to myself, "Who is that old fart?"

Anyway, as we progress through the forthcoming upgrades, I'm going to keep 4.19.0 in my lilo.conf as the "fallback" kernel.

Perhaps, the newer hardware is fast enough that it no longer matters, but it is now to the point I cannot "see or feel" any difference between a generic kernel (and initrd) and the huge kernel. OTOH, I would imagine a performance difference could be measured with the proper utilities.

1337_powerslacker · 10-30-2018, 09:22 PM

Quote:

Originally Posted by cwizardone

Perhaps, the newer hardware is fast enough that it no longer matters, but it is now to the point I cannot "see or feel" any difference between a generic kernel (and initrd) and the huge kernel. OTOH, I would imagine a performance difference could be measured with the proper utilities.

As far as I can tell, the only real difference between the huge and generic kernels is the number of modules built. I used a tutorial to find out how to compile only those modules my system actually needs. A side benefit is that the time required to compile modules is drastically reduced.

I totally agree with you about huge vs. generic.

Lysander666 · 10-31-2018, 04:51 AM

Quote:

Originally Posted by cwizardone

Perhaps, the newer hardware is fast enough that it no longer matters, but it is now to the point I cannot "see or feel" any difference between a generic kernel (and initrd) and the huge kernel. OTOH, I would imagine a performance difference could be measured with the proper utilities.

I'm glad you said this, I was beginning to wonder. I think for me the difference in boot speed between the two can't be more than about five seconds on my slowest machine. Having said that, I use persistent naming so I have to have an initrd anyway.