08:25kualameyose: mhenning[d]: there is no problem to establish a connection with the radio in science such as encrypted one. Normally you'd have to position and have array of antennas in the controller to determine the first channel etc. It's slithly described here
08:25kualameyose: https://www.rohde-schwarz.com/nl/solutions/wireless-communications-testing/wireless-standards/bluetooth/bluetooth-direction-finding/bluetooth-direction-finding_251246.html, you can do anything in the driver, and waves characteristics cam be am pm or fm, frequency, phase, amplitude modulation, and attenuate is rounded to and it's uniform cause radio waves are faster than other moving
08:25kualameyose: objects, they uniformly go through the body normally, leaving a beautiful sequence, however it was a war in cambodia done to me, yes sometimes with interference lots of kinqy things happen not only package loss. Since bluetooth firware can be gotten from baseband oses like zephyr in open source ways, a real danger to get beamed to pass-out is there, when combined with my code. I had fun
08:25kualameyose: career in prgramming i enjoyed all the way dealing with those fabulous systems otherwise. And i lied that Laura Keskinen got beaten up, i do not know that, i actually suspect the old action she got beamed out of senses, that's popular punishment in cambodia, i warned her many times about that. So the vehicle needs some defense systems to be designed, so now it's that i gotta leave my own,
08:26kualameyose: sorry we can not publish my code, i have it otherwise in good shape probably.
11:24karolherbst: dwfreed: any suggestion how to get rid of an entire /18 subnet without adding like.. 64 akick entries?
11:27karolherbst: ohh wait, that one is simple
14:53dwfreed: karolherbst: IP bans take subnet masks
14:54karolherbst: ohh, so like *@123.123.123.123/18?
14:54dwfreed: yeah
14:54karolherbst: ahh cool
14:54karolherbst: luckily in this case it was an entire /16 I could remove, so it wasn't too bad, it just looked initially like /19 or something because it was fragmented but all belonged to the same company
18:10steel01[d]: A few notes about the minigbm impl, gfxstrand[d]
18:10steel01[d]: 1) It works via hidl, but gets texture errors via aidl. 0o Afaik, it should be requesting the same stuff, just over a different api. But we'll have to figure this out eventually.
18:10steel01[d]: 2) No, this does not fix the brokenness on gp10b. But since it doesn't happen with the gpu off, it's something to do with nouveau. But since it's not a regression, it's not likely a gralloc issue. Maybe kernel, clocks, who knows.
18:10steel01[d]: 3) This causes instability. I'm getting soft resets and full out kernel panics complaining about fencing. This is happening on both gm20b and gp10b. And did not happen with the dumb driver or swiftshader.
18:10steel01[d]: 4) I've got a lot more selinux avc's to deal with now. >< For some reason, just about everything is calling DRM_IOCTL_TEGRA_GET_SYNCPT now. And it's in the context of various apps, not the gralloc hal. Meh, I'll figure something out.
18:14gfxstrand[d]: steel01[d]: gp20b is TX2, right?
18:14steel01[d]: gp10b is tx2.
18:15steel01[d]: steel01[d]: See here for the brokenness I'm talking about.
18:16steel01[d]: The only thought that was had was that clocks were too low to keep up with rendering. But afaict, gpc is scaling properly. And it almost seems to get worse the higher the clock is.
18:18steel01[d]: I spent some time in the nvgpu code trying to figure out reclocking. And afaict, the only thing it touches is gpcclk, then bpmp does everything else. That's for everything newer too, should we ever get those running.
18:28steel01[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1431710911852183733/stacktrace.txt?ex=68fe6831&is=68fd16b1&hm=99ded2b17646eeada25958c5b17c18ae0033386bc6570d96991b17b7353e4cd9&
18:28steel01[d]: Got a copy of the kernel panic trace. This was on tx2.
18:34gfxstrand[d]: The synchronization issues are not likely because we NGL doesn't support the Android fence sync extension. Next step really is NVK.
18:35steel01[d]: You think the tx2 broken rendering could be a sync issue?
18:35gfxstrand[d]: As for syncpt, I have no idea why anyone except drmhwc is talking to Tegra.
18:36gfxstrand[d]: steel01[d]: Is it stable or does it flicker?
18:36steel01[d]: It moves. And flickers in and out.
18:36steel01[d]: It almost looks like a broken video mode. But the mode is fine.
18:37steel01[d]: If a static image is rendering, it's fine. But when something starts moving, it'll start doing stuff like that intermittently.
18:39gfxstrand[d]: That sounds like sync
18:39gfxstrand[d]: Or someone's not flushing a cache
18:41steel01[d]: Trying to grab a video. Sec.
18:42steel01[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1431714457570119840/2025-10-25_13-40-28.mkv?ex=68fe6b7e&is=68fd19fe&hm=599a781698144c4ef75b750eb71fdc1c93fcbc43edf6d2858937c54ad547f23a&
18:42steel01[d]: Not the best example, but you can see it when transitioning between apps.
18:44steel01[d]: It's weird that it happens on gp10b and not gm20b.
18:47steel01[d]: There's also an issue where tx2 and xavier render darker than they should. I think that's a tegra-drm issue with nvdisplay, the 'new' ip on t186 and t194. But I have no idea why. It happens for everything, even dumb buffer bit banging to the display hardware. So it's not a nouveau issue. That's why everything is hard to see in that recording.
19:44gfxstrand[d]: They probably added color profiles or something and they're not getting programmed correctly.
20:37steel01[d]: :sigh: Every update makes stuff worse.
20:37steel01[d]: error: extern blocks should be unsafe
20:37steel01[d]: --> src/compiler/rust/libcompiler.rlib.p/structured/bindings.rs:22208:1
20:37steel01[d]: |
20:37steel01[d]: 22208 | extern "C" {
20:37steel01[d]: | ^
20:37steel01[d]: | |
20:37steel01[d]: | _help: needs `unsafe` before the extern keyword: `unsafe`
20:37steel01[d]: | |
20:37steel01[d]: 22209 | | pub fn nir_unlower_io_to_vars(nir: *mut nir_shader, keep_intrinsics: bool) -> bool;
20:37steel01[d]: 22210 | | }
20:37steel01[d]: | |_^
20:37steel01[d]: |
20:37steel01[d]: = warning: this is accepted in the current edition (Rust 2021) but is a hard error in Rust 2024!
20:37steel01[d]: = note: for more information, see issue #123743 <https://github.com/rust-lang/rust/issues/123743>
20:37steel01[d]: error: aborting due to 625 previous errors
20:37steel01[d]: Rebased on 25.3-rc2 and rust is super unhappy again.
20:38steel01[d]: ../src/nouveau/compiler/nak_bindings.h:12:10: fatal error: 'xf86drm.h' file not found
20:38steel01[d]: New deps too, apparently.
21:10steel01[d]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36386
21:10steel01[d]: gfxstrand[d] This is what's causing the latter failure. How are C include paths supposed to be passed to rust?
21:13gfxstrand[d]: steel01[d]: I have a patch for that one but it requires bumping the rust version (it's a fairly late addition) so we haven't landed it.
21:14steel01[d]: Meh. So... that reads like 'nvk android is screwed now'.
21:15steel01[d]: It wasn't an error on 25.2.3, though.
21:27gfxstrand[d]: Pass `-Drust_std=2021` to meson
21:28gfxstrand[d]: It's fixable. I'm sure. Just need to bang on flags somewhere.
21:30gfxstrand[d]: steel01[d]: Uh... Might be missing an include in the meson somewhere.
21:31gfxstrand[d]: That's an error that'll never show up on a developer's machine because that header always gets installed to /usr/include
21:34steel01[d]: Docs say to add `-Dallow-fallback-for=libdrm` to the meson setup command, but that did nothing.
21:34gfxstrand[d]: steel01[d]: Bindgen calls in meson should be able to take dependencies and include flags. We just missed `dep_libdrm`
21:34steel01[d]: Mmm, I'll look.
21:36gfxstrand[d]: But yeah, if you see C nonsense in the rust parts, chances are it's a bindgen call in the meson
21:40gfxstrand[d]: For the unsafe extern thing, bindgen has support as of last December: https://github.com/rust-lang/rust-bindgen/pull/3015
21:42gfxstrand[d]: But you can also make it emit a `#![allow(unsafe_extern_blocks)]` with `--raw-line` to turn off the warning.
21:42steel01[d]: Mmm. Did mesa switch default version to rust 2024 in the 25.3 cycle?
21:42gfxstrand[d]: No
21:43gfxstrand[d]: But we added some lints
21:44steel01[d]: Mmm, something changed to turn that from an error to warning. Cause my android tree hasn't changed. I just rebased my fork from 25.2.3 to 25.3-rc2 and that extern thing became an error.
21:44steel01[d]: Unless that error gets ignored and isn't operable. Which would be... weird.
21:44steel01[d]: error: aborting due to 625 previous errors
21:44steel01[d]: It claims to be aborting due to that.
21:45gfxstrand[d]: You can also just disable some lints: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/meson.build?ref_type=heads#L806
21:45steel01[d]: But until I clear the libdrm error, suppose I can't know for sure that that's telling the truth.
21:45gfxstrand[d]: steel01[d]: That one's true
21:46steel01[d]: Setting the rust std to 2021 still prints the same bindgen errors, fwiw.
21:46gfxstrand[d]: Yeah, it's the lint. Just comment out all the 2024 lints
21:47gfxstrand[d]: steel01[d]: Okay, this one is weird. We definitely have libdrm in the deps: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/nouveau/compiler/meson.build?ref_type=heads#L79
21:50steel01[d]: It's in the general deps definitely. It's just not getting to rust or bindgen or whatever somehow. Once I get the extern spam out of the way, maybe I'll be able to see the initial bindgen command and see what's there.
21:51gfxstrand[d]: Yeah, it's in the deps so there should be a `-I` for it
21:51gfxstrand[d]: But bindgen seems eternally cursed
21:52steel01[d]: Mmm, I wonder. I'll have to double-check the clang args that had to be added on 25.2.3 for bindgen.
21:55steel01[d]: Just dropping externs from the lint list did clear the spam. So I can see the bindgen command now. Which... is like 400 lines long. :sigh: I'll be back in an hour once I can parse the thing. 🙄
22:04gfxstrand[d]: ðŸ˜
22:05steel01[d]: -I/home/buildbot/vc_960/lineage-23.0/external/libdrm/include/drm
22:05steel01[d]: -I/home/buildbot/vc_960/lineage-23.0/external/libdrm/android
22:05steel01[d]: -I/home/buildbot/vc_960/lineage-23.0/external/libdrm/include/drm
22:05steel01[d]: -I/home/buildbot/vc_960/lineage-23.0/external/libdrm/android
22:05steel01[d]: Mmm, without tearing the entire thing apart, I see this. But.
22:05steel01[d]: buildbot@vengeance:~/.../libdrm$ pwd
22:05steel01[d]: /home/buildbot/vc_960/lineage-23.0/external/libdrm
22:05steel01[d]: buildbot@vengeance:~/.../libdrm$ find . -name xf86drm.h
22:05steel01[d]: ./xf86drm.h
22:06steel01[d]: So it's adding subfolders, but not the top level, where this include is.
22:09steel01[d]: That may be pulled from libdrm_headers. Those are listed in `export_include_dirs`. The top level dir is exported via `export_system_include_dirs`. Not sure if something is magically converting the bp rules or if they'e hardcoded somewhere. I don't see `include/drm` in the meson build rules anyways.
22:21gfxstrand[d]: Include/drm is the kernel DRM headers, not libdrm.
22:22gfxstrand[d]: But I guess it might be coming from there? <a:shrug_anim:1096500513106841673>
22:23steel01[d]: I threw a hardcoded path at cross_mesa3d.mk and it looks to be getting further. Would be better to figure out how to make meson generate that directly, though.
22:24steel01[d]: Yeah, got it to finish building the vulkan hal. Meh. Cleaning some of this up is gonna be a pain.
22:32steel01[d]: Alright, kicking a full build. With tegra enabled in the nvk conformance check. Fireworks incoming, I'm sure.
23:41steel01[d]: 01-01 00:01:03.977 833 937 E vulkan : VkGetPhysicalDeviceImageFormatProperties2 for AHB usage failed: -11
23:41steel01[d]: Well, nvk+angle fails to render anything. I got this in the log once, even though the graphics stack is causing boot loops. The debug trace has:
23:41steel01[d]: 01-01 00:01:08.933 512 512 E [minigbm:nouveau_bo_create_for_modifier(666)]: Allocating new BO: 128x128, fourcc = AB24, size = 131072 domain = 0x4, pte_kind = 0xfe, tile_mode = 0x50, modifier = 0x300000000000015
23:41steel01[d]: 01-01 00:01:08.934 1000 1014 F RenderEngine: Failed to create a valid texture. [0xb400002b3b810530]:[128,128] isProtected:0 isWriteable:1 format:1
23:41steel01[d]: 01-01 00:01:08.934 1000 1014 F libc : Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 1014 (RenderEngine), pid 1000 (surfaceflinger)
23:41steel01[d]: But earlier allocs were fine, like:
23:41steel01[d]: 01-01 00:01:08.921 512 823 E [minigbm:nouveau_bo_create_for_modifier(666)]: Allocating new BO: 1920x1080, fourcc = AB24, size = 9830400 domain = 0x4, pte_kind = 0xfe, tile_mode = 0x50, modifier = 0x300000000000015
23:41steel01[d]: 01-01 00:01:08.926 512 512 E [minigbm:nouveau_bo_create_for_modifier(666)]: Allocating new BO: 1920x1080, fourcc = AB24, size = 9830400 domain = 0x4, pte_kind = 0xfe, tile_mode = 0x50, modifier = 0x300000000000015
23:46steel01[d]: I'm noticing that when it fails, it's on 128x128 surfaces, whereas the ones that worked were full screen 1920x1080. That matches what I've quoted here in earlier failures too. But then the following was fine on my tx1 devkit earlier today without vulkan:
23:46steel01[d]: 01-01 00:00:26.660 485 485 E [minigbm:nouveau_bo_create_for_modifier(666)]: Allocating new BO: 128x128, fourcc = AB24, size = 131072 domain = 0x4, pte_kind = 0xfe, tile_mode = 0x50, modifier = 0x300000000000015
23:46steel01[d]: 01-01 00:00:26.661 485 485 E [minigbm:nouveau_bo_create_for_modifier(666)]: Allocating new BO: 128x128, fourcc = AB4H, size = 262144 domain = 0x4, pte_kind = 0xfe, tile_mode = 0x50, modifier = 0x300000000000015
23:46steel01[d]: Not sure what's different.