Re: [PATCH v5 9/9] drm: ci: Update xfails

[Daniel Stone]

Hi Vignesh,

On Thu, 19 Oct 2023 at 09:07, Vignesh Raman  wrote:
> +# Some tests crashes with malloc error and IGT tests floods
> +# the CI log with error messages and we end up with a warning message
> +# Job's log exceeded limit of 4194304 bytes.
> +# Job execution will continue but no more output will be collected.

This is just from GitLab warning that we have a huge log, so not
related to the actual fails here.

> +# Below is the error log:
> +# malloc(): corrupted top size
> +# Received signal SIGABRT.
> +# Stack trace:
> +#  #0 [fatal_sig_handler+0x17b]
> +#  #1 [__sigaction+0x40]
> +#  #2 [pthread_key_delete+0x14c]
> +#  #3 [gsignal+0x12]
> +#  #4 [abort+0xd3]
> +#  #5 [__fsetlocking+0x290]
> +#  #6 [timer_settime+0x37a]
> +#  #7 [__default_morecore+0x1f1b]
> +#  #8 [__libc_calloc+0x161]
> +#  #9 [drmModeGetPlaneResources+0x44]
> +#  #10 [igt_display_require+0x194]
> +#  #11 [__igt_uniquereal_main1356+0x93c]
> +#  #12 [main+0x3f]
> +#  #13 [__libc_init_first+0x8a]
> +#  #14 [__libc_start_main+0x85]
> +#  #15 [_start+0x21]
> +# malloc(): corrupted top size

By the time we get this error, it indicates that there was previously
memory corruption, but it is only being noticed at a later point. The
skip lists here are way too big - stuff like drm_read is common
testing not affected by virtio at all - so we really need to isolate
the test which is actually breaking things.

The way to do this would be to use valgrind to detect where the memory
corruption is. VirtIO can be run locally so this is something you can
do on your machine.

Cheers,
Daniel
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH] drm/virtio: set fb_modifiers_not_supported

[Daniel Stone]

On Wed, 31 Aug 2022 at 20:06, Chia-I Wu  wrote:

> Without this, the drm core advertises LINEAR modifier which is
> incorrect.
>
> Also userspace virgl does not support modifiers.  For example, it causes
> chrome on ozone/drm to fail with "Failed to create scanout buffer".
>
> Fixes: 2af104290da5 ("drm: introduce fb_modifiers_not_supported flag in
> mode_config")
> Suggested-by: Shao-Chuan Lee 
> Signed-off-by: Chia-I Wu 


 Reviewed-by: Daniel Stone 
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH] drm/cirrus: rewrite and modernize driver.

[Daniel Stone]

On Wed, 3 Apr 2019 at 16:12, Adam Jackson  wrote:
> On Wed, 2019-04-03 at 09:23 +0200, Gerd Hoffmann wrote:
> >  - Only DRM_FORMAT_RGB565 (depth 16) is supported.  The old driver does
> >that too by default.  There was a module parameter which enables 24/32
> >bpp support and disables higher resolutions (due to cirrus hardware
> >constrains).  That parameter wasn't reimplemented.
>
> One slightly annoying aspect of this (well, initially of the patch to
> clamp the default to 16bpp, but this too) is that we only have a way to
> ask the driver which format it prefers, not which ones it supports at
> all. For X's modesetting driver (and yes some of this is because X is
> awful) this creates the following failure mode:
>
> 1: user sets up xorg.conf for depth 24
> 2: user upgrades kernel, reboots
> 3: X driver detects that depth 16 is preferred, but
> 4: X core respects user's xorg.conf and tries depth 24, which
> 5: throws -EINVAL and X won't start.
>
> Possibly X should work around this by transparently setting up a shadow
> framebuffer at the user's requested depth. The problem there is, if 565
> is preferred but  works, you're adding a format-conversion blit in
> the middle for no reason. If I could ask the kernel for the entire list
> of supported formats, I could only set up the shadow if it was
> necessary.

There's already a list of supported formats for each DRM plane, which
you can get via drmModeGetPlane (being careful to enable universal
planes so you can discover the primary plane). The same information is
present in the 'IN_FORMATS' property, which is more difficult to parse
but also tells you about modifiers.

modesetting already pulls all this out (at least in the atomic path)
so we can reason about acceptable modifiers.

Cheers,
Daniel
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH 2/2] drm/virtio: send vblank event on plane atomic update

[Daniel Stone]

Hi,

On 21 March 2016 at 19:23, Gustavo Padovan  wrote:
> @@ -96,6 +98,11 @@ static void virtio_gpu_plane_atomic_update(struct 
> drm_plane *plane,
>   plane->state->crtc_y,
>   plane->state->crtc_w,
>   plane->state->crtc_h);
> +
> +   spin_lock_irqsave(>dev->event_lock, flags);
> +   if (crtc->state->event)
> +   drm_crtc_send_vblank_event(crtc, crtc->state->event);
> +   spin_unlock_irqrestore(>dev->event_lock, flags);

This seems like the wrong place to do it, in that it will generate one
flip event per plane, rather than one per CRTC. So this should
probably be done in the overall atomic_commit hook I think.

Also, without some kind of delay, this means that we'll generate
flip-complete events immediately, which will cause compositors like
Weston to render infinitely fast. It's probably worth looking at what
happened when this came up with Bochs - I'm not sure if we fake a 16ms
delay, or refuse to do async modesets, or what.

Cheers,
Daniel
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH] Add virtio gpu driver.

[Daniel Stone]

Hi,

On 24 March 2015 at 16:07, Gerd Hoffmann kra...@redhat.com wrote:
 +static int virtio_gpu_crtc_page_flip(struct drm_crtc *crtc,
 +struct drm_framebuffer *fb,
 +struct drm_pending_vblank_event *event,
 +uint32_t flags)
 +{
 +   return -EINVAL;
 +}

I'm not going to lie, I was really hoping the 5th (?) GPU option for
Qemu would support pageflipping. Daniel's comment about conversion to
atomic is relevant, but: do you have a mechanism which allows you to
post updates (e.g. 'start displaying this buffer now please') that
allows you to get events back when they have actually been displayed?

Cheers,
Daniel
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH] Add virtio gpu driver.

[Daniel Stone]

Hi,

On Wednesday, March 25, 2015, Dave Airlie airl...@gmail.com wrote:

 On 25 March 2015 at 08:50, Daniel Stone dan...@fooishbar.org
 javascript:; wrote:
  I'm not going to lie, I was really hoping the 5th (?) GPU option for
  Qemu would support pageflipping. Daniel's comment about conversion to
  atomic is relevant, but: do you have a mechanism which allows you to
  post updates (e.g. 'start displaying this buffer now please') that
  allows you to get events back when they have actually been displayed?

 Page flip is implemented in a later patch,


 https://www.kraxel.org/cgit/linux/commit/?h=virtio-gpuid=1e167e8e964f8e08100d315dd354cc0a4b090841

 Since its a long way from an actual display, finding out when
 something is actually displayed is hard,
 but when we've posted it to the frontbuffer should be fine.


Oh nice. 100% exact timings aren't critical; it's more just having
something to gate to 60fps that we can actually drive Weston's repaint loop
off, as that's (not unreasonably) driven by pageflip events.

Cheers,
Daniel
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization