Bug 11463

Summary:	sshd hangs on close
Product:	Process Management	Reporter:	Rafael J. Wysocki (rjw)
Component:	Preemption	Assignee:	Robert Love (rlove)
Status:	CLOSED UNREPRODUCIBLE
Severity:	normal	CC:	navinkumar+bugs
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	2.6.27-rc5	Subsystem:
Regression:	Yes	Bisected commit-id:
Bug Depends on:
Bug Blocks:	11167

Description Rafael J. Wysocki 2008-08-30 13:26:40 UTC

Subject    : sshd hangs on close
Submitter  : Matthias Urlichs <matthias@urlichs.de>
Date       : 2008-08-30 9:18
References : http://marc.info/?l=linux-kernel&m=122008800512864&w=4

This entry is being used for tracking a regression from 2.6.26.  Please don't
close it until the problem is fixed in the mainline.

Comment 1 Matthias Urlichs 2008-09-14 13:09:52 UTC

Unfortunately, the problem seems to have permanently vanished after the affected machine has been rebooted with a known-good kernel, and has since resisted my attempts at reproducing it.

Comment 2 N K 2011-01-12 05:08:55 UTC

I am able to reproduce this problem on one machine with 2.6.32 (rhel6).  It appears to be due to needing a kernel-thread 'events' to get cpu time on a foreign cpu.  E.g. if sshd is running on cpu0, and cpu1 is shielded with a FIFO-99 process starving the kernel-thread 'events/1' (non-RT), sshd on cpu0 hangs with wchan=flush_cpu with the last strace being closing the filedescriptor of /dev/ptmx.

Question1 - why does cpu0 wait for events/1?
Question2 - why does sshd's close /dev/ptmx trigger this?
Question3 - what exactly is wchan=cpu_flush indicating?