00:10 mlankhorst: gnurou: can you test the following patch? https://paste.debian.net/284383/
00:38 gnurou: mlankhorst: my Jetson seems to be happy with it. You will want to confirm with tagr that this is ok though
00:41 mlankhorst: yeah just asked him in #dri-devel, seems that it breaks dsi and edp :/
00:42 mlankhorst: which I kind of find weird since it runs the same sequence to power off a crtc.
01:35 karolherbst: somebody want to review some more envytools patches?
02:11 karolherbst: hi skeggsb, do you have some time? ( imirkin imirkin_ ping )
02:12 hakzsam: karolherbst, what about values 2 and 3 of reg 0x460? I assume they are undefined but I just want to make sure
02:12 karolherbst: I seriously don't know
02:13 karolherbst: this is just what we got since we started with the pcie 2.0 3.0 thing
02:13 karolherbst: its pretty empty though
02:13 karolherbst: for me the entire reg is something like 80089000
02:13 karolherbst: for 2.5GT/s
02:14 karolherbst: the 9 could mean something, but its the same everywhere
02:15 hakzsam: and 80089020 for 5.0GT/s, right?
02:15 karolherbst: ohh wait
02:15 karolherbst: you meant the tesla/fermi bits
02:15 karolherbst: this reg is full of stuff
02:15 karolherbst: like this: 0xb06c2220
02:15 hakzsam: yeah, the CONFIG_LINK reg
02:16 karolherbst: values 2 and 3 seems not to be anywhere though
02:16 karolherbst: mhh
02:16 hakzsam: could you show nvascan 0x460?
02:18 karolherbst: I am currently on my kepler card
02:19 hakzsam: karolherbst, btw, a good practice is to document all bitfields even if you don't know what they mean
02:19 hakzsam: and mark them as UNKXX
02:20 karolherbst: I see
02:21 karolherbst: ahh but you meant the values not regs
02:21 karolherbst: I don't think value 2 and 3 are existing at all
02:22 karolherbst: but I could imagine that 2 should have beend 8_0GT and 3 16_0
02:22 karolherbst: hakzsam: high="5" then?
02:22 hakzsam: yeah probably
02:23 karolherbst: even up to 8 there is nothing
02:23 hakzsam: karolherbst, pos=5
02:23 karolherbst: okay
02:24 hakzsam: and for example, if the range low=7 high=8 exists, you have to document it and mark it as UNK7
02:24 karolherbst: okay
02:24 karolherbst: I am currently searching through all nvc* traces
02:24 hakzsam: okay
02:24 karolherbst: but its like there are only 6 possible values for this entire reg
02:25 hakzsam: other patches look good to me
02:25 karolherbst: mhh
02:30 hakzsam: karolherbst, if you plug a tesla/fermi I would like to see 'nvascan 0x460' :)
02:30 hakzsam: I only have a kepler right now
02:30 karolherbst: does it have to be the nouveau driver?
02:30 hakzsam: (at work)
02:30 hakzsam: no
02:30 karolherbst: because that gave me nothing
02:30 hakzsam: nothing == ... ?
02:31 karolherbst: yeah
02:31 karolherbst: sure about 0x460 though?
02:31 karolherbst: and you don't mean 0x088460 ?
02:32 hakzsam: my bad, yes, I was looking at 0x460 :D
02:33 karolherbst: the latter gives me b06c2210 f7ff2ffc 00042000 *
02:33 hakzsam: forgot to add base addr of PPCI
02:33 karolherbst: what does nvascan do by the way?
02:35 hakzsam: it check bitfields
02:35 hakzsam: +s
02:35 hakzsam: nvascan -c1 0x088460
02:35 hakzsam: 088460: b0681220 f7fb1ffc 00001000 *
02:35 hakzsam: on nva8
02:36 hakzsam: f7fb1ffc is the bitfield
02:36 karolherbst: I see
02:37 hakzsam: <karolherbst> the latter gives me b06c2210 f7ff2ffc 00042000 *
02:37 hakzsam: which card?
02:38 karolherbst: fermi mhh
02:38 karolherbst: 630M
02:38 karolherbst: GF108
02:38 hakzsam: so, you also have to document variants.. :)
02:39 karolherbst: why?
02:39 karolherbst: its also the same for tesla cards
02:40 karolherbst: since G84 its nearly the same
02:40 hakzsam: because the bitfields is not the same between a8 and c1
02:40 hakzsam: f7fb1ffc != f7ff2ffc
02:42 karolherbst: yeah, but the relevent part is the same, isn't it?
02:43 hakzsam: yes
02:48 hakzsam: karolherbst, feel free to show me again when all bitfields of CONFIG_LINK will be documented
02:48 hakzsam: lunch time
03:52 karolherbst: mupuf: one of your card is special
03:52 karolherbst: one of the G94
03:53 mupuf: yeah, I have a lot of those "special" gpus
03:54 karolherbst: its strange though
03:54 mupuf: I like to blend with them, they don't call me names
03:54 mupuf: hmm hmm
03:54 mupuf: :D
03:54 karolherbst: the CONFIG_LINK is usually pretty the same for one card
03:54 karolherbst: like only a few bits are changing
03:54 karolherbst: 1. speed and the first 3 bits
03:54 karolherbst: but yours...
03:55 karolherbst: not yours
03:55 karolherbst: 0xb0602204, then 0x30602200, then 0x30602202
03:55 karolherbst: not the one high bit changing
03:55 karolherbst: *note
03:55 karolherbst: this never happens for other cards
03:56 mupuf: yeah, bit 31 is gone
03:56 karolherbst: yeah
03:56 mupuf: well, I guess we will need to check if it is needed
03:56 mupuf: I still have at least one G94
03:56 hakzsam: karolherbst, but nvascan is the same on this G94, right?
03:56 karolherbst: nv84 and nv86have it not set
03:57 hakzsam: the bitfield should be f7fb1ffc on g94, isn't it?
03:58 karolherbst: who knows, I only have the trace
03:58 hakzsam: ah ok
03:58 karolherbst: I usually demmio and grep through the entire databse
03:58 karolherbst: or part of it
03:59 karolherbst: the reg is pretty much the same though
03:59 karolherbst: fourth byte can be either 0x1 or 0x2
03:59 hakzsam: I bet the bitfield is the same on that card :)
03:59 karolherbst: fifth 0 8 or c
03:59 karolherbst: 8th 3 or b
03:59 karolherbst: and that's pretty much it
03:59 hakzsam: okay
03:59 karolherbst: except the bits we know
04:00 karolherbst: allthough there is sometimes a 0x2 and 0x4 in the first byte
04:00 karolherbst: mupuf: yeah your nv94 is special
04:00 karolherbst: the others always have 0xb
04:00 karolherbst: maybe something was not right with your pcie and it felt back to something slower?
04:01 karolherbst: ohhh
04:01 karolherbst: this could be the pcie v2 bit
04:02 hakzsam: did you make progress at documenting all unknown bits of the CONFIG_LINK reg btw?
04:03 karolherbst: I did something wrong
04:03 mupuf: hakzsam: how do you plan on REing this?
04:04 hakzsam: mupuf, I don't plan to RE that, but we can mark unknown bits as UNK as usual
04:05 mupuf: hakzsam: yeah, but the funky thing about this reg is that you can't really run nvamask on it "s
04:05 hakzsam: why?
04:05 mupuf: so it is hard to know where the fields are
04:05 hakzsam: you mean nvascan?
04:06 mupuf: because it crashes the PCIe link ... which is kind of annoying to read back the results
04:06 mupuf: yes, sorry. I meant scan
04:06 hakzsam: oh right, this is really annoying
04:06 hakzsam: but when I tried on reator, the card didn't crash
04:07 hakzsam: <hakzsam> 088460: b0681220 f7fb1ffc 00001000 *
04:07 mupuf: really? great!
04:07 hakzsam: on the nva8
04:07 mupuf: it always crashed for me on kepler and maxwell
04:08 hakzsam: okay
04:09 karolherbst: mupuf: what crashed?
04:09 karolherbst: changing pcie link?
04:10 hakzsam: nvscan pcie link register
04:10 mupuf: karolherbst: trying to scan the register that changes the pcie link, yes
04:10 karolherbst: I see
04:10 karolherbst: never did it here
04:11 karolherbst: shall I?
04:11 karolherbst: what can possible go wrong :D
04:11 karolherbst: well
04:11 karolherbst: 08c040: 80089000 ffffffff ffffffff *
04:16 karolherbst: strange
04:16 karolherbst: mupuf: the gpu sets the bit back
04:16 karolherbst: after some time
04:16 karolherbst: I set the byte to 0x3 on the fermi here
04:16 karolherbst: and after 10 seconds or something it was 0xb again
04:17 mupuf: karolherbst: yes, see, you upset the gpu :D
04:17 karolherbst: :D
04:17 mupuf: usually, when you get ffffffff, it is because the gpu stops answering
04:17 karolherbst: nothing changes in lspci though
04:17 mupuf: hmm, interesting
04:17 karolherbst: yeah that I saw already
04:17 karolherbst: will try at 5.0 speed
04:18 karolherbst: maybe I should commit? :D
04:18 karolherbst: mhh
04:18 karolherbst: more strange
04:18 karolherbst: it was set to 5.0 in the reg, but the link was still at 2.5
04:19 karolherbst: commit bit has no influence here
04:21 karolherbst: also poking 0x2 or 0x4 into the first byte does not change anything
04:23 karolherbst: ohhh!!!
04:23 karolherbst: somethign changed
04:23 karolherbst: got 5.0 latency down to 256ns
04:23 karolherbst: instead of 512ns
04:26 mupuf: karolherbst: pretty sweet, using lspci is actually a good idea
04:26 karolherbst: mhhh
04:27 karolherbst: strange
04:27 karolherbst: the latency changes in lnkcap
04:27 karolherbst: and the lnksta fells back to 2.5
04:29 karolherbst: mupuf: could you think of any use case where half latency would be better than doubled speed?
04:29 karolherbst: not in general, but for pcie
04:29 mupuf: do not think about that, do the reverse engineering first
04:30 mupuf: and when you understand how the entire thing works then you can start thinking about how to use it
04:30 karolherbst: th ething is
04:30 karolherbst: either 5.0 speed or 256ns latency
04:30 karolherbst: never both
04:30 mupuf: on your card, maybe
04:30 karolherbst: yeah
04:30 karolherbst: on my card
04:31 karolherbst: bit 2 set
04:31 karolherbst: this drops the latency
04:31 mupuf: I can't talk now, sorry
04:31 karolherbst: okay
04:33 karolherbst: hakzsam: could you check on your card?
04:36 hakzsam: karolherbst, what should I do?
04:37 karolherbst: nvapeek 0x088460
04:37 hakzsam: # nvapeek 0x088460
04:37 hakzsam: ...
04:37 hakzsam: nve6
04:37 karolherbst: ahh kepler
04:37 hakzsam: err, nve7
04:37 hakzsam: yeah
04:37 karolherbst: mhh, need a fermi though :/
04:37 hakzsam: I have one at home
04:38 karolherbst: okay
04:38 hakzsam: I could check this evening
04:38 karolherbst: would be nice
04:38 hakzsam: (if you still need)
04:41 karolherbst: this reg is really strange
04:41 karolherbst: I can poke nearly every value from different cards
04:41 karolherbst: but the gpu just resets all of that
04:41 karolherbst: some bits doesn't get changed, some will be reset later
04:42 karolherbst: only bit 2 seems to be lnkcap L0 latency related
04:43 karolherbst: ohh nice
04:43 karolherbst: the nvascan just messed up my card
04:43 karolherbst: is there a safe way to turn off the card now?
04:43 karolherbst: or unload the module
04:49 mupuf: karolherbst: reboot, I would say
04:49 karolherbst: :/
04:50 karolherbst: maybe I could try to force the card off by executing the acpi bits and the unload nouveau?
04:50 karolherbst: or will nouveau just be too upset
05:35 karolherbst: mupuf: okay, the reg isn't gone in kepler
05:35 karolherbst: I forgot
05:35 karolherbst: but it shouldn't be touched there as far as I tested it out
05:35 karolherbst: ohh wait
05:35 karolherbst: wrong grep
05:36 karolherbst: variants="G84:GF119" ?
05:38 karolherbst: mhhh
05:40 karolherbst: I will figure it out
05:48 tnt: In all the reveng done here, does anyone know what's in PCI configuration space at offset 0x40 ?
05:50 karolherbst: tnt: which family?
05:51 tnt: GK208M
05:52 karolherbst: M?
05:52 karolherbst: mobile I guess
05:52 tnt: yes
05:52 karolherbst: GT7X0M card?
05:52 tnt: yup 730M
05:52 karolherbst: I may know what you mean
05:53 karolherbst: will check in a second
05:53 karolherbst: mupuf: in "G84:GF119" seems nvd9 missing
05:53 karolherbst: I though nvd0 is GF119?
05:54 karolherbst: ǹvd9
05:54 hakzsam: nvd9 == GF119, yes
05:55 karolherbst: tnt: MMIO32 R 0x088040 0x84611043 PPCI.SUBSYSTEM_ID_WR => { VENDOR = 0x1043 | SUBSYSTEM = 0x8461 } this?
05:56 karolherbst: hakzsam: shouldn't demmio resolve 0x088460 to PPCI.CONFIG_LINK with variants="G84:GF119" then?
05:56 tnt: karolherbst: arf, yeah, it's just the subsystem ID ...
05:57 hakzsam: karolherbst, yes, if the chipset is between G84 and GF117
05:58 karolherbst: ohh
05:58 hakzsam: GF119 is exclusive IIRC
05:58 tnt: karolherbst: thanks ! At least now I know how to differentiate between the two methods. (ACPI changes the subsystem id).
05:58 karolherbst: :/
05:58 karolherbst: what would be the proper range then?
05:58 karolherbst: G84:GF120 ?
05:58 hakzsam: G84:GK104
05:58 karolherbst: ohh okay
05:59 karolherbst: yeah, seems to work now, thanks
05:59 karolherbst: didn't now that
05:59 hakzsam: GF120 doesn't exist, and the next chipset after GF119 is GK104
05:59 karolherbst: the reg is there on keopler though, but it only contains 0x0
06:00 karolherbst: hakzsam: current version: https://github.com/karolherbst/envytools/commit/9f9959c8324ecafb049fea485197e3ec7819fd24
06:00 karolherbst: maybe I figure out bit 2 today, maybe not
06:01 karolherbst: all the others, no clue really
06:01 karolherbst: maybe 31 is pci 2.0 related
06:01 hakzsam: reverse engineering takes long time :)
06:03 hakzsam: that reg doesn't exist on nv50?
06:03 karolherbst: I could mark every bit UNKXX if it has different values across boards though
06:03 karolherbst: no
06:03 karolherbst: its doing pcie 2.0 stuff
06:03 hakzsam: okay
06:03 karolherbst: link reconfiguration
06:03 hakzsam: yes, please mark unknown bits with UNKXX
06:03 karolherbst: there is a pcie v1.0 to pcie v2.0 bit though in another reg
06:18 karolherbst: hakzsam: what should I do about the bits which are the same across all cards?
06:20 hakzsam: + <reg32 offset="0x460" name="CONFIG_LINK" variants="G84:GK104" --> first you have to remove the variants tag here because bitfield are not the same across all cards, this variants tag must be tied to the bitfield tags
06:21 hakzsam: for example:
06:21 hakzsam: <bitfield low=0 high=2 variants=g84:g98/> <bitfield low=0 high=3 variants=g98 />
06:22 hakzsam: in case we have one more bit on g98+
06:25 karolherbst: I see
06:39 karolherbst: hakzsam: 0x30600000 seems to be always set for all cards, how should I handle this?
06:51 hakzsam: karolherbst, variants="g84-" should be good
06:52 karolherbst: but should these bits be tagged with UNK, too?
06:53 hakzsam: if you don't know what they mean, yes
06:55 karolherbst: what does the nvascan gives us? bits which are constant and doesn't mean anything?
06:56 hakzsam: no, bits which can be set
06:57 karolherbst: but then also bits which can't be set
06:57 hakzsam: sure :)
06:58 karolherbst: but how should these be handled in the rnndb?
07:00 hakzsam: sec, I'm going to give you a full example
07:05 hakzsam: karolherbst, http://hastebin.com/umeyaruvet.xml
07:06 hakzsam: I assume I know nothing about this reg, I just documented all bitfields
07:06 karolherbst: okay
07:11 karolherbst: you scan was 088460: b0681220 f7fb1ffc 00001000 * on nva8?
07:11 karolherbst: *your
07:11 hakzsam: yes
07:12 karolherbst: ahh its the paste also
07:12 hakzsam: yeha
07:16 karolherbst: hakzsam: If I find a trace with 0x2000 set and one without it, buts its the same chip, I can assume, this bit can be set for this chip?
07:18 hakzsam: karolherbst, not sure, nvascan will tell you if this bit exists and in case of 0x088460 on nva8, it is
07:19 karolherbst: the problem is, I don't have that many cards here ;) only the one fermi, so I can hardly use more than the traces
07:21 hakzsam: if you only have a GF108 for example, you can add a variant tag with "GF108-" (and assume that the bitfield is the same for next chipsets)
07:22 hakzsam: karolherbst, http://ng.0x04.net/~mwk/scans/ --> here there is lot of traces but the site is currently dead.. :/
07:22 karolherbst: I got the stuff from mupuf
07:23 hakzsam: you can start by documenting only one chipset and improve doc later
07:24 karolherbst: allthough in the traces I already see some changing bits, could just leave the stuff out I really don't know
07:26 hakzsam: in my opinion, you should really start by documenting only one variant at a time, the GF108 one in your case
07:37 karolherbst: hakzsam: bit 12 is always 1 for you, right?
07:37 hakzsam: on nva8?
07:39 karolherbst: yeah
07:40 hakzsam: I didn't check in details, but it seems, yes
07:40 karolherbst: if I didn't do something wrong: https://github.com/karolherbst/envytools/commit/f489f812271ad180b608189cd7f2b8223ab11827
07:40 karolherbst: still checking traces though
07:40 karolherbst: maybe I find something
07:51 hakzsam: karolherbst, are you sure about <bitfield pos="0" name="COMMIT"/> because the bitfield is 0xc
07:51 karolherbst: yes
07:51 karolherbst: will test though
07:52 hakzsam: [root@reator ~]# nvapeek -c1 0x088460
07:52 hakzsam: 00088460: b0681220
07:52 hakzsam: [root@reator ~]# nvapoke -c1 0x088460 b0681221
07:52 hakzsam: [root@reator ~]# nvapeek -c1 0x088460
07:52 hakzsam: 00088460: b0681220
07:52 karolherbst: check lspci
07:52 karolherbst: you need the commit bit to actually change the speed
07:53 karolherbst: nvapoke -c1 0x088460 b0681210
07:53 karolherbst: won't change pcie speed to 2.5
07:53 karolherbst: nvapoke -c1 0x088460 b0681211
07:53 karolherbst: has to be done
07:54 hakzsam: do I need to add some options to lspci?
07:54 karolherbst: -vv
07:55 hakzsam: okay this one: LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
07:55 karolherbst: no
07:55 karolherbst: LnkSta
07:55 hakzsam: okay
07:56 mwk: hakzsam: ng.0x04.net is permanently down, but I've put up a copy at http://0x04.net/~mwk/scans/
07:56 hakzsam: oh nice, thanks :)
07:58 hakzsam: karolherbst, give me the full commands to change the pcie speed, please :)
08:01 karolherbst: okay
08:01 karolherbst: first I need your current lspci -vv -s ... output of the card
08:01 karolherbst: allhtouh
08:01 karolherbst: it should have v2 already
08:02 karolherbst: then
08:03 karolherbst: nvapoke 0x088460 b0681220
08:03 karolherbst: no
08:03 karolherbst: nvapoke 0x088460 b0681221
08:03 karolherbst: this
08:03 karolherbst: should be enough
08:03 hakzsam: http://hastebin.com/caxesokoga.xml
08:03 karolherbst: ahh the cap
08:03 karolherbst: right
08:03 karolherbst: we need to fix this first
08:04 karolherbst: nvapeek 0x00154c
08:04 hakzsam: # nvapeek -c1 0x00154c
08:04 hakzsam: 0000154c: 0000023d
08:05 karolherbst: nvapoke 0x00154c 0x2bd
08:05 karolherbst: nvapoke 0x088460 b0681221
08:05 karolherbst: done
08:06 hakzsam: same http://hastebin.com/ayezokorux.xml
08:07 karolherbst: allthough the LnkCap is now at 5.0
08:07 karolherbst: ahh
08:07 karolherbst: I see the issue
08:07 karolherbst: mhh
08:07 karolherbst: "Exit Latency L0s <256ns" this has to change to Exit Latency L0s <512ns
08:08 hakzsam: the LnkCap is related to 0x154c, right?
08:08 karolherbst: a bit
08:08 karolherbst: not all
08:11 hakzsam: karolherbst, did you try on nva8?
08:12 karolherbst: okay, got it
08:12 karolherbst: nvapoke 0x088460 b0681220
08:12 karolherbst: nvapoke 0x088460 b0681221
08:12 karolherbst: if not then this:
08:12 karolherbst: nvapoke 0x088460 b0681210
08:12 karolherbst: nvapoke 0x088460 b0681211
08:12 karolherbst: nvapoke 0x088460 b0681220
08:12 karolherbst: nvapoke 0x088460 b0681221
08:14 hakzsam: still 2.5...
08:14 karolherbst: mhh
08:15 karolherbst: at least the cap changed
08:15 hakzsam: yes
08:16 karolherbst: on my fermi card I have to poke b0602221
08:18 hakzsam: karolherbst, do I need to have nouveau module loaded?
08:18 karolherbst: never tried with blob
08:18 karolherbst: but the blob changes the speed all the time
08:19 karolherbst: its tied to pstates
08:19 hakzsam: okay
08:21 karolherbst: imirkin: hi
08:22 imirkin: howdy
08:25 imirkin: mupuf: the infinite loop in alarms is back.
08:28 karolherbst: hakzsam: did you tried with nouveau?
08:28 imirkin: karolherbst: i can't seem to set my 12:15 nibble to 1, so that must be fixed by the system somehow... perhaps by the remote end?
08:29 karolherbst: which reg?
08:29 imirkin: 88460
08:29 hakzsam: karolherbst, no
08:30 imirkin: the 8:11 nibble seems to control LnkCap, and therefore the 4:7 nibble probably controls LnkSta
08:30 karolherbst: imirkin: to be honest, I don't know what this part does
08:30 karolherbst: no
08:30 karolherbst: LnkCap is controlled elsewhere
08:30 karolherbst: tesla: 0x00154c
08:30 karolherbst: later: 0x02241c
08:30 imirkin: multiple things are required
08:30 imirkin: try writing a 1 in there
08:30 imirkin: instead of a 2
08:30 imirkin: and you'll notice that it changes the speed
08:31 imirkin: in the cap
08:31 imirkin: those other regs control pcie v1 vs v2
08:31 imirkin: which is also required for that junk
08:31 karolherbst: no wait
08:31 karolherbst: bit 8 in 0x02241c controlls lnkcap
08:31 karolherbst: bit 1 controlls pcie version
08:31 imirkin: lnkcap is like 100 diff things
08:32 imirkin: what i'm talking about is just the speed in there
08:32 karolherbst: yeah
08:32 karolherbst: me too
08:32 imirkin: and it most definitively is controlled at least in part by 88460
08:32 imirkin: because i just did a write in ther
08:32 imirkin: and it changed
08:32 karolherbst: nvamask $link_cap_reg 0x1 0x00 will change the speed in lnkcap
08:32 karolherbst: mhh
08:32 karolherbst: it can be dropped by this, yeah
08:32 imirkin: try it.
08:32 karolherbst: I noticed that too
08:32 karolherbst: but I couldn't get it to top speed anymore
08:33 imirkin: so the 12:15 nibble is probably what the system supports, the 8:11 nibble is what the card supports, and the 4:7 nibble is the actual speed (in lnksta)
08:33 karolherbst: could be
08:33 karolherbst: would make sense somehow
08:33 karolherbst: 8:15 seems pretty constant for me
08:34 karolherbst: never changed in a card
08:34 imirkin: but you can change it
08:34 imirkin: and when you do
08:34 imirkin: then things in lspci change.
08:34 imirkin: at least for 8:11
08:34 karolherbst: yeah well
08:34 imirkin: for 12:15 i think it's constant -- i tried writing and it wouldn't change
08:34 karolherbst: after some time some bits will change back
08:35 karolherbst: 0x4 for example
08:35 karolherbst: but thats another thing
08:36 imirkin: yeah, i think only 1 and 2 are valid
08:36 imirkin: even though it's a 4-wide bitfield. or you can treat the other bits as reserved...wtvr
08:36 karolherbst: 0x4 actually changes something
08:36 karolherbst: sometimes
08:37 hakzsam: imirkin> so the 12:15 nibble is probably what the system supports, the 8:11 nibble is what the card supports, and the 4:7 nibble is the actual speed (in lnksta)
08:37 hakzsam: this is probably true
08:37 karolherbst: got the lnkcap L0 latency changed
08:37 hakzsam: because I can't change pcie speed on the nva8
08:37 hakzsam: karolherbst, nvapeek 0x088460 ?
08:37 karolherbst: mmmhhhh
08:38 karolherbst: right if byte 4 is 0x1
08:38 karolherbst: the blob never actually tries to get up to 5.0
08:39 hakzsam: I bet you have bit 13 set, right?
08:39 karolherbst: I have 0x2220 for the lower 4 bytes
08:39 karolherbst: mhh
08:39 karolherbst: no
08:39 karolherbst: on fermi
08:39 karolherbst: kepler is different anyway
08:40 hakzsam: okay, so bit 13 is set :)
08:40 hakzsam: on nva8 I have, 0x1210
08:40 karolherbst: 0x10 is configured speed
08:40 karolherbst: this is actually important
08:40 karolherbst: 0x10 is 2.5
08:40 karolherbst: 0x20 is 5.0
08:40 karolherbst: but
08:40 hakzsam: this seems to be pretty logical
08:40 hakzsam: yeah
08:40 karolherbst: cards usually start with 0x20
08:40 karolherbst: and lnksta is still 2.5
08:41 karolherbst: so there has to be at leaste one flush with 0x21 to actually activate 5.0
08:41 hakzsam: right
08:41 hakzsam: at start, I have 0xb0681220
08:41 karolherbst: yeah
08:41 hakzsam: but if 12:15 is what the system supports, that's explain why I can't change the speed
08:41 karolherbst: probably
08:42 karolherbst: there are only two values for this anyway
08:42 karolherbst: wither 0x1 or 0x2
08:42 karolherbst: no card has anything else there
08:42 hakzsam: I''l try at home with my nva8
08:42 karolherbst: name?
08:42 karolherbst: SYS_SUPPORTED_SPEED?
08:42 karolherbst: BUS_SUPPORTED_SPEED?
08:42 karolherbst: hakzsam: where is the card plugged in and wich mainboard?
08:43 hakzsam: this one is on reator
08:43 karolherbst: but we got the cap up to 5.0
08:43 karolherbst: is the cap what the bus or what the card can do?
08:43 hakzsam: I would say, card
08:43 hakzsam: but not sure
08:43 karolherbst: I know that your card can do 5.0 for sure
08:44 karolherbst: or wait
08:44 karolherbst: is it a GeForce 210 ?
08:44 hakzsam: btw, my computer at home is more recent that reator, maybe I'll find some other stuff
08:45 hakzsam: yes
08:45 karolherbst: ...
08:45 hakzsam: huh?
08:45 karolherbst: wiki tells something interessting about that
08:45 karolherbst: there are v2.0 and v1.0 versions out there
08:45 karolherbst: might be wrong
08:46 karolherbst: its the only GT218 with both
08:46 karolherbst: but I would say lnkCap is what the link can do
08:46 karolherbst: because we got 5.0 on reator working I think
08:47 karolherbst: imirkin: do you know for sure?
08:47 karolherbst: mupuf: maybe you?
08:47 imirkin: lnkcap = what the card says the link can do
08:47 karolherbst: ahh okay
08:47 imirkin: lnksta = what the current link is
08:47 imirkin: (status)
08:47 imirkin: and capabilities
08:47 karolherbst: yeah status is obvious
08:48 karolherbst: but the card tells us that the link can do 5.0
08:48 karolherbst: but won't go into 5.0 status
08:48 karolherbst: hakzsam: try to push 0x2221 into the lower byte
08:48 karolherbst: :D
08:48 imirkin: well, if the starting state is 0xb0681220, then that means that the host can't support the 5GT/s speed
08:48 imirkin: so no amount of things that the card does will change that
08:48 karolherbst: its the same with my fermi card
08:48 karolherbst: starts with 0x2220
08:49 imirkin: you also have a 1 there?
08:49 karolherbst: is at 2.5 cap and status
08:49 imirkin: hmmmmmmm
08:49 karolherbst: I have to push the cap to 5.0
08:49 imirkin: oh, but is it v1?
08:49 karolherbst: then I can do 0x2221 to set the status to 5.0
08:49 imirkin: pastebin lspci output
08:49 karolherbst: no v2
08:49 imirkin: from when it's in such a state
08:49 imirkin: and a 88460 read from such a time as well
08:50 imirkin: i'll bbiab, will look then
08:50 karolherbst: http://pastebin.com/Pn4mGXQW
08:50 karolherbst: but I messed with the card already
08:51 karolherbst: okay, lnkcap 5.0 seems to be the default
08:51 karolherbst: no, its cool
08:52 karolherbst: 0xb06c2220 in the reg
08:53 karolherbst: poke 0xb06c2220 didn't change anything
08:53 karolherbst: poke 0xb06c2221 pushed lnkSta to 5.0
08:56 karolherbst: okay
08:56 karolherbst: wait I got it
08:57 karolherbst: ha
08:57 karolherbst: lnkCap: 2.5 lnkSta: 5.0
08:57 karolherbst: poked 0xb06c2120
08:58 karolherbst: yeah we can lie about what the card can to in 8:11
09:02 karolherbst: imirkin: https://github.com/karolherbst/envytools/commit/3b952c2908cab1bc12d584c533c9b48007ed102a
09:02 Manoa: I have a GK110B card, it's not installed yet, but I was wondering if any users have similar card and can share some the experiences with this card type ?
09:05 Manoa: especially from the point of view of running WINE games on it, some people say that open source drivers give better WINE results
09:08 imirkin: Manoa: afaik Tom^ has precisely such a card (GTX 780 Ti)
09:08 Tom^: i have yes
09:08 Manoa: how good has it been to you with nouveau ?
09:08 Tom^: and it runs poorly sadly because reclocking doesnt go past second state, and on that state it hangs frequently
09:09 Tom^: if only i knew more C and had more whiskey i would help ! :p
09:09 Manoa: xD
09:10 imirkin: Tom^: this is even with 4.0 which had the ctxsw fix?
09:10 Tom^: other then that it had some small quirks in the older kernels
09:10 Manoa: I was under the impression that in this card class they removed the states and replaced them with Turbo 2
09:11 imirkin: i guess marketing did their job well
09:11 Manoa: haha
09:11 Tom^: imirkin: yea , its not frequent but it happens from time to time when changing pstate :p
09:11 Manoa: that what it says on the box xD
09:11 karolherbst: Manoa: it does only is faster for some games and only with native d3d9
09:11 Tom^: at random occassions and i find that hard to actually bugtest so i sadly gave up
09:11 karolherbst: and with some I mean like none
09:12 imirkin: well, i think the experience will vary a lot from specific gpu to gpu...
09:12 Tom^: so sure as long as you dont plan to game that much nouveau kinda works :p
09:12 Tom^: but people getting the 780ti i suspect usually want to game ;)
09:13 Manoa: native d3d9 worked very well on the r600 I had in the past
09:13 imirkin: i've definitely heard of people getting much better results on nouveau with d3d9 than with wine-opengl + nvidia
09:13 Manoa: I buyed this for upgrade :)
09:13 imirkin: but definitely not all the time
09:14 karolherbst: yeah it works great on radeon most of the time
09:14 Tom^: imirkin: well yea, i tried once forcing the clocks on the blob to the same state as on nouveau, nouveau ran it better with d3d9 :p
09:14 imirkin: for radeon it's easier since catalyst sucks and the open drivers can reclock.
09:14 Tom^: tbh nouveau even handled wine-opengl nicely too
09:14 karolherbst: where is wine usually bottlenecked, cpu?
09:15 Manoa: I think it depend on the game
09:15 Tom^: karolherbst: a bit of everything
09:15 karolherbst: okay for opengl game obviously not
09:15 Manoa: some games there is mutch load on wineserver in others almost none (starcraft 2)
09:15 karolherbst: I meant like AAA titles
09:15 Tom^: karolherbst: mostly it suffers from not having CMS fully implented, yet.
09:16 karolherbst: yeah, I know
09:16 Tom^: multithreading etc, etc.
09:16 karolherbst: but I am running with them all the time
09:16 karolherbst: the CSMT patches
09:17 karolherbst: imirkin: does the patch look fine so far? Or is there anythig we forgot or isn't "verified" enough yet
09:18 imirkin: the chipsets you're using are highly non-standard
09:18 karolherbst: the unknown bits are there beacuse hakzsam told me to do it that way :D
09:19 hakzsam: karolherbst, if you're interested, on g84 I have 088460: b0681220 f7fb1ffc 00001000 *
09:19 hakzsam: imirkin, yeah, I asked him to document unknown bits as usual
09:19 imirkin: like nothing is ever GT218-
09:19 imirkin: it'd be GT215-
09:19 imirkin: at the least
09:19 Tom^: Manoa: but yea, try nouveau. however make sure you stick to newer kernels. preferrably even the newest ones.
09:19 karolherbst: I think it doesn't make sense to look for the mask here anyway
09:19 hakzsam: imirkin, but I didn't have a detailed look at the patch :)
09:20 imirkin: or GF108 -- it'd be GF100
09:20 Manoa: yhe I am planning to run 4.2, right now I have 3.10
09:20 karolherbst: imirkin: that's because hakzsam has a GT218 and I have a GF108
09:20 Tom^: perhaps imirkin landed some magical 4.1 patches i havent seen yet so gk110b runs better then ever!
09:20 Tom^: =D
09:20 Manoa: xD
09:20 Tom^:has faith.
09:20 karolherbst: I would simply remove the variants bits, because it looks all the same across all cards
09:20 karolherbst: doesn't make sense in the reg, really
09:21 imirkin: unlikely.
09:21 imirkin: karolherbst: i have a GT215
09:21 imirkin: karolherbst: i'd be fine with removing the variants
09:22 karolherbst: yeah, cleaning up
09:22 imirkin: leave the high-level one on the bitfield
09:22 karolherbst: imirkin: did you notice the 0x3 and 0xb last byte?
09:23 imirkin: yeah, probably high bit just means something
09:23 karolherbst: yeah
09:23 imirkin: we'll never know what ;)
09:23 karolherbst: its 0x3 on pcie 1.0 chipsets and 0xb on 2.0 chipsets
09:24 imirkin: so the high bit probably means something in relation to that
09:24 imirkin: you should separate it out
09:24 imirkin: if you haven't already
09:24 karolherbst: nv8* have 0x3 there
09:25 imirkin: <bitfield low="28" high="31" name="UNK28" variants="GT218-"/>
09:25 imirkin: you def want the 31 bit to be a separate thing
09:25 karolherbst: yeah
09:25 imirkin: i.e. <bitfield pos="31" name="UNK31">
09:25 imirkin: type="boolean" too
09:25 imirkin: or perhaps it auto-defaults to that, i forget
09:26 karolherbst: https://github.com/karolherbst/envytools/commit/9530133030c3e31ca6e4f77b50dd49ebd9b8f0f0
09:26 imirkin: just makes the display neater since it'll say like UNK31 instead of UNK31 = 1
09:26 karolherbst: ahh
09:26 karolherbst: okay
09:26 imirkin: do that for all of the single-bit fields
09:26 mupuf: imirkin: never had to say boolean
09:26 imirkin: mupuf: you don't HAVE to
09:27 mupuf: <bitfield pos="31" name="UNK31" /> is enough
09:27 Tom^: imirkin: now that you made me think, didnt you help me trace some freeze down to mesa?
09:27 karolherbst: yeah single bits are boolean
09:27 imirkin: Tom^: conceivable. i def remember you having problems with a ctxsw bug at some point.
09:28 karolherbst: new version: https://github.com/karolherbst/envytools/commit/40a5cfc507dd67b3ae024b1b0a15c6eb649306d9
09:28 imirkin: Tom^: and i'm pretty sure i fixed some gk110 isa emission bugs that you encountered
09:28 Tom^: yea that thing got fixed, but i remember now that you helped me trace something to mesa which i made a bugreport for there
09:28 Tom^: hm
09:28 Tom^: perhaps things is in a betters state afterall, heh.
09:29 imirkin: [and some more since then]
09:29 imirkin: http://cgit.freedesktop.org/mesa/mesa/log/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
09:29 hakzsam: karolherbst, <bitfield low="12" high="15" name="SYSTEM_SUPPORTED_LINK_SPEED"> --> only 12 exists on g84:gk104, except on gf108
09:30 karolherbst: hakzsam: its read only
09:30 Tom^: imirkin: indeed, hm. i think its time for weekend nouveau testing again
09:30 Tom^: :P
09:30 imirkin: hakzsam: it's 2 for me.
09:30 imirkin: i.e. bit 13 is set
09:30 imirkin: i bet it's just like the other ones...
09:30 hakzsam: imirkin, which card?
09:30 karolherbst: yeah its always either 1 or 2
09:30 karolherbst: for all cards
09:30 imirkin: Tom^: well, unlikely that anything reclocking- or speed-related would have changed
09:31 imirkin: hakzsam: GT215
09:31 hakzsam: karolherbst, if it's read-only, you can add 'access="ro"'
09:31 hakzsam: imirkin, strange
09:31 imirkin: Tom^: but there could have been some correctness fixes... i've recently fixed a *ton* of little issues throughout
09:31 imirkin: hakzsam: why is that strange? my mobo supports 5GT/s
09:31 Tom^: imirkin: exactly, and i have to spend my beer with something to fiddle on.
09:31 hakzsam: imirkin, ah okay
09:32 imirkin: Tom^: someone filed a ton of bugs about this or that going wrong, and a bunch of them had easy fixes. a few... not so much =/ and at least one wine issue encountered too (in the opengl they generate)
09:33 karolherbst: imirkin, hakzsam: https://github.com/karolherbst/envytools/commit/7f88a8b965484b8aee8e8addeae150a92f72747c
09:33 karolherbst: anything else?
09:33 karolherbst: should I change the names?
09:33 karolherbst: they are pretty long
09:33 imirkin: yeah
09:33 imirkin: i'd just call it CARD_SPEED and SYSTEM_SPEED
09:34 karolherbst: and SPEED => STATUS_SPEED?
09:34 karolherbst: or CURRENT_SPEED?
09:34 karolherbst: allthouth thats not true
09:34 karolherbst: REQUESTED_SPEED would fit
09:34 imirkin: TARGET_SPEED?
09:35 karolherbst: CARD_SPEED is funny to mess with :)
09:35 karolherbst: lnkcap: 2.5 and lnkSta: 5.0
09:35 hakzsam: I'll have a look later, bbl
09:35 imirkin: yeah... i suspect that card speed should just be left alone
09:36 karolherbst: https://github.com/karolherbst/envytools/commit/6813f17092cba125f71f6d255bacc09ffbe85dca
09:36 imirkin: just coz it's writable, doesn't mean it should be written :)
09:36 karolherbst: :)
09:36 karolherbst: right
09:36 imirkin: that all LGTM
09:36 karolherbst: but we will figure out bit3 today too
09:36 karolherbst: maybe
09:37 karolherbst: somehow I got the L0 latency up to 512us
09:37 karolherbst: *ns
09:37 karolherbst: in lnkcap
09:38 imirkin: i wouldn't worry about it -- i have no idea what that latency is in the first place
09:39 karolherbst: LO is a power save state
09:39 karolherbst: wakeup latency I assume
09:39 karolherbst: yeah "Exit Latency"
09:40 karolherbst: its used by ASPM
09:40 imirkin: which we don't use, i think
09:40 karolherbst: its automatic
09:40 mogorva: Hi! Is it possible to build mesa on a system that uses a 64-bit kernel but userspace is 32-bit?
09:41 imirkin: mogorva: sure
09:41 karolherbst: yes
09:41 imirkin: mogorva: in fact, userspace should be largely oblivious to the fact that it's running on a 64-bit kernel
09:41 imirkin: (there are ways it can figure that out if it really wants to, but the usual things work in the usual ways)
09:42 karolherbst: are there any platforms where this was a big problem in the first place?
09:42 imirkin: karolherbst: "this"?
09:42 mogorva: first i hit this build error: http://hastebin.com/uxoqukofuq.vbs
09:42 karolherbst: imirkin: 32bit userspace on 64bit kernel
09:42 imirkin: karolherbst: linux, in the early days :) compat ioctl's were all broken
09:42 karolherbst: :D
09:43 karolherbst: yeah well...
09:43 imirkin: mogorva: ermmm.... hrm
09:43 karolherbst: this happens
09:43 karolherbst: looks like 64bit code into 32bis assembler or the other way around?
09:43 mogorva: if I disable '--enable-glx-tls' configure option I can get further but later hit: http://hastebin.com/irinitasud.vbs
09:43 karolherbst: yeah
09:43 imirkin: mogorva: yeah, the build system seems to think you're building for a 64-bit target
09:43 mogorva: what am i doing wrong?
09:43 imirkin: (or host? i can never remember what's called what)
09:44 imirkin: mogorva: can i see your configure cmdline?
09:44 karolherbst: mogorva: cflags
09:44 karolherbst: CFLAGS=-m32 CXXFLAGS=-32 LDFLAGS=-32 should help
09:44 imirkin: karolherbst: no, that's for a 64-bit compiler building 32 bits
09:44 mogorva: cflags: http://hastebin.com/ojivurokiq.vbs
09:44 karolherbst: imirkin: maybe his 32bit compiler wants to build for 64bit? :D
09:45 imirkin: mogorva: ok, that all seems fine. i'm guessing that the stupid build system does uname or something and determines that it's on 64-bit and wants to build 64-bit things
09:45 imirkin: mogorva: what does 'uname -m' say?
09:46 mogorva: maybe I shouldn't have installed the 64-bit kernel headers (they're installed in /usr/local/include)?
09:46 imirkin: no, that's fine
09:46 mogorva: uname -m --> x86_64
09:46 imirkin: ok, so that's the problem.
09:46 imirkin: give me a sec
09:47 imirkin: what if you do... ./configure .... --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu
09:47 mogorva: this was the first time I compiled and installed a 64-bit kernel on 32-bit userspace, maybe I was doing something wrong
09:47 imirkin: no, it's the mesa build system that's wrong :(
09:47 mogorva: imirkin, wait a sec
09:47 imirkin: xexaxo: ---^
09:47 xexaxo: imirkin: patches welcome.
09:48 imirkin: looks like mesa uses uname to determine bitness of build?
09:48 xexaxo: nop
09:48 imirkin: xexaxo: how does it determine the build/host targets?
09:48 xexaxo: as we have --enable-asm, it tires to build some misc module which generates some more BS.
09:49 xexaxo: that particular part is the one that requires the explicit --host --build.
09:49 xexaxo: as it sets the "cross" compilation flag, which makes sure that ad-hoc generation is correct.
09:49 imirkin: xexaxo: is --enable-asm good for anything?
09:50 xexaxo: I'd love to see the day where someone clears it up :)
09:50 imirkin: xexaxo: mogorva doesn't have --enable-asm in his configure line btw
09:50 imirkin: xexaxo: http://hastebin.com/raw/ojivurokiq
09:50 xexaxo: imirkin: iirc mostly for legacy application - OpenGL 1.x style
09:50 karolherbst: ...
09:50 imirkin: xexaxo: sure but... why is it an option?
09:51 imirkin: either the thing is beneficial and we always do it
09:51 imirkin: or it's not and we don't
09:52 xexaxo: it's beneficial, and enabled when not cross-compiling
09:52 imirkin: what does cross-compiling have to do with anything?
09:52 karolherbst: gccs asm stuff is a bit odd
09:52 karolherbst: especially sse stuff
09:52 xexaxo: imirkin: just follow how the offending file is generated.
09:53 imirkin: xexaxo: the generator doesn't know how to cross-compile?
09:53 imirkin: i.e. you don't just build it for a particular target?
09:53 xexaxo: imirkin: no the file that's created how to be executed on the build machine.
09:53 imirkin: ugh, that's broken
09:53 imirkin: where is this?
09:54 xexaxo: somewhere in mapi iirc... or maybe mesa
09:54 xexaxo: let me take a closer look
09:54 xexaxo: mapi is a major POS btw.
09:54 imirkin: if you point it out to me, i'll have a look to see if i can just redo it -- coz that's wholly broken
09:54 imirkin: mogorva: did that help btw?
09:55 mogorva: adding '--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu' to ./configure did the trick and now mesa compiled without errors. thank you for pointing that out
09:55 imirkin: np
09:55 xexaxo: hmm.. this seems to be another lovely piece. not the one I'm talking about
09:55 mogorva: is '--enable-asm' needed too?
09:55 imirkin: no :)
09:56 xexaxo: enable-asm is overwritten as you provide the above --host --build
09:56 xexaxo: imirkin: take a look at gen_matypes in src/mesa/Makefile.am
09:56 imirkin: k
09:56 imirkin: will do
09:57 mogorva: what are the benefits if I'm using a 64-bit kernel over 32-bit userspace? (formerly I used 32-bit kernel with PAE)
09:58 imirkin: mogorva: 4GB address space per process instead of 3GB, and easier to have multiple processes use > 4GB of RAM in sum
09:58 imirkin: also file caching/etc
09:59 xexaxo: PAE uses 36bit address doesn't it ?
09:59 imirkin: xexaxo: PAE lets you access up to 36 bits of address space, yes
09:59 imirkin: xexaxo: but... the way that you access things beyond 4G is... obtuse
10:00 xexaxo: imirkin: yes, 4+32 with the added benefit of extra head scratches :)
10:00 xexaxo: thanks.
10:01 mogorva: if I build libdrm and nouveau DDX from git on this 64-bit kernel, do I have to add additional options to configure?
10:01 imirkin: xexaxo: iirc you end up having to use a bounce buffer to access that stuff, so it's highly inefficient
10:01 imirkin: mogorva: no, pretty sure that mesa was unique in its breakage
10:02 xexaxo: would call it breakage, more of design deficiency :\
10:02 imirkin: 32-bit userspace with 64-bit kernel is a moderately common setup, i'm surprised this has gone on so long =/
10:02 imirkin: xexaxo: when it doesn't work, i call it "broken". you can call it "featureful", but... i'll disagree :p
10:02 mogorva: I wonder if the 'out of memory' crash in fear2 still occurs now, have to reboot to try it out
10:03 xexaxo: in no way I would call it a feature, its a nasty thing that should be killed imho.
10:03 imirkin: i'm a *bit* surprised that uname -m returns "x86_64" though
10:03 imirkin: i would have imagined it'd return i686
10:03 xexaxo: but people love keeping such things around.
10:03 imirkin: mogorva: you're sure you have 32-bit userspace?
10:04 xexaxo: but as said - feel free to unravel the bugger.
10:04 imirkin: mogorva: what does "file /usr/bin/uname" say?
10:04 mogorva: yes, I compiled only the kernel, I used 'make ARCH=x86_64 CROSS_COMPILE=/usr/bin/x86_64-linux-gnu- bzImage' et al.
10:05 mogorva: imirkin, /usr/bin/uname: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=f77bad05e9edd43cd98744b07b89a39b3dba3fb2, stripped
10:05 imirkin: ok.
10:05 imirkin: well, my surprise remains ;)
10:05 karolherbst: imirkin: I think uname is right
10:06 imirkin: kinda
10:06 imirkin: i think there's a way to change it... there's that setpersonality ioctl
10:06 karolherbst: otherwise it would have to tell you for what system it got compiled for
10:06 imirkin: but wtvr
10:06 mogorva: uname -a --> Linux gyebro-desktop 4.1.2-nouveau_x64 #2 SMP PREEMPT Tue Jul 21 17:14:58 CEST 2015 x86_64 x86_64 x86_64 GNU/Linux
10:06 karolherbst: man pages are sometimes handy
10:07 karolherbst: -m "print the machine hardware name"
10:09 mogorva: i was unsure about this kernel option, I left it disabled: http://cateee.net/lkddb/web-lkddb/X86_X32.html
10:10 mogorva: should I enable that option?
10:10 karolherbst: won't help you much
10:11 imirkin: no, X32 is something else
10:11 imirkin: it lets you run in a 32-bit address space but with all the other x86_64 stuff
10:12 imirkin: i.e. you still get 64-bit registers, etc
10:13 mogorva: unrelated to mesa/nouveau, i had to disable gcc stack-protector when building a x86_64 kernel on Fedora 22. can anyone tell why is that? i was getting build an error when enabled: http://hastebin.com/gugihabapa.vbs
10:13 imirkin: it's esp good if you have very pointer-heavy data structures
10:14 imirkin: hmmm... because some stuff in the kernel is improperly guarded for the situation where it decides to disable the stack protector even in the presence of a broken compiler
10:14 imirkin: er, even in the presence of the config option to enable it
10:15 imirkin: or... i dunno
10:15 imirkin: but either way, you should probably disable it if the compiler has buggy support
10:16 mogorva: i see
10:17 imirkin: ifneq ($(shell $(CONFIG_SHELL) $(cc_has_sp) $(CC) $(KBUILD_CPPFLAGS) $(biarch)),y)
10:17 imirkin: i wonder if $(CC) is right
10:17 mogorva:is rebooting now
10:18 imirkin: hm no, it is
10:20 imirkin: hmmm... although it was allegedly fixed in 2006
10:21 imirkin: mogorva: i'd report that stack protector issue to linux kernel guys... it seems like it should work, the fix for the issue they're checking for went in in about 2006, so... you should be all set with it
10:22 mogorva: imirkin, maybe i should try a x64 kernel from the official fedora repo to see if stack protector is enabled by default in their build
10:22 karolherbst: imirkin: https://gist.github.com/karolherbst/a48df5f03f25ccc19d9c it makes perfectly sense this way
10:23 imirkin: mogorva: meh, it should be fine either way
10:24 karolherbst: the reg 0x088088 changes according do the stuff in 0x088460
10:24 karolherbst: :)
10:25 imirkin: karolherbst: that makes sense...
10:25 karolherbst: :O
10:25 karolherbst: I found something!
10:25 mogorva: first i built 4.2.0-rc3 x86_x64, but it failed to boot properly, I'm not sure maybe i hit https://bugzilla.kernel.org/show_bug.cgi?id=101061
10:25 karolherbst: one card:
10:25 karolherbst: [0] 137.447191 MMIO32 R 0x088088 0x1101004a PPCI.EXP_LNK_CMD_STA => { CMD = { ASPMC = 0x2 | RCB | CCC } | STA = { SPEED = 2_5GT | WIDTH = 16 | SL_CLK } }
10:25 karolherbst: [0] 137.449478 MMIO32 R 0x088088 0x1011004a PPCI.EXP_LNK_CMD_STA => { CMD = { ASPMC = 0x2 | RCB | CCC } | STA = { SPEED = 2_5GT | WIDTH = 1 | SL_CLK } }
10:25 karolherbst: width
10:26 imirkin: karolherbst: whoa, we have a link width change sequence somewhere?
10:26 karolherbst: G96+MCP79_340.76-5_reclocking.mmio.xz
10:26 karolherbst: a lot of them there
10:26 imirkin: yay! that's pmoreau's setup
10:26 imirkin: is that the G96 or the MCP79?
10:27 karolherbst: I will look into this today, I have to be in the train for some hours
10:27 karolherbst: nv96/x@x/G96+MCP79_340.76-5_reclocking.mmio.xz
10:27 karolherbst: don't know which card it is exactly
10:27 imirkin: ok, so the G96 :)
10:27 imirkin: it's the macbook
10:28 imirkin: which has an nvidia igp and discrete gpu
10:28 karolherbst: :D
10:28 karolherbst: I will check that out
10:28 karolherbst: the timestamps are close enough so that there can't be much going on
10:29 karolherbst: could be that I won't be in IRC until the day after tomorrow though
10:29 imirkin: k
10:29 karolherbst: found another one
10:29 karolherbst: nv94/@/nv96-0x96980c1-0653-downclock.xz
10:29 imirkin: well if you have internet, there are logs available online
10:30 karolherbst: I have the repository local :)
10:30 karolherbst: or what kind of logs do you mean?
10:31 karolherbst: won't be able to try it out though :/
10:31 karolherbst: mhh
10:31 karolherbst: need a kepler trace with stuff like that
10:31 karolherbst: maybe not
10:31 imirkin: btw, have a look at r600_pcie_gen2_enable for how radeon does the pcie gen change
10:32 imirkin: that file should also have link width changes in there as well
10:32 imirkin: i.e. what the various things to check are, etc
10:32 karolherbst: yeah, will do when writing the kernel stuff
10:32 karolherbst: mwks logs are damn big :/
10:33 imirkin: well, even when trying to understand the various parameters
10:35 karolherbst: will that help that much?
10:35 imirkin: dunno. but interesting to see.
10:35 karolherbst: won't be able to do anything on the fermi card for the next month anyway
10:38 karolherbst: do you think width change may save power? or are there cards with a lower width than possible?
10:39 imirkin: link width change should save power
10:39 imirkin: question is how much
10:40 karolherbst: I see
10:41 karolherbst: mhh
10:41 karolherbst: looks pretty trivial
10:41 karolherbst: imirkin:
10:41 karolherbst: https://gist.github.com/karolherbst/e07b37344cd96a5332a2
10:41 karolherbst: there is nothing else in between
10:42 karolherbst: 0x088150 or 0x088140 ?
10:42 imirkin: so... 88150 probably
10:42 karolherbst: will find a place where it is changed back
10:43 karolherbst: added: https://gist.github.com/karolherbst/e07b37344cd96a5332a2
10:43 karolherbst: ...
10:43 karolherbst: no
10:44 karolherbst: ....
10:44 karolherbst: gist is messing up
10:45 karolherbst: https://gist.github.com/karolherbst/1bbbce4c890bc0d9e1fa
10:45 karolherbst: its 0x088140
10:46 karolherbst: 0x8001100 is width = 1
10:46 karolherbst: 0x8010100 is width = 16
10:46 imirkin: ah yeah, it's 140
10:46 imirkin: so... 12:17 is the link width
10:46 karolherbst: 0x8008100 = 8?
10:46 karolherbst: 0x8004100 = 4?
10:46 karolherbst: 0x8002100 = 2?
10:47 imirkin: i suspect the low bit is a commit bit
10:47 karolherbst: will try on fermi
10:48 karolherbst: yeah, its on fermi
10:48 imirkin: on my GT215: 00088140: 08010010
10:49 karolherbst: yeah
10:49 karolherbst: its a little bit different
10:49 imirkin: LnkSta: Speed 5GT/s, Width x8
10:49 imirkin: w00t
10:49 imirkin: wrote 08008010 followed by 08008011
10:50 karolherbst: :D
10:50 karolherbst: mhhh
10:50 karolherbst: doesn't work here
10:50 karolherbst: peek gives ... now
10:51 imirkin: on fermi?
10:51 karolherbst: I pokde the 8 away
10:51 karolherbst: :D
10:51 imirkin: oh. don't do that.
10:51 karolherbst: width 1x :)
10:52 karolherbst: rmmod makes trouble now though
10:52 imirkin: yeah, don't 0 out these things
10:52 imirkin: you can do nvascan on most things, but pci regs is a bit tricky
10:52 karolherbst: I mean after setting to 1x
10:54 karolherbst: okay, seems to work then
10:55 karolherbst: still could change to 2x and stuff
10:55 karolherbst: but then the gpu blocked
11:01 karolherbst: imirkin: any idea for kepler?
11:03 karolherbst: wtf...
11:03 karolherbst: wait
11:04 karolherbst: ahh no
11:04 karolherbst: I though I had a width change as well
11:11 mogorva: FEAR2 under wine (bug #91187) still crashes on a 64-bit kernel, now task manager shows that fear2.exe uses 4.0 GB VSZ and 1.6 GB RSS when it crashes
11:17 mogorva: when using nvidia binary drivers memory consumption was 2.1GB VSZ and 1.0 GB RSS
11:19 imirkin_: mogorva: yeah... that makes sense given what you saw with a 32-bit kernel
11:19 imirkin_: it runs out of address space and moves on :)
11:19 imirkin_: question is why it runs out of address space...
11:37 mogorva: is it normal that my kernel build tree takes up 6.2GB disk space after compiling a 64-bit kernel? I don't remember if my previous 32-bit build took up so much.
11:38 imirkin_: seems a bit large
11:38 imirkin_: perhaps you did allmodconfig?
11:39 mogorva: i left out lots of stuff that i don't need
11:39 mogorva: first i did make oldconfig then make menuconfig
11:39 imirkin_: also perhaps before you weren't counting the git tree size
11:39 imirkin_: which is all in .git
11:39 imirkin_: and weighs in a 2 or 3G iirc
11:39 imirkin_: er hm. 1.3GB.
11:40 imirkin_: my fully-built tree which includes the git history takes up 2.3GB total
11:40 imirkin_: so either you enable a TON more stuff, or... i dunno
11:40 imirkin_: perhaps you have some option that explodes debug info or something
11:40 imirkin_: like stack protector :) and its other friends
11:42 mogorva: i have config_64bit=y config_x86_64=y and config_x86=y set
11:42 imirkin_: sounds right
11:43 imirkin_: this is my .config: http://0bin.net/paste/im2JBkC3Cs+hFJr4#RAbcloNjv-UJvzkhdsJcMoRXihFBWebPWLVbwv/zmd7
11:43 mogorva: is it 'make mrproper' that should be issued before compiling the kernel?
11:43 imirkin_: uhhh... if you want the compile to take 100 years, yeah
11:44 imirkin_: just run 'make'. that always works. except maybe if you change arch's
11:45 mogorva: I copied an existing .config from a 32-bit kernel, issued 'make ARCH=x86_64 CROSS_COMPILE=/usr/bin/x86_64-linux-gnu- oldconfig' then 'make ARCH=x86_64 CROSS_COMPILE=/usr/bin/x86_64-linux-gnu- menuconfig'
11:45 imirkin_: that should be fine
11:46 imirkin_: you can diff my config with yours and see how much more junk you have enabled :)
11:46 imirkin_: [i'm generally good about trimming out useless junk, but i do miss things too...]
11:46 hakzsam: imirkin_, can you explain why karol defines bit 0 as COMMIT while the bitfield is f7fb1ffc ?
11:47 imirkin_: hakzsam: how is the "bitfield" generated?
11:47 imirkin_: magic?
11:47 hakzsam: nvascan
11:47 imirkin_: and what does nvascan do
11:47 hakzsam: it checks if bits can be set or not
11:47 imirkin_: and how does it do that
11:47 hakzsam: write 0xffffffff to that reg I guess
11:48 imirkin_: and then
11:49 hakzsam: and then it reads the reg to see what bits have changed
11:50 imirkin_: right
11:50 imirkin_: so... do i need to explain further, or do you see what's going on?
11:52 hakzsam: it's okay :)
11:52 imirkin_: i don't mind explaining, but don't want to do it if you already get it
11:53 hakzsam: my understanding is that allowed values are from 0x0 to 0xc
11:53 imirkin_: heh
11:53 imirkin_: ok, so forget about this reg
11:53 imirkin_: let's look at an INTR reg, which we understand fairly well
11:53 imirkin_: basically various bits in an INTR reg will be set, and you write them back out to clear them
11:53 imirkin_: what will happen if you use nvascan on an INTR reg?
11:54 hakzsam: it will launch all interrupts since we write 0xffffffff
11:54 imirkin_: launch?
11:54 imirkin_: it will clear the whole register
11:54 imirkin_: and when read back out, it'll read 0
11:54 imirkin_: so nvascan will decide that the bitmask is 0
11:55 imirkin_: basically nvascan works fine for registers that just store various values
11:55 imirkin_: and are readable/writable
11:55 imirkin_: but it can't work for bits which perform actions
11:55 imirkin_: in the case of this reg, the bottom 2 bits clearly trigger some sort of action when written
11:55 hakzsam: I see
11:55 imirkin_: but are 0 when read back out
11:55 imirkin_: because... they have no meaning
11:55 imirkin_: this isn't just memory
11:56 imirkin_: a mmio write isn't the same as writing value X to memory location Y
11:56 imirkin_: it's more akin to a function call
11:56 imirkin_: which in *many* cases ends up just storing the value somewhere
11:56 imirkin_: but hardly always
11:57 hakzsam: I understand
11:58 hakzsam: I only used nvascan to find out muxs, so it was just perfect because muxs store values
11:59 hakzsam: I didn't know about those "action bits"
11:59 imirkin_: yeah. it's really convenient for the situations where values are just stored
11:59 imirkin_: but just coz they're not, doesn't mean that you can't write bits there
11:59 hakzsam: sure
11:59 imirkin_: alternatively there can just be read-only values
11:59 hakzsam: I was wrong :)
11:59 imirkin_: e.g. that system bus link speed thing...
12:00 hakzsam: yeah
12:00 imirkin_: it is what it is reported by the system, no amount of writing will change it
12:00 hakzsam: okay
12:01 hakzsam: so, that patch looks perfect to me right now ;)
12:02 imirkin_: go ahead and merge it
12:02 hakzsam: okay, and after I'll have a look at the cb dirty logic
12:03 imirkin_: i assume you saw my note
12:03 mogorva: imirkin_, next time I compile a kernel i will take your .config into account
12:03 hakzsam: imirkin_, yes
12:03 imirkin_: mogorva: note that it only selects my machine's hw, so you'll probably have to enable some things like nic/wifi/etc
12:04 mogorva: for example 'CONFIG_KALLSYMS_ALL' is enabled for me but disabled on your machine, isn't that required to get proper backtraces? http://cateee.net/lkddb/web-lkddb/KALLSYMS_ALL.html
12:04 imirkin_: dunno... i have a /proc/kallsyms
12:05 imirkin_: kallsyms_all seems to be for kgdb & co
12:31 imirkin_: mogorva: btw, my config might not boot with systemd, dunno. systemd needs all kinds of crazy things that no normal system should worry about.
12:45 mogorva: could i install the 32-bit Nvidia binary package on my hybrid (64-bit kernel/32-bit userspace) distro without problems?
12:46 imirkin_: you need a 64-bit kernel module
12:46 mogorva: so i need the x86_64 package, right?
12:48 imirkin_: i assume so... not sure how they package things
12:54 Karlton: isn't that just basically a multi-library system?
12:56 imirkin_: not really... only 32-bit userspace
12:57 Karlton: it's possible to compile a kernel using only 32-bit toolchain?
12:58 Karlton: err a 64-bit kernel I mean
12:59 imirkin_: with a cross-compiler
12:59 imirkin_: much as it's possible to compile an arm kernel on x86
12:59 mogorva: yes, i installed gcc-x86_64 and binutils-x86_64
13:00 Karlton: and probably 64-bit version of glibc
13:00 mogorva: uh no, i have only 32-bit glibc
13:00 imirkin_: no need for 64-bit glibc
13:01 imirkin_: you'd need it to execute 64-bit binaries (that wanted glibc) but you have no such interest
13:06 mogorva: now have to find a way to tell the linux steam client to start the 32-bit version of a game when both .x86 and .x86_64 exist
14:08 mlankhorst: setarch i686 O:-)
14:59 imirkin_: xexaxo: 'configure: remove unneeded AC_SUBST statements' -- what software package is that for?
15:00 xexaxo: imirkin: pardon I should have made it explicit - xf86-video-nouveau
15:01 xexaxo: I'll be sending similar ones to the other three ddxen in a bit :)
15:02 imirkin_: ah, i'll just wait for them to review then ;)
15:08 xexaxo: why ?
15:09 imirkin_: because i'm lazy
15:09 imirkin_: and if they ok it then it must be good :)
15:09 xexaxo: how would that make it any easier/faster ?
15:09 imirkin_: whereas this way i have to go and double-check your claim
15:09 xexaxo: that's not really the definition of lazy, is it ?
15:10 imirkin_: since i don't know this stuff off-hand
15:10 xexaxo: https://autotools.io/pkgconfig/pkg_check_modules.html
15:10 xexaxo: neither did I. stumbled upon it a few weeks ago.
15:11 xexaxo: plus xf86-video-ati seems to be OK on this regard.
15:12 xexaxo: has some overlinking but that's another story :)
15:12 imirkin_: ooh fancy
15:13 imirkin_: xexaxo: AC_SUBST(LIBDRM_NOUVEAU_CFLAGS) -- should that have been AC_SUBST([LIBDRM_NOUVEAU_CFLAGS]) ?
15:13 imirkin_: and/or did it do something else without the [] ?
15:13 imirkin_:is weak on m4
15:14 xexaxo: imirkin: the "quotes" are not required in this particular case.
15:14 xexaxo: iirc one should use them with stuff like () @ and alike
15:17 xexaxo: never fails to crack you up - AM_CFLAGS = ... -DTRUE=1 -DFALSE=0
15:18 imirkin_: where?
15:20 xexaxo: in the intel ddx.
15:23 karolherbst: imirkin_: did you killed your card? :D
15:23 karolherbst: or does it just work with the width?
15:24 xexaxo: imirkin: in case it calms your mind freedreno and nouveau seems to be the only offenders wrt AC_SUBST. both ati and intel are ok.
15:25 imirkin_: xexaxo: r-b already sent :p
15:26 imirkin_: karolherbst: my GT215 worked ok
15:26 imirkin_: karolherbst: i didn't test my GF108 or GK208
15:26 xexaxo: if you feel like pushing it in a few days that'll be swell.
15:26 imirkin_: i'm on the GK208 right now, but i think kepler does something else
15:26 imirkin_: xexaxo: push yourself
15:26 xexaxo: xf86-video-nouveau is off limits for me (no idea why)
15:26 imirkin_: or are you not in the nouveau group?
15:27 xexaxo: last time I've checked I was not "invited" to hang around the cool kids :(
15:27 imirkin_: more like the island of misfit mascots...
15:29 xexaxo: beauty is in the eyes of beholder, they say :)
15:35 imirkin_: karolherbst: looks like you have a typo in your pull request
15:35 imirkin_: karolherbst: UNK28 vs UNK31
15:38 karolherbst: imirkin_: thanks
15:38 karolherbst: I think I might found the parts how we can check for width on kepler, but I couldn't change it actually
15:39 karolherbst: didn't got into the death mode either
15:40 imirkin_: fyi, on my GK208, this is my 8cXXX space: http://hastebin.com/fihunoxaka.sm
15:40 imirkin_: note that it's width = 8
15:40 imirkin_: i believe that's the physical card width, so width = 16 wouldn't be possible
15:40 imirkin_: karolherbst: can you run the same command on your GK106?
15:40 imirkin_: (nvapeek 8c000 1000)
15:41 karolherbst: wait a bit
15:41 karolherbst: there are actually two sources
15:41 karolherbst: 0x08c040
15:41 karolherbst: 6th byte
15:41 karolherbst: this is only 4 on 8x width cards
15:42 imirkin_: you mean 6th nibble?
15:42 xexaxo: imirkin: seems like the composite thing landed.
15:42 imirkin_: xexaxo: aka i pushed it?
15:42 karolherbst: yeah
15:42 xexaxo: can you point me to some location where I can read more on the topic.
15:42 karolherbst: second I think it has something todo with PPCI_2+0x1c0
15:43 karolherbst: don't know exactly how though
15:43 imirkin_: xexaxo: sure 'git grep screen_x' in the xserver ;)
15:43 imirkin_: karolherbst: can you just paste the output of that command?
15:43 imirkin_: for your GK106
15:43 karolherbst: yeah
15:43 xexaxo: imirkin: how about the arguments "neither intel nor the ati ddx do this" and "it's not a build failure" :)
15:44 imirkin_: xexaxo: it was very much a build failure
15:44 karolherbst: imirkin_: https://gist.github.com/karolherbst/df09854bef1d5ae2e2c5
15:44 imirkin_: xexaxo: without composite defined, screen_x/y aren't in the structure
15:44 imirkin_: karolherbst: thanks
15:44 karolherbst: 0008c080 looks suspicion too
15:44 xexaxo: hmm what script was I using then ... /me checks again
15:44 imirkin_: interesting.
15:45 karolherbst: should I try 0008c080?
15:45 imirkin_: so on 8c040 you have 8008 while i have 4040
15:45 imirkin_: yeah, 8c080 is probably the right one
15:45 imirkin_: one of them is probably the target width and one is the actual width
15:45 karolherbst: :/
15:45 karolherbst: ro
15:45 imirkin_: we'll see about that!
15:48 xexaxo: silly typo ... --disable-compoite. /me runs away in shame
15:48 imirkin_: hehe
15:48 imirkin_: karolherbst: ok fine. that one's RO :(
15:48 karolherbst: imirkin_: I think we need a trace where the blob does change the width :/
15:48 karolherbst: imirkin_: will you add the rnndb stuff for the width on fermi/tesla
15:48 karolherbst: ?
15:49 karolherbst: I have a long flight tomorrow and I still want to flash my phone I got today :D
15:50 imirkin_: karolherbst: mmmm... probably
15:51 karolherbst: you player around with it and I wasn't here ;)
15:59 imirkin_: gnurou: neither GK20A nor GM20B hang off a pci bus, right?
16:04 xexaxo: imirkin: so what's the verdict is dri3 staying or going ?
16:05 imirkin_: xexaxo: i dunno
16:05 skeggsb: imirkin_: no, they don't
16:06 xexaxo: I'll send the cleanup over in that case.
16:06 imirkin_: skeggsb: you're alive!
16:06 skeggsb: yeah, i've been heads-down finishing some stuff, so not so chatty :P
16:06 karolherbst: hi skeggsb
16:07 imirkin_: ok, well since you lifted your head up...
16:07 imirkin_: karolherbst and a few others have been lookign at pcie link settings
16:07 skeggsb: i've been following, somewhat :P
16:07 imirkin_: should we just add a pci subdev in nouveau with various api's for changing the settings?
16:08 skeggsb: i've already got a pci subdev in the code i'll push on, hopefully, friday
16:08 skeggsb: but yes, that'd be a good place for it
16:08 mupuf: skeggsb: nice
16:08 karolherbst: nice
16:08 imirkin_: ok cool
16:08 karolherbst: so shall I continue on the work then or should anybody else do it?
16:08 imirkin_: i think we're still focusing on the RE bits, but a bunch of it is moderately understood
16:08 mupuf: skeggsb: what do you need it for?
16:09 skeggsb: mupuf: i've been doing a massive cleanup/type-safety rework of the kernel driver, the pci subdev came as part of the cleanup
16:09 mupuf: ah, the long-waited for cleanup!
16:10 mupuf: I guess it is a good time, waiting for nvidia to drop the firmwares!
16:11 karolherbst: imirkin_: you should grep agains PPCI demmio output
16:11 karolherbst: :D
16:11 karolherbst: before and after the new stuff
16:11 karolherbst: especially on kepler a lot of unknown stuff is good now
16:11 skeggsb: mupuf: long awaited because i gave up my earlier attempts at it for ages :P
16:12 skeggsb: it was tricky to do in bisectable pieces, but, i managed it finally
16:13 imirkin_: skeggsb: easy -- just make one big piece and everyone's happy
16:13 imirkin_: heh
16:13 imirkin_: except the people that land on that commit during a bisect
16:14 mupuf: imirkin_: right, which is likely to be ... skeggsb :D
16:14 imirkin_: no, likely to be end users for whom nouveau stops working
16:15 imirkin_: i remember a *ton* of them landed on some 3.8 mega-commit
16:18 karolherbst: stupid phone :/
16:19 karolherbst: formating takes forever, this is just insane
16:20 imirkin_: next time, get one with less storage
16:22 karolherbst: ...
16:22 karolherbst: its not even doing anything now
16:22 karolherbst: stupid recovery mode
16:24 karolherbst: ahhh
16:54 karolherbst: skeggsb: will there be anything implemented in the pci subdev? or is it more or less empty and does only print some information?
17:20 skeggsb: karolherbst: it doesn't implement the stuff you've been working on, you can do that :P
17:21 karolherbst: okay, I was just curious though
17:21 karolherbst: I think I will still start with the PCIe v1 => v2 transition, just to check out how I have to do stuff
20:23 boxfire_: I'm having trouble with an external display turning off and not being able to turn back on
20:23 boxfire_: on a optimus setup, the screen is attached via display port to the nouveau provider card (quattro 2000M)
20:24 boxfire_: if the screen turns off via DPMS it wont come back unless I restart X
20:25 boxfire_: a workaround of disabling DPMS is not really acceptable, I do indeed want it to be able to turn off after idle time, but I use that as a workaround at the moment
20:42 jushur: boxfire_: got the firmware blobs loaded?
20:50 boxfire_: jushur: there are no firmware blobs for this card I thought?
20:51 boxfire_: jushur: I do not have firmware, just naked nouveau