00:31gnurou: skeggsb: wrt. gm204 mixed memory & secure boot issue, maybe for the moment we could go with a workaround to allocate WPR memory from the lower area?
00:32gnurou: skeggsb: things are still under discussion on our side, and this is affecting quite a few users...
00:43imirkin: gnurou: does that really fix things? seems like people will still get random crashes, just later on
00:56gnurou: imirkin: do they? I only tested quickly, but it seemed to fix the issue on my side...
00:56gnurou:looks at the bug again
00:57imirkin: wouldn't the issue happen if anything tried to use vram in the problem area?
00:59gnurou: afaik this area is only doomed for secure boot
00:59skeggsb: and for the rest, you're probably writing over other (wrong) areas of vram and will end up crashing weirdly later anyway
01:00gnurou: one drastic workaround would be to limit the available memory to the "safe"area on problematic chips, after all all it's not as if users can take advantage of their 4GB at the current state of things
01:01skeggsb: yes, i'm still not entirely sure it's safe to do that on all configurations, because nv haven't answered my questions :P
01:01skeggsb: ie. we can drop the partitions with disabled ltcs easily enough
01:01skeggsb: but, are there configurations where *all* partitions have some disabled that'll make us drop them all?
01:01gnurou: skeggsb: it may take some more time, there is a lot of internal discussion currently
01:02gnurou: skeggsb: btw, I think we discussed the idea of allocating secboot memory in the lower areas, but you dismissed it for a good reason - I cannot remember what that reason was?
01:02skeggsb: because it's pointless when it doesn't solve the problem :)
01:03skeggsb: iirc, the area past the end of valid vram in the lower area just wraps back around over the valid area
01:03skeggsb: so anything allocated in the weird part will just write to "random" places elsewhere in vram
01:04skeggsb: we can't do *anything* except just drop the upper portion completely, and we don't have enough information to figure out what to drop yet
01:04skeggsb: and that'll come in the form of a) people providing enough traces of different configurations to figure it out ourselves, or b) nv to just answer the question!
01:04gnurou: there is a document in preparation, but you know how long it takes us to release docs... >_<
01:05skeggsb: yeah, i heard a brief update about that this morning
01:56jrayhawk_: I have a (somewhat uncommon?) mobile gm204 quadro I can test if anyone wants to point me at a reporting methodology. 'gm20' will hilight me on future occasions.
01:57jrayhawk_: Either via Optimus or dedicated.
03:33imirkin: jrayhawk_: should mostly just work on newer kernels. are you having some kind of trouble? (is it a 4GB one with the funny memory partition thing?)
07:56lapion: Does anyone in here have a laptop with 8GB ram and a nvidia FX1800M
07:57lapion: my laptop with nvidia quadro fx1800m keeps freezing up. if I have more than 6GB installed
07:59lapion: at least with the nVidia stock driver it regularly has jitters, artefacts and freezes up, with the nouveau it has less artefacts and jitters and freezes less frequently.
09:00kwizart: FYI, I've managed to recover from my black screen at uefi by removing the cmos batterie to reinit the bios/uefi setting
09:00kwizart: but something remains corrupted when trying to enable uefi again
09:01karolherbst: gnurou: by the way, anything regarding my questions about the coefficients? :D
09:02gnurou: karolherbst: I'm afraid it got buried sadly :( nobody wants to take the responsibility to confirm this and risk seeing GPUs burn
09:02gnurou: which is not a very sound reasonning, considering that things will go ahead nonetheless...
09:02karolherbst: if they fear this, they could provice docs about the P+0x50 table! :D
09:03karolherbst: because this defines the driver downclocking on high temperature
09:03karolherbst: I was able to figure a bit more out regarding the power budgets, so I guess we are fine there
09:05karolherbst: gnurou: yeah, but if they confirm this, we can point fingers!
09:50thican: Hello everyone, I have those messages when I am using WebGL inside Firefox with my (old) GPU, a Nvidia 8600 GT (from April 2007) https://bpaste.net/show/b1b0c656f1dd
09:50thican: plenty of them
09:50thican: like30k of those lines
09:51thican: therefore 2k times
09:54thican: I am using Mesa 12.0.3
09:56RSpliet: thican: what kernel version is that?
09:56thican: with some "hardened" patches
09:57thican: Not mine, from Gentoo's Hardened project's maintainers
09:57thican: I happens with this website http://madebyevan.com/webgl-path-tracing/
09:57RSpliet: that all doesn't sound unreasonable
09:58thican: I don't think it's related, I just wanted to say it's not vanilla
09:59thican: It had some security improvments, like GRsec (which I don’t use, too tidious), PAX, etc
10:00RSpliet: that shouldn't make a big difference in these kind of cases
10:00thican: So, I think it might be related to the support of this GPU
10:01RSpliet: definitely. Might be worth filing a bug on our bugzilla
10:02thican: related to the NV50, but I am not sure if I am correct about it
10:02RSpliet: mention the webpage, the buttons you press to reproduce and the likelihood of reproduction and all the standard stuf on our "report a bug page"
10:02thican: ok, I will
10:02RSpliet: add a full unfiltered dmesg
10:02thican: Thanks for the answer
10:02RSpliet: that'll give some information about the precise hardware
10:03thican: well, except I have 2k the same 14 lines
10:03RSpliet: sorry I don't have a quicker fix :-)
10:03thican: it's ok, I am not that hurry
10:03thican: I have 30k lines of those dmg, therefore 2k times
15:16jwright: ping imirkin you around?
15:17jwright: ive got what looks like a driver lockup in nouveau on a NVS 310, read fault
15:17jwright: Oct 9 15:04:10 acampeau-desktop kernel: nouveau E[ PFIFO][0000:02:00.0] read fault at 0x0001784000 [PAGE_NOT_PRESENT] from PGRAPH/GPC0/TEX on channel 0x003fcb1000 [gnome-shell]
15:17jwright: Oct 9 15:04:10 acampeau-desktop kernel: nouveau E[ PFIFO][0000:02:00.0] PGRAPH engine fault on channel 5, recovering...
15:17jwright: Oct 9 15:04:10 acampeau-desktop kernel: nouveau E[ PGRAPH][0000:02:00.0] TRAP ch 5 [0x003fcb1000 gnome-shell]
15:17jwright: Oct 9 15:04:10 acampeau-desktop kernel: nouveau E[ PGRAPH][0000:02:00.0] GPC0/TPC0/TEX: 0x80000049
15:21jwright: ping #nouveau if anyone else knows too... ^
15:23digital0: I have garbled screen (https://bugs.freedesktop.org/show_bug.cgi?id=70972 )
15:23digital0: is there anything I can try to make it work at 1280x800?
15:34imirkin: digital0: i suspect trying xf86-video-nv would be worth trying
15:34imirkin: jwright: i'm around, but no insight into your issue
15:34digital0: Tied nv, did not help
15:34digital0: the same problem
15:35jwright: imirkin, robclark said you might have an idea, thanks for looking anyway
15:36imirkin: jwright: were there earlier errors?
15:36jwright: im just going to have them panic it and see if i can get anything out of the vmcore
15:36jwright: no it seems cyclical though
15:36jwright: almost like its causing deadlocks in the kernel
15:36robclark: that sort of error is more likely a userspace (libdrm or mesa) triggered issue..
15:36imirkin: nouveau reliability is pretty much crap
15:37imirkin: so if this is on a system that has to be reliable, either stop using gnome-shell or stop using nouveau_dri.
15:38jwright: eh... so is nvidia proprietary :P
15:38imirkin: (and when i say 'stop using gnome-shell', what i really mean is 'stop using GL apps on a regular basis')
15:38karolherbst: it would be so nice to get that stuff fixed though
15:39imirkin: never said anything to the contrary
15:39karolherbst: well, what I really need is like 4 weeks off to finish my stuff
15:40karolherbst: I would even check if there are some race conditions within the kernel module itself, totally ignoring what userspace might be able to mess up
15:41karolherbst: couldn't we just implement a real pessimistic locking on the nouveau interfaces in the kernel and see how that would go?
15:43ajax: isn't it somewhat negligent to _not_ implement locking in an era where every machine has at least two cores
15:43ajax: sorry, sorry. not helpful, i know.
15:43jwright: lol ajax
15:43imirkin: ajax: locking is implemented. doesn't mean there aren't bugs.
15:44karolherbst: you don't want to lock ever. Locking is something you _have_ to do, but don't want to do basically, that's the painful part
15:44karolherbst: so everybody tries to be as smart as possible
15:44karolherbst: and mess things up
15:44imirkin: digital0: ok, well if it doesn't work xf86-video-nv, i'm not surprised nouveau doesn't work either - the pre-nv50 modesetting logic is pretty much a direct copy of the nv driver
15:44imirkin: ajax: or are you referring to the nouveau_dri woes?
15:44karolherbst: and if you lock real bad, you get like 10% of your original performance
15:44Lyude: mupuf: that sounds interesting
15:45imirkin: ajax: in that case, it's a very recent development that applicaitons try to use GL from multiple threads
15:45karolherbst: and we have multiple applications at once doing this
15:45digital0: so going back to nvidia driver is the only option?
15:46karolherbst: you could disable modesetting as well
15:47ajax: maybe in your world.
15:48imirkin: digital0: unless you're interested in figuring out the issue yourself, pretty much yea
15:48digital0: without modesetting I get vesa driver and the same 1024x768 resolution, but I need 1280x800
15:48imirkin: looks like someone on that bug made a mmiotrace
15:49imirkin: however no one has spent time analyzing it (except the user who created it)
15:49imirkin: basically one would have to compare what it does to what nouveau does
15:49imirkin: and see where nouveau goes wrong
15:49karolherbst: what issue?
15:49karolherbst: link above
15:50karolherbst: silly me
15:50imirkin: karolherbst: modesetting fail on the 1280x800 internal panel on laptops with NV67/NV68
15:50imirkin: (which are nv4x derivatives)
15:51imirkin: ajax: the first app i'm aware of that ran into multithreading issues on nouveau was warsow 2.0. this was like a year ago.
15:51karolherbst: the only old nvidia gpu I have is actually too old
15:51imirkin: karolherbst: the issue is specific to those laptops
15:51karolherbst: I am sure my system has enough issues with nouveau already anyway
15:52karolherbst: fx 5200 ultra :3 and ppc, that sounds like a lot of fun
15:52imirkin: i have that ppc sitting next to me
15:53karolherbst: also that 1st gen imac g5?
15:53imirkin: it's a regular g5 ppc with an agp nv34
15:53karolherbst: mine ain't
15:53karolherbst: but I am sure I have such a card somewhere
15:53imirkin: i got things kinda working on it
15:53imirkin: but without docs, it's too much of a mindfuck
15:53karolherbst: well I _think_ mine has the nvidia gpu at least
15:54karolherbst: I could take a look whenever I have some time
15:54imirkin: basically for every operation i have to think "are things getting swapped, and if so, how"
15:54imirkin: i need to write some standalone apps that test things out
15:54imirkin: for each engine
15:55imirkin: but ... my motivation to do things has been on a steady decline
15:55karolherbst: yeah.. I also don't really care about such old systems…
15:55karolherbst: maybe in ten years again
15:56karolherbst: and I have actually more important issues to address :(
15:56imirkin: meh, dunno. i've been thinking of trying to get a libXvMCW plugin lib going for the VPE1 chips
15:58karolherbst: well that makes actually some sense
16:16Sagnik_Sasmal: Anyone on?
16:31Sagnik_Sasmal: I need some help please
16:33Yoshimo: just state your problem and be patient
16:33Sagnik_Sasmal: Okay :)
16:34Sagnik_Sasmal: I thought of installing Ubuntu on my new PC. The monitor has a resolution of 1366x768, that's not included by default in Ubuntu or any other Linux distro. So, I made new modeline. cvt1366 768 60 returned
16:34Sagnik_Sasmal: # 1368x768 @ 60.00 Hz (GTF) hsync: 47.70 kHz; pclk: 85.86 MHz Modeline "1368x768_60.00" 85.86 1368 1440 1584 1800 768 769 772 795 -HSync + Vsync
16:34Sagnik_Sasmal: See the new modeline is 1368 instead of 1366. So, can anyone help me out in making a custom modeline? I've got the hsync, vsync rate of the monitor from the manual itself.
16:34Sagnik_Sasmal: But I got to know from http://superuser.com/questions/981157/writing-xorg-custom-modeline-for-1366x768-with-nvidia-driver that Noveau support 1366x768 resolution
16:36imirkin: Sagnik_Sasmal: are you running on this machine right now?
16:36imirkin: i don't think 1366 is a valid horizontal resolution, normally it's a multiple of 8. dunno.
16:37Sagnik_Sasmal: No, I am running on Windows right now
16:37imirkin: anyways, i can't tell what your problem/question is from your description
16:37Sagnik_Sasmal: But my monitor, model is Samsung S19A300N, has that
16:37Sagnik_Sasmal: Yea. So, how to make a custom modeline
16:37imirkin: is it "please help me use the proprietary nvidia driver"?
16:38imirkin: if so, you're looking for #nvidia, or their support forums.
16:38Sagnik_Sasmal: No, I am using that thread as a refrence
16:38Sagnik_Sasmal: I am looking to either make a custom modeline
16:39Sagnik_Sasmal: And know whether noveau supports 1366x768
16:39imirkin: nothing special about doing that with nouveau vs other drivers
16:39imirkin: nouveau just reads whatever's in the EDID of the monitor
16:39imirkin: it doesn't have special support for any particular resolutions
16:41Sagnik_Sasmal: Can you guys help me in making a custom modeline?
16:43ajax: sure. 'cvt -r <width> <height>'
16:44Sagnik_Sasmal: But it converts 1366x768 to 1368x768
16:45ajax: yeah, so, dirty secret here
16:45ajax: 13x7 is the stupidest fucking resolution ever invented
16:45ajax: one, that's what "720p" displays claim to be. so despite actually having pixel-precise positioning, you still have to upscale.
16:45ajax: because tv vendors are idiots
16:46Sagnik_Sasmal: Any way to get it working with that 1366x768?
16:46ajax: two, all the timing specs for generating modelines are defined in terms of 8-pixel wide character cells
16:46ajax: because apparently we still think DOS is a thing
16:47ajax: (and some gpus even have that limitation in hardware and will reject non-multiple-of-eight widths)
16:47ajax: 1366, you may have noticed, is not divisible by 8
16:47Sagnik_Sasmal: 1368 is
16:47Sagnik_Sasmal: and that's why it gets converted to that
16:47ajax: so just smash the 1368s in the modeline to 1366 and it'll probably work
16:47ajax: (which is what xserver does)
16:47Sagnik_Sasmal: But 1366 works on the same PC when running windows
16:48Sagnik_Sasmal: Can you give me the cmds please?
16:48Sagnik_Sasmal: I am like a n00b when it comes to linux for personal use :(
16:48ajax: what do you mean, the commands.
16:48ajax: cvt -r printed a modeline for you, right?
16:48ajax: use your text editor, find the number 1368, change it to 1366
16:49Sagnik_Sasmal: it'll work?
16:49ajax: it might! i'm not a psychic.
16:50ajax: i'm just telling you what xserver does when trying to make 13x7 work, and what i would try myself.
16:50Sagnik_Sasmal: BTW, are you there on Skype?
16:52ajax: i use it as a calendar, that's about it
16:53Sagnik_Sasmal: BTW, my graphics card is of nVidia, will it be any help?
20:35Manoa: if I have function not implemented when writing to the pstate that meens the driver can't reclock the card ?
20:35Manoa: I have nothing in dmesg
20:37imirkin: which gpu do you have?
20:40Manoa: GF110 NVC8
20:40Manoa: it a evga gtx 580 classified
20:40imirkin: no such thing as fermi2... just fermi. yeah, no reclocking, sorry
20:41imirkin: [i guess one could argue that nvd7/nvd9 are fermi2, but the differences are only in the display engine and the video decoding engine]
20:43mwk: they're Kermi.
20:43imirkin: skeggsb: any opinions on https://bugs.freedesktop.org/show_bug.cgi?id=98149 ?
20:44Manoa: I have a thermi, too, but because it so hot I afraid to put him in the computer
20:44imirkin: skeggsb: i looked through the code, but it's long and confusing and hasn't really changed. my suspicion is that the *order* of something changed, and something's not initialized that it relies on
20:44imirkin: Manoa: is that a GF100?
20:44imirkin: well, while nouveau can't reclock, the boards work at whatever speed they boot to
20:45imirkin: diff boards boot to diff speeds, no great way to predict it
20:45imirkin: on average, high end boards boot to a low perf level, while low-end boards boot to a middle perf level
20:46imirkin: but that's hardly always the case
20:46Manoa: it ok I will wait a while until I reconfigure the cooling system and then I will plug in the radeon 7950, I have many cards xD
20:47imirkin: that 7950 will work much better on many levels
20:47Manoa: it's funny how things turned out that 780 Ti will have reclocking soon but fermies will not
20:48imirkin: amd has invested in creating decent open-source drivers for their hw, while nvidia has not
20:48imirkin: 780ti should reclock ok with the latest nouveau tree just fine (for the most part)
20:48imirkin: as should all keplers
20:49imirkin: (although to be sure some issues will be exposed)
20:50Manoa: well at least with this latest mesa building I got rid of nvidia drivers, now everything open source, wine workx very good, mutch better than before
20:51imirkin: that's ... surprising
20:51imirkin: give it a few days ;)
20:51karolherbst: most likely gallium nine
20:51Manoa: it because of the native directx9 mode
20:51karolherbst: yeah, that one runs pretty smooth
20:51karolherbst: there are some random instabilities though
20:52karolherbst: so you have to expect that your system just freezes for no reason
20:52hermier: for me days was minutes with my new card XD
20:52Manoa: the new 480 radeon ?
20:52imirkin: hermier: remind me which issue you had?
20:53hermier: most probably issues with GDDR5 and instabilities due to kde web rendering
20:53imirkin: ah. kde. right.
20:54Manoa: you know this specific problem exist also in windows 7
20:54Manoa: I had cases where because internet explorer opened web page game crash on start
20:55hermier: well I was able to crash without desktop started, randr enabled
20:56hermier: but with nvidia all is good so far. I have to test with 4.8.1 thought
20:56imirkin: won't be any different...
20:56hermier: well there is one thing I want to test
20:57hermier: there is a change about screen suspend handling I want to test about multihead
20:58hermier: otherwise yes, I don't have illusions after reading the change log ^^