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>