[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b6a2187b0902060335h646e8d86pf00773035f577665@mail.gmail.com>
Date: Fri, 6 Feb 2009 19:35:50 +0800
From: Jeff Chua <jeff.chua.linux@...il.com>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: David Miller <davem@...emloft.net>,
"Rafael J. Wysocki" <rjw@...k.pl>,
Linus Torvalds <torvalds@...ux-foundation.org>,
lkml <linux-kernel@...r.kernel.org>, netdev@...r.kernel.org
Subject: Re: commit 64ff3b938ec6782e6585a83d5459b98b0c3f6eb8 breaks rlogin
On Fri, Feb 6, 2009 at 1:45 PM, Herbert Xu <herbert@...dor.apana.org.au> wrote:
> On Fri, Feb 06, 2009 at 01:39:19PM +0800, Jeff Chua wrote:
>>
>> Attached are two strace. t1.good is a good rlogin run. t4.bad is bad
>> rlogin run where nothing is displayed but typing "~-." gets back to
>> the host.
>
> You traced the side receiving the urgent pointer. This has
> nothing to do with the patch since it only changes sending
> behaviour.
The problem is the "remote" side that's frozen. The "local" side can
be on any kernel version and it won't have any effect. The runs that I
did was for one good run with "strace -o t1.good rlogin ju" that has
the bad kernel and a second one with "strace -o t4.bad rlogin ju" that
just hang.
> Did you change the kernel on the other side during these tests?
No. Was hoping that the traces would show where it hang for the good
and bad trace.
> If reverting the patch on the other side does fix the problem
> for you, please do the two straces there.
Sorry, forgot to send the good trace run for the patched remote side.
Here's attached. t5.good.
Thanks,
Jeff.
Download attachment "t5.good" of type "application/octet-stream" (14894 bytes)
Powered by blists - more mailing lists