Re: Nouveau on a RISC-V SBC with Tesla K80? Supposed to not work or yes?

[Ilia Mirkin]

I don't think anyone was ever able to get their hands on a K80 to
confirm. It's a different ID than the GK110 (0xf0) / GK110B (0xf1). I
believe it's referred to as a GK210, but not sure if that's just a
marketing thing or if it's actually different.

You can try copying the 0xf1 entry in devinit and seeing what happens.

https://cgit.freedesktop.org/drm/drm/tree/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c#n3284

i.e. just add "case 0xf2: device->chip = _chipset; break;"

However it does seem somewhat likely there would be additional
differences, so I wouldn't be extremely surprised if it didn't come up
without at least some extracted firmware (which we've never done for
that chipset).

Cheers,

  -ilia

On Fri, Apr 19, 2024 at 11:14 AM Raymond Wong  wrote:
>
> NOUVEAU MESSAGE :  {
> [ 47.314360] nouveau 0001:03:00.0: enabling device ( -> 0002)
>
> [ 47.314452] nouveau 0001:03:00.0: unknown chipset (0f22d0a1) [ 47.323897]
>
> pci 0001:02:10.0: enabling device ( -> 0002) [ 47.323938] nouveau 
> 0001:04:00.0: enabling device ( -> 0002)
>
> [ 47.324095] nouveau 0001:04:00.0: unknown chipset (0f22d0a1)
> }
>
> CONTEXT : {
> This thing belongs to someone else, but I'm playing with it. It is a 
> VisionFive 2 (a third one). It would seem like the PCIe implementation in 
> there is missing something that Navi 2s and 3s want. Therefore some Polaris 
> cards and Kepler cards are probably the best GPUs this SBC can run.
> Of course, it is two GPUs on a single PCIe 2.0 x1 lane using a riser. I see 
> that the Tesla K80 has it's own suspiciously incomplete line in the CodeNames 
> section. But nouveau reports unknown chipset when attempting to load drivers 
> onto the GPUs. Maybe it doesn't have the configuration for a Tesla K80 after 
> all?
> However, given Fishwaldo's 5.15.131 kernel is running on the SBC, I wonder if 
> Tesla K80 support has been added somewhere, But my roommates (myself 
> included) are combined all just too noob at googling to find it.
> }
>
> SYSTEM : {
> Board : VisionFive 2
> Kernel : 5.15.131 Fishwaldo using pine64-star64_defconfig
> Nouveau enabled using scripts/config -m CONFIG_DRM_NOUVEAU
> GPU : Tesla K80 dual GPU wanting to use nouveau drivers. One PCIe 2.0 x1 link 
> connects both GPUs.
> OS : Slackware ARM RISC-V (Full system, 16GB installed)
> Notes : It would appear that a GTX 750 Ti worked on another VisionFive 2, as 
> did a RX 550 on my Star64.
> }

Re: [Nouveau] Kernel problem with multiseat on one card

[Ilia Mirkin]

On Sat, Dec 2, 2023 at 8:18 AM Bagas Sanjaya  wrote:
>
> On Thu, Nov 30, 2023 at 11:48:24AM +0100, Gert Vanhaerents wrote:
> > Hi Kernel list,
> > I'm the IT person of a school, earlier we used multiseatcomputers for the
> > school, i have maded with a XGL implementation and it works fine but not so
> > fantastic. The school wants that i build new computers but the XGL project
> > is too outdated so i can't use it anymore.
> >
> > How can i make a multiseatcomputer with more then one user on one card with
> > systemd? I have asked already to the makers of systemd but they said it's a
> > kernel problem.
> >
> > With Systemd loginctl and the nouveau drivers you have this:
> >
> > ─/sys/devices/pci:00/:00:03.1/:08:00.0/drm/card0
> >   │ [MASTER] drm:card0
> >   │
> > ├─/sys/devices/pci:00/:00:03.1/:08:00.0/drm/card0/card0-DVI-D-1
> >   │ │ [MASTER] drm:card0-DVI-D-1
> >   │
> > ├─/sys/devices/pci:00/:00:03.1/:08:00.0/drm/card0/card0-HDMI-A-1
> >   │ │ [MASTER] drm:card0-HDMI-A-1
> >   │
> > └─/sys/devices/pci:00/:00:03.1/:08:00.0/drm/card0/card0-VGA-1
> >   │   [MASTER] drm:card0-VGA-1
> > ├─/sys/devices/pci:00/:00:03.1/:08:00.0/drm/renderD128
> >   │ drm:renderD128
> > ├─/sys/devices/pci:00/:00:03.1/:08:00.0/graphics/fb0
> >   │ graphics:fb0 "nouveaudrmfb"
> >
> > So it will be:
> >
> > loginctl attach seat1 
> > /sys/devices/pci:00/:00:03.1/:08:00.0/drm/card0/card0-VGA-1
> >
> > For the seat1 (the VGA d-sub output for seat1 and the other HDMI output for
> > seat0) and of course the mouse and keyboard.
> >
> > When you do this, all the graphics outputs are on the second seat (seat1)
> > and not anymore on the first seat. So i need to move only the VGA output to
> > seat1 and not all the outputs.

(Note: I know nothing about multiseat, but I know something about nouveau.)

What GPU is this? The fact that VGA is listed makes me think it's an
older one. Pre-Kepler GPUs only support 2 CRTC's, which means you can
only have 2 outputs enabled at a time -- this is a hardware
limitation. So if this is a GFxxx or GTxxx in "lspci" (or even older,
Gxx or NVxx), then this will never work with 3 outputs / seats.

Also, I notice that you have a "fb" driver going, whose sole task is
to display the same thing on all outputs. I don't know how this
interacts with multiseat, but basically you have to ensure that you're
in "graphics" mode, which I think makes it effectively disabled. But
I've never used systemd, so I'm not completely sure how that
interaction is brokered.

Cheers,

  -ilia

Re: [PATCH 1/6] drm/nouveau: convert to using is_hdmi and has_audio from display info

[Ilia Mirkin]

