On Wednesday, 15 August 2001 at  7:16:02 +0200, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, 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

> 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 
<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 
<groggy> #4  0xc02b409d in ffs_valloc (pvp=0xcfc9b920, mode=0x81a4, cred=0xc252db00, 
<groggy>     at ../../ufs/ffs/ffs_alloc.c:615
<groggy> #5  0xc02cc670 in ufs_makeinode (mode=0x81a4, dvp=0xcfc9b920, vpp=0xcfcdeea4, 
<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 
<groggy> #8  0xc02068a9 in vn_open (ndp=0xcfcdee90, flagp=0xcfcdee5c, cmode=0x1a4) at 
<groggy> #9  0xc0201f9a in open (p=0xcfc25cc0, uap=0xcfcdef80) at 
<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 
<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 
<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 :-)

See complete headers for address and phone numbers

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to