similar to: 5.6-rc3 nouveau failure, 5.6-rc2 OK

Hi After installing Kernel 5.6 I am getting this error: Cannot run in framebuffer mode. Please specify busIDs for all framebuffer devices [ 0.757317] nouveau 0000:05:00.0: NVIDIA GP107 (137000a1) [ 0.869775] nouveau 0000:05:00.0: bios: version 86.07.42.00.4a [ 0.870157] nouveau 0000:05:00.0: acr: failed to load firmware [ 0.870256] nouveau 0000:05:00.0: acr: failed to load firmware [ 0.870356]

Hi After installing Kernel 5.6 I am getting this error: Cannot run in framebuffer mode. Please specify busIDs for all framebuffer devices [ 0.757317] nouveau 0000:05:00.0: NVIDIA GP107 (137000a1) [ 0.869775] nouveau 0000:05:00.0: bios: version 86.07.42.00.4a [ 0.870157] nouveau 0000:05:00.0: acr: failed to load firmware [ 0.870256] nouveau 0000:05:00.0: acr: failed to load firmware [ 0.870356]

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)

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 Tue, 31 Jan 2023 at 09:09, Chris Clayton <chris2553 at googlemail.com> wrote: > > Hi again. > > On 30/01/2023 20:19, Chris Clayton wrote: > > Thanks, Ben. > > <snip> > > >> Hey, > >> > >> This is a complete shot-in-the-dark, as I don't see this behaviour on > >> *any* of my boards. Could you try the attached patch

Ben -- probably the ACR changes in 5.6 don't fall back nicely anymore when there's no firmware? The load shouldn't be failed, just GR disabled... Zeno -- if you grab linux-firmware, it should be all better. Not sure if you're missing it on purpose or by accident. Cheers, -ilia On Fri, Apr 3, 2020 at 11:07 AM Zeno Davatz <zdavatz at gmail.com> wrote: > > Hi >

gp104 refuses to switch to "graphic" mode and show anything past this line: fb0: switching to nouveaufb from EFI VGA Machine is fine, as it I can press Ctrl+Alt+Delete and reboot it normally. 5.5 is OK. 5.6 is broken. Bisecting is kinda painful with miscompilation and init/main.c breakage. BTW do I need all those megabytes of firmware? [ 0.923273] fb0: switching to nouveaufb

Hi, this is ontop of Linus' tree from the 4th (lemme know if I should try the latest) on one of my test boxes: nouveau 0000:01:00.0: vgaarb: deactivate vga console Console: switching to colour dummy device 80x25 nouveau 0000:01:00.0: NVIDIA GT218 (0a8280b1) CE: hpet increased min_delta_ns to 20115 nsec nouveau 0000:01:00.0: bios: version 70.18.49.00.00 nouveau 0000:01:00.0: fb: 1024 MiB DDR3

On Fri, Oct 9, 2020 at 11:35 PM Ondrej Zary <linux at zary.sk> wrote: > > Hello, > I'm testing 5.9.0-rc8 and found that Riva TNT2 stopped working: > [ 0.000000] Linux version 5.9.0-rc8+ (zary at gsql) (gcc (Debian 8.3.0-6) 8.3.0, GNU ld (GNU Binutils for Debian) 2.31.1) #326 SMP Fri Oct 9 22:31:40 CEST 2020 > ... > [ 14.771464] nouveau 0000:01:00.0: GPU not

Hello, I'm testing 5.9.0-rc8 and found that Riva TNT2 stopped working: [ 0.000000] Linux version 5.9.0-rc8+ (zary at gsql) (gcc (Debian 8.3.0-6) 8.3.0, GNU ld (GNU Binutils for Debian) 2.31.1) #326 SMP Fri Oct 9 22:31:40 CEST 2020 ... [ 14.771464] nouveau 0000:01:00.0: GPU not supported on big-endian [ 14.771782] nouveau: probe of 0000:01:00.0 failed with error -38 big-endian? WTF? The

Hi Boris, There was a fixup to that patch that you'll also have to revert first -- 7dbbdd37f2ae7dd4175ba3f86f4335c463b18403. I guess there's some subtle difference between the old open-coded logic and the helper, they were supposed to be identical. Cheers, -ilia On Thu, Jun 18, 2020 at 4:09 PM Borislav Petkov <bp at alien8.de> wrote: > > Hi, > > my test box

Hi, my test box won't boot 5.8-rc1 all the way but stops at ... fb0: switching to nouveaufb from EFI VGA <-- EOF I've bisected it to the commit in $Subject, see below. Unfortunately, it doesn't revert cleanly so I can't really do the final test of reverting it ontop of 5.8-rc1 to confirm that this one is really causing it. Any ideas? GPU is: [ 5.678614] fb0: switching

Hi . I am having a very annoying problem not sure where the root of it lies When running FLdigi it runs fine for about 10 mineuts then i start getting errors leading to a complete lock up that needs a power button to free it up i get the following [ 653.080497] nouveau 0000:01:00.0: fifo: DMA_PUSHER - ch 3 [systemd-logind[462]] get 00000d3a24 [ 653.081461] nouveau 0000:01:00.0: gr:

Hi, I've encountered a severe regression in TU116 (probably also TU117) introduced in 5.3-rc4 (valid also for recent 5.4.2) [1]. The system usually hangs on the subsequent graphic mode related operation (calling xrandr after login is enough) with the following error: > kernel: nouveau 0000:01:00.0: fifo: SCHED_ERROR 08 [] ... > kernel: nouveau 0000:01:00.0: DRM: failed to idle channel

This changes the fb name from "nouveaufb" to "nouveaudrmfb". Aside: I wonder whether the in_interrupt() check is good enough for the nouveau acceleration. Cargo-cult says drm_can_sleep() is needed, which isn't actually working if you pick a .config without PREEMPT. For the generic fbdev defio support we've gone with offloading everything to a worker. For the non-accel

Hi Marcin, You should do a git bisect rather than guessing about commits. I suspect that searching for "kernel git bisect fedora" should prove instructive if you're not sure how to do this. Cheers, -ilia On Mon, Dec 16, 2019 at 11:42 AM Marcin Zaj?czkowski <mszpak at wp.pl> wrote: > > Hi, > > I've encountered a severe regression in TU116 (probably also

The obvious candidate based on a quick scan is 0acf5676dc0ffe0683543a20d5ecbd112af5b8ee -- it merges a fix that messes with PCI stuff, and there lie dragons. You could try building that commit, and if things still work, then I have no idea (and you've narrowed the range). Also I'd recommend ensuring that the good kernel is really good and the bad kernel is really bad -- boot them a few

On 2019-12-16 18:08, Ilia Mirkin wrote: > Hi Marcin, > > You should do a git bisect rather than guessing about commits. I > suspect that searching for "kernel git bisect fedora" should prove > instructive if you're not sure how to do this. Thanks for your suggestion. I realize that I can do it at the Git level and it is the ultimate way to go. However, building the

[big snip] > There is a sysfs attribute called "d3cold_allowed" which can be used > for "blocking" D3cold, so can you please retest using that? > Hey-this is almost certainly not the right place in this thread to respond, but this thread has gotten so deep evolution can't push the subject further to the right, heh. So I'll just respond here. I've been

This changes the fb name from "nouveaufb" to "nouveaudrmfb". Aside: I wonder whether the in_interrupt() check is good enough for the nouveau acceleration. Cargo-cult says drm_can_sleep() is needed, which isn't actually working if you pick a .config without PREEMPT. For the generic fbdev defio support we've gone with offloading everything to a worker. For the non-accel