On Fri, Jan 12, 2024 at 11:50 AM Jani Nikula  wrote:
>
> Prefer the parsed results for is_hdmi and has_audio in display info over
> calling drm_detect_hdmi_monitor() and drm_detect_monitor_audio(),
> respectively.
>
> Conveniently, this also removes the need to use edid_blob_ptr.
>
> Cc: Karol Herbst 
> Cc: Lyude Paul 
> Cc: Danilo Krummrich 
> Cc: nouveau@lists.freedesktop.org
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/nouveau/dispnv50/disp.c | 8 
>  drivers/gpu/drm/nouveau/dispnv50/head.c | 8 +---
>  drivers/gpu/drm/nouveau/nouveau_connector.c | 2 +-
>  3 files changed, 6 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index 8d37a694b772..908b1042669c 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -750,7 +750,7 @@ nv50_audio_enable(struct drm_encoder *encoder, struct 
> nouveau_crtc *nv_crtc,
> struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
> struct nvif_outp *outp = _encoder->outp;
>
> -   if (!nv50_audio_supported(encoder) || 
> !drm_detect_monitor_audio(nv_connector->edid))
> +   if (!nv50_audio_supported(encoder) || 
> !nv_connector->base.display_info.has_audio)
> return;
>
> mutex_lock(>audio.lock);
> @@ -1764,7 +1764,7 @@ nv50_sor_atomic_enable(struct drm_encoder *encoder, 
> struct drm_atomic_state *sta
> if ((disp->disp->object.oclass == GT214_DISP ||
>  disp->disp->object.oclass >= GF110_DISP) &&
> nv_encoder->dcb->type != DCB_OUTPUT_LVDS &&
> -   drm_detect_monitor_audio(nv_connector->edid))
> +   nv_connector->base.display_info.has_audio)
> hda = true;
>
> if (!nvif_outp_acquired(outp))
> @@ -1773,7 +1773,7 @@ nv50_sor_atomic_enable(struct drm_encoder *encoder, 
> struct drm_atomic_state *sta
> switch (nv_encoder->dcb->type) {
> case DCB_OUTPUT_TMDS:
> if (disp->disp->object.oclass != NV50_DISP &&
> -   drm_detect_hdmi_monitor(nv_connector->edid))
> +   !nv_connector->base.display_info.is_hdmi)

This is backwards, no?

> nv50_hdmi_enable(encoder, nv_crtc, nv_connector, 
> state, mode, hda);
>
> if (nv_encoder->outp.or.link & 1) {
> @@ -1786,7 +1786,7 @@ nv50_sor_atomic_enable(struct drm_encoder *encoder, 
> struct drm_atomic_state *sta
>  */
> if (mode->clock >= 165000 &&
> nv_encoder->dcb->duallink_possible &&
> -   !drm_detect_hdmi_monitor(nv_connector->edid))
> +   !nv_connector->base.display_info.is_hdmi)
> proto = 
> NV507D_SOR_SET_CONTROL_PROTOCOL_DUAL_TMDS;
> } else {
> proto = NV507D_SOR_SET_CONTROL_PROTOCOL_SINGLE_TMDS_B;
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/head.c 
> b/drivers/gpu/drm/nouveau/dispnv50/head.c
> index 83355dbc15ee..d7c74cc43ba5 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/head.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/head.c
> @@ -127,14 +127,8 @@ nv50_head_atomic_check_view(struct nv50_head_atom *armh,
> struct drm_display_mode *omode = >state.adjusted_mode;
> struct drm_display_mode *umode = >state.mode;
> int mode = asyc->scaler.mode;
> -   struct edid *edid;
> int umode_vdisplay, omode_hdisplay, omode_vdisplay;
>
> -   if (connector->edid_blob_ptr)
> -   edid = (struct edid *)connector->edid_blob_ptr->data;
> -   else
> -   edid = NULL;
> -
> if (!asyc->scaler.full) {
> if (mode == DRM_MODE_SCALE_NONE)
> omode = umode;
> @@ -162,7 +156,7 @@ nv50_head_atomic_check_view(struct nv50_head_atom *armh,
>  */
> if ((asyc->scaler.underscan.mode == UNDERSCAN_ON ||
> (asyc->scaler.underscan.mode == UNDERSCAN_AUTO &&
> -drm_detect_hdmi_monitor(edid {
> +connector->display_info.is_hdmi))) {
> u32 bX = asyc->scaler.underscan.hborder;
> u32 bY = asyc->scaler.underscan.vborder;
> u32 r = (asyh->view.oH << 19) / asyh->view.oW;
> diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c 
> b/drivers/gpu/drm/nouveau/nouveau_connector.c
> index 856b3ef5edb8..938832a6af15 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_connector.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
> @@ -1034,7 +1034,7 @@ get_tmds_link_bandwidth(struct drm_connector *connector)
> unsigned duallink_scale =
> nouveau_duallink && nv_encoder->dcb->duallink_possible ? 2 : 
> 1;
>
> -   if (drm_detect_hdmi_monitor(nv_connector->edid)) {
> +   if (nv_connector->base.display_info.is_hdmi) {
> info = 

Re: [Nouveau] PR: nv50 IB-mode DMA crash fixes

[Ilia Mirkin]

On Mon, Dec 4, 2023 at 11:04 AM Ilia Mirkin  wrote:
>
> On Sun, Dec 3, 2023 at 11:37 AM Monty Montgomery  wrote:
> > 1) The nv50 DMA code clearly believed push buffers could not (or
> > should not) exceed NV50_DMA_PUSH_MAX_LENGTH, when my analysis logging
> > shows that they regularly exceed this maximum by an order of magnitude
> > or more.  Was the assumption originally true?  If so, when/why did it
> > change?  Is the more correct fix to enforce individual pushbuf size
> > limits?
>
> The BO itself can be artibrarily sized. However the length stored in
> the ring only has so many bits, so that provides a natural maximum.
>
> https://envytools.readthedocs.io/en/latest/hw/fifo/dma-pusher.html#ib-mode
>
> This might be different on newer gens though.

Oh, but that said, the way we pass the NO_PREFETCH flag through *is*
by bumping the length -- IIRC the uapi doesn't have an explicit
setting for it.

e.g. see 
https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw.c#n477

This is the API for libdrm_nouveau, but I seem to recall it's largely
just passed through.

Cheers,

  -ilia

Re: [Nouveau] PR: nv50 IB-mode DMA crash fixes

[Ilia Mirkin]

On Sun, Dec 3, 2023 at 11:37 AM Monty Montgomery  wrote:
> 1) The nv50 DMA code clearly believed push buffers could not (or
> should not) exceed NV50_DMA_PUSH_MAX_LENGTH, when my analysis logging
> shows that they regularly exceed this maximum by an order of magnitude
> or more.  Was the assumption originally true?  If so, when/why did it
> change?  Is the more correct fix to enforce individual pushbuf size
> limits?

The BO itself can be artibrarily sized. However the length stored in
the ring only has so many bits, so that provides a natural maximum.

https://envytools.readthedocs.io/en/latest/hw/fifo/dma-pusher.html#ib-mode

This might be different on newer gens though.

Cheers,

  -ilia

Re: [Nouveau] [PATCH v2] drm/nouveau: bring back blit subchannel for pre nv50 GPUs

[Ilia Mirkin]

On Fri, May 26, 2023 at 5:11 AM Karol Herbst  wrote:
>
> 1ba6113a90a0 removed a lot of the kernel GPU channel, but method 0x128
> was important as otherwise the GPU spams us with `CACHE_ERROR` messages.
>
> We use the blit subchannel inside our vblank handling, so we should keep
> at least this part.
>
> v2: Only do it for NV11+ GPUs
>
> Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/201
> Fixes: 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers")
> Signed-off-by: Karol Herbst 
> ---
>  drivers/gpu/drm/nouveau/nouveau_chan.c |  1 +
>  drivers/gpu/drm/nouveau/nouveau_chan.h |  1 +
>  drivers/gpu/drm/nouveau/nouveau_drm.c  | 20 +---
>  3 files changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.c 
> b/drivers/gpu/drm/nouveau/nouveau_chan.c
> index e648ecd0c1a0..3dfbc374478e 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_chan.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_chan.c
> @@ -90,6 +90,7 @@ nouveau_channel_del(struct nouveau_channel **pchan)
> if (cli)
> nouveau_svmm_part(chan->vmm->svmm, chan->inst);
>
> +   nvif_object_dtor(>blit);
> nvif_object_dtor(>nvsw);
> nvif_object_dtor(>gart);
> nvif_object_dtor(>vram);
> diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.h 
> b/drivers/gpu/drm/nouveau/nouveau_chan.h
> index e06a8ffed31a..bad7466bd0d5 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_chan.h
> +++ b/drivers/gpu/drm/nouveau/nouveau_chan.h
> @@ -53,6 +53,7 @@ struct nouveau_channel {
> u32 user_put;
>
> struct nvif_object user;
> +   struct nvif_object blit;
>
> struct nvif_event kill;
> atomic_t killed;
> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
> b/drivers/gpu/drm/nouveau/nouveau_drm.c
> index cc7c5b4a05fd..9512f1c2f871 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
> @@ -369,15 +369,29 @@ nouveau_accel_gr_init(struct nouveau_drm *drm)
> ret = nvif_object_ctor(>channel->user, "drmNvsw",
>NVDRM_NVSW, nouveau_abi16_swclass(drm),
>NULL, 0, >channel->nvsw);
> +
> +   if (ret == 0 && device->info.chipset >= 0x11) {

Can you double-check that this is needed on NV15? IIRC there's some
non-linearity of chipsets here which is why we had (some long time
ago, not sure if it's still there), a chip class which would simplify
such checks.

Cheers,

  -ilia

Re: [Nouveau] TV Out question

[Ilia Mirkin]

On Fri, Nov 4, 2022 at 12:56 PM Lukas Satin  wrote:
>
> Hello, sorry fo the typos. Wanted to catch you before the weekend, to get 
> some hints for upcoming work.
>
> I'm back at PC.
>
> Does your driver support switching to 240p in NTSC and 288p in PAL on the go 
> via xrandr, for example?
>
> If not, can I find some relevant part of code in your repository where to 
> implement that?

https://cgit.freedesktop.org/drm/drm/tree/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
+ tvmodesnv17.c

There's definitely a lot of hard-coding going on. A lot of the
pre-nv50 display code is from This code is (likely) originally from
https://cgit.freedesktop.org/xorg/driver/xf86-video-nv/tree/src but I
can't immediately find the TV code in there. But perhaps it's there
anyways, I only spent about 30s looking for it.

I don't remember by now, but there _might_ be a kms property (which
should get piped through to xrandr properties) which allows you to
change this live?

> Some info I found regarding 240p and that it is a part of NTSC: 
> https://en.wikipedia.org/wiki/Low-definition_television
>
> TV with S-Video mostly supports 480i and 240p as well. So the current issue 
> is outputting that via TV out.
>
> My current configuration looks like this:
> TV-1 connected 240x224+0+0 (normal left inverted right x axis y axis) 0mm x 
> 0mm
>720x480   59.94 +
>1024x768  59.94
>800x600   59.94
>720x576   59.94
>640x480   59.94
>400x300   59.94
>320x240   59.93
>320x200   59.94
>768x576   50.00
>360x200   60.00
>360x240   60.00
>640x240   60.00
>SR-1_240x224@60.10  60.10*
>
> I see I have created 240x224 (I need to fix that), but even 320x240 does not 
> work. It always stays at 480i.

Did you try 360x240? I have no idea though, sorry. I was just happy
when the S-Video worked at all. It could require further modifications
to how we configure those registers.

Re: [Nouveau] TV Out question

[Ilia Mirkin]

https://nouveau.freedesktop.org/KernelModuleParameters.html

Perhaps nouveau.tv_norm=NTSC-M will help get you the 60hz modes? I
haven't played with these options much at all, it has always sorta
Just Worked for me.

This should have the validation of new modes, make sure you don't run
afoul of this:

https://cgit.freedesktop.org/drm/drm/tree/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c#n303

Cheers,

  -ilia

On Thu, Nov 3, 2022 at 10:56 PM Lukas Satin  wrote:
>
> Hi, I am currently testing Batocera Linux for retrogaming with 15KHz output 
> on CRT / TV.
>
> The machine I discovered is a certified Windows Media Center / Intel ViiV 
> machine: Acer iDEA 510
>
> It features:
> RCA component output
> S-Video CVBS output
> S-Video DIN output
> Scart IN / Scart OUT (two DVB-T tuners for realtime playback and recording)
> DVI-I out
> HDMI out
>
> Laptop style components, MXM module Geforce 7 Go 7600 (NVIDIA Curie).
>
> Now, BIOS default output via RCA component is 640x480 NTSC (480i, 60Hz). In 
> Windows I can switch between NTSC and PAL (480i or 576i).
>
> As this is EU machine, after BIOS it often defaults to 576i PAL, unless set 
> otherwise.
>
> Now your nouveau driver therefore defaults to 576i.
>
> Xrandr looks like this:
> TV-1 connected 640x480+0+0 (normal left inverted right x axis y axis) 0mm x 
> 0mm
>720x576   50.00 +
>1024x768  50.00
>800x600   50.00
>720x480   50.00
>640x480   50.00*
>400x300   50.00
>320x240   50.00
>320x200   50.00
>768x576   50.00
>360x200   60.00
>360x240   60.00
>640x240   60.00
>
> I tried to add some additional modelines. But look at 640x480. It forces 50Hz 
> and I am unable to remove it, create new or change it to 60Hz. Therefore the 
> TV is always set to 576i and screen output is 640x480, therefore it looks 
> like GPU scaled. First I read your troubleshooting which mentions scaling, so 
> I tried to disable scaling. Did not help.
>
> Now I read about this:
> https://nvidia.custhelp.com/app/answers/detail/a_id/177/~/linux---configuring-tv-out
>
> And this might be the solution and issue. It would correspond with what can 
> be observed in Windows 7.
>
> Does your driver have some options for configuring TV Out and name switching 
> from PAL to NTSC or HD480i mode? It should be automatic based on 480i or 576i 
> or 240p or 288p, but it is not.
>
> Thanks,
> Lukas

Re: [Nouveau] Hardware decoding in video playback with Nvidia GT 218 (NVA8)

[Ilia Mirkin]

Hi Joe,

On Sun, May 29, 2022 at 6:58 PM Joe  wrote:
>
> Hi all, I'm trying to make running hardware acceleration decoding on
> my old GeForce 210 (AKA GT-218, or NVA8 / NV-50 Tesla family).
> --
> 02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218
> [GeForce 210] [10de:0a65] (rev a2)
> --
> [ ... ]
>
> But when I touch something, for instance "f" to enlarge to fullscreen,
> or "q" to quit MPV...
> Surprise!
>
> My system freeze, nothing work again, just the mouse cursor can still
> be moved around.
>
> [ ... ]
>
> I'd like to use open drivers, but I'd like to take advantage of
> hardware decoding too, so that my CPU rests as quiet and fresh as
> possible. Is there some other suggest to configure some other aspect
> and try to achieve my scope?
> Or my tests are all I can do?
> So for hwdec is better to switch back to closed source nvidia driver
> legacy 340.108 ?

Proprietary driver will definitely work better for hwdec than nouveau.
Forgetting about any stability/performance issues, there are some
reference frame ordering issues in H.264 decoding that were never
addressed. This leads to occasional corruption in some videos.

FWIW I've mostly tested with mplayer, and I didn't run into problems
there. There should be instructions on using mplayer at
https://nouveau.freedesktop.org/VideoAcceleration.html. The thing you
esp want to avoid is using VDPAU + GL in the same process -- so things
like "-vo vdpau" are much more likely to work than "-vo gpu" or "-vo
gl". You can try enabling DRI3 -- perhaps something broke in the DRI2
paths. You can add

Option "DRI" "3"

into the Driver section of the xorg.conf to expose it. It's not on by
default because there are some annoying corner cases that some window
managers run into with it (KDE as I recall).

I'm also not sure why VA-API is corrupted for you, it has worked in
the past. But it gets a lot of changes only reviewed by AMD
developers, so it can get broken pretty easily with AMD-specific
assumptions which don't hold on NVIDIA. I suspect it should be easy to
fix by someone who is interested in investigating -- probably a bisect
to sort out what broke it, and then revert or get the person who wrote
it to fix it.

Cheers,

  -ilia

Re: [Nouveau] Nvidia GK106GLM (Quadro K2100M) with Nouveau

[Ilia Mirkin]

On Tue, Mar 15, 2022 at 6:10 AM Martin Knoblauch  wrote:
>
> On Tue, Mar 15, 2022 at 10:55 AM Martin Knoblauch  wrote:
> >
> > On Mon, Mar 14, 2022 at 10:42 PM Ilia Mirkin  wrote:
> > >
> > > On Mon, Mar 14, 2022 at 5:30 PM Martin Knoblauch  
> > > wrote:
> > > >
> > > > On Mon, Mar 14, 2022 at 7:45 PM Ilia Mirkin  
> > > > wrote:
> > > > >
> > > > > Hi Martin,
> > > > >
> > > > > Depends what your expectations are. Nouveau is missing a number of
> > > > > features of the blob, the most important of which is probably
> > > > > stability. Whether you run into instability or not depends a lot on
> > > > > the software that you use, so you'll just have to find out for
> > > > > yourself if it works well for you or not. Personally, I have
> > > > > multi-month uptimes with it. But others struggle to stay up for an
> > > > > hour.
> > > > >
> > > > > With GK106, you should have manual reclocking, which should enable you
> > > > > to achieve ~50-80% of blob performance, if that's a concern for you.
> > > > > You won't get Vulkan nor H.264 hardware encoding.
> > > > >
> > > > > Cheers,
> > > > >
> > > > >   -ilia
> > > > >
> > > > Hi Ilia,
> > > >
> > > >  most of my expectations would be met, if I were able to get a decent
> > > > resolution from the GK106. As it is the card is not recognized, and it
> > > > falls back to VESA with 1280x1024 which is pathetic. I have not much
> > > > need or expectation on speed.
> > >
> > > That's not normal. Please post logs. Perhaps you have nouveau
> > > blacklisted or something like that? Nouveau should definitely
> > > recognize your card.
> > >
> > >   -ilia
> > Hi Ilia,
> >
> >  thanks for providing the correct clue: "blacklisted". I had removed
> > one blacklist command from /etc/modprobe.d, but the proprietary
> > installer had left another at /usr/lib/modprobe.d. Kicked that out and
> > now I have 1920x1080 and all my stuff is working fine :-)
> >
> > Btw card is recognized as "NVIDIA NVE6". Does that make sense?
> >
> > Cheers
> > Martin
>
> Just for completeness, here the kernel messages with the exception of
> the last four line it looks fine to me:
> L2XQJL32:/etc/X11 # dmesg | egrep -i "nouv|drm"
> [0.622266] ata1.00: supports DRM functions and may not be fully accessible
> [0.626716] ata1.00: supports DRM functions and may not be fully accessible
> [2.449847] ACPI: bus type drm_connector registered
> [2.503983] fb0: switching to nouveau from VESA VGA
> [2.504110] nouveau :01:00.0: vgaarb: deactivate vga console
> [2.504203] nouveau :01:00.0: NVIDIA GK106 (0e63c0a1)
> [2.581231] nouveau :01:00.0: bios: version 80.06.7d.00.06
> [2.581548] nouveau :01:00.0: mxm: BIOS version 3.0
> [2.582662] nouveau :01:00.0: fb: 2048 MiB GDDR5
> [2.649210] nouveau :01:00.0: DRM: VRAM: 2048 MiB
> [2.649213] nouveau :01:00.0: DRM: GART: 1048576 MiB
> [2.649215] nouveau :01:00.0: DRM: TMDS table version 2.0
> [2.649216] nouveau :01:00.0: DRM: DCB version 4.0
> [2.649217] nouveau :01:00.0: DRM: DCB outp 00: 01000f13 00010034
> [2.649218] nouveau :01:00.0: DRM: DCB outp 03: 08015fd6 0f420020
> [2.649219] nouveau :01:00.0: DRM: DCB outp 04: 08015f92 00020020
> [2.649220] nouveau :01:00.0: DRM: DCB outp 05: 08014fc6 0f420010
> [2.649221] nouveau :01:00.0: DRM: DCB outp 06: 08014f82 00020010
> [2.649222] nouveau :01:00.0: DRM: DCB outp 10: 02027fa6 0f420010
> [2.649223] nouveau :01:00.0: DRM: DCB outp 11: 02027f62 00020010
> [2.649224] nouveau :01:00.0: DRM: DCB outp 13: 02049f00 
> [2.649225] nouveau :01:00.0: DRM: DCB conn 00: 0040
> [2.649226] nouveau :01:00.0: DRM: DCB conn 04: 01000446
> [2.649227] nouveau :01:00.0: DRM: DCB conn 05: 02000546
> [2.649227] nouveau :01:00.0: DRM: DCB conn 07: 00010746
> [2.649228] nouveau :01:00.0: DRM: DCB conn 08: 00020847
> [2.649229] nouveau :01:00.0: DRM: DCB conn 09: 0900
> [2.650904] nouveau :01:00.0: DRM: MM: using COPY for buffer copies
> [3.094131] nouveau :01:00.0: DRM: allocated 1920x1080 fb:
> 0xa, bo f4ade0b2
> [3.094272] fbcon: nouveaudrmfb (fb0) is primary device
> [3.870574] nouveau :01:00.0: [drm] 

Re: [Nouveau] Nvidia GK106GLM (Quadro K2100M) with Nouveau

[Ilia Mirkin]

On Mon, Mar 14, 2022 at 5:30 PM Martin Knoblauch  wrote:
>
> On Mon, Mar 14, 2022 at 7:45 PM Ilia Mirkin  wrote:
> >
> > Hi Martin,
> >
> > Depends what your expectations are. Nouveau is missing a number of
> > features of the blob, the most important of which is probably
> > stability. Whether you run into instability or not depends a lot on
> > the software that you use, so you'll just have to find out for
> > yourself if it works well for you or not. Personally, I have
> > multi-month uptimes with it. But others struggle to stay up for an
> > hour.
> >
> > With GK106, you should have manual reclocking, which should enable you
> > to achieve ~50-80% of blob performance, if that's a concern for you.
> > You won't get Vulkan nor H.264 hardware encoding.
> >
> > Cheers,
> >
> >   -ilia
> >
> Hi Ilia,
>
>  most of my expectations would be met, if I were able to get a decent
> resolution from the GK106. As it is the card is not recognized, and it
> falls back to VESA with 1280x1024 which is pathetic. I have not much
> need or expectation on speed.

That's not normal. Please post logs. Perhaps you have nouveau
blacklisted or something like that? Nouveau should definitely
recognize your card.

  -ilia

Re: [Nouveau] Nvidia GK106GLM (Quadro K2100M) with Nouveau

[Ilia Mirkin]

Hi Martin,

Depends what your expectations are. Nouveau is missing a number of
features of the blob, the most important of which is probably
stability. Whether you run into instability or not depends a lot on
the software that you use, so you'll just have to find out for
yourself if it works well for you or not. Personally, I have
multi-month uptimes with it. But others struggle to stay up for an
hour.

With GK106, you should have manual reclocking, which should enable you
to achieve ~50-80% of blob performance, if that's a concern for you.
You won't get Vulkan nor H.264 hardware encoding.

Cheers,

  -ilia

On Mon, Mar 14, 2022 at 11:55 AM Martin Knoblauch  wrote:
>
> Hi,
>
>  for years I have been running my DELL M4800 Laptop under Linux with the 
> proprietary drivers from NV. Finally I am kind of sick of recompiling those 
> drivers every time I upgrade the Kernel.
>
> So, my question is: is there any chance to operate a GK106GLM using 
> nouveau.ko?
>
> Sorry if this has been asked before.
>
> Cheers
> Martin
> --
> --
> Martin Knoblauch
> email: k n o b i AT knobisoft DOT de
> www: http://www.knobisoft.de

Re: [Nouveau] External monitor support for GTX 1650 (NV167/TU117)

[Ilia Mirkin]

Hi Andre,

You're going to be best off filing a bug at
gitlab.freedesktop.org/drm/nouveau with some details of your setup:

1. lspci -nn -d 10de:
2. Your vbios (/sys/kernel/debug/dri/1/vbios.rom)
3. Your monitor's EDID, esp as reported when plugged into nouveau
(/sys/class/drm/card1-HDMI-1/edid or the appropriate connector)
4. dmesg after nouveau is loaded and monitor plugged in

This should allow all the info to be well-contained and accessible to
everyone who needs to see it.

There aren't any currently outstanding known issues that I can think
of that would cause your current situation. But plenty of unknown
ones!

Cheers,

  -ilia

On Fri, Mar 4, 2022 at 7:12 PM Andre Costa  wrote:
>
> Hi there,
>
> I just bought an Acer Nitro 5 (AN515-44) notebook with an AMD Renoir iGPU and 
> a GTX 1650 dGPU. I installed Fedora 35 and, for the most part, it's working 
> great. The only issue so far is that I cannot use Wayland + external monitor 
> with Nouveau -- it does recognize the external monitor, but only renders the 
> top half of the screen, the bottom half remains (literally) blank.
>
> (BTW the HDMI port is wired to the GTX 1650)
>
> For the record, I can use the external monitor just fine with Nvidia's 
> proprietary driver on X11, but I'd rather use Nouveau if possible.
>
> I know support for the NV160 family is still coming up according to the 
> feature matrix, so I'll patiently wait. I just wanted to volunteer to do some 
> testing on this specific setup if this can help in any way. Just let me know.
>
> Keep up the great work!
>
> Cheers,
> Andre

Re: [Nouveau] [PATCH] drm/nouveau/bios: Use HWSQ entry 1 for PowerBook6, 1

[Ilia Mirkin]

I'm not saying this is wrong, but could you file a bug at
gitlab.freedesktop.org/drm/nouveau/-/issues and include the VBIOS
(/sys/kernel/debug/dri/0/vbios.rom)? That would make it easier to
review the full situation.

On Mon, Feb 14, 2022 at 11:03 AM Icenowy Zheng  wrote:
>
> On PowerBook6,1 (PowerBook G4 867 12") HWSQ entry 0 (which is currently
> always used by nouveau) fails, but the BIOS declares 2 HWSQ entries and
> entry 1 works.
>
> Add a quirk to use HWSQ entry 1.
>
> Signed-off-by: Icenowy Zheng 
> ---
>  drivers/gpu/drm/nouveau/nouveau_bios.c | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c 
> b/drivers/gpu/drm/nouveau/nouveau_bios.c
> index e8c445eb11004..2691d0e0cf9f1 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bios.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bios.c
> @@ -1977,6 +1977,13 @@ static int load_nv17_hw_sequencer_ucode(struct 
> drm_device *dev,
> if (!hwsq_offset)
> return 0;
>
> +#ifdef __powerpc__
> +   /* HWSQ entry 0 fails on PowerBook G4 867 12" (Al) */
> +   if (of_machine_is_compatible("PowerBook6,1"))
> +   return load_nv17_hwsq_ucode_entry(dev, bios,
> + hwsq_offset + sz, 1);
> +#endif
> +
> /* always use entry 0? */
> return load_nv17_hwsq_ucode_entry(dev, bios, hwsq_offset + sz, 0);
>  }
> --
> 2.30.2
>

Re: [Nouveau] Off-by-one or bad BIOS image? Apple eMac 800 GeForce 2MX

[Ilia Mirkin]

There's a surprisingly long document at
https://docs.kernel.org/process/submitting-patches.html

But basically make a git commit, make sure the commit message looks
like other commit messages in the area (look at "git log
drivers/gpu/drm/nouveau" for inspiration). Make sure your
Signed-off-by is on there. Then git format-patch the commit, and use
git send-email to send the resulting file to this mailing list +
dri-devel (or any other method of causing the contents of that file to
end up as the email that's sent rather than an attachment).

Cheers,

  -ilia

On Fri, Jan 21, 2022 at 12:07 AM Nick Lopez  wrote:
>
> If it’s correct I’d like to see it make its way upstream. I have no idea what 
> the submission procedure is.
>
>
>
> From: Ilia Mirkin
> Sent: Thursday, January 20, 2022 11:24 AM
> To: Nick Lopez
> Cc: nouveau@lists.freedesktop.org
> Subject: Re: [Nouveau] Off-by-one or bad BIOS image? Apple eMac 800 GeForce 
> 2MX
>
>
>
> This stuff is always so confusing. Let's think this through if
>
> bios size is 4, and we're trying to read a 4-byte thing starting at
>
> address 0, that _ought_ to work, I think. So in my strawman case,
>
> bios->size == 4, and size == 4. So we should only error if size >
>
> bios->size, not if they're ==. Looks like your patch is right.
>
>
>
> Want to make a linux kernel patch submission with this? (i.e.
>
> including changelog, signoff, etc?)
>
>
>
> Cheers,
>
>
>
>   -ilia
>
>
>
> On Thu, Jan 20, 2022 at 1:17 PM Nick Lopez  wrote:
>
> >
>
> > Because I watch too much retro YouTube I decided it was a good idea to try 
> > installing Adelie Linux on my old G4/800 eMac, but the Live installer would 
> > freeze. By blacklisting nouveau I was able to get it booted and manually 
> > installed and, after hours and hours of compiling, get a working kernel 
> > tree to poke at. After only a few iterations with dump_stack() and 
> > nvkm_debug and the output of envytools/nvbios I worked out at the last 
> > initscript instruction was stored in the last byte of the ROM. I think the 
> > bounds check in the nvbios_addr() function is miscalculating the limit as 
> > one byte short, that’s why I was seeing this in the syslog:
>
> >
>
> >
>
> >
>
> > nouveau :00:10.0: bios: OOB 1 07b2 07b2
>
> >
>
> > nouveau :00:10.0: devinit: 0x07b2[ ]: unknown opcode 0x00
>
> >
>
> > nouveau :00:10.0: preinit failed with -22
>
> >
>
> > nouveau: DRM-master::0080: init failed with -22
>
> >
>
> > nouveau :00:10.0: DRM-master: Device allocation failed: -22
>
> >
>
> > nouveau: probe of :00:10.0 failed with error -22
>
> >
>
> >
>
> >
>
> > After I changed the limit check from:
>
> >
>
> > if (unlikely(*addr + size >= bios->size)) {
>
> >
>
> > to:
>
> >
>
> > if (unlikely(*addr + size > bios->size)) {
>
> >
>
> >
>
> >
>
> > it initialized the card properly, brought up the fbconsole and even seems 
> > to be working in X with DRI. So the question is: was the bounds check 
> > wrong, or is the NVDA,BMP image provided by OpenFirmware truncated? I’m 
> > guess this doesn’t turn up elsewhere because the ROM images read through 
> > any of the other methods are the size of flash chip they’re stored on so 
> > there’s always unused space at the end and they never use the last byte 
> > where the NVDA,BMP provided by OpenFirmware is just the active section.
>
> >
>
> >
>
> >
>
> > The patch is against the Adelie easy-kernel patch 5.4 tree, but it looks 
> > like that code is still there in the current upstream torvalds/linux git.
>
>

Re: [Nouveau] Off-by-one or bad BIOS image? Apple eMac 800 GeForce 2MX

[Ilia Mirkin]

This stuff is always so confusing. Let's think this through if
bios size is 4, and we're trying to read a 4-byte thing starting at
address 0, that _ought_ to work, I think. So in my strawman case,
bios->size == 4, and size == 4. So we should only error if size >
bios->size, not if they're ==. Looks like your patch is right.

Want to make a linux kernel patch submission with this? (i.e.
including changelog, signoff, etc?)

Cheers,

  -ilia

On Thu, Jan 20, 2022 at 1:17 PM Nick Lopez  wrote:
>
> Because I watch too much retro YouTube I decided it was a good idea to try 
> installing Adelie Linux on my old G4/800 eMac, but the Live installer would 
> freeze. By blacklisting nouveau I was able to get it booted and manually 
> installed and, after hours and hours of compiling, get a working kernel tree 
> to poke at. After only a few iterations with dump_stack() and nvkm_debug and 
> the output of envytools/nvbios I worked out at the last initscript 
> instruction was stored in the last byte of the ROM. I think the bounds check 
> in the nvbios_addr() function is miscalculating the limit as one byte short, 
> that’s why I was seeing this in the syslog:
>
>
>
> nouveau :00:10.0: bios: OOB 1 07b2 07b2
>
> nouveau :00:10.0: devinit: 0x07b2[ ]: unknown opcode 0x00
>
> nouveau :00:10.0: preinit failed with -22
>
> nouveau: DRM-master::0080: init failed with -22
>
> nouveau :00:10.0: DRM-master: Device allocation failed: -22
>
> nouveau: probe of :00:10.0 failed with error -22
>
>
>
> After I changed the limit check from:
>
> if (unlikely(*addr + size >= bios->size)) {
>
> to:
>
> if (unlikely(*addr + size > bios->size)) {
>
>
>
> it initialized the card properly, brought up the fbconsole and even seems to 
> be working in X with DRI. So the question is: was the bounds check wrong, or 
> is the NVDA,BMP image provided by OpenFirmware truncated? I’m guess this 
> doesn’t turn up elsewhere because the ROM images read through any of the 
> other methods are the size of flash chip they’re stored on so there’s always 
> unused space at the end and they never use the last byte where the NVDA,BMP 
> provided by OpenFirmware is just the active section.
>
>
>
> The patch is against the Adelie easy-kernel patch 5.4 tree, but it looks like 
> that code is still there in the current upstream torvalds/linux git.

Re: [Nouveau] Ubuntu 20.04 and vlc

[Ilia Mirkin]

Hey Jerry,

I'd look in the kernel log to see what's up. Perhaps the GPU hangs?

Cheers,

  -ilia

On Fri, Nov 5, 2021 at 10:42 AM Jerry Geis  wrote:
>
> Hi All,
>
> I am using Ubuntu 20.04 with VLC... normally the box boots up runs an plays 
> videos just fien with about 20% usage for VLC (celeron and or intel Atom 
> hardware).
> After some time - day or two of playing videos. Something happens.
> The CPU usage jumps way up like 120% kind of usage.  Like the vdpau stuff is 
> no longer working.
>
> Is this a know issue ?
> What should I look for  ?
> What can I provide to help ?
>
>  Intel(R) Atom(TM) CPU D525   @ 1.80GHz
> 03:00.0 VGA compatible controller: NVIDIA Corporation GT218 [ION] (rev a2)
>
> Thanks
>
> Jerry

Re: [Nouveau] Advice about debugging nouveau driver suspend issue (init_on_alloc=1 and init_on_free=1)

[Ilia Mirkin]

On Thu, Oct 14, 2021 at 12:51 PM Computer Enthusiastic
 wrote:
>
> Hello,
>
> Thanks for the answer.
>
> On Wed, Oct 13, 2021 at 01:43:56PM -0400, Ilia Mirkin wrote:
> > The most straightforward thing, if you can reproduce at will, would be
> > to do a bisect to figure out which change this happened with. Once we
> > know which change caused the problem, it will hopefully provide with
> > more ability to sort out where we're going wrong. You can also play
> > with things like KASAN, although it's not clear to me that they would
> > necessarily catch this problem.
>
> The patch is "mm: security: introduce init_on_alloc=1 and init_on_free=1
> boot options" (commit 6471384af2a6530696fc0203bafe4de41a23c9ef) [1].
>
> It was introduced in kernel version 5.2:
> $ git describe --tags 6471384af2a6530696fc0203bafe4de41a23c9ef
> v5.2-5754-g6471384af2a6

Uff... so you've verified that a kernel at that commit +
init_on_alloc=1 and init_on_free=1 (or the CONFIG_* equivalents) will
cause the problems?

That means the problem has "always been there" (or at least we have no
great way of knowing when it might have been introduced).

I think there's some sort of SLUB debug options that help find
use-after-frees and such. What if you disable the init_on_*, enable
SLUB, and boot with like "slub_debug=FZP"?

  -ilia

Re: [Nouveau] Advice about debugging nouveau driver suspend issue (init_on_alloc=1 and init_on_free=1)

[Ilia Mirkin]

The most straightforward thing, if you can reproduce at will, would be
to do a bisect to figure out which change this happened with. Once we
know which change caused the problem, it will hopefully provide with
more ability to sort out where we're going wrong. You can also play
with things like KASAN, although it's not clear to me that they would
necessarily catch this problem.

Cheers,

  -ilia

On Wed, Oct 13, 2021 at 1:31 PM Computer Enthusiastic
 wrote:
>
> Hello,
>
> Greeting to all list members.
>
> I hope this mailing list is the right place to ask about it, otherwise
> I apologize in advance and, please, direct me to the right mailing
> list.
>
> I would like to receive advice on how to debug (or help to debug) the
> noveau kernel module suspend issue reported in [1][2][3]. The issue is
> constantly reproducible and it consists in a  screen corruption with
> system lockup on resume after suspend to ram or suspend to disk. It
> seems to affect NV50 nvidia graphic cards at least from kernel 5.10.0
> (probably from 5.2 or 5.3) up to 5.14.10 (I have not tested 5.15 in rc
> state, actually).
>
> Thanks in advance.
>
> [1] https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/-/issues/547
> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989705
> [3] https://bugzilla.kernel.org/show_bug.cgi?id=213617

Re: [Nouveau] Nouveau on Ubuntu 20.04 LTS

[Ilia Mirkin]

On Fri, Oct 1, 2021 at 4:56 PM Jerry Geis  wrote:
>
>
>
> On Fri, Oct 1, 2021 at 4:48 PM Jerry Geis  wrote:
>>
>>
>>
>> On Fri, Oct 1, 2021 at 4:41 PM Ilia Mirkin  wrote:
>>>
>>> On Fri, Oct 1, 2021 at 4:29 PM Jerry Geis  wrote:
>>> > yes very weird on the sound. Using analog speakers at the moment
>>> > I got no test sound - and no video sound after getting nouveau to run 
>>> > correctly 
>>> > I was playing analog audio before ?
>>> > Does nouveau only do HDMI audio ?
>>>
>>> nouveau only does HDMI(/DP) audio. A different driver will handle a
>>> built-in sound card (e.g. snd_hda_intel). You might want to reach out
>>> to your distro's support channels to better diagnose what's going on.
>>> Unlikely to have anything to do with nouveau. More likely that you had
>>> added "acpi=off" to hack around this. Or perhaps pci=nomsi for a
>>> broken audio adapter? Don't know. dmesg (not to mention google) will
>>> have the answers.
>>>
>>>   -ilia
>>
>>
>> Thanks - I switched monitors - using a 4K monitor with buildin sound.
>> Sound works now- great.  but the screen is not in 4K .
>> Does Nouveau not do 4K - 3840x2160?
>>
>> Thanks!
>>
>> Jerry
>
>
> HA! I just dawned on my the OLD GT218 does not do 4K... The 4K display looks 
> like a strched for some reason - I thought it would jus tbe the normal 1080p.
> Anyway - got it working - thanks to all the suggestions!

We enforce a max of 165mhz on those boards for HDMI (this is what the
HW is rated for). If you feel like forcing it, you can boot with
nouveau.hdmimhz=300 to allow the 4k resolution. Note that it's a
weaker GPU, and 4k will not be great on it anyways.

  -ilia

Re: [Nouveau] Nouveau on Ubuntu 20.04 LTS

[Ilia Mirkin]

On Fri, Oct 1, 2021 at 4:29 PM Jerry Geis  wrote:
> yes very weird on the sound. Using analog speakers at the moment
> I got no test sound - and no video sound after getting nouveau to run 
> correctly 
> I was playing analog audio before ?
> Does nouveau only do HDMI audio ?

nouveau only does HDMI(/DP) audio. A different driver will handle a
built-in sound card (e.g. snd_hda_intel). You might want to reach out
to your distro's support channels to better diagnose what's going on.
Unlikely to have anything to do with nouveau. More likely that you had
added "acpi=off" to hack around this. Or perhaps pci=nomsi for a
broken audio adapter? Don't know. dmesg (not to mention google) will
have the answers.

  -ilia

Re: [Nouveau] Nouveau on Ubuntu 20.04 LTS

[Ilia Mirkin]

On Fri, Oct 1, 2021 at 3:58 PM Jerry Geis  wrote:
>
>
>
> On Fri, Oct 1, 2021 at 3:40 PM Ilia Mirkin  wrote:
>>
>> On Fri, Oct 1, 2021 at 3:36 PM Jerry Geis  wrote:
>> >
>> >
>> >
>> > On Fri, Oct 1, 2021 at 3:27 PM Jerry Geis  wrote:
>> >>
>> >>
>> >>
>> >> On Fri, Oct 1, 2021 at 3:20 PM Ilia Mirkin  wrote:
>> >>>
>> >>> On Fri, Oct 1, 2021 at 3:17 PM Jerry Geis  wrote:
>> >>> > On Fri, Oct 1, 2021 at 3:06 PM Ilia Mirkin  
>> >>> > wrote:
>> >>> >>
>> >>> >> On Fri, Oct 1, 2021 at 3:00 PM Jerry Geis  
>> >>> >> wrote:
>> >>> >> > lsmod | grep nouveau
>> >>> >> >
>> >>> >> > What dont I have ?
>> >>> >>
>> >>> >> nouveau :)
>> >>> >>
>> >>> >> Other than that, you got everything...
>> >>> >>
>> >>> >> Check dmesg for errors.
>> >>> >>
>> >>> >> Cheers,
>> >>> >>
>> >>> >>   -ilia
>> >>> >
>> >>> >
>> >>> > I see this:
>> >>> > Oct  1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: (==) 
>> >>> > Matched nouveau as autoconfigured driver 0
>> >>>
>> >>> This is not dmesg. This is some log file. Please look in dmesg.
>> >>>
>> >>> > Oct  1 15:11:23 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: (**) 
>> >>> > VESA(0): Using "Shadow Framebuffer"
>> >>>
>> >>> X is using the VESA driver because nouveau (nor any other DRM driver) is 
>> >>> loaded.
>> >>>
>> >>> >
>> >>> > So it seems like its loading  but perhaps its not happy 
>> >>> >
>> >>> > What do I do  ?
>> >>>
>> >>> Check dmesg for why nouveau didn't load.
>> >>>
>> >>>   -ilia
>> >>
>> >>
>> >>  grep -i nouveau /var/log/dmesg
>> >> [   19.934733] kernel: fb0: switching to nouveaufb from VESA VGA
>> >> [   20.013197] kernel: nouveau :03:00.0: vgaarb: deactivate vga 
>> >> console
>> >> [   20.013415] kernel: nouveau :03:00.0: NVIDIA GT218 (0a8200b1)
>> >> [   20.159472] kernel: nouveau :03:00.0: bios: version 70.18.45.00.00
>> >> [   20.162603] kernel: nouveau :03:00.0: fb: 512 MiB DDR3
>> >> [   21.552858] kernel: nouveau :03:00.0: DRM: VRAM: 512 MiB
>> >> [   21.552873] kernel: nouveau :03:00.0: DRM: GART: 1048576 MiB
>> >> [   21.552888] kernel: nouveau :03:00.0: DRM: TMDS table version 2.0
>> >> [   21.552900] kernel: nouveau :03:00.0: DRM: DCB version 4.0
>> >> [   21.552911] kernel: nouveau :03:00.0: DRM: DCB outp 00: 01000302 
>> >> 0030
>> >> [   21.552924] kernel: nouveau :03:00.0: DRM: DCB outp 01: 02000300 
>> >> 
>> >> [   21.552937] kernel: nouveau :03:00.0: DRM: DCB outp 02: 02011362 
>> >> 00020010
>> >> [   21.552950] kernel: nouveau :03:00.0: DRM: DCB conn 00: 1030
>> >> [   21.552961] kernel: nouveau :03:00.0: DRM: DCB conn 01: 2161
>> >> [   21.568834] kernel: nouveau :03:00.0: DRM: MM: using COPY for 
>> >> buffer copies
>> >> [   21.645206] kernel: nouveau :03:00.0: DRM: allocated 1920x1080 fb: 
>> >> 0x7, bo (ptrval)
>> >> [   21.648681] kernel: fbcon: nouveaudrmfb (fb0) is primary device
>> >> [   21.837701] kernel: nouveau :03:00.0: [drm] fb0: nouveaudrmfb 
>> >> frame buffer device
>> >> [   21.873290] kernel: [drm] Initialized nouveau 1.3.1 20120801 for 
>> >> :03:00.0 on minor 0
>>
>> I was looking for you to just run "dmesg", BTW, not read a log file.
>>
>> >>
>> >> lsmod | grep nouveau
>> >> nouveau  1986560  30
>> >> mxm_wmi16384  1 nouveau
>> >> i2c_algo_bit   16384  1 nouveau
>> >> drm_ttm_helper 16384  1 nouveau
>> >> ttm73728  2 drm_ttm_helper,nouveau
>> >> drm_kms_helper237568  1 nouveau
>> >> drm   548864  25 drm_kms_helper,drm_ttm_helper,ttm,nou

Re: [Nouveau] Nouveau on Ubuntu 20.04 LTS

[Ilia Mirkin]

On Fri, Oct 1, 2021 at 3:36 PM Jerry Geis  wrote:
>
>
>
> On Fri, Oct 1, 2021 at 3:27 PM Jerry Geis  wrote:
>>
>>
>>
>> On Fri, Oct 1, 2021 at 3:20 PM Ilia Mirkin  wrote:
>>>
>>> On Fri, Oct 1, 2021 at 3:17 PM Jerry Geis  wrote:
>>> > On Fri, Oct 1, 2021 at 3:06 PM Ilia Mirkin  wrote:
>>> >>
>>> >> On Fri, Oct 1, 2021 at 3:00 PM Jerry Geis  wrote:
>>> >> > lsmod | grep nouveau
>>> >> >
>>> >> > What dont I have ?
>>> >>
>>> >> nouveau :)
>>> >>
>>> >> Other than that, you got everything...
>>> >>
>>> >> Check dmesg for errors.
>>> >>
>>> >> Cheers,
>>> >>
>>> >>   -ilia
>>> >
>>> >
>>> > I see this:
>>> > Oct  1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: (==) 
>>> > Matched nouveau as autoconfigured driver 0
>>>
>>> This is not dmesg. This is some log file. Please look in dmesg.
>>>
>>> > Oct  1 15:11:23 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: (**) 
>>> > VESA(0): Using "Shadow Framebuffer"
>>>
>>> X is using the VESA driver because nouveau (nor any other DRM driver) is 
>>> loaded.
>>>
>>> >
>>> > So it seems like its loading  but perhaps its not happy 
>>> >
>>> > What do I do  ?
>>>
>>> Check dmesg for why nouveau didn't load.
>>>
>>>   -ilia
>>
>>
>>  grep -i nouveau /var/log/dmesg
>> [   19.934733] kernel: fb0: switching to nouveaufb from VESA VGA
>> [   20.013197] kernel: nouveau :03:00.0: vgaarb: deactivate vga console
>> [   20.013415] kernel: nouveau :03:00.0: NVIDIA GT218 (0a8200b1)
>> [   20.159472] kernel: nouveau :03:00.0: bios: version 70.18.45.00.00
>> [   20.162603] kernel: nouveau :03:00.0: fb: 512 MiB DDR3
>> [   21.552858] kernel: nouveau :03:00.0: DRM: VRAM: 512 MiB
>> [   21.552873] kernel: nouveau :03:00.0: DRM: GART: 1048576 MiB
>> [   21.552888] kernel: nouveau :03:00.0: DRM: TMDS table version 2.0
>> [   21.552900] kernel: nouveau :03:00.0: DRM: DCB version 4.0
>> [   21.552911] kernel: nouveau :03:00.0: DRM: DCB outp 00: 01000302 
>> 0030
>> [   21.552924] kernel: nouveau :03:00.0: DRM: DCB outp 01: 02000300 
>> 
>> [   21.552937] kernel: nouveau :03:00.0: DRM: DCB outp 02: 02011362 
>> 00020010
>> [   21.552950] kernel: nouveau :03:00.0: DRM: DCB conn 00: 1030
>> [   21.552961] kernel: nouveau :03:00.0: DRM: DCB conn 01: 2161
>> [   21.568834] kernel: nouveau :03:00.0: DRM: MM: using COPY for buffer 
>> copies
>> [   21.645206] kernel: nouveau :03:00.0: DRM: allocated 1920x1080 fb: 
>> 0x7, bo (ptrval)
>> [   21.648681] kernel: fbcon: nouveaudrmfb (fb0) is primary device
>> [   21.837701] kernel: nouveau :03:00.0: [drm] fb0: nouveaudrmfb frame 
>> buffer device
>> [   21.873290] kernel: [drm] Initialized nouveau 1.3.1 20120801 for 
>> :03:00.0 on minor 0

I was looking for you to just run "dmesg", BTW, not read a log file.

>>
>> lsmod | grep nouveau
>> nouveau  1986560  30
>> mxm_wmi16384  1 nouveau
>> i2c_algo_bit   16384  1 nouveau
>> drm_ttm_helper 16384  1 nouveau
>> ttm73728  2 drm_ttm_helper,nouveau
>> drm_kms_helper237568  1 nouveau
>> drm   548864  25 drm_kms_helper,drm_ttm_helper,ttm,nouveau
>> video  53248  1 nouveau
>> wmi32768  2 mxm_wmi,nouveau
>>
>> I took off ALL extra kernel command paramters - nothing specific to nouveau 
>> - and I got better results. however - video is still dropping frames.

Perhaps you had a "nomodeset" in there? That would prevent nouveau
from doing anything useful, although I think it'd still load in that
case.

>>
>> So progress. but still no good.

Check xorg log to make sure you see NOUVEAU lines, not modeset lines.
If you see modeset lines, make sure you force the nouveau DDX driver
to load. (Some distros think it's funny to prevent it from loading by
default...)

>>
>> Jerry
>
>
> I see this error:
> nouveau :03:00.0: Direct firmware load for nouveau/nva8_fuc084 failed
>
> I did apt-file search nva8_fuc084
> and it did not return anything.

This is for video decoding acceleration (vdpau / va-api). You can set
this up by following the instructions at
https://nouveau.freedesktop.org/VideoAcceleration.html . Note that
it's hardly perfect.

Cheers,

  -ilia

Re: [Nouveau] Nouveau on Ubuntu 20.04 LTS

[Ilia Mirkin]

On Fri, Oct 1, 2021 at 3:17 PM Jerry Geis  wrote:
> On Fri, Oct 1, 2021 at 3:06 PM Ilia Mirkin  wrote:
>>
>> On Fri, Oct 1, 2021 at 3:00 PM Jerry Geis  wrote:
>> > lsmod | grep nouveau
>> >
>> > What dont I have ?
>>
>> nouveau :)
>>
>> Other than that, you got everything...
>>
>> Check dmesg for errors.
>>
>> Cheers,
>>
>>   -ilia
>
>
> I see this:
> Oct  1 15:11:21 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: (==) Matched 
> nouveau as autoconfigured driver 0

This is not dmesg. This is some log file. Please look in dmesg.

> Oct  1 15:11:23 mediaport57 /usr/lib/gdm3/gdm-x-session[1546]: (**) VESA(0): 
> Using "Shadow Framebuffer"

X is using the VESA driver because nouveau (nor any other DRM driver) is loaded.

>
> So it seems like its loading  but perhaps its not happy 
>
> What do I do  ?

Check dmesg for why nouveau didn't load.

  -ilia

Re: [Nouveau] Nouveau on Ubuntu 20.04 LTS

[Ilia Mirkin]

On Fri, Oct 1, 2021 at 3:00 PM Jerry Geis  wrote:
> lsmod | grep nouveau
>
> What dont I have ?

nouveau :)

Other than that, you got everything...

Check dmesg for errors.

Cheers,

  -ilia

Re: [Nouveau] Nouveau on Ubuntu 20.04 LTS

[Ilia Mirkin]

On Fri, Oct 1, 2021 at 2:29 PM Jerry Geis  wrote:
> Thanks perhaps this is part of the problem:
>  ls -l /sys/kernel/debug/dri/
> total 0

This indicates that nouveau is not loaded. (Or loaded and failed
part-way through the load.)

Cheers,

  -ilia

Re: [Nouveau] Nouveau on Ubuntu 20.04 LTS

[Ilia Mirkin]

You can check the perf level your GPU is at, and potentially adjust it.

cat /sys/kernel/debug/dri/0/pstate

This should give a list of levels like "xx: stuff", with the "AC"
level being the current settings. Echo'ing any one of the xx's into
that file will attempt to switch to a different performance level.
Sometimes it works, other times it kills the GPU until you reboot. Use
with care.

Cheers,

  -ilia

On Fri, Oct 1, 2021 at 11:01 AM Jerry Geis  wrote:
>
> I am trying to get Nouveau running and also playing video.
> lspci | grep VGA shows
> 03:00.0 VGA compatible controller: NVIDIA Corporation GT218 [ION] (rev a2)
>
> syslog shows nouveau loaded
>
> But video performance is SLOW - dropping frames.
>
> have I missed something ?
>
> How do I get better video performance ?
>
> Thanks,
>
> Jerry

Re: [Nouveau] Understanding BAR1 Offset to imem/VRAM PA Mapping

[Ilia Mirkin]

Hi Joshua,

It looks like you got most of the way there. The BARs (BAR1 and BAR3)
are initialized by the code in nvkm/subdev/bar/gf100.c. As you can
see, this sets up a vmm per BAR, whose (physical address >> 12) is
written to 0x1704 / 0x1714. A vmm is basically a list of PDE's (and
the PTE lists those PDE's point to). The address, I believe, is the
base of the PDE's (or maybe they start at 0x200 from the base
address). I believe that all addresses relative to the appropriate BAR
are then translated through this vmm and hit the appropriate physical
VRAM addresses. You can see how this is all set up in
nvkm/subdev/mmu/vmmgf100.c. The code is somewhat fancy to generically
deal with different page sizes/etc, but you can mostly ignore that.
Different generations allow different things, which is what you'll
find in the subsequent vmm* files. Pascal gains 48-bit virtual
addresses (up from 40), which I think changes some details around as
well.

Ben - please correct me if I'm wrong. I suspect I missed some details
relative to *actually* making this work, but this should be the gist
of it.

Hope this helps,

  -ilia

On Wed, Sep 29, 2021 at 4:17 PM Joshua Bakita  wrote:
>
> Hello,
>
> I'm trying to understand how VRAM PAs are mapped to BAR1 offsets on
> Fermi+, but I'm having difficulty digging through the abstractions in
> nouveau. I spent the better part of yesterday digging through the
> nv50_instobj_*() functions, but I lost track of which page tables are
> being modified and where they're coming from somewhere around level 7
> of indirection/aliasing from the nvkm_kmap() call (aka
> nv50_instobj_acquire()) to the actual nvkm_vmm_iter() logic which I
> think does the mapping.
>
> If page tables are used to map BAR1 offsets to VRAM PAs on Fermi+, I'd
> like to understand their relation to the normal GPU VA to PA page
> tables, and how we tell the hardware which page tables to use for the
> BAR1 mappings.
>
> Best regards,
>
> Joshua Bakita
> PhD Student
> UNC Chapel Hill | Real-Time Systems Group
>
> (Apologies if anyone already received this email, I tried sending it
> earlier and I think it got stuck in moderation.)

Re: [Nouveau] Trouble with TTM patches w/nouveau in linux-next

[Ilia Mirkin]

GEM init happens here:

https://cgit.freedesktop.org/drm/drm/tree/drivers/gpu/drm/nouveau/nouveau_gem.c#n221

Note the bo alloc / gem init / bo init dance.

I don't think there is a GEM object for internal allocations at all --
we just allocate bo's directly and that's it. Perhaps you meant
something else? I thought GEM was meant for externally-available
objects.

Cheers,

  -ilia

On Wed, Jun 9, 2021 at 10:58 AM Christian König
 wrote:
>
> Good point, but I think that is unrelated.
>
> My suspicion is rather that nouveau is not initializing the underlying
> GEM object for internal allocations.
>
> So what happens is the same as on VMWGFX that TTM doesn't know anything
> about the size to of the BO resulting in a kmalloc() with a random value
> and eventually -ENOMEM.
>
> Good news is that I can reproduce it, so going to look into that later
> today.
>
> Regards,
> Christian.
>
> Am 09.06.21 um 16:52 schrieb Ilia Mirkin:
> > Christian - potentially relevant is that Tegra doesn't have VRAM at
> > all -- all GTT (or GART or whatever it's called nowadays). No
> > fake/stolen VRAM.
> >
> > Cheers,
> >
> >-ilia
> >
> > On Wed, Jun 9, 2021 at 10:18 AM Christian König
> >  wrote:
> >> Hi Mikko,
> >>
> >> strange sounds like Nouveau was somehow also using the GEM workaround
> >> for VMWGFX as well.
> >>
> >> But -12 means -ENOMEM which doesn't fits into the picture.
> >>
> >> I will try with a G710, but if that doesn't yields anything I need some
> >> more input from you.
> >>
> >> Thanks for the report,
> >> Christian.
> >>
> >>
> >> Am 09.06.21 um 15:47 schrieb Mikko Perttunen:
> >>> Hi,
> >>>
> >>> I'm observing nouveau not initializing recently on linux-next on my
> >>> Tegra186 Jetson TX2 board. Specifically it looks like BO allocation is
> >>> failing when initializing the sync subsystem:
> >>>
> >>> [   21.858149] nouveau 1700.gpu: DRM: failed to initialise sync
> >>> subsystem, -28
> >>>
> >>> I have been bisecting and I have found two patches that affect this.
> >>> Firstly, things first break on
> >>>
> >>> d02117f8efaa drm/ttm: remove special handling for non GEM drivers
> >>>
> >>> starting to return error code -12. Then, at
> >>>
> >>> d79025c7f5e3 drm/ttm: always initialize the full ttm_resource v2
> >>>
> >>> the error code changes to the above -28.
> >>>
> >>> If I checkout one commit prior to d79025c7f5e3 and revert
> >>> d02117f8efaa, things work again. There are a bunch of other TTM
> >>> commits between this and HEAD, so reverting these on top of HEAD
> >>> doesn't work. However, I checked that both yesterday's and today's
> >>> nexts are also broken.
> >>>
> >>> Thank you,
> >>> Mikko
> >>>
> >> ___
> >> Nouveau mailing list
> >> Nouveau@lists.freedesktop.org
> >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fnouveaudata=04%7C01%7Cchristian.koenig%40amd.com%7Caaf09cbea0b04d8dc01208d92b5637ba%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637588472445308290%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=ePoWVtHPXeK5RThkRuQSykKrfWCgPOzG5CLTzfw9%2Fuw%3Dreserved=0
>
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Trouble with TTM patches w/nouveau in linux-next

[Ilia Mirkin]

Christian - potentially relevant is that Tegra doesn't have VRAM at
all -- all GTT (or GART or whatever it's called nowadays). No
fake/stolen VRAM.

Cheers,

  -ilia

On Wed, Jun 9, 2021 at 10:18 AM Christian König
 wrote:
>
> Hi Mikko,
>
> strange sounds like Nouveau was somehow also using the GEM workaround
> for VMWGFX as well.
>
> But -12 means -ENOMEM which doesn't fits into the picture.
>
> I will try with a G710, but if that doesn't yields anything I need some
> more input from you.
>
> Thanks for the report,
> Christian.
>
>
> Am 09.06.21 um 15:47 schrieb Mikko Perttunen:
> > Hi,
> >
> > I'm observing nouveau not initializing recently on linux-next on my
> > Tegra186 Jetson TX2 board. Specifically it looks like BO allocation is
> > failing when initializing the sync subsystem:
> >
> > [   21.858149] nouveau 1700.gpu: DRM: failed to initialise sync
> > subsystem, -28
> >
> > I have been bisecting and I have found two patches that affect this.
> > Firstly, things first break on
> >
> > d02117f8efaa drm/ttm: remove special handling for non GEM drivers
> >
> > starting to return error code -12. Then, at
> >
> > d79025c7f5e3 drm/ttm: always initialize the full ttm_resource v2
> >
> > the error code changes to the above -28.
> >
> > If I checkout one commit prior to d79025c7f5e3 and revert
> > d02117f8efaa, things work again. There are a bunch of other TTM
> > commits between this and HEAD, so reverting these on top of HEAD
> > doesn't work. However, I checked that both yesterday's and today's
> > nexts are also broken.
> >
> > Thank you,
> > Mikko
> >
>
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] nouveau broken on Riva TNT2 in 5.13.0-rc4: NULL pointer dereference in nouveau_bo_sync_for_device

[Ilia Mirkin]

Another instance of a report like this here:
https://gitlab.freedesktop.org/drm/nouveau/-/issues/92

On Sat, Jun 5, 2021 at 3:53 PM Ondrej Zary  wrote:
>
> Hello,
> I'm testing 5.13.0-rc4 and nouveau crashes with NULL pointer dereference in 
> nouveau_bo_sync_for_device.
> Found various reports like this but that was back in februaryso that should 
> be fixed now.
>
> [   21.003216] BUG: kernel NULL pointer dereference, address: 
> [   21.003235] #PF: supervisor read access in kernel mode
> [   21.003243] #PF: error_code(0x) - not-present page
> [   21.003250] *pde = 
> [   21.003258] Oops:  [#1] SMP
> [   21.003268] CPU: 0 PID: 222 Comm: systemd-udevd Not tainted 5.13.0-rc4+ 
> #327
> [   21.003278] Hardware name:  /848P-ICH5, BIOS 6.00 PG 02/03/2005
> [   21.003285] EIP: nouveau_bo_sync_for_device+0x9e/0xbf [nouveau]
> [   21.003571] Code: 02 89 45 e8 01 d1 8b 19 89 5d ec bb 01 00 00 00 3b 5d e8 
> 74 0d 89 d8 c1 e0 05 03 45 ec 39 04 99 74 1e 8b 46 10 89 d9 c1 e1 0c <8b> 14 
> 10 8b 47 e0 8b 40 08 6a 01 e8 d5 03 55 df 01 5d f0 58 eb ae
> [   21.003588] EAX:  EBX: 0010 ECX: 0001 EDX: 
> [   21.003597] ESI: c3e90280 EDI: c185a494 EBP: c2ed7c10 ESP: c2ed7bf8
> [   21.003606] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 EFLAGS: 00210206
> [   21.003615] CR0: 80050033 CR2:  CR3: 02ecb000 CR4: 0690
> [   21.003625] Call Trace:
> [   21.003635]  nouveau_bo_validate+0x3f/0x48 [nouveau]
> [   21.003911]  nouveau_bo_pin+0xf0/0x187 [nouveau]
> [   21.004182]  nouveau_channel_prep+0xc0/0x269 [nouveau]
> [   21.004454]  nouveau_channel_new+0x3c/0x5f5 [nouveau]
> [   21.004725]  ? slab_free_freelist_hook+0x3b/0xa7
> [   21.004740]  ? kfree+0x9e/0x11a
> [   21.004749]  ? nvif_object_sclass_put+0xd/0x16 [nouveau]
> [   21.004944]  nouveau_drm_device_init+0x2e2/0x646 [nouveau]
> [   21.005186]  ? pci_enable_device_flags+0x23/0x97
> [   21.005202]  nouveau_drm_probe+0xe5/0x182 [nouveau]
> [   21.005443]  ? nouveau_drm_device_init+0x646/0x646 [nouveau]
> [   21.005683]  pci_device_probe+0x89/0xe9
> [   21.005696]  really_probe+0x127/0x2b9
> [   21.005707]  driver_probe_device+0x62/0x89
> [   21.005715]  device_driver_attach+0x2e/0x41
> [   21.005724]  __driver_attach+0x83/0x8a
> [   21.005732]  bus_for_each_dev+0x4c/0x66
> [   21.005740]  driver_attach+0x14/0x16
> [   21.005747]  ? device_driver_attach+0x41/0x41
> [   21.005756]  bus_add_driver+0xc5/0x16c
> [   21.005764]  driver_register+0x87/0xb9
> [   21.005772]  __pci_register_driver+0x38/0x3b
> [   21.005780]  ? 0xf0be4000
> [   21.005787]  nouveau_drm_init+0x14c/0x1000 [nouveau]
> [   21.005964]  do_one_initcall+0x5a/0x134
> [   21.005975]  ? __vunmap+0x124/0x12d
> [   21.005984]  ? __vunmap+0x124/0x12d
> [   21.005992]  ? kmem_cache_alloc+0xa8/0xb6
> [   21.006001]  ? do_init_module+0x17/0x1cf
> [   21.006012]  do_init_module+0x46/0x1cf
> [   21.006021]  load_module+0x1799/0x1bcb
> [   21.006032]  __ia32_sys_finit_module+0x72/0x7a
> [   21.006044]  do_int80_syscall_32+0x53/0x62
> [   21.006054]  entry_INT80_32+0xf0/0xf0
> [   21.006063] EIP: 0xb7f40092
> [   21.006071] Code: 00 00 00 e9 90 ff ff ff ff a3 24 00 00 00 68 30 00 00 00 
> e9 80 ff ff ff ff a3 e8 ff ff ff 66 90 00 00 00 00 00 00 00 00 cd 80  8d 
> b4 26 00 00 00 00 8d b6 00 00 00 00 8b 1c 24 c3 8d b4 26 00
> [   21.006086] EAX: ffda EBX: 0010 ECX: b7e9bbdd EDX: 
> [   21.006095] ESI: 008f27d0 EDI: 008f9e10 EBP:  ESP: bfa140b8
> [   21.006103] DS: 007b ES: 007b FS:  GS: 0033 SS: 007b EFLAGS: 00200296
> [   21.006114] Modules linked in: nouveau(+) snd_intel8x0 snd_ac97_codec 
> pcmcia wmi hwmon ac97_bus yenta_socket pcmcia_rsrc drm_ttm_helper snd_pcm ttm 
> snd_timer pcmcia_core psmouse 8139cp snd sg soundcore serio_raw parport_pc 
> intel_agp parport
> [   21.006165] CR2: 
> [   21.006201] ---[ end trace 02dc541683feafc6 ]---
> [   21.006211] EIP: nouveau_bo_sync_for_device+0x9e/0xbf [nouveau]
> [   21.006460] Code: 02 89 45 e8 01 d1 8b 19 89 5d ec bb 01 00 00 00 3b 5d e8 
> 74 0d 89 d8 c1 e0 05 03 45 ec 39 04 99 74 1e 8b 46 10 89 d9 c1 e1 0c <8b> 14 
> 10 8b 47 e0 8b 40 08 6a 01 e8 d5 03 55 df 01 5d f0 58 eb ae
> [   21.006476] EAX:  EBX: 0010 ECX: 0001 EDX: 
> [   21.006485] ESI: c3e90280 EDI: c185a494 EBP: c2ed7c10 ESP: c2ed7bf8
> [   21.006494] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 EFLAGS: 00210206
> [   21.006503] CR0: 80050033 CR2:  CR3: 02ecb000 CR4: 0690
>
>
> --
> Ondrej Zary
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH v4 02/17] drm/nouveau/kms/nv50-: Move AUX adapter reg to connector late register/early unregister

[Ilia Mirkin]

Some trivia, no comment on the real logic of the changes:

On Fri, Apr 23, 2021 at 2:43 PM Lyude Paul  wrote:
>
> Since AUX adapters on nouveau have their respective DRM connectors as
> parents, we need to make sure that we register then after their connectors.

then -> them

>
> Signed-off-by: Lyude Paul 
> ---
>  drivers/gpu/drm/nouveau/nouveau_connector.c | 25 -
>  1 file changed, 20 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c 
> b/drivers/gpu/drm/nouveau/nouveau_connector.c
> index 61e6d7412505..c04044be3d32 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_connector.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
> @@ -401,7 +401,6 @@ nouveau_connector_destroy(struct drm_connector *connector)
> drm_connector_cleanup(connector);
> if (nv_connector->aux.transfer) {
> drm_dp_cec_unregister_connector(_connector->aux);
> -   drm_dp_aux_unregister(_connector->aux);
> kfree(nv_connector->aux.name);
> }
> kfree(connector);
> @@ -905,13 +904,29 @@ nouveau_connector_late_register(struct drm_connector 
> *connector)
> int ret;
>
> ret = nouveau_backlight_init(connector);
> +   if (ret)
> +   return ret;
>
> +   if (connector->connector_type == DRM_MODE_CONNECTOR_eDP ||
> +   connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort) {
> +   ret = drm_dp_aux_register(_connector(connector)->aux);
> +   if (ret)
> +   goto backlight_fini;
> +   }
> +
> +   return 0;
> +backlight_fini:
> +   nouveau_backlight_fini(connector);
> return ret;
>  }
>
>  static void
>  nouveau_connector_early_unregister(struct drm_connector *connector)
>  {
> +   if (connector->connector_type == DRM_MODE_CONNECTOR_eDP ||
> +   connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort)
> +   drm_dp_aux_unregister(_connector(connector)->aux);
> +
> nouveau_backlight_fini(connector);
>  }
>
> @@ -1343,14 +1358,14 @@ nouveau_connector_create(struct drm_device *dev,
> snprintf(aux_name, sizeof(aux_name), "sor-%04x-%04x",
>  dcbe->hasht, dcbe->hashm);
> nv_connector->aux.name = kstrdup(aux_name, GFP_KERNEL);
> -   ret = drm_dp_aux_register(_connector->aux);
> +   drm_dp_aux_init(_connector->aux);
> if (ret) {
> -   NV_ERROR(drm, "failed to register aux channel\n");
> +   NV_ERROR(drm, "Failed to init AUX adapter for 
> sor-%04x-%04x: %d\n",

Maybe just use aux_name instead of rebuilding the string again?

> +dcbe->hasht, dcbe->hashm, ret);
> kfree(nv_connector);
> return ERR_PTR(ret);
> }
> -   funcs = _connector_funcs;
> -   break;
> +   fallthrough;
> default:
> funcs = _connector_funcs;
> break;
> --
> 2.30.2
>
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH v2] ALSA: hda: Continue to probe when codec probe fails

[Ilia Mirkin]

On Mon, Apr 12, 2021 at 4:01 PM Aaron Plattner  wrote:
>
> On 4/12/21 12:36 PM, Roy Spliet wrote:
> > Hello Aaron,
> >
> > Thanks for your insights. A follow-up query and some observations
> > in-line.
> >
> > Op 12-04-2021 om 20:06 schreef Aaron Plattner:
> >> On 4/10/21 1:48 PM, Roy Spliet wrote:
> >>> Op 10-04-2021 om 20:23 schreef Lukas Wunner:
>  On Sat, Apr 10, 2021 at 04:51:27PM +0100, Roy Spliet wrote:
> > Can I ask someone with more
> > technical knowledge of snd_hda_intel and vgaswitcheroo to
> > brainstorm about
> > the possible challenges of nouveau taking matters into its own
> > hand rather
> > than keeping this PCI quirk around?
> 
>  It sounds to me like the HDA is not powered if no cable is plugged in.
>  What is reponsible then for powering it up or down, firmware code on
>  the GPU or in the host's BIOS?
> >>>
> >>> Sometimes the BIOS, but definitely unconditionally the PCI quirk
> >>> code:
> >>> https://github.com/torvalds/linux/blob/master/drivers/pci/quirks.c#L5289
> >>>
> >>>
> >>> (CC Aaron Plattner)
> >>
> >> My basic understanding is that the audio function stops responding
> >> whenever the graphics function is powered off. So the requirement
> >> here is that the audio driver can't try to talk to the audio function
> >> while the graphics function is asleep, and must trigger a graphics
> >> function wakeup before trying to communicate with the audio function.
> >
> > I believe that vgaswitcheroo takes care of this for us.
> >
> >> I think there are also requirements about the audio function needing
> >> to be awake when the graphics driver is updating the ELD, but I'm not
> >> sure.
> >>
> >> This is harder on Windows because the audio driver lives in its own
> >> little world doing its own thing but on Linux we can do better.
> >>
>  Ideally, we should try to find out how to control HDA power from the
>  operating system rather than trying to cooperate with whatever
>  firmware
>  is doing.  If we have that capability, the OS should power the HDA up
>  and down as it sees fit.
> >>
> >> After system boot, I don't think there's any firmware involved, but
> >> I'm not super familiar with the low-level details and it's possible
> >> the situation changed since I last looked at it.
> >>
> >> I think the problem with having nouveau write this quirk is that the
> >> kernel will need to re-probe the PCI device to notice that it has
> >> suddenly become a multi-function device with an audio function, and
> >> hotplug the audio driver. I originally looked into trying to do that
> >> but it was tricky because the PCI subsystem didn't really have a
> >> mechanism for a single-function device to become a multi-function
> >> device on the fly and it seemed easier to enable it early on during
> >> bus enumeration. That way the kernel sees both functions all the time
> >> without anything else having to be special about this configuration.
> >
> > Right, so for a little more context: a while ago I noticed that my
> > laptop (lucky me, Asus K501UB) has a 940M with HDA but no codec. Seems
> > legit, given how this GPU has no displays attached; they're all hooked
> > up to the Intel integrated GPU. That threw off the snd_hda_intel
> > mid-probe, and as a result didn't permit runpm, keeping the entire
> > GPU, PCIe bus and thus the CPU package awake. A bit of hackerly later
> > we decided to continue probing without a codec, and now my laptop is
> > happy, but...
>
> What is the PCI class of the GPU in your system? If it has no display
> outputs it's probably 0x302 ("3D Controller") rather than 0x300 ("VGA
> Controller"). Looking at the code it looks like this workaround is being
> applied to both but maybe it should be restricted to just VGA controllers.

That was a comment I had back when the quirk was being implemented,
but helpfully there are some of these devices running around which say
"3D Controller" but still have displays attached to them. Lukas
probably remembers more specifics.

  -ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] SLI support for nv44

[Ilia Mirkin]

On Tue, Mar 30, 2021 at 4:25 AM Karol Herbst  wrote:
>
> On Tue, Mar 30, 2021 at 8:28 AM  wrote:
> >
> > Hi,
> > I am currently the happy owner of a nforce 4 - SLI with two 7100gs graphics 
> > cards setup.
> > Since I've read on your features matrix that such a setup is rather 
> > uncommon among developers, I would like to help you implementing SLI for 
> > old GeForce cards as much as I can. The lack of support for newer kernels 
> > from Nvidia has indeed made my system obsolete (I do encounter graphical 
> > glitches with many DEs).
> > I can run tests with my hardware, try new drivers, and know the basics of C 
> > programming if necessary.
> >
> > If you think that I could be helpful in any way, don't hesitate to contact 
> > me back.
> >
>
> well, SLI is really low priority, so unless somebody is willing to
> reverse engineer the nvidia driver and implement the code in nouveau,
> I highly doubt there will be any progress on SLI in the near or far
> future. So if you want to help out, you'd do the full thing as there
> is nobody working on SLI. Some bits might already be reverse
> engineered though.

The tricky bit with SLI is how to split up the work. The original
Voodoo2 SLI was great -- the renderer would build up the scene, and
both boards would do the render, but alternate scanlines of what they
actually computed, effectively doing half the work. The specific
method of splitting doesn't matter, but the important part is that the
splitting is done. However with more modern software, you might have
an intermediate render, e.g. first you render a texture, then you use
that texture for the final render, then you have to recombine the two
render "halves" on both GPUs in order for them to have access to it
for the final render. This reduces SLI's effectiveness, and makes it
much trickier to manage.

If you wanted to improve the situation with that generation of
hardware, I'd definitely focus more on making it conform to GL 2.1.
This is a problem on which you can make measurable progress on. There
are a number of shortcomings there, and I think fixing them will help
resolve some of the issues you see with DEs. This is not an extremely
easy task -- if it were, it'd be done already. If you're interested in
diving in, join #nouveau on irc.freenode.net and we can talk further
about your abilities, goals, and next steps.

Cheers,

  -ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH] drm/nouveau/kms/nv50-: Check plane size for cursors, not fb size

[Ilia Mirkin]

On Thu, Mar 18, 2021 at 5:56 PM Lyude Paul  wrote:
>
> Found this while trying to make some changes to the kms_cursor_crc test.
> curs507a_acquire checks that the width and height of the cursor framebuffer
> are equal (asyw->image.{w,h}). This is actually wrong though, as we only
> want to be concerned that the actual width/height of the plane are the
> same. It's fine if we scan out from an fb that's slightly larger than the
> cursor plane (in fact, some igt tests actually do this).

How so? The scanout engine expects the data to be packed. Height can
be larger, but width has to match.

  -ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH] xv: add MMX / SSE acceleration for YV12 -> YUYV repacking

[Ilia Mirkin]

This is used by the blit adaptor. Might as well try to accelerate it.
When testing with it hacked to take effect for nvc0, saw, a decrease of
NVPutImage usage in the X process from 68% -> 43% (MMX) -> 24% (SSE)
(which is approximately a 7x speed-up to the function, assuming other
parts remained equal).

Signed-off-by: Ilia Mirkin 
---

I did some basic testing with a patch to force the texture path to do
this conversion rather than to NV12, testing all 3 cases. However I need
to do better testing of edge cases, which I will do before pushing.

 src/nouveau_xv.c | 94 
 1 file changed, 80 insertions(+), 14 deletions(-)

diff --git a/src/nouveau_xv.c b/src/nouveau_xv.c
index b2d75c5..16aca93 100644
--- a/src/nouveau_xv.c
+++ b/src/nouveau_xv.c
@@ -25,7 +25,7 @@
 #include "config.h"
 #endif
 
-#ifdef __SSE2__
+#if defined(__SSE2__) || defined(__MMX__)
 #include 
 #endif
 
@@ -568,7 +568,7 @@ NVCopyData420(unsigned char *src1, unsigned char *src2, 
unsigned char *src3,
 {
CARD32 *dst;
CARD8 *s1, *s2, *s3;
-   int i, j;
+   int i, j, l, e;
 
 #define su(X) (((j & 1) && j < (h-1)) ? ((unsigned)((signed int)s2[X] +
\
(signed int)(s2 + srcPitch2)[X]) / 2) : (s2[X]))
@@ -576,29 +576,95 @@ NVCopyData420(unsigned char *src1, unsigned char *src2, 
unsigned char *src3,
(signed int)(s3 + srcPitch2)[X]) / 2) : (s3[X]))
 
w >>= 1;
+#ifdef __MMX__
+   l = w >> 3;
+   e = w & 7;
+#else
+   l = w >> 2;
+   e = w & 3;
+#endif
 
for (j = 0; j < h; j++) {
dst = (CARD32*)dst1;
s1 = src1;  s2 = src2;  s3 = src3;
i = w;
 
-   while (i > 4) {
+   for (i = 0; i < l; i++) {
+#ifdef __MMX__
+   __m64 mm_v = *(__m64 *)[0];
+   __m64 mm_u = *(__m64 *)[0];
+
+   if (j & 1 && j < (h - 1)) {
+   __m64 mm_vnext = *(__m64 *)&(s2 + srcPitch2)[0];
+#ifdef __SSE__
+   mm_v = _mm_avg_pu8(mm_v, mm_vnext);
+#else /* __SSE__ */
+   __m64 zero = _m_from_int(0);
+   /* make 16-bit wide values */
+   __m64 mm_vnext16_1 = _mm_unpacklo_pi8(mm_vnext, 
zero);
+   __m64 mm_vnext16_2 = _mm_unpackhi_pi8(mm_vnext, 
zero);
+   __m64 mm_v16_1 = _mm_unpacklo_pi8(mm_v, zero);
+   __m64 mm_v16_2 = _mm_unpackhi_pi8(mm_v, zero);
+   /* add together */
+   mm_v16_1 = _mm_add_pi16(mm_v16_1, mm_vnext16_1);
+   mm_v16_2 = _mm_add_pi16(mm_v16_2, mm_vnext16_2);
+   /* divide by 2 */
+   mm_v16_1 = _mm_srli_pi16(mm_v16_1, 1);
+   mm_v16_2 = _mm_srli_pi16(mm_v16_2, 1);
+   /* put back into 8-bit values */
+   mm_v = _mm_packs_pu16(mm_v16_1, mm_v16_2);
+#endif
+
+   /* repeat for u */
+   __m64 mm_unext = *(__m64 *)&(s3 + srcPitch2)[0];
+#ifdef __SSE__
+   mm_u = _mm_avg_pu8(mm_u, mm_unext);
+#else /* __SSE__ */
+   /* make 16-bit wide values */
+   __m64 mm_unext16_1 = _mm_unpacklo_pi8(mm_unext, 
zero);
+   __m64 mm_unext16_2 = _mm_unpackhi_pi8(mm_unext, 
zero);
+   __m64 mm_u16_1 = _mm_unpacklo_pi8(mm_u, zero);
+   __m64 mm_u16_2 = _mm_unpackhi_pi8(mm_u, zero);
+   /* add together */
+   mm_u16_1 = _mm_add_pi16(mm_u16_1, mm_unext16_1);
+   mm_u16_2 = _mm_add_pi16(mm_u16_2, mm_unext16_2);
+   /* divide by 2 */
+   mm_u16_1 = _mm_srli_pi16(mm_u16_1, 1);
+   mm_u16_2 = _mm_srli_pi16(mm_u16_2, 1);
+   /* put back into 8-bit values */
+   mm_u = _mm_packs_pu16(mm_u16_1, mm_u16_2);
+#endif
+   }
+
+   __m64 mm_y1 = *(__m64 *)s1;
+   __m64 mm_y2 = *(__m64 *)[8];
+
+   __m64 mm_uv1 = _mm_unpacklo_pi8(mm_u, mm_v);
+   __m64 mm_uv2 = _mm_unpackhi_pi8(mm_u, mm_v);
+
+   *(__m64 *)[0] = _mm_unpacklo_pi8(mm_y1, mm_uv1);
+   *(__m64 *)[2] = _mm_unpackhi_pi8(mm_y1, mm_uv1);
+   *(__m64 *)[4] = _mm_unpacklo_pi8(mm_y2, mm_uv2);
+   *(__m64 *)[6] = _mm_unpackhi_pi8(mm_y2, m

[Nouveau] [PATCH] drm/nouveau/kms/nv04: use vzalloc for nv04_display

[Ilia Mirkin]

The struct is giant, and triggers an order-7 allocation (512K). There is
no reason for this to be kmalloc-type memory, so switch to vmalloc. This
should help loading nouveau on low-memory and/or long-running systems.

Reported-by: Nathan E. Egge 
Signed-off-by: Ilia Mirkin 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/nouveau/dispnv04/disp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c 
b/drivers/gpu/drm/nouveau/dispnv04/disp.c
index 7739f46470d3..99fee4d8cd31 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
@@ -205,7 +205,7 @@ nv04_display_destroy(struct drm_device *dev)
nvif_notify_dtor(>flip);
 
nouveau_display(dev)->priv = NULL;
-   kfree(disp);
+   vfree(disp);
 
nvif_object_unmap(>client.device.object);
 }
@@ -223,7 +223,7 @@ nv04_display_create(struct drm_device *dev)
struct nv04_display *disp;
int i, ret;
 
-   disp = kzalloc(sizeof(*disp), GFP_KERNEL);
+   disp = vzalloc(sizeof(*disp));
if (!disp)
return -ENOMEM;
 
-- 
2.26.2

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Ilia Mirkin]

On Wed, Mar 3, 2021 at 8:25 AM Uwe Sauter  wrote:
>
> Am 03.03.21 um 14:12 schrieb Ilia Mirkin:
> > On Wed, Mar 3, 2021 at 7:41 AM Alex Riesen  
> > wrote:
> >>
> >> Ilia Mirkin, Sat, Feb 27, 2021 22:26:57 +0100:
> >>> Can you try Alex's patch to modetest and confirm that you see issues
> >>> with modetest? If so, can you (and maybe Alex as well) try an older
> >>> kernel (I'm on 5.6) and see if modetest behaves well there. [The patch
> >>> in question was to expose 256x256 as the 'preferred' size, but support
> >>> for the larger cursors has been around for a while.] Alex - if you
> >>> have time, same question to you.
> >>
> >> Sorry that it took so long. I retestet with the same kernel as Uwe did
> >> (5.4.101) and my results are the same: modetest with 64 and 128 cursors 
> >> looks
> >> good, 256 broken. Didn't test with X this time (this being my main office
> >> machine), but can do later if required.
> >
> > Thanks for confirming! No need to test X - that will work fine, since
> > we were reporting the smaller cursors on that kernel.
> >
> > So I think we have definitive evidence that at least all Kepler
> > doesn't do 256x256 (and it's not just some bug in the display macro
> > rework that got introduced). And unless I'm blind and don't see the
> > corruption, Pascal seems fine. Question remains for Maxwell1/2 GPUs.
> > Unless someone has immediate plans to test on those, I'd recommend
> > bumping the minimum for 256x256 being reported to Pascal, and doing
> > 128x128 for Kepler / Maxwell.
>
> The only older model I have access to would be a 6600GT (NV43). Don't know if 
> this would have any
> significance…

Nope, we want newer :) Maxwell came after Kepler. GTX 750 for Maxwell
1, and GTX 9xx for Maxwell 2. (GM10x and GM20x).

Cheers,

  -ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Ilia Mirkin]

On Wed, Mar 3, 2021 at 7:41 AM Alex Riesen  wrote:
>
> Ilia Mirkin, Sat, Feb 27, 2021 22:26:57 +0100:
> > Can you try Alex's patch to modetest and confirm that you see issues
> > with modetest? If so, can you (and maybe Alex as well) try an older
> > kernel (I'm on 5.6) and see if modetest behaves well there. [The patch
> > in question was to expose 256x256 as the 'preferred' size, but support
> > for the larger cursors has been around for a while.] Alex - if you
> > have time, same question to you.
>
> Sorry that it took so long. I retestet with the same kernel as Uwe did
> (5.4.101) and my results are the same: modetest with 64 and 128 cursors looks
> good, 256 broken. Didn't test with X this time (this being my main office
> machine), but can do later if required.

Thanks for confirming! No need to test X - that will work fine, since
we were reporting the smaller cursors on that kernel.

So I think we have definitive evidence that at least all Kepler
doesn't do 256x256 (and it's not just some bug in the display macro
rework that got introduced). And unless I'm blind and don't see the
corruption, Pascal seems fine. Question remains for Maxwell1/2 GPUs.
Unless someone has immediate plans to test on those, I'd recommend
bumping the minimum for 256x256 being reported to Pascal, and doing
128x128 for Kepler / Maxwell.

Simon, Lyude -- thoughts?

Cheers,

  -ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] How to reverse engineer a PCI-Express driver under Linux ?

