From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 2 00:40:25 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1AA3A16A4B3 for ; Sun, 2 Jul 2006 00:40:25 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id D00DE44A9D for ; Sat, 1 Jul 2006 19:44:37 +0000 (GMT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 1 Jul 2006 20:44:36 +0100 (BST) Date: Sat, 1 Jul 2006 20:44:35 +0100 From: David Malone To: Hans Petter Selasky Message-ID: <20060701194435.GA30115@walton.maths.tcd.ie> References: <200605271102.19799.hselasky@c2i.net> <200606302029.28563.hselasky@c2i.net> <20060630203226.GG734@turion.vk2pj.dyndns.org> <200607011044.54872.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200607011044.54872.hselasky@c2i.net> User-Agent: Mutt/1.5.6i Sender: dwmalone@maths.tcd.ie Cc: freebsd-hackers@freebsd.org Subject: Re: contiguous memory allocation problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2006 00:40:25 -0000 On Sat, Jul 01, 2006 at 10:44:54AM +0200, Hans Petter Selasky wrote: > > The latest concensus seems to be that the USB system should make use of > > the scatter-gather facilities in the hardware to avoid the need to > > allocate large contiguous memory chunks. iedowse@ had mostly finished > > implementing this in mid May. > > Yes, but scatter and gather will add extra complexity to the driver, and maybe > an extra memory copy in most cases. The idea is to allocate less than or > equal to a page of memory, and then avoid the problem? I believe the USB drivers in -current grew scatter/gather support about a month ago. See the commit message below. Is this likely to help? David. Use the limited scatter-gather capabilities of ehci, ohci and uhci host controllers to avoid the need to allocate any multi-page physically contiguous memory blocks. This makes it possible to use USB devices reliably on low-memory systems or when memory is too fragmented for contiguous allocations to succeed. The USB subsystem now uses bus_dmamap_load() directly on the buffers supplied by USB peripheral drivers, so this also avoids having to copy data back and forth before and after transfers. The ehci and ohci controllers support scatter/gather as long as the buffer is contiguous in the virtual address space. For uhci the hardware cannot handle a physical address discontinuity within a USB packet, so it is necessary to copy small memory fragments at times. From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 2 01:57:17 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EDDAE16A513 for ; Sun, 2 Jul 2006 01:57:17 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2711D44334 for ; Sat, 1 Jul 2006 15:10:12 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from Andro-Beta.Leidinger.net (p54A5DBEF.dip.t-dialin.net [84.165.219.239]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.6/8.13.6) with ESMTP id k61F2jic039339; Sat, 1 Jul 2006 17:02:46 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) by Andro-Beta.Leidinger.net (8.13.4/8.13.3) with ESMTP id k61F9vbM093259; Sat, 1 Jul 2006 17:09:57 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Sat, 1 Jul 2006 17:10:52 +0200 From: Alexander Leidinger To: "Joseph Koshy" Message-ID: <20060701171052.6da59330@Magellan.Leidinger.net> In-Reply-To: <84dead720607010554w3ecc8618xb8ede50ac3fba29d@mail.gmail.com> References: <000f01c69ca5$02fa8ff0$6400a8c0@s2003> <20060701032139.GB4915@dan.emsphone.com> <84dead720607010554w3ecc8618xb8ede50ac3fba29d@mail.gmail.com> X-Mailer: Sylpheed-Claws 2.3.1 (GTK+ 2.8.19; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new X-Mailman-Approved-At: Sun, 02 Jul 2006 03:49:29 +0000 Cc: freebsd-hackers@freebsd.org, Jean-Marc Lienher , Dan Nelson Subject: Re: Alternative compiler toolchain ? 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, 02 Jul 2006 01:57:18 -0000 Quoting "Joseph Koshy" (Sat, 1 Jul 2006 18:24:18 +0530): > Other bugs with tcc on FreeBSD: > - Someone reported that a few of our headers don't > compile with tcc. I haven't tracked down whether > this is on account of an unsupported Gcc'ism in > the header or whether this is a bug in tcc. Maybe it's enough to add tcc support to sys/cdefs.h. Bye, Alexander. -- Forrest Gump: "I'm sorry for ruining your party, Lieutenant Dan. She tasted of cigarettes" 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 Sun Jul 2 09:38:08 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B87E16A412 for ; Sun, 2 Jul 2006 09:38:08 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.swip.net [212.247.154.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4E6D43D45 for ; Sun, 2 Jul 2006 09:38:07 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: gvlK0tOCzrqh9CPROFOFPw== X-Cloudmark-Score: 0.000000 [] Received: from mp-216-91-105.daxnet.no ([193.216.91.105] verified) by mailfe04.swip.net (CommuniGate Pro SMTP 5.0.8) with ESMTP id 224810400; Sun, 02 Jul 2006 11:38:04 +0200 From: Hans Petter Selasky To: David Malone Date: Sun, 2 Jul 2006 11:38:10 +0200 User-Agent: KMail/1.7 References: <200605271102.19799.hselasky@c2i.net> <200607011044.54872.hselasky@c2i.net> <20060701194435.GA30115@walton.maths.tcd.ie> In-Reply-To: <20060701194435.GA30115@walton.maths.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607021138.11945.hselasky@c2i.net> Cc: freebsd-hackers@freebsd.org Subject: Re: contiguous memory allocation problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2006 09:38:08 -0000 On Saturday 01 July 2006 21:44, David Malone wrote: > On Sat, Jul 01, 2006 at 10:44:54AM +0200, Hans Petter Selasky wrote: > > > The latest concensus seems to be that the USB system should make use of > > > the scatter-gather facilities in the hardware to avoid the need to > > > allocate large contiguous memory chunks. iedowse@ had mostly finished > > > implementing this in mid May. > > > > Yes, but scatter and gather will add extra complexity to the driver, and > > maybe an extra memory copy in most cases. The idea is to allocate less > > than or equal to a page of memory, and then avoid the problem? > > I believe the USB drivers in -current grew scatter/gather support > about a month ago. See the commit message below. Is this likely to > help? I see. But there is one problem, that has been overlooked, and that is High speed isochronous transfers, which are not supported by the existing USB system. I don't think that the EHCI specification was designed for scatter and gather, when you consider this: 8 transfers of 0xC00 bytes has to fit on 7 pages. If this is going to work, and I am right, one page has to contain two transfers. (see page 43 of ehci-r10.pdf) Currently the PAGE_SIZE is 0x1000, right? As you can see "(0xC00 * 2) > 0x1000". So is it possible to change the PAGE_SIZE ? --HPS From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 2 09:50:28 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB02116A407 for ; Sun, 2 Jul 2006 09:50:28 +0000 (UTC) (envelope-from mmendez@energyhq.be) Received: from spitfire.energyhq.be (20.Red-88-6-12.staticIP.rima-tde.net [88.6.12.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id B55614412E for ; Sun, 2 Jul 2006 09:50:25 +0000 (GMT) (envelope-from mmendez@energyhq.be) Received: from scienide.energyhq.be (scienide.energyhq.be [192.168.2.2]) by spitfire.energyhq.be (Postfix) with SMTP id 7BEA9FEAE; Sun, 2 Jul 2006 11:50:23 +0200 (CEST) Date: Sun, 2 Jul 2006 11:49:50 +0200 From: Miguel Mendez To: Christian Zander Message-Id: <20060702114950.bf39e312.mmendez@energyhq.be> In-Reply-To: <20060629111231.GA692@wolf.nvidia.com> References: <20060629111231.GA692@wolf.nvidia.com> Organization: EnergyHQ X-Mailer: Sylpheed version 2.2.0 (GTK+ 2.8.11; amd64-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Sun__2_Jul_2006_11_49_50_+0200_2W40b2VpcOOz+tYZ" Cc: freebsd-hackers@freebsd.org Subject: Re: NVIDIA FreeBSD kernel feature requests 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, 02 Jul 2006 09:50:28 -0000 --Signature=_Sun__2_Jul_2006_11_49_50_+0200_2W40b2VpcOOz+tYZ Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 29 Jun 2006 13:12:31 +0200 Christian Zander wrote: Hi, I just saw an article on OSNews about this, seems I missed it. > NVIDIA has been looking at ways to improve its graphics driver for the > FreeBSD i386 platform, as well as investigating the possibility of adding > support for the FreeBSD amd64 platform, and identified a number of > obstacles. Some progress has been made to resolve them, and NVIDIA would Yes, I'll tell you what the obstacle is: Lack of documentation. If you guys released the specs of your hardware this wouldn't be a problem. Maybe not for the latest GPUs but I'm sure a lot people would be happy if they could use not-so-new NVidia hardware on FreeBSD/amd64. I built and AMD64 box from scratch with the sole purpose of running FreeBSD/amd64 on it. When it came time to choose the gfx card the choice was obvious: Ati Radeon 9250. I know that a lot of FreeBSDers are more than happy to have proprietary drivers which I personlly won't touch with the proverbial 10 foot pole :) So please, do tell, is there any _real_ problem with releasing a register spec doc for last year's hardware so amd64 users can hope to have more than a framebuffer some day? How about the proprietary nforce4 chipset? Cheers. --=20 Miguel Mendez =20 http://www.energyhq.be PGP Key: 0xDC8514F1 --Signature=_Sun__2_Jul_2006_11_49_50_+0200_2W40b2VpcOOz+tYZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEp5bBnLctrNyFFPERApKLAJ4zppstC0ubnW0emXQPO4WhWY4x3QCfeCfK ZWeZvczakRpw4iOcQolO85U= =lPCq -----END PGP SIGNATURE----- --Signature=_Sun__2_Jul_2006_11_49_50_+0200_2W40b2VpcOOz+tYZ-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 2 12:05:04 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C8E816A40F for ; Sun, 2 Jul 2006 12:05:04 +0000 (UTC) (envelope-from iedowse@iedowse.com) Received: from nowhere.iedowse.com (nowhere.iedowse.com [82.195.144.75]) by mx1.FreeBSD.org (Postfix) with SMTP id BD97B43D45 for ; Sun, 2 Jul 2006 12:05:03 +0000 (GMT) (envelope-from iedowse@iedowse.com) Received: from localhost ([127.0.0.1] helo=iedowse.com) by nowhere.iedowse.com via local-iedowse id ; 2 Jul 2006 13:05:01 +0100 (IST) To: Hans Petter Selasky In-Reply-To: Your message of "Sun, 02 Jul 2006 11:38:10 +0200." <200607021138.11945.hselasky@c2i.net> Date: Sun, 02 Jul 2006 13:05:00 +0100 From: Ian Dowse Message-ID: <200607021305.aa75873@nowhere.iedowse.com> Cc: David Malone , freebsd-hackers@freebsd.org Subject: Re: contiguous memory allocation problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2006 12:05:04 -0000 In message <200607021138.11945.hselasky@c2i.net>, Hans Petter Selasky writes: >But there is one problem, that has been overlooked, and that is High speed >isochronous transfers, which are not supported by the existing USB system. I >don't think that the EHCI specification was designed for scatter and gather, >when you consider this: > >8 transfers of 0xC00 bytes has to fit on 7 pages. If this is going to work, >and I am right, one page has to contain two transfers. (see page 43 of >ehci-r10.pdf) I haven't looked into the details, but the text in section 3.3.3 seems to suggest that EHCI is designed to not require physically contiguous allocations here either, so the same approach of using bus_dmamap_load() should work: This data structure requires the associated data buffer to be contiguous (relative to virtual memory), but allows the physical memory pages to be non-contiguous. Seven page pointers are provided to support the expression of 8 isochronous transfers. The seven pointers allow for 3 (transactions) * 1024 (maximum packet size) * 8 (transaction records) (24576 bytes) to be moved with this data structure, regardless of the alignment offset of the first page. Ian From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 2 12:33:28 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3BE6E16A407 for ; Sun, 2 Jul 2006 12:33:28 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.swip.net [212.247.154.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B0ED43D45 for ; Sun, 2 Jul 2006 12:33:27 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: gvlK0tOCzrqh9CPROFOFPw== X-Cloudmark-Score: 0.000000 [] Received: from mp-216-120-91.daxnet.no ([193.216.120.91] verified) by mailfe05.swip.net (CommuniGate Pro SMTP 5.0.8) with ESMTP id 125631313; Sun, 02 Jul 2006 14:33:25 +0200 From: Hans Petter Selasky To: Ian Dowse Date: Sun, 2 Jul 2006 14:33:30 +0200 User-Agent: KMail/1.7 References: <200607021305.aa75873@nowhere.iedowse.com> In-Reply-To: <200607021305.aa75873@nowhere.iedowse.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607021433.32278.hselasky@c2i.net> Cc: David Malone , freebsd-hackers@freebsd.org Subject: Re: contiguous memory allocation problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2006 12:33:28 -0000 On Sunday 02 July 2006 14:05, Ian Dowse wrote: > In message <200607021138.11945.hselasky@c2i.net>, Hans Petter Selasky writes: > >But there is one problem, that has been overlooked, and that is High speed > >isochronous transfers, which are not supported by the existing USB system. > > I don't think that the EHCI specification was designed for scatter and > > gather, when you consider this: > > > >8 transfers of 0xC00 bytes has to fit on 7 pages. If this is going to > > work, and I am right, one page has to contain two transfers. (see page 43 > > of ehci-r10.pdf) > > I haven't looked into the details, but the text in section 3.3.3 > seems to suggest that EHCI is designed to not require physically > contiguous allocations here either, so the same approach of using > bus_dmamap_load() should work: > > This data structure requires the associated data buffer to be > contiguous (relative to virtual memory), but allows the physical > memory pages to be non-contiguous. Seven page pointers are provided > to support the expression of 8 isochronous transfers. The seven > pointers allow for 3 (transactions) * 1024 (maximum packet size) > * 8 (transaction records) (24576 bytes) to be moved with this > data structure, regardless of the alignment offset of the first > page. 3 * 1024 bytes = 0xC00 bytes 8 * 0xC00 = 0x6000 bytes maximum According to this you need "6" "EHCI pages", because "6 * 0x1000 = 0x6000". The seventh "EHCI page" is just there to allow one to start at any page offset. There is no eight "EHCI page". The only solution I see, is to have a double layer ITD. The first layer have the 4 first transfers activated, and the second layer have the 4 last transfers activated. A little more complicated, but not impossible. --HPS From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 2 13:23:56 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 20C9516A403 for ; Sun, 2 Jul 2006 13:23:56 +0000 (UTC) (envelope-from iedowse@iedowse.com) Received: from nowhere.iedowse.com (nowhere.iedowse.com [82.195.144.75]) by mx1.FreeBSD.org (Postfix) with SMTP id 1143943D45 for ; Sun, 2 Jul 2006 13:23:54 +0000 (GMT) (envelope-from iedowse@iedowse.com) Received: from localhost ([127.0.0.1] helo=iedowse.com) by nowhere.iedowse.com via local-iedowse id ; 2 Jul 2006 14:23:53 +0100 (IST) To: Hans Petter Selasky In-Reply-To: Your message of "Sun, 02 Jul 2006 14:33:30 +0200." <200607021433.32278.hselasky@c2i.net> Date: Sun, 02 Jul 2006 14:23:53 +0100 From: Ian Dowse Message-ID: <200607021423.aa76796@nowhere.iedowse.com> Cc: David Malone , freebsd-hackers@freebsd.org Subject: Re: contiguous memory allocation problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2006 13:23:56 -0000 In message <200607021433.32278.hselasky@c2i.net>, Hans Petter Selasky writes: >On Sunday 02 July 2006 14:05, Ian Dowse wrote: >> This data structure requires the associated data buffer to be >> contiguous (relative to virtual memory), but allows the physical >> memory pages to be non-contiguous. Seven page pointers are provided >> to support the expression of 8 isochronous transfers. The seven >> pointers allow for 3 (transactions) * 1024 (maximum packet size) >> * 8 (transaction records) (24576 bytes) to be moved with this >> data structure, regardless of the alignment offset of the first >> page. > >3 * 1024 bytes = 0xC00 bytes > >8 * 0xC00 = 0x6000 bytes maximum > >According to this you need "6" "EHCI pages", because "6 * 0x1000 = 0x6000". >The seventh "EHCI page" is just there to allow one to start at any page >offset. There is no eight "EHCI page". > >The only solution I see, is to have a double layer ITD. The first layer have >the 4 first transfers activated, and the second layer have the 4 last >transfers activated. > >A little more complicated, but not impossible. The trick is that if the 0x6000 bytes are contiguous in virtual memory then they never span more than 6 pages so one iTD is enough. i.e. you can just do malloc(0x6000) and you don't need multi-page physically contiguous buffers or extra memory-memory copies regardless of how the virtual buffer maps to physical pages. This seems to be the general extent of scatter-gather support offered by the various USB host controllers (modulo various caveats such as assuming pages are >= 4k, handling physical addresses > 4GB on non-IOMMU hardware and UHCI's lack of support for mid-packet non-contiguous page boundaries). Ian From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 2 14:34:37 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 133AE16A817 for ; Sun, 2 Jul 2006 14:34:37 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id B775243D62 for ; Sun, 2 Jul 2006 14:34:27 +0000 (GMT) (envelope-from Andre.Albsmeier@siemens.com) Received: from mail2.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id k62EYPvV022902; Sun, 2 Jul 2006 16:34:25 +0200 Received: from ims.mchp.siemens.de (ims.mchp.siemens.de [139.25.31.39]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id k62EYP0c015141; Sun, 2 Jul 2006 16:34:25 +0200 Received: from mail-ct.mchp.siemens.de (mail-ct.mchp.siemens.de [139.25.31.51]) by ims.mchp.siemens.de with ESMTP id k62EYOJQ020611; Sun, 2 Jul 2006 16:34:24 +0200 (MEST) Received: from curry.mchp.siemens.de (curry [139.25.40.130]) by mail-ct.mchp.siemens.de (8.12.11/8.12.11) with ESMTP id k62EYO1L006351; Sun, 2 Jul 2006 16:34:24 +0200 (MEST) Received: (from localhost) by curry.mchp.siemens.de (8.13.6/8.13.6) id k62EYNJK086643; Date: Sun, 2 Jul 2006 16:34:23 +0200 From: Andre Albsmeier To: Matthias Andree Message-ID: <20060702143423.GA1108@curry.mchp.siemens.de> References: <20060628181045.GA54915@curry.mchp.siemens.de> <20060629054222.GA92895@leiferikson.flosken.lan> <20060629162319.GA94921@leiferikson.flosken.lan> <20060630045937.GB97868@leiferikson.flosken.lan> <417C9B11412FF8C17A1AD483@Zelazny> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Echelon: X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.11 Cc: freebsd-hackers@freebsd.org, Pat Lashley , Johannes Weiner , Andre.Albsmeier@siemens.com Subject: Re: Return value of malloc(0) 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, 02 Jul 2006 14:34:37 -0000 On Sat, 01-Jul-2006 at 10:35:47 +0200, Matthias Andree wrote: > Pat Lashley writes: > > > BUT, that said, the safest and most portable coding practice would be: > > > > // The C standard does not require malloc(0) to return NULL; > > // but whatever it returns MUST NOT be dereferenced. > > ptr = ( size == 0 ) ? NULL : malloc( size ) ; > > Safest (avoiding null derefence) would instead be: > > ptr = malloc(size ? size : 1); I hacked malloc.c to do exactly this automatically, just for testing. 15 Minutes after rebooting (and after doing a lot of desktop switching and opening and closing of windows) the X-server ran out of memory :-). I assume there are lots of programs out there which do malloc(0) but only firefox (and apparently seamonkey) dereference the returned non-NULL pointer and crash therefore. -Andre From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 2 14:59:38 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 84FB716A40F for ; Sun, 2 Jul 2006 14:59:38 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id B334B43D45 for ; Sun, 2 Jul 2006 14:59:36 +0000 (GMT) (envelope-from Andre.Albsmeier@siemens.com) Received: from mail3.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id k62ExZd5007556; Sun, 2 Jul 2006 16:59:35 +0200 Received: from ims.mchp.siemens.de (ims.mchp.siemens.de [139.25.31.39]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id k62ExYAH003564; Sun, 2 Jul 2006 16:59:35 +0200 Received: from mail-ct.mchp.siemens.de (mail-ct.mchp.siemens.de [139.25.31.51]) by ims.mchp.siemens.de with ESMTP id k62ExYJQ020630; Sun, 2 Jul 2006 16:59:34 +0200 (MEST) Received: from curry.mchp.siemens.de (curry [139.25.40.130]) by mail-ct.mchp.siemens.de (8.12.11/8.12.11) with ESMTP id k62ExYTA008817; Sun, 2 Jul 2006 16:59:34 +0200 (MEST) Received: (from localhost) by curry.mchp.siemens.de (8.13.6/8.13.6) id k62ExX7n086703; Date: Sun, 2 Jul 2006 16:59:33 +0200 From: Andre Albsmeier To: Pat Lashley Message-ID: <20060702145933.GB1108@curry.mchp.siemens.de> References: <20060628181045.GA54915@curry.mchp.siemens.de> <20060628212956.GI822@wombat.fafoe.narf.at> <805AA34B676EDF411B3CF548@Zelazny> <20060629165629.GA6875@britannica.bec.de> <44odwbu1cu.fsf@be-well.ilk.org> <2FCF78FADC5CAB74EF6D9405@Zelazny> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2FCF78FADC5CAB74EF6D9405@Zelazny> X-Echelon: X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.11 Cc: freebsd-hackers@freebsd.org, Andre.Albsmeier@siemens.com Subject: Re: Return value of malloc(0) 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, 02 Jul 2006 14:59:38 -0000 On Fri, 30-Jun-2006 at 12:15:21 -0400, Pat Lashley wrote: > >I went wandering through the C Working Group archives for the heck of > >it, and apparently a lot of people were confused over this, thinking > >either as you did or that "unique" meant it would a value unique to > >the usage of malloc(0). It's been clarified recently (and will be in > >the next revision of the standard) to the meaning you understood. > > ... > > >This is wandering into -standards territory, though. In any case, the > >answer to thread's original question is "mozilla should fix its code > >to not assume malloc(0)==NULL". > > Agreed. (With the usual observation that they, too, are a mainly > volunteer-based project; and would probably appreciate the inclusion of a patch Well, I was unsure of the correct behaviour. That's why I came here:-). >From all what I've read so far, I can summarize: - Returning a non-NULL value from malloc(0) is completely legal. - We return a non-NULL value which, when dereferenced, always make the application crash (as a warning). See the commit message of rev. 1.60 of malloc.c: -------------------------------- snip -------------------------- phkmalloc->evilchecks++; If zero bytes are allocated, return pointer to the middle of page-zero (which is protected) so that the programme will crash if it dereferences this illgotten pointer. Inspired & Urged by: Theo de Raadt -------------------------------- snap -------------------------- - What we do isn't 100% perfect since we always return the same value for each malloc(0). - It was firefox' fault to crash. - The manpage is heavily misleading. Firefox must be fixed but some stuff can be done in FreeBSD as well: - If we keep our current behaviour we have to change the manpage. (As I said before, I could do that if someone will commit it later.) - We could reverse the meaning of the V-flag (or, introduce a new flag to avoid confusion). This would mean that by default a malloc(0) will return NULL in future. The new flag can be used to change this behaviour to the way it was done before: We hand out the value which, when dereferenced, make the programme crash as a warning to the author. We note in the manpage that it is not 100% legal since we always use the same value. > with the bug report. And, of course, that the original poster of this thread > should file a bug report with the Mozilla project.) Please see: https://bugzilla.mozilla.org/show_bug.cgi?id=343283 It wasn't me who created this PR but the author of the extension which actually revealed the bug. -Andre -- UNIX is an operating system, OS/2 is half an operating system, Windows is a shell, and DOS is a bootsector virus. From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 2 15:20:42 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B8DB716A407 for ; Sun, 2 Jul 2006 15:20:42 +0000 (UTC) (envelope-from iedowse@iedowse.com) Received: from nowhere.iedowse.com (nowhere.iedowse.com [82.195.144.75]) by mx1.FreeBSD.org (Postfix) with SMTP id EBDD343D49 for ; Sun, 2 Jul 2006 15:20:41 +0000 (GMT) (envelope-from iedowse@iedowse.com) Received: from localhost ([127.0.0.1] helo=iedowse.com) by nowhere.iedowse.com via local-iedowse id ; 2 Jul 2006 16:20:40 +0100 (IST) To: Hans Petter Selasky In-Reply-To: Your message of "Sun, 02 Jul 2006 14:23:53 BST." <200607021423.aa76796@nowhere.iedowse.com> Date: Sun, 02 Jul 2006 16:20:39 +0100 From: Ian Dowse Message-ID: <200607021620.aa78471@nowhere.iedowse.com> Cc: David Malone , freebsd-hackers@freebsd.org Subject: Re: contiguous memory allocation problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2006 15:20:42 -0000 In message <200607021423.aa76796@nowhere.iedowse.com>, Ian Dowse writes: >The trick is that if the 0x6000 bytes are contiguous in virtual >memory then they never span more than 6 pages so one iTD is enough. Sorry, I meant of course 6 page boundaries, which means no more than 7 pages. This is why the 7 physical address slots in the iTD is always enough for 8 x 3k transaction records if the 24k buffer is contiguous in virtual memory. Ian From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 2 15:59:49 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BE5816A407 for ; Sun, 2 Jul 2006 15:59:49 +0000 (UTC) (envelope-from randyhyde@earthlink.net) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBFF643D46 for ; Sun, 2 Jul 2006 15:59:48 +0000 (GMT) (envelope-from randyhyde@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=BeIK97Mxi0a4rFwr75bz0W1y7DhyKkoxZVW1ZWkUsT/ZOy8D24QlvY1F1fftsn21; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.180.58.59] (helo=pentiv) by elasmtp-galgo.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Fx4MO-0003Lb-0X for freebsd-hackers@freebsd.org; Sun, 02 Jul 2006 11:59:48 -0400 Message-ID: <001b01c69df0$973850c0$6302a8c0@pentiv> From: "Randall Hyde" To: References: <200605271102.19799.hselasky@c2i.net><200606302029.28563.hselasky@c2i.net><20060630203226.GG734@turion.vk2pj.dyndns.org><200607011044.54872.hselasky@c2i.net> <20060701123444.GD8447@turion.vk2pj.dyndns.org> Date: Sun, 2 Jul 2006 09:00:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-ELNK-Trace: eba5e0c9192a36dcd6dd28457998182d7e972de0d01da940de51b7939e7063835168e21e54c50403350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.180.58.59 Subject: Re: contiguous memory allocation problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2006 15:59:49 -0000 ----- Original Message ----- From: "Peter Jeremy" To: "Randall Hyde" Sent: Saturday, July 01, 2006 11:10 PM Subject: Re: FLEX, was Re: Return value of malloc(0) The following compiles without error: %{ typedef int YYSTYPE; typedef int YYLTYPE; /* ** Allow for a recursive version of Bison parser. */ #undef YY_DECL #define YY_DECL int yylex( YYSTYPE *yylval, YYLTYPE *yylloc) %} %% . ECHO; %% I'll accept that you are having a problem getting HLA to build. No-one else is reporting problems. If you want assistance from other people then you are going to need to help by either providing a test case to reproduce the failure you are seeing or you are going to need to provide the pre-processed context where the error occurs. <<<<<<<<<<<<<<<<<<<<<<< Uh, is the above *not* the test case you are asking for? Does this particular code snippet compile for you? If so, then I've definitely got some configuration problems with GCC on my machine. BTW, if I haven't made myself clear, the problem with the code above is a GCC error, not a FLEX error. That is, FLEX happily produces the yy.lex.c output file, GCC under FreeBSD rejects the source code it produces. Yet that *same exact* source code compiles just fine under Linux with GCC, Windows with Borland C++, and Windows with VC++. Creating a recursive lexer is a documented feature of FLEX. Indeed, I used the example present in the FLEX documentation to pull this off. And I've been using this code for about eight years on Windows and about four years on Linux. Perhaps FreeBSD types have never tried to create a recursive parser/lexer and haven't had to deal with this issue, but as you can see from the code snippet above, this really has nothing to do with HLA, per se, other than the fact that it uses a recursive lexer/parser. And the fact remains, the code compiles just fine under Windows and Linux. The compilation uses a documented feature of FLEX. There *is* a problem with the implementation of GCC under FreeBSD (or header files under FreeBSD). It's not specific to HLA. And I can't imagine how to give you a better test case than the code above. Cheers, Randy Hyde From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 2 17:20:32 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AAA5616A412 for ; Sun, 2 Jul 2006 17:20:32 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id B916D44141 for ; Sun, 2 Jul 2006 16:52:31 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.13.7/8.13.7) with ESMTP id k62Gq4KD015381; Sun, 2 Jul 2006 09:52:04 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.7/8.13.7/Submit) id k62Gq0N0015380; Sun, 2 Jul 2006 09:52:00 -0700 (PDT) (envelope-from sgk) Date: Sun, 2 Jul 2006 09:52:00 -0700 From: Steve Kargl To: Randall Hyde Message-ID: <20060702165200.GA15180@troutmask.apl.washington.edu> References: <20060701123444.GD8447@turion.vk2pj.dyndns.org> <001b01c69df0$973850c0$6302a8c0@pentiv> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001b01c69df0$973850c0$6302a8c0@pentiv> User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@freebsd.org Subject: Re: contiguous memory allocation problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2006 17:20:32 -0000 On Sun, Jul 02, 2006 at 09:00:07AM -0700, Randall Hyde wrote: > > ----- Original Message ----- > From: "Peter Jeremy" > To: "Randall Hyde" > Sent: Saturday, July 01, 2006 11:10 PM > Subject: Re: FLEX, was Re: Return value of malloc(0) > > The following compiles without error: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > %{ > typedef int YYSTYPE; > typedef int YYLTYPE; > > /* > ** Allow for a recursive version of Bison parser. > */ > #undef YY_DECL > #define YY_DECL int yylex( YYSTYPE *yylval, YYLTYPE *yylloc) > %} > > %% > . ECHO; > %% > > I'll accept that you are having a problem getting HLA to build. No-one > else is reporting problems. If you want assistance from other people > then you are going to need to help by either providing a test case to > reproduce the failure you are seeing or you are going to need to provide > the pre-processed context where the error occurs. > > <<<<<<<<<<<<<<<<<<<<<<< > > Uh, is the above *not* the test case you are asking for? Carefully, read what Peter wrote. The code above compiles on FreeBSD. As does the 37 *.y files under /usr/src (excluding the 30 *.y under /usr/src/contrib which may or may not be used during compilation). > Does this particular code snippet compile for you? Yes, it does. > If so, then I've definitely got some configuration problems > with GCC on my machine. What version of FreeBSD, and did you upgrade from a previous version? Perhaps, you have some stale header files. Did you install a different version of gcc under /usr/local (or other directory) that appears early in your path? -- Steve From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 2 19:06:24 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3443916A412 for ; Sun, 2 Jul 2006 19:06:24 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe12.swip.net [212.247.155.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8904843D49 for ; Sun, 2 Jul 2006 19:06:23 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: gvlK0tOCzrqh9CPROFOFPw== X-Cloudmark-Score: 0.000000 [] Received: from mp-216-87-158.daxnet.no ([193.216.87.158] verified) by mailfe12.swip.net (CommuniGate Pro SMTP 5.0.8) with ESMTP id 56831261; Sun, 02 Jul 2006 21:06:21 +0200 From: Hans Petter Selasky To: Ian Dowse Date: Sun, 2 Jul 2006 21:06:21 +0200 User-Agent: KMail/1.7 References: <200607021620.aa78471@nowhere.iedowse.com> In-Reply-To: <200607021620.aa78471@nowhere.iedowse.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607022106.22935.hselasky@c2i.net> Cc: David Malone , freebsd-hackers@freebsd.org Subject: Re: contiguous memory allocation problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2006 19:06:24 -0000 On Sunday 02 July 2006 17:20, Ian Dowse wrote: > In message <200607021423.aa76796@nowhere.iedowse.com>, Ian Dowse writes: > >The trick is that if the 0x6000 bytes are contiguous in virtual > >memory then they never span more than 6 pages so one iTD is enough. > > Sorry, I meant of course 6 page boundaries, which means no more > than 7 pages. This is why the 7 physical address slots in the iTD > is always enough for 8 x 3k transaction records if the 24k buffer > is contiguous in virtual memory. > Ok. So the solution to my problem is to use scatter and gather. I will see about updating my USB system to do it like that. But there is one thing I do not understand yet. When you load a page that physically resides above 4GB, because a computer has more than 4GB of memory, how does "bus_dmamap_load()" move that page down below 4GB, so that the 32-bit USB host controllers can reach it? --HPS From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 2 21:30:33 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A4F0C16A548 for ; Sun, 2 Jul 2006 21:30:33 +0000 (UTC) (envelope-from iedowse@iedowse.com) Received: from nowhere.iedowse.com (nowhere.iedowse.com [82.195.144.75]) by mx1.FreeBSD.org (Postfix) with SMTP id 489D3440F5 for ; Sun, 2 Jul 2006 21:03:49 +0000 (GMT) (envelope-from iedowse@iedowse.com) Received: from localhost ([127.0.0.1] helo=iedowse.com) by nowhere.iedowse.com via local-iedowse id ; 2 Jul 2006 22:03:47 +0100 (IST) To: Hans Petter Selasky In-Reply-To: Your message of "Sun, 02 Jul 2006 21:06:21 +0200." <200607022106.22935.hselasky@c2i.net> Date: Sun, 02 Jul 2006 22:03:47 +0100 From: Ian Dowse Message-ID: <200607022203.aa83223@nowhere.iedowse.com> Cc: David Malone , freebsd-hackers@freebsd.org Subject: Re: contiguous memory allocation problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2006 21:30:33 -0000 In message <200607022106.22935.hselasky@c2i.net>, Hans Petter Selasky writes: >Ok. So the solution to my problem is to use scatter and gather. I will see >about updating my USB system to do it like that. > >But there is one thing I do not understand yet. When you load a page that >physically resides above 4GB, because a computer has more than 4GB of memory, >how does "bus_dmamap_load()" move that page down below 4GB, so that the >32-bit USB host controllers can reach it? What should happen is that bus_dma allocates a bounce buffer and performs copies as required from within the bus_dmamap_sync() calls. This is something I haven't been able to verify yet with the USB code though, so there could easily be bugs there. BTW, as far as I know bus_dma is also missing support for multi-segment allocations, so for example if you ask it to allocate 16k in at most 4 segments below the 4GB mark, it will actually attempt a physically contiguous allocation. If this was fixed it could be used by usbd_alloc_buffer() to give directly usable buffers without contiguous allocations. Ian From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 2 21:53:45 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C0BD316A4B3 for ; Sun, 2 Jul 2006 21:53:45 +0000 (UTC) (envelope-from mime@traveller.cz) Received: from ss.eunet.cz (ss.eunet.cz [193.85.228.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8648343FDB for ; Sun, 2 Jul 2006 21:53:02 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from localhost.i.cz (ss.eunet.cz [193.85.228.13]) by ss.eunet.cz (8.13.6/8.13.6) with ESMTP id k62LpbJD092142 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 2 Jul 2006 23:51:38 +0200 (CEST) (envelope-from mime@traveller.cz) From: Michal Mertl To: Miguel Mendez In-Reply-To: <20060702114950.bf39e312.mmendez@energyhq.be> References: <20060629111231.GA692@wolf.nvidia.com> <20060702114950.bf39e312.mmendez@energyhq.be> Content-Type: text/plain Date: Sun, 02 Jul 2006 23:51:35 +0200 Message-Id: <1151877095.1085.19.camel@genius.i.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Christian Zander Subject: Re: NVIDIA FreeBSD kernel feature requests 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, 02 Jul 2006 21:53:45 -0000 Miguel Mendez wrote: > On Thu, 29 Jun 2006 13:12:31 +0200 > Christian Zander wrote: > > Hi, > > I just saw an article on OSNews about this, seems I missed it. > > > NVIDIA has been looking at ways to improve its graphics driver for the > > FreeBSD i386 platform, as well as investigating the possibility of adding > > support for the FreeBSD amd64 platform, and identified a number of > > obstacles. Some progress has been made to resolve them, and NVIDIA would > > Yes, I'll tell you what the obstacle is: Lack of documentation. If you > guys released the specs of your hardware this wouldn't be a problem. I think that this reaction wasn't called for. Modern GPUs are extraordinarily complex HW and to write a decent driver will take appropriate effort. I understand that open source "infected" people (like me) prefer having the detailed HW documentation but we shouldn't refuse the vendor's efforts to provide good driver to us. I haven't understood much of Mr. Zander's questions but I am pretty sure some readers did and probably have been talking to him off-list. I also tend to believe that his requests for features were based on good understanding of FreeBSD kernel internals (better that mine and probably also yours) and if we add the features or help him effectively use what's there everyone will benefit. > Maybe not for the latest GPUs but I'm sure a lot people would be happy > if they could use not-so-new NVidia hardware on FreeBSD/amd64. I built > and AMD64 box from scratch with the sole purpose of running > FreeBSD/amd64 on it. When it came time to choose the gfx card the choice > was obvious: Ati Radeon 9250. > > I know that a lot of FreeBSDers are more than happy to have proprietary > drivers which I personlly won't touch with the proverbial 10 foot > pole :) > > So please, do tell, is there any _real_ problem with releasing a > register spec doc for last year's hardware so amd64 users can hope to > have more than a framebuffer some day? How about the proprietary > nforce4 chipset? They well may have reasons not to disclose everything. There is probably lot of their market success hidden in the full specs. I bet that Mr. Zanders can't answer the question (and definitely can't decide to give the specs) anyway. And - again - it will probably take a couple of very skilled programmers' years' time to write good driver from scratch. > > Cheers. From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 2 22:47:37 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 88B3C16A494 for ; Sun, 2 Jul 2006 22:47:37 +0000 (UTC) (envelope-from S@mSmith.net) Received: from sebastian.foriru.co.uk (router.foriru.co.uk [82.152.78.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id E34F94451E for ; Sun, 2 Jul 2006 22:47:36 +0000 (GMT) (envelope-from S@mSmith.net) Received: from sebastian.foriru.co.uk (localhost [127.0.0.1]) by sebastian.foriru.co.uk (8.13.6/8.12.6) with ESMTP id k62MlYQn030602 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Sun, 2 Jul 2006 23:47:34 +0100 (BST) Received: from localhost (sams@localhost) by sebastian.foriru.co.uk (8.13.6/8.12.6/Submit) with ESMTP id k62MlS7L018104; Sun, 2 Jul 2006 23:47:28 +0100 (BST) X-Authentication-Warning: sebastian.foriru.co.uk: sams owned process doing -bs Date: Sun, 2 Jul 2006 23:47:28 +0100 (BST) From: Sam Smith X-X-Sender: sams@sebastian.foriru.co.uk To: Michal Mertl In-Reply-To: <1151877095.1085.19.camel@genius.i.cz> Message-ID: References: <20060629111231.GA692@wolf.nvidia.com> <20060702114950.bf39e312.mmendez@energyhq.be> <1151877095.1085.19.camel@genius.i.cz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Sun, 02 Jul 2006 23:10:51 +0000 Cc: freebsd-hackers@freebsd.org, Christian Zander Subject: Re: NVIDIA FreeBSD kernel feature requests 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, 02 Jul 2006 22:47:37 -0000 On Sun, 2 Jul 2006, Michal Mertl wrote: > And - again - it will probably take a couple of very skilled > programmers' years' time to write good driver from scratch. It took someone far less than that http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/if_nfe.c http://www.openbsd.org/cgi-bin/man.cgi?query=nfe&sektion=4 Nvidia don't want to give out docs. That's their commercial decision - as a result, if you their cards, you may end up with a particularly expensive paperweight the day they decide you need to buy a new card for your new version of freebsd which has different internals; or someone finds bugs in their drivers that they wont fix. it's not like there aren't plenty of other vendors who are more willing to help the developers with documentation in an open manner. Regards Sam -- Procrastination: Hard work often pays off after time. Laziness pays off now From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 3 01:40:44 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEC4F16A56E for ; Mon, 3 Jul 2006 01:40:44 +0000 (UTC) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6194E44458 for ; Mon, 3 Jul 2006 01:22:47 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [192.168.2.4]) ([10.251.60.69]) by a50.ironport.com with ESMTP; 02 Jul 2006 18:22:47 -0700 Message-ID: <44A87163.1020203@elischer.org> Date: Sun, 02 Jul 2006 18:22:43 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ian Dowse References: <200607021305.aa75873@nowhere.iedowse.com> In-Reply-To: <200607021305.aa75873@nowhere.iedowse.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: David Malone , freebsd-hackers@freebsd.org, Hans Petter Selasky Subject: Re: contiguous memory allocation problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2006 01:40:45 -0000 Ian Dowse wrote: >In message <200607021138.11945.hselasky@c2i.net>, Hans Petter Selasky writes: > > >>But there is one problem, that has been overlooked, and that is High speed >>isochronous transfers, which are not supported by the existing USB system. I >>don't think that the EHCI specification was designed for scatter and gather, >>when you consider this: >> >>8 transfers of 0xC00 bytes has to fit on 7 pages. If this is going to work, >>and I am right, one page has to contain two transfers. (see page 43 of >>ehci-r10.pdf) >> >> > >I haven't looked into the details, but the text in section 3.3.3 >seems to suggest that EHCI is designed to not require physically >contiguous allocations here either, so the same approach of using >bus_dmamap_load() should work: > > This data structure requires the associated data buffer to be > contiguous (relative to virtual memory), but allows the physical > memory pages to be non-contiguous. Seven page pointers are provided > to support the expression of 8 isochronous transfers. The seven > pointers allow for 3 (transactions) * 1024 (maximum packet size) > * 8 (transaction records) (24576 bytes) to be moved with this > data structure, regardless of the alignment offset of the first > page. > > yes, as long as the beffers are contiguous in some virtual space then the maximum number of pages they can need is 7. (they actually fit into 6 but they may start part way through the first page and may therefore overflow into a 7th). >Ian >_______________________________________________ >freebsd-hackers@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 3 03:37:13 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0742D16A49E for ; Mon, 3 Jul 2006 03:37:13 +0000 (UTC) (envelope-from joseph.koshy@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB18B43F4C for ; Mon, 3 Jul 2006 03:12:43 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by ug-out-1314.google.com with SMTP id e2so813872ugf for ; Sun, 02 Jul 2006 20:12:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=LYqz9wnz/JZhYbeBjSGf/+/N/vVX5UcUQ7zTmcf4TWsPHd4T//yECXQPyj4Uxlqq5zSPLIbl47kXRJpYEKETJ3edso7RwIeNw8VhjuLvzWfLt2g44kn/Qq9jyMKnN3pn8ZZJHRWpcu3KclRiteajm4Xxd9C9v0h0+kWX6xdyMnE= Received: by 10.78.97.7 with SMTP id u7mr722097hub; Sun, 02 Jul 2006 20:12:42 -0700 (PDT) Received: by 10.78.50.15 with HTTP; Sun, 2 Jul 2006 20:12:42 -0700 (PDT) Message-ID: <84dead720607022012g7a49ff81k3fa510c20737b6be@mail.gmail.com> Date: Mon, 3 Jul 2006 08:42:42 +0530 From: "Joseph Koshy" To: "Sam Smith" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060629111231.GA692@wolf.nvidia.com> <20060702114950.bf39e312.mmendez@energyhq.be> <1151877095.1085.19.camel@genius.i.cz> Cc: freebsd-hackers@freebsd.org, Michal Mertl , Christian Zander Subject: Re: NVIDIA FreeBSD kernel feature requests 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, 03 Jul 2006 03:37:13 -0000 > That's their commercial decision - as a result, if you > their cards, you may end up with a particularly expensive > paperweight the day they decide you need to buy a new card > for your new version of freebsd which has different > internals; or someone finds bugs in their drivers that > they wont fix. This is the relatively benign scenario. In the less benign one that "convenient" binary driver that you loaded into the kernel would contain a silent security vulnerability. Google for "Sony DRM rootkit". > it's not like there aren't plenty of other > vendors who are more willing to help the developers with > documentation in an open manner. True. -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 3 03:44:45 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 80DA916A403 for ; Mon, 3 Jul 2006 03:44:45 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 076E843D46 for ; Mon, 3 Jul 2006 03:44:44 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [IPv6:::1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k633gwRQ037374; Sun, 2 Jul 2006 21:42:58 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 02 Jul 2006 21:43:02 -0600 (MDT) Message-Id: <20060702.214302.-1622603270.imp@bsdimp.com> To: kmacy@fsmware.com From: "M. Warner Losh" In-Reply-To: References: <20060629111231.GA692@wolf.nvidia.com> <44A3FD87.8000006@pbxpress.com> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: NVIDIA FreeBSD kernel feature requests 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, 03 Jul 2006 03:44:45 -0000 In message: "Kip Macy" writes: : IIRC lack of per instance cdevs also limits Freebsd to one vmware instance. Can you describe the proper semantics here? A cdev is a cdev, and when we do things like dup we just copy the reference to that cdev. This has also traditionally been resisted on layering violations grounds (since the data we have doesn't map easily back to the fd at the time we call the cdev methods). Warner : On 6/29/06, Oleksandr Tymoshenko wrote: : > Christian Zander wrote: : > > Hi all, : > > # Task: implement mechanism to allow character drivers to : > > maintain per-open instance data (e.g. like the Linux : > > kernel's 'struct file *'). : > > Motivation: allows per thread NVIDIA notification delivery; also : > > reduces CPU overhead for notification delivery : > > from the NVIDIA kernel module to the X driver and to : > > OpenGL. : > > Priority: should translate to improved X/OpenGL performance. : > > Status: has not been started. : > I've stumbled across this issue a while ago. Actually it can : > be partially solved using EVENTHANDLER_REGISTER of dev_clone event with : > keeping state structure in si_drv1 or si_drv2 fields. I'm not sure it's : > the best solution but it works for me though it smells like hack, and : > looks like hack :) Anyway, having legitimate per-open instance data : > structures of cdevs is a great assistance in porting linux drivers to : > FreeBSD. Just my $0.02. : > : > -- : > Sincerely, : > : > Oleksandr Tymoshenko : > PBXpress Communications, Inc. : > http://www.pbxpress.com : > Tel./Fax.: +1 866 SIP PBX1 Ext. 656 : > _______________________________________________ : > freebsd-hackers@freebsd.org mailing list : > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers : > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" : > : _______________________________________________ : freebsd-hackers@freebsd.org mailing list : http://lists.freebsd.org/mailman/listinfo/freebsd-hackers : To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" : From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 3 04:02:45 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.ORG Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0416116A403 for ; Mon, 3 Jul 2006 04:02:45 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BC2443D49 for ; Mon, 3 Jul 2006 04:02:44 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [IPv6:::1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k6342Emu037541; Sun, 2 Jul 2006 22:02:14 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 02 Jul 2006 22:02:17 -0600 (MDT) Message-Id: <20060702.220217.2073896080.imp@bsdimp.com> To: czander@nvidia.com From: "M. Warner Losh" In-Reply-To: <20060629111231.GA692@wolf.nvidia.com> References: <20060629111231.GA692@wolf.nvidia.com> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: NVIDIA FreeBSD kernel feature requests 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, 03 Jul 2006 04:02:45 -0000 In message: <20060629111231.GA692@wolf.nvidia.com> Christian Zander writes: : This summary makes an attempt to describe the kernel interfaces needed by : the NVIDIA FreeBSD i386 graphics driver to achieve feature parity with : the Linux/Solaris graphics drivers, and/or required to make support for : the FreeBSD amd64 platform feasible. It also describes some of the : technical difficulties encountered by NVIDIA during the FreeBSD i386 : graphics driver's development, how these problems have been worked around : and what could be done to solve them better. Thank you for taking the time to let us know how we might make the system better. : The NVIDIA graphics driver needs to be able to create uncached kernel : and user mappings of I/O memory, such as NVIDIA GPU registers. The : FreeBSD kernel does not currently provide the interfaces necessary to : specify the memory type when creating such mappings, which makes it : difficult for the NVIDIA graphics driver to guarantee that the correct : memory type is selected. Is this via the bus_alloc_resource interface? Is uncached kernel memory different than non-prefetchable memory? If so, please specify how it is different. If not, then we have an interface that will do what you want, except it is only implemented for cardbus and would need to be implemented for pci pci and pci host bridges. Would having better functionality here help? I noticed it wasn't on the task list... Warner From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 3 09:33:30 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A571C16A40F for ; Mon, 3 Jul 2006 09:33:30 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4660E43D46 for ; Mon, 3 Jul 2006 09:33:30 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id CD8E046C28; Mon, 3 Jul 2006 05:33:29 -0400 (EDT) Date: Mon, 3 Jul 2006 10:33:29 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "M. Warner Losh" In-Reply-To: <20060702.214302.-1622603270.imp@bsdimp.com> Message-ID: <20060703103108.D26325@fledge.watson.org> References: <20060629111231.GA692@wolf.nvidia.com> <44A3FD87.8000006@pbxpress.com> <20060702.214302.-1622603270.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, kmacy@fsmware.com Subject: Re: NVIDIA FreeBSD kernel feature requests 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, 03 Jul 2006 09:33:30 -0000 On Sun, 2 Jul 2006, M. Warner Losh wrote: > In message: > "Kip Macy" writes: > : IIRC lack of per instance cdevs also limits Freebsd to one vmware instance. > > Can you describe the proper semantics here? A cdev is a cdev, and when we > do things like dup we just copy the reference to that cdev. This has also > traditionally been resisted on layering violations grounds (since the data > we have doesn't map easily back to the fd at the time we call the cdev > methods). In the past, I've done some experimental implementation allowing devfs providers to provide session cookies for the file descriptor. This is fairly contrary to our VFS design, and our notions of "open" are a bit hazy -- for example, there are a number of situations in which I/O occurs on vnodes without the vnode being open. The devfs cloning model does offer significant simplications in many cases, and certainly fits our VFS model a bit more happily. It also exists today. It may be that our VMware kernel module doesn't know about it yet, however. Robert N M Watson Computer Laboratory University of Cambridge > > Warner > > : On 6/29/06, Oleksandr Tymoshenko wrote: > : > Christian Zander wrote: > : > > Hi all, > : > > # Task: implement mechanism to allow character drivers to > : > > maintain per-open instance data (e.g. like the Linux > : > > kernel's 'struct file *'). > : > > Motivation: allows per thread NVIDIA notification delivery; also > : > > reduces CPU overhead for notification delivery > : > > from the NVIDIA kernel module to the X driver and to > : > > OpenGL. > : > > Priority: should translate to improved X/OpenGL performance. > : > > Status: has not been started. > : > I've stumbled across this issue a while ago. Actually it can > : > be partially solved using EVENTHANDLER_REGISTER of dev_clone event with > : > keeping state structure in si_drv1 or si_drv2 fields. I'm not sure it's > : > the best solution but it works for me though it smells like hack, and > : > looks like hack :) Anyway, having legitimate per-open instance data > : > structures of cdevs is a great assistance in porting linux drivers to > : > FreeBSD. Just my $0.02. > : > > : > -- > : > Sincerely, > : > > : > Oleksandr Tymoshenko > : > PBXpress Communications, Inc. > : > http://www.pbxpress.com > : > Tel./Fax.: +1 866 SIP PBX1 Ext. 656 > : > _______________________________________________ > : > freebsd-hackers@freebsd.org mailing list > : > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > : > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > : > > : _______________________________________________ > : freebsd-hackers@freebsd.org mailing list > : http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > : To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > : > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 3 09:40:16 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B151F16A412 for ; Mon, 3 Jul 2006 09:40:16 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1404243D48 for ; Mon, 3 Jul 2006 09:40:16 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 4C60E46B28; Mon, 3 Jul 2006 05:40:15 -0400 (EDT) Date: Mon, 3 Jul 2006 10:40:15 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Sam Smith In-Reply-To: Message-ID: <20060703103420.B26325@fledge.watson.org> References: <20060629111231.GA692@wolf.nvidia.com> <20060702114950.bf39e312.mmendez@energyhq.be> <1151877095.1085.19.camel@genius.i.cz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, Michal Mertl , Christian Zander Subject: Re: NVIDIA FreeBSD kernel feature requests 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, 03 Jul 2006 09:40:16 -0000 On Sun, 2 Jul 2006, Sam Smith wrote: > On Sun, 2 Jul 2006, Michal Mertl wrote: >> And - again - it will probably take a couple of very skilled >> programmers' years' time to write good driver from scratch. > > It took someone far less than that > http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/if_nfe.c > http://www.openbsd.org/cgi-bin/man.cgi?query=nfe&sektion=4 > > Nvidia don't want to give out docs. > > That's their commercial decision - as a result, if you their cards, you may > end up with a particularly expensive paperweight the day they decide you > need to buy a new card for your new version of freebsd which has different > internals; or someone finds bugs in their drivers that they wont fix. it's > not like there aren't plenty of other vendors who are more willing to help > the developers with documentation in an open manner. As I've also pointed out privately, but figure the list might benefit from -- this is a discussion of NVIDIA's video hardware, not network hardware, and the differences are significant: Producing a device driver for a network interface is a pretty casual activity, since network interfaces are often just glorified hardware fifos, and there is relatively little that distinguishes most low-end cards on the market. Producing a driver for a GPU card, especially one that possibly converts from GL-foo to foo appropriate to program and feed an ASIC on a video card, is quite different matter entirely. I'm all for open source drivers, and would also encourage NVIDIA to continue to reconsider their closed source driver approach where it makes sense (especially for the network interfaces). However, I think that we shouldn't conflate these two cases rhetorically, as there are orders of magnitude complexity (and intellectual property) differences. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 3 10:32:12 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A9B916A403 for ; Mon, 3 Jul 2006 10:32:12 +0000 (UTC) (envelope-from clsung@FreeBSD.csie.nctu.edu.tw) Received: from FreeBSD.csie.nctu.edu.tw (freebsd.csie.nctu.edu.tw [140.113.17.209]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57B1844A09 for ; Mon, 3 Jul 2006 10:32:04 +0000 (GMT) (envelope-from clsung@FreeBSD.csie.nctu.edu.tw) Received: from localhost (localhost.csie.nctu.edu.tw [127.0.0.1]) by FreeBSD.csie.nctu.edu.tw (Postfix) with ESMTP id D98BD7E921 for ; Mon, 3 Jul 2006 18:33:39 +0800 (CST) Received: from FreeBSD.csie.nctu.edu.tw ([127.0.0.1]) by localhost (FreeBSD.csie.nctu.edu.tw [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMjQtcLcQ+Xl for ; Mon, 3 Jul 2006 18:33:38 +0800 (CST) Received: by FreeBSD.csie.nctu.edu.tw (Postfix, from userid 1038) id B1BAE7E9B5; Mon, 3 Jul 2006 18:33:38 +0800 (CST) Date: Mon, 3 Jul 2006 18:33:38 +0800 From: Cheng-Lung Sung To: freebsd-hackers@freebsd.org Message-ID: <20060703103338.GA31839@FreeBSD.csie.nctu.edu.tw> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IS0zKkzwUGydFO0o" Content-Disposition: inline X-Fingerprint: E0BC 57F9 F44B 46C6 DB53 8462 F807 89F3 956E 8BC1 X-Public-Key: http://sungsung.dragon2.net/pubring.asc User-Agent: Mutt/1.5.11 Subject: [patch] display jail id in /usr/bin/top 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, 03 Jul 2006 10:32:12 -0000 --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=big5 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi,=20 The attached patch provide top(1) the ability to display=20 jail id.=20 Usage: % top -j=20 or in=20 interactive mode, toggle with 'j'. Suggestions are needed. diff -ruN /usr/src/usr.bin/top/machine.c.orig usr.bin/top/machine.c --- /usr/src/usr.bin/top/machine.c Wed May 18 21:42:51 2005 +++ usr.bin/top/machine.c Sun Jun 4 22:13:00 2006 @@ -99,26 +99,26 @@ */ =20 static char io_header[] =3D - " PID %-*.*s VCSW IVCSW READ WRITE FAULT TOTAL PERCENT COMMAND"; + " PID%s %-*.*s VCSW IVCSW READ WRITE FAULT TOTAL PERCENT COMMAND= "; =20 #define io_Proc_format \ - "%5d %-*.*s %6ld %6ld %6ld %6ld %6ld %6ld %6.2f%% %.*s" + "%5d%s %-*.*s %6ld %6ld %6ld %6ld %6ld %6ld %6.2f%% %.*s" =20 static char smp_header_thr[] =3D - " PID %-*.*s THR PRI NICE SIZE RES STATE C TIME %6s COMMAND"; + " PID%s %-*.*s THR PRI NICE SIZE RES STATE C TIME %6s COMMAND"; static char smp_header[] =3D - " PID %-*.*s " "PRI NICE SIZE RES STATE C TIME %6s COMMAND"; + " PID%s %-*.*s " "PRI NICE SIZE RES STATE C TIME %6s COMMAND"; =20 #define smp_Proc_format \ - "%5d %-*.*s %s%3d %4d%7s %6s %-6.6s %1x%7s %5.2f%% %.*s" + "%5d%s %-*.*s %s%3d %4d%7s %6s %-6.6s %1x%7s %5.2f%% %.*s" =20 static char up_header_thr[] =3D - " PID %-*.*s THR PRI NICE SIZE RES STATE TIME %6s COMMAND"; + " PID%s %-*.*s THR PRI NICE SIZE RES STATE TIME %6s COMMAND"; static char up_header[] =3D - " PID %-*.*s " "PRI NICE SIZE RES STATE TIME %6s COMMAND"; + " PID%s %-*.*s " "PRI NICE SIZE RES STATE TIME %6s COMMAND"; =20 #define up_Proc_format \ - "%5d %-*.*s %s%3d %4d%7s %6s %-6.6s%.0d%7s %5.2f%% %.*s" + "%5d%s %-*.*s %s%3d %4d%7s %6s %-6.6s%.0d%7s %5.2f%% %.*s" =20 =20 /* process state names for the "STATE" column of the display */ @@ -218,7 +218,8 @@ */ char *ordernames[] =3D { "cpu", "size", "res", "time", "pri", "threads", - "total", "read", "write", "fault", "vcsw", "ivcsw", NULL + "total", "read", "write", "fault", "vcsw", "ivcsw",=20 + "jid", NULL }; #endif =20 @@ -299,12 +300,14 @@ (ps.thread ? smp_header : smp_header_thr) : (ps.thread ? up_header : up_header_thr); snprintf(Header, sizeof(Header), prehead, + ps.jail ? " JID" : "", namelength, namelength, uname_field, ps.wcpu ? "WCPU" : "CPU"); break; case DISP_IO: prehead =3D io_header; snprintf(Header, sizeof(Header), prehead, + ps.jail ? " JID" : "", namelength, namelength, uname_field); break; } @@ -657,7 +660,7 @@ int state; struct rusage ru, *rup; long p_tot, s_tot; - char *proc_fmt, thr_buf[6]; + char *proc_fmt, thr_buf[6], jid_buf[6]; =20 /* find and remember the next proc structure */ hp =3D (struct handle *)handle; @@ -718,6 +721,12 @@ break; } =20 + if (ps.jail =3D=3D 0) + jid_buf[0] =3D '\0'; + else + snprintf(jid_buf, sizeof(jid_buf), " %*d", + sizeof(jid_buf) - 3, pp->ki_jid); + if (displaymode =3D=3D DISP_IO) { oldp =3D get_old_proc(pp); if (oldp !=3D NULL) { @@ -735,6 +744,7 @@ =20 sprintf(fmt, io_Proc_format, pp->ki_pid, + jid_buf, namelength, namelength, (*get_userid)(pp->ki_ruid), rup->ru_nvcsw, @@ -760,6 +770,7 @@ =20 sprintf(fmt, proc_fmt, pp->ki_pid, + jid_buf, namelength, namelength, (*get_userid)(pp->ki_ruid), thr_buf, @@ -891,6 +902,12 @@ return (diff > 0 ? 1 : -1); \ } while (0) =20 +#define ORDERKEY_JID(a, b) do { \ + int diff =3D (int)(b)->ki_jid - (int)(a)->ki_jid; \ + if (diff !=3D 0) \ + return (diff > 0 ? 1 : -1); \ +} while (0) + /* compare_cpu - the comparison function for sorting by cpu percentage */ =20 int @@ -918,6 +935,8 @@ int compare_size(), compare_res(), compare_time(), compare_prio(), compare= _threads(); /* io compare routines */ int compare_iototal(), compare_ioread(), compare_iowrite(), compare_iofaul= t(), compare_vcsw(), compare_ivcsw(); +/* jail id compare routine */ +int compare_jid(); =20 int (*compares[])() =3D { compare_cpu, @@ -932,6 +951,7 @@ compare_iofault, compare_vcsw, compare_ivcsw, + compare_jid, NULL }; =20 @@ -1015,6 +1035,24 @@ struct kinfo_proc *p2 =3D *(struct kinfo_proc **)arg2; =20 ORDERKEY_THREADS(p1, p2); + ORDERKEY_PCTCPU(p1, p2); + ORDERKEY_CPTICKS(p1, p2); + ORDERKEY_STATE(p1, p2); + ORDERKEY_PRIO(p1, p2); + ORDERKEY_RSSIZE(p1, p2); + ORDERKEY_MEM(p1, p2); + + return (0); +} + +/* compare_jid - the comparison function for sorting by jid */ +int +compare_jid(void *arg1, void *arg2) +{ + struct kinfo_proc *p1 =3D *(struct kinfo_proc **)arg1; + struct kinfo_proc *p2 =3D *(struct kinfo_proc **)arg2; + + ORDERKEY_JID(p1, p2); ORDERKEY_PCTCPU(p1, p2); ORDERKEY_CPTICKS(p1, p2); ORDERKEY_STATE(p1, p2); diff -ruN /usr/src/contrib/top/machine.h.orig contrib/top/machine.h --- /usr/src/contrib/top/machine.h.orig Wed May 18 21:30:08 2005 +++ contrib/top/machine.h Sat Jun 3 12:25:15 2006 @@ -62,6 +62,7 @@ int thread; /* show threads */ int uid; /* only this uid (unless uid =3D=3D -1) */ int wcpu; /* show weighted cpu */ + int jail; /* show jail id */ char *command; /* only this command (unless =3D=3D NULL) */ }; =20 diff -ruN /usr/src/contrib/top/top.c.orig contrib/top/top.c --- /usr/src/contrib/top/top.c.orig Sun Apr 30 14:06:33 2006 +++ contrib/top/top.c Sat Jun 3 12:38:45 2006 @@ -193,9 +193,9 @@ fd_set readfds; =20 #ifdef ORDER - static char command_chars[] =3D "\f qh?en#sdkriIutHmSCo"; + static char command_chars[] =3D "\f qh?en#sdkriIutHmSCoj"; #else - static char command_chars[] =3D "\f qh?en#sdkriIutHmSC"; + static char command_chars[] =3D "\f qh?en#sdkriIutHmSCj"; #endif /* these defines enumerate the "strchr"s of the commands in command_chars = */ #define CMD_redraw 0 @@ -222,6 +222,7 @@ #ifdef ORDER #define CMD_order 20 #endif +#define CMD_jidtog 21 =20 /* set the buffer for stdout */ #ifdef DEBUG @@ -252,6 +253,7 @@ ps.uid =3D -1; ps.thread =3D No; ps.wcpu =3D 1; + ps.jail =3D No; ps.command =3D NULL; =20 /* get preset options from the environment */ @@ -277,7 +279,7 @@ optind =3D 1; } =20 - while ((i =3D getopt(ac, av, "CSIHbinquvs:d:U:m:o:t")) !=3D EOF) + while ((i =3D getopt(ac, av, "CSIHbijnquvs:d:U:m:o:t")) !=3D EOF) { switch(i) { @@ -394,6 +396,10 @@ ps.thread =3D !ps.thread; break; =20 + case 'j': + ps.jail =3D !ps.jail; + break; + default: fprintf(stderr, "Top version %s\n" @@ -1044,6 +1050,15 @@ } break; #endif + case CMD_jidtog: + ps.jail =3D !ps.jail; + new_message(MT_standout | MT_delayed, + " %sisplaying jail id.", + ps.jail ? "D" : "Not d"); + header_text =3D format_header(uname_field); + reset_display(); + putchar('\r'); + break; =20 default: new_message(MT_standout, " BAD CASE IN SWITCH!"); diff -ruN /usr/src/contrib/top/top.X.orig contrib/top/top.X --- /usr/src/contrib/top/top.X.orig Wed Jun 28 08:57:54 2006 +++ contrib/top/top.X Fri Jun 30 13:15:10 2006 @@ -96,6 +96,11 @@ Do not display idle processes. By default, top displays both active and idle processes. .TP +.B \-j +Display the +.IR jail (8) +id. +.TP .B \-t Do not display the .I top @@ -170,7 +175,8 @@ The default for .I count on an intelligent terminal is, in fact, -.BI infinity . +.BI infinity +. .PP The environment variable .B TOP @@ -221,7 +227,8 @@ .TP .B q Quit -.IR top. +.IR top +. .TP .B d Change the number of displays to show (prompt for new number). @@ -277,6 +284,11 @@ .BR I ) Toggle the display of idle processes. .TP +.B j +Toggle the display of +.IR jail (8) +id. +.TP .B t Toggle the display of the .I top @@ -302,8 +314,11 @@ The remainder of the screen displays information about individual processes. This display is similar in spirit to .IR ps (1) -but it is not exactly the same. PID is the process id, USERNAME is the na= me -of the process's owner (if +but it is not exactly the same. PID is the process id,=20 +JID, when displayed, is the=20 +.IR jail (8) +ID corresponding to the process, +USERNAME is the name of the process's owner (if .B \-u is specified, a UID column will be substituted for USERNAME), PRI is the current priority of the process, --=20 Cheng-Lung Sung - clsung@ --IS0zKkzwUGydFO0o Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEqPKB+AeJ85Vui8ERAla1AJ0eCcBU7jJ7savEMl5qKcqSHtxIBwCgg6o3 2aS1ssGAbLN0MdGJYi0+kjQ= =VyQS -----END PGP SIGNATURE----- --IS0zKkzwUGydFO0o-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 3 12:02:33 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.ORG Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E7F4116A47E for ; Mon, 3 Jul 2006 12:02:32 +0000 (UTC) (envelope-from CZander@nvidia.com) Received: from HQEMGATE01.nvidia.com (hqemgate01.nvidia.com [216.228.112.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id D6A9D43D46 for ; Mon, 3 Jul 2006 12:02:26 +0000 (GMT) (envelope-from CZander@nvidia.com) Received: from hqemfe02.nvidia.com (Not Verified[172.16.227.92]) by HQEMGATE01.nvidia.com id ; Mon, 03 Jul 2006 05:03:43 -0700 Received: from nvidia.com ([172.16.228.84]) by hqemfe02.nvidia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Jul 2006 05:02:03 -0700 Date: Mon, 3 Jul 2006 14:02:36 +0200 From: Christian Zander To: "M. Warner Losh" Message-ID: <20060703120236.GS692@wolf.nvidia.com> References: <20060629111231.GA692@wolf.nvidia.com> <20060702.220217.2073896080.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060702.220217.2073896080.imp@bsdimp.com> User-Agent: Mutt/1.4.2.1i X-NVConfidentiality: public X-OriginalArrivalTime: 03 Jul 2006 12:02:04.0038 (UTC) FILETIME=[7FA51260:01C69E98] Cc: freebsd-hackers@FreeBSD.ORG, czander@nvidia.com Subject: Re: NVIDIA FreeBSD kernel feature requests X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christian Zander List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2006 12:02:33 -0000 On Sun, Jul 02, 2006 at 10:02:17PM -0600, M. Warner Losh wrote: > In message: <20060629111231.GA692@wolf.nvidia.com> > Christian Zander writes: > : This summary makes an attempt to describe the kernel interfaces needed by > : the NVIDIA FreeBSD i386 graphics driver to achieve feature parity with > : the Linux/Solaris graphics drivers, and/or required to make support for > : the FreeBSD amd64 platform feasible. It also describes some of the > : technical difficulties encountered by NVIDIA during the FreeBSD i386 > : graphics driver's development, how these problems have been worked around > : and what could be done to solve them better. > > Thank you for taking the time to let us know how we might make the > system better. > > : The NVIDIA graphics driver needs to be able to create uncached kernel > : and user mappings of I/O memory, such as NVIDIA GPU registers. The > : FreeBSD kernel does not currently provide the interfaces necessary to > : specify the memory type when creating such mappings, which makes it > : difficult for the NVIDIA graphics driver to guarantee that the correct > : memory type is selected. > > Is this via the bus_alloc_resource interface? Is uncached kernel > memory different than non-prefetchable memory? If so, please specify > how it is different. If not, then we have an interface that will do > what you want, except it is only implemented for cardbus and would > need to be implemented for pci pci and pci host bridges. Would having > better functionality here help? I noticed it wasn't on the task list... > The I/O memory in question is non-prefetchable. The NVIDIA FreeBSD graphics driver currently uses the bus_alloc_resource() interface without the RF_ACTIVE flag and then uses pmap_mapdev() to obtain kernel mappings of the I/O memory, which it then updates with the PCD/PWT flags to force them to be uncached. User mappings are created via mmap(); they use the effective memory type derived from the MTRR configuration. If you're interested in taking a look, the FreeBSD kernel specific interface code is included with the NVIDIA graphics driver. John is working on pmap_mapdev_attr(), which is built on top of the PAT support he is adding, and this interface will allow the caller to request a specific memory type to use for the mapping, handling the details transparently (e.g. the direct mapping on FreeBSD amd64). It would probably be useful if the bus_alloc_resource() interface supported this functionality, but the NVIDIA graphics driver would still need to use the pmap_mapdev_attr() interface, e.g. for its AGP GART driver. The current plan is to replace pmap_mapdev() with pmap_mapdev_attr() in the driver when the latter interface becomes available. Thanks, > Warner -- christian zander ch?zander@nvidia.com From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 3 12:02:33 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9031916A492; Mon, 3 Jul 2006 12:02:33 +0000 (UTC) (envelope-from CZander@nvidia.com) Received: from HQEMGATE01.nvidia.com (hqemgate01.nvidia.com [216.228.112.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id D6C4143D53; Mon, 3 Jul 2006 12:02:26 +0000 (GMT) (envelope-from CZander@nvidia.com) Received: from hqemfe03.nvidia.com (Not Verified[172.16.227.123]) by HQEMGATE01.nvidia.com id ; Mon, 03 Jul 2006 05:03:43 -0700 Received: from nvidia.com ([172.16.228.84]) by hqemfe03.nvidia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Jul 2006 05:02:08 -0700 Date: Mon, 3 Jul 2006 14:02:41 +0200 From: Christian Zander To: Robert Watson Message-ID: <20060703120241.GT692@wolf.nvidia.com> References: <20060629111231.GA692@wolf.nvidia.com> <44A3FD87.8000006@pbxpress.com> <20060702.214302.-1622603270.imp@bsdimp.com> <20060703103108.D26325@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060703103108.D26325@fledge.watson.org> User-Agent: Mutt/1.4.2.1i X-NVConfidentiality: public X-OriginalArrivalTime: 03 Jul 2006 12:02:08.0631 (UTC) FILETIME=[8261E870:01C69E98] Cc: freebsd-hackers@freebsd.org, kmacy@fsmware.com Subject: Re: NVIDIA FreeBSD kernel feature requests X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christian Zander List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2006 12:02:33 -0000 On Mon, Jul 03, 2006 at 10:33:29AM +0100, Robert Watson wrote: > > On Sun, 2 Jul 2006, M. Warner Losh wrote: > > >In message: > > "Kip Macy" writes: > >: IIRC lack of per instance cdevs also limits Freebsd to one vmware > >instance. > > > >Can you describe the proper semantics here? A cdev is a cdev, and when we > >do things like dup we just copy the reference to that cdev. This has also > >traditionally been resisted on layering violations grounds (since the data > >we have doesn't map easily back to the fd at the time we call the cdev > >methods). > > In the past, I've done some experimental implementation allowing devfs > providers to provide session cookies for the file descriptor. This is > fairly contrary to our VFS design, and our notions of "open" are a bit hazy > -- for example, there are a number of situations in which I/O occurs on > vnodes without the vnode being open. The devfs cloning model does offer > significant simplications in many cases, and certainly fits our VFS model a > bit more happily. It also exists today. It may be that our VMware kernel > module doesn't know about it yet, however. > I've made a first pass at implementing support for the device cloning mechanism in the NVIDIA FreeBSD graphics driver and it seems to work well with the driver's notification mechanism on FreeBSD 5.3. I'll need to do more testing and check what implications the mechanism has (locking, etc.), but it looks like it's a good match. Thanks, > Robert N M Watson > Computer Laboratory > University of Cambridge > > > > >Warner > > > >: On 6/29/06, Oleksandr Tymoshenko wrote: > >: > Christian Zander wrote: > >: > > Hi all, > >: > > # Task: implement mechanism to allow character drivers to > >: > > maintain per-open instance data (e.g. like the Linux > >: > > kernel's 'struct file *'). > >: > > Motivation: allows per thread NVIDIA notification delivery; also > >: > > reduces CPU overhead for notification delivery > >: > > from the NVIDIA kernel module to the X driver and to > >: > > OpenGL. > >: > > Priority: should translate to improved X/OpenGL performance. > >: > > Status: has not been started. > >: > I've stumbled across this issue a while ago. Actually it can > >: > be partially solved using EVENTHANDLER_REGISTER of dev_clone event with > >: > keeping state structure in si_drv1 or si_drv2 fields. I'm not sure it's > >: > the best solution but it works for me though it smells like hack, and > >: > looks like hack :) Anyway, having legitimate per-open instance data > >: > structures of cdevs is a great assistance in porting linux drivers to > >: > FreeBSD. Just my $0.02. > >: > > >: > -- > >: > Sincerely, > >: > > >: > Oleksandr Tymoshenko > >: > PBXpress Communications, Inc. > >: > http://www.pbxpress.com > >: > Tel./Fax.: +1 866 SIP PBX1 Ext. 656 > >: > _______________________________________________ > >: > freebsd-hackers@freebsd.org mailing list > >: > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > >: > To unsubscribe, send any mail to > >"freebsd-hackers-unsubscribe@freebsd.org" > >: > > >: _______________________________________________ > >: freebsd-hackers@freebsd.org mailing list > >: http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > >: To unsubscribe, send any mail to > >"freebsd-hackers-unsubscribe@freebsd.org" > >: > >_______________________________________________ > >freebsd-hackers@freebsd.org mailing list > >http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > >To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- christian zander ch?zander@nvidia.com From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 3 17:31:47 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C7F016A523 for ; Mon, 3 Jul 2006 17:31:47 +0000 (UTC) (envelope-from artifact.one@googlemail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id F188D4533A for ; Mon, 3 Jul 2006 17:09:28 +0000 (GMT) (envelope-from artifact.one@googlemail.com) Received: by ug-out-1314.google.com with SMTP id e2so1010336ugf for ; Mon, 03 Jul 2006 10:09:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=JiwulRWln7noCezBGtBcFGvNFDZwbp1WhASHZC5TLyE7mtFykgEb6iH7HCnIqqLgHxvnieMfHMp21xbtXycu3uL2U6Km6a++LrKsy5LHDXXqHTaOdVGAzNHiRlVMgOFMqxdadArwAgwpDqTkA3MJSwx6D8wisbxBElCtTFnqt8o= Received: by 10.78.177.11 with SMTP id z11mr998289hue; Mon, 03 Jul 2006 10:09:27 -0700 (PDT) Received: by 10.78.43.9 with HTTP; Mon, 3 Jul 2006 10:09:27 -0700 (PDT) Message-ID: <8e96a0b90607031009v4ec2630fgfc432f5dad15abda@mail.gmail.com> Date: Mon, 3 Jul 2006 18:09:27 +0100 From: "mal content" To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Stop further socket() or connect() calls. 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, 03 Jul 2006 17:31:47 -0000 Was it my imagination or did I see a function in libc that allowed a process to prevent further network access? I'm pretty sure that I read the manual page for it and now I can't find it. I was looking for a way to write a small wrapper program that disables network access and then exec()'s a given program. thanks MC From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 3 18:34:23 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F04C16A4A0 for ; Mon, 3 Jul 2006 18:34:23 +0000 (UTC) (envelope-from randyhyde@earthlink.net) Received: from smtpauth04.mail.atl.earthlink.net (smtpauth04.mail.atl.earthlink.net [209.86.89.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2C094500F for ; Mon, 3 Jul 2006 18:34:20 +0000 (GMT) (envelope-from randyhyde@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=KYTbMKEt5zdPAhMLEQKD3WLcbV+z2QG2oEbCqNzcrJMpoD+qHna7NPRThSXCWyWX; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.180.58.59] (helo=pentiv) by smtpauth04.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1FxTFU-0007Ly-7s for freebsd-hackers@freebsd.org; Mon, 03 Jul 2006 14:34:20 -0400 Message-ID: <002501c69ecf$5967c6b0$6302a8c0@pentiv> From: "Randall Hyde" To: References: <16887068.1151618963387.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> <20060630081019.GB734@turion.vk2pj.dyndns.org> Date: Mon, 3 Jul 2006 11:34:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-ELNK-Trace: eba5e0c9192a36dcd6dd28457998182d7e972de0d01da940670466a2a7ed15635ce4232287f362ac350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.180.58.59 Subject: getc in BSD (was FLEX issues) 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, 03 Jul 2006 18:34:23 -0000 Well, having a little bit of time to play around with the issues I'm having with Flex under GCC, I've determined that the problem occurs in the following code fragment: for ( n = 0; n < num_to_read && ( c = getc << X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFC8A16A407 for ; Mon, 3 Jul 2006 19:04:53 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail31.syd.optusnet.com.au (mail31.syd.optusnet.com.au [211.29.132.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB76743D53 for ; Mon, 3 Jul 2006 19:04:50 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail31.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k63J4mVp005418 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 4 Jul 2006 05:04:48 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.6/8.13.6) with ESMTP id k63J4mDT003086; Tue, 4 Jul 2006 05:04:48 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.6/8.13.6/Submit) id k63J4mq5003085; Tue, 4 Jul 2006 05:04:48 +1000 (EST) (envelope-from peter) Date: Tue, 4 Jul 2006 05:04:48 +1000 From: Peter Jeremy To: mal content Message-ID: <20060703190448.GD727@turion.vk2pj.dyndns.org> References: <8e96a0b90607031009v4ec2630fgfc432f5dad15abda@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="n2Pv11Ogg/Ox8ay5" Content-Disposition: inline In-Reply-To: <8e96a0b90607031009v4ec2630fgfc432f5dad15abda@mail.gmail.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: freebsd-hackers@freebsd.org Subject: Re: Stop further socket() or connect() calls. 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, 03 Jul 2006 19:04:54 -0000 --n2Pv11Ogg/Ox8ay5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 2006-Jul-03 18:09:27 +0100, mal content wrote: >Was it my imagination or did I see a function in libc that >allowed a process to prevent further network access? The closest is shutdown(2) which can stop further access in one direction on an existing socket - not what you want. >I was looking for a way to write a small wrapper program >that disables network access and then exec()'s a given >program. For dynamic executables, you could LD_PRELOAD a .so that replaces all the socket-related syscalls. --=20 Peter Jeremy --n2Pv11Ogg/Ox8ay5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFEqWpP/opHv/APuIcRAjHSAJ48JmftHhRx6zIVE6iRPHYNHRrRAwCeNYWJ RDdOJHrIkWfsgd84+w/ip2c= =LCqj -----END PGP SIGNATURE----- --n2Pv11Ogg/Ox8ay5-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 3 23:46:17 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1736616A4E0 for ; Mon, 3 Jul 2006 23:46:17 +0000 (UTC) (envelope-from jimmy@jamesbailie.com) Received: from smtp101.rog.mail.re2.yahoo.com (smtp101.rog.mail.re2.yahoo.com [206.190.36.79]) by mx1.FreeBSD.org (Postfix) with SMTP id 9EB6F43D78 for ; Mon, 3 Jul 2006 23:46:12 +0000 (GMT) (envelope-from jimmy@jamesbailie.com) Received: (qmail 27493 invoked from network); 3 Jul 2006 23:46:11 -0000 Received: from unknown (HELO ?70.29.126.205?) (jazzturk@rogers.com@70.29.126.205 with plain) by smtp101.rog.mail.re2.yahoo.com with SMTP; 3 Jul 2006 23:46:11 -0000 Message-ID: <44A9AC43.3090606@jamesbailie.com> Date: Mon, 03 Jul 2006 19:46:11 -0400 From: James Bailie User-Agent: Thunderbird 1.5.0.4 (X11/20060701) MIME-Version: 1.0 To: Randall Hyde References: <16887068.1151618963387.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> <20060630081019.GB734@turion.vk2pj.dyndns.org> <002501c69ecf$5967c6b0$6302a8c0@pentiv> In-Reply-To: <002501c69ecf$5967c6b0$6302a8c0@pentiv> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: getc in BSD (was FLEX issues) 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, 03 Jul 2006 23:46:17 -0000 Randall Hyde wrote: > This kind of gives me the impression that "getc" is defined a bit > differently under FreeBSD than other environments? Any ideas? Yes. It's defined as a macro. -- James Bailie http://www.jamesbailie.com From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 4 00:06:54 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB94716A4DA for ; Tue, 4 Jul 2006 00:06:54 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: from mired.org (vpn.mired.org [66.92.153.74]) by mx1.FreeBSD.org (Postfix) with SMTP id 2284943D45 for ; Tue, 4 Jul 2006 00:06:53 +0000 (GMT) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: (qmail 14212 invoked by uid 1001); 4 Jul 2006 00:06:53 -0000 Received: by bhuda.mired.org (tmda-sendmail, from uid 1001); Mon, 03 Jul 2006 20:06:53 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17577.45340.818482.432245@bhuda.mired.org> Date: Mon, 3 Jul 2006 20:06:52 -0400 To: James Bailie In-Reply-To: <44A9AC43.3090606@jamesbailie.com> References: <16887068.1151618963387.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> <20060630081019.GB734@turion.vk2pj.dyndns.org> <002501c69ecf$5967c6b0$6302a8c0@pentiv> <44A9AC43.3090606@jamesbailie.com> X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid X-Primary-Address: mwm@mired.org X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`; h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) From: Mike Meyer Cc: freebsd-hackers@freebsd.org, Randall Hyde Subject: Re: getc in BSD (was FLEX issues) 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, 04 Jul 2006 00:06:54 -0000 In <44A9AC43.3090606@jamesbailie.com>, James Bailie typed: > Randall Hyde wrote: > > This kind of gives me the impression that "getc" is defined a bit > > differently under FreeBSD than other environments? Any ideas? > Yes. It's defined as a macro. Linux says that getc "may be implemented as a macro". Anything that needs a function should be using fgetc, not getc. But http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 4 00:25:45 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ABDE816A4E5 for ; Tue, 4 Jul 2006 00:25:45 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACC6C43D46 for ; Tue, 4 Jul 2006 00:25:41 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from gothmog.pc (host5.bedc.ondsl.gr [62.103.39.229]) (authenticated bits=128) by igloo.linux.gr (8.13.7/8.13.7/Debian-1) with ESMTP id k640PMVX025998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 4 Jul 2006 03:25:24 +0300 Received: from gothmog.pc (gothmog [127.0.0.1]) by gothmog.pc (8.13.7/8.13.7) with ESMTP id k640PHnS091635; Tue, 4 Jul 2006 03:25:17 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from giorgos@localhost) by gothmog.pc (8.13.7/8.13.7/Submit) id k640PC5e091634; Tue, 4 Jul 2006 03:25:12 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Tue, 4 Jul 2006 03:25:12 +0300 From: Giorgos Keramidas To: Mike Meyer Message-ID: <20060704002512.GA91588@gothmog.pc> References: <16887068.1151618963387.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> <20060630081019.GB734@turion.vk2pj.dyndns.org> <002501c69ecf$5967c6b0$6302a8c0@pentiv> <44A9AC43.3090606@jamesbailie.com> <17577.45340.818482.432245@bhuda.mired.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <17577.45340.818482.432245@bhuda.mired.org> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (score=-3.542, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.86, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: James Bailie , freebsd-hackers@freebsd.org, Randall Hyde Subject: Re: getc in BSD (was FLEX issues) 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, 04 Jul 2006 00:25:45 -0000 On 2006-07-03 20:06, Mike Meyer wrote: > In <44A9AC43.3090606@jamesbailie.com>, James Bailie typed: > > Randall Hyde wrote: > > > This kind of gives me the impression that "getc" is defined a bit > > > differently under FreeBSD than other environments? Any ideas? > > Yes. It's defined as a macro. > > Linux says that getc "may be implemented as a macro". Anything that > needs a function should be using fgetc, not getc. But The C99 standard (actually the latest public draft[1]) allows getc() to be a macro: [1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf from http://www.open-std.org/jtc1/sc22/wg14/www/standards | §7.19.7.5 The getc function | | Synopsis | | 1 #include | int getc(FILE *stream); | | Description | | 2 The getc function is equivalent to fgetc, except that if it is | implemented as a macro, it may evaluate stream more than once, | so the argument should never be an expression with side | effects. This means one shouldn't depend on getc() being a function. From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 4 06:09:46 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5FA1416A4DE for ; Tue, 4 Jul 2006 06:09:46 +0000 (UTC) (envelope-from lists-freebsd@silverwraith.com) Received: from pear.silverwraith.com (pear.silverwraith.com [69.12.167.160]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2634743D46 for ; Tue, 4 Jul 2006 06:09:45 +0000 (GMT) (envelope-from lists-freebsd@silverwraith.com) Received: from avleen by pear.silverwraith.com with local (Exim 4.61 (FreeBSD)) (envelope-from ) id 1Fxe6T-000P7P-Cf for freebsd-hackers@freebsd.org; Mon, 03 Jul 2006 23:09:45 -0700 Date: Mon, 3 Jul 2006 23:09:45 -0700 From: Avleen Vig To: freebsd-hackers@freebsd.org Message-ID: <20060704060945.GS19592@silverwraith.com> References: <20060629111231.GA692@wolf.nvidia.com> <20060702114950.bf39e312.mmendez@energyhq.be> <1151877095.1085.19.camel@genius.i.cz> <84dead720607022012g7a49ff81k3fa510c20737b6be@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84dead720607022012g7a49ff81k3fa510c20737b6be@mail.gmail.com> User-Agent: Mutt/1.5.11 Subject: Re: NVIDIA FreeBSD kernel feature requests 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, 04 Jul 2006 06:09:46 -0000 On Mon, Jul 03, 2006 at 08:42:42AM +0530, Joseph Koshy wrote: > In the less benign one that "convenient" binary driver that > you loaded into the kernel would contain a silent security > vulnerability. Google for "Sony DRM rootkit". I think the difference here is that NVIDIA are a little more trusted than Sony ever was :-) From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 4 06:27:44 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8198216A4E7 for ; Tue, 4 Jul 2006 06:27:44 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id CEDE743D58 for ; Tue, 4 Jul 2006 06:27:42 +0000 (GMT) (envelope-from kip.macy@gmail.com) Received: by nz-out-0102.google.com with SMTP id 34so596611nzf for ; Mon, 03 Jul 2006 23:27:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XH1orRbElRgZCpvUcKGzugJHzv7EuYqRalYswr5SColQuEMcGPH8oCMc3x947kyeMufXiv9SahXsY1Swec5W6woy6zRK9qBoXMo7rMsI6jm2sMT1JbXjjBK/XIfRuII8xHNEegYDTML8so1dgvtEJh6rmYW46JMTsY16/y/7kyE= Received: by 10.65.218.8 with SMTP id v8mr3850887qbq; Mon, 03 Jul 2006 23:27:42 -0700 (PDT) Received: by 10.65.225.9 with HTTP; Mon, 3 Jul 2006 23:27:42 -0700 (PDT) Message-ID: Date: Mon, 3 Jul 2006 23:27:42 -0700 From: "Kip Macy" To: "Robert Watson" In-Reply-To: <20060703103420.B26325@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060629111231.GA692@wolf.nvidia.com> <20060702114950.bf39e312.mmendez@energyhq.be> <1151877095.1085.19.camel@genius.i.cz> <20060703103420.B26325@fledge.watson.org> Cc: Sam Smith , freebsd-hackers@freebsd.org, Michal Mertl , Christian Zander Subject: Re: NVIDIA FreeBSD kernel feature requests X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kmacy@fsmware.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2006 06:27:44 -0000 > Producing a driver for a GPU card, especially one that possibly converts from > GL-foo to foo appropriate to program and feed an ASIC on a video card, is > quite different matter entirely. > > I'm all for open source drivers, and would also encourage NVIDIA to continue > to reconsider their closed source driver approach where it makes sense > (especially for the network interfaces). However, I think that we shouldn't > conflate these two cases rhetorically, as there are orders of magnitude > complexity (and intellectual property) differences. Furthermore, requesting needed changes to the kernel interfaces is completely orthogonal to their documentation policies. -Kip From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 4 13:54:15 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ABE6216A4DA for ; Tue, 4 Jul 2006 13:54:15 +0000 (UTC) (envelope-from aag.lists@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48D1243D49 for ; Tue, 4 Jul 2006 13:54:15 +0000 (GMT) (envelope-from aag.lists@gmail.com) Received: by py-out-1112.google.com with SMTP id b36so1770681pyb for ; Tue, 04 Jul 2006 06:54:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=hc24LEOa4YgAZ+k68PSV7nK0uRMZL9MyM2sVcfKOZeWzmaFwRBGSAMPvliJJ694eE3hMOt/GwMG1x1d5nDADR14usEGnvSwZG68H+UYf67lArLW5x4bEGknTqQ3JQwlV0CSf66byxqL2dGjHhqSU2XFC8QdwRWkco837w8izsVY= Received: by 10.35.98.6 with SMTP id a6mr2396682pym; Tue, 04 Jul 2006 06:54:14 -0700 (PDT) Received: by 10.35.50.18 with HTTP; Tue, 4 Jul 2006 06:54:14 -0700 (PDT) Message-ID: <2f3a439f0607040654h1983febbhfbceb974e366e855@mail.gmail.com> Date: Tue, 4 Jul 2006 19:24:14 +0530 From: "Aditya Godbole" To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: assyms.s 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, 04 Jul 2006 13:54:15 -0000 Hi, I was going through the machine dependant code and found that assembler symbols are created using a script that parses symbol names taken from an object file. Why is it done this way? Are there any advantages of doing this? -aditya From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 4 14:07:07 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 715E816A4DD for ; Tue, 4 Jul 2006 14:07:07 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F44E43D45 for ; Tue, 4 Jul 2006 14:07:05 +0000 (GMT) (envelope-from avg@icyb.net.ua) Received: from [212.40.38.87] (oddity-e.topspin.kiev.ua [212.40.38.87]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA22381 for ; Tue, 04 Jul 2006 17:07:03 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <44AA7607.2060302@icyb.net.ua> Date: Tue, 04 Jul 2006 17:07:03 +0300 From: Andriy Gapon User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Subject: vop_stratgey name 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, 04 Jul 2006 14:07:07 -0000 Maybe this question rather belongs to -questions (or -ancient-history), but I thought I'd get a better chance here. I wonder why vop_strategy is named that, what meaning of "strategy" is used here ? I mean this is a read-or-write function for block devices, why "strategy" :-) -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 4 14:09:51 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F29BC16A4DE for ; Tue, 4 Jul 2006 14:09:51 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 211A543D5C for ; Tue, 4 Jul 2006 14:09:51 +0000 (GMT) (envelope-from asmrookie@gmail.com) Received: by wx-out-0102.google.com with SMTP id s9so707026wxc for ; Tue, 04 Jul 2006 07:09:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=iuNHzQ988qGpCzM2M8TOzp0nCvEzmbXbq4dpGcqCnw/IodG0LnNZQxM7bsbHgZRcRnHrAbxZZPtmVqCcU1a59YAcrgDcWaa1iAxP6nFqAgOtqWXoaWRfnXAkeeplH7zvgdXQnMecR6ZghYQgBLmNkAllYJMHGd0JJWAQytQ96qU= Received: by 10.70.128.8 with SMTP id a8mr7670309wxd; Tue, 04 Jul 2006 07:09:50 -0700 (PDT) Received: by 10.70.11.15 with HTTP; Tue, 4 Jul 2006 07:09:50 -0700 (PDT) Message-ID: <3bbf2fe10607040709h3625059ck616eded8ce38499f@mail.gmail.com> Date: Tue, 4 Jul 2006 16:09:50 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Aditya Godbole" In-Reply-To: <2f3a439f0607040654h1983febbhfbceb974e366e855@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2f3a439f0607040654h1983febbhfbceb974e366e855@mail.gmail.com> X-Google-Sender-Auth: 75abe608f0d11710 Cc: freebsd-hackers@freebsd.org Subject: Re: assyms.s 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, 04 Jul 2006 14:09:52 -0000 2006/7/4, Aditya Godbole : > Hi, > > I was going through the machine dependant code and found that > assembler symbols are created using a script that parses symbol names > taken from an object file. Why is it done this way? Are there any > advantages of doing this? assym.s just keeps track of some 'offsets' (often inside data structures) to be used in .s codes. It's preliminary generated from $arch/$arch/genassym.c. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 4 18:40:56 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 97AF716A4DA for ; Tue, 4 Jul 2006 18:40:56 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49DBE43D46 for ; Tue, 4 Jul 2006 18:40:56 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.13.7/8.13.7) with ESMTP id k64Ie9wK029566; Tue, 4 Jul 2006 11:40:09 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.7/8.13.7/Submit) id k64Ie57W029565; Tue, 4 Jul 2006 11:40:05 -0700 (PDT) (envelope-from sgk) Date: Tue, 4 Jul 2006 11:40:05 -0700 From: Steve Kargl To: Randall Hyde Message-ID: <20060704184005.GA29544@troutmask.apl.washington.edu> References: <16887068.1151618963387.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> <20060630081019.GB734@turion.vk2pj.dyndns.org> <002501c69ecf$5967c6b0$6302a8c0@pentiv> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002501c69ecf$5967c6b0$6302a8c0@pentiv> User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@freebsd.org Subject: Re: getc in BSD (was FLEX issues) 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, 04 Jul 2006 18:40:56 -0000 On Mon, Jul 03, 2006 at 11:34:41AM -0700, Randall Hyde wrote: > > The error reported is "syntax error before numeric constant". > This kind of gives me the impression that "getc" is defined a bit > differently under FreeBSD than other environments? Any ideas? As others have stated, getc() is implemented via a macro, which may depend on other macros. In reading the flex NEWS file, I ran across the -Cr option. I added this option to your flex command, and the hla.flx file is processed and produces a compilable lex.yy.c. -- Steve From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 5 01:15:49 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8BD7016A4DA for ; Wed, 5 Jul 2006 01:15:49 +0000 (UTC) (envelope-from artifact.one@googlemail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by mx1.FreeBSD.org (Postfix) with ESMTP id D2BE143D45 for ; Wed, 5 Jul 2006 01:15:48 +0000 (GMT) (envelope-from artifact.one@googlemail.com) Received: by ug-out-1314.google.com with SMTP id e2so1443577ugf for ; Tue, 04 Jul 2006 18:15:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pXnW6iYWdIsIW+VqYtCS3cnOiKUzzLdg+elO3K54hBnT6DQ1r5i1aM9iKwb4Z6Jxl6bhg/FOtWKXuGVuJuekPZZzwnBpxyUfdkirXA/zBd8oWvJ72b97ROfnm1HpN8QL2Ln0KnE4CVjpQNcavXorugFDVTmE2LY1h1X+pQpmfcI= Received: by 10.78.151.3 with SMTP id y3mr1526260hud; Tue, 04 Jul 2006 18:15:45 -0700 (PDT) Received: by 10.78.43.9 with HTTP; Tue, 4 Jul 2006 18:15:44 -0700 (PDT) Message-ID: <8e96a0b90607041815s7888cf7areb5244247b9bdb53@mail.gmail.com> Date: Wed, 5 Jul 2006 02:15:44 +0100 From: "mal content" To: "Peter Jeremy" In-Reply-To: <20060703190448.GD727@turion.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8e96a0b90607031009v4ec2630fgfc432f5dad15abda@mail.gmail.com> <20060703190448.GD727@turion.vk2pj.dyndns.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Stop further socket() or connect() calls. 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, 05 Jul 2006 01:15:49 -0000 On 03/07/06, Peter Jeremy wrote: > For dynamic executables, you could LD_PRELOAD a .so that replaces > all the socket-related syscalls. Excellent suggestion! Ok, I've created a basic .so file with the following code, but I've basically got stuck because I don't know how the original syscalls are defined and can't find the definitions in the source: --- #include #include #include int socket(int d, int t, int prot) { return __syscall(SYS_socket, d, t, prot); } int connect(int s, const struct sockaddr *sa, socklen_t len) { return __syscall(SYS_connect, s, sa, len); } int bind(int s, const struct sockaddr *sa, socklen_t len) { return __syscall(SYS_bind, s, sa, len); } int listen(int s, int bl) { return __syscall(SYS_listen, s, bl); } --- This doesn't work, it causes various runtime errors. Where are the system calls defined in the source? I could just copy the definitions. cheers MC From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 5 05:50:59 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9567716A4E2 for ; Wed, 5 Jul 2006 05:50:59 +0000 (UTC) (envelope-from kamalpr@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50E9243D53 for ; Wed, 5 Jul 2006 05:50:58 +0000 (GMT) (envelope-from kamalpr@gmail.com) Received: by nz-out-0102.google.com with SMTP id x3so741882nzd for ; Tue, 04 Jul 2006 22:50:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=mUJnmKqbYQeXYqxJTfJekPKLJmf/xFjUgm8X+NvEnbBTpn9KZwxj5ToseAJt7WsqEnqSMSxAEcT+ydzzBM3iIVJ5vglaaanIeRftku39FBmiqBJ4iyxV6jQrwXPQFrwcIlSSy+d8CWm+oLI4m6kVQkFwziHLKYKaLTqxhlmXACQ= Received: by 10.36.19.4 with SMTP id 4mr4792805nzs; Tue, 04 Jul 2006 22:50:57 -0700 (PDT) Received: by 10.36.18.18 with HTTP; Tue, 4 Jul 2006 22:50:57 -0700 (PDT) Message-ID: Date: Wed, 5 Jul 2006 11:20:57 +0530 From: "Kamal R. Prasad" Sender: kamalpr@gmail.com To: "Andriy Gapon" In-Reply-To: <44AA7607.2060302@icyb.net.ua> MIME-Version: 1.0 References: <44AA7607.2060302@icyb.net.ua> X-Google-Sender-Auth: 0af0e1b7a062c1d4 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: vop_stratgey name 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, 05 Jul 2006 05:50:59 -0000 The block device has a head which is positioned at (platter, cylinder, sector) etc. before a write or read can be done. The strategy function chooses the order in which blocks are to be accessed so as to minimize the positioning required i.e. if we schedule closely located blocks of data for access -no matter when the request came in, that will speed up disk I/O. (In addition to this, the VM also does some strategizing of blocks to be read/written before passing them to the block driver.). regards -kamal On 7/4/06, Andriy Gapon wrote: > > > Maybe this question rather belongs to -questions (or -ancient-history), > but I thought I'd get a better chance here. > > I wonder why vop_strategy is named that, what meaning of "strategy" is > used here ? > I mean this is a read-or-write function for block devices, why > "strategy" :-) > > -- > Andriy Gapon > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 5 06:09:15 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 87FBB16A4DA for ; Wed, 5 Jul 2006 06:09:15 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2399843D49 for ; Wed, 5 Jul 2006 06:09:15 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [IPv6:::1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k6566oF2079818; Wed, 5 Jul 2006 00:06:50 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 05 Jul 2006 00:06:54 -0600 (MDT) Message-Id: <20060705.000654.-1543907249.imp@bsdimp.com> To: kmacy@fsmware.com, kip.macy@gmail.com From: "M. Warner Losh" In-Reply-To: References: <20060703103420.B26325@fledge.watson.org> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: S@msmith.net, freebsd-hackers@freebsd.org, mime@traveller.cz, rwatson@freebsd.org, czander@nvidia.com Subject: Re: NVIDIA FreeBSD kernel feature requests 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, 05 Jul 2006 06:09:15 -0000 In message: "Kip Macy" writes: : > Producing a driver for a GPU card, especially one that possibly converts from : > GL-foo to foo appropriate to program and feed an ASIC on a video card, is : > quite different matter entirely. : > : > I'm all for open source drivers, and would also encourage NVIDIA to continue : > to reconsider their closed source driver approach where it makes sense : > (especially for the network interfaces). However, I think that we shouldn't : > conflate these two cases rhetorically, as there are orders of magnitude : > complexity (and intellectual property) differences. : : Furthermore, requesting needed changes to the kernel interfaces is : completely orthogonal to their documentation policies. It is well documented that NVIDIA gives you binary drivers. Other vendors give you source or binary as they see fit. When you have a choice, the type of driver may factor into what you buy. When you don't have a choice (because, say, it is a built-in chip), the availability of a binary-only driver vs no driver at all may save your laptop or computer from being a paperweight. As interesting as such choices are, they, as Kip points out, are orthogonal to suggestions on how FreeBSD could be better. Even if NVIDIA had release open source drivers for their current binary drivers, the issues they took the trouble to document and writeup in a clear, coherent fashion here would still be present. It is in the best interest of the FreeBSD project to accept this valuable input and evaluate it on its merits, rather than on our political judgment of the messenger. Warner From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 5 06:14:43 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 03CCE16A4E6 for ; Wed, 5 Jul 2006 06:14:43 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C07843D58 for ; Wed, 5 Jul 2006 06:14:42 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [IPv6:::1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k656D0bv079938; Wed, 5 Jul 2006 00:13:01 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 05 Jul 2006 00:13:05 -0600 (MDT) Message-Id: <20060705.001305.1661916063.imp@bsdimp.com> To: aag.lists@gmail.com From: "M. Warner Losh" In-Reply-To: <2f3a439f0607040654h1983febbhfbceb974e366e855@mail.gmail.com> References: <2f3a439f0607040654h1983febbhfbceb974e366e855@mail.gmail.com> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: assyms.s 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, 05 Jul 2006 06:14:43 -0000 In message: <2f3a439f0607040654h1983febbhfbceb974e366e855@mail.gmail.com> "Aditya Godbole" writes: : I was going through the machine dependant code and found that : assembler symbols are created using a script that parses symbol names : taken from an object file. Why is it done this way? Are there any : advantages of doing this? genassym is done so that the C compiler can tell us the offsets of different fields of different structures shared between C and aseembler code. This method is done because it doesn't require execution of a program to determine the offsets. Once upon a time, it used to be implemented as something approximating: printf("#define FOO_BAR %d\n", offsetof(foo, foo_bar)); but this required execution in the target environment. When host and target were the same, this didn't matter. But when the host is i386 and the target is alpha, for example, the program would produce different numbers on i386 than on alpha for any data structure that contained pointers. The current method of creating a .o file using the target compiler and then teasing the information out of that .o file generates the same results on both host and target. Well, assuming the absense of compiler bugs for the target compiler running a given host. Warner From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 5 09:39:49 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7825116A4E5 for ; Wed, 5 Jul 2006 09:39:49 +0000 (UTC) (envelope-from Danovitsch@vitsch.net) Received: from amsfep20-int.chello.nl (amsfep17-int.chello.nl [213.46.243.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55CC443D45 for ; Wed, 5 Jul 2006 09:39:47 +0000 (GMT) (envelope-from Danovitsch@vitsch.net) Received: from Tuinhuisje.Vitsch.net ([62.195.87.223]) by amsfep20-int.chello.nl (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20060705093944.NMMH3918.amsfep20-int.chello.nl@Tuinhuisje.Vitsch.net>; Wed, 5 Jul 2006 11:39:44 +0200 Received: from [192.168.87.6] (f23025.upc-f.chello.nl [80.56.23.25]) (authenticated bits=0) by Tuinhuisje.Vitsch.net (8.13.1/8.13.1) with ESMTP id k659dbDD059131; Wed, 5 Jul 2006 11:39:39 +0200 (CEST) (envelope-from Danovitsch@vitsch.net) From: "Daan Vreeken [PA4DAN]" Organization: Vitsch Electronics To: "mal content" Date: Wed, 5 Jul 2006 11:39:31 +0200 User-Agent: KMail/1.8.2 References: <8e96a0b90607031009v4ec2630fgfc432f5dad15abda@mail.gmail.com> <20060703190448.GD727@turion.vk2pj.dyndns.org> <8e96a0b90607041815s7888cf7areb5244247b9bdb53@mail.gmail.com> In-Reply-To: <8e96a0b90607041815s7888cf7areb5244247b9bdb53@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607051139.32393.Danovitsch@vitsch.net> Cc: freebsd-hackers@freebsd.org Subject: Re: Stop further socket() or connect() calls. 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, 05 Jul 2006 09:39:49 -0000 On Wednesday 05 July 2006 03:15, mal content wrote: > On 03/07/06, Peter Jeremy wrote: > > For dynamic executables, you could LD_PRELOAD a .so that replaces > > all the socket-related syscalls. > > Excellent suggestion! Ok, I've created a basic .so file with the following > code, but I've basically got stuck because I don't know how the original > syscalls are defined and can't find the definitions in the source: > > --- > #include > #include > #include > > int socket(int d, int t, int prot) > { > return __syscall(SYS_socket, d, t, prot); > } > [ ... ] Wouldn't this still allow a program to open sockets when the program does the __syscall() dance for itself instead of relying on socket() to work? I have never tried MAC myself, so correct me if I'm wrong, but I think something like this could be done using a modified version of mac_portacl(4). grtz, Daan From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 5 17:05:34 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFFF816A4E1 for ; Wed, 5 Jul 2006 17:05:34 +0000 (UTC) (envelope-from artifact.one@googlemail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id F337043D45 for ; Wed, 5 Jul 2006 17:05:33 +0000 (GMT) (envelope-from artifact.one@googlemail.com) Received: by nf-out-0910.google.com with SMTP id l35so1289356nfa for ; Wed, 05 Jul 2006 10:05:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FCQVtSNyu8aPyoIKcgWpXx7lMP6Cio5F1sGyjhKHKs6MAYuApyD4MR3uU9+2Z0iPLSvqk2LvQxmNckOD3snbWLiJcIKsjRFChoP5/5braUIlk/nGe1Csxde7cHUMR4fiPxdUko97POuHY5yT4lk4Eiyr4CY00y+gut5FbjQqfqc= Received: by 10.78.156.6 with SMTP id d6mr2440708hue; Wed, 05 Jul 2006 10:05:32 -0700 (PDT) Received: by 10.78.43.9 with HTTP; Wed, 5 Jul 2006 10:05:32 -0700 (PDT) Message-ID: <8e96a0b90607051005l5b6c5abeh6fa4b7387cae2fb6@mail.gmail.com> Date: Wed, 5 Jul 2006 18:05:32 +0100 From: "mal content" To: "Daan Vreeken [PA4DAN]" In-Reply-To: <200607051139.32393.Danovitsch@vitsch.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8e96a0b90607031009v4ec2630fgfc432f5dad15abda@mail.gmail.com> <20060703190448.GD727@turion.vk2pj.dyndns.org> <8e96a0b90607041815s7888cf7areb5244247b9bdb53@mail.gmail.com> <200607051139.32393.Danovitsch@vitsch.net> Cc: freebsd-hackers@freebsd.org Subject: Re: Stop further socket() or connect() calls. 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, 05 Jul 2006 17:05:35 -0000 On 05/07/06, Daan Vreeken [PA4DAN] wrote: > On Wednesday 05 July 2006 03:15, mal content wrote: > > On 03/07/06, Peter Jeremy wrote: > > > For dynamic executables, you could LD_PRELOAD a .so that replaces > > > all the socket-related syscalls. > > > > Excellent suggestion! Ok, I've created a basic .so file with the following > > code, but I've basically got stuck because I don't know how the original > > syscalls are defined and can't find the definitions in the source: > > > > --- > > #include > > #include > > #include > > > > int socket(int d, int t, int prot) > > { > > return __syscall(SYS_socket, d, t, prot); > > } > > [ ... ] > > Wouldn't this still allow a program to open sockets when the program does the > __syscall() dance for itself instead of relying on socket() to work? > I have never tried MAC myself, so correct me if I'm wrong, but I think > something like this could be done using a modified version of mac_portacl(4). Yes, it would. It's not meant as a security measure, more a sort of 'make this app misbehave' for testing purposes. Seems to be working well anyway now. MC From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 5 19:35:02 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 575C016A4DD for ; Wed, 5 Jul 2006 19:35:02 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3C7143D45 for ; Wed, 5 Jul 2006 19:35:01 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k65JYutT002384; Wed, 5 Jul 2006 15:34:57 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Wed, 5 Jul 2006 12:04:30 -0400 User-Agent: KMail/1.9.1 References: <20060628181045.GA54915@curry.mchp.siemens.de> <417C9B11412FF8C17A1AD483@Zelazny> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607051204.31577.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 05 Jul 2006 15:34:58 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1585/Tue Jul 4 16:39:34 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: Pat Lashley , Matthias Andree , Johannes Weiner Subject: Re: Return value of malloc(0) 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, 05 Jul 2006 19:35:02 -0000 On Saturday 01 July 2006 04:35, Matthias Andree wrote: > Pat Lashley writes: > > > BUT, that said, the safest and most portable coding practice would be: > > > > // The C standard does not require malloc(0) to return NULL; > > // but whatever it returns MUST NOT be dereferenced. > > ptr = ( size == 0 ) ? NULL : malloc( size ) ; > > Safest (avoiding null derefence) would instead be: > > ptr = malloc(size ? size : 1); > > BTW: // is not a valid C89 comment, but a GCC-ism. It's valid in C99 though. :) -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 5 19:35:06 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 924B216A4FB for ; Wed, 5 Jul 2006 19:35:06 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id C935843D45 for ; Wed, 5 Jul 2006 19:35:05 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k65JYutU002384; Wed, 5 Jul 2006 15:34:59 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Wed, 5 Jul 2006 12:11:57 -0400 User-Agent: KMail/1.9.1 References: <20060629111231.GA692@wolf.nvidia.com> <20060702.220217.2073896080.imp@bsdimp.com> In-Reply-To: <20060702.220217.2073896080.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607051211.58386.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 05 Jul 2006 15:34:59 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1585/Tue Jul 4 16:39:34 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: czander@nvidia.com Subject: Re: NVIDIA FreeBSD kernel feature requests 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, 05 Jul 2006 19:35:06 -0000 On Monday 03 July 2006 00:02, M. Warner Losh wrote: > In message: <20060629111231.GA692@wolf.nvidia.com> > Christian Zander writes: > : This summary makes an attempt to describe the kernel interfaces needed by > : the NVIDIA FreeBSD i386 graphics driver to achieve feature parity with > : the Linux/Solaris graphics drivers, and/or required to make support for > : the FreeBSD amd64 platform feasible. It also describes some of the > : technical difficulties encountered by NVIDIA during the FreeBSD i386 > : graphics driver's development, how these problems have been worked around > : and what could be done to solve them better. > > Thank you for taking the time to let us know how we might make the > system better. > > : The NVIDIA graphics driver needs to be able to create uncached kernel > : and user mappings of I/O memory, such as NVIDIA GPU registers. The > : FreeBSD kernel does not currently provide the interfaces necessary to > : specify the memory type when creating such mappings, which makes it > : difficult for the NVIDIA graphics driver to guarantee that the correct > : memory type is selected. > > Is this via the bus_alloc_resource interface? Is uncached kernel > memory different than non-prefetchable memory? If so, please specify > how it is different. If not, then we have an interface that will do > what you want, except it is only implemented for cardbus and would > need to be implemented for pci pci and pci host bridges. Would having > better functionality here help? I noticed it wasn't on the task list... This isn't an issue of how the memory is mapped in the PCI-PCI bridge where non-prefetchable is used to keep the bridge from prefetching things, but as to how the memory is mapped in the CPU itself. Also, I've seen mention of using bus_dma, etc. One of the problems is our current bus APIs have a very limited view of caching "modes". E.g. here you mention overloading non-prefetchable to get a UC mapping. In bus_dma(9) we have the COHERENT flag to UC rather than a WB mapping. Neither of these API's allow for, say, WC (Write-Combining) mappings. :) Other OS's such as Windows and OS X allow you to explicitly specify what type of cache "mode" you want for a mapping. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 5 20:28:48 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0818E16A4DD for ; Wed, 5 Jul 2006 20:28:48 +0000 (UTC) (envelope-from randyhyde@earthlink.net) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 666C443D64 for ; Wed, 5 Jul 2006 20:28:47 +0000 (GMT) (envelope-from randyhyde@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=DQLMCUBmsHAVbSFo47rAQ6MrPSokwYRu1H4SqzI54n65VnraiRWr1nGrQPSXtnAc; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.40] (helo=elwamui-milano.atl.sa.earthlink.net) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1FyDzK-0004Wj-Sp; Wed, 05 Jul 2006 16:28:46 -0400 Received: from 198.74.38.59 by webmail.pas.earthlink.net with HTTP; Wed, 5 Jul 2006 16:28:46 -0400 Message-ID: <4596402.1152131326848.JavaMail.root@elwamui-milano.atl.sa.earthlink.net> Date: Wed, 5 Jul 2006 13:28:46 -0700 (GMT-07:00) From: Randall Hyde To: freebsd-hackers@freebsd.org Cc: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: eba5e0c9192a36dcd6dd28457998182d7e972de0d01da940448929ee647a707c6f9c473998cf8d9e350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.40 Subject: Re: getc in BSD (was FLEX issues) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randall Hyde List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2006 20:28:48 -0000 -----Original Message----- >From: Steve Kargl >Sent: Jul 4, 2006 11:40 AM >To: Randall Hyde >Cc: freebsd-hackers@freebsd.org >Subject: Re: getc in BSD (was FLEX issues) > >On Mon, Jul 03, 2006 at 11:34:41AM -0700, Randall Hyde wrote: >> >> The error reported is "syntax error before numeric constant". >> This kind of gives me the impression that "getc" is defined a bit >> differently under FreeBSD than other environments? Any ideas? > >As others have stated, getc() is implemented via a macro, >which may depend on other macros. In reading the flex >NEWS file, I ran across the -Cr option. I added this >option to your flex command, and the hla.flx file is >processed and produces a compilable lex.yy.c. > >-- >Steve Yeah, getc was the problem. I modified flex (via one the various macros it defines) to emit fgetc rather than getc and the problem went away. I'll have to try the -Cr option and see what happens there. Cheers, Randy Hyde From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 5 23:30:56 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C0DF16A4DE; Wed, 5 Jul 2006 23:30:56 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id B722143D49; Wed, 5 Jul 2006 23:30:53 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id k65NUqFm057530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Jul 2006 16:30:53 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <44AC4BAC.4040105@errno.com> Date: Wed, 05 Jul 2006 16:30:52 -0700 From: Sam Leffler User-Agent: Thunderbird 1.5.0.2 (X11/20060508) MIME-Version: 1.0 To: John Baldwin References: <20060629111231.GA692@wolf.nvidia.com> <20060702.220217.2073896080.imp@bsdimp.com> <200607051211.58386.jhb@freebsd.org> In-Reply-To: <200607051211.58386.jhb@freebsd.org> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, czander@nvidia.com Subject: Re: NVIDIA FreeBSD kernel feature requests 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, 05 Jul 2006 23:30:56 -0000 John Baldwin wrote: > On Monday 03 July 2006 00:02, M. Warner Losh wrote: >> In message: <20060629111231.GA692@wolf.nvidia.com> >> Christian Zander writes: >> : This summary makes an attempt to describe the kernel interfaces needed by >> : the NVIDIA FreeBSD i386 graphics driver to achieve feature parity with >> : the Linux/Solaris graphics drivers, and/or required to make support for >> : the FreeBSD amd64 platform feasible. It also describes some of the >> : technical difficulties encountered by NVIDIA during the FreeBSD i386 >> : graphics driver's development, how these problems have been worked around >> : and what could be done to solve them better. >> >> Thank you for taking the time to let us know how we might make the >> system better. >> >> : The NVIDIA graphics driver needs to be able to create uncached kernel >> : and user mappings of I/O memory, such as NVIDIA GPU registers. The >> : FreeBSD kernel does not currently provide the interfaces necessary to >> : specify the memory type when creating such mappings, which makes it >> : difficult for the NVIDIA graphics driver to guarantee that the correct >> : memory type is selected. >> >> Is this via the bus_alloc_resource interface? Is uncached kernel >> memory different than non-prefetchable memory? If so, please specify >> how it is different. If not, then we have an interface that will do >> what you want, except it is only implemented for cardbus and would >> need to be implemented for pci pci and pci host bridges. Would having >> better functionality here help? I noticed it wasn't on the task list... > > This isn't an issue of how the memory is mapped in the PCI-PCI bridge where > non-prefetchable is used to keep the bridge from prefetching things, but as > to how the memory is mapped in the CPU itself. Also, I've seen mention of > using bus_dma, etc. One of the problems is our current bus APIs have a very > limited view of caching "modes". E.g. here you mention overloading > non-prefetchable to get a UC mapping. In bus_dma(9) we have the COHERENT > flag to UC rather than a WB mapping. Neither of these API's allow for, say, > WC (Write-Combining) mappings. :) Other OS's such as Windows and OS X allow > you to explicitly specify what type of cache "mode" you want for a mapping. > As we've discussed privately, bus_dma is the right api for drivers to use. If it doesn't do what he needs then we need to extend it. Drivers should not be groveling around inside the vm system. Sam From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 6 01:02:58 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 62B1616A4E0 for ; Thu, 6 Jul 2006 01:02:58 +0000 (UTC) (envelope-from dwoolworth@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id F0F4743D45 for ; Thu, 6 Jul 2006 01:02:56 +0000 (GMT) (envelope-from dwoolworth@gmail.com) Received: by nf-out-0910.google.com with SMTP id o60so18067nfa for ; Wed, 05 Jul 2006 18:02:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=mEgZxGRPow8dy+LMu+fgCbY6QJX/nci/fbVlJxP1xOS8cnS0Ox0JprWEaGZScPl+cx03BOmsYIidBzm7LQU0boAbGRXxXtfw9rhs3ekEmuuT9yWxCLGFQltO6EiubDjFsZnJ4aAqmt5mGdX/PkQE0RQEki/V+XCjRi7eAEAP0Ps= Received: by 10.48.242.11 with SMTP id p11mr80867nfh; Wed, 05 Jul 2006 18:02:55 -0700 (PDT) Received: by 10.48.207.4 with HTTP; Wed, 5 Jul 2006 18:02:55 -0700 (PDT) Message-ID: <10fd06c60607051802jd9d6158ufd3406465cc64dfc@mail.gmail.com> Date: Wed, 5 Jul 2006 20:02:55 -0500 From: "Derrick T. Woolworth" To: freebsd-questions@freebsd.org, freebsd-performance@freebsd.org, freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: SATA300 Controllers 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, 06 Jul 2006 01:02:58 -0000 Hello all, Sorry for cross-posting, but these issues seem relevant for lists... Has anyone had success with SATA300 controllers with FreeBSD 6.1? I've been trying Promise and nVidia nForce4 and I'm not having any luck. Using a MSI K8NGM2-L motherboard and others, but 6.1's installation hangs as soon as it sees ad4. I've also tried using an Adaptec 1210SA controller and had zero results. I've read that the chipset on this controller is not very good - forces serialized access to the controller's channels??? Nevertheless, I've got a K8N Diamond motherboard on a workstation and I was able to at least "start" the 6.1 installation. I have no idea if its stable. At this point, I'd settle for just knowing "which" SATA300 controller to use that will work successfully and "well" with FreeBSD 6.0 OR 6.1. Another question, would I have more success installing 6.0 and then upgrading the kernel and recompiling with a build-world? I'm currently trying to build a moderate large system with 4 presentation servers, 2 database servers and one large storage system using NFS mapped to ~1.2 terrabyte of SATA disks (4x Maxtor 500GB 7200 RPM disks w/RAID5 config). Any suggestions? Thanks, Derrick From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 6 02:54:04 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EFCE516A4DD for ; Thu, 6 Jul 2006 02:54:04 +0000 (UTC) (envelope-from fcash@ocis.net) Received: from smtp.sd73.bc.ca (mailtest.sd73.bc.ca [142.24.13.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05B0E43D5E for ; Thu, 6 Jul 2006 02:54:01 +0000 (GMT) (envelope-from fcash@ocis.net) Received: from localhost (localhost [127.0.0.1]) by localhost.sd73.bc.ca (Postfix) with ESMTP id 839388A0026; Wed, 5 Jul 2006 20:01:17 -0700 (PDT) Received: from smtp.sd73.bc.ca ([127.0.0.1]) by localhost (smtp.sd73.bc.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 74621-01-11; Wed, 5 Jul 2006 20:01:11 -0700 (PDT) Received: from webmail.sd73.bc.ca (unknown [10.10.10.17]) by smtp.sd73.bc.ca (Postfix) with ESMTP id 445E38A0034; Wed, 5 Jul 2006 20:01:06 -0700 (PDT) Received: from webmail.sd73.bc.ca (localhost.localdomain [127.0.0.1]) by webmail.sd73.bc.ca (Postfix) with ESMTP id 51F7B9000612; Wed, 5 Jul 2006 19:53:50 -0700 (PDT) Received: from 24.71.118.34 (SquirrelMail authenticated user fcash) by webmail.sd73.bc.ca with HTTP; Wed, 5 Jul 2006 19:53:50 -0700 (PDT) Message-ID: <62134.24.71.118.34.1152154430.squirrel@webmail.sd73.bc.ca> In-Reply-To: <10fd06c60607051802jd9d6158ufd3406465cc64dfc@mail.gmail.com> References: <10fd06c60607051802jd9d6158ufd3406465cc64dfc@mail.gmail.com> Date: Wed, 5 Jul 2006 19:53:50 -0700 (PDT) From: "Freddie Cash" To: "Derrick T. Woolworth" User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new using ClamAV at sd73.bc.ca Cc: hackers@freebsd.org Subject: Re: SATA300 Controllers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: fcash@ocis.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2006 02:54:05 -0000 On Wed, July 5, 2006 6:02 pm, Derrick T. Woolworth wrote: > Sorry for cross-posting, but these issues seem relevant for lists... > Has anyone had success with SATA300 controllers with FreeBSD 6.1? > I've been trying Promise and nVidia nForce4 and I'm not having any > luck. Using a MSI K8NGM2-L motherboard and others, but 6.1's Considered getting a real, server-class motherboard with a server-class chipset on it? Something using an AMD 8000-series chipset, or a ServerWorks chipset, or even (as a last resort) an Intel chipset? Something other than nVidia and Ati. :) We're got several dozen servers (tower and rackmount) using Tyan S2882 motherboards, with 3Ware Escalade 9550SX RAID controllers. Running FreeBSD 6.1 on a 12x 400 GB SATA HD RAID5 array was fun. :) 4 TB of usable diskspace. Unfortunately, it was reformatted with Debian Linux before being put into production. ---- Freddie Cash fcash@ocis.net From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 6 01:23:59 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4222516A4DA; Thu, 6 Jul 2006 01:23:59 +0000 (UTC) (envelope-from drechsau@Geeks.ORG) Received: from mail.geeks.org (jacobs.Geeks.ORG [204.153.247.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id A31B243D46; Thu, 6 Jul 2006 01:23:58 +0000 (GMT) (envelope-from drechsau@Geeks.ORG) Received: by mail.geeks.org (Postfix, from userid 1000) id 9EA2E15905A; Wed, 5 Jul 2006 20:23:57 -0500 (CDT) Date: Wed, 5 Jul 2006 20:23:57 -0500 From: Mike Horwath To: "Derrick T. Woolworth" Message-ID: <20060706012357.GB80086@Geeks.ORG> Mail-Followup-To: "Derrick T. Woolworth" , freebsd-questions@freebsd.org, freebsd-performance@freebsd.org, freebsd-hackers@freebsd.org References: <10fd06c60607051802jd9d6158ufd3406465cc64dfc@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10fd06c60607051802jd9d6158ufd3406465cc64dfc@mail.gmail.com> X-PGP-Fingerprint: D8 24 CC E6 47 5F E4 60 BF B7 6E FA BF C7 6E C5 X-GPG-Fingerprint: 6A89 E78A B8B1 69D9 8CDB E966 4A5A C3F9 A1B0 C381 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Mailman-Approved-At: Thu, 06 Jul 2006 03:38:54 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-performance@freebsd.org, freebsd-questions@freebsd.org Subject: Re: SATA300 Controllers 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, 06 Jul 2006 01:23:59 -0000 On Wed, Jul 05, 2006 at 08:02:55PM -0500, Derrick T. Woolworth wrote: > Sorry for cross-posting, but these issues seem relevant for lists... That's okay, I am not on all and I'll create some bounces, I am sure. > Has anyone had success with SATA300 controllers with FreeBSD 6.1? > I've been trying Promise and nVidia nForce4 and I'm not having any > luck. Using a MSI K8NGM2-L motherboard and others, but 6.1's > installation hangs as soon as it sees ad4. I've also tried using an > Adaptec 1210SA controller and had zero results. I've read that the > chipset on this controller is not very good - forces serialized > access to the controller's channels??? Nevertheless, I've got a K8N > Diamond motherboard on a workstation and I was able to at least > "start" the 6.1 installation. I have no idea if its stable. At > this point, I'd settle for just knowing "which" SATA300 controller > to use that will work successfully and "well" with FreeBSD 6.0 OR > 6.1. Another question, would I have more success installing 6.0 and > then upgrading the kernel and recompiling with a build-world? I am running 6.0 and 6.1 systems (-STABLE) with both ARECA 12xx cards and 3WARE/AMCC 9550SX cards. Neither are cheap, but they are doing the job and are in use in binary spoolers for news. > I'm currently trying to build a moderate large system with 4 presentation > servers, 2 database servers and one large storage system using NFS mapped to > ~1.2 terrabyte of SATA disks (4x Maxtor 500GB 7200 RPM disks w/RAID5 > config). Any suggestions? Up the # of spindles? :) -- Mike Horwath, reachable via drechsau@Geeks.ORG From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 6 03:45:41 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C27C16A4DA for ; Thu, 6 Jul 2006 03:45:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E41A43D46 for ; Thu, 6 Jul 2006 03:45:40 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k663jSFo005135; Wed, 5 Jul 2006 23:45:29 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Sam Leffler Date: Wed, 5 Jul 2006 23:42:28 -0400 User-Agent: KMail/1.9.1 References: <20060629111231.GA692@wolf.nvidia.com> <200607051211.58386.jhb@freebsd.org> <44AC4BAC.4040105@errno.com> In-Reply-To: <44AC4BAC.4040105@errno.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607052342.29273.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [192.168.0.1]); Wed, 05 Jul 2006 23:45:29 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1586/Wed Jul 5 15:22:07 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: freebsd-hackers@freebsd.org, czander@nvidia.com Subject: Re: NVIDIA FreeBSD kernel feature requests 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, 06 Jul 2006 03:45:41 -0000 On Wednesday 05 July 2006 19:30, Sam Leffler wrote: > John Baldwin wrote: > > On Monday 03 July 2006 00:02, M. Warner Losh wrote: > >> In message: <20060629111231.GA692@wolf.nvidia.com> > >> Christian Zander writes: > >> : This summary makes an attempt to describe the kernel interfaces needed by > >> : the NVIDIA FreeBSD i386 graphics driver to achieve feature parity with > >> : the Linux/Solaris graphics drivers, and/or required to make support for > >> : the FreeBSD amd64 platform feasible. It also describes some of the > >> : technical difficulties encountered by NVIDIA during the FreeBSD i386 > >> : graphics driver's development, how these problems have been worked around > >> : and what could be done to solve them better. > >> > >> Thank you for taking the time to let us know how we might make the > >> system better. > >> > >> : The NVIDIA graphics driver needs to be able to create uncached kernel > >> : and user mappings of I/O memory, such as NVIDIA GPU registers. The > >> : FreeBSD kernel does not currently provide the interfaces necessary to > >> : specify the memory type when creating such mappings, which makes it > >> : difficult for the NVIDIA graphics driver to guarantee that the correct > >> : memory type is selected. > >> > >> Is this via the bus_alloc_resource interface? Is uncached kernel > >> memory different than non-prefetchable memory? If so, please specify > >> how it is different. If not, then we have an interface that will do > >> what you want, except it is only implemented for cardbus and would > >> need to be implemented for pci pci and pci host bridges. Would having > >> better functionality here help? I noticed it wasn't on the task list... > > > > This isn't an issue of how the memory is mapped in the PCI-PCI bridge where > > non-prefetchable is used to keep the bridge from prefetching things, but as > > to how the memory is mapped in the CPU itself. Also, I've seen mention of > > using bus_dma, etc. One of the problems is our current bus APIs have a very > > limited view of caching "modes". E.g. here you mention overloading > > non-prefetchable to get a UC mapping. In bus_dma(9) we have the COHERENT > > flag to UC rather than a WB mapping. Neither of these API's allow for, say, > > WC (Write-Combining) mappings. :) Other OS's such as Windows and OS X allow > > you to explicitly specify what type of cache "mode" you want for a mapping. > > > > As we've discussed privately, bus_dma is the right api for drivers to > use. If it doesn't do what he needs then we need to extend it. Drivers > should not be groveling around inside the vm system. I don't disagree, but my point is that the APIs do need extending. Look at it this way. The current changes are to provide a way so nvidia can call pmap_foo() functions rather than modifying PTE's and the PAT MSR's directly. This is progress. :) -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 6 08:39:36 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 66EB516A4DA; Thu, 6 Jul 2006 08:39:36 +0000 (UTC) (envelope-from bsam@ns.kfs.ru) Received: from ns.kfs.ru (kfs.kfs.ru [62.183.117.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id DEFEB43D45; Thu, 6 Jul 2006 08:39:35 +0000 (GMT) (envelope-from bsam@ns.kfs.ru) Received: from bsam by ns.kfs.ru with local (Exim 4.54 (FreeBSD)) id 1FyPOX-0006c1-Tj; Thu, 06 Jul 2006 12:39:33 +0400 To: "Derrick T. Woolworth" References: <10fd06c60607051802jd9d6158ufd3406465cc64dfc@mail.gmail.com> From: Boris Samorodov Date: Thu, 06 Jul 2006 12:39:33 +0400 In-Reply-To: <10fd06c60607051802jd9d6158ufd3406465cc64dfc@mail.gmail.com> (Derrick T. Woolworth's message of "Wed, 5 Jul 2006 20:02:55 -0500") Message-ID: <83074666@serv3.int.kfs.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: "Boris B. Samorodov" X-Mailman-Approved-At: Thu, 06 Jul 2006 11:54:46 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-performance@freebsd.org, freebsd-questions@freebsd.org Subject: Re: SATA300 Controllers 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, 06 Jul 2006 08:39:36 -0000 On Wed, 5 Jul 2006 20:02:55 -0500 Derrick T. Woolworth wrote: > Has anyone had success with SATA300 controllers with FreeBSD 6.1? I've been > trying Promise and nVidia nForce4 and I'm not having any luck. Using a MSI I have an nForce4 built-in card on amd64 motherboard and use it as a testing machine with 6.1-STABLE/7.0-CURRENT amd64/i386 worlds. Everyting is fine so far (crossing fingers). > K8NGM2-L motherboard and others, but 6.1's installation hangs as soon as it > sees ad4. I've also tried using an Adaptec 1210SA controller and had zero > results. I've read that the chipset on this controller is not very good - > forces serialized access to the controller's channels??? Nevertheless, I've > got a K8N Diamond motherboard on a workstation and I was able to at least > "start" the 6.1 installation. I have no idea if its stable. At this point, > I'd settle for just knowing "which" SATA300 controller to use that will work > successfully and "well" with FreeBSD 6.0 OR 6.1. Another question, would I > have more success installing 6.0 and then upgrading the kernel and > recompiling with a build-world? > I'm currently trying to build a moderate large system with 4 presentation > servers, 2 database servers and one large storage system using NFS mapped to > ~1.2 terrabyte of SATA disks (4x Maxtor 500GB 7200 RPM disks w/RAID5 > config). Any suggestions? WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 6 15:25:28 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A3AF16A4DF; Thu, 6 Jul 2006 15:25:28 +0000 (UTC) (envelope-from ahebert@pubnix.net) Received: from mail.pubnix.net (Mail.pubnix.net [192.172.250.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id E87E343D55; Thu, 6 Jul 2006 15:25:27 +0000 (GMT) (envelope-from ahebert@pubnix.net) Received: from [10.0.1.2] (aal.pubnix.net [64.235.216.13]) (authenticated bits=0) by mail.pubnix.net (8.13.6/8.13.6) with ESMTP id k66FPP5F002963; Thu, 6 Jul 2006 11:25:26 -0400 (EDT) (envelope-from ahebert@pubnix.net) Message-ID: <44AD2B65.9080407@pubnix.net> Date: Thu, 06 Jul 2006 11:25:25 -0400 From: Alain Hebert Organization: PubNIX, Inc. User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20060514 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <10fd06c60607051802jd9d6158ufd3406465cc64dfc@mail.gmail.com> In-Reply-To: <10fd06c60607051802jd9d6158ufd3406465cc64dfc@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-performance@freebsd.org, freebsd-questions@freebsd.org Subject: Re: SATA300 Controllers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ahebert@pubnix.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2006 15:25:28 -0000 Hi, I've been having the same issues. The conclusion of my testing is that type of card (aka Adaptec 1210SA, Promise PDC2* ) are not stable, reliable, performant. (For my taste btw) The underlying technology is just mickey mouse: They store the config on drive (ok); They dont accelerate mirror that much. (mirror function in driver); If you loose a drive your filesystem jam (since the mirror function is in the driver); You have to rebuilt via the bios (long downtime). The best card are the 3ware 9000/9500 series. Which is a real hard implementation. FYI: I have both success with Marvell 88SX5041 SATA150 and Promise PDC20378 SATA150. I had major failure under load with Adaptec 1210SA and Promise TX2300. Good luck. Derrick T. Woolworth wrote: > Hello all, > > Sorry for cross-posting, but these issues seem relevant for lists... > > Has anyone had success with SATA300 controllers with FreeBSD 6.1? > I've been > trying Promise and nVidia nForce4 and I'm not having any luck. Using > a MSI > K8NGM2-L motherboard and others, but 6.1's installation hangs as soon > as it > sees ad4. I've also tried using an Adaptec 1210SA controller and had > zero > results. I've read that the chipset on this controller is not very > good - > forces serialized access to the controller's channels??? > Nevertheless, I've > got a K8N Diamond motherboard on a workstation and I was able to at least > "start" the 6.1 installation. I have no idea if its stable. At this > point, > I'd settle for just knowing "which" SATA300 controller to use that > will work > successfully and "well" with FreeBSD 6.0 OR 6.1. Another question, > would I > have more success installing 6.0 and then upgrading the kernel and > recompiling with a build-world? > > I'm currently trying to build a moderate large system with 4 presentation > servers, 2 database servers and one large storage system using NFS > mapped to > ~1.2 terrabyte of SATA disks (4x Maxtor 500GB 7200 RPM disks w/RAID5 > config). Any suggestions? > > Thanks, > > Derrick > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" > -- Alain Hebert ahebert@pubnix.net PubNIX Inc. P.O. Box 175 Beaconsfield, Quebec H9W 5T7 tel 514-990-5911 http://www.pubnix.net fax 514-990-9443 From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 6 19:54:23 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0675616A4E0 for ; Thu, 6 Jul 2006 19:54:23 +0000 (UTC) (envelope-from mmendez@energyhq.be) Received: from spitfire.energyhq.be (161.Red-83-57-201.dynamicIP.rima-tde.net [83.57.201.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5720543D53 for ; Thu, 6 Jul 2006 19:54:19 +0000 (GMT) (envelope-from mmendez@energyhq.be) Received: from scienide.energyhq.be (scienide.energyhq.be [192.168.2.2]) by spitfire.energyhq.be (Postfix) with SMTP id E9B8CFE96; Thu, 6 Jul 2006 21:54:17 +0200 (CEST) Date: Thu, 6 Jul 2006 21:53:39 +0200 From: Miguel Mendez To: Michal Mertl Message-Id: <20060706215339.36c52f2e.mmendez@energyhq.be> In-Reply-To: <1151877095.1085.19.camel@genius.i.cz> References: <20060629111231.GA692@wolf.nvidia.com> <20060702114950.bf39e312.mmendez@energyhq.be> <1151877095.1085.19.camel@genius.i.cz> Organization: EnergyHQ X-Mailer: Sylpheed version 2.2.0 (GTK+ 2.8.11; amd64-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Thu__6_Jul_2006_21_53_39_+0200_xZx3vuvin8BDKqjq" Cc: freebsd-hackers@freebsd.org, czander@nvidia.com Subject: Re: NVIDIA FreeBSD kernel feature requests 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, 06 Jul 2006 19:54:23 -0000 --Signature=_Thu__6_Jul_2006_21_53_39_+0200_xZx3vuvin8BDKqjq Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, 02 Jul 2006 23:51:35 +0200 Michal Mertl wrote: Hi, I'm going to reply to this, once, just to make my argument clear. > I think that this reaction wasn't called for. Modern GPUs are > extraordinarily complex HW and to write a decent driver will take > appropriate effort. I understand that open source "infected" people > (like me) prefer having the detailed HW documentation but we shouldn't > refuse the vendor's efforts to provide good driver to us. I agree modern GPUs are way more complex than the C64 VIC. However I never asked for the source code of the driver. I ran one earlier version through Siul+hacky's dasm and, believe me, you don't want that code. NVidia's reason for not releasing the source code of their proprietary OpenGL driver is that it contains licensed 3rd party code. Let's buy that for a second. That still doesn't explain why the nforce chipsets are undocumented. And that doesn't explain why there isn't any register documentation for earlier GPUs. I mean, for Christ's sake, if you're on a 6 month release cycle, who honestly cares about a card that was released 2 years ago? But still no documentation. You might be familiar with this quote: "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety". In these days many freenix users happily give up their freedom in order to gain functinality. It's funny when you think about it, NVidia started when some engineers left SGI. SGI has contributed a lot to the free software community, e.g. XFS, while NVidia doesn't seem to care at all. Considering that they're a _hardware_ company I find it amusing that they refuse to help people do work for them for free. > I haven't understood much of Mr. Zander's questions but I am pretty sure > some readers did and probably have been talking to him off-list. I also > tend to believe that his requests for features were based on good > understanding of FreeBSD kernel internals (better that mine and probably > also yours) and if we add the features or help him effectively use > what's there everyone will benefit. And as I see it, NVidia is asking FreeBSD developers to invest man hours, for free, so they can release a _proprietary_ driver for FreeBSD which you can neither use on !x86/amd64 nor study. Sounds like a very nice deal. I know many among the BSD camp consider people like Richard Stallman and Theo to be extremists when it comes to software freedom. Maybe you'll change your mind next time you're trying to use NVidia hardware on a macppc box. Cheers. --=20 Miguel Mendez =20 http://www.energyhq.be PGP Key: 0xDC8514F1 --Signature=_Thu__6_Jul_2006_21_53_39_+0200_xZx3vuvin8BDKqjq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFErWpGnLctrNyFFPERAvz3AJ9iRLli3ezQqZh7Fpv/jeC14NjLhgCbBasz eC7UA50CUs141C07aj+P5rM= =tJyR -----END PGP SIGNATURE----- --Signature=_Thu__6_Jul_2006_21_53_39_+0200_xZx3vuvin8BDKqjq-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 6 19:55:20 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8427616A4F6; Thu, 6 Jul 2006 19:55:20 +0000 (UTC) (envelope-from wb@freebie.xs4all.nl) Received: from smtp-vbr3.xs4all.nl (smtp-vbr3.xs4all.nl [194.109.24.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A08243D68; Thu, 6 Jul 2006 19:55:10 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp-vbr3.xs4all.nl (8.13.6/8.13.6) with ESMTP id k66Jt6dC021133; Thu, 6 Jul 2006 21:55:06 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.13.6/8.13.3) with ESMTP id k66Jt4K4001336; Thu, 6 Jul 2006 21:55:04 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.13.6/8.13.6/Submit) id k66Jt4RU001335; Thu, 6 Jul 2006 21:55:04 +0200 (CEST) (envelope-from wb) Date: Thu, 6 Jul 2006 21:55:04 +0200 From: Wilko Bulte To: "Derrick T. Woolworth" Message-ID: <20060706195504.GA1252@freebie.xs4all.nl> References: <10fd06c60607051802jd9d6158ufd3406465cc64dfc@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10fd06c60607051802jd9d6158ufd3406465cc64dfc@mail.gmail.com> User-Agent: Mutt/1.5.11 X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-hackers@freebsd.org, freebsd-performance@freebsd.org, freebsd-questions@freebsd.org Subject: Re: SATA300 Controllers 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, 06 Jul 2006 19:55:20 -0000 On Wed, Jul 05, 2006 at 08:02:55PM -0500, Derrick T. Woolworth wrote.. > Hello all, > > Sorry for cross-posting, but these issues seem relevant for lists... > > Has anyone had success with SATA300 controllers with FreeBSD 6.1? I've been > trying Promise and nVidia nForce4 and I'm not having any luck. Using a MSI > K8NGM2-L motherboard and others, but 6.1's installation hangs as soon as it > sees ad4. I've also tried using an Adaptec 1210SA controller and had zero Well, just as a datapoint this works fine for me: wb@freebie ~: dmesg|grep -i Prom atapci0: port 0xd480-0xd4ff,0xd000-0xd0ff mem 0xf7ff6000-0xf7ff6fff,0xf7fa0000-0xf7fbffff irq 21 at device 13.0 on pci2 ar0: 238475MB status: READY wb@freebie ~: uname -a FreeBSD freebie.xs4all.nl 6.1-STABLE FreeBSD 6.1-STABLE #2: Wed Jun 14 22:01:33 CEST 2006 root@freebie.xs4all.nl:/usr/obj/usr/src/sys/FREEBIE i386 -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 6 21:26:41 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C82E16A504; Thu, 6 Jul 2006 21:26:41 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9123A43D45; Thu, 6 Jul 2006 21:26:37 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [10.10.3.185] ([69.15.205.254]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k66LQNiH022282; Thu, 6 Jul 2006 15:26:29 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <44AD7FF9.8010405@samsco.org> Date: Thu, 06 Jul 2006 15:26:17 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060206 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Wilko Bulte References: <10fd06c60607051802jd9d6158ufd3406465cc64dfc@mail.gmail.com> <20060706195504.GA1252@freebie.xs4all.nl> In-Reply-To: <20060706195504.GA1252@freebie.xs4all.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=3.8 tests=none autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org X-Mailman-Approved-At: Thu, 06 Jul 2006 21:39:57 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-performance@freebsd.org, freebsd-questions@freebsd.org, "Derrick T. Woolworth" Subject: Re: SATA300 Controllers 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, 06 Jul 2006 21:26:41 -0000 Wilko Bulte wrote: > On Wed, Jul 05, 2006 at 08:02:55PM -0500, Derrick T. Woolworth wrote.. > >>Hello all, >> >>Sorry for cross-posting, but these issues seem relevant for lists... >> >>Has anyone had success with SATA300 controllers with FreeBSD 6.1? I've been >>trying Promise and nVidia nForce4 and I'm not having any luck. Using a MSI >>K8NGM2-L motherboard and others, but 6.1's installation hangs as soon as it >>sees ad4. I've also tried using an Adaptec 1210SA controller and had zero > > > Well, just as a datapoint this works fine for me: > > wb@freebie ~: dmesg|grep -i Prom > atapci0: port > 0xd480-0xd4ff,0xd000-0xd0ff mem 0xf7ff6000-0xf7ff6fff,0xf7fa0000-0xf7fbffff > irq 21 at device 13.0 on pci2 > ar0: 238475MB status: READY > wb@freebie ~: uname -a > FreeBSD freebie.xs4all.nl 6.1-STABLE FreeBSD 6.1-STABLE #2: Wed Jun 14 > 22:01:33 CEST 2006 root@freebie.xs4all.nl:/usr/obj/usr/src/sys/FREEBIE > i386 > Promise has a good relationship with FreeBSD, I would expect their controllers to work pretty well. Scott From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 6 21:36:08 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C12916A589; Thu, 6 Jul 2006 21:36:08 +0000 (UTC) (envelope-from mikej@rogers.com) Received: from H43.C18.B96.tor.eicat.ca (H43.C18.B96.tor.eicat.ca [66.96.18.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 25DC943D46; Thu, 6 Jul 2006 21:36:05 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from [127.0.0.1] (desktop.home.local [172.16.0.200]) by H43.C18.B96.tor.eicat.ca (Postfix) with ESMTP id 84C7D1144F; Thu, 6 Jul 2006 17:35:27 -0400 (EDT) Message-ID: <44AD8253.80702@rogers.com> Date: Thu, 06 Jul 2006 17:36:19 -0400 From: Mike Jakubik User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Derrick T. Woolworth" References: <10fd06c60607051802jd9d6158ufd3406465cc64dfc@mail.gmail.com> In-Reply-To: <10fd06c60607051802jd9d6158ufd3406465cc64dfc@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SpamToaster-Information: This messages has been scanned by SpamToaster http://www.digitalprogression.ca X-SpamToaster: Found to be clean X-SpamToaster-SpamCheck: not spam, SpamAssassin (not cached, score=-2.49, required 3.5, ALL_TRUSTED -1.80, BAYES_00 -2.60, DK_POLICY_SIGNSOME 0.00, DNS_FROM_RFC_ABUSE 0.20, DNS_FROM_RFC_POST 1.71) X-SpamToaster-From: mikej@rogers.com X-Spam-Status: No X-Mailman-Approved-At: Thu, 06 Jul 2006 21:40:08 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-performance@freebsd.org, freebsd-questions@freebsd.org Subject: Re: SATA300 Controllers 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, 06 Jul 2006 21:36:08 -0000 Derrick T. Woolworth wrote: > Hello all, > > Sorry for cross-posting, but these issues seem relevant for lists... > > Has anyone had success with SATA300 controllers with FreeBSD 6.1? > I've been > trying Promise and nVidia nForce4 and I'm not having any luck. Using > a MSI Yes, this chipset works well for me. --- atapci0: port 0x3040-0x3047,0x3034-0x3037,0x3038-0x303f,0x3030-0x3033,0x3020-0x302f mem 0xed000000-0xed0003ff irq 19 at device 31.2 on pci0 ad4: 152627MB at ata2-master SATA300 GEOM_MIRROR: Device gm created (id=1306182778). GEOM_MIRROR: Device gm: provider ad4 detected. ad6: 152627MB at ata3-master SATA300 SMP: AP CPU #1 Launched! GEOM_MIRROR: Device gm: provider ad6 detected. GEOM_MIRROR: Device gm: provider ad6 activated. GEOM_MIRROR: Device gm: provider ad4 activated. GEOM_MIRROR: Device gm: provider mirror/gm launched. --- For a simple RAID such as mirroring, i strongly suggest you stay away from cheap/onboard RAID solutions, and use gmirror instead. From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 6 22:10:48 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.ORG Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 272A816A4DA; Thu, 6 Jul 2006 22:10:48 +0000 (UTC) (envelope-from wb@freebie.xs4all.nl) Received: from smtp-vbr8.xs4all.nl (smtp-vbr8.xs4all.nl [194.109.24.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4787143D45; Thu, 6 Jul 2006 22:10:46 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp-vbr8.xs4all.nl (8.13.6/8.13.6) with ESMTP id k66MAeov023809; Fri, 7 Jul 2006 00:10:45 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.13.6/8.13.3) with ESMTP id k66MAeVH003601; Fri, 7 Jul 2006 00:10:40 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.13.6/8.13.6/Submit) id k66MAe6x003600; Fri, 7 Jul 2006 00:10:40 +0200 (CEST) (envelope-from wb) Date: Fri, 7 Jul 2006 00:10:40 +0200 From: Wilko Bulte To: Scott Long Message-ID: <20060706221039.GA3579@freebie.xs4all.nl> References: <10fd06c60607051802jd9d6158ufd3406465cc64dfc@mail.gmail.com> <20060706195504.GA1252@freebie.xs4all.nl> <44AD7FF9.8010405@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44AD7FF9.8010405@samsco.org> User-Agent: Mutt/1.5.11 X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-hackers@FreeBSD.ORG, freebsd-performance@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG, "Derrick T. Woolworth" Subject: Re: SATA300 Controllers 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, 06 Jul 2006 22:10:48 -0000 On Thu, Jul 06, 2006 at 03:26:17PM -0600, Scott Long wrote.. > Wilko Bulte wrote: > >On Wed, Jul 05, 2006 at 08:02:55PM -0500, Derrick T. Woolworth wrote.. > > > >>Hello all, > >> > >>Sorry for cross-posting, but these issues seem relevant for lists... > >> > >>Has anyone had success with SATA300 controllers with FreeBSD 6.1? I've > >>been > >>trying Promise and nVidia nForce4 and I'm not having any luck. Using a > >>MSI > >>K8NGM2-L motherboard and others, but 6.1's installation hangs as soon as > >>it > >>sees ad4. I've also tried using an Adaptec 1210SA controller and had zero > > > > > >Well, just as a datapoint this works fine for me: > > > >wb@freebie ~: dmesg|grep -i Prom > >atapci0: port > >0xd480-0xd4ff,0xd000-0xd0ff mem 0xf7ff6000-0xf7ff6fff,0xf7fa0000-0xf7fbffff > >irq 21 at device 13.0 on pci2 > >ar0: 238475MB status: READY > >wb@freebie ~: uname -a > >FreeBSD freebie.xs4all.nl 6.1-STABLE FreeBSD 6.1-STABLE #2: Wed Jun 14 > >22:01:33 CEST 2006 root@freebie.xs4all.nl:/usr/obj/usr/src/sys/FREEBIE > >i386 > > > > Promise has a good relationship with FreeBSD, I would expect their > controllers to work pretty well. Yup. I cleared this TX2200 (IIRC) card with Soren first before I ordered it. It only has SATA150 disks connected to it though, I do not own SATA300 drives. All in all the whole thing works fine for me. -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 6 23:08:22 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 21F5D16A4DD for ; Thu, 6 Jul 2006 23:08:22 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (megan.kiwi-computer.com [63.224.10.3]) by mx1.FreeBSD.org (Postfix) with SMTP id A7C4F43D68 for ; Thu, 6 Jul 2006 23:08:10 +0000 (GMT) (envelope-from rick@kiwi-computer.com) Received: (qmail 55321 invoked by uid 2001); 6 Jul 2006 23:08:08 -0000 Date: Thu, 6 Jul 2006 18:08:08 -0500 From: "Rick C. Petty" To: freebsd-hackers@freebsd.org Message-ID: <20060706230808.GA55294@megan.kiwi-computer.com> References: <10fd06c60607051802jd9d6158ufd3406465cc64dfc@mail.gmail.com> <20060706195504.GA1252@freebie.xs4all.nl> <44AD7FF9.8010405@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44AD7FF9.8010405@samsco.org> User-Agent: Mutt/1.4.2.1i Subject: Re: SATA300 Controllers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd@kiwi-computer.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2006 23:08:22 -0000 On Thu, Jul 06, 2006 at 03:26:17PM -0600, Scott Long wrote: > > > >>Has anyone had success with SATA300 controllers with FreeBSD 6.1? I've > >>been > >>trying Promise and nVidia nForce4 and I'm not having any luck. Using a > >>MSI > >>K8NGM2-L motherboard and others, but 6.1's installation hangs as soon as > >>it > >>sees ad4. I've also tried using an Adaptec 1210SA controller and had zero > > Promise has a good relationship with FreeBSD, I would expect their > controllers to work pretty well. I'm using a few "Promise PDC40718 SATA300 controller" with identical SATA300 drives and it seems to work well. My only gripe is the channels are misnumbered: port #1 maps to channel 3 port #2 maps to channel 1 port #3 maps to channel 0 port #4 maps to channel 2 I had to use the serial numbers to make sure I was writing on the correct drives, so that was annoying. -- Rick C. Petty From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 7 05:04:12 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B2F6F16A4E9 for ; Fri, 7 Jul 2006 05:04:12 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.FreeBSD.org (Postfix) with SMTP id EF06843D69 for ; Fri, 7 Jul 2006 05:04:07 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 2051 invoked by uid 399); 7 Jul 2006 05:04:06 -0000 Received: from localhost (HELO ?192.168.0.7?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 7 Jul 2006 05:04:06 -0000 Message-ID: <44ADEB46.7010401@FreeBSD.org> Date: Thu, 06 Jul 2006 22:04:06 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Miguel Mendez References: <20060629111231.GA692@wolf.nvidia.com> <20060702114950.bf39e312.mmendez@energyhq.be> <1151877095.1085.19.camel@genius.i.cz> <20060706215339.36c52f2e.mmendez@energyhq.be> In-Reply-To: <20060706215339.36c52f2e.mmendez@energyhq.be> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, czander@nvidia.com Subject: Re: NVIDIA FreeBSD kernel feature requests 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, 07 Jul 2006 05:04:12 -0000 I found your manifesto for free software interesting, although I didn't really see anything new there so I snipped it. In my opinion, you can always vote with your wallet, and if you feel that strongly about needing all the parts of your system to be "free," well, knock yourself out. On the other hand, I like nvidia graphics cards, they meet my needs, and I appreciate their support of free software, particularly the brand of OS that I choose to use. It is of no consequence to me that their idea of "free" does not match up with what others believe to be "truly free." However, what I did want to react to was this bit below ... Miguel Mendez wrote: > And as I see it, NVidia is asking FreeBSD developers to invest man > hours, for free, so they can release a _proprietary_ driver for FreeBSD > which you can neither use on !x86/amd64 nor study. Sounds like a very > nice deal. You may choose to see it how you wish, and you may also choose to try and persuade others to see it your way. However, several developers (who are a lot smarter than I when it comes to kernel stuff) have already spoken up to say that at least some of the ideas presented would have value in other areas if they were implemented, so at best I would deem your characterization to be slanted. You may wish to consider if perhaps it is not also inaccurate. Doug -- This .signature sanitized for your protection From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 7 09:04:56 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC83A16A4DA for ; Fri, 7 Jul 2006 09:04:56 +0000 (UTC) (envelope-from sos@freebsd.org) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D9F643D46 for ; Fri, 7 Jul 2006 09:04:56 +0000 (GMT) (envelope-from sos@freebsd.org) Received: from [194.192.25.130] (sos.deepcore.dk [194.192.25.130]) by spider.deepcore.dk (8.13.6/8.13.4) with ESMTP id k6794tAj029698; Fri, 7 Jul 2006 11:04:55 +0200 (CEST) (envelope-from sos@freebsd.org) Message-ID: <44AE23B6.7000607@freebsd.org> Date: Fri, 07 Jul 2006 11:04:54 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Thunderbird 1.5.0.2 (X11/20060531) MIME-Version: 1.0 To: rick-freebsd@kiwi-computer.com References: <10fd06c60607051802jd9d6158ufd3406465cc64dfc@mail.gmail.com> <20060706195504.GA1252@freebie.xs4all.nl> <44AD7FF9.8010405@samsco.org> <20060706230808.GA55294@megan.kiwi-computer.com> In-Reply-To: <20060706230808.GA55294@megan.kiwi-computer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-mail-scanned: by DeepCore Virus & Spam killer v1.16 Cc: freebsd-hackers@freebsd.org Subject: Re: SATA300 Controllers 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, 07 Jul 2006 09:04:56 -0000 Rick C. Petty wrote: > On Thu, Jul 06, 2006 at 03:26:17PM -0600, Scott Long wrote: > >>>> Has anyone had success with SATA300 controllers with FreeBSD 6.1? I've >>>> been >>>> trying Promise and nVidia nForce4 and I'm not having any luck. Using a >>>> MSI >>>> K8NGM2-L motherboard and others, but 6.1's installation hangs as soon as >>>> it >>>> sees ad4. I've also tried using an Adaptec 1210SA controller and had zero >>>> >> Promise has a good relationship with FreeBSD, I would expect their >> controllers to work pretty well. >> > > I'm using a few "Promise PDC40718 SATA300 controller" with identical > SATA300 drives and it seems to work well. My only gripe is the channels > are misnumbered: > port #1 maps to channel 3 > port #2 maps to channel 1 > port #3 maps to channel 0 > port #4 maps to channel 2 > > I had to use the serial numbers to make sure I was writing on the correct > drives, so that was annoying. > Actually its the channel numbering printed on the card thats flawed, it doesn't match the physical channel numbers that the chip uses (and hence ATA channel numbers). I have no idea why they did that on some of their controllers, but I suspect historical reasons as they older controllers had the physical connectors in that order (3 1 0 2), but the guy that did the silkscreen layout probably ordered them "nicely" at some point :) -Søren From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 8 00:27:13 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2510E16A4DA for ; Sat, 8 Jul 2006 00:27:13 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8674643D45 for ; Sat, 8 Jul 2006 00:27:12 +0000 (GMT) (envelope-from killing@multiplay.co.uk) Received: from vader ([212.135.219.179]) by multiplay.co.uk (multiplay.co.uk [85.236.96.23]) (MDaemon PRO v9.0.1) with ESMTP id md50002741863.msg for ; Sat, 08 Jul 2006 01:27:02 +0100 Message-ID: <031501c6a225$27797a00$b3db87d4@multiplay.co.uk> From: "Steven Hartland" To: Date: Sat, 8 Jul 2006 01:26:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Processed: multiplay.co.uk, Sat, 08 Jul 2006 01:27:02 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 212.135.219.179 X-Return-Path: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org X-MDAV-Processed: multiplay.co.uk, Sat, 08 Jul 2006 01:27:04 +0100 Subject: BSD tar broken file name parsing 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, 08 Jul 2006 00:27:13 -0000 Just had a really strange one, on a fresh 6.1 install tar will not extract named files e.g. tar -xvzPf my.tar.gz /usr/local/etc/apache/httpd.conf The above fails to extract the file which quite clearly exists: tar -tvzPf my.tar.gz | grep /usr/local/etc/httpd.conf -rw-r--r-- 0 root wheel 37202 May 6 23:30 /usr/local/etc/apache/httpd.conf Similarly -tvzPf naming the file doesnt find the file. Using wild cards finds the file: tar -tvzPf my.tar.gz '*httpd.conf' -rw-r--r-- 0 root wheel 37202 May 6 23:30 /usr/local/etc/apache/httpd.conf I suspect its -P processing that is broken. Installing gtar and using that works fine: gtar -xvzPf my.tar.gz /usr/local/etc/apache/httpd.conf /usr/local/etc/apache/httpd.conf gtar -tvzPf my.tar.gz /usr/local/etc/apache/httpd.conf -rw-r--r-- root/wheel 37202 2006-05-06 23:30:58 /usr/local/etc/apache/httpd.conf Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 8 02:55:38 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3DC7A16A4DD for ; Sat, 8 Jul 2006 02:55:38 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9ED5A43D45 for ; Sat, 8 Jul 2006 02:55:37 +0000 (GMT) (envelope-from killing@multiplay.co.uk) Received: from vader ([212.135.219.179]) by multiplay.co.uk (multiplay.co.uk [85.236.96.23]) (MDaemon PRO v9.0.1) with ESMTP id md50002742571.msg for ; Sat, 08 Jul 2006 03:55:33 +0100 Message-ID: <064a01c6a239$e5e2a7f0$b3db87d4@multiplay.co.uk> From: "Steven Hartland" To: Date: Sat, 8 Jul 2006 03:54:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Processed: multiplay.co.uk, Sat, 08 Jul 2006 03:55:33 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 212.135.219.179 X-Return-Path: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org X-MDAV-Processed: multiplay.co.uk, Sat, 08 Jul 2006 03:55:35 +0100 Subject: Promise PDC20267 / ide bug? 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, 08 Jul 2006 02:55:38 -0000 I've just reinstalled a box with 6.1-RELEASE on a Promise PDC20267 RAID 0+1 ARRAY. On boot the BIOS says the array is "functional" but FreeBSD claims its running in DEGRADED mode. [dmesg] ad4: 190782MB at ata2-master UDMA100 ad5: 114473MB at ata2-slave UDMA100 ad6: 114473MB at ata3-master UDMA100 ad7: 114473MB at ata3-slave UDMA100 ar0: WARNING - mirror protection lost. RAID0+1 array in DEGRADED mode ar0: 228946MB status: DEGRADED ar0: disk0 DOWN no device found for this subdisk ar0: disk1 READY (master) using ad5 at ata2-slave ar0: disk2 READY (mirror) using ad6 at ata3-master ar0: disk3 READY (mirror) using ad7 at ata3-slave [/dmesg] atacontrol status ar0 ar0: ATA RAID0+1 stripesize=128 subdisks: DOWN ad5 ad6 ad7 status: DEGRADED I believe the problem is due to the size of ad4 which is a 200Gb disk as I had no spare 120's to replace the failed disk for this install. I think this is causing BSD to error as the RAID bios only listed it as a ~120GB i.e. only slightly bigger than other 120's. Has anyone see this before? Is it a bug with the ide driver? Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 8 03:17:17 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9FEEC16A4DD for ; Sat, 8 Jul 2006 03:17:17 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id F06B143D46 for ; Sat, 8 Jul 2006 03:17:16 +0000 (GMT) (envelope-from killing@multiplay.co.uk) Received: from vader ([212.135.219.179]) by multiplay.co.uk (multiplay.co.uk [85.236.96.23]) (MDaemon PRO v9.0.1) with ESMTP id md50002742676.msg for ; Sat, 08 Jul 2006 04:17:02 +0100 Message-ID: <065801c6a23c$e6fd8670$b3db87d4@multiplay.co.uk> From: "Steven Hartland" To: References: <064a01c6a239$e5e2a7f0$b3db87d4@multiplay.co.uk> Date: Sat, 8 Jul 2006 04:16:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Processed: multiplay.co.uk, Sat, 08 Jul 2006 04:17:02 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 212.135.219.179 X-Return-Path: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org X-MDAV-Processed: multiplay.co.uk, Sat, 08 Jul 2006 04:17:03 +0100 Subject: Re: Promise PDC20267 / ide bug? 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, 08 Jul 2006 03:17:17 -0000 I believe this is also causing random crashes such as "more" core dumping after the machine has done signigicant disk access. After more IO I then start getting the following errors on the console such as the follow: g_vfs_done():ar0s1f[READ(offset=-33834299286175744, lenght=16384)] error5 handle_workitme_freeblocks: block count ad7: FAILURE - WRITE_DMA status=51 I've just reinstalled a box with 6.1-RELEASE on a > Promise PDC20267 RAID 0+1 ARRAY. > On boot the BIOS says the array is "functional" > but FreeBSD claims its running in DEGRADED mode. > > [dmesg] > ad4: 190782MB at ata2-master UDMA100 > ad5: 114473MB at ata2-slave UDMA100 > ad6: 114473MB at ata3-master UDMA100 > ad7: 114473MB at ata3-slave UDMA100 > ar0: WARNING - mirror protection lost. RAID0+1 array in DEGRADED mode > ar0: 228946MB status: > DEGRADED > ar0: disk0 DOWN no device found for this subdisk > ar0: disk1 READY (master) using ad5 at ata2-slave > ar0: disk2 READY (mirror) using ad6 at ata3-master > ar0: disk3 READY (mirror) using ad7 at ata3-slave > [/dmesg] > > atacontrol status ar0 > ar0: ATA RAID0+1 stripesize=128 subdisks: DOWN ad5 ad6 ad7 status: > DEGRADED > > I believe the problem is due to the size of ad4 which > is a 200Gb disk as I had no spare 120's to replace > the failed disk for this install. I think this is > causing BSD to error as the RAID bios only listed it > as a ~120GB i.e. only slightly bigger than other > 120's. > > Has anyone see this before? Is it a bug with the ide > driver? > > Steve > > > ================================================ > This e.mail is private and confidential between Multiplay (UK) Ltd. > and the person or entity to whom it is addressed. In the event of > misdirection, the recipient is prohibited from using, copying, > printing or otherwise disseminating it or any information contained > in it. > > In the event of misdirection, illegible or incomplete transmission > please telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 8 04:08:16 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6719716A4DA for ; Sat, 8 Jul 2006 04:08:16 +0000 (UTC) (envelope-from daijo@unixevil.info) Received: from zeus.daijo.org (zeus.daijo.org [85.17.16.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3C5A43D45 for ; Sat, 8 Jul 2006 04:08:15 +0000 (GMT) (envelope-from daijo@unixevil.info) Received: (qmail 21353 invoked by uid 210); 8 Jul 2006 06:12:17 +0200 Received: from 84.123.228.149 by zeus (envelope-from , uid 201) with qmail-scanner-2.01st (clamdscan: 0.88.2/1589. spamassassin: 3.1.3. perlscan: 2.01st. Clear:RC:1(84.123.228.149):. Processed in 0.027317 secs); 08 Jul 2006 04:12:17 -0000 Received: from unknown (HELO ?192.168.1.5?) (84.123.228.149) by 0 with (DHE-RSA-AES256-SHA encrypted) SMTP; 8 Jul 2006 06:12:16 +0200 Message-ID: <44AF2FAD.5020205@unixevil.info> Date: Sat, 08 Jul 2006 06:08:13 +0200 From: Victor Roman Archidona User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, flameeyes@gentoo.org, spb@gentoo.org X-Enigmail-Version: 0.94.0.0 OpenPGP: id=A31FA9A0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Static built binaries having unknown ELF binary types 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, 08 Jul 2006 04:08:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, at first I should mention that this post is about Gentoo/FreeBSD for amd64 port, using the Gentoo portage system with FreeBSD sources, library and so on. If you're not interested in this you can stop reading now :-). I'm compiling "make" (usr.bin/make), but when I try to execute it I got the following results: root@localhost ~ # /usr/bin/make ELF binary type "0" not known. - -su: /usr/bin/make: cannot execute binary file root@localhost ~ # I must say that this *only* happends when "make" is built statically (if you want it compiled dynamically change the Makefile). This is the file information about it: root@localhost ~ # file /usr/bin/make /usr/bin/make: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for FreeBSD 6.1, statically linked, for FreeBSD 6.1, stripped root@localhost ~ # Doing some research I found that every static binary has the same issue, so consider the following example as trust of this: #include #include int main(int argc, char *argv[]) { printf("it works!\n"); exit(EXIT_SUCCESS); } Compile it statically: root@localhost ~ # gcc -static test.c -o test root@localhost ~ # file test test: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for FreeBSD 6.1, statically linked, for FreeBSD 6.1, not stripped root@localhost ~ # Then run it: root@localhost ~ # ./test ELF binary type "0" not known. - -su: ./test: cannot execute binary file root@localhost ~ # Now it's time to do the same as dinamically: root@localhost ~ # gcc test.c -o test root@localhost ~ # file test test: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for FreeBSD 6.1, dynamically linked (uses shared libs), for FreeBSD 6.1, not stripped root@localhost ~ # ./test it works! root@localhost ~ # Can anyone point me a possible solution to fix this? I tried doing: "sysctl kern.default_elf_branding=9" but it's a hack and I think it should have a more elegant solution. For some system information, I have the following: binutils (version 2.17), available BFDs: elf64-x86-64 elf32-i386 elf32-i386-freebsd coff-i386 efi-app-ia32 elf64-little elf64-big elf32-little elf32-big srec symbolsrec tekhex binary ihex binutils (version 2.16), available emulations: elf_x86_64_fbsd elf_i386_fbsd elf_x86_64 elf_i386 gcc: gcc (GCC) 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9) system: athlon64 3500+ freebsd sources used: 6.1-RELEASE Thanks for any input in advance, - -- Victor Roman Archidona -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) iD8DBQFEry+sQ/ddYKMfqaARAqUeAJ9TTWBLAJCLxQ7pkNOZHWoc0qFkpQCfY9WT HO1N6kfSIgmROAFT1fxMp9o= =4vZz -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 8 04:19:07 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 835FE16A4DD for ; Sat, 8 Jul 2006 04:19:07 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E8B443D46 for ; Sat, 8 Jul 2006 04:19:07 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.13.7/8.13.7) with ESMTP id k684Hmr8097348; Fri, 7 Jul 2006 21:17:48 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.7/8.13.7/Submit) id k684HmPG097347; Fri, 7 Jul 2006 21:17:48 -0700 (PDT) (envelope-from sgk) Date: Fri, 7 Jul 2006 21:17:48 -0700 From: Steve Kargl To: Victor Roman Archidona Message-ID: <20060708041748.GA97335@troutmask.apl.washington.edu> References: <44AF2FAD.5020205@unixevil.info> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44AF2FAD.5020205@unixevil.info> User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@freebsd.org, flameeyes@gentoo.org, spb@gentoo.org Subject: Re: Static built binaries having unknown ELF binary types 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, 08 Jul 2006 04:19:07 -0000 On Sat, Jul 08, 2006 at 06:08:13AM +0200, Victor Roman Archidona wrote: > > at first I should mention that this post is about Gentoo/FreeBSD for > amd64 port, using the Gentoo portage system with FreeBSD sources, > library and so on. If you're not interested in this you can stop > reading now :-). > This is off-topic for this list. -- Steve From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 8 04:30:06 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3ED9B16A4E1 for ; Sat, 8 Jul 2006 04:30:06 +0000 (UTC) (envelope-from joseph.koshy@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C74A43D45 for ; Sat, 8 Jul 2006 04:30:05 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by ug-out-1314.google.com with SMTP id m3so996234uge for ; Fri, 07 Jul 2006 21:30:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=GVPbx94jeYZFAO3x3Jb7TxCwboc5YiI2Lr9P+prLPMgHQrIFA+PJqJdnqXR9vhg2HtKC7BypLTOfqXcnzkPayGdeMzE1khJxkR+aK/BsQrAFliEkiTbGiRkP1doUbcL1kdwnn+VBJu2EAWWPJPoHzjdT3+fdOUGfdRIc0zsNNc4= Received: by 10.78.177.3 with SMTP id z3mr973946hue; Fri, 07 Jul 2006 21:30:03 -0700 (PDT) Received: by 10.78.50.15 with HTTP; Fri, 7 Jul 2006 21:30:03 -0700 (PDT) Message-ID: <84dead720607072130q32362962p45071058d05456d0@mail.gmail.com> Date: Sat, 8 Jul 2006 10:00:03 +0530 From: "Joseph Koshy" To: "Victor Roman Archidona" In-Reply-To: <44AF2FAD.5020205@unixevil.info> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44AF2FAD.5020205@unixevil.info> Cc: freebsd-hackers@freebsd.org, flameeyes@gentoo.org, spb@gentoo.org Subject: Re: Static built binaries having unknown ELF binary types 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, 08 Jul 2006 04:30:06 -0000 > I'm compiling "make" (usr.bin/make), but when I try to execute > it I got the following results: [snip] 'Tis a bug in your toolchain. e_ident[EI_OSABI] in the ELF header isn't being set correctly for static executables. -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 8 15:14:26 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF63216A4DD; Sat, 8 Jul 2006 15:14:26 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 201E143D45; Sat, 8 Jul 2006 15:14:25 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.180.165] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis), id 0ML21M-1FzEVk1pMP-0005CA; Sat, 08 Jul 2006 17:14:24 +0200 From: Max Laier Organization: FreeBSD To: freebsd-hackers@freebsd.org Date: Sat, 8 Jul 2006 17:14:17 +0200 User-Agent: KMail/1.9.1 References: <200606252139.15862.max@love2party.net> In-Reply-To: <200606252139.15862.max@love2party.net> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2218258.qSTYUWII6N"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200607081714.23266.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: freebsd-current@freebsd.org Subject: Re: Call for Status Reports: 07/07 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, 08 Jul 2006 15:14:26 -0000 --nextPart2218258.qSTYUWII6N Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 25 June 2006 21:39, I wrote: > All, > > it's time for the Status Reports for the second quater of 2006. During t= he > last three month a lot of progress has been made. FreeBSD 6.1 and 5.5 are > released, a new round of Google's Summer of Code has been started, and a > very productive Developer Summit took place during BSDCan. On top of tha= t, > we are now running on Sun's new architecture and a lot of progress has be= en > made for the arm platform, making FreeBSD more viable in the embedded > market. > > We hope that all your projects made good progress as well and would like = to > hear about it. Please share your news and progress over the last three > month with us. Submission are due by 7 July, 2006. > > Once again, submissions are not limited to FreeBSD developers. We will > happily include non-code projects of any kind as long as it is FreeBSD > related. > > For previous reports and submission details, please see: > http://www.freebsd.org/news/status/ Last call, if you have something to submit but didn't yet, let me know *now= *=20 about it and send in the report ASAP!! We have a really good turnout already, so we won't be waiting much longer. Thanks. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart2218258.qSTYUWII6N Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQBEr8vPXyyEoT62BG0RArPWAJ9C2D8XODu2HfhfDaJJDlrLvCvjNgCcDXdI mKxe7lFfK6kGjJmR2mpLGao= =MqDA -----END PGP SIGNATURE----- --nextPart2218258.qSTYUWII6N-- From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 8 21:55:18 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8216016A4DD for ; Sat, 8 Jul 2006 21:55:18 +0000 (UTC) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFF6943D46 for ; Sat, 8 Jul 2006 21:55:10 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id k68Lt964031457; Sat, 8 Jul 2006 14:55:09 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id k68Lt97q031456; Sat, 8 Jul 2006 14:55:09 -0700 Date: Sat, 8 Jul 2006 14:55:09 -0700 From: Brooks Davis To: Steven Hartland Message-ID: <20060708215509.GA31026@odin.ac.hmc.edu> References: <031501c6a225$27797a00$b3db87d4@multiplay.co.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KsGdsel6WgEHnImy" Content-Disposition: inline In-Reply-To: <031501c6a225$27797a00$b3db87d4@multiplay.co.uk> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new Cc: freebsd-hackers@freebsd.org Subject: Re: BSD tar broken file name parsing 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, 08 Jul 2006 21:55:18 -0000 --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 08, 2006 at 01:26:21AM +0100, Steven Hartland wrote: > Just had a really strange one, on a fresh 6.1 install > tar will not extract named files e.g. > tar -xvzPf my.tar.gz /usr/local/etc/apache/httpd.conf >=20 > The above fails to extract the file which quite > clearly exists: > tar -tvzPf my.tar.gz | grep /usr/local/etc/httpd.conf > -rw-r--r-- 0 root wheel 37202 May 6 23:30=20 > /usr/local/etc/apache/httpd.conf >=20 > Similarly -tvzPf naming the file doesnt find the file. >=20 > Using wild cards finds the file: > tar -tvzPf my.tar.gz '*httpd.conf' =20 > -rw-r--r-- 0 root wheel 37202 May 6 23:30=20 > /usr/local/etc/apache/httpd.conf >=20 > I suspect its -P processing that is broken. Installing > gtar and using that works fine: > gtar -xvzPf my.tar.gz /usr/local/etc/apache/httpd.conf =20 > /usr/local/etc/apache/httpd.conf >=20 > gtar -tvzPf my.tar.gz /usr/local/etc/apache/httpd.conf > -rw-r--r-- root/wheel 37202 2006-05-06 23:30:58=20 > /usr/local/etc/apache/httpd.conf Hmm, it look's like -P isn't quite doing it's job. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --KsGdsel6WgEHnImy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFEsCm8XY6L6fI4GtQRApvuAJ48Zv6Cyky7W5bGsv7NEvV7mY2YzQCgr2X5 YkuByEchzoUceNe08GRMg+8= =arXg -----END PGP SIGNATURE----- --KsGdsel6WgEHnImy--