08:08 <jhovold> bamse: are you booting with efi=noruntime? That would indeed cause a NULL-pointer derereference as the efi.set_variable pointer would be left uninitialised

16:12 <bamse> jhovold: ahh, yeah that i indeed do on the particular machine that failed

16:14 <jhovold> bamse: there are too separate NULL derefs that can be hit depending on if runtime services have been disabled completely or based on the fw support mask. In the former case the callback pointers have never been set up and in the latter case, the workqueue used for the call has never been allocated

16:14 <jhovold> good thing you were still using efi=noruntime on that machine, or this could have taken much longer to track down

16:15 <jhovold> two separate*

16:16 <jhovold> bamse:I assume it was the CRD as well so you had console output?

16:17 <bamse> jhovold: the problem i ran into was that process_one had a 0x0 on the top of the callstack, with lr as refresh_nv_rng_seed

16:18 <bamse> jhovold: it was not the CRD, so it was non-trivial to figure out

16:18 <jhovold> right, because efi.set_variable was NULL with efi=noruntime

16:18 <bamse> exactly

16:18 <jhovold> wow, ok, glad you did!

16:19 <bamse> would have been nice to be able to scroll in the efifb

16:20 <bamse> and it would be really nice if regulators aren't blindly disabled after 30 seconds...

16:21 <bamse> does efi_rt_services_supported(XYZ) return true when efi=noruntime? or do we need a separate check for the NULL case?

16:21 <jhovold> bamse: I finally figured out all the dependencies needed for display in initramfs. Won't help if the display driver fails to probe after this particular bug though...

16:21 <bamse> hmm, my display works fine when this happens...with efifb and keyboard...

16:22 <bamse> but rather quickly the regulator framework kills the backlight

16:22 <jhovold> bamse: yeah, but since you use efifb, regulator core will disable the display regulator, as you noticed

16:23 <jhovold> so either we probe the msm drm driver in initramfs, or hack regulator core to disable that 30s timeout. That are the two options currently unfortunately.

16:27 <bamse> jhovold: i think in general it would be nice if we didn't disable clocks, pds, interconnects or regulators while we're in the ramdisk console...not sure if there's a way to achieve that

16:32 <jhovold> bamse: not currently, no

18:03 <javierm> jhovold: you are using a DTB on the X13s right? I wonder if you could use the simplefb driver instead since it allows to define regulators, clocks, etc for the simple-framebuffer DT node