[Ilia Mirkin]

On Wed, Mar 3, 2021 at 5:30 AM Karol Herbst  wrote:
>
>
>
> On Wed, Mar 3, 2021 at 11:07 AM Tomek LECOCQ  wrote:
>>
>> Hello,
>>
>> I’ve already asked this on the Kernel Newbies mail list, but as developing 
>> nouveau seems to be kind of similar to what I want to achieve, I thought it 
>> would be a good idea to ask it here as well.
>>
>> I have a PCI-Express video capture card that has a proprietary driver for 
>> Linux.
>> I have some experience with programming in C, and so I would like to start a 
>> hobby project to develop a free/libre driver for this device for Linux.
>> Of course I don’t have access to any documentation about how to communicate 
>> with this device (I’ve tried to contact the company making these, but my 
>> hopes are not high), so I think I will need to reverse-engineer the way the 
>> existing driver communicates with the hardware. How could I achieve this ?
>>
>
> Usually drivers map PCIe bars into the VM and read/write at certain offsets 
> to do.. stuff. In the linux kernel we have the mmiotrace tracer in order to 
> capture what a driver does with the hardware. You still need to interpret the 
> trace file, but at least this should give you the raw data on what's going 
> on. Hope that helps.

Here's a good guide on how to use mmiotrace. It's nvidia-focused, but
the same steps would apply to any driver:
https://wiki.ubuntu.com/X/MMIOTracing

Basically, start mmiotrace, load target driver, do some stuff, stop
mmiotrace, analyze the resulting trace.

We have some tooling to help with that -- envytools/rnn/demmio will
parse the mmiotrace against a given rnndb (also in envytools). You
won't be able to reuse our rnndb, but you'd be able to build up your
own. You also wouldn't be able to use demmio directly, but you could
see how it works and modify it to your hw's needs. (e.g. it waits for
a read of the "0" mmio reg to determine which chip is being traced,
and loads up the appropriate rnndb settings - that won't work with
your hw out of the box.)

>> Also, the long term goal of this project would be to have this driver merged 
>> into mainline, so what is allowed or not while doing this to avoid 
>> problematic legal ramifications ?

This isn't legal advice (for that, consult a lawyer), however a few
things that are definitely going to get you into trouble:

 - stealing (or using stolen) documentation
 - de-compiling target driver and copying its implementation (as that
would be subject to copyright)

A semi-common technique is to use a so-called "chinese firewall", e.g.
one person/team de-compiles, writes documentation, and then a second
person/team uses that documentation to implement a driver. That way no
copying of copyright-able content occurs, and no one can claim that
the implementer had access to the copyrighted materials and thus could
copy without even trying to. But it all depends on the target company
(and jurisdictions in question) -- if they're particularly litigious,
they could sue you for breathing air -- doesn't matter that their case
has no merit, you'd still be stuck defending yourself.

Cheers,

  -ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Ilia Mirkin]

On Sun, Feb 28, 2021 at 2:24 PM Uwe Sauter  wrote:
> >> Summary:
> >> 5.4.101  | 5.10.19  | 5.11.2
> >> modetest-64   seems ok | seems ok | seems ok
> >> modetest-128  seems ok | seems ok | seems ok
> >> modetest-256  sliced   | sliced   | sliced
> >> X mouse pointer   ok   | ok   | sliced
> >> (modesetting ddx)
> >> X mouse pointer   ok   | ok   | ok
> >> (nouveau ddx)
>
> One more data point:
> Linus' vanilla kernel commit 5695e51619745d4fe3ec2506a2f0cd982c5e27a4 (Sat 
> Feb 27 08:29:02 2021 -0800) shows the same
> behavior.
>
> I could try to bisect…

There's nothing to bisect. The issue is exposed by advertising 256x256
cursors by default. But older kernels supported 256x256 cursors as
well, which is why modetest was a good test for it. modesetting ddx
takes the "default" cursor size.

It's just a matter of figuring out which hardware has the problem.

  -ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Ilia Mirkin]

On Sun, Feb 28, 2021 at 12:59 PM Uwe Sauter  wrote:
>
>
>
> Am 28.02.21 um 18:02 schrieb Ilia Mirkin:
> > On Sun, Feb 28, 2021 at 10:10 AM Uwe Sauter  wrote:
> >>
> >>
> >>
> >> Am 27.02.21 um 22:26 schrieb Ilia Mirkin:
> >>> On Sat, Feb 27, 2021 at 7:28 AM Uwe Sauter  
> >>> wrote:
> >>>>
> >>>> I can also report that the modesetting ddx that comes with xorg-server 
> >>>> 1.20.10-3 (Arch Linux package) shows this kind of
> >>>> cursor-cut-into-horizontal-stripes behavior. Changing to 
> >>>> xf86-video-nouveau 1.0.17-1 solves this issue. But nouveau has
> >>>> issues with Mate 1.24 (as discussed earlier this month).
> >>>>
> >>>> My hardware:
> >>>> # lspci -s 3:0.0 -v
> >>>> 03:00.0 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT 
> >>>> 710] (rev a1) (prog-if 00 [VGA controller])
> >>>>   Subsystem: ASUSTeK Computer Inc. GT710-4H-SL-2GD5
> >>>>   Flags: bus master, fast devsel, latency 0, IRQ 36, IOMMU group 
> >>>> 12
> >>>>   Memory at fb00 (32-bit, non-prefetchable) [size=16M]
> >>>>   Memory at fff000 (64-bit, prefetchable) [size=128M]
> >>>>   Memory at fff800 (64-bit, prefetchable) [size=32M]
> >>>>   I/O ports at f000 [size=128]
> >>>>   Expansion ROM at fc00 [disabled] [size=512K]
> >>>>   Capabilities: [60] Power Management version 3
> >>>>   Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+
> >>>>   Capabilities: [78] Express Legacy Endpoint, MSI 00
> >>>>   Capabilities: [100] Virtual Channel
> >>>>   Capabilities: [128] Power Budgeting 
> >>>>   Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 
> >>>> Len=024 
> >>>>   Capabilities: [900] Secondary PCI Express
> >>>>   Kernel driver in use: nouveau
> >>>>   Kernel modules: nouveau
> >>>>
> >>>>
> >>>> If I can help in any way please let me know.
> >>>
> >>> Thanks, that's good info. Simon - you originally said that everything
> >>> looked good on your GK208, so a retest would be super.
> >>>
> >>> I just double-checked on a GP108 (with an older kernel, but same idea
> >>> should apply), and it seems like 256x256 cursors are fine there.
> >>> However the display logic has gone through some ideally no-op updates
> >>> since that kernel version, but there could very easily be issues.
> >>>
> >>> Can you try Alex's patch to modetest and confirm that you see issues
> >>> with modetest? If so, can you (and maybe Alex as well) try an older
> >>> kernel (I'm on 5.6) and see if modetest behaves well there. [The patch
> >>> in question was to expose 256x256 as the 'preferred' size, but support
> >>> for the larger cursors has been around for a while.] Alex - if you
> >>> have time, same question to you.
> >>>
> >>> You can find the patch here:
> >>> https://lists.x.org/archives/nouveau/2021-February/037992.html
> >>
> >> I had to install a parallel Arch Linux to my existing production system in 
> >> order to keep it clean from all the
> >> development stuff.
> >>
> >> System summary (most recent):
> >> AMD Ryzen 3 3100
> >> Gigabyte B550M S2H with BIOS F13c
> >> Asus GT710-4H-SL-2GD5 (GK208B [GeForce GT 710] (rev a1)) using nouveau 
> >> kernel module
> >> 32GB DDR4-3200MHz ECC
> >>
> >> libdrm 2.4.104-1
> >> linux 5.11.2.arch1-1
> >> mesa 20.3.4-3
> >> xf86-video-nouveau 1.0.17-1
> >>
> >>
> >>
> >> I built libdrm 2.4.104.r16.ga9bb32cf in order to get modetest.
> >>
> >> With unmodified kernel / modetest (cw=64, ch=64) I call:
> >>
> >> $ ./modetest -c |grep '^[0-9]\|preferred'
> >> 85  86  connected HDMI-A-1530x300   40  86
> >> #0 1920x1080 60.00 1920 2008 2052 2200 1080 1084 1089 1125 148500 
> >> flags: phsync, pvsync; type: preferred, driver
> >> 87  0 disconnected  HDMI-A-20x0   0 88
> >> 89  0 disconnected  HDMI-A-30x0   0 90
> >> 91  0 disconnected  HDMI-A-40x0   0 92
> >>
> >>

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Ilia Mirkin]

On Sun, Feb 28, 2021 at 10:10 AM Uwe Sauter  wrote:
>
>
>
> Am 27.02.21 um 22:26 schrieb Ilia Mirkin:
> > On Sat, Feb 27, 2021 at 7:28 AM Uwe Sauter  wrote:
> >>
> >> I can also report that the modesetting ddx that comes with xorg-server 
> >> 1.20.10-3 (Arch Linux package) shows this kind of
> >> cursor-cut-into-horizontal-stripes behavior. Changing to 
> >> xf86-video-nouveau 1.0.17-1 solves this issue. But nouveau has
> >> issues with Mate 1.24 (as discussed earlier this month).
> >>
> >> My hardware:
> >> # lspci -s 3:0.0 -v
> >> 03:00.0 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT 
> >> 710] (rev a1) (prog-if 00 [VGA controller])
> >>  Subsystem: ASUSTeK Computer Inc. GT710-4H-SL-2GD5
> >>  Flags: bus master, fast devsel, latency 0, IRQ 36, IOMMU group 12
> >>  Memory at fb00 (32-bit, non-prefetchable) [size=16M]
> >>  Memory at fff000 (64-bit, prefetchable) [size=128M]
> >>  Memory at fff800 (64-bit, prefetchable) [size=32M]
> >>  I/O ports at f000 [size=128]
> >>  Expansion ROM at fc00 [disabled] [size=512K]
> >>  Capabilities: [60] Power Management version 3
> >>  Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+
> >>  Capabilities: [78] Express Legacy Endpoint, MSI 00
> >>  Capabilities: [100] Virtual Channel
> >>  Capabilities: [128] Power Budgeting 
> >>  Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 
> >> Len=024 
> >>  Capabilities: [900] Secondary PCI Express
> >>  Kernel driver in use: nouveau
> >>  Kernel modules: nouveau
> >>
> >>
> >> If I can help in any way please let me know.
> >
> > Thanks, that's good info. Simon - you originally said that everything
> > looked good on your GK208, so a retest would be super.
> >
> > I just double-checked on a GP108 (with an older kernel, but same idea
> > should apply), and it seems like 256x256 cursors are fine there.
> > However the display logic has gone through some ideally no-op updates
> > since that kernel version, but there could very easily be issues.
> >
> > Can you try Alex's patch to modetest and confirm that you see issues
> > with modetest? If so, can you (and maybe Alex as well) try an older
> > kernel (I'm on 5.6) and see if modetest behaves well there. [The patch
> > in question was to expose 256x256 as the 'preferred' size, but support
> > for the larger cursors has been around for a while.] Alex - if you
> > have time, same question to you.
> >
> > You can find the patch here:
> > https://lists.x.org/archives/nouveau/2021-February/037992.html
>
> I had to install a parallel Arch Linux to my existing production system in 
> order to keep it clean from all the
> development stuff.
>
> System summary (most recent):
> AMD Ryzen 3 3100
> Gigabyte B550M S2H with BIOS F13c
> Asus GT710-4H-SL-2GD5 (GK208B [GeForce GT 710] (rev a1)) using nouveau kernel 
> module
> 32GB DDR4-3200MHz ECC
>
> libdrm 2.4.104-1
> linux 5.11.2.arch1-1
> mesa 20.3.4-3
> xf86-video-nouveau 1.0.17-1
>
>
>
> I built libdrm 2.4.104.r16.ga9bb32cf in order to get modetest.
>
> With unmodified kernel / modetest (cw=64, ch=64) I call:
>
> $ ./modetest -c |grep '^[0-9]\|preferred'
> 85  86  connected HDMI-A-1530x300   40  86
>#0 1920x1080 60.00 1920 2008 2052 2200 1080 1084 1089 1125 148500 flags: 
> phsync, pvsync; type: preferred, driver
> 87  0 disconnected  HDMI-A-20x0   0 88
> 89  0 disconnected  HDMI-A-30x0   0 90
> 91  0 disconnected  HDMI-A-40x0   0 92
>
> ./modetest -s 85:1920x1080 -C
> trying to open device 'i915'...failed
> trying to open device 'amdgpu'...failed
> trying to open device 'radeon'...failed
> trying to open device 'nouveau'...done
> setting mode 1920x1080-60.00Hz on connectors 85, crtc 50
> starting cursor
> ^C
>
> This shows several things:
> * There is a moving gray, half transparent square bouncing around. I believe 
> that this is
>the mentioned cursor.
>
> * The cursor movement happens at various speeds, sometimes staying half a 
> second on the
>same position to then move quite fast to another, then slowing down.
>
> * The cursor is flickering.
>
> * When (forcefully) ending the test the screen is not properly reset, leaving 
> the
>previous content in a state similar to the phenomenon with the mouse 
> cursor that stated
>this discussion. O

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Ilia Mirkin]

