Date: Wed, 15 Aug 2001 15:01:15 +0930 From: Greg Lehey <grog@FreeBSD.org> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Andrew Kenneth Milton <akm@theinternet.com.au>, Michael Lucas <mwlucas@blackhelicopters.org>, current@FreeBSD.ORG Subject: Re: devfs and Vinum (was: any -current && vinum problems?) Message-ID: <20010815150115.V49989@wantadilla.lemis.com> In-Reply-To: <75038.997852562@critter>; from phk@critter.freebsd.dk on Wed, Aug 15, 2001 at 07:16:02AM %2B0200 References: <20010815113056.H854@zeus.theinternet.com.au> <75038.997852562@critter>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, 15 August 2001 at 7:16:02 +0200, Poul-Henning Kamp wrote: > In message <20010815113056.H854@zeus.theinternet.com.au>, Andrew Kenneth Milton > writes: >> +-------[ Greg Lehey ]---------------------- >>> >> >> [snip] >> >>> whether it's been fixed. Basically, devfs as supplied in CURRENT had >>> a 16 character limit on device names, and it didn't understand >>> subdirectories: it treated the / as a part of the device name. >> >> The subdir part bit me about a week ago, so I'd say it's still not fixed. > > This is absolutely news to me. Thinking about it, it is to me too. I noticed that devfs doesn't create directory nodes when I was trying to find ways to delete existing directory entries, but that's the only problem I've had with it. I mentioned it here because it related to the name length limit: the length of the name includes the complete path from the mount point. > More details on this bug are most welcome. > > I'm working on the 16char limit problem as well, but I want to avoid > allocating memory in incovenient circumstances if at all possible. The problem is that I kept having problems with the devfs/vinum combination even after increasing the size to 96 characters. As I said to you on IRC quite some time ago now: <groggy> phk: I've been getting a lot of panics out of zaphod. <groggy> phk: I suspect a bogon or misunderstandingn with Vinum and devfs. <phk> groggy: any clues/traces/pointers ? <phk> wli: you're not a member of the club. <groggy> phk: I'm just guessing that it's a name length problem. <groggy> phk: Hmm. Could be due to incorrect header files somewhere. <groggy> phk: I upped the name length to 96 chars. <groggy> phk: Traceback: <groggy> 1 0xc01b88c4 in panic (fmt=0xc034ce38 "getnewvnode: free vnode isn't") at ../../kern/kern_shutdown.c:598 <groggy> #2 0xc01fb30e in getnewvnode (tag=VT_UFS, mp=0xc230d400, vops=0xc22c4600, vpp=0xcfcdec10) at ../../kern/vfs_subr.c:552 <groggy> #3 0xc02c33aa in ffs_vget (mp=0xc230d400, ino=0x12099, vpp=0xcfcdec60) at ../../ufs/ffs/ffs_vfsops.c:1157 <groggy> #4 0xc02b409d in ffs_valloc (pvp=0xcfc9b920, mode=0x81a4, cred=0xc252db00, vpp=0xcfcdec60) <groggy> at ../../ufs/ffs/ffs_alloc.c:615 <groggy> #5 0xc02cc670 in ufs_makeinode (mode=0x81a4, dvp=0xcfc9b920, vpp=0xcfcdeea4, cnp=0xcfcdeeb8) <groggy> at ../../ufs/ufs/ufs_vnops.c:2215 <groggy> #6 0xc02c9c14 in ufs_create (ap=0xcfcdedbc) at ../../ufs/ufs/ufs_vnops.c:194 <groggy> #7 0xc02ccb39 in ufs_vnoperate (ap=0xcfcdedbc) at ../../ufs/ufs/ufs_vnops.c:2587 <groggy> #8 0xc02068a9 in vn_open (ndp=0xcfcdee90, flagp=0xcfcdee5c, cmode=0x1a4) at vnode_if.h:90 <groggy> #9 0xc0201f9a in open (p=0xcfc25cc0, uap=0xcfcdef80) at ../../kern/vfs_syscalls.c:1077 <groggy> #10 0xc0312445 in syscall (frame={tf_fs = 0x2f, tf_es = 0x2f, tf_ds = 0x2f, tf_edi = 0xbfbff9b8, tf_esi = 0x8, <groggy> tf_ebp = 0xbfbff820, tf_isp = 0xcfcdefd4, tf_ebx = 0x80b54a0, tf_edx = 0x80b5b80, tf_ecx = 0x10, tf_eax = 0x5, <groggy> tf_trapno = 0xc, tf_err = 0x2, tf_eip = 0x8091fec, tf_cs = 0x1f, tf_eflags = 0x293, tf_esp = 0xbfbff7f4, <groggy> tf_ss = 0x2f}) at ../../i386/i386/trap.c:1176 <groggy> phk: I'm wondering whether to analyse, reboot and upgrade, or ignore for the moment. <phk> groggy doesn't really point to either of vinum or DEVFS if you ask me... <groggy> (kgdb) f 9 <groggy> #9 0xc0201f9a in open (p=0xcfc25cc0, uap=0xcfcdef80) at ../../kern/vfs_syscalls.c:1077 <groggy> warning: Source file is more recent than executable. <groggy> 1077 error = vn_open(&nd, &flags, cmode); <groggy> (kgdb) p *uap <groggy> $1 = { <groggy> path = 0x80c4030 "lib/username.o", <groggy> path_ = 0xcfcdef84 "\001\006", <groggy> flags = 0x601, <groggy> flags_ = 0xcfcdef88 "¶\001", <groggy> mode = 0x1b6, <groggy> mode_ = 0xcfcdef8c "¸ù¿¿\006" <groggy> } <groggy> phk: Not directly. I'm suspecting some kind of corruption. <groggy> phk: But nobody else has mentioned it, and there must be some reason why it keeps happening. <groggy> phk: The trouble is, I use this box for two different purposes; <groggy> phk: 1: Testing Vinum. <groggy> phk: 1: Testing Samba. * groggy points at http://build.samba.org/ <groggy> s/1/2/ <groggy> phk: This only started happening since I installed devfs, and I think it only happens if Vinum is loaded. <phk> groggy: well, as far as I know we still havn't conclusive evidence that vinum+DEVFS does the right thing, do we ? <groggy> phk: Exactly. <groggy> phk: I was just waiting for you to say "hey, that sounds familiar". <phk> groggy I'm sorry I havn't gotten further on the long-names for devices, but life has kind of kept me busy this week, starting with a leaky water pipe last sunday... <groggy> phk: No worries. I'll keep looking, maybe. Sorry I can't give you a date on this, but I'm sure you remember. Maybe the leaky water pipe will put a date on it :-) Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010815150115.V49989>