From owner-freebsd-current@FreeBSD.ORG Sun Apr 30 00:08:46 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B8F5C16A402 for ; Sun, 30 Apr 2006 00:08:46 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from creme-brulee.marcuscom.com (creme-brulee.marcuscom.com [24.172.16.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4013A43D45 for ; Sun, 30 Apr 2006 00:08:46 +0000 (GMT) (envelope-from marcus@FreeBSD.org) Received: from shumai.marcuscom.com (shumai.marcuscom.com [192.168.1.4]) by creme-brulee.marcuscom.com (8.13.6/8.13.6) with ESMTP id k3U0ACHE009963; Sat, 29 Apr 2006 20:10:12 -0400 (EDT) (envelope-from marcus@FreeBSD.org) From: Joe Marcus Clarke To: Scott Long In-Reply-To: <4453FB29.3040309@samsco.org> References: <1146346120.16564.12.camel@shumai.marcuscom.com> <4453FB29.3040309@samsco.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-8KAcoAn+HEAAR7LRJKV1" Organization: FreeBSD, Inc. Date: Sat, 29 Apr 2006 20:08:42 -0400 Message-Id: <1146355722.16564.20.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.1 FreeBSD GNOME Team Port Cc: freebsd-current@FreeBSD.org Subject: Re: File descriptor leak in libcam X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Apr 2006 00:08:47 -0000 --=-8KAcoAn+HEAAR7LRJKV1 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2006-04-29 at 17:47 -0600, Scott Long wrote: > Joe Marcus Clarke wrote: > > There is a leak in the cam_lookup_pass() if the ioctl call fails to fin= d > > the passthru device. Basically, the xpt file descriptor will not be > > closed. Can anyone give me permission to commit the following patch? > > Thanks. > >=20 > > http://www.marcuscom.com/downloads/camlib.c.diff > >=20 > > Joe > >=20 >=20 > Looks good to me. Style-wise, I'd have it close the fd before > testing the return of the ioctl, but that's minor. So you'd rather see something like: int rc; ... rc =3D ioctl(fd, CAMGETPASSTHRU, &ccb); close(fd); if (rc =3D=3D -1) { ... Joe --=20 Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome --=-8KAcoAn+HEAAR7LRJKV1 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQBEVAAKb2iPiv4Uz4cRAsOEAJ0RDYhxx/F9Av7Guch+fhukeH0sMQCfQzXX /ukbIuAA4bBiktaZE+66urQ= =iTGW -----END PGP SIGNATURE----- --=-8KAcoAn+HEAAR7LRJKV1-- From owner-freebsd-current@FreeBSD.ORG Sun Apr 30 03:16:22 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5824F16A401 for ; Sun, 30 Apr 2006 03:16:22 +0000 (UTC) (envelope-from leafy7382@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8C7A43D46 for ; Sun, 30 Apr 2006 03:16:21 +0000 (GMT) (envelope-from leafy7382@gmail.com) Received: by nz-out-0102.google.com with SMTP id l1so2167016nzf for ; Sat, 29 Apr 2006 20:16:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ccwy91N1en2KzhJePboZnJntHWTCA5ENYPIMBY8E4EbU2W5Py9/T1yrpoBZf9nbqLPCUhGY03zSAoeNvKn6UPEc65aWCHtU0jo4djg+djpHqY8fdNL8BN7Epr1tsAHMQneld773ZMqMksYKOxs2CrSmsjEvj8hrE8+Bop9lEg+E= Received: by 10.65.155.4 with SMTP id h4mr239331qbo; Sat, 29 Apr 2006 20:16:21 -0700 (PDT) Received: by 10.65.105.17 with HTTP; Sat, 29 Apr 2006 20:16:21 -0700 (PDT) Message-ID: Date: Sun, 30 Apr 2006 11:16:21 +0800 From: "Jiawei Ye" To: "Michael Bushkov" In-Reply-To: <002401c66b0a$44c230e0$01655050@jersey> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <002401c66b0a$44c230e0$01655050@jersey> Cc: freebsd-current@freebsd.org Subject: Re: [HEADS UP] caching daemon imported into the source tree X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Apr 2006 03:16:22 -0000 On 4/29/06, Michael Bushkov wrote: > Caching daemon supports caching of getXXXent() functions' results (cachin= g > of sequences of data) - which can be very helpful - as getpwent() functio= n, > for example, is called during each login operation. > > Caching daemon can greatly increase system performance when using LDAP or > NIS nsswitch sources (especially the login speed). It also helps with > caching huge /etc/services file - not every getservXXX() query now search= es > this whole file. Performance benchmarks results comparisons still have no= t > been made - but they will surely be done. > > I'm currently working further on the caching daemon and nsswitch-related > stuff. Please, try it out and send me your comments and ideas. I'll be > really glad to hear them. > > With best regards, > Michael Bushkov > Hi, I find that enabling cache for passwd breaks Apache's UserDir function, could you please look into that? apache-event-2.2.0_7 Version 2.2 of Apache web server with event MPM. Error shown [Sun Apr 30 11:11:25 2006] [error] [client 192.168.0.101] File does not exist: /usr/local/www/apache22/data/~ Jiawei Ye -- "Without the userland, the kernel is useless." --inspired by The Tao of Programming From owner-freebsd-current@FreeBSD.ORG Sun Apr 30 08:06:19 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 32DD716A400 for ; Sun, 30 Apr 2006 08:06:19 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from yam.park.rambler.ru (yam.park.rambler.ru [81.19.64.116]) by mx1.FreeBSD.org (Postfix) with ESMTP id 878ED43D49 for ; Sun, 30 Apr 2006 08:06:17 +0000 (GMT) (envelope-from is@rambler-co.ru) Received: from is.park.rambler.ru (is.park.rambler.ru [81.19.64.102]) by yam.park.rambler.ru (8.13.3/8.13.3) with ESMTP id k3U86F2h074987 for ; Sun, 30 Apr 2006 12:06:15 +0400 (MSD) (envelope-from is@rambler-co.ru) Date: Sun, 30 Apr 2006 12:06:15 +0400 (MSD) From: Igor Sysoev X-X-Sender: is@is.park.rambler.ru To: freebsd-current@freebsd.org Message-ID: <20060430115932.Y39336@is.park.rambler.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: FreeBSD-SA-06:14.fpu X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Apr 2006 08:06:19 -0000 The last security advisory FreeBSD-SA-06:14.fpu ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-06:14.fpu.asc that fixes very doubtful security bug in AMD CPUs, also adds unnecessary penalty in FPU context switch for all other SSE-enabled CPUs. Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-current@FreeBSD.ORG Sun Apr 30 08:59:50 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from [127.0.0.1] (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id CCC4C16A404; Sun, 30 Apr 2006 08:59:49 +0000 (UTC) (envelope-from davidxu@freebsd.org) Message-ID: <44547C85.7040107@freebsd.org> Date: Sun, 30 Apr 2006 16:59:49 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060302 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Igor Sysoev References: <20060430115932.Y39336@is.park.rambler.ru> In-Reply-To: <20060430115932.Y39336@is.park.rambler.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD-SA-06:14.fpu X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Apr 2006 08:59:50 -0000 Igor Sysoev wrote: > > The last security advisory FreeBSD-SA-06:14.fpu > ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-06:14.fpu.asc > that fixes very doubtful security bug in AMD CPUs, also > adds unnecessary penalty in FPU context switch for all other > SSE-enabled CPUs. > > > Igor Sysoev > http://sysoev.ru/en/ Probably it should only be applied to AMD CPU but not Intel and others, it is easy to check cpu vendor and put a if (bug_fxsave) fpu_clean_state(); in file npx.c. David Xu From owner-freebsd-current@FreeBSD.ORG Sun Apr 30 09:54:23 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3355216A402; Sun, 30 Apr 2006 09:54:23 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FEC643D49; Sun, 30 Apr 2006 09:54:21 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.6/8.13.3) with ESMTP id k3U9sHhx014299 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 30 Apr 2006 11:54:17 +0200 (CEST) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.6/8.13.3/Submit) id k3U9sGkl014298; Sun, 30 Apr 2006 11:54:16 +0200 (CEST) Date: Sun, 30 Apr 2006 11:54:16 +0200 From: Divacky Roman To: current@freebsd.org Message-ID: <20060430095416.GA14226@stud.fit.vutbr.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.54 on 147.229.10.14 Cc: davidxu@freebsd.org Subject: firefox hang with libthr X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Apr 2006 09:54:23 -0000 Hi, after gnome upgrade firefox (1.5) doesnt start when linked with libthr... it seems to be stuck in: 80466 root 4 98 0 93572K 62464K ucond 0:04 0.30% firefox-bin when I link it with pthread it works ok roman ---------------------- www.liberalnistrana.cz From owner-freebsd-current@FreeBSD.ORG Sun Apr 30 10:06:46 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9EC5816A402 for ; Sun, 30 Apr 2006 10:06:46 +0000 (UTC) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id E774043D48 for ; Sun, 30 Apr 2006 10:06:45 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.6/8.13.3) with ESMTP id k3UA6fD2015011 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 30 Apr 2006 12:06:41 +0200 (CEST) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.6/8.13.3/Submit) id k3UA6f5I015010 for current@freebsd.org; Sun, 30 Apr 2006 12:06:41 +0200 (CEST) Date: Sun, 30 Apr 2006 12:06:41 +0200 From: Divacky Roman To: current@freebsd.org Message-ID: <20060430100641.GA14980@stud.fit.vutbr.cz> References: <20060430095416.GA14226@stud.fit.vutbr.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060430095416.GA14226@stud.fit.vutbr.cz> User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.54 on 147.229.10.14 Cc: Subject: Re: firefox hang with libthr X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Apr 2006 10:06:46 -0000 On Sun, Apr 30, 2006 at 11:54:16AM +0200, Divacky Roman wrote: > Hi, > > after gnome upgrade firefox (1.5) doesnt start when linked with libthr... > > it seems to be stuck in: > 80466 root 4 98 0 93572K 62464K ucond 0:04 0.30% firefox-bin > > when I link it with pthread it works ok forgot to say that the system is FreeBSD witten 7.0-CURRENT FreeBSD 7.0-CURRENT #139: Fri Mar 31 15:15:20 CEST 2006 is86 From owner-freebsd-current@FreeBSD.ORG Sun Apr 30 11:24:29 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B5B216A403 for ; Sun, 30 Apr 2006 11:24:29 +0000 (UTC) (envelope-from rosti.bsd@gmail.com) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.174]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9272443D46 for ; Sun, 30 Apr 2006 11:24:28 +0000 (GMT) (envelope-from rosti.bsd@gmail.com) Received: by uproxy.gmail.com with SMTP id m3so1783701ugc for ; Sun, 30 Apr 2006 04:24:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:x-mailer:mime-version:content-type:content-transfer-encoding; b=r25qSXV/1LTJlfV9blm3cwzkcKeN3Xa84KBqcBbvaO2MxJl/PrgSut3xQZ6W28ms3FyEWEPaJ+6wkuC++mNBeQQ5M70QD8i9ZL1HpJxQfzd2ZOncssEoSIWJAyndFdwKFwC1hxzBJS4ckP9w4U8T1iRRhMsnOdKD6up7IShgMJY= Received: by 10.66.255.16 with SMTP id c16mr95157ugi; Sun, 30 Apr 2006 04:24:27 -0700 (PDT) Received: from saturn.lan ( [212.143.154.227]) by mx.gmail.com with ESMTP id j1sm3584361ugf.2006.04.30.04.24.25; Sun, 30 Apr 2006 04:24:27 -0700 (PDT) Date: Sun, 30 Apr 2006 14:24:08 +0300 From: Rostislav Krasny To: David Xu , Igor Sysoev Message-Id: <20060430142408.fcd60069.rosti.bsd@gmail.com> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.17; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD-SA-06:14.fpu X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Apr 2006 11:24:29 -0000 David Xu wrote: > Igor Sysoev wrote: > > > > The last security advisory FreeBSD-SA-06:14.fpu > > ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-06:14.fpu.asc > > that fixes very doubtful security bug in AMD CPUs, also > > adds unnecessary penalty in FPU context switch for all other > > SSE-enabled CPUs. > > Probably it should only be applied to AMD CPU but not Intel and others, > it is easy to check cpu vendor and put a > if (bug_fxsave) > fpu_clean_state(); > > in file npx.c. Other possible solution is making the fpu_clean_state() optional by something like following: #ifdef BUG_FXSAVE #define fpu_clean_state() __fpu_clean_state() #else #define fpu_clean_state() ; #endif ... and including "options BUG_FXSAVE" to GENERIC. From owner-freebsd-current@FreeBSD.ORG Sun Apr 30 09:50:39 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 009C716A400 for ; Sun, 30 Apr 2006 09:50:39 +0000 (UTC) (envelope-from marius.nuennerich@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 06D4443D4C for ; Sun, 30 Apr 2006 09:50:37 +0000 (GMT) (envelope-from marius.nuennerich@gmx.net) Received: (qmail invoked by alias); 30 Apr 2006 09:50:34 -0000 Received: from p50838B96.dip0.t-ipconnect.de (EHLO sol) [80.131.139.150] by mail.gmx.net (mp031) with SMTP; 30 Apr 2006 11:50:34 +0200 X-Authenticated: #5707313 Date: Sun, 30 Apr 2006 11:50:30 +0200 From: Marius Nuennerich To: David Xu Message-ID: <20060430115030.69402983@sol> In-Reply-To: <44547C85.7040107@freebsd.org> References: <20060430115932.Y39336@is.park.rambler.ru> <44547C85.7040107@freebsd.org> X-Mailer: Sylpheed-Claws 2.1.1 (GTK+ 2.8.17; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Mailman-Approved-At: Sun, 30 Apr 2006 11:45:36 +0000 Cc: Igor Sysoev , freebsd-current@freebsd.org Subject: Re: FreeBSD-SA-06:14.fpu X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Apr 2006 09:50:39 -0000 On Sun, 30 Apr 2006 16:59:49 +0800 David Xu wrote: > Igor Sysoev wrote: > > > > The last security advisory FreeBSD-SA-06:14.fpu > > ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-06:14.fpu.asc > > that fixes very doubtful security bug in AMD CPUs, also > > adds unnecessary penalty in FPU context switch for all other > > SSE-enabled CPUs. > > > > > > Igor Sysoev > > http://sysoev.ru/en/ > > Probably it should only be applied to AMD CPU but not Intel and others, > it is easy to check cpu vendor and put a > if (bug_fxsave) > fpu_clean_state(); > > in file npx.c. > > David Xu Shouldn't we use an existing variable which is already in L1 instead of the new dummy_variable? Or isn't this noticable in performance? btw Linux does it this way: > http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.16.y.git;a=commitdiff;h=7466f9e72dac13452d871a3fb72fc7bd9c93c864 regards Marius P.S. I have no idea what variable we could use. From owner-freebsd-current@FreeBSD.ORG Sun Apr 30 12:52:31 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9364416A403 for ; Sun, 30 Apr 2006 12:52:31 +0000 (UTC) (envelope-from grafan@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id E651343D46 for ; Sun, 30 Apr 2006 12:52:30 +0000 (GMT) (envelope-from grafan@gmail.com) Received: by nz-out-0102.google.com with SMTP id i28so2242994nzi for ; Sun, 30 Apr 2006 05:52:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=SfQaKsTRTD9+nnHUYiwwdXzHJoTvTSc9mMDP/0GfDw0YOkXyqtFxRnhc5BrxSr5J6um/L2uPzcVreNiO4mjE5KTbHIevXEeWnYL7xyEVotQ1P+I1TfybcdytNMF/KYAps/v2S3PYFnLxZUJFqTwghtulf6x5F6wU5hV8Pr2EhN8= Received: by 10.36.178.10 with SMTP id a10mr4463406nzf; Sun, 30 Apr 2006 05:52:26 -0700 (PDT) Received: by 10.36.24.17 with HTTP; Sun, 30 Apr 2006 05:52:26 -0700 (PDT) Message-ID: <6eb82e0604300552he3d8010yf2ca81e52b54c4a7@mail.gmail.com> Date: Sun, 30 Apr 2006 08:52:26 -0400 From: "Rong-En Fan" To: "FreeBSD Current" , marcel@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Subject: lpt0 disappear (ppc related) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Apr 2006 12:52:31 -0000 Hi, After upgrading from Apr 11 to Arp 29. I found that my lpt0 disappearing, and ppc0 is no longer attached. A binary search finds out that the recently ppc commit is related. To be more specific, before the ppc commit I2006.04.24.23.00.00), ppc0 and lpt0 both attached: ppc0: using extended I/O port range ppc0: SPP ppc0: port 0x3bc-0x3be irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppc0: [GIANT-LOCKED] After the ppc commit (2006.04.25.00.00.00), they stop to attach: ppc0: parallel port found at 0x3bc ppc0: cannot reserve I/O port range ppc0: failed to probe at port 0x3bc-0x3c3 irq 7 on isa0 The dmesg, devinfo before ppc commit and after are available at: http://www.rafan.org/FreeBSD/ppc/ There is also a make update output shows the difference between Apr 24 23:00 to Apr 25 00:00. Thanks, Rong-En Fan From owner-freebsd-current@FreeBSD.ORG Sun Apr 30 12:59:07 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2955916A405 for ; Sun, 30 Apr 2006 12:59:07 +0000 (UTC) (envelope-from rmgls@wanadoo.fr) Received: from smtp13.wanadoo.fr (smtp13.wanadoo.fr [193.252.22.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id C621043D45 for ; Sun, 30 Apr 2006 12:59:06 +0000 (GMT) (envelope-from rmgls@wanadoo.fr) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf1306.wanadoo.fr (SMTP Server) with ESMTP id 4CF2B7000092 for ; Sun, 30 Apr 2006 14:59:05 +0200 (CEST) Received: from wanadoo.fr (ARouen-252-1-138-189.w86-215.abo.wanadoo.fr [86.215.73.189]) by mwinf1306.wanadoo.fr (SMTP Server) with ESMTP id E7BF47000091 for ; Sun, 30 Apr 2006 14:59:04 +0200 (CEST) X-ME-UUID: 20060430125904949.E7BF47000091@mwinf1306.wanadoo.fr To: freebsd-current@freebsd.org From: rmgls@wanadoo.fr Date: Sun, 30 Apr 2006 14:59:02 +0200 Sender: rmgls@wanadoo.fr Message-Id: <20060430125904.E7BF47000091@mwinf1306.wanadoo.fr> Subject: iwi driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Apr 2006 12:59:07 -0000 hello all, since the last update dated Sat Apr 29, (on current), the iwi driver does not work: cannot change any achannel, and no association! the old version of the driver works. ... ;* Copyright Sam Leffler */ previous: /* $FreeBSD: src/sys/dev/iwi/if_iwi.c,v 1.27 2006/01/29 12:03:03 damien Exp $ */ the nic is seated onboard of a s5 Sony laptop. dmesg: ... firmware_get: failed to load firmware image iwi_bss iwi0: could not load firmware ... firmware_get: failed to load firmware image iwi_bss iwi0: could not load firmware pciconf -lv iwi0@pci6:11:0: class=0x028000 card=0x27538086 chip=0x42208086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/Wireless 2200BG Network Connection' class = network Please can you tell me something to do about this? thanks rmgls rmgls@wanadoo.fr From owner-freebsd-current@FreeBSD.ORG Sun Apr 30 15:05:03 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1CB8416A40E for ; Sun, 30 Apr 2006 15:05:03 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.18.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F04243D49 for ; Sun, 30 Apr 2006 15:05:02 +0000 (GMT) (envelope-from freebsd-listen@fabiankeil.de) Received: (qmail 17007 invoked from network); 30 Apr 2006 15:05:00 -0000 Received: from unknown (HELO localhost) ([pbs]775067@[217.50.135.99]) (envelope-sender ) by smtprelay03.ispgateway.de (qmail-ldap-1.03) with SMTP for ; 30 Apr 2006 15:05:00 -0000 Date: Sun, 30 Apr 2006 17:04:57 +0200 From: Fabian Keil To: rmgls@wanadoo.fr Message-ID: <20060430170457.131da033@localhost> In-Reply-To: <20060430125904.E7BF47000091@mwinf1306.wanadoo.fr> References: <20060430125904.E7BF47000091@mwinf1306.wanadoo.fr> X-Mailer: Sylpheed-Claws 2.0.0 (GTK+ 2.8.17; i386-portbld-freebsd6.0) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2006-08-19.asc Mime-Version: 1.0 Content-Type: multipart/signed; boundary=Sig_lCjVMUTypJl_fd.YIJzDxMP; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: freebsd-current@freebsd.org Subject: Re: iwi driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Apr 2006 15:05:03 -0000 --Sig_lCjVMUTypJl_fd.YIJzDxMP Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable rmgls@wanadoo.fr wrote: > since the last update dated > Sat Apr 29, (on current), > the iwi driver does not work: > cannot change any achannel, and no association! > the old version of the driver works. >=20 > ... > ;* Copyright Sam Leffler */ >=20 > previous: > /* $FreeBSD: src/sys/dev/iwi/if_iwi.c,v 1.27 2006/01/29 12:03:03 damien E= xp $ */ >=20 > the nic is seated onboard of a s5 Sony laptop. > dmesg: > ... > firmware_get: failed to load firmware image iwi_bss > iwi0: could not load firmware >=20 > ... >=20 > firmware_get: failed to load firmware image iwi_bss > iwi0: could not load firmware I'm using iwiNG with FreeBSD 6.1-RC and it has the same problem (with ether as well) if iwi0 is already running and the firmware loaded. Most of the time a few ifconfig iwi0 down/up runs get it working again. Sometimes I have to reload the modules. If all iwi0 settings are done with only one ifconfig call, I don't see any problems. Fabian --=20 http://www.fabiankeil.de/ --Sig_lCjVMUTypJl_fd.YIJzDxMP Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEVNIajV8GA4rMKUQRArreAKC4FEuUBWbZ6DLl6PdhsHL8QMdIHACg3zHg X4BLhFtERivoeUrviNgegIY= =ouSu -----END PGP SIGNATURE----- --Sig_lCjVMUTypJl_fd.YIJzDxMP-- From owner-freebsd-current@FreeBSD.ORG Sun Apr 30 16:45:38 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1378616A401 for ; Sun, 30 Apr 2006 16:45:38 +0000 (UTC) (envelope-from rmgls@wanadoo.fr) Received: from smtp4.wanadoo.fr (smtp4.wanadoo.fr [193.252.22.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id AFC2C43D49 for ; Sun, 30 Apr 2006 16:45:37 +0000 (GMT) (envelope-from rmgls@wanadoo.fr) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf0406.wanadoo.fr (SMTP Server) with ESMTP id A999E1C0027E for ; Sun, 30 Apr 2006 18:45:36 +0200 (CEST) Received: from wanadoo.fr (ARouen-252-1-128-154.w86-208.abo.wanadoo.fr [86.208.91.154]) by mwinf0406.wanadoo.fr (SMTP Server) with ESMTP id 975AF1C00262 for ; Sun, 30 Apr 2006 18:45:36 +0200 (CEST) X-ME-UUID: 20060430164536620.975AF1C00262@mwinf0406.wanadoo.fr From: Raoul MEGELAS To: freebsd-current@freebsd.org In-Reply-To: Date: Sun, 30 Apr 2006 18:45:34 +0200 Sender: rmgls@wanadoo.fr Message-Id: <20060430164536.975AF1C00262@mwinf0406.wanadoo.fr> Subject: Re: iwi driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Apr 2006 16:45:38 -0000 On Sun, Apr 30, 2006 at 05:04:57PM +0200, Fabian Keil wrote: > rmgls@wanadoo.fr wrote: > > > since the last update dated > > Sat Apr 29, (on current), > > the iwi driver does not work: > > cannot change any achannel, and no association! > > the old version of the driver works. > > > > ... > > ;* Copyright Sam Leffler */ > > > > previous: > > /* $FreeBSD: src/sys/dev/iwi/if_iwi.c,v 1.27 2006/01/29 12:03:03 damien Exp $ */ > > > > the nic is seated onboard of a s5 Sony laptop. > > dmesg: > > ... > > firmware_get: failed to load firmware image iwi_bss > > iwi0: could not load firmware > > > > ... > > > > firmware_get: failed to load firmware image iwi_bss > > iwi0: could not load firmware > > I'm using iwiNG with FreeBSD 6.1-RC and it has the same > problem (with ether as well) if iwi0 is already running > and the firmware loaded. > > Most of the time a few ifconfig iwi0 down/up runs get it > working again. Sometimes I have to reload the modules. > > If all iwi0 settings are done with only one ifconfig call, > I don't see any problems. > > Fabian > -- > http://www.fabiankeil.de/ Hi Fabian, thanks for your reply,. But even with numerous down/up, ifconfig on one line, the channel is always 1, and does not associate. Best Regards. raoul rmgls@wanadoo.fr From owner-freebsd-current@FreeBSD.ORG Sun Apr 30 16:53:10 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAB1E16A402 for ; Sun, 30 Apr 2006 16:53:10 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 371CE43D4C for ; Sun, 30 Apr 2006 16:53:09 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.13.4/8.13.3) with ESMTP id k3UGr8Vq065009; Sun, 30 Apr 2006 20:53:08 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Sun, 30 Apr 2006 20:53:08 +0400 (MSD) From: Maxim Konovalov To: Raoul MEGELAS In-Reply-To: <20060430164536.975AF1C00262@mwinf0406.wanadoo.fr> Message-ID: <20060430205123.G64737@mp2.macomnet.net> References: <20060430164536.975AF1C00262@mwinf0406.wanadoo.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-current@freebsd.org Subject: Re: iwi driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Apr 2006 16:53:10 -0000 [...] > thanks for your reply,. > But even with numerous down/up, ifconfig on one line, > the channel is always 1, and does not associate. My lifebook 7010 works OK with iwi(4) and yesterday -current. Make sure you have up-to-date iwi-firmware-kmod port installed. Please show kldstat | grep iwi. -- Maxim Konovalov From owner-freebsd-current@FreeBSD.ORG Sun Apr 30 17:45:17 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7039116A402 for ; Sun, 30 Apr 2006 17:45:17 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 229D743D46 for ; Sun, 30 Apr 2006 17:45:17 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.199] ([10.0.0.199]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id k3UHjGTb060807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 30 Apr 2006 10:45:16 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <4454F7AC.3070904@errno.com> Date: Sun, 30 Apr 2006 10:45:16 -0700 From: Sam Leffler Organization: Errno Consulting User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308) MIME-Version: 1.0 To: rmgls@wanadoo.fr References: <20060430125904.E7BF47000091@mwinf1306.wanadoo.fr> In-Reply-To: <20060430125904.E7BF47000091@mwinf1306.wanadoo.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: iwi driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Apr 2006 17:45:17 -0000 rmgls@wanadoo.fr wrote: > hello all, > > since the last update dated > Sat Apr 29, (on current), > the iwi driver does not work: > cannot change any achannel, and no association! > the old version of the driver works. > > ... > ;* Copyright Sam Leffler */ > > previous: > /* $FreeBSD: src/sys/dev/iwi/if_iwi.c,v 1.27 2006/01/29 12:03:03 damien Exp $ */ > > the nic is seated onboard of a s5 Sony laptop. > dmesg: > ... > firmware_get: failed to load firmware image iwi_bss > iwi0: could not load firmware > > ... > > firmware_get: failed to load firmware image iwi_bss > iwi0: could not load firmware > > pciconf -lv > iwi0@pci6:11:0: class=0x028000 card=0x27538086 chip=0x42208086 rev=0x05 hdr=0x00 > vendor = 'Intel Corporation' > device = 'PRO/Wireless 2200BG Network Connection' > class = network > > Please can you tell me something to do about this? The firmware image file could not be loaded; verify it is present and named properly. The driver in cvs will accept either 2.4 or 3.x rev image formats so if you get the filename right it should just work. Unfortunately there was a period of time where the driver in cvs would only accept rev 3.0 firmware then the names associated with the firmware changed, etc. As a result some people have bogus firmware files on their system. When in doubt you can pre-load the firmware with kldload. Unfortunately firmware(9) doesn't have any debug msgs to show things like firmware images being registered. This would be useful for cases like this. Sam From owner-freebsd-current@FreeBSD.ORG Sun Apr 30 18:17:57 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5260D16A405; Sun, 30 Apr 2006 18:17:57 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id E77BA43D46; Sun, 30 Apr 2006 18:17:56 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.4.250] (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.13.6/8.13.6) with ESMTP id k3UIHuDY000917; Sun, 30 Apr 2006 11:17:56 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <6eb82e0604300552he3d8010yf2ca81e52b54c4a7@mail.gmail.com> References: <6eb82e0604300552he3d8010yf2ca81e52b54c4a7@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <72F3EFB8-E710-4288-8719-89B6BE7B4D2C@xcllnt.net> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Sun, 30 Apr 2006 11:17:56 -0700 To: Rong-En Fan X-Mailer: Apple Mail (2.749.3) Cc: FreeBSD Current , marcel@freebsd.org Subject: Re: lpt0 disappear (ppc related) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Apr 2006 18:17:57 -0000 On Apr 30, 2006, at 5:52 AM, Rong-En Fan wrote: > Hi, > > After upgrading from Apr 11 to Arp 29. I found that my lpt0 > disappearing, > and ppc0 is no longer attached. You need to configure your kernel with acpi. The ppc(4) driver ends up without acpi attachment because of that. This causes it to try the isa attachment, but that fails. FYI, -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Sun Apr 30 19:31:58 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 61D8A16A404 for ; Sun, 30 Apr 2006 19:31:58 +0000 (UTC) (envelope-from grafan@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D5E143D46 for ; Sun, 30 Apr 2006 19:31:57 +0000 (GMT) (envelope-from grafan@gmail.com) Received: by nz-out-0102.google.com with SMTP id i28so2284353nzi for ; Sun, 30 Apr 2006 12:31:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=CGuCRGwO1Mw2zcoysFVP0UKxliy49eXB8GU8ILuNdqLI2IgXK6oRjZJPa7MKmecy8onUGIT4YTFPsO7E6wOAoWIPk3UHKYWqYod55RRu/+kVLFgJa1al1mhT/Ys34A6LlDnNWJFe9YsDGcOMu/4Tas1vWLos6JJgMFedsaINWdk= Received: by 10.37.2.23 with SMTP id e23mr7591384nzi; Sun, 30 Apr 2006 12:31:56 -0700 (PDT) Received: by 10.36.24.17 with HTTP; Sun, 30 Apr 2006 12:31:56 -0700 (PDT) Message-ID: <6eb82e0604301231g568cc12ah3b2d4f7ae5377e69@mail.gmail.com> Date: Sun, 30 Apr 2006 15:31:56 -0400 From: "Rong-En Fan" To: "Marcel Moolenaar" In-Reply-To: <72F3EFB8-E710-4288-8719-89B6BE7B4D2C@xcllnt.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <6eb82e0604300552he3d8010yf2ca81e52b54c4a7@mail.gmail.com> <72F3EFB8-E710-4288-8719-89B6BE7B4D2C@xcllnt.net> Cc: FreeBSD Current , marcel@freebsd.org Subject: Re: lpt0 disappear (ppc related) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Apr 2006 19:31:58 -0000 On 4/30/06, Marcel Moolenaar wrote: > > On Apr 30, 2006, at 5:52 AM, Rong-En Fan wrote: > > > Hi, > > > > After upgrading from Apr 11 to Arp 29. I found that my lpt0 > > disappearing, > > and ppc0 is no longer attached. > > You need to configure your kernel with acpi. The ppc(4) driver ends > up without acpi attachment because of that. This causes it to try > the isa attachment, but that fails. I have acpi.ko loaded. Before the change, ppc0 was found on acpi0 (see my dmesg). kldstat shows: $ kldstat Id Refs Address Size Name 1 25 0xc0400000 37be54 kernel 2 1 0xc077c000 11654 if_ath.ko 3 2 0xc078e000 4474 ath_rate.ko 4 3 0xc0793000 3016c ath_hal.ko 5 1 0xc07c4000 9a80 if_fxp.ko 6 2 0xc07ce000 1b8a8 miibus.ko 7 1 0xc07ea000 566c snd_ich.ko 8 2 0xc07f0000 26ca8 sound.ko 9 1 0xc0817000 5638 acpi_video.ko 10 3 0xc081d000 652a8 acpi.ko 11 1 0xc0883000 504c acpi_ibm.ko 12 1 0xc0889000 9f90 cpufreq.ko 13 1 0xc35a4000 6000 linprocfs.ko 14 2 0xc35e4000 1b000 linux.ko 15 1 0xc36be000 2000 rtc.ko Regards, Rong-En Fan From owner-freebsd-current@FreeBSD.ORG Sun Apr 30 22:20:54 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 624DE16A403 for ; Sun, 30 Apr 2006 22:20:54 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id C058B43D46 for ; Sun, 30 Apr 2006 22:20:53 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.185.79] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1FaKHb1xB7-0000eb; Mon, 01 May 2006 00:20:52 +0200 From: Max Laier Organization: FreeBSD To: freebsd-current@freebsd.org Date: Mon, 1 May 2006 00:20:42 +0200 User-Agent: KMail/1.9.1 References: <20060430125904.E7BF47000091@mwinf1306.wanadoo.fr> <4454F7AC.3070904@errno.com> In-Reply-To: <4454F7AC.3070904@errno.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart8229981.CS7TTfcPKH"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200605010020.50468.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: rmgls@wanadoo.fr Subject: Re: iwi driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Apr 2006 22:20:54 -0000 --nextPart8229981.CS7TTfcPKH Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 30 April 2006 19:45, Sam Leffler wrote: > rmgls@wanadoo.fr wrote: > > hello all, > > > > since the last update dated > > Sat Apr 29, (on current), > > the iwi driver does not work: > > cannot change any achannel, and no association! > > the old version of the driver works. > > > > ... > > ;* Copyright Sam Leffler */ > > > > previous: > > /* $FreeBSD: src/sys/dev/iwi/if_iwi.c,v 1.27 2006/01/29 12:03:03 damien > > Exp $ */ > > > > the nic is seated onboard of a s5 Sony laptop. > > dmesg: > > ... > > firmware_get: failed to load firmware image iwi_bss > > iwi0: could not load firmware > > > > ... > > > > firmware_get: failed to load firmware image iwi_bss > > iwi0: could not load firmware > > > > pciconf -lv > > iwi0@pci6:11:0: class=3D0x028000 card=3D0x27538086 chip=3D0x42208086 re= v=3D0x05 > > hdr=3D0x00 vendor =3D 'Intel Corporation' > > device =3D 'PRO/Wireless 2200BG Network Connection' > > class =3D network > > > > Please can you tell me something to do about this? > > The firmware image file could not be loaded; verify it is present and > named properly. The driver in cvs will accept either 2.4 or 3.x rev > image formats so if you get the filename right it should just work. > Unfortunately there was a period of time where the driver in cvs would > only accept rev 3.0 firmware then the names associated with the firmware > changed, etc. As a result some people have bogus firmware files on > their system. > > When in doubt you can pre-load the firmware with kldload. Unfortunately > firmware(9) doesn't have any debug msgs to show things like firmware > images being registered. This would be useful for cases like this. Here is a small patch to build a "debug.firmware" sysctl. Should give:=20 "iwi_bss/300/191142" for the latest firmware from net/iwi-firmware-kmod Any comments on the patch? Will commit shortly otherwise. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart8229981.CS7TTfcPKH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQBEVThCXyyEoT62BG0RAlN9AJ44jkMSaooH0yvhP3Leo8eSp0AUDgCdFzpS Sb5vOrn6QCPNbcbvAtASFuI= =uceu -----END PGP SIGNATURE----- --nextPart8229981.CS7TTfcPKH-- From owner-freebsd-current@FreeBSD.ORG Sun Apr 30 22:36:59 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B69916A401 for ; Sun, 30 Apr 2006 22:36:59 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id 078D643D46 for ; Sun, 30 Apr 2006 22:36:58 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.185.79] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1FaKXB0vHu-0008Q8; Mon, 01 May 2006 00:36:57 +0200 From: Max Laier Organization: FreeBSD To: freebsd-current@freebsd.org Date: Mon, 1 May 2006 00:36:49 +0200 User-Agent: KMail/1.9.1 References: <20060430125904.E7BF47000091@mwinf1306.wanadoo.fr> <4454F7AC.3070904@errno.com> <200605010020.50468.max@love2party.net> In-Reply-To: <200605010020.50468.max@love2party.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart7401376.FPI4Ip6rWb"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200605010036.56447.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Subject: Re: iwi driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Apr 2006 22:36:59 -0000 --nextPart7401376.FPI4Ip6rWb Content-Type: multipart/mixed; boundary="Boundary-01=_CwTVErmKjF50z1V" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_CwTVErmKjF50z1V Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 01 May 2006 00:20, Max Laier wrote: > Here is a small patch to build a "debug.firmware" sysctl. Should give: > "iwi_bss/300/191142" for the latest firmware from net/iwi-firmware-kmod > > Any comments on the patch? Will commit shortly otherwise. =46orgot the patch. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --Boundary-01=_CwTVErmKjF50z1V Content-Type: text/x-diff; charset="iso-8859-6"; name="firmware_debug.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="firmware_debug.diff" Index: subr_firmware.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/store/mlaier/fcvs/src/sys/kern/subr_firmware.c,v retrieving revision 1.1 diff -u -r1.1 subr_firmware.c =2D-- subr_firmware.c 29 Jan 2006 02:52:41 -0000 1.1 +++ subr_firmware.c 30 Apr 2006 22:11:05 -0000 @@ -32,6 +32,8 @@ #include #include #include +#include +#include #include #include #include @@ -41,6 +43,8 @@ #include #include =20 +static int sysctl_debug_firmware(SYSCTL_HANDLER_ARGS); + #define FIRMWARE_MAX 30 static char *name_unload =3D "UNLOADING"; static struct firmware firmware_table[FIRMWARE_MAX]; @@ -48,6 +52,49 @@ struct mtx firmware_mtx; MTX_SYSINIT(firmware, &firmware_mtx, "firmware table", MTX_DEF); =20 +static int +sysctl_debug_firmware(SYSCTL_HANDLER_ARGS) +{ + struct firmware *fp; + struct sbuf sb; + int error, i, count =3D 0; + + for (i =3D 0; i < FIRMWARE_MAX; i++) { + fp =3D &firmware_table[i]; + if (fp->name !=3D NULL) + count++; + } + + if (count =3D=3D 0) + return (sysctl_handle_string(oidp, "NONE", 5, req)); + + sbuf_new(&sb, NULL, count * 32 + 2, SBUF_FIXEDLEN); + + sbuf_printf(&sb, "\n"); + + mtx_lock(&firmware_mtx); + for (i =3D 0; i < FIRMWARE_MAX; i++) { + fp =3D &firmware_table[i]; + if (fp->name !=3D NULL) { + if (count-- <=3D 0) + sbuf_printf(&sb, "...\n"); + else + sbuf_printf(&sb, "\t%16s/%u/%zi\n", fp->name, + fp->version, fp->datasize); + } + } + mtx_unlock(&firmware_mtx); + + sbuf_trim(&sb); + sbuf_finish(&sb); + error =3D sysctl_handle_string(oidp, sbuf_data(&sb), sbuf_len(&sb), req); + sbuf_delete(&sb); + + return (error); +} +SYSCTL_OID(_debug, OID_AUTO, firmware, CTLTYPE_STRING|CTLFLAG_RD, NULL, 0, + sysctl_debug_firmware, "A", "Loaded firmware images"); + /* * Register a firmware image with the specified name. The * image name must not already be registered. If this is a --Boundary-01=_CwTVErmKjF50z1V-- --nextPart7401376.FPI4Ip6rWb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQBEVTwIXyyEoT62BG0RAjFRAJ9ndok8R/2UD65y9hTVLZtatnsvIwCeIqbr cyIADGpdpJg/KvBQDbH7FyM= =HUlM -----END PGP SIGNATURE----- --nextPart7401376.FPI4Ip6rWb-- From owner-freebsd-current@FreeBSD.ORG Mon May 1 03:51:43 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E935016A400 for ; Mon, 1 May 2006 03:51:43 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78E7E43D48 for ; Mon, 1 May 2006 03:51:42 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.4.250] (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.13.6/8.13.6) with ESMTP id k413pdB1003746; Sun, 30 Apr 2006 20:51:41 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <6eb82e0604301231g568cc12ah3b2d4f7ae5377e69@mail.gmail.com> References: <6eb82e0604300552he3d8010yf2ca81e52b54c4a7@mail.gmail.com> <72F3EFB8-E710-4288-8719-89B6BE7B4D2C@xcllnt.net> <6eb82e0604301231g568cc12ah3b2d4f7ae5377e69@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Sun, 30 Apr 2006 20:51:39 -0700 To: Rong-En Fan X-Mailer: Apple Mail (2.749.3) Cc: FreeBSD Current Subject: Re: lpt0 disappear (ppc related) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2006 03:51:44 -0000 On Apr 30, 2006, at 12:31 PM, Rong-En Fan wrote: > On 4/30/06, Marcel Moolenaar wrote: >> >> On Apr 30, 2006, at 5:52 AM, Rong-En Fan wrote: >> >> > Hi, >> > >> > After upgrading from Apr 11 to Arp 29. I found that my lpt0 >> > disappearing, >> > and ppc0 is no longer attached. >> >> You need to configure your kernel with acpi. The ppc(4) driver ends >> up without acpi attachment because of that. This causes it to try >> the isa attachment, but that fails. > > I have acpi.ko loaded. Which means you don't have device acpi configured into the kernel. > Before the change, ppc0 was found on > acpi0 (see my dmesg). That's because you have device isa configured into the kernel and the acpi attachment was coupled to device isa. I uncoupled it with the commit, because device acpi needs to be able to exist without there being a device isa. So, the acpi attachment for ppc(4) exists only when device acpi is configured in the kernel. Alternatively, someone needs to make a module for ppc(4). -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Mon May 1 04:10:42 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 924BD16A401 for ; Mon, 1 May 2006 04:10:42 +0000 (UTC) (envelope-from grafan@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05B3343D48 for ; Mon, 1 May 2006 04:10:41 +0000 (GMT) (envelope-from grafan@gmail.com) Received: by nz-out-0102.google.com with SMTP id x3so2800969nzd for ; Sun, 30 Apr 2006 21:10:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZeaO35+WLK82PiqsAErRXmcZV4toIoNDdPBfR+6MQbDWbKFLUXht4tQeggM7BjygCh1XETS9YxE6o2mriorNvg36S+3jXYADZfgpulYsFjws0UY+3cMEBgpGMEBF9G6BRg2mFAWsiSTZ9QJBLv3t9i7vZuZmE03HaxyJg7fJTn8= Received: by 10.36.158.17 with SMTP id g17mr1799577nze; Sun, 30 Apr 2006 21:10:41 -0700 (PDT) Received: by 10.36.24.17 with HTTP; Sun, 30 Apr 2006 21:10:41 -0700 (PDT) Message-ID: <6eb82e0604302110j7bca56eftce23feb306111823@mail.gmail.com> Date: Mon, 1 May 2006 00:10:41 -0400 From: "Rong-En Fan" To: "Marcel Moolenaar" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <6eb82e0604300552he3d8010yf2ca81e52b54c4a7@mail.gmail.com> <72F3EFB8-E710-4288-8719-89B6BE7B4D2C@xcllnt.net> <6eb82e0604301231g568cc12ah3b2d4f7ae5377e69@mail.gmail.com> Cc: FreeBSD Current Subject: Re: lpt0 disappear (ppc related) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2006 04:10:42 -0000 On 4/30/06, Marcel Moolenaar wrote: > On Apr 30, 2006, at 12:31 PM, Rong-En Fan wrote: > > On 4/30/06, Marcel Moolenaar wrote: > >> On Apr 30, 2006, at 5:52 AM, Rong-En Fan wrote: > >> > >> > Hi, > >> > > >> > After upgrading from Apr 11 to Arp 29. I found that my lpt0 > >> > disappearing, > >> > and ppc0 is no longer attached. > >> > >> You need to configure your kernel with acpi. The ppc(4) driver ends > >> up without acpi attachment because of that. This causes it to try > >> the isa attachment, but that fails. > > > > I have acpi.ko loaded. > > Which means you don't have device acpi configured into the kernel. > > > Before the change, ppc0 was found on > > acpi0 (see my dmesg). > > That's because you have device isa configured into the kernel and > the acpi attachment was coupled to device isa. I uncoupled it with > the commit, because device acpi needs to be able to exist without > there being a device isa. So, the acpi attachment for ppc(4) exists > only when device acpi is configured in the kernel. > Alternatively, someone needs to make a module for ppc(4). OK, I see. Thanks for the explnation. As for building acpi into kernel, i386/conf/NOTES says: # Note that building ACPI into the kernel is deprecated; the module is # normally loaded automatically by the loader. I thought that was deprecated? Regards, Rong-En Fan From owner-freebsd-current@FreeBSD.ORG Mon May 1 04:20:52 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 962F916A40A for ; Mon, 1 May 2006 04:20:52 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 531C143D45 for ; Mon, 1 May 2006 04:20:51 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.4.250] (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.13.6/8.13.6) with ESMTP id k414KoCg003888; Sun, 30 Apr 2006 21:20:51 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <6eb82e0604302110j7bca56eftce23feb306111823@mail.gmail.com> References: <6eb82e0604300552he3d8010yf2ca81e52b54c4a7@mail.gmail.com> <72F3EFB8-E710-4288-8719-89B6BE7B4D2C@xcllnt.net> <6eb82e0604301231g568cc12ah3b2d4f7ae5377e69@mail.gmail.com> <6eb82e0604302110j7bca56eftce23feb306111823@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Sun, 30 Apr 2006 21:20:51 -0700 To: Rong-En Fan X-Mailer: Apple Mail (2.749.3) Cc: FreeBSD Current Subject: Re: lpt0 disappear (ppc related) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2006 04:20:52 -0000 > As for building acpi into kernel, i386/conf/NOTES says: > > # Note that building ACPI into the kernel is deprecated; the module is > # normally loaded automatically by the loader. > > I thought that was deprecated? No, it isn't really. The use of modules is not a requirement. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Mon May 1 04:46:13 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 02C2416A404 for ; Mon, 1 May 2006 04:46:13 +0000 (UTC) (envelope-from rmgls@wanadoo.fr) Received: from smtp14.wanadoo.fr (smtp14.wanadoo.fr [193.252.23.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id 529F543D45 for ; Mon, 1 May 2006 04:46:12 +0000 (GMT) (envelope-from rmgls@wanadoo.fr) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf1401.wanadoo.fr (SMTP Server) with ESMTP id E8C20700008B for ; Mon, 1 May 2006 06:46:10 +0200 (CEST) Received: from wanadoo.fr (ARouen-252-1-128-154.w86-208.abo.wanadoo.fr [86.208.91.154]) by mwinf1401.wanadoo.fr (SMTP Server) with ESMTP id D404B700008A for ; Mon, 1 May 2006 06:46:10 +0200 (CEST) X-ME-UUID: 20060501044610868.D404B700008A@mwinf1401.wanadoo.fr To: freebsd-current@freebsd.org From: rmgls@wanadoo.dr Date: Mon, 01 May 2006 06:46:08 +0200 Sender: rmgls@wanadoo.fr Message-Id: <20060501044610.D404B700008A@mwinf1401.wanadoo.fr> Subject: re: iwi driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2006 04:46:13 -0000 On Monday 01 May 2006 00:20, Max Laier wrote: > Here is a small patch to build a "debug.firmware" sysctl. Should give: > "iwi_bss/300/191142" for the latest firmware from net/iwi-firmware-kmod > > Any comments on the patch? Will commit shortly otherwise. ... hello all, many thanks to all who helped. the problem is solved and the driver works perfectly now. I will test the patch and report soon. best regards Raoul rmgls@freebsd.org ===================================== Index: subr_firmware.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/store/mlaier/fcvs/src/sys/kern/subr_firmware.c,v retrieving revision 1.1 diff -u -r1.1 subr_firmware.c =2D-- subr_firmware.c 29 Jan 2006 02:52:41 -0000 1.1 +++ subr_firmware.c 30 Apr 2006 22:11:05 -0000 @@ -32,6 +32,8 @@ #include #include #include +#include +#include #include #include #include @@ -41,6 +43,8 @@ #include #include =20 +static int sysctl_debug_firmware(SYSCTL_HANDLER_ARGS); + #define FIRMWARE_MAX 30 static char *name_unload =3D "UNLOADING"; static struct firmware firmware_table[FIRMWARE_MAX]; @@ -48,6 +52,49 @@ struct mtx firmware_mtx; MTX_SYSINIT(firmware, &firmware_mtx, "firmware table", MTX_DEF); =20 +static int +sysctl_debug_firmware(SYSCTL_HANDLER_ARGS) +{ + struct firmware *fp; + struct sbuf sb; + int error, i, count =3D 0; + + for (i =3D 0; i < FIRMWARE_MAX; i++) { + fp =3D &firmware_table[i]; + if (fp->name !=3D NULL) + count++; + } + + if (count =3D=3D 0) + return (sysctl_handle_string(oidp, "NONE", 5, req)); + + sbuf_new(&sb, NULL, count * 32 + 2, SBUF_FIXEDLEN); + + sbuf_printf(&sb, "\n"); + + mtx_lock(&firmware_mtx); + for (i =3D 0; i < FIRMWARE_MAX; i++) { + fp =3D &firmware_table[i]; + if (fp->name !=3D NULL) { + if (count-- <=3D 0) + sbuf_printf(&sb, "...\n"); + else + sbuf_printf(&sb, "\t%16s/%u/%zi\n", fp->name, + fp->version, fp->datasize); + } + } + mtx_unlock(&firmware_mtx); + + sbuf_trim(&sb); + sbuf_finish(&sb); + error =3D sysctl_handle_string(oidp, sbuf_data(&sb), sbuf_len(&sb), req); + sbuf_delete(&sb); + + return (error); +} +SYSCTL_OID(_debug, OID_AUTO, firmware, CTLTYPE_STRING|CTLFLAG_RD, NULL, 0, + sysctl_debug_firmware, "A", "Loaded firmware images"); + /* * Register a firmware image with the specified name. The * image name must not already be registered. If this is a From owner-freebsd-current@FreeBSD.ORG Mon May 1 04:51:56 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C8B3616A400 for ; Mon, 1 May 2006 04:51:56 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26B3B43D48 for ; Mon, 1 May 2006 04:51:55 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.21]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id k414po8O061200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 May 2006 14:21:50 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Mon, 1 May 2006 14:21:48 +0930 User-Agent: KMail/1.9.1 References: <6eb82e0604300552he3d8010yf2ca81e52b54c4a7@mail.gmail.com> <6eb82e0604302110j7bca56eftce23feb306111823@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4038429.TdPLxQ7dff"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200605011421.49909.doconnor@gsoft.com.au> X-Spam-Score: -1.36 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.56 on 203.31.81.10 Cc: Rong-En Fan , Marcel Moolenaar Subject: Re: lpt0 disappear (ppc related) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2006 04:51:56 -0000 --nextPart4038429.TdPLxQ7dff Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 01 May 2006 13:50, Marcel Moolenaar wrote: > > As for building acpi into kernel, i386/conf/NOTES says: > > > > # Note that building ACPI into the kernel is deprecated; the module is > > # normally loaded automatically by the loader. > > > > I thought that was deprecated? > > No, it isn't really. The use of modules is not a requirement. However you wouldn't expect that using it as a module would result in reduc= ed=20 functionality. (The same as how you wouldn't expect compiling something int= o=20 your kernel would result in reduced functionality) =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart4038429.TdPLxQ7dff Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQBEVZPl5ZPcIHs/zowRAoTYAJ9PFn9Q1TwoX0ZKjACVPXnsh/tlkwCeMXAG 1V6w7jjFN/DgvgO63TyZlw4= =OuDl -----END PGP SIGNATURE----- --nextPart4038429.TdPLxQ7dff-- From owner-freebsd-current@FreeBSD.ORG Mon May 1 05:13:14 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E36E16C085 for ; Mon, 1 May 2006 05:12:46 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from hexahedron.daemonology.net (s64-180-110-239.bc.hsia.telus.net [64.180.110.239]) by mx1.FreeBSD.org (Postfix) with SMTP id 47DF143D45 for ; Mon, 1 May 2006 05:12:38 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: (qmail 24816 invoked from network); 1 May 2006 05:12:34 -0000 Received: from unknown (HELO ?127.0.0.1?) (127.0.0.1) by localhost with SMTP; 1 May 2006 05:12:34 -0000 Message-ID: <44554601.5090105@freebsd.org> Date: Sun, 30 Apr 2006 16:19:29 -0700 From: Colin Percival User-Agent: Thunderbird 1.5 (X11/20060416) MIME-Version: 1.0 To: Rostislav Krasny References: <20060430142408.fcd60069.rosti.bsd@gmail.com> In-Reply-To: <20060430142408.fcd60069.rosti.bsd@gmail.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Igor Sysoev , David Xu , freebsd-current@freebsd.org Subject: Re: FreeBSD-SA-06:14.fpu X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2006 05:13:14 -0000 > David Xu wrote: >> Probably it should only be applied to AMD CPU but not Intel and others, >> it is easy to check cpu vendor and put a >> if (bug_fxsave) >> fpu_clean_state(); >> in file npx.c. The problem with doing something like this is that the branch will almost never be in the processor's branch prediction tables, so you will get a branch mis-prediction on the unaffected processors -- which is likely to be more expensive than simply running the state cleaning code. Rostislav Krasny wrote: > Other possible solution is making the fpu_clean_state() optional by > something like following: > > #ifdef BUG_FXSAVE > #define fpu_clean_state() __fpu_clean_state() > #else > #define fpu_clean_state() ; > #endif > > ... and including "options BUG_FXSAVE" to GENERIC. Yes, this is probably the right solution. My priority was to fix the bug; optimizing performance comes second. Colin Percival From owner-freebsd-current@FreeBSD.ORG Mon May 1 06:35:15 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D499916A402 for ; Mon, 1 May 2006 06:35:15 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay00.pair.com (relay00.pair.com [209.68.5.9]) by mx1.FreeBSD.org (Postfix) with SMTP id 5D82743D45 for ; Mon, 1 May 2006 06:35:15 +0000 (GMT) (envelope-from pho@holm.cc) Received: (qmail 61071 invoked from network); 1 May 2006 06:35:14 -0000 Received: from unknown (HELO peter.osted.lan) (unknown) by unknown with SMTP; 1 May 2006 06:35:14 -0000 X-pair-Authenticated: 83.95.197.184 Received: from peter.osted.lan (localhost.osted.lan [127.0.0.1]) by peter.osted.lan (8.13.4/8.13.4) with ESMTP id k416ZDdO022708 for ; Mon, 1 May 2006 08:35:13 +0200 (CEST) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.13.4/8.13.4/Submit) id k416ZDmT022707 for current@freebsd.org; Mon, 1 May 2006 08:35:13 +0200 (CEST) (envelope-from pho) Date: Mon, 1 May 2006 08:35:12 +0200 From: Peter Holm To: current@freebsd.org Message-ID: <20060501063512.GA22682@peter.osted.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: panic: flush_pagedep_deps: MKDIR_BODY X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2006 06:35:15 -0000 In GENERIC HEAD from Apr 30 07:27 UTC I got this double panic while stress testing: panic(c08e9dc3,b7c40,0,5af,c0a10258) at panic+0x14b flush_pagedep_deps(c3cbd924,c38ac510,c41024f8) at flush_pagedep_deps+0x18e softdep_sync_metadata(c3cbd924) at softdep_sync_metadata+0x410 ffs_syncvnode(c3cbd924,1) at ffs_syncvnode+0x328 ffs_truncate(c3cbd924,e00,0,880,c3b82c00,c3dac1b0) at ffs_truncate+0x4bf ufs_direnter(c3cbd924,c4b6d410,e614c9f8,e614cbc8,0) at ufs_direnter+0x7cf ufs_makeinode(1180,c3cbd924,e614cbb4,e614cbc8) at ufs_makeinode+0x456 ufs_mknod(e614cb60,c3cbd924,0,e614cc6c,c06dffe2) at ufs_mknod+0x29 VOP_MKNOD_APV(c098ab00,e614cb60) at VOP_MKNOD_APV+0x7e kern_mkfifo(c3dac1b0,804b720,0,180,e614cd30) at kern_mkfifo+0x2d6 mkfifo(c3dac1b0,e614cd04,e614cccc,c0687740,c3dac1b0) at mkfifo+0x15 syscall(3b,3b,3b,2805188c,bfbfe908) at syscall+0x27e and panic(c08d94f3,d756ca70,c382edb0,e643d76c,c06cd39e) at panic+0x54 bremfree(d756ca70) at bremfree+0x45 getblk(c382ed34,227580,0,4000,0) at getblk+0x15a breadn(c382ed34,227580,0,4000,0) at breadn+0x2f bread(c382ed34,227580,0,4000,0,e643d82c,c3751558,0,...) at bread+0x20 ffs_alloccg(c434f630,6,89d38,0,4000,c3751558,1,...) at ffs_alloccg+0x11d ffs_hashalloc(c434f630,6,89d38,0,4000) at ffs_hashalloc+0x43 ffs_realloccg(c434f630,0,0,8abee,0) at ffs_realloccg+0x541 ffs_balloc_ufs2(c4719c30,1000,0,1000,c3b82c00) at ffs_balloc_ufs2+0xd89 ffs_write(e643db9c,0,0,c097efe0,e643db50) at ffs_write+0x2ac VOP_WRITE_APV(c098ab00,e643db9c) at VOP_WRITE_APV+0x112 vn_write(c6caadc8,e643dc64,c3b82c00,0,c411fa20) at vn_write+0x1ea dofilewrite(c411fa20,4,c6caadc8,e643dc64,ffffffff) at dofilewrite+0x7b kern_writev(c411fa20,4,e643dc64,bfbfd7d0,1000) at kern_writev+0x36 write(c411fa20,e643dd04,e643dccc,c0687740,c411fa20) at write+0x45 syscall(2805003b,bfbf003b,bfbf003b,2805188c,bfbfe90c) at syscall+0x27e More details at http://people.freebsd.org/~pho/stress/log/cons199.html -- Peter Holm From owner-freebsd-current@FreeBSD.ORG Mon May 1 10:33:00 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D3B7416A400; Mon, 1 May 2006 10:33:00 +0000 (UTC) (envelope-from conrads@cox.net) Received: from eastrmmtao06.cox.net (eastrmmtao06.cox.net [68.230.240.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19AA243D48; Mon, 1 May 2006 10:32:59 +0000 (GMT) (envelope-from conrads@cox.net) Received: from serene.no-ip.org ([72.200.25.154]) by eastrmmtao06.cox.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20060501103258.WKUP16402.eastrmmtao06.cox.net@serene.no-ip.org>; Mon, 1 May 2006 06:32:58 -0400 Received: from localhost (localhost [127.0.0.1]) by serene.no-ip.org (8.13.6/8.13.6) with ESMTP id k41AWwJN016887; Mon, 1 May 2006 05:32:58 -0500 (CDT) (envelope-from conrads@cox.net) Date: Mon, 1 May 2006 05:32:52 -0500 From: "Conrad J. Sabatier" To: Pascal Hofstee Message-ID: <20060501053252.1f240f7e@localhost> In-Reply-To: <1146339764.1187.15.camel@synergy.odyssey.homeunix.org> References: <200604281203.k3SC3da7070033@repoman.freebsd.org> <20060428141404.Q40418@fledge.watson.org> <1146339764.1187.15.camel@synergy.odyssey.homeunix.org> Organization: A Rag-Tag Band of Drug-Crazed Hippies X-Mailer: Sylpheed-Claws 2.1.1 (GTK+ 2.8.17; amd64-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Hajimu UMEMOTO , current@freebsd.org Subject: Re: name-service caching X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2006 10:33:00 -0000 On Sat, 29 Apr 2006 12:42:44 -0700, Pascal Hofstee wrote: > On Sat, 2006-04-29 at 02:58 +0900, Hajimu UMEMOTO wrote: > > Okay, you can set it up quite easy: > > > > 1) Make sure you have /etc/cached.conf installed. > > 2) Put cached_enable="YES" into your /etc/rc.conf. > > 3) Start cached(8) by `/etc/rc.d/cached start'. > > 4) Put `cache' keyword to the database entries which you want to > > cache the result in /etc/nsswitch.conf. For example: > > > > hosts: cache files dns > > > > Please refer cached(8) and cached.conf(5) manpages for detail. > > Ok .. i am wondering if it's just me doing something stupid or if > things really are broken in some way. I followed the instructions as > provided above, using the default cached.conf. > > With a standard nsswitch.conf (without any cache lines) everything > works as expected. The second i modify the hosts: entry > in /etc/nsswitch.conf as suggested above, a lot of things stop > working. > > - cvs [update aborted]: received broken pipe signal > - portsnap can't fetch its tag information and aborts because of it > - the ports system can't seem to fetch any distfiles > > Those are a few of the immediate issues i encountered. > The second i remove the cache definition from the hosts: entry, normal > system operation is restored again. > > This is experienced on FreeBSD/amd64 7.0-CURRENT updated about an hour > ago since the time of writing. Any suggestions would be highly > appreciated. No, it's not just you. :-) I'm seeing the same thing here, also on an amd64 box. -- Conrad J. Sabatier -- "In Unix veritas" From owner-freebsd-current@FreeBSD.ORG Mon May 1 15:54:22 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA89C16A403 for ; Mon, 1 May 2006 15:54:22 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A05343D46 for ; Mon, 1 May 2006 15:54:22 +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.4/8.13.4) with ESMTP id k41FrIoN039648; Mon, 1 May 2006 09:53:23 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 01 May 2006 09:53:17 -0600 (MDT) Message-Id: <20060501.095317.06445891.imp@bsdimp.com> To: doconnor@gsoft.com.au From: "M. Warner Losh" In-Reply-To: <200605011421.49909.doconnor@gsoft.com.au> References: <6eb82e0604302110j7bca56eftce23feb306111823@mail.gmail.com> <200605011421.49909.doconnor@gsoft.com.au> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, grafan@gmail.com, marcel@xcllnt.net Subject: Re: lpt0 disappear (ppc related) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2006 15:54:22 -0000 In message: <200605011421.49909.doconnor@gsoft.com.au> "Daniel O'Connor" writes: : On Monday 01 May 2006 13:50, Marcel Moolenaar wrote: : > > As for building acpi into kernel, i386/conf/NOTES says: : > > : > > # Note that building ACPI into the kernel is deprecated; the module is : > > # normally loaded automatically by the loader. : > > : > > I thought that was deprecated? : > : > No, it isn't really. The use of modules is not a requirement. : : However you wouldn't expect that using it as a module would result in reduced : functionality. (The same as how you wouldn't expect compiling something into : your kernel would result in reduced functionality) At the same time, you'd expect it to behave like every other 'bus' in the tree. We omit the attachments for drivers to that bus when the kernel is built w/o that bus. This is why if you have, say, ep in the kernel, but pccard loaded as a module, the 3c589 you just inserted into the pccard slot won't work. It is a minor imperfection in the config system that no one has taken on as a Problem To Solve. Solving it turns out to be somewhat tricky. Warner From owner-freebsd-current@FreeBSD.ORG Mon May 1 16:55:42 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE86A16A442 for ; Mon, 1 May 2006 16:55:42 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B8DF43D46 for ; Mon, 1 May 2006 16:55:41 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.4.250] (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.13.6/8.13.6) with ESMTP id k41GteA1007871; Mon, 1 May 2006 09:55:40 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <200605011421.49909.doconnor@gsoft.com.au> References: <6eb82e0604300552he3d8010yf2ca81e52b54c4a7@mail.gmail.com> <6eb82e0604302110j7bca56eftce23feb306111823@mail.gmail.com> <200605011421.49909.doconnor@gsoft.com.au> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5DD170B6-01CA-4B17-A92E-62656070A012@xcllnt.net> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Mon, 1 May 2006 09:55:40 -0700 To: "Daniel O'Connor" X-Mailer: Apple Mail (2.749.3) Cc: freebsd-current@freebsd.org, Rong-En Fan Subject: Re: lpt0 disappear (ppc related) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2006 16:55:43 -0000 On Apr 30, 2006, at 9:51 PM, Daniel O'Connor wrote: > On Monday 01 May 2006 13:50, Marcel Moolenaar wrote: >>> As for building acpi into kernel, i386/conf/NOTES says: >>> >>> # Note that building ACPI into the kernel is deprecated; the >>> module is >>> # normally loaded automatically by the loader. >>> >>> I thought that was deprecated? >> >> No, it isn't really. The use of modules is not a requirement. > > However you wouldn't expect that using it as a module would result > in reduced > functionality. True. This is exactly where our kernel modules have a weakness. Or differently put, where our kernel configuration has its weakness. A module is pretty much all-inclusive. A kernel configuration is minimalistic by nature (hence, one would actually expect reduced functonality). Mixing them gives unwanted results in a pre-dominantly modular configuration. One way to attack it is to make a kernel configuration the same as a bundled set or a preloaded set of modules. This means for example that if you configure ppc(4) into the kernel, you get the acpi attachment even if you don't have device acpi configured into the kernel. This of course may result in unresolved symbols, so it's not a trivial solution. If it's a solution at all... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Mon May 1 21:25:40 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9DBFF16A402; Mon, 1 May 2006 21:25:40 +0000 (UTC) (envelope-from jd@ugcs.caltech.edu) Received: from regurgitate.ugcs.caltech.edu (regurgitate.ugcs.caltech.edu [131.215.176.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4906343D45; Mon, 1 May 2006 21:25:39 +0000 (GMT) (envelope-from jd@ugcs.caltech.edu) Received: by regurgitate.ugcs.caltech.edu (Postfix, from userid 3640) id 3669BE8AC; Mon, 1 May 2006 14:25:39 -0700 (PDT) Date: Mon, 1 May 2006 14:25:39 -0700 From: Paul Allen To: Mikhail Teterin Message-ID: <20060501212539.GA24193@regurgitate.ugcs.caltech.edu> References: <200605011604.26507.mi+mx@aldan.algebra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200605011604.26507.mi+mx@aldan.algebra.com> Sender: jd@ugcs.caltech.edu Cc: stable@freebsd.org, current@freebsd.org Subject: Re: cc can't build 32-bit executables on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2006 21:25:40 -0000 This was originally mentioned in amd64/76224 which was closed by obrien with the terse remark: "We don't yet support building 32-bit apps on a 64-bit system. We only barely support *running* them at this point." Really this deserves an errata mention at the very least. It just simply isn't intuitive that this functionality would be missing from a tier-1 release. Paul >From Mikhail Teterin , Mon, May 01, 2006 at 04:04:26PM -0400: > Can I direct someone's attention to the annoying but easy to fix bug: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=gnu/96570 > > There are still a few days left to make sure, FreeBSD-6.1 is shipped with > amd64 being able to link 32-bit executables. > > Release Engineers insist, it must be fixed in current first... > > Thanks! > > -mi > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon May 1 20:04:58 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6BA7F16A409; Mon, 1 May 2006 20:04:58 +0000 (UTC) (envelope-from mi+mx@aldan.algebra.com) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B52A43D67; Mon, 1 May 2006 20:04:56 +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 aldan.algebra.com (8.13.6/8.13.6) with ESMTP id k41K4qik092834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 May 2006 16:04:54 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from [172.21.130.86] (mx-broadway [38.98.68.18]) by corbulon.video-collage.com (8.13.6/8.13.6) with ESMTP id k41K4kqk073573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 May 2006 16:04:46 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) From: Mikhail Teterin Organization: Virtual Estates, Inc. To: current@freebsd.org, stable@freebsd.org Date: Mon, 1 May 2006 16:04:26 -0400 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200605011604.26507.mi+mx@aldan.algebra.com> X-Virus-Scanned: ClamAV 0.88/1433/Mon May 1 04:10:05 2006 on corbulon.video-collage.com X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.43 X-Mailman-Approved-At: Mon, 01 May 2006 21:32:57 +0000 Cc: Subject: cc can't build 32-bit executables on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2006 20:04:58 -0000 Can I direct someone's attention to the annoying but easy to fix bug: http://www.freebsd.org/cgi/query-pr.cgi?pr=gnu/96570 There are still a few days left to make sure, FreeBSD-6.1 is shipped with amd64 being able to link 32-bit executables. Release Engineers insist, it must be fixed in current first... Thanks! -mi From owner-freebsd-current@FreeBSD.ORG Mon May 1 22:15:59 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4AE8916A408; Mon, 1 May 2006 22:15:59 +0000 (UTC) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id E5F1043D45; Mon, 1 May 2006 22:15:58 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.19.131]) ([10.251.19.131]) by a50.ironport.com with ESMTP; 01 May 2006 15:15:59 -0700 Message-ID: <4456889D.1020006@elischer.org> Date: Mon, 01 May 2006 15:15:57 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <44512C65.9070106@elischer.org> In-Reply-To: <44512C65.9070106@elischer.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: announce@bafug.org, current@freebsd.org, grehan@freebsd.org Subject: Bay Area FreeBSD user's Group Meeting Wed. ACPI + Alan Cox X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2006 22:16:01 -0000 Wednesdays' meeting is almost upon us. Nate Lawson will tell us about ACPI You will also have the oportunity to meet Alan Cox of VM fame. I will be webcasting and recording the meeting as usual. Wednesday, 19:30 Pacific time (currently 7 hours behind UTC). Feedback via IRC (efnet #bafug as per usual) Audio/video at: rtsp://jello.ironport.com/bafug-live.sdp http://www.bafug.org/ for directions etc. San Francisco bay area resident freebsd users are invide, ney, encouraged to attend! Others are welcome to attend virtually. Julian From owner-freebsd-current@FreeBSD.ORG Mon May 1 22:46:13 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5BF8D16A413 for ; Mon, 1 May 2006 22:46:13 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id B664B43D45 for ; Mon, 1 May 2006 22:46:10 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp194-198.lns1.adl4.internode.on.net [203.122.194.198]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id k41Mjl9k099026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 May 2006 08:15:56 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: "M. Warner Losh" Date: Tue, 2 May 2006 08:15:14 +0930 User-Agent: KMail/1.9.1 References: <6eb82e0604302110j7bca56eftce23feb306111823@mail.gmail.com> <200605011421.49909.doconnor@gsoft.com.au> <20060501.095317.06445891.imp@bsdimp.com> In-Reply-To: <20060501.095317.06445891.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1293653.X7BX66CkEv"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200605020815.31012.doconnor@gsoft.com.au> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.56 on 203.31.81.10 Cc: freebsd-current@freebsd.org, grafan@gmail.com, marcel@xcllnt.net Subject: Re: lpt0 disappear (ppc related) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2006 22:46:13 -0000 --nextPart1293653.X7BX66CkEv Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 02 May 2006 01:23, M. Warner Losh wrote: > : However you wouldn't expect that using it as a module would result in > : reduced functionality. (The same as how you wouldn't expect compiling > : something into your kernel would result in reduced functionality) > > At the same time, you'd expect it to behave like every other 'bus' in > the tree. We omit the attachments for drivers to that bus when the > kernel is built w/o that bus. This is why if you have, say, ep in the > kernel, but pccard loaded as a module, the 3c589 you just inserted > into the pccard slot won't work. > > It is a minor imperfection in the config system that no one has taken > on as a Problem To Solve. Solving it turns out to be somewhat tricky. Hmm, but I load acpi as a module and get acpi attachments.. (for sio and pp= c) it's black magic to me anyway :) I didn't mean to belittle Marcel's work, I was just suprised that it would= =20 cause a functionality loss like that. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1293653.X7BX66CkEv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQBEVo+K5ZPcIHs/zowRAvGWAJ4kxQcjpcRxHRw3kZ2dMj0/StA6/QCggjfc Bijiu8t7z+D3rQI0VwZd7jU= =s6tt -----END PGP SIGNATURE----- --nextPart1293653.X7BX66CkEv-- From owner-freebsd-current@FreeBSD.ORG Mon May 1 22:56:06 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E890D16A43C; Mon, 1 May 2006 22:56:06 +0000 (UTC) (envelope-from noackjr@alumni.rice.edu) Received: from mail.clickfox.com (cffw1.clickfox.com [72.16.213.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63A6C43D48; Mon, 1 May 2006 22:56:06 +0000 (GMT) (envelope-from noackjr@alumni.rice.edu) X-PMWin-Version: 2.5.1s, Antispam-Engine: 2.3.0.1, Antivirus-Engine: 2.32.14 X-PMWin-Spam: Gauge=IIIIIIII, Probability=8%, Report='__HAS_MSGID, __SANE_MSGID, __USER_AGENT, __MIME_VERSION, __CT, __CHARSET_IS_KOI8U, __CTYPE_CHARSET_QUOTED, __CT_TEXT_PLAIN, __CTE, __HIGHBITS, __MIME_TEXT_ONLY' Thread-Index: AcZtcxKNrCm1bXjBSvS0dlbpsIJI5A== Received: from [10.20.30.156] ([10.20.30.156]) by mail.clickfox.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 May 2006 19:00:42 -0400 Message-ID: <445691FE.6000608@alumni.rice.edu> Date: Mon, 01 May 2006 18:55:58 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2663 Content-class: urn:content-classes:message Importance: normal Priority: normal From: "Jonathan Noack" User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Mikhail Teterin" References: <200605011604.26507.mi+mx@aldan.algebra.com> <20060501212539.GA24193@regurgitate.ugcs.caltech.edu> <200605011739.02920.mi+mx@aldan.algebra.com> In-reply-to: <200605011739.02920.mi+mx@aldan.algebra.com> Content-Type: text/plain; format=flowed; charset="KOI8-U" Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 01 May 2006 23:00:42.0439 (UTC) FILETIME=[126C4570:01C66D73] Cc: stable@freebsd.org, Paul Allen , current@freebsd.org Subject: Re: cc can't build 32-bit executables on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: noackjr@alumni.rice.edu List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2006 22:56:07 -0000 Mikhail Teterin wrote: > ÐÏÎÅĦÌÏË 01 ÔÒÁ×ÅÎØ 2006 17:25, Paul Allen ÎÁÐÉÓÁ×: >> This was originally mentioned in amd64/76224 which was closed by obrien >> with the terse remark: "We don't yet support building 32-bit apps on a >> 64-bit system. We only barely support *running* them at this point." > > I may be missing something huge, but, it seems to me, that my little patch is > sufficient to point cc to the right direction. With it I can create 32-bit > executables. Thus created lame, for example (from the audio/lame port) works > and happily converts mp3 files (using assembler-optimized routines available > only for 32-bit i386). Did you miss the previous reply which mentioned using '-B/usr/lib32 -B/usr/local/lib32' in addition to '-m32'? From gcc(1): The run-time support file 'libgcc.a' is also searched for using the '-B' prefix, if needed. If it is not found there, the two standard prefixes above are tried, and that is all. The file is left out of the link if it is not found by those means. Most of the time, on most machines, 'libgcc.a' is not actually necessary. -Jonathan From owner-freebsd-current@FreeBSD.ORG Tue May 2 00:15:16 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 408A116A421 for ; Tue, 2 May 2006 00:15:16 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1010943D82 for ; Tue, 2 May 2006 00:15:11 +0000 (GMT) (envelope-from joao@matik.com.br) Received: from anb (anb.matik.com.br [200.152.83.34]) by msrv.matik.com.br (8.13.6/8.13.1) with ESMTP id k420FAfi083557 for ; Mon, 1 May 2006 21:15:10 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR To: freebsd-current@freebsd.org Date: Mon, 1 May 2006 21:15:07 -0300 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200605012115.08314.joao@matik.com.br> X-Filter-Version: 1.11a (msrv.matik.com.br) X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on msrv.matik.com.br X-Virus-Status: Clean Subject: kbd strugglings X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2006 00:15:16 -0000 Hi it seems when I compile options MAXCONS=3D3 and/or options SC_HISTORY_SIZE=3D300 options SC_DFLT_FONT makeoptions SC_DFLT_FONT=3Diso options SC_NORM_ATTR=3D(FG_LIGHTGREY|BG_BLACK) options SC_NORM_REV_ATTR=3D(FG_YELLOW|BG_BLACK) options SC_KERNEL_CONS_ATTR=3D(FG_LIGHTGREY|BG_BLACK) options SC_KERNEL_CONS_REV_ATTR=3D(FG_RED|BG_BLACK) my keyboard dos not respond anymore, doesn't matter if I use kbdmux or not then when I compile kbdmux in (without the above) then my keyboard does not= =20 work under xorg anymore seems that there is created a kbd1 device before kbd0 what I believe is the= =20 ps2 connector on my laptop. This happens wether it is disabled in the Bios = or=20 not. So in order to get my real keyboard working I can not use adicional SC_=20 options neither kbdmux Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-current@FreeBSD.ORG Mon May 1 21:39:34 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 43DCD16A400; Mon, 1 May 2006 21:39:34 +0000 (UTC) (envelope-from mi+mx@aldan.algebra.com) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 25AFE43D45; Mon, 1 May 2006 21:39:29 +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 aldan.algebra.com (8.13.6/8.13.6) with ESMTP id k41LdEu8093066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 May 2006 17:39:23 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from [172.21.130.86] (mx-broadway [38.98.68.18]) by corbulon.video-collage.com (8.13.6/8.13.6) with ESMTP id k41Ld8Rw077828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 May 2006 17:39:08 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) From: Mikhail Teterin Organization: Virtual Estates, Inc. To: Paul Allen Date: Mon, 1 May 2006 17:39:02 -0400 User-Agent: KMail/1.9.1 References: <200605011604.26507.mi+mx@aldan.algebra.com> <20060501212539.GA24193@regurgitate.ugcs.caltech.edu> In-Reply-To: <20060501212539.GA24193@regurgitate.ugcs.caltech.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-u" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200605011739.02920.mi+mx@aldan.algebra.com> X-Virus-Scanned: ClamAV 0.88/1434/Mon May 1 15:51:00 2006 on corbulon.video-collage.com X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.43 X-Mailman-Approved-At: Tue, 02 May 2006 02:17:34 +0000 Cc: stable@freebsd.org, current@freebsd.org Subject: Re: cc can't build 32-bit executables on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2006 21:39:34 -0000 ÐÏÎÅĦÌÏË 01 ÔÒÁ×ÅÎØ 2006 17:25, Paul Allen ÎÁÐÉÓÁ×: > This was originally mentioned in amd64/76224 which was closed by obrien > with the terse remark: "We don't yet support building 32-bit apps on a > 64-bit system. We only barely support *running* them at this point." I may be missing something huge, but, it seems to me, that my little patch is sufficient to point cc to the right direction. With it I can create 32-bit executables. Thus created lame, for example (from the audio/lame port) works and happily converts mp3 files (using assembler-optimized routines available only for 32-bit i386). Maybe, there was more to it, when the amd64/76224 was closed, but there is so little now... It may still not work for something trickier, but, I think, I offer an improvement... -mi > Really this deserves an errata mention at the very least. šIt just simply > isn't intuitive that this functionality would be missing from a tier-1 > release. From owner-freebsd-current@FreeBSD.ORG Mon May 1 22:04:27 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 829AB16A473; Mon, 1 May 2006 22:04:27 +0000 (UTC) (envelope-from rsmith@xs4all.nl) Received: from smtp-vbr9.xs4all.nl (smtp-vbr9.xs4all.nl [194.109.24.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D88D43D77; Mon, 1 May 2006 22:04:23 +0000 (GMT) (envelope-from rsmith@xs4all.nl) Received: from slackbox.xs4all.nl (slackbox.xs4all.nl [213.84.242.160]) by smtp-vbr9.xs4all.nl (8.13.6/8.13.6) with ESMTP id k41M4E2r062587; Tue, 2 May 2006 00:04:15 +0200 (CEST) (envelope-from rsmith@xs4all.nl) Received: by slackbox.xs4all.nl (Postfix, from userid 1001) id 974E3B82E; Tue, 2 May 2006 00:04:14 +0200 (CEST) Date: Tue, 2 May 2006 00:04:14 +0200 From: Roland Smith To: Mikhail Teterin Message-ID: <20060501220414.GA74865@slackbox.xs4all.nl> References: <200605011604.26507.mi+mx@aldan.algebra.com> <20060501212539.GA24193@regurgitate.ugcs.caltech.edu> <200605011739.02920.mi+mx@aldan.algebra.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YZ5djTAD1cGYuMQK" Content-Disposition: inline In-Reply-To: <200605011739.02920.mi+mx@aldan.algebra.com> X-GPG-Fingerprint: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 X-GPG-Key: http://www.xs4all.nl/~rsmith/pubkey.txt X-GPG-Notice: If this message is not signed, don't assume I sent it! User-Agent: Mutt/1.5.11 X-Virus-Scanned: by XS4ALL Virus Scanner X-Mailman-Approved-At: Tue, 02 May 2006 02:17:44 +0000 Cc: stable@freebsd.org, Paul Allen , current@freebsd.org Subject: Re: cc can't build 32-bit executables on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2006 22:04:27 -0000 --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 01, 2006 at 05:39:02PM -0400, Mikhail Teterin wrote: > I may be missing something huge, but, it seems to me, that my little > patch is sufficient to point cc to the right direction. With it I can > create 32-bit executables. Thus created lame, for example (from the > audio/lame port) works and happily converts mp3 files (using > assembler-optimized routines available only for 32-bit i386). Lame compiles and runs just fine on amd64. Roland --=20 R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) --YZ5djTAD1cGYuMQK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEVoXeEnfvsMMhpyURAuNXAKCVeuN464n9gmfJOEvvvdYzzQyClACeIne1 MuM4ThvEmKdEnr3THjf3vBY= =mxEt -----END PGP SIGNATURE----- --YZ5djTAD1cGYuMQK-- From owner-freebsd-current@FreeBSD.ORG Mon May 1 23:01:01 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F59D16A401; Mon, 1 May 2006 23:01:01 +0000 (UTC) (envelope-from mi+mx@aldan.algebra.com) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id AED8543D7C; Mon, 1 May 2006 23:00:51 +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 aldan.algebra.com (8.13.6/8.13.6) with ESMTP id k41N0bEp093278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 May 2006 19:00:37 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from [172.21.130.86] (mx-broadway [38.98.68.18]) by corbulon.video-collage.com (8.13.6/8.13.6) with ESMTP id k41N0Rra079534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 May 2006 19:00:31 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) From: Mikhail Teterin Organization: Virtual Estates, Inc. To: noackjr@alumni.rice.edu, stable@freebsd.org, current@freebsd.org Date: Mon, 1 May 2006 19:00:21 -0400 User-Agent: KMail/1.9.1 References: <200605011604.26507.mi+mx@aldan.algebra.com> <200605011739.02920.mi+mx@aldan.algebra.com> <445691FE.6000608@alumni.rice.edu> In-Reply-To: <445691FE.6000608@alumni.rice.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-u" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200605011900.22011.mi+mx@aldan.algebra.com> X-Virus-Scanned: ClamAV 0.88/1434/Mon May 1 15:51:00 2006 on corbulon.video-collage.com X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.43 X-Mailman-Approved-At: Tue, 02 May 2006 02:17:58 +0000 Cc: Subject: Re: cc can't build 32-bit executables on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2006 23:01:01 -0000 ÐÏÎÅĦÌÏË 01 ÔÒÁ×ÅÎØ 2006 18:55, Jonathan Noack ÎÁÐÉÓÁ×: > Did you miss the previous reply which mentioned using '-B/usr/lib32 > -B/usr/local/lib32' in addition to '-m32'? I did not miss this work-around. But it is not a proper way -- one need not specify -B/usr/lib in the 64-bit case. Nor should one need to specify -B/usr/lib32, when using the -m32 flag. The gcc's multilib.h functionality is just for that. We just aren't using it (although we do for for aout) -- presumably, because there *was* a much bigger fish to fry to enable such compiles... -mi From owner-freebsd-current@FreeBSD.ORG Mon May 1 23:40:10 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3DCF216A402; Mon, 1 May 2006 23:40:10 +0000 (UTC) (envelope-from mi+mx@aldan.algebra.com) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id C113B43D48; Mon, 1 May 2006 23:40:08 +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 aldan.algebra.com (8.13.6/8.13.6) with ESMTP id k41Ne3TR093354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 May 2006 19:40:04 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from [172.21.130.86] (mx-broadway [38.98.68.18]) by corbulon.video-collage.com (8.13.6/8.13.6) with ESMTP id k41NdvfW080749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 May 2006 19:39:58 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) From: Mikhail Teterin Organization: Virtual Estates, Inc. To: "Sean Bryant" Date: Mon, 1 May 2006 19:39:51 -0400 User-Agent: KMail/1.9.1 References: <200605011604.26507.mi+mx@aldan.algebra.com> <200605011900.22011.mi+mx@aldan.algebra.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200605011939.52224.mi+mx@aldan.algebra.com> X-Virus-Scanned: ClamAV 0.88/1434/Mon May 1 15:51:00 2006 on corbulon.video-collage.com X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.43 X-Mailman-Approved-At: Tue, 02 May 2006 02:18:05 +0000 Cc: stable@freebsd.org, current@freebsd.org Subject: Re: cc can't build 32-bit executables on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2006 23:40:10 -0000 понеділок 01 травень 2006 19:25, Sean Bryant напиÑав: > > The gcc's multilib.h functionality is just for that. [...] > Then why not work on adding the functionality? I'm sure freebsd people > would love to have a proper working 32 bit compatibility layer > happening. Did you see the PR -- with the patch on the bottom? Does not the originator's name look familiar? http://www.freebsd.org/cgi/query-pr.cgi?pr=gnu/96570 Uh-oh... -mi From owner-freebsd-current@FreeBSD.ORG Tue May 2 01:06:30 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: by hub.freebsd.org (Postfix, from userid 692) id CB70A16A403; Tue, 2 May 2006 01:06:30 +0000 (UTC) Date: Tue, 2 May 2006 01:06:30 +0000 From: John Birrell To: current@freebsd.org Message-ID: <20060502010630.GA61548@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Tue, 02 May 2006 02:18:16 +0000 Cc: Subject: DTrace for FreeBSD and Google's SoC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2006 01:06:30 -0000 This is a HEADS-UP for people eligible to enter in Google's Summer of Code and who are still looking for something to work on. The FreeBSD port of Sun's DTrace could use some help. The status page is: There are lots of areas where students can contribute. If you are considering submitting an application (and remember that May 8 is the deadline), please contact me. I am signed up as a mentor. -- John Birrell From owner-freebsd-current@FreeBSD.ORG Tue May 2 02:30:19 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7109E16A415; Tue, 2 May 2006 02:30:19 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F52343D45; Tue, 2 May 2006 02:30:17 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k422U7h6035935; Mon, 1 May 2006 20:30:07 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4456C439.1070500@samsco.org> Date: Mon, 01 May 2006 20:30:17 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051230 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Allen References: <200605011604.26507.mi+mx@aldan.algebra.com> <20060501212539.GA24193@regurgitate.ugcs.caltech.edu> In-Reply-To: <20060501212539.GA24193@regurgitate.ugcs.caltech.edu> 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.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: Mikhail Teterin , stable@freebsd.org, current@freebsd.org Subject: Re: cc can't build 32-bit executables on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2006 02:30:19 -0000 Paul Allen wrote: > This was originally mentioned in amd64/76224 which was closed by obrien with the > terse remark: "We don't yet support building 32-bit apps on a 64-bit system. We > only barely support *running* them at this point." > > Really this deserves an errata mention at the very least. It just simply > isn't intuitive that this functionality would be missing from a tier-1 release. > > Paul Sorry, I'm not going to allow the toolchain to get hacked up the week before the release. If this is a feature that you want for FreeBSD 6.2, then please work with the architects of the FreeBSD/amd64 platform to make it happen. Saying at the very very last minute before a release that a pet feature is a requirement for tier-1 only falls on deaf ears. Scott From owner-freebsd-current@FreeBSD.ORG Tue May 2 04:29:32 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5087516A408 for ; Tue, 2 May 2006 04:29:32 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id C676E43D45 for ; Tue, 2 May 2006 04:29:31 +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.4/8.13.4) with ESMTP id k424RfhY009527; Mon, 1 May 2006 22:27:44 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 01 May 2006 22:27:43 -0600 (MDT) Message-Id: <20060501.222743.32503989.imp@bsdimp.com> To: doconnor@gsoft.com.au From: "M. Warner Losh" In-Reply-To: <200605020815.31012.doconnor@gsoft.com.au> References: <200605011421.49909.doconnor@gsoft.com.au> <20060501.095317.06445891.imp@bsdimp.com> <200605020815.31012.doconnor@gsoft.com.au> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, grafan@gmail.com, marcel@xcllnt.net Subject: Re: lpt0 disappear (ppc related) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2006 04:29:32 -0000 In message: <200605020815.31012.doconnor@gsoft.com.au> "Daniel O'Connor" writes: : On Tuesday 02 May 2006 01:23, M. Warner Losh wrote: : > : However you wouldn't expect that using it as a module would result in : > : reduced functionality. (The same as how you wouldn't expect compiling : > : something into your kernel would result in reduced functionality) : > : > At the same time, you'd expect it to behave like every other 'bus' in : > the tree. We omit the attachments for drivers to that bus when the : > kernel is built w/o that bus. This is why if you have, say, ep in the : > kernel, but pccard loaded as a module, the 3c589 you just inserted : > into the pccard slot won't work. : > : > It is a minor imperfection in the config system that no one has taken : > on as a Problem To Solve. Solving it turns out to be somewhat tricky. : : Hmm, but I load acpi as a module and get acpi attachments.. (for sio and ppc) : : it's black magic to me anyway :) : : I didn't mean to belittle Marcel's work, I was just suprised that it would : cause a functionality loss like that. I think it just points out a weakness in the underlying system... Warner From owner-freebsd-current@FreeBSD.ORG Tue May 2 04:38:33 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C71416A402 for ; Tue, 2 May 2006 04:38:33 +0000 (UTC) (envelope-from grafan@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id C920243D46 for ; Tue, 2 May 2006 04:38:32 +0000 (GMT) (envelope-from grafan@gmail.com) Received: by nz-out-0102.google.com with SMTP id x3so2996934nzd for ; Mon, 01 May 2006 21:38:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=E2aPjjOk0Vrke289LiOPoVxSqgm62FBcNdsaZrvPEeeDQ/Wc9RYHi+YHf2WDab0T7SjFweoKKYV/ESUMMa/h36ZYIYhVy3CWoYg8v2k+vTRbIgBibrx9frM34aiCa/p0EQ7WWwPqrCE1Tq7JM5u7hbrjFntyDwCQ5BKTvBw5ruM= Received: by 10.36.154.8 with SMTP id b8mr471614nze; Mon, 01 May 2006 21:38:32 -0700 (PDT) Received: by 10.36.24.17 with HTTP; Mon, 1 May 2006 21:38:32 -0700 (PDT) Message-ID: <6eb82e0605012138t1fb1c351o36203a5e269e889d@mail.gmail.com> Date: Tue, 2 May 2006 00:38:32 -0400 From: "Rong-En Fan" To: "M. Warner Losh" In-Reply-To: <20060501.222743.32503989.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200605011421.49909.doconnor@gsoft.com.au> <20060501.095317.06445891.imp@bsdimp.com> <200605020815.31012.doconnor@gsoft.com.au> <20060501.222743.32503989.imp@bsdimp.com> Cc: freebsd-current@freebsd.org, marcel@xcllnt.net Subject: Re: lpt0 disappear (ppc related) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2006 04:38:33 -0000 On 5/2/06, M. Warner Losh wrote: > In message: <200605020815.31012.doconnor@gsoft.com.au> > "Daniel O'Connor" writes: > : On Tuesday 02 May 2006 01:23, M. Warner Losh wrote: > : > : However you wouldn't expect that using it as a module would result = in > : > : reduced functionality. (The same as how you wouldn't expect compili= ng > : > : something into your kernel would result in reduced functionality) > : > > : > At the same time, you'd expect it to behave like every other 'bus' in > : > the tree. We omit the attachments for drivers to that bus when the > : > kernel is built w/o that bus. This is why if you have, say, ep in th= e > : > kernel, but pccard loaded as a module, the 3c589 you just inserted > : > into the pccard slot won't work. > : > > : > It is a minor imperfection in the config system that no one has taken > : > on as a Problem To Solve. Solving it turns out to be somewhat tricky= . > : > : Hmm, but I load acpi as a module and get acpi attachments.. (for sio an= d ppc) > : > : it's black magic to me anyway :) > : > : I didn't mean to belittle Marcel's work, I was just suprised that it wo= uld > : cause a functionality loss like that. > > I think it just points out a weakness in the underlying system... Hmm, until this is solved. Could we have acpi configured in kernel on i386 as default? I really don't know why this is deprecated usage. (as the comments in NOTES says) Thanks, Rong-En Fan From owner-freebsd-current@FreeBSD.ORG Tue May 2 05:04:44 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A17AD16A400; Tue, 2 May 2006 05:04:44 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A1C043D46; Tue, 2 May 2006 05:04:41 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k4254MqD036652; Mon, 1 May 2006 23:04:22 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4456E860.8090308@samsco.org> Date: Mon, 01 May 2006 23:04:32 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051230 X-Accept-Language: en-us, en MIME-Version: 1.0 To: stable@freebsd.org References: <200605011604.26507.mi+mx@aldan.algebra.com> <20060501212539.GA24193@regurgitate.ugcs.caltech.edu> <4456C439.1070500@samsco.org> In-Reply-To: <4456C439.1070500@samsco.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.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: Mikhail Teterin , Paul Allen , current@freebsd.org Subject: Re: cc can't build 32-bit executables on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2006 05:04:44 -0000 I tend to get snippy towards the end of release cycles, and I apologize to those I've offended or have been needlessly rude to. But please hear me out on what I have to say here.... What makes a release cycle stressful is not the bug tracking and fixing, or the building of bits, or anything like that. It's that many people seem to wait until the very last minute to test the release and speak up with their issues. I don't know if it's because people politely assume that all of the issues are already known and are being worked on, therefore their effort and their voice isn't needed, or if it's because people are reluctant to test anything until others have worked the bugs out for them. Either way, whether I try to rush a release in 1 month or let it draw out to 3 months, there is always the last minute push by those who are concerned about a certain problem or a missing feature and who desperately hope that something will be done about it. First of all, each release is a step in the overall process. While it's always unfortunate and undesirable to have bugs in releases or have missing features, it's even more undesirable to hold releases indefinitely until "all the problems are solved". It amounts to throwing away all of the work has happened on the hopes that future work might happen. Releases need to happen, and they need to happen on a regular basis. If something is broken or missing in a release, then it can be worked on in the next release. 6.1 is just a precursor to 6.2, and 6.2 can't happen until 6.1 is released. Second, we need more people testing early on in the release process. The BETA builds are meant to give people a baseline of what the expected functionality should be so that bugs can be found and fixed. The RC's are just meant to be a final polishing of cosmetic things. Waiting until RC1 or RC2 to test UFS quotas or ask why 32-bit compiling doesn't work is a bit late. If these things had been brought up 3 months ago, or even 1 month ago, there is a much higher probability that they could have been addressed. If no one wants to do any serious testing (with the notable exception of Kris Kenneway, Peter Holms, and a few others), then I might as well just skip the majority of the release cycle and just stamp out RC1 followed immediately by RELEASE. The release cycle doesn't work if people put off testing until others test for them. So please, when 6.2-BETA2 happens, everyone reading this email please give it a spin, even if it's just in a QEMU or VMWare session (and it is rediculously easy to test a CD with those, I do it all the time for my day job). The release process is about balancing the need to "get it done" with the need to "get it as good as possible". The time to identify and fix problems is during the BETA phase, so please help us to make that happen. And if we get to the RC phase and something is broken or unfinished, then please help us to get it resolved for the next release. Thanks, Scott From owner-freebsd-current@FreeBSD.ORG Tue May 2 06:23:38 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3695116A400; Tue, 2 May 2006 06:23:38 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5AD3943D48; Tue, 2 May 2006 06:23:37 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from gothmog.pc (aris.bedc.ondsl.gr [62.103.39.226]) (authenticated bits=128) by igloo.linux.gr (8.13.6/8.13.6/Debian-1) with ESMTP id k426MrYD009839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 May 2006 09:22:59 +0300 Received: from gothmog.pc (gothmog [127.0.0.1]) by gothmog.pc (8.13.6/8.13.6) with ESMTP id k426Mwo7063009; Tue, 2 May 2006 09:22:58 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from giorgos@localhost) by gothmog.pc (8.13.6/8.13.6/Submit) id k426MwW1063008; Tue, 2 May 2006 09:22:58 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Tue, 2 May 2006 09:22:58 +0300 From: Giorgos Keramidas To: Mikhail Teterin Message-ID: <20060502062258.GA62901@gothmog.pc> References: <200605011604.26507.mi+mx@aldan.algebra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200605011604.26507.mi+mx@aldan.algebra.com> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (score=-3.398, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.80, BAYES_00 -2.60, DNS_FROM_RFC_ABUSE 0.20) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: stable@freebsd.org, current@freebsd.org Subject: Re: cc can't build 32-bit executables on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2006 06:23:38 -0000 On 2006-05-01 16:04, Mikhail Teterin wrote: > Can I direct someone's attention to the annoying but easy to fix bug: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=gnu/96570 > > There are still a few days left to make sure, FreeBSD-6.1 is shipped with > amd64 being able to link 32-bit executables. > > Release Engineers insist, it must be fixed in current first... cc can build binaries just fine if you also use the -B option: % cc -m32 -B/usr/lib32 ... I know it does because I've used it on my laptop a while ago, running FreeBSD/amd64. It's dead now so I can verify this works in all cases, but it seemed to solve this for me a couple of months ago. From owner-freebsd-current@FreeBSD.ORG Tue May 2 09:46:54 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B90C16A402; Tue, 2 May 2006 09:46:54 +0000 (UTC) (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 6375D43D45; Tue, 2 May 2006 09:46:53 +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 1FarT0-000GYk-Sy; Tue, 02 May 2006 12:46:50 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Scott Long In-reply-to: <4456E860.8090308@samsco.org> References: <200605011604.26507.mi+mx@aldan.algebra.com> <20060501212539.GA24193@regurgitate.ugcs.caltech.edu> <4456C439.1070500@samsco.org> <4456E860.8090308@samsco.org> Comments: In-reply-to Scott Long message dated "Mon, 01 May 2006 23:04:32 -0600." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 02 May 2006 12:46:50 +0300 From: Danny Braniss Message-ID: Cc: stable@freebsd.org, Paul Allen , Mikhail Teterin , current@freebsd.org Subject: Re: cc can't build 32-bit executables on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2006 09:46:54 -0000 > I tend to get snippy towards the end of release cycles, and I apologize > to those I've offended or have been needlessly rude to. But please hear > me out on what I have to say here.... > ... > The release process is about balancing the need to "get it done" with > the need to "get it as good as possible". The time to identify and fix > problems is during the BETA phase, so please help us to make that > happen. And if we get to the RC phase and something is broken or > unfinished, then please help us to get it resolved for the next release. Just speeking for myself, and maybe others think like me :-), I have been running 6.1-XXX on several servers and work stations all along, and haven't felt any panics or serious problems to report, so sorry :-) [there of cource problems, slowness of network come to mind] So please, keep the good work! danny From owner-freebsd-current@FreeBSD.ORG Tue May 2 10:00:29 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C161A16A402; Tue, 2 May 2006 10:00:29 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail23.syd.optusnet.com.au (mail23.syd.optusnet.com.au [211.29.133.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF9C143D5F; Tue, 2 May 2006 10:00:21 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail23.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k429xsvx010034 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 2 May 2006 19:59:54 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.6/8.13.6) with ESMTP id k429xsRT001309; Tue, 2 May 2006 19:59:54 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.6/8.13.6/Submit) id k429xsSr001308; Tue, 2 May 2006 19:59:54 +1000 (EST) (envelope-from peter) Date: Tue, 2 May 2006 19:59:54 +1000 From: Peter Jeremy To: Roland Smith Message-ID: <20060502095954.GA693@turion.vk2pj.dyndns.org> References: <200605011604.26507.mi+mx@aldan.algebra.com> <20060501212539.GA24193@regurgitate.ugcs.caltech.edu> <200605011739.02920.mi+mx@aldan.algebra.com> <20060501220414.GA74865@slackbox.xs4all.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Dxnq1zWXvFF0Q93v" Content-Disposition: inline In-Reply-To: <20060501220414.GA74865@slackbox.xs4all.nl> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: Mikhail Teterin , stable@freebsd.org, current@freebsd.org Subject: Re: cc can't build 32-bit executables on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2006 10:00:30 -0000 --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 2006-May-02 00:04:14 +0200, Roland Smith wrote: >On Mon, May 01, 2006 at 05:39:02PM -0400, Mikhail Teterin wrote: =2E.. >> create 32-bit executables. Thus created lame, for example (from the >> audio/lame port) works and happily converts mp3 files (using >> assembler-optimized routines available only for 32-bit i386). > >Lame compiles and runs just fine on amd64. But probably not as fast since it's using a generic 'C' core instead of a hand-tweaked assembler core. I read Mikhail's comment as meaning that it is possible to build non-trivial 32-bit executables on amd64, there's just work still needed to make this work as a general case. --=20 Peter Jeremy --Dxnq1zWXvFF0Q93v Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEVy2Z/opHv/APuIcRAgZuAKCTY2dxioLZ8UuUv1biKhqUedZjugCeKSRQ YNo8Aid/WYh5l166tR5lR4s= =EDc+ -----END PGP SIGNATURE----- --Dxnq1zWXvFF0Q93v-- From owner-freebsd-current@FreeBSD.ORG Tue May 2 11:05:49 2006 Return-Path: X-Original-To: Freebsd-current@freebsd.org Delivered-To: Freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E565916A425 for ; Tue, 2 May 2006 11:05:49 +0000 (UTC) (envelope-from rmgls@wanadoo.fr) Received: from smtp18.wanadoo.fr (smtp18.wanadoo.fr [193.252.22.126]) by mx1.FreeBSD.org (Postfix) with ESMTP id 259BE43D69 for ; Tue, 2 May 2006 11:05:44 +0000 (GMT) (envelope-from rmgls@wanadoo.fr) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf1809.wanadoo.fr (SMTP Server) with ESMTP id E78DD700009B for ; Tue, 2 May 2006 13:05:42 +0200 (CEST) Received: from wanadoo.fr (ARouen-252-1-140-192.w86-215.abo.wanadoo.fr [86.215.75.192]) by mwinf1809.wanadoo.fr (SMTP Server) with ESMTP id D120B7000093 for ; Tue, 2 May 2006 13:05:42 +0200 (CEST) X-ME-UUID: 20060502110542856.D120B7000093@mwinf1809.wanadoo.fr To: Freebsd-current@freebsd.org From: rmgls@wanadoo.fr Date: Tue, 02 May 2006 13:05:38 +0200 Sender: rmgls@wanadoo.fr Message-Id: <20060502110542.D120B7000093@mwinf1809.wanadoo.fr> Cc: Subject: debug_firmware patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2006 11:05:50 -0000 On Monday 01 May 2006 00:20, Max Laier wrote: > Here is a small patch to build a "debug.firmware" sysctl. Should give: > "iwi_bss/300/191142" for the latest firmware from net/iwi-firmware-kmod > Any comments on the patch? Will commit shortly otherwise. ... Hi, A minor side effect of the patch: if defined before X_load="YES" (say ucom, and uplcom), in loader.conf, prevents X_loading: no cuaU nor ttyU present; No problem if defined after. Best regards, | mlaier@freebsd.org Raoul rmgls@wanadoo.Fr Index: subr_firmware.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/store/mlaier/fcvs/src/sys/kern/subr_firmware.c,v retrieving revision 1.1 diff -u -r1.1 subr_firmware.c =2D-- subr_firmware.c 29 Jan 2006 02:52:41 -0000 1.1 +++ subr_firmware.c 30 Apr 2006 22:11:05 -0000 @@ -32,6 +32,8 @@ #include #include #include +#include +#include #include #include #include @@ -41,6 +43,8 @@ #include #include +static int sysctl_debug_firmware(SYSCTL_HANDLER_ARGS); +#define FIRMWARE_MAX 30 static char *name_unload = "UNLOADING"; static struct firmware firmware_table[FIRMWARE_MAX]; @@ -48,6 +52,49 @@ struct mtx firmware_mtx; MTX_SYSINIT(firmware, &firmware_mtx, "firmware table", MTX_DEF); +static int +sysctl_debug_firmware(SYSCTL_HANDLER_ARGS) +{ + struct firmware *fp; + struct sbuf sb; + int error, i, count = 0; + + for (i = 0; i < FIRMWARE_MAX; i++) { + fp = &firmware_table[i]; + if (fp->name != NULL) + count++; + } + + if (count == 0) + return (sysctl_handle_string(oidp, "NONE", 5, req)); + + sbuf_new(&sb, NULL, count * 32 + 2, SBUF_FIXEDLEN); + + sbuf_printf(&sb, "\n"); + + mtx_lock(&firmware_mtx); + for (i = 0; i < FIRMWARE_MAX; i++) { + fp = &firmware_table[i]; + if (fp->name != NULL) { + if (count-- <= 0) + sbuf_printf(&sb, "...\n"); + else + sbuf_printf(&sb, "\t%16s/%u/%zi\n", fp->name, + fp->version, fp->datasize); + } + } + mtx_unlock(&firmware_mtx); + + sbuf_trim(&sb); + sbuf_finish(&sb); + error = sysctl_handle_string(oidp, sbuf_data(&sb), sbuf_len(&sb), req); + sbuf_delete(&sb); + + return (error); +} +SYSCTL_OID(_debug, OID_AUTO, firmware, CTLTYPE_STRING|CTLFLAG_RD, NULL, 0, + sysctl_debug_firmware, "A", "Loaded firmware images"); + /* * Register a firmware image with the specified name. The * image name must not already be registered. If this is a From owner-freebsd-current@FreeBSD.ORG Tue May 2 14:07:44 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D197416A401 for ; Tue, 2 May 2006 14:07:44 +0000 (UTC) (envelope-from matt@mattsnetwork.co.uk) Received: from mattsnetwork.co.uk (mattsnetwork.co.uk [82.152.140.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5755643D45 for ; Tue, 2 May 2006 14:07:42 +0000 (GMT) (envelope-from matt@mattsnetwork.co.uk) Received: from workstation1.local.mattsnetwork.co.uk (md001@workstation1.local.mattsnetwork.co.uk [192.168.0.145]) (authenticated bits=0) by mattsnetwork.co.uk (8.13.4/8.13.4) with ESMTP id k42E7alT027131 for ; Tue, 2 May 2006 15:07:36 +0100 (BST) (envelope-from matt@mattsnetwork.co.uk) From: Matt Dawson To: freebsd-current@freebsd.org Date: Tue, 2 May 2006 15:07:35 +0100 User-Agent: KMail/1.9.1 References: <20060502120040.3E99316A431@hub.freebsd.org> In-Reply-To: <20060502120040.3E99316A431@hub.freebsd.org> X-Face: Zrm9At!%e{M_#Po+[-\; RFQih#L0/\!^6f8JS_1Nz,8`(@bR%|T,c)3:o6my`.sy$Rt)'^)ec9cWp!MmeH^Gp|Afl)BkcH1GENCBqb&wZ$cdqN27uYfD=jU@1:vWXf|)LmuVKo?1wuS68KeDX&3,#wZP2$N1Ao!_'mZOws67 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200605021507.35823.matt@mattsnetwork.co.uk> X-Spam-Status: No, score=-4.4 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=unavailable version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on central.local.mattsnetwork.co.uk X-Virus-Scanned: ClamAV 0.88.2/1434/Mon May 1 20:51:00 2006 on central.local.mattsnetwork.co.uk X-Virus-Status: Clean Subject: Re: freebsd-current Digest, Vol 143, Issue 2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2006 14:07:44 -0000 On Tuesday 02 May 2006 13:00, freebsd-current-request@freebsd.org wrote: > I tend to get snippy towards the end of release cycles, and I apologize > to those I've offended or have been needlessly rude to. You were quite justified, IMHO, and didn't come across as rude at all. Once a branch reaches beta or release candidate, the focus is, and always should be, on testing existing features, not adding new ones. OK, the RocketRAID driver was added for RC2 but that's a one-off safe addition that appears not to affect any other stable code, unlike messing with the build tools at this late stage. Being trapped between pet feature proponents and folks with a timetable cannot be fun and your restraint is admirable, especially considering the already high workload on releng at the moment. Personally, I would not like to see a situation like 5.2 where creature feep and not enough testing made 5.2.1 necessary soon afterwards. The releng team got the blame but it was the demanding pet feature owners that caused the problem, AFAICS. Such things reflect badly on the project as a whole, unlike not being able to view the WMV funny sent by your co-worker from two cubes away, which is trivial by comparison and only reflects on the application's inability to be 64bit clean or being a closed-source binary blob which is only compiled against i386. BTW, running RC2/amd64 and so far it seems rock solid and very fast (empirical evidence only - I don't do synthetic benchmarks as they tend to tempt you to add silly things like -ffast-math to make.conf in a vain attempt to get similar performance to whatever you're testing against on a workload that is rarely likely to crop up in Real Life [TM]). I'm having a few problems with Xorg and a Radeon 9700 on one desktop, but that is nothing to do with the base system. My opinion only, of course. -- Matt Dawson. matt@mattsnetwork.co.uk MTD15-RIPE OpenNIC M_D9 MD51-6BONE From owner-freebsd-current@FreeBSD.ORG Tue May 2 14:10:21 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5408216A404 for ; Tue, 2 May 2006 14:10:21 +0000 (UTC) (envelope-from peter@netkey.at) Received: from xena.netkey.at (ns.netkey.at [83.64.50.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id C385243D46 for ; Tue, 2 May 2006 14:10:20 +0000 (GMT) (envelope-from peter@netkey.at) Received: from localhost (localhost [127.0.0.1]) by xena.netkey.at (Postfix) with ESMTP id 736B8118 for ; Tue, 2 May 2006 16:10:18 +0200 (CEST) Received: from xena.netkey.at ([127.0.0.1]) by localhost (xena.netkey.at [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 12175-03-4 for ; Tue, 2 May 2006 16:10:13 +0200 (CEST) Received: from [192.168.0.244] (83-64-50-177.hietzing.xdsl-line.inode.at [83.64.50.177]) by xena.netkey.at (Postfix) with ESMTP id CCB2EA3 for ; Tue, 2 May 2006 16:10:13 +0200 (CEST) From: Peter Klett Organization: netkey information technology gesmbh To: freebsd-current@freebsd.org Date: Tue, 2 May 2006 16:10:12 +0200 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200605021610.12599.peter@netkey.at> X-Virus-Scanned: by amavisd-new at xena.netkey.at X-Mailman-Approved-At: Tue, 02 May 2006 15:51:07 +0000 Subject: DRI seems to bee broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2006 14:10:21 -0000 Hello CURRENT, my system has been cvsup'd yesterday, world is approx. 4 weeks old, kernel was compiled yesterday. When I try to start X (xorg 6.9.0) my screen gets dark and Xorg uses up to 100% cpu. Pressing any key just don't help at all. I can log into my box via ssh but cannot kill the process. If I comment out the module "dri" entry in xorg.conf everything works again :-) An old kernel (1 month old) works with the dri setting. Could it just be because world and kernel are out of sync ? Thx for any input. greetings Peter From owner-freebsd-current@FreeBSD.ORG Tue May 2 14:29:52 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 21BCF16A424; Tue, 2 May 2006 14:29:52 +0000 (UTC) (envelope-from mi+kde@aldan.algebra.com) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 210C243D62; Tue, 2 May 2006 14:29:44 +0000 (GMT) (envelope-from mi+kde@aldan.algebra.com) Received: from aldan.algebra.com (aldan [127.0.0.1]) by aldan.algebra.com (8.13.6/8.13.6) with ESMTP id k42ETebr095965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 May 2006 10:29:40 -0400 (EDT) (envelope-from mi+kde@aldan.algebra.com) Received: from localhost (localhost [[UNIX: localhost]]) by aldan.algebra.com (8.13.6/8.13.6/Submit) id k42ETetP095964; Tue, 2 May 2006 10:29:40 -0400 (EDT) (envelope-from mi+kde@aldan.algebra.com) From: Mikhail Teterin To: Giorgos Keramidas Date: Tue, 2 May 2006 10:29:39 -0400 User-Agent: KMail/1.9.1 References: <200605011604.26507.mi+mx@aldan.algebra.com> <20060502062258.GA62901@gothmog.pc> In-Reply-To: <20060502062258.GA62901@gothmog.pc> X-Face: %UW#n0|w>ydeGt/b@1-.UFP=K^~-:0f#O:D7whJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli" X-Mailman-Approved-At: Tue, 02 May 2006 15:53:38 +0000 Cc: Mikhail Teterin , stable@freebsd.org, current@freebsd.org Subject: Re: cc can't build 32-bit executables on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2006 14:29:52 -0000 On Tuesday 02 May 2006 02:22, Giorgos Keramidas wrote: = cc can build binaries just fine if you also use the -B option: = =         % cc -m32 -B/usr/lib32 ... Yes, this is a work-around. It is not a solution... /usr/lib32 should be there automatically. = I know it does because I've used it on my laptop a while ago [...] Unfortunately, according to the compiler-maintainer, there are some cases, when the different include files should also be used in the -m32 case, and that appears harder to fix. Until that is fixed, David is unwilling to pick this very low-hanging fruit either. Evidently, he does not "subscribe" to the 80/20 principle :-( -mi From owner-freebsd-current@FreeBSD.ORG Tue May 2 15:02:07 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 535C016A44C; Tue, 2 May 2006 15:02:07 +0000 (UTC) (envelope-from mi+kde@aldan.algebra.com) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F19043D77; Tue, 2 May 2006 15:01:59 +0000 (GMT) (envelope-from mi+kde@aldan.algebra.com) Received: from aldan.algebra.com (aldan [127.0.0.1]) by aldan.algebra.com (8.13.6/8.13.6) with ESMTP id k42F1wFT096142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 May 2006 11:01:58 -0400 (EDT) (envelope-from mi+kde@aldan.algebra.com) Received: from localhost (localhost [[UNIX: localhost]]) by aldan.algebra.com (8.13.6/8.13.6/Submit) id k42F1v1W096141; Tue, 2 May 2006 11:01:57 -0400 (EDT) (envelope-from mi+kde@aldan.algebra.com) From: Mikhail Teterin To: Peter Jeremy Date: Tue, 2 May 2006 11:01:57 -0400 User-Agent: KMail/1.9.1 References: <200605011604.26507.mi+mx@aldan.algebra.com> <20060501220414.GA74865@slackbox.xs4all.nl> <20060502095954.GA693@turion.vk2pj.dyndns.org> In-Reply-To: <20060502095954.GA693@turion.vk2pj.dyndns.org> X-Face: %UW#n0|w>ydeGt/b@1-.UFP=K^~-:0f#O:D7whJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli" X-Mailman-Approved-At: Tue, 02 May 2006 15:54:30 +0000 Cc: Roland Smith , Mikhail Teterin , stable@freebsd.org, current@freebsd.org Subject: Re: cc can't build 32-bit executables on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2006 15:02:07 -0000 On Tuesday 02 May 2006 05:59, Peter Jeremy wrote: = But probably not as fast since it's using a generic 'C' core instead = of a hand-tweaked assembler core. šI read Mikhail's comment as meaning = that it is possible to build non-trivial 32-bit executables on amd64, = there's just work still needed to make this work as a general case. Thanks, Peter. You are correct, that was my meaning. Interestingly, the assembler-optimized 32-bit routines made lame slower than the native 64-bit code in my experiments (one may wish to compare assembler vs. C lame on i386 too). But it all *worked*, which was the point... -mi From owner-freebsd-current@FreeBSD.ORG Tue May 2 15:15:37 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC17C16A403 for ; Tue, 2 May 2006 15:15:37 +0000 (UTC) (envelope-from karagodov@gmail.com) Received: from pproxy.gmail.com (pproxy.gmail.com [64.233.166.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44F3743D48 for ; Tue, 2 May 2006 15:15:37 +0000 (GMT) (envelope-from karagodov@gmail.com) Received: by pproxy.gmail.com with SMTP id t32so3103375pyc for ; Tue, 02 May 2006 08:15:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=LPB12aaMFuJwJJoZORZn1AeZrPBeGe3Erob5fL9dKW5RU6a7YlUfUomn9ZY1xwY2sMV1mNhCW31PbVY/b60evGbikvRlaf0dAUVabxiFwTlBknLelidXbl3VqrFF5Ewaqra+th8cr/qpj4Qm9NbnnpwtpgMB6kkUdEvLZiZ2JFU= Received: by 10.35.17.8 with SMTP id u8mr1096442pyi; Tue, 02 May 2006 08:15:36 -0700 (PDT) Received: by 10.35.135.15 with HTTP; Tue, 2 May 2006 08:15:36 -0700 (PDT) Message-ID: Date: Tue, 2 May 2006 19:15:36 +0400 From: "Alexey Karagodov" To: "Mikhail Teterin" In-Reply-To: <200605021101.57778@aldan> MIME-Version: 1.0 References: <200605011604.26507.mi+mx@aldan.algebra.com> <20060501220414.GA74865@slackbox.xs4all.nl> <20060502095954.GA693@turion.vk2pj.dyndns.org> <200605021101.57778@aldan> X-Mailman-Approved-At: Tue, 02 May 2006 15:54:42 +0000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@freebsd.org, Peter Jeremy , Mikhail Teterin , stable@freebsd.org, Roland Smith Subject: Re: cc can't build 32-bit executables on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2006 15:15:38 -0000 workaround i use: 32-bit jail on amd64 system ... not so bad ... 2006/5/2, Mikhail Teterin : > > On Tuesday 02 May 2006 05:59, Peter Jeremy wrote: > =3D But probably not as fast since it's using a generic 'C' core instead > =3D of a hand-tweaked assembler core. I read Mikhail's comment as meaning > =3D that it is possible to build non-trivial 32-bit executables on amd64, > =3D there's just work still needed to make this work as a general case. > > Thanks, Peter. You are correct, that was my meaning. > > Interestingly, the assembler-optimized 32-bit routines made lame slower > than > the native 64-bit code in my experiments (one may wish to compare > assembler > vs. C lame on i386 too). But it all *worked*, which was the point... > > -mi > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue May 2 16:32:05 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ADEF116A402; Tue, 2 May 2006 16:32:05 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6920643D46; Tue, 2 May 2006 16:32:05 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id B3BCD975; Tue, 2 May 2006 11:32:04 -0500 (CDT) Date: Tue, 2 May 2006 11:32:04 -0500 To: Scott Long Message-ID: <20060502163204.GB31236@soaustin.net> References: <200605011604.26507.mi+mx@aldan.algebra.com> <20060501212539.GA24193@regurgitate.ugcs.caltech.edu> <4456C439.1070500@samsco.org> <4456E860.8090308@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4456E860.8090308@samsco.org> User-Agent: Mutt/1.5.9i From: linimon@lonesome.com (Mark Linimon) X-Mailman-Approved-At: Tue, 02 May 2006 16:52:15 +0000 Cc: stable@freebsd.org, Paul Allen , Mikhail Teterin , current@freebsd.org Subject: Re: cc can't build 32-bit executables on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2006 16:32:05 -0000 On Mon, May 01, 2006 at 11:04:32PM -0600, Scott Long wrote: > While it's always unfortunate and undesirable to have bugs in releases > or have missing features, it's even more undesirable to hold releases > indefinitely until "all the problems are solved". Even the most cursory review of GNATS will reveal that there are bugs in every release. Even if we were a professional, rather than almost-all- volunteer, organization, this would _still_ be true. This is true of all software, not just FreeBSD. (I will not mention the name of any Major Operating System/Applications Vendors here). The tradeoff is _always_ "which bugs affect the most people". If we waited for all the problems to be solved, we would have releases very rarely. This was tried in the 5.X cycle and really didn't work very well :-) So it's a question of where you make the tradeoffs. From at least one perspective (ports, could you have guessed? :-) ), the release has already been fairly drawn-out as it is. I'll echo what Scott said about preparing for these things early, so that everyone can try to prioritize which bugs most need to be addressed. mcl From owner-freebsd-current@FreeBSD.ORG Tue May 2 17:10:55 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8AB3A16A406 for ; Tue, 2 May 2006 17:10:55 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF40F43D66 for ; Tue, 2 May 2006 17:10:44 +0000 (GMT) (envelope-from joao@matik.com.br) Received: from [200.152.83.34] (anb.matik.com.br [200.152.83.34]) by msrv.matik.com.br (8.13.6/8.13.1) with ESMTP id k42H9pIB011609; Tue, 2 May 2006 14:09:51 -0300 (BRT) (envelope-from joao@matik.com.br) Message-ID: <4457928F.60805@matik.com.br> Date: Tue, 02 May 2006 14:10:39 -0300 From: joaoBR User-Agent: Thunderbird 1.5 (X11/20060424) MIME-Version: 1.0 To: Mark Linimon References: <200605011604.26507.mi+mx@aldan.algebra.com> <20060501212539.GA24193@regurgitate.ugcs.caltech.edu> <4456C439.1070500@samsco.org> <4456E860.8090308@samsco.org> <20060502163204.GB31236@soaustin.net> In-Reply-To: <20060502163204.GB31236@soaustin.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Filter-Version: 1.11a (msrv.matik.com.br) X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on msrv.matik.com.br X-Virus-Status: Clean Cc: current@freebsd.org Subject: Re: cc can't build 32-bit executables on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2006 17:10:55 -0000 Mark Linimon wrote: > > Even the most cursory review of GNATS will reveal that there are bugs in > every release. Even if we were a professional, rather than almost-all- > volunteer, organization, this would _still_ be true. This is true of > all software, not just FreeBSD. > well,that is a really nice quote João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-current@FreeBSD.ORG Tue May 2 17:55:41 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6DA1616A465 for ; Tue, 2 May 2006 17:55:41 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5859E43DC6 for ; Tue, 2 May 2006 17:55:16 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from gothmog.pc (aris.bedc.ondsl.gr [62.103.39.226]) (authenticated bits=128) by igloo.linux.gr (8.13.6/8.13.6/Debian-1) with ESMTP id k42HsqCE002334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 May 2006 20:54:55 +0300 Received: from gothmog.pc (gothmog [127.0.0.1]) by gothmog.pc (8.13.6/8.13.6) with ESMTP id k42Ht2Qi040631; Tue, 2 May 2006 20:55:02 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from giorgos@localhost) by gothmog.pc (8.13.6/8.13.6/Submit) id k42Ht25R040630; Tue, 2 May 2006 20:55:02 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Tue, 2 May 2006 20:55:02 +0300 From: Giorgos Keramidas To: joaoBR Message-ID: <20060502175502.GA31993@gothmog.pc> References: <200605011604.26507.mi+mx@aldan.algebra.com> <20060501212539.GA24193@regurgitate.ugcs.caltech.edu> <4456C439.1070500@samsco.org> <4456E860.8090308@samsco.org> <20060502163204.GB31236@soaustin.net> <4457928F.60805@matik.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4457928F.60805@matik.com.br> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (score=-3.396, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.80, BAYES_00 -2.60, DNS_FROM_RFC_ABUSE 0.20) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: Mark Linimon , current@freebsd.org Subject: Re: cc can't build 32-bit executables on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2006 17:55:44 -0000 On 2006-05-02 14:10, joaoBR wrote: >Mark Linimon wrote: >> Even the most cursory review of GNATS will reveal that there are >> bugs in every release. Even if we were a professional, rather than >> almost-all- volunteer, organization, this would _still_ be true. >> This is true of all software, not just FreeBSD. > > well,that is a really nice quote A wise quote too. Mark obviously knows what he is talking about. It took me the better part of ten years to realise the truth in what Mark wrote :-) From owner-freebsd-current@FreeBSD.ORG Tue May 2 19:12:42 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9EAD116A894 for ; Tue, 2 May 2006 19:12:42 +0000 (UTC) (envelope-from darren.pilgrim@bitfreak.org) Received: from mail.bitfreak.org (mail.bitfreak.org [65.75.198.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57CA343D55 for ; Tue, 2 May 2006 19:12:42 +0000 (GMT) (envelope-from darren.pilgrim@bitfreak.org) Received: from [127.0.0.1] (mail.bitfreak.org [65.75.198.146]) by mail.bitfreak.org (Postfix) with ESMTP id 5793519F40; Tue, 2 May 2006 12:12:41 -0700 (PDT) Message-ID: <4457AF26.3070205@bitfreak.org> Date: Tue, 02 May 2006 12:12:38 -0700 From: Darren Pilgrim User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Peter Klett References: <200605021610.12599.peter@netkey.at> In-Reply-To: <200605021610.12599.peter@netkey.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: DRI seems to bee broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2006 19:12:42 -0000 Peter Klett wrote: > Hello CURRENT, > > my system has been cvsup'd yesterday, world is approx. 4 weeks old, kernel was > compiled yesterday. When I try to start X (xorg 6.9.0) my screen gets dark > and Xorg uses up to 100% cpu. Pressing any key just don't help at all. I can > log into my box via ssh but cannot kill the process. > > If I comment out the module "dri" entry in xorg.conf everything works > again :-) > > An old kernel (1 month old) works with the dri setting. Could it just be > because world and kernel are out of sync ? Probably. Running a kernel and world from seperate source tree revisions is so problematic that the very first thing anyone will tell you is to sync your kernel and world, regardless of the question you asked. You can (sometimes) get away with it on an errata branch, but across release versions, on -STABLE and on -CURRENT, you're begging for an automatic podiatric firearm actuator device. From owner-freebsd-current@FreeBSD.ORG Tue May 2 20:18:55 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA86D16A476 for ; Tue, 2 May 2006 20:18:55 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7132F43D45 for ; Tue, 2 May 2006 20:18:47 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 8C2D16FD; Tue, 2 May 2006 15:18:47 -0500 (CDT) Date: Tue, 2 May 2006 15:18:47 -0500 To: Giorgos Keramidas Message-ID: <20060502201847.GA7449@soaustin.net> References: <200605011604.26507.mi+mx@aldan.algebra.com> <20060501212539.GA24193@regurgitate.ugcs.caltech.edu> <4456C439.1070500@samsco.org> <4456E860.8090308@samsco.org> <20060502163204.GB31236@soaustin.net> <4457928F.60805@matik.com.br> <20060502175502.GA31993@gothmog.pc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060502175502.GA31993@gothmog.pc> User-Agent: Mutt/1.5.9i From: linimon@lonesome.com (Mark Linimon) X-Mailman-Approved-At: Tue, 02 May 2006 20:31:11 +0000 Cc: Mark Linimon , joaoBR , current@freebsd.org Subject: Re: cc can't build 32-bit executables on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2006 20:18:55 -0000 On Tue, May 02, 2006 at 08:55:02PM +0300, Giorgos Keramidas wrote: > A wise quote too. Mark obviously knows what he is talking about. > It took me the better part of ten years to realise the truth in what > Mark wrote :-) Remember, I've been doing this for a _lot_ longer than 10 years :-) It took me quite a while to learn it, and even that was on embedded systems where the code was much smaller and centrally controlled than an entire OS plus utilities plus applications. The problem space was orders of magnitude smaller, and the code only needed to run on one piece of hardware. Even so, there was always something else that was broken ... mcl From owner-freebsd-current@FreeBSD.ORG Tue May 2 20:53:44 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0745016A43D for ; Tue, 2 May 2006 20:53:44 +0000 (UTC) (envelope-from jd@ugcs.caltech.edu) Received: from regurgitate.ugcs.caltech.edu (regurgitate.ugcs.caltech.edu [131.215.176.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5B6243D48 for ; Tue, 2 May 2006 20:53:43 +0000 (GMT) (envelope-from jd@ugcs.caltech.edu) Received: by regurgitate.ugcs.caltech.edu (Postfix, from userid 3640) id 38E1CE8AC; Tue, 2 May 2006 13:53:43 -0700 (PDT) Date: Tue, 2 May 2006 13:53:43 -0700 From: Paul Allen To: Mark Linimon Message-ID: <20060502205343.GA28259@regurgitate.ugcs.caltech.edu> References: <200605011604.26507.mi+mx@aldan.algebra.com> <20060501212539.GA24193@regurgitate.ugcs.caltech.edu> <4456C439.1070500@samsco.org> <4456E860.8090308@samsco.org> <20060502163204.GB31236@soaustin.net> <4457928F.60805@matik.com.br> <20060502175502.GA31993@gothmog.pc> <20060502201847.GA7449@soaustin.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060502201847.GA7449@soaustin.net> Sender: jd@ugcs.caltech.edu Cc: Giorgos Keramidas , joaoBR , current@freebsd.org Subject: Re: cc can't build 32-bit executables on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2006 20:53:44 -0000 > It took me quite a while to learn it, and even that was on embedded systems > where the code was much smaller and centrally controlled than an entire OS > plus utilities plus applications. The problem space was orders of magnitude > smaller, and the code only needed to run on one piece of hardware. Even so, > there was always something else that was broken ... Yes... usually things "work" not because they do what you intended but often because of some unusual unplanned property. e.g., the size of types happens to just work out. This shouldn't be surprising. Write a bunch of code... it has many errors in it. Stochastically fix them until it works. It goes a long way to demonstrating how biological evolution works. Luckily hardware designers take a more rigorous approach, but then again an ECO could cost hundreds of thousands of dollars--if not millions. Paul From owner-freebsd-current@FreeBSD.ORG Tue May 2 21:42:05 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C10D516A400 for ; Tue, 2 May 2006 21:42:05 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8852143D62 for ; Tue, 2 May 2006 21:42:01 +0000 (GMT) (envelope-from joao@matik.com.br) Received: from anb (anb.matik.com.br [200.152.83.34]) by msrv.matik.com.br (8.13.6/8.13.1) with ESMTP id k42Lf8wj023991; Tue, 2 May 2006 18:41:08 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR To: freebsd-current@freebsd.org Date: Tue, 2 May 2006 18:41:55 -0300 User-Agent: KMail/1.9.1 References: <200605011604.26507.mi+mx@aldan.algebra.com> <20060502201847.GA7449@soaustin.net> <20060502205343.GA28259@regurgitate.ugcs.caltech.edu> In-Reply-To: <20060502205343.GA28259@regurgitate.ugcs.caltech.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200605021841.55832.joao@matik.com.br> X-Filter-Version: 1.11a (msrv.matik.com.br) X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on msrv.matik.com.br X-Virus-Status: Clean Cc: Paul Allen Subject: Re: cc can't build 32-bit executables on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2006 21:42:05 -0000 On Tuesday 02 May 2006 17:53, Paul Allen wrote: > > This shouldn't be surprising. Write a bunch of code... it has many errors > in it. Stochastically fix them until it works. It goes a long way to > demonstrating how biological evolution works. > hey, are you tryin to say the code is written by monkeys?=20 Otherwise I think it could be of interest explaining this "biological=20 evolution of software" ... sounds dangerous :S Jo=E3o=20 A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-current@FreeBSD.ORG Wed May 3 00:52:00 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9759C16A40A for ; Wed, 3 May 2006 00:52:00 +0000 (UTC) (envelope-from peter@netkey.at) Received: from xena.netkey.at (ns.netkey.at [83.64.50.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2601243D49 for ; Wed, 3 May 2006 00:51:59 +0000 (GMT) (envelope-from peter@netkey.at) Received: from localhost (localhost [127.0.0.1]) by xena.netkey.at (Postfix) with ESMTP id 728F4116; Wed, 3 May 2006 02:51:56 +0200 (CEST) Received: from xena.netkey.at ([127.0.0.1]) by localhost (xena.netkey.at [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 16983-03-3; Wed, 3 May 2006 02:51:45 +0200 (CEST) Received: from [192.168.0.6] (chello062178207215.8.15.tuwien.teleweb.at [62.178.207.215]) by xena.netkey.at (Postfix) with ESMTP id 19359AB; Wed, 3 May 2006 02:51:45 +0200 (CEST) From: Peter Klett Organization: netkey information technology gesmbh To: Darren Pilgrim Date: Wed, 3 May 2006 02:51:43 +0200 User-Agent: KMail/1.9.1 References: <200605021610.12599.peter@netkey.at> <4457AF26.3070205@bitfreak.org> In-Reply-To: <4457AF26.3070205@bitfreak.org> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200605030251.43979.peter@netkey.at> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at xena.netkey.at Cc: freebsd-current@freebsd.org Subject: Re: DRI seems to bee broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2006 00:52:00 -0000 On Tuesday 02 May 2006 21:12, Darren Pilgrim wrote: > you're begging for > an automatic podiatric firearm actuator device. Ok, I made a cvsup, world and kernel, rebooted and tried again, same problem. I got no error messages in the logs, the Xorg just hangs. I tried to debug via ssh, but gdb could not attach. # uname -a FreeBSD schlepptop.home 7.0-CURRENT FreeBSD 7.0-CURRENT #11: Wed May 3 03:49:37 CEST 2006 root@:/usr/obj/usr/src/sys/SCHLEPPTOP_CURRENT i386 part of my xorg.conf: ---SNIP--- Section "DRI" Mode 0666 EndSection Section "Module" Load "dbe" Load "dri" Load "extmod" Load "glx" Load "record" Load "xtrap" Load "freetype" Load "type1" EndSection ---SNIP--- As stated before does it work if I comment out the Load "dri" line. Can I provide you with more infomation/configs ? Greetings Peter From owner-freebsd-current@FreeBSD.ORG Wed May 3 01:10:18 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AEF7816A403 for ; Wed, 3 May 2006 01:10:18 +0000 (UTC) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FE7F43D49 for ; Wed, 3 May 2006 01:10:18 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (localhost [127.0.0.1]) by lexi.siliconlandmark.com (8.13.3/8.13.3) with ESMTP id k431AAqk043388; Tue, 2 May 2006 21:10:10 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost) by lexi.siliconlandmark.com (8.13.3/8.13.3/Submit) with ESMTP id k431AATx043385; Tue, 2 May 2006 21:10:10 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Tue, 2 May 2006 21:10:10 -0400 (EDT) From: Andre Guibert de Bruet To: Peter Klett In-Reply-To: <200605030251.43979.peter@netkey.at> Message-ID: <20060502210605.C43100@lexi.siliconlandmark.com> References: <200605021610.12599.peter@netkey.at> <4457AF26.3070205@bitfreak.org> <200605030251.43979.peter@netkey.at> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Information: Please contact the ISP for more information X-SL-MailScanner: Found to be clean X-SL-SpamCheck: not spam, SpamAssassin (score=-2.59, required 6, autolearn=not spam, AWL 0.01, BAYES_00 -2.60) X-MailScanner-From: andy@siliconlandmark.com Cc: freebsd-current@freebsd.org Subject: Re: DRI seems to bee broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2006 01:10:19 -0000 On Wed, 3 May 2006, Peter Klett wrote: > On Tuesday 02 May 2006 21:12, Darren Pilgrim wrote: >> you're begging for >> an automatic podiatric firearm actuator device. > > Ok, I made a cvsup, world and kernel, rebooted and tried again, same problem. > I got no error messages in the logs, the Xorg just hangs. I tried to debug via > ssh, but gdb could not attach. > > # uname -a > FreeBSD schlepptop.home 7.0-CURRENT FreeBSD 7.0-CURRENT #11: Wed May 3 > 03:49:37 CEST 2006 root@:/usr/obj/usr/src/sys/SCHLEPPTOP_CURRENT i386 > > part of my xorg.conf: > > ---SNIP--- > Section "DRI" > Mode 0666 > EndSection > > Section "Module" > Load "dbe" > Load "dri" > Load "extmod" > Load "glx" > Load "record" > Load "xtrap" > Load "freetype" > Load "type1" > EndSection > > ---SNIP--- > > As stated before does it work if I comment out the Load "dri" line. > > Can I provide you with more infomation/configs ? Just out of curiosity, what kind of video card are you using? Also, are you compiling dri support into your kernel or using a kld? Andy /* Andre Guibert de Bruet * 6f43 6564 7020 656f 2e74 4220 7469 6a20 */ /* Code poet / Sysadmin * 636f 656b 2e79 5320 7379 6461 696d 2e6e */ /* GSM: +1 734 846 8758 * 5520 494e 2058 6c73 7565 6874 002e 0000 */ /* WWW: siliconlandmark.com * Tormenting bytes since 1980. */ From owner-freebsd-current@FreeBSD.ORG Wed May 3 01:13:26 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6FB3516A402 for ; Wed, 3 May 2006 01:13:26 +0000 (UTC) (envelope-from darren.pilgrim@bitfreak.org) Received: from mail.bitfreak.org (mail.bitfreak.org [65.75.198.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDDBD43D6D for ; Wed, 3 May 2006 01:13:23 +0000 (GMT) (envelope-from darren.pilgrim@bitfreak.org) Received: from [127.0.0.1] (mail.bitfreak.org [65.75.198.146]) by mail.bitfreak.org (Postfix) with ESMTP id 824B619F40; Tue, 2 May 2006 18:13:22 -0700 (PDT) Message-ID: <445803AE.2050700@bitfreak.org> Date: Tue, 02 May 2006 18:13:18 -0700 From: Darren Pilgrim User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Peter Klett References: <200605021610.12599.peter@netkey.at> <4457AF26.3070205@bitfreak.org> <200605030251.43979.peter@netkey.at> In-Reply-To: <200605030251.43979.peter@netkey.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: DRI seems to bee broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2006 01:13:26 -0000 Peter Klett wrote: > On Tuesday 02 May 2006 21:12, Darren Pilgrim wrote: >> you're begging for >> an automatic podiatric firearm actuator device. > > Ok, I made a cvsup, world and kernel, rebooted and tried again, same problem. Did you go through the entire source upgrade process? The entire upgrade process being: 1: cvsup src 2: Read UPDATING and do any extra steps it may indicate. 3: Verify that your kernel config is still correct. 4: /usr/src/usr.sbin/mergemaster/mergemaster.sh -p 5: make buildworld 6: make buildkernel 7: make installkernel 8: reboot to single user mode 9: make installworld 10: mergemaster 11: reboot > Can I provide you with more infomation/configs ? dmesg, pciconf -vl, kernel config, your complete xorg.conf and the Xorg log file from the last run. From owner-freebsd-current@FreeBSD.ORG Wed May 3 09:46:39 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7EC1316A405 for ; Wed, 3 May 2006 09:46:39 +0000 (UTC) (envelope-from peter@netkey.at) Received: from xena.netkey.at (ns.netkey.at [83.64.50.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5841E43D5A for ; Wed, 3 May 2006 09:46:34 +0000 (GMT) (envelope-from peter@netkey.at) Received: from localhost (localhost [127.0.0.1]) by xena.netkey.at (Postfix) with ESMTP id E0006348; Wed, 3 May 2006 11:46:32 +0200 (CEST) Received: from xena.netkey.at ([127.0.0.1]) by localhost (xena.netkey.at [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 21793-01; Wed, 3 May 2006 11:46:23 +0200 (CEST) Received: from [192.168.0.244] (83-64-50-177.hietzing.xdsl-line.inode.at [83.64.50.177]) by xena.netkey.at (Postfix) with ESMTP id 6258C1B9; Wed, 3 May 2006 11:46:23 +0200 (CEST) From: Peter Klett Organization: netkey information technology gesmbh To: Darren Pilgrim Date: Wed, 3 May 2006 11:46:21 +0200 User-Agent: KMail/1.9.1 References: <200605021610.12599.peter@netkey.at> <200605030251.43979.peter@netkey.at> <445803AE.2050700@bitfreak.org> In-Reply-To: <445803AE.2050700@bitfreak.org> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_uvHWEZ49B9wtnhP" Message-Id: <200605031146.22340.peter@netkey.at> X-Virus-Scanned: by amavisd-new at xena.netkey.at X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: DRI seems to bee broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2006 09:46:40 -0000 --Boundary-00=_uvHWEZ49B9wtnhP Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Wednesday 03 May 2006 03:13, Darren Pilgrim wrote: > Did you go through the entire source upgrade process? The entire > upgrade process being: > > 1: cvsup src # cd /usr/src # make update > 2: Read UPDATING and do any extra steps it may indicate. not really I must confess, as you can see in my make.conf, I still haven't put the NO_XXX in src.conf (and translated them to WITHOUT_XXX knobs) The lastest entry in my UPDATING is from 20060317. > 3: Verify that your kernel config is still correct. Hoped that, how can I verify that ? > 4: /usr/src/usr.sbin/mergemaster/mergemaster.sh -p > 5: make buildworld > 6: make buildkernel > 7: make installkernel > 8: reboot to single user mode > 9: make installworld > 10: mergemaster > 11: reboot Actually I rebooted into single user mode, after make upate, then # make buildworld # make kernel # mergemaster -p (probably in /usr/sbin) # make installworld # mergemaster # reboot > dmesg, pciconf -vl, kernel config, your complete xorg.conf and the Xorg > log file from the last run. attached hth Peter --Boundary-00=_uvHWEZ49B9wtnhP Content-Type: text/plain; charset="iso-8859-1"; name="dmesg" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dmesg" May 3 11:23:06 schlepptop syslogd: kernel boot file is /boot/kernel/kernel May 3 11:23:06 schlepptop kernel: Copyright (c) 1992-2006 The FreeBSD Project. May 3 11:23:06 schlepptop kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 May 3 11:23:06 schlepptop kernel: The Regents of the University of California. All rights reserved. May 3 11:23:06 schlepptop kernel: FreeBSD 7.0-CURRENT #11: Wed May 3 03:49:37 CEST 2006 May 3 11:23:06 schlepptop kernel: root@:/usr/obj/usr/src/sys/SCHLEPPTOP_CURRENT May 3 11:23:06 schlepptop kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 May 3 11:23:06 schlepptop kernel: CPU: Intel(R) Pentium(R) M processor 1.60GHz (1596.05-MHz 686-class CPU) May 3 11:23:06 schlepptop kernel: Origin = "GenuineIntel" Id = 0x6d8 Stepping = 8 May 3 11:23:06 schlepptop kernel: Features=0xafe9fbff May 3 11:23:06 schlepptop kernel: Features2=0x180 May 3 11:23:06 schlepptop kernel: AMD Features=0x100000 May 3 11:23:06 schlepptop kernel: real memory = 535429120 (510 MB) May 3 11:23:06 schlepptop kernel: avail memory = 514539520 (490 MB) May 3 11:23:06 schlepptop kernel: acpi0: on motherboard May 3 11:23:06 schlepptop kernel: acpi_bus_number: can't get _ADR May 3 11:23:06 schlepptop last message repeated 9 times May 3 11:23:06 schlepptop kernel: acpi0: Power Button (fixed) May 3 11:23:06 schlepptop kernel: acpi_bus_number: can't get _ADR May 3 11:23:06 schlepptop kernel: acpi_bus_number: can't get _ADR May 3 11:23:06 schlepptop kernel: acpi_ec0: port 0x62,0x66 on acpi0 May 3 11:23:06 schlepptop kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 May 3 11:23:06 schlepptop kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 May 3 11:23:06 schlepptop kernel: cpu0: on acpi0 May 3 11:23:06 schlepptop kernel: est0: on cpu0 May 3 11:23:06 schlepptop kernel: p4tcc0: on cpu0 May 3 11:23:06 schlepptop kernel: acpi_acad0: on acpi0 May 3 11:23:06 schlepptop kernel: battery0: on acpi0 May 3 11:23:06 schlepptop kernel: acpi_lid0: on acpi0 May 3 11:23:06 schlepptop kernel: acpi_button0: on acpi0 May 3 11:23:06 schlepptop kernel: acpi_button1: on acpi0 May 3 11:23:06 schlepptop kernel: pcib0: port 0xcf8-0xcff on acpi0 May 3 11:23:06 schlepptop kernel: pci0: on pcib0 May 3 11:23:06 schlepptop kernel: pcib1: irq 11 at device 1.0 on pci0 May 3 11:23:06 schlepptop kernel: pci1: on pcib1 May 3 11:23:06 schlepptop kernel: vgapci0: port 0x3000-0x30ff mem 0xd0000000-0xd7ffffff,0xc0100000-0xc010ffff irq 11 at device 0.0 on pci1 May 3 11:23:06 schlepptop kernel: drm0: on vgapci0 May 3 11:23:06 schlepptop kernel: info: [drm] Initialized radeon 1.24.0 20060225 May 3 11:23:06 schlepptop kernel: pcib2: irq 10 at device 28.0 on pci0 May 3 11:23:06 schlepptop kernel: pci2: on pcib2 May 3 11:23:06 schlepptop kernel: uhci0: port 0x1800-0x181f irq 5 at device 29.0 on pci0 May 3 11:23:06 schlepptop kernel: uhci0: [GIANT-LOCKED] May 3 11:23:06 schlepptop kernel: usb0: on uhci0 May 3 11:23:06 schlepptop kernel: usb0: USB revision 1.0 May 3 11:23:06 schlepptop kernel: uhub0: on usb0 May 3 11:23:06 schlepptop kernel: uhub0: 2 ports with 2 removable, self powered May 3 11:23:06 schlepptop kernel: uhci1: port 0x1820-0x183f irq 5 at device 29.1 on pci0 May 3 11:23:06 schlepptop kernel: uhci1: [GIANT-LOCKED] May 3 11:23:06 schlepptop kernel: usb1: on uhci1 May 3 11:23:06 schlepptop kernel: usb1: USB revision 1.0 May 3 11:23:06 schlepptop kernel: uhub1: on usb1 May 3 11:23:06 schlepptop kernel: uhub1: 2 ports with 2 removable, self powered May 3 11:23:06 schlepptop kernel: uhci2: port 0x1840-0x185f irq 5 at device 29.2 on pci0 May 3 11:23:06 schlepptop kernel: uhci2: [GIANT-LOCKED] May 3 11:23:06 schlepptop kernel: usb2: on uhci2 May 3 11:23:06 schlepptop kernel: usb2: USB revision 1.0 May 3 11:23:06 schlepptop kernel: uhub2: on usb2 May 3 11:23:06 schlepptop kernel: uhub2: 2 ports with 2 removable, self powered May 3 11:23:06 schlepptop kernel: uhci3: port 0x1860-0x187f irq 11 at device 29.3 on pci0 May 3 11:23:06 schlepptop kernel: uhci3: [GIANT-LOCKED] May 3 11:23:06 schlepptop kernel: usb3: on uhci3 May 3 11:23:06 schlepptop kernel: usb3: USB revision 1.0 May 3 11:23:06 schlepptop kernel: uhub3: on usb3 May 3 11:23:06 schlepptop kernel: uhub3: 2 ports with 2 removable, self powered May 3 11:23:06 schlepptop kernel: ehci0: mem 0xc0000000-0xc00003ff irq 5 at device 29.7 on pci0 May 3 11:23:06 schlepptop kernel: ehci0: [GIANT-LOCKED] May 3 11:23:06 schlepptop kernel: usb4: EHCI version 1.0 May 3 11:23:06 schlepptop kernel: usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 May 3 11:23:06 schlepptop kernel: usb4: on ehci0 May 3 11:23:06 schlepptop kernel: usb4: USB revision 2.0 May 3 11:23:06 schlepptop kernel: uhub4: on usb4 May 3 11:23:06 schlepptop kernel: uhub4: 8 ports with 8 removable, self powered May 3 11:23:06 schlepptop kernel: pcib3: at device 30.0 on pci0 May 3 11:23:06 schlepptop kernel: pci6: on pcib3 May 3 11:23:06 schlepptop kernel: bge0: mem 0xc8000000-0xc800ffff irq 5 at device 5.0 on pci6 May 3 11:23:06 schlepptop kernel: miibus0: on bge0 May 3 11:23:06 schlepptop kernel: brgphy0: on miibus0 May 3 11:23:06 schlepptop kernel: brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto May 3 11:23:06 schlepptop kernel: bge0: Ethernet address: 00:13:77:01:05:c2 May 3 11:23:06 schlepptop kernel: iwi0: mem 0xc8010000-0xc8010fff irq 11 at device 7.0 on pci6 May 3 11:23:06 schlepptop kernel: iwi0: Ethernet address: 00:12:f0:1d:96:b5 May 3 11:23:06 schlepptop kernel: cbb0: at device 9.0 on pci6 May 3 11:23:06 schlepptop kernel: cardbus0: on cbb0 May 3 11:23:06 schlepptop kernel: pccard0: <16-bit PCCard bus> on cbb0 May 3 11:23:06 schlepptop kernel: fwohci0: mem 0xc8011000-0xc80117ff at device 9.1 on pci6 May 3 11:23:06 schlepptop kernel: fwohci0: OHCI version 1.0 (ROM=1) May 3 11:23:06 schlepptop kernel: fwohci0: No. of Isochronous channels is 4. May 3 11:23:06 schlepptop kernel: fwohci0: EUI64 00:00:f0:41:20:04:66:bd May 3 11:23:06 schlepptop kernel: fwohci0: Phy 1394a available S400, 2 ports. May 3 11:23:06 schlepptop kernel: fwohci0: Link S400, max_rec 2048 bytes. May 3 11:23:06 schlepptop kernel: firewire0: on fwohci0 May 3 11:23:06 schlepptop kernel: sbp0: on firewire0 May 3 11:23:06 schlepptop kernel: fwe0: on firewire0 May 3 11:23:06 schlepptop kernel: if_fwe0: Fake Ethernet address: 02:00:f0:04:66:bd May 3 11:23:06 schlepptop kernel: fwe0: Ethernet address: 02:00:f0:04:66:bd May 3 11:23:06 schlepptop kernel: fwe0: if_start running deferred for Giant May 3 11:23:06 schlepptop kernel: fwohci0: Initiate bus reset May 3 11:23:06 schlepptop kernel: fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode May 3 11:23:06 schlepptop kernel: firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) May 3 11:23:06 schlepptop kernel: firewire0: bus manager 0 (me) May 3 11:23:06 schlepptop kernel: pci6: at device 9.2 (no driver attached) May 3 11:23:06 schlepptop kernel: pci6: at device 9.3 (no driver attached) May 3 11:23:06 schlepptop kernel: pcm0: port 0x1c00-0x1cff,0x1880-0x18bf mem 0xc0000800-0xc00009ff,0xc0000400-0xc00004ff irq 10 at device 30.2 on pci0 May 3 11:23:06 schlepptop kernel: pcm0: May 3 11:23:06 schlepptop kernel: pci0: at device 30.3 (no driver attached) May 3 11:23:06 schlepptop kernel: isab0: at device 31.0 on pci0 May 3 11:23:06 schlepptop kernel: isa0: on isab0 May 3 11:23:06 schlepptop kernel: atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x18c0-0x18cf at device 31.1 on pci0 May 3 11:23:06 schlepptop kernel: ata0: on atapci0 May 3 11:23:06 schlepptop kernel: ata1: on atapci0 May 3 11:23:06 schlepptop kernel: pci0: at device 31.3 (no driver attached) May 3 11:23:06 schlepptop kernel: acpi_tz0: on acpi0 May 3 11:23:06 schlepptop kernel: acpi_hpet0: iomem 0xfed00000-0xfed003ff irq 0,8 on acpi0 May 3 11:23:06 schlepptop kernel: acpi_hpet0: Vendor: 0x8086 May 3 11:23:06 schlepptop kernel: acpi_hpet0: Leg_Route_Cap: 1 May 3 11:23:06 schlepptop kernel: acpi_hpet0: Count_Size_Cap: 1 May 3 11:23:06 schlepptop kernel: acpi_hpet0: Num_Tim_Cap: 1 May 3 11:23:06 schlepptop kernel: acpi_hpet0: Rev_id: 0x1 May 3 11:23:06 schlepptop kernel: acpi_hpet0: Period: 69841279 fs (14318180 Hz) May 3 11:23:06 schlepptop kernel: acpi_hpet0: HPET attach May 3 11:23:06 schlepptop kernel: atkbdc0: port 0x60,0x64 irq 1 on acpi0 May 3 11:23:06 schlepptop kernel: atkbd0: irq 1 on atkbdc0 May 3 11:23:06 schlepptop kernel: kbd0 at atkbd0 May 3 11:23:06 schlepptop kernel: atkbd0: [GIANT-LOCKED] May 3 11:23:06 schlepptop kernel: psm0: irq 12 on atkbdc0 May 3 11:23:06 schlepptop kernel: psm0: [GIANT-LOCKED] May 3 11:23:06 schlepptop kernel: psm0: model IntelliMouse, device ID 3 May 3 11:23:06 schlepptop kernel: pmtimer0 on isa0 May 3 11:23:06 schlepptop kernel: orm0: at iomem 0xc0000-0xcffff,0xd0000-0xd3fff,0xdc000-0xdffff,0xe0000-0xe3fff pnpid ORM0000 on isa0 May 3 11:23:06 schlepptop kernel: sc0: at flags 0x100 on isa0 May 3 11:23:06 schlepptop kernel: sc0: VGA <16 virtual consoles, flags=0x300> May 3 11:23:06 schlepptop kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 May 3 11:23:06 schlepptop kernel: ums0: on uhub0 May 3 11:23:06 schlepptop kernel: ums0: 3 buttons and Z dir. May 3 11:23:06 schlepptop kernel: Timecounter "TSC" frequency 1596051492 Hz quality 800 May 3 11:23:06 schlepptop kernel: Timecounters tick every 3.333 msec May 3 11:23:06 schlepptop kernel: acpi_acad0: acline initialization start May 3 11:23:06 schlepptop kernel: acpi_acad0: On Line May 3 11:23:06 schlepptop kernel: acpi_acad0: acline initialibattery0: battery initialization start May 3 11:23:06 schlepptop kernel: zation done, tried 1 times May 3 11:23:06 schlepptop kernel: battery0: battery initialization done, tried 1 times May 3 11:23:06 schlepptop kernel: ad0: 56713MB at ata0-master UDMA100 May 3 11:23:06 schlepptop kernel: acd0: DVDR at ata0-slave UDMA33 May 3 11:23:06 schlepptop kernel: cd0 at ata0 bus 0 target 1 lun 0 May 3 11:23:06 schlepptop kernel: cd0: Removable CD-ROM SCSI-0 device May 3 11:23:06 schlepptop kernel: cd0: 33.000MB/s transfers May 3 11:23:06 schlepptop kernel: cd0: cd present [1 x 2048 byte records] May 3 11:23:06 schlepptop kernel: Trying to mount root from ufs:/dev/ad0s2a May 3 11:23:06 schlepptop savecore: no dumps found May 3 11:23:09 schlepptop ntpd: logging to file /var/log/ntpd.log May 3 11:26:53 schlepptop kernel: info: [drm] Setting GART location based on old memory map May 3 11:26:53 schlepptop kernel: info: [drm] Loading R300 Microcode May 3 11:26:53 schlepptop kernel: info: [drm] writeback test failed May 3 11:27:00 schlepptop kernel: stray irq7 May 3 11:27:25 schlepptop last message repeated 3 times May 3 11:27:29 schlepptop kernel: too many stray irq 7's: not logging anymore --Boundary-00=_uvHWEZ49B9wtnhP Content-Type: text/plain; charset="iso-8859-1"; name="SCHLEPPTOP_CURRENT" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="SCHLEPPTOP_CURRENT" # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.432 2005/08/06 23:05:48 davidxu Exp $ machine i386 #cpu I486_CPU #cpu I586_CPU cpu I686_CPU ident SCHLEPPTOP_CURRENT # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. #makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_ULE # ULE scheduler #options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories #options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server #options NFS_ROOT # NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options MSDOSFS_LARGE # > 128 GB options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_GPT # GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev #options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. #options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. options ADAPTIVE_GIANT # Giant mutex is adaptive. options HZ=300 # altq(9). Enable the base part of the hooks with the ALTQ option. # Individual disciplines must be built into the base system and can not be # loaded as modules at this point. ALTQ requires a stable TSC so if yours is # broken or changes with CPU throttling then you must also have the ALTQ_NOPCC # option. options ALTQ options ALTQ_CBQ # Class Bases Queueing options ALTQ_RED # Random Early Detection options ALTQ_RIO # RED In/Out options ALTQ_HFSC # Hierarchical Packet Scheduler options ALTQ_CDNR # Traffic conditioner options ALTQ_PRIQ # Priority Queueing options ALTQ_NOPCC # Required if the TSC is unusable #options ALTQ_DEBUG # Debugging for use in -current #options KDB # Enable kernel debugger support. #options DDB # Support DDB. #options GDB # Support remote GDB. #options INVARIANTS # Enable calls of extra sanity checking #options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS #options WITNESS # Enable checks to detect deadlocks and cycles #options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed # To make an SMP kernel, the next two lines are needed #options SMP # Symmetric MultiProcessor Kernel #device apic # I/O APIC # Bus support. Do not remove isa, even if you have no isa slots device isa device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives device atapicam # emulate ATAPI devices as SCSI ditto via CAM options ATA_STATIC_ID # Static device numbering # DRM device drm # DRM core module required by DRM drivers device radeondrm # ATI Radeon # SCSI Controllers #device ahb # EISA AHA1742 family #device ahc # AHA2940 and onboard AIC7xxx devices #device ahd # AHA39320/29320 and onboard AIC79xx devices #device amd # AMD 53C974 (Tekram DC-390(T)) #device isp # Qlogic family #device ispfw # Firmware for QLogic HBAs- normally a module #device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic #device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') #device trm # Tekram DC395U/UW/F DC315U adapters #device adv # Advansys SCSI adapters #device adw # Advansys wide SCSI adapters #device aha # Adaptec 154x SCSI adapters #device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. #device bt # Buslogic/Mylex MultiMaster SCSI adapters #device ncv # NCR 53C500 #device nsp # Workbit Ninja SCSI-3 #device stg # TMC 18C30/18C50 # SCSI peripherals device scbus # SCSI bus (required for SCSI) #device ch # SCSI media changers device da # Direct Access (disks) #device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem #device amr # AMI MegaRAID #device arcmsr # Areca SATA II RAID #device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID #device ciss # Compaq Smart RAID 5* #device dpt # DPT Smartcache III, IV - See NOTES for options #device hptmv # Highpoint RocketRAID 182x #device iir # Intel Integrated RAID #device ips # IBM (Adaptec) ServeRAID #device mly # Mylex AcceleRAID/eXtremeRAID #device twa # 3ware 9000 series PATA/SATA RAID # RAID controllers #device aac # Adaptec FSA RAID #device aacp # SCSI passthrough for aac (requires CAM) #device ida # Compaq Smart RAID #device mlx # Mylex DAC960 family #device pst # Promise Supertrak SX6000 #device twe # 3ware ATA RAID # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc # Enable this for the pcvt (VT220 compatible) console driver #device vt #options XSERVER # support for X server on a vt console #options FAT_CURSOR # start with block cursor device agp # support several AGP chipsets # To include support for VGA VESA video modes options VESA # Turn on extra debugging checks and output for VESA support. options VESA_DEBUG # Floating point support - do not disable. device npx # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. device pmtimer # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support device cbb # cardbus (yenta) bridge device pccard # PC Card (16-bit) bus device cardbus # CardBus (32-bit) bus # Serial (COM) ports #device sio # 8250, 16[45]50 based serial ports # Parallel port #device ppc #device ppbus # Parallel port bus (required) #device lpt # Printer #device plip # TCP/IP over parallel #device ppi # Parallel port interface device #device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to the sio and/or ppc drivers): #device puc # PCI Ethernet NICs. #device de # DEC/Intel DC21x4x (``Tulip'') #device em # Intel PRO/1000 adapter Gigabit Ethernet Card #device ixgb # Intel PRO/10GbE Ethernet Card #device txp # 3Com 3cR990 (``Typhoon'') #device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support #device bfe # Broadcom BCM440x 10/100 Ethernet device bge # Broadcom BCM570xx Gigabit Ethernet #device dc # DEC/Intel 21143 and various workalikes #device fxp # Intel EtherExpress PRO/100B (82557, 82558) #device lge # Level 1 LXT1001 gigabit Ethernet #device nge # NatSemi DP83820 gigabit Ethernet #device nve # nVidia nForce MCP on-board Ethernet Networking #device pcn # AMD Am79C97x PCI 10/100(precedence over 'lnc') #device re # RealTek 8139C+/8169/8169S/8110S #device rl # RealTek 8129/8139 #device sf # Adaptec AIC-6915 (``Starfire'') #device sis # Silicon Integrated Systems SiS 900/SiS 7016 #device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet #device ste # Sundance ST201 (D-Link DFE-550TX) #device ti # Alteon Networks Tigon I/II gigabit Ethernet #device tl # Texas Instruments ThunderLAN #device tx # SMC EtherPower II (83c170 ``EPIC'') #device vge # VIA VT612x gigabit Ethernet #device vr # VIA Rhine, Rhine II #device wb # Winbond W89C840F #device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. pccard NICs included. #device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' #device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards #device ex # Intel EtherExpress Pro/10 and Pro/10+ #device ep # Etherlink III based cards #device fe # Fujitsu MB8696x based cards #device ie # EtherExpress 8/16, 3C507, StarLAN 10 etc. #device lnc # NE2100, NE32-VL Lance Ethernet cards #device sn # SMC's 9000 series of Ethernet chips #device xe # Xircom pccard Ethernet # ISA devices that use the old ISA shims #device le # Wireless NIC cards device wlan # 802.11 support #device an # Aironet 4500/4800 802.11 wireless NICs. #device awi # BayStack 660 and others #device ral # Ralink Technology RT2500 wireless NICs. #device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. #device wl # Older non 802.11 Wavelan wireless NIC. # Pseudo devices. device loop # Network loopback device mem # Memory and kernel memory devices device io # I/O device device random # Entropy device device ether # Ethernet support #device sl # Kernel SLIP #device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse #device ural # Ralink Technology RT2500USB wireless NICs #device urio # Diamond Rio 500 MP3 player device uscanner # Scanners # USB Ethernet, requires miibus #device aue # ADMtek USB Ethernet #device axe # ASIX Electronics USB Ethernet #device cdce # Generic USB over Ethernet #device cue # CATC USB Ethernet #device kue # Kawasaki LSI USB Ethernet #device rue # RealTek RTL8150 USB Ethernet # FireWire support device firewire # FireWire bus code device sbp # SCSI over FireWire (Requires scbus and da) device fwe # Ethernet over FireWire (non-standard!) --Boundary-00=_uvHWEZ49B9wtnhP Content-Type: text/plain; charset="iso-8859-1"; name="xorg.conf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="xorg.conf" Section "ServerLayout" Identifier "X.org Configured" Screen 0 "Screen0" 0 0 InputDevice "Mouse0" "CorePointer" InputDevice "Keyboard0" "CoreKeyboard" EndSection Section "DRI" Mode 0666 EndSection Section "Files" RgbPath "/usr/X11R6/lib/X11/rgb" ModulePath "/usr/X11R6/lib/modules" FontPath "/usr/X11R6/lib/X11/fonts/misc/" FontPath "/usr/X11R6/lib/X11/fonts/TTF/" FontPath "/usr/X11R6/lib/X11/fonts/TrueType/" FontPath "/usr/X11R6/lib/X11/fonts/Type1/" FontPath "/usr/X11R6/lib/X11/fonts/75dpi/" FontPath "/usr/X11R6/lib/X11/fonts/100dpi/" FontPath "/usr/X11R6/lib/X11/fonts/URW/" FontPath "/usr/local/share/fonts/" FontPath "/usr/X11R6/lib/X11/fonts/bitstream-vera/" EndSection Section "Module" Load "dbe" Load "dri" Load "extmod" Load "glx" Load "record" Load "xtrap" Load "freetype" Load "type1" EndSection Section "Extensions" Option "Composite" "Enable" EndSection Section "InputDevice" Identifier "Keyboard0" Driver "kbd" Option "XkbLayout" "de" Option "XkbModel" "pc105" EndSection Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/sysmouse" Option "ZAxisMapping" "4 5" Option "Buttons" "5" EndSection Section "Monitor" Identifier "Monitor0" VendorName "Monitor Vendor" ModelName "Monitor Model" ModeLine "1400x1050minus" 108.00 1400 34208 34320 1688 1050 1052 1055 1063 -HSync -VSync EndSection Section "Device" ### Available Driver options are:- ### Values: : integer, : float, : "True"/"False", ### : "String", : " Hz/kHz/MHz" ### [arg]: arg optional #Option "NoAccel" # [] #Option "SWcursor" # [] #Option "Dac6Bit" # [] #Option "Dac8Bit" # [] #Option "BusType" # [] #Option "CPPIOMode" # [] #Option "CPusecTimeout" # #Option "AGPMode" # #Option "AGPFastWrite" # [] #Option "AGPSize" # #Option "GARTSize" # #Option "RingSize" # #Option "BufferSize" # #Option "EnableDepthMoves" # [] #Option "EnablePageFlip" # [] #Option "NoBackBuffer" # [] #Option "PanelOff" # [] #Option "DDCMode" # [] #Option "MonitorLayout" # [] #Option "IgnoreEDID" # [] #Option "UseFBDev" # [] #Option "VideoKey" # #Option "MergedFB" # [] #Option "CRT2HSync" # [] #Option "CRT2VRefresh" # [] #Option "CRT2Position" # [] #Option "MetaModes" # [] #Option "MergedDPI" # [] #Option "NoMergedXinerama" # [] #Option "MergedXineramaCRT2IsScreen0" # [] #Option "DisplayPriority" # [] #Option "PanelSize" # [] #Option "ForceMinDotClock" # #Option "RenderAccel" # [] #Option "SubPixelOrder" # [] #Option "ShowCache" # [] #Option "DynamicClocks" # [] Identifier "Card0" #Driver "ati" Driver "radeon" VendorName "ATI Technologies Inc" BoardName "Unknown Board" BusID "PCI:1:0:0" EndSection Section "Screen" Identifier "Screen0" Device "Card0" Monitor "Monitor0" SubSection "Display" Viewport 0 0 Depth 1 EndSubSection SubSection "Display" Viewport 0 0 Depth 4 EndSubSection SubSection "Display" Viewport 0 0 Depth 8 EndSubSection SubSection "Display" Viewport 0 0 Depth 15 EndSubSection SubSection "Display" Viewport 0 0 Depth 16 Modes "1400x1050minus" EndSubSection SubSection "Display" Viewport 0 0 Depth 24 Modes "1400x1050minus" EndSubSection EndSection --Boundary-00=_uvHWEZ49B9wtnhP Content-Type: text/plain; charset="iso-8859-1"; name="make.conf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="make.conf" # newline CPUTYPE=pentium-m CFLAGS= -O -pipe NO_NIS=true NO_I4B=true BOOTWAIT=3000 KERNCONF=SCHLEPPTOP_CURRENT SUP_UPDATE=yes SUP=/usr/local/bin/cvsup SUPFLAGS= -g -L 1 SUPHOST=cvsup.at.FreeBSD.org SUPFILE=/usr/local/etc/standard-supfile PORTSSUPFILE=/usr/local/etc/ports-supfile DOCSUPFILE=/usr/local/etc/doc-supfile # added by use.perl 2006-04-10 16:45:28 PERL_VER=5.8.8 PERL_VERSION=5.8.8 --Boundary-00=_uvHWEZ49B9wtnhP-- From owner-freebsd-current@FreeBSD.ORG Wed May 3 09:51:22 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 08A0B16A403 for ; Wed, 3 May 2006 09:51:22 +0000 (UTC) (envelope-from peter@netkey.at) Received: from xena.netkey.at (ns.netkey.at [83.64.50.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B85F43D45 for ; Wed, 3 May 2006 09:51:21 +0000 (GMT) (envelope-from peter@netkey.at) Received: from localhost (localhost [127.0.0.1]) by xena.netkey.at (Postfix) with ESMTP id B1532525; Wed, 3 May 2006 11:51:20 +0200 (CEST) Received: from xena.netkey.at ([127.0.0.1]) by localhost (xena.netkey.at [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 21695-02-3; Wed, 3 May 2006 11:51:15 +0200 (CEST) Received: from [192.168.0.244] (unknown [192.168.0.244]) by xena.netkey.at (Postfix) with ESMTP id 6BA391B9; Wed, 3 May 2006 11:51:15 +0200 (CEST) From: Peter Klett Organization: netkey information technology gesmbh To: Andre Guibert de Bruet Date: Wed, 3 May 2006 11:51:12 +0200 User-Agent: KMail/1.9.1 References: <200605021610.12599.peter@netkey.at> <200605030251.43979.peter@netkey.at> <20060502210605.C43100@lexi.siliconlandmark.com> In-Reply-To: <20060502210605.C43100@lexi.siliconlandmark.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200605031151.12464.peter@netkey.at> X-Virus-Scanned: by amavisd-new at xena.netkey.at Cc: freebsd-current@freebsd.org Subject: Re: DRI seems to bee broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2006 09:51:22 -0000 On Wednesday 03 May 2006 03:10, Andre Guibert de Bruet wrote: > Just out of curiosity, what kind of video card are you using? Also, are > you compiling dri support into your kernel or using a kld? Its a ATI Technologies M24 1P Radeon Mobility X600 in a Samsung X25 Laptop. I have device drm and device radeondrm in my KERNCONF Haven't found a dri option/device in NOTES. Is my config wrong (sent to the list few minutes ago) ? Greetings Peter From owner-freebsd-current@FreeBSD.ORG Wed May 3 10:09:06 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B9AAD16A40A for ; Wed, 3 May 2006 10:09:06 +0000 (UTC) (envelope-from peter@netkey.at) Received: from xena.netkey.at (ns.netkey.at [83.64.50.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4622443D73 for ; Wed, 3 May 2006 10:09:01 +0000 (GMT) (envelope-from peter@netkey.at) Received: from localhost (localhost [127.0.0.1]) by xena.netkey.at (Postfix) with ESMTP id E2B671CC; Wed, 3 May 2006 12:08:59 +0200 (CEST) Received: from xena.netkey.at ([127.0.0.1]) by localhost (xena.netkey.at [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 21695-03-3; Wed, 3 May 2006 12:08:55 +0200 (CEST) Received: from [192.168.0.244] (83-64-50-177.hietzing.xdsl-line.inode.at [83.64.50.177]) by xena.netkey.at (Postfix) with ESMTP id 6228516E; Wed, 3 May 2006 12:08:55 +0200 (CEST) From: Peter Klett Organization: netkey information technology gesmbh To: Darren Pilgrim Date: Wed, 3 May 2006 12:08:54 +0200 User-Agent: KMail/1.9.1 References: <200605021610.12599.peter@netkey.at> <200605030251.43979.peter@netkey.at> <445803AE.2050700@bitfreak.org> In-Reply-To: <445803AE.2050700@bitfreak.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200605031208.54613.peter@netkey.at> X-Virus-Scanned: by amavisd-new at xena.netkey.at Cc: freebsd-current@freebsd.org Subject: Re: DRI seems to bee broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2006 10:09:06 -0000 On Wednesday 03 May 2006 03:13, Darren Pilgrim wrote: > dmesg, pciconf -vl, kernel config, your complete xorg.conf and the Xorg > log file from the last run. seemed I've forgotten the pciconf output or the list removed it, here it is: hostb0@pci0:0:0: class=0x060000 card=0xc018144d chip=0x25908086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82915PM/GM/GMS, 82910GML Host Bridge' class = bridge subclass = HOST-PCI pcib1@pci0:1:0: class=0x060400 card=0x00000088 chip=0x25918086 rev=0x03 hdr=0x01 vendor = 'Intel Corporation' device = '82915PM/GM PCI Express Graphics Port' class = bridge subclass = PCI-PCI pcib2@pci0:28:0: class=0x060400 card=0x00000040 chip=0x26608086 rev=0x03 hdr=0x01 vendor = 'Intel Corporation' device = '82801FB/FR/FW/FRW PCI Express Port 1' class = bridge subclass = PCI-PCI uhci0@pci0:29:0: class=0x0c0300 card=0xc018144d chip=0x26588086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801FB/FR/FW/FRW USB UHCI Controller' class = serial bus subclass = USB uhci1@pci0:29:1: class=0x0c0300 card=0xc018144d chip=0x26598086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801FB/FR/FW/FRW USB UHCI Controller' class = serial bus subclass = USB uhci2@pci0:29:2: class=0x0c0300 card=0xc018144d chip=0x265a8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801FB/FR/FW/FRW USB UHCI Controller' class = serial bus subclass = USB uhci3@pci0:29:3: class=0x0c0300 card=0xc018144d chip=0x265b8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801FB/FR/FW/FRW USB UHCI Controller' class = serial bus subclass = USB ehci0@pci0:29:7: class=0x0c0320 card=0xc018144d chip=0x265c8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801FB/FR/FW/FRW USB 2.0 EHCI Controller' class = serial bus subclass = USB pcib3@pci0:30:0: class=0x060401 card=0x00000050 chip=0x24488086 rev=0xd3 hdr=0x01 vendor = 'Intel Corporation' device = '82801BAM/CAM/DBM (ICH2-M/3-M/4-M) Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI pcm0@pci0:30:2: class=0x040100 card=0xc018144d chip=0x266e8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801FB/FR/FW/FRW AC '97 Audio Controller' class = multimedia subclass = audio none0@pci0:30:3: class=0x070300 card=0x2115144d chip=0x266d8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801FB/FR/FW/FRW AC '97 Modem Controller' class = simple comms subclass = generic modem isab0@pci0:31:0: class=0x060100 card=0xc018144d chip=0x26418086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801FBM ICH6M LPC Interface Bridge' class = bridge subclass = PCI-ISA atapci0@pci0:31:1: class=0x01018a card=0xc018144d chip=0x266f8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801FB/FBM Ultra ATA Storage Controllers - 266F' class = mass storage subclass = ATA none1@pci0:31:3: class=0x0c0500 card=0xc018144d chip=0x266a8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801FB/FR/FW/FRW SMBus Controller' class = serial bus subclass = SMBus vgapci0@pci1:0:0: class=0x030000 card=0xc018144d chip=0x31501002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'M24 1P Radeon Mobility X600' class = display subclass = VGA bge0@pci6:5:0: class=0x020000 card=0xc018144d chip=0x169c14e4 rev=0x03 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM570x Broadcom Gigabit Ethernet BCM570x NetXtreme' class = network subclass = ethernet iwi0@pci6:7:0: class=0x028000 card=0x27318086 chip=0x42208086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/Wireless 2200BG Network Connection' class = network cbb0@pci6:9:0: class=0x060700 card=0xc018144d chip=0x04761180 rev=0xb3 hdr=0x02 vendor = 'Ricoh Co Ltd' device = 'RL5c476 CardBus Controller' class = bridge subclass = PCI-CardBus fwohci0@pci6:9:1: class=0x0c0010 card=0xc018144d chip=0x05521180 rev=0x08 hdr=0x00 vendor = 'Ricoh Co Ltd' device = 'RL5c552 IEEE-1394 Controller' class = serial bus subclass = FireWire none2@pci6:9:2: class=0x080500 card=0xc018144d chip=0x08221180 rev=0x17 hdr=0x00 vendor = 'Ricoh Co Ltd' device = 'SD Bus Host Adapter' class = base peripheral none3@pci6:9:3: class=0x088000 card=0xc018144d chip=0x05921180 rev=0x08 hdr=0x00 vendor = 'Ricoh Co Ltd' device = 'Memory Stick Bus Host Adapter' class = base peripheral Peter From owner-freebsd-current@FreeBSD.ORG Wed May 3 10:26:40 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A2B9316A401 for ; Wed, 3 May 2006 10:26:40 +0000 (UTC) (envelope-from vladgalu@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CD9743D5A for ; Wed, 3 May 2006 10:26:38 +0000 (GMT) (envelope-from vladgalu@gmail.com) Received: by py-out-1112.google.com with SMTP id e30so165338pya for ; Wed, 03 May 2006 03:26:38 -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:content-transfer-encoding:content-disposition:references; b=jcqeSgjw8vB8EEAXWuEOjr9mE+C9EDr+Us3EHQ2FI0Nm966PXMfLvmAe4aKr+QAB6+eSWS5h3g/sAb9GgywzNwapklf8I4KV8ksh0ayMtvxQeue8091mXZnTu93diuDTrqCMjM9QDjgfBlP0bAi+iWJzUt93IzzzmPDrOWrlJuk= Received: by 10.35.17.8 with SMTP id u8mr18486pyi; Wed, 03 May 2006 03:26:38 -0700 (PDT) Received: by 10.35.34.3 with HTTP; Wed, 3 May 2006 03:26:38 -0700 (PDT) Message-ID: <79722fad0605030326q547fdd46ke4aef97fa948d55a@mail.gmail.com> Date: Wed, 3 May 2006 13:26:38 +0300 From: "Vlad GALU" To: freebsd-current@freebsd.org In-Reply-To: <200605031208.54613.peter@netkey.at> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200605021610.12599.peter@netkey.at> <200605030251.43979.peter@netkey.at> <445803AE.2050700@bitfreak.org> <200605031208.54613.peter@netkey.at> Subject: Re: DRI seems to bee broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2006 10:26:40 -0000 On 5/3/06, Peter Klett wrote: > On Wednesday 03 May 2006 03:13, Darren Pilgrim wrote: > > dmesg, pciconf -vl, kernel config, your complete xorg.conf and the Xorg > > log file from the last run. > seemed I've forgotten the pciconf output or the list removed it, here it = is: > > hostb0@pci0:0:0: class=3D0x060000 card=3D0xc018144d chip=3D0x25908= 086 rev=3D0x03 > hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82915PM/GM/GMS, 82910GML Host Bridge' > class =3D bridge > subclass =3D HOST-PCI > pcib1@pci0:1:0: class=3D0x060400 card=3D0x00000088 chip=3D0x25918086 rev= =3D0x03 > hdr=3D0x01 > vendor =3D 'Intel Corporation' > device =3D '82915PM/GM PCI Express Graphics Port' > class =3D bridge > subclass =3D PCI-PCI > pcib2@pci0:28:0: class=3D0x060400 card=3D0x00000040 chip=3D0x26608= 086 rev=3D0x03 > hdr=3D0x01 > vendor =3D 'Intel Corporation' > device =3D '82801FB/FR/FW/FRW PCI Express Port 1' > class =3D bridge > subclass =3D PCI-PCI > uhci0@pci0:29:0: class=3D0x0c0300 card=3D0xc018144d chip=3D0x26588= 086 rev=3D0x03 > hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801FB/FR/FW/FRW USB UHCI Controller' > class =3D serial bus > subclass =3D USB > uhci1@pci0:29:1: class=3D0x0c0300 card=3D0xc018144d chip=3D0x26598= 086 rev=3D0x03 > hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801FB/FR/FW/FRW USB UHCI Controller' > class =3D serial bus > subclass =3D USB > uhci2@pci0:29:2: class=3D0x0c0300 card=3D0xc018144d chip=3D0x265a8= 086 rev=3D0x03 > hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801FB/FR/FW/FRW USB UHCI Controller' > class =3D serial bus > subclass =3D USB > uhci3@pci0:29:3: class=3D0x0c0300 card=3D0xc018144d chip=3D0x265b8= 086 rev=3D0x03 > hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801FB/FR/FW/FRW USB UHCI Controller' > class =3D serial bus > subclass =3D USB > ehci0@pci0:29:7: class=3D0x0c0320 card=3D0xc018144d chip=3D0x265c8= 086 rev=3D0x03 > hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801FB/FR/FW/FRW USB 2.0 EHCI Controller' > class =3D serial bus > subclass =3D USB > pcib3@pci0:30:0: class=3D0x060401 card=3D0x00000050 chip=3D0x24488= 086 rev=3D0xd3 > hdr=3D0x01 > vendor =3D 'Intel Corporation' > device =3D '82801BAM/CAM/DBM (ICH2-M/3-M/4-M) Hub Interface to PCI = Bridge' > class =3D bridge > subclass =3D PCI-PCI > pcm0@pci0:30:2: class=3D0x040100 card=3D0xc018144d chip=3D0x266e8086 rev= =3D0x03 > hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801FB/FR/FW/FRW AC '97 Audio Controller' > class =3D multimedia > subclass =3D audio > none0@pci0:30:3: class=3D0x070300 card=3D0x2115144d chip=3D0x266d8= 086 rev=3D0x03 > hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801FB/FR/FW/FRW AC '97 Modem Controller' > class =3D simple comms > subclass =3D generic modem > isab0@pci0:31:0: class=3D0x060100 card=3D0xc018144d chip=3D0x26418= 086 rev=3D0x03 > hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801FBM ICH6M LPC Interface Bridge' > class =3D bridge > subclass =3D PCI-ISA > atapci0@pci0:31:1: class=3D0x01018a card=3D0xc018144d chip=3D0x266f8= 086 rev=3D0x03 > hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801FB/FBM Ultra ATA Storage Controllers - 266F' > class =3D mass storage > subclass =3D ATA > none1@pci0:31:3: class=3D0x0c0500 card=3D0xc018144d chip=3D0x266a8= 086 rev=3D0x03 > hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801FB/FR/FW/FRW SMBus Controller' > class =3D serial bus > subclass =3D SMBus > vgapci0@pci1:0:0: class=3D0x030000 card=3D0xc018144d chip=3D0x31501= 002 rev=3D0x00 > hdr=3D0x00 > vendor =3D 'ATI Technologies Inc' > device =3D 'M24 1P Radeon Mobility X600' > class =3D display > subclass =3D VGA > bge0@pci6:5:0: class=3D0x020000 card=3D0xc018144d chip=3D0x169c14e4 rev= =3D0x03 > hdr=3D0x00 > vendor =3D 'Broadcom Corporation' > device =3D 'BCM570x Broadcom Gigabit Ethernet BCM570x NetXtreme' > class =3D network > subclass =3D ethernet > iwi0@pci6:7:0: class=3D0x028000 card=3D0x27318086 chip=3D0x42208086 rev= =3D0x05 > hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D 'PRO/Wireless 2200BG Network Connection' > class =3D network > cbb0@pci6:9:0: class=3D0x060700 card=3D0xc018144d chip=3D0x04761180 rev= =3D0xb3 > hdr=3D0x02 > vendor =3D 'Ricoh Co Ltd' > device =3D 'RL5c476 CardBus Controller' > class =3D bridge > subclass =3D PCI-CardBus > fwohci0@pci6:9:1: class=3D0x0c0010 card=3D0xc018144d chip=3D0x05521= 180 rev=3D0x08 > hdr=3D0x00 > vendor =3D 'Ricoh Co Ltd' > device =3D 'RL5c552 IEEE-1394 Controller' > class =3D serial bus > subclass =3D FireWire > none2@pci6:9:2: class=3D0x080500 card=3D0xc018144d chip=3D0x08221180 rev= =3D0x17 > hdr=3D0x00 > vendor =3D 'Ricoh Co Ltd' > device =3D 'SD Bus Host Adapter' > class =3D base peripheral > none3@pci6:9:3: class=3D0x088000 card=3D0xc018144d chip=3D0x05921180 rev= =3D0x08 > hdr=3D0x00 > vendor =3D 'Ricoh Co Ltd' > device =3D 'Memory Stick Bus Host Adapter' > class =3D base peripheral > FWIW, http://lists.freebsd.org/pipermail/freebsd-x11/2006-February/00267= 4.html. I have the very same problem as described in this thread. > > Peter > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From owner-freebsd-current@FreeBSD.ORG Wed May 3 15:56:10 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A7CB716A400; Wed, 3 May 2006 15:56:10 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0570943D49; Wed, 3 May 2006 15:56:09 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 6385650C8E; Wed, 3 May 2006 17:56:06 +0200 (CEST) Received: from localhost (dlf3.neoplus.adsl.tpnet.pl [83.24.35.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 6CE4550BD1; Wed, 3 May 2006 17:55:59 +0200 (CEST) Date: Wed, 3 May 2006 17:54:20 +0200 From: Pawel Jakub Dawidek To: Julian Elischer Message-ID: <20060503155420.GC3335@garage.freebsd.pl> References: <44512C65.9070106@elischer.org> <4456889D.1020006@elischer.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="f+W+jCU1fRNres8c" Content-Disposition: inline In-Reply-To: <4456889D.1020006@elischer.org> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r535 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=BAYES_00,RCVD_IN_NJABL_DUL autolearn=no version=3.0.4 Cc: announce@bafug.org, current@freebsd.org, grehan@freebsd.org Subject: Re: Bay Area FreeBSD user's Group Meeting Wed. ACPI + Alan Cox X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2006 15:56:10 -0000 --f+W+jCU1fRNres8c Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 01, 2006 at 03:15:57PM -0700, Julian Elischer wrote: +> Wednesdays' meeting is almost upon us. +>=20 +> Nate Lawson will tell us about ACPI +> You will also have the oportunity to meet Alan Cox of VM fame. +>=20 +> I will be webcasting and recording the meeting as usual. +>=20 +> Wednesday, 19:30 Pacific time (currently 7 hours behind UTC). +> Feedback via IRC (efnet #bafug as per usual) +>=20 +> Audio/video at: +> rtsp://jello.ironport.com/bafug-live.sdp +>=20 +> http://www.bafug.org/ for directions etc. +>=20 +> San Francisco bay area resident freebsd users +> are invide, ney, encouraged to attend! +>=20 +> Others are welcome to attend virtually. I'd love to see it, but last I tried I wasn't able to watch it on FreeBSD with all players I know. Hey! It's FreeBSD user's group, right? Can you setup something which is "watchable" from FreeBSD? Pretty please. If there is software already which I can use to watch it, tell me its name and ignore above begging:) Thanks! --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --f+W+jCU1fRNres8c Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFEWNIsForvXbEpPzQRArReAJ0ZFKW957jtRRHmV5zRqMYwdpU9CACfVxu8 ImBzUT4MTMQai965unVS7ho= =Va3e -----END PGP SIGNATURE----- --f+W+jCU1fRNres8c-- From owner-freebsd-current@FreeBSD.ORG Wed May 3 17:23:35 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4025716A406; Wed, 3 May 2006 17:23:35 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk.360sip.com [72.236.70.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id C59CC43D46; Wed, 3 May 2006 17:23:34 +0000 (GMT) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.255.17] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.4/8.13.4) with ESMTP id k43HNQkc080534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 May 2006 10:23:27 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <4458E70B.4020609@FreeBSD.org> Date: Wed, 03 May 2006 10:23:23 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <44512C65.9070106@elischer.org> <4456889D.1020006@elischer.org> <20060503155420.GC3335@garage.freebsd.pl> In-Reply-To: <20060503155420.GC3335@garage.freebsd.pl> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Cc: announce@bafug.org, Julian Elischer , grehan@FreeBSD.org, current@FreeBSD.org Subject: Re: Bay Area FreeBSD user's Group Meeting Wed. ACPI + Alan Cox X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2006 17:23:35 -0000 VLC should be what you are looking for. -Maxim Pawel Jakub Dawidek wrote: > On Mon, May 01, 2006 at 03:15:57PM -0700, Julian Elischer wrote: > +> Wednesdays' meeting is almost upon us. > +> > +> Nate Lawson will tell us about ACPI > +> You will also have the oportunity to meet Alan Cox of VM fame. > +> > +> I will be webcasting and recording the meeting as usual. > +> > +> Wednesday, 19:30 Pacific time (currently 7 hours behind UTC). > +> Feedback via IRC (efnet #bafug as per usual) > +> > +> Audio/video at: > +> rtsp://jello.ironport.com/bafug-live.sdp > +> > +> http://www.bafug.org/ for directions etc. > +> > +> San Francisco bay area resident freebsd users > +> are invide, ney, encouraged to attend! > +> > +> Others are welcome to attend virtually. > > I'd love to see it, but last I tried I wasn't able to watch it on > FreeBSD with all players I know. > > Hey! It's FreeBSD user's group, right? Can you setup something which is > "watchable" from FreeBSD? Pretty please. > > If there is software already which I can use to watch it, tell me its > name and ignore above begging:) Thanks! > From owner-freebsd-current@FreeBSD.ORG Wed May 3 18:35:21 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 01B8116A403; Wed, 3 May 2006 18:35:21 +0000 (UTC) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF3D643D70; Wed, 3 May 2006 18:35:14 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.23.118]) ([10.251.23.118]) by a50.ironport.com with ESMTP; 03 May 2006 11:35:15 -0700 Message-ID: <4458F7E2.7000204@elischer.org> Date: Wed, 03 May 2006 11:35:14 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <44512C65.9070106@elischer.org> <4456889D.1020006@elischer.org> <20060503155420.GC3335@garage.freebsd.pl> <4458F772.3030404@elischer.org> In-Reply-To: <4458F772.3030404@elischer.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: announce@bafug.org, Pawel Jakub Dawidek , current@FreeBSD.org, multimedia@freebsd.org Subject: Re: Bay Area FreeBSD user's Group Meeting Wed. ACPI + Alan Cox X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2006 18:35:21 -0000 sorry guys for the huge mail.. should have sent a link to the file.. > I've been told that VLC works.. > > ok so, given that I am using the quicktime broadcaster on MacOS-X > what settings would be the best for viewable compatibility and good > efficiency? > > I include a png file with all the audio options and video options > and the audio and video packetiser options > > I've been going with mpeg4 audio and video > but if there is somethign more standard... > > > > ------------------------------------------------------------------------ > From owner-freebsd-current@FreeBSD.ORG Wed May 3 18:37:17 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E154F16A403; Wed, 3 May 2006 18:37:17 +0000 (UTC) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2AB7443D53; Wed, 3 May 2006 18:37:17 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.23.118]) ([10.251.23.118]) by a50.ironport.com with ESMTP; 03 May 2006 11:37:18 -0700 Message-ID: <4458F85C.4060108@elischer.org> Date: Wed, 03 May 2006 11:37:16 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <44512C65.9070106@elischer.org> <4456889D.1020006@elischer.org> <20060503155420.GC3335@garage.freebsd.pl> <4458F772.3030404@elischer.org> <4458F7E2.7000204@elischer.org> In-Reply-To: <4458F7E2.7000204@elischer.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: announce@bafug.org, Pawel Jakub Dawidek , current@FreeBSD.org, multimedia@freebsd.org Subject: Re: Bay Area FreeBSD user's Group Meeting Wed. ACPI + Alan Cox X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2006 18:37:18 -0000 Julian Elischer wrote: > sorry guys for the huge mail.. > should have sent a link to the file.. http://www.freebsd.org/~julian/options.png > >> I've been told that VLC works.. >> >> ok so, given that I am using the quicktime broadcaster on MacOS-X >> what settings would be the best for viewable compatibility and good >> efficiency? >> >> I include a png file with all the audio options and video options >> and the audio and video packetiser options >> >> I've been going with mpeg4 audio and video >> but if there is somethign more standard... >> >> >> >> ------------------------------------------------------------------------ >> > > From owner-freebsd-current@FreeBSD.ORG Wed May 3 18:52:59 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F3A216A417; Wed, 3 May 2006 18:52:59 +0000 (UTC) (envelope-from kdk@daleco.biz) Received: from ezekiel.daleco.biz (southernuniform.com [66.76.92.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id B68C343D46; Wed, 3 May 2006 18:52:58 +0000 (GMT) (envelope-from kdk@daleco.biz) Received: from [192.168.2.2] ([69.27.149.254]) by ezekiel.daleco.biz (8.13.4/8.13.1) with ESMTP id k43IqfOh015470; Wed, 3 May 2006 13:52:42 -0500 (CDT) (envelope-from kdk@daleco.biz) Message-ID: <4458FBED.2000305@daleco.biz> Date: Wed, 03 May 2006 13:52:29 -0500 From: Kevin Kinsey User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060426 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <44512C65.9070106@elischer.org> <4456889D.1020006@elischer.org> <20060503155420.GC3335@garage.freebsd.pl> In-Reply-To: <20060503155420.GC3335@garage.freebsd.pl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: announce@bafug.org, Julian Elischer , grehan@freebsd.org, current@freebsd.org Subject: Re: Bay Area FreeBSD user's Group Meeting Wed. ACPI + Alan Cox X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2006 18:52:59 -0000 Pawel Jakub Dawidek wrote: > On Mon, May 01, 2006 at 03:15:57PM -0700, Julian Elischer wrote: > +> Others are welcome to attend virtually. > > I'd love to see it, but last I tried I wasn't able to watch it on > FreeBSD with all players I know. > > Hey! It's FreeBSD user's group, right? Can you setup something which is > "watchable" from FreeBSD? Pretty please. > > If there is software already which I can use to watch it, tell me its > name and ignore above begging:) Thanks! > I download the files and watch 'em with mplayer on FBSD 6.1. What have you tried? Maybe you need some additional codec? Kevin Kinsey -- Language is a virus from another planet. -- William Burroughs From owner-freebsd-current@FreeBSD.ORG Wed May 3 19:01:57 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF26416A4D6; Wed, 3 May 2006 19:01:57 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA9CD43D73; Wed, 3 May 2006 19:01:49 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 9A11950C8E; Wed, 3 May 2006 21:01:47 +0200 (CEST) Received: from localhost (dlf3.neoplus.adsl.tpnet.pl [83.24.35.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 964C750B0D; Wed, 3 May 2006 21:01:41 +0200 (CEST) Date: Wed, 3 May 2006 21:00:01 +0200 From: Pawel Jakub Dawidek To: Kevin Kinsey Message-ID: <20060503190001.GD3335@garage.freebsd.pl> References: <44512C65.9070106@elischer.org> <4456889D.1020006@elischer.org> <20060503155420.GC3335@garage.freebsd.pl> <4458FBED.2000305@daleco.biz> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eheScQNz3K90DVRs" Content-Disposition: inline In-Reply-To: <4458FBED.2000305@daleco.biz> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r535 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=BAYES_00,RCVD_IN_NJABL_DUL autolearn=no version=3.0.4 Cc: announce@bafug.org, Julian Elischer , grehan@freebsd.org, current@freebsd.org Subject: Re: Bay Area FreeBSD user's Group Meeting Wed. ACPI + Alan Cox X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2006 19:01:58 -0000 --eheScQNz3K90DVRs Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 03, 2006 at 01:52:29PM -0500, Kevin Kinsey wrote: +> Pawel Jakub Dawidek wrote: +> >On Mon, May 01, 2006 at 03:15:57PM -0700, Julian Elischer wrote: +>=20 +> >+> Others are welcome to attend virtually. +> >I'd love to see it, but last I tried I wasn't able to watch it on +> >FreeBSD with all players I know. +> >Hey! It's FreeBSD user's group, right? Can you setup something which is +> >"watchable" from FreeBSD? Pretty please. +> >If there is software already which I can use to watch it, tell me its +> >name and ignore above begging:) Thanks! +>=20 +> I download the files and watch 'em with mplayer on FBSD 6.1. What have = you tried? Maybe you need some additional codec? I was able to watch the files, I wasn't able to watch the stream, I'll try vlc. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --eheScQNz3K90DVRs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFEWP2xForvXbEpPzQRArLTAKDDxm5NfbWCK5cmElzdzJ6mAUb/7gCgwk7L usD8ocHjd7BpUF8lXN69uBM= =tEwt -----END PGP SIGNATURE----- --eheScQNz3K90DVRs-- From owner-freebsd-current@FreeBSD.ORG Wed May 3 19:41:49 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6FA8816A47D; Wed, 3 May 2006 19:41:49 +0000 (UTC) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 18CF343D58; Wed, 3 May 2006 19:41:33 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.23.118]) ([10.251.23.118]) by a50.ironport.com with ESMTP; 03 May 2006 12:41:34 -0700 Message-ID: <4459076D.70004@elischer.org> Date: Wed, 03 May 2006 12:41:33 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <44512C65.9070106@elischer.org> <4456889D.1020006@elischer.org> <20060503155420.GC3335@garage.freebsd.pl> <4458FBED.2000305@daleco.biz> <20060503190001.GD3335@garage.freebsd.pl> In-Reply-To: <20060503190001.GD3335@garage.freebsd.pl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: announce@bafug.org, Kevin Kinsey , grehan@FreeBSD.org, current@FreeBSD.org Subject: Re: Bay Area FreeBSD user's Group Meeting Wed. ACPI + Alan Cox X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2006 19:41:49 -0000 Pawel Jakub Dawidek wrote: >On Wed, May 03, 2006 at 01:52:29PM -0500, Kevin Kinsey wrote: >+> Pawel Jakub Dawidek wrote: >+> >On Mon, May 01, 2006 at 03:15:57PM -0700, Julian Elischer wrote: >+> >+> >+> Others are welcome to attend virtually. >+> >I'd love to see it, but last I tried I wasn't able to watch it on >+> >FreeBSD with all players I know. >+> >Hey! It's FreeBSD user's group, right? Can you setup something which is >+> >"watchable" from FreeBSD? Pretty please. >+> >If there is software already which I can use to watch it, tell me its >+> >name and ignore above begging:) Thanks! >+> >+> I download the files and watch 'em with mplayer on FBSD 6.1. What have you tried? Maybe you need some additional codec? > >I was able to watch the files, I wasn't able to watch the stream, I'll >try vlc. > > > I'll have it up and streaming my cube in a few minutes so you can try out a few programs.. From owner-freebsd-current@FreeBSD.ORG Wed May 3 21:49:58 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CAF5616A403 for ; Wed, 3 May 2006 21:49:58 +0000 (UTC) (envelope-from oz@nixil.net) Received: from nixil.net (nixil.net [161.58.222.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15F5143D79 for ; Wed, 3 May 2006 21:49:55 +0000 (GMT) (envelope-from oz@nixil.net) Received: from [10.20.12.64] (fw.oremut02.us.wh.verio.net [198.65.168.24]) (authenticated bits=0) by nixil.net (8.13.6/8.13.1) with ESMTP id k43Lnmwg061370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 3 May 2006 15:49:54 -0600 (MDT) Message-ID: <4459257C.5010807@nixil.net> Date: Wed, 03 May 2006 15:49:48 -0600 From: Phil Oleson User-Agent: Thunderbird 1.5 (X11/20060112) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (nixil.net [161.58.222.1]); Wed, 03 May 2006 15:49:54 -0600 (MDT) X-Virus-Scanned: ClamAV 0.88/1438/Wed May 3 12:40:02 2006 on nixil.net X-Virus-Status: Clean Subject: Google SOC project Suggestion page. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2006 21:50:01 -0000 Hey.. I was perusing the SOC project page (http://www.freebsd.org/projects/summerofcode.html) to see what was likely to be worked upon by the SOC volunteers, and noticed the 'BSD licensed API compatible version of GNU readline' suggestion. I thought we already had a solution for this in libedit, except that we exclude the readline compatability layer because readline is part of the base system and would cause conflicts? Shouldn't this project suggestion be reworded to say complete/flesh out libedit's readline compatability layer in the effort to remove the readline library from the base system? Or are we wanting someone to re-invent the wheel again? -Phil. From owner-freebsd-current@FreeBSD.ORG Wed May 3 21:53:41 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C2A0F16A408 for ; Wed, 3 May 2006 21:53:41 +0000 (UTC) (envelope-from takawata@init-main.com) Received: from ns.init-main.com (104.194.138.210.bn.2iij.net [210.138.194.104]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5CE8B43D46 for ; Wed, 3 May 2006 21:53:41 +0000 (GMT) (envelope-from takawata@init-main.com) Received: from init-main.com (localhost [127.0.0.1]) by ns.init-main.com (8.13.6/8.13.3) with ESMTP id k43Lpjg2009960; Thu, 4 May 2006 06:51:54 +0900 (JST) (envelope-from takawata@init-main.com) Message-Id: <200605032151.k43Lpjg2009960@ns.init-main.com> To: "M. Warner Losh" From: takawata@jp.freebsd.org In-reply-to: Your message of "Mon, 01 May 2006 22:27:43 CST." <20060501.222743.32503989.imp@bsdimp.com> Date: Thu, 04 May 2006 06:51:45 +0900 Sender: takawata@init-main.com Cc: freebsd-current@freebsd.org Subject: Re: lpt0 disappear (ppc related) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2006 21:53:41 -0000 In message <20060501.222743.32503989.imp@bsdimp.com>, "M. Warner Losh" $B$5$s$$$o(B $B$/(B: >In message: <200605020815.31012.doconnor@gsoft.com.au> > "Daniel O'Connor" writes: >: On Tuesday 02 May 2006 01:23, M. Warner Losh wrote: >: > : However you wouldn't expect that using it as a module would result in >: > : reduced functionality. (The same as how you wouldn't expect compiling >: > : something into your kernel would result in reduced functionality) >: > >: > At the same time, you'd expect it to behave like every other 'bus' in >: > the tree. We omit the attachments for drivers to that bus when the >: > kernel is built w/o that bus. This is why if you have, say, ep in the >: > kernel, but pccard loaded as a module, the 3c589 you just inserted >: > into the pccard slot won't work. >: > >: > It is a minor imperfection in the config system that no one has taken >: > on as a Problem To Solve. Solving it turns out to be somewhat tricky. >: >: Hmm, but I load acpi as a module and get acpi attachments.. (for sio and ppc >) >: >: it's black magic to me anyway :) >: >: I didn't mean to belittle Marcel's work, I was just suprised that it would >: cause a functionality loss like that. > >I think it just points out a weakness in the underlying system... Is it time to hide isa_dma interface under isa_if ? All acpi capable archictectures links isa_if.c, I think. From owner-freebsd-current@FreeBSD.ORG Wed May 3 22:02:32 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C36F16A400 for ; Wed, 3 May 2006 22:02:32 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AD7943D45 for ; Wed, 3 May 2006 22:02:32 +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.4/8.13.4) with ESMTP id k43LxZ7B043560; Wed, 3 May 2006 15:59:37 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 03 May 2006 15:59:37 -0600 (MDT) Message-Id: <20060503.155937.118274131.imp@bsdimp.com> To: takawata@jp.freebsd.org From: "M. Warner Losh" In-Reply-To: <200605032151.k43Lpjg2009960@ns.init-main.com> References: <20060501.222743.32503989.imp@bsdimp.com> <200605032151.k43Lpjg2009960@ns.init-main.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: lpt0 disappear (ppc related) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2006 22:02:32 -0000 In message: <200605032151.k43Lpjg2009960@ns.init-main.com> takawata@jp.freebsd.org writes: : In message <20060501.222743.32503989.imp@bsdimp.com>, "M. Warner Losh" $B$5$s$$$o(B : $B$/(B: : >In message: <200605020815.31012.doconnor@gsoft.com.au> : > "Daniel O'Connor" writes: : >: On Tuesday 02 May 2006 01:23, M. Warner Losh wrote: : >: > : However you wouldn't expect that using it as a module would result in : >: > : reduced functionality. (The same as how you wouldn't expect compiling : >: > : something into your kernel would result in reduced functionality) : >: > : >: > At the same time, you'd expect it to behave like every other 'bus' in : >: > the tree. We omit the attachments for drivers to that bus when the : >: > kernel is built w/o that bus. This is why if you have, say, ep in the : >: > kernel, but pccard loaded as a module, the 3c589 you just inserted : >: > into the pccard slot won't work. : >: > : >: > It is a minor imperfection in the config system that no one has taken : >: > on as a Problem To Solve. Solving it turns out to be somewhat tricky. : >: : >: Hmm, but I load acpi as a module and get acpi attachments.. (for sio and ppc : >) : >: : >: it's black magic to me anyway :) : >: : >: I didn't mean to belittle Marcel's work, I was just suprised that it would : >: cause a functionality loss like that. : > : >I think it just points out a weakness in the underlying system... : : Is it time to hide isa_dma interface under isa_if ? : All acpi capable archictectures links isa_if.c, I think. Yes. I think it would be worthwhile to have all the ISA symbols hidden, like we do for PC Card. This would be a step in that direction... Maybe the last step? Warner From owner-freebsd-current@FreeBSD.ORG Wed May 3 22:47:56 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9FBDF16A40F; Wed, 3 May 2006 22:47:56 +0000 (UTC) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1A4843D6B; Wed, 3 May 2006 22:47:50 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.23.118]) ([10.251.23.118]) by a50.ironport.com with ESMTP; 03 May 2006 15:47:50 -0700 Message-ID: <44593315.4030006@elischer.org> Date: Wed, 03 May 2006 15:47:49 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <44512C65.9070106@elischer.org> <4456889D.1020006@elischer.org> <20060503155420.GC3335@garage.freebsd.pl> <4458FBED.2000305@daleco.biz> <20060503190001.GD3335@garage.freebsd.pl> <4459076D.70004@elischer.org> In-Reply-To: <4459076D.70004@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: announce@bafug.org, Pawel Jakub Dawidek , Kevin Kinsey , current@freebsd.org Subject: Re: [Announce] Bay Area FreeBSD user's Group Meeting Wed. ACPI + Alan Cox X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2006 22:47:56 -0000 Julian Elischer wrote: >Pawel Jakub Dawidek wrote: > > > >>On Wed, May 03, 2006 at 01:52:29PM -0500, Kevin Kinsey wrote: >>+> Pawel Jakub Dawidek wrote: >>+> >On Mon, May 01, 2006 at 03:15:57PM -0700, Julian Elischer wrote: >>+> >>+> >+> Others are welcome to attend virtually. >>+> >I'd love to see it, but last I tried I wasn't able to watch it on >>+> >FreeBSD with all players I know. >>+> >Hey! It's FreeBSD user's group, right? Can you setup something which is >>+> >"watchable" from FreeBSD? Pretty please. >>+> >If there is software already which I can use to watch it, tell me its >>+> >name and ignore above begging:) Thanks! >>+> >>+> I download the files and watch 'em with mplayer on FBSD 6.1. What have you tried? Maybe you need some additional codec? >> >>I was able to watch the files, I wasn't able to watch the stream, I'll >>try vlc. >> >> >> >> >> >I'll have it up and streaming my cube in a few minutes so you can try >out a few programs.. > > try: rtsp://jello.ironport.com/bafug-live.sdp comments to irc://efnet/#bafug From owner-freebsd-current@FreeBSD.ORG Wed May 3 22:53:57 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 88A8816A452 for ; Wed, 3 May 2006 22:53:57 +0000 (UTC) (envelope-from kdk@daleco.biz) Received: from ezekiel.daleco.biz (southernuniform.com [66.76.92.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2777843D5D for ; Wed, 3 May 2006 22:53:56 +0000 (GMT) (envelope-from kdk@daleco.biz) Received: from [192.168.2.2] ([69.27.149.254]) by ezekiel.daleco.biz (8.13.4/8.13.1) with ESMTP id k43MrqYw017001; Wed, 3 May 2006 17:53:52 -0500 (CDT) (envelope-from kdk@daleco.biz) Message-ID: <4459347A.6070006@daleco.biz> Date: Wed, 03 May 2006 17:53:46 -0500 From: Kevin Kinsey User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060426 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrzej Tobola References: <44512C65.9070106@elischer.org> <4456889D.1020006@elischer.org> <20060503155420.GC3335@garage.freebsd.pl> <4458FBED.2000305@daleco.biz> <20060503222855.GA77524@amper.iem.pw.edu.pl> In-Reply-To: <20060503222855.GA77524@amper.iem.pw.edu.pl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Bay Area FreeBSD user's Group Meeting Wed. ACPI + Alan Cox X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2006 22:53:57 -0000 Andrzej Tobola wrote: > On Wed, May 03, 2006 at 01:52:29PM -0500, Kevin Kinsey wrote: > >>I download the files and watch 'em with mplayer on FBSD 6.1. What have >>you tried? Maybe you need some additional codec? > > >>From where ? Can't find them > > cheeers, > -a http://people.freebsd.org/~julian/BAFUG/talks/ ;-) KDK -- The strong give up and move on, while the weak give up and stay. From owner-freebsd-current@FreeBSD.ORG Wed May 3 23:02:53 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1204416A403; Wed, 3 May 2006 23:02:53 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk.360sip.com [72.236.70.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7699E43D70; Wed, 3 May 2006 23:02:48 +0000 (GMT) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.0.90] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.6/8.13.6) with ESMTP id k43N2eeC002345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 May 2006 16:02:41 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <4459368C.70609@FreeBSD.org> Date: Wed, 03 May 2006 16:02:36 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Julian Elischer References: <44512C65.9070106@elischer.org> <4456889D.1020006@elischer.org> <20060503155420.GC3335@garage.freebsd.pl> <4458FBED.2000305@daleco.biz> <20060503190001.GD3335@garage.freebsd.pl> <4459076D.70004@elischer.org> <44593315.4030006@elischer.org> In-Reply-To: <44593315.4030006@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: announce@bafug.org, Pawel Jakub Dawidek , Kevin Kinsey , current@FreeBSD.org Subject: Re: [Announce] Bay Area FreeBSD user's Group Meeting Wed. ACPI + Alan Cox X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2006 23:02:53 -0000 Julian Elischer wrote: > Julian Elischer wrote: > >> Pawel Jakub Dawidek wrote: >> >> >> >>> On Wed, May 03, 2006 at 01:52:29PM -0500, Kevin Kinsey wrote: >>> +> Pawel Jakub Dawidek wrote: >>> +> >On Mon, May 01, 2006 at 03:15:57PM -0700, Julian Elischer wrote: >>> +> +> >+> Others are welcome to attend virtually. >>> +> >I'd love to see it, but last I tried I wasn't able to watch it on >>> +> >FreeBSD with all players I know. >>> +> >Hey! It's FreeBSD user's group, right? Can you setup something >>> which is >>> +> >"watchable" from FreeBSD? Pretty please. >>> +> >If there is software already which I can use to watch it, tell me >>> its >>> +> >name and ignore above begging:) Thanks! >>> +> +> I download the files and watch 'em with mplayer on FBSD 6.1. >>> What have you tried? Maybe you need some additional codec? >>> >>> I was able to watch the files, I wasn't able to watch the stream, I'll >>> try vlc. >>> >>> >>> >>> >> I'll have it up and streaming my cube in a few minutes so you can try >> out a few programs.. >> >> > > try: > rtsp://jello.ironport.com/bafug-live.sdp Hey, I see you. :) -Maxim From owner-freebsd-current@FreeBSD.ORG Wed May 3 23:23:23 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C7DB16A403; Wed, 3 May 2006 23:23:23 +0000 (UTC) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D7EF43D49; Wed, 3 May 2006 23:23:20 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.23.118]) ([10.251.23.118]) by a50.ironport.com with ESMTP; 03 May 2006 16:23:20 -0700 Message-ID: <44593B67.4050702@elischer.org> Date: Wed, 03 May 2006 16:23:19 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <44512C65.9070106@elischer.org> <4456889D.1020006@elischer.org> <20060503155420.GC3335@garage.freebsd.pl> <4458FBED.2000305@daleco.biz> <20060503190001.GD3335@garage.freebsd.pl> <4459076D.70004@elischer.org> <44593315.4030006@elischer.org> In-Reply-To: <44593315.4030006@elischer.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: announce@bafug.org, Pawel Jakub Dawidek , Kevin Kinsey , current@freebsd.org Subject: Re: [Announce] Bay Area FreeBSD user's Group Meeting Wed. ACPI + Alan Cox X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2006 23:23:23 -0000 Julian Elischer wrote: >Julian Elischer wrote: > > > >>Pawel Jakub Dawidek wrote: >> >> >> >> >>I'll have it up and streaming my cube in a few minutes so you can try >>out a few programs.. >> >> >> >> > >try: > rtsp://jello.ironport.com/bafug-live.sdp > > you may also try: rtsp://jello.ironport.com:80/bafug-live.sdp >comments to irc://efnet/#bafug > > From owner-freebsd-current@FreeBSD.ORG Thu May 4 00:04:52 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C64816A400 for ; Thu, 4 May 2006 00:04:52 +0000 (UTC) (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 BEC8543D45 for ; Thu, 4 May 2006 00:04:51 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (j87jwwcrtmcchmal@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.4/8.13.3) with ESMTP id k4404l6m048015; Wed, 3 May 2006 17:04:47 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.4/8.13.3/Submit) id k4404jJ2048014; Wed, 3 May 2006 17:04:45 -0700 (PDT) (envelope-from jmg) Date: Wed, 3 May 2006 17:04:45 -0700 From: John-Mark Gurney To: "M. Warner Losh" Message-ID: <20060504000445.GU728@funkthat.com> Mail-Followup-To: "M. Warner Losh" , takawata@jp.freebsd.org, freebsd-current@freebsd.org References: <20060501.222743.32503989.imp@bsdimp.com> <200605032151.k43Lpjg2009960@ns.init-main.com> <20060503.155937.118274131.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060503.155937.118274131.imp@bsdimp.com> 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-current@freebsd.org Subject: Re: lpt0 disappear (ppc related) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2006 00:04:52 -0000 Warner Losh wrote this message on Wed, May 03, 2006 at 15:59 -0600: > In message: <200605032151.k43Lpjg2009960@ns.init-main.com> > takawata@jp.freebsd.org writes: > : In message <20060501.222743.32503989.imp@bsdimp.com>, "M. Warner Losh" ?$B$5$s$$$o > : ?$B$/: > : >In message: <200605020815.31012.doconnor@gsoft.com.au> > : > "Daniel O'Connor" writes: > : >: On Tuesday 02 May 2006 01:23, M. Warner Losh wrote: > : >: > : However you wouldn't expect that using it as a module would result in > : >: > : reduced functionality. (The same as how you wouldn't expect compiling > : >: > : something into your kernel would result in reduced functionality) > : >: > > : >: > At the same time, you'd expect it to behave like every other 'bus' in > : >: > the tree. We omit the attachments for drivers to that bus when the > : >: > kernel is built w/o that bus. This is why if you have, say, ep in the > : >: > kernel, but pccard loaded as a module, the 3c589 you just inserted > : >: > into the pccard slot won't work. > : >: > > : >: > It is a minor imperfection in the config system that no one has taken > : >: > on as a Problem To Solve. Solving it turns out to be somewhat tricky. > : >: > : >: Hmm, but I load acpi as a module and get acpi attachments.. (for sio and ppc > : >) > : >: > : >: it's black magic to me anyway :) > : >: > : >: I didn't mean to belittle Marcel's work, I was just suprised that it would > : >: cause a functionality loss like that. > : > > : >I think it just points out a weakness in the underlying system... > : > : Is it time to hide isa_dma interface under isa_if ? > : All acpi capable archictectures links isa_if.c, I think. > > Yes. I think it would be worthwhile to have all the ISA symbols > hidden, like we do for PC Card. This would be a step in that > direction... Maybe the last step? Yeh, it'd be good.. I don't plan on adding support for ISA to sun4v till I don't have to define anoying symbols like isa_init just to get it running.. :( -- 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-current@FreeBSD.ORG Thu May 4 10:25:55 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0E4C416A400 for ; Thu, 4 May 2006 10:25:55 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from fw.zoral.com.ua (ll-227.216.82.212.sovam.net.ua [212.82.216.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 064E143D46 for ; Thu, 4 May 2006 10:25:53 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id k44APl1I026488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 4 May 2006 13:25:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.13.6/8.13.6) with ESMTP id k44APlfv010472 for ; Thu, 4 May 2006 13:25:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.6/8.13.6/Submit) id k44APkWL010471 for freebsd-current@freebsd.org; Thu, 4 May 2006 13:25:46 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 4 May 2006 13:25:46 +0300 From: Kostik Belousov To: freebsd-current@freebsd.org Message-ID: <20060504102546.GC35756@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SkvwRMAIpAhPCcCJ" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on fw.zoral.com.ua Subject: [patch] userquota= syntax in fstab is broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2006 10:25:55 -0000 --SkvwRMAIpAhPCcCJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Man page for fstab describes syntax of the form userquota=3D and groupquota=3D that allows to specify alternative quota files. This feature is supported by quota*(8) group of commands, but putting such option into the fstab cause complain from kernel, since this options shall be trimmed from mount option list. Rev. 1.75 of sbin/mount/mount.c does this for userquota/groupquota _without_ "=3D". Patch below fixes the problem for specified syntax as well. Please, apply. Index: sbin/mount/mount.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/local/arch/ncvs/src/sbin/mount/mount.c,v retrieving revision 1.83 diff -u -r1.83 mount.c --- sbin/mount/mount.c 3 Mar 2006 02:46:15 -0000 1.83 +++ sbin/mount/mount.c 4 May 2006 10:24:25 -0000 @@ -120,6 +120,9 @@ 0 }; =20 +static const char userquotaeq[] =3D "userquota=3D"; +static const char groupquotaeq[] =3D "groupquota=3D"; + static int use_mountprog(const char *vfstype) { @@ -634,8 +637,12 @@ continue; } else if (strcmp(p, "userquota") =3D=3D 0) { continue; + } else if (strncmp(p, userquotaeq, sizeof(userquotaeq) - 1) =3D=3D 0) { + continue; } else if (strcmp(p, "groupquota") =3D=3D 0) { continue; + } else if (strncmp(p, groupquotaeq, sizeof(groupquotaeq) - 1) =3D=3D 0)= { + continue; } else if (*p =3D=3D '-') { argv[argc++] =3D p; p =3D strchr(p, '=3D'); --SkvwRMAIpAhPCcCJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEWdapC3+MBN1Mb4gRApIDAJ4w513arLjw1xCKfe9ZZ9qbETA8TQCffSUI +dajIsyk+y/DQ2eESLZEXdY= =fDgB -----END PGP SIGNATURE----- --SkvwRMAIpAhPCcCJ-- From owner-freebsd-current@FreeBSD.ORG Thu May 4 13:01:30 2006 Return-Path: X-Original-To: freebsd-current@www.freebsd.org Delivered-To: freebsd-current@www.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F96416A40F for ; Thu, 4 May 2006 13:01:30 +0000 (UTC) (envelope-from ggajic@afrodita.rcub.bg.ac.yu) Received: from afrodita.rcub.bg.ac.yu (afrodita.rcub.bg.ac.yu [147.91.1.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64A5443D4C for ; Thu, 4 May 2006 13:01:29 +0000 (GMT) (envelope-from ggajic@afrodita.rcub.bg.ac.yu) Received: from afrodita.rcub.bg.ac.yu (localhost.localdomain [127.0.0.1]) by afrodita.rcub.bg.ac.yu (8.13.6/8.13.4) with ESMTP id k44D1LFY023434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 4 May 2006 15:01:21 +0200 Received: from localhost (ggajic@localhost) by afrodita.rcub.bg.ac.yu (8.13.6/8.13.6/Submit) with ESMTP id k44D1KXN023429 for ; Thu, 4 May 2006 15:01:21 +0200 Date: Thu, 4 May 2006 15:01:20 +0200 (CEST) From: Goran Gajic To: freebsd-current@www.freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-RCUB-MailScanner-Information: Please contact the RCUB if you have problem with mail X-RCUB-MailScanner: Found to be clean X-RCUB-MailScanner-From: ggajic@afrodita.rcub.bg.ac.yu X-Mailman-Approved-At: Thu, 04 May 2006 13:51:50 +0000 Cc: Subject: umount smbfs LOR X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2006 13:01:30 -0000 Hi, I'm sorry if this is already known, but this is what happens when I try to umount smbfs mounted export: netsmb_dev: loaded lockmgr: thread 0xc30e1870 unlocking unheld lock KDB: stack backtrace: kdb_backtrace(c08c0d3a,c30e1870) at kdb_backtrace+0x29 lockmgr(c2c4f808,2006,c2c4f878,c30e1870,d6eb4c00) at lockmgr+0x5f6 smb_co_put(c2c4f800,d6eb4c00,d6eb4c00,c30e1870,c2719880) at smb_co_put+0x4c smbfs_unmount(c279f2d4,8000000,c30e1870,0,42f) at smbfs_unmount+0x71 dounmount(c279f2d4,8000000,c30e1870,c0993b68,0) at dounmount+0x2b5 unmount(c30e1870,d6eb4d04,c30e2000,c,c30e1870) at unmount+0x201 syscall(3b,3b,3b,804a465,8202e01) at syscall+0x27e Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (22, FreeBSD ELF32, unmount), eip = 0x280c23ef, esp = 0xbfbfe56c, ebp = 0xbfbfe618 --- It is from today built: FreeBSD fbsd.interex-pla.net 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Thu May 4 14:20:19 CEST 2006 (config is GENERIC). Regards, gg. From owner-freebsd-current@FreeBSD.ORG Thu May 4 17:28:39 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D162B16A405; Thu, 4 May 2006 17:28:39 +0000 (UTC) (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 C98FC43D48; Thu, 4 May 2006 17:28:38 +0000 (GMT) (envelope-from bushman@rsu.ru) Received: from jersey ([80.80.97.196]) (authenticated bits=0) by mail.r61.net (8.13.6/8.13.6) with ESMTP id k44HSExI078924 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 4 May 2006 21:28:24 +0400 (MSD) (envelope-from bushman@rsu.ru) Message-ID: <019f01c66fa0$34052240$a9655050@jersey> From: "Michael Bushkov" To: "Ceri Davies" , "Robert Watson" References: <002401c66b0a$44c230e0$01655050@jersey> <44529510.6030704@freebsd.org> <20060428222627.GI51777@submonkey.net> <001801c66b42$d48d4740$e8775050@jersey> <20060429100236.GJ51777@submonkey.net> <20060429174129.H11416@fledge.watson.org> Date: Thu, 4 May 2006 21:28:25 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on asterix.r61.net X-Virus-Status: Clean Cc: freebsd-current@FreeBSD.org, Hajimu UMEMOTO , Colin Percival , freebsd-arch@FreeBSD.org Subject: Re: [HEADS UP] upcoming /etc/services updating X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2006 17:28:39 -0000 Hi, > Robert Watson wrote: > BTW, since this is in the context of significantly increasing the size of > the services database, have we: > > (1) Measured what impact adding the cache daemon for local databases has? > Specifically, does adding the cache daemon for a database like > /etc/services, /etc/passwd, etc, improve performance, or add overhead? > > (2) Looked at adding /etc/services.db, similar to the other compiled > database > pieces, in order to improve lookup times for very large tables. This > change would be orthoganal to a cache daemon. getpwXXX() and getgrXXX() functions work slower in about 3 times with cached enabled when only "files" source is used. The thing is, I think, I'll be able to improve cached's performance to reduce this drawback. Currently, cached gives real performance gain with sources such as DNS and LDAP and is not that useful with local sources, except the "services" database (I'll do accurate benchmarking with all types of sources and will post the report with its results). I'll test the cached performance with very large /etc/services file. However, at this moment, the solution with compiled database for services will be probably faster. Anyway, cached can be used right now to allow IANA list importing without significant performance drawbacks, IMHO. With best regards, Michael Bushkov From owner-freebsd-current@FreeBSD.ORG Thu May 4 18:15:25 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0BF6B16A40D; Thu, 4 May 2006 18:15:25 +0000 (UTC) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id CDDEC43D45; Thu, 4 May 2006 18:15:24 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.19.131]) ([10.251.19.131]) by a50.ironport.com with ESMTP; 04 May 2006 11:15:18 -0700 Message-ID: <445A44B6.5080906@elischer.org> Date: Thu, 04 May 2006 11:15:18 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org, arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: SGI kernel braindump. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2006 18:15:25 -0000 One of the (ex) main developers for the SGI SMP scheduler and related fields has offered to do a brain dump, possibly with some of his ex-cohorts of what they learned in their efforts to make SGI's unix do good SMP scheduling. This would be in the guise of the July 5 BAFUG meeting, and would be webcast as usual, so People from all-over could attend. If we do this I'd like to make sure that there are enough interested people to make it worth the time of these people to go out of their way to collect together information and make presentations, and I'd also like to ask that interested people start thinking about quuestions they'd like to ask. I'd like to start by collecting questions ASAP so that I can forward them on to the speaker to help hi,m gather together information that would be useful for us. Let the comments and Questions come in please! Julian p.s. Last night's recordings of Alan Cox's and Nate Walker's talks will be put up for download in the next couple of days. From owner-freebsd-current@FreeBSD.ORG Thu May 4 19:00:33 2006 Return-Path: X-Original-To: freebsd-current@www.freebsd.org Delivered-To: freebsd-current@www.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 13C5116A401 for ; Thu, 4 May 2006 19:00:18 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 03D9943D46 for ; Thu, 4 May 2006 19:00:16 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 8B4B41FF905; Thu, 4 May 2006 21:00:13 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id 16E761FF903; Thu, 4 May 2006 21:00:10 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 32E204448D6; Thu, 4 May 2006 18:55:10 +0000 (UTC) Date: Thu, 4 May 2006 18:55:10 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Goran Gajic In-Reply-To: Message-ID: <20060504185406.V54242@maildrop.int.zabbadoz.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Cc: freebsd-current@www.freebsd.org Subject: Re: umount smbfs unloking unheld lock [not a LOR] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2006 19:00:33 -0000 On Thu, 4 May 2006, Goran Gajic wrote: > I'm sorry if this is already known, but this is what happens > when I try to umount smbfs mounted export: not everything that gives a backtrace and is realted to locking is a LOR ;-) > netsmb_dev: loaded > lockmgr: thread 0xc30e1870 unlocking unheld lock > KDB: stack backtrace: > kdb_backtrace(c08c0d3a,c30e1870) at kdb_backtrace+0x29 > lockmgr(c2c4f808,2006,c2c4f878,c30e1870,d6eb4c00) at lockmgr+0x5f6 > smb_co_put(c2c4f800,d6eb4c00,d6eb4c00,c30e1870,c2719880) at smb_co_put+0x4c > smbfs_unmount(c279f2d4,8000000,c30e1870,0,42f) at smbfs_unmount+0x71 > dounmount(c279f2d4,8000000,c30e1870,c0993b68,0) at dounmount+0x2b5 > unmount(c30e1870,d6eb4d04,c30e2000,c,c30e1870) at unmount+0x201 > syscall(3b,3b,3b,804a465,8202e01) at syscall+0x27e > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (22, FreeBSD ELF32, unmount), eip = 0x280c23ef, esp = 0xbfbfe56c, > ebp = 0xbfbfe618 --- > > It is from today built: > > FreeBSD fbsd.interex-pla.net 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Thu May 4 > 14:20:19 CEST 2006 > (config is GENERIC). > > Regards, > gg. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-current@FreeBSD.ORG Thu May 4 19:17:45 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F8C716A417; Thu, 4 May 2006 19:17:45 +0000 (UTC) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DBAA43D46; Thu, 4 May 2006 19:17:45 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.19.131]) ([10.251.19.131]) by a50.ironport.com with ESMTP; 04 May 2006 12:17:44 -0700 Message-ID: <445A5358.5070004@elischer.org> Date: Thu, 04 May 2006 12:17:44 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <445A44B6.5080906@elischer.org> In-Reply-To: <445A44B6.5080906@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, current@freebsd.org Subject: Re: SGI kernel braindump. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2006 19:17:47 -0000 Julian Elischer wrote: > > One of the (ex) main developers for the SGI SMP scheduler and related > fields > has offered to do a brain dump, possibly with some of his > ex-cohorts of what they learned in their efforts to make SGI's unix > do good SMP > scheduling. > > This would be in the guise of the July 5 BAFUG meeting, and would be > webcast as usual, so People from all-over could attend. > > If we do this I'd like to make sure that there are enough interested > people to make it worth the time of these people to go out of their > way to collect > together information and make presentations, and I'd also like to ask > that interested people > start thinking about quuestions they'd like to ask. I'd like to start > by collecting > questions ASAP so that I can forward them on to the speaker to help > hi,m gather together > information that would be useful for us. > > > Let the comments and Questions come in please! > > Julian > > p.s. Last night's recordings of Alan Cox's and Nate Walker's talks Duh braino.. Nate LAWSON > will be put up for download in the next couple of days. > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu May 4 19:33:29 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3451A16A400; Thu, 4 May 2006 19:33:29 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id CAB8843D48; Thu, 4 May 2006 19:33:28 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.13.4.20060308/8.13.4) with ESMTP id k44JXS2w033060; Thu, 4 May 2006 12:33:28 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.13.4.20060308/8.13.4/Submit) id k44JXS7N033059; Thu, 4 May 2006 12:33:28 -0700 (PDT) Date: Thu, 4 May 2006 12:33:28 -0700 (PDT) From: Matthew Dillon Message-Id: <200605041933.k44JXS7N033059@apollo.backplane.com> To: freebsd-gnats-submit@freebsd.org, freebsd-current@freebsd.org Cc: Subject: Re: kern/93942: panic: ufs_dirbad: bad dir X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2006 19:33:29 -0000 I've found three additional issues which might be related to ufs_dirbad panics. Again, unfortunately, no smoking gun. First, if B_NOCACHE gets set on a B_DIRTY buffer, the buffer can be lost without the data being written under certain conditions due to brelse() mechanics. B_NOCACHE is typically set by softupdates related code but can be set by other things as well (in particular, if a buffer is resized, and certain write/read combinations). One might think that calling bwrite() after setting B_NOCACHE would be safe, but that is not necessarily true. If a buffer is redirtied (B_DIRTY set) during the write, something which softupdates does all the time, B_NOCACHE almost certainly has to be cleared. Of the three issues I found, this is the most likely cause. Second, vnode_pager_setsize() is being called too late in ufs/ufs/ufs_lookup.c (line 733 in FreeBSD-current). It is being called after the buffer has been instantiated. This could create problems with the VMIO backing store for the buffer created by the UFS_BALLOC call. Third, vnode_pager_setsize() is being called too late in ufs/ufs/ufs_vnops.c (line 1557 in FreeBSD-current). It is being called after the buffer has been instantiated by UFS_BALLOC() in ufs_mkdir(), which could create problems with the buffer's VMIO backing store. -- The M.O. of this corruption, after examining over a dozen kernel cores, makes me now believe that the corruption is occuring when the kernel attempts to append a full block to a directory. The bitmaps are all good... it is if as though the directory block never got written and the data we are seeing is data that existed in tha block before the directory allocated it. But, likewise, the issue has occured with different disk drivers so I think we can rule out a disk driver failure. The issue also seems to occur most often with large, 'busy' buffers (lots of directory operations going on). Since no similar corruption has ever been reported for heavily used files, this supports the idea that it is *not* the disk driver. I believe that the data is getting written to the filesystem buffer representing the new block, but the buffer or its backing store is somehow getting thrown away without being written, or getting thrown away and then reinstantiated without being read. The areas I indicate in the above list are areas where data can potentially get thrown away or lost prior to a write. -Matt Matthew Dillon (Patch against DragonFly, will not apply to FreeBSD directly, included for reference only): Index: kern/vfs_bio.c =================================================================== RCS file: /cvs/src/sys/kern/vfs_bio.c,v retrieving revision 1.53.2.1 diff -u -r1.53.2.1 vfs_bio.c --- kern/vfs_bio.c 18 Apr 2006 17:12:25 -0000 1.53.2.1 +++ kern/vfs_bio.c 24 Apr 2006 19:22:04 -0000 @@ -972,6 +972,13 @@ bdirty(struct buf *bp) { KASSERT(bp->b_qindex == BQUEUE_NONE, ("bdirty: buffer %p still on queue %d", bp, bp->b_qindex)); + if (bp->b_flags & B_NOCACHE) { + printf("bdirty: clearing B_NOCACHE on buf %p\n", bp); + bp->b_flags &= ~B_NOCACHE; + } + if (bp->b_flags & B_INVAL) { + printf("bdirty: warning, dirtying invalid buffer %p\n", bp); + } bp->b_flags &= ~(B_READ|B_RELBUF); if ((bp->b_flags & B_DELWRI) == 0) { @@ -1096,6 +1103,11 @@ crit_enter(); + if ((bp->b_flags & (B_NOCACHE|B_DIRTY)) == (B_NOCACHE|B_DIRTY)) { + printf("warning: buf %p marked dirty & B_NOCACHE, clearing B_NOCACHE\n", bp); + bp->b_flags &= ~B_NOCACHE; + } + if (bp->b_flags & B_LOCKED) bp->b_flags &= ~B_ERROR; Index: vfs/ufs/ufs_lookup.c =================================================================== RCS file: /cvs/src/sys/vfs/ufs/ufs_lookup.c,v retrieving revision 1.18 diff -u -r1.18 ufs_lookup.c --- vfs/ufs/ufs_lookup.c 14 Sep 2005 01:13:48 -0000 1.18 +++ vfs/ufs/ufs_lookup.c 24 Apr 2006 19:22:23 -0000 @@ -716,6 +716,7 @@ */ if (dp->i_offset & (DIRBLKSIZ - 1)) panic("ufs_direnter: newblk"); + vnode_pager_setsize(dvp, dp->i_offset + DIRBLKSIZ); flags = B_CLRBUF; if (!DOINGSOFTDEP(dvp) && !DOINGASYNC(dvp)) flags |= B_SYNC; @@ -727,7 +728,6 @@ } dp->i_size = dp->i_offset + DIRBLKSIZ; dp->i_flag |= IN_CHANGE | IN_UPDATE; - vnode_pager_setsize(dvp, (u_long)dp->i_size); dirp->d_reclen = DIRBLKSIZ; blkoff = dp->i_offset & (VFSTOUFS(dvp->v_mount)->um_mountp->mnt_stat.f_iosize - 1); Index: vfs/ufs/ufs_vnops.c =================================================================== RCS file: /cvs/src/sys/vfs/ufs/ufs_vnops.c,v retrieving revision 1.32 diff -u -r1.32 ufs_vnops.c --- vfs/ufs/ufs_vnops.c 17 Sep 2005 07:43:12 -0000 1.32 +++ vfs/ufs/ufs_vnops.c 24 Apr 2006 19:22:42 -0000 @@ -1420,12 +1420,12 @@ dirtemplate = *dtp; dirtemplate.dot_ino = ip->i_number; dirtemplate.dotdot_ino = dp->i_number; + vnode_pager_setsize(tvp, DIRBLKSIZ); if ((error = VOP_BALLOC(tvp, (off_t)0, DIRBLKSIZ, cnp->cn_cred, B_CLRBUF, &bp)) != 0) goto bad; ip->i_size = DIRBLKSIZ; ip->i_flag |= IN_CHANGE | IN_UPDATE; - vnode_pager_setsize(tvp, (u_long)ip->i_size); bcopy((caddr_t)&dirtemplate, (caddr_t)bp->b_data, sizeof dirtemplate); if (DOINGSOFTDEP(tvp)) { /* From owner-freebsd-current@FreeBSD.ORG Fri May 5 01:52:14 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2EB3516A400; Fri, 5 May 2006 01:52:14 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBBF743D45; Fri, 5 May 2006 01:52:13 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id k451qCGN065193; Thu, 4 May 2006 21:52:13 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.4P/8.13.4) with ESMTP id k451ptXh056347; Thu, 4 May 2006 21:51:55 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 604087302F; Thu, 4 May 2006 21:52:12 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20060505015212.604087302F@freebsd-current.sentex.ca> Date: Thu, 4 May 2006 21:52:12 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2006 01:52:14 -0000 TB --- 2006-05-04 23:49:18 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-05-04 23:49:18 - starting HEAD tinderbox run for i386/i386 TB --- 2006-05-04 23:49:18 - cleaning the object tree TB --- 2006-05-04 23:49:48 - checking out the source tree TB --- 2006-05-04 23:49:48 - cd /tinderbox/HEAD/i386/i386 TB --- 2006-05-04 23:49:48 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-05-04 23:56:30 - building world (CFLAGS=-O2 -pipe) TB --- 2006-05-04 23:56:30 - cd /src TB --- 2006-05-04 23:56:30 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2006-05-05 01:04:09 - generating LINT kernel config TB --- 2006-05-05 01:04:09 - cd /src/sys/i386/conf TB --- 2006-05-05 01:04:09 - /usr/bin/make -B LINT TB --- 2006-05-05 01:04:09 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-05-05 01:04:09 - cd /src TB --- 2006-05-05 01:04:09 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri May 5 01:04:09 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Fri May 5 01:29:44 UTC 2006 TB --- 2006-05-05 01:29:44 - building GENERIC kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-05-05 01:29:44 - cd /src TB --- 2006-05-05 01:29:44 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri May 5 01:29:44 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Fri May 5 01:50:15 UTC 2006 TB --- 2006-05-05 01:50:15 - building PAE kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-05-05 01:50:15 - cd /src TB --- 2006-05-05 01:50:15 - /usr/bin/make buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Fri May 5 01:50:15 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/dev/ata/ata-raid.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/dev/ata/atapi-cd.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/dev/ata/atapi-fd.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/dev/ata/atapi-tape.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/dev/ath/ath_rate/sample/sample.c -I/src/sys/contrib/dev/ath/freebsd cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/dev/ath/if_ath.c -I/src/sys/contrib/dev/ath/freebsd /src/sys/dev/ath/if_ath.c: In function `ath_descdma_setup': /src/sys/dev/ath/if_ath.c:2378: warning: large integer implicitly truncated to unsigned type *** Error code 1 Stop in /obj/src/sys/PAE. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-05-05 01:52:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-05-05 01:52:12 - ERROR: failed to build PAE kernel TB --- 2006-05-05 01:52:12 - tinderbox aborted TB --- 1.23 user 5.78 system 7373.65 real From owner-freebsd-current@FreeBSD.ORG Fri May 5 14:57:03 2006 Return-Path: X-Original-To: freebsd-current@www.freebsd.org Delivered-To: freebsd-current@www.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C168516A42D for ; Fri, 5 May 2006 14:57:03 +0000 (UTC) (envelope-from kariukiphares@yahoo.com) Received: from web50504.mail.yahoo.com (web50504.mail.yahoo.com [206.190.38.80]) by mx1.FreeBSD.org (Postfix) with SMTP id B207243D66 for ; Fri, 5 May 2006 14:56:56 +0000 (GMT) (envelope-from kariukiphares@yahoo.com) Received: (qmail 53226 invoked by uid 60001); 5 May 2006 14:56:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=oNBs3e55i4+PwZmSsoqcZJ5u01WRdoouU7P458SKHDL/XUr+TN+keu20+df+z6D+s2/AJRLEWgytkCeNbvaFebB2cWIzm0MzBdxX+rqNyP84TRJ7+H/VRIEb7lglVtTjU938PJvgaCTPybQ0R0EFCuB4OC3S3eZmGT1LrJcXNBw= ; Message-ID: <20060505145655.53224.qmail@web50504.mail.yahoo.com> Received: from [196.202.220.136] by web50504.mail.yahoo.com via HTTP; Fri, 05 May 2006 07:56:55 PDT Date: Fri, 5 May 2006 07:56:55 -0700 (PDT) From: Kariuki Kaboro To: freebsd-current@www.freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: SAMBA issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kariukiphares@yahoo.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2006 14:57:04 -0000 Hi, I am running FreeBSD 5.4, however, I fall under the category of a "newbie". I have run into some issues... I installed samba 2.2.12. I got errors first to do with the loopback adaptor which i was able to eventually figure out.. however, the biggest problem has been that I am unable to access my machine from windows computers and my config seems OK. Kindly have a look @ it and if you can tell me where I am going wrong.... =====================================================>>> # This is the main Samba configuration file. You should read the # smb.conf(5) manual page in order to understand the options listed # here. Samba has a huge number of configurable options (perhaps too # many!) most of which are not shown in this example # # Any line which starts with a ; (semi-colon) or a # (hash) # is a comment and is ignored. In this example we will use a # # for commentry and a ; for parts of the config file that you # may wish to enable # # NOTE: Whenever you modify this file you should run the command "testparm" # to check that you have not many any basic syntactic errors. # #======================= Global Settings ===================================== [global] # workgroup = NT-Domain-Name or Workgroup-Name, eg: REDHAT4 netbios name = ajay workgroup = SOCRATES # server string is the equivalent of the NT Description field server string = ajay #socket = 192.168.170.3 log file = /var/log/log.%m # This option is important for security. It allows you to restrict # connections to machines which are on your local network. The # following example restricts access to two C class networks and # the "loopback" interface. For more examples of the syntax see # the smb.conf man page ; hosts allow = 192.168.1. 192.168.2. 127. # If you want to automatically load your printer list rather # than setting them up individually then you'll need this load printers = yes # you may wish to override the location of the printcap file ; printcap name = /etc/printcap # on SystemV system setting printcap name to lpstat should allow # you to automatically obtain a printer list from the SystemV spool # system ; printcap name = lpstat # It should not be necessary to specify the print system type unless # it is non-standard. Currently supported print systems include: # bsd, sysv, plp, lprng, aix, hpux, qnx ; printing = bsd # Uncomment this if you want a guest account, you must add this to /etc/passwd # otherwise the user "nobody" is used ; guest account = pcguest # this tells Samba to use a separate log file for each machine # that connects log file = /var/log/log.%m # Put a capping on the size of the log files (in Kb). max log size = 50 # Security mode. Most people will want user level security. See # security_level.txt for details. security = user # Use password server option only with security = server # The argument list may include: # password server = My_PDC_Name [My_BDC_Name] [My_Next_BDC_Name] # or to auto-locate the domain controller/s # password server = * ; password server = # Note: Do NOT use the now deprecated option of "domain controller" # This option is no longer implemented. # You may wish to use password encryption. Please read # ENCRYPTION.txt, Win95.txt and WinNT.txt in the Samba documentation. # Do not enable this option unless you have read those documents ; encrypt passwords = yes # Using the following line enables you to customise your configuration # on a per machine basis. The %m gets replaced with the netbios name # of the machine that is connecting ; include = /usr/local/etc/smb.conf.%m # Most people will find that this option gives better performance. # See speed.txt and the manual pages for details # You may want to add the following on a Linux system: # SO_RCVBUF=8192 SO_SNDBUF=8192 # socket options = TCP_NODELAY # Configure Samba to use multiple interfaces # If you have multiple network interfaces then you must list them # here. See the man page for details. ; interfaces = 192.168.12.2/24 192.168.13.2/24 # Browser Control Options: # set local master to no if you don't want Samba to become a master # browser on your network. Otherwise the normal election rules apply local master = yes # OS Level determines the precedence of this server in master browser # elections. The default value should be reasonable os level = 65 # Domain Master specifies Samba to be the Domain Master Browser. This # allows Samba to collate browse lists between subnets. Don't use this # if you already have a Windows NT domain controller doing this job domain master = yes # Preferred Master causes Samba to force a local browser election on startup # and gives it a slightly higher chance of winning the election preferred master = yes #Miscellaneous Options ;socket options = TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF=8192 SO_RCVBUF=8192 #Dont show files starting with dots hide dot files = yes #Do not allow Guest Access, use only local sytem accounts. security = user guest ok = no invalid users = bin daemon sys man postfix mail ftp admin users = @domadm, #Domain Administrators ;domain admin group = @domadm ;domain admin users = @domadm, root # Enable this if you want Samba to be a domain logon server for # Windows95 workstations. domain logons = yes # if you enable domain logons then you may want a per-machine or # per user logon script # run a specific logon batch file per workstation (machine) ; logon script = %m.bat # run a specific logon batch file per username ; logon script = %U.bat #General Logon Script in Dos Format logon script = netlogon.bat # Where to store roving profiles (only for Win95 and WinNT) # %L substitutes for this servers netbios name, %U is username # You must uncomment the [Profiles] share below logon path = \\%L\Profiles\%U # Windows Internet Name Serving Support Section: # WINS Support - Tells the NMBD component of Samba to enable it's WINS Server wins support = yes # WINS Server - Tells the NMBD components of Samba to be a WINS Client # Note: Samba can be either a WINS Server, or a WINS Client, but NOT both ; wins server = w.x.y.z # WINS Proxy - Tells Samba to answer name resolution queries on # behalf of a non WINS capable client, for this to work there must be # at least one WINS Server on the network. The default is NO. ; wins proxy = yes # DNS Proxy - tells Samba whether or not to try to resolve NetBIOS names # via DNS nslookups. The built-in default for versions 1.9.17 is yes, # this has been changed in version 1.9.18 to no. dns proxy = no # Client codepage settings # for Greek users ; client code page=737 # for European users (Latin 1) ; client code page=850 # for European users (Latin 2) ; client code page=852 # for Icelandic users ; client code page=861 # for Cyrillic users ; client code page=866 # for Japanese Users ; client code page=932 ; coding system=cap # for Simplified Chinese Users ; client code page=936 ; coding system=cap # for Korean Users ; client code page=949 ; coding system=cap # for Traditional Chinese Users ; client code page=950 ; coding system=cap #============================ Share Definitions ============================== [homes] comment = Home Directories browseable = no writeable = yes # Un-comment the following two lines to add a recycle bin facility to a samba share # NOTE: It currently doesn't work with the [homes] virtual share, use a regular share instead ; vfs object = /usr/local/lib/samba/recycle.so ; vfs options= /usr/local/etc/recycle.conf.default # Un-comment the following and create the netlogon directory for Domain Logons [netlogon] comment = Network Logon Service path = /usr/local/samba/lib/netlogon guest ok = no browseable = no writeable = no share modes = no valid users = @domadm, @domusers # Un-comment the following to provide a specific roving profile share # the default is to use the user's home directory [Profiles] path = /usr/local/samba/profiles browseable = no guest ok = no create mask = 0700 directory mask = 0700 valid users = root, @domadm, @domusers # NOTE: If you have a BSD-style print system there is no need to # specifically define each individual printer [printers] comment = All Printers path = /var/spool/samba browseable = no # Set public = yes to allow user 'guest account' to print guest ok = no writeable = no printable = yes # This one is useful for people to share files ;[tmp] ; comment = Temporary file space ; path = /tmp ; read only = no ; public = yes # A publicly accessible directory, but read only, except for people in # the "staff" group [public] comment = Public Stuff path = /home/samba/public public = yes writeable = yes printable = no write list = @staff # Other examples. # # A private printer, usable only by fred. Spool data will be placed in fred's # home directory. Note that fred must have write access to the spool directory, # wherever it is. ;[fredsprn] ; comment = Fred's Printer ; valid users = fred ; path = /homes/fred ; printer = freds_printer ; public = no ; writeable = no ; printable = yes # A private directory, usable only by fred. Note that fred requires write # access to the directory. ;[fredsdir] ; comment = Fred's Service ; path = /usr/somewhere/private ; valid users = fred ; public = no ; writeable = yes ; printable = no # a service which has a different directory for each machine that connects # this allows you to tailor configurations to incoming machines. You could # also use the %U option to tailor it by user name. # The %m gets replaced with the machine name that is connecting. ;[pchome] ; comment = PC Directories ; path = /usr/pc/%m ; public = no ; writeable = yes # A publicly accessible directory, read/write to all users. Note that all files # created in the directory by users will be owned by the default user, so # any user with access can delete any other user's files. Obviously this # directory must be writeable by the default user. Another user could of course # be specified, in which case all files would be owned by that user instead. ;[public] ; path = /usr/somewhere/else/public ; public = yes ; only guest = yes ; writeable = yes ; printable = no # Un-comment the following two lines to add a recycle bin facility to a samba share ; vfs object = /usr/local/lib/samba/recycle.so ; vfs options= /usr/local/etc/recycle.conf.default # The following two entries demonstrate how to share a directory so that two # users can place files there that will be owned by the specific users. In this # setup, the directory should be writeable by both users and should have the # sticky bit set on it to prevent abuse. Obviously this could be extended to # as many users as required. ;[myshare] ; comment = Mary's and Fred's stuff ; path = /usr/somewhere/shared ; valid users = mary fred ; public = no ; writeable = yes ; printable = no ; create mask = 0765 <<======================================================== Thanks. Kaboro Kariuki. Yours Truly, Phares Kariuki --------------------------------- Yahoo! Messenger with Voice. PC-to-Phone calls for ridiculously low rates. From owner-freebsd-current@FreeBSD.ORG Fri May 5 16:51:28 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A325C16A403 for ; Fri, 5 May 2006 16:51:28 +0000 (UTC) (envelope-from sthalik@tehran.lain.pl) Received: from tehran.lain.pl (tehran.lain.pl [85.221.230.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2762C43D49 for ; Fri, 5 May 2006 16:51:28 +0000 (GMT) (envelope-from sthalik@tehran.lain.pl) Received: from sthalik by tehran.lain.pl with local (envelope-from ) id 1Fc3WY-0006Bp-JB for freebsd-current@freebsd.org; Fri, 05 May 2006 18:51:26 +0200 Date: Fri, 5 May 2006 18:51:26 +0200 From: Stanislaw Halik To: freebsd-current@freebsd.org Message-ID: <20060505165126.GA23622@tehran.lain.pl> Mail-Followup-To: freebsd-current@freebsd.org References: <20060505145655.53224.qmail@web50504.mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5vNYLRcllDrimb99" Content-Disposition: inline In-Reply-To: <20060505145655.53224.qmail@web50504.mail.yahoo.com> X-PGP-Key: http://tehran.lain.pl/public.key User-Agent: Mutt/1.5.11 X-User: sthalik Subject: Re: SAMBA issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2006 16:51:28 -0000 --5vNYLRcllDrimb99 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, May 05, 2006, Kariuki Kaboro wrote: > I am running FreeBSD 5.4, however, I fall under the category of a > "newbie". I have run into some issues... I installed samba 2.2.12. I > got errors first to do with the loopback adaptor which i was able to > eventually figure out.. however, the biggest problem has been that I > am unable to access my machine from windows computers did you enable nmbd? or alternatively, does accessing by \\ip from windows work? -- sh --5vNYLRcllDrimb99 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEW4KOadU+vjT62TERAtMzAJ9mJwgqSF6SiY3lLkei+fBGodJCrwCZAZGs 3qAMgZ3VyOFCxZP2SeLq08A= =lVze -----END PGP SIGNATURE----- --5vNYLRcllDrimb99-- From owner-freebsd-current@FreeBSD.ORG Fri May 5 18:30:54 2006 Return-Path: X-Original-To: freebsd-current@www.freebsd.org Delivered-To: freebsd-current@www.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C27916A403 for ; Fri, 5 May 2006 18:30:54 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C24A43D45 for ; Fri, 5 May 2006 18:30:53 +0000 (GMT) (envelope-from swhetzel@gmail.com) Received: by wx-out-0102.google.com with SMTP id h31so579078wxd for ; Fri, 05 May 2006 11:30:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hf6EM8qatQfEveIzmAFQV2YXBHzKKikl3+2J1v1Pjcg5Y40D++Pkl9brts3/HNhxRtxzLpNeCHGcshHPuN+ibyc81MV0Rpn7fMxR+6oiSIQ/MKlTlaeeyXfkOajcvjyVpPC+yInrCjxhA6VmwKNKALkRzeLsirt6sWO+OsVX3rQ= Received: by 10.70.110.4 with SMTP id i4mr2801672wxc; Fri, 05 May 2006 11:30:52 -0700 (PDT) Received: by 10.70.53.10 with HTTP; Fri, 5 May 2006 11:30:52 -0700 (PDT) Message-ID: <790a9fff0605051130y6191180br776337370b469e86@mail.gmail.com> Date: Fri, 5 May 2006 13:30:52 -0500 From: "Scot Hetzel" To: kariukiphares@yahoo.com In-Reply-To: <20060505145655.53224.qmail@web50504.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20060505145655.53224.qmail@web50504.mail.yahoo.com> Cc: freebsd-current@www.freebsd.org Subject: Re: SAMBA issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2006 18:30:54 -0000 On 5/5/06, Kariuki Kaboro wrote: > Hi, > I am running FreeBSD 5.4, however, I fall under the category of a "newb= ie". I have run into some issues... I installed samba 2.2.12. I got errors= first to do with the loopback adaptor which i was able to eventually figu= re out.. however, the biggest problem has been that I am unable to access = my machine from windows computers and my config seems OK. Kindly have a lo= ok @ it and if you can tell me where I am going wrong.... > You should have posted on either FreeBSD-questions, FreeBSD-ports, or the SAMBA mailing lists. FreeBSD-CURRENT is for discussing the problems with the development of the next FreeBSD release (Currently, 7.0). Check that you have set both smbd_enable and nmbd_enable to yes in your /etc/rc.conf. Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. From owner-freebsd-current@FreeBSD.ORG Fri May 5 19:45:26 2006 Return-Path: X-Original-To: freebsd-current@www.freebsd.org Delivered-To: freebsd-current@www.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C4BD516A406 for ; Fri, 5 May 2006 19:45:26 +0000 (UTC) (envelope-from mikej@rogers.com) Received: from smtp106.rog.mail.re2.yahoo.com (smtp106.rog.mail.re2.yahoo.com [68.142.225.204]) by mx1.FreeBSD.org (Postfix) with SMTP id A91B043D48 for ; Fri, 5 May 2006 19:45:19 +0000 (GMT) (envelope-from mikej@rogers.com) Received: (qmail 37290 invoked from network); 5 May 2006 19:45:19 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=082oaJi5WnHd7migElckJUKV42jRf8SRjTOvSE09ST3C+h9/PSCrcTzWB0LiXB6doZhZyjUzAvCbXLA+KU1oetUSbm2AVbM5Cy4SCEDbJ3CagtkM2TP0tOWGuzUShN9U0C2sxr+2WyoJJ3VPzLoXYBL93dCVr19Z+sRoxqVVr28= ; Received: from unknown (HELO ?70.31.50.218?) (mikej@rogers.com@70.31.50.218 with plain) by smtp106.rog.mail.re2.yahoo.com with SMTP; 5 May 2006 19:45:18 -0000 Message-ID: <445BAB52.8090409@rogers.com> Date: Fri, 05 May 2006 15:45:22 -0400 From: Mike Jakubik User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Scot Hetzel References: <20060505145655.53224.qmail@web50504.mail.yahoo.com> <790a9fff0605051130y6191180br776337370b469e86@mail.gmail.com> In-Reply-To: <790a9fff0605051130y6191180br776337370b469e86@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@www.freebsd.org, kariukiphares@yahoo.com Subject: Re: SAMBA issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2006 19:45:26 -0000 Scot Hetzel wrote: > On 5/5/06, Kariuki Kaboro wrote: >> Hi, >> I am running FreeBSD 5.4, however, I fall under the category of a >> "newbie". I have run into some issues... I installed samba 2.2.12. I >> got errors first to do with the loopback adaptor which i was able to >> eventually figure out.. however, the biggest problem has been that I >> am unable to access my machine from windows computers and my config >> seems OK. Kindly have a look @ it and if you can tell me where I am >> going wrong.... >> > You should have posted on either FreeBSD-questions, FreeBSD-ports, or > the SAMBA mailing lists. > > FreeBSD-CURRENT is for discussing the problems with the development of > the next FreeBSD release (Currently, 7.0). > > Check that you have set both smbd_enable and nmbd_enable to yes in > your /etc/rc.conf. You should also consider using the samba3 port instead, as it is the current stable version of Samba. (This should be changed in the ports imo) From owner-freebsd-current@FreeBSD.ORG Fri May 5 19:49:42 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FCC716A423 for ; Fri, 5 May 2006 19:49:42 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 028FA43D55 for ; Fri, 5 May 2006 19:49:41 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.13.6/8.13.6) with ESMTP id k45JnfJa029013 for ; Fri, 5 May 2006 12:49:41 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.6/8.13.6/Submit) id k45JnfbC029012 for freebsd-current@freebsd.org; Fri, 5 May 2006 12:49:41 -0700 (PDT) (envelope-from sgk) Date: Fri, 5 May 2006 12:49:41 -0700 From: Steve Kargl To: freebsd-current@freebsd.org Message-ID: <20060505194941.GA20542@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: loader problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2006 19:49:42 -0000 I have set WITHOUT_FORTRAN in /etc/make.conf and rebuilt/installed a new world. I've removed all Fortran files related to the base system f77 (aka g77) from my system. I've install gfortran as a Fortran compiler in /usr/local. As root, I do % cd /usr/ports/math/lapack % setenv FC gfortran % make gfortran -O2 -pipe -c lsame.f cc -O2 -fno-strict-aliasing -pipe -march=opteron -march=opteron -c etime_.c gfortran -O2 -pipe -c slamch.f gfortran -O2 -pipe -c second.f gfortran -O2 -pipe -c dlamch.f gfortran -O2 -pipe -c dsecnd.f building static lapack library ranlib liblapack.a gfortran -fpic -DPIC -O2 -pipe -o lsame.So -c lsame.f cc -fpic -DPIC -O2 -fno-strict-aliasing -pipe -march=opteron -march=opteron -c etime_.c -o etime_.So gfortran -fpic -DPIC -O2 -pipe -o slamch.So -c slamch.f gfortran -fpic -DPIC -O2 -pipe -o second.So -c second.f gfortran -fpic -DPIC -O2 -pipe -o dlamch.So -c dlamch.f gfortran -fpic -DPIC -O2 -pipe -o dsecnd.So -c dsecnd.f building shared library liblapack.so.3 /usr/bin/ld: cannot find -lg2c *** Error code 1 Stop in /usr/ports/math/lapack/work/LAPACK/SRC. *** Error code 1 Why is /usr/bin/ld looking for libg2c, which was removed? libg2c is f77's (aka g77's) runtime library. How do I tell ld to not include -lg2c? -- Steve From owner-freebsd-current@FreeBSD.ORG Sat May 6 07:44:57 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9929816A402; Sat, 6 May 2006 07:44:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2FE1F43D45; Sat, 6 May 2006 07:44:57 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id k467iugA017678; Sat, 6 May 2006 03:44:56 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.6/8.13.6) with ESMTP id k467iuYs021633; Sat, 6 May 2006 03:44:56 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 05A0C7302F; Sat, 6 May 2006 03:44:56 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20060506074456.05A0C7302F@freebsd-current.sentex.ca> Date: Sat, 6 May 2006 03:44:56 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2006 07:44:57 -0000 TB --- 2006-05-06 05:33:52 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-05-06 05:33:52 - starting HEAD tinderbox run for i386/i386 TB --- 2006-05-06 05:33:52 - cleaning the object tree TB --- 2006-05-06 05:34:25 - checking out the source tree TB --- 2006-05-06 05:34:25 - cd /tinderbox/HEAD/i386/i386 TB --- 2006-05-06 05:34:25 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-05-06 05:41:14 - building world (CFLAGS=-O2 -pipe) TB --- 2006-05-06 05:41:14 - cd /src TB --- 2006-05-06 05:41:14 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2006-05-06 06:49:03 - generating LINT kernel config TB --- 2006-05-06 06:49:03 - cd /src/sys/i386/conf TB --- 2006-05-06 06:49:03 - /usr/bin/make -B LINT TB --- 2006-05-06 06:49:03 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-05-06 06:49:03 - cd /src TB --- 2006-05-06 06:49:03 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat May 6 06:49:03 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sat May 6 07:19:50 UTC 2006 TB --- 2006-05-06 07:19:50 - building GENERIC kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-05-06 07:19:50 - cd /src TB --- 2006-05-06 07:19:50 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat May 6 07:19:51 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Sat May 6 07:43:07 UTC 2006 TB --- 2006-05-06 07:43:07 - building PAE kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-05-06 07:43:07 - cd /src TB --- 2006-05-06 07:43:07 - /usr/bin/make buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Sat May 6 07:43:07 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/dev/ata/ata-raid.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/dev/ata/atapi-cd.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/dev/ata/atapi-fd.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/dev/ata/atapi-tape.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/dev/ath/ath_rate/sample/sample.c -I/src/sys/contrib/dev/ath/freebsd cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/dev/ath/if_ath.c -I/src/sys/contrib/dev/ath/freebsd /src/sys/dev/ath/if_ath.c: In function `ath_descdma_setup': /src/sys/dev/ath/if_ath.c:2378: warning: large integer implicitly truncated to unsigned type *** Error code 1 Stop in /obj/src/sys/PAE. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-05-06 07:44:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-05-06 07:44:55 - ERROR: failed to build PAE kernel TB --- 2006-05-06 07:44:55 - tinderbox aborted TB --- 1.17 user 5.81 system 7863.91 real From owner-freebsd-current@FreeBSD.ORG Sat May 6 14:16:50 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB2D516A401; Sat, 6 May 2006 14:16:49 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1466643D46; Sat, 6 May 2006 14:16:48 +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 709FF46C1F; Sat, 6 May 2006 10:16:48 -0400 (EDT) Date: Sat, 6 May 2006 15:16:48 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Message-ID: <20060506150622.C17611@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: performance@FreeBSD.org Subject: Fine-grained locking for POSIX local sockets (UNIX domain sockets) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2006 14:16:50 -0000 Dear all, Attached, please find a patch implementing more fine-grained locking for the POSIX local socket subsystem (UNIX domain socket subsystem). In the current implementation, we use a single global subsystem lock to protect all local IPC over the PF_LOCAL socket type. This has low overhead, but can result in significant contention, especially for workloads like MySQL which push a great deal of data through UNIX domain sockets, and involve many parties. The hope is that by improving granularity, we can reduce contention sufficiently to overcome the added cost of increased locking overhead (a side-effect of greater granularity). At a high level, here are the changes made: - Introduced a mutex for each UNIX domain socket protocol control block (unpcb). - Use the global lock as a guard lock around simultaneous locking of two unpcbs, which have no defined order. - Introduce new states associated with "binding" and "connecting" of sockets -- this corrects several long-standing race conditions in this code relating to blocking file system lookups, especially where sockets are shared between process or threads. Certain critical paths do still acquire the global lock since they involve multiple pcbs (send, receive) but the scope is now reduced. I hope to further refine these changes to eliminate the acquisition of the global lock in these critical cases. In local measurements, I have observed a 0% change in MySQL performance on uniprocessor systems, and on a dual-processor system I have observed a 4%-5% performance improvement with two client MySQL threads. I'm looking for two things: (1) Stability and correctness testing. Does this break your applications and/or kernel. (2) Performance assessment. Does this change performance for critical applications that use UNIX domain sockets, such as MySQL, especially with respect to CPU count. I hope to get this committed to the 7.x tree in the next week or so if there is sufficient positive feedback on performance, and sufficiently little negative feedback on stability and performance. Thanks, Robert N M Watson --- //depot/vendor/freebsd/src/sys/kern/uipc_usrreq.c 2006/04/24 19:10:17 +++ //depot/user/rwatson/proto/src/sys/kern/uipc_usrreq.c 2006/05/06 12:44:20 @@ -88,32 +88,99 @@ struct mbuf *unp_addsockcred(struct thread *, struct mbuf *); /* - * Currently, UNIX domain sockets are protected by a single subsystem lock, - * which covers global data structures and variables, the contents of each - * per-socket unpcb structure, and the so_pcb field in sockets attached to - * the UNIX domain. This provides for a moderate degree of paralellism, as - * receive operations on UNIX domain sockets do not need to acquire the - * subsystem lock. Finer grained locking to permit send() without acquiring - * a global lock would be a logical next step. + * Both send and receive buffers are allocated PIPSIZ bytes of buffering + * for stream sockets, although the total for sender and receiver is + * actually only PIPSIZ. + * Datagram sockets really use the sendspace as the maximum datagram size, + * and don't really want to reserve the sendspace. Their recvspace should + * be large enough for at least one max-size datagram plus address. + */ +#ifndef PIPSIZ +#define PIPSIZ 8192 +#endif +static u_long unpst_sendspace = PIPSIZ; +static u_long unpst_recvspace = PIPSIZ; +static u_long unpdg_sendspace = 2*1024; /* really max datagram size */ +static u_long unpdg_recvspace = 4*1024; + +static int unp_rights; /* file descriptors in flight */ + +SYSCTL_DECL(_net_local_stream); +SYSCTL_ULONG(_net_local_stream, OID_AUTO, sendspace, CTLFLAG_RW, + &unpst_sendspace, 0, ""); +SYSCTL_ULONG(_net_local_stream, OID_AUTO, recvspace, CTLFLAG_RW, + &unpst_recvspace, 0, ""); +SYSCTL_DECL(_net_local_dgram); +SYSCTL_ULONG(_net_local_dgram, OID_AUTO, maxdgram, CTLFLAG_RW, + &unpdg_sendspace, 0, ""); +SYSCTL_ULONG(_net_local_dgram, OID_AUTO, recvspace, CTLFLAG_RW, + &unpdg_recvspace, 0, ""); +SYSCTL_DECL(_net_local); +SYSCTL_INT(_net_local, OID_AUTO, inflight, CTLFLAG_RD, &unp_rights, 0, ""); + +/* + * Locking and synchronization: + * + * A global UNIX domain socket mutex protects all global variables in the + * implementation, as well as the linked lists tracking the set of allocated + * UNIX domain sockets. These variables/fields may be read lockless using + * atomic operations if stale values are permissible; otherwise the global + * mutex is required to read or read-modify-write. The global mutex also + * serves to prevent deadlock when multiple PCB locks may be acquired at once + * (see below). Finally, the global mutex protects uncounted references from + * vnodes to sockets bound to those vnodes: to safely dereference the + * v_socket pointer, the global mutex must be held while a full reference is + * acquired. + * + * UNIX domain sockets each have one unpcb PCB associated with them from + * pru_attach() to pru_detach() via the so_pcb pointer. The validity of that + * reference is an invariant for the lifetime of the socket, so no lock is + * required to dereference the so_pcb pointer if a valid socket reference is + * held. + * + * Each PCB has a back-pointer to its socket, unp_socket. This pointer may + * only be safely dereferenced as long as a valid reference to the PCB is + * held. Typically, this reference will be from the socket, or from another + * PCB when the referring PCB's lock is held (in order that the reference not + * be invalidated during use). In particular, to follow + * unp->unp_conn->unp_socket, you need unlock the lock on unp, not unp_conn. + * + * Fields of PCBs are locked using a per-unpcb lock, unp_mtx. Individual + * atomic reads without the lock may be performed "lockless", but more + * complex reads and read-modify-writes require the mutex to be held. No + * lock order is defined between PCB locks -- multiple PCB locks may be + * acquired at the same time only when holding the global UNIX domain socket + * mutex, which prevents deadlocks. To prevent inter-PCB references from + * becoming invalid, the lock protecting the reference must be held for the + * lifetime of use of the reference. * - * The UNIX domain socket lock preceds all socket layer locks, including the - * socket lock and socket buffer lock, permitting UNIX domain socket code to - * call into socket support routines without releasing its locks. + * Blocking with UNIX domain sockets is a tricky issue: unlike most network + * protocols, bind() is a non-atomic operation, and connect() requires + * potential sleeping in the protocol, due to potentially waiting on local or + * distributed file systems. We try to separate "lookup" operations, which + * may sleep, and the IPC operations themselves, which typically can occur + * with relative atomicity as locks can be held over the entire operation. * - * Some caution is required in areas where the UNIX domain socket code enters - * VFS in order to create or find rendezvous points. This results in - * dropping of the UNIX domain socket subsystem lock, acquisition of the - * Giant lock, and potential sleeping. This increases the chances of races, - * and exposes weaknesses in the socket->protocol API by offering poor - * failure modes. + * Another tricky issue is simultaneous multi-threaded or multi-process + * access to a single UNIX domain socket. These are handled by the flags + * UNP_CONNECTING and UNP_BINDING. */ -static struct mtx unp_mtx; -#define UNP_LOCK_INIT() \ - mtx_init(&unp_mtx, "unp", NULL, MTX_DEF) -#define UNP_LOCK() mtx_lock(&unp_mtx) -#define UNP_UNLOCK() mtx_unlock(&unp_mtx) -#define UNP_LOCK_ASSERT() mtx_assert(&unp_mtx, MA_OWNED) -#define UNP_UNLOCK_ASSERT() mtx_assert(&unp_mtx, MA_NOTOWNED) +static struct mtx unp_global_mtx; + +#define UNP_GLOBAL_LOCK_INIT() mtx_init(&unp_global_mtx, \ + "unp_global_mtx", NULL, MTX_DEF) +#define UNP_GLOBAL_LOCK() mtx_lock(&unp_global_mtx) +#define UNP_GLOBAL_UNLOCK() mtx_unlock(&unp_global_mtx) +#define UNP_GLOBAL_UNLOCK_ASSERT() mtx_assert(&unp_global_mtx, MA_NOTOWNED) +#define UNP_GLOBAL_LOCK_ASSERT() mtx_assert(&unp_global_mtx, MA_OWNED) + +#define UNP_PCB_LOCK_INIT(unp) mtx_init(&(unp)->unp_mtx, \ + "unp_mtx", "unp_mtx", \ + MTX_DUPOK|MTX_DEF|MTX_RECURSE) +#define UNP_PCB_LOCK_DESTROY(unp) mtx_destroy(&(unp)->unp_mtx) +#define UNP_PCB_LOCK(unp) mtx_lock(&(unp)->unp_mtx) +#define UNP_PCB_UNLOCK(unp) mtx_unlock(&(unp)->unp_mtx) +#define UNP_PCB_LOCK_ASSERT(unp) mtx_assert(&(unp)->unp_mtx, MA_OWNED) /* * Garbage collection of cyclic file descriptor/socket references occurs @@ -123,12 +190,10 @@ */ static struct task unp_gc_task; -static int unp_attach(struct socket *); static void unp_detach(struct unpcb *); -static int unp_bind(struct unpcb *,struct sockaddr *, struct thread *); static int unp_connect(struct socket *,struct sockaddr *, struct thread *); static int unp_connect2(struct socket *so, struct socket *so2, int); -static void unp_disconnect(struct unpcb *); +static void unp_disconnect(struct unpcb *unp, struct unpcb *unp2); static void unp_shutdown(struct unpcb *); static void unp_drop(struct unpcb *, int); static void unp_gc(__unused void *, int); @@ -137,8 +202,6 @@ static void unp_discard(struct file *); static void unp_freerights(struct file **, int); static int unp_internalize(struct mbuf **, struct thread *); -static int unp_listen(struct socket *, struct unpcb *, int, - struct thread *); static void uipc_abort(struct socket *so) @@ -147,83 +210,238 @@ unp = sotounpcb(so); KASSERT(unp != NULL, ("uipc_abort: unp == NULL")); - UNP_LOCK(); + + UNP_GLOBAL_LOCK(); + UNP_PCB_LOCK(unp); unp_drop(unp, ECONNABORTED); unp_detach(unp); - UNP_UNLOCK_ASSERT(); + UNP_GLOBAL_UNLOCK_ASSERT(); } static int uipc_accept(struct socket *so, struct sockaddr **nam) { - struct unpcb *unp; + struct unpcb *unp, *unp2; const struct sockaddr *sa; /* - * Pass back name of connected socket, - * if it was bound and we are still connected - * (our peer may have closed already!). + * Pass back name of connected socket, if it was bound and we are + * still connected (our peer may have closed already!). */ unp = sotounpcb(so); KASSERT(unp != NULL, ("uipc_accept: unp == NULL")); + *nam = malloc(sizeof(struct sockaddr_un), M_SONAME, M_WAITOK); - UNP_LOCK(); - if (unp->unp_conn != NULL && unp->unp_conn->unp_addr != NULL) + UNP_GLOBAL_LOCK(); + UNP_PCB_LOCK(unp); + unp2 = unp->unp_conn; + if (unp->unp_conn != NULL && unp->unp_conn->unp_addr != NULL) { + UNP_PCB_LOCK(unp2); sa = (struct sockaddr *) unp->unp_conn->unp_addr; - else + bcopy(sa, *nam, sa->sa_len); + UNP_PCB_UNLOCK(unp2); + } else { sa = &sun_noname; - bcopy(sa, *nam, sa->sa_len); - UNP_UNLOCK(); + bcopy(sa, *nam, sa->sa_len); + } + UNP_PCB_UNLOCK(unp); + UNP_GLOBAL_UNLOCK(); return (0); } static int uipc_attach(struct socket *so, int proto, struct thread *td) { + u_long sendspace, recvspace; + struct unpcb *unp; + int error; + + KASSERT(so->so_pcb == NULL, ("uipc_attach: so_pcb != NULL")); + if (so->so_snd.sb_hiwat == 0 || so->so_rcv.sb_hiwat == 0) { + switch (so->so_type) { + case SOCK_STREAM: + sendspace = unpst_sendspace; + recvspace = unpst_recvspace; + break; + + case SOCK_DGRAM: + sendspace = unpdg_sendspace; + recvspace = unpdg_recvspace; + break; + + default: + panic("uipc_attach"); + } + error = soreserve(so, sendspace, recvspace); + if (error) + return (error); + } + unp = uma_zalloc(unp_zone, M_WAITOK | M_ZERO); + if (unp == NULL) + return (ENOBUFS); + LIST_INIT(&unp->unp_refs); + UNP_PCB_LOCK_INIT(unp); + unp->unp_socket = so; + so->so_pcb = unp; + + UNP_GLOBAL_LOCK(); + unp->unp_gencnt = ++unp_gencnt; + unp_count++; + LIST_INSERT_HEAD(so->so_type == SOCK_DGRAM ? &unp_dhead + : &unp_shead, unp, unp_link); + UNP_GLOBAL_UNLOCK(); - return (unp_attach(so)); + return (0); } static int uipc_bind(struct socket *so, struct sockaddr *nam, struct thread *td) { + struct sockaddr_un *soun = (struct sockaddr_un *)nam; + struct vnode *vp; + struct mount *mp; + struct vattr vattr; + int error, namelen; + struct nameidata nd; struct unpcb *unp; - int error; + char *buf; unp = sotounpcb(so); KASSERT(unp != NULL, ("uipc_bind: unp == NULL")); - UNP_LOCK(); - error = unp_bind(unp, nam, td); - UNP_UNLOCK(); + + namelen = soun->sun_len - offsetof(struct sockaddr_un, sun_path); + if (namelen <= 0) + return (EINVAL); + + /* + * We don't allow simultaneous bind() calls on a single UNIX domain + * socket, so flag in-progress operations, and return an error if an + * operation is already in progress. + * + * Historically, we have not allowed a socket to be rebound, so this + * also returns an error. Not allowing re-binding certainly + * simplifies the implementation and avoids a great many possible + * failure modes. + */ + UNP_PCB_LOCK(unp); + if (unp->unp_vnode != NULL) { + UNP_PCB_UNLOCK(unp); + return (EINVAL); + } + if (unp->unp_flags & UNP_BINDING) { + UNP_PCB_UNLOCK(unp); + return (EALREADY); + } + unp->unp_flags |= UNP_BINDING; + UNP_PCB_UNLOCK(unp); + + buf = malloc(namelen + 1, M_TEMP, M_WAITOK); + strlcpy(buf, soun->sun_path, namelen + 1); + + mtx_lock(&Giant); +restart: + mtx_assert(&Giant, MA_OWNED); + NDINIT(&nd, CREATE, NOFOLLOW | LOCKPARENT | SAVENAME, UIO_SYSSPACE, + buf, td); +/* SHOULD BE ABLE TO ADOPT EXISTING AND wakeup() ALA FIFO's */ + error = namei(&nd); + if (error) + goto error; + vp = nd.ni_vp; + if (vp != NULL || vn_start_write(nd.ni_dvp, &mp, V_NOWAIT) != 0) { + NDFREE(&nd, NDF_ONLY_PNBUF); + if (nd.ni_dvp == vp) + vrele(nd.ni_dvp); + else + vput(nd.ni_dvp); + if (vp != NULL) { + vrele(vp); + error = EADDRINUSE; + goto error; + } + error = vn_start_write(NULL, &mp, V_XSLEEP | PCATCH); + if (error) + goto error; + goto restart; + } + VATTR_NULL(&vattr); + vattr.va_type = VSOCK; + vattr.va_mode = (ACCESSPERMS & ~td->td_proc->p_fd->fd_cmask); +#ifdef MAC + error = mac_check_vnode_create(td->td_ucred, nd.ni_dvp, &nd.ni_cnd, + &vattr); +#endif + if (error == 0) { + VOP_LEASE(nd.ni_dvp, td, td->td_ucred, LEASE_WRITE); + error = VOP_CREATE(nd.ni_dvp, &nd.ni_vp, &nd.ni_cnd, &vattr); + } + NDFREE(&nd, NDF_ONLY_PNBUF); + vput(nd.ni_dvp); + if (error) { + vn_finished_write(mp); + goto error; + } + vp = nd.ni_vp; + ASSERT_VOP_LOCKED(vp, "uipc_bind"); + soun = (struct sockaddr_un *)sodupsockaddr(nam, M_WAITOK); + + /* + * XXXRW: handle race against another consumer also frobbing + * v_socket? Or not. + */ + UNP_GLOBAL_LOCK(); + UNP_PCB_LOCK(unp); + vp->v_socket = unp->unp_socket; + unp->unp_vnode = vp; + unp->unp_addr = soun; + unp->unp_flags &= ~UNP_BINDING; + UNP_PCB_UNLOCK(unp); + UNP_GLOBAL_UNLOCK(); + VOP_UNLOCK(vp, 0, td); + vn_finished_write(mp); + mtx_unlock(&Giant); + free(buf, M_TEMP); + return (0); + +error: + UNP_PCB_LOCK(unp); + unp->unp_flags &= ~UNP_BINDING; + UNP_PCB_UNLOCK(unp); + mtx_unlock(&Giant); + free(buf, M_TEMP); return (error); } static int uipc_connect(struct socket *so, struct sockaddr *nam, struct thread *td) { - struct unpcb *unp; int error; KASSERT(td == curthread, ("uipc_connect: td != curthread")); - unp = sotounpcb(so); - KASSERT(unp != NULL, ("uipc_connect: unp == NULL")); - UNP_LOCK(); + + UNP_GLOBAL_LOCK(); error = unp_connect(so, nam, td); - UNP_UNLOCK(); + UNP_GLOBAL_UNLOCK(); return (error); } int uipc_connect2(struct socket *so1, struct socket *so2) { - struct unpcb *unp; + struct unpcb *unp, *unp2; int error; - unp = sotounpcb(so1); + UNP_GLOBAL_LOCK(); + unp = so1->so_pcb; KASSERT(unp != NULL, ("uipc_connect2: unp == NULL")); - UNP_LOCK(); + UNP_PCB_LOCK(unp); + unp2 = so2->so_pcb; + KASSERT(unp2 != NULL, ("uipc_connect2: unp2 == NULL")); + UNP_PCB_LOCK(unp2); error = unp_connect2(so1, so2, PRU_CONNECT2); - UNP_UNLOCK(); + UNP_PCB_UNLOCK(unp2); + UNP_PCB_UNLOCK(unp); + UNP_GLOBAL_UNLOCK(); return (error); } @@ -236,21 +454,31 @@ unp = sotounpcb(so); KASSERT(unp != NULL, ("uipc_detach: unp == NULL")); - UNP_LOCK(); + + UNP_GLOBAL_LOCK(); + UNP_PCB_LOCK(unp); unp_detach(unp); - UNP_UNLOCK_ASSERT(); + UNP_GLOBAL_UNLOCK_ASSERT(); } static int uipc_disconnect(struct socket *so) { - struct unpcb *unp; + struct unpcb *unp, *unp2; unp = sotounpcb(so); KASSERT(unp != NULL, ("uipc_disconnect: unp == NULL")); - UNP_LOCK(); - unp_disconnect(unp); - UNP_UNLOCK(); + + UNP_GLOBAL_LOCK(); + UNP_PCB_LOCK(unp); + unp2 = unp->unp_conn; + if (unp2 != NULL) { + UNP_PCB_LOCK(unp2); + unp_disconnect(unp, unp2); + UNP_PCB_UNLOCK(unp2); + } + UNP_PCB_UNLOCK(unp); + UNP_GLOBAL_UNLOCK(); return (0); } @@ -262,81 +490,105 @@ unp = sotounpcb(so); KASSERT(unp != NULL, ("uipc_listen: unp == NULL")); - UNP_LOCK(); + + UNP_PCB_LOCK(unp); if (unp->unp_vnode == NULL) { - UNP_UNLOCK(); + UNP_PCB_UNLOCK(unp); return (EINVAL); } - error = unp_listen(so, unp, backlog, td); - UNP_UNLOCK(); + + SOCK_LOCK(so); + error = solisten_proto_check(so); + if (error == 0) { + cru2x(td->td_ucred, &unp->unp_peercred); + unp->unp_flags |= UNP_HAVEPCCACHED; + solisten_proto(so, backlog); + } + SOCK_UNLOCK(so); + UNP_PCB_UNLOCK(unp); return (error); } static int uipc_peeraddr(struct socket *so, struct sockaddr **nam) { - struct unpcb *unp; + struct unpcb *unp, *unp2; const struct sockaddr *sa; unp = sotounpcb(so); KASSERT(unp != NULL, ("uipc_peeraddr: unp == NULL")); + *nam = malloc(sizeof(struct sockaddr_un), M_SONAME, M_WAITOK); - UNP_LOCK(); - if (unp->unp_conn != NULL && unp->unp_conn->unp_addr!= NULL) - sa = (struct sockaddr *) unp->unp_conn->unp_addr; - else { - /* - * XXX: It seems that this test always fails even when - * connection is established. So, this else clause is - * added as workaround to return PF_LOCAL sockaddr. - */ + UNP_PCB_LOCK(unp); + /* + * XXX: It seems that this test always fails even when connection is + * established. So, this else clause is added as workaround to + * return PF_LOCAL sockaddr. + */ + unp2 = unp->unp_conn; + if (unp2 != NULL) { + UNP_PCB_LOCK(unp2); + if (unp2->unp_addr != NULL) + sa = (struct sockaddr *) unp->unp_conn->unp_addr; + else + sa = &sun_noname; + bcopy(sa, *nam, sa->sa_len); + UNP_PCB_UNLOCK(unp2); + } else { sa = &sun_noname; + bcopy(sa, *nam, sa->sa_len); } - bcopy(sa, *nam, sa->sa_len); - UNP_UNLOCK(); + UNP_PCB_UNLOCK(unp); return (0); } static int uipc_rcvd(struct socket *so, int flags) { - struct unpcb *unp; + struct unpcb *unp, *unp2; struct socket *so2; u_long newhiwat; unp = sotounpcb(so); KASSERT(unp != NULL, ("uipc_rcvd: unp == NULL")); - UNP_LOCK(); - switch (so->so_type) { - case SOCK_DGRAM: + + if (so->so_type == SOCK_DGRAM) panic("uipc_rcvd DGRAM?"); - /*NOTREACHED*/ - case SOCK_STREAM: - if (unp->unp_conn == NULL) - break; - so2 = unp->unp_conn->unp_socket; - SOCKBUF_LOCK(&so2->so_snd); - SOCKBUF_LOCK(&so->so_rcv); - /* - * Adjust backpressure on sender - * and wakeup any waiting to write. - */ - so2->so_snd.sb_mbmax += unp->unp_mbcnt - so->so_rcv.sb_mbcnt; - unp->unp_mbcnt = so->so_rcv.sb_mbcnt; - newhiwat = so2->so_snd.sb_hiwat + unp->unp_cc - - so->so_rcv.sb_cc; - (void)chgsbsize(so2->so_cred->cr_uidinfo, &so2->so_snd.sb_hiwat, - newhiwat, RLIM_INFINITY); - unp->unp_cc = so->so_rcv.sb_cc; - SOCKBUF_UNLOCK(&so->so_rcv); - sowwakeup_locked(so2); - break; + if (so->so_type != SOCK_STREAM) + panic("uipc_rcvd unknown socktype"); - default: - panic("uipc_rcvd unknown socktype"); + /* + * Adjust backpressure on sender and wakeup any waiting to write. + * + * The consistency requirements here are a bit complex: we must + * acquire the lock for our own unpcb in order to prevent it from + * disconnecting while in use, changing the unp_conn peer. We do not + * need unp2's lock, since the unp2->unp_socket pointer will remain + * static as long as the unp2 pcb is valid, which it will be until we + * release unp's lock to allow a disconnect. We do need socket + * mutexes for both socket endpoints since we manipulate fields in + * both; we hold both locks at once since we access both + * simultaneously. + */ + UNP_PCB_LOCK(unp); + unp2 = unp->unp_conn; + if (unp2 == NULL) { + UNP_PCB_UNLOCK(unp); + return (0); } - UNP_UNLOCK(); + so2 = unp2->unp_socket; + SOCKBUF_LOCK(&so2->so_snd); + SOCKBUF_LOCK(&so->so_rcv); + so2->so_snd.sb_mbmax += unp->unp_mbcnt - so->so_rcv.sb_mbcnt; + unp->unp_mbcnt = so->so_rcv.sb_mbcnt; + newhiwat = so2->so_snd.sb_hiwat + unp->unp_cc - so->so_rcv.sb_cc; + (void)chgsbsize(so2->so_cred->cr_uidinfo, &so2->so_snd.sb_hiwat, + newhiwat, RLIM_INFINITY); + unp->unp_cc = so->so_rcv.sb_cc; + SOCKBUF_UNLOCK(&so->so_rcv); + sowwakeup_locked(so2); + UNP_PCB_UNLOCK(unp); return (0); } @@ -346,13 +598,14 @@ uipc_send(struct socket *so, int flags, struct mbuf *m, struct sockaddr *nam, struct mbuf *control, struct thread *td) { - int error = 0; - struct unpcb *unp; + struct unpcb *unp, *unp2; struct socket *so2; u_long newhiwat; + int error = 0; unp = sotounpcb(so); KASSERT(unp != NULL, ("uipc_send: unp == NULL")); + if (flags & PRUS_OOB) { error = EOPNOTSUPP; goto release; @@ -361,32 +614,38 @@ if (control != NULL && (error = unp_internalize(&control, td))) goto release; - UNP_LOCK(); + UNP_GLOBAL_LOCK(); + UNP_PCB_LOCK(unp); switch (so->so_type) { case SOCK_DGRAM: { const struct sockaddr *from; + unp2 = unp->unp_conn; if (nam != NULL) { - if (unp->unp_conn != NULL) { + if (unp2 != NULL) { error = EISCONN; break; } + UNP_PCB_UNLOCK(unp); error = unp_connect(so, nam, td); + UNP_PCB_LOCK(unp); if (error) break; + unp2 = unp->unp_conn; } else { - if (unp->unp_conn == NULL) { + if (unp2 == NULL) { error = ENOTCONN; break; } } - so2 = unp->unp_conn->unp_socket; + UNP_PCB_LOCK(unp2); + so2 = unp2->unp_socket; if (unp->unp_addr != NULL) from = (struct sockaddr *)unp->unp_addr; else from = &sun_noname; - if (unp->unp_conn->unp_flags & UNP_WANTCRED) + if (unp2->unp_flags & UNP_WANTCRED) control = unp_addsockcred(td, control); SOCKBUF_LOCK(&so2->so_rcv); if (sbappendaddr_locked(&so2->so_rcv, from, m, control)) { @@ -398,19 +657,22 @@ error = ENOBUFS; } if (nam != NULL) - unp_disconnect(unp); + unp_disconnect(unp, unp2); + UNP_PCB_UNLOCK(unp2); break; } case SOCK_STREAM: /* Connect if not connected yet. */ /* - * Note: A better implementation would complain - * if not equal to the peer's address. + * Note: A better implementation would complain if not equal + * to the peer's address. */ if ((so->so_state & SS_ISCONNECTED) == 0) { if (nam != NULL) { + UNP_PCB_UNLOCK(unp); error = unp_connect(so, nam, td); + UNP_PCB_LOCK(unp); if (error) break; /* XXX */ } else { @@ -419,22 +681,34 @@ } } + /* + * Lock order here has to be handled carefully: we hold the + * global lock, so acquiring two unpcb locks is OK. We must + * acquire both before acquiring any socket mutexes. We must + * also acquire the local socket send mutex before the remote + * socket receive mutex. The only tricky thing is making + * sure to acquire the unp2 lock before the local socket send + * lock, or we will experience deadlocks. + */ + unp2 = unp->unp_conn; + KASSERT(unp2 != NULL, + ("uipc_send connected but no connection?")); + UNP_PCB_LOCK(unp2); SOCKBUF_LOCK(&so->so_snd); if (so->so_snd.sb_state & SBS_CANTSENDMORE) { SOCKBUF_UNLOCK(&so->so_snd); + UNP_PCB_UNLOCK(unp2); error = EPIPE; break; } - if (unp->unp_conn == NULL) - panic("uipc_send connected but no connection?"); - so2 = unp->unp_conn->unp_socket; + so2 = unp2->unp_socket; SOCKBUF_LOCK(&so2->so_rcv); - if (unp->unp_conn->unp_flags & UNP_WANTCRED) { + if (unp2->unp_flags & UNP_WANTCRED) { /* * Credentials are passed only once on * SOCK_STREAM. */ - unp->unp_conn->unp_flags &= ~UNP_WANTCRED; + unp2->unp_flags &= ~UNP_WANTCRED; control = unp_addsockcred(td, control); } /* @@ -445,19 +719,19 @@ if (control != NULL) { if (sbappendcontrol_locked(&so2->so_rcv, m, control)) control = NULL; - } else { + } else sbappend_locked(&so2->so_rcv, m); - } so->so_snd.sb_mbmax -= so2->so_rcv.sb_mbcnt - unp->unp_conn->unp_mbcnt; - unp->unp_conn->unp_mbcnt = so2->so_rcv.sb_mbcnt; + unp2->unp_mbcnt = so2->so_rcv.sb_mbcnt; newhiwat = so->so_snd.sb_hiwat - - (so2->so_rcv.sb_cc - unp->unp_conn->unp_cc); + (so2->so_rcv.sb_cc - unp2->unp_cc); (void)chgsbsize(so->so_cred->cr_uidinfo, &so->so_snd.sb_hiwat, newhiwat, RLIM_INFINITY); SOCKBUF_UNLOCK(&so->so_snd); - unp->unp_conn->unp_cc = so2->so_rcv.sb_cc; + unp2->unp_cc = so2->so_rcv.sb_cc; sorwakeup_locked(so2); + UNP_PCB_UNLOCK(unp2); m = NULL; break; @@ -473,7 +747,8 @@ socantsendmore(so); unp_shutdown(unp); } - UNP_UNLOCK(); + UNP_PCB_UNLOCK(unp); + UNP_GLOBAL_UNLOCK(); if (control != NULL && error != 0) unp_dispose(control); @@ -489,22 +764,28 @@ static int uipc_sense(struct socket *so, struct stat *sb) { - struct unpcb *unp; + struct unpcb *unp, *unp2; struct socket *so2; unp = sotounpcb(so); KASSERT(unp != NULL, ("uipc_sense: unp == NULL")); - UNP_LOCK(); + + UNP_GLOBAL_LOCK(); + UNP_PCB_LOCK(unp); sb->st_blksize = so->so_snd.sb_hiwat; - if (so->so_type == SOCK_STREAM && unp->unp_conn != NULL) { - so2 = unp->unp_conn->unp_socket; + unp2 = unp->unp_conn; + if (so->so_type == SOCK_STREAM && unp2 != NULL) { + UNP_PCB_LOCK(unp2); + so2 = unp2->unp_socket; sb->st_blksize += so2->so_rcv.sb_cc; + UNP_PCB_UNLOCK(unp2); } sb->st_dev = NODEV; if (unp->unp_ino == 0) unp->unp_ino = (++unp_ino == 0) ? ++unp_ino : unp_ino; sb->st_ino = unp->unp_ino; - UNP_UNLOCK(); + UNP_PCB_UNLOCK(unp); + UNP_GLOBAL_UNLOCK(); return (0); } @@ -515,10 +796,13 @@ unp = sotounpcb(so); KASSERT(unp != NULL, ("uipc_shutdown: unp == NULL")); - UNP_LOCK(); + + UNP_GLOBAL_LOCK(); + UNP_PCB_LOCK(unp); socantsendmore(so); unp_shutdown(unp); - UNP_UNLOCK(); + UNP_PCB_UNLOCK(unp); + UNP_GLOBAL_UNLOCK(); return (0); } @@ -530,14 +814,15 @@ unp = sotounpcb(so); KASSERT(unp != NULL, ("uipc_sockaddr: unp == NULL")); + *nam = malloc(sizeof(struct sockaddr_un), M_SONAME, M_WAITOK); - UNP_LOCK(); + UNP_PCB_LOCK(unp); if (unp->unp_addr != NULL) sa = (struct sockaddr *) unp->unp_addr; else sa = &sun_noname; bcopy(sa, *nam, sa->sa_len); - UNP_UNLOCK(); + UNP_PCB_UNLOCK(unp); return (0); } @@ -574,12 +859,13 @@ unp = sotounpcb(so); KASSERT(unp != NULL, ("uipc_ctloutput: unp == NULL")); - UNP_LOCK(); + error = 0; switch (sopt->sopt_dir) { case SOPT_GET: switch (sopt->sopt_name) { case LOCAL_PEERCRED: + UNP_PCB_LOCK(unp); if (unp->unp_flags & UNP_HAVEPC) xu = unp->unp_peercred; else { @@ -588,22 +874,31 @@ else error = EINVAL; } + UNP_PCB_UNLOCK(unp); if (error == 0) error = sooptcopyout(sopt, &xu, sizeof(xu)); break; + case LOCAL_CREDS: + UNP_PCB_LOCK(unp); optval = unp->unp_flags & UNP_WANTCRED ? 1 : 0; + UNP_PCB_UNLOCK(unp); error = sooptcopyout(sopt, &optval, sizeof(optval)); break; + case LOCAL_CONNWAIT: + UNP_PCB_LOCK(unp); optval = unp->unp_flags & UNP_CONNWAIT ? 1 : 0; + UNP_PCB_UNLOCK(unp); error = sooptcopyout(sopt, &optval, sizeof(optval)); break; + default: error = EOPNOTSUPP; break; } break; + case SOPT_SET: switch (sopt->sopt_name) { case LOCAL_CREDS: @@ -613,19 +908,24 @@ if (error) break; -#define OPTSET(bit) \ - if (optval) \ - unp->unp_flags |= bit; \ - else \ - unp->unp_flags &= ~bit; +#define OPTSET(bit) do { \ + UNP_PCB_LOCK(unp); \ + if (optval) \ + unp->unp_flags |= bit; \ + else \ + unp->unp_flags &= ~bit; \ + UNP_PCB_UNLOCK(unp); \ +} while (0) switch (sopt->sopt_name) { case LOCAL_CREDS: OPTSET(UNP_WANTCRED); break; + case LOCAL_CONNWAIT: OPTSET(UNP_CONNWAIT); break; + default: break; } @@ -636,117 +936,60 @@ break; } break; + default: error = EOPNOTSUPP; break; } - UNP_UNLOCK(); return (error); } -/* - * Both send and receive buffers are allocated PIPSIZ bytes of buffering - * for stream sockets, although the total for sender and receiver is - * actually only PIPSIZ. - * Datagram sockets really use the sendspace as the maximum datagram size, - * and don't really want to reserve the sendspace. Their recvspace should - * be large enough for at least one max-size datagram plus address. - */ -#ifndef PIPSIZ -#define PIPSIZ 8192 -#endif -static u_long unpst_sendspace = PIPSIZ; -static u_long unpst_recvspace = PIPSIZ; -static u_long unpdg_sendspace = 2*1024; /* really max datagram size */ -static u_long unpdg_recvspace = 4*1024; - -static int unp_rights; /* file descriptors in flight */ - -SYSCTL_DECL(_net_local_stream); -SYSCTL_ULONG(_net_local_stream, OID_AUTO, sendspace, CTLFLAG_RW, - &unpst_sendspace, 0, ""); -SYSCTL_ULONG(_net_local_stream, OID_AUTO, recvspace, CTLFLAG_RW, - &unpst_recvspace, 0, ""); -SYSCTL_DECL(_net_local_dgram); -SYSCTL_ULONG(_net_local_dgram, OID_AUTO, maxdgram, CTLFLAG_RW, - &unpdg_sendspace, 0, ""); -SYSCTL_ULONG(_net_local_dgram, OID_AUTO, recvspace, CTLFLAG_RW, - &unpdg_recvspace, 0, ""); -SYSCTL_DECL(_net_local); -SYSCTL_INT(_net_local, OID_AUTO, inflight, CTLFLAG_RD, &unp_rights, 0, ""); - -static int -unp_attach(struct socket *so) -{ - struct unpcb *unp; - int error; - - KASSERT(so->so_pcb == NULL, ("unp_attach: so_pcb != NULL")); - if (so->so_snd.sb_hiwat == 0 || so->so_rcv.sb_hiwat == 0) { - switch (so->so_type) { - - case SOCK_STREAM: - error = soreserve(so, unpst_sendspace, unpst_recvspace); - break; - - case SOCK_DGRAM: - error = soreserve(so, unpdg_sendspace, unpdg_recvspace); - break; - - default: - panic("unp_attach"); - } - if (error) - return (error); - } - unp = uma_zalloc(unp_zone, M_WAITOK | M_ZERO); - if (unp == NULL) - return (ENOBUFS); - LIST_INIT(&unp->unp_refs); - unp->unp_socket = so; - so->so_pcb = unp; - - UNP_LOCK(); - unp->unp_gencnt = ++unp_gencnt; - unp_count++; - LIST_INSERT_HEAD(so->so_type == SOCK_DGRAM ? &unp_dhead - : &unp_shead, unp, unp_link); - UNP_UNLOCK(); - - return (0); -} - static void unp_detach(struct unpcb *unp) { + int local_unp_rights; struct vnode *vp; - int local_unp_rights; + struct unpcb *unp2; - UNP_LOCK_ASSERT(); + UNP_GLOBAL_LOCK_ASSERT(); + UNP_PCB_LOCK_ASSERT(unp); LIST_REMOVE(unp, unp_link); unp->unp_gencnt = ++unp_gencnt; --unp_count; + + /* + * XXXRW: What if v_socket != our soket? + */ if ((vp = unp->unp_vnode) != NULL) { - /* - * XXXRW: should v_socket be frobbed only while holding - * Giant? - */ unp->unp_vnode->v_socket = NULL; unp->unp_vnode = NULL; } - if (unp->unp_conn != NULL) - unp_disconnect(unp); + unp2 = unp->unp_conn; + if (unp2 != NULL) { + UNP_PCB_LOCK(unp2); + unp_disconnect(unp, unp2); + UNP_PCB_UNLOCK(unp2); + } + + /* + * We hold the global lock, so it's OK to acquire multiple pcb locks + * at a time. + */ while (!LIST_EMPTY(&unp->unp_refs)) { struct unpcb *ref = LIST_FIRST(&unp->unp_refs); + + UNP_PCB_LOCK(ref); unp_drop(ref, ECONNRESET); + UNP_PCB_UNLOCK(ref); } + UNP_GLOBAL_UNLOCK(); soisdisconnected(unp->unp_socket); unp->unp_socket->so_pcb = NULL; local_unp_rights = unp_rights; - UNP_UNLOCK(); if (unp->unp_addr != NULL) FREE(unp->unp_addr, M_SONAME); + UNP_PCB_LOCK_DESTROY(unp); uma_zfree(unp_zone, unp); if (vp) { int vfslocked; @@ -760,97 +1003,6 @@ } static int -unp_bind(struct unpcb *unp, struct sockaddr *nam, struct thread *td) -{ - struct sockaddr_un *soun = (struct sockaddr_un *)nam; - struct vnode *vp; - struct mount *mp; - struct vattr vattr; - int error, namelen; - struct nameidata nd; - char *buf; - - UNP_LOCK_ASSERT(); - - /* - * XXXRW: This test-and-set of unp_vnode is non-atomic; the - * unlocked read here is fine, but the value of unp_vnode needs - * to be tested again after we do all the lookups to see if the - * pcb is still unbound? - */ - if (unp->unp_vnode != NULL) - return (EINVAL); - - namelen = soun->sun_len - offsetof(struct sockaddr_un, sun_path); - if (namelen <= 0) - return (EINVAL); - - UNP_UNLOCK(); - - buf = malloc(namelen + 1, M_TEMP, M_WAITOK); - strlcpy(buf, soun->sun_path, namelen + 1); - - mtx_lock(&Giant); -restart: - mtx_assert(&Giant, MA_OWNED); - NDINIT(&nd, CREATE, NOFOLLOW | LOCKPARENT | SAVENAME, UIO_SYSSPACE, - buf, td); -/* SHOULD BE ABLE TO ADOPT EXISTING AND wakeup() ALA FIFO's */ - error = namei(&nd); - if (error) - goto done; - vp = nd.ni_vp; - if (vp != NULL || vn_start_write(nd.ni_dvp, &mp, V_NOWAIT) != 0) { - NDFREE(&nd, NDF_ONLY_PNBUF); - if (nd.ni_dvp == vp) - vrele(nd.ni_dvp); - else - vput(nd.ni_dvp); - if (vp != NULL) { - vrele(vp); - error = EADDRINUSE; - goto done; - } - error = vn_start_write(NULL, &mp, V_XSLEEP | PCATCH); - if (error) - goto done; - goto restart; - } - VATTR_NULL(&vattr); - vattr.va_type = VSOCK; - vattr.va_mode = (ACCESSPERMS & ~td->td_proc->p_fd->fd_cmask); -#ifdef MAC - error = mac_check_vnode_create(td->td_ucred, nd.ni_dvp, &nd.ni_cnd, - &vattr); -#endif - if (error == 0) { - VOP_LEASE(nd.ni_dvp, td, td->td_ucred, LEASE_WRITE); - error = VOP_CREATE(nd.ni_dvp, &nd.ni_vp, &nd.ni_cnd, &vattr); - } - NDFREE(&nd, NDF_ONLY_PNBUF); - vput(nd.ni_dvp); - if (error) { - vn_finished_write(mp); - goto done; - } - vp = nd.ni_vp; - ASSERT_VOP_LOCKED(vp, "unp_bind"); - soun = (struct sockaddr_un *)sodupsockaddr(nam, M_WAITOK); - UNP_LOCK(); - vp->v_socket = unp->unp_socket; - unp->unp_vnode = vp; - unp->unp_addr = soun; - UNP_UNLOCK(); - VOP_UNLOCK(vp, 0, td); - vn_finished_write(mp); -done: - mtx_unlock(&Giant); - free(buf, M_TEMP); - UNP_LOCK(); - return (error); -} - -static int unp_connect(struct socket *so, struct sockaddr *nam, struct thread *td) { struct sockaddr_un *soun = (struct sockaddr_un *)nam; @@ -862,15 +1014,25 @@ char buf[SOCK_MAXADDRLEN]; struct sockaddr *sa; - UNP_LOCK_ASSERT(); + UNP_GLOBAL_LOCK_ASSERT(); + UNP_GLOBAL_UNLOCK(); unp = sotounpcb(so); KASSERT(unp != NULL, ("unp_connect: unp == NULL")); + len = nam->sa_len - offsetof(struct sockaddr_un, sun_path); if (len <= 0) return (EINVAL); strlcpy(buf, soun->sun_path, len + 1); - UNP_UNLOCK(); + + UNP_PCB_LOCK(unp); + if (unp->unp_flags & UNP_CONNECTING) { + UNP_PCB_UNLOCK(unp); + return (EALREADY); + } + unp->unp_flags |= UNP_CONNECTING; + UNP_PCB_UNLOCK(unp); + sa = malloc(sizeof(struct sockaddr_un), M_SONAME, M_WAITOK); mtx_lock(&Giant); NDINIT(&nd, LOOKUP, FOLLOW | LOCKLEAF, UIO_SYSSPACE, buf, td); @@ -892,9 +1054,15 @@ if (error) goto bad; mtx_unlock(&Giant); - UNP_LOCK(); + unp = sotounpcb(so); KASSERT(unp != NULL, ("unp_connect: unp == NULL")); + + /* + * Lock global lock for two reasons: make sure v_socket is stable, + * and to protect simultaneous locking of multiple pcbs. + */ + UNP_GLOBAL_LOCK(); so2 = vp->v_socket; if (so2 == NULL) { error = ECONNREFUSED; @@ -907,14 +1075,18 @@ if (so->so_proto->pr_flags & PR_CONNREQUIRED) { if (so2->so_options & SO_ACCEPTCONN) { /* - * NB: drop locks here so unp_attach is entered + * NB: drop locks here so uipc_attach is entered * w/o locks; this avoids a recursive lock * of the head and holding sleep locks across * a (potentially) blocking malloc. + * + * XXXRW: This is actually a non-blocking alloc. + * Lock order issue is real. Releasing lock here + * may invalidate so2 pointer, however. */ - UNP_UNLOCK(); + UNP_GLOBAL_UNLOCK(); so3 = sonewconn(so2, 0); - UNP_LOCK(); + UNP_GLOBAL_LOCK(); } else so3 = NULL; if (so3 == NULL) { @@ -924,6 +1096,9 @@ unp = sotounpcb(so); unp2 = sotounpcb(so2); unp3 = sotounpcb(so3); + UNP_PCB_LOCK(unp); + UNP_PCB_LOCK(unp2); + UNP_PCB_LOCK(unp3); if (unp2->unp_addr != NULL) { bcopy(unp2->unp_addr, sa, unp2->unp_addr->sun_len); unp3->unp_addr = (struct sockaddr_un *) sa; @@ -941,7 +1116,7 @@ /* * The receiver's (server's) credentials are copied * from the unp_peercred member of socket on which the - * former called listen(); unp_listen() cached that + * former called listen(); uipc_listen() cached that * process's credentials at that time so we can use * them now. */ @@ -952,6 +1127,9 @@ unp->unp_flags |= UNP_HAVEPC; if (unp2->unp_flags & UNP_WANTCRED) unp3->unp_flags |= UNP_WANTCRED; + UNP_PCB_UNLOCK(unp3); + UNP_PCB_UNLOCK(unp2); + UNP_PCB_UNLOCK(unp); #ifdef MAC SOCK_LOCK(so); mac_set_socket_peer_from_socket(so, so3); @@ -961,9 +1139,17 @@ so2 = so3; } + unp = sotounpcb(so); + KASSERT(unp != NULL, ("unp_connect: unp == NULL")); + unp2 = sotounpcb(so2); + KASSERT(unp2 != NULL, ("unp_connect: unp2 == NULL")); + UNP_PCB_LOCK(unp); + UNP_PCB_LOCK(unp2); error = unp_connect2(so, so2, PRU_CONNECT); + UNP_PCB_UNLOCK(unp2); + UNP_PCB_UNLOCK(unp); bad2: - UNP_UNLOCK(); + UNP_GLOBAL_UNLOCK(); mtx_lock(&Giant); bad: mtx_assert(&Giant, MA_OWNED); @@ -971,25 +1157,33 @@ vput(vp); mtx_unlock(&Giant); free(sa, M_SONAME); - UNP_LOCK(); + UNP_GLOBAL_LOCK(); + UNP_PCB_LOCK(unp); + unp->unp_flags &= ~UNP_CONNECTING; + UNP_PCB_UNLOCK(unp); return (error); } static int unp_connect2(struct socket *so, struct socket *so2, int req) { - struct unpcb *unp = sotounpcb(so); + struct unpcb *unp; struct unpcb *unp2; - UNP_LOCK_ASSERT(); + unp = sotounpcb(so); + KASSERT(unp != NULL, ("unp_connect2: unp == NULL")); + unp2 = sotounpcb(so2); + KASSERT(unp2 != NULL, ("unp_connect2: unp2 == NULL")); + + UNP_GLOBAL_LOCK_ASSERT(); + UNP_PCB_LOCK_ASSERT(unp); + UNP_PCB_LOCK_ASSERT(unp2); if (so2->so_type != so->so_type) return (EPROTOTYPE); - unp2 = sotounpcb(so2); - KASSERT(unp2 != NULL, ("unp_connect2: unp2 == NULL")); unp->unp_conn = unp2; + switch (so->so_type) { - case SOCK_DGRAM: LIST_INSERT_HEAD(&unp2->unp_refs, unp, unp_reflink); soisconnected(so); @@ -1012,15 +1206,16 @@ } static void -unp_disconnect(struct unpcb *unp) +unp_disconnect(struct unpcb *unp, struct unpcb *unp2) { - struct unpcb *unp2 = unp->unp_conn; struct socket *so; - UNP_LOCK_ASSERT(); + KASSERT(unp2 != NULL, ("unp_disconnect: unp2 == NULL")); + + UNP_GLOBAL_LOCK_ASSERT(); + UNP_PCB_LOCK_ASSERT(unp); + UNP_PCB_LOCK_ASSERT(unp2); - if (unp2 == NULL) - return; unp->unp_conn = NULL; switch (unp->unp_socket->so_type) { case SOCK_DGRAM: @@ -1039,16 +1234,6 @@ } } -#ifdef notdef -void -unp_abort(struct unpcb *unp) -{ - - unp_detach(unp); - UNP_UNLOCK_ASSERT(); -} -#endif - /* * unp_pcblist() assumes that UNIX domain socket memory is never reclaimed * by the zone (UMA_ZONE_NOFREE), and as such potentially stale pointers @@ -1087,10 +1272,10 @@ * OK, now we're committed to doing something. */ xug = malloc(sizeof(*xug), M_TEMP, M_WAITOK); - UNP_LOCK(); + UNP_GLOBAL_LOCK(); gencnt = unp_gencnt; n = unp_count; - UNP_UNLOCK(); + UNP_GLOBAL_UNLOCK(); xug->xug_len = sizeof *xug; xug->xug_count = n; @@ -1104,23 +1289,34 @@ unp_list = malloc(n * sizeof *unp_list, M_TEMP, M_WAITOK); - UNP_LOCK(); + /* + * XXXRW: Note, this code relies very explicitly in pcb's being type + * stable. + */ + UNP_GLOBAL_LOCK(); for (unp = LIST_FIRST(head), i = 0; unp && i < n; unp = LIST_NEXT(unp, unp_link)) { + UNP_PCB_LOCK(unp); if (unp->unp_gencnt <= gencnt) { if (cr_cansee(req->td->td_ucred, unp->unp_socket->so_cred)) continue; unp_list[i++] = unp; } + UNP_PCB_UNLOCK(unp); } - UNP_UNLOCK(); + UNP_GLOBAL_UNLOCK(); n = i; /* in case we lost some during malloc */ + /* + * XXXRW: The logic below asumes that it is OK to lock a mutex in + * an unpcb that may have been freed. + */ error = 0; xu = malloc(sizeof(*xu), M_TEMP, M_WAITOK | M_ZERO); for (i = 0; i < n; i++) { unp = unp_list[i]; + UNP_PCB_LOCK(unp); if (unp->unp_gencnt <= gencnt) { xu->xu_len = sizeof *xu; xu->xu_unpp = unp; @@ -1138,8 +1334,10 @@ unp->unp_conn->unp_addr->sun_len); bcopy(unp, &xu->xu_unp, sizeof *unp); sotoxsocket(unp->unp_socket, &xu->xu_socket); + UNP_PCB_UNLOCK(unp); error = SYSCTL_OUT(req, xu, sizeof *xu); - } + } else + UNP_PCB_UNLOCK(unp); } free(xu, M_TEMP); if (!error) { @@ -1170,33 +1368,38 @@ static void unp_shutdown(struct unpcb *unp) { + struct unpcb *unp2; struct socket *so; - UNP_LOCK_ASSERT(); + UNP_GLOBAL_LOCK_ASSERT(); + UNP_PCB_LOCK_ASSERT(unp); - if (unp->unp_socket->so_type == SOCK_STREAM && unp->unp_conn && - (so = unp->unp_conn->unp_socket)) - socantrcvmore(so); + unp2 = unp->unp_conn; + if (unp->unp_socket->so_type == SOCK_STREAM && unp2 != NULL) { + so = unp2->unp_socket; + if (so != NULL) + socantrcvmore(so); + } } static void unp_drop(struct unpcb *unp, int errno) { struct socket *so = unp->unp_socket; + struct unpcb *unp2; - UNP_LOCK_ASSERT(); + UNP_GLOBAL_LOCK_ASSERT(); + UNP_PCB_LOCK_ASSERT(unp); so->so_error = errno; - unp_disconnect(unp); -} + unp2 = unp->unp_conn; + if (unp2 == NULL) + return; -#ifdef notdef -void -unp_drain(void) -{ - + UNP_PCB_LOCK(unp2); + unp_disconnect(unp, unp2); + UNP_PCB_UNLOCK(unp2); } -#endif static void unp_freerights(struct file **rp, int fdcount) @@ -1205,7 +1408,6 @@ struct file *fp; for (i = 0; i < fdcount; i++) { - fp = *rp; /* * zero the pointer before calling * unp_discard since it may end up @@ -1213,7 +1415,8 @@ * * XXXRW: This is less true than it used to be. */ - *rp++ = 0; + fp = *rp; + *rp++ = NULL; unp_discard(fp); } } @@ -1233,7 +1436,7 @@ int f; u_int newlen; - UNP_UNLOCK_ASSERT(); + UNP_GLOBAL_UNLOCK_ASSERT(); error = 0; if (controlp != NULL) /* controlp == NULL => free control messages */ @@ -1338,6 +1541,7 @@ void unp_init(void) { + unp_zone = uma_zcreate("unpcb", sizeof(struct unpcb), NULL, NULL, NULL, NULL, UMA_ALIGN_PTR, UMA_ZONE_NOFREE); if (unp_zone == NULL) @@ -1348,7 +1552,7 @@ LIST_INIT(&unp_dhead); LIST_INIT(&unp_shead); TASK_INIT(&unp_gc_task, 0, unp_gc, NULL); - UNP_LOCK_INIT(); + UNP_GLOBAL_LOCK_INIT(); } static int @@ -1368,7 +1572,7 @@ int error, oldfds; u_int newlen; - UNP_UNLOCK_ASSERT(); + UNP_GLOBAL_UNLOCK_ASSERT(); error = 0; *controlp = NULL; @@ -1748,25 +1952,6 @@ unp_scan(m, unp_discard); } -static int -unp_listen(struct socket *so, struct unpcb *unp, int backlog, - struct thread *td) -{ - int error; - - UNP_LOCK_ASSERT(); - - SOCK_LOCK(so); - error = solisten_proto_check(so); - if (error == 0) { - cru2x(td->td_ucred, &unp->unp_peercred); - unp->unp_flags |= UNP_HAVEPCCACHED; - solisten_proto(so, backlog); - } - SOCK_UNLOCK(so); - return (error); -} - static void unp_scan(struct mbuf *m0, void (*op)(struct file *)) { @@ -1819,6 +2004,9 @@ static void unp_mark(struct file *fp) { + + /* XXXRW: Should probably assert file list lock here. */ + if (fp->f_gcflag & FMARK) return; unp_defer++; @@ -1828,11 +2016,12 @@ static void unp_discard(struct file *fp) { - UNP_LOCK(); + + UNP_GLOBAL_LOCK(); FILE_LOCK(fp); fp->f_msgcount--; unp_rights--; FILE_UNLOCK(fp); - UNP_UNLOCK(); + UNP_GLOBAL_UNLOCK(); (void) closef(fp, (struct thread *)NULL); } --- //depot/vendor/freebsd/src/sys/sys/unpcb.h 2005/04/13 00:05:41 +++ //depot/user/rwatson/proto/src/sys/sys/unpcb.h 2006/04/27 20:47:29 @@ -78,6 +78,7 @@ unp_gen_t unp_gencnt; /* generation count of this instance */ int unp_flags; /* flags */ struct xucred unp_peercred; /* peer credentials, if applicable */ + struct mtx unp_mtx; /* mutex */ }; /* @@ -98,6 +99,14 @@ #define UNP_WANTCRED 0x004 /* credentials wanted */ #define UNP_CONNWAIT 0x008 /* connect blocks until accepted */ +/* + * These flags are used to handle non-atomicity in connect() and bind() + * operations on a socket: in particular, to avoid races between multiple + * threads or processes operating simultaneously on the same socket. + */ +#define UNP_CONNECTING 0x010 /* Currently connecting. */ +#define UNP_BINDING 0x020 /* Currently binding. */ + #define sotounpcb(so) ((struct unpcb *)((so)->so_pcb)) /* Hack alert -- this structure depends on . */ From owner-freebsd-current@FreeBSD.ORG Sat May 6 14:20:53 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3FFEA16A401; Sat, 6 May 2006 14:20:53 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id A919E43D60; Sat, 6 May 2006 14:20:52 +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 5605246C36; Sat, 6 May 2006 10:20:52 -0400 (EDT) Date: Sat, 6 May 2006 15:20:52 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org In-Reply-To: <20060506150622.C17611@fledge.watson.org> Message-ID: <20060506152016.I17611@fledge.watson.org> References: <20060506150622.C17611@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: performance@FreeBSD.org Subject: Re: Fine-grained locking for POSIX local sockets (UNIX domain sockets) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2006 14:20:53 -0000 On Sat, 6 May 2006, Robert Watson wrote: > Attached, please find a patch implementing more fine-grained locking for the > POSIX local socket subsystem (UNIX domain socket subsystem). In the current > implementation, we use a single global subsystem lock to protect all local > IPC over the PF_LOCAL socket type. This has low overhead, but can result in > significant contention, especially for workloads like MySQL which push a > great deal of data through UNIX domain sockets, and involve many parties. > The hope is that by improving granularity, we can reduce contention > sufficiently to overcome the added cost of increased locking overhead (a > side-effect of greater granularity). At a high level, here are the changes > made: FYI, you can download a copy unmangled by my and your mail systems at the following URL: http://www.watson.org/~robert/freebsd/netperf/20060506a-uds-fine-grain.diff Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Sat May 6 15:23:11 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A420416A401; Sat, 6 May 2006 15:23:11 +0000 (UTC) (envelope-from nox@saturn.kn-bremen.de) Received: from gwyn.kn-bremen.de (gwyn.kn-bremen.de [212.63.36.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B97043D48; Sat, 6 May 2006 15:23:09 +0000 (GMT) (envelope-from nox@saturn.kn-bremen.de) Received: from gwyn.kn-bremen.de (gwyn [127.0.0.1]) by gwyn.kn-bremen.de (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k46FN8kg029438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 6 May 2006 17:23:08 +0200 Received: from saturn.kn-bremen.de (uucp@localhost) by gwyn.kn-bremen.de (8.13.4/8.13.4/Submit) with UUCP id k46FN824029436; Sat, 6 May 2006 17:23:08 +0200 Received: from saturn.kn-bremen.de (nox@localhost [127.0.0.1]) by saturn.kn-bremen.de (8.13.3/8.13.1) with ESMTP id k46FL05Y033801; Sat, 6 May 2006 17:21:00 +0200 (CEST) (envelope-from nox@saturn.kn-bremen.de) Received: (from nox@localhost) by saturn.kn-bremen.de (8.13.3/8.13.1/Submit) id k46FL0L8033800; Sat, 6 May 2006 17:21:00 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Sat, 6 May 2006 17:20:59 +0200 To: Igor Kovalenko Message-ID: <20060506152059.GA33481@saturn.kn-bremen.de> Mail-Followup-To: Igor Kovalenko , freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, Gleb Smirnoff References: <20060427203718.GA15953@saturn.kn-bremen.de> <445241DE.9020909@mail.ru> <20060428221142.GA11504@saturn.kn-bremen.de> <44530C50.6040902@mail.ru> <20060430004646.GA70632@saturn.kn-bremen.de> <4458277F.4010902@mail.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4458277F.4010902@mail.ru> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Sat, 06 May 2006 15:25:54 +0000 Cc: freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, Gleb Smirnoff Subject: re(4) (was: Re: playing with qemu's 8139 nic and FreeBSD (loopback mode missing?)) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2006 15:23:11 -0000 [Cc'ing glebius@ because he did most of the recent re(4) commits, and -current in case possible other driver developers didn't see this thread in -emulation] On Wed, May 03, 2006 at 07:46:07AM +0400, Igor Kovalenko wrote: > Juergen Lock wrote: > > On Sat, Apr 29, 2006 at 10:48:48AM +0400, Igor Kovalenko wrote: > >> Juergen Lock wrote: > >>> On Fri, Apr 28, 2006 at 08:25:02PM +0400, Igor Kovalenko wrote: > >>>> Juergen Lock wrote: > >>>>> I played with > >>>>> qemu -monitor stdio -m 256 -cdrom 6.1-RC1-i386-disc1.iso -usb -soundhw es1370 -kernel-kqemu -net nic,model=rtl8139 -net user > >>>>> and got it as far as > >>>>> re0: diagnostic failed, failed to receive packet in loopback mode > >>>>> (followed by a panic :) with the (experimental) patches below. > >>>>> > >>>>> Anyone in the mood to implement loopback mode for this nic? > >>>>> > >>>>> Hmm actually... I just found the original posting in the archive, > >>>>> is C+ mode implemented now? If not re is probably not what I want, > >>>> The rtl8139 is set up with PCI rev ID 0x20 which should be enough for OS driver > >>>> to detect C+ mode features. C+ mode is OK, tested with Linux driver. > >>> Cool, so I want FreeBSD's re driver. That one checks TxConfig > >>> tho, as changed in my patch (inside #if 0). And when changed, > >>> it still doesn't work as mentioned above because the driver expects > >>> loopback mode to be working. > >>>>> but the rl driver that it attaches without that #if 0'd (now) hunk > >>>>> below doesnt seem to be able to get data thru either and I get > >>>>> rl0: watchdog timeout > >>>>> in dmesg, which usually means the driver doesnt receive interrupts. > >>>>> > >>>>> What the heck, I'll append a log of a run just doing in fixit->cdrom: > >>>>> ifconfig rl0 10.0.2.15 > >>>>> and then exiting (which is enough to trigger the watchdog timeout...) > >>>>> > >>>> I'm too lasy to test with fresh freebsd installation :) > >>> No need to install FreeBSD, you can get away by just using > >>> fixit mode of an install iso, i.e. disc1. (which actually is > >>> what I did above. :) > >>> > >>> You can look at 6.1RC's re driver here: > >>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/re/if_re.c?annotate=1.46.2.14 > >>> which includes: > >>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/if_rlreg.h?annotate=1.51.2.3 > >>> > >>> And 6.1RC disc1 iso is e.g. here: > >>> ftp://ftp.ru.freebsd.org:/pub/FreeBSD/ISO-IMAGES-i386/6.1/6.1-RC1-i386-disc1.iso > >>> > >>> > >> Thanks, that iso pointer made it. > >> > > :) > > > >> Please try the following on top of your patch, at least ping should now work: > > > > Thanks, that seems to get the rl driver going. Now to fix C+ mode > > (re driver) change the #if 0 in my patch to #if 1... > > > > > > I believe freebsd re driver is somewhat broken, e.g. it does not follow documented > procedure to detect hardware features (e.g. 8139 c+ mode) Hmm, a bit of googling didn't reveal docs about this, do you have a pointer? (I only found the data sheet at http://people.freebsd.org/~wpaul/RealTek/spec-8139cp(150).pdf which doesnt seem to mention detecting c+ hardware specifically) > and in tries to use 8169 > registers (e.g. 0xda) on 8139 hardware etc. Oh, then it must have mis-detected the nic as a 8169 because the code in question reads: if (sc->rl_type == RL_8169) CSR_WRITE_2(sc, RL_MAXRXPKTLEN, 16383); > > Therefore some action from driver people is needed; I can provide a patch which > enables board timer in rtl8139 emulation (and thus enables hardware timeout > events) if you need it. Yeah I guess that would be useful... From owner-freebsd-current@FreeBSD.ORG Sat May 6 20:32:08 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A56C716A40E; Sat, 6 May 2006 20:32:08 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DCC243D6E; Sat, 6 May 2006 20:32:04 +0000 (GMT) (envelope-from bra@fsn.hu) Received: from localhost (localhost [127.0.0.1]) by people.fsn.hu (Postfix) with ESMTP id 82E9584423; Sat, 6 May 2006 22:32:03 +0200 (CEST) Received: from people.fsn.hu ([127.0.0.1]) by localhost (people.fsn.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 33631-04; Sat, 6 May 2006 22:31:58 +0200 (CEST) Received: from [172.16.164.67] (fw.axelero.hu [195.228.243.120]) by people.fsn.hu (Postfix) with ESMTP id CD6EA8441E; Sat, 6 May 2006 22:31:57 +0200 (CEST) Message-ID: <445D07C1.7080403@fsn.hu> Date: Sat, 06 May 2006 22:32:01 +0200 From: Attila Nagy User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Robert Watson References: <20060506150622.C17611@fledge.watson.org> In-Reply-To: <20060506150622.C17611@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at fsn.hu Cc: performance@FreeBSD.org, current@FreeBSD.org Subject: Re: Fine-grained locking for POSIX local sockets (UNIX domain sockets) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2006 20:32:09 -0000 Hello, On 2006. 05. 06. 16:16, Robert Watson wrote: > In local measurements, I have observed a 0% change in MySQL performance > on uniprocessor systems, and on a dual-processor system I have observed > a 4%-5% performance improvement with two client MySQL threads. Just a quick, nowhere correct test: http://people.fsn.hu/~bra/freebsd/20060506a-uds-fine-grain.diff/domsock.png The machine is a quad core Xeon LV server, the client side is sysbench, accessing mysql 4.1.8 on a socket. Heap table, simple test. -- Attila Nagy e-mail: Attila.Nagy@fsn.hu Free Software Network (FSN.HU) phone: +3630 306 6758 http://www.fsn.hu/ From owner-freebsd-current@FreeBSD.ORG Sat May 6 20:50:36 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A280B16A400; Sat, 6 May 2006 20:50:36 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52EDA43D45; Sat, 6 May 2006 20:50:36 +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 D88E946BD8; Sat, 6 May 2006 16:50:35 -0400 (EDT) Date: Sat, 6 May 2006 21:50:35 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Attila Nagy In-Reply-To: <445D07C1.7080403@fsn.hu> Message-ID: <20060506214838.Q46997@fledge.watson.org> References: <20060506150622.C17611@fledge.watson.org> <445D07C1.7080403@fsn.hu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: performance@FreeBSD.org, current@FreeBSD.org Subject: Re: Fine-grained locking for POSIX local sockets (UNIX domain sockets) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2006 20:50:36 -0000 On Sat, 6 May 2006, Attila Nagy wrote: > On 2006. 05. 06. 16:16, Robert Watson wrote: >> In local measurements, I have observed a 0% change in MySQL performance on >> uniprocessor systems, and on a dual-processor system I have observed a >> 4%-5% performance improvement with two client MySQL threads. > Just a quick, nowhere correct test: > http://people.fsn.hu/~bra/freebsd/20060506a-uds-fine-grain.diff/domsock.png > > The machine is a quad core Xeon LV server, the client side is sysbench, > accessing mysql 4.1.8 on a socket. Heap table, simple test. Which threading library is that with, btw? If libpthread, could you run the same test with libthr, and vice versa? I've noticed that libpthread has the interesting property that it greatly improves contention issues on certain locks when those locks are contended on within a process. The reason is that it avoids having threads within the process compete with themselves. The big locks threaded processes hit when contending with themselves are the file descriptor array lock and signal delivery related locks. Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Sat May 6 20:38:20 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7244316A403; Sat, 6 May 2006 20:38:20 +0000 (UTC) (envelope-from garrison@mail.ru) Received: from umail.ru (umail.ru [195.34.32.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7086143D58; Sat, 6 May 2006 20:38:09 +0000 (GMT) (envelope-from garrison@mail.ru) Received: from [85.140.126.56] (HELO skyserv) by umail.ru (CommuniGate Pro SMTP 4.2b6) with ESMTP-TLS id 668065023; Sun, 07 May 2006 00:38:07 +0400 Received: from localhost ([127.0.0.1]) by skyserv with esmtp (Exim 4.61) (envelope-from ) id 1FcTXS-00023j-PR; Sun, 07 May 2006 00:38:06 +0400 Message-ID: <445D092E.2040501@mail.ru> Date: Sun, 07 May 2006 00:38:06 +0400 From: Igor Kovalenko User-Agent: Thunderbird 1.5.0.2 (X11/20060505) MIME-Version: 1.0 To: Igor Kovalenko , freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, Gleb Smirnoff , nox@jelal.kn-bremen.de References: <20060427203718.GA15953@saturn.kn-bremen.de> <445241DE.9020909@mail.ru> <20060428221142.GA11504@saturn.kn-bremen.de> <44530C50.6040902@mail.ru> <20060430004646.GA70632@saturn.kn-bremen.de> <4458277F.4010902@mail.ru> <20060506152059.GA33481@saturn.kn-bremen.de> In-Reply-To: <20060506152059.GA33481@saturn.kn-bremen.de> Content-Type: multipart/mixed; boundary="------------090201030807060400040102" X-Mailman-Approved-At: Sat, 06 May 2006 21:48:09 +0000 Cc: Subject: Re: playing with qemu's 8139 nic and FreeBSD (loopback mode missing? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2006 20:38:20 -0000 This is a multi-part message in MIME format. --------------090201030807060400040102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Juergen, Juergen Lock wrote: > [Cc'ing glebius@ because he did most of the recent re(4) commits, and > -current in case possible other driver developers didn't see this thread > in -emulation] > > On Wed, May 03, 2006 at 07:46:07AM +0400, Igor Kovalenko wrote: >> Juergen Lock wrote: >>> On Sat, Apr 29, 2006 at 10:48:48AM +0400, Igor Kovalenko wrote: >>>> Juergen Lock wrote: >>>>> On Fri, Apr 28, 2006 at 08:25:02PM +0400, Igor Kovalenko wrote: >>>>>> Juergen Lock wrote: >>>>>>> I played with >>>>>>> qemu -monitor stdio -m 256 -cdrom 6.1-RC1-i386-disc1.iso -usb -soundhw es1370 -kernel-kqemu -net nic,model=rtl8139 -net user >>>>>>> and got it as far as >>>>>>> re0: diagnostic failed, failed to receive packet in loopback mode >>>>>>> (followed by a panic :) with the (experimental) patches below. >>>>>>> >>>>>>> Anyone in the mood to implement loopback mode for this nic? >>>>>>> >>>>>>> Hmm actually... I just found the original posting in the archive, >>>>>>> is C+ mode implemented now? If not re is probably not what I want, >>>>>> The rtl8139 is set up with PCI rev ID 0x20 which should be enough for OS driver >>>>>> to detect C+ mode features. C+ mode is OK, tested with Linux driver. >>>>> Cool, so I want FreeBSD's re driver. That one checks TxConfig >>>>> tho, as changed in my patch (inside #if 0). And when changed, >>>>> it still doesn't work as mentioned above because the driver expects >>>>> loopback mode to be working. >>>>>>> but the rl driver that it attaches without that #if 0'd (now) hunk >>>>>>> below doesnt seem to be able to get data thru either and I get >>>>>>> rl0: watchdog timeout >>>>>>> in dmesg, which usually means the driver doesnt receive interrupts. >>>>>>> >>>>>>> What the heck, I'll append a log of a run just doing in fixit->cdrom: >>>>>>> ifconfig rl0 10.0.2.15 >>>>>>> and then exiting (which is enough to trigger the watchdog timeout...) >>>>>>> >>>>>> I'm too lasy to test with fresh freebsd installation :) >>>>> No need to install FreeBSD, you can get away by just using >>>>> fixit mode of an install iso, i.e. disc1. (which actually is >>>>> what I did above. :) >>>>> >>>>> You can look at 6.1RC's re driver here: >>>>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/re/if_re.c?annotate=1.46.2.14 >>>>> which includes: >>>>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/if_rlreg.h?annotate=1.51.2.3 >>>>> >>>>> And 6.1RC disc1 iso is e.g. here: >>>>> ftp://ftp.ru.freebsd.org:/pub/FreeBSD/ISO-IMAGES-i386/6.1/6.1-RC1-i386-disc1.iso >>>>> >>>>> >>>> Thanks, that iso pointer made it. >>>> >>> :) >>> >>>> Please try the following on top of your patch, at least ping should now work: >>> Thanks, that seems to get the rl driver going. Now to fix C+ mode >>> (re driver) change the #if 0 in my patch to #if 1... >>> >>> >> I believe freebsd re driver is somewhat broken, e.g. it does not follow documented >> procedure to detect hardware features (e.g. 8139 c+ mode) > > Hmm, a bit of googling didn't reveal docs about this, do you have > a pointer? (I only found the data sheet at > http://people.freebsd.org/~wpaul/RealTek/spec-8139cp(150).pdf > which doesnt seem to mention detecting c+ hardware specifically) Well, I might have misread some docs; please do not consider this as an assault :) I remember PCI rev id >= 0x20 is C+ mode for realtek 8139. > >> and in tries to use 8169 >> registers (e.g. 0xda) on 8139 hardware etc. > > Oh, then it must have mis-detected the nic as a 8169 because > the code in question reads: > > if (sc->rl_type == RL_8169) > CSR_WRITE_2(sc, RL_MAXRXPKTLEN, 16383); >> Therefore some action from driver people is needed; I can provide a patch which >> enables board timer in rtl8139 emulation (and thus enables hardware timeout >> events) if you need it. > > Yeah I guess that would be useful... > > Please find rtl8139.c.freebsd.timer.diff attached hereto. The diff contains part of your changes to chip identification so re driver does see it as C+ mode chip. Timer support is added (and there is no kpanic now), though the specs require it to be clocked with PCI bus; that is somewhat hard to achieve. Common qemu timer is of much lower resolution; doing it differently will require some effort. -- Kind regards, Igor V. Kovalenko --------------090201030807060400040102 Content-Type: text/x-patch; name="rtl8139.c.freebsd.timer.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="rtl8139.c.freebsd.timer.diff" Index: rtl8139.c =================================================================== RCS file: /cvsroot/qemu/qemu/hw/rtl8139.c,v retrieving revision 1.1 diff -u -r1.1 rtl8139.c --- rtl8139.c 5 Feb 2006 04:14:41 -0000 1.1 +++ rtl8139.c 6 May 2006 20:27:02 -0000 @@ -32,6 +32,8 @@ /* debug RTL8139 card */ //#define DEBUG_RTL8139 1 +#define PCI_FREQUENCY 33000000L + /* debug RTL8139 card C+ mode only */ //#define DEBUG_RTL8139CP 1 @@ -315,6 +317,11 @@ (b30<<30 | b29<<29 | b28<<28 | b27<<27 | b26<<26 | b23<<23 | b22<<22) #define HW_REVID_MASK HW_REVID(1, 1, 1, 1, 1, 1, 1) +#define RTL8139_PCI_REVID_8139 0x10 +#define RTL8139_PCI_REVID_8139CPLUS 0x20 + +#define RTL8139_PCI_REVID RTL8139_PCI_REVID_8139CPLUS + /* Size is 64 * 16bit words */ #define EEPROM_9346_ADDR_BITS 6 #define EEPROM_9346_SIZE (1 << EEPROM_9346_ADDR_BITS) @@ -414,7 +421,13 @@ uint32_t RxRingAddrHI; EEprom9346 eeprom; - + + uint32_t TCTR; + uint32_t TimerInt; + int64_t TCTR_base; + + QEMUTimer *timer; + } RTL8139State; void prom9346_decode_command(EEprom9346 *eeprom, uint8_t command) @@ -512,6 +525,19 @@ eeprom->output <<= 1; if (eeprom->tick == 16) { +#if 1 + // the FreeBSD drivers (rl and re) don't explicitly toggle + // CS between reads (or does setting Cfg9346 to 0 count too?), + // so we need to enter wait-for-command state here + eeprom->mode = Chip9346_enter_command_mode; + eeprom->input = 0; + eeprom->tick = 0; + +#if defined(DEBUG_RTL8139) + printf("eeprom: +++ end of read, awaiting next command\n"); +#endif +#else + // original behaviour ++eeprom->address; eeprom->address &= EEPROM_9346_ADDR_MASK; eeprom->output = eeprom->contents[eeprom->address]; @@ -521,6 +547,7 @@ printf("eeprom: +++ read next address 0x%02x data=0x%04x\n", eeprom->address, eeprom->output); #endif +#endif } break; @@ -751,7 +778,7 @@ } } -static void rtl8139_receive(void *opaque, const uint8_t *buf, int size) +static void rtl8139_do_receive(void *opaque, const uint8_t *buf, int size, int do_interrupt) { RTL8139State *s = opaque; @@ -1078,7 +1105,16 @@ } s->IntrStatus |= RxOK; - rtl8139_update_irq(s); + + if (do_interrupt) + { + rtl8139_update_irq(s); + } +} + +static void rtl8139_receive(void *opaque, const uint8_t *buf, int size) +{ + rtl8139_do_receive(opaque, buf, size, 1); } static void rtl8139_reset_rxring(RTL8139State *s, uint32_t bufferSize) @@ -1103,6 +1139,11 @@ /* prepare eeprom */ s->eeprom.contents[0] = 0x8129; +#if 1 + // PCI vendor and device ID should be mirrored here + s->eeprom.contents[1] = 0x10ec; + s->eeprom.contents[2] = 0x8139; +#endif memcpy(&s->eeprom.contents[7], s->macaddr, 6); /* mark all status registers as owned by host */ @@ -1129,7 +1170,7 @@ // s->TxConfig |= HW_REVID(1, 0, 0, 0, 0, 0, 0); // RTL-8139 HasHltClk s->clock_enabled = 0; #else - s->TxConfig |= HW_REVID(1, 1, 1, 0, 1, 0, 0); // RTL-8139C HasLWake + s->TxConfig |= HW_REVID(1, 1, 1, 0, 1, 1, 0); // RTL-8139C+ HasLWake s->clock_enabled = 1; #endif @@ -1157,6 +1198,11 @@ s->NWayAdvert = 0x05e1; /* all modes, full duplex */ s->NWayLPAR = 0x05e1; /* all modes, full duplex */ s->NWayExpansion = 0x0001; /* autonegotiation supported */ + + /* also reset timer and disable timer interrupt */ + s->TCTR = 0; + s->TimerInt = 0; + s->TCTR_base = 0; } static void rtl8139_ChipCmd_write(RTL8139State *s, uint32_t val) @@ -1622,12 +1668,22 @@ #endif cpu_physical_memory_read(s->TxAddr[descriptor], txbuffer, txsize); - qemu_send_packet(s->vc, txbuffer, txsize); - /* Mark descriptor as transferred */ s->TxStatus[descriptor] |= TxHostOwns; s->TxStatus[descriptor] |= TxStatOK; + if (TxLoopBack == (s->TxConfig & TxLoopBack)) + { +#ifdef DEBUG_RTL8139 + printf("RTL8139: +++ transmit loopback mode\n"); +#endif + rtl8139_do_receive(s, txbuffer, txsize, 0); + } + else + { + qemu_send_packet(s->vc, txbuffer, txsize); + } + #ifdef DEBUG_RTL8139 printf("RTL8139: +++ transmitted %d bytes from descriptor %d\n", txsize, descriptor); #endif @@ -1748,9 +1804,6 @@ #endif cpu_physical_memory_read(tx_addr, txbuffer, txsize); - /* transmit the packet */ - qemu_send_packet(s->vc, txbuffer, txsize); - /* transfer ownership to target */ txdw0 &= ~CP_RX_OWN; @@ -1777,6 +1830,19 @@ ++s->currCPlusTxDesc; } + if (TxLoopBack == (s->TxConfig & TxLoopBack)) + { +#ifdef DEBUG_RTL8139 + printf("RTL8139: +++ C+ transmit loopback mode\n"); +#endif + rtl8139_receive(s, txbuffer, txsize); + } + else + { + /* transmit the packet */ + qemu_send_packet(s->vc, txbuffer, txsize); + } + #ifdef DEBUG_RTL8139 printf("RTL8139: +++ C+ mode transmitted %d bytes from descriptor %d\n", txsize, descriptor); #endif @@ -1909,6 +1975,8 @@ #endif s->TxAddr[txAddrOffset/4] = le32_to_cpu(val); + + s->currCPlusTxDesc = 0; } static uint32_t rtl8139_TxAddr_read(RTL8139State *s, uint32_t txAddrOffset) @@ -1949,6 +2017,18 @@ return ret; } +static uint32_t rtl8139_RxBufAddr_read(RTL8139State *s) +{ + /* this value is NOT off by 16 */ + uint32_t ret = s->RxBufAddr; + +#ifdef DEBUG_RTL8139 + printf("RTL8139: RxBufAddr read val=0x%04x\n", ret); +#endif + + return ret; +} + static void rtl8139_RxBuf_write(RTL8139State *s, uint32_t val) { #ifdef DEBUG_RTL8139 @@ -2281,6 +2361,21 @@ s->RxRingAddrHI = val; break; + case Timer: +#ifdef DEBUG_RTL8139 + printf("RTL8139: TCTR Timer reset on write\n"); +#endif + s->TCTR = 0; + s->TCTR_base = qemu_get_clock(vm_clock); + break; + + case FlashReg: +#ifdef DEBUG_RTL8139 + printf("RTL8139: FlashReg TimerInt write val=0x%08x\n", val); +#endif + s->TimerInt = val; + break; + default: #ifdef DEBUG_RTL8139 printf("RTL8139: ioport write(l) addr=0x%x val=0x%08x via write(b)\n", addr, val); @@ -2355,7 +2450,7 @@ break; case PCIRevisionID: - ret = 0x10; + ret = RTL8139_PCI_REVID; #ifdef DEBUG_RTL8139 printf("RTL8139: PCI Revision ID read 0x%x\n", ret); #endif @@ -2411,6 +2506,10 @@ ret = rtl8139_RxBufPtr_read(s); break; + case RxBufAddr: + ret = rtl8139_RxBufAddr_read(s); + break; + case BasicModeCtrl: ret = rtl8139_BasicModeCtrl_read(s); break; @@ -2521,6 +2620,20 @@ #endif break; + case Timer: + ret = s->TCTR; +#ifdef DEBUG_RTL8139 + printf("RTL8139: TCTR Timer read val=0x%08x\n", ret); +#endif + break; + + case FlashReg: + ret = s->TimerInt; +#ifdef DEBUG_RTL8139 + printf("RTL8139: FlashReg TimerInt read val=0x%08x\n", ret); +#endif + break; + default: #ifdef DEBUG_RTL8139 printf("RTL8139: ioport read(l) addr=0x%x via read(b)\n", addr); @@ -2688,6 +2801,10 @@ qemu_put_8s(f, &s->eeprom.eesk); qemu_put_8s(f, &s->eeprom.eedi); qemu_put_8s(f, &s->eeprom.eedo); + + qemu_put_be32s(f, &s->TCTR); + qemu_put_be32s(f, &s->TimerInt); + qemu_put_be64s(f, &s->TCTR_base); } static int rtl8139_load(QEMUFile* f,void* opaque,int version_id) @@ -2695,9 +2812,11 @@ RTL8139State* s=(RTL8139State*)opaque; int i; - if (version_id != 1) + /* just 2 versions for now */ + if (version_id > 2) return -EINVAL; + /* saved since version 1 */ qemu_get_buffer(f, s->phys, 6); qemu_get_buffer(f, s->mult, 8); @@ -2769,7 +2888,22 @@ qemu_get_8s(f, &s->eeprom.eedi); qemu_get_8s(f, &s->eeprom.eedo); - return 0; + /* saved since version 2 */ + if (version_id >= 2) + { + qemu_get_be32s(f, &s->TCTR); + qemu_get_be32s(f, &s->TimerInt); + qemu_get_be64s(f, &s->TCTR_base); + } + else + { + /* not saved, use default */ + s->TCTR = 0; + s->TimerInt = 0; + s->TCTR_base = 0; + } + + return 0; } /***********************************************************/ @@ -2817,6 +2951,63 @@ rtl8139_mmio_writel, }; +static inline int64_t rtl8139_get_next_tctr_time(RTL8139State *s, int64_t current_time) +{ + int64_t next_time = current_time + + muldiv64(1, ticks_per_sec, PCI_FREQUENCY); + if (next_time <= current_time) + next_time = current_time + 1; + return next_time; +} + +static void rtl8139_timer(void *opaque) +{ + RTL8139State *s = opaque; + + int is_timeout = 0; + + int64_t curr_time; + uint32_t curr_tick; + + if (!s->clock_enabled) + { +#ifdef DEBUG_RTL8139 + printf("RTL8139: >>> timer: clock is not running\n"); +#endif + return; + } + + curr_time = qemu_get_clock(vm_clock); + + curr_tick = muldiv64(curr_time - s->TCTR_base, PCI_FREQUENCY, ticks_per_sec); + + if (s->TimerInt && curr_tick >= s->TimerInt) + { + if (s->TCTR < s->TimerInt || curr_tick < s->TCTR) + { + is_timeout = 1; + } + } + + s->TCTR = curr_tick; + +#ifdef DEBUG_RTL8139 + printf("RTL8139: >>> timer: tick=%08u\n", s->TCTR); +#endif + + if (is_timeout) + { +#ifdef DEBUG_RTL8139 + printf("RTL8139: >>> timer: timeout tick=%08u\n", s->TCTR); +#endif + s->IntrStatus |= PCSTimeout; + rtl8139_update_irq(s); + } + + qemu_mod_timer(s->timer, + rtl8139_get_next_tctr_time(s,curr_time)); +} + void pci_rtl8139_init(PCIBus *bus, NICInfo *nd) { PCIRTL8139State *d; @@ -2833,7 +3024,7 @@ pci_conf[0x02] = 0x39; pci_conf[0x03] = 0x81; pci_conf[0x04] = 0x05; /* command = I/O space, Bus Master */ - pci_conf[0x08] = 0x20; /* 0x10 */ /* PCI revision ID; >=0x20 is for 8139C+ */ + pci_conf[0x08] = RTL8139_PCI_REVID; /* PCI revision ID; >=0x20 is for 8139C+ */ pci_conf[0x0a] = 0x00; /* ethernet network controller */ pci_conf[0x0b] = 0x02; pci_conf[0x0e] = 0x00; /* header_type */ @@ -2869,7 +3060,13 @@ s->macaddr[5]); /* XXX: instance number ? */ - register_savevm("rtl8139", 0, 1, rtl8139_save, rtl8139_load, s); + register_savevm("rtl8139", 0, 2, rtl8139_save, rtl8139_load, s); register_savevm("rtl8139_pci", 0, 1, generic_pci_save, generic_pci_load, &d->dev); + + s->timer = qemu_new_timer(vm_clock, rtl8139_timer, s); + + qemu_mod_timer(s->timer, + rtl8139_get_next_tctr_time(s,qemu_get_clock(vm_clock))); } + --------------090201030807060400040102-- From owner-freebsd-current@FreeBSD.ORG Sat May 6 22:19:09 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C0F8216A402; Sat, 6 May 2006 22:19:09 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A24943D45; Sat, 6 May 2006 22:19:09 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 07E231A4D8E; Sat, 6 May 2006 15:19:09 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 6B17B51A2C; Sat, 6 May 2006 18:19:08 -0400 (EDT) Date: Sat, 6 May 2006 18:19:08 -0400 From: Kris Kennaway To: Robert Watson Message-ID: <20060506221908.GB51268@xor.obsecurity.org> References: <20060506150622.C17611@fledge.watson.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1LKvkjL3sHcu1TtY" Content-Disposition: inline In-Reply-To: <20060506150622.C17611@fledge.watson.org> User-Agent: Mutt/1.4.2.1i Cc: performance@FreeBSD.org, current@FreeBSD.org Subject: Re: Fine-grained locking for POSIX local sockets (UNIX domain sockets) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2006 22:19:09 -0000 --1LKvkjL3sHcu1TtY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 06, 2006 at 03:16:48PM +0100, Robert Watson wrote: >=20 > Dear all, >=20 > Attached, please find a patch implementing more fine-grained locking for= =20 > the POSIX local socket subsystem (UNIX domain socket subsystem). Dear Sir, Per your request, please find attached the results of my measurements using super-smack on a 12-cpu E4500. supersmack queries/second with n worker threads: norwatson =3D without your patch (but with some other local locking patches) rwatson =3D also with your patch x norwatson-4 + rwatson-4 +------------------------------------------------------------+ | x xx + + | |x xx xx x + ++++ +++| | |_AM_| |__A___| | +------------------------------------------------------------+ N Min Max Median Avg Stddev x 10 3067.92 3098.05 3086.945 3084.402 8.8815574 + 10 3245.06 3287.8 3270.52 3270.475 13.241953 Difference at 95.0% confidence 186.073 +/- 10.5935 6.03271% +/- 0.343455% (Student's t, pooled s =3D 11.2746) x norwatson-6 + rwatson-6 +------------------------------------------------------------+ | xx x + | |x *xxxx + + + ++ + ++ | | |__A__| |_____________A_____M________|| +------------------------------------------------------------+ N Min Max Median Avg Stddev x 10 3641.11 3693.89 3679.735 3677.083 14.648967 + 10 3672.23 3896.32 3869.415 3845.071 66.826543 Difference at 95.0% confidence 167.988 +/- 45.4534 4.56851% +/- 1.23613% (Student's t, pooled s =3D 48.3755) i.e. in both cases there is a clear net gain in throughput with your patch. Without your patch, 6 clients is the optimum client load on this 12-cpu machine. At higher loads performance drops, even though formally all CPUs are not saturated. This is due to rapidly diverging lock contention (see below). x norwatson-8 + rwatson-8 +------------------------------------------------------------+ | + | | + + + x x| |+ + +++ + x xxxxx x x| | |_________A___M______| |___A___| | +------------------------------------------------------------+ N Min Max Median Avg Stddev x 10 2601.46 2700.26 2650.52 2653.441 30.758034 + 10 2240.86 2516.87 2496.085 2468.468 81.868576 Difference at 95.0% confidence -184.973 +/- 58.1052 -6.97106% +/- 2.1898% (Student's t, pooled s =3D 61.8406) We see the drop in performance in both cases indicating that we are in the "overloaded" regime. The fact that your patch seems to give worse performance is puzzling at first sight. Running mutex profiling (and only keeping the unp mutex entries and the 10 most contended for clarity) shows the following: norwatson, 8 clients: debug.mutex.prof.stats: max total count avg cnt_hold cnt_lock name 5 40 9 4 0 3 kern/uipc_u= srreq.c:170 (unp) 8 8 1 8 0 0 vm/uma_core= .c:2101 (unpcb) 13 283 52 5 0 0 vm/uma_core= .c:890 (unpcb) 14 1075 200 5 0 0 vm/uma_core= .c:1885 (unpcb) 4 52 18 2 4 6 kern/uipc_u= srreq.c:577 (unp) 5 39 9 4 4 2 kern/uipc_u= srreq.c:534 (unp) 5 35 11 3 6 6 kern/uipc_u= srreq.c:974 (unp) 5 45 11 4 7 4 kern/uipc_u= srreq.c:210 (unp) 171 1164 9 129 7 2 kern/uipc_u= srreq.c:917 (unp) 14 78 20 3 11 2872481 kern/uipc_u= srreq.c:709 (unp) 70 156 11 14 13 4 kern/uipc_u= srreq.c:895 (unp) 43 581 20 29 24 6 kern/uipc_u= srreq.c:239 (unp) 44 429 18 23 26 8 kern/uipc_u= srreq.c:518 (unp) 55 491 12 40 30 10 kern/uipc_u= srreq.c:251 (unp) =2E.. 449 20000519 320038 62 15158 0 kern/uipc_u= srreq.c:431 (so_rcv) 459 86616085 2880079 30 15699 4944 kern/uipc_u= srreq.c:319 (so_snd) 146 2273360 640315 3 27918 29789 kern/kern_s= ig.c:1002 (process lock) 387 3325481 640099 5 38143 47670 kern/kern_d= escrip.c:420 (filedesc structure) 150 1881990 640155 2 64111 49033 kern/kern_d= escrip.c:368 (filedesc structure) 496 13792853 3685885 3 101692 132480 kern/kern_d= escrip.c:1988 (filedesc structure) 207 4061793 551604 7 115427 118242 kern/kern_s= ynch.c:220 (process lock) 391 10332282 3685885 2 194387 129547 kern/kern_d= escrip.c:1967 (filedesc structure) 465 25504709 320042 79 1632192 294498 kern/uipc_u= srreq.c:364 (unp) 470 124263922 2880084 43 13222757 2685853 kern/uipc_u= srreq.c:309 (unp) i.e. there is indeed heavy contention on the unp lock (column 5 counts the number of times we tried to acquire it and failed because someone else had the lock) - in fact about 5 times as many contentions as successful acquisitions. With your patch and the same load: 3 20 9 2 0 0 kern/uipc_u= srreq.c:1028 (unp_mtx) 3 22 9 2 0 0 kern/uipc_u= srreq.c:1161 (unp_mtx) 5 29 9 3 0 2 kern/uipc_u= srreq.c:1065 (unp_global_mtx) 5 53 18 2 0 76488 kern/uipc_u= srreq.c:287 (unp_global_mtx) 6 33 9 3 0 0 kern/uipc_u= srreq.c:236 (unp_mtx) 6 37 9 4 0 0 kern/uipc_u= srreq.c:819 (unp_mtx) 7 7 1 7 0 0 vm/uma_core= .c:2101 (unpcb) 8 49 9 5 0 0 kern/uipc_u= srreq.c:1101 (unp_mtx) 11 136 18 7 0 1 kern/uipc_u= srreq.c:458 (unp_global_mtx) 32 143 9 15 0 1 kern/uipc_u= srreq.c:1160 (unp_global_mtx) 44 472 18 26 0 0 kern/uipc_u= srreq.c:801 (unp_mtx) 123 310 9 34 0 0 kern/uipc_u= srreq.c:1100 (unp_mtx) 147 452 9 50 0 0 kern/uipc_u= srreq.c:1099 (unp_mtx) 172 748 9 83 0 0 kern/uipc_u= srreq.c:473 (unp_mtx) 337 1592 9 176 0 0 kern/uipc_u= srreq.c:1147 (unp_mtx) 350 1790 9 198 0 0 kern/uipc_u= srreq.c:1146 (unp_mtx) 780 39405928 320038 123 0 0 kern/uipc_u= srreq.c:618 (unp_mtx) 18 140 9 15 1 0 kern/uipc_u= srreq.c:235 (unp_global_mtx) 70 717 18 39 1 3 kern/uipc_u= srreq.c:800 (unp_global_mtx) 528 2444 9 271 1 1 kern/uipc_u= srreq.c:1089 (unp_global_mtx) 158 616 9 68 2 2 kern/uipc_u= srreq.c:476 (unp_mtx) 794 175382857 2880084 60 2 7686 kern/uipc_u= srreq.c:574 (unp_mtx) 4 25 9 2 3 2 kern/uipc_u= srreq.c:422 (unp_global_mtx) 186 874 9 97 3 3 kern/uipc_u= srreq.c:472 (unp_global_mtx) 768 33783759 320038 105 7442 0 kern/uipc_u= srreq.c:696 (unp_mtx) =2E.. 465 913127 320045 2 43130 35046 kern/uipc_s= ocket.c:1101 (so_snd) 483 2453927 628737 3 44768 46177 kern/kern_s= ig.c:1002 (process lock) 767 124298544 2880082 43 70037 59994 kern/uipc_u= srreq.c:581 (so_snd) 794 45176699 320038 141 83252 72140 kern/uipc_u= srreq.c:617 (unp_global_mtx) 549 9858281 3200210 3 579269 712643 kern/kern_r= esource.c:1172 (sleep mtxpool) 554 17122245 631715 27 641888 268243 kern/kern_d= escrip.c:420 (filedesc structure) 388 3009912 631753 4 653540 260590 kern/kern_d= escrip.c:368 (filedesc structure) 642 49626755 3681446 13 1642954 682669 kern/kern_d= escrip.c:1988 (filedesc structure) 530 13802687 3681446 3 1663244 616899 kern/kern_d= escrip.c:1967 (filedesc structure) 477 23472709 2810986 8 5671248 1900047 kern/kern_s= ynch.c:220 (process lock) The top 10 heavily contended mutexes are very different (but note the number of mutex acquisitions, column 3, is about the same). There is not much contention on unp_global_mtx any longer, but there is a lot more on some of the other mutexes, especially the process lock via msleep(). Off-hand I don't know what is the cause of this bottleneck (note: libthr is used as threading library and libpthread is not ported to sparc64). Also, a lot of the contention that used to be on the unp lock seems to have fallen through onto contending *two* of the filedesc locks (all about 1.6 million contentions). This may also help to explain the performance drop. With only 6 clients, the contention is about an order of magnitude less on most of the top 10, even though the number of mutex calls is only about 25% fewer than with 8 clients: 195 715786 240037 2 47462 48821 kern/uipc_s= ocket.c:1101 (so_snd) 524 3456427 480079 7 50257 53368 kern/kern_d= escrip.c:420 (filedesc structure) 647 21650810 240030 90 50609 2 kern/uipc_u= srreq.c:705 (so_rcv) 710 37962453 240031 158 63743 57814 kern/uipc_u= srreq.c:617 (unp_global_mtx) 345 1624193 488866 3 80349 62950 kern/kern_d= escrip.c:368 (filedesc structure) 595 108074003 2160067 50 83327 63451 kern/uipc_u= srreq.c:581 (so_snd) 453 3706420 519735 7 119947 181434 kern/kern_s= ynch.c:220 (process lock) 469 13085667 2800771 4 122344 132478 kern/kern_d= escrip.c:1988 (filedesc structure) 320 8814736 2800771 3 200492 148967 kern/kern_d= escrip.c:1967 (filedesc structure) 440 7591194 2400171 3 544692 507583 kern/kern_r= esource.c:1172 (sleep mtxpool) In summary, this is a good test case since it shows both the benefits of your patch and the areas of remaining concern. Yours sincerely, Kristian D. Kennaway --1LKvkjL3sHcu1TtY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEXSDbWry0BWjoQKURAh8HAJkBGINyDyuC30ghHYqo1oSi6F25hACg9Yy+ ggHk4zGOlXNVL8NAZtCnp8g= =Sc2u -----END PGP SIGNATURE----- --1LKvkjL3sHcu1TtY-- From owner-freebsd-current@FreeBSD.ORG Sat May 6 22:39:59 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C02F516A416; Sat, 6 May 2006 22:39:59 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2577E43D53; Sat, 6 May 2006 22:39:58 +0000 (GMT) (envelope-from bra@fsn.hu) Received: from localhost (localhost [127.0.0.1]) by people.fsn.hu (Postfix) with ESMTP id 174438441F; Sun, 7 May 2006 00:39:57 +0200 (CEST) Received: from people.fsn.hu ([127.0.0.1]) by localhost (people.fsn.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 44147-01-3; Sun, 7 May 2006 00:39:51 +0200 (CEST) Received: from [172.16.164.66] (fw.axelero.hu [195.228.243.120]) by people.fsn.hu (Postfix) with ESMTP id 5256A84408; Sun, 7 May 2006 00:39:51 +0200 (CEST) Message-ID: <445D25BA.9020508@fsn.hu> Date: Sun, 07 May 2006 00:39:54 +0200 From: Attila Nagy User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Robert Watson References: <20060506150622.C17611@fledge.watson.org> <445D07C1.7080403@fsn.hu> <20060506214838.Q46997@fledge.watson.org> In-Reply-To: <20060506214838.Q46997@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at fsn.hu Cc: performance@FreeBSD.org, current@FreeBSD.org Subject: Re: Fine-grained locking for POSIX local sockets (UNIX domain sockets) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2006 22:39:59 -0000 On 2006. 05. 06. 22:50, Robert Watson wrote: >> The machine is a quad core Xeon LV server, the client side is >> sysbench, accessing mysql 4.1.8 on a socket. Heap table, simple test. > Which threading library is that with, btw? If libpthread, could you run > the same test with libthr, and vice versa? thr and with dynamically linked mysql, because when I link it with -static, it dies with sig11 at startup. You can find the updated picture at the previous link. -- Attila Nagy e-mail: Attila.Nagy@fsn.hu Free Software Network (FSN.HU) phone: +3630 306 6758 http://www.fsn.hu/