On Sat, Feb 27, 2021 at 7:28 AM Uwe Sauter  wrote:
>
> Hi Ilia,
>
> Am 24.02.21 um 18:47 schrieb Ilia Mirkin:
> > On Wed, Feb 24, 2021 at 12:03 PM Alex Riesen
> >  wrote:
> >>
> >> Ilia Mirkin, Wed, Feb 24, 2021 17:57:41 +0100:
> >>> On Wed, Feb 24, 2021 at 11:53 AM Alex Riesen 
> >>>  wrote:
> >>>> Ilia Mirkin, Wed, Feb 24, 2021 17:48:39 +0100:
> >>>>> Just to be crystal clear -- are you saying that 128x128 works or does
> >>>>> not work? (You said "yes", which would imply it works OK, but then you
> >>>>> said both cases, which would imply doesn't work since 256x256 doesn't
> >>>>> work?)
> >>>>
> >>>> Modetest with 128x128 cursor works. Without damage to the cursor: 
> >>>> modetest
> >>>> shows normal cursor in vanilla v5.11. Modetest also shows normal cursor 
> >>>> in
> >>>> vanilla v5.11 with the commit reverted.
> >>>
> >>> But modetest with 256x256 doesn't work (correctly) right? Or did I
> >>> misunderstand?
> >>
> >> Right. That's why I was asking if I did everything right: it was just 
> >> corrupted
> >> in both kernels.
> >
> > OK. So 128x128 works, 256x256 does not. Interesting.
> >
> >>
> >>> All the patch does is allow those large cursors to be used, which gets
> >>> reported via drm APIs and modesetting picks the largest cursor
> >>> available. (And actually I think it's even not required to use the
> >>> large cursors, it just controls what's reported in the defaults to
> >>> userspace.)
> >>
> >> Maybe something in X code is not prepared to handle the kernel reporting
> >> large cursor support? Even though 128x128 is pretty large, and I don't 
> >> think
> >> I even use that large cursors in X configuration. How can I check?
> >
> > Yes, 64x64 is enough for anyone (or was it 640kb?) But it's unlikely
> > to be an issue. I believe that AMD also exposes 256x256 cursors
> > depending on the gen:
> >
> > display/dc/dce100/dce100_resource.c:dc->caps.max_cursor_size = 128;
> > display/dc/dce110/dce110_resource.c:dc->caps.max_cursor_size = 128;
> > display/dc/dce112/dce112_resource.c:dc->caps.max_cursor_size = 128;
> > display/dc/dce120/dce120_resource.c:dc->caps.max_cursor_size = 128;
> > display/dc/dce60/dce60_resource.c:  dc->caps.max_cursor_size = 64;
> > display/dc/dce60/dce60_resource.c:  dc->caps.max_cursor_size = 64;
> > display/dc/dce60/dce60_resource.c:  dc->caps.max_cursor_size = 64;
> > display/dc/dce80/dce80_resource.c:  dc->caps.max_cursor_size = 128;
> > display/dc/dce80/dce80_resource.c:  dc->caps.max_cursor_size = 128;
> > display/dc/dce80/dce80_resource.c:  dc->caps.max_cursor_size = 128;
> > display/dc/dcn10/dcn10_resource.c:  dc->caps.max_cursor_size = 256;
> > display/dc/dcn20/dcn20_resource.c:  dc->caps.max_cursor_size = 256;
> > display/dc/dcn21/dcn21_resource.c:  dc->caps.max_cursor_size = 256;
> > display/dc/dcn30/dcn30_resource.c:  dc->caps.max_cursor_size = 256;
> >
> > which should have the equivalent effect.
> >
> > But since you're seeing issues with modetest as well (which uses the
> > ioctl's pretty directly), presumably Xorg is not to blame.
> >
> > It's easy enough to adjust the kernel to report a lower size (and
> > reject the larger cursors), I just want to understand which gens are
> > affected by this.
>
> I can also report that the modesetting ddx that comes with xorg-server 
> 1.20.10-3 (Arch Linux package) shows this kind of
> cursor-cut-into-horizontal-stripes behavior. Changing to xf86-video-nouveau 
> 1.0.17-1 solves this issue. But nouveau has
> issues with Mate 1.24 (as discussed earlier this month).
>
> My hardware:
> # lspci -s 3:0.0 -v
> 03:00.0 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT 710] 
> (rev a1) (prog-if 00 [VGA controller])
> Subsystem: ASUSTeK Computer Inc. GT710-4H-SL-2GD5
> Flags: bus master, fast devsel, latency 0, IRQ 36, IOMMU group 12
> Memory at fb00 (32-bit, non-prefetchable) [size=16M]
> Memory at fff000 (64-bit, prefetchable) [size=128M]
> Memory at fff800 (64-bit, prefetchable) [size=32M]
> I/O ports at f000 [size=128]
> Expansion ROM at fc00 [disabled] [size=512K]
> Capabilities: [60] Power Management version 3
> Capabilities: [68] MSI: Enabl

Re: [Nouveau] i2c-dev driver corrupts display?

[Ilia Mirkin]

That's very surprising. As I recall, i2c-dev just adds /dev nodes for
various i2c devices (some of which would be exposed by nouveau, most
likely just the connector one to read EDID in your case, as temp/etc
sensors came later). It shouldn't cause nouveau to do anything
differently -- just allows user-space to have access to the i2c
adapters.

You can try messing with the i2c implementation a bit with

nouveau.config=NvI2C=1

which will flip the internal implementation from the "shared" bit-bang
implementation, to a dedicated nouveau one. But it shouldn't matter.
And as I mentioned before, not sure how the i2c-dev module can affect
it either way -- either the shared impl works or it doesn't.

You can also try booting with

nouveau.debug=debug

to see if you can glean any meaningful information from the "broken" case.

I also remember reports of a later mobile board (NV28M) having weird
clock-related and cursor layout issues
(https://bugs.freedesktop.org/show_bug.cgi?id=54700,
https://bugs.freedesktop.org/show_bug.cgi?id=78543). Not directly
related to your situation, but just pointing to it in case it triggers
some ideas.

In your testing, it might also be wise to differentiate warm vs cold
boots. You can also force re-initialization of the board with

nouveau.config=NvForcePost=1

Cheers,

  -ilia

On Thu, Feb 25, 2021 at 5:40 PM Roger  wrote:
>
> HARDWARE:
> Dell Inspiron 8100 laptop
> nVIDIA Geforce2 Go (NV11) with Intel AGP
>
> PROBLEM:
> Display corruption whenever nouveau module was loaded, seemingly at random.
>
> CULPRIT:
> Whenever the i2c-dev.ko driver/module was loaded, the display would become
> corrupted, or as if the timing became out of sync with hardware 
> specifications,
> with weird moving pixels throughout the display.
>
> If the i2c-dev is built into the kernel, possible the display would turn-off
> upon nouveau module loading, but could be possibly worked around (I think) by
> building the nouveau driver statically into the kernel, possibly loading prior
> to i2c-dev loading?
>
> Been having this problem for many years, finally found it, and nothing found
> via Google on i2c-dev & nouveau.
>
> WORKAROUND:
> /etc/modprobe.d/blacklist.conf
> blacklist i2c_dev
>
> Or, rebuild the kernel without i2c-dev.
>
> Quite a few Linux distributions either compile the i2c-dev into the kernel, or
> load the module during booting, creating significant display problems (as 
> noted
> above) when trying to install from a Linux distribution CD/DVD.  Most people
> performing an install, I'm guessing, are then simply performing a nomodeset
> during boot and/or reverting to VESA/UVESAFB.
>
>
> --
> Roger
> http://rogerx.sdf.org/
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Ilia Mirkin]

On Wed, Feb 24, 2021 at 12:03 PM Alex Riesen
 wrote:
>
> Ilia Mirkin, Wed, Feb 24, 2021 17:57:41 +0100:
> > On Wed, Feb 24, 2021 at 11:53 AM Alex Riesen  
> > wrote:
> > > Ilia Mirkin, Wed, Feb 24, 2021 17:48:39 +0100:
> > > > Just to be crystal clear -- are you saying that 128x128 works or does
> > > > not work? (You said "yes", which would imply it works OK, but then you
> > > > said both cases, which would imply doesn't work since 256x256 doesn't
> > > > work?)
> > >
> > > Modetest with 128x128 cursor works. Without damage to the cursor: modetest
> > > shows normal cursor in vanilla v5.11. Modetest also shows normal cursor in
> > > vanilla v5.11 with the commit reverted.
> >
> > But modetest with 256x256 doesn't work (correctly) right? Or did I
> > misunderstand?
>
> Right. That's why I was asking if I did everything right: it was just 
> corrupted
> in both kernels.

OK. So 128x128 works, 256x256 does not. Interesting.

>
> > All the patch does is allow those large cursors to be used, which gets
> > reported via drm APIs and modesetting picks the largest cursor
> > available. (And actually I think it's even not required to use the
> > large cursors, it just controls what's reported in the defaults to
> > userspace.)
>
> Maybe something in X code is not prepared to handle the kernel reporting
> large cursor support? Even though 128x128 is pretty large, and I don't think
> I even use that large cursors in X configuration. How can I check?

Yes, 64x64 is enough for anyone (or was it 640kb?) But it's unlikely
to be an issue. I believe that AMD also exposes 256x256 cursors
depending on the gen:

display/dc/dce100/dce100_resource.c:dc->caps.max_cursor_size = 128;
display/dc/dce110/dce110_resource.c:dc->caps.max_cursor_size = 128;
display/dc/dce112/dce112_resource.c:dc->caps.max_cursor_size = 128;
display/dc/dce120/dce120_resource.c:dc->caps.max_cursor_size = 128;
display/dc/dce60/dce60_resource.c:  dc->caps.max_cursor_size = 64;
display/dc/dce60/dce60_resource.c:  dc->caps.max_cursor_size = 64;
display/dc/dce60/dce60_resource.c:  dc->caps.max_cursor_size = 64;
display/dc/dce80/dce80_resource.c:  dc->caps.max_cursor_size = 128;
display/dc/dce80/dce80_resource.c:  dc->caps.max_cursor_size = 128;
display/dc/dce80/dce80_resource.c:  dc->caps.max_cursor_size = 128;
display/dc/dcn10/dcn10_resource.c:  dc->caps.max_cursor_size = 256;
display/dc/dcn20/dcn20_resource.c:  dc->caps.max_cursor_size = 256;
display/dc/dcn21/dcn21_resource.c:  dc->caps.max_cursor_size = 256;
display/dc/dcn30/dcn30_resource.c:  dc->caps.max_cursor_size = 256;

which should have the equivalent effect.

But since you're seeing issues with modetest as well (which uses the
ioctl's pretty directly), presumably Xorg is not to blame.

It's easy enough to adjust the kernel to report a lower size (and
reject the larger cursors), I just want to understand which gens are
affected by this.

Cheers,

  -ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Ilia Mirkin]

On Wed, Feb 24, 2021 at 11:53 AM Alex Riesen
 wrote:
>
> Ilia Mirkin, Wed, Feb 24, 2021 17:48:39 +0100:
> > On Wed, Feb 24, 2021 at 11:35 AM Alex Riesen  
> > wrote:
> > > Ilia Mirkin, Wed, Feb 24, 2021 16:10:57 +0100:
> > > > The fact that you're getting lines with modetest means there's
> > > > something wrong with 256x256. What if you do 128x128 -- does that work
> > > > OK?
> > >
> > > Yes. Unfortunately in both cases.
> >
> > Just to be crystal clear -- are you saying that 128x128 works or does
> > not work? (You said "yes", which would imply it works OK, but then you
> > said both cases, which would imply doesn't work since 256x256 doesn't
> > work?)
>
> Modetest with 128x128 cursor works. Without damage to the cursor: modetest
> shows normal cursor in vanilla v5.11. Modetest also shows normal cursor in
> vanilla v5.11 with the commit reverted.

But modetest with 256x256 doesn't work (correctly) right? Or did I
misunderstand?

All the patch does is allow those large cursors to be used, which gets
reported via drm APIs and modesetting picks the largest cursor
available. (And actually I think it's even not required to use the
large cursors, it just controls what's reported in the defaults to
userspace.)

Thanks,

  -ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Ilia Mirkin]

On Wed, Feb 24, 2021 at 11:35 AM Alex Riesen
 wrote:
> Ilia Mirkin, Wed, Feb 24, 2021 16:10:57 +0100:
> > The fact that you're getting lines with modetest means there's
> > something wrong with 256x256. What if you do 128x128 -- does that work
> > OK?
>
> Yes. Unfortunately in both cases.

Just to be crystal clear -- are you saying that 128x128 works or does
not work? (You said "yes", which would imply it works OK, but then you
said both cases, which would imply doesn't work since 256x256 doesn't
work?)

Thanks,

  -ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Ilia Mirkin]

[+emersion, -various people and lists who definitely don't care]

On Wed, Feb 24, 2021 at 4:09 AM Alex Riesen
 wrote:
>
> Ilia Mirkin, Tue, Feb 23, 2021 19:13:59 +0100:
> > On Tue, Feb 23, 2021 at 11:23 AM Alex Riesen  
> > wrote:
> > >
> > > $ xrandr  --listproviders
> > > Providers: number : 1
> > > Provider 0: id: 0x68 cap: 0x7, Source Output, Sink Output, Source 
> > > Offload crtcs: 4 outputs: 5 associated providers: 0 name:nouveau
> > >
> > > And yes, the cursor looks good in v5.11 even without reverting the commit.
> >
> > FWIW it's not immediately apparent to me what grave error modesetting
> > is committing in setting the cursor. The logic looks perfectly
> > reasonable. It's not trying to be fancy with rendering the cursor/etc.
> >
> > The one thing is that it's using drmModeSetCursor2 which sets the
> > hotspot at the same time. But internally inside nouveau I think it
> > should work out to the same thing. Perhaps setting the hotspot, or
> > something in that path, doesn't quite work for 256x256? [Again, no
> > clue what that might be.]
> >
> > It might also be worthwhile just testing if the 256x256 cursor works
> > quite the way one would want. If you're interested, grab libdrm,
> > there's a test called 'modetest', which has an option to enable a
> > moving cursor (-c iirc). It's hard-coded to 64x64, so you'll have to
> > modify it there too (and probably change the pattern from plain gray
> > to any one of the other ones).
>
> I am interested, so I did.
>
> If I start the test without X running, the sprite of 256x256 cursor always
> contained horizontal lines across it, both with commit reverted and vanilla
> v5.11. Similarly, the 64x64 cursor has no lines across it in both kernels.
>
> The test does not seem to work at all if there is an X server running (using
> modesetting driver): modetest complained about permission denied to set the
> mode, and just sits there, drawing nothing on the displays.
> So I could not run the test in the environment of original problem.
> Am I starting it correctly? Is the change in modetest.c correct?

Looks right. Although TBH I'd just start it on a single display (I
forgot you could even do multiple displays). You should be able to
start it with the X server running if you switch to a vt (and run it
as root). If you can't, that means the modesetting driver is
forgetting to do something in the LeaveVT function.

The fact that you're getting lines with modetest means there's
something wrong with 256x256. What if you do 128x128 -- does that work
OK?

Simon, you tested on a GK208, that has a slightly later display
controller than the GK104 -- can you try to reproduce Alex's results?
Perhaps there was a problem with the GK10x's and it starts working OK
with the GK110 disp.

I don't have any GK10x's in my posession (I have nearly every other
iteration of the display controller), but hopefully someone on the
nouveau team will be able to dig one up and reproduce.

Thanks for testing, Alex!

>
> $ ./modetest -c |grep '^[0-9]\|preferred'
> 85  86  connected   LVDS-1  340x190 13  86
>   #0 1920x1080 60.01 1920 2010 2070 2226 1080 1086 1095 1142 152540 
> flags: phsync, nvsync; type: preferred, driver
> 87  89  connected   DP-1470x300 18  88, 89
>   #0 1680x1050 59.88 1680 1728 1760 1840 1050 1053 1059 1080 119000 
> flags: phsync, nvsync; type: preferred, driver
> 90  0   disconnectedDP-20x0 0   91, 92
> 93  95  connected   DP-3520x320 10  94, 95
>   #0 1920x1200 59.95 1920 1968 2000 2080 1200 1203 1209 1235 154000 
> flags: phsync, nvsync; type: preferred, driver
> 96  0   disconnectedVGA-1   0x0 0   97
>
> $ ./modetest -s 85:1920x1080 -s 93:1920x1200 -s 87:1680x1050  -C
> trying to open device 'i915'...failed
> trying to open device 'amdgpu'...failed
> trying to open device 'radeon'...failed
> trying to open device 'nouveau'...done
> setting mode 1920x1080-60.01Hz on connectors 85, crtc 50
> starting cursor
>
> cursor stopped
>
> This is the change on top of 1225171b (master):
>
> diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
> index fc75383a..cdba7b4e 100644
> --- a/tests/modetest/modetest.c
> +++ b/tests/modetest/modetest.c
> @@ -1730,14 +1730,14 @@ static void set_cursors(struct device *dev, struct 
> pipe_arg *pipes, unsigned int
> int ret;
>
> /* maybe make cursor width/height configurable some day */
> -   uint32_t cw = 64;
> -

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Ilia Mirkin]

On Tue, Feb 23, 2021 at 11:23 AM Alex Riesen
 wrote:
>
> Alex Riesen, Tue, Feb 23, 2021 16:51:26 +0100:
> > Ilia Mirkin, Tue, Feb 23, 2021 16:46:52 +0100:
> > > I'd recommend using xf86-video-nouveau in any case, but some distros
> >
> > I would like try this out. Do you know how to force the xorg server to
> > choose this driver instead of modesetting?
>
> Found that myself (a Device section with Driver set to "nouveau"):
>
> $ xrandr  --listproviders
> Providers: number : 1
> Provider 0: id: 0x68 cap: 0x7, Source Output, Sink Output, Source Offload 
> crtcs: 4 outputs: 5 associated providers: 0 name:nouveau
>
> And yes, the cursor looks good in v5.11 even without reverting the commit.

FWIW it's not immediately apparent to me what grave error modesetting
is committing in setting the cursor. The logic looks perfectly
reasonable. It's not trying to be fancy with rendering the cursor/etc.

The one thing is that it's using drmModeSetCursor2 which sets the
hotspot at the same time. But internally inside nouveau I think it
should work out to the same thing. Perhaps setting the hotspot, or
something in that path, doesn't quite work for 256x256? [Again, no
clue what that might be.]

It might also be worthwhile just testing if the 256x256 cursor works
quite the way one would want. If you're interested, grab libdrm,
there's a test called 'modetest', which has an option to enable a
moving cursor (-c iirc). It's hard-coded to 64x64, so you'll have to
modify it there too (and probably change the pattern from plain gray
to any one of the other ones).

Cheers,

  -ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Ilia Mirkin]

On Tue, Feb 23, 2021 at 10:36 AM Alex Riesen
 wrote:
>
> Ilia Mirkin, Tue, Feb 23, 2021 15:56:21 +0100:
> > On Tue, Feb 23, 2021 at 9:26 AM Alex Riesen  
> > wrote:
> > > Lyude Paul, Tue, Jan 19, 2021 02:54:13 +0100:
> > > > diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
> > > > b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > > > index c6367035970e..5f4f09a601d4 100644
> > > > --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > > > +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > > > @@ -2663,6 +2663,14 @@ nv50_display_create(struct drm_device *dev)
> > > >   else
> > > >   nouveau_display(dev)->format_modifiers = 
> > > > disp50xx_modifiers;
> > > >
> > > > + if (disp->disp->object.oclass >= GK104_DISP) {
> > > > + dev->mode_config.cursor_width = 256;
> > > > + dev->mode_config.cursor_height = 256;
> > > > + } else {
> > > > + dev->mode_config.cursor_width = 64;
> > > > + dev->mode_config.cursor_height = 64;
> > > > + }
> > > > +
> > > >   /* create crtc objects to represent the hw heads */
> > > >   if (disp->disp->object.oclass >= GV100_DISP)
> > > >   crtcs = nvif_rd32(>object, 0x610060) & 0xff;
> > >
> > > This change broke X cursor in my setup, and reverting the commit restores 
> > > it.
> > >
> > > Dell Precision M4800, issue ~2014 with GK106GLM [Quadro K2100M] (rev a1).
> > > libdrm 2.4.91-1 (Debian 10.8 stable).
> > > There are no errors or warnings in Xorg logs nor in the kernel log.
> >
> > Could you confirm which ddx is driving the nvidia hw? You can find
> > this out by running "xrandr --listproviders", or also in the xorg log.
>
> xrandr(1) does not seem to list much:
>
> $ xrandr --listproviders
> Providers: number : 1
> Provider 0: id: 0x48 cap: 0xf, Source Output, Sink Output, Source Offload, 
> Sink Offload crtcs: 4 outputs: 5 associated providers: 0 name:modesetting

Thanks - this is what I was looking for. name:modesetting, i.e. the
modesetting ddx driver.

I checked nouveau source, and it seems like it uses a 64x64 cursor no
matter what. Not sure what the modesetting ddx does.

I'd recommend using xf86-video-nouveau in any case, but some distros
have decided to explicitly force modesetting in preference of nouveau.
Oh well. (And regardless, the regression should be addressed somehow,
but it's also good to understand what the problem is.)

Can you confirm what the problem with the cursor is?

  -ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace

[Ilia Mirkin]

On Tue, Feb 23, 2021 at 9:26 AM Alex Riesen
 wrote:
>
> Lyude Paul, Tue, Jan 19, 2021 02:54:13 +0100:
> > diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
> > b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > index c6367035970e..5f4f09a601d4 100644
> > --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > @@ -2663,6 +2663,14 @@ nv50_display_create(struct drm_device *dev)
> >   else
> >   nouveau_display(dev)->format_modifiers = disp50xx_modifiers;
> >
> > + if (disp->disp->object.oclass >= GK104_DISP) {
> > + dev->mode_config.cursor_width = 256;
> > + dev->mode_config.cursor_height = 256;
> > + } else {
> > + dev->mode_config.cursor_width = 64;
> > + dev->mode_config.cursor_height = 64;
> > + }
> > +
> >   /* create crtc objects to represent the hw heads */
> >   if (disp->disp->object.oclass >= GV100_DISP)
> >   crtcs = nvif_rd32(>object, 0x610060) & 0xff;
>
> This change broke X cursor in my setup, and reverting the commit restores it.
>
> Dell Precision M4800, issue ~2014 with GK106GLM [Quadro K2100M] (rev a1).
> libdrm 2.4.91-1 (Debian 10.8 stable).
> There are no errors or warnings in Xorg logs nor in the kernel log.

Hi Alex,

Could you confirm which ddx is driving the nvidia hw? You can find
this out by running "xrandr --listproviders", or also in the xorg log.

Thanks,

  -ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] nouveau 1.0.17 and GT-710 (GK208B): graphics stack freezes when turning off display

[Ilia Mirkin]

No, you still need nouveau. Just add an xorg.conf which has Driver
"modesetting" rather than Driver "nouveau".

On Tue, Feb 9, 2021 at 3:43 PM Uwe Sauter  wrote:
>
> Re-adding the list to receipients as it got lost.
>
>
> I'm unsure how to configure the modeset ddx. Do I need to rebuild my initrd 
> so it does not include the nouveau driver?
> Do I need to blacklist nouveau?
>
>
> Am 09.02.21 um 21:34 schrieb Ilia Mirkin:
> > I don't see any indication of a nouveau failure here. You could try
> > with the modeset ddx, perhaps the nouveau ddx gets hung up somehow.
> >
> > On Tue, Feb 9, 2021 at 3:32 PM Uwe Sauter  wrote:
> >>
> >> When I stop the X server I fall back to the console and I can through vt1 
> >> to vt6.
> >>
> >> Starting X another time brings me back to a desktop where the seconds in 
> >> the clock applet are counting. Pulling a frame
> >> around desktop symbols is working and applications started from the panel 
> >> show their window.
> >>
> >> What's strange is that the issue doesn't occur when using the proprietary 
> >> drivers. Do you really think that the driver
> >> would make a difference for Mate?
> >>
> >> Attached are the logs from the second run.
> >>
> >> Am 09.02.21 um 21:11 schrieb Ilia Mirkin:
> >>> And presumably at the point where the display was turned back on, the
> >>> image was stuck? There are no prints in dmesg here, which means you're
> >>> not getting a traditional error... although curiously the stream of
> >>> framebuffer creations stops too. Maybe not a kernel issue after all?
> >>> Could it be MATE getting stuck somehow? Perhaps it waits for some
> >>> event and doesn't get it?
> >>>
> >>> What happens if you restart X after it gets into this stuck state?
> >>>
> >>> On Tue, Feb 9, 2021 at 2:57 PM Uwe Sauter  wrote:
> >>>>
> >>>> Hi Ilia,
> >>>>
> >>>> this is a first shot on getting the logs.
> >>>>
> >>>> Does the list allow attachments? Else I need to find a place where I can 
> >>>> upload the files.
> >>>>
> >>>> The dmesg log was created with kernel command line arguments 
> >>>> "log_buf_len=16M drm.debug=12".
> >>>>
> >>>> I have indicated within the file when the desktop environment was ready, 
> >>>> when the display was turned off by the
> >>>> screensaver and back on when moving the mouse. I then stopped the X 
> >>>> server.
> >>>>
> >>>> Please let me know if this test should be repeated with more verbose 
> >>>> settings or if other log files are required, too.
> >>>>
> >>>>
> >>>> Regards,
> >>>>
> >>>>   Uwe
> >>>>
> >>>>
> >>>> Am 08.02.21 um 23:32 schrieb Ilia Mirkin:
> >>>>> The referenced issue is a context switching error / timeout. Is that
> >>>>> what you're seeing?
> >>>>>
> >>>>> Is there anything in dmesg when the problem occurs? Can you reproduce
> >>>>> it by forcing the monitor to sleep (xset s off or equivalent)?
> >>>>>
> >>>>> What you're describing sounds most like a display engine hang. Cursor
> >>>>> position updates happen on another channel, so that makes sense it
> >>>>> keeps working. Usually when there's an error, we'll print what the
> >>>>> failing transition was. But sometimes that info isn't available, and
> >>>>> it just says "timeout" a lot on the core channel. In that case, we'll
> >>>>> have to enable more logging.
> >>>>>
> >>>>> On Mon, Feb 8, 2021 at 4:58 PM Uwe Sauter  
> >>>>> wrote:
> >>>>>>
> >>>>>> Hello,
> >>>>>>
> >>>>>> I don't know if this is the appropriate list to post; if not please 
> >>>>>> point me in the right direction.
> >>>>>>
> >>>>>>
> >>>>>> I have an issue with the nouveau driver for a GT 710 (GK208B) card, 
> >>>>>> hardware details and software versions below.
> >>>>>> Once the X server decides to switch into power saving mode and turns 
> >>>>>> t

Re: [Nouveau] nouveau 1.0.17 and GT-710 (GK208B): graphics stack freezes when turning off display

[Ilia Mirkin]

And presumably at the point where the display was turned back on, the
image was stuck? There are no prints in dmesg here, which means you're
not getting a traditional error... although curiously the stream of
framebuffer creations stops too. Maybe not a kernel issue after all?
Could it be MATE getting stuck somehow? Perhaps it waits for some
event and doesn't get it?

What happens if you restart X after it gets into this stuck state?

On Tue, Feb 9, 2021 at 2:57 PM Uwe Sauter  wrote:
>
> Hi Ilia,
>
> this is a first shot on getting the logs.
>
> Does the list allow attachments? Else I need to find a place where I can 
> upload the files.
>
> The dmesg log was created with kernel command line arguments "log_buf_len=16M 
> drm.debug=12".
>
> I have indicated within the file when the desktop environment was ready, when 
> the display was turned off by the
> screensaver and back on when moving the mouse. I then stopped the X server.
>
> Please let me know if this test should be repeated with more verbose settings 
> or if other log files are required, too.
>
>
> Regards,
>
> Uwe
>
>
> Am 08.02.21 um 23:32 schrieb Ilia Mirkin:
> > The referenced issue is a context switching error / timeout. Is that
> > what you're seeing?
> >
> > Is there anything in dmesg when the problem occurs? Can you reproduce
> > it by forcing the monitor to sleep (xset s off or equivalent)?
> >
> > What you're describing sounds most like a display engine hang. Cursor
> > position updates happen on another channel, so that makes sense it
> > keeps working. Usually when there's an error, we'll print what the
> > failing transition was. But sometimes that info isn't available, and
> > it just says "timeout" a lot on the core channel. In that case, we'll
> > have to enable more logging.
> >
> > On Mon, Feb 8, 2021 at 4:58 PM Uwe Sauter  wrote:
> >>
> >> Hello,
> >>
> >> I don't know if this is the appropriate list to post; if not please point 
> >> me in the right direction.
> >>
> >>
> >> I have an issue with the nouveau driver for a GT 710 (GK208B) card, 
> >> hardware details and software versions below.
> >> Once the X server decides to switch into power saving mode and turns the 
> >> display off using DPMS some part of the
> >> graphics stack seems to freeze. I can wake up the display and it will show 
> >> me the last picture but most of the
> >> functionality is still frozen. I can move the mouse pointer but the clock 
> >> applet won't show the current time and
> >> selecting desktop icons does not work.
> >> It seems that I can still start programs from the panel (I can see the 
> >> process when remotely logging in) but they
> >> produce no graphics output.
> >>
> >> This happens in either of the two clock settings I can set in 
> >> /sys/kernel/debug/dri/0/pstate .
> >>
> >>
> >> The proprietary driver does not show this behavior but seems to be much 
> >> slower with glxgears, though this is not a
> >> proper benchmark, I know. The results between nouveau and nvidia are about 
> >> the same when nouveau is in the low pstate
> >> but performance almost triples when the high pstate is configured.
> >>
> >> I bought this card just recently because it was said to be the last model 
> >> that was properly usable without the
> >> proprietary driver.
> >>
> >> As you can see below, I'm already running xf86-video-nouveau 1.0.17 but 
> >> compiling from git shouldn't be a problem if
> >> necessary.
> >>
> >> Currently the nvidia driver is in use but I should be able to quickly 
> >> switch back to nouveau for any logs that might be
> >> required.
> >>
> >> Please advise what logs (and log levels) are needed in order to get to the 
> >> bottom of this.
> >>
> >>
> >> This bug reports also describes what I see:
> >>
> >> https://gitlab.freedesktop.org/mesa/mesa/-/issues/1171#note_385608
> >>
> >>
> >>
> >>
> >> Regards,
> >>
> >>  Uwe
> >>
> >>
> >>
> >> ### hardware ###
> >> CPU: AMD Ryzen 3 3100
> >> Mainboard: Gigabyte B550M S2H, Bios F13a with AMD AGESA ComboV2 1.2.0.0
> >> RAM: 2x 16GB Kingston DDR4 3200MHz ECC
> >> GPU: ASUS GT710-4H-SL-2GD5, 2GB GDDR5, 4x HDMI, VideoBIOS: 80.28.b8.00.05
> >> Display: ViewSonic VP2468
> >> 
> >>
>

Re: [Nouveau] nouveau 1.0.17 and GT-710 (GK208B): graphics stack freezes when turning off display

[Ilia Mirkin]

The referenced issue is a context switching error / timeout. Is that
what you're seeing?

Is there anything in dmesg when the problem occurs? Can you reproduce
it by forcing the monitor to sleep (xset s off or equivalent)?

What you're describing sounds most like a display engine hang. Cursor
position updates happen on another channel, so that makes sense it
keeps working. Usually when there's an error, we'll print what the
failing transition was. But sometimes that info isn't available, and
it just says "timeout" a lot on the core channel. In that case, we'll
have to enable more logging.

On Mon, Feb 8, 2021 at 4:58 PM Uwe Sauter  wrote:
>
> Hello,
>
> I don't know if this is the appropriate list to post; if not please point me 
> in the right direction.
>
>
> I have an issue with the nouveau driver for a GT 710 (GK208B) card, hardware 
> details and software versions below.
> Once the X server decides to switch into power saving mode and turns the 
> display off using DPMS some part of the
> graphics stack seems to freeze. I can wake up the display and it will show me 
> the last picture but most of the
> functionality is still frozen. I can move the mouse pointer but the clock 
> applet won't show the current time and
> selecting desktop icons does not work.
> It seems that I can still start programs from the panel (I can see the 
> process when remotely logging in) but they
> produce no graphics output.
>
> This happens in either of the two clock settings I can set in 
> /sys/kernel/debug/dri/0/pstate .
>
>
> The proprietary driver does not show this behavior but seems to be much 
> slower with glxgears, though this is not a
> proper benchmark, I know. The results between nouveau and nvidia are about 
> the same when nouveau is in the low pstate
> but performance almost triples when the high pstate is configured.
>
> I bought this card just recently because it was said to be the last model 
> that was properly usable without the
> proprietary driver.
>
> As you can see below, I'm already running xf86-video-nouveau 1.0.17 but 
> compiling from git shouldn't be a problem if
> necessary.
>
> Currently the nvidia driver is in use but I should be able to quickly switch 
> back to nouveau for any logs that might be
> required.
>
> Please advise what logs (and log levels) are needed in order to get to the 
> bottom of this.
>
>
> This bug reports also describes what I see:
>
> https://gitlab.freedesktop.org/mesa/mesa/-/issues/1171#note_385608
>
>
>
>
> Regards,
>
> Uwe
>
>
>
> ### hardware ###
> CPU: AMD Ryzen 3 3100
> Mainboard: Gigabyte B550M S2H, Bios F13a with AMD AGESA ComboV2 1.2.0.0
> RAM: 2x 16GB Kingston DDR4 3200MHz ECC
> GPU: ASUS GT710-4H-SL-2GD5, 2GB GDDR5, 4x HDMI, VideoBIOS: 80.28.b8.00.05
> Display: ViewSonic VP2468
> 
>
> ### software ###
> Arch Linux
> Kernel: 5.10.13-arch1-2
> linux-firmware: 20201218.646f159-1
> mate-desktop: 1.24.1-1
> Mesa: 20.3.4-1
> xorg-server: 1.20.10-3
> xf86-video-nouveau: 1.0.17-1
>
> alternatively:
> nvidia-dkms: 460.39-1
> #
>
> ### lspci fpr GPU ###
> # lspci -s 3:0.0 -v | head -n 2
> #03:00.0 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT 
> 710] (rev a1) (prog-if 00 [VGA controller])
> Subsystem: ASUSTeK Computer Inc. Device 8770
>
> # lspci -s 3:0.0 -vvn
> 03:00.0 0300: 10de:128b (rev a1) (prog-if 00 [VGA controller])
> Subsystem: 1043:8770
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
> SERR-  Latency: 0
> Interrupt: pin A routed to IRQ 55
> IOMMU group: 12
> Region 0: Memory at fb00 (32-bit, non-prefetchable) [size=16M]
> Region 1: Memory at fff000 (64-bit, prefetchable) [size=128M]
> Region 3: Memory at fff800 (64-bit, prefetchable) [size=32M]
> Region 5: I/O ports at f000 [size=128]
> Expansion ROM at fc00 [virtual] [disabled] [size=512K]
> Capabilities: [60] Power Management version 3
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
> Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+
> Address: fee0  Data: 
> Capabilities: [78] Express (v2) Legacy Endpoint, MSI 00
> DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s 
> unlimited, L1 <64us
> ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
> DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-
> RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+
> MaxPayload 128 bytes, MaxReadReq 512 bytes
> DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- 
> TransPend-
> LnkCap: Port #6, Speed 5GT/s, Width x8, 

