Re: ssh sessions with pseudo terminal hang when in kernel events thread hangs
On Mon, Mar 19, 2012 at 02:04:34PM +0100, Sven Hoexter wrote: Hi, since about December we see machines where interactive ssh sessions hang or logins are no longer possible. The machine itself is still alive and using ssh without pseudo terminal allocation works fine (ssh -T). To follow this up (I only received one private reply so far), I've filled bug #670398 with more information. Short summary: I currently think it's an issue with Intel Nehalem CPUs. So far we've evidence for the following CPUs (all Lynnfield as far as I know): - X3430 - X3450 - L3426 In case someone experiences those issue on CPUs beyond the 3400 series I'd be interested to know about that. HTH Sven -- And I don't know much, but I do know this: With a golden heart comes a rebel fist. [ Streetlight Manifesto - Here's To Life ] -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120425180703.GA4133@marvin
ssh sessions with pseudo terminal hang when in kernel events thread hangs
Hi, since about December we see machines where interactive ssh sessions hang or logins are no longer possible. The machine itself is still alive and using ssh without pseudo terminal allocation works fine (ssh -T). What we have so far is that this happens on systems with Linux 2.6.32. (Mostly Debian but we've seen this on one RHEL 6.1 system aswell but there the patch level was too far off to open a support case.) Sometimes ssh logins work for a short time, e.g. you see motd and get no prompt or you can execute a few commands and suddenly it hangs. Pseudo terminals are allocated just fine and device nodes can bee seen in /dev/pts/. When it happens we can see one of the in kernel [events/$x] processes to be in state D and the number of context switches and interrupts goes up by factor 6. Most of those interrupts seem to be generated by hpet on the CPU where the events/$x process is running ($x = number of the CPU/CPU core of this system). Has someone seen a similar behaviour? We currently have no idea how and why it happens. It's all Dell Hardware we're running on (R210, 410, 710). Regards, Sven -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120319130434.gb2...@sho.bk.hosteurope.de
