this by verifying that we actually know that there's a head
> assigned to an ior before allowing it to be inherited through nvif. This
> -should- hopefully fix the WARN_ON on GT218 reported by Borislav.
>
> Signed-off-by: Lyude Paul
> Cc: Borislav Petkov
> ---
> driv
On Wed, Dec 13, 2023 at 12:39:36PM +0100, Borislav Petkov wrote:
> We're getting close to releasing so I guess we either debug this or shut
> up the WARN.
Not only that - panic_on_warn turns this into an explosion so you don't
want that in a released kernel.
--
Regards/Gruss,
On Tue, Dec 12, 2023 at 10:35:51PM -0500, Paul Dufresne wrote:
> https://gitlab.freedesktop.org/drm/nouveau/-/issues/282
Let's add more folks who were involved in
1b477f42285e ("drm/nouveau/kms: Add INHERIT ioctl to nvkm/nvif for reading IOR
state")
Apparently, someone wants to know that the lo
On Sat, Nov 11, 2023 at 01:03:23PM +0100, Borislav Petkov wrote:
> 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 :01:00.0: vgaarb: deactivate vga console
> Console: switching to
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 :01:00.0: vgaarb: deactivate vga console
Console: switching to colour dummy device 80x25
nouveau :01:00.0: NVIDIA GT218 (0a8280b1)
CE: hpet increased min_delta_ns to 2011
On Thu, Aug 17, 2023 at 12:24:45PM +0200, Karol Herbst wrote:
> simply throw a
>
> printk(KERN_WARNING "nvkm_uconn_uevent %u\n", outp->info.location);
>
> inside drivers/gpu/drm/nouveau/nvkm/engine/disp/uconn.c:104 after that
> mentioned comment.
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/
On Thu, Aug 17, 2023 at 12:00:47PM +0200, Karol Herbst wrote:
> btw, what would help is to know where `nvkm_uconn_uevent` actually
> fails, or rather, are you running into this "/* TODO: support DP IRQ
> on ANX9805 and remove this hack. */" condition?
Send me a diff, I'll run it here and catch out
On Thu, Aug 17, 2023 at 01:18:12AM +0200, Karol Herbst wrote:
> do you have one of these? https://en.wikipedia.org/wiki/DMS-59
Ah, DMS == Dual Monitor Solution :-)
Yap, that's exactly what the GPU has. And the Y-cable is 2xDVI. It is
a Dell workstation and it came this way, meaning I haven't done
On Wed, Aug 16, 2023 at 11:27:05PM +0200, Karol Herbst wrote:
> that GPU has only a `DMS-59` connector, is that right?
No clue. How do I figure that out?
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Wed, Aug 16, 2023 at 04:57:28PM +0200, Karol Herbst wrote:
> Do you have any connectors listed in "/sys/class/drm"?
tree /sys/class/drm/
/sys/class/drm/
├── card0 -> ../../devices/pci:00/:00:02.0/:03:00.0/drm/card0
├── renderD128 ->
../../devices/pci:00/:00:02.0/:03:00.
On Wed, Aug 16, 2023 at 11:51:50AM +0200, Karol Herbst wrote:
> Mind sharing your kernel logs with that patch applied? I suspect your
> system boots up but you might just not have the connector available or
> something? It could be that you have one of those GPUs affected by the
> original change a
On Wed, Aug 16, 2023 at 12:11:57PM +0200, Borislav Petkov wrote:
> Does that help?
Btw, note that this is *plain* -rc5, without your patch.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Wed, Aug 16, 2023 at 12:03:44PM +0200, Borislav Petkov wrote:
> On Wed, Aug 16, 2023 at 11:51:50AM +0200, Karol Herbst wrote:
> > Mind sharing your kernel logs with that patch applied? I suspect your
> > system boots up but you might just not have the connector available or
&g
On Wed, Aug 16, 2023 at 11:51:50AM +0200, Karol Herbst wrote:
> Mind sharing your kernel logs with that patch applied? I suspect your
> system boots up but you might just not have the connector available or
> something? It could be that you have one of those GPUs affected by the
> original change a
On Mon, Aug 14, 2023 at 04:49:32PM +0200, Karol Herbst wrote:
> We can't simply free the connector after calling drm_connector_init on it.
> We need to clean up the drm side first.
>
> It might not fix all regressions from 2b5d1c29f6c4 ("drm/nouveau/disp:
> PIOR DP uses GPIO for HPD, not PMGR AUX
On Tue, Aug 08, 2023 at 12:39:32PM +0200, Karol Herbst wrote:
> ahh, that would have been good to know :)
Yeah, I didn't see it before - it would only freeze. Only after I added
the printk you requested.
> Mind figuring out what's exactly NULL inside nvif_object_mthd? Or
> rather what line `nvif_
On Mon, Aug 07, 2023 at 01:49:42PM +0200, Karol Herbst wrote:
> in what way does it stop? Just not progressing? That would be kinda
> concerning. Mind tracing with what arguments `nvkm_uevent_add` is
> called with and without that patch?
Well, me dumping those args I guess made the box not freeze
Hi folks,
the patch in $Subject breaks booting here on one of my test boxes, see
below.
Reverting it ontop of -rc4 fixes the issue.
Thx.
[3.580535] ACPI: \_PR_.CP04: Found 4 idle states
[3.585694] ACPI: \_PR_.CP05: Found 4 idle states
[3.590852] ACPI: \_PR_.CP06: Found 4 idle states
+ nouveau@lists.freedesktop.org
On Wed, Dec 02, 2020 at 10:32:57AM +, Capek Pavel wrote:
> Dear kernel maintainers,
>
> After upgrading Fedora from 31 to 32 I try to deal with frequent and
> substantial slowing down of the OS. The computer does not react at random
> when I move a mouse or I
On Thu, Jun 18, 2020 at 10:39:07PM +0200, Borislav Petkov wrote:
> I'll redo the bisection tomorrow, on a fresh head, to check.
Ok, just did it again, similar bisection log, points at the same commit.
The commit before it:
fb172f5fe880 ("drm/nouveau/gr/gk20a: move MODULE_FIRM
Hi,
On Thu, Jun 18, 2020 at 04:19:02PM -0400, Ilia Mirkin wrote:
> 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 we
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 th
On Sun, Mar 24, 2013 at 10:00:55PM +0400, Lijo Antony wrote:
> Looks like this has been fixed in -rc4.
Yep, it seems so here too.
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
___
Nouveau mailing lis
On Wed, Mar 20, 2013 at 07:23:19PM +0400, Lijo Antony wrote:
> # bad: [fffddfd6c8e0c10c42c6e2cc54ba880fcc36ebbb] Merge branch
> 'drm-next' of git://people.freedesktop.org/~airlied/linux
> git bisect bad fffddfd6c8e0c10c42c6e2cc54ba880fcc36ebbb
This is a merge commit which means something went wron
On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote:
> Dropping Tegra ML, it's not the place where Nouveau mails should go.
> Adding Nouveau ML and Maarten, who probably knows Lockdep+Nouveau best.
Ok,
with the hope of having the right people on CC now (finally, thanks
Lucas :-)), here's
On Wed, Mar 06, 2013 at 12:31:49PM -0700, Stephen Warren wrote:
> get_maintainer.pl could always look at file contents IIRC. The change
> was that I added keyword "tegra" to the Tegra section that now matches
> this file's contents.
>
> ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau
>
> .
On Wed, Mar 06, 2013 at 08:14:18PM +0100, Marcin Slusarz wrote:
> On Wed, Mar 06, 2013 at 01:04:29AM +0100, Borislav Petkov wrote:
> > On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote:
> > > Dropping Tegra ML, it's not the place where Nouveau mails should g
On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote:
> Dropping Tegra ML, it's not the place where Nouveau mails should go.
$ ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau/nv50_display.c
...
linux-te...@vger.kernel.org (open list:TEGRA SUPPORT)
Maybe get_maintainer.pl patterns ne
28 matches
Mail list logo