Re: [Nouveau] [RFC v3 05/10] drm/i915/dpcd_bl: Cleanup intel_dp_aux_vesa_enable_backlight() a bit

[Ilia Mirkin]

On Fri, Feb 5, 2021 at 6:45 PM Lyude Paul  wrote:
>
> Get rid of the extraneous switch case in here, and just open code
> edp_backlight_mode as we only ever use it once.
>
> Signed-off-by: Lyude Paul 
> ---
>  .../gpu/drm/i915/display/intel_dp_aux_backlight.c | 15 ++-
>  1 file changed, 2 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
> b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> index c37ccc8538cb..95e3e344cf40 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> @@ -382,7 +382,7 @@ intel_dp_aux_vesa_enable_backlight(const struct 
> intel_crtc_state *crtc_state,
> struct intel_dp *intel_dp = intel_attached_dp(connector);
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> struct intel_panel *panel = >panel;
> -   u8 dpcd_buf, new_dpcd_buf, edp_backlight_mode;
> +   u8 dpcd_buf, new_dpcd_buf;
> u8 pwmgen_bit_count = panel->backlight.edp.vesa.pwmgen_bit_count;
>
> if (drm_dp_dpcd_readb(_dp->aux,
> @@ -393,12 +393,8 @@ intel_dp_aux_vesa_enable_backlight(const struct 
> intel_crtc_state *crtc_state,
> }
>
> new_dpcd_buf = dpcd_buf;
> -   edp_backlight_mode = dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
>
> -   switch (edp_backlight_mode) {
> -   case DP_EDP_BACKLIGHT_CONTROL_MODE_PWM:
> -   case DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET:
> -   case DP_EDP_BACKLIGHT_CONTROL_MODE_PRODUCT:
> +   if ((dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) != 
> DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) {

You probably meant != MODE_DPCD?

> new_dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
> new_dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
>
> @@ -406,13 +402,6 @@ intel_dp_aux_vesa_enable_backlight(const struct 
> intel_crtc_state *crtc_state,
>pwmgen_bit_count) != 1)
> drm_dbg_kms(>drm,
> "Failed to write aux pwmgen bit count\n");
> -
> -   break;
> -
> -   /* Do nothing when it is already DPCD mode */
> -   case DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD:
> -   default:
> -   break;
> }
>
> if (panel->backlight.edp.vesa.pwm_freq_pre_divider) {
> --
> 2.29.2
>
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH v3] nouveau/dispnv50: add cursor pitch check

[Ilia Mirkin]

On Fri, Feb 5, 2021 at 5:24 PM Simon Ser  wrote:
>
> The hardware needs a FB which is packed. Add checks to make sure
> this is the case.
>
> While at it, add debug logs for the existing checks. This allows
> user-space to more easily figure out why a configuration is
> rejected.
>
> v2:
> - Use drm_format_info instead of hardcoding bytes-per-pixel (Ilia)
> - Remove unnecessary size check (Ilia)
>
> v3:
> - Add missing newlines in debug messages (Lyude)
> - Use NV_ATOMIC (Lyude)
> - Add missing debug log for invalid format (Ilia)
>
> Signed-off-by: Simon Ser 
> Reviewed-by: Lyude Paul 
> Cc: Ben Skeggs 
> Cc: Ilia Mirkin 
> ---
>  drivers/gpu/drm/nouveau/dispnv50/curs507a.c | 31 +++--
>  1 file changed, 28 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/curs507a.c 
> b/drivers/gpu/drm/nouveau/dispnv50/curs507a.c
> index 54fbd6fe751d..56459cfd037e 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/curs507a.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/curs507a.c
> @@ -30,6 +30,7 @@
>
>  #include 
>  #include 
> +#include 

Why is this needed?

>
>  bool
>  curs507a_space(struct nv50_wndw *wndw)
> @@ -99,6 +100,8 @@ curs507a_acquire(struct nv50_wndw *wndw, struct 
> nv50_wndw_atom *asyw,
>  struct nv50_head_atom *asyh)
>  {
> struct nv50_head *head = nv50_head(asyw->state.crtc);
> +   struct nouveau_drm *drm = nouveau_drm(head->base.base.dev);
> +   struct drm_framebuffer *fb = asyw->state.fb;
> int ret;
>
> ret = drm_atomic_helper_check_plane_state(>state, >state,
> @@ -109,14 +112,36 @@ curs507a_acquire(struct nv50_wndw *wndw, struct 
> nv50_wndw_atom *asyw,
> if (ret || !asyh->curs.visible)
> return ret;
>
> -   if (asyw->image.w != asyw->image.h)
> +   if (asyw->image.w != asyw->image.h) {
> +   NV_ATOMIC(drm,
> + "Invalid cursor image size: width (%d) must match 
> height (%d)\n",
> + asyw->image.w, asyw->image.h);

Maybe keep with the style of the other NV_ATOMIC's, e.g. include %s:
at the beginning with wndw->plane.name as the value?

Either way,

Reviewed-by: Ilia Mirkin 

> return -EINVAL;
> +   }
> +   if (asyw->image.pitch[0] != asyw->image.w * fb->format->cpp[0]) {
> +   NV_ATOMIC(drm,
> + "Invalid cursor image pitch: image must be packed 
> (pitch = %d, width = %d)\n",
> + asyw->image.pitch[0], asyw->image.w);
> +   return -EINVAL;
> +   }
>
> ret = head->func->curs_layout(head, asyw, asyh);
> -   if (ret)
> +   if (ret) {
> +   NV_ATOMIC(drm,
> + "Invalid cursor image size: unsupported size 
> %dx%d\n",
> + asyw->image.w, asyw->image.h);
> +   return ret;
> +   }
> +
> +   ret = head->func->curs_format(head, asyw, asyh);
> +   if (ret) {
> +   NV_ATOMIC(drm,
> + "Invalid cursor image format 0x%X\n",
> + fb->format->format);
> return ret;
> +   }
>
> -   return head->func->curs_format(head, asyw, asyh);
> +   return 0;
>  }
>
>  static const u32
> --
> 2.30.0
>
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH v2] nouveau/dispnv50: add cursor pitch check

[Ilia Mirkin]

On Fri, Feb 5, 2021 at 4:00 PM Simon Ser  wrote:
>
> The hardware needs a FB which is packed. Add checks to make sure
> this is the case.
>
> While at it, add debug logs for the existing checks. This allows
> user-space to more easily figure out why a configuration is
> rejected.
>
> v2:
> - Use drm_format_info instead of hardcoding bytes-per-pixel (Ilia)
> - Remove unnecessary size check (Ilia)
>
> Signed-off-by: Simon Ser 
> Cc: Lyude Paul 
> Cc: Ben Skeggs 
> Cc: Ilia Mirkin 
> ---
>  drivers/gpu/drm/nouveau/dispnv50/curs507a.c | 21 +++--
>  1 file changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/curs507a.c 
> b/drivers/gpu/drm/nouveau/dispnv50/curs507a.c
> index 54fbd6fe751d..00f09c9a8d15 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/curs507a.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/curs507a.c
> @@ -30,6 +30,7 @@
>
>  #include 
>  #include 
> +#include 
>
>  bool
>  curs507a_space(struct nv50_wndw *wndw)
> @@ -99,6 +100,8 @@ curs507a_acquire(struct nv50_wndw *wndw, struct 
> nv50_wndw_atom *asyw,
>  struct nv50_head_atom *asyh)
>  {
> struct nv50_head *head = nv50_head(asyw->state.crtc);
> +   struct drm_device *dev = head->base.base.dev;
> +   struct drm_framebuffer *fb = asyw->state.fb;
> int ret;
>
> ret = drm_atomic_helper_check_plane_state(>state, >state,
> @@ -109,12 +112,26 @@ curs507a_acquire(struct nv50_wndw *wndw, struct 
> nv50_wndw_atom *asyw,
> if (ret || !asyh->curs.visible)
> return ret;
>
> -   if (asyw->image.w != asyw->image.h)
> +   if (asyw->image.w != asyw->image.h) {
> +   drm_dbg_atomic(dev,
> +  "Invalid cursor image size: width (%d) must 
> match height (%d)",
> +  asyw->image.w, asyw->image.h);
> return -EINVAL;
> +   }
> +   if (asyw->image.pitch[0] != asyw->image.w * fb->format->cpp[0]) {
> +   drm_dbg_atomic(dev,
> +  "Invalid cursor image pitch: image must be 
> packed (pitch = %d, width = %d)",
> +  asyw->image.pitch[0], asyw->image.w);
> +   return -EINVAL;
> +   }
>
> ret = head->func->curs_layout(head, asyw, asyh);
> -   if (ret)
> +   if (ret) {
> +   drm_dbg_atomic(dev,
> +  "Invalid cursor image size: unsupported size 
> %dx%d",
> +  asyw->image.w, asyw->image.h);
> return ret;
> +   }
>
> return head->func->curs_format(head, asyw, asyh);

While you're at it, maybe give this one some love too?

Cheers,

  -ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH] nouveau/dispnv50: add cursor size/pitch checks

[Ilia Mirkin]

On Fri, Feb 5, 2021 at 11:45 AM Simon Ser  wrote:
>
> The hardware needs a FB which is packed and not too large. Add
> checks to make sure this is the case.
>
> While at it, add a debug log for the existing check. This allows
> user-space to more easily figure out why a configuration is
> rejected.
>
> This commit depends on "drm/nouveau/kms/nv50-: Report max cursor
> size to userspace", otherwise mode_config.cursor_{width,height}
> is zero.
>
> Signed-off-by: Simon Ser 
> Cc: Lyude Paul 
> Cc: Ben Skeggs 
> Cc: Ilia Mirkin 
> ---
>  drivers/gpu/drm/nouveau/dispnv50/curs507a.c | 22 -
>  1 file changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/curs507a.c 
> b/drivers/gpu/drm/nouveau/dispnv50/curs507a.c
> index 54fbd6fe751d..9a401751c56d 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/curs507a.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/curs507a.c
> @@ -99,6 +99,7 @@ curs507a_acquire(struct nv50_wndw *wndw, struct 
> nv50_wndw_atom *asyw,
>  struct nv50_head_atom *asyh)
>  {
> struct nv50_head *head = nv50_head(asyw->state.crtc);
> +   struct drm_device *dev = head->base.base.dev;
> int ret;
>
> ret = drm_atomic_helper_check_plane_state(>state, >state,
> @@ -109,8 +110,27 @@ curs507a_acquire(struct nv50_wndw *wndw, struct 
> nv50_wndw_atom *asyw,
> if (ret || !asyh->curs.visible)
> return ret;
>
> -   if (asyw->image.w != asyw->image.h)
> +   if (asyw->image.w != asyw->image.h) {
> +   drm_dbg_atomic(dev,
> +  "Invalid cursor image size: width (%d) must 
> match height (%d)",
> +  asyw->image.w, asyw->image.h);
> return -EINVAL;
> +   }
> +   if (asyw->image.w > dev->mode_config.cursor_width ||
> +   asyw->image.h > dev->mode_config.cursor_height) {
> +   drm_dbg_atomic(dev,
> +  "Invalid cursor image size: too large (%dx%d > 
> %dx%d)",
> +  asyw->image.w, asyw->image.h,
> +  dev->mode_config.cursor_width,
> +  dev->mode_config.cursor_height);
> +   return -EINVAL;
> +   }
> +   if (asyw->image.pitch[0] != asyw->image.w * 4) {

Rather than hard-coding to 4, make this look at the format (or cpp,
which should be available somewhere too I think). (Yeah, currently we
only expose RGBA8, but we should also be doing RGB5A1.)

> +   drm_dbg_atomic(dev,
> +  "Invalid cursor image pitch: image must be 
> packed (pitch = %d, width = %d)",
> +  asyw->image.pitch[0], asyw->image.w);
> +   return -EINVAL;
> +   }
>
> ret = head->func->curs_layout(head, asyw, asyh);

And this will fail due to the width/height not being supported, right?

  -ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Request for help in adding a HDMI output

[Ilia Mirkin]

On Sat, Jan 23, 2021 at 6:09 PM o1bigtenor  wrote:
>
> On Sat, Jan 23, 2021 at 12:52 PM Ilia Mirkin  wrote:
> >
> > On Sat, Jan 23, 2021 at 1:40 PM o1bigtenor  wrote:
> > >
> > > On Sat, Jan 23, 2021 at 10:55 AM Ilia Mirkin  wrote:
> > > >
> > > > On Fri, Jan 22, 2021 at 2:13 PM o1bigtenor  wrote:
> > > > >
> > > > > On Fri, Jan 22, 2021 at 12:26 PM Ilia Mirkin  
> > > > > wrote:
> > > > > snip
> > >
> > > I've been doing a bunch of research and have a whole lot more input but 
> > > still
> > > can't find any answers - - - - except holes where there 'should be' 
> > > answers.
> > >338.75  3840 4080 4488 5136  2160 2163 2168 2200 -hsync +vsync
> > > I also understand you're trying to help but some of the stuff you've
> > > been stating
> > > - - - well - - - it just ain't so! - - - - so if you'd rather not
> > > continue - - - - fair enough
> > > - - - -
> >
> > No one's perfect. I have to make do with guesses which are the
> > simplest explanations. Sometimes there's something else.
> >
> > > >
> > > > Unfortunately it looks like you did this *after* messing with modelines.
> > > >
> > > Getting that information would have meant being able to go back in time 
> > > some
> > > 24 hours or so. I can't find any way of removing mode lines from xrandr - 
> > > - -
> > > or do you know of some?338.75  3840 4080 4488 5136  2160 2163 2168 2200 
> > > -hsync +vsync
> >
> > A reboot is a great way to reset these things.
>
> Unfortunately- - - - here - - - - a reboot means the use of about 30 minutes
> in using xrandr to connect monitors 3 and 4 (even without the HDMI I'm
> working on) and then setting up everything else on my system (only 20 desktops
> and almost all of the them are loaded) so reboots are used as seldom as
> possible.
> >
> > > > >
> > > > > $ xrandr --verbose
> > > >
> > > > [ ... snip ...]
> > > >
> > > > > HDMI-1-2 connected (normal left inverted right x axis y axis)
> > > > > Identifier: 0xf9
> > > > > Timestamp:  483290
> > > > > Subpixel:   unknown
> > > > > Clones:
> > > > > CRTCs:  4 5
> > > > > Transform:  1.00 0.00 0.00
> > > > > 0.00 1.00 0.00
> > > > > 0.00 0.00 1.00
> > > > >filter:
> > > > > EDID:
> > > > > 000020a32f000100
> > > > > 0c1a0103807341780acf74a3574cb023
> > > > > 09484c21080081c08140818001010101
> > > > > 01010101010104740030f2705a80b058
> > > > > 8a00501d741e023a801871382d40
> > > > > 582c4500501d741e00fc0048
> > > > > 4953454e53450a202020202000fd
> > > > > 00184b0f511e000a202020202020017f
> > > > > 02034571525f5e5d0102040510111314
> > > > > 1f202122626364290907071507505506
> > > > > 008301e200f9e305ff016e030c00
> > > > > 1000383c20008001020304e50e60616a
> > > > > 6be3060d01011d8018711c1620582c25
> > > > > 00c48e219e011d80d0721c162010
> > > > > 2c2580c48e219e023a80d072382d
> > > > > 40102c4580c48e211ed5
> > > >
> > > > OK, so this is your 4k monitor. It is plugged into the *secondary*
> > > > GPU, and does not report any 4k@60 modes in the EDID (well, it does
> > > > report 4k@60 YUV 4:2:0 modes, but we don't support those in nouveau at
> > > > this time). Whether that's because the monitor itself doesn't support
> > > > HDMI 2.0, or you plugged it into your old GPU which does not support
> > > > HDMI 2.0, I couldn't say from just this output. What I can say is that
> > > > no amount of modelines will get you 4k@60 in this setup with nouveau.
> > >
> > > Here comes the part where you're getting some very funky information
> > > and I wish I knew from where!
> > > Actually the code, in hex, is NOT EDID - - - - that was superseded in
> > > some 2017. Now that may be what nouveau is using but EDID2.0 was
> > > released some time in 2007 yet its EDID1.4 that is used. That's the first
> > > problem and it introduces the next problems. Using EDID means that
> > > nouveau 'thinks' it see  a : (taken from /var/log/Xorg.0.log)
> >
> > EDID is

[Nouveau] [ANNOUNCE] xf86-video-nouveau 1.0.17

[Ilia Mirkin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Carlo Caione (1):
  Don't advertise any PRIME offloading capabilities without acceleration

Ilia Mirkin (8):
  nv4/exa: tiling is unsupported pre-nv10, reduce alignment requirements
  dri2,present: move in pixmap before getting addresses
  make error when failing to allocate surface more descriptive
  drmmode: fix screen resize without acceleration
  present: don't enable if there's no acceleration
  drmmode: make event handler leave a note that there are stuck events
  present: fix handling of drmWaitVBlank failures
  Bump version to 1.0.17

git tag: xf86-video-nouveau-1.0.17

https://xorg.freedesktop.org/archive/individual/driver/xf86-video-nouveau-1.0.17.tar.bz2
SHA256: 499322e27a55c8183166bf2dd1e47d085eb834143e0d7036baba8427b90c156b  
xf86-video-nouveau-1.0.17.tar.bz2
SHA512: 
adba58ba5298d1a5b3f9f8540f9ef2cb2e10e47bba8e374103ec2e1f92e915f5f4393ed0021168cd649646e12315135a1efcdf77e8fb1648e1295914d87279b2
  xf86-video-nouveau-1.0.17.tar.bz2
PGP:  
https://xorg.freedesktop.org/archive/individual/driver/xf86-video-nouveau-1.0.17.tar.bz2.sig

https://xorg.freedesktop.org/archive/individual/driver/xf86-video-nouveau-1.0.17.tar.gz
SHA256: 21e9233b2c6304b976c526729ba48660c16976a757a319fa95cc8a8605316105  
xf86-video-nouveau-1.0.17.tar.gz
SHA512: 
10336f521d39289b214ce640b8b7195f4709ab780a4057ba83d02c2f3b4f7c7b17e37cf5f3224c43bf39aa8939a8836be1ee9eb26901d713cb98d161db2375e9
  xf86-video-nouveau-1.0.17.tar.gz
PGP:  
https://xorg.freedesktop.org/archive/individual/driver/xf86-video-nouveau-1.0.17.tar.gz.sig

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEv7mwwnbVdnxxAIbvsXi+TqB13gcFAmAMdncACgkQsXi+TqB1
3gdS/Qf+NuLPs8PKUjwyEZNl5pDchnRkqsNVie22oguVUqhI0VgLYjBxPBwvoiZz
iyDJwRSIRgIR5YwIjz/YZ4SBx2TI7pESjxfYAAowOmxMNe3jiQIOC8OChmQFPEtl
a9NdiKJifpex34y+YnXwZjGqUo1aG489DPCjeOKH4WoNB19LlV6sD1bHj2QxLAUc
lqzZ2Hq8Nb6RVb0LRyywEccMA1jRlW0re1W8/3igBznPUunk8hznGpbFDtmUvVqc
sOvkW1iwP8BWt0/pVG2iikIhaQvtrWF5+9XgqjC72RCo4iaGycJCS/GvQV6xWVVk
L3AvL1HjlKLc9xIMQcp/44vkhPKJTw==
=6/s4
-END PGP SIGNATURE-
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Request for help in adding a HDMI output

[Ilia Mirkin]

On Sat, Jan 23, 2021 at 1:40 PM o1bigtenor  wrote:
>
> On Sat, Jan 23, 2021 at 10:55 AM Ilia Mirkin  wrote:
> >
> > On Fri, Jan 22, 2021 at 2:13 PM o1bigtenor  wrote:
> > >
> > > On Fri, Jan 22, 2021 at 12:26 PM Ilia Mirkin  wrote:
> > > snip
>
> I've been doing a bunch of research and have a whole lot more input but still
> can't find any answers - - - - except holes where there 'should be' answers.
>
> I also understand you're trying to help but some of the stuff you've
> been stating
> - - - well - - - it just ain't so! - - - - so if you'd rather not
> continue - - - - fair enough
> - - - -

No one's perfect. I have to make do with guesses which are the
simplest explanations. Sometimes there's something else.

> >
> > Unfortunately it looks like you did this *after* messing with modelines.
> >
> Getting that information would have meant being able to go back in time some
> 24 hours or so. I can't find any way of removing mode lines from xrandr - - -
> or do you know of some?

A reboot is a great way to reset these things.

> > >
> > > $ xrandr --verbose
> >
> > [ ... snip ...]
> >
> > > HDMI-1-2 connected (normal left inverted right x axis y axis)
> > > Identifier: 0xf9
> > > Timestamp:  483290
> > > Subpixel:   unknown
> > > Clones:
> > > CRTCs:  4 5
> > > Transform:  1.00 0.00 0.00
> > > 0.00 1.00 0.00
> > > 0.00 0.00 1.00
> > >filter:
> > > EDID:
> > > 000020a32f000100
> > > 0c1a0103807341780acf74a3574cb023
> > > 09484c21080081c08140818001010101
> > > 01010101010104740030f2705a80b058
> > > 8a00501d741e023a801871382d40
> > > 582c4500501d741e00fc0048
> > > 4953454e53450a202020202000fd
> > > 00184b0f511e000a202020202020017f
> > > 02034571525f5e5d0102040510111314
> > > 1f202122626364290907071507505506
> > > 008301e200f9e305ff016e030c00
> > > 1000383c20008001020304e50e60616a
> > > 6be3060d01011d8018711c1620582c25
> > > 00c48e219e011d80d0721c162010
> > > 2c2580c48e219e023a80d072382d
> > > 40102c4580c48e211ed5
> >
> > OK, so this is your 4k monitor. It is plugged into the *secondary*
> > GPU, and does not report any 4k@60 modes in the EDID (well, it does
> > report 4k@60 YUV 4:2:0 modes, but we don't support those in nouveau at
> > this time). Whether that's because the monitor itself doesn't support
> > HDMI 2.0, or you plugged it into your old GPU which does not support
> > HDMI 2.0, I couldn't say from just this output. What I can say is that
> > no amount of modelines will get you 4k@60 in this setup with nouveau.
>
> Here comes the part where you're getting some very funky information
> and I wish I knew from where!
> Actually the code, in hex, is NOT EDID - - - - that was superseded in
> some 2017. Now that may be what nouveau is using but EDID2.0 was
> released some time in 2007 yet its EDID1.4 that is used. That's the first
> problem and it introduces the next problems. Using EDID means that
> nouveau 'thinks' it see  a : (taken from /var/log/Xorg.0.log)

EDID is very much a thing, and is basically the only thing. Things
like DisplayID are extension blocks to the EDID.

> So where are we at now - - - - -
> well there is NO HDMI port on the EVGA Nvidia 570 card

OK, that was a bad guess on my part to explain what I was seeing.

> HDMI cable IS plugged in and there is only only place for it to be plugged
>   in - - - - so the HDMI cable is plugged into the Nvidia 1050 Ti card

Cool. So then what you said was incorrect -- the GTX 570 is the
primary, and the 1050 is secondary. Please flip that around.

> EDID really is way beyond EOL
> Information provided by the EDID reading is most likely erroneous
> Nouveau at lest doesn't seem to have gotten to DisplayID where the current,
>at least as of 2017, version is 2.0
> if DisplayID were used perhaps the information  listed as taken from my system
>might be accurate

EDID is the only way for a monitor to provide information. DisplayID
is a block within the EDID. You can access a relatively full-featured
parser at https://people.freedesktop.org/~imirkin/edid-decode/ -- just
paste the hex there.

>
> >
> > >   3840x2160_60.00 (0x6ce) 712.750MHz -HSync +VSync
> > > h: width  3840 start 4160 end 4576 total 5312 skew0 clock 
> > > 134.18KHz
> > > v: height 2160 start 2163 end 2168 total 2237   clock  
> > > 59.98Hz
> > >   3840x2160R (0x70c) 533.000MHz +HS

Re: [Nouveau] Request for help in adding a HDMI output

[Ilia Mirkin]

On Fri, Jan 22, 2021 at 2:13 PM o1bigtenor  wrote:
>
> On Fri, Jan 22, 2021 at 12:26 PM Ilia Mirkin  wrote:
> snip
> > Can you provide the output of "xrandr --verbose" before you've messed
> > around with anything like modelines/etc?
> >
>
> Its huge - - -

Unfortunately it looks like you did this *after* messing with modelines.

>
> $ xrandr --verbose

[ ... snip ...]

> HDMI-1-2 connected (normal left inverted right x axis y axis)
> Identifier: 0xf9
> Timestamp:  483290
> Subpixel:   unknown
> Clones:
> CRTCs:  4 5
> Transform:  1.00 0.00 0.00
> 0.00 1.00 0.00
> 0.00 0.00 1.00
>filter:
> EDID:
> 000020a32f000100
> 0c1a0103807341780acf74a3574cb023
> 09484c21080081c08140818001010101
> 01010101010104740030f2705a80b058
> 8a00501d741e023a801871382d40
> 582c4500501d741e00fc0048
> 4953454e53450a202020202000fd
> 00184b0f511e000a202020202020017f
> 02034571525f5e5d0102040510111314
> 1f202122626364290907071507505506
> 008301e200f9e305ff016e030c00
> 1000383c20008001020304e50e60616a
> 6be3060d01011d8018711c1620582c25
> 00c48e219e011d80d0721c162010
> 2c2580c48e219e023a80d072382d
> 40102c4580c48e211ed5

OK, so this is your 4k monitor. It is plugged into the *secondary*
GPU, and does not report any 4k@60 modes in the EDID (well, it does
report 4k@60 YUV 4:2:0 modes, but we don't support those in nouveau at
this time). Whether that's because the monitor itself doesn't support
HDMI 2.0, or you plugged it into your old GPU which does not support
HDMI 2.0, I couldn't say from just this output. What I can say is that
no amount of modelines will get you 4k@60 in this setup with nouveau.

>   3840x2160_60.00 (0x6ce) 712.750MHz -HSync +VSync
> h: width  3840 start 4160 end 4576 total 5312 skew0 clock 
> 134.18KHz
> v: height 2160 start 2163 end 2168 total 2237   clock  59.98Hz
>   3840x2160R (0x70c) 533.000MHz +HSync -VSync
> h: width  3840 start 3888 end 3920 total 4000 skew0 clock 
> 133.25KHz
> v: height 2160 start 2163 end 2168 total    clock  59.97Hz

And this is how I know you've messed with modelines. The whole point
of the above question was to see the pre-messing-with-modelines state.
This is not the default setup. The NVIDIA GTX 570 can only handle up
to 225mhz by default over HDMI, which isn't enough for the 4k@30 modes
either. If you think it can handle more, you can try to override that
with the hdmimhz parameter. However I'd strongly recommend plugging
the 4k screen into the GTX 1050, as even if it did work on the
secondary GPU, sending a 4k screen to a remote GPU is really not a
great idea.

Cheers,

  -ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Request for help in adding a HDMI output

[Ilia Mirkin]

On Fri, Jan 22, 2021 at 12:12 PM o1bigtenor  wrote:
>
> On Fri, Jan 22, 2021 at 8:30 AM Ilia Mirkin  wrote:
> >
> > On Thu, Jan 21, 2021 at 9:59 PM o1bigtenor  wrote:
> > >
> > > Greetings
> > >
> > > Running a debian testing system
> > > $ uname -r
> > > 5.4.0-4-amd64
> > > with 2 graphics cards.
> > > The one I'm working on is a: GP 107 Nvidia  GTX 1050 Ti
> > >
> > > Asus ROG GeForce GX 1050 Ti Strix-GTX1050 Ti with 2 - DVI plus 1 DP1.4
> > > and I HDMI2.0 ports (four in total).
> > >
> > > I have been running 2 1920x1080 monitors on this card (and its
> > > previous nvidia 570) for quite some time. Been running nouveau for the
> > > last about 4 years as my last nvidia 570 (started with 3) is EOL by
> > > nvidia.
>
> > Cheers,
> >
> >   -ilia
> > > Have gotten quite comfortable using xrandr setting up the second card
> > > (the nvidia 570) and its 2 monitors. Nouveau software is:
> > > xserver-xorg-video-nouveau -> 1:1.0.16-1 ;
> > > xserver-xorg -> 1:7.7+21 ; and libdrm-nouveau2:amd64 -> 2.4.102-1 .
> > >
> > > I want to add a 4k TV onto the HDMI port on card #1.
> > > Can't seem to get the card and the TV talking.
> >
> > Unfortunately my initial attempt at supporting >340mhz modelines over
> > HDMI was incomplete -- worked in my own testing, but not for everyone.
> > (You need 597mhz to get 4k@60.)
>
> $ cvt 3840 2160
> # 3840x2160 59.98 Hz (CVT 8.29M9) hsync: 134.18 kHz; pclk: 712.75 MHz
> Modeline "3840x2160_60.00"  712.75  3840 4160 4576 5312  2160 2163
> 2168 2237 -hsync +vsync

That just plain won't work. HDMI 2.0 maxes out at 600mhz, whereas
you're giving it a 712mhz modeline. You're trying to be too clever.
This stuff should just work out of the box.

What happens if you use a 5.8 or later kernel and don't do any of
this? You should just be able to do like xrandr --output HDMI-1-2
--auto. But having a 4k display on a secondary GPU is not a great idea
-- I'd flip it around, make the GTX 1050 the primary.

Can you provide the output of "xrandr --verbose" before you've messed
around with anything like modelines/etc?

Thanks,

  -ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Request for help in adding a HDMI output

[Ilia Mirkin]

On Thu, Jan 21, 2021 at 9:59 PM o1bigtenor  wrote:
>
> Greetings
>
> Running a debian testing system
> $ uname -r
> 5.4.0-4-amd64
> with 2 graphics cards.
> The one I'm working on is a: GP 107 Nvidia  GTX 1050 Ti
>
> Asus ROG GeForce GX 1050 Ti Strix-GTX1050 Ti with 2 - DVI plus 1 DP1.4
> and I HDMI2.0 ports (four in total).
>
> I have been running 2 1920x1080 monitors on this card (and its
> previous nvidia 570) for quite some time. Been running nouveau for the
> last about 4 years as my last nvidia 570 (started with 3) is EOL by
> nvidia.
> Have gotten quite comfortable using xrandr setting up the second card
> (the nvidia 570) and its 2 monitors. Nouveau software is:
> xserver-xorg-video-nouveau -> 1:1.0.16-1 ;
> xserver-xorg -> 1:7.7+21 ; and libdrm-nouveau2:amd64 -> 2.4.102-1 .
>
> I want to add a 4k TV onto the HDMI port on card #1.
> Can't seem to get the card and the TV talking.

Unfortunately my initial attempt at supporting >340mhz modelines over
HDMI was incomplete -- worked in my own testing, but not for everyone.
(You need 597mhz to get 4k@60.)

Ben was able to figure out what was wrong and fix it:

commit a1ef8bad506e4ffa0c57ac5f8cb99ab5cbc3b1fc
Author: Ben Skeggs 
Date:   Fri May 29 15:18:47 2020 +1000

drm/nouveau/disp/gm200-: fix NV_PDISP_SOR_HDMI2_CTRL(n) selection

I believe this change is in kernel v5.8. If you don't want to upgrade,
just ensure you pick a 30hz mode-line for that display, which should
enable 4k to work.

Also it looks like you have both GPUs plugged in, and slaving one off
the other. If possible, I'd recommend to keep everything on one GPU.
The DP port can (most likely) be used for HDMI or DVI with a passive
converter (not sure if it can be used with HDMI 2.0 though). Having
remote displays is not a great experience (it does work though, and
better than nothing in cases that require it).

Cheers,

  -ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [mesa-20.3.2] NULL pointer dereference in vl_compositor_yuv_deint_full

[Ilia Mirkin]

On Sun, Jan 3, 2021 at 1:25 PM Alexander Kapshuk
 wrote:
>
> On Sun, Jan 3, 2021 at 7:20 PM Ilia Mirkin  wrote:
> >
> > On Sun, Jan 3, 2021 at 3:18 AM Alexander Kapshuk
> >  wrote:
> > >
> > > NVIDIA chip affected:
> > > 01:00.0 VGA compatible controller: NVIDIA Corporation GT216 [GeForce
> > > 210] (rev a1)
> > >
> > > The null pointer dereference occurs here:
> > > Thread 27 "vlc" received signal SIGSEGV, Segmentation fault.
> > > [Switching to Thread 0x7fff8f7c1640 (LWP 79292)]
> > > 0x7fff8d59d1da in vl_compositor_yuv_deint_full (s=0x7fff980e8518,
> > > c=0x7fff980e83d8, src=0x7fff98670030, dst=0x0,
> > > src_rect=0x7fff8f7c0470,
> > > dst_rect=0x7fff8f7c0460, deinterlace=VL_COMPOSITOR_WEAVE) at
> > > ../mesa-20.3.2/src/gallium/auxiliary/vl/vl_compositor.c:689
> > > 689 dst_surfaces = dst->get_surfaces(dst); //dst==NULL
> > >
> > > => 0x7fff8d5981da <+42>:call   *0x38(%rcx) //rcx is dst
> > > (gdb) i r rcx
> > > rcx0x0 0
> > >
> > > (gdb) bt
> > > #0  0x7fff8d59d1da in vl_compositor_yuv_deint_full
> > > (s=0x7fff980e8518, c=0x7fff980e83d8, src=0x7fff98670030, dst=0x0,
> > > src_rect=0x7fff8f7c0470, dst_rect=0x7fff8f7c0460,
> > > deinterlace=VL_COMPOSITOR_WEAVE) at
> > > ../mesa-20.3.2/src/gallium/auxiliary/vl/vl_compositor.c:689
> > > #1  0x7fff8d58a29b in vlVaDeriveImage (ctx=0x7fff980c1590,
> > > surface=, image=0x7fff8f7c05e0)
> > > at ../mesa-20.3.2/src/gallium/frontends/va/image.c:321
> > > #2  0x7fff91485799 in vaDeriveImage () at /usr/lib/libva.so.2
> > > #3  0x7fff8e2256d2 in  () at
> > > /usr/lib/vlc/plugins/video_output/libglconv_vaapi_x11_plugin.so
> > > #4  0x7fff8e224189 in  () at
> > > /usr/lib/vlc/plugins/video_output/libglconv_vaapi_x11_plugin.so
> > > #5  0x7fff8f6b1896 in  () at
> > > /usr/lib/vlc/plugins/video_output/libgl_plugin.so
> > > #6  0x7fff8f6b86db in  () at
> > > /usr/lib/vlc/plugins/video_output/libgl_plugin.so
> > > #7  0x77d07cee in  () at /usr/lib/libvlccore.so.9
> > > #8  0x77cfa019 in  () at /usr/lib/libvlccore.so.9
> > > #9  0x77cfbf9e in  () at /usr/lib/libvlccore.so.9
> > > #10 0x77f623e9 in start_thread () at /usr/lib/libpthread.so.0
> > > #11 0x77e8a293 in clone () at /usr/lib/libc.so.6
> > >
> > > mesa-20.3.2/src/gallium/frontends/va/image.c:312,313
> > > VAStatus
> > > vlVaDeriveImage(VADriverContextP ctx, VASurfaceID surface, VAImage *image)
> > > {
> > > ...
> > >  new_template.interlaced = false; //create_video_buffer
> > > returns NULL if new_template.interlaced is set to false See below.
> > >  new_buffer = drv->pipe->create_video_buffer(drv->pipe, 
> > > _template);
> > > ...
> > >  vl_compositor_yuv_deint_full(>cstate, >compositor,
> > >surf->buffer, new_buffer,
> > >_rect, _rect,
> > >VL_COMPOSITOR_WEAVE);
> > > ...
> > > }
> > >
> > > [Note]
> > > mesa-20.3.2/src/gallium/drivers/nouveau/nv50/nv84_video.c:618,621
> > > struct pipe_video_buffer *
> > > nv84_video_buffer_create(struct pipe_context *pipe,
> > >  const struct pipe_video_buffer *template)
> > > {
> > > ...
> > >if (!template->interlaced) { //setting this to true in
> > > vlVaDeriveImage returns valid buffer
> > >   debug_printf("Require interlaced video buffers\n");
> > >   return NULL;
> > >}
> > > ...
> > > }
> > >
> > > Please advise on the further course of action.
> >
> > Figure out what change in mesa broke it, send a revert (or fix, if
> > you're able). There has been a bunch of activity in st/vl lately, and
> > the developers never take NVIDIA into account, only AMD (well, they're
> > AMD developers, so not entirely surprising).
> >
> > Cheers,
> >
> >   -ilia
>
> The following commit,
> https://gitlab.freedesktop.org/mesa/mesa/-/commit/338745c6f4b7133d7b36f78562d46bc4e8d368f5,
> introduced derive_interlaced_allowlist, which currently comprises the
> 'vlc' media player. Which, as far as I could tell, was to make an
> exception for vlc, so a video buffer would be created when
> surf->b

Re: [Nouveau] [mesa-20.3.2] NULL pointer dereference in vl_compositor_yuv_deint_full

[Ilia Mirkin]

On Sun, Jan 3, 2021 at 3:18 AM Alexander Kapshuk
 wrote:
>
> NVIDIA chip affected:
> 01:00.0 VGA compatible controller: NVIDIA Corporation GT216 [GeForce
> 210] (rev a1)
>
> The null pointer dereference occurs here:
> Thread 27 "vlc" received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7fff8f7c1640 (LWP 79292)]
> 0x7fff8d59d1da in vl_compositor_yuv_deint_full (s=0x7fff980e8518,
> c=0x7fff980e83d8, src=0x7fff98670030, dst=0x0,
> src_rect=0x7fff8f7c0470,
> dst_rect=0x7fff8f7c0460, deinterlace=VL_COMPOSITOR_WEAVE) at
> ../mesa-20.3.2/src/gallium/auxiliary/vl/vl_compositor.c:689
> 689 dst_surfaces = dst->get_surfaces(dst); //dst==NULL
>
> => 0x7fff8d5981da <+42>:call   *0x38(%rcx) //rcx is dst
> (gdb) i r rcx
> rcx0x0 0
>
> (gdb) bt
> #0  0x7fff8d59d1da in vl_compositor_yuv_deint_full
> (s=0x7fff980e8518, c=0x7fff980e83d8, src=0x7fff98670030, dst=0x0,
> src_rect=0x7fff8f7c0470, dst_rect=0x7fff8f7c0460,
> deinterlace=VL_COMPOSITOR_WEAVE) at
> ../mesa-20.3.2/src/gallium/auxiliary/vl/vl_compositor.c:689
> #1  0x7fff8d58a29b in vlVaDeriveImage (ctx=0x7fff980c1590,
> surface=, image=0x7fff8f7c05e0)
> at ../mesa-20.3.2/src/gallium/frontends/va/image.c:321
> #2  0x7fff91485799 in vaDeriveImage () at /usr/lib/libva.so.2
> #3  0x7fff8e2256d2 in  () at
> /usr/lib/vlc/plugins/video_output/libglconv_vaapi_x11_plugin.so
> #4  0x7fff8e224189 in  () at
> /usr/lib/vlc/plugins/video_output/libglconv_vaapi_x11_plugin.so
> #5  0x7fff8f6b1896 in  () at
> /usr/lib/vlc/plugins/video_output/libgl_plugin.so
> #6  0x7fff8f6b86db in  () at
> /usr/lib/vlc/plugins/video_output/libgl_plugin.so
> #7  0x77d07cee in  () at /usr/lib/libvlccore.so.9
> #8  0x77cfa019 in  () at /usr/lib/libvlccore.so.9
> #9  0x77cfbf9e in  () at /usr/lib/libvlccore.so.9
> #10 0x77f623e9 in start_thread () at /usr/lib/libpthread.so.0
> #11 0x77e8a293 in clone () at /usr/lib/libc.so.6
>
> mesa-20.3.2/src/gallium/frontends/va/image.c:312,313
> VAStatus
> vlVaDeriveImage(VADriverContextP ctx, VASurfaceID surface, VAImage *image)
> {
> ...
>  new_template.interlaced = false; //create_video_buffer
> returns NULL if new_template.interlaced is set to false See below.
>  new_buffer = drv->pipe->create_video_buffer(drv->pipe, 
> _template);
> ...
>  vl_compositor_yuv_deint_full(>cstate, >compositor,
>surf->buffer, new_buffer,
>_rect, _rect,
>VL_COMPOSITOR_WEAVE);
> ...
> }
>
> [Note]
> mesa-20.3.2/src/gallium/drivers/nouveau/nv50/nv84_video.c:618,621
> struct pipe_video_buffer *
> nv84_video_buffer_create(struct pipe_context *pipe,
>  const struct pipe_video_buffer *template)
> {
> ...
>if (!template->interlaced) { //setting this to true in
> vlVaDeriveImage returns valid buffer
>   debug_printf("Require interlaced video buffers\n");
>   return NULL;
>}
> ...
> }
>
> Please advise on the further course of action.

Figure out what change in mesa broke it, send a revert (or fix, if
you're able). There has been a bunch of activity in st/vl lately, and
the developers never take NVIDIA into account, only AMD (well, they're
AMD developers, so not entirely surprising).

Cheers,

  -ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] 5.9.11 still hanging 2mn at each boot and looping on nvidia-gpu 0000:01:00.3: PME# enabled (Quadro RTX 4000 Mobile)

[Ilia Mirkin]

On Tue, Dec 29, 2020 at 10:52 AM Marc MERLIN  wrote:
>
> On Sat, Dec 26, 2020 at 03:12:09AM -0800, Ilia Mirkin wrote:
> > > after boot, when it gets the right trigger (not sure which ones), it
> > > loops on this evern 2 seconds, mostly forever.
> >
> > The gpu suspends with runtime pm. And then gets woken up for some
> > reason (could be something quite silly, like lspci, or could be
> > something explicitly checking connectors, etc). Repeat.
>
> Ah, fair point.  Could it be powertop even?
> How would I go towards tracing that?
> Sounds like this would be a problem with all chips if userspace is able
> to wake them up every second or two with a probe. Now I wonder what
> broken userspace I have that could be doing this.

Well, it's a theory. Some userspace helpfully prevents the GPU from
suspending entirely, unfortunately I don't remember its name though by
messing with the attached audio device. It's very common and meant to
help... oh well.

>
> > Display offload usually requires acceleration -- the copies are done
> > using the DMA engine. Please make sure that you have firmware
> > available (and a new enough mesa). The errors suggest that you don't
> > have firmware available at the time that nouveau loads. Depending on
> > your setup, that might mean the firmware has to be built into the
> > kernel, or available in initramfs. (Or just regular filesystem if you
> > don't use a complicated boot sequence. But many people go with distro
> > defaults, which do have this complexity.)
>
> Hi Ilia, thanks for your answer.
>
> Do you think that could be a reason why the boot would hang for 2 full 
> minutes at every
> boot ever since I upgraded to 5.5?

I'd have to check, but I'm guessing TU104 acceleration became a thing
in 5.5. I would also not be very surprised if the code didn't handle
failure extremely gracefully - there definitely have been problems
with that in the past.

>
> Also, without wanting to sound like a full newbie, where is that
> firmware you're talking about? In my kernel source?
>
> Here's what I do have:
> sauron:/usr/local/bin# dpkggrep nouveau
> libdrm-nouveau2:amd64   install
> xserver-xorg-video-nouveau  install
>
> no nouveau-firmware package in debian:
> sauron:/usr/local/bin# apt-cache search nouveau
> bumblebee - NVIDIA Optimus support for Linux
> libdrm-nouveau2 - Userspace interface to nouveau-specific kernel DRM services 
> -- runtime
> xfonts-jmk - Jim Knoble's character-cell fonts for X
> xserver-xorg-video-nouveau - X.Org X server -- Nouveau display driver
>
> No firmware file on my disk:
> sauron:/usr/local/bin# find /lib/modules/5.9.11-amd64-preempt-sysrq-20190817/ 
> /lib/firmware/ |grep nouveau
> /lib/modules/5.9.11-amd64-preempt-sysrq-20190817/kernel/drivers/gpu/drm/nouveau
> /lib/modules/5.9.11-amd64-preempt-sysrq-20190817/kernel/drivers/gpu/drm/nouveau/nouveau.ko
> sauron:/usr/local/bin#
>
> The kernel module is in my initrd:
> sauron:/usr/local/bin# dd 
> if=/boot/initrd.img-5.9.11-amd64-preempt-sysrq-20190817 bs=2966528  skip=1 | 
> gunzip | cpio -tdv | grep nouveau
> drwxr-xr-x   1 root root0 Nov 30 15:40 
> usr/lib/modules/5.9.11-amd64-preempt-sysrq-20190817/kernel/drivers/gpu/drm/nouveau
> -rw-r--r--   1 root root  3691385 Nov 30 15:35 
> usr/lib/modules/5.9.11-amd64-preempt-sysrq-20190817/kernel/drivers/gpu/drm/nouveau/nouveau.ko
> 17+1 records in
> 17+1 records out
> 52566778 bytes (53 MB, 50 MiB) copied, 1.69708 s, 31.0 MB/s

I think that gets you out of "full newbie" land...

>
> What am I supposed to do/check next?
>
> Note that ultimately I only need nouveau not to hang my boot 2mn and do
> PM so that the nvidia chip goes to sleep since I don't use it.

I'm not extremely familiar with debian packaging, but the firmware is
provided by NVIDIA and shipped as part of linux-firmware:

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/nvidia

This needs to be available at /lib/firmware/nvidia when nouveau loads.
Based on your email above, it's most likely that it would load from
the initrd - so make sure it's in there.

Of course now that I read your email a bit more carefully, it seems
your issue is with the "saving config space" messages. I'm not sure
I've seen those before. Perhaps you have some sort of debug enabled.
I'd find where in the kernel they are being produced, and what the
conditions for it are. But the failure to load firmware isn't great --
not 100% sure if it impacts runpm or not.

I just double-checked, TU10x accel came in via
afa3b96b058d87c2c44d1c83dadb2ba6998d03ce, which was first in v5.6.
Initial TU10x support came in v5.0. So that doesn't line up with your
timeline.

Anyways, I'd definitely sort the firmware situation out, but it may
not be the cause of your problem.

Cheers,

  -ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] 5.9.11 still hanging 2mn at each boot and looping on nvidia-gpu 0000:01:00.3: PME# enabled (Quadro RTX 4000 Mobile)

[Ilia Mirkin]

On Sun, Dec 27, 2020 at 12:03 PM Marc MERLIN  wrote:
>
> This started with 5.5 and hasn't gotten better since then, despite some 
> reports
> I tried to send.
>
> As per my previous message:
> I have a Thinkpad P70 with hybrid graphics.
> 01:00.0 VGA compatible controller: NVIDIA Corporation GM107GLM [Quadro M600M] 
> (rev a2)
> that one works fine, I can use i915 for the main screen, and nouveau to
> display on the external ports (external ports are only wired to nvidia
> chip, so it's impossible to use them without turning the nvidia chip
> on).
>
> I now got a newer P73 also with the same hybrid graphics (setup as such
> in the bios). It runs fine with i915, and I don't need to use external
> display with nouveau for now (it almost works, but I only see the mouse
> cursor on the external screen, no window or anything else can get
> displayed, very weird).
> 01:00.0 VGA compatible controller: NVIDIA Corporation TU104GLM [Quadro RTX 
> 4000 Mobile / Max-Q] (rev a1)

Display offload usually requires acceleration -- the copies are done
using the DMA engine. Please make sure that you have firmware
available (and a new enough mesa). The errors suggest that you don't
have firmware available at the time that nouveau loads. Depending on
your setup, that might mean the firmware has to be built into the
kernel, or available in initramfs. (Or just regular filesystem if you
don't use a complicated boot sequence. But many people go with distro
defaults, which do have this complexity.)

>
>
> after boot, when it gets the right trigger (not sure which ones), it
> loops on this evern 2 seconds, mostly forever.

The gpu suspends with runtime pm. And then gets woken up for some
reason (could be something quite silly, like lspci, or could be
something explicitly checking connectors, etc). Repeat.

Cheers,

  -ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH v2] ALSA: hda: Continue to probe when codec probe fails

[Ilia Mirkin]

On Mon, Dec 21, 2020 at 11:33 AM Kai-Heng Feng
 wrote:
>
> [+Cc nouveau]
>
> On Fri, Dec 18, 2020 at 4:06 PM Takashi Iwai  wrote:
> [snip]
> > > Quite possibly the system doesn't power up HDA controller when there's
> > > no external monitor.
> > > So when it's connected to external monitor, it's still needed for HDMI 
> > > audio.
> > > Let me ask the user to confirm this.
> >
> > Yeah, it's the basic question whether the HD-audio is supposed to work
> > on this machine at all.  If yes, the current approach we take makes
> > less sense - instead we should rather make the HD-audio controller
> > working.
>
> Yea, confirmed that the Nvidia HDA works when HDMI is connected prior boot.
>
> > > > - The second problem is that pci_enable_device() ignores the error
> > > >   returned from pci_set_power_state() if it's -EIO.  And the
> > > >   inaccessible access error returns -EIO, although it's rather a fatal
> > > >   problem.  So the driver believes as the PCI device gets enabled
> > > >   properly.
> > >
> > > This was introduced in 2005, by Alan's 11f3859b1e85 ("[PATCH] PCI: Fix
> > > regression in pci_enable_device_bars") to fix UHCI controller.
> > >
> > > >
> > > > - The third problem is that HD-audio driver blindly believes the
> > > >   codec_mask read from the register even if it's a read failure as I
> > > >   already showed.
> > >
> > > This approach has least regression risk.
> >
> > Yes, but it assumes that HD-audio is really non-existent.
>
> I really don't know any good approach to address this.
> On Windows, HDA PCI is "hidden" until HDMI cable is plugged, then the
> driver will flag the magic bit to make HDA audio appear on the PCI
> bus.
> IIRC the current approach is to make nouveau and device link work.

I don't have the full context of this discussion, but the kernel
force-enables the HDA subfunction nowadays, irrespective of nouveau or
nvidia or whatever:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/quirks.c?h=v5.10#n5267

Cheers,

  -ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Nouveau video --- [ cut here ] ----- crash dump 5.10.0-rc6

[Ilia Mirkin]

Unfortunately this isn't a crash, but rather a warning that things are
timing out. By the time you get this, the display is most likely hung.

Was there anything before this, e.g. an error state dump perhaps?

What GPU are you using, what displays, and how are they connected?
What kind of userspace is running here? X or a Wayland compositor (or
something else entirely)?

On Thu, Dec 3, 2020 at 12:13 AM Dave Airlie  wrote:
>
> cc'ing Ben + nouveau
>
> On Thu, 3 Dec 2020 at 14:59, bob  wrote:
> >
> > Hello.  I have a crash dump for:
> >
> > $ uname -a
> > Linux freedom 5.10.0-rc6 #1 SMP Sun Nov 29 17:26:13 MST 2020 x86_64
> > x86_64 x86_64 GNU/Linux
> >
> > Occasionally when this dumps it likes to lock up the computer, but I
> > caught it this time.
> >
> > Also video likes to flicker a lot.   Nouveau has been iffy since kernel
> > 5.8.0.
> >
> > This isn't the only dump, it dumped probably 50 times.  If you are
> > really desperate for all of it,
> >
> > reply to me directly as I'm not on the mailing list.  Here is one of them.
> >
> > [39019.426580] [ cut here ]
> > [39019.426589] WARNING: CPU: 6 PID: 14136 at
> > drivers/gpu/drm/nouveau/dispnv50/disp.c:211 nv50_dmac_wait+0x1e1/0x230
> > [39019.426590] Modules linked in: mt2131 s5h1409 fuse tda8290 tuner
> > cx25840 rt2800usb rt2x00usb rt2800lib snd_hda_codec_analog
> > snd_hda_codec_generic ledtrig_audio rt2x00lib binfmt_misc
> > intel_powerclamp coretemp cx23885 mac80211 tda18271 altera_stapl
> > videobuf2_dvb m88ds3103 tveeprom cx2341x dvb_core rc_core i2c_mux
> > snd_hda_codec_hdmi videobuf2_dma_sg videobuf2_memops videobuf2_v4l2
> > snd_hda_intel videobuf2_common snd_intel_dspcfg kvm_intel snd_hda_codec
> > videodev snd_hda_core kvm mc snd_hwdep snd_pcm_oss snd_mixer_oss
> > irqbypass snd_pcm cfg80211 snd_seq_dummy snd_seq_midi snd_seq_oss
> > snd_seq_midi_event snd_rawmidi snd_seq intel_cstate snd_seq_device
> > serio_raw snd_timer input_leds nfsd libarc4 snd asus_atk0110 i7core_edac
> > soundcore i5500_temp auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc
> > parport_pc ppdev lp parport ip_tables x_tables btrfs blake2b_generic
> > libcrc32c xor zstd_compress raid6_pq dm_mirror dm_region_hash dm_log
> > pata_acpi pata_marvell hid_generic usbhid hid psmouse firewire_ohci
> > [39019.426650]  firewire_core crc_itu_t i2c_i801 ahci sky2 libahci
> > i2c_smbus lpc_ich
> > [39019.426658] CPU: 6 PID: 14136 Comm: kworker/u16:0 Tainted: GW
> > I   5.10.0-rc6 #1
> > [39019.426659] Hardware name: System manufacturer System Product
> > Name/P6T DELUXE, BIOS 220909/21/2010
> > [39019.426662] Workqueue: events_unbound nv50_disp_atomic_commit_work
> > [39019.426665] RIP: 0010:nv50_dmac_wait+0x1e1/0x230
> > [39019.426667] Code: 8d 48 04 48 89 4a 68 c7 00 00 00 00 20 49 8b 46 38
> > 41 c7 86 20 01 00 00 00 00 00 00 49 89 46 68 e8 e4 fc ff ff e9 76 fe ff
> > ff <0f> 0b b8 92 ff ff ff e9 ed fe ff ff 49 8b be 80 00 00 00 e8 c7 fc
> > [39019.426668] RSP: 0018:b79d028ebd48 EFLAGS: 00010282
> > [39019.426670] RAX: ff92 RBX: 000d RCX:
> > 
> > [39019.426671] RDX: ff92 RSI: b79d028ebc88 RDI:
> > b79d028ebd28
> > [39019.426671] RBP: b79d028ebd48 R08:  R09:
> > b79d028ebc58
> > [39019.426672] R10: 0030 R11: 11c4 R12:
> > fffb
> > [39019.426673] R13: a05fc1ebd368 R14: a05fc1ebd3a8 R15:
> > a05fc2425000
> > [39019.426675] FS:  () GS:a061f3d8()
> > knlGS:
> > [39019.426676] CS:  0010 DS:  ES:  CR0: 80050033
> > [39019.426677] CR2: 7fb2d58e CR3: 00026280a000 CR4:
> > 06e0
> > [39019.426678] Call Trace:
> > [39019.426685]  base827c_image_set+0x2f/0x1d0
> > [39019.426687]  nv50_wndw_flush_set+0x89/0x1c0
> > [39019.426688]  nv50_disp_atomic_commit_tail+0x4e7/0x7e0
> > [39019.426693]  process_one_work+0x1d4/0x370
> > [39019.426695]  worker_thread+0x4a/0x3b0
> > [39019.426697]  ? process_one_work+0x370/0x370
> > [39019.426699]  kthread+0xfe/0x140
> > [39019.426701]  ? kthread_park+0x90/0x90
> > [39019.426704]  ret_from_fork+0x22/0x30
> > [39019.426706] ---[ end trace d512d675211c738c ]---
> > [39021.426751] [ cut here ]
> >
> >
> > Thanks in advance,
> >
> > Bob
> >
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Problem with kernel 5.10-rc5

[Ilia Mirkin]

Hi Mark,

Presumably this is the same thing as the other thread you started,
which seemed to conclude with a working patch, and this email was just
stuck in the moderation queue?

Cheers,

  -ilia

On Sun, Nov 29, 2020 at 6:02 PM Mark Hounschell  wrote:
>
> I am not subscribed to this mailing list so please CC me directly for
> any response.
>
> I'm running an older "NVIDIA Corporation G70 [GeForce 7800 GT] (rev a1)"
> card in a newer BIOSTAR B550GTA MB. Kernel 5.10-rc5 does not work. I get
> no virtual consoles or X screen.
>
> I have not tried any other RC versions. Only rc5. Kernel 5.9.10 works
> fine. I am running a SuSE Leap-15.2 system.
>
> I have another machine with an NVIDIA Corporation GT218 [GeForce 210]
> (rev a2) that works just fine with 5.10-rc5.
>
>
> On the broken machine the screen goes blank, the leds on the front turn
> orange as if the PC was turned off.
>
> My dmesg seems to show the cause:
>
> [5.825702] fb0: switching to nouveaufb from VESA VGA
> [6.242991] nouveau :14:00.0: vgaarb: deactivate vga console
> [6.243066] nouveau :14:00.0: NVIDIA G70 (047200a1)
> [6.443671] nouveau :14:00.0: bios: version 05.70.02.13.7b
> [6.443948] nouveau :14:00.0: fb: 256 MiB GDDR3
> [6.498039] nouveau :14:00.0: DRM: VRAM: 250 MiB
> [6.498041] nouveau :14:00.0: DRM: GART: 512 MiB
> [6.498044] nouveau :14:00.0: DRM: TMDS table version 1.1
> [6.498046] nouveau :14:00.0: DRM: DCB version 3.0
> [6.498049] nouveau :14:00.0: DRM: DCB outp 00: 01000300 0028
> [6.498051] nouveau :14:00.0: DRM: DCB outp 01: 03000302 
> [6.498053] nouveau :14:00.0: DRM: DCB outp 02: 04011310 0028
> [6.498055] nouveau :14:00.0: DRM: DCB outp 03: 04011312 
> [6.498057] nouveau :14:00.0: DRM: DCB outp 04: 020223f1 0040c080
> [6.498060] nouveau :14:00.0: DRM: DCB conn 00: 1030
> [6.498062] nouveau :14:00.0: DRM: DCB conn 01: 2130
> [6.498064] nouveau :14:00.0: DRM: DCB conn 02: 0210
> [6.498065] nouveau :14:00.0: DRM: DCB conn 03: 0211
> [6.498067] nouveau :14:00.0: DRM: DCB conn 04: 0213
> [6.502949] nouveau :14:00.0: DRM: Setting dpms mode 3 on TV
> encoder (output 4)
> [6.585845] nouveau :14:00.0: DRM: failed to map fb: -28
> [6.585949] [drm] Initialized nouveau 1.3.1 20120801 for :14:00.0
> on minor 0
>
> If I can do anything else please let me know.
>
> Regards
> Mark
>
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Could Fedora-5.9.9/X-server problem be a Nouveau-problem?

[Ilia Mirkin]

When in doubt, blame nouveau.

I believe there has been some recent work around adjusting the logic
which checks that modes have enough bandwidth. Adding Lyude, who
worked on these changes. Not sure when they landed.

Klaus -- please supply a full Xorg log.

Cheers,

  -ilia

On Sun, Nov 29, 2020 at 4:28 PM Klaus Ebbe Grue  wrote:
>
> Hi nouveau@lists.freedesktop.org
>
> My X-server gives a blank screen on Fedora kernel 5.9.9.
>
> I am in doubt whether or not I should blame Nouveau for that.
>
> I know the nvidea drivers have problems with Fedora kernel 5.9.9.
>
> I can file a bug against Nouveau and provide logs if you think there is a 
> remote chance that Nouveau could be the cause.
>
> Here are some details:
>
> Fedora 5.8.18 / X-server works fine.
>
> I can boot into Fedora 5.9.9 runlevel 3 (no X-server).
>
> If I boot into Fedora 5.9.9 runlevel 5 (with X-server), the screen powers off 
> instead of giving a login prompt, but apart from that, Fedora 5.9.9 works 
> fine and produces log files.
>
> If I then power off and boot into Fedora 5.8.18 and read Xorg.0.log.old I can 
> see that the X-server under Fedora 5.9.9 did not get the screen resolutions 
> right.
>
> Here is what monitor-edid says under both Fedora 5.9.9 and 5.8.18:
>
> > monitor-edid
> Name: PHL BDM4350
> EISA ID: PHL08fa
> EDID version: 1.4
> EDID extension blocks: 1
> Screen size: 95.3 cm x 54.3 cm (43.18 inches, aspect ratio 16/9 = 1.76)
> Gamma: 2.2
> Digital signal
> Max video bandwidth: 600 MHz
> HorizSync 30-160
> VertRefresh 23-80
> # Monitor preferred modeline (60.0 Hz vsync, 133.3 kHz hsync, ratio 
> 16/9, 102 dpi) (bad ratio)
> ModeLine "3840x2160" 533.25 3840 3888 3920 4000 2160 2163 2168  
> -hsync +vsync
> ...
>
> But under Fedora 5.9.9, the X-server is unaware of the 3840x2160 resolution 
> according to Xorg.0.log.old. It also gets the screen physical size wrong.
>
> My first cry of help is here:
> https://ask.fedoraproject.org/t/no-login-screen-after-upgrade/10618
> That is where I leaned that the nvidea drivers have problems with Fedora 5.9.9
>
> Cheers,
> Klaus
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] GT710 and Nouveau on ARM/ARM64

[Ilia Mirkin]

On Tue, Nov 3, 2020 at 1:08 PM Dave Stevenson
 wrote:
>
> Hi Ilia
> Thanks again for the reply.
>
> On Wed, 28 Oct 2020 at 14:59, Ilia Mirkin  wrote:
> >
> > On Wed, Oct 28, 2020 at 10:20 AM Dave Stevenson
> >  wrote:
> > >
> > > Hi Ilia
> > >
> > > Thanks for taking the time to reply.
> > >
> > > On Wed, 28 Oct 2020 at 14:10, Ilia Mirkin  wrote:
> > > >
> > > > The most common issue on arm is that the pci memory window is too 
> > > > narrow to allocate all the BARs. Can you see if there are messages in 
> > > > the kernel to that effect?
> > >
> > > All the BAR allocations seem to succeed except for the IO one.
> > > AIUI I/O is deprecated, but is it still used on these cards?
> >
> > I must admit I was ignorant of the fact that the IO ports were treated
> > as a BAR, but it makes a lot of sense.
> >
> > One thing does stand out as odd:
> >
> > >
> > > [1.060851] brcm-pcie fd50.pcie: host bridge /scb/pcie@7d50 
> > > ranges:
> > > [1.060892] brcm-pcie fd50.pcie:   No bus range found for
> > > /scb/pcie@7d50, using [bus 00-ff]
> > > [1.060975] brcm-pcie fd50.pcie:  MEM
> > > 0x06..0x063fff -> 0x00c000
> > > [1.061061] brcm-pcie fd50.pcie:   IB MEM
> > > 0x00..0x00 -> 0x01
> > > [1.109943] brcm-pcie fd50.pcie: link up, 5.0 GT/s PCIe x1 (SSC)
> > > [1.110129] brcm-pcie fd50.pcie: PCI host bridge to bus :00
> > > [1.110159] pci_bus :00: root bus resource [bus 00-ff]
> > > [1.110187] pci_bus :00: root bus resource [mem
> > > 0x6-0x63fff] (bus address [0xc000-0x])
> > > [1.110286] pci :00:00.0: [14e4:2711] type 01 class 0x060400
> > > [1.110505] pci :00:00.0: PME# supported from D0 D3hot
> > > [1.114095] pci :00:00.0: bridge configuration invalid ([bus
> > > 00-00]), reconfiguring
> > > [1.114343] pci :01:00.0: [10de:128b] type 00 class 0x03
> > > [1.114404] pci :01:00.0: reg 0x10: [mem 0x-0x00ff]
> > > [1.114456] pci :01:00.0: reg 0x14: [mem 0x-0x07ff
> > > 64bit pref]
> > > [1.114510] pci :01:00.0: reg 0x1c: [mem 0x-0x01ff
> > > 64bit pref]
> > > [1.114551] pci :01:00.0: reg 0x24: [io  0x-0x007f]
> > > [1.114590] pci :01:00.0: reg 0x30: [mem 0x-0x0007 
> > > pref]
> > > [1.114853] pci :01:00.0: 4.000 Gb/s available PCIe bandwidth,
> > > limited by 5.0 GT/s PCIe x1 link at :00:00.0 (capable of 63.008
> > > Gb/s with 8.0 GT/s PCIe x8 link)
> > > [1.115022] pci :01:00.0: vgaarb: VGA device added:
> > > decodes=io+mem,owns=none,locks=none
> > > [1.115125] pci :01:00.1: [10de:0e0f] type 00 class 0x040300
> > > [1.115184] pci :01:00.1: reg 0x10: [mem 0x-0x3fff]
> > > [1.119065] pci_bus :01: busn_res: [bus 01-ff] end is updated to 01
> > > [1.119120] pci :00:00.0: BAR 9: assigned [mem
> > > 0x6-0x60bff 64bit pref]
> > > [1.119151] pci :00:00.0: BAR 8: assigned [mem 
> > > 0x60c00-0x60d7f]
> >
> > This is your brcm-pcie device.
> >
> > > [1.119183] pci :01:00.0: BAR 1: assigned [mem
> > > 0x6-0x607ff 64bit pref]
> > > [1.119235] pci :01:00.0: BAR 3: assigned [mem
> > > 0x60800-0x609ff 64bit pref]
> > > [1.119285] pci :01:00.0: BAR 0: assigned [mem 
> > > 0x60c00-0x60cff]
> >
> > And this is the NVIDIA device. Note that these memory windows are
> > identical (or at least overlapping). I must admit almost complete
> > ignorance of PCIe and whether this is OK, but it seems sketchy at
> > first glance. A quick eyeballing of my x86 system suggests that all
> > PCIe devices get non-overlapping windows. OTOH there are messages
> > further up about some sort of remapping going on, so perhaps it's OK?
> > But two things on the same bus still shouldn't have the same addresses
> > allocated, based on my (limited) understanding.
>
> I've raised this with colleagues and it seems that this is normal.
> The PCI bridge reports the window through which devices can be mapped,
> and all devices have to fit within that. Pass as to whether that is a
> quirk of ARM or this particular bridge.
>
> I do note that on my x86 systems device 

Re: [Nouveau] GT710 and Nouveau on ARM/ARM64

[Ilia Mirkin]

On Wed, Oct 28, 2020 at 10:20 AM Dave Stevenson
 wrote:
>
> Hi Ilia
>
> Thanks for taking the time to reply.
>
> On Wed, 28 Oct 2020 at 14:10, Ilia Mirkin  wrote:
> >
> > The most common issue on arm is that the pci memory window is too narrow to 
> > allocate all the BARs. Can you see if there are messages in the kernel to 
> > that effect?
>
> All the BAR allocations seem to succeed except for the IO one.
> AIUI I/O is deprecated, but is it still used on these cards?

I must admit I was ignorant of the fact that the IO ports were treated
as a BAR, but it makes a lot of sense.

One thing does stand out as odd:

>
> [1.060851] brcm-pcie fd50.pcie: host bridge /scb/pcie@7d50 ranges:
> [1.060892] brcm-pcie fd50.pcie:   No bus range found for
> /scb/pcie@7d50, using [bus 00-ff]
> [1.060975] brcm-pcie fd50.pcie:  MEM
> 0x06..0x063fff -> 0x00c000
> [1.061061] brcm-pcie fd50.pcie:   IB MEM
> 0x00..0x00 -> 0x01
> [1.109943] brcm-pcie fd50.pcie: link up, 5.0 GT/s PCIe x1 (SSC)
> [1.110129] brcm-pcie fd50.pcie: PCI host bridge to bus :00
> [1.110159] pci_bus :00: root bus resource [bus 00-ff]
> [1.110187] pci_bus :00: root bus resource [mem
> 0x6-0x63fff] (bus address [0xc000-0x])
> [1.110286] pci :00:00.0: [14e4:2711] type 01 class 0x060400
> [1.110505] pci :00:00.0: PME# supported from D0 D3hot
> [1.114095] pci :00:00.0: bridge configuration invalid ([bus
> 00-00]), reconfiguring
> [1.114343] pci :01:00.0: [10de:128b] type 00 class 0x03
> [1.114404] pci :01:00.0: reg 0x10: [mem 0x-0x00ff]
> [1.114456] pci :01:00.0: reg 0x14: [mem 0x-0x07ff
> 64bit pref]
> [1.114510] pci :01:00.0: reg 0x1c: [mem 0x-0x01ff
> 64bit pref]
> [1.114551] pci :01:00.0: reg 0x24: [io  0x-0x007f]
> [1.114590] pci :01:00.0: reg 0x30: [mem 0x-0x0007 pref]
> [1.114853] pci :01:00.0: 4.000 Gb/s available PCIe bandwidth,
> limited by 5.0 GT/s PCIe x1 link at :00:00.0 (capable of 63.008
> Gb/s with 8.0 GT/s PCIe x8 link)
> [1.115022] pci :01:00.0: vgaarb: VGA device added:
> decodes=io+mem,owns=none,locks=none
> [1.115125] pci :01:00.1: [10de:0e0f] type 00 class 0x040300
> [1.115184] pci :01:00.1: reg 0x10: [mem 0x-0x3fff]
> [1.119065] pci_bus :01: busn_res: [bus 01-ff] end is updated to 01
> [1.119120] pci :00:00.0: BAR 9: assigned [mem
> 0x6-0x60bff 64bit pref]
> [1.119151] pci :00:00.0: BAR 8: assigned [mem 0x60c00-0x60d7f]

This is your brcm-pcie device.

> [1.119183] pci :01:00.0: BAR 1: assigned [mem
> 0x6-0x607ff 64bit pref]
> [1.119235] pci :01:00.0: BAR 3: assigned [mem
> 0x60800-0x609ff 64bit pref]
> [1.119285] pci :01:00.0: BAR 0: assigned [mem 0x60c00-0x60cff]

And this is the NVIDIA device. Note that these memory windows are
identical (or at least overlapping). I must admit almost complete
ignorance of PCIe and whether this is OK, but it seems sketchy at
first glance. A quick eyeballing of my x86 system suggests that all
PCIe devices get non-overlapping windows. OTOH there are messages
further up about some sort of remapping going on, so perhaps it's OK?
But two things on the same bus still shouldn't have the same addresses
allocated, based on my (limited) understanding.

In case it's an option, could you "unplug" the NIC (not just not load
its driver, but make it not appear at all on the PCI bus)?

> [1.119317] pci :01:00.0: BAR 6: assigned [mem
> 0x60d00-0x60d07 pref]

Never heard of a BAR6 on NVIDIA. Probably just my ignorance though.

> [1.119345] pci :01:00.1: BAR 0: assigned [mem 0x60d08-0x60d083fff]
> [1.119376] pci :01:00.0: BAR 5: no space for [io  size 0x0080]
> [1.119400] pci :01:00.0: BAR 5: failed to assign [io  size 0x0080]
> [1.119426] pci :00:00.0: PCI bridge to [bus 01]
> [1.119456] pci :00:00.0:   bridge window [mem 0x60c00-0x60d7f]
> [1.119484] pci :00:00.0:   bridge window [mem
> 0x6-0x60bff 64bit pref]
> [1.119662] pci :01:00.1: D0 power state depends on :01:00.0

Back to your original issue:

>
>   Dave
>
> > On Wed, Oct 28, 2020, 9:46 AM Dave Stevenson 
> >  wrote:
> >>
> >> Hi
> >>
> >> Seeing as we (Raspberry Pi) have just launched the Compute Module 4
> >> with an exposed PCIe x1 lane, people are asking about adding graphics
> >> cards.
> >>
> >> Seeing as you are the people who

Re: [Nouveau] GT710 and Nouveau on ARM/ARM64

[Ilia Mirkin]

The most common issue on arm is that the pci memory window is too narrow to
allocate all the BARs. Can you see if there are messages in the kernel to
that effect?

On Wed, Oct 28, 2020, 9:46 AM Dave Stevenson 
wrote:

> Hi
>
> Seeing as we (Raspberry Pi) have just launched the Compute Module 4
> with an exposed PCIe x1 lane, people are asking about adding graphics
> cards.
>
> Seeing as you are the people who have the knowledge with regard to
> NVidia and nouveau, what are your immediate thoughts of nouveau
> working on ARM/ARM64? Is there a chance of this working? I'm no PCIe
> expert, although I can call on some expertise :-/
>
> I've tried it so far with a GT710 board [1] and ARM64. It's blowing up
> in the memset of nvkm_instobj_new whilst initialising the BAR
> subdevice [2], having gone through the "No such luck" path in
> nvkm_mmu_ptc_get [3].
>
> Taking the naive approach of simply removing the memset, I get through
> initialising all the subdevices, but again die in a location I
> currently haven't pinpointed. The last logging messages are:
> [ 1023.407302] nouveau :01:00.0: fifo: one-time init completed in 760us
> [ 1023.407312] nouveau :01:00.0: fifo: init completed in 775us
> [ 1023.407325] nouveau: DRM-master::80009009: init running...
> [ 1023.407329] nouveau: DRM-master::80009009: init children...
> [ 1023.407333] nouveau: DRM-master::80009009: init completed in 4us
> [ 1023.407352] nouveau :01:00.0: fifo: fault 01 [WRITE] at
> 000d1000 engine 05 [BAR2] client 08 [HUB/HOST_CPU_NB] reason
> 02 [PTE] on channel -1 [007fd38000 unknown]
> [ 1023.407354] nouveau: DRM-master::: ioctl: return 0
> [ 1023.407385] nouveau: DRM-master::: ioctl: size 32
> [ 1023.407392] nouveau: DRM-master::: ioctl: vers 0
> type 01 object ff80ee8c2170 owner ff
> [ 1023.407415] nouveau: DRM-master::80009009: ioctl: sclass size 8
> [ 1023.407419] nouveau: DRM-master::80009009: ioctl: sclass
> vers 0 count 0
> [ 1023.407432] nouveau: DRM-master::: ioctl: return 0
> [ 1023.407452] nouveau: DRM-master::: ioctl: size 48
> [ 1023.407459] nouveau: DRM-master::: ioctl: vers 0
> type 01 object ff80ee8c2170 owner ff
> [ 1023.407482] nouveau: DRM-master::80009009: ioctl: sclass size 24
> [ 1023.407485] nouveau: DRM-master::80009009: ioctl: sclass
> vers 0 count 2
> [ 1023.407498] nouveau: DRM-master::: ioctl: return 0
> [ 1023.407519] nouveau: DRM-master::: ioctl: size 48
>
> Any input very welcome, otherwise I'll continue blundering about
> slightly in the dark.
>
> Thanks
>   Dave
>
> [1]
> https://www.amazon.co.uk/ASUS-GT710-4H-SL-2GD5-GeForce-Multi-Monitor-Productivity/dp/B0897T6PYM/
> [2]
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/base.c#L114
> [3]
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/base.c#L201
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
>
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Small patch for nv50_vbo.c

[Ilia Mirkin]

This isn't meant to fix applications, it's meant to limit the range of
access to the buffer, for robustness/etc reasons. One would have to
look very carefully, as all this logic is rather tricky.

On Mon, Oct 19, 2020 at 4:07 AM Andrew Randrianasulu
 wrote:
>
> Hi all!
>
> I saw TODO comment in nv50_vbo.c and decided to look at similar file, 
> nvc0_vbo.c. I copied those two lines into nv50 with slight name change 
> (nvc0->nv50) and apparently it doesn't fix any OpenGL app I have, but does 
> not broke them further (I have compute pacthes currently applied, so some 
> breakage expected).
>
> diff --git a/src/gallium/drivers/nouveau/nv50/nv50_vbo.c 
> b/src/gallium/drivers/nouveau/nv50/nv50_vbo.c
> index 8d1c8c7665b..29b63a525aa 100644
> --- a/src/gallium/drivers/nouveau/nv50/nv50_vbo.c
> +++ b/src/gallium/drivers/nouveau/nv50/nv50_vbo.c
> @@ -189,8 +189,12 @@ nv50_user_vbuf_range(struct nv50_context *nv50, unsigned 
> vbi,
> assert(vbi < PIPE_MAX_ATTRIBS);
> if (unlikely(nv50->vertex->instance_bufs & (1 << vbi))) {
>/* TODO: use min and max instance divisor to get a proper range */
> -  *base = 0;
> -  *size = nv50->vtxbuf[vbi].buffer.resource->width0;
> +  const uint32_t div = nv50->vertex->min_instance_div[vbi];
> +  *base = nv50->instance_off * nv50->vtxbuf[vbi].stride;
> +  *size = (nv50->instance_max / div) * nv50->vtxbuf[vbi].stride +
> + nv50->vertex->vb_access_size[vbi];
> +//  *base = 0;
> +//  *size = nv50->vtxbuf[vbi].buffer.resource->width0;
> } else {
>/* NOTE: if there are user buffers, we *must* have index bounds */
>assert(nv50->vb_elt_limit != ~0);
>
> Does this look correct?
>
>
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH] drm/nouveau/device: fix changing endianess code to work on older GPUs

[Ilia Mirkin]

On Tue, Oct 13, 2020 at 8:01 AM Karol Herbst  wrote:
>
> With this we try to detect if the endianess switch works and assume LE if
> not. Suggested by Ben.
>
> Fixes: 51c05340e407 ("drm/nouveau/device: detect if changing endianness 
> failed")
> ---
>  .../gpu/drm/nouveau/nvkm/engine/device/base.c | 39 ---
>  1 file changed, 26 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c 
> b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
> index dcb70677d0acc..7851bec5f0e5f 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
> @@ -2924,17 +2924,34 @@ nvkm_device_del(struct nvkm_device **pdevice)
> }
>  }
>
> +/* returns true if the GPU is in the CPU native byte order */
>  static inline bool
>  nvkm_device_endianness(struct nvkm_device *device)
>  {
> -   u32 boot1 = nvkm_rd32(device, 0x04) & 0x0101;
>  #ifdef __BIG_ENDIAN
> -   if (!boot1)
> -   return false;
> +   const bool big_endian = true;
>  #else
> -   if (boot1)
> -   return false;
> +   const bool big_endian = false;
>  #endif
> +
> +   /* Read NV_PMC_BOOT_1, and assume non-functional endian switch if it
> +* doesn't contain the expected values.
> +*/
> +   u32 pmc_boot_1 = nvkm_rd32(device, 0x04);
> +   if (pmc_boot_1 && pmc_boot_1 != 0x0101)

Are you sure there are no other bits in there, esp on newer GPUs?

> +   return !big_endian; /* Assume GPU is LE in this case. */
> +
> +   /* 0 means LE and 0x0101 means BE GPU. Condition is true when
> +* GPU/CPU endianness don't match.
> +*/
> +   if (big_endian == !pmc_boot_1) {
> +   nvkm_wr32(device, 0x04, 0x0101);
> +   nvkm_rd32(device, 0x00);
> +   if (nvkm_rd32(device, 0x04) != (big_endian ? 0x0101 : 
> 0x))
> +   return !big_endian; /* Assume GPU is LE on any 
> unexpected read-back. */
> +   }
> +
> +   /* CPU/GPU endianness should (hopefully) match. */
> return true;
>  }
>
> @@ -2987,14 +3004,10 @@ nvkm_device_ctor(const struct nvkm_device_func *func,
> if (detect) {
> /* switch mmio to cpu's native endianness */
> if (!nvkm_device_endianness(device)) {
> -   nvkm_wr32(device, 0x04, 0x0101);
> -   nvkm_rd32(device, 0x00);
> -   if (!nvkm_device_endianness(device)) {
> -   nvdev_error(device,
> -   "GPU not supported on 
> big-endian\n");
> -   ret = -ENOSYS;
> -   goto done;
> -   }
> +   nvdev_error(device,
> +   "Couldn't switch GPU to CPUs 
> endianess\n");
> +   ret = -ENOSYS;
> +   goto done;
> }
>
> boot0 = nvkm_rd32(device, 0x00);
> --
> 2.26.2
>
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] nouveau broken on Riva TNT2 in 5.9.0-rc8: GPU not supported on big-endian

[Ilia Mirkin]

On Fri, Oct 9, 2020 at 5:54 PM Karol Herbst  wrote:
>
> On Fri, Oct 9, 2020 at 11:35 PM Ondrej Zary  wrote:
> >
> > Hello,
> > I'm testing 5.9.0-rc8 and found that Riva TNT2 stopped working:
> > [0.00] Linux version 5.9.0-rc8+ (zary@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 :01:00.0: GPU not supported on big-endian
> > [   14.771782] nouveau: probe of :01:00.0 failed with error -38
> >
> > big-endian? WTF? The machine is x86.
> >
>
> mhh, we reworked the endianess checks a bit and apparently that broke
> something... I will give it some thoughts, but could you be so kind
> and create an mmiotrace under 5.9 with nouveau? You won't need to
> start X or anything while doing it. Just enable the trace and modprobe
> nouveau and collect the trace.

Looks like nvkm_device_endianness unconditionally reads out 0x4. I
don't think that reg is there pre-NV11. At least NV4, NV5, NV10 and
maybe NV15 (which is logically pre-NV11) don't support big-endian
mode. Not sure about NV1A, which was the IGP of the series and IIRC
logically pre-NV11 as well (but clearly could only be used with x86
chips, since it was part of the motherboard).

Aha, it's documented in rnndb:

https://github.com/envytools/envytools/blob/master/rnndb/bus/pmc.xml


  -ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH] drm/nouveau/kms/nv50-: Fix clock checking algorithm in nv50_dp_mode_valid()

[Ilia Mirkin]

On Fri, Sep 25, 2020 at 6:08 PM Lyude Paul  wrote:
>
> On Tue, 2020-09-22 at 17:22 -0400, Ilia Mirkin wrote:
> > On Tue, Sep 22, 2020 at 5:14 PM Lyude Paul  wrote:
> > > On Tue, 2020-09-22 at 17:10 -0400, Ilia Mirkin wrote:
> > > > Can we use 6bpc on arbitrary DP monitors, or is there a capability for
> > > > it? Maybe only use 6bpc if display_info.bpc == 6 and otherwise use 8?
> > >
> > > I don't think that display_info.bpc actually implies a minimum bpc, only a
> > > maximum bpc iirc (Ville would know the answer to this one). The other 
> > > thing
> > > to
> > > note here is that we want to assume the lowest possible bpc here since 
> > > we're
> > > only concerned if the mode passed to ->mode_valid can be set under -any-
> > > conditions (including those that require lowering the bpc beyond it's
> > > maximum
> > > value), so we definitely do want to always use 6bpc here even once we get
> > > support for optimizing the bpc based on the available display bandwidth.
> >
> > Yeah, display_info is the max bpc. But would an average monitor
> > support 6bpc? And if it does, does the current link training code even
> > try that when display_info.bpc != 6?
>
> So I did confirm that 6bpc support is mandatory for DP, so yes-6 bpc will 
> always
> work.
>
> But also, your second comment doesn't really apply here. So: to be clear, 
> we're
> not really concerned here about whether nouveau will actually use 6bpc or not.
> In truth I'm not actually sure either if we have any code that uses 6bpc (iirc
> we don't), since we don't current optimize bpc. I think it's very possible for
> us to use 6bpc for eDP displays if I recall though, but I'm not sure on that.
>
> But that's also not the point of this code. ->mode_valid() is only used in two
> situations in DRM modesetting: when probing connector modes, and when checking
> if a mode is valid or not during the atomic check for atomic modesetting. Its
> purpose is only to reject display modes that are physically impossible to set 
> in
> hardware due to static hardware constraints. Put another way, we only check 
> the
> given mode against constraints which will always remain constant regardless of
> the rest of the display state. An example of a static constraint would be the
> max pixel clock supported by the hardware, since on sensible hardware this 
> never
> changes. A dynamic constraint would be something like how much bandwidth is
> currently unused on an MST topology, since that value is entirely dependent on
> the rest of the display state.
>
> So - with that said, bpc is technically a dynamic constraint because while a
> sink and source both likely have their own bpc limits, any bpc which is equal 
> or
> below that limit can be used depending on what the driver decides - which will
> be based on the max_bpc property, and additionally for MST displays it will 
> also
> depend on the available bandwidth on the topology. The only non-dynamic thing
> about bpc is that at a minimum, it will be 6 - so any mode that doesn't fit on
> the link with a bpc of 6 is guaranteed to be a mode that we'll never be able 
> to
> set and therefore want to prune.
>
> So, even if we're not using 6 in the majority of situations, I'm fairly
> confident it's the right value here. It's also what i915 does as well (and 
> they
> previously had to fix a bug that was the result of assuming a minimum of 8bpc
> instead of 6).

Here's the situation I'm trying to avoid:

1. Mode is considered "OK" from a bandwidth perspective @6bpc
2. Modesetting logic never tries 6bpc and the modeset fails

As long as the two bits of logic agree on what is settable, I'm happy.

Cheers,

  -ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [RFC] Documentation: nouveau: Introduce some nouveau documentation

[Ilia Mirkin]

On Thu, Sep 24, 2020 at 9:06 AM Roy Spliet  wrote:
>
>
> Op 23-09-2020 om 22:36 schreef Karol Herbst:
> > On Wed, Sep 23, 2020 at 10:39 PM Jeremy Cline  wrote:
> >>
> >> On Wed, Sep 23, 2020 at 09:02:45PM +0200, Karol Herbst wrote:
> >>> On Fri, Sep 11, 2020 at 6:21 PM Jeremy Cline  wrote:
> >>
> >> 
> >>
> >>> yeah, I think overall this file is a good idea and being able to get a
> >>> quick overview over the driver is helpful. I think if we focus on the
> >>> user facing things first, like the hwmon or other things users
> >>> generally interact with would be helpful. I think if we start to
> >>> document areas where there are many low hanging fruits, this could
> >>> help random people to start with easier tasks and get more used to the
> >>> driver overall, so I'd probably ignore most of the stuff which really
> >>> requires a fundamental understanding on how things work and focus more
> >>> on vbios parsing (which has annoying interfaces anyway and it might
> >>> make sense to make it more consistent and nicer to use) and/or simple
> >>> code interfacing with the mmio space.
> >>>
> >>
> >> I'll admit to being motivated by entirely selfish reasons. I know
> >> practically nothing about nouveau and I'm the type of person who likes
> >> to keep notes about how things work together, both free form and
> >> structured in-line docs. All that to say, I think focusing on the
> >> "low-hanging fruit" stuff will be very beneficial and I'm happy to do
> >> that, but I'm also interested in documenting everything else I run
> >> across.
> >>
> >
> > yeah, that's fine. I was just giving a suggestion on where the initial
> > focus should be on.
> >
> >>> Eg some users have problems with their fans as they are either always
> >>> ramping up to max, or not running at all... GPUs temperature or power
> >>> consumption is reporting incorrectly... all those things users hit
> >>> regularly, but which isn't really important enough so it just falls
> >>> under the table even if it gets reported.
> >>>
> >>
> >> This does bring up an interesting point about organization and target
> >> audiences. Typically when I'm writing documentation I like to organize
> >> things by target audiences, so we could have a layout like:
> >>
> >> * General Introduction
> >>
> >> * User Guide
> >>  - Overview of supported hardware/features/etc
> >
> > That's best to document in a wiki though. And we had plans to convert
> > the existing old wiki over to gitlab. And maybe It think we really
> > should do that and clean it up while we work on that. It's just a huge
> > project but maybe just starting with whatever you want to do would be
> > fine and after a while nothing is left. Anyway, I think we should
> > discuss this more openly with the others as well. i don't like the
> > current wiki anyway, as only approved developers can change things and
> > with a gitlab wiki we could even take MRs on stuff.
> >
> >>  - Installation
> >
> > well.. I think this can be skipped ;) But still, also belongs more
> > into a wiki. I think what we could cover here is to how to clean up
> > remaining stuff from the blob driver as this is something which comes
> > up quite a lot on IRC though.
> >
> >>  - Configuration (module parameters and such)
> >>  - Troubleshooting
> >
> > that would be cool to have in the wiki as well. Just collecting the
> > most common issue and document it there. Especially if it is on
> > gitlab, users can just do that as well :)
> >
> >>  - Getting Involved (bug reporting, running tests, etc)
> >
> > yeah, and we have some stuff on that on the old wiki already, it's
> > just very outdated and needs updating, which as said above can only be
> > done by developers and developers sadly have other things to do :)
> >
> >>
> >> * Developer Guide
> >>  - Architecture Overview
> >>  - External APIs (include/uapi/drm/nouveau_drm.h, any sysfs stuff)?
> >>  - Internal APIs
> >
> > Right, those things I'd like to see in the kernel tree actually.
> >
> >>  - Debugging and Development Tools
> >>  - Contribution Guide
> >>
> >
> > Those I think belong more into the wiki again. The latter is a bit
> > hard to split as there are kernel guides, but also community and
> > project guides. Mesa does things differently than let's say the
> > kernel. And Nouveau is still in this limbo state being on the old
> > infra, but also on the new one with mesa...
> >
> >> I'm not sure how much stuff people want to keep on the
> >> nouveau.freedesktop.org wiki vs here.
> >>
> >
> > I think the first step actually is to set up a proper nouveau project
> > on gitlab for dealing with issues and the wiki. I would be fine to do
> > that and we can also move the code there late. But maybe let's start
> > with the wiki :)
>
> Risking to turn this into a "let's fix everything in one go" project
> that ends up never getting finished, I just want to make sure that
> everybody is also aware of the documentation generated from 

Re: [Nouveau] [PATCH] drm/nouveau/kms/nv50-: Fix clock checking algorithm in nv50_dp_mode_valid()

[Ilia Mirkin]

On Tue, Sep 22, 2020 at 5:14 PM Lyude Paul  wrote:
>
> On Tue, 2020-09-22 at 17:10 -0400, Ilia Mirkin wrote:
> > Can we use 6bpc on arbitrary DP monitors, or is there a capability for
> > it? Maybe only use 6bpc if display_info.bpc == 6 and otherwise use 8?
>
> I don't think that display_info.bpc actually implies a minimum bpc, only a
> maximum bpc iirc (Ville would know the answer to this one). The other thing to
> note here is that we want to assume the lowest possible bpc here since we're
> only concerned if the mode passed to ->mode_valid can be set under -any-
> conditions (including those that require lowering the bpc beyond it's maximum
> value), so we definitely do want to always use 6bpc here even once we get
> support for optimizing the bpc based on the available display bandwidth.

Yeah, display_info is the max bpc. But would an average monitor
support 6bpc? And if it does, does the current link training code even
try that when display_info.bpc != 6?

  -ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH] drm/nouveau/kms/nv50-: Fix clock checking algorithm in nv50_dp_mode_valid()

