From Newsgroup: alt.os.linux.slackware

My new PC had 96 GB RAM and now has 128 GB. Slackware-stable detects it. Slackware-current, and Slackware-current kernels on Slackware-stable,
partly don't, as below.

root@cosmos:~# free
total used free shared buff/cache available
Mem: 72 68 1 0
4 4
Swap: 232 26 206
root@cosmos:~# inxi --memory-modules
Memory:
System RAM: total: 128 GiB available: 72.72 GiB used: 66.82 GiB (91.9%)
Array-1: capacity: 256 GiB note: est. slots: 4 modules: 2
EC: Multi-bit ECC
Device-1: Channel-A DIMM 1 type: DDR5 size: 64 GiB speed: 5600 MT/s
Device-2: Channel-B DIMM 1 type: DDR5 size: 64 GiB speed: 5600 MT/s

The ProcPS 'free' program doesn't show it all, but inxi and most/all other hardware detection programs do. Didn't happen with Linux kernel v6.1 (on Slackware-stable, Devuan) but happens by Linux kernel v6.12 and all
newer. The ProcPS people told me it's a kernel issue. If that's it (and
not just a possible defect in new hardware) how do I go about reporting
this to the Linux kernel itself without being told it's not enough information. I said/asked all this in the official Slackware (LinuxQuestions.org) forum and just got various output, but not
suggestions what to do next. If it's the memory controller on my brand-
new GigaByte Aorus X870 Xtreme AI Top, how do I find that out... or is it
okay to report to kernel then they can say how to check that?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

David Chmelik <dchmelik@gmail.com> wrote:

The ProcPS people told me it's a kernel issue. If that's it (and
not just a possible defect in new hardware) how do I go about reporting
this to the Linux kernel itself without being told it's not enough >information.

You can find the change in kernel that is responsible for the issue. The instructions are here:

https://docs.kernel.org/admin-guide/bug-bisect.html

After you have found the offending commit, you can report it, for example, here:

https://bugzilla.kernel.org/
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On Sun, 30 Nov 2025 19:58:18 -0000 (UTC), Petri Kaukasoina wrote:

David Chmelik <dchmelik@gmail.com> wrote:

The ProcPS people told me it's a kernel issue. If that's it (and not
just a possible defect in new hardware) how do I go about reporting this
to the Linux kernel itself without being told it's not enough
information.

You can find the change in kernel that is responsible for the issue. The instructions are here:

https://docs.kernel.org/admin-guide/bug-bisect.html

After you have found the offending commit, you can report it, for
example,
here:

https://bugzilla.kernel.org/

Well, I only use normally-numbered long-term/stable/user, not hash-
numbered commit/experimental/testing versions, but I'll follow
instructions further up that guide.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

David Chmelik <someone@somewhere.com> wrote:

[...snip...]
Well, I only use normally-numbered long-term/stable/user,
not hash-numbered commit/experimental/testing versions,

I typically use -current, but your remark got me curious:
if, say, during the last 10 years I'd installed/re-installed
-current 100 times at random intervals, then how many times
would package bugs, that weren't present in -stable, have
caused "noticeable" (whatever that means) problems?
That is, what percentage of -current releases have
non-trivial problems not also present in -stable?
--
John Forkosh
--- Synchronet 3.21a-Linux NewsLink 1.2