00:00 <steev> what all arguments do you have?

00:01 <steev> fwiw, my command line looks like `pd_ignore_unused clk_ignore_unused net.ifnames=0 ipv6.disable=1 pcie_aspm.policy=powersupersave quiet splash`

00:06 <steev> but that sounds like maybe secureboot is still on?

00:08 <harvests[m]> I believe it's off, let me double check

00:10 <harvests[m]> One difference is I have /boot/efi/sc8280xp-lenovo-thinkpad-x13s.dtb from the debian installer guide but also /boot/efi/EFI/Armbian/grubaa64.efi and /boot/efi/BOOT/grubaa64.efi

00:13 <steev> maybe it's loading the armbian dtb and not the debian one?

00:14 <harvests[m]> how does your /boot/efi look? Should I delete the directory /boot/efi/EFI

00:26 <steev> i'm not using a pure debian setup; i installed mine back in the day with the modified iso

00:32 <harvests[m]> via the linaro guide?

00:36 <steev> yeah, from back when the support was VERY preliminary

00:39 <harvests[m]> I've done ironrobin's archiso with my own kernel, linaro debian and armbian haha

00:41 <harvests[m]> Removed armbian's dtb, hopefully that works

01:01 <LoganLeland[m]> that did not work haha

01:39 <adamcstephens> steev: thanks i audited the initrd kernel modules and was missing a couple. adding those and updating the order got me booted on 6.7rc8

01:48 <steev> \o/

02:30 <enyalios> when building a steev kernel with `make johan_defconfig`, the git commit gets appended to the kernel image name, is there any way to make it not do that so the name is more predictable?

02:41 <enyalios> oh maybe i just set CONFIG_LOCALVERSION_AUTO=n ?

02:45 <enyalios> yeah that seems to have worked

09:33 <ema> harvests[m]: in general it would be better to use a debian-only setup if possible, different combos of dtbs/grub/shims may lead to various problems

10:17 <agl> steev: I compile/install your kernel version 6.6.9 but my bluetooth mouse is not in the list of the bluetooth devices when I start your new kernel. Under kernel version 6.6.6 all works. kernel 6.6.9 have a new device tree file (.dtb) against 6.6.6. Is there a module necessary which is no enabled in the .config for kernel 6.6.6. I have used the kernel .config from 6.6.6!

10:26 <agl> steev: Shall I use the new johan_defconfig and to enable the modules which I need for USB-thethering ... and so on

10:38 <jglathe> @jhovold: yes, me waking up to a laptop with no wifi connection ;) Only diff is I didn't close the lid, which is SOP. But knowing this is nothing newly introduced since 6.7-rc6 is something.

10:42 <jhovold> agl: you probably need to update whatever script you use to set the Bluetooth device address in case steev decided to include that fix in his 6.6.9 branch

10:42 <jhovold> it should be set big-endiann order, but previsouly had to be set in reverse order

10:44 <jhovold> jglathe: got it, thanks for clarifying

11:57 <agl> jhovold: Thanks, after I entered the address in Big-Endiann order the bluetooth mouse works again.

13:52 <steev> enyalios: yeah, that's the config option, i always forget it when i try out his too :P

13:53 <steev> jhovold: yeah i do include it, fixes are fixes :P

13:53 <steev> but it's more so i don't have to swap them when i'm going between stable and rcs

13:57 <jhovold> steev: yeah, and I marked the fix for stable backport so it should end up there sooner or later anyway

14:02 <steev> adapter i'm using (with 2 usb-c cables to plug it in since the 2 ports are ever so slightly wider than a mac)

14:02 <steev> jhovold: is there a "fix" for the internal display not waking up when some external displays are connected? https://paste.debian.net/1302913/ is what i see in the logs, though, oddly, that seems to occur *as* the suspend/sleep is happening - i can disconnect and that wakes up the internal display, however, plugging the adapter back in, the external display doesn't come back until a reboot; https://www.amazon.com/dp/B07PFNV82M is the

14:03 <steev> blergh, actually it looks like flipping it over fixes it

14:32 <jglathe_> whut... haven't had a case where the orientation mattered yet

14:43 <steev> today you learned :)

14:43 <steev> yes orientation can matter

15:14 <jhovold> steev: are you saying that the external display problem goes away if you flip the usb-c connector?

15:15 <jhovold> and no, there

15:15 <jhovold> is no fix yet for that

15:18 <jglathe_> hardware

15:21 <steev> on that one, yeah, more specifically when waking up from sleep

15:21 <steev> because if i then unplug it and plug it back in, the external display does *not* get a signal

15:21 <steev> the computer sees it there, the monitor reports no signal

15:46 <jhovold> steev: that is a known issue with the drm driver as I mentioned, I've asked lumag to look into it

15:46 <jhovold> have not noticed that flipping the cable would make any difference though

15:49 <jhovold> just tested here too, and the usb-c orientation does not seem to make any difference, all display are gone after suspending with external display connected

16:11 <steev> what happened here with that dock was, switching the orientation, the internal display came back when i unplugged it, external display came back when plugging it in, however, unplugged then, and plugged back in, the monitor says no signal, but as i said, the system sees it

