09:27 RSpliet: kherbst: I didn't point it out yesterday, but Throwawayname's boot log also spits "[ 4.763894] nouveau 0000:01:00.0: bios: OOB 1 013f1901 013f1901". It might be failing to initialise something important.
09:27 kherbst: ohh
09:27 kherbst: indeed...
12:51 Throwawayname: I am back. I updated to 5.10, and grep . /sys/class/drm/card*/status results in "disconnected"
13:04 kherbst: Throwawayname: for all outputs?
13:04 kherbst: okay...
13:04 Throwawayname: for 1 only output
13:04 kherbst: Throwawayname: in the meantime, we figured there might be something wrong in the init sequence as we might fail to parse the vbios correctly
13:05 kherbst: Throwawayname: did you upload your vbios.rom file anywhere?
13:08 Throwawayname: Also, another thing is that when I installed nouveau-firmware package from repos, the colored symbols were replaced by a general corruption - blank screen with a few horizontal lines. Removing nouveau-firmware did not do anything
13:08 Throwawayname: kherbst: I didnt
13:09 kherbst: Throwawayname: yeah, that's just random stuff I guess
13:09 kherbst: we wail to bring up the GPU properly
13:09 kherbst: so you only see one connector
13:09 kherbst: and I bet you have more ports
13:09 Throwawayname: Its a All-in-one PC, which has no other ports other than internal LVDS
13:10 Throwawayname: How much did you bet anyways?
13:10 kherbst: I didn't say they are wired up :p
13:11 Throwawayname: On MoBo I only found a VGA placeholder with no resistors or the actual port soldered
13:11 kherbst: Throwawayname: so.. you have a /sys/kernel/debug/dri/0/vbios.rom file and that I'd need. If you don't have any storage for upload it, you can always create an issue on gitlab: https://gitlab.freedesktop.org/drm/nouveau/-/issues
13:12 Throwawayname: There is also a /sys/kernel/debug/dri/128/vbios.rom - Interested?
13:12 kherbst: it's the same file
13:13 RSpliet: kherbst, Throwawayname: I see there's two VBIOS fixes, one of which probably hasn't made it to this 5.4.94 branch. Be nice to know if a newer kernel still spits "[ 4.763894] nouveau 0000:01:00.0: bios: OOB 1 013f1901 013f1901"
13:13 kherbst: ohhh, yeah, good point
13:13 Throwawayname: RSpliet, I am on 5.10, and will pastebin the new dmesg now
13:13 RSpliet: kherbst: think there's any merit in telling nouveau to use a different VBIOS access method... does that still exist? We used to have PROM, PRAMIN, ACPI I think
13:13 RSpliet: Throwawayname: thanks!
13:14 kherbst: RSpliet: mhhhh yes
13:14 kherbst: but let's check the vbios first
13:15 RSpliet: Another interesting one to try is forcepost?
13:15 RSpliet: Just shooting ideas :-P
13:16 kherbst: well, that wouldn't help with vbios parsing
13:16 Throwawayname: https://paste.ubuntu.com/p/b7qMmjyJrD/
13:16 RSpliet: It wouldn't, but it might initialise something that the UEFI didn't
13:16 kherbst: still there
13:17 RSpliet: yep. It also lists 10 connectors in the DCB?
13:17 kherbst: RSpliet: that's normal
13:17 RSpliet: Sure. Just wondering whether they're valid :-)
13:17 kherbst: not all
13:17 kherbst: but there seems to be one declared output at least
13:18 kherbst: not more
13:18 Throwawayname: vbios.rom - https://paste.c-net.org/CorryUgliness
13:19 RSpliet: Throwawayname: you seem to be the curious type :-P If you want to see for yourself what's in it, you can parse it on https://people.freedesktop.org/~imirkin/nvbios/
13:19 kherbst: mhh
13:20 Throwawayname: Well... seems like vbios.rom parses also broke down on me :)
13:20 Throwawayname: Assertion failed: cannot call main when async dependencies remain! (listen on Module["onRuntimeInitialized"])
13:21 kherbst: weird
13:21 kherbst: works for me
13:21 Throwawayname: Should I bother imir kin with this?
13:21 kherbst: RSpliet: I am actually curious where that address is coming from
13:21 RSpliet: Same, but also note WARN: checksum fail
13:22 kherbst: well
13:22 kherbst: OEMs put broken vbios
13:22 kherbst: tough :p
13:22 RSpliet: the blob works, and that normally chickens out first when the checksum is invalid
13:23 RSpliet: I suspect we're accessing it wrong
13:23 RSpliet: actually
13:23 kherbst: Failed to parse d DP INFO table at 0x8141, version 21
13:23 kherbst: mhhh
13:24 RSpliet: It doesn't have DP, makes sense to me. I think this is pre-eDP
13:24 kherbst: well...
13:24 kherbst: who knows
13:24 Throwawayname: Any other info useful to dump?
13:24 kherbst: not sure
13:24 kherbst: so there is this LVDS connector...
13:25 RSpliet: kherbst: can we make the BIOS parser in nouveau more verbose? Might give hints as to when it's shouting OOB
13:25 kherbst: and nouveau thinks it's disconnected, right?
13:25 kherbst: RSpliet: I don't think it matters
13:25 kherbst: some garbabe in the vbios, wouldn't be the first time
13:25 kherbst: what I am more curious about is, why don't we detect the LVDS display to be connected
13:26 RSpliet: There's a few MXM pins in GPIO, there's a PANEL_POWER pin in the GPIO table... we might be doing something wrong there?
13:26 kherbst: yeah.. PANEL_POWER might be something
13:26 kherbst: let's see
13:26 RSpliet: It was powered before nouveau was loaded :-D
13:27 kherbst: ahhhhh
13:27 kherbst: no
13:27 kherbst: okay
13:27 kherbst: I got it
13:27 kherbst: DCB_GPIO_PANEL_POWER is only used for _eDP_ connectorts
13:27 kherbst: *connectors
13:27 kherbst: inside nouveau
13:28 RSpliet: And that should also be LVDS I guess?
13:28 kherbst: checking
13:28 kherbst: "LCD0 power: Panel Power control. LCD0 corresponds to the LCD0 defined in the LCD ID field in the Connector Table."
13:28 RSpliet: Anyway, I need to go back t
13:29 RSpliet: 'work. I'll read the backlog later :-P
13:29 kherbst: but given it's 1 I wouldn't be surprised if it's use pre eDP :D
13:31 kherbst: shit.. I know nearly nothing in this area :/
13:32 kherbst: Lyude might have some ideas if not, then skeggsb_ for sure
13:41 Throwawayname: Will try booting ubuntu 11.04 livecd
15:25 imirkin: pmoreau: fyi, i'm getting closer to being happy with the full nv50 compute series. in the meanwhile, were you going to look at the remainder of the "prep" patches?
15:26 imirkin: the full series has gained "indirect" compute, compute invocations counter, and a variety of fixes. most reasonable tests pass for me now.
15:33 imirkin: kherbst: fyi, going to push that nv50 prep-for-compute mr unless i hear objections today
15:34 kherbst: no, I think it's fine
15:35 kherbst: I can take a look, I just don't know if I feel motivated enough today
15:36 kherbst: will probablye at least check the codegen changes
15:36 kherbst: ohh one thing
15:37 kherbst: imirkin: I just hope we don't have stale mkImms with 16/8 bit values elsewhere which could cause issues
15:39 imirkin: kherbst: only place that 16-bit stuff was used previously was mul lowering
15:39 imirkin: kherbst: oh, you mean like a mkImm(uint16_t) which was getting upgraded to uint32_t before but now won't be?
15:39 imirkin: i doubt it'll matter
15:40 kherbst: yeah... I hope so too
15:41 imirkin: basically i use the 16-bit stuff a lot in the image load/store logic where i pack/unpack various formats
15:41 imirkin: and also for coordinate manipulation to make 3d -> 2d
15:41 kherbst: sure