[Ilia Mirkin]

Can we use 6bpc on arbitrary DP monitors, or is there a capability for
it? Maybe only use 6bpc if display_info.bpc == 6 and otherwise use 8?

On Tue, Sep 22, 2020 at 5:06 PM Lyude Paul  wrote:
>
> While I thought I had this correct (since it actually did reject modes
> like I expected during testing), Ville Syrjala from Intel pointed out
> that the logic here isn't correct. max_clock refers to the max symbol
> rate supported by the encoder, so limiting clock to ds_clock using max()
> doesn't make sense. Additionally, we want to check against 6bpc for the
> time being since that's the minimum possible bpc here, not the reported
> bpc from the connector. See:
>
> https://lists.freedesktop.org/archives/dri-devel/2020-September/280276.html
>
> For more info.
>
> So, let's rewrite this using Ville's advice.
>
> Signed-off-by: Lyude Paul 
> Fixes: 409d38139b42 ("drm/nouveau/kms/nv50-: Use downstream DP clock limits 
> for mode validation")
> Cc: Ville Syrjälä 
> Cc: Lyude Paul 
> Cc: Ben Skeggs 
> ---
>  drivers/gpu/drm/nouveau/nouveau_dp.c | 23 +--
>  1 file changed, 13 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c 
> b/drivers/gpu/drm/nouveau/nouveau_dp.c
> index 7b640e05bd4cd..24c81e423d349 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_dp.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
> @@ -231,23 +231,26 @@ nv50_dp_mode_valid(struct drm_connector *connector,
>const struct drm_display_mode *mode,
>unsigned *out_clock)
>  {
> -   const unsigned min_clock = 25000;
> -   unsigned max_clock, ds_clock, clock;
> +   const unsigned int min_clock = 25000;
> +   unsigned int max_clock, ds_clock, clock;
> +   const u8 bpp = 18; /* 6 bpc */
> enum drm_mode_status ret;
>
> if (mode->flags & DRM_MODE_FLAG_INTERLACE && !outp->caps.dp_interlace)
> return MODE_NO_INTERLACE;
>
> max_clock = outp->dp.link_nr * outp->dp.link_bw;
> -   ds_clock = drm_dp_downstream_max_dotclock(outp->dp.dpcd,
> - outp->dp.downstream_ports);
> -   if (ds_clock)
> -   max_clock = min(max_clock, ds_clock);
> -
> -   clock = mode->clock * (connector->display_info.bpc * 3) / 10;
> -   ret = nouveau_conn_mode_clock_valid(mode, min_clock, max_clock,
> -   );
> +   clock = mode->clock * bpp / 8;
> +   if (clock > max_clock)
> +   return MODE_CLOCK_HIGH;
> +
> +   ds_clock = drm_dp_downstream_max_dotclock(outp->dp.dpcd, 
> outp->dp.downstream_ports);
> +   if (ds_clock && mode->clock > ds_clock)
> +   return MODE_CLOCK_HIGH;
> +
> +   ret = nouveau_conn_mode_clock_valid(mode, min_clock, max_clock, 
> );
> if (out_clock)
> *out_clock = clock;
> +
> return ret;
>  }
> --
> 2.26.2
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] libva-utils test siuite is crashing in nouveau sriver

