00:43PyroSamurai: pmoreau: thanks, I'll have a look at it.
17:22tobijk: hey there airlied, skeggsb, imirkin: its merge window again, and as it is getting somewhat good paractice, i have a kernel null pointer dereference: https://hastebin.com/fihokakoqa.pas
17:23tobijk: somebody already noticed this? or do i have to bisect? :>
17:23imirkin: i think someone complained about that semi-recently
17:23tobijk: card is nv136, but should not be important
17:23imirkin: but without any additional info
17:24tobijk: imirkin: semi-recent?
17:24imirkin: past 2 weeks
17:24imirkin: i have a hard time telling time :)
17:24tobijk: with drm-next then?
17:24imirkin: no clue
17:24tobijk: this stated with the 4.14 pull request
17:25imirkin: maybe it was karol. i really don't remember.
17:25tobijk: i take this as a do a bisect then, thx
17:25imirkin: yep ;)
17:25imirkin: esp if you can repro
17:26tobijk: yep, unplug screen and boot :D
18:15karolherbst_: could have been me
18:15karolherbst_: imirkin: I also got an error about VGA-1 connector being leaked in drm, might be related
19:22karolherbst: we are in 2017 and we still need to specify those mtrr values? meh
19:23karolherbst: I thought we had PAT, but dmesg still asks me to
19:25karolherbst: "please specify mtrr_gran_size/mtrr_chunk_size"
19:26tobijk: never seen that :O
19:47karolherbst: tobijk: well I didn't see it before as well, but I upgraded my RAM today
19:48tobijk: still makes no sense to me
19:48tobijk: gotta reboot: next bisect iteration, will be back
20:31karolherbst: yay, somebody interested in an EVOC project
20:33RSpliet: Ah, what topic?
20:34karolherbst: maxwell video accell
20:34tobijk: :o not an easy one
20:35karolherbst: ahh, a german student
20:35karolherbst: but foreign last name
20:35RSpliet: Well, that narrows down the number of mentors ;-)
20:36tobijk: were is the entry btw
20:36karolherbst: and started the email with "mr. herbst" :(
20:36karolherbst: tobijk: https://www.x.org/wiki/SummerOfCodeIdeas/
20:36tobijk: well its getting "herbst" ;-)
20:37karolherbst: RSpliet: well, mupuf was sneaky and wrote "Power Management in Nouveau" in the potential mentors list :D
20:42karolherbst: sadly he lives like 800km away from me, so I can't just go to him and "motivate" him when starting to get lazy
20:43RSpliet: Are you sure he isn't Dutch?
20:43tobijk: so, bw?
20:43tobijk: oder by :D
20:43karolherbst: tobijk: the other south
20:44karolherbst: RSpliet: quite so
21:08tobijk: meh, double error for me, hope i'm guessing my bisect right :/
22:10karolherbst: any idea on how to make an EVoC project work if the student has no Nvidia GPU? I would say there is no way, but maybe somebody of you knows something
22:15mwk: well, there is ssh...
22:15mwk: but definitely not a pretty situation
22:15karolherbst: especially not for video accell
22:16mwk: well, could be worse, like working on display stuff remotely :p
22:18imirkin: having one local is pretty key... having a second dev box is even better
22:24hanetzer: hey folks. Does anyone have an example envytools session I could use as a guideline for tracing another gpu thingus?
22:24hanetzer: its an arm soc peripheral, lacks hardware docs, has blob kernel driver.
22:28RSpliet: hanetzer: envytools isn't going to help you the tiniest bit with Mali...
22:29karolherbst: RSpliet: why not? the etnaviv guys also use envytools
22:32RSpliet: karolherbst: and so does freedreno... for documenting stuff. There's nothing in envytools that will trace an ARM periph. I'm not even sure if mmiotrace works on ARM if you want to write the docs yourself and use demmio, but I guess hanetzer should first be a lot clearer about his intentions.
22:32karolherbst: yeah sure
22:32RSpliet: as for the EVoC project dude: he could request a modest budget for acquiring a Maxwell GPU as part of the EVoC application.
22:32karolherbst: but at least those nva tools might be helpful, like nvapeek and such
22:32karolherbst: RSpliet: those are 100€+
22:33karolherbst: maybe not if used
22:33RSpliet: Nothing wrong with a used one
22:33RSpliet: They never did make something low-end, did they?
22:34RSpliet: Anyway, there's GTX 750s on ebay for 60 quid, should be acceptable
22:35karolherbst: should be
22:36RSpliet: I had something like that being made available for me to do GT21x reclocking EVoC
22:37hanetzer: RSpliet: not mali. Something else. video hardware codec
22:37RSpliet: hanetzer: yeah I knew I jumped to conclusions somewhere ;-)
22:38hanetzer: unnamed, even in the 'good' vendor datasheet (all the boring stuff is fairly well documented, none of the av stuff is )
22:38hanetzer: and all the documented stuff is mostly boring old primecell parts (jellybean/bread and butter arm peripherals)
22:39RSpliet: hanetzer: classic. Anyway, I'm guessing the best person to talk to is robclark, he knows the deal with reverse engineering periphs on ARM
22:41RSpliet: ya. rly.
22:41imirkin: hanetzer: envytools is a collection of many tools
22:41hanetzer: yeah, so I gather. I just need to know how to use said tools in this sort of instance.
22:41imirkin: hanetzer: among other things, it includes a way to store register definitions, and access them programmatically as well as generate headers
22:42imirkin: this bit is used by freedreno as well as others
22:42imirkin: hanetzer: mmiotrace would be trickier to make work, and it definitely wouldn't work "out of the box", but i'm also not sure that there are any kernel blob issues on arm -- dunno.
22:43imirkin: hanetzer: you can look at libwrap which robclark wrote to trace adreno stuff - basically intercepts the various cmd submit ioctl's
22:43hanetzer: imirkin: well, they're not blobs per se. they are structured kernel modules and some userspace libs
22:43imirkin: right - the issue with nvidia is that the kernel module is a blob
22:44imirkin: so in order to trace what it does, we have to resort to shady shit (aka mmiotrace)
22:44hanetzer: imirkin: like a literal *.bin with some objdump magick applied to it?
22:44imirkin: [which dicks around with page tables to intercept accesses]
22:44hanetzer: erm, objcopy*
22:44imirkin: well, *.o, but yeah
22:44hanetzer: ugly af.
22:44imirkin: there's a small shim to interface
22:45imirkin: but majority of it is closed, and since you can do mmio directly from the code, it does.
22:45karolherbst: imirkin: mmiotrace isn't shady :O
22:45imirkin: karolherbst: using the in-kernel instruction parser isn't shady? :)
22:45karolherbst: there is a in-kernel instruction emulator?
22:46imirkin: karolherbst: how do you think mmiotrace works?
22:46imirkin: when an op hits a memory location
22:46imirkin: it goes and fetches the thing
22:46imirkin: but then it needs to do the thing that the op was going ot do
22:46karolherbst: I mean, I know, but there is no "kernel-wide" instruction emulator afaik
22:46imirkin: not originally, but iirc it hooks into some kvm stuff which exists for similar purposes
22:47karolherbst: I don't think so
22:47imirkin: hanetzer: for tracing userspace, we use valgrind-mmt which is tuned to dealing with the kernel. it's kind of like libwrap, but ... probably more complete (and valgrind-based)
22:48imirkin: hanetzer: what GPU are you targeting?
22:48hanetzer: I usually idle a lot, but at the moment I'm away from home (my amd ryzen build) due to harvey damages and relocation.
22:49hanetzer: imirkin: I'm not sure I'd call it a gpu. Its a periph inside the hisilicon hi3521a and related chipsets, does av enc/dec and some other stuff.
22:49RSpliet: imirkin: I thought that was all just done using pagefault handler?... like it's a regular pae-fault only you can't actually swap out MMIO mem so you fiddle with PTs to pretend it is. Presumably the interrupt holds the required info to handle the pagefault, no need to emulate insns?
22:49imirkin: those tend to be ... quite painful to deal with.
22:49imirkin: RSpliet: yes, and what does the page fault handler do?
22:50hanetzer: They never name it (other than VEDU [video something] or TDE [two dimensional engine]) in any of the docs I can find.
22:50imirkin: let's say the op is add ax, [mem]
22:50imirkin: and mem hits the page fault handler. now what?
22:54RSpliet: imirkin: arch-specific? I'll trust your factual knowledge on the x86 arch, but principally: If the arch has a pagefault status register that tells you (address, read/write, (physical?) src/dst reg) there's little need to interpret the entire instruction. Can work fine if it's either RISC or operating on the micro-op level... in theory
22:55imirkin: well - the thing is that you handle the page fault
22:55imirkin: after which you have to return to the code that faulted
22:55karolherbst: imirkin: so as I thought, there is no kvm thing used and mmiotrace doesn't do emultion, but single stepping. And the instruction parser is here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/mm/mmio-mod.c?h=v4.13#n143
22:55imirkin: a normal page fault handler makes the page appear, in which case great -- just run the instruction again
22:56imirkin: however here you're not making the page appear. so you have to emulate the instruction and resume at the next instruction.
22:56karolherbst: it uses get_ins_type though
22:57karolherbst: imirkin: hum, yes, mmiotrace does exactly this
22:57karolherbst: it makes the page to be there again
22:57karolherbst: and doesn't emulate
22:57imirkin: oh really? then it's changed since i last looked (a very very long time ago)
22:57karolherbst: it always did this afaik
22:57karolherbst: but my always is like from 2015
22:58imirkin: well, i remember when pq was trying to work it out originally in like ... 2007?
22:58karolherbst: well, the idea to use emulation was always thre
22:58karolherbst: because it makes things easier
22:58karolherbst: like handling repeat instructions
22:58karolherbst: currently, mmiotrace can't handle repeat
22:58RSpliet: imirkin: I guess the pagefault interrupt mechanism wasn't designed for the mmiotrace use-case. Sounds easier for HW to operate on the macro-op (just rely on the pc, you're going to lose your pipeline contents anyway on an interrupt)
22:58hanetzer: this seems pretty useful, valgrind-mmt
22:58imirkin: hanetzer: have a look at libwrap in freedreno/freedreno
22:58imirkin: also useful.
22:59hanetzer: am, its a LD_PRELOAD hack, right?
22:59karolherbst: and we hit repeate on nvidia
23:01hanetzer: so what I'm gathering is one would use this valgrind fork/whatever to run some application that uses the 'normal' vendor-provided userspace/whatevs and trace what it does with it.
23:06hanetzer: the fuck is this 'freedreno-zz/amd-gpu' 'goldmine' repo XD
23:11hanetzer: do any of you folks happen to know of an ioctl decoder util one can use? I see a fair amount of them in the disassembly and was wondering if there was a a 'cleanish' way one could take the 32bits and spit out a #define or at least most of one?
23:33imirkin: hanetzer: well, valgrind-mmt spits out files that are decoded by the 'demmt' tool -- both of those are pretty nvidia-specific. for freedreno there's libwrap which generates .rd files parsed by cffdump
23:33imirkin: in both cases, a lot of the specific info is supplied by the rnndb files
23:39hanetzer: what a pain :P
23:41imirkin: no magic available to just do everything you need, sadly
23:41imirkin: some assembly required
23:49hanetzer: why can't vendors stop being cunts :<