https://bugzilla.kernel.org/show_bug.cgi?id=18242
Summary: kernel should forbid app from using GPU if it causes
lockups
Product: Drivers
Version: 2.5
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: enhancement
Priority: P1
Component: Video(DRI - non Intel)
AssignedTo: drivers_video-...@kernel-bugs.osdl.org
ReportedBy: edwinto...@gmail.com
Regression: No
During the testing of r600g (still in development) it happens that some mesa
demos/games lockup the GPU.
Most of the time the kernel recovers from this nicely, however the app will
lockup the GPU over and over again.
It doesn't even know the correct process, for example it was the gloss demo
(using direct rendering) this time:
[ 3070.276433] GPU lockup (waiting for 0x0003708B last fence id 0x00037088)
...
[ 3070.276467] Pid: 4274, comm: Xorg Not tainted 2.6.36-rc3-phenom #96
It could have been an app using LIBGL_ALWAYS_INDIRECT=1 though, so just killing
the app causing the lockup is not a good idea (could easily lead to getting X
killed).
I think the kernel should forbid the app from sending any more GPU commands
(perhaps by returning failure for every ioctl it does?) once it determines it
locked up. So in this case it'd first forbid Xorg, then see there is another
lockup, then forbid gloss.
It should probably print a message like:
Process '<processname>' (pid <pid>) caused a GPU lockup, forbidding GPU
commands for 'N minutes'. To reenable do 'echo <pid>
>/sys/kernel/..../gpu_reenable'.
Of course it'd be best if the kernel wouldn't accept the GPU commands leading
to a GPU lockup, but that might not be possible to determine in general
(whether certain GPU instructions will cause a lockup or not).
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
