You need to added your mirror testing directory in your /etc/slackpkg/mirrors

sorry double post

tested kernel-4.14.4, not convincing, segfaults as usual (on first boot).

It is because of the PRIORITY setting in your /etc/slackpkg/slackpkg.conf file. This sets the order in which it will look for packages. The default is set to patches, %PKGMAIN (which is the original packages in the slackware or slackware64 directory), extra, pasture, and finally testing.

If you want the testing kernels through slackpkg, you'd need to move testing to a higher priority than %PKGMAIN (since patches aren't being used in -current, that option does nothing right now).

Keep in mind, this will prioritize all of the testing/ packages above the normal install, so in addition to the kernels, you'll also get php-7.2 and efibootmgr-0.6.0. Both of the existing php and efibootmgr packages will be upgraded to the testing versions unless you blacklist them (and then you'll need to keep up with them manually).

And efibootmgr has been in there since the 14.1 development cycle:

P8400 supports virtualisation and is 64 bit

Thanks you, I know.

But I have only 4GB memory, then I considered better to use 32 bits, to minimize memory consumption.

Not really sure if it is true 100%, but I have the bias that enter more things in the memory of a 32 bits, when you have (less than or) 4GB.

In other hand, I am a 32 bit die-harder, more than you imagine. And saying "die-harder", it is just some soft word to describe.

I am curious just try next time to do a cold reboot. There is a reason for this. Not a restart but a "shutdown -h now" .

This would point me in a direction.

Reason I say this I could reproduce on a old intel duo. I drug out of the closet. But doing a cold reboot after upgrade did not cause this issue.
let me know.
Waiting for it to freeze pushing it.

Put it in a boot loop.

I mean: leave it to bring up the desktop, then after several minutes, via an script ran on startup by desktop, order a reboot.

I think is the best way to test if your PC is stable or affected by this issue(s).

Just found this post about 4.14 regressions: https://lkml.org/lkml/2017/10/15/65

3 members found this post helpful.

I tested what suggested Drakeo: cold reboot.
I halted the system.
Cold boot one: ok
Halt the system.
Cold boot two: see the photos, something new
- stall a long time on : [drm] RC6 on
- stall a long time on USB: disconnect
- then segfaulted

There is no improvement since kernel-4.14.0, in my humble opinion, it's even getting worse (?).

nota1: sent from slackware-14.2 with kernel-4.9.67 (rock stable).
nota2: filed a bug on bugzilla.kernel.org: https://bugzilla.kernel.org/show_bug.cgi?id=198091

Attached Thumbnails

   

1 members found this post helpful.

Worry not, I feel that everything will be fixed until x.y.10, which usually was adopted in the past.

I wonder why...

I propose to all you guys, up to our BDFL: lets take a break and to leave the Kernel guys to do their job, until at least the 4.14.10 is released. You know, just like was in the past.

We can test other things meantime, you know?

2 members found this post helpful.

Like Plasma 5

2 members found this post helpful.

The linux kernel will need to use PAE to address more than about 3GB of memory in practice (try running 'free' with PAE turned off and you will see some of your 4GB disappear). That doesn't mean that a binary with 32-bit pointers might not run faster than a binary of the same program with 64-bit pointers, but using 4GB as your cut-off is somewhat arbitrary.

1 members found this post helpful.

When kernel-4.9 has ready i have posted:

https://www.linuxquestions.org/quest...ml#post5651338

the problem was fixed when version 4.9.7 is out

https://www.linuxquestions.org/quest...ml#post5663540

2 members found this post helpful.

Ha ha! Why not?

BTW, I plan for this weekend to switch to Plasma5 in one of my computers, then to seriously try to add back enough KDE4 support for, well... I think there is no one who missed for what.