All of lore.kernel.org
 help / color / mirror / Atom feed
From: "K.R. Foley" <kr@cybsft.com>
To: Serge Noiraud <serge.noiraud@bull.net>
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: RT : Large transfert with 2.6.12rc5	+	realtime-preempt-2.6.12-rc5-V0.7.47-15
Date: Wed, 01 Jun 2005 06:10:54 -0500	[thread overview]
Message-ID: <429D97BE.4060905@cybsft.com> (raw)
In-Reply-To: <1117609093.5580.6.camel@ibiza.btsn.frna.bull.fr>

Serge Noiraud wrote:
> Le mar 31/05/2005 à 18:18, K.R. Foley a écrit :
> 
>>Serge Noiraud wrote:
>>
>>>I had the same problem with rc4+47-07, rc5+47-10,47-13
>>>I reproduce this problem with a tg3 driver and with e1000 driver.
>>>So I think it's not a driver problem.
>>>
>>>I try to copy an iso image from this machine to another one by scp.
>>>after 35 to 45MB, the copy become stalled with no more transfert.
>>>We can ping the target machine, all apparently is OK except the scp
>>>which finish with timeout.
>>>With ftp, the stalled state is about 100MB.
>>>If I reboot with a standard kernel ( without RT ), no problem.
>>>
>>>Perhaps there is a progress, in 47-15, the size is now 135-140MB
>>>
>>>On this machine, we have an ide disk.
>>>I have setup : hdparm 
>>>-sh-2.05b# hdparm /dev/hda
>>>
>>>/dev/hda:
>>> multcount    = 16 (on)
>>> IO_support   =  3 (32-bit w/sync)
>>> unmaskirq    =  1 (on)
>>> using_dma    =  1 (on)
>>> keepsettings =  0 (off)
>>> readonly     =  0 (off)
>>> readahead    = 256 (on)
>>> geometry     = 65535/16/63, sectors = 78165360, start = 0
>>>
>>
>>Hi,
>>
>>I am not sure what might be causing this problem for you. I just tried 
>>to reproduce this on one of my systems but could not (scsi not ide). The 
>>first time it copied 450MB before the remote system ran out of space. 
>>After cleaning up a bit I got the whole 630MB without a hitch. Do you 
>>have the RT patch on both systems or just on the originating system? In 
>>my case its the latter. There is
> 
> 
> The scp or ftp start on a RT machine.
> The destination is an RT or Non RT machine, the problem is the same.
> It's not a space problem, I have 4GB available on the destination path.
> I can reproduce the phenomena at each try.
> If I <CTRL C> the scp when it is stalled then relaunch the scp command, the transfert restart without problem.
> I'm trying to trace this problem but I don't know how to do this.
> Has someone one method ?
> 
> 

Do any of your logs provide any clues? Does this happen with just
2.6.12-rc5 and no rt-preempt patch? Does ifconfig provide any clues? How
about netstat -a? What is the state of the connection?

-- 
   kr

  reply	other threads:[~2005-06-01 11:13 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-31 15:07 RT : Large transfert with 2.6.12rc5 + realtime-preempt-2.6.12-rc5-V0.7.47-15 Serge Noiraud
2005-05-31 16:18 ` K.R. Foley
2005-06-01  6:58   ` Serge Noiraud
2005-06-01 11:10     ` K.R. Foley [this message]
2005-06-07 13:23       ` RT : Large transfert with 2.6.12rc5+realtime-preempt-2.6.12-rc5-V0.7.47-15 Serge Noiraud

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=429D97BE.4060905@cybsft.com \
    --to=kr@cybsft.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=serge.noiraud@bull.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.