Created attachment 76272 [details] picture of the screen oops i dont know how to describe the bug further. nothing fancy was happening on the laptop. linux 3.9-rc1 xorg server 1.14.0 intel driver 2.21.3 mesa 9.1 i will report again if this happens.
The primary bug is in perf. The second oops is due to the WARN hit along an atomic modeset path. Still we should not pollute the paniclog in this case - maybe cancel the warning if in_atomic()?
drm modeset locking on panic/kgdb/sysrq notifier is terminally broken, i.e. imo the warn is fully justified. So I think we should keep this like it is currently instead of just shutting it up, to keep the nagging feeling around.
(In reply to comment #2) > So I think we should keep this like it is currently instead of just shutting > it up, to keep the nagging feeling around. The problem as demonstrated is that the real bug is hidden by the panic in the panic printing code, which kind of makes the ability of KMS to present the paniclog a farce.
commit a9b054e8ab06504c2afa0e307ee78d3778993a1d Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu May 2 09:43:05 2013 +0200 drm: don't check modeset locks in panic handler Since we know that locking is broken in that case and it's more important to not flood the dmesg with random gunk. Cc: Dave Airlie <airlied@gmail.com> Cc: Borislav Petkov <bp@alien8.de> References: http://lkml.kernel.org/r/20130502000206.GH15623@pd.tnic Cc: stable@vger.kernel.org Reported-and-tested-by: Borislav Petkov <bp@suse.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.