Quoting Michal Wajdeczko (2018-02-01 15:51:58) > I was assuming these steps: > > 1. add new failure checkpoint(s) to the code > 2. boot driver with inject modparam=-1 to list active checkpoints > 3. note the number of checkpoint that we want to trigger > 4. boot driver with inject modparam=n to trigger selected checkpoint > 5. repeat steps 2-4 in case of rebase/code refactor/new checkpoints > > > how to make it more useful than drv_module_reload and to keep it working > > as you intend. A pure fault-counter doesn't seem very robust or > > intuitive for me when you are trying to develop a new fault point. Otoh, > > Currently we identify fault checkpoint by pair [function:line] so if we > want > to invest more in this mechanism we can change modparam to char* and then > check against function and line instead of the counter. Then no iteration > (or listing checkpoints) would be needed. So I've no strong objection to the overall approach. (If time were infinite, I would push the fault-counters into a .data section so we could probe them from the i915.ko without loading.) I think though to make it really useful would be to add a tag to each fault-point (NULL for boring existing ones unless you're feeling inventive). Then the developer need only say ./tests/drv_reload_fault my-tag and that will then be stable across different kernels. The minimum bar for adding this dev feature would be the corresponding tool for igt, with a small integrated test. (Hmm, if we could push the tags to .data, we could even tell how many fault-injection sites were hit.) Long term desire would be kprobe/ebpf hookup, or some [soon-to-be] existing infrastructure for fault-injection along those lines. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
