From owner-freebsd-arm@FreeBSD.ORG Thu Aug 8 15:43:31 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F08EB547 for ; Thu, 8 Aug 2013 15:43:31 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B238A2D5A for ; Thu, 8 Aug 2013 15:43:31 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1V7SN3-0001Sb-Er; Thu, 08 Aug 2013 15:43:25 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r78FhNq5030263; Thu, 8 Aug 2013 09:43:23 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19zaot4BvmKlAdUeeG9gf2q Subject: Re: System freezes when using scp From: Ian Lepore To: Krister Olofsson In-Reply-To: References: <1375967077.3320.117.camel@revolution.hippie.lan> Content-Type: multipart/mixed; boundary="=-u1wXiY5m6cUtRLv8QKcN" Date: Thu, 08 Aug 2013 09:43:23 -0600 Message-ID: <1375976603.3320.147.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 15:43:32 -0000 --=-u1wXiY5m6cUtRLv8QKcN Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Try the attached patch -- I need it to run 8.2 on a Kirkwood chip, maybe the same thing is needed on Discovery chips. One of the things it fixes for me is data corruption on big network and sata transfers, so maybe it's related to the problem you're seeing. -- Ian On Thu, 2013-08-08 at 16:42 +0200, Krister Olofsson wrote: > Hi, > > I don't notice any pause if I ssh to it. (The pause using scp is ca 3 > seconds) > I've tested netcast and there is no problem if I send the output to > /dev/null > but the system reboots if I send it to a file. > I've also tested to copy the file using nfs and there is no problem with > that. > > Running 'cat file' (file size ca 50 Mb) sometimes causes the problem after > ca 10 s, but not always. > If I do ssh to a third machine and run 'cat file' the problem always occurs > at once > > Regards, > Krister > > > 2013/8/8 Ian Lepore > > > On Thu, 2013-08-08 at 13:44 +0200, Krister Olofsson wrote: > > > Hi, > > > > > > I'm working with a board with FreeBSD 8.2 on Marvell MV78100 (Discovery > > > SOC) - an ARMv5TE and Marvell Gigabit Ethernet controller. > > > My problem is that when I copy files (size ca 50 Mb) with scp using > > > ethernet, the system > > > seems to freeze for a few seconds before the copy process starts. > > > The board has an external watchdog that has to be kicked but the script > > > doing this freezes and the system is rebooted by the watchdog. > > > > > > Any ideas how to tackle this? > > > > > > Regards, > > > Krister > > > > > > Configuration: > > > > > > # > > > # Custom kernel for PROJ, based on Marvell's DB-78xx > > > # > > > [...] > > > > Do you get the same kind of pause interactively ssh'ing to it? When you > > say "a few seconds" what do you mean? 3 seconds? 8? 30? > > > > I think a good first step is to figure out whether the problem is > > related to ssh, or network IO, or disk IO. You can take ssh out of the > > picture by using netcat to test, something like: > > > > On the arm: nc -l 8000 >/output/file > > On the sender: nc 8000 > > > If you send the output to /dev/null on the arm you're just testing the > > network part. > > > > In my experience, a long pause at the start of an ssh session followed > > by normal performance after that is what you get when a wimpy arm chip > > with software floating point generates the session keys. But that's > > based on experience with a 180mhz armv4 chip. I've never noticed that > > sort of slowness on my DreamPlug (1.2ghz Marvell Kirkwood chips). > > > > -- Ian > > > > > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" --=-u1wXiY5m6cUtRLv8QKcN Content-Disposition: inline; filename="dp_cache_wralloc.diff" Content-Type: text/x-patch; name="dp_cache_wralloc.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit Do not enable allocating a cache line on write access. Instead, leave that feature in whatever state the bootloader set it to, on the theory that the firmware that comes with the unit knows best. This fixes intermittant cache line corruptions during bulk network data flow. diff -r df572d6d53cd -r a142512ee876 sys/arm/arm/cpufunc.c --- sys/arm/arm/cpufunc.c Thu Nov 22 16:46:06 2012 -0700 +++ sys/arm/arm/cpufunc.c Sat Dec 01 15:38:59 2012 -0700 @@ -1067,13 +1067,13 @@ set_cpufuncs() */ if (cputype == CPU_ID_MV88FR571_VD || cputype == CPU_ID_MV88FR571_41) { - sheeva_control_ext(0xffffffff, - FC_DCACHE_STREAM_EN | FC_WR_ALLOC_EN | + sheeva_control_ext(0xffffffff & ~FC_WR_ALLOC_EN, + FC_DCACHE_STREAM_EN | FC_BRANCH_TARG_BUF_DIS | FC_L2CACHE_EN | FC_L2_PREF_DIS); } else { - sheeva_control_ext(0xffffffff, - FC_DCACHE_STREAM_EN | FC_WR_ALLOC_EN | + sheeva_control_ext(0xffffffff & ~FC_WR_ALLOC_EN, + FC_DCACHE_STREAM_EN | FC_BRANCH_TARG_BUF_DIS | FC_L2CACHE_EN); } --=-u1wXiY5m6cUtRLv8QKcN--