14:54 skinkie: What is the best way to report a trace?
14:55 skinkie: https://gist.github.com/skinkie/ec619598d207ef3d694e35243116126f
14:56 imirkin: you can report it on gitlab.freedesktop.org/drm/nouveau
14:57 imirkin: make sure to include system details
14:57 imirkin: that's a display hang ... we don't get those often
14:58 skinkie: imirkin: is that positive or not? ;)
14:59 imirkin: have you ever known a hang to be positive?
14:59 skinkie: imirkin: rather the fact, that those kind of bugs almost never happen :)
15:00 imirkin: they can be quite difficult to track down
15:00 imirkin: in fact completely impossible without a repro, i think?
15:00 skinkie: imirkin: Is there any way to recover, without a reboot?
15:00 imirkin: although maybe we dump enough info above
15:00 imirkin: depending on your setup, your could reload nouveau
15:00 imirkin: you'd have to carefully detach everything in your system from it
15:01 imirkin: oh, also system suspend / resume would fix it ... if the suspend actually works
15:05 orbea: is that general advice about suspend/resume with gpu issues or specific to this case? Never thought of trying that before...
15:06 imirkin: general advice
15:06 imirkin: depends on the nature of the hang though
15:06 imirkin: like in this case, pretty sure things aren't stuck
15:06 orbea: ah
15:06 imirkin: everything is working fine with the minor exception that nothing is showing up on the screen
15:06 imirkin: whereas if the kernel is stuck in some way, suspend ain't happening
15:07 orbea: makes sense
15:07 orbea: usually in cases where its not stuck you can ssh in or something
15:07 imirkin: well, with SMP even if it's stuck you can still ssh in
15:10 skinkie: https://gitlab.freedesktop.org/drm/nouveau/-/issues/165 <- if it needs more details, please let me know
15:10 imirkin: skinkie: was there anything above that timeout?
15:10 imirkin: like "here's a bunch of useful info that will be useful in debugging the timeout"?
15:10 imirkin: we dump that sometimes
15:10 imirkin: although maybe we only do that on error
15:10 skinkie: imirkin: the same timeout over-and-over, but I can check out what logs i have retained
15:11 imirkin: it'll be super-verbose register-dumpy-looking thing
15:12 imirkin: skinkie: also can you mention how the screen is connected? i assume VGA + DVI-D?
15:14 imirkin: interlaced modes aren't like the _most_ tested bit of nouveau, but should def work in general
15:14 skinkie: imirkin: there might be something interesing, it is now attached.
15:14 imirkin: a disp timeout means that we tried to adjust _something_ display-related (could be as innocuous as flipping buffers, could be changing modes/settings), and ... it times out
15:15 imirkin: yeah ... just a core notifier timeout as the first issue
15:15 imirkin: so we updated the "core" channel and it never completed. or something
15:16 skinkie: imirkin: the mini-hdmi connector -> mini2fullhdmi -> hdmi-cable to ATEM; the DVI connector -> long DVI2HDMI cable -> ATEM.
15:17 skinkie: imirkin: could it be that the EDID information already informed that the connected display only supports one mode, and it hangs on that? It is really interesting to see that in for example OSX connecting to an ATEM "just works" regardless of the mode installed.
15:18 imirkin: skinkie: ok, so 2x HDMI inputs on the monitor?
15:18 imirkin: skinkie: sure, grab edid while you're at it. /sys/class/drm/card0-HDMI-1/edid or whatever
15:19 imirkin: https://people.freedesktop.org/~imirkin/edid-decode/ -- if you're too lazy to install the edid-decode utility yourself
15:19 skinkie: imirkin: basically a bunch of connectors eventually becoming HDMI
15:20 imirkin: i'm guessing the people writing OSX have expended a lot more effort on making screens work :)
15:21 imirkin: we barely support HDMI..
15:22 imirkin: just checking out what this ATEM device is
15:22 imirkin: one thing which i observe is that it claims to only support YUV 4:2:2. we only output RGB 4:4:4
15:22 skinkie: imirkin: any tips on running edid decode?
15:23 imirkin: just feed the file into it
15:23 skinkie: imirkin: hence from /sys?
15:23 imirkin: or copy the file from /sys somewhere first
15:24 skinkie: imirkin: want the output here or in the ticket?
15:24 imirkin: won't hurt in ticket
15:26 skinkie: done
15:27 imirkin: ok, so looks like 1920x1080i@50 is definitely on the supported list
15:27 imirkin: it marks a ton of VIC's as native, which i'm pretty sure is naughty
15:27 imirkin: did edid-decode complain at the end?
15:28 skinkie: imirkin: not at all
15:28 imirkin: hm ok
15:28 imirkin: maybe it's ok then
15:28 imirkin: whoa
15:28 imirkin: Vfront 2 Vsync 5 Vback 15 Vpol P Vfront +0.5 Odd Field
15:28 imirkin: Vfront 2 Vsync 5 Vback 15 Vpol P Vback +0.5 Even Field
15:29 imirkin: i don't think i've ever seen that +0.5 thing
15:29 imirkin: maybe i just haven't looked at those detailed infos for interlaced modelines? dunno
15:30 skinkie: imirkin: I stole my custom modeline directly from xrandr. So maybe mine is wrong, but at least it does display in this very picky device. If YUV would be really the only one supported... that would have been... visible (or rather black).
15:31 imirkin: yeah, according to the EDID, it also supports YUV 4:4:4, and i suspect that RGB 4:4:4 is mandated by the HDMI spec
15:33 imirkin: anyways
15:33 skinkie: imirkin: if only it supported YUVA 4:4:4:4 over a single wire... because it does over two.
15:33 imirkin: while this is all interesting
15:33 imirkin: it has nothing to do with the issue at hand
15:33 imirkin: the system died after about 20s
15:33 imirkin: do you have any idea what might have happened then?
15:33 skinkie: imirkin: starting of my QML program? :)
15:34 imirkin: what does it do?
15:34 imirkin: it switches modes? or something else?
15:34 skinkie: imirkin: display pretty animations
15:34 imirkin: i meant as far as nouveau is concerned
15:34 skinkie: imirkin: it indeed sets up the EGL/KMS stuff
15:34 imirkin: ok, so then we tried to switch modes and failed spectacularly
15:34 skinkie: 74.25 1920 2448 2492 2640 1080 1084 1094 1125 +hsync +vsync interlace
15:35 skinkie: my guess is, it did everything up to the interlace part 'correctly'
15:35 imirkin: well
15:35 imirkin: so the thing about HDMI/DVI
15:35 imirkin: is that they don't give a shit about the sink
15:35 imirkin: even if it screws up some setting, that just means the sink won't display pictures
15:35 imirkin: but the board should keep running just fine
15:36 imirkin: we must have made some sort of illegal setting change
15:36 imirkin: which causes the display engine to lock up
15:36 imirkin: can you reproduce this?
15:36 imirkin: if so, i'll give you some nouveau params to dump a ton more info
15:37 skinkie: imirkin: sure, i think I can just remove the interlace setting and get it to break, where do I enable the ton of dums?
15:38 imirkin: let me check which setting you need ... debug or trace. hold on
15:40 imirkin: skinkie: try nouveau.debug=disp=debug drm.debug=0x1e
15:40 imirkin: this will produce a lot of logs
15:42 skinkie: imirkin: where best to put this? kernel cmdline or modprobe?
15:53 skinkie: imirkin: debug version attached.
15:54 imirkin: kernel cmdline, but i guess you figured it out
16:01 skinkie: imirkin: i could only make it go wrong now by 'stopping' the software
16:02 imirkin: yeah, feels like something not-quite-deterministic
16:02 skinkie: imirkin: maybe switching back to the previous mode is the issue
16:02 imirkin: perhaps
16:02 imirkin: the trace has all the mode info (or at least a lot of it)
16:02 skinkie: imirkin: just out of curiousity could you give me a hint how to achieve this mode straight from boot?
16:03 imirkin: 1920x1080i@50?
16:03 skinkie: exactly
16:03 imirkin: so i think if you do nothing, you get @60, yea?
16:03 skinkie: imirkin: exactly
16:03 imirkin: i.e. 1920x1080i@60
16:03 imirkin: so interlaced, but NTSC rather than PAL
16:04 skinkie: imirkin: i am not sure if it is interlaced though. I have attempted several KMS things, but never got the boot actually visible on this device.
16:04 imirkin: i don't know offhand ... let's glance at the parameter parsing logic
16:04 imirkin: well, this trace should have the info actually
16:05 imirkin: Mar 19 16:49:04 kabelkrant kernel: [drm:drm_client_modeset_probe] desired mode 1920x1080i set on crtc 50 (0,0)
16:05 imirkin: Mar 19 16:49:04 kabelkrant kernel: [drm:drm_client_modeset_probe] desired mode 1920x1080i set on crtc 60 (0,0)
16:05 imirkin: so yeah. it's picking the first mode, which is
16:05 imirkin: Mar 19 16:49:04 kabelkrant kernel: [drm:drm_mode_debug_printmodeline] Modeline "1920x1080i": 60 74250 1920 2008 2052 2200 1080 1084 1094 1125 0x48 0x15
16:06 skinkie: imirkin: the name of the mode for 60 is the same as the 50 one.
16:06 imirkin: you're reading that wrong
16:06 imirkin: crtc #50
16:06 imirkin: and crtc #60
16:06 imirkin: no connection to refresh rates
16:06 skinkie: oh just ports?
16:06 imirkin: just internal id's
16:07 imirkin: e.g. Mar 19 16:49:04 kabelkrant kernel: [drm:drm_atomic_get_crtc_state] Added [CRTC:50:head-0] (____ptrval____) state to (____ptrval____)
16:07 imirkin: CRTC id 50 = head-0 on that board, etc
16:07 imirkin: (why is the id so high? it's a shared id space, other things get allocated from it)
16:08 imirkin: skinkie: try booting with video=1920x1080@50i
16:09 imirkin: [yeah, annoying that the i goes in a diff spot.]
16:09 imirkin: you can also do it differently for each connector, e.g.
16:10 imirkin: video=DVI-I-1:1920x1080@50i video=HDMI-A-1:1920x1080@50i
16:10 skinkie: imirkin: I guess you want the output log of that one failing, because I have tried that one before :)
16:10 imirkin: unfortunately the connector names aren't fully deterministic, so it's an imperfect system
16:10 imirkin: in what way does it fail?
16:12 skinkie: imirkin: no output on screen
16:12 imirkin: ah
16:13 imirkin: it could be that it's creating its own modeline
16:13 imirkin: i wish there were a video=VIC20
16:13 imirkin: or whatever
16:13 imirkin: but yeah, try that boot with the extra debug params
16:13 imirkin: at least drm.debug=0x1e
16:13 imirkin: which will give you the stuff going on in drm
16:14 skinkie: imirkin: the connectors names are also different within QT, that is really annoying.
16:14 imirkin: yeah, can't help with hat
16:14 imirkin: that*
16:15 imirkin: there were some unforced errors in the early drm days which might have encouraged that
16:15 skinkie: imirkin: now i am a little bit scared, because it does not reboot.
16:16 imirkin: well, the power button is the ultimate hammer
16:16 skinkie: imirkin: that suggest that it is next to me
16:16 imirkin: it does
16:16 imirkin: sorry, i wouldn't have asked you to mess with kernel if i didn't think you had it next to you
16:17 skinkie: imirkin: it is back
16:18 skinkie: [ 2.677832] [drm:drm_connector_init] cmdline mode for connector DVI-I-1 1920x1080@50Hz interlaced
16:18 imirkin: so something's working
16:18 imirkin: but i'm guessing it tries to make its own modeline
16:18 imirkin: rather than get a matching one from the edid
16:19 skinkie: imirkin: the output is now 'just' the basic setup, no qt stuff running
16:19 skinkie: ticket updated
16:21 imirkin: oh hm
16:21 imirkin: [ 2.953296] [drm:drm_client_modeset_probe] looking for cmdline mode on connector 61
16:21 imirkin: [ 2.953297] [drm:drm_client_modeset_probe] found mode 1920x1080i
16:21 imirkin: that looks like it's actually going through the edid modes
16:21 imirkin: SIGH
16:22 imirkin: [ 2.887030] [drm:drm_mode_debug_printmodeline] Modeline "1920x1080i": 50 74250 1920 2448 2492 2640 1080 1084 1094 1125 0x60 0x15
16:22 imirkin: [ 2.887032] [drm:drm_mode_debug_printmodeline] Modeline "1920x1080i": 50 74250 1920 2448 2492 2640 1080 1084 1094 1125 0x40 0x15
16:22 imirkin: why are there two 1920x1080i modes??
16:22 imirkin: slight difference in flags
16:22 imirkin: or polarities or whatever
16:23 imirkin: it's the mode "type", whatever that is
16:24 imirkin: aha. a completely pointless thing.
16:24 imirkin: one is DRIVER the other is DRIVER | USERDEF
16:24 imirkin: but since they're identical, doesn't really matter
16:27 imirkin: dunno. weird.
16:33 imirkin: unfortunately display stuff isn't my wheelhouse
16:36 skinkie: imirkin: i'll wait until some replies fly in from the ticket