From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 23 06:19:13 2005 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B160516A41F for ; Sun, 23 Oct 2005 06:19:13 +0000 (GMT) (envelope-from frank@exit.com) Received: from tinker.exit.com (tinker.exit.com [206.223.0.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2391543D45 for ; Sun, 23 Oct 2005 06:19:13 +0000 (GMT) (envelope-from frank@exit.com) Received: from realtime.exit.com (realtime [206.223.0.5]) by tinker.exit.com (8.13.4/8.13.4) with ESMTP id j9N6JDmR025991 for ; Sat, 22 Oct 2005 23:19:13 -0700 (PDT) (envelope-from frank@exit.com) Received: from realtime.exit.com (localhost [127.0.0.1]) by realtime.exit.com (8.13.4/8.13.4) with ESMTP id j9N6JC1d003545 for ; Sat, 22 Oct 2005 23:19:12 -0700 (PDT) (envelope-from frank@exit.com) Received: (from frank@localhost) by realtime.exit.com (8.13.4/8.13.4/Submit) id j9N6JBll003544 for hackers@freebsd.org; Sat, 22 Oct 2005 23:19:11 -0700 (PDT) (envelope-from frank@exit.com) X-Authentication-Warning: realtime.exit.com: frank set sender to frank@exit.com using -f From: Frank Mayhar To: hackers@freebsd.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Exit Consulting Date: Sat, 22 Oct 2005 23:19:11 -0700 Message-Id: <1130048351.3442.8.camel@realtime.exit.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port X-Virus-Scanned: ClamAV 0.86.2/1146/Thu Oct 20 21:36:48 2005 on tinker.exit.com X-Virus-Status: Clean Cc: Subject: "panic: initiate_write_inodeblock_ufs2: already started" on 6.0-RC1 with Intel SRCU42L RAID. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: frank@exit.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2005 06:19:13 -0000 I ran into this panic this evening; PR entered as kern/87861. The filesystem that gets this is on an Intel SRCU42L RAID5 array and that seems to be the important characteristic. This also happens in 5.4-stable, so it's not something special about 6.0. I can reproduce this at will so it will be easy for me to help diagnose it. -- Frank Mayhar frank@exit.com http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 23 08:30:18 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D876016A426 for ; Sun, 23 Oct 2005 08:30:18 +0000 (GMT) (envelope-from kamal_ckk@yahoo.com) Received: from web35705.mail.mud.yahoo.com (web35705.mail.mud.yahoo.com [66.163.179.159]) by mx1.FreeBSD.org (Postfix) with SMTP id B9DB343D49 for ; Sun, 23 Oct 2005 08:30:15 +0000 (GMT) (envelope-from kamal_ckk@yahoo.com) Received: (qmail 18294 invoked by uid 60001); 23 Oct 2005 08:30:15 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=4Wt2Ab9cl0h8qPd52bZgNT4OHUuj54ivLC2kH2KLHLN7HDTfvDZ2Of1zSN/6LTQFrpV1GXQdXEN45P8Uvm2yK8aaF35HMHYPydEoT2qpErVIzK37wxh76+cemzY4G00I+aiu/rtcN/1uBbl42Qu8ZZzwcVfKuwtvgL4DtUBuJGs= ; Message-ID: <20051023083015.18292.qmail@web35705.mail.mud.yahoo.com> Received: from [202.79.62.15] by web35705.mail.mud.yahoo.com via HTTP; Sun, 23 Oct 2005 01:30:15 PDT Date: Sun, 23 Oct 2005 01:30:15 -0700 (PDT) From: kamal kc To: freebsd MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd Subject: in_cksum() for ip packets with multiple mbufs 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, 23 Oct 2005 08:30:19 -0000 i come across this unusual problem. i changed the ip_tos field of the struct ip and computed the checksum by using in_cksum(). when the packet uses only one mbuf the computed checksum is ok but when the packet uses more than one mbuf then the computed checksum is wrong. eg. pinging with payload less than 1470 bytes is ok but with payload greater than 1480 bytes does not work. (the error being bad checksum --that i knew by capturing network packets by ethereal) is it a real problem or i have made some mistake. i put the code before the if_output() in the ip_output() function. help !! kamal __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 23 10:20:57 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 82D8616A41F; Sun, 23 Oct 2005 10:20:57 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from aiolos.otenet.gr (aiolos.otenet.gr [195.170.0.93]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCB0743D45; Sun, 23 Oct 2005 10:20:56 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from flame.pc (aris.bedc.ondsl.gr [62.103.39.226]) by aiolos.otenet.gr (8.13.4/8.13.4/Debian-1) with SMTP id j9NAKs0T006593; Sun, 23 Oct 2005 13:20:55 +0300 Received: from flame.pc (flame [127.0.0.1]) by flame.pc (8.13.4/8.13.4) with ESMTP id j9NAJKew020145; Sun, 23 Oct 2005 13:19:20 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by flame.pc (8.13.4/8.13.4/Submit) id j9NAJKCB020118; Sun, 23 Oct 2005 13:19:20 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Sun, 23 Oct 2005 13:19:20 +0300 From: Giorgos Keramidas To: kamal kc Message-ID: <20051023101919.GA9957@flame.pc> References: <20051023083015.18292.qmail@web35705.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051023083015.18292.qmail@web35705.mail.mud.yahoo.com> Cc: freebsd , freebsd Subject: Re: in_cksum() for ip packets with multiple mbufs 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, 23 Oct 2005 10:20:57 -0000 On 2005-10-23 01:30, kamal kc wrote: > i come across this unusual problem. > > i changed the ip_tos field of the struct ip and computed the checksum > by using in_cksum(). > > when the packet uses only one mbuf the computed checksum is ok but > when the packet uses more than one mbuf then the computed checksum is > wrong. Note that the IP header contains a checksum of the IP header only. A common mistake is to calculate the checksum of data too, which results in an invalid IP header checksum. > eg. pinging with payload less than 1470 bytes is ok but with payload > greater than 1480 bytes does not work. (the error being bad checksum > --that i knew by capturing network packets by ethereal) > > is it a real problem or i have made some mistake. > > i put the code before the if_output() in the ip_output() function. Show us the diff, if possible :) From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 23 11:13:34 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9EF4F16A420 for ; Sun, 23 Oct 2005 11:13:34 +0000 (GMT) (envelope-from kamal_ckk@yahoo.com) Received: from web35701.mail.mud.yahoo.com (web35701.mail.mud.yahoo.com [66.163.179.155]) by mx1.FreeBSD.org (Postfix) with SMTP id B295243D49 for ; Sun, 23 Oct 2005 11:13:33 +0000 (GMT) (envelope-from kamal_ckk@yahoo.com) Received: (qmail 53652 invoked by uid 60001); 23 Oct 2005 11:13:33 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=cavUSpZcLCp8U/AE3PuwW3MRUTseWCcLMnpUtPw0VFKE6OK51hLs/+wHN1Hmb1W3uV65VHAmntmvs76nFuKoHrISw3uw55EGJT13ZlkwENUQk8sEaH+PD5JeQfPiDXM9fZq6KFzBub3HDoWWsvhxPzAqVHpE6qV/eeVyt+VKv/c= ; Message-ID: <20051023111333.53650.qmail@web35701.mail.mud.yahoo.com> Received: from [202.79.62.15] by web35701.mail.mud.yahoo.com via HTTP; Sun, 23 Oct 2005 04:13:33 PDT Date: Sun, 23 Oct 2005 04:13:33 -0700 (PDT) From: kamal kc To: Giorgos Keramidas In-Reply-To: <20051023101919.GA9957@flame.pc> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd , freebsd Subject: Re: in_cksum() for ip packets with multiple mbufs 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, 23 Oct 2005 11:13:34 -0000 > > i changed the ip_tos field of the struct ip and > computed the checksum > > by using in_cksum(). > > > > when the packet uses only one mbuf the computed > checksum is ok but > > when the packet uses more than one mbuf then the > computed checksum is > > wrong. > > Note that the IP header contains a checksum of the > IP header only. > > A common mistake is to calculate the checksum of > data too, which results > in an invalid IP header checksum. ok i made this mistake to calculate the checksum over the entire IP payload. i corrected this and used the ip_hl field ::: /* the argument m is the (struct mbuf *) that * contains the packet data */ void copy_the_memorybuffer(struct mbuf **m) { struct mbuf *mbuf_pointer=*m; struct mbuf **next_packet; next_packet=&mbuf_pointer; struct ip *my_ip_hdr; my_ip_hdr=mtod((*next_packet),struct ip *); my_ip_hdr->ip_tos=64; my_ip_hdr->ip_sum=0; my_ip_hdr->ip_sum= in_cksum((*next_packet),(my_ip_hdr->ip_hl<<2)); ....... } but still it doesn't seem to work. and the problem is still there. i am really confused .. > > eg. pinging with payload less than 1470 bytes is > ok but with payload > > greater than 1480 bytes does not work. (the error > being bad checksum > > --that i knew by capturing network packets by > ethereal) > > > > is it a real problem or i have made some mistake. > > > > i put the code before the if_output() in the > ip_output() function. > > Show us the diff, if possible :) sorry i did not understand what to show here. does it mean to show the packet data captured by the ethereal.. thanks kamal __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 23 12:06:20 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 787A316A41F; Sun, 23 Oct 2005 12:06:20 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from rosebud.otenet.gr (rosebud.otenet.gr [195.170.0.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8000B43D46; Sun, 23 Oct 2005 12:06:18 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from flame.pc (aris.bedc.ondsl.gr [62.103.39.226]) by rosebud.otenet.gr (8.13.4/8.13.4/Debian-1) with SMTP id j9NC6G3M008871; Sun, 23 Oct 2005 15:06:17 +0300 Received: from flame.pc (flame [127.0.0.1]) by flame.pc (8.13.4/8.13.4) with ESMTP id j9NC4gEG030056; Sun, 23 Oct 2005 15:04:42 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by flame.pc (8.13.4/8.13.4/Submit) id j9NC4gmu030055; Sun, 23 Oct 2005 15:04:42 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Sun, 23 Oct 2005 15:04:42 +0300 From: Giorgos Keramidas To: kamal kc Message-ID: <20051023120442.GB29924@flame.pc> References: <20051023101919.GA9957@flame.pc> <20051023111333.53650.qmail@web35701.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051023111333.53650.qmail@web35701.mail.mud.yahoo.com> X-Mailman-Approved-At: Sun, 23 Oct 2005 12:13:31 +0000 Cc: freebsd , freebsd Subject: Re: in_cksum() for ip packets with multiple mbufs 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, 23 Oct 2005 12:06:20 -0000 On 2005-10-23 04:13, kamal kc wrote: > /* the argument m is the (struct mbuf *) that > * contains the packet data > */ > > void copy_the_memorybuffer(struct mbuf **m) > { > struct mbuf *mbuf_pointer=*m; > struct mbuf **next_packet; > > next_packet=&mbuf_pointer; > > struct ip *my_ip_hdr; > my_ip_hdr=mtod((*next_packet),struct ip *); > my_ip_hdr->ip_tos=64; > my_ip_hdr->ip_sum=0; > > my_ip_hdr->ip_sum= > in_cksum((*next_packet),(my_ip_hdr->ip_hl<<2)); > ....... > } Why all this pointer fun? How do you know that it's safe to dereference `m' when you do: struct mbuf *mbuf_pointer=*m; Why are you dereferencing `m' once to obtain mbuf_pointer and then taking the address of that to obtain next_packet, when you could just do: next_packet = m; There are also several other problems with copy_the_memorybuffer() as it's written above: - It's considered bad style to mix declarations and code the way you have done above - It is probably better to return the copy of the mbuf you're fiddling with, instead of modifying in place a parameter of the function. - If you are not *REALLY* copying the data of the mbuf, then the name of copy_the_memorybuffer() is very confusing. - What is the magic constant 64 that is assigned to ip_tos? What you probably want to do is something like: void ip_set_type_of_service(struct mbuf *m) { struct ip *iph; assert(m != NULL); iph = mtod(m, struct ip *); iph->ip_tos = IPTOS_PREC_IMMEDIATE; iph->ip_sum = 0; iph->ip_sum = in_cksum((uint16_t *)iph, iph->ip_hl << 2); } but that's not copying anything. > but still it doesn't seem to work. and the problem > is still there. You have obviously made a lot of changes that we haven't seen yet. Instead of posting snippets here and there, save a copy of the original sources somewhere, then a copy of the new sources, and run diff(1) on the two directories to extract *ALL* the changes. $ cd /usr/src $ diff -ruN src.old/ src/ > /tmp/patchfile and put the patchfile somewhere online where we can have a look at all the changes. From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 23 13:24:04 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3213916A41F; Sun, 23 Oct 2005 13:24:04 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id C442643D45; Sun, 23 Oct 2005 13:24:03 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1ETfpS-0001FJ-Rn; Sun, 23 Oct 2005 15:24:02 +0200 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 23 Oct 2005 15:24:02 +0200 From: Danny Braniss Message-ID: Cc: freebsd-hackers@freebsd.org Subject: iSCSI initiator driver beta version, testers wanted 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, 23 Oct 2005 13:24:04 -0000 this is the second round of tests, the driver is cleaner, handles multiple LUN's ok, and can handle big (256) tagged opening. so far it's been tested on OS: FreeBSD-5.4/6.0 both intel & amd64, UP & SMP targets: NetAPP, Intransa, SanRAD, Cisco, Promise, Equallogic still missing: most important is recovery after a network disconnect. the source is in: ftp://ftp.cs.huji.ac.il/users/danny/freebsd/iscsi-12.tar.bz2 danny From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 24 02:34:46 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D65AF16A41F for ; Mon, 24 Oct 2005 02:34:46 +0000 (GMT) (envelope-from dr2867@pacbell.net) Received: from smtp114.sbc.mail.mud.yahoo.com (smtp114.sbc.mail.mud.yahoo.com [68.142.198.213]) by mx1.FreeBSD.org (Postfix) with SMTP id 702CC43D46 for ; Mon, 24 Oct 2005 02:34:46 +0000 (GMT) (envelope-from dr2867@pacbell.net) Received: (qmail 125 invoked from network); 24 Oct 2005 02:34:45 -0000 Received: from unknown (HELO ?192.168.0.190?) (dr2867.business@pacbell.net@68.126.211.246 with plain) by smtp114.sbc.mail.mud.yahoo.com with SMTP; 24 Oct 2005 02:34:45 -0000 Message-ID: <435C4845.3080503@pacbell.net> Date: Sun, 23 Oct 2005 19:34:45 -0700 From: Daniel Rudy User-Agent: Mozilla/5.0 (X11R6; UNIX; FreeBSD/i386 5.4-RELEASE-p7; en-US; ja-JP; rv:1.7.12) Gecko/20050915 MultiZilla/1.6.2.0c Mnenhy/0.7.2.0 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: ticso@cicely.de References: <43553287.4030907@pacbell.net> <20051018.223845.67882192.imp@bsdimp.com> <20051020110428.GC31913@cicely12.cicely.de> In-Reply-To: <20051020110428.GC31913@cicely12.cicely.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Accessing USB Mass Storage Device X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2005 02:34:47 -0000 At about the time of 10/20/2005 4:04 AM, Bernd Walter stated the following: > On Tue, Oct 18, 2005 at 10:38:45PM -0600, M. Warner Losh wrote: > >>In message: <43553287.4030907@pacbell.net> >> Daniel Rudy writes: >>: >>: When the umass driver is compiled into the kernel, and one inserts a USB >>: mass storage device, how does one access the device descriptors (serial >>: number) while the device is listed as a da device? I would perfer to >>: have the OS do all the work of accessing the hardware. >> >>The serial number can be obtained with devifo. However, since cam >>doesn't hook into the device tree, mapping da number to umass number >>can be tricky in the arbitrary case. >> >>devinfo -v | grep umass >> umass0 pnpinfo vendor=0x054c product=0x014d devclass=0x00 devsubclass=0x00 release=0x0110 sernum="0052450548137984" intclass=0x08 intsubclass= at port=0 interface=0 > > > This is the USB serial number, there might even exist another one > at CAM device layer. > e.g.: > [108]cicely13# camcontrol inquiry -n da -u 1 > pass1: Removable Direct Access SCSI-2 device > pass1: Serial Number ST92163-2000 > pass1: 1.000MB/s transfers > [110]cicely13# devinfo -v | grep umass0 > umass0 pnpinfo vendor=0x0483 product=0x1307 devclass=0x00 devsubclass=0x00 sernum="4710765066451" interface=0 intclass=0x08 intsubclass=0x06 at port=1 > That was one of the first things that I tried. It didn't work. All I got was a blank line. -- Daniel Rudy From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 24 02:55:51 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 79CD916A41F for ; Mon, 24 Oct 2005 02:55:51 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from ant.bwct.de (ant.bwct.de [85.159.14.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id D087343D48 for ; Mon, 24 Oct 2005 02:55:50 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by ant.bwct.de (8.12.11/8.12.11) with ESMTP id j9O2tRBv021426; Mon, 24 Oct 2005 04:55:27 +0200 (CEST) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id j9O2tJgO076609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Oct 2005 04:55:19 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id j9O2tInr049132; Mon, 24 Oct 2005 04:55:18 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id j9O2tE2D049131; Mon, 24 Oct 2005 04:55:14 +0200 (CEST) (envelope-from ticso) Date: Mon, 24 Oct 2005 04:55:14 +0200 From: Bernd Walter To: Daniel Rudy Message-ID: <20051024025513.GE31913@cicely12.cicely.de> References: <43553287.4030907@pacbell.net> <20051018.223845.67882192.imp@bsdimp.com> <20051020110428.GC31913@cicely12.cicely.de> <435C4845.3080503@pacbell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <435C4845.3080503@pacbell.net> X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-5.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 X-Spam-Report: * -3.3 ALL_TRUSTED Did not pass through any untrusted hosts * -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on cicely12.cicely.de Cc: freebsd-hackers@freebsd.org, ticso@cicely.de Subject: Re: Accessing USB Mass Storage Device X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2005 02:55:51 -0000 On Sun, Oct 23, 2005 at 07:34:45PM -0700, Daniel Rudy wrote: > At about the time of 10/20/2005 4:04 AM, Bernd Walter stated the following: > > On Tue, Oct 18, 2005 at 10:38:45PM -0600, M. Warner Losh wrote: > > > >>In message: <43553287.4030907@pacbell.net> > >> Daniel Rudy writes: > >>: > >>: When the umass driver is compiled into the kernel, and one inserts a USB > >>: mass storage device, how does one access the device descriptors (serial > >>: number) while the device is listed as a da device? I would perfer to > >>: have the OS do all the work of accessing the hardware. > >> > >>The serial number can be obtained with devifo. However, since cam > >>doesn't hook into the device tree, mapping da number to umass number > >>can be tricky in the arbitrary case. > >> > >>devinfo -v | grep umass > >> umass0 pnpinfo vendor=0x054c product=0x014d devclass=0x00 devsubclass=0x00 release=0x0110 sernum="0052450548137984" intclass=0x08 intsubclass= at port=0 interface=0 > > > > > > This is the USB serial number, there might even exist another one > > at CAM device layer. > > e.g.: > > [108]cicely13# camcontrol inquiry -n da -u 1 > > pass1: Removable Direct Access SCSI-2 device > > pass1: Serial Number ST92163-2000 > > pass1: 1.000MB/s transfers > > [110]cicely13# devinfo -v | grep umass0 > > umass0 pnpinfo vendor=0x0483 product=0x1307 devclass=0x00 devsubclass=0x00 sernum="4710765066451" interface=0 intclass=0x08 intsubclass=0x06 at port=1 > > > > That was one of the first things that I tried. It didn't work. All I > got was a blank line. Neither the USB serial number nor the CAM one must exist. And if they exist noone garanties that they make sense, in the case above the CAM one sounds more like a chip identification than a unique serial number. However the devinfo umass* line must exist, at least without a serial. To make things more confusing, an USB device may even have different serial numbers in different languages, while it is not often used an USB device can have strings in several languages, the serial number is not an exception here. -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 24 02:56:58 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8893316A41F for ; Mon, 24 Oct 2005 02:56:58 +0000 (GMT) (envelope-from dr2867@pacbell.net) Received: from smtp111.sbc.mail.mud.yahoo.com (smtp111.sbc.mail.mud.yahoo.com [68.142.198.210]) by mx1.FreeBSD.org (Postfix) with SMTP id 2FBAE43D46 for ; Mon, 24 Oct 2005 02:56:58 +0000 (GMT) (envelope-from dr2867@pacbell.net) Received: (qmail 74113 invoked from network); 24 Oct 2005 02:56:57 -0000 Received: from unknown (HELO ?192.168.0.190?) (dr2867.business@pacbell.net@68.126.211.246 with plain) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 24 Oct 2005 02:56:57 -0000 Message-ID: <435C4D7C.7080504@pacbell.net> Date: Sun, 23 Oct 2005 19:57:00 -0700 From: Daniel Rudy User-Agent: Mozilla/5.0 (X11R6; UNIX; FreeBSD/i386 5.4-RELEASE-p7; en-US; ja-JP; rv:1.7.12) Gecko/20050915 MultiZilla/1.6.2.0c Mnenhy/0.7.2.0 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: devinfo(3) 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, 24 Oct 2005 02:56:58 -0000 Consider the following code fragment: (segment 2) Calling code section: /* get devinfo root nexus */ printf("root ptr: %p\n", root); result = usb_devinfo_root(&root); printf("root ptr: %p\n", root); if (result < 0) { usb_devinfo_close(); return(-1); } /* internal: get devinfo root nexus */ int usb_devinfo_root(struct devinfo_dev **root) { printf("root: %p\n", *root); *root = devinfo_handle_to_device(DEVINFO_ROOT_DEVICE); printf("root: %p\n", *root); <---- second call printf if (*root == NULL) { if (usb_param_use_error == TRUE) error("usb.c: usb_devinfo_root: root device not found", errno); if (usb_param_errors_fatal == TRUE) exit(2); return(-1); } return(0); } The problem is that devinfo_handle_to_device always returns a null pointer here. Why? The next code segment, devinfo_handle_to_device returns a proper address. (segment 1) /* get devinfo root nexus */ root = devinfo_handle_to_device(DEVINFO_ROOT_DEVICE); if (root == NULL) { devinfo_free(); return(-1); } output: usb_param_devmode: 255 usb_param_devtype: 255 usb_param_mode_pref: 0 ioctl result: -1 devinfo result: 0 found_ioctl: 0 found_devinfo: 1 <---- first call devinfo device name: umass0 usb_devinfo_open result: 0 root ptr: 0x2815769c root: 0x2815769c root: 0x0 <---- second call usb.c: usb_devinfo_root: root device not found: No such file or directory root ptr: 0x0 Fatal: Unable to get device information Now I have made sure that I have called devinfo_free() during the first call before calling devinfo_init() a second time. I tried calling this code branch on the first time, and it executes properly, so why does it fail on the second call? -- Daniel Rudy From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 24 05:10:08 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B498E16A41F for ; Mon, 24 Oct 2005 05:10:08 +0000 (GMT) (envelope-from andreas@klemm.apsfilter.org) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA60D43D46 for ; Mon, 24 Oct 2005 05:10:07 +0000 (GMT) (envelope-from andreas@klemm.apsfilter.org) Received: from srv1.cosmo-project.de (localhost [IPv6:::1]) by srv1.cosmo-project.de (8.12.10/8.12.10) with ESMTP id j9O5A5JG030362 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 24 Oct 2005 07:10:05 +0200 (CEST) (envelope-from andreas@klemm.apsfilter.org) Received: (from uucp@localhost) by srv1.cosmo-project.de (8.12.10/8.12.10/Submit) with UUCP id j9O5A5bc030361; Mon, 24 Oct 2005 07:10:05 +0200 (CEST) (envelope-from andreas@klemm.apsfilter.org) Received: from titan.klemm.apsfilter.org (localhost.klemm.apsfilter.org [127.0.0.1]) by klemm.apsfilter.org (8.13.4/8.13.4) with ESMTP id j9O53QiS020191; Mon, 24 Oct 2005 07:03:26 +0200 (CEST) (envelope-from andreas@titan.klemm.apsfilter.org) Received: (from andreas@localhost) by titan.klemm.apsfilter.org (8.13.4/8.13.4/Submit) id j9O53POr020190; Mon, 24 Oct 2005 07:03:25 +0200 (CEST) (envelope-from andreas) Date: Mon, 24 Oct 2005 07:03:25 +0200 From: Andreas Klemm To: Sangwoo Shim Message-ID: <20051024050325.GA18276@titan.klemm.apsfilter.org> References: <4352D860.000002.03681@tide.yandex.ru> <20051017144920.GA597@gothic.blackend.org> <4cbd01f40510171008x42b4738bi@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4cbd01f40510171008x42b4738bi@mail.gmail.com> X-Operating-System: FreeBSD 6.0-RC1 X-Disclaimer: A free society is one where it is safe to be unpopular User-Agent: Mutt/1.5.11 Cc: freebsd-hackers@freebsd.org Subject: Re: nvi for serious hacking 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, 24 Oct 2005 05:10:08 -0000 On Tue, Oct 18, 2005 at 02:08:40AM +0900, Sangwoo Shim wrote: > Actually the first thing that I do after minimal installing of new system is > to install vim from the ports tree. (in fact, installing cvsup, of course :-) > I remember once upon a time someone (david?) made a suggestion that nvi in > our tree should be changed to vim-lite(or something.) I'm tend to agree > with that.. (Although vim is GPL'd, nvi is in the src/contrib anyway..) Please no ;-) Although vim has some nice features its definitively different to standard vi behaviour, which can really bitch you in some situations. Most favourite example: I personally still get mad if it comes to the "u" undo key. Standard vi lets you toggle your last change by hitting "u". So I'm used that it doesn't hurt to type the "u" key multiple times. This is very usefull to let your eye browse through a complex change to make an "a/b" comparison. If you do that in vim, then you loose as many last changes as you hit "u" repeatedly. And if you did many changes you loose a serious amount of work. >From my experience you cannot recover from such a mistake. Therefore standard vi is for me much superior, since with it I can get my job done in a reliable manner without fancy side effects. I don't want to start an editor flamewar. I know many people who start to like vi starting with vim. And editors are an issue of taste and experience in use ... Its only a thing to take into consideration whats better. To learn standard vi, thats available everywhere. Or to have the same situation as with emacs ... Vim is still kind of an exot for me. That its standard vi on nearly all Linuxes around still doesn't qualify it enough as standard vi... Andreas /// -- Andreas Klemm - Powered by FreeBSD 6 Need a magic printfilter today ? -> http://www.apsfilter.org/ From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 24 05:27:02 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B94416A420 for ; Mon, 24 Oct 2005 05:27:02 +0000 (GMT) (envelope-from kamal_ckk@yahoo.com) Received: from web35705.mail.mud.yahoo.com (web35705.mail.mud.yahoo.com [66.163.179.159]) by mx1.FreeBSD.org (Postfix) with SMTP id 9BB5A43D45 for ; Mon, 24 Oct 2005 05:27:01 +0000 (GMT) (envelope-from kamal_ckk@yahoo.com) Received: (qmail 63217 invoked by uid 60001); 24 Oct 2005 05:27:00 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=N79z5gnjr6mNXJoLZb81I5twdTYK5SGYObEvqRSJsvupfSO5HIm3hphLWqrC57eUUU+8tJq0wpPhu23wL1g//2v7MbYiSiPTFfu9lJ46SYFKEO2S4LbWvF1RFZv/r5rrgNqxH5/Z0RT73Y8EMn8b3wuQDVLnoYn6//Wp5cc++G8= ; Message-ID: <20051024052700.63215.qmail@web35705.mail.mud.yahoo.com> Received: from [202.79.62.15] by web35705.mail.mud.yahoo.com via HTTP; Sun, 23 Oct 2005 22:27:00 PDT Date: Sun, 23 Oct 2005 22:27:00 -0700 (PDT) From: kamal kc To: Giorgos Keramidas In-Reply-To: <20051023120442.GB29924@flame.pc> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd , freebsd Subject: Re: in_cksum() for ip packets with multiple mbufs 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, 24 Oct 2005 05:27:02 -0000 > > void copy_the_memorybuffer(struct mbuf **m) > > { > > struct mbuf *mbuf_pointer=*m; > > struct mbuf **next_packet; > > > > next_packet=&mbuf_pointer; > > > > struct ip *my_ip_hdr; > > my_ip_hdr=mtod((*next_packet),struct ip *); > > my_ip_hdr->ip_tos=64; > > my_ip_hdr->ip_sum=0; > > > > my_ip_hdr->ip_sum= > > > in_cksum((*next_packet),(my_ip_hdr->ip_hl<<2)); > > ....... > > } > > Why all this pointer fun? How do you know that it's > safe to dereference > `m' when you do: > > struct mbuf *mbuf_pointer=*m; > > Why are you dereferencing `m' once to obtain > mbuf_pointer and then > taking the address of that to obtain next_packet, > when you could > just do: > > next_packet = m; > > There are also several other problems with > copy_the_memorybuffer() as > it's written above: > > - It's considered bad style to mix declarations > and code the way you > have done above > > - It is probably better to return the copy of > the mbuf you're > fiddling with, instead of modifying in place a > parameter of the > function. one thing i would like to ask? does it make any difference if i free the mbuf 'm' passed to if_output() and pass my own mbuf to if_output. is the original mbuf referenced by any other pointers or global variables ?? i couldn't figure out much from the sources. > - If you are not *REALLY* copying the data of > the mbuf, then > the name of copy_the_memorybuffer() is very > confusing. i didn't showed in the above code snippet but actually i am copying the data contained in the mbufs in a character array. my purpose is to compress the data contained in the ip packet > - What is the magic constant 64 that is assigned > to ip_tos? that was just to see that i could actually modify the ip header. > What you probably want to do is something like: > > void > ip_set_type_of_service(struct mbuf *m) > { > struct ip *iph; > > assert(m != NULL); > > iph = mtod(m, struct ip *); > iph->ip_tos = IPTOS_PREC_IMMEDIATE; > iph->ip_sum = 0; > iph->ip_sum = in_cksum((uint16_t *)iph, > iph->ip_hl << 2); > } thanks i will try this code and try to make the code simpler next time. > but that's not copying anything. > > > but still it doesn't seem to work. and the problem > > is still there. > > You have obviously made a lot of changes that we > haven't seen yet. > Instead of posting snippets here and there, save a > copy of the original > sources somewhere, then a copy of the new sources, > and run diff(1) on > the two directories to extract *ALL* the changes. > > $ cd /usr/src > $ diff -ruN src.old/ src/ > /tmp/patchfile > > and put the patchfile somewhere online where we can > have a look at all > the changes. i am new to kernel sources and kernel programming and thank you for informing me on the diff(1). thanks to you that the problem was solved (i don't know if it is completely ok). i found that - i had made mistake in computing checksum. earlier checksum was computed over the whole dat I may soon put up patchfiles on web. thanks. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 24 05:35:33 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E23916A432 for ; Mon, 24 Oct 2005 05:35:33 +0000 (GMT) (envelope-from kamal_ckk@yahoo.com) Received: from web35709.mail.mud.yahoo.com (web35709.mail.mud.yahoo.com [66.163.179.163]) by mx1.FreeBSD.org (Postfix) with SMTP id C117343D49 for ; Mon, 24 Oct 2005 05:35:32 +0000 (GMT) (envelope-from kamal_ckk@yahoo.com) Received: (qmail 48334 invoked by uid 60001); 24 Oct 2005 05:35:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=LwyplNWoknRYIRyr3cEF93UzrDitRl+69AiAaSSDvtRo1KwNwHi6ShUICFtIb5jS6qTP1wybn49SVDefsVzXjCx3bhinvFeG4Uva5+iJZ1nJjCHmTKL35q62lhKRGl/VgSTncnBNX3ZfF9reV5fU7pDrt+ST+HNbiXncTKcWRFA= ; Message-ID: <20051024053532.48332.qmail@web35709.mail.mud.yahoo.com> Received: from [202.79.62.15] by web35709.mail.mud.yahoo.com via HTTP; Sun, 23 Oct 2005 22:35:32 PDT Date: Sun, 23 Oct 2005 22:35:32 -0700 (PDT) From: kamal kc To: Giorgos Keramidas In-Reply-To: <20051023120442.GB29924@flame.pc> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd , freebsd Subject: Re: in_cksum() for ip packets with multiple mbufs 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, 24 Oct 2005 05:35:33 -0000 > > void copy_the_memorybuffer(struct mbuf **m) > > { > > struct mbuf *mbuf_pointer=*m; > > struct mbuf **next_packet; > > > > next_packet=&mbuf_pointer; > > > > struct ip *my_ip_hdr; > > my_ip_hdr=mtod((*next_packet),struct ip *); > > my_ip_hdr->ip_tos=64; > > my_ip_hdr->ip_sum=0; > > > > my_ip_hdr->ip_sum= > > > in_cksum((*next_packet),(my_ip_hdr->ip_hl<<2)); > > ....... > > } > > Why all this pointer fun? How do you know that it's > safe to dereference > `m' when you do: > > struct mbuf *mbuf_pointer=*m; > > Why are you dereferencing `m' once to obtain > mbuf_pointer and then > taking the address of that to obtain next_packet, > when you could > just do: > > next_packet = m; > > There are also several other problems with > copy_the_memorybuffer() as > it's written above: > > - It's considered bad style to mix declarations > and code the way you > have done above > > - It is probably better to return the copy of > the mbuf you're > fiddling with, instead of modifying in place a > parameter of the > function. one thing i would like to ask? does it make any difference if i free the mbuf 'm' passed to if_output() and pass my own mbuf to if_output. is the original mbuf referenced by any other pointers or global variables ?? i couldn't figure out much from the sources. > - If you are not *REALLY* copying the data of > the mbuf, then > the name of copy_the_memorybuffer() is very > confusing. i didn't showed in the above code snippet but actually i am copying the data contained in the mbufs in a character array. my purpose is to compress the data contained in the ip packet > - What is the magic constant 64 that is assigned > to ip_tos? that was just to see that i could actually modify the ip header. > What you probably want to do is something like: > > void > ip_set_type_of_service(struct mbuf *m) > { > struct ip *iph; > > assert(m != NULL); > > iph = mtod(m, struct ip *); > iph->ip_tos = IPTOS_PREC_IMMEDIATE; > iph->ip_sum = 0; > iph->ip_sum = in_cksum((uint16_t *)iph, > iph->ip_hl << 2); > } thanks i will try this code and try to make the code simpler next time. > but that's not copying anything. > > > but still it doesn't seem to work. and the problem > > is still there. > > You have obviously made a lot of changes that we > haven't seen yet. i did not put the whole code because i am a bit lazy and the code is cumbersome. and i thought that it was causing the problem. > Instead of posting snippets here and there, save a > copy of the original > sources somewhere, then a copy of the new sources, > and run diff(1) on > the two directories to extract *ALL* the changes. > > $ cd /usr/src > $ diff -ruN src.old/ src/ > /tmp/patchfile > > and put the patchfile somewhere online where we can > have a look at all > the changes. i am new to kernel sources and kernel programming and thank you for informing me on the diff(1). thanks to you that the problem was solved (i don't know if it is completely ok). i found that - i had made mistake in computing checksum. earlier checksum was computed over the whole data but now i calculate checksum over the header only. - byte ordering. tell me one thing isn't the byte order of the ip_id in network byte order in the mbuf when passed to the if_output() ?? i had to use the htons() to ip_id before computing the checksum - final thing does this makes any difference (calling the htons() twice): ip->ip_id=htons(ip->ip_id); ip->ip_id=htons(ip->ip_id); I will try put up patchfiles on web. thanks very much, kamal __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 24 06:07:06 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3512E16A41F; Mon, 24 Oct 2005 06:07:06 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: from mortis.over-yonder.net (adsl-157-21-180.jan.bellsouth.net [70.157.21.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD3EF43D48; Mon, 24 Oct 2005 06:07:05 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: by mortis.over-yonder.net (Postfix, from userid 100) id B2ADA20F56; Mon, 24 Oct 2005 01:07:04 -0500 (CDT) Date: Mon, 24 Oct 2005 01:07:04 -0500 From: "Matthew D. Fuller" To: Andreas Klemm Message-ID: <20051024060704.GW66908@over-yonder.net> References: <4352D860.000002.03681@tide.yandex.ru> <20051017144920.GA597@gothic.blackend.org> <4cbd01f40510171008x42b4738bi@mail.gmail.com> <20051024050325.GA18276@titan.klemm.apsfilter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051024050325.GA18276@titan.klemm.apsfilter.org> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.9i-fullermd.2 Cc: freebsd-hackers@freebsd.org, Sangwoo Shim Subject: Re: nvi for serious hacking 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, 24 Oct 2005 06:07:06 -0000 On Mon, Oct 24, 2005 at 07:03:25AM +0200 I heard the voice of Andreas Klemm, and lo! it spake thus: > > Most favourite example: > I personally still get mad if it comes to the "u" undo key. I miss :N. You have to :split and then :n separately. > Standard vi lets you toggle your last change by hitting "u". > > From my experience you cannot recover from such a mistake. You need redo (^R) to do the same in vim. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 24 09:45:42 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3AA6316A41F for ; Mon, 24 Oct 2005 09:45:42 +0000 (GMT) (envelope-from dr2867@pacbell.net) Received: from smtp106.sbc.mail.mud.yahoo.com (smtp106.sbc.mail.mud.yahoo.com [68.142.198.205]) by mx1.FreeBSD.org (Postfix) with SMTP id CD79A43D46 for ; Mon, 24 Oct 2005 09:45:41 +0000 (GMT) (envelope-from dr2867@pacbell.net) Received: (qmail 39950 invoked from network); 24 Oct 2005 09:45:41 -0000 Received: from unknown (HELO ?192.168.0.190?) (dr2867.business@pacbell.net@68.126.211.246 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 24 Oct 2005 09:45:41 -0000 Message-ID: <435CAD47.7000409@pacbell.net> Date: Mon, 24 Oct 2005 02:45:43 -0700 From: Daniel Rudy User-Agent: Mozilla/5.0 (X11R6; UNIX; FreeBSD/i386 5.4-RELEASE-p7; en-US; ja-JP; rv:1.7.12) Gecko/20050915 MultiZilla/1.6.2.0c Mnenhy/0.7.2.0 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: ticso@cicely.de References: <43553287.4030907@pacbell.net> <20051018.223845.67882192.imp@bsdimp.com> <20051020110428.GC31913@cicely12.cicely.de> <435C4845.3080503@pacbell.net> <20051024025513.GE31913@cicely12.cicely.de> In-Reply-To: <20051024025513.GE31913@cicely12.cicely.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Accessing USB Mass Storage Device X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2005 09:45:42 -0000 At about the time of 10/23/2005 7:55 PM, Bernd Walter stated the following: > On Sun, Oct 23, 2005 at 07:34:45PM -0700, Daniel Rudy wrote: > >>At about the time of 10/20/2005 4:04 AM, Bernd Walter stated the following: >> >>>On Tue, Oct 18, 2005 at 10:38:45PM -0600, M. Warner Losh wrote: >>> >>> >>>>In message: <43553287.4030907@pacbell.net> >>>> Daniel Rudy writes: >>>>: >>>>: When the umass driver is compiled into the kernel, and one inserts a USB >>>>: mass storage device, how does one access the device descriptors (serial >>>>: number) while the device is listed as a da device? I would perfer to >>>>: have the OS do all the work of accessing the hardware. >>>> >>>>The serial number can be obtained with devifo. However, since cam >>>>doesn't hook into the device tree, mapping da number to umass number >>>>can be tricky in the arbitrary case. >>>> >>>>devinfo -v | grep umass >>>>umass0 pnpinfo vendor=0x054c product=0x014d devclass=0x00 devsubclass=0x00 release=0x0110 sernum="0052450548137984" intclass=0x08 intsubclass= at port=0 interface=0 >>> >>> >>>This is the USB serial number, there might even exist another one >>>at CAM device layer. >>>e.g.: >>>[108]cicely13# camcontrol inquiry -n da -u 1 >>>pass1: Removable Direct Access SCSI-2 device >>>pass1: Serial Number ST92163-2000 >>>pass1: 1.000MB/s transfers >>>[110]cicely13# devinfo -v | grep umass0 >>> umass0 pnpinfo vendor=0x0483 product=0x1307 devclass=0x00 devsubclass=0x00 sernum="4710765066451" interface=0 intclass=0x08 intsubclass=0x06 at port=1 >>> >> >>That was one of the first things that I tried. It didn't work. All I >>got was a blank line. > > > Neither the USB serial number nor the CAM one must exist. > And if they exist noone garanties that they make sense, in the case > above the CAM one sounds more like a chip identification than a unique > serial number. > However the devinfo umass* line must exist, at least without a serial. > To make things more confusing, an USB device may even have different > serial numbers in different languages, while it is not often used an > USB device can have strings in several languages, the serial number > is not an exception here. > Now I read somewhere (I think it was the USB standard documents in fact, that a USB flash drive *MUST* have a unique serial number because of Windows. Anyways, I've written software to scan the devinfo(3) device tree and parse out the data from the umass string. Seems to work quite well, except the auto search mode which is in another email posted to the list. I figured when I was looking at other people's code that there could be multiple languages because all of the code that I have found checks the language id for the strings. Seems US-EN is 0x0409. -- Daniel Rudy From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 24 09:46:45 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 957CF16A41F; Mon, 24 Oct 2005 09:46:45 +0000 (GMT) (envelope-from corecode@fs.ei.tum.de) Received: from stella.fs.ei.tum.de (stella.fs.ei.tum.de [129.187.54.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED31143D48; Mon, 24 Oct 2005 09:46:40 +0000 (GMT) (envelope-from corecode@fs.ei.tum.de) Received: from localhost (localhost [127.0.0.1]) by localhost.fs.ei.tum.de (Postfix) with ESMTP id CB1418DC3F; Mon, 24 Oct 2005 11:46:38 +0200 (CEST) Received: from stella.fs.ei.tum.de ([127.0.0.1]) by localhost (stella [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 31710-05; Mon, 24 Oct 2005 11:46:38 +0200 (CEST) Received: from [10.150.180.180] (r180180.olydorf.swh.mhn.de [10.150.180.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by stella.fs.ei.tum.de (Postfix) with ESMTP id 40BDA8D759; Mon, 24 Oct 2005 11:46:38 +0200 (CEST) Message-ID: <435CAD9C.3010407@fs.ei.tum.de> Date: Mon, 24 Oct 2005 11:47:08 +0200 From: Simon 'corecode' Schubert User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050912) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Matthew D. Fuller" References: <4352D860.000002.03681@tide.yandex.ru> <20051017144920.GA597@gothic.blackend.org> <4cbd01f40510171008x42b4738bi@mail.gmail.com> <20051024050325.GA18276@titan.klemm.apsfilter.org> <20051024060704.GW66908@over-yonder.net> In-Reply-To: <20051024060704.GW66908@over-yonder.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at fs.ei.tum.de Cc: freebsd-hackers@freebsd.org, Sangwoo Shim Subject: Re: nvi for serious hacking 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, 24 Oct 2005 09:46:45 -0000 Matthew D. Fuller wrote: >>Most favourite example: >>I personally still get mad if it comes to the "u" undo key. > I miss :N. You have to :split and then :n separately. Do you mean :sn? cheers simon -- Serve - BSD +++ RENT this banner advert +++ ASCII Ribbon /"\ Work - Mac +++ space for low $$$ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \ From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 24 09:50:34 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 72C0A16A41F; Mon, 24 Oct 2005 09:50:34 +0000 (GMT) (envelope-from corecode@fs.ei.tum.de) Received: from stella.fs.ei.tum.de (stella.fs.ei.tum.de [129.187.54.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1950843D55; Mon, 24 Oct 2005 09:50:32 +0000 (GMT) (envelope-from corecode@fs.ei.tum.de) Received: from localhost (localhost [127.0.0.1]) by localhost.fs.ei.tum.de (Postfix) with ESMTP id 33B8E8DC3F; Mon, 24 Oct 2005 11:50:31 +0200 (CEST) Received: from stella.fs.ei.tum.de ([127.0.0.1]) by localhost (stella [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 31742-06; Mon, 24 Oct 2005 11:50:31 +0200 (CEST) Received: from [10.150.180.180] (r180180.olydorf.swh.mhn.de [10.150.180.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by stella.fs.ei.tum.de (Postfix) with ESMTP id C75CF8D759; Mon, 24 Oct 2005 11:50:30 +0200 (CEST) Message-ID: <435CAE85.2050509@fs.ei.tum.de> Date: Mon, 24 Oct 2005 11:51:01 +0200 From: Simon 'corecode' Schubert User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050912) X-Accept-Language: en-us, en MIME-Version: 1.0 To: kamal kc References: <20051024053532.48332.qmail@web35709.mail.mud.yahoo.com> In-Reply-To: <20051024053532.48332.qmail@web35709.mail.mud.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at fs.ei.tum.de Cc: Giorgos Keramidas , freebsd , freebsd Subject: Re: in_cksum() for ip packets with multiple mbufs 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, 24 Oct 2005 09:50:34 -0000 kamal kc wrote: > - final thing does this makes any difference > (calling the htons() twice): > > ip->ip_id=htons(ip->ip_id); > ip->ip_id=htons(ip->ip_id); on little endian machines: yes. on big endian machines: no. So don't do it. :) freebsd has several fields of the ip headerin host byte order to speed up access. they get converted to network byte order at a very late stage of the ip output path. cheers simon -- Serve - BSD +++ RENT this banner advert +++ ASCII Ribbon /"\ Work - Mac +++ space for low $$$ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \ From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 24 12:33:06 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6588F16A41F; Mon, 24 Oct 2005 12:33:06 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from ant.bwct.de (ant.bwct.de [85.159.14.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E6B943D5A; Mon, 24 Oct 2005 12:33:04 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by ant.bwct.de (8.12.11/8.12.11) with ESMTP id j9OCX2fJ023697; Mon, 24 Oct 2005 14:33:03 +0200 (CEST) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id j9OCWu5V080828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Oct 2005 14:32:57 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id j9OCWuml051168; Mon, 24 Oct 2005 14:32:56 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id j9OCWtnE051167; Mon, 24 Oct 2005 14:32:55 +0200 (CEST) (envelope-from ticso) Date: Mon, 24 Oct 2005 14:32:55 +0200 From: Bernd Walter To: Frank Behrens Message-ID: <20051024123254.GI31913@cicely12.cicely.de> References: <200510211216.37814.jhb@freebsd.org> <200510221516.j9MFGnqT026691@pinky.frank-behrens.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200510221516.j9MFGnqT026691@pinky.frank-behrens.de> X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-5.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 X-Spam-Report: * -3.3 ALL_TRUSTED Did not pass through any untrusted hosts * -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on cicely12.cicely.de Cc: freebsd-hackers@freebsd.org Subject: Re: How disable attachment of sio(4) driver to device? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2005 12:33:06 -0000 On Sat, Oct 22, 2005 at 05:16:49PM +0200, Frank Behrens wrote: > Warner, John and others, > > thanks for your fast responses. > > John Baldwin wrote on 21 Oct 2005 12:16: > > But you could hack the sio(4) driver to check its IO port and return ENXIO if > > it has a certain value, for example. > > Yes, this would not be a problem for me. But I want to publish my > driver as port and make it for the user as easy as possible. That > includes not the need for building a new kernel. > > M. Warner Losh wrote on 21 Oct 2005 10:06: > > Another "soltution" is to not have sio in your kernel while you are > > debugging your driver. > > Well, you used already the quotes. It is not an option for me, > because my system has no keyboard and monitor attached and the serial > console is my only way to see the panic messages. ;-) > > > Another solution would be to have your driver use the tty layer > > instead of banging the hardware directly, if that is compatible with > > the goals of your driver. This solution isn't in quotes because for > > some class of devices (say a keyboard driver for a sun or apple newton > > keyboard that does serial), it might be the right one. > > Hm, this looks even more complicated and has more overhead. To show > shortly my requirements: The protocol is for an eib driver, (further > information on http://www.sax.de/~frank/eib4bsd/), it uses 9600 baud > on serial line. If the PC wants to send a telegram it resets RTS and > has to poll CTS. If CTS is active the transmission of one byte is > possible. If the last bit is sent (transceiver shift empty!) the PC > sets RTS and waits until CTS is inactive. Then a new handshake can > start and a transmission of about 30 bytes must be finished in 130 > ms. IMHO this can be handled only in an interrupt routine with low > overhead. PEI-16 design is evil IMO and PEI-10 capable BCU are less common. I already planed support for EIB using Weinzierl's USB hardware, it's just a matter of time. I dislike the protocol beeing based on UHID, but that's how it is standardized, at least other EIB USB devices are likly to work as well. Usually UHID is prefered so people don't have to write Windows-driver. -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 24 12:46:17 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E00B16A420 for ; Mon, 24 Oct 2005 12:46:17 +0000 (GMT) (envelope-from frank@pinky.sax.de) Received: from pinky.frank-behrens.de (pinky.frank-behrens.de [82.139.199.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0259143D53 for ; Mon, 24 Oct 2005 12:46:14 +0000 (GMT) (envelope-from frank@pinky.sax.de) Received: from [192.168.20.31] (pulse.behrens [192.168.20.31]) by pinky.frank-behrens.de (8.13.4/8.13.4) with ESMTP/MSA id j9OCk5YV018166; Mon, 24 Oct 2005 14:46:05 +0200 (CEST) (envelope-from frank@pinky.sax.de) Message-Id: <200510241246.j9OCk5YV018166@pinky.frank-behrens.de> From: "Frank Behrens" To: Bernd Walter Date: Mon, 24 Oct 2005 14:46:03 +0200 MIME-Version: 1.0 Priority: normal In-reply-to: <20051024123254.GI31913@cicely12.cicely.de> References: <200510221516.j9MFGnqT026691@pinky.frank-behrens.de> X-mailer: Pegasus Mail for Windows (4.30 public beta 1, DE v4.30 PB1 (for PB1)) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Cc: freebsd-hackers@freebsd.org Subject: Re: How disable attachment of sio(4) driver to device? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2005 12:46:17 -0000 Bernd Walter wrote on 24 Oct 2005 14:32: > PEI-16 design is evil IMO and PEI-10 capable BCU are less common. Yes, of course. I do not understand how an engineer could invent such a "protocol" like PEI-16. But now I have an RS-232 interface with BCU1 and I want to use it. It worked well for me for some years with FreeBSD-4.2 and yesterday I updated my other machine to newest 6.0 and went into "production" with my new driver. -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available. From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 24 13:45:24 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A447B16A41F; Mon, 24 Oct 2005 13:45:24 +0000 (GMT) (envelope-from nocool@263.net) Received: from smtp.263.net (smtp.x263.net [211.150.96.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 018C243D48; Mon, 24 Oct 2005 13:45:23 +0000 (GMT) (envelope-from nocool@263.net) Received: from iscas-zfw728iit (smtp1 [127.0.0.1]) by smtp.263.net (Postfix) with ESMTP id 31E53F02; Mon, 24 Oct 2005 21:45:27 +0800 (CST) (envelope-from nocool@263.net) X-Originating-IP: [159.226.5.225] Date: Mon, 24 Oct 2005 21:45:57 +0800 From: "nocool" To: "das" , "freebsd-hackers" , "freebsd-current" , "delphij" X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Message-Id: <20051024134527.31E53F02@smtp.263.net> Cc: Subject: Re: Re: where to release proc.p_stats 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, 24 Oct 2005 13:45:24 -0000 SSBkaWRuJ3Qgbm90aWNlIHRoZSBVTUFfWk9ORV9OT0ZSRUUgZmxhZyBvZiBwcm9jX3pvbmUsIHNv IHByb2MgaXRlbXMgd2lsbCBub3QgYmUgcmVjeWNsZWQuDQpCdXQgdGhlIGV4aXN0ZW5jZSBvZiBw cm9jX2ZpbmkgcmVhbGx5IGNvbmZ1c2VkIG1lLg0KDQpBbm90aGVyIHF1ZXN0aW9uPw0KDQpDYW4g bWVtb3J5IG1hbmFnZW1lbnQgc3lzdGVtIHV0aWxpemUgQ09XIHRvIHN1cHBseSB6ZXJvLWZpbGxl ZCBwYWdlIHRvIGtlcm5lbCBvciB1c2VyIHByb2Nlc3MuDQpUaGF0IGlzIHRvIHNheToNCldoZW4g cHJvY2Vzc2VzIHdhbnQgemVyb2VkIHBhZ2UsIHdlIGdpdmUgdGhlbSBhIG1pcnJvciBvZiBvbmUg YWxyZWFkeSB6ZXJvZCBwYWdlcy4gSWYgdGhleSBqdXN0DQpyZWFkLCB0aGV5IGNhbiByZWFkIHpl cm8gZnJvbSB0aGUgYmFjayBwYWdlLiANCldlIG5lZWRuJ3QgcmVhbGx5IGFsbG9jIGEgbmV3IHpl cm8tZmlsbGVkIHBhZ2UgdW50aWwgdGhleSBtb2RpZnkgdGhlIHBhZ2UuDQpTbyB3ZSBjYW4gc2F2 aW5nIG1hbnkgdGltZSBmcm9tIGZpbGxpbmcgcGFnZXMgd2l0aCB6ZXJvLCBpZiBzb21lIHByb2Nl c3MganVzdCB3YW50IHJlYWQgZnJvbSB0aGVtLg0KDQpDYW4gdGhpcyBzdWdnZXN0aW9uIHdvcms/ IA0KPk9uIEZyaWRheSAyMSBPY3RvYmVyIDIwMDUgMDQ6MzIgcG0sIERhdmlkIFNjaHVsdHogd3Jv dGU6DQo+PiBPbiBGcmksIE9jdCAyMSwgMjAwNSwgSm9obiBCYWxkd2luIHdyb3RlOg0KPj4gPiBP biBGcmlkYXkgMjEgT2N0b2JlciAyMDA1IDA5OjEzIGFtLCBub2Nvb2wgd3JvdGU6DQo+PiA+ID4g ZnJlZWJzZC1oYWNrZXJzge+BvIxoZWxsbw0KPj4gPiA+DQo+PiA+ID4gCVF1ZXN0aW9uIGFib3V0 IDUuNCBrZXJuZWwgc291cmNlIGNvZGUuDQo+PiA+ID4gCUkgaGF2ZSBzb21lIHF1ZXN0aW9uIGFi b3V0IHN0cnVzdCBwcm9jJ3MgaW5pdGlhbGl6ZS4gS2VybmVsIHVzZQ0KPj4gPiA+IHByb2Nfem9u ZSB0byBhbGxvY2F0ZSBwcm9jIGl0ZW1zIGFuZCBpbml0aWFsaXplIHRoZW0gd2l0aCBwcm9jX2lu aXQNCj4+ID4gPiAoc3lzXGtlcm5ca2Vybl9wcm9jLmMpIGZ1bmN0aW9uLiBJbiB0aGlzIGZ1bmN0 aW9uLCB3ZSBjYW4gZmluZCB0aGUNCj4+ID4gPiBmaWVsZCBwcm9jLnBfc3RhdHMgaXMgYWxsb2Nh dGVkIHdpdGggcHN0YXRzX2FsbG9jKCksIGFzDQo+PiA+ID4NCj4+ID4gPiBwLT5wX3N0YXRzID0g cHN0YXRzX2FsbG9jKCk7DQo+PiA+ID4NCj4+ID4gPiBhbmQgcHN0YXRzX2FsbG9jIGlzIHJlYWxp emVkIGFzDQo+PiA+ID4NCj4+ID4gPiBtYWxsb2Moc2l6ZW9mKHN0cnVjdCBwc3RhdHMpLCBNX1NV QlBST0MsIE1fWkVST3xNX1dBSVRPSyk7DQo+PiA+ID4NCj4+ID4gPiBCdXQgSSBjYW4ndCBmaW5k IHdoZXJlIHRoaXMgZmllbGQgaXMgZnJlZWQuIElmIGl0IHdpbGwgbm90IGJlIHJlbGVhc2UsDQo+ PiA+ID4gd2lsbCB0aGVyZSBiZSBtZW1vcnkgbGVha2FnZT8NCj4+ID4NCj4+ID4gSGVoLCBkYXNA IGZvcmdvdCB0byBjYWxsIHBzdGF0c19mcmVlKCkgd2hlbiBoZSBkaWQgdGhlIGNoYW5nZXMuICBU aGUNCj4+ID4gcmVhc29uIGlzIHByb2JhYmx5IGJlY2F1c2UgcHJvY19maW5pKCkgZG9lc24ndCBk byBhbnl0aGluZyB1c2VmdWwgYmVjYXVzZQ0KPj4gPiB3ZSBuZXZlciByZWN5Y2xlIHByb2Mgc3Ry dWN0cy4gIFdlIHNob3VsZCBwcm9iYWJseSBhdCBsZWFzdCBhZGQgdGhlDQo+PiA+IG9wZXJhdGlv bnMgdGhlcmUgdGhvdWdoIGZvciBkb2N1bWVudGF0aW9uIHB1cnBvc2VzLiAgU29tZXRoaW5nIGxp a2UgdGhpcw0KPj4gPiB3b3VsZCB3b3JrIEkgdGhpbms6DQo+Pg0KPj4gSSBkaWRuJ3QgcHV0IGlu IHRoZSBjYWxsIGJlY2F1c2Ugd2UgbmV2ZXIgZnJlZSBwcm9jIHN0cnVjdHVyZXMsIGJ1dA0KPj4g ZG9jdW1lbnRpbmcgd2hhdCBzaG91bGQgaGFwcGVuIGlmIHdlIGV2ZXIgZG8gZnJlZSB0aGVtIGlz IGEgZ29vZA0KPj4gaWRlYS4gIFRoZXJlJ3MgYSBmYWlyIGFtb3VudCBvZiBvdGhlciBjbGVhbnVw IHRoYXQgbmVlZHMgdG8gaGFwcGVuDQo+PiBhcyB3ZWxsLCB3aGljaCB5b3UgY2FuIHByb2JhYmx5 IGZpbmQgaW4gdGhlIENWUyBoaXN0b3J5LiAgKElJUkMsDQo+PiBJJ20gZ3VpbHR5IG9mIHJlbW92 aW5nIHRoZSBjb2RlIGF0IGEgdGltZSB3aGVuIG1vcmUgdGhpbmdzIGRlcGVuZGVkDQo+PiB1cG9u IHN0cnVjdCBwcm9jIGJlaW5nIHR5cGUgc2FmZS4gIEFyZSB0aGVyZSBhbnkgcmVtYWluaW5nIHJl YXNvbnMNCj4+IHdoeSB3ZSBjYW4ndCBmcmVlIHN0cnVjdCBwcm9jcyBhdCB0aGlzIHBvaW50PykN Cj4+DQo+PiBCeSB0aGUgd2F5LCB0aGVyZSdzIG5vIHJlYXNvbiB3aHkgd2UgY2FuJ3QgZm9sZCBz dHJ1Y3QgcHN0YXRzIGludG8NCj4+IHN0cnVjdCBwcm9jIHNvIHdlIGRvbid0IGhhdmUgdG8gYWxs b2NhdGUgYW5kIGZyZWUgaXQgYXQgYWxsLg0KPj4gSXQncyBuZXZlciBzaGFyZWQsIHNvIHRoZSBl eHRyYSBsZXZlbCBvZiBpbmRpcmVjdGlvbiBqdXN0IGFkZHMgb3ZlcmhlYWQuDQo+PiBUaGUgbWFp biByZWFzb24gSSBkaWRuJ3QgbWFrZSB0aGlzIGNoYW5nZSBlYXJsaWVyIHdhcyB0byBtYWludGFp biBiaW5hcnkNCj4+IGNvbXBhdGliaWxpdHkgd2hlbiBJIGJhY2twb3J0ZWQgbXkgVS1hcmVhIGNo YW5nZXMgdG8gLVNUQUJMRS4NCj4NCj5Mb29rcyBsaWtlIHNvbWUgb2YgdGhlIGZ1bmN0aW9ucyAo dm1fZGlzcG9zZV9wcm9jKCkgYW5kIHNjaGVkX2Rlc3Ryb3lwcm9jKCkpIA0KPmhhdmUgdmFuaXNo ZWQsIHNvIHRoaXMgaXMgYWxsIHRoYXQgd291bGQgYmUgaW4gdGhlcmUgbm93Og0KPg0KPkluZGV4 OiBrZXJuX3Byb2MuYw0KPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj5SQ1MgZmlsZTogL3Vzci9jdnMvc3JjL3N5cy9r ZXJuL2tlcm5fcHJvYy5jLHYNCj5yZXRyaWV2aW5nIHJldmlzaW9uIDEuMjMyDQo+ZGlmZiAtdSAt cjEuMjMyIGtlcm5fcHJvYy5jDQo+LS0tIGtlcm5fcHJvYy5jIDIgT2N0IDIwMDUgMjM6Mjc6NTYg LTAwMDAgICAgICAgMS4yMzINCj4rKysga2Vybl9wcm9jLmMgMjEgT2N0IDIwMDUgMjE6MjE6NDUg LTAwMDANCj5AQCAtMTk2LDggKzE5NiwxNyBAQA0KPiBzdGF0aWMgdm9pZA0KPiBwcm9jX2Zpbmko dm9pZCAqbWVtLCBpbnQgc2l6ZSkNCj4gew0KPisjaWZkZWYgbm90bm93DQo+KyAgICAgICBzdHJ1 Y3QgcHJvYyAqcDsNCj4NCj4rICAgICAgIHAgPSAoc3RydWN0IHByb2MgKiltZW07DQo+KyAgICAg ICBwc3RhdHNfZnJlZShwLT5wX3N0YXRzKTsNCj4rICAgICAgIGtzZWdycF9mcmVlKEZJUlNUX0tT RUdSUF9JTl9QUk9DKHApKTsNCj4rICAgICAgIHRocmVhZF9mcmVlKEZJUlNUX1RIUkVBRF9JTl9Q Uk9DKHApKTsNCj4rICAgICAgIG10eF9kZXN0cm95KCZwLT5wX210eCk7DQo+KyNlbHNlDQo+ICAg ICAgICBwYW5pYygicHJvYyByZWNsYWltZWQiKTsNCj4rI2VuZGlmDQo+IH0NCj4NCj4gLyoNCj4N Cj4NCj4tLSANCj5Kb2huIEJhbGR3aW4gPGpoYkBGcmVlQlNELm9yZz4gIDw+PCAgaHR0cDovL3d3 dy5GcmVlQlNELm9yZy9+amhiLw0KPiJQb3dlciBVc2VycyBVc2UgdGhlIFBvd2VyIHRvIFNlcnZl IiAgPSAgaHR0cDovL3d3dy5GcmVlQlNELm9yZw0KDQo9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9 ID0gPSA9ID0gPSA9ID0NCgkJCQ0KDQqhoaGhoaGhoaGhoaGhoaGh1sINCsDxo6ENCiANCgkJCQkg DQqhoaGhoaGhoaGhoaGhoaGhbm9jb29sDQqhoaGhoaGhoaGhoaGhoaGhbm9jb29sQDI2My5uZXQN CqGhoaGhoaGhoaGhoaGhoaGhoaGhMjAwNS0xMC0yMg0KDQo= From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 24 01:48:58 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E485416A41F for ; Mon, 24 Oct 2005 01:48:58 +0000 (GMT) (envelope-from jason.harmening@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F27443D46 for ; Mon, 24 Oct 2005 01:48:58 +0000 (GMT) (envelope-from jason.harmening@gmail.com) Received: by zproxy.gmail.com with SMTP id 40so539876nzk for ; Sun, 23 Oct 2005 18:48:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:to:subject:date:user-agent:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:from; b=BUWnSzNYDsqA00GLUqp3ScLcirxYv7sSt18CwGjcRD6TI8UIU1rTO5T5HY3a8hurOp7KcPM8eviQJX3xQv4MrwcSQDS0zMMW9wZVV5W4ecTvtiV7GgH3mGqdFp3YT0IdzOpfqktmYgxWbVzxEc3Wzv3vH2rr/ON3fsN3afO4URQ= Received: by 10.37.13.79 with SMTP id q79mr5876045nzi; Sun, 23 Oct 2005 18:48:57 -0700 (PDT) Received: from ?192.168.0.3? ( [70.112.17.171]) by mx.gmail.com with ESMTP id 18sm3576722nzo.2005.10.23.18.48.55; Sun, 23 Oct 2005 18:48:57 -0700 (PDT) To: freebsd-hackers@freebsd.org Date: Sun, 23 Oct 2005 20:49:16 -0500 User-Agent: KMail/1.8.2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510232049.16352.Jason.Harmening@gmail.com> From: Jason Harmening X-Mailman-Approved-At: Mon, 24 Oct 2005 13:48:03 +0000 Subject: Native ATAPI MO driver 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, 24 Oct 2005 01:48:59 -0000 Hi, I have a 2.3G Fujitsu MO drive, and I've gotten tired of using atapicam to access it. I'm thinking of writing a native ATAPI driver that could be added to the kernel through a configuration line like: device atapimo I've been doing a little work to see how feasible this is--the kernel already defines the ATA_ATAPI_TYPE_OPTICAL device type that is received from my drive during probing. But ATA_ATAPI_TYPE_OPTICAL isn't actually used anywhere, and there is no driver that can actually recognize and attach to an ATAPI MO drive. I modified the atapifd driver (src/sys/dev/ata/atapi-fd.c) to also recognize ATA_ATAPI_TYPE_OPTICAL, and my drive was actually recognized during probing as afd0, but afd_attach returned an error. It looks as if afd_sense() was failing, which I'm guessing is because ATAPI MO drives (or mine, at least) use a different capabilities page code and/or capabilities page structure than ATAPI floppies. The atapi-fd driver uses 0x5 for its "Capabilities and Mechanical Status" page code, while everything else (atapi-cd, atapi-tape) uses 0x2a. All three drivers have distinctly different structures for this page. So I'm wondering: do ATAPI MO drives use a capabilities page code/structure more like CD/DVD drives, or do they have their own unique ATAPI page structure? If so, where can I find a document outlining the structure? I've found loads of documents detailing the page structure for CD/DVD drives, but nothing for MO drives (or floppies or tape drives for that matter). Also, beyond the capabilities page, are there any other special considerations I'd need to make for an MO driver? Any answers would be really awesome. Thanks, Jason Harmening From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 24 07:31:20 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E7E3716A41F; Mon, 24 Oct 2005 07:31:20 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from rosebud.otenet.gr (rosebud.otenet.gr [195.170.0.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2CB8043D45; Mon, 24 Oct 2005 07:31:19 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from flame.pc (aris.bedc.ondsl.gr [62.103.39.226]) by rosebud.otenet.gr (8.13.4/8.13.4/Debian-1) with SMTP id j9O7VHZg012074; Mon, 24 Oct 2005 10:31:18 +0300 Received: from flame.pc (flame [127.0.0.1]) by flame.pc (8.13.4/8.13.4) with ESMTP id j9O7TfaT001965; Mon, 24 Oct 2005 10:29:41 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by flame.pc (8.13.4/8.13.4/Submit) id j9O7TfTN001964; Mon, 24 Oct 2005 10:29:41 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Mon, 24 Oct 2005 10:29:41 +0300 From: Giorgos Keramidas To: kamal kc Message-ID: <20051024072941.GA1944@flame.pc> References: <20051023120442.GB29924@flame.pc> <20051024052700.63215.qmail@web35705.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051024052700.63215.qmail@web35705.mail.mud.yahoo.com> X-Mailman-Approved-At: Mon, 24 Oct 2005 13:48:03 +0000 Cc: freebsd , freebsd Subject: Re: in_cksum() for ip packets with multiple mbufs 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, 24 Oct 2005 07:31:21 -0000 On 2005-10-23 22:27, kamal kc wrote: > one thing i would like to ask? > > does it make any difference if i free the mbuf 'm' passed to > if_output() and pass my own mbuf to if_output. > > is the original mbuf referenced by any other pointers or global > variables ?? If you are hooking your own functions right before if_output, then it shouldn't be a problem. > > - If you are not *REALLY* copying the data of the mbuf, then the > > name of copy_the_memorybuffer() is very confusing. > > i didn't showed in the above code snippet but actually i am copying > the data contained in the mbufs in a character array. AH! That makes more sense then :) > thanks to you that the problem was solved (i don't > know if it is completely ok). i found that > - i had made mistake in computing checksum. > earlier checksum was computed over the whole dat Nice. Glad to know it's fixed now. From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 24 14:28:31 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E82316A41F for ; Mon, 24 Oct 2005 14:28:31 +0000 (GMT) (envelope-from victor.cruceru@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0DC443D46 for ; Mon, 24 Oct 2005 14:28:30 +0000 (GMT) (envelope-from victor.cruceru@gmail.com) Received: by wproxy.gmail.com with SMTP id i5so630744wra for ; Mon, 24 Oct 2005 07:28:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=S42rJyc2WvivQ+lZj/3MKR5diW7+5ldr59YhVVFte3hU0jLcqnTberRpE0ALMm+NJ09snsolbtHg7zBSSc4AQXU7KUA49btojEkGdvJ1Ly2Lmd1JgIs4Q+eEGMJ4VH8HFEkF/Tk6EFVg7W68KHh26dMVmVlSL38AQh2KsjbEBGs= Received: by 10.54.157.10 with SMTP id f10mr3281374wre; Mon, 24 Oct 2005 07:28:30 -0700 (PDT) Received: by 10.54.91.4 with HTTP; Mon, 24 Oct 2005 07:28:29 -0700 (PDT) Message-ID: <49402550510240728y555979c9i2fe4adc73137a1e7@mail.gmail.com> Date: Mon, 24 Oct 2005 17:28:29 +0300 From: victor cruceru To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Re: devinfo(3) problem... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: soc-victor@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2005 14:28:31 -0000 Daniel, What is the OS version you are using when this is happening? Did you try to update the libdevinfo (using cvsup for example) to a newer version? I think that under the original 5.4 it is a bug in devinfo(4) with the described behaviour below. > > ------------------------------ > > Message: 5 > Date: Sun, 23 Oct 2005 19:57:00 -0700 > From: Daniel Rudy > Subject: devinfo(3) problem... > To: freebsd-hackers@freebsd.org > Message-ID: <435C4D7C.7080504@pacbell.net> > Content-Type: text/plain; charset=3Dus-ascii > > > Consider the following code fragment: > > > (segment 2) > Calling code section: > /* get devinfo root nexus */ > printf("root ptr: %p\n", root); > result =3D usb_devinfo_root(&root); > printf("root ptr: %p\n", root); > if (result < 0) > { > usb_devinfo_close(); > return(-1); > } > > /* internal: get devinfo root nexus */ > int usb_devinfo_root(struct devinfo_dev **root) > { > printf("root: %p\n", *root); > *root =3D devinfo_handle_to_device(DEVINFO_ROOT_DEVICE); > printf("root: %p\n", *root); <---- second call printf > if (*root =3D=3D NULL) > { > if (usb_param_use_error =3D=3D TRUE) error("usb.c: usb_devinfo_ro= ot: > root device not found", errno); > if (usb_param_errors_fatal =3D=3D TRUE) exit(2); > return(-1); > } > return(0); > } > > The problem is that devinfo_handle_to_device always returns a null > pointer here. Why? The next code segment, devinfo_handle_to_device > returns a proper address. > > (segment 1) > /* get devinfo root nexus */ > root =3D devinfo_handle_to_device(DEVINFO_ROOT_DEVICE); > if (root =3D=3D NULL) > { > devinfo_free(); > return(-1); > } > > output: > usb_param_devmode: 255 > usb_param_devtype: 255 > usb_param_mode_pref: 0 > ioctl result: -1 > devinfo result: 0 > found_ioctl: 0 > found_devinfo: 1 <---- first call > devinfo device name: umass0 > usb_devinfo_open result: 0 > root ptr: 0x2815769c > root: 0x2815769c > root: 0x0 <---- second call > usb.c: usb_devinfo_root: root device not found: No such file or directory > root ptr: 0x0 > Fatal: Unable to get device information > > > Now I have made sure that I have called devinfo_free() during the first > call before calling devinfo_init() a second time. I tried calling this > code branch on the first time, and it executes properly, so why does it > fail on the second call? > > -- > Daniel Rudy > > > -- victor cruceru ------------------------------------------------ Non est respondendum ad omnia. ( Cicero, Pro Murena Oratio ) ------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 24 15:42:30 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 14BB416A421 for ; Mon, 24 Oct 2005 15:42:30 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F85743D46 for ; Mon, 24 Oct 2005 15:42:29 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from [10.50.41.234] (Not Verified[10.50.41.234]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Mon, 24 Oct 2005 11:59:10 -0400 From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 24 Oct 2005 11:20:29 -0400 User-Agent: KMail/1.8.2 References: <200510211216.37814.jhb@freebsd.org> <200510221516.j9MFGnqT026691@pinky.frank-behrens.de> <20051022.103242.98606517.imp@bsdimp.com> In-Reply-To: <20051022.103242.98606517.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510241120.31203.jhb@freebsd.org> Cc: frank@pinky.sax.de Subject: Re: How disable attachment of sio(4) driver to device? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2005 15:42:30 -0000 On Saturday 22 October 2005 12:32 pm, M. Warner Losh wrote: > In message: <200510221516.j9MFGnqT026691@pinky.frank-behrens.de> > > "Frank Behrens" writes: > : > Another solution would be to have your driver use the tty layer > : > instead of banging the hardware directly, if that is compatible with > : > the goals of your driver. This solution isn't in quotes because for > : > some class of devices (say a keyboard driver for a sun or apple newton > : > keyboard that does serial), it might be the right one. > : > : Hm, this looks even more complicated and has more overhead. To show > : shortly my requirements: The protocol is for an eib driver, (further > : information on http://www.sax.de/~frank/eib4bsd/), it uses 9600 baud > : on serial line. If the PC wants to send a telegram it resets RTS and > : has to poll CTS. If CTS is active the transmission of one byte is > : possible. If the last bit is sent (transceiver shift empty!) the PC > : sets RTS and waits until CTS is inactive. Then a new handshake can > : start and a transmission of about 30 bytes must be finished in 130 > : ms. IMHO this can be handled only in an interrupt routine with low > : overhead. > > That's only about a 25% duty cycle on the line. You might look at the > uart driver to see if you can hook into it in such a way as to get the > notification of these events via interrupt. I thought that when the > control bits changed there was an interrupt. > > : M. Warner Losh wrote on 21 Oct 2005 11:37: > : > I'd like to be able to say that sio0 is at handle=\_SB_.PCI0.PX40.UAR2 > : > rather than some arbitrary address. Or that bge1 is at > : > > : > bge0 pnpinfo vendor=0x14e4 device=0x16a6 subvendor=0x14e4 > : > subdevice=0x8009 class=0x020000 at slot=3 function=0 > : > handle=\_SB_.PCI0.G0PA.LAN0 miibus0 > : > brgphy0 pnpinfo oui=0x818 model=0x16 rev=0x2 at phyno=1 > : > bge1 pnpinfo vendor=0x14e4 device=0x16a6 subvendor=0x14e4 > : > subdevice=0x8009 class=0x020000 at slot=4 function=0 > : > handle=\_SB_.PCI0.G0PA.LAN1 > : > > : > either at pci2.4.0 *OR* at handle=\_SB_.PCI0.G0PA.LAN1 (or even > : > handle=LAN1). So there'd need to be some kind of bus specific mapping > : > function that would say true or false if a given device_t on that bus > : > matched the string presented. > : > : For my driver I made already a sort of this. Part of my probe routine > : is > : if (resource_string_value(EIBNAME, 0, "at", &hintBus)) > : return (ENXIO); > : if (strcmp(hintBus, "pci")) > : return (ENXIO); > : > : if (resource_int_value(EIBNAME, 0, "bus", &hint) == 0 && > : pci_get_bus(device) != hint) { > : return (ENXIO); > : } > : if (resource_int_value(EIBNAME, 0, "slot", &hint) == 0 && > : pci_get_slot(device) != hint) { > : return (ENXIO); > : } > : if (resource_int_value(EIBNAME, 0, "function", &hint) == 0 && > : pci_get_function(device) != hint) { > : return (ENXIO); > : } > > There's problems doing this in the general case. I tried doing > something similar to this a few years back, and discovered that doing > it in the driver caused problems. Specifically, if another device is > before you in the probe order, that device might snag the hinted > device's location. With most drivers returning BUS_PROBE_DEFAULT > these days, this is effectively masked. It is also tedious and > error-prone to specificy things this way... it will likely be > completely adequate for most of your needs, however... > > : So my conclusion is: > : 2. I will create a PR to change the sio(4) driver, that it returns > : BUS_PROBE_DEFAULT instead of BUS_PROBE_SPECIFIC. > : Then further patching is not necessary. > > I believe that's correct. Only if you make sure that sio(4) doesn't try to pass data between probe() and attach() via the softc since the softc is preserved from probe to attach if you return 0 from probe. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 24 16:27:35 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31E2D16A41F for ; Mon, 24 Oct 2005 16:27:35 +0000 (GMT) (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 741AF43D45 for ; Mon, 24 Oct 2005 16:27:34 +0000 (GMT) (envelope-from sos@FreeBSD.org) Received: from [194.192.25.136] (mac.deepcore.dk [194.192.25.136]) by spider.deepcore.dk (8.13.4/8.13.3) with ESMTP id j9OGRLDq050461; Mon, 24 Oct 2005 18:27:21 +0200 (CEST) (envelope-from sos@FreeBSD.org) In-Reply-To: <200510232049.16352.Jason.Harmening@gmail.com> References: <200510232049.16352.Jason.Harmening@gmail.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <08AD1F28-AE42-4C36-B5E0-3E909130BDB8@FreeBSD.org> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= Date: Mon, 24 Oct 2005 18:27:29 +0200 To: Jason Harmening X-Mailer: Apple Mail (2.734) X-mail-scanned: by DeepCore Virus & Spam killer v1.12 Cc: freebsd-hackers@FreeBSD.org Subject: Re: Native ATAPI MO driver 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, 24 Oct 2005 16:27:35 -0000 On 24/10/2005, at 3:49, Jason Harmening wrote: > Hi, > > I have a 2.3G Fujitsu MO drive, and I've gotten tired of using =20 > atapicam to > access it. I'm thinking of writing a native ATAPI driver that =20 > could be added > to the kernel through a configuration line like: > > device atapimo > > I've been doing a little work to see how feasible this is--the =20 > kernel already > defines the ATA_ATAPI_TYPE_OPTICAL device type that is received =20 > from my drive > during probing. But ATA_ATAPI_TYPE_OPTICAL isn't actually used =20 > anywhere, and > there is no driver that can actually recognize and attach to an =20 > ATAPI MO > drive. > > I modified the atapifd driver (src/sys/dev/ata/atapi-fd.c) to also =20 > recognize > ATA_ATAPI_TYPE_OPTICAL, and my drive was actually recognized during =20= > probing > as afd0, but afd_attach returned an error. It looks as if afd_sense=20= > () was > failing, which I'm guessing is because ATAPI MO drives (or mine, at =20= > least) > use a different capabilities page code and/or capabilities page =20 > structure > than ATAPI floppies. The atapi-fd driver uses 0x5 for its =20 > "Capabilities and > Mechanical Status" page code, while everything else (atapi-cd, =20 > atapi-tape) > uses 0x2a. All three drivers have distinctly different structures =20 > for this > page. > > So I'm wondering: do ATAPI MO drives use a capabilities page code/=20 > structure > more like CD/DVD drives, or do they have their own unique ATAPI page > structure? If so, where can I find a document outlining the =20 > structure? > > I've found loads of documents detailing the page structure for CD/=20 > DVD drives, > but nothing for MO drives (or floppies or tape drives for that =20 > matter). > > Also, beyond the capabilities page, are there any other special =20 > considerations > I'd need to make for an MO driver? I did plan to write such a driver back when, but HW seemed to have =20 disappeared from all the vendors I've asked so it was pu ton the =20 backburner. Anyhow I should have the docs somewhere so it should be possible to =20 get this working... S=F8ren Schmidt sos@FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 24 16:28:03 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 94D4E16A41F; Mon, 24 Oct 2005 16:28:03 +0000 (GMT) (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 3254143D49; Mon, 24 Oct 2005 16:28:03 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j9OGQKEu069536; Mon, 24 Oct 2005 10:26:20 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 24 Oct 2005 10:27:47 -0600 (MDT) Message-Id: <20051024.102747.89800306.imp@bsdimp.com> To: jhb@freebsd.org From: "M. Warner Losh" In-Reply-To: <200510241120.31203.jhb@freebsd.org> References: <200510221516.j9MFGnqT026691@pinky.frank-behrens.de> <20051022.103242.98606517.imp@bsdimp.com> <200510241120.31203.jhb@freebsd.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Mon, 24 Oct 2005 10:26:20 -0600 (MDT) Cc: frank@pinky.sax.de, freebsd-hackers@freebsd.org Subject: Re: How disable attachment of sio(4) driver to device? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2005 16:28:03 -0000 In message: <200510241120.31203.jhb@freebsd.org> John Baldwin writes: : Only if you make sure that sio(4) doesn't try to pass data between probe() and : attach() via the softc since the softc is preserved from probe to attach if : you return 0 from probe. sio's probe routine, now that you mention this, I believe leaves things in a state that sioattach knows abou. However, it looks like the probe routine will get called twice when you return < 0, so maybe this is OK. Warner From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 24 23:56:04 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD6D516A41F for ; Mon, 24 Oct 2005 23:56:04 +0000 (GMT) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe09.swip.net [212.247.155.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3098D43D49 for ; Mon, 24 Oct 2005 23:56:03 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: FsolnbhBgcq3rQZom0rCNg== Received: from mp-216-120-199.daxnet.no ([193.216.120.199] verified) by mailfe09.swip.net (CommuniGate Pro SMTP 4.3.8) with ESMTP id 11406862; Mon, 24 Oct 2005 22:34:42 +0200 From: Hans Petter Selasky Date: Mon, 24 Oct 2005 22:35:47 +0200 User-Agent: KMail/1.7 MIME-Version: 1.0 Content-Disposition: inline To: tech-kern@netbsd.org, freebsd-hackers@freebsd.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200510242235.48403.hselasky@c2i.net> Cc: Subject: FreeBSD 5/6/7 kernel emulator for NetBSD 2.x X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hselasky@c2i.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2005 23:56:04 -0000 Hi, I have made an effort on making a FreeBSD 5/6/7 kernel emulator for NetBSD 2.x. Many device drivers are shared between these two operating systems, and I think a lot of work can be saved when it comes to porting code and patches forth and back. Currently this emulator makes my FreeBSD PCI ISDN driver load and run on NetBSD. I have chosen to make FreeBSD 5+ the standard for several reasons: - all drivers are dynamically linked through use of the "section attribute" in the "C" compiler. - "/dev" is a file system that can be manipulated from the kernel, without intervention from "mknod". - All I/O resources are allocated through a single function, "bus_alloc_resource()". - And more. Here is a case in which such a kernel emulator can be used: I think it is a good idea that FreeBSD and NetBSD shares as many USB drivers as possible. But sharing USB device drivers like "/usr/src/sys/dev/usb/ulpt.c", is difficult, because two quite different interfaces are used to create devices in "/dev/". And it is not only this, but also how USB device drivers register in the kernel so that they get probed. Here one has tried to hide system differences by using macros. I think one should rather have some external library that hides these system differences, so that there is only one branch for the USB device drivers, for both NetBSD and FreeBSD, and probably the other *BSD's aswell, if possible. That means a branch without "ifdefs" for every operating system it is supposed to compile on. Then one has got to choose the library interface, and I would say that "FreeBSD 5+ specific" is the best candidate so far. I see that one can move many USB drivers over to FreeBSD, merge everything together, expand all the macros in "/usr/src/sys/dev/usb/usb_port.h", and then copy it back to NetBSD which then must have a FreeBSD kernel emulator in the kernel. When the drivers are updated later, it will be very easy to cross port the changes, and at the same time the USB system is brought out of the Giant lock. Also it will be easier to create portable USB kernel device drivers. Anyone have any opinion about what system is better to use as a standard in the kernel? Main features: - Implements FreeBSD's devfs on NetBSD. - Support for mutexes, mtx_xxxx() and msleep() - Support for probe/attach and general use of PCI devices - Support for SYSINIT() - Support for DRIVER_MODULE() - And some other things found in FreeBSD 5/6/7 Here is a tarball (only tested on i386 and compatible, NetBSD 2.x): http://home.c2i.net/hselasky/isdn4bsd/privat/temporary/new_ihfc_1_5_5_NetBSD.tar.bz2 --HPS From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 25 02:15:40 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E4A7616A41F for ; Tue, 25 Oct 2005 02:15:40 +0000 (GMT) (envelope-from dungkaitai@hk-cse.dyxnet.com) Received: from mail81.messagelabs.com (cluster1.hk.messagelabs.com [203.129.72.243]) by mx1.FreeBSD.org (Postfix) with SMTP id 0F30E43D45 for ; Tue, 25 Oct 2005 02:15:39 +0000 (GMT) (envelope-from dungkaitai@hk-cse.dyxnet.com) X-VirusChecked: Checked X-Env-Sender: dungkaitai@hk-cse.dyxnet.com X-Msg-Ref: server-9.tower-81.messagelabs.com!1130206537!26065941!1 X-StarScan-Version: 5.4.15; banners=dyxnet.com,-,- X-Originating-IP: [202.134.93.80] Received: (qmail 18438 invoked from network); 25 Oct 2005 02:15:37 -0000 Received: from ip-80-93-134-202.rev.dyxnet.com (HELO smtp-hk.dyxnet.com) (202.134.93.80) by server-9.tower-81.messagelabs.com with SMTP; 25 Oct 2005 02:15:37 -0000 Received: from [192.168.0.100] (ip-165-67-134-202.rev.dyxnet.com [202.134.67.165]) by smtp-hk.dyxnet.com (8.12.8/8.12.8) with ESMTP id j9P2FaVm009284 for ; Tue, 25 Oct 2005 10:15:37 +0800 Message-ID: <435D95BE.8000004@hk-cse.dyxnet.com> Date: Tue, 25 Oct 2005 10:17:34 +0800 From: Patrick Dung User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en, zh-tw MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Is there any tools that can display TCP window size for current connections? 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, 25 Oct 2005 02:15:41 -0000 Hi Tcpdump can see windows size. But I want a tool that like netstat that list established connection, and with the sliding window size. Is there any tools out there for FreeBSD? ______________________________________________________________________ This email has been checked for virus by DYXNet Managed Virusfree Email Service with 4 anti-virus scanners (http://www.dyxnet.com/) From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 25 12:55:19 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 50B2216A41F; Tue, 25 Oct 2005 12:55:19 +0000 (GMT) (envelope-from bushman@rsu.ru) Received: from mail.r61.net (mail.r61.net [195.208.245.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 873D143D4C; Tue, 25 Oct 2005 12:55:18 +0000 (GMT) (envelope-from bushman@rsu.ru) Received: from [195.208.252.201] (celsius.cc.rsu.ru [195.208.252.201]) by mail.r61.net (8.13.4/8.13.4) with ESMTP id j9PCtFH9041602; Tue, 25 Oct 2005 16:55:15 +0400 (MSD) (envelope-from bushman@rsu.ru) Message-ID: <435E2C1E.8030702@rsu.ru> Date: Tue, 25 Oct 2005 16:59:10 +0400 From: Michael Bushkov User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051018) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.86.2, clamav-milter version 0.86 on asterix.r61.net X-Virus-Status: Clean Cc: Subject: [PATCH] nsswitch extensions + caching daemon 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, 25 Oct 2005 12:55:19 -0000 Hello! I've made the "nsswitch + caching daemon" project during the Google's Summer of Code. There were some issues, though, in the first release of the project. Here is the second version of the patch: http://www.rsu.ru/~bushman/nsswitch_cached/nss_cached.patch It contains several new features, which were not included in the first release (like negative caching, nscd-like functionality support, new cached.conf file syntax). Besides, a lot of code style improvements were made to match the style(9) rules. The description of the project itself and its new features can be found here: http://rsu.ru/~bushman/nsswitch_cached/ Please test the patch and send me your feedback. It would be just great if it could be included to the HEAD. If it's not possible right now, I'll continue working on it to fix all the issues, so that it could be finally merged into the FreeBSD source tree. With best regards, Michael Bushkov Rostov State University From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 25 13:16:03 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B721016A41F for ; Tue, 25 Oct 2005 13:16:03 +0000 (GMT) (envelope-from dinesh@alphaque.com) Received: from ns2.alphaque.com (ns2.alphaque.com [202.75.47.153]) by mx1.FreeBSD.org (Postfix) with SMTP id 5ABB843D49 for ; Tue, 25 Oct 2005 13:16:01 +0000 (GMT) (envelope-from dinesh@alphaque.com) Received: (qmail 61099 invoked by uid 0); 25 Oct 2005 13:15:58 -0000 Received: from lucifer.net-gw.com (HELO prophet.alphaque.com) (202.75.47.153) by lucifer.net-gw.com with SMTP; 25 Oct 2005 13:15:58 -0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by prophet.alphaque.com (8.13.4/8.13.4) with ESMTP id j9PDFlP2024687 for ; Tue, 25 Oct 2005 21:15:47 +0800 (MYT) (envelope-from dinesh@alphaque.com) Message-ID: <435E3003.4050609@alphaque.com> Date: Tue, 25 Oct 2005 21:15:47 +0800 From: Dinesh Nair User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8b) Gecko/20050915 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: correct use of bus_dmamap_sync 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, 25 Oct 2005 13:16:03 -0000 i came across this message http://lists.freebsd.org/pipermail/freebsd-current/2004-December/044395.html and while it explains the use of bus_dmamap_sync, i'm still a little confused on it's usage. i'm trying to port over a driver from freebsd 5.x to freebsd 4.x, and it uses dma mapped addresses extensively. i've been trying to figure out the best places to use bus_dmamap_sync when reading/writing to a dma mapped address space. however, i cant seem to get the gist of this, either from the mailing list discussions or the man page. i've got two buffers, one for read, and one for write. both have been set up with calls to bus_dma_tag_create, bus_dmamem_alloc and bus_dmamap_load. the buffers, which are used in the calls to bus_dmamem_alloc and bus_dmamap_load are, int *readbuf; int *writebuf; (must i malloc space for them before passing them into those functions, or will the call to bus_dmamem_alloc do it for me ?) also, i'm on FreeBSD 4.11 right now, and i notice the definitions of BUS_DMASYNC_* has changed from an enum (0-3) in 4.x to a typedef in 5.x in machine/bus_dma.h the pseudo code for the read and write, called during an interrupt cycle, are: rx_func() { POSITION A while(there_is_some_data) { memcpy(somebuf, readbuf) } POSITION B } tx_func() { POSITION C while(there_is_some_data) { memcpy(writebuf, somebuf) } POSITION D } the question is, what op should i use for bus_dmamap_sync in positions A, B, C and D ? any assistance would be gladly appreciated, as i'm seeing some really weird symptoms on this device, where data written out is being immediately read in. i'm guessing this has to do with my wrong usage of bus_dmamap_sync(). -- Regards, /\_/\ "All dogs go to heaven." dinesh@alphaque.com (0 0) http://www.alphaque.com/ +==========================----oOO--(_)--OOo----==========================+ | for a in past present future; do | | for b in clients employers associates relatives neighbours pets; do | | echo "The opinions here in no way reflect the opinions of my $a $b." | | done; done | +=========================================================================+ -- Regards, /\_/\ "All dogs go to heaven." dinesh@alphaque.com (0 0) http://www.alphaque.com/ +==========================----oOO--(_)--OOo----==========================+ | for a in past present future; do | | for b in clients employers associates relatives neighbours pets; do | | echo "The opinions here in no way reflect the opinions of my $a $b." | | done; done | +=========================================================================+ -- Regards, /\_/\ "All dogs go to heaven." dinesh@alphaque.com (0 0) http://www.alphaque.com/ +==========================----oOO--(_)--OOo----==========================+ | for a in past present future; do | | for b in clients employers associates relatives neighbours pets; do | | echo "The opinions here in no way reflect the opinions of my $a $b." | | done; done | +=========================================================================+ From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 25 14:03:02 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C984516A41F for ; Tue, 25 Oct 2005 14:03:02 +0000 (GMT) (envelope-from dinesh@alphaque.com) Received: from ns2.alphaque.com (ns2.alphaque.com [202.75.47.153]) by mx1.FreeBSD.org (Postfix) with SMTP id 45E6B43D62 for ; Tue, 25 Oct 2005 14:02:57 +0000 (GMT) (envelope-from dinesh@alphaque.com) Received: (qmail 61661 invoked by uid 0); 25 Oct 2005 14:02:55 -0000 Received: from lucifer.net-gw.com (HELO prophet.alphaque.com) (202.75.47.153) by lucifer.net-gw.com with SMTP; 25 Oct 2005 14:02:55 -0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by prophet.alphaque.com (8.13.4/8.13.4) with ESMTP id j9PE2irF025022; Tue, 25 Oct 2005 22:02:44 +0800 (MYT) (envelope-from dinesh@alphaque.com) Message-ID: <435E3B04.7060306@alphaque.com> Date: Tue, 25 Oct 2005 22:02:44 +0800 From: Dinesh Nair User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8b) Gecko/20050915 MIME-Version: 1.0 To: Dinesh Nair References: <435E3003.4050609@alphaque.com> In-Reply-To: <435E3003.4050609@alphaque.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: correct use of bus_dmamap_sync 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, 25 Oct 2005 14:03:02 -0000 On 10/25/05 21:15 Dinesh Nair said the following: > the pseudo code for the read and write, called during an interrupt > cycle, are: > > rx_func() > { > POSITION A > > while(there_is_some_data) { > memcpy(somebuf, readbuf) > } > POSITION B > } > > tx_func() > { > POSITION C > > while(there_is_some_data) { > memcpy(writebuf, somebuf) > } > POSITION D > } > > the question is, what op should i use for bus_dmamap_sync in positions > A, B, C and D ? responding to my own request, i mean which of BUS_DMASYNC_PREREAD, BUS_DMASYNC_POSTREAD, BUS_DMASYNC_PREWRITE, BUS_DMASYNC_POSTWRITE should i use, and where ? -- Regards, /\_/\ "All dogs go to heaven." dinesh@alphaque.com (0 0) http://www.alphaque.com/ +==========================----oOO--(_)--OOo----==========================+ | for a in past present future; do | | for b in clients employers associates relatives neighbours pets; do | | echo "The opinions here in no way reflect the opinions of my $a $b." | | done; done | +=========================================================================+ From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 25 17:02:54 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B7B316A41F for ; Tue, 25 Oct 2005 17:02:54 +0000 (GMT) (envelope-from Vijay.Singh@netapp.com) Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id CAF5343D53 for ; Tue, 25 Oct 2005 17:02:47 +0000 (GMT) (envelope-from Vijay.Singh@netapp.com) Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx1.netapp.com with ESMTP; 25 Oct 2005 10:02:47 -0700 X-IronPort-AV: i="3.97,250,1125903600"; d="scan'208"; a="263307956:sNHT18029304" Received: from svlexc02.hq.netapp.com (svlexc02.corp.netapp.com [10.57.157.136]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id j9PH2kpI017657; Tue, 25 Oct 2005 10:02:46 -0700 (PDT) Received: from exsvl01.hq.netapp.com ([10.56.8.45]) by svlexc02.hq.netapp.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 25 Oct 2005 10:02:46 -0700 Received: from magenta.hq.netapp.com ([10.56.11.84]) by exsvl01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Oct 2005 10:02:46 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Oct 2005 10:02:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <637A278D8D0DBC438EA5E75C6E1818B9063C0E64@magenta.hq.netapp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: correct use of bus_dmamap_sync Thread-Index: AcXZbOaGhsPWuqJEQD6zNdhZskKULAAGPqRw From: "Singh, Vijay" To: "Dinesh Nair" X-OriginalArrivalTime: 25 Oct 2005 17:02:46.0074 (UTC) FILETIME=[EBDA09A0:01C5D985] X-Mailman-Approved-At: Tue, 25 Oct 2005 17:27:10 +0000 Cc: freebsd-hackers@freebsd.org Subject: RE: correct use of bus_dmamap_sync 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, 25 Oct 2005 17:02:54 -0000 man bus_dma(9) > -----Original Message----- > From: Dinesh Nair [mailto:dinesh@alphaque.com]=20 > Sent: Tuesday, October 25, 2005 7:03 AM > To: Dinesh Nair > Cc: freebsd-hackers@freebsd.org > Subject: Re: correct use of bus_dmamap_sync >=20 >=20 >=20 > On 10/25/05 21:15 Dinesh Nair said the following: > > the pseudo code for the read and write, called during an interrupt=20 > > cycle, are: > >=20 > > rx_func() > > { > > POSITION A > >=20 > > while(there_is_some_data) { > > memcpy(somebuf, readbuf) > > } > > POSITION B > > } > >=20 > > tx_func() > > { > > POSITION C > >=20 > > while(there_is_some_data) { > > memcpy(writebuf, somebuf) > > } > > POSITION D > > } > >=20 > > the question is, what op should i use for bus_dmamap_sync=20 > in positions=20 > > A, B, C and D ? >=20 > responding to my own request, i mean which of=20 > BUS_DMASYNC_PREREAD, BUS_DMASYNC_POSTREAD,=20 > BUS_DMASYNC_PREWRITE, BUS_DMASYNC_POSTWRITE should i use, and where ? >=20 > --=20 > Regards, /\_/\ "All dogs go to heaven." > dinesh@alphaque.com (0 0) http://www.alphaque.com/ > = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D----oOO--(_)--OOo----=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > +=3D=3D+ > | for a in past present future; do =20 > | > | for b in clients employers associates relatives=20 > neighbours pets; do | > | echo "The opinions here in no way reflect the opinions of=20 > my $a $b." | > | done; done =20 > | > = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > +=3D=3D+ > _______________________________________________ > freebsd-hackers@freebsd.org mailing list=20 > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to=20 > "freebsd-hackers-unsubscribe@freebsd.org" >=20 From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 25 17:31:24 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA0C416A41F for ; Tue, 25 Oct 2005 17:31:24 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id B227D43D67 for ; Tue, 25 Oct 2005 17:31:22 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from [10.50.41.234] (Not Verified[10.50.41.234]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Tue, 25 Oct 2005 13:48:05 -0400 From: John Baldwin To: freebsd-hackers@freebsd.org Date: Tue, 25 Oct 2005 13:27:59 -0400 User-Agent: KMail/1.8.2 References: <435E3003.4050609@alphaque.com> In-Reply-To: <435E3003.4050609@alphaque.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510251327.59965.jhb@freebsd.org> Cc: Subject: Re: correct use of bus_dmamap_sync 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, 25 Oct 2005 17:31:24 -0000 On Tuesday 25 October 2005 09:15 am, Dinesh Nair wrote: > i came across this message > http://lists.freebsd.org/pipermail/freebsd-current/2004-December/044395.htm >l > > and while it explains the use of bus_dmamap_sync, i'm still a little > confused on it's usage. i'm trying to port over a driver from freebsd 5.x > to freebsd 4.x, and it uses dma mapped addresses extensively. > > i've been trying to figure out the best places to use bus_dmamap_sync when > reading/writing to a dma mapped address space. however, i cant seem to get > the gist of this, either from the mailing list discussions or the man page. > > i've got two buffers, one for read, and one for write. both have been set > up with calls to bus_dma_tag_create, bus_dmamem_alloc and bus_dmamap_load. > > the buffers, which are used in the calls to bus_dmamem_alloc and > bus_dmamap_load are, > > int *readbuf; > int *writebuf; > > (must i malloc space for them before passing them into those functions, or > will the call to bus_dmamem_alloc do it for me ?) bus_dmamem_alloc() will do it for you. > also, i'm on FreeBSD 4.11 right now, and i notice the definitions of > BUS_DMASYNC_* has changed from an enum (0-3) in 4.x to a typedef in 5.x in > machine/bus_dma.h > > the pseudo code for the read and write, called during an interrupt cycle, > are: > > rx_func() > { > POSITION A bus_dmamap_sync(PREREAD); > while(there_is_some_data) { > memcpy(somebuf, readbuf) > } > POSITION B bus_dmamap_sync(POSTREAD); > } > > tx_func() > { > POSITION C bus_dmamap_sync(PREWRITE); > while(there_is_some_data) { > memcpy(writebuf, somebuf) > } > POSITION D bus_dmamap_sync(POSTWRITE); > } > > the question is, what op should i use for bus_dmamap_sync in positions A, > B, C and D ? > > any assistance would be gladly appreciated, as i'm seeing some really weird > symptoms on this device, where data written out is being immediately read > in. i'm guessing this has to do with my wrong usage of bus_dmamap_sync(). Probably not as the sync()'s don't really do anything with memory allocated via bus_dmamem_alloc(). The operations are named from the CPU's perspective, thus when you send data to your device, that is a WRITE operation (even though your device is doing a DMA to read data), and when you get data back from your device, that is a READ operation (even though your device is doing a DMA to write the data into the buffer). -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 25 17:41:27 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 56DA316A41F; Tue, 25 Oct 2005 17:41:27 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7ACA43D7B; Tue, 25 Oct 2005 17:41:19 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from [10.50.41.234] (Not Verified[10.50.41.234]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Tue, 25 Oct 2005 13:57:48 -0400 From: John Baldwin To: Julian Elischer Date: Tue, 25 Oct 2005 13:41:20 -0400 User-Agent: KMail/1.8.2 References: <20051021131329.A16FC126E@smtp.263.net> <200510211728.32476.jhb@freebsd.org> <435965EE.7070504@elischer.org> In-Reply-To: <435965EE.7070504@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200510251341.22621.jhb@freebsd.org> Cc: nocool , freebsd-hackers@freebsd.org, David Schultz , freebsd-current , delphij Subject: Re: where to release proc.p_stats 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, 25 Oct 2005 17:41:27 -0000 On Friday 21 October 2005 06:04 pm, Julian Elischer wrote: > John Baldwin wrote: > >On Friday 21 October 2005 04:32 pm, David Schultz wrote: > >>On Fri, Oct 21, 2005, John Baldwin wrote: > >>>On Friday 21 October 2005 09:13 am, nocool wrote: > >>>>freebsd-hackers=EF=BF=BD=C3=AF=EF=BF=BD=C2=BC=C5=92hello > >>>> > >>>> Question about 5.4 kernel source code. > >>>> I have some question about strust proc's initialize. Kernel use > >>>>proc_zone to allocate proc items and initialize them with proc_init > >>>>(sys\kern\kern_proc.c) function. In this function, we can find the > >>>>field proc.p_stats is allocated with pstats_alloc(), as > >>>> > >>>>p->p_stats =3D pstats_alloc(); > >>>> > >>>>and pstats_alloc is realized as > >>>> > >>>>malloc(sizeof(struct pstats), M_SUBPROC, M_ZERO|M_WAITOK); > >>>> > >>>>But I can't find where this field is freed. If it will not be release, > >>>>will there be memory leakage? > >>> > >>>Heh, das@ forgot to call pstats_free() when he did the changes. The > >>>reason is probably because proc_fini() doesn't do anything useful > >>> because we never recycle proc structs. We should probably at least a= dd > >>> the operations there though for documentation purposes. Something li= ke > >>> this would work I think: > >> > >>I didn't put in the call because we never free proc structures, but > >>documenting what should happen if we ever do free them is a good > >>idea. There's a fair amount of other cleanup that needs to happen > >>as well, which you can probably find in the CVS history. (IIRC, > >>I'm guilty of removing the code at a time when more things depended > >>upon struct proc being type safe. Are there any remaining reasons > >>why we can't free struct procs at this point?) > >> > >>By the way, there's no reason why we can't fold struct pstats into > >>struct proc so we don't have to allocate and free it at all. > >>It's never shared, so the extra level of indirection just adds overhead. > >>The main reason I didn't make this change earlier was to maintain binary > >>compatibility when I backported my U-area changes to -STABLE. > > > >Looks like some of the functions (vm_dispose_proc() and > > sched_destroyproc()) have vanished, so this is all that would be in the= re > > now: > > > >Index: kern_proc.c > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >RCS file: /usr/cvs/src/sys/kern/kern_proc.c,v > >retrieving revision 1.232 > >diff -u -r1.232 kern_proc.c > >--- kern_proc.c 2 Oct 2005 23:27:56 -0000 1.232 > >+++ kern_proc.c 21 Oct 2005 21:21:45 -0000 > >@@ -196,8 +196,17 @@ > > static void > > proc_fini(void *mem, int size) > > { > >+#ifdef notnow > >+ struct proc *p; > > > >+ p =3D (struct proc *)mem; > >+ pstats_free(p->p_stats); > >+ ksegrp_free(FIRST_KSEGRP_IN_PROC(p)); > >+ thread_free(FIRST_THREAD_IN_PROC(p)); > >+ mtx_destroy(&p->p_mtx); > >+#else > > panic("proc reclaimed"); > >+#endif > > } > > > > /* > > sched_destroyproc was removed by someone I believe because "it was not > used". > > if you were removing a proc you possibly should re introduce it. I actually looked in the CVS history to find out if vm_dispose_proc() and=20 sched_destroyproc() should come back and I don't think they need to. =2D-=20 John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" =3D http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 25 17:47:07 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B31716A41F for ; Tue, 25 Oct 2005 17:47:07 +0000 (GMT) (envelope-from dr2867@pacbell.net) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by mx1.FreeBSD.org (Postfix) with SMTP id B2EAB43D46 for ; Tue, 25 Oct 2005 17:47:04 +0000 (GMT) (envelope-from dr2867@pacbell.net) Received: (qmail 26622 invoked from network); 25 Oct 2005 17:47:04 -0000 Received: from unknown (HELO ?192.168.0.190?) (dr2867.business@pacbell.net@68.126.211.246 with plain) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 25 Oct 2005 17:47:03 -0000 Message-ID: <435E6F9C.9090008@pacbell.net> Date: Tue, 25 Oct 2005 10:47:08 -0700 From: Daniel Rudy User-Agent: Mozilla/5.0 (X11R6; UNIX; FreeBSD/i386 5.4-RELEASE-p7; en-US; ja-JP; rv:1.7.12) Gecko/20050915 MultiZilla/1.6.2.0c Mnenhy/0.7.2.0 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: soc-victor@freebsd.org References: <49402550510240728y555979c9i2fe4adc73137a1e7@mail.gmail.com> In-Reply-To: <49402550510240728y555979c9i2fe4adc73137a1e7@mail.gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: devinfo(3) 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: Tue, 25 Oct 2005 17:47:07 -0000 At about the time of 10/24/2005 7:28 AM, victor cruceru stated the following: > Daniel, > What is the OS version you are using when this is happening? > Did you try to update the libdevinfo (using cvsup for example) to a > newer version? > I think that under the original 5.4 it is a bug in devinfo(4) with the > described behaviour below. I'm running 5.4-RELEASE. When you mentioned that it might be a bug, I went and looked at /usr/src/lib/libdevinfo/devinfo.c using the cvs web depository. I found that devinfo_generation = 0 was added to the end of the devinfo_free function starting at line 367. I added the code and recompiled just that library, and now everything seems to be working ok, except now I'm getting a bunch of garbage on the serial number of the USB flash drive. I'm not sure if it's my code, or if it's a bug in the library. -- Daniel Rudy From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 25 18:48:32 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B426916A41F for ; Tue, 25 Oct 2005 18:48:32 +0000 (GMT) (envelope-from dinesh@alphaque.com) Received: from ns2.alphaque.com (ns2.alphaque.com [202.75.47.153]) by mx1.FreeBSD.org (Postfix) with SMTP id 530BF43D48 for ; Tue, 25 Oct 2005 18:48:30 +0000 (GMT) (envelope-from dinesh@alphaque.com) Received: (qmail 65281 invoked by uid 0); 25 Oct 2005 18:48:28 -0000 Received: from lucifer.net-gw.com (HELO prophet.alphaque.com) (202.75.47.153) by lucifer.net-gw.com with SMTP; 25 Oct 2005 18:48:28 -0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by prophet.alphaque.com (8.13.4/8.13.4) with ESMTP id j9PIka1E000561; Wed, 26 Oct 2005 02:46:36 +0800 (MYT) (envelope-from dinesh@alphaque.com) Message-ID: <435E7D8C.90401@alphaque.com> Date: Wed, 26 Oct 2005 02:46:36 +0800 From: Dinesh Nair User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8b) Gecko/20050915 MIME-Version: 1.0 To: John Baldwin References: <435E3003.4050609@alphaque.com> <200510251327.59965.jhb@freebsd.org> In-Reply-To: <200510251327.59965.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: correct use of bus_dmamap_sync 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, 25 Oct 2005 18:48:32 -0000 On 10/26/05 01:27 John Baldwin said the following: > On Tuesday 25 October 2005 09:15 am, Dinesh Nair wrote: >>(must i malloc space for them before passing them into those functions, or >>will the call to bus_dmamem_alloc do it for me ?) > > bus_dmamem_alloc() will do it for you. thanx. > Probably not as the sync()'s don't really do anything with memory allocated > via bus_dmamem_alloc(). The operations are named from the CPU's perspective, however, the man page at http://www.freebsd.org/cgi/man.cgi?query=bus_dmamap_sync&apropos=0&sektion=0&manpath=FreeBSD+5.4-stable&format=html says, "Although no explicit loading is required to access the memory referenced by the returned map, the synchronization requirements as described in the bus_dmamap_sync() section still apply." also, is bus_dmamap_load() required, since the same man page section above says it isnt ? have things changed between freebsd 4.x (which i'm using) and freebsd 5.x ? > thus when you send data to your device, that is a WRITE operation (even > though your device is doing a DMA to read data), and when you get data back > from your device, that is a READ operation (even though your device is doing > a DMA to write the data into the buffer). thanx, the verbiage on the man page is slightly confusing with it's use of CPU, giving the opposite impression. -- Regards, /\_/\ "All dogs go to heaven." dinesh@alphaque.com (0 0) http://www.alphaque.com/ +==========================----oOO--(_)--OOo----==========================+ | for a in past present future; do | | for b in clients employers associates relatives neighbours pets; do | | echo "The opinions here in no way reflect the opinions of my $a $b." | | done; done | +=========================================================================+ From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 25 18:48:32 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C477D16A420 for ; Tue, 25 Oct 2005 18:48:32 +0000 (GMT) (envelope-from dinesh@alphaque.com) Received: from ns2.alphaque.com (ns2.alphaque.com [202.75.47.153]) by mx1.FreeBSD.org (Postfix) with SMTP id 5327643D49 for ; Tue, 25 Oct 2005 18:48:30 +0000 (GMT) (envelope-from dinesh@alphaque.com) Received: (qmail 65278 invoked by uid 0); 25 Oct 2005 18:48:28 -0000 Received: from lucifer.net-gw.com (HELO prophet.alphaque.com) (202.75.47.153) by lucifer.net-gw.com with SMTP; 25 Oct 2005 18:48:28 -0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by prophet.alphaque.com (8.13.4/8.13.4) with ESMTP id j9PIdt3m000550; Wed, 26 Oct 2005 02:39:55 +0800 (MYT) (envelope-from dinesh@alphaque.com) Message-ID: <435E7BFA.8090805@alphaque.com> Date: Wed, 26 Oct 2005 02:39:54 +0800 From: Dinesh Nair User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8b) Gecko/20050915 MIME-Version: 1.0 To: "Singh, Vijay" References: <637A278D8D0DBC438EA5E75C6E1818B9063C0E64@magenta.hq.netapp.com> In-Reply-To: <637A278D8D0DBC438EA5E75C6E1818B9063C0E64@magenta.hq.netapp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: correct use of bus_dmamap_sync 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, 25 Oct 2005 18:48:33 -0000 On 10/26/05 01:02 Singh, Vijay said the following: > man bus_dma(9) thanx, but that doesn't exist on freebsd 4.x. though http://www.freebsd.org/cgi/man.cgi?query=bus_dmamap_sync&apropos=0&sektion=0&manpath=FreeBSD+5.4-stable&format=html has it, it still applies only to 5.x. -- Regards, /\_/\ "All dogs go to heaven." dinesh@alphaque.com (0 0) http://www.alphaque.com/ +==========================----oOO--(_)--OOo----==========================+ | for a in past present future; do | | for b in clients employers associates relatives neighbours pets; do | | echo "The opinions here in no way reflect the opinions of my $a $b." | | done; done | +=========================================================================+ From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 25 19:50:33 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C338F16A41F for ; Tue, 25 Oct 2005 19:50:33 +0000 (GMT) (envelope-from victor.cruceru@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5497C43D48 for ; Tue, 25 Oct 2005 19:50:33 +0000 (GMT) (envelope-from victor.cruceru@gmail.com) Received: by wproxy.gmail.com with SMTP id i5so95063wra for ; Tue, 25 Oct 2005 12:50:32 -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=YTL5NY5J96wCSvG+7Ulxj5YUFg4p7Fl4Ol/OVTapN8tiuU5OMxziDDlKgUHgSltNrUwlvAO2R60SuUfrLxrJW5FdzMQNPtHcSBvNLh/lD+6mph2n11wyNJ+ZIeR8ovNeksvdt4FOOPmd9FVCc0yTx081sZqarpDT+LnZwhvNhWI= Received: by 10.54.62.2 with SMTP id k2mr39294wra; Tue, 25 Oct 2005 12:50:32 -0700 (PDT) Received: by 10.54.91.4 with HTTP; Tue, 25 Oct 2005 12:50:32 -0700 (PDT) Message-ID: <49402550510251250g66a89037q9a1eb3bdbedf94c3@mail.gmail.com> Date: Tue, 25 Oct 2005 22:50:32 +0300 From: victor cruceru To: Daniel Rudy In-Reply-To: <435E6F9C.9090008@pacbell.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <49402550510240728y555979c9i2fe4adc73137a1e7@mail.gmail.com> <435E6F9C.9090008@pacbell.net> Cc: freebsd-hackers@freebsd.org Subject: Re: devinfo(3) problem... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: soc-victor@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2005 19:50:33 -0000 Hi Daniel, Yes, this is the fix. And yes, I think that the bug was reported (at least on a mailing list...) BTW: I dare to suggest to fully upgrade your system to the "latest" 6.0, it is a huge step forward from 5.4. Before doing this you may want to give it a try by booting from a CD and check that your hw is fully functional (and detected). To check if it is your mistake or another bug in libdevinfo, you may want to run the associated tool (man -k devinfo). Hope this helps. On 10/25/05, Daniel Rudy wrote: > At about the time of 10/24/2005 7:28 AM, victor cruceru stated the > following: > > Daniel, > > What is the OS version you are using when this is happening? > > Did you try to update the libdevinfo (using cvsup for example) to a > > newer version? > > I think that under the original 5.4 it is a bug in devinfo(4) with the > > described behaviour below. > > I'm running 5.4-RELEASE. > > When you mentioned that it might be a bug, I went and looked at > /usr/src/lib/libdevinfo/devinfo.c using the cvs web depository. I found > that devinfo_generation =3D 0 was added to the end of the devinfo_free > function starting at line 367. I added the code and recompiled just > that library, and now everything seems to be working ok, except now I'm > getting a bunch of garbage on the serial number of the USB flash drive. > I'm not sure if it's my code, or if it's a bug in the library. > > -- > Daniel Rudy > -- victor cruceru ------------------------------------------------ Non est respondendum ad omnia. ( Cicero, Pro Murena Oratio ) ------------------------------------------------ From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 25 20:09:19 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D7FD316A41F for ; Tue, 25 Oct 2005 20:09:19 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 95A9843D49 for ; Tue, 25 Oct 2005 20:09:18 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from [10.50.41.234] (Not Verified[10.50.41.234]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Tue, 25 Oct 2005 16:26:02 -0400 From: John Baldwin To: Dinesh Nair Date: Tue, 25 Oct 2005 16:10:52 -0400 User-Agent: KMail/1.8.2 References: <435E3003.4050609@alphaque.com> <200510251327.59965.jhb@freebsd.org> <435E7D8C.90401@alphaque.com> In-Reply-To: <435E7D8C.90401@alphaque.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510251610.53127.jhb@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: correct use of bus_dmamap_sync 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, 25 Oct 2005 20:09:20 -0000 On Tuesday 25 October 2005 02:46 pm, Dinesh Nair wrote: > On 10/26/05 01:27 John Baldwin said the following: > > On Tuesday 25 October 2005 09:15 am, Dinesh Nair wrote: > >>(must i malloc space for them before passing them into those functions, > >> or will the call to bus_dmamem_alloc do it for me ?) > > > > bus_dmamem_alloc() will do it for you. > > thanx. > > > Probably not as the sync()'s don't really do anything with memory > > allocated via bus_dmamem_alloc(). The operations are named from the > > CPU's perspective, > > however, the man page at > http://www.freebsd.org/cgi/man.cgi?query=bus_dmamap_sync&apropos=0&sektion= >0&manpath=FreeBSD+5.4-stable&format=html says, > > "Although no explicit loading is required to access the memory referenced > by the returned map, the synchronization requirements as described in the > bus_dmamap_sync() section still apply." Yes, and on some archs the sync() operations do have memory barriers in place, but there isn't any bounce buffering with bus_dmamem_alloc() memory. > also, is bus_dmamap_load() required, since the same man page section above > says it isnt ? Well, you need it to get the physical address to pass to your device for it to do DMA against. > have things changed between freebsd 4.x (which i'm using) and freebsd 5.x ? I don't think so as far as the interface. > > thus when you send data to your device, that is a WRITE operation (even > > though your device is doing a DMA to read data), and when you get data > > back from your device, that is a READ operation (even though your device > > is doing a DMA to write the data into the buffer). > > thanx, the verbiage on the man page is slightly confusing with it's use of > CPU, giving the opposite impression. Yes, I know. :) -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 25 21:09:02 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.ORG Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 45E5616A41F; Tue, 25 Oct 2005 21:09:02 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E0F643D45; Tue, 25 Oct 2005 21:09:00 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j9PL8mI3003059; Wed, 26 Oct 2005 00:08:48 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 45987-04; Wed, 26 Oct 2005 00:08:45 +0300 (EEST) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j9PL4O8W002978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Oct 2005 00:04:24 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.4/8.13.4) id j9PL4PPU006407; Wed, 26 Oct 2005 00:04:25 +0300 (EEST) (envelope-from ru) Date: Wed, 26 Oct 2005 00:04:25 +0300 From: Ruslan Ermilov To: Dinesh Nair Message-ID: <20051025210425.GF85749@ip.net.ua> References: <435E3003.4050609@alphaque.com> <200510251327.59965.jhb@freebsd.org> <435E7D8C.90401@alphaque.com> <200510251610.53127.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fwqqG+mf3f7vyBCB" Content-Disposition: inline In-Reply-To: <200510251610.53127.jhb@freebsd.org> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua Cc: freebsd-hackers@FreeBSD.ORG, John Baldwin Subject: Re: correct use of bus_dmamap_sync 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, 25 Oct 2005 21:09:02 -0000 --fwqqG+mf3f7vyBCB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 25, 2005 at 04:10:52PM -0400, John Baldwin wrote: > On Tuesday 25 October 2005 02:46 pm, Dinesh Nair wrote: [...] > > > thus when you send data to your device, that is a WRITE operation (ev= en > > > though your device is doing a DMA to read data), and when you get data > > > back from your device, that is a READ operation (even though your dev= ice > > > is doing a DMA to write the data into the buffer). > > > > thanx, the verbiage on the man page is slightly confusing with it's use= of > > CPU, giving the opposite impression. >=20 > Yes, I know. :) >=20 Please go read the HEAD version of the manpage; it's been fixed recently to improve the description of these details. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --fwqqG+mf3f7vyBCB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDXp3ZqRfpzJluFF4RAgxBAJ4p8RSk9Xr81pm/fhnDFfluCmnicACePG/a lPuQ8Z89sRdXWsImDCVogPQ= =Jrcd -----END PGP SIGNATURE----- --fwqqG+mf3f7vyBCB-- From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 26 02:39:21 2005 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2742816A41F for ; Wed, 26 Oct 2005 02:39:21 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB56A43D45 for ; Wed, 26 Oct 2005 02:39:20 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id j9Q2dI3n034175 for ; Tue, 25 Oct 2005 20:39:18 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <435EEC56.9080708@samsco.org> Date: Tue, 25 Oct 2005 20:39:18 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hackers@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: Subject: [Fwd: Re: use of bus_dmamap_sync] 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, 26 Oct 2005 02:39:21 -0000 Apparently the original poster sent his question to me in private, then sent it again to the mailing list right as I was responding in private. Anyways, no need to continue to guess; if anyone has any questions, feel free to ask. Below is my response. Note that I edited it slightly to fix an error that I found Scott -------- Original Message -------- Subject: Re: use of bus_dmamap_sync Date: Tue, 25 Oct 2005 07:59:03 -0600 From: Scott Long To: Dinesh Nair References: <435DD3B0.70605@alphaque.com> Dinesh Nair wrote: > > hi scott, > > i came across this message of yours, > http://lists.freebsd.org/pipermail/freebsd-current/2004-December/044395.html > > > and you seem like the perfect person to assist me in something. i've been > trying to figure out the best places to use bus_dmamap_sync when > reading/writing to a dma mapped address space. however, i cant seem to get > the gist of this, either from the mailing list discussions or the man page. > could you assist me ? > > i'm on FreeBSD 4.11 right now, and i notice the definitions of > BUS_DMASYNC_* has changed from an enum (0-3) in 4.x to a typedef in 5.x. > > this is what i have done. i have used two buffers to handle reads from the > device and writes to the device. the pseudocode is as follows > > rx_func() > { > POSITION A bus_dmamap_sync(tag, map, BUS_DMASYNC_PREREAD); Ask hardware for data bus_dmamap_sync(tag, map, BUS_DMASYNC_POSTREAD); > > read from readbuf (i'm assuming that device has put data in > readbuf) > POSITION B > } > > tx_func() > { > POSITION C > > write to txbuf (here's where we write to txbuf) bus_dmamap_sync(tag, map, BUS_DMASYNC_PREWRITE); notify hardware of the write > > POSITION D bus_dmamap_sync(tag, map, BUS_DMASYNC_POSTWRITE); > } > > what BUS_DMASYNC_{PRE,POST}{READ,WRITE} option should i use for > bus_dmamap_sync in position A, B, C and D ? > > any assistance would be gladly appreciated, as i'm seeing some really weird > symptoms on this device, where data written out is being immediately read > in. i'm guessing this has to do with my wrong usage of bus_dmamap_sync(). > The point of the syncs is to do the proper memory barrier and cache coherency magic between the CPU and the bus as well as do the memory copies for bounce buffers. If you are dealing with statically mapped buffers, i.e. for an rx/tx descriptor ring, then you'll want code exactly like described above. In reality, most platforms only do stuff for the POSTREAD and PREWRITE cases, but for the sake of completeness the others are documented and usually used in drivers. NetBSD might have platforms that require operations for PREREAD and POSTWRITE, but I've never looked that closely. If you are dealing with dynamic buffers, i.e. for mbuf data, then you'll want the PREREAD and PREWRITE ops to happen in the callback function for bus_dmamap_load() and the POSTREAD and POSTWRITE ops to happen right before calling bus_dmamap_unload. So in this case is would be: rx_buf() { allocate buffer allocate map bus_dmamap_load(tag, map, buffer, size, rx_callback, arg, flags) } rx_callback(arg, segs, nsegs, errno) { convert segs to hardware format bus_dmamap_sync(tag, map, BUS_DMASYNC_PREREAD) notify hardware about buffer } rx_complete() { bus_dmamap_sync(tag, map, BUS_DMASYNC_POSTREAD) bus_dmamap_unload(tag, map, buffer) deallocate map process buffer } tx_buf() { fill buffer allocate map bus_dmamap_load(tag, map, buffer, size, tx_callback, arg, flags) } tx_callback(arg, segs, nsegs, errno) { convert segs to hardware format bus_dmamap_sync(tag, map, BUS_DMASYNC_PREWRITE) notify hardware about buffer } tx_complete() bus_dmamap_sync(tag, map, BUS_DMASYNC_POSTWRITE) bus_dmamap_unload(tag, map, buffer) deallocate map free buffer } This is the design that busdma was originally modelled on. It works well for storage devices where the load operation must succeed. It doesn't work as well for network devices where the latency of the indirect calls is measurable. So for that, I added bus_dmamap_load_mbuf_sg(). It eliminates the callback function and returns the scatter gather list directly. So, the above example would be: tx_buf() { bus_dma_segment_t segs[maxsegs]; int nsegs; fill buffer allocate map bus_dmamap_load_mbuf_sg(tag, map, buffer, size, &segs, &nsegs) convert segs to hardware format bus_dmamap_sync(tag, map, BUS_DMASYNC_PREWRITE) notify hardware about buffer } Also, the 'allocate map' part should be done carefully. Most network drivers are lazy and call bus_dmamap_create() and bus_dmamap_destroy() for each buffer. It's often better to pre-allocate the maps at init time, put them on a list, and then just push and pop them off the list at runtime. This is usually faster than calling the busdma functions, but you'll have to weigh the tradeoffs. Scott From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 26 05:08:25 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0939916A41F for ; Wed, 26 Oct 2005 05:08:25 +0000 (GMT) (envelope-from chr_koffe@hotmail.com) Received: from hotmail.com (bay108-f5.bay108.hotmail.com [65.54.162.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF1D043D45 for ; Wed, 26 Oct 2005 05:08:24 +0000 (GMT) (envelope-from chr_koffe@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 25 Oct 2005 22:08:24 -0700 Message-ID: Received: from 65.54.162.200 by by108fd.bay108.hotmail.msn.com with HTTP; Wed, 26 Oct 2005 05:08:24 GMT X-Originating-IP: [148.244.181.89] X-Originating-Email: [chr_koffe@hotmail.com] X-Sender: chr_koffe@hotmail.com From: "Chrystian Lopez" To: freebsd-hackers@freebsd.org Date: Wed, 26 Oct 2005 05:08:24 +0000 X-OriginalArrivalTime: 26 Oct 2005 05:08:24.0609 (UTC) FILETIME=[4AD74110:01C5D9EB] MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format="flowed" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: usb umass 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, 26 Oct 2005 05:08:25 -0000 que onda hola estoy inetentando montar my memoria usbcon usbdevs -v me aparece con el driver usb0 y cuando quiero montarla con mount_msdosfs /dev/usb1 /mnt/usb1 me mando un mensaje diciendo /dev/usb1 block device require _________________________________________________________________ Tu horóscopo diario, semanal y gratuito. [1]Cartas, tarot y predicciones en MSN Horóscopo References 1. http://g.msn.com/8HMBESES/2728??PS=47575 From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 26 06:13:35 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA2A916A41F for ; Wed, 26 Oct 2005 06:13:35 +0000 (GMT) (envelope-from dinesh@alphaque.com) Received: from ns2.alphaque.com (ns2.alphaque.com [202.75.47.153]) by mx1.FreeBSD.org (Postfix) with SMTP id 83B3143D46 for ; Wed, 26 Oct 2005 06:13:32 +0000 (GMT) (envelope-from dinesh@alphaque.com) Received: (qmail 72013 invoked by uid 0); 26 Oct 2005 06:13:27 -0000 Received: from lucifer.net-gw.com (HELO prophet.alphaque.com) (202.75.47.153) by lucifer.net-gw.com with SMTP; 26 Oct 2005 06:13:27 -0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by prophet.alphaque.com (8.13.4/8.13.4) with ESMTP id j9Q6DCWA007073; Wed, 26 Oct 2005 14:13:12 +0800 (MYT) (envelope-from dinesh@alphaque.com) Message-ID: <435F1E77.30007@alphaque.com> Date: Wed, 26 Oct 2005 14:13:11 +0800 From: Dinesh Nair User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8b) Gecko/20050915 MIME-Version: 1.0 To: John Baldwin References: <435E3003.4050609@alphaque.com> <200510251327.59965.jhb@freebsd.org> <435E7D8C.90401@alphaque.com> <200510251610.53127.jhb@freebsd.org> In-Reply-To: <200510251610.53127.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: correct use of bus_dmamap_sync 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, 26 Oct 2005 06:13:36 -0000 On 10/26/05 04:10 John Baldwin said the following: > Yes, and on some archs the sync() operations do have memory barriers in place, > but there isn't any bounce buffering with bus_dmamem_alloc() memory. and in _bus_dmamap_load() in /usr/src/sys/i386/i386/busdma_machdep.c, apparently if the second argument to bus_dmamap_load (the pointer to bus_dmamap_t)) is NULL, the syscall code sets it to &nobounce_dmamap, a static struct which doesnt seem to be used/allocated, except within the syscall. what would the implications of using NULL for the dmamap address be ? > Well, you need it to get the physical address to pass to your device for it to > do DMA against. on freebsd 4.x, vtophys(buffer) returns the same value as the this address. (i.e, when the callback function from bus_dmamap_load() is called, the address of the segment returned is the same as vtophys(buffer)). this is the current observed behaviour on 4.x. >>have things changed between freebsd 4.x (which i'm using) and freebsd 5.x ? > I don't think so as far as the interface. the values of the BUS_DMASYNC_XXXX constants have changed though. they're an enum with values 0-3 in 4.x but in 5.x they're defined as 0x01, 0x02, 0x04 and 0x08. due to this, combining BUS_DMASYNC_XXX thru an OR could possibly give different behaviour on 4.x and 5.x. an example would be using (BUS_DMASYNC_POSTREAD|BUS_DMASYNC_PREWRITE) which would be 0x03 in freebsd 4.x and 0x06 in freebsd 5.x. the gotcha is that 0x03 in freebsd 4.x is BUS_DMASYNC_POSTWRITE. so therefore, BUS_DMASYNC_POSTREAD|BUS_DMASYNC_PREWRITE will be BUS_DMASYNC_POSTWRITE in 4.x which in the syscall is actually a no op. also, in both 4.x and 5.x, only POSTREAD and PREWRITE have any real meaning, as PREREAD and POSTWRITE are no ops. it's due to these that the importance of correctly using the correct PRE/POST READ/WRITE and in the correct places seem important and the source of my confusion. :) >>>thus when you send data to your device, that is a WRITE operation (even >>>though your device is doing a DMA to read data), and when you get data >>>back from your device, that is a READ operation (even though your device >>>is doing a DMA to write the data into the buffer). taking ruslan's suggestion, i looked up the HEAD manpage at http://www.freebsd.org/cgi/man.cgi?query=bus_dmamap_sync&apropos=0&sektion=0&manpath=FreeBSD+6.0-current&format=html i've quoted the relevant descriptions below: BUS_DMASYNC_PREWRITE Perform any synchronization required after an update of memory by the CPU but prior to DMA write operations. BUS_DMASYNC_POSTREAD Perform any synchronization required after DMA read operations, but prior to CPU access of the memory. which would indicate that we'd need to use POSTREAD /before/ reading the buffer and PREWRITE /after/ the CPU writes to the buffer, for the following pseudo code: /*cpu reads from device */ bus_dmamap_sync(..., BUS_DMASYNC_POSTREAD) memcpy(myreceivebuf, mappedreceivebuf) /* do some computation on data read from device */ /* cpu writes to device */ memcpy(mappedtransmitbuf, mytransmitbuf) bus_dmamap_sync(..., BUS_DMASYNC_PREWRITE) where mappedreceivebuf and mappedtransmitbuf is the bufferspace allocated in bus_dmamem_alloc() and myreceivebuf/mytransmitbuf is a temporary holding area before writing to the device. is this reasoning correct ? -- Regards, /\_/\ "All dogs go to heaven." dinesh@alphaque.com (0 0) http://www.alphaque.com/ +==========================----oOO--(_)--OOo----==========================+ | for a in past present future; do | | for b in clients employers associates relatives neighbours pets; do | | echo "The opinions here in no way reflect the opinions of my $a $b." | | done; done | +=========================================================================+ From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 26 08:25:28 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 161A416A41F for ; Wed, 26 Oct 2005 08:25:28 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C93E43D53 for ; Wed, 26 Oct 2005 08:25:24 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id BC0A0EB101D; Wed, 26 Oct 2005 16:25:22 +0800 (CST) Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id 64960-17; Wed, 26 Oct 2005 16:25:18 +0800 (CST) Received: from beastie.frontfree.net (unknown [211.71.95.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 8D476EB1037; Wed, 26 Oct 2005 16:25:16 +0800 (CST) Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id 41C22130FD9; Wed, 26 Oct 2005 16:25:10 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51035-12; Wed, 26 Oct 2005 16:25:09 +0800 (CST) Received: from [10.217.12.68] (sina152-194.staff.sina.com.cn [61.135.152.194]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by beastie.frontfree.net (Postfix) with ESMTP id C463A130C93; Wed, 26 Oct 2005 16:25:08 +0800 (CST) From: Xin LI To: freebsd-hackers@FreeBSD.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-d+sFaITjGw0SPWFkVk8H" Organization: The FreeBSD Simplified Chinese Project Date: Wed, 26 Oct 2005 16:25:01 +0800 Message-Id: <1130315101.810.5.camel@spirit> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port X-Virus-Scanned: amavisd-new at frontfree.net X-Virus-Scanned: amavisd-new at geekcn.org Cc: zhuyan@staff.sina.com.cn, LI Xin Subject: Is it possible to mmap() raw disk device? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2005 08:25:28 -0000 --=-d+sFaITjGw0SPWFkVk8H Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Dear folks, When we were trying to make a userland FS application we have encountered "Invalid Argument" when doing mmap() over an open descriptor to a disk device. The program goes here: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D #include #include #include /* mmap() */ #include #include #include int main(int argc, char *argv[]) { int fd; char *src, *dst; struct stat statbuf; dst =3D strdup("abcdefghijklmn"); if (dst =3D=3D NULL) { printf("Can not allocate memory\n"); exit(-1); } if ((fd =3D open("/dev/da2s1", O_RDWR | O_DIRECT)) < 0) printf("can't open for read/write"); if ((src =3D mmap(0, 10, PROT_WRITE | PROT_READ, MAP_SHARED, fd, 0)) =3D=3D (caddr_t) -1) { perror("mmap error for input"); return -1; } memcpy(dst, src, 10); /* does the file copy */ exit(0); } =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Do we need some special prerequisite before doing mmap()? According to the vm_mmap.c it seems that we should map a DTYPE_VNODE object, which looks somewhat confusing... Thanks in advance! Cheers, --=20 Xin LI http://www.delphij.net/ --=-d+sFaITjGw0SPWFkVk8H Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDXz1d/cVsHxFZiIoRAuweAJ4lkRXRjkXNUEP3Zk8Fv5EW89ODAwCghEjf s5YomQWnRju+otn6BzuCBFY= =yNeR -----END PGP SIGNATURE----- --=-d+sFaITjGw0SPWFkVk8H-- From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 26 08:50:17 2005 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 066CF16A421 for ; Wed, 26 Oct 2005 08:50:17 +0000 (GMT) (envelope-from dinesh@alphaque.com) Received: from ns2.alphaque.com (ns2.alphaque.com [202.75.47.153]) by mx1.FreeBSD.org (Postfix) with SMTP id BB00343D58 for ; Wed, 26 Oct 2005 08:50:11 +0000 (GMT) (envelope-from dinesh@alphaque.com) Received: (qmail 73720 invoked by uid 0); 26 Oct 2005 08:50:01 -0000 Received: from lucifer.net-gw.com (HELO prophet.alphaque.com) (202.75.47.153) by lucifer.net-gw.com with SMTP; 26 Oct 2005 08:50:01 -0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by prophet.alphaque.com (8.13.4/8.13.4) with ESMTP id j9Q8lAXO035557; Wed, 26 Oct 2005 16:47:10 +0800 (MYT) (envelope-from dinesh@alphaque.com) Message-ID: <435F428E.50609@alphaque.com> Date: Wed, 26 Oct 2005 16:47:10 +0800 From: Dinesh Nair User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8b) Gecko/20050915 MIME-Version: 1.0 To: Scott Long References: <435EEC56.9080708@samsco.org> In-Reply-To: <435EEC56.9080708@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org Subject: Re: [Fwd: Re: use of bus_dmamap_sync] 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, 26 Oct 2005 08:50:17 -0000 On 10/26/05 10:39 Scott Long said the following: > Apparently the original poster sent his question to me in private, then > sent it again to the mailing list right as I was responding in private. apologies on that, scott. an initial search only turned up your message in the archives, but spreading it wider (not confining the google to lists.freebsd.org) brought up more hits, and that made me post it into -hackers. do bear with me as i try to understand this. > Below is my response. Note that I edited it slightly to fix an error > that I found > bus_dmamap_sync(tag, map, BUS_DMASYNC_PREREAD); > Ask hardware for data > bus_dmamap_sync(tag, map, BUS_DMASYNC_POSTREAD); > >> >> read from readbuf (i'm assuming that device has put data in >> readbuf) >> POSITION B >> } in other words, the PREREAD/POSTREAD wrap around the device's access to memory, and not the CPU's ? > bus_dmamap_sync(tag, map, BUS_DMASYNC_PREWRITE); > notify hardware of the write > bus_dmamap_sync(tag, map, BUS_DMASYNC_POSTWRITE); > The point of the syncs is to do the proper memory barrier and cache > coherency magic between the CPU and the bus as well as do the memory > copies for bounce buffers. If you are dealing with statically mapped > buffers, i.e. for an rx/tx descriptor ring, then you'll want code however, reading thru the syscall code, bus_dmamem_alloc() sets the dmamap to NULL, and if it's null, bus_dmamap_sync() is not called at all. would this mean that if memory is allocated by bus_dmamem_alloc(), it does not need to be synced with bus_dmamap_sync() ? bus_dmamap_sync() only seems critical when a dma map is created with bus_dmamap_create() and the buffer space allocated dynamically thru contigmalloc. > well for storage devices where the load operation must succeed. It > doesn't work as well for network devices where the latency of the > indirect calls is measurable. So for that, I added > bus_dmamap_load_mbuf_sg(). It eliminates the callback function and > returns the scatter gather list directly. So, the above example would > be: i'm basically trying to debug a problem with a driver which works like a charm on freebsd 5.x, but somehow doesnt on freebsd 4.x. the source for the driver is /exactly/ the same on both systems. the symptoms i keep seeing are that the same data which is written out is also read in by the read routines, which is what made me suspect that somewhere the dma transfers were not happenning and stumbled upon this. > for each buffer. It's often better to pre-allocate the maps at init > time, put them on a list, and then just push and pop them off the list i do this, for each buffer, at init time. int *readbuf bus_dma_tag_create() bus_dmamem_alloc() bus_dmamap_load() int *writebuf bus_dma_tag_create() bus_dmamem_alloc() bus_dmamap_load() subsequently, the device interrupts once every ms (1000Hz) and the buffers are read/written to. in the interrupt handler, i currently have, bus_dmamap_sync(POSTREAD) read data from readbuf (readval = readbuf) write data to writebuf (writebuf = someval) bus_dmamap_sync(PREWRITE) i've left out PREREAD and POSTWRITE as both seem to be no ops in freebsd 4.x. this seems consistent with your explanation. is this correct ? -- Regards, /\_/\ "All dogs go to heaven." dinesh@alphaque.com (0 0) http://www.alphaque.com/ +==========================----oOO--(_)--OOo----==========================+ | for a in past present future; do | | for b in clients employers associates relatives neighbours pets; do | | echo "The opinions here in no way reflect the opinions of my $a $b." | | done; done | +=========================================================================+ From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 26 15:46:49 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B4CC16A41F for ; Wed, 26 Oct 2005 15:46:49 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 928A443D45 for ; Wed, 26 Oct 2005 15:46:48 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from [10.50.41.234] (Not Verified[10.50.41.234]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Wed, 26 Oct 2005 12:03:33 -0400 From: John Baldwin To: freebsd-hackers@freebsd.org Date: Wed, 26 Oct 2005 11:30:44 -0400 User-Agent: KMail/1.8.2 References: <435EEC56.9080708@samsco.org> <435F428E.50609@alphaque.com> In-Reply-To: <435F428E.50609@alphaque.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510261130.45506.jhb@freebsd.org> Cc: Scott Long Subject: Re: [Fwd: Re: use of bus_dmamap_sync] 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, 26 Oct 2005 15:46:49 -0000 On Wednesday 26 October 2005 04:47 am, Dinesh Nair wrote: > On 10/26/05 10:39 Scott Long said the following: > > Apparently the original poster sent his question to me in private, then > > sent it again to the mailing list right as I was responding in private. > > apologies on that, scott. an initial search only turned up your message in > the archives, but spreading it wider (not confining the google to > lists.freebsd.org) brought up more hits, and that made me post it into > -hackers. > > do bear with me as i try to understand this. > > > Below is my response. Note that I edited it slightly to fix an error > > that I found > > > > bus_dmamap_sync(tag, map, BUS_DMASYNC_PREREAD); > > Ask hardware for data > > bus_dmamap_sync(tag, map, BUS_DMASYNC_POSTREAD); > > > >> read from readbuf (i'm assuming that device has put data in > >> readbuf) > >> POSITION B > >> } > > in other words, the PREREAD/POSTREAD wrap around the device's access to > memory, and not the CPU's ? Yes, scott's notes are more correct than mine here. > > bus_dmamap_sync(tag, map, BUS_DMASYNC_PREWRITE); > > notify hardware of the write > > bus_dmamap_sync(tag, map, BUS_DMASYNC_POSTWRITE); > > > > The point of the syncs is to do the proper memory barrier and cache > > coherency magic between the CPU and the bus as well as do the memory > > copies for bounce buffers. If you are dealing with statically mapped > > buffers, i.e. for an rx/tx descriptor ring, then you'll want code > > however, reading thru the syscall code, bus_dmamem_alloc() sets the dmamap > to NULL, and if it's null, bus_dmamap_sync() is not called at all. would > this mean that if memory is allocated by bus_dmamem_alloc(), it does not > need to be synced with bus_dmamap_sync() ? Perhaps on i386. Each arch implements sync(). Argh, it does look like the memory barriers needed on e.g., Alpha aren't used with static buffers because of the map != NULL check in sys/busdma.h. *sigh* I guess archs that need membars even without bounce buffers need to always allocate and setup a bus_dmamap. None of that matters for i386 though. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 26 15:54:26 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9518016A421; Wed, 26 Oct 2005 15:54:26 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBC3B43D48; Wed, 26 Oct 2005 15:54:22 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id j9QFsHOD023912; Wed, 26 Oct 2005 09:54:17 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <435FA6A9.4000600@samsco.org> Date: Wed, 26 Oct 2005 09:54:17 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <435EEC56.9080708@samsco.org> <435F428E.50609@alphaque.com> <200510261130.45506.jhb@freebsd.org> In-Reply-To: <200510261130.45506.jhb@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-hackers@freebsd.org Subject: Re: [Fwd: Re: use of bus_dmamap_sync] 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, 26 Oct 2005 15:54:26 -0000 John Baldwin wrote: > On Wednesday 26 October 2005 04:47 am, Dinesh Nair wrote: > >>On 10/26/05 10:39 Scott Long said the following: >> >>>Apparently the original poster sent his question to me in private, then >>>sent it again to the mailing list right as I was responding in private. >> >>apologies on that, scott. an initial search only turned up your message in >>the archives, but spreading it wider (not confining the google to >>lists.freebsd.org) brought up more hits, and that made me post it into >>-hackers. >> >>do bear with me as i try to understand this. >> >> >>>Below is my response. Note that I edited it slightly to fix an error >>>that I found >>> >>> bus_dmamap_sync(tag, map, BUS_DMASYNC_PREREAD); >>> Ask hardware for data >>> bus_dmamap_sync(tag, map, BUS_DMASYNC_POSTREAD); >>> >>> >>>> read from readbuf (i'm assuming that device has put data in >>>> readbuf) >>>> POSITION B >>>>} >> >>in other words, the PREREAD/POSTREAD wrap around the device's access to >>memory, and not the CPU's ? > > > Yes, scott's notes are more correct than mine here. > > >>> bus_dmamap_sync(tag, map, BUS_DMASYNC_PREWRITE); >>> notify hardware of the write >>> bus_dmamap_sync(tag, map, BUS_DMASYNC_POSTWRITE); >>> >>>The point of the syncs is to do the proper memory barrier and cache >>>coherency magic between the CPU and the bus as well as do the memory >>>copies for bounce buffers. If you are dealing with statically mapped >>>buffers, i.e. for an rx/tx descriptor ring, then you'll want code >> >>however, reading thru the syscall code, bus_dmamem_alloc() sets the dmamap >>to NULL, and if it's null, bus_dmamap_sync() is not called at all. would >>this mean that if memory is allocated by bus_dmamem_alloc(), it does not >>need to be synced with bus_dmamap_sync() ? > The value of the map is an implementation detail, which is why it's an opaque typedef. Portable code should always assume that the map has valid data. Now, specifically for i386, if you have a device with a 4GB address limit, and it has no data alignment constraints (unlike twe), and you are not using PAE, then yes the map will be NULL and the syncs will do nothing. Assuming that all three of these cases are false is not good, though. > > Perhaps on i386. Each arch implements sync(). Argh, it does look like the > memory barriers needed on e.g., Alpha aren't used with static buffers because > of the map != NULL check in sys/busdma.h. *sigh* I guess archs that need > membars even without bounce buffers need to always allocate and setup a > bus_dmamap. None of that matters for i386 though. > Feel free to fix alpha. Again, long ago, I thought that alpha pretended to be coherent in the 2GB DMA window that we use so that it could be more like i386. If that's not true then that's fine. If you need to make structural changes to the MI code on order to fix alpha, please let me know. Scott From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 26 16:12:40 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7AADD16A41F for ; Wed, 26 Oct 2005 16:12:40 +0000 (GMT) (envelope-from dinesh@alphaque.com) Received: from ns2.alphaque.com (ns2.alphaque.com [202.75.47.153]) by mx1.FreeBSD.org (Postfix) with SMTP id D900643D46 for ; Wed, 26 Oct 2005 16:12:38 +0000 (GMT) (envelope-from dinesh@alphaque.com) Received: (qmail 78737 invoked by uid 0); 26 Oct 2005 16:12:35 -0000 Received: from lucifer.net-gw.com (HELO prophet.alphaque.com) (202.75.47.153) by lucifer.net-gw.com with SMTP; 26 Oct 2005 16:12:35 -0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by prophet.alphaque.com (8.13.4/8.13.4) with ESMTP id j9QG6mvD000833; Thu, 27 Oct 2005 00:06:49 +0800 (MYT) (envelope-from dinesh@alphaque.com) Message-ID: <435FA998.2050409@alphaque.com> Date: Thu, 27 Oct 2005 00:06:48 +0800 From: Dinesh Nair User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8b) Gecko/20050915 MIME-Version: 1.0 To: Scott Long References: <435EEC56.9080708@samsco.org> <435F428E.50609@alphaque.com> <200510261130.45506.jhb@freebsd.org> <435FA6A9.4000600@samsco.org> In-Reply-To: <435FA6A9.4000600@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: [Fwd: Re: use of bus_dmamap_sync] 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, 26 Oct 2005 16:12:40 -0000 On 10/26/05 23:54 Scott Long said the following: > The value of the map is an implementation detail, which is why it's an > opaque typedef. Portable code should always assume that the map has > valid data. Now, specifically for i386, if you have a device with a right, so for portability's sake, bus_dmamap_sync should be used anyway. > twe), and you are not using PAE, then yes the map will be NULL and the > syncs will do nothing. Assuming that all three of these cases are false > is not good, though. well, they are in my situation, so obviously bus dma is not the cause of the problem i'm seeing. thanx to both scottl and jhb for the explanation. this throws a lot of light onto the handling of dma access to devices for me. -- Regards, /\_/\ "All dogs go to heaven." dinesh@alphaque.com (0 0) http://www.alphaque.com/ +==========================----oOO--(_)--OOo----==========================+ | for a in past present future; do | | for b in clients employers associates relatives neighbours pets; do | | echo "The opinions here in no way reflect the opinions of my $a $b." | | done; done | +=========================================================================+ From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 26 16:27:07 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A669016A42C for ; Wed, 26 Oct 2005 16:27:07 +0000 (GMT) (envelope-from ray@redshift.com) Received: from mail.quickmeet.com (quickmeet.com [216.228.17.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5498143D53 for ; Wed, 26 Oct 2005 16:27:07 +0000 (GMT) (envelope-from ray@redshift.com) Received: from workstation (workstation [192.168.20.250]) by mail.quickmeet.com (Postfix) with SMTP id 9B32A17032; Wed, 26 Oct 2005 09:00:00 -0700 (PDT) Message-Id: <3.0.1.32.20051026092709.00a67828@pop.redshift.com> X-Mailer: na X-Sender: redshift.com Date: Wed, 26 Oct 2005 09:27:09 -0700 To: freebsd-hackers@freebsd.org From: ray@redshift.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Xyplex terminal server via ttyd0 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, 26 Oct 2005 16:27:07 -0000 Here's one for anyone bored out there :-) I have a cluster here running FreeBSD and years back I got an old Xyplex Maxserver 40 1640 terminal server off ebay. Basically it's a box that has a bunch of serial ports on it and one 10 mbit ethernet port. You assign an IP# to the ethernet port, then run a serial cable from one of the 40 ports on the back to the COM1 serial port of your servers. Okay, so no problem, works great... except when it comes to terminal emulation. Something is a bit funky there and I can't track it down. Here is where I am stuck. If anyone has any ideas, lay 'em on me. The workstation is Windows XP running Putty SSH. If I SSH into the server via the network, everything works perfectly. But if I telnet into the terminal server and end up at the ttyd0 (serial port 1 on the FreeBSD server), I get a console/login prompt okay, and I'm able to login, but once I get to the bash prompt, the emulation is hosed. For example, if I do 'more' on a file, it just rolls over on itself as it displays. Forget vi or pico. I've edited the /etc/ttys file and changed the following serial port line (running kill -1 1 each time): from: ttyd0 "/usr/libexec/getty std.9600" xterm on secure to all of the following - all with about the same results: ttyd0 "/usr/libexec/getty std.9600" cons25 on secure ttyd0 "/usr/libexec/getty std.9600" xterm-color on secure ttyd0 "/usr/libexec/getty std.9600" vt100 on secure ttyd0 "/usr/libexec/getty std.9600" vt200 on secure ttyd0 "/usr/libexec/getty std.9600" ansi on secure ttyd0 "/usr/libexec/getty std.9600" unknown on secure ttyd0 "/usr/libexec/getty std.9600" network on secure I've tried export TERM=VT100 (right now my default is xterm-color). I tried naming away .profile, no luck. I've read the Putty FAQ and the FreeBSD handbook, but still can't seem to hit on what is causing the problem. I don't quite get why going across the terminal server would be so radically different than coming in via the network. Anyone have any ideas off hand? I can live with how it is now, since this is just an emergency thing to reboot the server, but it would be nice to be able to edit and view files, instead of just being limited to 'shutdown -r now' from the serial port. BTW, I tried telnet via MS-DOS and still the same... so it seems like it's not a Putty issue per se, but maybe something having to do with how the emulation is handled across the serial port vs. the network? Any ideas would be most appreciated, thanks! Ray From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 26 00:09:20 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 36F2A16A41F for ; Wed, 26 Oct 2005 00:09:20 +0000 (GMT) (envelope-from lennart@augustsson.net) Received: from calvin.augustsson.net (1-1-8-21a.gan.gbg.bostream.se [82.182.103.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC8A443D58 for ; Wed, 26 Oct 2005 00:09:18 +0000 (GMT) (envelope-from lennart@augustsson.net) Received: from [172.16.4.2] (dyn-2-g.augustsson.net [172.16.4.2]) (authenticated bits=0) by calvin.augustsson.net (8.13.3/8.12.11) with ESMTP id j9Q097tK028362; Wed, 26 Oct 2005 02:09:08 +0200 (MEST) Message-ID: <435EC923.10209@augustsson.net> Date: Wed, 26 Oct 2005 02:09:07 +0200 From: Lennart Augustsson User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050528) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hselasky@c2i.net References: <200510242235.48403.hselasky@c2i.net> In-Reply-To: <200510242235.48403.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-1.6 (calvin.augustsson.net [82.182.103.12]); Wed, 26 Oct 2005 02:09:08 +0200 (MEST) X-Mailman-Approved-At: Wed, 26 Oct 2005 16:44:32 +0000 Cc: freebsd-hackers@freebsd.org, tech-kern@netbsd.org Subject: Re: FreeBSD 5/6/7 kernel emulator for NetBSD 2.x 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, 26 Oct 2005 00:09:20 -0000 You'll never get a driver that looks exactly right for one OS to work with another, even with an emulation layer. For instance, FreeBSD doesn't have an activate method for device drivers whereas NetBSD and OpenBSD do. And there are examples of the reverse. So shared drivers will have some clutter. Personally, I prefer the macros. -- Lennart Hans Petter Selasky wrote: > Hi, > > I have made an effort on making a FreeBSD 5/6/7 kernel emulator for NetBSD > 2.x. Many device drivers are shared between these two operating systems, and > I think a lot of work can be saved when it comes to porting code and patches > forth and back. Currently this emulator makes my FreeBSD PCI ISDN driver load > and run on NetBSD. I have chosen to make FreeBSD 5+ the standard for several > reasons: > > - all drivers are dynamically linked through use of the "section attribute" in > the "C" compiler. > > - "/dev" is a file system that can be manipulated from the kernel, without > intervention from "mknod". > > - All I/O resources are allocated through a single function, > "bus_alloc_resource()". > > - And more. > > > Here is a case in which such a kernel emulator can be used: > > I think it is a good idea that FreeBSD and NetBSD shares as many USB drivers > as possible. But sharing USB device drivers like > "/usr/src/sys/dev/usb/ulpt.c", is difficult, because two quite different > interfaces are used to create devices in "/dev/". And it is not only this, > but also how USB device drivers register in the kernel so that they get > probed. Here one has tried to hide system differences by using macros. > > I think one should rather have some external library that hides these system > differences, so that there is only one branch for the USB device drivers, for > both NetBSD and FreeBSD, and probably the other *BSD's aswell, if possible. > That means a branch without "ifdefs" for every operating system it is > supposed to compile on. Then one has got to choose the library interface, and > I would say that "FreeBSD 5+ specific" is the best candidate so far. > > I see that one can move many USB drivers over to FreeBSD, merge everything > together, expand all the macros in "/usr/src/sys/dev/usb/usb_port.h", and > then copy it back to NetBSD which then must have a FreeBSD kernel emulator in > the kernel. When the drivers are updated later, it will be very easy to cross > port the changes, and at the same time the USB system is brought out of the > Giant lock. Also it will be easier to create portable USB kernel device > drivers. > > > Anyone have any opinion about what system is better to use as a standard in > the kernel? > > > > Main features: > > - Implements FreeBSD's devfs on NetBSD. > > - Support for mutexes, mtx_xxxx() and msleep() > > - Support for probe/attach and general use of PCI devices > > - Support for SYSINIT() > > - Support for DRIVER_MODULE() > > - And some other things found in FreeBSD 5/6/7 > > > Here is a tarball (only tested on i386 and compatible, NetBSD 2.x): > > http://home.c2i.net/hselasky/isdn4bsd/privat/temporary/new_ihfc_1_5_5_NetBSD.tar.bz2 > > > --HPS > From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 26 17:17:49 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B12E616A41F for ; Wed, 26 Oct 2005 17:17:49 +0000 (GMT) (envelope-from dr2867@pacbell.net) Received: from smtp111.sbc.mail.mud.yahoo.com (smtp111.sbc.mail.mud.yahoo.com [68.142.198.210]) by mx1.FreeBSD.org (Postfix) with SMTP id BA81243D45 for ; Wed, 26 Oct 2005 17:17:48 +0000 (GMT) (envelope-from dr2867@pacbell.net) Received: (qmail 36803 invoked from network); 26 Oct 2005 17:17:48 -0000 Received: from unknown (HELO ?192.168.0.190?) (dr2867.business@pacbell.net@68.126.211.246 with plain) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 26 Oct 2005 17:17:47 -0000 Message-ID: <435FBA42.1070604@pacbell.net> Date: Wed, 26 Oct 2005 10:17:54 -0700 From: Daniel Rudy User-Agent: Mozilla/5.0 (X11R6; UNIX; FreeBSD/i386 5.4-RELEASE-p7; en-US; ja-JP; rv:1.7.12) Gecko/20050915 MultiZilla/1.6.2.0c Mnenhy/0.7.2.0 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: soc-victor@freebsd.org References: <49402550510240728y555979c9i2fe4adc73137a1e7@mail.gmail.com> <435E6F9C.9090008@pacbell.net> <49402550510251250g66a89037q9a1eb3bdbedf94c3@mail.gmail.com> In-Reply-To: <49402550510251250g66a89037q9a1eb3bdbedf94c3@mail.gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: devinfo(3) 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: Wed, 26 Oct 2005 17:17:49 -0000 At about the time of 10/25/2005 12:50 PM, victor cruceru stated the following: > Hi Daniel, > Yes, this is the fix. And yes, I think that the bug was reported (at > least on a mailing list...) > BTW: I dare to suggest to fully upgrade your system to the "latest" > 6.0, it is a huge step forward from 5.4. Before doing this you may > want to give it a try by booting from a CD and check that your hw is > fully functional (and detected). For stability reasons, I don't run the absolute latest software. When 6.x comes out, I'll wait awhile for the bugs to be worked out before I migrate to it. As for hardware, I tend to run FreeBSD on older hardware, so I don't think that there will be a problem with the hardware being properly detected. > To check if it is your mistake or another bug in libdevinfo, you may > want to run the associated tool (man -k devinfo). > Hope this helps. > Actually, the devinfo tool was working the whole time. I tried the devinfo tool before I decided to use the libdevinfo.so library. I've tested it with my code and it is working now with that one line of additional code. > On 10/25/05, Daniel Rudy wrote: > >>At about the time of 10/24/2005 7:28 AM, victor cruceru stated the >>following: >> >>>Daniel, >>>What is the OS version you are using when this is happening? >>>Did you try to update the libdevinfo (using cvsup for example) to a >>>newer version? >>>I think that under the original 5.4 it is a bug in devinfo(4) with the >>>described behaviour below. >> >>I'm running 5.4-RELEASE. >> >>When you mentioned that it might be a bug, I went and looked at >>/usr/src/lib/libdevinfo/devinfo.c using the cvs web depository. I found >>that devinfo_generation = 0 was added to the end of the devinfo_free >>function starting at line 367. I added the code and recompiled just >>that library, and now everything seems to be working ok, except now I'm >>getting a bunch of garbage on the serial number of the USB flash drive. >> I'm not sure if it's my code, or if it's a bug in the library. >> >>-- >>Daniel Rudy >> > > > > -- > victor cruceru > ------------------------------------------------ > Non est respondendum ad omnia. > ( Cicero, Pro Murena Oratio ) > ------------------------------------------------ > -- Daniel Rudy From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 26 17:23:34 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E31C516A422 for ; Wed, 26 Oct 2005 17:23:34 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E73343D46 for ; Wed, 26 Oct 2005 17:23:34 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from [10.50.41.234] (Not Verified[10.50.41.234]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Wed, 26 Oct 2005 13:39:37 -0400 From: John Baldwin To: Scott Long Date: Wed, 26 Oct 2005 13:24:02 -0400 User-Agent: KMail/1.8.2 References: <435EEC56.9080708@samsco.org> <200510261130.45506.jhb@freebsd.org> <435FA6A9.4000600@samsco.org> In-Reply-To: <435FA6A9.4000600@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510261324.03790.jhb@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: [Fwd: Re: use of bus_dmamap_sync] 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, 26 Oct 2005 17:23:35 -0000 On Wednesday 26 October 2005 11:54 am, Scott Long wrote: > > Perhaps on i386. Each arch implements sync(). Argh, it does look like > > the memory barriers needed on e.g., Alpha aren't used with static buffers > > because of the map != NULL check in sys/busdma.h. *sigh* I guess archs > > that need membars even without bounce buffers need to always allocate and > > setup a bus_dmamap. None of that matters for i386 though. > > Feel free to fix alpha. Again, long ago, I thought that alpha pretended > to be coherent in the 2GB DMA window that we use so that it could be > more like i386. If that's not true then that's fine. If you need to > make structural changes to the MI code on order to fix alpha, please let > me know. No, I'm just a moron. Alpha uses the nobounce_map for static buffers, so bus_dmamap_sync will use the appropriate membars. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 26 17:23:36 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B826916A422 for ; Wed, 26 Oct 2005 17:23:36 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5922343D46 for ; Wed, 26 Oct 2005 17:23:36 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from [10.50.41.234] (Not Verified[10.50.41.234]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Wed, 26 Oct 2005 13:39:37 -0400 From: John Baldwin To: Dinesh Nair Date: Wed, 26 Oct 2005 13:20:15 -0400 User-Agent: KMail/1.8.2 References: <435E3003.4050609@alphaque.com> <200510251610.53127.jhb@freebsd.org> <435F1E77.30007@alphaque.com> In-Reply-To: <435F1E77.30007@alphaque.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510261320.16175.jhb@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: correct use of bus_dmamap_sync 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, 26 Oct 2005 17:23:36 -0000 On Wednesday 26 October 2005 02:13 am, Dinesh Nair wrote: > On 10/26/05 04:10 John Baldwin said the following: > > Yes, and on some archs the sync() operations do have memory barriers in > > place, but there isn't any bounce buffering with bus_dmamem_alloc() > > memory. > > and in _bus_dmamap_load() in /usr/src/sys/i386/i386/busdma_machdep.c, > apparently if the second argument to bus_dmamap_load (the pointer to > bus_dmamap_t)) is NULL, the syscall code sets it to &nobounce_dmamap, a > static struct which doesnt seem to be used/allocated, except within the > syscall. > > what would the implications of using NULL for the dmamap address be ? > > > Well, you need it to get the physical address to pass to your device for > > it to do DMA against. > > on freebsd 4.x, vtophys(buffer) returns the same value as the this address. > (i.e, when the callback function from bus_dmamap_load() is called, the > address of the segment returned is the same as vtophys(buffer)). this is > the current observed behaviour on 4.x. On i386, yes. It won't on sparc64 when using an IOMMU for example. The whole point of using bus_dma is to not use vtophys() since by doing that you are assuming that the PA's used by the CPU map 1:1 to the addresses used by your device to do DMA, and on architectures with an IOMMU such as sparc64, G5 ppc boxes, and probably amd64 boxes in the future, that is not a valid assumption at all. > >>have things changed between freebsd 4.x (which i'm using) and freebsd 5.x > >> ? > > > > I don't think so as far as the interface. > > the values of the BUS_DMASYNC_XXXX constants have changed though. they're > an enum with values 0-3 in 4.x but in 5.x they're defined as 0x01, 0x02, > 0x04 and 0x08. due to this, combining BUS_DMASYNC_XXX thru an OR could > possibly give different behaviour on 4.x and 5.x. > > an example would be using (BUS_DMASYNC_POSTREAD|BUS_DMASYNC_PREWRITE) which > would be 0x03 in freebsd 4.x and 0x06 in freebsd 5.x. the gotcha is that > 0x03 in freebsd 4.x is BUS_DMASYNC_POSTWRITE. so therefore, > BUS_DMASYNC_POSTREAD|BUS_DMASYNC_PREWRITE will be BUS_DMASYNC_POSTWRITE in > 4.x which in the syscall is actually a no op. Yes, that is fugly. Just don't use the | versions for now I would guess. > also, in both 4.x and 5.x, only POSTREAD and PREWRITE have any real > meaning, as PREREAD and POSTWRITE are no ops. On i386, yes. Eventually those operations might be used to manipulate IOMMU mappings for example. > it's due to these that the importance of correctly using the correct > PRE/POST READ/WRITE and in the correct places seem important and the source > of my confusion. :) > > >>>thus when you send data to your device, that is a WRITE operation (even > >>>though your device is doing a DMA to read data), and when you get data > >>>back from your device, that is a READ operation (even though your device > >>>is doing a DMA to write the data into the buffer). > > taking ruslan's suggestion, i looked up the HEAD manpage at > http://www.freebsd.org/cgi/man.cgi?query=bus_dmamap_sync&apropos=0&sektion= >0&manpath=FreeBSD+6.0-current&format=html > > i've quoted the relevant descriptions below: > > BUS_DMASYNC_PREWRITE > Perform any synchronization required after an update of memory by the CPU > but prior to DMA write operations. > > BUS_DMASYNC_POSTREAD > Perform any synchronization required after DMA read operations, but prior > to CPU access of the memory. > > which would indicate that we'd need to use POSTREAD /before/ reading the > buffer and PREWRITE /after/ the CPU writes to the buffer, for the following > pseudo code: > > /*cpu reads from device */ > bus_dmamap_sync(..., BUS_DMASYNC_POSTREAD) > memcpy(myreceivebuf, mappedreceivebuf) > > /* do some computation on data read from device */ > > /* cpu writes to device */ > memcpy(mappedtransmitbuf, mytransmitbuf) > bus_dmamap_sync(..., BUS_DMASYNC_PREWRITE) > > where mappedreceivebuf and mappedtransmitbuf is the bufferspace allocated > in bus_dmamem_alloc() and myreceivebuf/mytransmitbuf is a temporary holding > area before writing to the device. > > is this reasoning correct ? Yes. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 26 18:25:28 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 19F1B16A41F; Wed, 26 Oct 2005 18:25:28 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 97E0E43D48; Wed, 26 Oct 2005 18:25:27 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from [10.50.41.234] (Not Verified[10.50.41.234]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Wed, 26 Oct 2005 14:42:12 -0400 From: John Baldwin To: freebsd-hackers@freebsd.org Date: Wed, 26 Oct 2005 14:25:13 -0400 User-Agent: KMail/1.8.2 References: <49402550510240728y555979c9i2fe4adc73137a1e7@mail.gmail.com> <49402550510251250g66a89037q9a1eb3bdbedf94c3@mail.gmail.com> <435FBA42.1070604@pacbell.net> In-Reply-To: <435FBA42.1070604@pacbell.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510261425.14759.jhb@freebsd.org> Cc: soc-victor@freebsd.org, Daniel Rudy Subject: Re: devinfo(3) 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: Wed, 26 Oct 2005 18:25:28 -0000 On Wednesday 26 October 2005 01:17 pm, Daniel Rudy wrote: > At about the time of 10/25/2005 12:50 PM, victor cruceru stated the > > following: > > Hi Daniel, > > Yes, this is the fix. And yes, I think that the bug was reported (at > > least on a mailing list...) > > BTW: I dare to suggest to fully upgrade your system to the "latest" > > 6.0, it is a huge step forward from 5.4. Before doing this you may > > want to give it a try by booting from a CD and check that your hw is > > fully functional (and detected). > > For stability reasons, I don't run the absolute latest software. When > 6.x comes out, I'll wait awhile for the bugs to be worked out before I > migrate to it. As for hardware, I tend to run FreeBSD on older > hardware, so I don't think that there will be a problem with the > hardware being properly detected. FYI, I merged that fix back to RELENG_5 a while ago, so it will be fixed in 5.5 as well as 6.0. > > To check if it is your mistake or another bug in libdevinfo, you may > > want to run the associated tool (man -k devinfo). > > Hope this helps. > > Actually, the devinfo tool was working the whole time. I tried the > devinfo tool before I decided to use the libdevinfo.so library. I've > tested it with my code and it is working now with that one line of > additional code. Yes, devinfo(1) only traverses the tree once, so it didn't run into this bug. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 26 18:30:08 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.ORG Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A78C016A420; Wed, 26 Oct 2005 18:30:08 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3775C43D46; Wed, 26 Oct 2005 18:30:08 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.3/8.13.1) with ESMTP id j9QISFXX052429; Wed, 26 Oct 2005 14:28:15 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.3/8.13.1/Submit) id j9QISEgg052428; Wed, 26 Oct 2005 14:28:14 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Wed, 26 Oct 2005 14:28:14 -0400 From: David Schultz To: nocool Message-ID: <20051026182814.GA52373@VARK.MIT.EDU> Mail-Followup-To: nocool , freebsd-hackers , freebsd-current , delphij References: <20051024134527.31E53F02@smtp.263.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051024134527.31E53F02@smtp.263.net> Cc: freebsd-hackers , freebsd-current , delphij Subject: Re: Re: where to release proc.p_stats 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, 26 Oct 2005 18:30:08 -0000 On Mon, Oct 24, 2005, nocool wrote: > Can memory management system utilize COW to supply zero-filled page to kernel or user process. > That is to say: > When processes want zeroed page, we give them a mirror of one already zerod pages. If they just > read, they can read zero from the back page. > We needn't really alloc a new zero-filled page until they modify the page. > So we can saving many time from filling pages with zero, if some process just want read from them. I don't know whether this is done now, but yes, we could do copy-on-write (really, allocate-on-write) for heap pages that have never been written to. But this is a sort of silly optimization that would only affect naive benchmarks. The value stored at a location on the heap that has never been written to is unspecified, so correct applications would never notice this change. Incorrect applications might use fewer pages, but they could also take more traps (one for the read and one for the write), so this change might actually reduce performance. From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 26 20:00:55 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C8BBB16A41F for ; Wed, 26 Oct 2005 20:00:55 +0000 (GMT) (envelope-from dinesh@alphaque.com) Received: from ns2.alphaque.com (ns2.alphaque.com [202.75.47.153]) by mx1.FreeBSD.org (Postfix) with SMTP id 8014843D45 for ; Wed, 26 Oct 2005 20:00:54 +0000 (GMT) (envelope-from dinesh@alphaque.com) Received: (qmail 81459 invoked by uid 0); 26 Oct 2005 20:00:52 -0000 Received: from lucifer.net-gw.com (HELO prophet.alphaque.com) (202.75.47.153) by lucifer.net-gw.com with SMTP; 26 Oct 2005 20:00:52 -0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by prophet.alphaque.com (8.13.4/8.13.4) with ESMTP id j9QJvovp001930; Thu, 27 Oct 2005 03:57:50 +0800 (MYT) (envelope-from dinesh@alphaque.com) Message-ID: <435FDFBD.3000506@alphaque.com> Date: Thu, 27 Oct 2005 03:57:49 +0800 From: Dinesh Nair User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8b) Gecko/20050915 MIME-Version: 1.0 To: John Baldwin References: <435E3003.4050609@alphaque.com> <200510251610.53127.jhb@freebsd.org> <435F1E77.30007@alphaque.com> <200510261320.16175.jhb@freebsd.org> In-Reply-To: <200510261320.16175.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: correct use of bus_dmamap_sync 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, 26 Oct 2005 20:00:55 -0000 On 10/27/05 01:20 John Baldwin said the following: > On i386, yes. It won't on sparc64 when using an IOMMU for example. The whole > point of using bus_dma is to not use vtophys() since by doing that you are righto, so for platform portability, we'd still need to use it there though. > Yes, that is fugly. Just don't use the | versions for now I would guess. which would mean than backporting stuff from 5.x would need to be double checked for | usage. >>is this reasoning correct ? > Yes. excellent, thanx jhb. -- Regards, /\_/\ "All dogs go to heaven." dinesh@alphaque.com (0 0) http://www.alphaque.com/ +==========================----oOO--(_)--OOo----==========================+ | for a in past present future; do | | for b in clients employers associates relatives neighbours pets; do | | echo "The opinions here in no way reflect the opinions of my $a $b." | | done; done | +=========================================================================+ From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 26 20:16:29 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D85116A41F; Wed, 26 Oct 2005 20:16:29 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E00243D45; Wed, 26 Oct 2005 20:16:26 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id j9QKGMmt053955; Wed, 26 Oct 2005 14:16:22 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <435FE416.1050703@samsco.org> Date: Wed, 26 Oct 2005 14:16:22 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <435E3003.4050609@alphaque.com> <200510251610.53127.jhb@freebsd.org> <435F1E77.30007@alphaque.com> <200510261320.16175.jhb@freebsd.org> In-Reply-To: <200510261320.16175.jhb@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-hackers@freebsd.org Subject: Re: correct use of bus_dmamap_sync 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, 26 Oct 2005 20:16:29 -0000 John Baldwin wrote: > On Wednesday 26 October 2005 02:13 am, Dinesh Nair wrote: > >>On 10/26/05 04:10 John Baldwin said the following: >> >>>Yes, and on some archs the sync() operations do have memory barriers in >>>place, but there isn't any bounce buffering with bus_dmamem_alloc() >>>memory. >> >>and in _bus_dmamap_load() in /usr/src/sys/i386/i386/busdma_machdep.c, >>apparently if the second argument to bus_dmamap_load (the pointer to >>bus_dmamap_t)) is NULL, the syscall code sets it to &nobounce_dmamap, a >>static struct which doesnt seem to be used/allocated, except within the >>syscall. >> >>what would the implications of using NULL for the dmamap address be ? >> >> >>>Well, you need it to get the physical address to pass to your device for >>>it to do DMA against. >> >>on freebsd 4.x, vtophys(buffer) returns the same value as the this address. >> (i.e, when the callback function from bus_dmamap_load() is called, the >>address of the segment returned is the same as vtophys(buffer)). this is >>the current observed behaviour on 4.x. > > > On i386, yes. It won't on sparc64 when using an IOMMU for example. The whole > point of using bus_dma is to not use vtophys() since by doing that you are > assuming that the PA's used by the CPU map 1:1 to the addresses used by your > device to do DMA, and on architectures with an IOMMU such as sparc64, G5 ppc > boxes, and probably amd64 boxes in the future, that is not a valid assumption > at all. > Well, the point of busdma is to make the DMA mechanics transparent to the driver. It's not just about IOMMUs, it's also about handling alignment constraints and address boundaries and exclusion areas. It's a set-it-and-forget-it deal. Set the requirements and constraints in the tag, follow the API, and the details Just Work without having to worry about them. > >>>>have things changed between freebsd 4.x (which i'm using) and freebsd 5.x >>>>? >>> >>>I don't think so as far as the interface. >> >>the values of the BUS_DMASYNC_XXXX constants have changed though. they're >>an enum with values 0-3 in 4.x but in 5.x they're defined as 0x01, 0x02, >>0x04 and 0x08. due to this, combining BUS_DMASYNC_XXX thru an OR could >>possibly give different behaviour on 4.x and 5.x. >> >>an example would be using (BUS_DMASYNC_POSTREAD|BUS_DMASYNC_PREWRITE) which >>would be 0x03 in freebsd 4.x and 0x06 in freebsd 5.x. the gotcha is that >>0x03 in freebsd 4.x is BUS_DMASYNC_POSTWRITE. so therefore, >>BUS_DMASYNC_POSTREAD|BUS_DMASYNC_PREWRITE will be BUS_DMASYNC_POSTWRITE in >>4.x which in the syscall is actually a no op. > > > Yes, that is fugly. Just don't use the | versions for now I would guess. > Trying to maintain source compatibility between 4.x and 5.x/6.x will make you encounter a whole lot more problems than just this. > >>also, in both 4.x and 5.x, only POSTREAD and PREWRITE have any real >>meaning, as PREREAD and POSTWRITE are no ops. > > > On i386, yes. Eventually those operations might be used to manipulate IOMMU > mappings for example. > I honestly don't ever expect to see IOMMU code for i386. The IOMMU that is provided by the AGP bus is fairly limited in what it can do, and trying to coordinate its use with X would be simply a nightmare. I'm less clear on the IOMMU that exists for amd64 and whether it's a true IOMMU or just an aliasing of the AGP IOMMU. Scott From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 27 00:13:44 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE3CF16A41F for ; Thu, 27 Oct 2005 00:13:44 +0000 (GMT) (envelope-from dmw@unete.cl) Received: from qmail2.ifxnetworks.com (qmail2.ifxnetworks.com [200.110.128.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id C09DE43D5A for ; Thu, 27 Oct 2005 00:13:42 +0000 (GMT) (envelope-from dmw@unete.cl) Received: (qmail 14818 invoked from network); 27 Oct 2005 00:13:41 -0000 X-Spam-DCC: CollegeOfNewCaledonia: qmail2.ifxnetworks.com 1189; Body=1 Fuz1=1 Fuz2=1 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on qmail2.ifxnetworks.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.5 tests=none autolearn=disabled version=3.1.0 Received: from unknown (HELO hopto.org) ([200.73.82.13]) (envelope-sender ) by qmail2.ifxnetworks.com (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 27 Oct 2005 00:13:29 -0000 Received: from hopto.org (dmw@localhost.daemon.cl [127.0.0.1]) by hopto.org (8.13.4/8.13.1) with ESMTP id j9R0DvGi038392; Wed, 26 Oct 2005 21:13:57 -0300 (CLST) (envelope-from dmw@unete.cl) Received: (from dmw@localhost) by hopto.org (8.13.4/8.13.1/Submit) id j9R0Du5Q038391; Wed, 26 Oct 2005 21:13:56 -0300 (CLST) (envelope-from dmw@unete.cl) X-Authentication-Warning: dmw.hopto.org: dmw set sender to dmw@unete.cl using -f Date: Wed, 26 Oct 2005 21:13:55 -0300 From: Daniel Molina Wegener To: Chrystian Lopez Message-ID: <20051027001355.GA37986@dmw.hopto.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Description: mensaje Content-Disposition: inline Organization: DMW Cc: freebsd-hackers@freebsd.org Subject: Re: usb umass X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Molina Wegener List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2005 00:13:45 -0000 On Wed, Oct 26, 2005 at 05:08:24AM +0000, Chrystian Lopez wrote: > que onda hola estoy inetentando montar my memoria usbcon > usbdevs -v Ok, es un pendrive supongo. > me aparece con el driver usb0 Sera el dispositivo usb0?, ese es solo el puerto USB, no el dispositivo umass (pendrive). > y cuando quiero montarla con mount_msdosfs /dev /mnt /usb1 No puedes montar usb0 por que no es un dispositivo de bloques, revisa el log, o si se crea el dispositivo da0 en tu devfs cuando conectas el dispositivo umass (pendrive, mp3 player, etc.). > > me mando un mensaje diciendo /dev/usb1 block device require > Correcto, lo que debes hacer es montar el dispositivo umass, usando algo como: mount_msdos /dev/da0s1 /mnt/pendrive Deberias revisar el log... Cuando tengas dudas, te aconsejo usar la lista FreeBSD Questions, con la direccion questions at freebsd dot org. Atte. -- . 0 . | Daniel Molina Wegener . . 0 | dmw at unete dot cl 0 0 0 | FreeBSD Power User From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 27 05:07:58 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC35616A41F for ; Thu, 27 Oct 2005 05:07:58 +0000 (GMT) (envelope-from dr2867@pacbell.net) Received: from smtp108.sbc.mail.mud.yahoo.com (smtp108.sbc.mail.mud.yahoo.com [68.142.198.207]) by mx1.FreeBSD.org (Postfix) with SMTP id 860E143D48 for ; Thu, 27 Oct 2005 05:07:57 +0000 (GMT) (envelope-from dr2867@pacbell.net) Received: (qmail 38924 invoked from network); 27 Oct 2005 05:07:57 -0000 Received: from unknown (HELO ?192.168.0.190?) (dr2867.business@pacbell.net@68.126.211.246 with plain) by smtp108.sbc.mail.mud.yahoo.com with SMTP; 27 Oct 2005 05:07:56 -0000 Message-ID: <436060B2.5050203@pacbell.net> Date: Wed, 26 Oct 2005 22:08:02 -0700 From: Daniel Rudy User-Agent: Mozilla/5.0 (X11R6; UNIX; FreeBSD/i386 5.4-RELEASE-p7; en-US; ja-JP; rv:1.7.12) Gecko/20050915 MultiZilla/1.6.2.0c Mnenhy/0.7.2.0 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: John Baldwin References: <49402550510240728y555979c9i2fe4adc73137a1e7@mail.gmail.com> <49402550510251250g66a89037q9a1eb3bdbedf94c3@mail.gmail.com> <435FBA42.1070604@pacbell.net> <200510261425.14759.jhb@freebsd.org> In-Reply-To: <200510261425.14759.jhb@freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: soc-victor@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: devinfo(3) 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: Thu, 27 Oct 2005 05:07:59 -0000 At about the time of 10/26/2005 11:25 AM, John Baldwin stated the following: > On Wednesday 26 October 2005 01:17 pm, Daniel Rudy wrote: > >>At about the time of 10/25/2005 12:50 PM, victor cruceru stated the >> >>following: >> >>>Hi Daniel, >>>Yes, this is the fix. And yes, I think that the bug was reported (at >>>least on a mailing list...) >>>BTW: I dare to suggest to fully upgrade your system to the "latest" >>>6.0, it is a huge step forward from 5.4. Before doing this you may >>>want to give it a try by booting from a CD and check that your hw is >>>fully functional (and detected). >> >>For stability reasons, I don't run the absolute latest software. When >>6.x comes out, I'll wait awhile for the bugs to be worked out before I >>migrate to it. As for hardware, I tend to run FreeBSD on older >>hardware, so I don't think that there will be a problem with the >>hardware being properly detected. > > > FYI, I merged that fix back to RELENG_5 a while ago, so it will be fixed in > 5.5 as well as 6.0. Oh good, now I don't have to keep track of it when I go to 5.5 then. I'll still have to keep an eye on it for the security releases through the remainder of 5.4 though. >>>To check if it is your mistake or another bug in libdevinfo, you may >>>want to run the associated tool (man -k devinfo). >>>Hope this helps. >> >>Actually, the devinfo tool was working the whole time. I tried the >>devinfo tool before I decided to use the libdevinfo.so library. I've >>tested it with my code and it is working now with that one line of >>additional code. > > > Yes, devinfo(1) only traverses the tree once, so it didn't run into this bug. > I analyzed the source code for devinfo(8) and used as an example of how to use the devinfo(3) library. So I knew it transversed the device tree once, and my code does it twice, first time to locate (is it there?), the second time to actually extract the data and use it. -- Daniel Rudy From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 27 05:48:30 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F56016A41F for ; Thu, 27 Oct 2005 05:48:30 +0000 (GMT) (envelope-from dinesh@alphaque.com) Received: from ns2.alphaque.com (ns2.alphaque.com [202.75.47.153]) by mx1.FreeBSD.org (Postfix) with SMTP id BBFFE43D4C for ; Thu, 27 Oct 2005 05:48:26 +0000 (GMT) (envelope-from dinesh@alphaque.com) Received: (qmail 86832 invoked by uid 0); 27 Oct 2005 05:48:23 -0000 Received: from lucifer.net-gw.com (HELO prophet.alphaque.com) (202.75.47.153) by lucifer.net-gw.com with SMTP; 27 Oct 2005 05:48:23 -0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by prophet.alphaque.com (8.13.4/8.13.4) with ESMTP id j9R5lxJI001291; Thu, 27 Oct 2005 13:47:59 +0800 (MYT) (envelope-from dinesh@alphaque.com) Message-ID: <43606A0F.5000704@alphaque.com> Date: Thu, 27 Oct 2005 13:47:59 +0800 From: Dinesh Nair User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8b) Gecko/20050915 MIME-Version: 1.0 To: Scott Long References: <435E3003.4050609@alphaque.com> <200510251610.53127.jhb@freebsd.org> <435F1E77.30007@alphaque.com> <200510261320.16175.jhb@freebsd.org> <435FE416.1050703@samsco.org> In-Reply-To: <435FE416.1050703@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: correct use of bus_dmamap_sync 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, 27 Oct 2005 05:48:30 -0000 On 10/27/05 04:16 Scott Long said the following: >>> an example would be using (BUS_DMASYNC_POSTREAD|BUS_DMASYNC_PREWRITE) >>> which >>> would be 0x03 in freebsd 4.x and 0x06 in freebsd 5.x. the gotcha is that >>> 0x03 in freebsd 4.x is BUS_DMASYNC_POSTWRITE. so therefore, >>> BUS_DMASYNC_POSTREAD|BUS_DMASYNC_PREWRITE will be >>> BUS_DMASYNC_POSTWRITE in >>> 4.x which in the syscall is actually a no op. >> >> Yes, that is fugly. Just don't use the | versions for now I would guess. > > Trying to maintain source compatibility between 4.x and 5.x/6.x will > make you encounter a whole lot more problems than just this. could you elaborate on what busdma related problems there'd be, between 4.x and 5.x/6.x ? do, for example, the inner workings of the bus_dma* syscalls work the same on both ? -- Regards, /\_/\ "All dogs go to heaven." dinesh@alphaque.com (0 0) http://www.alphaque.com/ +==========================----oOO--(_)--OOo----==========================+ | for a in past present future; do | | for b in clients employers associates relatives neighbours pets; do | | echo "The opinions here in no way reflect the opinions of my $a $b." | | done; done | +=========================================================================+ From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 27 11:24:55 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8726416A41F for ; Thu, 27 Oct 2005 11:24:55 +0000 (GMT) (envelope-from dinesh@alphaque.com) Received: from ns2.alphaque.com (ns2.alphaque.com [202.75.47.153]) by mx1.FreeBSD.org (Postfix) with SMTP id 4675A43D45 for ; Thu, 27 Oct 2005 11:24:53 +0000 (GMT) (envelope-from dinesh@alphaque.com) Received: (qmail 90217 invoked by uid 0); 27 Oct 2005 11:24:51 -0000 Received: from lucifer.net-gw.com (HELO prophet.alphaque.com) (202.75.47.153) by lucifer.net-gw.com with SMTP; 27 Oct 2005 11:24:51 -0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by prophet.alphaque.com (8.13.4/8.13.4) with ESMTP id j9RBOUrf061036; Thu, 27 Oct 2005 19:24:30 +0800 (MYT) (envelope-from dinesh@alphaque.com) Message-ID: <4360B8EE.4070605@alphaque.com> Date: Thu, 27 Oct 2005 19:24:30 +0800 From: Dinesh Nair User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8b) Gecko/20050915 MIME-Version: 1.0 To: John Baldwin References: <435EEC56.9080708@samsco.org> <200510261130.45506.jhb@freebsd.org> <435FA6A9.4000600@samsco.org> <200510261324.03790.jhb@freebsd.org> In-Reply-To: <200510261324.03790.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Scott Long Subject: locking in a device driver (was: use of bus_dmamap_sync) 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, 27 Oct 2005 11:24:55 -0000 carrying on this discussion, what would be a good locking mechanism to use to protect tsleep() and other sensitive areas in a driver in freebsd 4.x ? the current code for the driver in 5.x uses mtx_lock and mtx_unlock with some parts even being protected by mtx_lock(&Giant). would the use of simple_lock() or s_lock() do, given that SIMPLELOCK_DEBUG was defined in the 4.x kernel ? the mechanism is actually a pseudo device driver which communicates with the real device driver. the pseudo device driver creates a bunch of /dev/ devices which the userland reads/writes to, and the pseudo device driver then places data in a few buffers. the real device driver then reads these buffers and uses busdma to send the data to the device. reading is done by using busdma to read from the device and then placing the data in these buffers for the pseudo device to return to the userland process. locking in the real device driver uses splhigh/splx, but what locking should be used in the pseudo device driver ? -- Regards, /\_/\ "All dogs go to heaven." dinesh@alphaque.com (0 0) http://www.alphaque.com/ +==========================----oOO--(_)--OOo----==========================+ | for a in past present future; do | | for b in clients employers associates relatives neighbours pets; do | | echo "The opinions here in no way reflect the opinions of my $a $b." | | done; done | +=========================================================================+ From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 27 11:54:15 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 376F416A41F for ; Thu, 27 Oct 2005 11:54:15 +0000 (GMT) (envelope-from kamal_ckk@yahoo.com) Received: from web35702.mail.mud.yahoo.com (web35702.mail.mud.yahoo.com [66.163.179.156]) by mx1.FreeBSD.org (Postfix) with SMTP id 49E1B43D4C for ; Thu, 27 Oct 2005 11:54:14 +0000 (GMT) (envelope-from kamal_ckk@yahoo.com) Received: (qmail 77473 invoked by uid 60001); 27 Oct 2005 11:54:11 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=DMI7Dskm3sUn+4zufvNJpjCRhjiRP4YJx6YRxGvgyLedVGTn3ofrNr7z6WDLNnyqmigje2D2uTRPI8JHMGUIrjN9bVpU5QG9689aB8fdhU/EKXSD8yCPNWhTs8TvNc4HZGFlyrIHqtt5lMUEeCRxmav9VVBpgQy4DrvTot47VQQ= ; Message-ID: <20051027115411.77471.qmail@web35702.mail.mud.yahoo.com> Received: from [202.79.62.15] by web35702.mail.mud.yahoo.com via HTTP; Thu, 27 Oct 2005 04:54:10 PDT Date: Thu, 27 Oct 2005 04:54:10 -0700 (PDT) From: kamal kc To: freebsd MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd Subject: compiling the kernel faster 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, 27 Oct 2005 11:54:15 -0000 hello everybody, i am new to kernel programming. i am developing a compression/decompression functionality in the ip layer. i want to compile the kernel faster. it would be ok if the kernel doesn't have support for sound devices, or other devices like scsi,usb etc. because i would be using the compiled kernel for network data compression only. how could i do that. which source files and where in the makefiles do i make modifications ???? thanks for any suggestions kamal __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 27 12:14:47 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB8D416A41F; Thu, 27 Oct 2005 12:14:47 +0000 (GMT) (envelope-from ray@redshift.com) Received: from mail.quickmeet.com (quickmeet.com [216.228.17.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 960DE43D45; Thu, 27 Oct 2005 12:14:47 +0000 (GMT) (envelope-from ray@redshift.com) Received: from workstation (workstation [192.168.20.250]) by mail.quickmeet.com (Postfix) with SMTP id 5888117032; Thu, 27 Oct 2005 04:47:32 -0700 (PDT) Message-Id: <3.0.1.32.20051027051451.00a842c0@pop.redshift.com> X-Mailer: na X-Sender: redshift.com Date: Thu, 27 Oct 2005 05:14:51 -0700 To: kamal kc , freebsd From: ray@redshift.com In-Reply-To: <20051027115411.77471.qmail@web35702.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: freebsd Subject: Re: compiling the kernel faster 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, 27 Oct 2005 12:14:47 -0000 At 04:54 AM 10/27/2005 -0700, kamal kc wrote: | hello everybody, | | i am new to kernel programming. | i am developing a compression/decompression | functionality in the ip layer. | | i want to compile the kernel faster. | | it would | be ok if the kernel doesn't have support for sound | devices, or other devices like scsi,usb etc. because | i would be using the compiled kernel for | network data compression only. | | how could i do that. which source files and where in | the makefiles do i make modifications ???? | | thanks for any suggestions | | kamal Kamal, The files you modify to drop stuff out of the kernel are in /sys/i386/conf/ (assuming you are on an Intel platform). Copy the GENERIC file in there to something else (e.g DEVKERNEL), then edit that file. Comment out any drivers you don't need using # (check your dmesg output when you boot to see what drivers the OS is loading for your hardware). Don't comment out anything unless it's obviously something you don't need - doublt check the dmesg for stuff like network drivers, hard drive stuff, etc.) Once you comment out the drivers, you will need to re-compile the kernel. Go into /sys/i386/conf/ directory type this: config DEVKERNEL (using the example above) then change into the directory it shows you (should be something like ../compile/DEVKERNEL or something like that) and type this: make depend && make all install clean that will compile the new kernel and leave it in /boot/kernel (it will also backup your old kernel into kernel.old) go into /boot/kernel/ and type this: strip -s * then reboot using shutdown -r now If all goes well, you should boot to the new kernel. You can use the uname -a command to make sure you are on the new kernel okay. If the machine won't boot, you can boot into single user mode and copy the old kernel back in place. An excellent book on the subject is: Absolute BSD: The Ultimate Guide to FreeBSD (Paperback) good luck. Ray From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 26 18:06:03 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 09E0716A41F for ; Wed, 26 Oct 2005 18:06:03 +0000 (GMT) (envelope-from smb@cs.columbia.edu) Received: from machshav.com (machshav.com [147.28.0.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9C9043D46 for ; Wed, 26 Oct 2005 18:06:02 +0000 (GMT) (envelope-from smb@cs.columbia.edu) Received: by machshav.com (Postfix, from userid 512) id 3CA5DFB285; Wed, 26 Oct 2005 18:06:02 +0000 (UTC) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A6CB4FB262; Wed, 26 Oct 2005 18:06:01 +0000 (UTC) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 84A8E3BFD40; Wed, 26 Oct 2005 14:06:00 -0400 (EDT) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: Jason Thorpe In-Reply-To: Your message of "Wed, 26 Oct 2005 10:55:39 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 26 Oct 2005 14:06:00 -0400 Sender: smb@cs.columbia.edu Message-Id: <20051026180600.84A8E3BFD40@berkshire.machshav.com> X-Mailman-Approved-At: Thu, 27 Oct 2005 12:41:01 +0000 Cc: freebsd-hackers@freebsd.org, tech-kern@NetBSD.org, Bill Studenmund , Hans Petter Selasky Subject: Re: FreeBSD 5/6/7 kernel emulator for NetBSD 2.x 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, 26 Oct 2005 18:06:03 -0000 In message , Jason Thorpe writes: > >FWIW, I think a devfs based on our new tmpfs would be better for NetBSD. > I was under the impression that each i-node in tmpfs consumed a fair amount of space, making it a bad match for things like /dev which have very many i-nodes but no actual files. (Well, I've seen glitches on ancient systems where /dev/null got turned into a regular file, leading to amusing messages about "/dev/null: no space left on device"...) --Steven M. Bellovin, http://www.cs.columbia.edu/~smb From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 26 21:18:01 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E0D116A41F for ; Wed, 26 Oct 2005 21:18:01 +0000 (GMT) (envelope-from jon.brisbin@npcinternational.com) Received: from mail1.npci.com (mail.npcinternational.com [63.76.154.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2AE5F43D45 for ; Wed, 26 Oct 2005 21:18:00 +0000 (GMT) (envelope-from jon.brisbin@npcinternational.com) Received: from fc63r41.npci.com ([172.16.0.131]) by mail1.npci.com (MOS 3.5.9-GR) with ESMTP id BWL04091 (AUTH via LOGINBEFORESMTP); Wed, 26 Oct 2005 16:13:04 -0500 (CDT) Date: Wed, 26 Oct 2005 16:18:00 -0500 From: Jon Brisbin To: freebsd-hackers@freebsd.org Message-ID: <20051026161800.72a5b809@fc63r41.npci.com> Organization: NPC International X-Mailer: Sylpheed-Claws 1.9.13 (GTK+ 2.6.9; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 27 Oct 2005 12:41:01 +0000 Subject: ICC 9 in FreeBSD 6 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, 26 Oct 2005 21:18:01 -0000 I'm trying to hack the ICC 8 port files to work with ICC 9 and I was wondering if anyone knows right off the bat whether or not I can use the existing patch files in the "files/" directory? I did some diffs on the newer files and it looks like they should work okay, but I don't know what effect that will have on the installation. At the very least, I'll just copy the patched files so I can revert later, if I want to. Has anyone tried this yet? I'm anxious to get ICC 9 working on my BSD boxes since I got it to work on the Linux box. Thanks! Jon Brisbin Webmeister NPC International, Inc. From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 27 12:27:03 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4704016A41F; Thu, 27 Oct 2005 12:27:03 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from mail.yazzy.org (mail.yazzy.org [217.8.140.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0A0043D46; Thu, 27 Oct 2005 12:27:02 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from 217-13-2-82.dd.nextgentel.com ([217.13.2.82] helo=marcin) by mail.yazzy.org with esmtps (TLSv1:AES256-SHA:256) (YazzY.org) id 1EV6pw-0001OL-NG; Thu, 27 Oct 2005 14:26:29 +0200 Date: Thu, 27 Oct 2005 14:27:06 +0200 From: Marcin Jessa To: kamal kc Message-Id: <20051027142706.26473f23.lists@yazzy.org> In-Reply-To: <20051027115411.77471.qmail@web35702.mail.mud.yahoo.com> References: <20051027115411.77471.qmail@web35702.mail.mud.yahoo.com> Organization: YazzY.org X-Mailer: Sylpheed version 2.0.0 (GTK+ 2.6.8; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: -2.5 (--) X-Mailman-Approved-At: Thu, 27 Oct 2005 12:41:01 +0000 Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: compiling the kernel faster 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, 27 Oct 2005 12:27:03 -0000 On Thu, 27 Oct 2005 04:54:10 -0700 (PDT) kamal kc wrote: > hello everybody, > > i am new to kernel programming. > i am developing a compression/decompression > functionality in the ip layer. > > i want to compile the kernel faster. > > it would > be ok if the kernel doesn't have support for sound > devices, or other devices like scsi,usb etc. because > i would be using the compiled kernel for > network data compression only. > > how could i do that. which source files and where in > the makefiles do i make modifications ???? > > thanks for any suggestions Read the handbook - http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig.html Next time remember to post to questions@ when asking begginer questions. Cheers Marcin From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 26 17:55:41 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D72BD16A41F for ; Wed, 26 Oct 2005 17:55:41 +0000 (GMT) (envelope-from thorpej@shagadelic.org) Received: from mail.shagadelic.org (isc-temp1.netbsd.org [204.152.190.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9DE2D43D48 for ; Wed, 26 Oct 2005 17:55:41 +0000 (GMT) (envelope-from thorpej@shagadelic.org) Received: from [17.221.46.152] (A17-221-46-152.apple.com [17.221.46.152]) by mail.shagadelic.org (Postfix) with ESMTP id 05E6A3CA162; Wed, 26 Oct 2005 10:55:41 -0700 (PDT) In-Reply-To: <20051026172252.GA23243@netbsd.org> References: <200510242235.48403.hselasky@c2i.net> <20051026172252.GA23243@netbsd.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jason Thorpe Date: Wed, 26 Oct 2005 10:55:39 -0700 To: Bill Studenmund X-Mailer: Apple Mail (2.746.2) X-Mailman-Approved-At: Thu, 27 Oct 2005 12:47:34 +0000 Cc: freebsd-hackers@freebsd.org, tech-kern@netbsd.org, Hans Petter Selasky Subject: Re: FreeBSD 5/6/7 kernel emulator for NetBSD 2.x 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, 26 Oct 2005 17:55:42 -0000 On Oct 26, 2005, at 10:22 AM, Bill Studenmund wrote: > In the past, we (NetBSD folks) have talked about a devfs. One issue > that > has come up (I'll be honest, I've raised it a lot) is a desire to > retain > permission changes across boots, and to tie devices (when possible) > to a > device-specific attribute rather than a probe order. The permission thing is solvable using scripts that can fix up the perms after mount. The "nodes named after attributes" thing is interesting... and largely something I'm concerned about with wedges, although in that case, it's pretty easy to handle from within wedges itself. > Does FreeBSD's devfs support locators and persistent information? Are > there plans to support something like that, if not? FreeBSD's devfs does not, to my knowledge, include the things that you have mentioned above. FWIW, I think a devfs based on our new tmpfs would be better for NetBSD. -- thorpej From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 26 17:22:54 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5BA5616A420 for ; Wed, 26 Oct 2005 17:22:54 +0000 (GMT) (envelope-from wrstuden@netbsd.org) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2528043D46 for ; Wed, 26 Oct 2005 17:22:54 +0000 (GMT) (envelope-from wrstuden@netbsd.org) Received: by mail.netbsd.org (Postfix, from userid 1130) id E96BD63B301; Wed, 26 Oct 2005 17:22:53 +0000 (UTC) Date: Wed, 26 Oct 2005 10:22:52 -0700 From: Bill Studenmund To: Hans Petter Selasky Message-ID: <20051026172252.GA23243@netbsd.org> References: <200510242235.48403.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline In-Reply-To: <200510242235.48403.hselasky@c2i.net> User-Agent: Mutt/1.4.1i X-Mailman-Approved-At: Thu, 27 Oct 2005 12:48:51 +0000 Cc: freebsd-hackers@freebsd.org, tech-kern@netbsd.org Subject: Re: FreeBSD 5/6/7 kernel emulator for NetBSD 2.x 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, 26 Oct 2005 17:22:54 -0000 --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 24, 2005 at 10:35:47PM +0200, Hans Petter Selasky wrote: >=20 > Main features: >=20 > - Implements FreeBSD's devfs on NetBSD. In the past, we (NetBSD folks) have talked about a devfs. One issue that=20 has come up (I'll be honest, I've raised it a lot) is a desire to retain=20 permission changes across boots, and to tie devices (when possible) to a=20 device-specific attribute rather than a probe order. Does FreeBSD's devfs support locators and persistent information? Are=20 there plans to support something like that, if not? Take care, Bill --tKW2IUtsqtDRztdT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (NetBSD) iD8DBQFDX7tsWz+3JHUci9cRAkrlAKCOOWwqnX/urSjcJDR+/IsgsI+JdwCfUe2j +L63fRiyOILHrYtqYspCWXY= =Vzf3 -----END PGP SIGNATURE----- --tKW2IUtsqtDRztdT-- From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 27 13:54:42 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E398516A41F; Thu, 27 Oct 2005 13:54:42 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4583A43D45; Thu, 27 Oct 2005 13:54:41 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.204] ([192.168.254.204]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id j9RDscsC072099; Thu, 27 Oct 2005 07:54:38 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4360DC20.90700@samsco.org> Date: Thu, 27 Oct 2005 07:54:40 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dinesh Nair References: <435E3003.4050609@alphaque.com> <200510251610.53127.jhb@freebsd.org> <435F1E77.30007@alphaque.com> <200510261320.16175.jhb@freebsd.org> <435FE416.1050703@samsco.org> <43606A0F.5000704@alphaque.com> In-Reply-To: <43606A0F.5000704@alphaque.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-hackers@freebsd.org Subject: Re: correct use of bus_dmamap_sync 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, 27 Oct 2005 13:54:43 -0000 Dinesh Nair wrote: > > On 10/27/05 04:16 Scott Long said the following: > >>>> an example would be using >>>> (BUS_DMASYNC_POSTREAD|BUS_DMASYNC_PREWRITE) which >>>> would be 0x03 in freebsd 4.x and 0x06 in freebsd 5.x. the gotcha is >>>> that >>>> 0x03 in freebsd 4.x is BUS_DMASYNC_POSTWRITE. so therefore, >>>> BUS_DMASYNC_POSTREAD|BUS_DMASYNC_PREWRITE will be >>>> BUS_DMASYNC_POSTWRITE in >>>> 4.x which in the syscall is actually a no op. >>> >>> >>> Yes, that is fugly. Just don't use the | versions for now I would >>> guess. >> >> >> Trying to maintain source compatibility between 4.x and 5.x/6.x will >> make you encounter a whole lot more problems than just this. > > > could you elaborate on what busdma related problems there'd be, between > 4.x and 5.x/6.x ? do, for example, the inner workings of the bus_dma* > syscalls work the same on both ? > I was speaking about driver code in general. For busdma specifically, the only difference is the extra arguments to bus_dma_tag_create(). Scott From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 27 14:00:29 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E84E16A41F; Thu, 27 Oct 2005 14:00:29 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 880D943D49; Thu, 27 Oct 2005 14:00:28 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.204] ([192.168.254.204]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id j9RE0O3E072795; Thu, 27 Oct 2005 08:00:24 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4360DD7B.20900@samsco.org> Date: Thu, 27 Oct 2005 08:00:27 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dinesh Nair References: <435EEC56.9080708@samsco.org> <200510261130.45506.jhb@freebsd.org> <435FA6A9.4000600@samsco.org> <200510261324.03790.jhb@freebsd.org> <4360B8EE.4070605@alphaque.com> In-Reply-To: <4360B8EE.4070605@alphaque.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-hackers@freebsd.org Subject: Re: locking in a device driver 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, 27 Oct 2005 14:00:29 -0000 Dinesh Nair wrote: > > carrying on this discussion, what would be a good locking mechanism to > use to protect tsleep() and other sensitive areas in a driver in freebsd > 4.x ? > > the current code for the driver in 5.x uses mtx_lock and mtx_unlock with > some parts even being protected by mtx_lock(&Giant). > > would the use of simple_lock() or s_lock() do, given that > SIMPLELOCK_DEBUG was defined in the 4.x kernel ? > > the mechanism is actually a pseudo device driver which communicates with > the real device driver. the pseudo device driver creates a bunch of > /dev/ devices which the userland reads/writes to, and the pseudo device > driver then places data in a few buffers. > > the real device driver then reads these buffers and uses busdma to send > the data to the device. reading is done by using busdma to read from the > device and then placing the data in these buffers for the pseudo device > to return to the userland process. > > locking in the real device driver uses splhigh/splx, but what locking > should be used in the pseudo device driver ? > If you need to protect your pseudodriver from being interrupted by the real driver then you'll need to use the same spl() as the driver. Note that you shouldn't be using splhigh() unless you really know what you are doing. Other than that, there likely isn't anything that you need to do for 'locking' in 4.x. The kernel is non-reentrant there, so you don't need to worry about synchronizing multiple threads. Scott From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 27 14:13:21 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F26A16A41F for ; Thu, 27 Oct 2005 14:13:21 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id D2F3243D45 for ; Thu, 27 Oct 2005 14:13:20 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 395AD2082; Thu, 27 Oct 2005 16:13:13 +0200 (CEST) X-Spam-Tests: ALL_TRUSTED,AWL,BAYES_00 X-Spam-Learn: ham X-Spam-Score: -4.4/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on tim.des.no Received: from xps.des.no (des.no [80.203.228.37]) by tim.des.no (Postfix) with ESMTP id BEA842080; Thu, 27 Oct 2005 16:13:12 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id A211833C1D; Thu, 27 Oct 2005 16:13:12 +0200 (CEST) To: Xin LI References: <1130315101.810.5.camel@spirit> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Thu, 27 Oct 2005 16:13:12 +0200 In-Reply-To: <1130315101.810.5.camel@spirit> (Xin LI's message of "Wed, 26 Oct 2005 16:25:01 +0800") Message-ID: <868xwf59qf.fsf@xps.des.no> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@FreeBSD.org, zhuyan@staff.sina.com.cn, LI Xin Subject: Re: Is it possible to mmap() raw disk device? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2005 14:13:21 -0000 Xin LI writes: > When we were trying to make a userland FS application we have > encountered "Invalid Argument" when doing mmap() over an open > descriptor to a disk device. It is not currently possible to mmap disk devices. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 27 15:36:52 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EFAFE16A41F; Thu, 27 Oct 2005 15:36:52 +0000 (GMT) (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 5959C43D48; Thu, 27 Oct 2005 15:36:52 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j9RFYgq3042586; Thu, 27 Oct 2005 09:34:47 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 27 Oct 2005 09:34:42 -0600 (MDT) Message-Id: <20051027.093442.65174562.imp@bsdimp.com> To: dr2867@pacbell.net From: "M. Warner Losh" In-Reply-To: <436060B2.5050203@pacbell.net> References: <435FBA42.1070604@pacbell.net> <200510261425.14759.jhb@freebsd.org> <436060B2.5050203@pacbell.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 27 Oct 2005 09:34:47 -0600 (MDT) Cc: soc-victor@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: devinfo(3) 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: Thu, 27 Oct 2005 15:36:53 -0000 In message: <436060B2.5050203@pacbell.net> Daniel Rudy writes: : I analyzed the source code for devinfo(8) and used as an example of how : to use the devinfo(3) library. So I knew it transversed the device tree : once, and my code does it twice, first time to locate (is it there?), : the second time to actually extract the data and use it. Maybe you've found a bug in devinfo then... I don't think anybody has used it like this before. Warner From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 27 15:40:28 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E09216A41F for ; Thu, 27 Oct 2005 15:40:28 +0000 (GMT) (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 BE3A343D46 for ; Thu, 27 Oct 2005 15:40:27 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j9RFcYO1042598; Thu, 27 Oct 2005 09:38:37 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 27 Oct 2005 09:38:33 -0600 (MDT) Message-Id: <20051027.093833.114360961.imp@bsdimp.com> To: scottl@samsco.org From: "M. Warner Losh" In-Reply-To: <4360DD7B.20900@samsco.org> References: <200510261324.03790.jhb@freebsd.org> <4360B8EE.4070605@alphaque.com> <4360DD7B.20900@samsco.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 27 Oct 2005 09:38:41 -0600 (MDT) Cc: freebsd-hackers@freebsd.org Subject: Re: locking in a device driver 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, 27 Oct 2005 15:40:28 -0000 In message: <4360DD7B.20900@samsco.org> Scott Long writes: : Dinesh Nair wrote: : > : > carrying on this discussion, what would be a good locking mechanism to : > use to protect tsleep() and other sensitive areas in a driver in freebsd : > 4.x ? : > : > the current code for the driver in 5.x uses mtx_lock and mtx_unlock with : > some parts even being protected by mtx_lock(&Giant). : > : > would the use of simple_lock() or s_lock() do, given that : > SIMPLELOCK_DEBUG was defined in the 4.x kernel ? : > : > the mechanism is actually a pseudo device driver which communicates with : > the real device driver. the pseudo device driver creates a bunch of : > /dev/ devices which the userland reads/writes to, and the pseudo device : > driver then places data in a few buffers. : > : > the real device driver then reads these buffers and uses busdma to send : > the data to the device. reading is done by using busdma to read from the : > device and then placing the data in these buffers for the pseudo device : > to return to the userland process. : > : > locking in the real device driver uses splhigh/splx, but what locking : > should be used in the pseudo device driver ? : > : : If you need to protect your pseudodriver from being interrupted by the : real driver then you'll need to use the same spl() as the driver. Note : that you shouldn't be using splhigh() unless you really know what you : are doing. Other than that, there likely isn't anything that you need : to do for 'locking' in 4.x. The kernel is non-reentrant there, so you : don't need to worry about synchronizing multiple threads. One thing to also bear in mind is that in 4.x spl locking is a code lock. It keeps multiple 'threads' of execution from entering a block of code. mutexes in -current are data locks. While usually one can think of the two the same, it can trip the unweary up. Locking in 4.x is indeed much simpler. Warner From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 27 15:45:35 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E249616A41F for ; Thu, 27 Oct 2005 15:45:35 +0000 (GMT) (envelope-from fcash@ocis.net) Received: from smtp.sd73.bc.ca (smtp.sd73.bc.ca [142.24.13.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9117743D46 for ; Thu, 27 Oct 2005 15:45:35 +0000 (GMT) (envelope-from fcash@ocis.net) Received: from localhost (localhost [127.0.0.1]) by localhost.sd73.bc.ca (Postfix) with ESMTP id 480998A0195; Thu, 27 Oct 2005 08:46:03 -0700 (PDT) Received: from smtp.sd73.bc.ca ([127.0.0.1]) by localhost (mailtest.sd73.bc.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 88640-01-49; Thu, 27 Oct 2005 08:46:01 -0700 (PDT) Received: from [192.168.0.157] (unknown [192.168.0.157]) by smtp.sd73.bc.ca (Postfix) with ESMTP id 55EE18A017E; Thu, 27 Oct 2005 08:46:01 -0700 (PDT) From: Freddie Cash To: freebsd-hackers@freebsd.org Date: Thu, 27 Oct 2005 08:45:32 -0700 User-Agent: KMail/1.8.2 References: <200510242235.48403.hselasky@c2i.net> <20051026172252.GA23243@netbsd.org> In-Reply-To: <20051026172252.GA23243@netbsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510270845.32525.fcash@ocis.net> X-Virus-Scanned: by amavisd-new using ClamAV at sd73.bc.ca Cc: tech-kern@netbsd.org Subject: Re: FreeBSD 5/6/7 kernel emulator for NetBSD 2.x 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, 27 Oct 2005 15:45:36 -0000 On October 26, 2005 10:22 am, Bill Studenmund wrote: > On Mon, Oct 24, 2005 at 10:35:47PM +0200, Hans Petter Selasky wrote: > > Main features: > > - Implements FreeBSD's devfs on NetBSD. > In the past, we (NetBSD folks) have talked about a devfs. One issue > that has come up (I'll be honest, I've raised it a lot) is a desire to > retain permission changes across boots, and to tie devices (when > possible) to a device-specific attribute rather than a probe order. FreeBSD 5+ has /etc/devfs.conf and /etc/devfs.rules which include information regarding permissions and ownership for device nodes under /dev. These files can even be used for creating fancy names for devices using symlinks (like /dev/burner for CD-RW devices, or /dev/floppy and so on). At boot time, /etc/devfs.conf is read, and /etc/devfs.rules is read whenever new devices are attached to the system (I believe that's how it works, anyway). Is that what you're looking for? > Does FreeBSD's devfs support locators and persistent information? Are > there plans to support something like that, if not? -- Freddie Cash fcash@ocis.net From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 27 15:54:19 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB76616A41F for ; Thu, 27 Oct 2005 15:54:19 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62F6043D48 for ; Thu, 27 Oct 2005 15:54:18 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.204] ([192.168.254.204]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id j9RFsDHK085681; Thu, 27 Oct 2005 09:54:13 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4360F827.4040603@samsco.org> Date: Thu, 27 Oct 2005 09:54:15 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M. Warner Losh" References: <200510261324.03790.jhb@freebsd.org> <4360B8EE.4070605@alphaque.com> <4360DD7B.20900@samsco.org> <20051027.093833.114360961.imp@bsdimp.com> In-Reply-To: <20051027.093833.114360961.imp@bsdimp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-hackers@freebsd.org Subject: Re: locking in a device driver 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, 27 Oct 2005 15:54:20 -0000 M. Warner Losh wrote: > In message: <4360DD7B.20900@samsco.org> > Scott Long writes: > : Dinesh Nair wrote: > : > > : > carrying on this discussion, what would be a good locking mechanism to > : > use to protect tsleep() and other sensitive areas in a driver in freebsd > : > 4.x ? > : > > : > the current code for the driver in 5.x uses mtx_lock and mtx_unlock with > : > some parts even being protected by mtx_lock(&Giant). > : > > : > would the use of simple_lock() or s_lock() do, given that > : > SIMPLELOCK_DEBUG was defined in the 4.x kernel ? > : > > : > the mechanism is actually a pseudo device driver which communicates with > : > the real device driver. the pseudo device driver creates a bunch of > : > /dev/ devices which the userland reads/writes to, and the pseudo device > : > driver then places data in a few buffers. > : > > : > the real device driver then reads these buffers and uses busdma to send > : > the data to the device. reading is done by using busdma to read from the > : > device and then placing the data in these buffers for the pseudo device > : > to return to the userland process. > : > > : > locking in the real device driver uses splhigh/splx, but what locking > : > should be used in the pseudo device driver ? > : > > : > : If you need to protect your pseudodriver from being interrupted by the > : real driver then you'll need to use the same spl() as the driver. Note > : that you shouldn't be using splhigh() unless you really know what you > : are doing. Other than that, there likely isn't anything that you need > : to do for 'locking' in 4.x. The kernel is non-reentrant there, so you > : don't need to worry about synchronizing multiple threads. > > One thing to also bear in mind is that in 4.x spl locking is a code > lock. It keeps multiple 'threads' of execution from entering a block > of code. mutexes in -current are data locks. While usually one can > think of the two the same, it can trip the unweary up. > > Locking in 4.x is indeed much simpler. > > Warner I wouldn't characterize spls that way. An spl keeps top-half code from being preempted by an interrupt that would cause bottom half code to run. It's more of a special critical section that a code serializer. It's big advantage is that it doesn't mask out all interrupts, just the ones that you want, and it's much more light weight on x86 that doing explicit cli/sti instructions. It's the BGL spinlock that keeps multiple processes from executing the top half at the same time, and there is no control over that; it's just 'there'. The synchronization guarantees that you have in the 4.x kernel are: 1. Only one process will be executing in the kernel at a time. Multiple processes might be blocked at the same time, but only one will be executing, regardless of the number of CPUs. 2. Only one interrupt handler will execute at a time, and while it is executing there will not be any top half code executing on any other CPUs. 3. Interrupt handlers can preempt a process executing in the kernel unless the appropriate spl mask/level is set. Scott From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 27 16:46:20 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 175AC16A41F for ; Thu, 27 Oct 2005 16:46:20 +0000 (GMT) (envelope-from dinesh@alphaque.com) Received: from ns2.alphaque.com (ns2.alphaque.com [202.75.47.153]) by mx1.FreeBSD.org (Postfix) with SMTP id 90CAF43D46 for ; Thu, 27 Oct 2005 16:46:18 +0000 (GMT) (envelope-from dinesh@alphaque.com) Received: (qmail 93840 invoked by uid 0); 27 Oct 2005 16:46:16 -0000 Received: from lucifer.net-gw.com (HELO prophet.alphaque.com) (202.75.47.153) by lucifer.net-gw.com with SMTP; 27 Oct 2005 16:46:16 -0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by prophet.alphaque.com (8.13.4/8.13.4) with ESMTP id j9RGk3MO017438; Fri, 28 Oct 2005 00:46:03 +0800 (MYT) (envelope-from dinesh@alphaque.com) Message-ID: <4361044B.50807@alphaque.com> Date: Fri, 28 Oct 2005 00:46:03 +0800 From: Dinesh Nair User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8b) Gecko/20050915 MIME-Version: 1.0 To: Scott Long References: <435EEC56.9080708@samsco.org> <200510261130.45506.jhb@freebsd.org> <435FA6A9.4000600@samsco.org> <200510261324.03790.jhb@freebsd.org> <4360B8EE.4070605@alphaque.com> <4360DD7B.20900@samsco.org> In-Reply-To: <4360DD7B.20900@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: locking in a device driver 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, 27 Oct 2005 16:46:20 -0000 On 10/27/05 22:00 Scott Long said the following: > are doing. Other than that, there likely isn't anything that you need > to do for 'locking' in 4.x. The kernel is non-reentrant there, so you > don't need to worry about synchronizing multiple threads. thanx a bunch, scott. it's been a nightmare trying to debug the driver and to try to find out why the driver compiled from the same source tree works on freebsd 5.x and doesnt work at all on freebsd 4.x . so far, i've been gloriously unsuccesful at this, and am getting at my wits end on what to go look at. the userland application uses pthreads, and works like a charm both on 4.x and 5.x without using the device. however, when the device is used, it somehow has synchronization errors on 4.x, leading to timers (created in the userland app) timing out and the like. -- Regards, /\_/\ "All dogs go to heaven." dinesh@alphaque.com (0 0) http://www.alphaque.com/ +==========================----oOO--(_)--OOo----==========================+ | for a in past present future; do | | for b in clients employers associates relatives neighbours pets; do | | echo "The opinions here in no way reflect the opinions of my $a $b." | | done; done | +=========================================================================+ From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 27 18:31:18 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5222016A41F for ; Thu, 27 Oct 2005 18:31:18 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3058043D45 for ; Thu, 27 Oct 2005 18:31:17 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.3/8.13.3) with ESMTP id j9RIV7QV021353; Thu, 27 Oct 2005 11:31:07 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.3/8.13.3/Submit) id j9RIV62w021352; Thu, 27 Oct 2005 11:31:06 -0700 (PDT) (envelope-from jmg) Date: Thu, 27 Oct 2005 11:31:06 -0700 From: John-Mark Gurney To: Bill Studenmund Message-ID: <20051027183106.GM4115@funkthat.com> Mail-Followup-To: Bill Studenmund , Hans Petter Selasky , freebsd-hackers@freebsd.org, tech-kern@netbsd.org References: <200510242235.48403.hselasky@c2i.net> <20051026172252.GA23243@netbsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051026172252.GA23243@netbsd.org> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: freebsd-hackers@freebsd.org, tech-kern@netbsd.org, Hans Petter Selasky Subject: Re: FreeBSD 5/6/7 kernel emulator for NetBSD 2.x X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2005 18:31:18 -0000 Bill Studenmund wrote this message on Wed, Oct 26, 2005 at 10:22 -0700: > On Mon, Oct 24, 2005 at 10:35:47PM +0200, Hans Petter Selasky wrote: > > > > Main features: > > > > - Implements FreeBSD's devfs on NetBSD. > > In the past, we (NetBSD folks) have talked about a devfs. One issue that > has come up (I'll be honest, I've raised it a lot) is a desire to retain > permission changes across boots, and to tie devices (when possible) to a > device-specific attribute rather than a probe order. > > Does FreeBSD's devfs support locators and persistent information? Are > there plans to support something like that, if not? Well, there are two camps (there may be more, but I can only think of these two) to the locators and persistent info... One is the geom_label route, where the devices self identify, so no matter what adX a device appears as, you can just mount /dev/ufs/fsname... The other of course is to allow you to wire down devices... which some things are better about allowing than others.. like you can wire down da and sio devices... Though one things I miss on FreeBSD that MacOSX has is that when you plug in a USB to serial adapter, MacOSX includes the serial number in the device name: /dev/tty.usbserial-FTC8P121, which is convient... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 27 23:26:52 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E524316A41F for ; Thu, 27 Oct 2005 23:26:51 +0000 (GMT) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BBC043D45 for ; Thu, 27 Oct 2005 23:26:50 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: Y1QAsIk9O44SO+J/q9KNyQ== Received: from mp-217-136-130.daxnet.no ([193.217.136.130] verified) by mailfe06.swip.net (CommuniGate Pro SMTP 4.3.8) with ESMTP id 11744433; Fri, 28 Oct 2005 01:26:48 +0200 From: Hans Petter Selasky To: tech-kern@netbsd.org, freebsd-hackers@freebsd.org Date: Fri, 28 Oct 2005 01:27:49 +0200 User-Agent: KMail/1.7 References: <200510242235.48403.hselasky@c2i.net> <20051027072952.GA505@beta.martani.repy.czf> <20051027161005.GB16197@netbsd.org> In-Reply-To: <20051027161005.GB16197@netbsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200510280127.50156.hselasky@c2i.net> Cc: Subject: Re: FreeBSD 5/6/7 kernel emulator for NetBSD 2.x X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hselasky@c2i.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2005 23:26:52 -0000 On Thursday 27 October 2005 18:10, Bill Studenmund wrote: > On Thu, Oct 27, 2005 at 09:29:52AM +0200, pcah8322@artax.karlin.mff.cuni.= cz=20 wrote: > > On Wed, Oct 26, 2005 at 05:48:06PM -0700, Bill Studenmund wrote: > > > The reason I'm interested in locators is so that if devices renumber > > > themselves, the permissions follow. I am assuming, but I think we'd > > > rather not use locators for names (/dev/sd.52004567BA64678D anyone?). > > > But if we can tie the permissions to a locator, then it doesn't matter > > > if it's sd2 or sd12. :-) > > > > I think it does matter, because all userland programs use device names, > > not locators. If permissions are enforced by an userland program, they > > will not follow locators. > > Oh, but part of all of this would be that userland would be able to find > out the locators for a device! It won't work any other way. > I was thinking that one could mount devfs on /dev/dev, and then make some=20 symlinks from /dev/ to /dev/dev/, hence it is not possible to union mount=20 anything on /dev. Then symlinks and permissions can be managed by a daemon= =20 reading the configuration from "/etc/devfs.conf", like on "FreeBSD". Another problem about /dev as a file system, is that one will possibly not= =20 find all the devices on the system, without being a kernel expert. And the= =20 major/minor numering is not easy, like mentioned by someone else. On Wednesday 26 October 2005 02:09, Lennart Augustsson wrote: > You'll never get a driver that looks exactly right for one > OS to work with another, even with an emulation layer. That is what I have done. Remember, my emulator is not sandwitched between = the=20 driver and the NetBSD kernel. It is more like something that sits beside th= e=20 NetBSD kernel. Else this task would be nearly impossible, due to the=20 differences between NetBSD and FreeBSD. So if you put a driver under my emulation layer, it will not be a child of = the=20 NetBSD device system, but the FreeBSD device system.=20 > For instance, FreeBSD doesn't have an activate method for > device drivers whereas NetBSD and OpenBSD do. There is no problem adding a "device_activate" method to the FreeBSD driver= s,=20 though it will only be used on NetBSD/OpenBSD and alike=B7 In fact, you can= add=20 any method you like to any device. > And there are examples of the reverse. =A0So shared drivers > will have some clutter. I see that there are some problems, but no big problems. For example on=20 =46reeBSD there is no parent bus_dma_tag for PCI devices. But there is no=20 problem to add something like "device_get_parent_dma_tag(device_t *dev)" th= at=20 will return "NULL" on FreeBSD and the correct value on NetBSD. Merging thes= e=20 smaller differences will be the least problem. The situation is like this, that having two branches of a driver is double= =20 work for the maintainer. And maybe this is the reason some drivers are only= =20 available on one system. And when one can spend twice as much time on=20 something, it should be better. Shouldn't it be easier to port kernel=20 software between FreeBSD and NetBSD? When it comes to mutexes I want to say that FreeBSD's "struct mtx" is porta= ble=20 to NetBSD without any problems. But when a NetBSD driver is ported to=20 =46reeBSD, it will fall under the Giant lock, possibly forcing other parts = of=20 the kernel under Giant aswell. Giant is bad, because it puts a single lock = on=20 the kernel. Moving some piece of code out of Giant is sometimes easy, but=20 from my experience, it can require a lot of work. Locking is not just that= =20 simple. An advantage about non-tsleep-able mutexes, is that one can warn th= e=20 user when a function that can sleep is called, depending on the context. Th= is=20 might be as innocent as allocating some memory while holding a mutex, which= =20 many think will not cause a sleep. So code using its own mutexes, is really= =20 preferred, or is it not so important with mutexes? =2D-HPS From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 27 23:36:22 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F1F016A41F for ; Thu, 27 Oct 2005 23:36:22 +0000 (GMT) (envelope-from dmw@unete.cl) Received: from qmail2.ifxnetworks.com (qmail2.ifxnetworks.com [200.110.128.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1962743D48 for ; Thu, 27 Oct 2005 23:36:20 +0000 (GMT) (envelope-from dmw@unete.cl) Received: (qmail 32108 invoked from network); 27 Oct 2005 23:36:19 -0000 Received: from unknown (HELO hopto.org) ([200.73.29.233]) (envelope-sender ) by qmail2.ifxnetworks.com (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 27 Oct 2005 23:36:14 -0000 Received: from hopto.org (null@localhost.daemon.cl [127.0.0.1]) by hopto.org (8.13.4/8.13.1) with ESMTP id j9RNacGF039446; Thu, 27 Oct 2005 20:36:38 -0300 (CLST) (envelope-from dmw@unete.cl) Received: (from dmw@localhost) by hopto.org (8.13.4/8.13.1/Submit) id j9RNabjr039445; Thu, 27 Oct 2005 20:36:37 -0300 (CLST) (envelope-from dmw@unete.cl) X-Authentication-Warning: dmw.hopto.org: dmw set sender to dmw@unete.cl using -f Date: Thu, 27 Oct 2005 20:36:36 -0300 From: Daniel Molina Wegener To: ray@redshift.com Message-ID: <20051027233636.GA39380@dmw.hopto.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Description: message Content-Disposition: inline In-Reply-To: <3.0.1.32.20051027051451.00a842c0@pop.redshift.com> Organization: DMW Cc: kamal kc , freebsd , freebsd Subject: Re: compiling the kernel faster X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Molina Wegener List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2005 23:36:22 -0000 On Thu, Oct 27, 2005 at 05:14:51AM -0700, ray@redshift.com wrote: > At 04:54 AM 10/27/2005 -0700, kamal kc wrote: > | hello everybody, > | > | i am new to kernel programming. > | i am developing a compression/decompression > | functionality in the ip layer. > | > | i want to compile the kernel faster. > | > | it would > | be ok if the kernel doesn't have support for sound > | devices, or other devices like scsi,usb etc. because > | i would be using the compiled kernel for > | network data compression only. > | > | how could i do that. which source files and where in > | the makefiles do i make modifications ???? > | > | thanks for any suggestions > | > | kamal > > Kamal, > > The files you modify to drop stuff out of the kernel are in > /sys/i386/conf/ (assuming you are on an Intel platform). Copy > the GENERIC file in there to something else (e.g DEVKERNEL), > then edit that file. That's OK, also can take a look into the NOTES kernel config for additional options. > Comment out any drivers you don't need using # (check your > dmesg output when you boot to see what drivers the OS is > loading for your hardware). Don't comment out anything unless > it's obviously something you don't need - doublt check the > dmesg for stuff like network drivers, hard drive stuff, etc.) > > Once you comment out the drivers, you will need to re-compile > the kernel. Go into /sys/i386/conf/ directory type this: > > config DEVKERNEL (using the example above) > > then change into the directory it shows you (should be > something like ../compile/DEVKERNEL or something like that) > and type this: > > make depend && make all install clean > > that will compile the new kernel and leave it in /boot/kernel > (it will also backup your old kernel into kernel.old) Here are new instructions to compile the kernel. Go to the root source directory -- usually /usr/src -- then... make buildkernel KERNCONF=DEVKERNEL But, before making a new kernel, if you add new devices, edit the src/sys/conf/files to add the device properly. > go into /boot/kernel/ and type this: > > strip -s * > > then reboot using shutdown -r now Nope, if you are developing over the kernel _never_ strip the symbol table. Do not use the strip command. Instead, use the kernel config command flag in the DEVKERNEL config file. makeoptions DEBUG=-g This will enable symbol tables on the kernel for debugging purposes ;) > If all goes well, you should boot to the new kernel. You can > use the uname -a command to make sure you are on the new > kernel okay. If the machine won't boot, you can boot into > single user mode and copy the old kernel back in place. > > An excellent book on the subject is: > > Absolute BSD: The Ultimate Guide to FreeBSD (Paperback) > > good luck. > > Ray That's OK Also take a look on the FreeBSD Documetation Proyect. Regards. -- . 0 . | Daniel Molina Wegener . . 0 | dmw at unete dot cl 0 0 0 | FreeBSD Power User From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 28 02:54:56 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C7B2916A420 for ; Fri, 28 Oct 2005 02:54:56 +0000 (GMT) (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 244BD43D53 for ; Fri, 28 Oct 2005 02:54:56 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j9S2qn8Y048554; Thu, 27 Oct 2005 20:52:49 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 27 Oct 2005 20:52:50 -0600 (MDT) Message-Id: <20051027.205250.55834228.imp@bsdimp.com> To: dinesh@alphaque.com From: "M. Warner Losh" In-Reply-To: <4361044B.50807@alphaque.com> References: <4360B8EE.4070605@alphaque.com> <4360DD7B.20900@samsco.org> <4361044B.50807@alphaque.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 27 Oct 2005 20:52:52 -0600 (MDT) Cc: freebsd-hackers@freebsd.org, scottl@samsco.org Subject: Re: locking in a device driver 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, 28 Oct 2005 02:54:56 -0000 In message: <4361044B.50807@alphaque.com> Dinesh Nair writes: : the userland application uses pthreads, and works like a charm both on 4.x : and 5.x without using the device. however, when the device is used, it : somehow has synchronization errors on 4.x, leading to timers (created in : the userland app) timing out and the like. libc_r will block all other threads in the application while an ioctl executes. libpthread and libthr won't. I've had several bugs at work that can be traced to faulty drivers and/or faulty APIs that were specified by people who were unaware of this issue... Warner From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 28 04:04:55 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 97A8C16A41F; Fri, 28 Oct 2005 04:04:55 +0000 (GMT) (envelope-from craig@tobuj.gank.org) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2AC4D43D45; Fri, 28 Oct 2005 04:04:54 +0000 (GMT) (envelope-from craig@tobuj.gank.org) Received: by ion.gank.org (mail, from userid 1001) id 8B1832BC50; Thu, 27 Oct 2005 23:04:54 -0500 (CDT) Date: Thu, 27 Oct 2005 23:04:50 -0500 From: Craig Boston To: freebsd-hackers@freebsd.org Message-ID: <20051028040450.GB50419@nowhere> Mail-Followup-To: Craig Boston , freebsd-hackers@freebsd.org, Pawel Jakub Dawidek Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="17pEHd4RhPHOinZp" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Pawel Jakub Dawidek Subject: [PATCH] IPv6 support for ggate 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, 28 Oct 2005 04:04:55 -0000 --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi hackers: Today I had a need to run ggate over an IPv6-only network. I was a little surprised that it didn't seem to like that, but not discouraged. So here's a patch that adds IPv6 support for ggated(8) and ggatec(8) ;) Overview: * Standardizes on sockaddr_storage for both sockets and addresses * A few semantic differences for certain functions due to the above change (ip2str, g_gate_str2ip) * ggated by default listens on both v4 and v6 sockets (uses select loop instead of accept loop). You can listen on v4 only with "-a 0.0.0.0" or v6 only with "-a ::", or of course bind to a specific address * Use getaddrinfo in place of gethostbyname, and parse addresses with inet_pton * All address are stored internally in network byte order now. Mask comparisons should be independent of byte order since it's purely a "vertical" comparison. Things I'm not entirely happy with: * More AF_INET/AF_INET6 conditional code than I'd have liked to add. Unfortunately there doesn't seem to be an easy way to be protocol neutral with a lot of the socket functions. * The v6 part of countmask is really ugly and complicated. I need to check the ifconfig source and see if there's any standard way for converting a /nnn mask to a binary mask. * When resolving DNS names, it will only use the first entry if there are multiple. It technically always had this problem, but it's more noticeable now. Networks are more likely to have names with both a v4 and v6 record than to have multiple v4 addresses. Fixing this the 'right way' would require significantly more invasive changes. Other than that, I was running with this patch for most of the afternoon with great success. Now I just need to write a kernel mode ggatec so I can mount root over ggate :P -- Craig --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ggate.ipv6.diff" diff -ruN ggate.orig/ggatec/ggatec.c ggate/ggatec/ggatec.c --- ggate.orig/ggatec/ggatec.c Thu Oct 27 22:12:19 2005 +++ ggate/ggatec/ggatec.c Thu Oct 27 22:28:22 2005 @@ -244,21 +244,27 @@ struct g_gate_version ver; struct g_gate_cinit cinit; struct g_gate_sinit sinit; - struct sockaddr_in serv; + struct sockaddr_storage serv; int sfd; /* * Do the network stuff. */ bzero(&serv, sizeof(serv)); - serv.sin_family = AF_INET; - serv.sin_addr.s_addr = g_gate_str2ip(host); - if (serv.sin_addr.s_addr == INADDR_NONE) { - g_gate_log(LOG_DEBUG, "Invalid IP/host name: %s.", host); - return (-1); + serv = g_gate_str2ip(host); + switch(serv.ss_family) { + case AF_INET: + ((struct sockaddr_in*)&serv)->sin_port = htons(port); + break; + case AF_INET6: + ((struct sockaddr_in6*)&serv)->sin6_port = htons(port); + break; + default: + g_gate_log(LOG_DEBUG, + "Invalid IP/host name: %s.", host); + return (-1); } - serv.sin_port = htons(port); - sfd = socket(AF_INET, SOCK_STREAM, 0); + sfd = socket(serv.ss_family, SOCK_STREAM, 0); if (sfd == -1) { g_gate_log(LOG_DEBUG, "Cannot open socket: %s.", strerror(errno)); @@ -267,7 +273,7 @@ g_gate_socket_settings(sfd); - if (connect(sfd, (struct sockaddr *)&serv, sizeof(serv)) == -1) { + if (connect(sfd, (struct sockaddr *)&serv, serv.ss_len) == -1) { g_gate_log(LOG_DEBUG, "Cannot connect to server: %s.", strerror(errno)); close(sfd); diff -ruN ggate.orig/ggated/ggated.c ggate/ggated/ggated.c --- ggate.orig/ggated/ggated.c Thu Oct 27 22:12:19 2005 +++ ggate/ggated/ggated.c Thu Oct 27 22:37:55 2005 @@ -68,7 +68,7 @@ time_t c_birthtime; char *c_path; uint64_t c_token; - in_addr_t c_srcip; + struct sockaddr_storage c_srcaddr; LIST_ENTRY(ggd_connection) c_next; }; @@ -84,15 +84,16 @@ struct ggd_export { char *e_path; /* path to device/file */ - in_addr_t e_ip; /* remote IP address */ - in_addr_t e_mask; /* IP mask */ + struct sockaddr_storage e_addr; /* remote IP address */ + struct sockaddr_storage e_mask; /* IP mask */ + unsigned e_prefixlen; unsigned e_flags; /* flags (RO/RW) */ SLIST_ENTRY(ggd_export) e_next; }; static const char *exports_file = GGATED_EXPORT_FILE; static int got_sighup = 0; -in_addr_t bindaddr; +struct sockaddr_storage bindaddr; static TAILQ_HEAD(, ggd_request) inqueue = TAILQ_HEAD_INITIALIZER(inqueue); static TAILQ_HEAD(, ggd_request) outqueue = TAILQ_HEAD_INITIALIZER(outqueue); @@ -116,31 +117,71 @@ } static char * -ip2str(in_addr_t ip) +ip2str(struct sockaddr *addr) { - static char sip[16]; + static char sip[40]; + void *data; - snprintf(sip, sizeof(sip), "%u.%u.%u.%u", - ((ip >> 24) & 0xff), - ((ip >> 16) & 0xff), - ((ip >> 8) & 0xff), - (ip & 0xff)); + switch(addr->sa_family) { + case AF_INET: + data = &((struct sockaddr_in*)addr)->sin_addr; + break; + case AF_INET6: + data = &((struct sockaddr_in6*)addr)->sin6_addr; + break; + default: + strcpy(sip, "Unknown"); + return sip; + } + + if (!inet_ntop(addr->sa_family, data, sip, sizeof(sip))) + strcpy(sip, "Unknown"); return (sip); } -static in_addr_t -countmask(unsigned m) +static struct sockaddr_storage +countmask(unsigned m, sa_family_t f) { - in_addr_t mask; + struct sockaddr_storage ss; - if (m == 0) { - mask = 0x0; - } else { - mask = 1 << (32 - m); - mask--; - mask = ~mask; + bzero(&ss, sizeof(ss)); + ss.ss_family = f; + + if (f == AF_INET) { + in_addr_t mask4; + if (m == 0) { + mask4 = 0x0; + } else { + mask4 = 1 << (32 - m); + mask4--; + mask4 = ~mask4; + } + + ((struct sockaddr_in*)&ss)->sin_addr.s_addr = htonl(mask4); + } else if (f == AF_INET6) { + uint32_t mask6; + int i; + unsigned cm; + + for (i = 3; i >= 0; i--) { + if (m <= 32*(unsigned)i) { + mask6 = 0; + } else { + cm = m - 32*i; + if (cm >= 32) { + mask6 = 0xffffffff; + } else { + mask6 = 1 << (32 - cm); + mask6--; + mask6 = ~mask6; + } + } + + ((struct sockaddr_in6*)&ss)->sin6_addr.__u6_addr.__u6_addr32[i] = htonl(mask6); + } } - return (mask); + + return (ss); } static void @@ -149,9 +190,11 @@ struct ggd_export *ex; char *word, *path, *sflags; unsigned flags, i, vmask; - in_addr_t ip, mask; + struct sockaddr_storage ip, mask; - ip = mask = flags = vmask = 0; + flags = vmask = 0; + bzero(&ip, sizeof(ip)); + bzero(&mask, sizeof(mask)); path = NULL; sflags = NULL; @@ -160,13 +203,14 @@ switch (i) { case 0: /* IP address or host name */ ip = g_gate_str2ip(strsep(&word, "/")); - if (ip == INADDR_NONE) { + if (ip.ss_family == AF_UNSPEC) { g_gate_xlog("Invalid IP/host name at line %u.", lineno); } - ip = ntohl(ip); - if (word == NULL) + if (word == NULL && ip.ss_family == AF_INET) vmask = 32; + else if (word == NULL && ip.ss_family == AF_INET6) + vmask = 128; else { errno = 0; vmask = strtoul(word, NULL, 10); @@ -174,12 +218,15 @@ g_gate_xlog("Invalid IP mask value at " "line %u.", lineno); } - if ((unsigned)vmask > 32) { - g_gate_xlog("Invalid IP mask value at line %u.", - lineno); + if (((unsigned)vmask > 32 && + ip.ss_family == AF_INET) || + ((unsigned)vmask > 128 && + ip.ss_family == AF_INET6)) { + g_gate_xlog("Invalid IP mask value at " + "line %u.", lineno); } } - mask = countmask(vmask); + mask = countmask(vmask, ip.ss_family); break; case 1: /* flags */ if (strcasecmp("rd", word) == 0 || @@ -217,14 +264,15 @@ g_gate_xlog("No enough memory."); /* Made 'and' here. */ - ex->e_ip = (ip & mask); + ex->e_addr = ip; ex->e_mask = mask; + ex->e_prefixlen = vmask; ex->e_flags = flags; SLIST_INSERT_HEAD(&exports, ex, e_next); g_gate_log(LOG_DEBUG, "Added %s/%u %s %s to exports list.", - ip2str(ex->e_ip), vmask, path, sflags); + ip2str((struct sockaddr*)&ex->e_addr), vmask, path, sflags); } static void @@ -302,12 +350,11 @@ exports_check(struct ggd_export *ex, struct g_gate_cinit *cinit, struct ggd_connection *conn) { - char ipmask[32]; /* 32 == strlen("xxx.xxx.xxx.xxx/xxx.xxx.xxx.xxx")+1 */ + char ipmask[44]; /* 44 == strlen("xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/xxx")+1 */ int error = 0, flags; - strlcpy(ipmask, ip2str(ex->e_ip), sizeof(ipmask)); - strlcat(ipmask, "/", sizeof(ipmask)); - strlcat(ipmask, ip2str(ex->e_mask), sizeof(ipmask)); + snprintf(ipmask, sizeof(ipmask), "%s/%u", + ip2str((struct sockaddr*)&ex->e_addr), ex->e_prefixlen); if ((cinit->gc_flags & GGATE_FLAG_RDONLY) != 0) { if (ex->e_flags == O_WRONLY) { g_gate_log(LOG_WARNING, "Read-only access requested, " @@ -355,17 +402,56 @@ return (0); } +static int +mask_compare(struct sockaddr *a, struct sockaddr *b, struct sockaddr *m) { + + if (a->sa_family != m->sa_family) { + g_gate_log(LOG_DEBUG, + "mask_check: Address/mask family mismatch."); + return 0; + } + + if (m->sa_family == AF_INET) { + struct sockaddr_in *a4 = (struct sockaddr_in*)a; + struct sockaddr_in *b4 = (struct sockaddr_in*)b; + struct sockaddr_in *m4 = (struct sockaddr_in*)m; + + if ((a4->sin_addr.s_addr & m4->sin_addr.s_addr) == + (b4->sin_addr.s_addr & m4->sin_addr.s_addr)) { + return 1; + } + } else if (m->sa_family == AF_INET6) { + struct sockaddr_in6 *a6 = (struct sockaddr_in6*)a; + struct sockaddr_in6 *b6 = (struct sockaddr_in6*)b; + struct sockaddr_in6 *m6 = (struct sockaddr_in6*)m; + uint32_t *aaddr = a6->sin6_addr.__u6_addr.__u6_addr32; + uint32_t *baddr = b6->sin6_addr.__u6_addr.__u6_addr32; + uint32_t *maddr = m6->sin6_addr.__u6_addr.__u6_addr32; + int i; + + for (i = 0; i < 4; i++) { + if ((aaddr[i] & maddr[i]) != + (baddr[i] & maddr[i])) { + return 0; + } + } + + return 1; + } + + return 0; +} + static struct ggd_export * exports_find(struct sockaddr *s, struct g_gate_cinit *cinit, struct ggd_connection *conn) { struct ggd_export *ex; - in_addr_t ip; int error; - ip = htonl(((struct sockaddr_in *)(void *)s)->sin_addr.s_addr); SLIST_FOREACH(ex, &exports, e_next) { - if ((ip & ex->e_mask) != ex->e_ip) { + if (!mask_compare(s, (struct sockaddr*)&ex->e_addr, + (struct sockaddr*)&ex->e_mask)) { g_gate_log(LOG_DEBUG, "exports[%s]: IP mismatch.", ex->e_path); continue; @@ -384,7 +470,7 @@ } } g_gate_log(LOG_WARNING, "Unauthorized connection from: %s.", - ip2str(ip)); + ip2str(s)); errno = EPERM; return (NULL); } @@ -404,7 +490,8 @@ LIST_REMOVE(conn, c_next); g_gate_log(LOG_NOTICE, "Connection from %s [%s] removed.", - ip2str(conn->c_srcip), conn->c_path); + ip2str((struct sockaddr*)&conn->c_srcaddr), + conn->c_path); close(conn->c_diskfd); close(conn->c_sendfd); close(conn->c_recvfd); @@ -430,7 +517,6 @@ connection_new(struct g_gate_cinit *cinit, struct sockaddr *s, int sfd) { struct ggd_connection *conn; - in_addr_t ip; /* * First, look for old connections. @@ -449,8 +535,7 @@ return (NULL); } conn->c_token = cinit->gc_token; - ip = htonl(((struct sockaddr_in *)(void *)s)->sin_addr.s_addr); - conn->c_srcip = ip; + memcpy(&conn->c_srcaddr, s, s->sa_len); conn->c_sendfd = conn->c_recvfd = -1; if ((cinit->gc_flags & GGATE_FLAG_SEND) != 0) conn->c_sendfd = sfd; @@ -461,7 +546,7 @@ time(&conn->c_birthtime); conn->c_flags = cinit->gc_flags; LIST_INSERT_HEAD(&connections, conn, c_next); - g_gate_log(LOG_DEBUG, "Connection created [%s, %s].", ip2str(ip), + g_gate_log(LOG_DEBUG, "Connection created [%s, %s].", ip2str(s), conn->c_path); return (conn); } @@ -470,13 +555,11 @@ connection_add(struct ggd_connection *conn, struct g_gate_cinit *cinit, struct sockaddr *s, int sfd) { - in_addr_t ip; - ip = htonl(((struct sockaddr_in *)(void *)s)->sin_addr.s_addr); if ((cinit->gc_flags & GGATE_FLAG_SEND) != 0) { if (conn->c_sendfd != -1) { g_gate_log(LOG_WARNING, - "Send socket already exists [%s, %s].", ip2str(ip), + "Send socket already exists [%s, %s].", ip2str(s), conn->c_path); return (EEXIST); } @@ -485,12 +568,12 @@ if (conn->c_recvfd != -1) { g_gate_log(LOG_WARNING, "Receive socket already exists [%s, %s].", - ip2str(ip), conn->c_path); + ip2str(s), conn->c_path); return (EEXIST); } conn->c_recvfd = sfd; } - g_gate_log(LOG_DEBUG, "Connection added [%s, %s].", ip2str(ip), + g_gate_log(LOG_DEBUG, "Connection added [%s, %s].", ip2str(s), conn->c_path); return (0); } @@ -505,7 +588,7 @@ LIST_REMOVE(conn, c_next); g_gate_log(LOG_DEBUG, "Connection removed [%s %s].", - ip2str(conn->c_srcip), conn->c_path); + ip2str((struct sockaddr*)&conn->c_srcaddr), conn->c_path); if (conn->c_sendfd != -1) close(conn->c_sendfd); if (conn->c_recvfd != -1) @@ -815,10 +898,8 @@ static void log_connection(struct sockaddr *from) { - in_addr_t ip; - ip = htonl(((struct sockaddr_in *)(void *)from)->sin_addr.s_addr); - g_gate_log(LOG_INFO, "Connection from: %s.", ip2str(ip)); + g_gate_log(LOG_INFO, "Connection from: %s.", ip2str(from)); } static int @@ -940,14 +1021,18 @@ int main(int argc, char *argv[]) { - struct sockaddr_in serv; - struct sockaddr from; + fd_set listenfds; + struct sockaddr_in serv4; + struct sockaddr_in6 serv6; + struct sockaddr_storage from; socklen_t fromlen; - int sfd, tmpsfd; + int sfd4, sfd6, tmpsfd, maxfd; unsigned port; - bindaddr = htonl(INADDR_ANY); + bindaddr.ss_family = AF_UNSPEC; port = G_GATE_PORT; + sfd4 = sfd6 = -1; + maxfd = 0; for (;;) { int ch; @@ -957,7 +1042,7 @@ switch (ch) { case 'a': bindaddr = g_gate_str2ip(optarg); - if (bindaddr == INADDR_NONE) { + if (bindaddr.ss_family == AF_UNSPEC) { errx(EXIT_FAILURE, "Invalid IP/host name to bind to."); } @@ -1006,28 +1091,84 @@ signal(SIGCHLD, SIG_IGN); - sfd = socket(AF_INET, SOCK_STREAM, 0); - if (sfd == -1) - g_gate_xlog("Cannot open stream socket: %s.", strerror(errno)); - bzero(&serv, sizeof(serv)); - serv.sin_family = AF_INET; - serv.sin_addr.s_addr = bindaddr; - serv.sin_port = htons(port); - - g_gate_socket_settings(sfd); - - if (bind(sfd, (struct sockaddr *)&serv, sizeof(serv)) == -1) - g_gate_xlog("bind(): %s.", strerror(errno)); - if (listen(sfd, 5) == -1) - g_gate_xlog("listen(): %s.", strerror(errno)); + if (bindaddr.ss_family != AF_INET6) { + struct sockaddr_in *bindaddr4 = (struct sockaddr_in*)&bindaddr; + + sfd4 = socket(AF_INET, SOCK_STREAM, 0); + if (sfd4 == -1) + g_gate_xlog("Cannot open stream socket: %s.", + strerror(errno)); + + bzero(&serv4, sizeof(serv4)); + serv4.sin_family = AF_INET; + if (bindaddr.ss_family == AF_INET) + serv4.sin_addr.s_addr = bindaddr4->sin_addr.s_addr; + else + serv4.sin_addr.s_addr = INADDR_ANY; + serv4.sin_port = htons(port); + + g_gate_socket_settings(sfd4); + + if (bind(sfd4, (struct sockaddr *)&serv4, sizeof(serv4)) == -1) + g_gate_xlog("bind(): %s.", strerror(errno)); + if (listen(sfd4, 5) == -1) + g_gate_xlog("listen(): %s.", strerror(errno)); + + g_gate_log(LOG_INFO, "Listen on IPv4 port: %d.", port); + + if (maxfd <= sfd4) + maxfd = sfd4 + 1; + } + if (bindaddr.ss_family != AF_INET) { + struct sockaddr_in6 *bindaddr6 = (struct sockaddr_in6*)&bindaddr; + + sfd6 = socket(AF_INET6, SOCK_STREAM, 0); + if (sfd6 == -1) + g_gate_xlog("Cannot open stream socket: %s.", + strerror(errno)); + bzero(&serv6, sizeof(serv6)); + serv6.sin6_family = AF_INET6; + if (bindaddr.ss_family == AF_INET6) { + serv6.sin6_addr = bindaddr6->sin6_addr; + } else { + struct in6_addr in6any = IN6ADDR_ANY_INIT; + serv6.sin6_addr = in6any; + } + serv6.sin6_port = htons(port); + + g_gate_socket_settings(sfd6); - g_gate_log(LOG_INFO, "Listen on port: %d.", port); + if (bind(sfd6, (struct sockaddr *)&serv6, sizeof(serv6)) == -1) + g_gate_xlog("bind(): %s.", strerror(errno)); + if (listen(sfd6, 5) == -1) + g_gate_xlog("listen(): %s.", strerror(errno)); + + g_gate_log(LOG_INFO, "Listen on IPv6 port: %d.", port); + + if (maxfd <= sfd6) + maxfd = sfd6 + 1; + } signal(SIGHUP, huphandler); for (;;) { + FD_ZERO(&listenfds); + if (sfd4 > 0) + FD_SET(sfd4, &listenfds); + if (sfd6 > 0) + FD_SET(sfd6, &listenfds); + + select(maxfd, &listenfds, NULL, NULL, NULL); + fromlen = sizeof(from); - tmpsfd = accept(sfd, &from, &fromlen); + if (sfd4 > 0 && FD_ISSET(sfd4, &listenfds)) { + tmpsfd = accept(sfd4, (struct sockaddr*)&from, + &fromlen); + } else if (sfd6 > 0 && FD_ISSET(sfd6, &listenfds)) { + tmpsfd = accept(sfd6, (struct sockaddr*)&from, + &fromlen); + } else continue; + if (tmpsfd == -1) g_gate_xlog("accept(): %s.", strerror(errno)); @@ -1036,9 +1177,12 @@ exports_get(); } - if (!handshake(&from, tmpsfd)) + if (!handshake((struct sockaddr*)&from, tmpsfd)) close(tmpsfd); } - close(sfd); + if (sfd4 > 0) + close(sfd4); + if (sfd6 > 0) + close(sfd6); exit(EXIT_SUCCESS); } diff -ruN ggate.orig/shared/ggate.c ggate/shared/ggate.c --- ggate.orig/shared/ggate.c Thu Oct 27 22:12:19 2005 +++ ggate/shared/ggate.c Thu Oct 27 22:39:22 2005 @@ -376,20 +376,47 @@ } #endif /* LIBGEOM */ -in_addr_t +struct sockaddr_storage g_gate_str2ip(const char *str) { - struct hostent *hp; - in_addr_t ip; + struct sockaddr_storage ss; + struct addrinfo *addr; + struct sockaddr_in *ip = (struct sockaddr_in*)&ss; + struct sockaddr_in6 *ip6 = (struct sockaddr_in6*)&ss; - ip = inet_addr(str); - if (ip != INADDR_NONE) { - /* It is a valid IP address. */ - return (ip); + bzero(&ss, sizeof(ss)); + + if (inet_pton(AF_INET, str, &ip->sin_addr.s_addr)) { + /* It is a valid IPv4 address. */ + ss.ss_len = sizeof(struct sockaddr_in); + ss.ss_family = AF_INET; + return ss; + } else if (inet_pton(AF_INET6, str, &ip6->sin6_addr)) { + /* It is a valid IPv6 address. */ + ss.ss_len = sizeof(struct sockaddr_in6); + ss.ss_family = AF_INET6; + return ss; } + /* Check if it is a valid host name. */ - hp = gethostbyname(str); - if (hp == NULL) - return (INADDR_NONE); - return (((struct in_addr *)(void *)hp->h_addr)->s_addr); + if (!getaddrinfo(str, NULL, NULL, &addr)) { + struct sockaddr* sa = (struct sockaddr*)&ss; + + sa->sa_family = addr->ai_family; + switch(sa->sa_family) { + case AF_INET: + sa->sa_len = sizeof(struct sockaddr_in); + break; + case AF_INET6: + sa->sa_len = sizeof(struct sockaddr_in6); + break; + } + + memcpy(&sa->sa_data, addr->ai_addr, addr->ai_addrlen); + freeaddrinfo(addr); + return ss; + } + + ss.ss_family = AF_UNSPEC; + return ss; } diff -ruN ggate.orig/shared/ggate.h ggate/shared/ggate.h --- ggate.orig/shared/ggate.h Thu Oct 27 22:12:19 2005 +++ ggate/shared/ggate.h Thu Oct 27 11:14:30 2005 @@ -110,7 +110,7 @@ #ifdef LIBGEOM void g_gate_list(int unit, int verbose); #endif -in_addr_t g_gate_str2ip(const char *str); +struct sockaddr_storage g_gate_str2ip(const char *str); /* * g_gate_swap2h_* - functions swap bytes to host byte order (from big endian). --17pEHd4RhPHOinZp-- From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 28 04:59:14 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C75916A420 for ; Fri, 28 Oct 2005 04:59:14 +0000 (GMT) (envelope-from matt@gsicomp.on.ca) Received: from skippyii.compar.com (webpos.compar.com [216.208.38.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0B0043D66 for ; Fri, 28 Oct 2005 04:59:10 +0000 (GMT) (envelope-from matt@gsicomp.on.ca) Received: from hermes (CPE00062566c7bb-CM000039c69a66.cpe.net.cable.rogers.com [70.28.254.189] (may be forged)) by skippyii.compar.com (8.13.1/8.13.1) with ESMTP id j9S4xxlt005205 for ; Fri, 28 Oct 2005 01:00:00 -0400 (EDT) (envelope-from matt@gsicomp.on.ca) Message-ID: <002a01c5db7c$6817e030$1200a8c0@gsicomp.on.ca> From: "Matt Emmerton" To: Date: Fri, 28 Oct 2005 00:59:39 -0400 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 Subject: RFC: porting NetBSD fsdb enhancements to FreeBSD 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, 28 Oct 2005 04:59:14 -0000 Recently I've had to do some low-level surgery on some disks that have gone bad in order to recover some of the data. This has required me to zero out blocks on disk, patch up the affected files, and pull the data off the disks. I was toying around the with fsdb tool, but couldn't figure out a way to map blocks to inodes (although the 'blocks' command does the mapping in the other direction quite nicely.) Poking around I found that someone has added this functionality (via a "findblk" command) to NetBSD's fsdb (back in 2003!), which I have grafted onto a 4.x box here with relative ease. NetBSD Mailing List Posting: http://groups.google.com/group/mailing.netbsd.tech.userlevel/browse_thread/thread/18acceb04cf5aadb/2a891d67edf9279%232a891d67edf9279?sa=X&oi=groupsr&start=0&num=3) NetBSD CVS: http://cvsweb.netbsd.org/bsdweb.cgi/src/sbin/fsdb/fsdb.c.diff?r1=1.24&r2=1.25&f=h Is this something that folks would like to see on FreeBSD? I've got RELENG_5_4 and RELENG_6_0 boxes here in my office so I can whip up the patches and do some testing in short order. Regards, -- Matt Emmerton From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 28 07:02:44 2005 Return-Path: X-Original-To: hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 743A616A420; Fri, 28 Oct 2005 07:02:44 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: from mail.localelinks.com (web.localelinks.com [65.170.254.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id E89FD43D46; Fri, 28 Oct 2005 07:02:41 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: from mortis.over-yonder.net (adsl-152-91-239.jan.bellsouth.net [70.152.91.239]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.localelinks.com (Postfix) with ESMTP id DF1BB2A; Fri, 28 Oct 2005 02:02:40 -0500 (CDT) Received: by mortis.over-yonder.net (Postfix, from userid 100) id 1DC1320F67; Fri, 28 Oct 2005 02:02:38 -0500 (CDT) Date: Fri, 28 Oct 2005 02:02:37 -0500 From: "Matthew D. Fuller" To: "Mikhail T." Message-ID: <20051028070237.GB68758@over-yonder.net> References: <200510280518.j9S5I3oQ025430@blue.virtual-estates.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200510280518.j9S5I3oQ025430@blue.virtual-estates.net> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.9i-fullermd.2 Cc: hackers@FreeBSD.org, hardware@FreeBSD.org, sos@FreeBSD.org Subject: Re: Very slow writing to SATA disk 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, 28 Oct 2005 07:02:44 -0000 On Fri, Oct 28, 2005 at 01:18:03AM -0400 I heard the voice of Mikhail T., and lo! it spake thus: > > According to smartctl, the drive runs at 56C during the copying. Its > idle temperature seems to be 54C. That sounds a little high to me. Smartctl has been weird lately, and it only shows temp on one of my drives, but it (7200RPM 9gig SCSI) is showing 32C. The higher density probably burns a little more power, but half again the temperature? -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 28 09:24:53 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B294A16A438 for ; Fri, 28 Oct 2005 09:24:53 +0000 (GMT) (envelope-from dinesh@alphaque.com) Received: from ns2.alphaque.com (ns2.alphaque.com [202.75.47.153]) by mx1.FreeBSD.org (Postfix) with SMTP id 8912843D46 for ; Fri, 28 Oct 2005 09:24:51 +0000 (GMT) (envelope-from dinesh@alphaque.com) Received: (qmail 4194 invoked by uid 0); 28 Oct 2005 09:24:49 -0000 Received: from lucifer.net-gw.com (HELO prophet.alphaque.com) (202.75.47.153) by lucifer.net-gw.com with SMTP; 28 Oct 2005 09:24:49 -0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by prophet.alphaque.com (8.13.4/8.13.4) with ESMTP id j9S8e159000962; Fri, 28 Oct 2005 16:40:01 +0800 (MYT) (envelope-from dinesh@alphaque.com) Message-ID: <4361E3E0.4090409@alphaque.com> Date: Fri, 28 Oct 2005 16:40:00 +0800 From: Dinesh Nair User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8b) Gecko/20050915 MIME-Version: 1.0 To: "M. Warner Losh" References: <4360B8EE.4070605@alphaque.com> <4360DD7B.20900@samsco.org> <4361044B.50807@alphaque.com> <20051027.205250.55834228.imp@bsdimp.com> In-Reply-To: <20051027.205250.55834228.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, scottl@samsco.org Subject: Re: locking in a device driver 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, 28 Oct 2005 09:24:53 -0000 On 10/28/05 10:52 M. Warner Losh said the following: > libc_r will block all other threads in the application while an ioctl > executes. libpthread and libthr won't. I've had several bugs at work which is a Good Thing(tm) indeed for me on 4.x. -- Regards, /\_/\ "All dogs go to heaven." dinesh@alphaque.com (0 0) http://www.alphaque.com/ +==========================----oOO--(_)--OOo----==========================+ | for a in past present future; do | | for b in clients employers associates relatives neighbours pets; do | | echo "The opinions here in no way reflect the opinions of my $a $b." | | done; done | +=========================================================================+ From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 28 09:49:15 2005 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A12E916A41F; Fri, 28 Oct 2005 09:49:15 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail11.syd.optusnet.com.au (mail11.syd.optusnet.com.au [211.29.132.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE12043D5D; Fri, 28 Oct 2005 09:49:13 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail11.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j9S9mjrv020513 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 28 Oct 2005 19:48:51 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.10/8.12.10) with ESMTP id j9S9miHh050120; Fri, 28 Oct 2005 19:48:44 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost) by cirb503493.alcatel.com.au (8.12.10/8.12.9/Submit) id j9S9mikL050119; Fri, 28 Oct 2005 19:48:44 +1000 (EST) (envelope-from pjeremy) Date: Fri, 28 Oct 2005 19:48:44 +1000 From: Peter Jeremy To: "Mikhail T." Message-ID: <20051028094844.GU39882@cirb503493.alcatel.com.au> References: <200510280518.j9S5I3oQ025430@blue.virtual-estates.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200510280518.j9S5I3oQ025430@blue.virtual-estates.net> User-Agent: Mutt/1.4.2.1i X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc Cc: hackers@freebsd.org, hardware@freebsd.org, sos@freebsd.org Subject: Re: Very slow writing to SATA disk 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, 28 Oct 2005 09:49:15 -0000 On Fri, 2005-Oct-28 01:18:03 -0400, Mikhail T. wrote: >I've got a new Hitachi drive with 16Mb of cache: > > ad8: 476940MB at ata4-master SATA150 > >and am trying to use it to store backups online. Unfortunately, writing >to the disk is painfully slow (by today's standards) -- it can barely >keep 7Mb/second and my other (SCSI) disks run circles around it. If this drive doesn't support tagged-queueing, is the write cache disabled? I get that sort of performance from a (PATA) disk with the cache disabled (hw.ata.wc="0" in loader.conf) >According to smartctl, the drive runs at 56C during the copying. Its >idle temperature seems to be 54C. I'd double-check that (eg with a finger). If the drive really is running at 56°C, it won't last very long. -- Peter Jeremy From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 28 09:50:48 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 69E2416A41F for ; Fri, 28 Oct 2005 09:50:48 +0000 (GMT) (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 17C3E43D78 for ; Fri, 28 Oct 2005 09:50:45 +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 122DC46B7B; Fri, 28 Oct 2005 05:50:44 -0400 (EDT) Date: Fri, 28 Oct 2005 10:50:43 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Matt Emmerton In-Reply-To: <002a01c5db7c$6817e030$1200a8c0@gsicomp.on.ca> Message-ID: <20051028105015.K20147@fledge.watson.org> References: <002a01c5db7c$6817e030$1200a8c0@gsicomp.on.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: RFC: porting NetBSD fsdb enhancements to FreeBSD 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, 28 Oct 2005 09:50:48 -0000 On Fri, 28 Oct 2005, Matt Emmerton wrote: > Recently I've had to do some low-level surgery on some disks that have > gone bad in order to recover some of the data. This has required me to > zero out blocks on disk, patch up the affected files, and pull the data > off the disks. > > I was toying around the with fsdb tool, but couldn't figure out a way to > map blocks to inodes (although the 'blocks' command does the mapping in > the other direction quite nicely.) > > Poking around I found that someone has added this functionality (via a > "findblk" command) to NetBSD's fsdb (back in 2003!), which I have > grafted onto a 4.x box here with relative ease. > > NetBSD Mailing List Posting: > http://groups.google.com/group/mailing.netbsd.tech.userlevel/browse_thread/thread/18acceb04cf5aadb/2a891d67edf9279%232a891d67edf9279?sa=X&oi=groupsr&start=0&num=3) > NetBSD CVS: > http://cvsweb.netbsd.org/bsdweb.cgi/src/sbin/fsdb/fsdb.c.diff?r1=1.24&r2=1.25&f=h > > Is this something that folks would like to see on FreeBSD? I've got > RELENG_5_4 and RELENG_6_0 boxes here in my office so I can whip up the > patches and do some testing in short order. I'm sure if you submit a patch in a PR, we can find someone willing to get it committed. Robert N M Watson From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 28 09:55:28 2005 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F371816A41F; Fri, 28 Oct 2005 09:55:27 +0000 (GMT) (envelope-from ray@redshift.com) Received: from mail.quickmeet.com (quickmeet.com [216.228.17.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3CD743D45; Fri, 28 Oct 2005 09:55:27 +0000 (GMT) (envelope-from ray@redshift.com) Received: from workstation (workstation [192.168.20.250]) by mail.quickmeet.com (Postfix) with SMTP id A8AF217032; Fri, 28 Oct 2005 02:28:02 -0700 (PDT) Message-Id: <3.0.1.32.20051028025532.00a66e90@pop.redshift.com> X-Mailer: na X-Sender: redshift.com Date: Fri, 28 Oct 2005 02:55:32 -0700 To: Peter Jeremy , "Mikhail T." From: ray@redshift.com In-Reply-To: <20051028094844.GU39882@cirb503493.alcatel.com.au> References: <200510280518.j9S5I3oQ025430@blue.virtual-estates.net> <200510280518.j9S5I3oQ025430@blue.virtual-estates.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: hackers@freebsd.org, hardware@freebsd.org, sos@freebsd.org Subject: Re: Very slow writing to SATA disk 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, 28 Oct 2005 09:55:28 -0000 At 07:48 PM 10/28/2005 +1000, Peter Jeremy wrote: | On Fri, 2005-Oct-28 01:18:03 -0400, Mikhail T. wrote: | >I've got a new Hitachi drive with 16Mb of cache: | > | > ad8: 476940MB at ata4-master SATA150 | > | >and am trying to use it to store backups online. Unfortunately, writing | >to the disk is painfully slow (by today's standards) -- it can barely | >keep 7Mb/second and my other (SCSI) disks run circles around it. | | If this drive doesn't support tagged-queueing, is the write cache | disabled? I get that sort of performance from a (PATA) disk with | the cache disabled (hw.ata.wc="0" in loader.conf) | | >According to smartctl, the drive runs at 56C during the copying. Its | >idle temperature seems to be 54C. | | I'd double-check that (eg with a finger). If the drive really is | running at 56°C, it won't last very long. | | -- | Peter Jeremy I just checked the temp on my workstation for comparison. It's running two SATA drives (74GB Raptors) and the temp on those drives is 30C/86F. Like Peter says, at 133F, I don't think they would last very long, not to mention you'd probably smell something hot/burning. Ray From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 28 10:24:19 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DC3516A420; Fri, 28 Oct 2005 10:24:19 +0000 (GMT) (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 B83AA43D45; Fri, 28 Oct 2005 10:24:18 +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 414F746BB1; Fri, 28 Oct 2005 06:24:18 -0400 (EDT) Date: Fri, 28 Oct 2005 11:24:18 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Vaibhave Agarwal In-Reply-To: Message-ID: <20051028105057.J20147@fledge.watson.org> References: <20051027233636.GA39380@dmw.hopto.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd , freebsd Subject: Re: how to make the FreeBSD 6.0 run faster 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, 28 Oct 2005 10:24:19 -0000 On Thu, 27 Oct 2005, Vaibhave Agarwal wrote: > How do u disable malloc debugging flags in the userland? I read > somewhere that " ln -s aj /etc/malloc.conf" disables malloc debugging. > How does it work? > > And how to disable verbose features in the kernel? > > Apart from this, are there other ways to make the kernel run faster?? The note has now been removed, since it was accurate only through the beta series. "Run faster" is a bit nebulous, as performance optimization is a complex thing. Since you CC'd the net@ list, I assume you want the networking to run faster. The usual techniques are: - If your workload permits it, run with network stack direct dispatch, which avoids a context switch into the network stack. Be warned that this may reduce the opportunities for parallelism between the interrupt and link layer code and network layer code, so while it improves many workloads, it won't improve all. Set net.dispatch.direct=1. - If your workload benefits from it, consider running with device polling -- this moves form an interrupt driven network model to a polled network model, greatly decreasing overhead as a result of avoiding thrashing interrupt handlers, and allowing you to moderate the load generated by the network. See polling(4) for details, as this requires a custom kernel configuration and some careful thought. This is usually best for routers, etc. Polling may increase the latency of packet processing based on how frequently polling polls, but substantially increase throughput. - Depending on the workload and hardware, you may want to reconsider compiling with SMP. I.e., for some workloads, HTT helps, and SMP helps, and for other workloads, it doesn't. - Carefully evaluate your hardware configuration -- if this is about network performance, you may want to make sure that storage and networking devices are on separate PCI buses, and that if needed, those buses are 64-bit. - Another common hardware issue is shared interrupts -- for example, on many motherboards, USB and the on-motherboard network device end up on the same interrupt, or their interrupts fire simultaneously regardless of the interrupt numbers. Since the USB code is pretty heavy-weight, you don't want to run it every time you receive a batch of packets via an interrupt for gig-e. Compiling out USB in this environment may help. This problem can be detected using vmstat -i, and seeing if the interrupt rates for USB and your motherboard network device both look the same -- i.e., very big. - Another common concern with threaded network applications is whether the thread library model and implementation match the requirements of your application. FreeBSD provides several thread libraries with different properties, so you might want to consider changing thread libraries. - Recent reports indicate that on some systems, slow time counters are used during context switches. You may want to consider switching to a faster time counter if time accuracy is less important to you. In one measurement, this added 30% performance to loop-back network traffic. This issue is being actively researched. Other than that, you'll need to tell us what you're doing. Robert N M Watson From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 27 23:53:02 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F58C16A421; Thu, 27 Oct 2005 23:53:02 +0000 (GMT) (envelope-from vaibhave@cs.utah.edu) Received: from mail-svr1.cs.utah.edu (brahma.cs.utah.edu [155.98.64.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E1F843D5D; Thu, 27 Oct 2005 23:53:00 +0000 (GMT) (envelope-from vaibhave@cs.utah.edu) Received: from localhost (localhost [127.0.0.1]) by mail-svr1.cs.utah.edu (Postfix) with ESMTP id 998C1346EB; Thu, 27 Oct 2005 17:52:59 -0600 (MDT) Received: from mail-svr1.cs.utah.edu ([127.0.0.1]) by localhost (mail-svr1.cs.utah.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26618-05; Thu, 27 Oct 2005 17:52:59 -0600 (MDT) Received: from trust.cs.utah.edu (trust.cs.utah.edu [155.98.65.28]) by mail-svr1.cs.utah.edu (Postfix) with ESMTP id 4CF88346D3; Thu, 27 Oct 2005 17:52:59 -0600 (MDT) Received: by trust.cs.utah.edu (Postfix, from userid 4969) id 26DD63F6F; Thu, 27 Oct 2005 17:52:59 -0600 (MDT) Received: from localhost (localhost [127.0.0.1]) by trust.cs.utah.edu (Postfix) with ESMTP id 189AC3F6C; Thu, 27 Oct 2005 17:52:59 -0600 (MDT) Date: Thu, 27 Oct 2005 17:52:59 -0600 (MDT) From: Vaibhave Agarwal To: freebsd In-Reply-To: <20051027233636.GA39380@dmw.hopto.org> Message-ID: References: <20051027233636.GA39380@dmw.hopto.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: amavisd-new at cs.utah.edu X-Mailman-Approved-At: Fri, 28 Oct 2005 13:18:07 +0000 Cc: freebsd Subject: how to make the FreeBSD 6.0 run faster 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, 27 Oct 2005 23:53:02 -0000 In the file /usr/src/UPDATING, there is a following statement NOTE TO PEOPLE WHO THINK THAT FreeBSD 6.x IS SLOW: FreeBSD 6.x has many debugging features turned on, in both the kernel and userland. These features attempt to detect incorrect use of system primitives, and encourage loud failure through extra sanity checking and fail stop semantics. They also substantially impact system performance. If you want to do performance measurement, benchmarking, and optimization, you'll want to turn them off. This includes various WITNESS- related kernel options, INVARIANTS, malloc debugging flags in userland, and various verbose features in the kernel. Many developers choose to disable these features on build machines to maximize performance. How do u disable malloc debugging flags in the userland? I read somewhere that " ln -s aj /etc/malloc.conf" disables malloc debugging. How does it work? And how to disable verbose features in the kernel? Apart from this, are there other ways to make the kernel run faster?? thanks vaibhave From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 28 01:20:14 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48F6F16A420 for ; Fri, 28 Oct 2005 01:20:14 +0000 (GMT) (envelope-from glenn@antimatter.net) Received: from cobalt.antimatter.net (cobalt.antimatter.net [69.55.224.239]) by mx1.FreeBSD.org (Postfix) with ESMTP id F037143D48 for ; Fri, 28 Oct 2005 01:20:13 +0000 (GMT) (envelope-from glenn@antimatter.net) Received: from glenn-mobile.antimatter.net (cpe-66-91-226-109.san.res.rr.com [66.91.226.109]) (authenticated bits=0) by cobalt.antimatter.net (8.13.4/8.13.4) with ESMTP id j9S1KCS2024668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Oct 2005 18:20:13 -0700 X-MailKey: purple frogs are falling from the sky Message-Id: <6.2.3.4.2.20051027181307.04801d70@cobalt.antimatter.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Thu, 27 Oct 2005 18:17:41 -0700 To: Daniel Molina Wegener , ray@redshift.com From: Glenn Dawson In-Reply-To: <20051027233636.GA39380@dmw.hopto.org> References: <3.0.1.32.20051027051451.00a842c0@pop.redshift.com> <20051027233636.GA39380@dmw.hopto.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Fri, 28 Oct 2005 13:18:07 +0000 Cc: kamal kc , freebsd Subject: Re: compiling the kernel faster 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, 28 Oct 2005 01:20:14 -0000 At 04:36 PM 10/27/2005, Daniel Molina Wegener wrote: > On Thu, Oct 27, 2005 at 05:14:51AM -0700, > ray@redshift.com wrote: > > > At 04:54 AM 10/27/2005 -0700, kamal kc wrote: > > | hello everybody, > > | > > | i am new to kernel programming. > > | i am developing a compression/decompression > > | functionality in the ip layer. > > | > > | i want to compile the kernel faster. > > | You can set NOCLEAN in your environment. That will save you from having to rebuild things that didn't change. Major time saver if you're only working in a couple of files. -Glenn From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 28 05:18:04 2005 Return-Path: X-Original-To: hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E5DC216A41F; Fri, 28 Oct 2005 05:18:04 +0000 (GMT) (envelope-from mi@blue.virtual-estates.net) Received: from blue.virtual-estates.net (aldan.algebra.com [216.254.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B88443D55; Fri, 28 Oct 2005 05:18:04 +0000 (GMT) (envelope-from mi@blue.virtual-estates.net) Received: from blue.virtual-estates.net (blue [127.0.0.1]) by blue.virtual-estates.net (8.13.4/8.13.4) with ESMTP id j9S5I3Y6025431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Oct 2005 01:18:03 -0400 (EDT) (envelope-from mi@blue.virtual-estates.net) Received: (from mi@localhost) by blue.virtual-estates.net (8.13.4/8.13.4/Submit) id j9S5I3oQ025430; Fri, 28 Oct 2005 01:18:03 -0400 (EDT) (envelope-from mi) From: "Mikhail T." Message-Id: <200510280518.j9S5I3oQ025430@blue.virtual-estates.net> To: hardware@FreeBSD.org, hackers@FreeBSD.org Date: Fri, 28 Oct 2005 01:18:03 -0400 (EDT) X-Face: %UW#n0|w>ydeGt/b@1-.UFP=K^~-:0f#O:D7w hJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2005 05:18:05 -0000 Hi! I've got a new Hitachi drive with 16Mb of cache: ad8: 476940MB at ata4-master SATA150 and am trying to use it to store backups online. Unfortunately, writing to the disk is painfully slow (by today's standards) -- it can barely keep 7Mb/second and my other (SCSI) disks run circles around it. I tried to just cp a huge file from a SCSI disk to this one -- without any other activity. 7Mb/second is the best it could do :-( For bulk writing, undisturbed by other access, I'd expect at least 30Mb/sec... Is it the drive, the controller: atapci1: port 0xac00-0xac07,0xa480-0xa483,0xa400-0xa407,0xa080-0xa083,0xa000-0xa00f mem 0xbe6fbc00-0xbe6fbfff irq 25 at device 5.0 on pci3 the driver (6.0/amd64), or a misconfiguration of some sort? According to smartctl, the drive runs at 56C during the copying. Its idle temperature seems to be 54C. Thanks for any hints! -mi From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 28 12:01:42 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B15616A41F; Fri, 28 Oct 2005 12:01:42 +0000 (GMT) (envelope-from babkin@verizon.net) Received: from vms042pub.verizon.net (vms042pub.verizon.net [206.46.252.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4B7643D53; Fri, 28 Oct 2005 12:01:41 +0000 (GMT) (envelope-from babkin@verizon.net) Received: from vms062.mailsrvcs.net ([192.168.1.3]) by vms042.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0IP200I05K2T8C20@vms042.mailsrvcs.net>; Fri, 28 Oct 2005 07:01:41 -0500 (CDT) Date: Fri, 28 Oct 2005 07:01:41 -0500 (CDT) From: Sergey Babkin To: Vaibhave Agarwal Message-id: <20858923.1130500901324.JavaMail.root@vms062.mailsrvcs.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Mailman-Approved-At: Fri, 28 Oct 2005 13:18:07 +0000 Cc: freebsd , freebsd Subject: Re: Re: how to make the FreeBSD 6.0 run faster X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: babkin@users.sf.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2005 12:01:42 -0000 >From: Robert Watson >On Thu, 27 Oct 2005, Vaibhave Agarwal wrote: > >> How do u disable malloc debugging flags in the userland? I read >> somewhere that " ln -s aj /etc/malloc.conf" disables malloc debugging. >> How does it work? >> >> And how to disable verbose features in the kernel? >> >> Apart from this, are there other ways to make the kernel run faster?? > >Other than that, you'll need to tell us what you're doing. And the most important part: try to optimize your application first. I've seen a surprizing number of people who feel that they need to do something with the kernel while what is really suboptimal (or downright broken) is their application. When writing programs people make many assumptions about what is fast and often these assumptions are wrong, plus there are bugs where the code generally works but does it slowly. This is especially true for applications written in C++ and other OO languages, and for threaded applications. If you want to have a cost-efficient solution, the applications really need to be profiled and measured, and all the performance squeezed out of them before going into the kernel. -SB From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 27 22:43:20 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7086E16A41F for ; Thu, 27 Oct 2005 22:43:20 +0000 (GMT) (envelope-from wrstuden@netbsd.org) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id AEAA243D46 for ; Thu, 27 Oct 2005 22:43:19 +0000 (GMT) (envelope-from wrstuden@netbsd.org) Received: by mail.netbsd.org (Postfix, from userid 1130) id 8EF2563B17A; Thu, 27 Oct 2005 22:43:19 +0000 (UTC) Date: Thu, 27 Oct 2005 15:43:17 -0700 From: Bill Studenmund To: der Mouse Message-ID: <20051027224317.GE16197@netbsd.org> References: <200510242235.48403.hselasky@c2i.net> <20051026172252.GA23243@netbsd.org> <200510270845.32525.fcash@ocis.net> <200510272055.QAA19487@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2hMgfIw2X+zgXrFs" Content-Disposition: inline In-Reply-To: <200510272055.QAA19487@Sparkle.Rodents.Montreal.QC.CA> User-Agent: Mutt/1.4.1i X-Mailman-Approved-At: Fri, 28 Oct 2005 13:30:25 +0000 Cc: freebsd-hackers@freebsd.org, tech-kern@NetBSD.org Subject: Re: FreeBSD 5/6/7 kernel emulator for NetBSD 2.x 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, 27 Oct 2005 22:43:20 -0000 --2hMgfIw2X+zgXrFs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 27, 2005 at 04:53:35PM -0400, der Mouse wrote: > >>> - Implements FreeBSD's devfs on NetBSD. > >> In the past, we (NetBSD folks) have talked about a devfs. > >> [...persistence...] > > FreeBSD 5+ has /etc/devfs.conf and /etc/devfs.rules [...]. Is that > > what you're looking for? >=20 > I didn't write what you're responding to, but, speaking personally: >=20 > If making changes to /dev with chmod/chown/mv/etc results in those > files getting rewritten to match, it's fine. If not, it's not. I think that having those changes propogated to the userland config files= =20 would be very good. I'd really want NetBSD to do it, and I bet it could be= =20 a useful feature for FreeBSD too. Take care, Bill --2hMgfIw2X+zgXrFs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (NetBSD) iD8DBQFDYVgFWz+3JHUci9cRAjpGAJ910+d9coFUYHl+vOVZ/YqBtKc4wwCgheZJ Fuyo7+aBPSr117kAAbDEKM0= =0MTz -----END PGP SIGNATURE----- --2hMgfIw2X+zgXrFs-- From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 28 13:35:19 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8540416A41F; Fri, 28 Oct 2005 13:35:19 +0000 (GMT) (envelope-from ray@redshift.com) Received: from mail.quickmeet.com (quickmeet.com [216.228.17.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id A932E43D45; Fri, 28 Oct 2005 13:35:17 +0000 (GMT) (envelope-from ray@redshift.com) Received: from workstation (workstation [192.168.20.250]) by mail.quickmeet.com (Postfix) with SMTP id 7294617032; Fri, 28 Oct 2005 06:07:51 -0700 (PDT) Message-Id: <3.0.1.32.20051028063522.00a75268@pop.redshift.com> X-Mailer: na X-Sender: redshift.com Date: Fri, 28 Oct 2005 06:35:22 -0700 To: babkin@users.sf.net, Vaibhave Agarwal From: ray@redshift.com In-Reply-To: <20858923.1130500901324.JavaMail.root@vms062.mailsrvcs.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: freebsd , freebsd Subject: Re: Re: how to make the FreeBSD 6.0 run faster 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, 28 Oct 2005 13:35:19 -0000 At 07:01 AM 10/28/2005 -0500, Sergey Babkin wrote: | >From: Robert Watson | >On Thu, 27 Oct 2005, Vaibhave Agarwal wrote: | > | >> How do u disable malloc debugging flags in the userland? I read | >> somewhere that " ln -s aj /etc/malloc.conf" disables malloc debugging. | >> How does it work? | >> | >> And how to disable verbose features in the kernel? | >> | >> Apart from this, are there other ways to make the kernel run faster?? | > | >Other than that, you'll need to tell us what you're doing. | | And the most important part: try to optimize your application | first. I've seen a surprizing number of people who feel | that they need to do something with the kernel while what | is really suboptimal (or downright broken) is their application. | When writing programs people make many assumptions about | what is fast and often these assumptions are wrong, plus | there are bugs where the code generally works but does it slowly. | This is especially true for applications written in C++ | and other OO languages, and for threaded applications. | If you want to have a cost-efficient solution, the applications | really need to be profiled and measured, and all the performance | squeezed out of them before going into the kernel. | | -SB | I will second that. In some recent benchmarks I did with our web application, I discovered that I was able to get a nearly 200% boost in speed (i.e. things ran twice as fast) by simply changing how I was handling variables in PHP. The golden rule of performance tweaking is *assume nothing, test everything*. I have read papers on PHP for example that swear up and down that removing comments will not improve speed and that it's just a myth. BS, removing comments does improve speed because the interpreter has less to sift through. Usually performance tuning is the combination of many small improvements, not any one major short fall. Without knowing your exact application, I can't say specifically, but in most all of my cases, the Kernel itself (even when fully optimized) only added about 20 or 30% to any given situation. In my experience, what makes a server scream is the combination of many small performance increases including everything from faster hard drive, more streamlined kernel, streamlined apps, better compilation, better coding on your application, better threading, etc, etc. Eventually you'll reach a point where the time needed to produce further gains becomes a diminishing returns situation and/or stability would have to be sacrificed. At that point, generally it's better, cheaper and faster to just add additional hardware (assuming you are working in a cluster). But to echo what Sergey says, you'd be surprised how often poor coding is the root of the problem, not the kernel. Ray From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 28 15:25:42 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8845316A41F; Fri, 28 Oct 2005 15:25:42 +0000 (GMT) (envelope-from vd@datamax.bg) Received: from jengal.datamax.bg (jengal.datamax.bg [82.103.104.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F57943D53; Fri, 28 Oct 2005 15:25:41 +0000 (GMT) (envelope-from vd@datamax.bg) Received: from qlovarnika.bg.datamax (qlovarnika.bg.datamax [192.168.10.2]) by jengal.datamax.bg (Postfix) with SMTP id 0A153B854; Fri, 28 Oct 2005 18:25:40 +0300 (EEST) Received: (nullmailer pid 43051 invoked by uid 1002); Fri, 28 Oct 2005 15:25:39 -0000 Date: Fri, 28 Oct 2005 18:25:39 +0300 From: Vasil Dimov To: Vaibhave Agarwal Message-ID: <20051028152539.GA42957@qlovarnika.bg.datamax> References: <20051027233636.GA39380@dmw.hopto.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 6.0-RC1 User-Agent: Mutt/1.5.11 Cc: freebsd , freebsd Subject: Re: how to make the FreeBSD 6.0 run faster X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vd@datamax.bg List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2005 15:25:42 -0000 I would just like to add some numbers: system: freebsd 6.0 i386 job: make buildworld buildkernel When kernel and world are compiled with -g and witness,memguard,invariants are switched on the job takes 120min. With witness,memguard,invariants turned off it takes 66min. 1/3 More speedup when using world and kernel, compiled with -O2 instead of -g, and yet 10% more speedup when removing J option from malloc.conf(3). -- Vasil Dimov From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 28 15:51:16 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF4A916A41F for ; Fri, 28 Oct 2005 15:51:16 +0000 (GMT) (envelope-from apelisse@gmail.com) Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1184643D46 for ; Fri, 28 Oct 2005 15:51:15 +0000 (GMT) (envelope-from apelisse@gmail.com) Received: by nproxy.gmail.com with SMTP id l23so162794nfc for ; Fri, 28 Oct 2005 08:51: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:in-reply-to:mime-version:content-type:references; b=ga69BGlvVCZWeRnY30xx+iQNgh93KGUTLBr5sJORik1n5X2cBzyFlxj+PiH3s7eRaTWK257ZCymjD28N/TKqb96sN/FdE3+6jXDNmpHMvoFCm0p46crAHVL2tdkoWvsfFdAuY+D2LMfM8R8KBvuBjl+rVTzKPQGcuavUWqDggWQ= Received: by 10.48.226.12 with SMTP id y12mr153929nfg; Fri, 28 Oct 2005 08:51:14 -0700 (PDT) Received: by 10.49.5.13 with HTTP; Fri, 28 Oct 2005 08:51:14 -0700 (PDT) Message-ID: <61c746830510280851x4988f40j56586923ee572db2@mail.gmail.com> Date: Fri, 28 Oct 2005 16:51:14 +0100 From: Antoine Pelisse To: freebsd-hackers@freebsd.org In-Reply-To: <61c746830510280849k682cef02ja4c752b0e5642eee@mail.gmail.com> MIME-Version: 1.0 References: <3.0.1.32.20051027051451.00a842c0@pop.redshift.com> <20051027233636.GA39380@dmw.hopto.org> <6.2.3.4.2.20051027181307.04801d70@cobalt.antimatter.net> <61c746830510280849k682cef02ja4c752b0e5642eee@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: compiling the kernel faster 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, 28 Oct 2005 15:51:17 -0000 > > You can set NOCLEAN in your environment. That will save you from > having to rebuild things that didn't change. Major time saver if > you're only working in a couple of files. It's NO_CLEAN actually, and for the kernel building, it's especially NO_KERNELCLEAN Antoine Pelisse -Glenn From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 28 17:56:49 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2693716A41F; Fri, 28 Oct 2005 17:56:49 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7854C43D49; Fri, 28 Oct 2005 17:56:48 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from [10.50.41.234] (Not Verified[10.50.41.234]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Fri, 28 Oct 2005 14:13:17 -0400 From: John Baldwin To: "M. Warner Losh" Date: Fri, 28 Oct 2005 13:54:59 -0400 User-Agent: KMail/1.8.2 References: <435FBA42.1070604@pacbell.net> <436060B2.5050203@pacbell.net> <20051027.093442.65174562.imp@bsdimp.com> In-Reply-To: <20051027.093442.65174562.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510281355.01150.jhb@freebsd.org> Cc: soc-victor@freebsd.org, freebsd-hackers@freebsd.org, dr2867@pacbell.net Subject: Re: devinfo(3) 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: Fri, 28 Oct 2005 17:56:49 -0000 On Thursday 27 October 2005 11:34 am, M. Warner Losh wrote: > In message: <436060B2.5050203@pacbell.net> > > Daniel Rudy writes: > : I analyzed the source code for devinfo(8) and used as an example of how > : to use the devinfo(3) library. So I knew it transversed the device tree > : once, and my code does it twice, first time to locate (is it there?), > : the second time to actually extract the data and use it. > > Maybe you've found a bug in devinfo then... I don't think anybody has > used it like this before. He re-found an old bug that is already, fixed, yes. :) -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 28 20:48:20 2005 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 985E916A41F; Fri, 28 Oct 2005 20:48:20 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail28.syd.optusnet.com.au (mail28.syd.optusnet.com.au [211.29.133.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id E75E043D49; Fri, 28 Oct 2005 20:48:19 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail28.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j9SKm4Zn003819 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 29 Oct 2005 06:48:07 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.10/8.12.10) with ESMTP id j9SKm4Hh053641; Sat, 29 Oct 2005 06:48:04 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost) by cirb503493.alcatel.com.au (8.12.10/8.12.9/Submit) id j9SKm37K053640; Sat, 29 Oct 2005 06:48:03 +1000 (EST) (envelope-from pjeremy) Date: Sat, 29 Oct 2005 06:48:03 +1000 From: Peter Jeremy To: Mikhail Teterin Message-ID: <20051028204803.GW39882@cirb503493.alcatel.com.au> References: <200510280518.j9S5I3oQ025430@blue.virtual-estates.net> <20051028094844.GU39882@cirb503493.alcatel.com.au> <200510281245.28314.mi+mx@aldan.algebra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200510281245.28314.mi+mx@aldan.algebra.com> User-Agent: Mutt/1.4.2.1i X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc Cc: hackers@freebsd.org, hardware@freebsd.org, sos@freebsd.org Subject: Re: Very slow writing to SATA disk 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, 28 Oct 2005 20:48:20 -0000 On Fri, 2005-Oct-28 12:45:27 -0400, Mikhail Teterin wrote: >No, just checked -- the hw.ata.wc is set to 1. Is there anything else to look >at? That exhausts my ideas, sorry. Sören might be able to suggest something. >> >According to smartctl, the drive runs at 56C during the copying. Its >> >idle temperature seems to be 54C. >It sure feels hot to the touch, but nothing is burning, A rule-of-thumb is that you can hold your finger on something for 4 seconds then it is 45°C (or less). >this model's 'Ambient Temperature' spec is 5 to 55C... It's unlikely to affect I/O performance (though it may increase the number of thermal re-calibrations) but it will definitely shorten the drive life. -- Peter Jeremy From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 28 21:35:19 2005 Return-Path: X-Original-To: hackers@FreeBSD.ORG Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D93B16A41F; Fri, 28 Oct 2005 21:35:19 +0000 (GMT) (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 769AF43D46; Fri, 28 Oct 2005 21:35:18 +0000 (GMT) (envelope-from sos@FreeBSD.ORG) Received: from [194.192.25.136] (mac.deepcore.dk [194.192.25.136]) by spider.deepcore.dk (8.13.4/8.13.3) with ESMTP id j9SLY2il023959; Fri, 28 Oct 2005 23:34:02 +0200 (CEST) (envelope-from sos@FreeBSD.ORG) In-Reply-To: <20051028204803.GW39882@cirb503493.alcatel.com.au> References: <200510280518.j9S5I3oQ025430@blue.virtual-estates.net> <20051028094844.GU39882@cirb503493.alcatel.com.au> <200510281245.28314.mi+mx@aldan.algebra.com> <20051028204803.GW39882@cirb503493.alcatel.com.au> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= Date: Fri, 28 Oct 2005 23:35:02 +0200 To: Peter Jeremy X-Mailer: Apple Mail (2.734) X-mail-scanned: by DeepCore Virus & Spam killer v1.12 Cc: Mikhail Teterin , hackers@FreeBSD.ORG, hardware@FreeBSD.ORG Subject: Re: Very slow writing to SATA disk 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, 28 Oct 2005 21:35:19 -0000 On 28/10/2005, at 22:48, Peter Jeremy wrote: > On Fri, 2005-Oct-28 12:45:27 -0400, Mikhail Teterin wrote: > >> No, just checked -- the hw.ata.wc is set to 1. Is there anything =20 >> else to look >> at? > That exhausts my ideas, sorry. S=F6ren might be able to suggest =20 > something. Not really, however I have no experience with Hitachi drives, I =20 havn't trusted that line of drives since their name was IBM Deathstar =20= DTLA series :/ >>>> According to smartctl, the drive runs at 56C during the copying. =20= >>>> Its >>>> idle temperature seems to be 54C. >>>> >> It sure feels hot to the touch, but nothing is burning, > > A rule-of-thumb is that you can hold your finger on something for 4 > seconds then it is 45=B0C (or less). > >> this model's 'Ambient Temperature' spec is 5 to 55C... > > It's unlikely to affect I/O performance (though it may increase the > number of thermal re-calibrations) but it will definitely shorten the > drive life. Indeed, 55C is way to high for 24/7 usage, and it might be that the =20 drive is choking on it and barely is able to compensate.. What does SMART say ? any unusual like high correction rates or =20 anything ? S=F8ren Schmidt sos@FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 28 21:52:34 2005 Return-Path: X-Original-To: hackers@FreeBSD.ORG Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A6C3E16A41F; Fri, 28 Oct 2005 21:52:34 +0000 (GMT) (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 0C8E543D46; Fri, 28 Oct 2005 21:52:33 +0000 (GMT) (envelope-from sos@FreeBSD.ORG) Received: from [194.192.25.136] (mac.deepcore.dk [194.192.25.136]) by spider.deepcore.dk (8.13.4/8.13.3) with ESMTP id j9SLpMHq024144; Fri, 28 Oct 2005 23:51:22 +0200 (CEST) (envelope-from sos@FreeBSD.ORG) In-Reply-To: <200510281745.43138.mi+mx@aldan.algebra.com> References: <200510280518.j9S5I3oQ025430@blue.virtual-estates.net> <20051028204803.GW39882@cirb503493.alcatel.com.au> <200510281745.43138.mi+mx@aldan.algebra.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <2835B7B9-03AA-4EB2-996B-8CEC485071C6@FreeBSD.ORG> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= Date: Fri, 28 Oct 2005 23:52:23 +0200 To: Mikhail Teterin X-Mailer: Apple Mail (2.734) X-mail-scanned: by DeepCore Virus & Spam killer v1.12 Cc: Peter Jeremy , hackers@FreeBSD.ORG, hardware@FreeBSD.ORG Subject: Re: Very slow writing to SATA disk 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, 28 Oct 2005 21:52:34 -0000 On 28/10/2005, at 23:45, Mikhail Teterin wrote: >> Indeed, 55C is way to high for 24/7 usage, and it might be that the >> drive is choking on it and barely is able to compensate. > > The reads are pretty quick... I'd like to be able to spin it down, but > ataidle is broken :-( Ask the maintainer to get it fixed, but be warned experience says it =20 might hose your data... >> What does SMART say ? any unusual like high correction rates or >> anything ? > (SMART data deleted) Well except the excessive temperature nothing out of the ordinary... Now, you say read speed is OK, but write speed isnt, is that on the =20 raw disk device or though the filesystem ? S=F8ren Schmidt sos@FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 28 22:18:07 2005 Return-Path: X-Original-To: hackers@FreeBSD.ORG Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8852416A423; Fri, 28 Oct 2005 22:18:07 +0000 (GMT) (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 DA4F543D49; Fri, 28 Oct 2005 22:18:05 +0000 (GMT) (envelope-from sos@FreeBSD.ORG) Received: from [194.192.25.136] (mac.deepcore.dk [194.192.25.136]) by spider.deepcore.dk (8.13.4/8.13.3) with ESMTP id j9SMGsCw024465; Sat, 29 Oct 2005 00:16:54 +0200 (CEST) (envelope-from sos@FreeBSD.ORG) In-Reply-To: <200510281803.15734.mi+mx@aldan.algebra.com> References: <200510280518.j9S5I3oQ025430@blue.virtual-estates.net> <200510281745.43138.mi+mx@aldan.algebra.com> <2835B7B9-03AA-4EB2-996B-8CEC485071C6@FreeBSD.ORG> <200510281803.15734.mi+mx@aldan.algebra.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= Date: Sat, 29 Oct 2005 00:17:54 +0200 To: Mikhail Teterin X-Mailer: Apple Mail (2.734) X-mail-scanned: by DeepCore Virus & Spam killer v1.12 Cc: Peter Jeremy , hackers@FreeBSD.ORG, hardware@FreeBSD.ORG Subject: Re: Very slow writing to SATA disk 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, 28 Oct 2005 22:18:07 -0000 On 29/10/2005, at 0:03, Mikhail Teterin wrote: >> Ask the maintainer to get it [ataidle -mi] fixed, but be warned =20 >> experience >> says it might hose your data... > The maintainer did not break it. An incompatible change to the API =20 > did :) You > are, probably, in the best position to show us, how the new API =20 > should be > used. Look in smartmontools I provided patches for that, its not rocket =20 science you know... > >> Now, you say read speed is OK, but write speed isnt, is that on the >> raw disk device or though the filesystem ? > > Everething is through the filesystem -- as stated in my original e-=20 > mail in > this thread. There is no other activity, when a single cp reads the =20= > huge file > from a SCSI disk (da1) to the IDE (ad8). > > According to `systat -vm', da1 is barely breaking a sweat, while =20 > ad8 is at > 99-101% throughput at 7Mb/second. > > Soft-updates are on. The filesystem is almost empty. The box has a =20 > single > dual-core Opteron-275 with 2Gb of RAM. > > The SATA controller is your "favorite": > > atapci1: port > 0xac00-0xac07,0xa480-0xa483,0xa400-0xa407,0xa080-0xa083,0xa000-0xa00f =20= > mem 0 > xbe6fbc00-0xbe6fbfff irq 25 at device 5.0 on pci3 OK, then we dont know where the slowdown is yet... You need to find out what the transfer rates are for the RAW disk, ie =20= by doing a dd from /dev/zero to the disk with a a resonable blocksize =20= say 1M to minimize overhead. Also read speed from disk to /dev/null =20 blocksize 1M would be helpfull. S=F8ren Schmidt sos@FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 28 23:00:52 2005 Return-Path: X-Original-To: hackers@FreeBSD.ORG Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 050F116A41F; Fri, 28 Oct 2005 23:00:52 +0000 (GMT) (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 D984E43D46; Fri, 28 Oct 2005 23:00:49 +0000 (GMT) (envelope-from sos@FreeBSD.ORG) Received: from [194.192.25.136] (mac.deepcore.dk [194.192.25.136]) by spider.deepcore.dk (8.13.4/8.13.3) with ESMTP id j9SMxZnn024955; Sat, 29 Oct 2005 00:59:35 +0200 (CEST) (envelope-from sos@FreeBSD.ORG) In-Reply-To: <200510281841.19751.mi+mx@aldan.algebra.com> References: <200510280518.j9S5I3oQ025430@blue.virtual-estates.net> <200510281803.15734.mi+mx@aldan.algebra.com> <200510281841.19751.mi+mx@aldan.algebra.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <6F8F4C0A-1D7C-42FF-9CCB-C582827A5D2B@FreeBSD.ORG> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= Date: Sat, 29 Oct 2005 01:00:36 +0200 To: Mikhail Teterin X-Mailer: Apple Mail (2.734) X-mail-scanned: by DeepCore Virus & Spam killer v1.12 Cc: Peter Jeremy , hackers@FreeBSD.ORG, hardware@FreeBSD.ORG Subject: Re: Very slow writing to SATA disk 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, 28 Oct 2005 23:00:52 -0000 On 29/10/2005, at 0:41, Mikhail Teterin wrote: >> Look in smartmontools I provided patches for that, its not rocket >> science you know... >> > > This attitude -- on top of the API change itself -- is not really =20 > encouraging > for ISVs, you know :-) Sigh, ataidle is a hack and the author had no intention to listen =20 back when, so I dont feel teribly sorry about it you know. Spinning =20 down disks needs to be done at the driver level so ATA knows what =20 state the disk is in etc... > >> You need to find out what the transfer rates are for the RAW disk, ie >> by doing a dd from /dev/zero to the disk with a a resonable blocksize >> say 1M to minimize overhead. Also read speed from disk to /dev/null >> blocksize 1M would be helpfull. >> > > The read test averaged 62603828 bytes/sec over a minute or so. > The write test is only 6931231 bytes/sec -- about 9 times less. > > While dd is running, `systat 1 -vm' reports about 110 ata-=20 > interrupts (irq 25) > per second during the write test, and about 1000 during the read test. Hmm, that does sound as problems with that disk, or maybe disk vs =20 diskcontroller. Any chance you could try the disk on something else ? One other thing, how much mem do you have in there ? more than 4G and =20= bounce buffering might get into the picture ruining the transfer rate... S=F8ren Schmidt sos@FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 28 23:14:14 2005 Return-Path: X-Original-To: hackers@FreeBSD.ORG Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B0FE416A420; Fri, 28 Oct 2005 23:14:14 +0000 (GMT) (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 0305243D46; Fri, 28 Oct 2005 23:14:13 +0000 (GMT) (envelope-from sos@FreeBSD.ORG) Received: from [194.192.25.136] (mac.deepcore.dk [194.192.25.136]) by spider.deepcore.dk (8.13.4/8.13.3) with ESMTP id j9SND2MR025113; Sat, 29 Oct 2005 01:13:02 +0200 (CEST) (envelope-from sos@FreeBSD.ORG) In-Reply-To: <200510281909.55669.mi+mx@aldan.algebra.com> References: <200510280518.j9S5I3oQ025430@blue.virtual-estates.net> <200510281841.19751.mi+mx@aldan.algebra.com> <6F8F4C0A-1D7C-42FF-9CCB-C582827A5D2B@FreeBSD.ORG> <200510281909.55669.mi+mx@aldan.algebra.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <1558937F-50BF-4E8F-8DD0-203E8255CB2A@FreeBSD.ORG> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= Date: Sat, 29 Oct 2005 01:14:03 +0200 To: Mikhail Teterin X-Mailer: Apple Mail (2.734) X-mail-scanned: by DeepCore Virus & Spam killer v1.12 Cc: Peter Jeremy , hackers@FreeBSD.ORG, hardware@FreeBSD.ORG Subject: Re: Very slow writing to SATA disk 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, 28 Oct 2005 23:14:14 -0000 On 29/10/2005, at 1:09, Mikhail Teterin wrote: >> Hmm, that does sound as problems with that disk, or maybe disk vs >> diskcontroller. Any chance you could try the disk on something else ? >> > > I'll try... > >> One other thing, how much mem do you have in there ? more than 4G and >> bounce buffering might get into the picture ruining the transfer =20 >> rate... >> > > 2Gb right now. Does the 4Gb limit apply to amd64 as well? Yes, the SiI3114 is a 32bit device.. S=F8ren Schmidt sos@FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 29 02:59:50 2005 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 36B3F16A41F; Sat, 29 Oct 2005 02:59:50 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9683543D45; Sat, 29 Oct 2005 02:59:48 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id j9T2xcie021753; Fri, 28 Oct 2005 20:59:39 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4362E59A.7040909@samsco.org> Date: Fri, 28 Oct 2005 20:59:38 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= References: <200510280518.j9S5I3oQ025430@blue.virtual-estates.net> <20051028204803.GW39882@cirb503493.alcatel.com.au> <200510281745.43138.mi+mx@aldan.algebra.com> <2835B7B9-03AA-4EB2-996B-8CEC485071C6@FreeBSD.ORG> In-Reply-To: <2835B7B9-03AA-4EB2-996B-8CEC485071C6@FreeBSD.ORG> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: Peter Jeremy , Mikhail Teterin , hackers@freebsd.org, hardware@freebsd.org Subject: Re: Very slow writing to SATA disk 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, 29 Oct 2005 02:59:50 -0000 Søren Schmidt wrote: > > On 28/10/2005, at 23:45, Mikhail Teterin wrote: > >>> Indeed, 55C is way to high for 24/7 usage, and it might be that the >>> drive is choking on it and barely is able to compensate. >> >> >> The reads are pretty quick... I'd like to be able to spin it down, but >> ataidle is broken :-( > > > Ask the maintainer to get it fixed, but be warned experience says it > might hose your data... > >>> What does SMART say ? any unusual like high correction rates or >>> anything ? >> >> > > (SMART data deleted) > > Well except the excessive temperature nothing out of the ordinary... > > Now, you say read speed is OK, but write speed isnt, is that on the raw > disk device or though the filesystem ? > > Søren Schmidt > sos@FreeBSD.org > For what it's worth, I'm seeing slow write speeds on some tests with other (non-ata) controllers. Haven't had time to isolate it just yet. Scott From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 29 06:04:18 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D773116A41F for ; Sat, 29 Oct 2005 06:04:18 +0000 (GMT) (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 702A943D45 for ; Sat, 29 Oct 2005 06:04:18 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j9T61cYe067498; Sat, 29 Oct 2005 00:01:43 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 29 Oct 2005 00:01:42 -0600 (MDT) Message-Id: <20051029.000142.95903921.imp@bsdimp.com> To: rpaulo@fnop.net From: "M. Warner Losh" In-Reply-To: <20051026181403.GF1702@neuron.fnop.net> References: <200510242235.48403.hselasky@c2i.net> <20051026172252.GA23243@netbsd.org> <20051026181403.GF1702@neuron.fnop.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sat, 29 Oct 2005 00:01:47 -0600 (MDT) Cc: freebsd-hackers@freebsd.org, tech-kern@NetBSD.org, wrstuden@NetBSD.org, hselasky@c2i.net Subject: Re: FreeBSD 5/6/7 kernel emulator for NetBSD 2.x 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, 29 Oct 2005 06:04:19 -0000 In message: <20051026181403.GF1702@neuron.fnop.net> Rui Paulo writes: : On 2005.10.26 10:22:52 -0700, Bill Studenmund wrote: : | On Mon, Oct 24, 2005 at 10:35:47PM +0200, Hans Petter Selasky wrote: : | > : | > Main features: : | > : | > - Implements FreeBSD's devfs on NetBSD. : | : | In the past, we (NetBSD folks) have talked about a devfs. One issue that : | has come up (I'll be honest, I've raised it a lot) is a desire to retain : | permission changes across boots, and to tie devices (when possible) to a : | device-specific attribute rather than a probe order. : | : | Does FreeBSD's devfs support locators and persistent information? Are : | there plans to support something like that, if not? : : I remember Linux's devfs having a configure file for that particular : objective. The user would set the permission flags in (I can't recall : if this is the real name) /etc/devfsd.conf and let devfsd do the job. : : You could also use another directory for permissions, like /dev-state, : but personally, I don't like this method. : : http://www.atnf.csiro.au/people/rgooch/linux/docs/devfs.html#persistence FreeBSD also has a file that can be used to control the permissions and ownerships at runtime. The persistance can be there, but isn't there by default like the old nodes in /dev. Warner From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 29 06:29:33 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 75B9416A41F for ; Sat, 29 Oct 2005 06:29:33 +0000 (GMT) (envelope-from dinesh@alphaque.com) Received: from ns2.alphaque.com (ns2.alphaque.com [202.75.47.153]) by mx1.FreeBSD.org (Postfix) with SMTP id D2F6743D48 for ; Sat, 29 Oct 2005 06:29:30 +0000 (GMT) (envelope-from dinesh@alphaque.com) Received: (qmail 15734 invoked by uid 0); 29 Oct 2005 06:29:28 -0000 Received: from lucifer.net-gw.com (HELO prophet.alphaque.com) (202.75.47.153) by lucifer.net-gw.com with SMTP; 29 Oct 2005 06:29:28 -0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by prophet.alphaque.com (8.13.4/8.13.4) with ESMTP id j9SDwgRq000945; Fri, 28 Oct 2005 21:58:42 +0800 (MYT) (envelope-from dinesh@alphaque.com) Message-ID: <43622E92.2070205@alphaque.com> Date: Fri, 28 Oct 2005 21:58:42 +0800 From: Dinesh Nair User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8b) Gecko/20050915 MIME-Version: 1.0 To: Scott Long References: <435EEC56.9080708@samsco.org> <200510261130.45506.jhb@freebsd.org> <435FA6A9.4000600@samsco.org> <200510261324.03790.jhb@freebsd.org> <4360B8EE.4070605@alphaque.com> <4360DD7B.20900@samsco.org> In-Reply-To: <4360DD7B.20900@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: locking in a device driver 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, 29 Oct 2005 06:29:33 -0000 On 10/27/05 22:00 Scott Long said the following: > If you need to protect your pseudodriver from being interrupted by the > real driver then you'll need to use the same spl() as the driver. Note > that you shouldn't be using splhigh() unless you really know what you the driver currently is set to use INTR_TYPE_MISC, which from my understanding can only be masked with splhigh(). using another INTR_TYPE may be possible, so this is something i can explore. however, the device interrupts at a constant 1000Hz, as it's a quad-span E1/T1 line card, and thus it needs to have that interrupt serviced pronto to avoid E1/T1 frame slips. any advice here ? -- Regards, /\_/\ "All dogs go to heaven." dinesh@alphaque.com (0 0) http://www.alphaque.com/ +==========================----oOO--(_)--OOo----==========================+ | for a in past present future; do | | for b in clients employers associates relatives neighbours pets; do | | echo "The opinions here in no way reflect the opinions of my $a $b." | | done; done | +=========================================================================+ From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 29 08:56:46 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D587416A41F for ; Sat, 29 Oct 2005 08:56:46 +0000 (GMT) (envelope-from markir@paradise.net.nz) Received: from linda-2.paradise.net.nz (bm-2a.paradise.net.nz [203.96.152.181]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79E4F43D46 for ; Sat, 29 Oct 2005 08:56:46 +0000 (GMT) (envelope-from markir@paradise.net.nz) Received: from smtp-2.paradise.net.nz (tclsnelbe2-src-nat-1 [203.96.152.177]) by linda-2.paradise.net.nz (Paradise.net.nz) with ESMTP id <0IP400EP966L15@linda-2.paradise.net.nz> for freebsd-hackers@freebsd.org; Sat, 29 Oct 2005 21:56:45 +1300 (NZDT) Received: from [192.168.1.11] (218-101-45-218.paradise.net.nz [218.101.45.218]) by smtp-2.paradise.net.nz (Postfix) with ESMTP id 3FE841460511 for ; Sat, 29 Oct 2005 21:56:45 +1300 (NZDT) Date: Sat, 29 Oct 2005 21:56:40 +1300 From: Mark Kirkwood To: freebsd-hackers@freebsd.org Message-id: <43633948.5030801@paradise.net.nz> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050726) Subject: Display files currently in the buffer cache 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, 29 Oct 2005 08:56:46 -0000 Dear hackers, I'm interested in being able to display some data about the contents of the buffer cache , say file name and page offset (something like IRIX's 'bufview'). Is there any utilities that do this currently? (searched around but didn't see anything in ports). Assuming not, is it feasible to write one to do this? (if so, any pointers appreciated - massive FreeBSD internals newbie here....). Cheers Mark From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 29 11:14:44 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0FE2E16A420 for ; Sat, 29 Oct 2005 11:14:44 +0000 (GMT) (envelope-from bruce@cran.org.uk) Received: from smtp-out3.blueyonder.co.uk (smtp-out3.blueyonder.co.uk [195.188.213.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D34D43D45 for ; Sat, 29 Oct 2005 11:14:42 +0000 (GMT) (envelope-from bruce@cran.org.uk) Received: from photon.meadownet ([82.41.12.253]) by smtp-out3.blueyonder.co.uk with Microsoft SMTPSVC(5.0.2195.6713); Sat, 29 Oct 2005 12:15:32 +0100 Received: from localhost.meadownet ([127.0.0.1] helo=photon.meadownet) by photon.meadownet with esmtp (Exim 4.52 (FreeBSD)) id 1EVoct-000Eqo-Jl for freebsd-hackers@freebsd.org; Sat, 29 Oct 2005 12:11:59 +0100 Received: (from brucec@localhost) by photon.meadownet (8.13.1/8.13.1/Submit) id j9TBBn91057089 for freebsd-hackers@freebsd.org; Sat, 29 Oct 2005 12:11:49 +0100 (BST) (envelope-from brucec) Date: Sat, 29 Oct 2005 12:11:46 +0100 From: Bruce Cran To: freebsd-hackers@freebsd.org Message-ID: <20051029111146.GA57024@photon.meadownet> References: <200510280518.j9S5I3oQ025430@blue.virtual-estates.net> <200510281803.15734.mi+mx@aldan.algebra.com> <200510281841.19751.mi+mx@aldan.algebra.com> <6F8F4C0A-1D7C-42FF-9CCB-C582827A5D2B@FreeBSD.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6F8F4C0A-1D7C-42FF-9CCB-C582827A5D2B@FreeBSD.ORG> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 29 Oct 2005 11:15:32.0927 (UTC) FILETIME=[13FB14F0:01C5DC7A] Subject: Re: Very slow writing to SATA disk 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, 29 Oct 2005 11:14:44 -0000 On Sat, Oct 29, 2005 at 01:00:36AM +0200, S?ren Schmidt wrote: > > On 29/10/2005, at 0:41, Mikhail Teterin wrote: > > >>Look in smartmontools I provided patches for that, its not rocket > >>science you know... > >> > > > >This attitude -- on top of the API change itself -- is not really > >encouraging > >for ISVs, you know :-) > > Sigh, ataidle is a hack and the author had no intention to listen > back when, so I dont feel teribly sorry about it you know. Spinning > down disks needs to be done at the driver level so ATA knows what > state the disk is in etc... I'm the author of ataidle. I know it is a hack, and I agree that power management should be done at the driver level. However, I have released what worked for me in the hope that other people find it useful - but yes, there is always the possibility that data will be lost, since it does bypass the driver. Unfortunately I've been very busy recently and so have until now been unable to look at FreeBSD 6.0 and the new ATA driver. I have however updated ataidle to cope with the new API and it can be downloaded from http://www.cran.org.uk/bruce/software/ataidle-0.9.tar.gz . -- Bruce Cran From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 28 16:45:48 2005 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3FB2816A41F; Fri, 28 Oct 2005 16:45:48 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: from blue.virtual-estates.net (aldan.algebra.com [216.254.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 323BE43D45; Fri, 28 Oct 2005 16:45:46 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: from corbulon.video-collage.com (static-151-204-231-237.bos.east.verizon.net [151.204.231.237]) by blue.virtual-estates.net (8.13.4/8.13.4) with ESMTP id j9SGjgPW074130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Oct 2005 12:45:45 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from mteterin.us.murex.com (195-11.customer.cloud9.net [168.100.195.11]) by corbulon.video-collage.com (8.13.4/8.13.1) with ESMTP id j9SGjaho003308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Oct 2005 12:45:36 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from mteterin.us.murex.com (mteterin@localhost [127.0.0.1]) by mteterin.us.murex.com (8.13.3/8.13.3) with ESMTP id j9SGjUg4015645; Fri, 28 Oct 2005 12:45:30 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from localhost (localhost [[UNIX: localhost]]) by mteterin.us.murex.com (8.13.3/8.13.3/Submit) id j9SGjSwY015644; Fri, 28 Oct 2005 12:45:28 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) X-Authentication-Warning: mteterin.us.murex.com: mteterin set sender to mi+mx@aldan.algebra.com using -f From: Mikhail Teterin Organization: Virtual Estates, Inc. To: Peter Jeremy Date: Fri, 28 Oct 2005 12:45:27 -0400 User-Agent: KMail/1.8.2 References: <200510280518.j9S5I3oQ025430@blue.virtual-estates.net> <20051028094844.GU39882@cirb503493.alcatel.com.au> In-Reply-To: <20051028094844.GU39882@cirb503493.alcatel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200510281245.28314.mi+mx@aldan.algebra.com> X-Virus-Scanned: ClamAV devel-20050525/1149/Thu Oct 27 16:20:09 2005 on corbulon.video-collage.com X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.43 X-Mailman-Approved-At: Sat, 29 Oct 2005 16:37:28 +0000 Cc: hackers@freebsd.org, hardware@freebsd.org, sos@freebsd.org Subject: Re: Very slow writing to SATA disk 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, 28 Oct 2005 16:45:48 -0000 > If this drive doesn't support tagged-queueing, is the write cache > disabled?  I get that sort of performance from a (PATA) disk with > the cache disabled (hw.ata.wc="0" in loader.conf) No, just checked -- the hw.ata.wc is set to 1. Is there anything else to look at? > >According to smartctl, the drive runs at 56C during the copying. Its > >idle temperature seems to be 54C. > I'd double-check that (eg with a finger).  If the drive really is > running at 56°C, it won't last very long. It sure feels hot to the touch, but nothing is burning, of course (freshly poured tee is near 100C and never ignites the paper cup). Do you think, the high temperature explains the poor write performance? The drive still reads at tens of Mb per second... According to http://www.spacecentersystems.com/catalog/product_info.php/products_id/293088 this model's 'Ambient Temperature' spec is 5 to 55C... I'd like to be able to turn the drive off between backups, but sysutils/ataidle is broken on 6.0 (Soren?). Thanks! -mi From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 28 18:11:30 2005 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63EE216A41F for ; Fri, 28 Oct 2005 18:11:30 +0000 (GMT) (envelope-from jinmtb@sbcglobal.net) Received: from smtp112.sbc.mail.mud.yahoo.com (smtp112.sbc.mail.mud.yahoo.com [68.142.198.211]) by mx1.FreeBSD.org (Postfix) with SMTP id 4D4A743D48 for ; Fri, 28 Oct 2005 18:11:29 +0000 (GMT) (envelope-from jinmtb@sbcglobal.net) Received: (qmail 13692 invoked from network); 28 Oct 2005 18:11:28 -0000 Received: from unknown (HELO ?192.168.2.10?) (jinmtb@sbcglobal.net@68.127.176.112 with plain) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 28 Oct 2005 18:11:27 -0000 Message-ID: <43626A15.7040002@sbcglobal.net> Date: Fri, 28 Oct 2005 11:12:37 -0700 From: Jin Guojun User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mikhail Teterin References: <200510280518.j9S5I3oQ025430@blue.virtual-estates.net> <20051028094844.GU39882@cirb503493.alcatel.com.au> <200510281245.28314.mi+mx@aldan.algebra.com> In-Reply-To: <200510281245.28314.mi+mx@aldan.algebra.com> X-Mailman-Approved-At: Sat, 29 Oct 2005 16:37:28 +0000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Peter Jeremy , hackers@freebsd.org, hardware@freebsd.org, sos@freebsd.org Subject: Re: Very slow writing to SATA disk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j_guojun@lbl.gov List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2005 18:11:30 -0000 Mikhail Teterin wrote: >>>idle temperature seems to be 54C. >>> >>> > According to smartctl, the drive runs at 56C during the copying. Its > > > > >>I'd double-check that (eg with a finger). If the drive really is >>running at 56°C, it won't last very long. >> >> > >It sure feels hot to the touch, but nothing is burning, of course (freshly >poured tee is near 100C and never ignites the paper cup). > >Do you think, the high temperature explains the poor write performance? The >drive still reads at tens of Mb per second... According to > >http://www.spacecentersystems.com/catalog/product_info.php/products_id/293088 > >this model's 'Ambient Temperature' spec is 5 to 55C... > > Generally, the temperature is not directly affecting the performance till the mechanical problem occurred due to the temperature. A few types of hard drives are manufactured with higher temperature spec., however, those drives are usually broken in 3-6 months (continuously run). Otherwise, the higher temperature is due to some mechanical problem which may slow down the performance. In your case, it seems to me that your drive temperature is at or above the upper bound that could indicate a mechanical problem. Check to see if the reading speed of this drive is normal, then, this won't be the case for now. But keep in mind, if this drive always operates at this temperature, it will not last long. The better temperature for electronic components is below 39C, and not more than 45C~50C. So, 56C can gradually damage the mechanical as well as the electronic components. -Jin From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 28 21:46:02 2005 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2ECBC16A41F; Fri, 28 Oct 2005 21:46:02 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: from blue.virtual-estates.net (aldan.algebra.com [216.254.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 780A343D45; Fri, 28 Oct 2005 21:46:01 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: from corbulon.video-collage.com (static-151-204-231-237.bos.east.verizon.net [151.204.231.237]) by blue.virtual-estates.net (8.13.4/8.13.4) with ESMTP id j9SLjufa075369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Oct 2005 17:46:00 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from mteterin.us.murex.com (195-11.customer.cloud9.net [168.100.195.11]) by corbulon.video-collage.com (8.13.4/8.13.1) with ESMTP id j9SLjoE1006646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Oct 2005 17:45:51 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from mteterin.us.murex.com (mteterin@localhost [127.0.0.1]) by mteterin.us.murex.com (8.13.3/8.13.3) with ESMTP id j9SLjjNJ022068; Fri, 28 Oct 2005 17:45:45 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from localhost (localhost [[UNIX: localhost]]) by mteterin.us.murex.com (8.13.3/8.13.3/Submit) id j9SLjh70022067; Fri, 28 Oct 2005 17:45:43 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) X-Authentication-Warning: mteterin.us.murex.com: mteterin set sender to mi+mx@aldan.algebra.com using -f From: Mikhail Teterin Organization: Virtual Estates, Inc. To: =?utf-8?q?S=C3=B8ren_Schmidt?= Date: Fri, 28 Oct 2005 17:45:42 -0400 User-Agent: KMail/1.8.2 References: <200510280518.j9S5I3oQ025430@blue.virtual-estates.net> <20051028204803.GW39882@cirb503493.alcatel.com.au> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200510281745.43138.mi+mx@aldan.algebra.com> X-Virus-Scanned: ClamAV devel-20050525/1149/Thu Oct 27 16:20:09 2005 on corbulon.video-collage.com X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.43 X-Mailman-Approved-At: Sat, 29 Oct 2005 16:37:28 +0000 Cc: Peter Jeremy , hackers@freebsd.org, hardware@freebsd.org Subject: Re: Very slow writing to SATA disk 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, 28 Oct 2005 21:46:02 -0000 > Indeed, 55C is way to high for 24/7 usage, and it might be that the   > drive is choking on it and barely is able to compensate.. The reads are pretty quick... I'd like to be able to spin it down, but ataidle is broken :-( > What does SMART say ? any unusual like high correction rates or   > anything ? % atacontrol ad8 Protocol Serial ATA v1.0 Serial ATA II device model HDS725050KLA360 serial number KRVN02ZAG1SV7C firmware revision K2AOA11A cylinders 16383 heads 16 sectors/track 63 lba supported 268435455 sectors lba48 supported 976773168 sectors dma supported overlap not supported Feature Support Enable Value Vendor write cache yes yes read ahead yes yes Native Command Queuing (NCQ) yes - 31/0x1F Tagged Command Queuing (TCQ) no no 31/0x1F SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management yes no 0/0x00 automatic acoustic management yes yes 128/0x80 128/0x80 % smartctl -a /dev/ad8 === START OF INFORMATION SECTION === Device Model: HDS725050KLA360 Serial Number: KRVN02ZAG1SV7C Firmware Version: K2AOA11A User Capacity: 500,107,862,016 bytes Device is: Not in smartctl database [for details use: -P showall] ATA Version is: 7 ATA Standard is: ATA/ATAPI-7 T13 1532D revision 1 Local Time is: Fri Oct 28 17:42:16 2005 EDT SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x82) Offline data collection activity was completed without error. Auto Offline Data Collection: Enabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: (10419) seconds. Offline data collection capabilities: (0x5b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. No Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 1) minutes. Extended self-test routine recommended polling time: ( 174) minutes. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000b 100 100 016 Pre-fail Always - 1 2 Throughput_Performance 0x0004 159 159 050 Old_age Offline - 205 3 Spin_Up_Time 0x0007 110 110 024 Pre-fail Always - 618 (Average 645) 4 Start_Stop_Count 0x0012 100 100 000 Old_age Always - 34 5 Reallocated_Sector_Ct 0x0033 100 100 005 Pre-fail Always - 0 7 Seek_Error_Rate 0x000a 100 100 067 Old_age Always - 0 8 Seek_Time_Performance 0x0004 136 136 020 Old_age Offline - 31 9 Power_On_Hours 0x0012 100 100 000 Old_age Always - 691 10 Spin_Retry_Count 0x0012 100 100 060 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 32 192 Power-Off_Retract_Count 0x0032 100 100 050 Old_age Always - 62 193 Load_Cycle_Count 0x0012 100 100 050 Old_age Always - 62 194 Temperature_Celsius 0x0002 105 105 000 Old_age Always - 52 (Lifetime Min/Max 22/62) 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0 197 Current_Pending_Sector 0x0022 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0008 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x000a 200 253 000 Old_age Always - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Short offline Completed without error 00% 3 - # 2 Short captive Completed without error 00% 2 - Warning! SMART Selective Self-Test Log Structure error: invalid SMART checksum. SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 28 22:03:31 2005 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C125316A41F; Fri, 28 Oct 2005 22:03:31 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: from blue.virtual-estates.net (aldan.algebra.com [216.254.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id F152A43D46; Fri, 28 Oct 2005 22:03:30 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: from corbulon.video-collage.com (static-151-204-231-237.bos.east.verizon.net [151.204.231.237]) by blue.virtual-estates.net (8.13.4/8.13.4) with ESMTP id j9SM3Te6075423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Oct 2005 18:03:30 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from mteterin.us.murex.com (195-11.customer.cloud9.net [168.100.195.11]) by corbulon.video-collage.com (8.13.4/8.13.1) with ESMTP id j9SM3NEP006782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Oct 2005 18:03:24 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from mteterin.us.murex.com (mteterin@localhost [127.0.0.1]) by mteterin.us.murex.com (8.13.3/8.13.3) with ESMTP id j9SM3Ih3022417; Fri, 28 Oct 2005 18:03:18 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from localhost (localhost [[UNIX: localhost]]) by mteterin.us.murex.com (8.13.3/8.13.3/Submit) id j9SM3Fu5022415; Fri, 28 Oct 2005 18:03:15 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) X-Authentication-Warning: mteterin.us.murex.com: mteterin set sender to mi+mx@aldan.algebra.com using -f From: Mikhail Teterin Organization: Virtual Estates, Inc. To: =?iso-8859-1?q?S=F8ren_Schmidt?= Date: Fri, 28 Oct 2005 18:03:15 -0400 User-Agent: KMail/1.8.2 References: <200510280518.j9S5I3oQ025430@blue.virtual-estates.net> <200510281745.43138.mi+mx@aldan.algebra.com> <2835B7B9-03AA-4EB2-996B-8CEC485071C6@FreeBSD.ORG> In-Reply-To: <2835B7B9-03AA-4EB2-996B-8CEC485071C6@FreeBSD.ORG> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200510281803.15734.mi+mx@aldan.algebra.com> X-Virus-Scanned: ClamAV devel-20050525/1149/Thu Oct 27 16:20:09 2005 on corbulon.video-collage.com X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.43 X-Mailman-Approved-At: Sat, 29 Oct 2005 16:37:28 +0000 Cc: Peter Jeremy , hackers@freebsd.org, hardware@freebsd.org Subject: Re: Very slow writing to SATA disk 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, 28 Oct 2005 22:03:31 -0000 > Ask the maintainer to get it [ataidle -mi] fixed, but be warned experience > says it might hose your data... The maintainer did not break it. An incompatible change to the API did :) You are, probably, in the best position to show us, how the new API should be used. > Now, you say read speed is OK, but write speed isnt, is that on the   > raw disk device or though the filesystem ? Everething is through the filesystem -- as stated in my original e-mail in this thread. There is no other activity, when a single cp reads the huge file from a SCSI disk (da1) to the IDE (ad8). According to `systat -vm', da1 is barely breaking a sweat, while ad8 is at 99-101% throughput at 7Mb/second. Soft-updates are on. The filesystem is almost empty. The box has a single dual-core Opteron-275 with 2Gb of RAM. The SATA controller is your "favorite": atapci1: port 0xac00-0xac07,0xa480-0xa483,0xa400-0xa407,0xa080-0xa083,0xa000-0xa00f mem 0 xbe6fbc00-0xbe6fbfff irq 25 at device 5.0 on pci3 -mi From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 28 22:41:36 2005 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 41D6E16A420; Fri, 28 Oct 2005 22:41:36 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: from blue.virtual-estates.net (aldan.algebra.com [216.254.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 736D043D45; Fri, 28 Oct 2005 22:41:35 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: from corbulon.video-collage.com (static-151-204-231-237.bos.east.verizon.net [151.204.231.237]) by blue.virtual-estates.net (8.13.4/8.13.4) with ESMTP id j9SMfX6m075523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Oct 2005 18:41:34 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from mteterin.us.murex.com (195-11.customer.cloud9.net [168.100.195.11]) by corbulon.video-collage.com (8.13.4/8.13.1) with ESMTP id j9SMfRtw007143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Oct 2005 18:41:28 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from mteterin.us.murex.com (mteterin@localhost [127.0.0.1]) by mteterin.us.murex.com (8.13.3/8.13.3) with ESMTP id j9SMfMEW023128; Fri, 28 Oct 2005 18:41:22 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from localhost (localhost [[UNIX: localhost]]) by mteterin.us.murex.com (8.13.3/8.13.3/Submit) id j9SMfJ3s023126; Fri, 28 Oct 2005 18:41:19 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) X-Authentication-Warning: mteterin.us.murex.com: mteterin set sender to mi+mx@aldan.algebra.com using -f From: Mikhail Teterin Organization: Virtual Estates, Inc. To: =?iso-8859-1?q?S=F8ren_Schmidt?= Date: Fri, 28 Oct 2005 18:41:19 -0400 User-Agent: KMail/1.8.2 References: <200510280518.j9S5I3oQ025430@blue.virtual-estates.net> <200510281803.15734.mi+mx@aldan.algebra.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200510281841.19751.mi+mx@aldan.algebra.com> X-Virus-Scanned: ClamAV devel-20050525/1149/Thu Oct 27 16:20:09 2005 on corbulon.video-collage.com X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.43 X-Mailman-Approved-At: Sat, 29 Oct 2005 16:37:28 +0000 Cc: Peter Jeremy , hackers@freebsd.org, hardware@freebsd.org Subject: Re: Very slow writing to SATA disk 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, 28 Oct 2005 22:41:36 -0000 > Look in smartmontools I provided patches for that, its not rocket   > science you know... This attitude -- on top of the API change itself -- is not really encouraging for ISVs, you know :-) > You need to find out what the transfer rates are for the RAW disk, ie   > by doing a dd from /dev/zero to the disk with a a resonable blocksize   > say 1M to minimize overhead. Also read speed from disk to /dev/null   > blocksize 1M would be helpfull. The read test averaged 62603828 bytes/sec over a minute or so. The write test is only 6931231 bytes/sec -- about 9 times less. While dd is running, `systat 1 -vm' reports about 110 ata-interrupts (irq 25) per second during the write test, and about 1000 during the read test. Thanks for your help. -mi From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 28 23:10:15 2005 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6CB7F16A41F; Fri, 28 Oct 2005 23:10:15 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: from blue.virtual-estates.net (aldan.algebra.com [216.254.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6353643D77; Fri, 28 Oct 2005 23:10:11 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: from corbulon.video-collage.com (static-151-204-231-237.bos.east.verizon.net [151.204.231.237]) by blue.virtual-estates.net (8.13.4/8.13.4) with ESMTP id j9SNA9sd075616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Oct 2005 19:10:10 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from mteterin.us.murex.com (195-11.customer.cloud9.net [168.100.195.11]) by corbulon.video-collage.com (8.13.4/8.13.1) with ESMTP id j9SNA3Fd008148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Oct 2005 19:10:03 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from mteterin.us.murex.com (mteterin@localhost [127.0.0.1]) by mteterin.us.murex.com (8.13.3/8.13.3) with ESMTP id j9SN9wH4023645; Fri, 28 Oct 2005 19:09:58 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from localhost (localhost [[UNIX: localhost]]) by mteterin.us.murex.com (8.13.3/8.13.3/Submit) id j9SN9tRA023644; Fri, 28 Oct 2005 19:09:55 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) X-Authentication-Warning: mteterin.us.murex.com: mteterin set sender to mi+mx@aldan.algebra.com using -f From: Mikhail Teterin Organization: Virtual Estates, Inc. To: =?iso-8859-1?q?S=F8ren_Schmidt?= Date: Fri, 28 Oct 2005 19:09:55 -0400 User-Agent: KMail/1.8.2 References: <200510280518.j9S5I3oQ025430@blue.virtual-estates.net> <200510281841.19751.mi+mx@aldan.algebra.com> <6F8F4C0A-1D7C-42FF-9CCB-C582827A5D2B@FreeBSD.ORG> In-Reply-To: <6F8F4C0A-1D7C-42FF-9CCB-C582827A5D2B@FreeBSD.ORG> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200510281909.55669.mi+mx@aldan.algebra.com> X-Virus-Scanned: ClamAV devel-20050525/1149/Thu Oct 27 16:20:09 2005 on corbulon.video-collage.com X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.43 X-Mailman-Approved-At: Sat, 29 Oct 2005 16:37:28 +0000 Cc: Peter Jeremy , hackers@freebsd.org, hardware@freebsd.org Subject: Re: Very slow writing to SATA disk 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, 28 Oct 2005 23:10:15 -0000 > Hmm, that does sound as problems with that disk, or maybe disk vs   > diskcontroller. Any chance you could try the disk on something else ? I'll try... > One other thing, how much mem do you have in there ? more than 4G and   > bounce buffering might get into the picture ruining the transfer rate... 2Gb right now. Does the 4Gb limit apply to amd64 as well? -mi From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 29 11:47:32 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 25A3016A41F for ; Sat, 29 Oct 2005 11:47:32 +0000 (GMT) (envelope-from rpaulo@fnop.net) Received: from pluricanal.net (mail.pluricanal.net [83.144.129.196]) by mx1.FreeBSD.org (Postfix) with SMTP id D60DB43D46 for ; Sat, 29 Oct 2005 11:47:30 +0000 (GMT) (envelope-from rpaulo@fnop.net) Received: (qmail 20781 invoked from network); 29 Oct 2005 12:20:54 -0000 Received: from unknown (HELO pxe-laptop.internal.fnop.net) (83.144.140.45) by mail.pluricanal.net with SMTP; 29 Oct 2005 12:20:54 -0000 Received: by pxe-laptop.internal.fnop.net (Postfix, from userid 1000) id 3A1EC1CDD1; Sat, 29 Oct 2005 11:59:03 +0100 (WEST) Date: Sat, 29 Oct 2005 11:59:03 +0100 From: Rui Paulo To: "M. Warner Losh" Message-ID: <20051029105902.GA741@pxe-laptop.internal.fnop.net> References: <200510242235.48403.hselasky@c2i.net> <20051026172252.GA23243@netbsd.org> <20051026181403.GF1702@neuron.fnop.net> <20051029.000142.95903921.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="u3/rZRmxL6MmkK24" Content-Disposition: inline In-Reply-To: <20051029.000142.95903921.imp@bsdimp.com> User-Agent: Mutt/1.5.11 X-Mailman-Approved-At: Sat, 29 Oct 2005 16:38:08 +0000 Cc: freebsd-hackers@freebsd.org, tech-kern@NetBSD.org, wrstuden@NetBSD.org, hselasky@c2i.net Subject: Re: FreeBSD 5/6/7 kernel emulator for NetBSD 2.x 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, 29 Oct 2005 11:47:32 -0000 --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2005.10.29 00:01:42 -0600, M. Warner Losh wrote: | In message: <20051026181403.GF1702@neuron.fnop.net> | Rui Paulo writes: | : On 2005.10.26 10:22:52 -0700, Bill Studenmund wrote: | : | On Mon, Oct 24, 2005 at 10:35:47PM +0200, Hans Petter Selasky wrote: | : | >=20 | : | > Main features: | : | >=20 | : | > - Implements FreeBSD's devfs on NetBSD. | : |=20 | : | In the past, we (NetBSD folks) have talked about a devfs. One issue t= hat=20 | : | has come up (I'll be honest, I've raised it a lot) is a desire to ret= ain=20 | : | permission changes across boots, and to tie devices (when possible) t= o a=20 | : | device-specific attribute rather than a probe order. | : |=20 | : | Does FreeBSD's devfs support locators and persistent information? Are= =20 | : | there plans to support something like that, if not? | :=20 | : I remember Linux's devfs having a configure file for that particular | : objective. The user would set the permission flags in (I can't recall | : if this is the real name) /etc/devfsd.conf and let devfsd do the job. | :=20 | : You could also use another directory for permissions, like /dev-state, | : but personally, I don't like this method. | :=20 | : http://www.atnf.csiro.au/people/rgooch/linux/docs/devfs.html#persistence |=20 | FreeBSD also has a file that can be used to control the permissions | and ownerships at runtime. The persistance can be there, but isn't | there by default like the old nodes in /dev. The other problem I see here is how devfs works in single user mode where devfsd is not started and no permissions are set. How does FreeBSD solve this problem? -- Rui Paulo --u3/rZRmxL6MmkK24 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (NetBSD) iD8DBQFDY1X2ZPqyxs9FH4QRAh6nAJ9K7/NKmBPwzEaaDwD+DP1knSEK+gCfSaus 0b8RkKTYjzs+lnTKJe/XhRY= =FxPZ -----END PGP SIGNATURE----- --u3/rZRmxL6MmkK24-- From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 29 16:45:44 2005 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D817216A41F; Sat, 29 Oct 2005 16:45:44 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from smtp-vbr10.xs4all.nl (smtp-vbr10.xs4all.nl [194.109.24.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C7F343D45; Sat, 29 Oct 2005 16:45:43 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp-vbr10.xs4all.nl (8.13.3/8.13.3) with ESMTP id j9TGjRdH029526; Sat, 29 Oct 2005 18:45:27 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.13.4/8.13.3) with ESMTP id j9TGjReP008505; Sat, 29 Oct 2005 18:45:27 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.13.4/8.13.1/Submit) id j9TGjRxG008504; Sat, 29 Oct 2005 18:45:27 +0200 (CEST) (envelope-from wb) Date: Sat, 29 Oct 2005 18:45:27 +0200 From: Wilko Bulte To: Mikhail Teterin Message-ID: <20051029164527.GA8473@freebie.xs4all.nl> References: <200510280518.j9S5I3oQ025430@blue.virtual-estates.net> <200510281841.19751.mi+mx@aldan.algebra.com> <6F8F4C0A-1D7C-42FF-9CCB-C582827A5D2B@FreeBSD.ORG> <200510281909.55669.mi+mx@aldan.algebra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200510281909.55669.mi+mx@aldan.algebra.com> X-OS: FreeBSD 6.0-RC1 User-Agent: Mutt/1.5.9i X-Virus-Scanned: by XS4ALL Virus Scanner Cc: Peter Jeremy , hackers@freebsd.org, hardware@freebsd.org, =?iso-8859-1?Q?S=F8ren?= Schmidt Subject: Re: Very slow writing to SATA disk 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, 29 Oct 2005 16:45:45 -0000 On Fri, Oct 28, 2005 at 07:09:55PM -0400, Mikhail Teterin wrote.. > > Hmm, that does sound as problems with that disk, or maybe disk vs   > > diskcontroller. Any chance you could try the disk on something else ? > > I'll try... > > > One other thing, how much mem do you have in there ? more than 4G and   > > bounce buffering might get into the picture ruining the transfer rate... > > 2Gb right now. Does the 4Gb limit apply to amd64 as well? If your PCI card can only drive 32 addressbits you are toast beyond 4GB, in the sense that you need bounce buffers, regardless of the CPU. -- Wilko Bulte wilko@FreeBSD.org