02:06 pmoreau: Does someone know what PFIFO interrupt 0x04000000 refers to? (dmesg: https://phabricator.pmoreau.org/P2) It occurs while starting X, the MCP79 is the main card.
03:01 skeggsb_: pmoreau: it generally happens at the same time as the flush timeout, so i'd hazard a guess and say there's an interrupt for that :P
03:01 skeggsb_: basically "something went horribly, *horribly* wrong"
03:02 skeggsb_: i don't suppose you have a trace of the binary driver on that gpu?
03:04 pmoreau: skeggsb_: I do have some, but I don't have my laptop (and the traces) at hand.
03:05 skeggsb_: did you upload it to gmail at all? i can look there
03:05 pmoreau: I did upload one at gmail, for an issue where connecting an external screen
03:06 pmoreau: It should have everything
03:06 skeggsb_: i see it
03:06 pmoreau: It seems like Nouveau or drm is wanting to set some things on the G96 when starting X, even if it doesn't drive the screen.
03:07 pmoreau: I hacked Nouveau so the G96 will auto-suspend, and when starting X afterwards, the card would wake up for some reason
03:07 pmoreau: Is it a desirable behaviour?
03:12 skeggsb_: i'm guessing X is probing it for displays or something
03:16 pmoreau: Maybe
05:00 pmoreau: ddddddwdwqd////////quitddddddddddddddsss
05:02 pmoreau: Sorry, network was done...
05:02 pmoreau: So I was typing blindly and nothing was happening
07:51 Eliasvan: pmoreau: hi, I might be able to do some reclocking dumps on GT 555M and GT 740M from friends of mine, but first I need to know whether my reclocking procedure is good enough, and maybe also whether I should include extra tests such as fan control, etc.
07:51 Eliasvan: Here are the tracing steps of my last dump (on the GTX 760): http://pastebin.com/i9GcEh7s
08:04 pmoreau: Eliasvan: Hi! For reclocking dumping procedures, you should rather ask RSpliet. :-)
08:04 Eliasvan: I've also given "demmio" a brief try on the resulting dump (https://filetea.me/t1skRiFCE08SBK8PHWp32GYlw), but I can't really differentiate between the reclocking part and the idle part (both include the PTHERM and PCLOCK commands)
08:04 Eliasvan: pmoreau: ah, ok
08:05 pmoreau: I need to learn that from him too ;)
08:07 Eliasvan: RSpliet: Hi RSpliet, can you please provide some feedback on the way how I performed my reclocking dumps?
08:08 Eliasvan: RSpliet: The dump I attached here is also visible in the mmio.dumps mailbox with title: "[NVE4-GTX760]: reclocking trace"
09:26 Eliasvan: mupuf: Hi mupuf, I've got a question regarding "fan control", is setting the fan speed possible on all GPUs (let's say, starting from NVC0+) using nouveau?
09:30 RSpliet: Eliasvan: sorry, my mind is currently at completely different matters
09:30 Eliasvan: RSpliet: no problem ;)
09:30 RSpliet: (if anywhere that is, I'm a little tired too :p)
09:30 Eliasvan: RSpliet: It isn't urgent
09:31 RSpliet: well, I understand your pain; reclocking is the biggest perf bottleneck atm, and I'd *love* to do something about it
09:31 RSpliet: but the current situation doesn't allow me to
09:31 Eliasvan: RSpliet: it's just because it would spare me to redo some dumps on the laptops of my friends ;)
09:32 RSpliet: yes I understand
09:33 Eliasvan: mupuf: In case it is not yet possible, are mmio dumps welcome, or are vbios dumps more prefered?
09:33 RSpliet: regarding fan control, I recall mupuf saying there's trouble with one of the fan controllers, but most should work fine
09:33 Eliasvan: ah, ok, thanks :)
09:33 RSpliet: also, not sure how that goes nowadays, but back in the old days the laptop GPU didn't have a controllable fan
09:34 RSpliet: in many laptops it used to all be tied to one big lumpy heatsink
09:34 RSpliet: with a little fan inside for airflow
09:34 Eliasvan: ah, I couldn't check, because I couldn't access the "Coolbits" option on an Optimus laptop
09:34 RSpliet: and "someone else" was responsible for controlling that little fanny thing
09:35 Eliasvan: yeah, cool, in that case it would spare me some tests ;)
09:36 Eliasvan: I'll just attach the vbios, that will be sufficient I suppose
09:36 Eliasvan: And if I have to redo the dumps, it's not the end of the world ;)
09:37 RSpliet: that's the spirit!
09:37 Eliasvan: :)
09:37 Eliasvan: ok, thanks for your time! bye
10:44 tobijk: hey could somebody look at http://lists.freedesktop.org/archives/mesa-dev/2015-January/074474.html and possibly push it to mesa/master? would ease the work with OBS :)
14:58 buhman: erm, aren't failed assertions supposed to halt the program's execution?
14:58 buhman: the returns should have no effect
14:59 prg: release build might remove the assert
15:07 tobijk: they are, at least in the gallium part of mesa
15:07 tobijk: ...removed...
15:14 pmoreau: Bug reports tend to multiply too quickly these days regarding the number of bugs being solved... :/
15:16 tobijk: well if bug reports keep multiplying, it just mean that folks are actually using nouveau :-)
15:18 pmoreau: Right, but it's not like we have enough time to handle some more bug reports given that some already sitting idle for a few weeks/months
15:19 pmoreau: *are
15:19 tobijk: yeah :/
15:20 tobijk: btw: where is our dungeon-keeper? :D
15:20 pmoreau: :D
15:22 pmoreau: There are probably a few dozens that could be closed as users didn't provide required infos
15:24 tobijk: mh that feels wrong to be, but it might help to get a better picture
15:33 tobijk: actually digging through this would be helpful :O
15:40 pmoreau: :)
15:40 pmoreau: I'll join the party
15:45 pmoreau: Would it make sense to use the whiteboard or keywords fields to store the chipsets, regression/bisection status rather than having everything in the subject?
15:46 tobijk: maybe, i'm not really trained in using bugzilla
15:47 pmoreau: Me neither, just seeing that there are some fields we are not using.
15:48 pmoreau: The inconvenient of not putting it in the subject is that devs have to change the default column display to get keywords or whiteboard and see the chipsets.
15:49 tobijk: mh yeah that is something i'd really dislike to do actually
15:50 pmoreau: :p
15:59 tobijk: pmoreau: you got a MCP77/MCP78 chip?
16:01 pmoreau: tobijk: Nah, only MCP79/7A
16:01 tobijk: close enough, can you run piglits MCP77/MCP78 and see if this creates some dmesg errors?
16:01 pmoreau: (well, "only" is probably wrong here)
16:02 tobijk: argh paste :D
16:02 tobijk: -> glsl-array-bounds-02
16:03 pmoreau: Ok, I'll do that sometime tomorrow
16:03 pmoreau: So only the glsl-array-bounds-02 test?
16:05 tobijk: https://bugs.freedesktop.org/show_bug.cgi?id=68348
16:05 tobijk: just look if that still occurs
16:05 tobijk: thanks :)
16:06 pmoreau: Sure :)
16:16 pmoreau: tobijk: If you deal with bug reports involving MCP77/78 or MCP79/7A, ask them to test with 3.19-rc4 at least
16:17 tobijk: were there some fixes for those chipsets?
16:18 pmoreau: Yes, enabling NISO poller
16:18 pmoreau: Without it my NVAC would just hang at init
16:19 skeggsb_: yours is an exception there though, the vbios appears to do it on most systems
16:19 tobijk: oh good to know, i think i have just messed with a nvac bugreport for this :o
16:20 pmoreau: skeggsb_: Other vbioses enables the bits, but allocating pages might not be done
16:20 pmoreau: But yeah, my laptop seems to be an exception... Think different I guess
16:21 skeggsb_: it's always been in the upper part of carveout in traces i've seen, which, nouveau already ignores
16:22 pmoreau: (Thinking of it, I need to push to envytools how to compute the address stored in 100c18 & co.)
16:23 pmoreau: skeggsb_: Any luck with the mmiotrace?
16:23 skeggsb_: i only had a quick look to see if the binary driver had to deal with that same interrupt and reset something
16:23 skeggsb_: but, no
16:25 pmoreau: Maybe they just reset by default? :D
16:25 skeggsb_: well yes, but i don't know *what* that thing might be
16:26 skeggsb_: nvidia touch a heap of stuff we don't :)
16:26 pmoreau: :)
16:27 pmoreau: https://bugs.freedesktop.org/show_bug.cgi?id=86539 <- Should we activate POST by default or try to reset 61c084 under some conditions?
16:28 skeggsb_: we shouldn't/can't do the former, the bios init tables do... unexpected.. things on a lot of boards if it's no run on a cold card
16:29 skeggsb_: again, that's probably actually our fault, but with limited knowledge....
16:31 pmoreau: I wonder wether it's just the switch mechanism under Mac OS which creates this situation or not.
16:32 pmoreau: I wasn't able to test under Linux as switching with vga_switcheroo wouldn't survive a reboot.
16:33 skeggsb_: you *could* try and find what makes the binary driver decide to run devinit, and not us
16:34 pmoreau: Will try now that I have more cards than just my laptop's ones :)
16:37 skeggsb_: well it's more your laptop's case i'm interested in, the binary driver generally doesn't run devinit unless it thinks it has to
16:39 pmoreau: But I might be able to compare what the blob is doing when it runs devinit and when it doesn't
16:40 skeggsb_: i wouldn't be entirely shocked if it was an "oh fuck this is a macbook" quirk :P
16:40 pmoreau: I know it runs devinit no matter what on my laptop, so need to have one card where it doesn't
16:40 pmoreau: :D
16:45 pmoreau: tobijk: Do piglit results from 01 January 2015 works? I forgot I did some testing for Ilia
16:46 tobijk: sure
16:48 pmoreau: glsl-array-bounds-{12,10} give me a dmesg-warn, otherwise the others pass
16:48 tobijk: mh might still be a subset of the bug
16:49 tobijk: sth. like this -> [ 4653.971680] nouveau E[ PGRAPH][0000:02:00.0] TRAP_MP - TP0: Unhandled ustatus 0x00000001 ?
16:49 pmoreau: Quite, "nouveau E[ PGRAPH][0000:03:00.0] TRAP_MP - TP0: LOCAL_LIMIT_READ"
16:51 pmoreau: And LOCAL_LIMIT_READ = 0x00000001, so yes, it is a subset :)
16:52 pmoreau: skeggsb_: Oh, I have a patch for your repo, just removing a couple of dead-links.
16:53 pmoreau: Just need to find it back and send it
16:55 skeggsb_: ah it's ok, i've got those handled already
16:55 skeggsb_: i'll push it monday
16:55 pmoreau: Ok
16:55 skeggsb_: the symlinks won't exist anymore at all
16:55 pmoreau: Nice :)
16:57 pmoreau: So everything will be in drm or did you organise it differently?
16:58 skeggsb_: i ditched autotools for custom makefiles for the library build, so i could reuse the Kbuild files (automake doesn't like the kernel's variable naming)
16:58 skeggsb_: so, lib/ builds its objects from drm/.. no more dual makefiles, no more symlinks
16:59 pmoreau: Cool!
17:37 tobijk: oh pmoreau: is your patch for the dmux dealing with that:
17:37 tobijk: [ 6.109489] ACPI Warning: \_SB_.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20141107/nsarguments-95)
17:37 tobijk: ?
17:40 pmoreau: tobijk: No, I just add support for another UUID and rev
17:40 pmoreau: This is a legitimate warning, as I discovered yesterday
17:41 pmoreau: ACPI specs says arg #4 of _DSM is a Package
17:41 tobijk: damn you bios :>
17:41 pmoreau: But it seems some implementations return a Buffer instead (my laptop too)
17:42 pmoreau: however, the function emitting the warning is just doing some type checking and does nothing else, not even returning an error code
17:43 pmoreau: So it has no influence on the parsing, as long as Nouveau precise it should wait for a buffer rather than a package, which it already does
17:43 tobijk: well you handle the 4th arg as buffer, maybe we need to do this for otimus as well
17:44 pmoreau: Optimus is already doing this
17:44 tobijk: oh slow me
17:44 pmoreau: I mostly copy/pasted the optimus code and change the UUID and rev numbers :)
17:44 pmoreau: s/change/changed
17:46 tobijk: fine
17:48 tobijk: and if it helps r-b for the "move conditional suspend messages into conditionals" :D
17:48 pmoreau: :D Thanks!
17:52 pmoreau: skeggsb_: I uploaded a new dmesg for interrupt 0x04000000, this time it has dump_stack in vm flush. Maybe it will shed some light on what's happening. https://phabricator.pmoreau.org/P3
18:36 pmoreau: It seems NOUVEAU_GEM_NEW and NOUVEAU_CHANNEL_ALLOC are the ones causing troubles on the G96.
18:36 pmoreau: I'll have a look at them tomorrow, need some sleep...
21:08 mupuf: Eliasvan: fan management should just work, even on maxwell
21:09 mupuf: if it does not work, then it may mean you have an external controller for the fan