On Wed Nov 12, 2025 at 3:42 AM JST, Lyude Paul wrote: > On Mon, 2025-11-10 at 10:16 -0500, Joel Fernandes wrote: >> On 11/5/2025 6:19 PM, Timur Tabi wrote: >> > On Wed, 2025-11-05 at 13:55 -0800, John Hubbard wrote: >> > > > #define nvdev_trace(d,f,a...) nvdev_printk((d), TRACE, info, f, ##a) >> > > > #define nvdev_spam(d,f,a...) nvdev_printk((d), SPAM, dbg, f, ##a) >> > > >> > > ...and those are unusable, unfortunately. I've tried. >> > >> > This works great for me: >> > >> > modprobe nouveau dyndbg="+p" modeset=1 debug="gsp=spam" config=NvGspRm=1 >> > >> > I get all sequencer messages when I boot with these options. >> > >> > > ftrace/bpftrace, maybe those are the real way to "trace"...or something >> > > other than this. >> > >> > You could say the same thing about most dev_dbg() statements. >> > >> > I agree that dev_dbg for sequencer commands is excessive, and that >> > implementing new debug levels >> > just to get sequencer prints is also excessive. But Nouveau implement >> > nvkm_trace for a reason. And >> > we all know that because of ? in Rust, NovaCore does a terrible job at >> > telling us where an error >> > actually occurred. So there is a lot of room for improvement. >> >> IMO, the best way to do this is the tracing subsystem. It is the lowest >> overhead >> runtime kernel logging system that I know off, lockless, independent of the >> serial console etc, next to no runtime overhead when off, etc. >> > > I agree. FWIW, it's worth noting that honestly avoiding logging is the way to > go for anything spammy. I've seen quite a number of heisenbugs that only > appear when trace logging isn't turned on in nouveau or vice-versa (igt tests > that fail because logging causes things to time out…).
+1 for tracing, when debugging we are typically interested in a very small subset of the debug logs and the ability to only enable what is needed is essential. Though I am not sure about the current state of tracing support in Rust...
