00:02Guest88694: Hello. I've read troubleshooting and didn't find a solution.
00:04Guest88694: I've got nVidia GeForce GTX 745 and the screen resolution is way too big. I can't change it.
00:06Guest88694: On boot up it says nouveau firmware failed to load.
00:45mogorva: is this a known bug in the open source driver? (water and sky textures are replaced with colorful, blocky pixels): http://i.imgur.com/gfu6Q5b.jpg
00:47RSpliet: 'd you try to install support for txc_dxtn ?
00:47mogorva: the game is Two Worlds 2 running in wine
00:47RSpliet: using nine?
00:48mogorva: no, wined3d and libtxc_dxtn-1.0.0-4.fc22.i686 is installed
00:51RSpliet: ok... and are you sure it's a driver bug and not a wine bug?
00:52RSpliet: do you have the ability to try different drivers?
00:52mogorva: it wasn't present with the binary drivers 340.76 I tried a few days ago
00:53RSpliet: what's the output of "glxinfo | grep render" ?
00:54mogorva: glxinfo | grep render -> http://pastebin.com/jdcxEKtS
00:54RSpliet: so far so good; NV92 should be a well supported GPU too
00:55RSpliet: any errors in dmesg ?
00:55mogorva: no, there's nothing
00:56RSpliet: oh I see you've had more trouble with nouveau and wine games
00:57RSpliet: (reading back IRC logs)
00:57RSpliet: sorry, I could have known your set-up was correct now ;-)
00:57mogorva: with gallium nine + wine certainly, but not with vanilla wine
00:58RSpliet: yeah, nine probably exposes some driver bugs that nobody really had the time to fix
00:58RSpliet: it works better for AMD ironically
00:58mogorva: i can't get nine working in wine even though native d3d9 is active according to the terminal output, even the most basic dx9 test application crashes when native d3d9 is enabled
00:59RSpliet: anyway, I'm afraid I'm not a rendering expert, but your problem looks like trouble with texture sampling
00:59RSpliet: and highly related to what I see in DOTA2
00:59RSpliet: or... well, maybe it isn't, because then I'd expect some odd colours *with* shadows and lighting...
00:59RSpliet: that's... well, I know very little of rendering :-D
01:00RSpliet: I think it's valid to file a bug in bugzilla for this
01:00RSpliet: but expect a request for an api trace
01:00mogorva: i check my other games too, i remember seeing similar issues in other games as well with nouveau
01:12marcus: hmm, when i start with modprobe.blacklist=nouveau the xserver does not start anymore. does the modesetting driver require nouveau to be present as well?
01:17mogorva: RSpliet: i get this garbled screen in Trine 2 (wine) when detail level is set higher than 'low' --> http://imgur.com/nRldNRm
01:17mogorva: i remember not having such an issue with the binary drivers
01:19pq: marcus, yes, modesetting driver need the Nouveau kernel driver for KMS.
01:20pq: otherwise there is no modesetting on the kernel for that gfx card
09:27flipmess: hi, my xbacklight prefers nv_backlight over intel_backlight. is that nouveau, i915 or x problem?
09:28imirkin_: it's the universe's :)
09:28flipmess: xorg.0.log says [ 11.982] (--) intel(0): Found backlight control interface nv_backlight (type 'raw') for output LVDS1
09:29flipmess: it started when i installed nouveau
09:29imirkin_: so... there's a simple solution, which is to add something in xorg.conf
09:30imirkin_: of course the irony of doing that would be that you would no longer be able to use the nvidia gpu via reverse prime
09:30flipmess: i mean shit
09:30imirkin_: i'm not well-versed in backlight stuff
09:31imirkin_: hansg (who appears to not be around) just posted a huge series reworking a lot of it (linux-wide)
09:31imirkin_: you might try in #intel-gfx, they *love* backlight-related issues there
09:31imirkin_: maybe that's why they have so many
09:33gnidmoo: hi there, I'm trying to run Minecraft with FTB Lite 3 modpack, but it crashes when I launch it and I think its a problem between Forge and nouveau, I've a Nvidia GeForce GT 525M, here is the result of 'dmesg | grep nouveau': http://phosphor.i0i0.me/jznYWwUz and here is the crash log: http://hastebin.com/asivexakak.txt
09:34gnidmoo: It works with FTB Lite 2 which uses an older version of Forge, could it be related to nouveau, or it is related to Forge? Since a friend have a GT 540M with NVIDIA drivers, and it works on his PC...
09:34imirkin_: gnidmoo: are you, perchance, using libdrm 2.4.60?
09:36gnidmoo: imirkin_, I'm using libdrm 2.4.61
09:36imirkin_: hm ok. that shouldn't have the issue i was thinking of.
09:37imirkin_: (and your logs didn't super-indicate it, but... one can dream!)
09:37imirkin_: anyways, it's clearly a nouveau bug
09:38imirkin_: (even if it's a forge bug, it's still a nouveau bug to error like this)
09:38gnidmoo: imirkin_, where should I look to see more infos about this problem?
09:38imirkin_: unfortunately i have no clue. i don't know how to debug these sorts of issues.
09:38imirkin_: i have enough easier-to-debug issues that i tend to concentrate on :)
09:39gnidmoo: me neither, that's why I'm here :/
09:44imirkin_: perhaps skeggsb_ has ideas, but i don't really... sorry
09:44imirkin_: i have a super-reproducible crash with supertuxkart 0.9 that i still haven't tracked down which MIGHT look like at least one of the issues in your log
09:45imirkin_: but i tried tracking it down and had no clue what was going on
09:46gnidmoo: I think I'll try nvidia drivers until it's fixed, thanks anyway
09:49flipmess: can i still use reverse prime if i disable lvds-1-2?
09:51imirkin_: flipmess: sure
09:51imirkin_: gnidmoo: well, nouveau's not so great for gaming in the first place, esp with a fermi like yours where we can't reclock
09:55flipmess: imirkin_ << you told me once not to use vga if i can use dp++. i tried using hdmi with an adapter on dp++ but it allways shows as disconnected.
09:55imirkin_: doh :(
09:55imirkin_: well in theory it should work :p
09:56imirkin_: could you do 'grep . /sys/class/drm/card*-*/status'
09:58flipmess: thats the same thing xrandr reports
09:58imirkin_: and that's with the HDMI thing hooked up?
09:58flipmess: can i force it?
09:58imirkin_: well, i know for a fact that it works on my intel-only laptop with a dp++ port
09:59imirkin_: if you want, we can try debugging why it doesn't show up
09:59flipmess: i want
09:59imirkin_: boot with nouveau.debug=DISP=debug,VBIOS=trace,I2C=debug,DRM=debug drm.debug=0xe
09:59imirkin_: this will be a lot of stuff, so you want to set the kernel log size to be large
10:00imirkin_: i forget how... log_buf_len=10M or something?
10:00imirkin_: yeah, that seems right
10:00imirkin_: [assuming you can spare 10M of ram for such a debugging exercise)
10:01flipmess: np 32gb
10:01flipmess: imirkin_ << can i keep the other kernel parameters?
10:02imirkin_: as long as none of them are nouveau.debug :)
10:03flipmess: i'll reboot now... should i keep the connector connected or disconnect?
10:06flipmess: journal is spitting stuff like
10:06flipmess: kernel: [drm:intel_fbc_cancel_work] cancelling pending FBC enable
10:06imirkin_: yeah that makes sense
10:06flipmess: the whole time.. 100/s
10:06imirkin_: that doesn't
10:06imirkin_: i'd ask in #intel-gfx about that
10:06imirkin_: for now just drop the drm.debug=0xe
10:06imirkin_: it's interesting stuff, but i guess we'll do without
10:07imirkin_: oh, i should remove the driver stuff from the mask
10:07imirkin_: hold on
10:07imirkin_: need to look up how the mask works :)
10:08imirkin_: drm.debug=0xc instead of 0xe
10:09flipmess: ok rebooting
10:10imirkin_: problem solved? :)
10:11flipmess: it's still spitting kernel: [drm:intel_fbc_cancel_work] cancelling pending FBC enable
10:11flipmess: there are single:
10:11flipmess: kernel: [drm:gen7_fbc_enable] enabled fbc on plane A
10:12flipmess: kernel: [drm:ilk_fbc_disable] disabled FBC
10:12flipmess: what is FBC?
10:12imirkin_: framebuffer compression
10:13imirkin_: hm, yeah, that stuff is logged as DRM_DEBUG_KMS
10:13imirkin_: not sure what the polciy should be
10:14flipmess: options i915 enable_rc6=7 enable_fbc=1 lvds_downclock=1
10:14flipmess: i'll remove enable_fbc=1
10:16flipmess: it stopped
10:16flipmess: imirkin << now i get "some" kernel: [drm:drm_mode_addfb2] [FB:59]
10:17imirkin_: can you pastebin a clean boot
10:17imirkin_: with that thing plugged in?
10:17flipmess: ahm... dmesg?
10:20flipmess: imirkin << http://sprunge.us/UbJL
10:26flipmess: imirkin_ << http://sprunge.us/UbJL
10:26flipmess: sry there are 2 of you
10:31imirkin_: heh yeah
10:31imirkin_: also it's a long log :)
10:32flipmess: sry ^^
10:33imirkin_: and the hdmi was plugged in right?
10:33flipmess: maybe it's hardware defect?
10:34imirkin_: just an uncommon configuration
10:35imirkin_: that we likely don't handle properly =/
10:35flipmess: i read it's the "worst case scenario" where all the external ports are linked to nvidia
10:35imirkin_: so this is the interesting bit: http://hastebin.com/raw/ahibowaquy
10:36imirkin_: which it reads as disconnected
10:36imirkin_: i don't know enough about how this is supposed to work to know where to even look though
10:36imirkin_: file a bug, including that log as an attachment
10:40flipmess: so "xrandr --setprovideroutputsource nouveau Intel" isn't necessary to detect dp ports?
10:40flipmess: because only when i do that does xrandr show the ports
10:45imirkin_: flipmess: well, the detection happens irrespective of that
10:45imirkin_: in order to get them to show up in X you need to do that
10:45imirkin_: but the driver sees it regardless
10:48flipmess: ok i went to vga again... and it doesn't work anymore...
10:48flipmess: when i do xrandr --output VGA-1-2 --auto --above LVDS1
10:49flipmess: i can see the same picture as on primary monitor and it's flickering at 5Hz
10:51flipmess: i have to do xrandr --setprovideroutputsource nouveau 0x0 to turn off the screen but the card stays on...
11:00flipmess: i get every 10s:
11:01flipmess: kernel: nouveau D[ I2C][0000:01:00.0][0x00000000] PAD:X:02: -> PORT:02
11:01flipmess: kernel: nouveau D[ I2C][0000:01:00.0][0x00000000] PAD:X:02: -> NULL
11:03imirkin_: probably polling the DP thing? dunno
11:05flipmess: i tried it with drm_kms_helper.poll=0 as you suggested earlier but i still cannot stop the card once it's activated with "xrandr --output VGA-1-2 --auto --above LVDS1"
11:16flipmess: ok when i restar x nouveau goes to sleep -.-;
11:36qbco: I'm on an nvidia 650, and I get missing letters in any X program, does anyone have any idea why?
11:36qbco: THe problem looks like this: https://sr.ht/a2d4.png
11:38qbco: I don't get the problem with the propietry drivers, but I'd rather run nouveua
11:43qbco: just tried, and it doesn't occur with X bitmap fonts, so I'm assuming it's some kind of faulty interaction with freetype
11:45qbco: dmesg is filled with stuff like [ 807.157370] nouveau E[ PDISP][0000:02:00.0] Core - DAC 0:
11:45qbco: [ 807.157380] nouveau E[ PDISP][0000:02:00.0] 0x0180: 0x00000000
11:49flipmess: qbco << is it changing when you scroll?
11:54imirkin_: qbco: pastebin xorg log
12:16qbco: imirkin_: sorry, just got back, wait a sec
12:17qbco: flipmess: it does not change as a scroll, but if I type or any of the text in the window changes, it does change
17:57Guest88694: Hello. I've read troubleshooting and didn't find a solution.
17:58Guest88694: I've got nVidia GeForce GTX 745 and the screen resolution is way too big. I can't change it.
17:58Guest88694: On boot up it says nouveau firmware failed to load.
17:59imirkin_: pastebin dmesg
17:59imirkin_: what do you mean by 'resolution way too big'?
18:01Guest88694: I have one option in displays for resolution. 800x600 (4:3)
18:01Guest88694: my display is not recognized
18:02Guest88694: on a 24" screen it looks horrible.
18:02imirkin_: anyways, like i said... pastebin dmesg
18:03imirkin_: that should hopefully explain what's going on
18:11imirkin_: ok, so you have a GM107 and a 3.16 kernel. try updating. with kernel 4.1-rcN you should be able to get out-of-the-box accel, but with some older kernels you should be able to at least get modesetting.
18:12skeggsb: boot with nouveau.config=PGRAPH=0 for a workaround
18:13skeggsb: 4.1 should work fully out of the box though, and fixes both the not loading if no fw present, and the need for external firmware on gm107
18:14imirkin_: skeggsb: someone was here earlier with what seemed like a failed bios read from acpi on a GM107
18:14imirkin_: it was a late 4.1-rc, which should have had your vbios loading fixes... i thought
18:14imirkin_: i got him to make an acpidump, but didn't analyze
18:14skeggsb: fuck me, i hate acpi
18:15imirkin_: well, it *got* the vbios, but it was non-sensical
18:15imirkin_: dcb version 0x83 or something
18:15imirkin_: and unknown opcode 0xaf or so
18:15skeggsb: yeah, i'd say garbage
18:16skeggsb: unless he has a gm2xx+20 somehow :P
18:16imirkin_: skeggsb: oh, btw, should DP++ work (i.e. hdmi-over-dp?)
18:16skeggsb: yes, it should be no different to direct hdmi
18:17skeggsb: unless dp++ is something more fucked than the usual tmds passthrough
18:17skeggsb: in which case, it should just be normal dp :P
18:17airlied: no it's just that
18:18imirkin_: see my conversation with flipmess in the scrollback - this is the log i had him make: http://sprunge.us/UbJL
18:18imirkin_: he claims that something was plugged into one of the DP ports
18:19imirkin_: (search for DP-1)
18:20skeggsb: well, the hotplug pin for that is asserted, or we wouldn't have even attempted the aux transaction to see if it's real dp or not
18:21skeggsb: it times out, as one would expect if it's not *actually* DP
18:21skeggsb: but then we still don't manage to pull anything from ddc in the normal way either
18:21imirkin_: let me ask another way, have you ever, personally, tried plugging in a hdmi thing into a DP++ port?
18:21skeggsb: yes, often
18:21imirkin_: hm ok
18:22skeggsb: it's a fairly normal configuration to have actually
18:22skeggsb: most dp->dvi/hdmi things are passthrough
18:22imirkin_: well, it's more normal to just have a matching port :p
18:23skeggsb: challenging when a lot of laptops only come with a DP connector these days :P
18:24imirkin_: heh, yeah, that happened on mine too :)
18:24imirkin_: but then again i don't have lenovo shipping me a new laptop every week
18:24skeggsb: i'll be re-testing pretty much everything i have over the next week or so anyway, so if something has broken there, i'm sure i'll notice it
18:24imirkin_: ooh, atomic?
18:25skeggsb: no, rhel :P
18:25imirkin_: ah heh
18:25skeggsb: but, that said, i'll either finish that "real soon now" (yep...), or hack mst support into our current code
18:26airlied: skeggsb: yeah if that w541 is mst dock, then someone will care :)
18:26imirkin_: did you like my comment on the ml re when mst would be available?
18:26skeggsb: airlied: i'm pretty sure that the mst helper is going to need some changes to be a nice fit on atomic too anyway ;)
18:26skeggsb: airlied: when're you doing radeon? hehe
18:26skeggsb: imirkin_: yes, i did notice that :P
18:26airlied: skeggsb: radeon is upstream :)
18:27airlied: just not on by default yet!
18:27skeggsb: atomic, i mean
18:27airlied: oh atomic, I ran away
18:27airlied: I didn't see it ending well
18:28Guest88694: ok. updating the kernel doesn't seem to have made a difference.
18:28skeggsb: :) yeah, was somewhat more work than i expected too
18:29airlied: I got list on how much of atomic I wanted at once
18:29airlied: lost even
18:30imirkin_: skeggsb: btw, i assume you haven't had a chance to look at the stk 0.9 crash?
18:30airlied: probably easier to just to write a pure atomic driver from scatch and debug it into working
18:30skeggsb: airlied: yeah, that's what i decided too after a quick attempt at following the "transition steps"
18:30skeggsb: imirkin_: nope, hasn't even crossed my mind actually
18:34imirkin_: skeggsb: what's "PGRAPH/DISPATCH"? [as far as read fault errors go]
18:36imirkin_: yeah_guy: what's the new kernel version?
18:45yeah_guy: i guess the kernel upgrade didn't take. i'm still at 3.16.0-4
18:50buhman: lol 3.16