01:43czaks: a quick question: i have an NV110 card (NV117/GF 840M) as an Optimus card on Fedora 23. i'm fed up with the Fedora 23 nvidia driver fiasco. last I tried nouveau (a year ago) it didn't work and i assume it's due to signed firmware issue. any hint in which direction should I head now?
01:43Tom^: signed firmware issue isnt fixed yet.
01:44czaks: Tom^: can I extract the firmware from the proprietary driver? or is it an absolutely no-go right now?
01:45Tom^: you can get modesetting as i understand but no 3D acceleration
01:45czaks: modesetting wouldn't help me at all, as I have an Optimus setup
01:45Tom^: so i guess it depends on what you plan on doing :p
01:46czaks: apparently in the Feature Matrix NV110 series cards work pretty well, just no 2d support, and AFAIK all NV110s require firmware
01:46czaks: the signed firmware I mean
01:51prg: the codenames page lists the 840 as first gen maxwell, which should kinda work already afaik
01:51prg: the signed fw thing was only for second gen maxwell
01:56czaks: hm, my card is being reported as GM108M, which is NV118, not NV117 (which actually also includes a card named 840M)
01:59prg: you could just give it a try and see how it works, though afaik maxwell isn't supported that well yet since the devs don't care much till the fw situation is sorted out
02:00prg: (even if it only affects second gen gpus)
02:01prg: just make sure you have the newest everything
02:02czaks: prg: is Fedora 23 newest enough?
02:02prg: nfi what that comes with
02:02prg: kernel, mesa, nouveau and intel ddx seem important
02:03czaks: prg: mesa-libGL-11.1.0-2.20151218.fc23.x86_64, kernel-4.3.5-300.fc23.x86_64, xorg-x11-drv-intel-2.99.917-16.20150729.fc23.x86_64, xorg-x11-drv-nouveau-1.0.12-1.fc23.x86_64
02:04prg: i don't know what's required exactly, just that newer tends to work better than older
02:04Tom^: czaks: mesa and kernel is old. :p
03:53czaks: ok, so if anyone is interested in my results:
03:54czaks: nouveau doesn't work with NV118, only with NV117
03:55czaks: even with a 4.5.0-0.rc3.git3.2.fc24.x86_64 kernel
03:56czaks: it's just unsupported (yet?)
03:56czaks: fortunately, i fixed my issue with nvidia optimus: i missed a primus.i686 package, now everything works
09:12karolherbst: any idea what could be 16MB big and what could be 0.5MB big kind of memory of a nvidia kepler gpu?
09:13mwk: karolherbst: that's kind of strange question, where did you find those?
09:13mwk: 16MB could be L2 cache size
09:13mwk: oh, iomem
09:13mwk: is that something nv driver ioremaps?
09:13karolherbst: it is without driver loaded
09:13karolherbst: that's why I am interested in it
09:13karolherbst: I found another 256MB region
09:14mwk: as in, another BAR?
09:14karolherbst: mhh, summary: I found 256MB, 32MB, 16MB and 0.5MB mappings
09:14karolherbst: once each
09:16karolherbst: ohh found something interessting in my dmesg: "Using GB pages for direct mapping"
09:16karolherbst: would be nice to know if anybody with mmiotrace issues also gets this
09:16karolherbst: it is near the PAT stuff at the top
09:16karolherbst: pmoreau: would you like to check that?
09:18karolherbst: mwk: I was thinking maybe that the PRAMIN stuff gets listed in iomem, would be an easy way to find where we should write stuff in
09:20karolherbst: nvidia claims the 16MB region itself when it is loaded
09:20mwk: karolherbst: which size is which BAR?
09:20karolherbst: how can I check?
09:20mwk: 16MB is mmio, 32MB is ramin BAR, 256MB is main vram BAR
09:21imirkin: karolherbst: "mapping" is not a thing. please be precise re wtf you're talking about.
09:21mwk: 0.5MB could be the vbios
09:21mwk: some people count it as BAR6
09:21imirkin: (or rather, "mapping" is too many things)
09:22karolherbst: mwk: Memory behind bridge: f6000000-f70fffff, this includes the 16MB and 0.5MB one
09:23karolherbst: I/O behind bridge: 0000e000-0000efff is the 256MB one maybe?
09:23karolherbst: Prefetchable memory behind bridge: 00000000e0000000-00000000f1ffffff is the 256MB + 32MB one then
09:33karolherbst: mwk: okay, so if we know where pramin is located in the address space, we can just write to it where the faked vbios belongs, tell the card where to look and be done with it?
09:34imirkin: karolherbst: that's what nvafakebios does
09:34karolherbst: imirkin: well, not for me
09:34karolherbst: I think it reads the address out of a mmio reg, which is just 0x1 for me
09:34karolherbst: and then writes into some memory
09:35karolherbst: so maybe asking the system for the address ranges is more reliable in that case
09:35imirkin: that's what nvafakebios is *supposed* to do... better? :)
09:35karolherbst: nvafakebios checks 0x619f04 (which is 0x1) and 0x1700 (which is 0x0)
09:36karolherbst: also it writes into 0x00700000 + offset through nv_wr8
09:37karolherbst: maybe "nva_cards[card]->bar0" returns the wrong address for some reasons
09:39phillipsjk: I am getting fair severe graphical corruption for the Gallium 0.4 renderer on NV4A (Geforce6200) with Mesa git-111602e 2016-02-10 trusty-oibaf-ppa in the form of black and white "snow" (Mesa 11.2.0-devel)
09:40phillipsjk: using X and firefox. Dmesg noise: http://paste.debian.net/384158/
09:42phillipsjk: Not sure it is strictly related to nouveau since I broke my window manager installing bleeding-edge drivers for testing gallium 9 with "path of Exile" (Radeon, Intel, nouveau all have cinnamon crash on start-up)
09:43RSpliet: phillipsjk: could you start by getting a newer kernel running? some fixes were made to the kernel side of things. Might be 100% unrelated, but 'd be good to rule those out
09:44RSpliet: 4.4'd be good
09:44imirkin: phillipsjk: gallium-nine won't work with the nv3x driver iirc
09:44imirkin: phillipsjk: if the snow is analog-looking, that usually means the display controller can't keep up, try increasing clocks (boot with nouveau.pstate=1)
09:44phillipsjk: Not sure how bleeding edge my available kernels are from repos (using linux mint, and made it non-lts to get the video drivers installed)
09:45RSpliet: phillipsjk: also: listen to imirkin. I make general remarks, he makes more specific ones :-P
09:46phillipsjk: Even at full tilt, the NV card should draw less power than the radeon I was testing :)
09:47phillipsjk: I guess adding the pstate line to the boot arguments should be an "easy" fix.
09:47imirkin: the kernel you're on is fine
09:48imirkin: phillipsjk: how's this thing hooked up? PCI?
09:49phillipsjk:took a minute to figure out how imirkin knew what kernel they were using
09:51imirkin: phillipsjk: anyways, looks like there was a bit of a fifo desync. that could mean some kind of hw-related screwup, or a driver-related screwup. not sure which it would be with that gpu.
09:53phillipsjk: I got it instead of a special over-priced half-height AGP4x card. Now I can use it in machines equipped with PCI-E :)
09:54phillipsjk: (as long as legalcy PCI slots are included anyway)
09:55imirkin: phillipsjk: once you boot with that, echo 20 > /sys/class/drm/card0/device/pstate
09:55imirkin: and see if the snow goes away
09:55imirkin: but to be clear, i consider the nv3x mesa driver to be quite poor.
09:56imirkin: if it's an option, i'd highly recommend a G80 or later gpu, if you're looking to mess around with mesa + nouveau.
09:58phillipsjk:wonders why they had to make grub so complicated.
09:59phillipsjk: I was trying to use nouveau as a "known good" comparison :)
09:59phillipsjk: Actually I do have a newer card sitting around. Not sure what it is.
10:00phillipsjk:does not have immediate access to it.
10:00imirkin: the nv50 driver is, generally, in *much* better shape than the nv30 driver
10:02imirkin: anyways, the main reason i haven't worked on it is i don't have a nv3x/nv4x pci card. and only 2 pcie slots, which are occupied by more important gpu's. so i can't test it on the side. i've been looking for a geforce fx pci board, but they're all too expensive. ($15 or so.) when one appears for half that, i'll probably grab it.
10:03imirkin: [this would also potentially allow me to test nouveau_vieux on the same card...]
10:15phillipsjk: I think I paid like $40 for mine (brand new), which is like $30 in USD
10:16phillipsjk:still has not figired out where he is supposed to edit the command-line. With lilo it was: edit the one file, run lilo.
10:19RSpliet: phillipsjk: you can still edit /boot/grub/grub.cfg or similar, but good practice is to edit /etc/default/grub , then run grub2-mkconfig -o <path-to-grub-config-file>
10:19RSpliet: on Fedora this config file is in /boot/grub2/grub.cfg, not sure what the debian convention is
10:20phillipsjk: Thanks RSpliet. Found a tutorial pointing me to that
10:21phillipsjk: apparently every in /boot is automatically generated these days in debian-based.
10:27phillipsjk: I think setting pstate=1 made things worse.
10:27imirkin: grub1 or grub2?
10:27phillipsjk: computer actuall froze up before I could log in
10:27imirkin: well, pstate=1 does nothing -- it just allows you to do stuff
10:28phillipsjk: You mean grub-update was bad?
10:31phillipsjk: maybe it just needed a cold-boot.
10:39joi: skeggsb: I sent GM108 mmiotrace to mmio.dumps@gmail
10:39phillipsjk: firefox is now saying something about vector smash protection being enabled. (and is kind of unresponsive) dmesg implicates something called "plugin-containe" (I knew flash was evil)
10:39imirkin: joi: afaik we already had one
10:39joi: imirkin: since when?
10:39imirkin: joi: like a year :)
10:40imirkin: joi: https://bugs.freedesktop.org/show_bug.cgi?id=89558
10:40joi: so why it's not supported by nouveau?
10:40imirkin: because someone's being lazy
10:40joi: I don't mean 3D
10:40imirkin: i know
10:40imirkin: someone has to go over the trace and make sure that the golden values are the same as for GM107
10:41imirkin: unfortunately someone split up all the golden values so that they're in 100 different places now, so it's very difficult to follow for anyone other than the person who split them up
10:41imirkin: [not that it was very easy before...]
10:42imirkin: [and yeah, it sucks to have 100 identical copies of the same thing, so i totally see why it was done. still hard to follow.]
10:43imirkin: joi: if you're trying to get yours to work, just stick a "case 0x118:" above the case 0x117 :)
10:43joi: if you need mmts for gm108, just ping me
10:44imirkin: i think it should be the same as gm107 - mesa is mostly up to par, but not completely.
10:44imirkin: need to finish tess. and need to debug that glamor bug (unrelated to maxwell).
10:47phillipsjk:kills most recently open tab since load-average went over 3 with the machine doing nothing. (plugin-container again)
10:49phillipsjk: more Dmesg noise: http://paste.debian.net/384204/
10:49joi: imirkin: I don't want to deal with lockups 10 times a day, so I'll wait for proper kernel support
10:54imirkin: joi: i don't see how proper kernel support will prevent that
10:54imirkin: joi: besides, with no reclocking, you're better off with the intel gpu in that laptop
11:14karolherbst: mwk: one question, is card->bar0 suppose to be random?
11:14karolherbst: in nva that is
11:16karolherbst: mhh seems like some virtual addressing thing, because all bar0-bar2 values make sense when compared to each other
11:16mwk: nva* is a user space program
11:16mwk: and bar0 is a pointer to an mmapped area
11:16mwk: which is a usual virtual pointer in a linux process
11:16mwk: it's going to be entirely unrelated to any physical address
11:17mwk: and yeah, it's likely going to be random, due to ASLR
11:17karolherbst: I am still wondering why my kernel crashes with nvafakevbios, it doesn't make sense
11:17karolherbst: well "crashes"
11:17karolherbst: it just stops doing anything
11:19karolherbst: nva_wr8 writes to *(((volatile uint8_t *)base) + addr) where base is nva_cards[card]->bar0 and addr is [0x00700000,0x00700000+vbios_size]
11:20mwk: was the card POSTed?
11:20karolherbst: mwk: well anyhow, I did nvafakebios + nvagetbios on mupufs maxwell card and the returning vbios through pramin is corrupted
11:20karolherbst: mwk: mhhh maybe mine wasn't but mupufs was for sure
11:21mwk: could you tell me what is in reg 619f04 on that card?
11:21mwk: that's bad
11:21karolherbst: also on mupufs maxwell card
11:21mwk: and 1700?
11:21karolherbst: ohh wait
11:21mwk: ok, that's very bad
11:21karolherbst: 1700 is 0x1ef
11:21karolherbst: but that may be because I messed with nvafakebios a bit
11:22karolherbst: usually it is 0x0
11:22mwk: so the proper pointer is not set...
11:22karolherbst: mwk: yep, it is 0x0 when after powering down and up
11:23mwk: I'm afraid nv just doesn't care for storing bios in vram on maxwells
11:23mwk: it's a gm107?
11:23karolherbst: mwk: no, gk106
11:23karolherbst: mwk: with nvidia loaded: 619f04=0x0 and 1700=0xbff0
11:23karolherbst: wait, the first one is 0x1, sorry
11:26karolherbst: mwk: anyway, in multiple ways my kepler is a very maxwell like anyway, pwm voltage control and some vbios stuff
11:34mwk: it appears GK106 doesn't actually have vbios in VRAM
11:34karolherbst: all of them?
11:34mwk: my specimen
11:34mwk: nor my GK104 for that matter
11:34karolherbst: mhh okay
11:35karolherbst: I need to use prom to get the vbios
11:35mwk: it does happen to have 0x0000beef written in the first word of where vbios should be
11:35mwk: so perhaps it still supports loading a vbios from there, and 0xbeef is supposed to poison the place so it doesn't accidentally load junk
11:36karolherbst: could be
11:36karolherbst: does nvidia also sets 1700 to 0xbff0 for you?
11:36mwk: yeah, 0x3ff0
11:37mwk: 619f04 is correctly set to 0x3ffe09 though
11:37mwk: not like your invalid value
11:37karolherbst: for me it is bff0 though not 3ff0
11:37mwk: yeah, it's size of VRAM - 1MB
11:37karolherbst: ahh okay
11:37karolherbst: anyhow, I think on my fermi it is the same
11:37karolherbst: let me check
11:38mwk: right, what happens on G80 cards and up is: 1700 gets VRAM_size - 1MB, 619f04 gets VRAM_size - 128kiB, and 9 in the low bits
11:38karolherbst: 619f04 0x1 and 1700 0x0, before posting though
11:38mwk: then vbios is uploaded at VRAM_size - 128kiB, which happens to be readable at 7e0000 due to the window setup
11:39mwk: yeah, these are correct pre-post values
11:39mwk: how do you post it, then?
11:39karolherbst: loading a driver I guess. they are mobile gpus and usually off
11:39mwk: which driver?
11:40karolherbst: well usually I don't need to post the gpu, so I was never aware of doing it
11:40mwk: nouveau may get the init wrong, let me see...
11:41mwk: yeah, it does
11:41mwk: it doesn't bother to poke 619f04 or leave 1700 correct
11:56karolherbst: mwk: with my nvc1 card, 619f04 also gets 0x1 even when nvidia is loaded
11:56karolherbst: and X running, so that I am sure the card was posted
11:57karolherbst: maybe this is an issue for cards not being the main card of that system?
11:57mwk: maybe that's only set when it's posted by actual vbios...
12:00bgeer: Just upgraded to kernel 4.4.1 w/ nouveau, hardware is onboard nvidia 6150
12:00bgeer: getting lots of flashing in both console & X
12:00karolherbst: mwk: want me to check what these reg contains after a reboot and without turning of the gpu?
12:00bgeer: Any help?
12:00karolherbst: bgeer: did an older kernel work without problems?
12:00bgeer: 4.4.0 no problema
12:01karolherbst: ohh then this is gonna be easy
12:01karolherbst: bgeer: do you compile your kernel yourself?
12:01bgeer: No - upgraded using Slackware64-current mirror
12:02karolherbst: mhh weird
12:02karolherbst: there is no change for nouveau for 4.4.1
12:02karolherbst: are you sure it worked with 4.4?
12:05bgeer: Yes - ran 4.4 since Jan 13 & no flashy
12:16bgeer: I may have fixed it - sudo cpufreq-set -g performance
12:17bgeer: I noticed in changelog the following notes for kernel: CPU_FREQ_DEFAULT_GOV_ONDEMAND n -> y CPU_FREQ_DEFAULT_GOV_USERSPACE y -> n CPU_FREQ_GOV_CONSERVATIVE m -> y CPU_FREQ_GOV_ONDEMAND m -> y CPU_FREQ_GOV_PERFORMANCE m -> y CPU_FREQ_GOV_POWERSAVE m -> y
12:19karolherbst: this shouldn't effect this
12:19karolherbst: bgeer: could you downgrade to 4.4.0 and check if this still happens?
12:19karolherbst: maybe something else changed
12:20Dezponia: I dont get how Michael is running his tests on Heaven in this benchmark: http://www.phoronix.com/scan.php?page=article&item=nouveau-rad-45&num=3
12:20bgeer: Please see my response just before TheCephalopod joined:
12:21bgeer: Or, to repeat: I may have fixed it - sudo cpufreq-set -g performance
12:21bgeer: I noticed in changelog the following notes for kernel: CPU_FREQ_DEFAULT_GOV_ONDEMAND n -> y CPU_FREQ_DEFAULT_GOV_USERSPACE y -> n CPU_FREQ_GOV_CONSERVATIVE m -> y CPU_FREQ_GOV_ONDEMAND m -> y CPU_FREQ_GOV_PERFORMANCE m -> y CPU_FREQ_GOV_POWERSAVE m -> y
12:23Dezponia: About that phoronix benchmark: "With all of the NVIDIA GeForce 600/700 Kepler graphics cards, they were re-clocked to their highest power-state manually prior to testing." That just cant be right?
12:24Dezponia: Guess his 780Ti still doesnt play nice with reclocking
12:25imirkin: Dezponia: in general, anything on that site is likely to be inaccurate.
12:26Dezponia: imirkin: Well yeah, but I seem to real karolherbst reaching out to him to figure out why his 780Ti was not reclocking properly but I guess he never came back with a response
12:26karolherbst: I am so gonna never install ubuntu on any machine again....
12:27karolherbst: Dezponia: he just didn't manage to install my patches
12:27Dezponia: karolherbst: Good choice
12:27karolherbst: yeah... stupid ubuntu
12:27karolherbst: I remove the xorg.conf file
12:27karolherbst: restart lightdm
12:27karolherbst: guess what, xorg.conf there again
12:31karolherbst: something thinks it is funny to set the gl stuff back to nvidia...
12:31Dezponia: karolherbst: Dont you love when stuff messes with your config files for you?
12:32karolherbst: this is a violation of the most important rule in programming at all time: don't be smart
12:32karolherbst: being smart means screwing up
12:33Tom^: Dezponia: it isnt reclocking to max cstate, he just assumes it does.
12:35Dezponia: Tom^: I like how he continues to be perplexed in every benchmark about why it doesnt perform well with the reclock :P
12:35Tom^: or he simply means he is clocking them to the max working pstate
12:35Dezponia: Tom^: Without ever seemingly checking what its actually clocking to
12:36Tom^: without my superduper fixallthethings volt hack he wont get max cstates on his 780ti :P
12:36Dezponia: Tom^: A secret technique passed down from generation to generation? :)
12:36Tom^: simply set it it to .max
12:37Dezponia: Tom^: Are you a wizard!?
12:37Tom^: it was karolherbst magic that did it tho im just stealing his glory :(
12:37karolherbst: .... that attitude: ""Before asking for help here, please file a bug report using 'ubuntu-bug xorg'." yeah, I would if X would start....
12:37karolherbst: ohh wait, maybe it works without X :D
12:39Dezponia: Well imma go get pizza. Weekend demands it
12:42Tom^: karolherbst: why are you installing ubuntu :o
12:42karolherbst: it is already
12:42karolherbst: I just wanted to have bumblebee working again there
13:08karolherbst: there is a stupid binary called gpu-manager
13:08karolherbst: this stupid thing overwrites all my stuff
13:09karolherbst: and segfaults when I launch it with -h
13:09karolherbst: such quality
13:12linkmauve1: karolherbst, I encountered it the other day when helping somebody use Nouveau on a recent Ubuntu.
13:12karolherbst: yeah, this binary sucks
13:12karolherbst: it thinks I want a prime offloading setup
13:12karolherbst: the nvidia thing
13:13karolherbst: where intel is modesetting and nvidia rendering
13:13linkmauve1: DRI_PRIME=1 you mean?
13:13karolherbst: the nvidia prime thing
13:13linkmauve1: I haven’t used their driver in like ten years.
13:14karolherbst: I have this alternative entry though: x86_64-linux-gnu_gl_conf -> /usr/lib/nvidia-352/ld.so.conf
13:14karolherbst: and I have no alternative for this?
13:15karolherbst: ahh now it points to mesa
13:15karolherbst: yeah whatever, gpu-manager changed it back
13:16karolherbst: how I have such smart tools :/
13:17karolherbst: well it is a boot service so maybe disabling helps
13:19karolherbst: masking the gpu-manager service helps
13:23karolherbst: and on reboot it gets unmasked.... what the hell
13:29karolherbst: this all mess just because /var/lib/lightdm wasn't owned by lightdm?
13:31imirkin: and this is why i prefer easy-to-use distros like gentoo
13:34karolherbst: well this machines has to update itself without involving any actions by me
13:34karolherbst: so gentoo is hardly the best choice for that
13:37imirkin: "do things by itself" == "not easy to use"
13:37imirkin: can't have it all
13:42karolherbst: mwk: okay, ever when the card wasn't turned off after a reboot, 0x619f04 is still 0x1
16:43imirkin: hakzsam: in the past i've noticed that stuff like C34_RZ_O14_20 is actually bogus
16:43imirkin: hakzsam: or rather, not bogus, but controlled by some flag
16:44imirkin: oh hm, maybe not
16:44hakzsam: I don't think it's related to C34_RZ_O14_20
16:44hakzsam: imirkin, you can try with fe2047f1 021fc000
16:45hakzsam: lop3 has 3 inputs, and envydis only define two
16:45imirkin: hakzsam: can you give me the whole snippet?
16:45imirkin: so i can just paste it instead of finding the stupid sched codes
16:46hakzsam: imirkin, http://hastebin.com/igogewabic.pl
16:46imirkin: not what i had in mind, but good enough
16:47imirkin: 00000140: fe2047f1 021fc000 $p0 lop3 lut cc $r241 c0[0x3f88] $r128 0x1f [unknown: 00004700 00000000]
16:47imirkin: that's not a real op
16:47imirkin: that's just a misinterpreted sched code
16:48hakzsam: imirkin, well, nvidiasm returns: /*0008*/ @P0 LOP3.LUT R241.CC, R71, c[0x0][0x3f88], R128, 0x1f; /* 0x021fc000fe2047f1 */
16:49hakzsam: my patch adds this R71 reg
16:49imirkin: can you give me the whole snippet to paste into nvdisasm? i can't get it to work
16:49imirkin: anyways... wtvr. your patch is fine
16:50hakzsam: imirkin, I used this snippet http://hastebin.com/ipeluxokiv.hs
16:52hakzsam: imirkin, I'll wait for mwk feedback before pushing it, but I'm off now, see you :)
16:54imirkin: but ftr, that's not a real opcode (in the stream you pasted), but rather a sched op
17:52mwk: hakzsam: tbh I don't have any clue about Maxwell, but yeah, sounds like it should have 3 inputs
19:30imirkin: hakzsam: looks like you forgot to add PIPE_SHADER_CAP_SUPPORTED_IRS to nv50
19:52Riastradh: For a GeForce 210 (GT218) device, in the stack trace nouveau_drm_load -> nouveau_display_create -> nouveau_object_new -> nouveau_object_ctor -> nv50_disp_base_ctor -> nouveau_ramht_new -> nouveau_gpuobj_create_ -> nv_wo32, inside nouveau_gpuobj_create_, what is the wr32 method of gpuobj likely to be?
19:53imirkin: Riastradh: depends on the object being written
19:53imirkin: if it's the gpuobj itself, look at nouveau_gpuobj_wr32
19:54imirkin: Riastradh: those functions have been reorg'd a bit to be a bit more direct, i think, this stuff changed a lot in 4.3 or so
19:54Riastradh: OK. I'm effectively looking at 3.15 at the moment.
19:54Riastradh: What would pfuncs->wr32 likely be, then?
19:55imirkin: wait, you said wo32
19:55imirkin: wo32 = write object
19:55imirkin: wr32 = always mmio write
19:55Riastradh: Right. I'm looking at the call to nv_wo32 at the end of nouveau_gpuobj_create_.
19:55imirkin: what file?
19:55imirkin: (full path please)
19:56imirkin: nv_wo32(gpuobj, i, 0x00000000);
19:57imirkin: that is effectively calling _nouveau_gpuobj_wr32
19:57Riastradh: OK. That reduces to nv_ofuncs(gpuobj->parent)->wr32 -- what's that likely to be?
19:57imirkin: i *assume* that's just the regular nv_wr32
19:57imirkin: hol don
19:58Riastradh: Your `heh' answer anticipates the reason I gave up trying to find it myself and asked here!
19:59imirkin: i *think* it might be instmem
19:59Riastradh: I have three candidates: _nouveau_fifo_channel_wr32, nouveau_barobj_32, and nv40_instmem_wr32.
19:59imirkin: i.e. nv50_instobj_wr32
19:59Riastradh: But I'm having a hard time persuading myself that nv40_instmem_wr32 is sensible here, given that it is a GT218 device.
20:00Riastradh: Oh, wait.
20:00Riastradh: No, I see, it must be vanilla nv_wr32.
20:01Riastradh: ...from a clue I had just completely overlooked.
20:02Riastradh: Context, if you're curious: I ported nouveau to NetBSD a while back, and it works on a number of devices, but on the GT218 it fails immediately at boot in this register write, and I'm trying to debug it -- <http://gnats.netbsd.org/50372>.
20:02imirkin: it's probably nv50_instobj_wr32.
20:02imirkin: from v3.15:drivers/gpu/drm/nouveau/core/subdev/instmem/nv50.c
20:03Riastradh: I'm not sure the true trace goes via that (semiplausible -- but there's a spinlock release in the path, which I would expect to see in debugger's stack trace), but it definitely is inside nv_wr32.
20:03imirkin: Riastradh: oh cool!
20:03imirkin: is there a particular reason you picked 3.15?
20:04Riastradh: At the time I did the bulk of the work (summer 2014), that was close to the current Linux release.
20:04Riastradh: It's getting time to do an update!
20:04imirkin: hm ok, it gets unhappy when trying to create a ramht... odd
20:04imirkin: what's bus_space_write_4? i'm guessing it's a iowr32?
20:05Riastradh: Basically, yeah.
20:05Riastradh: The clue is that the extended back trace from gdb, which the submitter eventually procured, says bus_space_write_stream_4 -- which means `don't swap byte order, I know what I'm doing' -- and the only case of that is in nv_wr32, not in the other candidates I just named.
20:05imirkin: so... that's consistent with creating a gpuobj
20:06Riastradh: Here's the extended stack trace: http://flex.phys.tohoku.ac.jp/~okuyama/nouveau20151028.bt
20:06imirkin: basically it creates a "gpuobj" aka "an object in vram"
20:06imirkin: and the way it writes to vram is by configuring imem window and then writing. this is all done over mmio.
20:06Riastradh: (OK, there's one other bus_space_write_stream_4, in nouveau_vga_font_io, but I can't imagine it's that.)
20:06Riastradh: Yeah. I probably just botched something about mapping the device mmio registers, but not badly enough to hose everything else.
20:07imirkin: #8 0xffffffff80114548 in bus_space_write_stream_4 ()
20:07imirkin: #9 0xffffffff80a4799a in nv_wo32 (data=0, addr=0, obj=0xfffffe811d65b250)
20:07imirkin: at /var/build/src/sys/external/bsd/drm2/dist/drm/nouveau/core/include/core/object.h:182
20:08imirkin: i don't see a call to iowr32() in nv_wo32
20:08imirkin: do you?
20:08imirkin: can you provide a pointer to that code?
20:09Riastradh: I didn't touch any of the function pointer indirections -- only the final calls to iowrite32(_native).
20:09imirkin: ok, well... can you explain the stack trace then?
20:09Riastradh: Here's the nouveau code in NetBSD: http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/external/bsd/drm2/dist/drm/nouveau/?only_with_tag=MAIN
20:09imirkin: it can't have inlined stuff...
20:10imirkin: (or if it did, you have a serious compiler problem)
20:10Riastradh: It wasn't inlined -- it was tail-call-optimized.
20:10Riastradh: So there are no stack frames for the debugger to find.
20:10imirkin: can you do a build that's super-debug-friendly?
20:10imirkin: -O0, -fno-omit-frame-pointer
20:10imirkin: or at least -Og
20:11Riastradh: Probably yes. But I don't actually have a GT218 device myself. I can only ask someone who lives in another continent and 11hr time zone difference to do a test for me.
20:11imirkin: ah, i see
20:11imirkin: well.... i'll tell you what i've told others...
20:11imirkin: there have been a lot of bug fixes in the past 1.5-2 years
20:11imirkin: perhaps try a fresher codebase :)
20:12Riastradh: Yes -- been planning on doing an update for a little while now. Just haven't had the time to do it -- only time to do some littler things.
20:12imirkin: i'm looking through changes now to see if there was anything relevant
20:12imirkin: but it doesn't ring a bell
20:13imirkin: do you know if that GT218 works with nouveau on linux (esp the linux 3.15 nouveau)
20:15imirkin: that's an important data point
20:16imirkin: i.e. did you screw up the port, or is it a straight-up nouveau bug (plenty of those)
20:24Riastradh: The mmio registers are all mapped in nouveau_devobj_ctor, right?
20:25imirkin: the mmio space is mapped somewhere *very* early
20:25imirkin: iirc it's BAR1
20:25imirkin: or BAR32
20:26Riastradh: So the only place I see subdev->mmio being initialized is in nouveau_subdev_create_, where it is initialized to be nv_subdev(device)->mmio; the only place I see that initialized is in nouveau_devobj_ctor, mapped from BAR 0. (I'm also doing a very dumb naive search here; I could refine it if necessary.)
20:29imirkin: did i totally misremember? entirely possible
20:29imirkin: yes, bar0 = mmio
20:30imirkin: so for writing that gpuobj, it will write some stuff to mmio on bar0, which will configure the vram aperture on bar1, and the remaining writes will go there, i think
20:31imirkin: (or bar3... same diff)
20:33Riastradh: Does it make sense to zero all the mmio registers in some range?
20:33Riastradh: It seems to me that this zeroing is likely intended for a vram mapping, not an mmio register mapping.
20:33Riastradh: (That would suggest a bug in nouveau, not in my port.)
20:34imirkin: that's right - it's zeroing part of vram
20:34imirkin: but.... how do you access vram :)
20:34imirkin: basically you write to a couple of mmio regs in bar0 to configure the window in bar1/bar3
20:35imirkin: and then you read/write it via bar1/bar3
20:35Riastradh: Right, but the write that is faulting is to bar0.
20:35Riastradh: So maybe you can zero the newly allocated vram via some window in mmio registers...but that seems odd to me.
20:36imirkin: i think there's such a thing actually
20:36imirkin: hold on
20:37Riastradh: Is there a glossary for all this jargon? I have no idea what a ramht is, for example.
20:38imirkin: ht = hash table
20:38Riastradh: I found <https://nouveau.freedesktop.org/wiki/NouveauTerms/>, but it seems to be missing a lot.
20:38imirkin: yeah.... not a lot of docs
20:38imirkin: you can look through the hwdocs in envytools
20:38Riastradh: OK, I guess not a glossary -- I guessed that `ram' means RAM and `ht' means hash table, but I have no clue what the ramht is for or how it fits into anything else.
20:38imirkin: (that's at envytools.rtfd.org)
20:38imirkin: tbh, i'm a bit weak on it too. i think it has to do with which objects are bound to which channel
20:39imirkin: you really want to ask skeggsb, who knows all this stuff like the back of his hand
20:39imirkin: send an email to the list, i don't think he reads scrollback
20:40Riastradh: (When I first did the port, it was an afternoon throwaway project, augmented by about a dozen rounds of whack-a-mole with compiler errors/warnings for the next year when I was bored. That's why you haven't heard anything from me before -- I was focussing on Intel and Radeon graphics instead.)
20:41imirkin: fair enough
20:41imirkin: there shouldn't be *too* much to port in nouveau, once you have things like drm and ttm already done
20:42imirkin: and it'll be problems you've already solved before, like locking, interrupt handling, etc
20:45Riastradh: Yeah, we have shims in place to map trivial things like the Linux mutex and spinlock APIs to the native NetBSD API, so that was no trouble. Mapping device memory mapping and handling interrupts is a little bit different, but not hard.
22:20imirkin: can m2mf/copy engine do scaling?
22:57phillipsjk:had is commented-out xorg.conf renamed on Linux Mint. I was like: WTF?
23:01phillipsjk: I think it may have been because i upgraded xorg.