no this setting has nothing to do with ext4 corruption. I still got fs corrupted event without this option turned on

1 members found this post helpful.

No fix for the BLK-MQ corruption (what they initially thought was EXT4) yet... hopefully in 4.19.8.

1 members found this post helpful.

This is the fix. Not yet in Linus tree. https://git.kernel.org/pub/scm/linux...a4727ea284661e

1 members found this post helpful.

Well then I'm corrected by an expert ). But why have a config directory that is specific for 14.2 and one that is specific for -current? It would be interesting to attempt a build using PV's config. There are significant differences between the two and I do know that the -current change log mentions some config settings specific for -current software while also (as posted by cwizardone) to avoid some issues others are experiencing. Of course 4.19.5 is running so much better than 4.4.165 that maybe it should be left alone, or maybe that generic 14.2 config is better than PV's? ;-) I'll have to do a lot of investigation into the differences and see if anything would correct a potential issue or improve performance before changing.

1 members found this post helpful.

Are you talking on official mirrors (because dusk keeps all the configs in a single directory)? If so, it is because they both need their own source tree and the configs are different based on the kernel version you're building. A 4.4 config shouldn't be used to build a 4.19 kernel, just as a 4.19 config shouldn't be used to build a 4.4 kernel.

I've used -current configs for years while I've been a version or two behind on stable releases. In fact, I'm running his 4.19.4 config on my 4.19.5 kernel on 14.2 and not running into any problems. In fact, many times in the past I'd use the actual kernels provided on -current on older versions of Slackware. I've heard that due to the gcc bump between 14.2 and -current, this could cause problems, so I've built my own kernels this time.

I can't think of anything that would affect software, except to possibly enable some features. Like adding F2FS and tweaking the installer allows devices to be formatted as F2FS.

Are you talking about using the generic 14.2 config to build the 4.19 kernel? If so, that is likely to cause all sorts of problems since configs generally won't match from one kernel version to another (this is why you're supposed to run make oldconfig when using an older config to find the changes and get them adjusted).

1 members found this post helpful.

I'm using the one from current and all seems to be fine on my 14.2 32bit.

Have you had to build any kernel modules? That is what I heard was going to cause problems if you used the kernel packages from -current on 14.2. I think someone specifically said they had issues with building virtualbox modules.

I've used kernels from -current quite a bit in the past, but when I read that, I decided I'd just build it myself. It doesn't take too long on my machine and I was too lazy to take the time and test whether or not kernel modules could be compiled on the -current packages.

We should probably let dusk speak to this, but there are separate configs at the site for 14.2 and current. Not sure why, there just are. Agreed, which is why I went in hunt of someone who had a 14.2 Slackware with a 4.19.y config. Dusk's repository fit that criteria.


Nice to know then that PV's config's should not cause harm to your hardware configuration. However, I've also read that it is quite dangerous to simply take -current kernel binaries from -current and attempt to run them under stable, because the gcc must be of the same release as the running gcc. Which I see you confirm in the next statement. I read the same concern, which is why I went looking for a 14.2 (old gcc) config of 4.19.y as a starting point.

No that is not what I was explaining. My original statement, simple went through the steps of AlienBob's slackdoc article of building a kernel. The make oldconfig step wouldn't have had any effect since make oldconfig looks at the .config in the source folder (created with the zcat /proc/config.gz > /usr/src/linux/.config command) and uses it to make a config. Since I didn't do that step and instead placed the config from Dusk's repository in the source folder then that 4.19.y config was used to make .config. I was careful to explain that I started with a 4.19.y config not the running config on the PC (since it was 4.4.y based). @birdboy's question was legitimate to ask, since AlienBob's article says to acquire the config from the /source/k/config-generic-smp-x.x.y, but again that was with a different gcc and had -current's changelog read as if one shouldn't do that due to newer features being turned on which aren't available from stables software packages.
Hope this better explains the steps I used.

@bassmadrigal, thanks for joining the conversation about how to build a 4.19.y kernel for stable. Your experience and advice are always appreciated by those of us who are still novice kernel builders.

I am wondering if you're mixing up a config with a kernel package. The configs are interchangeable between various versions of Slackware and are strictly the options used to compile the kernel. You can use a 4.19 config to compile a kernel on 13.1, 14.2, and -current without issue (although, I suppose it's possible the software in the 13.1 version are too old to compile a 4.19 kernel, but I imagine it would still work). The configs don't change based on the gcc version of Slackware. The configs adjust hardware support and low-level kernel details and are unaffected by gcc versions installed. The binary output once compiled may be different, but the configs are the same.

Dusk keeps all kernel configs in a single directory. The kernels were able to be used in 14.2 or -current and allowed some -current users to keep more modern kernels than what was shipped in -current at the time... since Pat tends to stick with the LTS kernels, -current was on 4.9, 4.14, and now 4.19 -- when the upcoming 4.20 comes out, Pat likely won't add it to -current, so it will likely be available on dusk for -current (and 14.2) users to use.

As for using -current kernels on older versions of Slackware, normally this isn't an issue, but it's been stated (actually earlier in this thread) that due to the changes with gcc that it may break trying to compile 3rd-party kernel modules. But I haven't verified this. Since I know I haven't had problems with this in the past, if it is truly an issue, I'm guessing it has to do with the massive rebuild Slackware had back in Apr 2018, where they switched to a new C++ ABI. I suppose that could cause breakage and I was too lazy to test it on my machine to find out.

It is normally not good to take packages from -current and use it on 14.2, not just because of gcc changes, but also due to changes in libraries that may break software. But just like how you can take the source from -current and compile it on 14.2, you can take the configs from the kernel in -current and use it to compile a kernel on 14.2.

Hopefully this cleared it up a bit. I know it can be confusing as you're trying to make heads or tails of these things.

Nope.


My mistake, I remembered them being by package in that directory, obviously they aren't.

Thanks again. Cheers, BrianA_MN

Looks like the fix will be in the 4.19.8 update,

https://www.phoronix.com/scan.php?pa....20-BLK-MQ-Fix

The full article is at the above link.

Yes, blk-mq-fix-corruption-with-direct-issue.patch is already in Greg K-H's queue for 4.19-stable patches.

1 members found this post helpful.

I hope they get 4.19.8 out ASAP...

1 members found this post helpful.

Looks like 4.19.8 will be released Saturday morning, depending on your time zone.

What do you mean? .config is compiler independent. when you open it .config just list available compiler. In fact I used .config-4.13.11 to built 4.19.7 kernel.

After saving, run diff and all new options added will pop up and old options not used anymore will wanish. Then deselect what you don't need or enable more options.

.config is just editable file that lets you change some options (using proper editor), but not all. It does not depend on gcc (what you see in the editor is information regarding available (not required) compiler.

Personally I prefer to build my own kernel because it is optimized for my hardware, and I can avoid potential issues during kernel upgrade. Long time ago it was a way to learn a bit about linux. Running someone else's config will not teach anything.
Building kernels like Slackware default or DUSK is more difficult as it has to fit all possible system configs.

However claiming after few hours after installation that "kernel runs fine" is not more informative that stating that kernel boots.

I wish linux had similar facility as BSD's that is last good kernel is automatically backed up and in the case of new kernel failure one can easily boot system again from the old working kernel. Unfortunately it seems that this would be more difficult to automate in comparison to BSD (or Solaris)