Hi,
the stable LTS linux kernels 6.6.102 and 6.12.42 have a regression regarding network interface monitoring with xosview and gkrellm. Both programs no longer show any network traffic with gkrellm even considering all network interfaces as being in down state. I haven't checked other LTS kernels so I cannot tell if there are more affected kernel branches.
I have bisected the issue to the commits 33c778ea0bd0fa62ff590497e72562ff90f82b13 in 6.6.102 and fc1072d934f687e1221d685cf1a49a5068318f34 in 6.12.42 which are both the same change code-wise (upstream commit ff7ec8dc1b646296f8d94c39339e8d3833d16c05).
Reverting these commits makes xosview and gkrellm "work" again as in they both show network traffic again.
Kind regards Lars Wendler
On Fri, Aug 15, 2025 at 07:56:16PM +0200, Lars Wendler wrote:
Hi,
the stable LTS linux kernels 6.6.102 and 6.12.42 have a regression regarding network interface monitoring with xosview and gkrellm. Both programs no longer show any network traffic with gkrellm even considering all network interfaces as being in down state. I haven't checked other LTS kernels so I cannot tell if there are more affected kernel branches.
I have bisected the issue to the commits 33c778ea0bd0fa62ff590497e72562ff90f82b13 in 6.6.102 and fc1072d934f687e1221d685cf1a49a5068318f34 in 6.12.42 which are both the same change code-wise (upstream commit ff7ec8dc1b646296f8d94c39339e8d3833d16c05).
Reverting these commits makes xosview and gkrellm "work" again as in they both show network traffic again.
Is this also an issue in 6.16.1 and 6.17-rc1?
thanks,
greg k-h
* Greg KH gregkh@linuxfoundation.org wrote:
I have bisected the issue to the commits 33c778ea0bd0fa62ff590497e72562ff90f82b13 in 6.6.102 and fc1072d934f687e1221d685cf1a49a5068318f34 in 6.12.42 which are both the same change code-wise (upstream commit ff7ec8dc1b646296f8d94c39339e8d3833d16c05).
Reverting these commits makes xosview and gkrellm "work" again as in they both show network traffic again.
Is this also an issue in 6.16.1 and 6.17-rc1?
I can confirm the issue with gkrellm on 6.16.1 (and 6.15.10 fwiw).
On Sun, Aug 17, 2025 at 03:43:29PM +0200, Markus Reichelt wrote:
- Greg KH gregkh@linuxfoundation.org wrote:
I have bisected the issue to the commits 33c778ea0bd0fa62ff590497e72562ff90f82b13 in 6.6.102 and fc1072d934f687e1221d685cf1a49a5068318f34 in 6.12.42 which are both the same change code-wise (upstream commit ff7ec8dc1b646296f8d94c39339e8d3833d16c05).
Reverting these commits makes xosview and gkrellm "work" again as in they both show network traffic again.
Is this also an issue in 6.16.1 and 6.17-rc1?
I can confirm the issue with gkrellm on 6.16.1 (and 6.15.10 fwiw).
Great, we are bug compatible!
Please work with the developers of those changes to resolve the regression in Linus's tree and then we can backport the needed fixes.
thanks,
greg k-h
Hi,
the stable LTS linux kernels 6.6.102 and 6.12.42 have a regression regarding network interface monitoring with xosview and gkrellm. Both programs no longer show any network traffic with gkrellm even considering all network interfaces as being in down state. I haven't checked other LTS kernels so I cannot tell if there are more affected kernel branches.
I have bisected the issue to the commits 33c778ea0bd0fa62ff590497e72562ff90f82b13 in 6.6.102 and fc1072d934f687e1221d685cf1a49a5068318f34 in 6.12.42 which are both the same change code-wise (upstream commit ff7ec8dc1b646296f8d94c39339e8d3833d16c05).
Reverting these commits makes xosview and gkrellm "work" again as in they both show network traffic again.
Kind regards Lars Wendler
Hi, Sorry for the delay, I have a rest on weekends. I think I get what happened. We should call pde_set_flags when create proc_dir_entry, and there has omission in net related proc file. I will fix it ASAP.
linux-stable-mirror@lists.linaro.org