From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 17 07:27:31 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D012A106566B for ; Sun, 17 Jan 2010 07:27:31 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.210.171]) by mx1.freebsd.org (Postfix) with ESMTP id 863228FC0C for ; Sun, 17 Jan 2010 07:27:31 +0000 (UTC) Received: by yxe1 with SMTP id 1so1499732yxe.3 for ; Sat, 16 Jan 2010 23:27:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=mCu0/t4KWekck7b/ZxTaISnixGgqpHOK0INEABOw054=; b=GRAeGWzlIyJhZtUeJZkwADR2OfEeCVnb+mGVWLiHmyUZCOScATbE1/MRvI9MRNOC/U Az1V6qVbNNBeWzD2xh1VwsFfVIMSk3AmOLDjQhnJGLgzxcmawwxGADofWhcioXdbCGBt JbTdYQpR85QGUQNKpeQUbsTXGVfGuNkE/Bb4g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=gg00g85/QOKuodPihQ2AvOmutv5HnveXREa2xhOzhT12EYnyOpfdRSggjUBwKRqcdq RgwSZwG9+Jsn1FcUVkKzObUR79AHKG+9iWi/iJzWota1OaMvlQJDLRa8vVjA6n1aJCpM yvdZkhaEqSBNZN3Fh3/Cbbh9Jzt+f7ZxhH7bg= Received: by 10.91.19.35 with SMTP id w35mr867709agi.76.1263713249177; Sat, 16 Jan 2010 23:27:29 -0800 (PST) Received: from ?192.168.0.214? (deviant.freebsdgirl.com [173.8.183.73]) by mx.google.com with ESMTPS id 6sm1523114ywd.22.2010.01.16.23.27.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 16 Jan 2010 23:27:27 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: <20100115213546.GA39730@lpthe.jussieu.fr> Date: Sat, 16 Jan 2010 23:26:54 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100115213546.GA39730@lpthe.jussieu.fr> To: Michel Talon X-Mailer: Apple Mail (2.1077) Cc: hackers@freebsd.org Subject: Re: User error or awk bug? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2010 07:27:31 -0000 On Jan 15, 2010, at 1:35 PM, Michel Talon wrote: > awk doesn't use perl or python type regular expressions but much > simpler ones, called "extended". Your constructs are managed by Gnu = awk > with the --posix option only. The following achieves what you want in=20= > a simpler way >=20 >=20 > niobe% echo "/"|awk 'gsub(/\/+/,"/")' > / > niobe% echo "//"|awk 'gsub(/\/+/,"/")' > / Someone else on the gawk list provided me with the answer: awk doesn't = support POSIX regexp intervals, even though the spec says awk should. = His assumption was the fact that awk uses {} for separating control = statements, but I'm not sure if that's true or not. Thanks! -Garrett= From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 17 17:42:11 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA6E31065693; Sun, 17 Jan 2010 17:42:11 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9D8598FC08; Sun, 17 Jan 2010 17:42:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o0HHgBYB008072; Sun, 17 Jan 2010 17:42:11 GMT (envelope-from danger@freefall.freebsd.org) Received: (from danger@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o0HHgBf1008071; Sun, 17 Jan 2010 17:42:11 GMT (envelope-from danger) Date: Sun, 17 Jan 2010 17:42:11 +0000 From: Daniel Gerzo To: hackers@freebsd.org Message-ID: <20100117174211.GA99840@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.2.3i Cc: stable@freebsd.org, current@freebsd.org Subject: FreeBSD Quarterly Status Report for October - December 2009 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: monthly@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2010 17:42:11 -0000 Introduction This report covers FreeBSD related projects between October and December 2009. This is the last of the four reports covering 2009, which has shown to be a very important year for the FreeBSD Project. Besides other notable things, a new major version of FreeBSD, 8.0-RELEASE, has been released, while the release process for 7.3-RELEASE is soon to begin. Thanks to all the reporters for the excellent work! We hope you enjoy reading. Let us also take this opportunity to wish you all a happy and successful new year for 2010. Please note that the deadline for submissions covering the period between January and March 2010 is April 15th, 2010. __________________________________________________________________ Google Summer of Code * BSD-licensed iconv Projects * 3G USB support * Clang replacing GCC in the base system * FreeBSD TDM Framework * HAST -- Highly Available Storage * Intel XScale hwpmc(9) support * POSIX utmpx for FreeBSD * SUJ -- Journaled SoftUpdates * The webcamd deamon FreeBSD Team Reports * FreeBSD Bugbusting Team * FreeBSD Release Engineering * The FreeBSD Foundation Status Report Network Infrastructure * bwn(4) -- Broadcom Wireless driver * IP Payload Compression Protocol support * Ralink wireless RT2700U/2800U/3000U run(4) USB driver * Syncing pf(4) with OpenBSD 4.5 * Wireless mesh networking Kernel * CAM-based ATA implementation * Group Limit Increase * NFSv4 ACL support * V4L support in Linux emulator Documentation * The FreeBSD German Documentation Project * The FreeBSD Hungarian Documentation Project * The FreeBSD Spanish Documentation Project Architectures * Flattened Device Tree for embedded FreeBSD * FreeBSD/ia64 * FreeBSD/mips * FreeBSD/sparc64 Ports * Chromium web browser * Ports Collection * VirtualBox on FreeBSD Vendor / 3rd Party Software * DAHDI (Zaptel) support for FreeBSD * NVIDIA amd64 driver Miscellaneous * AsiaBSDCon 2010 -- The BSD Conference * BSDCan 2010 -- The BSD Conference * meetBSD 2010 -- The BSD Conference * The FreeBSD Forums Userland utilities * BSD-licensed text processing tools __________________________________________________________________ 3G USB support Contact: Andrew Thompson Recently, a bunch of new device IDs have been added for the u3g(4) cellular wireless driver; the list should be comparable now with other operating systems around. A lot of these devices have a feature where the unit first attaches as a disk or CD-ROM that contains the Win/Mac drivers. This state should be detected by the u3g driver and the usb device is sent a command to switch to modem mode. This has been working for quite some time but as it is implemented differently for each vendor I am looking for feedback on any units where the auto switchover is not working (or the init is not recognized at all). Please ensure you are running an up to date kernel, like r201681 or later from 9.0-CURRENT, or 8-STABLE after the future merge of this revision. __________________________________________________________________ AsiaBSDCon 2010 -- The BSD Conference URL: http://2010.AsiaBSDCon.org/ Contact: AsiaBSDCon Information AsiaBSDCon is a conference for users and developers on BSD based systems. AsiaBSDCon is a technical conference and aims to collect the best technical papers and presentations available to ensure that the latest developments in our open source community are shared with the widest possible audience. The conference is for anyone developing, deploying and using systems based on FreeBSD, NetBSD, OpenBSD, DragonFlyBSD, Darwin and MacOS X. The next conference will be held at the Tokyo University of Science, Tokyo, Japan, on 11th to 14th March, 2010. For more detailed information, please check the conference web site. __________________________________________________________________ BSD-licensed iconv URL: http://p4db.FreeBSD.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2 009/gabor_iconv Contact: Gábor Kövesdán Good compatibility has been ensured and there are only few pending items that have to be reviewed/enhanced. Recently, an enhancement has been completed, which makes it possible to accomplish better transliteration, just like in the GNU version. An initial testing patch is expected at the beginning of February. Open tasks: 1. Enhance conversion tables to make use of enhanced transliteration. 2. A performance optimization might be done later. __________________________________________________________________ BSD-licensed text processing tools URL: http://p4db.FreeBSD.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2 008/gabor_textproc Contact: Gábor Kövesdán As 8.0-RELEASE is out, BSD bc/dc can be now committed to 9.0-CURRENT. We are only waiting for an experimental package building to make sure there are no regressions after this change. BSD grep is complete but it cannot be integrated yet because of some regex library issues. We need first a fast and modern regex library so that we can change to BSD grep. BSD sort has few incomplete features and needs some performance review. Open tasks: 1. Commit BSD bc/dc. 2. Implement remaining features for sort and optimize performance. __________________________________________________________________ BSDCan 2010 -- The BSD Conference URL: http://www.BSDCan.org/2010/ Contact: BSDCan Information BSDCan, a BSD conference held in Ottawa, Canada, has quickly established itself as the technical conference for people working on and with 4.4BSD based operating systems and related projects. The organizers have found a fantastic formula that appeals to a wide range of people from extreme novices to advanced developers. BSDCan 2010 will be held on 13-14 May 2010 at the University of Ottawa, and will be preceded by two days of Tutorials on 11-12 May 2010. There will be related events (of a social nature, for the most part) on the day before and after the conference. Please check the conference web site for more information. __________________________________________________________________ bwn(4) -- Broadcom Wireless driver URL: http://p4db.FreeBSD.org/depotTreeBrowser.cgi?FSPC=//depot/user/weongyo/ wireless/src/sys/dev/bwn&HIDEDEL=NO Contact: Weongyo Jeong bwn(4) is replacing bwi(4) driver for to the following reasons: * Uses latest v4 firmware image instead of using the much older v3 firmware. In this way, we have some great benefits, such as support for N-PHYs and the fixes of various earlier firmware bugs. * Supports PIO mode. This is important because -- as you might know -- the Broadcom Wireless Driver is created by reverse-engineering so some pieces of hardware might not work with DMA operations. * Supports 64 bit DMA operations. * Separates bwi(4) driver into two parts; siba(4) driver and bwn(4) driver. Many Broadcom wireless and NIC devices are based on Silicon Sonics Backplane, such as bwi(4), which implemented the SIBA operations internally. This resulted in code duplication as other drivers had to implement their own routines to deal with SIBA. In the case of bwn(4), these two parts have been separated and implemented in their own kernel modules to avoid this problem and help further development by providing a standalone siba(4) driver. Currently, it is tested on big/little endian machines and 32/64-bit DMA operation with STA mode. A major patch for siba(4) is being reviewed before committing into 9.0-CURRENT. Open tasks: 1. MESH/IBSS/HOSTAP mode is not supported. 2. LP/N PHYs are not supported. __________________________________________________________________ CAM-based ATA implementation Contact: Alexander Motin Contact: Scott Long Existing ata(4) infrastructure, which has been around many years, has various problems and limitations when compared to modern controllers/device support. Although the CAM subsystem (used for SCSI) is almost as old as ata(4), it is more eligible to solve the current problems. To reduce code duplication and better support border cases such as ATAPI and SAS, we have started to develop a new CAM based ATA implementation. As such, CAM infrastructure has been extended to support different transports. New transport has been implemented to support PATA/SATA buses. To support ATA disks, a new CAM driver (ada) has been written. ATAPI devices are supported by existing SCSI drivers cd, da, sa, etc. To support SATA port-multipliers another new CAM driver (pmp) has been written. To support most featured and widespread SATA controllers, new drivers ahci(4) and siis(4) have been developed. To support legacy ATA controllers, a kernel option ATA_CAM has been added. When used, it makes all ata(4) controllers directly available to CAM, deprecating ata(4) peripheral drivers and external APIs. To make this possible, ata(4) code has been heavily refactored, making controller driver API stricter. Command queuing support gives new ATA implementation up to double performance benefit on some workloads, with 20-30% improvement quite usual. SATA Port Multiplier support makes it easy to build fast and cheap storage with huge capacities, by using dozens of SATA drives in one system or external enclosures, Some of that code has been presented in the recently released FreeBSD 8.0-RELEASE but 8-STABLE now includes a much improved version. Open tasks: 1. Improve timeout and transport error recovery. 2. Improve hot-plug support. 3. Find and fix any show stoppers for legacy ata(4) deprecation. 4. Write a new, more featured driver for Marvell SATA controllers (specifications desired). 5. Write SAS-specific transport and drivers for SAS HBAs (specifications desired). SAS controllers can support SATA devices and multipliers, so it should fit nicely into the new infrastructure. __________________________________________________________________ Chromium web browser URL: http://chromium.jaggeri.com URL: http://www.links.org/?p=724 Contact: Ben Laurie Chromium is a Webkit-based web browser that is largely BSD licensed. It has been ported from Linux to FreeBSD in October and we have been posting patches and test builds periodically since then. Chromium works well on FreeBSD -- it is very fast and stable but there are a handful of rough edges that need to be polished up. Two remaining bugs should probably be fixed before releasing a chromium-devel port. We are looking for volunteers to test and maintain this port to make this BSD browser a viable option on FreeBSD desktop systems. Open tasks: 1. Fix sporadic rendering freezes. 2. Fix JavaScript interpreter, v8, on i386 architecture. __________________________________________________________________ Clang replacing GCC in the base system URL: http://wiki.FreeBSD.org/BuildingFreeBSDWithClang Contact: Ed Schouten Contact: Roman Divacky Contact: Brooks Davis Contact: Pawel Worach We are again able to build bootable i386/amd64 kernel. Nathan Whitehorn committed a fix to FreeBSD, which enabled LLVM/clang to work mostly fine on PowerPC. There is some preliminary testing of LLVM/clang on ARM and MIPS being done. We have some ideas about sparc64 support which are currently being investigated. You are welcome to contact us if you want to help. Since the last report, a lot has happened mostly in the area of C++; clang is currently able to build working groff, gperf and devd, i.e. all of the C++ apps we have in base. Unfortunately, it still cannot build any of the C++ libraries -- two of them are missing builtins and libstdc++ is broken for other reasons. Not much happened in the clangbsd branch as we cannot upgrade the clang/llvm there because we are blocked by a bug that requires using newer assembler than we can ship. This might be solved by either fixing this (short term) or using llvm-mc instead of GNU as for assembling (longer term). Open tasks: 1. Help with ARM/MIPS/sparc64. 2. More testing of clang on 3rd party apps (ports). 3. Discussion on integrating LLVM/clang into FreeBSD. __________________________________________________________________ DAHDI (Zaptel) support for FreeBSD URL: http://www.mail-archive.com/asterisk-dev@lists.digium.com/msg39598.html URL: http://svn.digium.com/svn/dahdi/freebsd/trunk/ Contact: Max Khon A DAHDI support module for FreeBSD has been created in the official Asterisk SVN repository. The following drivers are currently ported: * main DAHDI driver * all software echo cancellation drivers * dahdi_dynamic * dahdi_dynamic_loc The following HW drivers are currently ported and tested: * wct4xxp, including HW echo cancellation support (Octasic) + Digium TE205P/TE207P/TE210P/TE212P: PCI dual-port T1/E1/J1 + Digium TE405P/TE407P/TE410P/TE412P: PCI quad-port T1/E1/J1 + Digium TE220: PCI-Express dual-port T1/E1/J1 + Digium TE420: PCI-Express quad-port T1/E1/J1 * wcb4xxp + Digium B410: PCI quad-port BRI + Junghanns.NET HFC-2S/4S/8S duo/quad/octoBRI + OpenVox B200P/B400P/B800P + BeroNet BN2S0/BN4S0/BN8S0 Open tasks: 1. The port for dahdi_dynamic_eth and dahdi_dynamic_ethmf is underway. 2. More HW drivers need to be ported. 3. Please let me know if you can provide remote access with serial console to any box with ISDN/T1/E1 HW not currently supported by DAHDI for FreeBSD but supported by DAHDI for Linux. I am also interested in porting drivers for FXO/FXS cards. Please let me know if you can provide a remote access or donate a card. __________________________________________________________________ Flattened Device Tree for embedded FreeBSD URL: http://wiki.FreeBSD.org/FlattenedDeviceTree URL: http://p4db.FreeBSD.org/changeList.cgi?FSPC=//depot/projects/fdt/... Contact: Rafal Jaworowski The purpose of this project is to provide FreeBSD with support for the Flattened Device Tree (FDT) technology, the mechanism for describing computer hardware resources, which cannot be probed or self enumerated, in a uniform and portable way. The primary consumers of this technology are embedded FreeBSD platforms (ARM, AVR32, MIPS, PowerPC), where a lot of designs are based on similar chips but have different assignment of pins, memory layout, addresses bindings, interrupts routing and other resources. Current state highlights: * Environment, supported tools + Integrated device tree compiler (dtc) and libfdt into FreeBSD userspace, kernel and loader build * loader(8) + Full support for device tree blob handling + Load, traverse, modify (including add/remove) device tree nodes and properties + Pass the device tree blob to the kernel + Both ARM and PowerPC loader(8) supported * Kernel side FDT support (common) + Developed OF interface for FDT-backed platforms + ofw_bus I/F (and /dev/openfirm) available with FDT + Integrated FDT resources representation with newbus (fdtbus and simplebus drivers) * PowerPC kernel (Freescale MPC85XX SOC) + MPC8555CDS and MPC8572DS successfully converted to FDT conventions * ARM kernel (Marvell Orion, Kirkwood and Discovery SOC) + Work in progress on integrating FDT infrastructure with ARM platform code Work on this project has been sponsored by the FreeBSD Foundation. Open tasks: 1. Complete missing pieces for PowerPC (PCI bridge driver conversion to FDT). 2. Complete ARM support. 3. Merge to SVN. __________________________________________________________________ FreeBSD Bugbusting Team URL: http://www.FreeBSD.org/support.html#gnats URL: http://wiki.FreeBSD.org/BugBusting URL: http://people.FreeBSD.org/~linimon/studies/prs/ URL: http://people.FreeBSD.org/~linimon/studies/prs/recommended_prs.html URL: http://people.FreeBSD.org/~linimon/recommended_subscribers.txt Contact: Gavin Atkinson Contact: Mark Linimon Contact: Remko Lodder Contact: Volker Werth Bugmeister Gavin Atkinson has now been granted a src commit bit, and is now starting to work through some of our backlog. The list of PRs recommended for committer evaluation by the Bugbusting Team continues to receive new additions; however, it has not yet achieved high visibility. (This list contains PRs, mostly with patches, that the Bugbusting Team consider potentially ready to be committed as-is, or are probably trivially resolved in the hands of a committer with knowledge of the particular subsystem.) One of the suggestions at the Cambridge devsummit was to create a way for people to be emailed the weekly summary that is posted to freebsd-bugs@, and this has now been implemented. Please email linimon@FreeBSD.org to ask to be added to the recommended_subscribers.txt file (see above). We continue to classify PRs as they arrive, adding 'tags' to the subject lines corresponding to the kernel subsystem involved, or man page references for userland PRs. These tags, in turn, produce lists of PRs sorted both by tag and by manpage. At this point most of the PRs that refer to supported versions of FreeBSD have been converted, and we are keeping up as new ones come in. We hope that this is making it easier to browse the PR database. The overall PR count jumped to over 6,200 during the 8.0-RELEASE release cycle but seems to have stabilized at around 6,100. As in the past, we have a fairly good clearance rate for ports PRs but much less so for other PRs. (Partly this is due to the concept of individual ports having 'maintainers'.) Open tasks: 1. Try to find ways to get more committers helping us with closing PRs that the team has already analyzed. __________________________________________________________________ FreeBSD Release Engineering URL: http://www.FreeBSD.org/releng/ Contact: Release Engineering Team The Release Engineering Team announced FreeBSD 8.0-RELEASE on November 26th, 2009. With 8.0-RELEASE completed planning has begun for 7.3-RELEASE. The schedule has been set with the release date planned for early March 2010. The Release Engineering Team would like to thank George Neville-Neil (gnn@) for his service on the team. George continues to work with the FreeBSD Project but has stepped down from the Release Engineering Team to focus on other activities. __________________________________________________________________ FreeBSD TDM Framework Contact: Rafal Czubak Contact: Michal Hajduk Important changes regarding FreeBSD TDM Framework since the last status report: * Fully functional TDM controller driver for Marvell Kirkwood and Discovery SoCs. * Working voiceband channel character device driver. * Working Si3215, Si3050 codec drivers on corresponding FXS, FXO ports. * Demo application, which is capable of manipulating voiceband channel and codec state, starting/stopping channel transfers and echoing on single channel. * Preliminary version of driver bridging the voiceband infrastructure with Zaptel/DAHDI. Open tasks: 1. Improve various issues regarding working drivers and demo application. 2. Test Si3050 codec driver operation with PSTN. 3. Fully integrate voiceband infrastructure with Zaptel/DAHDI telephony hardware drivers. __________________________________________________________________ FreeBSD/ia64 Contact: Marcel Moolenaar Work continues on our ia64 port. Many recent commits to help improve stability have been made to 9.0-CURRENT and MFCed to 8-STABLE. Due to interest from a very motivated user, package builds have been restarted for ia64-8. This is primarily intended as a QA step to discover and fix bugs on ia64, rather than to create packages for upload. Based on the above, Mark Linimon documented how to add more architectures to the package cluster scheduler. (This work will also be of use in an upcoming effort to start powerpc package builds.) There are currently 3 ia64 machines online and building packages. The machines seem stable as long as multiple simultaneous package builds are not attempted, in which case they get machine checks. This is puzzling, since other heavy workloads seem stable on the same machines. Open tasks: 1. Continue to try to understand why multiple simultaneous package builds bring the machines down. 2. Upgrade the firmware on the two machines at Yahoo! to see if that helps the problem. 3. Configure a fourth machine that has been made available to us. 4. Figure out the problems with the latest GCC port on ia64. 5. We can use some help with reviewing the ia64 platform pages and bringing them up-to-date. __________________________________________________________________ FreeBSD/mips URL: http://www.FreeBSD.org/projects/mips/index.html URL: http://wiki.FreeBSD.org/FreeBSD/mips Contact: The FreeBSD/mips mailing list Contact: Warner Losh The base/projects/mips branch has been merged into 9.0-CURRENT. The merge is complete and the sanity tests have passed. The code has booted on both a Ubiquiti RouterStation (big endian) as well as in gxemul (little endian). The branch lived for one year, minus a day, and accumulated much work: * A new port to the Atheros AR71xx series of processors. This port supports the RouterStation and RouterStation PRO boards from Ubiquiti. Other boards should work with minimal tweaking. This port should be considered as nearing production quality, and has been used extensively by the developers. The primary author of this port is Oleksandr Tymoshenko (gonzo@FreeBSD.org). * A new port to the SiByte BCM1250 SoC on the BCM91250 evaluation board (aka SWARM). This port is reported to be stable, but this hardware is a little old and not widely available. The primary author of this port is Neel Natu (neel@FreeBSD.org). Only one core is presently supported. * A port, donated by Cavium, to their Octeon and Octeon plus series of SoC (CN3xxx and CN5xxx). This code is preliminary, supporting only a single core right now. It has been lightly tested on the CN3860 evaluation board only in 32-bit mode. Warner Losh (imp@FreeBSD.org) has been driving the efforts to get this code into the tree. * A port, donated by RMI, to their XLR series of SoCs. This port is single core only, as well. The code reaches multi-user but should be considered beta quality for the moment. Randal Stewart (rrs@FreeBSD.org) has been driving the efforts to integrate this into the tree. * Preliminary support for building a mips64 kernel from this source base. More work is needed here, but at least two kernels successfully build in 64-bit mode (OCTEON1 and MALTA64). * Very early support for N32 and N64 ABIs * Support for booting compressed kernels has been added (gonzo@). * Improved support for debugging * Improved busdma and bus_space support * Many bug fixes * More types of MIPS cores are recognized * Expanded cache handling for newer processors * Beginning of a port to the alchemy au1XXX cpus is present, but experimental. * Work on SMP is underway to support multicore processors like the SiByte, Octeon and XLR processors. The development branch had been updated incorrectly several times over the past year, and the damage was too much to repair. We have retired the branch and will do further mips development in 9.0-CURRENT for the time being. If you have a checked out tree, the suggested way to update the projects/mips tree you have is to do a "svn switch svn://svn.FreeBSD.org/base/head" in that tree. I would like to thank everybody that has contributed time, code or hardware to make FreeBSD/mips better. As development proceeds, I will keep posting updates. In addition, I hope to have some mini "how-to" wiki pages done for people that want to try it out. Open tasks: 1. We are still investigating how feasible merging all this work into 8-STABLE will be, as it represents a huge leap forward in code stability and quality. __________________________________________________________________ FreeBSD/sparc64 Contact: Marius Strobl The main thing that has taken place since the last Status Report is that I have gotten to the bottom of the remaining PCI problems with Sun Fire V215/V245 and support for these has been completed and since r202023 now is part of 9.0-CURRENT. With some luck it will also be part of the upcoming 7.3-RELEASE. Some other news: * Two bugs in the NFS server causing unaligned access and thus panics on sparc64 and all other architectures with strict alignment requirements (basically all Tier-2 ones) have been fixed. There likely will be a 8.0-RELEASE Erratum Notice released for these. * FreeBSD has been adopted to the changed firmware of newer Sun Fire V480 (those equipped with version 7 Schizo bridges) and has been reported to now run fine on these. The necessary change will be part of 7.3-RELEASE. Unfortunately, using the on-board NICs in older models of Sun Fire V480 (at least those equipped with version 4 Schizo bridges) under FreeBSD still leads to the firmware issuing a FATAL RESET due to what appears to be a CPU bug, which needs to be worked around. * Work on supporting Sun Fire V1280 has been started but still is in very early stages. Unfortunately, these are rather quirky machines. After solving two firmware specialties the loader now is able to boot the kernel but the latter currently still fails in early cycles as trying to take the trap table over from the firmware results in a solid hang. __________________________________________________________________ Group Limit Increase Contact: Brooks Davis Historically, FreeBSD has limited the number of supplemental groups per process to 15 (NGROUPS_MAX was incorrectly declared to be 16). In FreeBSD 8.0-RELEASE we raised the limit to 1023, which should be sufficient for most users and will be acceptably efficient for incorrectly written applications that statically allocate NGROUPS_MAX + 1 entries. Because some systems such as Linux 2.6 support a larger group limit, we have further relaxed this restriction in 9.0-CURRENT and made kern.ngroups a tunable value, which supports values between 1023 and INT_MAX - 1. We plan to merge this to 8-STABLE before 8.1-RELEASE. __________________________________________________________________ HAST -- Highly Available Storage URL: http://lists.FreeBSD.org/pipermail/freebsd-announce/2009-October/001279 .html Contact: Pawel Jakub Dawidek HAST software will provide synchronous replication of any GEOM provider (eg. disk, partition, mirror, etc.) or file from one FreeBSD machine (primary node) to another one (secondary node). Because data is replicated at the block level neither applications, nor file systems have to be modified to take advantage of this functionality. The functionality that HAST software will provide is very similar to the functionality provided by the DRBD project for Linux. The HAST project is sponsored by the FreeBSD Foundation. Work is progressing well; first milestone was reached in December 2009 and the expected project completion date is January 31, 2010. Check out FreeBSD mailing lists for patches to test in February and wish me good luck! And by the way, do not forget to donate to the FreeBSD Foundation, as your donations make projects like this possible. Thank you! __________________________________________________________________ Intel XScale hwpmc(9) support Contact: Rui Paulo Preliminary Hardware Performance Counter support for Intel XScale ARM processors was committed to FreeBSD 9.0-CURRENT in December. This adds another supported architecture to hwpmc(9). The system works for basic performance counter usage but more advanced usage scenarios, namely callchain support, are not yet implemented. __________________________________________________________________ IP Payload Compression Protocol support Contact: Bjoern A. Zeeb One of the longer outstanding feature problems with the FreeBSD IP security stack, broken IP Payload Compression Protocol (IPcomp) support, has been fixed. While working on the fix, various problems had been identified: * Problems with the IPcomp packet handling in IPsec. * opencrypto compression handling and deflate implementation limitations. These were debugged using DTrace SDT probes. * Problems due to an outdated version of zlib used in some parts of the network stack and by the opencrypto framework. Patches for all but the zlib support have been committed to 9.0-RELEASE and merged to all supported stable branches including 6-STABLE. Special thanks to Eugene Grosbein for helping with testing. Open tasks: 1. Fix ng_deflate so that we can make use of Kip Macy's work on an up-to-date unified zlib version in the kernel, which would also fix the last occasional IPcomp hiccups. __________________________________________________________________ meetBSD 2010 -- The BSD Conference URL: http://www.meetBSD.org Contact: meetBSD Information The meetBSD conference is an annual event gathering users and developers of the BSD operating system family, mostly FreeBSD, NetBSD and OpenBSD. Afer the special California edition, meetBSD Wintercamp in Livigno, this year we are back to Krakow, Poland. In 2010, meetBSD will be held on 2-3 July at the Jagiellonian University. See the conference main web site for more details. __________________________________________________________________ NFSv4 ACL support URL: http://wiki.FreeBSD.org/NFSv4_ACLs Contact: Edward Tomasz Napierala Native NFSv4 ACL support in ZFS and UFS has been committed into 9.0-CURRENT. It is expected to be MFCed in order to make it into FreeBSD 8.1-RELEASE. Open tasks: 1. Support for NFSv4 ACLs in tar(1). 2. MFC. __________________________________________________________________ NVIDIA amd64 driver URL: http://www.nvnews.net/vbulletin/showthread.php?t=142120 Contact: John Baldwin NVIDIA has released the first BETA version of its graphics drivers for FreeBSD/amd64. Note that this driver will work on FreeBSD versions 7.3-RELEASE or 8.0-RELEASE and later. It also works on very recent versions of 7.2-STABLE. More details are provided in the official release announcement. __________________________________________________________________ Ports Collection URL: http://www.FreeBSD.org/ports/ URL: http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributing-ports/ URL: http://portsmon.FreeBSD.org/index.html URL: http://www.FreeBSD.org/portmgr/index.html URL: http://tinderbox.marcuscom.com Contact: Mark Linimon Most of the recent activity has been dealing with the 8.0-RELEASE process. As an experiment, we have tried to decouple the ports QA timeline as much as possible from the src QA timeline. Although this meant that the impact on people actively maintaining and using ports has been much less than in previous releases, it still has not solved the problem of the release going out with a stale set of packages. We are still trying to come up with a better solution for the problem. The ports count is over 21,000. The PR count jumped to over 1,000 but is now back to around 950. We are currently building packages for amd64-6, amd64-7, amd64-8, i386-6, i386-7, i386-8, i386-9, ia64-8, sparc64-7, and sparc64-8. This represents the addition of i386-9 and ia64-8 since the last report. There has been some discussion of when to drop regular package builds for 6.X but no decision has been made yet. The cluster and the port managers are struggling to keep up with so many branches being active all at the same time. Mark Linimon continues to make progress on the cluster nodes. Almost every node that does not have a hard disk failure is now online. In addition, he continues to make progress debugging problems that occasionally take nodes offline. The next task is to characterize the overall performance of the build cluster. The question has been asked of us, "what would it take to speed up package builds?" There is no one simple answer. It is not merely a matter of having a larger number of package building machines, so before asking for funding we first need to identify the current bottlenecks. While we are starting to understand the problems on the nodes, the problems on the dispatch machine itself are much harder. Complicating the matter is that there are several periodic processes (ZFS backup, ZFS expiration, and errorlog compression, among others) that can combine to slow that machine significantly. The simultaneous interaction of all these is proving difficult to quantify. Between Pav Lucistnik and Martin Wilke, many more experimental ports runs have been completed and committed. We have added 3 new committers since the last report, and 1 older one has rejoined us. Open tasks: 1. We are still trying to set up ports tinderboxes that can be made available to committers for pre-testing. 2. Most of the remaining ports PRs are "existing port/PR assigned to committer". Although the maintainer-timeout policy is helping to keep the backlog down, we are going to need to do more to get the ports in the shape they really need to be in. 3. Although we have added many maintainers, we still have more than 4,700 unmaintained ports. (See, for instance, the list on portsmon. The percentage remains steady at just over 22%.) We are always looking for dedicated volunteers to adopt at least a few unmaintained ports. As well, the packages on amd64 and especially sparc64 lag behind i386, and we need more testers for those. __________________________________________________________________ POSIX utmpx for FreeBSD URL: http://lists.FreeBSD.org/pipermail/freebsd-current/2010-January/014893. html URL: http://www.opengroup.org/onlinepubs/9699919799/functions/endutxent.html URL: http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/lib/libc/gen/utmpx.c URL: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/ port/gen/getutx.c Contact: Ed Schouten On January 13, I removed the utmp user accounting database and replaced it with a new POSIX utmpx implementation. Unfortunately, the upgrade path is a bit complex, because the utmp interface provided almost no library interface to interact with the database files. This change may have caused some regressions. Some ports may fail to build, while there could also be bugs in the library functions. Open tasks: 1. Get a list of broken ports. 2. Fix them to comply to standards. 3. Send patches upstream. __________________________________________________________________ Ralink wireless RT2700U/2800U/3000U run(4) USB driver URL: http://forums.FreeBSD.org/showthread.php?t=7562 Contact: Akinori Furukoshi The run(4) driver brings support for Ralink RT2700U/2800U/3000U USB wireless devices. For detailed information and list of all the supported devices, please see the above mentioned URL. The source code has been imported to the USB P4 repository on January 10, 2010 (172906). Open tasks: 1. Solve USB_TIMEOUT problem when sending beacons, and/or confirm which chipsets supports AP mode if all of them do not support it. 2. Read TX stats for AMRR on AP mode, and/or confirm which chipsets supports AP mode if all of them do not support it. 3. Maintain the code. __________________________________________________________________ SUJ -- Journaled SoftUpdates URL: http://jeffr_tech.livejournal.com/ Contact: Jeff Roberson I have been adding a small intent log to SoftUpdates to eliminate the requirement for fsck after an unclean shutdown. This work has been funded by Yahoo!, iXsystems, and Juniper. Kirk McKusick has been aiding me with design critiques and helping me better understand SoftUpdates. Extensive testing by myself and Peter Holm has yielded a stable patch. Current users are encouraged to follow the instructions posted to the current@FreeBSD.org mailing list to verify stability in your own workloads. Updates are forthcoming and it is expected to be merged to 9.0-CURRENT before the end of January. Ports to older versions of FreeBSD will be available in SVN under alternate branches. Official backports will be decided by re@ when 9.0-CURRENT is stable. The changes are fully backwards and forwards compatible as there are very few metadata changes to the filesystem. The journal may be enabled or disabled on existing FFS filesystems using tunefs(8). The log consumes 64 MB of space at maximum and fsck time is bounded by the size of the log rather than the size of the filesystem. Other details are available in my technical journal. __________________________________________________________________ Syncing pf(4) with OpenBSD 4.5 URL: http://svn.FreeBSD.org/viewvc/base/user/eri/pf45/ URL: http://svn.FreeBSD.org/base/user/eri/pf45/head/ Contact: Ermal Luçi This import is based on OpenBSD 4.5 state of pf(4). It includes many improvements over the code currently present in FreeBSD. The actual new feature present in pf45 repository is support for divert(4), which should allow tools like snort_inline to work with pf(4) too. Currently, the pf(4) import is considered stable with normal kernel, as well as VIMAGE enabled kernels. Open tasks: 1. pflow(4)/pflog(4)/pfsync(4) need to be made VIMAGE aware. 2. More regression testing is needed. __________________________________________________________________ The FreeBSD Forums URL: http://forums.FreeBSD.org/ Contact: FreeBSD Forums Admins Contact: FreeBSD Forums Moderators Since the last report we have seen a growth of 2,000 users on our forums resulting in approximately 10,000 registered users at this time. The posts count is about to reach 60,000 soon, which are contained in almost 9,000 threads. The sign-up rate still hovers between 50-100 each week. The total number of visitors (including 'guests') is currently hard to gauge, but is likely to be a substantial multiple of the registered userbase. New topics and posts are actively 'pushed out' to search engines. This in turn makes the forums show up in search results more and more often, making it a valuable and very accessible source of information for the FreeBSD community. One of the contributing factors to the forums' success is their 'BSD-style' approach when it comes to administration and moderation. The forums have a strong and unified identity and are very actively moderated, spam-free, and with a core group of very active and helpful members, dispensing many combined decades' worth of knowledge to starting, intermediate and professional users of FreeBSD. __________________________________________________________________ The FreeBSD Foundation Status Report URL: http://www.FreeBSDFoundation.org/ URL: https://twitter.com/freebsdfndation Contact: Deb Goodkin Despite a difficult economy, we more than doubled our number of donors, we raised $269K towards our goal of $300K, and with an improved economy hope to surpass that this year. We have funded two new projects. One is the Flattened Device Tree by Rafal Jaworowski. And, the second one is Highly Available Storage by Pawel Jakub Dawidek. We continued supporting the New Console Driver by Ed Schouten and Improvements to the FreeBSD TCP Stack by Lawrence Stewart. We also purchased equipment for several projects. We have big plans for the new year! We are going to significantly increase our project development and equipment spending. Stay tuned for a project proposal submission announcement soon. We just announced that we are accepting travel grant applications for AsiaBSDCon and will be accepting them soon for BSDCan. And, we are working on infrastructure projects to beef up hardware for package-building, network-testing, etc. Read more about how we supported the project and community by reading our end-of-year newsletter available at http://www.FreeBSDFoundation.org/press/2009Dec-newsletter.shtml. We are fund-raising for 2010 now! Find out more at http://www.FreeBSDFoundation.org/donate/. __________________________________________________________________ The FreeBSD German Documentation Project URL: http://doc.bsdgroup.de Contact: Johann Kois Contact: Benedict Reuschling Contact: Martin Wilke We are happy to announce that Benedict Reuschling is now free from mentorship and can commit to the documentation tree on his own. Since the last status report, the German Documentation Team has chased updates to various sections of the FreeBSD Handbook, FAQ and the German website. Many handbook pages have been updated to the latest version, including chapters about configuration, disks, kernel configuration, printing, multimedia and virtualization. We require help from volunteers that are willing to contribute bug fixes or translations. The following documents need active maintainership and are a good training ground for those willing to join the translation team: * arch-handbook/jail/ * developers-handbook/I10n/ * developers-handbook/policies/ * developers-handbook/sockets/ (translation from scratch) * handbook/firewalls/ (translation from scratch) * handbook/security/ * porters-handbook/ Open tasks: 1. Read the translations and report bugs to de-bsd-translators@de.FreeBSD.org. 2. Translate articles or missing sections listed above. __________________________________________________________________ The FreeBSD Hungarian Documentation Project URL: http://www.FreeBSD.org/hu/ URL: http://www.FreeBSD.org/doc/hu/ URL: http://wiki.FreeBSD.org/HungarianDocumentationProject URL: http://p4web.FreeBSD.org/@md=d&cd=//depot/projects/docproj_hu/&c=aXw@// depot/projects/docproj_hu/?ac=83 Contact: Gábor Kövesdán Contact: Gábor Páli In the last months, no new translation has been added. Lacking human resources, we can only manage to keep the existing documentation and web page translations up to date. If you are interested in helping us, please contact us via the the email addresses noted above. Open tasks: 1. Translate release notes. 2. Add more article translations. __________________________________________________________________ The FreeBSD Spanish Documentation Project URL: http://www.FreeBSD.org/doc/es/articles/fdp-es/ URL: https://listas.es.FreeBSD.org/mailman/listinfo/doc Contact: Gábor Kövesdán There is one article translation pending review. Apart from this, neither translations nor maintainance work have been done. We need more volunteers, mostly translators but we are glad to have more reviewers, as well. One can join by simply subscribing to the translators' mailing list where all the work is done. Open tasks: 1. Update Handbook translation. 2. Update webpage translation. 3. Add more article translations. __________________________________________________________________ The webcamd deamon URL: http://www.selasky.org/hans_petter/video4bsd/ Contact: Hans Petter Selasky The webcamd daemon enables hundreds of different USB based webcam devices to be used under the FreeBSD-8/9 operating system. The webcam daemon is basically an application, which is a port of Video4Linux USB webcam drivers into userspace on FreeBSD. The daemon currently depends on libc, pthreads, libusb and the VIDEO4BSD kernel module. Open tasks: 1. Add support for the remaining Video4Linux USB devices. 2. Make patches for increased buffer sizes, due to higher latency in userspace. Especially for High Speed USB. __________________________________________________________________ V4L support in Linux emulator URL: http://opal.com/freebsd/sys/compat/linux/ Contact: J.R. Oldroyd V4L video support in the Linux emulator is now available. This work allows Linux applications using V4L video calls to work with existing FreeBSD video drivers that provide V4L interfaces. It is tested and working with the net/skype port and also with browser-based Flash applications that access webcams. An early version has been committed to 9.0-CURRENT and work is in progress to commit the latest version and then MFC. It is also tested on FreeBSD-8.0/amd64 and FreeBSD-7.2/i386. Note: to be clear, this does not add V4L support to all webcams. The FreeBSD camera driver must already offer V4L support itself in order for a Linux application to be able to use that camera. The multimedia/pwcbsd port provides the pwc(4) driver that already has V4L support. If your camera is supported by a different driver, you will need to enhance that driver to add V4L support. __________________________________________________________________ VirtualBox on FreeBSD URL: http://wiki.FreeBSD.org/VirtualBox Contact: Beat Gaetzi Contact: Bernhard Froehlich Contact: Juergen Lock Contact: Martin Wilke VirtualBox 3.1.2 has been committed to the ports tree. Several changes to the port have been performed with this update including: * Port has been renamed to virtualbox-ose to reflect that we are now using the OSE version. * A seperate port for the kernel modules has been created -- virtualbox-ose-kmod. * A seperate port for guest additions for FreeBSD guests has been created -- virtualbox-ose-additions. * Proper FreeBSD support for PulseAudio has been added. * Procfs is not required anymore because vbox uses sysctl(3) now. * Juergen Lock's FreeBSD host networking patches have been added. They are now also in the upstream vbox SVN (modulo vbox variable naming style adjustments). * Allow direct tap networking again (for users that need the best network performance and/or need more complex network setups, like when they want to use routing instead of bridging to e.g. protect guests from messing with the lan's ARP tables; a tap + routing + proxy arp example is in the above freebsd-emulation@ posting.) * Enable vbox's shared MAC feature when using bridged mode on a Wifi interface, together with the virtualbox-ose-kmod change this should fix bridged mode for Wifi users. * We would like to say thanks to all the people that helped us by reporting bugs and submitting fixes. We also thank the VirtualBox developers for their help with the ongoing effort to port VirtualBox to FreeBSD __________________________________________________________________ Wireless mesh networking URL: http://wiki.FreeBSD.org/WifiMesh Contact: Rui Paulo Development of the FreeBSD 802.11s stack continues. The code in FreeBSD HEAD has been updated to comply with draft 4.0. Merge to FreeBSD 8-STABLE will be done soon. The developer is looking for funding to be able to implement mesh link security algorithms and/or coordinated channel access (performance improvement). From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 17 17:43:00 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCA9310656C6 for ; Sun, 17 Jan 2010 17:43:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id D849C8FC19 for ; Sun, 17 Jan 2010 17:42:58 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o0HHgqTM097482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Jan 2010 19:42:52 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id o0HHgqa5042633; Sun, 17 Jan 2010 19:42:52 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id o0HHgpm2042632; Sun, 17 Jan 2010 19:42:51 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 17 Jan 2010 19:42:51 +0200 From: Kostik Belousov To: Ali Polatel Message-ID: <20100117174251.GG62907@deviant.kiev.zoral.com.ua> References: <20100116190137.GA11414@harikalardiyari> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YCGSkTKVt49j0xAo" Content-Disposition: inline In-Reply-To: <20100116190137.GA11414@harikalardiyari> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org Subject: Re: ptrace bug or feature? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2010 17:43:00 -0000 --YCGSkTKVt49j0xAo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 16, 2010 at 09:01:37PM +0200, Ali Polatel wrote: > Hey everyone, >=20 > Problem: ptrace's PT_SETREGS request can't alter system calls. > Code: http://alip.github.com/code/ptrace-freebsd-deny.c > Expected: The file foo.bar shouldn't be created. > Got: The file is created. Other efforts like replacing > PT_GETREGS/PT_SETREGS calls with PT_KILL doesn't help, the file is > created nevertheless. >=20 > I'm inclined to call this a bug but I can't be sure. > Any comments appreciated. > TIA It may be a missed feature, not a bug. There is obvious hack value in ability to modify syscall arguments from the debugger. Do you know whether other operating systems allow this ? I was around this code today, and wrote the patch for i386, amd64 and ia32 on amd64. Other architectures need to be handled. diff --git a/sys/amd64/amd64/trap.c b/sys/amd64/amd64/trap.c index df301d1..bd7ee63 100644 --- a/sys/amd64/amd64/trap.c +++ b/sys/amd64/amd64/trap.c @@ -885,95 +885,131 @@ dblfault_handler(struct trapframe *frame) panic("double fault"); } =20 -/* - * syscall - system call request C handler - * - * A system call is essentially treated as a trap. - */ -void -syscall(struct trapframe *frame) -{ - caddr_t params; +struct syscall_args { + u_int code; struct sysent *callp; - struct thread *td =3D curthread; - struct proc *p =3D td->td_proc; - register_t orig_tf_rflags; - int error; - int narg; register_t args[8]; register_t *argp; - u_int code; - int reg, regcnt; - ksiginfo_t ksi; - - PCPU_INC(cnt.v_syscall); + int narg; +}; =20 -#ifdef DIAGNOSTIC - if (ISPL(frame->tf_cs) !=3D SEL_UPL) { - panic("syscall"); - /* NOT REACHED */ - } -#endif +static int +fetch_syscall_args(struct thread *td, struct syscall_args *sa) +{ + struct proc *p; + struct trapframe *frame; + caddr_t params; + int reg, regcnt, error; =20 + p =3D td->td_proc; + frame =3D td->td_frame; reg =3D 0; regcnt =3D 6; - td->td_pticks =3D 0; - td->td_frame =3D frame; - if (td->td_ucred !=3D p->p_ucred)=20 - cred_update_thread(td); + params =3D (caddr_t)frame->tf_rsp + sizeof(register_t); - code =3D frame->tf_rax; - orig_tf_rflags =3D frame->tf_rflags; + sa->code =3D frame->tf_rax; =20 if (p->p_sysent->sv_prepsyscall) { - (*p->p_sysent->sv_prepsyscall)(frame, (int *)args, &code, ¶ms); + (*p->p_sysent->sv_prepsyscall)(frame, (int *)sa->args, + &sa->code, ¶ms); } else { - if (code =3D=3D SYS_syscall || code =3D=3D SYS___syscall) { - code =3D frame->tf_rdi; + if (sa->code =3D=3D SYS_syscall || sa->code =3D=3D SYS___syscall) { + sa->code =3D frame->tf_rdi; reg++; regcnt--; } } - if (p->p_sysent->sv_mask) - code &=3D p->p_sysent->sv_mask; + sa->code &=3D p->p_sysent->sv_mask; =20 - if (code >=3D p->p_sysent->sv_size) - callp =3D &p->p_sysent->sv_table[0]; + if (sa->code >=3D p->p_sysent->sv_size) + sa->callp =3D &p->p_sysent->sv_table[0]; else - callp =3D &p->p_sysent->sv_table[code]; + sa->callp =3D &p->p_sysent->sv_table[sa->code]; =20 - narg =3D callp->sy_narg; - KASSERT(narg <=3D sizeof(args) / sizeof(args[0]), + sa->narg =3D sa->callp->sy_narg; + KASSERT(sa->narg <=3D sizeof(sa->args) / sizeof(sa->args[0]), ("Too many syscall arguments!")); error =3D 0; - argp =3D &frame->tf_rdi; - argp +=3D reg; - bcopy(argp, args, sizeof(args[0]) * regcnt); - if (narg > regcnt) { + sa->argp =3D &frame->tf_rdi; + sa->argp +=3D reg; + bcopy(sa->argp, sa->args, sizeof(sa->args[0]) * regcnt); + if (sa->narg > regcnt) { KASSERT(params !=3D NULL, ("copyin args with no params!")); - error =3D copyin(params, &args[regcnt], - (narg - regcnt) * sizeof(args[0])); + error =3D copyin(params, &sa->args[regcnt], + (sa->narg - regcnt) * sizeof(sa->args[0])); } - argp =3D &args[0]; + sa->argp =3D &sa->args[0]; =20 + /* + * This may result in two records if debugger modified + * registers or memory during sleep at stop/ptrace point. + */ #ifdef KTRACE if (KTRPOINT(td, KTR_SYSCALL)) - ktrsyscall(code, narg, argp); + ktrsyscall(sa->code, sa->narg, sa->argp); #endif + return (error); +} =20 - CTR4(KTR_SYSC, "syscall enter thread %p pid %d proc %s code %d", td, - td->td_proc->p_pid, td->td_name, code); +/* + * syscall - system call request C handler + * + * A system call is essentially treated as a trap. + */ +void +syscall(struct trapframe *frame) +{ + struct thread *td; + struct proc *p; + struct syscall_args sa; + register_t orig_tf_rflags; + int error; + ksiginfo_t ksi; =20 + PCPU_INC(cnt.v_syscall); + td =3D curthread; + p =3D td->td_proc; td->td_syscalls++; =20 +#ifdef DIAGNOSTIC + if (ISPL(frame->tf_cs) !=3D SEL_UPL) { + panic("syscall"); + /* NOT REACHED */ + } +#endif + + td->td_pticks =3D 0; + td->td_frame =3D frame; + if (td->td_ucred !=3D p->p_ucred)=20 + cred_update_thread(td); + orig_tf_rflags =3D frame->tf_rflags; + if (p->p_flag & P_TRACED) { + PROC_LOCK(p); + td->td_dbgflags &=3D ~TDB_USERWR; + PROC_UNLOCK(p); + } + error =3D fetch_syscall_args(td, &sa); + + CTR4(KTR_SYSC, "syscall enter thread %p pid %d proc %s code %d", td, + td->td_proc->p_pid, td->td_name, sa.code); + if (error =3D=3D 0) { td->td_retval[0] =3D 0; td->td_retval[1] =3D frame->tf_rdx; =20 - STOPEVENT(p, S_SCE, narg); - + STOPEVENT(p, S_SCE, sa.narg); PTRACESTOP_SC(p, td, S_PT_SCE); + if (td->td_dbgflags & TDB_USERWR) { + /* + * Reread syscall number and arguments if + * debugger modified registers or memory. + */ + error =3D fetch_syscall_args(td, &sa); + if (error !=3D 0) + goto retval; + td->td_retval[1] =3D frame->tf_rdx; + } =20 #ifdef KDTRACE_HOOKS /* @@ -981,13 +1017,13 @@ syscall(struct trapframe *frame) * callback and if there is a probe active for the * syscall 'entry', process the probe. */ - if (systrace_probe_func !=3D NULL && callp->sy_entry !=3D 0) - (*systrace_probe_func)(callp->sy_entry, code, callp, - args); + if (systrace_probe_func !=3D NULL && sa.callp->sy_entry !=3D 0) + (*systrace_probe_func)(sa.callp->sy_entry, sa.code, + sa.callp, sa.args); #endif =20 - AUDIT_SYSCALL_ENTER(code, td); - error =3D (*callp->sy_call)(td, argp); + AUDIT_SYSCALL_ENTER(sa.code, td); + error =3D (*sa.callp->sy_call)(td, sa.argp); AUDIT_SYSCALL_EXIT(error, td); =20 /* Save the latest error return value. */ @@ -999,12 +1035,12 @@ syscall(struct trapframe *frame) * callback and if there is a probe active for the * syscall 'return', process the probe. */ - if (systrace_probe_func !=3D NULL && callp->sy_return !=3D 0) - (*systrace_probe_func)(callp->sy_return, code, callp, - args); + if (systrace_probe_func !=3D NULL && sa.callp->sy_return !=3D 0) + (*systrace_probe_func)(sa.callp->sy_return, sa.code, + sa.callp, sa.args); #endif } - + retval: cpu_set_syscall_retval(td, error); =20 /* @@ -1023,14 +1059,16 @@ syscall(struct trapframe *frame) * Check for misbehavior. */ WITNESS_WARN(WARN_PANIC, NULL, "System call %s returning", - (code >=3D 0 && code < SYS_MAXSYSCALL) ? syscallnames[code] : "???"); + (sa.code >=3D 0 && sa.code < SYS_MAXSYSCALL) ? + syscallnames[sa.code] : "???"); KASSERT(td->td_critnest =3D=3D 0, ("System call %s returning in a critical section", - (code >=3D 0 && code < SYS_MAXSYSCALL) ? syscallnames[code] : "???")); + (sa.code >=3D 0 && sa.code < SYS_MAXSYSCALL) ? + syscallnames[sa.code] : "???")); KASSERT(td->td_locks =3D=3D 0, ("System call %s returning with %d locks held", - (code >=3D 0 && code < SYS_MAXSYSCALL) ? syscallnames[code] : "???", - td->td_locks)); + (sa.code >=3D 0 && sa.code < SYS_MAXSYSCALL) ? + syscallnames[sa.code] : "???", td->td_locks)); =20 /* * Handle reschedule and other end-of-syscall issues @@ -1038,11 +1076,11 @@ syscall(struct trapframe *frame) userret(td, frame); =20 CTR4(KTR_SYSC, "syscall exit thread %p pid %d proc %s code %d", td, - td->td_proc->p_pid, td->td_name, code); + td->td_proc->p_pid, td->td_name, sa.code); =20 #ifdef KTRACE if (KTRPOINT(td, KTR_SYSRET)) - ktrsysret(code, error, td->td_retval[0]); + ktrsysret(sa.code, error, td->td_retval[0]); #endif =20 /* @@ -1050,7 +1088,7 @@ syscall(struct trapframe *frame) * register set. If we ever support an emulation where this * is not the case, this code will need to be revisited. */ - STOPEVENT(p, S_SCX, code); + STOPEVENT(p, S_SCX, sa.code); =20 PTRACESTOP_SC(p, td, S_PT_SCX); } diff --git a/sys/amd64/ia32/ia32_syscall.c b/sys/amd64/ia32/ia32_syscall.c index 5e20876..aa1ae6c 100644 --- a/sys/amd64/ia32/ia32_syscall.c +++ b/sys/amd64/ia32/ia32_syscall.c @@ -88,101 +88,136 @@ extern const char *freebsd32_syscallnames[]; =20 void ia32_syscall(struct trapframe *frame); /* Called from asm code */ =20 -void -ia32_syscall(struct trapframe *frame) -{ +struct ia32_syscall_args { + u_int code; caddr_t params; - int i; struct sysent *callp; - struct thread *td =3D curthread; - struct proc *p =3D td->td_proc; - register_t orig_tf_rflags; - int error; + u_int64_t args64[8]; int narg; +}; + +static int +fetch_ia32_syscall_args(struct thread *td, struct ia32_syscall_args *sa) +{ + struct proc *p; + struct trapframe *frame; u_int32_t args[8]; - u_int64_t args64[8]; - u_int code; - ksiginfo_t ksi; + int error, i; =20 - PCPU_INC(cnt.v_syscall); - td->td_pticks =3D 0; - td->td_frame =3D frame; - if (td->td_ucred !=3D p->p_ucred)=20 - cred_update_thread(td); - params =3D (caddr_t)frame->tf_rsp + sizeof(u_int32_t); - code =3D frame->tf_rax; - orig_tf_rflags =3D frame->tf_rflags; + p =3D td->td_proc; + frame =3D td->td_frame; + + sa->params =3D (caddr_t)frame->tf_rsp + sizeof(u_int32_t); + sa->code =3D frame->tf_rax; =20 if (p->p_sysent->sv_prepsyscall) { /* * The prep code is MP aware. */ - (*p->p_sysent->sv_prepsyscall)(frame, args, &code, ¶ms); + (*p->p_sysent->sv_prepsyscall)(frame, args, &sa->code, + &sa->params); } else { /* * Need to check if this is a 32 bit or 64 bit syscall. * fuword is MP aware. */ - if (code =3D=3D SYS_syscall) { + if (sa->code =3D=3D SYS_syscall) { /* * Code is first argument, followed by actual args. */ - code =3D fuword32(params); - params +=3D sizeof(int); - } else if (code =3D=3D SYS___syscall) { + sa->code =3D fuword32(sa->params); + sa->params +=3D sizeof(int); + } else if (sa->code =3D=3D SYS___syscall) { /* * Like syscall, but code is a quad, so as to maintain * quad alignment for the rest of the arguments. * We use a 32-bit fetch in case params is not * aligned. */ - code =3D fuword32(params); - params +=3D sizeof(quad_t); + sa->code =3D fuword32(sa->params); + sa->params +=3D sizeof(quad_t); } } - if (p->p_sysent->sv_mask) - code &=3D p->p_sysent->sv_mask; - - if (code >=3D p->p_sysent->sv_size) - callp =3D &p->p_sysent->sv_table[0]; + sa->code &=3D p->p_sysent->sv_mask; + if (sa->code >=3D p->p_sysent->sv_size) + sa->callp =3D &p->p_sysent->sv_table[0]; else - callp =3D &p->p_sysent->sv_table[code]; - - narg =3D callp->sy_narg; + sa->callp =3D &p->p_sysent->sv_table[sa->code]; + sa->narg =3D sa->callp->sy_narg; =20 - /* - * copyin and the ktrsyscall()/ktrsysret() code is MP-aware - */ - if (params !=3D NULL && narg !=3D 0) - error =3D copyin(params, (caddr_t)args, - (u_int)(narg * sizeof(int))); + if (sa->params !=3D NULL && sa->narg !=3D 0) + error =3D copyin(sa->params, (caddr_t)args, + (u_int)(sa->narg * sizeof(int))); else error =3D 0; =20 - for (i =3D 0; i < narg; i++) - args64[i] =3D args[i]; + for (i =3D 0; i < sa->narg; i++) + sa->args64[i] =3D args[i]; =20 #ifdef KTRACE if (KTRPOINT(td, KTR_SYSCALL)) - ktrsyscall(code, narg, args64); + ktrsyscall(sa->code, sa->narg, sa->args64); #endif + + return (error); +} + +void +ia32_syscall(struct trapframe *frame) +{ + struct thread *td; + struct proc *p; + struct ia32_syscall_args sa; + register_t orig_tf_rflags; + int error; + ksiginfo_t ksi; + + PCPU_INC(cnt.v_syscall); + td =3D curthread; + p =3D td->td_proc; + td->td_syscalls++; + + td->td_pticks =3D 0; + td->td_frame =3D frame; + if (td->td_ucred !=3D p->p_ucred)=20 + cred_update_thread(td); + orig_tf_rflags =3D frame->tf_rflags; + if (p->p_flag & P_TRACED) { + PROC_LOCK(p); + td->td_dbgflags &=3D ~TDB_USERWR; + PROC_UNLOCK(p); + } + error =3D fetch_ia32_syscall_args(td, &sa); + CTR4(KTR_SYSC, "syscall enter thread %p pid %d proc %s code %d", td, - td->td_proc->p_pid, td->td_proc->p_comm, code); + td->td_proc->p_pid, td->td_name, sa.code); =20 if (error =3D=3D 0) { td->td_retval[0] =3D 0; td->td_retval[1] =3D frame->tf_rdx; =20 - STOPEVENT(p, S_SCE, narg); - + STOPEVENT(p, S_SCE, sa.narg); PTRACESTOP_SC(p, td, S_PT_SCE); + if (td->td_dbgflags & TDB_USERWR) { + /* + * Reread syscall number and arguments if + * debugger modified registers or memory. + */ + error =3D fetch_ia32_syscall_args(td, &sa); + if (error !=3D 0) + goto retval; + td->td_retval[1] =3D frame->tf_rdx; + } =20 - AUDIT_SYSCALL_ENTER(code, td); - error =3D (*callp->sy_call)(td, args64); + AUDIT_SYSCALL_ENTER(sa.code, td); + error =3D (*sa.callp->sy_call)(td, sa.args64); AUDIT_SYSCALL_EXIT(error, td); - } =20 + /* Save the latest error return value. */ + td->td_errno =3D error; + } + retval: cpu_set_syscall_retval(td, error); =20 /* @@ -201,14 +236,16 @@ ia32_syscall(struct trapframe *frame) * Check for misbehavior. */ WITNESS_WARN(WARN_PANIC, NULL, "System call %s returning", - (code >=3D 0 && code < SYS_MAXSYSCALL) ? freebsd32_syscallnames[code]= : "???"); + (sa.code >=3D 0 && sa.code < SYS_MAXSYSCALL) ? + freebsd32_syscallnames[sa.code] : "???"); KASSERT(td->td_critnest =3D=3D 0, ("System call %s returning in a critical section", - (code >=3D 0 && code < SYS_MAXSYSCALL) ? freebsd32_syscallnames[code]= : "???")); + (sa.code >=3D 0 && sa.code < SYS_MAXSYSCALL) ? + freebsd32_syscallnames[sa.code] : "???")); KASSERT(td->td_locks =3D=3D 0, ("System call %s returning with %d locks held", - (code >=3D 0 && code < SYS_MAXSYSCALL) ? freebsd32_syscallnames[code]= : "???", - td->td_locks)); + (sa.code >=3D 0 && sa.code < SYS_MAXSYSCALL) ? + freebsd32_syscallnames[sa.code] : "???", td->td_locks)); =20 /* * Handle reschedule and other end-of-syscall issues @@ -216,10 +253,10 @@ ia32_syscall(struct trapframe *frame) userret(td, frame); =20 CTR4(KTR_SYSC, "syscall exit thread %p pid %d proc %s code %d", td, - td->td_proc->p_pid, td->td_proc->p_comm, code); + td->td_proc->p_pid, td->td_proc->p_comm, sa.code); #ifdef KTRACE if (KTRPOINT(td, KTR_SYSRET)) - ktrsysret(code, error, td->td_retval[0]); + ktrsysret(sa.code, error, td->td_retval[0]); #endif =20 /* @@ -227,7 +264,7 @@ ia32_syscall(struct trapframe *frame) * register set. If we ever support an emulation where this * is not the case, this code will need to be revisited. */ - STOPEVENT(p, S_SCX, code); + STOPEVENT(p, S_SCX, sa.code); =20 PTRACESTOP_SC(p, td, S_PT_SCX); } diff --git a/sys/i386/i386/trap.c b/sys/i386/i386/trap.c index 1d3dc3b..305cfd2 100644 --- a/sys/i386/i386/trap.c +++ b/sys/i386/i386/trap.c @@ -969,97 +969,130 @@ dblfault_handler() panic("double fault"); } =20 -/* - * syscall - system call request C handler - * - * A system call is essentially treated as a trap. - */ -void -syscall(struct trapframe *frame) -{ - caddr_t params; +struct syscall_args { + u_int code; struct sysent *callp; - struct thread *td =3D curthread; - struct proc *p =3D td->td_proc; - register_t orig_tf_eflags; - int error; - int narg; int args[8]; - u_int code; - ksiginfo_t ksi; + register_t *argp; + int narg; +}; =20 - PCPU_INC(cnt.v_syscall); +static int +fetch_syscall_args(struct thread *td, struct syscall_args *sa) +{ + struct proc *p; + struct trapframe *frame; + caddr_t params; + int error; =20 -#ifdef DIAGNOSTIC - if (ISPL(frame->tf_cs) !=3D SEL_UPL) { - panic("syscall"); - /* NOT REACHED */ - } -#endif + p =3D td->td_proc; + frame =3D td->td_frame; =20 - td->td_pticks =3D 0; - td->td_frame =3D frame; - if (td->td_ucred !=3D p->p_ucred)=20 - cred_update_thread(td); params =3D (caddr_t)frame->tf_esp + sizeof(int); - code =3D frame->tf_eax; - orig_tf_eflags =3D frame->tf_eflags; + sa->code =3D frame->tf_eax; =20 if (p->p_sysent->sv_prepsyscall) { - (*p->p_sysent->sv_prepsyscall)(frame, args, &code, ¶ms); + (*p->p_sysent->sv_prepsyscall)(frame, sa->args, &sa->code, + ¶ms); } else { /* * Need to check if this is a 32 bit or 64 bit syscall. */ - if (code =3D=3D SYS_syscall) { + if (sa->code =3D=3D SYS_syscall) { /* * Code is first argument, followed by actual args. */ - code =3D fuword(params); + sa->code =3D fuword(params); params +=3D sizeof(int); - } else if (code =3D=3D SYS___syscall) { + } else if (sa->code =3D=3D SYS___syscall) { /* * Like syscall, but code is a quad, so as to maintain * quad alignment for the rest of the arguments. */ - code =3D fuword(params); + sa->code =3D fuword(params); params +=3D sizeof(quad_t); } } =20 if (p->p_sysent->sv_mask) - code &=3D p->p_sysent->sv_mask; - - if (code >=3D p->p_sysent->sv_size) - callp =3D &p->p_sysent->sv_table[0]; + sa->code &=3D p->p_sysent->sv_mask; + if (sa->code >=3D p->p_sysent->sv_size) + sa->callp =3D &p->p_sysent->sv_table[0]; else - callp =3D &p->p_sysent->sv_table[code]; - - narg =3D callp->sy_narg; + sa->callp =3D &p->p_sysent->sv_table[sa->code]; + sa->narg =3D sa->callp->sy_narg; =20 - if (params !=3D NULL && narg !=3D 0) - error =3D copyin(params, (caddr_t)args, - (u_int)(narg * sizeof(int))); + if (params !=3D NULL && sa->narg !=3D 0) + error =3D copyin(params, (caddr_t)sa->args, + (u_int)(sa->narg * sizeof(int))); else error =3D 0; =09 #ifdef KTRACE if (KTRPOINT(td, KTR_SYSCALL)) - ktrsyscall(code, narg, args); + ktrsyscall(sa->code, sa->narg, sa->args); #endif + return (error); +} =20 - CTR4(KTR_SYSC, "syscall enter thread %p pid %d proc %s code %d", td, - td->td_proc->p_pid, td->td_name, code); +/* + * syscall - system call request C handler + * + * A system call is essentially treated as a trap. + */ +void +syscall(struct trapframe *frame) +{ + struct thread *td; + struct proc *p; + struct syscall_args sa; + register_t orig_tf_eflags; + int error; + ksiginfo_t ksi; =20 + PCPU_INC(cnt.v_syscall); + td =3D curthread; + p =3D td->td_proc; td->td_syscalls++; =20 +#ifdef DIAGNOSTIC + if (ISPL(frame->tf_cs) !=3D SEL_UPL) { + panic("syscall"); + /* NOT REACHED */ + } +#endif + + td->td_pticks =3D 0; + td->td_frame =3D frame; + if (td->td_ucred !=3D p->p_ucred)=20 + cred_update_thread(td); + orig_tf_eflags =3D frame->tf_eflags; + if (p->p_flag & P_TRACED) { + PROC_LOCK(p); + td->td_dbgflags &=3D ~TDB_USERWR; + PROC_UNLOCK(p); + } + error =3D fetch_syscall_args(td, &sa); + + CTR4(KTR_SYSC, "syscall enter thread %p pid %d proc %s code %d", td, + td->td_proc->p_pid, td->td_name, sa.code); + if (error =3D=3D 0) { td->td_retval[0] =3D 0; td->td_retval[1] =3D frame->tf_edx; =20 - STOPEVENT(p, S_SCE, narg); - + STOPEVENT(p, S_SCE, sa.narg); PTRACESTOP_SC(p, td, S_PT_SCE); + if (td->td_dbgflags & TDB_USERWR) { + /* + * Reread syscall number and arguments if + * debugger modified registers or memory. + */ + error =3D fetch_syscall_args(td, &sa); + if (error !=3D 0) + goto retval; + td->td_retval[1] =3D frame->tf_edx; + } =20 #ifdef KDTRACE_HOOKS /* @@ -1067,13 +1100,13 @@ syscall(struct trapframe *frame) * callback and if there is a probe active for the * syscall 'entry', process the probe. */ - if (systrace_probe_func !=3D NULL && callp->sy_entry !=3D 0) - (*systrace_probe_func)(callp->sy_entry, code, callp, - args); + if (systrace_probe_func !=3D NULL && sa.callp->sy_entry !=3D 0) + (*systrace_probe_func)(sa.callp->sy_entry, sa.code, + sa.callp, sa.args); #endif =20 - AUDIT_SYSCALL_ENTER(code, td); - error =3D (*callp->sy_call)(td, args); + AUDIT_SYSCALL_ENTER(sa.code, td); + error =3D (*sa.callp->sy_call)(td, sa.args); AUDIT_SYSCALL_EXIT(error, td); =20 /* Save the latest error return value. */ @@ -1085,12 +1118,12 @@ syscall(struct trapframe *frame) * callback and if there is a probe active for the * syscall 'return', process the probe. */ - if (systrace_probe_func !=3D NULL && callp->sy_return !=3D 0) - (*systrace_probe_func)(callp->sy_return, code, callp, - args); + if (systrace_probe_func !=3D NULL && sa.callp->sy_return !=3D 0) + (*systrace_probe_func)(sa.callp->sy_return, sa.code, + sa.callp, sa.args); #endif } - + retval: cpu_set_syscall_retval(td, error); =20 /* @@ -1109,14 +1142,16 @@ syscall(struct trapframe *frame) * Check for misbehavior. */ WITNESS_WARN(WARN_PANIC, NULL, "System call %s returning", - (code >=3D 0 && code < SYS_MAXSYSCALL) ? syscallnames[code] : "???"); + (sa.code >=3D 0 && sa.code < SYS_MAXSYSCALL) ? + syscallnames[sa.code] : "???"); KASSERT(td->td_critnest =3D=3D 0, ("System call %s returning in a critical section", - (code >=3D 0 && code < SYS_MAXSYSCALL) ? syscallnames[code] : "???")); + (sa.code >=3D 0 && sa.code < SYS_MAXSYSCALL) ? + syscallnames[sa.code] : "???")); KASSERT(td->td_locks =3D=3D 0, ("System call %s returning with %d locks held", - (code >=3D 0 && code < SYS_MAXSYSCALL) ? syscallnames[code] : "???", - td->td_locks)); + (sa.code >=3D 0 && sa.code < SYS_MAXSYSCALL) ? + syscallnames[sa.code] : "???", td->td_locks)); =20 /* * Handle reschedule and other end-of-syscall issues @@ -1124,11 +1159,11 @@ syscall(struct trapframe *frame) userret(td, frame); =20 CTR4(KTR_SYSC, "syscall exit thread %p pid %d proc %s code %d", td, - td->td_proc->p_pid, td->td_name, code); + td->td_proc->p_pid, td->td_name, sa.code); =20 #ifdef KTRACE if (KTRPOINT(td, KTR_SYSRET)) - ktrsysret(code, error, td->td_retval[0]); + ktrsysret(sa.code, error, td->td_retval[0]); #endif =20 /* @@ -1136,7 +1171,7 @@ syscall(struct trapframe *frame) * register set. If we ever support an emulation where this * is not the case, this code will need to be revisited. */ - STOPEVENT(p, S_SCX, code); + STOPEVENT(p, S_SCX, sa.code); =20 PTRACESTOP_SC(p, td, S_PT_SCX); } diff --git a/sys/kern/sys_process.c b/sys/kern/sys_process.c index dfc36ba..3c6394c 100644 --- a/sys/kern/sys_process.c +++ b/sys/kern/sys_process.c @@ -816,6 +816,7 @@ kern_ptrace(struct thread *td, int req, pid_t pid, void= *addr, int data) =20 case PT_WRITE_I: case PT_WRITE_D: + td2->td_dbgflags |=3D TDB_USERWR; write =3D 1; /* FALLTHROUGH */ case PT_READ_I: @@ -884,6 +885,7 @@ kern_ptrace(struct thread *td, int req, pid_t pid, void= *addr, int data) break; case PIOD_WRITE_D: case PIOD_WRITE_I: + td2->td_dbgflags |=3D TDB_USERWR; uio.uio_rw =3D UIO_WRITE; break; default: @@ -906,6 +908,7 @@ kern_ptrace(struct thread *td, int req, pid_t pid, void= *addr, int data) goto sendsig; /* in PT_CONTINUE above */ =20 case PT_SETREGS: + td2->td_dbgflags |=3D TDB_USERWR; error =3D PROC_WRITE(regs, td2, addr); break; =20 @@ -914,6 +917,7 @@ kern_ptrace(struct thread *td, int req, pid_t pid, void= *addr, int data) break; =20 case PT_SETFPREGS: + td2->td_dbgflags |=3D TDB_USERWR; error =3D PROC_WRITE(fpregs, td2, addr); break; =20 @@ -922,6 +926,7 @@ kern_ptrace(struct thread *td, int req, pid_t pid, void= *addr, int data) break; =20 case PT_SETDBREGS: + td2->td_dbgflags |=3D TDB_USERWR; error =3D PROC_WRITE(dbregs, td2, addr); break; =20 diff --git a/sys/sys/proc.h b/sys/sys/proc.h index 0ae36af..dd9efae 100644 --- a/sys/sys/proc.h +++ b/sys/sys/proc.h @@ -341,6 +341,7 @@ do { \ /* Userland debug flags */ #define TDB_SUSPEND 0x00000001 /* Thread is suspended by debugger */ #define TDB_XSIG 0x00000002 /* Thread is exchanging signal under trace */ +#define TDB_USERWR 0x00000004 /* Debugger modified memory or registers */ =20 /* * "Private" flags kept in td_pflags: --YCGSkTKVt49j0xAo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAktTTBsACgkQC3+MBN1Mb4gimACgqDy33BQLby/qcFeTv2+r2Pgu B0gAoNUuL+1fMTJqb4by4GjKLtUmF8Lx =waFa -----END PGP SIGNATURE----- --YCGSkTKVt49j0xAo-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 17 18:06:54 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C33CA1065697 for ; Sun, 17 Jan 2010 18:06:54 +0000 (UTC) (envelope-from nate@thatsmathematics.com) Received: from euclid.ucsd.edu (euclid.ucsd.edu [132.239.145.52]) by mx1.freebsd.org (Postfix) with ESMTP id 8D5798FC1F for ; Sun, 17 Jan 2010 18:06:54 +0000 (UTC) Received: from zeno.ucsd.edu (zeno.ucsd.edu [132.239.145.22]) by euclid.ucsd.edu (8.11.7p3+Sun/8.11.7) with ESMTP id o0HI6rY15472; Sun, 17 Jan 2010 10:06:53 -0800 (PST) Received: from localhost (neldredg@localhost) by zeno.ucsd.edu (8.11.7p3+Sun/8.11.7) with ESMTP id o0HI6rH00814; Sun, 17 Jan 2010 10:06:53 -0800 (PST) X-Authentication-Warning: zeno.ucsd.edu: neldredg owned process doing -bs Date: Sun, 17 Jan 2010 10:06:52 -0800 (PST) From: Nate Eldredge X-X-Sender: neldredg@zeno.ucsd.edu To: Kostik Belousov In-Reply-To: <20100117174251.GG62907@deviant.kiev.zoral.com.ua> Message-ID: References: <20100116190137.GA11414@harikalardiyari> <20100117174251.GG62907@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Ali Polatel , freebsd-hackers@freebsd.org Subject: Re: ptrace bug or feature? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2010 18:06:54 -0000 On Sun, 17 Jan 2010, Kostik Belousov wrote: > It may be a missed feature, not a bug. There is obvious hack value > in ability to modify syscall arguments from the debugger. > > Do you know whether other operating systems allow this ? Linux does, I've used it. -- Nate Eldredge nate@thatsmathematics.com From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 17 18:23:13 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B98B4106566B for ; Sun, 17 Jan 2010 18:23:13 +0000 (UTC) (envelope-from polatel@gmail.com) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by mx1.freebsd.org (Postfix) with ESMTP id 45DDB8FC21 for ; Sun, 17 Jan 2010 18:23:12 +0000 (UTC) Received: by ewy26 with SMTP id 26so2699814ewy.3 for ; Sun, 17 Jan 2010 10:23:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:message-id:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=ydKqUKtNwpYspmVkJulIsHDW+RR39bYMMaLJ8fcn8Bs=; b=RaV+eBo/JaV6jJDt5rbMTm63dYDy0Uh9yf103dQqtr2VLQuneYkhHVXHkTbFwYjafV X2nv7qwIANzZz8pTyvfzf/+BAdNL3OGXFnfnifub0x08AjebivNnH1LL7TVBxKY9Oket YLfjyVzYod5cnDwWALgjhjxNPlhGs1qD+P1x4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=BZZXH8wgL6cuB/eX1Zubimi15biv5Y/GnUCirEZOSJbrC1kT4VGniXGyKMERtAyq+2 U+FMjznHKAQ5NO2049xWsBiaBfdkwpCimBa2mFSFAVj3tHLwM73pLEU9+dL4P+GuMHV+ SKOuqHO6jOtJkM5LQ+ln38ajxov1nXI1X0U5E= Received: by 10.213.15.17 with SMTP id i17mr5467096eba.83.1263752592134; Sun, 17 Jan 2010 10:23:12 -0800 (PST) Received: from harikalardiyari ([78.179.49.34]) by mx.google.com with ESMTPS id 16sm119317ewy.2.2010.01.17.10.23.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 17 Jan 2010 10:23:10 -0800 (PST) Sender: Ali Polatel Date: Sun, 17 Jan 2010 20:23:08 +0200 From: Ali Polatel To: Nate Eldredge Message-ID: <20100117182307.GA7106@harikalardiyari> References: <20100116190137.GA11414@harikalardiyari> <20100117174251.GG62907@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0F1p//8PRICkK4MW" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Kostik Belousov , freebsd-hackers@freebsd.org Subject: Re: ptrace bug or feature? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2010 18:23:13 -0000 --0F1p//8PRICkK4MW Content-Type: text/plain; charset=iso-8859-9 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Nate Eldredge yazm=FD=FE: > On Sun, 17 Jan 2010, Kostik Belousov wrote: >=20 > >It may be a missed feature, not a bug. There is obvious hack value > >in ability to modify syscall arguments from the debugger. > > > >Do you know whether other operating systems allow this ? >=20 > Linux does, I've used it. Yep it does, here's example code: http://alip.github.com/code/ptrace-linux-deny.c > --=20 >=20 > Nate Eldredge > nate@thatsmathematics.com --=20 Regards, Ali Polatel --0F1p//8PRICkK4MW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEABECAAYFAktTVYsACgkQQU4yORhF8iDt1wCeLSmfIxJml53gL+z+0TLO2yEd JLwAoKe6a/CTpPj6rVHN5ySxAkvCOzH3 =QOql -----END PGP SIGNATURE----- --0F1p//8PRICkK4MW-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 17 21:57:40 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B46E0106566C for ; Sun, 17 Jan 2010 21:57:40 +0000 (UTC) (envelope-from tyler@monkeypox.org) Received: from starfish.geekisp.com (mail.geekisp.com [216.168.135.169]) by mx1.freebsd.org (Postfix) with ESMTP id 643028FC15 for ; Sun, 17 Jan 2010 21:57:40 +0000 (UTC) Received: (qmail 105 invoked by uid 1003); 17 Jan 2010 21:30:58 -0000 Received: from localhost (HELO kiwi.sharlinx.com) (tyler@monkeypox.org@127.0.0.1) by mail.geekisp.com with SMTP; 17 Jan 2010 21:30:56 -0000 Date: Sun, 17 Jan 2010 13:30:50 -0800 From: "R. Tyler Ballance" To: freebsd-hackers@freebsd.org Message-ID: <20100117213049.GA2259@kiwi.sharlinx.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BXVAT5kNtrzKuDFl" Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Weekend PR smashing X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2010 21:57:40 -0000 --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Howdy all, I've recently taken up perusing the PR database looking for small(ish) bugs that will help me: (1) start contributing to FreeBSD again (2) familiarize myself with -CURRENT. Last weekend I knocked off #43337 (to which my patch still remains unaddressed) and started looking for more and more bugs, particularly in the 'bin' category. I've noticed a couple things, and would love a helping hand with: * There's a lot of **old** PRs, some of the userland bugs that are over a decade old I have no idea what to do with (try to reproduce a bug filed against 2.2?) * There's a lot of PRs with patches and a discussion; I don't *think* I can do anything helpful with these Additionally, I feel somewhat overwhelmed, I'm really hunting for tasks anywhere from a few hours to an all-nighter. Some of the things the KDE team does to get people involved I find useful, such as the "bugs howto" for information on triaging and getting started with contributing: http://quality.kde.org/develop/howto/howtobugs.php As well as the "junior jobs" keyword in their bugzilla: https://bugs.kde.org/buglist.cgi?keywords=junior-jobs&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&cmdtype=doit Are there similar resources I've not stumbled across yet? I would like to help, I have but one machine running -CURRENT and sporadic free time over the weekends. Tips? :D Cheers, -R. Tyler Ballance -------------------------------------- Jabber: rtyler@jabber.org GitHub: http://github.com/rtyler Twitter: http://twitter.com/agentdero Blog: http://unethicalblogger.com --BXVAT5kNtrzKuDFl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEUEARECAAYFAktTgYkACgkQFCbH3D9R4W+X4gCeI7tA5/LK+bPXaN0XO4AlbWGZ OoEAmIb3x20DTp7s4/3Q9CVTFxZzN60= =Qn52 -----END PGP SIGNATURE----- --BXVAT5kNtrzKuDFl-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 18 01:07:59 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 538801065693 for ; Mon, 18 Jan 2010 01:07:59 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id CD59C8FC16 for ; Mon, 18 Jan 2010 01:07:57 +0000 (UTC) Received: from park.js.berklix.net (p549A60F7.dip.t-dialin.net [84.154.96.247]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id o0I17tvt074497 for ; Mon, 18 Jan 2010 01:07:56 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id o0I17oMg090065 for ; Mon, 18 Jan 2010 02:07:50 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id o0I17jbS088321 for ; Mon, 18 Jan 2010 02:07:50 +0100 (CET) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201001180107.o0I17jbS088321@fire.js.berklix.net> To: hackers@freebsd.org From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Linux Unix Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com/~jhs/cv/ Date: Mon, 18 Jan 2010 02:07:45 +0100 Sender: jhs@berklix.com Cc: Subject: limits for run away Firefox ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 01:07:59 -0000 Hi hackers I'm tired of my X server occasionaly freezing, swap thrasing, & firefox dumps: 4,346,937,344 ~/firefox-bin.core so as a temporary cludge I ran touch ~/firefox-bin.core ; chmod 000 ~/firefox-bin.core I could put X users in another group, & reduce limits, per man login.conf ... RESOURCE LIMITS suggestions of values welcome. Yes 7.1 is old, thats my screen server, till I complete local builds of 7.2 & 8.0 on other boxes., then I'll upgrade, but I'll still want firefox though I see firefox is still troublesome eg uname -r # 8.0-RELEASE cd /usr/ports/www/firefox/Makefile ; make make # ===> firefox-2.0.0.20_9,1 is forbidden: too many security issues cd ../firefox3 ; make # is OK, & runs on 8.0 i686, but on amd64 fails with GLib-WARNING **: g_set_prgname() called multiple times so I'm pausing for perspective, comment invited :-) Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text not quoted-printable, HTML or Base64 http://asciiribbon.org From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 18 04:13:35 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DC231065670 for ; Mon, 18 Jan 2010 04:13:35 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f177.google.com (mail-iw0-f177.google.com [209.85.223.177]) by mx1.freebsd.org (Postfix) with ESMTP id BEDF38FC19 for ; Mon, 18 Jan 2010 04:13:34 +0000 (UTC) Received: by iwn7 with SMTP id 7so1833740iwn.7 for ; Sun, 17 Jan 2010 20:13:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=oIbJqXqICSOpV7JTxFzW0TvTE+qnxL2chJKqT66X+ds=; b=M7hkuk5bL27uLX1ahmq9BIX/hYfQNuEQ+LPKZhY4EAQrN04K17nAvD8UjhnWq56ew/ O4O4MHJqFvXH6X5bfD5fsvR49Xx/vUwG5WNhRFaBadGR9GAyhaNnO8a8jReEDerxnFa9 f7EeAROx+3CxMmhRmw02ckTToH4Q3S4b+LRUg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=q1U7MOCGxw5ZMnlScdIVfxqAwV7+CfPTMRzI0Jt64yI/1rg0whHuAodjgIEdli7Vpn 3PQSd3aJs5Q9dJcpcLe30zNnDLi1cOqWiZTFv1ojZ7Ibdz50R3gN5Q0B5HihHKdilFOv FyzQFz3173HI0Myk/EQ9oFN3nc2tWnY+K/2gY= Received: by 10.231.167.204 with SMTP id r12mr4013049iby.31.1263788013727; Sun, 17 Jan 2010 20:13:33 -0800 (PST) Received: from ppp-22.250.dialinfree.com (ppp-22.250.dialinfree.com [209.172.22.250]) by mx.google.com with ESMTPS id 21sm4124031iwn.14.2010.01.17.20.13.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 17 Jan 2010 20:13:32 -0800 (PST) Sender: "J. Hellenthal" Date: Sun, 17 Jan 2010 23:13:19 -0500 From: jhell To: "Julian H. Stacey" In-Reply-To: <201001180107.o0I17jbS088321@fire.js.berklix.net> Message-ID: References: <201001180107.o0I17jbS088321@fire.js.berklix.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: hackers@freebsd.org Subject: Re: limits for run away Firefox ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 04:13:35 -0000 On Sun, 17 Jan 2010 20:07, jhs@ wrote: > Hi hackers > I'm tired of my X server occasionaly freezing, swap thrasing, & firefox dumps: > 4,346,937,344 ~/firefox-bin.core > so as a temporary cludge I ran > touch ~/firefox-bin.core ; chmod 000 ~/firefox-bin.core > I could put X users in another group, & reduce limits, per > man login.conf ... RESOURCE LIMITS > suggestions of values welcome. > > Yes 7.1 is old, thats my screen server, till I complete local builds of > 7.2 & 8.0 on other boxes., then I'll upgrade, but I'll still want firefox > though I see firefox is still troublesome eg > uname -r # 8.0-RELEASE > cd /usr/ports/www/firefox/Makefile ; make > make # ===> firefox-2.0.0.20_9,1 is forbidden: > too many security issues > cd ../firefox3 ; make # is OK, & runs on 8.0 i686, but on > amd64 fails with > GLib-WARNING **: g_set_prgname() called multiple times > so I'm pausing for perspective, comment invited :-) > > Cheers, > Julian Is it a possibility for you to add something like this to your ~/.login_conf me:\ :umask=027:\ :lang=C:\ :charset=en_US.ISO8859-1:\ :coredumpsize=0 Of course, adjust accordingly. Maybe you could just run it in a different class that you can setup globally in your login.conf as well so you do not have to turn off core dumps for your user entirely. At least you wont have the core dumps but this may not exactly be what you are looking for. Best of luck. -- jhell From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 18 05:27:08 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D930A106566C for ; Mon, 18 Jan 2010 05:27:08 +0000 (UTC) (envelope-from sudakov+freebsd@sibptus.tomsk.ru) Received: from relay2.tomsk.ru (relay2.tomsk.ru [212.73.124.8]) by mx1.freebsd.org (Postfix) with ESMTP id 36E5F8FC13 for ; Mon, 18 Jan 2010 05:27:07 +0000 (UTC) X-Virus-Scanned: by clamd daemon 0.93.1 for FreeBSD at relay2.tomsk.ru Received: from admin.sibptus.tomsk.ru (account sudakov@sibptus.tomsk.ru [212.73.125.240] verified) by relay2.tomsk.ru (CommuniGate Pro SMTP 5.1.13) with ESMTPSA id 13439005 for freebsd-hackers@freebsd.org; Mon, 18 Jan 2010 11:27:06 +0600 Received: from admin.sibptus.tomsk.ru (sudakov@localhost [127.0.0.1]) by admin.sibptus.tomsk.ru (8.13.6/8.13.6) with ESMTP id o0I5R5k2056262 for ; Mon, 18 Jan 2010 11:27:05 +0600 (OMST) (envelope-from sudakov+freebsd@sibptus.tomsk.ru) Received: (from sudakov@localhost) by admin.sibptus.tomsk.ru (8.13.6/8.13.6/Submit) id o0I5R4nA056261 for freebsd-hackers@freebsd.org; Mon, 18 Jan 2010 11:27:04 +0600 (OMST) (envelope-from sudakov+freebsd@sibptus.tomsk.ru) X-Authentication-Warning: admin.sibptus.tomsk.ru: sudakov set sender to sudakov+freebsd@sibptus.tomsk.ru using -f Date: Mon, 18 Jan 2010 11:27:04 +0600 From: Victor Sudakov To: freebsd-hackers@freebsd.org Message-ID: <20100118052704.GA56224@admin.sibptus.tomsk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Organization: AO "Svyaztransneft", SibPTUS Subject: what's "Exception: t_mutex::lock failed" in ports/net/twinkle/ ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 05:27:08 -0000 Colleagues, I have installed ports/net/twinkle/ v. 1.4.2 on 8.0-RELEASE. When started, it displays the "Exception: t_mutex::lock failed" messagebox and exits after pressing the "OK" button. What is this error? I really need a SIP softphone on a FreeBSD box. Google was not particularly helpful, actually, it only finds my own post to a Russian newsgroup on the same problem. If somebody wants to have a look, I am willing to provide a kdump. TIA for any input. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov@sibptus.tomsk.ru From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 18 13:23:28 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C69F9106566C; Mon, 18 Jan 2010 13:23:28 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 87CF38FC19; Mon, 18 Jan 2010 13:23:28 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id A4B591FFC22; Mon, 18 Jan 2010 13:23:27 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 805AE84439; Mon, 18 Jan 2010 14:23:27 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Jaakko Heinonen References: <1bd550a01001010945i1a043ff9t70eb814cafe4b30a@mail.gmail.com> <20100101193814.GA60021@stack.nl> <20100116071114.GA7988@a91-153-117-195.elisa-laajakaista.fi> Date: Mon, 18 Jan 2010 14:23:27 +0100 In-Reply-To: <20100116071114.GA7988@a91-153-117-195.elisa-laajakaista.fi> (Jaakko Heinonen's message of "Sat, 16 Jan 2010 09:11:15 +0200") Message-ID: <86636z4kds.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Hackers , Jilles Tjoelker , Fernando =?utf-8?Q?Apestegu=C3=ADa?= Subject: Re: linprocfs Input/output error X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 13:23:28 -0000 Jaakko Heinonen writes: > Maybe des@ can comment if this looks sane? Looks good. It may confuse userland apps, but that's their own fault - and frankly my dear, I don't give a damn :) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 18 17:33:29 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CB5E106566C for ; Mon, 18 Jan 2010 17:33:29 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 1E4968FC0A for ; Mon, 18 Jan 2010 17:33:28 +0000 (UTC) Received: (qmail 17988 invoked by uid 399); 18 Jan 2010 17:33:28 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 18 Jan 2010 17:33:28 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4B549B67.90206@FreeBSD.org> Date: Mon, 18 Jan 2010 09:33:27 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.5) Gecko/20100114 Thunderbird/3.0 MIME-Version: 1.0 To: "Julian H. Stacey" References: <201001180107.o0I17jbS088321@fire.js.berklix.net> In-Reply-To: <201001180107.o0I17jbS088321@fire.js.berklix.net> X-Enigmail-Version: 1.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org Subject: Re: limits for run away Firefox ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 17:33:29 -0000 On 01/17/10 17:07, Julian H. Stacey wrote: > Hi hackers > I'm tired of my X server occasionaly freezing, swap thrasing, & firefox dumps: > 4,346,937,344 ~/firefox-bin.core > so as a temporary cludge I ran > touch ~/firefox-bin.core ; chmod 000 ~/firefox-bin.core Sorry I don't have a solution to your actual problem, but a better way to deal with this is to do: ln -s /dev/null ~/firefox-bin.core hth, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 18 19:15:32 2010 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C0FA1065694 for ; Mon, 18 Jan 2010 19:15:32 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 23BD88FC19 for ; Mon, 18 Jan 2010 19:15:31 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o0IJEUPK000790; Mon, 18 Jan 2010 20:14:46 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o0IJEUXV000789; Mon, 18 Jan 2010 20:14:30 +0100 (CET) (envelope-from olli) Date: Mon, 18 Jan 2010 20:14:30 +0100 (CET) Message-Id: <201001181914.o0IJEUXV000789@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG, david@catwhisker.org, yanefbsd@gmail.com In-Reply-To: <7d6fde3d1001151402m74d999e5off14be9a99b5d187@mail.gmail.com> X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Mon, 18 Jan 2010 20:14:46 +0100 (CET) Cc: Subject: Re: User error or awk bug? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 19:15:32 -0000 Garrett Cooper wrote: > David Wolfskill wrote: > > How about: > > > > d254(6.4-S)[10] echo //////// | awk '{ gsub (/\/\/+/, "/"); print }' > > / > > d254(6.4-S)[11] > > > > then? > > This works very well. Is the expression quantifier operator [ `{' > ] not supported in awk like perl, python, tcl, etc? awk is quite old. It implements the historical behaviour of egrep which did not support braces (this is mentioned in the manual page). Braces are a relatively new feature in egrep. They were probably never added to awk because of compatibility issues with existing scripts. By the way, you can use strings as regular expressions so you don't have to enclose them in slashes. This saves you from the ugly escaping with backslashes: echo //////// | awk '{gsub ("/+", "/"); print}' will do what you want. On the other hand, the typical tool for simple search+replace tasks is sed: echo //////// | sed 's=//*=/=g' By the way, when egrep parses brace expressions, it simply translates them to standard expressions. So, when it sees "/{2,}" it converts it to "//+" before creating the DFA. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "The scanf() function is a large and complex beast that often does something almost but not quite entirely unlike what you desired." -- Chris Torek From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 18 19:29:22 2010 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2EDC1065670; Mon, 18 Jan 2010 19:29:22 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 452278FC13; Mon, 18 Jan 2010 19:29:22 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o0IJT5q6001219; Mon, 18 Jan 2010 20:29:20 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o0IJT5IZ001218; Mon, 18 Jan 2010 20:29:05 +0100 (CET) (envelope-from olli) Date: Mon, 18 Jan 2010 20:29:05 +0100 (CET) Message-Id: <201001181929.o0IJT5IZ001218@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG, jhs@berklix.com, dougb@FreeBSD.ORG In-Reply-To: <4B549B67.90206@FreeBSD.org> X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Mon, 18 Jan 2010 20:29:20 +0100 (CET) Cc: Subject: Re: limits for run away Firefox ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 19:29:22 -0000 Doug Barton wrote: > On 01/17/10 17:07, Julian H. Stacey wrote: > > Hi hackers > > I'm tired of my X server occasionaly freezing, swap thrasing, & firefox dumps: > > 4,346,937,344 ~/firefox-bin.core > > so as a temporary cludge I ran > > touch ~/firefox-bin.core ; chmod 000 ~/firefox-bin.core > > Sorry I don't have a solution to your actual problem, but a better way > to deal with this is to do: ln -s /dev/null ~/firefox-bin.core I think not generating a core dump at all is better than writing 4 GB to /dev/null. Thus: alias firefox='/usr/bin/limits -c 0 /usr/local/bin/firefox3' solves the problem of not generating a core dump. Of course, if firefox is started by other means (e.g. through a desktop icon or a WM menu), the "limits -c 0" command should be added there instead. By the way, if you don't want any coredumps at all, you can disable them globally with sysctl kern.coredump=0. Another part of the problem is that the firefox process grows that big at all. I suggest you watch the size of the process during normal operation ("SIZE" in top(1) or "VSS" in ps(1)), and then make an apropriate virtualmem size limit for the firefox process. This is the -v option to the limits(1) tool. HTH. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Perl will consistently give you what you want, unless what you want is consistency." -- Larry Wall From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 18 20:25:45 2010 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E23A7106568B for ; Mon, 18 Jan 2010 20:25:45 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 7664C8FC1D for ; Mon, 18 Jan 2010 20:25:45 +0000 (UTC) Received: (qmail 24873 invoked by uid 399); 18 Jan 2010 20:25:44 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 18 Jan 2010 20:25:44 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4B54C3C7.5040904@FreeBSD.org> Date: Mon, 18 Jan 2010 12:25:43 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.5) Gecko/20100114 Thunderbird/3.0 MIME-Version: 1.0 To: Oliver Fromme References: <201001181929.o0IJT5IZ001218@lurza.secnetix.de> In-Reply-To: <201001181929.o0IJT5IZ001218@lurza.secnetix.de> X-Enigmail-Version: 1.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.ORG, jhs@berklix.com Subject: Re: limits for run away Firefox ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 20:25:46 -0000 On 01/18/10 11:29, Oliver Fromme wrote: > Doug Barton wrote: > > On 01/17/10 17:07, Julian H. Stacey wrote: > > > Hi hackers > > > I'm tired of my X server occasionaly freezing, swap thrasing, & firefox dumps: > > > 4,346,937,344 ~/firefox-bin.core > > > so as a temporary cludge I ran > > > touch ~/firefox-bin.core ; chmod 000 ~/firefox-bin.core > > > > Sorry I don't have a solution to your actual problem, but a better way > > to deal with this is to do: ln -s /dev/null ~/firefox-bin.core > > I think not generating a core dump at all is better than > writing 4 GB to /dev/null. A) The method I proposed is useful for other things too, and as you pointed out it can sometimes be difficult to track down all the ways a given thing is started. B) If we're going to be snarky, it would be far better if it didn't need to dump core in the first place. :) Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 19 09:42:03 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A65A106566B for ; Tue, 19 Jan 2010 09:42:03 +0000 (UTC) (envelope-from list@sheringeorge.co.cc) Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by mx1.freebsd.org (Postfix) with ESMTP id 7F19B8FC0C for ; Tue, 19 Jan 2010 09:42:03 +0000 (UTC) Received: by pxi13 with SMTP id 13so2648269pxi.3 for ; Tue, 19 Jan 2010 01:42:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.90.12 with SMTP id s12mr3481527rvl.123.1263892768978; Tue, 19 Jan 2010 01:19:28 -0800 (PST) Date: Tue, 19 Jan 2010 14:49:28 +0530 Message-ID: <7f14551c1001190119x46c6b04dx2362cd1252f0d81@mail.gmail.com> From: Sherin George To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Setting "zfs_arc_max" value in FreeBSD 8. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 09:42:03 -0000 Hello, I am trying to tune ZFS file system by setting "zfs_arc_max" value in FreeBSD 8. In solaris, it is achieved like this ================================================= For example, if an application needs 5 GBytes of memory on a system with 36-GBytes of memory, you could set the arc maximum to 30 GBytes, (0x780000000 or 32212254720 bytes). Set the zfs:zfs_arc_max parameter in the /etc/system file: set zfs:zfs_arc_max = 0x780000000 or set zfs:zfs_arc_max = 32212254720 ================================================= But, I couldn't find /etc/system file in FreeBSD. Could some one please guide me to correctly configure "zfs_arc_max" in FreeBSD 8. -- Best Regards, Sherin From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 19 09:46:23 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D23B110656A8 for ; Tue, 19 Jan 2010 09:46:23 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 8DCDA8FC14 for ; Tue, 19 Jan 2010 09:46:23 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1NXAfC-0004et-2U for freebsd-hackers@freebsd.org; Tue, 19 Jan 2010 10:46:18 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Jan 2010 10:46:18 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Jan 2010 10:46:18 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Tue, 19 Jan 2010 10:45:59 +0100 Lines: 34 Message-ID: References: <7f14551c1001190119x46c6b04dx2362cd1252f0d81@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.5) Gecko/20100118 Thunderbird/3.0 In-Reply-To: <7f14551c1001190119x46c6b04dx2362cd1252f0d81@mail.gmail.com> Sender: news Subject: Re: Setting "zfs_arc_max" value in FreeBSD 8. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 09:46:23 -0000 On 01/19/10 10:19, Sherin George wrote: > Hello, > > I am trying to tune ZFS file system by setting "zfs_arc_max" value in > FreeBSD 8. > > In solaris, it is achieved like this > > ================================================= > For example, if an application needs 5 GBytes of memory on a system with > 36-GBytes of memory, you could set the arc maximum to 30 GBytes, > (0x780000000 or 32212254720 bytes). Set the zfs:zfs_arc_max parameter in the > /etc/system file: > > set zfs:zfs_arc_max = 0x780000000 > > or > > set zfs:zfs_arc_max = 32212254720 > ================================================= > > But, I couldn't find /etc/system file in FreeBSD. > > Could some one please guide me to correctly configure "zfs_arc_max" in > FreeBSD 8. You should probably start here: http://wiki.freebsd.org/ZFSTuningGuide and more generally, here: http://wiki.freebsd.org/ZFS From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 19 10:16:06 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 836141065676 for ; Tue, 19 Jan 2010 10:16:06 +0000 (UTC) (envelope-from list@sheringeorge.co.cc) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx1.freebsd.org (Postfix) with ESMTP id 64EDD8FC1D for ; Tue, 19 Jan 2010 10:16:05 +0000 (UTC) Received: by pwi15 with SMTP id 15so2469712pwi.3 for ; Tue, 19 Jan 2010 02:16:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.214.8 with SMTP id r8mr5210078rvq.268.1263896165023; Tue, 19 Jan 2010 02:16:05 -0800 (PST) In-Reply-To: References: <7f14551c1001190119x46c6b04dx2362cd1252f0d81@mail.gmail.com> Date: Tue, 19 Jan 2010 15:46:04 +0530 Message-ID: <7f14551c1001190216w49814186n1ada2b721380502b@mail.gmail.com> From: Sherin George To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Setting "zfs_arc_max" value in FreeBSD 8. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 10:16:06 -0000 Thanks Ivan :) I found It. add following in /boot/loader.conf =================== vfs.zfs.arc_max="10244M" =================== -- Best Regards, Sherin On Tue, Jan 19, 2010 at 3:15 PM, Ivan Voras wrote: > On 01/19/10 10:19, Sherin George wrote: > >> Hello, >> >> I am trying to tune ZFS file system by setting "zfs_arc_max" value in >> FreeBSD 8. >> >> In solaris, it is achieved like this >> >> ================================================= >> For example, if an application needs 5 GBytes of memory on a system with >> 36-GBytes of memory, you could set the arc maximum to 30 GBytes, >> (0x780000000 or 32212254720 bytes). Set the zfs:zfs_arc_max parameter in >> the >> /etc/system file: >> >> set zfs:zfs_arc_max = 0x780000000 >> >> or >> >> set zfs:zfs_arc_max = 32212254720 >> ================================================= >> >> But, I couldn't find /etc/system file in FreeBSD. >> >> Could some one please guide me to correctly configure "zfs_arc_max" in >> FreeBSD 8. >> > > You should probably start here: > > http://wiki.freebsd.org/ZFSTuningGuide > > and more generally, here: > > http://wiki.freebsd.org/ZFS > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 19 11:01:50 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 569011065692 for ; Tue, 19 Jan 2010 11:01:50 +0000 (UTC) (envelope-from bvgastel@bitpowder.com) Received: from rustug.science.ru.nl (rustug.science.ru.nl [131.174.16.158]) by mx1.freebsd.org (Postfix) with ESMTP id 06BB08FC1B for ; Tue, 19 Jan 2010 11:01:48 +0000 (UTC) Received: from smeltpunt.science.ru.nl (smeltpunt.science.ru.nl [131.174.16.145]) by rustug.science.ru.nl (8.13.7/5.31) with ESMTP id o0JAiDf6007069 for ; Tue, 19 Jan 2010 11:44:14 +0100 (MET) Received: from [10.0.1.2] (shadowfax.bitpowder.com [145.99.244.126]) (authen=bernardg) by smeltpunt.science.ru.nl (8.13.7/5.31) with ESMTP id o0JAi9WN013448 for ; Tue, 19 Jan 2010 11:44:09 +0100 (MET) From: Bernard van Gastel Content-Type: multipart/signed; boundary=Apple-Mail-1--24675925; protocol="application/pkcs7-signature"; micalg=sha1 Date: Tue, 19 Jan 2010 11:44:08 +0100 Message-Id: <71A129DC-68A0-46C3-956D-C8AFF1BA29E1@bitpowder.com> To: freebsd-hackers@freebsd.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) X-Spam-Score: 0.001 () BAYES_50 X-Scanned-By: MIMEDefang 2.63 on 131.174.16.145 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: pthread_{mutex,cond} & fifo/starvation/scheduling policy X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 11:01:50 -0000 --Apple-Mail-1--24675925 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi everyone, I'm curious to the exact scheduling policy of POSIX threads in relation = to mutexes and conditions. If there are two threads (a & b), both with = the following code: while (1) { pthread_mutex_lock(mutex); ... pthread_mutex_unlock(mutex); } What is the scheduling policy of the different thread libraries? Are = both threads getting an equal amount of time? Are there no starvation = issues (are they executed in alternating turns)? (a test program of mine = indicates that libpthread and libthr both have starvation issues, in = contrary to Mac OS X 10.6) Also, I'm interested in the scheduling behaviour in combination with = pthread_cond. Get a signalled thread priority to relock the mutex it is = waiting on, or is the relock operation just a normal lock operation and = is handled as such? (so different kind of starvation issues can occur in = the latter case) I have googled extensively and browsed the libthr sources, but can't = find the specs that I'm looking for. Any help will appreciated. With regards, Bernard van Gastel= --Apple-Mail-1--24675925-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 19 11:16:37 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0756D106568F for ; Tue, 19 Jan 2010 11:16:37 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id BF0EE8FC14 for ; Tue, 19 Jan 2010 11:16:36 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id AC7871FFC4D; Tue, 19 Jan 2010 11:16:35 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 8DFC9844BD; Tue, 19 Jan 2010 12:16:35 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Bernard van Gastel References: <71A129DC-68A0-46C3-956D-C8AFF1BA29E1@bitpowder.com> Date: Tue, 19 Jan 2010 12:16:35 +0100 In-Reply-To: <71A129DC-68A0-46C3-956D-C8AFF1BA29E1@bitpowder.com> (Bernard van Gastel's message of "Tue, 19 Jan 2010 11:44:08 +0100") Message-ID: <86hbqifip8.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: pthread_{mutex,cond} & fifo/starvation/scheduling policy X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 11:16:37 -0000 Bernard van Gastel writes: > What is the scheduling policy of the different thread libraries? Threads are scheduled by the kernel, not by the library. Look at sys/kern/sched_umtx.c and sys/kern/sched_{4bsd,ule}.c. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 19 09:49:18 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0350F1065670 for ; Tue, 19 Jan 2010 09:49:18 +0000 (UTC) (envelope-from kraduk@googlemail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id 613118FC14 for ; Tue, 19 Jan 2010 09:49:16 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 19so201172fgg.13 for ; Tue, 19 Jan 2010 01:49:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=nKzIPy7f5agLJD8yE/OpV92+ix2Z4Wa0p+qBxXs8msw=; b=oMwDY5nAgpYpI4IGEUqIoVsJpuLZqXDkVNjaMf57jWohzzg024886vw/n3ZzBwzKSw JWXAqL4RgieLVInzjfOH47cciNwMoVhXXfomgwWANEF1iqRem8tuIp7etktjQh1ixga0 mXpLdTsRaMeUPEr/CgZmen3A2+AiH3PouWoEs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fsWngWq8cLDLYT1SBYLWCqfeHW14wGU0eUZlUpc+hWBOMpIIKGHeLELNZx+Pcof6ea q6xJ8kibaAe4NwmepoV0pfPjJULLTvaj7HrKUitF2QbdxngiSjYHXdzqKorWk1C+O2YF 2FaIZTv3Z3cDWagigvZfsLnH+oT6nU/qV7yh4= MIME-Version: 1.0 Received: by 10.239.190.137 with SMTP id x9mr140890hbh.18.1263894556135; Tue, 19 Jan 2010 01:49:16 -0800 (PST) In-Reply-To: References: <7f14551c1001190119x46c6b04dx2362cd1252f0d81@mail.gmail.com> Date: Tue, 19 Jan 2010 09:49:16 +0000 Message-ID: From: krad To: Ivan Voras X-Mailman-Approved-At: Tue, 19 Jan 2010 12:23:47 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: Setting "zfs_arc_max" value in FreeBSD 8. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 09:49:18 -0000 2010/1/19 Ivan Voras > On 01/19/10 10:19, Sherin George wrote: > >> Hello, >> >> I am trying to tune ZFS file system by setting "zfs_arc_max" value in >> FreeBSD 8. >> >> In solaris, it is achieved like this >> >> ================================================= >> For example, if an application needs 5 GBytes of memory on a system with >> 36-GBytes of memory, you could set the arc maximum to 30 GBytes, >> (0x780000000 or 32212254720 bytes). Set the zfs:zfs_arc_max parameter in >> the >> /etc/system file: >> >> set zfs:zfs_arc_max = 0x780000000 >> >> or >> >> set zfs:zfs_arc_max = 32212254720 >> ================================================= >> >> But, I couldn't find /etc/system file in FreeBSD. >> >> Could some one please guide me to correctly configure "zfs_arc_max" in >> FreeBSD 8. >> > > You should probably start here: > > http://wiki.freebsd.org/ZFSTuningGuide > > and more generally, here: > > http://wiki.freebsd.org/ZFS > > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > sysctl vfs.zfs.arc_max=XXXX add it to /etc/sysctl.conf to make persistent From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 19 14:25:23 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC44A1065693 for ; Tue, 19 Jan 2010 14:25:23 +0000 (UTC) (envelope-from lsimakov@gmail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id 81C9A8FC28 for ; Tue, 19 Jan 2010 14:25:23 +0000 (UTC) Received: by mail-fx0-f218.google.com with SMTP id 10so756851fxm.14 for ; Tue, 19 Jan 2010 06:25:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=lO3yNmqXVab0qoKb38cJ9IqrDB9aB+KKmbLt6IIFV+U=; b=TZ/Arn51rXZJl3I0YzUOtvudPUHUDpqTCvUiay/0FcWmMHN6uaa5rGrDakn0WtQ9K0 79fb8s1YEKeYb/tKzz4GBxqidMfVWMQSKMnBgGVRMTDHpOnpPTe5KZjVjr31f5FyFEEM rKfuUEtYfWgtts8OTn5snAL32bayVD/asjyHA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=CeCc2EPd1cELUF+pV8ecZT2fbOG+nNYkEKuVnOzwzLMxxgJO99e4t/xCpb6Y4C/ke4 602yvuKfwwTFRwJDeCeWzQoUSmRkLZ1pPdo/81Y4eDDUfZJzu+R7SnT26377GvaZjwaM 8woYS6Wqv5PtYOimvCrtQFjuqfgSL6E/CZTeQ= MIME-Version: 1.0 Received: by 10.216.88.139 with SMTP id a11mr2880908wef.50.1263911122954; Tue, 19 Jan 2010 06:25:22 -0800 (PST) In-Reply-To: <201001151711.23061.max@love2party.net> References: <201001151711.23061.max@love2party.net> Date: Tue, 19 Jan 2010 17:25:22 +0300 Message-ID: From: q q To: Max Laier Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: Q:possibility PFIL+mbuf use for packet spawning X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 14:25:24 -0000 I coded all checksum calculations code. All works ok when i just modifying data of packets(like all T letters to Q letters) But now i get some strange error: packet1: TestMessage. packet2: 2nd message im using on first packet only next code(data is a pointer to char* from mbuf containing strings): TEST[0]='G'; TEST[1]='\0'; int res=m_append(*m,2,TEST); m_fixhdr(*m); printf("res cames from m_append:%d \n",res); printf("new data string is %s \n",data); iph->ip_len+=2;//modifying IP header length Then recalculatin IP and TCP cheksums(correctly seems because network doesnt drop packets) And server got message:"Test Message.Qnd message" As well server reply with ACK=25. So seems no new chars were added. Seems like im overwriting 2nd packet. But why this happening? Thank you :) Yours, Qspirit. PS sorry Max for double mail, forgot to add cc hackers. 2010/1/15 Max Laier > On Friday 15 January 2010 12:26:06 q q wrote: > > I'm using pfil as packet filter for packet modifications. > > > > Is it possible to spawn new packets to network from pfil using mbuf? > > You can call into ip_output with a new mbuf to send a new packet. See for > example pf_send_tcp in contrib/pf/net/pf.c > > > Another question: im using m_append to change packet length and add > > data(its working, at least server got longer message) but when i > wireshark > > clients packets(win machine) i see that i got acknoledge on older length > > not on new one. Am i missunderstanding something? > > Assuming you are talking about tcp packets (otherwise there wouldn't be an > ack), you have to alter the tcp header, checksums, etc. as well. Just > adding > data doesn't work. > > Regards, > -- > Max > From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 19 14:28:21 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3745D1065676 for ; Tue, 19 Jan 2010 14:28:21 +0000 (UTC) (envelope-from lsimakov@gmail.com) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by mx1.freebsd.org (Postfix) with ESMTP id AD5778FC15 for ; Tue, 19 Jan 2010 14:28:20 +0000 (UTC) Received: by ewy26 with SMTP id 26so1038787ewy.3 for ; Tue, 19 Jan 2010 06:28:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=A8fqbOxwurxPyZOyP9o+eoHAaUhq5qS8GbywXdyMB4s=; b=rCbtmYvJH5me1mGFNoH0wWZQ+O80D12ObCALzHyXiQihR1XF8oHUUFrKMpJx5DZsV/ g613/C6QNeFSPRx/FRZT16lVKZsSNDBUEdA3HUFMHmCm2zYeqKZAIJzaJTm2kLQGoQdu H2id+/2g+S3WPp94VwQZfaO3z4KOKoRuz2z04= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=c+sqHF7sh262dR8Kpo9Aob04dVW8CCstOePwb1TycK0X66uJv6m9ekJA5n58jnVANY hy4CY/5gdCC2QcKVUzDQCD9mnnFlJRdts8MJX1f8Qyjs1/ZA3BLc1ks6MBgCEYsrtVBn aPzwyNqLUu6Bl5qOfhHXzZDW+SXUOVr40g7Ms= MIME-Version: 1.0 Received: by 10.216.85.213 with SMTP id u63mr512613wee.15.1263911299468; Tue, 19 Jan 2010 06:28:19 -0800 (PST) In-Reply-To: References: <201001151711.23061.max@love2party.net> Date: Tue, 19 Jan 2010 17:28:19 +0300 Message-ID: From: q q To: Max Laier Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: Q:possibility PFIL+mbuf use for packet spawning X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 14:28:21 -0000 Error: line And server got message:"Test Message.Qnd message" should read as line And server got message:"Test Message.G\0d message". Sent you last logs, big Apologises :( 2010/1/19 q q > > I coded all checksum calculations code. All works ok when i just modifying > data of packets(like all T letters to Q letters) > > But now i get some strange error: > packet1: TestMessage. > packet2: 2nd message > > im using on first packet only next code(data is a pointer to char* from > mbuf containing strings): > > TEST[0]='G'; > TEST[1]='\0'; > int res=m_append(*m,2,TEST); > m_fixhdr(*m); > printf("res cames from m_append:%d \n",res); > printf("new data string is %s \n",data); > iph->ip_len+=2;//modifying IP header length > > Then recalculatin IP and TCP cheksums(correctly seems because network > doesnt drop packets) > > And server got message:"Test Message.Qnd message" As well server reply with > ACK=25. So seems no new chars were added. > Seems like im overwriting 2nd packet. But why this happening? > > Thank you :) > > Yours, Qspirit. > > PS sorry Max for double mail, forgot to add cc hackers. > > 2010/1/15 Max Laier > >> On Friday 15 January 2010 12:26:06 q q wrote: >> >> > I'm using pfil as packet filter for packet modifications. >> > >> > Is it possible to spawn new packets to network from pfil using mbuf? >> >> You can call into ip_output with a new mbuf to send a new packet. See for >> example pf_send_tcp in contrib/pf/net/pf.c >> >> > Another question: im using m_append to change packet length and add >> > data(its working, at least server got longer message) but when i >> wireshark >> > clients packets(win machine) i see that i got acknoledge on older >> length >> > not on new one. Am i missunderstanding something? >> >> Assuming you are talking about tcp packets (otherwise there wouldn't be an >> ack), you have to alter the tcp header, checksums, etc. as well. Just >> adding >> data doesn't work. >> >> Regards, >> -- >> Max >> > > From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 19 14:46:11 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D6D210656C7 for ; Tue, 19 Jan 2010 14:46:11 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-qy0-f174.google.com (mail-qy0-f174.google.com [209.85.221.174]) by mx1.freebsd.org (Postfix) with ESMTP id F0D8C8FC1D for ; Tue, 19 Jan 2010 14:46:10 +0000 (UTC) Received: by qyk4 with SMTP id 4so2353539qyk.7 for ; Tue, 19 Jan 2010 06:46:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=DS5Xbcr8saUcIy5U5DP6bUJJZV2BiPc/98tVNBNE0yA=; b=Sande7/L8eESF10MKSmEWpTHRwQA2q3r6xoEgdfYurlRaPlJaLvEFaLGi8FM8Mi8X+ wFJHfk9PsOuWLFY8PmsgAAF844U/H+1Z7wQ4F6+RhEWHw3D+fcq9rGK+fqssWMtqzidx 27yIZoN1tGcKVZITPj3ZbUNlkp9kxwqP2S1Wc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=AQJXYSRzhQI/VqpUHYfnTusapFbNOOMRm6EhVWJHsXeiOCecmvJ1J3uSw/2zuYt8cE WH53kEXS8hRciMaMOMAdAg8/zK+poLE55foUDhDwkvRP461b60OjMmeYv1zGFGlsOgeP GXKoBDWpvfxi74YWyUtWoYdXEHQ3GaL0su82I= Received: by 10.224.13.145 with SMTP id c17mr3081633qaa.244.1263912366483; Tue, 19 Jan 2010 06:46:06 -0800 (PST) Received: from ?192.168.31.4? (ppp-22.65.dialinfree.com [209.172.22.65]) by mx.google.com with ESMTPS id 23sm6128109qyk.3.2010.01.19.06.46.02 (version=SSLv3 cipher=RC4-MD5); Tue, 19 Jan 2010 06:46:04 -0800 (PST) Sender: "J. Hellenthal" Message-ID: <4B55C5A6.2020109@DataIX.net> Date: Tue, 19 Jan 2010 09:45:58 -0500 From: jhell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <7f14551c1001190119x46c6b04dx2362cd1252f0d81@mail.gmail.com> <7f14551c1001190216w49814186n1ada2b721380502b@mail.gmail.com> In-Reply-To: <7f14551c1001190216w49814186n1ada2b721380502b@mail.gmail.com> X-Enigmail-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: Setting "zfs_arc_max" value in FreeBSD 8. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 14:46:11 -0000 On 1/19/2010 5:16 AM, Sherin George wrote: > Thanks Ivan :) > > I found It. add following in /boot/loader.conf > > =================== > vfs.zfs.arc_max="10244M" > =================== > > -- > Best Regards, > Sherin > > On Tue, Jan 19, 2010 at 3:15 PM, Ivan Voras wrote: > >> On 01/19/10 10:19, Sherin George wrote: >> >>> Hello, >>> >>> I am trying to tune ZFS file system by setting "zfs_arc_max" value in >>> FreeBSD 8. >>> >>> In solaris, it is achieved like this >>> >>> ================================================= >>> For example, if an application needs 5 GBytes of memory on a system with >>> 36-GBytes of memory, you could set the arc maximum to 30 GBytes, >>> (0x780000000 or 32212254720 bytes). Set the zfs:zfs_arc_max parameter in >>> the >>> /etc/system file: >>> >>> set zfs:zfs_arc_max = 0x780000000 >>> >>> or >>> >>> set zfs:zfs_arc_max = 32212254720 >>> ================================================= >>> >>> But, I couldn't find /etc/system file in FreeBSD. >>> >>> Could some one please guide me to correctly configure "zfs_arc_max" in >>> FreeBSD 8. >>> >> >> You should probably start here: >> >> http://wiki.freebsd.org/ZFSTuningGuide >> >> and more generally, here: >> >> http://wiki.freebsd.org/ZFS >> I just thought I would give a shout at this for stable/7 as of last week. I am not sure if this is just me but I had tried to adjust zfs_arc_max and found out that it was unadjusted to my value after the system came back up. Anyone know if it is adjustable on a system with 1024MB of ram ? Is this just being auto calculated by some other value ? -- jhell From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 19 18:46:20 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C2001065693 for ; Tue, 19 Jan 2010 18:46:20 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email1.allantgroup.com (email1.emsphone.com [199.67.51.115]) by mx1.freebsd.org (Postfix) with ESMTP id D604A8FC29 for ; Tue, 19 Jan 2010 18:46:19 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email1.allantgroup.com (8.14.0/8.14.0) with ESMTP id o0JIkIGM027120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 19 Jan 2010 12:46:19 -0600 (CST) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.4/8.14.3) with ESMTP id o0JIkIDh019435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 19 Jan 2010 12:46:18 -0600 (CST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.4/8.14.3/Submit) id o0JIkI7D019433; Tue, 19 Jan 2010 12:46:18 -0600 (CST) (envelope-from dan) Date: Tue, 19 Jan 2010 12:46:17 -0600 From: Dan Nelson To: Bernard van Gastel Message-ID: <20100119184617.GB50360@dan.emsphone.com> References: <71A129DC-68A0-46C3-956D-C8AFF1BA29E1@bitpowder.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <71A129DC-68A0-46C3-956D-C8AFF1BA29E1@bitpowder.com> X-OS: FreeBSD 7.2-STABLE User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: clamav-milter 0.95.3 at email1.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (email1.allantgroup.com [199.67.51.78]); Tue, 19 Jan 2010 12:46:19 -0600 (CST) X-Scanned-By: MIMEDefang 2.45 Cc: freebsd-hackers@freebsd.org Subject: Re: pthread_{mutex,cond} & fifo/starvation/scheduling policy X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 18:46:20 -0000 In the last episode (Jan 19), Bernard van Gastel said: > I'm curious to the exact scheduling policy of POSIX threads in relation to > mutexes and conditions. If there are two threads (a & b), both with the > following code: > > while (1) { > pthread_mutex_lock(mutex); > ... > pthread_mutex_unlock(mutex); > } > > What is the scheduling policy of the different thread libraries? Are both > threads getting an equal amount of time? Are there no starvation issues > (are they executed in alternating turns)? (a test program of mine > indicates that libpthread and libthr both have starvation issues, in > contrary to Mac OS X 10.6) There's no guarantee of fairness when dealing with mutexes afaik. My guess is that if thread "a" unlocks the mutex and still has time left in its quantum, it'll be able to grab it again without even going to the kernel. >From the POSIX docs on mutexes: http://www.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_lock.html#tag_16_439_08 "Mutex objects are intended to serve as a low-level primitive from which other thread synchronization functions can be built. As such, the implementation of mutexes should be as efficient as possible, and this has ramifications on the features available at the interface. The mutex functions and the particular default settings of the mutex attributes have been motivated by the desire to not preclude fast, inlined implementations of mutex locking and unlocking." The idea being that mutexes should be held for as little time as possible. Is there a way to write your code so that most of the CPU-consuming activity is done outside of the mutex? Perhaps use a job queue of some sort, and only lock the mutex when pushing/popping elements. Then worker processes can run without holding the mutex, and will be fairly scheduled by the kernel. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 19 20:13:53 2010 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62CAA1065670 for ; Tue, 19 Jan 2010 20:13:53 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from hamlet.setfilepointer.com (hamlet.SetFilePointer.com [63.224.10.2]) by mx1.freebsd.org (Postfix) with SMTP id 0EC188FC0A for ; Tue, 19 Jan 2010 20:13:52 +0000 (UTC) Received: (qmail 95424 invoked from network); 19 Jan 2010 14:13:51 -0600 Received: from keira.kiwi-computer.com (HELO kiwi-computer.com) (63.224.10.3) by hamlet.setfilepointer.com with SMTP; 19 Jan 2010 14:13:51 -0600 Received: (qmail 76593 invoked by uid 2001); 19 Jan 2010 20:13:51 -0000 Date: Tue, 19 Jan 2010 14:13:51 -0600 From: "Rick C. Petty" To: Doug Barton Message-ID: <20100119201351.GA76360@keira.kiwi-computer.com> References: <201001181929.o0IJT5IZ001218@lurza.secnetix.de> <4B54C3C7.5040904@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B54C3C7.5040904@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@FreeBSD.ORG, jhs@berklix.com, Oliver Fromme Subject: Re: limits for run away Firefox ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd2009@kiwi-computer.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 20:13:53 -0000 On Mon, Jan 18, 2010 at 12:25:43PM -0800, Doug Barton wrote: > On 01/18/10 11:29, Oliver Fromme wrote: > > Doug Barton wrote: > > > On 01/17/10 17:07, Julian H. Stacey wrote: > > > > Hi hackers > > > > I'm tired of my X server occasionaly freezing, swap thrasing, & firefox dumps: > > > > 4,346,937,344 ~/firefox-bin.core > > > > so as a temporary cludge I ran > > > > touch ~/firefox-bin.core ; chmod 000 ~/firefox-bin.core > > > > > > Sorry I don't have a solution to your actual problem, but a better way > > > to deal with this is to do: ln -s /dev/null ~/firefox-bin.core > > > > I think not generating a core dump at all is better than > > writing 4 GB to /dev/null. > > A) The method I proposed is useful for other things too, and as you > pointed out it can sometimes be difficult to track down all the ways a > given thing is started. What about just adding the limit command to the /usr/local/bin/firefox script? That would guarantee any instantiation of firefox wouldn't dump core. > B) If we're going to be snarky, it would be far better if it didn't need > to dump core in the first place. :) I don't think that Oliver was at all snarky. He was merely suggesting a solution which would prevent the core file from being generated at all; the OP was tired of the extra time spent and Oliver's suggestion would certainly reduce this time. The symlink seems to hackish to me, although I've had to use it often in other situations. And in some cases the culprit would unlink(2) it first, so I've had to "chflags noschg" it, which works better than "chmod 000" (if the FS supports it). But I agree that it would be nice to prevent ffox from segfaulting; unfortunately this is one of those apps which segfaults a lot (for me at least). =) Cheers, -- Rick C. Petty From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 19 21:50:34 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8299106566C for ; Tue, 19 Jan 2010 21:50:34 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.29.23]) by mx1.freebsd.org (Postfix) with ESMTP id 4B0588FC23 for ; Tue, 19 Jan 2010 21:50:33 +0000 (UTC) Received: from [78.34.165.227] (helo=r500.local) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1NXLy3-0006v1-Vl for freebsd-hackers@freebsd.org; Tue, 19 Jan 2010 22:50:32 +0100 Date: Tue, 19 Jan 2010 22:51:02 +0100 From: Fabian Keil To: freebsd-hackers@freebsd.org Message-ID: <20100119225102.2c4197ce@r500.local> In-Reply-To: <20100119201351.GA76360@keira.kiwi-computer.com> References: <201001181929.o0IJT5IZ001218@lurza.secnetix.de> <4B54C3C7.5040904@FreeBSD.org> <20100119201351.GA76360@keira.kiwi-computer.com> X-Mailer: Claws Mail 3.7.3 (GTK+ 2.18.5; amd64-portbld-freebsd9.0) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2008-08-18.asc Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/odZj0u8+V/g.u2hK49L_Wlb"; protocol="application/pgp-signature" X-Df-Sender: 775067 Subject: Re: limits for run away Firefox ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 21:50:34 -0000 --Sig_/odZj0u8+V/g.u2hK49L_Wlb Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable "Rick C. Petty" wrote: > On Mon, Jan 18, 2010 at 12:25:43PM -0800, Doug Barton wrote: > > On 01/18/10 11:29, Oliver Fromme wrote: > > > Doug Barton wrote: > > > > On 01/17/10 17:07, Julian H. Stacey wrote: > > > > > Hi hackers > > > > > I'm tired of my X server occasionaly freezing, swap thrasing, & > > > > > firefox dumps: 4,346,937,344 ~/firefox-bin.core > > > > > so as a temporary cludge I ran > > > > > touch ~/firefox-bin.core ; chmod 000 ~/firefox-bin.core > > > >=20 > > > > Sorry I don't have a solution to your actual problem, but a > > > > better way to deal with this is to do: ln -s /dev/null > > > > ~/firefox-bin.core > > >=20 > > > I think not generating a core dump at all is better than > > > writing 4 GB to /dev/null. > >=20 > > A) The method I proposed is useful for other things too, and as you > > pointed out it can sometimes be difficult to track down all the ways a > > given thing is started. >=20 > What about just adding the limit command to the /usr/local/bin/firefox > script? That would guarantee any instantiation of firefox wouldn't dump > core. Until the next update ... > > B) If we're going to be snarky, it would be far better if it didn't > > need to dump core in the first place. :) >=20 > I don't think that Oliver was at all snarky. He was merely suggesting a > solution which would prevent the core file from being generated at all; > the OP was tired of the extra time spent and Oliver's suggestion would > certainly reduce this time. >=20 > The symlink seems to hackish to me, although I've had to use it often in > other situations. And in some cases the culprit would unlink(2) it > first, so I've had to "chflags noschg" it, which works better than > "chmod 000" (if the FS supports it). >=20 > But I agree that it would be nice to prevent ffox from segfaulting; > unfortunately this is one of those apps which segfaults a lot (for me at > least). =3D) I get a lot less segfaults since I disabled ogg support (which never worked for me anyway): about:config -> media.ogg.enabled =3D false Fabian --Sig_/odZj0u8+V/g.u2hK49L_Wlb Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAktWKU0ACgkQBYqIVf93VJ3jOQCgrhoQJwdKs5h6g9T03/gwVp3y aFUAniCez+5xEUIrUBnW39hFkgen95aJ =OK17 -----END PGP SIGNATURE----- --Sig_/odZj0u8+V/g.u2hK49L_Wlb-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 19 21:54:23 2010 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E0BF106566B; Tue, 19 Jan 2010 21:54:23 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 990548FC12; Tue, 19 Jan 2010 21:54:22 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o0JLs5w3070883; Tue, 19 Jan 2010 22:54:20 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o0JLs4oS070881; Tue, 19 Jan 2010 22:54:04 +0100 (CET) (envelope-from olli) From: Oliver Fromme Message-Id: <201001192154.o0JLs4oS070881@lurza.secnetix.de> To: rick-freebsd2009@kiwi-computer.com Date: Tue, 19 Jan 2010 22:54:04 +0100 (CET) In-Reply-To: <20100119201351.GA76360@keira.kiwi-computer.com> X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 19 Jan 2010 22:54:21 +0100 (CET) Cc: freebsd-hackers@FreeBSD.org, jhs@berklix.com, Doug Barton Subject: Re: limits for run away Firefox ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 21:54:23 -0000 Rick C. Petty wrote: > On Mon, Jan 18, 2010 at 12:25:43PM -0800, Doug Barton wrote: > > On 01/18/10 11:29, Oliver Fromme wrote: > > > Doug Barton wrote: > > > > On 01/17/10 17:07, Julian H. Stacey wrote: > > > > > Hi hackers > > > > > I'm tired of my X server occasionaly freezing, swap thrasing, & firefox dumps: > > > > > 4,346,937,344 ~/firefox-bin.core > > > > > so as a temporary cludge I ran > > > > > touch ~/firefox-bin.core ; chmod 000 ~/firefox-bin.core > > > > > > > > Sorry I don't have a solution to your actual problem, but a better way > > > > to deal with this is to do: ln -s /dev/null ~/firefox-bin.core > > > > > > I think not generating a core dump at all is better than > > > writing 4 GB to /dev/null. > > > > A) The method I proposed is useful for other things too, and as you > > pointed out it can sometimes be difficult to track down all the ways a > > given thing is started. > > What about just adding the limit command to the /usr/local/bin/firefox > script? That would guarantee any instantiation of firefox wouldn't dump > core. Many users probably don't want any core dumps at all, so disabling them completely would be the best and easiest solution for them. This can be done globally (either with the sysctl or via /etc/login.conf) or per-user via ~/.login_conf. Then you don't have to track down the ways a given thing is started. > > B) If we're going to be snarky, it would be far better if it didn't need > > to dump core in the first place. :) > > I don't think that Oliver was at all snarky. The word "snarky" isn't even in my dictionary, so I can only guess what it means. Anyway, my suggestion was meant to be completely serious, without any irony or other undertone. I'm not a native English speaker, so maybe my words expressed a meaning that wasn't intended. In that case please allow me to apologize. > But I agree that it would be nice to prevent ffox from segfaulting; Definitely. I agree, too. However, that's a lot more difficult than preventing core dumps being written. > unfortunately this is one of those apps which segfaults a lot (for me at > least). =) One of the reasons why I prefer Opera. :) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "C++ is over-complicated nonsense. And Bjorn Shoestrap's book a danger to public health. I tried reading it once, I was in recovery for months." -- Cliff Sarginson From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 19 22:11:55 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C613E106566B for ; Tue, 19 Jan 2010 22:11:55 +0000 (UTC) (envelope-from wilkinsa@dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id 2777D8FC15 for ; Tue, 19 Jan 2010 22:11:54 +0000 (UTC) Received: from ednmsw520.dsto.defence.gov.au (ednmsw520.dsto.defence.gov.au [131.185.68.60]) by digger1.defence.gov.au (DSTO/DSTO) with ESMTP id o0JLusTS003648 for ; Wed, 20 Jan 2010 08:26:54 +1030 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw520.dsto.defence.gov.au (Clearswift SMTPRS 5.3.2) with ESMTP id for ; Wed, 20 Jan 2010 08:29:31 +1030 Received: from stlex511.dsto.defence.gov.au ([203.6.60.49]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Jan 2010 08:29:31 +1030 Received: from stlux550.dsto.defence.gov.au ([203.6.60.61]) by stlex511.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Jan 2010 05:59:30 +0800 Received: from stlux550.dsto.defence.gov.au (localhost [127.0.0.1]) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3) with ESMTP id o0JLrsg0045434 for ; Wed, 20 Jan 2010 05:53:54 +0800 (WST) (envelope-from wilkinsa@stlux550.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3/Submit) id o0JLrsU9045433 for freebsd-hackers@freebsd.org; Wed, 20 Jan 2010 05:53:54 +0800 (WST) (envelope-from wilkinsa) Date: Wed, 20 Jan 2010 05:53:54 +0800 From: "Wilkinson, Alex" To: freebsd-hackers@freebsd.org Message-ID: <20100119215354.GC45270@stlux503.dsto.defence.gov.au> Mail-Followup-To: freebsd-hackers@freebsd.org References: <201001181929.o0IJT5IZ001218@lurza.secnetix.de> <4B54C3C7.5040904@FreeBSD.org> <20100119201351.GA76360@keira.kiwi-computer.com> <20100119225102.2c4197ce@r500.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20100119225102.2c4197ce@r500.local> Organisation: Defence Science Technology Organisation X-Message-Flag: "Please Restore Line Breaks If Necessary" User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 19 Jan 2010 21:59:30.0464 (UTC) FILETIME=[AD239A00:01CA9952] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-6.000.1038-17142.000 X-TM-AS-Result: No--2.856900-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Content-Transfer-Encoding: 7bit Subject: Re: limits for run away Firefox ? [SEC=UNCLASSIFIED] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 22:11:55 -0000 0n Tue, Jan 19, 2010 at 10:51:02PM +0100, Fabian Keil wrote: >"Rick C. Petty" wrote: > >> On Mon, Jan 18, 2010 at 12:25:43PM -0800, Doug Barton wrote: >> > On 01/18/10 11:29, Oliver Fromme wrote: >> > > Doug Barton wrote: >> > > > On 01/17/10 17:07, Julian H. Stacey wrote: >> > > > > Hi hackers >> > > > > I'm tired of my X server occasionaly freezing, swap thrasing, & >> > > > > firefox dumps: 4,346,937,344 ~/firefox-bin.core >> > > > > so as a temporary cludge I ran >> > > > > touch ~/firefox-bin.core ; chmod 000 ~/firefox-bin.core >> > > > >> > > > Sorry I don't have a solution to your actual problem, but a >> > > > better way to deal with this is to do: ln -s /dev/null >> > > > ~/firefox-bin.core how about using: #chflags schg /firefox-bin.core ? -Alex IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 19 23:09:31 2010 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5AB31065692 for ; Tue, 19 Jan 2010 23:09:30 +0000 (UTC) (envelope-from dougb@dougbarton.us) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 8F6D28FC13 for ; Tue, 19 Jan 2010 23:09:30 +0000 (UTC) Received: (qmail 9833 invoked by uid 399); 19 Jan 2010 22:42:49 -0000 Received: from localhost (HELO ?10.71.6.27?) (127.0.0.1) by localhost with ESMTPM; 19 Jan 2010 22:42:49 -0000 X-Originating-IP: 127.0.0.1 References: <201001192154.o0JLs4oS070881@lurza.secnetix.de> Message-Id: From: Doug Barton To: Oliver Fromme In-Reply-To: <201001192154.o0JLs4oS070881@lurza.secnetix.de> Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (7D11) Mime-Version: 1.0 (iPhone Mail 7D11) Date: Tue, 19 Jan 2010 14:42:31 -0800 X-Mailman-Approved-At: Tue, 19 Jan 2010 23:13:21 +0000 Cc: "rick-freebsd2009@kiwi-computer.com" , "jhs@berklix.com" , Doug Barton , "freebsd-hackers@FreeBSD.org" Subject: Re: limits for run away Firefox ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 23:09:31 -0000 No offense was implied, thus the smiley. ;) Doug Sent from my iPhone On Jan 19, 2010, at 1:54 PM, Oliver Fromme =20 wrote: > > Rick C. Petty wrote: >> On Mon, Jan 18, 2010 at 12:25:43PM -0800, Doug Barton wrote: >>> On 01/18/10 11:29, Oliver Fromme wrote: >>>> Doug Barton wrote: >>>>> On 01/17/10 17:07, Julian H. Stacey wrote: >>>>>> Hi hackers >>>>>> I'm tired of my X server occasionaly freezing, swap thrasing, & =20= >>>>>> firefox dumps: >>>>>> 4,346,937,344 ~/firefox-bin.core >>>>>> so as a temporary cludge I ran >>>>>> touch ~/firefox-bin.core ; chmod 000 ~/firefox-bin.core >>>>> >>>>> Sorry I don't have a solution to your actual problem, but a =20 >>>>> better way >>>>> to deal with this is to do: ln -s /dev/null ~/firefox-bin.core >>>> >>>> I think not generating a core dump at all is better than >>>> writing 4 GB to /dev/null. >>> >>> A) The method I proposed is useful for other things too, and as you >>> pointed out it can sometimes be difficult to track down all the =20 >>> ways a >>> given thing is started. >> >> What about just adding the limit command to the /usr/local/bin/=20 >> firefox >> script? That would guarantee any instantiation of firefox wouldn't =20= >> dump >> core. > > Many users probably don't want any core dumps at all, so > disabling them completely would be the best and easiest > solution for them. This can be done globally (either with > the sysctl or via /etc/login.conf) or per-user via > ~/.login_conf. Then you don't have to track down the > ways a given thing is started. > >>> B) If we're going to be snarky, it would be far better if it =20 >>> didn't need >>> to dump core in the first place. :) >> >> I don't think that Oliver was at all snarky. > > The word "snarky" isn't even in my dictionary, so I can > only guess what it means. > > Anyway, my suggestion was meant to be completely serious, > without any irony or other undertone. I'm not a native > English speaker, so maybe my words expressed a meaning > that wasn't intended. In that case please allow me to > apologize. > >> But I agree that it would be nice to prevent ffox from segfaulting; > > Definitely. I agree, too. However, that's a lot more > difficult than preventing core dumps being written. > >> unfortunately this is one of those apps which segfaults a lot (for =20= >> me at >> least). =3D) > > One of the reasons why I prefer Opera. :) > > Best regards > Oliver > > --=20 > Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing =20= > b. M. > Handelsregister: Registergericht Muenchen, HRA 74606, Gesch=C3=A4ftsfue= h=20 > rung: > secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht =20= > M=C3=BCn- > chen, HRB 125758, Gesch=C3=A4ftsf=C3=BChrer: Maik Bachmann, Olaf Erb, = Ralf Ge=20 > bhart > > FreeBSD-Dienstleistungen, -Produkte und mehr: = http://www.secnetix.de/bsd > > "C++ is over-complicated nonsense. And Bjorn Shoestrap's book > a danger to public health. I tried reading it once, I was in > recovery for months." > -- Cliff Sarginson > From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 20 00:51:56 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 508EF106566C for ; Wed, 20 Jan 2010 00:51:56 +0000 (UTC) (envelope-from lujiandong1001@yahoo.com.cn) Received: from web15704.mail.cnb.yahoo.com (web15704.mail.cnb.yahoo.com [202.165.102.71]) by mx1.freebsd.org (Postfix) with SMTP id B6A9F8FC0C for ; Wed, 20 Jan 2010 00:51:55 +0000 (UTC) Received: (qmail 61931 invoked by uid 60001); 20 Jan 2010 00:51:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.cn; s=s1024; t=1263948713; bh=IxDTMyazZ3vxKWz38fdKKNv3V45SSyBOOUKBzYGKDuU=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=unTE4rRCO+EuRGGJ5G3gpOBmPrl16d1RJ9Zh0Zq+fN7dWjrFS8dls6fc2LBST97q0BbahEqjaYqw5DWf3jkH4RGLy4wuURy4tcgAt1Tb/ylmZ0EoOI/ozv0/dB6tuP4ZZKurywjPy3LeJPGBnEy5cFyPJART8Vy0JgS6O3Zwg6g= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.cn; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=QG0q6shb/NiAnHjnjsOaQiUqp8h10i4xXiGT6AsLhKPWSWj1uKtTiNqKDWjWpvqdiutXAQG4hylAxmAMlE/FkmqXUPkwytxBu7p5HsLOXIjCrrUZ42cNSruxE75WAZc8zRTgsinpWOOfx6mXx6/IaUGVb6fT8ZH0zZXIV/zZ9oo=; Message-ID: <780211.61560.qm@web15704.mail.cnb.yahoo.com> X-YMail-OSG: RRcBoeUVM1lBcMXURbFB2mOJxx6.6FHMPVbjrA0g1kRNrcm_0bpSTI30.dQ_o9eZy9unat.s5i.4_D9e9T_UBcpTdKrlc5x6BmlxkI3O_OZS0yOc79mCbc7KR9U3tNzz7Zc5jTZoj1ubAao9GgNZJQhtIcFlA.FwTZnE3lqxvf0t4NPwbnhY2WjlY2.KCr8w64S_3jqCTCpUja925pC9.PN0KT.fYhhSy1D77UyEblTkQUVSK_b2qy2WWFkZTpg- Received: from [218.241.83.19] by web15704.mail.cnb.yahoo.com via HTTP; Wed, 20 Jan 2010 08:51:53 CST X-Mailer: YahooMailRC/240.3 YahooMailWebService/0.8.100.260964 References: <739519.89145.qm@web15707.mail.cnb.yahoo.com> Date: Wed, 20 Jan 2010 08:51:53 +0800 (CST) From: Jiandong Lu To: Xin LI In-Reply-To: MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 20 Jan 2010 03:00:47 +0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: =?utf-8?b?5Zue5aSN77yaIGFib3V0IGxpYnN0ZGMrKyAsY2hhbmdlIHRoZSBk?= =?utf-8?q?efaule_allocator?= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 00:51:56 -0000 Thanks=0A=0A=0A=0A=0A________________________________=0A=E5=8F=91=E4=BB=B6= =E4=BA=BA=EF=BC=9A Xin LI =0A=E6=94=B6=E4=BB=B6=E4=BA=BA= =EF=BC=9A Jiandong Lu =0A=E6=8A=84 =E9=80=81= =EF=BC=9A freebsd-hackers@freebsd.org=0A=E5=8F=91=E9=80=81=E6=97=A5=E6=9C= =9F=EF=BC=9A 2010/1/15 (=E5=91=A8=E4=BA=94) 2:54:42 =E4=B8=8A=E5=8D=88=0A= =E4=B8=BB =E9=A2=98=EF=BC=9A Re: about libstdc++ ,change the defaule allo= cator=0A=0A2010/1/13 Jiandong Lu :=0A> hello,e= veryone.=0A> =E8=81=BD =E8=81=BD I get the current source code from svn,and= successfully build world.=0A> =E8=81=BD =E8=81=BD c++'s standard library i= s from gnu. This library privodes many allocators:=0A> bitmap_allocator_bas= e=0A> malloc_allocator_base=0A> mt_allocator_base=0A> new_allocator_base=0A= > pool_allocator_base=0A> I want to know how to set a default allocator,and= how to change it.=0A>=0A> I have read the Makefile:=0A> /usr/src/gnu/lib/l= ibstdc++/Makefile=0A=0AI have no idea why you will think the allocator is b= eing changed here...=0A=0AThe standard and portable way to override the all= ocator is at the=0Apoint you instance C++ templates by specifing Allocator = parameter.=0AIf, however, you want to globally change the default allocator= without=0Atouching all your source files, the only way is to make modifica= tion=0Aon c++allocator.h, which is, in my opinion, never permitted by the= =0Astandard and banned by god.=0A=0ACheers,=0A-- =0AXin LI http://www.delphij.net=0A=0A=0A=0A _____________________________= ______________________________ =0A =E5=A5=BD=E7=8E=A9=E8=B4=BA=E5=8D=A1=E7= =AD=89=E4=BD=A0=E5=8F=91=EF=BC=8C=E9=82=AE=E7=AE=B1=E8=B4=BA=E5=8D=A1=E5=85= =A8=E6=96=B0=E4=B8=8A=E7=BA=BF=EF=BC=81 =0Ahttp://card.mail.cn.yahoo.com/ From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 21 10:19:40 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F350106566C for ; Thu, 21 Jan 2010 10:19:40 +0000 (UTC) (envelope-from bvgastel@bitpowder.com) Received: from smeltpunt.science.ru.nl (smeltpunt.science.ru.nl [131.174.16.145]) by mx1.freebsd.org (Postfix) with ESMTP id C4F6D8FC08 for ; Thu, 21 Jan 2010 10:19:39 +0000 (UTC) Received: from [10.0.1.2] (shadowfax.bitpowder.com [145.99.244.126]) (authen=bernardg) by smeltpunt.science.ru.nl (8.13.7/5.31) with ESMTP id o0LAJYiq019518; Thu, 21 Jan 2010 11:19:35 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-1-146649389; protocol="application/pkcs7-signature"; micalg=sha1 From: Bernard van Gastel In-Reply-To: <86hbqifip8.fsf@ds4.des.no> Date: Thu, 21 Jan 2010 11:19:34 +0100 Message-Id: <72CE899C-5941-4659-B922-DC65BB0CE67D@bitpowder.com> References: <71A129DC-68A0-46C3-956D-C8AFF1BA29E1@bitpowder.com> <86hbqifip8.fsf@ds4.des.no> To: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= X-Mailer: Apple Mail (2.1077) X-Spam-Score: 0.001 () BAYES_50 X-Scanned-By: MIMEDefang 2.63 on 131.174.16.145 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: pthread_{mutex,cond} & fifo/starvation/scheduling policy X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 10:19:40 -0000 --Apple-Mail-1-146649389 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 But the descheduling of threads if the mutex is not available is done by = the library. And especially the order of rescheduling of the threads = (thats what I'm interested in). Or am I missing something in the = sys/kern/sched files (btw I don't have the umtx file). Regards, Bernard Op 19 jan 2010, om 12:16 heeft Dag-Erling Sm=F8rgrav het volgende = geschreven: > Bernard van Gastel writes: >> What is the scheduling policy of the different thread libraries? >=20 > Threads are scheduled by the kernel, not by the library. Look at > sys/kern/sched_umtx.c and sys/kern/sched_{4bsd,ule}.c. >=20 > DES > --=20 > Dag-Erling Sm=F8rgrav - des@des.no --Apple-Mail-1-146649389-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 21 10:27:36 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42F221065676 for ; Thu, 21 Jan 2010 10:27:36 +0000 (UTC) (envelope-from bvgastel@bitpowder.com) Received: from smeltpunt.science.ru.nl (smeltpunt.science.ru.nl [131.174.16.145]) by mx1.freebsd.org (Postfix) with ESMTP id E81A68FC18 for ; Thu, 21 Jan 2010 10:27:35 +0000 (UTC) Received: from [10.0.1.2] (shadowfax.bitpowder.com [145.99.244.126]) (authen=bernardg) by smeltpunt.science.ru.nl (8.13.7/5.31) with ESMTP id o0LAROGM019844; Thu, 21 Jan 2010 11:27:24 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-2-147118908; protocol="application/pkcs7-signature"; micalg=sha1 From: Bernard van Gastel In-Reply-To: <20100119184617.GB50360@dan.emsphone.com> Date: Thu, 21 Jan 2010 11:27:23 +0100 Message-Id: <1B4E9B02-AA63-45BF-9BB7-3B0A2884CCB0@bitpowder.com> References: <71A129DC-68A0-46C3-956D-C8AFF1BA29E1@bitpowder.com> <20100119184617.GB50360@dan.emsphone.com> To: Dan Nelson X-Mailer: Apple Mail (2.1077) X-Spam-Score: 0.001 () BAYES_50 X-Scanned-By: MIMEDefang 2.63 on 131.174.16.145 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: pthread_{mutex,cond} & fifo/starvation/scheduling policy X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 10:27:36 -0000 --Apple-Mail-2-147118908 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In real world application such a proposed queue would work almost = always, but I'm trying to exclude all starvation situations primarily = (speed is less relevant). And although such a worker can execute it work = and be scheduled fairly, the addition of the work to the queue can = result in starvation (one of the threads trying to add to the queue = could stall forever if the lock is heavily contested). Is this possible with POSIX thread stuff? Or is the only option to use = IPC like message queues for this? Regards, Bernard Op 19 jan 2010, om 19:46 heeft Dan Nelson het volgende geschreven: > In the last episode (Jan 19), Bernard van Gastel said: >> I'm curious to the exact scheduling policy of POSIX threads in = relation to >> mutexes and conditions. If there are two threads (a & b), both with = the >> following code: >>=20 >> while (1) { >> pthread_mutex_lock(mutex); >> ... >> pthread_mutex_unlock(mutex); >> } >>=20 >> What is the scheduling policy of the different thread libraries? Are = both >> threads getting an equal amount of time? Are there no starvation = issues >> (are they executed in alternating turns)? (a test program of mine >> indicates that libpthread and libthr both have starvation issues, in >> contrary to Mac OS X 10.6) >=20 > There's no guarantee of fairness when dealing with mutexes afaik. My = guess > is that if thread "a" unlocks the mutex and still has time left in its > quantum, it'll be able to grab it again without even going to the = kernel.=20 > =46rom the POSIX docs on mutexes: >=20 > = http://www.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_loc= k.html#tag_16_439_08 >=20 > "Mutex objects are intended to serve as a low-level primitive from = which > other thread synchronization functions can be built. As such, the > implementation of mutexes should be as efficient as possible, and = this > has ramifications on the features available at the interface. >=20 > The mutex functions and the particular default settings of the mutex > attributes have been motivated by the desire to not preclude fast, > inlined implementations of mutex locking and unlocking." >=20 > The idea being that mutexes should be held for as little time as = possible.=20 > Is there a way to write your code so that most of the CPU-consuming = activity > is done outside of the mutex? Perhaps use a job queue of some sort, = and > only lock the mutex when pushing/popping elements. Then worker = processes > can run without holding the mutex, and will be fairly scheduled by the > kernel. >=20 > --=20 > Dan Nelson > dnelson@allantgroup.com --Apple-Mail-2-147118908-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 21 10:31:28 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1295D1065672 for ; Thu, 21 Jan 2010 10:31:28 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id C44FA8FC1C for ; Thu, 21 Jan 2010 10:31:27 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id o0LAVNUT026044; Thu, 21 Jan 2010 05:31:23 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.2 (mail.netplex.net [204.213.176.10]); Thu, 21 Jan 2010 05:31:23 -0500 (EST) Date: Thu, 21 Jan 2010 05:31:23 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Bernard van Gastel In-Reply-To: <72CE899C-5941-4659-B922-DC65BB0CE67D@bitpowder.com> Message-ID: References: <71A129DC-68A0-46C3-956D-C8AFF1BA29E1@bitpowder.com> <86hbqifip8.fsf@ds4.des.no> <72CE899C-5941-4659-B922-DC65BB0CE67D@bitpowder.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , freebsd-hackers@freebsd.org Subject: Re: pthread_{mutex,cond} & fifo/starvation/scheduling policy X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 10:31:28 -0000 On Thu, 21 Jan 2010, Bernard van Gastel wrote: > But the descheduling of threads if the mutex is not available is done > by the library. And especially the order of rescheduling of the > threads (thats what I'm interested in). Or am I missing something in > the sys/kern/sched files (btw I don't have the umtx file). No, it's done by the kernel. Threads block on a umtx in the kernel, and they are also woken up by the kernel. The threads library does not wake up a specific thread - it just calls into the kernel to unlock the umtx and the kernel decides which thread to wake up. You should probably see src/sys/kern/kern_umtx.c. -- DE From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 21 10:37:46 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 589201065679 for ; Thu, 21 Jan 2010 10:37:46 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from mail.embedded-brains.de (host-82-135-62-35.customer.m-online.net [82.135.62.35]) by mx1.freebsd.org (Postfix) with ESMTP id 11C218FC26 for ; Thu, 21 Jan 2010 10:37:45 +0000 (UTC) Received: by mail.embedded-brains.de (Postfix, from userid 65534) id F08086F7D44; Thu, 21 Jan 2010 11:21:59 +0100 (CET) Received: from [192.168.96.31] (eb0011.eb.z [192.168.96.31]) by mail.embedded-brains.de (Postfix) with ESMTP id BCFD56F7D42 for ; Thu, 21 Jan 2010 11:21:56 +0100 (CET) Message-ID: <4B582AC4.9030502@embedded-brains.de> Date: Thu, 21 Jan 2010 11:21:56 +0100 From: Sebastian Huber User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091130 SUSE/3.0.0-17.1 Lightning/1.0b1 Thunderbird/3.0 MIME-Version: 1.0 To: FreeBSD-Hackers Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: ARM and structure size boundary X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 10:37:46 -0000 Hi, on ARM the GCC has an option for the structure size boundary: http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html#ARM-Options In the GCC sources (gcc/config/arm) you see that NetBSD changes the default value to 8 from 32. For FreeBSD I did not found something similar. What value is used on FreeBSD by default? This value is (or was) important for the network stack. Do you know if the current FreeBSD network stack is dependent on this value? In the file gcc/config/arm/netbsd.h (GCC sources) is a comment about this topic. Have a nice day! -- Sebastian Huber, embedded brains GmbH Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany Phone : +49 89 18 90 80 79-6 Fax : +49 89 18 90 80 79-9 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 21 10:39:06 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78E05106566C for ; Thu, 21 Jan 2010 10:39:06 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 3ACAD8FC1E for ; Thu, 21 Jan 2010 10:39:05 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id C9B3B1FFC51; Thu, 21 Jan 2010 10:39:04 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id A891B844BD; Thu, 21 Jan 2010 11:39:04 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Bernard van Gastel References: <71A129DC-68A0-46C3-956D-C8AFF1BA29E1@bitpowder.com> <86hbqifip8.fsf@ds4.des.no> <72CE899C-5941-4659-B922-DC65BB0CE67D@bitpowder.com> Date: Thu, 21 Jan 2010 11:39:04 +0100 In-Reply-To: <72CE899C-5941-4659-B922-DC65BB0CE67D@bitpowder.com> (Bernard van Gastel's message of "Thu, 21 Jan 2010 11:19:34 +0100") Message-ID: <86sk9zagjb.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: pthread_{mutex,cond} & fifo/starvation/scheduling policy X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 10:39:06 -0000 Bernard van Gastel writes: > But the descheduling of threads if the mutex is not available is done > by the library. And especially the order of rescheduling of the > threads (thats what I'm interested in). Or am I missing something in > the sys/kern/sched files (btw I don't have the umtx file). Sorry, it's sys/kern/kern_umtx.c DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 21 10:41:12 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F111D1065672 for ; Thu, 21 Jan 2010 10:41:12 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id B01BC8FC14 for ; Thu, 21 Jan 2010 10:41:12 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id o0LAf87B029378; Thu, 21 Jan 2010 05:41:08 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.2 (mail.netplex.net [204.213.176.10]); Thu, 21 Jan 2010 05:41:08 -0500 (EST) Date: Thu, 21 Jan 2010 05:41:08 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Bernard van Gastel In-Reply-To: <1B4E9B02-AA63-45BF-9BB7-3B0A2884CCB0@bitpowder.com> Message-ID: References: <71A129DC-68A0-46C3-956D-C8AFF1BA29E1@bitpowder.com> <20100119184617.GB50360@dan.emsphone.com> <1B4E9B02-AA63-45BF-9BB7-3B0A2884CCB0@bitpowder.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, Dan Nelson Subject: Re: pthread_{mutex,cond} & fifo/starvation/scheduling policy X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 10:41:13 -0000 On Thu, 21 Jan 2010, Bernard van Gastel wrote: > In real world application such a proposed queue would work almost > always, but I'm trying to exclude all starvation situations primarily > (speed is less relevant). And although such a worker can execute it > work and be scheduled fairly, the addition of the work to the queue > can result in starvation (one of the threads trying to add to the > queue could stall forever if the lock is heavily contested). > > Is this possible with POSIX thread stuff? Or is the only option to use > IPC like message queues for this? I don't see what your problem is if you are using mutexes correctly. Adding or removing work to the queue should be very quick; you lock the mutex, add or remove work to/from the queue, signal the condition variable to wake up any threads waiting for work (when adding work), and unlock the mutex. That's it. -- DE From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 21 10:47:41 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6D47106566B for ; Thu, 21 Jan 2010 10:47:41 +0000 (UTC) (envelope-from mlfbsd@kanar.ci0.org) Received: from kanar.ci0.org (unknown [IPv6:2a01:e0b:1:50:40:63ff:feea:93a]) by mx1.freebsd.org (Postfix) with ESMTP id 34B158FC13 for ; Thu, 21 Jan 2010 10:47:40 +0000 (UTC) Received: from kanar.ci0.org (pluxor@localhost [127.0.0.1]) by kanar.ci0.org (8.14.2/8.14.3) with ESMTP id o0LAmJvN004512; Thu, 21 Jan 2010 11:48:19 +0100 (CET) (envelope-from mlfbsd@kanar.ci0.org) Received: (from mlfbsd@localhost) by kanar.ci0.org (8.14.2/8.14.3/Submit) id o0LAmJG5004511; Thu, 21 Jan 2010 11:48:19 +0100 (CET) (envelope-from mlfbsd) Date: Thu, 21 Jan 2010 11:48:19 +0100 From: Olivier Houchard To: Sebastian Huber Message-ID: <20100121104819.GA4371@ci0.org> References: <4B582AC4.9030502@embedded-brains.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B582AC4.9030502@embedded-brains.de> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Thu, 21 Jan 2010 12:38:54 +0000 Cc: FreeBSD-Hackers Subject: Re: ARM and structure size boundary X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 10:47:41 -0000 On Thu, Jan 21, 2010 at 11:21:56AM +0100, Sebastian Huber wrote: > Hi, > Hi Sebastian, > on ARM the GCC has an option for the structure size boundary: > > http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html#ARM-Options > > In the GCC sources (gcc/config/arm) you see that NetBSD changes the default > value to 8 from 32. > > For FreeBSD I did not found something similar. What value is used on FreeBSD > by default? > > This value is (or was) important for the network stack. Do you know if the > current FreeBSD network stack is dependent on this value? In the file > gcc/config/arm/netbsd.h (GCC sources) is a comment about this topic. > > Have a nice day! > FreeBSD uses the default value of 32. The NetBSD comment states NetBSD has to use 8, because this is what some buggy code expects in their kernel (or expected at some point, no clue if it's still there). Nothing in the network stack, or anywhere in the kernel, should depend on it. Regards, Olivier From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 21 11:47:18 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9555C106566C for ; Thu, 21 Jan 2010 11:47:18 +0000 (UTC) (envelope-from pdegoeje@service2media.com) Received: from s2m-is-001.service2media.com (rev-130-102.virtu.nl [217.114.102.130]) by mx1.freebsd.org (Postfix) with ESMTP id 2F0548FC1C for ; Thu, 21 Jan 2010 11:47:17 +0000 (UTC) Received: from pieter-dev-linux.localnet ([10.0.1.77] RDNS failed) by s2m-is-001.service2media.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Jan 2010 12:35:10 +0100 From: Pieter de Goeje Organization: Service2Media To: freebsd-hackers@freebsd.org Date: Thu, 21 Jan 2010 12:35:10 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-17-generic; KDE/4.3.2; i686; ; ) References: <71A129DC-68A0-46C3-956D-C8AFF1BA29E1@bitpowder.com> <20100119184617.GB50360@dan.emsphone.com> <1B4E9B02-AA63-45BF-9BB7-3B0A2884CCB0@bitpowder.com> In-Reply-To: <1B4E9B02-AA63-45BF-9BB7-3B0A2884CCB0@bitpowder.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201001211235.10129.pieter@service2media.com> X-OriginalArrivalTime: 21 Jan 2010 11:35:10.0715 (UTC) FILETIME=[CA3704B0:01CA9A8D] X-Mailman-Approved-At: Thu, 21 Jan 2010 12:39:03 +0000 Cc: Dan Nelson Subject: Re: pthread_{mutex,cond} & fifo/starvation/scheduling policy X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 11:47:18 -0000 On Thursday 21 January 2010 11:27:23 Bernard van Gastel wrote: > In real world application such a proposed queue would work almost always, > but I'm trying to exclude all starvation situations primarily (speed is > less relevant). And although such a worker can execute it work and be > scheduled fairly, the addition of the work to the queue can result in > starvation (one of the threads trying to add to the queue could stall > forever if the lock is heavily contested). This is not possible. The worker threads unlock the mutex during pthread_cond_wait(). So when the queue is empty, threads can add new items without blocking. So for a worker we have: while(1) { pthread_mutex_lock(&m) while(queue_empty()) { // this atomically unlocks and locks the mutex pthread_cond_wait(&c, &m) } w = fetch_work(); pthread_mutex_unlock(&m); do_work(&w); } And a provider does this: pthread_mutex_lock(&m); add_work(&w); pthread_cond_signal(&c); pthread_mutex_unlock(&m); - Pieter de Goeje From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 21 13:18:25 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from alona.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 689B11065672; Thu, 21 Jan 2010 13:18:24 +0000 (UTC) (envelope-from davidxu@freebsd.org) Message-ID: <4B58541D.1030200@freebsd.org> Date: Thu, 21 Jan 2010 21:18:21 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.21 (X11/20090522) MIME-Version: 1.0 To: Bernard van Gastel References: <71A129DC-68A0-46C3-956D-C8AFF1BA29E1@bitpowder.com> <86hbqifip8.fsf@ds4.des.no> <72CE899C-5941-4659-B922-DC65BB0CE67D@bitpowder.com> In-Reply-To: <72CE899C-5941-4659-B922-DC65BB0CE67D@bitpowder.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , freebsd-hackers@freebsd.org Subject: Re: pthread_{mutex,cond} & fifo/starvation/scheduling policy X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 13:18:25 -0000 Bernard van Gastel wrote: > But the descheduling of threads if the mutex is not available is done by the library. And especially the order of rescheduling of the threads (thats what I'm interested in). Or am I missing something in the sys/kern/sched files (btw I don't have the umtx file). > > Regards, > Bernard The libthr mutex wait-queue is FIFO in kernel, however, the decision whether a thread should be preempted or not is made by scheduler, when mutex owner unlocks the mutex, it just wakes up a waiter thread from head of the queue, if the thread has been blocked for enough long time, kernel scheduler may decide to raises its priority, and if the mutex owner has spent too much cpu time, the scheduler may decides to low its priority, so when the mutex owner unlocks the mutex, preemption may happen if the waiter has higher priority, and the waiter thread can lock the mutex, otherwise the waiter still has to wait for some time to gain higher thread priority. It looks like round-robin fashion, and the round-robin quantum is made by kernel scheduler. In theory, this has best performance, and directly hand-off seems hurt performance drastically. From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 21 15:48:29 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6BD3106566C for ; Thu, 21 Jan 2010 15:48:29 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id 68A918FC20 for ; Thu, 21 Jan 2010 15:48:28 +0000 (UTC) Received: by fxm10 with SMTP id 10so116503fxm.34 for ; Thu, 21 Jan 2010 07:48:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=ZZ6JMn2z08bkZEPFeGfeHGymAqt29Km0Ml38oiLxgBA=; b=AjsUd2AN4Vs4Mhkhr00nenMrcjkOdEYE1bVtGigTxE6xr0oMtCta29d9n91Y1PJ2UW +Ehk0C8TcJMzE2qc6UfxkBr1CgCRJFXT7MHUwfwBP+7DbYWf8T8FbpqnH3qDIoIMiuZ0 9Mj4kLyUobpE5ktGYL+fm5ywFTMcrahQQjuTM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=YfDBq9LbtydxVfZmceT/fVCemDgk8rgChLbBqRtfzFp4n+Unz9JPtXoXwgnqyiNYEB vxv8etf0YMq2LrZcgMI6DbVeZXjBxKNsm7n7MfgIRynPly9J5+yKVnIquydZCziRr/Vr 1D5Kfrt0G+KIbPeibhmoeI9tK0Qe90FoNkLX0= Received: by 10.87.40.26 with SMTP id s26mr2574149fgj.72.1264088907913; Thu, 21 Jan 2010 07:48:27 -0800 (PST) Received: from ?10.0.10.4? (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by mx.google.com with ESMTPS id 15sm681903fxm.6.2010.01.21.07.48.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 21 Jan 2010 07:48:27 -0800 (PST) Sender: Rui Paulo Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: <4B582AC4.9030502@embedded-brains.de> Date: Thu, 21 Jan 2010 15:48:25 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <2B030914-1EC4-4887-856D-994FB66378F5@freebsd.org> References: <4B582AC4.9030502@embedded-brains.de> To: Sebastian Huber X-Mailer: Apple Mail (2.1077) Cc: FreeBSD-Hackers Subject: Re: ARM and structure size boundary X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 15:48:29 -0000 On 21 Jan 2010, at 10:21, Sebastian Huber wrote: > Hi, >=20 > on ARM the GCC has an option for the structure size boundary: >=20 > http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html#ARM-Options >=20 > In the GCC sources (gcc/config/arm) you see that NetBSD changes the = default > value to 8 from 32. >=20 > For FreeBSD I did not found something similar. What value is used on = FreeBSD > by default? >=20 > This value is (or was) important for the network stack. Do you know = if the > current FreeBSD network stack is dependent on this value? In the file > gcc/config/arm/netbsd.h (GCC sources) is a comment about this topic. >=20 > Have a nice day! Just for clarification, on FreeBSD, given it's use of the default = structure size boundary, if you composing a packet format using a = structure, you need to use __packed if the structure is not a multiple = of 4. struct a { int8_t b; int8_t b; }; sizeof(struct a) on FreeBSD/arm is 4 and not 2. To make sure it will get = the correct value, you need to type: struct a { ... } __packed; -- Rui Paulo From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 22 11:44:55 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F569106568F for ; Fri, 22 Jan 2010 11:44:55 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 054A88FC13 for ; Fri, 22 Jan 2010 11:44:54 +0000 (UTC) Received: from outgoing.leidinger.net (pD954F1B8.dip.t-dialin.net [217.84.241.184]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 950E9844844; Fri, 22 Jan 2010 12:44:46 +0100 (CET) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 705C77EE71; Thu, 21 Jan 2010 03:32:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1264041141; bh=QKHZREHz8Ii6K9Utur1Kq2s7hZIDkHNE3qneJP/Dgl4=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=KiRywhyG4bVQ4TYN/B3nM8EbqUZkzBzXIZ43qhSqLzwJZ335xIK9qIkI8igsTweF8 F48cTmvlekdQazheG7RojoXkqKxwsltnAIqSUNUN4MWg2AUEJNll6D+8hlW/uClM+g LmAch5TKSaXqN1HLKrl/vuu/jXsOSUFB24heqTTHSOxJKet+9ksOAI8ctfqijCz0Vk PLWgZJQIhvgOtSApQvq+RWorKC5fzIw2Yg6rd++iQfepGOWvgwyiv0ATcC06xMYamY YIr0x0T9qZh8LOX75ZY5lpuvoRu/7VOWBmiO8hZ8PJSV+k2Fyhxw6FUhtyV7kR3rTN N8kdnd7vdUd1w== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id o0KAEXam042606; Wed, 20 Jan 2010 11:14:33 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Wed, 20 Jan 2010 11:14:33 +0100 Message-ID: <20100120111433.25801pnmhrxnirok@webmail.leidinger.net> Date: Wed, 20 Jan 2010 11:14:33 +0100 From: Alexander Leidinger To: jhell References: <7f14551c1001190119x46c6b04dx2362cd1252f0d81@mail.gmail.com> <7f14551c1001190216w49814186n1ada2b721380502b@mail.gmail.com> <4B55C5A6.2020109@DataIX.net> In-Reply-To: <4B55C5A6.2020109@DataIX.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 950E9844844.264A1 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.363, required 6, autolearn=disabled, ALL_TRUSTED -1.44, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00, TW_ZF 0.08) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1264765490.64908@58FsmgaiYaZEQSlgAHNtDg X-EBL-Spam-Status: No X-Mailman-Approved-At: Fri, 22 Jan 2010 12:46:18 +0000 Cc: freebsd-hackers@FreeBSD.org Subject: Re: Setting "zfs_arc_max" value in FreeBSD 8. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 11:44:55 -0000 Quoting jhell (from Tue, 19 Jan 2010 09:45:58 -0500): > On 1/19/2010 5:16 AM, Sherin George wrote: >> Thanks Ivan :) >> >> I found It. add following in /boot/loader.conf >> >> =================== >> vfs.zfs.arc_max="10244M" >> =================== > I just thought I would give a shout at this for stable/7 as of last > week. I am not sure if this is just me but I had tried to adjust > zfs_arc_max and found out that it was unadjusted to my value after the > system came back up. > > Anyone know if it is adjustable on a system with 1024MB of ram ? Is this > just being auto calculated by some other value ? Can you confirm that you made the modification in /boot/loader.conf, and that you used the double-quotes around the value as shown above? The code in 7-stable regarding this is the same as in 8-stable and 9-current, so if it is done correctly, it has to change accordingly. Bye, Alexander. -- You ain't learning nothing when you're talking. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 22 14:32:33 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F36541065670; Fri, 22 Jan 2010 14:32:32 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id B13338FC16; Fri, 22 Jan 2010 14:32:32 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 3FA8C1FFC22; Fri, 22 Jan 2010 14:32:31 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 1C359844B0; Fri, 22 Jan 2010 15:32:31 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Ivan Voras References: <9bbcef731001220527u5bbec479n59143b6631c6e2d8@mail.gmail.com> Date: Fri, 22 Jan 2010 15:32:31 +0100 In-Reply-To: <9bbcef731001220527u5bbec479n59143b6631c6e2d8@mail.gmail.com> (Ivan Voras's message of "Fri, 22 Jan 2010 14:27:21 +0100") Message-ID: <86tyuefbwg.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org, Randall Stewart Subject: Re: Greetings... a patch I would like your comments on... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 14:32:33 -0000 [bcc: to original list] Ivan Voras writes: > Randall Stewart writes: > > I have put together a patch against head that I would like > > your opinion of. > But you will probably soon receive a message to take this discussion > to hackers@freebsd.org, and I agree :) Please take this discussion to :) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 22 14:46:56 2010 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BDFB106566C; Fri, 22 Jan 2010 14:46:56 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by mx1.freebsd.org (Postfix) with ESMTP id 205768FC15; Fri, 22 Jan 2010 14:46:56 +0000 (UTC) Received: from [192.168.2.144] (pool-96-238-218-31.snfcca.dsl-w.verizon.net [96.238.218.31]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id o0MEkqLj090930 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 22 Jan 2010 09:46:54 -0500 (EST) (envelope-from rrs@lakerest.net) Message-Id: <5DEC2B2B-0823-420B-B064-32D5B0731E37@lakerest.net> From: Randall Stewart To: Randall Stewart In-Reply-To: <24C6E6AA-0D67-448F-87A6-1536211EE595@lakerest.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 22 Jan 2010 06:46:46 -0800 References: <9bbcef731001220527u5bbec479n59143b6631c6e2d8@mail.gmail.com> <24C6E6AA-0D67-448F-87A6-1536211EE595@lakerest.net> X-Mailer: Apple Mail (2.936) Cc: hackers@FreeBSD.org, Ivan Voras Subject: Re: Greetings... a patch I would like your comments on... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 14:46:56 -0000 Lets try that again with the right email subscribed to hackers ;-) R On Jan 22, 2010, at 6:43 AM, Randall Stewart wrote: > Ivan: > > Ok, over we go ;-) > > I do want to add this into Head here eventually so if you happen > to have an interest in umtx or kqueue you may want to take a close > look at this patch ;-) > > R > On Jan 22, 2010, at 5:27 AM, Ivan Voras wrote: > >> 2010/1/22 Randall Stewart : >>> All: >>> >>> I have put together a patch against head that I would like >>> your opinion of. >>> >>> So first what does it do? >>> >>> Well one thing I thought lacking in the kernel was the ability >>> to send a cond event (umtx_cond) to a thread that was waiting >>> on a kqueue... >>> >>> So the rough idea is I have N fd's and other things I am watching >>> but I would also like a local thread (maybe remote if the >>> umtx_cond_t is >>> in shared memory) to be able to wake me up as well. >> >> This is a good and useful addition! I think Windows has implemented a >> generalization of this (called "wait objects" or something like >> that), >> which effectively allows a select()- (or in this case kqueue())-like >> syscall to wait on both file descriptors and condvars (as well as >> probably other MS-style objects). It's useful for multiplexing events >> for dissimilar sources. >> >> But you will probably soon receive a message to take this discussion >> to hackers@freebsd.org, and I agree :) >> > > ------------------------------ > Randall Stewart > 803-317-4952 (cell) > 803-345-0391(direct) > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 22 14:44:08 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C387106568B; Fri, 22 Jan 2010 14:44:08 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by mx1.freebsd.org (Postfix) with ESMTP id F0EA38FC08; Fri, 22 Jan 2010 14:44:07 +0000 (UTC) Received: from [192.168.2.144] (pool-96-238-218-31.snfcca.dsl-w.verizon.net [96.238.218.31]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id o0MEi4cV090785 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 22 Jan 2010 09:44:06 -0500 (EST) (envelope-from rrs@lakerest.net) Message-Id: <24C6E6AA-0D67-448F-87A6-1536211EE595@lakerest.net> From: Randall Stewart To: Ivan Voras In-Reply-To: <9bbcef731001220527u5bbec479n59143b6631c6e2d8@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 22 Jan 2010 06:43:59 -0800 References: <9bbcef731001220527u5bbec479n59143b6631c6e2d8@mail.gmail.com> X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Fri, 22 Jan 2010 14:51:27 +0000 Cc: hackers@freebsd.org Subject: Re: Greetings... a patch I would like your comments on... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 14:44:08 -0000 Ivan: Ok, over we go ;-) I do want to add this into Head here eventually so if you happen to have an interest in umtx or kqueue you may want to take a close look at this patch ;-) R On Jan 22, 2010, at 5:27 AM, Ivan Voras wrote: > 2010/1/22 Randall Stewart : >> All: >> >> I have put together a patch against head that I would like >> your opinion of. >> >> So first what does it do? >> >> Well one thing I thought lacking in the kernel was the ability >> to send a cond event (umtx_cond) to a thread that was waiting >> on a kqueue... >> >> So the rough idea is I have N fd's and other things I am watching >> but I would also like a local thread (maybe remote if the >> umtx_cond_t is >> in shared memory) to be able to wake me up as well. > > This is a good and useful addition! I think Windows has implemented a > generalization of this (called "wait objects" or something like that), > which effectively allows a select()- (or in this case kqueue())-like > syscall to wait on both file descriptors and condvars (as well as > probably other MS-style objects). It's useful for multiplexing events > for dissimilar sources. > > But you will probably soon receive a message to take this discussion > to hackers@freebsd.org, and I agree :) > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 22 15:10:36 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AAD1C106566C; Fri, 22 Jan 2010 15:10:36 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 4F4228FC15; Fri, 22 Jan 2010 15:10:36 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 1D5541CE23; Fri, 22 Jan 2010 16:10:35 +0100 (CET) Date: Fri, 22 Jan 2010 16:10:35 +0100 From: Ed Schouten To: Ivan Voras Message-ID: <20100122151035.GX77705@hoeg.nl> References: <9bbcef731001220527u5bbec479n59143b6631c6e2d8@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VgNP6wxEowREGVu+" Content-Disposition: inline In-Reply-To: <9bbcef731001220527u5bbec479n59143b6631c6e2d8@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD Hackers , Randall Stewart Subject: Re: Greetings... a patch I would like your comments on... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 15:10:36 -0000 --VgNP6wxEowREGVu+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Ivan Voras wrote: > This is a good and useful addition! I think Windows has implemented a > generalization of this (called "wait objects" or something like that), > which effectively allows a select()- (or in this case kqueue())-like > syscall to wait on both file descriptors and condvars (as well as > probably other MS-style objects). It's useful for multiplexing events > for dissimilar sources. NtWaitForSingleObject(), NtWaitForMultipleObjects(), etc. :-) --=20 Ed Schouten WWW: http://80386.nl/ --VgNP6wxEowREGVu+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAktZv+sACgkQ52SDGA2eCwVbEwCdH5Y70ntuupJyKaA1jGFPnHnf oecAnjXVkfTbLHxQudgFifHTkRJ0LYC6 =F975 -----END PGP SIGNATURE----- --VgNP6wxEowREGVu+-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 22 15:33:53 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E99AA1065696 for ; Fri, 22 Jan 2010 15:33:53 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id A51E88FC14 for ; Fri, 22 Jan 2010 15:33:53 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1NYLW9-0004xC-EA for freebsd-hackers@freebsd.org; Fri, 22 Jan 2010 16:33:49 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Jan 2010 16:33:49 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Jan 2010 16:33:49 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Fri, 22 Jan 2010 16:33:27 +0100 Lines: 31 Message-ID: References: <9bbcef731001220527u5bbec479n59143b6631c6e2d8@mail.gmail.com> <20100122151035.GX77705@hoeg.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.5) Gecko/20100118 Thunderbird/3.0 In-Reply-To: <20100122151035.GX77705@hoeg.nl> Sender: news Subject: Re: Greetings... a patch I would like your comments on... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 15:33:54 -0000 On 01/22/10 16:10, Ed Schouten wrote: > * Ivan Voras wrote: >> This is a good and useful addition! I think Windows has implemented a >> generalization of this (called "wait objects" or something like that), >> which effectively allows a select()- (or in this case kqueue())-like >> syscall to wait on both file descriptors and condvars (as well as >> probably other MS-style objects). It's useful for multiplexing events >> for dissimilar sources. > > NtWaitForSingleObject(), NtWaitForMultipleObjects(), etc. :-) > Yes, I was thinking about WaitForMultipleObjects() - I sometimes wished I had it in FreeBSD :) I think the hackers@ side of the thread is missing the original link to the patch file offered for review, so here it is: http://people.freebsd.org/~rrs/kque_umtx.patch My kqueue-fu level is too low to be really useful here but from what I've read it looks like a logical and even reasonably clean way of doing it. If I read the comment at filt_umtxattach() correctly, in the best case you would need an extension to the kevent structure to add more fields like data & udata (for passing values back and forth between userland and kernel). I agree with this - it would be very convenient for some future purposes (like file modification notification) if the kernel filter could both accept and return a struct of data from/to the userland. From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 22 15:49:44 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EBE91065670; Fri, 22 Jan 2010 15:49:44 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id DB7EA8FC20; Fri, 22 Jan 2010 15:49:43 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 50CAC1CE23; Fri, 22 Jan 2010 16:49:43 +0100 (CET) Date: Fri, 22 Jan 2010 16:49:43 +0100 From: Ed Schouten To: Ivan Voras Message-ID: <20100122154943.GY77705@hoeg.nl> References: <9bbcef731001220527u5bbec479n59143b6631c6e2d8@mail.gmail.com> <20100122151035.GX77705@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="m9FEOsnejx470nED" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org Subject: Re: Greetings... a patch I would like your comments on... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 15:49:44 -0000 --m9FEOsnejx470nED Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Ivan Voras wrote: > Yes, I was thinking about WaitForMultipleObjects() - I sometimes > wished I had it in FreeBSD :) FreeBSD already has -- unfortunately it's only accessible from within the ndisulator. ;-) --=20 Ed Schouten WWW: http://80386.nl/ --m9FEOsnejx470nED Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAktZyRcACgkQ52SDGA2eCwX4vgCfSJosLJlhrc9TZIGDJmGbqJ/7 IhgAmgMJjOZA2z0T3q/0YluQo1q/Q8J1 =jTLA -----END PGP SIGNATURE----- --m9FEOsnejx470nED-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 22 15:56:02 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02ED5106566B; Fri, 22 Jan 2010 15:56:02 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by mx1.freebsd.org (Postfix) with ESMTP id 7A64D8FC15; Fri, 22 Jan 2010 15:56:01 +0000 (UTC) Received: from [32.177.153.43] ([32.177.153.43]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id o0MFtsjC094006 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 22 Jan 2010 10:55:59 -0500 (EST) (envelope-from rrs@lakerest.net) Message-Id: <905EFCFB-7362-4F54-B9E7-69C0B4699A37@lakerest.net> From: Randall Stewart To: Ivan Voras In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 22 Jan 2010 07:55:47 -0800 References: <9bbcef731001220527u5bbec479n59143b6631c6e2d8@mail.gmail.com> <20100122151035.GX77705@hoeg.nl> X-Mailer: Apple Mail (2.936) Cc: freebsd-hackers@freebsd.org Subject: Re: Greetings... a patch I would like your comments on... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 15:56:02 -0000 Ivan: A couple of comments... On Jan 22, 2010, at 7:33 AM, Ivan Voras wrote: > On 01/22/10 16:10, Ed Schouten wrote: >> * Ivan Voras wrote: >>> This is a good and useful addition! I think Windows has >>> implemented a >>> generalization of this (called "wait objects" or something like >>> that), >>> which effectively allows a select()- (or in this case kqueue())-like >>> syscall to wait on both file descriptors and condvars (as well as >>> probably other MS-style objects). It's useful for multiplexing >>> events >>> for dissimilar sources. >> >> NtWaitForSingleObject(), NtWaitForMultipleObjects(), etc. :-) >> > > Yes, I was thinking about WaitForMultipleObjects() - I sometimes > wished I had it in FreeBSD :) > > I think the hackers@ side of the thread is missing the original link > to the patch file offered for review, so here it is: > > http://people.freebsd.org/~rrs/kque_umtx.patch > > My kqueue-fu level is too low to be really useful here but from what > I've read it looks like a logical and even reasonably clean way of > doing it. thanks it made sense to me ;-) > > If I read the comment at filt_umtxattach() correctly, in the best > case you would need an extension to the kevent structure to add more > fields like data & udata (for passing values back and forth between > userland and kernel). I agree with this - it would be very > convenient for some future purposes (like file modification > notification) if the kernel filter could both accept and return a > struct of data from/to the userland. Yeah, more arguments inside the kevent would allow me to add the COND_CV_WAIT* where a lock and condition are passed in as well... But I was hesitant to add more than was already there since doing so would cause ABI ripples that I did not want to face. I plan on committing this to head if I don't get strong "you idiot you did it wrong" comments ;-) R > > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org > " > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 22 16:05:20 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72B851065733 for ; Fri, 22 Jan 2010 16:05:19 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id B2E7D8FC21 for ; Fri, 22 Jan 2010 16:05:18 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1NYM0Z-00034U-RV for freebsd-hackers@freebsd.org; Fri, 22 Jan 2010 17:05:15 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Jan 2010 17:05:15 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Jan 2010 17:05:15 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Fri, 22 Jan 2010 17:04:56 +0100 Lines: 29 Message-ID: References: <9bbcef731001220527u5bbec479n59143b6631c6e2d8@mail.gmail.com> <20100122151035.GX77705@hoeg.nl> <905EFCFB-7362-4F54-B9E7-69C0B4699A37@lakerest.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.5) Gecko/20100118 Thunderbird/3.0 In-Reply-To: <905EFCFB-7362-4F54-B9E7-69C0B4699A37@lakerest.net> Sender: news Subject: Re: Greetings... a patch I would like your comments on... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 16:05:20 -0000 On 01/22/10 16:55, Randall Stewart wrote: >> If I read the comment at filt_umtxattach() correctly, in the best case >> you would need an extension to the kevent structure to add more fields >> like data & udata (for passing values back and forth between userland >> and kernel). I agree with this - it would be very convenient for some >> future purposes (like file modification notification) if the kernel >> filter could both accept and return a struct of data from/to the >> userland. > > Yeah, more arguments inside the kevent would allow me to add the > COND_CV_WAIT* where a lock and condition are passed > in as well... But I was hesitant to add more than was already there > since doing > so would cause ABI ripples that I did not want to face. Yes, this should be done carefully; just adding more "data" and "udata" fields will postpone the problem to when someone else needs one more field to make his idea working - a memory blob should probably be the way to go. > I plan on committing this to head if I don't get strong "you idiot you > did it wrong" comments ;-) Hmmm, something just occured to me: why did you name the event / filter "EVFILT_KQUEUE"? Why not something like "EVFILT_UMTX" or "EVFLT_COND"? You said you didn't make the actual connection to the userland pthead_* API yet - how did you test it? From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 22 16:22:38 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4241E10656C1; Fri, 22 Jan 2010 16:22:38 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by mx1.freebsd.org (Postfix) with ESMTP id C5BC78FC14; Fri, 22 Jan 2010 16:22:37 +0000 (UTC) Received: from [32.177.153.43] ([32.177.153.43]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id o0MGMSnu095275 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 22 Jan 2010 11:22:35 -0500 (EST) (envelope-from rrs@lakerest.net) Message-Id: From: Randall Stewart To: Ivan Voras In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 22 Jan 2010 08:22:21 -0800 References: <9bbcef731001220527u5bbec479n59143b6631c6e2d8@mail.gmail.com> <20100122151035.GX77705@hoeg.nl> <905EFCFB-7362-4F54-B9E7-69C0B4699A37@lakerest.net> X-Mailer: Apple Mail (2.936) Cc: freebsd-hackers@freebsd.org Subject: Re: Greetings... a patch I would like your comments on... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 16:22:38 -0000 On Jan 22, 2010, at 8:04 AM, Ivan Voras wrote: > On 01/22/10 16:55, Randall Stewart wrote: > >>> If I read the comment at filt_umtxattach() correctly, in the best >>> case >>> you would need an extension to the kevent structure to add more >>> fields >>> like data & udata (for passing values back and forth between >>> userland >>> and kernel). I agree with this - it would be very convenient for >>> some >>> future purposes (like file modification notification) if the kernel >>> filter could both accept and return a struct of data from/to the >>> userland. >> >> Yeah, more arguments inside the kevent would allow me to add the >> COND_CV_WAIT* where a lock and condition are passed >> in as well... But I was hesitant to add more than was already there >> since doing >> so would cause ABI ripples that I did not want to face. > > Yes, this should be done carefully; just adding more "data" and > "udata" fields will postpone the problem to when someone else needs > one more field to make his idea working - a memory blob should > probably be the way to go. > >> I plan on committing this to head if I don't get strong "you idiot >> you >> did it wrong" comments ;-) > > Hmmm, something just occured to me: why did you name the event / > filter "EVFILT_KQUEUE"? Why not something like "EVFILT_UMTX" or > "EVFLT_COND"? Yep.. has I am just sitting down to write my "super crusher" test case I realize .. what was I smoking when I said EVFILT_KQUEUE.. thats got to change.. I think maybe EVFILT_UMTX_COND is best.. UMTX might let you think you could send in a lock or something else.. > > You said you didn't make the actual connection to the userland > pthead_* API yet - how did you test it? Actually I am using just raw umtx itself. For just quick testing a _thr_umtx_wake((u_long *)addr, count); Works.. Or one can even dig in and do the actual syscall.. _umtx_op().. but that requires a lot more arguments ;-) I need to think on integrating it into pthread*.. but we actully have at work our own mutex stuff for apps that is in user space and is a bit faster (quite a bit)... and it uses the umtx stuff directly ;-) R > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org > " > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 22 16:47:48 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 140E3106568F for ; Fri, 22 Jan 2010 16:47:48 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-iw0-f198.google.com (mail-iw0-f198.google.com [209.85.223.198]) by mx1.freebsd.org (Postfix) with ESMTP id CB0588FC12 for ; Fri, 22 Jan 2010 16:47:47 +0000 (UTC) Received: by iwn36 with SMTP id 36so1148703iwn.3 for ; Fri, 22 Jan 2010 08:47:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=t8o9p/8fatDSBQCsW3Ky3om2opXuQVLMzJmc/ER8fqA=; b=seXNmCJChm1R0fUKsznzKyTyCHpTdWCnHsfZXE2WjlA2jMB4lBqzyrklYh+rgmRVNO 3bV9WKr3Uz9Gr/i6/Vwy1ZCwOBYJ8NhHPORiaLy1RHRcPqDMGVMKE9MbD0jzJef1yTjN ISzl3A7eZQy4AGJjAB4aUl5GuES0CBrWESDy0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=cewf065WpAKtx//LcmXuwbtvFMUxShNaod2NBoY1FLB7a0PO0LJQKmFzbT2SL/oeFx 6ebzOf771PJU55pIk8FMlltknsTPKNTodB2utkJ0wTjF6GQhueZ7Cck6ECqLSaX9GXQc VEM4VcaRFZhztIqZvaGyqnvylz9WHfhtjXndk= MIME-Version: 1.0 Sender: artemb@gmail.com Received: by 10.231.150.73 with SMTP id x9mr5100828ibv.75.1264178866763; Fri, 22 Jan 2010 08:47:46 -0800 (PST) In-Reply-To: <20100120111433.25801pnmhrxnirok@webmail.leidinger.net> References: <7f14551c1001190119x46c6b04dx2362cd1252f0d81@mail.gmail.com> <7f14551c1001190216w49814186n1ada2b721380502b@mail.gmail.com> <4B55C5A6.2020109@DataIX.net> <20100120111433.25801pnmhrxnirok@webmail.leidinger.net> Date: Fri, 22 Jan 2010 08:47:46 -0800 X-Google-Sender-Auth: 0f73be3a8120ce2a Message-ID: From: Artem Belevich To: jhell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Alexander Leidinger , freebsd-hackers@freebsd.org Subject: Re: Setting "zfs_arc_max" value in FreeBSD 8. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 16:47:48 -0000 >> Anyone know if it is adjustable on a system with 1024MB of ram ? Is this >> just being auto calculated by some other value ? You may want to make sure that vm.kmem_size is set to a value much larger than vfs.zfs.arc_max. Default value may be too small to allow such a large ARC. On a side note, I'm not sure that ZFS is a good match for system with only 1G of RAM. By trial and error on my box with 8G or memory I've figured out that I need to set arc_max ~1G below physical memory size to avoid lockups under load. YMMV. --Artem On Wed, Jan 20, 2010 at 2:14 AM, Alexander Leidinger wrote: > Quoting jhell (from Tue, 19 Jan 2010 09:45:58 -0500): > >> On 1/19/2010 5:16 AM, Sherin George wrote: >>> >>> Thanks Ivan :) >>> >>> I found It. add following in /boot/loader.conf >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> vfs.zfs.arc_max=3D"10244M" >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> I just thought I would give a shout at this for stable/7 as of last >> week. I am not sure if this is just me but I had tried to adjust >> zfs_arc_max and found out that it was unadjusted to my value after the >> system came back up. >> >> Anyone know if it is adjustable on a system with 1024MB of ram ? Is this >> just being auto calculated by some other value ? > > Can you confirm that you made the modification in /boot/loader.conf, and > that you used the double-quotes around the value as shown above? > > The code in 7-stable regarding this is the same as in 8-stable and > 9-current, so if it is done correctly, it has to change accordingly. > > Bye, > Alexander. > > -- > You ain't learning nothing when you're talking. > > http://www.Leidinger.net =A0 =A0Alexander @ Leidinger.net: PGP ID =3D B00= 63FE7 > http://www.FreeBSD.org =A0 =A0 =A0 netchild @ FreeBSD.org =A0: PGP ID =3D= 72077137 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 22 17:25:28 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77737106566B; Fri, 22 Jan 2010 17:25:28 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id 0C51B8FC19; Fri, 22 Jan 2010 17:25:28 +0000 (UTC) Received: from toad.stack.nl (toad.stack.nl [IPv6:2001:610:1108:5010::135]) by mx1.stack.nl (Postfix) with ESMTP id 06B211DD635; Fri, 22 Jan 2010 18:25:26 +0100 (CET) Received: by toad.stack.nl (Postfix, from userid 1677) id E0F9573F9D; Fri, 22 Jan 2010 18:25:25 +0100 (CET) Date: Fri, 22 Jan 2010 18:25:25 +0100 From: Jilles Tjoelker To: Randall Stewart Message-ID: <20100122172525.GA37884@stack.nl> References: <9bbcef731001220527u5bbec479n59143b6631c6e2d8@mail.gmail.com> <20100122151035.GX77705@hoeg.nl> <905EFCFB-7362-4F54-B9E7-69C0B4699A37@lakerest.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <905EFCFB-7362-4F54-B9E7-69C0B4699A37@lakerest.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-hackers@freebsd.org, Ivan Voras Subject: Re: Greetings... a patch I would like your comments on... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 17:25:28 -0000 On Fri, Jan 22, 2010 at 07:55:47AM -0800, Randall Stewart wrote: > On Jan 22, 2010, at 7:33 AM, Ivan Voras wrote: > > On 01/22/10 16:10, Ed Schouten wrote: > >> * Ivan Voras wrote: > >>> This is a good and useful addition! I think Windows has > >>> implemented a > >>> generalization of this (called "wait objects" or something like > >>> that), > >>> which effectively allows a select()- (or in this case kqueue())-like > >>> syscall to wait on both file descriptors and condvars (as well as > >>> probably other MS-style objects). It's useful for multiplexing > >>> events > >>> for dissimilar sources. > >> NtWaitForSingleObject(), NtWaitForMultipleObjects(), etc. :-) > > Yes, I was thinking about WaitForMultipleObjects() - I sometimes > > wished I had it in FreeBSD :) > > I think the hackers@ side of the thread is missing the original link > > to the patch file offered for review, so here it is: > > http://people.freebsd.org/~rrs/kque_umtx.patch Cool. > > My kqueue-fu level is too low to be really useful here but from what > > I've read it looks like a logical and even reasonably clean way of > > doing it. > thanks it made sense to me ;-) > > If I read the comment at filt_umtxattach() correctly, in the best > > case you would need an extension to the kevent structure to add more > > fields like data & udata (for passing values back and forth between > > userland and kernel). I agree with this - it would be very > > convenient for some future purposes (like file modification > > notification) if the kernel filter could both accept and return a > > struct of data from/to the userland. > Yeah, more arguments inside the kevent would allow me to add the > COND_CV_WAIT* where a lock and condition are passed > in as well... But I was hesitant to add more than was already there > since doing > so would cause ABI ripples that I did not want to face. I don't think passing the lock is needed. Traditional way (error handling omitted): pthread_mutex_lock(&M); while (!P) pthread_cond_wait(&C, &M); do_work(); pthread_mutex_unlock(&M); The thread must be registered as a waiter before unlocking the mutex, otherwise a wakeup could be lost. Possible kqueue way (error handling omitted): kq = kqueue(); pthread_mutex_lock(&M); while (!P) { pthread_cond_kqueue_register_wait_np(&C, kq); pthread_mutex_unlock(&M); nevents = kevent(kq, NULL, 0, events, 1, NULL); ... handle other events ... pthread_mutex_lock(&M); } do_work(); pthread_mutex_unlock(&M); close(kq); To avoid lost wakeup, the kqueue must be registered as a waiter before unlocking the mutex. Once it has been registered, it is safe to unlock the mutex as the kqueue will store the fact that the condition has been signalled. Hence, pthread_cond_kqueue_register_wait_np() or however it will be named does not need the mutex explicitly. kevent() needs to return some sort of identifier of C, possibly via kevent.udata. In that case the hack with fflags and data remains needed. Registering multiple condvars in one function call could be nasty, as it requires all the mutexes to be locked simultaneously. On the other hand if you do want registration and waiting in the same function, like kqueue can do with file descriptors, then it is needed to pass all the locks so they can be unlocked after registering and before waiting. I think this results in a rather complicated API though. Adding a mutex to a kqueue probably means that mutexes are used wrongly: they should not be locked for so long that it is desirable to wait for one together with other objects (pthread_mutex_timedlock() is meant as a fail-safe). Semaphores could also be waited for via kqueue, probably via a version of sem_trywait() that registers the kqueue as a waiter. Once this is signalled, the thread can call the function again to obtain the semaphore or register again if another thread obtained the semaphore first. -- Jilles Tjoelker From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 22 17:54:06 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 979A21065679; Fri, 22 Jan 2010 17:54:06 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by mx1.freebsd.org (Postfix) with ESMTP id 2D6BF8FC0A; Fri, 22 Jan 2010 17:54:06 +0000 (UTC) Received: from [32.177.153.43] ([32.177.153.43]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id o0MHruZQ099197 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 22 Jan 2010 12:54:03 -0500 (EST) (envelope-from rrs@lakerest.net) Message-Id: <6F462467-1004-4A6F-9AD6-2B533A9E7A8D@lakerest.net> From: Randall Stewart To: Jilles Tjoelker In-Reply-To: <20100122172525.GA37884@stack.nl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 22 Jan 2010 09:53:50 -0800 References: <9bbcef731001220527u5bbec479n59143b6631c6e2d8@mail.gmail.com> <20100122151035.GX77705@hoeg.nl> <905EFCFB-7362-4F54-B9E7-69C0B4699A37@lakerest.net> <20100122172525.GA37884@stack.nl> X-Mailer: Apple Mail (2.936) Cc: freebsd-hackers@freebsd.org, Ivan Voras Subject: Re: Greetings... a patch I would like your comments on... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 17:54:06 -0000 On Jan 22, 2010, at 9:25 AM, Jilles Tjoelker wrote: > On Fri, Jan 22, 2010 at 07:55:47AM -0800, Randall Stewart wrote: >> On Jan 22, 2010, at 7:33 AM, Ivan Voras wrote: > >>> On 01/22/10 16:10, Ed Schouten wrote: >>>> * Ivan Voras wrote: >>>>> This is a good and useful addition! I think Windows has >>>>> implemented a >>>>> generalization of this (called "wait objects" or something like >>>>> that), >>>>> which effectively allows a select()- (or in this case kqueue())- >>>>> like >>>>> syscall to wait on both file descriptors and condvars (as well as >>>>> probably other MS-style objects). It's useful for multiplexing >>>>> events >>>>> for dissimilar sources. > >>>> NtWaitForSingleObject(), NtWaitForMultipleObjects(), etc. :-) > >>> Yes, I was thinking about WaitForMultipleObjects() - I sometimes >>> wished I had it in FreeBSD :) > >>> I think the hackers@ side of the thread is missing the original link >>> to the patch file offered for review, so here it is: > >>> http://people.freebsd.org/~rrs/kque_umtx.patch > > Cool. > >>> My kqueue-fu level is too low to be really useful here but from what >>> I've read it looks like a logical and even reasonably clean way of >>> doing it. > >> thanks it made sense to me ;-) > >>> If I read the comment at filt_umtxattach() correctly, in the best >>> case you would need an extension to the kevent structure to add more >>> fields like data & udata (for passing values back and forth between >>> userland and kernel). I agree with this - it would be very >>> convenient for some future purposes (like file modification >>> notification) if the kernel filter could both accept and return a >>> struct of data from/to the userland. > >> Yeah, more arguments inside the kevent would allow me to add the >> COND_CV_WAIT* where a lock and condition are passed >> in as well... But I was hesitant to add more than was already there >> since doing >> so would cause ABI ripples that I did not want to face. > > I don't think passing the lock is needed. > > Traditional way (error handling omitted): > > pthread_mutex_lock(&M); > while (!P) > pthread_cond_wait(&C, &M); > do_work(); > pthread_mutex_unlock(&M); > > The thread must be registered as a waiter before unlocking the mutex, > otherwise a wakeup could be lost. > > Possible kqueue way (error handling omitted): > > kq = kqueue(); > pthread_mutex_lock(&M); > while (!P) > { > pthread_cond_kqueue_register_wait_np(&C, kq); > pthread_mutex_unlock(&M); > nevents = kevent(kq, NULL, 0, events, 1, NULL); > ... handle other events ... > pthread_mutex_lock(&M); > } > do_work(); > pthread_mutex_unlock(&M); > close(kq); > True, we are doing this at my day job.. I had just noticed a UMTX_CV_WAIT type wait.. and that one passes in a lock to unlock.. I just wanted it clear that this can't do that one.. you have to do something (like what you outlined) to deal with the mutex... > To avoid lost wakeup, the kqueue must be registered as a waiter before > unlocking the mutex. Once it has been registered, it is safe to unlock > the mutex as the kqueue will store the fact that the condition has > been > signalled. Hence, pthread_cond_kqueue_register_wait_np() or however it > will be named does not need the mutex explicitly. > > kevent() needs to return some sort of identifier of C, possibly via > kevent.udata. In that case the hack with fflags and data remains > needed. Hmm yeah right now the return is really just the ident which tells you the address waited on. We probably will need something more to tie things together when the pthread side of this is built. > > Registering multiple condvars in one function call could be nasty, > as it > requires all the mutexes to be locked simultaneously. > > On the other hand if you do want registration and waiting in the same > function, like kqueue can do with file descriptors, then it is > needed to > pass all the locks so they can be unlocked after registering and > before > waiting. I think this results in a rather complicated API though. Yep.. it leads to a twisty passage of fun ;-) > > Adding a mutex to a kqueue probably means that mutexes are used > wrongly: > they should not be locked for so long that it is desirable to wait for > one together with other objects (pthread_mutex_timedlock() is meant > as a > fail-safe). > > Semaphores could also be waited for via kqueue, probably via a version > of sem_trywait() that registers the kqueue as a waiter. Once this is > signalled, the thread can call the function again to obtain the > semaphore or register again if another thread obtained the semaphore > first. True.. I had not thought of doing that.. I was just more interested in waiting on an fd and a cond... :-) R > > -- > Jilles Tjoelker > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 22 17:58:41 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14E1910656A8 for ; Fri, 22 Jan 2010 17:58:41 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id D858F8FC14 for ; Fri, 22 Jan 2010 17:58:40 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id o0MHwcZM011238; Fri, 22 Jan 2010 12:58:38 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.2 (mail.netplex.net [204.213.176.10]); Fri, 22 Jan 2010 12:58:39 -0500 (EST) Date: Fri, 22 Jan 2010 12:58:38 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Jilles Tjoelker In-Reply-To: <20100122172525.GA37884@stack.nl> Message-ID: References: <9bbcef731001220527u5bbec479n59143b6631c6e2d8@mail.gmail.com> <20100122151035.GX77705@hoeg.nl> <905EFCFB-7362-4F54-B9E7-69C0B4699A37@lakerest.net> <20100122172525.GA37884@stack.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, Randall Stewart , Ivan Voras Subject: Re: Greetings... a patch I would like your comments on... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 17:58:41 -0000 On Fri, 22 Jan 2010, Jilles Tjoelker wrote: > On Fri, Jan 22, 2010 at 07:55:47AM -0800, Randall Stewart wrote: >> On Jan 22, 2010, at 7:33 AM, Ivan Voras wrote: > >>> On 01/22/10 16:10, Ed Schouten wrote: >>>> * Ivan Voras wrote: >>>>> This is a good and useful addition! I think Windows has >>>>> implemented a >>>>> generalization of this (called "wait objects" or something like >>>>> that), >>>>> which effectively allows a select()- (or in this case kqueue())-like >>>>> syscall to wait on both file descriptors and condvars (as well as >>>>> probably other MS-style objects). It's useful for multiplexing >>>>> events >>>>> for dissimilar sources. > >>>> NtWaitForSingleObject(), NtWaitForMultipleObjects(), etc. :-) > >>> Yes, I was thinking about WaitForMultipleObjects() - I sometimes >>> wished I had it in FreeBSD :) > >>> I think the hackers@ side of the thread is missing the original link >>> to the patch file offered for review, so here it is: > >>> http://people.freebsd.org/~rrs/kque_umtx.patch > > Cool. > >>> My kqueue-fu level is too low to be really useful here but from what >>> I've read it looks like a logical and even reasonably clean way of >>> doing it. > >> thanks it made sense to me ;-) > >>> If I read the comment at filt_umtxattach() correctly, in the best >>> case you would need an extension to the kevent structure to add more >>> fields like data & udata (for passing values back and forth between >>> userland and kernel). I agree with this - it would be very >>> convenient for some future purposes (like file modification >>> notification) if the kernel filter could both accept and return a >>> struct of data from/to the userland. > >> Yeah, more arguments inside the kevent would allow me to add the >> COND_CV_WAIT* where a lock and condition are passed >> in as well... But I was hesitant to add more than was already there >> since doing >> so would cause ABI ripples that I did not want to face. > > I don't think passing the lock is needed. > > Traditional way (error handling omitted): > > pthread_mutex_lock(&M); > while (!P) > pthread_cond_wait(&C, &M); > do_work(); > pthread_mutex_unlock(&M); > > The thread must be registered as a waiter before unlocking the mutex, > otherwise a wakeup could be lost. > > Possible kqueue way (error handling omitted): > > kq = kqueue(); > pthread_mutex_lock(&M); > while (!P) > { > pthread_cond_kqueue_register_wait_np(&C, kq); > pthread_mutex_unlock(&M); > nevents = kevent(kq, NULL, 0, events, 1, NULL); > ... handle other events ... > pthread_mutex_lock(&M); > } > do_work(); > pthread_mutex_unlock(&M); > close(kq); This is ugly from the userland point of view -- if you need this, I would encompass everything in a kq event object thingie. As in: /* * Create an object containing everything you need to wait * or signal kqueue events. */ kq = kqueue(); kq_obj = kq_create(kq, ...); kq_lock(&kq_obj); while (!P) { /* Atomically unlocks kq_obj and blocks. */ nevents = kq_wait(&kq_obj, ...); /* When you wakeup, kq_obj is locked again. */ } do_work(); /* Wouldn't you want to unlock before this? */ kq_unlock(&kq_obj); /* From another thread, you could do: */ kq_lock(&kq_obj); if (kq_waiters(&kq_obj) > 0) kq_signal(&kq_obj); /* or kq_broadcast() */ kq_unlock(&kq_obj); -- DE From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 22 18:49:58 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 930F310656A3; Fri, 22 Jan 2010 18:49:58 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by mx1.freebsd.org (Postfix) with ESMTP id 204FB8FC23; Fri, 22 Jan 2010 18:49:58 +0000 (UTC) Received: from [32.177.153.43] ([32.177.153.43]) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id o0MInqKA001502 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 22 Jan 2010 13:49:55 -0500 (EST) (envelope-from rrs@lakerest.net) Message-Id: <72CD3F66-1428-4876-BE35-6651417C5BC0@lakerest.net> From: Randall Stewart To: Daniel Eischen In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 22 Jan 2010 10:49:44 -0800 References: <9bbcef731001220527u5bbec479n59143b6631c6e2d8@mail.gmail.com> <20100122151035.GX77705@hoeg.nl> <905EFCFB-7362-4F54-B9E7-69C0B4699A37@lakerest.net> <20100122172525.GA37884@stack.nl> X-Mailer: Apple Mail (2.936) Cc: freebsd-hackers@freebsd.org, Ivan Voras , Jilles Tjoelker Subject: Re: Greetings... a patch I would like your comments on... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 18:49:58 -0000 Daniel: Well it may be ugly, but it gets even uglier on how you have to pass the mtx down to the kernel with the cond wait variables... One can do it.. but it will take some additional changes to the kevent structure which breaks the ABI... which I was not going to venture down that path :-) Hmm I suppose one might be able to abuse udata. Right now the incoming "value" is in the data (the value that is checked before putting you on the umtx sleep queue). We could, pass the mtx into the "udata" field but this rather breaks the definition of udata: "Opaque user-defined value passed through the kernel unchanged" Now I suppose if you placed the MTX pointer there that you are NOT exactly changing it ... but you WOULD be changing the value of it (as you unlock the mutex).. I will work on getting this first set of changes into the kernel. If we don't abuse udata, then the only choice would be to add some additional "data" element.. or maybe as Ivan suggested a "blob" which would still mean an ABI change since you would have to include a size in the blob... hmmm unless we did "data" is a pointer and flags is the size.. But this really seems hackish .. sigh .. R On Jan 22, 2010, at 9:58 AM, Daniel Eischen wrote: >> > > This is ugly from the userland point of view -- if you need > this, I would encompass everything in a kq event object > thingie. As in: > > /* > * Create an object containing everything you need to wait > * or signal kqueue events. > */ > kq = kqueue(); > kq_obj = kq_create(kq, ...); > > kq_lock(&kq_obj); > while (!P) > { > /* Atomically unlocks kq_obj and blocks. */ > nevents = kq_wait(&kq_obj, ...); > > /* When you wakeup, kq_obj is locked again. */ > } > > do_work(); /* Wouldn't you want to unlock before this? */ > kq_unlock(&kq_obj); > > > /* From another thread, you could do: */ > kq_lock(&kq_obj); > if (kq_waiters(&kq_obj) > 0) > kq_signal(&kq_obj); /* or kq_broadcast() */ > kq_unlock(&kq_obj); > > > -- > DE > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 22 21:18:50 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5957110656A8 for ; Fri, 22 Jan 2010 21:18:50 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from poseidon.ceid.upatras.gr (poseidon.ceid.upatras.gr [150.140.141.169]) by mx1.freebsd.org (Postfix) with ESMTP id C31478FC24 for ; Fri, 22 Jan 2010 21:18:49 +0000 (UTC) Received: from mail.ceid.upatras.gr (unknown [10.1.0.143]) by poseidon.ceid.upatras.gr (Postfix) with ESMTP id 83C5AEB498A; Fri, 22 Jan 2010 23:18:48 +0200 (EET) Received: from localhost (europa.ceid.upatras.gr [127.0.0.1]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 49156160CDE; Fri, 22 Jan 2010 23:18:48 +0200 (EET) X-Virus-Scanned: amavisd-new at ceid.upatras.gr Received: from mail.ceid.upatras.gr ([127.0.0.1]) by localhost (europa.ceid.upatras.gr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7gXBDBdDhdw; Fri, 22 Jan 2010 23:18:48 +0200 (EET) Received: from kobe.laptop (ppp-94-64-255-117.home.otenet.gr [94.64.255.117]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 0ED93160CDD; Fri, 22 Jan 2010 23:18:47 +0200 (EET) Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id o0MLIjVD036905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jan 2010 23:18:45 +0200 (EET) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id o0MLIiNQ036899; Fri, 22 Jan 2010 23:18:44 +0200 (EET) (envelope-from keramida@freebsd.org) From: Giorgos Keramidas To: "R. Tyler Ballance" In-Reply-To: <20100117213049.GA2259@kiwi.sharlinx.com> (R. Tyler Ballance's message of "Sun, 17 Jan 2010 13:30:50 -0800") Date: Fri, 22 Jan 2010 23:18:09 +0200 Message-ID: <877hr9ltym.fsf@kobe.laptop> References: <20100117213049.GA2259@kiwi.sharlinx.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.91 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Cc: freebsd-hackers@freebsd.org Subject: Re: Weekend PR smashing X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 21:18:50 -0000 --=-=-= On Sun, 17 Jan 2010 13:30:50 -0800, "R. Tyler Ballance" wrote: > Are there similar resources I've not stumbled across yet? I would like to help, > I have but one machine running -CURRENT and sporadic free time over the > weekends. Hi there. I just noticed this post in among others in -hackers. If you don't know about the bugbuster team already, you should check it out. There's a mailing list at freebsd-bugbusters and an IRC channel at the EFnet network. Since you are looking for pointers to get you started, the following may help a bit: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/ http://www.freebsd.org/doc/en_US.ISO8859-1/articles/pr-guidelines/ http://www.freebsd.org/doc/en_US.ISO8859-1/articles/problem-reports/ Finally, it's worth noting that it is not a huge problem if you only have weekend-time to contribute. We welcome all the help we can get, so please feel free to jump in and help in any way you can with the existing bugs (or new ones that you have noticed). --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAktaFhoACgkQ1g+UGjGGA7bPFwCfbnaYWscFUFTfNYqFeQT2iym+ cPcAn3hPFgLbYJ9hyfSTW2zajt1cpsr9 =fIZt -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 22 18:13:50 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29518106568B for ; Fri, 22 Jan 2010 18:13:50 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yw0-f197.google.com (mail-yw0-f197.google.com [209.85.211.197]) by mx1.freebsd.org (Postfix) with ESMTP id DD1A58FC1B for ; Fri, 22 Jan 2010 18:13:49 +0000 (UTC) Received: by ywh35 with SMTP id 35so1186741ywh.7 for ; Fri, 22 Jan 2010 10:13:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=cXshbdZTZMZ0nUSzAPUqMBBcK+gyfjE/cbi9yTrIrvk=; b=TYrmIrOFwdPVT9u8T8/jBea2hEg9hqKUR2K7R7q2eq65xYDW3nbtGNRe7MLAEU3PZj bWN9XheqMYZBfkL/Muy1kG0OvEDXnEbmp2OsDtzi2qqO49PZ3XMlPd3DfdJzxwFsS5nk tCyydDaE4M1wQKqJ3VmKI2gjXuSpqlFBuQ2Xo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ceOOY4Ulxh4R8JA6go5BJQUwcYq1M/b+HKNirXrb++i+X0wXqZHwJj4qChDODzMb4X YoQH71tUT0TcND1JcnFdWQSzCe+Ho6/CPlEwjfYn4L9cJVPby8gHmXMQXucGxX3dEd0g OkiaW44R+6ypzpClynnyTVF81Y1ii/sSNpdCQ= MIME-Version: 1.0 Received: by 10.101.12.6 with SMTP id p6mr4215154ani.248.1264182586100; Fri, 22 Jan 2010 09:49:46 -0800 (PST) Date: Fri, 22 Jan 2010 19:49:46 +0200 Message-ID: From: Dan Naumov To: FreeBSD-STABLE Mailing List , freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Fri, 22 Jan 2010 21:31:14 +0000 Cc: Subject: posting coding bounties, appropriate money amounts? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 18:13:50 -0000 Hello I am curious about posting some coding bounties, my current interest revolves around improving the ZVOL functionality in FreeBSD: fixing the known ZVOL SWAP reliability/stability problems as well as making ZVOLs work as a dumpon device (as is already the case in OpenSolaris) for crash dumps. I am a private individual and not some huge Fortune 100 and while I am not exactly rich, I am willing to put some of my personal money towards this. I am curious though, what would be the best way to approach this: directly approaching committer(s) with the know-how-and-why of the areas involved or through the FreeBSD Foundation? And how would one go about calculating the appropriate amount of money for such a thing? Thanks. - Sincerely, Dan Naumov From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 22 23:10:07 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5824D106566B for ; Fri, 22 Jan 2010 23:10:07 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 12CB78FC0C for ; Fri, 22 Jan 2010 23:10:06 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1NYSdg-00047H-3x for freebsd-hackers@freebsd.org; Sat, 23 Jan 2010 00:10:04 +0100 Received: from 93-138-99-190.adsl.net.t-com.hr ([93.138.99.190]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 23 Jan 2010 00:10:04 +0100 Received: from ivoras by 93-138-99-190.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 23 Jan 2010 00:10:04 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Sat, 23 Jan 2010 00:06:25 +0100 Lines: 22 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 93-138-99-190.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.21 (X11/20090612) In-Reply-To: Sender: news Cc: freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Subject: Re: posting coding bounties, appropriate money amounts? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 23:10:07 -0000 Dan Naumov wrote: > Hello > > I am curious about posting some coding bounties, my current interest > revolves around improving the ZVOL functionality in FreeBSD: fixing > the known ZVOL SWAP reliability/stability problems as well as making > ZVOLs work as a dumpon device (as is already the case in OpenSolaris) > for crash dumps. I am a private individual and not some huge Fortune > 100 and while I am not exactly rich, I am willing to put some of my > personal money towards this. I am curious though, what would be the > best way to approach this: directly approaching committer(s) with the > know-how-and-why of the areas involved or through the FreeBSD > Foundation? And how would one go about calculating the appropriate > amount of money for such a thing? Hi, This idea (bounties) appear approximately every 6 months and it appears there is no better way than contacting the developers directly. AFAIK all attempts to conglomerate such an effort have failed. One important conclusion is that it cannot go through the Foundation since they cannot accept targeted donations. From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 23 00:05:18 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 948A61065679; Sat, 23 Jan 2010 00:05:18 +0000 (UTC) (envelope-from mattjeet@gmail.com) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx1.freebsd.org (Postfix) with ESMTP id 559208FC13; Sat, 23 Jan 2010 00:05:18 +0000 (UTC) Received: by pwi15 with SMTP id 15so1223946pwi.3 for ; Fri, 22 Jan 2010 16:05:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=Ac3+p2e1Yd2SwWueZbPmWpim4uv5eetnfcarYxribXo=; b=XJMqVNadz3jtoXAd/Akacl1q1DCDC6jDI6GLtNUhEBRr1TpNYThD+wkPolyHflTbMU RYe9ut62fNXz+UbSJUfPddJkSHYKEd2aYuyqMBzZiKkWbtfnjEOE5XJBFt7E2CS5yNci tbqBfSk0n7fcnJxDDrOMiFD3i5tyhs3q2Th+0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=vL5ULOW3kpK44/VHPRf2pKFuuGYgKyS966HIq8DHhVTIcVVpeoJgBAU1aif7F91c3v ab6VrbFjMuX5zZcXZomj2Ep0bmQ32KBszQhX/A5pRoNMi6fqw9ZEhHKndmZ6JsVIL3S2 f4yoM69Hk7wiYA3p7rVeXmZiyzul5wN34fcVk= MIME-Version: 1.0 Sender: mattjeet@gmail.com Received: by 10.142.1.20 with SMTP id 20mr2460947wfa.73.1264203320891; Fri, 22 Jan 2010 15:35:20 -0800 (PST) In-Reply-To: References: Date: Fri, 22 Jan 2010 15:35:20 -0800 X-Google-Sender-Auth: f0816e0fa82657ee Message-ID: <9740caf1001221535l1fcb45f0pa189c84517640314@mail.gmail.com> From: Matt Olander To: Ivan Voras Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Subject: Re: posting coding bounties, appropriate money amounts? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: matt@ixsystems.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 00:05:18 -0000 On Fri, Jan 22, 2010 at 3:06 PM, Ivan Voras wrote: > Dan Naumov wrote: >> >> Hello >> >> I am curious about posting some coding bounties, my current interest >> revolves around improving the ZVOL functionality in FreeBSD: fixing >> the known ZVOL SWAP reliability/stability problems as well as making >> ZVOLs work as a dumpon device (as is already the case in OpenSolaris) >> for crash dumps. I am a private individual and not some huge Fortune >> 100 and while I am not exactly rich, I am willing to put some of my >> personal money towards this. I am curious though, what would be the >> best way to approach this: directly approaching committer(s) with the >> know-how-and-why of the areas involved or through the FreeBSD >> Foundation? And how would one go about calculating the appropriate >> amount of money for such a thing? > > Hi, > > This idea (bounties) appear approximately every 6 months and it appears > there is no better way than contacting the developers directly. AFAIK all > attempts to conglomerate such an effort have failed. One important > conclusion is that it cannot go through the Foundation since they cannot > accept targeted donations. Awhile back, we built a simple app for posting bounties, getting devs and sponsors on board, posting the committed code in a browser viewable format, and then handle final payout upon completion. iXsystems is more than willing to handle financial details and I would gladly be the first to sponsor this project on the site. http://www.sponsorbsd.org We would need a team leader *cough* Ivan *cough* that could make sure developing contributors are actually involved so that the final payoff can be shared accordingly. It's a cakephp app and I'm sure it needs a bit more polish but we could do it on the fly and it shouldn't be to hard :) Any cakephp or php devs interested in helping testing and launch, let me know. I just haven't had much time to spend on launching it although I still think it's a great idea. If somebody would like to spearhead this effort, that would be great. For companies wishing to sponsor non-community code, it also has the option of hiding the community committed code. best, -matt From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 23 00:05:57 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2ABA2106566B for ; Sat, 23 Jan 2010 00:05:57 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id DDC848FC1A for ; Sat, 23 Jan 2010 00:05:56 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1NYTVg-0003Vs-L9 for freebsd-hackers@freebsd.org; Sat, 23 Jan 2010 01:05:52 +0100 Received: from 93-138-99-190.adsl.net.t-com.hr ([93.138.99.190]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 23 Jan 2010 01:05:52 +0100 Received: from ivoras by 93-138-99-190.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 23 Jan 2010 01:05:52 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Sat, 23 Jan 2010 01:05:29 +0100 Lines: 8 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 93-138-99-190.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.21 (X11/20090612) Sender: news Subject: A 7 vs 8 db benchmark X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 00:05:57 -0000 This is a bit old, I forgot to post it earlier: http://suckit.blog.hu/2009/10/05/freebsd_8_is_it_worth_to_upgrade Some interesting graphs there. Jeff Roberson said the bogus CPU topology shouldn't influence end-performance much. He thinks the lockmgr rewrite was responsible for most of the big performance difference. From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 23 01:28:21 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47CE31065670 for ; Sat, 23 Jan 2010 01:28:21 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-qy0-f201.google.com (mail-qy0-f201.google.com [209.85.221.201]) by mx1.freebsd.org (Postfix) with ESMTP id EA3DD8FC17 for ; Sat, 23 Jan 2010 01:28:20 +0000 (UTC) Received: by qyk39 with SMTP id 39so968919qyk.27 for ; Fri, 22 Jan 2010 17:28:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=tfWc94/5KTzPlemQ0Tez5mXpx1ptZy6K+hCelidercw=; b=eXzisVt2a1AyKxGpdKA27kNgXHYniFEVjoBE1XFV/GriFE6J7I1uoUYPHyE5KO9NxQ WutNWsvXJp8SlaAwoac7KGUBr69jO0Fi5WZG/Cy06onVqxHgmosE3Pek7nwDkCKY79Nw i6Bf2IiD5qeNkTh223LftDaeazGho37n4ThA0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=EUeYwD0gmT4U7QbiJtoWUMf/leSfmowcdssmXQuunrYO4CmLsem956SVa7ZP2Y+63/ nL26nc9ItTXpfqna1VhHT97+YbAVax/9mBG8Mb3AveRK42DjcdBfUqWbE/iZgYPtJsJ9 CQx4unSLcaY7RjGXJqtDB+bms4SUT73ig8FpU= Received: by 10.224.32.11 with SMTP id a11mr2509183qad.3.1264210099925; Fri, 22 Jan 2010 17:28:19 -0800 (PST) Received: from centel.dataix.local (ppp-22.1.dialinfree.com [209.172.22.1]) by mx.google.com with ESMTPS id 23sm2087697qyk.15.2010.01.22.17.28.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 22 Jan 2010 17:28:18 -0800 (PST) Sender: "J. Hellenthal" Date: Fri, 22 Jan 2010 20:28:09 -0500 From: jhell To: Alexander Leidinger In-Reply-To: <20100120111433.25801pnmhrxnirok@webmail.leidinger.net> Message-ID: References: <7f14551c1001190119x46c6b04dx2362cd1252f0d81@mail.gmail.com> <7f14551c1001190216w49814186n1ada2b721380502b@mail.gmail.com> <4B55C5A6.2020109@DataIX.net> <20100120111433.25801pnmhrxnirok@webmail.leidinger.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: freebsd-hackers@freebsd.org Subject: Re: Setting "zfs_arc_max" value in FreeBSD 8. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 01:28:21 -0000 On Wed, 20 Jan 2010 05:14, Alexander@ wrote: > Quoting jhell (from Tue, 19 Jan 2010 09:45:58 -0500): > >> On 1/19/2010 5:16 AM, Sherin George wrote: >>> Thanks Ivan :) >>> >>> I found It. add following in /boot/loader.conf >>> >>> =================== >>> vfs.zfs.arc_max="10244M" >>> =================== > >> I just thought I would give a shout at this for stable/7 as of last >> week. I am not sure if this is just me but I had tried to adjust >> zfs_arc_max and found out that it was unadjusted to my value after the >> system came back up. >> >> Anyone know if it is adjustable on a system with 1024MB of ram ? Is this >> just being auto calculated by some other value ? > > Can you confirm that you made the modification in /boot/loader.conf, and that > you used the double-quotes around the value as shown above? > > The code in 7-stable regarding this is the same as in 8-stable and 9-current, > so if it is done correctly, it has to change accordingly. > > Bye, > Alexander. > > Yes, The sysctl in question on my machine is/was put in loader.conf with the double quotes. Every time I have set this before I was trying to set it to a value >= 512M which with the values below must have not been excepted and fell back to 320M. If I set this to a value of <= 511M it works fine which leads me to believe this is limited by some other value listed below ? dmesg: real memory = 1072107520 (1022 MB) avail memory = 1035038720 (987 MB) loader.conf: kern.maxusers="512" << Not sure if this has anything to do with it. vfs.zfs.arc_min="80M" vfs.zfs.arc_max="512M" << This fails. stays at 335544320. vm.kmem_size="512M" vm.kmem_size_max="512M" << Maybe this one. kern.ipc.semmni="40" kern.ipc.semmns="300" kern.maxdsiz="536870912" kern.maxfiles="16384" There is points in time where I would like to dedicate 2/3 of ram or more using ZFS arc_max but somehow I feel like I have limited this by one of the other values that I had not had the time to look into if they impact larger values of arc_max being set. Thank you, Best regards,, -- jhell From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 23 02:40:04 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4CEE106568B for ; Sat, 23 Jan 2010 02:40:03 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by mx1.freebsd.org (Postfix) with ESMTP id 8D6E98FC08 for ; Sat, 23 Jan 2010 02:40:03 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 5so443253qwd.7 for ; Fri, 22 Jan 2010 18:40:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=Vi4QMMMItXrdmvUridc26XW47EJh1Ae4LrUa2EuZmR4=; b=XEIsokSZawMgiKxOUct3mWNSXEN39lQniMfBa8dmW6GLNuOz7Cr/r7nvJvU6brnczp cjiLX6rSmU0fHHFB9g1Uv0xZby6wCy1JJ0JA6B5g0zKC79R3/Rr4lUdpSmatcX4lywdC fMv1IZHSr1kePZaZAYqNYrZzb4UfcXQ9mOeOQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=Zve14o8hZ4kz+7qXF1704Rj+sWOf2LhL9qqvHTtTJs0EGsSKS0XcPQF73nwF1kKGml k5e3qd91YpEenpf/+unlZvrpuMuC9qCk3a2I3AbsYA94mNWONIUz4r7zX4PldD+OdjY7 F4mD5uuqyOCD46nocKSOWgRafss94jiEFxlaw= Received: by 10.224.121.203 with SMTP id i11mr2513796qar.199.1264214402740; Fri, 22 Jan 2010 18:40:02 -0800 (PST) Received: from centel.dataix.local (ppp-22.219.dialinfree.com [209.172.22.219]) by mx.google.com with ESMTPS id 22sm2160844qyk.2.2010.01.22.18.39.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 22 Jan 2010 18:40:01 -0800 (PST) Sender: "J. Hellenthal" Date: Fri, 22 Jan 2010 21:39:48 -0500 From: jhell To: Artem Belevich In-Reply-To: Message-ID: References: <7f14551c1001190119x46c6b04dx2362cd1252f0d81@mail.gmail.com> <7f14551c1001190216w49814186n1ada2b721380502b@mail.gmail.com> <4B55C5A6.2020109@DataIX.net> <20100120111433.25801pnmhrxnirok@webmail.leidinger.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Alexander Leidinger , FreeBSD Hackers Subject: Re: Setting "zfs_arc_max" value in FreeBSD 8. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 02:40:04 -0000 On Fri, 22 Jan 2010 11:47, fbsdlist@ wrote: >>> Anyone know if it is adjustable on a system with 1024MB of ram ? Is this >>> just being auto calculated by some other value ? > > You may want to make sure that vm.kmem_size is set to a value much > larger than vfs.zfs.arc_max. Default value may be too small to allow > such a large ARC. > > On a side note, I'm not sure that ZFS is a good match for system with > only 1G of RAM. By trial and error on my box with 8G or memory I've > figured out that I need to set arc_max ~1G below physical memory size > to avoid lockups under load. YMMV. > ZFS on this box with 1G has been quite enjoyable actually. With the settings I have posted I have not had any lockup on stable/7 and no sudden freezes or waits for transfers. So this entirely thus far has been a godsend. I had even put this thing through some of the tortures that others have posted to the list and not come up with the same results but better. There is obviously a lot of variables in this between hardware and configurations used so the results are minimal in comparison. With ZFS in place on this machine it performs a little bit under specs for the hardware but I wouldn't expect anything less for such a file-system. -- Thoughts & Prayers out to Haiti. jhell From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 23 05:19:39 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BCE361065672 for ; Sat, 23 Jan 2010 05:19:39 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.210.171]) by mx1.freebsd.org (Postfix) with ESMTP id 72B288FC0A for ; Sat, 23 Jan 2010 05:19:39 +0000 (UTC) Received: by yxe1 with SMTP id 1so1616780yxe.3 for ; Fri, 22 Jan 2010 21:19:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=pCQEOkQFIyUOy83DZWEOhyAW4+JWKaDGOLL4utN+bB8=; b=DR72wvyv/dquxgYpF8QpG0KW6pjYPDoYP+2NbKJdPJgRKlOIw/Zc6l5JM4fqCrGfNm ney7I7gb856HXnEKXIYn8IaFlwiO7O3g5EFtQlWh5vLGX8Bgaajmgp90YoaV0BQ3iAKW p+0zI0CrJBoondMfIDGRAOggESu5oUq6u9lik= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=kxQtGeNQCIHGLjAQ0f1ySU2CcT6VehNqdmGe+P4WrbrW2cuJIkgjx8ExuHTz1XbhAe hV7Ba2wXb7BiML3LqDkTpu/ihdTDOd117SCUBfibx0K4Om1tdZtDclk1r0MJ9MxAsUjn xSzLojBGQEHpjmTefQ9AHhT+9LHhSYfBiYQgI= MIME-Version: 1.0 Sender: artemb@gmail.com Received: by 10.90.135.14 with SMTP id i14mr3602579agd.24.1264223978625; Fri, 22 Jan 2010 21:19:38 -0800 (PST) In-Reply-To: References: <7f14551c1001190119x46c6b04dx2362cd1252f0d81@mail.gmail.com> <7f14551c1001190216w49814186n1ada2b721380502b@mail.gmail.com> <4B55C5A6.2020109@DataIX.net> <20100120111433.25801pnmhrxnirok@webmail.leidinger.net> Date: Fri, 22 Jan 2010 21:19:38 -0800 X-Google-Sender-Auth: 0409ad67480a1e60 Message-ID: From: Artem Belevich To: jhell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Alexander Leidinger , FreeBSD Hackers Subject: Re: Setting "zfs_arc_max" value in FreeBSD 8. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 05:19:39 -0000 Good to hear that it's usable for you even on a relatively low-memory system. Now, throw in an SSD for L2ARC, more RAM for ARC (and L2ARC housekeeping) and then it starts to really shine. As for better than expected performance, in my not-so scientific benchmarks (copying 10G-large files on 8-disk RAIDZ2 pool until filesystem is full) ZFS on FreeBSD did beat the hell out of OpenSolaris on the same hardware. I was really surprised. I'm sure something needed to be tuned on OpenSolaris, but it was nice to see FreeBSD performing so well. --Artem On Fri, Jan 22, 2010 at 6:39 PM, jhell wrote: > > On Fri, 22 Jan 2010 11:47, fbsdlist@ wrote: >>>> >>>> Anyone know if it is adjustable on a system with 1024MB of ram ? Is th= is >>>> just being auto calculated by some other value ? >> >> You may want to make sure that vm.kmem_size is set to a value much >> larger than vfs.zfs.arc_max. Default value may be too small to allow >> such a large ARC. >> >> On a side note, I'm not sure that ZFS is a good match for system with >> only 1G of RAM. By trial and error on my box with 8G or memory I've >> figured out that I need to set arc_max ~1G below physical memory size >> to avoid lockups under load. YMMV. >> > > ZFS on this box with 1G has been quite enjoyable actually. With the setti= ngs > I have posted I have not had any lockup on stable/7 and no sudden freezes= or > waits for transfers. So this entirely thus far has been a godsend. I had > even put this thing through some of the tortures that others have posted = to > the list and not come up with the same results but better. There is > obviously a lot of variables in this between hardware and configurations > used so the results are minimal in comparison. With ZFS in place on this > machine it performs a little bit under specs for the hardware but I would= n't > expect anything less for such a file-system. > > -- > > =A0Thoughts & Prayers out to Haiti. > > =A0jhell > > From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 23 09:19:07 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3085E106568B for ; Sat, 23 Jan 2010 09:19:07 +0000 (UTC) (envelope-from list@sheringeorge.co.cc) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx1.freebsd.org (Postfix) with ESMTP id 169038FC08 for ; Sat, 23 Jan 2010 09:19:06 +0000 (UTC) Received: by pwi15 with SMTP id 15so1419098pwi.3 for ; Sat, 23 Jan 2010 01:19:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.106.10 with SMTP id i10mr2817692rvm.188.1264238346584; Sat, 23 Jan 2010 01:19:06 -0800 (PST) Date: Sat, 23 Jan 2010 14:49:06 +0530 Message-ID: <7f14551c1001230119r65464667t6d6b604118101419@mail.gmail.com> From: Sherin George To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Strange network issue in freebsd 8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 09:19:07 -0000 Hello, i am facing some sort of strange network issue in a freebsd server occasionally. OS: FreeBSD 8.0-RELEASE - amd64 The servers loses network connection once in a few days. I logged into console and verified that network is up. I even restarted network service using following command. /etc/rc.d/netif restart Still, it didn't fix. I checked /var/log/messages, but I am not getting any clue. ============== Jan 19 12:10:20 myserver kernel: GEOM_MIRROR: Device gm0: rebuilding provider ad0 finished. Jan 19 20:20:23 myserver nfsd[732]: select failed: Interrupted system call Jan 19 20:21:07 myserver nfsd[732]: select failed: Interrupted system call Jan 23 02:14:33 myserver login: ROOT LOGIN (root) ON ttyv0 Jan 23 02:19:51 myserver kernel: ifa_del_loopback_route: deletion failed Jan 23 02:19:57 myserver kernel: em0: link state changed to DOWN Jan 23 02:20:02 myserver kernel: em0: link state changed to UP Jan 23 02:29:58 myserver reboot: rebooted by root Jan 23 02:29:58 myserver syslogd: exiting on signal 15 Jan 23 02:31:31 myserver syslogd: kernel boot file is /boot/kernel/kernel Jan 23 02:31:31 myserver kernel: Copyright (c) 1992-2009 The FreeBSD Project. Jan 23 02:31:31 myserver kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jan 23 02:31:31 myserver kernel: The Regents of the University of California. All rights reserved. Jan 23 02:31:31 myserver kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Jan 23 02:31:31 myserver kernel: FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:02:08 UTC 2009 Jan 23 02:31:31 myserver kernel: root@mason.cse.buffalo.edu: /usr/obj/usr/src/sys/GENERIC Jan 23 02:31:31 myserver kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 ============== Network, TCP stack all were up. It was pinging gateway even. But, traceroute was not going beyond gateway. I believe the issue is not related to anything outside server since a reboot always fixes the issue. I will be grateful for any advise that can help me in troubleshooting this problem. -- Best Regards, Sherin From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 23 12:07:55 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4E4D106566B for ; Sat, 23 Jan 2010 12:07:54 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-exrelay3.uni-muenster.de (ZIVM-EXRELAY3.UNI-MUENSTER.DE [128.176.192.20]) by mx1.freebsd.org (Postfix) with ESMTP id 770868FC16 for ; Sat, 23 Jan 2010 12:07:52 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.49,329,1262559600"; d="txt'?scan'208";a="24160735" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER01.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay3.uni-muenster.de with ESMTP; 23 Jan 2010 13:07:51 +0100 Received: by ZIVMAILUSER01.UNI-MUENSTER.DE (Postfix, from userid 149459) id AAC021B0768; Sat, 23 Jan 2010 13:07:51 +0100 (CET) Date: Sat, 23 Jan 2010 13:07:44 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=+permail-20100123120744f0889e84000015c5-a_best01+ Cc: Subject: [patch] extending/completing brandelf's OS knowledge X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 12:07:55 -0000 This is a MIME encoded multipart message. --+permail-20100123120744f0889e84000015c5-a_best01+ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit patch is pretty self explanatory i guess. brandelf should now be able to handle all OSes defined in the current SCO elf specs (26.10.2009). cheers. alex --+permail-20100123120744f0889e84000015c5-a_best01+ Content-Type: text/plain Content-Transfer-Encoding: Base64 Content-Disposition: attachment; filename="brandelf.patch.txt" SW5kZXg6IHVzci5iaW4vYnJhbmRlbGYvYnJhbmRlbGYuMQo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB1c3IuYmlu L2JyYW5kZWxmL2JyYW5kZWxmLjEJKHJldmlzaW9uIDIwMjg0OCkKKysrIHVzci5iaW4vYnJhbmRl bGYvYnJhbmRlbGYuMQkod29ya2luZyBjb3B5KQpAQCAtMjcsNyArMjcsNyBAQAogLlwiCiAuXCIg JEZyZWVCU0QkCiAuXCIKLS5EZCBGZWJydWFyeSA2LCAxOTk3CisuRGQgSmFudWFyeSAyMywgMjAx MAogLkR0IEJSQU5ERUxGIDEKIC5PcwogLlNoIE5BTUUKQEAgLTYyLDEwICs2MiwyNSBAQAogLkFy IHN0cmluZwogQUJJIHR5cGUuCiBDdXJyZW50bHkgc3VwcG9ydGVkIEFCSXMgYXJlCisuRHEgTGkg U1ZSNCAsCisuRHEgTGkgSFBVWCAsCisuRHEgTGkgTmV0QlNEICwKKy5EcSBMaSBMaW51eCAsCisu RHEgTGkgSHVyZCAsCisuRHEgTGkgODZPcGVuICwKKy5EcSBMaSBTb2xhcmlzICwKKy5EcSBMaSBB SVggLAorLkRxIExpIElSSVggLAogLkRxIExpIEZyZWVCU0QgLAotLkRxIExpIExpbnV4ICwKKy5E cSBMaSBUUlU2NCAsCisuRHEgTGkgTW9kZXN0byAsCisuRHEgTGkgT3BlbkJTRCAsCisuRHEgTGkg T3BlblZNUyAsCisuRHEgTGkgSFBOU0sgLAorLkRxIExpIEFST1MgLAorLkRxIExpIEZlbml4T1MK IGFuZAotLkRxIExpIFNWUjQgLgorLkRxIExpIEFSTSAuCiAuSXQgQXIgZmlsZQogSWYKIC5GbCB0 IEFyIHN0cmluZwpAQCAtOTUsNyArMTEwLDcgQEAKIC5ScwogLiVBIFRoZSBTYW50YSBDcnV6IE9w ZXJhdGlvbiwgSW5jLgogLiVUIFN5c3RlbSBWIEFwcGxpY2F0aW9uIEJpbmFyeSBJbnRlcmZhY2UK LS4lRCBBcHJpbCAyOSwgMTk5OCAoRFJBRlQpCisuJUQgT2N0b2JlciAyNiwgMjAwOSAoRFJBRlQp CiAuJVUgaHR0cDovL3d3dy5zY28uY29tL2RldmVsb3Blci9kZXZzcGVjcy8KIC5SZQogLlNoIEhJ U1RPUlkKSW5kZXg6IHVzci5iaW4vYnJhbmRlbGYvYnJhbmRlbGYuYwo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB1 c3IuYmluL2JyYW5kZWxmL2JyYW5kZWxmLmMJKHJldmlzaW9uIDIwMjg0OCkKKysrIHVzci5iaW4v YnJhbmRlbGYvYnJhbmRlbGYuYwkod29ya2luZyBjb3B5KQpAQCAtNDksMTIgKzQ5LDI1IEBACiAJ Y29uc3QgY2hhciAqc3RyOwogCWludCB2YWx1ZTsKIH07Ci0vKiBYWFggLSBhbnkgbW9yZSB0eXBl cz8gKi8KIHN0YXRpYyBzdHJ1Y3QgRUxGdHlwZXMgZWxmdHlwZXNbXSA9IHsKLQl7ICJGcmVlQlNE IiwJRUxGT1NBQklfRlJFRUJTRCB9LAorCXsgIlNWUjQiLAlFTEZPU0FCSV9OT05FIH0sCisJeyAi SFBVWCIsCUVMRk9TQUJJX0hQVVggfSwKKwl7ICJOZXRCU0QiLAlFTEZPU0FCSV9ORVRCU0QgfSwK IAl7ICJMaW51eCIsCUVMRk9TQUJJX0xJTlVYIH0sCisJeyAiSHVyZCIsCUVMRk9TQUJJX0hVUkQg fSwKKwl7ICI4Nk9wZW4iLAlFTEZPU0FCSV84Nk9QRU4gfSwKIAl7ICJTb2xhcmlzIiwJRUxGT1NB QklfU09MQVJJUyB9LAotCXsgIlNWUjQiLAlFTEZPU0FCSV9TWVNWIH0KKwl7ICJBSVgiLAlFTEZP U0FCSV9BSVggfSwKKwl7ICJJUklYIiwJRUxGT1NBQklfSVJJWCB9LAorCXsgIkZyZWVCU0QiLAlF TEZPU0FCSV9GUkVFQlNEIH0sCisJeyAiVFJVNjQiLAlFTEZPU0FCSV9UUlU2NCB9LAorCXsgIk1v ZGVzdG8iLAlFTEZPU0FCSV9NT0RFU1RPIH0sCisJeyAiT3BlbkJTRCIsCUVMRk9TQUJJX09QRU5C U0QgfSwKKwl7ICJPcGVuVk1TIiwJRUxGT1NBQklfT1BFTlZNUyB9LAorCXsgIkhQTlNLIiwJRUxG T1NBQklfTlNLIH0sCisJeyAiQVJPUyIsCUVMRk9TQUJJX0FST1MgfSwKKwl7ICJGZW5peE9TIiwJ RUxGT1NBQklfRkVOSVhPUyB9LAorCXsgIkFSTSIsCUVMRk9TQUJJX0FSTSB9CiB9OwogCiBpbnQK SW5kZXg6IHN5cy9zeXMvZWxmX2NvbW1vbi5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9zeXMvZWxmX2Nv bW1vbi5oCShyZXZpc2lvbiAyMDI4NDgpCisrKyBzeXMvc3lzL2VsZl9jb21tb24uaAkod29ya2lu ZyBjb3B5KQpAQCAtMTEzLDYgKzExMyw3IEBACiAjZGVmaW5lCUVMRk9TQUJJX09QRU5WTVMJMTMJ LyogT3BlbiBWTVMgKi8KICNkZWZpbmUJRUxGT1NBQklfTlNLCQkxNAkvKiBIUCBOb24tU3RvcCBL ZXJuZWwgKi8KICNkZWZpbmUJRUxGT1NBQklfQVJPUwkJMTUJLyogQW1pZ2EgUmVzZWFyY2ggT1Mg Ki8KKyNkZWZpbmUJRUxGT1NBQklfRkVOSVhPUwkxNgkvKiBGZW5peE9TICovCiAjZGVmaW5lCUVM Rk9TQUJJX0FSTQkJOTcJLyogQVJNICovCiAjZGVmaW5lCUVMRk9TQUJJX1NUQU5EQUxPTkUJMjU1 CS8qIFN0YW5kYWxvbmUgKGVtYmVkZGVkKSBhcHBsaWNhdGlvbiAqLwogCg== --+permail-20100123120744f0889e84000015c5-a_best01+-- From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 23 09:25:23 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81A07106566B for ; Sat, 23 Jan 2010 09:25:23 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 383668FC14 for ; Sat, 23 Jan 2010 09:25:22 +0000 (UTC) Received: from outgoing.leidinger.net (pD9E2CA42.dip.t-dialin.net [217.226.202.66]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 6302484515E; Sat, 23 Jan 2010 10:25:18 +0100 (CET) Received: from unknown (unknown [192.168.2.110]) by outgoing.leidinger.net (Postfix) with ESMTP id 4DDD4235134; Sat, 23 Jan 2010 10:25:15 +0100 (CET) Date: Sat, 23 Jan 2010 10:25:13 +0100 From: Alexander Leidinger To: jhell Message-ID: <20100123102513.00001f67@unknown> In-Reply-To: References: <7f14551c1001190119x46c6b04dx2362cd1252f0d81@mail.gmail.com> <7f14551c1001190216w49814186n1ada2b721380502b@mail.gmail.com> <4B55C5A6.2020109@DataIX.net> <20100120111433.25801pnmhrxnirok@webmail.leidinger.net> X-Mailer: Claws Mail 3.7.2cvs15 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 6302484515E.588E7 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.44, required 6, autolearn=disabled, ALL_TRUSTED -1.44) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1264843518.83811@DyA0xFoM55/qUskiJjnXPw X-EBL-Spam-Status: No X-Mailman-Approved-At: Sat, 23 Jan 2010 12:45:46 +0000 Cc: FreeBSD Hackers , Artem Belevich Subject: Re: Setting "zfs_arc_max" value in FreeBSD 8. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 09:25:23 -0000 On Fri, 22 Jan 2010 21:39:48 -0500 jhell wrote: > > On Fri, 22 Jan 2010 11:47, fbsdlist@ wrote: > >>> Anyone know if it is adjustable on a system with 1024MB of ram ? > >>> Is this just being auto calculated by some other value ? > > > > You may want to make sure that vm.kmem_size is set to a value much > > larger than vfs.zfs.arc_max. Default value may be too small to allow > > such a large ARC. > > > > On a side note, I'm not sure that ZFS is a good match for system > > with only 1G of RAM. By trial and error on my box with 8G or memory > > I've figured out that I need to set arc_max ~1G below physical > > memory size to avoid lockups under load. YMMV. > > > > ZFS on this box with 1G has been quite enjoyable actually. With the > settings I have posted I have not had any lockup on stable/7 and no > sudden freezes or waits for transfers. So this entirely thus far has > been a godsend. I had even put this thing through some of the > tortures that others have posted to the list and not come up with the > same results but better. There is obviously a lot of variables in > this between hardware and configurations used so the results are > minimal in comparison. With ZFS in place on this machine it performs > a little bit under specs for the hardware but I wouldn't expect > anything less for such a file-system. You may want to switch to fletcher4 checksums. This is the default in Solaris and 8.0 now. I didn't merge this change to 7-stable as I didn't took the time to analyze if the change for the default has some unwanted implications for existig pools. I have a 9-current box with 1GB RAM and ZFS which shows the slow-down after some hours of running (and doing things) too. It would be good to make a list of OS versions and if there are slowdowns or not (anyone with time out there to have a look at the mails and get this info out of the mails / people?). Maybe it is related to changes not in ZFS... Bye, Alexander. From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 23 09:44:40 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 155AE106566C for ; Sat, 23 Jan 2010 09:44:40 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id AE68F8FC0C for ; Sat, 23 Jan 2010 09:44:39 +0000 (UTC) Received: from outgoing.leidinger.net (pD9E2CA42.dip.t-dialin.net [217.226.202.66]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 57FFA84515E; Sat, 23 Jan 2010 10:44:33 +0100 (CET) Received: from unknown (unknown [192.168.2.110]) by outgoing.leidinger.net (Postfix) with ESMTP id 32FA623555B; Sat, 23 Jan 2010 10:44:30 +0100 (CET) Date: Sat, 23 Jan 2010 10:44:28 +0100 From: Alexander Leidinger To: jhell Message-ID: <20100123104428.000021b5@unknown> In-Reply-To: References: <7f14551c1001190119x46c6b04dx2362cd1252f0d81@mail.gmail.com> <7f14551c1001190216w49814186n1ada2b721380502b@mail.gmail.com> <4B55C5A6.2020109@DataIX.net> <20100120111433.25801pnmhrxnirok@webmail.leidinger.net> X-Mailer: Claws Mail 3.7.2cvs15 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 57FFA84515E.9FC50 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.363, required 6, autolearn=disabled, ALL_TRUSTED -1.44, TW_ZF 0.08) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1264844673.92093@+374hwtCd7ONB6WpEGie2g X-EBL-Spam-Status: No X-Mailman-Approved-At: Sat, 23 Jan 2010 12:46:00 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: Setting "zfs_arc_max" value in FreeBSD 8. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 09:44:40 -0000 On Fri, 22 Jan 2010 20:28:09 -0500 jhell wrote: > > On Wed, 20 Jan 2010 05:14, Alexander@ wrote: > > Quoting jhell (from Tue, 19 Jan 2010 09:45:58 > > -0500): > > > >> On 1/19/2010 5:16 AM, Sherin George wrote: > >>> Thanks Ivan :) > >>> > >>> I found It. add following in /boot/loader.conf > >>> > >>> =================== > >>> vfs.zfs.arc_max="10244M" > >>> =================== > > > >> I just thought I would give a shout at this for stable/7 as of last > >> week. I am not sure if this is just me but I had tried to adjust > >> zfs_arc_max and found out that it was unadjusted to my value after > >> the system came back up. > >> > >> Anyone know if it is adjustable on a system with 1024MB of ram ? > >> Is this just being auto calculated by some other value ? > > > > Can you confirm that you made the modification > > in /boot/loader.conf, and that you used the double-quotes around > > the value as shown above? > > > > The code in 7-stable regarding this is the same as in 8-stable and > > 9-current, so if it is done correctly, it has to change accordingly. > Yes, > > The sysctl in question on my machine is/was put in loader.conf with > the double quotes. > > Every time I have set this before I was trying to set it to a value > >= 512M which with the values below must have not been excepted and > >fell back > to 320M. > > If I set this to a value of <= 511M it works fine which leads me to > believe this is limited by some other value listed below ? It can not be bigger than kmem_max. While I do not know if this is checked, it sounds from your description that it is. > dmesg: > real memory = 1072107520 (1022 MB) > avail memory = 1035038720 (987 MB) > > loader.conf: > kern.maxusers="512" << Not sure if this has anything to do It should influence the kmem_max... if you would not change it yourself. > with it. vfs.zfs.arc_min="80M" > vfs.zfs.arc_max="512M" << This fails. stays at 335544320. It needs to be a lot less than kmem_max (the arc is allocated from the kmem, as such it can not exceed kmem_max, and as other parts of the kernel also need kmem, you need to limit the arc size). On a 32bit system with 1 GB RAM I have kmem_size_max set to 512M and arc_max set to 160M. > vm.kmem_size="512M" > vm.kmem_size_max="512M" << Maybe this one. > kern.ipc.semmni="40" > kern.ipc.semmns="300" > kern.maxdsiz="536870912" > kern.maxfiles="16384" Bye, Alexander. From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 23 13:34:25 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4136E106568D for ; Sat, 23 Jan 2010 13:34:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id ADF658FC14 for ; Sat, 23 Jan 2010 13:34:24 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o0NDYJnm088388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Jan 2010 15:34:19 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id o0NDYJ1s000842; Sat, 23 Jan 2010 15:34:19 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id o0NDYJLP000841; Sat, 23 Jan 2010 15:34:19 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 23 Jan 2010 15:34:19 +0200 From: Kostik Belousov To: Alexander Best Message-ID: <20100123133419.GI59590@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xSXKkePCxtN78XFb" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org Subject: Re: [patch] extending/completing brandelf's OS knowledge X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 13:34:25 -0000 --xSXKkePCxtN78XFb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 23, 2010 at 01:07:44PM +0100, Alexander Best wrote: > patch is pretty self explanatory i guess. brandelf should now be able to > handle all OSes defined in the current SCO elf specs (26.10.2009). >=20 > cheers. > alex > Index: usr.bin/brandelf/brandelf.1 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- usr.bin/brandelf/brandelf.1 (revision 202848) > +++ usr.bin/brandelf/brandelf.1 (working copy) > @@ -27,7 +27,7 @@ > .\" > .\" $FreeBSD$ > .\" > -.Dd February 6, 1997 > +.Dd January 23, 2010 > .Dt BRANDELF 1 > .Os > .Sh NAME > @@ -62,10 +62,25 @@ > .Ar string > ABI type. > Currently supported ABIs are > +.Dq Li SVR4 , > +.Dq Li HPUX , > +.Dq Li NetBSD , > +.Dq Li Linux , > +.Dq Li Hurd , > +.Dq Li 86Open , > +.Dq Li Solaris , > +.Dq Li AIX , > +.Dq Li IRIX , > .Dq Li FreeBSD , > -.Dq Li Linux , > +.Dq Li TRU64 , > +.Dq Li Modesto , > +.Dq Li OpenBSD , > +.Dq Li OpenVMS , > +.Dq Li HPNSK , > +.Dq Li AROS , > +.Dq Li FenixOS > and > -.Dq Li SVR4 . > +.Dq Li ARM . > .It Ar file > If > .Fl t Ar string > @@ -95,7 +110,7 @@ > .Rs > .%A The Santa Cruz Operation, Inc. > .%T System V Application Binary Interface > -.%D April 29, 1998 (DRAFT) > +.%D October 26, 2009 (DRAFT) > .%U http://www.sco.com/developer/devspecs/ > .Re > .Sh HISTORY > Index: usr.bin/brandelf/brandelf.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- usr.bin/brandelf/brandelf.c (revision 202848) > +++ usr.bin/brandelf/brandelf.c (working copy) > @@ -49,12 +49,25 @@ > const char *str; > int value; > }; > -/* XXX - any more types? */ > static struct ELFtypes elftypes[] =3D { > - { "FreeBSD", ELFOSABI_FREEBSD }, > + { "SVR4", ELFOSABI_NONE }, > + { "HPUX", ELFOSABI_HPUX }, > + { "NetBSD", ELFOSABI_NETBSD }, > { "Linux", ELFOSABI_LINUX }, > + { "Hurd", ELFOSABI_HURD }, > + { "86Open", ELFOSABI_86OPEN }, > { "Solaris", ELFOSABI_SOLARIS }, > - { "SVR4", ELFOSABI_SYSV } > + { "AIX", ELFOSABI_AIX }, > + { "IRIX", ELFOSABI_IRIX }, > + { "FreeBSD", ELFOSABI_FREEBSD }, > + { "TRU64", ELFOSABI_TRU64 }, > + { "Modesto", ELFOSABI_MODESTO }, > + { "OpenBSD", ELFOSABI_OPENBSD }, > + { "OpenVMS", ELFOSABI_OPENVMS }, > + { "HPNSK", ELFOSABI_NSK }, > + { "AROS", ELFOSABI_AROS }, > + { "FenixOS", ELFOSABI_FENIXOS }, > + { "ARM", ELFOSABI_ARM } > }; > =20 > int > Index: sys/sys/elf_common.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/sys/elf_common.h (revision 202848) > +++ sys/sys/elf_common.h (working copy) > @@ -113,6 +113,7 @@ > #define ELFOSABI_OPENVMS 13 /* Open VMS */ > #define ELFOSABI_NSK 14 /* HP Non-Stop Kernel */ > #define ELFOSABI_AROS 15 /* Amiga Research OS */ > +#define ELFOSABI_FENIXOS 16 /* FenixOS */ > #define ELFOSABI_ARM 97 /* ARM */ > #define ELFOSABI_STANDALONE 255 /* Standalone (embedded) application */ > =20 This does not make a sense. brandelf(1) is (was) used as a way to specify hint for the FreeBSD kernel under which ABI emulation the binary should be activated. We do not support, and I believe never will, ABIs added in the patch. --xSXKkePCxtN78XFb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkta+tsACgkQC3+MBN1Mb4g01wCg6fpHxyRDLeQ0sPhDW8dkFVp9 ImEAn0Ps5/mGAWlWLX7gEg35jieU71Iu =mVj6 -----END PGP SIGNATURE----- --xSXKkePCxtN78XFb-- From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 23 14:38:11 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6192C106566C for ; Sat, 23 Jan 2010 14:38:11 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-exrelay2.uni-muenster.de (ZIVM-EXRELAY2.UNI-MUENSTER.DE [128.176.192.15]) by mx1.freebsd.org (Postfix) with ESMTP id A7BAF8FC15 for ; Sat, 23 Jan 2010 14:38:10 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.49,329,1262559600"; d="scan'208";a="234756187" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER04.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay2.uni-muenster.de with ESMTP; 23 Jan 2010 15:38:08 +0100 Received: by ZIVMAILUSER04.UNI-MUENSTER.DE (Postfix, from userid 149459) id D12161B07BD; Sat, 23 Jan 2010 15:38:08 +0100 (CET) Date: Sat, 23 Jan 2010 15:38:08 +0100 (CET) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Kostik Belousov Message-ID: In-Reply-To: <20100123133419.GI59590@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: [patch] extending/completing brandelf's OS knowledge X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 14:38:11 -0000 oh. i thought brandelf's purpose was to adjust an executable's OS ABI on a general basis. an example would be having solaris executables with the OS ABI set to 0. although freebsd won't support running these binaries brandelf could be used to correct the OS ABI value which might come in handy if you're using freebsd for backup purposes e.g. or is this purpose covered by a different application in the base dir? cheers. alex Kostik Belousov schrieb am 2010-01-23: > On Sat, Jan 23, 2010 at 01:07:44PM +0100, Alexander Best wrote: > > patch is pretty self explanatory i guess. brandelf should now be > > able to > > handle all OSes defined in the current SCO elf specs (26.10.2009). > > cheers. > > alex > > Index: usr.bin/brandelf/brandelf.1 > > =================================================================== > > --- usr.bin/brandelf/brandelf.1 (revision 202848) > > +++ usr.bin/brandelf/brandelf.1 (working copy) > > @@ -27,7 +27,7 @@ > > .\" > > .\" $FreeBSD$ > > .\" > > -.Dd February 6, 1997 > > +.Dd January 23, 2010 > > .Dt BRANDELF 1 > > .Os > > .Sh NAME > > @@ -62,10 +62,25 @@ > > .Ar string > > ABI type. > > Currently supported ABIs are > > +.Dq Li SVR4 , > > +.Dq Li HPUX , > > +.Dq Li NetBSD , > > +.Dq Li Linux , > > +.Dq Li Hurd , > > +.Dq Li 86Open , > > +.Dq Li Solaris , > > +.Dq Li AIX , > > +.Dq Li IRIX , > > .Dq Li FreeBSD , > > -.Dq Li Linux , > > +.Dq Li TRU64 , > > +.Dq Li Modesto , > > +.Dq Li OpenBSD , > > +.Dq Li OpenVMS , > > +.Dq Li HPNSK , > > +.Dq Li AROS , > > +.Dq Li FenixOS > > and > > -.Dq Li SVR4 . > > +.Dq Li ARM . > > .It Ar file > > If > > .Fl t Ar string > > @@ -95,7 +110,7 @@ > > .Rs > > .%A The Santa Cruz Operation, Inc. > > .%T System V Application Binary Interface > > -.%D April 29, 1998 (DRAFT) > > +.%D October 26, 2009 (DRAFT) > > .%U http://www.sco.com/developer/devspecs/ > > .Re > > .Sh HISTORY > > Index: usr.bin/brandelf/brandelf.c > > =================================================================== > > --- usr.bin/brandelf/brandelf.c (revision 202848) > > +++ usr.bin/brandelf/brandelf.c (working copy) > > @@ -49,12 +49,25 @@ > > const char *str; > > int value; > > }; > > -/* XXX - any more types? */ > > static struct ELFtypes elftypes[] = { > > - { "FreeBSD", ELFOSABI_FREEBSD }, > > + { "SVR4", ELFOSABI_NONE }, > > + { "HPUX", ELFOSABI_HPUX }, > > + { "NetBSD", ELFOSABI_NETBSD }, > > { "Linux", ELFOSABI_LINUX }, > > + { "Hurd", ELFOSABI_HURD }, > > + { "86Open", ELFOSABI_86OPEN }, > > { "Solaris", ELFOSABI_SOLARIS }, > > - { "SVR4", ELFOSABI_SYSV } > > + { "AIX", ELFOSABI_AIX }, > > + { "IRIX", ELFOSABI_IRIX }, > > + { "FreeBSD", ELFOSABI_FREEBSD }, > > + { "TRU64", ELFOSABI_TRU64 }, > > + { "Modesto", ELFOSABI_MODESTO }, > > + { "OpenBSD", ELFOSABI_OPENBSD }, > > + { "OpenVMS", ELFOSABI_OPENVMS }, > > + { "HPNSK", ELFOSABI_NSK }, > > + { "AROS", ELFOSABI_AROS }, > > + { "FenixOS", ELFOSABI_FENIXOS }, > > + { "ARM", ELFOSABI_ARM } > > }; > > int > > Index: sys/sys/elf_common.h > > =================================================================== > > --- sys/sys/elf_common.h (revision 202848) > > +++ sys/sys/elf_common.h (working copy) > > @@ -113,6 +113,7 @@ > > #define ELFOSABI_OPENVMS 13 /* Open VMS */ > > #define ELFOSABI_NSK 14 /* HP Non-Stop Kernel > > */ > > #define ELFOSABI_AROS 15 /* Amiga Research OS > > */ > > +#define ELFOSABI_FENIXOS 16 /* FenixOS */ > > #define ELFOSABI_ARM 97 /* ARM */ > > #define ELFOSABI_STANDALONE 255 /* Standalone > > (embedded) application */ > This does not make a sense. brandelf(1) is (was) used as a way to > specify > hint for the FreeBSD kernel under which ABI emulation the binary > should > be activated. > We do not support, and I believe never will, ABIs added in the patch. From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 23 15:08:22 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF8BA106566C for ; Sat, 23 Jan 2010 15:08:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 024A78FC0A for ; Sat, 23 Jan 2010 15:08:21 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o0NF8H6w094998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Jan 2010 17:08:17 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id o0NF8HvC001327; Sat, 23 Jan 2010 17:08:17 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id o0NF8HlA001326; Sat, 23 Jan 2010 17:08:17 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 23 Jan 2010 17:08:17 +0200 From: Kostik Belousov To: Alexander Best Message-ID: <20100123150817.GJ59590@deviant.kiev.zoral.com.ua> References: <20100123133419.GI59590@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BGXdj9oeR8eUT83d" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org Subject: Re: [patch] extending/completing brandelf's OS knowledge X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 15:08:22 -0000 --BGXdj9oeR8eUT83d Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 23, 2010 at 03:38:08PM +0100, Alexander Best wrote: > oh. i thought brandelf's purpose was to adjust an executable's OS ABI on a > general basis. an example would be having solaris executables with the OS= ABI > set to 0. although freebsd won't support running these binaries brandelf = could > be used to correct the OS ABI value which might come in handy if you're u= sing > freebsd for backup purposes e.g. >=20 > or is this purpose covered by a different application in the base dir? I do not see a need for such rudimentary ELF editor in the base at all. Ports do have "hacker tools". After the work of dchagin@/bz@, brandelf is needed only for the corner cases, if at all. >=20 > cheers. > alex >=20 > Kostik Belousov schrieb am 2010-01-23: > > On Sat, Jan 23, 2010 at 01:07:44PM +0100, Alexander Best wrote: > > > patch is pretty self explanatory i guess. brandelf should now be > > > able to > > > handle all OSes defined in the current SCO elf specs (26.10.2009). >=20 > > > cheers. > > > alex >=20 > > > Index: usr.bin/brandelf/brandelf.1 > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > --- usr.bin/brandelf/brandelf.1 (revision 202848) > > > +++ usr.bin/brandelf/brandelf.1 (working copy) > > > @@ -27,7 +27,7 @@ > > > .\" > > > .\" $FreeBSD$ > > > .\" > > > -.Dd February 6, 1997 > > > +.Dd January 23, 2010 > > > .Dt BRANDELF 1 > > > .Os > > > .Sh NAME > > > @@ -62,10 +62,25 @@ > > > .Ar string > > > ABI type. > > > Currently supported ABIs are > > > +.Dq Li SVR4 , > > > +.Dq Li HPUX , > > > +.Dq Li NetBSD , > > > +.Dq Li Linux , > > > +.Dq Li Hurd , > > > +.Dq Li 86Open , > > > +.Dq Li Solaris , > > > +.Dq Li AIX , > > > +.Dq Li IRIX , > > > .Dq Li FreeBSD , > > > -.Dq Li Linux , > > > +.Dq Li TRU64 , > > > +.Dq Li Modesto , > > > +.Dq Li OpenBSD , > > > +.Dq Li OpenVMS , > > > +.Dq Li HPNSK , > > > +.Dq Li AROS , > > > +.Dq Li FenixOS > > > and > > > -.Dq Li SVR4 . > > > +.Dq Li ARM . > > > .It Ar file > > > If > > > .Fl t Ar string > > > @@ -95,7 +110,7 @@ > > > .Rs > > > .%A The Santa Cruz Operation, Inc. > > > .%T System V Application Binary Interface > > > -.%D April 29, 1998 (DRAFT) > > > +.%D October 26, 2009 (DRAFT) > > > .%U http://www.sco.com/developer/devspecs/ > > > .Re > > > .Sh HISTORY > > > Index: usr.bin/brandelf/brandelf.c > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > --- usr.bin/brandelf/brandelf.c (revision 202848) > > > +++ usr.bin/brandelf/brandelf.c (working copy) > > > @@ -49,12 +49,25 @@ > > > const char *str; > > > int value; > > > }; > > > -/* XXX - any more types? */ > > > static struct ELFtypes elftypes[] =3D { > > > - { "FreeBSD", ELFOSABI_FREEBSD }, > > > + { "SVR4", ELFOSABI_NONE }, > > > + { "HPUX", ELFOSABI_HPUX }, > > > + { "NetBSD", ELFOSABI_NETBSD }, > > > { "Linux", ELFOSABI_LINUX }, > > > + { "Hurd", ELFOSABI_HURD }, > > > + { "86Open", ELFOSABI_86OPEN }, > > > { "Solaris", ELFOSABI_SOLARIS }, > > > - { "SVR4", ELFOSABI_SYSV } > > > + { "AIX", ELFOSABI_AIX }, > > > + { "IRIX", ELFOSABI_IRIX }, > > > + { "FreeBSD", ELFOSABI_FREEBSD }, > > > + { "TRU64", ELFOSABI_TRU64 }, > > > + { "Modesto", ELFOSABI_MODESTO }, > > > + { "OpenBSD", ELFOSABI_OPENBSD }, > > > + { "OpenVMS", ELFOSABI_OPENVMS }, > > > + { "HPNSK", ELFOSABI_NSK }, > > > + { "AROS", ELFOSABI_AROS }, > > > + { "FenixOS", ELFOSABI_FENIXOS }, > > > + { "ARM", ELFOSABI_ARM } > > > }; >=20 > > > int > > > Index: sys/sys/elf_common.h > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > --- sys/sys/elf_common.h (revision 202848) > > > +++ sys/sys/elf_common.h (working copy) > > > @@ -113,6 +113,7 @@ > > > #define ELFOSABI_OPENVMS 13 /* Open VMS */ > > > #define ELFOSABI_NSK 14 /* HP Non-Stop Kernel > > > */ > > > #define ELFOSABI_AROS 15 /* Amiga Research OS > > > */ > > > +#define ELFOSABI_FENIXOS 16 /* FenixOS */ > > > #define ELFOSABI_ARM 97 /* ARM */ > > > #define ELFOSABI_STANDALONE 255 /* Standalone > > > (embedded) application */ >=20 >=20 > > This does not make a sense. brandelf(1) is (was) used as a way to > > specify > > hint for the FreeBSD kernel under which ABI emulation the binary > > should > > be activated. >=20 > > We do not support, and I believe never will, ABIs added in the patch. --BGXdj9oeR8eUT83d Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAktbEOAACgkQC3+MBN1Mb4hc0gCghKbLwbFkzVokL2tRaC1jbKMC M58AnjW5wPWf6yZkSGxoPeh5n1njzRTQ =iiec -----END PGP SIGNATURE----- --BGXdj9oeR8eUT83d-- From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 23 15:11:19 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9A501065679 for ; Sat, 23 Jan 2010 15:11:19 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by mx1.freebsd.org (Postfix) with ESMTP id 568CB8FC1C for ; Sat, 23 Jan 2010 15:11:19 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 5so531953qwd.7 for ; Sat, 23 Jan 2010 07:11:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=Ur6a2Wr98dbHy6HuS3bKdkBHku3qHNMKvs0ptCbrHco=; b=Lq1yXBXdTJOsfqn5AIei8MjeYsAkVAIvZqVVyHDOBjbq+Y4DZJExoXu2i7cqGoZA4X nVfKfiBqf0avRt6MBMXMCv3GMvR951h4c9jF0wclemP3toQmG2rho4RSWgvn24AVJrLa YuHd+sZMP7hgVIzJsx/II+VutdsNVrsJh6jd4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=f5D3hQskpQzh3258MV/c7RBNW+RhstltiK9JtvkFR7IHUWC9F67iI7pdiJeFu73s22 IA8MBhAmJ9ezNrOPT5FjomY5dSUywwdYf/b6FVzZqzB/gxgEGNjDP9Iz3BHxl5q2x+Pb qrexb19fjh3ykAZF4+ajTiWj5zi0rkEeQg7FI= Received: by 10.224.106.80 with SMTP id w16mr2813159qao.362.1264259478320; Sat, 23 Jan 2010 07:11:18 -0800 (PST) Received: from centel.dataix.local (ppp-21.26.dialinfree.com [209.172.21.26]) by mx.google.com with ESMTPS id 8sm11346601qwj.23.2010.01.23.07.11.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 23 Jan 2010 07:11:17 -0800 (PST) Sender: "J. Hellenthal" Date: Sat, 23 Jan 2010 10:10:54 -0500 From: jhell To: Alexander Leidinger In-Reply-To: <20100123102513.00001f67@unknown> Message-ID: References: <7f14551c1001190119x46c6b04dx2362cd1252f0d81@mail.gmail.com> <7f14551c1001190216w49814186n1ada2b721380502b@mail.gmail.com> <4B55C5A6.2020109@DataIX.net> <20100120111433.25801pnmhrxnirok@webmail.leidinger.net> <20100123102513.00001f67@unknown> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Hackers , Artem Belevich Subject: Re: Setting "zfs_arc_max" value in FreeBSD 8. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 15:11:19 -0000 On Sat, 23 Jan 2010 04:25, Alexander@ wrote: > On Fri, 22 Jan 2010 21:39:48 -0500 jhell wrote: > >> >> On Fri, 22 Jan 2010 11:47, fbsdlist@ wrote: >>>>> Anyone know if it is adjustable on a system with 1024MB of ram ? >>>>> Is this just being auto calculated by some other value ? >>> >>> You may want to make sure that vm.kmem_size is set to a value much >>> larger than vfs.zfs.arc_max. Default value may be too small to allow >>> such a large ARC. >>> >>> On a side note, I'm not sure that ZFS is a good match for system >>> with only 1G of RAM. By trial and error on my box with 8G or memory >>> I've figured out that I need to set arc_max ~1G below physical >>> memory size to avoid lockups under load. YMMV. >>> >> >> ZFS on this box with 1G has been quite enjoyable actually. With the >> settings I have posted I have not had any lockup on stable/7 and no >> sudden freezes or waits for transfers. So this entirely thus far has >> been a godsend. I had even put this thing through some of the >> tortures that others have posted to the list and not come up with the >> same results but better. There is obviously a lot of variables in >> this between hardware and configurations used so the results are >> minimal in comparison. With ZFS in place on this machine it performs >> a little bit under specs for the hardware but I wouldn't expect >> anything less for such a file-system. > > You may want to switch to fletcher4 checksums. This is the default in > Solaris and 8.0 now. I didn't merge this change to 7-stable as I didn't > took the time to analyze if the change for the default has some unwanted > implications for existig pools. > I will do this and report back with any differences that I find. As for your previous email that arrived I believe after this one, Thank you for your replies I appreciate the feedback. > I have a 9-current box with 1GB RAM and ZFS which shows the slow-down > after some hours of running (and doing things) too. It would be good to > make a list of OS versions and if there are slowdowns or not (anyone > with time out there to have a look at the mails and get this info out > of the mails / people?). Maybe it is related to changes not in ZFS... > > Bye, > Alexander. > Is there any recommendations from anyone ? so there is a basis for what can be tested from. (unixbench|iozone|others) in comparison to the same results version to version ? Thanks -- jhell From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 23 16:19:48 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E9A01065670 for ; Sat, 23 Jan 2010 16:19:48 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-qy0-f174.google.com (mail-qy0-f174.google.com [209.85.221.174]) by mx1.freebsd.org (Postfix) with ESMTP id EB8BC8FC12 for ; Sat, 23 Jan 2010 16:19:47 +0000 (UTC) Received: by qyk4 with SMTP id 4so1198155qyk.7 for ; Sat, 23 Jan 2010 08:19:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type:content-transfer-encoding; bh=wxuEPhxRsiFSQgUycmLs6sgRxd3VgwAFSD/yNdusxmo=; b=A52tJp/g2KVxnlSel6tNUbDxulBi6F83oiAbwHAsXPRseakl6a2Ji//gNSYvBWogeQ +b6NF/ukq5LF+4yxGaUleRlgGxSVGIcRISJIdouMcXMk/GC4p3tO8SiIS3OGzKzPW7Uy umq3fTH3i+BBTYfaUhKONdjkkAjXIGBWjF8l4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type:content-transfer-encoding; b=xkh8yGvb4nlS4E6C/ql+nnbjDetZyCAulMY6X5Wpi2JPI7GrdtJ89ciHKgyMKvtD3I v3QweXJ6hfsn+5mfiZHknO3zmct7Iab9nzJ7BPv6F3INwx/cNlPT1NenKXpZQ60XWtKM EeONa/RiCuDAUUG6Tn3U1Fkse2YEYNzarN+2k= Received: by 10.224.85.5 with SMTP id m5mr1329924qal.97.1264263587032; Sat, 23 Jan 2010 08:19:47 -0800 (PST) Received: from centel.dataix.local (ppp-21.34.dialinfree.com [209.172.21.34]) by mx.google.com with ESMTPS id 6sm7617637qwk.21.2010.01.23.08.19.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 23 Jan 2010 08:19:45 -0800 (PST) Sender: "J. Hellenthal" Date: Sat, 23 Jan 2010 11:19:33 -0500 From: jhell To: Artem Belevich In-Reply-To: Message-ID: References: <7f14551c1001190119x46c6b04dx2362cd1252f0d81@mail.gmail.com> <7f14551c1001190216w49814186n1ada2b721380502b@mail.gmail.com> <4B55C5A6.2020109@DataIX.net> <20100120111433.25801pnmhrxnirok@webmail.leidinger.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Cc: Alexander Leidinger , FreeBSD Hackers Subject: Re: Setting "zfs_arc_max" value in FreeBSD 8. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 16:19:48 -0000 On Sat, 23 Jan 2010 00:19, fbsdlist@ wrote: > Good to hear that it's usable for you even on a relatively low-memory > system. Now, throw in an SSD for L2ARC, more RAM for ARC (and L2ARC > housekeeping) and then it starts to really shine. > Can not wait until I can get something like this spinning!. I'm looking at around 6 months before this type of configuration will come into effect and be viable. I'm excited!. > As for better than expected performance, in my not-so scientific > benchmarks (copying 10G-large files on 8-disk RAIDZ2 pool until > filesystem is full) ZFS on FreeBSD did beat the hell out of > OpenSolaris on the same hardware. I was really surprised. I'm sure > something needed to be tuned on OpenSolaris, but it was nice to see > FreeBSD performing so well. > > --Artem > These guys really are doing one hell (maybe 2 or 3 ;]) of a job. Couldn't ask for better people to work on this. > > > On Fri, Jan 22, 2010 at 6:39 PM, jhell wrote: >> >> On Fri, 22 Jan 2010 11:47, fbsdlist@ wrote: >>>>> >>>>> Anyone know if it is adjustable on a system with 1024MB of ram ? Is this >>>>> just being auto calculated by some other value ? >>> >>> You may want to make sure that vm.kmem_size is set to a value much >>> larger than vfs.zfs.arc_max. Default value may be too small to allow >>> such a large ARC. >>> >>> On a side note, I'm not sure that ZFS is a good match for system with >>> only 1G of RAM. By trial and error on my box with 8G or memory I've >>> figured out that I need to set arc_max ~1G below physical memory size >>> to avoid lockups under load. YMMV. >>> >> >> ZFS on this box with 1G has been quite enjoyable actually. With the settings >> I have posted I have not had any lockup on stable/7 and no sudden freezes or >> waits for transfers. So this entirely thus far has been a godsend. I had >> even put this thing through some of the tortures that others have posted to >> the list and not come up with the same results but better. There is >> obviously a lot of variables in this between hardware and configurations >> used so the results are minimal in comparison. With ZFS in place on this >> machine it performs a little bit under specs for the hardware but I wouldn't >> expect anything less for such a file-system. >> >> -- >> >>  Thoughts & Prayers out to Haiti. >> >>  jhell >> >> > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- jhell From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 23 18:02:08 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6AD8106566B for ; Sat, 23 Jan 2010 18:02:08 +0000 (UTC) (envelope-from g.veniamin@googlemail.com) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by mx1.freebsd.org (Postfix) with ESMTP id 2AE308FC16 for ; Sat, 23 Jan 2010 18:02:07 +0000 (UTC) Received: by ewy3 with SMTP id 3so911246ewy.13 for ; Sat, 23 Jan 2010 10:02:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:mime-version:content-type:content-transfer-encoding :message-id; bh=2xYJ6Q+ti2A07Qq4BUxSez0ru2Phkzh90E4rsScuCr4=; b=U7B53YhS+Zetcc7tbuyqOo31Az+tb3+6RfRoJypXtE8kAux79l19XFjVpciaR6O1F+ Ng5aHBoytG/yb5stwXZocTfbpOVYxsTyrGir8bUjn5o/N8W0nh6w0xjbrwIgOHtVa4cZ cKotHenurnj7rioOFYJk8o9Sj56WPRPQqf8ic= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:message-id; b=dRCts/FGKKDBBU1MV2G22U3558dBErIQ7f5ussV5JPSjFGlxkVsI8CP/Xr7biYzZfn 68+x5IiFe2PbzLlT2bTR2RgHzWU2cPsuEnlev8bvTnj3O15XjMSAkjcAxjzNTxUZBDkY +lVFGnZTZwg5WgaqFRqcWpHacblm5IwXt5ZIw= Received: by 10.213.2.81 with SMTP id 17mr1403064ebi.83.1264269726989; Sat, 23 Jan 2010 10:02:06 -0800 (PST) Received: from zlobook.local (zloidemon.kraslan.ru [94.78.205.21]) by mx.google.com with ESMTPS id 14sm2917896ewy.3.2010.01.23.10.02.04 (version=SSLv3 cipher=RC4-MD5); Sat, 23 Jan 2010 10:02:05 -0800 (PST) From: zloidemon To: freebsd-hackers@freebsd.org Date: Sun, 24 Jan 2010 01:01:53 +0700 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.4; i386; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201001240101.54360.g.veniamin@googlemail.com> Subject: ethernet SiS(190/191) problem driver X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 18:02:08 -0000 Hi all! zlobook# uname -a FreeBSD zlobook.local 8.0-STABLE FreeBSD 8.0-STABLE #22: Sun Jan 3 12:17:19 KRAT 2010 root@zlobook.local:/usr/obj/usr/src/sys/zlobook i386 none0@pci0:0:4:0: class=0x020000 card=0x08021558 chip=0x01911039 rev=0x02 hdr=0x00 vendor = 'Silicon Integrated Systems (SiS)' device = 'SIS190 (SIS190)' class = network subclass = ethernet this is chip=0x01911039 real SiS191 ethernet card i downloaded this is driver for sis 190 from http://pohoyda.gmxhome.de/sis190- freebsd-7.tar.gz a problem when compiling.... zlobook# make Warning: Object directory not changed from original /root/123/sis190-FreeBSD-7 @ -> /usr/src/sys machine -> /usr/src/sys/i386/include awk -f @/tools/makeobjops.awk @/kern/device_if.m -h awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h awk -f @/tools/makeobjops.awk @/dev/mii/miibus_if.m -h cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc - I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 -- param large-function-growth=1000 -fno-common -mno-align-long-strings - mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall - Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes - Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat- extensions -c if_sis19x.c cc1: warnings being treated as errors if_sis19x.c:148: warning: pointer type mismatch in conditional expression *** Error code 1 Stop in /root/sis190-FreeBSD-7. I made a patch for the driver. Now support SiS 191 and SiS 190. Tested only SiS 191 --- if_sis19x.c.orig 2008-04-23 11:53:14.000000000 +0800 +++ if_sis19x.c 2010-01-24 00:06:43.000000000 +0700 @@ -92,13 +92,14 @@ MODULE_DEPEND(sis, miibus, 1, 1, 1); */ static struct sis_type sis19x_devs[] = { { SIS_VENDORID, SIS_DEVICEID_190, "SiS 190 10/100BaseTX" }, + { SIS_VENDORID, SIS_DEVICEID_191, "SiS 190 10/100BaseTX" }, { 0, 0, NULL } }; static int sis_probe (device_t); static int sis_attach (device_t); static int sis_detach (device_t); -static void sis_shutdown (device_t); +static int sis_shutdown (device_t); static int sis_miibus_readreg (device_t, int, int); static int sis_miibus_writereg (device_t, int, int, int); @@ -621,12 +622,14 @@ sis_attach(dev) MTX_DEF | MTX_RECURSE); callout_init_mtx(&sc->sis_stat_ch, &sc->sis_mtx, 0); - if (pci_get_device(dev) != SIS_DEVICEID_190) { - error = ENXIO; + if (pci_get_device(dev) == SIS_DEVICEID_190) + sc->sis_type = SIS_TYPE_190; + else if (pci_get_device(dev) == SIS_DEVICEID_191) + sc->sis_type = SIS_TYPE_190; + else { + error =ENXIO; goto fail; } - - sc->sis_type = SIS_TYPE_190; sc->sis_rev = pci_read_config(dev, PCIR_REVID, 1); /* @@ -885,8 +888,9 @@ sis_detach(dev) /* * Stop all chip I/O so that the kernel's probe routines don't * get confused by errant DMAs when rebooting. - */ -static void +*/ + +static int sis_shutdown(dev) device_t dev; { @@ -898,6 +902,7 @@ sis_shutdown(dev) sis_reset(sc); sis_stop(sc); SIS_UNLOCK(sc); + return (0); } this is log from messages when i using this is driver. pci0: driver added found-> vendor=0x1039, dev=0x0191, revid=0x02 domain=0, bus=0, slot=4, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=19 powerspec 2 supports D0 D1 D2 D3 current D0 pci0:0:4:0: reprobing on driver added sis19x0: port 0x1000-0x107f mem 0xd3307000-0xd330707f irq 19 at device 4.0 on pci0 miibus0: on sis19x0 rlphy0: PHY 1 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis19x0: bpf attached sis19x0: Ethernet address: 00:90:f5:95:05:e9 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 1 vector 53 sis19x0: [MPSAFE] sis19x0: [ITHREAD] pci1: driver added pci3: driver added found-> vendor=0x197b, dev=0x2382, revid=0x20 domain=0, bus=3, slot=0, func=0 class=08-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=4 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=16 powerspec 3 supports D0 D3 current D0 MSI supports 1 message pci0:3:0:0: reprobing on driver added found-> vendor=0x197b, dev=0x2383, revid=0x20 domain=0, bus=3, slot=0, func=3 class=08-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=4 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=16 powerspec 3 supports D0 D3 current D0 MSI supports 1 message pci0:3:0:3: reprobing on driver added pci9: driver added The device successfully identified sis19x0@pci0:0:4:0: class=0x020000 card=0x08021558 chip=0x01911039 rev=0x02 hdr=0x00 vendor = 'Silicon Integrated Systems (SiS)' device = 'SIS190 (SIS190)' class = network subclass = ethernet i see a problem every 10-30 seconds sis19x0: error_bits=0x40020001 sis19x0: watchdog timeout sis19x0: watchdog timeout sis19x0: watchdog timeout sis19x0: watchdog timeout sis19x0: watchdog timeout sis19x0: watchdog timeout sis19x0: error_bits=0x40020001 sis19x0: watchdog timeout 64 bytes from 192.168.3.100: icmp_seq=52 ttl=128 time=0.256 ms 64 bytes from 192.168.3.100: icmp_seq=53 ttl=128 time=0.272 ms 64 bytes from 192.168.3.100: icmp_seq=54 ttl=128 time=0.294 ms 64 bytes from 192.168.3.100: icmp_seq=55 ttl=128 time=4148.943 ms 64 bytes from 192.168.3.100: icmp_seq=56 ttl=128 time=3150.245 ms 64 bytes from 192.168.3.100: icmp_seq=57 ttl=128 time=2148.678 ms 64 bytes from 192.168.3.100: icmp_seq=58 ttl=128 time=1148.346 ms 64 bytes from 192.168.3.100: icmp_seq=59 ttl=128 time=147.464 ms 64 bytes from 192.168.3.100: icmp_seq=60 ttl=128 time=0.111 ms somehow fix this possible?