01:43 mhenning[d]: You're building an aur package?
01:44 mhenning[d]: you might need to delete both the downloaded repo and the checkout, so both the `mesa` and `src` folders
01:45 mhenning[d]: there might also be a way to recover the git repo eg `git remote prune` or something
10:08 Jaymoniepayday[m]: 🗣 We pay consistently, enjoy your services with us☑️.... (full message at <https://matrix.org/oftc/media/v1/media/download/AQWvgRGEg40ErMzhFQo-AkXf9T4-4H7vmNOkVdMAX7-3tIdsyw-O3IrzVdoZISvLwFz-8SQVEKhPvwcZQIDubbdCeYakEaFQAG1hdHJpeC5vcmcveEREUlZSQ0Fpd2lqdUlRa2VLTGhyakFF>)
10:08 chikuwad[d]: :sigh:
10:10 pixelcluster[d]: HEY EVERY !
10:10 chikuwad[d]: hi pixel
10:25 ermine1716[d]: Hello cluster
10:41 karolherbst: dwfreed: some matrix spam account ^^
12:09 gfxstrand[d]: pixelcluster[d]: Hey!
12:10 pixelcluster[d]: hi lol i think the original context is missing now
12:10 pixelcluster[d]: there was some spam message from matrix in response to which i imitated Spamton from deltarune
13:04 marysaka[d]: Before I forget to ask, I was looking with mohamexiety[d] at reviving patches for bigger pages a bit and I have a few questions:
13:04 marysaka[d]: - Is there any reasons we do not report large and huge pages as VMM_PAGE_HOST on Turing+ at the very least? That would on `domain=VRAM | GART` case allow bigger page size with minimal changes
13:04 marysaka[d]: - On Turing+, what is considered "MAPPABLE" on the host in general when we select VRAM as a domain? would I be wrong to assume large and huge page to be mappable? (as per suggested by skeggsb9778 here https://discord.com/channels/1033216351990456371/1034184951790305330/1344118504424607785
14:45 weechat11k: https://filehost.0bin.xyz/FgyiRqcs4b20.zip
14:52 magic_rb[d]: Not sketchy at all
15:03 karolherbst[d]: yeah.. I banned them from a couple of channels now
16:34 phomes_[d]: I occasionally get a hang in gnome-shell with nvk/zink. Happens once or twice per day. Typically if I watch youtube in firefox.
16:34 phomes_[d]: dmesg contains this:
16:34 phomes_[d]: `kernel: nouveau 0000:01:00.0: gnome-shell[6837]: job timeout, channel 10 killed!
16:34 phomes_[d]: gnome-shell[6837]: MESA: error: ZINK: vkQueueSubmit failed (VK_ERROR_DEVICE_LOST)
16:34 phomes_[d]: kernel: workqueue: drm_fb_helper_damage_work hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND
16:34 phomes_[d]: kernel: workqueue: drm_fb_helper_damage_work hogged CPU for >10000us 5 times, consider switching to WQ_UNBOUND`
16:34 phomes_[d]: I can go to a different tty but if I go back the screen is all artifacts.
16:34 phomes_[d]: Anyone else hitting this?
18:06 gfxstrand[d]: Do you always see the work queue messages with it?
18:33 phomes_[d]: at least the last two times. I have not looked carefully before
20:00 gfxstrand[d]: Keep an eye on it. If it's consistent it could provide a clue as to what's going on.
20:01 gfxstrand[d]: Or it could be unrelated
21:25 kar1m0[d]: Has anyone tried to reverse engineer NVML?
21:44 avhe[d]: i have a bit
21:45 avhe[d]: it's not a very interesting library, it's basically a simple abstraction around a set of ioctls
21:46 kar1m0[d]: avhe[d]: I want to implement gpu info exposure through gsp for nouveau
21:47 kar1m0[d]: So that it will be shown during tests
21:47 kar1m0[d]: Like gpu usage vram usage watt usage
21:47 kar1m0[d]: Clock speed and etc
21:47 kar1m0[d]: So I thought that reverse engineering nvml might help me understand it more so that I can implement it
21:50 avhe[d]: most of that stuff is already known
21:51 avhe[d]: it goes through a block of shared memory called rusd (iirc there are also ways to directly query GSP but undocumented)
21:51 chikuwad[d]: I don't think nvml is relevant here though, since the goal is to pipe that data from the gsp to the hwmon interface
21:52 kar1m0[d]: Does it have to pass to hwmon?
21:52 kar1m0[d]: Or is it the only way to make it work for now?
21:52 chikuwad[d]: maybe the kernel side is helpful, but the userspace bits? not really
21:52 chikuwad[d]: kar1m0[d]: that's the standard interface in the kernel, yes
21:53 kar1m0[d]: I thought about directly accessing gsp tbh and then passing it to the drivers kernel
21:53 chikuwad[d]: I'm not aware of any upstream driver not exposing via hwmon
21:54 avhe[d]: https://discord.com/channels/1033216351990456371/1223647774575431771/1384860194638659635 relevant discussion
21:54 avhe[d]: fwiw this topic comes up like every other week so i recommend reading through logs of this server
21:55 kar1m0[d]: avhe[d]: My bad, I did plan to work on this like a month ago
21:59 airlied[d]: gfxstrand[d]: dma copy classes dropped