Michel is correct your patch will probably break resume in some cases. Please enable lockdep debugging during your kernel compile and take a look what is deadlocking here and why instead of trying to band aid over the real problem. Regards, Christian. Am 13.08.2016 um 08:56 schrieb Qu, Jim: > Hi Michel: > > 1. add console_unlock() in fail case > ------issue also can be observed. > 2. with console_trylock() > ------switch VT is no problem. > ------log into console and interact with shell are no problem. > > > Thanks > JimQu > > ________________________________________ > å??件人: Michel Dänzer <michel at daenzer.net> > å??é??æ?¶é?´: 2016å¹´8æ??10æ?¥ 14:54:48 > æ?¶ä»¶äºº: Qu, Jim > æ??é??: amd-gfx at lists.freedesktop.org > 主é¢?: Re: ç?å¤?: [PATCH] drm/amd/amdgpu: S3 resume fail > > On 10/08/16 01:39 PM, Qu, Jim wrote: >> HI Michel: >> >> 1. So far, I not sure which one causes the console_lock() fail, maybe I >> need enable kernel mutex debug feature to trace it. > Or, maybe you can just try fixing the cases in amdgpu_resume_kms where > console_unlock() isn't called, and see if that fixes the problem? > > >> 2. Phenomenally, it can be restore to desktop normally. Do you know >> any methods to check it whether driver without calling >> amdgpu_fbdev_set_suspend(adev, 0) has side effect or not? > Does VT switching to console with Ctrl-Alt-Fx work? Does logging into > the console and interacting with the shell work? > > > -- > Earthling Michel Dänzer | http://www.amd.com > Libre software enthusiast | Mesa and X developer > _______________________________________________ > amd-gfx mailing list > amd-gfx at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx