[Bugme-new] [Bug 18242] New: kernel should forbid app from using GPU if it causes lockups
bugzilla-daemon at bugzilla.kernel.org
bugzilla-daemon at bugzilla.kernel.org
Sat Sep 11 00:28:55 PDT 2010
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-dri at kernel-bugs.osdl.org
ReportedBy: edwintorok at 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 on the CC list for the bug.
More information about the Bugme-new
mailing list