From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 12 03:36:22 2005 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E981716A41C; Sun, 12 Jun 2005 03:36:22 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id A5A8C43D49; Sun, 12 Jun 2005 03:36:22 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.3/8.13.3) with ESMTP id j5C3aLTm070569; Sat, 11 Jun 2005 20:36:21 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j5C3aGpd070568; Sat, 11 Jun 2005 20:36:16 -0700 (PDT) (envelope-from obrien) Date: Sat, 11 Jun 2005 20:36:16 -0700 From: "David O'Brien" To: Slawa Olhovchenkov Message-ID: <20050612033616.GE67746@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Slawa Olhovchenkov , Scott Long , hackers@freebsd.org, 'FreeBSD Current' References: <42A11C92.5050505@samsco.org> <20050605200233.GA38531@zxy.spb.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050605200233.GA38531@zxy.spb.ru> X-Operating-System: FreeBSD 6.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.9i Cc: Scott Long , hackers@freebsd.org, 'FreeBSD Current' Subject: Re: HEADS UP! 6.0 Schedule, 6.0-CURRENT Snapshot X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2005 03:36:23 -0000 On Mon, Jun 06, 2005 at 12:02:33AM +0400, Slawa Olhovchenkov wrote: > On Fri, Jun 03, 2005 at 09:14:26PM -0600, Scott Long wrote: > > > All, > > > > The long anticipated and much feared 6.0 code freeze is about to begin! > > I'll cut to the chase: > > > > June 10 - Feature freeze + code slush > > ^^^^^^^ > > > > July 10 - RELENG_6 branch > > August 1 - RELENG_6_0 branch > > August 15 - 6.0-RELEASE > > Nice time for compat5x? Yes, it will be there. -- -- David (obrien@FreeBSD.org) From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 12 15:34:15 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 50BCD16A41C; Sun, 12 Jun 2005 15:34:15 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id D02A743D48; Sun, 12 Jun 2005 15:34:14 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from beastie.frontfree.net (unknown [219.239.99.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 1A123EB0B84; Sun, 12 Jun 2005 23:34:13 +0800 (CST) Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id 4E82E135186; Sun, 12 Jun 2005 23:34:11 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23102-19; Sun, 12 Jun 2005 23:34:05 +0800 (CST) Received: by beastie.frontfree.net (Postfix, from userid 1001) id D8588135169; Sun, 12 Jun 2005 23:34:04 +0800 (CST) Date: Sun, 12 Jun 2005 23:34:04 +0800 From: Xin LI To: ru@FreeBSD.org, freebsd-hackers@FreeBSD.org Message-ID: <20050612153404.GA30999@frontfree.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-GPG-key-ID/Fingerprint: 0xCAEEB8C0 / 43B8 B703 B8DD 0231 B333 DC28 39FB 93A0 CAEE B8C0 X-GPG-Public-Key: http://www.delphij.net/delphij.asc X-Operating-System: FreeBSD beastie.frontfree.net 5.4-RELEASE-p1 FreeBSD 5.4-RELEASE-p1 #1: Fri May 27 00:47:15 CST 2005 delphij@beastie.frontfree.net:/usr/obj/usr/src/sys/BEASTIE i386 X-URL: http://www.delphij.net X-By: delphij@beastie.frontfree.net X-Location: Beijing, China X-Virus-Scanned: amavisd-new at frontfree.net Cc: Subject: How to make use of the current source tree's include file? 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, 12 Jun 2005 15:34:15 -0000 --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, Ruslan, I am recently working on a patchset that would provide mini-crashdump which needs to include a newly added include file into /sys/sys/ from the kgdb(1) source code. I have used the following line to make this possible, in the latter's Makefile: CFLAGS+=3D -I${.CURDIR}/../../../../sys/ However I'm under the impression that there is some better ways to archive this, will you please give me some hints? Thanks in advance! Cheers, --=20 Xin LI http://www.delphij.net/ See complete headers for GPG key and other information. --2oS5YaxWCcQjTEyO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCrFXs/cVsHxFZiIoRAiCwAJ94uTQQQeCfXOeK4tLwW3s7p4t1gwCdG3tI rxDmiOU6Zit5FtF0pQACrcc= =tXxK -----END PGP SIGNATURE----- --2oS5YaxWCcQjTEyO-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 12 19:31:19 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DC7416A41C for ; Sun, 12 Jun 2005 19:31:19 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DC8B43D53 for ; Sun, 12 Jun 2005 19:31:17 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j5CJVCnQ053780; Sun, 12 Jun 2005 22:31:12 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 28446-11; Sun, 12 Jun 2005 22:31:12 +0300 (EEST) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j5CJVBY9053777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Jun 2005 22:31:12 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.3/8.13.3) id j5CJVfoH004619; Sun, 12 Jun 2005 22:31:41 +0300 (EEST) (envelope-from ru) Date: Sun, 12 Jun 2005 22:31:35 +0300 From: Ruslan Ermilov To: Xin LI Message-ID: <20050612193135.GA94541@ip.net.ua> References: <20050612153404.GA30999@frontfree.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9jxsPFA5p3P2qPhR" Content-Disposition: inline In-Reply-To: <20050612153404.GA30999@frontfree.net> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua Cc: freebsd-hackers@freebsd.org Subject: Re: How to make use of the current source tree's include file? 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, 12 Jun 2005 19:31:19 -0000 --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Xin, On Sun, Jun 12, 2005 at 11:34:04PM +0800, Xin LI wrote: > I am recently working on a patchset that would provide mini-crashdump > which needs to include a newly added include file into /sys/sys/ from > the kgdb(1) source code. I have used the following line to make this > possible, in the latter's Makefile: >=20 > CFLAGS+=3D -I${.CURDIR}/../../../../sys/ >=20 > However I'm under the impression that there is some better ways to > archive this, will you please give me some hints? >=20 This line would be redundant when you "make buildworld" -- in this case, the fresh headers are used. But if you are looking for a way to compile a program with a new (previously non-existent) header, the above makes sense. Alternatively, you can "make .. DEBUG_FLAGS=3D-I${.CURDIR}/.../sys" without modifying the makefile. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --9jxsPFA5p3P2qPhR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCrI2XqRfpzJluFF4RAtRlAKCT5jJ7ZmLALz9Gv8kZn9Z1rwMLxgCfeIZ3 7EJtdOPP2jww8nCORrZN+80= =mHGq -----END PGP SIGNATURE----- --9jxsPFA5p3P2qPhR-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 06:47:57 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3153916A41C for ; Mon, 13 Jun 2005 06:47:57 +0000 (GMT) (envelope-from NKoch@demig.de) Received: from server.absolute-media.de (server.absolute-media.de [213.239.231.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2A3143D1F for ; Mon, 13 Jun 2005 06:47:56 +0000 (GMT) (envelope-from NKoch@demig.de) Received: from localhost (unknown [127.0.0.1]) by server.absolute-media.de (Postfix) with ESMTP id 4810580558; Mon, 13 Jun 2005 08:47:54 +0200 (CEST) Received: from server.absolute-media.de ([127.0.0.1]) by localhost (server [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14957-05; Mon, 13 Jun 2005 08:47:49 +0200 (CEST) Received: from firewall.demig (p50839F04.dip0.t-ipconnect.de [80.131.159.4]) by server.absolute-media.de (Postfix) with ESMTP id 8513B7EA7F; Mon, 13 Jun 2005 08:47:49 +0200 (CEST) Received: from ws-ew-3 (ws-ew-3.w2kdemig [192.168.1.72]) by firewall.demig (8.13.4/8.13.1) with SMTP id j5D6jN97028372; Mon, 13 Jun 2005 08:45:23 +0200 (CEST) (envelope-from NKoch@demig.de) From: "Norbert Koch" To: , "Neo-Vortex" , "Mike Hunter" Date: Mon, 13 Jun 2005 08:45:25 +0200 Message-ID: <001001c56fe3$7a725620$4801a8c0@ws-ew-3.W2KDEMIG> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <20050611062448.57145.qmail@web52708.mail.yahoo.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at absolute-media.de Cc: freebsd-hackers@freebsd.org Subject: RE: Slowing down an old program to run on a fast CPU? 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, 13 Jun 2005 06:47:57 -0000 > > You could try installing vmware and running however > > many copies of windows > > it takes to make the game playable... (i would say > > some other form of > > *BSD, but it probobly wouldn't hog as much cpu :P) > > > > ~NVX Or try qemu. I yesterday booted & installed NetBSD in a qemu box running under FreeBSD5.4 ;-) Try to run it with/without 'kldload kqemu'. From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 08:32:57 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C26416A41C for ; Mon, 13 Jun 2005 08:32:57 +0000 (GMT) (envelope-from NKoch@demig.de) Received: from server.absolute-media.de (server.absolute-media.de [213.239.231.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7615943D4C for ; Mon, 13 Jun 2005 08:32:56 +0000 (GMT) (envelope-from NKoch@demig.de) Received: from localhost (unknown [127.0.0.1]) by server.absolute-media.de (Postfix) with ESMTP id 7A5B97EDE6 for ; Mon, 13 Jun 2005 10:32:54 +0200 (CEST) Received: from server.absolute-media.de ([127.0.0.1]) by localhost (server [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21405-05 for ; Mon, 13 Jun 2005 10:32:49 +0200 (CEST) Received: from firewall.demig (p50839F04.dip0.t-ipconnect.de [80.131.159.4]) by server.absolute-media.de (Postfix) with ESMTP id 180C481154 for ; Mon, 13 Jun 2005 10:32:49 +0200 (CEST) Received: from ws-ew-3 (ws-ew-3.w2kdemig [192.168.1.72]) by firewall.demig (8.13.4/8.13.1) with SMTP id j5D8WDjn030805 for ; Mon, 13 Jun 2005 10:32:13 +0200 (CEST) (envelope-from NKoch@demig.de) From: "Norbert Koch" To: Date: Mon, 13 Jun 2005 10:32:12 +0200 Message-ID: <000001c56ff2$65b5a8e0$4801a8c0@ws-ew-3.W2KDEMIG> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_01C57003.293E78E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <001701c56d83$aada3e20$4801a8c0@ws-ew-3.W2KDEMIG> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at absolute-media.de Subject: RE: usbd.conf: detach ukbd 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, 13 Jun 2005 08:32:57 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C57003.293E78E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > > Else if devd is not available on 4.11 you will have to change > > some code and > > compile a new kernel, from what I can see. > > > > To the file /sys/dev/usb/ukbd.c add this: > > > > static void > > usbd_add_device_detach_event(device_t self) > > { > > struct usb_event ue; > > > > bzero(&ue, sizeof(ue)); > > > > strlcpy(ue.u.ue_device.udi_devnames[0], > > device_get_nameunit(self), USB_MAX_DEVNAMELEN) ; > > > > usb_add_event(USB_EVENT_DEVICE_DETACH, &ue); > > return; > > } > > > > ukbd_detach() > > { > > ... > > usbd_add_device_detach_event(self); > > return (0); > > } > > > > This will make the suggestion from Maksim work. Ok, that seems to work with a minor change [no strlcpy] and two additional patches in usb.h & usb.c. Usbd gets a detach event "ukbd0" and another event from its fallthrough device. Thank you once again. If someone is interested in the patch files against 4.11 see the attachment. Norbert ------=_NextPart_000_0001_01C57003.293E78E0 Content-Type: application/octet-stream; name="ukbd.c.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ukbd.c.patch" LS0tIC91c3IvbG9jYWwvamFpbC91c3Ivc3JjL3N5cy9kZXYvdXNiL3VrYmQuYwlNb24gTWFyICAx IDIxOjU2OjAyIDIwMDQKKysrIHVrYmQuYwlGcmkgSnVuIDEwIDE0OjM0OjA1IDIwMDUKQEAgLTE5 NSw2ICsxOTUsMjIgQEAKIAlVU0JfQVRUQUNIX1NVQ0NFU1NfUkVUVVJOOwogfQogCisKK3N0YXRp YyB2b2lkCit1c2JkX2FkZF9kZXZpY2VfZGV0YWNoX2V2ZW50KGRldmljZV90IHNlbGYpCit7Cisg ICAgICAgIHN0cnVjdCB1c2JfZXZlbnQgdWU7CisKKyAgICAgICAgYnplcm8oJnVlLCBzaXplb2Yo dWUpKTsKKworICAgICAgICBzdHJuY3B5KHVlLnUudWVfZGV2aWNlLnVkaV9kZXZuYW1lc1swXSwK KyAgICAgICAgICAgICAgICBkZXZpY2VfZ2V0X25hbWV1bml0KHNlbGYpLCBVU0JfTUFYX0RFVk5B TUVMRU4pOworICAgICAgICB1ZS51LnVlX2RldmljZS51ZGlfZGV2bmFtZXNbMF1bVVNCX01BWF9E RVZOQU1FTEVOIC0gMV0gPSAnXDAnOworCisgICAgICAgIHVzYl9hZGRfZXZlbnQoVVNCX0VWRU5U X0RFVklDRV9ERVRBQ0gsICZ1ZSk7Cit9CisKKwogaW50CiB1a2JkX2RldGFjaChkZXZpY2VfdCBz ZWxmKQogewpAQCAtMjE5LDYgKzIzNSw4IEBACiAJCXJldHVybiBlcnJvcjsKIAogCURQUklOVEYo KCIlczogZGlzY29ubmVjdGVkXG4iLCBVU0JERVZOQU1FKHNlbGYpKSk7CisgICAgICAgIAorICAg ICAgICB1c2JkX2FkZF9kZXZpY2VfZGV0YWNoX2V2ZW50KHNlbGYpOwogCiAJcmV0dXJuICgwKTsK IH0K ------=_NextPart_000_0001_01C57003.293E78E0 Content-Type: application/octet-stream; name="usb.c.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="usb.c.patch" LS0tIC91c3IvbG9jYWwvamFpbC91c3Ivc3JjL3N5cy9kZXYvdXNiL3VzYi5jCU1vbiBNYXkgMTYg MTE6Mzk6MjUgMjAwNQorKysgdXNiLmMJRnJpIEp1biAxMCAxNDo1MzoyMSAyMDA1CkBAIC0xOTMs OCArMTkzLDYgQEAKIFN0YXRpYyBzdHJ1Y3Qgc2VsaW5mbyB1c2Jfc2VsZXZlbnQ7CiBTdGF0aWMg c3RydWN0IHByb2MgKnVzYl9hc3luY19wcm9jOyAgLyogcHJvY2VzcyB0aGF0IHdhbnRzIFVTQiBT SUdJTyAqLwogU3RhdGljIGludCB1c2JfZGV2X29wZW4gPSAwOwotU3RhdGljIHZvaWQgdXNiX2Fk ZF9ldmVudChpbnQsIHN0cnVjdCB1c2JfZXZlbnQgKik7Ci0KIFN0YXRpYyBpbnQgdXNiX2dldF9u ZXh0X2V2ZW50KHN0cnVjdCB1c2JfZXZlbnQgKik7CiAKIFN0YXRpYyBjb25zdCBjaGFyICp1c2Jy ZXZfc3RyW10gPSBVU0JSRVZfU1RSOwo= ------=_NextPart_000_0001_01C57003.293E78E0 Content-Type: application/octet-stream; name="usb.h.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="usb.h.patch" LS0tIC91c3IvbG9jYWwvamFpbC91c3Ivc3JjL3N5cy9kZXYvdXNiL3VzYi5oCU1vbiBNYXIgIDEg MDE6MDc6MjIgMjAwNAorKysgdXNiLmgJRnJpIEp1biAxMCAxNDo1NDo0MSAyMDA1CkBAIC02NTUs NiArNjU1LDEwIEBACiAJfSB1OwogfTsKIAorI2lmIGRlZmluZWQoX0tFUk5FTCkKK3ZvaWQgdXNi X2FkZF9ldmVudChpbnQsIHN0cnVjdCB1c2JfZXZlbnQgKik7CisjZW5kaWYgLyogX0tFUk5FTCAq LworCiAvKiBVU0IgY29udHJvbGxlciAqLwogI2RlZmluZSBVU0JfUkVRVUVTVAkJX0lPV1IoJ1Un LCAxLCBzdHJ1Y3QgdXNiX2N0bF9yZXF1ZXN0KQogI2RlZmluZSBVU0JfU0VUREVCVUcJCV9JT1cg KCdVJywgMiwgaW50KQo= ------=_NextPart_000_0001_01C57003.293E78E0-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 09:14:05 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 70B2316A41C for ; Mon, 13 Jun 2005 09:14:05 +0000 (GMT) (envelope-from ray@redshift.com) Received: from outgoing.redshift.com (outgoing.redshift.com [207.177.231.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 564F543D55 for ; Mon, 13 Jun 2005 09:14:05 +0000 (GMT) (envelope-from ray@redshift.com) Received: from workstation (216-228-19-21.dsl.redshift.com [216.228.19.21]) by outgoing.redshift.com (Postfix) with SMTP id 02F30974D8; Mon, 13 Jun 2005 02:14:04 -0700 (PDT) Message-Id: <3.0.1.32.20050613021410.00a56bb8@pop.redshift.com> X-Mailer: na X-Sender: redshift.com Date: Mon, 13 Jun 2005 02:14:10 -0700 To: freebsd-hackers@freebsd.org From: ray@redshift.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: FreeBSD 5.3/4 vs 4.11 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, 13 Jun 2005 09:14:05 -0000 Hello list, I've recently been doing quite a few benchmarks with regard to PHP and Apache, as well as stripping down the Kernel on 5.3 and 5.4 to improve performance for web/application servers. My question is: I was wondering if anyone out there has ever done a head to head test of 4.11 to 5.3 (or 5.4) and if so, is 4.11 faster in any areas and/or does it provide any benefits over 5.3+? Thanks. Ray From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 09:22:57 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5292916A41C for ; Mon, 13 Jun 2005 09:22:57 +0000 (GMT) (envelope-from NKoch@demig.de) Received: from server.absolute-media.de (server.absolute-media.de [213.239.231.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5511643D4C for ; Mon, 13 Jun 2005 09:22:56 +0000 (GMT) (envelope-from NKoch@demig.de) Received: from localhost (unknown [127.0.0.1]) by server.absolute-media.de (Postfix) with ESMTP id 9D4E684EB3; Mon, 13 Jun 2005 11:22:54 +0200 (CEST) Received: from server.absolute-media.de ([127.0.0.1]) by localhost (server [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24076-04; Mon, 13 Jun 2005 11:22:49 +0200 (CEST) Received: from firewall.demig (p50839F04.dip0.t-ipconnect.de [80.131.159.4]) by server.absolute-media.de (Postfix) with ESMTP id 0BA187EDE6; Mon, 13 Jun 2005 11:22:48 +0200 (CEST) Received: from ws-ew-3 (ws-ew-3.w2kdemig [192.168.1.72]) by firewall.demig (8.13.4/8.13.1) with SMTP id j5D9JSKF031279; Mon, 13 Jun 2005 11:19:28 +0200 (CEST) (envelope-from NKoch@demig.de) From: "Norbert Koch" To: "Maksim Yevmenkin" Date: Mon, 13 Jun 2005 11:19:28 +0200 Message-ID: <000001c56ff8$ffda5b40$4801a8c0@ws-ew-3.W2KDEMIG> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_01C57009.C3632B40" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <42A0891F.8080800@savvis.net> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at absolute-media.de Cc: "Freebsd-Hackers@Freebsd. Org" Subject: RE: using vkbd device 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, 13 Jun 2005 09:22:57 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C57009.C3632B40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > you also might want to look at experimental keyboard mux drivers. it is > based on vkbd(4) and uses the idea of one super-keyboard that consumes > scancodes from other keyboards. there are still a few issues i need to > fix, but, in general, it works. > > http://www.geocities.com/m_evmenkin/kbdmux-2.tar.gz > > thanks, > max > Hello Max, I back-ported kbdmux to FreeBSD 4.11 (and stopped work on vkbd). It seems to work, although I still have some stability issues with dynamically attaching/detaching a usb keyboard. For your reference I have enclosed a patch file. Sorry for some diffs due to slightly different coding and debugging style. Thank you for any comments, Norbert ------=_NextPart_000_0001_01C57009.C3632B40 Content-Type: application/octet-stream; name="kbdmux.c.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="kbdmux.c.patch" LS0tIGtiZG11eC9rYmRtdXguYwlTYXQgTWF5IDIxIDAxOjUxOjQ3IDIwMDUKKysrIGtiZG11eC5j CU1vbiBKdW4gMTMgMTE6MDg6MTggMjAwNQpAQCAtMjcsNyArMjcsNyBAQAogICogT1VUIE9GIFRI RSBVU0UgT0YgVEhJUyBTT0ZUV0FSRSwgRVZFTiBJRiBBRFZJU0VEIE9GIFRIRSBQT1NTSUJJTElU WSBPRgogICogU1VDSCBEQU1BR0UuCiAgKgotICogJElkJAorICogJElkOiBrYmRtdXguYyx2IDEu NCAyMDA1LzA2LzEzIDA5OjA2OjMwIG5rIEV4cCAkCiAgKiAkRnJlZUJTRCQKICAqLwogCkBAIC0z NiwyNSArMzYsMTA4IEBACiAjaW5jbHVkZSA8c3lzL3BhcmFtLmg+CiAjaW5jbHVkZSA8c3lzL2Nv bmYuaD4KICNpbmNsdWRlIDxzeXMvY29uc2lvLmg+CisjaWYgX19GcmVlQlNEX3ZlcnNpb24gPj0g NjAwMDAwCiAjaW5jbHVkZSA8c3lzL2ZjbnRsLmg+CisjZWxzZQorI2luY2x1ZGUgPHN5cy92bm9k ZS5oPgorI2VuZGlmCiAjaW5jbHVkZSA8c3lzL2tiaW8uaD4KICNpbmNsdWRlIDxzeXMva2VybmVs Lmg+CisjaWYgX19GcmVlQlNEX3ZlcnNpb24gPj0gNTAwMDAwCiAjaW5jbHVkZSA8c3lzL2xpbWl0 cy5oPgorI2Vsc2UKKyNpbmNsdWRlIDxtYWNoaW5lL2xpbWl0cy5oPgorI2VuZGlmCiAjaW5jbHVk ZSA8c3lzL2xvY2suaD4KICNpbmNsdWRlIDxzeXMvbWFsbG9jLmg+CiAjaW5jbHVkZSA8c3lzL21v ZHVsZS5oPgorI2lmIF9fRnJlZUJTRF92ZXJzaW9uID49IDUwMDAxNAogI2luY2x1ZGUgPHN5cy9t dXRleC5oPgorI2VuZGlmCiAjaW5jbHVkZSA8c3lzL3BvbGwuaD4KICNpbmNsdWRlIDxzeXMvcHJv Yy5oPgogI2luY2x1ZGUgPHN5cy9xdWV1ZS5oPgorI2lmIF9fRnJlZUJTRF92ZXJzaW9uID49IDUw MDAxNAogI2luY2x1ZGUgPHN5cy9zZWxpbmZvLmg+CisjZWxzZQorI2luY2x1ZGUgPHN5cy9zZWxl Y3QuaD4KKyNlbmRpZgogI2luY2x1ZGUgPHN5cy9zeXN0bS5oPgogI2luY2x1ZGUgPHN5cy90YXNr cXVldWUuaD4KICNpbmNsdWRlIDxzeXMvdHR5Lmg+CiAjaW5jbHVkZSA8c3lzL3Vpby5oPgogI2lu Y2x1ZGUgPGRldi9rYmQva2JkcmVnLmg+CiAjaW5jbHVkZSA8ZGV2L2tiZC9rYmR0YWJsZXMuaD4K LSNpbmNsdWRlIDxkZXYva2JkbXV4L2tiZG11eF92YXIuaD4KKyNpbmNsdWRlICJrYmRtdXhfdmFy LmgiCisKKyNpZm5kZWYgREVCVUcKKyNkZWZpbmUgREVCVUcgICAgICAgICAgIDEKKyNlbmRpZgor I2lmbmRlZiBWRVJCT1NFCisjZGVmaW5lIFZFUkJPU0UgICAgICAgICAxCisjZW5kaWYKKyNpZm5k ZWYgREVCVUdfVVNFU1lTTE9HCisjZGVmaW5lIERFQlVHX1VTRVNZU0xPRyAwCisjZW5kaWYKKyNk ZWZpbmUgREVCVUdfVEFHICAgICAgIHZrYmQKKworI2RlZmluZSBERUJVR19RVUVVRSAgICAgREVC VUcKKworI2luY2x1ZGUgPGRldl9kZWJ1Zy9kZXZfZGVidWcuaD4KKworCisvKgorICogZGVjbGFy ZSB1aW50IHN5c2N0bCBkZWJ1Zy52a2JkX2RlYnVnCisgKiB3aXRoIGluaXRpYWwgdmFsdWUgb2Yg OQorICovCisKK2RlYnVnX3Zhcl9kZWNsKDkpOworZGVidWdfc3lzY3RsKCk7CisKKworLyoKKyAq IE9TIHNwZWNpZmljCisgKi8KKworI2RlZmluZSBQUFJJTyAgICAgICAgICAgICAgICAgICAoUFpF Uk8rMSkKKworI2lmIF9fRnJlZUJTRF92ZXJzaW9uID49IDUwMDAxNAorCisjZGVmaW5lIFRBU0tR VUVVRSAgICAgICAgICAgICAgIHRhc2txdWV1ZV9zd2lfZ2lhbnQKKworI2RlZmluZSBLQkRNVVhf TE9DS19ERUNMX0dMT0JBTCBzdHJ1Y3QgbXR4X2xvY2sga3NfbG9jaworI2RlZmluZSBLQkRNVVhf TE9DTF9ERUNMX0xPQ0FMCS8qIG9ubHkgZm9yIEZyZWVCU0QgNC5YICovCisjZGVmaW5lIEtCRE1V WF9MT0NLX0lOSVQocykgICAgIG10eF9pbml0ICgmIChzKS0+a3NfbG9jaywgTlVMTCwgTlVMTCwg TVRYX0RFRikKKyNkZWZpbmUgS0JETVVYX0xPQ0tfREVTVFJPWShzKSAgbXR4X2Rlc3Ryb3kgKCYg KHMpLT5rc19sb2NrKQorI2RlZmluZSBLQkRNVVhfTE9DSyhzKSAgICAgICAgICBtdHhfbG9jayAo JiAocyktPmtzX2xvY2spCisjZGVmaW5lIEtCRE1VWF9VTkxPQ0socykgICAgICAgIG10eF91bmxv Y2sgKCYgKHMpLT5rc19sb2NrKQorI2RlZmluZSBLQkRNVVhfTE9DS19BU1NFUlQocywgdyltdHhf YXNzZXJ0ICgmIChzKS0+a3NfbG9jaywgdykKKyNkZWZpbmUgS0JETVVYX1NMRUVQKHMsIGYsIGQs IHQsIGUpICBcCisgIGUgPSBtc2xlZXAgKCYgKHMpLT5mLCAmIChzKS0+a3NfbG9jaywgUENBVENI fFBQUklPLCBkLCB0KQorCisjZWxzZQorCisjZGVmaW5lIFRBU0tRVUVVRSAgICAgICAgICAgICAg IHRhc2txdWV1ZV9zd2kKKworI2RlZmluZSBLQkRNVVhfTE9DS19ERUNMX0dMT0JBTAkvKiBvbmx5 IGZvciBGcmVlQlNEIDUuWCBhbmQgdXAgKi8KKyNkZWZpbmUgS0JETVVYX0xPQ0tfREVDTF9MT0NB TCAgaW50cm1hc2tfdCBpcGwKKyNkZWZpbmUgS0JETVVYX0xPQ0tfSU5JVChzKQkvKiBvbmx5IGZv ciBGcmVlQlNEIDUuWCBhbmQgdXAgKi8KKyNkZWZpbmUgS0JETVVYX0xPQ0tfREVTVFJPWShzKQkv KiBvbmx5IGZvciBGcmVlQlNEIDUuWCBhbmQgdXAgKi8KKyNkZWZpbmUgS0JETVVYX0xPQ0socykg ICAgICAgICAgaXBsID0gc3BsaGlnaCAoKQorI2RlZmluZSBLQkRNVVhfVU5MT0NLKHMpICAgICAg ICBzcGx4IChpcGwpCisjZGVmaW5lIEtCRE1VWF9MT0NLX0FTU0VSVChzLCB3KQkvKiBvbmx5IGJ5 IEZyZWVCU0QgNS5YIGFuZCB1cAorCQkJCQkgKiBzdXBwb3J0ZWQgKi8KKyNkZWZpbmUgS0JETVVY X1NMRUVQKHMsIGYsIGQsIHQpICAgICAgICAgICAgICAgIFwKKyAgZG8gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKKyAgeyAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFwKKyAgICBLQkRNVVhfVU5MT0NLIChzKTsgICAgICAgICAg ICAgICAgICAgICAgICAgIFwKKyAgICB0c2xlZXAgKCYgKHMpLT5mLCBQQ0FUQ0h8UFBSSU8sIGQs IHQpOyAgICAgIFwKKyAgICBLQkRNVVhfTE9DSyAocyk7ICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFwKKyAgfSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwK KyAgd2hpbGUgKDApCisKKyNlbmRpZgorCiAKICNkZWZpbmUgS0VZQk9BUkRfTkFNRQkia2JkbXV4 IgogCkBAIC02NywxNSArMTUwLDYgQEAKICAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgogICoqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqLwogCi0jZGVmaW5lIEtCRE1VWF9MT0NLX0RFQ0wJc3RydWN0IG10eCBrc19s b2NrCi0jZGVmaW5lIEtCRE1VWF9MT0NLX0lOSVQocykJbXR4X2luaXQoJihzKS0+a3NfbG9jaywg TlVMTCwgTlVMTCwgTVRYX0RFRikKLSNkZWZpbmUgS0JETVVYX0xPQ0tfREVTVFJPWShzKQltdHhf ZGVzdHJveSgmKHMpLT5rc19sb2NrKQotI2RlZmluZSBLQkRNVVhfTE9DSyhzKQkJbXR4X2xvY2so JihzKS0+a3NfbG9jaykKLSNkZWZpbmUgS0JETVVYX1VOTE9DSyhzKQltdHhfdW5sb2NrKCYocykt PmtzX2xvY2spCi0jZGVmaW5lIEtCRE1VWF9MT0NLX0FTU0VSVChzLCB3KQltdHhfYXNzZXJ0KCYo cyktPmtzX2xvY2ssIHcpCi0jZGVmaW5lIEtCRE1VWF9TTEVFUChzLCBmLCBkLCB0KSBcCi0JbXNs ZWVwKCYocyktPmYsICYocyktPmtzX2xvY2ssIFBDQVRDSCB8IChQWkVSTyArIDEpLCBkLCB0KQot CiAjZGVmaW5lCUtCRE1VWF9JTlRSKGtiZCwgYXJnKSBcCiAJKCprYmRzd1soa2JkKS0+a2JfaW5k ZXhdLT5pbnRyKSgoa2JkKSwgKGFyZykpCiAKQEAgLTkxLDkgKzE2NSwxMCBAQAogI2RlZmluZQlL QkRNVVhfRU5BQkxFKGtiZCkgXAogCSgqa2Jkc3dbKGtiZCktPmtiX2luZGV4XS0+ZW5hYmxlKSgo a2JkKSkKIAotLyoga2JkbXV4IGtleWJvYXJkICovCi1zdHJ1Y3Qga2JkbXV4X2tiZAoteworLyoK KyAqIGtiZG11eCBrZXlib2FyZCAKKyAqLworc3RydWN0IGtiZG11eF9rYmQgewogCWtleWJvYXJk X3QJCSprYmQ7CS8qIGtleWJvYXJkICovCiAJaW50CQkJIGlkeDsJLyoga2V5Ym9hcmQgaW5kZXgg Ki8KIAlTTElTVF9FTlRSWShrYmRtdXhfa2JkKQkgbmV4dDsJLyogbGluayB0byBuZXh0ICovCkBA IC0xMDEsOSArMTc2LDEwIEBACiAKIHR5cGVkZWYgc3RydWN0IGtiZG11eF9rYmQJa2JkbXV4X2ti ZF90OwogCi0vKiBrYmRtdXggc3RhdGUgKi8KLXN0cnVjdCBrYmRtdXhfc3RhdGUKLXsKKy8qCisg KiBrYmRtdXggc3RhdGUgCisgKi8KK3N0cnVjdCBrYmRtdXhfc3RhdGUgewogCXN0cnVjdCBjbGlz dAkJIGtzX2lucTsJLyogaW5wdXQgY2hhcnMgcXVldWUgKi8KIAlzdHJ1Y3QgdGFzawkJIGtzX3Rh c2s7CS8qIGludGVycnVwdCB0YXNrICovCiAKQEAgLTEyMCw3ICsxOTYsNyBAQAogCiAJU0xJU1Rf SEVBRCgsIGtiZG11eF9rYmQpIGtzX2tiZHM7CS8qIGtleWJvYXJkcyAqLwogCi0JS0JETVVYX0xP Q0tfREVDTDsKKwkgICAgICAgICAgICAgICAgS0JETVVYX0xPQ0tfREVDTF9HTE9CQUw7CiB9Owog CiB0eXBlZGVmIHN0cnVjdCBrYmRtdXhfc3RhdGUJa2JkbXV4X3N0YXRlX3Q7CkBAIC0xMzQsMTIg KzIxMCwxNSBAQAogc3RhdGljIHZvaWQJCQlrYmRtdXhfa2JkX2ludHIodm9pZCAqLCBpbnQpOwog c3RhdGljIGtiZF9jYWxsYmFja19mdW5jX3QJa2JkbXV4X2tiZF9ldmVudDsKIAotLyogSW50ZXJy dXB0IGhhbmRsZXIgdGFzayAqLworLyoKKyAqIEludGVycnVwdCBoYW5kbGVyIHRhc2sgCisgKi8K IHZvaWQKIGtiZG11eF9rYmRfaW50cih2b2lkICp4a2JkLCBpbnQgcGVuZGluZykKIHsKIAlrZXli b2FyZF90CSprYmQgPSAoa2V5Ym9hcmRfdCAqKSB4a2JkOwogCWtiZG11eF9zdGF0ZV90CSpzdGF0 ZSA9IChrYmRtdXhfc3RhdGVfdCAqKSBrYmQtPmtiX2RhdGE7CisJS0JETVVYX0xPQ0tfREVDTF9M T0NBTDsKIAogCUtCRE1VWF9JTlRSKGtiZCwgTlVMTCk7CiAKQEAgLTE1MSwxOSArMjMwLDI1IEBA CiAJS0JETVVYX1VOTE9DSyhzdGF0ZSk7CiB9CiAKLS8qIFByb2Nlc3MgZXZlbnQgZnJvbSBvbmUg b2Ygb3VyIGtleWJvYXJkcyAqLworLyoKKyAqIFByb2Nlc3MgZXZlbnQgZnJvbSBvbmUgb2Ygb3Vy IGtleWJvYXJkcyAKKyAqLwogc3RhdGljIGludAoga2JkbXV4X2tiZF9ldmVudChrZXlib2FyZF90 ICprYmQsIGludCBldmVudCwgdm9pZCAqYXJnKQogewogCWtiZG11eF9zdGF0ZV90CSpzdGF0ZSA9 IChrYmRtdXhfc3RhdGVfdCAqKSBhcmc7CiAKIAlzd2l0Y2ggKGV2ZW50KSB7Ci0JY2FzZSBLQkRJ T19LRVlJTlBVVDogeworCWNhc2UgS0JESU9fS0VZSU5QVVQ6CisJCXsKIAkJaW50CWM7CisJCQlL QkRNVVhfTE9DS19ERUNMX0xPQ0FMOwogCiAJCUtCRE1VWF9MT0NLKHN0YXRlKTsKIAotCQkvKiBy ZWFkIGFsbCBjaGFycyBmcm9tIHRoZSBrZXlib2FyZCAqLworCQkJLyoKKwkJCSAqIHJlYWQgYWxs IGNoYXJzIGZyb20gdGhlIGtleWJvYXJkIAorCQkJICovCiAJCXdoaWxlIChLQkRNVVhfQ0hFQ0tf Q0hBUihrYmQpKSB7CiAJCQljID0gS0JETVVYX1JFQURfQ0hBUihrYmQsIDApOwogCQkJaWYgKGMg PT0gTk9LRVkpCkBAIC0xNzEsMzEgKzI1NiwzOSBAQAogCQkJaWYgKGMgPT0gRVJSS0VZKQogCQkJ CWNvbnRpbnVlOyAvKiBYWFggcmluZyBiZWxsICovCiAJCQlpZiAoIUtCRF9JU19CVVNZKGtiZCkp Ci0JCQkJY29udGludWU7IC8qIG5vdCBvcGVuIC0gZGlzY2FyZCB0aGUgaW5wdXQgKi8KKwkJCQkJ Y29udGludWU7CS8qIG5vdCBvcGVuIC0gZGlzY2FyZAorCQkJCQkJCSAqIHRoZSBpbnB1dCAqLwog CiAJCQlwdXRjKGMsICZzdGF0ZS0+a3NfaW5xKTsKIAkJfQogCi0JCS8qIHF1ZXVlIGludGVycnVw dCB0YXNrIGlmIG5lZWRlZCAqLwotCQlpZiAoc3RhdGUtPmtzX2lucS5jX2NjID4gMCAmJiAhKHN0 YXRlLT5rc19mbGFncyAmIFRBU0spICYmCi0JCSAgICB0YXNrcXVldWVfZW5xdWV1ZSh0YXNrcXVl dWVfc3dpX2dpYW50LCAmc3RhdGUtPmtzX3Rhc2spID09IDApCisJCQkvKgorCQkJICogcXVldWUg aW50ZXJydXB0IHRhc2sgaWYgbmVlZGVkIAorCQkJICovCisJCQlpZiAoc3RhdGUtPmtzX2lucS5j X2NjID4gMCAmJiAhKHN0YXRlLT5rc19mbGFncyAmIFRBU0spCisJCQkgICAgJiYgdGFza3F1ZXVl X2VucXVldWUoVEFTS1FVRVVFLAorCQkJCQkJICZzdGF0ZS0+a3NfdGFzaykgPT0gMCkKIAkJCXN0 YXRlLT5rc19mbGFncyB8PSBUQVNLOwogCiAJCUtCRE1VWF9VTkxPQ0soc3RhdGUpOwotCQl9IGJy ZWFrOworCQl9CisJCWJyZWFrOwogCi0JY2FzZSBLQkRJT19VTkxPQURJTkc6IHsKKwljYXNlIEtC RElPX1VOTE9BRElORzoKKwkJewogCQlrYmRtdXhfa2JkX3QJKms7CisJCQlLQkRNVVhfTE9DS19E RUNMX0xPQ0FMOwogCiAJCUtCRE1VWF9MT0NLKHN0YXRlKTsKIAotCQlTTElTVF9GT1JFQUNIKGss ICZzdGF0ZS0+a3Nfa2JkcywgbmV4dCkKLQkJCWlmIChrLT5rYmQgPT0ga2JkKQorCQkJU0xJU1Rf Rk9SRUFDSChrLCAmc3RhdGUtPmtzX2tiZHMsCisJCQkJICAgICAgbmV4dCkgaWYgKGstPmtiZCA9 PSBrYmQpCiAJCQkJYnJlYWs7CiAKIAkJaWYgKGsgIT0gTlVMTCkgewogCQkJa2JkX3JlbGVhc2Uo ay0+a2JkLCAmay0+a2JkKTsKLQkJCVNMSVNUX1JFTU9WRSgmc3RhdGUtPmtzX2tiZHMsIGssIGti ZG11eF9rYmQsIG5leHQpOworCQkJCVNMSVNUX1JFTU9WRSgmc3RhdGUtPmtzX2tiZHMsIGssIGti ZG11eF9rYmQsCisJCQkJCSAgICAgbmV4dCk7CiAKIAkJCWstPmtiZCA9IE5VTEw7CiAJCQlrLT5p ZHggPSAtMTsKQEAgLTIwNCwxMSArMjk3LDE0IEBACiAJCX0KIAogCQlLQkRNVVhfVU5MT0NLKHN0 YXRlKTsKLQkJfSBicmVhazsKKwkJfQorCQlicmVhazsKIAogCWRlZmF1bHQ6CiAJCXJldHVybiAo RUlOVkFMKTsKLQkJLyogTk9UIFJFQUNIRUQgKi8KKwkJLyoKKwkJICogTk9UIFJFQUNIRUQgCisJ CSAqLwogCX0KIAogCXJldHVybiAoMCk7CkBAIC0yNDAsNiArMzM2LDggQEAKIHN0YXRpYyBrYmRf c2V0X3N0YXRlX3QJa2JkbXV4X3NldF9zdGF0ZTsKIHN0YXRpYyBrYmRfcG9sbF9tb2RlX3QJa2Jk bXV4X3BvbGw7CiAKKyNpZiBfX0ZyZWVCU0RfdmVyc2lvbiA+PSA1MDAwMTQKKwogc3RhdGljIGtl eWJvYXJkX3N3aXRjaF90IGtiZG11eHN3ID0gewogCS5wcm9iZSA9CWtiZG11eF9wcm9iZSwKIAku aW5pdCA9CQlrYmRtdXhfaW5pdCwKQEAgLTI2MiwyMSArMzYwLDUzIEBACiAJLmRpYWcgPQkJZ2Vu a2JkX2RpYWcsCiB9OwogCi0vKiBSZXR1cm4gdGhlIG51bWJlciBvZiBmb3VuZCBrZXlib2FyZHMg Ki8KKyNlbHNlCisKK3N0YXRpYyBrZXlib2FyZF9zd2l0Y2hfdCBrYmRtdXhzdyA9IHsKKwlrYmRt dXhfcHJvYmUsCisJa2JkbXV4X2luaXQsCisJa2JkbXV4X3Rlcm0sCisJa2JkbXV4X2ludHIsCisJ a2JkbXV4X3Rlc3RfaWYsCisJa2JkbXV4X2VuYWJsZSwKKwlrYmRtdXhfZGlzYWJsZSwKKwlrYmRt dXhfcmVhZCwKKwlrYmRtdXhfY2hlY2ssCisJa2JkbXV4X3JlYWRfY2hhciwKKwlrYmRtdXhfY2hl Y2tfY2hhciwKKwlrYmRtdXhfaW9jdGwsCisJa2JkbXV4X2xvY2ssCisJa2JkbXV4X2NsZWFyX3N0 YXRlLAorCWtiZG11eF9nZXRfc3RhdGUsCisJa2JkbXV4X3NldF9zdGF0ZSwKKwlnZW5rYmRfZ2V0 X2ZrZXlzdHIsCisJa2JkbXV4X3BvbGwsCisJZ2Vua2JkX2RpYWcKK307CisKKyNlbmRpZgorCisv KgorICogUmV0dXJuIHRoZSBudW1iZXIgb2YgZm91bmQga2V5Ym9hcmRzIAorICovCiBzdGF0aWMg aW50CiBrYmRtdXhfY29uZmlndXJlKGludCBmbGFncykKIHsKIAlyZXR1cm4gKDEpOwogfQogCi0v KiBEZXRlY3QgYSBrZXlib2FyZCAqLworLyoKKyAqIERldGVjdCBhIGtleWJvYXJkIAorICovCiBz dGF0aWMgaW50CiBrYmRtdXhfcHJvYmUoaW50IHVuaXQsIHZvaWQgKmFyZywgaW50IGZsYWdzKQog ewogCXJldHVybiAoMCk7CiB9CiAKLS8qIFJlc2V0IGFuZCBpbml0aWFsaXplIHRoZSBrZXlib2Fy ZCAoc3RvbGVuIGZyb20gYXRrYmQuYykgKi8KKy8qCisgKiBSZXNldCBhbmQgaW5pdGlhbGl6ZSB0 aGUga2V5Ym9hcmQgKHN0b2xlbiBmcm9tIGF0a2JkLmMpIAorICovCiBzdGF0aWMgaW50CiBrYmRt dXhfaW5pdChpbnQgdW5pdCwga2V5Ym9hcmRfdCAqKmtiZHAsIHZvaWQgKmFyZywgaW50IGZsYWdz KQogewpAQCAtMjg2LDkgKzQxNiwxMSBAQAogICAgICAgICBhY2NlbnRtYXBfdAkqYWNjbWFwID0g TlVMTDsKICAgICAgICAgZmtleXRhYl90CSpma2V5bWFwID0gTlVMTDsKIAlpbnQJCSBlcnJvciwg bmVlZGZyZWUsIGZrZXltYXBfc2l6ZTsKKwlLQkRNVVhfTE9DS19ERUNMX0xPQ0FMOwogCiAJaWYg KCprYmRwID09IE5VTEwpIHsKLQkJKmtiZHAgPSBrYmQgPSBtYWxsb2Moc2l6ZW9mKCprYmQpLCBN X0tCRE1VWCwgTV9OT1dBSVQgfCBNX1pFUk8pOworCQkqa2JkcCA9IGtiZCA9CisJCSAgICBtYWxs b2Moc2l6ZW9mKCprYmQpLCBNX0tCRE1VWCwgTV9OT1dBSVQgfCBNX1pFUk8pOwogCQlzdGF0ZSA9 IG1hbGxvYyhzaXplb2YoKnN0YXRlKSwgTV9LQkRNVVgsIE1fTk9XQUlUIHwgTV9aRVJPKTsKIAkJ a2V5bWFwID0gbWFsbG9jKHNpemVvZihrZXlfbWFwKSwgTV9LQkRNVVgsIE1fTk9XQUlUKTsKIAkJ YWNjbWFwID0gbWFsbG9jKHNpemVvZihhY2NlbnRfbWFwKSwgTV9LQkRNVVgsIE1fTk9XQUlUKTsK QEAgLTMwMyw3ICs0MzUsOCBAQAogCQl9CiAKIAkJS0JETVVYX0xPQ0tfSU5JVChzdGF0ZSk7Ci0J CWNsaXN0X2FsbG9jX2NibG9ja3MoJnN0YXRlLT5rc19pbnEsIEtCRE1VWF9RX1NJWkUsIEtCRE1V WF9RX1NJWkUgLyAyKTsgLyogWFhYICovCisJCWNsaXN0X2FsbG9jX2NibG9ja3MoJnN0YXRlLT5r c19pbnEsIEtCRE1VWF9RX1NJWkUsIEtCRE1VWF9RX1NJWkUgLyAyKTsJLyogWFhYIAorCQkJCQkJ CQkJCQkgKi8KIAkJVEFTS19JTklUKCZzdGF0ZS0+a3NfdGFzaywgMCwga2JkbXV4X2tiZF9pbnRy LCAodm9pZCAqKSBrYmQpOwogCQlTTElTVF9JTklUKCZzdGF0ZS0+a3Nfa2Jkcyk7CiAJfSBlbHNl IGlmIChLQkRfSVNfSU5JVElBTElaRUQoKmtiZHApICYmIEtCRF9JU19DT05GSUdVUkVEKCprYmRw KSkgewpAQCAtMzE5LDEyICs0NTIsMTUgQEAKIAl9CiAKIAlpZiAoIUtCRF9JU19QUk9CRUQoa2Jk KSkgewotCQkvKiBYWFggYXNzdW1lIDEwMS8xMDIga2V5cyBrZXlib2FyZCAqLworCQkvKgorCQkg KiBYWFggYXNzdW1lIDEwMS8xMDIga2V5cyBrZXlib2FyZCAKKwkJICovCiAJCWtiZF9pbml0X3N0 cnVjdChrYmQsIEtFWUJPQVJEX05BTUUsIEtCXzEwMSwgdW5pdCwgZmxhZ3MsIDAsIDApOwogCQli Y29weSgma2V5X21hcCwga2V5bWFwLCBzaXplb2Yoa2V5X21hcCkpOwogCQliY29weSgmYWNjZW50 X21hcCwgYWNjbWFwLCBzaXplb2YoYWNjZW50X21hcCkpOwogCQliY29weShma2V5X3RhYiwgZmtl eW1hcCwKLQkJCWltaW4oZmtleW1hcF9zaXplKnNpemVvZihma2V5bWFwWzBdKSwgc2l6ZW9mKGZr ZXlfdGFiKSkpOworCQkgICAgICBpbWluKGZrZXltYXBfc2l6ZSAqIHNpemVvZihma2V5bWFwWzBd KSwKKwkJCSAgIHNpemVvZihma2V5X3RhYikpKTsKIAkJa2JkX3NldF9tYXBzKGtiZCwga2V5bWFw LCBhY2NtYXAsIGZrZXltYXAsIGZrZXltYXBfc2l6ZSk7CiAJCWtiZC0+a2JfZGF0YSA9ICh2b2lk ICopc3RhdGU7CiAJCkBAIC0zNDAsMTIgKzQ3NiwxMSBAQAogCWlmICghS0JEX0lTX0lOSVRJQUxJ WkVEKGtiZCkgJiYgIShmbGFncyAmIEtCX0NPTkZfUFJPQkVfT05MWSkpIHsKIAkJa2JkLT5rYl9j b25maWcgPSBmbGFncyAmIH5LQl9DT05GX1BST0JFX09OTFk7CiAKLS8qIFhYWAotCQlrYmRtdXhf aW9jdGwoa2JkLCBLRFNFVExFRCwgKGNhZGRyX3QpJnN0YXRlLT5rc19zdGF0ZSk7Ci0JCWRlbGF5 WzBdID0ga2JkLT5rYl9kZWxheTE7Ci0JCWRlbGF5WzFdID0ga2JkLT5rYl9kZWxheTI7Ci0JCWti ZG11eF9pb2N0bChrYmQsIEtEU0VUUkVQRUFULCAoY2FkZHJfdClkZWxheSk7Ci1YWFggKi8KKwkJ LyoKKwkJICogWFhYIGtiZG11eF9pb2N0bChrYmQsIEtEU0VUTEVELCAoY2FkZHJfdCkmc3RhdGUt PmtzX3N0YXRlKTsKKwkJICogZGVsYXlbMF0gPSBrYmQtPmtiX2RlbGF5MTsgZGVsYXlbMV0gPSBr YmQtPmtiX2RlbGF5MjsKKwkJICoga2JkbXV4X2lvY3RsKGtiZCwgS0RTRVRSRVBFQVQsIChjYWRk cl90KWRlbGF5KTsgWFhYIAorCQkgKi8KIAogCQlLQkRfSU5JVF9ET05FKGtiZCk7CiAJfQpAQCAt MzgxLDIwICs1MTYsMjcgQEAKIAlyZXR1cm4gKGVycm9yKTsKIH0KIAotLyogRmluaXNoIHVzaW5n IHRoaXMga2V5Ym9hcmQgKi8KKy8qCisgKiBGaW5pc2ggdXNpbmcgdGhpcyBrZXlib2FyZCAKKyAq Lwogc3RhdGljIGludAoga2JkbXV4X3Rlcm0oa2V5Ym9hcmRfdCAqa2JkKQogewogCWtiZG11eF9z dGF0ZV90CSpzdGF0ZSA9IChrYmRtdXhfc3RhdGVfdCAqKSBrYmQtPmtiX2RhdGE7CiAJa2JkbXV4 X2tiZF90CSprOworCUtCRE1VWF9MT0NLX0RFQ0xfTE9DQUw7CiAKIAlLQkRNVVhfTE9DSyhzdGF0 ZSk7CiAKLQkvKiB3YWl0IGZvciBpbnRlcnJ1cHQgdGFzayAqLworCS8qCisJICogd2FpdCBmb3Ig aW50ZXJydXB0IHRhc2sgCisJICovCiAJd2hpbGUgKHN0YXRlLT5rc19mbGFncyAmIFRBU0spCiAJ CUtCRE1VWF9TTEVFUChzdGF0ZSwga3NfdGFzaywgImtiZG11eGMiLCAwKTsKIAotCS8qIHJlbGVh c2UgYWxsIGtleWJvYXJkcyBmcm9tIHRoZSBtdXggKi8KKwkvKgorCSAqIHJlbGVhc2UgYWxsIGtl eWJvYXJkcyBmcm9tIHRoZSBtdXggCisJICovCiAJd2hpbGUgKChrID0gU0xJU1RfRklSU1QoJnN0 YXRlLT5rc19rYmRzKSkgIT0gTlVMTCkgewogCQlrYmRfcmVsZWFzZShrLT5rYmQsICZrLT5rYmQp OwogCQlTTElTVF9SRU1PVkVfSEVBRCgmc3RhdGUtPmtzX2tiZHMsIG5leHQpOwpAQCAtNDA1LDcg KzU0Nyw5IEBACiAJCWZyZWUoaywgTV9LQkRNVVgpOwogCX0KIAotCS8qIGZsdXNoIGlucHV0IHF1 ZXVlICovCisJLyoKKwkgKiBmbHVzaCBpbnB1dCBxdWV1ZSAKKwkgKi8KIAluZGZsdXNoKCZzdGF0 ZS0+a3NfaW5xLCBzdGF0ZS0+a3NfaW5xLmNfY2MpOwogCWNsaXN0X2ZyZWVfY2Jsb2Nrcygmc3Rh dGUtPmtzX2lucSk7CiAKQEAgLTQyMSwyNyArNTY1LDM2IEBACiAJcmV0dXJuICgwKTsKIH0KIAot LyogS2V5Ym9hcmQgaW50ZXJydXB0IHJvdXRpbmUgKi8KKy8qCisgKiBLZXlib2FyZCBpbnRlcnJ1 cHQgcm91dGluZSAKKyAqLwogc3RhdGljIGludAoga2JkbXV4X2ludHIoa2V5Ym9hcmRfdCAqa2Jk LCB2b2lkICphcmcpCiB7CiAJaW50CWM7CiAKIAlpZiAoS0JEX0lTX0FDVElWRShrYmQpICYmIEtC RF9JU19CVVNZKGtiZCkpIHsKLQkJLyogbGV0IHRoZSBjYWxsYmFjayBmdW5jdGlvbiB0byBwcm9j ZXNzIHRoZSBpbnB1dCAqLworCQkvKgorCQkgKiBsZXQgdGhlIGNhbGxiYWNrIGZ1bmN0aW9uIHRv IHByb2Nlc3MgdGhlIGlucHV0IAorCQkgKi8KIAkJKCprYmQtPmtiX2NhbGxiYWNrLmtjX2Z1bmMp KGtiZCwgS0JESU9fS0VZSU5QVVQsCiAJCQkJCSAgICBrYmQtPmtiX2NhbGxiYWNrLmtjX2FyZyk7 CiAJfSBlbHNlIHsKLQkJLyogcmVhZCBhbmQgZGlzY2FyZCB0aGUgaW5wdXQ7IG5vIG9uZSBpcyB3 YWl0aW5nIGZvciBpbnB1dCAqLworCQkvKgorCQkgKiByZWFkIGFuZCBkaXNjYXJkIHRoZSBpbnB1 dDsgbm8gb25lIGlzIHdhaXRpbmcgZm9yIGlucHV0IAorCQkgKi8KIAkJZG8gewogCQkJYyA9IGti ZG11eF9yZWFkX2NoYXIoa2JkLCBGQUxTRSk7Ci0JCX0gd2hpbGUgKGMgIT0gTk9LRVkpOworCQl9 CisJCXdoaWxlIChjICE9IE5PS0VZKTsKIAl9CiAKIAlyZXR1cm4gKDApOwogfQogCi0vKiBUZXN0 IHRoZSBpbnRlcmZhY2UgdG8gdGhlIGRldmljZSAqLworLyoKKyAqIFRlc3QgdGhlIGludGVyZmFj ZSB0byB0aGUgZGV2aWNlIAorICovCiBzdGF0aWMgaW50CiBrYmRtdXhfdGVzdF9pZihrZXlib2Fy ZF90ICprYmQpCiB7CkBAIC00NjAsNyArNjEzLDkgQEAKIAlyZXR1cm4gKDApOwogfQogCi0vKiBE aXNhbGxvdyB0aGUgYWNjZXNzIHRvIHRoZSBkZXZpY2UgKi8KKy8qCisgKiBEaXNhbGxvdyB0aGUg YWNjZXNzIHRvIHRoZSBkZXZpY2UgCisgKi8KIHN0YXRpYyBpbnQKIGtiZG11eF9kaXNhYmxlKGtl eWJvYXJkX3QgKmtiZCkKIHsKQEAgLTQ2OCwxMiArNjIzLDE1IEBACiAJcmV0dXJuICgwKTsKIH0K IAotLyogUmVhZCBvbmUgYnl0ZSBmcm9tIHRoZSBrZXlib2FyZCBpZiBpdCdzIGFsbG93ZWQgKi8K Ky8qCisgKiBSZWFkIG9uZSBieXRlIGZyb20gdGhlIGtleWJvYXJkIGlmIGl0J3MgYWxsb3dlZCAK KyAqLwogc3RhdGljIGludAoga2JkbXV4X3JlYWQoa2V5Ym9hcmRfdCAqa2JkLCBpbnQgd2FpdCkK IHsKIAlrYmRtdXhfc3RhdGVfdAkqc3RhdGUgPSAoa2JkbXV4X3N0YXRlX3QgKikga2JkLT5rYl9k YXRhOwogCWludAkJIGM7CisJS0JETVVYX0xPQ0tfREVDTF9MT0NBTDsKIAogCUtCRE1VWF9MT0NL KHN0YXRlKTsKIAljID0gZ2V0Yygmc3RhdGUtPmtzX2lucSk7CkBAIC00ODUsMTIgKzY0MywxNSBA QAogCXJldHVybiAoS0JEX0lTX0FDVElWRShrYmQpPyBjIDogLTEpOwogfQogCi0vKiBDaGVjayBp ZiBkYXRhIGlzIHdhaXRpbmcgKi8KKy8qCisgKiBDaGVjayBpZiBkYXRhIGlzIHdhaXRpbmcgCisg Ki8KIHN0YXRpYyBpbnQKIGtiZG11eF9jaGVjayhrZXlib2FyZF90ICprYmQpCiB7CiAJa2JkbXV4 X3N0YXRlX3QJKnN0YXRlID0gTlVMTDsKIAlpbnQJCSByZWFkeTsKKwlLQkRNVVhfTE9DS19ERUNM X0xPQ0FMOwogCiAJaWYgKCFLQkRfSVNfQUNUSVZFKGtiZCkpCiAJCXJldHVybiAoRkFMU0UpOwpA QCAtNTA0LDE5ICs2NjUsMjQgQEAKIAlyZXR1cm4gKHJlYWR5KTsKIH0KIAotLyogUmVhZCBjaGFy IGZyb20gdGhlIGtleWJvYXJkIChzdG9sZW4gZnJvbSBhdGtiZC5jKSAqLworLyoKKyAqIFJlYWQg Y2hhciBmcm9tIHRoZSBrZXlib2FyZCAoc3RvbGVuIGZyb20gYXRrYmQuYykgCisgKi8KIHN0YXRp YyB1X2ludAoga2JkbXV4X3JlYWRfY2hhcihrZXlib2FyZF90ICprYmQsIGludCB3YWl0KQogewog CWtiZG11eF9zdGF0ZV90CSpzdGF0ZSA9IChrYmRtdXhfc3RhdGVfdCAqKSBrYmQtPmtiX2RhdGE7 CiAJdV9pbnQJCSBhY3Rpb247CiAJaW50CQkgc2NhbmNvZGUsIGtleWNvZGU7CisJS0JETVVYX0xP Q0tfREVDTF9MT0NBTDsKIAogCUtCRE1VWF9MT0NLKHN0YXRlKTsKIAogbmV4dF9jb2RlOgogCi0J LyogZG8gd2UgaGF2ZSBhIGNvbXBvc2VkIGNoYXIgdG8gcmV0dXJuPyAqLworCS8qCisJICogZG8g d2UgaGF2ZSBhIGNvbXBvc2VkIGNoYXIgdG8gcmV0dXJuPyAKKwkgKi8KIAlpZiAoIShzdGF0ZS0+ a3NfZmxhZ3MgJiBDT01QT1NFKSAmJiAoc3RhdGUtPmtzX2NvbXBvc2VkX2NoYXIgPiAwKSkgewog CQlhY3Rpb24gPSBzdGF0ZS0+a3NfY29tcG9zZWRfY2hhcjsKIAkJc3RhdGUtPmtzX2NvbXBvc2Vk X2NoYXIgPSAwOwpAQCAtNTMxLDIzICs2OTcsMzEgQEAKIAkJcmV0dXJuIChhY3Rpb24pOwogCX0K IAotCS8qIHNlZSBpZiB0aGVyZSBpcyBzb21ldGhpbmcgaW4gdGhlIGtleWJvYXJkIHF1ZXVlICov CisJLyoKKwkgKiBzZWUgaWYgdGhlcmUgaXMgc29tZXRoaW5nIGluIHRoZSBrZXlib2FyZCBxdWV1 ZSAKKwkgKi8KIAlzY2FuY29kZSA9IGdldGMoJnN0YXRlLT5rc19pbnEpOwogCWlmIChzY2FuY29k ZSA9PSAtMSkgewogCQlLQkRNVVhfVU5MT0NLKHN0YXRlKTsKIAkJcmV0dXJuIChOT0tFWSk7CiAJ fQotCS8qIFhYWCBGSVhNRTogY2hlY2sgZm9yIC0xIGlmIHdhaXQgPT0gMSEgKi8KKwkvKgorCSAq IFhYWCBGSVhNRTogY2hlY2sgZm9yIC0xIGlmIHdhaXQgPT0gMSEgCisJICovCiAKIAlrYmQtPmti X2NvdW50ICsrOwogCi0JLyogcmV0dXJuIHRoZSBieXRlIGFzIGlzIGZvciB0aGUgS19SQVcgbW9k ZSAqLworCS8qCisJICogcmV0dXJuIHRoZSBieXRlIGFzIGlzIGZvciB0aGUgS19SQVcgbW9kZSAK KwkgKi8KIAlpZiAoc3RhdGUtPmtzX21vZGUgPT0gS19SQVcpIHsKIAkJS0JETVVYX1VOTE9DSyhz dGF0ZSk7CiAJCXJldHVybiAoc2NhbmNvZGUpOwogCX0KIAotCS8qIHRyYW5zbGF0ZSB0aGUgc2Nh biBjb2RlIGludG8gYSBrZXljb2RlICovCisJLyoKKwkgKiB0cmFuc2xhdGUgdGhlIHNjYW4gY29k ZSBpbnRvIGEga2V5Y29kZSAKKwkgKi8KIAlrZXljb2RlID0gc2NhbmNvZGUgJiAweDdGOwogCXN3 aXRjaCAoc3RhdGUtPmtzX3ByZWZpeCkgewogCWNhc2UgMHgwMDoJLyogbm9ybWFsIHNjYW5jb2Rl ICovCkBAIC02MjIsNyArNzk2LDkgQEAKIAkJY2FzZSAweDUzOgkvKiBncmV5IGRlbGV0ZSBrZXkg Ki8KIAkJCWtleWNvZGUgPSAweDY3OwogCQkJYnJlYWs7Ci0JCS8qIHRoZSBmb2xsb3dpbmcgMyBh cmUgb25seSB1c2VkIG9uIHRoZSBNUyAiTmF0dXJhbCIga2V5Ym9hcmQgKi8KKwkJCS8qCisJCQkg KiB0aGUgZm9sbG93aW5nIDMgYXJlIG9ubHkgdXNlZCBvbiB0aGUgTVMgIk5hdHVyYWwiIGtleWJv YXJkIAorCQkJICovCiAJCWNhc2UgMHg1YjoJLyogbGVmdCBXaW5kb3cga2V5ICovCiAJCQlrZXlj b2RlID0gMHg2OTsKIAkJCWJyZWFrOwpAQCAtNjU2LDcgKzgzMiw5IEBACiAJCWlmIChrZXljb2Rl ID09IDB4MUQpCiAJCQlzdGF0ZS0+a3NfcHJlZml4ID0gMHgxRDsKIAkJZ290byBuZXh0X2NvZGU7 Ci0JCS8qIE5PVCBSRUFDSEVEICovCisJCS8qCisJCSAqIE5PVCBSRUFDSEVEIAorCQkgKi8KIAlj YXNlIDB4MUQ6CS8qIHBhdXNlIC8gYnJlYWsgKi8KIAkJc3RhdGUtPmtzX3ByZWZpeCA9IDA7CiAJ CWlmIChrZXljb2RlICE9IDB4NDUpCkBAIC02NjUsNyArODQzLDkgQEAKIAkJYnJlYWs7CiAJfQog Ci0JLyogWFhYIGFzc3VtZSAxMDEvMTAyIGtleXMgQVQga2V5Ym9hcmQgKi8KKwkvKgorCSAqIFhY WCBhc3N1bWUgMTAxLzEwMiBrZXlzIEFUIGtleWJvYXJkIAorCSAqLwogCXN3aXRjaCAoa2V5Y29k ZSkgewogCWNhc2UgMHg1YzoJLyogcHJpbnQgc2NyZWVuICovCiAJCWlmIChzdGF0ZS0+a3NfZmxh Z3MgJiBBTFRTKQpAQCAtNjc3LDE3ICs4NTcsMjUgQEAKIAkJYnJlYWs7CiAJfQogCi0JLyogcmV0 dXJuIHRoZSBrZXkgY29kZSBpbiB0aGUgS19DT0RFIG1vZGUgKi8KKwkvKgorCSAqIHJldHVybiB0 aGUga2V5IGNvZGUgaW4gdGhlIEtfQ09ERSBtb2RlIAorCSAqLwogCWlmIChzdGF0ZS0+a3NfbW9k ZSA9PSBLX0NPREUpIHsKIAkJS0JETVVYX1VOTE9DSyhzdGF0ZSk7CiAJCXJldHVybiAoa2V5Y29k ZSB8IChzY2FuY29kZSAmIDB4ODApKTsKIAl9CiAKLQkvKiBjb21wb3NlIGEgY2hhcmFjdGVyIGNv ZGUgKi8KKwkvKgorCSAqIGNvbXBvc2UgYSBjaGFyYWN0ZXIgY29kZSAKKwkgKi8KIAlpZiAoc3Rh dGUtPmtzX2ZsYWdzICYgQ09NUE9TRSkgewogCQlzd2l0Y2ggKGtleWNvZGUgfCAoc2NhbmNvZGUg JiAweDgwKSkgewotCQkvKiBrZXkgcHJlc3NlZCwgcHJvY2VzcyBpdCAqLwotCQljYXNlIDB4NDc6 IGNhc2UgMHg0ODogY2FzZSAweDQ5OgkvKiBrZXlwYWQgNyw4LDkgKi8KKwkJCS8qCisJCQkgKiBr ZXkgcHJlc3NlZCwgcHJvY2VzcyBpdCAKKwkJCSAqLworCQljYXNlIDB4NDc6CisJCWNhc2UgMHg0 ODoKKwkJY2FzZSAweDQ5OgkvKiBrZXlwYWQgNyw4LDkgKi8KIAkJCXN0YXRlLT5rc19jb21wb3Nl ZF9jaGFyICo9IDEwOwogCQkJc3RhdGUtPmtzX2NvbXBvc2VkX2NoYXIgKz0ga2V5Y29kZSAtIDB4 NDA7CiAJCQlpZiAoc3RhdGUtPmtzX2NvbXBvc2VkX2NoYXIgPiBVQ0hBUl9NQVgpIHsKQEAgLTY5 NSw3ICs4ODMsOSBAQAogCQkJCXJldHVybiAoRVJSS0VZKTsKIAkJCX0KIAkJCWdvdG8gbmV4dF9j b2RlOwotCQljYXNlIDB4NEI6IGNhc2UgMHg0QzogY2FzZSAweDREOgkvKiBrZXlwYWQgNCw1LDYg Ki8KKwkJY2FzZSAweDRCOgorCQljYXNlIDB4NEM6CisJCWNhc2UgMHg0RDoJLyoga2V5cGFkIDQs NSw2ICovCiAJCQlzdGF0ZS0+a3NfY29tcG9zZWRfY2hhciAqPSAxMDsKIAkJCXN0YXRlLT5rc19j b21wb3NlZF9jaGFyICs9IGtleWNvZGUgLSAweDQ3OwogCQkJaWYgKHN0YXRlLT5rc19jb21wb3Nl ZF9jaGFyID4gVUNIQVJfTUFYKSB7CkBAIC03MDMsNyArODkzLDkgQEAKIAkJCQlyZXR1cm4gKEVS UktFWSk7CiAJCQl9CiAJCQlnb3RvIG5leHRfY29kZTsKLQkJY2FzZSAweDRGOiBjYXNlIDB4NTA6 IGNhc2UgMHg1MToJLyoga2V5cGFkIDEsMiwzICovCisJCWNhc2UgMHg0RjoKKwkJY2FzZSAweDUw OgorCQljYXNlIDB4NTE6CS8qIGtleXBhZCAxLDIsMyAqLwogCQkJc3RhdGUtPmtzX2NvbXBvc2Vk X2NoYXIgKj0gMTA7CiAJCQlzdGF0ZS0+a3NfY29tcG9zZWRfY2hhciArPSBrZXljb2RlIC0gMHg0 RTsKIAkJCWlmIChzdGF0ZS0+a3NfY29tcG9zZWRfY2hhciA+IFVDSEFSX01BWCkgewpAQCAtNzE5 LDEwICs5MTEsMTggQEAKIAkJCX0KIAkJCWdvdG8gbmV4dF9jb2RlOwogCi0JCS8qIGtleSByZWxl YXNlZCwgbm8gaW50ZXJlc3QgaGVyZSAqLwotCQljYXNlIDB4Qzc6IGNhc2UgMHhDODogY2FzZSAw eEM5OgkvKiBrZXlwYWQgNyw4LDkgKi8KLQkJY2FzZSAweENCOiBjYXNlIDB4Q0M6IGNhc2UgMHhD RDoJLyoga2V5cGFkIDQsNSw2ICovCi0JCWNhc2UgMHhDRjogY2FzZSAweEQwOiBjYXNlIDB4RDE6 CS8qIGtleXBhZCAxLDIsMyAqLworCQkJLyoKKwkJCSAqIGtleSByZWxlYXNlZCwgbm8gaW50ZXJl c3QgaGVyZSAKKwkJCSAqLworCQljYXNlIDB4Qzc6CisJCWNhc2UgMHhDODoKKwkJY2FzZSAweEM5 OgkvKiBrZXlwYWQgNyw4LDkgKi8KKwkJY2FzZSAweENCOgorCQljYXNlIDB4Q0M6CisJCWNhc2Ug MHhDRDoJLyoga2V5cGFkIDQsNSw2ICovCisJCWNhc2UgMHhDRjoKKwkJY2FzZSAweEQwOgorCQlj YXNlIDB4RDE6CS8qIGtleXBhZCAxLDIsMyAqLwogCQljYXNlIDB4RDI6CQkJCS8qIGtleXBhZCAw ICovCiAJCQlnb3RvIG5leHRfY29kZTsKIApAQCAtNzQwLDcgKzk0MCw5IEBACiAJCX0KIAl9CiAK LQkvKiBrZXljb2RlIHRvIGtleSBhY3Rpb24gKi8KKwkvKgorCSAqIGtleWNvZGUgdG8ga2V5IGFj dGlvbiAKKwkgKi8KIAlhY3Rpb24gPSBnZW5rYmRfa2V5YWN0aW9uKGtiZCwga2V5Y29kZSwgc2Nh bmNvZGUgJiAweDgwLAogCQkJJnN0YXRlLT5rc19zdGF0ZSwgJnN0YXRlLT5rc19hY2NlbnRzKTsK IAlpZiAoYWN0aW9uID09IE5PS0VZKQpAQCAtNzUxLDEyICs5NTMsMTUgQEAKIAlyZXR1cm4gKGFj dGlvbik7CiB9CiAKLS8qIENoZWNrIGlmIGNoYXIgaXMgd2FpdGluZyAqLworLyoKKyAqIENoZWNr IGlmIGNoYXIgaXMgd2FpdGluZyAKKyAqLwogc3RhdGljIGludAoga2JkbXV4X2NoZWNrX2NoYXIo a2V5Ym9hcmRfdCAqa2JkKQogewogCWtiZG11eF9zdGF0ZV90CSpzdGF0ZSA9IChrYmRtdXhfc3Rh dGVfdCAqKSBrYmQtPmtiX2RhdGE7CiAJaW50CQkgcmVhZHk7CisJS0JETVVYX0xPQ0tfREVDTF9M T0NBTDsKIAogCWlmICghS0JEX0lTX0FDVElWRShrYmQpKQogCQlyZXR1cm4gKEZBTFNFKTsKQEAg LTc3MywxMyArOTc4LDE2IEBACiAJcmV0dXJuIChyZWFkeSk7CiB9CiAKLS8qIEtleWJvYXJkIGlv Y3RsJ3MgKi8KKy8qCisgKiBLZXlib2FyZCBpb2N0bCdzIAorICovCiBzdGF0aWMgaW50CiBrYmRt dXhfaW9jdGwoa2V5Ym9hcmRfdCAqa2JkLCB1X2xvbmcgY21kLCBjYWRkcl90IGFyZykKIHsKIAlr YmRtdXhfc3RhdGVfdAkqc3RhdGUgPSAoa2JkbXV4X3N0YXRlX3QgKikga2JkLT5rYl9kYXRhOwog CWtiZG11eF9rYmRfdAkqayA9IE5VTEw7CiAJaW50CQkgZXJyb3IgPSAwLCBtb2RlOworCUtCRE1V WF9MT0NLX0RFQ0xfTE9DQUw7CiAKIAlpZiAoc3RhdGUgPT0gTlVMTCkKIAkJcmV0dXJuIChFTlhJ Tyk7CkBAIC03ODgsOCArOTk2LDggQEAKIAljYXNlIEtCRE1VWF9BRERLQkQ6IC8qIGFkZCBrZXli b2FyZCB0byB0aGUgbXV4ICovCiAJCUtCRE1VWF9MT0NLKHN0YXRlKTsKIAotCQlTTElTVF9GT1JF QUNIKGssICZzdGF0ZS0+a3Nfa2JkcywgbmV4dCkKLQkJCWlmIChrLT5pZHggPT0gKigoaW50ICop IGFyZykpCisJCVNMSVNUX0ZPUkVBQ0goaywgJnN0YXRlLT5rc19rYmRzLAorCQkJICAgICAgbmV4 dCkgaWYgKGstPmlkeCA9PSAqKChpbnQgKilhcmcpKQogCQkJCWJyZWFrOwogCiAJCWlmIChrICE9 IE5VTEwpIHsKQEAgLTg0NywxNCArMTA1NSwxNSBAQAogCWNhc2UgS0JETVVYX1JFTEtCRDogLyog cmVsZWFzZSBrZXlib2FyZCBmcm9tIHRoZSBtdXggKi8KIAkJS0JETVVYX0xPQ0soc3RhdGUpOwog Ci0JCVNMSVNUX0ZPUkVBQ0goaywgJnN0YXRlLT5rc19rYmRzLCBuZXh0KQotCQkJaWYgKGstPmlk eCA9PSAqKChpbnQgKikgYXJnKSkKKwkJU0xJU1RfRk9SRUFDSChrLCAmc3RhdGUtPmtzX2tiZHMs CisJCQkgICAgICBuZXh0KSBpZiAoay0+aWR4ID09ICooKGludCAqKWFyZykpCiAJCQkJYnJlYWs7 CiAKIAkJaWYgKGsgIT0gTlVMTCkgewogCQkJZXJyb3IgPSBrYmRfcmVsZWFzZShrLT5rYmQsICZr LT5rYmQpOwogCQkJaWYgKGVycm9yID09IDApIHsKLQkJCQlTTElTVF9SRU1PVkUoJnN0YXRlLT5r c19rYmRzLCBrLCBrYmRtdXhfa2JkLCBuZXh0KTsKKwkJCQlTTElTVF9SRU1PVkUoJnN0YXRlLT5r c19rYmRzLCBrLCBrYmRtdXhfa2JkLAorCQkJCQkgICAgIG5leHQpOwogCiAJCQkJay0+a2JkID0g TlVMTDsKIAkJCQlrLT5pZHggPSAtMTsKQEAgLTg3OSwxMSArMTA4OCwxNSBAQAogCQlzd2l0Y2gg KCooKGludCAqKSBhcmcpKSB7CiAJCWNhc2UgS19YTEFURToKIAkJCWlmIChzdGF0ZS0+a3NfbW9k ZSAhPSBLX1hMQVRFKSB7Ci0JCQkJLyogbWFrZSBsb2NrIGtleSBzdGF0ZSBhbmQgTEVEIHN0YXRl IG1hdGNoICovCisJCQkJLyoKKwkJCQkgKiBtYWtlIGxvY2sga2V5IHN0YXRlIGFuZCBMRUQgc3Rh dGUgbWF0Y2ggCisJCQkJICovCiAJCQkJc3RhdGUtPmtzX3N0YXRlICY9IH5MT0NLX01BU0s7CiAJ CQkJc3RhdGUtPmtzX3N0YXRlIHw9IEtCRF9MRURfVkFMKGtiZCk7CiAgICAgICAgICAgICAgICAg ICAgICAgICB9Ci0gICAgICAgICAgICAgICAgICAgICAgICAvKiBGQUxMVEhST1VHSCAqLworCQkJ LyoKKwkJCSAqIEZBTExUSFJPVUdIIAorCQkJICovCiAKIAkJY2FzZSBLX1JBVzoKIAkJY2FzZSBL X0NPREU6CkBAIC05MTAsNyArMTEyMyw5IEBACiAJY2FzZSBLRFNFVExFRDogLyogc2V0IGtleWJv YXJkIExFRCAqLwogCQlLQkRNVVhfTE9DSyhzdGF0ZSk7CiAKLQkJLyogTk9URTogbG9jayBrZXkg c3RhdGUgaW4ga3Nfc3RhdGUgd29uJ3QgYmUgY2hhbmdlZCAqLworCQkvKgorCQkgKiBOT1RFOiBs b2NrIGtleSBzdGF0ZSBpbiBrc19zdGF0ZSB3b24ndCBiZSBjaGFuZ2VkIAorCQkgKi8KIAkJaWYg KCooKGludCAqKSBhcmcpICYgfkxPQ0tfTUFTSykgewogCQkJS0JETVVYX1VOTE9DSyhzdGF0ZSk7 CiAKQEAgLTk0Myw3ICsxMTU4LDkgQEAKIAkJS0JETVVYX1VOTE9DSyhzdGF0ZSk7CiAKIAkJcmV0 dXJuIChrYmRtdXhfaW9jdGwoa2JkLCBLRFNFVExFRCwgYXJnKSk7Ci0JCS8qIE5PVCBSRUFDSEVE ICovCisJCS8qCisJCSAqIE5PVCBSRUFDSEVEIAorCQkgKi8KIAogCWNhc2UgS0RTRVRSRVBFQVQ6 IC8qIHNldCBrZXlib2FyZCByZXBlYXQgcmF0ZSAobmV3IGludGVyZmFjZSkgKi8KIAkJYnJlYWs7 CkBAIC05NTcsNyArMTE3NCw5IEBACiAJCUtCRE1VWF9MT0NLKHN0YXRlKTsKICAgICAgICAgICAg ICAgICBzdGF0ZS0+a3NfYWNjZW50cyA9IDA7CiAJCUtCRE1VWF9VTkxPQ0soc3RhdGUpOwotICAg ICAgICAgICAgICAgIC8qIEZBTExUSFJPVUdIICovCisJCS8qCisJCSAqIEZBTExUSFJPVUdIIAor CQkgKi8KIAogCWRlZmF1bHQ6CiAJCWVycm9yID0gZ2Vua2JkX2NvbW1vbmlvY3RsKGtiZCwgY21k LCBhcmcpOwpAQCAtOTY3LDE0ICsxMTg2LDE4IEBACiAJcmV0dXJuIChlcnJvcik7CiB9CiAKLS8q IExvY2sgdGhlIGFjY2VzcyB0byB0aGUga2V5Ym9hcmQgKi8KKy8qCisgKiBMb2NrIHRoZSBhY2Nl c3MgdG8gdGhlIGtleWJvYXJkIAorICovCiBzdGF0aWMgaW50CiBrYmRtdXhfbG9jayhrZXlib2Fy ZF90ICprYmQsIGludCBsb2NrKQogewogCXJldHVybiAoMSk7IC8qIFhYWCAqLwogfQogCi0vKiBD bGVhciB0aGUgaW50ZXJuYWwgc3RhdGUgb2YgdGhlIGtleWJvYXJkICovCisvKgorICogQ2xlYXIg dGhlIGludGVybmFsIHN0YXRlIG9mIHRoZSBrZXlib2FyZCAKKyAqLwogc3RhdGljIHZvaWQKIGti ZG11eF9jbGVhcl9zdGF0ZV9sb2NrZWQoa2JkbXV4X3N0YXRlX3QgKnN0YXRlKQogewpAQCAtOTg0 LDcgKzEyMDcsOSBAQAogCXN0YXRlLT5rc19zdGF0ZSAmPSBMT0NLX01BU0s7CS8qIHByZXNlcnZl IGxvY2tpbmcga2V5IHN0YXRlICovCiAJc3RhdGUtPmtzX2FjY2VudHMgPSAwOwogCXN0YXRlLT5r c19jb21wb3NlZF9jaGFyID0gMDsKLS8qCXN0YXRlLT5rc19wcmVmaXggPSAwOwkJWFhYICovCisJ LyoKKwkgKiBzdGF0ZS0+a3NfcHJlZml4ID0gMDsgWFhYIAorCSAqLwogCiAJbmRmbHVzaCgmc3Rh dGUtPmtzX2lucSwgc3RhdGUtPmtzX2lucS5jX2NjKTsKIH0KQEAgLTk5MywxMyArMTIxOCwxNiBA QAoga2JkbXV4X2NsZWFyX3N0YXRlKGtleWJvYXJkX3QgKmtiZCkKIHsKIAlrYmRtdXhfc3RhdGVf dAkqc3RhdGUgPSAoa2JkbXV4X3N0YXRlX3QgKikga2JkLT5rYl9kYXRhOworCUtCRE1VWF9MT0NL X0RFQ0xfTE9DQUw7CiAKIAlLQkRNVVhfTE9DSyhzdGF0ZSk7CiAJa2JkbXV4X2NsZWFyX3N0YXRl X2xvY2tlZChzdGF0ZSk7CiAJS0JETVVYX1VOTE9DSyhzdGF0ZSk7CiB9CiAKLS8qIFNhdmUgdGhl IGludGVybmFsIHN0YXRlICovCisvKgorICogU2F2ZSB0aGUgaW50ZXJuYWwgc3RhdGUgCisgKi8K IHN0YXRpYyBpbnQKIGtiZG11eF9nZXRfc3RhdGUoa2V5Ym9hcmRfdCAqa2JkLCB2b2lkICpidWYs IHNpemVfdCBsZW4pCiB7CkBAIC0xMDA4LDI4ICsxMjM2LDM1IEBACiAJaWYgKGxlbiA8IHNpemVv ZihrYmRtdXhfc3RhdGVfdCkpCiAJCXJldHVybiAoLTEpOwogCi0JYmNvcHkoa2JkLT5rYl9kYXRh LCBidWYsIHNpemVvZihrYmRtdXhfc3RhdGVfdCkpOyAvKiBYWFggbG9ja2luZz8gKi8KKwliY29w eShrYmQtPmtiX2RhdGEsIGJ1Ziwgc2l6ZW9mKGtiZG11eF9zdGF0ZV90KSk7CS8qIFhYWAorCQkJ CQkJCQkgKiBsb2NraW5nPyAqLwogCiAJcmV0dXJuICgwKTsKIH0KIAotLyogU2V0IHRoZSBpbnRl cm5hbCBzdGF0ZSAqLworLyoKKyAqIFNldCB0aGUgaW50ZXJuYWwgc3RhdGUgCisgKi8KIHN0YXRp YyBpbnQKIGtiZG11eF9zZXRfc3RhdGUoa2V5Ym9hcmRfdCAqa2JkLCB2b2lkICpidWYsIHNpemVf dCBsZW4pCiB7CiAJaWYgKGxlbiA8IHNpemVvZihrYmRtdXhfc3RhdGVfdCkpCiAJCXJldHVybiAo RU5PTUVNKTsKIAotCWJjb3B5KGJ1Ziwga2JkLT5rYl9kYXRhLCBzaXplb2Yoa2JkbXV4X3N0YXRl X3QpKTsgLyogWFhYIGxvY2tpbmc/ICovCisJYmNvcHkoYnVmLCBrYmQtPmtiX2RhdGEsIHNpemVv ZihrYmRtdXhfc3RhdGVfdCkpOwkvKiBYWFgKKwkJCQkJCQkJICogbG9ja2luZz8gKi8KIAogCXJl dHVybiAoMCk7CiB9CiAKLS8qIFNldCBwb2xsaW5nICovCisvKgorICogU2V0IHBvbGxpbmcgCisg Ki8KIHN0YXRpYyBpbnQKIGtiZG11eF9wb2xsKGtleWJvYXJkX3QgKmtiZCwgaW50IG9uKQogewog CWtiZG11eF9zdGF0ZV90CSpzdGF0ZSA9IE5VTEw7CisJS0JETVVYX0xPQ0tfREVDTF9MT0NBTDsK IAogCXN0YXRlID0gKGtiZG11eF9zdGF0ZV90ICopIGtiZC0+a2JfZGF0YTsKIApAQCAtMTEwMiwx MiArMTMzNywxNCBAQAogCQlicmVhazsKIAogCWNhc2UgTU9EX1VOTE9BRDoKLQkJaWYgKChzdyA9 IGtiZF9nZXRfc3dpdGNoKEtFWUJPQVJEX05BTUUpKSA9PSBOVUxMKQotCQkJcGFuaWMoImtiZF9n ZXRfc3dpdGNoKCIgS0VZQk9BUkRfTkFNRSAiKSA9PSBOVUxMIik7CisJCXN3ID0ga2JkX2dldF9z d2l0Y2goS0VZQk9BUkRfTkFNRSk7CisJCUFTU0VSVChzdyAhPSBOVUxMLAorCQkgICAgICAgImti ZF9nZXRfc3dpdGNoKCIgS0VZQk9BUkRfTkFNRSAiKSA9PSBOVUxMIik7CiAKIAkJa2JkID0ga2Jk X2dldF9rZXlib2FyZChrYmRfZmluZF9rZXlib2FyZChLRVlCT0FSRF9OQU1FLCAwKSk7Ci0JCWlm IChrYmQgPT0gTlVMTCkKLQkJCSBwYW5pYygia2JkX2dldF9rZXlib2FyZChrYmRfZmluZF9rZXli b2FyZCgiIEtFWUJPQVJEX05BTUUgIiwgMCkpID09IE5VTEwiKTsKKwkJQVNTRVJUKGtiZCAhPSBO VUxMLAorCQkgICAgICAgImtiZF9nZXRfa2V5Ym9hcmQoa2JkX2ZpbmRfa2V5Ym9hcmQoIiBLRVlC T0FSRF9OQU1FCisJCSAgICAgICAiLCAwKSkgPT0gTlVMTCIpOwogCiAJCSgqc3ctPmRpc2FibGUp KGtiZCk7CiAJCWtiZF9kZXRhY2goa2JkKTsKQEAgLTExMjUsNCArMTM2MiwzIEBACiB9CiAKIERF Vl9NT0RVTEUoa2JkbXV4LCBrYmRtdXhfbW9kZXZlbnQsIE5VTEwpOwotCg== ------=_NextPart_000_0001_01C57009.C3632B40 Content-Type: application/octet-stream; name="dev_debug.h" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dev_debug.h" LyoKICogJEhlYWRlcjogL3Vzci9sb2NhbC9jdnMvZGV2X2RlYnVnL2Rldl9kZWJ1Zy5oLHYgMS42 IDIwMDUvMDUvMzEgMTQ6Mjk6MjIgbmsgRXhwICQKICoKICogICAgQ09QWVJJR0hUKGMpIDIwMDMs MjAwNCwyMDA1IGJ5IGRlbWlnIFByb3plc3NhdXRvbWF0aXNpZXJ1bmcgR21iSCAKICogICAgICB8 XCAgL3wgIEhhYXJkdHN0cmFzc2UgNDAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CiAqICAgICAgfF9cLyB8ICBELTU3MDc2IFNpZWdlbiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogKiAgICAgIHwgL1wgfCAgR2VybWFueSAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICogICAgICB8LyAgXHwgIGh0dHA6Ly93d3cuZGVtaWcuZGUg IGluZm9AZGVtaWcuZGUgICAgICAgICAgICAgICAgCiAqLwoKCiNpZm5kZWYgREVWX0RFQlVHX0gK I2RlZmluZSBERVZfREVCVUdfSAoKCiNpZm5kZWYgREVCVUcKI2Vycm9yICAiREVCVUcgbm90IGRl ZmluZWQiCiNlbmRpZgojaWZuZGVmIFZFUkJPU0UKI2Vycm9yICAiVkVSQk9TRSBub3QgZGVmaW5l ZCIKI2VuZGlmCiNpZm5kZWYgREVCVUdfVVNFU1lTTE9HCiNlcnJvciAgIkRFQlVHX1VTRVNZU0xP RyBub3QgZGVmaW5lZCIKI2VuZGlmCiNpZm5kZWYgREVCVUdfVEFHCiNlcnJvciAgIkRFQlVHX1RB RyBub3QgZGVmaW5lZCIKI2VuZGlmCgoKI2RlZmluZSBDQVQoeCx5KSAgICAgICAgeCMjeQojZGVm aW5lIFhDQVQoeCx5KSAgICAgICBDQVQgKHgseSkKI2RlZmluZSBTVFIoeCkgICN4CiNkZWZpbmUg WFNUUih4KSBTVFIgKHgpCgoKI2lmIERFQlVHCiNkZWZpbmUgSU5MSU5FCiNlbHNlCiNkZWZpbmUg SU5MSU5FICBfX2lubGluZQojZW5kaWYKCgojaWYgREVCVUdfVVNFU1lTTE9HCgojaW5jbHVkZSA8 c3lzL3N5c2xvZy5oPgojZGVmaW5lIExPRyh0eHQsIGFyZ3MuLi4pICAgICAgIGxvZyAoTE9HX0RF QlVHLCB0eHQsICMjIGFyZ3MpCgojZWxzZQoKI2RlZmluZSBMT0codHh0LCBhcmdzLi4uKSAgICAg ICBwcmludGYgKHR4dCwgIyMgYXJncykKCiNlbmRpZgoKCiNpZiBkZWZpbmVkIChOREVCVUcpCiNk ZWZpbmUgREVCVUdQUklOVEYwKGV4cHIsIGZ1bmMsIHR4dCwgYXJncy4uLikgICAgICAgICAgXAog IGRvICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwK ICB7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBc CiAgICBpZiAoZXhwcikgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg XAogICAgeyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFwKICAgICAgZnVuYyAoWFNUUiAoREVCVUdfVEFHKSAiOiAiIHR4dCwgIyMgYXJncyk7ICAgICAg ICBcCiAgICB9ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgXAogIH0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFwKICB3aGlsZSAoRkFMU0UpCiNlbHNlCiNkZWZpbmUgREVCVUdQUklOVEYwKGV4cHIsIGZ1 bmMsIHR4dCwgYXJncy4uLikgICAgICAgICAgXAogIGRvICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICB7ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgICBpZiAoZXhwcikgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgeyAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAgICAgZnVuYyAoWFNUUiAoX19GSUxF X18pIiwgIiBYU1RSIChfX0xJTkVfXykgIjogIiAgICBcCiAgICAgICAgICAgIHR4dCwgIyMgYXJn cyk7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAogICAgfSAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICB9ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBcCiAgd2hpbGUgKEZBTFNFKQojZW5k aWYKCgojaWYgZGVmaW5lZCAoTkRFQlVHKQojZGVmaW5lIEFTU0VSVChleHByLCB0eHQsIGFyZ3Mu Li4pCiNlbHNlCiNkZWZpbmUgQVNTRVJUKGV4cHIsIHR4dCwgYXJncy4uLikgXAogIERFQlVHUFJJ TlRGMCAoISAoZXhwciksIHBhbmljLCB0eHQsICMjIGFyZ3MpCiNlbmRpZgoKCiNpZiBWRVJCT1NF CiNkZWZpbmUgdnByaW50Zih0eHQsIGFyZ3MuLi4pIFwKICBERUJVR1BSSU5URjAgKFRSVUUsIHBy aW50ZiwgdHh0LCAjIyBhcmdzKQojZWxzZQojZGVmaW5lIHZwcmludGYodHh0LCBhcmdzLi4uKQoj ZW5kaWYKCgojZGVmaW5lIERFQlVHUFJJTlRGKGx2bCwgY21wLCB0eHQsIGFyZ3MuLi4pICAgICAg IFwKICBERUJVR1BSSU5URjAgKGNtcCA+PSBsdmwsIExPRywgdHh0LCAjIyBhcmdzKQoKCiNkZWZp bmUgREVCVUdfVkFSX1NDT1BFICAgICAgICAgc3RhdGljCiNkZWZpbmUgREVCVUdfVkFSX1RZUEUg ICAgICAgICAgaW50CiNkZWZpbmUgREVCVUdfVkFSX1NZU0NUTCAgICAgICAgU1lTQ1RMX1VJTlQK I2RlZmluZSBERUJVR19WQVJfTkFNRSh0YWcpICAgICBYQ0FUICh0YWcsIF9kZWJ1ZykKCgojaWYg REVCVUcKCiNpZiBkZWZpbmVkIChOREVCVUcpCiNkZWZpbmUgREVCVUdfVkFSX0RFQ0wodGFnLCBs dmwpICAgICAgICAgICAgICAgIFwKREVCVUdfVkFSX1NDT1BFIERFQlVHX1ZBUl9UWVBFIERFQlVH X1ZBUl9OQU1FICh0YWcpID0gMAojZWxzZQojZGVmaW5lIERFQlVHX1ZBUl9ERUNMKHRhZywgbHZs KSAgICAgICAgICAgICAgICBcCkRFQlVHX1ZBUl9TQ09QRSBERUJVR19WQVJfVFlQRSBERUJVR19W QVJfTkFNRSAodGFnKSA9IGx2bAojZW5kaWYKCiNkZWZpbmUgRFBSSU5URih0YWcsIGx2bCwgdHh0 LCBhcmdzLi4uKSAgICAgICAgIFwKICBERUJVR1BSSU5URiAobHZsLCBERUJVR19WQVJfTkFNRSAo dGFnKSwgdHh0LCAjIyBhcmdzKQoKI2luY2x1ZGUgPHN5cy9zeXNjdGwuaD4KCiNkZWZpbmUgREVC VUdfU1lTQ1RMKHRhZykgICAgICAgICAgICAgICAgICAgICAgIFwKREVCVUdfVkFSX1NZU0NUTCAo X2RlYnVnLCAgICAgICAgICAgICAgICAgICAgICAgXAogICAgICAgICAgICAgICAgICBPSURfQVVU TywgICAgICAgICAgICAgICAgICAgICBcCiAgICAgICAgICAgICAgICAgIFhDQVQgKHRhZywgX2Rl YnVnKSwgICAgICAgICAgIFwKICAgICAgICAgICAgICAgICAgQ1RMRkxBR19SVywgICAgICAgICAg ICAgICAgICAgXAogICAgICAgICAgICAgICAgICAmIERFQlVHX1ZBUl9OQU1FICh0YWcpLCAgICAg ICBcCiAgICAgICAgICAgICAgICAgIDAsICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwKICAg ICAgICAgICAgICAgICAgWENBVCAoWFNUUiAodGFnKSwgIiBkZWJ1ZyIpKQoKCiNlbHNlCgojZGVm aW5lIERFQlVHX1ZBUl9ERUNMKHRhZywgbHZsKQojZGVmaW5lIERFQlVHX1NZU0NUTCh0YWcpCiNk ZWZpbmUgRFBSSU5URih0YWcsIGx2bCwgdHh0LCBhcmdzLi4uKQoKI2VuZGlmCgoKI2RlZmluZSBk ZWJ1Z192YXJfZGVjbChsdmwpICAgICBERUJVR19WQVJfREVDTCAoREVCVUdfVEFHLCBsdmwpCiNk ZWZpbmUgZGVidWdfc3lzY3RsKCkgICAgICAgICAgREVCVUdfU1lTQ1RMIChERUJVR19UQUcpCiNk ZWZpbmUgZHByaW50ZihsdmwsIHR4dCwgYXJncy4uLikgICAgICAgICAgICAgIFwKICBEUFJJTlRG IChERUJVR19UQUcsIGx2bCwgdHh0LCAjIyBhcmdzKQoKCiNlbmRpZgo= ------=_NextPart_000_0001_01C57009.C3632B40-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 10:56:30 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9315A16A41C for ; Mon, 13 Jun 2005 10:56:30 +0000 (GMT) (envelope-from apachexm@hotmail.com) Received: from hotmail.com (bay19-f33.bay19.hotmail.com [64.4.53.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6894843D49 for ; Mon, 13 Jun 2005 10:56:30 +0000 (GMT) (envelope-from apachexm@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 13 Jun 2005 03:56:30 -0700 Message-ID: Received: from 220.168.71.88 by by19fd.bay19.hotmail.msn.com with HTTP; Mon, 13 Jun 2005 10:56:29 GMT X-Originating-IP: [220.168.71.88] X-Originating-Email: [apachexm@hotmail.com] X-Sender: apachexm@hotmail.com From: "Apache Xie" To: freebsd-hackers@freebsd.org Date: Mon, 13 Jun 2005 10:56:29 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 13 Jun 2005 10:56:30.0166 (UTC) FILETIME=[8DD61760:01C57006] Subject: contigmalloc() and mmap() 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, 13 Jun 2005 10:56:30 -0000 I have some experiences in writing Linux device driver, but I am new to FreeBSD kernel, although from the first glimpse, there seems no big differences between the kernel operations a char device driver can use, but I met some problems when the driver is running in FreeBSD. Our device is an experimental communication card, which can do remote DMA between two cards, which means the card in one node can DMA memory data to network, and when data are transfered to the card on another node, it will be DMAed to memory too. Because the card can only use contiguous physical memory for DMA operations, so data in user process will be copied to an contiguous memory buffer, then DMA will tranfer data in this buffer, and this buffer is allocated by driver using __get_free_pages() in Linux. The buffer is mmaped to user process space, so user process can do the copy directly in user space, it can directly orgnize data in this mmaped memory too. When I am porting my driver to FreeBSD, I use /dev/bktr driver as the example, seems easily, just using contigmalloc() to allocate the buffer, and in driver's _mmap() function, return the physical address for each page to be mmaped. The problem is, in Linux, I allocate buffer in driver's ioctl() function, and free it in a timer function, many processes may use the driver at the same time, each process use a different kernel buffer, when the process first use the driver, it calls __get_free_pages() to allocate kernel buffer, and when it exit, it trigger timer function, the timer function will can free_pages() to free the buffer, so these two kernel interfaces will be called frequently, but this usage pattern works correctly in Linux. In FreeBSD, the driver works in the same pattern, but when a user process mmap driver's buffer (allocated by contigmalloc()) and is killed, then when another process mmap the same buffer again, sometimes it cannot get correct data from the mmaped pages, which means the user space virtual aderess may not point to the correct physical page of driver's buffer, sometimes the OS even panic with some information such as "Trap 12, Page not present" etc. I browsed kernel tree, I found those drivers which use contigmalloc() and contigfree() always call these two kernel interfaces in _attach() and _detach(), but in my driver, I call contigmalloc() in ioctl(), and call contigfree() in a callout function which is set by callout_reset(). What I want to know is if contigmalloc() and contigfree() can only be used under some conditions? And recently, I modified my driver, I allocated a big chunk of contiguous physical memory using contigmalloc() in the driver's _attach() function, and I use a simple first-fit algorithm to manage this memory myself, which mean in ioctl() I use my allocate/deallocate functions instead of contigmalloc(), in _detach() function contigfree() is called to free the big chunk of memory, no panic again, but sometimes, process cannot get the correct data from the mmaped memory. I don't know why. Any help is welcomed. Thanks. _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 11:19:17 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E3DB16A41C for ; Mon, 13 Jun 2005 11:19:17 +0000 (GMT) (envelope-from ray@redshift.com) Received: from outgoing.redshift.com (outgoing.redshift.com [207.177.231.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A64043D48 for ; Mon, 13 Jun 2005 11:19:17 +0000 (GMT) (envelope-from ray@redshift.com) Received: from workstation (216-228-19-21.dsl.redshift.com [216.228.19.21]) by outgoing.redshift.com (Postfix) with SMTP id E9AB497521; Mon, 13 Jun 2005 04:19:07 -0700 (PDT) Message-Id: <3.0.1.32.20050613041913.00a64470@pop.redshift.com> X-Mailer: na X-Sender: redshift.com Date: Mon, 13 Jun 2005 04:19:13 -0700 To: "Julian H. Stacey" From: ray@redshift.com In-Reply-To: <200506130942.j5D9g4SN006890@fire.jhs.private> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD 5.3/4 vs 4.11 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, 13 Jun 2005 11:19:17 -0000 yeah, thanks. I'm subscribed to performance also - it's kinda dead over there. I'll check the archives also, thanks. Ray At 11:42 AM 6/13/2005 +0200, Julian H. Stacey wrote: | ray@redshift.com wrote: | > Hello list, | > | > I've recently been doing quite a few benchmarks with regard to PHP and Apache, | > as well as stripping down the Kernel on 5.3 and 5.4 to improve performance for | > web/application servers. | > | > My question is: I was wondering if anyone out there has ever done a head to head | > test of 4.11 to 5.3 (or 5.4) and if so, is 4.11 faster in any areas and/or does | > it provide any benefits over 5.3+? | | There was a discussion of performance just recently on one if the | main lists (ie current or hackers or stable, can't remember) However | you'll find it by browsing the the mail archives via | http://www.freebsd.org. | | FreeBSD has a mail list dedicated to discussing performance issues. | I suggest you subscribe it, after first browsing those archives: | http://lists.freebsd.org/pipermail/freebsd-performance/ | | - | Julian Stacey Net & Sys Eng Consultant, Munich http://berklix.com | Mail in Ascii (Html=Spam). Ihr Rauch = mein allergischer Kopfschmerz. | | From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 12 20:01:02 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E429716A420; Sun, 12 Jun 2005 20:01:01 +0000 (GMT) (envelope-from creep@daedalus.desk.pl) Received: from daedalus.desk.pl (daedalus.desk.pl [62.233.238.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id D258143D48; Sun, 12 Jun 2005 20:01:00 +0000 (GMT) (envelope-from creep@daedalus.desk.pl) Received: from localhost (localhost [127.0.0.1]) by daedalus.desk.pl (Postfix) with ESMTP id C1F83366CFB; Sun, 12 Jun 2005 21:54:27 +0200 (CEST) Received: from daedalus.desk.pl ([127.0.0.1]) by localhost (daedalus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09871-01; Sun, 12 Jun 2005 21:54:26 +0200 (CEST) Received: by daedalus.desk.pl (Postfix, from userid 1023) id 71DF5366658; Sun, 12 Jun 2005 21:54:26 +0200 (CEST) Date: Sun, 12 Jun 2005 21:54:26 +0200 From: Marcin Koziej To: freebsd-hackers@freebsd.org, brooks@FreeBSD.org Message-ID: <20050612195426.GA5248@daedalus.desk.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Antivirus: Skaner Antywirusowy DESK.pl X-Mailman-Approved-At: Mon, 13 Jun 2005 11:52:14 +0000 Cc: Subject: Tracking FreeBSD performance over time - what hackers want? 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, 12 Jun 2005 20:01:02 -0000 Hello Hackers! I have an idea which could be used to track FreeBSD performance and regression testing. Please take a look and give Your opinion on how usefull that would be for the FreeBSD project. The basis for this system would be hijacking certain functions execution with injected code. Hijacker program runs target binary with LD_PRELOAD to inject some code (code doing statistics, tests, etc..) and installs redirections using ptrace (injecting jump instructions here and there). It then deattaches and the program runs almost as normal. (A little demo of how this might look later). This approach has its pros and cons: + no context switch to fire hijacking code + flexible - You can hijack any function that has a symbol. Hijacking PLT (done) and relocations in shared libraries (will be done) included. + transparent - there needs to be no modiffication in target binary; hackers don't own all the hardware. It's hard to ask people with interesting equipement to recompile their binaries with profiling options. This would allow them to measure performance without changing their system. + small performance impact - put code only in places You want, and put there only the code which is needed there. (can be made O(1) unless You make it worse) - ABI / Architecture dependent - needs all the shared library mechanism to inject code (LD_PRELOAD) - needs symbols - writes the ro code pages on installing the redirections (negligible?) And here is the demo of poc code (not particulary usefull..but..) This hijack code has a static table indexed by read sizes in which we count how many times a read of this size was called. ------------------------------------ #include #include #define PROBES 400 #define QUANT 0x10 static int stats[PROBES]; static int max_read; // RV(type) gives return value of the code HIJACK(int, read, (int fd, char *buf, size_t size), /* before call*/ , /* after call*/ printf("read() = %d\n", RV(int)); if (max_read < RV(int)) max_read = RV(int); if ((RV(int) >=0) && (RV(int) < QUANT * PROBES)) { stats[RV(int) / QUANT]++; } ) HIJACK(int, main, (), printf("hello hijacking!\n"); , ) HIJACK(int, exit, (), int i; for (i=0; i X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 205E516A41C for ; Mon, 13 Jun 2005 11:58:20 +0000 (GMT) (envelope-from BORJAMAR@SARENET.ES) Received: from sollube.sarenet.es (sollube.sarenet.es [192.148.167.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id C85A143D1F for ; Mon, 13 Jun 2005 11:58:19 +0000 (GMT) (envelope-from BORJAMAR@SARENET.ES) Received: from [127.0.0.1] (unknown [192.148.167.21]) by sollube.sarenet.es (Postfix) with ESMTP id 3CA9A1A0D; Mon, 13 Jun 2005 13:58:18 +0200 (CEST) In-Reply-To: <20050612195426.GA5248@daedalus.desk.pl> References: <20050612195426.GA5248@daedalus.desk.pl> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8C00D100-950A-4868-A177-19E5A5E86507@SARENET.ES> Content-Transfer-Encoding: 7bit From: Borja Marcos Date: Mon, 13 Jun 2005 13:58:50 +0200 To: Marcin Koziej X-Mailer: Apple Mail (2.730) Cc: freebsd-hackers@freebsd.org Subject: Re: Tracking FreeBSD performance over time - what hackers want? 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, 13 Jun 2005 11:58:20 -0000 > So, again, please send Your opinions on this idea. Do You think > this (+ all needed utilities to do statistics etc) would be > applicable to Summer Of Code "Tracking performance over time" project? A very good (and simple) way to track and plot peformance over time is Orca. You only need to generate simple text files with the data, and Orca creates {beauti,use}ful graphs. Moreover, you can generate the graphs and keep the rrd files from a different machine. http://www.orcaware.com I know, I know, I'm being slow with devilator :/ (I'm working on a data collector for FreeBSD), but I'm stuck in an urgent project right now :( Borja. From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 12:11:48 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E33CA16A41C for ; Mon, 13 Jun 2005 12:11:48 +0000 (GMT) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.swip.net [212.247.154.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7296343D1D for ; Mon, 13 Jun 2005 12:11:47 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: Y1QAsIk9O44SO+J/q9KNyQ== Received: from mp-217-230-219.daxnet.no ([193.217.230.219] verified) by mailfe05.swip.net (CommuniGate Pro SMTP 4.3.2) with ESMTP id 197082139 for freebsd-hackers@freebsd.org; Mon, 13 Jun 2005 14:11:46 +0200 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Mon, 13 Jun 2005 14:12:38 +0200 User-Agent: KMail/1.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506131412.38967.hselasky@c2i.net> Subject: Obvious bug in /sys/i386/include/bus.h (was: bus_at386.h) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hselasky@c2i.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2005 12:11:49 -0000 Hi, I stumbled across this bug a year ago, but still none has managed to fix it. Instead the PR got lost and I am now posting it a second time: http://www.freebsd.org/cgi/query-pr.cgi?pr=80980 In FreeBSD 6-current the code for "bus_space_write_multi_1()" says: __asm __volatile(" \n\ cld \n\ 1: lodsb \n\ movb %%al,(%2) \n\ loop 1b" : "=S" (addr), "=c" (count) : "r" (bsh + offset), "0" (addr), "1" (count) : "%eax", "memory", "cc"); This is equivalent to: while(--count) { /* I/O */ } which is obviously wrong, because it doesn't check for count equal to zero. So how can I fix this in assembly. I am not an expert with inlined assembly, so maybe someone can correct me if I am wrong, but something like this needs to be added: or %ecx, %ecx jz 2 2: Another solution would be to wrap the inlined assembly into if(count) { ... } So can someone have this fixed, or is there a reason not to fix it. The one who wrote the code has done the same mistake with every one of the bus_space_XXXX that does memory mapped I/O. It currently breaks my drivers. --HPS From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 12:26:18 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C629416A41C for ; Mon, 13 Jun 2005 12:26:18 +0000 (GMT) (envelope-from gerarra@tin.it) Received: from vsmtp2.tin.it (vsmtp2.tin.it [212.216.176.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7731C43D1D for ; Mon, 13 Jun 2005 12:26:18 +0000 (GMT) (envelope-from gerarra@tin.it) Received: from ims3a.cp.tin.it (192.168.70.103) by vsmtp2.tin.it (7.0.027) id 42ABD4F2000771E1; Mon, 13 Jun 2005 14:26:16 +0200 Received: from [192.168.70.226] by ims3a.cp.tin.it with HTTP; Mon, 13 Jun 2005 14:26:14 +0200 Date: Mon, 13 Jun 2005 14:26:14 +0200 Message-ID: <429C8E8F00015E63@ims3a.cp.tin.it> In-Reply-To: <200506131412.38967.hselasky@c2i.net> From: gerarra@tin.it To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable X-Originating-IP: 151.100.38.110 Cc: hselasky@c2i.net Subject: RE: Obvious bug in /sys/i386/include/bus.h (was: bus_at386.h) 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, 13 Jun 2005 12:26:18 -0000 >http://www.freebsd.org/cgi/query-pr.cgi?pr=3D80980 > >In FreeBSD 6-current the code for "bus_space_write_multi_1()" says: > > __asm __volatile(" \n\ > cld \n\ > 1: lodsb \n\ > movb %%al,(%2) \n\ > loop 1b" : > "=3DS" (addr), "=3Dc" (count) : > "r" (bsh + offset), "0" (addr), "1" (count) : > "%eax", "memory", "cc"); > >This is equivalent to: > >while(--count) >{ > /* I/O */ >} > >which is obviously wrong, because it doesn't check for count equal to ze= ro. >So >how can I fix this in assembly. I am not an expert with inlined assembly= , >so >maybe someone can correct me if I am wrong, but something like this need= s >to >be added: > >or %ecx, %ecx >jz 2 > >2: This is wrong beacause the result is stored in ecx. Better using JECXZ in= struction before the loop. Greeting, rookie From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 12:33:35 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2507C16A421 for ; Mon, 13 Jun 2005 12:33:35 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: from hydra.bec.de (www.ostsee-abc.de [62.206.222.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6B5043D48 for ; Mon, 13 Jun 2005 12:33:34 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: from britannica.bec.de (unknown [139.30.252.67]) by hydra.bec.de (Postfix) with ESMTP id D1EC535707 for ; Mon, 13 Jun 2005 14:33:30 +0200 (CEST) Received: by britannica.bec.de (Postfix, from userid 1001) id 062CD53ED; Mon, 13 Jun 2005 14:33:27 +0200 (CEST) Date: Mon, 13 Jun 2005 14:33:27 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Message-ID: <20050613123327.GC1343@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20050610224415.GB11336@malcolm.berkeley.edu> <20050611085830.N98712@Neo-Vortex.net> <200506102357.j5ANvoUD010517@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200506102357.j5ANvoUD010517@apollo.backplane.com> User-Agent: Mutt/1.5.6i Subject: Re: Slowing down an old program to run on a fast CPU? 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, 13 Jun 2005 12:33:35 -0000 On Fri, Jun 10, 2005 at 04:57:50PM -0700, Matthew Dillon wrote: > > You think that is bad, try running 'rain' on an xterm! HAHA. Not only xterm, normal console is good enough :) Joerg From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 12:44:33 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 33F3C16A41C for ; Mon, 13 Jun 2005 12:44:33 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: from hydra.bec.de (www.ostsee-abc.de [62.206.222.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC16E43D1F for ; Mon, 13 Jun 2005 12:44:32 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: from britannica.bec.de (unknown [139.30.252.67]) by hydra.bec.de (Postfix) with ESMTP id C033E35707 for ; Mon, 13 Jun 2005 14:44:31 +0200 (CEST) Received: by britannica.bec.de (Postfix, from userid 1001) id 8BCCD53ED; Mon, 13 Jun 2005 14:44:28 +0200 (CEST) Date: Mon, 13 Jun 2005 14:44:27 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Message-ID: <20050613124427.GD1343@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <200506131412.38967.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200506131412.38967.hselasky@c2i.net> User-Agent: Mutt/1.5.6i Subject: Re: Obvious bug in /sys/i386/include/bus.h (was: bus_at386.h) 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, 13 Jun 2005 12:44:33 -0000 On Mon, Jun 13, 2005 at 02:12:38PM +0200, Hans Petter Selasky wrote: > This is equivalent to: > > while(--count) > { > /* I/O */ > } > > which is obviously wrong, because it doesn't check for count equal to > zero. Why do you think it is a bug? It is part of the interface contract and useful to avoid an unnecessary check in 99% of the cases. Joerg From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 12:52:56 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9024716A41F for ; Mon, 13 Jun 2005 12:52:56 +0000 (GMT) (envelope-from NKoch@demig.de) Received: from server.absolute-media.de (server.absolute-media.de [213.239.231.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B95543D49 for ; Mon, 13 Jun 2005 12:52:55 +0000 (GMT) (envelope-from NKoch@demig.de) Received: from localhost (unknown [127.0.0.1]) by server.absolute-media.de (Postfix) with ESMTP id 76A3685587; Mon, 13 Jun 2005 14:52:53 +0200 (CEST) Received: from server.absolute-media.de ([127.0.0.1]) by localhost (server [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03926-09; Mon, 13 Jun 2005 14:52:48 +0200 (CEST) Received: from firewall.demig (p50839F04.dip0.t-ipconnect.de [80.131.159.4]) by server.absolute-media.de (Postfix) with ESMTP id ADE3E8505C; Mon, 13 Jun 2005 14:52:48 +0200 (CEST) Received: from ws-ew-3 (ws-ew-3.w2kdemig [192.168.1.72]) by firewall.demig (8.13.4/8.13.1) with SMTP id j5DCp3RS033621; Mon, 13 Jun 2005 14:51:03 +0200 (CEST) (envelope-from NKoch@demig.de) From: "Norbert Koch" To: , Date: Mon, 13 Jun 2005 14:51:02 +0200 Message-ID: <000001c57016$8e4b0600$4801a8c0@ws-ew-3.W2KDEMIG> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <429C8E8F00015E63@ims3a.cp.tin.it> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at absolute-media.de Cc: hselasky@c2i.net Subject: RE: Obvious bug in /sys/i386/include/bus.h (was: bus_at386.h) 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, 13 Jun 2005 12:52:56 -0000 > >So > >how can I fix this in assembly. I am not an expert with inlined assembly, > >so > >maybe someone can correct me if I am wrong, but something like this needs > >to > >be added: > > > >or %ecx, %ecx > >jz 2 > > > >2: > > This is wrong beacause the result is stored in ecx. Better using > JECXZ instruction > before the loop. > > Greeting, > rookie No, it's a correct method to set/reset the zero flag: (X | X) == X just as (X & X) == X So, he could also write: "and %ecx, %ecx". I may be wrong, but in the old 386/486 days the "jecxz" was even less efficient, wasn't it? Twenty years ago, my z80 programs had a lot of lines like and a ret z Weren't there discussions, if an nmos cpu consumed more electric power with either "and a" or "or a"? ;-) Norbert From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 15:03:10 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D9DCA16A41C for ; Mon, 13 Jun 2005 15:03:10 +0000 (GMT) (envelope-from apachexm@hotmail.com) Received: from hotmail.com (bay19-f5.bay19.hotmail.com [64.4.53.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id B11EE43D53 for ; Mon, 13 Jun 2005 15:03:10 +0000 (GMT) (envelope-from apachexm@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 13 Jun 2005 08:03:10 -0700 Message-ID: Received: from 220.169.39.197 by by19fd.bay19.hotmail.msn.com with HTTP; Mon, 13 Jun 2005 15:03:10 GMT X-Originating-IP: [220.169.39.197] X-Originating-Email: [apachexm@hotmail.com] X-Sender: apachexm@hotmail.com In-Reply-To: <200506131241.j5DCfXL5026935@casselton.net> From: "Apache Xie" To: tinguely@casselton.net Date: Mon, 13 Jun 2005 15:03:10 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 13 Jun 2005 15:03:10.0444 (UTC) FILETIME=[037D4AC0:01C57029] Cc: freebsd-hackers@freebsd.org Subject: Re: contigmalloc() and mmap() 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, 13 Jun 2005 15:03:11 -0000 >From: Mark Tinguely >To: apachexm@hotmail.com, freebsd-hackers@freebsd.org >Subject: Re: contigmalloc() and mmap() >Date: Mon, 13 Jun 2005 07:41:33 -0500 (CDT) > > > I browsed kernel tree, I found those drivers which use contigmalloc() >and > > contigfree() always call these two kernel interfaces in _attach() and > > _detach(), but in my driver, I call contigmalloc() in ioctl(), and call > > contigfree() in a callout function which is set by callout_reset(). > > What I want to know is if contigmalloc() and contigfree() can only be >used > > under some conditions? > >Allocating early prevents unfullfilled requests due to fragmentation of >the physical memory. I believe starting in FreeBSD 5.x, contigmalloc() >started to fill physical memory requests from the higher memory locations >to help with fragmentation. FreeBSD 5/6 has a Unified Meory Allocator >that helps allocate/free cycles. > > > And recently, I modified my driver, I allocated a big chunk of >contiguous > > physical memory using contigmalloc() in the driver's _attach() >function, > > and I use a simple first-fit algorithm to manage this memory myself, >which > > mean in ioctl() I use my allocate/deallocate functions instead of > > contigmalloc(), > > in _detach() function contigfree() is called to free the big chunk of > > memory, > > no panic again, but sometimes, process cannot get the correct data from > > the mmaped memory. I don't know why. > >Are you sure that you are allocating page length request on page >boundaries? >Are you checking the success/failure of the allocation? Your page faults >before implementing your own allocation sounds like you did not check >the return status from contigmalloc() and were dereferencing a pointer >on page 0. > >--Mark Tinguely. I checked the return values of those functions in my code, the problem I meet now seems caused by some cache coherency, I am still not sure, maybe I should do some more tests. And I used /dev/mem and bktr driver as the template when I was porting my driver, the platform I use is IA-64, in sys/ia64/ia64/mem.c, I find this line: *paddr = IA64_PHYS_TO_RR7(offset); why return the region 7 address? _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 15:57:39 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 56EF916A41C for ; Mon, 13 Jun 2005 15:57:39 +0000 (GMT) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AECA43D4C for ; Mon, 13 Jun 2005 15:57:36 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: Y1QAsIk9O44SO+J/q9KNyQ== Received: from mp-217-233-35.daxnet.no ([193.217.233.35] verified) by mailfe06.swip.net (CommuniGate Pro SMTP 4.3.2) with ESMTP id 383553762; Mon, 13 Jun 2005 17:57:33 +0200 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Mon, 13 Jun 2005 17:58:24 +0200 User-Agent: KMail/1.7 References: <200506131412.38967.hselasky@c2i.net> <20050613124427.GD1343@britannica.bec.de> In-Reply-To: <20050613124427.GD1343@britannica.bec.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506131758.25671.hselasky@c2i.net> Cc: Joerg Sonnenberger Subject: Re: Obvious bug in /sys/i386/include/bus.h (was: bus_at386.h) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hselasky@c2i.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2005 15:57:39 -0000 On Monday 13 June 2005 14:44, Joerg Sonnenberger wrote: > On Mon, Jun 13, 2005 at 02:12:38PM +0200, Hans Petter Selasky wrote: > > This is equivalent to: > > > > while(--count) > > { > > /* I/O */ > > } > > > > which is obviously wrong, because it doesn't check for count equal to > > zero. > > Why do you think it is a bug? It is part of the interface contract and > useful to avoid an unnecessary check in 99% of the cases. > Where is it documented? This is a bug, because it will break standard FIFO design. Consider the following pseudo code: static void filter(struct fifo *f) { do { if(!f->len) { if(f->m) ...; f->m = get_mbuf(); if(!f->m) break; f->len = m->m_len; f->ptr = m->m_data; } /* f->Z_chip is the maximum transfer length */ io_len = min(f->len, f->Z_chip); bus_space_write_multi_1(t,h,xxx,f->ptr,io_len); f->len -= io_len; f->Z_chip -= io_len; f->ptr += io_len; } while(Z_chip); } This code is going to crash if "f->Z_chip" or "f->len" is zero. That happens when one is trying to send or receive a zero length frame or mbuf. So then one can argue wether one should allow zero length frames or not. I argue that zero length frames should be allowed, because it enables easy stream synchronization: For example to signal end of stream, send a frame less than 16 bytes. Maximum frame length is 16 bytes. If a stream is exactly 16 bytes long, then one has to send one 16 byte frame and one 0 byte frame. Also zero length frames can be used as a kind of heart-beat. Adding that extra check for zero transfer length is not going to affect performance at all. If one does that using "C", the compiler can optimize away that "if(count) ..." when "count" is a constant. Besides the i386 machine instructions "ins" and "outs" already exhibit that behaviour. --HPS From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 16:32:05 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48D8616A41F for ; Mon, 13 Jun 2005 16:32:05 +0000 (GMT) (envelope-from Maksim.Yevmenkin@savvis.net) Received: from mailgate1b.savvis.net (mailgate1b.savvis.net [216.91.182.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id DEFBE43D5E for ; Mon, 13 Jun 2005 16:32:04 +0000 (GMT) (envelope-from Maksim.Yevmenkin@savvis.net) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgate1b.savvis.net (Postfix) with ESMTP id 46D7B3BE95; Mon, 13 Jun 2005 11:32:04 -0500 (CDT) Received: from mailgate1b.savvis.net ([127.0.0.1]) by localhost (mailgate1b.savvis.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 12312-01-43; Mon, 13 Jun 2005 11:32:04 -0500 (CDT) Received: from out001.email.savvis.net (out001.apptix.savvis.net [216.91.32.44]) by mailgate1b.savvis.net (Postfix) with ESMTP id 0F6663BE2F; Mon, 13 Jun 2005 11:32:04 -0500 (CDT) Received: from s228130hz1ew031.apptix-01.savvis.net ([10.146.4.28]) by out001.email.savvis.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Jun 2005 11:32:06 -0500 Received: from [10.254.186.111] ([66.35.239.94]) by s228130hz1ew031.apptix-01.savvis.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Jun 2005 11:32:00 -0500 Message-ID: <42ADB4F8.5040701@savvis.net> Date: Mon, 13 Jun 2005 09:31:52 -0700 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Norbert Koch References: <000001c56ff8$ffda5b40$4801a8c0@ws-ew-3.W2KDEMIG> In-Reply-To: <000001c56ff8$ffda5b40$4801a8c0@ws-ew-3.W2KDEMIG> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jun 2005 16:32:01.0020 (UTC) FILETIME=[6CC2A3C0:01C57035] X-Virus-Scanned: amavisd-new at savvis.net Cc: "Freebsd-Hackers@Freebsd.Org" Subject: Re: using vkbd device 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, 13 Jun 2005 16:32:05 -0000 Hi Norbert, >> you also might want to look at experimental keyboard mux drivers. >> it is based on vkbd(4) and uses the idea of one super-keyboard that >> consumes scancodes from other keyboards. there are still a few >> issues i need to fix, but, in general, it works. >> >> http://www.geocities.com/m_evmenkin/kbdmux-2.tar.gz > > I back-ported kbdmux to FreeBSD 4.11 (and stopped work on vkbd). It thanks for your work and patches! i will merge some of your changes into my version. this way it will be easier to maintain (that is if kbdmux(4) will be included in FreeBSD :-) > seems to work, although I still have some stability issues with > dynamically attaching/detaching a usb keyboard. For your reference I would you share with us what sort of issues you are having? feel free to move this into private email if you are not comfortable discussing it on public mailing list. > have enclosed a patch file. Sorry for some diffs due to slightly > different coding and debugging style. no problem. in one of your previous emails you have been concerned about possible keyboard interrupt miss (in vkbd(4)). kbdmux(4) have the same issue. is that something you just did not fix yet, or it is not a problem anymore? in my local tree a added an extra callout that goes 10 times a second and queues interrupt if needed. also i'm curious why do you use splhigh() instead of spltty()? is this an issue with usb? (not sure which spl level usb runs on in 4.x) thanks, max From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 16:39:22 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E5CF16A41C for ; Mon, 13 Jun 2005 16:39:22 +0000 (GMT) (envelope-from nectar@FreeBSD.org) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id D920D43D48 for ; Mon, 13 Jun 2005 16:39:21 +0000 (GMT) (envelope-from nectar@FreeBSD.org) Received: from gw.celabo.org (localhost [127.0.0.1]) by internal.gw.celabo.org (Postfix) with ESMTP id 5CDC83E2F3D for ; Mon, 13 Jun 2005 11:39:20 -0500 (CDT) Received: from lum.celabo.org (lum.celabo.org [10.0.1.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "lum.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.celabo.org (Postfix) with ESMTP id 5612E3E2F3B for ; Mon, 13 Jun 2005 11:39:20 -0500 (CDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by lum.celabo.org (Postfix) with ESMTP id 2761B1259C0 for ; Mon, 13 Jun 2005 11:39:19 -0500 (CDT) Mime-Version: 1.0 (Apple Message framework v730) Content-Transfer-Encoding: 7bit Message-Id: <234CFECD-0A1A-4E71-AAD8-5E3E62A86C0F@FreeBSD.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-hackers@FreeBSD.org From: Jacques Vidrine Date: Mon, 13 Jun 2005 11:39:18 -0500 X-Mailer: Apple Mail (2.730) X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on hellblazer.celabo.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.3 Cc: Subject: possible problem writing to SCSI tapes 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, 13 Jun 2005 16:39:22 -0000 Hi Everyone, I thought I'd forward this, in case there is someone interested in working on SCSI tape support. Andrew Hume wrote in the June 2005 ";login": For outright bugs, two examples come to mind. The first is the weakness of the FreeBSD SCSI system; we cannot reliably write tapes on our FreeBSD nodes (although at least we get told about the errors!). Again, the tape is slow (5MB/s) and should not be an issue, and we can reliably write them on Linux (on more or less identical hardware). Although this is annoying, it turns out reading a tape works just fine, so we're not too annoyed. There's not further information in the article, nor is there a related PR that I can see. Perhaps someone interested can contact directly. Cheers, -- Jacques A Vidrine / NTT/Verio nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 17:10:57 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C9DE416A423 for ; Mon, 13 Jun 2005 17:10:57 +0000 (GMT) (envelope-from julian@elischer.org) Received: from bigwoop.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91E0043D1D for ; Mon, 13 Jun 2005 17:10:57 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by bigwoop.vicor-nb.com (Postfix) with ESMTP id 16E187A423; Mon, 13 Jun 2005 10:10:57 -0700 (PDT) Message-ID: <42ADBE21.6030007@elischer.org> Date: Mon, 13 Jun 2005 10:10:57 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050423 X-Accept-Language: en, hu MIME-Version: 1.0 To: Apache Xie References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: contigmalloc() and mmap() 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, 13 Jun 2005 17:10:58 -0000 Apache Xie wrote: > I have some experiences in writing Linux device driver, > but I am new to FreeBSD kernel, although from the first > glimpse, there seems no big differences between the kernel > operations a char device driver can use, but I met some > problems when the driver is running in FreeBSD. > > Our device is an experimental communication card, which can > do remote DMA between two cards, which means the card in one > node can DMA memory data to network, and when data are transfered > to the card on another node, it will be DMAed to memory too. sounds like a firewire card :-) > > Because the card can only use contiguous physical memory for > DMA operations, so data in user process will be copied to an > contiguous memory buffer, then DMA will tranfer data in this > buffer, and this buffer is allocated by driver using __get_free_pages() > in Linux. The buffer is mmaped to user process space, so user > process can do the copy directly in user space, it can directly > orgnize data in this mmaped memory too. > > When I am porting my driver to FreeBSD, I use /dev/bktr driver as the > example, seems easily, just using contigmalloc() to allocate the > buffer, and in driver's _mmap() function, return the physical > address for each page to be mmaped. > > The problem is, in Linux, I allocate buffer in driver's ioctl() > function, and free it in a timer function, many processes may use the > driver > at the same time, each process use a different kernel buffer, when > the process first use the driver, it calls __get_free_pages() to allocate > kernel buffer, and when it exit, it trigger timer function, the timer > function will can free_pages() to free the buffer, so these two kernel > interfaces will be called frequently, but this usage pattern works > correctly in Linux. > > In FreeBSD, the driver works in the same pattern, but when a user process > mmap driver's buffer (allocated by contigmalloc()) and is killed, then > when > another process mmap the same buffer again, sometimes it cannot get > correct > data from the mmaped pages, which means the user space virtual aderess > may > not point to the correct physical page of driver's buffer, sometimes > the OS > even panic with some information such as "Trap 12, Page not present" etc. > > I browsed kernel tree, I found those drivers which use contigmalloc() and > contigfree() always call these two kernel interfaces in _attach() and > _detach(), but in my driver, I call contigmalloc() in ioctl(), and call > contigfree() in a callout function which is set by callout_reset(). > What I want to know is if contigmalloc() and contigfree() can only be > used > under some conditions? Maybe I don't understand the problem but.. I think the problem is that you want to keep a separate buffer for each user, ] while the drivers you are looking at expect to have only one buffer per device. One answer to this would be to make each user open a different 'instance' of the device. (i.e. a differnt minor number). otherwise there is no really good place to store the information. The device does not track users as such and even if it did, how would it track when a user process forks and becomes 2? it is not notified of this event. > > And recently, I modified my driver, I allocated a big chunk of contiguous > physical memory using contigmalloc() in the driver's _attach() function, > and I use a simple first-fit algorithm to manage this memory myself, > which > mean in ioctl() I use my allocate/deallocate functions instead of > contigmalloc(), > in _detach() function contigfree() is called to free the big chunk of > memory, > no panic again, but sometimes, process cannot get the correct data from > the mmaped memory. I don't know why. > > Any help is welcomed. > > Thanks. > > _________________________________________________________________ > Express yourself instantly with MSN Messenger! Download today it's > FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 17:34:03 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C38216A41C for ; Mon, 13 Jun 2005 17:34:03 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41CE843D4C for ; Mon, 13 Jun 2005 17:34:03 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.4/8.13.4/NETPLEX) with ESMTP id j5DHXt7X008605; Mon, 13 Jun 2005 13:33:55 -0400 (EDT) Date: Mon, 13 Jun 2005 13:33:55 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Julian Elischer In-Reply-To: <42ADBE21.6030007@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: freebsd-hackers@freebsd.org, Apache Xie Subject: Re: contigmalloc() and mmap() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2005 17:34:03 -0000 On Mon, 13 Jun 2005, Julian Elischer wrote: > > Maybe I don't understand the problem but.. > > I think the problem is that you want to keep a separate buffer for each > user, ] > while the drivers you are looking at expect to have only one buffer per > device. > > One answer to this would be to make each user open a different 'instance' > of the device. (i.e. a differnt minor number). otherwise there is no > really good place to store the information. > The device does not track users as such and even if it did, how would it > track when a user process forks and becomes 2? it is not notified of this > event. Is he looking for something like this in FreeBSD? http://docs.sun.com/app/docs/doc/802-5900/6i9kj7or8?a=view -- DE From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 17:50:26 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5227B16A41C; Mon, 13 Jun 2005 17:50:26 +0000 (GMT) (envelope-from julian@elischer.org) Received: from bigwoop.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2753743D55; Mon, 13 Jun 2005 17:50:26 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by bigwoop.vicor-nb.com (Postfix) with ESMTP id 111BD7A403; Mon, 13 Jun 2005 10:50:26 -0700 (PDT) Message-ID: <42ADC762.6010801@elischer.org> Date: Mon, 13 Jun 2005 10:50:26 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050423 X-Accept-Language: en, hu MIME-Version: 1.0 To: Daniel Eischen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Apache Xie Subject: Re: contigmalloc() and mmap() 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, 13 Jun 2005 17:50:26 -0000 Daniel Eischen wrote: >On Mon, 13 Jun 2005, Julian Elischer wrote: > > >>Maybe I don't understand the problem but.. >> >>I think the problem is that you want to keep a separate buffer for each >>user, >>while the drivers you are looking at expect to have only one buffer per >>device. >> >>One answer to this would be to make each user open a different 'instance' >>of the device. (i.e. a differnt minor number). otherwise there is no >>really good place to store the information. >>The device does not track users as such and even if it did, how would it >>track when a user process forks and becomes 2? it is not notified of this >>event. >> >> > >Is he looking for something like this in FreeBSD? > > http://docs.sun.com/app/docs/doc/802-5900/6i9kj7or8?a=view > > Intersting, but no, I don't thionk that is what he is looking for. Several times in the past we've seen people complainign that Linux allows a device driver to know who called it and somehow it seems to store somewhere some information about who openned the device.. thos somehow allows linux to store an arbitrary structure for each openning process. I thin from the sond of it that he wants to do something similar. From the sond of it he wants to have a different buffer be used depending on who is calling. This would partly work but would not work when processes fork etc. I think Linux must do some extra housekeeping in this case. anyhow I may be wrong. I'll go read it again :-) From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 18:11:29 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE25516A41C for ; Mon, 13 Jun 2005 18:11:29 +0000 (GMT) (envelope-from julian@elischer.org) Received: from bigwoop.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A570443D53 for ; Mon, 13 Jun 2005 18:11:27 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by bigwoop.vicor-nb.com (Postfix) with ESMTP id 1C76E7A403; Mon, 13 Jun 2005 11:11:27 -0700 (PDT) Message-ID: <42ADCC4F.4090201@elischer.org> Date: Mon, 13 Jun 2005 11:11:27 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050423 X-Accept-Language: en, hu MIME-Version: 1.0 To: Apache Xie References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: contigmalloc() and mmap() 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, 13 Jun 2005 18:11:30 -0000 2nd try to answer this.. Apache Xie wrote: > I have some experiences in writing Linux device driver, > but I am new to FreeBSD kernel, although from the first > glimpse, there seems no big differences between the kernel > operations a char device driver can use, but I met some > problems when the driver is running in FreeBSD. > > Our device is an experimental communication card, which can > do remote DMA between two cards, which means the card in one > node can DMA memory data to network, and when data are transfered > to the card on another node, it will be DMAed to memory too. > > > Because the card can only use contiguous physical memory for > DMA operations, so data in user process will be copied to an > contiguous memory buffer, then DMA will tranfer data in this > buffer, and this buffer is allocated by driver using __get_free_pages() > in Linux. The buffer is mmaped to user process space, so user > process can do the copy directly in user space, it can directly > orgnize data in this mmaped memory too. ok, so far so good.. machine to machine DMA capability with contiguous buffers.. nothing too complicated so far.. I once did a simiar system on BSD4.3 in 1992. > > When I am porting my driver to FreeBSD, I use /dev/bktr driver as the > example, seems easily, just using contigmalloc() to allocate the > buffer, and in driver's _mmap() function, return the physical > address for each page to be mmaped. > > The problem is, in Linux, I allocate buffer in driver's ioctl() > function, and free it in a timer function, many processes may use the > driver > at the same time, each process use a different kernel buffer, when > the process first use the driver, it calls __get_free_pages() to allocate > kernel buffer, and when it exit, it trigger timer function, the timer > function will can free_pages() to free the buffer, so these two kernel > interfaces will be called frequently, but this usage pattern works > correctly in Linux. I'm unsure about this usage of the timer (callout(?) ) how does the timer know which buffer pages to remove? and if each userspace process does an ioctl to allocate a different buffer, are the new pages also visible to other processes? in FreeBSD your driver can register with at_exit() in 4.x and with eventhandler_register() in 5.x or 6.x to have stuff done when the process exits. (there are also at_fork and at_exec handlers too.) see man at_exit (etc.) in 4.x and man 9 EVENTHANDLER in 5.x and 6.x You could also make a hash table on the PID so that you keep different information available for different processes and look them up using curproc->p_pid (for 4.x) and curthhread->td_proc->p_pid for 5.x and 6.x to look up the Using these primatives you should be able to simulate what you need I believe. > In FreeBSD, the driver works in the same pattern, but when a user process > mmap driver's buffer (allocated by contigmalloc()) and is killed, then > when > another process mmap the same buffer again, sometimes it cannot get > correct > data from the mmaped pages, which means the user space virtual aderess > may > not point to the correct physical page of driver's buffer, sometimes > the OS > even panic with some information such as "Trap 12, Page not present" etc. sounds like you are getting the buffers confused.. are you doing correc treference counting on the buffers? > > I browsed kernel tree, I found those drivers which use contigmalloc() and > contigfree() always call these two kernel interfaces in _attach() and > _detach(), but in my driver, I call contigmalloc() in ioctl(), and call > contigfree() in a callout function which is set by callout_reset(). why by callout_reset()? > What I want to know is if contigmalloc() and contigfree() can only be > used > under some conditions? not that I know of.. > > And recently, I modified my driver, I allocated a big chunk of contiguous > physical memory using contigmalloc() in the driver's _attach() function, > and I use a simple first-fit algorithm to manage this memory myself, > which > mean in ioctl() I use my allocate/deallocate functions instead of > contigmalloc(), > in _detach() function contigfree() is called to free the big chunk of > memory, > no panic again, but sometimes, process cannot get the correct data from > the mmaped memory. I don't know why. it does sound a bit like you are not keeping the information separated between processes enough. > > Any help is welcomed. > > Thanks. > > _________________________________________________________________ > Express yourself instantly with MSN Messenger! Download today it's > FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 18:14:40 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A982F16A41C; Mon, 13 Jun 2005 18:14:40 +0000 (GMT) (envelope-from SRS0+0b851353296582aa3a45+659+infradead.org+hch@pentafluge.srs.infradead.org) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id F22A243D1D; Mon, 13 Jun 2005 18:14:39 +0000 (GMT) (envelope-from SRS0+0b851353296582aa3a45+659+infradead.org+hch@pentafluge.srs.infradead.org) Received: from hch by pentafluge.infradead.org with local (Exim 4.43 #1 (Red Hat Linux)) id 1DhtSF-0000pU-HI; Mon, 13 Jun 2005 19:14:35 +0100 Date: Mon, 13 Jun 2005 19:14:35 +0100 From: Christoph Hellwig To: Julian Elischer Message-ID: <20050613181435.GA3096@infradead.org> References: <42ADC762.6010801@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42ADC762.6010801@elischer.org> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Cc: Daniel Eischen , freebsd-hackers@freebsd.org, Apache Xie Subject: Re: contigmalloc() and mmap() 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, 13 Jun 2005 18:14:40 -0000 On Mon, Jun 13, 2005 at 10:50:26AM -0700, Julian Elischer wrote: > > Several times in the past we've seen people complainign that Linux > allows a device driver to know > who called it and somehow it seems to store somewhere some information > about who > openned the device.. thos somehow allows linux to store an arbitrary > structure > for each openning process. I thin from the sond of it that he wants to > do something > similar. From the sond of it he wants to have a different buffer be used > depending on > who is calling. This would partly work but would not work when processes > fork etc. > > I think Linux must do some extra housekeeping in this case. What Linux does is pretty simple. The driver has access to the file structure, and this structure has a field for driver private data. It can store private data in open and free it again in the release callback. From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 18:31:11 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6388516A41C for ; Mon, 13 Jun 2005 18:31:11 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: from hydra.bec.de (www.ostsee-abc.de [62.206.222.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id D370C43D1D for ; Mon, 13 Jun 2005 18:31:10 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: from britannica.bec.de (unknown [139.30.252.67]) by hydra.bec.de (Postfix) with ESMTP id A3A2B35707 for ; Mon, 13 Jun 2005 20:31:09 +0200 (CEST) Received: by britannica.bec.de (Postfix, from userid 1001) id B984B5428; Mon, 13 Jun 2005 18:27:43 +0200 (CEST) Date: Mon, 13 Jun 2005 18:27:43 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Message-ID: <20050613162743.GA769@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <200506131412.38967.hselasky@c2i.net> <20050613124427.GD1343@britannica.bec.de> <200506131758.25671.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200506131758.25671.hselasky@c2i.net> User-Agent: Mutt/1.5.6i Subject: Re: Obvious bug in /sys/i386/include/bus.h (was: bus_at386.h) 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, 13 Jun 2005 18:31:11 -0000 On Mon, Jun 13, 2005 at 05:58:24PM +0200, Hans Petter Selasky wrote: > static void > filter(struct fifo *f) > { > do { > if(!f->len) > { > if(f->m) ...; > > f->m = get_mbuf(); > if(!f->m) break; > > f->len = m->m_len; > f->ptr = m->m_data; > } > > /* f->Z_chip is the maximum transfer length */ > > io_len = min(f->len, f->Z_chip); if (io_len == 0) continue; > > bus_space_write_multi_1(t,h,xxx,f->ptr,io_len); > > f->len -= io_len; > f->Z_chip -= io_len; > f->ptr += io_len; > > } while(Z_chip); > } > [...] > Adding that extra check for zero transfer length is not going to affect > performance at all. If one does that using "C", the compiler can optimize > away that "if(count) ..." when "count" is a constant. Besides the i386 > machine instructions "ins" and "outs" already exhibit that behaviour. The compiler can only optimize it away if it is known to be a constant. But thinking again about it, it should be documented at least whether a count of 0 is allowed or not. I think it makes more sense to not allow it, but others (you included) might disagree. Joerg From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 18:37:00 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F38F16A41C for ; Mon, 13 Jun 2005 18:37:00 +0000 (GMT) (envelope-from erik.u@dnainternet.net) Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3037C43D1F for ; Mon, 13 Jun 2005 18:36:59 +0000 (GMT) (envelope-from erik.u@dnainternet.net) Received: from b-184-46.dsl.kpy.customers.dnainternet.fi ([212.149.184.46]:65532 "EHLO [192.168.1.11]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1229217AbVFMSg5 (ORCPT ); Mon, 13 Jun 2005 21:36:57 +0300 Message-ID: <42ADD249.7020709@dnainternet.net> Date: Mon, 13 Jun 2005 21:36:57 +0300 From: Erik Udo User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050430) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: prioritizing small ip packets? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-hackers@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2005 18:37:00 -0000 I came across this idea for prioritizing small IP packets, so that for example HTTP requests, game packets and other small, but importat packets would get uploaded before the big packets. Big files are usually uploaded in bigger packets, right? So, i haven't found a way to make this happen, i googled for it but didn't find anything. Does PF or IPFW have this feature? From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 18:39:43 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 431C216A41F; Mon, 13 Jun 2005 18:39:43 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6E2843D1D; Mon, 13 Jun 2005 18:39:42 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j5DIiVvZ005878; Mon, 13 Jun 2005 12:44:31 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42ADD253.4020606@samsco.org> Date: Mon, 13 Jun 2005 12:37:07 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christoph Hellwig References: <42ADC762.6010801@elischer.org> <20050613181435.GA3096@infradead.org> In-Reply-To: <20050613181435.GA3096@infradead.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: Daniel Eischen , freebsd-hackers@freebsd.org, Julian Elischer , Apache Xie Subject: Re: contigmalloc() and mmap() 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, 13 Jun 2005 18:39:43 -0000 Christoph Hellwig wrote: > On Mon, Jun 13, 2005 at 10:50:26AM -0700, Julian Elischer wrote: > >>Several times in the past we've seen people complainign that Linux >>allows a device driver to know >>who called it and somehow it seems to store somewhere some information >>about who >>openned the device.. thos somehow allows linux to store an arbitrary >>structure >>for each openning process. I thin from the sond of it that he wants to >>do something >>similar. From the sond of it he wants to have a different buffer be used >>depending on >>who is calling. This would partly work but would not work when processes >>fork etc. >> >>I think Linux must do some extra housekeeping in this case. > > > What Linux does is pretty simple. The driver has access to the file > structure, and this structure has a field for driver private data. > It can store private data in open and free it again in the release > callback. > How does linux handle the implications of fork(2) in this scenario? Scott From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 18:41:35 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BFCF416A41C for ; Mon, 13 Jun 2005 18:41:35 +0000 (GMT) (envelope-from baldur@foo.is) Received: from gremlin.foo.is (gremlin.foo.is [194.105.250.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 664CB43D5C for ; Mon, 13 Jun 2005 18:41:33 +0000 (GMT) (envelope-from baldur@foo.is) Received: from 127.0.0.1 (localhost.foo.is [127.0.0.1]) by injector.foo.is (Postfix) with SMTP id 8FAB33A2AA for ; Mon, 13 Jun 2005 18:41:31 +0000 (GMT) Received: by gremlin.foo.is (Postfix, from userid 1000) id AABDE3A2A9; Mon, 13 Jun 2005 18:41:28 +0000 (GMT) Date: Mon, 13 Jun 2005 18:41:28 +0000 From: Baldur Gislason To: freebsd-hackers@freebsd.org Message-ID: <20050613184128.GA16980@gremlin.foo.is> References: <42ADD249.7020709@dnainternet.net> In-Reply-To: <42ADD249.7020709@dnainternet.net> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on gremlin.foo.is X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=6.0 tests=AWL,BAYES_00 autolearn=ham version=2.61 X-Sanitizer: Foo MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Subject: Re: prioritizing small ip packets? 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, 13 Jun 2005 18:41:35 -0000 IPFW does have a queue feature which is a part of dummynet. You can match packets based on size and send them to different queues. Baldur On Mon, Jun 13, 2005 at 09:36:57PM +0300, Erik Udo wrote: > I came across this idea for prioritizing small > IP packets, so that for example HTTP requests, > game packets and other small, but importat packets > would get uploaded before the big packets. Big files > are usually uploaded in bigger packets, right? > > So, i haven't found a way to make this happen, i googled > for it but didn't find anything. Does PF or IPFW have this > feature? > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 18:44:00 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC77016A41C for ; Mon, 13 Jun 2005 18:44:00 +0000 (GMT) (envelope-from dodell@offmyserver.com) Received: from knight.ixsystems.net (afg.ixsystems.net [206.40.55.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id B07F043D1D for ; Mon, 13 Jun 2005 18:44:00 +0000 (GMT) (envelope-from dodell@offmyserver.com) Received: from [192.168.1.111] (afg.ixsystems.net [206.40.55.73]) by knight.ixsystems.net (8.12.10/8.11.6) with ESMTP id j5DIKTgs006952; Mon, 13 Jun 2005 11:20:30 -0700 (PDT) (envelope-from dodell@offmyserver.com) Message-ID: <42ADD3D5.6080103@offmyserver.com> Date: Mon, 13 Jun 2005 11:43:33 -0700 From: "Devon H. O'Dell" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Baldur Gislason References: <42ADD249.7020709@dnainternet.net> <20050613184128.GA16980@gremlin.foo.is> In-Reply-To: <20050613184128.GA16980@gremlin.foo.is> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: prioritizing small ip packets? 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, 13 Jun 2005 18:44:01 -0000 Baldur Gislason wrote: > IPFW does have a queue feature which is a part of dummynet. > You can match packets based on size and send them to different queues. > > Baldur > > On Mon, Jun 13, 2005 at 09:36:57PM +0300, Erik Udo wrote: > >>I came across this idea for prioritizing small >>IP packets, so that for example HTTP requests, >>game packets and other small, but importat packets >>would get uploaded before the big packets. Big files >>are usually uploaded in bigger packets, right? >> >>So, i haven't found a way to make this happen, i googled >>for it but didn't find anything. Does PF or IPFW have this >>feature? I'm not sure the rationale is appropriate, though. You should be more worried about prioritizing ACKs if this is an asynchronous low-speed connection. --Devon From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 18:45:55 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A7B2916A41C; Mon, 13 Jun 2005 18:45:55 +0000 (GMT) (envelope-from SRS0+0b851353296582aa3a45+659+infradead.org+hch@pentafluge.srs.infradead.org) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 547BB43D53; Mon, 13 Jun 2005 18:45:55 +0000 (GMT) (envelope-from SRS0+0b851353296582aa3a45+659+infradead.org+hch@pentafluge.srs.infradead.org) Received: from hch by pentafluge.infradead.org with local (Exim 4.43 #1 (Red Hat Linux)) id 1DhtwV-00010x-IX; Mon, 13 Jun 2005 19:45:51 +0100 Date: Mon, 13 Jun 2005 19:45:51 +0100 From: Christoph Hellwig To: Scott Long Message-ID: <20050613184551.GA3853@infradead.org> References: <42ADC762.6010801@elischer.org> <20050613181435.GA3096@infradead.org> <42ADD253.4020606@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42ADD253.4020606@samsco.org> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Cc: Daniel Eischen , Julian Elischer , Apache Xie , freebsd-hackers@freebsd.org Subject: Re: contigmalloc() and mmap() 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, 13 Jun 2005 18:45:55 -0000 On Mon, Jun 13, 2005 at 12:37:07PM -0600, Scott Long wrote: > How does linux handle the implications of fork(2) in this scenario? it's still counted as the same instance. Similar for dup or passing descriptors over AF_UNIX sockets. The data is explictly not per-process but per instance. There's not a lot of users actually using this feature, only the tty subsystem and multi-channel sound drivers for the old oss API that allowed multiple opens of /dev/dsp that way come to mind. Lot's of driver use file->private to get at per-device data easily, but that's just a shortcut. From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 18:58:23 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E45C16A41C; Mon, 13 Jun 2005 18:58:23 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id B1B8143D1F; Mon, 13 Jun 2005 18:58:22 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j5DJ34Q3006004; Mon, 13 Jun 2005 13:03:05 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42ADD6AC.3060505@samsco.org> Date: Mon, 13 Jun 2005 12:55:40 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christoph Hellwig References: <42ADC762.6010801@elischer.org> <20050613181435.GA3096@infradead.org> <42ADD253.4020606@samsco.org> <20050613184551.GA3853@infradead.org> In-Reply-To: <20050613184551.GA3853@infradead.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: Daniel Eischen , freebsd-hackers@freebsd.org, Julian Elischer , Apache Xie Subject: Re: contigmalloc() and mmap() 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, 13 Jun 2005 18:58:23 -0000 Christoph Hellwig wrote: > On Mon, Jun 13, 2005 at 12:37:07PM -0600, Scott Long wrote: > >>How does linux handle the implications of fork(2) in this scenario? > > > it's still counted as the same instance. Similar for dup or passing > descriptors over AF_UNIX sockets. The data is explictly not per-process > but per instance. > > There's not a lot of users actually using this feature, only the tty > subsystem and multi-channel sound drivers for the old oss API that > allowed multiple opens of /dev/dsp that way come to mind. > > Lot's of driver use file->private to get at per-device data easily, > but that's just a shortcut. Ok, I thought that you were talking about per-process data being in the file descriptor. Scott From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 19:02:28 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9056416A41C; Mon, 13 Jun 2005 19:02:28 +0000 (GMT) (envelope-from SRS0+0b851353296582aa3a45+659+infradead.org+hch@pentafluge.srs.infradead.org) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BEE043D48; Mon, 13 Jun 2005 19:02:28 +0000 (GMT) (envelope-from SRS0+0b851353296582aa3a45+659+infradead.org+hch@pentafluge.srs.infradead.org) Received: from hch by pentafluge.infradead.org with local (Exim 4.43 #1 (Red Hat Linux)) id 1DhuCW-00018d-MC; Mon, 13 Jun 2005 20:02:24 +0100 Date: Mon, 13 Jun 2005 20:02:24 +0100 From: Christoph Hellwig To: Scott Long Message-ID: <20050613190224.GA4308@infradead.org> References: <42ADC762.6010801@elischer.org> <20050613181435.GA3096@infradead.org> <42ADD253.4020606@samsco.org> <20050613184551.GA3853@infradead.org> <42ADD6AC.3060505@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42ADD6AC.3060505@samsco.org> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Cc: Daniel Eischen , freebsd-hackers@freebsd.org, Julian Elischer , Apache Xie Subject: Re: contigmalloc() and mmap() 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, 13 Jun 2005 19:02:28 -0000 On Mon, Jun 13, 2005 at 12:55:40PM -0600, Scott Long wrote: > >Lot's of driver use file->private to get at per-device data easily, > >but that's just a shortcut. > > Ok, I thought that you were talking about per-process data being in the > file descriptor. No, Linux has absolutely no concept of per-process data in driver, and if you think of it that would be rather bogus anyway (e.g. a driver opening the same device multiple times) From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 19:17:13 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6817916A41C; Mon, 13 Jun 2005 19:17:13 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id D6C4C43D49; Mon, 13 Jun 2005 19:17:08 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j5DJLu1c006113; Mon, 13 Jun 2005 13:21:56 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42ADDB18.9010805@samsco.org> Date: Mon, 13 Jun 2005 13:14:32 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christoph Hellwig References: <42ADC762.6010801@elischer.org> <20050613181435.GA3096@infradead.org> <42ADD253.4020606@samsco.org> <20050613184551.GA3853@infradead.org> <42ADD6AC.3060505@samsco.org> <20050613190224.GA4308@infradead.org> In-Reply-To: <20050613190224.GA4308@infradead.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: Daniel Eischen , freebsd-hackers@freebsd.org, Julian Elischer , Apache Xie Subject: Re: contigmalloc() and mmap() 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, 13 Jun 2005 19:17:13 -0000 Christoph Hellwig wrote: > On Mon, Jun 13, 2005 at 12:55:40PM -0600, Scott Long wrote: > >>>Lot's of driver use file->private to get at per-device data easily, >>>but that's just a shortcut. >> >>Ok, I thought that you were talking about per-process data being in the >>file descriptor. > > > No, Linux has absolutely no concept of per-process data in driver, and > if you think of it that would be rather bogus anyway (e.g. a driver opening > the same device multiple times) > Hence why I was confused and asking you about it. Thanks =-) Scott From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 19:31:56 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 586B116A41C for ; Mon, 13 Jun 2005 19:31:56 +0000 (GMT) (envelope-from mhunter@malcolm.berkeley.edu) Received: from malcolm.berkeley.edu (malcolm.Berkeley.EDU [128.32.206.239]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26A5643D49 for ; Mon, 13 Jun 2005 19:31:53 +0000 (GMT) (envelope-from mhunter@malcolm.berkeley.edu) Received: from malcolm.berkeley.edu (localhost [127.0.0.1]) by malcolm.berkeley.edu (8.13.3/8.13.3) with ESMTP id j5DJVoNI076251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Jun 2005 12:31:50 -0700 (PDT) (envelope-from mhunter@malcolm.berkeley.edu) Received: (from mhunter@localhost) by malcolm.berkeley.edu (8.13.3/8.13.3/Submit) id j5DJVoA8076250; Mon, 13 Jun 2005 12:31:50 -0700 (PDT) (envelope-from mhunter) Date: Mon, 13 Jun 2005 12:31:50 -0700 From: Mike Hunter To: Dag-Erling =?unknown-8bit?Q?Sm=F8rgrav?= Message-ID: <20050613193150.GA75218@malcolm.berkeley.edu> References: <20050610224058.GA11336@malcolm.berkeley.edu> <86vf4lb110.fsf@xps.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86vf4lb110.fsf@xps.des.no> User-Agent: Mutt/1.5.6i X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (malcolm.berkeley.edu [127.0.0.1]); Mon, 13 Jun 2005 12:31:51 -0700 (PDT) Cc: freebsd-hackers@freebsd.org Subject: Re: unitialized memory is all zeros...why not garbage instead? 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, 13 Jun 2005 19:31:56 -0000 On Jun 11, "Dag-Erling Smrgrav" wrote: > Mike Hunter writes: > > I have a feeling that I'm missing something really obvious, but I'm having > > trouble understanding why the following program: > > [...] > > Never prints anything but "0"'s. > > Because the kernel always hands processes pre-zeroed pages. > > > I ran less up to my hw.physmem by feeding it /dev/random and watching > > top, and then ran the program, so I "know" there was tons of non-zero > > bits in memory. > > If your program had been able to see leftovers from less in its own > address space, we'd have a huge security hole on our hands. > > > I'm curious because I am worried about information leaks between processes > > on the same machine...did somebody decide to solve this problem while I > > wasn't paying attention? :) > > It's always been this way. Thanks for setting me straight. I guess it wasn't this way on DOS where I first learned C++ and I've assumed garbage ever since :) Is the pre-zeroing of malloc'd memory documented somewhere? By my reading of the malloc manapge... The calloc() function allocates space for number objects, each size bytes in length. The result is identical to calling malloc() with an argument of ``number * size'', with the exception that the allocated memory is explicitly initialized to zero bytes. ...it seems like it's saying that malloc (as opposed to calloc) is NOT pre-zeroed. Is there a different document I should be reading? Tussen Tak! Mike From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 19:49:01 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 990A516A41C for ; Mon, 13 Jun 2005 19:49:01 +0000 (GMT) (envelope-from steve@Watt.COM) Received: from wattres.watt.com (wattres.watt.com [66.93.133.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2FC7043D4C for ; Mon, 13 Jun 2005 19:49:00 +0000 (GMT) (envelope-from steve@Watt.COM) Received: from wattres.watt.com (localhost.watt.com [127.0.0.1]) by wattres.watt.com (8.13.3/8.13.3) with ESMTP id j5DJmxq2011441; Mon, 13 Jun 2005 12:48:59 -0700 (PDT) (envelope-from steve@wattres.watt.com) Received: (from steve@localhost) by wattres.watt.com (8.13.3/8.13.3/Submit) id j5DJmx4e011440; Mon, 13 Jun 2005 12:48:59 -0700 (PDT) (envelope-from steve) Message-Id: <200506131948.j5DJmx4e011440@wattres.watt.com> X-Newsgroups: local.freebsd-hackers In-Reply-To: <20050613193150.GA75218@malcolm.berkeley.edu> References: <20050610224058.GA11336@malcolm.berkeley.edu> <86vf4lb110.fsf@xps.des.no> Organization: Watt Consultants From: steve@Watt.COM (Steve Watt) Date: Mon, 13 Jun 2005 12:48:59 -0700 X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: mhunter@ack.berkeley.edu X-Archived: 1118692139.930515067@wattres.Watt.COM X-Virus-Scanned: ClamAV 0.85.1/935/Mon Jun 13 09:27:50 2005 on wattres.Watt.COM X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org Subject: Re: unitialized memory is all zeros...why not garbage instead? 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, 13 Jun 2005 19:49:01 -0000 Mike Hunter wrote: >On Jun 11, "Dag-Erling Smrgrav" wrote: >> Mike Hunter writes: >> > I have a feeling that I'm missing something really obvious, but I'm having >> > trouble understanding why the following program: >> > [...] >> > Never prints anything but "0"'s. >> >> Because the kernel always hands processes pre-zeroed pages. > >Thanks for setting me straight. I guess it wasn't this way on DOS where I >first learned C++ and I've assumed garbage ever since :) > >Is the pre-zeroing of malloc'd memory documented somewhere? By my reading >of the malloc manapge... Careful now: The return value in memory from malloc() is not directly related to the return value in memory from sbrk(). malloc() may give the application back memory that was free()d previously by the same application. New pages that come out of sbrk() are 0s, but those aren't always needed to fulfill a malloc() request. > The calloc() function allocates space for number objects, each size > bytes in length. The result is identical to calling malloc() with an > argument of ``number * size'', with the exception that the allocated > memory is explicitly initialized to zero bytes. > >...it seems like it's saying that malloc (as opposed to calloc) is NOT >pre-zeroed. Is there a different document I should be reading? And if calloc() grabs something from the in-process "used, now free" pool, it will be zeroed. If malloc() grabs something from that same pool, it won't be. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8" / 37N 20' 14.9" Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices... From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 19:50:27 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 80DAD16A41F; Mon, 13 Jun 2005 19:50:27 +0000 (GMT) (envelope-from julian@elischer.org) Received: from bigwoop.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B8A843D1F; Mon, 13 Jun 2005 19:50:26 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by bigwoop.vicor-nb.com (Postfix) with ESMTP id 794577A403; Mon, 13 Jun 2005 12:50:26 -0700 (PDT) Message-ID: <42ADE382.4010403@elischer.org> Date: Mon, 13 Jun 2005 12:50:26 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050423 X-Accept-Language: en, hu MIME-Version: 1.0 To: Scott Long References: <42ADC762.6010801@elischer.org> <20050613181435.GA3096@infradead.org> <42ADD253.4020606@samsco.org> In-Reply-To: <42ADD253.4020606@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , Apache Xie , freebsd-hackers@freebsd.org Subject: Re: contigmalloc() and mmap() 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, 13 Jun 2005 19:50:27 -0000 Scott Long wrote: > Christoph Hellwig wrote: > >> On Mon, Jun 13, 2005 at 10:50:26AM -0700, Julian Elischer wrote: >> >>> Several times in the past we've seen people complainign that Linux >>> allows a device driver to know >>> who called it and somehow it seems to store somewhere some >>> information about who >>> openned the device.. thos somehow allows linux to store an arbitrary >>> structure >>> for each openning process. I thin from the sond of it that he wants >>> to do something >>> similar. From the sond of it he wants to have a different buffer be >>> used depending on >>> who is calling. This would partly work but would not work when >>> processes fork etc. >>> >>> I think Linux must do some extra housekeeping in this case. >> >> >> >> What Linux does is pretty simple. The driver has access to the file >> structure, and this structure has a field for driver private data. >> It can store private data in open and free it again in the release >> callback. >> > > How does linux handle the implications of fork(2) in this scenario? both processes get the same field.. I don't think there is any special handling.. that would require a "forking" handler in each driver. In practice it seems ot not be a problem. > > Scott From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 19:50:29 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64A1816A41C for ; Mon, 13 Jun 2005 19:50:29 +0000 (GMT) (envelope-from ertr1013@student.uu.se) Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 03BF743D1F for ; Mon, 13 Jun 2005 19:50:28 +0000 (GMT) (envelope-from ertr1013@student.uu.se) Received: from falcon.midgard.homeip.net (212.181.162.201) by pne-smtpout2-sn2.hy.skanova.net (7.2.059.6) id 429C53B6002EEBEB for freebsd-hackers@freebsd.org; Mon, 13 Jun 2005 21:50:27 +0200 Received: (qmail 90096 invoked by uid 1001); 13 Jun 2005 21:50:26 +0200 Date: Mon, 13 Jun 2005 21:50:26 +0200 From: Erik Trulsson To: Mike Hunter Message-ID: <20050613195026.GA90010@falcon.midgard.homeip.net> Mail-Followup-To: Mike Hunter , Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , freebsd-hackers@freebsd.org References: <20050610224058.GA11336@malcolm.berkeley.edu> <86vf4lb110.fsf@xps.des.no> <20050613193150.GA75218@malcolm.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050613193150.GA75218@malcolm.berkeley.edu> User-Agent: Mutt/1.5.9i Cc: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , freebsd-hackers@freebsd.org Subject: Re: unitialized memory is all zeros...why not garbage instead? 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, 13 Jun 2005 19:50:29 -0000 On Mon, Jun 13, 2005 at 12:31:50PM -0700, Mike Hunter wrote: > On Jun 11, "Dag-Erling Smrgrav" wrote: > > > Mike Hunter writes: > > > I have a feeling that I'm missing something really obvious, but I'm having > > > trouble understanding why the following program: > > > [...] > > > Never prints anything but "0"'s. > > > > Because the kernel always hands processes pre-zeroed pages. > > > > > I ran less up to my hw.physmem by feeding it /dev/random and watching > > > top, and then ran the program, so I "know" there was tons of non-zero > > > bits in memory. > > > > If your program had been able to see leftovers from less in its own > > address space, we'd have a huge security hole on our hands. > > > > > I'm curious because I am worried about information leaks between processes > > > on the same machine...did somebody decide to solve this problem while I > > > wasn't paying attention? :) > > > > It's always been this way. > > Thanks for setting me straight. I guess it wasn't this way on DOS where I > first learned C++ and I've assumed garbage ever since :) That is a good assumption. It is not true everywhere, but it rarely hurts being on the safe side. > > Is the pre-zeroing of malloc'd memory documented somewhere? By my reading > of the malloc manapge... > > The calloc() function allocates space for number objects, each size > bytes in length. The result is identical to calling malloc() with an > argument of ``number * size'', with the exception that the allocated > memory is explicitly initialized to zero bytes. > > ...it seems like it's saying that malloc (as opposed to calloc) is NOT > pre-zeroed. Is there a different document I should be reading? Note that this pre-zeroing is not done by malloc, but is done by the kernel before it hands over memory to a process. Memory is not necessarily returned to the system when free() is called, but is often retained within the process and reused by the next malloc(). This means that if you have a sequence like the following: foo=malloc(1234); bar=malloc(1234); /* do something that fills the memory that foo points to with garbage */ free(foo); baz=malloc(1234); Then there is no guarantees whatsoever that baz will not point to garbage. The memory that malloc() returns in the third call to malloc() will most likely be the same as that previously pointed to by foo and will still be filled with garbage. If your program needs zeroed memory you should use calloc() or do the zeroing yourself - malloc doesn't do it. What is guaranteed is that any garbage in the memory returned by malloc() will have been created by the same process, so that information is not leaked from another process in this way. In short memory from malloc() may or may not be pre-zeroed, but it is not a security problem in either case. -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 19:54:40 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 487A216A41C; Mon, 13 Jun 2005 19:54:40 +0000 (GMT) (envelope-from julian@elischer.org) Received: from bigwoop.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1650E43D1F; Mon, 13 Jun 2005 19:54:40 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by bigwoop.vicor-nb.com (Postfix) with ESMTP id 04CAB7A403; Mon, 13 Jun 2005 12:54:40 -0700 (PDT) Message-ID: <42ADE480.9040908@elischer.org> Date: Mon, 13 Jun 2005 12:54:40 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050423 X-Accept-Language: en, hu MIME-Version: 1.0 To: Christoph Hellwig References: <42ADC762.6010801@elischer.org> <20050613181435.GA3096@infradead.org> <42ADD253.4020606@samsco.org> <20050613184551.GA3853@infradead.org> <42ADD6AC.3060505@samsco.org> <20050613190224.GA4308@infradead.org> In-Reply-To: <20050613190224.GA4308@infradead.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , freebsd-hackers@freebsd.org, Scott Long , Apache Xie Subject: Re: contigmalloc() and mmap() 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, 13 Jun 2005 19:54:40 -0000 Christoph Hellwig wrote: >On Mon, Jun 13, 2005 at 12:55:40PM -0600, Scott Long wrote: > > >>>Lot's of driver use file->private to get at per-device data easily, >>>but that's just a shortcut. >>> >>> >>Ok, I thought that you were talking about per-process data being in the >>file descriptor. >> >> > >No, Linux has absolutely no concept of per-process data in driver, and >if you think of it that would be rather bogus anyway (e.g. a driver opening >the same device multiple times) > > though, some people use it for that purpose (e.g. in the original posting). it might not be such a bad idea.. I don't see why the device entrypoints shouldn't have that argument available.. (file descriptor by which we are getting here) As long as it can take account of the fact that not all accesses come via an FD (e.g mounted disks). From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 19:59:27 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 927FA16A41C; Mon, 13 Jun 2005 19:59:27 +0000 (GMT) (envelope-from SRS0+0b851353296582aa3a45+659+infradead.org+hch@pentafluge.srs.infradead.org) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3890E43D48; Mon, 13 Jun 2005 19:59:24 +0000 (GMT) (envelope-from SRS0+0b851353296582aa3a45+659+infradead.org+hch@pentafluge.srs.infradead.org) Received: from hch by pentafluge.infradead.org with local (Exim 4.43 #1 (Red Hat Linux)) id 1Dhv5Z-0001VI-NV; Mon, 13 Jun 2005 20:59:17 +0100 Date: Mon, 13 Jun 2005 20:59:17 +0100 From: Christoph Hellwig To: Julian Elischer Message-ID: <20050613195917.GA5710@infradead.org> References: <42ADC762.6010801@elischer.org> <20050613181435.GA3096@infradead.org> <42ADD253.4020606@samsco.org> <20050613184551.GA3853@infradead.org> <42ADD6AC.3060505@samsco.org> <20050613190224.GA4308@infradead.org> <42ADE480.9040908@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42ADE480.9040908@elischer.org> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Cc: Daniel Eischen , Scott Long , Apache Xie , freebsd-hackers@freebsd.org Subject: Re: contigmalloc() and mmap() 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, 13 Jun 2005 19:59:27 -0000 On Mon, Jun 13, 2005 at 12:54:40PM -0700, Julian Elischer wrote: > though, some people use it for that purpose (e.g. in the original posting). driver writers do all kinds of odd things ;-) > it might not be such a bad idea.. > I don't see why the device entrypoints shouldn't have that argument > available.. (file descriptor by which we are getting here) > As long as it can take account of the fact that not all accesses come > via an FD > (e.g mounted disks). disk drivers use a completely different set of entry points in Linux, and don't have access to per-fd data even in the case they're opened from userland. Character drivers to which this applies OTOH always get a valid struct file, it's guranteed as part of the driver API. From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 20:02:09 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CCA8916A41C; Mon, 13 Jun 2005 20:02:09 +0000 (GMT) (envelope-from SRS0+0b851353296582aa3a45+659+infradead.org+hch@pentafluge.srs.infradead.org) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 738C843D49; Mon, 13 Jun 2005 20:02:09 +0000 (GMT) (envelope-from SRS0+0b851353296582aa3a45+659+infradead.org+hch@pentafluge.srs.infradead.org) Received: from hch by pentafluge.infradead.org with local (Exim 4.43 #1 (Red Hat Linux)) id 1Dhv8J-0001XF-EJ; Mon, 13 Jun 2005 21:02:07 +0100 Date: Mon, 13 Jun 2005 21:02:07 +0100 From: Christoph Hellwig To: Julian Elischer Message-ID: <20050613200207.GA5823@infradead.org> References: <42ADC762.6010801@elischer.org> <20050613181435.GA3096@infradead.org> <42ADD253.4020606@samsco.org> <20050613184551.GA3853@infradead.org> <42ADD6AC.3060505@samsco.org> <20050613190224.GA4308@infradead.org> <42ADE480.9040908@elischer.org> <20050613195917.GA5710@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050613195917.GA5710@infradead.org> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Cc: Daniel Eischen , freebsd-hackers@freebsd.org, Scott Long , Apache Xie Subject: Re: contigmalloc() and mmap() 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, 13 Jun 2005 20:02:09 -0000 On Mon, Jun 13, 2005 at 08:59:17PM +0100, Christoph Hellwig wrote: > disk drivers use a completely different set of entry points in Linux, > and don't have access to per-fd data even in the case they're opened > from userland. Character drivers to which this applies OTOH always > get a valid struct file, it's guranteed as part of the driver API. That beeing said I'd suggest to not pass down the whole file struct if you want to add this feature for freebsd but just some well-defined API to store data in them. Giving driver writers less rope to shoot themselves improves averange driver quality significantly. We'll probably move towards such an API in Linux aswell one day, but it's a lot of work once drivers have started to do all kinds of nasty things. From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 21:02:40 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F17AD16A41C; Mon, 13 Jun 2005 21:02:39 +0000 (GMT) (envelope-from viro@www.linux.org.uk) Received: from parcelfarce.linux.theplanet.co.uk (parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7418843D55; Mon, 13 Jun 2005 21:02:39 +0000 (GMT) (envelope-from viro@www.linux.org.uk) Received: from viro by parcelfarce.linux.theplanet.co.uk with local (Exim 4.43) id 1Dhw5v-00080Z-T5; Mon, 13 Jun 2005 22:03:43 +0100 Date: Mon, 13 Jun 2005 22:03:43 +0100 From: Al Viro To: Scott Long Message-ID: <20050613210343.GL29811@parcelfarce.linux.theplanet.co.uk> References: <42ADC762.6010801@elischer.org> <20050613181435.GA3096@infradead.org> <42ADD253.4020606@samsco.org> <20050613184551.GA3853@infradead.org> <42ADD6AC.3060505@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42ADD6AC.3060505@samsco.org> User-Agent: Mutt/1.4.1i Sender: Al Viro Cc: Daniel Eischen , Julian Elischer , Apache Xie , freebsd-hackers@freebsd.org Subject: Re: contigmalloc() and mmap() 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, 13 Jun 2005 21:02:40 -0000 On Mon, Jun 13, 2005 at 12:55:40PM -0600, Scott Long wrote: > >Lot's of driver use file->private to get at per-device data easily, > >but that's just a shortcut. > > Ok, I thought that you were talking about per-process data being in the > file descriptor. Can't be done. FWIW, the main difference between FreeBSD and Linux in that area is that *all* files are vnode-based - we simply have pseudo-filesystems for pipes and sockets. So we have a single method (->release()) instead of multi-level scheme FreeBSD uses and unlike ->d_close() it does see struct file * (what with being a counterpart of ->fo_close()). While we are at it, is there any reason for passing struct thread * to ->fo_close() and then to vop_close()? 1) out of ->fo_close() instances only svr4_soo_close(), kqueue_close() and vn_closefile() look at the struct thread * in question. svr4_soo_close() panics if td is NULL (i.e. pass such descriptor in SCM_RIGHTS, make sure that it's garbage-collected by unp_gc() and watch closef(fp, NULL) panic the box). 2) vn_closefile() ends up passing it to VOP_CLOSE(). vop_close instances mostly ignore it or pass to other such instances. However, some do not - e.g. coda_close() panics if it gets NULL ap->a_td due to error = venus_close(vtomi(vp), &cp->c_fid, flag, cred, td->td_proc); AFAICS, the only reason for passing that pointer is kludge with controlling tty handling in spec_close() (or devfs_close() in -HEAD). And it doesn't look right, even ignoring the ugliness... From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 21:16:57 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9EDA216A41C for ; Mon, 13 Jun 2005 21:16:57 +0000 (GMT) (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 3F78A43D48 for ; Mon, 13 Jun 2005 21:16:57 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 26F7660F7; Mon, 13 Jun 2005 23:16:50 +0200 (CEST) Received: from xps.des.no (des.no [80.203.228.37]) by tim.des.no (Postfix) with ESMTP id 0A68E60F5; Mon, 13 Jun 2005 23:16:50 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id EED2233C49; Mon, 13 Jun 2005 23:16:49 +0200 (CEST) To: Mike Hunter References: <20050610224058.GA11336@malcolm.berkeley.edu> <86vf4lb110.fsf@xps.des.no> <20050613193150.GA75218@malcolm.berkeley.edu> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Mon, 13 Jun 2005 23:16:49 +0200 In-Reply-To: <20050613193150.GA75218@malcolm.berkeley.edu> (Mike Hunter's message of "Mon, 13 Jun 2005 12:31:50 -0700") Message-ID: <868y1eufcu.fsf@xps.des.no> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Learn: ham X-Spam-Score: -5.2/5.0 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on tim.des.no Cc: freebsd-hackers@freebsd.org Subject: Re: unitialized memory is all zeros...why not garbage instead? 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, 13 Jun 2005 21:16:57 -0000 Mike Hunter writes: > Is the pre-zeroing of malloc'd memory documented somewhere? By my reading > of the malloc manapge... malloc() does not pre-zero memory, but it hands you memory which has been pre-zeroed by the kernel unless you've used it before. Your test program makes only one malloc() call, so you get memory that has never been used before. > ...it seems like it's saying that malloc (as opposed to calloc) is NOT > pre-zeroed. Is there a different document I should be reading? No, but nowhere in the standard does it say that memory allocated with malloc() must contain non-zero garbage. If that is what you want, though, read the TUNING section in the malloc(3) man page. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 21:32:14 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C6D6A16A41C for ; Mon, 13 Jun 2005 21:32:14 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCACE43D53 for ; Mon, 13 Jun 2005 21:32:13 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix3-2.free.fr (Postfix) with ESMTP id AAEFDE399; Mon, 13 Jun 2005 22:44:37 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id A5B9C407E; Mon, 13 Jun 2005 22:44:16 +0200 (CEST) Date: Mon, 13 Jun 2005 22:44:16 +0200 From: Jeremie Le Hen To: "Devon H. O'Dell" Message-ID: <20050613204416.GJ30017@obiwan.tataz.chchile.org> References: <42ADD249.7020709@dnainternet.net> <20050613184128.GA16980@gremlin.foo.is> <42ADD3D5.6080103@offmyserver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42ADD3D5.6080103@offmyserver.com> User-Agent: Mutt/1.5.9i Cc: Baldur Gislason , freebsd-hackers@freebsd.org Subject: Re: prioritizing small ip packets? 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, 13 Jun 2005 21:32:14 -0000 Hi Devon, hi Baldur, (this thread would better seat on -net@, IMO) > >>So, i haven't found a way to make this happen, i googled > >>for it but didn't find anything. Does PF or IPFW have this > >>feature? > > I'm not sure the rationale is appropriate, though. You should be more > worried about prioritizing ACKs if this is an asynchronous low-speed > connection. This is true, prioritizing ACKs is very useful when you want to download with full speed while uploading. But I tend to agree with Baldur's idea too : I give HTTP and DNS requests as well as interactive SSH session (TOS field set to "low delay") a heavy weight in order to have them practically unaffected by a big mail delivery or a scp. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 21:33:57 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9424316A41C for ; Mon, 13 Jun 2005 21:33:57 +0000 (GMT) (envelope-from mhunter@malcolm.berkeley.edu) Received: from malcolm.berkeley.edu (malcolm.Berkeley.EDU [128.32.206.239]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4615243D1F for ; Mon, 13 Jun 2005 21:33:57 +0000 (GMT) (envelope-from mhunter@malcolm.berkeley.edu) Received: from malcolm.berkeley.edu (localhost [127.0.0.1]) by malcolm.berkeley.edu (8.13.3/8.13.3) with ESMTP id j5DLXtOM079553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Jun 2005 14:33:55 -0700 (PDT) (envelope-from mhunter@malcolm.berkeley.edu) Received: (from mhunter@localhost) by malcolm.berkeley.edu (8.13.3/8.13.3/Submit) id j5DLXtfm079552; Mon, 13 Jun 2005 14:33:55 -0700 (PDT) (envelope-from mhunter) Date: Mon, 13 Jun 2005 14:33:55 -0700 From: Mike Hunter To: Dag-Erling =?unknown-8bit?Q?Sm=F8rgrav?= , freebsd-hackers@freebsd.org Message-ID: <20050613213354.GA78702@malcolm.berkeley.edu> References: <20050610224058.GA11336@malcolm.berkeley.edu> <86vf4lb110.fsf@xps.des.no> <20050613193150.GA75218@malcolm.berkeley.edu> <20050613195026.GA90010@falcon.midgard.homeip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050613195026.GA90010@falcon.midgard.homeip.net> User-Agent: Mutt/1.5.6i X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (malcolm.berkeley.edu [127.0.0.1]); Mon, 13 Jun 2005 14:33:55 -0700 (PDT) Cc: Subject: Re: unitialized memory is all zeros...why not garbage instead? 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, 13 Jun 2005 21:33:57 -0000 On Jun 13, "Erik Trulsson" wrote: > > Is the pre-zeroing of malloc'd memory documented somewhere? By my reading > > of the malloc manapge... > > > > The calloc() function allocates space for number objects, each size > > bytes in length. The result is identical to calling malloc() with an > > argument of ``number * size'', with the exception that the allocated > > memory is explicitly initialized to zero bytes. > > > > ...it seems like it's saying that malloc (as opposed to calloc) is NOT > > pre-zeroed. Is there a different document I should be reading? > > Note that this pre-zeroing is not done by malloc, but is done by the > kernel before it hands over memory to a process. Memory is not necessarily > returned to the system when free() is called, but is often retained > within the process and reused by the next malloc(). > > > This means that if you have a sequence like the following: > > foo=malloc(1234); > bar=malloc(1234); > /* do something that fills the memory that foo points to with garbage > */ > free(foo); > baz=malloc(1234); > > Then there is no guarantees whatsoever that baz will not point to > garbage. The memory that malloc() returns in the third call to > malloc() will most likely be the same as that previously pointed to by > foo and will still be filled with garbage. > > If your program needs zeroed memory you should use calloc() or do the > zeroing yourself - malloc doesn't do it. > > What is guaranteed is that any garbage in the memory returned by > malloc() will have been created by the same process, so that > information is not leaked from another process in this way. > > In short memory from malloc() may or may not be pre-zeroed, but it is > not a security problem in either case. I got it. Thanks! This all stemmed from a discussion I was having with a coworker about vmware. I wondered aloud if information might leak from one VM to another via malloc. Whatever the answer is to that question (it's a linux VM server), I can now say I understand how FreeBSD behaves. Thanks again! Mike From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 14 00:17:23 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E95F416A41C for ; Tue, 14 Jun 2005 00:17:22 +0000 (GMT) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.swip.net [212.247.154.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C7C743D4C for ; Tue, 14 Jun 2005 00:17:22 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: Y1QAsIk9O44SO+J/q9KNyQ== Received: from mp-216-40-125.daxnet.no ([193.216.40.125] verified) by mailfe08.swip.net (CommuniGate Pro SMTP 4.3.2) with ESMTP id 196498115; Tue, 14 Jun 2005 02:17:20 +0200 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Tue, 14 Jun 2005 02:18:10 +0200 User-Agent: KMail/1.7 References: <200506131412.38967.hselasky@c2i.net> <200506131758.25671.hselasky@c2i.net> <20050613162743.GA769@britannica.bec.de> In-Reply-To: <20050613162743.GA769@britannica.bec.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506140218.11844.hselasky@c2i.net> Cc: Joerg Sonnenberger Subject: Re: Obvious bug in /sys/i386/include/bus.h (was: bus_at386.h) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hselasky@c2i.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2005 00:17:23 -0000 On Monday 13 June 2005 18:27, Joerg Sonnenberger wrote: > On Mon, Jun 13, 2005 at 05:58:24PM +0200, Hans Petter Selasky wrote: > > static void > > filter(struct fifo *f) > > { > > do { > > if(!f->len) > > { > > if(f->m) ...; > > > > f->m = get_mbuf(); > > if(!f->m) break; > > > > f->len = m->m_len; > > f->ptr = m->m_data; > > } > > > > /* f->Z_chip is the maximum transfer length */ > > > > io_len = min(f->len, f->Z_chip); > > if (io_len == 0) > continue; > > > bus_space_write_multi_1(t,h,xxx,f->ptr,io_len); > > > > f->len -= io_len; > > f->Z_chip -= io_len; > > f->ptr += io_len; > > > > } while(Z_chip); > > } > > [...] > > > Adding that extra check for zero transfer length is not going to affect > > performance at all. If one does that using "C", the compiler can optimize > > away that "if(count) ..." when "count" is a constant. Besides the i386 > > machine instructions "ins" and "outs" already exhibit that behaviour. > > The compiler can only optimize it away if it is known to be a constant. > But thinking again about it, it should be documented at least whether > a count of 0 is allowed or not. I think it makes more sense to not allow > it, but others (you included) might disagree. Why? If a count of zero is not allowed, then "bus_space_xxx()" should panic on count equal to zero and not freeze the system, so that the user is able to find out what is wrong: #if defined(XXX) if(count == 0) panic("not allowed"); #endif But that is just stupid, why not just return: #if defined(XXX) if(count == 0) return; #endif And then I can put: #define XXX in my code before including "bus.h". Instead of creating wrappers, just to be sure: #define bus_space_read_multi_1(t,h,off,ptr,count) \ { if(count) bus_space_read_multi_1(t,h,off,ptr,count); } Because this is really specific to i386 and amd64. If you look at "alpha", "sparc64" and "ia64" they all use "while(count--) ...". So I think the one that wrote that code did a mistake. My theory is that he or her copied: static __inline void insb(u_int port, void *addr, size_t cnt) { __asm __volatile("cld; rep; insb" : "+D" (addr), "+c" (cnt) : "d" (port) : "memory"); } And forgot to add that extra check for count equal to zero, when converting "rep" into "loop"! --HPS From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 14 00:49:36 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF4CB16A41C for ; Tue, 14 Jun 2005 00:49:36 +0000 (GMT) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.swip.net [212.247.154.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 624D343D53 for ; Tue, 14 Jun 2005 00:49:36 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: Y1QAsIk9O44SO+J/q9KNyQ== Received: from mp-217-209-246.daxnet.no ([193.217.209.246] verified) by mailfe05.swip.net (CommuniGate Pro SMTP 4.3.2) with ESMTP id 197706280; Tue, 14 Jun 2005 02:49:33 +0200 From: Hans Petter Selasky To: "M. Warner Losh" Date: Tue, 14 Jun 2005 02:50:24 +0200 User-Agent: KMail/1.7 References: <200506131412.38967.hselasky@c2i.net> <20050613.172307.81090793.imp@bsdimp.com> In-Reply-To: <20050613.172307.81090793.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506140250.26275.hselasky@c2i.net> Cc: freebsd-hackers@freebsd.org Subject: Re: Obvious bug in /sys/i386/include/bus.h X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hselasky@c2i.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2005 00:49:37 -0000 On Tuesday 14 June 2005 01:23, M. Warner Losh wrote: > In message: <200506131412.38967.hselasky@c2i.net> > > Hans Petter Selasky writes: > : So can someone have this fixed, or is there a reason not to fix it. The > : one who wrote the code has done the same mistake with every one of the > : bus_space_XXXX that does memory mapped I/O. It currently breaks my > : drivers. > > One isn't supposed to call these routines with count == 0. One could > say your drivers are broken :-) > > Back when these were written, small optimizations like this were made > to make things go faster. Now that cache sizes are bigger, a few > extra instructions likely wouldn't affect things too much. Best to > measure the effects of your proposed changes on real workloads... These functions are used to move smaller amounts of data. Larger amounts of data should be moved using DMA. In this case functionality is more important than performance?! -- HPS From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 14 01:08:37 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 33CC116A41C for ; Tue, 14 Jun 2005 01:08:37 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F24143D49 for ; Tue, 14 Jun 2005 01:08:36 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.13.4/8.13.4) with ESMTP id j5E18Fxb003216; Tue, 14 Jun 2005 10:38:16 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-hackers@freebsd.org Date: Tue, 14 Jun 2005 10:38:11 +0930 User-Agent: KMail/1.8 References: <42ADD249.7020709@dnainternet.net> <42ADD3D5.6080103@offmyserver.com> <20050613204416.GJ30017@obiwan.tataz.chchile.org> In-Reply-To: <20050613204416.GJ30017@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1365293.5FHxlCvz8t"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200506141038.12034.doconnor@gsoft.com.au> X-Spam-Score: -2.4 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.51 on 203.31.81.10 Cc: Baldur Gislason , Jeremie Le Hen , "Devon H. O'Dell" Subject: Re: prioritizing small ip packets? 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, 14 Jun 2005 01:08:37 -0000 --nextPart1365293.5FHxlCvz8t Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tue, 14 Jun 2005 06:14, Jeremie Le Hen wrote: > This is true, prioritizing ACKs is very useful when you want to download > with full speed while uploading. But I tend to agree with Baldur's idea > too : I give HTTP and DNS requests as well as interactive SSH session > (TOS field set to "low delay") a heavy weight in order to have them > practically unaffected by a big mail delivery or a scp. There is still a problem whereby a large packet in transit can't be=20 interrupted by a smaller packet. One solution I saw for this when doing VoIP over ADSL was using PPPoE and=20 setting it up for multi-link over one link. The packets get fragmented into= =20 smaller pieces and the fragments of smaller packets get higher priorities. Not sure how much over head it cost, but ISTR it wasn't too bad. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1365293.5FHxlCvz8t Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCri385ZPcIHs/zowRAlWsAJ4o+rHIG7OLn30dz3tcGF8Bvc45wQCfbN/X Lx+rY29F5o2vOY6yxA26xIE= =C5MR -----END PGP SIGNATURE----- --nextPart1365293.5FHxlCvz8t-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 14 01:26:55 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 521D216A41C for ; Tue, 14 Jun 2005 01:26:55 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-66.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0DCF343D49 for ; Tue, 14 Jun 2005 01:26:54 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j5DNM1Lb098405; Mon, 13 Jun 2005 17:22:02 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 13 Jun 2005 17:23:07 -0600 (MDT) Message-Id: <20050613.172307.81090793.imp@bsdimp.com> To: hselasky@c2i.net From: "M. Warner Losh" In-Reply-To: <200506131412.38967.hselasky@c2i.net> References: <200506131412.38967.hselasky@c2i.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Obvious bug in /sys/i386/include/bus.h 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, 14 Jun 2005 01:26:55 -0000 In message: <200506131412.38967.hselasky@c2i.net> Hans Petter Selasky writes: : So can someone have this fixed, or is there a reason not to fix it. The one : who wrote the code has done the same mistake with every one of the : bus_space_XXXX that does memory mapped I/O. It currently breaks my drivers. One isn't supposed to call these routines with count == 0. One could say your drivers are broken :-) Back when these were written, small optimizations like this were made to make things go faster. Now that cache sizes are bigger, a few extra instructions likely wouldn't affect things too much. Best to measure the effects of your proposed changes on real workloads... Warner From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 14 01:56:48 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E1AA16A41C for ; Tue, 14 Jun 2005 01:56:48 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-66.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42B8243D1F for ; Tue, 14 Jun 2005 01:56:48 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j5E1ua3a099456; Mon, 13 Jun 2005 19:56:38 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 13 Jun 2005 19:57:42 -0600 (MDT) Message-Id: <20050613.195742.07655207.imp@bsdimp.com> To: hselasky@c2i.net From: "M. Warner Losh" In-Reply-To: <200506140250.26275.hselasky@c2i.net> References: <200506131412.38967.hselasky@c2i.net> <20050613.172307.81090793.imp@bsdimp.com> <200506140250.26275.hselasky@c2i.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Obvious bug in /sys/i386/include/bus.h 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, 14 Jun 2005 01:56:48 -0000 In message: <200506140250.26275.hselasky@c2i.net> Hans Petter Selasky writes: : On Tuesday 14 June 2005 01:23, M. Warner Losh wrote: : > In message: <200506131412.38967.hselasky@c2i.net> : > : > Hans Petter Selasky writes: : > : So can someone have this fixed, or is there a reason not to fix it. The : > : one who wrote the code has done the same mistake with every one of the : > : bus_space_XXXX that does memory mapped I/O. It currently breaks my : > : drivers. : > : > One isn't supposed to call these routines with count == 0. One could : > say your drivers are broken :-) : > : > Back when these were written, small optimizations like this were made : > to make things go faster. Now that cache sizes are bigger, a few : > extra instructions likely wouldn't affect things too much. Best to : > measure the effects of your proposed changes on real workloads... : : These functions are used to move smaller amounts of data. Larger amounts of : data should be moved using DMA. In this case functionality is more important : than performance?! At the time, programmed I/O was still big, and sometimes big amounts of data were moved with them.... I'm not saying we can't make the interfaces more forgiving. NetBSD's implementation of these functions also have this flaw... The code looks identical, and the histories of the file leads me to believe that they were adopted unchanged from the original NetBSD implementation 7 or 8 years ago... Anyway, please view my note as a historical 'this is why it is the way it is' not a 'it must be this way because'. Warner From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 14 02:24:55 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D7D7D16A41C for ; Tue, 14 Jun 2005 02:24:55 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 782A043D1F for ; Tue, 14 Jun 2005 02:24:55 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j5E2Tbt3008154; Mon, 13 Jun 2005 20:29:37 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42AE3FEE.6040207@samsco.org> Date: Mon, 13 Jun 2005 20:24:46 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M. Warner Losh" References: <200506131412.38967.hselasky@c2i.net> <20050613.172307.81090793.imp@bsdimp.com> In-Reply-To: <20050613.172307.81090793.imp@bsdimp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: freebsd-hackers@freebsd.org, hselasky@c2i.net Subject: Re: Obvious bug in /sys/i386/include/bus.h 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, 14 Jun 2005 02:24:56 -0000 M. Warner Losh wrote: > In message: <200506131412.38967.hselasky@c2i.net> > Hans Petter Selasky writes: > : So can someone have this fixed, or is there a reason not to fix it. The one > : who wrote the code has done the same mistake with every one of the > : bus_space_XXXX that does memory mapped I/O. It currently breaks my drivers. > > One isn't supposed to call these routines with count == 0. One could > say your drivers are broken :-) > > Back when these were written, small optimizations like this were made > to make things go faster. Now that cache sizes are bigger, a few > extra instructions likely wouldn't affect things too much. Best to > measure the effects of your proposed changes on real workloads... > > Warner I'm torn between saying, "this is the kernel and the kernel is an unforgiving mistress," and "defensive programming is good." We still have viable and popular platforms that are based on i486, so I'd rather not see us unwind the small optimizations that are still valid there. Scott From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 14 02:53:48 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B9AE16A41C for ; Tue, 14 Jun 2005 02:53:48 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-66.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id F22FA43D49 for ; Tue, 14 Jun 2005 02:53:47 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j5E2radl000232; Mon, 13 Jun 2005 20:53:36 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 13 Jun 2005 20:54:42 -0600 (MDT) Message-Id: <20050613.205442.97297023.imp@bsdimp.com> To: hselasky@c2i.net From: "M. Warner Losh" In-Reply-To: <200506131758.25671.hselasky@c2i.net> References: <200506131412.38967.hselasky@c2i.net> <20050613124427.GD1343@britannica.bec.de> <200506131758.25671.hselasky@c2i.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, joerg@britannica.bec.de Subject: Re: Obvious bug in /sys/i386/include/bus.h 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, 14 Jun 2005 02:53:48 -0000 In message: <200506131758.25671.hselasky@c2i.net> Hans Petter Selasky writes: : Where is it documented? NetBSD's man page: ... These functions will never fail. If they would fail (e.g., because of an argument error), that indicates a software bug which should cause a panic. In that case, they will never return. ... Since FreeBSD doesn't have one yet, that's as good as can be expected. Warner From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 14 02:56:46 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1292616A41C for ; Tue, 14 Jun 2005 02:56:46 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-66.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC3AD43D49 for ; Tue, 14 Jun 2005 02:56:45 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j5E2tGX4000252; Mon, 13 Jun 2005 20:55:16 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 13 Jun 2005 20:56:22 -0600 (MDT) Message-Id: <20050613.205622.117024773.imp@bsdimp.com> To: joerg@britannica.bec.de From: "M. Warner Losh" In-Reply-To: <20050613162743.GA769@britannica.bec.de> References: <20050613124427.GD1343@britannica.bec.de> <200506131758.25671.hselasky@c2i.net> <20050613162743.GA769@britannica.bec.de> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Obvious bug in /sys/i386/include/bus.h 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, 14 Jun 2005 02:56:46 -0000 In message: <20050613162743.GA769@britannica.bec.de> Joerg Sonnenberger writes: : The compiler can only optimize it away if it is known to be a constant. : But thinking again about it, it should be documented at least whether : a count of 0 is allowed or not. I think it makes more sense to not allow : it, but others (you included) might disagree. I'd be happy with commitable bus_space.9, reguardless of how this discussion turns out. Warner From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 14 02:59:53 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D74AB16A41C for ; Tue, 14 Jun 2005 02:59:53 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-66.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8EAB343D1F for ; Tue, 14 Jun 2005 02:59:53 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j5E2vVah000263; Mon, 13 Jun 2005 20:57:32 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 13 Jun 2005 20:58:38 -0600 (MDT) Message-Id: <20050613.205838.56966326.imp@bsdimp.com> To: mhunter@ack.berkeley.edu From: "M. Warner Losh" In-Reply-To: <20050613193150.GA75218@malcolm.berkeley.edu> References: <20050610224058.GA11336@malcolm.berkeley.edu> <86vf4lb110.fsf@xps.des.no> <20050613193150.GA75218@malcolm.berkeley.edu> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: des@des.no, freebsd-hackers@freebsd.org Subject: Re: unitialized memory is all zeros...why not garbage instead? 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, 14 Jun 2005 02:59:54 -0000 In message: <20050613193150.GA75218@malcolm.berkeley.edu> Mike Hunter writes: : Is the pre-zeroing of malloc'd memory documented somewhere? By my reading : of the malloc manapge... : : The calloc() function allocates space for number objects, each size : bytes in length. The result is identical to calling malloc() with an : argument of ``number * size'', with the exception that the allocated : memory is explicitly initialized to zero bytes. : : ...it seems like it's saying that malloc (as opposed to calloc) is NOT : pre-zeroed. Is there a different document I should be reading? The memory isn't given to the process by malloc. It is given to it by some other means. That memory is zeroed for security reasons. The first time malloc returns the memory, with our current implementation, it will be all zeros. After that, all bets are off with out implementation. One should not rely on this behavior because one never knows when the first malloc happens, nor if our malloc might start writing into the memory it is about to return... Warner From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 14 03:50:50 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D69D116A41C for ; Tue, 14 Jun 2005 03:50:50 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-66.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 911F643D48 for ; Tue, 14 Jun 2005 03:50:50 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j5E3m5oE000935; Mon, 13 Jun 2005 21:48:06 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 13 Jun 2005 21:49:12 -0600 (MDT) Message-Id: <20050613.214912.38044070.imp@bsdimp.com> To: joerg@britannica.bec.de From: "M. Warner Losh" In-Reply-To: <20050613.205622.117024773.imp@bsdimp.com> References: <200506131758.25671.hselasky@c2i.net> <20050613162743.GA769@britannica.bec.de> <20050613.205622.117024773.imp@bsdimp.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Obvious bug in /sys/i386/include/bus.h 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, 14 Jun 2005 03:50:50 -0000 In message: <20050613.205622.117024773.imp@bsdimp.com> "M. Warner Losh" writes: : In message: <20050613162743.GA769@britannica.bec.de> : Joerg Sonnenberger writes: : : The compiler can only optimize it away if it is known to be a constant. : : But thinking again about it, it should be documented at least whether : : a count of 0 is allowed or not. I think it makes more sense to not allow : : it, but others (you included) might disagree. : : I'd be happy with commitable bus_space.9, reguardless of how this : discussion turns out. OK. Just committed one. It is silent on the issue of 0 byte counts :-) Warner From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 14 06:36:17 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3CD0D16A41C for ; Tue, 14 Jun 2005 06:36:17 +0000 (GMT) (envelope-from NKoch@demig.de) Received: from server.absolute-media.de (server.absolute-media.de [213.239.231.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id A488B43D49 for ; Tue, 14 Jun 2005 06:36:16 +0000 (GMT) (envelope-from NKoch@demig.de) Received: from localhost (unknown [127.0.0.1]) by server.absolute-media.de (Postfix) with ESMTP id A247A84FDB; Tue, 14 Jun 2005 08:36:14 +0200 (CEST) Received: from server.absolute-media.de ([127.0.0.1]) by localhost (server [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15214-04; Tue, 14 Jun 2005 08:36:10 +0200 (CEST) Received: from firewall.demig (p50839636.dip0.t-ipconnect.de [80.131.150.54]) by server.absolute-media.de (Postfix) with ESMTP id C18287EFF5; Tue, 14 Jun 2005 08:36:09 +0200 (CEST) Received: from ws-ew-3 (ws-ew-3.w2kdemig [192.168.1.72]) by firewall.demig (8.13.4/8.13.1) with SMTP id j5E6YCiJ021562; Tue, 14 Jun 2005 08:34:12 +0200 (CEST) (envelope-from NKoch@demig.de) From: "Norbert Koch" To: "Maksim Yevmenkin" Date: Tue, 14 Jun 2005 08:34:12 +0200 Message-ID: <001e01c570ab$13e1a280$4801a8c0@ws-ew-3.W2KDEMIG> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <42ADB4F8.5040701@savvis.net> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at absolute-media.de Cc: "Freebsd-Hackers@Freebsd.Org" Subject: RE: using vkbd device 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, 14 Jun 2005 06:36:17 -0000 > > seems to work, although I still have some stability issues with > > dynamically attaching/detaching a usb keyboard. For your reference I > > would you share with us what sort of issues you are having? feel free to > move this into private email if you are not comfortable discussing it on > public mailing list. Hello Max, I'm not yet finished with that issue, but it is _not_ related to kbdmux. Here is my scenario: An embedded device with a builtin at type keyboard and a usb connector. From usbd I call attach/detach scripts for ukbd. Attach: kbdcontrol -K kbdmuxctl -m /dev/kbd2 -ak 0 # at kbdmuxctl -m /dev/kbd2 -ak 1 # usb kbdcontrol -k /dev/kbd2 kbdcontrol -l Detach: kbdcontrol -K kbdmuxctl -m /dev/kbd2 -rk 0 # at kbdmuxctl -m /dev/kbd2 -rk 1 # usb kbdcontrol -k /dev/kbd0 kbdcontrol -l The ukbd-specific detaching only works, because I implemented something in ukbd.c, that Hans Petter Selasky [hselasky@c2i.net] suggested in thread "usbd.conf: detach ukbd". (See the patch files, I posted there) When the kernel panics, it does this in usb0 kernel thread. I figured out that this is only related to connecting/disconnecting the usb keyboard. It panics without kbdmux loaded and it panics with unmodified ukbd.c. So I'll have to try to remote debug it, as my embedded device has no swap space at all and so no core dump device (256MB flash/256 MD dram). > no problem. in one of your previous emails you have been concerned about > possible keyboard interrupt miss (in vkbd(4)). kbdmux(4) have the same > issue. is that something you just did not fix yet, or it is not a > problem anymore? in my local tree a added an extra callout that goes 10 > times a second and queues interrupt if needed. also i'm curious why do > you use splhigh() instead of spltty()? is this an issue with usb? (not > sure which spl level usb runs on in 4.x) I didn't see any missed keys. I just think it could happen in theory. There is no special reason for using splhigh(). Usb has - as far as I know - its own splusb(). I'm not a kernel expert, so I'm not sure, if spltty() would be ok here. The thing I not yet understand is, in what context will taskqueue_swi be executed? Is it some process context? Norbert From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 14 08:21:47 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C4A416A41F for ; Tue, 14 Jun 2005 08:21:47 +0000 (GMT) (envelope-from french.linuxian@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id DAA5443D1F for ; Tue, 14 Jun 2005 08:21:44 +0000 (GMT) (envelope-from french.linuxian@gmail.com) Received: by zproxy.gmail.com with SMTP id 12so132364nzp for ; Tue, 14 Jun 2005 01:21:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=hLSJbu4oo5mDsmqeHhUxDpWx67ECiTPlRk9sqboqrDCPrr7BEe6sL/R1X7suKx2t3FaN4MPuJq3q13dbSCghy4yuj1ifUZxO99JbTHx6DIJQmaZyF1Sjq/gYQ27ahKeq9SuLnzOGeVXuwFu0vsTuEFh1GAiVjKTbaBweii/hL5o= Received: by 10.36.222.24 with SMTP id u24mr3505013nzg; Tue, 14 Jun 2005 01:21:41 -0700 (PDT) Received: by 10.36.58.12 with HTTP; Tue, 14 Jun 2005 01:21:41 -0700 (PDT) Message-ID: <37273927050614012154fdb80b@mail.gmail.com> Date: Tue, 14 Jun 2005 04:21:41 -0400 From: Aziz Kezzou To: freebsd-hackers , freebsd-net Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Subject: FreeBSD Memory Management questions ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Aziz Kezzou List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2005 08:21:47 -0000 Hi all, I have two questions concerning FreeBSD Memory management : 1 - Right now to access the memory address space of a user process from kernel mode, I only have to set, on x86 systems, the register CR3 to the right value. How can I do that on other architectures ? is there an architecture-independant way of doing that ? 2- I have noticed that while in kernel mode the value of CR3 is equal to that of the user process beeing interrupted. Doesn't the kernel supposed to have its "own" page-directory, i.e it's own CR3 value ? or is kernel virtual address resolution does not go through CR3 at all ? =20 Thanks for your help, -aziz From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 14 10:06:47 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A368E16A41C for ; Tue, 14 Jun 2005 10:06:47 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail26.syd.optusnet.com.au (mail26.syd.optusnet.com.au [211.29.133.167]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2544043D58 for ; Tue, 14 Jun 2005 10:06:46 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) by mail26.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j5EA6ikJ003235 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 14 Jun 2005 20:06:45 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.10/8.12.10) with ESMTP id j5EA6hRx054021; Tue, 14 Jun 2005 20:06:44 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost) by cirb503493.alcatel.com.au (8.12.10/8.12.9/Submit) id j5EA6h5U054020; Tue, 14 Jun 2005 20:06:43 +1000 (EST) (envelope-from pjeremy) Date: Tue, 14 Jun 2005 20:06:42 +1000 From: Peter Jeremy To: Aziz Kezzou Message-ID: <20050614100642.GC50157@cirb503493.alcatel.com.au> References: <37273927050614012154fdb80b@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <37273927050614012154fdb80b@mail.gmail.com> User-Agent: Mutt/1.4.2i Cc: freebsd-hackers Subject: Re: FreeBSD Memory Management questions ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2005 10:06:47 -0000 [-net dropped: This is not off-topic there] On Tue, 2005-Jun-14 04:21:41 -0400, Aziz Kezzou wrote: >1 - Right now to access the memory address space of a user process >from kernel mode, I only have to set, on x86 systems, the register CR3 >to the right value. How can I do that on other architectures ? is >there an architecture-independant way of doing that ? The only supported way to access user memory from the kernel is via the copy(9), fetch(9) or store(9) functions. These functions include checks to ensure that the userland address is valid and resident. Playing with CR3 (or any other memory management control registers) is not supported outside the MD VM subsystem. >2- I have noticed that while in kernel mode the value of CR3 is equal >to that of the user process beeing interrupted. Doesn't the kernel >supposed to have its "own" page-directory, i.e it's own CR3 value ? >or is kernel virtual address resolution does not go through CR3 at >all ? Re-loading CR3 flushes the TLB. This makes it a quite expensive operation which should be avoided unless necessary. Instead, both the kernel and userland share the same flat address space and use different segment selectors to control access to the kernel space. -- Peter Jeremy From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 14 12:08:48 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 063A916A41C for ; Tue, 14 Jun 2005 12:08:48 +0000 (GMT) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from comsys.ntu-kpi.kiev.ua (comsys.ntu-kpi.kiev.ua [195.245.194.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id D60ED43D1D for ; Tue, 14 Jun 2005 12:08:37 +0000 (GMT) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from pm514-9.comsys.ntu-kpi.kiev.ua (pm514-9.comsys.ntu-kpi.kiev.ua [10.18.54.109]) (authenticated bits=0) by comsys.ntu-kpi.kiev.ua (8.12.10/8.12.10) with ESMTP id j5ECEE5O040194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Jun 2005 15:14:16 +0300 (EEST) Received: by pm514-9.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1000) id B30E32A5; Tue, 14 Jun 2005 15:07:06 +0300 (EEST) Date: Tue, 14 Jun 2005 15:07:06 +0300 From: Andrey Simonenko To: Aziz Kezzou Message-ID: <20050614120706.GA539@pm514-9.comsys.ntu-kpi.kiev.ua> References: <37273927050614012154fdb80b@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <37273927050614012154fdb80b@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-Spam-Status: No, score=-4.5 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on comsys.ntu-kpi.kiev.ua X-Virus-Scanned: ClamAV 0.82/921/Wed Jun 8 11:51:44 2005 on comsys.ntu-kpi.kiev.ua X-Virus-Status: Clean Cc: freebsd-hackers Subject: Re: FreeBSD Memory Management questions ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2005 12:08:48 -0000 On Tue, Jun 14, 2005 at 04:21:41AM -0400, Aziz Kezzou wrote: > > 1 - Right now to access the memory address space of a user process > from kernel mode, I only have to set, on x86 systems, the register CR3 > to the right value. How can I do that on other architectures ? is > there an architecture-independant way of doing that ? Addition to the previous answer. It is also possible to temporally map several pages of user memory into the kernel address space. Check pmap_qenter(9) and see physio -> vmapbuf, for example, how to use it. Another method, it is possible to COW a single user page and then use it in the kernel, but with this method an user process will not see any modification in this page made by the kernel and vice versa. Check socow_setup -> vm_page_cowsetup, for example, how to use it. From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 12:41:35 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EBBEB16A41C for ; Mon, 13 Jun 2005 12:41:35 +0000 (GMT) (envelope-from tinguely@casselton.net) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98C4643D1F for ; Mon, 13 Jun 2005 12:41:35 +0000 (GMT) (envelope-from tinguely@casselton.net) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.12.11/8.12.11) with ESMTP id j5DCfXAn026936; Mon, 13 Jun 2005 07:41:33 -0500 (CDT) (envelope-from tinguely@casselton.net) Received: (from tinguely@localhost) by casselton.net (8.12.11/8.12.11/Submit) id j5DCfXL5026935; Mon, 13 Jun 2005 07:41:33 -0500 (CDT) (envelope-from tinguely) Date: Mon, 13 Jun 2005 07:41:33 -0500 (CDT) From: Mark Tinguely Message-Id: <200506131241.j5DCfXL5026935@casselton.net> To: apachexm@hotmail.com, freebsd-hackers@freebsd.org In-Reply-To: X-Spam-Status: No, score=1.4 required=5.0 tests=REPLY_TO_EMPTY autolearn=no version=3.0.3 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on ccn.casselton.net X-Mailman-Approved-At: Tue, 14 Jun 2005 12:36:45 +0000 Cc: Subject: Re: contigmalloc() and mmap() 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, 13 Jun 2005 12:41:36 -0000 > I browsed kernel tree, I found those drivers which use contigmalloc() and > contigfree() always call these two kernel interfaces in _attach() and > _detach(), but in my driver, I call contigmalloc() in ioctl(), and call > contigfree() in a callout function which is set by callout_reset(). > What I want to know is if contigmalloc() and contigfree() can only be used > under some conditions? Allocating early prevents unfullfilled requests due to fragmentation of the physical memory. I believe starting in FreeBSD 5.x, contigmalloc() started to fill physical memory requests from the higher memory locations to help with fragmentation. FreeBSD 5/6 has a Unified Meory Allocator that helps allocate/free cycles. > And recently, I modified my driver, I allocated a big chunk of contiguous > physical memory using contigmalloc() in the driver's _attach() function, > and I use a simple first-fit algorithm to manage this memory myself, which > mean in ioctl() I use my allocate/deallocate functions instead of > contigmalloc(), > in _detach() function contigfree() is called to free the big chunk of > memory, > no panic again, but sometimes, process cannot get the correct data from > the mmaped memory. I don't know why. Are you sure that you are allocating page length request on page boundaries? Are you checking the success/failure of the allocation? Your page faults before implementing your own allocation sounds like you did not check the return status from contigmalloc() and were dereferencing a pointer on page 0. --Mark Tinguely. From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 14 12:44:41 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0BE2B16A41C for ; Tue, 14 Jun 2005 12:44:41 +0000 (GMT) (envelope-from gerarra@tin.it) Received: from vsmtp14.tin.it (vsmtp14.tin.it [212.216.176.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5E3543D1D for ; Tue, 14 Jun 2005 12:44:40 +0000 (GMT) (envelope-from gerarra@tin.it) Received: from ims3a.cp.tin.it (192.168.70.103) by vsmtp14.tin.it (7.0.027) id 429D6F26005562B2; Tue, 14 Jun 2005 14:44:39 +0200 Received: from [192.168.70.181] by ims3a.cp.tin.it with HTTP; Tue, 14 Jun 2005 14:44:38 +0200 Date: Tue, 14 Jun 2005 14:44:38 +0200 Message-ID: <429C8E8F00018903@ims3a.cp.tin.it> In-Reply-To: <000001c57016$8e4b0600$4801a8c0@ws-ew-3.W2KDEMIG> From: gerarra@tin.it To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable X-Originating-IP: 151.100.38.110 Cc: NKoch@demig.de Subject: RE: Obvious bug in /sys/i386/include/bus.h (was: bus_at386.h) 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, 14 Jun 2005 12:44:41 -0000 >No, it's a correct method to set/reset the zero flag: > (X | X) =3D=3D X just as (X & X) =3D=3D X > Yes but it stores result in ecx(using or, really, is not a problem)... ho= wever jecxz just is 2 bytes sized while or + jmp is 4 bytes. It means lesser FD= E latency time and the pseudocode is enough similar. greeting, rookie From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 14 13:11:17 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D1AE16A41C for ; Tue, 14 Jun 2005 13:11:17 +0000 (GMT) (envelope-from NKoch@demig.de) Received: from server.absolute-media.de (server.absolute-media.de [213.239.231.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id E71F843D1F for ; Tue, 14 Jun 2005 13:11:16 +0000 (GMT) (envelope-from NKoch@demig.de) Received: from localhost (unknown [127.0.0.1]) by server.absolute-media.de (Postfix) with ESMTP id 2209E85959; Tue, 14 Jun 2005 15:11:14 +0200 (CEST) Received: from server.absolute-media.de ([127.0.0.1]) by localhost (server [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05331-09; Tue, 14 Jun 2005 15:11:09 +0200 (CEST) Received: from firewall.demig (p50839636.dip0.t-ipconnect.de [80.131.150.54]) by server.absolute-media.de (Postfix) with ESMTP id 405FA85616; Tue, 14 Jun 2005 15:11:09 +0200 (CEST) Received: from ws-ew-3 (ws-ew-3.w2kdemig [192.168.1.72]) by firewall.demig (8.13.4/8.13.1) with SMTP id j5EDAjMM043204; Tue, 14 Jun 2005 15:10:45 +0200 (CEST) (envelope-from NKoch@demig.de) From: "Norbert Koch" To: "Maksim Yevmenkin" Date: Tue, 14 Jun 2005 15:10:45 +0200 Message-ID: <000001c570e2$79541300$4801a8c0@ws-ew-3.W2KDEMIG> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <001e01c570ab$13e1a280$4801a8c0@ws-ew-3.W2KDEMIG> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at absolute-media.de Cc: "Freebsd-Hackers@Freebsd.Org" Subject: kernel panic in usb0; was: RE: using vkbd device 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, 14 Jun 2005 13:11:17 -0000 > The ukbd-specific detaching only works, because I implemented something in > ukbd.c, > that Hans Petter Selasky [hselasky@c2i.net] suggested in thread > "usbd.conf: > detach ukbd". > (See the patch files, I posted there) > > When the kernel panics, it does this in usb0 kernel thread. > I figured out that this is only related to connecting/disconnecting > the usb keyboard. It panics without kbdmux loaded and it panics with > unmodified ukbd.c. So I'll have to try to remote debug it, as > my embedded device has no swap space at all and so no core dump device > (256MB flash/256 MD dram). Hello, I am observing spurious crashes in usb0 under FreeBSD 4.11. Kernel configuration/hardware: HZ=400, NO_SWAPPING, DEVICE_POLLING (with kern.polling.user_frac=90), fxp ethernet, 6x sio, ohci, Pentium MMX 166 MHz When quickly connecting/disconnecting a usb keyboard, after some time I have a panic in process 3 (usb0), either at usbd_ar_pipe+0x7 (when detaching) or at usbd_get_interface_descriptor+0x6 (when attaching). Stack traces are: (a) usbd_ar_pipe+0x7 usbd_ar_pipe(0,...) usbd_abort_pipe(0,...) ukbd_enable_intr() ukbd_term() ukbd_detach() DEVICE_DETACH() device_detach() device_delete_child() usb_discommect_port() uhub_explore() usb_discover() usb_event_thread() (b) usbd_get_interface_descriptor+0x6 usbd_get_interface_descriptor(0) ukbd_attach(c0bf3b80) DEVICE_ATTACH() device_probe_and_attach() usbd_probe_and_attach() usbd_new_device() uhub_explore() usb_discover() usb_event_thread() In situation(a), ipl is at bio, ks_intr_pipe is NULL when calling usbd_abort_pipe(). In situation (b), ipl is at none, USB_ATTACH_START() in USB_ATTACK(ukbd) in ukbd.c seems to make problems. The above stack traces are from ddb. Booting the kernel with -gd and using gdb -k didn't give more information. I almost always get an unusable empty stack trace and different crash addresses. It seems like 'usbd_setup_pipe: failed to start endpoint, IOERROR' always comes before the crash and ipl is mostly at bio, never at usb. When I'm doing these tests, I have an ssh console connected through fxp0 where I run usbd -dv. Any idea? Norbert From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 14 14:19:55 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 85F3D16A41C for ; Tue, 14 Jun 2005 14:19:55 +0000 (GMT) (envelope-from ruselek@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4FBB43D1F for ; Tue, 14 Jun 2005 14:19:54 +0000 (GMT) (envelope-from ruselek@gmail.com) Received: by wproxy.gmail.com with SMTP id 71so2354799wri for ; Tue, 14 Jun 2005 07:19:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=dFriHNtY/7M+ThgAErUbojNP+OGS/mX9WsDo/4Qhyy1BglH5hwHFiCAIzB/AVBLTPX8e/zVjUZOlWF6Dog7WTvA5eATP4MdnqT2qMU/9XXCdWkE20q8nrOquIYxN97kmthJy1DBzLNWzuKmJ0oXCt5LKDdiGr0g3GRkl5t4yhKo= Received: by 10.54.36.66 with SMTP id j66mr3232071wrj; Tue, 14 Jun 2005 07:19:53 -0700 (PDT) Received: by 10.54.84.9 with HTTP; Tue, 14 Jun 2005 07:19:53 -0700 (PDT) Message-ID: <1a8aebce050614071936c0b001@mail.gmail.com> Date: Tue, 14 Jun 2005 16:19:53 +0200 From: rusel To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: mbr and boot loader X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rusel List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2005 14:19:55 -0000 Hello,=20 bitch# uname -a FreeBSD bitch 5.3-RELEASE FreeBSD 5.3-RELEASE #0: Fri Nov 5 04:19:18 UTC 2004 root@harlow.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC=20 i386 I`ve got fbsd & winxp, now I have to format this stupid microshit coz its still reeboting itself ... and now, how to safely reinstall winshit without crushing mbr ... --=20 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCDR84vcL1obalX08RAoFhAJwNuXW5vKTb5bK6hlIFeFTymMiyPACgo6rI QtLBjucJJH+AtrEem2NBHKI=3D =3DbYD1 -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 14 14:38:13 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 84D8116A41C for ; Tue, 14 Jun 2005 14:38:13 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: from hydra.bec.de (www.ostsee-abc.de [62.206.222.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3566E43D53 for ; Tue, 14 Jun 2005 14:38:12 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: from britannica.bec.de (unknown [139.30.252.67]) by hydra.bec.de (Postfix) with ESMTP id E57F735707 for ; Tue, 14 Jun 2005 16:38:10 +0200 (CEST) Received: by britannica.bec.de (Postfix, from userid 1001) id 6A22853F0; Tue, 14 Jun 2005 16:38:04 +0200 (CEST) Date: Tue, 14 Jun 2005 16:38:04 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Message-ID: <20050614143804.GA67002@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <1a8aebce050614071936c0b001@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1a8aebce050614071936c0b001@mail.gmail.com> User-Agent: Mutt/1.5.6i Subject: Re: mbr and boot loader 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, 14 Jun 2005 14:38:13 -0000 On Tue, Jun 14, 2005 at 04:19:53PM +0200, rusel wrote: > Hello, > bitch# uname -a > > FreeBSD bitch 5.3-RELEASE FreeBSD 5.3-RELEASE #0: Fri Nov 5 04:19:18 > UTC 2004 root@harlow.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC > i386 > > I`ve got fbsd & winxp, now I have to format this stupid microshit coz > its still reeboting itself ... and now, how to safely reinstall > winshit without crushing mbr ... You can't. It will always overwrite the MBR. But you can just mark your FreeBSD slice as bootable afterwards to get back into FreeBSD after the reinstall. Joerg From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 14 21:22:15 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A297216A41C; Tue, 14 Jun 2005 21:22:15 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7179443D49; Tue, 14 Jun 2005 21:22:15 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (nprxrc@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.3/8.13.3) with ESMTP id j5ELMEes079099; Tue, 14 Jun 2005 14:22:14 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.3/8.13.3/Submit) id j5ELMEVU079098; Tue, 14 Jun 2005 14:22:14 -0700 (PDT) (envelope-from jmg) Date: Tue, 14 Jun 2005 14:22:14 -0700 From: John-Mark Gurney To: Aziz Kezzou Message-ID: <20050614212214.GK742@funkthat.com> Mail-Followup-To: Aziz Kezzou , freebsd-hackers , freebsd-net References: <37273927050614012154fdb80b@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <37273927050614012154fdb80b@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p1 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: freebsd-hackers , freebsd-net Subject: Re: FreeBSD Memory Management questions ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2005 21:22:15 -0000 Aziz Kezzou wrote this message on Tue, Jun 14, 2005 at 04:21 -0400: > I have two questions concerning FreeBSD Memory management : > > 1 - Right now to access the memory address space of a user process > from kernel mode, I only have to set, on x86 systems, the register CR3 > to the right value. How can I do that on other architectures ? is > there an architecture-independant way of doing that ? > > 2- I have noticed that while in kernel mode the value of CR3 is equal > to that of the user process beeing interrupted. Doesn't the kernel > supposed to have its "own" page-directory, i.e it's own CR3 value ? > or is kernel virtual address resolution does not go through CR3 at > all ? You should be using copyin(9)/copyout(9) instead of playing around with CR3 directly... or fuword(9)/suword(9)... This provides a platform independant way of accessing user's memory (for the current running process)... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 14 21:32:06 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B41316A41C for ; Tue, 14 Jun 2005 21:32:06 +0000 (GMT) (envelope-from gemini@geminix.org) Received: from gen129.n001.c02.escapebox.net (gen129.n001.c02.escapebox.net [213.73.91.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B6B943D1D for ; Tue, 14 Jun 2005 21:32:06 +0000 (GMT) (envelope-from gemini@geminix.org) Message-ID: <42AF4CCE.9040308@geminix.org> Date: Tue, 14 Jun 2005 23:31:58 +0200 From: Uwe Doering Organization: Private UNIX Site User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050526 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Norbert Koch References: <000001c57016$8e4b0600$4801a8c0@ws-ew-3.W2KDEMIG> In-Reply-To: <000001c57016$8e4b0600$4801a8c0@ws-ew-3.W2KDEMIG> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Received: from gemini by geminix.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51 (FreeBSD)) id 1DiJ0p-0007lm-3E; Tue, 14 Jun 2005 23:31:59 +0200 Cc: freebsd-hackers@freebsd.org Subject: Re: Obvious bug in /sys/i386/include/bus.h (was: bus_at386.h) 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, 14 Jun 2005 21:32:06 -0000 Norbert Koch wrote: >>>So >>>how can I fix this in assembly. I am not an expert with inlined assembly, >>>so >>>maybe someone can correct me if I am wrong, but something like this needs >>>to >>>be added: >>> >>>or %ecx, %ecx >>>jz 2 >>> >>>2: >> >>This is wrong beacause the result is stored in ecx. Better using >>JECXZ instruction >>before the loop. > > No, it's a correct method to set/reset the zero flag: > (X | X) == X just as (X & X) == X > > So, he could also write: "and %ecx, %ecx". > [...] Also, on pipelined processors like Intel Pentium and better you would use "test %ecx, %ecx" for this purpose which internally is an "and", but since it drops the result and just sets the condition register it is faster than "and" or "or". At least potentially. Depends on the surrounding code. Uwe -- Uwe Doering | EscapeBox - Managed On-Demand UNIX Servers gemini@geminix.org | http://www.escapebox.net From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 14 21:33:15 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3850816A41C; Tue, 14 Jun 2005 21:33:15 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCA7843D1D; Tue, 14 Jun 2005 21:33:14 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j5ELbsha013988; Tue, 14 Jun 2005 15:37:55 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42AF4C82.7070306@samsco.org> Date: Tue, 14 Jun 2005 15:30:42 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John-Mark Gurney References: <37273927050614012154fdb80b@mail.gmail.com> <20050614212214.GK742@funkthat.com> In-Reply-To: <20050614212214.GK742@funkthat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: freebsd-hackers , Aziz Kezzou , freebsd-net Subject: Re: FreeBSD Memory Management questions ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2005 21:33:15 -0000 John-Mark Gurney wrote: > Aziz Kezzou wrote this message on Tue, Jun 14, 2005 at 04:21 -0400: > >>I have two questions concerning FreeBSD Memory management : >> >>1 - Right now to access the memory address space of a user process >>from kernel mode, I only have to set, on x86 systems, the register CR3 >>to the right value. How can I do that on other architectures ? is >>there an architecture-independant way of doing that ? >> >>2- I have noticed that while in kernel mode the value of CR3 is equal >>to that of the user process beeing interrupted. Doesn't the kernel >>supposed to have its "own" page-directory, i.e it's own CR3 value ? >>or is kernel virtual address resolution does not go through CR3 at >>all ? > > > You should be using copyin(9)/copyout(9) instead of playing around with > CR3 directly... or fuword(9)/suword(9)... This provides a platform > independant way of accessing user's memory (for the current running > process)... > Not to mention that setting CR3, or whatever on other platforms, doesn't handle accessing pages that have been swapped out. That's the real magic that copyin/copyout does. Scott From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 14 23:38:54 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 70ED516A41C for ; Tue, 14 Jun 2005 23:38:54 +0000 (GMT) (envelope-from Maksim.Yevmenkin@savvis.net) Received: from mailgate1b.savvis.net (mailgate1b.savvis.net [216.91.182.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C25743D48 for ; Tue, 14 Jun 2005 23:38:54 +0000 (GMT) (envelope-from Maksim.Yevmenkin@savvis.net) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgate1b.savvis.net (Postfix) with ESMTP id 973833BE2B; Tue, 14 Jun 2005 18:38:53 -0500 (CDT) Received: from mailgate1b.savvis.net ([127.0.0.1]) by localhost (mailgate1b.savvis.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 29127-01-81; Tue, 14 Jun 2005 18:38:53 -0500 (CDT) Received: from out002.email.savvis.net (out002.apptix.savvis.net [216.91.32.45]) by mailgate1b.savvis.net (Postfix) with ESMTP id 5EAB13BE28; Tue, 14 Jun 2005 18:38:53 -0500 (CDT) Received: from s228130hz1ew171.apptix-01.savvis.net ([10.146.4.29]) by out002.email.savvis.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Jun 2005 18:38:48 -0500 Received: from [10.254.186.111] ([66.35.239.94]) by s228130hz1ew171.apptix-01.savvis.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Jun 2005 18:38:44 -0500 Message-ID: <42AF6A83.4050608@savvis.net> Date: Tue, 14 Jun 2005 16:38:43 -0700 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Norbert Koch References: <000001c570e2$79541300$4801a8c0@ws-ew-3.W2KDEMIG> In-Reply-To: <000001c570e2$79541300$4801a8c0@ws-ew-3.W2KDEMIG> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jun 2005 23:38:44.0485 (UTC) FILETIME=[34071B50:01C5713A] X-Virus-Scanned: amavisd-new at savvis.net Cc: "Freebsd-Hackers@Freebsd.Org" Subject: Re: kernel panic in usb0; was: RE: using vkbd device 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, 14 Jun 2005 23:38:54 -0000 Norbert, >> The ukbd-specific detaching only works, because I implemented >> something in ukbd.c, that Hans Petter Selasky [hselasky@c2i.net] >> suggested in thread "usbd.conf: detach ukbd". (See the patch files, >> I posted there) >> >> When the kernel panics, it does this in usb0 kernel thread. I >> figured out that this is only related to connecting/disconnecting >> the usb keyboard. It panics without kbdmux loaded and it panics >> with unmodified ukbd.c. So I'll have to try to remote debug it, as >> my embedded device has no swap space at all and so no core dump >> device (256MB flash/256 MD dram). > > I am observing spurious crashes in usb0 under FreeBSD 4.11. > Kernel configuration/hardware: > HZ=400, NO_SWAPPING, DEVICE_POLLING (with kern.polling.user_frac=90), > fxp ethernet, 6x sio, ohci, Pentium MMX 166 MHz could you try to compile kernel with debugging information? not sure if it will fit into ram. > When quickly connecting/disconnecting i guess you mean here unplug the keyboard and then immediately plug it back, right? > a usb keyboard, after some time I have a panic in process 3 (usb0), > either at usbd_ar_pipe+0x7 (when detaching) > or at usbd_get_interface_descriptor+0x6 (when attaching). > > Stack traces are: > > (a) > usbd_ar_pipe+0x7 > usbd_ar_pipe(0,...) > usbd_abort_pipe(0,...) > ukbd_enable_intr() > ukbd_term() > ukbd_detach() > DEVICE_DETACH() > device_detach() > device_delete_child() > usb_discommect_port() > uhub_explore() > usb_discover() > usb_event_thread() can you tell what value "pipe" handle has? i suspect its NULL > (b) > usbd_get_interface_descriptor+0x6 > usbd_get_interface_descriptor(0) > ukbd_attach(c0bf3b80) > DEVICE_ATTACH() > device_probe_and_attach() > usbd_probe_and_attach() > usbd_new_device() > uhub_explore() > usb_discover() > usb_event_thread() can you tell what value "iface" handle has? i suspect its NULL can you please compile the kernel with "DIAGNOSTIC" and check for messages from usb system? > In situation(a), ipl is at bio, ks_intr_pipe is NULL when calling > usbd_abort_pipe(). thats ok. splusb is defined as splbio > In situation (b), ipl is at none, USB_ATTACH_START() in USB_ATTACK(ukbd) in > ukbd.c > seems to make problems. not sure about this one > The above stack traces are from ddb. Booting the kernel with -gd and using > gdb -k > didn't give more information. I almost always get an unusable empty stack > trace > and different crash addresses. too bad :( > It seems like 'usbd_setup_pipe: failed to start endpoint, IOERROR' always > comes > before the crash and ipl is mostly at bio, never at usb. what is your usb controller? uhci/ohci? what chip? > When I'm doing these tests, I have an ssh console connected through fxp0 > where I > run usbd -dv. > > Any idea? please compile kernel with DIAGNOSTIC and USB_DEBUG. then try to adjust various "debug" knobs with sysctl(8) to get debug traces. at this point it looks like a race condition of some sort (to me). thanks, max From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 15 00:32:22 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 944DF16A41C for ; Wed, 15 Jun 2005 00:32:22 +0000 (GMT) (envelope-from julian@elischer.org) Received: from bigwoop.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7029043D1D for ; Wed, 15 Jun 2005 00:32:22 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by bigwoop.vicor-nb.com (Postfix) with ESMTP id 635557A403; Tue, 14 Jun 2005 17:32:22 -0700 (PDT) Message-ID: <42AF7716.7080108@elischer.org> Date: Tue, 14 Jun 2005 17:32:22 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050423 X-Accept-Language: en, hu MIME-Version: 1.0 To: Maksim Yevmenkin References: <000001c570e2$79541300$4801a8c0@ws-ew-3.W2KDEMIG> <42AF6A83.4050608@savvis.net> In-Reply-To: <42AF6A83.4050608@savvis.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Norbert Koch , "Freebsd-Hackers@Freebsd.Org" Subject: Re: kernel panic in usb0; was: RE: using vkbd device 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, 15 Jun 2005 00:32:22 -0000 Maksim Yevmenkin wrote: > Norbert, > >>> >> >> >> I am observing spurious crashes in usb0 under FreeBSD 4.11. >> Kernel configuration/hardware: >> HZ=400, NO_SWAPPING, DEVICE_POLLING (with kern.polling.user_frac=90), >> fxp ethernet, 6x sio, ohci, Pentium MMX 166 MHz > > > could you try to compile kernel with debugging information? not sure > if it will fit into ram. doesn't have to.. the debug info is not loaded. only made available to the debugger > >> When quickly connecting/disconnecting > > > i guess you mean here unplug the keyboard and then immediately plug it > back, right? > sounds like he means "repeatedly." >> a usb keyboard, after some time I have a panic in process 3 (usb0), >> either at usbd_ar_pipe+0x7 (when detaching) >> or at usbd_get_interface_descriptor+0x6 (when attaching). >> >> Stack traces are: >> >> (a) >> usbd_ar_pipe+0x7 >> usbd_ar_pipe(0,...) >> usbd_abort_pipe(0,...) >> ukbd_enable_intr() >> ukbd_term() >> ukbd_detach() >> DEVICE_DETACH() >> device_detach() >> device_delete_child() >> usb_discommect_port() >> uhub_explore() >> usb_discover() >> usb_event_thread() > > > can you tell what value "pipe" handle has? i suspect its NULL > >> (b) >> usbd_get_interface_descriptor+0x6 >> usbd_get_interface_descriptor(0) >> ukbd_attach(c0bf3b80) >> DEVICE_ATTACH() >> device_probe_and_attach() >> usbd_probe_and_attach() >> usbd_new_device() >> uhub_explore() >> usb_discover() >> usb_event_thread() > > > can you tell what value "iface" handle has? i suspect its NULL > > can you please compile the kernel with "DIAGNOSTIC" and check for > messages from usb system? > >> In situation(a), ipl is at bio, ks_intr_pipe is NULL when calling >> usbd_abort_pipe(). > > > thats ok. splusb is defined as splbio > >> In situation (b), ipl is at none, USB_ATTACH_START() in >> USB_ATTACK(ukbd) in > that would be ATTACH not ATACK! :-) >> ukbd.c >> seems to make problems. > > > not sure about this one > >> The above stack traces are from ddb. Booting the kernel with -gd and >> using >> gdb -k >> didn't give more information. I almost always get an unusable empty >> stack >> trace >> and different crash addresses. > booting with -gd drops you into the (gdb) debugger immediatly.. I presume you have a gdb looking at the serial port and have a serial debug port defined then? > > > please compile kernel with DIAGNOSTIC and USB_DEBUG. then try to > adjust various "debug" knobs with sysctl(8) to get debug traces. at > this point it looks like a race condition of some sort (to me). > > thanks, > max > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 15 00:57:06 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3BB9916A41C for ; Wed, 15 Jun 2005 00:57:06 +0000 (GMT) (envelope-from v.velox@vvelox.net) Received: from S1.cableone.net (smtp1.cableone.net [24.116.0.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE2BD43D4C for ; Wed, 15 Jun 2005 00:57:05 +0000 (GMT) (envelope-from v.velox@vvelox.net) Received: from vixen42.local.lan (unverified [24.119.122.41]) by S1.cableone.net (CableOne SMTP Service S1) with ESMTP id 23115741 for multiple; Tue, 14 Jun 2005 17:57:24 -0700 Date: Tue, 14 Jun 2005 19:58:11 -0500 From: Vulpes Velox To: rusel Message-ID: <20050614195811.4a856732@vixen42.local.lan> In-Reply-To: <1a8aebce050614071936c0b001@mail.gmail.com> References: <1a8aebce050614071936c0b001@mail.gmail.com> X-Mailer: Sylpheed-Claws 1.9.11 (GTK+ 2.6.7; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IP-stats: Incoming Last 0, First 27, in=35, out=0, spam=0 X-External-IP: 24.119.122.41 X-Abuse-Info: Send abuse complaints to abuse@cableone.net Cc: freebsd-hackers@freebsd.org Subject: Re: mbr and boot loader 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, 15 Jun 2005 00:57:06 -0000 On Tue, 14 Jun 2005 16:19:53 +0200 rusel wrote: > Hello, > bitch# uname -a > > FreeBSD bitch 5.3-RELEASE FreeBSD 5.3-RELEASE #0: Fri Nov 5 > 04:19:18 UTC 2004 root@harlow.cse.buffalo.edu:/usr/obj/usr/src/ > sys/GENERIC i386 > > I`ve got fbsd & winxp, now I have to format this stupid microshit > coz its still reeboting itself ... and now, how to safely reinstall > winshit without crushing mbr ... I would just like windows waste the mbr and use a freebsd install cd to write a new mbr. From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 15 06:29:35 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5370816A41C for ; Wed, 15 Jun 2005 06:29:35 +0000 (GMT) (envelope-from NKoch@demig.de) Received: from server.absolute-media.de (server.absolute-media.de [213.239.231.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id E5E9D43D1D for ; Wed, 15 Jun 2005 06:29:34 +0000 (GMT) (envelope-from NKoch@demig.de) Received: from localhost (unknown [127.0.0.1]) by server.absolute-media.de (Postfix) with ESMTP id 12F2784CFE; Wed, 15 Jun 2005 08:29:33 +0200 (CEST) Received: from server.absolute-media.de ([127.0.0.1]) by localhost (server [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16304-10; Wed, 15 Jun 2005 08:29:29 +0200 (CEST) Received: from firewall.demig (p5083A059.dip0.t-ipconnect.de [80.131.160.89]) by server.absolute-media.de (Postfix) with ESMTP id D059685B05; Wed, 15 Jun 2005 08:29:28 +0200 (CEST) Received: from ws-ew-3 (ws-ew-3.w2kdemig [192.168.1.72]) by firewall.demig (8.13.4/8.13.1) with SMTP id j5F6J2N8001128; Wed, 15 Jun 2005 08:19:08 +0200 (CEST) (envelope-from NKoch@demig.de) From: "Norbert Koch" To: "Julian Elischer" , "Maksim Yevmenkin" Date: Wed, 15 Jun 2005 08:25:50 +0200 Message-ID: <000f01c57173$12f8cc40$4801a8c0@ws-ew-3.W2KDEMIG> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <42AF7716.7080108@elischer.org> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at absolute-media.de Cc: "Freebsd-Hackers@Freebsd.Org" Subject: RE: kernel panic in usb0; was: RE: using vkbd device 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, 15 Jun 2005 06:29:35 -0000 > > > >> When quickly connecting/disconnecting > > > > > > i guess you mean here unplug the keyboard and then immediately plug it > > back, right? > > > > sounds like he means "repeatedly." yes > booting with -gd drops you into the (gdb) debugger immediatly.. > > I presume you have a gdb looking at the serial port and have a > serial debug port defined then? Yes. That's what I did: boot -gd && gdb -k kernel.debug && target remote /dev/cuaa0 In gdb "bt" only shows two entries. The function where the panic occurred and 0x0! BTW, after boot -gd, when gdb attaches I have a kernel panic too. But I can just enter "continue" and the kernel continues booting. Is that ok? From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 15 06:29:35 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5548216A41F for ; Wed, 15 Jun 2005 06:29:35 +0000 (GMT) (envelope-from NKoch@demig.de) Received: from server.absolute-media.de (server.absolute-media.de [213.239.231.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id E604143D48 for ; Wed, 15 Jun 2005 06:29:34 +0000 (GMT) (envelope-from NKoch@demig.de) Received: from localhost (unknown [127.0.0.1]) by server.absolute-media.de (Postfix) with ESMTP id 22AEC851C7; Wed, 15 Jun 2005 08:29:33 +0200 (CEST) Received: from server.absolute-media.de ([127.0.0.1]) by localhost (server [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16436-07; Wed, 15 Jun 2005 08:29:28 +0200 (CEST) Received: from firewall.demig (p5083A059.dip0.t-ipconnect.de [80.131.160.89]) by server.absolute-media.de (Postfix) with ESMTP id 823E980318; Wed, 15 Jun 2005 08:29:28 +0200 (CEST) Received: from ws-ew-3 (ws-ew-3.w2kdemig [192.168.1.72]) by firewall.demig (8.13.4/8.13.1) with SMTP id j5F6J2N6001128; Wed, 15 Jun 2005 08:19:02 +0200 (CEST) (envelope-from NKoch@demig.de) From: "Norbert Koch" To: "Maksim Yevmenkin" Date: Wed, 15 Jun 2005 08:25:44 +0200 Message-ID: <000e01c57173$0f453a20$4801a8c0@ws-ew-3.W2KDEMIG> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <42AF6A83.4050608@savvis.net> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at absolute-media.de Cc: "Freebsd-Hackers@Freebsd.Org" Subject: RE: kernel panic in usb0; was: RE: using vkbd device 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, 15 Jun 2005 06:29:35 -0000 > > When quickly connecting/disconnecting > > i guess you mean here unplug the keyboard and then immediately plug it > back, right? I mean plug in / plug out, repeat for ever. > can you tell what value "pipe" handle has? i suspect its NULL yes > can you tell what value "iface" handle has? i suspect its NULL yes > > thats ok. splusb is defined as splbio oh, ok. > what is your usb controller? uhci/ohci? what chip? ohci AcerLabs M5237 (Aladdin-V) > please compile kernel with DIAGNOSTIC and USB_DEBUG. then try to adjust > various "debug" knobs with sysctl(8) to get debug traces. at this point > it looks like a race condition of some sort (to me). ok, I'll try this. From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 14 14:37:54 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63E9916A41C for ; Tue, 14 Jun 2005 14:37:54 +0000 (GMT) (envelope-from hnaz@tutorialzone.de) Received: from ipx11328.ipxserver.de (e29.de [212.112.229.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06FA243D58 for ; Tue, 14 Jun 2005 14:37:53 +0000 (GMT) (envelope-from hnaz@tutorialzone.de) Received: from localhost (localhost [127.0.0.1]) by ipx11328.ipxserver.de (Postfix) with ESMTP id 7AA9A7E712; Tue, 14 Jun 2005 16:37:52 +0200 (CEST) Received: from ipx11328.ipxserver.de ([127.0.0.1]) by localhost (ipx11328 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21920-09; Tue, 14 Jun 2005 16:37:48 +0200 (CEST) Received: from localhost (p54A4B11B.dip0.t-ipconnect.de [84.164.177.27]) by ipx11328.ipxserver.de (Postfix) with ESMTP id 7529C2F8EA; Tue, 14 Jun 2005 16:37:48 +0200 (CEST) Date: Tue, 14 Jun 2005 16:37:41 +0200 From: Johannes Weiner To: rusel Message-ID: <20050614143741.GA4707@neurogen.fuck.this.shit> Mail-Followup-To: rusel , freebsd-hackers@freebsd.org References: <1a8aebce050614071936c0b001@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BOKacYhQ+x31HxR3" Content-Disposition: inline In-Reply-To: <1a8aebce050614071936c0b001@mail.gmail.com> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ipx11328.ipxserver.de X-Mailman-Approved-At: Wed, 15 Jun 2005 11:59:56 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: mbr and boot loader 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, 14 Jun 2005 14:37:54 -0000 --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 14, 2005 at 04:19:53PM +0200, rusel wrote: > Hello,=20 > bitch# uname -a >=20 > FreeBSD bitch 5.3-RELEASE FreeBSD 5.3-RELEASE #0: Fri Nov 5 04:19:18 > UTC 2004 root@harlow.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC=20 > i386 >=20 > I`ve got fbsd & winxp, now I have to format this stupid microshit coz > its still reeboting itself ... and now, how to safely reinstall > winshit without crushing mbr ... No Chance, it WILL delete your prior MBR, but you can boot via LiveCD into your FreeBSD and reinstall the BootManager. --BOKacYhQ+x31HxR3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCruuz1heCLyOG8GcRAnI1AKCDr9hKl2RQB8iNLBKd590tBcmFKACfYNmD 0LMxr81HyD0bPjYWLpAnbRQ= =zsSz -----END PGP SIGNATURE----- --BOKacYhQ+x31HxR3-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 15 15:19:54 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 752F516A41C for ; Wed, 15 Jun 2005 15:19:54 +0000 (GMT) (envelope-from faber@pun.isi.edu) Received: from pun.isi.edu (pun.isi.edu [128.9.160.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3DA5043D49 for ; Wed, 15 Jun 2005 15:19:54 +0000 (GMT) (envelope-from faber@pun.isi.edu) Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.13.3/8.13.1) with ESMTP id j5FFJrlP079542; Wed, 15 Jun 2005 08:19:53 -0700 (PDT) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.13.3/8.13.1/Submit) id j5FFJrtM079541; Wed, 15 Jun 2005 08:19:53 -0700 (PDT) (envelope-from faber) Date: Wed, 15 Jun 2005 08:19:53 -0700 From: Ted Faber To: freebsd-hackers@freebsd.org Message-ID: <20050615151953.GB78881@pun.isi.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NU0Ex4SbNnrxsi6C" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber Cc: Subject: ckgrp flags NIS groups as bad - patch included to fix 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, 15 Jun 2005 15:19:54 -0000 --NU0Ex4SbNnrxsi6C Content-Type: multipart/mixed; boundary="1UWUbFP1cBYEclgG" Content-Disposition: inline --1UWUbFP1cBYEclgG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable The change to /usr/sbin/chkgrp on Fri Jun 10 flags NIS groups as having an invalid character in them - the leading +. Attached is a patch to explicitly allow that case. If some helpful committer would like to test and commit the patch, that would be great. I think that the testing needed is minimal. If no one wants to put this in, I'll pr it. Thanks. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --1UWUbFP1cBYEclgG Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="chkgrp.patch" Content-Transfer-Encoding: quoted-printable --- chkgrp.c.orig Wed Jun 15 08:04:27 2005 +++ chkgrp.c Wed Jun 15 08:13:07 2005 @@ -105,7 +105,23 @@ line[i++] =3D 0; } =20 - for (cp =3D f[0] ; *cp ; cp++) { + /*=20 + * A group with the first character '+' is an NIS group. Allow that + * case explicitly. + */ + cp =3D f[0]; + if (!isalnum(*cp) && *cp !=3D '.' && *cp !=3D '+' && *cp !=3D '_' &&=20 + *cp !=3D '-') { + warnx("%s: line %d: '%c' invalid character", gfn, n, *cp); + e++; + } + cp++; + + /*=20 + * Check second through last characters of the group name for bad + * characters (cp is not re-initialized). + */ + for ( ; *cp ; cp++) { if (!isalnum(*cp) && *cp !=3D '.' && *cp !=3D '_' && *cp !=3D '-') { warnx("%s: line %d: '%c' invalid character", gfn, n, *cp); e++; --1UWUbFP1cBYEclgG-- --NU0Ex4SbNnrxsi6C Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCsEcZaUz3f+Zf+XsRAh7qAJ0Z6DmoWY5L0tTRoGipbwni+5L2MACgsZpB qh++3gq/78KhhlmNhvdbYEg= =XWKx -----END PGP SIGNATURE----- --NU0Ex4SbNnrxsi6C-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 15 19:43:23 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 307D616A41C for ; Wed, 15 Jun 2005 19:43:23 +0000 (GMT) (envelope-from julian@elischer.org) Received: from bigwoop.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 167AE43D1F for ; Wed, 15 Jun 2005 19:43:22 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by bigwoop.vicor-nb.com (Postfix) with ESMTP id 907E67A403; Wed, 15 Jun 2005 12:43:22 -0700 (PDT) Message-ID: <42B084DA.7040702@elischer.org> Date: Wed, 15 Jun 2005 12:43:22 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050423 X-Accept-Language: en, hu MIME-Version: 1.0 To: Norbert Koch References: <000f01c57173$12f8cc40$4801a8c0@ws-ew-3.W2KDEMIG> In-Reply-To: <000f01c57173$12f8cc40$4801a8c0@ws-ew-3.W2KDEMIG> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Freebsd-Hackers@Freebsd.Org" Subject: Re: kernel panic in usb0; was: RE: using vkbd device 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, 15 Jun 2005 19:43:23 -0000 Norbert Koch wrote: >>>>When quickly connecting/disconnecting >>>> >>>> >>>i guess you mean here unplug the keyboard and then immediately plug it >>>back, right? >>> >>> >>> >>sounds like he means "repeatedly." >> >> > >yes > > > >>booting with -gd drops you into the (gdb) debugger immediatly.. >> >>I presume you have a gdb looking at the serial port and have a >>serial debug port defined then? >> >> > >Yes. >That's what I did: > >boot -gd && gdb -k kernel.debug && target remote /dev/cuaa0 > >In gdb "bt" only shows two entries. The function where the panic >occurred and 0x0! > > that is normal you don't want to jump into gdb that soon. there is hardly anything set up. use the sysctl to enter gdb later. >BTW, after boot -gd, when gdb attaches I have a kernel panic too. >But I can just enter "continue" and the kernel continues booting. >Is that ok? > > what do you mean "panic"? I never use -gd, just -g then hitting ^ALT-ESC or using th esysctl makes me enter the debugger when I need to. From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 16 05:33:50 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D53B616A422 for ; Thu, 16 Jun 2005 05:33:50 +0000 (GMT) (envelope-from anton@abutsyk.sumy.ua) Received: from gkm.sumy.ua (gkm.sm.chereda.net [193.110.17.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB8EC43ED0 for ; Thu, 16 Jun 2005 05:26:00 +0000 (GMT) (envelope-from anton@abutsyk.sumy.ua) Received: (qmail 6317 invoked by uid 0); 16 Jun 2005 05:25:28 -0000 Received: from admin.gkm.sumy.ua (HELO ?127.0.0.1?) (10.3.0.1) by gkm.sumy.ua with SMTP; 16 Jun 2005 05:25:28 -0000 X-AntiVirus: Checked by Dr.Web [version: 4.32b, engine: 4.32b, virus records: 77720, updated: 16.06.2005] Message-ID: <42B10DC0.7000608@abutsyk.sumy.ua> Date: Thu, 16 Jun 2005 08:27:28 +0300 From: Anton Butsyk User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Freebsd-Hackers@Freebsd.Org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: konica minolta di1611 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, 16 Jun 2005 05:33:51 -0000 Hi list! We have device: #dmesg|grep KONICA ulpt0: KONICA MINOLTA KONICA MINOLTA Di1611 TWAIN Device, rev 1.10/1.00, addr 2, iclass 255/255 http://www.minolta.pl/products/business/kop_druk_cz-b/di1611_2011/ - picture. It works fine like printer server connected to FreeBSD 5.4 box, but also can do scan job. Can't make it to work like scanner. NetBSD, sane-backends doesn't have driver. Any ideas? Regards, butsyk From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 16 05:43:58 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B270E16A420 for ; Thu, 16 Jun 2005 05:43:58 +0000 (GMT) (envelope-from apachexm@hotmail.com) Received: from hotmail.com (bay19-f19.bay19.hotmail.com [64.4.53.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id 263F943F42 for ; Thu, 16 Jun 2005 05:39:36 +0000 (GMT) (envelope-from apachexm@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 15 Jun 2005 22:39:35 -0700 Message-ID: Received: from 218.76.42.20 by by19fd.bay19.hotmail.msn.com with HTTP; Thu, 16 Jun 2005 05:39:35 GMT X-Originating-IP: [218.76.42.20] X-Originating-Email: [apachexm@hotmail.com] X-Sender: apachexm@hotmail.com In-Reply-To: <42ADCC4F.4090201@elischer.org> From: "Apache Xie" To: freebsd-hackers@freebsd.org Date: Thu, 16 Jun 2005 05:39:35 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 16 Jun 2005 05:39:35.0960 (UTC) FILETIME=[C7B9C180:01C57235] Subject: Re: contigmalloc() and mmap() 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, 16 Jun 2005 05:43:59 -0000 >I'm unsure about this usage of the timer (callout(?) ) >how does the timer know which buffer pages to remove? >and if each userspace process does an ioctl to allocate a different buffer, >are >the new pages also visible to other processes? Use mmap() we can ensure different process access different buffer in user space without interference. > >in FreeBSD your driver can register with at_exit() in 4.x >and with eventhandler_register() in 5.x or 6.x to have stuff done >when the process exits. Yes, I use this macro and register my handler. > >(there are also at_fork and at_exec handlers too.) >see man at_exit (etc.) in 4.x >and man 9 EVENTHANDLER in 5.x and 6.x > >You could also make a hash table on the PID so that you keep different >information >available for different processes and look them up >using curproc->p_pid (for 4.x) and curthhread->td_proc->p_pid for 5.x and >6.x >to look up the > >Using these primatives you should be able to simulate what you need I >believe. > >>In FreeBSD, the driver works in the same pattern, but when a user process >>mmap driver's buffer (allocated by contigmalloc()) and is killed, then >>when >>another process mmap the same buffer again, sometimes it cannot get >>correct >>data from the mmaped pages, which means the user space virtual aderess may >>not point to the correct physical page of driver's buffer, sometimes the >>OS >>even panic with some information such as "Trap 12, Page not present" etc. > > >sounds like you are getting the buffers confused.. >are you doing correc treference counting on the buffers? > In Linux, before kernel memory is mmap to user space, memory pages must be set a reserved flag, no corresponding operations in FreeBSD, is it right? >> >>And recently, I modified my driver, I allocated a big chunk of contiguous >>physical memory using contigmalloc() in the driver's _attach() function, >>and I use a simple first-fit algorithm to manage this memory myself, which >>mean in ioctl() I use my allocate/deallocate functions instead of >>contigmalloc(), >>in _detach() function contigfree() is called to free the big chunk of >>memory, >>no panic again, but sometimes, process cannot get the correct data from >>the mmaped memory. I don't know why. > > > >it does sound a bit like you are not keeping the information >separated between processes enough. > I find a bug in my test program, because the big chunk memory in my driver is reused by new process, but it don't zero it before using it, so some data last process set interfere the new process. _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 16 15:50:55 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 736CC16A41C for ; Thu, 16 Jun 2005 15:50:55 +0000 (GMT) (envelope-from faber@pun.isi.edu) Received: from pun.isi.edu (pun.isi.edu [128.9.160.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5646343D53 for ; Thu, 16 Jun 2005 15:50:55 +0000 (GMT) (envelope-from faber@pun.isi.edu) Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.13.3/8.13.1) with ESMTP id j5GFotOB096720 for ; Thu, 16 Jun 2005 08:50:55 -0700 (PDT) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.13.3/8.13.1/Submit) id j5GFottR096719 for freebsd-hackers@freebsd.org; Thu, 16 Jun 2005 08:50:55 -0700 (PDT) (envelope-from faber) Date: Thu, 16 Jun 2005 08:50:55 -0700 From: Ted Faber To: freebsd-hackers@freebsd.org Message-ID: <20050616155055.GB95517@pun.isi.edu> References: <20050615151953.GB78881@pun.isi.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2B/JsCI69OhZNC5r" Content-Disposition: inline In-Reply-To: <20050615151953.GB78881@pun.isi.edu> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber Subject: Re: ckgrp flags NIS groups as bad - patch included to fix 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, 16 Jun 2005 15:50:55 -0000 --2B/JsCI69OhZNC5r Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 15, 2005 at 08:19:53AM -0700, Ted Faber wrote: > The change to /usr/sbin/chkgrp on Fri Jun 10 flags NIS groups as having > an invalid character in them - the leading +. Attached is a patch to > explicitly allow that case. If some helpful committer would like to > test and commit the patch, that would be great. I think that the > testing needed is minimal. >=20 > If no one wants to put this in, I'll pr it. After hearing no takers, I pr-ed this: bin/82325 http://www.freebsd.org/cgi/query-pr.cgi?pr=3D82325 --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --2B/JsCI69OhZNC5r Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCsZ/faUz3f+Zf+XsRAolbAJ46VjDACg9VEiGaH8BfY9vUjjdBKACfYoUE pg1O9O3euYFXqP7I7OeNtc0= =e6I2 -----END PGP SIGNATURE----- --2B/JsCI69OhZNC5r-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 16 15:55:41 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3342816A41C for ; Thu, 16 Jun 2005 15:55:41 +0000 (GMT) (envelope-from NKoch@demig.de) Received: from server.absolute-media.de (server.absolute-media.de [213.239.231.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A12943D49 for ; Thu, 16 Jun 2005 15:55:39 +0000 (GMT) (envelope-from NKoch@demig.de) Received: from localhost (unknown [127.0.0.1]) by server.absolute-media.de (Postfix) with ESMTP id 36FFF8603D; Thu, 16 Jun 2005 17:55:37 +0200 (CEST) Received: from server.absolute-media.de ([127.0.0.1]) by localhost (server [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16730-02; Thu, 16 Jun 2005 17:55:32 +0200 (CEST) Received: from firewall.demig (p5083984C.dip0.t-ipconnect.de [80.131.152.76]) by server.absolute-media.de (Postfix) with ESMTP id 35C8B7EDAB; Thu, 16 Jun 2005 17:55:32 +0200 (CEST) Received: from ws-ew-3 (ws-ew-3.w2kdemig [192.168.1.72]) by firewall.demig (8.13.4/8.13.1) with SMTP id j5GFohSX030397; Thu, 16 Jun 2005 17:50:43 +0200 (CEST) (envelope-from NKoch@demig.de) From: "Norbert Koch" To: "Julian Elischer" Date: Thu, 16 Jun 2005 17:49:24 +0200 Message-ID: <000001c5728a$f854fda0$4801a8c0@ws-ew-3.W2KDEMIG> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_01C5729B.BBDDCDA0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <42B084DA.7040702@elischer.org> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at absolute-media.de Cc: "Freebsd-Hackers@Freebsd.Org" Subject: RE: kernel panic in usb0; was: RE: using vkbd device 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, 16 Jun 2005 15:55:41 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C5729B.BBDDCDA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > >In gdb "bt" only shows two entries. The function where the panic > >occurred and 0x0! > > > > > > that is normal > you don't want to jump into gdb that soon. > there is hardly anything set up. > > use the sysctl to enter gdb later. > > >BTW, after boot -gd, when gdb attaches I have a kernel panic too. > >But I can just enter "continue" and the kernel continues booting. > >Is that ok? > > > > > > what do you mean "panic"? > I never use -gd, just -g > > then hitting ^ALT-ESC or using th esysctl makes me enter the debugger > when I need to. > > > Ok, may be, I am doing something stupidly wrong. 1. Added DIAGNOSTIC, USB_DEBUG, INVARIANT_SUPPORT, INVARIANTS to my configuration and installed a new debug kernel. 2. Booted the target to the loader prompt. "unload kernel" "load kerneld" "boot -gd" 3. "gdb -k kernel.debug" & "target remote /dev/cuaa0" on my workstation. 4. Arrived in Debugger() and pressed "c". 5. The kernel booted. I saw the usual boot messages. After seeing "IP filtering initialized...", I saw: "panic: usb_cold_explore: busses to explore when !cold". 6. Found, that cold is indeed 0. 7. Booted again up to 4. and set a breakpoint at usb_cold_explore(). Pressed "c" and got (from gdb): Continuing. Cannot insert breakpoint 1: Cannot access memory at address 0xc01e5a37. At the same time the target console showed twice: "Fatal trap 12: page fault..." "..." "supervisor read, page not present" "..." So, do I have something very wrong in my kernel configuration? (See attached file) What about HZ=400 and NO_SWAPPING? Any known problems? Can't I set a breakpoint at that early stage of booting? Thanks for any help, Norbert ------=_NextPart_000_0001_01C5729B.BBDDCDA0 Content-Type: application/octet-stream; name="MOPSD" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="MOPSD" IwojIE1PUFMgLS0gS2VybmVsIGNvbmZpZ3VyYXRpb24gZmlsZSBmb3IgRnJlZUJTRC9pMzg2CiMg JEhlYWRlcjogL3Vzci9sb2NhbC9jdnMvc3lzL2kzODYvY29uZi9NT1BTRCx2IDEuNyAyMDA1LzA2 LzA3IDExOjU3OjM1IG5rIEV4cCAkCiMKCm1hY2hpbmUJCWkzODYKY3B1CQlJNTg2X0NQVQpjcHUJ CUk2ODZfQ1BVCmlkZW50CQlNT1BTCgptYXh1c2VycwkwCgpvcHRpb25zICAgICAgICAgSFo9NDAw Cm9wdGlvbnMgICAgICAgICBERVZJQ0VfUE9MTElORwojI29wdGlvbnMgICAgICAgICBTSUdOQUxf SU9DSEsKCm9wdGlvbnMgICAgICAgICBESUFHTk9TVElDCm9wdGlvbnMgICAgICAgICBJTlZBUklB TlRfU1VQUE9SVApvcHRpb25zICAgICAgICAgSU5WQVJJQU5UUwpvcHRpb25zICAgICAgICAgVVNC X0RFQlVHCgptYWtlb3B0aW9ucwlERUJVRz0tZwkJI0J1aWxkIGtlcm5lbCB3aXRoIGdkYigxKSBk ZWJ1ZyBzeW1ib2xzCm1ha2VvcHRpb25zICAgICBNT0RVTEVTX09WRVJSSURFPSJzcGxhc2giCgpv cHRpb25zIAlJTkVUCQkJI0ludGVyTkVUd29ya2luZwpvcHRpb25zIAlGRlMJCQkjQmVya2VsZXkg RmFzdCBGaWxlc3lzdGVtCm9wdGlvbnMgCUZGU19ST09UCQkjRkZTIHVzYWJsZSBhcyByb290IGRl dmljZSBba2VlcCB0aGlzIV0Kb3B0aW9ucyAJU09GVFVQREFURVMJCSNFbmFibGUgRkZTIHNvZnQg dXBkYXRlcyBzdXBwb3J0Cm9wdGlvbnMgCVVGU19ESVJIQVNICQkjSW1wcm92ZSBwZXJmb3JtYW5j ZSBvbiBiaWcgZGlyZWN0b3JpZXMKb3B0aW9ucyAJTUZTCQkJI01lbW9yeSBGaWxlc3lzdGVtCm9w dGlvbnMgCU1EX1JPT1QJCQkjTUQgaXMgYSBwb3RlbnRpYWwgcm9vdCBkZXZpY2UKb3B0aW9ucyAJ UFJPQ0ZTCQkJI1Byb2Nlc3MgZmlsZXN5c3RlbQpvcHRpb25zIAlDT01QQVRfNDMJCSNDb21wYXRp YmxlIHdpdGggQlNEIDQuMyBbS0VFUCBUSElTIV0Kb3B0aW9ucyAJU0NTSV9ERUxBWT0xMDAwCSAg ICAgICAgI0RlbGF5IChpbiBtcykgYmVmb3JlIHByb2JpbmcgU0NTSQpvcHRpb25zIAlVQ09OU09M RQkJI0FsbG93IHVzZXJzIHRvIGdyYWIgdGhlIGNvbnNvbGUKb3B0aW9ucyAJS1RSQUNFCQkJI2t0 cmFjZSgxKSBzdXBwb3J0Cm9wdGlvbnMgCVNZU1ZTSE0JCQkjU1lTVi1zdHlsZSBzaGFyZWQgbWVt b3J5Cm9wdGlvbnMgCVNZU1ZNU0cJCQkjU1lTVi1zdHlsZSBtZXNzYWdlIHF1ZXVlcwpvcHRpb25z IAlTWVNWU0VNCQkJI1NZU1Ytc3R5bGUgc2VtYXBob3JlcwpvcHRpb25zIAlQMTAwM18xQgkJI1Bv c2l4IFAxMDAzXzFCIHJlYWwtdGltZSBleHRlbnNpb25zCm9wdGlvbnMgCV9LUE9TSVhfUFJJT1JJ VFlfU0NIRURVTElORwpvcHRpb25zIAlJQ01QX0JBTkRMSU0JCSNSYXRlIGxpbWl0IGJhZCByZXBs aWVzCm9wdGlvbnMgCUtCRF9JTlNUQUxMX0NERVYJIyBpbnN0YWxsIGEgQ0RFViBlbnRyeSBpbiAv ZGV2CgpvcHRpb25zICAgICAgICAgU01CRlMKb3B0aW9ucyAJTkVUU01CCQkJI1NNQi9DSUZTIHJl cXVlc3RlcgpvcHRpb25zIAlORVRTTUJDUllQVE8JCSNlbmNyeXB0ZWQgcGFzc3dvcmQgc3VwcG9y dCBmb3IgU01CCm9wdGlvbnMgCUxJQk1DSEFJTgkJI21idWYgbWFuYWdlbWVudCBsaWJyYXJ5Cm9w dGlvbnMgCUxJQklDT05WCgpvcHRpb25zIAlEREIKIyNvcHRpb25zICAgICAgICAgREVCVUdfTE9D S1MKIyNvcHRpb25zICAgICAgICAgS0JESU9fREVCVUcKIyNvcHRpb25zICAgICAgICAgU0NfREVC VUdfTEVWRUw9NQoKI29wdGlvbnMgCU5TRkJVRlM9OApvcHRpb25zICAgICAgICAgTk9fU1dBUFBJ TkcKb3B0aW9ucyAgICAgICAgIFBBTklDX1JFQk9PVF9XQUlUX1RJTUU9NjAKCm9wdGlvbnMgCUlQ RklSRVdBTEwJCSNmaXJld2FsbApvcHRpb25zICAgICAgICAgSVBGSVJFV0FMTF9ERUZBVUxUX1RP X0FDQ0VQVAoKZGV2aWNlCQlpc2EKZGV2aWNlCQlwY2kKCiMgQVRBIGFuZCBBVEFQSSBkZXZpY2Vz CmRldmljZQkJYXRhCmRldmljZQkJYXRhZGlzawkJCSMgQVRBIGRpc2sgZHJpdmVzCm9wdGlvbnMg CUFUQV9TVEFUSUNfSUQJCSNTdGF0aWMgZGV2aWNlIG51bWJlcmluZwoKIyBhdGtiZGMwIGNvbnRy b2xzIGJvdGggdGhlIGtleWJvYXJkIGFuZCB0aGUgUFMvMiBtb3VzZQpkZXZpY2UJCWF0a2JkYzAJ YXQgaXNhPyBwb3J0IElPX0tCRApkZXZpY2UJCWF0a2JkMAlhdCBhdGtiZGM/IGlycSAxIGZsYWdz IDB4MgojI2RldmljZQkJcHNtMAlhdCBhdGtiZGM/IGlycSAxMgpvcHRpb25zIAlBVEtCRF9ERkxU X0tFWU1BUAkjIHNwZWNpZnkgdGhlIGJ1aWx0LWluIGtleW1hcAptYWtlb3B0aW9ucwlBVEtCRF9E RkxUX0tFWU1BUD0iZ2VybWFuLmlzbyIKCmRldmljZQkJdmdhMAlhdCBpc2E/CiMjb3B0aW9ucyAJ VkVTQQoKIyBzcGxhc2ggc2NyZWVuL3NjcmVlbiBzYXZlcgpwc2V1ZG8tZGV2aWNlCXNwbGFzaAoK IyBzeXNjb25zIGlzIHRoZSBkZWZhdWx0IGNvbnNvbGUgZHJpdmVyLCByZXNlbWJsaW5nIGFuIFND TyBjb25zb2xlCiMjZGV2aWNlCQlzYzAJYXQgaXNhPyBmbGFncyAweDEwMApkZXZpY2UJCXNjMAlh dCBpc2E/IGZsYWdzIDB4MAoKb3B0aW9ucyAJU0NfRElTQUJMRV9SRUJPT1QJIyBkaXNhYmxlIHJl Ym9vdCBrZXkgc2VxdWVuY2UKI29wdGlvbnMgCVNDX0RJU0FCTEVfRERCS0VZCSMgZGlzYWJsZSBg ZGVidWcnIGtleQpvcHRpb25zIAlTQ19LRVJORUxfQ09OU19BVFRSPSIoRkdfR1JFRU58QkdfQkxB Q0spIgpvcHRpb25zIAlTQ19LRVJORUxfQ09OU19SRVZfQVRUUj0iKEZHX0JMQUNLfEJHX0xJR0hU R1JFWSkiCiMjb3B0aW9ucyAJU0NfUElYRUxfTU9ERQkJIyBhZGQgc3VwcG9ydCBmb3IgdGhlIHJh c3RlciB0ZXh0IG1vZGUKIyNvcHRpb25zICAgICAgIFNDX0hJU1RPUllfU0laRT0xMDAwCgpkZXZp Y2UJCWFncAkJIyBzdXBwb3J0IHNldmVyYWwgQUdQIGNoaXBzZXRzCgojIEZsb2F0aW5nIHBvaW50 IHN1cHBvcnQgLSBkbyBub3QgZGlzYWJsZS4KZGV2aWNlCQlucHgwCWF0IG5leHVzPyBwb3J0IElP X05QWCBpcnEgMTMKCm9wdGlvbnMgICAgICAgICBDT01fTVVMVElQT1JUCmRldmljZQkJc2lvMAlh dCBpc2E/IHBvcnQgSU9fQ09NMSBmbGFncyAweDkwICBpcnEgIDQKZGV2aWNlCQlzaW8xCWF0IGlz YT8gcG9ydCBJT19DT00yICAgICAgICAgICAgIGlycSAgMwpkZXZpY2UJCXNpbzIJYXQgaXNhPyBw b3J0IElPX0NPTTMgZmxhZ3MgMHgzMDUgICAgICAgICMgXCBzaGFyZWQKZGV2aWNlCQlzaW8zCWF0 IGlzYT8gcG9ydCBJT19DT000IGZsYWdzIDB4MzA1IGlycSAxMCAjIC8gaXJxIGdyb3VwCmRldmlj ZQkJc2lvNAlhdCBpc2E/IHBvcnQgMHg4MTAwICBmbGFncyAweDUwNSAgICAgICAgIyBcIHNoYXJl ZApkZXZpY2UJCXNpbzUJYXQgaXNhPyBwb3J0IDB4ODEwOCAgZmxhZ3MgMHg1MDUgaXJxICA5ICMg LyBpcnEgZ3JvdXAKCiMgUGFyYWxsZWwgcG9ydApkZXZpY2UJCXBwYzAJYXQgaXNhPyBpcnEgNwpk ZXZpY2UJCXBwYnVzCQkjIFBhcmFsbGVsIHBvcnQgYnVzIChyZXF1aXJlZCkKZGV2aWNlCQlscHQJ CSMgUHJpbnRlcgpkZXZpY2UJCXBwaQoKIyBQQ0kgRXRoZXJuZXQgTklDcyB0aGF0IHVzZSB0aGUg Y29tbW9uIE1JSSBidXMgY29udHJvbGxlciBjb2RlLgojIE5PVEU6IEJlIHN1cmUgdG8ga2VlcCB0 aGUgJ2RldmljZSBtaWlidXMnIGxpbmUgaW4gb3JkZXIgdG8gdXNlIHRoZXNlIE5JQ3MhCmRldmlj ZQkJbWlpYnVzCQkjIE1JSSBidXMgc3VwcG9ydApkZXZpY2UJCWZ4cAkJIyBJbnRlbCBFdGhlckV4 cHJlc3MgUFJPLzEwMEIgKDgyNTU3LCA4MjU1OCkKCiMgUHNldWRvIGRldmljZXMgLSB0aGUgbnVt YmVyIGluZGljYXRlcyBob3cgbWFueSB1bml0cyB0byBhbGxvY2F0ZS4KcHNldWRvLWRldmljZQls b29wCQkjIE5ldHdvcmsgbG9vcGJhY2sKcHNldWRvLWRldmljZQlldGhlcgkJIyBFdGhlcm5ldCBz dXBwb3J0CnBzZXVkby1kZXZpY2UJc2wJMQkjIEtlcm5lbCBTTElQCnBzZXVkby1kZXZpY2UJcHBw CTEJIyBLZXJuZWwgUFBQCnBzZXVkby1kZXZpY2UJdHVuCQkjIFBhY2tldCB0dW5uZWwuCnBzZXVk by1kZXZpY2UJcHR5CQkjIFBzZXVkby10dHlzICh0ZWxuZXQgZXRjKQpwc2V1ZG8tZGV2aWNlCW1k CQkjIE1lbW9yeSAiZGlza3MiCgojIFRoZSBgYnBmJyBwc2V1ZG8tZGV2aWNlIGVuYWJsZXMgdGhl IEJlcmtlbGV5IFBhY2tldCBGaWx0ZXIuCiMgQmUgYXdhcmUgb2YgdGhlIGFkbWluaXN0cmF0aXZl IGNvbnNlcXVlbmNlcyBvZiBlbmFibGluZyB0aGlzIQpwc2V1ZG8tZGV2aWNlCWJwZgkJI0Jlcmtl bGV5IHBhY2tldCBmaWx0ZXIKCiMgVVNCIHN1cHBvcnQKZGV2aWNlCQlvaGNpCQkjIE9IQ0kgUENJ LT5VU0IgaW50ZXJmYWNlCmRldmljZQkJdXNiCQkjIFVTQiBCdXMgKHJlcXVpcmVkKQpkZXZpY2UJ CXVnZW4JCSMgR2VuZXJpYwpkZXZpY2UJCXVoaWQJCSMgIkh1bWFuIEludGVyZmFjZSBEZXZpY2Vz IgpkZXZpY2UJCXVrYmQJCSMgS2V5Ym9hcmQKZGV2aWNlCQl1bHB0CQkjIFByaW50ZXIKCm9wdGlv bnMgCVVLQkRfREZMVF9LRVlNQVAJIyBzcGVjaWZ5IHRoZSBidWlsdC1pbiBrZXltYXAKbWFrZW9w dGlvbnMJVUtCRF9ERkxUX0tFWU1BUD0iZ2VybWFuLmlzbyIK ------=_NextPart_000_0001_01C5729B.BBDDCDA0-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 16 20:15:59 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 50AA316A41C for ; Thu, 16 Jun 2005 20:15:59 +0000 (GMT) (envelope-from shadow@psoft.net) Received: from mail.sevcity.net (mail.sevcity.net [213.227.234.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83DB743D5C for ; Thu, 16 Jun 2005 20:15:58 +0000 (GMT) (envelope-from shadow@psoft.net) Received: from mail.sevcity.net (service.sevcity [127.0.0.1]) by mail.sevcity.net (Postfix) with ESMTP id 8EDF8170006 for ; Thu, 16 Jun 2005 23:15:55 +0300 (EEST) Received: from berloga.shadowland (berloga.shadowland [172.20.2.3]) by mail.sevcity.net (Postfix) with ESMTP id 1E147170004 for ; Thu, 16 Jun 2005 23:15:55 +0300 (EEST) Received: from berloga.shadowland (berloga.shadowland [127.0.0.1] (may be forged)) by berloga.shadowland (8.12.11/8.12.11) with ESMTP id j5GKFsZN004076 for ; Thu, 16 Jun 2005 23:15:54 +0300 Received: (from root@localhost) by berloga.shadowland (8.12.11/8.12.11/Submit) id j5GKFnMW004074 for freebsd-hackers@freebsd.org; Thu, 16 Jun 2005 23:15:50 +0300 From: Alex Lyashkov To: freebsd-hackers@freebsd.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Positive Software Message-Id: <1118952949.2948.51.camel@berloga.shadowland> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-9) Date: Thu, 16 Jun 2005 23:15:49 +0300 X-Virus-Scanned: ClamAV using ClamSMTP Subject: 0xdeadc0de 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, 16 Jun 2005 20:15:59 -0000 Hello All With kernel from RELENG_5_4 (and RELENG_5) compiled with INVARIANTS i have - gw# sysctl -a | grep debug\.kdb\.available | hexdump -C 00000000 64 65 62 75 67 2e 6b 64 62 2e 61 76 61 69 6c 61 |debug.kdb.availa| 00000010 62 6c 65 3a 20 de c0 ad de de c0 ad de de c0 ad |ble: ...........| 00000020 de 60 9b 5c c0 de c0 ad de de c0 ad de de c0 ad |.`.\............| 00000030 de 60 9b 5c c0 0a |.`.\..| 00000036 how can be found what are cause of trouble? how can be found who last freed memory? -- Alex Lyashkov Positive Software From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 16 21:13:37 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8713316A41C for ; Thu, 16 Jun 2005 21:13:37 +0000 (GMT) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe03.swip.net [212.247.154.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2967443D4C for ; Thu, 16 Jun 2005 21:13:36 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: 2oks0tOpjyiYj2pStoKDXw== Received: from mp-216-40-128.daxnet.no ([193.216.40.128] verified) by mailfe03.swip.net (CommuniGate Pro SMTP 4.3.2) with ESMTP id 200838640 for freebsd-hackers@freebsd.org; Thu, 16 Jun 2005 22:41:51 +0200 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Thu, 16 Jun 2005 22:42:37 +0200 User-Agent: KMail/1.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506162242.38227.hselasky@c2i.net> Subject: sppp and Giant X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hselasky@c2i.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2005 21:13:37 -0000 Hi, In some existing code it says: NET_NEEDS_GIANT("i4b_isppp"); s = splimp(); sppp_input(&sc->sc_if, m); splx(s); I have rewritten that code to use its own mutex, but does sppp_input() require Giant to be locked? Can I remove "NET_NEEDS_GIANT(..)" if my "if_start" callback does not require Giant to be locked? --HPS From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 17 10:20:41 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 787C916A41C for ; Fri, 17 Jun 2005 10:20:41 +0000 (GMT) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from comsys.ntu-kpi.kiev.ua (comsys.ntu-kpi.kiev.ua [195.245.194.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id A54B043D49 for ; Fri, 17 Jun 2005 10:20:39 +0000 (GMT) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from pm514-9.comsys.ntu-kpi.kiev.ua (pm514-9.comsys.ntu-kpi.kiev.ua [10.18.54.109]) (authenticated bits=0) by comsys.ntu-kpi.kiev.ua (8.12.10/8.12.10) with ESMTP id j5HAQfFl007952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Jun 2005 13:26:41 +0300 (EEST) Received: by pm514-9.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1000) id B4F34E4; Fri, 17 Jun 2005 13:19:20 +0300 (EEST) Date: Fri, 17 Jun 2005 13:19:20 +0300 From: Andrey Simonenko To: Alex Lyashkov Message-ID: <20050617101920.GA465@pm514-9.comsys.ntu-kpi.kiev.ua> References: <1118952949.2948.51.camel@berloga.shadowland> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1118952949.2948.51.camel@berloga.shadowland> User-Agent: Mutt/1.4.2.1i X-Spam-Status: No, score=-4.5 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on comsys.ntu-kpi.kiev.ua X-Virus-Scanned: ClamAV 0.82/940/Wed Jun 15 09:58:59 2005 on comsys.ntu-kpi.kiev.ua X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org Subject: Re: 0xdeadc0de 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, 17 Jun 2005 10:20:41 -0000 On Thu, Jun 16, 2005 at 11:15:49PM +0300, Alex Lyashkov wrote: > > With kernel from RELENG_5_4 (and RELENG_5) compiled with INVARIANTS > i have - > gw# sysctl -a | grep debug\.kdb\.available | hexdump -C > 00000000 64 65 62 75 67 2e 6b 64 62 2e 61 76 61 69 6c 61 > |debug.kdb.availa| > 00000010 62 6c 65 3a 20 de c0 ad de de c0 ad de de c0 ad |ble: > ...........| > 00000020 de 60 9b 5c c0 de c0 ad de de c0 ad de de c0 ad > |.`.\............| > 00000030 de 60 9b 5c c0 0a |.`.\..| > 00000036 > > how can be found what are cause of trouble? This problem have been already fixed in -HEAD. The source of problem is the subr_kdb.c:kdb_sysctl_available function, which allocates memory for a string, but does not nul terminates it if nothing should be written there. > how can be found who last freed memory? You can see this garbage (old data) as the value of this sysctl variable, just because memory allocated for the value is not zeroed automatically, as pages for an userland process for example. From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 17 10:49:31 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7576B16A41C for ; Fri, 17 Jun 2005 10:49:31 +0000 (GMT) (envelope-from bu7cher@yandex.ru) Received: from mail.rdu.kirov.ru (ns.rdu.kirov.ru [217.9.151.217]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8585543D58 for ; Fri, 17 Jun 2005 10:49:29 +0000 (GMT) (envelope-from bu7cher@yandex.ru) Received: from kirov.so-cdu.ru (kirov [172.21.81.1]) by mail.rdu.kirov.ru (Postfix) with ESMTP id 84EFDFE1C for ; Fri, 17 Jun 2005 14:49:28 +0400 (MSD) Received: from kirov.so-cdu.ru (localhost [127.0.0.1]) by rdu.kirov.ru (Postfix) with SMTP id 6955C1544D for ; Fri, 17 Jun 2005 14:49:28 +0400 (MSD) Received: by rdu.kirov.ru (Postfix, from userid 1014) id 2CBD11544B; Fri, 17 Jun 2005 14:49:28 +0400 (MSD) Received: from [172.21.81.52] (elsukov.kirov.so-cdu.ru [172.21.81.52]) by rdu.kirov.ru (Postfix) with ESMTP id 154451542C for ; Fri, 17 Jun 2005 14:49:28 +0400 (MSD) Message-ID: <42B2AA96.7020905@yandex.ru> Date: Fri, 17 Jun 2005 14:48:54 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: multipart/mixed; boundary="------------070104010906080508070707" Subject: Re: kern/80642: [patch] IPFW small patch - new RULE OPTION 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, 17 Jun 2005 10:49:31 -0000 This is a multi-part message in MIME format. --------------070104010906080508070707 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Robert Watson wrote: > This patch breaks the ABI by inserting a new type into an implicitly > numbered enumeration, renumbering all entries later in the enum. > O_BOUND, if added, should be appended to the end, and/or we should > number the operations explicitly. Ok. I have corrected this. * ipfw_bound.diff - the patch with smallest changes, with only bound option. * ipfw_bound2.diff - bound and check-bound option. Examples: We can limit incoming traffic (internet is external interface): # ipfw add allow ip from any to 10.0.0.20 in recv internet bound 10MB # ipfw add deny ip from any to 10.0.0.0/24 in recv internet We can use traffic shaper after excess of a limit: # ipfw add allow ip from any to 10.0.0.20 in recv internet bound 10MB # ipfw add pipe 1 ip from any to 10.0.0.20 in recv internet # ipfw pipe 1 config bw 5Kbit/s queue 10Kbytes We can block any access after limit excess: # ipfw add 100 allow ip from 10.0.0.20 to any out xmit internet \ check-bound 200 # ipfw add 200 allow ip from any to 10.0.0.20 in recv internet bound \ 10MB # ipfw add 300 deny ip from any to any More details you can read on http://butcher.heavennet.ru/ -- WBR, Andrey V. Elsukov --------------070104010906080508070707 Content-Type: text/plain; name="ipfw_bound.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ipfw_bound.diff" --- sbin/ipfw/ipfw2.c Tue Jun 7 18:11:17 2005 +++ sbin/ipfw/ipfw2.c Fri Jun 17 13:09:43 2005 @@ -277,6 +277,7 @@ TOK_SRCIP6, TOK_IPV4, + TOK_BOUND, }; struct _s_x dummynet_params[] = { @@ -403,6 +404,7 @@ { "dst-ip6", TOK_DSTIP6}, { "src-ipv6", TOK_SRCIP6}, { "src-ip6", TOK_SRCIP6}, + { "bound", TOK_BOUND}, { "//", TOK_COMMENT }, { "not", TOK_NOT }, /* pseudo option */ @@ -1858,6 +1860,10 @@ print_ext6hdr( (ipfw_insn *) cmd ); break; + case O_BOUND: + printf(" bound %u", ((ipfw_insn_u64 *)cmd)->bound); + break; + default: printf(" [opcode %d len %d]", cmd->opcode, cmd->len); @@ -2515,7 +2521,7 @@ " icmp6types LIST | ext6hdr LIST | flow-id N[,N] |\n" " mac ... | mac-type LIST | proto LIST | {recv|xmit|via} {IF|IPADDR} |\n" " setup | {tcpack|tcpseq|tcpwin} NN | tcpflags SPEC | tcpoptions SPEC |\n" -" tcpdatalen LIST | verrevpath | versrcreach | antispoof\n" +" tcpdatalen LIST | verrevpath | versrcreach | antispoof | bound VALUE\n" ); exit(0); } @@ -3683,6 +3689,7 @@ int i; int open_par = 0; /* open parenthesis ( */ + int have_bound = 0; /* proto is here because it is used to fetch ports */ u_char proto = IPPROTO_IP; /* default protocol */ @@ -4492,6 +4499,33 @@ fill_comment(cmd, ac, av); av += ac; ac = 0; + break; + + case TOK_BOUND: + NEED1("bound requires numeric value"); + if (have_bound) + errx(EX_USAGE, "only one of bound is allowed"); + if (open_par) + errx(EX_USAGE, "bound cannot be part " + "of an or block"); + if (cmd->len & F_NOT) + errx(EX_USAGE, + "\"not\" not allowed with bound option"); + { + char *end = NULL; + uint64_t bound = strtoull(*av, &end, 0); + if (bound) + switch (*end){ + case 'G': bound *= 1024; + case 'M': bound *= 1024; + case 'K': bound *= 1024; + }; + cmd->opcode = O_BOUND; + ((ipfw_insn_u64 *)cmd)->bound = bound; + cmd->len = F_INSN_SIZE(ipfw_insn_u64) & F_LEN_MASK; + have_bound = 1; + ac--; av++; + } break; default: --- sys/netinet/ip_fw.h Fri Jun 3 05:10:28 2005 +++ sys/netinet/ip_fw.h Fri Jun 17 11:30:30 2005 @@ -154,6 +154,7 @@ O_NGTEE, /* copy to ng_ipfw */ O_IP4, + O_BOUND, /* u64 = bound in bytes */ O_LAST_OPCODE /* not an opcode! */ }; @@ -228,6 +229,14 @@ ipfw_insn o; u_int32_t d[1]; /* one or more */ } ipfw_insn_u32; + +/* + * This is used to store 64-bit bound value. + */ +typedef struct _ipfw_insn_u64 { + ipfw_insn o; + u_int64_t bound; +} ipfw_insn_u64; /* * This is used to store IP addr-mask pairs. --- sys/netinet/ip_fw2.c Thu Jun 16 18:55:58 2005 +++ sys/netinet/ip_fw2.c Fri Jun 17 11:46:36 2005 @@ -2251,6 +2251,10 @@ * logic to deal with F_NOT and F_OR flags associated * with the opcode. */ + case O_BOUND: + match = (f->bcnt < ((ipfw_insn_u64 *)cmd)->bound); + break; + case O_NOP: match = 1; break; @@ -3387,6 +3391,11 @@ case O_PROB: case O_ICMPTYPE: if (cmdlen != F_INSN_SIZE(ipfw_insn_u32)) + goto bad_size; + break; + + case O_BOUND: + if (cmdlen != F_INSN_SIZE(ipfw_insn_u64)) goto bad_size; break; --------------070104010906080508070707 Content-Type: text/plain; name="ipfw_bound2.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ipfw_bound2.diff" --- sbin/ipfw/ipfw2.c Tue Jun 7 18:11:17 2005 +++ sbin/ipfw/ipfw2.c Fri Jun 17 13:40:54 2005 @@ -277,6 +277,8 @@ TOK_SRCIP6, TOK_IPV4, + TOK_BOUND, + TOK_CHECK_BOUND, }; struct _s_x dummynet_params[] = { @@ -403,6 +405,8 @@ { "dst-ip6", TOK_DSTIP6}, { "src-ipv6", TOK_SRCIP6}, { "src-ip6", TOK_SRCIP6}, + { "bound", TOK_BOUND}, + { "check-bound", TOK_CHECK_BOUND}, { "//", TOK_COMMENT }, { "not", TOK_NOT }, /* pseudo option */ @@ -1636,6 +1640,9 @@ flags |= HAVE_PROTO; break; + case O_BOUND: + break; + default: /*options ... */ if (!(cmd->len & (F_OR|F_NOT))) if (((cmd->opcode == O_IP6) && @@ -1858,6 +1865,10 @@ print_ext6hdr( (ipfw_insn *) cmd ); break; + case O_CHECK_BOUND: + printf(" check-bound %d", cmd->arg1); + break; + default: printf(" [opcode %d len %d]", cmd->opcode, cmd->len); @@ -1872,6 +1883,8 @@ } } show_prerequisites(&flags, HAVE_IP, 0); + if (rule->cmd->opcode == O_BOUND) + printf(" bound %u", ((ipfw_insn_u64 *)(rule->cmd))->bound); if (comment) printf(" // %s", comment); printf("\n"); @@ -2515,7 +2528,8 @@ " icmp6types LIST | ext6hdr LIST | flow-id N[,N] |\n" " mac ... | mac-type LIST | proto LIST | {recv|xmit|via} {IF|IPADDR} |\n" " setup | {tcpack|tcpseq|tcpwin} NN | tcpflags SPEC | tcpoptions SPEC |\n" -" tcpdatalen LIST | verrevpath | versrcreach | antispoof\n" +" tcpdatalen LIST | verrevpath | versrcreach | antispoof | bound VALUE |\n" +" check-bound NUM\n" ); exit(0); } @@ -3677,7 +3691,8 @@ * various flags used to record that we entered some fields. */ ipfw_insn *have_state = NULL; /* check-state or keep-state */ - ipfw_insn *have_log = NULL, *have_altq = NULL; + ipfw_insn *have_log = NULL, *have_altq = NULL, + *have_bound = NULL; size_t len; int i; @@ -4494,6 +4509,39 @@ ac = 0; break; + case TOK_BOUND: + NEED1("bound requires numeric value"); + if (have_bound) + errx(EX_USAGE, "only one of bound is allowed"); + if (open_par) + errx(EX_USAGE, "bound cannot be part " + "of an or block"); + if (cmd->len & F_NOT) + errx(EX_USAGE, + "\"not\" not allowed with bound option"); + { + char *end = NULL; + uint64_t bound = strtoull(*av, &end, 0); + if (bound) + switch (*end){ + case 'G': bound *= 1024; + case 'M': bound *= 1024; + case 'K': bound *= 1024; + }; + cmd->opcode = O_BOUND; + ((ipfw_insn_u64 *)cmd)->bound = bound; + cmd->len = F_INSN_SIZE(ipfw_insn_u64) & F_LEN_MASK; + have_bound = cmd; + ac--; av++; + } + break; + + case TOK_CHECK_BOUND: + NEED1("check-bound requires rule number"); + fill_cmd(cmd, O_CHECK_BOUND, 0, strtoul(*av, NULL, 0)); + ac--; av++; + break; + default: errx(EX_USAGE, "unrecognised option [%d] %s\n", i, s); } @@ -4506,6 +4554,8 @@ done: /* * Now copy stuff into the rule. + * If we have a bound option, the first instruction MUST BE + * a O_BOUND. * If we have a keep-state option, the first instruction * must be a PROBE_STATE (which is generated here). * If we have a LOG option, it was stored as the first command, @@ -4514,7 +4564,15 @@ dst = (ipfw_insn *)rule->cmd; /* - * First thing to write into the command stream is the match probability. + * First write into the command stream bound instruction + */ + if (have_bound) { + bcopy(have_bound, dst, F_LEN(have_bound) * sizeof(uint32_t)); + dst = next_cmd(dst); + } + + /* + * write the match probability */ if (match_prob != 1) { /* 1 means always match */ dst->opcode = O_PROB; @@ -4531,7 +4589,8 @@ dst = next_cmd(dst); } /* - * copy all commands but O_LOG, O_KEEP_STATE, O_LIMIT, O_ALTQ + * copy all commands but O_LOG, O_KEEP_STATE, O_LIMIT, O_ALTQ, + * O_BOUND */ for (src = (ipfw_insn *)cmdbuf; src != cmd; src += i) { i = F_LEN(src); @@ -4541,6 +4600,7 @@ case O_KEEP_STATE: case O_LIMIT: case O_ALTQ: + case O_BOUND: break; default: bcopy(src, dst, i * sizeof(uint32_t)); --- sys/netinet/ip_fw.h Fri Jun 3 05:10:28 2005 +++ sys/netinet/ip_fw.h Fri Jun 17 13:18:47 2005 @@ -154,6 +154,8 @@ O_NGTEE, /* copy to ng_ipfw */ O_IP4, + O_BOUND, /* u64 = bound in bytes */ + O_CHECK_BOUND, /* u16 = rule number */ O_LAST_OPCODE /* not an opcode! */ }; @@ -230,6 +232,14 @@ } ipfw_insn_u32; /* + * This is used to store 64-bit bound value. + */ +typedef struct _ipfw_insn_u64 { + ipfw_insn o; + u_int64_t bound; +} ipfw_insn_u64; + +/* * This is used to store IP addr-mask pairs. */ typedef struct _ipfw_insn_ip { @@ -351,11 +361,16 @@ * * When assembling instruction, remember the following: * + * + if a rule has a "bound" option, then the first instruction + * (at r->cmd) MUST BE an O_BOUND * + if a rule has a "keep-state" (or "limit") option, then the * first instruction (at r->cmd) MUST BE an O_PROBE_STATE * + if a rule has a "log" option, then the first action * (at ACTION_PTR(r)) MUST be O_LOG * + if a rule has an "altq" option, it comes after "log" + * + * NOTE: actually, O_PROB instruction may be first too. But O_BOUND + * MUST BE always first (at r->cmd). * * NOTE: we use a simple linked list of rules because we never need * to delete a rule without scanning the list. We do not use --- sys/netinet/ip_fw2.c Thu Jun 16 18:55:58 2005 +++ sys/netinet/ip_fw2.c Fri Jun 17 13:26:19 2005 @@ -2251,6 +2251,26 @@ * logic to deal with F_NOT and F_OR flags associated * with the opcode. */ + case O_BOUND: + match = (f->bcnt < ((ipfw_insn_u64 *)cmd)->bound); + break; + + case O_CHECK_BOUND: + { + struct ip_fw* rule; + for (rule = f->next; + rule && cmd->arg1 >= rule->rulenum; + rule = rule->next) + if (rule->rulenum == cmd->arg1 && + rule->cmd->opcode == O_BOUND ) + { + match = (rule->bcnt < + ((ipfw_insn_u64 *)(rule->cmd))->bound); + break; + } + } + break; + case O_NOP: match = 1; break; @@ -3373,6 +3393,7 @@ case O_EXT_HDR: case O_IP6: case O_IP4: + case O_CHECK_BOUND: if (cmdlen != F_INSN_SIZE(ipfw_insn)) goto bad_size; break; @@ -3388,6 +3409,16 @@ case O_ICMPTYPE: if (cmdlen != F_INSN_SIZE(ipfw_insn_u32)) goto bad_size; + break; + + case O_BOUND: + if (cmdlen != F_INSN_SIZE(ipfw_insn_u64)) + goto bad_size; + if (cmd != rule->cmd) { + printf("ipfw: bogus rule, opcode %d must be first\n", + cmd->opcode); + return EINVAL; + } break; case O_LIMIT: --------------070104010906080508070707-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 17 16:31:35 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C3B8A16A41C for ; Fri, 17 Jun 2005 16:31:35 +0000 (GMT) (envelope-from french.linuxian@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DFF643D1F for ; Fri, 17 Jun 2005 16:31:35 +0000 (GMT) (envelope-from french.linuxian@gmail.com) Received: by zproxy.gmail.com with SMTP id 12so448428nzp for ; Fri, 17 Jun 2005 09:31:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Pcir6XAyjyVvJ4H8MeIn09mEw4sidguAaSXvjkkfOcCj24tKWwddrmXrM6ajq5fRZhsd6aISTiQ1wm2H27C/EqcmFxWBYl5qiZaKUUT7pTq2MEgQLxZVxxWfCk+lW4Z3FsAVhW5PvU31sR+dCXAIMKE8gvKjpP6wERlGM7r4nh8= Received: by 10.36.61.12 with SMTP id j12mr1454692nza; Fri, 17 Jun 2005 09:31:34 -0700 (PDT) Received: by 10.36.57.3 with HTTP; Fri, 17 Jun 2005 09:31:34 -0700 (PDT) Message-ID: <3727392705061709318b9346f@mail.gmail.com> Date: Fri, 17 Jun 2005 12:31:34 -0400 From: Aziz Kezzou To: freebsd-hackers Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: How to check root powers on a struct proc ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Aziz Kezzou List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2005 16:31:35 -0000 Hi all, I am trying to check that a process (struct proc) has root powers when it calls my KLD system call. I know from kern_jail.c that I can use suser() but this function takes a struct thread* instead of struct proc* although the credentials (struct ucred *p_ucred;) are stored in proc ! Is there an esay way to get a struct thread* from a struct proc* ? or should I simply use the function: int suser_cred(struct ucred *cred, int flag); with cred =3D p-> p_ucred BTW what would the value of flag be? Thanks, -aziz From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 17 16:47:54 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9571916A41C for ; Fri, 17 Jun 2005 16:47:54 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57EB643D1D for ; Fri, 17 Jun 2005 16:47:54 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by rproxy.gmail.com with SMTP id i8so816247rne for ; Fri, 17 Jun 2005 09:47:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=i/9yYxymenij+IdR3NTviNcH4pDpypNTci511ApCOm1CLwGUPXO+HJ46EgotRgrMy+GfOJjJ6r/Z98XLZrMdP0yS2C4kPbQSdsSvfTjsei9gNaQqKXjMONFF0p1Sd42BjN4wqwcaUePFKl5vVlbcfgUjGh/m2yEFINUf9N5cGn4= Received: by 10.38.88.14 with SMTP id l14mr1165097rnb; Fri, 17 Jun 2005 09:47:53 -0700 (PDT) Received: by 10.38.209.73 with HTTP; Fri, 17 Jun 2005 09:47:53 -0700 (PDT) Message-ID: <84dead72050617094731ff2b46@mail.gmail.com> Date: Fri, 17 Jun 2005 22:17:53 +0530 From: Joseph Koshy To: Aziz Kezzou In-Reply-To: <3727392705061709318b9346f@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <3727392705061709318b9346f@mail.gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: How to check root powers on a struct proc ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Joseph Koshy List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2005 16:47:54 -0000 > I am trying to check that a process (struct proc) has root=20 > powers when it calls my KLD system call. Don't you get a 'struct thread *' as an argument to your system call entry point? The 'flag' argument to suser_cred(9) is documented in its manual page. --=20 FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 17 17:18:26 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6A23916A41C for ; Fri, 17 Jun 2005 17:18:26 +0000 (GMT) (envelope-from julian@elischer.org) Received: from delight.idiom.com (delight.idiom.com [216.240.32.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3348343D55 for ; Fri, 17 Jun 2005 17:18:26 +0000 (GMT) (envelope-from julian@elischer.org) Received: from idiom.com (idiom.com [216.240.32.1]) by delight.idiom.com (Postfix) with ESMTP id CBECF1F6EBA; Fri, 17 Jun 2005 10:18:25 -0700 (PDT) Received: from [192.168.2.5] (home.elischer.org [216.240.48.38]) by idiom.com (8.12.11/8.12.11) with ESMTP id j5HHINKW017070; Fri, 17 Jun 2005 10:18:25 -0700 (PDT) (envelope-from julian@elischer.org) Message-ID: <42B305DB.50000@elischer.org> Date: Fri, 17 Jun 2005 10:18:19 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050424 X-Accept-Language: en, hu MIME-Version: 1.0 To: Aziz Kezzou References: <3727392705061709318b9346f@mail.gmail.com> In-Reply-To: <3727392705061709318b9346f@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers Subject: Re: How to check root powers on a struct proc ? 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, 17 Jun 2005 17:18:26 -0000 Aziz Kezzou wrote: > Hi all, > I am trying to check that a process (struct proc) has root powers when > it calls my KLD system call. > I know from kern_jail.c that I can use suser() but this function takes > a struct thread* instead of struct proc* although the credentials > (struct ucred *p_ucred;) are stored in proc ! no.. the thread has a credential that it inherrits from the proc. when a thread changes the credential of the process as a whole, the other threads in the kernel don't notice until they return from their syscalls.. in the mean time they continue to use the reference they hold to the old credential. This is so that a credential doesn;t change half way through a syscall. the active credential at entry will be the active credential for that thread until it completes its time in the kernel. > > Is there an esay way to get a struct thread* from a struct proc* ? or > should I simply use the function: int suser_cred(struct ucred *cred, > int flag); with cred = p-> p_ucred why get a struct proc? the thread has a pointer to the cred it is running under. > > BTW what would the value of flag be? > > Thanks, > -aziz > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 17 18:23:05 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E82C016A41C for ; Fri, 17 Jun 2005 18:23:05 +0000 (GMT) (envelope-from french.linuxian@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id A42A343D48 for ; Fri, 17 Jun 2005 18:23:05 +0000 (GMT) (envelope-from french.linuxian@gmail.com) Received: by zproxy.gmail.com with SMTP id 12so489335nzp for ; Fri, 17 Jun 2005 11:23:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jW3bC1/mBmqyIBL44nliXBg3nDwjCpi3GIiLGjd3Wwim1Kx9Djyyk+JcTzmxsZW2Km4tUyy9/hB2eJbULgfMRo3v8TvEfTsF4GW4yk21FKdCjEAxz64CDD75pMdS7rlNaBYxJSMcLGY3Jw666uo/kjKIUjuetM+slvGMklD68Yo= Received: by 10.36.222.19 with SMTP id u19mr864929nzg; Fri, 17 Jun 2005 11:23:05 -0700 (PDT) Received: by 10.36.57.3 with HTTP; Fri, 17 Jun 2005 11:23:05 -0700 (PDT) Message-ID: <372739270506171123a82a450@mail.gmail.com> Date: Fri, 17 Jun 2005 14:23:05 -0400 From: Aziz Kezzou To: Julian Elischer In-Reply-To: <42B305DB.50000@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <3727392705061709318b9346f@mail.gmail.com> <42B305DB.50000@elischer.org> Cc: freebsd-hackers Subject: Re: How to check root powers on a struct proc ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Aziz Kezzou List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2005 18:23:06 -0000 > Aziz Kezzou wrote: > > Hi all, > > I am trying to check that a process (struct proc) has root powers when > > it calls my KLD system call. > > I know from kern_jail.c that I can use suser() but this function takes > > a struct thread* instead of struct proc* although the credentials > > (struct ucred *p_ucred;) are stored in proc ! >=20 > no.. the thread has a credential that it inherrits from the proc. > when a thread changes the credential of the process as a whole, the > other threads in the kernel don't notice until they return from their > syscalls.. in the mean time they continue to use the reference they > hold to the old credential. This is so that a credential doesn;t change h= alf way > through a syscall. the active credential at entry will be the active cre= dential > for that thread until it completes its time in the kernel. >=20 > > > > Is there an esay way to get a struct thread* from a struct proc* ? or > > should I simply use the function: int suser_cred(struct ucred *cred, > > int flag); with cred =3D p-> p_ucred >=20 > why get a struct proc? the thread has a pointer to the cred it is runnin= g > under. >=20 >=20 I probably didn't make myself clear enough. When my KLD system call is called I get a reference on the calling process as "struct proc *p". Now how do I check if the calling process has root powers ? Would the following work ? : static int ukcoe_register_ud( struct proc *p, struct ukcoe_register_ud_args* arg ) { int error; error =3D suser_cred(p->p_cred, 0); if(error) return error; /* do the actual work*/ return 0; } Thanks, -aziz From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 17 19:03:05 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F75316A41C for ; Fri, 17 Jun 2005 19:03:05 +0000 (GMT) (envelope-from julian@elischer.org) Received: from bigwoop.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B9B143D1F for ; Fri, 17 Jun 2005 19:03:04 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by bigwoop.vicor-nb.com (Postfix) with ESMTP id CFCA37A403; Fri, 17 Jun 2005 12:03:00 -0700 (PDT) Message-ID: <42B31E65.2090803@elischer.org> Date: Fri, 17 Jun 2005 12:03:01 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050423 X-Accept-Language: en, hu MIME-Version: 1.0 To: Aziz Kezzou References: <3727392705061709318b9346f@mail.gmail.com> <42B305DB.50000@elischer.org> <372739270506171123a82a450@mail.gmail.com> In-Reply-To: <372739270506171123a82a450@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers Subject: Re: How to check root powers on a struct proc ? 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, 17 Jun 2005 19:03:05 -0000 Aziz Kezzou wrote: >>Aziz Kezzou wrote: >> >> >>>Hi all, >>>I am trying to check that a process (struct proc) has root powers when >>>it calls my KLD system call. >>>I know from kern_jail.c that I can use suser() but this function takes >>>a struct thread* instead of struct proc* although the credentials >>>(struct ucred *p_ucred;) are stored in proc ! >>> >>> >>no.. the thread has a credential that it inherrits from the proc. >>when a thread changes the credential of the process as a whole, the >>other threads in the kernel don't notice until they return from their >>syscalls.. in the mean time they continue to use the reference they >>hold to the old credential. This is so that a credential doesn;t change half way >>through a syscall. the active credential at entry will be the active credential >>for that thread until it completes its time in the kernel. >> >> >> >>>Is there an esay way to get a struct thread* from a struct proc* ? or >>>should I simply use the function: int suser_cred(struct ucred *cred, >>>int flag); with cred = p-> p_ucred >>> >>> >>why get a struct proc? the thread has a pointer to the cred it is running >>under. >> >> >> >> > >I probably didn't make myself clear enough. >When my KLD system call is called I get a reference on the calling >process as "struct proc *p". Now how do I check if the calling process >has root powers ? > > why do you get a proc*? Who is giving it to you? there is always a thread and it is always better to pass a thread than a proc. because you can trivially go from thread to proc but the converse is not easy.. (there may be many threads) given a thread you can do td->td_proc to find the proc you can also find the current thread easily with "curthread" so the current process is curthread->td_proc >Would the following work ? : >static int ukcoe_register_ud( struct proc *p, struct >ukcoe_register_ud_args* arg ) { >int error; >error = suser_cred(p->p_cred, 0); >if(error) return error; > >/* do the actual work*/ >return 0; >} > >Thanks, >-aziz >_______________________________________________ >freebsd-hackers@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 17 19:37:35 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC4D516A42B for ; Fri, 17 Jun 2005 19:37:35 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id D772443D48 for ; Fri, 17 Jun 2005 19:37:33 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.41.231] (Not Verified[216.133.140.1]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Fri, 17 Jun 2005 15:51:00 -0400 From: John Baldwin To: freebsd-hackers@freebsd.org Date: Fri, 17 Jun 2005 15:36:13 -0400 User-Agent: KMail/1.8 References: <3727392705061709318b9346f@mail.gmail.com> <372739270506171123a82a450@mail.gmail.com> <42B31E65.2090803@elischer.org> In-Reply-To: <42B31E65.2090803@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506171536.14711.jhb@FreeBSD.org> Cc: Julian Elischer , Aziz Kezzou Subject: Re: How to check root powers on a struct proc ? 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, 17 Jun 2005 19:37:36 -0000 On Friday 17 June 2005 03:03 pm, Julian Elischer wrote: > Aziz Kezzou wrote: > >>Aziz Kezzou wrote: > >>>Hi all, > >>>I am trying to check that a process (struct proc) has root powers when > >>>it calls my KLD system call. > >>>I know from kern_jail.c that I can use suser() but this function takes > >>>a struct thread* instead of struct proc* although the credentials > >>>(struct ucred *p_ucred;) are stored in proc ! > >> > >>no.. the thread has a credential that it inherrits from the proc. > >>when a thread changes the credential of the process as a whole, the > >>other threads in the kernel don't notice until they return from their > >>syscalls.. in the mean time they continue to use the reference they > >>hold to the old credential. This is so that a credential doesn;t change > >> half way through a syscall. the active credential at entry will be the > >> active credential for that thread until it completes its time in the > >> kernel. > >> > >>>Is there an esay way to get a struct thread* from a struct proc* ? or > >>>should I simply use the function: int suser_cred(struct ucred *cred, > >>>int flag); with cred = p-> p_ucred > >> > >>why get a struct proc? the thread has a pointer to the cred it is > >> running under. > > > >I probably didn't make myself clear enough. > >When my KLD system call is called I get a reference on the calling > >process as "struct proc *p". Now how do I check if the calling process > >has root powers ? > > why do you get a proc*? Who is giving it to you? > > > there is always a thread and it is always better to pass a thread than a > proc. > because you can trivially go from thread to proc but the converse is not > easy.. > (there may be many threads) > > given a thread you can do td->td_proc to find the proc > > you can also find the current thread easily with "curthread" > > so the current process is curthread->td_proc However, td_ucred can only be used from curthread (it's that way to be fast for curthread on purpose.) > >Would the following work ? : > >static int ukcoe_register_ud( struct proc *p, struct > >ukcoe_register_ud_args* arg ) { > >int error; > >error = suser_cred(p->p_cred, 0); > >if(error) return error; > > > >/* do the actual work*/ > >return 0; > >} You need some locks to avoid walking off a wild pointer. Namely, you need to lock the target process. See the various p_canfoo() functions for some examples. Your code might be something like: int error; PROC_LOCK(p); error = suser_cred(p->p_ucred, 0); PROC_UNLOCK(p); /* * XXX: Note that the cred is now free to change within that process * now that the lock is dropped. */ if (error) return (error); ... return (0); -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 18 08:31:02 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8581816A41C for ; Sat, 18 Jun 2005 08:31:02 +0000 (GMT) (envelope-from toasty@dragondata.com) Received: from mail.dragondata.com (server3-b.your.org [64.202.113.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 534C543D1D for ; Sat, 18 Jun 2005 08:31:00 +0000 (GMT) (envelope-from toasty@dragondata.com) Received: from [69.31.99.45] (pool045.dhcp.your.org [69.31.99.45]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.dragondata.com (Postfix) with ESMTP id A2E1F3D28A0 for ; Sat, 18 Jun 2005 03:30:59 -0500 (CDT) Mime-Version: 1.0 (Apple Message framework v730) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-hackers@freebsd.org From: Kevin Day Date: Sat, 18 Jun 2005 03:30:58 -0500 X-Mailer: Apple Mail (2.730) X-Mailman-Approved-At: Sat, 18 Jun 2005 12:11:44 +0000 Subject: Long uptime 5.2.1 server 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, 18 Jun 2005 08:31:02 -0000 We've got a FreeBSD 5.2.1-RELEASE-p1 server that's been up for 460 days now, with pretty heavy use the whole time (70GB+ per day http traffic, 140 hits/sec, etc). Before we give it a reboot to upgrade, does anyone want to see any counters or stats or anything? I ask because it's sometimes handy to see if your "shouldn't ever happen, but might given enough tries" corner cases ever got used. The obvious vmstat -m: Type InUse MemUse HighUse Requests Size(s) acpidev 64 1K 1K 64 16 acpisem 17 2K 2K 17 64 acpitask 0 0K 1K 2 16,32 acpica 1544 82K 82K 21971 16,32,64,128,256,512,1024 ATA generic 2 1K 1K 2 16,512 atkbddev 2 1K 1K 2 32 nexusdev 3 1K 1K 3 16 memdesc 1 4K 4K 1 4096 I/O APIC 3 2K 2K 3 512 UMAHash 3 4K 4K 9 256,512,1024,2048 VM pgdata 2 65K 65K 2 64 ISOFS mount 1 512K 512K 1 isadev 21 2K 2K 21 64 GEOM 172 23K 25K 578 16,32,64,128,256,512,1024,2048 UFS mount 6 39K 39K 6 256,2048 UFS ihash 1 512K 512K 1 UFS dirhash 1260 232K 233K 13128 16,32,64,128,256,512,2048 newdirblk 0 0K 1K 467 16 dirrem 5 1K 683K 58983277 32 mkdir 0 0K 28K 27680 32 diradd 5 1K 176K 59052465 32 freefile 4 1K 683K 57766630 32 freeblks 4 1K 2330K 66610310 256 freefrag 0 0K 36K 10171714 32 allocindir 0 0K 3514K 970090 64 indirdep 0 0K 97K 334465 32 allocdirect 0 0K 539K111582749 128 bmsafemap 1 1K 1K 4303657 32 newblk 1 1K 1K112552840 64,256 inodedep 26 516K 3245K 68769374 128 pagedep 5 129K 185K 4315757 64 p1003.1b 1 1K 1K 1 16 NFS daemon 1 1K 1K 1 256 NFS hash 1 512K 512K 1 NFSV3 diroff 2 1K 1K 2 512 NFS req 0 0K 2K133534971 64 syncache 1 8K 8K 1 hostcache 1 24K 24K 1 ip_moptions 0 0K 1K 1 128 IpFw/IpAcct 9 1K 1K 15 64,128 dummynet 13 2K 7K 1746 16,128,256 in_multi 3 1K 1K 15 32 igmp 2 1K 1K 2 16 routetbl 203 27K 46K 80626 16,32,64,128,256 pfs_vncache 0 0K 1K 740 32 pfs_fileno 1 20K 20K 1 lo 1 1K 1K 1 512 clone 1 4K 4K 1 4096 ether_multi 12 1K 2K 72 16,32,64 ifaddr 30 7K 7K 31 32,256,512,2048 BPF 3 1K 65K 31 16,64,128,256 mount 19 6K 6K 23 16,32,128,1024 pfs_nodes 20 3K 3K 20 128 vnodes 28 7K 7K 159 16,32,64,128,256 cluster_save buffer 0 0K 1K 1675551 32,64 vfscache 1 1024K 1024K 1 BIO buffer 10 5K 1557K 14609 512,2048 pcb 554 13K 22K199347192 16,32,64,2048 soname 7 1K 81K1961552163 16,128 tag 0 0K 1K 2 16 accf 4 1K 1K 30 16,32 ptys 2 1K 1K 2 512 ttys 1109 142K 176K 604490 128,512 shm 1 12K 14K 5 16,1024 sem 4 7K 7K 4 512,1024,4096 msg 4 25K 25K 4 512,4096 iov 0 0K 1K 28 128,256 ioctlops 0 0K 1K 38 512,1024 turnstiles 3337 209K 209K 3337 64 taskqueue 5 1K 1K 5 64 MSDOSFS mount 1 256K 256K 1 sbuf 0 0K 53K 694 16,32,64,128,256,512,1024,2048,4096 rman 68 5K 5K 419 64 DEVFS 140 21K 21K 143 16,32,128,4096 mbufmgr 1417 296K 296K 1417 32,64,256 USBdev 1 1K 2K 4 128,512 kobj 163 326K 328K 205 2048 eventhandler 35 2K 2K 35 32,128 devstat 10 21K 21K 10 16,4096 USB 12 2K 2K 12 16,32,64,128,256 bus-sc 52 45K 117K 2572 16,32,64,128,256,512,1024,2048,4096 bus 773 36K 153K 4239 16,32,64,128,1024 SWAP 2 549K 549K 2 64 umtx 0 0K 1K 1 32 sysctltmp 0 0K 1K 1863200 16,32,64,256 sysctloid 122 4K 4K 122 16,32,64 sysctl 0 0K 1K 3871363 16,32,64 uidinfo 6 2K 2K 134547 32,1024 entropy 1024 64K 64K 1024 64 cred 157 20K 117K521817590 128 subproc 264 993K 5453K 23808676 32,256,4096 proc 2 8K 8K 2 4096 session 25 4K 22K 2104621 128 pgrp 28 2K 11K 2115123 64 mtx_pool 1 8K 8K 1 module 266 17K 17K 266 64,128 temp 12 178K 294K1432689472 16,32,64,128,256,512,1024,2048,4096 devbuf 1619 1175K 11456K 96864859 16,32,64,128,256,512,1024,2048,4096 lockf 126 8K 48K1349719193 64 ACD driver 1 2K 2K 1 2048 linker 59 831K 836K 133 16,32,256,512,1024,4096 KTRACE 100 13K 13K 100 128 ithread 83 9K 9K 84 64,128 zombie 0 0K 45K 21791472 128 proc-args 29 2K 28K 25101849 16,32,64,128,256 kqueue 167 144K 1130K 90750936 256,1024,2048,4096 kenv 108 6K 6K 109 16,32,64,2048 sigio 1 1K 1K 2 32 file desc 381 96K 564K 21918416 256,512,1024,2048,4096 dev_t 65 17K 17K 65 256 ATA DMA 1 1K 1K 1 128 From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 18 12:35:26 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 202FA16A41C for ; Sat, 18 Jun 2005 12:35:26 +0000 (GMT) (envelope-from dimitry@andric.com) Received: from tensor.xs4all.nl (tensor.xs4all.nl [194.109.160.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBD5E43D49 for ; Sat, 18 Jun 2005 12:35:25 +0000 (GMT) (envelope-from dimitry@andric.com) Received: from kilgore.dim (kilgore.dim [192.168.0.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.xs4all.nl (Postfix) with ESMTP id 8AD87B83F; Sat, 18 Jun 2005 14:35:23 +0200 (CEST) Date: Sat, 18 Jun 2005 14:35:20 +0200 From: Dimitry Andric X-Mailer: The Bat! (v3.5.25) Professional X-Priority: 3 (Normal) Message-ID: <1116331180.20050618143520@andric.com> To: Kevin Day In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="----------691191461F922CCD" Cc: freebsd-hackers@freebsd.org Subject: Re: Long uptime 5.2.1 server X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dimitry Andric List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2005 12:35:26 -0000 ------------691191461F922CCD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On 2005-06-18 at 10:30:58 Kevin Day wrote: > We've got a FreeBSD 5.2.1-RELEASE-p1 server that's been up for 460 > days now, with pretty heavy use the whole time (70GB+ per day http =20 > traffic, 140 hits/sec, etc). Funny that some people insist on complaining about 5.x instability. :P ------------691191461F922CCD Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.1 (MingW32) iD8DBQFCtBUIsF6jCi4glqMRAtILAJ9Oqs+lHLkKeSim6XK11Z5DZY2CbgCgq1yH 576Vw7UXG4Y9ozmFCIOvpwo= =8xEW -----END PGP MESSAGE----- ------------691191461F922CCD-- From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 18 13:15:59 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C3FFC16A41C for ; Sat, 18 Jun 2005 13:15:59 +0000 (GMT) (envelope-from oceanare@pacific.net.sg) Received: from salvador.pacific.net.sg (salvador.pacific.net.sg [203.120.90.219]) by mx1.FreeBSD.org (Postfix) with SMTP id 031E043D4C for ; Sat, 18 Jun 2005 13:15:58 +0000 (GMT) (envelope-from oceanare@pacific.net.sg) Received: (qmail 27981 invoked from network); 18 Jun 2005 13:15:56 -0000 Received: from unknown (HELO maxwell2.pacific.net.sg) (203.120.90.192) by salvador with SMTP; 18 Jun 2005 13:15:56 -0000 Received: from [192.168.0.107] ([210.24.122.16]) by maxwell2.pacific.net.sg with ESMTP id <20050618131556.GJRT28012.maxwell2.pacific.net.sg@[192.168.0.107]>; Sat, 18 Jun 2005 21:15:56 +0800 Message-ID: <42B41E59.3020206@pacific.net.sg> Date: Sat, 18 Jun 2005 21:15:05 +0800 From: Erich Dollansky Organization: oceanare pte ltd User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050514) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dimitry Andric , freebsd-hackers@freebsd.org References: <1116331180.20050618143520@andric.com> In-Reply-To: <1116331180.20050618143520@andric.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Long uptime 5.2.1 server 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, 18 Jun 2005 13:15:59 -0000 Hi, Dimitry Andric wrote: > On 2005-06-18 at 10:30:58 Kevin Day wrote: > > >>We've got a FreeBSD 5.2.1-RELEASE-p1 server that's been up for 460 >>days now, with pretty heavy use the whole time (70GB+ per day http >>traffic, 140 hits/sec, etc). > > > Funny that some people insist on complaining about 5.x instability. :P Mine crashed once during that period of time under much lower load. Wans't it 4.x who set the standard? Erich From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 18 20:03:58 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 79D8A16A41C for ; Sat, 18 Jun 2005 20:03:58 +0000 (GMT) (envelope-from lists-freebsd@silverwraith.com) Received: from keylime.silverwraith.com (keylime.silverwraith.com [69.55.228.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5BB5743D1D for ; Sat, 18 Jun 2005 20:03:58 +0000 (GMT) (envelope-from lists-freebsd@silverwraith.com) Received: from keylime.silverwraith.com ([69.55.228.10]) by keylime.silverwraith.com with esmtp (Exim 4.41 (FreeBSD)) id 1DjjXh-000OWr-UI; Sat, 18 Jun 2005 13:03:49 -0700 Received: (from avleen@localhost) by keylime.silverwraith.com (8.12.11/8.12.11/Submit) id j5IK3jka094251; Sat, 18 Jun 2005 13:03:45 -0700 (PDT) (envelope-from lists-freebsd@silverwraith.com) X-Authentication-Warning: keylime.silverwraith.com: avleen set sender to lists-freebsd@silverwraith.com using -f Date: Sat, 18 Jun 2005 13:03:44 -0700 From: Avleen Vig To: Dimitry Andric Message-ID: <20050618200344.GX11612@silverwraith.com> References: <1116331180.20050618143520@andric.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1116331180.20050618143520@andric.com> User-Agent: Mutt/1.5.6i Cc: freebsd-hackers@freebsd.org, Kevin Day Subject: Re: Long uptime 5.2.1 server 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, 18 Jun 2005 20:03:58 -0000 On Sat, Jun 18, 2005 at 02:35:20PM +0200, Dimitry Andric wrote: > > We've got a FreeBSD 5.2.1-RELEASE-p1 server that's been up for 460 > > days now, with pretty heavy use the whole time (70GB+ per day http > > traffic, 140 hits/sec, etc). > > Funny that some people insist on complaining about 5.x instability. :P There were always two things I would recommend waiting for before moving to 5.x: 1. Performance. I remember reading the after 5.0's release, much debugging code was still in the OS and kernel which would reduce performance. 2. Stability. After 5.0 came out, most production environments were advised not to upgrade or put 5.x out, as we know there were probably many obscure bugs still present and trying to be worked out. (2) was put to rest when -STABLE was branched, but I never heard that (1) was dealt with. I assume it was but it would be nice to be sure :-) -- Avleen Vig Systems Administrator Personal: www.silverwraith.com Screams are expressions of pure joy & fulfillment when extracted in the proper manner. From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 18 20:10:32 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AEC8916A41C for ; Sat, 18 Jun 2005 20:10:32 +0000 (GMT) (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 6753643D4C for ; Sat, 18 Jun 2005 20:10:32 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id B3ADC60F3; Sat, 18 Jun 2005 22:10:24 +0200 (CEST) Received: from xps.des.no (des.no [80.203.228.37]) by tim.des.no (Postfix) with ESMTP id 4C8F360F2; Sat, 18 Jun 2005 22:10:24 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id 22FC533CDC; Sat, 18 Jun 2005 22:10:24 +0200 (CEST) To: Avleen Vig References: <1116331180.20050618143520@andric.com> <20050618200344.GX11612@silverwraith.com> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Sat, 18 Jun 2005 22:10:24 +0200 In-Reply-To: <20050618200344.GX11612@silverwraith.com> (Avleen Vig's message of "Sat, 18 Jun 2005 13:03:44 -0700") Message-ID: <863brfe89b.fsf@xps.des.no> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Learn: ham X-Spam-Score: -5.2/5.0 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on tim.des.no Cc: freebsd-hackers@freebsd.org, Dimitry Andric , Kevin Day Subject: Re: Long uptime 5.2.1 server 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, 18 Jun 2005 20:10:32 -0000 Avleen Vig writes: > There were always two things I would recommend waiting for before moving > to 5.x: > 1. Performance. I remember reading the after 5.0's release, much > debugging code was still in the OS and kernel which would reduce > performance. This debugging code is controlled by kernel options (INVARIANTS, WITNESS etc.). Those options were included in GENERIC in early 5.x releases, but were removed before 5.3 (and you could always remove or comment them out yourself). DES --=20 Dag-Erling Sm=F8rgrav - des@des.no