01:21 kugel: airlied: ping
06:59 RSpliet: gnurou: Does the Tegra K1 have the GK110-style 256KB/SM register file, or the GK210-style 512KB/SM?
07:01 imirkin_: RSpliet: it's SM35, it has 255 registers. is that what you're asking?
07:01 imirkin_: not aware of any GK210...
07:01 RSpliet: imirkin_: that's per-thread, I'd like to know the size of the total register file (let me find you the right whitepaper link)
07:01 imirkin_: no, i get it
07:02 imirkin_: no idea in that case :) i assume "smaller" :)
07:03 RSpliet: the whitepaper doesn't seem to hold the answer, but I basically wonder whether the GK20A design was derived from the GK210 or the GK110
07:03 RSpliet: the specific GK210 apparently is only used in the Tesla K80 (source: wikipedia)
07:10 gnurou: RSpliet: that would be GK110 I believe
07:12 imirkin_: RSpliet: i don't think GK210 is a thing... K80 is GK110B iirc.
07:12 imirkin_: RSpliet: might be a marketing gimmick
07:15 imirkin_: gnurou: could you confirm that there's no way to bind constbufs >= 8 on kepler compute shaders?
07:19 RSpliet: imirkin_: hmm, regardless of the name, I base my question on page 7 of http://international.download.nvidia.com/pdf/kepler/NVIDIA-Kepler-GK110-GK210-Architecture-Whitepaper.pdf
07:19 RSpliet: (shared mem/SMX is another interesting difference btw...)
07:20 RSpliet: oh, here's the table cut out http://i.imgur.com/adJxmic.png
07:21 imirkin_: right... so only diff is at the MP level
07:22 RSpliet: yes, possibly not too relevant for nouveau (although it might imply differences in grctx)
07:23 RSpliet: nor do I happen to have one of those K80 monsters :-)
07:24 imirkin_: i wouldn't wait on santa to bring one either :p
07:24 RSpliet: they're only 4500 quid
07:38 karolherbst: gnurou: is there somewhere a nice document about the pmu counters found on the gk20a chips? (I bet I asked this already, not sure though)
07:40 karolherbst: gnurou: I think the current nouveau code for them only sets them up and reads them out on the cpu and only a few "core" related ones
07:42 mupuf: karolherbst: yes, nvidia already documented it
07:42 mupuf: and I am pretty sure I added them all in rnndb
07:43 karolherbst: mupuf: I want to know what they really are for though
07:43 mupuf: Ah ah
07:43 karolherbst: this memory related thingies give me a big headache because I have no clue what to do with that one
07:43 karolherbst: it's just not reliable enough with the information we have now
07:43 karolherbst: especially because the nvidia userspace tools read them out really funny
09:21 Lemmata: hello I'm having some issues with noveau. When I do xrandr --listproviders there is only the Intel GPU and my dedicated GPU does not show up. Checking dmesg I get this error: "nouveau: probe of 0000:01:00.0 failed with error -22
09:21 Lemmata: "
09:21 Lemmata: I am running Debian testing with linux kernel 4.4.0-rc8
09:23 RSpliet: Lemmata: my guess is that your second-generation Maxwell GPU is not supported by nouveau yet... which GPU is that again?
09:23 Lemmata: It's a Geforce 640M
09:23 Lemmata: pretty sure it's supported
09:24 RSpliet: I guessed wrong :-)
09:24 Lemmata: :p
09:25 RSpliet: could you post the full dmesg on a paste website of choice please?
09:25 Lemmata: aye aye
09:25 Lemmata: http://pastebin.com/0yXbQ8Bs
09:27 Lemmata: I was discussing this issue with someone else a while back and they found that there was an error having to do with the kernel. They suggested updated the kernel, but that didn't seem to help
09:27 Lemmata: updating*
09:27 imirkin_: Lemmata: ooooh fun. some sort of failure reading vbios...
09:29 imirkin_: Lemmata: could you file a bug at bugs.freedesktop.org xorg -> Driver/nouveau and include an acpidump?
09:29 Lemmata: imirkin_: sure, how do I do an acpidump? :)
09:30 imirkin_: iirc you type "acpidump" :)
09:30 Lemmata: huh, I dont seem to have this command
09:33 Lemmata: does this look right? http://pastebin.com/nRMAu5t4
09:35 imirkin_: Lemmata: doesn't look wrong... please include that as an attachment rather than a pastebin link
09:36 RSpliet: "Genuine NVIDIA Certified Optimus Ready Motherboard"
09:36 RSpliet: lovely strings in there :-D
09:37 Lemmata: hehehe
09:38 Lemmata: I take it that I need a Bugzilla account to file a report?
09:38 imirkin_: that's how it usually works
09:41 karolherbst: "unknown opcode 0x00" that looks wrong
09:42 karolherbst: ahh that comes from the vbios
09:42 karolherbst: Lemmata: could you try to grap the vbios through envytools?
09:42 karolherbst: nvagetvbios
09:42 imirkin_: karolherbst: won't work
09:42 karolherbst: *nvagetbios
09:42 karolherbst: why not?
09:42 imirkin_: coz it's in acpi
09:43 karolherbst: :O
09:43 karolherbst: ohh
09:43 imirkin_: perhaps my comments make more sense now?
09:43 karolherbst: oh I miss your vbios comment
09:43 karolherbst: *missed
09:44 RSpliet: imirkin_: curious, whether the copy is useful at all or not, isn't debugfs supposed to get the right VBIOS? or is that strapped up to PRAMIN as well?
09:44 imirkin_: RSpliet: this stuff ain't magic
09:44 imirkin_: RSpliet: first off, nouveau fails to load
09:44 RSpliet: imirkin_: I know all that
09:45 imirkin_: RSpliet: secondly, even if it didn't, debugfs would show the incorrectly-read-in vbios
09:45 imirkin_: RSpliet: however acpidump should be the source of truth here
09:47 karolherbst: doesn't look like any sort of vbios nouveau would understand is inside this acpidump :/
09:47 RSpliet: imirkin_: thanks for that slightly redundant lecture, but that doesn't really answer my question
09:48 imirkin_: RSpliet: i must have misunderstood your question then
09:48 imirkin_: karolherbst: look at how the _ROM method operates
09:48 Lemmata: just out of curiousity, how can you tell that it is a vbios error?
09:48 imirkin_: karolherbst: normally it reads from a blob, that is the vbios
09:49 karolherbst: Lemmata: "nouveau/nvkm/subdev/bios/init.c: error("unknown opcode 0x%02x\n", opcode);"
09:49 imirkin_: Lemmata: [ 17.160378] nouveau 0000:01:00.0: devinit: 0x9b29[0]: unknown opcode 0x00
09:49 RSpliet: ah, I take it "right VBIOS" is a little vague, sorry if that confused you. I meant "the VBIOS image as nouveau works with"
09:49 imirkin_: Lemmata: it's referring to the init tables in the vbios
09:49 imirkin_: RSpliet: yes, debugfs shows a copy of what nouveau read in
09:50 karolherbst: k, so there are some VRAM related methods inside that acpi stuff :/
09:50 imirkin_: RSpliet: however i believe in this situation nouveau is reading it in wrong, so wanted to get at the soruce
09:51 RSpliet: imirkin_: thanks. :-) yes, I got why you advised Lemmata the way you did, but that doesn't stop me from being curious every now and then ;-)
09:52 imirkin_: RSpliet: i'm rotating my sleep schedule, so my comprehension skills are ... reduced ... but i still don't get what you're getting at
09:52 imirkin_: RSpliet: if you're still unclear on something, perhaps rephrase your question?
09:54 imirkin_: Lemmata: thanks!
09:54 Lemmata: imirkin_: bug report has been filed
09:54 imirkin_: yea, saw it
09:54 Lemmata: imirkin_: haha beat me to it
09:56 imirkin_: weird. they store the vbios as 4 32K-sized blobs
09:57 imirkin_: and they do clamp reading to 4K
09:57 imirkin_: but... in a different way than everyone else
09:58 imirkin_: Lemmata: if you feel like patching your kernel, there's an easy way to make it work i think
09:58 Lemmata: imirkin_: sure, I'm always up for learning something new :)
09:59 imirkin_: Lemmata: pull up drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
09:59 imirkin_: Lemmata: and comment out the line "{ 0, &nvbios_acpi_fast },"
10:04 Lemmata: imirkin_: I have to download the kernel, edit that line, and package/install the kernel, yes?
10:05 imirkin_: Lemmata: oh, well i assumed you already built your own kernel
10:05 imirkin_: Lemmata: but... yes. i guess one could potentially arrive at a simpler sequence of steps, but less deterministic
10:05 Lemmata: imirkin_: I've done it once before, but in a really naiive manner (just using old kernel settings)
10:06 Lemmata: imirkin_: but the kernel I'm using right now is provided as a Debian package
10:06 imirkin_: unfortunately it doesn't look like your vbios is in the acpidump itself
10:06 imirkin_: so i can't just give you a blob to use
10:08 RSpliet: Lemmata: you can use the same kernel configuration. I don't know the exact debian kernel build procedure, but perhaps you can dig up the source package for your kernel and work from there
10:09 Lemmata: RSpliet: yea, it's not a problem. The whole process is outlined in the admin handbook, it'll just take me a little while as I'm a bit new to this
10:20 Lemmata: imirkin_: the only line to commend is under the nvbios_shadow() function, correct?
10:20 Lemmata: comment*
10:21 imirkin_: Lemmata: yes
10:21 imirkin_: https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nvkm/subdev/bios/shadow.c#L172
10:21 imirkin_: this is the line to comment out
10:22 Lemmata: yup, got it
10:25 imirkin_: Lemmata: i've included my analysis of what's going on
10:25 imirkin_: Lemmata: i believe it's a bug in the _ROM method :(
10:26 imirkin_: Lemmata: that said, it's a shipping device, so at the end of the day we have to deal with it somehow
10:28 imirkin_: Lemmata: out of curiousity, what device is this?
10:29 imirkin_: i guess i should be able to tell from the acpidump...
10:29 imirkin_: sony vaio something
10:29 Lemmata: imirkin_: VAIO SVS151A11L laptop
10:29 imirkin_: ah thanks
10:30 Lemmata: imirkin_: it's the US version, don't think that makes a difference
10:30 imirkin_: NTSC vs NTSC-J? :)
10:32 Lemmata: imirkin_: lol
10:33 Lemmata: imirkin_: and yet Japan is DVD region 2 and US is region 1!!! :/
10:34 imirkin_: and its flavor of NTSC was different
10:37 Lemmata: imirkin_: true...
10:38 Lemmata: imirkin_: maybe they just really wanted to screw with people importing television series, having the same DVD region as SECAM and PAL
10:38 imirkin_: well iirc they have 50hz ac vs 60hz ac
10:39 imirkin_: which naturally dictated tv-related frequencies
10:39 Lemmata: huh, go figure
10:40 imirkin_: i don't remember the deal with SECAM/MESECAM... those were closer to PAL iirc
10:40 Lemmata: trading energy with neighboring states must be interesting
10:40 imirkin_: japan doesn't have too many of those
10:42 Lemmata: haha, they actually have a split grid, the east is 50 Hz and the western part of Japan is 60 Hz
10:43 imirkin_: down the middle? seems like doing it by island would make more sense... but what do i know
10:44 imirkin_: (or, you know, have a national standard. that could make sense too.)
10:44 pmoreau: Yep, that created some interesting situation with Fukushima: western Japan couldn't send electricity to eastern Japan --"
10:44 imirkin_: all the same voltage at least?
10:45 Lemmata: There seem to be 3 frequency coverters: https://en.wikipedia.org/wiki/File:Power_Grid_of_Japan.svg
10:45 imirkin_: hilarious
10:45 imirkin_: and i thought switzerland was weird for having a different plug than the rest of europe
10:46 Lemmata: imirkin_: The UK does it's own thing as well... with its fat ugly plugs
10:46 imirkin_: UK is an island
10:46 imirkin_: i.e. doesn't count :)
10:48 Lemmata: you would think being an island and having limited space would make their plugs smaller... but no....
10:49 imirkin_: perhaps as an homage to the empire it once was?
10:51 Lemmata: yes they have plenty of that. The gas tanks don't come with built-in valves, instead you need a "key" which is easily lost.
10:52 RSpliet: well, at least you don't need a transformer for UK->EU plugs, US on the other hand only delivers 110V
10:52 RSpliet: or 115-ish
10:53 imirkin_: i think nominally 120V
10:56 Lemmata: fortunately havent run into any fireworks yet using UK -> US converters :p
10:56 imirkin_: famous last words
10:56 RSpliet: nah, just takes twice as long to charge my battery in the US, and my toothbrush refuses to charge at all
10:57 Lemmata: oh, don't get me started on boiling water
10:57 RSpliet: heh, here in Cambridge they don't have water, just liquid limescale
10:58 Lemmata: that bad huh? I thought snowy states were supposed to have better water
10:58 RSpliet: Cambridge UK ;-)
10:58 Lemmata: ahhh
10:58 imirkin_: Cambridge, MA as well
10:58 Lemmata: you're from the "other" place
10:59 RSpliet: the 1209 Cambridge :-P
10:59 linkmauve1: RSpliet, haha, true. :D
10:59 linkmauve1: Hi from Cambridge, btw. o/
11:00 Lemmata: Oxford water probably isn't much better
11:16 Lemmata: imirkin_: what does this _ROM method do?
11:17 imirkin_: it returns the vbios
11:18 imirkin_: normally it'd be in an option rom, but with newer laptops it comes out of acpi
11:18 Lemmata: imirkin_: I see, so it's just setting the address and lengths for reading out the vbios?
11:19 imirkin_: yep. 4K at a time
11:19 imirkin_: but some bioses allow getting it all at once
11:19 imirkin_: so we try that first (this is the "fast" method)
11:20 Lemmata: imirkin_: so we're commenting out the fast method because it reads it incorrectly?
11:20 imirkin_: that's right
11:20 imirkin_: normally the fast method figures out that it didn't work
11:21 imirkin_: but due to a bug in your _ROM method, that doesn't happen
11:22 Lemmata: alright, so I see that you store arg0 as local0 and arg1 as local1, so why do you want to replace those in Add(arg0, arg1, local2)?
11:22 imirkin_: heh
11:23 imirkin_: coz local1 gets clamped to 0x1000
11:23 imirkin_: but arg1 does not
11:23 Lemmata: ahhh
11:23 imirkin_: really Add(Arg0, Local1, Local2) would work too
11:23 imirkin_: but at that point, might as well use Local0 :)
11:23 Lemmata: but cleaner code ;)
11:23 imirkin_: i dunno if there are various ACPI language restrictions on this stuff, btw
11:24 imirkin_: i can kinda read it, but i def can't write it
11:25 Lemmata: im not sure what you mean by acpi language restrictions
11:26 imirkin_: who knows if you can add Arg0 and Local1
11:26 Lemmata: I see
11:27 Lemmata: but adding Local0 and Local1 shouldn't be a problem
11:27 Lemmata: ?
11:27 imirkin_: no clue
11:28 Lemmata: so the code you posted is written in this ACPI language?
11:28 imirkin_: it's a decoding of the acpidump you provided
11:28 imirkin_: (well, a part of it)
11:29 Lemmata: how did you decode it?
11:29 imirkin_: with my bare hands!
11:29 imirkin_: heh
11:29 Lemmata: not bear hands?
11:29 imirkin_: acpixtract + iasl -d
11:31 Lemmata: cool thanks
11:45 Lemmata: imirkin_: so this acpidump, or at least the section you decoded, where does it come from? Is it just the machine code of the DRM component of nouveau?
11:54 pmoreau: l1k: It did lock up similarly on your 4.3.3 branch, so I think the unhappiness comes from one of your patches, which might trigger a lockup due to some insufficient setup by Nouveau.
11:56 pmoreau: l1k: I'd really like to have a look at it this week, not to hinder the upstreaming, but with FOSDEM getting quite close…
11:56 l1k: pmoreau: you're really fast
11:56 pmoreau: l1k: I'll have a look if you're aiming for a 4.5 merge
11:56 l1k: reacting to bugzilla comments like this :)
11:57 pmoreau: :-D
11:57 pmoreau: Well, I would have reacted on the bugzilla directly, if I had an acount on it.
11:57 pmoreau: (Or maybe I do have one, but don't remember my ids…)
12:08 imirkin: Lemmata: ACPI tables are provided by the bios(/efi)
12:16 l1k: pmoreau: could you test it with "drm.debug=0xf nouveau.debug=debug,therm=info,i2c=trace,disp=trace log_buf_len=10M" and send me the dmesg output?
12:17 l1k: pmoreau: I think for a 4.5 merge it's too late, it would have to get reviewed + merged + pulled this week.
12:20 Lemmata: imirkin_: so is it that the error in the _ROM method is an error in how the ACPI tables were coded?
12:21 imirkin: Lemmata: that's my belief, yes
12:23 Lemmata: imirkin_: so is the _ROM method a means of telling the kernel how to read the vbios quickly?
12:24 pmoreau: l1k: Ok, I'll get you that information. Could be tonight, since it shouldn't take long. :-)
12:24 Lemmata: imirkin_: otherwise, I don't understand why commenting out the acpi_fast method should fix this
12:25 imirkin: Lemmata: acpi tables provide information about the system
12:25 imirkin: Lemmata: the way they do this allows for logic to be built-in
12:25 imirkin: Lemmata: the logic in nouveau to interact with the logic in the tables is not working as intended
12:26 imirkin: Lemmata: based on my understanding of things, i believe that the "fast" method is hitting what is effectively a bug in the acpi table logic
12:27 Lemmata: imirkin_: does this mean that when the fast method requests X bytes of memory the card returns a truncated number of bytes?
12:28 imirkin: Lemmata: in this particular case, the method is only designed to hand out 4096 bytes at a time
12:28 imirkin: Lemmata: however due to a quirk in the logic, it's handing out all the data at once to nouveau
12:29 imirkin: Lemmata: however that data is corrupt
12:29 imirkin: Lemmata: and nouveau doesn't know any better
12:29 Lemmata: imirkin_: that makes a lot more sense now, thanks
12:30 imirkin: so at some point the table just cuts off and is probably filled with 0's
12:30 imirkin: that's just a guess though
12:33 Lemmata: imirkin_: so if your hypothesis is correct, the fast method just needs a way to pick up when it is dealing with this particular graphics card, and set the max bytes to 4096
12:34 Lemmata: imirkin_: and ignore the rest of the corrupted memory
12:34 imirkin: Lemmata: actually it needs to (better?) detect that the data is corrupt
12:34 imirkin: normally there's a checksum that takes care of it
12:34 Lemmata: imirkin_: right, that'd be more robust
12:35 imirkin: the slow method is the one that reads it out 4k at a time
12:39 Lemmata: imirkin_: so is there a hash in the vbios or acpi table which noveau does a checksum against?
12:39 imirkin: vbios should have a checksum of some sort
12:40 imirkin: we might have stopped checking it coz it failed on occasion, causing nouveau to load data from pcirom which was way wrong
12:40 Lemmata: lulz
12:48 airlied: kugel: pong?
13:03 Lemmata: imirkin: progress has been made, dmesg is no longer spitting out the same errors
13:04 Lemmata: imirkin: when I xranr --listproviders I get: Provider 0: id: 0x8a cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 4 outputs: 7 associated providers: 0 name:Intel
13:04 Lemmata: Provider 1: id: 0x5f cap: 0x5, Source Output, Source Offload crtcs: 0 outputs: 0 associated providers: 0 name:nouveau
13:05 imirkin: neat-o
13:06 Lemmata: imirkin: so now how do I get all them 0's to actually show my GPU? :P
13:07 karolherbst: Lemmata: what do you mean?
13:08 karolherbst: just do DRI_PRIME=1 glxinfo
13:08 karolherbst: it should use the nvidia gpu
13:08 imirkin: Lemmata: you may be interested in http://nouveau.freedesktop.org/wiki/Optimus/
13:08 Lemmata: imirkin: reading through it now ;)
13:09 Lemmata: It's just that in the example code it shows 2 outputs: 5 associated providers, etc...
13:09 Lemmata: where as mine is showing all 0's
13:41 karolherbst: Lemmata: because there is no port connected to your nvidia card, which makes things easier for you
14:55 kugel: airlied: hey. I've tried your prime-hw-cursor patch and it didn't work for me
14:56 kugel: (my setup is reverse prime with nvidia as primary and inte as secondary)
14:57 airlied: kugel: using nouveau or nvidia?
14:57 kugel: nouveau
14:57 airlied: so you still get sw cursors?
14:58 kugel: I think so. how can I be 100% sure? I'm thinking because I get the same faulty behavior as when enabling sw cursor by hand in a non-prime setup
14:59 kugel: that is blinking cursor in a fullscreen game (https://bugs.freedesktop.org/show_bug.cgi?id=93732)
15:00 kugel: the game runs full screen on the display attached to the nvidia gpu, it should use hw cursors as per your patch for that dispay right?
15:02 airlied: not sure you might need to add printf to make sure you get hw cursor in that case
15:06 kugel: will in the coming days. however I'm fairly sure it's not working, because I can't see any change in behavior with or without your patch and it's the same as when forcing sw cursors even in non-prime
15:07 kugel: btw, I cherry-picked http://lists.x.org/archives/xorg-devel/2015-June/046634.html onto X 1.18.0, the other patches in that series have been integrated into 1.18.0 already
15:09 kugel: airlied: anyway, I'll to be sure via printf or log (what's the preferred function call for this?). this was just to let you know. I'm also happy to test any new patch if you happen to pick this up again
15:10 kugel: not having hw cursor is a deal breaker for my setup due to the bug above (blinking sw cursor renders the game unplayble)
15:12 kugel: also thanks for all of your hard work for the graphics stack over the years, I've been following your (and other people's) work since the very early vgaswitcheroo days :)
15:17 airlied: kugel: ErrorF in the server is probably easier to find
15:19 haagch: i'm running a chromebook with tegra k1 with (almost) the archlinux arm mainline 4.4 config. I can modprobe and rmmod nouveau just fine, but I don't think it does anything (doesn't print anything in dmesg when loading), specifically I don't have /dev/dri/renderD128. Is there some special config that's needed for render nodes?
15:20 haagch: i also compiled and insmod'ded Gnurou/nouveau, but no luck with that either
15:21 karolherbst: haagch: dmesg pls
15:22 haagch: https://gist.github.com/ChristophHaag/bf4883be64560d463bbe
15:24 karolherbst: haagch: does lsmod show anything interessting?
15:25 haagch: not really https://gist.github.com/ChristophHaag/69a0ac2b718d04df2cac
15:26 karolherbst: tegra_drm
15:26 haagch: does nouveau need to be loaded instead of tegra_drm?
15:26 karolherbst: lspci -v
15:26 karolherbst: I have noe clue, but I would say so, because tegra_drm might use the gpu part already
15:26 haagch: there is no pci..
15:26 karolherbst: lspci -v will sho for sure
15:27 karolherbst: ohh right, I am not used to the arm stuff yet
15:27 haagch: me neither
15:27 karolherbst: haagch: but did you try lspci -v ?
15:27 haagch: yes, no output
15:28 karolherbst: ahh k
15:28 karolherbst: but it could also be, that tegra_drm doesn't do a thing here :/
15:28 karolherbst: ahhh
15:28 karolherbst: haagch: which tegra do you have?
15:29 karolherbst: tegra_drm is used for the pre kepler based tegras
15:29 karolherbst: and nouveau for the kepler ones
15:29 haagch: tegra k1, gk20a
15:29 karolherbst: haagch: you could try to blacklist the tegra_drm module then
15:30 karolherbst: it doesn't seem that you have any initramfs stuff?
15:30 karolherbst: if you have it, you have to rebuild it after adding the blacklist entry
15:30 haagch: no
15:30 karolherbst: ohh wait
15:30 karolherbst: tegra_drm is still be used
15:30 karolherbst: my mistake
15:31 karolherbst: then we could do this
15:31 karolherbst: haagch: load nouveau with debug=trace
15:32 karolherbst: dmesg should print something I hope
15:33 haagch: insmod nouveau.ko debug=trace, nothing in dmesg
15:33 karolherbst: gnurou: I am out of ideas ^^
15:37 karolherbst: haagch: I assume that glxinfo/eglinfo will only print software renderer stuff?
15:37 haagch: yes, llvmpipe
15:38 haagch: there's no proper 3d acceleration support anyway, but i want to test https://github.com/Gnurou/xserver/commit/a894e721c12c248d8fb5d497a8be9d3f14193ebb, so working nouveau render nodes would be helpful :)
15:39 karolherbst: why shouldn't be there proper 3d acceleration support? What's the point of having a gpu then otherwise?
15:40 karolherbst: glamor is 2d acceleration by the way
15:40 chithead: you can buy gpu add-in boards that don't even have a monitor output
15:40 karolherbst: which depends on working 3d acceleration
15:41 karolherbst: chithead: yeah but then you use them either for 3d acceleration or OpenCL/cuda workloads
15:41 haagch: i mean proper that it's not in upstream x server
15:41 karolherbst: x doesn't do much 3d by the way
15:41 karolherbst: it's in mesa
15:41 haagch: i've read that the tegra k1 only has the bare gpu core and nothing else that normal gpus have, so it can only be used with render nodes
15:41 karolherbst: except glamor, but glamor uses gl for 2d acceleration
15:41 karolherbst: ohh i see
15:42 karolherbst: still glamor is for 2d acceleration ;)
15:43 karolherbst: haagch: you should check if the gpu device is somewhere recognized at all, because I can only think of the possibility, that the gpu core isn't found by your kernel at all
15:44 karolherbst: no idea why, but it seems that way
15:44 grknight: is there a known location of the new firmware used in kernel 4.3? "nouveau 0000:01:00.0: Direct firmware load for nvidia/gf114/fecs_inst.bin failed with error -2" cannot find the gf114 anywhere
15:44 karolherbst: grknight: I guess it is "nvidia/gf114/fecs_inst.bin"
15:44 grknight: karolherbst: yeah, but where to get it?
15:44 karolherbst: grknight: same files, just different names
15:45 karolherbst: grknight: 409 = fecs, 41a = gpccs
15:46 karolherbst: ad = data, ac = inst I think, not quite sure
15:47 karolherbst: grknight: upstream patch: https://github.com/karolherbst/nouveau/commit/44fe057064d53f8053bc167f48a8bdae5ff72aaf?diff=unified
15:47 karolherbst: fuc409c => fecs_inst and so on
15:47 grknight: hmm. thanks
15:49 karolherbst: haagch: do you have any parameters set for nouveau? maybe something inside /etc/modprobe.d/ ?
15:51 karolherbst: ohh wait, this shouldn't effec insmod :/
15:52 karolherbst: haagch: anyway, that's the entry point of nouveau: https://github.com/Gnurou/nouveau/blob/staging/work/drm/nouveau/nouveau_drm.c#L1075
15:52 karolherbst: maybe you could add some printk(KERN_ERROR "something\n"); in it to see where it exactly fails
15:52 haagch: KERN_ERR
15:53 karolherbst: k, I always get that wrong
15:53 karolherbst: obviously I then use KERN_WARN
15:53 karolherbst: ...
15:53 karolherbst: :D
15:54 haagch: yea, at least that one runs
15:54 karolherbst: nouveau_drm_init? k
15:54 karolherbst: then I think you might figure out where it returns
15:54 karolherbst: my first guess would be if (!nouveau_modeset)
15:54 karolherbst: because that really looks like a silent fail
15:55 haagch: nope, init seems to work
15:57 haagch: and linus really doesn't want to debug the kernel with gdb
15:57 karolherbst: how would you do that anyway?
15:58 karolherbst: haagch: I think the next function to be called is nouveau_drm_load
15:59 haagch: it's not called
15:59 karolherbst: mhh
15:59 karolherbst: then something inside drm is weird
15:59 karolherbst: or nouveau_drm_probe
16:00 haagch: not called either
16:01 karolherbst: haagch: what does drm_pci_init return in nouveau_drm_init?
16:03 haagch: hm, -645309232
16:04 haagch: oh, wrong
16:06 haagch: when the function takes a format string and actually compiles without anything to format
16:06 haagch: -16
16:06 karolherbst: EBUSY
16:07 karolherbst: well drm_pci_init is part of the drm module
16:07 karolherbst: maybe there is a way to increase the debugging output of it, but I never played around with that, so I have no clue
16:09 karolherbst: pci_register_driver fails somewhere then
16:10 karolherbst: haagch: no idea, but maybe you could increase the global debugging level of the kernel a bit
16:11 karolherbst: loglevel=7
16:11 karolherbst: but that might cause too many messages
16:18 haagch: hm, I rebooted and now i can't load the module anymore, a lot of unknown symbol errors...
16:23 haagch: and after make clean and recompile it works again. weird. maybe gcc update
16:29 haagch: maybe it's something with LPAE and that the system has all 4 gb of ram.. that's the config I'm using anyway: https://github.com/sctincman/PKGBUILDs/blob/nyan-kernel/core/linux-armv7/config
16:34 karolherbst: haagch: really no idea, there is something odd while loading the module, but I have no idea what exactly
16:34 karolherbst: higher logging level might tell you though
16:40 Lemmata: karolherbst: got it, thanks
16:44 Lemmata: imirkin: video card seems to be working now. Shall I add a comment to the bug report?
16:52 haagch: aaand now i can't load the wifi module anymore: "no such device". time to go to bed
16:52 haagch: karol: if you read the log, thanks for taking the time
16:56 mupuf: DRM,1,3,0,nouveau,20120801,nVidia Riva/TNT/GeForce/Quadro/Tesla,0x10de,0x1056 <-- wow, is this really what we expose to the userspace about our DRM driver?
16:57 mupuf: I guess, if we drop Tesla, we should be good to go :D
18:46 gnurou: haagch: I'd bet your device tree is missing the node for the GPU, or has the wrong node?
18:46 gnurou: haagch: if you are using the device tree that came with your chromebook originaly, that's very likely the case
18:47 gnurou: the GPU on Tegra is not on the PCI bus, so anything PCI-related will not be called
23:08 imirkin: mupuf: actually there are cards whose marketing name is Tesla K40 or whatever.