[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <21d7e9971002040040w5910357j1a4b35ec256728b@mail.gmail.com>
Date: Thu, 4 Feb 2010 18:40:55 +1000
From: Dave Airlie <airlied@...il.com>
To: Tejun Heo <tj@...nel.org>
Cc: Andy Isaacson <adi@...apodia.org>, linux-kernel@...r.kernel.org,
dri-devel@...ts.sourceforge.net
Subject: Re: [2.6.33-rc6-git regression] idr fix breaks Xorg
On Thu, Feb 4, 2010 at 6:16 PM, Tejun Heo <tj@...nel.org> wrote:
> Hello,
>
> On 02/04/2010 04:56 PM, Andy Isaacson wrote:
>> 1265267921.568269 ioctl(8, 0xc020645e, 0x7fffe2196980) = -1 EBADF (Bad file descriptor)
>
> Hmm... -EBADF? I suppose it doesn't mean that the fd is invalid in
> this case but that the mapped object can't be found for some reason?
> Can anyone more familiar with the subsystem explain what's going on?
>
>> 1265267921.568649 write(2, "../../../libdrm/intel/intel_bufmgr_gem.c:637: Error mapping buffer 1073741824 (gen4 WM state): Bad file descriptor .\n", 117) = 117
>> 1265267921.569039 --- SIGSEGV (Segmentation fault) @ 0 (0) ---
>
> I'll forward the fore mentioned fix as it at least fixes one reported
> failure.
Hmm at this late stage, maybe revert first? since the old idr code works fine
with the subsystems in question.
The drm idr code usage isn't anything crazy, the EBADF is the return code
from the mmap ioctl when it calls the idr lookup function for a handle.
The lookup function is just an idr_find inside a spinlock.
Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists