From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 10 04:27:18 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 29EE316A49A for ; Sun, 10 Feb 2008 04:27:18 +0000 (UTC) (envelope-from ws@au.dyndns.ws) Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by mx1.freebsd.org (Postfix) with ESMTP id AF2AC13C468 for ; Sun, 10 Feb 2008 04:27:17 +0000 (UTC) (envelope-from ws@au.dyndns.ws) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAB4MrkeWZWdv/2dsb2JhbAAIkgGWCQ X-IronPort-AV: E=Sophos;i="4.25,328,1199626200"; d="scan'208";a="51461928" Received: from ppp103-111.static.internode.on.net (HELO [192.168.1.131]) ([150.101.103.111]) by ipmail05.adl2.internode.on.net with ESMTP; 10 Feb 2008 14:57:16 +1030 From: Wayne Sierke To: hackers In-Reply-To: <1202308467.5350.220.camel@predator-ii.buffyverse> References: <1202308467.5350.220.camel@predator-ii.buffyverse> Content-Type: text/plain Date: Sun, 10 Feb 2008 14:57:13 +1030 Message-Id: <1202617634.1464.23.camel@predator-ii.buffyverse> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Subject: Re: Any interest in unused hardware being made available for remote developer use? 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, 10 Feb 2008 04:27:18 -0000 Following up with some corrections/additional info: On Thu, 2008-02-07 at 01:04 +1030, Wayne Sierke wrote: > I have a Compaq ML370 Proliant server here which is likely to remain > unused for the foreseeable future. Some of its key specs are: > > - Dual 800MHz PIII/133MHz/256MB CPU Of course, that should be 256KB, not 256MB! > - 1.25GB ECC Memory > - 2 x 9G 10k SCSI-UW2 > - 1 x 18G 10k SCSI-UW2 > - 2 x Intel EtherExpress PRO/100 Ethernet > > I've been contemplating the idea of offering it for remote access, to > those with a legitimate use for it in a FreeBSD-related development > endeavour. > > There are numerous aspects about this that warrant careful consideration > and for which I'll be seeking comment if it comes to it, however the > first question is: Is there any interest, or likely to be? > Since all the interest expressed so far has been in having the system available ostensibly as a server, I should point out that current circumstances don't lend themselves to this type of use, for now. My intention is to make it available as a test/development system and allow it to be used essentially unrestricted (in the development sense). From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 10 04:44:57 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 30B5816A418 for ; Sun, 10 Feb 2008 04:44:57 +0000 (UTC) (envelope-from devin@spamcop.net) Received: from mail.distalzou.net (203.141.139.231.static.zoot.jp [203.141.139.231]) by mx1.freebsd.org (Postfix) with ESMTP id BF4A313C442 for ; Sun, 10 Feb 2008 04:44:56 +0000 (UTC) (envelope-from devin@spamcop.net) Received: from plexi.pun-pun.prv ([192.168.7.29]) by mail.distalzou.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JO3QX-0005cS-0m; Sun, 10 Feb 2008 13:04:25 +0900 Date: Sun, 10 Feb 2008 13:04:24 +0900 (JST) From: Tod McQuillin X-X-Sender: devin@plexi.pun-pun.prv To: Ivan Georgiev In-Reply-To: <20080209220206.695e5d9b.yngwiie@bk.ru> Message-ID: References: <20080209220206.695e5d9b.yngwiie@bk.ru> User-Agent: Alpine 1.00 (BSF 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: freebsd-hackers@freebsd.org Subject: Re: quotactl returns double values 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, 10 Feb 2008 04:44:57 -0000 On Sat, 9 Feb 2008, Ivan Georgiev wrote: > I was just playing, trying to see how quotactl works, > but in all my tries the values returned are doubled, > > the values stored in my_st->dqb_bhardlimit and my_st->dqb_curblocks > are the real values times two, the hard limit on the user is 102400K, > but my_st->dqb_bhardlimit holds 204800K. I hope you are remembering that the limits are measured in blocks -- a block is 512 bytes. Thus a limit of 102400K is 204800 blocks, since each 1K holds 2 blocks. -- Tod McQuillin From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 10 10:24: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 D765016A419 for ; Sun, 10 Feb 2008 10:24:10 +0000 (UTC) (envelope-from cihan@enderunix.org) Received: from istanbul.enderunix.org (freefall.marmara.edu.tr [193.140.143.23]) by mx1.freebsd.org (Postfix) with ESMTP id EA64B13C461 for ; Sun, 10 Feb 2008 10:24:09 +0000 (UTC) (envelope-from cihan@enderunix.org) Received: (qmail 42184 invoked by uid 1040); 10 Feb 2008 10:24:14 -0000 Received: from unknown (HELO localhost) (cihan@85.105.200.118) by 0 with ESMTPA; 10 Feb 2008 10:24:13 -0000 Date: Sun, 10 Feb 2008 12:23:54 +0200 From: =?utf-8?B?Q2loYW4gS8O2bWXDp2/En2x1?= X-Mailer: The Bat! (v3.99.29) UNREG X-Priority: 3 (Normal) Message-ID: <1623050662.20080210122354@enderunix.org> To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable X-Antivirus: avast! (VPS 080209-0, 09.02.2008), Outbound message X-Antivirus-Status: Clean X-SMTP-Filter: SurGATE SMTP Filter Engine Release 1.0.1 http://www.endersys.com X-SurGATE-Result: Clean (Content eval: -4.40 points) Subject: abort? 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, 10 Feb 2008 10:24:10 -0000 Hello list I cant understand why kill function is called two times to send sigabort signal. One signal to send is enough, isn't it? Thanks void abort(void) /* POSIX-style abort() function */ { sigset_t mask; struct sigaction action; /* * Caller can't ignore SIGABRT, if so reset to default. */ sigaction(SIGABRT, NULL, &action); if (action.sa_handler =3D=3D SIG_IGN) { action.sa_handler =3D SIG_DFL; sigaction(SIGABRT, &action, NULL); } if (action.sa_handler =3D=3D SIG_DFL) fflush(NULL); /* flush all open stdio streams */ /* * Caller can't block SIGABRT; make sure it's unblocked. */ sigfillset(&mask); sigdelset(&mask, SIGABRT); /* mask has only SIGABRT turned off */ sigprocmask(SIG_SETMASK, &mask, NULL); kill(getpid(), SIGABRT); /* send the signal */ /* * If we're here, process caught SIGABRT and returned. */ fflush(NULL); /* flush all open stdio streams */ action.sa_handler =3D SIG_DFL; sigaction(SIGABRT, &action, NULL); /* reset to default */ sigprocmask(SIG_SETMASK, &mask, NULL); /* just in case ... */ kill(getpid(), SIGABRT); /* and one more time */ exit(1); /* this should never be executed ... */ } =20 --=20 Cihan K=F6me=E7o=F0lu, EnderUNIX SDT mailto:cihan@enderunix.org From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 10 11:01: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 9C4C616A421 for ; Sun, 10 Feb 2008 11:01:05 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from galain.elvandar.org (galain.elvandar.org [217.148.169.56]) by mx1.freebsd.org (Postfix) with ESMTP id 60BAA13C455 for ; Sun, 10 Feb 2008 11:01:05 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from evilcoder.xs4all.nl ([195.64.94.120] helo=elvandar.local) by galain.elvandar.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JO9U5-000PmT-4u; Sun, 10 Feb 2008 11:32:29 +0100 Message-ID: <47AED2BC.2080505@FreeBSD.org> Date: Sun, 10 Feb 2008 11:32:28 +0100 From: Remko Lodder User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: =?UTF-8?B?Q2loYW4gS8O2bWXDp2/En2x1?= References: <1623050662.20080210122354@enderunix.org> In-Reply-To: <1623050662.20080210122354@enderunix.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org Subject: Re: abort? 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, 10 Feb 2008 11:01:05 -0000 Cihan Kömeçoğlu wrote: > Hello list > > I cant understand why kill function is called two times to send > sigabort signal. One signal to send is enough, isn't it? > > Thanks > > > > void > abort(void) /* POSIX-style abort() function */ > { > sigset_t mask; > struct sigaction action; > > /* > * Caller can't ignore SIGABRT, if so reset to default. > */ > sigaction(SIGABRT, NULL, &action); > if (action.sa_handler == SIG_IGN) { > action.sa_handler = SIG_DFL; > sigaction(SIGABRT, &action, NULL); > } > if (action.sa_handler == SIG_DFL) > fflush(NULL); /* flush all open stdio streams */ > > /* > * Caller can't block SIGABRT; make sure it's unblocked. > */ > sigfillset(&mask); > sigdelset(&mask, SIGABRT); /* mask has only SIGABRT turned off */ > sigprocmask(SIG_SETMASK, &mask, NULL); > kill(getpid(), SIGABRT); /* send the signal */ ^^^^^ kill 1 > > /* > * If we're here, process caught SIGABRT and returned. > */ > fflush(NULL); /* flush all open stdio streams */ > action.sa_handler = SIG_DFL; > sigaction(SIGABRT, &action, NULL); /* reset to default */ > sigprocmask(SIG_SETMASK, &mask, NULL); /* just in case ... */ > kill(getpid(), SIGABRT); /* and one more time */ ^^^^ kill 2 > exit(1); /* this should never be executed ... */ > } > > Just a wild guess... but if you read the above you'll see two kill statements, without conditionals around it, so my guess is that even when the signal had already been send (kill 1), the information regarding the pid etc remains in memory, and when you traverse the code, it sends it again (kill 2). my E0.02 -- /"\ Best regards, | remko@FreeBSD.org \ / Remko Lodder | remko@EFnet X http://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 10 11:03: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 4F35E16A419 for ; Sun, 10 Feb 2008 11:03:06 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id C8EDB13C478 for ; Sun, 10 Feb 2008 11:03:05 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from c83-253-25-183.bredband.comhem.se ([83.253.25.183]:50487 helo=falcon.midgard.homeip.net) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1JO9xg-00013d-5l for freebsd-hackers@freebsd.org; Sun, 10 Feb 2008 12:03:05 +0100 Received: (qmail 1908 invoked from network); 10 Feb 2008 12:02:59 +0100 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with ESMTP; 10 Feb 2008 12:02:59 +0100 Received: (qmail 3881 invoked by uid 1001); 10 Feb 2008 12:02:59 +0100 Date: Sun, 10 Feb 2008 12:02:59 +0100 From: Erik Trulsson To: Cihan =?iso-8859-1?B?S/ZtZedvPz9sdQ==?= Message-ID: <20080210110259.GA3652@owl.midgard.homeip.net> Mail-Followup-To: Cihan =?iso-8859-1?B?S/ZtZedvPz9sdQ==?= , freebsd-hackers@freebsd.org References: <1623050662.20080210122354@enderunix.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <1623050662.20080210122354@enderunix.org> User-Agent: Mutt/1.5.17 (2007-11-01) X-Originating-IP: 83.253.25.183 X-Scan-Result: No virus found in message 1JO9xg-00013d-5l. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1JO9xg-00013d-5l ea76ae9bd2e1c4703299c57ba1f1ed17 Cc: freebsd-hackers@freebsd.org Subject: Re: abort? 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, 10 Feb 2008 11:03:06 -0000 On Sun, Feb 10, 2008 at 12:23:54PM +0200, Cihan K=F6me=E7o??lu wrote: > Hello list >=20 > I cant understand why kill function is called two times to send > sigabort signal. One signal to send is enough, isn't it? The program might have installed a signal handler for SIGABRT. The signal is sent a second time if and only if the process did catch the SIGABRT signal *and* the signal handler returned. Before the signal is sent the first time the implementation below makes sure that SIGABRT is neither ignored nor blocked. Before the second time it sends the signal it also makes sure the signal is not caught. According to the specification for abort() a program is allowed to catch the SIGABRT signal, but if the signal handler returns then the program will be aborted anyway. PS. I am curious: Which abort() implementation is it you have quoted below? As far as I can tell it is not identical to any that has been included in FreeBSD. >=20 > Thanks >=20 >=20 >=20 > void > abort(void) /* POSIX-style abort() function */ > { > sigset_t mask; > struct sigaction action; >=20 > /* > * Caller can't ignore SIGABRT, if so reset to default. > */ > sigaction(SIGABRT, NULL, &action); > if (action.sa_handler =3D=3D SIG_IGN) { > action.sa_handler =3D SIG_DFL; > sigaction(SIGABRT, &action, NULL); > } > if (action.sa_handler =3D=3D SIG_DFL) > fflush(NULL); /* flush all open stdio streams */ >=20 > /* > * Caller can't block SIGABRT; make sure it's unblocked. > */ > sigfillset(&mask); > sigdelset(&mask, SIGABRT); /* mask has only SIGABRT turned off */ > sigprocmask(SIG_SETMASK, &mask, NULL); > kill(getpid(), SIGABRT); /* send the signal */ >=20 > /* > * If we're here, process caught SIGABRT and returned. > */ > fflush(NULL); /* flush all open stdio streams */ > action.sa_handler =3D SIG_DFL; > sigaction(SIGABRT, &action, NULL); /* reset to default */ > sigprocmask(SIG_SETMASK, &mask, NULL); /* just in case ... */ > kill(getpid(), SIGABRT); /* and one more time */ > exit(1); /* this should never be executed ... */ > } > =20 --=20 Erik Trulsson ertr1013@student.uu.se From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 10 18:03: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 E025D16A421 for ; Sun, 10 Feb 2008 18:03:32 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from mail.ciam.ru (ns.ciam.ru [213.247.195.75]) by mx1.freebsd.org (Postfix) with ESMTP id B9E6A13C46B for ; Sun, 10 Feb 2008 18:03:32 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from [79.164.225.201] (helo=solem.sem-home.ciam.ru) by mail.ciam.ru with esmtpa (Exim 4.x) id 1JOG4R-000JnP-P4 for freebsd-hackers@freebsd.org; Sun, 10 Feb 2008 20:34:28 +0300 Message-ID: <47AF349F.5040609@FreeBSD.org> Date: Sun, 10 Feb 2008 20:30:07 +0300 From: Sergey Matveychuk User-Agent: Thunderbird 2.0.0.9 (X11/20080127) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Subject: gprof: weird output 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, 10 Feb 2008 18:03:33 -0000 Hi. Why there are signed counters in gprof? It look weird: -0.20 -0.10 3749040/-2102105488 insert_overlayed [1800] 112.74 57.07 -2105854528/-2102105488 route2ro [4] [5] 76.3 112.53 56.97 -2102105488 ro_sort [5] 56.96 0.00 -447564710/-447429068 __bswap32 [6] 0.00 0.00 243125/94363371 strcmp [13] -- Dixi. Sem. From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 10 18:49: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 0930816A419 for ; Sun, 10 Feb 2008 18:49:18 +0000 (UTC) (envelope-from chuckr@chuckr.org) Received: from mail4.sea5.speakeasy.net (mail4.sea5.speakeasy.net [69.17.117.6]) by mx1.freebsd.org (Postfix) with ESMTP id 00C5D13C448 for ; Sun, 10 Feb 2008 18:49:17 +0000 (UTC) (envelope-from chuckr@chuckr.org) Received: (qmail 12029 invoked from network); 10 Feb 2008 18:49:17 -0000 Received: from april.chuckr.org (chuckr@[66.92.151.30]) (envelope-sender ) by mail4.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 10 Feb 2008 18:49:17 -0000 Message-ID: <47AF45EC.3000602@chuckr.org> Date: Sun, 10 Feb 2008 13:43:56 -0500 From: Chuck Robey User-Agent: Thunderbird 2.0.0.6 (X11/20071107) MIME-Version: 1.0 To: "Julian H. Stacey" References: <47ADFD2C.80009@chuckr.org> <200802091951.m19JpJfj096492@fire.js.berklix.net> <47AE0BFA.5030007@chuckr.org> <200802092216.m19MGgte098739@fire.js.berklix.net> <47AE2628.3070500@chuckr.org> <200802092334.m19NYUax000451@fire.js.berklix.net> In-Reply-To: <200802092334.m19NYUax000451@fire.js.berklix.net> X-Enigmail-Version: 0.95.5 OpenPGP: id=F3DCA0E9; url=http://pgp.mit.edu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-Hackers Subject: Re: USB Graphic Tablets 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, 10 Feb 2008 18:49:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Julian H. Stacey wrote: > Chuck Robey wrote: > Ah, sorry, forgot to say: Using a 2nd PC as traffic monitor. > > You'd issue probe from FreeBSD to USB device using whatever tools, > & the (Gasp! Wash my mouth out with soap!) - MS.EXE prog running > on a 2nd PC would trap a copy of traffic in each direction, > synchronising the 2 as well I believe though never tried it. The > 2nd monitoring (MS) PC uses 2 USB ports, one to copy FreeSBD PC to > tablet device traffic, & the other port to copy tablet to FreeBSD > traffic. ... & you have to make up a special USB cable, eg a male > to female USB extender cable, with tapped copies of signal in each > direction going to 2 extra USB connectors to 2 ports on 2nd monitor > PC. Sane developers seem to do that a lot on new unknown USB > scanners. > > >> but I know darn well you're right more often than I am, so I >> will give a good look at that list anyhow. > > Non tech flippancy: > Chuckle, dreadful thought to be wise! .. BBC's Hitchkikers Guide > To The Galaxy: To leader of bird people: "What do we call you ?" > "Well, some call me the wise .. old .. bird" ponderously said > by John Le Mesurier (Sergeant Wilson in BBC's 'Dad's Army') :-) Well, while I do have extra machines, none of them run MS, so that's no help for me. Kai Wang gave me an extremely nice kernel module, he's named it krepdump, and it's made a really remarkable report. I think I will cut and paste it here, it's obviously full of info, but I don't yet really know how to interpret it. I mailed a better description of the tablet to Kai separately (and also to the usb list), maybe that info might be of help in making sense of this: What follows is all from my dmesg. [report desc size=212] USAGE PAGE Digitizer(13) USAGE Pen(2) COLLECTION Application(1) REPORT ID 7 USAGE Stylus(32) COLLECTION Physical(0) USAGE Tip Switch(66) USAGE Barrel Switch(68) USAGE Eraser(69) LOGICAL MINIMUM 0 LOGICAL MAXIMUM 1 REPORT SIZE 1 REPORT COUNT 3 INPUT ( Data Variable Absolute ) (2) REPORT COUNT 3 INPUT ( Const Variable Absolute ) (3) USAGE In Range(50) REPORT COUNT 1 INPUT ( Data Variable Absolute ) (2) REPORT COUNT 1 INPUT ( Const Variable Absolute ) (3) USAGE PAGE Generic Desktop(1) USAGE X(48) REPORT SIZE 16 REPORT COUNT 1 PUSH UNIT EXPONENT 13 UNIT Seconds(51) PHYSICAL MINIMUM 0 PHYSICAL MAXIMUM 8000 LOGICAL MAXIMUM 16000 INPUT ( Data Variable Absolute ) (2) USAGE Y(49) PHYSICAL MAXIMUM 6000 LOGICAL MAXIMUM 12000 INPUT ( Data Variable Absolute ) (2) POP USAGE PAGE Digitizer(13) USAGE Tip Pressure(48) LOGICAL MAXIMUM 1023 INPUT ( Data Variable Absolute ) (2) REPORT SIZE 16 END COLLECTION END COLLECTION USAGE PAGE Generic Desktop(1) USAGE Mouse(2) COLLECTION Application(1) REPORT ID 8 USAGE Pointer(1) COLLECTION Physical(0) USAGE PAGE Button(9) USAGE MINIMUM Button1(1) USAGE MAXIMUM Button3(3) LOGICAL MINIMUM 0 LOGICAL MAXIMUM 1 REPORT COUNT 3 REPORT SIZE 1 INPUT ( Data Variable Absolute ) (2) REPORT COUNT 5 INPUT ( Const Array Absolute ) (1) USAGE PAGE Generic Desktop(1) USAGE X(48) USAGE Y(49) USAGE Wheel(56) USAGE Undefined(0) LOGICAL MINIMUM -127 LOGICAL MAXIMUM 127 REPORT SIZE 8 REPORT COUNT 4 INPUT ( Data Variable Relative ) (6) END COLLECTION END COLLECTION USAGE PAGE Generic Desktop(1) USAGE Mouse(2) COLLECTION Application(1) REPORT ID 9 USAGE Pointer(1) COLLECTION Physical(0) USAGE PAGE Button(9) USAGE MINIMUM Button1(1) USAGE MAXIMUM Button3(3) LOGICAL MINIMUM 0 LOGICAL MAXIMUM 1 REPORT COUNT 3 REPORT SIZE 1 INPUT ( Data Variable Absolute ) (2) REPORT COUNT 5 INPUT ( Const Array Absolute ) (1) USAGE PAGE Generic Desktop(1) USAGE X(48) USAGE Y(49) LOGICAL MINIMUM 0 LOGICAL MAXIMUM 32767 PHYSICAL MINIMUM 0 PHYSICAL MAXIMUM 32767 REPORT COUNT 2 REPORT SIZE 16 INPUT ( Data Variable Absolute ) (2) USAGE PAGE Digitizer(13) USAGE Tip Pressure(48) LOGICAL MAXIMUM 1023 REPORT COUNT 1 REPORT SIZE 16 INPUT ( Data Variable Absolute ) (2) END COLLECTION END COLLECTION ums0: on uhub0 ums0: X report 0x0002 not supported device_attach: ums0 attach returned 6 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHr0Xsz62J6PPcoOkRAvBWAKCWF2MEedgY8jnmOmmopS4m7Ww86wCgoEj7 /HeovqjS5bPdU4sbSlONdD4= =aplG -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 11 00:39:45 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 2A1AA16A418 for ; Mon, 11 Feb 2008 00:39:45 +0000 (UTC) (envelope-from mpp@mppsystems.com) Received: from lugdush.gulftel.com (lugdush.gulftel.com [216.231.163.39]) by mx1.freebsd.org (Postfix) with ESMTP id E491C13C467 for ; Mon, 11 Feb 2008 00:39:44 +0000 (UTC) (envelope-from mpp@mppsystems.com) Received: from localhost (localhost [127.0.0.1]) by lugdush.gulftel.com (Postfix) with ESMTP id C1848C40A; Sun, 10 Feb 2008 17:27:40 -0600 (CST) X-Virus-Scanned: amavisd-new at gulftel.com Received: from lugdush.gulftel.com ([127.0.0.1]) by localhost (lugdush.gulftel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLcW-YcQCaHo; Sun, 10 Feb 2008 17:27:36 -0600 (CST) Received: from mail.mppsystems.com (unknown [99.194.188.184]) by lugdush.gulftel.com (Postfix) with ESMTP id E5A81C388; Sun, 10 Feb 2008 17:27:34 -0600 (CST) Received: by mail.mppsystems.com (Postfix, from userid 1000) id 9146B17025; Sun, 10 Feb 2008 17:27:33 -0600 (CST) Date: Sun, 10 Feb 2008 17:27:33 -0600 From: Mike Pritchard To: Tod McQuillin Message-ID: <20080210232733.GA3240@mail.mppsystems.com> References: <20080209220206.695e5d9b.yngwiie@bk.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Mailman-Approved-At: Mon, 11 Feb 2008 00:57:25 +0000 Cc: freebsd-hackers@freebsd.org, Ivan Georgiev Subject: Re: quotactl returns double values 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, 11 Feb 2008 00:39:45 -0000 On Sun, Feb 10, 2008 at 01:04:24PM +0900, Tod McQuillin wrote: > On Sat, 9 Feb 2008, Ivan Georgiev wrote: > > >I was just playing, trying to see how quotactl works, > >but in all my tries the values returned are doubled, > > > >the values stored in my_st->dqb_bhardlimit and my_st->dqb_curblocks > >are the real values times two, the hard limit on the user is 102400K, > >but my_st->dqb_bhardlimit holds 204800K. > > I hope you are remembering that the limits are measured in blocks -- a block is > 512 bytes. > > Thus a limit of 102400K is 204800 blocks, since each 1K holds 2 blocks. You can also use "quota -r" to dump out the raw quota data. Simple answer is, internally the quota system maintains its block counts by counting the # of blocks that would be returned by stat(2) in the st_blocks field, which is the # of 512-byte blocks used by the file. Externally, (e.g. what it displays, takes as input) is 1024-byte blocks counts. -- Mike Pritchard mpp @ FreeBSD.org "If tyranny and oppression come to this land, it will be in the guise of fighting a foreign enemy." - James Madison (1787) From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 11 15:23:46 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 B525016A417 for ; Mon, 11 Feb 2008 15:23:46 +0000 (UTC) (envelope-from redcrash@gmail.com) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.187]) by mx1.freebsd.org (Postfix) with ESMTP id 429C213C46A for ; Mon, 11 Feb 2008 15:23:46 +0000 (UTC) (envelope-from redcrash@gmail.com) Received: by rn-out-0910.google.com with SMTP id s42so1844065rnb.13 for ; Mon, 11 Feb 2008 07:23:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=/+/qoSYGmbhDBsBlGTuV3tvcDZO0XMSvahTXH0HI3ms=; b=cpmrJYu+/hUWGm69aiLvgd6EOvErBvWfikhrieD3eNiQoJXFCPJwqYX+/6BNJLoNosnSt8qwgySqhhW1AOFNg9EI2vr7jm5A3fzQttLVfMkoc2n/TPl+pJqxaAFQtaV7wpdGij3jS2z9RW7kFBhRYBXKyr3TrlFkXi6PC4KG6So= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=DpyMfPWlsDKmO5h/ikODmj4f4CaFxiJjnQf0lvFPLLyrLEjpXwsb1gARXqvxIr4LPlk3lEh9jmfSqXF2WIFWAEwcUxS+oSBnCOyLk9x6jEt4ydfiuumNJ93cGjZHF2Wpn38VFhq22bHaTxWhgTfKW3ksAUru2oXjJrapA1FAKn8= Received: by 10.142.165.9 with SMTP id n9mr55806wfe.93.1202741886068; Mon, 11 Feb 2008 06:58:06 -0800 (PST) Received: by 10.142.143.9 with HTTP; Mon, 11 Feb 2008 06:58:06 -0800 (PST) Message-ID: Date: Mon, 11 Feb 2008 15:58:06 +0100 From: "Harald Servat" 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: backtrace call comparison 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, 11 Feb 2008 15:23:46 -0000 Hello list, I'm developing a tool that gathers the callstack information of an application at certain points. In order to do that, I use the "backtrace" (and its relative backtrace_symbols) call and I'm mailing you to share some results, thoughts & possible patches. When I compare the behaviour of the backtrace call on a FreeBSD 6.2 box and on Linux boxes I see that two levels of the callstack are missing. Using the example that can be found in http://www.gnu.org/software/libc/manual/html_node/Backtraces.html I see the following ( I present three commands here, compilation, run and translation of addresses using addr2line). FreeBSD output: ** #~/tests/seq/backtrace>gcc bt.c -o bt -rdynamic -g -I/usr/local/include -L/usr/local/lib/ -lexecinfo #~/tests/seq/backtrace>./bt Obtained 3 stack frames. 0x80486b3 at ./bt 0x80486d9 at ./bt 0x804856a <_start+118> at ./bt #~/tests/seq/backtrace>addr2line -e ./bt -f 0x80486b3 dummy_function /home/harald/tests/seq/backtrace/bt.c:30 0x80486d9 main /home/harald/tests/seq/backtrace/bt.c:36 0x804856a _start ??:0 Linux output: ** #>gcc -g -rdynamic ./bt.c -o bt #>./bt Obtained 5 stack frames. ./bt(print_trace+0x14) [0x8048668] ./bt(dummy_function+0xb) [0x80486e9] ./bt(main+0x15) [0x8048700] /lib/tls/libc.so.6(__libc_start_main+0xe4) [0x5d4ad4] ./bt [0x80485c5] #>addr2line -e ./bt -f 0x8048668 print_trace /home/des/harald/bt.c:14 0x80486e9 dummy_function /home/des/harald/bt.c:30 0x8048700 main /home/des/harald/bt.c:36 On the linux side we can see that there're two additional routines in the callstack. They're located on 0x8048668 and 0x80485c5. The latter seem to be related to the "trampoline" to run the application (i.e., to invoke the main) so I think this can be safely skipped, however the former it's the print_trace call which in fact is on the callstack but on the FreeBSD implementation it does not appear on the result. Thinking a bit more on this,... A programmer usually knows the routine that is running when he or she codes the application (unless he or she starts playing with the callstack manually with jumps and so), so in fact there's no real need to know the code is on print_trace. To emulate the Linux behaviour just add on level to the callstack that is the very same routine (in this case "print_trace"). So a possible patch for the example could be ... array[0] = (void*) print_trace; size = backtrace (&array[1], 10-1); size++; ... This does not give the same output because each entry of the array buffer points to the returning address of the callstack whereas array[0] is the first address of "print_trace" and not the returning address of backtrace itself. However it's enough for me. Regards, -- _________________________________________________________________ Empty your memory, with a free()... like a pointer! If you cast a pointer to an integer, it becomes an integer, if you cast a pointer to a struct, it becomes a struct. The pointer can crash..., and can overflow. Be a pointer my friend... From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 11 22:24:46 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 55F3B16A417; Mon, 11 Feb 2008 22:24:46 +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 C747A13C467; Mon, 11 Feb 2008 22:24:45 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 8B6B0744003; Tue, 12 Feb 2008 00:24:43 +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 10027) with ESMTP id iVkIyE8l+1M6; Tue, 12 Feb 2008 00:24:43 +0200 (EET) Received: from [10.74.70.239] (unknown [193.138.145.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 491FB744001; Tue, 12 Feb 2008 00:24:08 +0200 (EET) Message-ID: <47B0CAC8.2050603@icyb.net.ua> Date: Tue, 12 Feb 2008 00:23:04 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: Poul-Henning Kamp References: <200612221824.kBMIOhfM049471@freefall.freebsd.org> <47A2EDB0.8000801@icyb.net.ua> <47A2F404.7010208@icyb.net.ua> <47A7339E.4070708@icyb.net.ua> <47A73562.4010309@samsco.org> <47A9E062.3040409@icyb.net.ua> In-Reply-To: <47A9E062.3040409@icyb.net.ua> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-hackers@FreeBSD.org, Scott Long , Pav Lucistnik , Bruce Evans Subject: Re: fs/udf: vm pages "overlap" while reading large dir 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, 11 Feb 2008 22:24:46 -0000 on 06/02/2008 18:29 Andriy Gapon said the following: > Small summary of the above long description. > For directory reading fs/udf performs bread() on a (underlying) device > vnode. It passes block number as if block size was 512 bytes (i.e. > byte_offset_within_dev/512). On the other hand vm page index calculation > code uses the following formula: (blkno*bo_bsize)/PAGE_SIZE. > For CD/DVD devices bo_bsize is set to 2048. This results in page index > overlap when reading sufficiently many blocks from adjacent starting blocks. > That is, it seems that in "normal" cases page index gets calculated as > byte_offset/PAGE_SIZE, but in this case page index gets to be > 4*byte_offset/PAGE_SIZE. More details are in the quoted above text. > > With a lot of help from Bruce Evance I found this commit which seems to > have made a big difference: > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/vfs_bio.c.diff?r1=1.458;r2=1.459;f=h > > Before this change page index for device vnodes was always > (blkno*512)/PAGE_SIZE. This is because of the vn_isdisk() case. > > udf_mountfs device vnode is passed to g_vfs_open() (in geom_vfs.c) and > the latter has the following line of code: > bo->bo_bsize = pp->sectorsize; > Where pp is geom provider for the device in question. > > I am not sure if the mentioned above vfs_bio.c change broke something > else in reading from device vnodes or if it fixed something for that. I > am also not sure what would be the consequences of setting bo_bsize to > 512 for vnodes of "disk" devices. It would most probably fix current > code in UDF, but I am not sure if it might break anything else. > > Just wanted to let the more knowledgeable people know and make a decision. > > P.S. bo_bsize seems to be referenced only in a handful of files and in > most of them it seems that it is related to "file" vnodes (as opposed to > "device" vnodes). > Paul, do you have any comment or opinion on the above? [sorry if clamped too much of the previous context, but it's all in archives] And a little continuation: Just for the sake of experiment I tried to emulated the previous behavior by changing geom_vfs.c, function g_vfs_open(), so that the relevant code reads as follows: if (vn_isdisk(vp, NULL)) bo->bo_bsize = DEV_BSIZE; else bo->bo_bsize = pp->sectorsize; It didn't break anything for me and it re-enabled current (CVS) fs/udf code to work as before. (patch from kern/78987 still has to be applied for large directories to be handled). So udf (on DVD) is fixed, ufs (on HDD), msdosfs (on HDD) and cd9660 (on CD) are not broken. Of course, the change should have affected only filesystems on CD/DVD (where sector/block size is not 512 bytes). Of course, unlike Bruce I don't use msdosfs on CD/DVD media (e.g. DVD-RAM), so my test is somewhat incomplete. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 11 22:39: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 A72DC16A419; Mon, 11 Feb 2008 22:39:10 +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 23C9913C478; Mon, 11 Feb 2008 22:39:10 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id E156C43E41B; Tue, 12 Feb 2008 00:39:08 +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 10027) with ESMTP id dzAZRB52lhr7; Tue, 12 Feb 2008 00:39:08 +0200 (EET) Received: from [10.74.70.239] (unknown [193.138.145.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 2AA6A43E387; Tue, 12 Feb 2008 00:38:42 +0200 (EET) Message-ID: <47B0CE54.6090204@icyb.net.ua> Date: Tue, 12 Feb 2008 00:38:12 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: Poul-Henning Kamp References: <200612221824.kBMIOhfM049471@freefall.freebsd.org> <47A2EDB0.8000801@icyb.net.ua> <47A2F404.7010208@icyb.net.ua> <47A7339E.4070708@icyb.net.ua> <47A73562.4010309@samsco.org> <47A9E062.3040409@icyb.net.ua> In-Reply-To: <47A9E062.3040409@icyb.net.ua> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-hackers@FreeBSD.org, Scott Long , Pav Lucistnik , Bruce Evans Subject: Re: fs/udf: vm pages "overlap" while reading large dir 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, 11 Feb 2008 22:39:10 -0000 on 06/02/2008 18:29 Andriy Gapon said the following: > Small summary of the above long description. > For directory reading fs/udf performs bread() on a (underlying) device > vnode. It passes block number as if block size was 512 bytes (i.e. > byte_offset_within_dev/512). On the other hand vm page index calculation > code uses the following formula: (blkno*bo_bsize)/PAGE_SIZE. > For CD/DVD devices bo_bsize is set to 2048. This results in page index > overlap when reading sufficiently many blocks from adjacent starting blocks. > That is, it seems that in "normal" cases page index gets calculated as > byte_offset/PAGE_SIZE, but in this case page index gets to be > 4*byte_offset/PAGE_SIZE. More details are in the quoted above text. > > With a lot of help from Bruce Evance I found this commit which seems to > have made a big difference: > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/vfs_bio.c.diff?r1=1.458;r2=1.459;f=h > > Before this change page index for device vnodes was always > (blkno*512)/PAGE_SIZE. This is because of the vn_isdisk() case. > > udf_mountfs device vnode is passed to g_vfs_open() (in geom_vfs.c) and > the latter has the following line of code: > bo->bo_bsize = pp->sectorsize; > Where pp is geom provider for the device in question. > > I am not sure if the mentioned above vfs_bio.c change broke something > else in reading from device vnodes or if it fixed something for that. I > am also not sure what would be the consequences of setting bo_bsize to > 512 for vnodes of "disk" devices. It would most probably fix current > code in UDF, but I am not sure if it might break anything else. > > Just wanted to let the more knowledgeable people know and make a decision. > > P.S. bo_bsize seems to be referenced only in a handful of files and in > most of them it seems that it is related to "file" vnodes (as opposed to > "device" vnodes). > Poul-Henning, I am sorry for this duplicate post and very sorry for misspelling your name in the first one. do you have any comment or opinion on the above? [sorry if clamped too much of the previous context, but it's all in archives] And a little continuation: Just for the sake of experiment I tried to emulated the previous behavior by changing geom_vfs.c, function g_vfs_open(), so that the relevant code reads as follows: if (vn_isdisk(vp, NULL)) bo->bo_bsize = DEV_BSIZE; else bo->bo_bsize = pp->sectorsize; It didn't break anything for me and it re-enabled current (CVS) fs/udf code to work as before. (patch from kern/78987 still has to be applied for large directories to be handled). So udf (on DVD) is fixed, ufs (on HDD), msdosfs (on HDD) and cd9660 (on CD) are not broken. Of course, the change should have affected only filesystems on CD/DVD (where sector/block size is not 512 bytes). Of course, unlike Bruce I don't use msdosfs on CD/DVD media (e.g. DVD-RAM), so my test is somewhat incomplete. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 12 09:25:00 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 B585716A418; Tue, 12 Feb 2008 09:25:00 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 738FF13C461; Tue, 12 Feb 2008 09:25:00 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 999E117104; Tue, 12 Feb 2008 08:53:40 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m1C8rbF0003028; Tue, 12 Feb 2008 08:53:38 GMT (envelope-from phk@critter.freebsd.dk) To: Andriy Gapon From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 12 Feb 2008 00:38:12 +0200." <47B0CE54.6090204@icyb.net.ua> Date: Tue, 12 Feb 2008 08:53:37 +0000 Message-ID: <3027.1202806417@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-fs@FreeBSD.org, freebsd-hackers@FreeBSD.org, Scott Long , Pav Lucistnik , Bruce Evans Subject: Re: fs/udf: vm pages "overlap" while reading large dir 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, 12 Feb 2008 09:25:00 -0000 In message <47B0CE54.6090204@icyb.net.ua>, Andriy Gapon writes: >on 06/02/2008 18:29 Andriy Gapon said the following: >> Small summary of the above long description. >> For directory reading fs/udf performs bread() on a (underlying) device >> vnode. It passes block number as if block size was 512 bytes (i.e. >> byte_offset_within_dev/512). We have three sizes of relevance here, the sectorsize of the provider, the blocksize of the filesystem and the page size of the system. In general it is adventurous to have any of them be anything but powers of two, and it is at best ill-adviced and more likely asking for trouble to do requests that are not multiple of and aligned to the sectorsize of the provider. So up front, I would say that it is an UDF bug to do 512 byte reads off a 2k sector provider. Making the buffer cache handle this is possible, but it is not the direction we have planned for the buffercache (ie: that it should become a wrapper for using the VM system, rather than being a separately allocated cache). So if the objective is to make UDF work in the short term, your change might work, if the objective is to move FreeBSD's kernel architecture forward, the right thing to do is to fix UDF to not access subsectors. -- 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 Tue Feb 12 11:24: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 12F9E16A469; Tue, 12 Feb 2008 11:24:40 +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 7746113C45E; Tue, 12 Feb 2008 11:24:38 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id C710143D123; Tue, 12 Feb 2008 13:24:36 +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 Pnl6RIIlY1lj; Tue, 12 Feb 2008 13:24:36 +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 D19EA43D097; Tue, 12 Feb 2008 13:24:35 +0200 (EET) Message-ID: <47B181F2.2070808@icyb.net.ua> Date: Tue, 12 Feb 2008 13:24:34 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20080123) MIME-Version: 1.0 To: Poul-Henning Kamp References: <3027.1202806417@critter.freebsd.dk> In-Reply-To: <3027.1202806417@critter.freebsd.dk> Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-hackers@FreeBSD.org, Scott Long , Pav Lucistnik , Bruce Evans Subject: Re: fs/udf: vm pages "overlap" while reading large dir 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, 12 Feb 2008 11:24:40 -0000 on 12/02/2008 10:53 Poul-Henning Kamp said the following: > In message <47B0CE54.6090204@icyb.net.ua>, Andriy Gapon writes: >> on 06/02/2008 18:29 Andriy Gapon said the following: >>> Small summary of the above long description. >>> For directory reading fs/udf performs bread() on a (underlying) device >>> vnode. It passes block number as if block size was 512 bytes (i.e. >>> byte_offset_within_dev/512). > > We have three sizes of relevance here, the sectorsize of the provider, > the blocksize of the filesystem and the page size of the system. > > In general it is adventurous to have any of them be anything but > powers of two, and it is at best ill-adviced and more likely asking > for trouble to do requests that are not multiple of and aligned to > the sectorsize of the provider. > > So up front, I would say that it is an UDF bug to do 512 byte reads off > a 2k sector provider. > > Making the buffer cache handle this is possible, but it is not the > direction we have planned for the buffercache (ie: that it should > become a wrapper for using the VM system, rather than being a > separately allocated cache). > > So if the objective is to make UDF work in the short term, your > change might work, if the objective is to move FreeBSD's kernel > architecture forward, the right thing to do is to fix UDF to not > access subsectors. > Poul, I agree with what you say, but I think that I didn't properly explain what is UDF code doing and why it might be important in general. Let me try to do it step-by-step (sorry if I'll say something too obvious). And please correct me if I misunderstand something in the fundamental steps. 1.1. UDF is typically used with CD/DVD media, so provider's sector size is 2048. 1.2. udf vfs mount method calls g_vfs_open. 1.3. g_vfs_open creates vobject for a device vnode. 1.4. g_vfs_open sets bo_bsize=pp->sectorsize in the device vnode's bufobj. 1.5. g_vfs_open also overrides bo_ops for the bufobj. 2.1. UDF directory reading code performs bread() via the device vnode. [*] 2.2. this code passes to bread a size that is multiple of 2048. 2.3. this code passes to bread blkno that is calculated as 4*sector, where sector is a number of a physical 2048-byte sector. [**] [*] - this seems to be an uncommon thing among filesystems. [**] - I think that this is a requirement of buffcache system, because internally it performs many calculations that seem to assume that block size is always 512. E.g. breadn() code has the following: bp->b_iooffset = dbtob(bp->b_blkno); <-- effectively multiplies by 512 bstrategy(bp); And g_vfs_strategy has the following: bip->bio_offset = bp->b_iooffset; So, if udf code would pass blkno==sector, then bio_offset would be incorrect. Or maybe g_vfs_strategy should do some translation here from b_iooffset to bio_offset taking into account bo_bsize ?? So that the actual, non-adjusted, sector number could be passed to the bread() ? 3.1. for a fresh buf getlbk would assign the following: bsize = bo->bo_bsize; offset = blkno * bsize; ... bp->b_blkno = bp->b_lblkno = blkno; bp->b_offset = offset; <--- this is where this discussion started so b_offset of a buffer is 4*sector*2048. This is a source of the trouble. 3.2. getblk would set bp->b_flags |= B_VMIO; if a vnode has a vobject and our device vnode has it (step 1.3). 3.3. consequently allocbuf will execute code for B_VMIO case. 3.4. allocbuf will lookup/allocate pages by index which is calculated from "base index" of OFF_TO_IDX(bp->b_offset), which is, in essence, bp->b_offset divided by page size, 4096. So our "base index" is 2*sector. 4.1. Let's assume we bread() (via the device vnode, as described above) from physical sector N and we read 6 physical sectors (6*2048 bytes). 4.2 Sectors will get "mapped"/tied/bound to VM pages as follows (according to the above calculations): sectors[N, N+1] -> page[2*N], sectors[N+2, N+3] -> page[2*N + 1], /* the next page */ sectors[N+4, N+5] -> page[2*N + 2] /* the next page */ 4.5 Now lets consider "the next read" of X sectors but now starting from sector N+1; repeating the calculations we get the following mapping: sectors[(N+1), (N+1) + 1] -> page[2*(N+1)] = page[2N +2] But this page already has cached data from sectors[N+4, N+5]. Problem!! Theoretical calculations show it and practical testing confirms that. So this is a proof that bread()-ing via a device vnode is broken if: C1) the vnode was "set up" by g_vfs_open(); C2) sector size of underlying geom provider is not 512, but any non-trivial multiple of it; C3) bread size is sufficiently big; Current UDF code for directory reading is the only known to me place that meets all the 3 above conditions (for sufficiently large directories to meet condition C3). So I stated this, now let the wise speak. I already have a patch that makes UDF read directories via the directory vnodes. But the problem in general would remain. Maybe g_vfs_open is a correct place to change, maybe g_vfs_strategy is the place, maybe something, maybe "don't bother". I don't know. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 12 11:47: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 B3C9916A417; Tue, 12 Feb 2008 11:47:38 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 7004213C45B; Tue, 12 Feb 2008 11:47:38 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id CA95717104; Tue, 12 Feb 2008 11:47:36 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m1CBlYLx004300; Tue, 12 Feb 2008 11:47:34 GMT (envelope-from phk@critter.freebsd.dk) To: Andriy Gapon From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 12 Feb 2008 13:24:34 +0200." <47B181F2.2070808@icyb.net.ua> Date: Tue, 12 Feb 2008 11:47:34 +0000 Message-ID: <4299.1202816854@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-fs@FreeBSD.org, freebsd-hackers@FreeBSD.org, Pav Lucistnik , Bruce Evans Subject: Re: fs/udf: vm pages "overlap" while reading large dir 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, 12 Feb 2008 11:47:38 -0000 In message <47B181F2.2070808@icyb.net.ua>, Andriy Gapon writes: >2.3. this code passes to bread blkno that is calculated as 4*sector, >where sector is a number of a physical 2048-byte sector. [**] >[**] - I think that this is a requirement of buffcache system, because >internally it performs many calculations that seem to assume that block >size is always 512. Yes, the buf-cache works in 512 bytes units throughout. >3.1. for a fresh buf getlbk would assign the following: >bsize = bo->bo_bsize; >offset = blkno * bsize; That's clearly wrong. We need to assert that the blkno is aligned to the start of a sector and use the 512 byte units, so I guess it would be: offset = dbtob(blkno); KASSERT(!(offset & (bsize - 1)), ("suitable diagnostic")); -- 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 Tue Feb 12 12:33:24 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 A41AF16A41A; Tue, 12 Feb 2008 12:33:24 +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 4BE3413C4EF; Tue, 12 Feb 2008 12:33:24 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 3885C43E5F2; Tue, 12 Feb 2008 14:33:22 +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 FxO0vAEilxdU; Tue, 12 Feb 2008 14:33:22 +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 9276C43DB18; Tue, 12 Feb 2008 14:33:21 +0200 (EET) Message-ID: <47B19210.3010508@icyb.net.ua> Date: Tue, 12 Feb 2008 14:33:20 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20080123) MIME-Version: 1.0 To: Poul-Henning Kamp References: <4299.1202816854@critter.freebsd.dk> In-Reply-To: <4299.1202816854@critter.freebsd.dk> Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-hackers@FreeBSD.org, Pav Lucistnik , Bruce Evans Subject: Re: fs/udf: vm pages "overlap" while reading large dir 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, 12 Feb 2008 12:33:24 -0000 on 12/02/2008 13:47 Poul-Henning Kamp said the following: > In message <47B181F2.2070808@icyb.net.ua>, Andriy Gapon writes: > >> 2.3. this code passes to bread blkno that is calculated as 4*sector, >> where sector is a number of a physical 2048-byte sector. [**] >> [**] - I think that this is a requirement of buffcache system, because >> internally it performs many calculations that seem to assume that block >> size is always 512. > > Yes, the buf-cache works in 512 bytes units throughout. > >> 3.1. for a fresh buf getlbk would assign the following: >> bsize = bo->bo_bsize; >> offset = blkno * bsize; > > That's clearly wrong. > > We need to assert that the blkno is aligned to the start of a sector > and use the 512 byte units, so I guess it would be: > > offset = dbtob(blkno); > KASSERT(!(offset & (bsize - 1)), ("suitable diagnostic")); > > Thank you for this very insightful and neat suggestion! I think that it must work but I will try test it tonight on whatever media and FS-s I have available. Thank you again! P.S. hope to not get '"suitable diagnostic"' from something like msdosfs :-) -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 12 12:33: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 6CA3516A419; Tue, 12 Feb 2008 12:33:42 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail06.syd.optusnet.com.au (mail06.syd.optusnet.com.au [211.29.132.187]) by mx1.freebsd.org (Postfix) with ESMTP id EBEB513C4E8; Tue, 12 Feb 2008 12:33:41 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-219-213.carlnfd3.nsw.optusnet.com.au (c211-30-219-213.carlnfd3.nsw.optusnet.com.au [211.30.219.213]) by mail06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m1CCXa7n029892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Feb 2008 23:33:38 +1100 Date: Tue, 12 Feb 2008 23:33:36 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Poul-Henning Kamp In-Reply-To: <3027.1202806417@critter.freebsd.dk> Message-ID: <20080212220951.I92195@delplex.bde.org> References: <3027.1202806417@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Tue, 12 Feb 2008 13:45:45 +0000 Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, Pav Lucistnik , Andriy Gapon , Bruce Evans Subject: Re: fs/udf: vm pages "overlap" while reading large dir 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, 12 Feb 2008 12:33:42 -0000 On Tue, 12 Feb 2008, Poul-Henning Kamp wrote: > In message <47B0CE54.6090204@icyb.net.ua>, Andriy Gapon writes: >> on 06/02/2008 18:29 Andriy Gapon said the following: >>> Small summary of the above long description. >>> For directory reading fs/udf performs bread() on a (underlying) device >>> vnode. It passes block number as if block size was 512 bytes (i.e. >>> byte_offset_within_dev/512). > > We have three sizes of relevance here, the sectorsize of the provider, > the blocksize of the filesystem and the page size of the system. 4. The block size required for bread() and friends (almost always DEV_BSIZE). > In general it is adventurous to have any of them be anything but > powers of two, and it is at best ill-adviced and more likely asking > for trouble to do requests that are not multiple of and aligned to > the sectorsize of the provider. > > So up front, I would say that it is an UDF bug to do 512 byte reads off > a 2k sector provider. > > Making the buffer cache handle this is possible, but it is not the > direction we have planned for the buffercache (ie: that it should > become a wrapper for using the VM system, rather than being a > separately allocated cache). > > So if the objective is to make UDF work in the short term, your > change might work, if the objective is to move FreeBSD's kernel > architecture forward, the right thing to do is to fix UDF to not > access subsectors. This bug has nothing to do with subsectors, and very little to do with udf. udf is just depending on bread()'s API being unbroken. That API requires starting with blocks consisting of whole sectors (else the subsequent I/O would fail) and converting to blocks of size DEV_BSIZE, phyexcept for unusual (non-disk?) file systems like nfs (and no others?). All (?) disk file systems do this conversion. The bug is just more noticeable for udf since it is used more often on disks with a block size != DEV_BSIZE, and it apparently does something that makes the bug mess up VM more than other file systems. Of course, it might be better for the API to take blocks in units of the sector size, but that is not what it takes, and this can't be changed easily or safely. The standard macro btodb() is often used to convert from bytes to blocks of this size, and doesn't support bo_bsize or the bufobj pointer that would be needed to reach bo_bsize. ffs mostly uses its fsbtodb() macro, which converts blocks in ffs block (frag?)-sized units to blocks in DEV_BSIZE units so as to pass them to unbroken bread() and friends. ffs initializes bo_bsize to its block (not frag) size, and then never uses it directly except in ffs_rawread(), where it is used to check that the I/O is in units of whole sectors (otherwise, ffs_rawread() has DEV_BSIZE more hard-coded than the rest of ffs). The details of fsbtodb() are interesting. They show signs of previous attempts to use units of sectors. From ffs/fs.h: % /* % * Turn filesystem block numbers into disk block addresses. % * This maps filesystem blocks to device size blocks. % */ % #define fsbtodb(fs, b) ((daddr_t)(b) << (fs)->fs_fsbtodb) % #define dbtofsb(fs, b) ((b) >> (fs)->fs_fsbtodb) Creation of fs_fsbtodb is left to newfs. The units of DEV_BSIZE are thus built in to the on-disk data struct (in a fairly easy to change and/or override way, but there are a lot of existing disks). From newfs.c: % realsectorsize = sectorsize; % if (sectorsize != DEV_BSIZE) { /* XXX */ % int secperblk = sectorsize / DEV_BSIZE; % % sectorsize = DEV_BSIZE; % fssize *= secperblk; % if (pp != NULL) % pp->p_size *= secperblk; % } % mkfs(pp, special); Though mkfs() appears to support disk blocks of size = sectorsize, its sectorsize parameter is hacked on here, so it always generates fs_fsbtodb and other derived parameters for disk blocks of size DEV_BSIZE, as is required for the unbroken bread() API. msdosfs is similar to ffs here, except it constructs the shift count at mount time, to arrange for always converting to DEV_BSIZE blocks for passing the bread() and friends. udf is effectively similar, but pessimal and disorganized. For the conversion for bread(), it uses btodb(). In udf_bmap(), it constructs a shift count on every call by subtracting DEV_BSHIFT from its block shift count. In udf_strategy(), on every call it constructs a multiplier instead of a shift count, by dividing its block size by DEV_BSIZE. It's weird that the strategy routing, which will soon end up sending sectors to the disk, is converting to DEV_BSIZE units, a size that cannot be the size for udf's normal media. cd9660 uses btodb() for one conversion for bread() and ( - DEV_BSHIFT) in 7 other conversions to DEV_BSIZE units. So it's surprising that any file systems work on CDs and DVDs. Maybe the bug affects udf more because udf crosses page boundaries more. It's also surprising that the bug has such small effects. This seems to be because the blkno arg to bread() and friends is little more than a cookie. Each fs's strategy routine converts it to a byte offset later, and could do this using any unique cookie, but actually uses a simple shift forth and back. All fs's are consistent in their conversion to and from DEV_BSIZE or other units. Not much more than getblk() needs more than a cookie or uses an inconsistent conversion to a byte offset. Bruce From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 12 13:11:35 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 2517116A469; Tue, 12 Feb 2008 13:11:35 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail18.syd.optusnet.com.au (mail18.syd.optusnet.com.au [211.29.132.199]) by mx1.freebsd.org (Postfix) with ESMTP id 9F37813C448; Tue, 12 Feb 2008 13:11:34 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-219-213.carlnfd3.nsw.optusnet.com.au (c211-30-219-213.carlnfd3.nsw.optusnet.com.au [211.30.219.213]) by mail18.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m1CDBSUA008800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Feb 2008 00:11:32 +1100 Date: Wed, 13 Feb 2008 00:11:28 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Poul-Henning Kamp In-Reply-To: <4299.1202816854@critter.freebsd.dk> Message-ID: <20080212234018.O92415@delplex.bde.org> References: <4299.1202816854@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Tue, 12 Feb 2008 13:45:56 +0000 Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, Pav Lucistnik , Andriy Gapon , Bruce Evans Subject: Re: fs/udf: vm pages "overlap" while reading large dir 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, 12 Feb 2008 13:11:35 -0000 On Tue, 12 Feb 2008, Poul-Henning Kamp wrote: > In message <47B181F2.2070808@icyb.net.ua>, Andriy Gapon writes: > >> 2.3. this code passes to bread blkno that is calculated as 4*sector, >> where sector is a number of a physical 2048-byte sector. [**] >> [**] - I think that this is a requirement of buffcache system, because >> internally it performs many calculations that seem to assume that block >> size is always 512. > > Yes, the buf-cache works in 512 bytes units throughout. I missed the dbtob() conversions in vfs_bio.c when I replied previously So blkno cannot be a cookie; it must be for a 512-block. So how did the cases where bsize != DEV_BSIZE in getblk() ever work? >> 3.1. for a fresh buf getlbk would assign the following: >> bsize = bo->bo_bsize; >> offset = blkno * bsize; > > That's clearly wrong. If units were always 512-blocks, then anything except bsize = DEV_BSIZE would be clearly wrong. Things aren't that simple (but probably should be). Even RELENG_3 has bsize = f_iosize (possibly != 512) for non-disks. That seems to include nfs(client). In fact, nfs_getcacheblk() does weird scaling which seems to be mainly to compensate for for weird scaling here. It calls getblk() with a bn arg that seems to be f_iosize units. Then at then end, for the VREG case, it sets bp->b_blkno to this bn scaled to normal DEV_BSIZE units. bp->b_blkno seems to have DEV_BSIZE units for all uses of it in nfs. > We need to assert that the blkno is aligned to the start of a sector > and use the 512 byte units, so I guess it would be: > > offset = dbtob(blkno); > KASSERT(!(offset & (bsize - 1)), ("suitable diagnostic")); Barely worth checking. The current bug has nothing to do with this. The offset is just wrong at this point, after using a scale factor that is inconsistent with the units of blkno, for all (?) disk (and other?) file systems whose sector size isn't 512. Bruce From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 12 13:59: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 10F2016A41A; Tue, 12 Feb 2008 13:59:18 +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 776DB13C4CE; Tue, 12 Feb 2008 13:59:17 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 935FF43D123; Tue, 12 Feb 2008 15:59:15 +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 UdP0cuSbTNyG; Tue, 12 Feb 2008 15:59:15 +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 C7A9A43CBDF; Tue, 12 Feb 2008 15:59:14 +0200 (EET) Message-ID: <47B1A631.1000504@icyb.net.ua> Date: Tue, 12 Feb 2008 15:59:13 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20080123) MIME-Version: 1.0 To: Bruce Evans References: <4299.1202816854@critter.freebsd.dk> <20080212234018.O92415@delplex.bde.org> In-Reply-To: <20080212234018.O92415@delplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, Poul-Henning Kamp , Pav Lucistnik , Bruce Evans Subject: Re: fs/udf: vm pages "overlap" while reading large dir 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, 12 Feb 2008 13:59:18 -0000 on 12/02/2008 15:11 Bruce Evans said the following: > On Tue, 12 Feb 2008, Poul-Henning Kamp wrote: > >> In message <47B181F2.2070808@icyb.net.ua>, Andriy Gapon writes: >> >>> 2.3. this code passes to bread blkno that is calculated as 4*sector, >>> where sector is a number of a physical 2048-byte sector. [**] >>> [**] - I think that this is a requirement of buffcache system, because >>> internally it performs many calculations that seem to assume that block >>> size is always 512. >> Yes, the buf-cache works in 512 bytes units throughout. > > I missed the dbtob() conversions in vfs_bio.c when I replied previously > So blkno cannot be a cookie; it must be for a 512-block. So how did > the cases where bsize != DEV_BSIZE in getblk() ever work? It seems that this is because specific VOP_STRATEGY and/or BO_STRATEGY kicked in and did the right thing, see below. >>> 3.1. for a fresh buf getlbk would assign the following: >>> bsize = bo->bo_bsize; >>> offset = blkno * bsize; >> That's clearly wrong. > > If units were always 512-blocks, then anything except bsize = DEV_BSIZE > would be clearly wrong. Things aren't that simple (but probably should > be). Even RELENG_3 has bsize = f_iosize (possibly != 512) for non-disks. O, I missed this obvious thing! Bruce, thank you for putting me back on the ground :-) Even in UDF case, when we bread() via a file or directory vnode we pass a logical 2048-byte block number (within the file) to bread(). In this case the code in getblk() does the right thing when it calculates offset as blkno * 2048. Calculating it assuming 512-byte units would be a disaster. And the actual reading works correctly because udf_strategy is called for such vnodes and it translates block numbers from physical to logical and also correctly re-calculates b_iooffset for actual reading. So b_iooffset value set in breadn() (using bdtob) is completely ignored. I remember that this is why g_vfs_* was my primary target. It seems that I revert my opinion back: either g_vfs_open should be smart about setting bo_bsize, or g_vfs_strategy should be smart about calculating bio_offset, or individual filesystems should not depend on g_vfs_* always doing the best thing for them. In any case, it seems that it is the g_vfs_* that is currently inconsistent: it sets bo_bsize to a somewhat arbitrary value, but expects that it would always be provided with correct b_iooffset (the latter being rigidly calculated via bdtob() in buffcache code). So this leaves filesystems dead in the water while reading via device vnode: provide blkno in 512-byte units - screw up VM cache, provide blkno in bo_bsize units - screw up reading from disk. Not sure if the FS-s should have wits to set bo_bsize properly and/or provide proper bo_ops - we are talking about a device vnode here. Should filesystems be involved in the business of setting its properties? Not sure. But it seems that there are many possibilities for "fixups" and various filesystems [have to] do stuff in their unique ways (*_STRATEGY, etc). -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 12 16:08: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 68B5916A41B; Tue, 12 Feb 2008 16:08:16 +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 1461613C44B; Tue, 12 Feb 2008 16:08:16 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 6327843E22E; Tue, 12 Feb 2008 18:08:14 +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 fSmxEWbeB4dd; Tue, 12 Feb 2008 18:08:14 +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 6D83343E905; Tue, 12 Feb 2008 18:08:13 +0200 (EET) Message-ID: <47B1C46C.2010906@icyb.net.ua> Date: Tue, 12 Feb 2008 18:08:12 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20080123) MIME-Version: 1.0 To: Bruce Evans References: <4299.1202816854@critter.freebsd.dk> <20080212234018.O92415@delplex.bde.org> <47B1A631.1000504@icyb.net.ua> <20080213015738.L24074@besplex.bde.org> In-Reply-To: <20080213015738.L24074@besplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, Poul-Henning Kamp , Pav Lucistnik , Bruce Evans Subject: Re: fs/udf: vm pages "overlap" while reading large dir 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, 12 Feb 2008 16:08:16 -0000 on 12/02/2008 17:58 Bruce Evans said the following: > On Tue, 12 Feb 2008, Andriy Gapon wrote: >> And the actual reading works correctly because udf_strategy is called >> for such vnodes and it translates block numbers from physical to logical >> and also correctly re-calculates b_iooffset for actual reading. So >> b_iooffset value set in breadn() (using bdtob) is completely ignored. > > Is this setting ever used (and the corresponding setting for writing) > ever used? Bruce, replying only to this part (digesting the others): yes, it is used by g_vfs_strategy which is a bufobj startegy after g_vfs_open. It passes b_iooffset as is to bio_offset. P.S. of course, I am speaking about the current sources - I know you have almost an OS of your own, kidding :-) -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 12 18:05: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 05AA416A417 for ; Tue, 12 Feb 2008 18:05:14 +0000 (UTC) (envelope-from freebsd.dev@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.226]) by mx1.freebsd.org (Postfix) with ESMTP id 76F7213C467 for ; Tue, 12 Feb 2008 18:05:13 +0000 (UTC) (envelope-from freebsd.dev@gmail.com) Received: by wr-out-0506.google.com with SMTP id 68so4586237wri.3 for ; Tue, 12 Feb 2008 10:05:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=tZwNLr/zDKLD339d3H/Dm8RF46gVI5cRRyz2+lkRdic=; b=m8TgNW9NKxUGtyiYavAP1+YupZsExmJSUjOeVDCNYBt1GxYnWDPsppOGqNCkVLQpOtLxd7y46Orr4u3qJXs8Y1PGVJcBdTa0eujemWiAOydjd3XR7i1a6aS5ncAYhGtTze8fAdVICa7X/HAxF1AIePaJHSnPoH5KxIkSfxJj3Pg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Ae3lpEUM/ThO7UYbH8p9OeN+EI9C1jtLZK0qZiXsj1nmO7BIbGUCT5zwGx+lRnkopAv0nFcr35n3qlJLj5kKfgl7o1Aj9AaE1PgB0joNVXcggHNXw+ldVXrP2HYFxfKkYX4PrZne3vLbwSzGosc/z02ZU9I+VHZMRaiESdYnHAs= Received: by 10.140.147.18 with SMTP id u18mr1141315rvd.202.1202839511244; Tue, 12 Feb 2008 10:05:11 -0800 (PST) Received: by 10.141.20.13 with HTTP; Tue, 12 Feb 2008 10:05:11 -0800 (PST) Message-ID: <50cd4e5f0802121005s191a7875s98ffe2ca512389bc@mail.gmail.com> Date: Tue, 12 Feb 2008 12:05:11 -0600 From: "Biks N" To: "Sam Leffler" In-Reply-To: <47AB7775.2040000@errno.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <50cd4e5f0802071222w1222d901o3ce8770b5f5725b4@mail.gmail.com> <47AB7775.2040000@errno.com> Cc: freebsd-hackers@freebsd.org Subject: Re: retrive data from mbuf chain 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, 12 Feb 2008 18:05:14 -0000 Hi, thanks to everyone for providing me with different ideas. First I am trying to use m_copydata() method because I think it will be easy for me to copy data back and forth (using m_copydataback() ). But right now I am having problem using m_copydata() function. I want to copy data in all mbufs (only payload but no tcp/ip header) except the first Mbuf in chain. If payload is small enough to fit within 1st mbuf then I don't need that either. I am getting kernel panic ( please see below). I can see custom message "Starting m_copydata()" in log file. So I assume the problem is due to incorrect parameter in m_copydata(). here is the sample of code I am trying to use: /********************************/ caddr_t my_data_copy = NULL; /* check if m_len < m_pkthdr.len */ if ( m->m_len < m->m_pkthdr.len ) { /* copy data if there are more than 1 Mbufs in Chain */ log (LOG_DEBUG,"Starting m_copydata() \n"); m_copydata( m, m->m_len , m->m_pkthdr.len - m->m_len , my_data_copy); log (LOG_DEBUG,"%d Byte of Data copied\n", m->m_pkthdr.len - m->m_len); } else { /* skip if there is only 1 MBUF */ //log (LOG_DEBUG,"There must Only 1 MBUF in chain\n"); } /********************************/ Kernel Panic: Feb 12 11:36:09 bsd1 /kernel: Fatal trap 12: page fault while in kernel mode Feb 12 11:36:09 bsd1 /kernel: fault virtual address = 0x0 Feb 12 11:36:09 bsd1 /kernel: fault code = supervisor write, page not present Feb 12 11:36:09 bsd1 /kernel: instruction pointer = 0x8:0xc024efc2 Feb 12 11:36:09 bsd1 /kernel: stack pointer = 0x10:0xd15e8d08 Feb 12 11:36:09 bsd1 /kernel: frame pointer = 0x10:0xd15e8d2c Feb 12 11:36:09 bsd1 /kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Feb 12 11:36:09 bsd1 /kernel: = DPL 0, pres 1, def32 1, gran 1 Feb 12 11:36:09 bsd1 /kernel: processor eflags = interrupt enabled, resume, IOPL = 0 Feb 12 11:36:09 bsd1 /kernel: current process = 154 (ping) Feb 12 11:36:09 bsd1 /kernel: interrupt mask = Feb 12 11:36:09 bsd1 /kernel: I am using "ping -s 1200 host" to send larger packets so that system creates at least 2 mbufs. ------------ On Feb 7, 2008 3:26 PM, Sam Leffler wrote: > > Biks N wrote: > > Hi, > > > > I am new to FreeBSD kernel programming. > > > > Currently I am trying to work on mbuf data manupulation. > > > > >From my understanding: data (payload) is stored into one or more mufs > > which are chained together through m_next pointer. > > > > Now, I need to retrive all data in mbuf chain ( mbufs linked by > > m_next). I am working ip_output() in netinet/ip_output.c > > > > Does there exist inbuilt function/macro to retrive all the data in mbuf chain? > > > > man 9 mbuf; look for m_copydata. > > Sam > > From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 12 19:51:30 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 327C016A46C for ; Tue, 12 Feb 2008 19:51:30 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id D28E113C447 for ; Tue, 12 Feb 2008 19:51:29 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (unknown [202.108.54.204]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTP id E9B7D28478 for ; Wed, 13 Feb 2008 03:51:28 +0800 (CST) Received: from localhost (unknown [202.108.54.204]) by tarsier.geekcn.org (Postfix) with ESMTP id 95237EB29B1; Wed, 13 Feb 2008 03:51:28 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([202.108.54.204]) by localhost (mail.geekcn.org [202.108.54.204]) (amavisd-new, port 10024) with ESMTP id 9nUbsXi6WHbq; Wed, 13 Feb 2008 03:51:23 +0800 (CST) Received: from charlie.delphij.net (71.5.7.139.ptr.us.xo.net [71.5.7.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id D768AEB2973; Wed, 13 Feb 2008 03:51:22 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:subject:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=WEEhHRbFt77Iic+Iywnsh5qi7mTpZLf4TJZu1/kEzjwNNw6bh8KQDXMHtkWvoVVOJ 5H/KfCu/FA6l92L916DCA== Message-ID: <47B1F8B7.7030803@delphij.net> Date: Tue, 12 Feb 2008 11:51:19 -0800 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20080122) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org X-Enigmail-Version: 0.95.5 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: valgrind or workalike on FreeBSD/amd64 7.0/8.0? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2008 19:51:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Is there anyone working on valgrind on newer FreeBSD releases, or some work-alikes? Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHsfi3i+vbBBjt66ARAnT6AJ9jkaR3SRcGnkb2+DELmnZxFNQxoACgiECb eNHfq6uxaeUh1X2D7DIYxmY= =swuy -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 12 15:58: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 A56C116A41B; Tue, 12 Feb 2008 15:58:21 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail16.syd.optusnet.com.au (mail16.syd.optusnet.com.au [211.29.132.197]) by mx1.freebsd.org (Postfix) with ESMTP id 34D7613C4DB; Tue, 12 Feb 2008 15:58:21 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c211-30-219-213.carlnfd3.nsw.optusnet.com.au [211.30.219.213]) by mail16.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m1CFwC0G014582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Feb 2008 02:58:18 +1100 Date: Wed, 13 Feb 2008 02:58:12 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Andriy Gapon In-Reply-To: <47B1A631.1000504@icyb.net.ua> Message-ID: <20080213015738.L24074@besplex.bde.org> References: <4299.1202816854@critter.freebsd.dk> <20080212234018.O92415@delplex.bde.org> <47B1A631.1000504@icyb.net.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Wed, 13 Feb 2008 02:15:00 +0000 Cc: Bruce Evans , freebsd-hackers@freebsd.org, freebsd-fs@freebsd.org, Poul-Henning Kamp , Pav Lucistnik , Bruce Evans Subject: Re: fs/udf: vm pages "overlap" while reading large dir 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, 12 Feb 2008 15:58:21 -0000 On Tue, 12 Feb 2008, Andriy Gapon wrote: > on 12/02/2008 15:11 Bruce Evans said the following: >> On Tue, 12 Feb 2008, Poul-Henning Kamp wrote: >> >>> In message <47B181F2.2070808@icyb.net.ua>, Andriy Gapon writes: >>>> 3.1. for a fresh buf getlbk would assign the following: >>>> bsize = bo->bo_bsize; >>>> offset = blkno * bsize; >>> That's clearly wrong. >> >> If units were always 512-blocks, then anything except bsize = DEV_BSIZE >> would be clearly wrong. Things aren't that simple (but probably should >> be). Even RELENG_3 has bsize = f_iosize (possibly != 512) for non-disks. > > O, I missed this obvious thing! Me too. > Bruce, thank you for putting me back on the ground :-) > Even in UDF case, when we bread() via a file or directory vnode we pass > a logical 2048-byte block number (within the file) to bread(). In this > case the code in getblk() does the right thing when it calculates offset > as blkno * 2048. Calculating it assuming 512-byte units would be a disaster. I think the size is mnt_stat.f_iosize in general (but not for device vnodes). > And the actual reading works correctly because udf_strategy is called > for such vnodes and it translates block numbers from physical to logical > and also correctly re-calculates b_iooffset for actual reading. So > b_iooffset value set in breadn() (using bdtob) is completely ignored. Is this setting ever used (and the corresponding setting for writing) ever used? > I remember that this is why g_vfs_* was my primary target. > It seems that I revert my opinion back: either g_vfs_open should be > smart about setting bo_bsize, or g_vfs_strategy should be smart about > calculating bio_offset, or individual filesystems should not depend on > g_vfs_* always doing the best thing for them. In fact, ffs already overrides the setting of bo_bsize for the device vnode to a different wrong setting -- g_vfs_open() sets the sector size, and ffs_mount() changes the setting to fs_bsize, but ffs actually needs the setting to be DEV_BSIZE (I think). Other bugs from this: - ffs_rawread wants the sector size, and it assumes that this is in bo_bsize for the device vnode, but ffs_mount() has changed this to fs_bsize. - multiple r/o mounts are supposed to work, but don't, since there is only one device vnode with a shared bufobj, but the bufobj needs to be per-file-system since all mounts write to it. Various bad things including panics result. There is a well-know panic from bo_private becoming garbage on unmount. I just noticed more possibilities for panics. bo_ops points to static storage, so it never becomes complete garbage. However, at least ffs sets it blindly early on in ffs_mountfs(), before looking at the file system to see if ffs can mount it. Thus if the file system is already mounted by another ffs, then ffs clobbers the other fs's bo_ops. The ffs mount will presumably fail, leaving bo_ops clobbered. Also, a successful g_vfs_open() has clobbered bo_ops, bo_private and bo_bsize a little earlier. g_vfs_open() is fundamental to looking at the file system, since I/O is not set up until it completes. Clobbering the pointers is most dangerous, but just clobbering bo_bsize breaks blkno calculations for any code that uses bo_bsize. Apart from these bugs, the fix for the blkno calculations for device vp's may be as simple as setting bo_bsize to DEV_BSIZE for the device vp of all disk file systems (since all disk file systems use expect this size). Currently, ffs seems to be the only file system that overrides g_vfs_open()'s default of the sector size. Nothing in any of fs/, gnu/fs/ and contrib/ references bo_bsize. > In any case, it seems that it is the g_vfs_* that is currently > inconsistent: it sets bo_bsize to a somewhat arbitrary value, but > expects that it would always be provided with correct b_iooffset (the > latter being rigidly calculated via bdtob() in buffcache code). So this > leaves filesystems dead in the water while reading via device vnode: > provide blkno in 512-byte units - screw up VM cache, provide blkno in > bo_bsize units - screw up reading from disk. I think I/O on the disk doesn't use bo_bsize, but only the sector size (to scale the byte count to a sector count). Otherwise, ffs's override would break I/O. geom is another place that has few references to bo_bsize -- it just clobbers it in g_vfs_open(). > Not sure if the FS-s should have wits to set bo_bsize properly and/or > provide proper bo_ops - we are talking about a device vnode here. > Should filesystems be involved in the business of setting its > properties? Not sure. Yes. They can set it more easily as they can tell g_vfs_open() what to set it to. Except, until the bugs are fixed properly, g_vfs_open() can more easily do tests to prevent clobbering. For bo_bsize and bo_ops, sharing a common value is safe and safe changes can be detected by setting to a special value on last unmount. For bo_private, a safety check would probably disallow multiple mounts (since cp is dynamically allocated (?)). Bruce From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 13 12:58: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 5DFBB16A419; Wed, 13 Feb 2008 12:58:34 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from postfix1-g20.free.fr (postfix1-g20.free.fr [212.27.60.42]) by mx1.freebsd.org (Postfix) with ESMTP id CD99813C461; Wed, 13 Feb 2008 12:58:33 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by postfix1-g20.free.fr (Postfix) with ESMTP id F15932299BBA; Wed, 13 Feb 2008 13:29:14 +0100 (CET) Received: from smtp5-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp5-g19.free.fr (Postfix) with ESMTP id BDE543F619D; Wed, 13 Feb 2008 13:29:12 +0100 (CET) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id 769AA3F618F; Wed, 13 Feb 2008 13:29:12 +0100 (CET) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 4D02E9BF12; Wed, 13 Feb 2008 12:24:25 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 3455F405B; Wed, 13 Feb 2008 13:24:25 +0100 (CET) Date: Wed, 13 Feb 2008 13:24:25 +0100 From: Jeremie Le Hen To: Ariff Abdullah Message-ID: <20080213122425.GC46629@obiwan.tataz.chchile.org> References: <47A4FF5F.9010604@gmail.com> <200802041003.22658.jhb@freebsd.org> <20080204215250.GA1526@roadrunner.spoerlein.net> <954C22ED-D865-4067-9FDE-4002EB445AED@0x58.com> <20080205172546.7caea944.ariff@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080205172546.7caea944.ariff@FreeBSD.org> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: aryeh.friedman@gmail.com, xistence@0x58.com, freebsd-hackers@freebsd.org Subject: Re: /dev/dsp disappeared after power outage 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, 13 Feb 2008 12:58:34 -0000 Hi, On Tue, Feb 05, 2008 at 05:25:46PM +0800, Ariff Abdullah wrote: > On Mon, 4 Feb 2008 15:14:49 -0700 > Bert JW Regeer wrote: > > I just booted up my desktop machine at home, I don't have sound > > enabled by default, so I loaded the module that is required. Before > > > > the module was loaded: > > > > ls -lah /dev/dsp* > > ls: No match. > > > > After the module was loaded (I just load snd_driver). Nothing else > > was executed after the module was loaded. > > > > ls -lah /dev/dsp* > > crw-rw-rw- 1 root wheel 0, 106 Jan 26 05:24 /dev/dsp0.0 > > crw-rw-rw- 1 root wheel 0, 109 Jan 26 05:24 /dev/dsp0.1 > > crw-rw-rw- 1 root wheel 0, 112 Jan 26 05:24 /dev/dsp0.2 > > crw-rw-rw- 1 root wheel 0, 115 Jan 26 05:24 /dev/dsp0.3 > > crw-rw-rw- 1 root wheel 0, 118 Jan 26 05:24 /dev/dsp0.4 > > crw-rw-rw- 1 root wheel 0, 122 Jan 26 05:24 /dev/dsp0.5 > > crw-rw-rw- 1 root wheel 0, 107 Jan 26 05:24 /dev/dspW0.0 > > crw-rw-rw- 1 root wheel 0, 110 Jan 26 05:24 /dev/dspW0.1 > > crw-rw-rw- 1 root wheel 0, 113 Jan 26 05:24 /dev/dspW0.2 > > crw-rw-rw- 1 root wheel 0, 116 Jan 26 05:24 /dev/dspW0.3 > > crw-rw-rw- 1 root wheel 0, 119 Jan 26 05:24 /dev/dspW0.4 > > crw-rw-rw- 1 root wheel 0, 123 Jan 26 05:24 /dev/dspW0.5 > > crw-rw-rw- 1 root wheel 0, 121 Jan 26 05:24 /dev/dspr0.4 > ^^^^^^^^^^^^ > Yours is obviously 6.x . > > Beginning with 7.x and beyond, nothing will be created by default, > just like what the original poster being experiencing. Refer to > sound(4). BTW, is it possible to tighten sound(4) permissions with devfs.conf(5)? With something like: % own pcm0 root:audio % perm pcm0 0660 Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 13 13:04: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 6DA9F16A418; Wed, 13 Feb 2008 13:04:40 +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 DEC7213C4E1; Wed, 13 Feb 2008 13:04:39 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id BEA1243F36C; Wed, 13 Feb 2008 15:04:37 +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 fnqWw7irepm9; Wed, 13 Feb 2008 15:04:37 +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 3498343F366; Wed, 13 Feb 2008 15:04:36 +0200 (EET) Message-ID: <47B2EAE3.3010600@icyb.net.ua> Date: Wed, 13 Feb 2008 15:04:35 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20080123) MIME-Version: 1.0 To: Bruce Evans References: <4299.1202816854@critter.freebsd.dk> <20080212234018.O92415@delplex.bde.org> <47B1A631.1000504@icyb.net.ua> <20080213015738.L24074@besplex.bde.org> In-Reply-To: <20080213015738.L24074@besplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, Poul-Henning Kamp , freebsd-arch@freebsd.org Subject: device/disk vnode use by filesystems: vfs_bio, geom_vfs 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, 13 Feb 2008 13:04:40 -0000 I changed Subject to reflect more general discussion than what we originally had (UDF specifics). I also CC arch, because, I think, these issues are core architectural/design issues. ufs/ffs is quite a complex beast, I don't pretend I understand its internal workings well. on 12/02/2008 17:58 Bruce Evans said the following: > In fact, ffs already overrides the setting of bo_bsize for the device > vnode to a different wrong setting -- g_vfs_open() sets the sector size, > and ffs_mount() changes the setting to fs_bsize, but ffs actually needs > the setting to be DEV_BSIZE (I think). Latest ffs code doesn't seem to do that. It calls g_vfs_open which sets bo_bsize on disk vnode and that's it. The code does override indeed bo_ops from those that were set by g_vfs_open. What you said is done in ffs_vget, it assigns bo_bsize=fs_bsize for new vnodes for ffs files. > Other bugs from this: > - ffs_rawread wants the sector size, and it assumes that this is in bo_bsize > for the device vnode, but ffs_mount() has changed this to fs_bsize. In the latest code this is not true. bo_bsize is underlying GEOM provider's sector size ("device sector size"). > - multiple r/o mounts are supposed to work, but don't, since there is only > one device vnode with a shared bufobj, but the bufobj needs to be > per-file-system since all mounts write to it. Various bad things > including panics result. There is a well-know panic from bo_private > becoming garbage on unmount. I agree. Here's another example (more familiar to me) - many DVD disks have both CD9660 and UDF fs structures referencing the same data. mkisofs can also produce such images with -udf option. In theory, there should be nothing that would prevent simultaneous RO mount of such a disk via both methods. In practice at least bo_private would be overridden by the second mount. Well, even two simultaneous RO CD9660 mounts of the same device can/will result in a problem (at least one umount). I agree that this is indeed an architectural problem. Concurrent filesystems using the same device should not fight over its vnode/bufobj. They should get their private structures, but I have no idea how. > I just noticed more possibilities for > panics. bo_ops points to static storage, so it never becomes complete > garbage. However, at least ffs sets it blindly early on in > ffs_mountfs(), before looking at the file system to see if ffs can > mount it. Thus if the file system is already mounted by another > ffs, then ffs clobbers the other fs's bo_ops. The ffs mount will > presumably fail, leaving bo_ops clobbered. I agree. > Also, a successful > g_vfs_open() has clobbered bo_ops, bo_private and bo_bsize a little > earlier. I agree. > g_vfs_open() is fundamental to looking at the file system, > since I/O is not set up until it completes. Clobbering the pointers > is most dangerous, but just clobbering bo_bsize breaks blkno > calculations for any code that uses bo_bsize. I don't think there is any current code that uses bo_bsize for this purpose. > Apart from these bugs, the fix for the blkno calculations for device > vp's may be as simple as setting bo_bsize to DEV_BSIZE for the device > vp of all disk file systems (since all disk file systems use expect > this size). Currently, ffs seems to be the only file system that > overrides g_vfs_open()'s default of the sector size. Nothing in any > of fs/, gnu/fs/ and contrib/ references bo_bsize. It is the first possibility. And I actually currently run a system with this patch in place and do not see any regressions. Another possibility, which requires more changes but is more "elegant" (in my opinion), is to keep bo_bsize as it is. Instead, always use non-adjusted block numbers in bread*/bwrite and modify g_vfs_strategy to set bio_offset to blkno*bo_bsize. That is, filesystems would not have to hack block numbers via shifting them by (bshift - DEV_BSHIFT). In this case the code should be very similar whether you work via a device vnode or via a file vnode. This is because filesystems already pass logical block number when they work via a file vnode. > > Yes. They can set it more easily as they can tell g_vfs_open() what to > set it to. Except, until the bugs are fixed properly, g_vfs_open() can > more easily do tests to prevent clobbering. For bo_bsize and bo_ops, > sharing a common value is safe and safe changes can be detected by > setting to a special value on last unmount. For bo_private, a safety > check would probably disallow multiple mounts (since cp is dynamically > allocated (?)). I agree. We either should prohibit a concurrent use of a device vnode by multiple filesystems; or should have some reference counting - maybe this would work for multiple mounts for the same fs type; or design some way to have that data private to filesystems. One tough thing here is a lack of encapsulation: g_vfs_open can make its own changes in v_bufobj, then filesystem code can modify it further, so there is no single point of control. The simplest solution is to disallow this practice altogether. Another approach that comes to my mind is some kind of vnode "cloning", so that each filesystem has its own device vnode. This should work for multiple RO mounts, maybe with some resource usage penalties. RW mounts must be exclusive of course. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 14 07:12: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 6FB9A16A477 for ; Thu, 14 Feb 2008 07:12:21 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from frontmail.ipactive.de (frontmail.maindns.de [85.214.95.103]) by mx1.freebsd.org (Postfix) with ESMTP id 12A1713C44B for ; Thu, 14 Feb 2008 07:12:20 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from mail.vtec.ipme.de (Q7d7c.q.ppp-pool.de [89.53.125.124]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by frontmail.ipactive.de (Postfix) with ESMTP id 73144128844 for ; Thu, 14 Feb 2008 07:39:40 +0100 (CET) Received: from cesar.sz.vwsoft.com (cesar.sz.vwsoft.com [192.168.16.3]) by mail.vtec.ipme.de (Postfix) with ESMTP id 1D2573F443 for ; Thu, 14 Feb 2008 07:37:54 +0100 (CET) Message-ID: <47B3E21F.1010202@vwsoft.com> Date: Thu, 14 Feb 2008 07:39:27 +0100 From: Volker User-Agent: Thunderbird 2.0.0.9 (X11/20080125) MIME-Version: 1.0 To: hackers@freebsd.org X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit MailScanner-NULL-Check: 1203575884.25976@swJCVhKLy/f2+CshRFrHBQ X-VWSoft-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com X-ipactive-MailScanner-Information: Please contact the ISP for more information X-ipactive-MailScanner: Found to be clean X-ipactive-MailScanner-From: volker@vwsoft.com Cc: Subject: licensing question APSL 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, 14 Feb 2008 07:12:21 -0000 While working through the PR backlog, I found two PRs filed containing source code for two tools (decomment, relpath) under the Apple Public Source License (APSL). I think these tools aren't that bad but before pinging any committer with that, I thought I might throw the question on the table: What about importing code under the APSL license? Has there been any consensus in the past about that license? I'm not a lawyer but the license seems to be reasonable suited for the BSD projects. PRs in question: bin/67307 bin/67308 PR submitter is the author of the tools. Thanks Volker From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 14 15:02:02 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 E5ACB16A418 for ; Thu, 14 Feb 2008 15:02:02 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5FA8513C4EA for ; Thu, 14 Feb 2008 15:02:02 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.1/8.13.8) with ESMTP id m1EF21Gq018915; Thu, 14 Feb 2008 09:02:01 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.1/8.13.8/Submit) id m1EF21O3018914; Thu, 14 Feb 2008 09:02:01 -0600 (CST) (envelope-from brooks) Date: Thu, 14 Feb 2008 09:02:01 -0600 From: Brooks Davis To: Volker Message-ID: <20080214150200.GB18534@lor.one-eyed-alien.net> References: <47B3E21F.1010202@vwsoft.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3uo+9/B/ebqu+fSQ" Content-Disposition: inline In-Reply-To: <47B3E21F.1010202@vwsoft.com> User-Agent: Mutt/1.5.16 (2007-06-09) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Thu, 14 Feb 2008 09:02:01 -0600 (CST) Cc: hackers@freebsd.org Subject: Re: licensing question APSL 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, 14 Feb 2008 15:02:03 -0000 --3uo+9/B/ebqu+fSQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 14, 2008 at 07:39:27AM +0100, Volker wrote: > While working through the PR backlog, I found two PRs filed containing > source code for two tools (decomment, relpath) under the Apple Public > Source License (APSL). >=20 > I think these tools aren't that bad but before pinging any committer > with that, I thought I might throw the question on the table: What > about importing code under the APSL license? Has there been any > consensus in the past about that license? >=20 > I'm not a lawyer but the license seems to be reasonable suited for the > BSD projects. >=20 > PRs in question: bin/67307 bin/67308 The quotes on the followup are essentially correct except that explicit approval is required by core to add new Non-BSD-Licensed code and that there would need to be a mechanism to not build them as part of buildworld to allow environments that do not want to deal with the APSL to avoid it similar to GPL or CDDL code. -- Brooks --3uo+9/B/ebqu+fSQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFHtFe9XY6L6fI4GtQRAlVJAJ4sBR9SrbPruCc0+ouy1iYDRbSvfwCdG/3T TTpxvM/4HAsehAWroyPtSjw= =gyDi -----END PGP SIGNATURE----- --3uo+9/B/ebqu+fSQ-- From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 14 16:13:30 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 2290E16A418 for ; Thu, 14 Feb 2008 16:13:30 +0000 (UTC) (envelope-from st@anti-virus.by) Received: from tux.vba.com.by (vbaltd.vba.com.by [193.232.92.242]) by mx1.freebsd.org (Postfix) with ESMTP id 9515E13C505 for ; Thu, 14 Feb 2008 16:13:29 +0000 (UTC) (envelope-from st@anti-virus.by) Received: from st.vba.com.by (unknown [192.168.234.44]) by tux.vba.com.by (Postfix) with ESMTP id EE97AC4DCD for ; Thu, 14 Feb 2008 17:46:51 +0200 (EET) Date: Thu, 14 Feb 2008 17:46:45 +0200 From: Sergei Trofimovich To: freebsd-hackers@freebsd.org Message-ID: <20080214174645.5bdb2879@st.vba.com.by> Organization: VBA Ltd. X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.5; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/df3kCDDEh.F=AXwgOEs.pM/" X-Mailman-Approved-At: Thu, 14 Feb 2008 17:35:41 +0000 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: x86: sigaltstack problems 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, 14 Feb 2008 16:13:30 -0000 --MP_/df3kCDDEh.F=AXwgOEs.pM/ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Attached file causes segfaults on freebsd 4,5,6 but keeps alive in linux. IANIAML, so please CC me explicitly. Thanks! --MP_/df3kCDDEh.F=AXwgOEs.pM/-- From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 14 18:55:35 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 F36F116A417 for ; Thu, 14 Feb 2008 18:55:34 +0000 (UTC) (envelope-from rink@tragedy.rink.nu) Received: from mx1.rink.nu (alastor.rink.nu [213.34.49.5]) by mx1.freebsd.org (Postfix) with ESMTP id BF66413C455 for ; Thu, 14 Feb 2008 18:55:34 +0000 (UTC) (envelope-from rink@tragedy.rink.nu) Received: from localhost (alastor.rink.nu [213.34.49.5]) by mx1.rink.nu (Postfix) with ESMTP id 8D57CBFEC7C; Thu, 14 Feb 2008 18:39:38 +0000 (UTC) X-Virus-Scanned: amavisd-new at rink.nu Received: from mx1.rink.nu ([213.34.49.5]) by localhost (alastor.rink.nu [213.34.49.5]) (amavisd-new, port 10024) with ESMTP id XSrdAWekOSxS; Thu, 14 Feb 2008 18:39:28 +0000 (UTC) Received: from tragedy.rink.nu (tragedy.rink.nu [213.34.49.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.rink.nu (Postfix) with ESMTP id F20B1BFEB7A; Thu, 14 Feb 2008 18:39:27 +0000 (UTC) Received: from tragedy.rink.nu (tragedy.rink.nu [213.34.49.3]) by tragedy.rink.nu (8.13.8/8.13.8) with ESMTP id m1EIdRIc029794; Thu, 14 Feb 2008 19:39:27 +0100 (CET) (envelope-from rink@tragedy.rink.nu) Received: (from rink@localhost) by tragedy.rink.nu (8.13.8/8.13.8/Submit) id m1EIdRKq029793; Thu, 14 Feb 2008 19:39:27 +0100 (CET) (envelope-from rink) Date: Thu, 14 Feb 2008 19:39:27 +0100 From: Rink Springer To: Sergei Trofimovich Message-ID: <20080214183926.GB6162@rink.nu> References: <20080214174645.5bdb2879@st.vba.com.by> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080214174645.5bdb2879@st.vba.com.by> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-hackers@freebsd.org Subject: Re: x86: sigaltstack problems 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, 14 Feb 2008 18:55:35 -0000 On Thu, Feb 14, 2008 at 05:46:45PM +0200, Sergei Trofimovich wrote: > Attached file causes segfaults on freebsd 4,5,6 > but keeps alive in linux. Which attached file? :-) -- Rink P.W. Springer - http://rink.nu "Anyway boys, this is America. Just because you get more votes doesn't mean you win." - Fox Mulder From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 14 19:02:14 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 4E86816A47B for ; Thu, 14 Feb 2008 19:02:14 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from frontmail.ipactive.de (frontmail.maindns.de [85.214.95.103]) by mx1.freebsd.org (Postfix) with ESMTP id 1A3BE13C447 for ; Thu, 14 Feb 2008 19:02:12 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from mail.vtec.ipme.de (Q7d7c.q.ppp-pool.de [89.53.125.124]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by frontmail.ipactive.de (Postfix) with ESMTP id 86B39128844; Thu, 14 Feb 2008 20:02:05 +0100 (CET) Received: from cesar.sz.vwsoft.com (cesar.sz.vwsoft.com [192.168.16.3]) by mail.vtec.ipme.de (Postfix) with ESMTP id 55B813F443; Thu, 14 Feb 2008 20:00:23 +0100 (CET) Message-ID: <47B49023.20204@vwsoft.com> Date: Thu, 14 Feb 2008 20:01:55 +0100 From: Volker User-Agent: Thunderbird 2.0.0.9 (X11/20080125) MIME-Version: 1.0 To: Brooks Davis References: <47B3E21F.1010202@vwsoft.com> <20080214150200.GB18534@lor.one-eyed-alien.net> In-Reply-To: <20080214150200.GB18534@lor.one-eyed-alien.net> X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit MailScanner-NULL-Check: 1203620431.16006@LurJTlATvlsgh1RZRdH9Kg X-VWSoft-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com X-ipactive-MailScanner-Information: Please contact the ISP for more information X-ipactive-MailScanner: Found to be clean X-ipactive-MailScanner-From: volker@vwsoft.com Cc: hackers@freebsd.org Subject: Re: licensing question APSL 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, 14 Feb 2008 19:02:14 -0000 On 02/14/08 16:02, Brooks Davis wrote: > On Thu, Feb 14, 2008 at 07:39:27AM +0100, Volker wrote: >> PRs in question: bin/67307 bin/67308 > > The quotes on the followup are essentially correct except that explicit > approval is required by core to add new Non-BSD-Licensed code and > that there would need to be a mechanism to not build them as part of > buildworld to allow environments that do not want to deal with the APSL > to avoid it similar to GPL or CDDL code. Brooks, thank you for your opinion on that. The PR followup stating the APSL license is ok, has been the statement of the original PR submitter, so I don't trust that in the first place. That's why I was asking here for that license if there's a common agreement. So I can assume the APSL license is (still) generally accepted for the BSDs? If nobody complains about the APSL, I'll ping core for a green flag. Thanks Volker From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 14 19:17:39 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 43BC316A418 for ; Thu, 14 Feb 2008 19:17:39 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id BBA0213C459 for ; Thu, 14 Feb 2008 19:17:38 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.1/8.13.8) with ESMTP id m1EJHbnv021020; Thu, 14 Feb 2008 13:17:37 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.1/8.13.8/Submit) id m1EJHb2p021019; Thu, 14 Feb 2008 13:17:37 -0600 (CST) (envelope-from brooks) Date: Thu, 14 Feb 2008 13:17:37 -0600 From: Brooks Davis To: Volker Message-ID: <20080214191737.GA20098@lor.one-eyed-alien.net> References: <47B3E21F.1010202@vwsoft.com> <20080214150200.GB18534@lor.one-eyed-alien.net> <47B49023.20204@vwsoft.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bp/iNruPH9dso1Pn" Content-Disposition: inline In-Reply-To: <47B49023.20204@vwsoft.com> User-Agent: Mutt/1.5.16 (2007-06-09) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Thu, 14 Feb 2008 13:17:37 -0600 (CST) Cc: hackers@freebsd.org Subject: Re: licensing question APSL 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, 14 Feb 2008 19:17:39 -0000 --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 14, 2008 at 08:01:55PM +0100, Volker wrote: > On 02/14/08 16:02, Brooks Davis wrote: > > On Thu, Feb 14, 2008 at 07:39:27AM +0100, Volker wrote: > >> PRs in question: bin/67307 bin/67308 > >=20 > > The quotes on the followup are essentially correct except that explicit > > approval is required by core to add new Non-BSD-Licensed code and > > that there would need to be a mechanism to not build them as part of > > buildworld to allow environments that do not want to deal with the APSL > > to avoid it similar to GPL or CDDL code. >=20 > Brooks, >=20 > thank you for your opinion on that. The PR followup stating the APSL > license is ok, has been the statement of the original PR submitter, so I > don't trust that in the first place. That's why I was asking here for > that license if there's a common agreement. >=20 > So I can assume the APSL license is (still) generally accepted for the BS= Ds? APSL is not generally accepted in the base. It may be acceptable in certain circumstances, but strong technical justification is generally required for inclusion. -- Brooks > If nobody complains about the APSL, I'll ping core for a green flag. >=20 > Thanks >=20 > Volker > _______________________________________________ > 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" >=20 --bp/iNruPH9dso1Pn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFHtJPQXY6L6fI4GtQRAncyAJ9V2p9+fT1tseVmtLGj1SmVZgitCQCfdmbG YlGEP9ZGhl1RIy8mi/Z1+58= =LX0r -----END PGP SIGNATURE----- --bp/iNruPH9dso1Pn-- From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 14 19:47:24 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 3336D16A418; Thu, 14 Feb 2008 19:47:24 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from frontmail.ipactive.de (frontmail.maindns.de [85.214.95.103]) by mx1.freebsd.org (Postfix) with ESMTP id 001B213C45D; Thu, 14 Feb 2008 19:47:23 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from mail.vtec.ipme.de (Q7d7c.q.ppp-pool.de [89.53.125.124]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by frontmail.ipactive.de (Postfix) with ESMTP id 3F834128844; Thu, 14 Feb 2008 20:47:16 +0100 (CET) Received: from cesar.sz.vwsoft.com (cesar.sz.vwsoft.com [192.168.16.3]) by mail.vtec.ipme.de (Postfix) with ESMTP id 3BC503F43B; Thu, 14 Feb 2008 20:45:31 +0100 (CET) Message-ID: <47B49AB6.1040609@vwsoft.com> Date: Thu, 14 Feb 2008 20:47:02 +0100 From: Volker User-Agent: Thunderbird 2.0.0.9 (X11/20080125) MIME-Version: 1.0 To: Brooks Davis References: <47B3E21F.1010202@vwsoft.com> <20080214150200.GB18534@lor.one-eyed-alien.net> <47B49023.20204@vwsoft.com> <20080214191737.GA20098@lor.one-eyed-alien.net> In-Reply-To: <20080214191737.GA20098@lor.one-eyed-alien.net> X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit MailScanner-NULL-Check: 1203623142.04387@RpwMkqPxnOl7DzS37wt8VQ X-VWSoft-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com X-ipactive-MailScanner-Information: Please contact the ISP for more information X-ipactive-MailScanner: Found to be clean X-ipactive-MailScanner-From: volker@vwsoft.com Cc: hackers@freebsd.org Subject: Re: licensing question APSL 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, 14 Feb 2008 19:47:24 -0000 On 02/14/08 20:17, Brooks Davis wrote: > APSL is not generally accepted in the base. It may be acceptable in > certain circumstances, but strong technical justification is generally > required for inclusion. Brooks, so better put that into the ports tree? Thanks Volker From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 14 19:59:11 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 42FA416A41B; Thu, 14 Feb 2008 19:59:11 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id D484113C458; Thu, 14 Feb 2008 19:59:10 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.1/8.13.8) with ESMTP id m1EJx9HV022704; Thu, 14 Feb 2008 13:59:09 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.1/8.13.8/Submit) id m1EJx9bH022703; Thu, 14 Feb 2008 13:59:09 -0600 (CST) (envelope-from brooks) Date: Thu, 14 Feb 2008 13:59:09 -0600 From: Brooks Davis To: Volker Message-ID: <20080214195909.GA21030@lor.one-eyed-alien.net> References: <47B3E21F.1010202@vwsoft.com> <20080214150200.GB18534@lor.one-eyed-alien.net> <47B49023.20204@vwsoft.com> <20080214191737.GA20098@lor.one-eyed-alien.net> <47B49AB6.1040609@vwsoft.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ew6BAiZeqk4r7MaW" Content-Disposition: inline In-Reply-To: <47B49AB6.1040609@vwsoft.com> User-Agent: Mutt/1.5.16 (2007-06-09) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Thu, 14 Feb 2008 13:59:09 -0600 (CST) Cc: hackers@freebsd.org, Brooks Davis Subject: Re: licensing question APSL 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, 14 Feb 2008 19:59:11 -0000 --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 14, 2008 at 08:47:02PM +0100, Volker wrote: > On 02/14/08 20:17, Brooks Davis wrote: > > APSL is not generally accepted in the base. It may be acceptable in > > certain circumstances, but strong technical justification is generally > > required for inclusion. >=20 > Brooks, >=20 > so better put that into the ports tree? It could go into ports without issue. If it's functionality people need in the base then perhaps a case could be made, but at a glance it doesn't look like these really qualify. -- Brooks --ew6BAiZeqk4r7MaW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFHtJ2NXY6L6fI4GtQRAoyKAKC9JfGaABQhVj7lq+fiHmrdMLFhlwCdH+m0 VVL9AxX3SeVvuoJlEsqBpNU= =rXX0 -----END PGP SIGNATURE----- --ew6BAiZeqk4r7MaW-- From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 14 20:31:23 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 D25D916A41B for ; Thu, 14 Feb 2008 20:31:23 +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 9442813C45E for ; Thu, 14 Feb 2008 20:31:23 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 29FA474400B for ; Thu, 14 Feb 2008 22:31:22 +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 10027) with ESMTP id LJjNEo7C7GLq for ; Thu, 14 Feb 2008 22:31:22 +0200 (EET) Received: from [10.74.70.239] (unknown [193.138.145.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 9C09974400A for ; Thu, 14 Feb 2008 22:31:21 +0200 (EET) Message-ID: <47B4A514.1020103@icyb.net.ua> Date: Thu, 14 Feb 2008 22:31:16 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: cpu stats and another interrupt question 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, 14 Feb 2008 20:31:23 -0000 Dear hackers, I'd like to check with you if my understanding of some code is correct. If we speak about a typical older i386 system, with UP and "AT" PIC, I think this is how the CPU utilization stats are collected. RTC is configured to generate interrupts (IRQ8) 128 times per second. Each time interrupt is generated RTC interrupt handler (I will use simple non technical terms) takes a peek at what was interrupted and depending on the properties of that thing (kernel thread) bills a tick to particular category. E.g. if it sees that the "idle" thread is interrupted then a tick is billed to "idle", if an interrupt thread is interrupted (software or hardware) then a tick is billed to interrupt, if a thread is running user-mode code then a tick is billed to "user" or "nice", otherwise it's "system". I understand that I oversimplify, but is the above correct in general ? Another, unrelated, question. Considering this snippet from sys/i386/isa/atpic.c, i8259_init(): #ifndef PC98 /* OCW2_L1 sets priority order to 3-7, 0-2 (com2 first). */ if (!slave) outb(pic->at_ioaddr, OCW2_R | OCW2_SL | OCW2_L1); #endif Do I understand correctly the code and the comment that here we use a feature of 8259 PIC that can be called "cyclic shift of interrupt priorities" ? So, we really have the following order of interrupts, from higher priority to lower: 3-7,0,1,8-15? Considering two chained 8259s, of course. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 14 22:20:53 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 4A8D916A418 for ; Thu, 14 Feb 2008 22:20:53 +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 3892E13C442 for ; Thu, 14 Feb 2008 22:20:52 +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 DE5E946C04; Thu, 14 Feb 2008 17:04:05 -0500 (EST) Date: Thu, 14 Feb 2008 22:04:05 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Volker In-Reply-To: <47B49023.20204@vwsoft.com> Message-ID: <20080214215628.P9304@fledge.watson.org> References: <47B3E21F.1010202@vwsoft.com> <20080214150200.GB18534@lor.one-eyed-alien.net> <47B49023.20204@vwsoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: hackers@freebsd.org, Brooks Davis Subject: Re: licensing question APSL 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, 14 Feb 2008 22:20:53 -0000 On Thu, 14 Feb 2008, Volker wrote: > On 02/14/08 16:02, Brooks Davis wrote: >> On Thu, Feb 14, 2008 at 07:39:27AM +0100, Volker wrote: >>> PRs in question: bin/67307 bin/67308 >> >> The quotes on the followup are essentially correct except that explicit >> approval is required by core to add new Non-BSD-Licensed code and that >> there would need to be a mechanism to not build them as part of buildworld >> to allow environments that do not want to deal with the APSL to avoid it >> similar to GPL or CDDL code. > > thank you for your opinion on that. The PR followup stating the APSL license > is ok, has been the statement of the original PR submitter, so I don't trust > that in the first place. That's why I was asking here for that license if > there's a common agreement. > > So I can assume the APSL license is (still) generally accepted for the BSDs? > > If nobody complains about the APSL, I'll ping core for a green flag. Two points here, although I think Brooks has already pretty much covered things from a FreeBSD perspective: (1) While there is GPL/LGPL (and now CDDL) code in the FreeBSD base, that's only where there's a particular compelling technical reason to do so: for example, we need a C compiler. However, there are on-going efforts to identify and replace non-BSD licensed code with BSD licensed code -- recently this has included libarchive/bsdtar and it's spin-offs, such as the BSD-licensed unzip code, as well as the growing bsdelf tool collection. (2) The other BSDs, as far as I'm aware, take similar or possibly more conservative views in this regard, with a strong preference for new components to be BSD-licensed and not fall under GPL (or other licenses). I think it's a significant testament to the quality of the Solaris parts we've been pulling in (ZFS, DTrace) that CDDL parts are now in the base tree. They are carefully marked and isolated to make it easy to build CDDL-free systems in the same way that you can build GPL-free systems. I would anticipate that if any APSL code did come into the base, we'd need similar isolation. To date we have had some luck in requesting Apple relicense APSL code to BSD though (and more recently Apache license) -- for example the Audit and OpenBSM code is Apple code now under a BSD license, which allows us to include it in the base and GENERIC kernel. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 14 19:31:04 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 4BB5316A41A for ; Thu, 14 Feb 2008 19:31:04 +0000 (UTC) (envelope-from wb@freebie.xs4all.nl) Received: from smtp-vbr5.xs4all.nl (smtp-vbr5.xs4all.nl [194.109.24.25]) by mx1.freebsd.org (Postfix) with ESMTP id E45C913C448 for ; Thu, 14 Feb 2008 19:31:03 +0000 (UTC) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [82.95.250.254]) by smtp-vbr5.xs4all.nl (8.13.8/8.13.8) with ESMTP id m1EJFClo026610; Thu, 14 Feb 2008 20:15:20 +0100 (CET) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.13.8/8.13.3) with ESMTP id m1EJFBxA025282; Thu, 14 Feb 2008 20:15:11 +0100 (CET) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.13.8/8.13.6/Submit) id m1EJFBBU025281; Thu, 14 Feb 2008 20:15:11 +0100 (CET) (envelope-from wb) Date: Thu, 14 Feb 2008 20:15:11 +0100 From: Wilko Bulte To: Volker Message-ID: <20080214191511.GA25260@freebie.xs4all.nl> References: <47B3E21F.1010202@vwsoft.com> <20080214150200.GB18534@lor.one-eyed-alien.net> <47B49023.20204@vwsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47B49023.20204@vwsoft.com> User-Agent: Mutt/1.5.11 X-Virus-Scanned: by XS4ALL Virus Scanner X-Mailman-Approved-At: Fri, 15 Feb 2008 02:52:58 +0000 Cc: hackers@freebsd.org, Brooks Davis Subject: Re: licensing question APSL 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, 14 Feb 2008 19:31:04 -0000 Quoting Volker, who wrote on Thu, Feb 14, 2008 at 08:01:55PM +0100 .. > On 02/14/08 16:02, Brooks Davis wrote: > > On Thu, Feb 14, 2008 at 07:39:27AM +0100, Volker wrote: > >> PRs in question: bin/67307 bin/67308 > > > > The quotes on the followup are essentially correct except that explicit > > approval is required by core to add new Non-BSD-Licensed code and > > that there would need to be a mechanism to not build them as part of > > buildworld to allow environments that do not want to deal with the APSL > > to avoid it similar to GPL or CDDL code. > > Brooks, > > thank you for your opinion on that. The PR followup stating the APSL > license is ok, has been the statement of the original PR submitter, so I > don't trust that in the first place. That's why I was asking here for > that license if there's a common agreement. > > So I can assume the APSL license is (still) generally accepted for the BSDs? Depends on what you call generally accepted. > If nobody complains about the APSL, I'll ping core for a green flag. > > Thanks > > Volker > _______________________________________________ > 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" --- end of quoted text --- -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 15 08:49:11 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 E421616A420; Fri, 15 Feb 2008 08:49:11 +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 8D94B13C46A; Fri, 15 Feb 2008 08:49:11 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 6B938208C; Fri, 15 Feb 2008 09:49:08 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.3/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 5CEEA2087; Fri, 15 Feb 2008 09:49:08 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 4B362844A1; Fri, 15 Feb 2008 09:49:08 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Brooks Davis References: <47B3E21F.1010202@vwsoft.com> <20080214150200.GB18534@lor.one-eyed-alien.net> <47B49023.20204@vwsoft.com> <20080214191737.GA20098@lor.one-eyed-alien.net> Date: Fri, 15 Feb 2008 09:49:08 +0100 In-Reply-To: <20080214191737.GA20098@lor.one-eyed-alien.net> (Brooks Davis's message of "Thu\, 14 Feb 2008 13\:17\:37 -0600") Message-ID: <86fxvu1u63.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Volker , hackers@freebsd.org Subject: Re: licensing question APSL 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, 15 Feb 2008 08:49:12 -0000 Brooks Davis writes: > APSL is not generally accepted in the base. It may be acceptable in > certain circumstances, but strong technical justification is generally > required for inclusion. Which brings us to my reaction to the PR, which is "why do we even need this?" Stick it in ports, please. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 15 08:53:52 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 A681516A41B; Fri, 15 Feb 2008 08:53:52 +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 4DAA513C442; Fri, 15 Feb 2008 08:53:52 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 3D41E2085; Fri, 15 Feb 2008 09:53:49 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.3/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 2A5C2207E; Fri, 15 Feb 2008 09:53:49 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 1D3C5844A1; Fri, 15 Feb 2008 09:53:49 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Robert Watson References: <47B3E21F.1010202@vwsoft.com> <20080214150200.GB18534@lor.one-eyed-alien.net> <47B49023.20204@vwsoft.com> <20080214215628.P9304@fledge.watson.org> Date: Fri, 15 Feb 2008 09:53:49 +0100 In-Reply-To: <20080214215628.P9304@fledge.watson.org> (Robert Watson's message of "Thu\, 14 Feb 2008 22\:04\:05 +0000 \(GMT\)") Message-ID: <86bq6i1tya.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Volker , hackers@freebsd.org, Brooks Davis Subject: Re: licensing question APSL 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, 15 Feb 2008 08:53:52 -0000 Robert Watson writes: > I think it's a significant testament to the quality of the Solaris > parts we've been pulling in (ZFS, DTrace) that CDDL parts are now in > the base tree. They are carefully marked and isolated to make it easy > to build CDDL-free systems in the same way that you can build GPL-free > systems. No you can't. I've tried, and it's not doable at present. There are non-GNU parts of the tree that depend on GNU parts of the tree which can't be replaced. There is a WITHOUT_GNU build option, but it has no effect. You can however build a non-GNU kernel. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 15 07:40: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 9B29616A418 for ; Fri, 15 Feb 2008 07:40:14 +0000 (UTC) (envelope-from st@anti-virus.by) Received: from tux.vba.com.by (vbaltd.vba.com.by [193.232.92.242]) by mx1.freebsd.org (Postfix) with ESMTP id F382113C442 for ; Fri, 15 Feb 2008 07:40:13 +0000 (UTC) (envelope-from st@anti-virus.by) Received: from st.vba.com.by (unknown [192.168.234.44]) by tux.vba.com.by (Postfix) with ESMTP id 85ABDC6423 for ; Fri, 15 Feb 2008 09:40:11 +0200 (EET) Date: Fri, 15 Feb 2008 09:40:09 +0200 From: Sergei Trofimovich To: freebsd-hackers@freebsd.org Message-ID: <20080215094009.07079ef0@st.vba.com.by> In-Reply-To: <49BA5EE4-D845-4F74-A61D-3CD2AAB41E53@0x58.com> References: <20080214174645.5bdb2879@st.vba.com.by> <49BA5EE4-D845-4F74-A61D-3CD2AAB41E53@0x58.com> Organization: VBA Ltd. X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.5; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 15 Feb 2008 12:12:35 +0000 Subject: Re: x86: sigaltstack problems 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, 15 Feb 2008 07:40:14 -0000 On Thu, 14 Feb 2008 11:40:21 -0700 Bert JW Regeer wrote: > On Feb 14, 2008, at 08:46 , Sergei Trofimovich wrote: > > > Attached file causes segfaults on freebsd 4,5,6 > > but keeps alive in linux. > > > > IANIAML, so please CC me explicitly. > > > > Thanks! > > You did not attach any files. > > Bert JW Regeer Sorry, something stripped it out. (copy of file is here - http://rafb.net/p/OYjAUQ55.html) The question is: Is it okay the program segfaults? I thought sigaltstack is the way not to mess our (possible invalid) stack. IANIAML, so please CC me explicitly. ////////////////////////////////////////////////////// //main.c: ////////////////////////////////////////////////////// #include #include #include #include #include #include #include volatile int alarmed = 0; void alarm_handler(int signo) { alarmed = 1; } #define EMIT_ASM_CALL(aflag) \ asm volatile( \ "nop \t\n" \ /* backup and mess esp */ \ "movl %%esp, %%ebp \t\n" \ "xorl %%eax, %%eax \t\n" \ "movl %%eax, %%esp \t\n" \ \ "while_not_alarmed: \t\n" \ "movl %0, %%eax \t\n" \ "test %%eax, %%eax \t\n" \ \ /* loop on volatile var */ \ "jz while_not_alarmed \t\n" \ \ /* restore esp */ \ "movl %%ebp, %%esp \t\n" \ "nop \t\n" \ : \ : "m"(aflag) \ : "%eax", "%ebp", "%esp","cc" /* we mess up EFLAGS */); int main () { /* alternate stack not to segfault on signal arrival */ stack_t ss; ss.ss_sp = malloc(SIGSTKSZ); if (ss.ss_sp == NULL) exit (1); ss.ss_size = SIGSTKSZ; ss.ss_flags = 0; if (sigaltstack(&ss, NULL) == -1) exit (2); struct sigaction sa; memset(&sa, 0, sizeof(sa)); sigfillset(&sa.sa_mask); sa.sa_handler = alarm_handler; // we DO alternate stack on signal arrival sa.sa_flags = SA_ONSTACK; sigaction(SIGALRM, &sa, NULL); alarm (1); // loop on volatile var EMIT_ASM_CALL(alarmed); printf ("caught alarm signal\n"); return 0; } From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 15 16:23: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 6D30316A417 for ; Fri, 15 Feb 2008 16:23:59 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id DF5CA13C468 for ; Fri, 15 Feb 2008 16:23:58 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JQ33J-000Ihm-Ke for freebsd-hackers@freebsd.org; Fri, 15 Feb 2008 18:04:44 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id m1FG4FKV081766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Feb 2008 18:04:15 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m1FG4auO065108; Fri, 15 Feb 2008 18:04:36 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m1FG4ZgO065107; Fri, 15 Feb 2008 18:04:35 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 15 Feb 2008 18:04:35 +0200 From: Kostik Belousov To: Sergei Trofimovich Message-ID: <20080215160435.GG57756@deviant.kiev.zoral.com.ua> References: <20080214174645.5bdb2879@st.vba.com.by> <49BA5EE4-D845-4F74-A61D-3CD2AAB41E53@0x58.com> <20080215094009.07079ef0@st.vba.com.by> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pccYjlC/mV5H7SoF" Content-Disposition: inline In-Reply-To: <20080215094009.07079ef0@st.vba.com.by> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on skuns.kiev.zoral.com.ua X-Scanner-Signature: cd91eefa7e6da97c48661c56a607d3ec X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 2245 [Feb 15 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release Cc: freebsd-hackers@freebsd.org Subject: Re: x86: sigaltstack problems 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, 15 Feb 2008 16:23:59 -0000 --pccYjlC/mV5H7SoF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 15, 2008 at 09:40:09AM +0200, Sergei Trofimovich wrote: > On Thu, 14 Feb 2008 11:40:21 -0700 > Bert JW Regeer wrote: >=20 > > On Feb 14, 2008, at 08:46 , Sergei Trofimovich wrote: > >=20 > > > Attached file causes segfaults on freebsd 4,5,6 > > > but keeps alive in linux. > > > > > > IANIAML, so please CC me explicitly. > > > > > > Thanks! > >=20 > > You did not attach any files. > >=20 > > Bert JW Regeer >=20 > Sorry, something stripped it out. >=20 > (copy of file is here - http://rafb.net/p/OYjAUQ55.html) >=20 > The question is: > Is it okay the program segfaults? >=20 > I thought sigaltstack is the way not to mess our (possible invalid) stack. > IANIAML, so please CC me explicitly. >=20 > ////////////////////////////////////////////////////// > //main.c: > ////////////////////////////////////////////////////// >=20 > #include > #include > #include > #include >=20 > #include > #include > #include >=20 > volatile int alarmed =3D 0; > void alarm_handler(int signo) > { > alarmed =3D 1; > } >=20 > #define EMIT_ASM_CALL(aflag) \ > asm volatile( \ > "nop \t\n" \ > /* backup and mess esp */ \ > "movl %%esp, %%ebp \t\n" \ > "xorl %%eax, %%eax \t\n" \ > "movl %%eax, %%esp \t\n" \ > \ > "while_not_alarmed: \t\n" \ > "movl %0, %%eax \t\n" \ > "test %%eax, %%eax \t\n" \ > \ > /* loop on volatile var */ \ > "jz while_not_alarmed \t\n" \ > \ > /* restore esp */ \ > "movl %%ebp, %%esp \t\n" \ > "nop \t\n" \ > : \ > : "m"(aflag) \ > : "%eax", "%ebp", "%esp","cc" /* we mess up EFLAGS */); >=20 > int main () > { > /* alternate stack not to segfault on signal arrival */ > stack_t ss; > ss.ss_sp =3D malloc(SIGSTKSZ); > if (ss.ss_sp =3D=3D NULL) exit (1); > ss.ss_size =3D SIGSTKSZ; > ss.ss_flags =3D 0; > if (sigaltstack(&ss, NULL) =3D=3D -1) exit (2); >=20 >=20 > struct sigaction sa; > memset(&sa, 0, sizeof(sa)); > sigfillset(&sa.sa_mask); > sa.sa_handler =3D alarm_handler; > // we DO alternate stack on signal arrival > sa.sa_flags =3D SA_ONSTACK; > sigaction(SIGALRM, &sa, NULL); >=20 > alarm (1); >=20 > // loop on volatile var > EMIT_ASM_CALL(alarmed); >=20 > printf ("caught alarm signal\n"); > return 0; > } I do not see a problem on RELENG_7. The tail of the truss output is below: sigaltstack(0xbfbfe638,0x0,0x1,0x0,0x0,0x1) =3D 0 (0x0) sigaction(SIGALRM,{ 0x8048550 SA_ONSTACK ss_t },0x0) =3D 0 (0x0) setitimer(0,{0.000000, 1.000000},{0.000000, 0.000000}) =3D 0 (0x0) SIGNAL 14 (SIGALRM) sigreturn(0x28209500,0xe,0x0,0x28209500,0x0,0x8048550) =3D 0 (0x0) fstat(1,{mode=3Dcrw------- ,inode=3D137,size=3D0,blksize=3D4096}) =3D 0 (0x= 0) ioctl(1,TIOCGETA,0xbfbfe4e8) =3D 0 (0x0) caught alarm signal write(1,"caught alarm signal\n",20) =3D 20 (0x14) process exit, rval =3D 0 --pccYjlC/mV5H7SoF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEARECAAYFAke1uBIACgkQC3+MBN1Mb4g2eACfaeeOta1MaRAEdYatsuNs1uPD ko8AoMrzhjCvF5H/teVVC5g9LjGiRzD/ =TCv9 -----END PGP SIGNATURE----- --pccYjlC/mV5H7SoF-- From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 15 21:06: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 571D516A41A for ; Fri, 15 Feb 2008 21:06:54 +0000 (UTC) (envelope-from freebsd.dev@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by mx1.freebsd.org (Postfix) with ESMTP id 22B7513C447 for ; Fri, 15 Feb 2008 21:06:53 +0000 (UTC) (envelope-from freebsd.dev@gmail.com) Received: by py-out-1112.google.com with SMTP id u52so1021689pyb.10 for ; Fri, 15 Feb 2008 13:06:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=+sen+768uyIvYPnrs3M2vFyk5MCHU13PQDP3hB6+Dt0=; b=V+wQvCsADkI6YMFKnxmBOf/WR/IFi9/9NyOupqR33roskYaWZh4ZxGHq60urTV8o9ibVwfPiZu6/FJwZH/7Rp2EYGRR2EX5y1O+g0M448nK5nqlzufS0NksgzscX/YvSnvaYhF7HhEoty1ayn2erRJGYKRfa7J+ESy7lYXZT3cU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JCPIezQ4gtHT7A2bMJPFjJ3UTCpOZGP+ET3tkKSGxAvflIq1uGEyu2xg/ZIFD9Dxx3LMnBQmqDkIadr2iAisi9Z++FhxsCNjSV1alCG5ZKLOaUuextQAy26y5xpfDGcdZ2UmTUDHL4Cpf3EHvGjh+gq3SQoe0XzqGXUe45Aw1Cg= Received: by 10.140.208.14 with SMTP id f14mr2210636rvg.283.1203109612778; Fri, 15 Feb 2008 13:06:52 -0800 (PST) Received: by 10.141.20.13 with HTTP; Fri, 15 Feb 2008 13:06:52 -0800 (PST) Message-ID: <50cd4e5f0802151306j72e61780m594cf3fd8b5ea7f9@mail.gmail.com> Date: Fri, 15 Feb 2008 15:06:52 -0600 From: "Biks N" To: freebsd-hackers@freebsd.org In-Reply-To: <50cd4e5f0802121005s191a7875s98ffe2ca512389bc@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <50cd4e5f0802071222w1222d901o3ce8770b5f5725b4@mail.gmail.com> <47AB7775.2040000@errno.com> <50cd4e5f0802121005s191a7875s98ffe2ca512389bc@mail.gmail.com> Subject: Re: retrive data from mbuf chain 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, 15 Feb 2008 21:06:54 -0000 Please ignore my previous post. I was having problem because I didn't allocate memory to my_data_copy. Also, the correct usage is: m_copydata( m, 0, m->m_pkthdr.len , (caddr_t) my_data_copy); thanks On Tue, Feb 12, 2008 at 12:05 PM, Biks N wrote: > Hi, thanks to everyone for providing me with different ideas. > > First I am trying to use m_copydata() method because I think it will > be easy for me to copy data back and forth (using m_copydataback() ). > > But right now I am having problem using m_copydata() function. > > I want to copy data in all mbufs (only payload but no tcp/ip header) > except the first Mbuf in chain. > If payload is small enough to fit within 1st mbuf then I don't need that either. > > I am getting kernel panic ( please see below). > I can see custom message "Starting m_copydata()" in log file. > So I assume the problem is due to incorrect parameter in m_copydata(). > > > here is the sample of code I am trying to use: > > /********************************/ > caddr_t my_data_copy = NULL; > > > /* check if m_len < m_pkthdr.len */ > > if ( m->m_len < m->m_pkthdr.len ) { > > /* copy data if there are more than 1 Mbufs in Chain */ > log (LOG_DEBUG,"Starting m_copydata() \n"); > > m_copydata( m, m->m_len , m->m_pkthdr.len - m->m_len , my_data_copy); > > log (LOG_DEBUG,"%d Byte of Data copied\n", m->m_pkthdr.len - > m->m_len); > > } > else { > /* skip if there is only 1 MBUF */ > //log (LOG_DEBUG,"There must Only 1 MBUF in chain\n"); > } > /********************************/ > > > Kernel Panic: > > Feb 12 11:36:09 bsd1 /kernel: Fatal trap 12: page fault while in kernel mode > Feb 12 11:36:09 bsd1 /kernel: fault virtual address = 0x0 > Feb 12 11:36:09 bsd1 /kernel: fault code = supervisor > write, page not present > Feb 12 11:36:09 bsd1 /kernel: instruction pointer = 0x8:0xc024efc2 > Feb 12 11:36:09 bsd1 /kernel: stack pointer = 0x10:0xd15e8d08 > Feb 12 11:36:09 bsd1 /kernel: frame pointer = 0x10:0xd15e8d2c > Feb 12 11:36:09 bsd1 /kernel: code segment = base 0x0, > limit 0xfffff, type 0x1b > Feb 12 11:36:09 bsd1 /kernel: = DPL 0, pres 1, def32 1, gran 1 > Feb 12 11:36:09 bsd1 /kernel: processor eflags = interrupt enabled, > resume, IOPL = 0 > Feb 12 11:36:09 bsd1 /kernel: current process = 154 (ping) > Feb 12 11:36:09 bsd1 /kernel: interrupt mask = > Feb 12 11:36:09 bsd1 /kernel: > > > I am using "ping -s 1200 host" to send larger packets so that system > creates at least 2 mbufs. > > ------------ > > On Feb 7, 2008 3:26 PM, Sam Leffler wrote: > > > > > Biks N wrote: > > > Hi, > > > > > > I am new to FreeBSD kernel programming. > > > > > > Currently I am trying to work on mbuf data manupulation. > > > > > > >From my understanding: data (payload) is stored into one or more mufs > > > which are chained together through m_next pointer. > > > > > > Now, I need to retrive all data in mbuf chain ( mbufs linked by > > > m_next). I am working ip_output() in netinet/ip_output.c > > > > > > Does there exist inbuilt function/macro to retrive all the data in mbuf chain? > > > > > > > man 9 mbuf; look for m_copydata. > > > > Sam > > > > > From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 16 08:40:10 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 147B416A41A for ; Sat, 16 Feb 2008 08:40:10 +0000 (UTC) (envelope-from tofig@freebsd.az) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.187]) by mx1.freebsd.org (Postfix) with ESMTP id 0B53113C44B for ; Sat, 16 Feb 2008 08:40:09 +0000 (UTC) (envelope-from tofig@freebsd.az) Received: by rv-out-0910.google.com with SMTP id g13so776859rvb.43 for ; Sat, 16 Feb 2008 00:40:09 -0800 (PST) Received: by 10.141.79.12 with SMTP id g12mr2482765rvl.182.1203149506725; Sat, 16 Feb 2008 00:11:46 -0800 (PST) Received: by 10.140.194.14 with HTTP; Sat, 16 Feb 2008 00:11:46 -0800 (PST) Message-ID: <342414370802160011s7fc3edc2w5feb45ce788930c5@mail.gmail.com> Date: Sat, 16 Feb 2008 12:11:46 +0400 From: "Tofig Suleymanov" To: hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mailman-Approved-At: Sat, 16 Feb 2008 12:40:32 +0000 Cc: Subject: if_start() and sending packets problem 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, 16 Feb 2008 08:40:10 -0000 Hello hackers, I will be grateful if someone could point me to the right direction regarding the question below. My device driver is getting incoming packets fine, but for some reason I am not able to send a single packet. Here is the source code: http://www.freebsd.az/if_ib.c I've added several debug messages to the source and here is the output: (bringing interface up and assigning the ip/netmask combination) ifconfig ib0 192.168.0.6 netmask 255.255.255.0 up (At this moment I get this in my /var/log/messages. It seems to be a gratuitous arp who-has packet ) Feb 7 19:14:32 schizo kernel: ib_init entered Feb 7 19:14:32 schizo kernel: ib_start entered Feb 7 19:14:32 schizo kernel: ib_encap entered Feb 7 19:14:32 schizo kernel: DHOST ff ff ff ff ff ff Feb 7 19:14:32 schizo kernel: SHOST 0 c0 ee 22 3 14 Feb 7 19:14:32 schizo kernel: txeof entered Feb 7 19:14:32 schizo kernel: txeof exiting (now I try pinging, but no joy . I've added extra debug messages inside ping.c) schizo# ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1): 56 data bytes packets sent: -1 ping: sendto: Invalid argument packets sent: -1 ping: sendto: Invalid argument packets sent: -1 ping: sendto: Invalid argument ^C --- 192.168.0.1 ping statistics --- 3 packets transmitted, 0 packets received, 100% packet loss I have also tried to add debug messages to sys/net/if.c and sys/net/netisr.c and it seems that the kernel doesn't even try to run my ib_start() function. Doing tcpdump on the interface and pinging does not show any packets flowing. Please note that tcpdump shows the arp who-has request right after I assign the ip address. ifconfig ib0 gives the following: ib0: flags=1008c3 mtu 1500 inet 192.168.0.5 netmask 0xffffff00 broadcast 192.168.0.255 ether 00:c0:ee:22:03:14 media: Ethernet 10baseT/UTP status: active netstat -in gives the following output: Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll bge0* 1500 00:16:41:52:fb:1e 0 0 0 0 0 iwi0 1500 00:13:ce:cc:b8:10 3065 0 2856 0 0 iwi0 1500 192.168.1 192.168.1.5 3034 - 2825 - - lo0 16384 8 0 8 0 0 lo0 16384 127 127.0.0.1 8 - 8 - - ib0 1500 00:c0:ee:22:03:14 4 0 2 0 0 ib0 1500 192.168.0 192.168.0.5 0 - 3 - - Any ideas are highly appreciated. From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 16 14:00:29 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 40D3B16A417 for ; Sat, 16 Feb 2008 14:00:29 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.179]) by mx1.freebsd.org (Postfix) with ESMTP id D5B1F13C459 for ; Sat, 16 Feb 2008 14:00:28 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-038-022.pools.arcor-ip.net [88.66.38.22]) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis) id 0ML25U-1JQNOT0F9u-0006df; Sat, 16 Feb 2008 14:47:53 +0100 Received: (qmail 82134 invoked by uid 80); 16 Feb 2008 13:47:37 -0000 Received: from 192.168.4.151 (SquirrelMail authenticated user mlaier) by router.laiers.local with HTTP; Sat, 16 Feb 2008 14:47:37 +0100 (CET) Message-ID: <35810.192.168.4.151.1203169657.squirrel@router.laiers.local> In-Reply-To: <342414370802160011s7fc3edc2w5feb45ce788930c5@mail.gmail.com> References: <342414370802160011s7fc3edc2w5feb45ce788930c5@mail.gmail.com> Date: Sat, 16 Feb 2008 14:47:37 +0100 (CET) From: "Max Laier" To: "Tofig Suleymanov" User-Agent: SquirrelMail/1.4.13 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Provags-ID: V01U2FsdGVkX19402r/inK8UBDdVcC4ENlk4xIcpgi6bP1lUnG E0A3mKqJT+0xxuqGHkouzsv/1hmweimTP8ImcsSlqPc7pqL+pN 963z7ph4aBF19/FqVUgnA== Cc: hackers@freebsd.org Subject: Re: if_start() and sending packets problem 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, 16 Feb 2008 14:00:29 -0000 Am Sa, 16.02.2008, 09:11, schrieb Tofig Suleymanov: > Hello hackers, > > I will be grateful if someone could point me to the right direction > regarding the question below. > > My device driver is getting incoming packets fine, but for some reason I > am not able to send a single packet. Here is the source code: > > http://www.freebsd.az/if_ib.c > > I've added several debug messages to the source and here is the output: > > (bringing interface up and assigning the ip/netmask combination) > > ifconfig ib0 192.168.0.6 netmask 255.255.255.0 up > > (At this moment I get this in my /var/log/messages. It seems to be a > gratuitous arp who-has packet ) > > Feb 7 19:14:32 schizo kernel: ib_init entered > Feb 7 19:14:32 schizo kernel: ib_start entered > Feb 7 19:14:32 schizo kernel: ib_encap entered > Feb 7 19:14:32 schizo kernel: DHOST ff ff ff ff ff ff > Feb 7 19:14:32 schizo kernel: SHOST 0 c0 ee 22 3 14 > Feb 7 19:14:32 schizo kernel: txeof entered > Feb 7 19:14:32 schizo kernel: txeof exiting > > (now I try pinging, but no joy . I've added extra debug messages inside > ping.c) > > schizo# ping 192.168.0.1 > PING 192.168.0.1 (192.168.0.1): 56 data bytes > packets sent: -1 > ping: sendto: Invalid argument > packets sent: -1 > ping: sendto: Invalid argument > packets sent: -1 > ping: sendto: Invalid argument > ^C > --- 192.168.0.1 ping statistics --- > 3 packets transmitted, 0 packets received, 100% packet loss > > > I have also tried to add debug messages to sys/net/if.c and > sys/net/netisr.c and it seems that the kernel doesn't even try to run my > ib_start() function. > > Doing tcpdump on the interface and pinging does not show any packets > flowing. Please note that tcpdump shows the arp who-has request right > after I assign the ip address. > > ifconfig ib0 gives the following: > ib0: flags=1008c3 mtu 1500 Why do you set NOARP? It seems that your ping can't figure out the ARP address of 192.168.0.1 and hence returns early. Either install a static arp entry for 192.168.0.1 or lose the NOARP. > inet 192.168.0.5 netmask 0xffffff00 broadcast 192.168.0.255 > ether 00:c0:ee:22:03:14 > media: Ethernet 10baseT/UTP > status: active > > netstat -in gives the following output: > Name Mtu Network Address Ipkts Ierrs Opkts Oerrs > Coll > bge0* 1500 00:16:41:52:fb:1e 0 0 0 0 > 0 > iwi0 1500 00:13:ce:cc:b8:10 3065 0 2856 0 > 0 > iwi0 1500 192.168.1 192.168.1.5 3034 - 2825 - > - > lo0 16384 8 0 8 0 > 0 > lo0 16384 127 127.0.0.1 8 - 8 - > - > ib0 1500 00:c0:ee:22:03:14 4 0 2 0 > 0 > ib0 1500 192.168.0 192.168.0.5 0 - 3 - > - > > Any ideas are highly appreciated. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 16 17:29:55 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 0EE1A16A41A for ; Sat, 16 Feb 2008 17:29:55 +0000 (UTC) (envelope-from tofig@freebsd.az) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.freebsd.org (Postfix) with ESMTP id 977C513C4DB for ; Sat, 16 Feb 2008 17:29:54 +0000 (UTC) (envelope-from tofig@freebsd.az) Received: by ug-out-1314.google.com with SMTP id y2so117590uge.37 for ; Sat, 16 Feb 2008 09:29:53 -0800 (PST) Received: by 10.67.116.6 with SMTP id t6mr871558ugm.76.1203182992503; Sat, 16 Feb 2008 09:29:52 -0800 (PST) Received: from ?192.168.1.5? ( [81.21.81.41]) by mx.google.com with ESMTPS id b35sm1444566ugd.33.2008.02.16.09.29.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 16 Feb 2008 09:29:51 -0800 (PST) Message-ID: <47B71D7F.9070804@freebsd.az> Date: Sat, 16 Feb 2008 21:29:35 +0400 From: Tofig Suleymanov User-Agent: Thunderbird 1.5.0.8 (X11/20061113) MIME-Version: 1.0 To: Max Laier References: <342414370802160011s7fc3edc2w5feb45ce788930c5@mail.gmail.com> <35810.192.168.4.151.1203169657.squirrel@router.laiers.local> In-Reply-To: <35810.192.168.4.151.1203169657.squirrel@router.laiers.local> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 16 Feb 2008 18:04:21 +0000 Cc: hackers@freebsd.org Subject: Re: if_start() and sending packets problem 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, 16 Feb 2008 17:29:55 -0000 Max Laier wrote: > Am Sa, 16.02.2008, 09:11, schrieb Tofig Suleymanov: > >> Hello hackers, >> >> I will be grateful if someone could point me to the right direction >> regarding the question below. >> >> My device driver is getting incoming packets fine, but for some reason I >> am not able to send a single packet. Here is the source code: >> >> http://www.freebsd.az/if_ib.c >> >> I've added several debug messages to the source and here is the output: >> >> (bringing interface up and assigning the ip/netmask combination) >> >> ifconfig ib0 192.168.0.6 netmask 255.255.255.0 up >> >> (At this moment I get this in my /var/log/messages. It seems to be a >> gratuitous arp who-has packet ) >> >> Feb 7 19:14:32 schizo kernel: ib_init entered >> Feb 7 19:14:32 schizo kernel: ib_start entered >> Feb 7 19:14:32 schizo kernel: ib_encap entered >> Feb 7 19:14:32 schizo kernel: DHOST ff ff ff ff ff ff >> Feb 7 19:14:32 schizo kernel: SHOST 0 c0 ee 22 3 14 >> Feb 7 19:14:32 schizo kernel: txeof entered >> Feb 7 19:14:32 schizo kernel: txeof exiting >> >> (now I try pinging, but no joy . I've added extra debug messages inside >> ping.c) >> >> schizo# ping 192.168.0.1 >> PING 192.168.0.1 (192.168.0.1): 56 data bytes >> packets sent: -1 >> ping: sendto: Invalid argument >> packets sent: -1 >> ping: sendto: Invalid argument >> packets sent: -1 >> ping: sendto: Invalid argument >> ^C >> --- 192.168.0.1 ping statistics --- >> 3 packets transmitted, 0 packets received, 100% packet loss >> >> >> I have also tried to add debug messages to sys/net/if.c and >> sys/net/netisr.c and it seems that the kernel doesn't even try to run my >> ib_start() function. >> >> Doing tcpdump on the interface and pinging does not show any packets >> flowing. Please note that tcpdump shows the arp who-has request right >> after I assign the ip address. >> >> ifconfig ib0 gives the following: >> ib0: flags=1008c3 mtu 1500 >> > > Why do you set NOARP? It seems that your ping can't figure out the ARP > address of 192.168.0.1 and hence returns early. Either install a static > arp entry for 192.168.0.1 or lose the NOARP. > Good catch ! I've added a static arp entry as advised and now I am getting into ib_start() and ib_encap() successfully ! Kind regards, Tofig.