01:15 nyef: ... Ye gods, manadatory filesystem checks at boot suck. No progress indicator, no *bluetooth* running...
01:20 agent_sm1th: Why is NV130 missing from this table? https://nouveau.freedesktop.org/wiki/FeatureMatrix/
01:22 imirkin: because there's no accel support due to nvidia not releasing signed firmware
01:23 imirkin: once that's available it'll be the same level of support as maxwell
01:23 agent_sm1th: Ah I thought they didn't sign Maxwell as well
01:23 imirkin: GM10x doesn't require signatures, GM20x does
01:24 imirkin: however they've released a small fraction fo the firmware for GM20x
01:24 imirkin: which is enough to get basic accel going, but not enough to change frequencies
01:25 agent_sm1th: So my best bet if I want to run free drivers is to buy a Maxwell GPU at the moment.
01:25 imirkin: i'd recommend kepler over maxwell
01:25 imirkin: with kepler you get reclocking
01:25 nyef: In my idle moments, I've been wondering... If the nouveau drivers were ported to windows, and could do all of the various directx things and opencl and whatnot, would that be enough to remove the incentive for nvidia to maintain the blob as a separate driver?
01:26 imirkin: separate from what?
01:26 nyef: Separate from nouveau.
01:26 agent_sm1th: imirkin: *googling intensifies*
01:27 agent_sm1th: AMD GPUs has no free drivers available at all right?
01:27 agent_sm1th: have*
01:27 imirkin: agent_sm1th: if you're looking for the fastest gpu that nouveau runs ok on, GTX 780 Ti
01:27 imirkin: agent_sm1th: all AMD GPUs have free drivers
01:27 agent_sm1th: imirkin: thank you
01:27 imirkin: [all recent GPUs, that is]
01:27 nyef: Basically, can nouveau get to be good enough, and cover enough of the bases, that nvidia starts having trouble justifying maintaining a proprietary driver?
01:28 imirkin: nyef: theoretically conceivable, but practically, a team of 0.5 people is unlikely to beat out a team of 1000 people with hw/docs access.
01:28 agent_sm1th: They do? Then why do people that care about freedom bother with NVIDIA?
01:28 nyef: I know.
01:28 imirkin: agent_sm1th: don't ask me
01:29 imirkin: agent_sm1th: some people apparently take issue with the fact that some firmware is required to sit on their hard-drives rather than a CMOS chip on the board
01:29 nyef: I know why I'm running nvidia: On one system, it's what's installed. On another, for the hope at getting stereoscopic 3D working.
01:29 imirkin: but in the age of 1TB hd's, sacrificing 1MB doesn't seem *so* egregious...
01:31 nyef: ... Which actually brings me to another thing I've been wondering about, and having trouble finding anything useful with google: What's the current situation with stereoscopic 3D, either via HDMI or the 3D vision kit, or whatever?
01:32 nyef: (And not necessarily using nVidia hardware. I saw something about an intel driver getting HDMI 3D support?)
01:33 imirkin: 3D support is in the early days
01:34 imirkin: not a lot of the relevant display hardware lying around
01:35 nyef: That's fair, I guess.
01:36 nyef: Where should I start looking, both for getting things running and for, well, getting things running better?
01:36 agent_sm1th: With regard to AMD, I found this:
01:36 agent_sm1th: - "The open source Radeon drivers require nonfree firmware for
01:36 agent_sm1th: acceleration, so it won't work on free systems."
01:36 agent_sm1th: - "As far as I'm aware, there is no reverse-engineering effort with AMD GPUs, which means paradoxically that AMD cooperating half-way is even worse for our community than not cooperating at all, like Nvidia does."
01:36 agent_sm1th: Source: https://trisquel.info/en/forum/amd-radeon-8330-graphics-trisquel
01:36 agent_sm1th: Lol @ that last quote
01:37 imirkin: yeah, i totally don't get that line of reasoning tbh
01:37 imirkin: who cares about the firmware
01:37 imirkin: are they also up-in arms that the HDL for their CPU isn't out in the open? wtvr.
01:39 nyef: "Can the free drivers work with the non-free firmware? Is the non-free firmware available gratis if you have the hardware? If so, what's the problem here?"
01:42 agent_sm1th: Is firmware for GPUs ever updated?
01:42 imirkin: rarely.
01:43 imirkin: basically never.
01:43 Tom^: i would rather say that people sort of didnt knew about firmware until it got placed on their hdds :p
01:44 agent_sm1th: I sympathise with people that care about free firmware, but that might be out of ignorance. :D
01:45 imirkin: i mean sure, i'd love for firmware to be free
01:46 imirkin: but it seems orthogonal to having a free driver stack on your pc.
01:48 nyef: Hrm... "MPC89 [GeForce 320M] (rev a2)"... And of *course* the font size is wonky.
01:48 nyef: ... Tesla?
01:49 nyef: Tesla. NVAF.
01:50 imirkin: yes.
01:50 imirkin: only ever shipped in macbooks
01:50 nyef: This is a Mini 2010. Am I likely to have any issues with this hardware and Linux 4.10?
01:51 imirkin: yes
01:51 nyef: (I mean, I'm expecting a subscription worth of issues, really, but I'm hoping that none of it is at the KMS driver level or basic 2D or 3D functionality.)
01:53 imirkin: well, all tesla chips hit a bug in nouveau where Sometimes Shit Goes Wrong (tm)
01:53 imirkin: separately, i remember a few nvaf-specific issues (or so it seemed)
01:53 nyef: Damn.
01:54 agent_sm1th: Minifree, a company that only ships computers with Stallman-level freedom (i.e. free boot firmware), has this as their new product: https://minifree.org/product/libreboot-d16/
01:54 imirkin: some people hit them, others didn't
01:54 agent_sm1th: Comes with a GTX 660 Ti or 670
01:54 imirkin: agent_sm1th: the firmware nouveau uses is fully open
01:54 nyef: And with my luck, it'll be somewhere that I'm not looking to debug.
01:55 agent_sm1th: imirkin: "EXTFW means that the feature is usable, but requires firmware from the binary driver."
01:55 agent_sm1th: or is that only for video acceleration?
01:55 agent_sm1th: which is optional
01:55 imirkin: agent_sm1th: only for video accel, and yeah, that requires firmware from blob
01:56 imirkin: video decoding accel
01:56 agent_sm1th: Alright, thanks.
01:59 agent_sm1th: Why is reclocking important for performance by the way?
01:59 imirkin: the gpu's boot clock speeds are very low for kepler+ gpu's
02:00 imirkin: so instead of, say, 1000mhz, it's 50mhz
02:00 imirkin: as you can imagine, that leads to some perf differences :)
02:00 agent_sm1th: Ah...
02:00 agent_sm1th: And it will stay stuck at that value.
02:00 imirkin: reclocking is the process of changing the clock speeds
02:02 agent_sm1th: Yes I figured :D
02:02 agent_sm1th: Too bad you can't change the initial clock to just have it run at max then.
02:05 agent_sm1th: Oh wow, GTX 780 ti performance sits just above GTX 1060.
02:05 agent_sm1th: Not bad.
02:05 nyef: Hrm. Does a thunderbolt port count as a displayport, or is it something else?
02:05 agent_sm1th: It's something else.
02:05 agent_sm1th: You can tell because Wikipedia doesn't redirect you, for one thing.
02:06 agent_sm1th: https://en.wikipedia.org/wiki/Thunderbolt_(interface)
02:06 agent_sm1th: I was wrong!
02:07 nyef: Yeah, looks like a displayport to me! (-:
02:07 agent_sm1th: The port is different, but it supports the Displayport protocol.
02:07 agent_sm1th: Right...?
02:08 agent_sm1th: http://imgur.com/qFZr4w5l.png
02:09 agent_sm1th: Yeah you're right.
02:11 Tom^: imirkin: has karols reclocking patches not gone upstream yet?
02:11 Tom^: havent been aroudn in months i think
02:13 nyef: Searching the bug database for "tesla" and "nvaf" (separately) doesn't find much beyond some graphics corruption specifically on nvaf, and that latter not necessarily recently.
02:14 imirkin: Tom^: they're in 4.10, at least most are
02:14 Tom^: ah nice
02:14 imirkin: nyef: yeah, the gfx corruption on nvaf is what i was thinking of
02:14 imirkin: nyef: search around for 406040 for the general tesla issues
02:14 imirkin: [and 400040 iirc?]
02:16 agent_sm1th: When I look at all the work put into nouveau I start to think creating a GPU from scratch would have been easier. :-}
02:17 nyef: Once again, google proves to be spectacularly useless. /-:
02:17 nyef: agent_sm1th: Consider the costs of chip fabrication, and then board fabrication. You might change your mind.
02:18 imirkin: not to mention design ;)
02:18 agent_sm1th: nyef: Also, NVIDIA has 9200 employees, I'm probably not realizing how much work they put into the whole thing.
02:29 nyef: Is the multithread context problem a userland-only thing or does it also affect the kernel driver?
02:30 imirkin: mostly userland
02:31 nyef: Is it an actual system crash, or just the processes that are trying to run more than once context?
02:31 imirkin: well, userspace ends up submitting various bs which ends up causing the gpu to hang in a way that nouveau doesn't recover
02:31 imirkin: (which, in general, is pretty easy to do)
02:31 imirkin: nouveau recovery from gpu hangs sticks
02:31 imirkin: stinks
02:32 nyef: Okay, so total system crash, basically.
02:32 imirkin: sometimes, not always
02:33 nyef: I'm more assessing for scope of hardware required if I'm going to try to test it or work on it.
02:33 imirkin: a separate system you can hang again and again is quite nice
02:33 imirkin: doing it on your dev box is ... undesirable
02:34 nyef: Exactly.
02:34 imirkin: also i'd highly recommend a box whose primary gpu is !nvidia
02:34 nyef: It's not like trying to get the 3d vision drivers going, after all.
02:34 nyef: Oh?
02:35 imirkin: that way you can more easily do bad things to the nvidia gpu and then recover it by doing hard pci resets and whatnot
02:35 nyef: Ah.
02:35 nyef: Yeah, not quite an option in my situation.
02:38 agent_sm1th: Is there any reason why reclocking is not included in the Feature matrix?
02:38 agent_sm1th: Is it GPU specific or something?
02:38 nyef: It's part of power management?
02:39 agent_sm1th: nyef: I see thank you.
02:43 imirkin: the feature matrix isn't logically arranged
02:43 imirkin: it needs to be rethought
02:43 imirkin: it probably made sense back when the RE for all those units had to be done
03:03 nyef: I guess my next steps on the sterographic 3D are to look through the mesa code to see if/how it handles it, to look through the kernel code to see if/how it does the HDMI version (across the intel, amd, and nouveau backends), and to figure out the @!$%! 3d vision emitter a bit better.
03:04 imirkin: the open userspace stack doesn't handle it at all
03:06 nyef: I see.
03:06 nyef: Or, well, I don't see yet, but I plan to take a look. (-:
03:06 imirkin: nvidia had a thing which allowed you to make stereo visuals
03:06 imirkin: however i don't think that's particularly positively regarded nowadays
03:07 imirkin: there's an egl ext...
03:07 imirkin: which i naturally can't find
03:08 imirkin: EGL_EXT_multiview_window
03:08 imirkin: and related items
03:08 imirkin: which i think is the cool new way to do stereo
03:10 nyef: Some of the stuff in src/amd/ seems to indicate support for quad buffers.
03:11 imirkin: quad buffering :)
03:11 imirkin: which is separate from quad buffers
03:11 nyef: Okay, yeah, quad buffering.
03:11 nyef: Right, four buffers, not buffers for geometric quads.
03:12 nyef: (Four buffers, one for each eye!)
03:15 nyef: The amd kernel driver definitely has some support for stereographic output.
03:16 nyef: ... nouveau might be the odd one out here?
03:18 imirkin: maybe. like i said, i don't think it actually works anywhere
03:19 nyef: Mmm. And it's not like I can test: I don't have any non-nVidia hardware with HDMI ports.
03:55 imirkin: nyef: on the userspace side, i think the current thinking is that the *multiview* extensions are the way to go. but i'm no expert on it by a long shot
04:04 nyef: Okay, so we're both rather in the dark here, but I have enough to continue with for the time being. (-:
06:08 funfunctor: mwk: Hello?
06:10 funfunctor: I spent a few days trying to make heads or tails of this C++ library for this blackmagic driver. I think I am going to get nowhere with it and I just just treat it blackbox
06:10 funfunctor: what do you think?
06:11 funfunctor: its just heaps of indirection and getter/setters for class members that are offsets of rdi but need not necessarily be aligned unless by chance they fit C++ standard layout requirements (which seems unlikely if they used the private keyword at all).
12:37 foox: hey all.. Just got a new mainboard (laptop) and it seems that the display port doesn't get recognized by xrandr. In xorg.conf DP-1-{1,3} gets mentioned and for DP-1-3 it printed probed modes .. but still not available in xrandr and thus not usable. Any suggestions how to get it working again?
12:40 karolherbst_work: foox: https://nouveau.freedesktop.org/wiki/Optimus/ "Using outputs on discrete GPU"
12:49 foox: karolherbst_work: thanks! according to vgaswitcheroo the nvidia card is DynOff .. connecting the graphics connectors to the discrete gpu does not seem to change anything
12:50 karolherbst_work: mhh
12:50 karolherbst_work: odd
12:50 karolherbst_work: is the display on?
12:51 karolherbst_work: mhh
12:51 karolherbst_work: ohh wait
12:51 karolherbst_work: maybe just set it up in xrandr
12:51 karolherbst_work: I never had to do that
12:58 foox: karolherbst_work: xrandr does not show the connector. I've seen many issue reports where "disconnected" displays are shown. But for me, I cannot see it at all (except in the xorg log)
12:58 foox: brb, updated kernel and have to reboot
13:32 foox: karolherbst_work: thanks for your support.. I'm still struggling with the issue, but give up for now. Have a nice day!
19:00 nyef: Hrm. DPCD_SC00_SET_POWER_D3 still looks wrong in -rc2.
19:01 nyef: skeggsb: Are you the person to talk to about this? It's in nvkm/engine/disp/dport.h, the file has it at 0x03, but the DisplayPort spec (and the generic DRM code) have it as 2.
19:02 imirkin_: i thought DP spec was closed...
19:04 nyef: I found a 1.1a spec kicking around online somewhere.
19:04 imirkin_: ah ok
19:04 imirkin_: i'm not 100% sure that ben has access to a spec. i think he mostly just looks at blob traces
19:05 imirkin_: what does that spec have as 3? perhaps it's just the cmd name that's wrong...
19:05 nyef: The field mask. The only valid values for the field are 1 and 2, leaving 0 and 3 as reserved.
19:06 imirkin_: oh. well it's not used anywhere :)
19:07 imirkin_: probably just a typo
19:08 nyef: Err... Wha? Could have sworn it was.
19:08 imirkin_: D0 is
19:08 nyef: Yeah, I see that now.
19:08 nyef: Hrm.
19:08 nyef: That's a possible call for more power management work, actually.
19:08 imirkin_: quite possible. i would have assumed something in DPMS-land would do it
19:09 nyef: Exactly.
19:09 nyef: See drm_dp_helper.c, drm_dp_link_power_down().
19:10 nyef: Okay, so a bug, but not one with an observable effect at this time. Good enough, I guess.
19:11 imirkin_: ah, the other logic is in nouveau_connector.c
19:11 imirkin_: which writes DP_SET_POWER_D3 over the aux channel
19:11 nyef: Ah.
19:11 imirkin_: which presumably has the correct value
19:11 nyef: ... Why do we have separate constants for it, then?
19:11 imirkin_: generally nvkm is meant to be in its own little hermetic land without any drm dependencies.
19:12 imirkin_: also, i don't know that the shared stuff existed originally
19:12 nyef: Yes, DP_SET_POWER_D3 is 0x2, which is correct.
19:13 imirkin_: anyways, would be good to fix the duplicate definition lest someone try to use it and wonder why it's not working
19:14 nyef: Good-to-fix, yes. Critical-to-fix-for-4.10, no.
19:14 imirkin_: right.
19:17 nyef: An E-EDID is typically more than 128 bytes, isn't it?
19:17 imirkin_: yes.
19:17 imirkin_: the last byte has a bit that tells you whether there's another block iirc
19:17 imirkin_: er, the last byte of the first 128 that is
19:18 nyef: Thought that was a checksum?
19:18 imirkin_: then another byte ;)
19:18 imirkin_: right. the one before that.
19:18 imirkin_: at 0x7e
19:19 imirkin_: https://cgit.freedesktop.org/xorg/app/edid-decode/tree/edid-decode.c#n2030
19:19 nyef: Ah, the next-to-last-byte is the number of extra pages.
19:19 nyef: Okay, so this is a full dump, good to know.
19:19 imirkin_: well, note that depending on the connector, the monitor may return different EDIDs
19:19 nyef: The eDP panel that I've been struggling with recently. Only one connector. (-:
19:20 nyef: But thank you for the warning, I'll try to keep it in mind if I need to look at hardware with more than one connector type.
19:29 nyef: ... Looks like both eDP panels (the one in my test machine and the one in my main machine) have the same EDID, which isn't a huge surprise.
19:32 imirkin_: sometimes there's a serial number embedded
19:32 imirkin_: apparently not here
19:33 nyef: Yeah, I wouldn't have been surprised if they differend in minor things like serial number, manufacture date, and the like.
19:33 nyef: I'd've been more surprised if they differed in capability in some way.
19:34 imirkin_: my 2 identical monitors only differ in serials
20:04 nyef: ... Re-reading, these EDIDs have one extension page, which did get dumped. I'm feeling semi-clueless today.
20:06 imirkin_: nyef: use that edid-decode app i pointed you to
20:08 nyef: imirkin_: Right now I'm more interested in making sure that I have the raw bits handy than seeing what they say.
20:10 nyef: ... And I have all of the EDIDs that I need-and-can-get from where I am now. I should be able to get another one in about a week.
21:13 karolherbst: who is gonna go to sha2017? Would be nice to do something nouveau related there
22:48 NanoSector: anyone i can poke to debug sleep issues? :)
22:49 nyef: NanoSector: Please, please tell me it's a problem with an eDP laptop panel resuming from sleep?
22:50 NanoSector: nyef: probably? with nouveau my screen is either completely black or hangs at the first frame or something
22:50 NanoSector: and i can't SSH in my machine or anything
22:50 NanoSector: (but yes, it is a laptop)
22:50 nyef: What sort of laptop, and have you tried the latest drm-next kernel?
22:50 NanoSector: it's an Acer Aspire V7 Touch with i5 4200U and a GeForce GT750M 4GB DDR3, I've tried linux-git a week or so ago but that didn't fix anything
22:51 NanoSector: using the nvidia kernel module it's fixed
22:51 imirkin_: NanoSector: are you sure the panel is hooked up to the nvidia gpu?
22:51 NanoSector: imirkin_: it's hooked up to Intel
22:51 imirkin_: [have we had this discussion?]
22:51 NanoSector: this is an Optimus laptop
22:51 NanoSector: maybe?
22:51 NanoSector: my memory is shite
22:51 imirkin_: so is mine
22:51 imirkin_: the refresh interval is too low =/
22:51 NanoSector: :)
22:52 imirkin_: anyways, if the panel is hooked up to the intel gpu, this is a intel driver problem.
22:52 NanoSector: but why would installing the nvidia driver fix this, then?
22:52 imirkin_: that's definitely odd :)
22:52 NanoSector: I'm thinking nouveau hangs my system on resume or something
22:52 imirkin_: perhaps it's not as attached to the intel gpu as you thought?
22:52 imirkin_: well, if you can ssh in, probably not...
22:52 NanoSector: i can't
22:52 imirkin_: oh wait. you *can't* ssh in
22:53 imirkin_: that's different.
22:53 NanoSector: it is wired up to intel because I can shut off my nvidia gpu completely
22:53 imirkin_: so then it's somewhat likely that nouveau resume is messed up
22:53 NanoSector: someone poked me that there was something about mutliple resume code paths (don't remember the nickname.. :\ )
22:53 imirkin_: are you running with runpm=0 by any chance?
22:54 NanoSector: nope, no kernel parameters related to nouveau
22:54 imirkin_: yeah, there's also a way to do a suspend without actually doing i
22:54 NanoSector: [ 0.000000] Command line: initrd=\intel-ucode.img initrd=\initramfs-linux.img root=PARTUUID=520cfd21-35da-4088-94ae-928ca7d56d30 rw quiet splash resume=PARTUUID=520cfd21-35da-4088-94ae-928ca7d56d30 resume_offset=176128
22:54 imirkin_: it's useful for testing the suspend/resume paths
22:54 imirkin_: and you can usually get more info out of it
22:54 NanoSector: hmm?
22:55 NanoSector: how would i do such a thing?
22:56 imirkin_: [working on that]
22:56 NanoSector: ah :P
22:56 imirkin_: aha
22:56 NanoSector: nyef: why were you so eager to see someone with that specific issue? :P
22:56 imirkin_: NanoSector: do you have a /sys/power/pm_test ?
22:56 NanoSector: lessee
22:57 NanoSector: yep
22:57 imirkin_: NanoSector: it seems like you could do like "echo devices > /sys/power/pm_test; echo mem > /sys/power/state"
22:57 NanoSector: and that'd throw everything in dmesg?
22:57 imirkin_: ideally yes. i'd recommend ssh'ing in and running "dmesg -w" in parallel
22:59 NanoSector: doing that
22:59 NanoSector: will have to do that via my phone though so might be a little slow with uploading stuff
23:00 imirkin_: it's just to make sure that if the box dies, you still get to see the results
23:00 NanoSector: imirkin_: i915 reported a gpu hang but it did fix it this time, it never fixes it otherwise
23:01 imirkin_: huh?
23:01 NanoSector: i'll upload dmesg
23:01 imirkin_: perhaps i915 ends up trying to wait on nouveau completing something which will never happen as it's suspended?
23:01 NanoSector: i've no clue
23:02 NanoSector: imirkin_: https://nanosector.nl/log.txt
23:03 imirkin_: interesting.
23:03 imirkin_: (i obviously have no idea)
23:03 imirkin_: looks like it happens on resume
23:04 NanoSector: also nouveau keeps waking and shutting down my GPU for seemingly no reason (I never use DRI_PRIME=1 or anything), but that's a separate issue
23:05 imirkin_: dunno. perhaps it has a phantom output that something keeps polling?
23:06 NanoSector: how do I check?
23:06 NanoSector: xrandr reports eDP-1, HDMI-1, DP-1, HDMI-2
23:06 imirkin_: hm ok, then it's unlikely.
23:06 NanoSector: I have my laptop screen, a mini DP port, and an HDMI port
23:06 NanoSector: so i'm not sure where that second HDMI comes from
23:07 imirkin_: you could check `ls -d /sys/class/drm/card*-*`
23:07 NanoSector: all on card0
23:07 imirkin_: so no outputs. i got nothing.
23:07 NanoSector: :D
23:07 NanoSector: no worries
23:11 NanoSector: imirkin_: anyways, should I ask in the intel driver channel for this one?
23:12 nyef: NanoSector: The eDP panel fails to resume after suspend issue? Because it's the issue that I was struggling with for about the past week and a half, before finally figuring out what was going on yesterday morning.
23:12 NanoSector: nyef: tell me if i can try anything :)
23:12 imirkin_: NanoSector: it'd be a start
23:13 NanoSector: would you happen to know which channel that is? #intel sounds too generic to me
23:13 imirkin_: #intel-gfx
23:13 NanoSector: thanks
23:16 NanoSector: imirkin_: asked in there, will report if I get anywhere
23:16 nyef: Hrm. At some point during the next week I need to recapitate my test machine and do an mmiotrace of the blob with the LVDS panel, so that I can see what, if anything, happens with the GPIOs and the eDP HPD, because it seems wasteful to leave the GPIO on if there's nothing attached to the port...
23:17 imirkin_: ok, well it's a lot of the same people in all the various graphics chans :)
23:17 NanoSector: imirkin_: ah your non-_ version is in there :P didn't notice
23:42 NanoSector: imirkin_: the intel error log mentions kwin_x11 being the last process to take care of it so i wonder if it is anything to do with it
23:44 mooch2: mwk: any idea what this does on nv4 https://github.com/envytools/envytools/blob/master/rnndb/bus/pci.xml#L310
23:44 mwk: mooch2: it controls the behavior of the PCIROM mapping, aka BAR6
23:44 mooch2: what would writing 0 to it do?
23:45 mwk: if set to 1, read accesses to PCIROM will be forwarded to PRAMIN, ie. BAR0+0x700000
23:45 mooch2: because that's the last thing these drivers seem to do
23:45 mwk: if set to 0, they will be forwarded to BAR0+0x300000
23:45 mooch2: which is prom?
23:45 mwk: yep
23:45 mooch2: ah
23:46 mwk: also, on early cards, I think <NV30, PROM is disabled if this is set to 1, so you can't read from it at all
23:46 mwk: so it's necessary on NV4 to disable shadowing to read from PROM
23:46 mooch2: so i currently always have it point to prom, and it writes 0 to that reg
23:47 mooch2: it also reads from 10000 and 10010???
23:47 mwk: uhh.
23:47 mwk: what GPU is that?
23:47 mwk: NV4?
23:47 mooch2: yeah
23:47 mwk: wtf
23:47 mooch2: nv4 drivers too
23:47 mwk: how old are the drivers?
23:48 mooch2: they're the latest
23:48 mooch2: for nt4
23:48 mooch2: 71.84 i think?
23:48 mwk: any idea what's the newest supported card for them?
23:49 mooch2: nv40 series it seems
23:49 mwk: alright
23:49 mwk: I think these registers are just nonexistent on NV4, but someone forgot a condition in the driver
23:50 mwk: should be safe to read those as 0
23:50 mooch2: ah
23:50 mooch2: k, that's what i'm currently doing
23:50 mwk: it does *something* on NV4x
23:50 mwk: related to reading PCI config memory of neighbouring devices, I think
23:50 mooch2: ah shit, i think it's requiring me to hook up prom
23:50 mooch2: in bar0, that is
23:51 mwk: well, messing with rom shadow is a strong indicator of wanting to read PROM :)
23:56 mooch2: OKAY THAT WORKED