01:41 dchotas: hey folks, can anyone help me understand why Im getting glamour initialization failures on login, while using modesetting? Also nouveau doesn't seem to load: Here's my Xorg.log: http://termbin.com/qr0uv
02:15 imirkin: dchotas: appears that you have some other GPU that's coming out as primary
02:16 imirkin: dchotas: or you have something weird in your xorg log
02:16 imirkin: er, xorg conf
09:53 dchotas: Hello folks, I've installed nouveau on ubuntu17.10 laptop from https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers but I'm getting glamor initialization failed on Xorg.log, can anyone help me figure out why?
09:55 dchotas: http://termbin.com/cvii
12:50 ardb: hello all
12:51 ardb: i am having issues running either GT710 or GT210 based gfx card under nouveau on an arm64 system
12:51 ardb: i am getting a couple of 'nouveau 0000:00:00.0: DRM: base-0: timeout' messages
12:52 ardb: but the kernel either locks up, or proceeds without any output on the screen
12:52 ardb: (although the framebuffer works sometimes)
12:53 RSpliet: ardb: hmm... as a quick test could you try booting with nouveau.NvForcePost=1 as a kernel param?
12:54 RSpliet: It's a wild guess, but considering ARM boards don't have BIOSes, this might initialise parts of the card otherwise left uninitialised
12:54 robclark: RSpliet, btw, ardb was guy I was helping last week.. they are running the x86 option rom via "magic" ;-)
12:54 robclark: (also known as libqemu)
12:55 ardb: robclark: trying both with and without, symptoms are the same
12:55 robclark: GOP and efifb are working
12:55 robclark: ardb, btw, might be useful if you could pastebin whole dmesg?
12:56 imirkin_: ardb: what was the original issue?
12:57 ardb: imirkin_: i am sorry, i don't follow
12:57 ardb: imirkin_: original issue?
12:57 imirkin_: ardb: your original issue was something closer to DMA not working? or something?
12:58 ardb: imirkin_: no we have had some problems with PCIe on this board, but everything from legacy endpoints to xhci and network devices is working fine now, including msi/msi-x
12:58 ardb: imirkin_: so the question is really whether we still have issues with pcie :-)
12:59 imirkin_: ok. i recall that your observed issue was that everything looked fine but the fb didn't update
12:59 imirkin_: anyways, the base timeout thing means "display is messed up"
12:59 imirkin_: but you probably already knew that
12:59 ardb: imirkin_: well, in some cases, the nouveau driver appears to run but nothing is shown on the screen
12:59 imirkin_: if you happen to have any NV4x's lying around, those use a totally different logic for displaying things
13:00 ardb: imirkin_: but in other cases it locks up the system
13:00 imirkin_: but G80 and up are all on the "new" thing
13:00 ardb: imirkin_: i have 3 different samples, 2x 710 and 1x 210
13:02 imirkin_: ok, those all use the new disp hw
13:02 imirkin_: unfortunately i know fairly little about it... you send commands to it in a FIFO
13:02 imirkin_: but there's also non-FIFO-command-things that sometimes are done
13:02 imirkin_: you could boot with nouveau.debug=trace to get lots of info
13:02 imirkin_: but tbh i wouldn't necessarily know what to do with that info
13:03 imirkin_: really you want to get skeggsb interested in your issue :)
13:03 mupuf: duttasankha: definitely not pmu
13:04 imirkin_: coz he knows this stuff off the top of his head
13:04 imirkin_: whereas all i know off the top of mine is how to ask him
13:04 mupuf: duttasankha: sorry, the message was old :)
13:06 imirkin_: ardb: is this what you're workign on? http://socionextus.com/pressreleases/linaro-gigabyte-and-socionext-jointly-offer-development-environment-compliant-with-96boards/
13:07 ardb: https://pastebin.com/0L7Y8fRN
13:07 robclark: yes
13:07 ardb: imirkin_: yes
13:07 imirkin_: neat-o
13:07 imirkin_: mupuf: ----^
13:07 imirkin_: the bane of your existence
13:08 imirkin_: [ 13.772728] WARNING: CPU: 0 PID: 0 at /home/ard/linux-2.6/drivers/gpu/drm/nouveau/nvkm/subdev/timer/base.c:102 nvkm_timer_alarm+0xfc/0x108 [nouveau]
13:08 imirkin_: i thought ben fixed that... oh well.
13:08 mupuf: .... AGAIN
13:09 karolherbst1: ...
13:09 imirkin_: ardb: is there an option *not* to do your vbios emulation thing?
13:09 ardb: imirkin_: this is without, and with NvForcePost=1
13:09 imirkin_: ardb: hm ok. and is there something connected?
13:10 ardb: imirkin_: yes, analog. and it does show the framebuffer console
13:10 ardb: imirkin_: (but not every time)
13:11 imirkin_: ok
13:11 imirkin_: so in nv50_disp_atomic_commit_tail
13:11 imirkin_: we commit the state that was requested
13:12 imirkin_: and then after we do that
13:12 imirkin_: /* Wait for HW to signal completion. */
13:12 imirkin_: for_each_plane_in_state(state, plane, plane_state, i) {
13:12 imirkin_: ...
13:12 imirkin_: NV_ERROR(drm, "%s: timeout\n", plane->name);
13:12 imirkin_: which is what you're seeing
13:12 imirkin_: so ... "something ain't workin'"
13:13 ardb: imirkin_: right. thanks for tracking that down
13:13 imirkin_: which in turn reads ... some stuff from a BO
13:14 imirkin_: [i THINK it's nv50_base_ntfy_wait_begun]
13:14 imirkin_: and presumably those commands include a sync which writes to that bo
13:14 ardb: imirkin_: ok so it queues some commands in a fifo and then waits for the hw to signal completion?
13:14 imirkin_: yes.
13:14 imirkin_: and that signalling is not an interrupt but rather a fence write
13:14 ardb: imirkin_: is the fifo in memory or behind a BAR?
13:15 imirkin_: so there could be a missing flush
13:15 imirkin_: wellllll
13:15 imirkin_: maybe, maybe not
13:15 imirkin_: i mean, it's definitely one or the other, but i don't know which without reading more code :)
13:15 imirkin_: a bo can either be in system or in gpu vram
13:15 imirkin_: could be a missing flush
13:15 ardb: imirkin_: right
13:16 imirkin_: looks like it's in VRAM though
13:16 imirkin_: i'm not 100% sure how it's accessed -- via mapping the VRAM, or via the peephole directly. i tend to assume it's by mapping the VRAM.
13:17 imirkin_: althoughhhh
13:17 imirkin_: hah! it maps it.
13:17 imirkin_: [using ttm_kmap_obj_virtual]
13:18 imirkin_: [see nouveau_bo.c:nouveau_bo_rd32]
13:18 imirkin_: pretty sure is_iomem is false.
13:19 imirkin_: wonder what on earth this means: [ 9.050509] nouveau 0000:00:00.0: disp: outp 02:0000:0f02: missing IEDT RSS 1 for 00:00 65000 khz
13:19 imirkin_: i know what "missing" means, but that's about it.
13:20 ardb: imirkin_: so iomem means I/O ports?
13:21 ardb: imirkin_: or mmio? i hope the latter :-)
13:21 imirkin_: mmio.
13:22 imirkin_: io ports are done via mmio as well, thankfully
13:22 ardb: imirkin_: phew
13:22 imirkin_: i think the boards have some crazy emulation of it, but i'd be lying if i said i understood how i/o port writes work on x86
13:23 imirkin_: it must be like a whole separate set of connections
13:23 imirkin_: or no - i guess it's all over the pci bus, but then there's some way to tell which pci slot they go to
13:23 ardb: imirkin_: it dates back to <1980 so it can't be /that/ complicated :-)
13:23 imirkin_: i.e. the vgaarb thing
13:24 imirkin_: well - more like how it's implemented nowadays ;)
13:24 imirkin_: i'm not too worried about VLB
13:24 imirkin_: or, *gasp*, CGA
13:24 ardb: :-)
13:24 imirkin_: i'm crazy, but even my insanity has limits.
13:25 ardb: imirkin_: yeah
13:25 ardb: imirkin_: anyway, thanks for the help
13:25 imirkin_: good luck :)
13:25 ardb: imirkin_: i am going to get the h/w engineers to stick a pcie protocol analyzer in there
13:25 ardb: imirkin_: see if there are any issues on the link that correlate with the timeouts
13:26 imirkin_: all the nv4x modesetting is done by poking mmio directly, so you may have more luck with that :)
13:26 imirkin_: or stick to AMD.
13:26 ardb: imirkin_: good point!
13:28 imirkin_: also i know nothing about ARM cache coherency junk
13:28 imirkin_: so for all i know you need to do some sort of flush before reading device memory
13:28 imirkin_: [i.e. that device memory could be getting cached, MTRR'd, or who-knows-what]
13:28 ardb: imirkin_: no i don't think that's the issue here
13:28 imirkin_: ok
13:29 imirkin_: well it's sitting there waiting for something to change
13:29 imirkin_: iirc gnurou had to change some stuff in nouveau to make that work
13:29 imirkin_: [on arm]
13:29 imirkin_: but he never touched the display code because there's no display on the gpu chip on tegra
13:29 imirkin_: [the display is handled by a separate IP block there]
13:29 ardb: imirkin_: o have been using an arm64 box with a 210 as my primary desktop since march
13:30 imirkin_: oh. so it's just *this* arm64 box?
13:30 ardb: imirkin_: yes
13:30 imirkin_: then yeah. blame the hw.
13:30 imirkin_: ;)
13:30 ardb: imirkin_: indeed
13:30 ardb: thanks again
13:30 imirkin_: good luck!
19:25 duttasankha: mupuf: Thank you for the information. I really appreciate for your help specially because it was old :-)
19:44 mupuf: duttasankha: did you figure out then?
19:46 duttasankha: I am going through gf100.c and base.c under nvkm/engine/pm as per imirkin_ previous suggestion.
19:46 duttasankha: I fugured out the function calls up to some extend.
19:48 duttasankha: About the signal listings and their description in PCOUNTER. I am using Tesla C2075. Does Fermi+ signals listed in the envytools documentation contains the complete signal listings?
19:49 mupuf: we never check on these GPUs
19:49 mupuf: because we never got access to them
19:50 duttasankha: okay. I can do that cause I have it.
19:51 duttasankha: It would be interesting as well being it a a server grade GPU.
19:52 imirkin_: which chip is it?
19:52 duttasankha: But the architecture is Fermi
19:52 duttasankha: so it should be same regarding the performance counters
19:52 duttasankha: I guess
19:54 duttasankha: chip is GF 110GL
19:54 imirkin_: makes sense, i should have guessed that.
19:54 imirkin_: so it should be the SM2.1 signals?
19:55 imirkin_: i guess i dunno all those details
19:57 duttasankha: I didn't get SM2.1... are you talking about about the major and minor version?
20:15 imirkin_: the counters are per SM version
20:15 imirkin_: at least ... i think
20:15 duttasankha: Yeah the SM is SM2.0
20:18 mwk: nah, they're per-GPU
20:18 mwk: they change ridiculously often
20:23 duttasankha: So you are saying that even within Fermi generation GPUs the signals could change?
20:25 RSpliet: yes
20:30 duttasankha: How can I check that what signals are present and what they are responsible for? I mean how the RE usually goes for getting the signal details?
20:36 duttasankha: I guess the PCOUNTER MMIOs should be same within same SM generation or they can change as well?
20:42 mwk: duttasankha: the rough outline of MMIO regs is similiar
20:42 mwk: although signals are not
20:42 mwk: and even the clock domains can be different
20:46 duttasankha: okay...that's a challenge..I am curious how you found out the signal properties in other generations? I could follow similar approach..
20:49 duttasankha: I guess this problem would exsist in Kepler server grade GPUs as well (K40, K80)..I might get access to those and I can carry out similar RE of signals on those as well....so it would be interesting to know the approach..
20:49 imirkin_: i doubt K40 would be different from the other GK104's
20:49 imirkin_: [or whatever chip it is]
20:50 imirkin_: K80 is a GK210, which i dunno if we've seen in practice
20:51 duttasankha: mainly they are all server grade GPUs..