[Ilia Mirkin]

On Sun, Sep 13, 2020 at 5:01 PM Tomasz Kłoczko  wrote:
>
>
> On Sun, 13 Sep 2020 at 20:35, Ilia Mirkin  wrote:
>>
>> What hardware are you using?
>
>
> :18:00.0 VGA compatible controller: NVIDIA Corporation GP104GL [Quadro 
> P4000] (rev a1)

There's no acceleration support for video decoding past Kepler. FWIW I
don't get a crash with a GP108 when running vainfo:

$ vainfo
libva info: VA-API version 1.8.0
libva info: Trying to open /usr/lib64/va/drivers/nouveau_drv_video.so
libva info: va_openDriver() returns -1
vaInitialize failed with error code -1 (unknown libva error),exit

with Mesa 20.2.0-rc2. Not sure if your issue has been fixed (and now
it errors), or if you're hitting something else. Either way, most
likely an issue with the common code if it indeed persists.

Cheers,

  -ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] libva-utils test siuite is crashing in nouveau sriver

[Ilia Mirkin]

What hardware are you using?

On Sun, Sep 13, 2020 at 2:14 PM Tomasz Kłoczko  wrote:
>
> Hi,
>
> I'm hitting that issue since Mesa 20.0.6 and it is present still in latest 
> version 20.1.7
>
> ```
> [tkloczko@barrel SPECS]$ coredumpctl gdb 3926866
>PID: 3926866 (test_va_api)
>UID: 1000 (tkloczko)
>GID: 1000 (tkloczko)
> Signal: 11 (SEGV)
>  Timestamp: Sun 2020-09-13 18:57:06 BST (32s ago)
>   Command Line: ./test_va_api
> Executable: 
> /home/tkloczko/rpmbuild/BUILD/libva-utils-2.9.0/test/test_va_api
>  Control Group: /user.slice/user-1000.slice/session-297.scope
>   Unit: session-297.scope
>  Slice: user-1000.slice
>Session: 297
>  Owner UID: 1000 (tkloczko)
>Boot ID: ab9d350c623e4313bacb892de46b85f9
> Machine ID: d033f66b249a4ec09acfa81ac205554f
>   Hostname: barrel
>Storage: 
> /var/lib/systemd/coredump/core.test_va_api.1000.ab9d350c623e4313bacb892de46b85f9.3926866.160001982600.zst
>Message: Process 3926866 (test_va_api) of user 1000 dumped core.
>
> Stack trace of thread 3926866:
> #0  0x7f4e2d3fb6d2 vlVaCreateContext 
> (nouveau_drv_video.so + 0xb16d2)
> #1  0x7f4e2e32d0f7 vaCreateContext (libva.so.2 + 0x190f7)
> #2  0x55b48d29a419 n/a 
> (/home/tkloczko/rpmbuild/BUILD/libva-utils-2.9.0/test/test_va_api + 0x4e419)
>
> GNU gdb (GDB) Fedora 9.0.50.20191119-2.fc32
> Copyright (C) 2019 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "x86_64-redhat-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
>
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from 
> /home/tkloczko/rpmbuild/BUILD/libva-utils-2.9.0/test/test_va_api...
> [New LWP 3926866]
> [New LWP 3926903]
> [New LWP 3926906]
> [New LWP 3926905]
> [New LWP 3926904]
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> Core was generated by `./test_va_api'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  vlVaCreateContext (ctx=, config_id=4294967295, 
> picture_width=1920, picture_height=1080, flag=1, render_targets=0x0, 
> num_render_targets=0, context_id=0x55b48e39c458)
> at ../src/gallium/state_trackers/va/context.c:229
> 229 ../src/gallium/state_trackers/va/context.c: No such file or directory.
> [Current thread is 1 (Thread 0x7f4e2ddbf4c0 (LWP 3926866))]
>  elfutils-libelf-0.181-2.fc34.x86_64 expat-2.2.9-2.2.fc34.x86_64 
> glibc-2.32.9000-5.fc34.x86_64 gmp-6.2.0-5.fc33.x86_64 
> libX11-1.6.12-2.fc34.x86_64 libX11-xcb-1.6.12-2.fc34.x86_64 
> libXau-1.0.9-5.fc33.x86_64 libXdmcp-1.1.3-5.fc33.x86_64 
> libdrm-2.4.102-3.fc34.x86_64 libedit-3.1-34.20191231cvs.fc34.x86_64 
> libffi-3.2.1-2.3.fc32.x86_64 libgcc-10.2.1-3.fc34.x86_64 
> libstdc++-10.2.1-3.fc34.x86_64 libva-2.9.0-2.fc34.x86_64 
> libxcb-1.14-6.fc34.x86_64 libxml2-2.9.10-8.fc34.x86_64 
> libxshmfence-1.3-8.fc33.x86_64 libzstd-1.4.5-7.fc34.x86_64 
> llvm-libs-10.0.1-2.1.fc34.x86_64 ncurses-libs-6.2-4.20200817.fc34.x86_64 
> sssd-client-2.3.0-2.fc33.x86_64 xz-libs-5.2.5-4.fc33.x86_64 
> z3-libs-4.8.8-5.fc33.x86_64 zlib-1.2.11-23.fc33.x86_64
> (gdb) bt full
> Missing separate debuginfos, use: dnf debuginfo-install#0  vlVaCreateContext 
> (ctx=, config_id=4294967295, picture_width=1920, 
> picture_height=1080, flag=1, render_targets=0x0, num_render_targets=0, 
> context_id=0x55b48e39c458)
> at ../src/gallium/state_trackers/va/context.c:229
> drv = 0x55b48e398280
> context = 
> config = 0x0
> is_vpp = 
> #1  0x7f4e2e32d0f7 in vaCreateContext () from /lib64/libva.so.2
> No symbol table info available.
> #2  0x55b48d29a419 in VAAPI::VAAPIFixture::doCreateContext 
> (this=, resolution=..., expectation=@0x7ffea3f6e468: 4) at 
> test_va_api_fixture.cpp:436
> gtest_ar = {success_ = 32, message_ = {ptr_ = 0xebe6e1ca084a2300}}
> #3  0x55b48d29ed34 in 
> VAAPI::VAAPICreateContextToFail_CreateContextWithNoConfig_Test::TestBody 
> (this=0x55b48e39c430) at test_utils.h:36
> No locals.
> #4  0x55b48d296e23 in testing::Test::Run (this=0x55b48e39c430) at 
> ../test/gtest/src/gtest.cc:2474
> impl = 0x55b48d91af60
> impl = 
> #5  testing::Test::Run (this=0x55b48e39c430) at 
> ../test/gtest/src/gtest.cc:2465
> impl = 
> impl = 
> #6  testing::TestInfo::Run (this=0x55b48d91fe00) at 
> 

Re: [Nouveau] VAAPI on GeForce GT 620M

[Ilia Mirkin]

On Tue, Sep 1, 2020 at 9:10 AM Analabha Roy  wrote:
> Any suggestions on how to trace the config issues? Do I have to debug the 
> va_openDriver() function?

My guess, without reading any code, is that DRI_PRIME isn't doing what
you want it to, and the nouveau driver is being handed an intel
device. This does not work well. Fixing this will require tracing
through the va winsys code which to figure out how it invokes the
loader.

https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/frontends/va/context.c#n111

For the DRM/rendernodes "platform", it will just take whatever fd it
is given. vainfo appears to give it a fixed device:

https://github.com/intel/libva-utils/blob/master/common/va_display_drm.c#L39

However it looks like you can pass in --device /dev/dri/renderD129 or
whatever the right one is, which should pass in the right render node,
as seen here:

https://github.com/intel/libva-utils/blob/master/common/va_display.c#L80

Note that I've never tried this, just did a few google searches to
find this stuff.

Cheers,

  -ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] VAAPI on GeForce GT 620M

[Ilia Mirkin]

On Tue, Sep 1, 2020 at 3:31 AM Analabha Roy  wrote:
>
> Hi,
>
> If I am reading the featurematrix right, VAAPI is supported for nouveau on 
> the GeForce650M (my card).
>
> Here is the output of inxi -F
>
> System:Host: MediaServer Kernel: 5.4.0-42-generic x86_64 bits: 64 
> Console: tty 1 Distro: Ubuntu 18.04.5 LTS
> Machine:   Device: laptop System: SAMSUNG product: 300E4C/300E5C/300E7C v: 
> 0.1 serial: N/A
>Mobo: SAMSUNG model: NP300E5X-U01IN v: FAB1 serial: N/A
>UEFI [Legacy]: Phoenix v: P06RAC date: 10/25/2012
> BatteryBAT1: charge: 47.5 Wh 100.0% condition: 47.5/47.5 Wh (100%)
> CPU:   Dual core Intel Core i3-2310M (-MT-MCP-) cache: 3072 KB
>clock speeds: max: 2100 MHz 1: 835 MHz 2: 1031 MHz 3: 905 MHz 4: 
> 927 MHz
> Graphics:  Card-1: Intel 2nd Generation Core Processor Family Integrated 
> Graphics Controller
>Card-2: NVIDIA GF108M [GeForce GT 620M]
>Display Server: X.org 1.20.8 driver: i915 tty size: 171x45 
> Advanced Data: N/A out of X
>
>
> I have installed nouveau, and extracted the firmware from the prop nvidia 
> drivers separately as per instructions on 
> https://nouveau.freedesktop.org/wiki/VideoAcceleration/
> See installed firmware @ https://pastebin.com/Gaqxb88g
>
> But running vainfo yields error: https://pastebin.com/NyULBhXt
>
> Does the error mean that VAAPI is unsupported, or does it indicate a config 
> problem?

As Karol suggests, using the onboard CPU's decoding capabilities will
yield better results. However if there's some specific reason you
want/need to use the NVIDIA card, it should still work. I note that
you don't have an X server running - is that on purpose? I believe
that va-api needs some sort of winsys to be available, but I guess I'm
not entirely sure.

Do you see any errors in dmesg after running vainfo?

Cheers,

  -ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] qemu -display sdl,gl=on also eats CPU

[Ilia Mirkin]

The DDX eating CPU isn't intrinsically bad. Did you check where perf
says the CPU time is going? Could be doing copies/etc.

On Mon, Aug 17, 2020 at 12:52 AM Andrew Randrianasulu
 wrote:
