[06:29] 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:29] Ubuntu bug 1862498 in linux (Ubuntu) "Nuvision NES11 needs silead touchscreen quirks" [Undecided,Confirmed] === cpaelzer__ is now known as cpaelzer [06:52] ryuo: you should send the patch upstream [06:53] tjaalton: normally i would but i've been blown off before. last time i got more results by using an indirect channel. [06:58] so you're kinda asking others to do the work? [07:01] to an extent, i guess. i already did a lot of the work devising my patch. [07:01] yeah but it would have to go upstream [07:02] i know, but i'm a nobody. i would likely just get ignored like i have before. [07:02] sigh. [07:18] so you've sent the patch to linux-input@vger.kernel.org? [07:34] tjaalton: not this time but last time i had a patch [07:53] tjaalton: sent. [07:55] good [07:55] though i expect to be summarily ignored like before. [07:55] properly git formatted? [07:56] should be. i used git send-email [07:56] ok [08:14] ryuo: add that info a link to the upstream submission to the bug [08:15] makes it easier to find === cpaelzer__ is now known as cpaelzer [13:59] 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] my google fu seems to be failing me :) [15:10] Does the newest (Out-of-memory) OOM killer supports cgroups? [15:11] Hi :) [15:26] i thought that oom was related to memory cgroups when in use; but one should really test it [16:19] Okay, thanks. [18:18] 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? === ben_r_ is now known as ben_r [20:54] 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] anyone else having issues with screen brightness on the 5.4 kernel+focal? [21:47] chiluk, not me [21:47] apw intel graphics? [21:47] chiluk, yep [21:47] me neither, and yes intel graphics [21:47] I'm completely unclear what software stack is involved in making that happen. [21:48] I don't think it's consistent, depends on the model [21:48] 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] also good to see you guys are still kicking. [21:49] chiluk: look at /sys/class/backlight, should point you to your driver I think [21:49] not dead yet ;-) [21:50] yep intel_backlight [21:51] mine too [21:51] chiluk, sforshee: I'm having screen brightness issues - reported in bug #1861521 [21:51] bug 1861521 in linux-signed-5.4 (Ubuntu) "[FOCAL][REGRESSION] HP EliteBook 840 G5 screen brightness cannot be controlled" [Medium,Confirmed] https://launchpad.net/bugs/1861521 [21:51] I'm hoping to spend some time on that bug in the next couple days [21:51] intel_backlight for me, too [21:51] hey hey .. another old name.. [21:51] hey chiluk :) [21:52] although I'm ona dell over here. [21:53] chiluk: any chance you have a screen with a built-in privacy filter? [21:53] the hp_wmi warnings I pasted into the bug are likely not related so we still could be seeing the same issue [21:53] I do not but it is a touch screen. [21:53] I have a dell and a lenovo which are both working with intel_backlight [21:54] I'm on a inspiron 5540 which is a i9-9880H generation. [21:54] could be a generational thing. [21:54] sforshee I'm calling your shit old. [21:54] ;) [21:55] tyhicks how new is that? [21:55] $ glxinfo | grep Device Device: Mesa DRI Intel(R) UHD Graphics 620 (Kabylake GT2) (0x5917) [21:55] bah [21:55] bad paste [21:55] my dell is old, xps 13 with an i5-5200U [21:55] but my lenovo is brand spanking new, i7-10510U [21:55] chiluk: glxinfo shows "Device: Mesa DRI Intel(R) UHD Graphics 620 (Kabylake GT2) (0x5917)" [21:56] t$ glxinfo | grep Device [21:56] Device: Mesa DRI Intel(R) UHD Graphics 630 (Coffeelake 3x8 GT2) (0x3e9b) [21:56] so I'm gen9 according to https://en.wikipedia.org/wiki/List_of_Intel_graphics_processing_units#Gen9 [21:57] Device: Mesa DRI Intel(R) UHD Graphics (Comet Lake 3x8 GT2) (0x9b41) [21:57] same gen9 for chiluk [21:57] so maybe a gen 9 thing, I've got gen 10 [21:57] I've got another gen9 I can test with, too [21:58] I'm going to quick check that the 5.3. kernel works [22:04] Yep 5.3 works. Looks like a 5.4 regression. [22:06] my other gen9 works fine under 5.4.0-12-generic [22:06] Device: Mesa DRI Intel(R) HD Graphics 515 (Skylake GT2) (0x191e) [22:06] it is also an HP [22:06] nope ... that's a skylake carry-over gpu it looks like. [22:07] probably gen 7 or 8 gpu.. [22:07] skylake is gen9 gpu [22:08] the CPU is m5-6Y54 [22:09] 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] nope shares core bits with hd 530 [22:10] check code name column on wikipedia. [22:10] it's a different sku than the hd 6xx we have [22:10] I'm not arguing that [22:11] I'm arguing that it is still a gen9 [22:11] I'm saying that it's older ... [22:12] 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] I bet sforshee 's 10510u has a newer gpu than either of us. [22:12] you're going to have to say something other than "nope" to convince me that it isn't a gen9 gpu :) [22:12] well you know more than me at this point.. [22:13] yeah I guess it's actually a gen 11 [22:13] I just started looking at this .. [22:14] 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] skl, kbl, cfl, cml are all gen9 [22:15] gpu [22:15] icl is gen11 [22:15] gen10 (cnl, cannon lake) never really took off [22:16] yeah ... you can't map based on cpu model number or even age.. [22:17] cml and icl both have cpu models named after 10xxx [22:17] which is even more confusing [22:21] sforshee should 1861521 be against linux-signed or linux-generic? seems like linux-signed would only be used for secure boot issues. [22:22] chiluk: yes not signed, the source package will be linux-5.4 [22:32] sforshee: that's the source package that was ubuntu-bug picked for me [22:36] tyhicks: good deal, thanks for letting me know [22:38] now that I think about it, I think I saw a bug report for that [22:39] no, it was related but different - bug #1861446 [22:39] bug 1861446 in apport (Ubuntu Focal) "on focal 'ubuntu-bug linux' doesn't automatically collect kernel artifacts" [High,In progress] https://launchpad.net/bugs/1861446 [22:41] tyhicks: huh, I wonder what mechanism is deciding that 'ubuntu-bug linux' should map to linux-signed-5.4 [22:42] 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] sforshee, i think it is the other way, it is using uname -r to find the linux-image- package and mapping that to linux-signed-5.4 via apt-cache [22:44] apw: ok, that sounds believable [22:45] 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] some others in https://bugs.launchpad.net/ubuntu/+source/linux-signed-5.4/+bugs?field.status:list=NEW as well [22:46] sforshee, somewhere we have a bot which moves things to linux etc [22:47] hi all [22:47] 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] my options are tsc hpet acpi_pm [22:51] hmm, not sure i've seen anything like that; have you tried switching to hpet [22:54] I haven't yet [22:54] my drift according to chrony is over 830 ppm [22:55] that seems... really high. [22:55] it's causing ntpd to fail, since the max drift is 500ppm [22:55] tsc drift is often seen when an older kernel is run on very new kit which has new c-states for instance [22:57] hpet is giving me 6ppm [22:57] I'm not running an old kernel, though [22:57] I'm running a custom one based on 5.0.x [22:57] on an AMD 3400G [22:58] 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] ok, rebooting to check if this works. Thanks. [23:03] aberrant not sure if this is related..https://www.tomshardware.com/reviews/amd-ryzen-clock-bug-benchmark-scores,6312.html [23:04] looks like ryzen had some clock bugs in general. [23:05] perhaps, but I'm not OCing [23:05] brb though - rebooting to make sure hpet is now default [23:10] ok, that worked === aberrant_ is now known as aberrant [23:11] hpet is the better option for keeping drift low. [23:23] not sure whether the tsc drift is report-worthy, but I wouldn't even know what to put in the report.