02:05 FurretUber: Hi, I need some help on debugging a system crash. After roughly 2 hours of OpenGL load, the system is hard crashing with a BUG on i915
02:06 FurretUber: I got a backtrace that I can loop and will trigger the crash consistently. However, it is annoying to have to wait around 2 hours until the crash happens
02:08 FurretUber: Considering there are no dmesg or syslog messages until the crash, what other elements/logs/stats could I observe while the trace is replayed, before the crash?
05:07 jekstrand: FurretUber: Start by filing a bug at https://gitlab.freedesktop.org/drm/intel/-/issues with all of the information you do have
05:07 jekstrand: Typically a BUG_ON will result in a stack dump from the kernel so that should help
05:07 jekstrand: FurretUber: Also, if you can provide your reproducer, that helps as well.
14:15 pcercuei: is there a simple test app I could use to check that my overlay is working?
14:23 pcercuei: I guess modetest will do.
14:52 jekstrand: hakzsam: It'd be nice if you or someone else could look at those regressions and at least point me at the differences.
14:52 jekstrand: hakzsam: I'd like to get the CFG rework re-merged before too long.
14:53 jekstrand: It's been sitting there for over a month already and I think it does fix real bugs
14:53 jekstrand: Just not bugs that are likely to be produced by GLSLang or DXVK
14:53 hakzsam: jekstrand: sure, I will look next week
14:54 hakzsam: thanks a lot for the revert
14:54 jekstrand: yw
14:54 jekstrand: Now back to making ANV suck less :)
15:10 pcercuei: trying to modetest: modetest -D /dev/dri/card1 -M ingenic-drm -a -s 35@32:320x240-60 -P 33@32:320x240@RG16
15:10 pcercuei: That should make my overlay plane (ID #33) 320x240
15:10 pcercuei: I just get Atomic Commit failed [1]
15:11 pcercuei: my plane_atomic_check() returns 0, so I don't really know what's going on
16:05 doras: I've been experiecing some regressions with radeonsi in Mesa 20.0.3. I suspect the NIR backend, but I don't have a way to easily test this since the TGSI backend was removed :\
16:06 FurretUber: jekstrand: This is on Xubuntu Focal Beta, as drm-tip is fixed: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1870265
16:10 doras: Doesn't happen with LIBGL_ALWAYS_SOFTWARE=1, though.
16:36 jekstrand: FurretUber: Then wait for the backport to come to a kernel near you
16:36 jekstrand: Assuming they were aware of the fix and tagged it for backport
16:36 pepp: doras: can you create a gitlab issue?
16:37 FurretUber: I made them aware. Is there a way to find what is the commit that fixes this, assuming this is known? Or bisecting is the only way?
16:49 jekstrand: Bisecting is the best way
17:55 imirkin: robclark: silly idea -- could each job just decide whether it will run or not based on the changes in the commit?
17:59 robclark: I think we are doing some of that already... so a change in src/freedreno won't run panfrost CI.. I'm not entirely sure how it works, but I know we've somehow started doing that
18:01 imirkin: oh, didn't know that
18:05 robclark: I think it is 2a9d6fdd8c5a94b574e241f9cad5662cbaef54b2 that added this? but that is assuming I'm understanding the gitlab yml stuff (which is a moderately steep assumption)
18:16 pepp: robclark: yes it's this commit. But the mapping "source files modified => test job to run" is very basic, and could be improved
18:16 jekstrand: I think once we've got hw-driver-only changes not running CI on other people's HW, that's most of it.
18:20 robclark: yeah, and probably would be ok if core changes didn't run on everybody's hw until marge.. if marge ran more complete CI we could afford to be more aggressive with not running things pre-merge..
18:21 robclark: at that point, pre-merge CI because more of a rather convenient way for me to test changes that I'm working on across a bunch of gens of adreno (esp. now, wfh I don't really have with me all the different hw)
18:21 jekstrand: Maybe? When I'm doing NIR changes, I push an MR just to get a CI run on freedreno and friends
18:22 robclark: can we still push a branch called ci-<whatever> to trigger CI? Maybe that is another way to trigger more complete CI on demand?
18:22 jekstrand: Then again, I'm a pretty big offender when it comes to re-pushing an MR many times.
18:22 jekstrand: I'd be fine with CI requiring me to click a button
18:23 jekstrand: I just don't want to have to click 15 buttons. :)
18:23 pepp: that's the idea of https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432 : only marge run CI automatically (pre and post merge) but everyone can still manually trigger CI
18:23 robclark: me too.. although the first N times are just me finding what I broke on hw I don't have in front of me ;-)
18:23 jekstrand: Well... I do that to the Intel CI system. Most of my pushes to GitLab are me adding R-B tags or tiny changes to fix review nits.
18:24 robclark: the problem is (unless there is some clever trick I don't know) is gitlab is rather stupid about triggering things manually.. rather than clicking on the job I want, I need to click and wait at each stage..
18:25 karolherbst: robclark: can't you abort the full run and just retrigger the once you care about?
18:25 karolherbst: *ones
18:25 robclark: if gitlab just let me directly click all the freedreno jobs I wanted, and automatically realized that means it needs to run container and build steps, it wouldn't be so bad
18:25 pepp: the MR simplifies running the CI manually: it won't be needed to click on everything anymore
18:26 robclark: oh, ok.. as long as I don't have to (for example) wait for build step to finish to click the hw CI runner steps, then I'm happy
18:27 pepp: the hw CI will run automatically, if its dependencies are run (I think, I only skimmed through the changes). So I guess you'll need to manually run the correct container job(s) and that's all
18:29 robclark: hmm, does that mean, tho, that it will end up running both (for ex) panfrost and freedreno? Or do the rules about running based on paths changed by the MR still limit that so panfrost doesn't run for freedreno changes?
18:30 pepp: the path based rules still apply
18:30 robclark: hmm, ok.. yeah, I guess path based rules + just clicking container jobs wouldn't be as bad
19:20 xantoz: 1