similar to: [Bug 79971] New: 3.15.0-11819-gc1fdb2d: oops

Whatever the problem was, kernel 3.15.0-rc5 fixed it. I am not in a position to do a git bisect at present. Regards Sid. On 02/05/14 18:17, nouveau-request at lists.freedesktop.org wrote: > Subject: [Nouveau] Problem with kernels 3.15.0-rc and GF114 [GeForce > GTX 560 Ti] (rev a1) > Message-ID:<53638FA1.6020200 at blueyonder.co.uk> > Content-Type: text/plain;

On the slipstream box I have no problems with 3.14.0 kernel. With 3.15.0-rc kernels, in KDE some applications fail to start - e.g kmix, some like thunderbird come up but are not usable, e.g clicking to display a message text, nothing happens and sometimes screens won't switch. slipstream:~ # lspci 01:00.0 VGA compatible controller: NVIDIA Corporation GF114 [GeForce GTX 560 Ti] (rev a1)

First off, the current state of support for Maxwell (GM107/NV110) is not very useful to end-users. It's especially not useful if it's a 3d accelerator card without outputs (as yours appears to be), since acceleration is not supported in 3.15 out of the box. You'd have to figure out how to extract the context switching firmware from the blob driver and load it in nouveau. I'm told

+1 to bumping cmake version and cleaning build system somewhat. On Tue, Oct 29, 2019 at 8:23 PM Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 10/29/2019 10:10 AM, Chris Bieneman via llvm-dev wrote: > > At the LLVM Developer Meeting on October 23rd we held a CMake roundtable. One of the items we discussed was adopting a more regular timeline for CMake

Neil Nelson wrote: > When I was managing IT and the servers for a small company that > needed to be live 24/7 we used the latest Ubuntu LTS version > because we needed rock-solid performance as best we could get. > The software in the LTS version is tested and used by a large > user base with necessary updates and so we expected to have high > reliability. I used to work for

Yes, you are right - the Intel-chip is connected to the display, it just offloads 3D work to do to the nVidia-chip, which isn't even to tell how to get the EDID. I just wanted to try it out, simply for two reasons: 1. I heard that nouveau now "supports" the chip, and since I got the hardware, I wanted to try it out - just for the fun of it. :) 2. As far as I am informed, a way to

I am sure quite a number of packages not supported in the distribution are easy to build and install into /usr/local/bin and such. It is not that it is easy to defeat the standard distribution and update procedures as that doing so puts that software out of sync with the standard update procedure. From then on the distribution update for cmake has no effect. I suspect there are fairly rigid

On Sun, Nov 3, 2019 at 7:20 PM Neil Nelson via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Glad we are getting some reasonable justifications for CMake 3.15.0. There > are two points we may be missing. > > Is our plan to just keep updating to the most recent CMake version or will > our objectives be reached with this version? If we gain what we need with > this version

At the LLVM Developer Meeting on October 23rd we held a CMake roundtable. One of the items we discussed was adopting a more regular timeline for CMake upgrades. During the roundtable there was overwhelming support for upgrading CMake, and support for treating CMake differently than how we treat upgrading host compilers. Historically we've taken into account recent versions of Visual Studio,

On Tue, Oct 29, 2019 at 8:40 PM David Blaikie <dblaikie at gmail.com> wrote: > > > > On Tue, Oct 29, 2019 at 10:28 AM Roman Lebedev via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> +1 to bumping cmake version and cleaning build system somewhat. >> >> On Tue, Oct 29, 2019 at 8:23 PM Tom Stellard via llvm-dev >> <llvm-dev at

CMake doesn’t have the ability to reliably re-invoke itself in a way that would make that workflow reasonable. To do it would require a meta build system for our meta build system, and that is the road to madness. -Chris > On Nov 4, 2019, at 8:59 AM, Stephen Neuendorffer via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >  > > Since it's 'so easy', I wonder

On Tue, Oct 29, 2019 at 12:48 PM Jean-Daniel via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > Le 29 oct. 2019 à 19:00, Roman Lebedev via llvm-dev < > llvm-dev at lists.llvm.org> a écrit : > > On Tue, Oct 29, 2019 at 8:40 PM David Blaikie <dblaikie at gmail.com> wrote: > > > > > On Tue, Oct 29, 2019 at 10:28 AM Roman Lebedev via llvm-dev

> On Oct 30, 2019, at 12:02 PM, Andrew Kelley via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Here's an argument for why to *lower* the minimum supported CMake version: No offense, but that isn't going to happen. > > LLVM is a compiler backend. LLVM is *much* more than a compiler backend. Using LLVM as a compiler backend is one use of LLVM. It is also a JIT

Hello, guys. First apologize my flaws, I am not a native English speaker and thus am prone to stupid errors. My box is an ASUSTek Notebook with Optimus capability (no, this is NOT about Optimus, I don't try to use Optimus yet, so please don't switch off here) with a running Gentoo. The first GPU is an Haswell-based Intel chip, the second one is a nVidia GeForce GTX 850M, the chip is a

On Tue, Oct 29, 2019 at 3:29 PM James Y Knight via llvm-dev < llvm-dev at lists.llvm.org> wrote: > CMake is extremely easy for developers to download and build locally -- or > just download binaries for if you like, too. > Is there any script we can/would provide to help with this? Or is it so simple that two lines in the "getting started" instructions would be enough?

I'm not sure what benefit that would provide. For most developers they already have configured build directories and if their CMake is too old they are going to do a `git pull` and all of a sudden their build fails to configure. Then they go fetch a new CMake. Not sure a bootstrap script really helps with that. Especially since the CMake git repository contains one, and many people might

Hi Neil, I'm really not sure what you're getting at. Are you objecting to the proposal to update? The LLVM community operates by having request-for-comment (RFC) discussion threads to coalesce around a plan, then just moving forward. There is no formal argument or proposal needed. We also don't really have an official policy regarding updating CMake. In your other emails on the

Using fsdlm/ocfs2_controld.cman, I've rerun the test I've been having problems with on 2.6.30-rc1. After running for several minutes in the same directory on three nodes, the test hangs, and I collect the following information: bull-01 ------- 3053 S< [ocfs2dc] ocfs2_downconvert_thread 3054 S< [dlm_astd] dlm_astd 3055 S< [dlm_scand]

If init doesn't run then disp->outp might not be initialized, resulting in an oops. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/base.c b/drivers/gpu/drm/nouveau/core/engine/disp/base.c index c41f656abe64..9c38c5e40500 100644 --- a/drivers/gpu/drm/nouveau/core/engine/disp/base.c +++

On 15.09.2014 15:36, Ilia Mirkin wrote: > On Mon, Sep 15, 2014 at 4:23 AM, poma <pomidorabelisima at gmail.com> wrote: >> Chipset: G98 (NV98) >> Family : NV50 >> >> >> WORKING VIDEO RESUME(S3) >> >> 3.15.0-rc8.1.git.7a014a8 >> 3.15.0-rc8.2.git.456b057 >> 3.15.0-rc8.3.git.b8407c9 >> 3.15.0-rc8.4.git.bb7ef1e >> >>