From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 23 02:49:49 2008 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 02472106566B for ; Sun, 23 Mar 2008 02:49:49 +0000 (UTC) (envelope-from daniel@dgnetwork.com.br) Received: from mail.mastercabo.com.br (mail.mastercabo.com.br [200.179.179.14]) by mx1.freebsd.org (Postfix) with SMTP id 2B30D8FC1B for ; Sun, 23 Mar 2008 02:49:47 +0000 (UTC) (envelope-from daniel@dgnetwork.com.br) Received: (qmail 88037 invoked by uid 1008); 23 Mar 2008 02:23:07 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.6-unknown (2006-10-03) on srvmail3 X-Spam-Level: X-Spam-Status: No, score=-1.8 required=4.7 tests=AWL,BAYES_00 autolearn=ham version=3.1.6-unknown Received: from unknown (HELO ?10.0.1.10?) (daniel@dgnetwork.com.br@200.243.216.68) by mail.mastercabo.com.br with SMTP; 23 Mar 2008 02:23:03 -0000 Message-ID: <47E5BD04.5050806@dgnetwork.com.br> Date: Sat, 22 Mar 2008 23:14:28 -0300 From: =?ISO-8859-1?Q?Daniel_Dias_Gon=E7alves?= Organization: DGNET Network Solutions User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org, freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: FreeBSD OS Detection and Uptime X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: daniel@dgnetwork.com.br List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2008 02:49:49 -0000 Which methods used to prevent OS detection and uptime (nmap) ? http://nmap.org/misc/defeat-nmap-osdetect.html#BSD I tried, but not work. From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 23 11:32:31 2008 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 903DB106566C for ; Sun, 23 Mar 2008 11:32:31 +0000 (UTC) (envelope-from pprokharau@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by mx1.freebsd.org (Postfix) with ESMTP id 1946A8FC16 for ; Sun, 23 Mar 2008 11:32:30 +0000 (UTC) (envelope-from pprokharau@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so2050180fgg.35 for ; Sun, 23 Mar 2008 04:32:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; bh=c13NcPGbToBCSWey2mqfeBVekrhUeVbqgPQ4RSWn2YE=; b=O0zrWsVXPoATpAX44Dcqe8aloMzI9Fcntj0BDv3isuENRdKYeJwAMITQmCrZL9UYAVQH1XnzUByqNWQsCZA0kaMJh/m25f+mChTWdKLOle09JZ1rWhBr8WrBUxaHr+LnC/qh4E9EwuR1JWwnw9885hoZAqN5WSQEFIS4kpUaza8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=YmZPtSf8ZahPO0p3i2fX1i6XuqZRbTmckyPLI7aCkJyWxRFPf5cYPecfl9kgG6h735teQbzRCS2EVFz3A+1vo+dcBdOEG8XTBQjSredPRQfqH/ATzSd9w3oQCE+8kuLFQ31JOemRH2K5zDZ026sBkoD/d3N/Wf+KFzw9DAyvXKo= Received: by 10.86.62.3 with SMTP id k3mr3545172fga.8.1206270428280; Sun, 23 Mar 2008 04:07:08 -0700 (PDT) Received: by 10.86.93.12 with HTTP; Sun, 23 Mar 2008 04:07:08 -0700 (PDT) Message-ID: <187fbcb00803230407q549fb9b8va6616d590763f76c@mail.gmail.com> Date: Sun, 23 Mar 2008 13:07:08 +0200 From: "Pavel Prokharau" To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mailman-Approved-At: Sun, 23 Mar 2008 11:36:03 +0000 Cc: Yar Tikhiy Subject: cron(8) related summer of code project 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, 23 Mar 2008 11:32:31 -0000 I was thinking about updating our cron(8) implementation. This project is mentioned in ideas list http://www.freebsd.org/projects/ideas/#p-cron-and-atrun. For now my proposal is following: * update the code base to ISC (OpenBSD already has it for a while) * incorporate changes other BSDs has. First of all it's trivial security fixes OpenBSD has (like strcpy -> strlcpy) * atrun(8) improvements as mentioned on ideas page * add privilege separation to cron(8). Its code base is really old and likely to have security bugs. I'd like this work to be done a summer of code project. But I'm not sure if amount of work proposed sufficient for summer of code. If you have some ideas about further improvements to cron(8) I'd be glad hear them and work on it. Pavel From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 23 11:42:33 2008 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 235241065675; Sun, 23 Mar 2008 11:42:33 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0F5FC8FC17; Sun, 23 Mar 2008 11:42:31 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47E6422B.5060308@FreeBSD.org> Date: Sun, 23 Mar 2008 12:42:35 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Pavel Prokharau References: <187fbcb00803230407q549fb9b8va6616d590763f76c@mail.gmail.com> In-Reply-To: <187fbcb00803230407q549fb9b8va6616d590763f76c@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Yar Tikhiy Subject: Re: cron(8) related summer of code project 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, 23 Mar 2008 11:42:33 -0000 Pavel Prokharau wrote: > I was thinking about updating our cron(8) implementation. This project is > mentioned in ideas list > http://www.freebsd.org/projects/ideas/#p-cron-and-atrun. > > For now my proposal is following: > > * update the code base to ISC (OpenBSD already has it for a while) > > * incorporate changes other BSDs has. First of all it's trivial security > fixes OpenBSD has (like strcpy -> strlcpy) > > * atrun(8) improvements as mentioned on ideas page > > * add privilege separation to cron(8). Its code base is really old and > likely to have security bugs. > > I'd like this work to be done a summer of code project. But I'm not sure > if amount of work proposed sufficient for summer of code. > > If you have some ideas about further improvements to cron(8) I'd be glad > hear them and work on it. I think these are good ideas but as you say it doesn't sound like 3 months worth of work. If you would like to submit a proposal relating to this project I think you will need to propose additional tasks to meet the length expectation. Kris From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 23 15:00:54 2008 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 F2DB9106566B for ; Sun, 23 Mar 2008 15:00:54 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.186]) by mx1.freebsd.org (Postfix) with ESMTP id 73FDF8FC24 for ; Sun, 23 Mar 2008 15:00:54 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by fk-out-0910.google.com with SMTP id b27so3263924fka.11 for ; Sun, 23 Mar 2008 08:00:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:date:from:to:cc:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent:sender; bh=I+OesYSpS/2dwZG3sqL/h1cRTXnHriWfgSh17IaNBBc=; b=boXzepw48uSrnIRdlhT7Uj3iFMLx28KF73b0sRBlknTLDy5RphAXg5hO1WaGYDoEvak1quc4BNYRjMFcCNFZpc6WysnXVbXJvxwdnbuLLhbHLLpYzgvCIa3uZmbZFKI+8syLmE08t/VvWr/f5k/tgQYEumcLdBvjVwniO2r9p54= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=date:from:to:cc:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent:sender; b=oT8Zj5u9H/AkM59OiYtho40GoaYxQMa/TfPqnrvTIhcdXlYQTOppaswEiL/qv1hykt39VBJXpcGono+a9H6kYfzkcZhbwX/0zWnFDFJaregFpdGqShfeD/oAgQa2t2TCzcSoQWkPdtA5VXbAQ344Z34mwXrko58gTRppUR4D5SA= Received: by 10.78.107.8 with SMTP id f8mr17088864huc.23.1206284452036; Sun, 23 Mar 2008 08:00:52 -0700 (PDT) Received: from fnop.net ( [83.144.141.62]) by mx.google.com with ESMTPS id c22sm11255606ika.3.2008.03.23.08.00.50 (version=SSLv3 cipher=OTHER); Sun, 23 Mar 2008 08:00:51 -0700 (PDT) Date: Sun, 23 Mar 2008 15:00:38 +0000 From: Rui Paulo To: =?us-ascii?B?PT9JU08tODg1OS0xP1E/RGFuaWVsX0RpYXNfR29uPUU3YWx2ZXNf?= , ?=@fnop.net Message-ID: <20080323150038.GA17070@fnop.net> References: <47E5BD04.5050806@dgnetwork.com.br> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47E5BD04.5050806@dgnetwork.com.br> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: Rui Paulo Cc: freebsd-hackers@freebsd.org, freebsd-pf@freebsd.org, freebsd-net@freebsd.org Subject: Re: FreeBSD OS Detection and Uptime 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, 23 Mar 2008 15:00:55 -0000 On Sat, Mar 22, 2008 at 11:14:28PM -0300, =?ISO-8859-1?Q?Daniel_Dias_Gon=E7alves_ wrote: > Which methods used to prevent OS detection and uptime (nmap) ? > http://nmap.org/misc/defeat-nmap-osdetect.html#BSD > I tried, but not work. The TCP Drop SYN+FIN sysctl might help. % sysctl -d net.inet.tcp.drop_synfin net.inet.tcp.drop_synfin: Drop TCP packets with SYN+FIN set Regards. -- Rui Paulo From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 23 18:55:18 2008 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 058CE106566C for ; Sun, 23 Mar 2008 18:55:18 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 681708FC15 for ; Sun, 23 Mar 2008 18:55:17 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1JdVLS-0004xh-8l for freebsd-hackers@freebsd.org; Sun, 23 Mar 2008 18:55:02 +0000 Received: from 195.208.174.178 ([195.208.174.178]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 23 Mar 2008 18:55:02 +0000 Received: from vadim_nuclight by 195.208.174.178 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 23 Mar 2008 18:55:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Vadim Goncharov Followup-To: gmane.os.freebsd.devel.ipfw Date: Sun, 23 Mar 2008 18:51:43 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 358 Message-ID: X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 195.208.174.178 X-Comment-To: All User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news Cc: freebsd-ipfw@freebsd.org Subject: [HEADS UP!] IPFW Ideas: possible SoC 2008 candidate X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2008 18:55:18 -0000 Hi! [Sorry if it is too late for SoC, but I was unexpectedly busy last 3 days and couldn't finish this text earlier.] This is a proposal for ipfw improving ideas and architectural changes. Some of them are independent of each other and could be implemented without ABI breaking in STABLE, but, whether all of these will be a SoC 2008 candidate or not, should be finally implemented in FreeBSD. The only question is what should be corrected, so please discuss it :) This text also includes slightly changed and/or generalized ideas from: http://lists.freebsd.org/pipermail/freebsd-ipfw/2007-April/002931.html All syntax examples are only to give idea, this should be discussed. 1. Major changings (ABI breaking is necesary). 1.1. Dynamic rules reorganizing. Description: Current ipfw's dynamic rules are not suitable for several advanced tricks. For example, it is not possible to use saved information about current state of connection in the firewall rules elsewhere, and it is not possible to change that state from firewall also. Wanted features: * Ability to create/delete dynamic rule in any state via some API or ABI from all parts of system: userland, ipfw rules, other kernel modules. This can be useful for: a) Creating dynamic rule in the middle of connection, not only setup: ipfw add pipe 1 ip from any to any tagged 412 keep-state-middle This allows to change handling of connection after some event, e.g. L7 filtering by ng_bpf + ng_tag discovered that a connection belongs to some class by analyzing packet payload, and from now on connection should go directly with dynamic rules, but never sent again to expensive L7 processing. Currently you can use just "keep-state" for this, but ipfw will not see SYN's and rule will be subject to sysctl net.inet.ip.fw.dyn_rst_lifetime - by default expires after 1 second, which is undesirable for many cases. b) Ability to save/load dynamic rules in userland with files, e.g., to continue after reboot. c) Ability to exchange with rules state with other machine with ipfw, e.g., two firewalls in a CARP failover. d) Creation of rule with specified state and parameter before actual connection would be established. E.g. imagine a by-default-closed firewall with a netgraph(4) module analyzing FTP control connection and giving commands to ipfw to open dynamic "holes" for data connections, thus elimanating current practice of opening ports in the entire range 1024-65535 (insecure, yes). One can think about providing direct exchange between libalias(3)'s alias_link and ipfw dynamic rules, but that's a subject for further research. * Additional fields in dynamic rules to keep arbitrary info for specific connection, and opcodes for loading and storing that values from other parts of firewall or elsewhere. This will allow to implement a pf(4)'s "scrub" maximum TTL enforcing on connection, but not only that - generic data storage allows any future extensions. * Ability to change dynamic rule's parent rule "on the fly" (just changing a pointer to which static rule's ACTION_PTR to jump, yes). The latter will allow aforementioned distinguishing of connection packets before/after L7 processing in the case where packets are always classified to flows before any processing takes place - that example with "keep-state-middle" assumed that main firewall is stateless, only L7-matched packets are subject to be dynamic. And this allows to reassign an action for dynamic rule: ... ipfw add 100 check-state ... ipfw add 200 skipto 500 ip from any to any keep-state ... ipfw add 500 netgraph 41 ip from any to any ipfw add 600 change-parent 800 ip from any to any tagged 412 ipfw add 700 allow ip from any to any ipfw add 800 pipe 1 ip from any to any * More types for dynamic rules system would allow not only "keep-state" and "limit", but rather be extensible to something more. E.g., current "limit" rules just drop packets if limit is reached - but user possibly wants an option to process them with another rule afterwards. Possible implementation: * For arbitrary info: add a union of one uint32_t or two uint16_t's or four uint8_t's two each dynamic rules and operations to load/store those values (or may be an uint64_t and two uin32_t's and so on?..). Also add one void* to allow to store more data if one needs to. * Make a special netgraph node (or extend ng_ipfw) which will broadcast every change in dynamic rules to all it's hooks (how many to bundle into one mbuf should be customizable). Every input with structs of the same format will result in addition or deletion of dynamic rules in ipfw. A netgraph node method of work provides flexible and extensible way to manipulate dynamic rules: you can connect to it protocol-trackers which will insert rules for secondary connection (e.g. FTP); you can connect to it userland tool which will log all dynamic rule changing or will do load/save of rules in a file; you can connect to it an ng_ksocket(4) node with UDP to broadcast to someone or TCP to connect to another machine with the same setup to provide CARP failover. Note that node should not do delivery/retransmission checks as pfsync(4) does, because this is a task for someone other (to keep modularity), but two such nodes on different machines connected to each other should provide automatic rules synchronizing without additional actions after initial setup. 1.2. Userland (and other subsystems) interaction, modularity, rulesets. Description: Currently /sbin/ipfw2 is a custom-made parser which communicates with the kernel via setsockopt() calls. It is sometimes hard to extend with new features due to complex code. Using a socket instead a /dev entry means you always need to be root (uid 0) to both read firewall configuration and to change it. In-kernel protocol is also sometimes hard to extend, while some addional entire-ruleset features are useful. Wanted features: * Parser's code (sbin/ipfw2.c) should be reviewed and possibly rewritten using lex(1)/yacc(1). Syntax is ocmplicated, however, and it may be not possible to not implement all of it exactly. This should be further investigated. * It may be desirable to give some other user ability to at least read config and may be to write, as /dev/bpf* permissions allow it for tcpdump(1). * Device entry could also improve modularity: currently to add a new IP_FW_* socket option, you have to modify netinet/raw_ip.c, which means you can't just recompile /sbin/ipfw and ipfw kernel module. * The same applies to other ipfw-related facilities: dummynet, divert, NAT. It can be good to keep them configurable by some other means rather than tweaking raw_ip.c. It can be useful to separate dummynet and divert to it's own facilities to be able to use them without ipfw, e.g., from netgraph(4). Related to this is a problem with IPSEC interaction - if you use it with divert(4) on output, then on return from divert packets will be IPSEC'ed again because in ip_output() IPSEC is called before pfil(9). It could be useful to add an option for user (in addition to existing behaviour, to not break POLA) to call IPSEC processing from specified place in ruleset just like all others: ipfw add ipsec ip from any to any out * As patch about using rule counters is currently discussed in ipfw@, it is useful to add ability to change rule counters to arbitrary values rather than providing the only "zero" action. This is closely related with an option of restore ipfw's static ruleset without losing counter values. Currently you can save "ipfw list" to file, do an "awk '{print "add " $0}'" on it and then load it again (e.g. after reboot). It must be possible to do the same with "ipfw show". Syntax example for providing counters with "ipfw add" - all cases are distinguishable (current syntax allow only first two): ipfw add allow ip from any to any # select next rule number ipfw add 100 allow ip from any to any # exact rule number specified ipfw add 1234 76845 allow ip from any to any # counters without rulenum ipfw add 100 1234 76845 allow ip from any to any # rulenum and counters * Static ruleset loading and saving is closely related with ruleset precompilation and atomic commits. Imagine a rulesets with thousands of rules: if a packet arrives in the middle of ruleset updating, strange effects can occur. Of course, you can achieve the same results with sets, by disabling new set and atomically swapping them later, but that is not always comfortable. Precomplilation of the whole ruleset and then atomically installing it ("transaction commit") requires an implementation which will also allow saving and loading precompiled ruleset in binary form - good for routers where 20K-rules script can be processed for several minutes. * Precompiled binary rules can also be used for the same rule setting from both other kernel subsytems and other machines (CARP again). Thus, generic binary rule format/protocol (not only for /dev) might be invented. Moreover, compiled ruleset format may be different from current linked list, which has disadvantages of both initial "skipto" (and planned "call/return", see next section) and disabled-set-rules are still traversed. Precompiled form of opcodes-only allows to do quick jumps, easy running of cross-rule optimizations (and even possibility to compile ipfw opcodes to machine code like BPF_JITTER for bpf(4) for more speed). This has disadvantages of separate rule counters keeping and not-so-transparent need for user to recompile every time, so should be further investigated. * About several rulesets, for different interfaces (or hacks like per-interface setting of rule number to jump to on it): I think that this is unnecessary and unfriendly to user - having one rulesets is simpler, and you usually need common checks on packets. So "commit" precompiled rules, "call/return" actions (see next section) and stack virtualization via "vimage" should serve all practical purposes. Possible implementation: General view is clear from features description. One also can think about netgraph(4) node for this (again) and/or something like shared memory pages between kernel and userland, to not allocate memory in kernel twice for big rulesets. 2. Independent (minor) changes, which can be possible without ABI breakage. 2.1. call/return rule actions. Description of feature: A "skipto" rule is known as a useful tool to optimize packet flow through ruleset, also able to assign several actions to a dynamic rule (because dynamic rule on match simply jumps to action part of parent rule). But it can only jump forward, not backwards, for the same reason as bpf(4) assember instruction: to prevent infinite loops in packet flow which will cause machine to hang network operations. This can be addressed by introducing a pair of instructions, call and return, which remembers position to return in the stack of some kind. Because return is always done to the next rule after calling one (by number, as with divert/skipto), it is guaranteed that infinite loops can't occur, even in case of calling one rule many times by simply proceeding to next rule after stcak overflow. Thus call/return pair allows to organize some kind of subroutines, with the trick that issuing actual number lets to jump to the middle of subroutine, as in assembly language: ipfw add 100 call 600 ip from any to any in recv $internal ipfw add 100 call 700 ip from any to any in recv $external ... ipfw add 500 allow ip from any to any ipfw add 600 deny ip from any to any not antispoof ipfw add 700 deny tcp from any to any 135,445 ipfw add 900 return // for both those calls It should be noted again that calls are made by rule numbers, so in the following example the first "call 700" will pass control to rule 301, not second rule 300. ipfw add 300 call 700 ... ipfw add 300 call 800 ... ipfw add 301 count ip ... Allowing to use "tablearg" in "call" would be very useful. Parser should allow both version of "return", with some conditions (ususal rule body) and without them (like "check-state"). Possible implementation: Relatively easy. Allocate a mbuf tag for a stack of uint16_t rule numbers and a stack top pointer on first "call" for mbuf. The only thing to care are divert etc. calls, and distinguishing input and output passes (firewall can be called several times for each), thus stack underflow and overflow should be carefully analyzed. May be two tag types, one for input and one for output. It is difficult, however, to get this performing well, because of linked-list nature of ruleset and inability to cache pointer to skip destination, as done with "skipto" currently, because there can be several locations (even tablearg). Possible solutions may be to keep a cache to, say, 256 points in the list (rulenum / 256) to reduce looking after this point (effectively equivalent to hash on rulenum). Or to have compiled rulesets where offset to jump is easily calculated (see previous section). 2.2. Tables and tableargs. Tables are very powerful way to both increase processing speed and conveniently reduce rule maintaing cost for user, especially with tableargs. Tables, however, are currently limited to IPv4 addresses/masks as keys and uint32_t's as values. Table keys should be extended to another data types: IPv6 addresses, interface name strings: ipfw add allow ip from any to table6(1) in recv stringtable(2) or ipfw call tablearg ip from any to any via stringtable(3) The latter will be very handy for routers with e.g. 2000 VLAN or ng* interfaces, with separate client and rules for each. Tableargs should also be expanded to 16 bytes, to be able to store IPv6 address ot uint64_t for checking e.g. in rule counters. It is questionable whether tableargs could also be short (< 16 bytes) strings like interfaces' names. Due to implementation difficulties of distinguishing whether action parameter is a valid value or a tablearg (you usualyy have only one invalid value out ouf 65536 which is get assigned as tablearg indicator), I suggest adding operations like "settablearg" which will set tablearg without actual table used, e.g., from saved arbitrary info from dynamic rules (see section 1.1) or even packet header. So, values for "computed goto" or something like registers still be used by tablearg (just generalizing definition of table), or, at least this should be so in opcode level - user could be present with some other keyword, but I don't see any point in hiding this details. Number of tables of all types should be configurable via sysctl or at least loader tunable rather than current hradcoded number (128). 2.3. Time limit counter. An opcode for a token bucket and/or leaky bucket should be introduced. This will have a one counter changed with timer and other changed by actual packets. We currently have O_LOG opcode looking similar to this, but O_LOG has nothing to deal with timer. Proposed opcode must be useful at least for limiting a number of connections per second, but any other possible use is appreciated, from simplest shaping without dummynet to more exotic like counter "price" coefficinets allowing to build an in-kernel billing solely on ipfw counters. It is questionable where values of counters should be stored, due to locking optimising - directly, as with O_LOG, or separately addressable space like tables. 2.4. Action rules and parameters. Change ACTION_PTR handling in kernel and preparing in compiler to allow actions and their parameters to be placed in any order (except for opcodes where order is required, e.g. prob). This would easily allow placing several opcodes of the same type to action part, e.g.: ipfw add count tag 1 tag 2 tag 3 ip from any to any and using actions and their parameters interchangeably, like having a rule without actual action opcode (only parameter instead), e.g. use "tag" or "altq" as action too (equals to "count"). 2.5. Just to mention: modip, counter limits, fragments. These patches are already currently discussed in ipfw@, but included here just to not forget. These are "modip" action, allowing to modify IP header (DSCP, ToS, TTL) and corresponding match rule options, and a rule option to match when rule counters are less then specified number packets or bytes (possibly from dynamic rule's counters), may be a tablearg. This is also related with mentioned in section 1.2 ability to control rule counters. Adding a few keywords for O_FRAG more fragment matching (not only non-first fragment), e.g. for sending to specialized netgraph(4) reassembling module, is also desirable. That's all for today. Any comments, additions, corrections are welcome! -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 23 23:54:12 2008 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 6023A106564A for ; Sun, 23 Mar 2008 23:54:12 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: from mired.org (student.mired.org [66.92.153.77]) by mx1.freebsd.org (Postfix) with ESMTP id DA7F58FC18 for ; Sun, 23 Mar 2008 23:54:11 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: (qmail 27932 invoked by uid 1001); 23 Mar 2008 19:53:16 -0400 Received: from bhuda.mired.org (192.168.195.1) by bhuda.mired.org (tmda-ofmipd) with ESMTP; Sun, 23 Mar 2008 19:53:15 -0400 Date: Sun, 23 Mar 2008 19:49:02 -0400 To: "Pavel Prokharau" Message-ID: <20080323194902.2fcc6095@bhuda.mired.org> In-Reply-To: <187fbcb00803230407q549fb9b8va6616d590763f76c@mail.gmail.com> References: <187fbcb00803230407q549fb9b8va6616d590763f76c@mail.gmail.com> Organization: Meyer Consulting X-Mailer: Claws Mail 3.3.1 (GTK+ 2.12.8; amd64-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Mike Meyer Cc: freebsd-hackers@freebsd.org, Yar Tikhiy Subject: Re: cron(8) related summer of code project 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, 23 Mar 2008 23:54:12 -0000 On Sun, 23 Mar 2008 13:07:08 +0200 "Pavel Prokharau" wrote: > I was thinking about updating our cron(8) implementation. This project is > mentioned in ideas list > http://www.freebsd.org/projects/ideas/#p-cron-and-atrun. > > For now my proposal is following: > > * update the code base to ISC (OpenBSD already has it for a while) > > * incorporate changes other BSDs has. First of all it's trivial security > fixes OpenBSD has (like strcpy -> strlcpy) > > * atrun(8) improvements as mentioned on ideas page > > * add privilege separation to cron(8). Its code base is really old and > likely to have security bugs. > > I'd like this work to be done a summer of code project. But I'm not sure > if amount of work proposed sufficient for summer of code. > > If you have some ideas about further improvements to cron(8) I'd be glad > hear them and work on it. Not cron, but cron-related. I'd like to see the periodic infrastructure made available to users. This isn't hard, but you have to be careful about security. A last script in each of the daily/weekly/monthly periodic directories that for each user (does each have to ask ala cron? Does it just look for ~/periodic? ???), then runs periodic as that user with the proper arguments. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 24 04:19:04 2008 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 54F69106567C for ; Mon, 24 Mar 2008 04:19:04 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id D9CF18FC29 for ; Mon, 24 Mar 2008 04:19:03 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Jde9D-0003Ei-Vm for freebsd-hackers@freebsd.org; Mon, 24 Mar 2008 04:19:00 +0000 Received: from 195.208.174.178 ([195.208.174.178]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Mar 2008 04:18:59 +0000 Received: from vadim_nuclight by 195.208.174.178 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Mar 2008 04:18:59 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Vadim Goncharov Date: Mon, 24 Mar 2008 04:18:45 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 33 Message-ID: References: <2a7894eb0802200020g5e4f9ff8p7d3044bbec261706@mail.gmail.com> <2a7894eb0803171515l7a0e1acld84b793aa3c9cc6c@mail.gmail.com> <20080319134323.U38501@fledge.watson.org> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 195.208.174.178 X-Comment-To: Robert Watson User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news Subject: Re: Summer of Code 2008 Project Ideas X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2008 04:19:04 -0000 Hi Robert Watson! On Wed, 19 Mar 2008 13:45:19 +0000 (GMT); Robert Watson wrote about 'Re: Summer of Code 2008 Project Ideas': >> The FreeBSD Project was again accepted as a mentoring organization for the >> Google Summer of Code. The student application period will begin next week >> so if you have any ideas for great student projects, please send them to >> soc-admins@FreeBSD.org or post them here for discussion. A good student >> project has a well defined purpose, some key FreeBSD developers that could >> be identified as potential mentors, and is feasible for a student to >> complete in a few months time. The existing ideas list is available here : >> >> http://www.freebsd.org/projects/ideas/ >> >> If you can suggest something (getting specific parts of valgrind working on >> FreeBSD?) then please provide information in the form of the other projects >> listed on the page as far as difficulty level, requirements, etc.. > FYI, to students considering doing projects -- in the last day or two, we've > made significant updates to the project ideas list. If you looked a few days > ago, please look again. In particular, we've flagged a large number of > potential SoC projects that were not there previously. We've also filtered > out some that looked too big to be a good 3-month summer project, although you > can still find many on the full ideas list. If you're going to work on a > proposal for one of these projects, please directly contact the contacts > listed for the project to get feedback before submitting your proposal. We > will continue to update the project ideas page as new ideas come in, so do > keep checking back. Is it too late to add another SoC idea? I've made a proposal post yesterday :) -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 24 05:18:06 2008 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 A9070106564A for ; Mon, 24 Mar 2008 05:18:06 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: from mired.org (student.mired.org [66.92.153.77]) by mx1.freebsd.org (Postfix) with ESMTP id 3F0778FC1A for ; Mon, 24 Mar 2008 05:18:05 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: (qmail 67919 invoked by uid 1001); 24 Mar 2008 01:17:11 -0400 Received: from bhuda.mired.org (192.168.195.1) by bhuda.mired.org (tmda-ofmipd) with ESMTP; Mon, 24 Mar 2008 01:17:09 -0400 Date: Mon, 24 Mar 2008 01:17:08 -0400 To: Message-ID: <20080324011708.107ec3cb@bhuda.mired.org> Organization: Meyer Consulting X-Mailer: Claws Mail 3.3.1 (GTK+ 2.12.8; amd64-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Mike Meyer Subject: Problem with find -prune... 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, 24 Mar 2008 05:18:06 -0000 find -prune seems to not quite do what it says. At least, when delete is used. Here's an example tree (on 7.0-RELEASE, amd64 build): bhuda# ls -Rl /tmp/x total 2 drwx------ 2 root wheel 512 Mar 24 01:01 y /tmp/x/y: total 2 -rw-r--r-- 1 root wheel 1111 Mar 24 01:01 motd /tmp/x contains a subdirectory closed to everyone but root, which has a file in it. No problem. Point find at it as a user: bhuda% find /tmp/x -print /tmp/x /tmp/x/y find: /tmp/x/y: Permission denied As expected, it complains. Now let's use prune to trim the search - at the root of the tree: bhuda% find /tmp/x -prune /tmp/x Hmm, it prints the root of the tree. That might be a bug; might not. But we can fix it with a little tweak: bhuda% find /tmp/x -prune -o -print bhuda% Making the print conditional on not pruning, and we always prune. Ok, now let's look at what looks to me like a bug: bhuda% find /tmp/x -prune -o -delete find: /tmp/x/y: Permission denied Why on earth (or off it) is find trying to look at /tmp/x? Am I correct in assuming that this is a bug? Thanks, http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 24 12:22:48 2008 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 B1D2A106566B for ; Mon, 24 Mar 2008 12:22:48 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.236]) by mx1.freebsd.org (Postfix) with ESMTP id 70D298FC2C for ; Mon, 24 Mar 2008 12:22:48 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so3290654wxd.7 for ; Mon, 24 Mar 2008 05:22:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:reply-to:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:openpgp:content-type:from; bh=Ma8J3Gz5W7f7eYu5ltN/SM1/2gKY6jUS/nVITGKmkJ0=; b=K/biZs0vIALuiIsfMlQ04H/M6y0bQN7ZwrXIziNiF+B7IyQcUqZGx7ChHZeWltR6HjgJ+ETjPvHcVTCT9WGdtxUHbtNObd+T3uBdTxFhl4J3wkN+ZwOV+eWHl6JCaxl+AfshGeotBb7X9hLxI18cbYLeqW4Qnj8VI2Le3u/YtoA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:reply-to:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:openpgp:content-type:from; b=KT2N2SY4sJX3A6kIkBp0VsDk6ZecQiLkz1mOVBy8UL5MszHrbCC0ZPPbo3eI/62MEqQB61xjIkHe/ODddYCieKOIL7hBHZY6Ael+6uUdnyGQ9IC2feJkMAgCcihkJ95Jo9kZsxmg6uzdPlnDavngvv/I6bV1y4GpahvmBFO51lw= Received: by 10.141.142.15 with SMTP id u15mr2041089rvn.238.1206359612013; Mon, 24 Mar 2008 04:53:32 -0700 (PDT) Received: from island.freebsd.org ( [201.25.194.19]) by mx.google.com with ESMTPS id l22sm10866554wrl.34.2008.03.24.04.53.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 24 Mar 2008 04:53:31 -0700 (PDT) Message-ID: <47E79636.1000909@FreeBSD.org> Date: Mon, 24 Mar 2008 08:53:26 -0300 Organization: FreeBSD User-Agent: Thunderbird 2.0.0.0 (X11/20070521) MIME-Version: 1.0 To: vadim_nuclight@mail.ru References: In-Reply-To: X-Enigmail-Version: 0.95.0 OpenPGP: id=53E4CFA8 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig68C51D89D2EA2978728F1F6B" From: Marcelo Araujo X-Mailman-Approved-At: Mon, 24 Mar 2008 12:44:16 +0000 Cc: freebsd-ipfw@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: [HEADS UP!] IPFW Ideas: possible SoC 2008 candidate X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: araujo@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2008 12:22:48 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig68C51D89D2EA2978728F1F6B Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Vadim Goncharov wrote: > > 2.5. Just to mention: modip, counter limits, fragments. > > These patches are already currently discussed in ipfw@, but included > here just to not forget. These are "modip" action, allowing to modify I= P > header (DSCP, ToS, TTL) and corresponding match rule options, and a rul= e > option to match when rule counters are less then specified number > packets or bytes (possibly from dynamic rule's counters), may be > a tablearg. This is also related with mentioned in section 1.2 ability > to control rule counters. > > Adding a few keywords for O_FRAG more fragment matching (not only > non-first fragment), e.g. for sending to specialized netgraph(4) > reassembling module, is also desirable. > > > That's all for today. Any comments, additions, corrections are welcome!= > > =20 For remember to all, I work around of modip action stilly, I stoped my work during last week, but I work again in it. Work status: 1) We have modip action implemented: island# ipfw add modip ipfw: need modip [DF|TOS|IPPRE|DSCP]:code arg 2) Both DF and IPPRE works perfect: island# ipfw show 00010 371 36133 modip ippre:immediate ip from any to any 00011 52 5035 modip df:0 ip from any to any 3) DSCP: With the DSCP I've some errors but I believe that I fix it on this week. 4) ToS: I start the work on the next week. The patch: http://people.freebsd.org/~araujo/logs/ipfw-modip20080324.diff= Best Regards, --=20 Marcelo Araujo (__) araujo@FreeBSD.org \\\'',) http://www.FreeBSD.org \/ \ ^ Power To Server. .\. /_) --------------enig68C51D89D2EA2978728F1F6B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFH55Y6ovxJd1Pkz6gRAhUqAKCVpZfYvydqItLJBJTuCF9DY+wLdACgmmFG DgswIh3yibFXEUaA68uzRq8= =4XZQ -----END PGP SIGNATURE----- --------------enig68C51D89D2EA2978728F1F6B-- From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 24 14:06:38 2008 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 1F38E1065740 for ; Mon, 24 Mar 2008 14:06:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 138A28FC12 for ; Mon, 24 Mar 2008 14:06:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by elvis.mu.org (Postfix) with ESMTP id 4AD591A4D82; Mon, 24 Mar 2008 07:06:37 -0700 (PDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 24 Mar 2008 09:38:29 -0400 User-Agent: KMail/1.9.7 References: <200803221520.m2MFK7TM059293@lurza.secnetix.de> In-Reply-To: <200803221520.m2MFK7TM059293@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803240938.29781.jhb@freebsd.org> Cc: Oliver Fromme Subject: Re: vkernel & GSoC, some questions 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, 24 Mar 2008 14:06:38 -0000 On Saturday 22 March 2008 11:20:07 am Oliver Fromme wrote: > M. Warner Losh wrote: > > In message: <200803191633.m2JGXuBt088272@lurza.secnetix.de> > > > > Oliver Fromme writes: > > : The vkernel feature has certainly benefits, e.g. the fact > > : that you can attach to it with standard gdb and use the > > : familiar debugging facilities, which can attract more > > > > Can't you say qemu -s and attach gdb to that port as well? > > Good point. According to the manpage it would work, > but I've never tried it myself. (I'm rather careful > with the qemu manpage because it also contains a few > things that only work on Linux.) It works great and is how I debugged the recent GPT and BTX boot loader stuff. I haven't tried debugging the loader binary itself, but that should work. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 24 14:06:38 2008 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 8D12D1065741 for ; Mon, 24 Mar 2008 14:06:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 846E68FC15 for ; Mon, 24 Mar 2008 14:06:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by elvis.mu.org (Postfix) with ESMTP id 2312A1A4D7E; Mon, 24 Mar 2008 07:06:38 -0700 (PDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 24 Mar 2008 09:41:08 -0400 User-Agent: KMail/1.9.7 References: <20080321200319.GA13917@plan0> In-Reply-To: <20080321200319.GA13917@plan0> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803240941.08910.jhb@freebsd.org> Cc: Kai Wang Subject: Re: features of objcopy 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, 24 Mar 2008 14:06:38 -0000 On Friday 21 March 2008 04:03:19 pm Kai Wang wrote: > Hi list, > > I'm working on a BSD Licensed objcopy/strip rewrite(in p4) based on > libelf, I really want to know the answers to a few questions listed > below, and please do not hesitate if you have other related > suggestions. Thanks in advance! > > 2. Do you often convert ELF to raw binary, iHex, S-Record or > vice versa? See src/sys/boot/i386/boot2/Makefile for an example of using objcopy for this during the build. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 24 17:53:40 2008 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 1E93E1065673 for ; Mon, 24 Mar 2008 17:53:40 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outT.internet-mail-service.net (outT.internet-mail-service.net [216.240.47.243]) by mx1.freebsd.org (Postfix) with ESMTP id DD26E8FC1F for ; Mon, 24 Mar 2008 17:53:39 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Mon, 24 Mar 2008 13:34:16 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id BB3C82D6004; Mon, 24 Mar 2008 10:53:38 -0700 (PDT) Message-ID: <47E7EAA8.7020101@elischer.org> Date: Mon, 24 Mar 2008 10:53:44 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: araujo@FreeBSD.org References: <47E79636.1000909@FreeBSD.org> In-Reply-To: <47E79636.1000909@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: vadim_nuclight@mail.ru, freebsd-ipfw@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: [HEADS UP!] IPFW Ideas: possible SoC 2008 candidate 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, 24 Mar 2008 17:53:40 -0000 here are some of my ideas for ipfw changes: 1/ redo locking so that packets do not have to get locks on the structure... I have several ideas on this 2/ allow separate firewalls to be used at different parts of the network stack (i.e allow multiple taboe sto co-exist) 3/ possibly keeping per CPU stats.. From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 24 23:23:21 2008 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 33321106566C for ; Mon, 24 Mar 2008 23:23:21 +0000 (UTC) (envelope-from xistence@0x58.com) Received: from mailexchange.osnn.net (1e.66.5646.static.theplanet.com [70.86.102.30]) by mx1.freebsd.org (Postfix) with SMTP id CEF9F8FC28 for ; Mon, 24 Mar 2008 23:23:20 +0000 (UTC) (envelope-from xistence@0x58.com) Received: (qmail 95033 invoked by uid 0); 24 Mar 2008 23:23:19 -0000 Received: from unknown (HELO wideload.network.lan) (xistence@0x58.com@68.228.228.123) by mailexchange.osnn.net with SMTP; 24 Mar 2008 23:23:19 -0000 Message-Id: From: Bert JW Regeer To: FreeBSD Hackers Content-Type: multipart/signed; boundary=Apple-Mail-1-460532599; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 24 Mar 2008 16:23:19 -0700 X-Mailer: Apple Mail (2.919.2) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: zpool scrub tank && high file system activity caused crash 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, 24 Mar 2008 23:23:21 -0000 --Apple-Mail-1-460532599 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hey guys, I am running FreeBSD 7.0-RELEASE with GENERIC on a AMD XP Athlon 3500+ with 1267 MB of ram, and a GigBit NIC. I am testing out ZFS just for the hell of it, I know, 32 bit is not suggested and runs badly, but it does what it needs to do. I was copying large amounts of data for backup purposes from my MacBook Pro to the machine over FTP. At the time I was looking around the man page for zpool, and figured I'd run a zpool scrub just to see how badly it affects performance. It affects it in that it takes down the machine with a dump. keyhole# kgdb kernel.debug /var/crash/vmcore.0 [GDB will not be able to debug user-mode threads: /usr/lib/ libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: panic: vm_page_insert: offset already allocated cpuid = 0 Uptime: 10h58m58s Physical memory: 1267 MB Dumping 335 MB: 320 304 288 272 256 240 224 208 192 176 160 144 128 112 96 80 64 48 32 16 #0 doadump () at pcpu.h:195 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc0754457 in boot (howto=260) at /usr/src/sys/kern/ kern_shutdown.c:409 #2 0xc0754719 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc097c2dc in vm_page_insert (m=0xc17df8b0, object=0xc0bed860, pindex=76780) at /usr/src/sys/vm/vm_page.c:658 #4 0xc097c71c in vm_page_alloc (object=0xc0bed860, pindex=76780, req=34) at /usr/src/sys/vm/vm_page.c:1119 #5 0xc0970ef5 in kmem_malloc (map=0xc147108c, size=131072, flags=2) at /usr/src/sys/vm/vm_kern.c:344 #6 0xc09675b7 in page_alloc (zone=0x0, bytes=131072, pflag=0xe76e5b2f "\002", wait=2) at /usr/src/sys/vm/uma_core.c:955 #7 0xc096a080 in uma_large_malloc (size=131072, wait=2) at /usr/src/ sys/vm/uma_core.c:2709 #8 0xc0745568 in malloc (size=131072, mtp=0xc57d3440, flags=2) at / usr/src/sys/kern/kern_malloc.c:364 #9 0xc5752a60 in ?? () #10 0x00020000 in ?? () #11 0xc57d3440 in ?? () #12 0x00000002 in ?? () #13 0xe76e5b80 in ?? () #14 0xc57ae8e9 in ?? () #15 0x00020000 in ?? () #16 0x00000002 in ?? () #17 0xe76e5bd4 in ?? () #18 0xc5788805 in ?? () #19 0x00020000 in ?? () #20 0xc57cdced in ?? () #21 0x000008ee in ?? () #22 0x000008e6 in ?? () #23 0x00000000 in ?? () #24 0x00000000 in ?? () #25 0xe76e5c20 in ?? () #26 0xc5772cce in ?? () #27 0xd464e600 in ?? () #28 0x000036ad in ?? () #29 0x00000000 in ?? () #30 0xc6732e24 in ?? () #31 0x00002000 in ?? () #32 0x00000014 in ?? () #33 0xc6732e44 in ?? () #34 0x00020000 in ?? () #35 0xc6732e24 in ?? () #36 0xc4589400 in ?? () #37 0xc6732e34 in ?? () #38 0xe76e5c04 in ?? () #39 0xc5788b01 in ?? () #40 0x00002000 in ?? () #41 0xc6732e24 in ?? () #42 0x00000922 in ?? () #43 0x00000920 in ?? () #44 0x00000003 in ?? () #45 0x00000000 in ?? () #46 0x00000001 in ?? () #47 0xc6730000 in ?? () #48 0xc77aca80 in ?? () #49 0xc77aca80 in ?? () #50 0xe76e5c20 in ?? () #51 0xc5772193 in ?? () #52 0xc6732e24 in ?? () #53 0xc561b800 in ?? () #54 0x00000000 in ?? () #55 0xc6732e24 in ?? () #56 0x00000000 in ?? () #57 0xe76e5c84 in ?? () #58 0xc577326a in ?? () #59 0x00000002 in ?? () #60 0xe76e5c6c in ?? () #61 0xe76e5c74 in ?? () #62 0x00000003 in ?? () #63 0x00000000 in ?? () #64 0xffffffff in ?? () #65 0x00000001 in ?? () #66 0xc6732e24 in ?? () #67 0xc6730014 in ?? () #68 0x00000003 in ?? () #69 0x00000000 in ?? () #70 0xc561b954 in ?? () #71 0x0000000a in ?? () #72 0xd464e600 in ?? () #73 0xc6732d6c in ?? () #74 0x00000001 in ?? () #75 0xc57cf719 in ?? () #76 0x00000013 in ?? () #77 0x00000000 in ?? () #78 0xd464e600 in ?? () #79 0xc561bb10 in ?? () #80 0xc561b800 in ?? () #81 0xc561babc in ?? () #82 0xe76e5cf4 in ?? () #83 0xc578d59e in ?? () #84 0xc6730000 in ?? () #85 0xc57cdced in ?? () #86 0x0000096f in ?? () #87 0x00000971 in ?? () #88 0x0162715d in ?? () #89 0x536f8d22 in ?? () #90 0x1c8e4c0d in ?? () #91 0x8c8e0bb1 in ?? () #92 0x7f1469f1 in ?? () #93 0x0222d7a1 in ?? () #94 0x198f3f8f in ?? () #95 0x6b1e5f86 in ?? () #96 0xc6730000 in ?? () #97 0xc455d400 in ?? () #98 0x00000023 in ?? () #99 0xadd71f28 in ?? () #100 0xc561babc in ?? () #101 0x00000000 in ?? () #102 0xc60c7e00 in ?? () #103 0x00000000 in ?? () #104 0x00000000 in ?? () #105 0x00000000 in ?? () #106 0x00000000 in ?? () #107 0xc561b800 in ?? () #108 0x00000000 in ?? () #109 0xc4a65840 in ?? () #110 0xe76e5d24 in ?? () #111 0xc0734479 in fork_exit (callout=0x20000, arg=0x2, frame=0xe76e5bd4) at /usr/src/sys/kern/kern_fork.c:781 Previous frame inner to this frame (corrupt stack?) Please let me know if you need any additional information from the dump file. Give me commands and I shall be your terminal :P keyhole# zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT tank 374G 180G 194G 48% ONLINE - keyhole# zpool status pool: tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 ad2 ONLINE 0 0 0 ad3 ONLINE 0 0 0 ad4 ONLINE 0 0 0 ad6 ONLINE 0 0 0 errors: No known data errors keyhole# zfs list NAME USED AVAIL REFER MOUNTPOINT tank 180G 188G 18K /tank tank/archive 33.3G 188G 33.3G /usr/archive tank/media 146G 188G 146G /usr/media Bert JW Regeer --Apple-Mail-1-460532599-- From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 24 23:50:10 2008 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 DA633106566C for ; Mon, 24 Mar 2008 23:50:10 +0000 (UTC) (envelope-from xistence@0x58.com) Received: from mailexchange.osnn.net (1e.66.5646.static.theplanet.com [70.86.102.30]) by mx1.freebsd.org (Postfix) with SMTP id 998468FC1D for ; Mon, 24 Mar 2008 23:50:10 +0000 (UTC) (envelope-from xistence@0x58.com) Received: (qmail 752 invoked by uid 0); 24 Mar 2008 23:50:09 -0000 Received: from unknown (HELO wideload.network.lan) (xistence@0x58.com@68.228.228.123) by mailexchange.osnn.net with SMTP; 24 Mar 2008 23:50:09 -0000 Cc: FreeBSD Hackers Message-Id: From: Bert JW Regeer 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 v919.2) Date: Mon, 24 Mar 2008 16:50:09 -0700 References: X-Mailer: Apple Mail (2.919.2) Subject: Re: zpool scrub tank && high file system activity caused crash 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, 24 Mar 2008 23:50:11 -0000 On Mar 24, 2008, at 16:23 , Bert JW Regeer wrote: > Hey guys, > > I am running FreeBSD 7.0-RELEASE with GENERIC on a AMD XP Athlon > 3500+ with 1267 MB of ram, and a GigBit NIC. I am testing out ZFS > just for the hell of it, I know, 32 bit is not suggested and runs > badly, but it does what it needs to do. > > I was copying large amounts of data for backup purposes from my > MacBook Pro to the machine over FTP. At the time I was looking > around the man page for zpool, and figured I'd run a zpool scrub > just to see how badly it affects performance. It affects it in that > it takes down the machine with a dump. > > [...] > > Please let me know if you need any additional information from the > dump file. Give me commands and I shall be your terminal :P > > keyhole# zpool list > NAME SIZE USED AVAIL CAP HEALTH > ALTROOT > tank 374G 180G 194G 48% ONLINE - > keyhole# zpool status > pool: tank > state: ONLINE > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > ad2 ONLINE 0 0 0 > ad3 ONLINE 0 0 0 > ad4 ONLINE 0 0 0 > ad6 ONLINE 0 0 0 > > errors: No known data errors > keyhole# zfs list > NAME USED AVAIL REFER MOUNTPOINT > tank 180G 188G 18K /tank > tank/archive 33.3G 188G 33.3G /usr/archive > tank/media 146G 188G 146G /usr/media > > > Bert JW Regeer It crashed again, this time while vsftpd was running, which is the FTPD I am using to drop the files on the server. I am going to be going back to gconcat and friends for now. I will keep the dumps around if anyone needs me to run any commands on it, and find out more information! keyhole# kgdb kernel.debug /var/crash/vmcore.1 [GDB will not be able to debug user-mode threads: /usr/lib/ libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x2000020 fault code = supervisor read, page not present instruction pointer = 0x20:0xc097b5f9 stack pointer = 0x28:0xe769e6c4 frame pointer = 0x28:0xe769e71c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1281 (vsftpd) trap number = 12 panic: page fault cpuid = 0 Uptime: 39m11s Physical memory: 1267 MB Dumping 348 MB: 333 317 301 285 269 253 237 221 205 189 173 157 141 125 109 93 77 61 45 29 13 #0 doadump () at pcpu.h:195 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc0754457 in boot (howto=260) at /usr/src/sys/kern/ kern_shutdown.c:409 #2 0xc0754719 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc0a4905c in trap_fatal (frame=0xe769e684, eva=33554464) at /usr/ src/sys/i386/i386/trap.c:899 #4 0xc0a492e0 in trap_pfault (frame=0xe769e684, usermode=0, eva=33554464) at /usr/src/sys/i386/i386/trap.c:812 #5 0xc0a49c8c in trap (frame=0xe769e684) at /usr/src/sys/i386/i386/ trap.c:490 #6 0xc0a2fc0b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc097b5f9 in vm_page_splay (pindex=Unhandled dwarf expression opcode 0x93 ) at /usr/src/sys/vm/vm_page.c:590 #8 0xc097bb96 in vm_page_remove (m=0xc1ce2e30) at /usr/src/sys/vm/ vm_page.c:722 #9 0xc097bdb1 in vm_page_free_toq (m=0xc1ce2e30) at /usr/src/sys/vm/ vm_page.c:1291 #10 0xc097bf86 in vm_page_free (m=0xc1ce2e30) at /usr/src/sys/vm/ vm_page.c:498 #11 0xc0978860 in vm_object_page_remove (object=0xc0bed860, start=53402, end=53434, clean_only=0) at /usr/src/sys/vm/vm_object.c: 1848 #12 0xc0973072 in vm_map_delete (map=Variable "map" is not available. ) at /usr/src/sys/vm/vm_map.c:2307 #13 0xc0973191 in vm_map_remove (map=0xc147108c, start=3438907392, end=3439038464) at /usr/src/sys/vm/vm_map.c:2423 #14 0xc09707d0 in kmem_free (map=0xc147108c, addr=3438907392, size=131072) at /usr/src/sys/vm/vm_kern.c:210 #15 0xc0967579 in page_free (mem=0xccf99000, size=131072, flags=34 '"') at /usr/src/sys/vm/uma_core.c:1042 #16 0xc096a8b7 in uma_large_free (slab=0xc5988980) at /usr/src/sys/vm/ uma_core.c:2727 #17 0xc074542b in free (addr=0xccf99000, mtp=0xc0da0440) at /usr/src/ sys/kern/kern_malloc.c:444 #18 0xc0d2d597 in ?? () #19 0xccf99000 in ?? () #20 0xc0da0440 in ?? () #21 0x00000000 in ?? () #22 0x00000001 in ?? () #23 0x00000000 in ?? () #24 0xc0da31c0 in ?? () #25 0x00000001 in ?? () #26 0xc59fa5f0 in ?? () #27 0xd06e4000 in ?? () #28 0x00000000 in ?? () #29 0xe769e8b4 in ?? () #30 0xc0d2d77e in ?? () #31 0x00000010 in ?? () #32 0xd06e4000 in ?? () #33 0xc59fa5f0 in ?? () #34 0xd06e4000 in ?? () #35 0xd06e4000 in ?? () #36 0x00007fff in ?? () #37 0xe769e8e4 in ?? () #38 0xc0d2eb43 in ?? () #39 0xc59fa5f0 in ?? () #40 0xc8ceac08 in ?? () #41 0x00000000 in ?? () #42 0xe769e8e4 in ?? () #43 0x0451b1fc in ?? () #44 0x165ec0e8 in ?? () #45 0x00000001 in ?? () #46 0xc59fa5f0 in ?? () #47 0x00000000 in ?? () #48 0x00000000 in ?? () #49 0xe769e914 in ?? () #50 0xc0d336a3 in ?? () #51 0xc59fa5f0 in ?? () #52 0xc8ceac08 in ?? () #53 0xffffffff in ?? () #54 0x00000691 in ?? () #55 0xc59fa5f0 in ?? () #56 0xc8ceac44 in ?? () #57 0xc8ceac08 in ?? () #58 0xc8ceac08 in ?? () #59 0x00000000 in ?? () #60 0xc4a45678 in ?? () #61 0xe769e93c in ?? () #62 0xc0d414e1 in ?? () #63 0xc8ceac08 in ?? () #64 0xc0d9723c in ?? () ---Type to continue, or q to quit--- #65 0x00000002 in ?? () #66 0x00000000 in ?? () #67 0xc0d9723c in ?? () #68 0x0000097f in ?? () #69 0x00000000 in ?? () #70 0xc5150000 in ?? () #71 0xe769e9c4 in ?? () #72 0xc0d41914 in ?? () #73 0x0000097f in ?? () #74 0x00000000 in ?? () #75 0x00000000 in ?? () #76 0x00000001 in ?? () #77 0x00000011 in ?? () #78 0x00000000 in ?? () #79 0x00000002 in ?? () #80 0xc560d440 in ?? () #81 0x00000102 in ?? () #82 0xe769e988 in ?? () #83 0x12fde7e8 in ?? () #84 0x00000000 in ?? () #85 0xc560d440 in ?? () #86 0x00020000 in ?? () #87 0x0000097e in ?? () #88 0x00000000 in ?? () #89 0x00000000 in ?? () #90 0xe769e99c in ?? () #91 0xc4a45678 in ?? () #92 0x00000028 in ?? () #93 0x12fe0430 in ?? () #94 0x00000000 in ?? () #95 0xe769e9c4 in ?? () #96 0xc0d411e7 in ?? () #97 0xc588c700 in ?? () #98 0xc560d440 in ?? () #99 0x00000000 in ?? () #100 0xc588c700 in ?? () #101 0xe769e9b8 in ?? () #102 0xc560d440 in ?? () #103 0x00001c48 in ?? () #104 0x00000000 in ?? () #105 0xe769e9fc in ?? () #106 0xc0d41c03 in ?? () #107 0x00001c48 in ?? () #108 0x00000000 in ?? () #109 0x00000001 in ?? () #110 0x12fde7e8 in ?? () #111 0x00000000 in ?? () #112 0x00001c48 in ?? () #113 0x00000000 in ?? () #114 0x12fde7e8 in ?? () #115 0x00000000 in ?? () #116 0x12fe0430 in ?? () #117 0x00000000 in ?? () #118 0xc5bc984c in ?? () #119 0xe769eafc in ?? () #120 0xc0d900cc in ?? () #121 0xc588c700 in ?? () #122 0x000000b8 in ?? () #123 0x00000000 in ?? () #124 0x12fde7e8 in ?? () #125 0x00000000 in ?? () #126 0x00001c48 in ?? () #127 0x00000000 in ?? () #128 0xc56d8910 in ?? () #129 0xc4703e00 in ?? () ---Type to continue, or q to quit--- #130 0xe769ea44 in ?? () #131 0xc0893664 in tcp_timer_activate (tp=0x10, timer_type=-798081024, delta=3315574256) at /usr/src/sys/netinet/tcp_timer.c:599 Previous frame inner to this frame (corrupt stack?) From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 25 03:01:03 2008 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 808AB1065672 for ; Tue, 25 Mar 2008 03:01:03 +0000 (UTC) (envelope-from wxs@atarininja.org) Received: from syn.atarininja.org (syn.csh.rit.edu [129.21.60.158]) by mx1.freebsd.org (Postfix) with ESMTP id 4AB9E8FC1F for ; Tue, 25 Mar 2008 03:01:03 +0000 (UTC) (envelope-from wxs@atarininja.org) Received: by syn.atarininja.org (Postfix, from userid 1001) id CA7FE5C17; Mon, 24 Mar 2008 22:46:31 -0400 (EDT) Date: Mon, 24 Mar 2008 22:46:31 -0400 From: Wesley Shields To: Bert JW Regeer Message-ID: <20080325024631.GF7923@atarininja.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Cc: hackers@FreeBSD.org Subject: Re: zpool scrub tank && high file system activity caused crash 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, 25 Mar 2008 03:01:03 -0000 On Mon, Mar 24, 2008 at 04:23:19PM -0700, Bert JW Regeer wrote: > Hey guys, > > I am running FreeBSD 7.0-RELEASE with GENERIC on a AMD XP Athlon 3500+ with > 1267 MB of ram, and a GigBit NIC. I am testing out ZFS just for the hell of > it, I know, 32 bit is not suggested and runs badly, but it does what it > needs to do. > > I was copying large amounts of data for backup purposes from my MacBook Pro > to the machine over FTP. At the time I was looking around the man page for > zpool, and figured I'd run a zpool scrub just to see how badly it affects > performance. It affects it in that it takes down the machine with a dump. > > keyhole# kgdb kernel.debug /var/crash/vmcore.0 > [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: > Undefined symbol "ps_pglobal_lookup"] > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you > are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-marcel-freebsd". > > Unread portion of the kernel message buffer: > panic: vm_page_insert: offset already allocated > cpuid = 0 > Uptime: 10h58m58s > Physical memory: 1267 MB > Dumping 335 MB: 320 304 288 272 256 240 224 208 192 176 160 144 128 112 96 > 80 64 48 32 16 Out of curiosity, have you done any tuning on this machine? Specifically some of the stuff mentioned on the wiki? -- WXS From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 25 03:35:58 2008 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 0A2781065670 for ; Tue, 25 Mar 2008 03:35:58 +0000 (UTC) (envelope-from xistence@0x58.com) Received: from mailexchange.osnn.net (1e.66.5646.static.theplanet.com [70.86.102.30]) by mx1.freebsd.org (Postfix) with SMTP id AF5D08FC13 for ; Tue, 25 Mar 2008 03:35:57 +0000 (UTC) (envelope-from xistence@0x58.com) Received: (qmail 30488 invoked by uid 0); 25 Mar 2008 03:09:16 -0000 Received: from unknown (HELO wideload.network.lan) (xistence@0x58.com@68.228.228.123) by mailexchange.osnn.net with SMTP; 25 Mar 2008 03:09:16 -0000 Message-Id: From: Bert JW Regeer To: Wesley Shields In-Reply-To: <20080325024631.GF7923@atarininja.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 24 Mar 2008 20:09:16 -0700 References: <20080325024631.GF7923@atarininja.org> X-Mailer: Apple Mail (2.919.2) Cc: hackers@FreeBSD.org Subject: Re: zpool scrub tank && high file system activity caused crash 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, 25 Mar 2008 03:35:58 -0000 On Mar 24, 2008, at 19:46 , Wesley Shields wrote: > On Mon, Mar 24, 2008 at 04:23:19PM -0700, Bert JW Regeer wrote: >> Hey guys, >> >> I am running FreeBSD 7.0-RELEASE with GENERIC on a AMD XP Athlon >> 3500+ with >> 1267 MB of ram, and a GigBit NIC. I am testing out ZFS just for the >> hell of >> it, I know, 32 bit is not suggested and runs badly, but it does >> what it >> needs to do. >> >> I was copying large amounts of data for backup purposes from my >> MacBook Pro >> to the machine over FTP. At the time I was looking around the man >> page for >> zpool, and figured I'd run a zpool scrub just to see how badly it >> affects >> performance. It affects it in that it takes down the machine with a >> dump. >> >> keyhole# kgdb kernel.debug /var/crash/vmcore.0 >> [GDB will not be able to debug user-mode threads: /usr/lib/ >> libthread_db.so: >> Undefined symbol "ps_pglobal_lookup"] >> GNU gdb 6.1.1 [FreeBSD] >> Copyright 2004 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, >> and you >> are >> welcome to change it and/or distribute copies of it under certain >> conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for >> details. >> This GDB was configured as "i386-marcel-freebsd". >> >> Unread portion of the kernel message buffer: >> panic: vm_page_insert: offset already allocated >> cpuid = 0 >> Uptime: 10h58m58s >> Physical memory: 1267 MB >> Dumping 335 MB: 320 304 288 272 256 240 224 208 192 176 160 144 128 >> 112 96 >> 80 64 48 32 16 > > Out of curiosity, have you done any tuning on this machine? > Specifically some of the stuff mentioned on the wiki? > > -- WXS I had not. I changed the size the kernel was allowed to be to at least 512 M as that is recommended, and I got the same panic as the first email I sent out (this time as seen in dmesg -a), I also ran out of space on /var so it did not save the vmcore :(. I am going to wait till I get my 64 bit system up and running before messing with ZFS again. I don't think the amount of ram I have in that machine would be enough with some of the other stuff it will have to do as well, if I let the kernel eat up to a GB. Bert JW Regeer From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 25 05:38:58 2008 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 908BE106566B for ; Tue, 25 Mar 2008 05:38:58 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 6962E8FC16 for ; Tue, 25 Mar 2008 05:38:58 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 496D81CC060; Mon, 24 Mar 2008 22:38:58 -0700 (PDT) Date: Mon, 24 Mar 2008 22:38:58 -0700 From: Jeremy Chadwick To: Bert JW Regeer Message-ID: <20080325053858.GA32888@eos.sc1.parodius.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Cc: FreeBSD Hackers Subject: Re: zpool scrub tank && high file system activity caused crash 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, 25 Mar 2008 05:38:58 -0000 On Mon, Mar 24, 2008 at 04:23:19PM -0700, Bert JW Regeer wrote: > I am running FreeBSD 7.0-RELEASE with GENERIC on a AMD XP Athlon 3500+ with > 1267 MB of ram, and a GigBit NIC. I am testing out ZFS just for the hell of > it, I know, 32 bit is not suggested and runs badly, but it does what it > needs to do. > > I was copying large amounts of data for backup purposes from my MacBook Pro > to the machine over FTP. At the time I was looking around the man page for > zpool, and figured I'd run a zpool scrub just to see how badly it affects > performance. It affects it in that it takes down the machine with a dump. There's been many previous statements from others that heavy I/O on ZFS results in either a crash or a hard hang, on both i386 and amd64. You're not alone. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 25 09:28:12 2008 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 3D2DC106566B for ; Tue, 25 Mar 2008 09:28:12 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.247]) by mx1.freebsd.org (Postfix) with ESMTP id DAF338FC3C for ; Tue, 25 Mar 2008 09:28:11 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so1094839anc.13 for ; Tue, 25 Mar 2008 02:28:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=wTj8dp6qtPHt5Sks2V46KZxTzdL4ITIWdRSCwW2Qt7M=; b=Ljbbroesza9zDIcEPK0ki3uVRCOyizPIMFBI7S/do+jLPjL9AsN9A0pl3gPktSRifs1gj/I3rDX70HzlixpAu3n/ZgnkywOA1Z19anCSKRAHXbs58wccszoix99rFHxsMek0/w/8tIL5b0v+rsG8JtOGnaO2KrSnwkiZd6CF2rw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fP5kYfkURienz60K4HuUFphfV9c9Ddhj4s1Z7OQT+f10+xlbCoFw7jufWJco0RN/WK1Em7FG+XDx2D0SVwAuwRLZuEK8QHfcNm1cDZ3rT8CcB05OBd9RUehjlmZMrh7nFbJigH/X1Yd4EVk9fkj/UyAjnmpzWn9qNmrC3B7VxVk= Received: by 10.100.140.1 with SMTP id n1mr20440751and.70.1206435784460; Tue, 25 Mar 2008 02:03:04 -0700 (PDT) Received: by 10.100.8.19 with HTTP; Tue, 25 Mar 2008 02:03:04 -0700 (PDT) Message-ID: Date: Tue, 25 Mar 2008 17:03:04 +0800 From: "Sepherosa Ziehau" To: "Julian Elischer" In-Reply-To: <47E7EAA8.7020101@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47E79636.1000909@FreeBSD.org> <47E7EAA8.7020101@elischer.org> Cc: vadim_nuclight@mail.ru, freebsd-ipfw@freebsd.org, araujo@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: [HEADS UP!] IPFW Ideas: possible SoC 2008 candidate 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, 25 Mar 2008 09:28:12 -0000 On Tue, Mar 25, 2008 at 1:53 AM, Julian Elischer wrote: > 3/ possibly keeping per CPU stats.. This probably is the trickest part, not difficult for non-fastforward case. But if fastforward is enabled, I could only imagine full cross-cpu states duplication. Best Regards, sephe -- Live Free or Die From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 25 09:45:42 2008 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 96BB21065723 for ; Tue, 25 Mar 2008 09:45:42 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5970C8FC21 for ; Tue, 25 Mar 2008 09:45:42 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 0130046C1B; Tue, 25 Mar 2008 05:45:42 -0400 (EDT) Date: Tue, 25 Mar 2008 09:45:41 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Sepherosa Ziehau In-Reply-To: Message-ID: <20080325094400.I6905@fledge.watson.org> References: <47E79636.1000909@FreeBSD.org> <47E7EAA8.7020101@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: vadim_nuclight@mail.ru, freebsd-ipfw@freebsd.org, Julian Elischer , freebsd-hackers@freebsd.org, araujo@freebsd.org Subject: Re: [HEADS UP!] IPFW Ideas: possible SoC 2008 candidate 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, 25 Mar 2008 09:45:42 -0000 On Tue, 25 Mar 2008, Sepherosa Ziehau wrote: > On Tue, Mar 25, 2008 at 1:53 AM, Julian Elischer wrote: >> 3/ possibly keeping per CPU stats.. > > This probably is the trickest part, not difficult for non-fastforward case. > But if fastforward is enabled, I could only imagine full cross-cpu states > duplication. FWIW, there is decreasing difference between IP fast forwarding and regular IP processing in FreeBSD 7.x, as we perform direct dispatch by default, so it's not just the fast forward case where full input parallelism is possible for the firewall, and parallel firewall processing has occurred for output since 5.3. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 26 08:50:14 2008 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 433E5106566B for ; Wed, 26 Mar 2008 08:50:14 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id C43AD8FC18 for ; Wed, 26 Mar 2008 08:50:13 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1JeRKf-0008JM-5F for freebsd-hackers@freebsd.org; Wed, 26 Mar 2008 08:50:05 +0000 Received: from 195.208.174.178 ([195.208.174.178]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 26 Mar 2008 08:50:05 +0000 Received: from vadim_nuclight by 195.208.174.178 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 26 Mar 2008 08:50:05 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Vadim Goncharov Followup-To: gmane.os.freebsd.devel.ipfw Date: Wed, 26 Mar 2008 08:49:12 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 57 Message-ID: References: <47E79636.1000909@FreeBSD.org> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 195.208.174.178 X-Comment-To: Marcelo Araujo User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news Cc: freebsd-ipfw@freebsd.org Subject: Re: [HEADS UP!] IPFW Ideas: possible SoC 2008 candidate X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2008 08:50:14 -0000 Hi Marcelo Araujo! On Mon, 24 Mar 2008 08:53:26 -0300; Marcelo Araujo wrote about 'Re: [HEADS UP!] IPFW Ideas: possible SoC 2008 candidate': >> 2.5. Just to mention: modip, counter limits, fragments. >> >> These patches are already currently discussed in ipfw@, but included >> here just to not forget. These are "modip" action, allowing to modify IP >> header (DSCP, ToS, TTL) and corresponding match rule options, and a rule >> option to match when rule counters are less then specified number >> packets or bytes (possibly from dynamic rule's counters), may be >> a tablearg. This is also related with mentioned in section 1.2 ability >> to control rule counters. >> >> Adding a few keywords for O_FRAG more fragment matching (not only >> non-first fragment), e.g. for sending to specialized netgraph(4) >> reassembling module, is also desirable. > For remember to all, I work around of modip action stilly, I stoped my > work during last week, but I work again in it. > Work status: > 1) We have modip action implemented: > island# ipfw add modip > ipfw: need modip [DF|TOS|IPPRE|DSCP]:code arg > 2) Both DF and IPPRE works perfect: > island# ipfw show > 00010 371 36133 modip ippre:immediate ip from any to any > 00011 52 5035 modip df:0 ip from any to any > 3) DSCP: > With the DSCP I've some errors but I believe that I fix it on this week. > 4) ToS: > I start the work on the next week. > The patch: http://people.freebsd.org/~araujo/logs/ipfw-modip20080324.diff= Looked at the patch. Some line are changed e.g. in NAT definitions without any visible changes, strange. Also, you're adding 7 opcode in the kernel, 2 for match and 5 for setting, while having single "modip" action in userland. In the case of significantly changing compilation rulesm, etc., we may need many new opcodes so we should not waste them. For example, your O_IPTOSPRE is redundant because we already have O_IPPRECEDENCE which compiler could utilize while retainig more ABI compatibility. I can correct and extend your patch for DSCP/TTL/any bytes (not forgetting credits, of course), if you're too busy... -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 26 09:00:10 2008 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 5AD661065671 for ; Wed, 26 Mar 2008 09:00:10 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 15C7F8FC1E for ; Wed, 26 Mar 2008 09:00:10 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1JeRUJ-0000VQ-JD for freebsd-hackers@freebsd.org; Wed, 26 Mar 2008 09:00:03 +0000 Received: from 195.208.174.178 ([195.208.174.178]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 26 Mar 2008 09:00:03 +0000 Received: from vadim_nuclight by 195.208.174.178 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 26 Mar 2008 09:00:03 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Vadim Goncharov Followup-To: gmane.os.freebsd.devel.ipfw Date: Wed, 26 Mar 2008 08:51:59 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 24 Message-ID: References: <47E79636.1000909@FreeBSD.org> <47E7EAA8.7020101@elischer.org> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 195.208.174.178 X-Comment-To: Julian Elischer User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news Cc: freebsd-ipfw@freebsd.org Subject: Re: [HEADS UP!] IPFW Ideas: possible SoC 2008 candidate X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2008 09:00:10 -0000 Hi Julian Elischer! On Mon, 24 Mar 2008 10:53:44 -0700; Julian Elischer wrote about 'Re: [HEADS UP!] IPFW Ideas: possible SoC 2008 candidate': > here are some of my ideas for ipfw changes: > 1/ redo locking so that packets do not have to get locks on the > structure... I have several ideas on this Currently the main need for locking arises for rule byte/packet counters. The easiest short-term solution > 2/ allow separate firewalls to be used at different parts of the > network stack (i.e allow multiple taboe sto co-exist) Umm, could you explain it a little?.. > 3/ possibly keeping per CPU stats.. How that would be represented to user? -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 26 09:01:42 2008 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 19FAB106564A for ; Wed, 26 Mar 2008 09:01:42 +0000 (UTC) (envelope-from soralx@cydem.org) Received: from pd3mo1so.prod.shaw.ca (idcmail-mo1so.shaw.ca [24.71.223.10]) by mx1.freebsd.org (Postfix) with ESMTP id E53588FC2E for ; Wed, 26 Mar 2008 09:01:41 +0000 (UTC) (envelope-from soralx@cydem.org) Received: from pd3mr5so.prod.shaw.ca (pd3mr5so-qfe3.prod.shaw.ca [10.0.141.12]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0JYB00LB2YETGOD0@l-daemon> for freebsd-hackers@freebsd.org; Wed, 26 Mar 2008 03:01:41 -0600 (MDT) Received: from pn2ml1so.prod.shaw.ca ([10.0.121.145]) by pd3mr5so.prod.shaw.ca (Sun Java System Messaging Server 6.2-7.05 (built Sep 5 2006)) with ESMTP id <0JYB00DWVYERYB30@pd3mr5so.prod.shaw.ca> for freebsd-hackers@freebsd.org; Wed, 26 Mar 2008 03:01:42 -0600 (MDT) Received: from cydem.org ([24.87.3.133]) by l-daemon (Sun Java System Messaging Server 6.2-7.05 (built Sep 5 2006)) with ESMTP id <0JYB0030NYENLY00@l-daemon> for freebsd-hackers@freebsd.org; Wed, 26 Mar 2008 03:01:38 -0600 (MDT) Received: by cydem.org (Postfix/FreeBSD, from userid 58) id 5CD7D7FF25; Wed, 26 Mar 2008 02:02:18 -0700 (PDT) Received: from freen0de (s64-180-126-80.bc.hsia.telus.net [64.180.126.80]) by cydem.org (Postfix/FreeBSD) with ESMTP id BAB967F21A for ; Wed, 26 Mar 2008 02:02:17 -0700 (PDT) Date: Wed, 26 Mar 2008 02:01:31 -0700 From: soralx@cydem.org To: freebsd-hackers@freebsd.org Message-id: <20080326020131.589a3334@freen0de> MIME-version: 1.0 X-Mailer: Claws Mail 3.3.1 (GTK+ 2.12.9; i386-portbld-freebsd6.3) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on cydem.org X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.1.8 X-Spam-Level: Subject: ports system woes 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, 26 Mar 2008 09:01:42 -0000 Folks, are there any plans to rewrite the ports/packages system? Maybe someone started work on improving things in this area already? The thought that pkg_* tools and Mk/* scripts might be somewhat inefficient had crossed my mind before, when at last modular Xorg exposed all the inefficiencies in these tools. Basically, pkg_* and portupgrade seem to use very inefficient algorithms all over the place; they've become nearly useless on my system these days. Consider pkg_delete, for example: `time pkg_delete /var/db/pkg/rxvt-unicode-9.02/` real 7m4.207s user 0m4.083s sys 0m16.348s This one was rather benign. Many of bigger packages take 15 minutes to get removed. Now, all the test were conducted on Pentium 4-M 1.2GHz notebook with 256M RAM and MHT2040AH hard drive (5400RPM, 8M buffer). Notice the amount of RAM. Also: [root@freen0de /var/db/pkg]# ll|wc -l 959 For the rxvt case, the offending function is matchbyorigin() inside src/usr.sbin/pkg_install/lib/match.c, called from delete/perform.c function pkg_do(). Here's a snippet from pkg_do(): for (p = Plist.head; p ; p = p->next) { if (p->type != PLIST_PKGDEP) continue; deporigin = \ (p->next != NULL && p->next->type == PLIST_DEPORIGIN) ?p->next->name : NULL; if (Verbose) { printf("Trying to remove dependency on package '%s'", p->name); if (deporigin != NULL) printf(" with '%s' origin", deporigin); printf(".\n"); } if (!Fake) { depnames = (deporigin != NULL) ? matchbyorigin(deporigin, NULL) : NULL; if (depnames == NULL) { depnames = alloca(sizeof(*depnames) * 2); depnames[0] = p->name; depnames[1] = NULL; } for (i = 0; depnames[i] != NULL; i++) undepend(depnames[i], pkg); } } What exactly "removing dependency on package" means? (i.e., what is undepend() for?) I didn't figure it out yet (anyone?), but from what I read from the code, it calls matchbyorigin(deporigin, NULL) -- which is the super-slow part -- while processing each @pkgdep one-by-one. matchbyorigin(), in turn, scans +CONTENTS of each entry in db/pkg/* to get '@comment ORIGIN:' value. As a result, each operation (like "Trying to remove dependency on package 'xineramaproto-1.1.2' with 'x11/xineramaproto' origin.") takes 3-4 seconds (first one ~30s), and there are ~120(!) dependencies for urxvt (I imagine them evil penguins are all too glad to make everything complete chaos, but hopefully making things _so_ modular has at least some benefits). Replacing 'if (!Fake)' with 'if (FALSE)' makes pkg_delete go _really_ fast -- almost instantaneous. I didn't notice any side effects of that hack so far, but there sure are some. Anyway, I understand the desire to move functions like matchbyorigin() to libinstall, but can't that one at least be made to accept an array of strings (package names) and process them in a single pass? The whole of src/usr.sbin/pkg_install needs rewriting, IMO, as this is just one of many examples of slow code. Here's another example. Checking if a package is already installed was also quite slow. Much of the slowness, turns out, was caused by the following in ports/Mk/bsd.openssl.mk: .if !defined(OPENSSL_PORT) && \ exists(${LOCALBASE}/lib/libcrypto.so) # find installed port and use it for dependency PKG_DBDIR?= ${DESTDIR}/var/db/pkg OPENSSL_INSTALLED!= grep -l -r "^lib/libssl.so." "${PKG_DBDIR}" | \ while read contents; do \ sslprefix=`grep "^@cwd " "$${contents}" | ${HEAD} -n 1`; \ if test "$${sslprefix}" = "@cwd ${LOCALBASE}" ; then \ echo "$${contents}"; break; fi; done OPENSSL_PORT!= grep "^@comment ORIGIN:" "${OPENSSL_INSTALLED}" | ${CUT} -d : -f 2 OPENSSL_SHLIBFILE!= grep "^lib/libssl.so." "${OPENSSL_INSTALLED}" OPENSSL_SHLIBVER?= ${OPENSSL_SHLIBFILE:E} .endif OPENSSL_PORT?= security/openssl Simply defining 'OPENSSL_PORT=security/openssl' in make.conf helped a lot (although really, we need to figure a better method of finding installed openssl port -- perhaps a script that updates OPENSSL_PORT in make.conf after port installs?). It is still fairly slow, though. Another example: [root@freen0de /usr/ports/x11/nvidia-driver-96xx]# make fetch ===> Vulnerability check disabled, database not found ===> Found saved configuration for nvidia-driver-96.43.01 => NVIDIA-FreeBSD-x86-96.43.05.tar.gz doesn't seem to exist in /usr/ports/distfiles/. => Attempting to fetch from http://jp.download.nvidia.com/freebsd/96.43.05/. NVIDIA-FreeBSD-x86-96.43.05.tar.gz 100% of 9444 kB 71 kBps [root@freen0de /usr/ports/x11/nvidia-driver-96xx]# time make fetch ===> Vulnerability check disabled, database not found ===> Found saved configuration for nvidia-driver-96.43.01 real 0m53.340s user 0m0.299s sys 0m0.886s [root@freen0de /usr/ports/x11/nvidia-driver-96xx]# time make maintainer real 0m22.817s user 0m0.265s sys 0m0.685s [root@freen0de /usr/ports/x11/nvidia-driver-96xx]# So all these examples are only tip of the iceberg that is currently making pkg_* & ports sink, but of course no other bugs are as serious as the one with pkg_delete (or so I hope). And I'm not even talking about portupgrade. Dragging it's feet at a snail pace, running sluggish 'pkgdb -Q' each tiny step... it's a rather useful tool. But, I believe portupgrade is not really needed -- if FreeBSD's base ports/packaging tools get fixed and extended, they'd do the job (yah, there's portmaster, but with broken pkg_*, it's just as good as portupgrade). BTW, to make `portupgrade -a` at all useful, a while ago I whipped up a bash command that lists all dependencies of installed packages: export PORTSBASE=/usr/ports; cd /var/db/pkg for dir in `ls`; do tmp=`(grep '@comment ORIGIN' "${dir}/+CONTENTS"|awk -F ":" '{ print $2 }')`; echo ${tmp}; cd ${PORTSBASE}/${tmp} && (make package-depends-list|awk -F " " '{ print $3 }'); cd /var/db/pkg/; done|sort|uniq > /tmp/deps.lst Allow it 3-5 hours per 1000 installed ports 8-) The good thing is that theoretically this should get all the dependencies in fresh ports tree right, when fed from old (not updated) /var/db/pkg, so then you could do: for dir in `cat /tmp/deps.lst`; do cd ${PORTSBASE}/${dir} && make config-conditional; done which in ~10 minutes should take care care of all the new unconfigured (`make config`) ports in single attempt. Practically, there are always some problems with the gazillion versions of tcl* and tk* (go to ports tree and manually run `make config` for each and every version of tcl* and tk* that's there), and any cases where 'dialog' coredumps (long lists of options). /tmp/deps.lst can be usually reused. Now, just to convert these commands to normal /bin/sh script... [SorAlx] ridin' VN1500-B2 From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 26 12:17:59 2008 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 788BC106566B for ; Wed, 26 Mar 2008 12:17:59 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id 2A1C98FC19 for ; Wed, 26 Mar 2008 12:17:58 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so1269918anc.13 for ; Wed, 26 Mar 2008 05:17:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:reply-to:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:openpgp:content-type:from; bh=2E+K1OiPuhppx/jgA7oWBwJ9gpc3xQIVbP+UGZVDbqI=; b=OeiJfvDZPtCjOl/cLcGBdiQ7OFzVKJAFQM5uMBfElNT8GY/3LELPdVnNpMyKXdgWT9JGGzpnq3abH/S0fzYJBR97BAxpavQU3y96PJ1ERekanghjSkvXn+R2oqlIDxPbSWSuPdbZDSKObYk4jjLkhUaaEfsUN0hWOnu0t1wndwI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:reply-to:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:openpgp:content-type:from; b=Z21UJ73JzkzC/CJoILjv7mCzGLt3htvOVQfFBARuDneiqqZhrblEuV/2+oadJVgc8W/7Jo723WZJCd2aYQlrt+PHQdso/F9VJ1/H3rIZamh3a9bBn7cheC7uwnSix+1S+fMM1WZbDHbE9cjgyU+wk55o6uPUTX7V+GVIWBt7zVI= Received: by 10.100.225.19 with SMTP id x19mr21822777ang.5.1206533877834; Wed, 26 Mar 2008 05:17:57 -0700 (PDT) Received: from island.freebsd.org ( [200.247.114.5]) by mx.google.com with ESMTPS id c23sm15775511ana.15.2008.03.26.05.17.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 26 Mar 2008 05:17:56 -0700 (PDT) Message-ID: <47EA3EEC.2040007@FreeBSD.org> Date: Wed, 26 Mar 2008 09:17:48 -0300 Organization: FreeBSD User-Agent: Thunderbird 2.0.0.0 (X11/20070521) MIME-Version: 1.0 To: vadim_nuclight@mail.ru References: <47E79636.1000909@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.95.0 OpenPGP: id=53E4CFA8 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF38EA32A2BFA59820860D170" From: Marcelo Araujo X-Mailman-Approved-At: Wed, 26 Mar 2008 12:58:43 +0000 Cc: freebsd-ipfw@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: [HEADS UP!] IPFW Ideas: possible SoC 2008 candidate X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: araujo@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2008 12:17:59 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF38EA32A2BFA59820860D170 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Vadim Goncharov wrote: > > Looked at the patch. Some line are changed e.g. in NAT definitions with= out any > visible changes, strange. > > Also, you're adding 7 opcode in the kernel, 2 for match and 5 for setti= ng, > while having single "modip" action in userland. In the case of signific= antly > changing compilation rulesm, etc., we may need many new opcodes so we s= hould > not waste them. For example, your O_IPTOSPRE is redundant because we al= ready > have O_IPPRECEDENCE which compiler could utilize while retainig more AB= I > compatibility. > > I can correct and extend your patch for DSCP/TTL/any bytes (not forgett= ing > credits, of course), if you're too busy... > > =20 Of course, I've interest in any external support, because I need to finish my degree project and I'm a bit busy. Any help are welcome and please feel free to re-work the patch. Just like the really the most important thing is the *modip*, I'm happy that you work within this idea.= I'd like to see *modip* committed. I continue to my research and if I've some time to work with ipfw or another mechanism that have some relation with my project degree, I'll ma= ke. Best Regards, --=20 Marcelo Araujo (__) araujo@FreeBSD.org \\\'',) http://www.FreeBSD.org \/ \ ^ Power To Server. .\. /_) --------------enigF38EA32A2BFA59820860D170 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFH6j7wovxJd1Pkz6gRAsRtAJ4iFpSbKPiW8fIH6ynJ4wi5JZTU/wCfW3F0 qxGd8431PJTvgvZg3eQ7Ilk= =P/KB -----END PGP SIGNATURE----- --------------enigF38EA32A2BFA59820860D170-- From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 26 13:42:02 2008 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 9B0C71065674 for ; Wed, 26 Mar 2008 13:42:02 +0000 (UTC) (envelope-from shingrus@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.freebsd.org (Postfix) with ESMTP id 330F98FC26 for ; Wed, 26 Mar 2008 13:42:01 +0000 (UTC) (envelope-from shingrus@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so65758uge.37 for ; Wed, 26 Mar 2008 06:42:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=SHnOv5VODxPlGoa+I0J+kGifFeXzbNvLx2VvXMkPgRo=; b=M/yWkMM1n1tr0ZIJFve3CtG4etM4iN/JRDYimOq28gisZUxc1WRIblqgODOTk1wX1MrvsE4HXvlJZUlUsSe6RE2BopBryixuRQI1KKmZaLKhtDhNGJzXbP8+TJHrU+reKCy2Fv1tXO3z80Uewc3EaEk1v0hUIeyLzu6vUZ06cMs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:mime-version:content-type; b=rz3janpmHdrLsf0OIrH5/DJts60RTbQA3gBtO6c308VbmT6cjizt6jqqW59BglWBpVuVYQ3OKKv1S9juMNYc/j1y6uLn4qz6+AW+SrQkkgwfPb+0SS2YrjuGFrOl0DLAM4rQ41UNSkYSeb3PpOn3AD2ncwFJFde5GmwSetUrJQ8= Received: by 10.82.184.2 with SMTP id h2mr24519339buf.1.1206537377664; Wed, 26 Mar 2008 06:16:17 -0700 (PDT) Received: by 10.82.127.10 with HTTP; Wed, 26 Mar 2008 06:16:17 -0700 (PDT) Message-ID: <6a5f00340803260616t55902641m62fa8e2b7d685df1@mail.gmail.com> Date: Wed, 26 Mar 2008 16:16:17 +0300 From: "shing shing" To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: unsubsribe 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, 26 Mar 2008 13:42:02 -0000 From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 26 17:31:14 2008 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 30E3C1065670 for ; Wed, 26 Mar 2008 17:31:14 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outP.internet-mail-service.net (outp.internet-mail-service.net [216.240.47.239]) by mx1.freebsd.org (Postfix) with ESMTP id 1D5008FC23 for ; Wed, 26 Mar 2008 17:31:13 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Wed, 26 Mar 2008 13:17:41 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id A6DEA2D600D; Wed, 26 Mar 2008 10:31:12 -0700 (PDT) Message-ID: <47EA8860.3060709@elischer.org> Date: Wed, 26 Mar 2008 10:31:12 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: vadim_nuclight@mail.ru References: <47E79636.1000909@FreeBSD.org> <47E7EAA8.7020101@elischer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-ipfw@freebsd.org Subject: Re: [HEADS UP!] IPFW Ideas: possible SoC 2008 candidate 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, 26 Mar 2008 17:31:14 -0000 Vadim Goncharov wrote: > Hi Julian Elischer! > > On Mon, 24 Mar 2008 10:53:44 -0700; Julian Elischer wrote about 'Re: [HEADS UP!] IPFW Ideas: possible SoC 2008 candidate': > >> here are some of my ideas for ipfw changes: > >> 1/ redo locking so that packets do not have to get locks on the >> structure... I have several ideas on this > > Currently the main need for locking arises for rule byte/packet counters. The > easiest short-term solution The main need for locking is that the rules can be changed while a processor is traversing the rule set. > >> 2/ allow separate firewalls to be used at different parts of the >> network stack (i.e allow multiple taboe sto co-exist) there are many places that ipfw is currently callable from. ip_input(), ip_output(), ether_demux(), if_brige, ether_output() it would be interesting tobe able to have differnt firewalls in these places (possibly per interface) so that state (e.g. keep_state) can be kept seprately for one place then from another. for example you may not want the result of 'keep state' on an external interface to necessarily affect what happens to packets from the same session when viewed traversing an internal interface. Currently on my more complex ipfw rule sets I break the rule sets out so that packets in different places traverse different rules but it would be nice to have it explicitly supported. > > Umm, could you explain it a little?.. > >> 3/ possibly keeping per CPU stats.. > > How that would be represented to user? it wouldn't.. you'd add them together before presenting them. but every time a packet changes a counter that is shared, there is a chance that it is being altered by another processor, so if you have fine grained locking in ipfw, you really should use atomic adds, which are slow, or accept possibl collisions (which might be ok) but still cause a lot of cross cpu TLB flushing. > From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 27 00:59:19 2008 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 510B9106566B for ; Thu, 27 Mar 2008 00:59:19 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 9CCB38FC14 for ; Thu, 27 Mar 2008 00:59:18 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id m2R0xDmI082298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Mar 2008 11:29:15 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: stef@memberwebs.com Date: Thu, 27 Mar 2008 11:29:11 +1030 User-Agent: KMail/1.9.7 References: <20080320131638.7E66B94C853@mx.npubs.com> <200803220937.33552.doconnor@gsoft.com.au> <20080322045846.58F8D94C804@mx.npubs.com> In-Reply-To: <20080322045846.58F8D94C804@mx.npubs.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5747352.PgCTCiOgY6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200803271129.12772.doconnor@gsoft.com.au> X-Spam-Score: -3.977 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: freebsd-hackers@freebsd.org Subject: Re: Vital Patches for ataraid with Intel Matrix RAID (ICH7) 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, 27 Mar 2008 00:59:19 -0000 --nextPart5747352.PgCTCiOgY6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sat, 22 Mar 2008, Stef Walter wrote: > Daniel O'Connor wrote: > > I have seen this bug in other ATA RAID implementations (VIA & > > Promise) too. From what I can tell this part of your patch is > > general to all ATA RAID arrays, right? > > Yes, a small part. The part that will write out the RAID information > (thus updating the generation) whenever the status changes, > regardless of whether that change takes place when the machine is off > or not. I am fairly astonished that the ataraid code didn't do that already :( > Without testing, I can't be sure whether this solves the problem on > other ataraid devices. I don't have ready access to such systems anymore, we switched to 3ware=20 controllers after seeing problems with broken arrays. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart5747352.PgCTCiOgY6 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBH6vFg5ZPcIHs/zowRAt1oAJ41o1lfHyrp1gWBZZsbBIzeptGwTACfcNnC adHx65ASWcXCKoWQE2DVO8E= =aVW+ -----END PGP SIGNATURE----- --nextPart5747352.PgCTCiOgY6-- From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 27 06:00:49 2008 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 520BB106566B for ; Thu, 27 Mar 2008 06:00:49 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 433878FC17 for ; Thu, 27 Mar 2008 06:00:49 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 1694C1CC060; Wed, 26 Mar 2008 23:00:49 -0700 (PDT) Date: Wed, 26 Mar 2008 23:00:49 -0700 From: Jeremy Chadwick To: stef@memberwebs.com Message-ID: <20080327060049.GA47731@eos.sc1.parodius.com> References: <20080320131638.7E66B94C853@mx.npubs.com> <200803220937.33552.doconnor@gsoft.com.au> <20080322045846.58F8D94C804@mx.npubs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080322045846.58F8D94C804@mx.npubs.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-hackers@freebsd.org Subject: Re: Vital Patches for ataraid with Intel Matrix RAID (ICH7) 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, 27 Mar 2008 06:00:49 -0000 On Sat, Mar 22, 2008 at 04:58:47AM +0000, Stef Walter wrote: > Daniel O'Connor wrote: > > I have seen this bug in other ATA RAID implementations (VIA & Promise) > > too. From what I can tell this part of your patch is general to all ATA > > RAID arrays, right? > > Yes, a small part. The part that will write out the RAID information > (thus updating the generation) whenever the status changes, regardless > of whether that change takes place when the machine is off or not. > > Without testing, I can't be sure whether this solves the problem on > other ataraid devices. I have access to many boxes that have two disks, support native Intel MatrixRAID, and proper hot-swap backplanes. I also have access to a Promise TX4310 card, which I can hook up to said servers (vs. using the onboard ICH7). I should be able to reproduce failure scenarios (pulling disks while in a RAID-1 configuration, etc.) on those systems and report back here. Would that be ideal? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 27 06:03:47 2008 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 89686106564A for ; Thu, 27 Mar 2008 06:03:47 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 7AD088FC1B for ; Thu, 27 Mar 2008 06:03:47 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 55A461CC060; Wed, 26 Mar 2008 23:03:47 -0700 (PDT) Date: Wed, 26 Mar 2008 23:03:47 -0700 From: Jeremy Chadwick To: freebsd-hackers@freebsd.org Message-ID: <20080327060347.GA48293@eos.sc1.parodius.com> References: <20080320131638.7E66B94C853@mx.npubs.com> <200803220937.33552.doconnor@gsoft.com.au> <20080322045846.58F8D94C804@mx.npubs.com> <20080327060049.GA47731@eos.sc1.parodius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080327060049.GA47731@eos.sc1.parodius.com> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: Vital Patches for ataraid with Intel Matrix RAID (ICH7) 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, 27 Mar 2008 06:03:47 -0000 On Wed, Mar 26, 2008 at 11:00:49PM -0700, Jeremy Chadwick wrote: > On Sat, Mar 22, 2008 at 04:58:47AM +0000, Stef Walter wrote: > > Daniel O'Connor wrote: > > > I have seen this bug in other ATA RAID implementations (VIA & Promise) > > > too. From what I can tell this part of your patch is general to all ATA > > > RAID arrays, right? > > > > Yes, a small part. The part that will write out the RAID information > > (thus updating the generation) whenever the status changes, regardless > > of whether that change takes place when the machine is off or not. > > > > Without testing, I can't be sure whether this solves the problem on > > other ataraid devices. > > I have access to many boxes that have two disks, support native Intel > MatrixRAID, and proper hot-swap backplanes. I also have access to a > Promise TX4310 card, which I can hook up to said servers (vs. using the > onboard ICH7). > > I should be able to reproduce failure scenarios (pulling disks while in > a RAID-1 configuration, etc.) on those systems and report back here. > > Would that be ideal? Off-topic: Stef, if you read mailing lists: the MX associated with memberwebs.com is still using ORDB. You need to contact said mail administrators can tell them to stop using it, because it's returning false positives for every mail delivered to that domain: : host memberwebs.com[209.66.100.222] said: 554 Service unavailable; Client host [72.20.106.3] blocked using relays.ordb.org; ordb.org was shut down on December 18, 2006. Please remove from your mailserver. (in reply to RCPT TO command) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 27 06:47:07 2008 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 F3E56106566B for ; Thu, 27 Mar 2008 06:47:06 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 7F0348FC18 for ; Thu, 27 Mar 2008 06:47:06 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JeltB-0006zQ-2t for freebsd-hackers@freebsd.org; Thu, 27 Mar 2008 06:47:05 +0000 Received: from 195.208.174.178 ([195.208.174.178]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Mar 2008 06:47:05 +0000 Received: from vadim_nuclight by 195.208.174.178 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Mar 2008 06:47:05 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Vadim Goncharov Followup-To: gmane.os.freebsd.devel.ipfw Date: Thu, 27 Mar 2008 06:46:54 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 68 Message-ID: References: <47E79636.1000909@FreeBSD.org> <47E7EAA8.7020101@elischer.org> <47EA8860.3060709@elischer.org> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 195.208.174.178 X-Comment-To: Julian Elischer User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news Cc: freebsd-ipfw@freebsd.org Subject: Re: [HEADS UP!] IPFW Ideas: possible SoC 2008 candidate X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2008 06:47:08 -0000 Hi Julian Elischer! On Wed, 26 Mar 2008 10:31:12 -0700; Julian Elischer wrote about 'Re: [HEADS UP!] IPFW Ideas: possible SoC 2008 candidate': >>> here are some of my ideas for ipfw changes: >> >>> 1/ redo locking so that packets do not have to get locks on the >>> structure... I have several ideas on this >> >> Currently the main need for locking arises for rule byte/packet counters. The >> easiest short-term solution > The main need for locking is that the rules can be changed while a > processor is traversing the rule set. Oh, I haven't finished the letter. I wanted to say that easiest short-term solution would be splitting main ruleset lock into 2 locks: one for ruleset and one for counters, and wrap the only "f->*cnt +=" with that locks. >>> 2/ allow separate firewalls to be used at different parts of the >>> network stack (i.e allow multiple taboe sto co-exist) > there are many places that ipfw is currently callable from. > ip_input(), ip_output(), ether_demux(), if_brige, ether_output() > it would be interesting tobe able to have differnt firewalls in these > places (possibly per interface) so that state (e.g. keep_state) > can be kept seprately for one place then from another. > for example you may not want the result of 'keep state' on an > external interface to necessarily affect what happens to > packets from the same session when viewed traversing an internal > interface. > Currently on my more complex ipfw rule sets I break the rule sets out > so that packets in different places traverse different rules > but it would be nice to have it explicitly supported. Good. That should be added to proposal in part of creation of dynamic rules in any state: by default all-shared dynamic rules should be used (to preserve POLA), and an option in rule can be specified for a specific pass/layer. >> Umm, could you explain it a little?.. >> >>> 3/ possibly keeping per CPU stats.. >> >> How that would be represented to user? > it wouldn't.. you'd add them together before presenting them. > but every time a packet changes a counter that is shared, there is a > chance that it is being altered by another processor, so if you have > fine grained locking in ipfw, you really should use atomic adds, > which are slow, or accept possibl collisions (which might be ok) > but still cause a lot of cross cpu TLB flushing. Looked at the code... oh... I was wrong above with splitting for two locks into second for counters. It merely doen't exist and counters can get corrupted just now :-) The idea to keep separate per-CPU counters *could* be just reasonable, but as O_COUNTERLIMIT is likely to be introduced, it will need to access to already combined values, which now can be just for every packet, thus invalidating whole idea. The possible solution can again lie in ruleset compiled to single area of opcodes rather than linked list. In this case counters can be made a separate from opcodes array of int64's which will be contiguous and much smaller than current opcodes/counters mix, so chances for cache misses/flushes will be much smaller too. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 27 09:15:22 2008 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 D147A1065673; Thu, 27 Mar 2008 09:15:22 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id A58998FC13; Thu, 27 Mar 2008 09:15:22 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id EBB7346B8F; Thu, 27 Mar 2008 05:15:21 -0400 (EDT) Date: Thu, 27 Mar 2008 09:15:21 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Julian Elischer In-Reply-To: <47EA8860.3060709@elischer.org> Message-ID: <20080327090909.T34007@fledge.watson.org> References: <47E79636.1000909@FreeBSD.org> <47E7EAA8.7020101@elischer.org> <47EA8860.3060709@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: vadim_nuclight@mail.ru, freebsd-hackers@freebsd.org, freebsd-ipfw@freebsd.org Subject: Re: [HEADS UP!] IPFW Ideas: possible SoC 2008 candidate 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, 27 Mar 2008 09:15:23 -0000 On Wed, 26 Mar 2008, Julian Elischer wrote: > it wouldn't.. you'd add them together before presenting them. but every time > a packet changes a counter that is shared, there is a chance that it is > being altered by another processor, so if you have fine grained locking in > ipfw, you really should use atomic adds, which are slow, or accept possibl > collisions (which might be ok) but still cause a lot of cross cpu TLB > flushing. In malloc(9) and uma(9), we maintain per-CPU stats, coalescing only for presentation, relying on soft critical sections rather than locks to pretect consistency. What's worth remembering, however, is that recent multicore machines have significantly optimized the cost of atomic operations on cache lines held for write by the current CPU, and so the cost of locking has dramatically fallen in the last few years. This re-emphasizes the importance of careful cacheline management for per-CPU data structures (particularly, don't put data written by multiple CPUs in the same cacheline if you want the benefits of per-CPU access). Where read-write locking is the best model, Stephan's recent work on rmlocks looks quite promising. In my micro-benchmarks, on recent hardware it performs extremely well on SMP for read locks, but still requires optimization for UP-compiled kernels. For stats and writable structures, such as per-CPU caches, rmlocks aren't very helpful, but when compared with replicating infrequently written data structures across many CPUs, rwlocks/rmlocks offer a much simpler and less error-prone programming model. We need to see more optimization and measurement done on rmlocks for 8.x, and the lack of full priority propagation for rwlocks has to be kept in mind. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 27 10:13:28 2008 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 C23EB106564A; Thu, 27 Mar 2008 10:13:28 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:610:652::211]) by mx1.freebsd.org (Postfix) with ESMTP id 824D28FC17; Thu, 27 Mar 2008 10:13:28 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id ACB911CCC5; Thu, 27 Mar 2008 11:13:27 +0100 (CET) Date: Thu, 27 Mar 2008 11:13:27 +0100 From: Ed Schouten To: Jeremy Chadwick Message-ID: <20080327101327.GY51074@hoeg.nl> References: <20080224145940.GA41037@eos.sc1.parodius.com> <200802241738.m1OHccfW031633@lurza.secnetix.de> <20080224200305.GA49564@eos.sc1.parodius.com> <20080224220114.GA52366@eos.sc1.parodius.com> <20080224222124.GA54599@eos.sc1.parodius.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cN+O50sc7gZAK+8F" Content-Disposition: inline In-Reply-To: <20080224222124.GA54599@eos.sc1.parodius.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: FreeBSD Hackers , Oliver Fromme Subject: Re: loader and ficl/Forth help 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, 27 Mar 2008 10:13:28 -0000 --cN+O50sc7gZAK+8F Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Jeremy Chadwick wrote: > On Sun, Feb 24, 2008 at 02:01:14PM -0800, Jeremy Chadwick wrote: > > ... I'll submit a PR for the whole thing. We can hash out > > details/improvements there. >=20 > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D121064 Any news on this? I'm using this patch on my machines at the office. I would love to see it get committed. --=20 Ed Schouten WWW: http://g-rave.nl/ --cN+O50sc7gZAK+8F Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEARECAAYFAkfrc0cACgkQ52SDGA2eCwX1fwCdF2/SX8l3ABmgwxym1ZZM//4h VkcAn2LgJAZyvg1DToPHQuGI3GH29PXt =S+Hk -----END PGP SIGNATURE----- --cN+O50sc7gZAK+8F-- From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 27 15:51:16 2008 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 23C001065670 for ; Thu, 27 Mar 2008 15:51:16 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.191]) by mx1.freebsd.org (Postfix) with ESMTP id 9FB968FC26 for ; Thu, 27 Mar 2008 15:51:15 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: by ti-out-0910.google.com with SMTP id j2so1548129tid.3 for ; Thu, 27 Mar 2008 08:51:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; bh=NZ84DYFA+TzW19phcJ5dQkgfqKqwyvLYjfmUAg77SuQ=; b=us8lChY4cfKcc2zuOYPf6+UB+kcS/iMB/TpQm/ICRvWnmz9MfHdhtIu+tUsd54J8ZKZ9z6/zCzB7TvTZCiJttTgY4k/cklOLQ9ZZTRDdJkvijLEzmUwVRgQkrz9vLEYdMoEKvOQKmLKoTMgxE8RxSGWj9bg1F/+aH9I1oO3ebHU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=XvHes/q1oTdOIZJInb7gtrUAaPjH+Ahn7vy61ERzdcwGRPyrpDNI3bs1Exejnrudo3siDE+IOUoX8LenW2GHsJHqB5/hBPgWz4PInbZ9GQW2CMZ09sJs4KLutHZAyxuJzV23ZPszERuM2BVXcsJh9ghK7blslhyYoms1UEQ6IqQ= Received: by 10.150.201.13 with SMTP id y13mr881740ybf.100.1206633072120; Thu, 27 Mar 2008 08:51:12 -0700 (PDT) Received: by 10.150.230.16 with HTTP; Thu, 27 Mar 2008 08:51:12 -0700 (PDT) Message-ID: <3c0b01820803270851x24bfe739pea0bd4fb0ebecfb0@mail.gmail.com> Date: Thu, 27 Mar 2008 11:51:12 -0400 From: "Alexander Sack" To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-drivers@freebsd.org Subject: Stupid driver build/debug questions 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, 27 Mar 2008 15:51:16 -0000 Hello: New to the FreeBSD kernel and I'm investigating a driver problem (wasn't sure what list this should go on). I was wondering how to make a driver statically built instead of a loadable module? Is this an artifact of the driver source build or the generic kernel configuration mechanism via options etc.? i.e. does a driver need to use something different than the bsd.kmod.mk template make file to build a static driver. What I am trying to do is break at attach time more easily than stepping through driver_probe_and_attach()/driver_attach_child() until the attach routine gets called. I realize I can add a kdb_enter() but I was trying to do this on a live system without rebuilding the kernel (I understand this contradicts my first question but I still want to know how to build drivers statically). Thanks! -aps -- "What lies behind us and what lies in front of us is of little concern to what lies within us." -Ralph Waldo Emerson From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 27 16:18:25 2008 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 D0312106566C for ; Thu, 27 Mar 2008 16:18:25 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 8D8708FC27 for ; Thu, 27 Mar 2008 16:18:25 +0000 (UTC) (envelope-from des@des.no) Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 3873E208C; Thu, 27 Mar 2008 17:18:23 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Adrian Penisoara" Date: Thu, 27 Mar 2008 16:40:52 +0100 References: <78cb3d3f0803101440l54384d82rf57044aa9418efdf@mail.gmail.com> Message-ID: <86prtgb0oh.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Zaphod Beeblebrox , freebsd-rc@freebsd.org Subject: Re: ZFS startup scripts 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, 27 Mar 2008 16:18:26 -0000 A little old, but - On Sat, Mar 8, 2008 at 9:53 PM, Zaphod Beeblebrox wrote: > The startup scripts for ZFS are still a little green. One issue is > that the startup script 'requires' mountcritlocal --- I assume because > it figures it requires it so that it's own filesystems will mount on > top of other local UFS ones. No, it requires mountcritlocal because it needs write access to /boot/zfs/zpool.cache and /etc/zfs/exports. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 27 17:10:58 2008 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 788F7106566C for ; Thu, 27 Mar 2008 17:10:58 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id DF4B38FC29 for ; Thu, 27 Mar 2008 17:10:57 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 27041 invoked from network); 27 Mar 2008 16:20:24 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 27 Mar 2008 16:20:24 -0000 Message-ID: <47EBD520.8050305@freebsd.org> Date: Thu, 27 Mar 2008 18:10:56 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: Robert Watson References: <47E79636.1000909@FreeBSD.org> <47E7EAA8.7020101@elischer.org> <20080325094400.I6905@fledge.watson.org> In-Reply-To: <20080325094400.I6905@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sepherosa Ziehau , freebsd-hackers@freebsd.org, araujo@freebsd.org, vadim_nuclight@mail.ru, freebsd-ipfw@freebsd.org, Julian Elischer Subject: Re: [HEADS UP!] IPFW Ideas: possible SoC 2008 candidate 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, 27 Mar 2008 17:10:58 -0000 Robert Watson wrote: > > On Tue, 25 Mar 2008, Sepherosa Ziehau wrote: > >> On Tue, Mar 25, 2008 at 1:53 AM, Julian Elischer >> wrote: >> >>> 3/ possibly keeping per CPU stats.. >> >> >> This probably is the trickest part, not difficult for non-fastforward >> case. But if fastforward is enabled, I could only imagine full >> cross-cpu states duplication. > > > FWIW, there is decreasing difference between IP fast forwarding and > regular IP processing in FreeBSD 7.x, as we perform direct dispatch by > default, so it's not just the fast forward case where full input > parallelism is possible for the firewall, and parallel firewall > processing has occurred for output since 5.3. The regular forwarding path still does a (partial) copy of each packet it forwards. This is done for the ICMP redirect functionality. Additionally it has a much larger I-cache footprint due to the full ip_input(), ip_forward() and ip_output() functions being executed. Yes, the delta is shrinking but still quite big. I think regular forwarding still hits the wall at around 300-350kpps whereas fastforward can do 500kpps up to 1mpps with a good hardware base. -- Andre From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 27 19:25:13 2008 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 BABC7106564A for ; Thu, 27 Mar 2008 19:25:13 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outF.internet-mail-service.net (outf.internet-mail-service.net [216.240.47.229]) by mx1.freebsd.org (Postfix) with ESMTP id A838B8FC17 for ; Thu, 27 Mar 2008 19:25:13 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Thu, 27 Mar 2008 17:47:27 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 241992D6004; Thu, 27 Mar 2008 12:25:12 -0700 (PDT) Message-ID: <47EBF498.9090409@elischer.org> Date: Thu, 27 Mar 2008 12:25:12 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Alexander Sack References: <3c0b01820803270851x24bfe739pea0bd4fb0ebecfb0@mail.gmail.com> In-Reply-To: <3c0b01820803270851x24bfe739pea0bd4fb0ebecfb0@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-drivers@freebsd.org Subject: Re: Stupid driver build/debug questions 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, 27 Mar 2008 19:25:13 -0000 Alexander Sack wrote: > Hello: > > New to the FreeBSD kernel and I'm investigating a driver problem > (wasn't sure what list this should go on). > > I was wondering how to make a driver statically built instead of a > loadable module? Is this an artifact of the driver source build or > the generic kernel configuration mechanism via options etc.? i.e. > does a driver need to use something different than the bsd.kmod.mk > template make file to build a static driver. > > What I am trying to do is break at attach time more easily than > stepping through driver_probe_and_attach()/driver_attach_child() until > the attach routine gets called. I realize I can add a kdb_enter() but > I was trying to do this on a live system without rebuilding the kernel > (I understand this contradicts my first question but I still want to > know how to build drivers statically). put the filennames in /sys/conf/files or files.i386 (or whatever) at one stage you could also have a files.{CONFIGNAME} but I haven't tried that for a long time. > > Thanks! > > -aps > From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 27 19:52:39 2008 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 4E4A51065676 for ; Thu, 27 Mar 2008 19:52:39 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.237]) by mx1.freebsd.org (Postfix) with ESMTP id ECC698FC13 for ; Thu, 27 Mar 2008 19:52:38 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: by qb-out-0506.google.com with SMTP id a10so7949535qbd.7 for ; Thu, 27 Mar 2008 12:52:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=v3fLq7AcFlwF1CfhZs5TIQX/3aS1ipFqOlYKh1b94z8=; b=KVrKl+ktO03zeyJ++KHA0cBDXTjAV891RTWQHFLuVaBHdMB9nN7qUoXvWzzvktQcztdtWwNj1eDhbu9ESAmeeaZ18VcDmGsKdvgDprHUAaGNkJQhS2FONR4fzmB5ncc3PEV+QdpK0px/D0U0OggFQx+8Y9LgvtOsp5K+YPis1Ss= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=tZRD/IjlO+7bifnQjjV/oZBbFHhH8aEH4N9IAFUpm5Jql2uDwRZtN8Wbi+MulRxDPQuulWVbvMFCghHxKYXyR5eUHz4cn1+q0yOLb34pD60bAeHpEnLTV/KBIztyNZD+y5hudPpOZ9JRi9e9HkdPr86hWCjopfQ5kgPRx001r6g= Received: by 10.142.172.12 with SMTP id u12mr1739497wfe.16.1206647557589; Thu, 27 Mar 2008 12:52:37 -0700 (PDT) Received: by 10.142.147.6 with HTTP; Thu, 27 Mar 2008 12:52:37 -0700 (PDT) Message-ID: <3c0b01820803271252m488159ebi2af2255461f10358@mail.gmail.com> Date: Thu, 27 Mar 2008 15:52:37 -0400 From: "Alexander Sack" To: "Julian Elischer" In-Reply-To: <47EBF498.9090409@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3c0b01820803270851x24bfe739pea0bd4fb0ebecfb0@mail.gmail.com> <47EBF498.9090409@elischer.org> Cc: freebsd-hackers@freebsd.org, freebsd-drivers@freebsd.org Subject: Re: Stupid driver build/debug questions 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, 27 Mar 2008 19:52:39 -0000 On Thu, Mar 27, 2008 at 3:25 PM, Julian Elischer wrote: > Alexander Sack wrote: > > Hello: > > > > New to the FreeBSD kernel and I'm investigating a driver problem > > (wasn't sure what list this should go on). > > > > I was wondering how to make a driver statically built instead of a > > loadable module? Is this an artifact of the driver source build or > > the generic kernel configuration mechanism via options etc.? i.e. > > does a driver need to use something different than the bsd.kmod.mk > > template make file to build a static driver. > > > > What I am trying to do is break at attach time more easily than > > stepping through driver_probe_and_attach()/driver_attach_child() until > > the attach routine gets called. I realize I can add a kdb_enter() but > > I was trying to do this on a live system without rebuilding the kernel > > (I understand this contradicts my first question but I still want to > > know how to build drivers statically). > > put the filennames in /sys/conf/files or files.i386 (or whatever) > > at one stage you could also have a files.{CONFIGNAME} but I haven't > tried that for a long time. Thanks for the response. I will try this but I do have an obvious question, the build scripts do not need to be edited at all with the extra directory/files? It will just pickup my driver directory and link against the kernel automagically? -aps -- "What lies behind us and what lies in front of us is of little concern to what lies within us." -Ralph Waldo Emerson From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 27 20:39:32 2008 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 CC10E1065670 for ; Thu, 27 Mar 2008 20:39:32 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by mx1.freebsd.org (Postfix) with ESMTP id 49E5B8FC17 for ; Thu, 27 Mar 2008 20:39:31 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so2097933nfb.33 for ; Thu, 27 Mar 2008 13:39:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=XNRuu0CJhtx+RJK3DZl8FmECE2P/3XXVr67nEWUjBdM=; b=lYkLSDe/dgEDJ0zBKAF2Q5I/NPe6quQc5+St5mElWuIiD6tdalG4ArfH1omZtLmzuNtLInrh6k603Tojx32yots6JyTFYC3eUdjwnVzb634UcAzF2iA8U/a1AOmgBS9dLqWdqY88Q2WRfAhKQiozENStuBsxR+mfNTZUDB0ju1w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=F9z1xfEl09LWMoxCt7IqwCNoOSyywZt4VJXV0L+2tQaZGSbmkCjhOXXMRyXVbblegn4Qy0NRgmlgSlh24xpVB5rk80lvse5cyNv0OcwK7OV/q7HW4k1lyqQvAjpCBFYU8tpk/YUKZeSy7PEVgqE0gQAU3+h/EbSTaY8oTPls4vo= Received: by 10.78.68.18 with SMTP id q18mr4913491hua.72.1206650353558; Thu, 27 Mar 2008 13:39:13 -0700 (PDT) Received: by 10.78.53.4 with HTTP; Thu, 27 Mar 2008 13:39:13 -0700 (PDT) Message-ID: Date: Thu, 27 Mar 2008 23:39:13 +0300 From: pluknet To: "Alexander Sack" In-Reply-To: <3c0b01820803271252m488159ebi2af2255461f10358@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3c0b01820803270851x24bfe739pea0bd4fb0ebecfb0@mail.gmail.com> <47EBF498.9090409@elischer.org> <3c0b01820803271252m488159ebi2af2255461f10358@mail.gmail.com> Cc: freebsd-hackers@freebsd.org, Julian Elischer , freebsd-drivers@freebsd.org Subject: Re: Stupid driver build/debug questions 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, 27 Mar 2008 20:39:32 -0000 On 27/03/2008, Alexander Sack wrote: > On Thu, Mar 27, 2008 at 3:25 PM, Julian Elischer wrote: > > Alexander Sack wrote: > > > Hello: > > > > > > New to the FreeBSD kernel and I'm investigating a driver problem > > > (wasn't sure what list this should go on). > > > > > > I was wondering how to make a driver statically built instead of a > > > loadable module? Is this an artifact of the driver source build or > > > the generic kernel configuration mechanism via options etc.? i.e. > > > does a driver need to use something different than the bsd.kmod.mk > > > template make file to build a static driver. > > > > > > What I am trying to do is break at attach time more easily than > > > stepping through driver_probe_and_attach()/driver_attach_child() until > > > the attach routine gets called. I realize I can add a kdb_enter() but > > > I was trying to do this on a live system without rebuilding the kernel > > > (I understand this contradicts my first question but I still want to > > > know how to build drivers statically). > > > > put the filennames in /sys/conf/files or files.i386 (or whatever) > > > > at one stage you could also have a files.{CONFIGNAME} but I haven't > > tried that for a long time. > > > Thanks for the response. I will try this but I do have an obvious > question, the build scripts do not need to be edited at all with the > extra directory/files? It will just pickup my driver directory and > link against the kernel automagically? Yes, It will if you add them to standard files list (see conf/files). (Otherwise if you want it as options directive in your kernel config than you should mark its module name in conf/files and also put an appropriate record into conf/options). - pluknet From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 27 21:05:25 2008 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 333B41065671 for ; Thu, 27 Mar 2008 21:05:25 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by mx1.freebsd.org (Postfix) with ESMTP id 04F868FC20 for ; Thu, 27 Mar 2008 21:05:24 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: by wf-out-1314.google.com with SMTP id 25so4031809wfa.7 for ; Thu, 27 Mar 2008 14:05:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=hEJiW4kRPyNTGzHFYFkojk4UZOp9Wc3JtQGZ5dDmPLQ=; b=fAJS2JCJqcrmfbddTZ1oKoJzpn4gExn7EPiZf3NUbV0wv5FI80+zIAD6uM+/8LKf6bP/lgRZaNNJr8Cw/ol5WLEeY7Q50qPEq7EBu+EShTt4p97s/Se60qDrCtBZNrKGXwhmpoIrBN7lqlKDuL8qG3pL9QQ5DBBIJQQvWNccwp4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aUOZYWTL1TREI6izI9/WnOurmfQ8yj7w09Q4xZaiubY/kQ6G0WbW4qrnWD99Lui1kjEcrr8HF4X14OQ57QjIC1hU7zNhyRR2oKBmM9fJlUU582Sy8kEkdK8q6fQDDVjlPiov8q43jPSyOJSO4D26HuYZlys9bMqiVzC1+3/5kHo= Received: by 10.142.43.7 with SMTP id q7mr1816811wfq.67.1206651924605; Thu, 27 Mar 2008 14:05:24 -0700 (PDT) Received: by 10.142.147.6 with HTTP; Thu, 27 Mar 2008 14:05:24 -0700 (PDT) Message-ID: <3c0b01820803271405r2351cbbwb20b8b35c5621dcb@mail.gmail.com> Date: Thu, 27 Mar 2008 17:05:24 -0400 From: "Alexander Sack" To: pluknet In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3c0b01820803270851x24bfe739pea0bd4fb0ebecfb0@mail.gmail.com> <47EBF498.9090409@elischer.org> <3c0b01820803271252m488159ebi2af2255461f10358@mail.gmail.com> Cc: freebsd-hackers@freebsd.org, Julian Elischer , freebsd-drivers@freebsd.org Subject: Re: Stupid driver build/debug questions 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, 27 Mar 2008 21:05:25 -0000 On Thu, Mar 27, 2008 at 4:39 PM, pluknet wrote: > > On 27/03/2008, Alexander Sack wrote: > > On Thu, Mar 27, 2008 at 3:25 PM, Julian Elischer wrote: > > > Alexander Sack wrote: > > > > Hello: > > > > > > > > New to the FreeBSD kernel and I'm investigating a driver problem > > > > (wasn't sure what list this should go on). > > > > > > > > I was wondering how to make a driver statically built instead of a > > > > loadable module? Is this an artifact of the driver source build or > > > > the generic kernel configuration mechanism via options etc.? i.e. > > > > does a driver need to use something different than the bsd.kmod.mk > > > > template make file to build a static driver. > > > > > > > > What I am trying to do is break at attach time more easily than > > > > stepping through driver_probe_and_attach()/driver_attach_child() until > > > > the attach routine gets called. I realize I can add a kdb_enter() but > > > > I was trying to do this on a live system without rebuilding the kernel > > > > (I understand this contradicts my first question but I still want to > > > > know how to build drivers statically). > > > > > > put the filennames in /sys/conf/files or files.i386 (or whatever) > > > > > > at one stage you could also have a files.{CONFIGNAME} but I haven't > > > tried that for a long time. > > > > > > Thanks for the response. I will try this but I do have an obvious > > question, the build scripts do not need to be edited at all with the > > extra directory/files? It will just pickup my driver directory and > > link against the kernel automagically? > > Yes, It will if you add them to standard files list (see conf/files). > (Otherwise if you want it as options directive in your kernel config > than you should mark its module name in conf/files and also put > an appropriate record into conf/options). Thank you very much, that is what I thought regarding it as an options directive instead of a driver - I just wanted some validation before going down that path. Again, thanks guys, -aps -- "What lies behind us and what lies in front of us is of little concern to what lies within us." -Ralph Waldo Emerson From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 28 14:38:01 2008 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 3E1EC106566B; Fri, 28 Mar 2008 14:38:01 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id A3D198FC21; Fri, 28 Mar 2008 14:38:00 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id B62B5744026; Fri, 28 Mar 2008 16:37:58 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWnMpGNfeIFZ; Fri, 28 Mar 2008 16:37:58 +0200 (EET) Received: from [10.2.1.87] (gateway.cybervisiontech.com.ua [88.81.251.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 3A6B243C725; Fri, 28 Mar 2008 16:37:58 +0200 (EET) Message-ID: <47ED02C5.5090804@icyb.net.ua> Date: Fri, 28 Mar 2008 16:37:57 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.12 (X11/20080311) MIME-Version: 1.0 To: John Baldwin References: <47B96989.6070008@icyb.net.ua> <47C918B7.9040504@icyb.net.ua> <47EBCF32.9000705@icyb.net.ua> <200803271408.24684.jhb@freebsd.org> In-Reply-To: <200803271408.24684.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Nate Lawson Subject: Re: kobj method signature checking 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, 28 Mar 2008 14:38:01 -0000 on 27/03/2008 20:08 John Baldwin said the following: > On Thursday 27 March 2008 12:45:38 pm Andriy Gapon wrote: >> on 01/03/2008 10:49 Andriy Gapon said the following: >>> Here's one strange thing - in your patch you accidentally have >>> parameters of device_identify switched, I initially inherited that bug >>> too. I got no error/warning from compiler whatsoever. It wasn't until I >>> saw that device_get_unit(parent) returned garbage that I my untrained >>> eye noticed the mistake. >> As this thread died off I just want to make sure that the above issue is >> not lost. >> Maybe we should modify KOBJMETHOD(NAME, FUNC) macro to somehow check >> FUNC signature/type against the expected signature/type (which is >> available as NAME##_t)? > > It would be nice if we could do that, yes. > >> Maybe something like the following (a bit ugly but I couldn't think of >> anything better and syntactically correct): >> { &NAME##_desc, (kobjop_t) (FUNC != (NAME##_t *)NULL ? FUNC : NULL) } >> >> This is supposed to produce the following warning if FUNC and NAME##_t >> have different types: >> warning: comparison of distinct pointer types lacks a cast >> >> The message is also not very descriptive. > > A compile warning/error would be nice though. Then the proposed code should be good enough. That is: #define KOBJMETHOD(NAME, FUNC) \ { &NAME##_desc, (kobjop_t) (FUNC != (NAME##_t *)NULL ? FUNC : NULL) } BTW, the expression is an obvious NOP and I think that the compiler is required to calculate constant initializer expressions at compile time, so binary wise there should not be any incompatibilities too. >> P.S. strangely enough for me it seems that compiler treats the following >> two declarations differently: >> int f(); >> and >> int f(void); >> The warning appears for the latter when comparing with e.g. int g(int), >> but does not appear for the former. > > This is normal for C. :( > -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 28 15:07:34 2008 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 45A191065671; Fri, 28 Mar 2008 15:07:34 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id AC6DF8FC18; Fri, 28 Mar 2008 15:07:33 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 887A0744026; Fri, 28 Mar 2008 17:07:32 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZtdDlDsjqA8; Fri, 28 Mar 2008 17:07:32 +0200 (EET) Received: from [10.2.1.87] (gateway.cybervisiontech.com.ua [88.81.251.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 19B1A43C725; Fri, 28 Mar 2008 17:07:32 +0200 (EET) Message-ID: <47ED09B3.9010309@icyb.net.ua> Date: Fri, 28 Mar 2008 17:07:31 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.12 (X11/20080311) MIME-Version: 1.0 To: John Baldwin References: <47B96989.6070008@icyb.net.ua> <47C918B7.9040504@icyb.net.ua> <47EBCF32.9000705@icyb.net.ua> <200803271408.24684.jhb@freebsd.org> <47ED02C5.5090804@icyb.net.ua> In-Reply-To: <47ED02C5.5090804@icyb.net.ua> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org, Nate Lawson Subject: Re: kobj method signature checking 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, 28 Mar 2008 15:07:34 -0000 on 28/03/2008 16:37 Andriy Gapon said the following: > on 27/03/2008 20:08 John Baldwin said the following: >> On Thursday 27 March 2008 12:45:38 pm Andriy Gapon wrote: >>> on 01/03/2008 10:49 Andriy Gapon said the following: >>>> Here's one strange thing - in your patch you accidentally have >>>> parameters of device_identify switched, I initially inherited that bug >>>> too. I got no error/warning from compiler whatsoever. It wasn't until I >>>> saw that device_get_unit(parent) returned garbage that I my untrained >>>> eye noticed the mistake. >>> As this thread died off I just want to make sure that the above issue is >>> not lost. >>> Maybe we should modify KOBJMETHOD(NAME, FUNC) macro to somehow check >>> FUNC signature/type against the expected signature/type (which is >>> available as NAME##_t)? >> It would be nice if we could do that, yes. >> >>> Maybe something like the following (a bit ugly but I couldn't think of >>> anything better and syntactically correct): >>> { &NAME##_desc, (kobjop_t) (FUNC != (NAME##_t *)NULL ? FUNC : NULL) } >>> >>> This is supposed to produce the following warning if FUNC and NAME##_t >>> have different types: >>> warning: comparison of distinct pointer types lacks a cast >>> >>> The message is also not very descriptive. >> A compile warning/error would be nice though. > > Then the proposed code should be good enough. > That is: > #define KOBJMETHOD(NAME, FUNC) \ > { &NAME##_desc, (kobjop_t) (FUNC != (NAME##_t *)NULL ? FUNC : NULL) } > > BTW, the expression is an obvious NOP and I think that the compiler is > required to calculate constant initializer expressions at compile time, > so binary wise there should not be any incompatibilities too. And the demonstration of the code in work – the following is from 6.3 RELEASE kernel build (plus the above change): /usr/src/sys/dev/acpica/acpi_pcib_acpi.c:109: warning: comparison of distinct pointer types lacks a cast /usr/src/sys/dev/acpica/acpi_pcib_acpi.c:110: warning: comparison of distinct pointer types lacks a cast *** Error code 1 This is because pcib_read_config_t is defined to have several parameters of "u_int" type and acpi_pcib_read_config has "int" for them. Ditto for acpi_pcib_write_config and pcib_write_config_t. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 28 18:14:42 2008 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 EBFE91065673 for ; Fri, 28 Mar 2008 18:14:42 +0000 (UTC) (envelope-from shannon@widomaker.com) Received: from wilma.widomaker.com (wilma.widomaker.com [204.17.220.5]) by mx1.freebsd.org (Postfix) with ESMTP id BDE228FC1C for ; Fri, 28 Mar 2008 18:14:42 +0000 (UTC) (envelope-from shannon@widomaker.com) Received: from [69.72.100.77] (helo=escape.goid.lan) by wilma.widomaker.com with esmtp (Exim 3.36 #1) id 1JfIpX-0001BC-00 for freebsd-hackers@freebsd.org; Fri, 28 Mar 2008 13:57:32 -0400 Received: from cray.goid.lan (cray.goid.lan [192.168.1.11]) by escape.goid.lan (Postfix) with ESMTP id DF0FFA505 for ; Fri, 28 Mar 2008 13:57:27 -0400 (EDT) Message-Id: <1BD42692-F8C2-4F37-BDA6-619B95474065@widomaker.com> From: Shannon Hendrix To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 28 Mar 2008 13:57:30 -0400 X-Mailer: Apple Mail (2.919.2) X-Mailman-Approved-At: Fri, 28 Mar 2008 18:18:44 +0000 Subject: Using any network interface whatsoever 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, 28 Mar 2008 18:14:43 -0000 From mailing list archives: > I wrote some add-on bits for /etc/rc.network in 4.x that compares > the link addresses of attached network interfaces to a list of link > addresses, then sets ifconfig_ifN* variables accordingly before > rc.network does anything. It provides a means of wiring IP addresses > to physical ports in a way that gets around the problem of probe > order. If there's interest, I'll get to work on an rcNG version. I would be interested in seeing this. I build custom machines for a company I work for, and one of our requirements is the ability to number the network ports. End users configure our software based on which port they use, so we need steady numbering of the ports, even when one customer machine might have different cards and number of cards. We basically want the order to be: 0-N motherboard ports N+1 -> M card ports It sounds like your script might work, given the apparent absence of geographic mapping in most current systems. Thanks for any help. -- "Where some they sell their dreams for small desires." From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 28 18:26:21 2008 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 DD7B9106564A for ; Fri, 28 Mar 2008 18:26:21 +0000 (UTC) (envelope-from majorppk@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by mx1.freebsd.org (Postfix) with ESMTP id 2D2AD8FC1D for ; Fri, 28 Mar 2008 18:26:21 +0000 (UTC) (envelope-from majorppk@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so414313waf.3 for ; Fri, 28 Mar 2008 11:26:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:subject:from:reply-to:to:disposition-notification-to:x-priority:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; bh=hr+T+Rl0WfPVE8/xLRazNIaY2sjeRl3NEhkfNx3QA2Q=; b=bLZzYw3aEUbrn4Z33nK47mEIClaB/RYgn+2jyH0qdQhXFp40hj0Qo9ioCPHXZMloqiKaXYkiiRtZemuTezRCkMfozomK1Umg1Hs5ZIJzLKUyw63yOPfkT242yjekDUbYrKDci/06N3DatXxLef9yE2tNocy5I2EhxgqNcTUz15c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=subject:from:reply-to:to:disposition-notification-to:x-priority:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=ITL12HkrLcfQxmYhj5eomALADODtRjtC5qMXLyciIFTBBL4a1EttiMEb0vYwqgJUBF2H26JuszcCg/7W45MMczlwUDokUwIo4GMo9RkK29UuMJL30dNC6TY31RR/3aKdkIo+OkxZGTV6wq9uApsPSYXkSvdMi734YmU8P9kyXow= Received: by 10.114.154.1 with SMTP id b1mr4337545wae.34.1206727137219; Fri, 28 Mar 2008 10:58:57 -0700 (PDT) Received: from ?123.201.115.108? ( [123.201.115.108]) by mx.google.com with ESMTPS id m28sm1755030waf.20.2008.03.28.10.58.53 (version=SSLv3 cipher=RC4-MD5); Fri, 28 Mar 2008 10:58:55 -0700 (PDT) From: Lt Col Prashant To: hackers@FreeBSD.org X-Priority: 1 Content-Type: text/plain Date: Fri, 28 Mar 2008 23:31:42 +0530 Message-Id: <1206727302.4326.3.camel@swati> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-1.fc8) Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 28 Mar 2008 18:32:55 +0000 Cc: Subject: HELP TO INSTALL FreeBSD 7.0 ON LAPTOP ACER 5102 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: majorppk@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2008 18:26:22 -0000 Dear Sir, I was in need of some help with FreeBSD.I've installed FreeBSD 7.0 on my LAPTOP ACER 5102. However, I have the following issues unresolved, At the terminal prompt I cannot use the su command. I am unable to activate the services from the administration of gnome. I also am not able to use the DVD, since it is not detected. I also want to configure the ADSL Modem which is through the ethernet card. How do I get the Bison Web Cam working. I also am not able to use the bluetooth. Can you help. Thanks From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 28 19:43:05 2008 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 97F761065683 for ; Fri, 28 Mar 2008 19:43:05 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe11.swipnet.se [212.247.155.65]) by mx1.freebsd.org (Postfix) with ESMTP id 00E198FC12 for ; Fri, 28 Mar 2008 19:43:04 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [62.113.132.89] (account mc467741@c2i.net [62.113.132.89] verified) by mailfe11.swip.net (CommuniGate Pro SMTP 5.1.13) with ESMTPA id 701846813; Fri, 28 Mar 2008 20:43:03 +0100 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org, majorppk@gmail.com Date: Fri, 28 Mar 2008 20:44:07 +0100 User-Agent: KMail/1.9.7 References: <1206727302.4326.3.camel@swati> In-Reply-To: <1206727302.4326.3.camel@swati> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803282044.08748.hselasky@c2i.net> Cc: hackers@freebsd.org Subject: Re: HELP TO INSTALL FreeBSD 7.0 ON LAPTOP ACER 5102 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, 28 Mar 2008 19:43:05 -0000 On Friday 28 March 2008, Lt Col Prashant wrote: > Dear Sir, > I was in need of some help with FreeBSD.I've installed FreeBSD > 7.0 on my LAPTOP ACER 5102. However, I have the following issues > unresolved, > At the terminal prompt I cannot use the su command. > I am unable to activate the services from the > administration of gnome. I also am not able to use the DVD, since it is > not detected. > I also want to configure the ADSL Modem which is through > the ethernet card. How do I get the Bison Web Cam working. I also am not > able to use the bluetooth. > Can you help. > > Thanks http://www.freebsd.org/doc/en/books/handbook/network-bluetooth.html For bluetooth you need to do: kldload netgraph kldload ng_btsocket kldload ng_socket kldload ng_bluetooth kldload ng_hci kldload ng_ubt /etc/rc.d/bluetooth start ubt0 /etc/rc.d/bluetooth start ubt0 hccontrol -n ubt0hci inquiry Also see /usr/ports/comms/obexapp --HPS From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 28 20:43:07 2008 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 9987A1065670 for ; Fri, 28 Mar 2008 20:43:07 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe11.tele2.se [212.247.155.65]) by mx1.freebsd.org (Postfix) with ESMTP id 3020F8FC14 for ; Fri, 28 Mar 2008 20:43:06 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [62.113.132.89] (account mc467741@c2i.net [62.113.132.89] verified) by mailfe11.swip.net (CommuniGate Pro SMTP 5.1.13) with ESMTPA id 701846813; Fri, 28 Mar 2008 20:43:03 +0100 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org, majorppk@gmail.com Date: Fri, 28 Mar 2008 20:44:07 +0100 User-Agent: KMail/1.9.7 References: <1206727302.4326.3.camel@swati> In-Reply-To: <1206727302.4326.3.camel@swati> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803282044.08748.hselasky@c2i.net> Cc: hackers@freebsd.org Subject: Re: HELP TO INSTALL FreeBSD 7.0 ON LAPTOP ACER 5102 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, 28 Mar 2008 20:43:07 -0000 On Friday 28 March 2008, Lt Col Prashant wrote: > Dear Sir, > I was in need of some help with FreeBSD.I've installed FreeBSD > 7.0 on my LAPTOP ACER 5102. However, I have the following issues > unresolved, > At the terminal prompt I cannot use the su command. > I am unable to activate the services from the > administration of gnome. I also am not able to use the DVD, since it is > not detected. > I also want to configure the ADSL Modem which is through > the ethernet card. How do I get the Bison Web Cam working. I also am not > able to use the bluetooth. > Can you help. > > Thanks http://www.freebsd.org/doc/en/books/handbook/network-bluetooth.html For bluetooth you need to do: kldload netgraph kldload ng_btsocket kldload ng_socket kldload ng_bluetooth kldload ng_hci kldload ng_ubt /etc/rc.d/bluetooth start ubt0 /etc/rc.d/bluetooth start ubt0 hccontrol -n ubt0hci inquiry Also see /usr/ports/comms/obexapp --HPS From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 29 02:19:55 2008 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 498D8106564A for ; Sat, 29 Mar 2008 02:19:55 +0000 (UTC) (envelope-from tobias.fendin@glocalnet.net) Received: from mta2.glocalnet.net (mta2.glocalnet.net [213.163.128.209]) by mx1.freebsd.org (Postfix) with ESMTP id 0BA648FC15 for ; Sat, 29 Mar 2008 02:19:55 +0000 (UTC) (envelope-from tobias.fendin@glocalnet.net) Received: from asator.illumnati.sytes.net (84.217.120.74) by mta2.glocalnet.net (7.3.130) (authenticated as tobias.fendin@glocalnet.net) id 47A097200080E067; Sat, 29 Mar 2008 02:59:18 +0100 Message-ID: <47EDA271.7010700@glocalnet.net> Date: Sat, 29 Mar 2008 02:59:13 +0100 From: Tobias Fendin User-Agent: Thunderbird 2.0.0.6 (X11/20071028) MIME-Version: 1.0 To: majorppk@gmail.com References: <1206727302.4326.3.camel@swati> In-Reply-To: <1206727302.4326.3.camel@swati> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: HELP TO INSTALL FreeBSD 7.0 ON LAPTOP ACER 5102 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, 29 Mar 2008 02:19:55 -0000 Lt Col Prashant wrote: > Dear Sir, > I was in need of some help with FreeBSD.I've installed FreeBSD > 7.0 on my LAPTOP ACER 5102. However, I have the following issues > unresolved, > At the terminal prompt I cannot use the su command. > I am unable to activate the services from the > administration of gnome. I also am not able to use the DVD, since it is > not detected. > I also want to configure the ADSL Modem which is through > the ethernet card. How do I get the Bison Web Cam working. I also am not > able to use the bluetooth. > Can you help. > > Thanks > > _______________________________________________ > 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" > > OH, PLEASE GOD, ASK misc@ From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 29 11:26:40 2008 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 8244F1065671 for ; Sat, 29 Mar 2008 11:26:40 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 599298FC20 for ; Sat, 29 Mar 2008 11:26:40 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 599E046B85; Sat, 29 Mar 2008 07:26:39 -0400 (EDT) Date: Sat, 29 Mar 2008 11:26:39 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Tobias Fendin In-Reply-To: <47EDA271.7010700@glocalnet.net> Message-ID: <20080329112602.W38373@fledge.watson.org> References: <1206727302.4326.3.camel@swati> <47EDA271.7010700@glocalnet.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, majorppk@gmail.com Subject: Re: HELP TO INSTALL FreeBSD 7.0 ON LAPTOP ACER 5102 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, 29 Mar 2008 11:26:40 -0000 On Sat, 29 Mar 2008, Tobias Fendin wrote: > OH, PLEASE GOD, ASK misc@ I'm guessing you mean questions@, but yes, this question is probably best addressed to questions@FreeBSD.org. Robert N M Watson Computer Laboratory University of Cambridge