From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 24 12:37:41 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E1AA16A4CE for ; Sat, 24 Jan 2004 12:37:41 -0800 (PST) Received: from dust.freshx.de (freshx.de [80.190.100.215]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6047E43D3F for ; Sat, 24 Jan 2004 12:37:40 -0800 (PST) (envelope-from kai@freshx.de) Received: from localhost (unknown [127.0.0.1]) by dust.freshx.de (Postfix) with ESMTP id F002515E32D; Sat, 24 Jan 2004 21:37:30 +0100 (CET) Received: from localhost (unknown [127.0.0.1]) by dust.freshx.de (Postfix) with ESMTP id 3487115E305; Sat, 24 Jan 2004 21:37:30 +0100 (CET) Received: from 127.0.0.1 ( [127.0.0.1]) as user dust0005@localhost by localhost with HTTP; Sat, 24 Jan 2004 21:37:30 +0100 Message-ID: <1074976650.4012d78a1aae3@localhost> Date: Sat, 24 Jan 2004 21:37:30 +0100 From: kai@freshx.de To: =?ISO-8859-1?B?RGFnLUVybGluZyBTbfhyZ3Jhdg==?= References: <1074970937.4012c1394eba7@localhost> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.0 X-Virus-Scanned: by AMaViS 0.3.12 X-Mailman-Approved-At: Sun, 25 Jan 2004 06:00:31 -0800 cc: hackers@freebsd.org cc: sapdb@komadev.de Subject: Re: strange "less" behaviour on big files X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2004 20:37:41 -0000 Zitat von Dag-Erling Smørgrav : > Kai Mosebach writes: > > i lessed a 1.0 gig file filled with zeros and less seems to slurp in > > as much as it can get at one time! > > AFAIK, it tries to read one entire line; since your file doesn't > contain any line feed characters, it ends up reading the entire file. > > DES > -- > Dag-Erling Smørgrav - des@des.no > > Yeah, thought of something like this, because on "real" binary files you get asked, if you want to show the binary file, on the zero file not. Still strange though, that 4.9 has no problem with it ... From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 24 13:12:13 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A5BA16A4CE; Sat, 24 Jan 2004 13:12:13 -0800 (PST) Received: from mta06-svc.ntlworld.com (mta06-svc.ntlworld.com [62.253.162.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 871DF43D2D; Sat, 24 Jan 2004 13:12:11 -0800 (PST) (envelope-from S@mSmith.net) Received: from sebastian.foriru.co.uk ([213.106.181.8]) by mta06-svc.ntlworld.comESMTP <20040124211211.OGLS22499.mta06-svc.ntlworld.com@sebastian.foriru.co.uk>; Sat, 24 Jan 2004 21:12:11 +0000 Received: from sebastian.foriru.co.uk (localhost [127.0.0.1]) i0OLCN9x019032 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Sat, 24 Jan 2004 21:12:23 GMT Received: from localhost (sams@localhost)i0OLCNu9019872; Sat, 24 Jan 2004 21:12:23 GMT X-Authentication-Warning: sebastian.foriru.co.uk: sams owned process doing -bs Date: Sat, 24 Jan 2004 21:12:23 +0000 (GMT) From: Sam Smith X-X-Sender: sams@sebastian.foriru.co.uk To: Robert Watson In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Sun, 25 Jan 2004 06:00:31 -0800 cc: Max Laier cc: hackers@freebsd.org Subject: Re: XL driver checksum producing corrupted but checksum-correct packets X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2004 21:12:13 -0000 On Sat, 24 Jan 2004, Robert Watson wrote: > On Sat, 24 Jan 2004, Max Laier wrote: > > On Saturday 24 January 2004 17:06, Robert Watson wrote: > > > On Fri, 23 Jan 2004, Matthew Dillon wrote: > > > > I tracked down an occassional buildworld failure on DragonFly to > > > > my XL driver, which is synchronized to 4.x's XL driver. > > > > FYI: This was reproduced on OpenBSD as well (w/ ftp and scp): > > http://marc.theaimsgroup.com/?l=openbsd-tech&m=107494884327698&w=2 > > Two thoughts on other things to try, with that in mind: The thread on the OpenBSD list now contains a patch which seems to fix the problem (for me, on OpenBSD, shifting data by both NFS and ftp doing md5 checksums on the files at both ends). Although it doesn't seem to turn off hardware checksums (which is what I think it should do). Regards Sam -- Murphy's revenge: The more reliable you make a system, the longer it will take you to figure out what's wrong when it breaks. From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 24 14:43:54 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F7D816A4CE for ; Sat, 24 Jan 2004 14:43:54 -0800 (PST) Received: from chococat.sd.dreamhost.com (chococat.sd.dreamhost.com [66.33.206.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id E67A643D48 for ; Sat, 24 Jan 2004 14:43:53 -0800 (PST) (envelope-from erek@necrotec.com) Received: from webmail.necrotec.com (localhost [127.0.0.1]) by chococat.sd.dreamhost.com (Postfix) with SMTP id CDDAAFA39 for ; Sat, 24 Jan 2004 14:43:53 -0800 (PST) Received: from 216.9.170.43 (SquirrelMail authenticated user erek@necrotec.com) by webmail.necrotec.com with HTTP; Sat, 24 Jan 2004 14:43:53 -0800 (PST) Message-ID: <49251.216.9.170.43.1074984233.spork@webmail.necrotec.com> Date: Sat, 24 Jan 2004 14:43:53 -0800 (PST) From: "erek" To: hackers@freebsd.org User-Agent: DreamHost Webmail MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Sun, 25 Jan 2004 06:00:31 -0800 Subject: Re: Re: FreeBSD 5.2-RELEASE buildworld failure. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2004 22:43:54 -0000 sed version is 1.35 and parse.c / parse+%DIKED.c are indeed different From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 24 20:30:44 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3241E16A4CE for ; Sat, 24 Jan 2004 20:30:44 -0800 (PST) Received: from cowbert.2y.net (d46h180.public.uconn.edu [137.99.46.180]) by mx1.FreeBSD.org (Postfix) with SMTP id 822E843D4C for ; Sat, 24 Jan 2004 20:30:40 -0800 (PST) (envelope-from sirmoo@cowbert.2y.net) Received: (qmail 29270 invoked by uid 1001); 25 Jan 2004 04:30:39 -0000 Date: Sat, 24 Jan 2004 23:30:39 -0500 From: "Peter C. Lai" To: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org, freebsd-ports@freebsd.org Message-ID: <20040125043039.GG311@cowbert.2y.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Mailman-Approved-At: Sun, 25 Jan 2004 06:00:31 -0800 cc: sirmoo@cowbert.2y.net Subject: lpt0 blocking i/o causes ghostscript to hang system X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: peter.lai@uconn.edu List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2004 04:30:44 -0000 Hi. I have this peculiar issue with printing to lpt0 with ghostscript-gnu 7.05. I'm running stock lpd(1) with a handwritten input filter. If I am printing a huge file (such that the printer can't buffer all of the document at once and I am spooling to the printer as the printer is printing), and the printer starts blocking i/o (due to paper jam/paper out/etc), the ghostscript hangs the system until I unblock the parport (by remedying the condition, or hitting the "retry" button on the printer). It appears that ghostscript attempting to pipe its output trips interupts to the point that all of the cpu is taken up and the system will stop responding until the printer unblocks lpt0. My input filter is: #!/bin/sh exec 3>&1 1>&2 GS=/usr/local/bin/gs GS_FONTPATH=/usr/local/share/ghostscript/fonts:\ /usr/local/share/ghostscript/7.05/lib export GS GS_FONTPATH $GS -q -dNOPAUSE -dSAFER -sDEVICE=ljet4 -sOutputFile=/dev/fd/3 - && exit 0 exit 2 Now, if I don't use gs, and just use cat(1) as my passthrough filter like this: #!/bin/sh exec 3>&1 1>&2 /bin/cat 1>&3 && exit 0 exit 2 When i/o on lpt0 is blocking in this case, cat(1) will quietly sit there until such time that lpt0 can be written to again. I believe this is because cat(1) buffers its output. Right now my solution is to have ghostscript's -sOutputFile=\|"/usr/bin/lpr -h \ -Pbuffer" where a printcap(5) entry for the "buffer" printer's device is lpt0 and has an input filter that uses cat(1) (just like above). Here, gs will output the processed job to a "buffer" spool before any i/o is outbound to lpt0. Any of you run into this problem at all? It was seriously bugging me until I devised the 2 spooler system above, which adds stability to the system but feels too hackish for me. Whereas my print server is no longer hanging because someone is too lazy to put paper in it, the solution breaks my in-house web based job control system. The main culprit is gs not buffering its output; but lpd could also use a hand in "printer not-ready" detection. -- Peter C. Lai University of Connecticut Dept. of Molecular and Cell Biology Yale University School of Medicine SenseLab | Research Assistant http://cowbert.2y.net/ From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 25 07:57:33 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2091616A4CE for ; Sun, 25 Jan 2004 07:57:33 -0800 (PST) Received: from bast.unixathome.org (bast.unixathome.org [66.11.174.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E6C043D1F for ; Sun, 25 Jan 2004 07:57:32 -0800 (PST) (envelope-from dan@langille.org) Received: from wocker (wocker.unixathome.org [192.168.0.99]) by bast.unixathome.org (Postfix) with ESMTP id 235BE3D28 for ; Sun, 25 Jan 2004 10:57:31 -0500 (EST) From: "Dan Langille" To: freebsd-hackers@freebsd.org Date: Sun, 25 Jan 2004 10:57:31 -0500 MIME-Version: 1.0 Message-ID: <4013A11B.30806.3972D018@localhost> Priority: normal X-mailer: Pegasus Mail for Windows (v4.02a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Subject: problems resolving bsdcan.org? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2004 15:57:33 -0000 I've had reports of people not being able to resolve hostnames for bsdcan.org. I do know that one of the domain's DNS servers is offline (m20.unixathome.org). But the other (nezlok.unixathome.org) is up and accepting queries (at least for all my attempts). My testing at http://looking-glass.taide.net/ gives "connection timed out; no servers could be reached". But a dig from here goes OK: $ dig @nezlok.unixathome.org www.bsdcan.org ; <<>> DiG 8.3 <<>> @nezlok.unixathome.org www.bsdcan.org ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUERY SECTION: ;; www.bsdcan.org, type = A, class = IN ;; ANSWER SECTION: www.bsdcan.org. 3D IN A 66.154.97.250 ;; AUTHORITY SECTION: bsdcan.org. 3D IN NS m20.unixathome.org. bsdcan.org. 3D IN NS nezlok.unixathome.org. ;; ADDITIONAL SECTION: m20.unixathome.org. 3D IN A 66.11.169.50 nezlok.unixathome.org. 3D IN A 66.154.97.250 ;; Total query time: 203 msec ;; FROM: lists.unixathome.org to SERVER: nezlok.unixathome.org 66.154.97.250 ;; WHEN: Mon Jan 26 04:31:02 2004 ;; MSG SIZE sent: 32 rcvd: 130 I can't see the problem. Can you? Thanks. -- Dan Langille : http://www.langille.org/ From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 25 10:51:41 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A3C8816A4CE for ; Sun, 25 Jan 2004 10:51:41 -0800 (PST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 610D643D1F for ; Sun, 25 Jan 2004 10:51:40 -0800 (PST) (envelope-from silby@silby.com) Received: (qmail 83560 invoked from network); 25 Jan 2004 18:51:39 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 25 Jan 2004 18:51:39 -0000 X-pair-Authenticated: 209.68.2.70 Date: Sun, 25 Jan 2004 12:51:37 -0600 (CST) From: Mike Silbersack To: Dan Langille In-Reply-To: <4013A11B.30806.3972D018@localhost> Message-ID: <20040125124825.D873@odysseus.silby.com> References: <4013A11B.30806.3972D018@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org Subject: Re: problems resolving bsdcan.org? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2004 18:51:41 -0000 On Sun, 25 Jan 2004, Dan Langille wrote: > I've had reports of people not being able to resolve hostnames for > bsdcan.org. I do know that one of the domain's DNS servers is > offline (m20.unixathome.org). But the other (nezlok.unixathome.org) > is up and accepting queries (at least for all my attempts). > I can't see the problem. Can you? > > Thanks. > -- > Dan Langille : http://www.langille.org/ AFAIK, older versions of bind used to not handle the dead server case well at all. Perhaps people are still running older (unpatched), older (patched), or other vendor with the same bug DNS servers. I know this only because it happened to me back in 1999 or so, and was really frustrating (even though I still had 2/3 servers working!) IIRC, these older servers *did* handle the case where they received an icmp unreachable message fine, and just went on to the next machine; could you have another computer take over the dead DNS server's IP and run no services on it? Mike "Silby" Silbersack From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 25 11:09:49 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E0FD016A4CE for ; Sun, 25 Jan 2004 11:09:49 -0800 (PST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id B13A643D3F for ; Sun, 25 Jan 2004 11:09:45 -0800 (PST) (envelope-from silby@silby.com) Received: (qmail 87900 invoked from network); 25 Jan 2004 19:09:44 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 25 Jan 2004 19:09:44 -0000 X-pair-Authenticated: 209.68.2.70 Date: Sun, 25 Jan 2004 13:09:43 -0600 (CST) From: Mike Silbersack To: Sam Smith In-Reply-To: Message-ID: <20040125130453.E873@odysseus.silby.com> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Max Laier cc: hackers@freebsd.org cc: Robert Watson Subject: Re: XL driver checksum producing corrupted but checksum-correct packets X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2004 19:09:50 -0000 On Sat, 24 Jan 2004, Sam Smith wrote: > The thread on the OpenBSD list now contains a patch which > seems to fix the problem (for me, on OpenBSD, shifting data > by both NFS and ftp doing md5 checksums on the files at both > ends). Although it doesn't seem to turn off hardware > checksums (which is what I think it should do). > > Regards > Sam Turning off hardware checksumming is exactly what that patch does. This doesn't add any new information to the discussion, unfortunately. You don't happen to have the same type of motherboard chipset Matt does, do you? We could be barking up the wrong branch of a tree... Mike "Silby" Silbersack From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 25 11:13:39 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5417616A4CE for ; Sun, 25 Jan 2004 11:13:39 -0800 (PST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 4C11343D2D for ; Sun, 25 Jan 2004 11:13:30 -0800 (PST) (envelope-from silby@silby.com) Received: (qmail 88578 invoked from network); 25 Jan 2004 19:13:29 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 25 Jan 2004 19:13:29 -0000 X-pair-Authenticated: 209.68.2.70 Date: Sun, 25 Jan 2004 13:13:28 -0600 (CST) From: Mike Silbersack To: Robert Watson In-Reply-To: Message-ID: <20040125131053.X873@odysseus.silby.com> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Max Laier cc: hackers@freebsd.org Subject: Re: XL driver checksum producing corrupted but checksum-correct packets X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2004 19:13:39 -0000 On Sat, 24 Jan 2004, Robert Watson wrote: > To pick up the corrupted packet on the machine where the corruption is > occurring, you might want to try hooking up the UDP checksum drop case to > BPF_MTAP() for a special BPF device or rule, or have it spit them into a > raw socket (probably easier). He said that the packet's checksum passes, but it is corrupt, so this won't work. I suppose that one thing we could do in the long run to help detect this sort of corruption would be to import OpenBSD's TCP MD5 support and ensure that packets which fail the md5 or fail the checksum are logged so that they can be investigated. Of course, that's adding data to the packet, and heisenberg wouldn't be too happy about that. :) Mike "Silby" Silbersack From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 25 11:26:57 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D41116A4CE for ; Sun, 25 Jan 2004 11:26:57 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id EAEE843D53 for ; Sun, 25 Jan 2004 11:26:45 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.10/8.12.10) with ESMTP id i0PJOUUd001459; Sun, 25 Jan 2004 14:24:30 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i0PJOUEd001456; Sun, 25 Jan 2004 14:24:30 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sun, 25 Jan 2004 14:24:30 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Mike Silbersack In-Reply-To: <20040125131053.X873@odysseus.silby.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Max Laier cc: hackers@freebsd.org Subject: Re: XL driver checksum producing corrupted but checksum-correct packets X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2004 19:26:57 -0000 On Sun, 25 Jan 2004, Mike Silbersack wrote: > On Sat, 24 Jan 2004, Robert Watson wrote: > > > To pick up the corrupted packet on the machine where the corruption is > > occurring, you might want to try hooking up the UDP checksum drop case to > > BPF_MTAP() for a special BPF device or rule, or have it spit them into a > > raw socket (probably easier). > > He said that the packet's checksum passes, but it is corrupt, so this > won't work. I may have misread: my reading was that the if_xl card marks the packet as having passed the checksum test, but if you let the OS do the checksum, the checksum fails. I.e., either the hardware checksumming is broken, or the data is corrupted between when the hardware does the checksum, and it reaches the OS buffer. As such, Sam's patch works because it tells the OS to ignore the checksum results from the hardware (although it doesn't disable the checking of checksums), causing the OS to recalculate the checksums and drop the packets rather than accepting them. The goal of the change I suggested would be to also do the checksums in the OS as well, which allows you to detect the bad packets, but instead of dropping them, funnel them aside for later analysis. However, if I've misread, sorry for the confusion! Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 25 11:36:37 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E19A16A4CE; Sun, 25 Jan 2004 11:36:37 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B43743D1F; Sun, 25 Jan 2004 11:36:35 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) i0PJaY82043845; Sun, 25 Jan 2004 11:36:34 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id i0PJaYXt043844; Sun, 25 Jan 2004 11:36:34 -0800 (PST) (envelope-from dillon) Date: Sun, 25 Jan 2004 11:36:34 -0800 (PST) From: Matthew Dillon Message-Id: <200401251936.i0PJaYXt043844@apollo.backplane.com> To: Robert Watson References: cc: Max Laier cc: hackers@freebsd.org Subject: Re: XL driver checksum producing corrupted but checksum-correct packets X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2004 19:36:37 -0000 :> > To pick up the corrupted packet on the machine where the corruption is :> > occurring, you might want to try hooking up the UDP checksum drop case to :> > BPF_MTAP() for a special BPF device or rule, or have it spit them into a :> > raw socket (probably easier). :> :> He said that the packet's checksum passes, but it is corrupt, so this :> won't work. : :I may have misread: my reading was that the if_xl card marks the packet as :having passed the checksum test, but if you let the OS do the checksum, :the checksum fails. I.e., either the hardware checksumming is broken, or :the data is corrupted between when the hardware does the checksum, and it :reaches the OS buffer. As such, Sam's patch works because it tells the OS :to ignore the checksum results from the hardware (although it doesn't :disable the checking of checksums), causing the OS to recalculate the :checksums and drop the packets rather than accepting them. The goal of :the change I suggested would be to also do the checksums in the OS as :well, which allows you to detect the bad packets, but instead of dropping :them, funnel them aside for later analysis. However, if I've misread, :sorry for the confusion! : :Robert N M Watson FreeBSD Core Team, TrustedBSD Projects Ok, there's something not right... at least for me, the problem is on the transmit side. That is, its my NFS client that has the XL PCI card in it, and its a packet that it is transmitting that is getting corrupted. My NFS server is receiving the corrupted packet and accepting it (that is, the checksum check on my server on reception is succeeding). My server does *NOT* have an XL card in it. xl0: <3Com 3cSOHO100-TX OfficeConnect> port 0x9000-0x907f mem 0xe1000000-0xe100007f irq 11 at device 6.0 on pci1 When I turn off transmit checksums on the client side, the problem does not occur. However, I do not know whether that is because the server is now rejecting the packet as having a bad checksum due to the packet data being corrupted by the XL card as it is being sent, or whether it is because the client is no longer sending a corrupt packet. -Matt Matthew Dillon From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 25 11:59:36 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C5D3E16A4CE for ; Sun, 25 Jan 2004 11:59:36 -0800 (PST) Received: from mercury.qix.co.uk (mercury.qix.co.uk [212.42.1.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B8B743D41 for ; Sun, 25 Jan 2004 11:59:35 -0800 (PST) (envelope-from aledm@qix.co.uk) Received: from localhost (aledm@localhost) by mercury.qix.co.uk (8.12.8/8.12.8) with ESMTP id i0PJxWR2014706; Sun, 25 Jan 2004 19:59:33 GMT Date: Sun, 25 Jan 2004 19:59:32 +0000 (GMT) From: Aled Morris To: Mike Silbersack In-Reply-To: <20040125131053.X873@odysseus.silby.com> Message-ID: References: <20040125131053.X873@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: hackers@freebsd.org Subject: TCP MD5 (was Re: XL driver checksum producing corrupted but checksum-correct packets) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2004 19:59:36 -0000 On Sun, 25 Jan 2004, Mike Silbersack wrote: >I suppose that one thing we could do in the long run to help detect this >sort of corruption would be to import OpenBSD's TCP MD5 support If you're talking about RFC2385 style MD5 as used for BGP authentication, I'd pay someone to make that work on FreeBSD (with Zebra/Quagga.) Aled Morris QiX Limited From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 25 21:32:14 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6CD816A4CE; Sun, 25 Jan 2004 21:32:14 -0800 (PST) Received: from mxsf08.cluster1.charter.net (mxsf08.cluster1.charter.net [209.225.28.208]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2049043D4C; Sun, 25 Jan 2004 21:32:12 -0800 (PST) (envelope-from ups@tree.com) Received: from stups.com ([209.187.143.11])i0Q5Sg9B092379; Mon, 26 Jan 2004 00:28:42 -0500 (EST) (envelope-from ups@tree.com) Received: from tree.com (localhost [127.0.0.1]) by stups.com (8.9.3/8.9.3) with ESMTP id AAA32688; Mon, 26 Jan 2004 00:28:42 -0500 Message-Id: <200401260528.AAA32688@stups.com> X-Mailer: exmh version 2.0.2 To: Matthew Dillon In-Reply-To: Message from Matthew Dillon <200401251936.i0PJaYXt043844@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 26 Jan 2004 00:28:41 -0500 From: Stephan Uphoff cc: Max Laier cc: hackers@freebsd.org cc: Robert Watson Subject: Re: XL driver checksum producing corrupted but checksum-correct packets X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2004 05:32:14 -0000 Matthew Dillon wrote: > > When I turn off transmit checksums on the client side, the problem does > not occur. However, I do not know whether that is because the server is > now rejecting the packet as having a bad checksum due to the packet > data being corrupted by the XL card as it is being sent, or whether it > is because the client is no longer sending a corrupt packet. > > -Matt > Matthew Dillon > Hi, this behavior could be explained by a small xl driver bug. xl_start_90xB() puts packages on the transmit queue. The dma engine loads the packages and marks the related queue entry as complete. xl_txeof_90xB() looks for entries marked complete and m_freem()'s the related buffer. Transmit errors cause xl_txeoc() to be called. On some errors xl_txeoc() resets the queue pointer for the dma engine to entries already marked as complete. (and also does not stop the dma engine) Since transmit and the download engine are fairly independent a dma completion status interrupt can be generated after a transmit error interrupt. The transmit error can reset the dma engine to already completed entries and an already pending dma completion can then free the associated mbufs before they are successfully uploaded a second time. => data corruption. Solution: Someone with a good set of manuals and 3com cards should look how to stop the dma engine on serious transmit errors and then either remove all DMA completed entries from the queue or reset their completion marker bits. Unfortunately I have neither manuals nor cards. Stephan From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 25 22:28:09 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4387B16A4CE; Sun, 25 Jan 2004 22:28:09 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id C410C43D31; Sun, 25 Jan 2004 22:28:07 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.10/8.12.10) with ESMTP id i0Q6RxuO062002; Mon, 26 Jan 2004 07:28:05 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: slick From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 25 Jan 2004 23:09:11 EST." Date: Mon, 26 Jan 2004 07:27:59 +0100 Message-ID: <62001.1075098479@critter.freebsd.dk> cc: hackers@freebsd.org cc: freebsd-geom@freebsd.org Subject: Re: code compatibility between normal and geom methods for accessingdisk devices X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2004 06:28:09 -0000 In message , slick writes: > I wrote an fdisk program which uses several read(2) and write(2). You program needs to realize that disks have sectors. You cannot read a single byte from a disk at a time, you need to read an entire sector and pick the byte out you want. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 25 20:12:25 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3624B16A4CE; Sun, 25 Jan 2004 20:12:25 -0800 (PST) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79C5243D3F; Sun, 25 Jan 2004 20:12:19 -0800 (PST) (envelope-from plan_b@videotron.ca) Received: from player ([24.202.183.77]) by VL-MO-MR004.ip.videotron.ca (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with SMTP id <0HS200HU0WTU7Q@VL-MO-MR004.ip.videotron.ca>; Sun, 25 Jan 2004 23:08:18 -0500 (EST) Date: Sun, 25 Jan 2004 23:09:11 -0500 From: slick To: hackers@freebsd.org, freebsd-geom@freebsd.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: multipart/mixed; boundary="Boundary_(ID_ogyvznEVLFV5eupSOhg9Sg)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Mailman-Approved-At: Mon, 26 Jan 2004 05:28:00 -0800 Subject: code compatibility between normal and geom methods for accessingdisk devices X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2004 04:12:25 -0000 This is a multi-part message in MIME format. --Boundary_(ID_ogyvznEVLFV5eupSOhg9Sg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi, I wrote an fdisk program which uses several read(2) and write(2). My program should compile on any unix that uses sane libc. If compile it will work, except on systems that use geom methods. I read that geom is accessed via struct BIO. I can write a version of my program using struct BIO. I'm sure it will compile and work. Now should I maintain different version my program? Or should I write a set of function for each method, then some code to detect whatever method the kernel is using and use the appropriate set of functions. Also, I'm thinking, would it be a good idea to have another API to interface every other devices API. Like: Parent /dev using Master Device API Child /dev/disk using GEOM API Child /dev/net using NET API . . . . . . . . . I'm a bit confussed... plan_b@videotron.ca thanks for reading --Boundary_(ID_ogyvznEVLFV5eupSOhg9Sg) Content-type: text/plain; name=fdisk.txt; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=fdisk.txt #include #include #include #include #include #include #include int in; int out; int c = 0; int bc_size = 446; int pt_size = 66; unsigned char buffer[512]; int bc_copy(char *source, char *destination); int pt_copy(char *source, char *destination); int bc_print(char *source); int pt_print(char *source); int p_activate(char *source, char *partition); int p_type(char *source, char *partition, char *type); int ptbe_edit(char *source, char *partition, char *bc, char *bh, char *bs, char *ec, char *eh, char *es); int ptle_edit(char *source, char *partition, char *slba, char *lbas); int pt_sign(char *source); void pt_list(); void usage(); main(int argc, char **argv) { int opt; if (argc == 1) { usage(); return -1; } while ((opt = getopt(argc, argv, "a:c:C:e:E:hlp:P:S:t:u")) != -1) { switch (opt) { case 'a': if ((argc != 4)) { usage(); return -1; } p_activate(argv[2], argv[3]); break; case 'c': if ((argc != 4)) { usage(); return -1; } bc_copy(argv[2], argv[3]); break; case 'C': if ((argc != 4)) { usage(); return -1; } pt_copy(argv[2], argv[3]); break; case 'e': if ((argc != 10)) { usage(); return -1; } ptbe_edit(argv[2], argv[3], argv[4], argv[5], argv[6], argv[7], argv[8], argv[9]); break; case 'E': if ((argc != 6)) { usage(); return -1; } ptle_edit(argv[2], argv[3], argv[4], argv[5]); break; case 'h': usage(); break; case 'l': pt_list(); break; case 'p': if ((argc != 3)) { usage(); return -1; } bc_print(argv[2]); break; case 'P': if ((argc != 3)) { usage(); return -1; } pt_print(argv[2]); break; case 'S': if ((argc != 3)) { usage(); return -1; } pt_sign(argv[2]); break; case 't': if ((argc != 5)) { usage(); return -1; } p_type(argv[2], argv[3], argv[4]); break; case 'u': usage(); break; case '?': usage(); break; } argc -= optind; argv += optind; } } int p_activate(char *source, char *partition) { out = open(source, O_WRONLY|O_CREAT, S_IRUSR|S_IWUSR); while (c != 4) { lseek(out, bc_size, SEEK_SET); write(out, buffer, 1); bc_size = bc_size + 16; c++; } if ((strtoul(partition, NULL, 10) < 1) || (strtoul(partition, NULL, 10)) > 4) { printf("Partition Range: 1-4\n"); return -1; } bc_size = 430 + 16 * strtoul(partition, NULL, 10); buffer[0] = 128; lseek(out, bc_size, SEEK_SET); write(out, buffer, 1); } int bc_copy(char *source, char *destination) { in = open(source, O_RDONLY); out = open(destination, O_WRONLY|O_CREAT, S_IRUSR|S_IWUSR); read(in, buffer, bc_size); write(out, buffer, bc_size); printf("Boot Code has been transfered from %s to %s\n", source, destination); } int pt_copy(char *source, char *destination) { in = open(source, O_RDONLY); out = open(destination, O_WRONLY|O_CREAT, S_IRUSR|S_IWUSR); lseek(in, bc_size, SEEK_SET); read(in, buffer, pt_size); lseek(out, bc_size, SEEK_SET); write(out, buffer, pt_size); printf("Partition Table has been transfered from %s to %s\n", source, destination); } int ptbe_edit(char *source, char *partition, char *bc, char *bh, char *bs, char *ec, char *eh, char *es) { if ((strtoul(bc, NULL, 10) > 1024) || (strtoul(ec, NULL, 10) > 1024)) { printf("Maximum Cylinder value: 1024\n"); return -1; } if ((strtoul(bh, NULL, 10) > 255) || (strtoul(eh, NULL, 10) > 255)) { printf("Maximum Head value: 255\n"); return -1; } if ((strtoul(bs, NULL, 10) > 63) || (strtoul(es, NULL, 10) > 63)) { printf("Maximum Sector value: 63\n"); return -1; } if ((strtoul(partition, NULL, 10) < 1) || (strtoul(partition, NULL, 10) > 4)) { printf("Partition Range: 1-4\n"); return -1; } bc_size = 430 + 16 * strtoul(partition, NULL, 10); in = open(source, O_RDONLY); lseek(in, bc_size, SEEK_SET); read(in, buffer, 8); buffer[1] = strtoul(bh, NULL, 10); buffer[2] = (strtoul(bs, NULL, 10) + ((strtoul(bc, NULL, 10) & 768) >> 2)); buffer[3] = (strtoul(bc, NULL, 10) & 255); buffer[5] = strtoul(eh, NULL, 10); buffer[6] = (strtoul(es, NULL, 10) + ((strtoul(ec, NULL, 10) & 768) >> 2)); buffer[7] = (strtoul(ec, NULL, 10) & 255); out = open(source, O_WRONLY|O_CREAT, S_IRUSR|S_IWUSR); lseek(out, bc_size, SEEK_SET); write(out, buffer, 8); } int ptle_edit(char *source, char *partition, char *slba, char *lbas) { if (strtoul(slba, NULL, 10) > 2000000000) { printf("Maximum Starting LBA value: 2000000000\n"); return -1; } if (strtoul(lbas, NULL, 10) > 2000000000) { printf("Maximum LBA Size value: 2000000000\n"); return -1; } if ((strtoul(partition, NULL, 10) < 1) || (strtoul(partition, NULL, 10) > 4)) { printf("Partition Range: 1-4\n"); return -1; } bc_size = 438 + 16 * strtoul(partition, NULL, 10); buffer[0] = (strtoul(slba, NULL, 10) & 255); buffer[1] = ((strtoul(slba, NULL, 10) & 65280) >> 8); buffer[2] = ((strtoul(slba, NULL, 10) & 16711680) >> 16); buffer[3] = (strtoul(slba, NULL, 10) >> 24); buffer[4] = (strtoul(lbas, NULL, 10) & 255); buffer[5] = ((strtoul(lbas, NULL, 10) & 65280) >> 8); buffer[6] = ((strtoul(lbas, NULL, 10) & 16711680) >> 16); buffer[7] = (strtoul(lbas, NULL, 10) >> 24); out = open(source, O_WRONLY|O_CREAT, S_IRUSR|S_IWUSR); lseek(out, bc_size, SEEK_SET); write(out, buffer, 8); } int bc_print(char *source) { int bc = 0; in = open(source, O_RDONLY); read(in, buffer, bc_size); for (c; c < bc_size; c++) { if (bc == 16) { bc = 0; printf("\n"); } printf("%02x", buffer[c]); bc++; } printf("\n"); } int pt_print(char *source) { in = open(source, O_RDONLY); printf("\n"); while ( c != 4) { lseek(in, bc_size, SEEK_SET); read(in, buffer, 16); printf("Partition %2d is active %02x, type %02x, LBA start %d and LBA size %d\n", (c + 1), buffer[0], buffer[4], buffer[8] + (buffer[9] * 256) + (buffer[10] * 65536) + (buffer[11] * 16777216), buffer[12] + (buffer[13] * 256) + (buffer[14] * 65536) + (buffer[15] * 16777216)); printf("Beginning: %4d cylinder, %3d head, %2d sector\n", (((buffer[2] & 0xc0) << 2) + buffer[3]), buffer[1], (buffer[2] & 0x3f)); printf("Ending: %4d cylinder, %3d head, %2d sector\n\n", (((buffer[6] & 0xc0) << 2) + buffer[7]), buffer[5], (buffer[6] & 0x3f)); bc_size = bc_size + 16; c++; } } int p_type(char *source, char *partition, char *type) { if (strtoul(type, NULL, 10) > 255) { printf("Wrong Partition Type.\n"); pt_list(); return -1; } if ((strtoul(partition, NULL, 10) < 1) || (strtoul(partition, NULL, 10) > 4)) { printf("Partition Range: 1-4\n"); return -1; } bc_size = 434 + 16 * strtoul(partition, NULL, 10); buffer[0] = strtoul(type, NULL, 10); out = open(source, O_WRONLY|O_CREAT, S_IRUSR|S_IWUSR); lseek(out, bc_size, SEEK_SET); write(out, buffer, 1); } int pt_sign(char *source) { buffer[0] = 85; buffer[1] = 170; out = open(source, O_WRONLY|O_CREAT, S_IRUSR|S_IWUSR); lseek(out, 510, SEEK_SET); write(out, buffer, 2); } void pt_list() { printf("\n"); printf("00 Empty\n"); printf("01 12-bit FAT primary partition\n"); printf("04 16-bit FAT primary partition\n"); printf("05 Extended partition\n"); printf("06 BIGDOS FAT primary partition\n"); printf("07 NTFS primary partition\n"); printf("63 Unix System V (SCO, ISC Unix, UnixWare, ...), Mach, GNU Hurd\n"); printf("64 Novell Netware 286, 2.xx\n"); printf("65 Novell Netware 386, 3.xx or 4.xx\n"); printf("69 Novell Netware 5+, Novell Netware NSS Partition\n"); printf("82 Linux swap\n"); printf("83 Linux native partition\n"); printf("84 Hibernation partition\n"); printf("85 Linux extended partition\n"); printf("86 NTFS volume set\n"); printf("87 NTFS volume set\n"); printf("8b Legacy Fault Tolerant FAT32 volume\n"); printf("8c Legacy Fault Tolerant FAT32 volume using BIOS extended INT 13h\n"); printf("a0 Laptop hibernation partition\n"); printf("a5 NetBSD, FreeBSD, 386BSD\n"); printf("a6 OpenBSD\n"); printf("a9 NetBSD\n"); printf("eb BeOS\n"); printf("fb VMWare File System partition\n"); printf("fc VMWare Swap partition\n"); printf("\n"); } void usage() { printf("\n"); printf("fdisk - Partition Manager\n"); printf("\n"); printf("SYNOPSYS\n"); printf(" fdisk [-a:c:C:e:E:hlp:P:t:] [source] [destination] [partition] [type] [CHS start, CHS end] [LBA start, LBA size]\n"); printf("\n"); printf(" -a Activate [partition] on [source].\n"); printf(" -c Copy Boot Code from [source] to [destination].\n"); printf(" -C Copy Partition Table from [source] to [destination].\n"); printf(" -e Edit [partition] CHS parameters on [source].\n"); printf(" -E Edit [partition] LBA parameters on [source].\n"); printf(" -h Print help.\n"); printf(" -l Print Partition Type list.\n"); printf(" -p Print Boot Code from [source].\n"); printf(" -P Print Partition Table from [source].\n"); printf(" -S Sign the Partition Table.\n"); printf(" -t Change [partition] [type] on [source].\n"); printf(" -u Print help.\n"); printf("\n"); } --Boundary_(ID_ogyvznEVLFV5eupSOhg9Sg) Content-type: application/octet-stream; name=fdisk.c Content-transfer-encoding: quoted-printable Content-disposition: attachment; filename=fdisk.c #include =0A= #include =0A= #include =0A= #include =0A= #include =0A= #include =0A= #include =0A= =0A= int in;=0A= int out;=0A= int c =3D 0;=0A= int bc_size =3D 446;=0A= int pt_size =3D 66;=0A= unsigned char buffer[512];=0A= =0A= int bc_copy(char *source, char *destination);=0A= int pt_copy(char *source, char *destination);=0A= int bc_print(char *source);=0A= int pt_print(char *source);=0A= int p_activate(char *source, char *partition);=0A= int p_type(char *source, char *partition, char *type);=0A= int ptbe_edit(char *source, char *partition, char *bc, char *bh, char = *bs, char *ec, char *eh, char *es);=0A= int ptle_edit(char *source, char *partition, char *slba, char *lbas);=0A= int pt_sign(char *source);=0A= void pt_list();=0A= void usage();=0A= =0A= main(int argc, char **argv) {=0A= int opt;=0A= if (argc =3D=3D 1) { usage(); return -1; }=0A= while ((opt =3D getopt(argc, argv, "a:c:C:e:E:hlp:P:S:t:u")) !=3D -1) {=0A= switch (opt) {=0A= case 'a':=0A= if ((argc !=3D 4)) {=0A= usage();=0A= return -1;=0A= }=0A= p_activate(argv[2], argv[3]);=0A= break;=0A= case 'c':=0A= if ((argc !=3D 4)) {=0A= usage();=0A= return -1;=0A= }=0A= bc_copy(argv[2], argv[3]);=0A= break;=0A= case 'C':=0A= if ((argc !=3D 4)) {=0A= usage();=0A= return -1;=0A= }=0A= pt_copy(argv[2], argv[3]);=0A= break;=0A= case 'e':=0A= if ((argc !=3D 10)) {=0A= usage();=0A= return -1;=0A= }=0A= ptbe_edit(argv[2], argv[3], argv[4], argv[5], argv[6], argv[7], = argv[8], argv[9]);=0A= break;=0A= case 'E':=0A= if ((argc !=3D 6)) {=0A= usage();=0A= return -1;=0A= }=0A= ptle_edit(argv[2], argv[3], argv[4], argv[5]);=0A= break;=0A= case 'h':=0A= usage();=0A= break;=0A= case 'l':=0A= pt_list();=0A= break;=0A= case 'p':=0A= if ((argc !=3D 3)) {=0A= usage();=0A= return -1;=0A= }=0A= bc_print(argv[2]);=0A= break;=0A= case 'P':=0A= if ((argc !=3D 3)) {=0A= usage();=0A= return -1;=0A= }=0A= pt_print(argv[2]);=0A= break;=0A= case 'S':=0A= if ((argc !=3D 3)) {=0A= usage();=0A= return -1;=0A= }=0A= pt_sign(argv[2]);=0A= break;=0A= case 't':=0A= if ((argc !=3D 5)) {=0A= usage();=0A= return -1;=0A= }=0A= p_type(argv[2], argv[3], argv[4]);=0A= break;=0A= case 'u':=0A= usage();=0A= break;=0A= case '?':=0A= usage();=0A= break;=0A= }=0A= argc -=3D optind;=0A= argv +=3D optind;=0A= }=0A= }=0A= =0A= int p_activate(char *source, char *partition) {=0A= out =3D open(source, O_WRONLY|O_CREAT, S_IRUSR|S_IWUSR);=0A= while (c !=3D 4) {=0A= lseek(out, bc_size, SEEK_SET);=0A= write(out, buffer, 1);=0A= bc_size =3D bc_size + 16;=0A= c++;=0A= }=0A= if ((strtoul(partition, NULL, 10) < 1) || (strtoul(partition, NULL, = 10)) > 4) { printf("Partition Range: 1-4\n"); return -1; }=0A= bc_size =3D 430 + 16 * strtoul(partition, NULL, 10);=0A= buffer[0] =3D 128;=0A= lseek(out, bc_size, SEEK_SET);=0A= write(out, buffer, 1);=0A= }=0A= =0A= int bc_copy(char *source, char *destination) {=0A= in =3D open(source, O_RDONLY);=0A= out =3D open(destination, O_WRONLY|O_CREAT, S_IRUSR|S_IWUSR);=0A= read(in, buffer, bc_size);=0A= write(out, buffer, bc_size);=0A= printf("Boot Code has been transfered from %s to %s\n", source, = destination);=0A= }=0A= =0A= int pt_copy(char *source, char *destination) {=0A= in =3D open(source, O_RDONLY);=0A= out =3D open(destination, O_WRONLY|O_CREAT, S_IRUSR|S_IWUSR);=0A= lseek(in, bc_size, SEEK_SET);=0A= read(in, buffer, pt_size);=0A= lseek(out, bc_size, SEEK_SET);=0A= write(out, buffer, pt_size);=0A= printf("Partition Table has been transfered from %s to %s\n", source, = destination);=0A= }=0A= =0A= int ptbe_edit(char *source, char *partition, char *bc, char *bh, char = *bs, char *ec, char *eh, char *es) {=0A= if ((strtoul(bc, NULL, 10) > 1024) || (strtoul(ec, NULL, 10) > 1024)) {=0A= printf("Maximum Cylinder value: 1024\n");=0A= return -1;=0A= }=0A= if ((strtoul(bh, NULL, 10) > 255) || (strtoul(eh, NULL, 10) > 255)) {=0A= printf("Maximum Head value: 255\n");=0A= return -1;=0A= }=0A= if ((strtoul(bs, NULL, 10) > 63) || (strtoul(es, NULL, 10) > 63)) {=0A= printf("Maximum Sector value: 63\n");=0A= return -1;=0A= }=0A= if ((strtoul(partition, NULL, 10) < 1) || (strtoul(partition, NULL, 10) = > 4)) { printf("Partition Range: 1-4\n"); return -1; }=0A= bc_size =3D 430 + 16 * strtoul(partition, NULL, 10);=0A= in =3D open(source, O_RDONLY);=0A= lseek(in, bc_size, SEEK_SET);=0A= read(in, buffer, 8);=0A= buffer[1] =3D strtoul(bh, NULL, 10);=0A= buffer[2] =3D (strtoul(bs, NULL, 10) + ((strtoul(bc, NULL, 10) & 768) = >> 2));=0A= buffer[3] =3D (strtoul(bc, NULL, 10) & 255);=0A= buffer[5] =3D strtoul(eh, NULL, 10);=0A= buffer[6] =3D (strtoul(es, NULL, 10) + ((strtoul(ec, NULL, 10) & 768) = >> 2));=0A= buffer[7] =3D (strtoul(ec, NULL, 10) & 255);=0A= out =3D open(source, O_WRONLY|O_CREAT, S_IRUSR|S_IWUSR);=0A= lseek(out, bc_size, SEEK_SET);=0A= write(out, buffer, 8);=0A= }=0A= =0A= int ptle_edit(char *source, char *partition, char *slba, char *lbas) {=0A= if (strtoul(slba, NULL, 10) > 2000000000) {=0A= printf("Maximum Starting LBA value: 2000000000\n");=0A= return -1;=0A= }=0A= if (strtoul(lbas, NULL, 10) > 2000000000) {=0A= printf("Maximum LBA Size value: 2000000000\n");=0A= return -1;=0A= }=0A= if ((strtoul(partition, NULL, 10) < 1) || (strtoul(partition, NULL, 10) = > 4)) { printf("Partition Range: 1-4\n"); return -1; }=0A= bc_size =3D 438 + 16 * strtoul(partition, NULL, 10);=0A= buffer[0] =3D (strtoul(slba, NULL, 10) & 255);=0A= buffer[1] =3D ((strtoul(slba, NULL, 10) & 65280) >> 8);=0A= buffer[2] =3D ((strtoul(slba, NULL, 10) & 16711680) >> 16);=0A= buffer[3] =3D (strtoul(slba, NULL, 10) >> 24);=0A= buffer[4] =3D (strtoul(lbas, NULL, 10) & 255);=0A= buffer[5] =3D ((strtoul(lbas, NULL, 10) & 65280) >> 8);=0A= buffer[6] =3D ((strtoul(lbas, NULL, 10) & 16711680) >> 16);=0A= buffer[7] =3D (strtoul(lbas, NULL, 10) >> 24);=0A= out =3D open(source, O_WRONLY|O_CREAT, S_IRUSR|S_IWUSR);=0A= lseek(out, bc_size, SEEK_SET);=0A= write(out, buffer, 8);=0A= }=0A= =0A= int bc_print(char *source) {=0A= int bc =3D 0;=0A= in =3D open(source, O_RDONLY);=0A= read(in, buffer, bc_size);=0A= for (c; c < bc_size; c++) {=0A= if (bc =3D=3D 16) {=0A= bc =3D 0;=0A= printf("\n");=0A= }=0A= printf("%02x", buffer[c]);=0A= bc++;=0A= }=0A= printf("\n");=0A= }=0A= =0A= int pt_print(char *source) {=0A= in =3D open(source, O_RDONLY);=0A= printf("\n");=0A= while ( c !=3D 4) {=0A= lseek(in, bc_size, SEEK_SET);=0A= read(in, buffer, 16);=0A= printf("Partition %2d is active %02x, type %02x, LBA start %d and LBA = size %d\n", (c + 1), buffer[0], buffer[4], buffer[8] + (buffer[9] * 256) = + (buffer[10] * 65536) + (buffer[11] * 16777216), buffer[12] + = (buffer[13] * 256) + (buffer[14] * 65536) + (buffer[15] * 16777216));=0A= printf("Beginning: %4d cylinder, %3d head, %2d sector\n", (((buffer[2] = & 0xc0) << 2) + buffer[3]), buffer[1], (buffer[2] & 0x3f));=0A= printf("Ending: %4d cylinder, %3d head, %2d sector\n\n", = (((buffer[6] & 0xc0) << 2) + buffer[7]), buffer[5], (buffer[6] & 0x3f));=0A= bc_size =3D bc_size + 16;=0A= c++;=0A= }=0A= }=0A= =0A= int p_type(char *source, char *partition, char *type) {=0A= if (strtoul(type, NULL, 10) > 255) { printf("Wrong Partition Type.\n"); = pt_list(); return -1; }=0A= if ((strtoul(partition, NULL, 10) < 1) || (strtoul(partition, NULL, 10) = > 4)) { printf("Partition Range: 1-4\n"); return -1; }=0A= bc_size =3D 434 + 16 * strtoul(partition, NULL, 10);=0A= buffer[0] =3D strtoul(type, NULL, 10);=0A= out =3D open(source, O_WRONLY|O_CREAT, S_IRUSR|S_IWUSR);=0A= lseek(out, bc_size, SEEK_SET);=0A= write(out, buffer, 1);=0A= }=0A= =0A= int pt_sign(char *source) {=0A= buffer[0] =3D 85;=0A= buffer[1] =3D 170;=0A= out =3D open(source, O_WRONLY|O_CREAT, S_IRUSR|S_IWUSR);=0A= lseek(out, 510, SEEK_SET);=0A= write(out, buffer, 2);=0A= }=0A= =0A= void pt_list() {=0A= printf("\n");=0A= printf("00 Empty\n");=0A= printf("01 12-bit FAT primary partition\n");=0A= printf("04 16-bit FAT primary partition\n");=0A= printf("05 Extended partition\n");=0A= printf("06 BIGDOS FAT primary partition\n");=0A= printf("07 NTFS primary partition\n");=0A= printf("63 Unix System V (SCO, ISC Unix, UnixWare, ...), Mach, GNU = Hurd\n");=0A= printf("64 Novell Netware 286, 2.xx\n");=0A= printf("65 Novell Netware 386, 3.xx or 4.xx\n");=0A= printf("69 Novell Netware 5+, Novell Netware NSS Partition\n");=0A= printf("82 Linux swap\n");=0A= printf("83 Linux native partition\n");=0A= printf("84 Hibernation partition\n");=0A= printf("85 Linux extended partition\n");=0A= printf("86 NTFS volume set\n");=0A= printf("87 NTFS volume set\n");=0A= printf("8b Legacy Fault Tolerant FAT32 volume\n");=0A= printf("8c Legacy Fault Tolerant FAT32 volume using BIOS extended INT = 13h\n");=0A= printf("a0 Laptop hibernation partition\n");=0A= printf("a5 NetBSD, FreeBSD, 386BSD\n");=0A= printf("a6 OpenBSD\n");=0A= printf("a9 NetBSD\n");=0A= printf("eb BeOS\n");=0A= printf("fb VMWare File System partition\n");=0A= printf("fc VMWare Swap partition\n");=0A= printf("\n");=0A= }=0A= =0A= void usage() {=0A= printf("\n");=0A= printf("fdisk - Partition Manager\n");=0A= printf("\n");=0A= printf("SYNOPSYS\n");=0A= printf(" fdisk [-a:c:C:e:E:hlp:P:t:] [source] [destination] = [partition] [type] [CHS start, CHS end] [LBA start, LBA size]\n");=0A= printf("\n");=0A= printf(" -a Activate [partition] on [source].\n");=0A= printf(" -c Copy Boot Code from [source] to = [destination].\n");=0A= printf(" -C Copy Partition Table from [source] to = [destination].\n");=0A= printf(" -e Edit [partition] CHS parameters on [source].\n");=0A= printf(" -E Edit [partition] LBA parameters on [source].\n");=0A= printf(" -h Print help.\n");=0A= printf(" -l Print Partition Type list.\n");=0A= printf(" -p Print Boot Code from [source].\n");=0A= printf(" -P Print Partition Table from [source].\n");=0A= printf(" -S Sign the Partition Table.\n");=0A= printf(" -t Change [partition] [type] on [source].\n");=0A= printf(" -u Print help.\n");=0A= printf("\n");=0A= }=0A= --Boundary_(ID_ogyvznEVLFV5eupSOhg9Sg)-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 26 07:52:12 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8178916A4CE; Mon, 26 Jan 2004 07:52:12 -0800 (PST) Received: from smtp2.enst.fr (enst.enst.fr [137.194.2.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 641B343D81; Mon, 26 Jan 2004 07:50:26 -0800 (PST) (envelope-from pook@enst.fr) Received: from email.enst.fr (muse.enst.fr [137.194.2.33]) by smtp2.enst.fr (Postfix) with ESMTP id B31B753A42; Mon, 26 Jan 2004 16:47:42 +0100 (CET) Received: from roo (roo-ether.enst.fr [137.194.160.54]) by email.enst.fr (8.9.3/8.9.3) with ESMTP id QAA04459; Mon, 26 Jan 2004 16:47:43 +0100 (CET) Received: from pook (helo=roo) by roo with local-esmtp (Exim 3.36 #1 (Debian)) id 1Al8xj-0002aR-00; Mon, 26 Jan 2004 16:47:43 +0100 To: Don Lewis From: Stuart Pook Organisation: Ecole Nationale Superieure des Telecommunications, Paris, France In-reply-to: Message from truckman@FreeBSD.org of Fri, 23 Jan 2004 18:02:37 -0800. <200401240202.i0O22b7E068823@gw.catspoiler.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Date: Mon, 26 Jan 2004 16:47:43 +0100 Message-Id: Sender: Stuart Pook cc: freebsd-hackers@freebsd.org cc: andre@freebsd.org Subject: Re: send(2) does not block, send(2) man page wrong? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2004 15:52:12 -0000 > On 23 Jan 2004, Don Lewis wrote: > > the send does not give an error: the packet is just thrown away. > > Which is the same result as you would get if the bottleneck is just one > network hop away instead of at the local NIC. But it isn't. I'm broadcasting onto the local network. With Linux and Solaris (which implement what FreeBSD send(2) says), it is so easy: I just send(2) away, and because the send blocks when the kernel buffer space is full, I lose very few packets. With FreeBSD, I lose 60% of the packets. (The aim is to broadcast onto a private 802.11b network.) If I don't want to saturate the network then I will use kernel level traffic shaping to limit the outgoing bandwidth. I have already done this on Linux when I was broadcasting onto my 802.11b network via an access point connected via 100Mbits/s Ethernet. I just used traffic shaping to limit the outgoing traffic on that Ethernet interface to 3Mbits/s. I didn't have to change my program at all. (At one point I did try to put the delays (with nanosleep) into my program but it worked very badly because the scheduling delays were too big. The kernel does it so much better.) Once again it is vital that send blocks. I guess that I'm out of luck with *BSD. I hope that someone will update the send(2) man page so that the next person who wants to do what I'm doing will know that it isn't possible with FreeBSD. Stuart From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 26 10:53:59 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E5C316A4CE; Mon, 26 Jan 2004 10:53:59 -0800 (PST) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99C0E43D3F; Mon, 26 Jan 2004 10:53:57 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc13) with ESMTP id <2004012618535601600gf4f3e>; Mon, 26 Jan 2004 18:53:57 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA77321; Mon, 26 Jan 2004 10:53:55 -0800 (PST) Date: Mon, 26 Jan 2004 10:53:54 -0800 (PST) From: Julian Elischer To: Stuart Pook In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org cc: Don Lewis cc: andre@freebsd.org Subject: Re: send(2) does not block, send(2) man page wrong? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2004 18:53:59 -0000 do what ping does (ping -f) when you get an ENOBUFS do a usleep for 1 mSec. and then send it again. On Mon, 26 Jan 2004, Stuart Pook wrote: > > On 23 Jan 2004, Don Lewis wrote: > > > the send does not give an error: the packet is just thrown away. > > > > Which is the same result as you would get if the bottleneck is just one > > network hop away instead of at the local NIC. > > But it isn't. I'm broadcasting onto the local network. With Linux and > Solaris (which implement what FreeBSD send(2) says), it is so easy: I just > send(2) away, and because the send blocks when the kernel buffer space is > full, I lose very few packets. With FreeBSD, I lose 60% of the packets. > (The aim is to broadcast onto a private 802.11b network.) > > If I don't want to saturate the network then I will use kernel level > traffic shaping to limit the outgoing bandwidth. I have already done this > on Linux when I was broadcasting onto my 802.11b network via an access > point connected via 100Mbits/s Ethernet. I just used traffic shaping > to limit the outgoing traffic on that Ethernet interface to 3Mbits/s. > I didn't have to change my program at all. (At one point I did try > to put the delays (with nanosleep) into my program but it worked very > badly because the scheduling delays were too big. The kernel does it > so much better.) Once again it is vital that send blocks. > > I guess that I'm out of luck with *BSD. I hope that someone will update > the send(2) man page so that the next person who wants to do what I'm > doing will know that it isn't possible with FreeBSD. > > Stuart > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 26 11:16:39 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C7C516A4CE; Mon, 26 Jan 2004 11:16:39 -0800 (PST) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D3B543D1D; Mon, 26 Jan 2004 11:16:29 -0800 (PST) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i0QJGMAF096300; Mon, 26 Jan 2004 11:16:22 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i0QJGMGT096299; Mon, 26 Jan 2004 11:16:22 -0800 (PST) (envelope-from rizzo) Date: Mon, 26 Jan 2004 11:16:22 -0800 From: Luigi Rizzo To: Julian Elischer Message-ID: <20040126111622.A96082@xorpc.icir.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from julian@elischer.org on Mon, Jan 26, 2004 at 10:53:54AM -0800 cc: freebsd-hackers@freebsd.org cc: Don Lewis cc: andre@freebsd.org cc: Stuart Pook Subject: Re: send(2) does not block, send(2) man page wrong? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2004 19:16:39 -0000 On Mon, Jan 26, 2004 at 10:53:54AM -0800, Julian Elischer wrote: ... > On Mon, 26 Jan 2004, Stuart Pook wrote: > > > > On 23 Jan 2004, Don Lewis wrote: > > > > the send does not give an error: the packet is just thrown away. > > > > > > Which is the same result as you would get if the bottleneck is just one > > > network hop away instead of at the local NIC. > > > > But it isn't. I'm broadcasting onto the local network. With Linux and > > Solaris (which implement what FreeBSD send(2) says), it is so easy: I just > > send(2) away, and because the send blocks when the kernel buffer space is I'd be really curious to know how Linux/Solaris actually implement this blocking send and if they really block or use some kind of timeout/retry loop in the kernel. To implement a blocking send() on UDP sockets, you need a different driver model from the one we have, one where sockets and other data sources trying to access a full interface queue should be queued into some kind of list hanging off the interface, so that when the interface is ready again you can wake up the pending clients in turn and process their requests. This would cause the output queue to become effectively unbounded (basically, it is like reserving at least one slot per socket -- more if you want to deal with fragments), and even if the slot can be allocated as part of the socket, the delay would become unbounded as well. Secondly, if the interface for some reason goes "temporarily" down (e.g. no-carrier or the like) the process would suddenly block unless you mark the socket as non blocking. cheers luigi From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 26 12:59:42 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B9CDE16A4CE for ; Mon, 26 Jan 2004 12:59:42 -0800 (PST) Received: from wattres.Watt.COM (wattres.watt.com [66.93.133.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62BCD43D31 for ; Mon, 26 Jan 2004 12:59:41 -0800 (PST) (envelope-from steve@Watt.COM) Received: (from steve@localhost) by wattres.Watt.COM (8.12.9/8.12.9) id i0QKxdIi038551; Mon, 26 Jan 2004 12:59:39 -0800 (PST) (envelope-from steve) Message-Id: <200401262059.i0QKxdIi038551@wattres.Watt.COM> X-Newsgroups: local.freebsd-hackers In-Reply-To: References: Organization: Watt Consultants, San Jose, CA, USA From: steve@Watt.COM (Steve Watt) Date: Mon, 26 Jan 2004 12:59:39 -0800 X-Mailer: Mail User's Shell (7.2.6 beta(5) jp(8) 11/23/00) To: hackers@freebsd.org cc: julian@elischer.org Subject: Re: send(2) does not block, send(2) man page wrong? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2004 20:59:42 -0000 julian@elischer.org wrote: >do what ping does (ping -f) >when you get an ENOBUFS do a usleep for 1 mSec. >and then send it again. So how, exactly, do you actually sleep for 1mSec? I recently did some experiments using nanosleep(), and it seems that the minimum sleep time is 2 / HZ. I.e. ask for 100nS, get 20mS (on a 10mS-ticking system). Mind you, that behavior is precisely aligned with what POSIX says should happen, since nanosleep() is not allowed to return success before the specified amount of time has expired, and you might be calling it 5nS before the clock tick. But it does make doing correct Tx pacing a bit more challenging. Tried the same thing with usleep(10000), same result of ~20mS per sleep. Here's the program I tested that with. Same results on a 4.4-RELEASE and a 5.2-RELEASE machine. Numbers from one run: 4.4-REL: 1501 loops, 30.017931 elapsed, time per loop: 19998.622 us 5.2-REL: 1501 loops, 30.016053 elapsed, time per loop: 19997.371 us - - - 8< - - - #include #include #include /* Seconds to count loops */ #define RUNTIME 30 int main(int argc, char **argv) { struct timespec start, now, end, delay, remain; double ts, te; long loops = 0; int rv; clock_gettime(CLOCK_REALTIME, &start); end.tv_sec = start.tv_sec + RUNTIME; end.tv_nsec = start.tv_nsec; do { delay.tv_sec = 0; delay.tv_nsec = 10000; /* 10uS */ do { rv = nanosleep(&delay, &remain); delay = remain; } while (rv < 0 && errno == EINTR); ++loops; clock_gettime(CLOCK_REALTIME, &now); } while ((now.tv_sec == end.tv_sec) ? (now.tv_nsec < end.tv_nsec) : (now.tv_sec < end.tv_sec)); te = now.tv_sec + (now.tv_nsec / 1000000000.); ts = start.tv_sec + (start.tv_nsec / 1000000000.); printf("%d loops, %f elapsed, ", loops, te - ts); printf("time per loop: %.3f us\n", ((te - ts) / loops) * 1000000.); return 0; } -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8" / 37N 20' 14.9" Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices... From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 26 14:17:56 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 772C616A4CF; Mon, 26 Jan 2004 14:17:56 -0800 (PST) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE40543D45; Mon, 26 Jan 2004 14:17:52 -0800 (PST) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 9283865418; Sun, 25 Jan 2004 21:46:44 +0000 (GMT) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 31753-03-4; Sun, 25 Jan 2004 21:46:44 +0000 (GMT) Received: from saboteur.dek.spc.org (82-147-17-88.dsl.uk.rapidplay.com [82.147.17.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id B3549653C2; Sun, 25 Jan 2004 21:46:43 +0000 (GMT) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id 59304C3; Sun, 25 Jan 2004 21:46:42 +0000 (GMT) Date: Sun, 25 Jan 2004 21:46:41 +0000 From: Bruce M Simpson To: Mike Silbersack Message-ID: <20040125214641.GA707@saboteur.dek.spc.org> References: <20040125131053.X873@odysseus.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040125131053.X873@odysseus.silby.com> cc: Max Laier cc: hackers@freebsd.org cc: Robert Watson Subject: Re: XL driver checksum producing corrupted but checksum-correct packets X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2004 22:17:56 -0000 On Sun, Jan 25, 2004 at 01:13:28PM -0600, Mike Silbersack wrote: > I suppose that one thing we could do in the long run to help detect this > sort of corruption would be to import OpenBSD's TCP MD5 support and ensure > that packets which fail the md5 or fail the checksum are logged so that > they can be investigated. > > Of course, that's adding data to the packet, and heisenberg wouldn't be > too happy about that. :) I'm porting this right now. It's a bit different for us... BMS From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 26 14:17:56 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 92AA216A4D1 for ; Mon, 26 Jan 2004 14:17:56 -0800 (PST) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE26E43D41 for ; Mon, 26 Jan 2004 14:17:52 -0800 (PST) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 90226654D5; Sun, 25 Jan 2004 21:47:39 +0000 (GMT) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 31753-03-7; Sun, 25 Jan 2004 21:47:39 +0000 (GMT) Received: from saboteur.dek.spc.org (82-147-17-88.dsl.uk.rapidplay.com [82.147.17.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 02840654D2; Sun, 25 Jan 2004 21:47:37 +0000 (GMT) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id 550F5C3; Sun, 25 Jan 2004 21:47:36 +0000 (GMT) Date: Sun, 25 Jan 2004 21:47:36 +0000 From: Bruce M Simpson To: Aled Morris Message-ID: <20040125214736.GB707@saboteur.dek.spc.org> References: <20040125131053.X873@odysseus.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: cc: hackers@freebsd.org Subject: Re: TCP MD5 (was Re: XL driver checksum producing corrupted but checksum-correct packets) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2004 22:17:56 -0000 On Sun, Jan 25, 2004 at 07:59:32PM +0000, Aled Morris wrote: > If you're talking about RFC2385 style MD5 as used for BGP authentication, > I'd pay someone to make that work on FreeBSD (with Zebra/Quagga.) Someone already is, and I have patches for Quagga/Zebra ongoing... (how do you think I'm testing it? :-)) BMS From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 26 14:44:29 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 57D8816A4CE for ; Mon, 26 Jan 2004 14:44:29 -0800 (PST) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6429043D2F for ; Mon, 26 Jan 2004 14:44:24 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc13) with ESMTP id <2004012622442301600ge1eqe>; Mon, 26 Jan 2004 22:44:23 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA79753; Mon, 26 Jan 2004 14:44:22 -0800 (PST) Date: Mon, 26 Jan 2004 14:44:21 -0800 (PST) From: Julian Elischer To: Steve Watt In-Reply-To: <200401262059.i0QKxdIi038551@wattres.Watt.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: hackers@freebsd.org Subject: Re: send(2) does not block, send(2) man page wrong? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2004 22:44:29 -0000 On Mon, 26 Jan 2004, Steve Watt wrote: > julian@elischer.org wrote: > >do what ping does (ping -f) > >when you get an ENOBUFS do a usleep for 1 mSec. > >and then send it again. you are correct, but I just meant that it requested to sleep 1mSec, not that the sleep actually WAS 1mSec. Making udp sockets block would break so many things since it was always this way since sockets were invented in BSD2.x > > So how, exactly, do you actually sleep for 1mSec? I recently did some > experiments using nanosleep(), and it seems that the minimum sleep time > is 2 / HZ. I.e. ask for 100nS, get 20mS (on a 10mS-ticking system). > > Mind you, that behavior is precisely aligned with what POSIX says should > happen, since nanosleep() is not allowed to return success before the > specified amount of time has expired, and you might be calling it 5nS > before the clock tick. But it does make doing correct Tx pacing a bit > more challenging. > > Tried the same thing with usleep(10000), same result of ~20mS per > sleep. > > Here's the program I tested that with. Same results on a 4.4-RELEASE > and a 5.2-RELEASE machine. > > Numbers from one run: > 4.4-REL: 1501 loops, 30.017931 elapsed, time per loop: 19998.622 us > 5.2-REL: 1501 loops, 30.016053 elapsed, time per loop: 19997.371 us > > - - - 8< - - - > > #include > #include > #include > > /* Seconds to count loops */ > #define RUNTIME 30 > > int > main(int argc, char **argv) > { > struct timespec start, now, end, delay, remain; > double ts, te; > long loops = 0; > int rv; > > clock_gettime(CLOCK_REALTIME, &start); > end.tv_sec = start.tv_sec + RUNTIME; > end.tv_nsec = start.tv_nsec; > > do { > delay.tv_sec = 0; > delay.tv_nsec = 10000; /* 10uS */ > > do { > rv = nanosleep(&delay, &remain); > delay = remain; > } while (rv < 0 && errno == EINTR); > > ++loops; > clock_gettime(CLOCK_REALTIME, &now); > } while ((now.tv_sec == end.tv_sec) ? > (now.tv_nsec < end.tv_nsec) : > (now.tv_sec < end.tv_sec)); > > te = now.tv_sec + (now.tv_nsec / 1000000000.); > ts = start.tv_sec + (start.tv_nsec / 1000000000.); > > printf("%d loops, %f elapsed, ", loops, te - ts); > printf("time per loop: %.3f us\n", ((te - ts) / loops) * 1000000.); > > return 0; > } > > > -- > Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8" / 37N 20' 14.9" > Internet: steve @ Watt.COM Whois: SW32 > Free time? There's no such thing. It just comes in varying prices... > From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 29 09:34:06 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0247216A4CE for ; Wed, 29 Oct 2003 09:34:06 -0800 (PST) Received: from lakemtao06.cox.net (lakemtao06.cox.net [68.1.17.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFDA843FB1 for ; Wed, 29 Oct 2003 09:34:04 -0800 (PST) (envelope-from mezz7@cox.net) Received: from mezz.mezzweb.com ([68.103.32.11]) by lakemtao06.cox.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20031029173404.BTTH10862.lakemtao06.cox.net@mezz.mezzweb.com>; Wed, 29 Oct 2003 12:34:04 -0500 To: Isaac Gelado References: <3F9FAE4D.3020500@tid.es> From: Jeremy Messenger Content-Type: text/plain; format=flowed; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <3F9FAE4D.3020500@tid.es> User-Agent: Opera7.21/Linux M2 build 480 cc: freebsd-hackers@freebsd.org Subject: Re: POSIX Threads X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Wed, 29 Oct 2003 17:34:06 -0000 X-Original-Date: Wed, 29 Oct 2003 11:33:19 -0600 X-List-Received-Date: Wed, 29 Oct 2003 17:34:06 -0000 On Wed, 29 Oct 2003 13:10:53 +0100, Isaac Gelado wrote: > But, when the server is running under FreeBSD 5.0 I think that you do really need to update your machine to 5.1-CURRENT for the threads. It's a lot improvement from 5.0, but I have no idea if it will solve your problem in that area. At least, you can help with the developers to keep the things up to date. Cheers, Mezz -- bsdforums.org 's moderator, mezz. From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 4 11:35:07 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5451F16A4CF for ; Tue, 4 Nov 2003 11:35:07 -0800 (PST) Received: from mail.speakeasy.net (mail7.speakeasy.net [216.254.0.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 128C843FCB for ; Tue, 4 Nov 2003 11:35:02 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 25950 invoked from network); 4 Nov 2003 19:35:01 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 4 Nov 2003 19:35:01 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id hA4JYbce070696; Tue, 4 Nov 2003 14:34:37 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20031104191526.GA79079@VARK.homeunix.com> From: John Baldwin To: David Schultz X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: FreeBSD Hackers cc: FreeBSD Bugs cc: Igor Serikov Subject: Re: rfork problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Tue, 04 Nov 2003 19:35:07 -0000 X-Original-Date: Tue, 04 Nov 2003 14:34:37 -0500 (EST) X-List-Received-Date: Tue, 04 Nov 2003 19:35:07 -0000 On 04-Nov-2003 David Schultz wrote: > On Tue, Nov 04, 2003, Igor Serikov wrote: >> >> David, >> >> Is it okay to have a condition that can be created by a mortal user and >> then cannot be changed by the root? The waiting process cannot be killed >> and would keep "waiting" till system reboot. > > Aah, I see. No, it's not okay that a non-root user can create an > unkillable process. -CURRENT doesn't have this problem because it > rightly fails when a userland program tries to use RFPPWAIT. (It > isn't supposed to be available to userland, which is why it isn't > documented.) The problem could be fixed by backporting the > relevant bits from -CURRENT. > >> I do not think it is a good idea to make ppwait state uninterruptible in >> any case. > > I do not think it would be safe to deliver a signal to a parent > process while a vforked child is borrowing its address space. > > Here's a patch against -STABLE: > > Index: kern_fork.c > =================================================================== > RCS file: /cvs/src/sys/kern/kern_fork.c,v > retrieving revision 1.72.2.15 > diff -u -r1.72.2.15 kern_fork.c > --- kern_fork.c 28 Sep 2003 11:08:31 -0000 1.72.2.15 > +++ kern_fork.c 4 Nov 2003 19:13:33 -0000 > @@ -130,6 +130,9 @@ > int error; > struct proc *p2; > > + /* Don't allow kernel only flags. */ > + if ((uap->flags & RFKERNELONLY) != 0) > + return (EINVAL); > error = fork1(p, uap->flags, &p2); > if (error == 0) { > p->p_retval[0] = p2 ? p2->p_pid : 0; You'll need to backport RFKERNELONLY as well in sys/unistd.h as that isn't in 4.x AFAIK. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 4 12:34:50 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6DD9516A4CE for ; Tue, 4 Nov 2003 12:34:50 -0800 (PST) Received: from hak.cnd.mcgill.ca (hak.cnd.mcgill.ca [132.216.11.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA47743FEC for ; Tue, 4 Nov 2003 12:34:48 -0800 (PST) (envelope-from mat@hak.cnd.mcgill.ca) Received: from hak.cnd.mcgill.ca (localhost [127.0.0.1]) by hak.cnd.mcgill.ca (8.12.9/8.12.8) with ESMTP id hA4KWak4065399; Tue, 4 Nov 2003 15:32:36 -0500 (EST) (envelope-from mat@hak.cnd.mcgill.ca) Received: (from mat@localhost) by hak.cnd.mcgill.ca (8.12.9/8.12.8/Submit) id hA4KWaew065398; Tue, 4 Nov 2003 15:32:36 -0500 (EST) From: Mathew Kanner To: Anthony Schneider Message-ID: <20031104203236.GJ25967@cnd.mcgill.ca> References: <20031104060851.GA39619@x-anthony.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031104060851.GA39619@x-anthony.com> User-Agent: Mutt/1.4.1i Organization: I speak for myself, operating in Montreal, CANADA X-Spam-Status: No, hits=-4.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MUTT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: freebsd-hackers@freebsd.org Subject: Re: Sound Blaster Audigy LS problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Tue, 04 Nov 2003 20:34:50 -0000 X-Original-Date: Tue, 4 Nov 2003 15:32:36 -0500 X-List-Received-Date: Tue, 04 Nov 2003 20:34:50 -0000 On Nov 04, Anthony Schneider wrote: > [...] > timeout = (hz * sndbuf_getblksz(bs)) / (sndbuf_getspd(bs) * sndbuf_getbps(bs)); > if (timeout < 1) > timeout = 1; > timeout = 1; > > seems like overkill... > I noticed this too. It was introduced in rev 1.65 to "reduce latency/pauses in output." It isn't clear to me why it's there. --Mat -- It's impossible to awaken a man who is pretending to be asleep. - Navajo saying From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 9 08:34:49 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D187A16A4CE for ; Sun, 9 Nov 2003 08:34:49 -0800 (PST) Received: from titan.kleipool.org (e137166.upc-e.chello.nl [213.93.137.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6676E43FAF for ; Sun, 9 Nov 2003 08:34:47 -0800 (PST) (envelope-from Reinier@Kleipool.org) Received: from io (io.ovs.kleipool.org [192.168.1.82]) by titan.kleipool.org (8.12.6/8.12.6) with SMTP id hA9GYhnk061361 for ; Sun, 9 Nov 2003 17:34:44 +0100 (CET) (envelope-from Reinier@Kleipool.org) From: "Reinier Kleipool" To: Message-ID: <000001c3a6df$60ef28f0$5201a8c0@ovs.kleipool.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Subject: kernel enviroment in sysctl MIB X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Sun, 09 Nov 2003 16:34:49 -0000 X-Original-Date: Sun, 9 Nov 2003 17:34:41 +0100 X-List-Received-Date: Sun, 09 Nov 2003 16:34:49 -0000 Hello, I am investigating the possiblilies for looking at the kernel boot parameters from within a userland utility. (Possibly a new FreeBSD install facility) The idea is that by looking at sysctl kern.environment.* you should be able to see the BTX variables. An install program could use this to see an INSTALL_SERVER=install.company.com variable (etc...) to use as install server. The BTX loader could provide these variables at install boot time, thus enableing fully automated installs. When I look at kern/kern_environment.c I see that the BTX loader provides its "environment variables" to the kernel. They show up in the kernel under char *kern_envp. When looking at this variable in the gdb debugger I see the first environment variable of the BTX loader: "LINES=24". I do not master the gdb enhough to see the next enviroment variable (I tried (kgdb) print kern_envp@2, but this does not show the variable after the first \0 character) but I am sure its there. My question is this: When looking at kern/kern_environmet.c I see routines that install a SYSCTL_NODE kern.environment. The sysctl_kernenv routine handles this node. What I do not understand is how the environment is returned from this routine. I suppose that at sys_init time you should traverse the environment once and install SYSCTL_ADD_STRING leaves for all environment variables. Then later sysctl calls could ask for the value of these strings. Am I right? Or does it work differently? When you issue the command "sysctl kern.environment" as root you see no output, but also no error! When you try "sysctl kern.environment.LINES" you do get an error I can understand why! No leaves were installed. What is wrong, and how can we fix it? Vriendelijke groet / Kind Regards, Reinier Kleipool, Network Engineer, Protocomix Rotterdamserijweg 122 3042 AS Rotterdam Tel 0654 227144 Fax 010 245 0902 Reinier@protocomix.nl