linux-kernel - Re: [BUG] 4.14 regression: Xorg hangs on exit

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f1ac0ac6-04ad-0311-70d0-6c907a7fee2e@I-love.SAKURA.ne.jp>
Date:   Wed, 22 Nov 2017 22:23:25 +0900
From:   Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To:     Bob Tracy <rct@...rkin.frus.com>, linux-kernel@...r.kernel.org
Subject: Re: [BUG] 4.14 regression: Xorg hangs on exit

On 2017/11/22 13:11, Bob Tracy wrote:
> On Tue, Nov 21, 2017 at 11:12:35AM -0600, Bob Tracy wrote:
>> Apologies for the lack of detail, but the subject pretty much says it
>> all.  Xorg works fine with 4.13, but hangs on exit with 4.14.
>>
>> Logging in remotely and applying the "kill -9" sledgehammer has no
>> effect.  System logs don't show anything unusual going on.  Rebooting
>> hangs because of the unkillable process: hitting the reset switch is
>> the only way forward.
>>
>> Video driver is "radeon", reporting "ATOM BIOS: REDWOOD" at boot time.
>> Console is fb0 == radeondrmfb.
> 
> Only an "occasional" bad deal?  Lockup doesn't happen every time.
> I'll make this a "watch" item for the time being.  I'd apologize for the
> noise, but I never saw this happen prior to running the 4.14 kernel.
> Maybe was just lucky up until now :-(.
> 
> Running a 32-bit SMP kernel per "uname -a" output below:
> 
> Linux gherkin 4.14.0 #1 SMP PREEMPT Thu Nov 16 23:34:38 CST 2017 i686 Intel(R) Core(TM) i7-2600S CPU @ 2.80GHz GenuineIntel GNU/Linux
> 
> The i7-2600S has four hyperthreaded cores (/proc/cpuinfo shows 8 CPUs).
> 
> --Bob
> 
When you hit that problem next time, please capture SysRq-t and SysRq-m output
after logging in remotely.

# dmesg -c > dmesg.txt
# echo t > /proc/sysrq-trigger
# echo m > /proc/sysrq-trigger
# dmesg -c >> dmesg.txt
# sleep 60
# echo t > /proc/sysrq-trigger
# echo m > /proc/sysrq-trigger
# dmesg -c >> dmesg.txt

Then, we will likely be able to know where the Xorg process got stuck at.