Re: [Mesa-dev] threads and X.org/AIGLX drivers
On Wed, May 11, 2011 at 2:53 AM, Dave Airlie airl...@gmail.com wrote: Hey, So we got a bug reported against F15 where we were getting an illegal input event type 0, after passing it around the RH X team I eventually came to look at it. The problem appears to be that we are using llvmpipe as our swrast renderer and on systems that fallback to that we end up with threads inside the X server, that we didn't spawn. It appears SIGIO gets delivered to one of these threads while the main thread keeps on trucking and fail ensues. So I'm crossposting this as there are two fixes we can do that aren't exclusive but could act as belt and braces on Linux at least (other OSes get the belt only). Fix 1: use F_SETOWN_EX, thank to DrNick and AaronP on irc for digging up this nugget, From Linux 2.6.32 onwards, use F_SETOWN_EX to target SIGIO and SIGURG signals at a particular thread.. So on Linux we would use that instead of F_SETOWN to make sure SIGIO only goes to the main X process/thread. Though I'm not sure how to get the defintion for gettid which we need, though I'll look into this a bit more. Fix 2: block all signals in the gallium thread spawning code, this involves using pthread_sigmask around the pthread_create function. Calling it once with a full set of signals to block, and get a copy of the current signals, then calling it again to put back the current signals. I think this might be a good plan for some other things, as I can't see a good reason for a DRI driver to ever get SIGIO, esp as it may interfere with the parent app. I've built a test package with 2 in it for Fedora and am awaiting feedback from the tester, but just though I'd raise the subject here for some discussion/feedback. A different solution could be to use the input thread idea and stop taking SIGIO. Kristian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] threads and X.org/AIGLX drivers
On Thu, May 12, 2011 at 09:45:14AM -0400, Kristian Høgsberg wrote: A different solution could be to use the input thread idea and stop taking SIGIO. The input thread needs a lot of work though - we don't do any locking at all. So try doing device creation/destruction in a loop, or changing the device hierachy, or, or, or, while generating input events at the same time. It won't end well. Cheers, Daniel ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] threads and X.org/AIGLX drivers
Hey, So we got a bug reported against F15 where we were getting an illegal input event type 0, after passing it around the RH X team I eventually came to look at it. The problem appears to be that we are using llvmpipe as our swrast renderer and on systems that fallback to that we end up with threads inside the X server, that we didn't spawn. It appears SIGIO gets delivered to one of these threads while the main thread keeps on trucking and fail ensues. So I'm crossposting this as there are two fixes we can do that aren't exclusive but could act as belt and braces on Linux at least (other OSes get the belt only). Fix 1: use F_SETOWN_EX, thank to DrNick and AaronP on irc for digging up this nugget, From Linux 2.6.32 onwards, use F_SETOWN_EX to target SIGIO and SIGURG signals at a particular thread.. So on Linux we would use that instead of F_SETOWN to make sure SIGIO only goes to the main X process/thread. Though I'm not sure how to get the defintion for gettid which we need, though I'll look into this a bit more. Fix 2: block all signals in the gallium thread spawning code, this involves using pthread_sigmask around the pthread_create function. Calling it once with a full set of signals to block, and get a copy of the current signals, then calling it again to put back the current signals. I think this might be a good plan for some other things, as I can't see a good reason for a DRI driver to ever get SIGIO, esp as it may interfere with the parent app. I've built a test package with 2 in it for Fedora and am awaiting feedback from the tester, but just though I'd raise the subject here for some discussion/feedback. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] threads and X.org/AIGLX drivers
On 05/10/11 11:53 PM, Dave Airlie wrote: The problem appears to be that we are using llvmpipe as our swrast renderer and on systems that fallback to that we end up with threads inside the X server, that we didn't spawn. It appears SIGIO gets delivered to one of these threads while the main thread keeps on trucking and fail ensues. I wasn't around when you were asking on IRC last night, but we do have a driver that uses threads (required by the API to get ACPI events from our kernel unfortunately) and it had similar problems, including crashes in places like ATIMach64SetCursorPosition when that thread that caught SIGIO for a mouse event, processed down to the point that it tried to do an outb, but didn't have IOPL privilege, since that's set per-thread on Solaris. The fix it used was xf86BlockSIGIO() before starting the thread, and then unblocking only in the main thread afterwards: http://src.opensolaris.org/source/xref/x-cons/xnv-clone/open-src/driver/xf86-input-hotkey/sun-src/hotkey.c#224 -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