>
> I was testing Ilia's patches for ddx, and while they definitely helped for 
> Xorg itself,
> qemu still eats a lot of CPU if launched like this
>
> qemu-system-x86_64 -cdrom ~/Downloads/ISO/slax-English-US-7.0.8-x86_64.iso -m 
> 1G -display sdl,gl=on -enable-kvm
>
> and left for few hours.
>
> top - 07:38:01 up 18:05,  2 users,  load average: 2,00, 1,89, 1,83
> Tasks: 224 total,   3 running, 221 sleeping,   0 stopped,   0 zombie
> %Cpu(s): 40,6 us,  6,1 sy,  0,3 ni, 49,2 id,  0,8 wa,  0,0 hi,  2,9 si,  0,0 
> st
> MiB Mem :  11875,3 total,   3535,7 free,   3339,3 used,   5000,3 buff/cache
> MiB Swap:   1145,0 total,   1131,2 free, 13,8 used.   4874,7 avail Mem
>
>   PID USER  PR  NIVIRTRESSHR S  %CPU  %MEM TIME+ COMMAND
>  6215 guest 20   0 1455160 951768  45560 R  99,3   7,8 710:44.44 
> qemu-system-x86
> 12655 guest 20   0 2459848   1,5g 126708 R  59,1  12,6 217:53.21 seamonkey
>  1991 root  20   0  178112 109500  28840 S  20,9   0,9 187:20.05 Xorg
>  2068 guest 20   0  104932  51660  30764 S   5,6   0,4  54:08.99 ktorrent
>  6031 root  20   0   0  0  0 I   2,0   0,0   0:20.24 
> kworker/0:3-events
>  3697 guest 20   0  382432  20308  13696 S   1,7   0,2  91:38.13 xmms
>  2064 guest 20   0   55868  37048  23976 S   1,3   0,3   2:38.47 konsole
>  2319 guest 20   0   40160  21248  18548 S   1,3   0,2  12:36.63 gkrellm
>  5853 root  20   0   0  0  0 I   0,7   0,0   0:07.21 
> kworker/2:2-events
>
> opreport after  operf --pid 6215 said:
>
> opreport
> Using /home/guest/botva/src/xf86-video-nouveau/oprofile_data/samples/ for 
> samples directory.
> CPU: AMD64 family15h, speed 3800 MHz (estimated)
> Counted CPU_CLK_UNHALTED events (CPU Clocks not Halted) with a unit mask of 
> 0x00 (No unit mask) count 10
> CPU_CLK_UNHALT...|
>   samples|  %|
> --
>260163 100.000 qemu-system-x86_64
> CPU_CLK_UNHALT...|
>   samples|  %|
> --
>144120 55.3960 nouveau_dri.so
> 87990 33.8211 libdrm_nouveau.so.2.0.0
> 11783  4.5291 libpixman-1.so.0.38.0
>  7884  3.0304 kallsyms
>  5310  2.0410 libc-2.30.so
>   689  0.2648 ld-2.30.so
>   519  0.1995 nouveau
>   501  0.1926 qemu-system-x86_64
>   456  0.1753 ttm
>   239  0.0919 kvm
>   211  0.0811 kvm_amd
>81  0.0311 libpthread-2.30.so
>76  0.0292 drm
>49  0.0188 libSDL2-2.0.so.0.12.0
>43  0.0165 libxcb.so.1.1.0
>36  0.0138 libGL.so.1.2.0
>31  0.0119 libX11.so.6.3.0
>24  0.0092 snd_pcm
>23  0.0088 snd_hda_codec
>20  0.0077 libglib-2.0.so.0.5800.1
>11  0.0042 snd_timer
> 9  0.0035 libglapi.so.0.0.0
> 8  0.0031 libdrm.so.2.4.0
> 7  0.0027 snd_aloop
> 7  0.0027 snd_hda_intel
> 7  0.0027 libxshmfence.so.1.0.0
> 7  0.0027 libgcc_s.so.1
> 5  0.0019 [vdso] (tgid:6215 range:0xf7f9f000-0xf7f9)
> 5  0.0019 snd_hda_core
> 4  0.0015 r8169
> 3  0.0012 libahci
> 2 7.7e-04 ohci_hcd
> 2 7.7e-04 libxcb-present.so.0.0.0
> 1 3.8e-04 libatomic.so.1.1.0
>
> so, may be similar fix needed for mesa, too?
>
> ow, I started it in ddx src directory :} need to cleanup there. But at least 
> data is 100
>
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Accumulating CPU load from Xorg process with DRI3

[Ilia Mirkin]

On Sun, Aug 16, 2020 at 8:20 AM Andrew Randrianasulu
 wrote:
>
> В сообщении от Sunday 16 August 2020 07:20:18 Ilia Mirkin написал(а):
> > Well, if it's easy, try the patches I mailed to nouveau@ for the ddx.
>
> I applied patches manually (copy-pasted patches failed to apply by git apply,
> probably whitespace/end of line issues), and now I see in X log (after I left 
> machine to run alone):
>
> [  3584.553] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid 
> argument
> [  3584.553] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid 
> argument
> [  3584.570] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid 
> argument
> [  3584.586] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid 
> argument
> [  3584.602] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid 
> argument
> [  3584.619] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid 
> argument
> [  3584.635] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid 
> argument
> [  3584.651] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid 
> argument
> [  3584.668] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid 
> argument
> [  3584.684] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid 
> argument
> [  3584.700] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid 
> argument
> [  3584.717] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid 
> argument
> [  3584.733] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid 
> argument
> [  3584.749] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid 
> argument
> [  3584.766] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid 
> argument
> [  3584.782] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid 
> argument
> [  3584.798] (DB) NOUVEAU(0): PRESENT: Wait for VBlank failed: Invalid 
> argument

Aha, appears my assumption that X_DEBUG would get skipped under normal
Xorg invocations was wrong. I didn't mean for these to appear under
normal circumstances. I guess I'll #if 0 it out.

>
> and around 6mb more of those 
>
> but X still uses small amount of CPU:
>
>  op - 15:04:41 up  1:32,  2 users,  load average: 1,25, 1,67, 1,60
> Tasks: 220 total,   2 running, 218 sleeping,   0 stopped,   0 zombie
> %Cpu(s): 22,8 us,  5,9 sy,  0,3 ni, 69,2 id,  1,4 wa,  0,0 hi,  0,4 si,  0,0 
> st
> MiB Mem :  11875,3 total,   7630,1 free,   1967,5 used,   2277,7 buff/cache
> MiB Swap:   1145,0 total,   1145,0 free,  0,0 used.   9172,1 avail Mem
>
>   PID USER  PR  NIVIRTRESSHR S  %CPU  %MEM TIME+ COMMAND
>  2777 guest 20   0 2155076   1,2g 126108 R  84,4  10,7  69:24.46 seamonkey
>  1991 root  20   0  145764  78444  27936 S  14,6   0,6   6:42.10 Xorg
>  3697 guest 20   0   61208  17268  13580 S  12,6   0,1   7:34.75 xmms
>  2045 guest 20   06360   3932   2668 S   2,3   0,0   0:35.90 kompmgr
>  2068 guest 20   0  102664  48952  30764 S   2,3   0,4   2:35.98 ktorrent
>  2049 guest 20   0   42792  27908  23684 S   1,7   0,2   0:12.72 kicker
>  2319 guest 20   0   40160  21248  18548 S   1,3   0,2   0:55.63 gkrellm
>  2064 guest 20   0   50900  31592  23720 S   1,0   0,3   0:25.53 konsole
>  5086 root  20   0   0  0  0 I   0,7   0,0   0:02.57 
> kworker/0:2-events
>10 root  20   0   0  0  0 I   0,3   0,0   0:09.96 
> rcu_preempt
>  1918 root  20   0   0  0  0 I   0,3   0,0   0:04.78 
> kworker/3:0-events
>  2240 guest 20   0   59660  37848  30248 S   0,3   0,3   0:02.36 konqueror
>  2389 guest 20   0   33048  22592  20376 S   0,3   0,2   0:00.24 kdesu
>
> with CPU frequency set to 1.4Ghz (minimum possible). Usually around 5.6%-6.0%
> vblanks still work, at least glxgears from both cards still run at ~60 fps by 
> default
>
> I'll run with those patches for few more hours, but so far they seems to be 
> helpful.

Great!

  -ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH 1/2] drmmode: make event handler leave a note that there are stuck events

[Ilia Mirkin]

We don't really expect to have too many events in the queue. If there
are, then the algorithm we use isn't appropriate. Add a warning when the
queue gets very long, as it's an indication of something having gone
wrong.

Signed-off-by: Ilia Mirkin 
---
 src/drmmode_display.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index 2d3229c..45292c4 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -159,6 +159,8 @@ drmmode_events = {
.prev = _events,
 };
 
+static bool warned = false;
+
 static void
 drmmode_event_handler(int fd, unsigned int frame, unsigned int tv_sec,
  unsigned int tv_usec, void *event_data)
@@ -166,7 +168,10 @@ drmmode_event_handler(int fd, unsigned int frame, unsigned 
int tv_sec,
const uint64_t ust = (uint64_t)tv_sec * 100 + tv_usec;
struct drmmode_event *e = event_data;
 
+   int counter = 0;
+
xorg_list_for_each_entry(e, _events, head) {
+   counter++;
if (e == event_data) {
xorg_list_del(>head);
e->func((void *)(e + 1), e->name, ust, frame);
@@ -174,6 +179,12 @@ drmmode_event_handler(int fd, unsigned int frame, unsigned 
int tv_sec,
break;
}
}
+
+   if (counter > 100 && !warned) {
+   xf86DrvMsg(0, X_WARNING,
+  "Event handler iterated %d times\n", counter);
+   warned = true;
+   }
 }
 
 void
-- 
2.26.2

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH 2/2] present: fix handling of drmWaitVBlank failures

[Ilia Mirkin]

When drmWaitVBlank fails, make sure to remove the event from the queue.

Signed-off-by: Ilia Mirkin 
---

Note this needs a bit more testing, and also double-checking what the
"correct" way of dealing with these errors is. I was able to trigger
errors with "xset dpms force off", but perhaps there are also other
conditions.

 src/nouveau_present.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/src/nouveau_present.c b/src/nouveau_present.c
index 8167fd8..15516d6 100644
--- a/src/nouveau_present.c
+++ b/src/nouveau_present.c
@@ -113,8 +113,19 @@ nouveau_present_vblank_queue(RRCrtcPtr rrcrtc, uint64_t 
event_id, uint64_t msc)
args.request.signal = (unsigned long)token;
 
while ((ret = drmWaitVBlank(pNv->dev->fd, )) != 0) {
-   if (errno != EBUSY || drmmode_event_flush(crtc->scrn) < 0)
+   if (errno != EBUSY) {
+   xf86DrvMsg(crtc->scrn->scrnIndex, X_DEBUG,
+  "PRESENT: Wait for VBlank failed: %s\n", 
strerror(errno));
+   drmmode_event_abort(crtc->scrn, event_id, false);
return BadAlloc;
+   }
+   ret = drmmode_event_flush(crtc->scrn);
+   if (ret < 0) {
+   xf86DrvMsg(crtc->scrn->scrnIndex, X_DEBUG,
+  "PRESENT: Event flush failed\n");
+   drmmode_event_abort(crtc->scrn, event_id, false);
+   return BadAlloc;
+   }
}
 
return Success;
-- 
2.26.2

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Accumulating CPU load from Xorg process with DRI3

[Ilia Mirkin]

I've tracked down at least one source of these, which is that we don't
handle drmWaitVBlank errors properly in the PRESENT logic (which would
be used in conjunction with DRI3). These errors, broadly, will happen
while strings are turned off and/or in DPMS sleep. Did your monitors
go to sleep while a video was playing? If not, there's another path
for it to happen...

Cheers,

  -ilia

On Thu, Aug 13, 2020 at 6:47 PM Ilia Mirkin  wrote:
>
> I'm aware of this issue, and am experiencing it myself.
>
> The issue is that drmmode_event_handler takes up more and more CPU
> time. It seems like some events are being "left behind". I haven't had
> time to debug it further yet though.
>
> I also have DRI3 enabled, but only very rarely do I make use of my
> secondary GPUs, and I'm pretty sure I've seen the problem happen
> without any PRIME usage.
>
> Cheers,
>
>   -ilia
>
> On Thu, Aug 13, 2020 at 6:45 PM Andrew Randrianasulu
>  wrote:
> >
> > I observed this bug for quite some time, but so far I workarounded it
> > with just setting DRI2 (default) in xorg.conf.d/20-nouveau.conf
> >
> > Now with two GPU i iwsh to use DRI3, so right now it set up like this:
> >
> > cat /etc/X11/xorg.conf.d/20-nouveau.conf
> > Section "Device"
> > Identifier "Card0"
> > Driver "nouveau"
> > Option "PageFlip" "1"
> > #Option "AccelMethod" "glamor"
> > Option   "DRI"   "3"
> >
> > But just after two hours of uptime X already eating some CPU:
> >
> >
> > op - 01:30:49 up  2:45,  1 user,  load average: 1,12, 0,93, 0,84
> > Tasks: 210 total,   1 running, 209 sleeping,   0 stopped,   0 zombie
> > %Cpu(s): 12,1 us,  3,9 sy,  0,0 ni, 81,7 id,  0,7 wa,  0,0 hi,  1,6 si,  
> > 0,0 st
> > MiB Mem :  11875,3 total,   6416,4 free,   1634,8 used,   3824,1 buff/cache
> > MiB Swap:   1145,0 total,   1145,0 free,  0,0 used.   9969,7 avail Mem
> >
> >   PID USER  PR  NIVIRTRESSHR S  %CPU  %MEM TIME+ COMMAND
> >  1198 root  20   0  146160  78828  28160 S  35,8   0,6  30:41.37 Xorg
> >  1285 guest 20   0   59776  17332  13756 S  11,6   0,1  16:12.83 xmms
> >  4006 guest 20   0 1743952 919312 120628 S  10,9   7,6  20:51.01 
> > seamonkey
> >  1278 guest 20   0  101508  48528  30496 S   3,0   0,4   4:03.21 
> > ktorrent
> >  1274 guest 20   0   43368  31784  23684 S   2,0   0,3   0:29.43 konsole
> >  1259 guest 20   0   43092  28232  23640 S   1,3   0,2   0:21.53 kicker
> >  1255 guest 20   06560   4160   2720 S   1,0   0,0   1:00.90 kompmgr
> >  1293 guest 20   0   40164  21328  18636 S   1,0   0,2   1:30.50 gkrellm
> >  1254 guest 20   0   31616  21832  18944 S   0,7   0,2   0:06.49 kwin
> >
> > in ~1 day it will eat full core from my AMD FX-4300 and X will become 
> > sluggish ...
> >
> > I tried to trace it with operf 1.2.0:
> >
> > operf --pid 1198
> >
> > operf: Press Ctl-c or 'kill -SIGINT 7787' to stop profiling
> > operf: Profiler started
> > ^C
> > Profiling done.
> >
> > root@slax:~# opreport
> > Using /root/oprofile_data/samples/ for samples directory.
> > CPU: AMD64 family15h, speed 3800 MHz (estimated)
> > Counted CPU_CLK_UNHALTED events (CPU Clocks not Halted) with a unit mask of 
> > 0x00 (No unit mask) count 10
> > CPU_CLK_UNHALT...|
> >   samples|  %|
> > --
> > 78166 100.000 Xorg
> > CPU_CLK_UNHALT...|
> >   samples|  %|
> > --
> > 62905 80.4762 nouveau_drv.so
> >  5648  7.2256 kallsyms
> >  4186  5.3553 Xorg
> >  1419  1.8154 libpixman-1.so.0.38.0
> >  1038  1.3279 nouveau
> >   687  0.8789 libc-2.30.so
> >   632  0.8085 libexa.so
> >   510  0.6525 libdrm_nouveau.so.2.0.0
> >   402  0.5143 libfb.so
> >   259  0.3313 drm
> >   230  0.2942 ttm
> >   108  0.1382 libpthread-2.30.so
> >47  0.0601 libdrm.so.2.4.0
> >34  0.0435 [vdso] (tgid:1198 range:0xf7fbf000-0xf7fb)
> >27  0.0345 evdev_drv.so
> > 7  0.0090 snd_hda_codec
> > 5  0.0064 r8169
> > 5  0.0064 snd_pcm
> > 5  0.0064 libXfont2.so.2.0.0
> > 3  0.0038 snd_aloop
> > 3  0.0

Re: [Nouveau] Accumulating CPU load from Xorg process with DRI3

[Ilia Mirkin]

I'm aware of this issue, and am experiencing it myself.

The issue is that drmmode_event_handler takes up more and more CPU
time. It seems like some events are being "left behind". I haven't had
time to debug it further yet though.

I also have DRI3 enabled, but only very rarely do I make use of my
secondary GPUs, and I'm pretty sure I've seen the problem happen
without any PRIME usage.

Cheers,

  -ilia

On Thu, Aug 13, 2020 at 6:45 PM Andrew Randrianasulu
 wrote:
>
> I observed this bug for quite some time, but so far I workarounded it
> with just setting DRI2 (default) in xorg.conf.d/20-nouveau.conf
>
> Now with two GPU i iwsh to use DRI3, so right now it set up like this:
>
> cat /etc/X11/xorg.conf.d/20-nouveau.conf
> Section "Device"
> Identifier "Card0"
> Driver "nouveau"
> Option "PageFlip" "1"
> #Option "AccelMethod" "glamor"
> Option   "DRI"   "3"
>
> But just after two hours of uptime X already eating some CPU:
>
>
> op - 01:30:49 up  2:45,  1 user,  load average: 1,12, 0,93, 0,84
> Tasks: 210 total,   1 running, 209 sleeping,   0 stopped,   0 zombie
> %Cpu(s): 12,1 us,  3,9 sy,  0,0 ni, 81,7 id,  0,7 wa,  0,0 hi,  1,6 si,  0,0 
> st
> MiB Mem :  11875,3 total,   6416,4 free,   1634,8 used,   3824,1 buff/cache
> MiB Swap:   1145,0 total,   1145,0 free,  0,0 used.   9969,7 avail Mem
>
>   PID USER  PR  NIVIRTRESSHR S  %CPU  %MEM TIME+ COMMAND
>  1198 root  20   0  146160  78828  28160 S  35,8   0,6  30:41.37 Xorg
>  1285 guest 20   0   59776  17332  13756 S  11,6   0,1  16:12.83 xmms
>  4006 guest 20   0 1743952 919312 120628 S  10,9   7,6  20:51.01 seamonkey
>  1278 guest 20   0  101508  48528  30496 S   3,0   0,4   4:03.21 ktorrent
>  1274 guest 20   0   43368  31784  23684 S   2,0   0,3   0:29.43 konsole
>  1259 guest 20   0   43092  28232  23640 S   1,3   0,2   0:21.53 kicker
>  1255 guest 20   06560   4160   2720 S   1,0   0,0   1:00.90 kompmgr
>  1293 guest 20   0   40164  21328  18636 S   1,0   0,2   1:30.50 gkrellm
>  1254 guest 20   0   31616  21832  18944 S   0,7   0,2   0:06.49 kwin
>
> in ~1 day it will eat full core from my AMD FX-4300 and X will become 
> sluggish ...
>
> I tried to trace it with operf 1.2.0:
>
> operf --pid 1198
>
> operf: Press Ctl-c or 'kill -SIGINT 7787' to stop profiling
> operf: Profiler started
> ^C
> Profiling done.
>
> root@slax:~# opreport
> Using /root/oprofile_data/samples/ for samples directory.
> CPU: AMD64 family15h, speed 3800 MHz (estimated)
> Counted CPU_CLK_UNHALTED events (CPU Clocks not Halted) with a unit mask of 
> 0x00 (No unit mask) count 10
> CPU_CLK_UNHALT...|
>   samples|  %|
> --
> 78166 100.000 Xorg
> CPU_CLK_UNHALT...|
>   samples|  %|
> --
> 62905 80.4762 nouveau_drv.so
>  5648  7.2256 kallsyms
>  4186  5.3553 Xorg
>  1419  1.8154 libpixman-1.so.0.38.0
>  1038  1.3279 nouveau
>   687  0.8789 libc-2.30.so
>   632  0.8085 libexa.so
>   510  0.6525 libdrm_nouveau.so.2.0.0
>   402  0.5143 libfb.so
>   259  0.3313 drm
>   230  0.2942 ttm
>   108  0.1382 libpthread-2.30.so
>47  0.0601 libdrm.so.2.4.0
>34  0.0435 [vdso] (tgid:1198 range:0xf7fbf000-0xf7fb)
>27  0.0345 evdev_drv.so
> 7  0.0090 snd_hda_codec
> 5  0.0064 r8169
> 5  0.0064 snd_pcm
> 5  0.0064 libXfont2.so.2.0.0
> 3  0.0038 snd_aloop
> 3  0.0038 libglx.so
> 2  0.0026 kvm
> 2  0.0026 snd_timer
> 1  0.0013 snd_hda_core
> 1  0.0013 snd_hda_intel
>
> so, nouveau_drv itself is major CPU eater 
>
> I'll try to rebuild it with debug symbols enabled, and hopefully it will be 
> enough
> for at least seeing who eats all those cycles 
>
> Sorry for so many emails, just i keep discovering new bugs as I try new 
> things!
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH 2/2] present: don't enable if there's no acceleration

[Ilia Mirkin]

All the present logic relies on EXA being used to wrap everything.
Unclear if present could even be used without the other things EXA
enables, but better be safe.

Signed-off-by: Ilia Mirkin 
---
 src/nv_driver.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/nv_driver.c b/src/nv_driver.c
index a63674c..e72a6b6 100644
--- a/src/nv_driver.c
+++ b/src/nv_driver.c
@@ -1489,7 +1489,7 @@ NVScreenInit(SCREEN_INIT_ARGS_DECL)
 
xf86SetBlackWhitePixels(pScreen);
 
-   if (nouveau_present_init(pScreen))
+   if (pNv->AccelMethod == EXA && nouveau_present_init(pScreen))
xf86DrvMsg(pScrn->scrnIndex, X_INFO,
   "Hardware support for Present enabled\n");
else
-- 
2.26.2

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH 1/2] drmmode: fix screen resize without acceleration

[Ilia Mirkin]

This got broken with commit 86024cee back in 2014!
drmmode_pixmap/nouveau_pixmap expect there to be EXA wrapping around the
pixmap now, which is not there without accel.

Signed-off-by: Ilia Mirkin 
---
 src/drmmode_display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index 89927a4..69421e1 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -1561,7 +1561,7 @@ drmmode_xf86crtc_resize(ScrnInfoPtr scrn, int width, int 
height)
}
 
ppix = screen->GetScreenPixmap(screen);
-   if (pNv->AccelMethod >= NONE)
+   if (pNv->AccelMethod > NONE)
nouveau_bo_ref(pNv->scanout, _pixmap(ppix)->bo);
screen->ModifyPixmapHeader(ppix, width, height, -1, -1, pitch,
   (pNv->AccelMethod > NONE || pNv->ShadowPtr) ?
-- 
2.26.2

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Framebuffer double buffering (via FBIOPAN_DISPLAY)

[Ilia Mirkin]

Intel (i915) uses the same fbdev emulation layer, so should be largely
identical. Just make sure you're using a v4.12+ kernel -- I believe you
mentioned that your Intel system was using 4.9, so that's expected to not
support overallocation.

You might be interested instead in making a kms client which does all this,
as fbdev is deprecated and is unlikely to see any further development (even
to extend the emulation layer to provide features various dedicated drivers
may have had). Some samples available in e.g. kmscube:
https://cgit.freedesktop.org/mesa/kmscube/ (it used to be much simpler, but
has grown various demo features over the years).

Good luck!

  -ilia

On Sun, Jul 5, 2020 at 7:51 PM Michael T. Kloos 
wrote:

> Oops, the FBIOPAN_DISPLAY ioctl error was a stupid mistake on mistake on
> my part.  Thanks for the info on where the validation code was.  Comparing
> against that made it easy to find the mistake.  It's working now,
> well...where I have been able to get over-allocation working!  Thanks for
> the help.  If I can't get the over-allocation to work on my other systems,
> I'll take it up in Intel Graphics specific channels.  While the code is a
> mess right now, here is a link to the program:
> https://github.com/EchelonX-Ray/ttygraphics .  I'm just trying to learn
> about this and you really helped.
> On 7/5/20 7:17 PM, Ilia Mirkin wrote:
>
> Check fb_pan_display in drivers/video/fbdev/core/fbmem.c for the
> argument validation of the FBIOPAN_DISPLAY ioctl.
>
> CONFIG_FB_NVIDIA is a dedicated fbdev driver, not compatible with
> nouveau (it takes over the relevant PCI device). It also won't support
> your Pascal GPU, I believe -- I think it MIGHT support the Tesla
> generation (i.e. G80..GT21x) but definitely not anything newer. Most
> likely it supports pre-G80 GPUs, and again, not compatible with
> nouveau.
>
> DRM-based drivers use the DRM <-> FBDEV emulation layer to provide an
> fbdev interface for legacy applications. The fbdev emulation acts as
> sort of a regular DRM client and exposes the FBDEV API.
>
> The overallocation logic was added to this emulation layer in commit
> 5f15257689bfa, which is included in v4.12 and later kernels.
>
> Hope this helps,
>
>   -ilia
>
> On Sun, Jul 5, 2020 at 7:02 PM Michael T. Kloos 
>  wrote:
>
> Well...it's been a bit of a mixed bag.  Setting
> drm_kms_helper.drm_fbdev_overalloc=200 set the vinfo.yres_virtual to
> 2160 as opposed to 1080 (My monitor vertical resolution)  This fixed the
> mmap() problem.  However, it only worked on my main workstation.  My
> laptop running Intel graphics wasn't affected by the change in kernel
> cmdline.  My workstation is a custom build from a few years ago with a
> GTX 1060 6GB, running Gentoo(Kernel version: 5.4) machine, and my laptop
> running Manjaro.  I also can not get the IOCTL FBIOPAN_DISPLAY to work.
> It is now giving me an invalid argument error.  I have set vinfo.xoffset
> and vinfo.yoffset to 0 earlier in my program to try to eliminate them as
> variables.
>
> Other factors that may be at play:
>
> -I am trying to run this from an alternate TTY.  I have a graphical
> environment on TTY7 with x.org.  I think it is using the DRM interface.
> Maybe there is a conflict.
> -Maybe I am missing a driver in my Gentoo kernel config?  I'm still
> learning about it, but going into my workstation's kernel config, I
> noticed that CONFIG_FB_NVIDIA was set to "n".
>
> Do you know when CONFIG_DRM_FBDEV_OVERALLOC went into the kernel?  I was
> about to try this on my MacBook Pro running Gentoo, but I will have to
> recompile upgrade the kernel before I can give a report (It is currently
> running: 4.9).  I couldn't find it in menuconfig so I doubt the cmdline
> would make a difference.
>
> I really appreciate the help.  I've been looking header files and a such
> trying to cobble together some information to figure this out.  I hate
> to bother you with this because it seems slightly off topic.
>
> On 7/5/20 3:45 PM, Ilia Mirkin wrote:
>
> Try booting with drm_kms_helper.drm_fbdev_overalloc=200 and see if it
> works with that. (There's also CONFIG_DRM_FBDEV_OVERALLOC which sets
> the default.)
>
> Cheers,
>
>-ilia
>
> On Sun, Jul 5, 2020 at 3:41 PM  
>  wrote:
>
> I am not familiar with that setting, but I have really struggled to find 
> documentation on dealing with the framebuffer.  Referring to this guide, 
> "http://betteros.org/tut/graphics1.php#doublebuffer; 
> <http://betteros.org/tut/graphics1.php#doublebuffer>, I attempted to set the 
> mmap allocation size to double, but it caused the mmap to fail.  I no longer 
> believe that it is a driver issue, though, because I just tried it again on a 
> dell laptop with Inte

Re: [Nouveau] Framebuffer double buffering (via FBIOPAN_DISPLAY)

[Ilia Mirkin]

Check fb_pan_display in drivers/video/fbdev/core/fbmem.c for the
argument validation of the FBIOPAN_DISPLAY ioctl.

CONFIG_FB_NVIDIA is a dedicated fbdev driver, not compatible with
nouveau (it takes over the relevant PCI device). It also won't support
your Pascal GPU, I believe -- I think it MIGHT support the Tesla
generation (i.e. G80..GT21x) but definitely not anything newer. Most
likely it supports pre-G80 GPUs, and again, not compatible with
nouveau.

DRM-based drivers use the DRM <-> FBDEV emulation layer to provide an
fbdev interface for legacy applications. The fbdev emulation acts as
sort of a regular DRM client and exposes the FBDEV API.

The overallocation logic was added to this emulation layer in commit
5f15257689bfa, which is included in v4.12 and later kernels.

Hope this helps,

  -ilia

On Sun, Jul 5, 2020 at 7:02 PM Michael T. Kloos
 wrote:
>
> Well...it's been a bit of a mixed bag.  Setting
> drm_kms_helper.drm_fbdev_overalloc=200 set the vinfo.yres_virtual to
> 2160 as opposed to 1080 (My monitor vertical resolution)  This fixed the
> mmap() problem.  However, it only worked on my main workstation.  My
> laptop running Intel graphics wasn't affected by the change in kernel
> cmdline.  My workstation is a custom build from a few years ago with a
> GTX 1060 6GB, running Gentoo(Kernel version: 5.4) machine, and my laptop
> running Manjaro.  I also can not get the IOCTL FBIOPAN_DISPLAY to work.
> It is now giving me an invalid argument error.  I have set vinfo.xoffset
> and vinfo.yoffset to 0 earlier in my program to try to eliminate them as
> variables.
>
> Other factors that may be at play:
>
> -I am trying to run this from an alternate TTY.  I have a graphical
> environment on TTY7 with x.org.  I think it is using the DRM interface.
> Maybe there is a conflict.
> -Maybe I am missing a driver in my Gentoo kernel config?  I'm still
> learning about it, but going into my workstation's kernel config, I
> noticed that CONFIG_FB_NVIDIA was set to "n".
>
> Do you know when CONFIG_DRM_FBDEV_OVERALLOC went into the kernel?  I was
> about to try this on my MacBook Pro running Gentoo, but I will have to
> recompile upgrade the kernel before I can give a report (It is currently
> running: 4.9).  I couldn't find it in menuconfig so I doubt the cmdline
> would make a difference.
>
> I really appreciate the help.  I've been looking header files and a such
> trying to cobble together some information to figure this out.  I hate
> to bother you with this because it seems slightly off topic.
>
> On 7/5/20 3:45 PM, Ilia Mirkin wrote:
> > Try booting with drm_kms_helper.drm_fbdev_overalloc=200 and see if it
> > works with that. (There's also CONFIG_DRM_FBDEV_OVERALLOC which sets
> > the default.)
> >
> > Cheers,
> >
> >-ilia
> >
> > On Sun, Jul 5, 2020 at 3:41 PM  wrote:
> >> I am not familiar with that setting, but I have really struggled to find 
> >> documentation on dealing with the framebuffer.  Referring to this guide, 
> >> "http://betteros.org/tut/graphics1.php#doublebuffer;, I attempted to set 
> >> the mmap allocation size to double, but it caused the mmap to fail.  I no 
> >> longer believe that it is a driver issue, though, because I just tried it 
> >> again on a dell laptop with Intel HD Graphics 4400 to the same failure.
> >>
> >> On Jul 5, 2020 12:35, Ilia Mirkin  wrote:
> >>
> >> Are you setting the overallocation to 200?
> >>
> >> On Sun, Jul 5, 2020 at 3:41 AM Michael T. Kloos
> >>  wrote:
> >>> Does NOUVEAU support mmaping a double-sized Framebuffer?
> >>> When attempting to run, where fd refers to "/dev/fb0":
> >>>
> >>> mmap(ptr, screensize * 2, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
> >>>
> >>> I get back an invalid argument error.  This doesn't happen if I only
> >>> request a single screensize.  Is this a limitation of the driver?
> >>>
> >>> ___
> >>> Nouveau mailing list
> >>> Nouveau@lists.freedesktop.org
> >>> https://lists.freedesktop.org/mailman/listinfo/nouveau
> >>
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Framebuffer double buffering (via FBIOPAN_DISPLAY)

[Ilia Mirkin]

Try booting with drm_kms_helper.drm_fbdev_overalloc=200 and see if it
works with that. (There's also CONFIG_DRM_FBDEV_OVERALLOC which sets
the default.)

Cheers,

  -ilia

On Sun, Jul 5, 2020 at 3:41 PM  wrote:
>
> I am not familiar with that setting, but I have really struggled to find 
> documentation on dealing with the framebuffer.  Referring to this guide, 
> "http://betteros.org/tut/graphics1.php#doublebuffer;, I attempted to set the 
> mmap allocation size to double, but it caused the mmap to fail.  I no longer 
> believe that it is a driver issue, though, because I just tried it again on a 
> dell laptop with Intel HD Graphics 4400 to the same failure.
>
> On Jul 5, 2020 12:35, Ilia Mirkin  wrote:
>
> Are you setting the overallocation to 200?
>
> On Sun, Jul 5, 2020 at 3:41 AM Michael T. Kloos
>  wrote:
> >
> > Does NOUVEAU support mmaping a double-sized Framebuffer?
> > When attempting to run, where fd refers to "/dev/fb0":
> >
> > mmap(ptr, screensize * 2, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
> >
> > I get back an invalid argument error.  This doesn't happen if I only
> > request a single screensize.  Is this a limitation of the driver?
> >
> > ___
> > Nouveau mailing list
> > Nouveau@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/nouveau
>
>
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Framebuffer double buffering (via FBIOPAN_DISPLAY)

[Ilia Mirkin]

Are you setting the overallocation to 200?

On Sun, Jul 5, 2020 at 3:41 AM Michael T. Kloos
 wrote:
>
> Does NOUVEAU support mmaping a double-sized Framebuffer?
> When attempting to run, where fd refers to "/dev/fb0":
>
> mmap(ptr, screensize * 2, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
>
> I get back an invalid argument error.  This doesn't happen if I only
> request a single screensize.  Is this a limitation of the driver?
>
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Remove debug info from nouveau driver

[Ilia Mirkin]

You probably have drm.debug set to something.

On Tue, Jun 23, 2020 at 4:42 AM Mathieu Malaterre  wrote:
>
> Hi there,
>
> I am gettings tons of messages in dmesg output such as:
>
> [...]
> [ 2419.238990] [drm:drm_mode_addfb2 [drm]] [FB:65]
> [ 2419.243388] 00a0 2 base507c_ntfy_set
> [ 2419.243391] 0060
> [ 2419.243391] f000
> [ 2419.243393] 0084 1 base827c_image_set
> [ 2419.243394] 0010
> [ 2419.243395] 00c0 1 base827c_image_set
> [ 2419.243395] fb7a
> [ 2419.243396] 0110 2 base827c_image_set
> [ 2419.243397] 
> [ 2419.243398] 
> [ 2419.243399] 0800 5 base827c_image_set
> [ 2419.243399] 0007ce00
> [ 2419.243400] 
> [ 2419.243400] 04380780
> [ 2419.243401] 7804
> [ 2419.243402] cf00
> [ 2419.243408] 0080 1 base507c_update
> [ 2419.243409] 
> [...]
>
> Does anyone know how to remove those extra debug info from nouveau driver ?
>
> For reference:
>
> # cat /sys/module/nouveau/parameters/debug
> (null)
>
> Thanks much
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau