libc threadsafe ?
I see some changes to -current as of Jan 2001, that attempt to make libc threadsafe without -pthread and _THREAD_SAFE. http://groups.google.com/groups?q=Daniel+Eischen&hl=en&lr=&safe=off&scoring=d&as_drrb=b&as_mind=1&as_minm=1&as_miny=2001&as_maxd=20&; as_maxm=1&as_maxy=2001&rnum=4&ic=1&selm=94amg1%242fnu%241%40FreeBSD.csie.NCTU.edu.tw I'm attempting to port IBM's NGPT to freebsd and most of the things seem to be working fine. The following is the C file needed to make it work, apart from some minor work arounds for Makefiles. http://sharmas.dhs.org/~adsharma/pth_native_freebsd.c I'm trying to hunt down a stack corruption that I'm seeing after a sigsetjmp and siglongjmp. It could be due to a bug in NGPT or it could be due to the fact that I'm linking -lc and not -lc_r and -lc is not completely thread safe. The stack in question was malloc'ed and passed as an argument to rfork_thread. My question is, do I need to do anything else (apart from incrementing __isthreaded and providing strong references to locking routines) to get -lc to work in a MT environment ? -Arun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ppp problems on 4.3-RELEASE and PPPoE
According to James Housley: > and I am not in Canada. I am using natd and ipfw for NAT and the > firewall. The link has a static IP if it matters. Below I am attaching > ppp.conf. I have watched some of the data with tcpdump on both tun0 and I'm also using ppp + ng_pppoe on a 4.3-STABLE system. My MTU is 1492. Configuration below. I'm experiencing lockups from ppp (average is one time a day). ppp stops recieving anything from the modem (Alcatel Speed Touch Home with ethernet). Any idea where it could come from? -=-=- default: set device /dev/cuaa0 set speed 115200 disable lqr deny lqr set redial 15 0 set reconnect 15 1 set accmap 0 set server +3000 adsl: set device PPPoE:ed0: set authname * set authkey * set timeout 0 set mtu 1492 set mru 1492 set speed sync disable acfcomp protocomp deny acfcomp set log Phase Chat LQM hdlc LCP IPCP CCP tun set ifaddr 0/0 0/0 add 0 0 HISADDR dial -=-=- Nothing interesting from the ppp log :-( -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun 4 22:44:19 CEST 2000 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
_SC_NPROCESSORS_CONF
Single UNIX spec doesn't include the above sysconf(3) argument, but many UNIX variants do. What's the BSD way of doing this ? -Arun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [pthreads-devel] Bug in pth_native.c ? + FreeBSD port
On Sun, May 20, 2001 at 08:05:19AM -0400, Bill Abt wrote: > Yeah, your right about slot. It should be allocated off the heap... Hmm, > that would probably explain a few inconsistencies we've seen as well. > Thanks > > As far as incorporating your changes into the release, sure!!! Another > platform/os would be great. > Ok, the patch is here: http://sharmas.dhs.org/~adsharma/ngpt-freebsd.patch.txt Rough edges: (a) @NATIVE@ needs to be substituted with pth_native.c or pth_native_freebsd.c depending on the platform. I'm not too good at autoconf. (b) The changes to pth_lib.c can probably be ignored. They're there to fix compilation errors on FreeBSD and it's not clear to me what the correct solution is. (c) This is a mysterious bug that I'm not able to solve even after fighting with it for a couple of days: -void (* volatile mctx_starting_func)(void); +static void (* volatile mctx_starting_func)(void); This variable gets corrupted on FreeBSD after a context switch. I suspect that this could be a compiler issue, but haven't been able to pin point the problem. I'm using: $ gcc -v Using builtin specs. gcc version 2.95.3 20010315 (release) Datapoints: 1. Increasing the stack size, didn't help. It also makes it unlikely that someone is accidentally stepping on the malloc'ed stack. 2. The problem disappeared after I put some debug statements in the surrounding code. This might have tickled the compiler in such a way that the problem got masked. Making the variable static makes the problem go away. This shouldn't be a problem, since all threads get bootstrapped the same way ? -Arun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: _SC_NPROCESSORS_CONF
Arun Sharma writes: > Single UNIX spec doesn't include the above sysconf(3) argument, but > many UNIX variants do. What's the BSD way of doing this ? How about the hw.ncpu sysctl? Drew -- Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: [EMAIL PROTECTED] Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: _SC_NPROCESSORS_CONF
On Sun, May 20, 2001 at 04:57:17PM -0400, Andrew Gallatin wrote: > > Arun Sharma writes: > > Single UNIX spec doesn't include the above sysconf(3) argument, but > > many UNIX variants do. What's the BSD way of doing this ? > > How about the hw.ncpu sysctl? Any objections to a patch implementing sysconf(_SC_NPROCESSORS_CONF) in terms of hw.ncpu ? -Arun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
syscons problem
Yokota-san, I am experiencing a problem with syscons and init when I have a certain line in my kernel configuration file, and am hoping that you can fix the bug. My system is a recent 4-STABLE, although the problem also showed up in an April 24 4-STABLE. I do not have a -CURRENT box. FreeBSD trurl.zer0.org 4.3-STABLE FreeBSD 4.3-STABLE #6: Wed May 16 17:44:58 PDT 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GEN i386 Here is a diff between a working kernel configuration file (GEN) and a non-working one (GEN.not): trurl gsutter /sys/i386/conf $diff -u -0 GEN.not GEN --- GEN.not Wed May 16 17:12:42 2001 +++ GEN Wed May 16 17:49:06 2001 @@ -61 +61 @@ -optionsSC_HISTORY_SIZE=8000 +#options SC_HISTORY_SIZE=8000 I have not tested with other SC_HISTORY_SIZE values. When I boot with a kernel compiled with the SC_HISTORY_SIZE=8000 option, I observe the following: 1. No gettys are spawned. If I ssh in, I can manually start gettys. 2. Processes remain in zombie state after exiting. This occurs whether they exit normally, or are killed with any signal. These two symptoms lead me to believe that init(8) is being adversely affected by the syscons history size option. If I can be of assistance in tracking down this problem, please let me know. Regards, Greg -- Gregory S. Sutter Frotz! mailto:[EMAIL PROTECTED] http://www.zer0.org/~gsutter/ hkp://wwwkeys.pgp.net/0x845DFEDD PGP signature
Re: De-setgid-ifying ipcs(1)
Alfred Perlstein <[EMAIL PROTECTED]> writes:
> Probably not the commentary you're looking for, however the
> getopt parsing shouldn't be done like this:
Some comments is usually better than no comments: to have noticed this
problem, you had to have at least skimmed through the other (kernel)
parts, so I know I didn't do anything *too* evil :-).
> > - while ((i = getopt(argc, argv, "MmQqSsabC:cN:optT")) != -1)
> > + use_sysctl = 1;
> > + while ((i = getopt(argc, argv, "MmQqSsabC:cN:optTy")) != -1)
> > switch (i) {
> > case 'M':
> > display = SHMTOTAL;
> > @@ -184,39 +187,45 @@
> > case 't':
> > option |= TIME;
> > break;
> > + case 'y':
> > + use_sysctl = !use_sysctl;
> > + break;
> > default:
> > usage();
> > }
>
> Multiple -y options will invert the sense of the flag right?
>
> Might as well inialize it to 1 in the DATA segment and replace
> !use_sysctl with just 0.
Point taken. I've done as you suggested in the patch I just posted to
-audit for review.
Thanks again,
Dima Dorfman
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Boot time memory issue
I was curious whether the memory limitation on the Sony VAIO Z505 machines was an actual hardware limitation or a marketing issue. I just tried adding a 256MB module to my machine. The BIOS seemed to mostly recognize it. It did see 320MB of RAM, but had problems when testing all of it. Current (from a couple of weeks ago) boots, but gives me: Too many holes in the physical address space, giving up and comes up showing 64MB of RAM. Is this something that can be worked around, or have I run up against an actual hardware limit on the machine? barry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
background_fsck rc.conf option
Does anybody object to adding a background_fsck rc.conf option to
facilitate easy switching of background fsck on or off? Robert Watson
suggested this on cvs-all some time ago, but the discussion drifted
off. Attached is a very short patch to implement it; it basically
makes rev. 1.263 of src/etc/rc conditional on ${background_fsck}. The
patch leaves background fsck on by default, but now that can be easily
changed; I'm sure there will be a long thread about what the default
should be later.
Comments? Suggestions?
Thanks,
Dima Dorfman
[EMAIL PROTECTED]
Index: etc/rc
===
RCS file: /stl/src/FreeBSD/src/etc/rc,v
retrieving revision 1.264
diff -u -r1.264 rc
--- etc/rc 2001/05/13 20:43:30 1.264
+++ etc/rc 2001/05/21 00:19:25
@@ -184,9 +184,14 @@
case ${bootmode} in
autoboot)
echo 'Automatic boot in progress...'
-# To restore old fsck behavior use:
-# fsck -p
- fsck -F -p
+ case ${background_fsck} in
+ [Yy][Ee][Ss])
+ fsck -F -p
+ ;;
+ *)
+ fsck -p
+ ;;
+ esac
case $? in
0)
;;
@@ -810,9 +815,13 @@
;;
esac
-# Start background fsck checks
-echo 'Starting background filesystem checks'
-nice -4 fsck -B -p 2>&1 | logger -p daemon.notice &
+# Start background fsck checks if necessary
+case ${background_fsck} in
+[Yy][Ee][Ss])
+ echo 'Starting background filesystem checks'
+ nice -4 fsck -B -p 2>&1 | logger -p daemon.notice &
+ ;;
+esac
echo ''
Index: etc/defaults/rc.conf
===
RCS file: /stl/src/FreeBSD/src/etc/defaults/rc.conf,v
retrieving revision 1.105
diff -u -r1.105 rc.conf
--- etc/defaults/rc.conf2001/05/14 20:51:03 1.105
+++ etc/defaults/rc.conf2001/05/21 00:19:25
@@ -33,6 +33,7 @@
local_startup="/usr/local/etc/rc.d /usr/X11R6/etc/rc.d"# startup script dirs.
rc_conf_files="/etc/rc.conf /etc/rc.conf.local"
fsck_y_enable="NO" # Set to YES to do fsck -y if the initial preen fails.
+background_fsck="YES" # Attempt to run fsck in the background where possible.
##
### Network configuration sub-section ##
Index: share/man/man5/rc.conf.5
===
RCS file: /stl/src/FreeBSD/src/share/man/man5/rc.conf.5,v
retrieving revision 1.104
diff -u -r1.104 rc.conf.5
--- share/man/man5/rc.conf.52001/05/15 15:52:55 1.104
+++ share/man/man5/rc.conf.52001/05/21 00:19:25
@@ -625,6 +625,13 @@
.Xr fsck 8
will be run with the -y flag if the initial preen
of the filesystems fails.
+.It Va background_fsck
+.Pq Vt bool
+if set to
+.Ar YES ,
+the system will attempt to run
+.Xr fsck 8
+in the background where possible.
.It Va syslogd_enable
.Pq Vt bool
If set to
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: background_fsck rc.conf option
Looks good! Excellent! Go for it! :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
upgrading packages
Currently, upgrading packages is more painful than it should be. However, it would not take much work to make things significantly more friendly - 1. pkg_add - when a package is installed, it should check for an older version of itself, and if the new version provides everything from the old one, update the associated +REQUIRED_BY files 2. pkg_delete - when a package is deleted, it should check for a newer version of itself, and files that overlap between both versions should not be deleted Careful users can avoid the problems that these two changes fix, but there's really no reason to not make life simple for everyone. Comments? Takers? I'm a bit busy due to the finals that I've got looming on the horizon, but I'll eventually get to it if no one else does. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: syscons problem
In the last episode (May 20), Gregory Sutter said: > I am experiencing a problem with syscons and init when I have a > certain line in my kernel configuration file, and am hoping that you > can fix the bug. My system is a recent 4-STABLE, although the > problem also showed up in an April 24 4-STABLE. I do not have a > -CURRENT box. > > FreeBSD trurl.zer0.org 4.3-STABLE FreeBSD 4.3-STABLE #6: Wed May 16 17:44:58 PDT >2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GEN i386 > > Here is a diff between a working kernel configuration file (GEN) and > a non-working one (GEN.not): > > trurl gsutter /sys/i386/conf $diff -u -0 GEN.not GEN > --- GEN.not Wed May 16 17:12:42 2001 > +++ GEN Wed May 16 17:49:06 2001 > @@ -61 +61 @@ > -optionsSC_HISTORY_SIZE=8000 > +#options SC_HISTORY_SIZE=8000 That's 8000 lines; 320 25-line screens, totaling 64 bytes. Do you rally want a history that large? > I have not tested with other SC_HISTORY_SIZE values. > > When I boot with a kernel compiled with the SC_HISTORY_SIZE=8000 > option, I observe the following: > > 1. No gettys are spawned. If I ssh in, I can manually start > gettys. Does anything get logged in /var/log ? If init can't spawn a getty, it usually logs it. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
vmspace leak (+ tentative fix)
There's a certain issue that when several processes sharing a vmspace are
exiting at the same time, there is a race condition such that the shared
memory is going to be lost because the check for vm->vm_refcnt being the
check for the last decrement happening before the last decrement is
actually performed, allowing for the possibility of Giant being dropped
(duh, during flushing of dirty pages), and all the trouble that entails...
Anyway, here's what I currently have which seems to fix it. Anyone want to
comment on its correctness? The newly introduced vm_freer should be valid
to test against: it's only necessary to differentiate between multiple
holders of the same vmspace, so there shouldn't be any problem with recycled
proc pointers or anything.
Index: kern/kern_exit.c
===
RCS file: /usr2/ncvs/src/sys/kern/kern_exit.c,v
retrieving revision 1.123
diff -u -r1.123 kern_exit.c
--- kern/kern_exit.c2001/03/28 11:52:53 1.123
+++ kern/kern_exit.c2001/04/29 23:47:36
@@ -222,13 +222,14 @@
* Can't free the entire vmspace as the kernel stack
* may be mapped within that space also.
*/
- if (vm->vm_refcnt == 1) {
+ if (--vm->vm_refcnt == 0) {
if (vm->vm_shm)
shmexit(p);
pmap_remove_pages(vmspace_pmap(vm), VM_MIN_ADDRESS,
VM_MAXUSER_ADDRESS);
(void) vm_map_remove(&vm->vm_map, VM_MIN_ADDRESS,
VM_MAXUSER_ADDRESS);
+ vm->vm_freer = curproc;
}
PROC_LOCK(p);
@@ -379,7 +380,7 @@
/*
* Finally, call machine-dependent code to release the remaining
* resources including address space, the kernel stack and pcb.
-* The address space is released by "vmspace_free(p->p_vmspace)";
+* The address space is released by "vmspace_exitfree(p)";
* This is machine-dependent, as we may have to change stacks
* or ensure that the current one isn't reallocated before we
* finish. cpu_exit will end with a call to cpu_switch(), finishing
Index: vm/vm_map.c
===
RCS file: /usr2/ncvs/src/sys/vm/vm_map.c,v
retrieving revision 1.198
diff -u -r1.198 vm_map.c
--- vm/vm_map.c 2001/04/12 21:50:03 1.198
+++ vm/vm_map.c 2001/04/29 23:44:09
@@ -178,6 +178,7 @@
vm->vm_map.pmap = vmspace_pmap(vm); /* XXX */
vm->vm_refcnt = 1;
vm->vm_shm = NULL;
+ vm->vm_freer = NULL;
return (vm);
}
@@ -194,6 +195,27 @@
vm_object_init2();
}
+static __inline void
+vmspace_dofree(vm)
+ struct vmspace *vm;
+{
+
+ /*
+* Lock the map, to wait out all other references to it.
+* Delete all of the mappings and pages they hold, then call
+* the pmap module to reclaim anything left.
+*/
+ vm_map_lock(&vm->vm_map);
+ (void) vm_map_delete(&vm->vm_map, vm->vm_map.min_offset,
+ vm->vm_map.max_offset);
+ vm_map_unlock(&vm->vm_map);
+
+ pmap_release(vmspace_pmap(vm));
+ vm_map_destroy(&vm->vm_map);
+ zfree(vmspace_zone, vm);
+}
+
+
void
vmspace_free(vm)
struct vmspace *vm;
@@ -202,22 +224,17 @@
if (vm->vm_refcnt == 0)
panic("vmspace_free: attempt to free already freed vmspace");
- if (--vm->vm_refcnt == 0) {
+ if (--vm->vm_refcnt == 0)
+ vmspace_dofree(vm);
+}
- /*
-* Lock the map, to wait out all other references to it.
-* Delete all of the mappings and pages they hold, then call
-* the pmap module to reclaim anything left.
-*/
- vm_map_lock(&vm->vm_map);
- (void) vm_map_delete(&vm->vm_map, vm->vm_map.min_offset,
- vm->vm_map.max_offset);
- vm_map_unlock(&vm->vm_map);
+void
+vmspace_exitfree(p)
+ struct proc *p;
+{
- pmap_release(vmspace_pmap(vm));
- vm_map_destroy(&vm->vm_map);
- zfree(vmspace_zone, vm);
- }
+ if (p == p->p_vmspace->vm_freer)
+ vmspace_dofree(p->p_vmspace);
}
/*
@@ -2128,7 +2145,7 @@
vm2 = vmspace_alloc(old_map->min_offset, old_map->max_offset);
bcopy(&vm1->vm_startcopy, &vm2->vm_startcopy,
- (caddr_t) (vm1 + 1) - (caddr_t) &vm1->vm_startcopy);
+ (caddr_t) &vm1->vm_endcopy - (caddr_t) &vm1->vm_startcopy);
new_map = &vm2->vm_map; /* XXX */
new_map->timestamp = 1;
Index: vm/vm_map.h
===
RCS file: /usr2/ncvs/src/sys/vm/vm_map.h,v
retrieving revision 1.60
diff -u -r1.60 vm_map.h
--- vm/vm_map.h 2001/04/13 10:22:14 1.60
+++ vm/vm_map.h 2001/04/29 23:26:50
@@ -192,6 +192,8 @@
caddr_t vm_daddr; /* user virt
Re: syscons problem
Gregory Sutter writes: > I am experiencing a problem with syscons and init when I have a > certain line in my kernel configuration file, and am hoping that > you can fix the bug. My system is a recent 4-STABLE, although > the problem also showed up in an April 24 4-STABLE. I do not > have a -CURRENT box. > > FreeBSD trurl.zer0.org 4.3-STABLE FreeBSD 4.3-STABLE #6: Wed May 16 17:44:58 PDT >2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GEN i386 > > Here is a diff between a working kernel configuration file (GEN) > and a non-working one (GEN.not): > > trurl gsutter /sys/i386/conf $diff -u -0 GEN.not GEN > --- GEN.not Wed May 16 17:12:42 2001 > +++ GEN Wed May 16 17:49:06 2001 > @@ -61 +61 @@ > -optionsSC_HISTORY_SIZE=8000 > +#options SC_HISTORY_SIZE=8000 > > I have not tested with other SC_HISTORY_SIZE values. > > When I boot with a kernel compiled with the SC_HISTORY_SIZE=8000 > option, I observe the following: > > 1. No gettys are spawned. If I ssh in, I can manually start > gettys. > > 2. Processes remain in zombie state after exiting. This occurs > whether they exit normally, or are killed with any signal. > > These two symptoms lead me to believe that init(8) is being > adversely affected by the syscons history size option. > > If I can be of assistance in tracking down this problem, please > let me know. 0cicuta~(5)>strings /kernel | grep ___ | grep SC_HISTORY_SIZE ___options SC_HISTORY_SIZE=2118# number of history buffer lines 0cicuta~(6)>dc 2118 132 16 **p 4473216 q 0cicuta~(7)>uname -a FreeBSD cicuta.babolo.ru 4.3-STABLE FreeBSD 4.3-STABLE #2: Mon May 7 05:12:15 MSD 2001 [EMAIL PROTECTED]:/tmp/babolo/usr/src/sys/cicuta i386 As far as I remember with SC_HISTORY_SIZE=2200 switich to 132 column mode crashed FreeBSD of some old version. I think that reason for such behavior is big memory amount for history (non swapable?) -- @BABOLO http://links.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Should I worryy?
> I have a cdrom that defies logic: > > 1:14am harmony:/cdrom[51]> df /cdrom > Filesystem 1024-blocks UsedAvail Capacity Mounted on > /dev/acd0a 54 540 100%/cdrom > 1:14am harmony:/cdrom[52]> du /cdrom > 325460/cdrom/chujiten/data > 146 /cdrom/chujiten/gaiji > 325608/cdrom/chujiten > 1089 /cdrom/mac > 1077 /cdrom/win31 > 1425 /cdrom/win95 > 329203/cdrom > 1:14am harmony:/cdrom[53]> > > Anything to worry about? Notice du says 329M, whild df says 54k. > > This is 4.3-stable as of the first of the month. > > Warner > I'm interested in this... I've seen a problem like that in Linux (2.2.*) but never looked at each much... I don't know what happens in windows... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: _SC_NPROCESSORS_CONF
On Sun, May 20, 2001 at 01:56:55PM -0700, Arun Sharma wrote: > On Sun, May 20, 2001 at 04:57:17PM -0400, Andrew Gallatin wrote: > > > > Arun Sharma writes: > > > Single UNIX spec doesn't include the above sysconf(3) argument, but > > > many UNIX variants do. What's the BSD way of doing this ? > > > > How about the hw.ncpu sysctl? > > Any objections to a patch implementing > sysconf(_SC_NPROCESSORS_CONF) in terms of hw.ncpu ? http://www.freebsd.org/cgi/query-pr.cgi?pr=27489 -Arun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
