From owner-freebsd-bugs@FreeBSD.ORG Fri Nov 8 08:30:02 2013 Return-Path: Delivered-To: freebsd-bugs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7561FA25 for ; Fri, 8 Nov 2013 08:30:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 53A712880 for ; Fri, 8 Nov 2013 08:30:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rA88U16K002568 for ; Fri, 8 Nov 2013 08:30:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rA88U187002567; Fri, 8 Nov 2013 08:30:01 GMT (envelope-from gnats) Date: Fri, 8 Nov 2013 08:30:01 GMT Message-Id: <201311080830.rA88U187002567@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Ralf Wenk Subject: Re: kern/183753: Regression since r255138: network is slow, kernel: failed to create new mbuf X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Ralf Wenk List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 08:30:02 -0000 The following reply was made to PR kern/183753; it has been noted by GNATS. From: Ralf Wenk To: Oliver Pinter Cc: freebsd-gnats-submit@freebsd.org Subject: Re: kern/183753: Regression since r255138: network is slow, kernel: failed to create new mbuf Date: Fri, 08 Nov 2013 09:23:19 +0100 On 11/7/13, Oliver Pinter wrote: > On 11/7/13, Ralf Wenk wrote: > > > >>Number: 183753 > >>Category: kern > >>Synopsis: Regression since r255138: network is slow, kernel: failed > >> to create new mbuf > >>Confidential: no > >>Severity: non-critical > >>Priority: low > >>Responsible: freebsd-bugs > >>State: open > >>Quarter: > >>Keywords: > >>Date-Required: > >>Class: sw-bug > >>Submitter-Id: current-users > >>Arrival-Date: Thu Nov 07 15:20:00 UTC 2013 > >>Closed-Date: > >>Last-Modified: > >>Originator: Ralf Wenk > >>Release: FreeBSD 10.0-CURRENT arm > >>Organization: > > Hochschule Karlsruhe, University of Applied Sciences > >>Environment: > > FreeBSD raspberry-pi 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r255138: Wed Nov > > 6 08:42:26 CET 2013 > > root@IZ-FreeBSD1:/usr/obj/arm.armv6/root/rpi/255138/sys/RPI-Bsc arm > >>Description: > > While rsync(1)-ing an 1 GB file the RPi gets almost unresponsible after a > > while and on the serial console there are lots of > > > > smsc0: warning: failed to create new mbuf > > > > kernel messages. Occasionaly dotted with the > > > > [zone: mbuf_cluster] kern.ipc.nmbclusters limit reached > > > > kernel message. > > > > rsync shows a transfer speed of 27.40kB/s (over DSL) even if the files are > > already in sync and only the timestamps differ. > > > > Increasing the value of kern.ipc.nmbclusters by the factor of 2 just > > delayed > > the moment the problem happens. > > > > The first release which shows this is r25518. r255166 and older do not. Oh, I got the version numbers absolutely wrong here. The sentences should be: The first release which shows this is r255138. r255136 and older do not. > > rsync shows a transfer speed of 535.46kB/s (over DSL) on r255166 and older > > releases. > >>How-To-Repeat: > > Use a 1GB file as transfer file. > > If already transfered touch(1) transfer file at the source host. > > > > rsync -trv --modify-window=1 --compress --progress --stats --inplace > > --delete transfer_file user@target.host:/path/to/ > > > > Await problem around 10% of the file is transfered. > >>Fix: > > Undo r255138. > > > >>Release-Note: > >>Audit-Trail: > >>Unformatted: > > _______________________________________________ > > possible workaround: > > sysctl kern.eventtimer.idletick=1 > Just tried it with r255138. Unfortunately there is no change in behavior, so it is not a workaround. Ralf