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