similar to: [PATCH] drm/nouveau/nouveau_fbcon.c: fix for disabled fbdev emulation

https://bugs.freedesktop.org/show_bug.cgi?id=96307 Bug ID: 96307 Summary: Kernel 4.7-rc1 oops when starting X Product: xorg Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at

The patch f045f459d925 ("drm/nouveau/fbcon: fix out-of-bounds memory accesses") tries to fix some out of memory accesses. Unfortunatelly, the patch breaks the display when using fonts with width that is not divisiable by 8. The monochrome bitmap for each character is stored in memory by lines from top to bottom. Each line is padded to a full byte. For example, for 22x11 font, each line

On Thu, Jan 09, 2014 at 12:28:50AM -0800, Michael Dalton wrote: > Hi Michael, > > Here's a quick sketch of some code that enforces a minimum buffer > alignment of only 64, and has a maximum theoretical buffer size of > aligned GOOD_PACKET_LEN + (BUF_ALIGN - 1) * BUF_ALIGN, which is at least > 1536 + 63 * 64 = 5568. On x86, we already use a 64 byte alignment, and > this

Hi Michael, Here's a quick sketch of some code that enforces a minimum buffer alignment of only 64, and has a maximum theoretical buffer size of aligned GOOD_PACKET_LEN + (BUF_ALIGN - 1) * BUF_ALIGN, which is at least 1536 + 63 * 64 = 5568. On x86, we already use a 64 byte alignment, and this code supports all current buffer sizes, from 1536 to PAGE_SIZE. #if L1_CACHE_BYTES < 64 #define

Hi Michael, Here's a quick sketch of some code that enforces a minimum buffer alignment of only 64, and has a maximum theoretical buffer size of aligned GOOD_PACKET_LEN + (BUF_ALIGN - 1) * BUF_ALIGN, which is at least 1536 + 63 * 64 = 5568. On x86, we already use a 64 byte alignment, and this code supports all current buffer sizes, from 1536 to PAGE_SIZE. #if L1_CACHE_BYTES < 64 #define

Commit 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers") converted nouveau to generic fbdev emulation. The driver's internal implementation later got accidentally restored during a merge commit. Remove the file from the driver. No functional changes. v2: * point Fixes tag to merge commit (Alex) Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de>

Commit 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers") converted nouveau to generic fbdev emulation. Also remove the internal implementation from the driver. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> Fixes: 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers") Cc: Ben Skeggs <bskeggs at redhat.com> Cc:

On Mon, Jan 9, 2023 at 9:06 AM Thomas Zimmermann <tzimmermann at suse.de> wrote: > > Commit 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers") > converted nouveau to generic fbdev emulation. Also remove the internal > implementation from the driver. No functional changes. Looking at 4a16dd9d18a0, it appears to have removed this file already. I guess it

Hi Am 09.01.23 um 15:15 schrieb Alex Deucher: > On Mon, Jan 9, 2023 at 9:06 AM Thomas Zimmermann <tzimmermann at suse.de> wrote: >> >> Commit 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers") >> converted nouveau to generic fbdev emulation. Also remove the internal >> implementation from the driver. No functional changes. > > Looking

On Tue, Jul 12, 2016 at 06:49:34PM +0200, Peter Wu wrote: > The FBIOPUT_CON2FBMAP ioctl takes a console_lock(). When this is called > while nouveau was runtime suspended, a deadlock would occur due to > nouveau_fbcon_set_suspend also trying to obtain console_lock(). > > Fix this by delaying the drm_fb_helper_set_suspend call. Based on the > i915 code (which was done for

On Tue, Jul 12, 2016 at 06:49:34PM +0200, Peter Wu wrote: > The FBIOPUT_CON2FBMAP ioctl takes a console_lock(). When this is called > while nouveau was runtime suspended, a deadlock would occur due to > nouveau_fbcon_set_suspend also trying to obtain console_lock(). > > Fix this by delaying the drm_fb_helper_set_suspend call. Based on the > i915 code (which was done for

Currently vesafb/efifb/... is kicked when hardware driver is registering framebuffer. To do it hardware must be fully functional, so there's a short window between start of initialisation and framebuffer registration when two drivers touch the hardware. Unfortunately sometimes it breaks nouveau initialisation. Fix it by kicking firmware driver(s) before we start touching the hardware.

Hello Thomas, On 1/10/23 13:35, Thomas Zimmermann wrote: > Commit 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers") > converted nouveau to generic fbdev emulation. The driver's internal > implementation later got accidentally restored during a merge commit. > Remove the file from the driver. No functional changes. > > v2: > * point Fixes tag to

It simplifies nouveau code by removal of detection which region to pass to kick vesafb/efifb. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> Cc: Eric Anholt <eric at anholt.net> Cc: Ben Skeggs <bskeggs at redhat.com> Cc: Thomas Hellstrom <thellstrom at vmware.com> Cc: Dave Airlie <airlied at redhat.com> Cc: Peter Jones <pjones at redhat.com> Cc:

On Tue, Jul 12, 2016 at 06:49:34PM +0200, Peter Wu wrote: > The FBIOPUT_CON2FBMAP ioctl takes a console_lock(). When this is called > while nouveau was runtime suspended, a deadlock would occur due to > nouveau_fbcon_set_suspend also trying to obtain console_lock(). > > Fix this by delaying the drm_fb_helper_set_suspend call. Based on the > i915 code (which was done for

On Wed, Jul 13, 2016 at 06:17:47PM +0100, Chris Wilson wrote: > On Tue, Jul 12, 2016 at 06:49:34PM +0200, Peter Wu wrote: > > The FBIOPUT_CON2FBMAP ioctl takes a console_lock(). When this is called > > while nouveau was runtime suspended, a deadlock would occur due to > > nouveau_fbcon_set_suspend also trying to obtain console_lock(). > > > > Fix this by delaying

The FBIOPUT_CON2FBMAP ioctl takes a console_lock(). When this is called while nouveau was runtime suspended, a deadlock would occur due to nouveau_fbcon_set_suspend also trying to obtain console_lock(). Fix this by delaying the drm_fb_helper_set_suspend call. Based on the i915 code (which was done for performance reasons though). Cc: Chris Wilson <chris at chris-wilson.co.uk> Cc: Daniel

Adam Jackson (1): fbdev 0.4.0 Brice Goglin (1): Replace a non-ascii char with the corresponding groff escape in fbdev.man Ian Romanick (1): Add conditional support for pci-rework branch. Matthias Hopf (1): Fixed leftover PCIACCESS -> XSERVER_LIBPCIACCESS. Michel D?nzer (1): Only determine pitch after setting initial mode. git tag: xf86-video-fbdev-0.4.0

On Mon, Sep 10, 2018 at 02:48:43PM +0200, Bartlomiej Zolnierkiewicz wrote: > > On 08/22/2018 10:54 AM, Daniel Vetter wrote: > > This was only added for the drm's fbdev emulation support, so that it > > would try harder to show the Oops. > > > > Unfortunately this never really worked reliably, and in practice ended > > up pushing the real Oops off the

Am Dienstag, 27. November 2018, 18:34:24 CET schrieb Daniel Vetter: > KMS drivers really should all be able to restore their display state > on resume without fbcon helping out. So make this the default. > > Since I'm not entirely foolish, make it only a default, which drivers > can still override. That way when the inevitable regression report > happens I can fix things up