01:00hrw: printk() rulz
01:14directhex: hello, nouveau people. i'm working to add support for nouveau to a distro which currently hard-codes nvidia-glx for all nvidia gpus. i've got it working with the current software versions in the archive, but it's *really* unstable
01:15directhex: my suspicion is it's kernel-side stuff in desperate need of updating, but i'd like a quick sanity check
01:15hrw: directhex: on which cards and which kernel version? (just asking as I do not develop)
01:16directhex: hrw: my test card is a "gt210", which should be covered by nouveau's nv50 code path
01:17directhex: hrw: kernel is a patched 3.10, at https://github.com/ValveSoftware/steamos_kernel
01:17RSpliet: NolanSyKinsley: I've seen something similar happen with DOTA2. Are those open source games you're testing?
01:17RSpliet: directhex: I'm not sure what that really is, but you want something way newer
01:19directhex: updating the kernel wholesale isn't happening. specific backports i guess are *possible*, as long as there's little to no impact on code used by intel graphics. out-of-tree is easy(ish)
01:19NolanSyKinsley: RSpliet, nope, Space Engineers (windows only, running through WINE trying to get the Gallium Nine patch working) and Cities: Skylines which is linux native but unity3d based so mono
01:20RSpliet: NolanSyKinsley: ok.. hmm... sorry, I'm not particularly sharp today, but would you mind filing a bug for that?
01:23hrw: imirkin: nouveau_accel_init() calls channel_new() which calls channel_ind(). this one tries to create channel object by going in a loop with kepler/fermi/g82/nv50/0 and if does not create (which is a case on 7300se==nv46) it calls channel_del(). this one do lot of stuff and then go to nouveau_bo_ref() which calls ttm_bo_unref and OOPS happens
01:24mlankhorst: hrw: get a newer card. :P
01:25hrw: mlankhorst: I know that this is one of solutions
01:25mlankhorst: probably the cheaper one too
01:25hrw: mlankhorst: but I do not plan to spend any money on another pile of gfx cards
01:26mlankhorst: hrw: channel_ind should not be called for a nv46..
01:26mlankhorst: nouveau_channel_dma should be
01:26hrw: especially when 'a newer' one starts at 40€
01:27NolanSyKinsley: hmm... interesting, RSpliet I tried other 3d games and they seem to work, kairo works fine. I even loaded another unity3d game and it ran fine. So apparently the two games I actually want to play are the two games I can't >.<
01:27mlankhorst: oh seems like channel_ind should fail
01:27mlankhorst: but channel_dma should succeed
01:30directhex: is there an easy(ish) way to determine whether X crashes are caused by the xf86 driver, by mesa/gallium, or by the kernel? i'd rather not go into things blind
01:31hrw: mlankhorst: commented ttm_bo_unref and module loaded fine
01:31NolanSyKinsley: Did I say works? I meant mostly works...http://i.imgur.com/jyyyRzP.png
01:32RSpliet: the two games are likely suffering from the same bug
01:32RSpliet: I'm guessing a texture sample thing
01:34NolanSyKinsley: well, KSP is another unity3d/mono game and it has a tezxture bug as well, so...
01:37hrw: mlankhorst: accel_init checks for >= kepler and calls channel_new() or chipset => a3 (!aa !ac) and calls channel_new() and then call channel_new() anyway. channel_new() does not check chipset at all and calls channel_ind() and if it succeed (ret true) then calls channel_dma()
01:38mlankhorst: just check arch >= 50 or something
01:38hrw: as "if arch > 50 then channel_ind()"?
01:40mlankhorst: i think TESLA is the first one for which channel_ind is useful..
01:40mlankhorst: but tbh you should figure out why unref fails
01:41mlankhorst: it will probably ail again for other stuff too
01:48hrw: I start to hate pcie controller in xgene
02:02hrw: [ 181.078480] nouveau E[ PFIFO][0000:01:00.0] DMA_PUSHER - ch 0 [DRM] get 0x0000da64 put 0x0000da98 state 0x80000000 (err: INVALID_CMD) push 0x00000000
02:02hrw: lot of such ones when channel_ind() is not called
04:42imirkin: NolanSyKinsley: if you can put up a short apitrace of the failing programs, i can take a look. but first make sure you're on the latest mesa. (what mesa are you on btw?)
04:42imirkin: directhex: you're going to have to be a lot more specific in the types of issues you're running into if you're looking for assistance.
04:43directhex: hm, i think i spotted a rogue hashset
04:45NolanSyKinsley: but, as it is currently 4:40 am, I am off for now, I will be back later, also after I learn how to apitrace...
04:45imirkin: NolanSyKinsley: ok, that's plenty recent. apitrace would be nice. as you noticed, not _all_ games are messed up. oh, could you try running with NOUVEAU_SHADER_WATCHDOG=false in the environment?
04:48directhex: i *did* spot a rogue hashset. i actually have it working.
04:48directhex: also, i thought i was in a different channel. bloody netsplits
04:50directhex: imirkin: i'm trying to shoehorn nouveau into steamos, for cards not supported by the bleeding edge nvidia-glx they provide. it works! until it crashes. it crashes a lot. mostly when the steam client starts, or when trying to view steam's system information page.
04:50imirkin: and what does "crash" mean?
04:54directhex: let me swap the right gpu in so i can answer that accurately
04:57imirkin: directhex: also avoid nv50-era gpu's with GDDR5 vram
04:57imirkin: although those will basically not work at all with a 3.10 kernel
04:57imirkin: (there are *very* few such gpu's, but just fyi)
04:59directhex: the spec sheet says DDR3. no wonder it sucks.
04:59imirkin: gddr5 was very rare back then
04:59imirkin: a few GT21x's ended up with it, but it was still the *vast* minority of boards
05:00directhex: it's a new card. it's just old & crap. i wanted the cheapest card without nvidia-glx i could get
05:00imirkin: [and GT21x has little to no connection to GeForce GT xxx btw]
05:00directhex: yeah i know. all i needed was "not in nvidia-glx 346"
05:01imirkin: right :)
05:01imirkin: btw, i assume there's some deeper reason why you can't just grab the latest upstream kernel?
05:02imirkin: not that i'm suggesting it would fix these issues (since i have no idea what issues you're experiencing)
05:02directhex: i'm trying to make a modified steamos. valve's kernel for steamos 1.0 is 3.10 w/ relevant backports
05:02imirkin: ... and you can't replace the kernel because...
05:03directhex: i don't want to lose valve's patches, and i don't particularly want to play the game of maintaining relevant cherry-picks forward
05:04imirkin: ok. well if it does end up as a fixed-in-kernel situation, you could always provide a nouveau kernel and a everything-else kernel
05:04imirkin: but we haven't gotten to that
05:04directhex: how self-contained is nouveau's kernel end? i.e. how much is in nouveau.ko, how much is in drm.ko etc?
05:05RSpliet: nouveau's nvkm half is self-contained (core in older versions)
05:05RSpliet: but not API-stable
05:05imirkin: the problem is the drm <-> nouveau api
05:05imirkin: the drm api has changed a bunch since 3.10
05:05RSpliet: not even sure if 3.10 already had the nice split into core
05:05imirkin: as has the nouveau <-> nvkm api
05:06imirkin: the split happened in 3.8
05:06imirkin: but it's been iterated on
05:08directhex: if it's relevant to intel, it's backported, afaik.
05:09directhex: ok, so... https://gist.github.com/directhex/f120d44147141f0e18a0 is the "crash" when accessing system information. which clearly makes no sense
05:12directhex: let's trigger another
05:12imirkin: directhex: that's not a crash... that's X shutting down gracefully
05:13imirkin: directhex: pull up a terminal and pastebin the output of 'glxinfo'
05:13directhex: a bit more verbose this time. https://gist.github.com/directhex/e75b1364faaaf838b20a
05:13imirkin: hm ok
05:14imirkin: that would definitely be bad...
05:15imirkin: btw, i know you think you're doing me a favor by cropping the various logs, but in actuality, it's hurting my ability to tell what's going on
05:15directhex: glxinfo: https://gist.github.com/directhex/d3e3972b9a9e16ab6a1e
05:16imirkin: that's a really old mesa...
05:16imirkin: i'd definitely recommend at least updating mesa and libdrm
05:19imirkin: directhex: another question is... do you know if the steam application starts up multiple GL contexts used simultaneously from diff threads?
05:19imirkin: if it does, nouveau is sunk
05:19imirkin: long-standing issue that nobody has really cared about since it never happens in practice
05:20directhex: i don't know about the threading behaviour of big picture mode, since it's closed source
05:21directhex: libdrm is 2.4.58
05:21imirkin: oh, that's pretty recent
05:21imirkin: why is mesa so incredibly old then?
05:21directhex: it was 9 when they shipped
05:22imirkin: so it used to be even older? not sure that that makes me feel better :)
05:22directhex: there's some cherry-picking going on in their mesa branch. https://github.com/ValveSoftware/steamos_mesa/commits/alchemist-10.1
05:22imirkin: no nouveau bugfixes
05:22imirkin: since the 10.1.6 release
05:23imirkin: of which there have been a number... although nothing accounting for what i saw in that dmesg
05:24directhex: full dmesg: http://paste.ubuntu.com/10683495/
05:24directhex: full xorg.log: http://paste.ubuntu.com/10683497/
05:25imirkin: a number of interesting tidbits
05:25imirkin: like ancient X server version
05:25imirkin: and you're still loading the blob driver although it ignores the card
05:26imirkin: but you're loading the proper libglx.so and whatnot, so as long as the blob driver doesn't actively mess things up, should be fine
05:26directhex: the blob module isn't persisting, i don't see it on lsmod
05:27directhex: so unless it's leaving an unknown card in a shitty state, i'd hope that's benign
05:27imirkin: the load fails
05:27imirkin: i would hope that as well ;)
05:27directhex: sadly, amd has a strict alias: list on their module for supported cards. nvidia has a catch-all for 10de
05:27imirkin: as does nouveau :)
05:27imirkin: too many pci ids to keep track of
05:29directhex: i upgraded the xf86 module to almost-master
05:29directhex: (it was 1.0.1 previously)
05:29imirkin: yeah, i saw
05:29imirkin: sorry, no real words of wisdom from me =/
05:30directhex: anecdotally seems to not crash on startup as much. gracefully shutdown for no good goddamn reason, sorry. but still the system information page is screwy
05:30directhex: made it really hard to prove i had it working, when that was the one reliable failure case
05:30imirkin: that page could just be doing something screwy
05:30imirkin: like creating a second context
05:30imirkin: and accessing it from a different thread
05:31imirkin: which is a perfectly legitimate thing to do... just nouveau fails at it
05:33directhex: so nothing from my pastes tells you "hey directhex, that's definitely mesa" or "hey directhex, that's definitely drm"?
05:33imirkin: directhex: also note that kernel 3.19 picked up support for reclocking GT21x gpu's... not a stability improvement, but might be relevant to people playing games
05:34imirkin: well, that first message is about an unknown handle
05:34imirkin: which means that either mesa fed in an unknown handle
05:34imirkin: or nouveau drm somehow lost track of that handle
05:34directhex: i'll try & badger a newer mesa on there long enough to test against
05:35imirkin: neither case sounds particularly familiar, which means that something more nefarious could be going on
05:35imirkin: i'd recommend sticking a new kernel on there as well
05:35imirkin: and if _that_ doesn't fix things, we can move on from there
05:35imirkin: and if it does, that gives you something to figure out
05:40directhex: it's a 32-bit app on a 64-bit kernel. that wouldn't be a problem would it?
05:41directhex: i know virtualbox's gl stack shits the bed at such things
05:41imirkin: vbox is broken and should not be used...
05:41imirkin: 32-bit app on 64-bit kernel is the common case for games, should work fine
05:42imirkin: just make sure that you have a 32-bit GL as well (glxinfo is probably a 64-bit app)
05:43directhex: need to set up a 32-bit builder. mumble mumble
05:45cousin_luigi: pmoreau: hello there
05:46cousin_luigi: im testing the nouveau livecd you linked me to the other day
05:46cousin_luigi: I have a gtx660 and wondered if I could stress-test it somehow. Just to find out if this kernel version would fix the problem.
05:49imirkin: what was your original problem?
05:52gordan: Hi, is there a way to get the VBIOS image out of ACPI manually?
05:53imirkin: sure, acpidump
05:53gordan: When nouveau loads, I see this:
05:53imirkin: look for the _ROM method, it'll contain the data
05:53gordan: [11268.519525] nouveau [ VBIOS][0000:01:00.0] checking PRAMIN for image...
05:53gordan: [11268.519528] nouveau [ VBIOS][0000:01:00.0] ... signature not found
05:53gordan: [11268.519529] nouveau [ VBIOS][0000:01:00.0] checking PROM for image...
05:53gordan: [11268.519564] nouveau [ VBIOS][0000:01:00.0] ... signature not found
05:53gordan: [11268.519565] nouveau [ VBIOS][0000:01:00.0] checking ACPI for image...
05:53gordan: [11269.355467] nouveau [ VBIOS][0000:01:00.0] ... appears to be valid
05:53gordan: [11269.355471] nouveau [ VBIOS][0000:01:00.0] using image from ACPI
05:53gordan: [11269.355604] nouveau [ VBIOS][0000:01:00.0] BIT signature found
05:53gordan: [11269.355607] nouveau [ VBIOS][0000:01:00.0] version 82.07.34.00.08
05:53gordan: _ROM method where exactly?
05:53imirkin: please don't flood
05:53imirkin: use pastebin if you have to paste
05:54imirkin: in the acpi data. but you can reuse nouveau's efforts and just grab it from /sys/kernel/debug/dri/0/vbios.rom
05:54gordan: It's a secondary GPU
05:54imirkin: ... then /1/vbios.rom
05:54gordan: Doesn't appear to show up in /sys/kernel/debug/dri/
05:55imirkin: do you have debugfs mounted?
05:56gordan: That's just it - in the dri directory I see 0, 64 and 128
05:56gordan: And they all have many nodes beginning with i915
05:57gordan: Which makes me think all of those are the integrated Intel GPU
05:57imirkin: nouveau must not be loaded then?
05:57imirkin: (or does it dereg its debugfs nodes when it goes into pm sleep?)
05:58gordan: It loads, lsmod shows it, but later in the dmeg output it says Direct firmware load for nouveau/nv117_fuc409c failed with error -2
05:58gordan: It's an Optimus setup laptop.
05:58imirkin: that's fine though... (btw, if you grab ben's tree, you should be able to use acceleration on it)
05:59gordan: What I am really trying to do is get the VBIOS out.
06:00gordan: So I can side-load it when passing that GPU to a VM.
06:00gordan: The VBIOS image isn't attached to the GPU's ROM, so it can't be dumped out by nvflash. It's in the system main UEFI ROM.
06:01gordan: So I extracted it from that using PhoenixTool, but it looks like the EFI header is missing (so it looks like a legacy BIOS, but has the crypto certs which legacy BOES-es usually don't.
06:01gordan: I'm hoping what comes out of nouveau's view of the ROM might be complete with the headers.
06:01imirkin: it won't be
06:02gordan: Oh. :(
06:02imirkin: do an acpidump
06:02imirkin: and look for _ROM
06:02imirkin: that's all that nouveau gets
06:04gordan: There is no section in acpidump's output with "_ROM" in it.
06:04hakzsam_: imirkin, hi, Marek has ACKed the gallium changes for GL_AMD_performance_monitor, do you have some time to review patches 11, 13-15 of the series?
06:10imirkin: which ones are those?
06:10imirkin: gordan: look harder :) it should be in the DSDT or SSDT or whatever
06:11hakzsam_: imirkin, http://lists.freedesktop.org/archives/mesa-dev/2015-March/080243.html
06:11imirkin: hakzsam_: ah ok. i'll try to review today
06:11hakzsam_: thanks :)
06:12imirkin: if i forget, keep pinging me. early and often ;)
06:12gordan: imirkin, you mean in the payload? There is one instance of _ROM, but it looks nothing like the Nvidia BIOS.
06:13imirkin: gordan: use one of the decoder tools to help you find the _ROM method
06:13imirkin: yes, in the payload
06:14imirkin: hakzsam_: btw, any comments on that other dude's response about how he wants to get rid of the perf stuff and redo it?
06:15hakzsam_: imirkin, I just saw his answer today, I probably remove the mail by mistake ...
06:15hakzsam_: I'll try to answer today
06:15imirkin: ok cool
06:17cousin_luigi: imirkin: instability
06:18imirkin: using what kernel?
06:18cousin_luigi: imirkin: 3.16
06:19imirkin: hmmm... i forget when some of the GK106 fixes happened
06:19cousin_luigi: is it something I can search in the commit log?
06:20imirkin: well, there was at least 3d9e3921f4, not sure if it was backported
06:20imirkin: that went into 3.17
06:20imirkin: and helped people with funny partition arrangments
06:21imirkin: how much vram do you have?
06:23imirkin: hmmm. dunno if that often ends up in funny partitions
06:23imirkin: wouldn't think so, but who knows
06:24cousin_luigi: imirkin: wut?
06:24imirkin: memory partitions...
06:25cousin_luigi: I should check what kind of patches my distro ships
06:30mwk: imirkin: 2gb in funny partitions is common
06:30mwk: if you have 3 parititions
06:30imirkin: anyways... i do know that a bunch of people with unstable GTX660's had their issues fixed at some point recently... and iirc that patch that i pointed out was the one that fixed them
06:30imirkin: mwk: right. i just didn't know if it was common
06:30imirkin: mwk: btw, "funny" in this case means "unequally sized"
06:32gordan: OK - found the ROM method in the disassembled output.
06:33gordan: Apologies for a noob question, but - what do I do with it?
06:33cousin_luigi: imirkin: I'll try again and see what happens.
06:33imirkin: try what again?
06:34cousin_luigi: imirkin: a new kernel
06:34imirkin: ah ok
07:17gordan: imirkin - what do I do with the disassembled _ROM method to get the BIOS dump out?
07:34imirkin: gordan: it's a sequence of bytes, right?
07:34imirkin: so just stick those bytes into a file, and enjoy? not sure what the question is...
07:40gordan: I extracted the correct DSDT, and found the ROM method
07:40gordan: _ROM even
07:40gordan: But that appears to be a method for getting the ROM, not the ROM contents.
07:40gordan: So how do I exectute this to get the ROM contents?
07:41imirkin: oh, pastebin what the method says?
07:41imirkin: in the past i've seen it just be a sequence of bytes
07:42gordan: That's the whole SSDT block.
07:43gordan: There is a _ROM method on like 2847
07:43imirkin: oh my, that's beyond my knowledge of acpi
07:43imirkin: it comes from the VBS1/2/3/4 opregions
07:43imirkin: which are inside this:
07:44imirkin: OperationRegion (VBOR, SystemMemory, 0x9CF9C018, 0x00019604)
07:44imirkin: no clue what to do with that though.
07:44imirkin: perhaps mjg59 might know, he knows various low level details
07:45gordan: Alternatively, it'd be really handy if the /sys/kernel/debug/dri included a nouveau directory with vbios.rom
07:45gordan: But for some reason it doesn't.
07:45imirkin: i have no idea why...
07:45gordan: I know for a fact it got it out of the ACPI, and parsed it, otherwise dmesg wouldn't have listed various data from it (BIOS version, clock speed ranges, etc.)
07:46gordan: But then it chokes when it can't upload the FUC and it all goes south from there.
07:47gordan: So in theory, if I can get the contents of the ROM somehow, and it is expected to be retrievable via ACPI, I'll have to make OVMF UEFI firmware somehow present the same thing via ACPI so the driver in the VM knows how to initialize the card.
07:47imirkin: that shouldn't matter
07:47imirkin: there are a few ways to feed it in...
07:48imirkin: you could also stick it into PRAMIN on the card
07:48imirkin: aka vram
07:48imirkin: the top of vram is supposed to have a copy
07:49gordan: That's what dmesg says when I load nouveau.
07:49imirkin: oh, sad
07:49imirkin: try booting with nouveau.noaccel=1
07:49imirkin: should prevent that from happening i think
07:50imirkin: skeggsb: why does failing to load fw fail all of nouveau from loading? oh, is it because it's a display-less card?
07:51gordan: Yes, it's headless.
07:52gordan: What I'm hoping to do is run a VM "headless" with a fake monitor (details of that are still hazy, didn't get far enough to experiment), run D3D apps in the VM, and stream them out to my main Xorg desktop via something like Limelight/Splashtop/Kainy
07:52imirkin: yeah, good luck with that
07:54gordan: It is kind of what bumblebee does.
07:55gordan: It runs a headless Xorg on the Nvidia card, and then copies the frame buffer to the primary monitor driving card via some GL calls for efficiency.
07:55gordan: That's what gave me the idea in the first place.
07:56imirkin: i didn't say it was impossible
07:56imirkin: you could just use skeggsb's latest repo, which should give you open-source accel on there
07:56gordan: But I can't get the driver to initialize the card in the VM because it looks like it can't get hold of the BIOS. Specifically giving KVM the BIOS image I extracted from the system BIOS didn't work, and I am _suspecting_ it's could be because that extract seems to have a front-truncated payload (no UEFI header, only the legacy BIOS header).
07:56imirkin: although without reclocking, probably won't be that fast
07:57gordan: It's not about speed, it's about the fact that some apps won't run on Linux, hence why I need the VM.
07:58gordan: Maybe the fact it's being provided via ACPI is related to it being headerless in the dump.
07:58imirkin: not really
07:58gordan: Maybe it's not a BIOS image that is expected to be POST-ed, merely used by the driver to get the info on the card.
07:58gordan: So the header isn't useful in that context.
07:58imirkin: that's more related
07:59imirkin: that vbios image is unlikely to be able to POST the card
07:59imirkin: although... who knows
07:59gordan: But the point is that, e.g. with the secondary passthrough, the card doesn't get POST-ed anyway.
07:59gordan: The driver does all of the magic, but it still needs to get the BIOS tables to know what to do with it.
07:59gordan: And that's what seems to be failing.
08:00imirkin: just stick the vbios you get from acpi into the top of pramin
08:00imirkin: nvafakebios in envytools may be able to help
08:00gordan: So _maaaaybe_ I can just use the extract I have and somehow get OVMF firmware for the VM to make it available thrugh ACPI.
08:01gordan: You mean load the BIOS into pramin before giving the card to the VM?
08:01imirkin: no, making it available through acpi will be beyond difficult
08:01imirkin: yes, i mean load vbios into pramin before loading the vm
08:03gordan: That is quite an ingenious idea. Trying it now.
08:07gordan: It would have been too easy if it worked...
08:08gordan: Except now after shutting down the VM nouveau won't load at all.
08:08imirkin: probably coz you stuck a bad bios in there
08:09imirkin: get ben's repo
08:09imirkin: that will load fully
08:09imirkin: then you can get the vbios.rom out
08:10gordan: Interestingky, loading nvidia's binary module worked, and after unloading that, nouveau now loads and unloads OK.
08:19gordan: imirkin, do you happen to have a link handy for ben's repository?
08:20gordan: Or just something more to go on?
08:21gordan: It's a bit vague for googling it.
08:25prg_: gordan, git://people.freedesktop.org/~darktama/nouveau
09:33gordan: How do I build the .ko from darktama's git? The ./scripts/nvkm-am fails at the cp stage because $@ evaulates to nothing. What's the expected sytax for invoking the script?
09:34imirkin_: cd drm; make modules
09:50gordan: /home/build/nouveau/drm/nouveau/nv50_display.c:1733:2: error: implicit declaration of function ‘drm_eld_size’ [-Werror=implicit-function-declaration]
09:53hakzsam_: your kernel version is too old :)
09:53gordan: I'm on 3.18!
09:53gordan: That's like one behind the bleeding edge
09:54gordan: And some of my other stuff (e.g. ZFS dkms packages) doesn't build against 3.19 yet.
09:55imirkin_: gordan: i've built it against 3.19, so you need at least that
09:55mupuf: gordan: bleeding edge is drm-next :D
09:55mupuf: so, drm that will happen in 4.1
09:55gordan: I can't do that, my rootfs is on ZFS, and I think that won't build against 3.19
09:57gordan: Is there a slightly less new branch that might still give me the vbios?
09:57imirkin_: not without a ton of surgery
09:57gordan: Nothing's ever easy is it...
09:58imirkin_: you bring it on yourself
10:01gordan: I've no doubt that I am the instrument of my own undoing here, but I cannot quite figure out at which point did I go wrong (unless I went wrong in even remotely pondering doing this in the first place).
10:04gordan: So, USB stick boot, with 3.19... Joy...
10:06gordan: I'm going to laugh hysterically if the thing that falls out turns out to be exactly the same as the BIOS image that I got extracted out of the system firmware blob.
10:11imirkin_: gordan: using an out-of-tree filesystem as your root fs is a proximate cause for your undoing :)
10:12gordan: Blame the licensing faschists.
10:13imirkin_: fact is... you're doing it. i don't care why it's out of tree. but it is.
10:25mlankhorst: or make sure you have networking in your initramfs and scp out the vbios. :p
10:30gordan: That's actually quite a neat idea.
10:30gordan: But I think it'll be easier to just get a bootable USB stick up and running and use that.
11:47imirkin_: skeggsb: looks like there's an offer of ssh access to a GM108 laptop in bug 89558
12:22gaffa: Hi, I have an 8200 card and I can't get HDMI out to work. Where should I focus my debugging? Should I just start from xrandr (fb is not working either) and work my work from there, or do you guys have any suggestions that could help me out?
12:23imirkin_: gaffa: pastebin dmesg, xorg log, and xrandr output
12:23imirkin_: [i could go through and ask you a ton of questions, but they'll all be answered by those logs]
12:26gaffa: imirkin; I'm not at that computer right now. I'll just look for pointers in those logs then, when I do my debugging. Thanks for answering.
12:26imirkin_: offhand, not sure what that 8200 is. hdmi should work fairly well on all G84+ gpu's
12:27imirkin_: there were some issues with some older kernels, fixed around 3.13 or so
12:28imirkin_: well-known issue with the 6150SE igp which used an off-board hdmi encoder that we don't know how to drive, but pretty sure you have something else
12:31gaffa: I think the kernel is 3.16. It's an NVAA MCP77.
12:31imirkin_: yeah, that should work afaik
12:32imirkin_: there were some (unrelated) fixes to nvaa/nvac in kernel 3.19 though
12:33gaffa: Okay, thanks. I'll get to cloning the source and start looking it over until I get access to the machine again.
14:46gordan: Well - I got the vbios out - and without using 3.19. The nouvea module in 3.18 worked just fine when pursuaded with config=VBIOS=1,debug="VBIOS=debug",NvGrUseFW=0
14:47gordan: The bad news is that it is exactly identical to the VBIOS image I extracted from the system UEFI firmware blob
14:47mlankhorst: hah :p
14:48gordan: Which means that my problem is based around somehow providing the said blob using ACPI in OVMF firmware. Thanks for your help guys.
15:33imirkin_: tobijk: give the postfactor patch i sent out a shot, perhaps it magically fixes that pink tint issue with that tera* game
15:34imirkin_: seems unlikely since it didn't affect nvc0, but perhaps with the diff tex args and placement, it would have moved the code around enough for diff opt paths to be taken
15:46imirkin_: skeggsb: GK208 reclocking should work right?
15:47imirkin_: [if i disconnect, you'll know why]
15:49imirkin_: fun, it works. not a huge change in glxgears, but definitely not in the noise. (no displays connected...)
16:56tobijk: imirkin_: allright, will gie it a shot
17:09skeggsb: imirkin_: gears probably wouldn't change much, but try other stuff :P
17:09gordan: In nvafakebios.c: #define NV_PROM_SIZE 0x00010000
17:09gordan: Doesn't that mean that the BIOS payload is limited to 64KB?
17:10gordan: VBIOS-es sice ~ Fermi are bigger.
17:10gordan: Also, why is it that if I nvagetbios right after nvafakebios, the payload I get back from nvagetbios is often just garbage?
17:10gordan: But sometimes it sticks.
17:11gordan: Is the PRAMIN offset/size variable, even though it is definied in both of those source files as a fixed offset (0x00700000)?
17:11skeggsb: imirkin_: i'll try and see what, if anything, i can glean we need to fix from the mmiotrace first
17:12gordan: I've had somebody from nvidia suggest that as long as the VRAM is initialized (either by nouveau.ko or nvidia.ko), putting the BIOS payload into PRAMIN should survive the driver unloading and VFIO passthrough to the VM.
17:13imirkin: skeggsb: well that's the point -- no screen == hard to try "other stuff"
17:13imirkin: skeggsb: also i didn't have anything installed
17:13gordan: And that the Windows driver _should_ be OK with the BIOS in PRAMIN. Except I haven't actually managed to make it work, possibly because the PRAMIN location isn't as fixed as I thought (and as nvafakebios.c might imply).
17:14gordan: Any words of wisdom?
17:15skeggsb: PRAMIN is just a window over arbitrary memory these days
17:15skeggsb: 0x1700 controls where
17:15imirkin: right, you have to stick it in the right place in vram... end of memory right?
17:16imirkin: but nvafakebios knows all that
17:16skeggsb: the vbios usually does
17:16skeggsb: and yes, nvafakebios does it too
17:16imirkin: he's trying to get a card to be useful in a vm when its vbios comes from acpi
17:16gordan: Right. So how come dumping with nvagetbios immediately after nvafakebios often gives me something other than what I just uploaded?
17:17imirkin: should be the same thing, just larger
17:17skeggsb: last time i was playing with kepler pm and poking random bios bits to find what they do, the binary driver definitely still picked PRAMIN as the source if it was there, and valid
17:17imirkin: but the first N bytes should be the same
17:17gordan: Yes, but since there's no ACPI handle for it in the VM, then the driver _should_ (I'm told) fall back on PRAMIN.
17:17gordan: They aren't.
17:18gordan: I had to bump the NV_PROM_SIZE to 0x00020000 so the Maxwell 860M BIOS payload fits.
17:18imirkin: you don't have nouveau loaded while you're doing this right?
17:18imirkin: coz nouveau will put the card to sleep
17:19skeggsb: load nouveau, and pull the rom image from debugfs, it should figure out the exact size
17:19imirkin: at which point vram goes bye-bye
17:19gordan: I have the BIOS image from debugs, it's the identical to the one I pulled out manually from the system's main firmware (hence why it's provided via ACPI, it's not in the PROM).
17:20gordan: Right, so you are saying I need to load nouveau to init the VRAM, unload it immediately (make sure bbswitch is set to ON to stop the card from going to sleep, and only then it will stick?
17:20imirkin: unloading nouveau should cause the card to wake up.... maybe
17:20imirkin: not sure
17:21imirkin: definitely nouveau + bbswitch is a disaster waiting to happen
17:21imirkin: you can load nouveau with runpm=0 which should disable the auto-off stuff
17:21tobijk: imirkin: that magic is not working... :/
17:22imirkin: tobijk: hm?
17:22skeggsb: i have no idea what the kernel will do after unload, it may well put the device into D3
17:22gordan: Right, OK.
17:22tobijk: still pink "overlay"
17:23imirkin: tobijk: oh ok. thanks for testing.
17:23gordan: If I unload nouveau first, it seems to stick in PRAMIN (well, sort of, the dump ends up a little bigger, arbitrarily it seems.
17:23imirkin: nouveau puts vbios into top of pramin too
17:24skeggsb: nouveau doesn't put it anywhere, we just shadow it from wherever into system memory
17:43whompy: imirkin: a few days back, you asked about replaying a trace on an nv50 for bug 78161. Anything specific?
17:43whompy: Finally got a chance to grab it and update my laptop
17:44imirkin: whompy: yes, replay the trace with NOUVEAU_SHADER_WATCHDOG=false
17:45whompy: Did so. Need any output?
17:45whompy: No visible change.
17:45imirkin: does it look weird?
17:45imirkin: (replay it without that env var)
17:45imirkin: are there little squares
17:45whompy: Aye. Not even sure what it's supposed to be
17:46whompy: Just renders as fun fuzzy artifacts.
17:46imirkin: it's supposed to not have little green squares
17:46imirkin: or red or whatever color
17:46imirkin: iirc it was just like little dots if it was rendering correctly
17:46imirkin: play it with LIBGL_ALWAYS_SOFTWARE=1
17:46imirkin: to see what it _should_ do
17:50whompy: Ok. Yeah, screwy. Threw it at my radeon for kicks too
17:52imirkin: yeah, for some reason it peeters out after N iterations
17:52imirkin: if you can, try changing the 0x18 we feed to watchdog and make it 0x1e
18:11whompy: No dice.
18:11imirkin: ok. thanks for checking
18:12whompy: Just double checking my work: is there a good way to confirm I've got LD_LIBRARY_PATH pointing to the right place? I was having issues debugging portal junk the other day with the joys of multilib environments.
18:13whompy: Wanted to verify I had it working properly.
18:13imirkin: use glxinfo
18:13imirkin: it'll probably report some git-foo version
18:14whompy: Did a long backtrace on portal just to realize I had set the path for the 64-bit library. Not a happy realization.
18:14whompy: Shall confirm next time *before* doing that.
18:15imirkin: yeah, oops
18:15imirkin: note that glxinfo is probably a 64-bit binary
18:15imirkin: some distros ship a 'glxinfo32'
19:01whompy: Is it an issue that changing pstate while an application is running causes the system to hang?
19:02imirkin: whompy: i dunno... does it seem like an issue to you?
19:02imirkin: sure seems like an issue to me ;)
19:02whompy: Or is that expected behavior? Just realized I was on a low pstate when testing an old version of Portal, attempted to change the value and bam, hung.
19:02imirkin: what gpu?
19:03whompy: Seems like a bit of a corner until automated pstate changing becomes a thing. GT216
19:03imirkin: that's why we haven't really been thinking about it...
19:03imirkin: RSpliet: --^
19:03imirkin: afaik he thought it was fairly solid
19:03imirkin: what kind of vram do you have?
19:04imirkin: actually upload your vbios + 'dmesg | grep nouveau' somewhere... in case RSpliet has time to look at it
19:04imirkin: i know he's busy a lot lately, but it's also kinda his baby
19:07whompy: GDDR3. It has been pretty solid for the most part. This is really the only glitch in pstates I've encountered. I'll grab that stuff this weekend and open a bug.
19:08whompy: I think I provided an MMIO trace or something a while back for this card, can't remember if I got any of the rest while I was at it. Either way, I'll play with it more in the next few days.
19:08imirkin: whompy: vbios available at /sys/kernel/debug/dri/0/vbios.rom
19:32whompy: imirkin: RSpliet: vbios + 'dmesg | grep nouveau' for my GT216
20:33imirkin: whompy: did you mean to provide a link perhaps?
20:34whompy: Well. That might help a bit... ftp://whompy.linuxd.org/misc/nouveau/
20:34whompy: both files in there.
20:34imirkin: cool thanks :)
20:38imirkin: that says DDR3, not GDDR3
20:39imirkin: oh interesting. first time i've seen stuff in the SPREADSPECTRUM table