03:57 hansg: Hi all, so after needing to work on some nouveau stuff, I'm back to work at the blank window when vsync is enabled on NV46
03:58 hansg: skeggsb said to look into the ddx first, last time downgrading to 1.0.10 worked, but a bisect pointed to the problem being that vsync is disabled by default in ddx 1.0.10, where as it is enabled by default in later versions
04:00 hansg: So I've just started working on this again by trying "vblank_mode=3 glxgears" with 1.0.10, this yields a surprising result, things work this way, glxgears prints the message that it is syncing to vblank, but the fps display shows that it clearly is not ...
04:43 night199uk: hrm, anyone know off hand what the register at mmio (0x680 + i2c index) << 5 … i.e. (0xd000, 0xd020, 0xd040) would be?
04:43 night199uk: i don’t find it in nouveau
04:43 night199uk: this is for kepler
04:53 mupuf: night199uk: what do you mean?
04:53 night199uk: i don’t see 0xd000 -> 0xd1ff listed in any of the mmio register ranges it http://envytools.readthedocs.org/en/latest/hw/mmio.html
04:53 mupuf: this is PGPIO
04:53 night199uk: PGPIO?
04:53 mupuf: in envytools
04:53 night199uk: PGIO would make sense
04:53 mupuf: have a look at rnndb instead
04:53 hansg: mupuf, have you seen my question from a few lines up ?
04:54 mupuf: hansg: yes, just saw it, will answer in a sec
04:54 night199uk: is there an online rnndb?
04:54 mupuf: https://github.com/envytools/envytools/tree/master/rnndb
04:54 night199uk: otherwise i have ti build somewhere i guess
04:54 night199uk: thanks :-)
04:54 night199uk: is rnndb the most up-to-date source of registers?
04:55 night199uk: i thought envytools.readthedocs.com was automatically updated from rnndb actually
04:56 mupuf: night199uk: https://github.com/envytools/envytools/blob/master/rnndb/io/pnvio.xml#L129
04:56 mupuf: rnndb != hwdocs
04:57 mupuf: the point was that rnndb could be generated from hwdocs, but hwdocs never matured to that stage
04:57 mupuf: readthedocs only displays the content of hwdocs
04:58 mupuf: hansg: sync-to-vblank has always been buggy on nouveau
04:58 mupuf: until Mario came and fixed it
04:58 mupuf: IIRC, it only worked for videos
04:58 night199uk: thanks mupuf
04:59 hansg: mupuf, ok, so some of these fixes were probably in the ddx I guess ?
04:59 mupuf: yes
04:59 mupuf: Mario Kleiner
05:00 hansg: Right, so I guess I can bisect the ddx (not that much changes) testing with "vblank_mode=3 glxgears" and find the commit where the behavior changes from working but not actually syncing, to trying to actually sync and not working, that might yield an interesting result
05:01 mupuf:doubts so. It possibly never worked
05:01 mupuf: but I would trust skeggsb's hunch more than mine!
05:02 hansg: Well the behavior has changed from not syncing (running at max fps) to not displaying anything (0 fps)
05:07 hansg: I'm going to give this a try anyways, it is not that much work, and I'm stubborn :)
05:10 night199uk: mupuf: any idea how this would be used in nouveau? i.e. where to look for ref?
05:11 night199uk: since i don’t find 0xd000 in headers i’m guessing nouveau never uses it
05:12 mupuf: night199uk: you cannot grep like that
05:13 night199uk: yeah, i’m finding that. normally its a register like 0x619200 so this is easy to find
05:13 mupuf: the headers are not used anymore
05:13 night199uk: yeah, i noticed that too :-(
05:13 mupuf: be compute the addresses ourselves
05:13 mupuf: we*
05:13 mupuf: based on a ton of stuff
05:13 night199uk: so any idea where the code for pgpio would be?
05:13 mupuf: sure
05:14 mupuf: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/gpu/drm/nouveau/nvkm/subdev/gpio/gk104.c
05:14 night199uk: tx
05:14 night199uk: much appreciated
05:15 mupuf: and https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/gpu/drm/nouveau/nvkm/subdev/gpio/gf110.c
05:15 mupuf: look at the functions drive, sense, reset, intr_stat and intr_mask
05:16 mupuf: that's how we have code reuse between generations
05:17 night199uk: thanks - yeah, i normally find what i need
05:17 night199uk: but this one eluded me for some reason
05:19 mupuf: yeah, it is not typical do have so much object-oriented programming in C
05:19 night199uk: heh
05:19 night199uk: try uefi :-(
05:19 night199uk: same same
05:20 mupuf: I'll try not :)
05:20 night199uk: hehe
05:32 night199uk: mupuf: i’m still missing it :-)
05:32 night199uk: everything i see in the GPIO stuff reads/writes from higher regs
05:32 night199uk: u32 inte1 = nv_rd32(gpio, 0x00dc88);
05:33 night199uk: so the get / set seem to drive 0xd600 / 0xdc00 for everything
05:33 night199uk: i don’t see anything driving 0xd000
05:35 night199uk: any ideas?
05:35 mupuf: ah right, you want the i2c
05:35 mupuf: I don't think we use the hw-based bitbangers
05:35 night199uk: yeah, i’m just looking through the i2c source again now
05:35 mupuf: we use linux's implementation
05:36 mupuf: which is a sw-based bitbanger
05:36 mupuf: why do you care about 0xd000?
05:36 night199uk: erm :-)
05:37 night199uk: i see it used in some nvidia code
05:37 night199uk: which i’m trying to figure out
05:38 night199uk: it’s used as part of the kepler i2c implementation in their i2c init routines
05:39 night199uk: which is very different from the fermi / pre-fermi stuff
09:23 vivia: my problem was in troubleshooting, thanks to whoever put that together! (no EDID => 1024x768)
09:46 rah: nouveau E[ PFIFO][0000:01:00.0] write fault at 0x0000260000 [PTE] from GR/GPC0/PROP_0 on channel 0x007fb20000 [Xorg[7990]]
09:46 rah: nouveau E[ PFIFO][0000:01:00.0] PGR engine fault on channel 2, recovering...
09:46 rah: grrr
09:46 rah: now this is getting annoying
13:02 pmoreau: Oh yeah! It crashed!! Finally!
13:02 pmoreau: :)
13:03 pmoreau:is happy!
13:05 pmoreau: Reverting the changes made by the PCI-reset on PPCI makes it crash again.
13:06 pmoreau: So now let's find which value from PPCI do I need to reset to get the G96 to work... :-)
13:27 pmoreau: And the winner is apparently: 8841c, aka. PPCI.CONFIG
13:47 mlankhorst: :D
13:57 pmoreau: Looks like setting some of the bits between 7..0 to 1 is enough to make it unhappy.
13:58 pmoreau: Too bad the default value, aka. not the one from PCI-reset, is the one that is written by the blob.
14:01 mlankhorst: is PPCI.CONFIG one of the pci config registers or some config on the blob?
14:03 pmoreau: I would say, not on the blob as the laptop will always default to the faulty value on power on.
14:03 pmoreau: And the blob prefers to keep using it for some reason.
14:04 pmoreau: It most likely enables some feature that we don't configure (or not properly at least).
14:05 pmoreau: (Or that is not configured by my vbios, but will be on other computers)
14:55 pmoreau: skeggsb: I'll split the commits tomorrow morning.
16:04 newb123: Hi, I'm trying to get GPU passthrough working on a VM for bhyve (hypervisor). I have an ubuntu VM and I have a few errors that say "can't derive routing for PCI INT B, can't derive routing for PCI INT A". I'm trying to hunt down exactly what I need to fix in bhyve to get it working. Can someone tell me what the err messages mean?
16:15 newb123: I have a GK106 card, I believe someone from the past told me that BAR1 wasn't being enumerated correctly. Is there a way to check that?