Created attachment 305716 [details] Kernel config and „dmesg” output done from within 6.1.28 What more can I say? Exactly like in the subject. Slackware64 15.0 Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz
I forgot: there is also one more thing that looks somewhat strange: starting from 4.19.282 I noticed the kernel file gained „bss” section; here's how it looks in case of 304: size bzImage size: bzImage: warning: ignoring section flag IMAGE_SCN_MEM_NOT_PAGED in section .bss text data bss dec hex filename 7971136 0 15236288 23207424 1621e00 bzImage So bzip2-compressed kernel file now is over 2 MB larger than it usually used to be. For comparison how it looks in case of 6.1.72 kernel file: size bzImage text data bss dec hex filename 5979840 0 0 5979840 5b3ec0 bzImage „bss” part is empty here, as it should be. Not sure: has it been introduced with some new revision of 4.19.x (somewhere around 282), or some kernel option that I switched by accident is responsible?
Today compiled newest in the line, I mean 4.19.305 — both problems are still present. No change.
Barely anyone nowadays actively uses this kernel. Your best bet will be to bisect. https://docs.kernel.org/admin-guide/bug-bisect.html
1. I'd like to point your attention, that 4.19.x is „longterm” kernel, according to kernel.org. 2. What about that huge BSS section — what is causing that? I have nothing like that in 6.x kernel (and IIRC I never had that in compiled kernels), and according to „Kernel Size Tuning Guide”: „BSS segment is not stored in the kernel image because it can be synthesized at boot time by filling a block of memory with zeros”. Which driver/option is to blame and should be switched off?
I made an attempt with building the kernel using „make allnoconfig” — it seems that the BSS appears immediately after switching from 32-bit to 64-bit. Why is that? What for?
(In reply to Zbigniew from comment #4) > 1. I'd like to point your attention, that 4.19.x is „longterm” kernel, > according to kernel.org. > Then please also test current mainline (v6.7). > 2. What about that huge BSS section — what is causing that? I have nothing > like that in 6.x kernel (and IIRC I never had that in compiled kernels), and > according to „Kernel Size Tuning Guide”: „BSS segment is not stored in the > kernel image because it can be synthesized at boot time by filling a block > of memory with zeros”. > > Which driver/option is to blame and should be switched off? You may want to try building kernel with localmodconfig configuration (see Documentation/admin-guide/quickly-build-trimmed-linux.rst in the kernel sources for how).
1. I have no issues with 6.7 kernel (maybe because I don't use it) — I reported problems with 4.19. 2. There is no such document like Documentation/admin-guide/quickly-build-trimmed-linux.rst anywhere in 4.19.305 kernel sources. 3. Even, if it was present — the question remains: why one can build (seemingly) proper kernel for 32-bit, while creating the kernel of the same configuration, but for 64-bit, requires (according to you) some extraordinary procedures right now? What did you do the kernel lines 4.19. x and 4.14.x that presently it's not possible to create proper 64-bit kernels from these lines „just like that”, but it requires some supposed „localmodconfig configuration”?
(In reply to Zbigniew from comment #7) > 1. I have no issues with 6.7 kernel (maybe because I don't use it) — I > reported problems with 4.19. > Then please bisect between v4.19.282 and v4.19.304. > 2. There is no such document like > Documentation/admin-guide/quickly-build-trimmed-linux.rst anywhere in > 4.19.305 kernel sources. > It is in v6.7.
(In reply to Bagas Sanjaya from comment #8) > (In reply to Zbigniew from comment #7) > > 1. I have no issues with 6.7 kernel (maybe because I don't use it) — I > > reported problems with 4.19. > > > > Then please bisect between v4.19.282 and v4.19.304. Oops, I don't know what last v4.19 stable kernel that don't have this regression. Can you spill it? Confused...
(In reply to Zbigniew from comment #4) > 1. I'd like to point your attention, that 4.19.x is „longterm” kernel, > according to kernel.org. > > 2. What about that huge BSS section — what is causing that? I have nothing > like that in 6.x kernel (and IIRC I never had that in compiled kernels), and > according to „Kernel Size Tuning Guide”: „BSS segment is not stored in the > kernel image because it can be synthesized at boot time by filling a block > of memory with zeros”. > > Which driver/option is to blame and should be switched off? You may point my attention to anything but no one owes you anything: you get Linux for free, you really wanna try your best to help the project in return. Please reopen once you've done bisecting and found the bad commit.
1. Why did you mark this as „resolved”? IT'S NOT „resolved” at all. Did you fix anything? Not at all — then why you marked this bug report as „resolved”? 2. Regarding to who owes whom anything — or not — anyone forced you to work on Linux kernel, when you obviously aren't willing to? 3. If you don't want to fix this — then just leave this report „as is” — but don't you lie, that you've „resolved” anything; YOU DID NOTHING.
Not a single kernel developer has seen this bug report. Please continue to demand. It will get you really far. I told you exactly how you can help yourself instead you chose to bicker. Have fun. Marking this as NEEDINFO because without git bisect no one in the universe will help you.
*** Bug 218405 has been marked as a duplicate of this bug. ***
What more info you need? What kind of info? I'm all ears.
(In reply to Zbigniew from comment #14) > What more info you need? What kind of info? I'm all ears. Check comment number 3. For simplicity, I'll just repost it: Barely anyone nowadays actively uses this kernel. Your best bet will be to bisect. https://docs.kernel.org/admin-guide/bug-bisect.html
1. OK, after a few next (unnecessary, as it turned out) bi-secting compilations I finally found a problem: I forgot to include module fscrypto.ko, required by ext4.ko in that earlier kernels. From what I remember, earlier kernels always issued warning in such case, and it was „fatal: unable to mount rootfs”. Then why this behaviour has been modified and present kernels are silent? I didn't recall it at first, since last time I made that mistake it was 3 or 4 years ago, and it wasn't that much of a problem, when there was clear warning (and even command shell available). So the actual bug to be fixed is to bring back that message in case rootfs cannot be mount (and command shell). I tested again 4.19.305 and 4.14.336 — yes, with fscrypto.ko module included there is no boot-related problem anymore. 2. Still there is a problem with oversized kernel file and unnecessary presence of BSS section there. So this has to be fixed, if standard compilation procedure „make bzImage modules modules_install” (which fortunately works with no problem for 6.x kernels) isn't „good enough”.
The ext4 driver does not require the fscrypto driver, it's down to your setup. Ext4 by itself has not idea how to work with encrypted files, so there can be no user-friendly error message. Most people use distro provided kernels and don't deal with this "quirk". I'm glad you got it fixed.
The point is: 1. I have NO encrypted files neither partition; nothing at all is encrypted on my HDD. 2. modules.dep clearly shows dependency: kernel/fs/ext4/ext4.ko.gz: kernel/lib/crc16.ko.gz kernel/fs/jbd2/jbd2.ko.gz kernel/fs/crypto/fscrypto.ko.gz
This kernel is barely supported or used, so even there's a regression which is unlikely since no one else has reported it, it's highly unlikely it's gonna be dealt with or fixed. Besides most distros compile ext4 in, vs. compiling it as a module.