From owner-freebsd-current@FreeBSD.ORG Thu Jul 3 19:52:51 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5EFAE1065671; Thu, 3 Jul 2008 19:52:51 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by mx1.freebsd.org (Postfix) with ESMTP id EF5408FC17; Thu, 3 Jul 2008 19:52:50 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from p578b68b8.dip0.t-ipconnect.de ([87.139.104.184] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1KEUCi-0002Ch-0t; Thu, 03 Jul 2008 21:10:52 +0200 Message-ID: <486D2438.2060006@gwdg.de> Date: Thu, 03 Jul 2008 21:10:48 +0200 From: Rainer Hurling User-Agent: Thunderbird 2.0.0.14 (X11/20080609) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <486BFFE5.1010808@FreeBSD.org> In-Reply-To: <486BFFE5.1010808@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: Doug Barton Subject: Re: Panic using rsync to msdosfs filesystem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2008 19:52:51 -0000 It seems, that I get the same panic ('stack overflow detected') when *moving* a file on a msdos file system (fat32) like this: mv file_old file_new On 03.07.2008 00:23 (UTC+1), Doug Barton wrote: > I have a western digital passport USB hard drive that I use for backups. > It's always worked fine in FreeBSD and Windows doing straight copies. > Today I tried to get fancy and use rsync and it blew up on me. > > It is a large disk (160G) and I use the following options in fstab: > /dev/da0s1 /mnt/wd msdosfs rw,noauto,-olarge,-m775 0 0 My drive is connected and mounted as following: ad6: 476940MB at ata3-master SATA300 /dev/ad6s5 on /WINDAT (msdosfs, local) I observe this behaviour on different systems, but only with CURRENT newer than June 24. Also, let me know, if I can help. Thanks in advance, Rainer Hurling > Using the following command line for rsync I get a panic as soon as I > hit return: rsync -vv --backup -u -rlt source/ destination/ > > I'm using -current as of r180191. Here is the stack trace: > Unread portion of the kernel message buffer: > panic: stack overflow detected; backtrace may be corrupted > cpuid = 1 > Uptime: 1h52m1s > Physical memory: 2029 MB > Dumping 133 MB: 118 102 86 70 54 38 22 6 > > Reading symbols from /boot/modules/nvidia.ko...Reading symbols from > /boot/modules/nvidia.ko.symbols...done. > done. > Loaded symbols for /boot/modules/nvidia.ko > Reading symbols from /boot/kernel/acpi.ko...Reading symbols from > /boot/kernel/acpi.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/acpi.ko > Reading symbols from /boot/kernel/if_bge.ko...Reading symbols from > /boot/kernel/if_bge.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/if_bge.ko > Reading symbols from /boot/kernel/linux.ko...Reading symbols from > /boot/kernel/linux.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/linux.ko > Reading symbols from /boot/kernel/msdosfs.ko...Reading symbols from > /boot/kernel/msdosfs.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/msdosfs.ko > #0 doadump () at pcpu.h:196 > 196 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); > (kgdb) where > #0 doadump () at pcpu.h:196 > #1 0xc057a9ce in boot (howto=260) > at /usr/local/src/sys/kern/kern_shutdown.c:418 > #2 0xc057ac93 in panic (fmt=Variable "fmt" is not available. > ) at /usr/local/src/sys/kern/kern_shutdown.c:572 > #3 0xc059c5b2 in __stack_chk_fail () > at /usr/local/src/sys/kern/stack_protector.c:17 > #4 0xc652384a in msdosfs_rename (ap=0xc644aca4) > at > /usr/local/src/sys/modules/msdosfs/../../fs/msdosfs/msdosfs_vnops.c:1286 > #5 0xc07b4df5 in VOP_RENAME_APV (vop=0xc6525cc0, a=0xe9e59c1c) > at vnode_if.c:1184 > #6 0xc0605619 in kern_renameat (td=0xc58f1d20, oldfd=-100, > old=0xbfbfc4a0
, newfd=-100, > new=0xbfbfcca0
, > pathseg=UIO_USERSPACE) > at vnode_if.h:622 > #7 0xc06057a6 in kern_rename (td=0xc58f1d20, > from=0xbfbfc4a0
, > to=0xbfbfcca0
, > pathseg=UIO_USERSPACE) > at /usr/local/src/sys/kern/vfs_syscalls.c:3526 > #8 0xc06057d9 in rename (td=0xc58f1d20, uap=0xe9e59cf8) > at /usr/local/src/sys/kern/vfs_syscalls.c:3503 > #9 0xc07a6283 in syscall (frame=0xe9e59d38) > at /usr/local/src/sys/i386/i386/trap.c:1081 > #10 0xc078bb80 in Xint0x80_syscall () > at /usr/local/src/sys/i386/i386/exception.s:261 > #11 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > > > Let me know what I can do to help. > > Doug >