Bug 11463 - sshd hangs on close
sshd hangs on close
Status: CLOSED UNREPRODUCIBLE
Product: Process Management
Classification: Unclassified
Component: Preemption
All Linux
: P1 normal
Assigned To: Robert Love
:
Depends on:
Blocks: Regressions-2.6.26
  Show dependency treegraph
 
Reported: 2008-08-30 13:26 UTC by Rafael J. Wysocki
Modified: 2011-01-12 05:08 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.6.27-rc5
Tree: Mainline
Regression: Yes


Attachments

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?

Note You need to log in before you can comment on or make changes to this bug.