Re: scp: Write Failed: Cannot allocate memory
Quoting Peter Ross peter.r...@bogen.in-berlin.de:
Quoting Jeremy Chadwick free...@jdc.parodius.com:
On Wed, Jul 06, 2011 at 01:54:12PM +1000, Peter Ross wrote:
Quoting Jeremy Chadwick free...@jdc.parodius.com:
On Wed, Jul 06, 2011 at 01:07:53PM +1000, Peter Ross wrote:
Quoting Jeremy Chadwick free...@jdc.parodius.com:
On Wed, Jul 06, 2011 at 12:23:39PM +1000, Peter Ross wrote:
Quoting Jeremy Chadwick free...@jdc.parodius.com:
On Tue, Jul 05, 2011 at 01:03:20PM -0400, Scott Sipe wrote:
I'm running virtualbox 3.2.12_1 if that has anything to do with it.
sysctl vfs.zfs.arc_max: 62
While I'm trying to scp, kstat.zfs.misc.arcstats.size is
hovering right around that value, sometimes above, sometimes
below (that's as it should be, right?). I don't think that it
dies when crossing over arc_max. I can run the same scp 10 times
and it might fail 1-3 times, with no correlation to the
arcstats.size being above/below arc_max that I can see.
Scott
On Jul 5, 2011, at 3:00 AM, Peter Ross wrote:
Hi all,
just as an addition: an upgrade to last Friday's
FreeBSD-Stable and to VirtualBox 4.0.8 does not fix the
problem.
I will experiment a bit more tomorrow after hours and grab
some statistics.
Regards
Peter
Quoting Peter Ross peter.r...@bogen.in-berlin.de:
Hi all,
I noticed a similar problem last week. It is also very
similar to one reported last year:
http://lists.freebsd.org/pipermail/freebsd-stable/2010-September/058708.html
My server is a Dell T410 server with the same bge card (the
same pciconf -lvc output as described by Mahlon:
http://lists.freebsd.org/pipermail/freebsd-stable/2010-September/058711.html
Yours, Scott, is a em(4)..
Another similarity: In all cases we are using VirtualBox. I
just want to mention it, in case it matters. I am still
running VirtualBox 3.2.
Most of the time kstat.zfs.misc.arcstats.size was reaching
vfs.zfs.arc_max then, but I could catch one or two cases
then the value was still below.
I added vfs.zfs.prefetch_disable=1 to sysctl.conf but it
does not help.
BTW: It looks as ARC only gives back the memory when I
destroy the ZFS (a cloned snapshot containing virtual
machines). Even if nothing happens for hours the buffer
isn't released..
My machine was still running 8.2-PRERELEASE so I am upgrading.
I am happy to give information gathered on old/new kernel
if it helps.
Regards
Peter
Quoting Scott Sipe csco...@gmail.com:
On Jul 2, 2011, at 12:54 AM, jhell wrote:
On Fri, Jul 01, 2011 at 03:22:32PM -0700, Jeremy Chadwick wrote:
On Fri, Jul 01, 2011 at 03:13:17PM -0400, Scott Sipe wrote:
I'm running 8.2-RELEASE and am having new problems
with scp. When scping
files to a ZFS directory on the FreeBSD server --
most notably large files
-- the transfer frequently dies after just a few
seconds. In my last test, I
tried to scp an 800mb file to the FreeBSD system and
the transfer died after
200mb. It completely copied the next 4 times I
tried, and then died again on
the next attempt.
On the client side:
Connection to home closed by remote host.
lost connection
In /var/log/auth.log:
Jul 1 14:54:42 freebsd sshd[18955]: fatal: Write
failed: Cannot allocate
memory
I've never seen this before and have used scp before
to transfer large files
without problems. This computer has been used in
production for months and
has a current uptime of 36 days. I have not been
able to notice any problems
copying files to the server via samba or netatalk, or
any problems in
apache.
Uname:
FreeBSD xeon 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Sat
Feb 19 01:02:54 EST
2011 root@xeon:/usr/obj/usr/src/sys/GENERIC amd64
I've attached my dmesg and output of vmstat -z.
I have not restarted the sshd daemon or rebooted the computer.
Am glad to provide any other information or test anything else.
{snip vmstat -z and dmesg}
You didn't provide details about your networking setup (rc.conf,
ifconfig -a, etc.). netstat -m would be useful too.
Next, please see this thread circa September 2010,
titled Network
memory allocation failures:
http://lists.freebsd.org/pipermail/freebsd-stable/2010-September/thread.html#58708
The user in that thread is using rsync, which relies on
scp by default.
I believe this problem is similar, if not identical, to yours.
Please also provide your output of ( /usr/bin/limits -a )
for the server
end and the client.
I am not quite sure I agree with the need for ifconfig
-a but some
information about the networking driver your using for
the interface
would be helpful, uptime of the boxes. And configuration
of the pool.
e.g. ( zpool status -a ;zfs get all poolname ) You
should probably
prop this information up somewhere so you can reference by
URL whenever
needed.
rsync(1) does not rely on scp(1) whatsoever but rsync(1)
can be made to
use ssh(1) instead of rsh(1) and I believe that is what Jeremy is
stating here but correct me if I am wrong. It does use ssh(1) by
default.
Its a possiblity as well that if using
Re: scp: Write Failed: Cannot allocate memory
Quoting Peter Ross peter.r...@bogen.in-berlin.de:
Quoting Peter Ross peter.r...@bogen.in-berlin.de:
Quoting Jeremy Chadwick free...@jdc.parodius.com:
On Wed, Jul 06, 2011 at 01:54:12PM +1000, Peter Ross wrote:
Quoting Jeremy Chadwick free...@jdc.parodius.com:
On Wed, Jul 06, 2011 at 01:07:53PM +1000, Peter Ross wrote:
Quoting Jeremy Chadwick free...@jdc.parodius.com:
On Wed, Jul 06, 2011 at 12:23:39PM +1000, Peter Ross wrote:
Quoting Jeremy Chadwick free...@jdc.parodius.com:
On Tue, Jul 05, 2011 at 01:03:20PM -0400, Scott Sipe wrote:
I'm running virtualbox 3.2.12_1 if that has anything to do with it.
sysctl vfs.zfs.arc_max: 62
While I'm trying to scp, kstat.zfs.misc.arcstats.size is
hovering right around that value, sometimes above, sometimes
below (that's as it should be, right?). I don't think that it
dies when crossing over arc_max. I can run the same scp 10 times
and it might fail 1-3 times, with no correlation to the
arcstats.size being above/below arc_max that I can see.
Scott
On Jul 5, 2011, at 3:00 AM, Peter Ross wrote:
Hi all,
just as an addition: an upgrade to last Friday's
FreeBSD-Stable and to VirtualBox 4.0.8 does not fix the
problem.
I will experiment a bit more tomorrow after hours and grab
some statistics.
Regards
Peter
Quoting Peter Ross peter.r...@bogen.in-berlin.de:
Hi all,
I noticed a similar problem last week. It is also very
similar to one reported last year:
http://lists.freebsd.org/pipermail/freebsd-stable/2010-September/058708.html
My server is a Dell T410 server with the same bge card (the
same pciconf -lvc output as described by Mahlon:
http://lists.freebsd.org/pipermail/freebsd-stable/2010-September/058711.html
Yours, Scott, is a em(4)..
Another similarity: In all cases we are using VirtualBox. I
just want to mention it, in case it matters. I am still
running VirtualBox 3.2.
Most of the time kstat.zfs.misc.arcstats.size was reaching
vfs.zfs.arc_max then, but I could catch one or two cases
then the value was still below.
I added vfs.zfs.prefetch_disable=1 to sysctl.conf but it
does not help.
BTW: It looks as ARC only gives back the memory when I
destroy the ZFS (a cloned snapshot containing virtual
machines). Even if nothing happens for hours the buffer
isn't released..
My machine was still running 8.2-PRERELEASE so I am upgrading.
I am happy to give information gathered on old/new kernel
if it helps.
Regards
Peter
Quoting Scott Sipe csco...@gmail.com:
On Jul 2, 2011, at 12:54 AM, jhell wrote:
On Fri, Jul 01, 2011 at 03:22:32PM -0700, Jeremy Chadwick wrote:
On Fri, Jul 01, 2011 at 03:13:17PM -0400, Scott Sipe wrote:
I'm running 8.2-RELEASE and am having new problems
with scp. When scping
files to a ZFS directory on the FreeBSD server --
most notably large files
-- the transfer frequently dies after just a few
seconds. In my last test, I
tried to scp an 800mb file to the FreeBSD system and
the transfer died after
200mb. It completely copied the next 4 times I
tried, and then died again on
the next attempt.
On the client side:
Connection to home closed by remote host.
lost connection
In /var/log/auth.log:
Jul 1 14:54:42 freebsd sshd[18955]: fatal: Write
failed: Cannot allocate
memory
I've never seen this before and have used scp before
to transfer large files
without problems. This computer has been used in
production for months and
has a current uptime of 36 days. I have not been
able to notice any problems
copying files to the server via samba or netatalk, or
any problems in
apache.
Uname:
FreeBSD xeon 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Sat
Feb 19 01:02:54 EST
2011 root@xeon:/usr/obj/usr/src/sys/GENERIC amd64
I've attached my dmesg and output of vmstat -z.
I have not restarted the sshd daemon or rebooted the computer.
Am glad to provide any other information or test
anything else.
{snip vmstat -z and dmesg}
You didn't provide details about your networking setup
(rc.conf,
ifconfig -a, etc.). netstat -m would be useful too.
Next, please see this thread circa September 2010,
titled Network
memory allocation failures:
http://lists.freebsd.org/pipermail/freebsd-stable/2010-September/thread.html#58708
The user in that thread is using rsync, which relies on
scp by default.
I believe this problem is similar, if not identical, to yours.
Please also provide your output of ( /usr/bin/limits -a )
for the server
end and the client.
I am not quite sure I agree with the need for ifconfig
-a but some
information about the networking driver your using for
the interface
would be helpful, uptime of the boxes. And configuration
of the pool.
e.g. ( zpool status -a ;zfs get all poolname ) You
should probably
prop this information up somewhere so you can reference by
URL whenever
needed.
rsync(1) does not rely on scp(1) whatsoever but rsync(1)
can be made to
use ssh(1) instead of rsh(1) and I believe that is what
Jeremy is
stating here but correct me if I am wrong. It does use
Re: Status of support for Intel 3000 (Sandybridge) (and VESA help)
Does any one know what the state of support for this might be? ATM, the Intel driver simply does not recognize it. I just saw HP 4330s in the store. One post about year ago mentioned 3000/3100 working perfect. Could you try out all drivers, ie i915.ko? http://forums.freebsd.org/showthread.php?t=16395 I'm not sure if it is the same generation of graphics, re- garding the very name. There is just few reviews on details, but seems that linux works perfectly on the same hardware, after this russian site (if you could manage the lingo): http://retera.ru/reviews/hp-probook-4330s.html If you have time, post how you manage with your hardware. Zoran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: scp: Write Failed: Cannot allocate memory
On Wed, Jul 6, 2011 at 4:21 AM, Peter Ross peter.r...@bogen.in-berlin.dewrote:
Quoting Peter Ross peter.r...@bogen.in-berlin.de**:
Quoting Peter Ross peter.r...@bogen.in-berlin.de**:
Quoting Jeremy Chadwick free...@jdc.parodius.com:
On Wed, Jul 06, 2011 at 01:54:12PM +1000, Peter Ross wrote:
Quoting Jeremy Chadwick free...@jdc.parodius.com:
On Wed, Jul 06, 2011 at 01:07:53PM +1000, Peter Ross wrote:
Quoting Jeremy Chadwick free...@jdc.parodius.com:
On Wed, Jul 06, 2011 at 12:23:39PM +1000, Peter Ross wrote:
Quoting Jeremy Chadwick free...@jdc.parodius.com:
On Tue, Jul 05, 2011 at 01:03:20PM -0400, Scott Sipe wrote:
I'm running virtualbox 3.2.12_1 if that has anything to do with
it.
sysctl vfs.zfs.arc_max: 62
While I'm trying to scp, kstat.zfs.misc.arcstats.size is
hovering right around that value, sometimes above, sometimes
below (that's as it should be, right?). I don't think that it
dies when crossing over arc_max. I can run the same scp 10 times
and it might fail 1-3 times, with no correlation to the
arcstats.size being above/below arc_max that I can see.
Scott
On Jul 5, 2011, at 3:00 AM, Peter Ross wrote:
Hi all,
just as an addition: an upgrade to last Friday's
FreeBSD-Stable and to VirtualBox 4.0.8 does not fix the
problem.
I will experiment a bit more tomorrow after hours and grab
some statistics.
Regards
Peter
Quoting Peter Ross peter.r...@bogen.in-berlin.de**:
Hi all,
I noticed a similar problem last week. It is also very
similar to one reported last year:
http://lists.freebsd.org/**pipermail/freebsd-stable/2010-**
September/058708.htmlhttp://lists.freebsd.org/pipermail/freebsd-stable/2010-September/058708.html
My server is a Dell T410 server with the same bge card (the
same pciconf -lvc output as described by Mahlon:
http://lists.freebsd.org/**pipermail/freebsd-stable/2010-**
September/058711.htmlhttp://lists.freebsd.org/pipermail/freebsd-stable/2010-September/058711.html
Yours, Scott, is a em(4)..
Another similarity: In all cases we are using VirtualBox. I
just want to mention it, in case it matters. I am still
running VirtualBox 3.2.
Most of the time kstat.zfs.misc.arcstats.size was reaching
vfs.zfs.arc_max then, but I could catch one or two cases
then the value was still below.
I added vfs.zfs.prefetch_disable=1 to sysctl.conf but it
does not help.
BTW: It looks as ARC only gives back the memory when I
destroy the ZFS (a cloned snapshot containing virtual
machines). Even if nothing happens for hours the buffer
isn't released..
My machine was still running 8.2-PRERELEASE so I am upgrading.
I am happy to give information gathered on old/new kernel if it
helps.
Regards
Peter
Quoting Scott Sipe csco...@gmail.com:
On Jul 2, 2011, at 12:54 AM, jhell wrote:
On Fri, Jul 01, 2011 at 03:22:32PM -0700, Jeremy Chadwick
wrote:
On Fri, Jul 01, 2011 at 03:13:17PM -0400, Scott Sipe wrote:
I'm running 8.2-RELEASE and am having new problems
with scp. When scping
files to a ZFS directory on the FreeBSD server --
most notably large files
-- the transfer frequently dies after just a few
seconds. In my last test, I
tried to scp an 800mb file to the FreeBSD system and
the transfer died after
200mb. It completely copied the next 4 times I
tried, and then died again on
the next attempt.
On the client side:
Connection to home closed by remote host.
lost connection
In /var/log/auth.log:
Jul 1 14:54:42 freebsd sshd[18955]: fatal: Write
failed: Cannot allocate
memory
I've never seen this before and have used scp before
to transfer large files
without problems. This computer has been used in
production for months and
has a current uptime of 36 days. I have not been
able to notice any problems
copying files to the server via samba or netatalk, or
any problems in
apache.
Uname:
FreeBSD xeon 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Sat
Feb 19 01:02:54 EST
2011 root@xeon:/usr/obj/usr/src/**sys/GENERIC amd64
I've attached my dmesg and output of vmstat -z.
I have not restarted the sshd daemon or rebooted the
computer.
Am glad to provide any other information or test anything
else.
{snip vmstat -z and dmesg}
You didn't provide details about your networking setup
(rc.conf,
ifconfig -a, etc.). netstat -m would be useful too.
Next, please see this thread circa September 2010, titled
Network
memory allocation failures:
http://lists.freebsd.org/**pipermail/freebsd-stable/2010-**
September/thread.html#58708http://lists.freebsd.org/pipermail/freebsd-stable/2010-September/thread.html#58708
The user in that thread is using rsync, which relies on
scp by default.
I believe this problem is similar, if not identical, to yours.
Please also provide your output of ( /usr/bin/limits -a )
for the server
end and the client.
I am not quite sure I agree with the need for ifconfig -a but
some
information about the networking driver your using for the
panic: spin lock held too long (RELENG_8 from today)
I did a buildworld on this box to bring it up to RELENG_8 for the BIND fixes. Unfortunately, the formerly solid box (April 13th kernel) panic'd tonight with Unread portion of the kernel message buffer: spin lock 0xc0b1d200 (sched lock 1) held by 0xc5dac8a0 (tid 100107) too long panic: spin lock held too long cpuid = 0 Uptime: 13h30m4s Physical memory: 2035 MB Its a somewhat busy box taking in mail as well as backups for a few servers over nfs. At the time, it would have been getting about 250Mb/s inbound on its gigabit interface. Full core.txt file at http://www.tancsa.com/core-jul8-2011.txt #0 doadump () at pcpu.h:231 231 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:231 #1 0xc06fd6d3 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:429 #2 0xc06fd937 in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:602 #3 0xc06ed95f in _mtx_lock_spin_failed (m=0x0) at /usr/src/sys/kern/kern_mutex.c:490 #4 0xc06ed9e5 in _mtx_lock_spin (m=0xc0b1d200, tid=3312388992, opts=0, file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:526 #5 0xc0720254 in sched_add (td=0xc5dac5c0, flags=0) at /usr/src/sys/kern/sched_ule.c:1119 #6 0xc07203f9 in sched_wakeup (td=0xc5dac5c0) at /usr/src/sys/kern/sched_ule.c:1950 #7 0xc07061f8 in setrunnable (td=0xc5dac5c0) at /usr/src/sys/kern/kern_synch.c:499 #8 0xc07362af in sleepq_resume_thread (sq=0xca0da300, td=0xc5dac5c0, pri=Variable pri is not available. ) at /usr/src/sys/kern/subr_sleepqueue.c:751 #9 0xc0736e18 in sleepq_signal (wchan=0xc5fafe50, flags=1, pri=0, queue=0) at /usr/src/sys/kern/subr_sleepqueue.c:825 #10 0xc06b6764 in cv_signal (cvp=0xc5fafe50) at /usr/src/sys/kern/kern_condvar.c:422 #11 0xc08eaa0d in xprt_assignthread (xprt=Variable xprt is not available. ) at /usr/src/sys/rpc/svc.c:342 #12 0xc08ec502 in xprt_active (xprt=0xc95d9600) at /usr/src/sys/rpc/svc.c:378 #13 0xc08ee051 in svc_vc_soupcall (so=0xc6372ce0, arg=0xc95d9600, waitflag=1) at /usr/src/sys/rpc/svc_vc.c:747 #14 0xc075bbb1 in sowakeup (so=0xc6372ce0, sb=0xc6372d34) at /usr/src/sys/kern/uipc_sockbuf.c:191 #15 0xc08447bc in tcp_do_segment (m=0xcaa8d200, th=0xca6aa824, so=0xc6372ce0, tp=0xc63b4d20, drop_hdrlen=52, tlen=1448, iptos=0 '\0', ti_locked=2) at /usr/src/sys/netinet/tcp_input.c:1775 #16 0xc0847930 in tcp_input (m=0xcaa8d200, off0=20) at /usr/src/sys/netinet/tcp_input.c:1329 #17 0xc07ddaf7 in ip_input (m=0xcaa8d200) at /usr/src/sys/netinet/ip_input.c:787 #18 0xc07b8859 in netisr_dispatch_src (proto=1, source=0, m=0xcaa8d200) at /usr/src/sys/net/netisr.c:859 #19 0xc07b8af0 in netisr_dispatch (proto=1, m=0xcaa8d200) at /usr/src/sys/net/netisr.c:946 #20 0xc07ae5e1 in ether_demux (ifp=0xc56ed800, m=0xcaa8d200) at /usr/src/sys/net/if_ethersubr.c:894 #21 0xc07aeb5f in ether_input (ifp=0xc56ed800, m=0xcaa8d200) at /usr/src/sys/net/if_ethersubr.c:753 #22 0xc09977b2 in nfe_int_task (arg=0xc56ff000, pending=1) at /usr/src/sys/dev/nfe/if_nfe.c:2187 #23 0xc07387ca in taskqueue_run_locked (queue=0xc5702440) at /usr/src/sys/kern/subr_taskqueue.c:248 #24 0xc073895c in taskqueue_thread_loop (arg=0xc56ff130) at /usr/src/sys/kern/subr_taskqueue.c:385 #25 0xc06d1027 in fork_exit (callout=0xc07388a0 taskqueue_thread_loop, arg=0xc56ff130, frame=0xc538ed28) at /usr/src/sys/kern/kern_fork.c:861 #26 0xc09a5c24 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:275 (kgdb) -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
