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