[06:29] <ryuo> I submitted a Ubuntu bug for a rather simple issue and haven't heard anything yet. Any ideas when someone will respond? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1862498
[06:52] <tjaalton> ryuo: you should send the patch upstream
[06:53] <ryuo> tjaalton: normally i would but i've been blown off before. last time i got more results by using an indirect channel.
[06:58] <tjaalton> so you're kinda asking others to do the work?
[07:01] <ryuo> to an extent, i guess. i already did a lot of the work devising my patch.
[07:01] <tjaalton> yeah but it would have to go upstream
[07:02] <ryuo> i know, but i'm a nobody. i would likely just get ignored like i have before.
[07:02] <ryuo> sigh.
[07:18] <tjaalton> so you've sent the patch to linux-input@vger.kernel.org?
[07:34] <ryuo> tjaalton: not this time  but last time i had a patch
[07:53] <ryuo> tjaalton: sent.
[07:55] <tjaalton> good
[07:55] <ryuo> though i expect to be summarily ignored like before.
[07:55] <tjaalton> properly git formatted?
[07:56] <ryuo> should be. i used git send-email
[07:56] <tjaalton> ok
[08:14] <apw> ryuo: add that info a link to the upstream submission to the bug
[08:15] <apw> makes it easier to find
[13:59] <FragginRight> i seem to be missing the dvb kernel headers on my 16.04 machine. how might i get them installed? i've been searching for a while now
[14:00] <FragginRight> my google fu seems to be failing me :)
[15:10] <cezary_zukowski> Does the newest (Out-of-memory) OOM killer supports cgroups?
[15:11] <cezary_zukowski> Hi :)
[15:26] <apw> i thought that oom was related to memory cgroups when in use; but one should really test it
[16:19] <cezary_zukowski> Okay, thanks.
[18:18] <nerdykid> Hi!  I need to have dkms copy a firmware file along with the compiled kernel module automatically.  My /usr/src/tn40xx-003/dkms.conf: https://pastebin.com/1VvuWYNf    I need dkms to copy /usr/src/tn40xx-003/x3310fw_0_3_4_0_9445.hdr to the same directory as the compiled .ko module.  Anyone know how to do this?
[20:54] <apw> nerdykid (N,BFTL), if the dkms package is packaged up in a .deb you do it in that .deb context.  here is an example worked though in our wiki https://wiki.ubuntu.com/kengyu/dh_dkms
[21:46] <chiluk> anyone else having issues with screen brightness on the 5.4 kernel+focal?
[21:47] <apw> chiluk, not me
[21:47] <chiluk> apw intel graphics?
[21:47] <apw> chiluk, yep
[21:47] <sforshee> me neither, and yes intel graphics
[21:47] <chiluk> I'm completely unclear what software stack is involved in making that happen.
[21:48] <sforshee> I don't think it's consistent, depends on the model
[21:48] <chiluk> it was working afair until moving to the 5.4... that being said a bunch of other things probably changed at the same time as well.
[21:49] <chiluk> also good to see you guys are still kicking.
[21:49] <sforshee> chiluk: look at /sys/class/backlight, should point you to your driver I think
[21:49] <sforshee> not dead yet ;-)
[21:50] <chiluk> yep intel_backlight
[21:51] <sforshee> mine too
[21:51] <tyhicks> chiluk, sforshee: I'm having screen brightness issues - reported in bug #1861521
[21:51] <tyhicks> I'm hoping to spend some time on that bug in the next couple days
[21:51] <tyhicks> intel_backlight for me, too
[21:51] <chiluk> hey hey .. another old name..
[21:51] <tyhicks> hey chiluk :)
[21:52] <chiluk> although I'm ona dell over here.
[21:53] <tyhicks> chiluk: any chance you have a screen with a built-in privacy filter?
[21:53] <tyhicks> the hp_wmi warnings I pasted into the bug are likely not related so we still could be seeing the same issue
[21:53] <chiluk> I do not but it is a touch screen.
[21:53] <sforshee> I have a dell and a lenovo which are both working with intel_backlight
[21:54] <chiluk> I'm on a inspiron 5540 which is a i9-9880H generation.
[21:54] <chiluk> could be a generational thing.
[21:54] <chiluk> sforshee I'm calling your shit old.
[21:54] <chiluk> ;)
[21:55] <chiluk> tyhicks how new is that?
[21:55] <tyhicks> $ glxinfo | grep Device Device: Mesa DRI Intel(R) UHD Graphics 620 (Kabylake GT2)  (0x5917)
[21:55] <tyhicks> bah
[21:55] <tyhicks> bad paste
[21:55] <sforshee> my dell is old, xps 13 with an i5-5200U
[21:55] <sforshee> but my lenovo is brand spanking new, i7-10510U
[21:55] <tyhicks> chiluk: glxinfo shows "Device: Mesa DRI Intel(R) UHD Graphics 620 (Kabylake GT2)  (0x5917)"
[21:56] <chiluk> t$ glxinfo | grep Device
[21:56] <chiluk>     Device: Mesa DRI Intel(R) UHD Graphics 630 (Coffeelake 3x8 GT2)  (0x3e9b)
[21:56] <tyhicks> so I'm gen9 according to https://en.wikipedia.org/wiki/List_of_Intel_graphics_processing_units#Gen9
[21:57] <sforshee> Device: Mesa DRI Intel(R) UHD Graphics (Comet Lake 3x8 GT2)  (0x9b41)
[21:57] <tyhicks> same gen9 for chiluk 
[21:57] <sforshee> so maybe a gen 9 thing, I've got gen 10
[21:57] <tyhicks> I've got another gen9 I can test with, too
[21:58] <chiluk> I'm going to quick check that the 5.3. kernel works 
[22:04] <chiluk> Yep 5.3 works.  Looks like a 5.4 regression.
[22:06] <tyhicks> my other gen9 works fine under 5.4.0-12-generic
[22:06] <tyhicks> Device: Mesa DRI Intel(R) HD Graphics 515 (Skylake GT2)  (0x191e)
[22:06] <tyhicks> it is also an HP
[22:06] <chiluk> nope ... that's a skylake carry-over gpu it looks like.
[22:07] <chiluk> probably gen 7 or 8 gpu..
[22:07] <tyhicks> skylake is gen9 gpu
[22:08] <tyhicks> the CPU is m5-6Y54
[22:09] <tyhicks> it is in that Gen9 table on wikipedia and there are a lot of references out there that say skylakes are the first gen9 gpu
[22:09] <chiluk> nope shares core bits with hd 530
[22:10] <chiluk> check code name column on wikipedia.
[22:10] <chiluk> it's a different sku than the hd 6xx we have
[22:10] <tyhicks> I'm not arguing that
[22:11] <tyhicks> I'm arguing that it is still a gen9
[22:11] <chiluk> I'm saying that it's older ... 
[22:12] <tyhicks> I'm actively working on another i915 bug, using that laptop, and am 100% sure that changes I make to gen9_init_indirectctx_bb() have an effect
[22:12] <chiluk> I bet sforshee 's 10510u has a newer gpu than either of us.
[22:12] <tyhicks> you're going to have to say something other than "nope" to convince me that it isn't a gen9 gpu :)
[22:12] <chiluk> well you know more than me at this point.. 
[22:13] <sforshee> yeah I guess it's actually a gen 11
[22:13] <chiluk> I  just started looking at this ..
[22:14] <tyhicks> well intel's mapping from model numbers to generations is confusing so I would take your word if I haven't been screwing with this other bug all day
[22:15] <tjaalton> skl, kbl, cfl, cml are all gen9
[22:15] <tjaalton> gpu
[22:15] <tjaalton> icl is gen11
[22:15] <tjaalton> gen10 (cnl, cannon lake) never really took off
[22:16] <chiluk> yeah ... you can't map based on cpu model number or even age..
[22:17] <tjaalton> cml and icl both have cpu models named after 10xxx
[22:17] <tjaalton> which is even more confusing
[22:21] <chiluk> sforshee should 1861521 be against linux-signed or linux-generic?  seems like linux-signed would only be used for secure boot issues.
[22:22] <sforshee> chiluk: yes not signed, the source package will be linux-5.4
[22:32] <tyhicks> sforshee: that's the source package that was ubuntu-bug picked for me
[22:36] <sforshee> tyhicks: good deal, thanks for letting me know
[22:38] <tyhicks> now that I think about it, I think I saw a bug report for that
[22:39] <tyhicks> no, it was related but different - bug #1861446
[22:41] <sforshee> tyhicks: huh, I wonder what mechanism is deciding that 'ubuntu-bug linux' should map to linux-signed-5.4
[22:42] <tyhicks> sforshee: I'm not sure - I was surprised that it mapped to anything *-5.4 so I figured it was intentional and correct
[22:43] <apw> sforshee, i think it is the other way, it is using uname -r to find the linux-image-<foo> package and mapping that to linux-signed-5.4 via apt-cache
[22:44] <sforshee> apw: ok, that sounds believable
[22:45] <tyhicks> so that means that https://bugs.launchpad.net/ubuntu/+source/linux-signed/+bugs?field.status:list=NEW is receiving reports but perhaps not being monitored
[22:46] <tyhicks> some others in https://bugs.launchpad.net/ubuntu/+source/linux-signed-5.4/+bugs?field.status:list=NEW as well
[22:46] <apw> sforshee, somewhere we have a bot which moves things to linux etc
[22:47] <aberrant> hi all
[22:47] <aberrant> can someone please give me some guidance around clock sources? I'm seeing extremely high drift with my eoan setup, clocksource is tsc. What recommendations do you all have?
[22:50] <aberrant> my options are tsc hpet acpi_pm 
[22:51] <apw> hmm, not sure i've seen anything like that; have you tried switching to hpet 
[22:54] <aberrant> I haven't yet
[22:54] <aberrant> my drift according to chrony is over 830 ppm
[22:55] <aberrant> that seems... really high.
[22:55] <aberrant> it's causing ntpd to fail, since the max drift is 500ppm
[22:55] <apw> tsc drift is often seen when an older kernel is run on very new kit which has new c-states for instance
[22:57] <aberrant> hpet is giving me 6ppm
[22:57] <aberrant> I'm not running an old kernel, though
[22:57] <aberrant> I'm running a custom one based on 5.0.x
[22:57] <aberrant> on an AMD 3400G
[22:58] <aberrant> but yeah, my guess is it's idle or c-states that's causing the tsc problem. Even though hpet is less efficient, I'll switch to using it.
[23:02] <aberrant> ok, rebooting to check if this works. Thanks.
[23:03] <chiluk> aberrant not sure if this is related..https://www.tomshardware.com/reviews/amd-ryzen-clock-bug-benchmark-scores,6312.html
[23:04] <chiluk> looks like ryzen had some clock bugs in general.
[23:05] <aberrant> perhaps, but I'm not OCing
[23:05] <aberrant> brb though - rebooting to make sure hpet is now default
[23:10] <aberrant_> ok, that worked
[23:11] <aberrant> hpet is the better option for keeping drift low.
[23:23] <aberrant> not sure whether the tsc drift is report-worthy, but I wouldn't even know what to put in the report.