From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 16 10:59:30 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 892CD1065674 for ; Sun, 16 Jan 2011 10:59:30 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.c2i.net [212.247.154.34]) by mx1.freebsd.org (Postfix) with ESMTP id 144B78FC12 for ; Sun, 16 Jan 2011 10:59:29 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=V/BmsFzUvwB31XiPFgiZP9ZGx4++v9AH3cfAZ6JEaj8= c=1 sm=1 a=kf_XjstXatAA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=KmZ2arK2X3fM58_jNygA:9 a=_-J18OKGbEUfS6NXWEYA:7 a=4-U7Gzy7VGPv7lVPD6NjSU_X2ZMA:4 a=wPNLvfGTeEIA:10 a=mQPT0gYxG-YxHJGG:21 a=TRTxitl6H9e8qLYs:21 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe02.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 74754498; Sun, 16 Jan 2011 11:49:26 +0100 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Sun, 16 Jan 2011 11:49:28 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-PRERELEASE; KDE/4.4.5; amd64; ; ) References: In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201101161149.28569.hselasky@c2i.net> Cc: Mark Felder , Aryeh Friedman Subject: Re: Android development (was Re: best way to run -RELEASE and -CURRENT on the same machine) 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, 16 Jan 2011 10:59:30 -0000 On Saturday 15 January 2011 22:55:30 Aryeh Friedman wrote: > I am brand new to the whole android development thing... All I know is > the phone some how makes it self look like a Linux machine to the > outside world (how and such I have no clue)... when I connected it to > USB I got: > > ugen5.2: at usbus5 > umass0: on usbus5 > umass0: SCSI over Bulk-Only; quirks = 0x0000 > umass0:0:0:-1: Attached to scbus0 > (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error > (probe0:umass-sim0:0:0:0): SCSI status: Check Condition > (probe0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power > on, reset, or bus device reset occurred) > (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error > (probe0:umass-sim0:0:0:0): SCSI status: Check Condition > (probe0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not > present) da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > da0: Removable Direct Access SCSI-2 device > da0: 40.000MB/s transfers > da0: Attempt to query device size failed: NOT READY, Medium not present > > My mother board has a built in NIC so I think no WiFi there but I go > through a NetGear 54g router so if you can tell me the default IP or > anything else that would be helpful (the phone is completely set to > factory defaults has no SIM card or service) You could try loading the if_cdce kernel, else if your ADB client is using LibUSB it should work. --HPS From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 16 11:48:01 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2073106566B for ; Sun, 16 Jan 2011 11:48:01 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.c2i.net [212.247.154.194]) by mx1.freebsd.org (Postfix) with ESMTP id 3E4D28FC1A for ; Sun, 16 Jan 2011 11:48:00 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=47jFoQlQiPaXYvJJRPLdRbboc2AFRw6czTf8DabKp4c= c=1 sm=1 a=kf_XjstXatAA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=VPD-ovXZMJd_bjzVx3MA:9 a=7CLXsUY3M1iHWsa6dq_6EPD7MxQA:4 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 74767023; Sun, 16 Jan 2011 12:47:59 +0100 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Sun, 16 Jan 2011 12:48:01 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-PRERELEASE; KDE/4.4.5; amd64; ; ) References: <201101161149.28569.hselasky@c2i.net> In-Reply-To: <201101161149.28569.hselasky@c2i.net> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201101161248.01865.hselasky@c2i.net> Cc: Mark Felder , Aryeh Friedman Subject: Re: Android development (was Re: best way to run -RELEASE and -CURRENT on the same machine) 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, 16 Jan 2011 11:48:01 -0000 On Sunday 16 January 2011 11:49:28 Hans Petter Selasky wrote: > if_cdce kernel, if_cdce kernel module --HPS From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 16 11:59:18 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AECBF106566B for ; Sun, 16 Jan 2011 11:59:18 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 43E6E8FC0C for ; Sun, 16 Jan 2011 11:59:17 +0000 (UTC) Received: by wwf26 with SMTP id 26so4422466wwf.31 for ; Sun, 16 Jan 2011 03:59:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TnixBm0H+4aNdXwaEiqUvAWgjMcrIPy1TUdJmXuBHIM=; b=tT9HMn410OrhoexQRJAKIKca1+2VaXWPL5qi6SiUf7XCQF6nh6Jz8AX47RXk7za3CW wvsLgB+6bQdxlmii6kBYK22NvtLvRYSttirW4XqUK/ahuSugM6LkbAQSRPDkTsRXrfWU SkSwsOHCTjapyjH+JzQDD7215D1BL59aNSjwc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=W6fxXfAL+cLYxxvUGrC3BtgS2lI2Fjb0txC2J6XYi4aHuUXEcMZVvAYFk+Mdk+W2x2 orz19PO5sfrdQeBbcAxVwpj6BQtuDsJ6mTkTr4DbZmCgzJ8VR13XWOVgfqhijysbmlpl uXeRo6FSRH8TEgNu9osfKOELoi+/tgdL6Fquw= MIME-Version: 1.0 Received: by 10.216.39.196 with SMTP id d46mr2171167web.114.1295179157061; Sun, 16 Jan 2011 03:59:17 -0800 (PST) Received: by 10.216.52.66 with HTTP; Sun, 16 Jan 2011 03:59:17 -0800 (PST) In-Reply-To: <201101161248.01865.hselasky@c2i.net> References: <201101161149.28569.hselasky@c2i.net> <201101161248.01865.hselasky@c2i.net> Date: Sun, 16 Jan 2011 06:59:17 -0500 Message-ID: From: Aryeh Friedman To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, Mark Felder Subject: Re: Android development (was Re: best way to run -RELEASE and -CURRENT on the same machine) 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, 16 Jan 2011 11:59:18 -0000 On Sun, Jan 16, 2011 at 6:48 AM, Hans Petter Selasky wrote: > On Sunday 16 January 2011 11:49:28 Hans Petter Selasky wrote: >> if_cdce kernel, > > if_cdce kernel module > > --HPS > flosoft-stable# kldload if_cdce kldload: can't load if_cdce: File exists From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 16 12:07:16 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87997106566C for ; Sun, 16 Jan 2011 12:07:16 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.c2i.net [212.247.154.226]) by mx1.freebsd.org (Postfix) with ESMTP id 174578FC16 for ; Sun, 16 Jan 2011 12:07:15 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=Samd3CrC35PkFKGRAwjtIWdtalA6bcxM9GrYwcNK+gA= c=1 sm=1 a=kf_XjstXatAA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=8kQB0OdkAAAA:8 a=OAmtt0BQQRiPk8MAxh0A:9 a=wR2pEuPZwlmhdEfxJhHPzTh96XsA:4 a=wPNLvfGTeEIA:10 a=9aOQ2cSd83gA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe08.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 74671641; Sun, 16 Jan 2011 13:07:14 +0100 From: Hans Petter Selasky To: Aryeh Friedman Date: Sun, 16 Jan 2011 13:07:16 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-PRERELEASE; KDE/4.4.5; amd64; ; ) References: <201101161248.01865.hselasky@c2i.net> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201101161307.16474.hselasky@c2i.net> Cc: freebsd-hackers@freebsd.org, Mark Felder Subject: Re: Android development (was Re: best way to run -RELEASE and -CURRENT on the same machine) 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, 16 Jan 2011 12:07:16 -0000 On Sunday 16 January 2011 12:59:17 Aryeh Friedman wrote: > On Sun, Jan 16, 2011 at 6:48 AM, Hans Petter Selasky wrote: > > On Sunday 16 January 2011 11:49:28 Hans Petter Selasky wrote: > >> if_cdce kernel, > > > > if_cdce kernel module > > > > --HPS > > flosoft-stable# kldload if_cdce > kldload: can't load if_cdce: File exists Any ueX network interfaces? Also: usbconfig -d X.Y dump_device_desc --HPS From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 16 12:20:41 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A8FE106566B for ; Sun, 16 Jan 2011 12:20:41 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1D4F48FC18 for ; Sun, 16 Jan 2011 12:20:40 +0000 (UTC) Received: by wyf19 with SMTP id 19so4373614wyf.13 for ; Sun, 16 Jan 2011 04:20:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=As/I/tCzA/59A65Wt76ralq2L3DDiiL9lCupE4rh2kU=; b=cIXQRpkfaL4JVaOhEQIvO9aT6NKoTclpebv23WvLXnOTZ3XjKIm3Ynnf8NkGcx0BLC pPDzW+PcbyO/QTZK/SLZ8DTMs7YIsjT0fsDjKaSehqCwt1WrW4YyXO98kCs9d+JtaMzf y0uBhMfOyRNNmshxnZq4UJEUoVYlcjkdtNVp0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=EsCNl5gQn9+MQHPr+46S4UGPibHTKs2ex4mbun+tTOeFzRrWU0jQsMdzeU3HB5AIVF /lbt34D4xjwRDf14E5jQ89nWgCOwODqEkAYMe9ASo39t5yoABLG7vhE0hJMgCGZ1fweX Ime/kqbpdgiNWW4BRa/B08HbRLT4CRgYg2OyI= MIME-Version: 1.0 Received: by 10.216.154.136 with SMTP id h8mr2255159wek.84.1295180440017; Sun, 16 Jan 2011 04:20:40 -0800 (PST) Received: by 10.216.52.66 with HTTP; Sun, 16 Jan 2011 04:20:39 -0800 (PST) In-Reply-To: <201101161307.16474.hselasky@c2i.net> References: <201101161248.01865.hselasky@c2i.net> <201101161307.16474.hselasky@c2i.net> Date: Sun, 16 Jan 2011 07:20:39 -0500 Message-ID: From: Aryeh Friedman To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, Mark Felder Subject: Re: Android development (was Re: best way to run -RELEASE and -CURRENT on the same machine) 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, 16 Jan 2011 12:20:41 -0000 On Sun, Jan 16, 2011 at 7:07 AM, Hans Petter Selasky wrote: > On Sunday 16 January 2011 12:59:17 Aryeh Friedman wrote: >> On Sun, Jan 16, 2011 at 6:48 AM, Hans Petter Selasky > wrote: >> > On Sunday 16 January 2011 11:49:28 Hans Petter Selasky wrote: >> >> if_cdce kernel, >> > >> > if_cdce kernel module >> > >> > --HPS >> >> flosoft-stable# kldload if_cdce >> kldload: can't load if_cdce: File exists > > Any ueX network interfaces? None > > Also: > > usbconfig -d X.Y dump_device_desc flosoft-stable# usbconfig -d 5.2 dump_device_desc ugen5.2: at usbus5, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0102 bDeviceClass = 0x0000 bDeviceSubClass = 0x0000 bDeviceProtocol = 0x0000 bMaxPacketSize0 = 0x0040 idVendor = 0x0bb4 idProduct = 0x0c02 bcdDevice = 0x0100 iManufacturer = 0x0003 iProduct = 0x0002 iSerialNumber = 0x0001 bNumConfigurations = 0x0001 From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 16 12:27:29 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C1881065670 for ; Sun, 16 Jan 2011 12:27:29 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe03.c2i.net [212.247.154.66]) by mx1.freebsd.org (Postfix) with ESMTP id 9F8AE8FC13 for ; Sun, 16 Jan 2011 12:27:28 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=YBW/O6h5Sxti+EPY3DQm/1QFLiJsbZukn1QSWKMgb2w= c=1 sm=1 a=kf_XjstXatAA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=8kQB0OdkAAAA:8 a=1goxF4CluGYC4uzV5K4A:9 a=0mCq9p6-L7kg1K2G127eDCBzQ2AA:4 a=wPNLvfGTeEIA:10 a=9aOQ2cSd83gA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe03.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 74888747; Sun, 16 Jan 2011 13:27:27 +0100 From: Hans Petter Selasky To: Aryeh Friedman Date: Sun, 16 Jan 2011 13:27:29 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-PRERELEASE; KDE/4.4.5; amd64; ; ) References: <201101161307.16474.hselasky@c2i.net> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201101161327.29692.hselasky@c2i.net> Cc: freebsd-hackers@freebsd.org, Mark Felder Subject: Re: Android development (was Re: best way to run -RELEASE and -CURRENT on the same machine) 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, 16 Jan 2011 12:27:29 -0000 On Sunday 16 January 2011 13:20:39 Aryeh Friedman wrote: > On Sun, Jan 16, 2011 at 7:07 AM, Hans Petter Selasky wrote: > > On Sunday 16 January 2011 12:59:17 Aryeh Friedman wrote: > >> On Sun, Jan 16, 2011 at 6:48 AM, Hans Petter Selasky > > > > wrote: > >> > On Sunday 16 January 2011 11:49:28 Hans Petter Selasky wrote: > >> >> if_cdce kernel, > >> > > >> > if_cdce kernel module > >> > > >> > --HPS > >> > >> flosoft-stable# kldload if_cdce > >> kldload: can't load if_cdce: File exists > > > > Any ueX network interfaces? > > None > > > Also: > > And what about: usbconfig -d X.Y dump_curr_config_desc --HPS From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 16 12:30:35 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0202D106566B for ; Sun, 16 Jan 2011 12:30:35 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 89AC88FC0C for ; Sun, 16 Jan 2011 12:30:34 +0000 (UTC) Received: by wwf26 with SMTP id 26so4436462wwf.31 for ; Sun, 16 Jan 2011 04:30:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TfSK14UyqUVL/Q3tHJH4lAR+6w2caNAa8DLAderXKa0=; b=d5lW9i5IUnST1s7RpudYdK5QZ4KAxf3y6hoz3P0NZFj+HsHmjpXoYVC51A7sFkBNJE EuN9uFrystX+l7J40/3aNoDECgofra2E9qHvZnIF0COFFC4gq5WJWj4arbeXjIDEAzvm c55HldXG40fOdnIHaZDgtbWes9cyFgZ4Xmd7I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=pzZR8V8dpTOiMNmgBWVFBS3QloITHel0E4iL2hPHHt692Blri8qPVc0MIkXyTIYu+F mmhiK1OSJhGN8yB6/xByNY/fuTjEnugKqC82x7WTTAemxOsj4+f6O/UdXlqMCQAp9uS4 1cJ5AgSK+XxHFU8gclIzk/uDwm1oA3WU1xlxk= MIME-Version: 1.0 Received: by 10.216.153.210 with SMTP id f60mr1266055wek.114.1295181033053; Sun, 16 Jan 2011 04:30:33 -0800 (PST) Received: by 10.216.52.66 with HTTP; Sun, 16 Jan 2011 04:30:33 -0800 (PST) In-Reply-To: <201101161327.29692.hselasky@c2i.net> References: <201101161307.16474.hselasky@c2i.net> <201101161327.29692.hselasky@c2i.net> Date: Sun, 16 Jan 2011 07:30:33 -0500 Message-ID: From: Aryeh Friedman To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, Mark Felder Subject: Re: Android development (was Re: best way to run -RELEASE and -CURRENT on the same machine) 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, 16 Jan 2011 12:30:35 -0000 On Sun, Jan 16, 2011 at 7:27 AM, Hans Petter Selasky wrote: > On Sunday 16 January 2011 13:20:39 Aryeh Friedman wrote: >> On Sun, Jan 16, 2011 at 7:07 AM, Hans Petter Selasky > wrote: >> > On Sunday 16 January 2011 12:59:17 Aryeh Friedman wrote: >> >> On Sun, Jan 16, 2011 at 6:48 AM, Hans Petter Selasky >> > >> > wrote: >> >> > On Sunday 16 January 2011 11:49:28 Hans Petter Selasky wrote: >> >> >> if_cdce kernel, >> >> > >> >> > if_cdce kernel module >> >> > >> >> > --HPS >> >> >> >> flosoft-stable# kldload if_cdce >> >> kldload: can't load if_cdce: File exists >> > >> > Any ueX network interfaces? >> >> None >> >> > Also: >> > > > And what about: > > usbconfig -d X.Y dump_curr_config_desc flosoft-stable# usbconfig -d 5.2 dump_curr_config_desc ugen5.2: at usbus5, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON Configuration index 0 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x0037 bNumInterfaces = 0x0002 bConfigurationValue = 0x0001 iConfiguration = 0x0000 bmAttributes = 0x0080 bMaxPower = 0x0080 Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0000 bAlternateSetting = 0x0000 bNumEndpoints = 0x0002 bInterfaceClass = 0x0008 bInterfaceSubClass = 0x0006 bInterfaceProtocol = 0x0050 iInterface = 0x0000 Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0001 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0081 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 Interface 1 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0001 bAlternateSetting = 0x0000 bNumEndpoints = 0x0002 bInterfaceClass = 0x00ff bInterfaceSubClass = 0x0042 bInterfaceProtocol = 0x0001 iInterface = 0x0000 Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0002 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0082 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 > > --HPS > From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 16 12:58:26 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DAF7106564A for ; Sun, 16 Jan 2011 12:58:26 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.c2i.net [212.247.154.98]) by mx1.freebsd.org (Postfix) with ESMTP id C6FD58FC15 for ; Sun, 16 Jan 2011 12:58:25 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=jVx+AExU5EFhK37+rVAQq6jxd4lXLYohjT2gqEoUpuc= c=1 sm=1 a=kf_XjstXatAA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=8kQB0OdkAAAA:8 a=597gF8UQPBAQzWMf-nIA:9 a=Ktw01CP4EEy-oYwxXKOZU2aikecA:4 a=wPNLvfGTeEIA:10 a=9aOQ2cSd83gA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 74267273; Sun, 16 Jan 2011 13:58:23 +0100 From: Hans Petter Selasky To: Aryeh Friedman Date: Sun, 16 Jan 2011 13:58:26 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-PRERELEASE; KDE/4.4.5; amd64; ; ) References: <201101161327.29692.hselasky@c2i.net> In-Reply-To: X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201101161358.26075.hselasky@c2i.net> Cc: freebsd-hackers@freebsd.org, Mark Felder Subject: Re: Android development (was Re: best way to run -RELEASE and -CURRENT on the same machine) 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, 16 Jan 2011 12:58:26 -0000 On Sunday 16 January 2011 13:30:33 Aryeh Friedman wrote: > On Sun, Jan 16, 2011 at 7:27 AM, Hans Petter Selasky wrote: > > On Sunday 16 January 2011 13:20:39 Aryeh Friedman wrote: > >> On Sun, Jan 16, 2011 at 7:07 AM, Hans Petter Selasky > > > > wrote: > >> > On Sunday 16 January 2011 12:59:17 Aryeh Friedman wrote: > >> >> On Sun, Jan 16, 2011 at 6:48 AM, Hans Petter Selasky > >> >> > >> > > >> > wrote: > >> >> > On Sunday 16 January 2011 11:49:28 Hans Petter Selasky wrote: > >> >> >> if_cdce kernel, > >> >> > > >> >> > if_cdce kernel module > >> >> > > >> >> > --HPS > >> >> > >> >> flosoft-stable# kldload if_cdce > >> >> kldload: can't load if_cdce: File exists > >> > > >> > Any ueX network interfaces? > >> > >> None > >> > >> > Also: > > And what about: > > > > usbconfig -d X.Y dump_curr_config_desc > > flosoft-stable# usbconfig -d 5.2 dump_curr_config_desc > ugen5.2: at usbus5, cfg=0 md=HOST spd=HIGH (480Mbps) > pwr=ON > > > Configuration index 0 > > bLength = 0x0009 > bDescriptorType = 0x0002 > wTotalLength = 0x0037 > bNumInterfaces = 0x0002 > bConfigurationValue = 0x0001 > iConfiguration = 0x0000 > bmAttributes = 0x0080 > bMaxPower = 0x0080 > > Interface 0 > bLength = 0x0009 > bDescriptorType = 0x0004 > bInterfaceNumber = 0x0000 > bAlternateSetting = 0x0000 > bNumEndpoints = 0x0002 > bInterfaceClass = 0x0008 > bInterfaceSubClass = 0x0006 > bInterfaceProtocol = 0x0050 > iInterface = 0x0000 > > Endpoint 0 > bLength = 0x0007 > bDescriptorType = 0x0005 > bEndpointAddress = 0x0001 > bmAttributes = 0x0002 > wMaxPacketSize = 0x0200 > bInterval = 0x0000 > bRefresh = 0x0000 > bSynchAddress = 0x0000 > > Endpoint 1 > bLength = 0x0007 > bDescriptorType = 0x0005 > bEndpointAddress = 0x0081 > bmAttributes = 0x0002 > wMaxPacketSize = 0x0200 > bInterval = 0x0000 > bRefresh = 0x0000 > bSynchAddress = 0x0000 > > > Interface 1 > bLength = 0x0009 > bDescriptorType = 0x0004 > bInterfaceNumber = 0x0001 > bAlternateSetting = 0x0000 > bNumEndpoints = 0x0002 > bInterfaceClass = 0x00ff > bInterfaceSubClass = 0x0042 > bInterfaceProtocol = 0x0001 > iInterface = 0x0000 > > Endpoint 0 > bLength = 0x0007 > bDescriptorType = 0x0005 > bEndpointAddress = 0x0002 > bmAttributes = 0x0002 > wMaxPacketSize = 0x0200 > bInterval = 0x0000 > bRefresh = 0x0000 > bSynchAddress = 0x0000 > > Endpoint 1 > bLength = 0x0007 > bDescriptorType = 0x0005 > bEndpointAddress = 0x0082 > bmAttributes = 0x0002 > wMaxPacketSize = 0x0200 > bInterval = 0x0000 > bRefresh = 0x0000 > bSynchAddress = 0x0000 Looks like interface 1 is the ADB one (vendor specific). If the ADB client is not using LibUSB then you might get it working by adding the vendor ID and product ID to sys/dev/usb/serial/u3g.c as listed by dump_device_desc . A /dev/cuaU0 will then be created which you can use to transfer data. --HPS From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 16 13:17:26 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29A92106566C for ; Sun, 16 Jan 2011 13:17:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id B946A8FC0C for ; Sun, 16 Jan 2011 13:17:25 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p0GDHHVA014727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Jan 2011 15:17:17 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p0GDHH80065902; Sun, 16 Jan 2011 15:17:17 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p0GDHHlO065901; Sun, 16 Jan 2011 15:17:17 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 16 Jan 2011 15:17:17 +0200 From: Kostik Belousov To: Hans Petter Selasky Message-ID: <20110116131717.GC2518@deviant.kiev.zoral.com.ua> References: <201101161327.29692.hselasky@c2i.net> <201101161358.26075.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6IGTAXksYJqONypD" Content-Disposition: inline In-Reply-To: <201101161358.26075.hselasky@c2i.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org Subject: Re: Android development (was Re: best way to run -RELEASE and -CURRENT on the same machine) 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, 16 Jan 2011 13:17:26 -0000 --6IGTAXksYJqONypD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 16, 2011 at 01:58:26PM +0100, Hans Petter Selasky wrote: > On Sunday 16 January 2011 13:30:33 Aryeh Friedman wrote: > > On Sun, Jan 16, 2011 at 7:27 AM, Hans Petter Selasky = =20 > wrote: > > > On Sunday 16 January 2011 13:20:39 Aryeh Friedman wrote: > > >> On Sun, Jan 16, 2011 at 7:07 AM, Hans Petter Selasky > > >=20 > > > wrote: > > >> > On Sunday 16 January 2011 12:59:17 Aryeh Friedman wrote: > > >> >> On Sun, Jan 16, 2011 at 6:48 AM, Hans Petter Selasky > > >> >> > > >> >=20 > > >> > wrote: > > >> >> > On Sunday 16 January 2011 11:49:28 Hans Petter Selasky wrote: > > >> >> >> if_cdce kernel, > > >> >> >=20 > > >> >> > if_cdce kernel module > > >> >> >=20 > > >> >> > --HPS > > >> >>=20 > > >> >> flosoft-stable# kldload if_cdce > > >> >> kldload: can't load if_cdce: File exists > > >> >=20 > > >> > Any ueX network interfaces? > > >>=20 > > >> None > > >>=20 > > >> > Also: > > > And what about: > > >=20 > > > usbconfig -d X.Y dump_curr_config_desc > >=20 > > flosoft-stable# usbconfig -d 5.2 dump_curr_config_desc > > ugen5.2: at usbus5, cfg=3D0 md=3DHOST spd=3DHIGH (4= 80Mbps) > > pwr=3DON > >=20 > >=20 > > Configuration index 0 > >=20 > > bLength =3D 0x0009 > > bDescriptorType =3D 0x0002 > > wTotalLength =3D 0x0037 > > bNumInterfaces =3D 0x0002 > > bConfigurationValue =3D 0x0001 > > iConfiguration =3D 0x0000 > > bmAttributes =3D 0x0080 > > bMaxPower =3D 0x0080 > >=20 > > Interface 0 > > bLength =3D 0x0009 > > bDescriptorType =3D 0x0004 > > bInterfaceNumber =3D 0x0000 > > bAlternateSetting =3D 0x0000 > > bNumEndpoints =3D 0x0002 > > bInterfaceClass =3D 0x0008 > > bInterfaceSubClass =3D 0x0006 > > bInterfaceProtocol =3D 0x0050 > > iInterface =3D 0x0000 > >=20 > > Endpoint 0 > > bLength =3D 0x0007 > > bDescriptorType =3D 0x0005 > > bEndpointAddress =3D 0x0001 > > bmAttributes =3D 0x0002 > > wMaxPacketSize =3D 0x0200 > > bInterval =3D 0x0000 > > bRefresh =3D 0x0000 > > bSynchAddress =3D 0x0000 > >=20 > > Endpoint 1 > > bLength =3D 0x0007 > > bDescriptorType =3D 0x0005 > > bEndpointAddress =3D 0x0081 > > bmAttributes =3D 0x0002 > > wMaxPacketSize =3D 0x0200 > > bInterval =3D 0x0000 > > bRefresh =3D 0x0000 > > bSynchAddress =3D 0x0000 > >=20 > >=20 > > Interface 1 > > bLength =3D 0x0009 > > bDescriptorType =3D 0x0004 > > bInterfaceNumber =3D 0x0001 > > bAlternateSetting =3D 0x0000 > > bNumEndpoints =3D 0x0002 > > bInterfaceClass =3D 0x00ff > > bInterfaceSubClass =3D 0x0042 > > bInterfaceProtocol =3D 0x0001 > > iInterface =3D 0x0000 > >=20 > > Endpoint 0 > > bLength =3D 0x0007 > > bDescriptorType =3D 0x0005 > > bEndpointAddress =3D 0x0002 > > bmAttributes =3D 0x0002 > > wMaxPacketSize =3D 0x0200 > > bInterval =3D 0x0000 > > bRefresh =3D 0x0000 > > bSynchAddress =3D 0x0000 > >=20 > > Endpoint 1 > > bLength =3D 0x0007 > > bDescriptorType =3D 0x0005 > > bEndpointAddress =3D 0x0082 > > bmAttributes =3D 0x0002 > > wMaxPacketSize =3D 0x0200 > > bInterval =3D 0x0000 > > bRefresh =3D 0x0000 > > bSynchAddress =3D 0x0000 >=20 > Looks like interface 1 is the ADB one (vendor specific). If the ADB clien= t is=20 > not using LibUSB then you might get it working by adding the vendor ID an= d=20 > product ID to sys/dev/usb/serial/u3g.c as listed by dump_device_desc . A= =20 > /dev/cuaU0 will then be created which you can use to transfer data. FWIW, I successfully used adb from freebsd port of android SDK to connect to Samsung Galaxy S. For sure, it only worked on i386, but this is a known issue with libusb. --6IGTAXksYJqONypD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk0y790ACgkQC3+MBN1Mb4ixhwCeJfdJp9+CJ9xyVnMl6WNhDpSH +LAAoINrD1EuuPyPIePPvEXCtghZTny4 =TbkD -----END PGP SIGNATURE----- --6IGTAXksYJqONypD-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 16 14:19:24 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 416CC1065674 for ; Sun, 16 Jan 2011 14:19:24 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id C5F638FC27 for ; Sun, 16 Jan 2011 14:19:23 +0000 (UTC) Received: by wyf19 with SMTP id 19so4427550wyf.13 for ; Sun, 16 Jan 2011 06:19:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yopAKKTl/HwPq30/xUGgsQRN9MwlzeIl71xuzZ4xIlE=; b=MXRQKRx/J/Xztn4guIK25qGdfSRSE86mzKAxptLDl64S7HGO/R3Bm70WzfXslyEfS7 EFqjKr9v7eFRxtr0tafEB1NYrnXfMaiqFnq6NS8eGSjG5yMV09MFduzzbAFCsMdiF0zv 0z+vnwNRnWt8U8W1VH7OxeNKfIDtEIuvoe2M0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=uZJgBqNMibcV3DlFZqwjtDGjF4FaFFcM14QDkV7dFKnBFz/0Ai4nq7iU9vyBSSRJwQ lcCnUuI2cbrrCArqlBeV9m3703gaGA773i1Oimbt8IbuVSiYwpg0mqomDOfWYbZb0rRv Qk9QKGzyDZJUMJyCxDkHI9u/25e/hBaRZoHrI= MIME-Version: 1.0 Received: by 10.216.154.136 with SMTP id h8mr2323107wek.84.1295187562605; Sun, 16 Jan 2011 06:19:22 -0800 (PST) Received: by 10.216.52.66 with HTTP; Sun, 16 Jan 2011 06:19:22 -0800 (PST) In-Reply-To: <20110116131717.GC2518@deviant.kiev.zoral.com.ua> References: <201101161327.29692.hselasky@c2i.net> <201101161358.26075.hselasky@c2i.net> <20110116131717.GC2518@deviant.kiev.zoral.com.ua> Date: Sun, 16 Jan 2011 09:19:22 -0500 Message-ID: From: Aryeh Friedman To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Hans Petter Selasky Subject: Re: Android development (was Re: best way to run -RELEASE and -CURRENT on the same machine) 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, 16 Jan 2011 14:19:24 -0000 Are you talking about BSDoid or FreeDroid? On Sun, Jan 16, 2011 at 8:17 AM, Kostik Belousov wrot= e: > On Sun, Jan 16, 2011 at 01:58:26PM +0100, Hans Petter Selasky wrote: >> On Sunday 16 January 2011 13:30:33 Aryeh Friedman wrote: >> > On Sun, Jan 16, 2011 at 7:27 AM, Hans Petter Selasky >> wrote: >> > > On Sunday 16 January 2011 13:20:39 Aryeh Friedman wrote: >> > >> On Sun, Jan 16, 2011 at 7:07 AM, Hans Petter Selasky >> > > >> > > wrote: >> > >> > On Sunday 16 January 2011 12:59:17 Aryeh Friedman wrote: >> > >> >> On Sun, Jan 16, 2011 at 6:48 AM, Hans Petter Selasky >> > >> >> >> > >> > >> > >> > wrote: >> > >> >> > On Sunday 16 January 2011 11:49:28 Hans Petter Selasky wrote: >> > >> >> >> if_cdce kernel, >> > >> >> > >> > >> >> > if_cdce kernel module >> > >> >> > >> > >> >> > --HPS >> > >> >> >> > >> >> flosoft-stable# kldload if_cdce >> > >> >> kldload: can't load if_cdce: File exists >> > >> > >> > >> > Any ueX network interfaces? >> > >> >> > >> None >> > >> >> > >> > Also: >> > > And what about: >> > > >> > > usbconfig -d X.Y dump_curr_config_desc >> > >> > flosoft-stable# usbconfig -d 5.2 dump_curr_config_desc >> > ugen5.2: at usbus5, cfg=3D0 md=3DHOST spd=3DHIGH (= 480Mbps) >> > pwr=3DON >> > >> > >> > =A0Configuration index 0 >> > >> > =A0 =A0 bLength =3D 0x0009 >> > =A0 =A0 bDescriptorType =3D 0x0002 >> > =A0 =A0 wTotalLength =3D 0x0037 >> > =A0 =A0 bNumInterfaces =3D 0x0002 >> > =A0 =A0 bConfigurationValue =3D 0x0001 >> > =A0 =A0 iConfiguration =3D 0x0000 =A0 >> > =A0 =A0 bmAttributes =3D 0x0080 >> > =A0 =A0 bMaxPower =3D 0x0080 >> > >> > =A0 =A0 Interface 0 >> > =A0 =A0 =A0 bLength =3D 0x0009 >> > =A0 =A0 =A0 bDescriptorType =3D 0x0004 >> > =A0 =A0 =A0 bInterfaceNumber =3D 0x0000 >> > =A0 =A0 =A0 bAlternateSetting =3D 0x0000 >> > =A0 =A0 =A0 bNumEndpoints =3D 0x0002 >> > =A0 =A0 =A0 bInterfaceClass =3D 0x0008 >> > =A0 =A0 =A0 bInterfaceSubClass =3D 0x0006 >> > =A0 =A0 =A0 bInterfaceProtocol =3D 0x0050 >> > =A0 =A0 =A0 iInterface =3D 0x0000 =A0 >> > >> > =A0 =A0 =A0Endpoint 0 >> > =A0 =A0 =A0 =A0 bLength =3D 0x0007 >> > =A0 =A0 =A0 =A0 bDescriptorType =3D 0x0005 >> > =A0 =A0 =A0 =A0 bEndpointAddress =3D 0x0001 =A0 >> > =A0 =A0 =A0 =A0 bmAttributes =3D 0x0002 =A0 >> > =A0 =A0 =A0 =A0 wMaxPacketSize =3D 0x0200 >> > =A0 =A0 =A0 =A0 bInterval =3D 0x0000 >> > =A0 =A0 =A0 =A0 bRefresh =3D 0x0000 >> > =A0 =A0 =A0 =A0 bSynchAddress =3D 0x0000 >> > >> > =A0 =A0 =A0Endpoint 1 >> > =A0 =A0 =A0 =A0 bLength =3D 0x0007 >> > =A0 =A0 =A0 =A0 bDescriptorType =3D 0x0005 >> > =A0 =A0 =A0 =A0 bEndpointAddress =3D 0x0081 =A0 >> > =A0 =A0 =A0 =A0 bmAttributes =3D 0x0002 =A0 >> > =A0 =A0 =A0 =A0 wMaxPacketSize =3D 0x0200 >> > =A0 =A0 =A0 =A0 bInterval =3D 0x0000 >> > =A0 =A0 =A0 =A0 bRefresh =3D 0x0000 >> > =A0 =A0 =A0 =A0 bSynchAddress =3D 0x0000 >> > >> > >> > =A0 =A0 Interface 1 >> > =A0 =A0 =A0 bLength =3D 0x0009 >> > =A0 =A0 =A0 bDescriptorType =3D 0x0004 >> > =A0 =A0 =A0 bInterfaceNumber =3D 0x0001 >> > =A0 =A0 =A0 bAlternateSetting =3D 0x0000 >> > =A0 =A0 =A0 bNumEndpoints =3D 0x0002 >> > =A0 =A0 =A0 bInterfaceClass =3D 0x00ff >> > =A0 =A0 =A0 bInterfaceSubClass =3D 0x0042 >> > =A0 =A0 =A0 bInterfaceProtocol =3D 0x0001 >> > =A0 =A0 =A0 iInterface =3D 0x0000 =A0 >> > >> > =A0 =A0 =A0Endpoint 0 >> > =A0 =A0 =A0 =A0 bLength =3D 0x0007 >> > =A0 =A0 =A0 =A0 bDescriptorType =3D 0x0005 >> > =A0 =A0 =A0 =A0 bEndpointAddress =3D 0x0002 =A0 >> > =A0 =A0 =A0 =A0 bmAttributes =3D 0x0002 =A0 >> > =A0 =A0 =A0 =A0 wMaxPacketSize =3D 0x0200 >> > =A0 =A0 =A0 =A0 bInterval =3D 0x0000 >> > =A0 =A0 =A0 =A0 bRefresh =3D 0x0000 >> > =A0 =A0 =A0 =A0 bSynchAddress =3D 0x0000 >> > >> > =A0 =A0 =A0Endpoint 1 >> > =A0 =A0 =A0 =A0 bLength =3D 0x0007 >> > =A0 =A0 =A0 =A0 bDescriptorType =3D 0x0005 >> > =A0 =A0 =A0 =A0 bEndpointAddress =3D 0x0082 =A0 >> > =A0 =A0 =A0 =A0 bmAttributes =3D 0x0002 =A0 >> > =A0 =A0 =A0 =A0 wMaxPacketSize =3D 0x0200 >> > =A0 =A0 =A0 =A0 bInterval =3D 0x0000 >> > =A0 =A0 =A0 =A0 bRefresh =3D 0x0000 >> > =A0 =A0 =A0 =A0 bSynchAddress =3D 0x0000 >> >> Looks like interface 1 is the ADB one (vendor specific). If the ADB clie= nt is >> not using LibUSB then you might get it working by adding the vendor ID a= nd >> product ID to sys/dev/usb/serial/u3g.c as listed by dump_device_desc . A >> /dev/cuaU0 will then be created which you can use to transfer data. > > FWIW, I successfully used adb from freebsd port of android SDK to > connect to Samsung Galaxy S. For sure, it only worked on i386, but > this is a known issue with libusb. > From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 16 15:06:26 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C49E7106566C for ; Sun, 16 Jan 2011 15:06:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 0A09A8FC17 for ; Sun, 16 Jan 2011 15:06:25 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p0GF6HDR030481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Jan 2011 17:06:17 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p0GF6HMp066367; Sun, 16 Jan 2011 17:06:17 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p0GF6HOE066366; Sun, 16 Jan 2011 17:06:17 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 16 Jan 2011 17:06:17 +0200 From: Kostik Belousov To: Aryeh Friedman Message-ID: <20110116150617.GD2518@deviant.kiev.zoral.com.ua> References: <201101161327.29692.hselasky@c2i.net> <201101161358.26075.hselasky@c2i.net> <20110116131717.GC2518@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OjlPywxCsLltMP9x" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org, Hans Petter Selasky Subject: Re: Android development (was Re: best way to run -RELEASE and -CURRENT on the same machine) 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, 16 Jan 2011 15:06:26 -0000 --OjlPywxCsLltMP9x Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 16, 2011 at 09:19:22AM -0500, Aryeh Friedman wrote: > Are you talking about BSDoid or FreeDroid? I got SDK from http://bsdroid.org. No idea what FreeDroid is. >=20 > On Sun, Jan 16, 2011 at 8:17 AM, Kostik Belousov wr= ote: > > On Sun, Jan 16, 2011 at 01:58:26PM +0100, Hans Petter Selasky wrote: > >> On Sunday 16 January 2011 13:30:33 Aryeh Friedman wrote: > >> > On Sun, Jan 16, 2011 at 7:27 AM, Hans Petter Selasky > >> wrote: > >> > > On Sunday 16 January 2011 13:20:39 Aryeh Friedman wrote: > >> > >> On Sun, Jan 16, 2011 at 7:07 AM, Hans Petter Selasky > >> > > > >> > > wrote: > >> > >> > On Sunday 16 January 2011 12:59:17 Aryeh Friedman wrote: > >> > >> >> On Sun, Jan 16, 2011 at 6:48 AM, Hans Petter Selasky > >> > >> >> > >> > >> > > >> > >> > wrote: > >> > >> >> > On Sunday 16 January 2011 11:49:28 Hans Petter Selasky wrote: > >> > >> >> >> if_cdce kernel, > >> > >> >> > > >> > >> >> > if_cdce kernel module > >> > >> >> > > >> > >> >> > --HPS > >> > >> >> > >> > >> >> flosoft-stable# kldload if_cdce > >> > >> >> kldload: can't load if_cdce: File exists > >> > >> > > >> > >> > Any ueX network interfaces? > >> > >> > >> > >> None > >> > >> > >> > >> > Also: > >> > > And what about: > >> > > > >> > > usbconfig -d X.Y dump_curr_config_desc > >> > > >> > flosoft-stable# usbconfig -d 5.2 dump_curr_config_desc > >> > ugen5.2: at usbus5, cfg=3D0 md=3DHOST spd=3DHIGH= (480Mbps) > >> > pwr=3DON > >> > > >> > > >> > =9AConfiguration index 0 > >> > > >> > =9A =9A bLength =3D 0x0009 > >> > =9A =9A bDescriptorType =3D 0x0002 > >> > =9A =9A wTotalLength =3D 0x0037 > >> > =9A =9A bNumInterfaces =3D 0x0002 > >> > =9A =9A bConfigurationValue =3D 0x0001 > >> > =9A =9A iConfiguration =3D 0x0000 =9A > >> > =9A =9A bmAttributes =3D 0x0080 > >> > =9A =9A bMaxPower =3D 0x0080 > >> > > >> > =9A =9A Interface 0 > >> > =9A =9A =9A bLength =3D 0x0009 > >> > =9A =9A =9A bDescriptorType =3D 0x0004 > >> > =9A =9A =9A bInterfaceNumber =3D 0x0000 > >> > =9A =9A =9A bAlternateSetting =3D 0x0000 > >> > =9A =9A =9A bNumEndpoints =3D 0x0002 > >> > =9A =9A =9A bInterfaceClass =3D 0x0008 > >> > =9A =9A =9A bInterfaceSubClass =3D 0x0006 > >> > =9A =9A =9A bInterfaceProtocol =3D 0x0050 > >> > =9A =9A =9A iInterface =3D 0x0000 =9A > >> > > >> > =9A =9A =9AEndpoint 0 > >> > =9A =9A =9A =9A bLength =3D 0x0007 > >> > =9A =9A =9A =9A bDescriptorType =3D 0x0005 > >> > =9A =9A =9A =9A bEndpointAddress =3D 0x0001 =9A > >> > =9A =9A =9A =9A bmAttributes =3D 0x0002 =9A > >> > =9A =9A =9A =9A wMaxPacketSize =3D 0x0200 > >> > =9A =9A =9A =9A bInterval =3D 0x0000 > >> > =9A =9A =9A =9A bRefresh =3D 0x0000 > >> > =9A =9A =9A =9A bSynchAddress =3D 0x0000 > >> > > >> > =9A =9A =9AEndpoint 1 > >> > =9A =9A =9A =9A bLength =3D 0x0007 > >> > =9A =9A =9A =9A bDescriptorType =3D 0x0005 > >> > =9A =9A =9A =9A bEndpointAddress =3D 0x0081 =9A > >> > =9A =9A =9A =9A bmAttributes =3D 0x0002 =9A > >> > =9A =9A =9A =9A wMaxPacketSize =3D 0x0200 > >> > =9A =9A =9A =9A bInterval =3D 0x0000 > >> > =9A =9A =9A =9A bRefresh =3D 0x0000 > >> > =9A =9A =9A =9A bSynchAddress =3D 0x0000 > >> > > >> > > >> > =9A =9A Interface 1 > >> > =9A =9A =9A bLength =3D 0x0009 > >> > =9A =9A =9A bDescriptorType =3D 0x0004 > >> > =9A =9A =9A bInterfaceNumber =3D 0x0001 > >> > =9A =9A =9A bAlternateSetting =3D 0x0000 > >> > =9A =9A =9A bNumEndpoints =3D 0x0002 > >> > =9A =9A =9A bInterfaceClass =3D 0x00ff > >> > =9A =9A =9A bInterfaceSubClass =3D 0x0042 > >> > =9A =9A =9A bInterfaceProtocol =3D 0x0001 > >> > =9A =9A =9A iInterface =3D 0x0000 =9A > >> > > >> > =9A =9A =9AEndpoint 0 > >> > =9A =9A =9A =9A bLength =3D 0x0007 > >> > =9A =9A =9A =9A bDescriptorType =3D 0x0005 > >> > =9A =9A =9A =9A bEndpointAddress =3D 0x0002 =9A > >> > =9A =9A =9A =9A bmAttributes =3D 0x0002 =9A > >> > =9A =9A =9A =9A wMaxPacketSize =3D 0x0200 > >> > =9A =9A =9A =9A bInterval =3D 0x0000 > >> > =9A =9A =9A =9A bRefresh =3D 0x0000 > >> > =9A =9A =9A =9A bSynchAddress =3D 0x0000 > >> > > >> > =9A =9A =9AEndpoint 1 > >> > =9A =9A =9A =9A bLength =3D 0x0007 > >> > =9A =9A =9A =9A bDescriptorType =3D 0x0005 > >> > =9A =9A =9A =9A bEndpointAddress =3D 0x0082 =9A > >> > =9A =9A =9A =9A bmAttributes =3D 0x0002 =9A > >> > =9A =9A =9A =9A wMaxPacketSize =3D 0x0200 > >> > =9A =9A =9A =9A bInterval =3D 0x0000 > >> > =9A =9A =9A =9A bRefresh =3D 0x0000 > >> > =9A =9A =9A =9A bSynchAddress =3D 0x0000 > >> > >> Looks like interface 1 is the ADB one (vendor specific). If the ADB cl= ient is > >> not using LibUSB then you might get it working by adding the vendor ID= and > >> product ID to sys/dev/usb/serial/u3g.c as listed by dump_device_desc .= A > >> /dev/cuaU0 will then be created which you can use to transfer data. > > > > FWIW, I successfully used adb from freebsd port of android SDK to > > connect to Samsung Galaxy S. For sure, it only worked on i386, but > > this is a known issue with libusb. > > --OjlPywxCsLltMP9x Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk0zCWkACgkQC3+MBN1Mb4iKwgCgoO9z1pXuiZ2bHPEjWwg5BuXa izQAn27ht1xBCedKBoEbxolC8Pd+2/iZ =lvcN -----END PGP SIGNATURE----- --OjlPywxCsLltMP9x-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 16 17:17:10 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 756601065673 for ; Sun, 16 Jan 2011 17:17:10 +0000 (UTC) (envelope-from redcrash@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 397828FC18 for ; Sun, 16 Jan 2011 17:17:09 +0000 (UTC) Received: by iwn39 with SMTP id 39so4017623iwn.13 for ; Sun, 16 Jan 2011 09:17:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7If/JHsEtf2vWIcBUtKzg0l+1zBbtOhv1U/mpyQ3Fjk=; b=f3o6zNjUmM9Nk+xfr3OtuBqyXEbsHUnp68vi2VRqhBkrufdqssFuDLYxuFT0Ux6T5L avGDVbPq72t1X3ENtNbcA0gDl1XKIc3sUfGMt9QOQm0e8MaN+axrOwfGSsWWFuYuc27v EHHpb7LcLeZf0KwM3kKlPjhjDr+5verVWmAys= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=lft6kUxVFZNZmizQskyEquVpC5H59QmdKijVpdg4E2gGTtEQ93AczDUoYI9jS6lhA2 e+W6UV665eKMk5cdkwk4x/O/mgV49QpIxVTz6YkM1sDmf8whmYRKWuRILpEARfKPkAWh ZzFAtdzaTlWnbg89LKn2jhXNMtKq2U2Y6h8k4= MIME-Version: 1.0 Received: by 10.231.17.141 with SMTP id s13mr3126985iba.168.1295198229379; Sun, 16 Jan 2011 09:17:09 -0800 (PST) Received: by 10.231.32.194 with HTTP; Sun, 16 Jan 2011 09:17:09 -0800 (PST) In-Reply-To: References: Date: Sun, 16 Jan 2011 18:17:09 +0100 Message-ID: From: Harald Servat To: Oliver Pinter Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: Question about sysctl-ing coretemp module values X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 17:17:10 -0000 2011/1/15 Oliver Pinter > > http://oliverp.teteny.bme.hu/git/?p=base/AiBoost-sensord.git;a=blob;f=aiboost-sensord.c;h=349b612066eb0514a2d5c3035908e7418ca71500;hb=HEAD > > On 1/15/11, Harald Servat wrote: > > Hello, > > > > First of all, forgive if this is not the appropiate list to ask this. > > Could you point me the correct list if so? > > > > I'm writing a small program to capture the temperature reported by the > > coretemp kernel module. I'm doing this by using the sysctl API. However, > I'm > > facing a problem when reading that value (dev.cpu.0.temperature, for > > example). > > > > man 3 sysctl has an example (labeled as "To retrieve the standard > search > > path for the system utilities:") which seems great to me to know the > length > > of the OID it wants to read before running the "real" sysctl. I wrote a > > similar example (attached) based on that, but it does not work > appropiately. > > The 1st call tells me that len = 4 (whereas the value for > > dev.cpu.0.temperature is "37.0C" which should be 5 if \0 is not counted). > > > > Can anyone shed some light on what I'm doing wrong? > > > > Thank you very much! > > -- > Matthew, Oliver, thank you very much! When I use an int variable instead of a char[4] it works fine. As you stated, the module returns a value in 10ths of K. Now, I've been able to fix the issue. Regards. -- _________________________________________________________________ Fry: You can see how I lived before I met you. Bender: You lived before you met me?! Fry: Yeah, lots of people did. Bender: Really?! From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 16 19:23:57 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FF9C106564A for ; Sun, 16 Jan 2011 19:23:57 +0000 (UTC) (envelope-from magyarimiki@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 18A768FC16 for ; Sun, 16 Jan 2011 19:23:56 +0000 (UTC) Received: by vws9 with SMTP id 9so1757038vws.13 for ; Sun, 16 Jan 2011 11:23:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=scCQ4aXrSZz3CM/2SlXkgrdqrLjSeDJDbzNQFP58xBI=; b=Mk0mLQmhDeLr2MbFFzgFEOeRJGgxRwBgjjIVc957tDxTIm+PPVgsO8qNqFKJYgZG4/ UMC/msSmlYIuntKhs/66Huzi2FA1oP93Zm55LwiX+AaWYmICEURGR0HnzhZZKgg5OxEi sD2ju5uDtmzA7g51oCWCkFrKNs76Dctp2sxso= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=R6+x/YNQecOvGoUiD3lEIq9C7h4q5/4Jksa5mswuj8f1+gjlvuDDrE0p+SUVbEuA6e ziqthwHkzbhHJlnoONx1XxhwDQ/pEfPXEwy9s18/M6J1FQhsQoUOOQ2f/8VKGg16hZib +8PG3UUgyClmj8OWSgKHiELL71DFl6HwLbdOs= MIME-Version: 1.0 Received: by 10.220.185.79 with SMTP id cn15mr1114109vcb.54.1295204239599; Sun, 16 Jan 2011 10:57:19 -0800 (PST) Received: by 10.220.166.6 with HTTP; Sun, 16 Jan 2011 10:57:19 -0800 (PST) Date: Sun, 16 Jan 2011 19:57:19 +0100 Message-ID: From: Miki Magyari To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: problem debugging kernel module using kernel crash dump with kgdb 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, 16 Jan 2011 19:23:57 -0000 hi, I'm new to kernel programming, working on a kernel module and trying to debug a crash dump after a panic. Here is the backtrace: (kgdb) bt #0 doadump () at pcpu.h:246 #1 0xc089cb9e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0xc089ce72 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:590 #3 0xc04d1ab7 in db_panic (addr=Could not find the frame base for "db_panic". ) at /usr/src/sys/ddb/db_command.c:478 #4 0xc04d20e1 in db_command (last_cmdp=0xc0dd2f5c, cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:445 #5 0xc04d223a in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #6 0xc04d40dd in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:229 #7 0xc08cc4e6 in kdb_trap (type=3, code=0, tf=0xc8caa818) at /usr/src/sys/kern/subr_kdb.c:535 #8 0xc0bd4a9b in trap (frame=0xc8caa818) at /usr/src/sys/i386/i386/trap.c:690 #9 0xc0bb5f7b in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #10 0xc08cc66a in kdb_enter (why=0xc0cab4ec "panic", msg=0xc0cab4ec "panic") at cpufunc.h:71 #11 0xc089ce56 in panic (fmt=0xc0ca9eb8 "mtx_lock() of spin mutex %s @ %s:%d") at /usr/src/sys/kern/kern_shutdown.c:573 #12 0xc088d4ea in _mtx_lock_flags (m=0xc2911904, opts=0, file=0xc0cb66ca "/usr/src/sys/kern/vfs_bio.c", line=2545) at /usr/src/sys/kern/kern_mutex.c:197 #13 0xc091a282 in getblk (vp=0xc2911810, blkno=2, size=512, slpflag=0, slptimeo=0, flags=0) at /usr/src/sys/kern/vfs_bio.c:2545 #14 0xc091ab24 in breadn (vp=0xc2911810, blkno=Unhandled dwarf expression opcode 0x93 ) at /usr/src/sys/kern/vfs_bio.c:800 #15 0xc091ac9c in bread (vp=0xc2911810, blkno=Unhandled dwarf expression opcode 0x93 ) at /usr/src/sys/kern/vfs_bio.c:748 #16 0xc286d5b4 in minixfs_mount (mp=0xc2492000) at /usr/src/sys/modules/minixfs/../../fs/minixfs/minixfs_vfsops.c:149 #17 0xc09290a8 in vfs_donmount (td=0xc2817280, fsflags=0, fsoptions=0xc2499780) at /usr/src/sys/kern/vfs_mount.c:988 #18 0xc092a7e5 in nmount (td=0xc2817280, uap=0xc8caacf8) at /usr/src/sys/kern/vfs_mount.c:424 #19 0xc0bd4220 in syscall (frame=0xc8caad38) at /usr/src/sys/i386/i386/trap.c:1111 #20 0xc0bb5fe0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261 after using "f 16" I can use "list" command to see the source code and the bread() call that causes the panic, but I'm unable to investigate local variables for this code part using "i loc". It displays variables for function minixfs_mount, but bread() is actually called from minixfs_mountfs, called by minixfs_mount. Any pointers why this subfunction not shown with "bt" and why I cannot get local variables for it? thanks in advance, Miki From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 16 19:44:43 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 188C0106564A for ; Sun, 16 Jan 2011 19:44:43 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id A277B8FC1C for ; Sun, 16 Jan 2011 19:44:42 +0000 (UTC) Received: by ewy24 with SMTP id 24so2319647ewy.13 for ; Sun, 16 Jan 2011 11:44:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9npoQVL9DnvBE1jMzWQdcYjcannbcYHlUoSm8YhPFaI=; b=ruVYkpR5CwymMs/0LUEbK6L3tvNh0PNXhhicQ0ebFla5jPKG8oAkmhKkoOqvh+92pA bAygvHU63UoHDB4laQqyXFo/VJnP4S5o/yQWWBST3Dxswifk+o+j3MSjj23xy/twYq2G G5xIG2KmTsJl0+4vNAeWcn4e7nw+u9w1Vu9Hg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ZfLK+syC2TJCIpRV7+G0PbkP7SR05CUl735eR11hUP7HYVXazJoetBxaMWxZ7r4uDx lqZyZPkr5OwaJxTn7U/X6rRV6WofVXd2hwLOkAp6L+mNLKQE4Y/6+yn63hAl417yaKQU oSJF1yjSbESbq/ypOZrY5UM7Nn864Uc4Xi+FA= MIME-Version: 1.0 Received: by 10.213.20.78 with SMTP id e14mr2845419ebb.87.1295207081529; Sun, 16 Jan 2011 11:44:41 -0800 (PST) Received: by 10.213.22.14 with HTTP; Sun, 16 Jan 2011 11:44:41 -0800 (PST) In-Reply-To: References: Date: Sun, 16 Jan 2011 14:44:41 -0500 Message-ID: From: Ryan Stone To: Miki Magyari Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: problem debugging kernel module using kernel crash dump with kgdb 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, 16 Jan 2011 19:44:43 -0000 gcc has helpfully inlined minixfs_mountfs into minixfs_mount for you. kgdb, which is basically gdb patched to understand the structure of kernel cores, has no idea how to handle inlined functions. Sadly, you have only two options here that I'm aware of: 1) If the crash is reproducible, recompile you kernel with the attribute __attribute__((noinline)) attached to minixfs_mountfs's prototype. You should get a core that is possible to debug using kgdb. 2) If the crash is difficult to reproduce, the only thing I've been able to do in such a scenario is disassemble the function and try to work out where the variables I'm interested in are. This is extremely painful, so I'd suggest going with option 1 if it's at all feasible. From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 16 19:50:43 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D5431065672 for ; Sun, 16 Jan 2011 19:50:43 +0000 (UTC) (envelope-from magyarimiki@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 096E18FC1C for ; Sun, 16 Jan 2011 19:50:42 +0000 (UTC) Received: by vws9 with SMTP id 9so1761899vws.13 for ; Sun, 16 Jan 2011 11:50:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=zPRbTJpfrcjzvti7i5/cjUvnZEWPp7JbJI/jr1zCulY=; b=i2PbhSJJ9yEVV0xjsg9yg09twvGSrH9rwNbxjozGisX3WJS/781Uhm7bgoch2oqFoT G2BXGNoA9+tyuHpPStgjxRnwW+yBmzjDjZsVj+QCluPEWmcQDFABwKE+YemCTCHJ5W9f k5HF3J9ctu+4W6L4zDK0osn/+MzFrghcFIqKI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=iDiTvXhZHXO0lmiRa5/pQDDaBxnY4tBDbND32fQtpqhDnAjLZdaylrN4Tj8x8I2X+E 6I6PApqM05OXY+fRa9IARgVRM3KBq9kOwUbacgWuvTTaRDJ1vxLEWCKMwTV0LxzzakO1 tQcKgGKSkiS15j1VmsCsy0zF+/olDLhr6kKZc= MIME-Version: 1.0 Received: by 10.220.185.79 with SMTP id cn15mr1125090vcb.54.1295206884529; Sun, 16 Jan 2011 11:41:24 -0800 (PST) Received: by 10.220.166.6 with HTTP; Sun, 16 Jan 2011 11:41:24 -0800 (PST) In-Reply-To: References: Date: Sun, 16 Jan 2011 20:41:24 +0100 Message-ID: From: Miki Magyari To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: problem debugging kernel module using kernel crash dump with kgdb 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, 16 Jan 2011 19:50:43 -0000 > > Any pointers why this subfunction not shown with "bt" and why I cannot > get local variables for it? > hi, after sending this question and having a short break I've just realized that it is caused by the compiler optimization. -O0 seems to help. br, Miki From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 17 10:48:42 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BA57106566B for ; Mon, 17 Jan 2011 10:48:42 +0000 (UTC) (envelope-from magyarimiki@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id F2C858FC13 for ; Mon, 17 Jan 2011 10:48:41 +0000 (UTC) Received: by qyk8 with SMTP id 8so1336405qyk.13 for ; Mon, 17 Jan 2011 02:48:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=4bx2JFQdMM6jPChIVhlx5XvV8k33PkK6k6V0T9Ae9yU=; b=fG3gYXQ5n3qwLuVZr+yifrv+4aC0l+1VpsLcZ5bJ9vYaCfWU1yLBXnVHhW01skz+j4 1eHylWzCbUOhzupyuSloWdP3/gfbhnpjpEcgRwY+VqsrLRHCUiLxGfguH/bfSeWy0mxe a2yHpVi8eSOvzSfM3TOtF8b7nnOtps/iAA/mA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=WLjV4aH53/HLMEbdnpEVu4ELSRgRif6oukX96OD4mcMieRTPgUUiqLT27wtBRf419W Iw3P67LU6K2TI/uDfGYMDUfo4Vx6gEYL97sU3cUFOFGcvTLqJeuvEo+3JgmLwI4trbc6 3/Y7iaGaTRh9Of0gMD2HnOZ9BCVj4Jw5FvKsQ= MIME-Version: 1.0 Received: by 10.224.179.76 with SMTP id bp12mr3716114qab.264.1295261320848; Mon, 17 Jan 2011 02:48:40 -0800 (PST) Received: by 10.220.166.6 with HTTP; Mon, 17 Jan 2011 02:48:40 -0800 (PST) In-Reply-To: References: Date: Mon, 17 Jan 2011 11:48:40 +0100 Message-ID: From: Miki Magyari To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: problem debugging kernel module using kernel crash dump with kgdb 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, 17 Jan 2011 10:48:42 -0000 On Sun, Jan 16, 2011 at 7:57 PM, Miki Magyari wrote= : > hi, > > I'm new to kernel programming, working on a kernel module and trying > to debug a crash dump after a panic. Here is the backtrace: > > (kgdb) bt > #0 =A0doadump () at pcpu.h:246 > #1 =A00xc089cb9e in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown= .c:416 > #2 =A00xc089ce72 in panic (fmt=3DVariable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:590 > #3 =A00xc04d1ab7 in db_panic (addr=3DCould not find the frame base for "d= b_panic". > ) at /usr/src/sys/ddb/db_command.c:478 > #4 =A00xc04d20e1 in db_command (last_cmdp=3D0xc0dd2f5c, cmd_table=3D0x0, > dopager=3D1) at /usr/src/sys/ddb/db_command.c:445 > #5 =A00xc04d223a in db_command_loop () at /usr/src/sys/ddb/db_command.c:4= 98 > #6 =A00xc04d40dd in db_trap (type=3D3, code=3D0) at /usr/src/sys/ddb/db_m= ain.c:229 > #7 =A00xc08cc4e6 in kdb_trap (type=3D3, code=3D0, tf=3D0xc8caa818) at > /usr/src/sys/kern/subr_kdb.c:535 > #8 =A00xc0bd4a9b in trap (frame=3D0xc8caa818) at /usr/src/sys/i386/i386/t= rap.c:690 > #9 =A00xc0bb5f7b in calltrap () at /usr/src/sys/i386/i386/exception.s:165 > #10 0xc08cc66a in kdb_enter (why=3D0xc0cab4ec "panic", msg=3D0xc0cab4ec > "panic") at cpufunc.h:71 > #11 0xc089ce56 in panic (fmt=3D0xc0ca9eb8 "mtx_lock() of spin mutex %s @ > %s:%d") at /usr/src/sys/kern/kern_shutdown.c:573 > #12 0xc088d4ea in _mtx_lock_flags (m=3D0xc2911904, opts=3D0, > file=3D0xc0cb66ca "/usr/src/sys/kern/vfs_bio.c", line=3D2545) at > /usr/src/sys/kern/kern_mutex.c:197 > #13 0xc091a282 in getblk (vp=3D0xc2911810, blkno=3D2, size=3D512, slpflag= =3D0, > slptimeo=3D0, flags=3D0) at /usr/src/sys/kern/vfs_bio.c:2545 > #14 0xc091ab24 in breadn (vp=3D0xc2911810, blkno=3DUnhandled dwarf > expression opcode 0x93 > ) at /usr/src/sys/kern/vfs_bio.c:800 > #15 0xc091ac9c in bread (vp=3D0xc2911810, blkno=3DUnhandled dwarf > expression opcode 0x93 > ) at /usr/src/sys/kern/vfs_bio.c:748 > #16 0xc286d5b4 in minixfs_mount (mp=3D0xc2492000) at > /usr/src/sys/modules/minixfs/../../fs/minixfs/minixfs_vfsops.c:149 > #17 0xc09290a8 in vfs_donmount (td=3D0xc2817280, fsflags=3D0, > fsoptions=3D0xc2499780) at /usr/src/sys/kern/vfs_mount.c:988 > #18 0xc092a7e5 in nmount (td=3D0xc2817280, uap=3D0xc8caacf8) at > /usr/src/sys/kern/vfs_mount.c:424 > #19 0xc0bd4220 in syscall (frame=3D0xc8caad38) at > /usr/src/sys/i386/i386/trap.c:1111 > #20 0xc0bb5fe0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception= .s:261 I'm really stuck with the above panic. I have the feeling it is something wrong with my build as I can produce the same issue with ext2fs code. # cd /sys/modules/ext2fs # make # make load # mount_ext2fs ... causes the same "mtx_lock() of bufobj interlock..." panic. Is it possible that building a module using the above steps produces a .ko that not fully binary compatible with the running kernel? I'm not using GENERIC but a custom kernel built with most of the debugging stuff enabled (witness, invariants, diagnostic...). (I have compared /boot/kernel/ext2fs.ko and ext2fs.ko produced by the above steps and they differ) Any pointers are warmly welcome.. br, Miki From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 17 13:22:52 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BB781065670; Mon, 17 Jan 2011 13:22:52 +0000 (UTC) (envelope-from joris.dedieu@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id D82458FC15; Mon, 17 Jan 2011 13:22:51 +0000 (UTC) Received: by mail-fx0-f54.google.com with SMTP id 16so6125798fxm.13 for ; Mon, 17 Jan 2011 05:22:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=bL+0P8MRt1e99aKNQjSVOQQ4TO4+lzyZdzKv0EenqV4=; b=KWcg7/CyNwVa7h8KyC4xkuGDKYBbxnncVJ3Wi+othT0QFwmJgo+S55lnRpLaR+B51A o6gl9ZJnu9oqLe427dafJSYV0Gnr7CH1D9hCO8VEh2W70ErSkM1GavNnYamNh7eNg4Sl MeeMXeCsnx37vMumWrFle+MEAGi3Hdsun67Lo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=R64RXY+xfbCugZ7r5dG9/yyCoZUSSCZlCV7CZ2pJsy8O3qAPOCyNWiPqgKC5cvXpLK MVrj+m+aoG6J53HiWJ7+1vgP2ApuOR84wffi+cVhpqVeIBNC0x4AsaMILuf7peklgd/4 hSxraF98BLE40klN+lq/NTsmsqT+tBE0tS6vo= MIME-Version: 1.0 Received: by 10.223.86.1 with SMTP id q1mr4818213fal.107.1295270571447; Mon, 17 Jan 2011 05:22:51 -0800 (PST) Received: by 10.223.71.203 with HTTP; Mon, 17 Jan 2011 05:22:51 -0800 (PST) In-Reply-To: <4D2CA5E8.9070003@freebsd.org> References: <4D274C5E.500@freebsd.org> <4D2CA5E8.9070003@freebsd.org> Date: Mon, 17 Jan 2011 14:22:51 +0100 Message-ID: From: joris dedieu To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers Subject: Re: Fwd: binding non local ip. 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, 17 Jan 2011 13:22:52 -0000 Hi Julian and many thanks for your comments. 2011/1/11 Julian Elischer : > On 1/9/11 3:01 PM, joris dedieu wrote: >> >> ---------- Forwarded message ---------- >> From: joris dedieu >> Date: 2011/1/9 >> Subject: Re: binding non local ip. >> To: Julian Elischer >> >> >> 2011/1/7 Julian Elischer: >>> >>> On 1/7/11 4:57 AM, joris dedieu wrote: >>>> >>>> Hi, >>>> I need a to bind non local ips =A0daemons that don't >>>> implement IP_BINDANY sockopt. >>> >>> I'm not sure you need it >>> you can use the ipfw 'fwd' command to make a locally bound >>> socket act and look as if it is bound to a non local address >>> >>> You need to tell us a little more about what you need to do >>> >>> for example, >>> Is the socket just listenning? or is it initiating? >> >> listenning I think. >> Typicaly prepare a spare server. >> eg: >> - Failover as with carp but with more complexes actions has shutting >> down the power of the main server, check data consistency, check if >> the problem is not just a reboot or a buggy service that =A0need to be >> restarted. > > A listenning server can be listenning on a local port and address. > Use ipfw 'fwd' to force it to accept a non-local address socket. > the local address of the listenning socket will be switched to that > of the address on the session. > > e.g. > ipfw add 100 fwd 127.0.0.1,80 tcp from any to 111.123.123.123 in recv em0 > > your local server listenning on 127.0.0.1:80 will end up with a socket wi= th > a local > address of 111.123.123.123 =A0even if that is not any address of yours. > >> - Switch an ip from a main server to a already configured proxy (during = a >> dos) >> - monitor that spare service is running. > > this is easy as shown above As I said above there are several workarounds depending on the context. I agree enabling ipfw is not the worst. In my thought, the goal of this pat= ch is just to offer a simple answer to a simple question. How to bind a non local ip under FreeBSD ? For now the answer is implement = it with IP_BINDANY or do has if (with firewalling) or do it an other way. I know it. I do it that way on my job every days. I just think "turn on sysctl.XXX.YYY", is one of those little things you ar= e happy to find. Best regards Joris > >>>> There are several solutions as patching every single daemon >>>> or using carp (You may not want automatic failover), jailing >>>> the process and of course binding INADDR_ANY when possible ... >>>> >>>> As I'm too lazy for this, I wrote a little (maybe ugly as my >>>> kernel knowledges are really low) patch that add a sysctl >>>> entry in net.inet.ip that allow binding non local ips. It's >>>> maybe buggy and insecure but it seems to work. >>> >>> seems ok, but if the daemon is initiating, how does it know to bind to = a >>> non >>> local address? >> >> It doesn't know. That's the goal. So when the address became local >> it's already ready. So you don't discover that it's misconfigured or >> broken, or that else your dummy colleague has imagined :) . You or a >> script ifconfig the alias and back to bed ! >>> >>> also. if you have source, a single setsockopt() in each one is not much >>> of a >>> job.. >> >> I already do this for haproxy and for apr. But (for haproxy) it seems >> to be too specific to be integrated upstreams. For other services (as >> tomcat) that don't know privileges dropping it's more problematic as >> IP_BINDANY needs in most case root privileges. >> >> I think that a system wide solution should be a good thing. >> Joris >>> > > From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 18 15:48:35 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2AE881065672 for ; Tue, 18 Jan 2011 15:48:35 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id D8B868FC1F for ; Tue, 18 Jan 2011 15:48:34 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1PfDnN-000BsP-9P for freebsd-hackers@freebsd.org; Tue, 18 Jan 2011 17:48:33 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: freebsd-hackers Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Jan 2011 17:48:33 +0200 From: Daniel Braniss Message-ID: Subject: gpart/gstripe problems? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 15:48:35 -0000 I have: sf-03> gpart show => 34 976773101 ada0 GPT (466G) 34 128 1 freebsd-boot (64K) 162 4194304 2 freebsd-ufs (2.0G) 4194466 100663296 3 freebsd-swap (48G) 104857762 871915373 4 freebsd (416G) => 34 976773101 ada1 GPT (466G) 34 128 1 freebsd-boot (64K) 162 4194304 2 freebsd-ufs (2.0G) 4194466 100663296 3 freebsd-swap (48G) 104857762 871915373 4 freebsd (416G) sf-03> ls -ls /dev/ada* 0 crw-r----- 1 root operator 0, 78 Jan 18 14:35 /dev/ada0 0 crw-r----- 1 root operator 0, 80 Jan 18 14:35 /dev/ada0p1 0 crw-r----- 1 root operator 0, 81 Jan 18 14:35 /dev/ada0p2 0 crw-r----- 1 root operator 0, 82 Jan 18 14:35 /dev/ada0p3 0 crw-r----- 1 root operator 0, 83 Jan 18 14:35 /dev/ada0s4 0 crw-r----- 1 root operator 0, 79 Jan 18 14:35 /dev/ada1 0 crw-r----- 1 root operator 0, 84 Jan 18 14:35 /dev/ada1p1 0 crw-r----- 1 root operator 0, 85 Jan 18 14:35 /dev/ada1p2 0 crw-r----- 1 root operator 0, 86 Jan 18 14:35 /dev/ada1p3 0 crw-r----- 1 root operator 0, 87 Jan 18 14:35 /dev/ada1s4 next I did: # gstripe label s0 /dev/ada{0,1}s4 and on the console the following appeared: GEOM_STRIPE: Device s0 activated. GEOM_STRIPE: Cannot add disk gptid/bd0f6e54-22ea-11e0-b27c-001b245d5a5b to s0 (error=17). GEOM_STRIPE: Cannot add disk gptid/bdf7d563-22ea-11e0-b27c-001b245d5a5b to s0 (error=17). is this realy an error? cheers, danny From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 18 16:58:00 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1574106564A for ; Tue, 18 Jan 2011 16:58:00 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 516DB8FC16 for ; Tue, 18 Jan 2011 16:58:00 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PfEsX-0007EG-Nv for freebsd-hackers@freebsd.org; Tue, 18 Jan 2011 17:57:57 +0100 Received: from 213.202.123.54 ([213.202.123.54]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 18 Jan 2011 17:57:57 +0100 Received: from ivoras by 213.202.123.54 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 18 Jan 2011 17:57:57 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Tue, 18 Jan 2011 17:57:47 +0100 Lines: 47 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 213.202.123.54 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 In-Reply-To: Subject: Re: gpart/gstripe problems? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 16:58:00 -0000 On 18.1.2011 16:48, Daniel Braniss wrote: > I have: > sf-03> gpart show > => 34 976773101 ada0 GPT (466G) > 34 128 1 freebsd-boot (64K) > 162 4194304 2 freebsd-ufs (2.0G) > 4194466 100663296 3 freebsd-swap (48G) > 104857762 871915373 4 freebsd (416G) > > => 34 976773101 ada1 GPT (466G) > 34 128 1 freebsd-boot (64K) > 162 4194304 2 freebsd-ufs (2.0G) > 4194466 100663296 3 freebsd-swap (48G) > 104857762 871915373 4 freebsd (416G) > > sf-03> ls -ls /dev/ada* > 0 crw-r----- 1 root operator 0, 78 Jan 18 14:35 /dev/ada0 > 0 crw-r----- 1 root operator 0, 80 Jan 18 14:35 /dev/ada0p1 > 0 crw-r----- 1 root operator 0, 81 Jan 18 14:35 /dev/ada0p2 > 0 crw-r----- 1 root operator 0, 82 Jan 18 14:35 /dev/ada0p3 > 0 crw-r----- 1 root operator 0, 83 Jan 18 14:35 /dev/ada0s4 > 0 crw-r----- 1 root operator 0, 79 Jan 18 14:35 /dev/ada1 > 0 crw-r----- 1 root operator 0, 84 Jan 18 14:35 /dev/ada1p1 > 0 crw-r----- 1 root operator 0, 85 Jan 18 14:35 /dev/ada1p2 > 0 crw-r----- 1 root operator 0, 86 Jan 18 14:35 /dev/ada1p3 > 0 crw-r----- 1 root operator 0, 87 Jan 18 14:35 /dev/ada1s4 > > next I did: > # gstripe label s0 /dev/ada{0,1}s4 > and on the console the following appeared: > GEOM_STRIPE: Device s0 activated. > GEOM_STRIPE: Cannot add disk gptid/bd0f6e54-22ea-11e0-b27c-001b245d5a5b to s0 > (error=17). > GEOM_STRIPE: Cannot add disk gptid/bdf7d563-22ea-11e0-b27c-001b245d5a5b to s0 > (error=17). > > is this realy an error? It looks like a similar type of error as people commonly see with gmirror - a race with glabel. If you don't use glabel, the easyest way would be to disable some of kern.geom.label.*. I think one way to solve it would be for glabel export an attribute for devices (providers) on which this is possible (i.e. those whose size doesn't change from the underlying devices) which could be checked by such GEOM classes. From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 19 04:25:22 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22BAB106566C for ; Wed, 19 Jan 2011 04:25:22 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id E7A618FC1C for ; Wed, 19 Jan 2011 04:25:21 +0000 (UTC) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.4/8.14.1) with ESMTP id p0J4OmWX006801; Tue, 18 Jan 2011 20:24:48 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.14.4/8.13.4/Submit) id p0J4OkgW006798; Tue, 18 Jan 2011 20:24:46 -0800 (PST) Date: Tue, 18 Jan 2011 20:24:46 -0800 (PST) From: Matthew Dillon Message-Id: <201101190424.p0J4OkgW006798@apollo.backplane.com> To: Rick Macklem References: <334773590.270506.1295050163687.JavaMail.root@erie.cs.uoguelph.ca> Cc: freebsd-hackers@freebsd.org Subject: Re: NFS: file too large 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, 19 Jan 2011 04:25:22 -0000 :Well, since a server specifies the maximum file size it can :handle, it seems good form to check for that in the client. :(Although I'd agree that a server shouldn't crash if a read/write : that goes beyond that limit.) : :Also, as Matt notes, off_t is signed. As such, it looks to me like :the check could mess up if uio_offset it right near 0x7fffffffffffffff, :so that uio->ui_offset + uio->uio_resid ends up negative. I think the :check a little above that for uio_offset < 0 should also check :uio_offset + uio_resid < 0 to avoid this. : :rick Yes, though doing an overflow check in C, at least with newer versions of GCC, requires a separate comparison. The language has been mangled pretty badly over the years. if (a + b < a) -> can be optimized-out by the compiler if (a + b < 0) -> also can be optimized-out by the compiler x = a + b; if (x < a) -> this is ok (best method) x = a + b; if (x < 0) -> this is ok This sort of check may already be made in various places (e.g. by UFS and/or uio), since negative offsets are used to identify meta-data in UFS. -Matt Matthew Dillon From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 19 06:57:33 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 430A210656AA for ; Wed, 19 Jan 2011 06:57:33 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id EBB1D8FC16 for ; Wed, 19 Jan 2011 06:57:32 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1PfRyz-0000mX-Oa; Wed, 19 Jan 2011 08:57:29 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Matthew Dillon In-reply-to: <201101190424.p0J4OkgW006798@apollo.backplane.com> References: <334773590.270506.1295050163687.JavaMail.root@erie.cs.uoguelph.ca> <201101190424.p0J4OkgW006798@apollo.backplane.com> Comments: In-reply-to Matthew Dillon message dated "Tue, 18 Jan 2011 20:24:46 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 19 Jan 2011 08:57:29 +0200 From: Daniel Braniss Message-ID: Cc: freebsd-hackers@freebsd.org, Rick Macklem Subject: Re: NFS: file too large 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, 19 Jan 2011 06:57:33 -0000 > :Well, since a server specifies the maximum file size it can > :handle, it seems good form to check for that in the client. > :(Although I'd agree that a server shouldn't crash if a read/write > : that goes beyond that limit.) > : > :Also, as Matt notes, off_t is signed. As such, it looks to me like > :the check could mess up if uio_offset it right near 0x7fffffffffffffff, > :so that uio->ui_offset + uio->uio_resid ends up negative. I think the > :check a little above that for uio_offset < 0 should also check > :uio_offset + uio_resid < 0 to avoid this. > : > :rick > > Yes, though doing an overflow check in C, at least with newer versions > of GCC, requires a separate comparison. The language has been mangled > pretty badly over the years. > > > if (a + b < a) -> can be optimized-out by the compiler > > if (a + b < 0) -> also can be optimized-out by the compiler > > x = a + b; > if (x < a) -> this is ok (best method) > > x = a + b; > if (x < 0) -> this is ok > > > This sort of check may already be made in various places (e.g. by UFS > and/or uio), since negative offsets are used to identify meta-data in > UFS. > > -Matt > Matthew Dillon > my question, badly written, was why not let the underlaying fs (ufs, zfs, etc) have the last word, instead of the nfsclient having to guess? Is there a problem in sending back the error? danny From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 19 07:26:26 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BF121065674 for ; Wed, 19 Jan 2011 07:26:26 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 427108FC23 for ; Wed, 19 Jan 2011 07:26:26 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1PfSQz-00013F-1Z; Wed, 19 Jan 2011 09:26:25 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Ivan Voras In-reply-to: References: Comments: In-reply-to Ivan Voras message dated "Tue, 18 Jan 2011 17:57:47 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 19 Jan 2011 09:26:25 +0200 From: Daniel Braniss Message-ID: Cc: freebsd-hackers@freebsd.org Subject: Re: gpart/gstripe problems? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 07:26:26 -0000 > On 18.1.2011 16:48, Daniel Braniss wrote: > > I have: > > sf-03> gpart show > > => 34 976773101 ada0 GPT (466G) > > 34 128 1 freebsd-boot (64K) > > 162 4194304 2 freebsd-ufs (2.0G) > > 4194466 100663296 3 freebsd-swap (48G) > > 104857762 871915373 4 freebsd (416G) > > > > => 34 976773101 ada1 GPT (466G) > > 34 128 1 freebsd-boot (64K) > > 162 4194304 2 freebsd-ufs (2.0G) > > 4194466 100663296 3 freebsd-swap (48G) > > 104857762 871915373 4 freebsd (416G) > > > > sf-03> ls -ls /dev/ada* > > 0 crw-r----- 1 root operator 0, 78 Jan 18 14:35 /dev/ada0 > > 0 crw-r----- 1 root operator 0, 80 Jan 18 14:35 /dev/ada0p1 > > 0 crw-r----- 1 root operator 0, 81 Jan 18 14:35 /dev/ada0p2 > > 0 crw-r----- 1 root operator 0, 82 Jan 18 14:35 /dev/ada0p3 > > 0 crw-r----- 1 root operator 0, 83 Jan 18 14:35 /dev/ada0s4 > > 0 crw-r----- 1 root operator 0, 79 Jan 18 14:35 /dev/ada1 > > 0 crw-r----- 1 root operator 0, 84 Jan 18 14:35 /dev/ada1p1 > > 0 crw-r----- 1 root operator 0, 85 Jan 18 14:35 /dev/ada1p2 > > 0 crw-r----- 1 root operator 0, 86 Jan 18 14:35 /dev/ada1p3 > > 0 crw-r----- 1 root operator 0, 87 Jan 18 14:35 /dev/ada1s4 > > > > next I did: > > # gstripe label s0 /dev/ada{0,1}s4 > > and on the console the following appeared: > > GEOM_STRIPE: Device s0 activated. > > GEOM_STRIPE: Cannot add disk gptid/bd0f6e54-22ea-11e0-b27c-001b245d5a5b to s0 > > (error=17). > > GEOM_STRIPE: Cannot add disk gptid/bdf7d563-22ea-11e0-b27c-001b245d5a5b to s0 > > (error=17). > > > > is this realy an error? > > It looks like a similar type of error as people commonly see with > gmirror - a race with glabel. If you don't use glabel, the easyest way > would be to disable some of kern.geom.label.*. > > I think one way to solve it would be for glabel export an attribute for > devices (providers) on which this is possible (i.e. those whose size > doesn't change from the underlying devices) which could be checked by > such GEOM classes. thanks for the explanation, I did kern.geom.label.gptid.enable=0 which 'solved' it, since I don't have use for it (mainly I don't know what it's good for :-). danny From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 19 08:34:07 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 1060) id BB1971065696; Wed, 19 Jan 2011 08:34:07 +0000 (UTC) Date: Wed, 19 Jan 2011 00:34:07 -0800 From: Craig Rodrigues To: Jaakko Heinonen Message-ID: <20110119083407.GA51372@crodrigues.org> References: <20110114122454.GA4805@jh> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110114122454.GA4805@jh> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Wed, 19 Jan 2011 12:30:07 +0000 Cc: freebsd-hackers@FreeBSD.org Subject: Re: [patch] nmount ro, rw and negated option handling 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, 19 Jan 2011 08:34:07 -0000 Hi, I disagree with your patch and do not approve it. I prefer something simpler: Index: vfs_mount.c =================================================================== --- vfs_mount.c (revision 216607) +++ vfs_mount.c (working copy) @@ -522,10 +522,9 @@ struct vfsopt *opt, *noro_opt, *tmp_opt; char *fstype, *fspath, *errmsg; int error, fstypelen, fspathlen, errmsg_len, errmsg_pos; - int has_rw, has_noro; errmsg = fspath = NULL; - errmsg_len = has_noro = has_rw = fspathlen = 0; + errmsg_len = fspathlen = 0; errmsg_pos = -1; error = vfs_buildopts(fsoptions, &optlist); @@ -624,7 +623,8 @@ } else if (strcmp(opt->name, "rw") == 0) { fsflags &= ~MNT_RDONLY; - has_rw = 1; + free(opt->name, M_MOUNT); + opt->name = strdup("noro", M_MOUNT); } else if (strcmp(opt->name, "ro") == 0) fsflags |= MNT_RDONLY; @@ -642,22 +642,6 @@ } /* - * If "rw" was specified as a mount option, and we - * are trying to update a mount-point from "ro" to "rw", - * we need a mount option "noro", since in vfs_mergeopts(), - * "noro" will cancel "ro", but "rw" will not do anything. - */ - if (has_rw && !has_noro) { - noro_opt = malloc(sizeof(struct vfsopt), M_MOUNT, M_WAITOK); - noro_opt->name = strdup("noro", M_MOUNT); - noro_opt->value = NULL; - noro_opt->len = 0; - noro_opt->pos = -1; - noro_opt->seen = 1; - TAILQ_INSERT_TAIL(optlist, noro_opt, link); - } - - /* * Be ultra-paranoid about making sure the type and fspath * variables will fit in our mp buffers, including the * terminating NUL. ZFS can be changed to check for "rw" or "noro". -- Craig Rodrigues rodrigc@crodrigues.org On Fri, Jan 14, 2011 at 02:24:54PM +0200, Jaakko Heinonen wrote: > > Hi, > > Currently nmount(2) allows a mount point to have "ro", "rw", and "noro" > string options concurrently active. This can cause erratic behavior > demonstrated by this example: > > 1. Have mountd(8) running. > 2. # mdconfig -a -t vnode -f ufsimg > 3. # mount -o ro,rw /dev/md0 /mnt > > After these steps the mount point has string options "ro", "rw" and > "noro" active but the MNT_RDONLY flag is not set. Eventually this will > lead to "ffs_sync: rofs mod" (or similar) panic because the ffs code > marks the file system read-only due to the "ro" string option. > (MNT_RDONLY flag is used in most places for read-only check.) > > I wrote a patch to do following changes: > > - vfs_equalopts() now recognizes "ro" and "rw" as equal options > - vfs_mergeopts() uses vfs_sanitizeopts() to merge options. This ensures > that if the same option shows up several times (negated or not), only > the last one is taken in account. There is still a problem when for > example option "foo" and "nofoo" are merged: the "nofoo" option will > become an active option. This is not a regression however and > currently I don't know an easy way to solve this because the list of > valid options is not available in vfs_mergeopts(). > - vfs_donmount() always converts "norw"/"rdonly" to "ro" and "noro" to > "rw". Thus the mount point will always have either "rw" or "ro" > option. I haven't seen any in-tree file system to test for "noro" but > at least ZFS tests for "rw". That's why I chose "rw" instead or > "noro". > > The patch is available here: > > http://people.freebsd.org/~jh/patches/nmount-ro-rw.diff > > Reviews and testing would be appreciated. > > Here are some references to bug reports which the patch attempts to > resolve: > > http://lists.freebsd.org/pipermail/freebsd-current/2009-September/thread.html#11385 > http://lists.freebsd.org/pipermail/freebsd-questions/2009-August/204124.html > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/133614 > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/150206 > > -- > Jaakko From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 19 13:12:57 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 670661065672 for ; Wed, 19 Jan 2011 13:12:57 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 1F6E98FC19 for ; Wed, 19 Jan 2011 13:12:56 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEACxyNk2DaFvO/2dsb2JhbACED6EosF+PW4Ekgzh0BIRvhi+LOg X-IronPort-AV: E=Sophos;i="4.60,344,1291611600"; d="scan'208";a="105951528" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 19 Jan 2011 08:12:55 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id E6FE9B411F; Wed, 19 Jan 2011 08:12:55 -0500 (EST) Date: Wed, 19 Jan 2011 08:12:55 -0500 (EST) From: Rick Macklem To: Daniel Braniss Message-ID: <800508241.469728.1295442775861.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE8 (Win)/6.0.10_GA_2692) Cc: freebsd-hackers@freebsd.org Subject: Re: NFS: file too large 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, 19 Jan 2011 13:12:57 -0000 > > :Well, since a server specifies the maximum file size it can > > :handle, it seems good form to check for that in the client. > > :(Although I'd agree that a server shouldn't crash if a read/write > > : that goes beyond that limit.) > > : > > :Also, as Matt notes, off_t is signed. As such, it looks to me like > > :the check could mess up if uio_offset it right near > > 0x7fffffffffffffff, > > :so that uio->ui_offset + uio->uio_resid ends up negative. I think > > the > > :check a little above that for uio_offset < 0 should also check > > :uio_offset + uio_resid < 0 to avoid this. > > : > > :rick > > > > Yes, though doing an overflow check in C, at least with newer > > versions > > of GCC, requires a separate comparison. The language has been > > mangled > > pretty badly over the years. > > > > > > if (a + b < a) -> can be optimized-out by the compiler > > > > if (a + b < 0) -> also can be optimized-out by the compiler > > > > x = a + b; > > if (x < a) -> this is ok (best method) > > > > x = a + b; > > if (x < 0) -> this is ok > > Ok, thanks. I'll admit to being an old K+R type guy. > > my question, badly written, was why not let the underlaying fs (ufs, > zfs, etc) > have the last word, instead of the nfsclient having to guess? Is there > a problem in sending back the error? > Well, the principal I try and apply in the name of interoperability is: 1 - The client should adhere to the RFCs as strictly as possible 2 - The server should assume the loosest interpretation of the RFCs. For me #1 applies. ie. If a server specifies a maximum file size, the client should not violate that. (Meanwhile the server should assume that clients will exceed the maximum sooner or later.) Remember that the server might be a Netapp, EMC, ... and those vendors mostly test their servers against Linux, Solaris clients. (I've tried to convince them to fire up FreeBSD systems in-house for testing and even volunteered to help with the setup, but if they've done so, I've never heard about it. Their usual response is "come to connectathon". See below.) Here's an NFSv4.0 example: - RFC3530 describes the "dircount" argument for Readdir as a "hint of the maximum number of bytes of directory information" (in 4th para of pg 191). One vendor ships an NFSv4 client that always sets this value to 0. Their argument is that, since it is only a "hint" it can be anything they feel like putting there. (Several servers crapped out because of this in the early days.) Part of the problem is that I am not in a position to attend the interoperability testing events like www.connectathon.org, where these things are usually discovered (and since they are covered under an NDA that attendies sign, I don't find out the "easy way" when problems occur). rick From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 19 15:04:05 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8CC4106564A for ; Wed, 19 Jan 2011 15:04:05 +0000 (UTC) (envelope-from kwiat3k@panic.pl) Received: from mail.panic.pl (mail.panic.pl [IPv6:2a02:ee0:dead::7:1]) by mx1.freebsd.org (Postfix) with ESMTP id 5813B8FC21 for ; Wed, 19 Jan 2011 15:04:05 +0000 (UTC) Received: from mail.panic.pl (unknown [91.203.134.75]) by mail.panic.pl (Postfix) with ESMTP id E7A602FA41 for ; Wed, 19 Jan 2011 16:04:03 +0100 (CET) X-Virus-Scanned: amavisd-new at panic.pl Received: from mail.panic.pl ([91.203.134.75]) by mail.panic.pl (mail.panic.pl [91.203.134.75]) (amavisd-new, port 10024) with ESMTP id O9LearaMW2YL for ; Wed, 19 Jan 2011 16:04:03 +0100 (CET) Received: from stokrotka.t1.gda.wp-sa.pl (admin.wp-sa.pl [212.77.105.137]) by mail.panic.pl (Postfix) with ESMTPSA id 32CB52FA35 for ; Wed, 19 Jan 2011 16:04:03 +0100 (CET) Date: Wed, 19 Jan 2011 16:04:04 +0100 From: Mateusz Kwiatkowski To: freebsd-hackers Message-ID: <20110119160404.5d47ad6f@stokrotka.t1.gda.wp-sa.pl> Organization: Panic.PL X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Question about FreeBSD and long usernames X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kwiat@panic.pl List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 15:04:05 -0000 Hi, I have noticed inconsistent behaviour of some tools while working with long usernames. At first, 17 chars username (UT_NAMESIZE is set to 16, MAXLOGNAME to 17): # pw user add verylongusername pwd_mkdb: jira_pawprintgames: username too long But it is possible to create such user with vipw: # id verylongusername uid=1005(verylongusername) gid=1003(users) groups=1003(users) We can make use of this account: su - verylongusername % id uid=1005(verylongusername) gid=1003(users) groups=1003(users) # passwd verylongusername Changing local password for verylongusername New Password: Retype New Password: # 18 chars username: # id verylongusername1 uid=1006(verylongusername1) gid=1003(users) groups=1003(users) # su - verylongusername1 su: username too long # sudo -u verylongusername1 id uid=1006(verylongusername1) gid=1003(users) groups=1003(users) It's possible to change password: # passwd verylongusername1 Changing local password for verylongusername1 New Password: Retype New Password: # When trying to login with ssh (17 chars username worked ok): Jan 19 14:46:08 xxxx sshd[39050]: setlogin(verylongusername1): Invalid argument Why some tools deny using long usernames, while others permit? Should it be corrected? Cheers, Mateusz From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 19 15:12:15 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09E25106566C for ; Wed, 19 Jan 2011 15:12:15 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by mx1.freebsd.org (Postfix) with ESMTP id BA9CA8FC1B for ; Wed, 19 Jan 2011 15:12:14 +0000 (UTC) Received: from a91-153-123-205.elisa-laajakaista.fi (a91-153-123-205.elisa-laajakaista.fi [91.153.123.205]) by gw03.mail.saunalahti.fi (Postfix) with SMTP id 8FAF1216DE1; Wed, 19 Jan 2011 17:12:10 +0200 (EET) Date: Wed, 19 Jan 2011 17:12:10 +0200 From: Jaakko Heinonen To: Craig Rodrigues Message-ID: <20110119151210.GA2182@a91-153-123-205.elisa-laajakaista.fi> References: <20110114122454.GA4805@jh> <20110119083407.GA51372@crodrigues.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110119083407.GA51372@crodrigues.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@FreeBSD.org Subject: Re: [patch] nmount ro, rw and negated option handling 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, 19 Jan 2011 15:12:15 -0000 On 2011-01-19, Craig Rodrigues wrote: > I disagree with your patch and do not approve it. > > I prefer something simpler: Thanks for your reply. However, your patch doesn't fix the bug(s) I tried to resolve. See below. > ZFS can be changed to check for "rw" or "noro". It's possible but I don't like to support both "rw" and "noro". That makes the file system code unnecessary prone for bugs when someone forgets to test for both options. > > 1. Have mountd(8) running. > > 2. # mdconfig -a -t vnode -f ufsimg > > 3. # mount -o ro,rw /dev/md0 /mnt With your patch[1] after the third step the mount point has both "ro" and and "noro" active but the MNT_RDONLY flag is not set. Again, you will eventually get the "ffs_sync: rofs mod" (or similar) panic because the "ro" option is active during remount. Also, I didn't verify but I doubt that your patch will fix the problem described in PR kern/150206. [1] I had to comment vfs_mount.c line 622 "has_noro = 1;" and remove the noro_opt declaration to be able to compile kernel with your patch applied. -- Jaakko From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 19 23:23:41 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 456AF106566C for ; Wed, 19 Jan 2011 23:23:41 +0000 (UTC) (envelope-from lgj@usenix.org) Received: from lonestar.usenix.org (lonestar.usenix.org [131.106.3.102]) by mx1.freebsd.org (Postfix) with ESMTP id 135998FC0A for ; Wed, 19 Jan 2011 23:23:41 +0000 (UTC) Received: from negroni.usenix.org (negroni.usenix.org [131.106.3.145]) (authenticated bits=0) by lonestar.usenix.org (8.14.2/8.14.2) with ESMTP id p0JNLe3N028746 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 19 Jan 2011 15:23:40 -0800 (PST) From: Lionel Garth Jones Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 19 Jan 2011 15:23:40 -0800 Message-Id: To: freebsd-hackers@freebsd.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-DCC-USENIX-Metrics: lonestar; whitelist X-Spam-Status: No, score=0.7 required=6.0 tests=ALL_TRUSTED, FH_DATE_PAST_20XX autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on lonestar X-Mailman-Approved-At: Wed, 19 Jan 2011 23:35:11 +0000 Subject: USENIX NSDI '11 Registration Now Open 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, 19 Jan 2011 23:23:41 -0000 We are writing to invite you to NSDI '11, the 8th USENIX Symposium on Networked Systems Design and Implementation, which will take place March 30-April 1, 2011, in Boston, MA. http://www.usenix.org/nsdi11/proga NSDI '11 focuses on the design principles of large-scale networks and distributed systems. Our goal is to bring together researchers from across the systems and networking communities to foster cross-disciplinary approaches and to address shared research challenges. This year's program includes 27 technical papers carefully selected out of 157 submissions. The high-quality papers represent a diverse range of hot research areas including data-intensive computing, energy and storage, debugging and correctness, and more. In addition, NSDI '11 will feature a poster session where attendees can discuss emerging ideas in networked systems design by talking with leading researchers who are introducing their ongoing work. The submission deadline and more information will be available at: http://www.usenix.org/events/nsdi11/activities.html#poster Please join us in Boston for the latest innovative networked systems research. We look forward to seeing you there. Sincerely, David G. Andersen, Carnegie Mellon University Sylvia Ratnasamy, Intel Labs Berkeley nsdi11chairs@usenix.org P.S. Don't miss these workshops, which will be co-located with NSDI '11 and will take place on Tuesday, March 29, 2011: -- 4th USENIX Workshop on Large-Scale Exploits and Emergent Threats (LEET '11) http://www.usenix.org/events/leet11/ -- Workshop on Hot Topics in Management of Internet, Cloud, and Enterprise Networks and Services (Hot-ICE '11) http://www.usenix.org/events/hotice11/ ------------------------------------------------------------------------ 8th USENIX Symposium on Networked Systems Design and Implementation (NSDI '11) March 30-April 1, 2011 Boston, MA, USA http://www.usenix.org/nsdi11/proga Sponsored by USENIX in cooperation with ACM SIGCOMM and ACM SIGOPS Early Bird Registration Deadline: March 7, 2011 ------------------------------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 20 16:07:51 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73E8A1065672 for ; Thu, 20 Jan 2011 16:07:51 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 2A2D88FC1D for ; Thu, 20 Jan 2011 16:07:50 +0000 (UTC) Received: from outgoing.leidinger.net (p57B3B645.dip.t-dialin.net [87.179.182.69]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id A78F0844012; Thu, 20 Jan 2011 16:52:34 +0100 (CET) Received: from webmail.leidinger.net (unknown [IPv6:fd73:10c7:2053:1::2:102]) by outgoing.leidinger.net (Postfix) with ESMTP id 8919120F7; Thu, 20 Jan 2011 16:52:31 +0100 (CET) Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id p0KFqG1V092595; Thu, 20 Jan 2011 16:52:16 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Thu, 20 Jan 2011 16:52:15 +0100 Message-ID: <20110120165215.1794698qw7ejr18g@webmail.leidinger.net> Date: Thu, 20 Jan 2011 16:52:15 +0100 From: Alexander Leidinger To: Gleb Kurtsou References: <20101223224619.GA21984@tops> In-Reply-To: <20101223224619.GA21984@tops> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: A78F0844012.A6BA4 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=1.274, required 6, autolearn=disabled, RDNS_NONE 1.27) X-EBL-MailScanner-SpamScore: s X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1296143555.21337@dENTLu4SOwhfBQDCtUPCvQ X-EBL-Spam-Status: No X-Mailman-Approved-At: Thu, 20 Jan 2011 16:32:29 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: [rfc] Replacing FNV and hash32 with Paul Hsieh's SuperFastHash 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, 20 Jan 2011 16:07:51 -0000 Quoting Gleb Kurtsou (from Fri, 24 Dec 2010 00:46:20 +0200): > Hi, > > I've recently noticed that hash table use in nullfs was inefficient, 1/3 > to half of buckets remained unused. I've started investigating it > further and came across SuperFastHash hashing function, SFH > (SuperFastHash) has BSD license, used in WebKit and other open source > projects. Detailed description and Comparision with FNV and Bob Jenkin's > hash can be found here: > http://www.azillionmonkeys.com/qed/hash.html I found some web pages which tell about an unfair speed comparision and about a collision problem in SFH: http://coding.derkeiler.com/Archive/General/comp.programming/2005-03/0650.html http://www.team5150.com/~andrew/blog/2007/03/breaking_superfasthash.html http://blog.clawpaws.net/post/2007/04/22/Good-Hash-Functions It may be that this is not an issue for the use case we have here, but blindly replacing it without looking at the above web pages looks a little bit risky to me. Bye, Alexander. -- The use of money is all the advantage there is to having money. -- Benjamin Franklin http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 21 16:09:12 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5976106566C for ; Fri, 21 Jan 2011 16:09:11 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 96B0D8FC17 for ; Fri, 21 Jan 2011 16:09:11 +0000 (UTC) Received: by qwj9 with SMTP id 9so1903239qwj.13 for ; Fri, 21 Jan 2011 08:09:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=0J+qp840xVP7i5OO5LzYzEa91MJJR3qqk14TsOPlWjk=; b=stXjkzNk6sH3+CumB5ZgMYAQ8Z3oUQhTj5uVhIJamfc83zTDDGUfaBZxMg1zzCLvQJ lq8SrQfIvKgIS2wRc1kAHLwkblePgx3tT7+57F0Z8LZxoSghud1YLzjJPs+L9BaHXQ3x 41Uwi7agBKhD8TMFOIggHP9WW83TkHnpGSW9E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=UtV/0LPcZkeNQzfSSIR39pVkMIlraHb/EVi1FwNyidje0G56y7zmDz7W5M5ID23hHR uBt5YoFkNKEw+ktE2nGhxqAVl/YPMprZGiSIS0cc2JLMCSXrjkXVkvGULfKJoGN5Sjjc xhJ7couToSvwGTRs+t2FRJBuBYYsQ9v6rmIK4= MIME-Version: 1.0 Received: by 10.229.83.198 with SMTP id g6mr690442qcl.157.1295626150741; Fri, 21 Jan 2011 08:09:10 -0800 (PST) Received: by 10.229.102.87 with HTTP; Fri, 21 Jan 2011 08:09:10 -0800 (PST) Date: Fri, 21 Jan 2011 19:09:10 +0300 Message-ID: From: Sergey Kandaurov To: FreeBSD Hackers Content-Type: multipart/mixed; boundary=00163642748d7a0815049a5d78b6 Subject: [rfc] allow to boot with >= 256GB physmem 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, 21 Jan 2011 16:09:12 -0000 --00163642748d7a0815049a5d78b6 Content-Type: text/plain; charset=ISO-8859-1 Hello. Some time ago I faced with a problem booting with 400GB physmem. The problem is that vm.max_proc_mmap type overflows with such high value, and that results in a broken mmap() syscall. The max_proc_mmap value is a signed int and roughly calculated at vmmapentry_rsrc_init() as u_long vm_kmem_size quotient: vm_kmem_size / sizeof(struct vm_map_entry) / 100. Although at the time it was introduced at svn r57263 the value was quite low (f.e. the related commit log stands: "The value defaults to around 9000 for a 128MB machine."), the problem is observed on amd64 where KVA space after r212784 is factually bound to the only physical memory size. With INT_MAX here is 0x7fffffff, and sizeof(struct vm_map_entry) is 120, it's enough to have sligthly less than 256GB to be able to reproduce the problem. I rewrote vmmapentry_rsrc_init() to set large enough limit for max_proc_mmap just to protect from integer type overflow. As it's also possible to live tune this value, I also added a simple anti-shoot constraint to its sysctl handler. I'm not sure though if it's worth to commit the second part. As this patch may cause some bikeshedding, I'd like to hear your comments before I will commit it. http://plukky.net/~pluknet/patches/max_proc_mmap.diff -- wbr, pluknet --00163642748d7a0815049a5d78b6 Content-Type: application/octet-stream; name="max_proc_mmap.diff" Content-Disposition: attachment; filename="max_proc_mmap.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gj7a6ggp0 SW5kZXg6IHN5cy92bS92bV9tbWFwLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL3ZtL3ZtX21tYXAuYwko cmV2aXNpb24gMjE3NTM1KQorKysgc3lzL3ZtL3ZtX21tYXAuYwkod29ya2luZyBjb3B5KQpAQCAt OTIsOCArOTIsMjkgQEAgc3RydWN0IHNicmtfYXJncyB7CiB9OwogI2VuZGlmCiAKKyNpZm5kZWYJ TUFYX1BST0NfTU1BUAorI2RlZmluZQlNQVhfUFJPQ19NTUFQIDEwMDAwMDAwCisjZW5kaWYKKwog c3RhdGljIGludCBtYXhfcHJvY19tbWFwOwotU1lTQ1RMX0lOVChfdm0sIE9JRF9BVVRPLCBtYXhf cHJvY19tbWFwLCBDVExGTEFHX1JXLCAmbWF4X3Byb2NfbW1hcCwgMCwKKworc3RhdGljIGludAor c3lzY3RsX21heF9wcm9jX21tYXAoU1lTQ1RMX0hBTkRMRVJfQVJHUykKK3sKKwlpbnQgZXJyb3Is IG5ld192YWw7CisKKwluZXdfdmFsID0gbWF4X3Byb2NfbW1hcDsKKwllcnJvciA9IHN5c2N0bF9o YW5kbGVfaW50KG9pZHAsICZuZXdfdmFsLCAwLCByZXEpOworCWlmIChlcnJvciAhPSAwIHx8IHJl cS0+bmV3cHRyID09IE5VTEwpCisJCXJldHVybiAoZXJyb3IpOworCWlmIChuZXdfdmFsIDwgMCB8 fCBuZXdfdmFsID4gTUFYX1BST0NfTU1BUCkKKwkJZXJyb3IgPSBFSU5WQUw7CisJZWxzZQorCQlt YXhfcHJvY19tbWFwID0gbmV3X3ZhbDsKKwlyZXR1cm4gKGVycm9yKTsKK30KK1NZU0NUTF9QUk9D KF92bSwgT0lEX0FVVE8sIG1heF9wcm9jX21tYXAsIENUTFRZUEVfSU5UIHwgQ1RMRkxBR19SVywK KyAgICAmbWF4X3Byb2NfbW1hcCwgMCwgc3lzY3RsX21heF9wcm9jX21tYXAsICJJIiwKICAgICAi TWF4aW11bSBudW1iZXIgb2YgbWVtb3J5LW1hcHBlZCBmaWxlcyBwZXIgcHJvY2VzcyIpOwogCiAv KgpAQCAtMTA5LDExICsxMzAsMTYgQEAgU1lTSU5JVCh2bW1lcnNyYywgU0lfU1VCX0tWTV9SU1JD LCBTSV9PUkRFUl9GSVJTVCwKICAgICBOVUxMKTsKIAogc3RhdGljIHZvaWQKLXZtbWFwZW50cnlf cnNyY19pbml0KGR1bW15KQotICAgICAgICB2b2lkICpkdW1teTsKK3ZtbWFwZW50cnlfcnNyY19p bml0KHZvaWQgKmR1bW15KQogewotICAgIG1heF9wcm9jX21tYXAgPSB2bV9rbWVtX3NpemUgLyBz aXplb2Yoc3RydWN0IHZtX21hcF9lbnRyeSk7Ci0gICAgbWF4X3Byb2NfbW1hcCAvPSAxMDA7CisJ dV9sb25nIHRtcF92YWw7CisKKwl0bXBfdmFsID0gdm1fa21lbV9zaXplIC8gc2l6ZW9mKHN0cnVj dCB2bV9tYXBfZW50cnkpIC8gMTAwOworCisJLyogQXZvaWQgaW50ZWdlciBvdmVyZmxvdy4gKi8K KwlpZiAodG1wX3ZhbCA+IE1BWF9QUk9DX01NQVApCisJCXRtcF92YWwgPSBNQVhfUFJPQ19NTUFQ OworCW1heF9wcm9jX21tYXAgPSAoaW50KXRtcF92YWw7CiB9CiAKIHN0YXRpYyBpbnQgdm1fbW1h cF92bm9kZShzdHJ1Y3QgdGhyZWFkICosIHZtX3NpemVfdCwgdm1fcHJvdF90LCB2bV9wcm90X3Qg KiwK --00163642748d7a0815049a5d78b6-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 21 17:44:37 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0683F106566B for ; Fri, 21 Jan 2011 17:44:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id CDE8D8FC16 for ; Fri, 21 Jan 2011 17:44:36 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 87EB846B96; Fri, 21 Jan 2011 12:44:36 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 860888A01D; Fri, 21 Jan 2011 12:44:35 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Fri, 21 Jan 2011 12:44:13 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201101211244.13830.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 21 Jan 2011 12:44:35 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Sergey Kandaurov Subject: Re: [rfc] allow to boot with >= 256GB physmem 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, 21 Jan 2011 17:44:37 -0000 On Friday, January 21, 2011 11:09:10 am Sergey Kandaurov wrote: > Hello. > > Some time ago I faced with a problem booting with 400GB physmem. > The problem is that vm.max_proc_mmap type overflows with > such high value, and that results in a broken mmap() syscall. > The max_proc_mmap value is a signed int and roughly calculated > at vmmapentry_rsrc_init() as u_long vm_kmem_size quotient: > vm_kmem_size / sizeof(struct vm_map_entry) / 100. > > Although at the time it was introduced at svn r57263 the value > was quite low (f.e. the related commit log stands: > "The value defaults to around 9000 for a 128MB machine."), > the problem is observed on amd64 where KVA space after > r212784 is factually bound to the only physical memory size. > > With INT_MAX here is 0x7fffffff, and sizeof(struct vm_map_entry) > is 120, it's enough to have sligthly less than 256GB to be able > to reproduce the problem. > > I rewrote vmmapentry_rsrc_init() to set large enough limit for > max_proc_mmap just to protect from integer type overflow. > As it's also possible to live tune this value, I also added a > simple anti-shoot constraint to its sysctl handler. > I'm not sure though if it's worth to commit the second part. > > As this patch may cause some bikeshedding, > I'd like to hear your comments before I will commit it. > > http://plukky.net/~pluknet/patches/max_proc_mmap.diff Is there any reason we can't just make this variable and sysctl a long? -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 21 18:01:12 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D0E3106566C; Fri, 21 Jan 2011 18:01:12 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 09BAC8FC0C; Fri, 21 Jan 2011 18:01:11 +0000 (UTC) Received: by qwj9 with SMTP id 9so2010106qwj.13 for ; Fri, 21 Jan 2011 10:01:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0AlfnCxBKILan4B3Zc0vgiF9qdEvtcu4uF+MHkaG7Zo=; b=SxlDCuNsXXNugWxdDW7QEqZi7ZqgybzhfMHTX70S38pAGDS8n5quXeOigfZqhb4jJC DDmFSfRfhYBIjniyRTIWVPWVbGLq0FQiPAXH4KM3rtQD/1lEh36+KaLCnIZWmrONSAoB OLi4jeP1wGWg297qDGGzXWmCm42pEXhACxdhM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=pOEipGzxC2fCQcLt9nAWe6js2U5y5WG93qDPLYdBYiE82vIilIn46n7C7FSvgXX+JO FAWlveAl0SailLPHIdycTIzT33G1huPzPWt7EGUrr1FhQaNpJN3KzJLZHlasf2dPyb0n gsz+sTf1eT4Ni648laXI5DOJ/E9lwyTROk+pQ= MIME-Version: 1.0 Received: by 10.229.83.198 with SMTP id g6mr793174qcl.157.1295632871155; Fri, 21 Jan 2011 10:01:11 -0800 (PST) Received: by 10.229.102.87 with HTTP; Fri, 21 Jan 2011 10:01:11 -0800 (PST) In-Reply-To: <201101211244.13830.jhb@freebsd.org> References: <201101211244.13830.jhb@freebsd.org> Date: Fri, 21 Jan 2011 21:01:11 +0300 Message-ID: From: Sergey Kandaurov To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: [rfc] allow to boot with >= 256GB physmem 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, 21 Jan 2011 18:01:12 -0000 On 21 January 2011 20:44, John Baldwin wrote: > On Friday, January 21, 2011 11:09:10 am Sergey Kandaurov wrote: >> Hello. >> >> Some time ago I faced with a problem booting with 400GB physmem. >> The problem is that vm.max_proc_mmap type overflows with >> such high value, and that results in a broken mmap() syscall. >> The max_proc_mmap value is a signed int and roughly calculated >> at vmmapentry_rsrc_init() as u_long vm_kmem_size quotient: >> vm_kmem_size / sizeof(struct vm_map_entry) / 100. >> >> Although at the time it was introduced at svn r57263 the value >> was quite low (f.e. the related commit log stands: >> "The value defaults to around 9000 for a 128MB machine."), >> the problem is observed on amd64 where KVA space after >> r212784 is factually bound to the only physical memory size. >> >> With INT_MAX here is 0x7fffffff, and sizeof(struct vm_map_entry) >> is 120, it's enough to have sligthly less than 256GB to be able >> to reproduce the problem. >> >> I rewrote vmmapentry_rsrc_init() to set large enough limit for >> max_proc_mmap just to protect from integer type overflow. >> As it's also possible to live tune this value, I also added a >> simple anti-shoot constraint to its sysctl handler. >> I'm not sure though if it's worth to commit the second part. >> >> As this patch may cause some bikeshedding, >> I'd like to hear your comments before I will commit it. >> >> http://plukky.net/~pluknet/patches/max_proc_mmap.diff > > Is there any reason we can't just make this variable and sysctl a long? > That was my initial thought, but now I'm afraid this can result in 32bit vs 64bit comparison issue below in code. -- wbr, pluknet From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 21 19:58:47 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D47EC106564A; Fri, 21 Jan 2011 19:58:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id B6AEE8FC08; Fri, 21 Jan 2011 19:58:46 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p0LJwfNj023955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jan 2011 21:58:41 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p0LJwfxV055734; Fri, 21 Jan 2011 21:58:41 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p0LJwf8c055733; Fri, 21 Jan 2011 21:58:41 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 21 Jan 2011 21:58:41 +0200 From: Kostik Belousov To: John Baldwin Message-ID: <20110121195841.GA2518@deviant.kiev.zoral.com.ua> References: <201101211244.13830.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0w3sVzSwLDVzzp/e" Content-Disposition: inline In-Reply-To: <201101211244.13830.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org, Sergey Kandaurov Subject: Re: [rfc] allow to boot with >= 256GB physmem 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, 21 Jan 2011 19:58:48 -0000 --0w3sVzSwLDVzzp/e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 21, 2011 at 12:44:13PM -0500, John Baldwin wrote: > On Friday, January 21, 2011 11:09:10 am Sergey Kandaurov wrote: > > Hello. > >=20 > > Some time ago I faced with a problem booting with 400GB physmem. > > The problem is that vm.max_proc_mmap type overflows with > > such high value, and that results in a broken mmap() syscall. > > The max_proc_mmap value is a signed int and roughly calculated > > at vmmapentry_rsrc_init() as u_long vm_kmem_size quotient: > > vm_kmem_size / sizeof(struct vm_map_entry) / 100. > >=20 > > Although at the time it was introduced at svn r57263 the value > > was quite low (f.e. the related commit log stands: > > "The value defaults to around 9000 for a 128MB machine."), > > the problem is observed on amd64 where KVA space after > > r212784 is factually bound to the only physical memory size. > >=20 > > With INT_MAX here is 0x7fffffff, and sizeof(struct vm_map_entry) > > is 120, it's enough to have sligthly less than 256GB to be able > > to reproduce the problem. > >=20 > > I rewrote vmmapentry_rsrc_init() to set large enough limit for > > max_proc_mmap just to protect from integer type overflow. > > As it's also possible to live tune this value, I also added a > > simple anti-shoot constraint to its sysctl handler. > > I'm not sure though if it's worth to commit the second part. > >=20 > > As this patch may cause some bikeshedding, > > I'd like to hear your comments before I will commit it. > >=20 > > http://plukky.net/~pluknet/patches/max_proc_mmap.diff >=20 > Is there any reason we can't just make this variable and sysctl a long? I do not think we ever need 2G vm map entries in the single address space. --0w3sVzSwLDVzzp/e Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk055XEACgkQC3+MBN1Mb4i18ACfRPoNewWV614iaSp+JkTffK5z CcMAoL2FLbg/0myY890cXtmiJFx0DUfQ =8A6Q -----END PGP SIGNATURE----- --0w3sVzSwLDVzzp/e-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 21 20:58:32 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 527D9106566C; Fri, 21 Jan 2011 20:58:32 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id A949F8FC0C; Fri, 21 Jan 2011 20:58:31 +0000 (UTC) Received: by fxm16 with SMTP id 16so2324591fxm.13 for ; Fri, 21 Jan 2011 12:58:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=KBRU4nP67LU98Uizl2aLjhFGrgP4kOUsThpt1rNXP94=; b=PVRnHaf1SwjvnLsDqNZziskoiW71Ty/tjr4IhOlJdfH/6LYhT0pPZnHlxI8wnL6ExH pXymnLHI8OkD9SsWSn24CeRXqpCc4fNiQMMN+eI9zpy9/FQ7JqDEJLrLr9UpQZHkiE+l MuEYpCD5tLvuGBjs3LKEaVJXsokUfcNGdcTx8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=jSE0ex5xgQtZiVEvf8r34Q61pFWd4+Von+BX8onpgT9G/kaKDmDI2E58q54CYz2D2m NNFSsbFxSRIsiHr9+c06Uq3GXZvXzygzUUBaAjH0GhF3mypX+mqIIxOoeoZJWkSk1EIS eU/o4Nc0wHmyG+qy8AVOOdmMfa4AU7n8mgbvE= MIME-Version: 1.0 Received: by 10.223.120.193 with SMTP id e1mr1113184far.106.1295643510427; Fri, 21 Jan 2011 12:58:30 -0800 (PST) Received: by 10.223.126.207 with HTTP; Fri, 21 Jan 2011 12:58:30 -0800 (PST) In-Reply-To: <201101211244.13830.jhb@freebsd.org> References: <201101211244.13830.jhb@freebsd.org> Date: Fri, 21 Jan 2011 14:58:30 -0600 Message-ID: From: Alan Cox To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, Sergey Kandaurov Subject: Re: [rfc] allow to boot with >= 256GB physmem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alc@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 20:58:32 -0000 On Fri, Jan 21, 2011 at 11:44 AM, John Baldwin wrote: > On Friday, January 21, 2011 11:09:10 am Sergey Kandaurov wrote: > > Hello. > > > > Some time ago I faced with a problem booting with 400GB physmem. > > The problem is that vm.max_proc_mmap type overflows with > > such high value, and that results in a broken mmap() syscall. > > The max_proc_mmap value is a signed int and roughly calculated > > at vmmapentry_rsrc_init() as u_long vm_kmem_size quotient: > > vm_kmem_size / sizeof(struct vm_map_entry) / 100. > > > > Although at the time it was introduced at svn r57263 the value > > was quite low (f.e. the related commit log stands: > > "The value defaults to around 9000 for a 128MB machine."), > > the problem is observed on amd64 where KVA space after > > r212784 is factually bound to the only physical memory size. > > > > With INT_MAX here is 0x7fffffff, and sizeof(struct vm_map_entry) > > is 120, it's enough to have sligthly less than 256GB to be able > > to reproduce the problem. > > > > I rewrote vmmapentry_rsrc_init() to set large enough limit for > > max_proc_mmap just to protect from integer type overflow. > > As it's also possible to live tune this value, I also added a > > simple anti-shoot constraint to its sysctl handler. > > I'm not sure though if it's worth to commit the second part. > > > > As this patch may cause some bikeshedding, > > I'd like to hear your comments before I will commit it. > > > > http://plukky.net/~pluknet/patches/max_proc_mmap.diff > > Is there any reason we can't just make this variable and sysctl a long? > > Or just delete it. 1. Contrary to what the commit message says, this sysctl does not effectively limit the number of vm map entries. It only limits the number that are created by one system call, mmap(). Other system calls create vm map entries just as easily, for example, mprotect(), madvise(), mlock(), and minherit(). Basically, anything that alters the properties of a mapping. Thus, in 2000, after this sysctl was added, the same resource exhaustion induced crash could have been reproduced by trivially changing the program in PR/16573 to do an mprotect() or two. In a nutshell, if you want to really limit the number of vm map entries that a process can allocate, the implementation is a bit more involved than what was done for this sysctl. 2. UMA implements M_WAITOK, whereas the old zone allocator in 2000 did not. Moreover, vm map entries for user maps are allocated with M_WAITOK. So, the exact crash reported in PR/16573 couldn't happen any longer. 3. We now have the "vmemoryuse" resource limit. When this sysctl was defined, we didn't. Limiting the virtual memory indirectly but effectively limits the number of vm map entries that a process can allocate. In summary, I would do a little due diligence, for example, run the program from PR/16573 with the limit disabled. If you can't reproduce the crash, in other words, nothing contradicts point #2 above, then I would just delete this sysctl. Alan From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 21 21:43:24 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 363D51065673; Fri, 21 Jan 2011 21:43:24 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 877FA8FC1B; Fri, 21 Jan 2011 21:43:23 +0000 (UTC) Received: by fxm16 with SMTP id 16so2382385fxm.13 for ; Fri, 21 Jan 2011 13:43:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=MpeDP6yIEhNH9QxPNvArK3Qjr4rSbcJiZVzUg1yb+0U=; b=JvNCjY9EYG7m1QgyXlyFWUrlvD+lbLr24W5tdwgeGxcTkZ/sa+a7P8OUkVZxUNN8OU LgXZFhZTKT6Ao7WM9rkvuM3SoTFR0OeqidBGu90q5Gk8sNz3wAiINB6XioIdsLh8mI4e UYtKPiQ+d7b7obLFsGw0M/DlZQ+SFSdDOY9Kk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=LNV4MUK3LcR8b7Ff40tvgsbb6izoWRVNioHYgddVurklxXsORLnmQzYHY0+uFahysD 4pt31LkcDo3JXS33QoCVP9MQSaLrfFIn1aBK8Iz1y1g3A40zPP9kuMQNrPuMgSeO24Ye V+KDYDaIZ+LFxsxgwC11aAl1D9OqlJNsjsZ38= MIME-Version: 1.0 Received: by 10.223.36.220 with SMTP id u28mr1229363fad.11.1295646202491; Fri, 21 Jan 2011 13:43:22 -0800 (PST) Received: by 10.223.126.207 with HTTP; Fri, 21 Jan 2011 13:43:22 -0800 (PST) In-Reply-To: References: <201101211244.13830.jhb@freebsd.org> Date: Fri, 21 Jan 2011 15:43:22 -0600 Message-ID: From: Alan Cox To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, Sergey Kandaurov Subject: Re: [rfc] allow to boot with >= 256GB physmem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alc@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 21:43:24 -0000 On Fri, Jan 21, 2011 at 2:58 PM, Alan Cox wrote: > On Fri, Jan 21, 2011 at 11:44 AM, John Baldwin wrote: > >> On Friday, January 21, 2011 11:09:10 am Sergey Kandaurov wrote: >> > Hello. >> > >> > Some time ago I faced with a problem booting with 400GB physmem. >> > The problem is that vm.max_proc_mmap type overflows with >> > such high value, and that results in a broken mmap() syscall. >> > The max_proc_mmap value is a signed int and roughly calculated >> > at vmmapentry_rsrc_init() as u_long vm_kmem_size quotient: >> > vm_kmem_size / sizeof(struct vm_map_entry) / 100. >> > >> > Although at the time it was introduced at svn r57263 the value >> > was quite low (f.e. the related commit log stands: >> > "The value defaults to around 9000 for a 128MB machine."), >> > the problem is observed on amd64 where KVA space after >> > r212784 is factually bound to the only physical memory size. >> > >> > With INT_MAX here is 0x7fffffff, and sizeof(struct vm_map_entry) >> > is 120, it's enough to have sligthly less than 256GB to be able >> > to reproduce the problem. >> > >> > I rewrote vmmapentry_rsrc_init() to set large enough limit for >> > max_proc_mmap just to protect from integer type overflow. >> > As it's also possible to live tune this value, I also added a >> > simple anti-shoot constraint to its sysctl handler. >> > I'm not sure though if it's worth to commit the second part. >> > >> > As this patch may cause some bikeshedding, >> > I'd like to hear your comments before I will commit it. >> > >> > http://plukky.net/~pluknet/patches/max_proc_mmap.diff >> >> Is there any reason we can't just make this variable and sysctl a long? >> >> > Or just delete it. > > 1. Contrary to what the commit message says, this sysctl does not > effectively limit the number of vm map entries. It only limits the number > that are created by one system call, mmap(). Other system calls create vm > map entries just as easily, for example, mprotect(), madvise(), mlock(), and > minherit(). Basically, anything that alters the properties of a mapping. > Thus, in 2000, after this sysctl was added, the same resource exhaustion > induced crash could have been reproduced by trivially changing the program > in PR/16573 to do an mprotect() or two. > > In a nutshell, if you want to really limit the number of vm map entries > that a process can allocate, the implementation is a bit more involved than > what was done for this sysctl. > > 2. UMA implements M_WAITOK, whereas the old zone allocator in 2000 did > not. Moreover, vm map entries for user maps are allocated with M_WAITOK. > So, the exact crash reported in PR/16573 couldn't happen any longer. > > Actually, I take back part of what I said here. The old zone allocator did implement something like M_WAITOK, and that appears to have been used for user maps. However, the crash described in PR/16573 was actually on the allocation of a vm map entry within the *kernel* address space for a process U area. This type of allocation did not use the old zone allocator's equivalent to M_WAITOK. However, we no longer have U areas, so the exact crash scenario is clearly no longer possible. Interestingly, the sysctl in question has no direct effect on the allocation of kernel vm map entries. So, I remain skeptical that this sysctl is preventing any resource exhaustion based panics in the current kernel. Again, I would be thrilled to see one or more people do some testing, such as rerunning the program from PR/16573. 3. We now have the "vmemoryuse" resource limit. When this sysctl was > defined, we didn't. Limiting the virtual memory indirectly but effectively > limits the number of vm map entries that a process can allocate. > > In summary, I would do a little due diligence, for example, run the program > from PR/16573 with the limit disabled. If you can't reproduce the crash, in > other words, nothing contradicts point #2 above, then I would just delete > this sysctl. > > Alan > > From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 22 08:41:04 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F22A9106564A for ; Sat, 22 Jan 2011 08:41:04 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id AD6C48FC08 for ; Sat, 22 Jan 2011 08:41:04 +0000 (UTC) Received: by gxk8 with SMTP id 8so804403gxk.13 for ; Sat, 22 Jan 2011 00:41:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=upyGq+gq+IfCQ9Fycrz8VAsBJrJ/QDjTRXpFCqRGz+Q=; b=U31WLVEzqQEoTNbbXY8k3gPLNMO6ArPEtgdEZ6jPCKfU6G0Y3qvbwckVaXJl1csOIa 9Gl2M16jiMyAkGUZrbso21C0et3JeVcA6O+bH2J+4gT+rVvpN5nDoQHpx3jLHDa2B8x+ km6zDwacqurDxlZfE1RHQLYJrLTGh8kvIi51w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=wICKdFXXpUeaHLxN5MraAWVW+5BR680WxwMFTuMyF/8k9R8T9cNJgzs3G7r68BZfoX yg6MLg+bz+58SburfeWHkwvoMDEIXdQGtCCb91zdy/ZGlaZXDcoFScsEh1Qakpi+dNUH ZlDtUdB7Ulmi0ZNE/JmogtSkLoZYqZjjOIXDw= MIME-Version: 1.0 Received: by 10.90.233.9 with SMTP id f9mr1979175agh.78.1295685663879; Sat, 22 Jan 2011 00:41:03 -0800 (PST) Received: by 10.90.86.18 with HTTP; Sat, 22 Jan 2011 00:41:03 -0800 (PST) Date: Sat, 22 Jan 2011 00:41:03 -0800 Message-ID: From: Garrett Cooper To: freebsd-hackers@freebsd.org Content-Type: multipart/mixed; boundary=00163628489abc72bd049a6b53bc Subject: [PATCH] Make libc includes more POSIX compliant w.r.t. time.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: Sat, 22 Jan 2011 08:41:05 -0000 --00163628489abc72bd049a6b53bc Content-Type: text/plain; charset=ISO-8859-1 Hi, A handful of source files in libc are missing time.h includes for clock_* and timer_* functions, as well as related macros and other bits defined by the POSIX 2008.1 spec and our manpages. The attached patch makes libc more POSIX and requirements compliant with time.h and stddef.h (required for NULL symbol as per POSIX). The work is part of a larger effort I started in //depot/user/gcooper/posix-conformance-work/ -- to make FreeBSD more POSIX compliant. If someone could assist by committing the attached patch, it would be much appreciated. Thanks! -Garrett --00163628489abc72bd049a6b53bc Content-Type: text/x-patch; charset=US-ASCII; name="add-missing-libc-time-h-includes.patch" Content-Disposition: attachment; filename="add-missing-libc-time-h-includes.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gj89qual0 ZGlmZiAtLWdpdCBhL3VzZXIvZ2Nvb3Blci9wb3NpeC1jb25mb3JtYW5jZS13b3JrL2xpYi9saWJj L2dlbi9mdHcuYyBiL3VzZXIvZ2Nvb3Blci9wb3NpeC1jb25mb3JtYW5jZS13b3JrL2xpYi9saWJj L2dlbi9mdHcuYwppbmRleCA5NTljOWNjLi42MGQ5ODFlIDEwMDY0NAotLS0gYS91c2VyL2djb29w ZXIvcG9zaXgtY29uZm9ybWFuY2Utd29yay9saWIvbGliYy9nZW4vZnR3LmMKKysrIGIvdXNlci9n Y29vcGVyL3Bvc2l4LWNvbmZvcm1hbmNlLXdvcmsvbGliL2xpYmMvZ2VuL2Z0dy5jCkBAIC0zNSw2 ICszNSw3IEBAIF9fRkJTRElEKCIkRnJlZUJTRDogc3JjL2xpYi9saWJjL2dlbi9mdHcuYyx2IDEu NCAyMDA0LzA4LzI0IDEzOjAwOjU1IHRqciBFeHAgJCIpCiAjaW5jbHVkZSA8ZnRzLmg+CiAjaW5j bHVkZSA8ZnR3Lmg+CiAjaW5jbHVkZSA8bGltaXRzLmg+CisjaW5jbHVkZSA8c3RkZGVmLmg+CiAK IGludAogZnR3KGNvbnN0IGNoYXIgKnBhdGgsIGludCAoKmZuKShjb25zdCBjaGFyICosIGNvbnN0 IHN0cnVjdCBzdGF0ICosIGludCksCmRpZmYgLS1naXQgYS91c2VyL2djb29wZXIvcG9zaXgtY29u Zm9ybWFuY2Utd29yay9saWIvbGliYy9nZW4vdXRpbWUuYyBiL3VzZXIvZ2Nvb3Blci9wb3NpeC1j b25mb3JtYW5jZS13b3JrL2xpYi9saWJjL2dlbi91dGltZS5jCmluZGV4IGY1YTVkOGEuLmVkYmRh NTQgMTAwNjQ0Ci0tLSBhL3VzZXIvZ2Nvb3Blci9wb3NpeC1jb25mb3JtYW5jZS13b3JrL2xpYi9s aWJjL2dlbi91dGltZS5jCisrKyBiL3VzZXIvZ2Nvb3Blci9wb3NpeC1jb25mb3JtYW5jZS13b3Jr L2xpYi9saWJjL2dlbi91dGltZS5jCkBAIC0zNCw3ICszNCw3IEBAIHN0YXRpYyBjaGFyIHNjY3Np ZFtdID0gIkAoIyl1dGltZS5jCTguMSAoQmVya2VsZXkpIDYvNC85MyI7CiBfX0ZCU0RJRCgiJEZy ZWVCU0Q6IHNyYy9saWIvbGliYy9nZW4vdXRpbWUuYyx2IDEuMyAyMDA3LzAxLzA5IDAwOjI3OjU2 IGltcCBFeHAgJCIpOwogCiAjaW5jbHVkZSA8c3lzL3RpbWUuaD4KLQorI2luY2x1ZGUgPHN0ZGRl Zi5oPgogI2luY2x1ZGUgPHV0aW1lLmg+CiAKIGludApkaWZmIC0tZ2l0IGEvdXNlci9nY29vcGVy L3Bvc2l4LWNvbmZvcm1hbmNlLXdvcmsvbGliL2xpYmMvaW5jbHVkZS9pc2MvZXZlbnRsaWIuaCBi L3VzZXIvZ2Nvb3Blci9wb3NpeC1jb25mb3JtYW5jZS13b3JrL2xpYi9saWJjL2luY2x1ZGUvaXNj L2V2ZW50bGliLmgKaW5kZXggNTAwMzgyMy4uZDk1NDdjOSAxMDA2NDQKLS0tIGEvdXNlci9nY29v cGVyL3Bvc2l4LWNvbmZvcm1hbmNlLXdvcmsvbGliL2xpYmMvaW5jbHVkZS9pc2MvZXZlbnRsaWIu aAorKysgYi91c2VyL2djb29wZXIvcG9zaXgtY29uZm9ybWFuY2Utd29yay9saWIvbGliYy9pbmNs dWRlL2lzYy9ldmVudGxpYi5oCkBAIC0yNSw5ICsyNSwxMCBAQAogI2RlZmluZSBfRVZFTlRMSUJf SAogCiAjaW5jbHVkZSA8c3lzL3R5cGVzLmg+Ci0jaW5jbHVkZSA8c3lzL3Vpby5oPgogI2luY2x1 ZGUgPHN5cy90aW1lLmg+CisjaW5jbHVkZSA8c3lzL3Vpby5oPgogI2luY2x1ZGUgPHN0ZGlvLmg+ CisjaW5jbHVkZSA8dGltZS5oPgogCiAjaW5jbHVkZSA8aXNjL3BsYXRmb3JtLmg+CiAKZGlmZiAt LWdpdCBhL3VzZXIvZ2Nvb3Blci9wb3NpeC1jb25mb3JtYW5jZS13b3JrL2xpYi9saWJjL25ldC9y Y21kLmMgYi91c2VyL2djb29wZXIvcG9zaXgtY29uZm9ybWFuY2Utd29yay9saWIvbGliYy9uZXQv cmNtZC5jCmluZGV4IGE0NDQyODMuLjc0MzcxNDAgMTAwNjQ0Ci0tLSBhL3VzZXIvZ2Nvb3Blci9w b3NpeC1jb25mb3JtYW5jZS13b3JrL2xpYi9saWJjL25ldC9yY21kLmMKKysrIGIvdXNlci9nY29v cGVyL3Bvc2l4LWNvbmZvcm1hbmNlLXdvcmsvbGliL2xpYmMvbmV0L3JjbWQuYwpAQCAtNTEsNiAr NTEsNyBAQCBfX0ZCU0RJRCgiJEZyZWVCU0Q6IHNyYy9saWIvbGliYy9uZXQvcmNtZC5jLHYgMS40 MiAyMDA3LzAxLzA5IDAwOjI4OjAyIGltcCBFeHAgJAogI2luY2x1ZGUgPHN0ZGlvLmg+CiAjaW5j bHVkZSA8Y3R5cGUuaD4KICNpbmNsdWRlIDxzdHJpbmcuaD4KKyNpbmNsdWRlIDx0aW1lLmg+CiAj aW5jbHVkZSA8cnBjL3JwYy5oPgogI2lmZGVmIFlQCiAjaW5jbHVkZSA8cnBjc3ZjL3lwX3Byb3Qu aD4K --00163628489abc72bd049a6b53bc--