01:37 BinBasher: Hi, getting this (EE) Failed to load module "nv" (module does not exist, 0) while trying Xorg -configure ; any tips?
01:40 RSpliet: BinBasher: yes: don't try to load "nv"
01:40 RSpliet: it's obsolete and worthless
01:40 BinBasher: RSpliet: where can I edit the file to not load it?
01:40 RSpliet: modern X.org doesn't need a configuration to work
01:41 BinBasher: RSpliet: well I can't seem to control by backlight at all :(
01:41 RSpliet: ah, well, X.org isn't going to make a difference with that
01:42 RSpliet: that's all ACPI handler stuff
01:42 BinBasher: okay, so now I have the problem I already did Xorg -configure ; and from experience I know now I can't boot into my gui anymore.. How do undo my Xorg -configure ?
01:43 RSpliet: remove /etc/X11/xorg.conf
01:43 BinBasher: that's all?
01:43 RSpliet: usually yes
01:43 BinBasher: I don't have /etc/X11/xorg.conf
01:44 RSpliet: is there something generated in /etc/X11/xorg.conf,d ?
01:44 BinBasher: yes
01:44 RSpliet: which files?
01:45 BinBasher: oh it seems to be in /usr/share/X11/xorg.conf.d
01:45 BinBasher: not /etc
01:46 BinBasher: in /usr/share/X11/xorg.conf.d there is 10-evdev.conf 50-synaptics.conf 50-wacom.conf
01:46 BinBasher: 10-quirks.conf 50-vmmouse.conf
01:46 BinBasher: will this cause a problem?
01:48 urjaman: no
01:50 urjaman: man xorg.conf and check the search locations it describes
01:51 urjaman: (and note that if you're trying to start x as root, there are more places it could check, notably home ofroot...)
01:55 Tom^: BinBasher: which gpu?
01:55 BinBasher: Tom^: nvidia geforce gtx 675M
02:01 BinBasher: urjaman: couldn't find anything called xorg.conf in the default places when the server is started as a normal user
02:09 BinBasher: I'm afraid to reboot seeing that I have to do a clean install again :(
03:03 wvvu: is it possible to flash the bios with linux?
03:04 wvvu: GPUTweak2 wow, such a thing on linux?
03:04 wvvu: can it be run under wine?
03:10 wvvu: is it worth it to update the card BIOS to UEFI?
03:21 grarap: I came here yesterday, I'm having a problem with nouveau not accepting my monitor's EDID (wrong checksum)
03:21 grarap: After running get-edid, my monitor works
03:21 grarap: Now I found out that nouveau seems to be crashing once I unplug my monitor (after having run get-edid)
03:22 grarap: At least a stacktrace is printed when the monitor is unplugged
03:22 grarap: And at the end of the stack trace, nouveau once again tells me an EDID is not valid, even though at that time, the monitor is disconnected and cannot have sent an EDID
03:23 wvvu: is that an ancient monitor?
03:23 wvvu: grarap: perhaps you can fix it with modelines
03:24 grarap: Stacktrace is here: http://pastebin.com/0jvbSx1N
03:25 grarap: wvvu: No, not really, it's an Eizo FS 2331
03:25 grarap: wvvu: Could you point me to documentation on what modelines are and how to use them to fix this?
03:27 grarap: The FS2331 was released in 2011, so I wouldn't call it ancient
03:27 wvvu: grarap: gugel 'xorg modelines' you'll be greeted with a trillion results.
03:27 BinBasher: does xorg.conf.new do anything in /root/?
03:28 wvvu: grarap: I said ancient because I recall EDID tweaking used to be for really old monitors and attrocious monitor/tv firmware.
03:28 BinBasher: or does it wait there to become xorg.conf?
03:28 wvvu: BinBasher: might be distro specific
03:28 wvvu: ask your distro
03:28 grarap: wvvu: Ok, I thought it was nouveau-specific (modelines)
03:29 grarap: wvvu: That's what I don't get. I'm pretty much 100% sure this monitor has worked with nouveau in the past
03:29 wvvu: gardar: which distro?
03:30 grarap: That's why I'd like to find a proper plug'n'play solution rather than tweaking config files until it somehow starts working
03:30 grarap: wvvu: Arch
03:30 wvvu: gardar: thinks that come in mind to fix it other than EDID: 1- kernel command parameters 2- nouveau module options 3- modelines
03:30 grarap: Especially since I'd like the external monitor to work even before Xorg starts
03:30 wvvu: grarap: if it has work in the past, then test with some other distros.
03:31 wvvu: arch might be using a problematic nouveau version.
03:31 grarap: wvvu: I need to enter a password for decrypting my HDD even before anything else starts so Xorg is a bit too late
03:31 wvvu: grarap: last week I had a horrible issue and it was fix with a -rX revision of the nouveau.
03:31 wvvu: grarap: try LiveCD's
03:32 wvvu: grarap: also, here say that nouveau driver in kernel 4.4 is really awsome. Double check your kernel version.
03:33 grarap: wvvu: Ok, I may try some other nouveau versions like the current trunk
03:33 grarap: Ok, right now I still have 4.3.3
03:35 grarap: wvvu: Thanks
03:36 wvvu: try this? nouveau.modeset=0
03:50 grarap: wvvu: Hm, I read nouveau needs KMS to be enabled
03:50 grarap: And your line would disable it, no?
03:51 grarap: I'll try kernel 4.4 first
04:18 imirkin: grarap: modelines are unrelated to your issues. modeset=0 turns off nouveau. pretty sure none of that advice was relevant.
04:19 imirkin: grarap: the kernel splats you saw should be fixed by https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0a882cadbc63fd2da3994af7115b4ada2fcbd638
04:21 imirkin: BinBasher: pastebin your xorg log
04:21 imirkin: it should say exactly what it's reading and from where
04:25 grarap: imirkin: Thanks
04:26 grarap: imirkin: What version of linux did those fixes go into? I don't see any information on that in the commit
04:26 grarap: But I don't really know where to look either
04:27 imirkin: grarap: for now, just 4.5-rc1, but it was tagged with 'stable', which means it should be making it into a 4.4.x release eventually
04:28 grarap: imirkin: Ok. But that won't fix my EDID problem, right?
04:28 imirkin: i don't think so
05:15 BinBasher: imirkin: http://pastebin.com/MNZqPBHj
05:16 imirkin: BinBasher: what's the problem again?
05:22 BinBasher: imirkin: I remember doing something with xorg and not being able to reboot into a gui again - there's this error and I'm wondering if this could cause it
05:22 imirkin: what error? that xorg log looks perfectly fine.
05:24 BinBasher: imirkin: (EE) Failed to load module "nv" (module does not exist, 0)
05:25 imirkin: not a problem
05:25 BinBasher: ah okay
05:25 imirkin: xf86-video-nv is a largely outdated ddx
05:26 BinBasher: let's see and reboot then.. ugh I have a bad feeling about this :P
05:35 wvvu: is possible to flas vbios via linux? or use nvflash.exe under wine?
05:36 wvvu: anyone tried it? If not can any one try and let me know how it goes?
05:36 BinBasher: able to reboot! thanks
06:08 wvvu: wow, some cards offer maximum hackability
06:09 wvvu: flash succesful, as always with community guides, asus official app truly efftup
06:26 wvvu: the ppsspp emulator is hard locking nouveau, the interesting thing is that it was after checking some new fangled graphics options in ppsspp emulator. Is there a way to find out what's tripping nouveau?
06:28 imirkin: "hard locking"?
06:44 wvvu: imirkin: yeah, the whole Xorg thingy
06:44 imirkin: does the mouse cursor still move?
06:44 wvvu: only way to recover is rebooting blindly
06:44 wvvu: nothing
06:44 imirkin: can you ssh in?
06:45 wvvu: theoretically yes because the power button performs a clean shutdown.
06:46 wvvu: ok well, hard locking Xorg, no everything. But the hardlock is somewhat hard core because kills the mouse too and the keyboard.
06:47 imirkin: can you practically ssh in and see what's in dmesg when it happens? or perhaps those logs make it to disk?
06:47 wvvu: well yes there's a hard lock.
06:49 wvvu: could be raising the internal resolution of the games.
06:49 wvvu: it was playing fine before I started touching options.
06:50 wvvu: lemme see them logs
06:54 wvvu: [mi] EQ overflowing
06:55 wvvu: and keeps ongoing, do you want the log?
06:55 wvvu: do you desire it?
06:55 imirkin: no
06:55 imirkin: that just means "gpu has locked up"
06:55 imirkin: i'd be more interested in the kernel log
06:59 wvvu: I think this happened after I increased the internal resolution to the ppsspp emulator to x4
07:00 wvvu: imirkin: this is not helpful? --> http://hastebin.com/irewokenes.coffee
07:00 imirkin: nope
07:00 imirkin: that's just "gpu has hung"
07:00 wvvu: to get the dmesg I would have to make some major overhaul.
07:00 imirkin: i'd want a kernel log
07:01 wvvu: damn
07:01 imirkin: usually it gets saved somewhere
07:01 wvvu: ok then it's gonna take some more
07:01 wvvu: I deleted the old messages as it was 80MB
07:01 imirkin: and you're on a full-height 160MB SCSI-2 disk i assume?
07:02 wvvu: uh??
07:02 urjaman: :P
07:03 imirkin: you said 80MB as if it were a lot
07:03 imirkin: which it would be, if your total disk size were, say, 160MB
07:03 urjaman: I do have limited my systemd journal size to 32MB now that i'm thinking of this ...
07:04 wvvu: oh I see, it was a joke.
07:04 wvvu: 80MB for just txt seemed wrong and deleted it
07:06 urjaman: thats not even big tbh
07:06 imirkin: and i imagine that any 160MB drive would have been, at best, SCSI-2, and probably full-height (aka double the height of a regular CD-ROM drive)
07:06 imirkin: or, *gasp*, ESDI...
07:07 urjaman: (my journal size limit is just because i happen to have an old 20G disk for this thing and got annoyed...)
07:07 urjaman: imirkin: i have a 486 laptop whose maybe-original disk is a 120MB 2.5" ide ...
07:08 imirkin: no way
07:08 imirkin: er, maybe with a laptop
07:08 Binbasher_: Okay wsky are you there? I'm mobile.. It didn't work
07:08 imirkin: but those 80MB/etc drives were def in the 286/386 timeframe
07:09 wvvu: which nvidia card last gen is reccomended? I see the're pretty cheap for 2GB ones
07:09 imirkin: wvvu: for what purpose? for use with nouveau?
07:10 urjaman: 750 Ti? or did i misremember... i did look up the fastest with accel nowadays at one point...
07:11 wvvu: nouveau, gaming linux
07:13 urjaman: it was most likely 780 Ti what i thought of ...
07:14 orbea: i thought it was 78o Ti for nouveau, at least if you trust online benchmarks
07:15 imirkin: wvvu: get a kepler. 780 Ti is def the best thing out there wrt nouveau, although there might be some local tuning needed in order to get it to reclock properly.
07:16 imirkin: urjaman: 750 ti is maxwell, which is likely not working great. and has no reclocking support. so not great for gaming :)
07:17 urjaman: imirkin: yeah i misremembered
07:18 Tom^: yea the 780ti or the titan
07:18 wvvu: damn expensive still
07:19 imirkin: wvvu: any of the 6xx or 7xx line will work fine, except the 750/750Ti
07:19 imirkin: 680 is quite a monster too, afaik
07:19 wvvu: allright
07:20 Tom^: imirkin: i wonder if those are still sold
07:20 Tom^: the years fly by faster then you might imagine
07:21 urjaman: thats true...
07:21 wvvu: nice price point.
07:22 urjaman: i just noticed my pair of 9500 GT (in one machine) and 9400 GT (in this one) arent fancy anymore
07:22 wvvu: does 4GB ram in gfx card improve things?
07:22 Tom^: wvvu: do you plan on runing 4k resolutions or ~3 monitors?
07:24 wvvu: urjaman: that happened to me when I had a pair of geforce 8800 gt. One ended up with all caps blown off.
07:24 wvvu: Tom^: not 4k, multimonitor yeah.
07:26 urjaman: but yeah currently only real reason for me to upgrade from these would be the 4 monitor support
07:27 urjaman: and those cards look like f'ing monsters ... though i
07:27 urjaman: *'m unsure as to how to put 4 connectors into a card without it being 2-wide ...
07:27 urjaman: and thats the point when they start putting like exhausts there -.-
07:28 imirkin: Tom^: on ebay, i'm sure
07:28 wvvu: do games, m$$, use all 4GB ram of a card?
07:32 Tom^: urjaman: monsters ? http://i.imgur.com/j6ZGWsy.jpg im not sure i agree with that. it fits in just fine.
07:32 Tom^: =D
07:33 martm: i dunno despite you want to play morans, i am not that mad as i could be when doing that you would not handle programming the driver
07:33 martm: but my card works so flawlessly that i have not seen a single problem for 2months, it's kepler
07:35 urjaman: Tom^: yeah when i pick graphics cards i usually go for something that looks like http://www.xgcdb.com/pub/gc/xgcdb_chaintech_geforce_fx_5200_128mb_ddr_gsl5200.jpg :P
07:35 Tom^: =D
07:37 urjaman: http://ecx.images-amazon.com/images/I/51HMBtLaLgL._SY300_.jpg the 9500GT looks kinda like this (well 2x DVI so not the same), but that was a compromise to me
07:37 urjaman: too much fan already
07:39 Tom^: i guess my pic was a bit hard to notice but this is how it looks http://www.kitguru.net/wp-content/uploads/2014/10/IMG_7841.jpg
07:39 urjaman: Tom^: ok i thought it was 2 cards
07:39 urjaman: the pic was a bit blurry
07:39 Tom^: mhm cheap phone :P
07:40 urjaman: so i parsed the upper part and lower part as card 1 and card 2 somehow ...
08:19 wvvu: ok test it again, only locks up with ppsspp, all other emus, even dolphin-emu are fine.
08:19 wvvu: what could it be?
08:26 urjaman: get the dmesg
09:33 imirkin: could someone with a kepler test whether http://patchwork.freedesktop.org/patch/72085/ fixes the piglit mentioned in the commit description?
09:48 sarnex: imirkin: will a NV106 work? appears to be kepler
10:05 Jayhost: Computer lock up on Satan screensaver. Pretty appropriate
10:14 sarnex: imirkin: yeah the patches fixes arb_clear_buffer_object-unaligned for me on nv106
10:19 karolherbst: skeggsb: found another pmu messup :/
11:51 linkmauve1: Hi, I currently have access to a GKsomething which doesn’t boot on Linux 4.2.0 (from Ubuntu 15.10), after which something says “NMI watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [gpu-manager:1454]”
11:51 linkmauve1: It did boot on 14.04.
11:52 wvvu: linkmauve1: disable nmi via kernel parameters perhaps?
11:52 wvvu: easiest fastest way
11:52 urjaman: no.
11:53 linkmauve1: nonmi?
11:53 linkmauve1: But yeah, that’s likely not a fix.
11:55 linkmauve1: nmi_watchdog=0
11:56 imirkin: sarnex: thanks!
11:56 mjg59: That won't actually fix it
11:56 mjg59: You'll just have a stuck CPU and no warning about it
11:56 sarnex: imirkin: should i send Tested-by?
11:57 linkmauve1: It did boot further, but crashed at a point where no TTY was displayed.
11:57 imirkin: sarnex: if you like
11:57 linkmauve1: mjg59, yeah.
11:57 imirkin: sarnex: i just wanted someone to confirm that the kepler path worked since i don't have one to test on
11:57 sarnex: imirkin: i didnt reclock it to the higher clock if it matters
11:58 wvvu: linkmauve1: blacklist the module.
11:59 linkmauve1: wvvu, which module, nouveau?
11:59 wvvu: noo, nmi
11:59 wvvu: nmi is a module
11:59 imirkin: sarnex: not at all
11:59 sarnex: cool
12:00 imirkin: sarnex: i was sending somewhat illegal commands down to the engine
12:00 mjg59: linkmauve1: gpu-manager isn't an upstream driver, as far as I can see
12:00 linkmauve1: Well, it’s a watchdog, it means something is wrong and ideally I’d fix it for him instead of just ignoring the problem.
12:00 linkmauve1: mjg59, oh.
12:01 linkmauve1: Damn Ubuntu…
12:01 mjg59: Oh, it's userspace maybe?
12:01 mjg59: I'm not sure
12:01 sarnex: oh i see
12:01 mjg59: It's hard to tell what's going on without the full message that's generated
12:01 mjg59: If it's a userspace app then it's still a serious kernel issue that the app is able to wedge the kernel
12:02 linkmauve1: ubuntu-drivers-common…
12:03 mjg59: You could just try uninstalling that package and see if things are happier
12:03 mjg59: But obviously still not a real solution
12:04 linkmauve1: It’s when booting the live-usb, we obviously didn’t go up to the installer.
12:05 imirkin: linkmauve1: boot with nouveau.modeset=0
12:06 wvvu: linkmauve1: blacklist the watchdog module
12:06 imirkin: watchdog isn't a module, nor does it have anything to do with the issue at hand.
12:06 mjg59: wvvu: All the NMI is doing here is detecting that a CPU is stuck in a loop
12:06 mjg59: If you disable the NMI, the CPU will still be stuck in a loop
12:07 wvvu: oh ok, I understood the watchdog was the thing that had the bug
12:07 linkmauve1: imirkin, it boots fine then.
12:08 linkmauve1: Should I uninstall that package and reload (how?) nouveau’s modeset, instead of i915’s?
12:08 linkmauve1: But currently it’s totally usable.
12:09 imirkin: linkmauve1: is this a laptop?
12:09 linkmauve1: Yes, with two GPUs.
12:09 linkmauve1: This GK107 and an Haswell one.
12:10 imirkin: you need kernel 4.3 or 4.4 in all likelihood. there's an issue powering on the secondary gpu in some cases where ACPI doesn't bring it out of reset properly
12:10 imirkin: so we have to super-mega-reset it
12:16 linkmauve1: Ok, once it’s installed I’ll install a recent kernel.
12:16 linkmauve1: Anyway, booting will already make my FOSDEM host happy. :)
12:16 linkmauve1: bbl if there is another issue on 4.4.
13:36 linkmauve1: I love how Ubuntu breaks its GRUB when you install a new kernel from a PPA…
13:37 linkmauve1: How can a distribution be so broken?
13:37 wootehfoot: linkmauve1, you mean update grub, which is what happens when there's a kernel update in general?
13:38 linkmauve1: Yeah.
13:38 wootehfoot: linkmauve1, so, what breaks?
13:39 wootehfoot: if everything is still working, then your notion of it breaking grub is moot
13:39 linkmauve1: GRUB doesn’t even starts, it stays on a blinking cursor, with no input working.
13:39 linkmauve1: start*
13:40 wootehfoot: linkmauve1, you probably updated grub along with kernel
13:41 linkmauve1: Why would that totally usual operation that any user could do ever entirely break the system?
13:41 wootehfoot: was the grub update from a PPA?
13:41 wootehfoot: lol
13:42 wootehfoot: well, good luck
13:48 linkmauve1: wootehfoot, anyway, a grub-install solved it.
13:52 linkmauve1: imirkin_, thanks, it works perfectly on 4.4. :)
13:52 imirkin: linkmauve1: awesome. if you boot with nouveau.pstate=1 you shoudl also be able to reclock your gpu to make it faster than the intel one
14:00 linkmauve1: imirkin, but that’s manually right?
14:03 imirkin: linkmauve1: yes
14:12 linkmauve1: Maybe I’ll give him a launcher. :)
15:09 wvvu: I got something
15:12 wvvu: ppsspp crashing nouveau real hard ---> http://hastebin.com/wepujagiro.sm
15:13 wvvu: does it help?
15:15 wvvu: wow, many people have the same problem.
15:16 wvvu: is there a way to make the message more verbose? or that's enough?
15:18 Tatsh: hi all, have a 650m in a macbook pro from 2013; doesn't seem to work when i plug in a monitor via DisplayPort (mini DP/Thunderbolt to DisplayPort)
15:18 Tatsh: i get 'link training failed' errors
15:18 Tatsh: i will be trying kernel 4.4 shortly (currently on 4.1)
15:18 wvvu: I am happy to debug this if someone tells me how to isolate.
15:19 wvvu: Tatsh: yep, ppl highly reccomend 4.4
15:20 Tatsh: i get a bunch of these lines
15:20 Tatsh: Jan 30 15:19:43 audvare-mbpro kernel: nouveau E[ PDISP][0000:01:00.0] 0x0404: 0x00000000
15:20 Tatsh: then link training failed
15:20 Tatsh: once i disconnect the dp cable, boots up SDDM no issue
15:20 wvvu: wow my sort of bug spans from 3.13.7-1 all the way to 4.3.3-2 in this thread --> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744166
15:20 Tatsh: weird thing is, last night when i logged into Plasma then plugged in the monitor, monitor was detected and loaded fine
15:21 wvvu: Tatsh: with 4.4? I don't have DP to test with.
15:21 imirkin: wvvu: sadly this is a very generic sort of bug... for some reason, a resource we were attempting to access was not there
15:21 Tatsh: i will be testing 4.4 with this shortly
15:21 imirkin: wvvu: the only real way i can make progress on that would be to get a mmt trace + matching dmesg errors
15:22 wvvu: imirkin: imirkin how to do that? I know exactly which program triggers that. Even better I think is just ONE game that does it.
15:22 imirkin: Tatsh: i think airlied was also reporting PDISP errors on his macbook... they only happened under some circumstances though
15:22 imirkin: wvvu: if you can reproduce at will, get set up with mmt -- http://nouveau.freedesktop.org/wiki/Valgrind-mmt
15:23 imirkin: wvvu: btw, make sure you're running *the very latest* mesa... i fix stuff a bunch, so... mesa from git master is preferable.
15:23 Tatsh: it seems to happen when X is init'ing, it does not happen once you're in the desktop
15:23 Tatsh: very latest mesa :/
15:23 Tatsh: i'm on gentoo, that is somewhat feasible
15:23 imirkin: Tatsh: mesa doesn't affect your issue
15:24 Tatsh: in any case i'm updating xf86 nouvea to latest in the tree, 1.0.12
15:24 Tatsh: just in case
15:24 imirkin: wvvu: btw even if you get me all that, no guarantee i'll be able to track it down
15:24 imirkin: Tatsh: your issue lies solely in the kernel
15:24 Tatsh: imirkin, do you recommend i not build nouveau into the kernel?
15:24 Tatsh: build as a module
15:24 wvvu: imirkin: I know exactly how to trigger the sucker.
15:24 imirkin: wvvu: also, chances of me understanding wtf is going on become *much* higher if i can repro myself
15:25 imirkin: Tatsh: module is probably best
15:26 wvvu: imirkin: do you reccomend update the card to UEFI vbios? or leave it 'legacy'?
15:27 imirkin: wvvu: i doubt that's in any way connected to your issues
15:28 wvvu: wow, I can't give you the log right now, looking at the guide seems simple
15:29 imirkin: wvvu: yeah, so the idea is that you'd do the mmt trace, and capture the errors in dmesg
15:29 imirkin: and i should be able to match up the addresses in dmesg to stuff in the mmt trace, and hopefully figure out wtf is going on
15:30 imirkin: we should probably create a simpler way of tracing nouveau things than with mmt but... meh. it's there, and it works on the blob, so we use it for nouveau as well.
15:30 Tatsh: what are the steps to get VDPAU with nvidia's firmware?
15:30 imirkin: Tatsh: http://nouveau.freedesktop.org/wiki/VideoAcceleration/
15:31 Tatsh: thanks
15:31 imirkin: (there should be a gentoo package as well iirc)
15:31 wvvu: imirkin: should I upgrade to nouveau 1.0.12?
15:31 Tatsh: i don't usually use vdpau but just in case; usually xv is good enough
15:31 Tatsh: and vdpau can't do filters
15:31 imirkin: wvvu: it won't hurt, but it won't help this particular issue
15:31 wvvu: ok
15:33 karlmag: |?
15:34 imirkin: |&
15:34 wvvu: ppsspp is also very verbose when started with a terminal.
15:34 karlmag: heh... sorry... tidying a bit here, so I moved the keyboard and happend to drop something onto it :-P
15:49 wvvu: so do this with ppsspp? --> valgrind --tool=mmt --mmt-trace-nvidia-ioctls --log-file=file-bin.log
15:55 imirkin: wvvu: mmmm.... you want nouveau, not nvidia
15:55 imirkin: wvvu: and also i think you need to do --mmt-trace-file=/dev/dri/card0 or something
15:55 imirkin: the instructions make wild claims about this not being necessary
15:55 imirkin: but in practice i've found it to be necessary
15:56 wvvu: so this --> valgrind --tool=mmt --mmt-trace-nouveau-ioctls --mmt-trace-file=/dev/dri/card0 --log-file=file-bin.log ppsspp
16:00 Tatsh: i dunno; seems like kernel 4.4 is doing worse
16:00 Tatsh: it freezes when SDDM is about to launch; i can still SSH into the machine
16:01 wvvu: imirkin: do I have to run this as root?
16:07 wvvu: as root?
16:14 Tatsh: getting the same error in kernel 4.4
16:14 Tatsh: [ 162.658437] nouveau 0000:01:00.0: disp: outp 01:0006:0281: link training failed
16:15 Tatsh: could uvesafb be a cause?
16:16 wvvu: Tatsh: lol, I don't think uvesafb is reccomended with nouveau
16:16 Tatsh: ok
16:16 Tatsh: i will remove it and reboot again
16:17 wvvu: that's what I was told a few days ago
16:20 Tatsh: thing is now everytime i start SDDM it hangs, and it's not killable
16:20 Tatsh: kill -9 has no effect
16:20 Tatsh: Jan 30 16:19:35 audvare-mbpro sddm[903]: Running: /usr/bin/X -nolisten tcp -auth /var/run/sddm/{cfbf44dc-4fe4-40c5-9cd3-bd51f1f75651} -background none -noreset -displayfd 17 vt1
16:20 Tatsh: if i strace sddm, it's stuck on a read() some socket call
16:22 wvvu: what's SDDM?
16:22 Tatsh: actually when i strace the process, [pid 935] write(20</dev/vga_arbiter>, "lock io+mem", 11
16:22 Tatsh: i think this is X
16:22 Tatsh: yes it is X
16:23 Tatsh: X gets stuck at writing to /dev/vga_arbiter
16:23 Tatsh: any ideas on that? X is running as root, crw------- 1 root root 10, 63 Jan 30 16:18 /dev/vga_arbiter
16:28 wvvu: Tatsh: I don't have such a beast. You have two gfx cards right?
16:35 Tatsh: wvvu, technically yes but the other one is basically disabled
16:36 wvvu: I don't have such a convolution, so I can't help.
16:52 wvvu: oh man, the time has come. Time to hard lock my machine :(
17:11 imirkin: wtf is vga_arbiter? i've never heard that
17:11 imirkin: wvvu: shouldn't need to be root
17:12 wvvu: imirkin: EPIC FAIL
17:12 wvvu: valgrind failed to start tool 'mmt' for platform linux: no such file or directory
17:13 wvvu: how it's even possible
17:13 imirkin: sounds like you didn't get mmt properly set up
17:13 imirkin: i assume it's because you didn't properly follow the instructions on that wiki
17:13 wvvu: ah alright, mmt is ANOTHER package. I thought it was built in options
17:15 imirkin: just follow the instructions.
17:16 Tatsh: yea i had no luck with kernel 4.4 and nouveau all set up
17:16 Tatsh: i did not install nvidia firmware
17:16 Tatsh: i could use the thing, but i could never get SDDM to load with my 2 external monitors via mini-DP connected
17:16 Tatsh: so basically the laptop has special rules for working: boot up, log in, then connect external monitors
17:17 Tatsh: well actually in the case of kernel 4.4, i never got SDDM to show up, even on the main laptop screen
17:17 Tatsh: 4.1 works
17:19 Tatsh: using the built-in intel card is not an option because that has no access to the external ports
17:19 imirkin: oh, 4.1 works but 4.2 is broken?
17:19 imirkin: in that case you're best off doing a bisect
17:21 Tatsh: 4.4 is broken for me
17:21 Tatsh: i have not tried 4.2
17:21 Tatsh: i'm going back to the semi-working configuration (where i have to plug in external monitors after logging into plasma)
17:22 Tatsh: it's a little annoying but this laptop is actually going to be stationary 99% of the time
17:23 wvvu: that's crazy mmt.
17:24 Tatsh: unusable pdf2text output is crazy ;/
17:27 wvvu: imirkin: is it possible that mmt could go by another name such as memcheck?
17:27 imirkin: no, that's regular valgrind i think
17:29 wvvu: imirkin: I just realized :/
17:30 wvvu: oh my gawd!! another thing that I have to install manually???
17:30 imirkin: following instructions is hard.
17:31 wvvu: is part of envytools?
17:31 imirkin: no
17:31 imirkin: envytools is not at all necessary for this
17:31 imirkin: you just have to set up the repo and install valgrind...
17:31 imirkin: preferably to some prefix
17:31 imirkin: so that you don't overwrite any system things
17:34 wvvu: I will, is just way too many stepts :/
17:35 wvvu: I tought it was a matter of minutes, just issue the damn command now I have to multiple steps
17:36 imirkin: it's all in the wiki
17:36 imirkin: read it carefully.
17:44 Tatsh: hmm, so i did what i thought worked; logged into KDE 5, plugged in 1 monitor, then plugged in the second
17:44 Tatsh: on plugging in the second i got the link training failed error
17:44 Tatsh: X crashed at that point
17:51 wvvu: which prefix is needed here? --> ./configure --prefix=...
17:53 wvvu: what if I want to run off the folder?
17:55 Tatsh: i will now try kernel 4.3 :|
17:56 Tatsh: all i want is these 2 displayports to work :/
17:56 imirkin: wvvu: i like to use /home/user/install
17:56 Tatsh: they work fine on OS X, so they aren't broken; and nothing is wrong with the monitors or cables
17:56 wvvu: imirkin: ok, good idea I didn't want to trash /bin or /lib
17:56 imirkin: Tatsh: DP can be quite finicky unfortunately. nouveau hardly handles all the various cases.
17:57 imirkin: Tatsh: furthermore, nouveau does not support DP-MST
17:57 Tatsh: DP-MST?
17:57 imirkin: multi-stream transport
17:57 Tatsh: is that like, daisy chaining?
17:57 imirkin: e.g. multi-tile monitors, or where you have a DP hub
17:58 imirkin: some laptop makers think it's hilarious to stick a DP-MST hub inside of a docking station for example
17:58 Tatsh: no, i don't have a hub; and i'm not daisy chaining; there are two Thunderbolt/mini-DP ports right on the laptop
17:58 imirkin: and ideally apple's idea of fun isn't to stick a DP-MST hub inside of the laptop :)
17:58 imirkin: anyways, even if that were the case, what you'd see is an identical picture on both screens
17:59 imirkin: (instead of seeing them as separate screens)
18:01 Tatsh: no, they are always separate
18:02 Tatsh: the reason i'm using nouveau is because nvidia's driver seems to crash for some reason
18:02 wvvu: imirkin: VEX inside is like this? valgrind-mmt/VEX
18:02 imirkin: just follow the instructions.
18:02 wvvu: I am not using git
18:02 Tatsh: when i use nouveau, things work, and are pretty acceptable, although i have not yet got 2 external monitors to work, only 1
18:02 imirkin: wvvu: that's gonna be a problem.
18:08 Tatsh: know about this error? nouveau 0000:01:00.0: disp: outp 03:0006:0448: link not trained before attach
18:08 Tatsh: this is with the monitor hooked up before X starts
18:10 wvvu: imirkin: got it, soon will get the results
18:16 imirkin: Tatsh: some sort of failure during link training... try loading nouveau with "nouveau.debug=debug drm.debug=0x1e"
18:37 Tatsh: imirkin, on systemd where do you set that?
18:37 Tatsh: or rather
18:37 Tatsh: you mean on my boot options
18:38 Tatsh: ok
18:38 imirkin: boot options, yes
18:38 imirkin: or module load options
18:39 Tatsh: ok
18:39 Tatsh: i will have good output from dmesg
18:39 Tatsh: one sec
18:41 Tatsh: https://bpaste.net/show/990270ebbfab
18:43 Tatsh: at this point, X started on eDP-1, did not show on DP-2 (external), and it's now frozen
18:44 wvvu: imirkin: is normal for the "--log-file=file-bin.log" 1kb only? It only has 4 lines
18:44 imirkin: wvvu: no
18:44 wvvu: but I changed it to "--log-file=nouveau.bin"
18:46 imirkin: Tatsh: hm. it seems like all the link training sequences in that log complete successfully
18:46 imirkin: wvvu: --mmt-trace-nouveau-ioctls --mmt-log-file=/dev/dri/card0
18:46 imirkin: er
18:46 imirkin: sorry
18:47 Tatsh: the external monitor DP-2 is still sleeping
18:47 imirkin: wvvu: --mmt-trace-nouveau-ioctls --mmt-trace-file=/dev/dri/card0
18:47 Tatsh: and sddm-greeter (run in X) is frozen
18:47 Tatsh: no mouse movement
18:47 imirkin: Tatsh: well that log is obviously cut off... perhaps something died at the end too
18:47 wvvu: is this correct? --> imirkin that's what I did
18:48 imirkin: wvvu: is nouveau your only gpu?
18:48 imirkin: wvvu: and do you have DRI3 enabled?
18:51 wvvu: yes
18:51 wvvu: no idea
18:52 wvvu: /dev/dri/ has card0, control and render
18:53 Tatsh: imirkin, https://bpaste.net/show/c47bd4a4f3e2
18:53 imirkin: wvvu: try renderD128
18:53 imirkin: wvvu: i assume there's no renderD129?
18:53 Tatsh: i got into KDE, plugged in the monitor; the monitor became my primary, at 1080p, then i set settings to make the laptop go to the right and enable it back on, with the external monitor being the primary and at its max resolution 2560x1600
18:53 Tatsh: now, both screens are black
18:54 imirkin: Tatsh: aha there ya go... [ 164.005226] nouveau: evo channel stalled
18:54 imirkin: i suspect that's the cause of the problems
18:54 imirkin: dunno if that's the generic cause though
18:55 wvvu: imirkin: now the dmesg message is different --> http://hastebin.com/ogiloxiluj.css
18:55 wvvu: just one render
18:56 imirkin: wvvu: oh that's sad
18:57 Tatsh: imirkin, could this be bad hardware?
18:57 imirkin: Tatsh: unlikely
18:57 Tatsh: ok; i was wondering if that's why the nvidia drivers were crashing randomly
18:57 wvvu: imirkin: what's sad? The just one render?
18:58 wvvu: renderD128
18:58 imirkin: wvvu: no, the ctxsw timeout
18:58 imirkin: no way to recover from that
18:58 imirkin: Tatsh: who knows, no real way to determine. yay closed-source software?
18:58 imirkin: Tatsh: unfortunately i'm not too well versed in all this DP stuff
18:58 Tatsh: well you mean hardware?
19:00 wvvu: so run again valgrind against renderD128 ?
19:01 wvvu: imirkin: what do you mean 'no way to recover' ?? meaning it'll never be fixed?
19:01 wvvu: dolphin emulator doesnt' crash.
19:01 wvvu: nor do other emulators.
19:02 imirkin: wvvu: it means once your GPU gets into that state, we don't know how to unfuck it, you have to reload nouveau or reboot
19:02 wvvu: damn!!!
19:03 wvvu: is there any other debugging that'll help?
19:03 wvvu: can I do more?
19:03 imirkin: if you can explain to me how i can repro this, things might go faster.
19:03 wvvu: or is this a true blind spot?
19:04 wvvu: I use ppsspp emulator then run a game.
19:04 wvvu: download an iso image from torrents
19:04 imirkin: the blind spot is in debuggability - it doesn't sound like you were able to use mmt
19:05 wvvu: so run it against renderD128?
19:05 imirkin: first try it with glxgears instead of the emulator
19:05 imirkin: until you get it right
19:06 imirkin: then you can move on to more complex items
19:06 wvvu: do you think glxgears will trigger the error?
19:07 imirkin: absolutely not
19:07 imirkin: but it will be a good testing ground for you to figure out how to operate valgrind-mmt
19:07 wvvu: but with --mmt-trace-file=/dev/dri/renderD128 ?
19:08 imirkin: yea
19:08 wvvu: alright
19:08 imirkin: if that still doesn't work, also try LIBGL_DRI3_DISABLE=1
19:08 imirkin: (and use /dev/dri/card0)
19:12 wvvu: illegal hardware instruction with /dev/dri/renderD128
19:16 wvvu: illegal hardware instruction as well with /dev/dri/card0
19:18 wvvu: as root "illegal instruction"
19:19 wvvu: on standby for further instructions
19:21 wvvu:updates nouveau in the meantime
19:21 imirkin: ugh. i think the issue is that the emulator can't run under valgrind :(
19:21 imirkin: that's very sad.
19:22 imirkin: or are you saying that you also see this with glxgears?
19:22 wvvu: no, the emulator DID run, its glxgears that's NOT running
19:24 wvvu: I tried all combinatios LIBGL_DRI3_DISABLE=1
19:24 wvvu: and /dev/dri/card0
19:24 imirkin: weird!
19:24 wvvu: as root too
19:27 imirkin: sorry, i don't have time now to dig into this
23:59 Jayhost: hmm MMIOtrace breaks because shadowramin.c pramin_init rd32 0x2e/0x40