| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Mon, 22 Mar 2010 09:11:06 +0100 From: Karl Vogel <karl.vogel@...il.com> To: Eric Anholt <eric@...olt.net> Cc: linux-kernel@...r.kernel.org Subject: Re: i915 lockup / extreme delay On Mon, Mar 22, 2010 at 5:20 AM, Eric Anholt <eric@...olt.net> wrote: > On Sat, 20 Mar 2010 14:41:41 +0100, Karl Vogel <karl.vogel@...il.com> wrote: >> The 'effect' is that only the mouse pointer works in the X server. The >> cpu usage on the laptop during the sluggishness is minimal. When I >> suspend the game with winedbg, the X server slowly becomes responsive again. >> >> The output from latencytop seems to point to i915 being the culprit: > > If there's some code doing glFlush()es, it's probably that code at > fault. You don't need to do that unless you're doing frontbuffer > rendering, and if you're doing frontbuffer rendering you should really > be doing backbuffer rendering. I don't see a kernel issue here. That doesnt explain why the box completely locks up on 2.6.34-rc2 though, where only a cold reboot works. It also seems a bit odd that 1 opengl application is able to entirely lockup user interaction of the X server, then again that might be more of an X issue than a kernel one.. or is it expected behaviour? (the only thing you can do is wiggle the pointer, nothing else.. no window selection, no window dragging, not even start new apps that open windows) -- 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