Re: variable size too large?
Thus spake Ferruccio Vitale [EMAIL PROTECTED]: I'm writing a little multithread program: in my thread function, I allocated a char variable of IP_MAXPACKET size; when I try to compile it, everything goes well, but when I run it, it dies, making a core file. Assume that: 1) the same code, with only one thread, linked to libc, runs normally 2) the same code, with a smaller variable size, linked to libc_r, runs normally 3) I tried to allocate two variables of 64000 bytes in this function (IP_MAXPACKET is equal to 65535), linked to libc_r and runs normally Where am I wrong? :)) Threads get much smaller stacks by default than monolithic processes. You should avoid making large allocations on the stack in order to avoid this problem. Use malloc()/free() instead. (You can kludge around the problem by using larger stack sizes, but you really shouldn't.) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
January-February 2003 FreeBSD Bi-Monthly Status Report
January-February 2003 Status Report Introduction: Another busy two months have passed in the FreeBSD project. With 5.0 released, attention is focusing on making it faster via more fine-grained locking, adding more high-end features like large memory (PAE) support for i386, and further progress on many other projects. FreeBSD 5.1 is expected to ship in late May or early June, with 5.2 following at the end of summer. A roadmap for the push to 5-STABLE is available at [2]http://www.freebsd.org/doc/en/articles/5-roadmap. Although the 5.x series isn't expected to fully stabilize until the 5.2 release, 5.1 promises to be an exciting release and a significant improvement over 5.0 in terms of speed and stability. Not to be forgotten, FreeBSD 4.8, the latest in the 4-STABLE series, is nearing release. Lots of last minute work is going into to it to deliver features like XFree86 4.3.0, Intel HyperThreading(tm) support, and of course many more bug fixes. Don't forget to support the FreeBSD vendors and developers by buying a copy of the CD set when it comes out!. Thanks, Scott Long, Robert Watson Bluetooth stack for FreeBSD (Netgraph implementation) URL: http://www.geocities.com/m_evmenkin/ URL: http://bluez.sf.net URL: http://sourceforge.net/projects/openobex/ Contact: Maksim Yevmenkin [EMAIL PROTECTED] I'm very pleased to announce that another release is available for download at http://www.geocities.com/m_evmenkin/ngbt-fbsd-20030305.tar.gz This release features new in-kernel RFCOMM implementation that provides SOCK_STREAM sockets interface. This makes old user-space RFCOMM daemon obsolete. People should not use old user-space RFCOMM daemon any longer. The release features new RFCOMM PPP daemon that supports DUN and LAN profiles. Note: PPP patch (support for chat scripts in -direct mode) is required for DUN support. Look for it in the mailing list archive or contact me directly. People with Bluetooth enabled cell phones can now use them to access Internet. The Bluetooth sockets layer has been cleaned up. People should not see any WITNESS complains with new code. Locking issues have been revisited and code in much better shape now, although it probably is not 100% SMP ready just yet. The code should work on SMP system anyway because sockets layer is still under Giant. The simple OBEX server and client (based on OpenOBEX library) is complete. OBEX File Push and OBEX File Transfer profiles work and have been tested with Sony Ericsson T68i cell phone and Bluetooth 3COM stack on Windows2K. It is now possible to send pictures, address book and calendar entries from the cell phone via Bluetooth. Minor bug in OpenOBEX library has been fixed and OPEX Put-Empty command now works. Due to changes in API userland tools must be in sync with the kernel. People should install new include files, recompile and reinstall all userland tools as part of upgrade. I'm sorry about that. _ BSDCon 2003 URL: http://www.usenix.org/events/bsdcon03/cfp/ Contact: Gregory Shapiro [EMAIL PROTECTED] The BSDCon 2003 Program Committee invites you to contribute original and innovative papers on topics related to BSD-derived systems and the Open Source world. Topics of interest include but are not limited to: * Embedded BSD application development and deployment * Real world experiences using BSD systems * Using BSD in a mixed OS environment * Comparison with non-BSD operating systems; technical, practical, licensing (GPL vs. BSD) * Tracking open source development on non-BSD systems * BSD on the desktop * I/O subsystem and device driver development * SMP and kernel threads * Kernel enhancements * Internet and networking services * Security * Performance analysis and tuning * System administration * Future of BSD Submissions in the form of extended abstracts are due by April 1, 2003. Be sure to review the extended abstract expectations before submitting. Selection will be based on the quality of the written submission and whether the work is of interest to the community. We look forward to receiving your submissions! _ Buffer Cache lockdown Contact: Jeff Roberson [EMAIL PROTECTED] Most of the file system buffer cache has been reviewed and protected. The vnode interlock was extended to cover some buffer flag fields so that a seperate interlock was not required. The global buffer queue data structures were locked and counters were converted to atomic ops. The BUF_*LOCK functions grew an interlock argument so that buffers could be safely removed from the vnode clean and dirty lists. The lockmgr lock
() REFILL.CO.KR @
Title: ´ëÇѹα¹ ´ëÇ¥ ¸®ÇÊ»çÀÌÆ® :: Refill.co.kr Á¤º¸Åë½ÅºÎ ±Ç°í »çÇ× ¹ý·ü Á¦ 50Á¶¿¡ ÀÇ°ÅÇÏ¿© Á¦¸ñ¿¡ (±¤°í)¶ó°í Ç¥±âÇÑ ±¤°í¸ÞÀÏÀ̸ç, ±ÍÇÏÀÇ ¸ÞÀÏÁÖ¼Ò´Â À¥ ¼ÇÎÁß ¾Ë°Ô µÈ °ÍÀ̸ç, eMail ÁÖ¼Ò ¿Ü¿¡ ±ÍÇÏÀÇ ¾î¶°ÇÑ Á¤º¸µµ °¡Áö°í ÀÖÁö ¾ÊÀ¸´Ï ¾È½ÉÇÏ½Ã±æ ¹Ù¶ø´Ï´Ù. º» ¸ÞÀÏÀº ¹ß¼ÛÀü¿ë ¸ÞÀÏÀÓÀ¸·Î, ¿øÄ¡ ¾ÊÀ¸½Ã¸é [¼ö½Å°ÅºÎ] ¹öÆ°À» Click ÇØ ÁÖ¼¼¿ä. If you would like to be removed from any of our distribution lists, please click 'REFUSE'. It will be handled promptly. Thank you. [REFUSE] ¡Ø °í°´ ¼ºñ½º ¹®ÀÇ : 02-3281- Copyright 1991-2002. Futech co,.Ltd. All right reserved. ¡Iì¹» ®&Þ±éݨ¥¶Ý¢jçH:+éì¹» ®&Þ~·nÇaiÉ ®È§¶¡Ü¨~Ø^ë,j
Re: increasing KVA_PAGES and broken pthreads
Intel x86 hardware allows windows of 4GB of virtual memory even if you have the PSE-36 and the PAE extensions with more the 4GB of physical memory. Sound a little like Intel's 64KB windows, but if I remember correctly, the 4GB does not have to be contiguous. It would require a true MMU such as those in the 64 bit architectures (AMD opteron, Intel ia64, sparc64) to simulataneously be able to use more than 4GB of RAM. So far the thought it is better to go with a true 64 MMU than take and get a flat address space than take the performance hit (, plus the memory loss for the much larger page table without much benefit) than try to shuffle in the 4GB windows. Check the thread on this topic in the archives. --Mark Tinguely. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
make world + kernel with gcc 3.2?
Well, I installed 4.7-RELEASE a few months ago, and soon after installed GCC3.2. Since then, everything has worked fine, but I want to upgrade to -STABLE or at least 4.8-RELEASE when it comes out. I don't expect HUGE problems with making world, but am I asking for trouble if I make a new kernel with GCC3.2? I've tried searching archives but can only find old, vague references. Hopefully someone here has experience. -- Avleen Vig Say no to cheese-eating surrender-monkeys Systems AdminFast, Good, Cheap. Pick any two. www.silverwraith.com Move BSD. For great justice! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: style of sysctl description strings
In message: [EMAIL PROTECTED] Giorgos Keramidas [EMAIL PROTECTED] writes: : Is there a reason for wrapping with '\n'? If yes, what would that be? : I'm only asking because it would make my life simpler if the sysctl : descriptions didn't have embedded newlines, and this is a good : opportunity to learn something too :-) Habit. There's a bunch of these with OLDCARD. They all should be 80 characters, however. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: make world + kernel with gcc 3.2?
Le Saturday 15 March 2003 18:14, Avleen Vig a écrit : I don't expect HUGE problems with making world, but am I asking for trouble if I make a new kernel with GCC3.2? good luck to you ! just have a look at the differences in the source code between current and stable to enable the compilation of current with gcc3 (FriBi -Stable will not compile with anything other than gcc 2.95) TfH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: make world + kernel with gcc 3.2?
On Sat, Mar 15, 2003 at 07:08:40PM +0100, Thierry Herbelot wrote: Le Saturday 15 March 2003 18:14, Avleen Vig a écrit : I don't expect HUGE problems with making world, but am I asking for trouble if I make a new kernel with GCC3.2? good luck to you ! just have a look at the differences in the source code between current and stable to enable the compilation of current with gcc3 (FriBi -Stable will not compile with anything other than gcc 2.95) TfH I assume the OP installed gcc3 from ports...in this case the gcc2.95 system compiler will still be installed as well. I'm pretty sure that a kernel build will explicitly use the system compiler, and buildworld/buildkernel certainly do (I believe buildworld actually builds a fresh copy of gcc2.95 then uses that to build the rest of the system). As Thierry says, trying to build -stable with gcc3 is probably doomed to failure. Scott -- === Scott Mitchell | PGP Key ID | Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines scott at fishballoon.org | 0xAA775B8B | -- Anon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
high resolution kernel profiling
I try to use high resolution kernel profiling today on FreeBSD 4.6 release. I use config -p -p MYKERNEL and later kgmon -Br to start the profiling. However, the file generate by gprof contains many negative numbers such as -0.00, -0.02 under the columns of self and descendents. Why is the case? Does it mean we should not use high resolution profiling at all? Thanks for any enlightment. -Zhihui -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
making CVS more convenient
Hi all, I've been planning to send this message to the developers mailing list, but it has mysteriously disappeared (and I haven't found yet its replacement). So here it goes. The idea is to support a cache repository (the one copied to a local machine by CVSup or CTM) transparently. So that the reads from directory will go from the local cache repository (and won't overstrain the remote server, and will be fast too), while the commits and other changes will go into the remote master repository. A similar thing may be achieved by checking the files out from the local repository and doing any modification command with option -d. But that's troublesome and inconvenient. This patch allows to deine the following configuration: # so far everything is as usual export CVS_RSH=Hssh1 export [EMAIL PROTECTED]:/home/ncvs # this is new export CVSROOTCACHE=/arch/cacheroot The value specified in CVSROOTCACHE is the local path to the cache repository. All the check-outs, updates, diffs etc. will be obtained from there. All the check-ins, tagging etc. will go into the master repository specified by CVSROOT. Naturally, to see these changes in the cache repository, it needs to be updated by some outside means such as CVSup or CTM. BTW, if there is no chance of conflict between updating the cache directories and check-outs from it, running check-outs with cvs -r (read-only repository) will make it faster. The patch (and the same description) are available from http://people.freebsd.org/~babkin/cvs/ (If anyone wonders, yes, I do plan to submit this patch to the CVS people). -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
