[06:06] <lotuspsychje> good morning to all
[06:06] <lotuspsychje> anyone knows howto make apport import logs in case the kernel is HWE when filed against 'linux' and results to linux-signed-hwe-5.19 only 2 logs imported auto here
[06:07] <lotuspsychje> bug #2017955
[06:07] -ubottu:#ubuntu-kernel- Bug 2017955 in linux-signed-hwe-5.19 (Ubuntu) "Realtek Ethernet 8125 will disconnect randomly from Ethernet" [Undecided, New] https://launchpad.net/bugs/2017955
[06:20] <juergh> austin_: Looks like that patch will be submitted for upstream stable as well. Which means it should land in upstream 5.15 and then trickle down into our 5.15 kernels. So it should happen automatically, just takes time.
[06:20] <juergh> https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git/commit/?h=fix_ring_expansion&id=b4ebbfffe4e6440d2bbd3ed1e5ea9f60c0240cb3
[06:20] -ubottu:#ubuntu-kernel- Commit b4ebbff in kernel/git/mnyman/xhci.git "xhci: Fix incorrect tracking of free space on transfer rings fix_ring_expansion"
[08:12] <tomreyn> what lotuspsychje asks above is effectively a report that bugs reported (with apport) against "linux", if apport resolves it to a linux-signed-hwe-... package, do not seem to collect the right / enough logs (just Dependencies.txt + ProcCpuInfoMinimal.txt). is this something the kernel team can fix? does it need a bug report (against which package)?
[08:36] <lotuspsychje> yes thats it tomreyn tnx
[14:34] <juergh> A bug against the apport package would be good. I don't think what is collected is under the kernel's control.
[18:10] <ghavil> arighi: Hi, I finally got the https://kernel.ubuntu.com/~kernel-ppa/mainline/v6.3/amd64/ kernel setup on a box w/ cgroups v1 configured. Looks like the blkio throttle files only report 0's like I was seeing on 5.19. I'll put together a linux-kernel@vger.kernel.org email but, if you would like me to grab anything specific, I'm happy to do so 
[18:23] <arighi> ghavil, great! I also started to bisect the problem, but it's going to take a bit.. in the meantime I think you can send the email to the lkml (you can add me in in cc if you want - andrea.righi@canonical.com), I think there's clearly a behavior change and your test case should be clear enough
[18:23] <ghavil> arighi: I _just_ found https://lore.kernel.org/lkml/20230401094708.77631-1-hanjinke.666@bytedance.com/ which seems like it could be our issue here 
[18:24] <arighi> ghavil, ah! I could be that + the removal of the legacy io schedulers
[18:25] <ghavil> Do you think an email from me would still help or just add noise to the list?  
[18:25] <arighi> ghavil, that email looks like a potential fix, I can test it out
[18:25] <arighi> ghavil, let me do a quick test with that
[18:25] <ghavil> Sounds great, thanks again for all the help 
[18:36] <arighi> ghavil, so with that fix applied to the latest upstream kernel I can see the blkio stats in cgroupfs (v1)!
[18:37] <ghavil> \o/ 
[18:37] <arighi> ghavil, but only if I set some blkio.throttle limits, I don't remember if it was the same with 5.15
[18:37] <arighi> like if IO is unlimited it doesn't show any IO stats
[18:38] <ghavil> Hmmm, interesting, I don't think that's how it currently works. IIRC we have unlimited w/ 5.15 and still see metrics in those throttle files 
[18:38] <arighi> I need to do like `echo "8:0 100000000" > /sys/fs/cgroup/test/blkio.throttle.read_bps_device` and after that I can read the IO stats
[18:38] <ghavil> Oh maybe that's what Junke Han means in the commit with "But the current code only counts the bios that are actually throttled. When the user does not add the throttle limit, the io stats for cgroup v1 has nothing."
[18:42] <arighi> ghavil, I think so, it probably mimics io in cgroup2
[18:42] <arighi> that is still better than nothing
[18:42] <ghavil> Yeah, for sure 
[18:42] <arighi> but not a complete fix yet
[18:45] <arighi> ghavil, I'll do some tests with that fix applied (testing little changes), I'll keep you informed if I find a better fix for that
[18:45] <ghavil> Sounds fantastic, thanks again arighi 
[18:47] <arighi> ghavil, worst case scenario, we can SRU that fix and get that applied, then you could set insanely high limits to get the IO stats without triggering IO throttling (but ideally it'd be nice to find a proper fix)
[18:47] <ghavil> Ha yeah, I was just thinking the same thing 
[18:56] <arighi> ghavil, ok with the fix you found plus this extra fix (https://pastebin.ubuntu.com/p/WvWqqJf2rZ/) I am able to get the IO stats even without throttling limits configured \o/
[18:56] <arighi> I'll respond to the upstream thread to make sure this extra fix doesn't break something else :)
[18:57] <ghavil> That's excellent! 
[19:06] <arighi> ghavil, https://lore.kernel.org/lkml/ZEwY5Oo+5inO9UFf@righiandr-XPS-13-7390/ <- let's see what they say
[19:07] <ghavil> Great, I'll keep an eye on the thread and see where it goes