On Tue, Oct 15, 2013 at 05:45:52PM -0400, Pavel Roskin wrote:
> On Tue, 15 Oct 2013 21:59:08 +0100
> Chris Wilson wrote:
>
> > Yikes, that implies we have a size mismatch with the kernel - ideally
> > we construct the struct to have the same size when compiled with 32
> > or 64 bits.
> >
> > Ple
On Tue, Oct 15, 2013 at 02:00:50PM -0400, Pavel Roskin wrote:
> Hi Chris,
>
> It's almost certainly stack corruption. This "patch" fixes X for me.
> The first DRM_IOCTL_MODE_GETCONNECTOR in sna_output_init() must be
> overwriting the implied memory bounds.
>
> diff --git a/src/sna/sna_display.c
On Wed, 16 Oct 2013 00:39:34 +0100
Chris Wilson wrote:
> > However, I feel uneasy about that patch. I tried to debug the
> > problem, and it looked not as a data corruption, but as something
> > opposite. The kernel writes correct data to the userspace, but the
> > userspace gets the old value.
On Tue, 15 Oct 2013 21:59:08 +0100
Chris Wilson wrote:
> Yikes, that implies we have a size mismatch with the kernel - ideally
> we construct the struct to have the same size when compiled with 32
> or 64 bits.
>
> Please try:
>
> commit a63b4d5a0766a7e98efeff8dd520c58e9a1bea88
> Author: Chris
On Tue, Oct 15, 2013 at 11:12:24AM -0400, Pavel Roskin wrote:
> 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 t
Hi Chris,
It's almost certainly stack corruption. This "patch" fixes X for me.
The first DRM_IOCTL_MODE_GETCONNECTOR in sna_output_init() must be
overwriting the implied memory bounds.
diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c
index 28151ab..dac834f 100644
--- a/src/sna/sna_disp
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 part --
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 have already.
>
> I've just double
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 have already.
I've just double checked that an i386 Xserver runs with an x86-64 kernel
here. I think
Quoting Chris Wilson :
>> I believe the error is on the kernel side. The kernel should
>> convert the pointer. compat_ptr() doesn't convert the value, only
>> the type. The comment in arch/x86/include/asm/compat.h says:
>
> That seems odd as the kernel expects a 32-bit address for the user
> pr
On Fri, Oct 11, 2013 at 10:37:25PM -0400, Pavel Roskin wrote:
> Hello!
>
> I'm running 32-bit Ubuntu 12.04 on the latest x86_64 kernel
> (mainline git). I'm using the latest X from the x-edgers PPA
> (2.99.904+git20131009.b9ad5b62-0ubuntu0sarvatt~precise).
>
> The Intel Xorg driver fails with:
>
Hello!
I'm running 32-bit Ubuntu 12.04 on the latest x86_64 kernel (mainline
git). I'm using the latest X from the x-edgers PPA
(2.99.904+git20131009.b9ad5b62-0ubuntu0sarvatt~precise).
The Intel Xorg driver fails with:
(EE) intel(0): No outputs and no modes.
Xorg works with the i386 kern
12 matches
Mail list logo
