You are not logged in.
Tharbad wrote:Does ck has the faulty kernel option that cause ubuntu 17.10 to be pulled back from the mirrors?
(Something about an intel driver in kernel 4.13 that allows the kernel to write to the BIOS/UEFI memory space)Did you research https://bugs.launchpad.net/ubuntu/+sour … ug/1734147 / https://cateee.net/lkddb/web-lkddb/SPI_ … TFORM.html?
No. Just what I've heard. I guessing this means no?
Offline
https://bugs.launchpad.net/ubuntu/+sour … mments/209
You can check the status of CONFIG_SPI_INTEL_SPI_PLATFORM in any kernel you are interested in.
Edit:
As a general note graysky uses the same config as the linux kernel package so unless an issue is linux-ck speciffic both kernels will be affected.
Last edited by loqs (2017-12-21 18:35:11)
Offline
thanks
Offline
kernel/irq/.affinity.o.cmd:1: *** missing separator. Stop.
make[2]: *** [scripts/Makefile.build:573: kernel/irq] Error 2
make[1]: *** [Makefile:1029: kernel] Error 2
make: *** [Makefile:994: vmlinux_prereq] Error 2
==> ERROR: A failure occurred in build().
Aborting...
==> ERROR: Makepkg was unable to build linux-ck.
Any ideas? anyone?
Offline
i had this very same r8169 problem to make matters worse i have a gigabyte mobo i have to run amd_iommu=on iommu=pt for my usb3.0 to work and for my network to work without crashing as well. i seem to remember there being 2 versions of r8169 or perhaps it was r8168 when i first encountered this several years ago, anyway they both had same name but one crashed every 20 minutes
to above poster: do you have a gigabyte motherboard? mine is ga-970a-d3p, you may need the iommu solution
I finally had the time to test the proposed solution for my network problem. I added "intel_iommu=on iommu=pt" to the ck kernel command line but it didn't fix anything. I tried with intel_iommu rather than amd_iommu since my pc has no AMD part (Intel processor and Nvidia chipset).
Anyway, looking into the journal I found the following lines which I don't understand but seems to be indicative of a network problem:
Dec 25 10:34:03 conan kernel: perf: interrupt took too long (2510 > 2500), lowering kernel.perf_event_max_sample_rate to 79600
Dec 25 10:38:01 conan kernel: perf: interrupt took too long (3150 > 3137), lowering kernel.perf_event_max_sample_rate to 63500
Dec 25 10:38:22 conan plasmashell[494]: trying to show an empty dialog
Dec 25 10:39:40 conan kernel: NETDEV WATCHDOG: eth0 (forcedeth): transmit queue 0 timed out
Dec 25 10:39:40 conan kernel: ------------[ cut here ]------------
Dec 25 10:39:40 conan kernel: WARNING: CPU: 0 PID: 7 at net/sched/sch_generic.c:320 dev_watchdog+0x21b/0x220
Dec 25 10:39:40 conan kernel: Modules linked in: mousedev snd_hda_codec_realtek snd_hda_codec_generic nvidia(PO) coretemp kvm_intel ppdev snd_hda_intel kvm gspca_sonixj gspca_main snd_hda_codec v4l2_common videodev snd_hda_core snd_hwdep
Dec 25 10:39:40 conan kernel: CPU: 0 PID: 7 Comm: ksoftirqd/0 Tainted: P O 4.14.8-1-ck-core2 #1
Dec 25 10:39:40 conan kernel: Hardware name: System manufacturer System Product Name/P5N-E SLI, BIOS ASUS P5N-E SLI ACPI BIOS Revision 1301 09/25/2008
Dec 25 10:39:40 conan kernel: task: ffff8a1b3d165c00 task.stack: ffffa22e00040000
Dec 25 10:39:40 conan kernel: RIP: 0010:dev_watchdog+0x21b/0x220
Dec 25 10:39:40 conan kernel: RSP: 0000:ffffa22e00043d90 EFLAGS: 00013286
Dec 25 10:39:40 conan kernel: RAX: 000000000000003d RBX: 0000000000000000 RCX: 0000000000000000
Dec 25 10:39:40 conan kernel: RDX: 0000000000000000 RSI: ffff8a1b3fc0dbb8 RDI: ffff8a1b3fc0dbb8
Dec 25 10:39:40 conan kernel: RBP: ffff8a1b3c12445c R08: 0000000000000001 R09: 00000000000002b5
Dec 25 10:39:40 conan kernel: R10: ffffa22e00043e10 R11: 0000000000000000 R12: ffff8a1b3c124000
Dec 25 10:39:40 conan kernel: R13: 0000000000000000 R14: 0000000000000001 R15: ffff8a1b3c031280
Dec 25 10:39:40 conan kernel: FS: 0000000000000000(0000) GS:ffff8a1b3fc00000(0000) knlGS:0000000000000000
Dec 25 10:39:40 conan kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Dec 25 10:39:40 conan kernel: CR2: 00007f56acd0d020 CR3: 0000000076154000 CR4: 00000000000006f0
Dec 25 10:39:40 conan kernel: Call Trace:
Dec 25 10:39:40 conan kernel: ? qdisc_rcu_free+0x40/0x40
Dec 25 10:39:40 conan kernel: ? qdisc_rcu_free+0x40/0x40
Dec 25 10:39:40 conan kernel: call_timer_fn+0x2e/0x150
Dec 25 10:39:40 conan kernel: run_timer_softirq+0x435/0x480
Dec 25 10:39:40 conan kernel: ? __schedule+0x6fb/0xce0
Dec 25 10:39:40 conan kernel: ? sort_range+0x20/0x20
Dec 25 10:39:40 conan kernel: __do_softirq+0xd9/0x2da
Dec 25 10:39:40 conan kernel: ? sort_range+0x20/0x20
Dec 25 10:39:40 conan kernel: run_ksoftirqd+0x24/0x50
Dec 25 10:39:40 conan kernel: smpboot_thread_fn+0x114/0x1d0
Dec 25 10:39:40 conan kernel: kthread+0x117/0x130
Dec 25 10:39:40 conan kernel: ? kthread_create_on_node+0x70/0x70
Dec 25 10:39:40 conan kernel: ret_from_fork+0x25/0x30
Dec 25 10:39:40 conan kernel: Code: 8c 24 60 04 00 00 eb 8f 4c 89 e7 c6 05 40 96 78 00 01 e8 29 76 fd ff 89 d9 4c 89 e6 48 c7 c7 98 c4 a4 a6 48 89 c2 e8 30 1b b7 ff <0f> ff eb c1 90 66 66 66 66 90 48 c7 47 08 00 00 00 00 48 c7 07
Dec 25 10:39:40 conan kernel: ---[ end trace c90349d9637f22ee ]---
Dec 25 10:39:40 conan kernel: forcedeth 0000:00:14.0 eth0: Got tx_timeout. irq status: 00000032
Offline
@snack please rebuild linux-ck with the patchset swapped out the individual parts http://ck.kolivas.org/patches/4.0/4.14/ … 1/patches/ see if you can pinpoint which patch is the cause.
Please also use code tags and you forgot to include which networking driver the system is using and I could not see it from the list of modules the kernel listed as loaded.
Offline
@loqs thanks for your answer. I think that the network driver is forcedeth; it appears in the error message I posted above:
Dec 25 10:39:40 conan kernel: NETDEV WATCHDOG: eth0 (forcedeth): transmit queue 0 timed out
and also with dmesg:
$ dmesg | grep -i ethernet
[ 4.050134] forcedeth: Reverse Engineered nForce ethernet driver. Version 0.64.
As for the advice to build linux-ck removing the patches one by one, I don't think I can do it. As I said this is my parent's pc, I have limited access to it and it is an old machine for which building a kernel would require a lot of time. I'll see if I can do it in the next days.
Offline
@snack you could try reporting what you have to CK see if he has any thoughts on the cause, it could be MuQSS it could be something else in linux-ck patch set, it could be graysky's CPU optimizations.
Those are the main differences from the linux package that does not exhibit the issue. Or avoid using linux-ck on that system.
Edit:
@graysky have you done or will you be doing any benchmarking of 4.14.8 or earlier vs 4.14.11 on the performance impact of PTI seeing synthetic benchmarks just measuring the relative performance of
a context switch take a 30% performance reduction on ivy bridge [1] and 40% on EPYC [2] but that is just switching from kernel space to userspace not a real workload.
[1] https://twitter.com/grsecurity/status/9 … 9906757638
[2] https://twitter.com/grsecurity/status/9 … 5460702208
Last edited by loqs (2017-12-31 18:40:31)
Offline
Getting:
(16/16) checking keys in keyring [#########################################] 100%
downloading required keys...
:: Import PGP key 2048R/4E22BB637E26407D5DEE550988A032865EE46C4C, "graysky (used to sign repo-ck packages) <graysky@archlinux.us>", created: 2012-12-11? [Y/n]
(16/16) checking package integrity [#########################################] 100%
error: linux-ck-ivybridge: signature from "graysky (used to sign repo-ck packages) <graysky@archlinux.us>" is unknown trust
:: File /var/cache/pacman/pkg/linux-ck-ivybridge-4.14.11-1-x86_64.pkg.tar.xz is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n]
error: linux-ck-ivybridge-headers: signature from "graysky (used to sign repo-ck packages) <graysky@archlinux.us>" is unknown trust
:: File /var/cache/pacman/pkg/linux-ck-ivybridge-headers-4.14.11-1-x86_64.pkg.tar.xz is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n]
error: nvidia-ck-ivybridge: signature from "graysky (used to sign repo-ck packages) <graysky@archlinux.us>" is unknown trust
:: File /var/cache/pacman/pkg/nvidia-ck-ivybridge-1:387.34-7-x86_64.pkg.tar.xz is corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n]
error: failed to commit transaction (invalid or corrupted package)
Offline
4.14.11-1-ck-haswell worked for me
Offline
Getting:
(16/16) checking keys in keyring [#########################################] 100% downloading required keys... :: Import PGP key 2048R/4E22BB637E26407D5DEE550988A032865EE46C4C, "graysky (used to sign repo-ck packages) <graysky@archlinux.us>", created: 2012-12-11? [Y/n] (16/16) checking package integrity [#########################################] 100% error: linux-ck-ivybridge: signature from "graysky (used to sign repo-ck packages) <graysky@archlinux.us>" is unknown trust :: File /var/cache/pacman/pkg/linux-ck-ivybridge-4.14.11-1-x86_64.pkg.tar.xz is corrupted (invalid or corrupted package (PGP signature)). Do you want to delete it? [Y/n] error: linux-ck-ivybridge-headers: signature from "graysky (used to sign repo-ck packages) <graysky@archlinux.us>" is unknown trust :: File /var/cache/pacman/pkg/linux-ck-ivybridge-headers-4.14.11-1-x86_64.pkg.tar.xz is corrupted (invalid or corrupted package (PGP signature)). Do you want to delete it? [Y/n] error: nvidia-ck-ivybridge: signature from "graysky (used to sign repo-ck packages) <graysky@archlinux.us>" is unknown trust :: File /var/cache/pacman/pkg/nvidia-ck-ivybridge-1:387.34-7-x86_64.pkg.tar.xz is corrupted (invalid or corrupted package (PGP signature)). Do you want to delete it? [Y/n] error: failed to commit transaction (invalid or corrupted package)
My fault. Had to delete pacman keys a few days back and forgot to import ck keys afterwords.
Offline
I have just updated using the linux-ck-k10-4.14.12-3-x86_64.pkg.tar.xz package and the associated nvidia-ck-k10 and linux-ck-k10-headers packages.
On reboot, the system failed to mount an xfs partition, reporting 'Unknown filesystem, xfs'.
Downgraded to version 4.14-11 and booting normallyagain. Missing xfs support in the 4.14.12-3 kernel build perhaps?
Offline
Welcome to the archlinux forums pga256 did you check the package to see if did contain the xfs module?
$ pacman -Qlp linux-ck-k10-4.14.12-3-x86_64.pkg.tar.xz | grep xfs
linux-ck-k10 /usr/lib/modules/4.14.12-3-ck-k10/kernel/fs/xfs/
linux-ck-k10 /usr/lib/modules/4.14.12-3-ck-k10/kernel/fs/xfs/xfs.ko.xz
or `pacman -Ql linux-ck-k10` if the package is installed. Are you sure the boot partition was mounted when you performed the kernel update?
Offline
Welcome to the archlinux forums pga256 did you check the package to see if did contain the xfs module?
$ pacman -Qlp linux-ck-k10-4.14.12-3-x86_64.pkg.tar.xz | grep xfs linux-ck-k10 /usr/lib/modules/4.14.12-3-ck-k10/kernel/fs/xfs/ linux-ck-k10 /usr/lib/modules/4.14.12-3-ck-k10/kernel/fs/xfs/xfs.ko.xz
or `pacman -Ql linux-ck-k10` if the package is installed. Are you sure the boot partition was mounted when you performed the kernel update?
Thanks for your reply.
Yes, the above command reports that the xfs module is built in. The boot partition is definitely mounted and I have ran many similar upgrades without issue.
I ran the update again and the vmlinuz-ck-k10 file in /boot is not being updated by the upgrade. The initramfs-linux-ck-k10.img is updating normally and the associated fallback.img is being created.
I tried manually running
mkinitcpio -p linux-ck-k10
after updating but it made no difference. The partition used for /boot is a 512M ext2 partition with 376M free space, so disk space is not the issue. Checked the filesystem on /boot and it is clean.
Offline
To see if the xfs module is added to the initrd
$ bsdcpio -itv < /boot/initramfs-linux-ck-k10.img | grep xfs
When the xfs filesystem is failed to mount are you dropped to a rescue shell? If so what is the output of
ls /sys/module | grep xfs
modprobe xfs
ls /sys/module | grep xfs
uname
Offline
+1 westmere
If westmere is not planned to be added, then maybe it should be mentioned in the wiki table that westmere users should install nehalem.
Offline
I thougth that linux-ck strength was to make a desktop system extremely responsive. Running a ffmpeg H.264 encoding in the background made my computer totally unusable. My MP3 player audio started to stutter. The mouse cursor movement was jerky. Very ugly experience. It must be a regression as I don't recall seeing that type of bad performance for a long time with linux-ck.
I did try to play schedtool, set FFMPEG to IDLEPRIO and VLC to ISOPRIO. I tried to play with FFMPEG nice value, reduce its CPU affinity. Nothing did improve the situation. I must confess that I have a month old kernel. My system is up to date it is just that it has been that long that I haven't rebooted my computer...
Is there a know problem that could explain what I have seen?
$ sudo schedtool -D 20884 // <-- ffmpeg
$ ps -ef | grep vlc
lano1106 3443 587 10 2017 tty2 2-21:32:04 /usr/bin/vlc --started-from-file
lano1106 21798 721 0 14:08 pts/1 00:00:00 grep --color=auto vlc
$ sudo schedtool -I 3443
$ schedtool 20884
PID 20884: PRIO 0, POLICY D: SCHED_IDLEPRIO, NICE 0, AFFINITY 0xff
$ sudo schedtool -a 0x2e 20884
$ renice -n 19 -p 20884
20884 (process ID) old priority 0, new priority 19
$ uname -a
Linux Wailaba2 4.14.6-1-ck-nehalem #1 SMP PREEMPT Thu Dec 14 16:31:55 EST 2017 x86_64 GNU/Linux
$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz
stepping : 5
microcode : 0x19
cpu MHz : 2668.000
cache size : 8192 KB
Offline
Are you comparing ck to the standard kernel, or are you comparing a recent kernel to a month-old kernel, as there have been big changes with potentially substantial performance penalties recently in all kernels.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
It is not a comparison of different kernels. And I'm even not talking about the Intel CPU bug that has been discovered last week.
This is just an observation. A CPU intensive background (FFMPEG encoding) task is bringing my system to its knees. It is the first time that I observe that behavior and I was curious if others had ideas about what is going on...
I have been using linux-ck for at least 5 years and its strength was to avoid this exact situation...
Could the migration from BFS to MuQSS explain what I'm seeing?
You hit report instead of quote, lano1106.
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Offline
You hit report instead of quote, lano1106.
I know, sorry about that. I realize what I did just after clicking send when I couldn't see my reply.... I won't do it again. I promise...
This is not a comparison of different kernels. I'm not talking about the Intel CPU bug discovered last week. It is simply an observation that running a CPU intensive background task (ffmpeg) is now bringing my system to its knees no matter if I use tweakings that used to work in the past (schedtool)
This is surprising because the strength of linux-ck is supposed to be to avoid this type of situation. I have been using linux-ck for over 5 years and it is the first time that I'm that annoyed by a background task while using linux-ck...
Could it be caused by BFS to MuQSS migration? Or maybe by some well known recent issue (I must confess that I'm not here very often anymore...)
Last edited by lano1106 (2018-01-12 22:48:26)
Offline
Don't worry, accidents happen.
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Offline
I'm not talking about the Intel CPU bug discovered last week.
I know. My point was you should be. I don't know if the recent kernel patches would cause the level of disruption you describe, but they are known to cause (in some cases quite substantial) performance detriments. So why go hunting for other suspects until you attempt to rule out the most obvious one.
Last edited by Trilby (2018-01-12 23:20:52)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
I know. My point was you should be. I don't know if the recent kernel patches would cause the level of disruption you describe, but they are known to cause (in some cases quite substantial) performance detriments. So why go hunting for other suspects until you attempt to rule out the most obvious one.
This is a good point. but we can be sure that the latest patches aren't the cause. It is 4.14.6 compiled around mid-december!
Offline
Ah, that would rule that out
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
To see if the xfs module is added to the initrd
$ bsdcpio -itv < /boot/initramfs-linux-ck-k10.img | grep xfs
When the xfs filesystem is failed to mount are you dropped to a rescue shell? If so what is the output of
ls /sys/module | grep xfs modprobe xfs ls /sys/module | grep xfs uname
Sorry it took me a while to respond to this and thanks again for your reply.
Running the tests above show that the xfs module is not present and modprobe fails to find it. Running uname reports 'Linux' and running uname -r shows the version number as 4.14.11.
Although the initramfs is being updated, vmlinuz is not. This is also the case with the latest 4.14.13 build.
I have checked the file permissions and atrtributes but they look normal.
Offline