00:45 AndrewR: hm ..Lokking at https://www.phoronix.com/scan.php?page=news_item&px=ROCm-3.7-OpenCL-Image and into https://github.com/RadeonOpenCompute/ROCR-Runtime/tree/master/src/image ... does this (existence of addrlib and device-specific files) indicate OpenCL image support IS device-dependent (as far as driver is concerned?)
00:51 bnieuwenhuizen: not sure how the driver handles it, but hardware-wise there are significant differences between generations
01:17 AndrewR: https://gitlab.freedesktop.org/awatry/mesa/-/commits/clover-image-support/ - I found it while looking at issue-130 (in mesa) on gitlab
01:34 AndrewR: (there is a lot of everything going on in mesa :} )
02:07 jekstrand: AndrewR: It is device-specific in the sense that every device lays out images differently. However it should, in theory, be able to be handled by clover via the same abstractions it uses for images in GL.
02:07 jekstrand: It requires a bit of work in the driver but not much.
02:07 jekstrand: Part of the problem is that clover handles images unnecessarily differently from storage images in GL.
02:08 jekstrand: There's some history there which others understand far better than me.
02:08 jekstrand: But, generally, it's not too bad.
05:34 shivam_: Hi, My name is Shivam Singh from IIEST Shibpu, India. I would like to participate in the X.org endless vacation of code. Can someone guide me on that?
06:02 AndrewR: jekstrand, thanks!
07:19 remexre: if an drmModeSetCrtc call I'm doing is returning EACCES, what're the first things I should check?
07:22 danvet_: robclark, yeah it's about making sure no one misplaces a kmalloc in some future changes because they forgot to force some shrinker load
07:55 MrCooper: karolherbst: which version of Xwayland?
07:56 MrCooper: remexre: sounds like the process isn't DRM master
07:58 remexre: MrCooper: oh, yep, you're right; now I'm getting an EINVAL, which is gonna be more annoying...
07:59 MrCooper: /sys/module/drm/parameters/debug might be helpful for that
08:01 remexre: will take a look, thanks
08:11 remexre: ah, I forgot I set the mode pointer to NULL to debug a thing; working now insofar as the screen is black instead of a kernel console
08:12 remexre: not working insofar as the actual drawing doesn't appear to hit the framebuffer, sigh; that's a tomorrow problem though
08:18 remexre: wait, never mind, just needed a glFlush()
08:19 remexre: cool, time to sleep for real; thanks again
09:09 xexaxo1: robclark: indeed sorry. if anyone has tips for the future I'm all ears
11:22 karolherbst: MrCooper: 1.20.8-1.fc32
11:34 Venemo: Kayden, I added 2 more NIR patches to MR 6964, would appreciate a review from you or jekstrand, they also touch one line in the intel code.
11:35 Venemo: Kayden: these will basically give you the compile-time-known primitive count, if you enable counting them
11:56 danvet_: robclark, airlied on "[PATCH 2/3] drm/msm: add DRM_MSM_GEM_SYNC_CACHE for non-coherent cache maintenance"
11:56 danvet_: I'd say lets stuff them into drm_clflush.c and done
12:02 danvet_: I think that's the version we had like years ago already :-)
12:33 MrCooper: karolherbst: current upstream Git server-1.20-branch might help
12:58 karolherbst: MrCooper: are there any fedora builds I could just try out?
13:47 danvet_: robclark, [PATCH V2 0/8] opp: Unconditionally call dev_pm_opp_of_remove_table() <- can you pls take care
13:48 danvet_: robher, maybe for the arm part in drm-misc
14:07 MrCooper: karolherbst: dunno
14:07 MrCooper: maybe ask ofourdan or so
14:55 NiksDev: Hi all, I am trying to convert the upstream tidss drm driver to new connector model.
14:56 NiksDev: The connector is getting created by the tidss driver and bridges are attached with flag DRM_BRIDGE_ATTACH_NO_CONNECTOR
14:56 NiksDev: Here are some questions, regarding this:
14:56 NiksDev: 1) Most of the info regarding bus_format and bus flags is coming from the bridges. Is it okay to not populate connector->display_info?
14:56 NiksDev: 2) The "drm_atomic_bridge_chain_select_bus_fmts" does the format negotiation. So is it okay for the encoder to simply pick the bus_format from the first bridge's state?
14:56 NiksDev: 3) What is the meaning of MEDIA_BUS_FMT_FIXED? Does it mean that the bridge does not change the format from input to output?
14:56 NiksDev: 4) The bus_flags are available in bridge->timings->input_bus_flags and also in bridge_state->input_bus_cfg.flags. Which one should be used?
15:45 tomba: NiksDev: 1) display_info does contain all kinds of data, so I think it's still valid and we should get that somehow
17:22 italove: hi everyone, I don't know if this is the right place to ask this, but can someone take a look at my proposal/MR to add some new opcodes to NIR that are used with a lowering pass for vector_cmp? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6917
17:25 anholt: italove: I'm confused how you were getting the "before the patches" case -- if you care about vectors, the vectorizer should be doing better than that.
17:25 anholt: and vectoizer should help with the first after the patches case, too
17:40 italove: anholt: yeah, I had vectorizer off for some reason, sorry for that, I'll remove that section of the description, but that's not the main point of the MR
17:42 anholt: I'd focus on what your driver gets in to it and what it can produce out of that. while think that ball/bany would be nicer than the current ball/bany_eachcomparison, and backends would be good to recognize structures based on those, the MR seems to be complicating the situation when really one or the other driver should probably be recognizing a pattern
17:42 anholt: (to me, i965 vector should be recognizing ball/bany patterns, rather than the combinatorial nir ops)
17:45 italove: you said that you "think that ball/bany would be nicer than the current ...", does that mean that you think it's a good idea but not the way I implemented it, or that it isn't worth changing?
17:53 anholt: I think it's a good idea, but it's hard to evaluate without understanding why your backend can't handle mattst88's suggestion of just recognizing the pattern
17:55 italove: anholt: I mean, it can, it's just that I thought this solution solved the problem better and also works for other backends, but apparently it's not
17:56 italove: anholt: my idea was to replace the current nir ops with these new ones, but one thing at a time
17:57 jekstrand: Honestly, I'd kind-of like to see ball_*equal and bany_*nequal be replace by bany/ball. It seems a lot cleaner to me.
17:57 jekstrand: Either pattern can be detected in the back-end
17:57 jekstrand: The current one is probably a bit easier
17:58 jekstrand:reads intel vec4 code
17:59 jekstrand: The tricky bit is if you end up with a swizzle between the bany/ball and the comparison
18:13 italove: jekstrand: this might be a silly question but why isn't swizzle tricky with the current implementation? aren't we just changing ball_equal(v, True) for ball(v) where v is a result of a cmp?
18:18 jekstrand: italove: If you're checking for ball_equal(v, True), you can have a swizzle on v which can, in theory, be turned into a swizzle on v in the bany(v) that you emit in the back-end.
18:19 jekstrand: If you have bany(equal(v.swiz, w.swiz).swiz), then you have two swizzles and you have to compose them when you try to emit a bany_equal() in the back-end. It's possible but annoying.
18:21 italove: I see
20:13 ajax: danvet_: at the risk of learning the answer, what do you need an s390 for?
20:14 danvet_: I stumbled over an rabbit hole called follow_pfn in the kernel
20:14 danvet_: s390 pci_read/write syscalls use that too
20:15 danvet_: the excuse is I'm chasing this rabbit to improve my understanding of pin/get_user_pages rules and how this all works
20:16 danvet_: follow_pfn essentially just reads the page frame number from a pte and hopes that's a legit thing to do
20:16 danvet_: which in todays world with dynamic buffer managers and stuff, isn't
20:17 danvet_: the main user is in v4l
20:17 ajax: i got as far as "s390 pci" before deciding you're in a bad place
20:17 danvet_: I'm aware of that
20:18 danvet_: atm the smell is somewhat kept at bay by layers of refactoring blindly applied on top of the og sin
20:18 danvet_: but I'll go full stupid on this
20:18 ajax: hopefully you can get away with just an s390-targeting cross compiler?
20:20 ajax: neither actually building on s390 nor running it under qemu-user are especially fun
20:20 danvet_: yeah I'm not planning to do more than that
20:20 danvet_: there's at least one great thing with the kernel
20:21 danvet_: you can just compile test and assume the maintainer will test it
20:21 danvet_: the maintainer just acks it and assumes you've tested it
20:21 danvet_: everyone is happy
20:21 krh: mutual CI
20:22 HdkR: Mutually assured CI
20:22 ajax: mutually assumed ci, more like
20:22 krh: we have a winner
20:23 imirkin: i don't see why bother compile-testing
20:23 imirkin: just send it to list, you'll get an email from the kernel robot thing that tells you if it doesn't compile
20:24 danvet_: the 0day bot has become slow enough that it takes it days for the real obscure corners
20:24 danvet_: even once it's merged in linux-next
20:24 danvet_: so you're patch gets reviewed and merged
20:25 danvet_: then 1 week later 0day comes with the compile fail
20:25 danvet_: and the maintainer rips you
20:25 imirkin: for not compiling the intel driver on s390 big-endian
20:25 danvet_: so for flying under the radar you need to test the nonsense yoursefl
20:25 imirkin: :)
20:25 danvet_: usually it's i915 without acpi or backlight
20:26 danvet_: but yeah it's the complete nonsense combo
20:26 imirkin: the ones that are like "drm = m, backlight = y" type things are the most painful
20:26 imirkin: how about you *don't* do that, and everyone is happy
21:47 ajax: why is zink using drisw instead of VK_KHR_xlib_surface?
21:49 ajax: i'm going to hope the answer is of the form "just a spike solution because nobody likes hacking on the winsys code"
21:52 anholt:remembers asking this question and getting an answer I wasn't really convinced of
21:54 jekstrand: kusma: ^^
21:54 jekstrand: ajax: That's roughly my understanding. WSI is hard so punt.
21:55 jekstrand: Doesn't do good things for perf, of course.
21:55 jekstrand: zmike: ^^
22:02 airlied: ajax: it would need it's own libGL then
22:02 airlied: it doesn't use drisw really
22:02 airlied: it uses dri2 as well
22:02 airlied: drisw is the path for nvidia only
22:03 ajax: why would it need its own libGL?
22:04 airlied: like maybe it doesn't specifically need it, but if you want to avoid DRI then it makes it easier
22:04 ajax: not that cloning libGLX is all that difficult, i've done it, but i did it because i was being lazy
22:05 airlied: same as you can build swrast with it's own libGL
22:05 airlied: so it works without DRI
22:06 airlied: like maybe you can hack the whole gallium/winsys layers to avoid it but it was definitely on the tricky side
22:06 airlied: currently zink is broken on radeonsi and I thionk it might be due to not using WSI
22:07 airlied: (radeonsi->radv)
22:07 ajax: yeah, i feel like getting it using wsi is going to be essential to the "just use zink and skip the native gl driver" plan's credibility
22:07 ajax: which is admittedly a stretch goal
22:08 airlied: yeah it's for the nvidia use case or on other OSes
22:08 airlied: where you need your own libGL provider
22:08 airlied: I didn't mean you had to replace glvnd
22:09 ajax: well what delay does is build mesa's libGLX but with only the one "dri" provider that just happens to be radically unlike dri3. i kind of figure using wsi as your winsys would be the same kind of trick.
22:09 airlied: 9fa7400564244bdd333066eb71285c3703b537f7 is where I added dri support
22:09 ajax: oh nice
22:10 airlied: I knew adding that Ideally I wanted to use WSI, but I went down the have something work fast route
22:11 airlied: and at least on radv I don't think we allocate scanout images correctly so get some corruption
22:12 airlied: but src/gallium/targets/libgl-vkwsi
22:13 airlied: seems like a thing that was needed
22:16 airlied: and of course a winsys/vkwsi
22:20 airlied: ajax: now I have to spend today trying not to write it :-P
22:21 lrusak_: I seem to be getting a bogus error when using validation layers with RADV, "Submitted command buffer expects VkImage 0x190000000019[] (subresource: aspectMask 0x1 array layer 0, mip level 0) to be in layout VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL--instead, current layout is VK_IMAGE_LAYOUT_UNDEFINED."
22:22 lrusak_: If I disable validation the image seems to show just fine
22:22 airlied: lrusak_: radv should have no affect on validation
22:22 lrusak_: I also don't seem to see this issue on the intel driver
22:22 airlied: it's for showing app bugs usually
22:22 ajax: airlied: i mean, i will if you won't
22:23 lrusak_: airlied, yes sorry, I mean validation layer enabled in my app when running on radv
22:23 ajax: probably not _today_, but
22:23 airlied: lrusak_: it's a sign of a missing transition in the app
22:24 airlied: lrusak_: you are doing a transfer operation to an image that hasn't been transitioned out of undefined into dst optimal
22:26 airlied: not sure why intel doesn't show it, maybe you don't follow same paths
22:26 lrusak_: I'm aware of what needs to happen, the thing is if I change physical device from the iGPU to the amd card I get this error
22:32 lrusak_: the iGPU isn't connected to a physical output though, the AMD card is, but it seems rendering through wayland allows it to work (the tiling seems wrong though)
22:34 airlied: lrusak_: yeah it's wierd, but the validation is only called by the app
22:34 airlied: so the app does something different
22:35 lrusak_: it's the exact same code path :P
22:35 imirkin: is this the "it works on nvidia, so $other driver must be broken" argument?
22:37 airlied: lrusak_: maybe how prime submits the buffers kicks validatio
22:38 airlied:isn't sure if you can break easily on validation errors to backtrace
22:43 lrusak_: I'll try and figure it out :)
22:50 airlied: lrusak_: hmm it's possible the queue submit for secondary gpu display goes via validation
22:50 airlied: not sure if it's a big problem to fix
22:51 airlied:doesn't have a test setup for it at the moment
22:52 lrusak_: I'm not sure what you mean exactly
22:53 lrusak_: my amd gpu is my primary (it's connected to the monitor) the iGPU is just on the cpu
22:53 airlied: oh so then it shouldn't be hitting that ptah
22:53 airlied: maybe it's because intel is hitting that path
22:53 airlied: that is hidden ffrom valdaiton
22:54 airlied: but yeah look for a missing transition in the app from undefined to transfer dst then
22:57 lrusak_: tl;dr I create image with undefined, transition undefined->optimal, copy buffer to image, transition optimal->shader read only optimal
23:01 jekstrand: And now, time to write a clc loader.....
23:04 jekstrand: jenatali: Are you planning to bake CLC into your build?
23:05 jenatali: jekstrand: I'm assuming you mean libclc?
23:05 karolherbst: jenatali: huh, what kind of loader?
23:06 karolherbst: uhm.. jekstrand: ^^
23:07 jenatali: jekstrand: We're using xxd.py to convert it to a char array to embed in our binary, if that's what you were asking
23:08 jekstrand: jenatali: Yeah, that's what I was asking
23:09 jekstrand: karolherbst: I for... reasons... need a libclc loader outside of clover. Was wondering if we should re-arrange stuff so it lives in src/compiler/spirv or something like that.
23:09 karolherbst: maybe?
23:09 jekstrand: It's simple enough I don't mind duplicating
23:09 airlied: it's 20-30 loc happy to have it moed
23:09 airlied: moved
23:09 jekstrand: The really annoying part is sorting out the meson
23:09 jekstrand: which we'll need to sort out for jenatali too
23:09 karolherbst: yeah...
23:10 jenatali: I think the only complicated part is the lowering pass, which probably should be moved out of clover
23:10 jekstrand: This sounds like a problem for the superpowers of dcbaker[m]
23:10 karolherbst: jekstrand: you know what I think would help?
23:10 karolherbst: add a pkgconfig file to libclc
23:10 airlied: it has one already
23:10 karolherbst: oh really?
23:10 jenatali: Yep
23:10 karolherbst: and why do we play those dirty tricks with the clang resource path?
23:10 airlied: we don't for libclc
23:11 airlied: LIBCLC_LIBEXECDIR
23:11 karolherbst: ohh. right
23:11 airlied: though I'm not sure that is the right path :-P
23:11 karolherbst: libexecdir=/usr/lib64/clc/
23:11 karolherbst: looks like it :p
23:11 airlied:is seeing gings in /usr/share/clc
23:11 airlied: which makes more sense I suppose
23:11 airlied: since they aren't cpu arch specific
23:11 karolherbst: I guess
23:12 jekstrand:ignores meson for now and hacks. :)
23:12 jenatali: jekstrand: I don't have any strong opinions here, anything you'd be rearranging/duplicating is small enough that we can just resolve it later if we want
23:12 karolherbst: jekstrand: what part do you need for meson?
23:12 karolherbst: just wondering
23:13 jekstrand: karolherbst: We really need to break the SPIRV-LLVM-Translator and libCLC stuff out into a new needs_cl_spirv variable or something like that
23:13 karolherbst: mhhh
23:13 karolherbst: well, but that's unrelated to libclc
23:13 jekstrand: That way the MSFT thing can use it and me and clover
23:14 jekstrand: karolherbst: SLT and CLC seem to go together to me
23:14 karolherbst: SLT?
23:14 jekstrand: In a "compile OpenCL C to NIR" package
23:14 jenatali: jekstrand: Yep, I'd agree with that
23:14 jekstrand: SPIRV-LLVM-Translator. Sorry. Got tired of typing it. :)
23:14 karolherbst: ahh
23:14 jenatali: Too many TLAs :P
23:14 airlied: jekstrand: clover also calls spirv-val and a few other things
23:15 karolherbst: yeah.. mhh
23:15 jekstrand: airlied: Sure.
23:15 karolherbst: yeah, clover depends on spirv-tools
23:15 karolherbst: but I guess those can be pulled up as well
23:15 jenatali: So do we, for linking
23:15 karolherbst: yeah
23:15 jekstrand: Right... linking.
23:15 karolherbst: I don't think anybody will complain about that
23:15 jekstrand: I don't know if I care about linking
23:16 jekstrand: But I don't have a problem with having that in the list for now
23:16 karolherbst: so we need this library which links against clang, spirv-tools, and SPIRV-LLVM-Translator which turns OpenCL C + SPIR-V blobs into nir
23:16 karolherbst: sounds like src/compiler/clc to me
23:16 jenatali: Yes-ish
23:17 jekstrand: I mean, sure, but it's like 20 lines of C and 50 lines of meson. Hardly seems worth its own folder.
23:17 karolherbst: we could also make linking the problem of the runtime
23:17 jenatali: As long as it's parameterizable enough that's probably fine, but we'd like to have some control over things like using embedded headers rather than a clang installation, or control over default command line args, etc
23:17 karolherbst: and the src/compiler/clc stuff really just translates clc into spir-v
23:17 karolherbst: jenatali: sure, those can be options I think
23:18 jekstrand: for CLC, it'd be easy enough to have a meson switch for "static" CLC rather than dynamic.
23:18 karolherbst: jekstrand: well.. it's more
23:18 jenatali: Yeah, it's more
23:18 karolherbst: you have to configure your clang instance and shit
23:18 karolherbst: a lot of the code is shared with the clc to LLVM path inside clover
23:18 jekstrand: karolherbst: Hrm.... Actually, I don't think I need SLT
23:18 karolherbst: which we take to convert it into spir-v
23:18 jekstrand: I just need clc
23:18 karolherbst: yeah..
23:18 karolherbst: doesn't make your problem smaller
23:18 karolherbst: hum.. wait
23:19 airlied: yeah if you don't need online ocmpiler you don't need slt
23:19 karolherbst: clc is really a bad term
23:19 jenatali: Well at that point you're implying you're getting input SPIR-V, instead of input CL C
23:19 karolherbst: please use either libclc or CL C if you mean the language like glsl :p
23:19 jekstrand: hehe
23:19 jenatali: Yeah... probably better to be clear between CL C == source, libclc == a library of code
23:19 jekstrand: sure
23:19 karolherbst: anyway, if you only care about consuming spir-v, then yes.. the problem is quite small indeed
23:20 karolherbst: but then I don't see the benefit of sharing as it doesn't seem to be worth it really. We really just translate it to nir and add some passes, no?
23:20 jenatali: Yeah
23:20 jenatali: Sharing the CL C frontend would be more interesting, but also much more complicated
23:21 karolherbst: well.. you mean the glue code :p
23:21 jenatali: Yeah, setting up the clang invocation and the translator
23:21 airlied: sounds like the basics to share are the find and load the libclc binary, disk cache it maybe, and spirv->nir it
23:22 airlied:wonders how much the spirv options, compiler options matter there
23:22 jekstrand: Pass them in
23:22 airlied: but you should have access to those
23:23 airlied: but yeah having clover::nir::libclc_spirv_to_nir be a wrapper and clover::spirv::load_clc
23:23 airlied: seems like the basics
23:30 karolherbst: mhh I should look into wiring up the conversion stuff :)
23:32 airlied: karolherbst: what's stopping the constant ptr mr?
23:32 karolherbst: waiting on jekstrand other MR
23:32 zmike: ajax / jekstrand: no idea, probably because I've never even glanced at anything related to winsys
23:32 karolherbst: airlied: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6974
23:33 jekstrand: which is waiting on anholt
23:33 jekstrand: But also, I dealt with anholt's comments on Friday and didn't actually push the branch. :-/
23:33 karolherbst: mhh, I kind of feel like I think images are more important than conversions :D but conversions are so easy to wire up
23:33 airlied: ah hadn't realised it was in a queue :-P
23:33 karolherbst:adds nir_lower_alu_conversion_to_intrinsic
23:35 jekstrand: karolherbst: You can land your MR without my patch. It's just less optimal.
23:35 karolherbst: ohh, true
23:35 karolherbst: I guess I'll do that
23:35 airlied: my attempts fo fix review comments on my ci work broke my CI work
23:36 karolherbst: airlied: wanna give it another test run or should I just merge it?
23:37 karolherbst: although.. I kind of would like curro to take a look first as it touches some clover core dcode
23:37 karolherbst: *code
23:38 anholt: jekstrand: ok, fixups look good. also a reminder that you or cwabbott seem like about the only people that might review my liveness stuff so nir-to-tgsi can land. :)
23:38 jekstrand: anholt: Yeah...
23:39 airlied: karolherbst: worked fine when I tested it
23:39 jekstrand: anholt: It's getting late now. Ping me and I can look at it again tomorrow. I gave it a very quick look and seemed to like it better at the time.
23:39 karolherbst: ehhh
23:39 karolherbst: the pipe loader is broken?
23:39 jekstrand: anholt: Is that an RB for the const series once I squash?
23:40 anholt: as far as I could tell, yeah :)
23:40 karolherbst:goes bisecting
23:41 karolherbst: I get the feeling somebody reworked the pipe loader stuff in the past :p
23:45 karolherbst: but I kindof get the feeling I broke it locally :d
23:48 jekstrand: Or I could just do a fake libclc.....
23:48 karolherbst: nope
23:48 karolherbst: it crashes inside the pipe loader
23:48 jenatali: jekstrand: What good is a fake libclc?
23:48 karolherbst: ohh
23:48 karolherbst: that was unrelated to my rumbling
23:48 jekstrand: jenatali: Maybe not much good long-term. :)
23:49 airlied: just write the loader as a hack would be quicker
23:49 jekstrand: It's true
23:49 airlied: like if it's not in C++ it should be much smaller :-P
23:49 karolherbst: anholt: it doens't look good for you :p
23:49 airlied:runs awya
23:50 jekstrand: airlied: I've mostly written it. And mine's better because it mmaps the file. :D
23:50 karolherbst: :D
23:51 anholt: karolherbst: going to be done with work soon, put up some debug info an I might be able to help
23:51 karolherbst: dd->create_context is NULL, but I am done with git bisect soon as well
23:52 anholt: nouveau, presumably?
23:53 karolherbst: anholt: 8a05d6ffc65d0fd0e0a52fe84a174d4ca63e5521
23:53 karolherbst: anholt: iris :D
23:54 anholt: are you using the fixed up iris pipe loader, or an old rebase?
23:54 anholt: since it wasn't in master when I landed the code
23:54 anholt: (the pipe loader refactors, at least)
23:55 karolherbst: how would that matter for git bisect?
23:55 anholt: actually, back way way up here. what code even is crashing? are you running something on master, or some downstream branch?
23:55 karolherbst: I am on 8a05d6ffc65d0fd0e0a52fe84a174d4ca63e5521, it breaks clover
23:55 karolherbst: just running clinfo
23:55 karolherbst: nothing fancy about it really
23:55 anholt: I don't see a pipe_iris.c in tree, and I thought clover was all dynamic pipe loader
23:56 karolherbst: mhhhh... heh
23:56 karolherbst: good idea actually
23:56 karolherbst: I think the file is just left over in my local install prefix
23:56 anholt: so I'm skeptical that you're using clover on 8a05d6ffc6
23:57 karolherbst: yeah.. I am trying with a cleared prefix and see what that does
23:58 karolherbst: okay.. now it works