On Mon, 30 May 2005, Pekka Enberg wrote:
>
> On Sun, 2005-05-29 at 15:59 -0700, Linus Torvalds wrote:
> > However, I don't understand how wine can block the X server from doing
> > even cursor updates. It might be a scheduler bug, of course. The one thing
> > a bigger pipe buffer does is end up changing scheduling behaviour.
> >
> > (On the other hand, I would not be surprised if Wine does something that
> > makes X pause, like use DGA or whatever and tells X not to update the
> > screen, including cursors).
>
> It is not just X. Running the following shell script when hitting the
> bug:
Ok, this implies that the scheduler is really screwed up, we're not
scheduling anything else during that time.
Ingo, this sounds like you need to take a look.
Pekka, can you confirm that the SysRQ output in your original email was
from a "hung" time? Because that clearly shows that stuff is happening in
user space, which means that it's definitely not a kernel loop.
Also, pipes are a bit special from a scheduling standpoint because they
use the magic "synchronous wakeup" thing, and it might be worthwhile
trying to just change the two calls to "wake_up_interruptible_sync()" in
fs/pipe.c to the non-sync version (ie just remove the "_sync" part).
> It looks like no other processes other than wineserver and
> wine-preloader get any CPU time (also evident from Sysrq-P traces).
Indeed.
One more thing: are those processes given RT priority? Because if so, it
likely boils down to a wine bug again - a busy-looping high-priority
process is _supposed_ to do what you see.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
