00:21 mlankhorst: skeggsb_: https://launchpadlibrarian.net/195346510/CurrentDmesg.txt happen to know if that MMIO write fault at b010 has been fixed yet? if so remember what commit? :-)
03:22 rkantos: How are we doing :D
03:22 rkantos: So Fedora + latest kernel + Intel 4000 + 8400gs
03:23 rkantos: Newest kernel = still doesn't boot with video, but after hdd pw has been typed, then I can get video
03:23 rkantos: all same problems persist after though. Still setting up 4 monitors is a bit of a pain. Names of the inputs changing from VGA-1 to VGA-0 etc don't really make using my script exactly bliss..
03:24 rkantos: And now even the script doesn't work. Xorg just crashes I guess
03:24 rkantos: but activating the monitors one by one with arandr and after they're all on setting the order works
03:25 rkantos: haven't updated BIOS yet, but will probably do that today
04:20 mupuf: As usual, quality reporting by Phoronix...
04:21 mupuf: In any case, I guess it is also a good time to announce here that I started working with Intel
04:21 mupuf: What it will change for my involvement in Nouveau is stated here: http://www.mupuf.org/blog/2015/01/09/first-week-as-intel-employee/
04:21 hakzsam: :)
04:21 mupuf: (not referenced by Phoronix, hence the quality reporting ;))
04:22 mupuf: Short version: Not much should change with regards to my involvement in Nouveau
04:22 mupuf: I am not really available at the moment ... because I do not have access to the internet at home except through my phone
04:23 mupuf: and I'm battling with the Finnish bureaucracy a little to get everything in order
04:23 mupuf: My desktop computers + GPUs should arrive on Friday too :)
04:23 mupuf: hopefully all in good shape!
04:24 mupuf: I don't even have a desk yet though
04:24 hakzsam: reator, yeah :)
04:24 mupuf: well, we'll see. I may need to use a 4G internet connection for some time so the ping will be awful + no public IP address
04:25 mupuf: so that means reverse tunnel --> increased latency
04:26 mupuf: fortunately, my flat should be elligible to 350/20MBit internet
04:26 mupuf: ... when I manage to register as a Finnish permanent resident
04:26 mupuf: until then, 4G modem!
04:26 pmoreau: :)
04:46 Cloudef: I heard everyone is finnish here
04:47 mlankhorst: lies
04:47 mupuf: not really no, pq is
04:47 mupuf: and I happen to live in Finland now
04:47 Cloudef: mupuf: what crimes did you commit to end up here?
04:48 Cloudef: "Reverse engineering" isn't answer :P
04:48 mupuf: am I really person in the world attracted to nordic countries?
04:48 urjaman: Cloudef: you could bother with reading the logs ... and yeah i was the one who made the joke at him
04:48 Cloudef: urjaman: good idea
04:48 urjaman: mupuf: welcome to finland :)
04:48 mupuf: Well, no, I met a lot of them already
04:49 mupuf: urjaman: Kiitos :)
06:56 Superymk: Hello, I have one question about host memory (which accessed by the GPU via GART). How could the GPU know which GPU physical address range goes to the GART aperture?
06:57 mlankhorst: Superymk: it uses vm
06:58 mlankhorst: at least for nv50+, older uses dma objects
06:58 mlankhorst: which is similar to segments on x86
07:20 Alph4Num3rik: Hello World, I'm a French guy, so sorry for my english (correct me if I make spelling mistakes)
07:22 Alph4Num3rik: I'm a student in system managment and networking, so I have a good knowledge in Linux and network, but not in development.
07:26 Superymk: mlankhorst: Hmmm... but after vm translate GPU vaddr to GPU paddr, GPU needs to figure out if it needs to directly access VRAM or DMA, right?
07:26 mlankhorst: no, that's part of the vm translation
07:27 Superymk: I see. So that means in the PTE, there must be a bit to indicate the position
07:27 pmoreau: Alph4Num3rik: Hello! Are you looking to contribute to Nouveau?
07:27 mlankhorst: Superymk: and there is.. :p
07:28 Superymk: Cool, thanks mlankhorst!
07:29 mlankhorst: core/subdev/vm/nv*.c vm_map shows how a vram mapping is done, vm_map_sg how a GART map is done. mostly the same except target is different..
07:32 Superymk: but wait... there is one more question. If only the VM can be used to access GART aperture, then I can never put the cursor content in the GART aperture, because cursor use paddr only, correct?
07:32 mlankhorst: wrong
07:33 mlankhorst: or actually might be correct *looks closer*
07:33 Superymk: cursor uses paddr only, correct? Then there must be a way for the GPU to identify which range goes to VRAM and which range goes to GART
07:35 Superymk: :)
07:35 mlankhorst: scanout is special
07:35 Superymk: yes I know
07:35 Superymk: You answered this question before :)
07:36 mlankhorst: iirc it uses the old nv50 dma selectors
07:36 Superymk: yes
07:37 Superymk: This time, my question is that, with such scanout mechanism, the GPU should be able to identify which paddr range goes to VRAM and which range goes to GART, I guess
07:37 mlankhorst: see nv50_fbdma_init
07:37 Superymk: OK, let me see
07:38 mlankhorst: it sets target to VRAM/RDWR, I really don't see why you would ever want to set it to GART..
07:39 Superymk: for example, if I have an i915 + nvidia GPU
07:39 Superymk: I can use nvidia for hw rendering and i915 for output
07:40 mlankhorst: you already can
07:40 Superymk: in that case, the fb is in GART aperture, right?
07:40 mlankhorst: no there is a buffer in GART, but you can blit it to VRAM..
07:40 mlankhorst: and then use that for scanout
07:41 Superymk: wait..i915 does the scanout or nvidia does the scanout? I think it should be i915
07:42 mlankhorst: if i915 has the scanout you don't need a fb from nouveau..
07:44 mlankhorst: you could just allocate a fb in intel, export it to nouveau and render to it from nouveau. the entire nouveau display engine has nothing to do with it then..
07:44 Superymk: Please correct me if I am wrong. I originally think that the nvidia GPU render to a fb, which can be accessed by i915 (so the fb is definitely in the host memory). Then the i915 can scanout the fb
07:45 Superymk: yes
07:45 Superymk: ah
07:45 Superymk: I see what you mean....yes
07:49 Superymk: Thanks mlankhorst! I'll read the code you just mentioned, and see if there is any other questions :)
10:01 rkantos: RSpliet: do you remember my case of getting pch fifo overruns at boot? Who was it that was helping also. Anyway.. Bios was updated, no change
10:19 rkantos: hmm.. seems to be quite a recent bu
10:19 rkantos: https://www.libreoffice.org/bugzilla/show_bug.cgi?id=74102#c7
12:18 vnd: mupuf: ping?
14:02 vnd: hm, could any of you hint me how to diagnose the problem with the fan on gpu?
14:02 vnd: I’ve recompiled nouveau with debug level kernel messages
14:03 vnd: and I have a ton of logs
14:07 vnd: I can see that the fan is set to 40% (many entries: FAN target request: 40%)
14:07 hakzsam: I guess mupuf is asleep, but I could try to help you
14:07 hakzsam: what is your problem?
14:08 vnd: hi hakzsam
14:08 hakzsam: hey
14:08 vnd: my fan is working much much too fast
14:08 vnd: my gfx card is gt 730
14:08 hakzsam: do you have the same "issue" with the blob?
14:08 vnd: what do you mean by blob?
14:09 hakzsam: proprietary driver
14:09 vnd: I haven’t tried them but…
14:09 vnd: I’ve tried other system - livecd of ubuntu and everything works fine there
14:09 vnd: I’m currently on gentoo
14:10 hakzsam: what version of nouveau do you master? git master?
14:10 hakzsam: *have
14:11 hakzsam: and please, paste the dmesg logs
14:12 vnd: one moment, I’m checking it
14:12 vnd: I’m not using the git master sources
14:13 vnd: I use the ones provided by hardened-sources on gentoo
14:13 vnd: The kernel seems to be quite new (3.17.7)
14:15 vnd: hakzsam: you want dmesg with debug info? if so I need to find some way to don’t let it be trimmed
14:15 vnd: currently it shows all of the info since 6’th second after boot
14:15 hakzsam: mmh
14:16 hakzsam: do you see any errors related to nouveau in the dmesg output?
14:16 hakzsam: maybe, you could try this https://nouveau.pmoreau.org/
14:16 hakzsam: archlinux live-cd with pre-installed packages for nouveau
14:17 hakzsam: (to see if the issue still happens with the latest version of nouveau)
14:20 vnd: as far as I remember that live-cd I’ve used hat older nouveau that the one I currently use
14:20 vnd: but let me check it once again
14:20 vnd: I’ll try to reboot with no debug info then I’ll be able to check the nouveau version I think
14:20 hakzsam: okay
14:20 vnd: and then I’ll try to do the same thing on ubuntu live-cd
14:21 vnd: I guess that is some kernel configuration issue but I have no idea what it could be...
14:23 pmoreau: vnd: Each live-cd contains the latest Git head at the moment it was created. However you need to choose the Nouveau entry to get it, otherwise you may get the stock LTS kernel.
14:23 vnd: from obervations I could say that fan speed management “works”
14:24 vnd: pmoreau: you mean arch linux or gentoo or ubuntu?
14:24 hakzsam: vnd, with the nouveau archlinux live-cd
14:24 vnd: ok
14:24 pmoreau: The live-cd hakzsam mentioned
14:25 vnd: I could try it but I think it would work (as ubuntu does even if it has the older version than the one I currently use)
14:26 hakzsam: yes, please try if you have the time
14:27 vnd: I don’t know if you observe this symptoms before but pwm managment “works” - I mean I could turn the fan off (setting 0%) but setting even 1% turns the fan to the very high speed mode - however there’s a difference between let’s say 2% and 40%
14:27 vnd: it’s kinda strange
14:27 mcphail: Is there any way to make the kernel modesetting experience smoother if the EDID is not detected correctly? It has taken me months to get nouveau or radeon drivers working. Previously I had a black screen, which wasn't helpful for debugging. Is there a way nouveau could unload and switch back to vesa if the edid isn't detected?
14:39 vnd: ok, I found that I’m using nouveau 1.2.0 20120801 - if the last digits mean the date it is quite old…
14:39 hakzsam: really old :)
14:40 vnd: strange that it’s the default one on gentoo
14:40 vnd: the kernel is very fresh
14:41 vnd: ok, now I’ll try to check how does it look on ubuntu and than that nouveau arch
14:42 pmoreau: I'm not sure the version number is meaningful
14:42 pmoreau: iirc it's never updated nowadays
14:48 vnd: ok ;) I don’t think it’s the case - on ubuntu it’s 1.1.0 20060810
14:49 vnd: i’ll try to post you guys two dmesg’s - one from gentoo and the other one from working ubuntu
14:49 vnd: maybe you’ll find somethings
14:54 vnd: here’s the working one: http://pastebin.com/0nnpYFTT (ubuntu, the fan speed is ok)
15:00 vnd: and here’s the one that doesn’t work: http://pastebin.com/6M5twnW9 (gentoo, fan is going to took off)
15:00 vnd: hakzsam: ^
15:01 vnd: I can try this arch live-cd but I don’t know if there’s any reason to do it?
15:04 hakzsam: vnd, I don't see any strange stuff
15:15 vnd: ok, I’ve greped for “nouveau” in both dmesgs and the only real difference is irq for MSI/MSI-X
15:15 vnd: there’re also differences in kernel addresses but there’re obvious
15:16 vnd: any guess?
15:16 vnd: luck will be required
15:17 vnd: pmoreau: maybe you?
15:23 vnd: ok, some progress...
15:23 vnd: I was experimenting with the ubuntu and I’ve noticed that if I swich the pwm to manual mode (echo 2 > pwm1_enable), then the fan gets noisy
15:24 vnd: I can turn the fan off (echo 0 > pwm1_min && echo 0 > pwm1)
15:25 vnd: and set it to 1% (echo 1 > pwm1) but then it behaves exactly as in gentoo - so it is running still with very high speed
15:26 vnd: anyway, the silent mode is when pwm1 is 0, pwm1_enable is 2, pwm1_min is 40 and pwm1_max is 100
15:26 vnd: once again - any guess? :)
15:27 vnd: maybe some programmer of pwm system is in here? ;)
22:11 mupuf: too many bug reports on fan management, there must be something really wrong
22:45 pmoreau: mupuf: Too many bug reports at all... :/