ppy to provide more information and test patches.
--
Regards,
Pavel Roskin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Ben, David,
I would hate if Linux 4.14 is released without this fix, as it would
be a regression for my machine. As I mentioned, Linux 4.13 registers
nouveaufb even without the dock, but Linux 4.14 doesn't. And that
would cause an oops even if CONFIG_DRM_FBDEV_EMULATION is enabled.
Please let me
4-rc2 when
CONFIG_DRM_FBDEV_EMULATION option is disabled. It happens during gdm
login.
Linux 4.14-rc2 is affected even if CONFIG_DRM_FBDEV_EMULATION is enabled,
but no monitors are connected to the dock on a laptop with a discrete
NVIDIA card.
Signed-off-by: Pavel Roskin
---
drivers/gpu/d
Hi Daniel,
I meant Linux 4.13 of course, sorry! Can you fix the description for
me please? If not, I can resend the patch with the updated
description.
Let me add some context to my patch. My laptop is Dell Precision 7510
with dual graphics (Intel and Nvidia). The dock is connected to two
monitor
3.13 when
CONFIG_DRM_FBDEV_EMULATION option is disabled.
Signed-off-by: Pavel Roskin
---
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index f7707849bb53..698b8b10b
On Tue, 22 Oct 2013 10:38:03 +0100
Chris Wilson wrote:
> Prevent the user from passing in an ioctl command with up to 16,383
> bytes specified for the struct to be allocated and copied, and
> instead only allocate enough space to satisfy the kernel.
>
> Suggested-by: Pavel Roski
On Thu, 17 Oct 2013 13:26:47 +0100
Chris Wilson wrote:
> On Wed, Oct 16, 2013 at 08:12:35PM -0400, Pavel Roskin wrote:
> > The amount of data wanted by the userspace caller is encoded in the
> > ioctl number. Generic drm ioctls were ignoring it.
> >
> > As a resul
ff-by: Pavel Roskin
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/drm_drv.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index e572dd2..8a1c721 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_
abi
> incompatibility for 32-bit userspaces. To be strict we should do an
> ioc32 wrapper in the kernel.
I see. After all, the kernel fails to write the encoders at the
requested address, so perhaps it could be improved as well.
Thank you for the fix!
--
Regards,
Pavel Roskin
all restore any data on stack on return?
I have an impression that your patch complicates things too much
without addressing the actual problem.
--
Regards,
Pavel Roskin
-- next part --
A non-text attachment was scrubbed...
Name: 01-protect-array.patch
Type: text/x-patch
Size:
->kmode->connectors[num];
conn.count_props = 0;
--
Regards,
Pavel Roskin
On Tue, 15 Oct 2013 16:23:50 +0100
Chris Wilson wrote:
> to try and grab more information about the failure here.
Attached.
The only interesting difference is
+sna_output_init(num=0)
+sna_output_init: GETENCODER failed, ret=22
--
Regards,
Pavel Roskin
-- next p
On Sun, 13 Oct 2013 15:00:04 +0100
Chris Wilson wrote:
> On Sun, Oct 13, 2013 at 12:40:10AM -0400, Pavel Roskin wrote:
> > I won't see that system until Tuesday. I'll give you the
> > information you ask, I'm just trying to understand the debugging
> > data I
er IDs are
copied last and if the encoder ID is zero, it's not copied. So I
don't see how the kernel could overwrite that value. However, gcc
could reorder something, but I doubt it would reorder put_user()
calls. Anyway, I'll try to add buffers around enc in
sna_output_init() to protect against memory corruption.
--
Regards,
Pavel Roskin
ill have
* appropriately converted them already.
*/
I cannot find that conversion code. Maybe it's in
arch/x86/ia32/ia32entry.S, but we want architecture independent code
in drivers/gpu/drm.
Or maybe the API for DRM_IOCTL_MODE_GETCONNECTOR is fundamentally wr
ucher
:04 04 f641a4e6cb7ac7426a8a80f3a4cf51a6320f95d4
e974cd1737fafb82c6dc8f85dbcdf6cacfea893a M drivers
Thank you!!!
--
Regards,
Pavel Roskin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
y: Alex Deucher
:04 04 f641a4e6cb7ac7426a8a80f3a4cf51a6320f95d4
e974cd1737fafb82c6dc8f85dbcdf6cacfea893a M drivers
Thank you!!!
--
Regards,
Pavel Roskin
g when running unshield on some
proprietary Windows drivers in xterm on Fedora 17 x86_64 with Radeon
RV610.
--
Regards,
Pavel Roskin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
g when running unshield on some
proprietary Windows drivers in xterm on Fedora 17 x86_64 with Radeon
RV610.
--
Regards,
Pavel Roskin
ch. If
it doesn't help, I'll repeat the bisection.
--
Regards,
Pavel Roskin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
sday. I'll try that patch. If
it doesn't help, I'll repeat the bisection.
--
Regards,
Pavel Roskin
The kernel .config file is attached.
--
Regards,
Pavel Roskin
-- next part --
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 3.7.0 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="el
22 matches
Mail list logo