16:14 <jhovold> yeah, there are ways to get the display back, reconnecting from a VT terminal for example, I just don't want to spend any time more time on that since we need to get this fixed properly in the drm driver anyway

16:16 <jhovold> and lumag has looked at the relevant code in the past so should hopefully be able to track it down quickly, if he can find the time

16:31 <jglathe> running 6.7-rc8 now on the x13s https://github.com/jglathe/linux_ms_dev_kit/pull/new/jg/wdk2023-gunyah-6.7-rc8

17:46 <craftyguy> every so often ath11k on the x13s goes off into the weeds, I have to reload the driver to get wifi back: https://bpa.st/7ZZQ

17:46 <craftyguy> anyone else seeing that?

17:46 <steev> i do not see it here

17:47 <steev> something someone suggested was disabling powersave

17:47 <craftyguy> yeah, probably me lol

17:47 <craftyguy> (I have powersave disabled, to work around another issue I see)

17:51 <jglathe> I have balanced mode

17:55 <craftyguy> what is balanced mode?

17:57 <jglathe> volterra is also on 6.7-rc8 now

18:07 <jglathe> https://drive.google.com/file/d/12GB2AQoq3lS0Vsp7khr6ZtanJskI3ogw/view?usp=drive_link

18:50 <dgilmore> craftyguy: If the system tries to suspend here wifi gets angry, and often drops out. I have taken to just turning the system off when not actively being used

19:02 <craftyguy> ya in my case, it wasn't suspended, just sitting idly over night (doesn't happen all the time, but it has a few times over the last few weeks)

19:11 <steev> mine sits idly every night :(

19:15 <robclark> I hadn't seen fail-to-suspend issues until recently.. and not even correlated with switching kernels.. I've rebooted since, so we'll see if that resolved the issue

21:13 <jglathe> new device (for me) tested: GeneralPlus USB Audio Device idVendor=1b3f, idProduct=2008, bcdDevice= 1.00 HAma USB-C to 3.5mm audio jack

21:13 <jglathe> working nicely, can do quite good levels

21:14 <jglathe> need to do mic yet

21:15 <jglathe> All my USB headsets are headsets, so this is an improvement until soundwire over DP works

21:15 <jglathe> I meant BT or USB, but it's mono

21:39 <konradybcio> jglathe: what's the WARN here? https://github.com/jglathe/linux_ms_dev_kit/commit/0876b25a350e28b96180e986104af49bc542a8cd

21:43 <jglathe> clock for pcie3a is stuck on disabled for volterra. My workaround was to make enabling it controllable. Works nicely since then. Only caveat IMO is that you need to duplicate the clock control structs (and keep them up to date) because they are all static. I would prefer to create them dynamically.

21:46 <jglathe> the WARN comes from qcom_cc_really_probe()

21:47 <jglathe> drivers/clk/qcom/common.c

21:50 <konradybcio> is anything attached to this bus?

21:50 <jglathe> nope

21:50 <jglathe> I guess

21:51 <jglathe> still don't know why they clamp the thing down hard

21:51 <konradybcio> which clock exactly this is?

21:52 <jglathe> I see this here: [ 31.709268] VCC3B_WAN: disabling

21:52 <jglathe> volterra still runs

21:53 <konradybcio> this means the VCC3B_WAN regulator (presumably you copypasted this from another device as it's for the 5g modem) is being disabled as linux doesn't see any consumers attached to it

21:53 <jglathe> right, I assumed

21:53 <steev> that's WAN not WARN

21:54 <jglathe> oh the other is WARN with stack dump and whatnot

21:54 <konradybcio> that WARN has the clock name

21:58 <jglathe> in sc8280xp.dtsi (a place I didn't want to edit): https://drive.google.com/file/d/1qdSeULarM2TBUcwvPEqPcTctLsxJg0WL/view?usp=drive_link

21:58 <jglathe> Haven't seen that WARN since July 16 :)

21:59 <jglathe> would need to provoke it, tomorrow

22:04 <konradybcio> you didn't make that file public

22:04 <jglathe> oh sorry

22:04 <jglathe> I hate GD

22:05 <jglathe> should be now

22:06 <konradybcio> that.. doesn't tell me a whole lot

22:06 <konradybcio> the WARN you see in dmesg would be in the form of "clkname is stuck at 'off'"

22:08 <jglathe> I'm sorry again. The direct answer to your question will be the dmesg part of the WARN after I set pcie_3a_disabled to 0 in my dts, recompiled and rebooted on volterra. Tomorrow.

22:10 <jglathe> I actually didn't care which clock it was, it needs to be not set when bringing up the sc8280xp in Volterra config

22:16 <jglathe> found a picture of it on my phone ^^ https://drive.google.com/file/d/1_2XNEsmnLYmkMKgU_wDdgFhg0KnWE5Qo/view?usp=sharing

23:26 <konradybcio> gdsc is an inside-soc component, it's totally not hardware dependent

23:27 <konradybcio> is this reproducable on the current -next?

23:27 <konradybcio> is this reproducible with the upstream defconfig?