From owner-freebsd-current@FreeBSD.ORG Sun Dec 11 00:05:03 2005 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 39B2316A41F; Sun, 11 Dec 2005 00:05:03 +0000 (GMT) (envelope-from netchild@FreeBSD.org) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 73AED43D60; Sun, 11 Dec 2005 00:05:01 +0000 (GMT) (envelope-from netchild@FreeBSD.org) Received: from Andro-Beta.Leidinger.net (p54A5F2C0.dip.t-dialin.net [84.165.242.192]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.1/8.13.1) with ESMTP id jBANaJSg019681; Sun, 11 Dec 2005 00:36:20 +0100 (CET) (envelope-from netchild@FreeBSD.org) Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) by Andro-Beta.Leidinger.net (8.13.3/8.13.3) with ESMTP id jBB04ttU071472; Sun, 11 Dec 2005 01:04:55 +0100 (CET) (envelope-from netchild@FreeBSD.org) Date: Sun, 11 Dec 2005 01:04:54 +0100 From: Alexander Leidinger To: Joel Dahl Message-ID: <20051211010454.59a174cc@Magellan.Leidinger.net> In-Reply-To: <1134239935.685.8.camel@dude.automatvapen.se> References: <439AE13D.1040800@locolomo.org> <1134239935.685.8.camel@dude.automatvapen.se> Organization: FreeBSD X-Mailer: Sylpheed-Claws 1.9.100 (GTK+ 2.8.8; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new Cc: Erik =?UTF-8?B?TsO4cmdhYXJk?= , current@FreeBSD.org Subject: Re: Contacts for project idea list 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, 11 Dec 2005 00:05:03 -0000 On Sat, 10 Dec 2005 19:38:55 +0100 Joel Dahl wrote: > Yes, we're still looking for developers to act as technical contacts for > a few projects. I think netchild@ invented the PXE installer project > and the sysinstall renewal project, based upon feature requests from > users... If we talk about some improvements to sysinstall which is listed in the list: I like to think about it as a "fix some shortcommings until the new installer is committed". Regarding the PXE installer: IIRC this is more or less a cut&paste from a message in the mailinglists. If you know Solaris Jumpstart: it's something like this. Just do a PXE boot from a special server and you get the box installed. I think the simplest implementation would be a "boot a minimal system, parition the disk, extract an archive"-one. Bye, Alexander. -- 0 and 1. Now what could be so hard about that? http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-current@FreeBSD.ORG Sun Dec 11 01:22:31 2005 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 90A8216A41F; Sun, 11 Dec 2005 01:22:31 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id E61A643D5D; Sun, 11 Dec 2005 01:22:30 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp133-7.lns2.adl2.internode.on.net [59.167.133.7]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id jBB1LwiG084213 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 11 Dec 2005 11:51:59 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Sun, 11 Dec 2005 11:51:32 +1030 User-Agent: KMail/1.8.2 References: <439B1092.4080400@drexel.edu> In-Reply-To: <439B1092.4080400@drexel.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1889057.2N8L26ZBr3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200512111151.45208.doconnor@gsoft.com.au> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.54 on 203.31.81.10 Cc: Justin Smith , current@freebsd.org Subject: Re: No xpt devices 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, 11 Dec 2005 01:22:31 -0000 --nextPart1889057.2N8L26ZBr3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sun, 11 Dec 2005 03:59, Justin Smith wrote: > FreeBSD jsmith.org 6.0-STABLE FreeBSD 6.0-STABLE #0: Thu Dec 8 09:31:42 > EST 2005 jsmith@jsmith.org:/usr/obj/usr/src/sys/MYKERNEL i386 > > I'm trying to burn CD's and have my kernel configured with the pass, cd, > and atapcam devices. > > I get > > /dev/cd0 and /dev/pass0 but no /dev/xpt0 I am pretty sure xpt0 comes from scbus - ie you couldn't have pass0 without= =20 xpt0 becuase you get an xpt with every instance of CAM (ie one) Do you have anything odd in your devfs rules? =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 --nextPart1889057.2N8L26ZBr3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDm38p5ZPcIHs/zowRAmRnAJ9rj67KGV6JP3h5okWrQi8FCADNQQCfbFL9 4K5bzMcw1v3pPR/hIWfMMhQ= =hsQJ -----END PGP SIGNATURE----- --nextPart1889057.2N8L26ZBr3-- From owner-freebsd-current@FreeBSD.ORG Sun Dec 11 01:22:31 2005 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 90A8216A41F; Sun, 11 Dec 2005 01:22:31 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id E61A643D5D; Sun, 11 Dec 2005 01:22:30 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp133-7.lns2.adl2.internode.on.net [59.167.133.7]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id jBB1LwiG084213 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 11 Dec 2005 11:51:59 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Sun, 11 Dec 2005 11:51:32 +1030 User-Agent: KMail/1.8.2 References: <439B1092.4080400@drexel.edu> In-Reply-To: <439B1092.4080400@drexel.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1889057.2N8L26ZBr3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200512111151.45208.doconnor@gsoft.com.au> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.54 on 203.31.81.10 Cc: Justin Smith , current@freebsd.org Subject: Re: No xpt devices 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, 11 Dec 2005 01:22:31 -0000 --nextPart1889057.2N8L26ZBr3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sun, 11 Dec 2005 03:59, Justin Smith wrote: > FreeBSD jsmith.org 6.0-STABLE FreeBSD 6.0-STABLE #0: Thu Dec 8 09:31:42 > EST 2005 jsmith@jsmith.org:/usr/obj/usr/src/sys/MYKERNEL i386 > > I'm trying to burn CD's and have my kernel configured with the pass, cd, > and atapcam devices. > > I get > > /dev/cd0 and /dev/pass0 but no /dev/xpt0 I am pretty sure xpt0 comes from scbus - ie you couldn't have pass0 without= =20 xpt0 becuase you get an xpt with every instance of CAM (ie one) Do you have anything odd in your devfs rules? =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 --nextPart1889057.2N8L26ZBr3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDm38p5ZPcIHs/zowRAmRnAJ9rj67KGV6JP3h5okWrQi8FCADNQQCfbFL9 4K5bzMcw1v3pPR/hIWfMMhQ= =hsQJ -----END PGP SIGNATURE----- --nextPart1889057.2N8L26ZBr3-- From owner-freebsd-current@FreeBSD.ORG Sun Dec 11 01:55:01 2005 Return-Path: X-Original-To: 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 DC0E716A427; Sun, 11 Dec 2005 01:55:00 +0000 (GMT) (envelope-from davidxu@freebsd.org) Message-ID: <439B8711.2090501@freebsd.org> Date: Sun, 11 Dec 2005 09:55:29 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.10) Gecko/20050806 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pascal Hofstee References: <20051209175607.C23668@maildrop.int.zabbadoz.net> <1134240701.767.3.camel@synergy.odyssey.homeunix.org> In-Reply-To: <1134240701.767.3.camel@synergy.odyssey.homeunix.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , FreeBSD current mailing list Subject: Re: nve(4) patch - please test! 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, 11 Dec 2005 01:55:01 -0000 Pascal Hofstee wrote: >On Fri, 2005-12-09 at 20:28 +0000, Bjoern A. Zeeb wrote: > > >>Hi, >> >>everyone out there who had only seen timeouts like >> nve0: device timeout (4) >>on nve and __never got it working at all__ please try this patch[1] >>which made my nve working from 0 to 99. >> >>I still can get timeouts by for example flood pinging another machine >>on the local LAN but it all recovers on it's own and I can work on >>that machine and do things like find / over ssh without losing >>connectivity. Fixing the timeouts will be another problem that needs >>to be addressed later. >> >> > >Just thought i'd say that this patch also makes the onboard nve chip on >my EPOX 9NDA3+ (likely the same chip as David Xu's 9NDA3J board). > >I still get the occasional sputter of an nve0 device timeout(x) though x >seems to be a constant "1" .. instead of the typical climbing towards 64 >i have seen happening on other nve-boards. > > > Yes, I occasionally got timeout(x) too, annoyance is machine is stalled when the driver is resetting the device, I can not move mouse and type in key, can this be avoided ? From owner-freebsd-current@FreeBSD.ORG Sun Dec 11 09:47:53 2005 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 6A79E16A41F for ; Sun, 11 Dec 2005 09:47:53 +0000 (GMT) (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 5FDE243D53 for ; Sun, 11 Dec 2005 09:47:43 +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 292191FFDBC; Sun, 11 Dec 2005 10:47:40 +0100 (CET) Received: by transport.cksoft.de (Postfix, from userid 66) id 710911FFBF8; Sun, 11 Dec 2005 10:47:37 +0100 (CET) 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 37CB2444F50; Sun, 11 Dec 2005 09:43:15 +0000 (UTC) Date: Sun, 11 Dec 2005 09:43:15 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Ariff Abdullah In-Reply-To: <20051211011355.4b0b3f78.skywizard@MyBSD.org.my> Message-ID: <20051211094213.H23668@maildrop.int.zabbadoz.net> References: <439AF7C0.9060801@mcsi.pp.ru> <20051211011355.4b0b3f78.skywizard@MyBSD.org.my> 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: Maxim Maximov , FreeBSD current mailing list Subject: Re: LOR in pcm 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, 11 Dec 2005 09:47:53 -0000 On Sun, 11 Dec 2005, Ariff Abdullah wrote: > On Sat, 10 Dec 2005 18:44:00 +0300 > Maxim Maximov wrote: >> Hi all. >> >> Got this on SMP CURRENT from Sun Dec 4 22:06:46 MSK 2005. >> I have no recording devices, FWIW. >> >> lock order reversal: >> 1st 0xc35884c0 pcm0 (sound cdev) @ >> /usr/src/sys/dev/sound/pcm/dsp.c:277 2nd 0xc3562ac0 pcm0:record:0 >> (pcm record channel) @ >> /usr/src/sys/dev/sound/pcm/dsp.c:290 > > I believe this is during playback startup, right? If so, just ignore > it for a while, it is quite harmless (although a bit annoying). I'll > fix it alltogether hopefully before new year. I added it to "the LOR page" with ID 174: http://sources.zabbadoz.net/freebsd/lor.html#174 -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-current@FreeBSD.ORG Sun Dec 11 14:42:31 2005 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 90A9916A420 for ; Sun, 11 Dec 2005 14:42:31 +0000 (GMT) (envelope-from q@galgenberg.net) Received: from wrzx28.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A1CD43D72 for ; Sun, 11 Dec 2005 14:41:45 +0000 (GMT) (envelope-from q@galgenberg.net) Received: from wrzx30.rz.uni-wuerzburg.de (wrzx30.rz.uni-wuerzburg.de [132.187.1.30]) by wrzx28.rz.uni-wuerzburg.de (Postfix) with ESMTP id E0CB413F8D4; Sun, 11 Dec 2005 15:41:41 +0100 (CET) Received: from virusscan (localhost [127.0.0.1]) by wrzx30.rz.uni-wuerzburg.de (Postfix) with ESMTP id C71809DD21; Sun, 11 Dec 2005 15:41:41 +0100 (CET) Received: from wrzx28.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by wrzx30.rz.uni-wuerzburg.de (Postfix) with ESMTP id B06A59DCC3; Sun, 11 Dec 2005 15:41:41 +0100 (CET) Received: from frodo.galgenberg.net (wwsx14.win-screen.uni-wuerzburg.de [132.187.253.14]) by wrzx28.rz.uni-wuerzburg.de (Postfix) with ESMTP id C46BA13F8D4; Sun, 11 Dec 2005 15:41:40 +0100 (CET) Received: from coyote.q.local (gb-21-237.galgenberg.net [172.16.21.237]) by frodo.galgenberg.net (8.13.1/8.13.1) with ESMTP id jBBEfeFO045123; Sun, 11 Dec 2005 15:41:40 +0100 (CET) (envelope-from q@galgenberg.net) Received: from roadrunner.q.local (roadrunner.q.local [192.168.0.148]) by coyote.q.local (8.13.4/8.13.4) with ESMTP id jBBEfe3H055440; Sun, 11 Dec 2005 15:41:40 +0100 (CET) (envelope-from q@galgenberg.net) Received: from roadrunner.q.local (localhost [127.0.0.1]) by roadrunner.q.local (8.13.4/8.13.4) with ESMTP id jBBEfelC001470; Sun, 11 Dec 2005 15:41:40 +0100 (CET) (envelope-from q@galgenberg.net) Received: (from q@localhost) by roadrunner.q.local (8.13.4/8.13.4/Submit) id jBBEfcWp001469; Sun, 11 Dec 2005 15:41:38 +0100 (CET) (envelope-from q@galgenberg.net) Date: Sun, 11 Dec 2005 15:41:38 +0100 From: Ulrich Spoerlein To: Andrew Turner Message-ID: <20051211144138.GA1091@galgenberg.net> Mail-Followup-To: Andrew Turner , freebsd-current@freebsd.org References: <439B5907.4010809@fubar.geek.nz> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline In-Reply-To: <439B5907.4010809@fubar.geek.nz> X-Virus-Scanned: by amavisd-new (Rechenzentrum Universitaet Wuerzburg) Cc: freebsd-current@freebsd.org Subject: Re: BSDInstaller Beta 2 release 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, 11 Dec 2005 14:42:31 -0000 --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > As with the previous Beta release there are three virtual consoles availa= ble: > * ttyv0: The frontend > * ttyv1: The backend > * ttyv2: A standard login screen to login as root with no password I can't currently test this, so I'm asking: Is ttyv2 running a full live system with reasonable $PATH variable? In other words, can I run dd, fdisk, bsdlabel (including vi), newfs, tar/cp/cpio from inside this shell? And: Would it thus be possible to use dump(8) from the mounted live-CD and restore(8) the system to the local hard disk. Ulrich Spoerlein --=20 PGP Key ID: F0DB9F44 Encrypted mail welcome! Fingerprint: F1CE D062 0CA9 ADE3 349B 2FE8 980A C6B5 F0DB 9F44 Ok, which part of "Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn." didn't you understand? --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDnDqimArGtfDbn0QRAkInAJ9q5AWAuUgVfrZ71PepzTAJp+ShnACg08C2 +FXs/ViF486VTqrHs7ZdEd0= =dx/b -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9-- From owner-freebsd-current@FreeBSD.ORG Sun Dec 11 16:10:29 2005 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 4894016A420 for ; Sun, 11 Dec 2005 16:10:29 +0000 (GMT) (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 C9F8943D53 for ; Sun, 11 Dec 2005 16: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 jBBG9uFN098866 for ; Sun, 11 Dec 2005 11:09:56 -0500 (EST) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost) by lexi.siliconlandmark.com (8.13.3/8.13.3/Submit) with ESMTP id jBBG9u8l098863 for ; Sun, 11 Dec 2005 11:09:56 -0500 (EST) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Sun, 11 Dec 2005 11:09:56 -0500 (EST) From: Andre Guibert de Bruet To: current@freebsd.org Message-ID: <20051211105118.X17429@lexi.siliconlandmark.com> 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.529, required 6, autolearn=not spam, AWL 0.07, BAYES_00 -2.60) X-MailScanner-From: andy@siliconlandmark.com Cc: Subject: The /etc/ntp/ directory. 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, 11 Dec 2005 16:10:29 -0000 Hi, I have a 7.0-CURRENT machine that I have upgraded time and time again, since the 5.3-CURRENT days. While looking into setting up ntpd, I came across the empty /etc/ntp/ directory. After perusing the man file, and the rcNG startup scripts, I don't see anything that makes a reference to this directory. The locations that I do find are: ntpd.conf: /etc/ntpd.conf ntp.drift: /var/db/ntpd.drift ntpd.pid: /var/run/ntpd.pid Docs: /usr/share/doc/ntp I checked a fresh install of 6.0-RELEASE and this directory appears there too but again, without any references. On 4.11-STABLE, it does not exist. Is there any use at all for this directory? Cheers, 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 Sun Dec 11 16:50:53 2005 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 CBC8F16A41F for ; Sun, 11 Dec 2005 16:50:53 +0000 (GMT) (envelope-from sten@blinkenlights.nl) Received: from ford.blinkenlights.nl (ford.blinkenlights.nl [213.204.211.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3759343D67 for ; Sun, 11 Dec 2005 16:50:51 +0000 (GMT) (envelope-from sten@blinkenlights.nl) Received: from tea.blinkenlights.nl (tea.blinkenlights.nl [192.168.1.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ford.blinkenlights.nl (Postfix) with ESMTP id CD5FEBDFA; Sun, 11 Dec 2005 17:50:53 +0100 (CET) Received: by tea.blinkenlights.nl (Postfix, from userid 101) id CBA86192; Sun, 11 Dec 2005 17:51:47 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by tea.blinkenlights.nl (Postfix) with ESMTP id B2FE2159; Sun, 11 Dec 2005 17:51:47 +0100 (CET) Date: Sun, 11 Dec 2005 17:51:47 +0100 (CET) From: Sten Spans To: Andre Guibert de Bruet In-Reply-To: <20051211105118.X17429@lexi.siliconlandmark.com> Message-ID: References: <20051211105118.X17429@lexi.siliconlandmark.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: The /etc/ntp/ directory. 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, 11 Dec 2005 16:50:53 -0000 On Sun, 11 Dec 2005, Andre Guibert de Bruet wrote: > Hi, > > I have a 7.0-CURRENT machine that I have upgraded time and time again, since > the 5.3-CURRENT days. While looking into setting up ntpd, I came across the > empty /etc/ntp/ directory. After perusing the man file, and the rcNG startup > scripts, I don't see anything that makes a reference to this directory. The > locations that I do find are: > > ntpd.conf: /etc/ntpd.conf > ntp.drift: /var/db/ntpd.drift > ntpd.pid: /var/run/ntpd.pid > Docs: /usr/share/doc/ntp > > I checked a fresh install of 6.0-RELEASE and this directory appears there too > but again, without any references. On 4.11-STABLE, it does not exist. Is > there any use at all for this directory? The most common usage is with an ntpd running as user ntp. This user normally can't write to /var/db/ ( ntpd renames a temporary ntpd.drift.XXXX to ntpd.drift ). So ntpd.drift is moved to /etc/ntp where user ntp does have write permissions. Not that FreeBSD supports non-root ntpd (afaik). -- Sten Spans "There is a crack in everything, that's how the light gets in." Leonard Cohen - Anthem From owner-freebsd-current@FreeBSD.ORG Sun Dec 11 10:38:56 2005 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 DE30616A420 for ; Sun, 11 Dec 2005 10:38:56 +0000 (GMT) (envelope-from tomas@hodan.sk) Received: from acs.sk (acs.sk [62.176.161.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42E9A43D5C for ; Sun, 11 Dec 2005 10:38:54 +0000 (GMT) (envelope-from tomas@hodan.sk) Received: from mtl12349390 ([62.176.165.10]) (authenticated bits=0) by acs.sk (8.12.9/8.12.9) with ESMTP id jBBAcj7L016089 for ; Sun, 11 Dec 2005 11:38:50 +0100 (CET) (envelope-from tomas@hodan.sk) Message-Id: <200512111038.jBBAcj7L016089@acs.sk> From: "Tomas Hodan" To: Date: Sun, 11 Dec 2005 11:38:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcX+Pw9s3cHFfJVGQ5GHJG3+T6pC5g== X-Mailman-Approved-At: Sun, 11 Dec 2005 17:08:40 +0000 Subject: new ath_hal 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, 11 Dec 2005 10:38:57 -0000 hi Sam, I successfully compiled your kernel under RELENG_7 with your patches and new ath_hal, just it's not possible to compile athstats anymore. MiniBSD /usr/src/tools/tools/ath # make cc -o athstats athstats.c athstats.c: In function `printstats': athstats.c:128: error: structure has no member named `ast_tx_ctsburst' athstats.c:128: error: structure has no member named `ast_tx_ctsburst' athstats.c:129: error: structure has no member named `ast_tx_ctsext' athstats.c:129: error: structure has no member named `ast_tx_ctsext' *** Error code 1 Stop in /usr/src/tools/tools/ath. could you have a look? thx tomas From owner-freebsd-current@FreeBSD.ORG Sun Dec 11 20:55:18 2005 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 36CF216A420; Sun, 11 Dec 2005 20:55:18 +0000 (GMT) (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 6BA7043D5C; Sun, 11 Dec 2005 20:55:17 +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.4/8.13.4) with ESMTP id jBBKtGCn013470; Sun, 11 Dec 2005 15:55:16 -0500 (EST) (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.3/8.13.3) with ESMTP id jBBKtGlu001752; Sun, 11 Dec 2005 15:55:16 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D60E07302F; Sun, 11 Dec 2005 15:55:15 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051211205515.D60E07302F@freebsd-current.sentex.ca> Date: Sun, 11 Dec 2005 15:55:15 -0500 (EST) X-Virus-Scanned: ClamAV version 0.86, clamav-milter version 0.86 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on alpha/alpha 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: Sun, 11 Dec 2005 20:55:18 -0000 TB --- 2005-12-11 19:39:07 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-12-11 19:39:07 - starting HEAD tinderbox run for alpha/alpha TB --- 2005-12-11 19:39:07 - cleaning the object tree TB --- 2005-12-11 19:39:34 - checking out the source tree TB --- 2005-12-11 19:39:34 - cd /tinderbox/HEAD/alpha/alpha TB --- 2005-12-11 19:39:34 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-12-11 19:45:38 - building world (CFLAGS=-O2 -pipe) TB --- 2005-12-11 19:45:38 - cd /src TB --- 2005-12-11 19:45:38 - /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 --- 2005-12-11 20:50:52 - generating LINT kernel config TB --- 2005-12-11 20:50:52 - cd /src/sys/alpha/conf TB --- 2005-12-11 20:50:52 - /usr/bin/make -B LINT TB --- 2005-12-11 20:50:52 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-12-11 20:50:52 - cd /src TB --- 2005-12-11 20:50:52 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Dec 11 20:50:53 UTC 2005 >>> 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 -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/dev/ata/atapi-fd.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/dev/ata/atapi-tape.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/dev/awi/am79c930.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/dev/awi/awi.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/dev/awi/if_awi_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/dev/bge/if_bge.c /src/sys/dev/bge/if_bge.c: In function `bge_intr': /src/sys/dev/bge/if_bge.c:3710: warning: 'status' might be used uninitialized in this function *** Error code 1 Stop in /obj/alpha/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-12-11 20:55:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-12-11 20:55:15 - ERROR: failed to build lint kernel TB --- 2005-12-11 20:55:15 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sun Dec 11 21:25:04 2005 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 AD19416A41F for ; Sun, 11 Dec 2005 21:25:04 +0000 (GMT) (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 ECCC643D53 for ; Sun, 11 Dec 2005 21:25:00 +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 jBBLOtpA000457; Sun, 11 Dec 2005 16:24:55 -0500 (EST) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost) by lexi.siliconlandmark.com (8.13.3/8.13.3/Submit) with ESMTP id jBBLOtNC000454; Sun, 11 Dec 2005 16:24:55 -0500 (EST) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Sun, 11 Dec 2005 16:24:55 -0500 (EST) From: Andre Guibert de Bruet To: Sten Spans In-Reply-To: Message-ID: <20051211161558.Q17429@lexi.siliconlandmark.com> References: <20051211105118.X17429@lexi.siliconlandmark.com> 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.53, required 6, autolearn=not spam, AWL 0.07, BAYES_00 -2.60) X-MailScanner-From: andy@siliconlandmark.com Cc: current@freebsd.org Subject: Re: The /etc/ntp/ directory. 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, 11 Dec 2005 21:25:04 -0000 On Sun, 11 Dec 2005, Sten Spans wrote: > On Sun, 11 Dec 2005, Andre Guibert de Bruet wrote: > >> I have a 7.0-CURRENT machine that I have upgraded time and time again, >> since the 5.3-CURRENT days. While looking into setting up ntpd, I came >> across the empty /etc/ntp/ directory. After perusing the man file, and the >> rcNG startup scripts, I don't see anything that makes a reference to this >> directory. The locations that I do find are: >> >> ntpd.conf: /etc/ntpd.conf >> ntp.drift: /var/db/ntpd.drift >> ntpd.pid: /var/run/ntpd.pid >> Docs: /usr/share/doc/ntp >> >> I checked a fresh install of 6.0-RELEASE and this directory appears there >> too but again, without any references. On 4.11-STABLE, it does not exist. >> Is there any use at all for this directory? > > The most common usage is with an ntpd running as user ntp. > This user normally can't write to /var/db/ ( ntpd renames > a temporary ntpd.drift.XXXX to ntpd.drift ). > So ntpd.drift is moved to /etc/ntp where user ntp > does have write permissions. > > Not that FreeBSD supports non-root ntpd (afaik). Thanks for the insight. FreeBSD does not ship with an ntp user. I do however, see the facilities in place in the rcNG script for chrooting. So if ntpd is running as root because clock_settime(2) and friends require the effective user ID of the super-user, what is the functional purpose of this directory? Thanks, 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 Sun Dec 11 21:46:46 2005 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 97F1716A41F for ; Sun, 11 Dec 2005 21:46:46 +0000 (GMT) (envelope-from tim@thepacific.net) Received: from webhost1.tasman.net (webhost1.tasman.net [203.86.194.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06ACB43D62 for ; Sun, 11 Dec 2005 21:46:45 +0000 (GMT) (envelope-from tim@thepacific.net) Received: from [203.86.192.98] (helo=swamp) by webhost1.tasman.net with esmtpa (Exim 4.53 (FreeBSD)) id 1ElZ1m-0004IP-CH for current@freebsd.org; Mon, 12 Dec 2005 10:46:42 +1300 From: "Tim Price" To: Date: Mon, 12 Dec 2005 10:42:31 +1300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 Thread-Index: AcX+m8oalgPcO5vkRwCpJS1vB9B9Og== X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - webhost1.tasman.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [26 6] X-AntiAbuse: Sender Address Domain - thepacific.net X-Source: X-Source-Args: X-Source-Dir: Message-Id: <20051211214645.06ACB43D62@mx1.FreeBSD.org> Cc: Subject: 802.1QinQ Support 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, 11 Dec 2005 21:46:46 -0000 Is there any support, either inbuilt or third party, that anyone knows of for 802.1QinQ, VLAN Stacking, Inner VLAN (it's called a lot of things by a lot of companies)? The reason I ask is that we provide layer 2 transit over our wireless network using a freebsd 5.4 / 6 appliance. Recently we have been approached by a group that wants to use VLANS for QOS using their own routers but unless we encapsulate their traffic in our own VLANs we will eventually run into an issue with VLAN conflicts between this group and another potential VLAN user. Any input that the FreeBSD community has to offer on this issue, or other solutions that we may not have thought about would be greatly appreciated. Regards Tim Price Software Supervisor ThePacific.Net tim@thepacific.net +64 3 5439095 www.thepacific.net From owner-freebsd-current@FreeBSD.ORG Sun Dec 11 21:48:46 2005 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 82C0516A41F for ; Sun, 11 Dec 2005 21:48:46 +0000 (GMT) (envelope-from andrew@fubar.geek.nz) Received: from avmta3-rme.xtra.co.nz (avmta3-rme.xtra.co.nz [210.86.15.158]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9952143D75 for ; Sun, 11 Dec 2005 21:48:42 +0000 (GMT) (envelope-from andrew@fubar.geek.nz) Received: from mta4-rme.xtra.co.nz ([210.86.15.193]) by avmta3-rme.xtra.co.nz with ESMTP id <20051211214841.SLDK1410.avmta3-rme.xtra.co.nz@mta4-rme.xtra.co.nz>; Mon, 12 Dec 2005 10:48:41 +1300 Received: from serv.int.fubar.geek.nz ([222.152.219.118]) by mta4-rme.xtra.co.nz with ESMTP id <20051211214841.SAYA1416.mta4-rme.xtra.co.nz@serv.int.fubar.geek.nz>; Mon, 12 Dec 2005 10:48:41 +1300 Received: from [192.168.1.160] (unknown [192.168.1.160]) by serv.int.fubar.geek.nz (Postfix) with ESMTP id 61ECE611A; Mon, 12 Dec 2005 10:48:40 +1300 (NZDT) Message-ID: <439C9EB7.6080800@fubar.geek.nz> Date: Mon, 12 Dec 2005 10:48:39 +1300 From: Andrew Turner User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ulrich Spoerlein References: <439B5907.4010809@fubar.geek.nz> <20051211144138.GA1091@galgenberg.net> In-Reply-To: <20051211144138.GA1091@galgenberg.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: BSDInstaller Beta 2 release 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, 11 Dec 2005 21:48:46 -0000 Ulrich Spoerlein wrote: >>As with the previous Beta release there are three virtual consoles available: >>* ttyv0: The frontend >>* ttyv1: The backend >>* ttyv2: A standard login screen to login as root with no password >> >> > >I can't currently test this, so I'm asking: Is ttyv2 running a full live >system with reasonable $PATH variable? In other words, can I run dd, >fdisk, bsdlabel (including vi), newfs, tar/cp/cpio from inside this >shell? > > Yes, it is what you would get by installing just the base distribution. The installer uses fdisk, bsdlabel, newfs, tar and others in the installation process. >And: Would it thus be possible to use dump(8) from the mounted live-CD and >restore(8) the system to the local hard disk. > > You could use dump and restore as the CD contains both tools. The only problem would be if you don't have enough memory as there is no swap until part way through the install. Andrew From owner-freebsd-current@FreeBSD.ORG Sun Dec 11 21:59:41 2005 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 1C03916A41F for ; Sun, 11 Dec 2005 21:59:41 +0000 (GMT) (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 C503743D45 for ; Sun, 11 Dec 2005 21:59:40 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.192] ([10.0.0.192]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id jBBLxbXq079497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Dec 2005 13:59:40 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <439CA10A.5010204@errno.com> Date: Sun, 11 Dec 2005 13:58:34 -0800 From: Sam Leffler Organization: Errno Consulting User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tomas Hodan References: <200512111038.jBBAcj7L016089@acs.sk> In-Reply-To: <200512111038.jBBAcj7L016089@acs.sk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: new ath_hal 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, 11 Dec 2005 21:59:41 -0000 Tomas Hodan wrote: > hi Sam, > > I successfully compiled your kernel under RELENG_7 with your patches and new > ath_hal, just it's not possible to compile athstats anymore. > > MiniBSD /usr/src/tools/tools/ath # make > cc -o athstats athstats.c > athstats.c: In function `printstats': > athstats.c:128: error: structure has no member named `ast_tx_ctsburst' > athstats.c:128: error: structure has no member named `ast_tx_ctsburst' > athstats.c:129: error: structure has no member named `ast_tx_ctsext' > athstats.c:129: error: structure has no member named `ast_tx_ctsext' > *** Error code 1 > > Stop in /usr/src/tools/tools/ath. > > could you have a look? delete lines 128+129 From owner-freebsd-current@FreeBSD.ORG Sun Dec 11 22:02:25 2005 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 4E7FB16A41F for ; Sun, 11 Dec 2005 22:02:25 +0000 (GMT) (envelope-from marius.nuennerich@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.21]) by mx1.FreeBSD.org (Postfix) with SMTP id 7D16343D67 for ; Sun, 11 Dec 2005 22:02:24 +0000 (GMT) (envelope-from marius.nuennerich@gmx.net) Received: (qmail invoked by alias); 11 Dec 2005 22:02:23 -0000 Received: from p50838879.dip0.t-ipconnect.de (EHLO sol) [80.131.136.121] by mail.gmx.net (mp017) with SMTP; 11 Dec 2005 23:02:23 +0100 X-Authenticated: #5707313 Date: Sun, 11 Dec 2005 23:02:21 +0100 From: Marius N_nnerich To: freebsd-current@freebsd.org Message-ID: <20051211230221.6b87a2a0@sol> In-Reply-To: <439B5907.4010809@fubar.geek.nz> References: <439B5907.4010809@fubar.geek.nz> X-Mailer: Sylpheed-Claws 1.9.100 (GTK+ 2.8.8; 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, 11 Dec 2005 22:13:20 +0000 Subject: Re: BSDInstaller Beta 2 release 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, 11 Dec 2005 22:02:25 -0000 On Sun, 11 Dec 2005 11:39:03 +1300 Andrew Turner wrote: > I am pleased to announce the second release of FreeBSD install CD's > based on the BSD Installer. Hi, thanks for your work. I did a quick test and found that * I can deselect every distribution and accept that "selection", this obviously didn't work to install. I think there should at least be a hint that base is required. * The window to select the distributions is called "Select Packages" * /README is missing * kern.geom.debugflags is set to 16. Is this to allow to manipulate slice and partition information while the disk is mounted? If so, isn't there a better way (mounting the disk after editing those tables)? * The ISO should imo contain a portsnap snapshot and not only ports.tgz * Maybe for src the appropriate checkouts file for cvsup * fdisk and bsdlabel are called very often?! * Did I miss where to install the standard MBR instead of the menu one? * The selected keymap is not written to /etc/rc.conf of the new system? So far I like the Installer. Maybe one day someone integrates a graphical frontend for the installer (eg. like desktopbsd) :) regards Marius From owner-freebsd-current@FreeBSD.ORG Mon Dec 12 00:07:53 2005 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 BD2AB16A41F for ; Mon, 12 Dec 2005 00:07:53 +0000 (GMT) (envelope-from jasone@canonware.com) Received: from lh.synack.net (lh.synack.net [204.152.188.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDA2243D45 for ; Mon, 12 Dec 2005 00:07:51 +0000 (GMT) (envelope-from jasone@canonware.com) Received: by lh.synack.net (Postfix, from userid 100) id 629705E48DA; Sun, 11 Dec 2005 16:07:51 -0800 (PST) Received: from [192.168.168.203] (moscow-cuda-gen2-68-64-60-20.losaca.adelphia.net [68.64.60.20]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by lh.synack.net (Postfix) with ESMTP id AD7195E48A2; Sun, 11 Dec 2005 16:07:46 -0800 (PST) In-Reply-To: References: <0B746373-8C29-4ADF-9218-311AE08F3834@canonware.com> <7318D807-9086-4817-A40B-50D6960880FB@canonware.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <12CA5E15-D006-441D-A24C-1BCD1A69D740@canonware.com> Content-Transfer-Encoding: 7bit From: Jason Evans Date: Sun, 11 Dec 2005 16:04:09 -0800 To: Claus Guttesen X-Mailer: Apple Mail (2.746.2) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on lh.synack.net X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: current@freebsd.org Subject: Re: New libc malloc 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: Mon, 12 Dec 2005 00:07:53 -0000 On Dec 4, 2005, at 4:51 AM, Claus Guttesen wrote: > I was able to do a buildworld on current with this patch, but I had > problems getting X to run and kldxref took all my space on the > root-partition doing a installkernel. I've fixed the offending bug in kldxref in the latest patch: http://www.canonware.com/~jasone/jemalloc/jemalloc_20051211b.diff I spent several hours poking at X, but was never able to determine why it goes into an infinite loop. The infinite loop happens rather early, during the load of the libbitmap module. My best guess is that it is stuck trying to acquire the Xlib lock, but cannot be sure, since I don't know how to get debug symbols for the loaded X module. In any case, malloc is nowhere in the backtrace. I do not have the time to acquire the X expertise that is likely needed to track down this problem. Hopefully someone else will be willing to do so. No new problems in the malloc code have been found for some time now. It has been tested on i386, sparc64, arm, and amd64. In my opinion, the malloc patch is ready to be committed. I am now working on the assumption that new problems are more likely application bugs than malloc bugs. This seems like a good time to start sharing the debugging load with the community. =) So, how about it? Can this patch go in now? Thanks, Jason From owner-freebsd-current@FreeBSD.ORG Mon Dec 12 00:35:42 2005 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 83F4E16A41F for ; Mon, 12 Dec 2005 00:35:42 +0000 (GMT) (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 3093943D55 for ; Mon, 12 Dec 2005 00:35:42 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [192.168.2.6]) ([10.251.60.53]) by a50.ironport.com with ESMTP; 11 Dec 2005 16:35:39 -0800 X-IronPort-Anti-Spam-Filtered: true Message-ID: <439CC5DA.3080103@elischer.org> Date: Sun, 11 Dec 2005 16:35:38 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jason Evans References: <0B746373-8C29-4ADF-9218-311AE08F3834@canonware.com> <7318D807-9086-4817-A40B-50D6960880FB@canonware.com> <12CA5E15-D006-441D-A24C-1BCD1A69D740@canonware.com> In-Reply-To: <12CA5E15-D006-441D-A24C-1BCD1A69D740@canonware.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, Claus Guttesen Subject: Re: New libc malloc 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: Mon, 12 Dec 2005 00:35:42 -0000 Jason Evans wrote: > On Dec 4, 2005, at 4:51 AM, Claus Guttesen wrote: > >> I was able to do a buildworld on current with this patch, but I had >> problems getting X to run and kldxref took all my space on the >> root-partition doing a installkernel. > > > I've fixed the offending bug in kldxref in the latest patch: > > http://www.canonware.com/~jasone/jemalloc/jemalloc_20051211b.diff > > I spent several hours poking at X, but was never able to determine > why it goes into an infinite loop. The infinite loop happens rather > early, during the load of the libbitmap module. My best guess is > that it is stuck trying to acquire the Xlib lock, but cannot be sure, > since I don't know how to get debug symbols for the loaded X module. > In any case, malloc is nowhere in the backtrace. I do not have the > time to acquire the X expertise that is likely needed to track down > this problem. Hopefully someone else will be willing to do so. > > No new problems in the malloc code have been found for some time > now. It has been tested on i386, sparc64, arm, and amd64. In my > opinion, the malloc patch is ready to be committed. I am now working > on the assumption that new problems are more likely application bugs > than malloc bugs. This seems like a good time to start sharing the > debugging load with the community. =) > > So, how about it? Can this patch go in now? I may have missed it but some benchmark numbers could be good. Is there no way to make it an option for a while? that would get good testing AND a fallback for people. > > Thanks, > Jason > _______________________________________________ > 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" From owner-freebsd-current@FreeBSD.ORG Mon Dec 12 00:49:32 2005 Return-Path: X-Original-To: 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 ABFC816A420; Mon, 12 Dec 2005 00:49:31 +0000 (GMT) (envelope-from davidxu@freebsd.org) Message-ID: <439CC939.5080703@freebsd.org> Date: Mon, 12 Dec 2005 08:50:01 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.10) Gecko/20050806 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <0B746373-8C29-4ADF-9218-311AE08F3834@canonware.com> <7318D807-9086-4817-A40B-50D6960880FB@canonware.com> <12CA5E15-D006-441D-A24C-1BCD1A69D740@canonware.com> <439CC5DA.3080103@elischer.org> In-Reply-To: <439CC5DA.3080103@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Claus Guttesen , Jason Evans , current@freebsd.org Subject: Re: New libc malloc 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: Mon, 12 Dec 2005 00:49:32 -0000 Julian Elischer wrote: >> >> No new problems in the malloc code have been found for some time >> now. It has been tested on i386, sparc64, arm, and amd64. In my >> opinion, the malloc patch is ready to be committed. I am now >> working on the assumption that new problems are more likely >> application bugs than malloc bugs. This seems like a good time to >> start sharing the debugging load with the community. =) >> >> So, how about it? Can this patch go in now? > > > > I may have missed it but some benchmark numbers could be good. > > Is there no way to make it an option for a while? > that would get good testing AND a fallback for people. > I also would like to see any benchmark number, in fact, I had plan to import ptmalloc in the past, the malloc problem had been discussed several times in thread@ list. Also, it would be nice if a fallback can be provided :-) David Xu From owner-freebsd-current@FreeBSD.ORG Mon Dec 12 01:29:09 2005 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 B583B16A41F; Mon, 12 Dec 2005 01:29:09 +0000 (GMT) (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 E7ABD43D5A; Mon, 12 Dec 2005 01:29:08 +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 A52F41A3C26; Sun, 11 Dec 2005 17:29:08 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id A48245158E; Sun, 11 Dec 2005 20:29:07 -0500 (EST) Date: Sun, 11 Dec 2005 20:29:07 -0500 From: Kris Kennaway To: David Xu Message-ID: <20051212012907.GA13640@xor.obsecurity.org> References: <0B746373-8C29-4ADF-9218-311AE08F3834@canonware.com> <7318D807-9086-4817-A40B-50D6960880FB@canonware.com> <12CA5E15-D006-441D-A24C-1BCD1A69D740@canonware.com> <439CC5DA.3080103@elischer.org> <439CC939.5080703@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pf9I7BMVVzbSWLtt" Content-Disposition: inline In-Reply-To: <439CC939.5080703@freebsd.org> User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org, Jason Evans , Julian Elischer , Claus Guttesen Subject: Re: New libc malloc 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: Mon, 12 Dec 2005 01:29:10 -0000 --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 12, 2005 at 08:50:01AM +0800, David Xu wrote: > Julian Elischer wrote: >=20 > >> > >>No new problems in the malloc code have been found for some time =20 > >>now. It has been tested on i386, sparc64, arm, and amd64. In my =20 > >>opinion, the malloc patch is ready to be committed. I am now=20 > >>working on the assumption that new problems are more likely=20 > >>application bugs than malloc bugs. This seems like a good time to=20 > >>start sharing the debugging load with the community. =3D) > >> > >>So, how about it? Can this patch go in now? > > > > > > > >I may have missed it but some benchmark numbers could be good. > > > >Is there no way to make it an option for a while? > >that would get good testing AND a fallback for people. > > > I also would like to see any benchmark number, in fact, I had plan > to import ptmalloc in the past, the malloc problem had been discussed > several times in thread@ list. Here is the result of a benchmark that does 1K malloc()/free() with multiple threads on a 14-CPU sparc64 machine. This is a poor test because sparc64 doesn't have TLS support, which is needed for jemalloc to perform well. It still shows it kicking the pants off of phkmalloc for both single-threaded and multi-threaded malloc. phkmalloc: # ./malloc-test 1024 1000000 1 Starting test with 1 thread... Thread 2114048 adjusted timing: 27.124817 seconds for 1000000 requests of = 1024 bytes. Starting test with 2 threads... Thread 2114560 adjusted timing: 67.535854 seconds for 1000000 requests of = 1024 bytes. Thread 2114048 adjusted timing: 70.330298 seconds for 1000000 requests of = 1024 bytes. # ./malloc-test 1024 1000000 3 Starting test with 3 threads... Thread 2114048 adjusted timing: 74.154855 seconds for 1000000 requests of = 1024 bytes. Thread 2115072 adjusted timing: 74.356363 seconds for 1000000 requests of = 1024 bytes. Thread 2114560 adjusted timing: 77.038550 seconds for 1000000 requests of = 1024 bytes. # ./malloc-test 1024 1000000 4 Starting test with 4 threads... Thread 2115072 adjusted timing: 217.741657 seconds for 1000000 requests of= 1024 bytes. Thread 2115584 adjusted timing: 228.434310 seconds for 1000000 requests of= 1024 bytes. Thread 2114048 adjusted timing: 228.941544 seconds for 1000000 requests of= 1024 bytes. Thread 2114560 adjusted timing: 229.286134 seconds for 1000000 requests of= 1024 bytes. # ./malloc-test 1024 1000000 5 Starting test with 5 threads... Thread 2114048 adjusted timing: 770.255000 seconds for 1000000 requests of= 1024 bytes. Thread 2115072 adjusted timing: 770.749431 seconds for 1000000 requests of= 1024 bytes. Thread 2116096 adjusted timing: 771.307654 seconds for 1000000 requests of= 1024 bytes. Thread 2114560 adjusted timing: 772.293253 seconds for 1000000 requests of= 1024 bytes. Thread 2115584 adjusted timing: 772.550847 seconds for 1000000 requests of= 1024 bytes. jemalloc: # ./malloc-test 1024 1000000 1 Starting test with 1 thread... Thread -1610612656 adjusted timing: 5.428918 seconds for 1000000 requests = of 1024 bytes. # ./malloc-test 1024 1000000 2 Starting test with 2 threads... Thread -1610612656 adjusted timing: 4.840497 seconds for 1000000 requests = of 1024 bytes. Thread -1610612176 adjusted timing: 4.948382 seconds for 1000000 requests = of 1024 bytes. # ./malloc-test 1024 1000000 3 Starting test with 3 threads... Thread -1610611696 adjusted timing: 25.065195 seconds for 1000000 requests= of 1024 bytes. Thread -1610612656 adjusted timing: 25.218103 seconds for 1000000 requests= of 1024 bytes. Thread -1610612176 adjusted timing: 25.286181 seconds for 1000000 requests= of 1024 bytes. # ./malloc-test 1024 1000000 4 Starting test with 4 threads... Thread -1610612656 adjusted timing: 38.176479 seconds for 1000000 requests= of 1024 bytes. Thread -1610611216 adjusted timing: 38.221169 seconds for 1000000 requests= of 1024 bytes. Thread -1610611696 adjusted timing: 38.294425 seconds for 1000000 requests= of 1024 bytes. Thread -1610612176 adjusted timing: 38.320669 seconds for 1000000 requests= of 1024 bytes. # ./malloc-test 1024 1000000 5 Starting test with 5 threads... Thread -1610611216 adjusted timing: 50.376766 seconds for 1000000 requests= of 1024 bytes. Thread -1610612656 adjusted timing: 50.435407 seconds for 1000000 requests= of 1024 bytes. Thread -1610611696 adjusted timing: 50.885393 seconds for 1000000 requests= of 1024 bytes. Thread -1610610736 adjusted timing: 50.943412 seconds for 1000000 requests= of 1024 bytes. Thread -1610612176 adjusted timing: 50.953694 seconds for 1000000 requests= of 1024 bytes. i.e. jemalloc is a factor of 5 times faster for single-threaded malloc, and about 15 times faster than phkmalloc for 5 threads. You see the effect of the missing TLS on sparc64 in the scaling (i.e. performance should be even better with multiple threads), and with some large performance variation with larger numbers of threads (probably due to hash collisions): # ./malloc-test 1024 1000000 20 Starting test with 20 threads... Thread -1610604016 adjusted timing: 48.297304 seconds for 1000000 requests= of 1024 bytes. Thread -1610604496 adjusted timing: 104.249693 seconds for 1000000 request= s of 1024 bytes. Thread -1610602496 adjusted timing: 109.578616 seconds for 1000000 request= s of 1024 bytes. Thread -1610607856 adjusted timing: 252.337973 seconds for 1000000 request= s of 1024 bytes. Thread -1610610736 adjusted timing: 254.338225 seconds for 1000000 request= s of 1024 bytes. Thread -1610606896 adjusted timing: 255.015353 seconds for 1000000 request= s of 1024 bytes. Thread -1610607376 adjusted timing: 257.463410 seconds for 1000000 request= s of 1024 bytes. Thread -1610609776 adjusted timing: 257.848283 seconds for 1000000 request= s of 1024 bytes. Thread -1610605936 adjusted timing: 257.955005 seconds for 1000000 request= s of 1024 bytes. Thread -1610604976 adjusted timing: 259.303220 seconds for 1000000 request= s of 1024 bytes. Thread -1610611216 adjusted timing: 259.610871 seconds for 1000000 request= s of 1024 bytes. Thread -1610606416 adjusted timing: 260.622687 seconds for 1000000 request= s of 1024 bytes. Thread -1610611696 adjusted timing: 260.857706 seconds for 1000000 request= s of 1024 bytes. Thread -1610610256 adjusted timing: 261.056716 seconds for 1000000 request= s of 1024 bytes. Thread -1610608816 adjusted timing: 261.764455 seconds for 1000000 request= s of 1024 bytes. Thread -1610609296 adjusted timing: 261.800319 seconds for 1000000 request= s of 1024 bytes. Thread -1610605456 adjusted timing: 261.748707 seconds for 1000000 request= s of 1024 bytes. Thread -1610612176 adjusted timing: 262.108598 seconds for 1000000 request= s of 1024 bytes. Thread -1610608336 adjusted timing: 262.119440 seconds for 1000000 request= s of 1024 bytes. Thread -1610612656 adjusted timing: 262.315112 seconds for 1000000 request= s of 1024 bytes. I'll try to test this on a 4 CPU amd64 machine next. Kris --pf9I7BMVVzbSWLtt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDnNJjWry0BWjoQKURAsiwAJ9vN0+j3xDa6I6JM9RQv1Op0xTaxwCfTY6t RNJAER8CvxRvM/sJPgIJQ5Q= =AYVZ -----END PGP SIGNATURE----- --pf9I7BMVVzbSWLtt-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 12 01:48:57 2005 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 477CA16A41F for ; Mon, 12 Dec 2005 01:48:57 +0000 (GMT) (envelope-from bucht@acc.umu.se) Received: from mail.acc.umu.se (mail.acc.umu.se [130.239.18.156]) by mx1.FreeBSD.org (Postfix) with ESMTP id 805E043D5E for ; Mon, 12 Dec 2005 01:48:55 +0000 (GMT) (envelope-from bucht@acc.umu.se) Received: from localhost (localhost [127.0.0.1]) by amavisd-new (Postfix) with ESMTP id 737EF49A1; Mon, 12 Dec 2005 02:48:54 +0100 (MET) Received: from shaka.acc.umu.se (shaka.acc.umu.se [130.239.18.148]) by mail.acc.umu.se (Postfix) with ESMTP id 178BA4990; Mon, 12 Dec 2005 02:48:53 +0100 (MET) Received: by shaka.acc.umu.se (Postfix, from userid 23835) id E30C117213; Mon, 12 Dec 2005 02:48:52 +0100 (MET) Date: Mon, 12 Dec 2005 02:48:52 +0100 From: Johan Bucht To: Jason Evans Message-ID: <20051212014852.GA8775@shaka.acc.umu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: amavisd-new at acc.umu.se Cc: current@freebsd.org Subject: Re: New libc malloc 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: Mon, 12 Dec 2005 01:48:57 -0000 Ugh, forgot that I used another smtp server than the one subscribed to the list. So the mail shouldn't have made it to the list, if it has I apologize. Remembered one more thing about locking granularity too. Just a few comments, not sure if all of them are valid since I don't have a recent enough system to apply the patch and test it, so my comments are just based on reading the patch. I might have missed some thing hidden between all the lines differing. Can you put up a patched malloc.c somewhere? I made a proof-of-concept parallel allocator for my Master's Thesis during the spring and some of the comments are about differences and similarities between our implementations. * Fork safety functions Nice to have for all allocators and is something I missed having. Would like to have them regardless if your malloc becomes standard or not. * magazines, per-arena caches If I didn't miss something you don't seem to have it, pardon if I missed them in my quick readings. They can really help the scalability and is something that is implemented in Solaris libumem allocator with great success. I implemented them and they helped bring the scalability up quite a bit on the system I tested my allocator on aswell as bringing the allocation latency down. * Saw you used a tree to look up the allocation sizes at free, this * differs from how I and Solaris libumem does it. Instead I went for * prepending a 8/16 byte tag containing the size of the allocation for * lockless size lookup. * Bucket sizes If I didn't miss something you are using power of two sizes. Might be better to use smaller sizes to avoid internal fragmentation, aswell as improving locking granularity. * Locking granularity You use a single lock for the chunk allocation instead of a lock per bucket size or something similar. This means that you limit access unless threads allocate from their private arenas. Since you hash to get an arena there might be multiple threads accessing the same arena at the same time introducing contention. Might be better to have a lock per allocation size to somewhat improve the situation. * Locking primitive The biggest issue and as David Xu pointed out is probably the locking primitives. The SPINLOCK use has a limit in the threading library and makes is hard to have a lot of mutexes. I ended up using a wrapper around the umtx_lock function to get recursive mutexes and it would probably be better to extend the umtx functions to handle recursion. This would probably also be appreciated by other malloc implementations. Might be interesting to implement some of the ideas from the Linux futex implementation to help umtx. * sbrk vs mmap See you added the ability to try brk first and try mmap if brk fails. This is similar to my implementation aswell as ptmalloc. Looks good. * Big allocations It might be preferable to use mmap/munmap directly for big allocations (bigger than a few pages) to avoid the overhead of trying to be smart. These big allocations should be pretty few and shouldn't be that pessimized by this. It also means some memory savings as you can directly free memory from big allocations. * Ownership Didn't look that much for it so might have missed it. Basicly what happens if you free memory allocated in another arena, do you return memory to the arena the memory was allocated from or to the current threads arena? Not returning it to the original arena leads to cache line sharing. Returning it to the original adds some overhead and it might be argued that applications doing this might not be considered scalable and should be fixed instead. * Standalone version Would be nice to have a standalone version to test the allocator on solaris and linux to compare against their allocators. Would be nice for all the people with only access to SMP machines running another OS. I tested my allocator on both Solaris 9 and Freebsd 5/6 and it was both helpful in testing scalability and impact on small machines aswell as finding bugs in the implementation. I tested my allocator against Solaris libc, Hoard and libumem on a 4-cpu Solaris 9 machine (4x UltraSparc IIIi, 1600MHz, 16384MB RAM) at the university and tested my allocator vs the FreeBSD libc on my 400MHz laptop with too much beer and almost non working cpu fan. Beer as in standing in 10cm of beer in my backpack =). Not sure how much of the implementation is FreeBSD dependant, RB-trees?, Solaris 9 has the benefit of using a local malloc inside libc which makes the pthread library functions accessible from the malloc implementation. I avoided touching the libc malloc as I really didn't care at all about single threaded apps and simply used LD_PRELOAD to override libc malloc. Basicly I throw away memory if you allocate a multiple of the page size since I add a tag prepending the memory and I allocate whole pages. So a 8192 byte allocation becomes a 8200 byte allocation, wasting a page. * Focus - Single thread vs multithread What are the focus of the allocator, how much memory is it worth to waste to implement a good scalable implementation. This is the reason I think Solaris still keeps a serial allocator in libc and makes libumem accessible through LD_PRELOAD and friends. * Benchmarks Would be really nice with a few benchmarks against phkmalloc, ptmalloc, hoard and libumem to see how well it stands. Pure local arena allocation apps, Larson benchmarks and some other. Might also be good to see how much more memory it consumes compared to phkmalloc. * Comment Might be wise to fix the comment about always using mmap since brk can be used. * Conclussion Despite not having tested it it looks good and would be nice to have it in FreeBSD. Some parts are really independent on the allocator and would be nice to have, regardless of the general consensus. -- /Johan Bucht bucht@acc.umu.se From owner-freebsd-current@FreeBSD.ORG Mon Dec 12 01:51:27 2005 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 7626416A41F for ; Mon, 12 Dec 2005 01:51:27 +0000 (GMT) (envelope-from jasone@canonware.com) Received: from lh.synack.net (lh.synack.net [204.152.188.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A4B143D5A for ; Mon, 12 Dec 2005 01:51:27 +0000 (GMT) (envelope-from jasone@canonware.com) Received: by lh.synack.net (Postfix, from userid 100) id E431E5E48C4; Sun, 11 Dec 2005 17:51:26 -0800 (PST) Received: from [192.168.168.203] (moscow-cuda-gen2-68-64-60-20.losaca.adelphia.net [68.64.60.20]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by lh.synack.net (Postfix) with ESMTP id 42B385E48C4; Sun, 11 Dec 2005 17:51:26 -0800 (PST) In-Reply-To: <439CC5DA.3080103@elischer.org> References: <0B746373-8C29-4ADF-9218-311AE08F3834@canonware.com> <7318D807-9086-4817-A40B-50D6960880FB@canonware.com> <12CA5E15-D006-441D-A24C-1BCD1A69D740@canonware.com> <439CC5DA.3080103@elischer.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jason Evans Date: Sun, 11 Dec 2005 17:47:57 -0800 To: Julian Elischer X-Mailer: Apple Mail (2.746.2) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on lh.synack.net X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: current@freebsd.org Subject: Re: New libc malloc 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: Mon, 12 Dec 2005 01:51:27 -0000 On Dec 11, 2005, at 4:35 PM, Julian Elischer wrote: > I may have missed it but some benchmark numbers could be good. I haven't posted any benchmark numbers, but that is a reasonable request. Here's a summary of what I've seen so far. For single-threaded apps, phkmalloc and jemalloc exhibit very similar performance for all of the benchmarks I've run. Neither is a clear winner over the other from what I've seen. Kris Kennaway already posted some multi-threaded microbenchmark results. My tests have yielded similar results to his. It would be very informative to run benchmarks with real world multithreaded apps. bind9 (built with threading support) would be a great candidate, but thus far I haven't gotten a chance to use the machines that Robert Watson uses for such tests. > Is there no way to make it an option for a while? > that would get good testing AND a fallback for people. Unfortunately, there are some low level issues that make the two malloc implementations incompatible, and they both need access to libc internals in order to work correctly in a multi-threaded program. The way I have been comparing the two implementations is via chroot installations. It might be possible to make the two compatible (would require extra coding), but since both of them need to be part of libc, we would need a way of building separate libc libraries for the two mallocs. This all seems uglier than it's worth to me. Maybe there's another way... Jason From owner-freebsd-current@FreeBSD.ORG Mon Dec 12 02:03:26 2005 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 C1D4916A420 for ; Mon, 12 Dec 2005 02:03:26 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 16EF043D45 for ; Mon, 12 Dec 2005 02:03:25 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.3) id jBC231Fs006967; Sun, 11 Dec 2005 20:03:01 -0600 (CST) (envelope-from dan) Date: Sun, 11 Dec 2005 20:03:01 -0600 From: Dan Nelson To: Jason Evans Message-ID: <20051212020301.GJ95420@dan.emsphone.com> References: <0B746373-8C29-4ADF-9218-311AE08F3834@canonware.com> <7318D807-9086-4817-A40B-50D6960880FB@canonware.com> <12CA5E15-D006-441D-A24C-1BCD1A69D740@canonware.com> <439CC5DA.3080103@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 5.4-STABLE X-message-flag: Outlook Error User-Agent: Mutt/1.5.11 Cc: Julian Elischer , current@freebsd.org Subject: Re: New libc malloc 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: Mon, 12 Dec 2005 02:03:26 -0000 In the last episode (Dec 11), Jason Evans said: > On Dec 11, 2005, at 4:35 PM, Julian Elischer wrote: > > Is there no way to make it an option for a while? that would get > > good testing AND a fallback for people. > > Unfortunately, there are some low level issues that make the two > malloc implementations incompatible, and they both need access to > libc internals in order to work correctly in a multi-threaded > program. The way I have been comparing the two implementations is > via chroot installations. It might be possible to make the two > compatible (would require extra coding), but since both of them need > to be part of libc, we would need a way of building separate libc > libraries for the two mallocs. This all seems uglier than it's worth > to me. Maybe there's another way... I have had good results by simply compiling malloc.c into a shared library and loading it via LD_PRELOAD. Works enough to run mozilla at least. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Mon Dec 12 02:30:50 2005 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 85E5816A41F for ; Mon, 12 Dec 2005 02:30:50 +0000 (GMT) (envelope-from jasone@canonware.com) Received: from lh.synack.net (lh.synack.net [204.152.188.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01EC843D5F for ; Mon, 12 Dec 2005 02:30:49 +0000 (GMT) (envelope-from jasone@canonware.com) Received: by lh.synack.net (Postfix, from userid 100) id B14855E48ED; Sun, 11 Dec 2005 18:30:49 -0800 (PST) Received: from [192.168.168.203] (moscow-cuda-gen2-68-64-60-20.losaca.adelphia.net [68.64.60.20]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by lh.synack.net (Postfix) with ESMTP id 4D4C65E47EF; Sun, 11 Dec 2005 18:30:44 -0800 (PST) In-Reply-To: <20051212014852.GA8775@shaka.acc.umu.se> References: <20051212014852.GA8775@shaka.acc.umu.se> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9FAD2B4B-C167-42D7-A8E7-BE03F4C07543@canonware.com> Content-Transfer-Encoding: 7bit From: Jason Evans Date: Sun, 11 Dec 2005 18:27:14 -0800 To: Johan Bucht X-Mailer: Apple Mail (2.746.2) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on lh.synack.net X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: current@freebsd.org Subject: Re: New libc malloc 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: Mon, 12 Dec 2005 02:30:50 -0000 Johan, Thank you for your code review! Specific responses follow. On Dec 11, 2005, at 5:48 PM, Johan Bucht wrote: > > Just a few comments, not sure if all of them are valid since I don't > have a recent enough system to apply the patch and test it, so my > comments are just based on reading the patch. I might have missed some > thing hidden between all the lines differing. Can you put up a patched > malloc.c somewhere? http://www.canonware.com/~jasone/jemalloc/malloc.c > * Fork safety functions > Nice to have for all allocators and is something I missed having. > Would > like to have them regardless if your malloc becomes standard or not. I think that the implementation is currently fork-safe. The threads libraries call _malloc_prefork() and _malloc_postfork() in order to avoid locking issues. > * magazines, per-arena caches > If I didn't miss something you don't seem to have it, pardon if I > missed > them in my quick readings. They can really help the scalability and is > something that is implemented in Solaris libumem allocator with great > success. I implemented them and they helped bring the scalability up > quite a bit on the system I tested my allocator on aswell as bringing > the allocation latency down. Arenas do use caches for objects below a size threshold (currently ~1024 bytes on 32-bit systems and ~2048 bytes on 64-bit systems). The caching mechanism is quite different than magazines, but still very effective. > * Saw you used a tree to look up the allocation sizes at free, this > * differs from how I and Solaris libumem does it. Instead I went for > * prepending a 8/16 byte tag containing the size of the allocation for > * lockless size lookup. Actually, my implementation prepends a 4 byte tag that contains allocated/free flags, and the size of the allocation. The trees are only used to look up the sizes of huge allocations (> 8 MB on 32-bit platforms, and > 256 MB on 64-bit platforms). Huge allocations start at chunk boundaries, so prepending a tag would require an entire extra page (and would cause potentially serious external fragmentation on 32-bit systems). > * Bucket sizes > If I didn't miss something you are using power of two sizes. Might be > better to use smaller sizes to avoid internal fragmentation, aswell as > improving locking granularity. My implementation uses quantum-sized buckets (not power of two size classes). The quantum size is either 8 or 16 bytes, depending on the machine architecture. > * Locking granularity > You use a single lock for the chunk allocation instead of a lock per > bucket size or something similar. This means that you limit access > unless threads allocate from their private arenas. Since you hash > to get > an arena there might be multiple threads accessing the same arena > at the > same time introducing contention. Might be better to have a lock per > allocation size to somewhat improve the situation. Using a lock per allocation size requires that slower algorithms be used in some places (and it certainly complicates certain other operations). This didn't seem like a worthwhile tradeoff to me. By making the code faster and simpler, less time is spent in the malloc code. Unless an app does nothing but malloc/free, I don't expect this to be an issue. Even microbenchmarks that do nothing but malloc/ free don't appear to suffer. > * Locking primitive > The biggest issue and as David Xu pointed out is probably the locking > primitives. The SPINLOCK use has a limit in the threading library and > makes is hard to have a lot of mutexes. I ended up using a wrapper > around the umtx_lock function to get recursive mutexes and it would > probably be better to extend the umtx functions to handle recursion. > This would probably also be appreciated by other malloc > implementations. > Might be interesting to implement some of the ideas from the Linux > futex > implementation to help umtx. I have been contemplating creating a separate spinlock API that doesn't require the threads library to track the spinlocks across fork. This would (if I understand correctly) remove the current static spinlock limitations. As for supporting recursive spinlocks, I doubt that the overhead would be acceptable in general. If I could get rid of the need for the one recursive lock in malloc.c, I certainly would. =) > * Big allocations > It might be preferable to use mmap/munmap directly for big allocations > (bigger than a few pages) to avoid the overhead of trying to be smart. > These big allocations should be pretty few and shouldn't be that > pessimized by this. It also means some memory savings as you can > directly free memory from big allocations. I don't really see the approach I'm taking as "trying to be smart", so much as "making it simple by using the same algorithm for almost everything". Many other malloc implementations I've examined use three or more allocation approaches, depending on the allocation size. jemalloc uses only two, and huge allocations really are huge, such that they rarely if ever happen. In practice, I don't think there is a real memory savings to be had. Besides, madvise() calls in strategic locations would achieve approximately the same result. > * Ownership > Didn't look that much for it so might have missed it. Basicly what > happens if you free memory allocated in another arena, do you return > memory to the arena the memory was allocated from or to the current > threads arena? Not returning it to the original arena leads to cache > line sharing. Returning it to the original adds some overhead and it > might be argued that applications doing this might not be considered > scalable and should be fixed instead. Allocated objects can be associated with their parent arenas in constant time (by masking bits in the object addresses). This makes it possible to always free memory back to the same arena it came from. > * Standalone version > Would be nice to have a standalone version to test the allocator on > solaris and linux to compare against their allocators. Would be > nice for > all the people with only access to SMP machines running another OS. I > tested my allocator on both Solaris 9 and Freebsd 5/6 and it was both > helpful in testing scalability and impact on small machines aswell as > finding bugs in the implementation. I tested my allocator against > Solaris libc, Hoard and libumem on a 4-cpu Solaris 9 machine (4x > UltraSparc IIIi, 1600MHz, 16384MB RAM) at the university and tested my > allocator vs the FreeBSD libc on my 400MHz laptop with too much beer > and almost non working cpu fan. Beer as in standing in 10cm of beer in > my backpack =). > Not sure how much of the implementation is FreeBSD dependant, RB- > trees?, I actually have a separate more portable implementation of jemalloc that is part of a programming language runtime library (jemalloc is simply a FreeBSD-ized stand-alone version of that allocator). I've tested it on OS X, Linux, FreeBSD, and (IIRC) Solaris. On Linux I've compared against ptmalloc2, dlmalloc, and hoard. Unfortunately, that version of the allocator has to make some performance sacrifices regarding locking, since it doesn't have access to the pthreads internals. As such, it requires a lot of care to interpret performance results, so I haven't felt it to be worthwhile providing that version here. > * Focus - Single thread vs multithread > What are the focus of the allocator, how much memory is it worth to > waste to implement a good scalable implementation. This is the > reason I > think Solaris still keeps a serial allocator in libc and makes libumem > accessible through LD_PRELOAD and friends. jemalloc only creates two arenas for single-threaded applications (one for internal memory management, and one for user requests), so it doesn't really sacrifice much in the case of single-threaded programs -- a few pages maybe. In the case of multi-threaded programs, it potentially sacrifices memory compactness in order to reduce contention and cache line sharing. > * Comment > Might be wise to fix the comment about always using mmap since brk can > be used. Thanks, done. Jason From owner-freebsd-current@FreeBSD.ORG Mon Dec 12 02:58:42 2005 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 D67BD16A41F for ; Mon, 12 Dec 2005 02:58:42 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mail2.fluidhosting.com [204.14.90.12]) by mx1.FreeBSD.org (Postfix) with SMTP id 5017743D55 for ; Mon, 12 Dec 2005 02:58:42 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 86004 invoked by uid 399); 12 Dec 2005 02:58:41 -0000 Received: from localhost (HELO ?192.168.1.100?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 12 Dec 2005 02:58:41 -0000 Message-ID: <439CE760.9040001@FreeBSD.org> Date: Sun, 11 Dec 2005 18:58:40 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5 (X11/20051203) MIME-Version: 1.0 To: Jason Evans Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: New libc malloc 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: Mon, 12 Dec 2005 02:58:43 -0000 Jason Evans wrote: > It would be very informative to run benchmarks with real world > multithreaded apps. bind9 (built with threading support) would be a > great candidate, Maybe someday, but not at the moment. I've been told by the folks at ISC that in it's current form, threading is a pessimization on all versions of BIND 9 prior to the 9.4 code that they have in CVS (which has not been generally released). Thus, I would not expect performance of BIND 9 with threads to be an accurate reflection of the effectiveness of the library. hth, Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Mon Dec 12 02:56:03 2005 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 8619F16A41F for ; Mon, 12 Dec 2005 02:56:03 +0000 (GMT) (envelope-from dougb@dougbarton.us) Received: from mail2.fluidhosting.com (mail2.fluidhosting.com [204.14.90.12]) by mx1.FreeBSD.org (Postfix) with SMTP id D840143D5F for ; Mon, 12 Dec 2005 02:56:02 +0000 (GMT) (envelope-from dougb@dougbarton.us) Received: (qmail 83468 invoked by uid 399); 12 Dec 2005 02:56:01 -0000 Received: from localhost (HELO ?192.168.1.100?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 12 Dec 2005 02:56:01 -0000 Message-ID: <439CE6C0.8050107@dougbarton.us> Date: Sun, 11 Dec 2005 18:56:00 -0800 From: Doug Barton Organization: http://dougbarton.us/ User-Agent: Thunderbird 1.5 (X11/20051203) MIME-Version: 1.0 To: Jason Evans References: <0B746373-8C29-4ADF-9218-311AE08F3834@canonware.com> <7318D807-9086-4817-A40B-50D6960880FB@canonware.com> <12CA5E15-D006-441D-A24C-1BCD1A69D740@canonware.com> <439CC5DA.3080103@elischer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 12 Dec 2005 03:03:05 +0000 Cc: Julian Elischer , current@freebsd.org Subject: Re: New libc malloc 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: Mon, 12 Dec 2005 02:56:03 -0000 Jason Evans wrote: > It would be very informative to run benchmarks with real world > multithreaded apps. bind9 (built with threading support) would be a > great candidate, Maybe someday, but not at the moment. I've been told by the folks at ISC that in it's current form, threading is a pessimization on all versions of BIND 9 prior to the 9.4 code that they have in CVS (which has not been generally released). Thus, I would not expect performance of BIND 9 with threads to be an accurate reflection of the effectiveness of the library. hth, Doug -- If you're never wrong, you're not trying hard enough From owner-freebsd-current@FreeBSD.ORG Mon Dec 12 03:15:06 2005 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 89AE916A41F for ; Mon, 12 Dec 2005 03:15:06 +0000 (GMT) (envelope-from bucht@acc.umu.se) Received: from mail.acc.umu.se (mail.acc.umu.se [130.239.18.156]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C62A43D5E for ; Mon, 12 Dec 2005 03:15:05 +0000 (GMT) (envelope-from bucht@acc.umu.se) Received: from localhost (localhost [127.0.0.1]) by amavisd-new (Postfix) with ESMTP id 16393496F; Mon, 12 Dec 2005 04:15:04 +0100 (MET) Received: from [192.168.1.100] (53dbce07.umea.cust.skycom.se [83.219.206.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.acc.umu.se (Postfix) with ESMTP id A07574989; Mon, 12 Dec 2005 04:15:01 +0100 (MET) Message-ID: <439CEB74.9080505@acc.umu.se> Date: Mon, 12 Dec 2005 04:16:04 +0100 From: Johan Bucht User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jason Evans References: <20051212014852.GA8775@shaka.acc.umu.se> <9FAD2B4B-C167-42D7-A8E7-BE03F4C07543@canonware.com> In-Reply-To: <9FAD2B4B-C167-42D7-A8E7-BE03F4C07543@canonware.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at acc.umu.se Cc: current@freebsd.org Subject: Re: New libc malloc 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: Mon, 12 Dec 2005 03:15:06 -0000 Jason Evans wrote: > Johan, > > Thank you for your code review! Specific responses follow. Wouldn't exactly call scrolling through a diff at 3 AM review =). > > On Dec 11, 2005, at 5:48 PM, Johan Bucht wrote: > >> >> Just a few comments, not sure if all of them are valid since I don't >> have a recent enough system to apply the patch and test it, so my >> comments are just based on reading the patch. I might have missed some >> thing hidden between all the lines differing. Can you put up a patched >> malloc.c somewhere? > > > http://www.canonware.com/~jasone/jemalloc/malloc.c > Thanks! >> * Fork safety functions >> Nice to have for all allocators and is something I missed having. Would >> like to have them regardless if your malloc becomes standard or not. > > > I think that the implementation is currently fork-safe. The threads > libraries call _malloc_prefork() and _malloc_postfork() in order to > avoid locking issues. > Hmm, I meant that the _malloc_prefork() functions are independent from your malloc allocation and I would like them committed regardless as they make the life easier for other malloc implementation. >> * magazines, per-arena caches >> If I didn't miss something you don't seem to have it, pardon if I >> missed >> them in my quick readings. They can really help the scalability and is >> something that is implemented in Solaris libumem allocator with great >> success. I implemented them and they helped bring the scalability up >> quite a bit on the system I tested my allocator on aswell as bringing >> the allocation latency down. > > > Arenas do use caches for objects below a size threshold (currently > ~1024 bytes on 32-bit systems and ~2048 bytes on 64-bit systems). > The caching mechanism is quite different than magazines, but still > very effective. > Ah nice, shows how little review I did. =) Will look a bit more at this then. >> * Saw you used a tree to look up the allocation sizes at free, this >> * differs from how I and Solaris libumem does it. Instead I went for >> * prepending a 8/16 byte tag containing the size of the allocation for >> * lockless size lookup. > > > Actually, my implementation prepends a 4 byte tag that contains > allocated/free flags, and the size of the allocation. The trees are > only used to look up the sizes of huge allocations (> 8 MB on 32-bit > platforms, and > 256 MB on 64-bit platforms). Huge allocations start > at chunk boundaries, so prepending a tag would require an entire > extra page (and would cause potentially serious external > fragmentation on 32-bit systems). > Isn't 8 byte alignment expected by some applications? How do you know if a allocation is huge if you don't have a tag? Something more to read up on i guess. =) >> * Bucket sizes >> If I didn't miss something you are using power of two sizes. Might be >> better to use smaller sizes to avoid internal fragmentation, aswell as >> improving locking granularity. > > > My implementation uses quantum-sized buckets (not power of two size > classes). The quantum size is either 8 or 16 bytes, depending on the > machine architecture. > Ahh sorry, just saw the pow stuff and assumed it was power of two for the buckets. >> * Locking granularity >> You use a single lock for the chunk allocation instead of a lock per >> bucket size or something similar. This means that you limit access >> unless threads allocate from their private arenas. Since you hash to >> get >> an arena there might be multiple threads accessing the same arena at >> the >> same time introducing contention. Might be better to have a lock per >> allocation size to somewhat improve the situation. > > > Using a lock per allocation size requires that slower algorithms be > used in some places (and it certainly complicates certain other > operations). This didn't seem like a worthwhile tradeoff to me. By > making the code faster and simpler, less time is spent in the malloc > code. Unless an app does nothing but malloc/free, I don't expect > this to be an issue. Even microbenchmarks that do nothing but malloc/ > free don't appear to suffer. > Yeah, not sure how much of an impact it has on your allocator it has, just something that improved my allocator as I move magazines between local arenas and the global. >> * Locking primitive >> The biggest issue and as David Xu pointed out is probably the locking >> primitives. The SPINLOCK use has a limit in the threading library and >> makes is hard to have a lot of mutexes. I ended up using a wrapper >> around the umtx_lock function to get recursive mutexes and it would >> probably be better to extend the umtx functions to handle recursion. >> This would probably also be appreciated by other malloc >> implementations. >> Might be interesting to implement some of the ideas from the Linux >> futex >> implementation to help umtx. > > > I have been contemplating creating a separate spinlock API that > doesn't require the threads library to track the spinlocks across > fork. This would (if I understand correctly) remove the current > static spinlock limitations. > > As for supporting recursive spinlocks, I doubt that the overhead > would be acceptable in general. If I could get rid of the need for > the one recursive lock in malloc.c, I certainly would. =) > Yeah, made some attempts to remove my recursive locks in the global arena but it made the code more complicated and didn't really do much. >> * Big allocations >> It might be preferable to use mmap/munmap directly for big allocations >> (bigger than a few pages) to avoid the overhead of trying to be smart. >> These big allocations should be pretty few and shouldn't be that >> pessimized by this. It also means some memory savings as you can >> directly free memory from big allocations. > > > I don't really see the approach I'm taking as "trying to be smart", > so much as "making it simple by using the same algorithm for almost > everything". Many other malloc implementations I've examined use > three or more allocation approaches, depending on the allocation > size. jemalloc uses only two, and huge allocations really are huge, > such that they rarely if ever happen. In practice, I don't think > there is a real memory savings to be had. Besides, madvise() calls > in strategic locations would achieve approximately the same result. > Yeah, saving them for future use through madvise might be better. I chose the route to keep the big allocations simple and avoid caching and looking up stuff for. Basicly read the size and if it's big munmap it directly. >> * Ownership >> Didn't look that much for it so might have missed it. Basicly what >> happens if you free memory allocated in another arena, do you return >> memory to the arena the memory was allocated from or to the current >> threads arena? Not returning it to the original arena leads to cache >> line sharing. Returning it to the original adds some overhead and it >> might be argued that applications doing this might not be considered >> scalable and should be fixed instead. > > > Allocated objects can be associated with their parent arenas in > constant time (by masking bits in the object addresses). This makes > it possible to always free memory back to the same arena it came from. > Ok, good. >> * Standalone version >> Would be nice to have a standalone version to test the allocator on >> solaris and linux to compare against their allocators. Would be nice >> for >> all the people with only access to SMP machines running another OS. I >> tested my allocator on both Solaris 9 and Freebsd 5/6 and it was both >> helpful in testing scalability and impact on small machines aswell as >> finding bugs in the implementation. I tested my allocator against >> Solaris libc, Hoard and libumem on a 4-cpu Solaris 9 machine (4x >> UltraSparc IIIi, 1600MHz, 16384MB RAM) at the university and tested my >> allocator vs the FreeBSD libc on my 400MHz laptop with too much beer >> and almost non working cpu fan. Beer as in standing in 10cm of beer in >> my backpack =). >> Not sure how much of the implementation is FreeBSD dependant, RB- >> trees?, > > > I actually have a separate more portable implementation of jemalloc > that is part of a programming language runtime library (jemalloc is > simply a FreeBSD-ized stand-alone version of that allocator). I've > tested it on OS X, Linux, FreeBSD, and (IIRC) Solaris. On Linux I've > compared against ptmalloc2, dlmalloc, and hoard. Unfortunately, that > version of the allocator has to make some performance sacrifices > regarding locking, since it doesn't have access to the pthreads > internals. As such, it requires a lot of care to interpret > performance results, so I haven't felt it to be worthwhile providing > that version here. > ok >> * Focus - Single thread vs multithread >> What are the focus of the allocator, how much memory is it worth to >> waste to implement a good scalable implementation. This is the reason I >> think Solaris still keeps a serial allocator in libc and makes libumem >> accessible through LD_PRELOAD and friends. > > > jemalloc only creates two arenas for single-threaded applications > (one for internal memory management, and one for user requests), so > it doesn't really sacrifice much in the case of single-threaded > programs -- a few pages maybe. In the case of multi-threaded > programs, it potentially sacrifices memory compactness in order to > reduce contention and cache line sharing. > As I have not tested it I take your word. Mostly wanted to know where you stand in the issue of pessimizing single-threaded apps vs MT. And if it's worth keeping phkmalloc for some apps. >> * Comment >> Might be wise to fix the comment about always using mmap since brk can >> be used. > > > Thanks, done. > > Jason No problem, always fun to have some code that you actually understand the idea behind and see how it's implemented. /Johan Bucht From owner-freebsd-current@FreeBSD.ORG Mon Dec 12 03:21:40 2005 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 2B13316A41F for ; Mon, 12 Dec 2005 03:21:40 +0000 (GMT) (envelope-from bucht@acc.umu.se) Received: from mail.acc.umu.se (mail.acc.umu.se [130.239.18.156]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD63443D8D for ; Mon, 12 Dec 2005 03:21:32 +0000 (GMT) (envelope-from bucht@acc.umu.se) Received: from localhost (localhost [127.0.0.1]) by amavisd-new (Postfix) with ESMTP id 1CD01498A; Mon, 12 Dec 2005 04:21:32 +0100 (MET) Received: from [192.168.1.100] (53dbce07.umea.cust.skycom.se [83.219.206.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.acc.umu.se (Postfix) with ESMTP id 3484A4989; Mon, 12 Dec 2005 04:21:31 +0100 (MET) Message-ID: <439CED01.9050108@acc.umu.se> Date: Mon, 12 Dec 2005 04:22:41 +0100 From: Johan Bucht User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jason Evans References: <20051212014852.GA8775@shaka.acc.umu.se> <9FAD2B4B-C167-42D7-A8E7-BE03F4C07543@canonware.com> <439CEB74.9080505@acc.umu.se> In-Reply-To: <439CEB74.9080505@acc.umu.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at acc.umu.se Cc: current@freebsd.org Subject: Re: New libc malloc 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: Mon, 12 Dec 2005 03:21:40 -0000 Johan Bucht wrote: >>> * Fork safety functions >>> Nice to have for all allocators and is something I missed having. >>> Would >>> like to have them regardless if your malloc becomes standard or not. >> >> >> >> I think that the implementation is currently fork-safe. The threads >> libraries call _malloc_prefork() and _malloc_postfork() in order to >> avoid locking issues. >> > Hmm, I meant that the _malloc_prefork() functions are independent from > your malloc allocation and I would like them committed regardless as > they make the life easier for other malloc implementation. Bah, the libc bits not the actual functions of course. =) Should probably go to sleep instead of writing semi-understandable sentences. /Johan Bucht From owner-freebsd-current@FreeBSD.ORG Mon Dec 12 03:31:17 2005 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 38F8316A41F for ; Mon, 12 Dec 2005 03:31:17 +0000 (GMT) (envelope-from jasone@canonware.com) Received: from lh.synack.net (lh.synack.net [204.152.188.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 717FD43D58 for ; Mon, 12 Dec 2005 03:31:16 +0000 (GMT) (envelope-from jasone@canonware.com) Received: by lh.synack.net (Postfix, from userid 100) id 4EF0D5E48ED; Sun, 11 Dec 2005 19:31:16 -0800 (PST) Received: from [192.168.168.203] (moscow-cuda-gen2-68-64-60-20.losaca.adelphia.net [68.64.60.20]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by lh.synack.net (Postfix) with ESMTP id 9BD9D5E48A2; Sun, 11 Dec 2005 19:31:11 -0800 (PST) In-Reply-To: <439CEB74.9080505@acc.umu.se> References: <20051212014852.GA8775@shaka.acc.umu.se> <9FAD2B4B-C167-42D7-A8E7-BE03F4C07543@canonware.com> <439CEB74.9080505@acc.umu.se> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jason Evans Date: Sun, 11 Dec 2005 19:27:39 -0800 To: Johan Bucht X-Mailer: Apple Mail (2.746.2) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on lh.synack.net X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: current@freebsd.org Subject: Re: New libc malloc 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: Mon, 12 Dec 2005 03:31:17 -0000 On Dec 11, 2005, at 7:16 PM, Johan Bucht wrote: > Jason Evans wrote: >> >> On Dec 11, 2005, at 5:48 PM, Johan Bucht wrote: >>> * Saw you used a tree to look up the allocation sizes at free, this >>> * differs from how I and Solaris libumem does it. Instead I went for >>> * prepending a 8/16 byte tag containing the size of the >>> allocation for >>> * lockless size lookup. >> >> Actually, my implementation prepends a 4 byte tag that contains >> allocated/free flags, and the size of the allocation. The trees >> are only used to look up the sizes of huge allocations (> 8 MB on >> 32-bit platforms, and > 256 MB on 64-bit platforms). Huge >> allocations start at chunk boundaries, so prepending a tag would >> require an entire extra page (and would cause potentially serious >> external fragmentation on 32-bit systems). >> > Isn't 8 byte alignment expected by some applications? Yes, 8 or 16 byte alignment is expected (in fact I'm of the opinion that we should be using 16 byte alignment on i386 due to SSE2/SSE3). If I understand your question correctly, you're asking how I get away with 4 byte tags. Consider that (assuming 8-byte quantum) a malloc (16) call must actually be serviced by at least 24 bytes internally, in order to pad to the next quantum size. If I used 8 byte tags, then malloc(17) would require 32 bytes internally. By using 4 byte tags, malloc(13)..malloc(20) can be serviced by 24 bytes internally. At least one implementation (the OS X malloc implementation) uses 2 byte tags, but this has two problems: 1) unaligned memory access is slow on some architectures, and 2) it's too small to handle large object sizes, so a different allocation strategy has to be used starting at ~12 KB. > How do you know if a allocation is huge if you don't have a tag? I know an allocation is huge if its base address is chunk-aligned. The actual size is stored in a red-black tree node, which is allocated separately. Jason From owner-freebsd-current@FreeBSD.ORG Mon Dec 12 03:47:33 2005 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 DEC0316A41F for ; Mon, 12 Dec 2005 03:47:33 +0000 (GMT) (envelope-from bucht@acc.umu.se) Received: from mail.acc.umu.se (mail.acc.umu.se [130.239.18.156]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F25943D6D for ; Mon, 12 Dec 2005 03:47:32 +0000 (GMT) (envelope-from bucht@acc.umu.se) Received: from localhost (localhost [127.0.0.1]) by amavisd-new (Postfix) with ESMTP id E7E5B498E; Mon, 12 Dec 2005 04:47:31 +0100 (MET) Received: from [192.168.1.100] (53dbce07.umea.cust.skycom.se [83.219.206.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.acc.umu.se (Postfix) with ESMTP id ADAFC498A; Mon, 12 Dec 2005 04:47:30 +0100 (MET) Message-ID: <439CF318.4070903@acc.umu.se> Date: Mon, 12 Dec 2005 04:48:40 +0100 From: Johan Bucht User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jason Evans References: <20051212014852.GA8775@shaka.acc.umu.se> <9FAD2B4B-C167-42D7-A8E7-BE03F4C07543@canonware.com> <439CEB74.9080505@acc.umu.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at acc.umu.se Cc: current@freebsd.org Subject: Re: New libc malloc 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: Mon, 12 Dec 2005 03:47:34 -0000 Jason Evans wrote: >> Isn't 8 byte alignment expected by some applications? > > > Yes, 8 or 16 byte alignment is expected (in fact I'm of the opinion > that we should be using 16 byte alignment on i386 due to SSE2/SSE3). > If I understand your question correctly, you're asking how I get away > with 4 byte tags. Consider that (assuming 8-byte quantum) a malloc > (16) call must actually be serviced by at least 24 bytes internally, > in order to pad to the next quantum size. If I used 8 byte tags, > then malloc(17) would require 32 bytes internally. By using 4 byte > tags, malloc(13)..malloc(20) can be serviced by 24 bytes internally. > At least one implementation (the OS X malloc implementation) uses 2 > byte tags, but this has two problems: 1) unaligned memory access is > slow on some architectures, and 2) it's too small to handle large > object sizes, so a different allocation strategy has to be used > starting at ~12 KB. > Well, I just wondered how you avoided unaligned accesses with a 4 byte tag. >> How do you know if a allocation is huge if you don't have a tag? > > > I know an allocation is huge if its base address is chunk-aligned. > The actual size is stored in a red-black tree node, which is > allocated separately. Ok, expected it was through the address, thanks for answering anyway. Gonna take some time reading through the code before asking more stupid questions. =) /Johan Bucht From owner-freebsd-current@FreeBSD.ORG Mon Dec 12 04:15:16 2005 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 38EA816A41F; Mon, 12 Dec 2005 04:15:16 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74D4143D4C; Mon, 12 Dec 2005 04:15:15 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.4/8.13.4) with ESMTP id jBC4FDaC037587; Sun, 11 Dec 2005 23:15:13 -0500 (EST) (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.3/8.13.3) with ESMTP id jBC4FEwA050761; Sun, 11 Dec 2005 23:15:14 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 10C887302F; Sun, 11 Dec 2005 23:15:13 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051212041513.10C887302F@freebsd-current.sentex.ca> Date: Sun, 11 Dec 2005 23:15:13 -0500 (EST) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on sparc64/sparc64 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: Mon, 12 Dec 2005 04:15:16 -0000 TB --- 2005-12-12 02:51:25 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-12-12 02:51:25 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2005-12-12 02:51:25 - cleaning the object tree TB --- 2005-12-12 02:51:55 - checking out the source tree TB --- 2005-12-12 02:51:55 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2005-12-12 02:51:55 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-12-12 02:58:11 - building world (CFLAGS=-O2 -pipe) TB --- 2005-12-12 02:58:11 - cd /src TB --- 2005-12-12 02:58:11 - /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 --- 2005-12-12 04:03:21 - generating LINT kernel config TB --- 2005-12-12 04:03:21 - cd /src/sys/sparc64/conf TB --- 2005-12-12 04:03:21 - /usr/bin/make -B LINT TB --- 2005-12-12 04:03:21 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-12-12 04:03:21 - cd /src TB --- 2005-12-12 04:03:21 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Dec 12 04:03:21 UTC 2005 >>> 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 [...] In file included from /src/sys/gnu/fs/xfs/xfs_dfrag.c:58: /src/sys/gnu/fs/xfs/xfs_dfrag.h:49: error: syntax error before '*' token /src/sys/gnu/fs/xfs/xfs_dfrag.h:49: warning: function declaration isn't a prototype /src/sys/gnu/fs/xfs/xfs_dfrag.c:71: warning: no previous prototype for 'xfs_swapext' /src/sys/gnu/fs/xfs/xfs_dfrag.c:71: error: conflicting types for 'xfs_swapext' /src/sys/gnu/fs/xfs/xfs_dfrag.h:49: error: previous declaration of 'xfs_swapext' was here /src/sys/gnu/fs/xfs/xfs_dfrag.c:71: error: conflicting types for 'xfs_swapext' /src/sys/gnu/fs/xfs/xfs_dfrag.h:49: error: previous declaration of 'xfs_swapext' was here *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-12-12 04:15:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-12-12 04:15:13 - ERROR: failed to build lint kernel TB --- 2005-12-12 04:15:13 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Mon Dec 12 04:30:25 2005 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 A715916A41F; Mon, 12 Dec 2005 04:30:25 +0000 (GMT) (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 17C4D43D49; Mon, 12 Dec 2005 04:30:25 +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 9E2421A3C25; Sun, 11 Dec 2005 20:30:24 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 6782951432; Sun, 11 Dec 2005 23:30:23 -0500 (EST) Date: Sun, 11 Dec 2005 23:30:23 -0500 From: Kris Kennaway To: Kris Kennaway Message-ID: <20051212043023.GA16678@xor.obsecurity.org> References: <0B746373-8C29-4ADF-9218-311AE08F3834@canonware.com> <7318D807-9086-4817-A40B-50D6960880FB@canonware.com> <12CA5E15-D006-441D-A24C-1BCD1A69D740@canonware.com> <439CC5DA.3080103@elischer.org> <439CC939.5080703@freebsd.org> <20051212012907.GA13640@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sm4nu43k4a2Rpi4c" Content-Disposition: inline In-Reply-To: <20051212012907.GA13640@xor.obsecurity.org> User-Agent: Mutt/1.4.2.1i Cc: Julian Elischer , Jason Evans , Claus Guttesen , David Xu , current@freebsd.org Subject: Re: New libc malloc 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: Mon, 12 Dec 2005 04:30:25 -0000 --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Dec 11, 2005 at 08:29:07PM -0500, Kris Kennaway wrote: > I'll try to test this on a 4 CPU amd64 machine next. phkmalloc: # ./malloc-test 1024 10000000 1 Starting test with 1 thread... Thread 5298176 adjusted timing: 4.173052 seconds for 10000000 requests of 1024 bytes. # ./malloc-test 1024 10000000 2 Starting test with 2 threads... Thread 5299200 adjusted timing: 325.108643 seconds for 10000000 requests of 1024 bytes. Thread 5298176 adjusted timing: 325.202485 seconds for 10000000 requests of 1024 bytes. # ./malloc-test 1024 10000000 3 Starting test with 3 threads... Thread 5414912 adjusted timing: 1133.238459 seconds for 10000000 requests of 1024 bytes. Thread 5299200 adjusted timing: 1134.525255 seconds for 10000000 requests of 1024 bytes. Thread 5298176 adjusted timing: 1134.539555 seconds for 10000000 requests of 1024 bytes. jemalloc: # ./malloc-test 1024 10000000 1 Starting test with 1 thread... Thread 1073760528 adjusted timing: 3.777175 seconds for 10000000 requests of 1024 bytes. # ./malloc-test 1024 10000000 2 Starting test with 2 threads... Thread 1073760560 adjusted timing: 3.851702 seconds for 10000000 requests of 1024 bytes. Thread 1073761584 adjusted timing: 3.887943 seconds for 10000000 requests of 1024 bytes. # ./malloc-test 1024 10000000 3 Starting test with 3 threads... Thread 1073760528 adjusted timing: 3.866206 seconds for 10000000 requests of 1024 bytes. Thread 1073761552 adjusted timing: 13.382795 seconds for 10000000 requests of 1024 bytes. Thread 1073762688 adjusted timing: 14.407229 seconds for 10000000 requests of 1024 bytes. # ./malloc-test 1024 10000000 4 Starting test with 4 threads... Thread 1073760528 adjusted timing: 3.782923 seconds for 10000000 requests of 1024 bytes. Thread 1073763792 adjusted timing: 6.668655 seconds for 10000000 requests of 1024 bytes. Thread 1073762688 adjusted timing: 14.346569 seconds for 10000000 requests of 1024 bytes. Thread 1073761584 adjusted timing: 14.680211 seconds for 10000000 requests of 1024 bytes. # ./malloc-test 1024 10000000 5 Starting test with 5 threads... Thread 1073760560 adjusted timing: 4.748248 seconds for 10000000 requests of 1024 bytes. Thread 1073761584 adjusted timing: 9.898153 seconds for 10000000 requests of 1024 bytes. Thread 1073764896 adjusted timing: 13.019884 seconds for 10000000 requests of 1024 bytes. Thread 1073762688 adjusted timing: 15.326908 seconds for 10000000 requests of 1024 bytes. Thread 1073763792 adjusted timing: 15.442164 seconds for 10000000 requests of 1024 bytes. So it's 1.1 times faster for single-threaded, and 107 times faster with 3 threads. With libthr instead of libpthread: phkmalloc: # ./malloc-test 1024 10000000 1 Starting test with 1 thread... Thread 5255680 adjusted timing: 2.357247 seconds for 10000000 requests of 1024 bytes. # ./malloc-test 1024 10000000 2 Starting test with 2 threads... Thread 5256192 adjusted timing: 10.964918 seconds for 10000000 requests of 1024 bytes. Thread 5255680 adjusted timing: 11.001288 seconds for 10000000 requests of 1024 bytes. # ./malloc-test 1024 10000000 3 Starting test with 3 threads... Thread 5255680 adjusted timing: 17.467754 seconds for 10000000 requests of 1024 bytes. Thread 5256704 adjusted timing: 17.724583 seconds for 10000000 requests of 1024 bytes. Thread 5256192 adjusted timing: 17.913381 seconds for 10000000 requests of 1024 bytes. # ./malloc-test 1024 10000000 4 Starting test with 4 threads... Thread 5255680 adjusted timing: 42.715420 seconds for 10000000 requests of 1024 bytes. Thread 5256192 adjusted timing: 43.481252 seconds for 10000000 requests of 1024 bytes. Thread 5256704 adjusted timing: 43.871452 seconds for 10000000 requests of 1024 bytes. Thread 5257216 adjusted timing: 43.887820 seconds for 10000000 requests of 1024 bytes. # ./malloc-test 1024 10000000 5 Starting test with 5 threads... Thread 5255680 adjusted timing: 139.316332 seconds for 10000000 requests of 1024 bytes. Thread 5257216 adjusted timing: 140.117720 seconds for 10000000 requests of 1024 bytes. Thread 5256192 adjusted timing: 140.134057 seconds for 10000000 requests of 1024 bytes. Thread 5256704 adjusted timing: 140.855289 seconds for 10000000 requests of 1024 bytes. Thread 5257728 adjusted timing: 140.865934 seconds for 10000000 requests of 1024 bytes. jemalloc: # ./malloc-test 1024 10000000 1 Starting test with 1 thread... Thread 1073742416 adjusted timing: 1.366353 seconds for 10000000 requests of 1024 bytes. # ./malloc-test 1024 10000000 2 Starting test with 2 threads... Thread 1073742416 adjusted timing: 1.429485 seconds for 10000000 requests of 1024 bytes. Thread 1073742896 adjusted timing: 1.530733 seconds for 10000000 requests of 1024 bytes. # ./malloc-test 1024 10000000 3 Starting test with 3 threads... Thread 1073742416 adjusted timing: 1.419813 seconds for 10000000 requests of 1024 bytes. Thread 1073743376 adjusted timing: 1.432790 seconds for 10000000 requests of 1024 bytes. Thread 1073742896 adjusted timing: 1.490218 seconds for 10000000 requests of 1024 bytes. # ./malloc-test 1024 10000000 4 Starting test with 4 threads... Thread 1073743376 adjusted timing: 1.447554 seconds for 10000000 requests of 1024 bytes. Thread 1073742416 adjusted timing: 1.503659 seconds for 10000000 requests of 1024 bytes. Thread 1073743856 adjusted timing: 1.503937 seconds for 10000000 requests of 1024 bytes. Thread 1073742896 adjusted timing: 1.504926 seconds for 10000000 requests of 1024 bytes. # ./malloc-test 1024 10000000 5 Starting test with 5 threads... Thread 1073743376 adjusted timing: 1.595239 seconds for 10000000 requests of 1024 bytes. Thread 1073742896 adjusted timing: 1.689753 seconds for 10000000 requests of 1024 bytes. Thread 1073742416 adjusted timing: 1.750115 seconds for 10000000 requests of 1024 bytes. Thread 1073744336 adjusted timing: 1.744271 seconds for 10000000 requests of 1024 bytes. Thread 1073743856 adjusted timing: 1.890269 seconds for 10000000 requests of 1024 bytes. # ./malloc-test 1024 10000000 6 Starting test with 6 threads... Thread 1073743856 adjusted timing: 1.847653 seconds for 10000000 requests of 1024 bytes. Thread 1073742416 adjusted timing: 2.018481 seconds for 10000000 requests of 1024 bytes. Thread 1073743376 adjusted timing: 2.059817 seconds for 10000000 requests of 1024 bytes. Thread 1073742896 adjusted timing: 2.129204 seconds for 10000000 requests of 1024 bytes. Thread 1073744336 adjusted timing: 2.223751 seconds for 10000000 requests of 1024 bytes. Thread 1073744816 adjusted timing: 2.293809 seconds for 10000000 requests of 1024 bytes. # ./malloc-test 1024 10000000 20 Starting test with 20 threads... Thread 1073744816 adjusted timing: 5.113769 seconds for 10000000 requests of 1024 bytes. Thread 1073751136 adjusted timing: 4.973369 seconds for 10000000 requests of 1024 bytes. Thread 1073750176 adjusted timing: 5.295912 seconds for 10000000 requests of 1024 bytes. Thread 1073745296 adjusted timing: 5.502331 seconds for 10000000 requests of 1024 bytes. Thread 1073743856 adjusted timing: 5.614890 seconds for 10000000 requests of 1024 bytes. Thread 1073744336 adjusted timing: 5.608690 seconds for 10000000 requests of 1024 bytes. Thread 1073752096 adjusted timing: 5.555465 seconds for 10000000 requests of 1024 bytes. Thread 1073748736 adjusted timing: 5.650922 seconds for 10000000 requests of 1024 bytes. Thread 1073748256 adjusted timing: 6.608054 seconds for 10000000 requests of 1024 bytes. Thread 1073750656 adjusted timing: 7.144998 seconds for 10000000 requests of 1024 bytes. Thread 1073742896 adjusted timing: 7.390905 seconds for 10000000 requests of 1024 bytes. Thread 1073746256 adjusted timing: 7.364728 seconds for 10000000 requests of 1024 bytes. Thread 1073742416 adjusted timing: 7.556064 seconds for 10000000 requests of 1024 bytes. Thread 1073749216 adjusted timing: 7.357179 seconds for 10000000 requests of 1024 bytes. Thread 1073752576 adjusted timing: 7.349483 seconds for 10000000 requests of 1024 bytes. c Thread 1073747776 adjusted timing: 7.375179 seconds for 10000000 requests of 1024 bytes. Thread 1073751616 adjusted timing: 7.557854 seconds for 10000000 requests of 1024 bytes. Thread 1073743376 adjusted timing: 7.915978 seconds for 10000000 requests of 1024 bytes. Thread 1073749696 adjusted timing: 7.795219 seconds for 10000000 requests of 1024 bytes. Thread 1073745776 adjusted timing: 8.007392 seconds for 10000000 requests of 1024 bytes. So libthr is *much* faster than libpthread with both malloc implementations, but jemalloc is still 1.7 times faster for 1 thread and 80 times faster for 5 threads than phkmalloc. Kris P.S. Holy crap :) --sm4nu43k4a2Rpi4c Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDnPzeWry0BWjoQKURAnVqAJ9cJGJuCWOLnIKy1Y+V6DEyZeUrWwCgxOzF X+0gquCFzLB20OwCt+7qhVc= =rZUQ -----END PGP SIGNATURE----- --sm4nu43k4a2Rpi4c-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 12 05:03:22 2005 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 929DC16A41F for ; Mon, 12 Dec 2005 05:03:22 +0000 (GMT) (envelope-from bucht@acc.umu.se) Received: from mail.acc.umu.se (mail.acc.umu.se [130.239.18.156]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E4C943D49 for ; Mon, 12 Dec 2005 05:03:20 +0000 (GMT) (envelope-from bucht@acc.umu.se) Received: from localhost (localhost [127.0.0.1]) by amavisd-new (Postfix) with ESMTP id A94B4498E; Mon, 12 Dec 2005 06:03:19 +0100 (MET) Received: from [192.168.1.100] (53dbce07.umea.cust.skycom.se [83.219.206.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.acc.umu.se (Postfix) with ESMTP id 408044989; Mon, 12 Dec 2005 06:03:17 +0100 (MET) Message-ID: <439D04CF.1000204@acc.umu.se> Date: Mon, 12 Dec 2005 06:04:15 +0100 From: Johan Bucht User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kris Kennaway References: <0B746373-8C29-4ADF-9218-311AE08F3834@canonware.com> <7318D807-9086-4817-A40B-50D6960880FB@canonware.com> <12CA5E15-D006-441D-A24C-1BCD1A69D740@canonware.com> <439CC5DA.3080103@elischer.org> <439CC939.5080703@freebsd.org> <20051212012907.GA13640@xor.obsecurity.org> <20051212043023.GA16678@xor.obsecurity.org> In-Reply-To: <20051212043023.GA16678@xor.obsecurity.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at acc.umu.se Cc: current@freebsd.org Subject: Re: New libc malloc 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: Mon, 12 Dec 2005 05:03:22 -0000 Kris Kennaway wrote: >On Sun, Dec 11, 2005 at 08:29:07PM -0500, Kris Kennaway wrote: > > > >>I'll try to test this on a 4 CPU amd64 machine next. >> >> > > > Thanks for the time. >phkmalloc: > ># ./malloc-test 1024 10000000 1 >Starting test with 1 thread... > Thread 5298176 adjusted timing: 4.173052 seconds for 10000000 requests of 1024 bytes. ># ./malloc-test 1024 10000000 2 >Starting test with 2 threads... > Thread 5299200 adjusted timing: 325.108643 seconds for 10000000 requests of 1024 bytes. > Thread 5298176 adjusted timing: 325.202485 seconds for 10000000 requests of 1024 bytes. ># ./malloc-test 1024 10000000 3 >Starting test with 3 threads... > Thread 5414912 adjusted timing: 1133.238459 seconds for 10000000 requests of 1024 bytes. > Thread 5299200 adjusted timing: 1134.525255 seconds for 10000000 requests of 1024 bytes. > Thread 5298176 adjusted timing: 1134.539555 seconds for 10000000 requests of 1024 bytes. > > > Those times seems way too high even for a serial allocator, is libpthread performance really this bad on amd64 or is it broken? >jemalloc: > ># ./malloc-test 1024 10000000 1 >Starting test with 1 thread... > Thread 1073760528 adjusted timing: 3.777175 seconds for 10000000 requests of 1024 bytes. ># ./malloc-test 1024 10000000 2 >Starting test with 2 threads... > Thread 1073760560 adjusted timing: 3.851702 seconds for 10000000 requests of 1024 bytes. > Thread 1073761584 adjusted timing: 3.887943 seconds for 10000000 requests of 1024 bytes. ># ./malloc-test 1024 10000000 3 >Starting test with 3 threads... > Thread 1073760528 adjusted timing: 3.866206 seconds for 10000000 requests of 1024 bytes. > Thread 1073761552 adjusted timing: 13.382795 seconds for 10000000 requests of 1024 bytes. > Thread 1073762688 adjusted timing: 14.407229 seconds for 10000000 requests of 1024 bytes. ># ./malloc-test 1024 10000000 4 >Starting test with 4 threads... > Thread 1073760528 adjusted timing: 3.782923 seconds for 10000000 requests of 1024 bytes. > Thread 1073763792 adjusted timing: 6.668655 seconds for 10000000 requests of 1024 bytes. > Thread 1073762688 adjusted timing: 14.346569 seconds for 10000000 requests of 1024 bytes. > Thread 1073761584 adjusted timing: 14.680211 seconds for 10000000 requests of 1024 bytes. ># ./malloc-test 1024 10000000 5 >Starting test with 5 threads... > Thread 1073760560 adjusted timing: 4.748248 seconds for 10000000 requests of 1024 bytes. > Thread 1073761584 adjusted timing: 9.898153 seconds for 10000000 requests of 1024 bytes. > Thread 1073764896 adjusted timing: 13.019884 seconds for 10000000 requests of 1024 bytes. > Thread 1073762688 adjusted timing: 15.326908 seconds for 10000000 requests of 1024 bytes. > Thread 1073763792 adjusted timing: 15.442164 seconds for 10000000 requests of 1024 bytes. > >So it's 1.1 times faster for single-threaded, and 107 times faster >with 3 threads. > > > The problem with thread scheduling under 4bsd as reported earlier making the first thread getting higher priority than the later threads, makes these numbers a bit strange. >With libthr instead of libpthread: > >phkmalloc: > ># ./malloc-test 1024 10000000 1 >Starting test with 1 thread... > Thread 5255680 adjusted timing: 2.357247 seconds for 10000000 requests of 1024 bytes. ># ./malloc-test 1024 10000000 2 >Starting test with 2 threads... > Thread 5256192 adjusted timing: 10.964918 seconds for 10000000 requests of 1024 bytes. > Thread 5255680 adjusted timing: 11.001288 seconds for 10000000 requests of 1024 bytes. ># ./malloc-test 1024 10000000 3 >Starting test with 3 threads... > Thread 5255680 adjusted timing: 17.467754 seconds for 10000000 requests of 1024 bytes. > Thread 5256704 adjusted timing: 17.724583 seconds for 10000000 requests of 1024 bytes. > Thread 5256192 adjusted timing: 17.913381 seconds for 10000000 requests of 1024 bytes. ># ./malloc-test 1024 10000000 4 >Starting test with 4 threads... > Thread 5255680 adjusted timing: 42.715420 seconds for 10000000 requests of 1024 bytes. > Thread 5256192 adjusted timing: 43.481252 seconds for 10000000 requests of 1024 bytes. > Thread 5256704 adjusted timing: 43.871452 seconds for 10000000 requests of 1024 bytes. > Thread 5257216 adjusted timing: 43.887820 seconds for 10000000 requests of 1024 bytes. ># ./malloc-test 1024 10000000 5 >Starting test with 5 threads... > Thread 5255680 adjusted timing: 139.316332 seconds for 10000000 requests of 1024 bytes. > Thread 5257216 adjusted timing: 140.117720 seconds for 10000000 requests of 1024 bytes. > Thread 5256192 adjusted timing: 140.134057 seconds for 10000000 requests of 1024 bytes. > Thread 5256704 adjusted timing: 140.855289 seconds for 10000000 requests of 1024 bytes. > Thread 5257728 adjusted timing: 140.865934 seconds for 10000000 requests of 1024 bytes. > > > Looks reasonable for a serial allocator. >jemalloc: > ># ./malloc-test 1024 10000000 1 >Starting test with 1 thread... > Thread 1073742416 adjusted timing: 1.366353 seconds for 10000000 requests of 1024 bytes. ># ./malloc-test 1024 10000000 2 >Starting test with 2 threads... > Thread 1073742416 adjusted timing: 1.429485 seconds for 10000000 requests of 1024 bytes. > Thread 1073742896 adjusted timing: 1.530733 seconds for 10000000 requests of 1024 bytes. ># ./malloc-test 1024 10000000 3 >Starting test with 3 threads... > Thread 1073742416 adjusted timing: 1.419813 seconds for 10000000 requests of 1024 bytes. > Thread 1073743376 adjusted timing: 1.432790 seconds for 10000000 requests of 1024 bytes. > Thread 1073742896 adjusted timing: 1.490218 seconds for 10000000 requests of 1024 bytes. ># ./malloc-test 1024 10000000 4 >Starting test with 4 threads... > Thread 1073743376 adjusted timing: 1.447554 seconds for 10000000 requests of 1024 bytes. > Thread 1073742416 adjusted timing: 1.503659 seconds for 10000000 requests of 1024 bytes. > Thread 1073743856 adjusted timing: 1.503937 seconds for 10000000 requests of 1024 bytes. > Thread 1073742896 adjusted timing: 1.504926 seconds for 10000000 requests of 1024 bytes. ># ./malloc-test 1024 10000000 5 >Starting test with 5 threads... > Thread 1073743376 adjusted timing: 1.595239 seconds for 10000000 requests of 1024 bytes. > Thread 1073742896 adjusted timing: 1.689753 seconds for 10000000 requests of 1024 bytes. > Thread 1073742416 adjusted timing: 1.750115 seconds for 10000000 requests of 1024 bytes. > Thread 1073744336 adjusted timing: 1.744271 seconds for 10000000 requests of 1024 bytes. > Thread 1073743856 adjusted timing: 1.890269 seconds for 10000000 requests of 1024 bytes. ># ./malloc-test 1024 10000000 6 >Starting test with 6 threads... > Thread 1073743856 adjusted timing: 1.847653 seconds for 10000000 requests of 1024 bytes. > Thread 1073742416 adjusted timing: 2.018481 seconds for 10000000 requests of 1024 bytes. > Thread 1073743376 adjusted timing: 2.059817 seconds for 10000000 requests of 1024 bytes. > Thread 1073742896 adjusted timing: 2.129204 seconds for 10000000 requests of 1024 bytes. > Thread 1073744336 adjusted timing: 2.223751 seconds for 10000000 requests of 1024 bytes. > Thread 1073744816 adjusted timing: 2.293809 seconds for 10000000 requests of 1024 bytes. ># ./malloc-test 1024 10000000 20 >Starting test with 20 threads... > Thread 1073744816 adjusted timing: 5.113769 seconds for 10000000 requests of 1024 bytes. > Thread 1073751136 adjusted timing: 4.973369 seconds for 10000000 requests of 1024 bytes. > Thread 1073750176 adjusted timing: 5.295912 seconds for 10000000 requests of 1024 bytes. > Thread 1073745296 adjusted timing: 5.502331 seconds for 10000000 requests of 1024 bytes. > Thread 1073743856 adjusted timing: 5.614890 seconds for 10000000 requests of 1024 bytes. > Thread 1073744336 adjusted timing: 5.608690 seconds for 10000000 requests of 1024 bytes. > Thread 1073752096 adjusted timing: 5.555465 seconds for 10000000 requests of 1024 bytes. > Thread 1073748736 adjusted timing: 5.650922 seconds for 10000000 requests of 1024 bytes. > Thread 1073748256 adjusted timing: 6.608054 seconds for 10000000 requests of 1024 bytes. > Thread 1073750656 adjusted timing: 7.144998 seconds for 10000000 requests of 1024 bytes. > Thread 1073742896 adjusted timing: 7.390905 seconds for 10000000 requests of 1024 bytes. > Thread 1073746256 adjusted timing: 7.364728 seconds for 10000000 requests of 1024 bytes. > Thread 1073742416 adjusted timing: 7.556064 seconds for 10000000 requests of 1024 bytes. > Thread 1073749216 adjusted timing: 7.357179 seconds for 10000000 requests of 1024 bytes. > Thread 1073752576 adjusted timing: 7.349483 seconds for 10000000 requests of 1024 bytes. >c Thread 1073747776 adjusted timing: 7.375179 seconds for 10000000 requests of 1024 bytes. > Thread 1073751616 adjusted timing: 7.557854 seconds for 10000000 requests of 1024 bytes. > Thread 1073743376 adjusted timing: 7.915978 seconds for 10000000 requests of 1024 bytes. > Thread 1073749696 adjusted timing: 7.795219 seconds for 10000000 requests of 1024 bytes. > Thread 1073745776 adjusted timing: 8.007392 seconds for 10000000 requests of 1024 bytes. > > > Seems to experience the same scheduling issues but to a lesser extent. >So libthr is *much* faster than libpthread with both malloc >implementations, but jemalloc is still 1.7 times faster for 1 thread >and 80 times faster for 5 threads than phkmalloc. > > > This test simply tests the local arena performance making it the worst case for serial allocators as all threads contend for the same lock. At the same time this is the best case scenario for jemalloc as all memory resides in the local arena. This means no contention at all unless the threads get hashed into the same arena. Basicly you are comparing worst case of phkmalloc vs best case of jemalloc. =) Would be nice if someone could run some supersmack benchmarks. >Kris > >P.S. Holy crap :) > > From owner-freebsd-current@FreeBSD.ORG Mon Dec 12 05:56:07 2005 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 03CE316A420 for ; Mon, 12 Dec 2005 05:56:07 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6263443D5A; Mon, 12 Dec 2005 05:56:06 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id jBC5u4uk041944; Mon, 12 Dec 2005 05:56:05 GMT (envelope-from davidxu@freebsd.org) Message-ID: <439D10F9.6060004@freebsd.org> Date: Mon, 12 Dec 2005 13:56:09 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20050928 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Johan Bucht References: <0B746373-8C29-4ADF-9218-311AE08F3834@canonware.com> <7318D807-9086-4817-A40B-50D6960880FB@canonware.com> <12CA5E15-D006-441D-A24C-1BCD1A69D740@canonware.com> <439CC5DA.3080103@elischer.org> <439CC939.5080703@freebsd.org> <20051212012907.GA13640@xor.obsecurity.org> <20051212043023.GA16678@xor.obsecurity.org> <439D04CF.1000204@acc.umu.se> In-Reply-To: <439D04CF.1000204@acc.umu.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, Kris Kennaway Subject: Re: New libc malloc 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: Mon, 12 Dec 2005 05:56:07 -0000 Johan Bucht wrote: > >> > Those times seems way too high even for a serial allocator, is > libpthread performance really this bad on amd64 or is it broken? > Not sure which thread library has been tested. From owner-freebsd-current@FreeBSD.ORG Mon Dec 12 05:58:07 2005 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 4EA2E16A41F; Mon, 12 Dec 2005 05:58:07 +0000 (GMT) (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 D16A043D5A; Mon, 12 Dec 2005 05:58:06 +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 E92811A3C27; Sun, 11 Dec 2005 21:58:05 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id B1B95512AB; Mon, 12 Dec 2005 00:58:04 -0500 (EST) Date: Mon, 12 Dec 2005 00:58:04 -0500 From: Kris Kennaway To: David Xu Message-ID: <20051212055804.GA18100@xor.obsecurity.org> References: <7318D807-9086-4817-A40B-50D6960880FB@canonware.com> <12CA5E15-D006-441D-A24C-1BCD1A69D740@canonware.com> <439CC5DA.3080103@elischer.org> <439CC939.5080703@freebsd.org> <20051212012907.GA13640@xor.obsecurity.org> <20051212043023.GA16678@xor.obsecurity.org> <439D04CF.1000204@acc.umu.se> <439D10F9.6060004@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XsQoSWH+UP9D9v3l" Content-Disposition: inline In-Reply-To: <439D10F9.6060004@freebsd.org> User-Agent: Mutt/1.4.2.1i Cc: Johan Bucht , current@freebsd.org, Kris Kennaway Subject: Re: New libc malloc 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: Mon, 12 Dec 2005 05:58:07 -0000 --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 12, 2005 at 01:56:09PM +0800, David Xu wrote: > Johan Bucht wrote: > > > >> > >Those times seems way too high even for a serial allocator, is=20 > >libpthread performance really this bad on amd64 or is it broken? > > > Not sure which thread library has been tested. The quoted text referred to libpthread, the default on amd64. Kris --XsQoSWH+UP9D9v3l Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDnRFsWry0BWjoQKURAvHZAJ0aGYPBhbExU7Fs4e7Mqc/6ByW9DgCgoY9X g4ptKz1HcAb8neIM9jA6QZY= =tFOT -----END PGP SIGNATURE----- --XsQoSWH+UP9D9v3l-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 12 05:58:40 2005 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 B8CCE16A41F for ; Mon, 12 Dec 2005 05:58:40 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id E334B43D67 for ; Mon, 12 Dec 2005 05:58:39 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.5/8.13.5/NETPLEX) with ESMTP id jBC5wQlB012762; Mon, 12 Dec 2005 00:58:26 -0500 (EST) Date: Mon, 12 Dec 2005 00:58:25 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Jason Evans In-Reply-To: <9FAD2B4B-C167-42D7-A8E7-BE03F4C07543@canonware.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: Johan Bucht , current@freebsd.org Subject: Re: New libc malloc patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2005 05:58:40 -0000 On Sun, 11 Dec 2005, Jason Evans wrote: > On Dec 11, 2005, at 5:48 PM, Johan Bucht wrote: > > > * Locking primitive > > The biggest issue and as David Xu pointed out is probably the locking > > primitives. The SPINLOCK use has a limit in the threading library and > > makes is hard to have a lot of mutexes. I ended up using a wrapper > > around the umtx_lock function to get recursive mutexes and it would > > probably be better to extend the umtx functions to handle recursion. > > This would probably also be appreciated by other malloc > > implementations. > > Might be interesting to implement some of the ideas from the Linux > > futex > > implementation to help umtx. > > I have been contemplating creating a separate spinlock API that > doesn't require the threads library to track the spinlocks across > fork. This would (if I understand correctly) remove the current > static spinlock limitations. What about using pthread_atfork()? > As for supporting recursive spinlocks, I doubt that the overhead > would be acceptable in general. If I could get rid of the need for > the one recursive lock in malloc.c, I certainly would. =) Why do we need a recursive mutex? Can you not restructure the code so that it is not needed? -- DE From owner-freebsd-current@FreeBSD.ORG Mon Dec 12 06:32:12 2005 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 BAA2E16A41F; Mon, 12 Dec 2005 06:32:12 +0000 (GMT) (envelope-from jasone@canonware.com) Received: from lh.synack.net (lh.synack.net [204.152.188.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C8F243D4C; Mon, 12 Dec 2005 06:32:10 +0000 (GMT) (envelope-from jasone@canonware.com) Received: by lh.synack.net (Postfix, from userid 100) id C06265E48ED; Sun, 11 Dec 2005 22:32:10 -0800 (PST) Received: from [192.168.168.203] (moscow-cuda-gen2-68-64-60-20.losaca.adelphia.net [68.64.60.20]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by lh.synack.net (Postfix) with ESMTP id EDADC5E47EF; Sun, 11 Dec 2005 22:32:07 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jason Evans Date: Sun, 11 Dec 2005 22:28:30 -0800 To: Daniel Eischen X-Mailer: Apple Mail (2.746.2) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on lh.synack.net X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: Johan Bucht , current@freebsd.org Subject: Re: New libc malloc 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: Mon, 12 Dec 2005 06:32:12 -0000 On Dec 11, 2005, at 9:58 PM, Daniel Eischen wrote: > On Sun, 11 Dec 2005, Jason Evans wrote: >> I have been contemplating creating a separate spinlock API that >> doesn't require the threads library to track the spinlocks across >> fork. This would (if I understand correctly) remove the current >> static spinlock limitations. > > What about using pthread_atfork()? Aren't there potential ordering issues for that? It seems to me that the malloc pre-fork code would need to be run after any other pre- fork functions, in order to avoid potential deadlock, and that the malloc post-fork code would need to be run before any other post-fork functions, again to avoid potential deadlock. After looking at the spinlock code some more, it's no longer clear to me why the thread/thr_spinlock.c code uses a static array for spinlocks. It seems to me that it would work fine to allow the program to provide space for a spinlock and manually initialize it. This would remove the limitation on the number of spinlocks. >> As for supporting recursive spinlocks, I doubt that the overhead >> would be acceptable in general. If I could get rid of the need for >> the one recursive lock in malloc.c, I certainly would. =) > > Why do we need a recursive mutex? Can you not restructure the > code so that it is not needed? There is an internal arena that the malloc code uses for allocating internal data structures. In some cases, the internal arena has to recursively allocate. If there were no object caching, it might be possible to pre-allocate, such that recursion never happens, but given the object caching, it's difficult to reason about precisely what will occur internally for a single malloc/free operation. There are some other possibilities, but nothing I've thought of so far is simple or elegant. Fixing this would make all locking in the malloc code a bit cheaper, which is why it continues to bother me. Jason From owner-freebsd-current@FreeBSD.ORG Mon Dec 12 07:02:57 2005 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 14C3116A41F for ; Mon, 12 Dec 2005 07:02:57 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail25.syd.optusnet.com.au (mail25.syd.optusnet.com.au [211.29.133.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E8B843D5A for ; Mon, 12 Dec 2005 07:02:55 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail25.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id jBC72WNC015273 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 12 Dec 2005 18:02:41 +1100 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.10/8.12.10) with ESMTP id jBC72VHh076127; Mon, 12 Dec 2005 18:02:32 +1100 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost) by cirb503493.alcatel.com.au (8.12.10/8.12.9/Submit) id jBC72Vlf076126; Mon, 12 Dec 2005 18:02:31 +1100 (EST) (envelope-from pjeremy) Date: Mon, 12 Dec 2005 18:02:31 +1100 From: Peter Jeremy To: Jason Evans Message-ID: <20051212070231.GB74684@cirb503493.alcatel.com.au> References: <0B746373-8C29-4ADF-9218-311AE08F3834@canonware.com> <7318D807-9086-4817-A40B-50D6960880FB@canonware.com> <12CA5E15-D006-441D-A24C-1BCD1A69D740@canonware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <12CA5E15-D006-441D-A24C-1BCD1A69D740@canonware.com> User-Agent: Mutt/1.4.2.1i X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc Cc: current@freebsd.org Subject: Re: New libc malloc 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: Mon, 12 Dec 2005 07:02:57 -0000 On Sun, 2005-Dec-11 16:04:09 -0800, Jason Evans wrote: >early, during the load of the libbitmap module. My best guess is >that it is stuck trying to acquire the Xlib lock, but cannot be sure, >since I don't know how to get debug symbols for the loaded X module. I've run into a related problem in the past. Eric Anholt's advice was: >You could compile all the modules into the server by adding "#define >DoLoadableServer NO" to your host.conf when you compile XFree86-4-Server >(see scripts/configure for other defines that are added). Something similar probably works in X.org. I found that I had to remove elo2300 from XInputDrivers to correct a unresolved 'ELO2300'. -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Mon Dec 12 07:05:43 2005 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 6B98616A41F for ; Mon, 12 Dec 2005 07:05:43 +0000 (GMT) (envelope-from andrew@fubar.geek.nz) Received: from mta206-rme.xtra.co.nz (mta206-rme.xtra.co.nz [210.86.15.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 477D943D55 for ; Mon, 12 Dec 2005 07:05:41 +0000 (GMT) (envelope-from andrew@fubar.geek.nz) Received: from mta4-rme.xtra.co.nz ([210.86.15.192]) by mta206-rme.xtra.co.nz with ESMTP id <20051212070540.NZMH8029.mta206-rme.xtra.co.nz@mta4-rme.xtra.co.nz>; Mon, 12 Dec 2005 20:05:40 +1300 Received: from serv.int.fubar.geek.nz ([222.152.219.118]) by mta4-rme.xtra.co.nz with ESMTP id <20051212070540.JHSC1416.mta4-rme.xtra.co.nz@serv.int.fubar.geek.nz>; Mon, 12 Dec 2005 20:05:40 +1300 Received: from [192.168.1.160] (unknown [192.168.1.160]) by serv.int.fubar.geek.nz (Postfix) with ESMTP id 93BC760DD; Mon, 12 Dec 2005 20:05:38 +1300 (NZDT) Message-ID: <439D2148.2050406@fubar.geek.nz> Date: Mon, 12 Dec 2005 20:05:44 +1300 From: Andrew Turner User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marius N_nnerich References: <439B5907.4010809@fubar.geek.nz> <20051211230221.6b87a2a0@sol> In-Reply-To: <20051211230221.6b87a2a0@sol> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: BSDInstaller Beta 2 release 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, 12 Dec 2005 07:05:43 -0000 Marius N_nnerich wrote: >On Sun, 11 Dec 2005 11:39:03 +1300 >Andrew Turner wrote: > > > >>I am pleased to announce the second release of FreeBSD install CD's >>based on the BSD Installer. >> >> > >Hi, > >thanks for your work. > >I did a quick test and found that > >* I can deselect every distribution and accept that "selection", > this obviously didn't work to install. I think there should at > least be a hint that base is required. > > Thanks, I've added a note pointing out base is important. >* The window to select the distributions is called "Select Packages" > > Corrected the name. >* /README is missing > >* kern.geom.debugflags is set to 16. Is this to allow to manipulate > slice and partition information while the disk is mounted? If so, > isn't there a better way (mounting the disk after editing those > tables)? > > I needed it to install the mbr but dosn't appear to be needed anymore. >* The ISO should imo contain a portsnap snapshot and not only > ports.tgz > > I will when it is availiable in the release Makefile as it is outside the scope of this. >* Maybe for src the appropriate checkouts file for cvsup > >* fdisk and bsdlabel are called very often?! > > Talk to the main BSDInstaller developers about that. >* Did I miss where to install the standard MBR instead of the menu one? > > No, there is currently no way of doing it. >* The selected keymap is not written to /etc/rc.conf of the new system? > > I'll look into it. > >So far I like the Installer. >Maybe one day someone integrates a graphical frontend >for the installer (eg. like desktopbsd) :) > > As the frontend and backend are seperate processes it is possible to write a graphical frontend. From owner-freebsd-current@FreeBSD.ORG Mon Dec 12 07:17:58 2005 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 DF43616A420 for ; Mon, 12 Dec 2005 07:17:58 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6585F43D60; Mon, 12 Dec 2005 07:17:58 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id jBC7Hu3P046219; Mon, 12 Dec 2005 07:17:57 GMT (envelope-from davidxu@freebsd.org) Message-ID: <439D2429.7040808@freebsd.org> Date: Mon, 12 Dec 2005 15:18:01 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20050928 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kris Kennaway References: <7318D807-9086-4817-A40B-50D6960880FB@canonware.com> <12CA5E15-D006-441D-A24C-1BCD1A69D740@canonware.com> <439CC5DA.3080103@elischer.org> <439CC939.5080703@freebsd.org> <20051212012907.GA13640@xor.obsecurity.org> <20051212043023.GA16678@xor.obsecurity.org> <439D04CF.1000204@acc.umu.se> <439D10F9.6060004@freebsd.org> <20051212055804.GA18100@xor.obsecurity.org> In-Reply-To: <20051212055804.GA18100@xor.obsecurity.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Johan Bucht , current@freebsd.org Subject: Re: New libc malloc 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: Mon, 12 Dec 2005 07:17:59 -0000 Kris Kennaway wrote: > On Mon, Dec 12, 2005 at 01:56:09PM +0800, David Xu wrote: > >>Johan Bucht wrote: >> >>>Those times seems way too high even for a serial allocator, is >>>libpthread performance really this bad on amd64 or is it broken? >>> >> >>Not sure which thread library has been tested. > > > The quoted text referred to libpthread, the default on amd64. > > Kris May try libthr too ? :-) From owner-freebsd-current@FreeBSD.ORG Mon Dec 12 07:25:56 2005 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 0064816A420; Mon, 12 Dec 2005 07:25:55 +0000 (GMT) (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 8FEDB43D49; Mon, 12 Dec 2005 07:25:55 +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 2AD741A3C1D; Sun, 11 Dec 2005 23:25:55 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 7AD6B53212; Mon, 12 Dec 2005 02:25:54 -0500 (EST) Date: Mon, 12 Dec 2005 02:25:54 -0500 From: Kris Kennaway To: David Xu Message-ID: <20051212072554.GB19639@xor.obsecurity.org> References: <12CA5E15-D006-441D-A24C-1BCD1A69D740@canonware.com> <439CC5DA.3080103@elischer.org> <439CC939.5080703@freebsd.org> <20051212012907.GA13640@xor.obsecurity.org> <20051212043023.GA16678@xor.obsecurity.org> <439D04CF.1000204@acc.umu.se> <439D10F9.6060004@freebsd.org> <20051212055804.GA18100@xor.obsecurity.org> <439D2429.7040808@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="s/l3CgOIzMHHjg/5" Content-Disposition: inline In-Reply-To: <439D2429.7040808@freebsd.org> User-Agent: Mutt/1.4.2.1i Cc: Johan Bucht , current@freebsd.org, Kris Kennaway Subject: Re: New libc malloc 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: Mon, 12 Dec 2005 07:25:56 -0000 --s/l3CgOIzMHHjg/5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 12, 2005 at 03:18:01PM +0800, David Xu wrote: > Kris Kennaway wrote: > >On Mon, Dec 12, 2005 at 01:56:09PM +0800, David Xu wrote: > > > >>Johan Bucht wrote: > >> > >>>Those times seems way too high even for a serial allocator, is=20 > >>>libpthread performance really this bad on amd64 or is it broken? > >>> > >> > >>Not sure which thread library has been tested. > > > > > >The quoted text referred to libpthread, the default on amd64. > > > >Kris > May try libthr too ? :-) That was in the other half of the mail, I guess you didn't read it thoroughly :) Kris --s/l3CgOIzMHHjg/5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD4DBQFDnSYCWry0BWjoQKURAvFzAJdsQArdKQld84D6L1a4BjC9sLe3AKCZifgS qxlo48CzouZzSXkRgZy0Pg== =hv6T -----END PGP SIGNATURE----- --s/l3CgOIzMHHjg/5-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 12 07:56:09 2005 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 B295116A41F for ; Mon, 12 Dec 2005 07:56:09 +0000 (GMT) (envelope-from eta@lclark.edu) Received: from leguin.anholt.net (69-30-77-85.dq1sn.easystreet.com [69.30.77.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB97F43D5E for ; Mon, 12 Dec 2005 07:56:08 +0000 (GMT) (envelope-from eta@lclark.edu) Received: from leguin.anholt.net (localhost [127.0.0.1]) by leguin.anholt.net (8.13.4/8.13.1) with ESMTP id jBC7u3DS024706; Sun, 11 Dec 2005 23:56:03 -0800 (PST) (envelope-from eta@lclark.edu) Received: (from anholt@localhost) by leguin.anholt.net (8.13.4/8.13.1/Submit) id jBC7u2qJ024705; Sun, 11 Dec 2005 23:56:02 -0800 (PST) (envelope-from eta@lclark.edu) X-Authentication-Warning: leguin.anholt.net: anholt set sender to eta@lclark.edu using -f From: Eric Anholt To: Peter Jeremy In-Reply-To: <20051212070231.GB74684@cirb503493.alcatel.com.au> References: <0B746373-8C29-4ADF-9218-311AE08F3834@canonware.com> <7318D807-9086-4817-A40B-50D6960880FB@canonware.com> <12CA5E15-D006-441D-A24C-1BCD1A69D740@canonware.com> <20051212070231.GB74684@cirb503493.alcatel.com.au> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-nsBqNMRSUoJa8yaR6IOq" Date: Sun, 11 Dec 2005 23:56:01 -0800 Message-Id: <1134374161.1404.6.camel@leguin> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2 FreeBSD GNOME Team Port Cc: Jason Evans , current@freebsd.org Subject: Re: New libc malloc 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: Mon, 12 Dec 2005 07:56:09 -0000 --=-nsBqNMRSUoJa8yaR6IOq Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2005-12-12 at 18:02 +1100, Peter Jeremy wrote: > On Sun, 2005-Dec-11 16:04:09 -0800, Jason Evans wrote: > >early, during the load of the libbitmap module. My best guess is =20 > >that it is stuck trying to acquire the Xlib lock, but cannot be sure, =20 > >since I don't know how to get debug symbols for the loaded X module. =20 >=20 > I've run into a related problem in the past. Eric Anholt's advice was: > >You could compile all the modules into the server by adding "#define > >DoLoadableServer NO" to your host.conf when you compile XFree86-4-Server > >(see scripts/configure for other defines that are added). >=20 > Something similar probably works in X.org. I found that I had to > remove elo2300 from XInputDrivers to correct a unresolved 'ELO2300'. DoLoadableServer NO may or may not work at any time, and frequently changes bug reproducibility due to the lack of the loader process. If you can reproduce with xorg-server-snap, then WITH_DEBUG=3D1 during compile will get you a server with debug symbols. --=20 Eric Anholt eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org --=-nsBqNMRSUoJa8yaR6IOq Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDnS0RHUdvYGzw6vcRAveoAJ0Yp6kGrY2/t55eKYIojdzqHe9A+wCcDUR3 d0RAeqP/lmg+XuyGErm0kXU= =jRR9 -----END PGP SIGNATURE----- --=-nsBqNMRSUoJa8yaR6IOq-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 12 10:17:44 2005 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 9433316A41F; Mon, 12 Dec 2005 10:17:44 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from itchy.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DBC343D49; Mon, 12 Dec 2005 10:17:43 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from herring.rabson.org (herring.rabson.org [80.177.232.250]) by itchy.rabson.org (8.13.3/8.13.3) with ESMTP id jBCAHB9T053897; Mon, 12 Dec 2005 10:17:11 GMT (envelope-from dfr@nlsystems.com) From: Doug Rabson To: freebsd-current@freebsd.org Date: Mon, 12 Dec 2005 10:17:09 +0000 User-Agent: KMail/1.8.2 References: <20051212014852.GA8775@shaka.acc.umu.se> <9FAD2B4B-C167-42D7-A8E7-BE03F4C07543@canonware.com> <439CEB74.9080505@acc.umu.se> In-Reply-To: <439CEB74.9080505@acc.umu.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512121017.10220.dfr@nlsystems.com> X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on itchy.rabson.org X-Virus-Scanned: ClamAV 0.87.1/1208/Mon Dec 12 08:51:58 2005 on itchy.rabson.org X-Virus-Status: Clean Cc: Johan Bucht , Jason Evans , current@freebsd.org Subject: Re: New libc malloc 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: Mon, 12 Dec 2005 10:17:44 -0000 On Monday 12 December 2005 03:16, Johan Bucht wrote: > Isn't 8 byte alignment expected by some applications? > How do you know if a allocation is huge if you don't have a tag? > Something more to read up on i guess. =) Actually, I'm glad you pointed that out. My own applications use SSE2 primitives a lot and those guys need to be allocated on 16-byte boundaries. I currently use phkmalloc which has the nice property that small allocations are aligned to the next greater power-of-2 boundary which is (for me) always at least 16. Since you are targetting modern architectures with this allocator, could you please set the minimum alignment on all i386 and amd64 processors to 16. For what its worth, when gcc is using SSE instructions, it assumes this for all memory, stack or malloc. From owner-freebsd-current@FreeBSD.ORG Mon Dec 12 10:17:44 2005 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 9433316A41F; Mon, 12 Dec 2005 10:17:44 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from itchy.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DBC343D49; Mon, 12 Dec 2005 10:17:43 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from herring.rabson.org (herring.rabson.org [80.177.232.250]) by itchy.rabson.org (8.13.3/8.13.3) with ESMTP id jBCAHB9T053897; Mon, 12 Dec 2005 10:17:11 GMT (envelope-from dfr@nlsystems.com) From: Doug Rabson To: freebsd-current@freebsd.org Date: Mon, 12 Dec 2005 10:17:09 +0000 User-Agent: KMail/1.8.2 References: <20051212014852.GA8775@shaka.acc.umu.se> <9FAD2B4B-C167-42D7-A8E7-BE03F4C07543@canonware.com> <439CEB74.9080505@acc.umu.se> In-Reply-To: <439CEB74.9080505@acc.umu.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512121017.10220.dfr@nlsystems.com> X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on itchy.rabson.org X-Virus-Scanned: ClamAV 0.87.1/1208/Mon Dec 12 08:51:58 2005 on itchy.rabson.org X-Virus-Status: Clean Cc: Johan Bucht , Jason Evans , current@freebsd.org Subject: Re: New libc malloc 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: Mon, 12 Dec 2005 10:17:44 -0000 On Monday 12 December 2005 03:16, Johan Bucht wrote: > Isn't 8 byte alignment expected by some applications? > How do you know if a allocation is huge if you don't have a tag? > Something more to read up on i guess. =) Actually, I'm glad you pointed that out. My own applications use SSE2 primitives a lot and those guys need to be allocated on 16-byte boundaries. I currently use phkmalloc which has the nice property that small allocations are aligned to the next greater power-of-2 boundary which is (for me) always at least 16. Since you are targetting modern architectures with this allocator, could you please set the minimum alignment on all i386 and amd64 processors to 16. For what its worth, when gcc is using SSE instructions, it assumes this for all memory, stack or malloc. From owner-freebsd-current@FreeBSD.ORG Mon Dec 12 10:47:38 2005 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 69F6F16A41F for ; Mon, 12 Dec 2005 10:47:38 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id B864843D5A for ; Mon, 12 Dec 2005 10:47:37 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id jBCAlZ0L026013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Dec 2005 13:47:35 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id jBCAlYG7026012; Mon, 12 Dec 2005 13:47:34 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 12 Dec 2005 13:47:34 +0300 From: Gleb Smirnoff To: Tim Price Message-ID: <20051212104734.GG37414@FreeBSD.org> References: <20051211214645.06ACB43D62@mx1.FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20051211214645.06ACB43D62@mx1.FreeBSD.org> User-Agent: Mutt/1.5.6i Cc: current@FreeBSD.org Subject: Re: 802.1QinQ Support 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, 12 Dec 2005 10:47:38 -0000 On Mon, Dec 12, 2005 at 10:42:31AM +1300, Tim Price wrote: T> Is there any support, either inbuilt or third party, that anyone knows of T> for 802.1QinQ, VLAN Stacking, Inner VLAN (it's called a lot of things by a T> lot of companies)? T> T> The reason I ask is that we provide layer 2 transit over our wireless T> network using a freebsd 5.4 / 6 appliance. Recently we have been approached T> by a group that wants to use VLANS for QOS using their own routers but T> unless we encapsulate their traffic in our own VLANs we will eventually run T> into an issue with VLAN conflicts between this group and another potential T> VLAN user. Any input that the FreeBSD community has to offer on this issue, T> or other solutions that we may not have thought about would be greatly T> appreciated. You can nest us much 802.1q VLANs as you want using ng_vlan(4). -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Mon Dec 12 12:20:03 2005 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 9ED3616A423 for ; Mon, 12 Dec 2005 12:20:03 +0000 (GMT) (envelope-from jsmith@drexel.edu) Received: from smtp.mail.drexel.edu (pm2.irt.drexel.edu [144.118.29.82]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE69143D49 for ; Mon, 12 Dec 2005 12:20:02 +0000 (GMT) (envelope-from jsmith@drexel.edu) Received: from smtp.mail.drexel.edu (localhost.localdomain [127.0.0.1]) by smtp.mail.drexel.edu (Postfix) with SMTP id 78781116635; Mon, 12 Dec 2005 07:20:01 -0500 (EST) Received: from vorpal.math.drexel.edu (vorpal.math.drexel.edu [129.25.6.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mail.drexel.edu (Postfix) with ESMTP id 646D21165EA; Mon, 12 Dec 2005 07:20:01 -0500 (EST) Received: from [IPv6:::1] (vorpal.math.drexel.edu [129.25.6.250]) by vorpal.math.drexel.edu (8.13.4/8.13.4) with ESMTP id jBCCJtYF017489; Mon, 12 Dec 2005 07:20:00 -0500 (EST) (envelope-from jsmith@drexel.edu) Message-ID: <439D6AEB.4060105@drexel.edu> Date: Mon, 12 Dec 2005 07:19:55 -0500 From: Justin Smith User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051204) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Daniel O'Connor" References: <439B1092.4080400@drexel.edu> <200512111151.45208.doconnor@gsoft.com.au> In-Reply-To: <200512111151.45208.doconnor@gsoft.com.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: No xpt devices 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, 12 Dec 2005 12:20:03 -0000 After PLAYING music using the gnome cd player, the xpt device came into existence. But this didn't happen until I actually accessed the device (whereas the pass0 and cd0 devices did exist before accessing the device). As a result, some other programs (the gnome audio cd creator) said they could find no CD drives on my system. From owner-freebsd-current@FreeBSD.ORG Mon Dec 12 11:39:27 2005 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 DE08B16A41F for ; Mon, 12 Dec 2005 11:39:27 +0000 (GMT) (envelope-from tomas@hodan.sk) Received: from acs.sk (acs.sk [62.176.161.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id D054243D7F for ; Mon, 12 Dec 2005 11:39:23 +0000 (GMT) (envelope-from tomas@hodan.sk) Received: from mtl12349390 ([62.176.165.10]) (authenticated bits=0) by acs.sk (8.12.9/8.12.9) with ESMTP id jBCBcs7L047768; Mon, 12 Dec 2005 12:38:58 +0100 (CET) (envelope-from tomas@hodan.sk) Message-Id: <200512121138.jBCBcs7L047768@acs.sk> From: "Tomas Hodan" To: "'Sam Leffler'" Date: Mon, 12 Dec 2005 12:38:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcX+njGUojveLRNLTfitq+BKfO1uCgAcmqHg In-Reply-To: <439CA10A.5010204@errno.com> X-Mailman-Approved-At: Mon, 12 Dec 2005 12:46:22 +0000 Cc: freebsd-current@freebsd.org Subject: RE: new ath_hal 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, 12 Dec 2005 11:39:28 -0000 it works. thanks, tomas > -----Original Message----- > From: Sam Leffler [mailto:sam@errno.com] > Sent: Sunday, December 11, 2005 10:59 PM > To: Tomas Hodan > Cc: freebsd-current@freebsd.org > Subject: Re: new ath_hal > > Tomas Hodan wrote: > > hi Sam, > > > > I successfully compiled your kernel under RELENG_7 with > your patches > > and new ath_hal, just it's not possible to compile athstats anymore. > > > > MiniBSD /usr/src/tools/tools/ath # make cc -o athstats athstats.c > > athstats.c: In function `printstats': > > athstats.c:128: error: structure has no member named > `ast_tx_ctsburst' > > athstats.c:128: error: structure has no member named > `ast_tx_ctsburst' > > athstats.c:129: error: structure has no member named `ast_tx_ctsext' > > athstats.c:129: error: structure has no member named `ast_tx_ctsext' > > *** Error code 1 > > > > Stop in /usr/src/tools/tools/ath. > > > > could you have a look? > > delete lines 128+129 > > From owner-freebsd-current@FreeBSD.ORG Mon Dec 12 12:48:02 2005 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 C011E16A41F for ; Mon, 12 Dec 2005 12:48:02 +0000 (GMT) (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 1D65043D58 for ; Mon, 12 Dec 2005 12:48:01 +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 jBCClv34010748; Mon, 12 Dec 2005 07:47:57 -0500 (EST) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost) by lexi.siliconlandmark.com (8.13.3/8.13.3/Submit) with ESMTP id jBCClvYM010745; Mon, 12 Dec 2005 07:47:57 -0500 (EST) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Mon, 12 Dec 2005 07:47:57 -0500 (EST) From: Andre Guibert de Bruet To: Sten Spans In-Reply-To: Message-ID: <20051212073852.F17429@lexi.siliconlandmark.com> References: <20051211105118.X17429@lexi.siliconlandmark.com> <20051211161558.Q17429@lexi.siliconlandmark.com> 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.531, required 6, autolearn=not spam, AWL 0.07, BAYES_00 -2.60) X-MailScanner-From: andy@siliconlandmark.com Cc: current@freebsd.org Subject: Re: The /etc/ntp/ directory. 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, 12 Dec 2005 12:48:02 -0000 On Sun, 11 Dec 2005, Sten Spans wrote: > On Sun, 11 Dec 2005, Andre Guibert de Bruet wrote: >> >> So if ntpd is running as root because clock_settime(2) and friends require >> the effective user ID of the super-user, what is the functional purpose of >> this directory? > > None :) So, I guess it is safe to ask for its removal. 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 Mon Dec 12 14:08:02 2005 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 94F5916A420 for ; Mon, 12 Dec 2005 14:08:02 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2625C43D55 for ; Mon, 12 Dec 2005 14:07:45 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id jBCE7aHW051389; Mon, 12 Dec 2005 16:07:36 +0200 (EET) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 06946-01; Mon, 12 Dec 2005 16:07:33 +0200 (EET) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id jBCE2gnE051284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Dec 2005 16:02:42 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.4/8.13.4) id jBCE2mHm080336; Mon, 12 Dec 2005 16:02:48 +0200 (EET) (envelope-from ru) Date: Mon, 12 Dec 2005 16:02:48 +0200 From: Ruslan Ermilov To: Andre Guibert de Bruet Message-ID: <20051212140248.GA80275@ip.net.ua> References: <20051211105118.X17429@lexi.siliconlandmark.com> <20051211161558.Q17429@lexi.siliconlandmark.com> <20051212073852.F17429@lexi.siliconlandmark.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline In-Reply-To: <20051212073852.F17429@lexi.siliconlandmark.com> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua Cc: current@FreeBSD.org Subject: Re: The /etc/ntp/ directory. 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, 12 Dec 2005 14:08:02 -0000 --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 12, 2005 at 07:47:57AM -0500, Andre Guibert de Bruet wrote: >=20 > On Sun, 11 Dec 2005, Sten Spans wrote: > >On Sun, 11 Dec 2005, Andre Guibert de Bruet wrote: > >> > >>So if ntpd is running as root because clock_settime(2) and friends=20 > >>require the effective user ID of the super-user, what is the functional= =20 > >>purpose of this directory? > > > >None :) >=20 > So, I guess it is safe to ask for its removal. >=20 RCS file: /home/ncvs/src/etc/mtree/BSD.root.dist,v ---------------------------- revision 1.67 date: 2004/07/21 10:14:10; author: roberto; state: Exp; lines: +2 -0 Add /etc/ntp to hold keys for ntpd. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --AqsLC8rIMeq19msA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDnYMIqRfpzJluFF4RAq2oAJ9mqL5+vApEihBBSA85n7QyNYQH/ACcDeRs Wb4oBSysxKzsC7ItuoEf/P4= =uBzo -----END PGP SIGNATURE----- --AqsLC8rIMeq19msA-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 12 15:40:42 2005 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 476B616A41F for ; Mon, 12 Dec 2005 15:40:42 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 31E9143D5D for ; Mon, 12 Dec 2005 15:40:40 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.5/8.13.5/NETPLEX) with ESMTP id jBCFeUKp004243; Mon, 12 Dec 2005 10:40:30 -0500 (EST) Date: Mon, 12 Dec 2005 10:40:22 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Jason Evans In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: Johan Bucht , current@freebsd.org Subject: Re: New libc malloc patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2005 15:40:42 -0000 On Sun, 11 Dec 2005, Jason Evans wrote: > On Dec 11, 2005, at 9:58 PM, Daniel Eischen wrote: > > On Sun, 11 Dec 2005, Jason Evans wrote: > >> I have been contemplating creating a separate spinlock API that > >> doesn't require the threads library to track the spinlocks across > >> fork. This would (if I understand correctly) remove the current > >> static spinlock limitations. > > > > What about using pthread_atfork()? > > Aren't there potential ordering issues for that? It seems to me that > the malloc pre-fork code would need to be run after any other pre- > fork functions, in order to avoid potential deadlock, and that the > malloc post-fork code would need to be run before any other post-fork > functions, again to avoid potential deadlock. > > After looking at the spinlock code some more, it's no longer clear to > me why the thread/thr_spinlock.c code uses a static array for > spinlocks. It seems to me that it would work fine to allow the > program to provide space for a spinlock and manually initialize it. > This would remove the limitation on the number of spinlocks. We really want to deprecate the use of spinlocks in libc, so it is just a band-aid until we change our mutex types to be full structs instead of pointers to them that have to get allocated. When that happens, the malloc implementation should be changed to use mutexes since they will not have to be allocated, and, for the uncontested case, be just an instruction or two (very much like umtx, possibly the same). When the imminent symbol versioning hits the tree, it will be much easier to make the mutex change since it will not affect everything in the world that uses mutexes, CVs, etc. We just need to decide on a layout for them so all 3 thread libraries agree, at least on size and on what FOO_INITIALIZERs do. > >> As for supporting recursive spinlocks, I doubt that the overhead > >> would be acceptable in general. If I could get rid of the need for > >> the one recursive lock in malloc.c, I certainly would. =) > > > > Why do we need a recursive mutex? Can you not restructure the > > code so that it is not needed? > > There is an internal arena that the malloc code uses for allocating > internal data structures. In some cases, the internal arena has to > recursively allocate. If there were no object caching, it might be > possible to pre-allocate, such that recursion never happens, but > given the object caching, it's difficult to reason about precisely > what will occur internally for a single malloc/free operation. There > are some other possibilities, but nothing I've thought of so far is > simple or elegant. Well, just lock around the external functions and remove all locking from the internal and recursive functions. Can't all recursion be replaced with loops anyways ;-) > Fixing this would make all locking in the malloc code a bit cheaper, > which is why it continues to bother me. -- DE From owner-freebsd-current@FreeBSD.ORG Mon Dec 12 16:19:50 2005 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 2C92816A420; Mon, 12 Dec 2005 16:19:50 +0000 (GMT) (envelope-from bucht@acc.umu.se) Received: from mail.acc.umu.se (mail.acc.umu.se [130.239.18.156]) by mx1.FreeBSD.org (Postfix) with ESMTP id B302B43D80; Mon, 12 Dec 2005 16:19:27 +0000 (GMT) (envelope-from bucht@acc.umu.se) Received: from localhost (localhost [127.0.0.1]) by amavisd-new (Postfix) with ESMTP id 958ED498E; Mon, 12 Dec 2005 17:19:23 +0100 (MET) Received: from [192.168.1.100] (53dbce07.umea.cust.skycom.se [83.219.206.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.acc.umu.se (Postfix) with ESMTP id C364D48C8; Mon, 12 Dec 2005 17:19:20 +0100 (MET) Message-ID: <439DA34D.7040407@acc.umu.se> Date: Mon, 12 Dec 2005 17:20:29 +0100 From: Johan Bucht User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Eischen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at acc.umu.se Cc: current@freebsd.org Subject: Re: New libc malloc 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: Mon, 12 Dec 2005 16:19:50 -0000 Daniel Eischen wrote: >On Sun, 11 Dec 2005, Jason Evans wrote: > > >>>>As for supporting recursive spinlocks, I doubt that the overhead >>>>would be acceptable in general. If I could get rid of the need for >>>>the one recursive lock in malloc.c, I certainly would. =) >>>> >>>> >>>Why do we need a recursive mutex? Can you not restructure the >>>code so that it is not needed? >>> >>> >>There is an internal arena that the malloc code uses for allocating >>internal data structures. In some cases, the internal arena has to >>recursively allocate. If there were no object caching, it might be >>possible to pre-allocate, such that recursion never happens, but >>given the object caching, it's difficult to reason about precisely >>what will occur internally for a single malloc/free operation. There >>are some other possibilities, but nothing I've thought of so far is >>simple or elegant. >> >> > >Well, just lock around the external functions and remove all locking >from the internal and recursive functions. Can't all recursion >be replaced with loops anyways ;-) > > > Simple description of the issues following. First ideal case, no recursive locking needed: 1. Lock the local arena to allocate memory 2. If we need to allocate internal data structures lock the base arena 2.1. Allocate memory from the base arena 2.2. Unlock base arena 3. Unlock local arena The ideal case assumes that the base arena have everything it needs and don't have to set up internal data structures to handle the allocations. Actual case: 0. From malloc(3) friends get a local arena and pass that into the internal functions 1. Lock the supplied arena 2. If we need to allocate internal data structure goto step 1, using the base arena instead of one of the local arenas 2.1 Allocate memory from base arena 2.2 Unlock base arena 3. Unlock arena This means that we can lock the base arena recursivly, should the allocation of memory from the base arena need to allocate memory. Solving this would need some special handling for the base arena (avoid using the same interface as the other arenas or statically allocate the base arena). /Johan Bucht From owner-freebsd-current@FreeBSD.ORG Mon Dec 12 19:38:25 2005 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 81CC516A422 for ; Mon, 12 Dec 2005 19:38:25 +0000 (GMT) (envelope-from atomu@pacbell.net) Received: from ylpvm29.prodigy.net (ylpvm29-ext.prodigy.net [207.115.57.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 95A0D43D9F for ; Mon, 12 Dec 2005 19:38:14 +0000 (GMT) (envelope-from atomu@pacbell.net) Received: from pimout5-ext.prodigy.net (pimout5-int.prodigy.net [207.115.4.21]) by ylpvm29.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id jBCJcKri024687 for ; Mon, 12 Dec 2005 14:38:21 -0500 X-ORBL: [64.174.244.75] DomainKey-Signature: a=rsa-sha1; s=sbc01; d=pacbell.net; c=nofws; q=dns; h=message-id:x-sender:x-mailer:date:to:from:subject: mime-version:content-type; b=am7F65YGf+qs1sj0cOltmbZODQDDiqYoeG1V5VwO5VmvS5yzOybp7u5HVr4dH/SBF cyfRBowDF3l59M8ul2mow== Received: from nushitsu1.pacbell.net (adsl-64-174-244-75.dsl.sntc01.pacbell.net [64.174.244.75]) by pimout5-ext.prodigy.net (8.13.4 outbound domainkey aix/8.13.4) with ESMTP id jBCJcAqM131144 for ; Mon, 12 Dec 2005 14:38:12 -0500 Message-Id: <5.1.0.14.2.20051212113827.0398f4d0@66.120.28.15> X-Sender: culprit@66.120.28.15 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 12 Dec 2005 11:39:15 -0800 To: freebsd-current@freebsd.org From: Max Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Marvell 88E8111 Gigabit 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, 12 Dec 2005 19:38:26 -0000 Any plans for this driver to be added to sk? From owner-freebsd-current@FreeBSD.ORG Mon Dec 12 20:28:33 2005 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 7745516A41F; Mon, 12 Dec 2005 20:28:33 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D55743D73; Mon, 12 Dec 2005 20:28:27 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.4/8.13.4) with ESMTP id jBCKSQZS030184; Mon, 12 Dec 2005 12:28:26 -0800 (PST) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id jBCKSP0n030183; Mon, 12 Dec 2005 12:28:25 -0800 (PST) (envelope-from obrien) Date: Mon, 12 Dec 2005 12:28:25 -0800 From: "David O'Brien" To: David Xu Message-ID: <20051212202825.GA30110@dragon.NUXI.org> Mail-Followup-To: freebsd-current@freebsd.org, David Xu , "Bjoern A. Zeeb" , FreeBSD current mailing list References: <20051209175607.C23668@maildrop.int.zabbadoz.net> <439A049E.9020907@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <439A049E.9020907@freebsd.org> X-Operating-System: FreeBSD 7.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.11 Cc: "Bjoern A. Zeeb" , FreeBSD current mailing list Subject: Re: nve(4) patch - please test! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2005 20:28:33 -0000 On Sat, Dec 10, 2005 at 06:26:38AM +0800, David Xu wrote: > >[1] http://sources.zabbadoz.net/freebsd/patchset/nve-20051209-01.diff > > It saves the nve on my EPOX 9nda3j board! > it is a NForce3 250 GB, it is working now, oh, you are my hero! The update to v1.0-0310 (w/o the above patch) didn't help your issues? -- -- David (obrien@FreeBSD.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? From owner-freebsd-current@FreeBSD.ORG Mon Dec 12 21:32:27 2005 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 2660F16A41F; Mon, 12 Dec 2005 21:32:27 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D56F43D5A; Mon, 12 Dec 2005 21:32:26 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.4/8.13.4) with ESMTP id jBCLWNDp020116; Mon, 12 Dec 2005 16:32:23 -0500 (EST) (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.3/8.13.3) with ESMTP id jBCLWNnd004082; Mon, 12 Dec 2005 16:32:23 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D0C3F7302F; Mon, 12 Dec 2005 16:32:22 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051212213222.D0C3F7302F@freebsd-current.sentex.ca> Date: Mon, 12 Dec 2005 16:32:22 -0500 (EST) X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on clamscanner4 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on alpha/alpha 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: Mon, 12 Dec 2005 21:32:27 -0000 TB --- 2005-12-12 20:15:53 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-12-12 20:15:53 - starting HEAD tinderbox run for alpha/alpha TB --- 2005-12-12 20:15:53 - cleaning the object tree TB --- 2005-12-12 20:16:19 - checking out the source tree TB --- 2005-12-12 20:16:19 - cd /tinderbox/HEAD/alpha/alpha TB --- 2005-12-12 20:16:19 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-12-12 20:22:26 - building world (CFLAGS=-O2 -pipe) TB --- 2005-12-12 20:22:26 - cd /src TB --- 2005-12-12 20:22:26 - /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 --- 2005-12-12 21:27:40 - generating LINT kernel config TB --- 2005-12-12 21:27:40 - cd /src/sys/alpha/conf TB --- 2005-12-12 21:27:40 - /usr/bin/make -B LINT TB --- 2005-12-12 21:27:41 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-12-12 21:27:41 - cd /src TB --- 2005-12-12 21:27:41 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Dec 12 21:27:41 UTC 2005 >>> 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 -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/dev/ata/atapi-fd.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/dev/ata/atapi-tape.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/dev/awi/am79c930.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/dev/awi/awi.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/dev/awi/if_awi_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/dev/bge/if_bge.c /src/sys/dev/bge/if_bge.c: In function `bge_intr': /src/sys/dev/bge/if_bge.c:3710: warning: 'status' might be used uninitialized in this function *** Error code 1 Stop in /obj/alpha/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-12-12 21:32:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-12-12 21:32:22 - ERROR: failed to build lint kernel TB --- 2005-12-12 21:32:22 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Mon Dec 12 23:07:46 2005 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 2BF3B16A41F for ; Mon, 12 Dec 2005 23:07:46 +0000 (GMT) (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 E48FB43D5C for ; Mon, 12 Dec 2005 23:07:40 +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 274241FFDBC; Tue, 13 Dec 2005 00:07:38 +0100 (CET) Received: by transport.cksoft.de (Postfix, from userid 66) id 8B60E1FFDD8; Tue, 13 Dec 2005 00:07:35 +0100 (CET) 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 3A09A444F50; Mon, 12 Dec 2005 23:04:07 +0000 (UTC) Date: Mon, 12 Dec 2005 23:04:07 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Max In-Reply-To: <5.1.0.14.2.20051212113827.0398f4d0@66.120.28.15> Message-ID: <20051212230232.M23668@maildrop.int.zabbadoz.net> References: <5.1.0.14.2.20051212113827.0398f4d0@66.120.28.15> 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@freebsd.org Subject: Re: Marvell 88E8111 Gigabit 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, 12 Dec 2005 23:07:46 -0000 On Mon, 12 Dec 2005, Max wrote: > Any plans for this driver to be added to sk? IMHO this is a PHY. You most likely have a Marvell 88E8053 PCIe? -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-current@FreeBSD.ORG Mon Dec 12 23:12:53 2005 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 3B97016A41F; Mon, 12 Dec 2005 23:12:53 +0000 (GMT) (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 9086C43D79; Mon, 12 Dec 2005 23:12:17 +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.4/8.13.4) with ESMTP id jBCNCCjv034903; Mon, 12 Dec 2005 18:12:13 -0500 (EST) (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.3/8.13.3) with ESMTP id jBCNCCvp064379; Mon, 12 Dec 2005 18:12:12 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 989087302F; Mon, 12 Dec 2005 18:12:12 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051212231212.989087302F@freebsd-current.sentex.ca> Date: Mon, 12 Dec 2005 18:12:12 -0500 (EST) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on amd64/amd64 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: Mon, 12 Dec 2005 23:12:53 -0000 TB --- 2005-12-12 21:32:22 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-12-12 21:32:22 - starting HEAD tinderbox run for amd64/amd64 TB --- 2005-12-12 21:32:22 - cleaning the object tree TB --- 2005-12-12 21:33:02 - checking out the source tree TB --- 2005-12-12 21:33:02 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2005-12-12 21:33:02 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-12-12 21:39:02 - building world (CFLAGS=-O2 -pipe) TB --- 2005-12-12 21:39:02 - cd /src TB --- 2005-12-12 21:39:02 - /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 >>> stage 5.1: building 32 bit shim libraries TB --- 2005-12-12 23:10:15 - generating LINT kernel config TB --- 2005-12-12 23:10:15 - cd /src/sys/amd64/conf TB --- 2005-12-12 23:10:15 - /usr/bin/make -B LINT TB --- 2005-12-12 23:10:15 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-12-12 23:10:15 - cd /src TB --- 2005-12-12 23:10:15 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Dec 12 23:10:15 UTC 2005 >>> 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 [...] /src/sys/gnu/fs/xfs/FreeBSD/xfs_freebsd.h:130:5: #error Wrong BLKDEV_IOSIZE In file included from /src/sys/gnu/fs/xfs/xfs.h:36, from /src/sys/gnu/fs/xfs/xfs_iomap.c:33: /src/sys/gnu/fs/xfs/FreeBSD/xfs_freebsd.h:130:5: #error Wrong BLKDEV_IOSIZE In file included from /src/sys/gnu/fs/xfs/xfs.h:36, from /src/sys/gnu/fs/xfs/xfs_behavior.c:33: /src/sys/gnu/fs/xfs/FreeBSD/xfs_freebsd.h:130:5: #error Wrong BLKDEV_IOSIZE mkdep: compile failed *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-12-12 23:12:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-12-12 23:12:12 - ERROR: failed to build lint kernel TB --- 2005-12-12 23:12:12 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Mon Dec 12 23:59:50 2005 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 D0FCC16A420 for ; Mon, 12 Dec 2005 23:59:49 +0000 (GMT) (envelope-from davidxu@freebsd.org) Message-ID: <439E0F15.5010109@freebsd.org> Date: Tue, 13 Dec 2005 08:00:21 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.10) Gecko/20050806 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20051209175607.C23668@maildrop.int.zabbadoz.net> <439A049E.9020907@freebsd.org> <20051212202825.GA30110@dragon.NUXI.org> In-Reply-To: <20051212202825.GA30110@dragon.NUXI.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: nve(4) patch - please test! 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, 12 Dec 2005 23:59:50 -0000 David O'Brien wrote: >On Sat, Dec 10, 2005 at 06:26:38AM +0800, David Xu wrote: > > >>>[1] http://sources.zabbadoz.net/freebsd/patchset/nve-20051209-01.diff >>> >>> >>It saves the nve on my EPOX 9nda3j board! >>it is a NForce3 250 GB, it is working now, oh, you are my hero! >> >> > >The update to v1.0-0310 (w/o the above patch) didn't help your issues? > > > Yes, didn't help. From owner-freebsd-current@FreeBSD.ORG Tue Dec 13 00:04:13 2005 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 E52AF16A41F for ; Tue, 13 Dec 2005 00:04:13 +0000 (GMT) (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 9E83F43D53 for ; Tue, 13 Dec 2005 00:04:13 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.200] ([10.0.0.200]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id jBD04CXq086949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 12 Dec 2005 16:04:13 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <439E1030.1080304@errno.com> Date: Mon, 12 Dec 2005 16:05:04 -0800 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: ath changes: please test 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, 13 Dec 2005 00:04:14 -0000 There's a new hal and patch for the ath driver available for test: http://people.freebsd.org/~sam/ath_hal-20051212.tgz http://people.freebsd.org/~sam/ath.patch The patch is against current. I just committed a bunch of net80211 changes that are required so be sure your system is up to date before applying the ath patch. The changes include: o updates for the sample rate control algorithm (from madwifi) o use a private taskq thread o improved sta mode beacon miss handling o mcast frames sent at fixed rate (settable with ifconfig) o adhoc mode beacon timer fixups o packet capture now includes tsf and calibrated signal data o dfs wait-for-clear-channel handling (for ap mode) This code has been in test for a while and should be fine to use but I will not commit it until I get feedback. Please send me mail directly. especially if you see regressions from the current code in cvs or from the 0.9.16.3 hal snapshot I've had out for several months. All this stuff will eventually make it to RELENG_6 but not for a bit. Sam From owner-freebsd-current@FreeBSD.ORG Tue Dec 13 00:25:10 2005 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 5DBED16A41F; Tue, 13 Dec 2005 00:25:10 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65D0E43D67; Tue, 13 Dec 2005 00:25:09 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.4/8.13.4) with ESMTP id jBD0P82l042840; Mon, 12 Dec 2005 19:25:08 -0500 (EST) (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.3/8.13.3) with ESMTP id jBD0P8gd046251; Mon, 12 Dec 2005 19:25:08 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 4113C7302F; Mon, 12 Dec 2005 19:25:08 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051213002508.4113C7302F@freebsd-current.sentex.ca> Date: Mon, 12 Dec 2005 19:25:08 -0500 (EST) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner4 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 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: Tue, 13 Dec 2005 00:25:10 -0000 TB --- 2005-12-12 23:12:12 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-12-12 23:12:12 - starting HEAD tinderbox run for i386/i386 TB --- 2005-12-12 23:12:12 - cleaning the object tree TB --- 2005-12-12 23:12:48 - checking out the source tree TB --- 2005-12-12 23:12:48 - cd /tinderbox/HEAD/i386/i386 TB --- 2005-12-12 23:12:48 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-12-12 23:18:41 - building world (CFLAGS=-O2 -pipe) TB --- 2005-12-12 23:18:41 - cd /src TB --- 2005-12-12 23:18:41 - /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 --- 2005-12-13 00:23:03 - generating LINT kernel config TB --- 2005-12-13 00:23:03 - cd /src/sys/i386/conf TB --- 2005-12-13 00:23:03 - /usr/bin/make -B LINT TB --- 2005-12-13 00:23:04 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-12-13 00:23:04 - cd /src TB --- 2005-12-13 00:23:04 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Dec 13 00:23:04 UTC 2005 >>> 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 [...] /src/sys/gnu/fs/xfs/FreeBSD/xfs_freebsd.h:130:5: #error Wrong BLKDEV_IOSIZE In file included from /src/sys/gnu/fs/xfs/xfs.h:36, from /src/sys/gnu/fs/xfs/xfs_iomap.c:33: /src/sys/gnu/fs/xfs/FreeBSD/xfs_freebsd.h:130:5: #error Wrong BLKDEV_IOSIZE In file included from /src/sys/gnu/fs/xfs/xfs.h:36, from /src/sys/gnu/fs/xfs/xfs_behavior.c:33: /src/sys/gnu/fs/xfs/FreeBSD/xfs_freebsd.h:130:5: #error Wrong BLKDEV_IOSIZE mkdep: compile failed *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-12-13 00:25:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-12-13 00:25:08 - ERROR: failed to build lint kernel TB --- 2005-12-13 00:25:08 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Dec 13 00:32:05 2005 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 E606016A41F for ; Tue, 13 Dec 2005 00:32:05 +0000 (GMT) (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 76F2E43D69 for ; Tue, 13 Dec 2005 00:32:05 +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/8.13.4) with ESMTP id jBD0VY82011395; Mon, 12 Dec 2005 16:31:34 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.13.4/8.13.4/Submit) id jBD0VXih011394; Mon, 12 Dec 2005 16:31:33 -0800 (PST) Date: Mon, 12 Dec 2005 16:31:33 -0800 (PST) From: Matthew Dillon Message-Id: <200512130031.jBD0VXih011394@apollo.backplane.com> To: "Bjoern A. Zeeb" References: <20051209175607.C23668@maildrop.int.zabbadoz.net> <20051210125221.M23668@maildrop.int.zabbadoz.net> Cc: FreeBSD current mailing list Subject: Re: nve(4) patch - please test! 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, 13 Dec 2005 00:32:06 -0000 :Index: if_nve.c :=================================================================== :RCS file: /shared/mirror/FreeBSD/r/ncvs/src/sys/dev/nve/if_nve.c,v :retrieving revision 1.19 :diff -u -p -r1.19 if_nve.c :--- if_nve.c 7 Dec 2005 17:38:03 -0000 1.19 :+++ if_nve.c 10 Dec 2005 12:53:06 -0000 :@@ -643,6 +643,10 @@ nve_init_locked(struct nve_softc *sc) : nve_stop(sc); : DEBUGOUT(NVE_DEBUG_INIT, "nve: do pfnInit\n"); : :+ /* Setup multicast filter */ :+ nve_setmulti(sc); :+ nve_ifmedia_upd_locked(ifp); :+ : /* Setup Hardware interface and allocate memory structures */ : error = sc->hwapi->pfnInit(sc->hwapi->pADCX, : 0, /* force speed */ :@@ -661,10 +665,6 @@ nve_init_locked(struct nve_softc *sc) : sc->hwapi->pfnEnableInterrupts(sc->hwapi->pADCX); : sc->hwapi->pfnStart(sc->hwapi->pADCX); : :- /* Setup multicast filter */ :- nve_setmulti(sc); :- nve_ifmedia_upd_locked(ifp); :- This is very odd. I don't understand how making ABI calls prior to calling pfnInit() would help matters. Perhaps the actual problem was that the ABI calls were previously being made after interrupts were enabled and after the device was started. What happens if you move the setmulti and ifmedia calls to after the pfnInit() call but before the pfnEnableInterrupts() and Start calls? -Matt From owner-freebsd-current@FreeBSD.ORG Tue Dec 13 01:37:16 2005 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 AB49D16A41F; Tue, 13 Dec 2005 01:37:16 +0000 (GMT) (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 904D743D5E; Tue, 13 Dec 2005 01:37:15 +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.4/8.13.4) with ESMTP id jBD1bEnI057250; Mon, 12 Dec 2005 20:37:14 -0500 (EST) (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.3/8.13.3) with ESMTP id jBD1bERg025646; Mon, 12 Dec 2005 20:37:14 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 8C5FF7302F; Mon, 12 Dec 2005 20:37:14 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051213013714.8C5FF7302F@freebsd-current.sentex.ca> Date: Mon, 12 Dec 2005 20:37:14 -0500 (EST) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/pc98 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: Tue, 13 Dec 2005 01:37:16 -0000 TB --- 2005-12-13 00:25:08 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-12-13 00:25:08 - starting HEAD tinderbox run for i386/pc98 TB --- 2005-12-13 00:25:08 - cleaning the object tree TB --- 2005-12-13 00:25:38 - checking out the source tree TB --- 2005-12-13 00:25:38 - cd /tinderbox/HEAD/i386/pc98 TB --- 2005-12-13 00:25:38 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-12-13 00:31:24 - building world (CFLAGS=-O2 -pipe) TB --- 2005-12-13 00:31:24 - cd /src TB --- 2005-12-13 00:31:24 - /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 --- 2005-12-13 01:35:26 - generating LINT kernel config TB --- 2005-12-13 01:35:26 - cd /src/sys/pc98/conf TB --- 2005-12-13 01:35:26 - /usr/bin/make -B LINT TB --- 2005-12-13 01:35:26 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-12-13 01:35:26 - cd /src TB --- 2005-12-13 01:35:26 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Dec 13 01:35:26 UTC 2005 >>> 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 [...] /src/sys/gnu/fs/xfs/FreeBSD/xfs_freebsd.h:130:5: #error Wrong BLKDEV_IOSIZE In file included from /src/sys/gnu/fs/xfs/xfs.h:36, from /src/sys/gnu/fs/xfs/xfs_iomap.c:33: /src/sys/gnu/fs/xfs/FreeBSD/xfs_freebsd.h:130:5: #error Wrong BLKDEV_IOSIZE In file included from /src/sys/gnu/fs/xfs/xfs.h:36, from /src/sys/gnu/fs/xfs/xfs_behavior.c:33: /src/sys/gnu/fs/xfs/FreeBSD/xfs_freebsd.h:130:5: #error Wrong BLKDEV_IOSIZE mkdep: compile failed *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-12-13 01:37:14 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-12-13 01:37:14 - ERROR: failed to build lint kernel TB --- 2005-12-13 01:37:14 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Dec 13 03:15:26 2005 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 9E4D216A41F for ; Tue, 13 Dec 2005 03:15:26 +0000 (GMT) (envelope-from rainer.alves@gmail.com) Received: from valimar.ibest.com.br (mx11.ibest.com.br [200.181.68.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BA4743D60 for ; Tue, 13 Dec 2005 03:15:24 +0000 (GMT) (envelope-from rainer.alves@gmail.com) Received: from [127.0.0.1] (centaurus.ibest.com.br [200.181.68.107]) by valimar.ibest.com.br (Postfix) with ESMTP id 36E0417C240; Tue, 13 Dec 2005 01:15:22 -0200 (BRDT) Message-ID: <439E3C9F.3070709@gmail.com> Date: Tue, 13 Dec 2005 01:14:39 -0200 From: Rainer Alves User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051205 Thunderbird/1.0.7 Mnenhy/0.7.3.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Leffler References: <439E1030.1080304@errno.com> In-Reply-To: <439E1030.1080304@errno.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-iBEST-MailScanner-Information: Please contact the ISP for more information X-MailScanner-From: rainer.alves@gmail.com Cc: current@freebsd.org Subject: Re: ath changes: please test 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, 13 Dec 2005 03:15:26 -0000 Sam Leffler wrote: > There's a new hal and patch for the ath driver available for test: > > http://people.freebsd.org/~sam/ath_hal-20051212.tgz > http://people.freebsd.org/~sam/ath.patch > > The patch is against current. I just committed a bunch of net80211 > changes that are required so be sure your system is up to date before > applying the ath patch. > [...] Received the following error while trying to rebuild the kernel with your new ath hal/driver: ===> ath_rate_amrr (all) cc -O2 -fno-strict-aliasing -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -I. -I/usr/src/sys/modules/ath_rate_amrr/../../contrib/dev/ath/freebsd -I/usr/src/sys/modules/ath_rate_amrr/../../contrib/dev/ath -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/RAINER/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 -fno-common -I/usr/obj/usr/src/sys/RAINER -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /usr/src/sys/modules/ath_rate_amrr/../../dev/ath/ath_rate/amrr/amrr.c /usr/src/sys/modules/ath_rate_amrr/../../dev/ath/ath_rate/amrr/amrr.c: In function `ath_rate_update': /usr/src/sys/modules/ath_rate_amrr/../../dev/ath/ath_rate/amrr/amrr.c:253: error: structure has no member named `an_tx_rate3' *** Error code 1 I had to patch if_athvar.h, which fixed things for me: --- if_athvar.h.old Tue Dec 13 00:40:52 2005 +++ if_athvar.h Tue Dec 13 00:41:38 2005 @@ -78,6 +78,7 @@ /* driver-specific node state */ struct ath_node { struct ieee80211_node an_node; /* base class */ + u_int8_t an_tx_rate3; u_int32_t an_avgrssi; /* average rssi over all rx frames */ /* variable-length rate control state follows */ }; Hopefully that's the right fix. The new hal/driver seem to be working fine so far... thanks for your work on this. ath_hal: 0.9.16.13 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413, DFS) ath0: mem 0xc0210000-0xc021ffff irq 11 at device 0.0 on cardbus0 ath0: Ethernet address: 00:05:5d:88:d7:77 ath0: mac 4.2 phy 3.0 5ghz radio 1.7 2ghz radio 2.3 ath0: link state changed to UP -- Rainer Alves From owner-freebsd-current@FreeBSD.ORG Tue Dec 13 04:26:01 2005 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 C559C16A41F for ; Tue, 13 Dec 2005 04:26:01 +0000 (GMT) (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 3C72843D53 for ; Tue, 13 Dec 2005 04:26:01 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.200] ([10.0.0.200]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id jBD4Q0A8088259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Dec 2005 20:26:00 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <439E4D8C.2000600@errno.com> Date: Mon, 12 Dec 2005 20:26:52 -0800 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rainer Alves References: <439E1030.1080304@errno.com> <439E3C9F.3070709@gmail.com> In-Reply-To: <439E3C9F.3070709@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: ath changes: please test 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, 13 Dec 2005 04:26:01 -0000 Rainer Alves wrote: > Sam Leffler wrote: > >> There's a new hal and patch for the ath driver available for test: >> >> http://people.freebsd.org/~sam/ath_hal-20051212.tgz >> http://people.freebsd.org/~sam/ath.patch >> >> The patch is against current. I just committed a bunch of net80211 >> changes that are required so be sure your system is up to date before >> applying the ath patch. >> [...] > > > > Received the following error while trying to rebuild the kernel with > your new ath hal/driver: > > ===> ath_rate_amrr (all) > cc -O2 -fno-strict-aliasing -pipe -Werror -D_KERNEL -DKLD_MODULE > -nostdinc -I- -I. > -I/usr/src/sys/modules/ath_rate_amrr/../../contrib/dev/ath/freebsd > -I/usr/src/sys/modules/ath_rate_amrr/../../contrib/dev/ath > -DHAVE_KERNEL_OPTION_HEADERS -include > /usr/obj/usr/src/sys/RAINER/opt_global.h -I. -I@ -I@/contrib/altq > -finline-limit=8000 -fno-common -I/usr/obj/usr/src/sys/RAINER > -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx > -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall > -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual > -fformat-extensions -std=c99 -c > /usr/src/sys/modules/ath_rate_amrr/../../dev/ath/ath_rate/amrr/amrr.c > /usr/src/sys/modules/ath_rate_amrr/../../dev/ath/ath_rate/amrr/amrr.c: > In function `ath_rate_update': > /usr/src/sys/modules/ath_rate_amrr/../../dev/ath/ath_rate/amrr/amrr.c:253: > error: structure has no member named `an_tx_rate3' > *** Error code 1 > > > I had to patch if_athvar.h, which fixed things for me: > > --- if_athvar.h.old Tue Dec 13 00:40:52 2005 > +++ if_athvar.h Tue Dec 13 00:41:38 2005 > @@ -78,6 +78,7 @@ > /* driver-specific node state */ > struct ath_node { > struct ieee80211_node an_node; /* base class */ > + u_int8_t an_tx_rate3; > u_int32_t an_avgrssi; /* average rssi over all rx > frames */ > /* variable-length rate control state follows */ > }; > > > Hopefully that's the right fix. The new hal/driver seem to be working > fine so far... thanks for your work on this. Actually the right fix is a bit different; I've updated ath.patch with it. > > ath_hal: 0.9.16.13 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, > RF5413, DFS) > ath0: mem 0xc0210000-0xc021ffff irq 11 at device 0.0 on > cardbus0 > ath0: Ethernet address: 00:05:5d:88:d7:77 > ath0: mac 4.2 phy 3.0 5ghz radio 1.7 2ghz radio 2.3 > ath0: link state changed to UP Thanks for the report. Sam From owner-freebsd-current@FreeBSD.ORG Tue Dec 13 11:35:08 2005 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 A007716A41F for ; Tue, 13 Dec 2005 11:35:08 +0000 (GMT) (envelope-from jsn@chantry.devlix.dk) Received: from chantry.devlix.dk (chantry.devlix.dk [195.41.43.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2AA0743D49 for ; Tue, 13 Dec 2005 11:35:08 +0000 (GMT) (envelope-from jsn@chantry.devlix.dk) Received: by chantry.devlix.dk (Postfix, from userid 1001) id D7F485C33; Tue, 13 Dec 2005 12:35:06 +0100 (CET) Date: Tue, 13 Dec 2005 12:35:06 +0100 From: Jimmy Selgen To: freebsd-current@freebsd.org Message-ID: <20051213113506.GA5904@chantry.devlix.dk> References: <20051209175607.C23668@maildrop.int.zabbadoz.net> <439A049E.9020907@freebsd.org> <20051212202825.GA30110@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051212202825.GA30110@dragon.NUXI.org> User-Agent: Mutt/1.4.2.1i Subject: Re: nve(4) patch - please test! 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, 13 Dec 2005 11:35:08 -0000 On Mon, Dec 12, 2005 at 12:28:25PM -0800, David O'Brien wrote: > On Sat, Dec 10, 2005 at 06:26:38AM +0800, David Xu wrote: > > >[1] http://sources.zabbadoz.net/freebsd/patchset/nve-20051209-01.diff > > > > It saves the nve on my EPOX 9nda3j board! > > it is a NForce3 250 GB, it is working now, oh, you are my hero! > > The update to v1.0-0310 (w/o the above patch) didn't help your issues? Sure didn't help with my problems either. It might be due to me taking if_nve and nvelib frmo -CURRENT, and applying them to my RELENG_6 branch, but the device_timeout(1)'s are still there. Board is a Asus K8N4-E Deluxe, with NForce 4 4x chipset. NIC is recognized as : Dec 9 19:47:06 testbox kernel: nve0: port 0xc000-0xc007 mem 0xd3100000-0xd3100fff irq 21 at device 10.0 on pci0 Kernel config is GENERIC with the following lines added: device pf device pflog device pfsync /Jimmy From owner-freebsd-current@FreeBSD.ORG Tue Dec 13 13:39:00 2005 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 3B78816A41F; Tue, 13 Dec 2005 13:39:00 +0000 (GMT) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail-gw0.york.ac.uk (mail-gw0.york.ac.uk [144.32.128.245]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1F6743D45; Tue, 13 Dec 2005 13:38:59 +0000 (GMT) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from buffy.york.ac.uk (buffy-128.york.ac.uk [144.32.128.160]) by mail-gw0.york.ac.uk (8.12.10/8.12.10) with ESMTP id jBDDcuCN025353; Tue, 13 Dec 2005 13:38:56 GMT Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.13.4/8.13.4) with ESMTP id jBDDcuW4020768; Tue, 13 Dec 2005 13:38:56 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) Received: (from ga9@localhost) by buffy.york.ac.uk (8.13.4/8.13.4/Submit) id jBDDcu65020767; Tue, 13 Dec 2005 13:38:56 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin.atkinson@ury.york.ac.uk using -f From: Gavin Atkinson To: Gleb Smirnoff In-Reply-To: <20051212140446.GQ37414@FreeBSD.org> References: <20051211181324.G71610@ury.york.ac.uk> <20051212140446.GQ37414@FreeBSD.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 13 Dec 2005 13:38:55 +0000 Message-Id: <1134481135.15730.76.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin.atkinson@ury.york.ac.uk Cc: freebsd-current@FreeBSD.org, imp@FreeBSD.org Subject: Re: puc fails to attach serial ports 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, 13 Dec 2005 13:39:00 -0000 On Mon, 2005-12-12 at 17:04 +0300, Gleb Smirnoff wrote: > On Sun, Dec 11, 2005 at 06:22:40PM +0000, Gavin Atkinson wrote: > G> I'm trying to use puc(4) under RELENG_6 to attach the two serial ports on > G> a PCI card I have, but it's not working. It also fails under 6.0-RELEASE, > G> I don't have the ability to test earlier versions. > G> > G> The card is developed, but as far as I can see, no attempt is made to > G> attach the sio(4) devices below it. > G> > G> puc0: port 0x18c0-0x18df irq 25 at device 9.0 on > G> pci0 > G> puc0: Reserved 0x20 bytes for rid 0x10 type 4 at 0x18c0 > G> port rid 16 bst 0, start 18c0, end 18df > G> puc0: i 0, type sio, ressz 8, type 1 > G> puc: Using sio2 > G> puc: type 1, bar 10, offset 0 > G> puc0: i 1, type sio, ressz 8, type 1 > G> puc: Using sio3 > G> puc: type 1, bar 10, offset 8 > G> > G> Adding some printfs to the code, it turns out that device_probe_and_attach > G> around line 375 of sys/dev/puc/puc.c is returning 6. > G> > G> I have also added printfs to the probe and attach code of both the pci and > G> puc attachments of sio(4), and have determined that none of them get > G> called. > G> > G> How can I further diagnose why this card is not getting recognised? > > Afaik, you need 'device uart', that will attach to your pucs. No, as far as I can tell, it's sio that should be attaching. I've loaded the uart module anyway and it still fails. With BUS_DEBUG defined, I see the following: devclass_find_internal:761: looking for puc devclass_add_device:1356: (null) in devclass puc devclass_alloc_unit:1289: unit -1 in devclass puc devclass_alloc_unit:1329: now: unit 0 in devclass puc puc0: port 0x18c0-0x18df irq 25 at device 9.0 on pci0 puc0: Reserved 0x20 bytes for rid 0x10 type 4 at 0x18c0 port rid 16 bst 0, start 18c0, end 18df puc0: i 0, type sio, ressz 8, type 1 devclass_find_internal:761: looking for sio puc: Using sio2 device_add_child_ordered:1542: sio at puc with order 0 as unit 2 make_device:1427: sio at puc as unit 2 devclass_find_internal:761: looking for sio devclass_add_device:1356: (null) in devclass sio devclass_alloc_unit:1289: unit 2 in devclass sio devclass_alloc_unit:1329: now: unit 2 in devclass sio puc: type 1, bar 10, offset 0 devclass_find_driver_internal:1019: sio in devclass puc devclass_find_driver_internal:1026: not found puc0: i 1, type sio, ressz 8, type 1 devclass_find_internal:761: looking for sio puc: Using sio3 device_add_child_ordered:1542: sio at puc with order 0 as unit 3 make_device:1427: sio at puc as unit 3 devclass_find_internal:761: looking for sio devclass_add_device:1356: (null) in devclass sio devclass_alloc_unit:1289: unit 3 in devclass sio devclass_alloc_unit:1329: now: unit 3 in devclass sio puc: type 1, bar 10, offset 8 devclass_find_driver_internal:1019: sio in devclass puc devclass_find_driver_internal:1026: not found I'm sure somebody with more newbus knowledge will know exactly what that means... Are we somehow missing a devclass_add_driver(9) call from the puc initialisation? I'm almost at the point now where I can't understand how it could possibly be working for anyone else. Gavin From owner-freebsd-current@FreeBSD.ORG Tue Dec 13 13:51:01 2005 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 431ED16A41F; Tue, 13 Dec 2005 13:51:01 +0000 (GMT) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail-gw1.york.ac.uk (mail-gw1.york.ac.uk [144.32.128.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 972A243D70; Tue, 13 Dec 2005 13:50:32 +0000 (GMT) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from buffy.york.ac.uk (buffy-128.york.ac.uk [144.32.128.160]) by mail-gw1.york.ac.uk (8.12.10/8.12.10) with ESMTP id jBDDoJNW014622; Tue, 13 Dec 2005 13:50:19 GMT Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.13.4/8.13.4) with ESMTP id jBDDoI11020818; Tue, 13 Dec 2005 13:50:18 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) Received: (from ga9@localhost) by buffy.york.ac.uk (8.13.4/8.13.4/Submit) id jBDDoIhK020817; Tue, 13 Dec 2005 13:50:18 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin.atkinson@ury.york.ac.uk using -f From: Gavin Atkinson To: Robert Watson In-Reply-To: <20051104181424.R93043@ury.york.ac.uk> References: <1130943516.51544.34.camel@buffy.york.ac.uk> <20051102152322.GF93549@cicely12.cicely.de> <1130945849.51544.42.camel@buffy.york.ac.uk> <20051102164157.A18382@fledge.watson.org> <20051104181424.R93043@ury.york.ac.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 13 Dec 2005 13:50:17 +0000 Message-Id: <1134481817.15730.79.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin.atkinson@ury.york.ac.uk Cc: freebsd-current@freebsd.org, ticso@cicely.de Subject: Re: Poor NFS server performance in 6.0 with SMP and mpsafenet=1 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, 13 Dec 2005 13:51:01 -0000 On Thu, 2005-11-10 at 11:45 +0000, Gavin Atkinson wrote: > On Wed, 2 Nov 2005, Robert Watson wrote: > > On Wed, 2 Nov 2005, Gavin Atkinson wrote: > >> On Wed, 2005-11-02 at 16:23 +0100, Bernd Walter wrote: > >>> On Wed, Nov 02, 2005 at 02:58:36PM +0000, Gavin Atkinson wrote: > >>>> I'm seeing incredibly poor performance when serving files from an SMP > >>>> FreeBSD 6.0RC1 server to a Solaris 10 client. I've done some > >>>> experimenting and have discovered that either removing SMP from the > >>>> kernel, or setting debug.mpsafenet=0 in loader.conf massively improves > >>>> the speed. Switching preemption off seems to also help. > >>> Which scheduler? > >> > >> BSD. As I say, I'm running 6.0-RC1 with the standard GENERIC kernel, apart > >> from the options I have listed as being changed above. Polling is > >> therefore also not enabled. > > > > This does sound like a scheduling problem. I realize it's time-consuming, > > but would it be possible to have you run each of the above test cases twice > > more (or maybe even once) to confirm that in each case, the result is > > reproduceable? I've recently been looking at a scheduling problem relating > > to PREEMPTION and the netisr for loopback traffic, and is basically a result > > of poorly timed context switching ending up being a worst cast scenario. I > > suspect something similar is likely here. Have you tried varying the number > > of nfsd worker threads on the server to see how that changes matters? > > No problem. Sorry it's taken so long to get back to you, it's been a > hectic week :( Anyway, the trend is consistantly reproducable, although > the results themselves can vary between runs in the SMP/mpsafenet cases by > as much as 20%. Here are the averages of three reruns, which I've also > done for ULE: > > 4BSD ULE > No SMP, mpsafenet=1 78.7 62.7 > No SMP, mpsafenet=0 71.1 76.0 > No SMP, mpsafenet=1, no PREEMPTION 54.7 55.5 > No SMP, mpsafenet=0, no PREEMPTION 73.6 77.6 > SMP, mpsafenet=1 346.5 309.5 > SMP, mpsafenet=0 56.9 88.4 > SMP, mpsafenet=1, no PREEMPTION 320.2 136.6 > SMP, mpsafenet=0, no PREEMPTION 57.0 77.9 > > The above are results for 4 nfsd servers (nfsd -n 4). It turns out that > you were correct in thinking that the number of nfsd processes would make > a difference, here are some timings for the GENERIC+SMP kernel (eg with > PREEMPTION/4BSD, the slowest one above), with varying numbers of > processes: > > 1 2 4 8 12 16 > 52.8 59.2 319.3 356.1 377.3 388.1 > > As before, all tests were done with freshly rebooted server and with a > single "dry run" transfer to warm the vm cache up. The file transferred > each time is 512meg worth of /dev/random output. I'm actually quite > surprised about how much difference reducing the number of threads made. > > Does all of this information help track down the cause of the problem? > I'm happy to time more transfers with different configs if you want to > explore other avenues. Any further thoughts on this? The machines will be going live and into colo within the week, so I'll lose the chance to test anything further on them. Gavin From owner-freebsd-current@FreeBSD.ORG Tue Dec 13 13:58:41 2005 Return-Path: X-Original-To: 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 662A016A41F; Tue, 13 Dec 2005 13:58:37 +0000 (GMT) (envelope-from davidxu@freebsd.org) Message-ID: <439ED3AD.8080107@freebsd.org> Date: Tue, 13 Dec 2005 21:59:09 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.10) Gecko/20050806 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Dillon References: <20051209175607.C23668@maildrop.int.zabbadoz.net> <20051210125221.M23668@maildrop.int.zabbadoz.net> <200512130031.jBD0VXih011394@apollo.backplane.com> In-Reply-To: <200512130031.jBD0VXih011394@apollo.backplane.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , FreeBSD current mailing list Subject: Re: nve(4) patch - please test! 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, 13 Dec 2005 13:58:41 -0000 Matthew Dillon wrote: > This is very odd. I don't understand how making ABI calls prior > to calling pfnInit() would help matters. Perhaps the actual > problem was that the ABI calls were previously being made after > interrupts were enabled and after the device was started. > > What happens if you move the setmulti and ifmedia calls to after > the pfnInit() call but before the pfnEnableInterrupts() and Start calls? > > -Matt > > > I still get timeouts with your suggestion, but it is fewer, and the machine is no longer stalled when the device is being reset. David Xu From owner-freebsd-current@FreeBSD.ORG Tue Dec 13 14:07:00 2005 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 4E5EE16A41F; Tue, 13 Dec 2005 14:07:00 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66FDC43D58; Tue, 13 Dec 2005 14:06:59 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id jBDE6v5W050159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Dec 2005 17:06:57 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id jBDE6vJC050158; Tue, 13 Dec 2005 17:06:57 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 13 Dec 2005 17:06:57 +0300 From: Gleb Smirnoff To: Gavin Atkinson Message-ID: <20051213140657.GG37414@cell.sick.ru> References: <20051211181324.G71610@ury.york.ac.uk> <20051212140446.GQ37414@FreeBSD.org> <1134481135.15730.76.camel@buffy.york.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <1134481135.15730.76.camel@buffy.york.ac.uk> User-Agent: Mutt/1.5.6i Cc: freebsd-current@FreeBSD.org, imp@FreeBSD.org Subject: Re: puc fails to attach serial ports 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, 13 Dec 2005 14:07:00 -0000 G> > Afaik, you need 'device uart', that will attach to your pucs. G> G> No, as far as I can tell, it's sio that should be attaching. I've G> loaded the uart module anyway and it still fails. Well, I'm lame in this area, but I've got the following box: puc0: mem 0xe4021000-0xe4021fff irq 10 at device 10.0 on pci0 uart0: <16750 or compatible> on puc0 uart1: <16750 or compatible> on puc0 uart2: <16750 or compatible> on puc0 uart3: <16750 or compatible> on puc0 uart4: <16750 or compatible> on puc0 uart5: <16750 or compatible> on puc0 uart6: <16750 or compatible> on puc0 uart7: <16750 or compatible> on puc0 -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Tue Dec 13 14:49:40 2005 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 ECCF316A424; Tue, 13 Dec 2005 14:49:39 +0000 (GMT) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail-gw1.york.ac.uk (mail-gw1.york.ac.uk [144.32.128.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id A04FB43D7F; Tue, 13 Dec 2005 14:49:32 +0000 (GMT) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from buffy.york.ac.uk (buffy-128.york.ac.uk [144.32.128.160]) by mail-gw1.york.ac.uk (8.12.10/8.12.10) with ESMTP id jBDEnTNW029237; Tue, 13 Dec 2005 14:49:29 GMT Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.13.4/8.13.4) with ESMTP id jBDEnSJg020995; Tue, 13 Dec 2005 14:49:28 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) Received: (from ga9@localhost) by buffy.york.ac.uk (8.13.4/8.13.4/Submit) id jBDEnSrC020994; Tue, 13 Dec 2005 14:49:28 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin.atkinson@ury.york.ac.uk using -f From: Gavin Atkinson To: Gleb Smirnoff In-Reply-To: <1134481135.15730.76.camel@buffy.york.ac.uk> References: <20051211181324.G71610@ury.york.ac.uk> <20051212140446.GQ37414@FreeBSD.org> <1134481135.15730.76.camel@buffy.york.ac.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 13 Dec 2005 14:49:27 +0000 Message-Id: <1134485368.15730.95.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin.atkinson@ury.york.ac.uk Cc: freebsd-current@freebsd.org, imp@freebsd.org Subject: Re: puc fails to attach serial ports 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, 13 Dec 2005 14:49:40 -0000 On Tue, 2005-12-13 at 13:38 +0000, Gavin Atkinson wrote: > On Mon, 2005-12-12 at 17:04 +0300, Gleb Smirnoff wrote: > > On Sun, Dec 11, 2005 at 06:22:40PM +0000, Gavin Atkinson wrote: > > G> I'm trying to use puc(4) under RELENG_6 to attach the two serial ports on > > G> a PCI card I have, but it's not working. It also fails under 6.0-RELEASE, > > G> I don't have the ability to test earlier versions. > > G> > > G> How can I further diagnose why this card is not getting recognised? > > > > Afaik, you need 'device uart', that will attach to your pucs. > > No, as far as I can tell, it's sio that should be attaching. I've > loaded the uart module anyway and it still fails. > > With BUS_DEBUG defined, I see the following: > > devclass_find_internal:761: looking for puc > devclass_add_device:1356: (null) in devclass puc > devclass_alloc_unit:1289: unit -1 in devclass puc > devclass_alloc_unit:1329: now: unit 0 in devclass puc > puc0: port 0x18c0-0x18df irq 25 at device 9.0 > on pci0 > puc0: Reserved 0x20 bytes for rid 0x10 type 4 at 0x18c0 > port rid 16 bst 0, start 18c0, end 18df > puc0: i 0, type sio, ressz 8, type 1 > devclass_find_internal:761: looking for sio > puc: Using sio2 > device_add_child_ordered:1542: sio at puc with order 0 as unit 2 > make_device:1427: sio at puc as unit 2 > devclass_find_internal:761: looking for sio > devclass_add_device:1356: (null) in devclass sio > devclass_alloc_unit:1289: unit 2 in devclass sio > devclass_alloc_unit:1329: now: unit 2 in devclass sio > puc: type 1, bar 10, offset 0 > devclass_find_driver_internal:1019: sio in devclass puc > devclass_find_driver_internal:1026: not found > puc0: i 1, type sio, ressz 8, type 1 > devclass_find_internal:761: looking for sio > puc: Using sio3 > device_add_child_ordered:1542: sio at puc with order 0 as unit 3 > make_device:1427: sio at puc as unit 3 > devclass_find_internal:761: looking for sio > devclass_add_device:1356: (null) in devclass sio > devclass_alloc_unit:1289: unit 3 in devclass sio > devclass_alloc_unit:1329: now: unit 3 in devclass sio > puc: type 1, bar 10, offset 8 > devclass_find_driver_internal:1019: sio in devclass puc > devclass_find_driver_internal:1026: not found > > I'm sure somebody with more newbus knowledge will know exactly what that > means... Are we somehow missing a devclass_add_driver(9) call from the > puc initialisation? I'm almost at the point now where I can't > understand how it could possibly be working for anyone else. OK, I've cracked what's happening. Indeed we are somehow missing a call to devclass_add_driver(9). I was loading puc as a module, and in that case the following relevant calls to devclass_add_driver are made: devclass_add_driver: adding puc to cardbus devclass_add_driver: adding puc to pci devclass_add_driver: adding puc to pccard devclass_add_driver: adding uart to puc devclass_add_driver: adding sio to pccard devclass_add_driver: adding sio to pci devclass_add_driver: adding sio to cardbus devclass_add_driver: adding sio to isa devclass_add_driver: adding sio to acpi When compiling puc into the kernel as opposed to using the module, the following extra call is made: devclass_add_driver: adding sio to puc I don't understand why the DRIVER_METHOD(sio, puc, ...) is being ignored in the puc-as-a-module case. Is this expected behaviour? I'm guessing it's not. I do note also that ppc(4) is not added to the puc devclass, presumably for the same reason. I'm also guessing things would work if sio was a module too. It seems odd to me that a module cannot add an in-kernel driver to it's devclass, but at this point I'm out of my depth as far as figuring out how to fix it goes. Gavin Gavin From owner-freebsd-current@FreeBSD.ORG Tue Dec 13 15:19:07 2005 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 C29E716A41F; Tue, 13 Dec 2005 15:19:07 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from rwcrmhc12.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A0E143D62; Tue, 13 Dec 2005 15:19:06 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from c-24-63-58-245.hsd1.ma.comcast.net ([24.63.58.245]) by comcast.net (rwcrmhc13) with ESMTP id <20051213151905015004r42re>; Tue, 13 Dec 2005 15:19:05 +0000 Received: from c-24-63-58-245.hsd1.ma.comcast.net (localhost [127.0.0.1]) by c-24-63-58-245.hsd1.ma.comcast.net (8.13.4/8.13.1) with ESMTP id jBDFJ9qJ026852; Tue, 13 Dec 2005 10:19:09 -0500 (EST) (envelope-from rodrigc@c-24-63-58-245.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-24-63-58-245.hsd1.ma.comcast.net (8.13.4/8.13.1/Submit) id jBDFJ8cr026851; Tue, 13 Dec 2005 10:19:08 -0500 (EST) (envelope-from rodrigc) Date: Tue, 13 Dec 2005 10:19:08 -0500 From: Craig Rodrigues To: freebsd-current@freebsd.org Message-ID: <20051213151908.GA26821@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: freebsd-fs@freebsd.org Subject: XFS (read-only) support committed to CURRENT 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, 13 Dec 2005 15:19:07 -0000 Hi, Read-only XFS support has been committed to FreeBSD-CURRENT. Write access to XFS is not supported at this time. The XFS for FreeBSD source code is based off of GPL'd sources provided by SGI. You can compile it into your kernel by adding "XFS" to your kernel config file, or you can "kldload xfs". If you have an XFS partition on your system, you can try mounting it with: mount -t xfs [device] [mntpoint] Additional utilities such as mkfs.xfs are available in the sysutils/xfsprogs port. Many thanks to Alexander Kabaev and Russell Cattelan for starting and doing most of the work on the XFS for FreeBSD port, and also to SGI for making the XFS source code freely available. -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-current@FreeBSD.ORG Tue Dec 13 15:58:49 2005 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 DD4D416A41F for ; Tue, 13 Dec 2005 15:58:49 +0000 (GMT) (envelope-from db@nipsi.de) Received: from mr01.hansenet.de (mr01.hansenet.de [213.191.74.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB9A443D5E for ; Tue, 13 Dec 2005 15:58:45 +0000 (GMT) (envelope-from db@nipsi.de) Received: from depression.metaspinner.local (213.39.242.178) by mr01.hansenet.de (7.2.060.1) id 439E56D200004763; Tue, 13 Dec 2005 16:57:57 +0100 Received: from depression.metaspinner.local (localhost [127.0.0.1]) by depression.metaspinner.local (Postfix) with ESMTP id 203757BC23; Tue, 13 Dec 2005 16:57:57 +0100 (CET) Received: from [192.168.1.162] (unknown [192.168.1.162]) by depression.metaspinner.local (Postfix) with ESMTP id D90077BC16; Tue, 13 Dec 2005 16:57:56 +0100 (CET) Message-ID: <439EEF87.8040908@nipsi.de> Date: Tue, 13 Dec 2005 16:57:59 +0100 From: Dennis Berger User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Craig Rodrigues References: <20051213151908.GA26821@crodrigues.org> In-Reply-To: <20051213151908.GA26821@crodrigues.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AV-Checked: checked Cc: freebsd-current@freebsd.org Subject: Re: XFS (read-only) support committed to CURRENT 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, 13 Dec 2005 15:58:50 -0000 Craig Rodrigues wrote: >Hi, > >Read-only XFS support has been committed to FreeBSD-CURRENT. >Write access to XFS is not supported at this time. >The XFS for FreeBSD source code is based off of GPL'd sources >provided by SGI. > >You can compile it into your kernel by adding "XFS" to your >kernel config file, or you can "kldload xfs". > >If you have an XFS partition on your system, you can try mounting it >with: >mount -t xfs [device] [mntpoint] > >Additional utilities such as mkfs.xfs are available in the sysutils/xfsprogs >port. > > what does mkfs.xfs do on a read-only XFS filesystem? when is write support be expected? besides these are great NEWS best regards, Dennis >Many thanks to Alexander Kabaev and Russell Cattelan for >starting and doing most of the work on the XFS for FreeBSD port, >and also to SGI for making the XFS source code freely available. > > > From owner-freebsd-current@FreeBSD.ORG Tue Dec 13 16:01:48 2005 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 9BF1016A41F; Tue, 13 Dec 2005 16:01:48 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9CB243D6A; Tue, 13 Dec 2005 16:01:47 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 3721127 for multiple; Tue, 13 Dec 2005 11:04:00 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jBDG1fds013472; Tue, 13 Dec 2005 11:01:41 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 13 Dec 2005 11:01:42 -0500 User-Agent: KMail/1.8.2 References: <20051211181324.G71610@ury.york.ac.uk> <1134481135.15730.76.camel@buffy.york.ac.uk> <1134485368.15730.95.camel@buffy.york.ac.uk> In-Reply-To: <1134485368.15730.95.camel@buffy.york.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512131101.44375.jhb@freebsd.org> X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: Gleb Smirnoff , imp@freebsd.org Subject: Re: puc fails to attach serial ports 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, 13 Dec 2005 16:01:48 -0000 On Tuesday 13 December 2005 09:49 am, Gavin Atkinson wrote: > On Tue, 2005-12-13 at 13:38 +0000, Gavin Atkinson wrote: > > On Mon, 2005-12-12 at 17:04 +0300, Gleb Smirnoff wrote: > > > On Sun, Dec 11, 2005 at 06:22:40PM +0000, Gavin Atkinson wrote: > > > G> I'm trying to use puc(4) under RELENG_6 to attach the two serial > > > ports on G> a PCI card I have, but it's not working. It also fails > > > under 6.0-RELEASE, G> I don't have the ability to test earlier > > > versions. > > > G> > > > G> How can I further diagnose why this card is not getting recognised? > > > > > > Afaik, you need 'device uart', that will attach to your pucs. > > > > No, as far as I can tell, it's sio that should be attaching. I've > > loaded the uart module anyway and it still fails. > > > > With BUS_DEBUG defined, I see the following: > > > > devclass_find_internal:761: looking for puc > > devclass_add_device:1356: (null) in devclass puc > > devclass_alloc_unit:1289: unit -1 in devclass puc > > devclass_alloc_unit:1329: now: unit 0 in devclass puc > > puc0: port 0x18c0-0x18df irq 25 at device 9.0 > > on pci0 > > puc0: Reserved 0x20 bytes for rid 0x10 type 4 at 0x18c0 > > port rid 16 bst 0, start 18c0, end 18df > > puc0: i 0, type sio, ressz 8, type 1 > > devclass_find_internal:761: looking for sio > > puc: Using sio2 > > device_add_child_ordered:1542: sio at puc with order 0 as unit 2 > > make_device:1427: sio at puc as unit 2 > > devclass_find_internal:761: looking for sio > > devclass_add_device:1356: (null) in devclass sio > > devclass_alloc_unit:1289: unit 2 in devclass sio > > devclass_alloc_unit:1329: now: unit 2 in devclass sio > > puc: type 1, bar 10, offset 0 > > devclass_find_driver_internal:1019: sio in devclass puc > > devclass_find_driver_internal:1026: not found > > puc0: i 1, type sio, ressz 8, type 1 > > devclass_find_internal:761: looking for sio > > puc: Using sio3 > > device_add_child_ordered:1542: sio at puc with order 0 as unit 3 > > make_device:1427: sio at puc as unit 3 > > devclass_find_internal:761: looking for sio > > devclass_add_device:1356: (null) in devclass sio > > devclass_alloc_unit:1289: unit 3 in devclass sio > > devclass_alloc_unit:1329: now: unit 3 in devclass sio > > puc: type 1, bar 10, offset 8 > > devclass_find_driver_internal:1019: sio in devclass puc > > devclass_find_driver_internal:1026: not found > > > > I'm sure somebody with more newbus knowledge will know exactly what that > > means... Are we somehow missing a devclass_add_driver(9) call from the > > puc initialisation? I'm almost at the point now where I can't > > understand how it could possibly be working for anyone else. > > OK, I've cracked what's happening. Indeed we are somehow missing a call > to devclass_add_driver(9). I was loading puc as a module, and in that > case the following relevant calls to devclass_add_driver are made: > > devclass_add_driver: adding puc to cardbus > devclass_add_driver: adding puc to pci > devclass_add_driver: adding puc to pccard > devclass_add_driver: adding uart to puc > devclass_add_driver: adding sio to pccard > devclass_add_driver: adding sio to pci > devclass_add_driver: adding sio to cardbus > devclass_add_driver: adding sio to isa > devclass_add_driver: adding sio to acpi > > When compiling puc into the kernel as opposed to using the module, the > following extra call is made: > > devclass_add_driver: adding sio to puc > > I don't understand why the DRIVER_METHOD(sio, puc, ...) is being ignored > in the puc-as-a-module case. Is this expected behaviour? I'm guessing > it's not. I do note also that ppc(4) is not added to the puc devclass, > presumably for the same reason. I'm also guessing things would work if > sio was a module too. > > It seems odd to me that a module cannot add an in-kernel driver to it's > devclass, but at this point I'm out of my depth as far as figuring out > how to fix it goes. Because sio(4) only includes sio_puc.c in the kernel if you have 'puc' in your kernel config, and the puc kernel module only includes the puc files, it doesn't include sio_puc.c and ppc_puc.c. uart has the same issue as well. Looking at the three attachments, there's no reason for them to be dependent on puc, they don't actually call any symbols in the puc(4) kernel module itself, so they can be compiled into kernels w/o puc without causing any harm. Then loading puc as a module would work. Here's a patch: Index: files =================================================================== RCS file: /usr/cvs/src/sys/conf/files,v retrieving revision 1.1076 diff -u -r1.1076 files --- files 12 Dec 2005 01:14:59 -0000 1.1076 +++ files 13 Dec 2005 16:00:04 -0000 @@ -815,7 +815,7 @@ dev/si/si_pci.c optional si pci dev/sio/sio_pccard.c optional sio pccard dev/sio/sio_pci.c optional sio pci -dev/sio/sio_puc.c optional sio puc pci +dev/sio/sio_puc.c optional sio pci dev/smbus/smb.c optional smb dev/smbus/smbconf.c optional smbus dev/smbus/smbus.c optional smbus @@ -928,7 +928,7 @@ dev/uart/uart_bus_isa.c optional uart isa dev/uart/uart_bus_pccard.c optional uart pccard dev/uart/uart_bus_pci.c optional uart pci -dev/uart/uart_bus_puc.c optional uart puc +dev/uart/uart_bus_puc.c optional uart dev/uart/uart_core.c optional uart dev/uart/uart_dbg.c optional uart gdb dev/uart/uart_dev_ns8250.c optional uart Index: files.alpha =================================================================== RCS file: /usr/cvs/src/sys/conf/files.alpha,v retrieving revision 1.123 diff -u -r1.123 files.alpha --- files.alpha 27 Nov 2005 21:41:58 -0000 1.123 +++ files.alpha 13 Dec 2005 16:00:09 -0000 @@ -170,7 +170,7 @@ dev/hwpmc/hwpmc_alpha.c optional hwpmc dev/kbd/kbd.c optional atkbd | sc | ukbd dev/ppc/ppc.c optional ppc -dev/ppc/ppc_puc.c optional ppc puc +dev/ppc/ppc_puc.c optional ppc dev/sio/sio.c optional sio dev/sio/sio_isa.c optional sio isa dev/syscons/schistory.c optional sc Index: files.i386 =================================================================== RCS file: /usr/cvs/src/sys/conf/files.i386,v retrieving revision 1.550 diff -u -r1.550 files.i386 --- files.i386 7 Dec 2005 21:30:46 -0000 1.550 +++ files.i386 13 Dec 2005 16:00:15 -0000 @@ -188,7 +188,7 @@ dev/nve/if_nve.c optional nve pci dev/pcf/pcf_isa.c optional pcf dev/ppc/ppc.c optional ppc -dev/ppc/ppc_puc.c optional ppc puc pci +dev/ppc/ppc_puc.c optional ppc pci dev/random/nehemiah.c optional random dev/sbni/if_sbni.c optional sbni dev/sbni/if_sbni_isa.c optional sbni isa Index: files.ia64 =================================================================== RCS file: /usr/cvs/src/sys/conf/files.ia64,v retrieving revision 1.84 diff -u -r1.84 files.ia64 --- files.ia64 27 Nov 2005 21:41:58 -0000 1.84 +++ files.ia64 13 Dec 2005 16:00:28 -0000 @@ -59,7 +59,7 @@ dev/hwpmc/hwpmc_ia64.c optional hwpmc dev/kbd/kbd.c optional atkbd | sc | ukbd dev/ppc/ppc.c optional ppc isa -dev/ppc/ppc_puc.c optional ppc puc +dev/ppc/ppc_puc.c optional ppc dev/syscons/schistory.c optional sc dev/syscons/scmouse.c optional sc dev/syscons/scterm-dumb.c optional sc Index: files.pc98 =================================================================== RCS file: /usr/cvs/src/sys/conf/files.pc98,v retrieving revision 1.334 diff -u -r1.334 files.pc98 --- files.pc98 7 Dec 2005 21:30:46 -0000 1.334 +++ files.pc98 13 Dec 2005 16:00:36 -0000 @@ -107,7 +107,7 @@ dev/mem/memutil.c optional mem dev/mse/mse.c optional mse dev/mse/mse_cbus.c optional mse isa -dev/ppc/ppc_puc.c optional ppc puc pci +dev/ppc/ppc_puc.c optional ppc pci dev/sbni/if_sbni.c optional sbni dev/sbni/if_sbni_pci.c optional sbni pci dev/snc/dp83932.c optional snc -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Dec 13 17:00:22 2005 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 A56AC16A426; Tue, 13 Dec 2005 17:00:22 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B40E43D5C; Tue, 13 Dec 2005 17:00:16 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.4/8.13.4) with ESMTP id jBDH0F5r060210; Tue, 13 Dec 2005 09:00:15 -0800 (PST) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id jBDH0FYb060209; Tue, 13 Dec 2005 09:00:15 -0800 (PST) (envelope-from obrien) Date: Tue, 13 Dec 2005 09:00:15 -0800 From: "David O'Brien" To: John Baldwin Message-ID: <20051213170015.GA60145@dragon.NUXI.org> Mail-Followup-To: freebsd-current@freebsd.org, John Baldwin , Gleb Smirnoff , imp@freebsd.org References: <20051211181324.G71610@ury.york.ac.uk> <1134481135.15730.76.camel@buffy.york.ac.uk> <1134485368.15730.95.camel@buffy.york.ac.uk> <200512131101.44375.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200512131101.44375.jhb@freebsd.org> X-Operating-System: FreeBSD 7.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org, imp@freebsd.org, Gleb Smirnoff Subject: Re: puc fails to attach serial ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2005 17:00:22 -0000 On Tue, Dec 13, 2005 at 11:01:42AM -0500, John Baldwin wrote: > Because sio(4) only includes sio_puc.c in the kernel if you have 'puc' in your > kernel config, and the puc kernel module only includes the puc files, it > doesn't include sio_puc.c and ppc_puc.c. uart has the same issue as well. > Looking at the three attachments, there's no reason for them to be dependent > on puc, they don't actually call any symbols in the puc(4) kernel module > itself, so they can be compiled into kernels w/o puc without causing any > harm. Then loading puc as a module would work. Here's a patch: Isn't there another way? It just seems wrong to include *_puc bits in the kernel if you don't have 'puc' in your kernel. There are some working on trimming down the kernel for embedded purposes and this patch seems counter to that effort. -- -- David (obrien@FreeBSD.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? From owner-freebsd-current@FreeBSD.ORG Tue Dec 13 17:02:07 2005 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 55BF116A41F for ; Tue, 13 Dec 2005 17:02:07 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [216.148.227.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBB6E43D53 for ; Tue, 13 Dec 2005 17:02:06 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from c-24-63-58-245.hsd1.ma.comcast.net ([24.63.58.245]) by comcast.net (rwcrmhc11) with ESMTP id <2005121317020401300c994ce>; Tue, 13 Dec 2005 17:02:05 +0000 Received: from c-24-63-58-245.hsd1.ma.comcast.net (localhost [127.0.0.1]) by c-24-63-58-245.hsd1.ma.comcast.net (8.13.4/8.13.1) with ESMTP id jBDH278N029645; Tue, 13 Dec 2005 12:02:07 -0500 (EST) (envelope-from rodrigc@c-24-63-58-245.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-24-63-58-245.hsd1.ma.comcast.net (8.13.4/8.13.1/Submit) id jBDH26jR029644; Tue, 13 Dec 2005 12:02:06 -0500 (EST) (envelope-from rodrigc) Date: Tue, 13 Dec 2005 12:02:06 -0500 From: Craig Rodrigues To: Dennis Berger Message-ID: <20051213170206.GA29628@crodrigues.org> References: <20051213151908.GA26821@crodrigues.org> <439EEF87.8040908@nipsi.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <439EEF87.8040908@nipsi.de> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: XFS (read-only) support committed to CURRENT 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, 13 Dec 2005 17:02:07 -0000 On Tue, Dec 13, 2005 at 04:57:59PM +0100, Dennis Berger wrote: > what does mkfs.xfs do on a read-only XFS filesystem? You can format a device with mkfs.xfs and mount it as read-only. mksfs.xfs accepts a -p flag, which lets you write dummy metadata (i.e. directory entries) when you format the partition for XFS. -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-current@FreeBSD.ORG Tue Dec 13 18:01:43 2005 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 3F3AE16A41F; Tue, 13 Dec 2005 18:01:43 +0000 (GMT) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail-gw1.york.ac.uk (mail-gw1.york.ac.uk [144.32.128.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5BCBA43D55; Tue, 13 Dec 2005 18:00:59 +0000 (GMT) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from buffy.york.ac.uk (buffy-128.york.ac.uk [144.32.128.160]) by mail-gw1.york.ac.uk (8.12.10/8.12.10) with ESMTP id jBDI0tNW013649; Tue, 13 Dec 2005 18:00:55 GMT Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.13.4/8.13.4) with ESMTP id jBDI0sIo021607; Tue, 13 Dec 2005 18:00:54 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) Received: (from ga9@localhost) by buffy.york.ac.uk (8.13.4/8.13.4/Submit) id jBDI0sun021606; Tue, 13 Dec 2005 18:00:54 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin.atkinson@ury.york.ac.uk using -f From: Gavin Atkinson To: John Baldwin In-Reply-To: <200512131101.44375.jhb@freebsd.org> References: <20051211181324.G71610@ury.york.ac.uk> <1134481135.15730.76.camel@buffy.york.ac.uk> <1134485368.15730.95.camel@buffy.york.ac.uk> <200512131101.44375.jhb@freebsd.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 13 Dec 2005 18:00:53 +0000 Message-Id: <1134496853.15730.118.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin.atkinson@ury.york.ac.uk Cc: freebsd-current@freebsd.org, imp@freebsd.org, Gleb Smirnoff Subject: Re: puc fails to attach serial ports 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, 13 Dec 2005 18:01:43 -0000 On Tue, 2005-12-13 at 11:01 -0500, John Baldwin wrote: > > OK, I've cracked what's happening. Indeed we are somehow missing a call > > to devclass_add_driver(9). I was loading puc as a module, and in that > > case the following relevant calls to devclass_add_driver are made: > > > Because sio(4) only includes sio_puc.c in the kernel if you have 'puc' in your > kernel config, and the puc kernel module only includes the puc files, it > doesn't include sio_puc.c and ppc_puc.c. uart has the same issue as well. > Looking at the three attachments, there's no reason for them to be dependent > on puc, they don't actually call any symbols in the puc(4) kernel module > itself, so they can be compiled into kernels w/o puc without causing any > harm. Then loading puc as a module would work. Here's a patch: Thanks! I can confirm that this patch fixes the problem I was seeing. I understand David O'Brien's concerns about the patch and associated increase in kernel size, but as it stands, there seems to be little point in creating a puc module as it cannot work with the GENERIC kernel (other than for devices using uart, as that isn't in GENERIC). Gavin From owner-freebsd-current@FreeBSD.ORG Tue Dec 13 19:15:54 2005 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 853B416A440 for ; Tue, 13 Dec 2005 19:15:54 +0000 (GMT) (envelope-from unixfreunde@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD67743DD5 for ; Tue, 13 Dec 2005 19:14:21 +0000 (GMT) (envelope-from unixfreunde@gmail.com) Received: by zproxy.gmail.com with SMTP id z31so1787997nzd for ; Tue, 13 Dec 2005 11:13:59 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type:content-transfer-encoding; b=X6LVwn88SSIKSkSM+J6kzYgIPLp/XCHHT4k4LuklUhvyrpsJ5bZOQbqO4Lt0xxz+PJ3aa4P2m7cP3tIn6G4teni7umFDi4/oR1xoKy20DuuYNiphGeNGztTmoTeYbNZ3Bi6bRkzYe60he7Yj5hijhEuVPj/lR3BIYxyzDxWw/yM= Received: by 10.36.5.19 with SMTP id 19mr7631295nze; Tue, 13 Dec 2005 11:13:58 -0800 (PST) Received: from splash.homeunix.org ( [84.141.63.94]) by mx.gmail.com with ESMTP id 16sm11527215nzo.2005.12.13.11.13.56; Tue, 13 Dec 2005 11:13:58 -0800 (PST) Date: Tue, 13 Dec 2005 20:16:47 +0100 From: Martin Wilke To: freebsd-current@freebsd.org Message-ID: <20051213201647.758aae30@splash.homeunix.org> In-Reply-To: <20051213151908.GA26821@crodrigues.org> References: <20051213151908.GA26821@crodrigues.org> X-Mailer: Sylpheed-Claws 1.9.100 (GTK+ 2.8.9; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: base64 Subject: Re: XFS (read-only) support committed to CURRENT 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, 13 Dec 2005 19:15:56 -0000 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMQ0KDQpPbiBUdWUs IDEzIERlYyAyMDA1IDEwOjE5OjA4IC0wNTAwDQpDcmFpZyBSb2RyaWd1ZXMgPHJvZHJpZ2NAY3Jv ZHJpZ3Vlcy5vcmc+IHdyb3RlOg0KDQo+IEhpLA0KPiANCj4gUmVhZC1vbmx5IFhGUyBzdXBwb3J0 IGhhcyBiZWVuIGNvbW1pdHRlZCB0byBGcmVlQlNELUNVUlJFTlQuDQo+IFdyaXRlIGFjY2VzcyB0 byBYRlMgaXMgbm90IHN1cHBvcnRlZCBhdCB0aGlzIHRpbWUuDQo+IFRoZSBYRlMgZm9yIEZyZWVC U0Qgc291cmNlIGNvZGUgaXMgYmFzZWQgb2ZmIG9mIEdQTCdkIHNvdXJjZXMNCj4gcHJvdmlkZWQg YnkgU0dJLg0KPiANCj4gWW91IGNhbiBjb21waWxlIGl0IGludG8geW91ciBrZXJuZWwgYnkgYWRk aW5nICJYRlMiIHRvIHlvdXINCj4ga2VybmVsIGNvbmZpZyBmaWxlLCBvciB5b3UgY2FuICJrbGRs b2FkIHhmcyIuDQo+IA0KPiBJZiB5b3UgaGF2ZSBhbiBYRlMgcGFydGl0aW9uIG9uIHlvdXIgc3lz dGVtLCB5b3UgY2FuIHRyeSBtb3VudGluZyBpdA0KPiB3aXRoOg0KPiBtb3VudCAtdCB4ZnMgW2Rl dmljZV0gW21udHBvaW50XQ0KPiANCj4gQWRkaXRpb25hbCB1dGlsaXRpZXMgc3VjaCBhcyBta2Zz LnhmcyBhcmUgYXZhaWxhYmxlIGluIHRoZQ0KPiBzeXN1dGlscy94ZnNwcm9ncyBwb3J0LiANCj4g DQo+IE1hbnkgdGhhbmtzIHRvIEFsZXhhbmRlciBLYWJhZXYgYW5kIFJ1c3NlbGwgQ2F0dGVsYW4g Zm9yDQo+IHN0YXJ0aW5nIGFuZCBkb2luZyBtb3N0IG9mIHRoZSB3b3JrIG9uIHRoZSBYRlMgZm9y IEZyZWVCU0QgcG9ydCwNCj4gYW5kIGFsc28gdG8gU0dJIGZvciBtYWtpbmcgdGhlIFhGUyBzb3Vy Y2UgY29kZSBmcmVlbHkgYXZhaWxhYmxlLg0KPiANCg0KDQpoaSBndXlzLCANCg0KSW4gbXkgb3Bp bmlvbiB0aGUgeGZzIHN1cHBvcnQgaXMgYSBjb29sIGlkZWEuLiBOb3csIEkgaGVhcmQNCnRoZXJl IGlzIHRoZSBwb3NzaWJpbGl0eSB0byB0dXJuIGl0IG9mZiBvcHRpb25hbGx5PyAuLi4gSSBqdXN0 IGNhbnQNCmZpbmQgYW55IGRva3VtZW50YXRpb24gb3IgbWFudWFsIGZvciBpdC4NCg0KY2hlZXJz IE1hcnRpbg0KLS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYx LjQuMiAoRnJlZUJTRCkNCg0KaUQ4REJRRkRueDRpRlJaL2tCVDR2cDhSQXBRMEFKOWRBSWVtZTFt VFJGNnZuUmNPc0UrTWovNzFOUUNkRmtyeQ0KT0pDd3ZoMThpSnoyVUZYL1ZnTnk5aDQ9DQo9alBS RA0KLS0tLS1FTkQgUEdQIFNJR05BVFVSRS0tLS0tDQo= From owner-freebsd-current@FreeBSD.ORG Tue Dec 13 19:36:54 2005 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 55CAB16A41F; Tue, 13 Dec 2005 19:36:54 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB9AF43D49; Tue, 13 Dec 2005 19:36:52 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 3733879 for multiple; Tue, 13 Dec 2005 14:39:08 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jBDJakZ0050353; Tue, 13 Dec 2005 14:36:48 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 13 Dec 2005 14:36:02 -0500 User-Agent: KMail/1.8.2 References: <20051211181324.G71610@ury.york.ac.uk> <200512131101.44375.jhb@freebsd.org> <20051213170015.GA60145@dragon.NUXI.org> In-Reply-To: <20051213170015.GA60145@dragon.NUXI.org> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200512131436.03403.jhb@freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: Gleb Smirnoff , imp@freebsd.org Subject: Re: puc fails to attach serial ports 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, 13 Dec 2005 19:36:54 -0000 On Tuesday 13 December 2005 12:00 pm, David O'Brien wrote: > On Tue, Dec 13, 2005 at 11:01:42AM -0500, John Baldwin wrote: > > Because sio(4) only includes sio_puc.c in the kernel if you have 'puc' in > > your kernel config, and the puc kernel module only includes the puc > > files, it doesn't include sio_puc.c and ppc_puc.c. uart has the same > > issue as well. Looking at the three attachments, there's no reason for > > them to be dependent on puc, they don't actually call any symbols in the > > puc(4) kernel module itself, so they can be compiled into kernels w/o puc > > without causing any harm. Then loading puc as a module would work. > > Here's a patch: > > Isn't there another way? It just seems wrong to include *_puc bits in > the kernel if you don't have 'puc' in your kernel. There are some > working on trimming down the kernel for embedded purposes and this patch > seems counter to that effort. Well, you could have sio_puc, ppc_puc, and uart_puc modules, and you could do: kldload sio_puc.ko kldload ppc_puc.ko kldload uart_puc.ko kldload puc.ko However, that type of approach will give us a huge profileration of modules and make them even less useful and a PITA to use than they are now. Also, in this case we are talking about a total of about 6 short functions (2 per device), and even then you only get them if you put sio, ppc, uart, etc. in your kernel. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Dec 13 23:03:18 2005 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 B41BC16A41F; Tue, 13 Dec 2005 23:03:18 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCA4C43D8E; Tue, 13 Dec 2005 23:03:09 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id jBDN2me8023124; Tue, 13 Dec 2005 16:02:49 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 13 Dec 2005 16:02:48 -0700 (MST) Message-Id: <20051213.160248.74727585.imp@bsdimp.com> To: gavin.atkinson@ury.york.ac.uk From: Warner Losh In-Reply-To: <1134485368.15730.95.camel@buffy.york.ac.uk> References: <20051212140446.GQ37414@FreeBSD.org> <1134481135.15730.76.camel@buffy.york.ac.uk> <1134485368.15730.95.camel@buffy.york.ac.uk> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Tue, 13 Dec 2005 16:02:49 -0700 (MST) Cc: glebius@freebsd.org, freebsd-current@freebsd.org Subject: Re: puc fails to attach serial ports 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, 13 Dec 2005 23:03:18 -0000 On Tue, 2005-12-13 at 13:38 +0000, Gavin Atkinson wrote: > I don't understand why the DRIVER_METHOD(sio, puc, ...) is being ignored > in the puc-as-a-module case. Is this expected behaviour? Not being ignore, just not in the kernel. When you compile things statically, you compile them statically. You have to include puc and sio in the same kernel to get them both to work. *OR* you have to load puc and sio as modules. I do that all the time, and that works. Warner From owner-freebsd-current@FreeBSD.ORG Tue Dec 13 23:06:15 2005 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 42FCC16A41F; Tue, 13 Dec 2005 23:06:15 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 97C8043D53; Tue, 13 Dec 2005 23:06:14 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id jBDN5XpA023145; Tue, 13 Dec 2005 16:05:33 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 13 Dec 2005 16:05:32 -0700 (MST) Message-Id: <20051213.160532.41656770.imp@bsdimp.com> To: freebsd-current@freebsd.org, obrien@freebsd.org From: Warner Losh In-Reply-To: <20051213170015.GA60145@dragon.NUXI.org> References: <1134485368.15730.95.camel@buffy.york.ac.uk> <200512131101.44375.jhb@freebsd.org> <20051213170015.GA60145@dragon.NUXI.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Tue, 13 Dec 2005 16:05:33 -0700 (MST) Cc: glebius@freebsd.org Subject: Re: puc fails to attach serial ports 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, 13 Dec 2005 23:06:15 -0000 From: "David O'Brien" Subject: Re: puc fails to attach serial ports Date: Tue, 13 Dec 2005 09:00:15 -0800 > On Tue, Dec 13, 2005 at 11:01:42AM -0500, John Baldwin wrote: > > Because sio(4) only includes sio_puc.c in the kernel if you have 'puc' in your > > kernel config, and the puc kernel module only includes the puc files, it > > doesn't include sio_puc.c and ppc_puc.c. uart has the same issue as well. > > Looking at the three attachments, there's no reason for them to be dependent > > on puc, they don't actually call any symbols in the puc(4) kernel module > > itself, so they can be compiled into kernels w/o puc without causing any > > harm. Then loading puc as a module would work. Here's a patch: > > Isn't there another way? It just seems wrong to include *_puc bits in > the kernel if you don't have 'puc' in your kernel. There are some > working on trimming down the kernel for embedded purposes and this patch > seems counter to that effort. puc certainly isn't unique. pccard has exactly this same problem as well. However, with pccard, people rarely load it as a module. In general, if you want full dynamic behavior, you have to load everything as a module (this works very well, I do it for everything except ata on my laptop). If you want static behavior, you need to build stuff statically. If you want to cross threat the two, you might run into problems like this. Warner From owner-freebsd-current@FreeBSD.ORG Tue Dec 13 23:03:37 2005 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 41B8516A41F for ; Tue, 13 Dec 2005 23:03:37 +0000 (GMT) (envelope-from dci@kicks-ass.ru) Received: from cat.kicks-ass.ru (kicks-ass.ru [217.112.40.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id A04CB43D5E for ; Tue, 13 Dec 2005 23:03:31 +0000 (GMT) (envelope-from dci@kicks-ass.ru) Received: from [87.240.8.11] (unknown [87.240.8.11]) by cat.kicks-ass.ru (Postfix) with ESMTP id E369417087 for ; Tue, 13 Dec 2005 23:03:33 +0000 (UTC) Date: Wed, 14 Dec 2005 02:03:29 +0300 From: Anton X-Mailer: The Bat! (v3.0.1.33) Professional X-Priority: 3 (Normal) Message-ID: <1154074144.20051214020329@kicks-ass.ru> To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=Windows-1251 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Tue, 13 Dec 2005 23:10:14 +0000 Subject: rebuild problems with ata-raid on array with freebsd native meta X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?Windows-1251?Q?=C0=ED=F2=EE=ED?= List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2005 23:03:37 -0000 Hello freebsd-current, From the beginning... First of all i have a intel se7520jr2 motherboard with SATA RAID (or something:) integrated in ICH5R south bridge and two identical SATA HDDs connected to it. The aim is RAID1 array, which could be rebuilt without rebooting. Sounds simple. Before reading manuals and information i tried to do this directly, by creating RAID1 array in LSI Integrated RAID utility. FreeBSD6 had found created array and had been installed without any troubles, but `atacontrol rebuild ar0` always had had ENXIO as a result. After digging docs and ata-raid.c file, i understood, that arrays, which metadata format(LSI V3 MegaRAID) is r/o for ata-raid, can not be rebuilt by atacontrol(Is it correct?). Next step was disabling build-in 'RAID' and migrating to freebsd native metadata format. So, i had edited /etc/fstab to boot from ad0, then deleted array in LSI Utility, than disabled RAID extensions, than # atacontrol create RAID1 ad0 ad2 # atacontrol detach ata1 && atacontrol attach ata1 # atacontrol rebuild ar0 than i had edited fstab back to boot from ar0, reboot(Will Robinson here), # atacontrol detach ata1 && atacontrol attach ata1 # atacontrol rebuild ar0 to sync discs again and here i'd got a subject problem. rebuild process started, dd spawned, after several seconds progress counter switched to 1%. but then ad2 became inactive(LED turned off), progress counter fall back to 0%. ad0 remains active at this time. hour later dd finished reading and exited, raid status remained "REBUILDING 0% completed", no errors on all terminals was shown. i tried to launch dd again, but it all remains the same(counter goes up to 1%, then ad2 deactivation and counter reset). so problem is here: if filesystems are mounted from ad0, i can rebuild array. if thay are mounted from ar0, rebuild process will fail after some progress. this doesn't depend on kernel(i tried to rebuild with GENERIC), on drives(i tried tree different HDDs as spare). metadata is in native format(FreeBSD PseudoRAID RAID1 on boot). here some info about filesystems configuration: ~ # cat /etc/fstab # working config differs a lot, but error persists with this sample fstab. # Device Mountpoint FStype Options Dump Pass# /dev/ar0s1b none swap sw 0 0 /dev/ar0s1a / ufs rw 1 1 /dev/ar0s1f /home ufs rw 2 2 /dev/ar0s1d /usr ufs rw 2 2 /dev/ar0s1e /var ufs rw 2 2 ~ # df -H Filesystem Size Used Avail Capacity Mounted on /dev/ar0s1a 1.0G 57M 874M 6% / devfs 1.0k 1.0k 0B 100% /dev /dev/ar0s1f 281G 37k 259G 0% /home /dev/ar0s1d 1.0G 775M 156M 83% /usr /dev/ar0s1e 5.1G 999k 4.7G 0% /var ~ # so where should i look at? maybe i must recreate slices after raid creation? or maybe LSI V3 metadata write support is coming soon(even simple, for single array) and i should just wait some time? -- Best regards, Anton mailto:dci@kicks-ass.ru From owner-freebsd-current@FreeBSD.ORG Wed Dec 14 10:06:34 2005 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 1325816A41F for ; Wed, 14 Dec 2005 10:06:34 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from mail.yazzy.org (mail.yazzy.org [217.8.140.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9467043D67 for ; Wed, 14 Dec 2005 10:06:31 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from [84.247.144.144] (helo=marcin) by mail.yazzy.org with esmtps (TLSv1:AES256-SHA:256) (YazzY.org) id 1EmTVi-0002bc-Vn for current@freebsd.org; Wed, 14 Dec 2005 11:05:25 +0100 Date: Wed, 14 Dec 2005 11:06:33 +0100 From: Marcin Jessa To: FreeBSD-Current Message-Id: <20051214110633.0b1f8241.lists@yazzy.org> Organization: YazzY.org X-Mailer: Sylpheed version 2.0.4 (GTK+ 2.8.7; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: -2.2 (--) Cc: Subject: Incorrect link in pcap(3) 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, 14 Dec 2005 10:06:34 -0000 Hi. man 3 pcap points to unexisting link: http://www.shaftnet.org/~pizza/software/capturefrm.txt My uname -a: FreeBSD troll 7.0-CURRENT FreeBSD 7.0-CURRENT #9: Tue Dec 13 16:45:02 CET 2005 root@troll:/usr/obj/usr/src/sys/TROLL i386 From owner-freebsd-current@FreeBSD.ORG Wed Dec 14 13:11:07 2005 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 B671616A41F for ; Wed, 14 Dec 2005 13:11:07 +0000 (GMT) (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 7F07043D5A for ; Wed, 14 Dec 2005 13:11:06 +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.4/8.13.4) with ESMTP id jBEDAxu9014330 for ; Wed, 14 Dec 2005 14:10:59 +0100 Received: from localhost (ggajic@localhost) by afrodita.rcub.bg.ac.yu (8.13.4/8.13.4/Submit) with ESMTP id jBEDAwPC014327 for ; Wed, 14 Dec 2005 14:10:59 +0100 Date: Wed, 14 Dec 2005 14:10:58 +0100 (CET) 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: Wed, 14 Dec 2005 14:11:43 +0000 Cc: Subject: 7.0-CURRENT panic on kldunload linux.ko 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, 14 Dec 2005 13:11:07 -0000 FreeBSD fbsd.interex-pla.net 7.0-CURRENT FreeBSD 7.0-CURRENT #5: Wed Dec 14 13:30:55 CET 2005 root@fbsd.interex-pla.net:/usr/src/sys/i386/compile/TEST i386 fbsd# kgdb /usr/src/sys/i386/compile/TEST/kernel.debug /var/crash/vmcore.1 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: panic: witness_destroy: lock (sleep mutex) linux osname is not initialized KDB: enter: panic Uptime: 33s Dumping 511 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 511MB (130736 pages) 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:165 165 pcpu.h: No such file or directory. in pcpu.h (kgdb) backtrace #0 doadump () at pcpu.h:165 #1 0xc0666da0 in boot (howto=260) at ../../../kern/kern_shutdown.c:399 #2 0xc0666ffb in panic (fmt=0xc08db756 "%s: lock (%s) %s is not initialized") at ../../../kern/kern_shutdown.c:555 #3 0xc0687540 in witness_destroy (lock=0xc367ac7c) at ../../../kern/subr_witness.c:589 #4 0xc0660092 in mtx_destroy (m=0xc367ac7c) at ../../../kern/kern_mutex.c:891 #5 0xc065a355 in linker_file_sysuninit (lf=0xc3660400) at ../../../kern/kern_linker.c:238 #6 0xc065a992 in linker_file_unload (file=0xc3660400, flags=0) at ../../../kern/kern_linker.c:539 #7 0xc065b080 in kern_kldunload (td=0xc3660400, fileid=6, flags=0) at ../../../kern/kern_linker.c:828 #8 0xc065b0de in kldunloadf (td=0xc352cd80, uap=0x0) at ../../../kern/kern_linker.c:858 #9 0xc086db1e in syscall (frame= {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 6, tf_esi = -1077940702, tf_ebp = -1077941000, tf_isp = -646460060, tf_ebx = 1, tf_edx = 0, tf_ecx = 1, tf_e ax = 444, tf_trapno = 12, tf_err = 2, tf_eip = 671825691, tf_cs = 51, tf_eflags = 658, tf_esp = -1077942132, tf_ss = 59}) at ../../../i386/i386/trap.c:1008 #10 0xc085cc4f in Xint0x80_syscall () at ../../../i386/i386/exception.s:190 #11 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) Running skype-1.2.0.18 for linux will immediately reboot machine without warring.. Regards, gg. From owner-freebsd-current@FreeBSD.ORG Wed Dec 14 15:36:57 2005 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 3458016A41F for ; Wed, 14 Dec 2005 15:36:57 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vbook.fbsd.ru (swsoft-mipt-nat.sw.ru [195.214.233.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3291643D6A for ; Wed, 14 Dec 2005 15:36:55 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EmYgY-0006Dx-Pn for current@freebsd.org; Wed, 14 Dec 2005 18:36:54 +0300 From: Vladimir Grebenschikov To: current Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: SWsoft Date: Wed, 14 Dec 2005 18:36:54 +0300 Message-Id: <1134574614.1214.21.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.1 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov Cc: Subject: buildworld 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, 14 Dec 2005 15:36:57 -0000 7-CURRENT, fresh cvsup # make buildworld ... cat /usr/src/bin/csh/../../contrib/tcsh/nls/et/set1 /usr/src/bin/csh/../../contrib/tcsh/nls/et/set10 /usr/src/bin/csh/../../contrib/tcsh/nls/et/set11 /usr/src/bin/csh/../../contrib/tcsh/nls/et/set12 /usr/src/bin/csh/../../contrib/tcsh/nls/et/set13 /usr/src/bin/csh/../../contrib/tcsh/nls/et/set14 /usr/src/bin/csh/../../contrib/tcsh/nls/et/set15 /usr/src/bin/csh/../../contrib/tcsh/nls/et/set16 /usr/src/bin/csh/../../contrib/tcsh/nls/et/set17 /usr/src/bin/csh/../../contrib/tcsh/nls/et/set18 /usr/src/bin/csh/../../contrib/tcsh/nls/et/set19 /usr/src/bin/csh/../../contrib/tcsh/nls/et/set2 /usr/src/bin/csh/../../contrib/tcsh/nls/et/set20 /usr/src/bin/csh/../../contrib/tcsh/nls/et/set21 /usr/src/bin/csh/../../contrib/tcsh/nls/et/set22 /usr/src/bin/csh/../../contrib/tcsh/nls/et/set23 /usr/src/bin/csh/../../contrib/tcsh/nls/et/set24 /usr/src/bin/csh/../../contrib/tcsh/nls/et/set25 /usr/src/bin/csh/../../contrib/tcsh/nls/et/set26 /usr/src/bin/csh/../../contrib/tcsh/nls/et/set27 /usr/src /bin/csh/../../contrib/tcsh/nls/et/set29 /usr/src/bin/csh/../../contrib/tcsh/nls/et/set3 /usr/src/bin/csh/../../contrib/tcsh/nls/et/set30 /usr/src/bin/csh/../../contrib/tcsh/nls/et/set31 /usr/src/bin/csh/../../contrib/tcsh/nls/et/set4 /usr/src/bin/csh/../../contrib/tcsh/nls/et/set5 /usr/src/bin/csh/../../contrib/tcsh/nls/et/set6 /usr/src/bin/csh/../../contrib/tcsh/nls/et/set7 /usr/src/bin/csh/../../contrib/tcsh/nls/et/set8 /usr/src/bin/csh/../../contrib/tcsh/nls/et/set9 > et_EE.ISO8859-15.msg gencat et_EE.ISO8859-15.cat et_EE.ISO8859-15.msg et_EE.ISO8859-15.msg:4: invalid character: message ignored et_EE.ISO8859-15.msg:6: invalid character: message ignored et_EE.ISO8859-15.msg:9: invalid character: message ignored et_EE.ISO8859-15.msg:10: invalid character: message ignored et_EE.ISO8859-15.msg:11: invalid character: message ignored et_EE.ISO8859-15.msg:14: invalid character: message ignored et_EE.ISO8859-15.msg:16: invalid character: message ignored et_EE.ISO8859-15.msg:17: invalid character: message ignored et_EE.ISO8859-15.msg:18: invalid character: message ignored et_EE.ISO8859-15.msg:21: invalid character: message ignored et_EE.ISO8859-15.msg:22: invalid character: message ignored et_EE.ISO8859-15.msg:23: invalid character: message ignored et_EE.ISO8859-15.msg:28: invalid character: message ignored et_EE.ISO8859-15.msg:30: invalid character: message ignored et_EE.ISO8859-15.msg:33: invalid character: message ignored ... cut ... et_EE.ISO8859-15.msg:729: invalid character: message ignored et_EE.ISO8859-15.msg:732: invalid character: message ignored et_EE.ISO8859-15.msg:735: invalid character: message ignored et_EE.ISO8859-15.msg:736: invalid character: message ignored *** Error code 1 Stop in /usr/src/bin/csh. *** Error code 1 Stop in /usr/src/bin. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. # -- Vladimir B. Grebenschikov SWsoft Inc. vova@swsoft.com From owner-freebsd-current@FreeBSD.ORG Wed Dec 14 16:07:46 2005 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 6693B16A41F for ; Wed, 14 Dec 2005 16:07:46 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id A838C43D5D for ; Wed, 14 Dec 2005 16:07:45 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 3795607 for multiple; Wed, 14 Dec 2005 11:05:42 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jBEG7ZRV057568; Wed, 14 Dec 2005 11:07:36 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 14 Dec 2005 11:06:50 -0500 User-Agent: KMail/1.8.2 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512141106.51839.jhb@freebsd.org> X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: freebsd-current@www.freebsd.org, Goran Gajic Subject: Re: 7.0-CURRENT panic on kldunload linux.ko 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, 14 Dec 2005 16:07:46 -0000 On Wednesday 14 December 2005 08:10 am, Goran Gajic wrote: > FreeBSD fbsd.interex-pla.net 7.0-CURRENT FreeBSD 7.0-CURRENT #5: Wed Dec 14 > 13:30:55 CET 2005 > root@fbsd.interex-pla.net:/usr/src/sys/i386/compile/TEST i386 > > fbsd# kgdb /usr/src/sys/i386/compile/TEST/kernel.debug > /var/crash/vmcore.1 > [GDB will not be able to debug user-mode threads: > /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you > are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "i386-marcel-freebsd". > > Unread portion of the kernel message buffer: > panic: witness_destroy: lock (sleep mutex) linux osname is not initialized > KDB: enter: panic > Uptime: 33s > Dumping 511 MB (2 chunks) > chunk 0: 1MB (159 pages) ... ok > chunk 1: 511MB (130736 pages) 495 479 463 447 431 415 399 383 367 351 > 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 > 15 > > #0 doadump () at pcpu.h:165 > 165 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) backtrace > #0 doadump () at pcpu.h:165 > #1 0xc0666da0 in boot (howto=260) at ../../../kern/kern_shutdown.c:399 > #2 0xc0666ffb in panic (fmt=0xc08db756 "%s: lock (%s) %s is not > initialized") at ../../../kern/kern_shutdown.c:555 > #3 0xc0687540 in witness_destroy (lock=0xc367ac7c) at > ../../../kern/subr_witness.c:589 > #4 0xc0660092 in mtx_destroy (m=0xc367ac7c) at > ../../../kern/kern_mutex.c:891 > #5 0xc065a355 in linker_file_sysuninit (lf=0xc3660400) at > ../../../kern/kern_linker.c:238 > #6 0xc065a992 in linker_file_unload (file=0xc3660400, flags=0) at > ../../../kern/kern_linker.c:539 > #7 0xc065b080 in kern_kldunload (td=0xc3660400, fileid=6, flags=0) at > ../../../kern/kern_linker.c:828 > #8 0xc065b0de in kldunloadf (td=0xc352cd80, uap=0x0) at > ../../../kern/kern_linker.c:858 > #9 0xc086db1e in syscall (frame= > {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 6, tf_esi = > -1077940702, tf_ebp = -1077941000, tf_isp = -646460060, tf_ebx = 1, tf_edx > = 0, tf_ecx = 1, tf_e > ax = 444, tf_trapno = 12, tf_err = 2, tf_eip = 671825691, tf_cs = 51, > tf_eflags = 658, tf_esp = -1077942132, tf_ss = 59}) at > ../../../i386/i386/trap.c:1008 > #10 0xc085cc4f in Xint0x80_syscall () at > ../../../i386/i386/exception.s:190 > #11 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) Very odd indeed. Ah, try the patch at http://www.freebsd.org/~jhb/patches/linux_unload.patch The linux_osname mutex was being destroyed twice. > Running skype-1.2.0.18 for linux will immediately reboot machine without > warring.. That I don't have any good ideas for. Are you in X when it happens? If so, can you hook up a serial console to see if it panics? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Dec 14 16:07:54 2005 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 CE97316A41F for ; Wed, 14 Dec 2005 16:07:54 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 36C2743D49 for ; Wed, 14 Dec 2005 16:07:54 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 3795607 for multiple; Wed, 14 Dec 2005 11:05:42 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jBEG7ZRV057568; Wed, 14 Dec 2005 11:07:36 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 14 Dec 2005 11:06:50 -0500 User-Agent: KMail/1.8.2 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512141106.51839.jhb@freebsd.org> X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: freebsd-current@www.freebsd.org, Goran Gajic Subject: Re: 7.0-CURRENT panic on kldunload linux.ko 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, 14 Dec 2005 16:07:55 -0000 On Wednesday 14 December 2005 08:10 am, Goran Gajic wrote: > FreeBSD fbsd.interex-pla.net 7.0-CURRENT FreeBSD 7.0-CURRENT #5: Wed Dec 14 > 13:30:55 CET 2005 > root@fbsd.interex-pla.net:/usr/src/sys/i386/compile/TEST i386 > > fbsd# kgdb /usr/src/sys/i386/compile/TEST/kernel.debug > /var/crash/vmcore.1 > [GDB will not be able to debug user-mode threads: > /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you > are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "i386-marcel-freebsd". > > Unread portion of the kernel message buffer: > panic: witness_destroy: lock (sleep mutex) linux osname is not initialized > KDB: enter: panic > Uptime: 33s > Dumping 511 MB (2 chunks) > chunk 0: 1MB (159 pages) ... ok > chunk 1: 511MB (130736 pages) 495 479 463 447 431 415 399 383 367 351 > 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 > 15 > > #0 doadump () at pcpu.h:165 > 165 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) backtrace > #0 doadump () at pcpu.h:165 > #1 0xc0666da0 in boot (howto=260) at ../../../kern/kern_shutdown.c:399 > #2 0xc0666ffb in panic (fmt=0xc08db756 "%s: lock (%s) %s is not > initialized") at ../../../kern/kern_shutdown.c:555 > #3 0xc0687540 in witness_destroy (lock=0xc367ac7c) at > ../../../kern/subr_witness.c:589 > #4 0xc0660092 in mtx_destroy (m=0xc367ac7c) at > ../../../kern/kern_mutex.c:891 > #5 0xc065a355 in linker_file_sysuninit (lf=0xc3660400) at > ../../../kern/kern_linker.c:238 > #6 0xc065a992 in linker_file_unload (file=0xc3660400, flags=0) at > ../../../kern/kern_linker.c:539 > #7 0xc065b080 in kern_kldunload (td=0xc3660400, fileid=6, flags=0) at > ../../../kern/kern_linker.c:828 > #8 0xc065b0de in kldunloadf (td=0xc352cd80, uap=0x0) at > ../../../kern/kern_linker.c:858 > #9 0xc086db1e in syscall (frame= > {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 6, tf_esi = > -1077940702, tf_ebp = -1077941000, tf_isp = -646460060, tf_ebx = 1, tf_edx > = 0, tf_ecx = 1, tf_e > ax = 444, tf_trapno = 12, tf_err = 2, tf_eip = 671825691, tf_cs = 51, > tf_eflags = 658, tf_esp = -1077942132, tf_ss = 59}) at > ../../../i386/i386/trap.c:1008 > #10 0xc085cc4f in Xint0x80_syscall () at > ../../../i386/i386/exception.s:190 > #11 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) Very odd indeed. Ah, try the patch at http://www.freebsd.org/~jhb/patches/linux_unload.patch The linux_osname mutex was being destroyed twice. > Running skype-1.2.0.18 for linux will immediately reboot machine without > warring.. That I don't have any good ideas for. Are you in X when it happens? If so, can you hook up a serial console to see if it panics? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Dec 14 17:11:27 2005 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 0D85E16A41F for ; Wed, 14 Dec 2005 17:11:27 +0000 (GMT) (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 8CCE743D68 for ; Wed, 14 Dec 2005 17:11:22 +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/8.13.4) with ESMTP id jBEHAlwI033456; Wed, 14 Dec 2005 09:10:47 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.13.4/8.13.4/Submit) id jBEHAdZ3033442; Wed, 14 Dec 2005 09:10:39 -0800 (PST) Date: Wed, 14 Dec 2005 09:10:39 -0800 (PST) From: Matthew Dillon Message-Id: <200512141710.jBEHAdZ3033442@apollo.backplane.com> To: "Bjoern A. Zeeb" , FreeBSD current mailing list References: <20051209175607.C23668@maildrop.int.zabbadoz.net> <20051210125221.M23668@maildrop.int.zabbadoz.net> <200512130031.jBD0VXih011394@apollo.backplane.com> Cc: Subject: Re: nve(4) patch - please test! 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, 14 Dec 2005 17:11:27 -0000 In addition to moving the nv_setmulti() and nv_ifmedia_upd() calls to a slightly different place in DFly (after pfnInit and before pfnStart), I also noticed that pfnStop() seems to take a flags argument which the header files define AFFECT_RECEIVER and AFFECT_TRANSMITTER for, but both our codes have been calling pfnStop() with a flags argument of 0. I don't know if adding the flags has any effect but it doesn't seem to make things worse. If pfnStop() isn't actually stopping the hardware due to incorrect flags then all sorts of bad things can happen. -Matt From owner-freebsd-current@FreeBSD.ORG Wed Dec 14 17:26:48 2005 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 1B90F16A41F for ; Wed, 14 Dec 2005 17:26:48 +0000 (GMT) (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 42BF043D66 for ; Wed, 14 Dec 2005 17:26:47 +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/8.13.4) with ESMTP id jBEHQFHn033564; Wed, 14 Dec 2005 09:26:15 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.13.4/8.13.4/Submit) id jBEHQFZp033563; Wed, 14 Dec 2005 09:26:15 -0800 (PST) Date: Wed, 14 Dec 2005 09:26:15 -0800 (PST) From: Matthew Dillon Message-Id: <200512141726.jBEHQFZp033563@apollo.backplane.com> To: "Bjoern A. Zeeb" , FreeBSD current mailing list References: <20051209175607.C23668@maildrop.int.zabbadoz.net> <20051210125221.M23668@maildrop.int.zabbadoz.net> <200512130031.jBD0VXih011394@apollo.backplane.com> <200512141710.jBEHAdZ3033442@apollo.backplane.com> Cc: Subject: Re: nve(4) patch - please test! 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, 14 Dec 2005 17:26:48 -0000 : In addition to moving the nv_setmulti() and nv_ifmedia_upd() calls : to a slightly different place in DFly (after pfnInit and before pfnStart), : I also noticed that pfnStop() seems to take a flags argument which the : header files define AFFECT_RECEIVER and AFFECT_TRANSMITTER for, : but both our codes have been calling pfnStop() with a flags argument of : 0. : : I don't know if adding the flags has any effect but it doesn't seem to : make things worse. If pfnStop() isn't actually stopping the hardware : due to incorrect flags then all sorts of bad things can happen. : : -Matt Bah. On the second part the pfnStop() function seems to expect some other type of argument,. 'ucIsPowerDown': typedef NV_API_CALL NV_SINT32 (* PFN_ADAPTER_STOP) (PNV_VOID pvContext, NV_UINT8 ucIsPowerDown); So it is unclear what those AFFECT_* flags refer to. It looks like Nvidia has made changes to the ABI and not cleaned up after themselves. However, for some reason I have not gotten another complete lockup (requiring replugging the physical power cord to fix) since making both changes, so I've decided to leave it in for the moment even though the flags are not likely related to the ucIsPowerDown argument. I also noticed an ABI call which resets the PHY called pfnResetPhyInitState(). It might be worth calling that if the adapter gets stuck. If I can get my adapter to stick again I'll try it. -Matt From owner-freebsd-current@FreeBSD.ORG Wed Dec 14 22:19:42 2005 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 6234116A41F; Wed, 14 Dec 2005 22:19:42 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 47A4643D49; Wed, 14 Dec 2005 22:19:41 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 3819891 for multiple; Wed, 14 Dec 2005 17:17:39 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jBEMJa7M061528; Wed, 14 Dec 2005 17:19:36 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: current@freebsd.org Date: Wed, 14 Dec 2005 17:20:00 -0500 User-Agent: KMail/1.8.2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512141720.01572.jhb@freebsd.org> X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: anholt@freebsd.org Subject: hostb(4) and vgapci(4) 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: Wed, 14 Dec 2005 22:19:42 -0000 I have a patch that is an attempt to untangle a few things in relation to Host-PCI bridges and VGA PCI devices. Basically, the change is to create a more "real" hostb driver as well as a new vgapci driver and to change agp, drm, and acpi_video to attach to these drivers. This means among other things: - In theory you can now kldload agp after boot since it still has a place to attach to. - i830/915 drm is no longer a child of agp, instead both become children of vgapci0. - You can now use acpi_video with drm as both attach as children of vgapci0. - This provides a way for us to possibly solve the DPMS problem for suspend/resume (including a cleaner way to do the hack dpms patch I posted to acpi@ a long while ago that several people still use). Some other details include: - agp devices no longer map the _entire_ aperture into contiguous KVA meaning that it might be possible now to use a 256 MB aperture without panicing - I've added a new pci_if.m method for locating a specific capability for a PCI device. I have tested this on my laptop and verified that dri still works, but it needs some wider testing, especially the i830/i915 case is slightly more complicated. Also, this is not going to work with the nvidia-driver currently, but that's something that can be fixed in the future. If the agp non-mapping does fix the 256 MB aperture issues then I will probably MFC that part to RELENG_6. http://www.FreeBSD.org/~jhb/patches/agp_cvs.patch -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Dec 14 22:27:01 2005 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 EA06016A41F for ; Wed, 14 Dec 2005 22:27:01 +0000 (GMT) (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 E68D143D49 for ; Wed, 14 Dec 2005 22:26:54 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.17.229]) ([10.251.17.229]) by a50.ironport.com with ESMTP; 14 Dec 2005 14:26:52 -0800 X-IronPort-Anti-Spam-Filtered: true Message-ID: <43A09C2C.4020808@elischer.org> Date: Wed, 14 Dec 2005 14:26:52 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: how to change load address. 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, 14 Dec 2005 22:27:02 -0000 In our 4.x systems tHE shared libraries seem to load themselves at around 2G. which makes it hard to mmap objects that are big if they need to span that address range. I've looked around a bit in -currnet as well, but can't see if there is a way to change where the libraries are loaded.. I'd prefer to try move them up by 500MB to give me ore contiguous space below.. anyone know off the top of their head if we can do this? From owner-freebsd-current@FreeBSD.ORG Wed Dec 14 22:47:24 2005 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 D7D9816A41F for ; Wed, 14 Dec 2005 22:47:24 +0000 (GMT) (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 9FD0343D55 for ; Wed, 14 Dec 2005 22:47:24 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.17.229]) ([10.251.17.229]) by a50.ironport.com with ESMTP; 14 Dec 2005 14:47:24 -0800 X-IronPort-Anti-Spam-Filtered: true Message-ID: <43A0A0FC.4090806@elischer.org> Date: Wed, 14 Dec 2005 14:47:24 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <43A09C2C.4020808@elischer.org> In-Reply-To: <43A09C2C.4020808@elischer.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: how to change load address. 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, 14 Dec 2005 22:47:25 -0000 Julian Elischer wrote: > In our 4.x systems tHE shared libraries seem to load themselves at > around 2G. which makes it hard to mmap > objects that are big if they need to span that address range. > > I've looked around a bit in -currnet as well, > but can't see if there is a way to change where the libraries are > loaded.. > I'd prefer to try move them up by 500MB to give me ore contiguous > space below.. > > anyone know off the top of their head if we can do this? responding to myself.. looks like it uses maxdsize as a hint. > _______________________________________________ > 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" From owner-freebsd-current@FreeBSD.ORG Wed Dec 14 23:17:31 2005 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 8BB0B16A41F; Wed, 14 Dec 2005 23:17:31 +0000 (GMT) (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 BA96543D46; Wed, 14 Dec 2005 23:17:30 +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.4/8.13.4) with ESMTP id jBENHK2B004183; Thu, 15 Dec 2005 00:17:20 +0100 Received: from localhost (ggajic@localhost) by afrodita.rcub.bg.ac.yu (8.13.4/8.13.4/Submit) with ESMTP id jBENHINQ004180; Thu, 15 Dec 2005 00:17:19 +0100 Date: Thu, 15 Dec 2005 00:17:18 +0100 (CET) From: Goran Gajic To: John Baldwin In-Reply-To: <200512141106.51839.jhb@freebsd.org> Message-ID: References: <200512141106.51839.jhb@freebsd.org> 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: Wed, 14 Dec 2005 23:28:42 +0000 Cc: freebsd-current@www.freebsd.org Subject: Re: 7.0-CURRENT panic on kldunload linux.ko 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, 14 Dec 2005 23:17:31 -0000 Hi, I have just checked on my home machine and it seems that with your patch both problems have gone. Thanks. Regards, gg. On Wed, 14 Dec 2005, John Baldwin wrote: > > Very odd indeed. Ah, try the patch at > http://www.freebsd.org/~jhb/patches/linux_unload.patch > The linux_osname mutex was being destroyed twice. > >> Running skype-1.2.0.18 for linux will immediately reboot machine without >> warring.. > > That I don't have any good ideas for. Are you in X when it happens? If so, > can you hook up a serial console to see if it panics? > > From owner-freebsd-current@FreeBSD.ORG Thu Dec 15 00:17:39 2005 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 7709616A41F for ; Thu, 15 Dec 2005 00:17:39 +0000 (GMT) (envelope-from arne@rfc2549.org) Received: from dagobah.rfc1149.org (dagobah.rfc1149.org [217.160.170.141]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A9E243D5A for ; Thu, 15 Dec 2005 00:17:38 +0000 (GMT) (envelope-from arne@rfc2549.org) Received: from dslb-084-061-128-100.pools.arcor-ip.net ([84.61.128.100] helo=kamino.rfc1149.org) by dagobah.rfc1149.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 (FreeBSD)) id 1EmgoM-00054m-Fy; Thu, 15 Dec 2005 01:17:34 +0100 Received: from [127.0.0.1] (localhost [127.0.0.1]) by kamino.rfc1149.org (Postfix) with ESMTP id 714A04104; Thu, 15 Dec 2005 01:17:35 +0100 (CET) Message-ID: <43A0B61F.2070007@rfc2549.org> Date: Thu, 15 Dec 2005 01:17:35 +0100 From: Arne Schwabe User-Agent: Thunderbird 1.5 (X11/20051114) MIME-Version: 1.0 To: Sam Leffler References: <439E1030.1080304@errno.com> In-Reply-To: <439E1030.1080304@errno.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RFC-Spam-Score: -1.6 (-) Cc: current@freebsd.org Subject: Re: ath changes: please test 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, 15 Dec 2005 00:17:39 -0000 Sam Leffler wrote: > There's a new hal and patch for the ath driver available for test: > > http://people.freebsd.org/~sam/ath_hal-20051212.tgz > http://people.freebsd.org/~sam/ath.patch > > The patch is against current. I just committed a bunch of net80211 > changes that are required so be sure your system is up to date before > applying the ath patch. > > The changes include: > o updates for the sample rate control algorithm (from madwifi) > o use a private taskq thread > o improved sta mode beacon miss handling > o mcast frames sent at fixed rate (settable with ifconfig) > o adhoc mode beacon timer fixups > o packet capture now includes tsf and calibrated signal data > o dfs wait-for-clear-channel handling (for ap mode) > > This code has been in test for a while and should be fine to use but I > will not commit it until I get feedback. Please send me mail directly. > especially if you see regressions from the current code in cvs or from > the 0.9.16.3 hal snapshot I've had out for several months. > I tested the new hal and works here. I see no regression. ath0: flags=8843 mtu 1500 inet6 fe80::205:4eff:fe41:f327%ath0 prefixlen 64 scopeid 0x3 inet 192.168.42.23 netmask 0xffffff00 broadcast 192.168.42.255 ether 00:05:4e:bl:ab:la media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps) status: associated ssid Wellensalat channel 6 bssid 00:14:bf:1c:34:97 authmode WPA privacy ON deftxkey UNDEF TKIP 2:128-bit txpowmax 34 roaming MANUAL bintval 100 ath0: mem 0xc0210000-0xc021ffff irq 5 at device 2.0 on pci2 ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xc0210000 ath0: [MPSAFE] ath0: bpf attached ath0: Ethernet address: 00:05:4e:fo:ob:ar ath0: bpf attached ath0: bpf attached ath0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps ath0: mac 4.2 phy 3.0 5ghz radio 1.7 2ghz radio 2.3 From owner-freebsd-current@FreeBSD.ORG Thu Dec 15 01:01:55 2005 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 2036E16A41F for ; Thu, 15 Dec 2005 01:01:55 +0000 (GMT) (envelope-from m.r.orlando.1st@sbcglobal.net) Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3101243D55 for ; Thu, 15 Dec 2005 01:01:49 +0000 (GMT) (envelope-from m.r.orlando.1st@sbcglobal.net) X-ORBL: [69.107.226.17] DomainKey-Signature: a=rsa-sha1; s=sbc01; d=sbcglobal.net; c=nofws; q=dns; h=message-id:date:from:user-agent:x-accept-language: mime-version:to:cc:subject:content-type:content-transfer-encoding; b=aKG7sup0Gu+rs+xKRTHaH/SwTqwi5hJqDrmGUsOCvnaQT+0dV4LHav5e0PeJVSJZT RBjD0OopMnlUAVebZxl5g== Received: from [69.107.226.17] (adsl-69-107-226-17.dsl.sndg02.pacbell.net [69.107.226.17]) by pimout3-ext.prodigy.net (8.13.4 outbound domainkey aix/8.13.4) with ESMTP id jBF11k0j149330; Wed, 14 Dec 2005 20:01:47 -0500 Message-ID: <43A0C06C.8070200@sbcglobal.net> Date: Wed, 14 Dec 2005 17:01:32 -0800 From: "Michael R. Orlando" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en To: noackjr@alumni.rice.edu Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 15 Dec 2005 01:19:01 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: DesktopBSD install 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: Thu, 15 Dec 2005 01:01:55 -0000 Jon: I am trying to install DesktopBSD (based on FreeBSD) and when I attempt to boot from the CD burned from v1.0-RC3 X86-CD.ISO (from the DesktopBSD download area), I get t he following message: CD Loader 1.2 Building the boot loader arguments Looking up /BOOT/LOADER... FOUND Read Error: 0X32 Could not find Primary Volume Descriptor Here are the particulars of my system: Shuttle AK12AS04 board (06/08/2001-8363-686-AK12AC-00) AMD Athlon 1.133MHz processor 256 MB memory 30 GB EIDE WD Caviar HD Award BIOS v6.00PG System Commander v7 (multi-boot manager) I have successfully installed multiple versions of DOS, Windows 9x, Win 2000 Pr o, OS/2, and Linux on this system. The most recent post on the DesktopBSD forum under installation says to try again after the release of v3, and that is the version I am attempting to install. Please excuse my ignorance, but is there a directory of error messages, and their meanings that I could consult to determine the cause and possible remedies for the above, as well as other, error messages? ______________________________________________________________________ I have found a prior post which you replied to on the FreeBSD forums, repeated here: ______________________________________________________________________ On 3/24/2004 4:37 PM, Nicolai E M Plum wrote: > Hi > > I am having problems booting FreeBSD 5.2.1-RELEASE on a system I > have. Booting from CD gives me: > > ---- > [other messages from the BIOS] > CD Loader 1.01 > > Building the boot loader arguments > Read Error: 0x01 > Could not find Primary Volume Descriptor > ---- > > Booting from floppies works OK. > > The same happens when trying to boot a CD of 5.1-RC1 that I happen to > still have around. 4.9-RELEASE boots fine from CD. > > Hardware is an older Dell Pentium Pro system, with a Samsung SM-532 > DVD-ROM CD-RW drive. > > Any ideas why this happens? I've worked around it, but it's a bit > awkward. I can't find any details of why it happens in searching mailing > lists. The 5.x bootable install CDs no longer use floppy-emulation mode. The change was made because some newer machines do not support this emulation mode. However, older machines may not be able to boot CDs in "native" (non-emulation) mode. We can't support everybody, so we support the new machines. In many cases a BIOS update will fix this, so you might check for that. Jon ______________________________________________________________________ Do you have any further information that might be helpful here? How can I find the meanings and actions required of any error messages generated during installations or operations? How is the error message I receive (0x32) different from the one in the post you replied to (0x01)? Do you know if the current version I am using is any different from the previous version mentioned in the earlier post in this regard? Whatever you can tell me will be greatly appreciated. Thank you. Sincerely, Michael R. Orlando From owner-freebsd-current@FreeBSD.ORG Thu Dec 15 01:29:52 2005 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 B4F7516A41F for ; Thu, 15 Dec 2005 01:29:52 +0000 (GMT) (envelope-from oceanare@pacific.net.sg) Received: from smtpgate2.pacific.net.sg (smtpgate2.pacific.net.sg [203.120.90.32]) by mx1.FreeBSD.org (Postfix) with SMTP id C0F0B43D55 for ; Thu, 15 Dec 2005 01:29:51 +0000 (GMT) (envelope-from oceanare@pacific.net.sg) Received: (qmail 29724 invoked from network); 15 Dec 2005 01:29:49 -0000 Received: from maxwell2.pacific.net.sg (203.120.90.192) by smtpgate2.pacific.net.sg with SMTP; 15 Dec 2005 01:29:49 -0000 Received: from [192.168.0.107] ([210.24.124.189]) by maxwell2.pacific.net.sg with ESMTP id <20051215012948.LXOD28012.maxwell2.pacific.net.sg@[192.168.0.107]>; Thu, 15 Dec 2005 09:29:48 +0800 Message-ID: <43A0C6CC.5020906@pacific.net.sg> Date: Thu, 15 Dec 2005 09:28:44 +0800 From: Erich Dollansky Organization: oceanare pte ltd User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051204) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Michael R. Orlando" References: <43A0C06C.8070200@sbcglobal.net> In-Reply-To: <43A0C06C.8070200@sbcglobal.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: DesktopBSD install 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: Thu, 15 Dec 2005 01:29:52 -0000 Hi, before are all jumping that this is a FreeBSD list, have you tried to boot with a FreeBSD CD? It could be the case that DesktopBSD did a minor change, if not even more, which affects you. Michael R. Orlando wrote: > The most recent post on the DesktopBSD forum under installation says to > try again after the release of v3, and that is the version I am > attempting to install. > This could be a hint that to many changes are made on this place. Just install FreeBSD if it works with this CD. Erich From owner-freebsd-current@FreeBSD.ORG Thu Dec 15 02:47:39 2005 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 A7DD616A41F for ; Thu, 15 Dec 2005 02:47:39 +0000 (GMT) (envelope-from konfer@mikulas.com) Received: from s1.vhost.cz (s1.vhost.cz [82.208.27.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE5D843D55 for ; Thu, 15 Dec 2005 02:47:38 +0000 (GMT) (envelope-from konfer@mikulas.com) Received: (qmail 73174 invoked by alias); 15 Dec 2005 03:47:36 +0100 Received: from unknown (HELO localhost) (127.10.10.10) by s1.vhost.cz with SMTP; 15 Dec 2005 03:47:36 +0100 Received: from unknown ([127.0.0.1]) by localhost (s1.vhost.cz [127.0.0.1]) (amavisd-new, port 10628) id 67981-10; Thu, 15 Dec 2005 03:47:35 +0100 (CET) Received: from unknown (HELO ?195.122.218.78?) (jiri@mikulas.com@195.122.218.78) by s1.vhost.cz with AES256-SHA encrypted SMTP; 15 Dec 2005 03:47:35 +0100 Message-ID: <43A0D946.1040303@mikulas.com> Date: Thu, 15 Dec 2005 03:47:34 +0100 From: Jiri Mikulas User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051129) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Leffler References: <439E1030.1080304@errno.com> In-Reply-To: <439E1030.1080304@errno.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at vhost.cz Cc: current@freebsd.org Subject: Re: ath changes: please test 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, 15 Dec 2005 02:47:39 -0000 Hello THAKS! for your work :) I tested simple client config without problems I'll test it in hostap mode later. FreeBSD 7.0-CURRENT #0: Wed Dec 14 16:19:52 CET 2005 ifconfig_ath0="10.27.130.1/29 ssid PL2BH media autoselect mode 11a up" ath0: flags=8843 mtu 1500 inet6 fe80::290:4bff:fe7e:4118%ath0 prefixlen 64 scopeid 0x3 inet 10.27.130.1 netmask 0xfffffff8 broadcast 10.27.130.7 ether 00:90:4b:7e:41:18 media: IEEE 802.11 Wireless Ethernet autoselect mode 11a (OFDM/18Mbps) status: associated ssid PL2BH channel 120 (5600) bssid 00:80:48:3a:18:15 authmode OPEN privacy OFF deftxkey UNDEF powersavemode OFF powersavesleep 100 txpowmax 35 txpower 63 rtsthreshold 2346 mcastrate 1 fragthreshold 2346 -pureg protmode CTS -wme roaming AUTO bintval 100 ath0: mem 0xe7100000-0xe710ffff irq 10 at device 11.0 on pci0 ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xe7100000 ath0: [MPSAFE] ath0: bpf attached ath0: Ethernet address: 00:90:4b:7e:41:18 ath0: bpf attached ath0: bpf attached ath0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps ath0: turboA rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps ath0: mac 5.9 phy 4.3 radio 3.6 ath0: Use hw queue 1 for WME_AC_BE traffic ath0: Use hw queue 0 for WME_AC_BK traffic ath0: Use hw queue 2 for WME_AC_VI traffic ath0: Use hw queue 3 for WME_AC_VO traffic ath0: Use hw queue 8 for CAB traffic ath0: Use hw queue 9 for beacons Jiri Sam Leffler wrote: > There's a new hal and patch for the ath driver available for test: > > http://people.freebsd.org/~sam/ath_hal-20051212.tgz > http://people.freebsd.org/~sam/ath.patch > > The patch is against current. I just committed a bunch of net80211 > changes that are required so be sure your system is up to date before > applying the ath patch. > > The changes include: > o updates for the sample rate control algorithm (from madwifi) > o use a private taskq thread > o improved sta mode beacon miss handling > o mcast frames sent at fixed rate (settable with ifconfig) > o adhoc mode beacon timer fixups > o packet capture now includes tsf and calibrated signal data > o dfs wait-for-clear-channel handling (for ap mode) > > This code has been in test for a while and should be fine to use but I > will not commit it until I get feedback. Please send me mail directly. > especially if you see regressions from the current code in cvs or from > the 0.9.16.3 hal snapshot I've had out for several months. > > All this stuff will eventually make it to RELENG_6 but not for a bit. > > Sam From owner-freebsd-current@FreeBSD.ORG Thu Dec 15 03:32:49 2005 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 AADF316A41F; Thu, 15 Dec 2005 03:32:49 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BF1543D79; Thu, 15 Dec 2005 03:32:38 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [192.168.42.22] (andersonbox2.centtech.com [192.168.42.22]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id jBF3Wb1H071007; Wed, 14 Dec 2005 21:32:37 -0600 (CST) (envelope-from anderson@centtech.com) Message-ID: <43A0E3B3.6030903@centtech.com> Date: Wed, 14 Dec 2005 21:32:03 -0600 From: Eric Anderson User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051204) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <200512141720.01572.jhb@freebsd.org> In-Reply-To: <200512141720.01572.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/1209/Mon Dec 12 09:48:01 2005 on mh2.centtech.com X-Virus-Status: Clean Cc: anholt@freebsd.org, current@freebsd.org Subject: Re: hostb(4) and vgapci(4) 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: Thu, 15 Dec 2005 03:32:49 -0000 John Baldwin wrote: >I have a patch that is an attempt to untangle a few things in relation to >Host-PCI bridges and VGA PCI devices. Basically, the change is to create a >more "real" hostb driver as well as a new vgapci driver and to change agp, >drm, and acpi_video to attach to these drivers. This means among other >things: > >- In theory you can now kldload agp after boot since it still has a place to >attach to. >- i830/915 drm is no longer a child of agp, instead both become children of >vgapci0. >- You can now use acpi_video with drm as both attach as children of vgapci0. >- This provides a way for us to possibly solve the DPMS problem for >suspend/resume (including a cleaner way to do the hack dpms patch I posted to >acpi@ a long while ago that several people still use). > >Some other details include: > >- agp devices no longer map the _entire_ aperture into contiguous KVA meaning >that it might be possible now to use a 256 MB aperture without panicing >- I've added a new pci_if.m method for locating a specific capability for a >PCI device. > >I have tested this on my laptop and verified that dri still works, but it >needs some wider testing, especially the i830/i915 case is slightly more >complicated. Also, this is not going to work with the nvidia-driver >currently, but that's something that can be fixed in the future. If the agp >non-mapping does fix the 256 MB aperture issues then I will probably MFC that >part to RELENG_6. > >http://www.FreeBSD.org/~jhb/patches/agp_cvs.patch > > cc -c -O2 -pipe -fno-strict-aliasing -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/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 /usr/src/sys/pci/agp_i810.c /usr/src/sys/pci/agp_i810.c: In function `agp_i810_detach': /usr/src/sys/pci/agp_i810.c:463: warning: unused variable `child' *** Error code 1 Stop in /usr/obj/usr/src/sys/NEUTRINO. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. 7.0-CURRENT #48: Tue Dec 13 08:47:11 CST 2005 Anything else you would like? Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Thu Dec 15 05:31:03 2005 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 5FF7416A41F; Thu, 15 Dec 2005 05:31:03 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from mail.united-ware.com (am-productions.biz [69.61.164.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC32243D55; Thu, 15 Dec 2005 05:31:02 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.100] (am-productions.biz [69.61.164.22]) (authenticated bits=0) by mail.united-ware.com (8.13.4/8.13.4) with ESMTP id jBF5Xua6034094 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 15 Dec 2005 00:34:02 -0500 (EST) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: John Baldwin Date: Thu, 15 Dec 2005 00:32:54 -0500 User-Agent: KMail/1.8.3 References: <200512141720.01572.jhb@freebsd.org> In-Reply-To: <200512141720.01572.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1399242.3eh9Zmd3ga"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200512150033.13676.mistry.7@osu.edu> X-Spam-Status: No, score=-8.9 required=5.0 tests=ALL_TRUSTED,BAYES_05, MYFREEBSD2,MYFREEBSD3 autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on mail.united-ware.com X-Virus-Scanned: ClamAV 0.87/1209/Mon Dec 12 10:48:01 2005 on mail.united-ware.com X-Virus-Status: Clean Cc: freebsd-current@freebsd.org Subject: Re: hostb(4) and vgapci(4) 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: Thu, 15 Dec 2005 05:31:03 -0000 --nextPart1399242.3eh9Zmd3ga Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 14 December 2005 05:20 pm, John Baldwin wrote: > I have a patch that is an attempt to untangle a few things in > relation to Host-PCI bridges and VGA PCI devices. Basically, the > change is to create a more "real" hostb driver as well as a new > vgapci driver and to change agp, drm, and acpi_video to attach to > these drivers. This means among other things: > > - In theory you can now kldload agp after boot since it still has a > place to attach to. > - i830/915 drm is no longer a child of agp, instead both become > children of vgapci0. > - You can now use acpi_video with drm as both attach as children of > vgapci0. - This provides a way for us to possibly solve the DPMS > problem for suspend/resume (including a cleaner way to do the hack > dpms patch I posted to acpi@ a long while ago that several people > still use). > > Some other details include: > > - agp devices no longer map the _entire_ aperture into contiguous > KVA meaning that it might be possible now to use a 256 MB aperture > without panicing - I've added a new pci_if.m method for locating a > specific capability for a PCI device. > > I have tested this on my laptop and verified that dri still works, > but it needs some wider testing, especially the i830/i915 case is > slightly more complicated. Also, this is not going to work with > the nvidia-driver currently, but that's something that can be fixed > in the future. If the agp non-mapping does fix the 256 MB aperture > issues then I will probably MFC that part to RELENG_6. > > http://www.FreeBSD.org/~jhb/patches/agp_cvs.patch Thank you! It seems to work as advertised. I'm running mach64 DRM=20 with the DPMS patch acpi_video and they both work. :) One small problem though. When I unload the acpi_video module and=20 reload it I get the following: littleguy# kldload acpi_video acpi_video0: on vgapci0 acpi_video1: on vgapci0 littleguy# kldunload acpi_video acpi_video0: detached acpi_video1: detached littleguy# kldunload acpi_video kldunload: can't find file acpi_video: No such file or directory littleguy# kldload acpi_video acpi_video0: on vgapci0 acpi_video1: on vgapci0 acpi_video2: on vgapci0 littleguy# It also created multiple sysctls with subsequent loads: hw.acpi.video.crt0.active: 1 hw.acpi.video.lcd0.active: 1 hw.acpi.video.tv0.active: 0 hw.acpi.video.crt1.active: 1 hw.acpi.video.lcd1.active: 1 hw.acpi.video.tv1.active: 0 hw.acpi.video.crt2.active: 1 hw.acpi.video.lcd2.active: 1 hw.acpi.video.tv2.active: 0 =2D-=20 Anish Mistry --nextPart1399242.3eh9Zmd3ga Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDoQAZxqA5ziudZT0RAt/jAJ0fT9i3K6lMIgrmssjEL0bJ5QA+rQCeJHBA iBAu+5N4SHhzpIlT6Uh5BME= =GfZl -----END PGP SIGNATURE----- --nextPart1399242.3eh9Zmd3ga-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 15 10:04:31 2005 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 64CB916A41F; Thu, 15 Dec 2005 10:04:31 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id B293043D4C; Thu, 15 Dec 2005 10:04:30 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id jBFA4SC0094132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Dec 2005 13:04:29 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id jBFA4SvU094131; Thu, 15 Dec 2005 13:04:28 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 15 Dec 2005 13:04:28 +0300 From: Gleb Smirnoff To: current@FreeBSD.org, rodrigc@FreeBSD.org Message-ID: <20051215100428.GW59644@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.6i Cc: Subject: mount_nfs no longer blocks 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, 15 Dec 2005 10:04:31 -0000 On my testbox, that tracks -CURRENT I've noticed the following regression: NFS systems are not mounted at boot, probably because interface (or switch port) is not up at this moment. Before that the mount blocked for a few seconds until links comes up. This is how it looks now: Mounting NFS file systems:mount_nfs: jujik.ramtel.ru: hostname nor servname provided, or not known mount_nfs: jujik.ramtel.ru: hostname nor servname provided, or not known mount_nfs: jujik.ramtel.ru: hostname nor servname provided, or not known mount_nfs: jujik.ramtel.ru: hostname nor servname provided, or not known The corresponding fstab lines are: jujik.ramtel.ru:/usr/home/ncvs /usr/home/ncvs nfs ro,noexec,soft,intr 0 0 jujik.ramtel.ru:/usr/home/glebius /usr/home/glebius nfs rw,soft,intr 0 0 jujik.ramtel.ru:/usr/src /usr/src nfs ro,soft,intr 0 0 jujik.ramtel.ru:/usr/obj /usr/obj nfs ro,soft,intr 0 0 -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Thu Dec 15 09:44:25 2005 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 AE93316A41F; Thu, 15 Dec 2005 09:44:25 +0000 (GMT) (envelope-from wsk@gddsn.org.cn) Received: from gddsn.org.cn (gddsn.org.cn [218.19.164.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id AEC3843D53; Thu, 15 Dec 2005 09:44:24 +0000 (GMT) (envelope-from wsk@gddsn.org.cn) Received: from [192.168.168.138] (unknown [192.168.168.138]) by gddsn.org.cn (Postfix) with ESMTP id 66B1A38CB41; Thu, 15 Dec 2005 17:44:22 +0800 (CST) Message-ID: <43A13AF6.90003@gddsn.org.cn> Date: Thu, 15 Dec 2005 17:44:22 +0800 From: wsk User-Agent: Thunderbird 1.5 (X11/20051128) MIME-Version: 1.0 To: current@freebsd.org, hardware@freebsd.org, stable@freebsd.org Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 15 Dec 2005 12:57:20 +0000 Cc: Subject: Can support Intel's E8500 chipset on freebsd??? 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, 15 Dec 2005 09:44:25 -0000 lists: with DELL PE6850, It seems 6.0 Can't support the Intel's E8500 XMB chipset pciconf -lv: none0@pci0:9:0: class=0x050000 card=0x01701028 chip=0x26208086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'E8500 XMB A/B/C/D Identification Registers' class = memory subclass = RAM none1@pci0:9:1: class=0x050000 card=0x01701028 chip=0x26218086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'E8500 XMB A/B/C/D Miscellaneous Registers' class = memory subclass = RAM none2@pci0:9:2: class=0x050000 card=0x01701028 chip=0x26228086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'E8500 XMB A/B/C/D Memory Interleaving Registers' class = memory subclass = RAM dmesg: %dmesg Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.0-RELEASE #0: Fri Dec 16 00:54:34 CST 2005 wsk@wfdb2.gddsn.org.cn:/usr/obj/usr/src/sys/WFDB2 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) MP CPU 3.00GHz (2995.52-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0xf41 Stepping = 1 Features=0xbfebfbff Features2=0x659d> AMD Features=0x20100800 real memory = 9395240960 (8960 MB) avail memory = 8288649216 (7904 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 6 cpu2 (AP): APIC ID: 8 cpu3 (AP): APIC ID: 14 ioapic1: Changing APIC ID to 1 ioapic1: WARNING: intbase 32 != expected base 24 ioapic2: Changing APIC ID to 2 ioapic2: WARNING: intbase 64 != expected base 56 ioapic3: Changing APIC ID to 3 ioapic3: WARNING: intbase 96 != expected base 88 ioapic4: Changing APIC ID to 4 ioapic4: WARNING: intbase 128 != expected base 120 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 32-55 on motherboard ioapic2 irqs 64-87 on motherboard ioapic3 irqs 96-119 on motherboard ioapic4 irqs 128-151 on motherboard acpi0: on motherboard acpi0: Power Button (fixed) pci_link0: irq 11 on acpi0 pci_link1: irq 11 on acpi0 pci_link2: irq 5 on acpi0 pci_link3: irq 10 on acpi0 pci_link4: on acpi0 pci_link5: on acpi0 pci_link6: on acpi0 pci_link7: irq 3 on acpi0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pcib2: at device 2.0 on pci0 pci4: on pcib2 pcib3: at device 3.0 on pci0 pci7: on pcib3 pcib4: at device 4.0 on pci0 pci8: on pcib4 pcib5: at device 5.0 on pci0 pci11: on pcib5 pcib6: at device 6.0 on pci0 pci14: on pcib6 pcib7: mem 0xdf6ff000-0xdf6fffff at device 0.0 on pci14 pci15: on pcib7 pcib8: at device 0.2 on pci14 pci18: on pcib8 bge0: mem 0xdf8f0000-0xdf8fffff irq 64 at device 2.0 on pci18 miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge0: Ethernet address: 00:12:3f:ff:81:47 bge1: mem 0xdf8e0000-0xdf8effff irq 65 at device 2.1 on pci18 miibus1: on bge1 brgphy1: on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge1: Ethernet address: 00:12:3f:ff:81:48 pcib9: at device 7.0 on pci0 pci19: on pcib9 pcib10: at device 0.0 on pci19 pci20: on pcib10 amr0: mem 0xdd0f0000-0xdd0fffff,0xdf4c0000-0xdf4fffff irq 110 at device 14.0 on pci20 amr0: Firmware 521S, BIOS H430, 256MB RAM pcib11: at device 0.2 on pci19 pci21: on pcib11 pci0: at device 9.0 (no driver attached) pci0: at device 9.1 (no driver attached) pci0: at device 9.2 (no driver attached) pci0: at device 9.3 (no driver attached) pci0: at device 9.4 (no driver attached) pci0: at device 9.5 (no driver attached) pci0: at device 9.6 (no driver attached) pci0: at device 9.7 (no driver attached) pci0: at device 11.0 (no driver attached) pci0: at device 11.1 (no driver attached) pci0: at device 11.2 (no driver attached) pci0: at device 11.3 (no driver attached) pci0: at device 11.4 (no driver attached) pci0: at device 11.5 (no driver attached) pci0: at device 11.6 (no driver attached) pci0: at device 11.7 (no driver attached) pci0: at device 13.0 (no driver attached) pci0: at device 13.1 (no driver attached) pci0: at device 13.2 (no driver attached) pci0: at device 13.3 (no driver attached) pci0: at device 13.4 (no driver attached) pci0: at device 13.5 (no driver attached) pci0: at device 13.6 (no driver attached) pci0: at device 13.7 (no driver attached) pci0: at device 15.0 (no driver attached) pci0: at device 15.1 (no driver attached) pci0: at device 15.2 (no driver attached) pci0: at device 15.3 (no driver attached) pci0: at device 15.4 (no driver attached) pci0: at device 15.5 (no driver attached) pci0: at device 15.6 (no driver attached) pci0: at device 15.7 (no driver attached) uhci0: port 0x6ce0-0x6cff irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x6cc0-0x6cdf irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x6ca0-0x6cbf irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xdff00000-0xdff003ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub3: 6 ports with 6 removable, self powered uhub4: vendor 0x413c product 0xa001, class 9/0, rev 2.00/0.00, addr 2 uhub4: multiple transaction translators uhub4: 2 ports with 2 removable, self powered pcib12: at device 30.0 on pci0 pci22: on pcib12 pci22: at device 0.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A orm0: at iomem 0xc0000-0xc9fff,0xca000-0xcafff,0xcb000-0xcc7ff,0xec000-0xeffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 ppc0: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ums0: vendor 0x413c product 0x3010, rev 2.00/2.20, addr 2, iclass 3/1 ums0: 3 buttons and Z dir. ukbd0: Dell Dell USB Keyboard, rev 1.10/2.00, addr 3, iclass 3/1 kbd0 at ukbd0 Timecounters tick every 1.000 msec acd0: DVDROM at ata0-master UDMA33 amrd0: on amr0 amrd0: 1144320MB (2343567360 sectors) RAID 5 (optimal) ses0 at amr0 bus 0 target 6 lun 0 ses0: Fixed Processor SCSI-2 device ses0: SAF-TE Compliant Device SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! Trying to mount root from ufs:/dev/amrd0s1a bge0: link state changed to UP any ideas?? TIA From owner-freebsd-current@FreeBSD.ORG Thu Dec 15 14:51:58 2005 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 99EFA16A41F; Thu, 15 Dec 2005 14:51:58 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B32043D49; Thu, 15 Dec 2005 14:51:57 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 3864196 for multiple; Thu, 15 Dec 2005 09:49:56 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jBFEpqRv069483; Thu, 15 Dec 2005 09:51:52 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hardware@freebsd.org Date: Thu, 15 Dec 2005 09:52:20 -0500 User-Agent: KMail/1.8.2 References: <43A13AF6.90003@gddsn.org.cn> In-Reply-To: <43A13AF6.90003@gddsn.org.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512150952.22302.jhb@freebsd.org> X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: stable@freebsd.org, current@freebsd.org, wsk , hardware@freebsd.org Subject: Re: Can support Intel's E8500 chipset on freebsd??? 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, 15 Dec 2005 14:51:58 -0000 On Thursday 15 December 2005 04:44 am, wsk wrote: > lists: > with DELL PE6850, It seems 6.0 Can't support the > Intel's E8500 XMB chipset What doesn't work? > pciconf -lv: > none0@pci0:9:0: class=0x050000 card=0x01701028 chip=0x26208086 rev=0x00 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'E8500 XMB A/B/C/D Identification Registers' > class = memory > subclass = RAM These types of devices don't need a driver to work. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Dec 15 16:31:46 2005 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 F0F1016A420 for ; Thu, 15 Dec 2005 16:31:46 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9ACF443D86 for ; Thu, 15 Dec 2005 16:31:40 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 3869968 for multiple; Thu, 15 Dec 2005 11:29:19 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jBFGV0tE070021; Thu, 15 Dec 2005 11:31:05 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Goran Gajic Date: Thu, 15 Dec 2005 11:31:29 -0500 User-Agent: KMail/1.8.2 References: <200512141106.51839.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512151131.29895.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1210/Thu Dec 15 10:23:22 2005 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: freebsd-current@www.freebsd.org Subject: Re: 7.0-CURRENT panic on kldunload linux.ko 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, 15 Dec 2005 16:31:47 -0000 On Wednesday 14 December 2005 06:17 pm, Goran Gajic wrote: > Hi, > > I have just checked on my home machine and it seems that with your patch > both problems have gone. Thanks. Ok, thanks for testing. > Regards, > gg. > > On Wed, 14 Dec 2005, John Baldwin wrote: > > Very odd indeed. Ah, try the patch at > > http://www.freebsd.org/~jhb/patches/linux_unload.patch > > The linux_osname mutex was being destroyed twice. > > > >> Running skype-1.2.0.18 for linux will immediately reboot machine without > >> warring.. > > > > That I don't have any good ideas for. Are you in X when it happens? If > > so, can you hook up a serial console to see if it panics? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Dec 15 16:01:07 2005 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 3AA0216A41F for ; Thu, 15 Dec 2005 16:01:07 +0000 (GMT) (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 3D2F943D60 for ; Thu, 15 Dec 2005 16:01:03 +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.4/8.13.4) with ESMTP id jBFG0h68013369 for ; Thu, 15 Dec 2005 17:00:43 +0100 Received: from localhost (ggajic@localhost) by afrodita.rcub.bg.ac.yu (8.13.4/8.13.4/Submit) with ESMTP id jBFG0cf4013362 for ; Thu, 15 Dec 2005 17:00:43 +0100 Date: Thu, 15 Dec 2005 17:00:38 +0100 (CET) From: Goran Gajic To: freebsd-current@www.freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1536391169-1648064527-1134662438=:12379" 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, 15 Dec 2005 17:45:41 +0000 Cc: Subject: skype-1.2.0.18-static for linux and FreeBSD 7.0 CURRENT 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, 15 Dec 2005 16:01:07 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1536391169-1648064527-1134662438=:12379 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Hi, I have figgured out, adding: options DEBUG_LOCKS options DEBUG_VFS_LOCKS to the GENERIC config will efectevly cause skype to reboot 7.0-CURRENT when username and password are entered at skype login. this has nothing to do with panic caused by kldunload linux.ko I have reported earlier. Reagrds, Goran Gajic --1536391169-1648064527-1134662438=:12379 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=TEST Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=TEST Iw0KIyBHRU5FUklDIC0tIEdlbmVyaWMga2VybmVsIGNvbmZpZ3VyYXRpb24g ZmlsZSBmb3IgRnJlZUJTRC9pMzg2DQojDQojIEZvciBtb3JlIGluZm9ybWF0 aW9uIG9uIHRoaXMgZmlsZSwgcGxlYXNlIHJlYWQgdGhlIGhhbmRib29rIHNl Y3Rpb24gb24NCiMgS2VybmVsIENvbmZpZ3VyYXRpb24gRmlsZXM6DQojDQoj ICAgIGh0dHA6Ly93d3cuRnJlZUJTRC5vcmcvZG9jL2VuX1VTLklTTzg4NTkt MS9ib29rcy9oYW5kYm9vay9rZXJuZWxjb25maWctY29uZmlnLmh0bWwNCiMN CiMgVGhlIGhhbmRib29rIGlzIGFsc28gYXZhaWxhYmxlIGxvY2FsbHkgaW4g L3Vzci9zaGFyZS9kb2MvaGFuZGJvb2sNCiMgaWYgeW91J3ZlIGluc3RhbGxl ZCB0aGUgZG9jIGRpc3RyaWJ1dGlvbiwgb3RoZXJ3aXNlIGFsd2F5cyBzZWUg dGhlDQojIEZyZWVCU0QgV29ybGQgV2lkZSBXZWIgc2VydmVyIChodHRwOi8v d3d3LkZyZWVCU0Qub3JnLykgZm9yIHRoZQ0KIyBsYXRlc3QgaW5mb3JtYXRp b24uDQojDQojIEFuIGV4aGF1c3RpdmUgbGlzdCBvZiBvcHRpb25zIGFuZCBt b3JlIGRldGFpbGVkIGV4cGxhbmF0aW9ucyBvZiB0aGUNCiMgZGV2aWNlIGxp bmVzIGlzIGFsc28gcHJlc2VudCBpbiB0aGUgLi4vLi4vY29uZi9OT1RFUyBh bmQgTk9URVMgZmlsZXMuDQojIElmIHlvdSBhcmUgaW4gZG91YnQgYXMgdG8g dGhlIHB1cnBvc2Ugb3IgbmVjZXNzaXR5IG9mIGEgbGluZSwgY2hlY2sgZmly c3QNCiMgaW4gTk9URVMuDQojDQojICRGcmVlQlNEOiBzcmMvc3lzL2kzODYv Y29uZi9HRU5FUklDLHYgMS40MzYgMjAwNS8xMS8yNyAyMzoxNjo1OCBydSBF eHAgJA0KDQpjcHUJCUk0ODZfQ1BVDQpjcHUJCUk1ODZfQ1BVDQpjcHUJCUk2 ODZfQ1BVDQppZGVudAkJR0VORVJJQw0KDQojIFRvIHN0YXRpY2FsbHkgY29t cGlsZSBpbiBkZXZpY2Ugd2lyaW5nIGluc3RlYWQgb2YgL2Jvb3QvZGV2aWNl LmhpbnRzDQojaGludHMJCSJHRU5FUklDLmhpbnRzIgkJIyBEZWZhdWx0IHBs YWNlcyB0byBsb29rIGZvciBkZXZpY2VzLg0KDQptYWtlb3B0aW9ucwlERUJV Rz0tZwkJIyBCdWlsZCBrZXJuZWwgd2l0aCBnZGIoMSkgZGVidWcgc3ltYm9s cw0KDQojb3B0aW9ucyAJU0NIRURfVUxFCQkjIFVMRSBzY2hlZHVsZXINCm9w dGlvbnMgCVNDSEVEXzRCU0QJCSMgNEJTRCBzY2hlZHVsZXINCm9wdGlvbnMg CVBSRUVNUFRJT04JCSMgRW5hYmxlIGtlcm5lbCB0aHJlYWQgcHJlZW1wdGlv bg0Kb3B0aW9ucyAJSU5FVAkJCSMgSW50ZXJORVR3b3JraW5nDQpvcHRpb25z IAlJTkVUNgkJCSMgSVB2NiBjb21tdW5pY2F0aW9ucyBwcm90b2NvbHMNCm9w dGlvbnMgCUZGUwkJCSMgQmVya2VsZXkgRmFzdCBGaWxlc3lzdGVtDQpvcHRp b25zIAlTT0ZUVVBEQVRFUwkJIyBFbmFibGUgRkZTIHNvZnQgdXBkYXRlcyBz dXBwb3J0DQpvcHRpb25zIAlVRlNfQUNMCQkJIyBTdXBwb3J0IGZvciBhY2Nl c3MgY29udHJvbCBsaXN0cw0Kb3B0aW9ucyAJVUZTX0RJUkhBU0gJCSMgSW1w cm92ZSBwZXJmb3JtYW5jZSBvbiBiaWcgZGlyZWN0b3JpZXMNCm9wdGlvbnMg CU1EX1JPT1QJCQkjIE1EIGlzIGEgcG90ZW50aWFsIHJvb3QgZGV2aWNlDQpv cHRpb25zIAlORlNDTElFTlQJCSMgTmV0d29yayBGaWxlc3lzdGVtIENsaWVu dA0Kb3B0aW9ucyAJTkZTU0VSVkVSCQkjIE5ldHdvcmsgRmlsZXN5c3RlbSBT ZXJ2ZXINCm9wdGlvbnMgCU5GU19ST09UCQkjIE5GUyB1c2FibGUgYXMgLywg cmVxdWlyZXMgTkZTQ0xJRU5UDQpvcHRpb25zIAlNU0RPU0ZTCQkJIyBNU0RP UyBGaWxlc3lzdGVtDQpvcHRpb25zIAlDRDk2NjAJCQkjIElTTyA5NjYwIEZp bGVzeXN0ZW0NCm9wdGlvbnMgCVBST0NGUwkJCSMgUHJvY2VzcyBmaWxlc3lz dGVtIChyZXF1aXJlcyBQU0VVRE9GUykNCm9wdGlvbnMgCVBTRVVET0ZTCQkj IFBzZXVkby1maWxlc3lzdGVtIGZyYW1ld29yaw0Kb3B0aW9ucyAJR0VPTV9H UFQJCSMgR1VJRCBQYXJ0aXRpb24gVGFibGVzLg0Kb3B0aW9ucyAJQ09NUEFU XzQzCQkjIENvbXBhdGlibGUgd2l0aCBCU0QgNC4zIFtLRUVQIFRISVMhXQ0K b3B0aW9ucyAJQ09NUEFUX0ZSRUVCU0Q0CQkjIENvbXBhdGlibGUgd2l0aCBG cmVlQlNENA0Kb3B0aW9ucyAJQ09NUEFUX0ZSRUVCU0Q1CQkjIENvbXBhdGli bGUgd2l0aCBGcmVlQlNENQ0Kb3B0aW9ucyAJU0NTSV9ERUxBWT01MDAwCQkj IERlbGF5IChpbiBtcykgYmVmb3JlIHByb2JpbmcgU0NTSQ0Kb3B0aW9ucyAJ S1RSQUNFCQkJIyBrdHJhY2UoMSkgc3VwcG9ydA0Kb3B0aW9ucyAJU1lTVlNI TQkJCSMgU1lTVi1zdHlsZSBzaGFyZWQgbWVtb3J5DQpvcHRpb25zIAlTWVNW TVNHCQkJIyBTWVNWLXN0eWxlIG1lc3NhZ2UgcXVldWVzDQpvcHRpb25zIAlT WVNWU0VNCQkJIyBTWVNWLXN0eWxlIHNlbWFwaG9yZXMNCm9wdGlvbnMgCV9L UE9TSVhfUFJJT1JJVFlfU0NIRURVTElORyAjIFBPU0lYIFAxMDAzXzFCIHJl YWwtdGltZSBleHRlbnNpb25zDQpvcHRpb25zIAlLQkRfSU5TVEFMTF9DREVW CSMgaW5zdGFsbCBhIENERVYgZW50cnkgaW4gL2Rldg0Kb3B0aW9ucyAJQUhD X1JFR19QUkVUVFlfUFJJTlQJIyBQcmludCByZWdpc3RlciBiaXRmaWVsZHMg aW4gZGVidWcNCgkJCQkJIyBvdXRwdXQuICBBZGRzIH4xMjhrIHRvIGRyaXZl ci4NCm9wdGlvbnMgCUFIRF9SRUdfUFJFVFRZX1BSSU5UCSMgUHJpbnQgcmVn aXN0ZXIgYml0ZmllbGRzIGluIGRlYnVnDQoJCQkJCSMgb3V0cHV0LiAgQWRk cyB+MjE1ayB0byBkcml2ZXIuDQpvcHRpb25zIAlBREFQVElWRV9HSUFOVAkJ IyBHaWFudCBtdXRleCBpcyBhZGFwdGl2ZS4NCm9wdGlvbnMgCVNUT1BfTk1J CQkjIFN0b3AgQ1BVUyB1c2luZyBOTUkgaW5zdGVhZCBvZiBJUEkNCg0KIyBE ZWJ1Z2dpbmcgZm9yIHVzZSBpbiAtY3VycmVudA0Kb3B0aW9ucyAJS0RCCQkJ IyBFbmFibGUga2VybmVsIGRlYnVnZ2VyIHN1cHBvcnQuDQpvcHRpb25zIAlE REIJCQkjIFN1cHBvcnQgRERCLg0Kb3B0aW9ucyAJR0RCCQkJIyBTdXBwb3J0 IHJlbW90ZSBHREIuDQpvcHRpb25zIAlJTlZBUklBTlRTCQkjIEVuYWJsZSBj YWxscyBvZiBleHRyYSBzYW5pdHkgY2hlY2tpbmcNCm9wdGlvbnMgCUlOVkFS SUFOVF9TVVBQT1JUCSMgRXh0cmEgc2FuaXR5IGNoZWNrcyBvZiBpbnRlcm5h bCBzdHJ1Y3R1cmVzLCByZXF1aXJlZCBieSBJTlZBUklBTlRTDQpvcHRpb25z IAlXSVRORVNTCQkJIyBFbmFibGUgY2hlY2tzIHRvIGRldGVjdCBkZWFkbG9j a3MgYW5kIGN5Y2xlcw0Kb3B0aW9ucyAJV0lUTkVTU19TS0lQU1BJTgkjIERv bid0IHJ1biB3aXRuZXNzIG9uIHNwaW5sb2NrcyBmb3Igc3BlZWQNCg0KIyBU byBtYWtlIGFuIFNNUCBrZXJuZWwsIHRoZSBuZXh0IHR3byBsaW5lcyBhcmUg bmVlZGVkDQojb3B0aW9ucyAJU01QCQkJIyBTeW1tZXRyaWMgTXVsdGlQcm9j ZXNzb3IgS2VybmVsDQpkZXZpY2UJCWFwaWMJCQkjIEkvTyBBUElDDQoNCiMg QnVzIHN1cHBvcnQuDQpkZXZpY2UJCWVpc2ENCmRldmljZQkJcGNpDQoNCiMg RmxvcHB5IGRyaXZlcw0KZGV2aWNlCQlmZGMNCg0KIyBBVEEgYW5kIEFUQVBJ IGRldmljZXMNCmRldmljZQkJYXRhDQpkZXZpY2UJCWF0YWRpc2sJCSMgQVRB IGRpc2sgZHJpdmVzDQpkZXZpY2UJCWF0YXJhaWQJCSMgQVRBIFJBSUQgZHJp dmVzDQpkZXZpY2UJCWF0YXBpY2QJCSMgQVRBUEkgQ0RST00gZHJpdmVzDQpk ZXZpY2UJCWF0YXBpZmQJCSMgQVRBUEkgZmxvcHB5IGRyaXZlcw0KZGV2aWNl CQlhdGFwaXN0CQkjIEFUQVBJIHRhcGUgZHJpdmVzDQpvcHRpb25zIAlBVEFf U1RBVElDX0lECSMgU3RhdGljIGRldmljZSBudW1iZXJpbmcNCg0KIyBTQ1NJ IENvbnRyb2xsZXJzDQpkZXZpY2UJCWFoYgkJIyBFSVNBIEFIQTE3NDIgZmFt aWx5DQpkZXZpY2UJCWFoYwkJIyBBSEEyOTQwIGFuZCBvbmJvYXJkIEFJQzd4 eHggZGV2aWNlcw0KZGV2aWNlCQlhaGQJCSMgQUhBMzkzMjAvMjkzMjAgYW5k IG9uYm9hcmQgQUlDNzl4eCBkZXZpY2VzDQpkZXZpY2UJCWFtZAkJIyBBTUQg NTNDOTc0IChUZWtyYW0gREMtMzkwKFQpKQ0KZGV2aWNlCQlpc3AJCSMgUWxv Z2ljIGZhbWlseQ0KI2RldmljZSAJaXNwZncJCSMgRmlybXdhcmUgZm9yIFFM b2dpYyBIQkFzLSBub3JtYWxseSBhIG1vZHVsZQ0KZGV2aWNlCQltcHQJCSMg TFNJLUxvZ2ljIE1QVC1GdXNpb24NCiNkZXZpY2UJCW5jcgkJIyBOQ1IvU3lt YmlvcyBMb2dpYw0KZGV2aWNlCQlzeW0JCSMgTkNSL1N5bWJpb3MgTG9naWMg KG5ld2VyIGNoaXBzZXRzICsgdGhvc2Ugb2YgYG5jcicpDQpkZXZpY2UJCXRy bQkJIyBUZWtyYW0gREMzOTVVL1VXL0YgREMzMTVVIGFkYXB0ZXJzDQoNCmRl dmljZQkJYWR2CQkjIEFkdmFuc3lzIFNDU0kgYWRhcHRlcnMNCmRldmljZQkJ YWR3CQkjIEFkdmFuc3lzIHdpZGUgU0NTSSBhZGFwdGVycw0KZGV2aWNlCQlh aGEJCSMgQWRhcHRlYyAxNTR4IFNDU0kgYWRhcHRlcnMNCmRldmljZQkJYWlj CQkjIEFkYXB0ZWMgMTVbMDEyXXggU0NTSSBhZGFwdGVycywgQUlDLTZbMjNd NjAuDQpkZXZpY2UJCWJ0CQkjIEJ1c2xvZ2ljL015bGV4IE11bHRpTWFzdGVy IFNDU0kgYWRhcHRlcnMNCg0KZGV2aWNlCQluY3YJCSMgTkNSIDUzQzUwMA0K ZGV2aWNlCQluc3AJCSMgV29ya2JpdCBOaW5qYSBTQ1NJLTMNCmRldmljZQkJ c3RnCQkjIFRNQyAxOEMzMC8xOEM1MA0KDQojIFNDU0kgcGVyaXBoZXJhbHMN CmRldmljZQkJc2NidXMJCSMgU0NTSSBidXMgKHJlcXVpcmVkIGZvciBTQ1NJ KQ0KZGV2aWNlCQljaAkJIyBTQ1NJIG1lZGlhIGNoYW5nZXJzDQpkZXZpY2UJ CWRhCQkjIERpcmVjdCBBY2Nlc3MgKGRpc2tzKQ0KZGV2aWNlCQlzYQkJIyBT ZXF1ZW50aWFsIEFjY2VzcyAodGFwZSBldGMpDQpkZXZpY2UJCWNkCQkjIENE DQpkZXZpY2UJCXBhc3MJCSMgUGFzc3Rocm91Z2ggZGV2aWNlIChkaXJlY3Qg U0NTSSBhY2Nlc3MpDQpkZXZpY2UJCXNlcwkJIyBTQ1NJIEVudmlyb25tZW50 YWwgU2VydmljZXMgKGFuZCBTQUYtVEUpDQoNCiMgUkFJRCBjb250cm9sbGVy cyBpbnRlcmZhY2VkIHRvIHRoZSBTQ1NJIHN1YnN5c3RlbQ0KZGV2aWNlCQlh bXIJCSMgQU1JIE1lZ2FSQUlEDQpkZXZpY2UJCWFyY21zcgkJIyBBcmVjYSBT QVRBIElJIFJBSUQNCmRldmljZQkJYXNyCQkjIERQVCBTbWFydFJBSUQgViwg VkkgYW5kIEFkYXB0ZWMgU0NTSSBSQUlEDQpkZXZpY2UJCWNpc3MJCSMgQ29t cGFxIFNtYXJ0IFJBSUQgNSoNCmRldmljZQkJZHB0CQkjIERQVCBTbWFydGNh Y2hlIElJSSwgSVYgLSBTZWUgTk9URVMgZm9yIG9wdGlvbnMNCmRldmljZQkJ aHB0bXYJCSMgSGlnaHBvaW50IFJvY2tldFJBSUQgMTgyeA0KZGV2aWNlCQlp aXIJCSMgSW50ZWwgSW50ZWdyYXRlZCBSQUlEDQpkZXZpY2UJCWlwcwkJIyBJ Qk0gKEFkYXB0ZWMpIFNlcnZlUkFJRA0KZGV2aWNlCQltbHkJCSMgTXlsZXgg QWNjZWxlUkFJRC9lWHRyZW1lUkFJRA0KZGV2aWNlCQl0d2EJCSMgM3dhcmUg OTAwMCBzZXJpZXMgUEFUQS9TQVRBIFJBSUQNCg0KIyBSQUlEIGNvbnRyb2xs ZXJzDQpkZXZpY2UJCWFhYwkJIyBBZGFwdGVjIEZTQSBSQUlEDQpkZXZpY2UJ CWFhY3AJCSMgU0NTSSBwYXNzdGhyb3VnaCBmb3IgYWFjIChyZXF1aXJlcyBD QU0pDQpkZXZpY2UJCWlkYQkJIyBDb21wYXEgU21hcnQgUkFJRA0KZGV2aWNl CQltbHgJCSMgTXlsZXggREFDOTYwIGZhbWlseQ0KZGV2aWNlCQlwc3QJCSMg UHJvbWlzZSBTdXBlcnRyYWsgU1g2MDAwDQpkZXZpY2UJCXR3ZQkJIyAzd2Fy ZSBBVEEgUkFJRA0KDQojIGF0a2JkYzAgY29udHJvbHMgYm90aCB0aGUga2V5 Ym9hcmQgYW5kIHRoZSBQUy8yIG1vdXNlDQpkZXZpY2UJCWF0a2JkYwkJIyBB VCBrZXlib2FyZCBjb250cm9sbGVyDQpkZXZpY2UJCWF0a2JkCQkjIEFUIGtl eWJvYXJkDQpkZXZpY2UJCXBzbQkJIyBQUy8yIG1vdXNlDQoNCmRldmljZQkJ dmdhCQkjIFZHQSB2aWRlbyBjYXJkIGRyaXZlcg0KDQpkZXZpY2UJCXNwbGFz aAkJIyBTcGxhc2ggc2NyZWVuIGFuZCBzY3JlZW4gc2F2ZXIgc3VwcG9ydA0K DQojIHN5c2NvbnMgaXMgdGhlIGRlZmF1bHQgY29uc29sZSBkcml2ZXIsIHJl c2VtYmxpbmcgYW4gU0NPIGNvbnNvbGUNCmRldmljZQkJc2MNCg0KIyBFbmFi bGUgdGhpcyBmb3IgdGhlIHBjdnQgKFZUMjIwIGNvbXBhdGlibGUpIGNvbnNv bGUgZHJpdmVyDQojZGV2aWNlCQl2dA0KI29wdGlvbnMgCVhTRVJWRVIJCSMg c3VwcG9ydCBmb3IgWCBzZXJ2ZXIgb24gYSB2dCBjb25zb2xlDQojb3B0aW9u cyAJRkFUX0NVUlNPUgkjIHN0YXJ0IHdpdGggYmxvY2sgY3Vyc29yDQoNCmRl dmljZQkJYWdwCQkjIHN1cHBvcnQgc2V2ZXJhbCBBR1AgY2hpcHNldHMNCg0K IyBQb3dlciBtYW5hZ2VtZW50IHN1cHBvcnQgKHNlZSBOT1RFUyBmb3IgbW9y ZSBvcHRpb25zKQ0KI2RldmljZQkJYXBtDQojIEFkZCBzdXNwZW5kL3Jlc3Vt ZSBzdXBwb3J0IGZvciB0aGUgaTgyNTQuDQpkZXZpY2UJCXBtdGltZXINCg0K IyBQQ0NBUkQgKFBDTUNJQSkgc3VwcG9ydA0KIyBQQ01DSUEgYW5kIGNhcmRi dXMgYnJpZGdlIHN1cHBvcnQNCmRldmljZQkJY2JiCQkjIGNhcmRidXMgKHll bnRhKSBicmlkZ2UNCmRldmljZQkJcGNjYXJkCQkjIFBDIENhcmQgKDE2LWJp dCkgYnVzDQpkZXZpY2UJCWNhcmRidXMJCSMgQ2FyZEJ1cyAoMzItYml0KSBi dXMNCg0KIyBTZXJpYWwgKENPTSkgcG9ydHMNCmRldmljZQkJc2lvCQkjIDgy NTAsIDE2WzQ1XTUwIGJhc2VkIHNlcmlhbCBwb3J0cw0KZGV2aWNlCQl1YXJ0 CQkjIEdlbmVyaWMgVUFSVCBkcml2ZXINCg0KIyBQYXJhbGxlbCBwb3J0DQpk ZXZpY2UJCXBwYw0KZGV2aWNlCQlwcGJ1cwkJIyBQYXJhbGxlbCBwb3J0IGJ1 cyAocmVxdWlyZWQpDQpkZXZpY2UJCWxwdAkJIyBQcmludGVyDQpkZXZpY2UJ CXBsaXAJCSMgVENQL0lQIG92ZXIgcGFyYWxsZWwNCmRldmljZQkJcHBpCQkj IFBhcmFsbGVsIHBvcnQgaW50ZXJmYWNlIGRldmljZQ0KI2RldmljZQkJdnBv CQkjIFJlcXVpcmVzIHNjYnVzIGFuZCBkYQ0KDQojIElmIHlvdSd2ZSBnb3Qg YSAiZHVtYiIgc2VyaWFsIG9yIHBhcmFsbGVsIFBDSSBjYXJkIHRoYXQgaXMN CiMgc3VwcG9ydGVkIGJ5IHRoZSBwdWMoNCkgZ2x1ZSBkcml2ZXIsIHVuY29t bWVudCB0aGUgZm9sbG93aW5nDQojIGxpbmUgdG8gZW5hYmxlIGl0IChjb25u ZWN0cyB0byBzaW8sIHVhcnQgYW5kL29yIHBwYyBkcml2ZXJzKToNCiNkZXZp Y2UJCXB1Yw0KDQojIFBDSSBFdGhlcm5ldCBOSUNzLg0KZGV2aWNlCQlkZQkJ IyBERUMvSW50ZWwgREMyMXg0eCAoYGBUdWxpcCcnKQ0KZGV2aWNlCQllbQkJ IyBJbnRlbCBQUk8vMTAwMCBhZGFwdGVyIEdpZ2FiaXQgRXRoZXJuZXQgQ2Fy ZA0KZGV2aWNlCQlpeGdiCQkjIEludGVsIFBSTy8xMEdiRSBFdGhlcm5ldCBD YXJkDQpkZXZpY2UJCXR4cAkJIyAzQ29tIDNjUjk5MCAoYGBUeXBob29uJycp DQpkZXZpY2UJCXZ4CQkjIDNDb20gM2M1OTAsIDNjNTk1IChgYFZvcnRleCcn KQ0KDQojIFBDSSBFdGhlcm5ldCBOSUNzIHRoYXQgdXNlIHRoZSBjb21tb24g TUlJIGJ1cyBjb250cm9sbGVyIGNvZGUuDQojIE5PVEU6IEJlIHN1cmUgdG8g a2VlcCB0aGUgJ2RldmljZSBtaWlidXMnIGxpbmUgaW4gb3JkZXIgdG8gdXNl IHRoZXNlIE5JQ3MhDQpkZXZpY2UJCW1paWJ1cwkJIyBNSUkgYnVzIHN1cHBv cnQNCmRldmljZQkJYmZlCQkjIEJyb2FkY29tIEJDTTQ0MHggMTAvMTAwIEV0 aGVybmV0DQpkZXZpY2UJCWJnZQkJIyBCcm9hZGNvbSBCQ001NzB4eCBHaWdh Yml0IEV0aGVybmV0DQpkZXZpY2UJCWRjCQkjIERFQy9JbnRlbCAyMTE0MyBh bmQgdmFyaW91cyB3b3JrYWxpa2VzDQpkZXZpY2UJCWZ4cAkJIyBJbnRlbCBF dGhlckV4cHJlc3MgUFJPLzEwMEIgKDgyNTU3LCA4MjU1OCkNCmRldmljZQkJ bGdlCQkjIExldmVsIDEgTFhUMTAwMSBnaWdhYml0IEV0aGVybmV0DQpkZXZp Y2UJCW5nZQkJIyBOYXRTZW1pIERQODM4MjAgZ2lnYWJpdCBFdGhlcm5ldA0K ZGV2aWNlCQludmUJCSMgblZpZGlhIG5Gb3JjZSBNQ1Agb24tYm9hcmQgRXRo ZXJuZXQgTmV0d29ya2luZw0KZGV2aWNlCQlwY24JCSMgQU1EIEFtNzlDOTd4 IFBDSSAxMC8xMDAocHJlY2VkZW5jZSBvdmVyICdsbmMnKQ0KZGV2aWNlCQly ZQkJIyBSZWFsVGVrIDgxMzlDKy84MTY5LzgxNjlTLzgxMTBTDQpkZXZpY2UJ CXJsCQkjIFJlYWxUZWsgODEyOS84MTM5DQpkZXZpY2UJCXNmCQkjIEFkYXB0 ZWMgQUlDLTY5MTUgKGBgU3RhcmZpcmUnJykNCmRldmljZQkJc2lzCQkjIFNp bGljb24gSW50ZWdyYXRlZCBTeXN0ZW1zIFNpUyA5MDAvU2lTIDcwMTYNCmRl dmljZQkJc2sJCSMgU3lzS29ubmVjdCBTSy05ODR4ICYgU0stOTgyeCBnaWdh Yml0IEV0aGVybmV0DQpkZXZpY2UJCXN0ZQkJIyBTdW5kYW5jZSBTVDIwMSAo RC1MaW5rIERGRS01NTBUWCkNCmRldmljZQkJdGkJCSMgQWx0ZW9uIE5ldHdv cmtzIFRpZ29uIEkvSUkgZ2lnYWJpdCBFdGhlcm5ldA0KZGV2aWNlCQl0bAkJ IyBUZXhhcyBJbnN0cnVtZW50cyBUaHVuZGVyTEFODQpkZXZpY2UJCXR4CQkj IFNNQyBFdGhlclBvd2VyIElJICg4M2MxNzAgYGBFUElDJycpDQpkZXZpY2UJ CXZnZQkJIyBWSUEgVlQ2MTJ4IGdpZ2FiaXQgRXRoZXJuZXQNCmRldmljZQkJ dnIJCSMgVklBIFJoaW5lLCBSaGluZSBJSQ0KZGV2aWNlCQl3YgkJIyBXaW5i b25kIFc4OUM4NDBGDQpkZXZpY2UJCXhsCQkjIDNDb20gM2M5MHggKGBgQm9v bWVyYW5nJycsIGBgQ3ljbG9uZScnKQ0KDQojIElTQSBFdGhlcm5ldCBOSUNz LiAgcGNjYXJkIE5JQ3MgaW5jbHVkZWQuDQpkZXZpY2UJCWNzCQkjIENyeXN0 YWwgU2VtaWNvbmR1Y3RvciBDUzg5eDAgTklDDQojICdkZXZpY2UgZWQnIHJl cXVpcmVzICdkZXZpY2UgbWlpYnVzJw0KZGV2aWNlCQllZAkJIyBORVsxMl0w MDAsIFNNQyBVbHRyYSwgM2M1MDMsIERTODM5MCBjYXJkcw0KZGV2aWNlCQll eAkJIyBJbnRlbCBFdGhlckV4cHJlc3MgUHJvLzEwIGFuZCBQcm8vMTArDQpk ZXZpY2UJCWVwCQkjIEV0aGVybGluayBJSUkgYmFzZWQgY2FyZHMNCmRldmlj ZQkJZmUJCSMgRnVqaXRzdSBNQjg2OTZ4IGJhc2VkIGNhcmRzDQpkZXZpY2UJ CWllCQkjIEV0aGVyRXhwcmVzcyA4LzE2LCAzQzUwNywgU3RhckxBTiAxMCBl dGMuDQpkZXZpY2UJCWxuYwkJIyBORTIxMDAsIE5FMzItVkwgTGFuY2UgRXRo ZXJuZXQgY2FyZHMNCmRldmljZQkJc24JCSMgU01DJ3MgOTAwMCBzZXJpZXMg b2YgRXRoZXJuZXQgY2hpcHMNCmRldmljZQkJeGUJCSMgWGlyY29tIHBjY2Fy ZCBFdGhlcm5ldA0KDQojIElTQSBkZXZpY2VzIHRoYXQgdXNlIHRoZSBvbGQg SVNBIHNoaW1zDQojZGV2aWNlCQlsZQ0KDQojIFdpcmVsZXNzIE5JQyBjYXJk cw0KZGV2aWNlCQl3bGFuCQkjIDgwMi4xMSBzdXBwb3J0DQpkZXZpY2UJCWFu CQkjIEFpcm9uZXQgNDUwMC80ODAwIDgwMi4xMSB3aXJlbGVzcyBOSUNzLg0K ZGV2aWNlCQlhd2kJCSMgQmF5U3RhY2sgNjYwIGFuZCBvdGhlcnMNCmRldmlj ZQkJcmFsCQkjIFJhbGluayBUZWNobm9sb2d5IFJUMjUwMCB3aXJlbGVzcyBO SUNzLg0KZGV2aWNlCQl3aQkJIyBXYXZlTEFOL0ludGVyc2lsL1N5bWJvbCA4 MDIuMTEgd2lyZWxlc3MgTklDcy4NCiNkZXZpY2UJCXdsCQkjIE9sZGVyIG5v biA4MDIuMTEgV2F2ZWxhbiB3aXJlbGVzcyBOSUMuDQoNCiMgUHNldWRvIGRl dmljZXMuDQpkZXZpY2UJCWxvb3AJCSMgTmV0d29yayBsb29wYmFjaw0KZGV2 aWNlCQlyYW5kb20JCSMgRW50cm9weSBkZXZpY2UNCmRldmljZQkJZXRoZXIJ CSMgRXRoZXJuZXQgc3VwcG9ydA0KZGV2aWNlCQlzbAkJIyBLZXJuZWwgU0xJ UA0KZGV2aWNlCQlwcHAJCSMgS2VybmVsIFBQUA0KZGV2aWNlCQl0dW4JCSMg UGFja2V0IHR1bm5lbC4NCmRldmljZQkJcHR5CQkjIFBzZXVkby10dHlzICh0 ZWxuZXQgZXRjKQ0KZGV2aWNlCQltZAkJIyBNZW1vcnkgImRpc2tzIg0KZGV2 aWNlCQlnaWYJCSMgSVB2NiBhbmQgSVB2NCB0dW5uZWxpbmcNCmRldmljZQkJ ZmFpdGgJCSMgSVB2Ni10by1JUHY0IHJlbGF5aW5nICh0cmFuc2xhdGlvbikN Cg0KIyBUaGUgYGJwZicgZGV2aWNlIGVuYWJsZXMgdGhlIEJlcmtlbGV5IFBh Y2tldCBGaWx0ZXIuDQojIEJlIGF3YXJlIG9mIHRoZSBhZG1pbmlzdHJhdGl2 ZSBjb25zZXF1ZW5jZXMgb2YgZW5hYmxpbmcgdGhpcyENCiMgTm90ZSB0aGF0 ICdicGYnIGlzIHJlcXVpcmVkIGZvciBESENQLg0KZGV2aWNlCQlicGYJCSMg QmVya2VsZXkgcGFja2V0IGZpbHRlcg0KDQojIFVTQiBzdXBwb3J0DQpkZXZp Y2UJCXVoY2kJCSMgVUhDSSBQQ0ktPlVTQiBpbnRlcmZhY2UNCmRldmljZQkJ b2hjaQkJIyBPSENJIFBDSS0+VVNCIGludGVyZmFjZQ0KZGV2aWNlCQllaGNp CQkjIEVIQ0kgUENJLT5VU0IgaW50ZXJmYWNlIChVU0IgMi4wKQ0KZGV2aWNl CQl1c2IJCSMgVVNCIEJ1cyAocmVxdWlyZWQpDQojZGV2aWNlCQl1ZGJwCQkj IFVTQiBEb3VibGUgQnVsayBQaXBlIGRldmljZXMNCmRldmljZQkJdWdlbgkJ IyBHZW5lcmljDQpkZXZpY2UJCXVoaWQJCSMgIkh1bWFuIEludGVyZmFjZSBE ZXZpY2VzIg0KZGV2aWNlCQl1a2JkCQkjIEtleWJvYXJkDQpkZXZpY2UJCXVs cHQJCSMgUHJpbnRlcg0KZGV2aWNlCQl1bWFzcwkJIyBEaXNrcy9NYXNzIHN0 b3JhZ2UgLSBSZXF1aXJlcyBzY2J1cyBhbmQgZGENCmRldmljZQkJdW1zCQkj IE1vdXNlDQpkZXZpY2UJCXVyYWwJCSMgUmFsaW5rIFRlY2hub2xvZ3kgUlQy NTAwVVNCIHdpcmVsZXNzIE5JQ3MNCmRldmljZQkJdXJpbwkJIyBEaWFtb25k IFJpbyA1MDAgTVAzIHBsYXllcg0KZGV2aWNlCQl1c2Nhbm5lcgkjIFNjYW5u ZXJzDQojIFVTQiBFdGhlcm5ldCwgcmVxdWlyZXMgbWlpYnVzDQpkZXZpY2UJ CWF1ZQkJIyBBRE10ZWsgVVNCIEV0aGVybmV0DQpkZXZpY2UJCWF4ZQkJIyBB U0lYIEVsZWN0cm9uaWNzIFVTQiBFdGhlcm5ldA0KZGV2aWNlCQljZGNlCQkj IEdlbmVyaWMgVVNCIG92ZXIgRXRoZXJuZXQNCmRldmljZQkJY3VlCQkjIENB VEMgVVNCIEV0aGVybmV0DQpkZXZpY2UJCWt1ZQkJIyBLYXdhc2FraSBMU0kg VVNCIEV0aGVybmV0DQpkZXZpY2UJCXJ1ZQkJIyBSZWFsVGVrIFJUTDgxNTAg VVNCIEV0aGVybmV0DQoNCiMgRmlyZVdpcmUgc3VwcG9ydA0KZGV2aWNlCQlm aXJld2lyZQkjIEZpcmVXaXJlIGJ1cyBjb2RlDQpkZXZpY2UJCXNicAkJIyBT Q1NJIG92ZXIgRmlyZVdpcmUgKFJlcXVpcmVzIHNjYnVzIGFuZCBkYSkNCmRl dmljZQkJZndlCQkjIEV0aGVybmV0IG92ZXIgRmlyZVdpcmUgKG5vbi1zdGFu ZGFyZCEpDQoNCm9wdGlvbnMgSVBGSUxURVINCm9wdGlvbnMJU0NfUElYRUxf TU9ERQ0KDQpvcHRpb25zIERFQlVHX0xPQ0tTDQpvcHRpb25zIERFQlVHX1ZG U19MT0NLUw0KDQo= --1536391169-1648064527-1134662438=:12379-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 15 17:57:18 2005 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 190FB16A41F for ; Thu, 15 Dec 2005 17:57:18 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9B5143D72 for ; Thu, 15 Dec 2005 17:57:06 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 3874565 for multiple; Thu, 15 Dec 2005 12:55:02 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jBFHuqG6070481; Thu, 15 Dec 2005 12:56:55 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Anish Mistry Date: Thu, 15 Dec 2005 12:45:01 -0500 User-Agent: KMail/1.8.2 References: <200512141720.01572.jhb@freebsd.org> <200512150033.13676.mistry.7@osu.edu> In-Reply-To: <200512150033.13676.mistry.7@osu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512151245.01913.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1210/Thu Dec 15 10:23:22 2005 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: freebsd-current@freebsd.org Subject: Re: hostb(4) and vgapci(4) 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: Thu, 15 Dec 2005 17:57:18 -0000 On Thursday 15 December 2005 12:32 am, Anish Mistry wrote: > On Wednesday 14 December 2005 05:20 pm, John Baldwin wrote: > > I have a patch that is an attempt to untangle a few things in > > relation to Host-PCI bridges and VGA PCI devices. Basically, the > > change is to create a more "real" hostb driver as well as a new > > vgapci driver and to change agp, drm, and acpi_video to attach to > > these drivers. This means among other things: > > > > - In theory you can now kldload agp after boot since it still has a > > place to attach to. > > - i830/915 drm is no longer a child of agp, instead both become > > children of vgapci0. > > - You can now use acpi_video with drm as both attach as children of > > vgapci0. - This provides a way for us to possibly solve the DPMS > > problem for suspend/resume (including a cleaner way to do the hack > > dpms patch I posted to acpi@ a long while ago that several people > > still use). > > > > Some other details include: > > > > - agp devices no longer map the _entire_ aperture into contiguous > > KVA meaning that it might be possible now to use a 256 MB aperture > > without panicing - I've added a new pci_if.m method for locating a > > specific capability for a PCI device. > > > > I have tested this on my laptop and verified that dri still works, > > but it needs some wider testing, especially the i830/i915 case is > > slightly more complicated. Also, this is not going to work with > > the nvidia-driver currently, but that's something that can be fixed > > in the future. If the agp non-mapping does fix the 256 MB aperture > > issues then I will probably MFC that part to RELENG_6. > > > > http://www.FreeBSD.org/~jhb/patches/agp_cvs.patch > > Thank you! It seems to work as advertised. I'm running mach64 DRM > with the DPMS patch acpi_video and they both work. :) > One small problem though. When I unload the acpi_video module and > reload it I get the following: > littleguy# kldload acpi_video > acpi_video0: on vgapci0 > acpi_video1: on vgapci0 > littleguy# kldunload acpi_video > acpi_video0: detached > acpi_video1: detached > littleguy# kldunload acpi_video > kldunload: can't find file acpi_video: No such file or directory > littleguy# kldload acpi_video > acpi_video0: on vgapci0 > acpi_video1: on vgapci0 > acpi_video2: on vgapci0 > littleguy# > It also created multiple sysctls with subsequent loads: > hw.acpi.video.crt0.active: 1 > hw.acpi.video.lcd0.active: 1 > hw.acpi.video.tv0.active: 0 > hw.acpi.video.crt1.active: 1 > hw.acpi.video.lcd1.active: 1 > hw.acpi.video.tv1.active: 0 > hw.acpi.video.crt2.active: 1 > hw.acpi.video.lcd2.active: 1 > hw.acpi.video.tv2.active: 0 Ok, I can work around that for now. There really should be a driver_unidentify routine that gets called during bus_generic_detach() to clean these up. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Dec 15 17:57:18 2005 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 21A6F16A422; Thu, 15 Dec 2005 17:57:18 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3526543D75; Thu, 15 Dec 2005 17:57:07 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 3874557 for multiple; Thu, 15 Dec 2005 12:54:56 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jBFHuqG5070481; Thu, 15 Dec 2005 12:56:53 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Eric Anderson Date: Thu, 15 Dec 2005 11:32:44 -0500 User-Agent: KMail/1.8.2 References: <200512141720.01572.jhb@freebsd.org> <43A0E3B3.6030903@centtech.com> In-Reply-To: <43A0E3B3.6030903@centtech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512151132.45474.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1210/Thu Dec 15 10:23:22 2005 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: anholt@freebsd.org, current@freebsd.org Subject: Re: hostb(4) and vgapci(4) 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: Thu, 15 Dec 2005 17:57:18 -0000 On Wednesday 14 December 2005 10:32 pm, Eric Anderson wrote: > John Baldwin wrote: > >I have a patch that is an attempt to untangle a few things in relation to > >Host-PCI bridges and VGA PCI devices. Basically, the change is to create > > a more "real" hostb driver as well as a new vgapci driver and to change > > agp, drm, and acpi_video to attach to these drivers. This means among > > other things: > > > >- In theory you can now kldload agp after boot since it still has a place > > to attach to. > >- i830/915 drm is no longer a child of agp, instead both become children > > of vgapci0. > >- You can now use acpi_video with drm as both attach as children of > > vgapci0. - This provides a way for us to possibly solve the DPMS problem > > for suspend/resume (including a cleaner way to do the hack dpms patch I > > posted to acpi@ a long while ago that several people still use). > > > >Some other details include: > > > >- agp devices no longer map the _entire_ aperture into contiguous KVA > > meaning that it might be possible now to use a 256 MB aperture without > > panicing - I've added a new pci_if.m method for locating a specific > > capability for a PCI device. > > > >I have tested this on my laptop and verified that dri still works, but it > >needs some wider testing, especially the i830/i915 case is slightly more > >complicated. Also, this is not going to work with the nvidia-driver > >currently, but that's something that can be fixed in the future. If the > > agp non-mapping does fix the 256 MB aperture issues then I will probably > > MFC that part to RELENG_6. > > > >http://www.FreeBSD.org/~jhb/patches/agp_cvs.patch > > cc -c -O2 -pipe -fno-strict-aliasing -march=pentiumpro -Wall > -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual > -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys > -I/usr/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 > /usr/src/sys/pci/agp_i810.c > /usr/src/sys/pci/agp_i810.c: In function `agp_i810_detach': > /usr/src/sys/pci/agp_i810.c:463: warning: unused variable `child' > *** Error code 1 If you delete this line to fix the warning does it work ok? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Dec 15 18:56:17 2005 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 3791E16A432 for ; Thu, 15 Dec 2005 18:56:17 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C85A43D5C for ; Thu, 15 Dec 2005 18:56:16 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 3882432 for multiple; Thu, 15 Dec 2005 13:54:15 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jBFIuCJV070862; Thu, 15 Dec 2005 13:56:12 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 15 Dec 2005 13:56:40 -0500 User-Agent: KMail/1.8.2 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512151356.41550.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1210/Thu Dec 15 10:23:22 2005 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: Goran Gajic Subject: Re: skype-1.2.0.18-static for linux and FreeBSD 7.0 CURRENT 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, 15 Dec 2005 18:56:17 -0000 On Thursday 15 December 2005 11:00 am, Goran Gajic wrote: > Hi, > > I have figgured out, adding: > > options DEBUG_LOCKS > options DEBUG_VFS_LOCKS > > to the GENERIC config will efectevly cause skype to reboot 7.0-CURRENT > when username and password are entered at skype login. > > this has nothing to do with panic caused by kldunload linux.ko I have > reported earlier. > > > Reagrds, > Goran Gajic If you are in X this is probably a panic (currently the kernel doesn't create a coredump while you are in X which is a bug). Can you hook up a serial console and use that to get the panic message? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Dec 15 19:13:52 2005 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 7A34C16A41F for ; Thu, 15 Dec 2005 19:13:52 +0000 (GMT) (envelope-from eculp@bafirst.com) Received: from bafirst.com (72-12-2-214.wan.networktel.net [72.12.2.214]) by mx1.FreeBSD.org (Postfix) with ESMTP id B340B43D7F for ; Thu, 15 Dec 2005 19:13:42 +0000 (GMT) (envelope-from eculp@bafirst.com) Received: from localhost (localhost [127.0.0.1]) (uid 80) by bafirst.com with local; Thu, 15 Dec 2005 13:13:42 -0600 id 000959A0.43A1C066.0001674F Received: from local4.local.net (local4.local.net [192.168.1.4]) by mail.bafirst.com (Horde MIME library) with HTTP; Thu, 15 Dec 2005 13:13:41 -0600 Message-ID: <20051215131341.d0vnxkjw4kc480w8@mail.bafirst.com> Date: Thu, 15 Dec 2005 13:13:41 -0600 From: eculp@bafirst.com To: freebsd-current@freebsd.org References: <200512151356.41550.jhb@freebsd.org> In-Reply-To: <200512151356.41550.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.1-cvs Subject: Re: skype-1.2.0.18-static for linux and FreeBSD 7.0 CURRENT 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, 15 Dec 2005 19:13:52 -0000 Quoting John Baldwin : > On Thursday 15 December 2005 11:00 am, Goran Gajic wrote: >> Hi, >> >> I have figgured out, adding: >> >> options DEBUG_LOCKS >> options DEBUG_VFS_LOCKS >> >> to the GENERIC config will efectevly cause skype to reboot 7.0-CURRENT >> when username and password are entered at skype login. >> >> this has nothing to do with panic caused by kldunload linux.ko I have >> reported earlier. >> >> >> Reagrds, >> Goran Gajic > > If you are in X this is probably a panic (currently the kernel doesn't create > a coredump while you are in X which is a bug). Can you hook up a serial > console and use that to get the panic message? I've been seeing this problem on current for a while but the strange part about my reboot is that it is only when running KDE. I can start and stop skype in Gnome and twm with no problem. ed From owner-freebsd-current@FreeBSD.ORG Thu Dec 15 19:41:56 2005 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 CEB2816A41F; Thu, 15 Dec 2005 19:41:56 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id F161243D5E; Thu, 15 Dec 2005 19:41:55 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id jBFJfspX084257; Thu, 15 Dec 2005 13:41:54 -0600 (CST) (envelope-from anderson@centtech.com) Message-ID: <43A1C6E0.1050203@centtech.com> Date: Thu, 15 Dec 2005 13:41:20 -0600 From: Eric Anderson User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051204) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <200512141720.01572.jhb@freebsd.org> <43A0E3B3.6030903@centtech.com> <200512151132.45474.jhb@freebsd.org> In-Reply-To: <200512151132.45474.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/1210/Thu Dec 15 09:23:22 2005 on mh2.centtech.com X-Virus-Status: Clean Cc: anholt@freebsd.org, current@freebsd.org Subject: Re: hostb(4) and vgapci(4) 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: Thu, 15 Dec 2005 19:41:56 -0000 John Baldwin wrote: >On Wednesday 14 December 2005 10:32 pm, Eric Anderson wrote: > > >>John Baldwin wrote: >> >> >>>I have a patch that is an attempt to untangle a few things in relation to >>>Host-PCI bridges and VGA PCI devices. Basically, the change is to create >>>a more "real" hostb driver as well as a new vgapci driver and to change >>>agp, drm, and acpi_video to attach to these drivers. This means among >>>other things: >>> >>>- In theory you can now kldload agp after boot since it still has a place >>>to attach to. >>>- i830/915 drm is no longer a child of agp, instead both become children >>>of vgapci0. >>>- You can now use acpi_video with drm as both attach as children of >>>vgapci0. - This provides a way for us to possibly solve the DPMS problem >>>for suspend/resume (including a cleaner way to do the hack dpms patch I >>>posted to acpi@ a long while ago that several people still use). >>> >>>Some other details include: >>> >>>- agp devices no longer map the _entire_ aperture into contiguous KVA >>>meaning that it might be possible now to use a 256 MB aperture without >>>panicing - I've added a new pci_if.m method for locating a specific >>>capability for a PCI device. >>> >>>I have tested this on my laptop and verified that dri still works, but it >>>needs some wider testing, especially the i830/i915 case is slightly more >>>complicated. Also, this is not going to work with the nvidia-driver >>>currently, but that's something that can be fixed in the future. If the >>>agp non-mapping does fix the 256 MB aperture issues then I will probably >>>MFC that part to RELENG_6. >>> >>>http://www.FreeBSD.org/~jhb/patches/agp_cvs.patch >>> >>> >>cc -c -O2 -pipe -fno-strict-aliasing -march=pentiumpro -Wall >>-Wredundant-decls -Wnested-externs -Wstrict-prototypes >>-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual >>-fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys >>-I/usr/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 >>/usr/src/sys/pci/agp_i810.c >>/usr/src/sys/pci/agp_i810.c: In function `agp_i810_detach': >>/usr/src/sys/pci/agp_i810.c:463: warning: unused variable `child' >>*** Error code 1 >> >> > >If you delete this line to fix the warning does it work ok? > > Yep - I'll report anything else I see. Thanks! Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Thu Dec 15 19:43:43 2005 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 6696316A41F for ; Thu, 15 Dec 2005 19:43:43 +0000 (GMT) (envelope-from thron_forum@yahoo.com) Received: from web35908.mail.mud.yahoo.com (web35908.mail.mud.yahoo.com [66.163.179.192]) by mx1.FreeBSD.org (Postfix) with SMTP id 4680443D93 for ; Thu, 15 Dec 2005 19:43:35 +0000 (GMT) (envelope-from thron_forum@yahoo.com) Received: (qmail 49911 invoked by uid 60001); 15 Dec 2005 19:43:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=kbnyPh8TB1hybWgyQmk9ZaaWLv3SCvolqAG9943s/1kqXPUY0mlXOlctIeN0zeTuiNDn1ltG17hiQkSbDvUh98c0Z0LzyaC7U8TdIso6tJEYW6IGlHOrIzUpRIQ0JocuUc8dIAvlhbgZOVl29Vm5rfvaySsLxuhcyQLGIhK+qb0= ; Message-ID: <20051215194325.49909.qmail@web35908.mail.mud.yahoo.com> Received: from [208.57.242.155] by web35908.mail.mud.yahoo.com via HTTP; Thu, 15 Dec 2005 11:43:25 PST Date: Thu, 15 Dec 2005 11:43:25 -0800 (PST) From: thron forum To: freebsd-current@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 Subject: Adaptec SATA 1205sa support for FreeBSD 6.0 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, 15 Dec 2005 19:43:43 -0000 Does the current release support the Adaptec SATA 1205sa card? I have searched the Freebsd site as well as Google.com/bsd and I cant find the card. Any help would be greatly appreciated. Thanks Thron --------------------------------- Yahoo! Shopping Find Great Deals on Holiday Gifts at Yahoo! Shopping From owner-freebsd-current@FreeBSD.ORG Thu Dec 15 20:07:28 2005 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 838B716A41F for ; Thu, 15 Dec 2005 20:07:28 +0000 (GMT) (envelope-from sos@FreeBSD.org) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A49943D45 for ; Thu, 15 Dec 2005 20:07:27 +0000 (GMT) (envelope-from sos@FreeBSD.org) Received: from [194.192.25.142] (spider.deepcore.dk [194.192.25.142]) by spider.deepcore.dk (8.13.4/8.13.4) with ESMTP id jBFK7QZw038439; Thu, 15 Dec 2005 21:07:26 +0100 (CET) (envelope-from sos@FreeBSD.org) Message-ID: <43A1CCFE.10705@FreeBSD.org> Date: Thu, 15 Dec 2005 21:07:26 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: thron forum References: <20051215194325.49909.qmail@web35908.mail.mud.yahoo.com> In-Reply-To: <20051215194325.49909.qmail@web35908.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-mail-scanned: by DeepCore Virus & Spam killer v1.16 Cc: freebsd-current@FreeBSD.org Subject: Re: Adaptec SATA 1205sa support for FreeBSD 6.0 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, 15 Dec 2005 20:07:28 -0000 thron forum wrote: >Does the current release support the Adaptec SATA 1205sa card? I have searched the Freebsd site as well as Google.com/bsd and I cant find the card. > > The 1205 is based on the SiI3112 SATA chip and is as such supported. However, that chip is with a fair margin the worst piece of crap you can buy for money IMNHO. Get a real SATA controller and spare yourself the trouble, headackes etc... -Sřren From owner-freebsd-current@FreeBSD.ORG Thu Dec 15 20:17:40 2005 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 0BE5E16A41F; Thu, 15 Dec 2005 20:17:40 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from smtp-vbr7.xs4all.nl (smtp-vbr7.xs4all.nl [194.109.24.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 403FA43D5E; Thu, 15 Dec 2005 20:17:38 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp-vbr7.xs4all.nl (8.13.3/8.13.3) with ESMTP id jBFKHb1t026222; Thu, 15 Dec 2005 21:17:38 +0100 (CET) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.13.4/8.13.3) with ESMTP id jBFKHbh6010873; Thu, 15 Dec 2005 21:17:37 +0100 (CET) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.13.4/8.13.1/Submit) id jBFKHbsY010872; Thu, 15 Dec 2005 21:17:37 +0100 (CET) (envelope-from wb) Date: Thu, 15 Dec 2005 21:17:37 +0100 From: Wilko Bulte To: =?iso-8859-1?Q?S=F8ren?= Schmidt Message-ID: <20051215201737.GA10846@freebie.xs4all.nl> References: <20051215194325.49909.qmail@web35908.mail.mud.yahoo.com> <43A1CCFE.10705@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43A1CCFE.10705@FreeBSD.org> X-OS: FreeBSD 6.0-STABLE User-Agent: Mutt/1.5.11 X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-current@freebsd.org, thron forum Subject: Re: Adaptec SATA 1205sa support for FreeBSD 6.0 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, 15 Dec 2005 20:17:40 -0000 On Thu, Dec 15, 2005 at 09:07:26PM +0100, Sren Schmidt wrote.. > thron forum wrote: > > >Does the current release support the Adaptec SATA 1205sa card? I have > >searched the Freebsd site as well as Google.com/bsd and I cant find the > >card. > > > > > The 1205 is based on the SiI3112 SATA chip and is as such supported. > However, that chip is with a fair margin the worst piece of crap you can > buy for money IMNHO. > Get a real SATA controller and spare yourself the trouble, headackes etc... Soren, what would you recommend for a plain SATA controller? And what for one that can do true RAID1? thanks, Wilko -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Dec 15 20:42:11 2005 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 1E4BC16A420; Thu, 15 Dec 2005 20:42:11 +0000 (GMT) (envelope-from sos@deepcore.dk) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A0FE43D77; Thu, 15 Dec 2005 20:42:10 +0000 (GMT) (envelope-from sos@deepcore.dk) Received: from [194.192.25.142] (spider.deepcore.dk [194.192.25.142]) by spider.deepcore.dk (8.13.4/8.13.4) with ESMTP id jBFKg5t4038934; Thu, 15 Dec 2005 21:42:06 +0100 (CET) (envelope-from sos@deepcore.dk) Message-ID: <43A1D51D.7070804@deepcore.dk> Date: Thu, 15 Dec 2005 21:42:05 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Wilko Bulte References: <20051215194325.49909.qmail@web35908.mail.mud.yahoo.com> <43A1CCFE.10705@FreeBSD.org> <20051215201737.GA10846@freebie.xs4all.nl> In-Reply-To: <20051215201737.GA10846@freebie.xs4all.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-mail-scanned: by DeepCore Virus & Spam killer v1.16 Cc: thron forum , freebsd-current@FreeBSD.ORG, =?ISO-8859-1?Q?S=F8ren_Schmidt?= Subject: Re: Adaptec SATA 1205sa support for FreeBSD 6.0 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, 15 Dec 2005 20:42:11 -0000 Wilko Bulte wrote: > On Thu, Dec 15, 2005 at 09:07:26PM +0100, Sren Schmidt wrote.. > >>thron forum wrote: >> >> >>>Does the current release support the Adaptec SATA 1205sa card? I have >>>searched the Freebsd site as well as Google.com/bsd and I cant find the >>>card. >>> >>> >> >>The 1205 is based on the SiI3112 SATA chip and is as such supported. >>However, that chip is with a fair margin the worst piece of crap you can >>buy for money IMNHO. >>Get a real SATA controller and spare yourself the trouble, headackes etc... > > > Soren, what would you recommend for a plain SATA controller? Something Promise, a tx2 or tx4 depending on channels needed. > And what for one that can do true RAID1? Define true RAID1 ? All RAID1's that ATA supports are sofware based, any controller can do here, unless you want to boot from it, you'd go for one that has BIOS support for RAID like the Promise TX2200.. -Sřren From owner-freebsd-current@FreeBSD.ORG Thu Dec 15 20:52:52 2005 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 836FE16A420 for ; Thu, 15 Dec 2005 20:52:52 +0000 (GMT) (envelope-from thron_forum@yahoo.com) Received: from web35908.mail.mud.yahoo.com (web35908.mail.mud.yahoo.com [66.163.179.192]) by mx1.FreeBSD.org (Postfix) with SMTP id 8D97243D60 for ; Thu, 15 Dec 2005 20:52:51 +0000 (GMT) (envelope-from thron_forum@yahoo.com) Received: (qmail 82571 invoked by uid 60001); 15 Dec 2005 20:52:50 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=CP3YultbkFnYEm710dfdc8kYlr6xIwNrMlyo+8Onp1Xe5tIM3vJ6CfKbgYt1pCL2bsVRNZUFKAqpLozun3e3K6QBtb3kHXKm+FLjrT+QHJZUGKRWFu/hEBucpjwUxuwFQz0+fdEv67DWlTt48QZPI2p6wL5TODubR+sflJLvw0E= ; Message-ID: <20051215205250.82569.qmail@web35908.mail.mud.yahoo.com> Received: from [208.57.242.155] by web35908.mail.mud.yahoo.com via HTTP; Thu, 15 Dec 2005 12:52:50 PST Date: Thu, 15 Dec 2005 12:52:50 -0800 (PST) From: thron forum To: "Sďż˝ren" Schmidt In-Reply-To: <43A1CCFE.10705@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: freebsd-current@FreeBSD.org Subject: Re: Adaptec SATA 1205sa support for FreeBSD 6.0 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, 15 Dec 2005 20:52:52 -0000 Hum.. thats not incourging. So what driver supports the card? Unfortinatly this is what I have to work with so I cant get a new card. Sďż˝ren Schmidt wrote: thron forum wrote: >Does the current release support the Adaptec SATA 1205sa card? I have searched the Freebsd site as well as Google.com/bsd and I cant find the card. > > The 1205 is based on the SiI3112 SATA chip and is as such supported. However, that chip is with a fair margin the worst piece of crap you can buy for money IMNHO. Get a real SATA controller and spare yourself the trouble, headackes etc... -Sďż˝ren --------------------------------- Yahoo! Shopping Find Great Deals on Holiday Gifts at Yahoo! Shopping From owner-freebsd-current@FreeBSD.ORG Thu Dec 15 20:55:50 2005 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 CF23116A429 for ; Thu, 15 Dec 2005 20:55:50 +0000 (GMT) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFF4843D79 for ; Thu, 15 Dec 2005 20:55:35 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.13.4/8.13.4) with ESMTP id jBFKtQZH055566; Thu, 15 Dec 2005 15:55:26 -0500 (EST) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.3/8.13.3) with ESMTP id jBFKtKCH065466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Dec 2005 15:55:20 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <6.2.3.4.0.20051215155422.0824bc48@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Thu, 15 Dec 2005 15:55:09 -0500 To: Wilko Bulte From: Mike Tancsa In-Reply-To: <20051215201737.GA10846@freebie.xs4all.nl> References: <20051215194325.49909.qmail@web35908.mail.mud.yahoo.com> <43A1CCFE.10705@FreeBSD.org> <20051215201737.GA10846@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: freebsd-current@freebsd.org Subject: Re: Adaptec SATA 1205sa support for FreeBSD 6.0 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, 15 Dec 2005 20:55:51 -0000 At 03:17 PM 15/12/2005, Wilko Bulte wrote: >Soren, what would you recommend for a plain SATA controller? And what >for one that can do true RAID1? I am not Soren, but I have been using the 3ware 8500 series for some time and they work very well under FreeBSD, Linux and Windows in terms of reliability and reasonable performance. We have a lot of FreeBSD boxes running on 3ware cards with RAID1 and we like them a lot.... Especially when it comes time to change out a dead drive. Painless, easy and so far 100% reliable. ---Mike From owner-freebsd-current@FreeBSD.ORG Thu Dec 15 21:18:47 2005 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 8F34816A41F; Thu, 15 Dec 2005 21:18:47 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from smtp-vbr6.xs4all.nl (smtp-vbr6.xs4all.nl [194.109.24.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD10843D62; Thu, 15 Dec 2005 21:18:46 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp-vbr6.xs4all.nl (8.13.3/8.13.3) with ESMTP id jBFLIi4M050241; Thu, 15 Dec 2005 22:18:44 +0100 (CET) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.13.4/8.13.3) with ESMTP id jBFLIhfg011434; Thu, 15 Dec 2005 22:18:43 +0100 (CET) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.13.4/8.13.1/Submit) id jBFLIhqT011433; Thu, 15 Dec 2005 22:18:43 +0100 (CET) (envelope-from wb) Date: Thu, 15 Dec 2005 22:18:43 +0100 From: Wilko Bulte To: =?iso-8859-1?Q?S=F8ren?= Schmidt Message-ID: <20051215211842.GA11418@freebie.xs4all.nl> References: <20051215194325.49909.qmail@web35908.mail.mud.yahoo.com> <43A1CCFE.10705@FreeBSD.org> <20051215201737.GA10846@freebie.xs4all.nl> <43A1D51D.7070804@deepcore.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43A1D51D.7070804@deepcore.dk> X-OS: FreeBSD 6.0-STABLE User-Agent: Mutt/1.5.11 X-Virus-Scanned: by XS4ALL Virus Scanner Cc: thron forum , freebsd-current@FreeBSD.ORG, =?iso-8859-1?Q?S=F8ren?= Schmidt Subject: Re: Adaptec SATA 1205sa support for FreeBSD 6.0 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, 15 Dec 2005 21:18:47 -0000 On Thu, Dec 15, 2005 at 09:42:05PM +0100, Sren Schmidt wrote.. > Wilko Bulte wrote: > >On Thu, Dec 15, 2005 at 09:07:26PM +0100, Sren Schmidt wrote.. > > > >>thron forum wrote: > >> > >> > >>>Does the current release support the Adaptec SATA 1205sa card? I have > >>>searched the Freebsd site as well as Google.com/bsd and I cant find the > >>>card. > >>> > >>> > >> > >>The 1205 is based on the SiI3112 SATA chip and is as such supported. > >>However, that chip is with a fair margin the worst piece of crap you can > >>buy for money IMNHO. > >>Get a real SATA controller and spare yourself the trouble, headackes > >>etc... > > > > > >Soren, what would you recommend for a plain SATA controller? > > Something Promise, a tx2 or tx4 depending on channels needed. > > >And what for one that can do true RAID1? > > Define true RAID1 ? > > All RAID1's that ATA supports are sofware based, any controller can do > here, unless you want to boot from it, you'd go for one that has BIOS > support for RAID like the Promise TX2200.. Well, yes, booting is the issue yes. Seems in .NL TX2200 has become a rare breed. Would a TX2300 also do? -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Dec 15 21:19:19 2005 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 7E04016A41F; Thu, 15 Dec 2005 21:19:19 +0000 (GMT) (envelope-from sos@deepcore.dk) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E4EC43D72; Thu, 15 Dec 2005 21:19:18 +0000 (GMT) (envelope-from sos@deepcore.dk) Received: from [194.192.25.142] (spider.deepcore.dk [194.192.25.142]) by spider.deepcore.dk (8.13.4/8.13.4) with ESMTP id jBFLJF8W039382; Thu, 15 Dec 2005 22:19:15 +0100 (CET) (envelope-from sos@deepcore.dk) Message-ID: <43A1DDD3.70302@deepcore.dk> Date: Thu, 15 Dec 2005 22:19:15 +0100 From: =?UTF-8?B?U8O4cmVuIFNjaG1pZHQ=?= User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: thron forum References: <20051215205250.82569.qmail@web35908.mail.mud.yahoo.com> In-Reply-To: <20051215205250.82569.qmail@web35908.mail.mud.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-mail-scanned: by DeepCore Virus & Spam killer v1.16 Cc: freebsd-current@FreeBSD.ORG, =?UTF-8?B?IlwiU++/vXJlblwiIFNjaG1pZHQi?= Subject: Re: Adaptec SATA 1205sa support for FreeBSD 6.0 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, 15 Dec 2005 21:19:19 -0000 thron forum wrote: > Hum.. thats not incourging. So what driver supports the card? The ATA driver has support for most chips, including the 3112... However, Adaptec may use an "alien" PCI ID, I have some of them but it might not be all. let me know if its not found.. -Søren From owner-freebsd-current@FreeBSD.ORG Thu Dec 15 21:26:32 2005 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 86CEE16A41F for ; Thu, 15 Dec 2005 21:26:32 +0000 (GMT) (envelope-from sos@deepcore.dk) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2CB5D43D7D for ; Thu, 15 Dec 2005 21:26:22 +0000 (GMT) (envelope-from sos@deepcore.dk) Received: from [194.192.25.142] (spider.deepcore.dk [194.192.25.142]) by spider.deepcore.dk (8.13.4/8.13.4) with ESMTP id jBFLQFEg039509; Thu, 15 Dec 2005 22:26:15 +0100 (CET) (envelope-from sos@deepcore.dk) Message-ID: <43A1DF77.4040307@deepcore.dk> Date: Thu, 15 Dec 2005 22:26:15 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Wilko Bulte References: <20051215194325.49909.qmail@web35908.mail.mud.yahoo.com> <43A1CCFE.10705@FreeBSD.org> <20051215201737.GA10846@freebie.xs4all.nl> <43A1D51D.7070804@deepcore.dk> <20051215211842.GA11418@freebie.xs4all.nl> In-Reply-To: <20051215211842.GA11418@freebie.xs4all.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-mail-scanned: by DeepCore Virus & Spam killer v1.16 Cc: freebsd-current@FreeBSD.ORG Subject: Re: Adaptec SATA 1205sa support for FreeBSD 6.0 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, 15 Dec 2005 21:26:32 -0000 Wilko Bulte wrote: >>All RAID1's that ATA supports are sofware based, any controller can do >>here, unless you want to boot from it, you'd go for one that has BIOS >>support for RAID like the Promise TX2200.. > > Well, yes, booting is the issue yes. Seems in .NL TX2200 has become a rare > breed. Would a TX2300 also do? It should, I might not have all the PCI ID's in there yet (new ones keep popping up), but the support code is there, just needs the PCI ID in case its not found. -Sřren From owner-freebsd-current@FreeBSD.ORG Thu Dec 15 21:31:07 2005 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 D83B116A41F for ; Thu, 15 Dec 2005 21:31:07 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32F9343D45 for ; Thu, 15 Dec 2005 21:31:07 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 3893996 for multiple; Thu, 15 Dec 2005 16:29:03 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jBFLUxpN072215; Thu, 15 Dec 2005 16:31:00 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Anish Mistry Date: Thu, 15 Dec 2005 16:31:25 -0500 User-Agent: KMail/1.8.2 References: <200512141720.01572.jhb@freebsd.org> <200512150033.13676.mistry.7@osu.edu> In-Reply-To: <200512150033.13676.mistry.7@osu.edu> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_uCeoDlAN+5erUK+" Message-Id: <200512151631.26253.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1210/Thu Dec 15 10:23:22 2005 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: freebsd-current@freebsd.org Subject: Re: hostb(4) and vgapci(4) 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: Thu, 15 Dec 2005 21:31:08 -0000 --Boundary-00=_uCeoDlAN+5erUK+ Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Thursday 15 December 2005 12:32 am, Anish Mistry wrote: > On Wednesday 14 December 2005 05:20 pm, John Baldwin wrote: > > I have a patch that is an attempt to untangle a few things in > > relation to Host-PCI bridges and VGA PCI devices. Basically, the > > change is to create a more "real" hostb driver as well as a new > > vgapci driver and to change agp, drm, and acpi_video to attach to > > these drivers. This means among other things: > > > > - In theory you can now kldload agp after boot since it still has a > > place to attach to. > > - i830/915 drm is no longer a child of agp, instead both become > > children of vgapci0. > > - You can now use acpi_video with drm as both attach as children of > > vgapci0. - This provides a way for us to possibly solve the DPMS > > problem for suspend/resume (including a cleaner way to do the hack > > dpms patch I posted to acpi@ a long while ago that several people > > still use). > > > > Some other details include: > > > > - agp devices no longer map the _entire_ aperture into contiguous > > KVA meaning that it might be possible now to use a 256 MB aperture > > without panicing - I've added a new pci_if.m method for locating a > > specific capability for a PCI device. > > > > I have tested this on my laptop and verified that dri still works, > > but it needs some wider testing, especially the i830/i915 case is > > slightly more complicated. Also, this is not going to work with > > the nvidia-driver currently, but that's something that can be fixed > > in the future. If the agp non-mapping does fix the 256 MB aperture > > issues then I will probably MFC that part to RELENG_6. > > > > http://www.FreeBSD.org/~jhb/patches/agp_cvs.patch > > Thank you! It seems to work as advertised. I'm running mach64 DRM > with the DPMS patch acpi_video and they both work. :) > One small problem though. When I unload the acpi_video module and > reload it I get the following: > littleguy# kldload acpi_video > acpi_video0: on vgapci0 > acpi_video1: on vgapci0 > littleguy# kldunload acpi_video > acpi_video0: detached > acpi_video1: detached > littleguy# kldunload acpi_video > kldunload: can't find file acpi_video: No such file or directory > littleguy# kldload acpi_video > acpi_video0: on vgapci0 > acpi_video1: on vgapci0 > acpi_video2: on vgapci0 > littleguy# > It also created multiple sysctls with subsequent loads: > hw.acpi.video.crt0.active: 1 > hw.acpi.video.lcd0.active: 1 > hw.acpi.video.tv0.active: 0 > hw.acpi.video.crt1.active: 1 > hw.acpi.video.lcd1.active: 1 > hw.acpi.video.tv1.active: 0 > hw.acpi.video.crt2.active: 1 > hw.acpi.video.lcd2.active: 1 > hw.acpi.video.tv2.active: 0 Revert just the changes to acpi_video.c and then apply the attached patch to see if it fixes the multiple load issue. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org --Boundary-00=_uCeoDlAN+5erUK+ Content-Type: text/x-diff; charset="iso-8859-6"; name="agp_acpi.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="agp_acpi.patch" --- //depot/vendor/freebsd/src/sys/dev/acpica/acpi_video.c 2005/09/11 18:40:38 +++ //depot/user/jhb/agp/dev/acpica/acpi_video.c 2005/12/15 18:47:57 @@ -70,6 +70,7 @@ /* interfaces */ static int acpi_video_modevent(struct module*, int, void *); +static void acpi_video_identify(driver_t *driver, device_t parent); static int acpi_video_probe(device_t); static int acpi_video_attach(device_t); static int acpi_video_detach(device_t); @@ -137,6 +138,7 @@ #define DSS_COMMIT (1 << 31) static device_method_t acpi_video_methods[] = { + DEVMETHOD(device_identify, acpi_video_identify), DEVMETHOD(device_probe, acpi_video_probe), DEVMETHOD(device_attach, acpi_video_attach), DEVMETHOD(device_detach, acpi_video_detach), @@ -152,7 +154,7 @@ static devclass_t acpi_video_devclass; -DRIVER_MODULE(acpi_video, pci, acpi_video_driver, acpi_video_devclass, +DRIVER_MODULE(acpi_video, vgapci, acpi_video_driver, acpi_video_devclass, acpi_video_modevent, NULL); MODULE_DEPEND(acpi_video, acpi, 1, 1, 1); @@ -189,6 +191,25 @@ return (err); } +static void +acpi_video_identify(driver_t *driver, device_t parent) +{ + devclass_t dc; + device_t *children; + int count, i; + + dc = devclass_find("acpi_video"); + if (device_get_children(parent, &children, &count) != 0) + return; + for (i = 0; i < count; i++) { + if (device_get_devclass(children[i]) == dc) + break; + } + free(children, M_TEMP); + if (i == count) + device_add_child(parent, "acpi_video", -1); +} + static int acpi_video_probe(device_t dev) { --Boundary-00=_uCeoDlAN+5erUK+-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 15 21:41:48 2005 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 D584416A41F for ; Thu, 15 Dec 2005 21:41:48 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from smtp-vbr3.xs4all.nl (smtp-vbr3.xs4all.nl [194.109.24.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id A93D643D8D for ; Thu, 15 Dec 2005 21:41:32 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp-vbr3.xs4all.nl (8.13.3/8.13.3) with ESMTP id jBFLfUXE096378; Thu, 15 Dec 2005 22:41:30 +0100 (CET) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.13.4/8.13.3) with ESMTP id jBFLfTpG011797; Thu, 15 Dec 2005 22:41:29 +0100 (CET) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.13.4/8.13.1/Submit) id jBFLfT7G011796; Thu, 15 Dec 2005 22:41:29 +0100 (CET) (envelope-from wb) Date: Thu, 15 Dec 2005 22:41:29 +0100 From: Wilko Bulte To: =?iso-8859-1?Q?S=F8ren?= Schmidt Message-ID: <20051215214129.GA11777@freebie.xs4all.nl> References: <20051215194325.49909.qmail@web35908.mail.mud.yahoo.com> <43A1CCFE.10705@FreeBSD.org> <20051215201737.GA10846@freebie.xs4all.nl> <43A1D51D.7070804@deepcore.dk> <20051215211842.GA11418@freebie.xs4all.nl> <43A1DF77.4040307@deepcore.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43A1DF77.4040307@deepcore.dk> X-OS: FreeBSD 6.0-STABLE User-Agent: Mutt/1.5.11 X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-current@FreeBSD.ORG Subject: Re: Adaptec SATA 1205sa support for FreeBSD 6.0 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, 15 Dec 2005 21:41:48 -0000 On Thu, Dec 15, 2005 at 10:26:15PM +0100, Sren Schmidt wrote.. > Wilko Bulte wrote: > > >>All RAID1's that ATA supports are sofware based, any controller can do > >>here, unless you want to boot from it, you'd go for one that has BIOS > >>support for RAID like the Promise TX2200.. > > > >Well, yes, booting is the issue yes. Seems in .NL TX2200 has become a rare > >breed. Would a TX2300 also do? > > It should, I might not have all the PCI ID's in there yet (new ones keep > popping up), but the support code is there, just needs the PCI ID in > case its not found. OK. I ordered a 2300 and will let you know what develops :) -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Dec 15 21:13:31 2005 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 530D516A420 for ; Thu, 15 Dec 2005 21:13:31 +0000 (GMT) (envelope-from fcash-ml@sd73.bc.ca) Received: from smtp.sd73.bc.ca (smtp.sd73.bc.ca [142.24.13.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C3E343D55 for ; Thu, 15 Dec 2005 21:13:30 +0000 (GMT) (envelope-from fcash-ml@sd73.bc.ca) Received: from localhost (localhost [127.0.0.1]) by localhost.sd73.bc.ca (Postfix) with ESMTP id DC0D78A0021 for ; Thu, 15 Dec 2005 13:13:13 -0800 (PST) Received: from smtp.sd73.bc.ca ([127.0.0.1]) by localhost (smtp.sd73.bc.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 34149-01-5 for ; Thu, 15 Dec 2005 13:13:12 -0800 (PST) Received: from s157.sbo (unknown [192.168.0.157]) by smtp.sd73.bc.ca (Postfix) with ESMTP id 430B38A0118 for ; Thu, 15 Dec 2005 13:13:12 -0800 (PST) From: Freddie Cash Organization: School District 73 To: freebsd-current@freebsd.org Date: Thu, 15 Dec 2005 13:13:27 -0800 User-Agent: KMail/1.8.3 References: <20051215194325.49909.qmail@web35908.mail.mud.yahoo.com> <20051215201737.GA10846@freebie.xs4all.nl> <6.2.3.4.0.20051215155422.0824bc48@64.7.153.2> In-Reply-To: <6.2.3.4.0.20051215155422.0824bc48@64.7.153.2> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512151313.27735.fcash-ml@sd73.bc.ca> X-Virus-Scanned: by amavisd-new using ClamAV at sd73.bc.ca X-Mailman-Approved-At: Thu, 15 Dec 2005 22:27:28 +0000 Subject: Re: Adaptec SATA 1205sa support for FreeBSD 6.0 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, 15 Dec 2005 21:13:31 -0000 On December 15, 2005 12:55 pm, Mike Tancsa wrote: > At 03:17 PM 15/12/2005, Wilko Bulte wrote: > >Soren, what would you recommend for a plain SATA controller? And what > >for one that can do true RAID1? > I am not Soren, but I have been using the 3ware 8500 series for some > time and they work very well under FreeBSD, Linux and Windows in > terms of reliability and reasonable performance. We have a lot of > FreeBSD boxes running on 3ware cards with RAID1 and we like them a > lot.... Especially when it comes time to change out a dead > drive. Painless, easy and so far 100% reliable. We've been using the 3Ware 7000-series of PATA cards with great success as well. Have even managed to get the 3DM management program running on our FreeBSD 5.4 systems. We've tested the LSI MegaRAID 150-6 SATA card in one FreeBSD 5.4 system with good success, but they are giving us all kinds of grief in our RedHat Enterprise Linux 4 AS (32-bit) and Debian Linux 3.1 (32- and 64-bit) systems. -- Freddie Cash, LPIC-1 CCNT CCLP Helpdesk / Network Support Tech. School District 73 (250) 377-HELP [377-4357] fcash-ml@sd73.bc.ca From owner-freebsd-current@FreeBSD.ORG Thu Dec 15 22:52:24 2005 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 824DD16A41F for ; Thu, 15 Dec 2005 22:52:24 +0000 (GMT) (envelope-from dusatko@e-apollo.cz) Received: from mail.e-apollo.cz (mail.e-apollo.cz [212.158.136.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCFE143D53 for ; Thu, 15 Dec 2005 22:52:23 +0000 (GMT) (envelope-from dusatko@e-apollo.cz) Received: from kerio (unknown [10.1.1.5]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mail.e-apollo.cz (Mail) with ESMTP id 5DB5C1F2493 for ; Thu, 15 Dec 2005 23:52:22 +0100 (CET) Received: from relict ([85.160.31.16]) (authenticated user dusatko@e-apollo.cz) by kerio for freebsd-current@freebsd.org; Thu, 15 Dec 2005 23:52:02 +0100 From: =?iso-8859-2?B?SmFuIER1ueF0a28=?= To: Date: Thu, 15 Dec 2005 23:52:18 +0100 Organization: Apollo servis Message-ID: <001401c601ca$35066170$f601a8c0@relict> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <20051215214129.GA11777@freebie.xs4all.nl> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Importance: Normal Subject: WinTV-NOVA-T PCI 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, 15 Dec 2005 22:52:24 -0000 Hello, do you know anyone something about support or know-how for Hauppauge WinTV-NOVA-T PCI card under FreeBSD ? http://www.hauppauge.co.uk/pages/products/data_novatpci.html Thank you Jan From owner-freebsd-current@FreeBSD.ORG Thu Dec 15 23:23:47 2005 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 BF6FD16A41F; Thu, 15 Dec 2005 23:23:47 +0000 (GMT) (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 4C91643D55; Thu, 15 Dec 2005 23:23:46 +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.4/8.13.4) with ESMTP id jBFNNjhd072673; Thu, 15 Dec 2005 18:23:45 -0500 (EST) (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.3/8.13.3) with ESMTP id jBFNNjV9034472; Thu, 15 Dec 2005 18:23:45 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 1EFC57302F; Thu, 15 Dec 2005 18:23:45 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051215232345.1EFC57302F@freebsd-current.sentex.ca> Date: Thu, 15 Dec 2005 18:23:45 -0500 (EST) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on alpha/alpha 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: Thu, 15 Dec 2005 23:23:48 -0000 TB --- 2005-12-15 22:07:58 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-12-15 22:07:58 - starting HEAD tinderbox run for alpha/alpha TB --- 2005-12-15 22:07:58 - cleaning the object tree TB --- 2005-12-15 22:08:27 - checking out the source tree TB --- 2005-12-15 22:08:27 - cd /tinderbox/HEAD/alpha/alpha TB --- 2005-12-15 22:08:27 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-12-15 22:14:23 - building world (CFLAGS=-O2 -pipe) TB --- 2005-12-15 22:14:23 - cd /src TB --- 2005-12-15 22:14:23 - /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 --- 2005-12-15 23:19:20 - generating LINT kernel config TB --- 2005-12-15 23:19:20 - cd /src/sys/alpha/conf TB --- 2005-12-15 23:19:20 - /usr/bin/make -B LINT TB --- 2005-12-15 23:19:20 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-12-15 23:19:20 - cd /src TB --- 2005-12-15 23:19:20 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Dec 15 23:19:21 UTC 2005 >>> 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 -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/dev/ata/ata-dma.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/dev/ata/ata-isa.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/dev/ata/ata-lowlevel.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/dev/ata/ata-pci.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/dev/ata/ata-queue.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /src/sys/dev/ata/ata-raid.c /src/sys/dev/ata/ata-raid.c: In function `ata_raid_via_write_meta': /src/sys/dev/ata/ata-raid.c:3622: warning: cast from pointer to integer of different size *** Error code 1 Stop in /obj/alpha/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-12-15 23:23:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-12-15 23:23:44 - ERROR: failed to build lint kernel TB --- 2005-12-15 23:23:44 - tinderbox aborted TB --- 0.99 user 4.95 system 4546.29 real From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 01:05:53 2005 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 E5F3916A41F; Fri, 16 Dec 2005 01:05:53 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4883943D62; Fri, 16 Dec 2005 01:05:53 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.4/8.13.4) with ESMTP id jBG15pj2090863; Thu, 15 Dec 2005 20:05:51 -0500 (EST) (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.3/8.13.3) with ESMTP id jBG15ptF093067; Thu, 15 Dec 2005 20:05:51 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 7C5307302F; Thu, 15 Dec 2005 20:05:51 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051216010551.7C5307302F@freebsd-current.sentex.ca> Date: Thu, 15 Dec 2005 20:05:51 -0500 (EST) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on amd64/amd64 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, 16 Dec 2005 01:05:54 -0000 TB --- 2005-12-15 23:23:45 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-12-15 23:23:45 - starting HEAD tinderbox run for amd64/amd64 TB --- 2005-12-15 23:23:45 - cleaning the object tree TB --- 2005-12-15 23:24:21 - checking out the source tree TB --- 2005-12-15 23:24:21 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2005-12-15 23:24:21 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-12-15 23:30:19 - building world (CFLAGS=-O2 -pipe) TB --- 2005-12-15 23:30:19 - cd /src TB --- 2005-12-15 23:30:19 - /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 >>> stage 5.1: building 32 bit shim libraries TB --- 2005-12-16 01:00:32 - generating LINT kernel config TB --- 2005-12-16 01:00:32 - cd /src/sys/amd64/conf TB --- 2005-12-16 01:00:32 - /usr/bin/make -B LINT TB --- 2005-12-16 01:00:32 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-12-16 01:00:32 - cd /src TB --- 2005-12-16 01:00:32 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Dec 16 01:00:32 UTC 2005 >>> 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 -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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/dev/ata/ata-dma.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 -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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/dev/ata/ata-isa.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 -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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/dev/ata/ata-lowlevel.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 -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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/dev/ata/ata-pci.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 -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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/dev/ata/ata-queue.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 -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 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/dev/ata/ata-raid.c /src/sys/dev/ata/ata-raid.c: In function `ata_raid_via_write_meta': /src/sys/dev/ata/ata-raid.c:3622: warning: cast from pointer to integer of different size *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-12-16 01:05:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-12-16 01:05:51 - ERROR: failed to build lint kernel TB --- 2005-12-16 01:05:51 - tinderbox aborted TB --- 1.21 user 6.77 system 6126.03 real From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 02:31:16 2005 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 8E69A16A41F; Fri, 16 Dec 2005 02:31:16 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from mail.united-ware.com (am-productions.biz [69.61.164.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0560A43D5C; Fri, 16 Dec 2005 02:31:15 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.100] (am-productions.biz [69.61.164.22]) (authenticated bits=0) by mail.united-ware.com (8.13.4/8.13.4) with ESMTP id jBG2YFu9079293 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 15 Dec 2005 21:34:20 -0500 (EST) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: John Baldwin Date: Thu, 15 Dec 2005 21:33:21 -0500 User-Agent: KMail/1.8.3 References: <200512141720.01572.jhb@freebsd.org> <200512150033.13676.mistry.7@osu.edu> <200512151631.26253.jhb@freebsd.org> In-Reply-To: <200512151631.26253.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1421191.V91OXEagrC"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200512152133.28401.mistry.7@osu.edu> X-Spam-Status: No, score=-10.4 required=5.0 tests=ALL_TRUSTED,BAYES_00, MYFREEBSD2,MYFREEBSD3 autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on mail.united-ware.com X-Virus-Scanned: ClamAV 0.87/1210/Thu Dec 15 10:23:22 2005 on mail.united-ware.com X-Virus-Status: Clean Cc: freebsd-current@freebsd.org Subject: Re: hostb(4) and vgapci(4) 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: Fri, 16 Dec 2005 02:31:16 -0000 --nextPart1421191.V91OXEagrC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 15 December 2005 04:31 pm, you wrote: > On Thursday 15 December 2005 12:32 am, Anish Mistry wrote: > > On Wednesday 14 December 2005 05:20 pm, John Baldwin wrote: > > > I have a patch that is an attempt to untangle a few things in > > > relation to Host-PCI bridges and VGA PCI devices. Basically, > > > the change is to create a more "real" hostb driver as well as a > > > new vgapci driver and to change agp, drm, and acpi_video to > > > attach to these drivers. This means among other things: > > > > > > - In theory you can now kldload agp after boot since it still > > > has a place to attach to. > > > - i830/915 drm is no longer a child of agp, instead both become > > > children of vgapci0. > > > - You can now use acpi_video with drm as both attach as > > > children of vgapci0. - This provides a way for us to possibly > > > solve the DPMS problem for suspend/resume (including a cleaner > > > way to do the hack dpms patch I posted to acpi@ a long while > > > ago that several people still use). > > > > > > Some other details include: > > > > > > - agp devices no longer map the _entire_ aperture into > > > contiguous KVA meaning that it might be possible now to use a > > > 256 MB aperture without panicing - I've added a new pci_if.m > > > method for locating a specific capability for a PCI device. > > > > > > I have tested this on my laptop and verified that dri still > > > works, but it needs some wider testing, especially the > > > i830/i915 case is slightly more complicated. Also, this is not > > > going to work with the nvidia-driver currently, but that's > > > something that can be fixed in the future. If the agp > > > non-mapping does fix the 256 MB aperture issues then I will > > > probably MFC that part to RELENG_6. > > > > > > http://www.FreeBSD.org/~jhb/patches/agp_cvs.patch > > > > Thank you! It seems to work as advertised. I'm running mach64 > > DRM with the DPMS patch acpi_video and they both work. :) > > One small problem though. When I unload the acpi_video module > > and reload it I get the following: > > littleguy# kldload acpi_video > > acpi_video0: on vgapci0 > > acpi_video1: on vgapci0 > > littleguy# kldunload acpi_video > > acpi_video0: detached > > acpi_video1: detached > > littleguy# kldunload acpi_video > > kldunload: can't find file acpi_video: No such file or directory > > littleguy# kldload acpi_video > > acpi_video0: on vgapci0 > > acpi_video1: on vgapci0 > > acpi_video2: on vgapci0 > > littleguy# > > It also created multiple sysctls with subsequent loads: > > hw.acpi.video.crt0.active: 1 > > hw.acpi.video.lcd0.active: 1 > > hw.acpi.video.tv0.active: 0 > > hw.acpi.video.crt1.active: 1 > > hw.acpi.video.lcd1.active: 1 > > hw.acpi.video.tv1.active: 0 > > hw.acpi.video.crt2.active: 1 > > hw.acpi.video.lcd2.active: 1 > > hw.acpi.video.tv2.active: 0 > > Revert just the changes to acpi_video.c and then apply the attached > patch to see if it fixes the multiple load issue. Yes. The patch corrects the problem. Thanks, =2D-=20 Anish Mistry --nextPart1421191.V91OXEagrC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDoid4xqA5ziudZT0RAihVAJ90ETIsXJdNc5cVrkTfmqhJih+D+wCeMH+f 74tUWosdc0rBhmvIU5df9U8= =QfsN -----END PGP SIGNATURE----- --nextPart1421191.V91OXEagrC-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 03:27:57 2005 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 3EF5A16A41F; Fri, 16 Dec 2005 03:27:57 +0000 (GMT) (envelope-from wsk@gddsn.org.cn) Received: from gddsn.org.cn (gddsn.org.cn [218.19.164.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74B3D43D4C; Fri, 16 Dec 2005 03:27:51 +0000 (GMT) (envelope-from wsk@gddsn.org.cn) Received: from ns.gddsn.org.cn (localhost [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gddsn.org.cn (Postfix) with ESMTP id 3920B38CB41; Fri, 16 Dec 2005 11:27:48 +0800 (CST) Received: (from www@localhost) by ns.gddsn.org.cn (8.12.11/8.12.11/Submit) id jBG3Rlqp003315; Fri, 16 Dec 2005 11:27:47 +0800 (CST) (envelope-from wsk@gddsn.org.cn) X-Authentication-Warning: ns.gddsn.org.cn: www set sender to wsk@gddsn.org.cn using -f Received: from 218.19.164.157 ([218.19.164.157]) by gddsn.org.cn (IMP) with HTTP for ; Fri, 16 Dec 2005 11:27:47 +0800 Message-ID: <1134703667.43a23433b9aff@gddsn.org.cn> Date: Fri, 16 Dec 2005 11:27:47 +0800 From: wsk@gddsn.org.cn To: jhb@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 / FreeBSD-4.10 X-Originating-IP: 218.19.164.157 X-Mailman-Approved-At: Fri, 16 Dec 2005 03:38:02 +0000 Cc: hareware@freebsd.org, current@freebsd.org Subject: Re: Can support Intel's E8500 chipset on freebsd??? 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, 16 Dec 2005 03:27:57 -0000 jhb wrote: > lists: > with DELL PE6850, It seems 6.0 Can't support the > Intel's E8500 XMB chipset >What doesn't work? > pciconf -lv: > none0@pci0:9:0: class=0x050000 card=0x01701028 chip=0x26208086 rev=0x00 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'E8500 XMB A/B/C/D Identification Registers' > class = memory > subclass = RAM >These types of devices don't need a driver to work. no i just dislike to see the boot "no driver attached" mesegs :') ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 03:49:22 2005 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 644E716A41F for ; Fri, 16 Dec 2005 03:49:22 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBB1D43D5E for ; Fri, 16 Dec 2005 03:49:21 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id B6DFD72DDB; Thu, 15 Dec 2005 19:49:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id B157B72DD9; Thu, 15 Dec 2005 19:49:21 -0800 (PST) Date: Thu, 15 Dec 2005 19:49:21 -0800 (PST) From: Doug White To: eculp@bafirst.com In-Reply-To: <20051215131341.d0vnxkjw4kc480w8@mail.bafirst.com> Message-ID: <20051215194820.U96052@carver.gumbysoft.com> References: <200512151356.41550.jhb@freebsd.org> <20051215131341.d0vnxkjw4kc480w8@mail.bafirst.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-current@freebsd.org Subject: Re: skype-1.2.0.18-static for linux and FreeBSD 7.0 CURRENT 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, 16 Dec 2005 03:49:22 -0000 On Thu, 15 Dec 2005 eculp@bafirst.com wrote: > Quoting John Baldwin : > > > On Thursday 15 December 2005 11:00 am, Goran Gajic wrote: > >> Hi, > >> > >> I have figgured out, adding: > >> > >> options DEBUG_LOCKS > >> options DEBUG_VFS_LOCKS > >> > >> to the GENERIC config will efectevly cause skype to reboot 7.0-CURRENT > >> when username and password are entered at skype login. > >> > >> this has nothing to do with panic caused by kldunload linux.ko I have > >> reported earlier. > >> > >> > >> Reagrds, > >> Goran Gajic > > > > If you are in X this is probably a panic (currently the kernel doesn't create > > a coredump while you are in X which is a bug). Can you hook up a serial > > console and use that to get the panic message? > > I've been seeing this problem on current for a while but the strange > part about my reboot is that it is only when running KDE. I can start > and stop skype in Gnome and twm with no problem. KDE typically uses ARTS for its sound system backend .. its possible that ARTS and skype don't play well and end up triggering a nasty bug in the sound driver. Try disabling the sound system support from within KDE, then log out and log back in and try skype again. If that works then we need to figure out what the collision between arts and skype is. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 06:24:39 2005 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 3CE9A16A41F; Fri, 16 Dec 2005 06:24:39 +0000 (GMT) (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 C651743D70; Fri, 16 Dec 2005 06:24:30 +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.4/8.13.4) with ESMTP id jBG6OTkd002200; Fri, 16 Dec 2005 01:24:29 -0500 (EST) (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.3/8.13.3) with ESMTP id jBG6OTbk062911; Fri, 16 Dec 2005 01:24:29 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E31AC7302F; Fri, 16 Dec 2005 01:24:28 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051216062428.E31AC7302F@freebsd-current.sentex.ca> Date: Fri, 16 Dec 2005 01:24:28 -0500 (EST) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner1 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on sparc64/sparc64 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, 16 Dec 2005 06:24:39 -0000 TB --- 2005-12-16 04:52:37 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-12-16 04:52:37 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2005-12-16 04:52:37 - cleaning the object tree TB --- 2005-12-16 04:53:06 - checking out the source tree TB --- 2005-12-16 04:53:06 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2005-12-16 04:53:06 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-12-16 04:59:13 - building world (CFLAGS=-O2 -pipe) TB --- 2005-12-16 04:59:13 - cd /src TB --- 2005-12-16 04:59:13 - /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 --- 2005-12-16 06:18:56 - generating LINT kernel config TB --- 2005-12-16 06:18:56 - cd /src/sys/sparc64/conf TB --- 2005-12-16 06:18:56 - /usr/bin/make -B LINT TB --- 2005-12-16 06:18:56 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-12-16 06:18:56 - cd /src TB --- 2005-12-16 06:18:56 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Dec 16 06:18:57 UTC 2005 >>> 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 -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/dev/ata/ata-dma.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 -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/dev/ata/ata-isa.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 -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/dev/ata/ata-lowlevel.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 -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/dev/ata/ata-pci.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 -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/dev/ata/ata-queue.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 -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /src/sys/dev/ata/ata-raid.c /src/sys/dev/ata/ata-raid.c: In function `ata_raid_via_write_meta': /src/sys/dev/ata/ata-raid.c:3622: warning: cast from pointer to integer of different size *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-12-16 06:24:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-12-16 06:24:28 - ERROR: failed to build lint kernel TB --- 2005-12-16 06:24:28 - tinderbox aborted TB --- 0.98 user 4.82 system 5510.83 real From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 07:04:08 2005 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 158A516A41F; Fri, 16 Dec 2005 07:04:08 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12AD843D66; Fri, 16 Dec 2005 07:04:06 +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 jBG745en016094; Fri, 16 Dec 2005 00:04:05 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <43A266E5.3080103@samsco.org> Date: Fri, 16 Dec 2005 00:04:05 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: current , stable@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: Subject: HEADS UP: Release schedule for 2006 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, 16 Dec 2005 07:04:08 -0000 All, The following is the approximate schedule for FreeBSD releases in 2006: Jan 30: Freeze RELENG_5 and RELENG_6 Mar 20: Release FreeBSD 6.1 Apr 3: Release FreeBSD 5.5 Jun 12: Freeze RELENG_6 Jul 31: Release FreeBSD 6.2 Oct 23: Freeze RELENG_6 Dec 11: Release FreeBSD 6.3 A 'freeze' means that the tree will be closed to changes except with specific approval, and the focus will be on producing, testing, and fixing release candidates. The release dates are targets that we hope to make, but we will continue with the policy of only releasing once all of the showstoppers are cleared, i.e. we will release when it is ready. FreeBSD 5 5.5 will be the final release from the RELENG_5 tree. We are doing it to provide support for users who have committed to FreeBSD 5 and who need more time to transition to FreeBSD 6. However, in order to keep forward progress with FreeBSD 6, we will produce this in parallel with the 6.1 release, and thus it will not be our main focus. Users who are using FreeBSD 5 are strongly encouraged to evaluate FreeBSD 6. After this final release, the security team will provide security update support through 2007. FreeBSD 6 There will be three FreeBSD 6 releases in 2006. It will be our primary focus for bugfixes, performance enhancements, and incremental functionality and driver additions. There will likely be one more release in 2007, after which we will begin focus on FreeBSD 7. FreeBSD 7 We will start preparing for FreeBSD 7.0 in June 2007. I'll hopefully update the release engineering pages soon to reflect this. If you have any questions, please feel free to contact me and the rest of the release engineering team. Thanks!ott Scott From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 08:35:05 2005 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 1E8B216A41F; Fri, 16 Dec 2005 08:35:05 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7912543D55; Fri, 16 Dec 2005 08:35:00 +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 jBG8Ywug016608; Fri, 16 Dec 2005 01:34:59 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <43A27C32.6020501@samsco.org> Date: Fri, 16 Dec 2005 01:34:58 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gary Kline References: <43A266E5.3080103@samsco.org> <20051216082704.GA52634@thought.org> In-Reply-To: <20051216082704.GA52634@thought.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: stable@freebsd.org, current Subject: Re: HEADS UP: Release schedule for 2006 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, 16 Dec 2005 08:35:05 -0000 Gary Kline wrote: > On Fri, Dec 16, 2005 at 12:04:05AM -0700, Scott Long wrote: > >>All, >> >>The following is the approximate schedule for FreeBSD releases in 2006: >> >>Jan 30: Freeze RELENG_5 and RELENG_6 >>Mar 20: Release FreeBSD 6.1 >>Apr 3: Release FreeBSD 5.5 >>Jun 12: Freeze RELENG_6 >>Jul 31: Release FreeBSD 6.2 >>Oct 23: Freeze RELENG_6 >>Dec 11: Release FreeBSD 6.3 >> >>A 'freeze' means that the tree will be closed to changes except with >>specific approval, and the focus will be on producing, testing, and >>fixing release candidates. The release dates are targets that we hope >>to make, but we will continue with the policy of only releasing once >>all of the showstoppers are cleared, i.e. we will release when it is >>ready. >> >>FreeBSD 5 >>5.5 will be the final release from the RELENG_5 tree. We are doing it >>to provide support for users who have committed to FreeBSD 5 and who >>need more time to transition to FreeBSD 6. However, in order to keep >>forward progress with FreeBSD 6, we will produce this in parallel with >>the 6.1 release, and thus it will not be our main focus. Users who are >>using FreeBSD 5 are strongly encouraged to evaluate FreeBSD 6. After >>this final release, the security team will provide security update >>support through 2007. > > > Sounds like an ambitious schedule... All my FBSD servers > are at least up to 5.3; my laptop is happy at 5.4. I have > what I believe to be a rationalquestion. Why should I go > beyond v5.5? More to the point, why can't minor security > tweaks be maintained indefinitely for 5.5? Security updates will be maintained for quite a while. However, it takes manpower to test each proposed security change, so it's very hard to justify doing them 'indefinitely'. The stated policy from the security team is 2 years. So they will probably support 5.5 into 2008, but I wanted to be conservative in my statement in case they have different plans. > What will > releases -6 and -7 offer that can;t reasonably be dropped > into -5? Significant performance and stability enhancements that simply cannot be broken up and backported to FreeBSD 5. We are marching towards a 'Giant-less' kernel, which means continuing better SMP performance and better UP responsiveness. With 6.0 we are finally starting to see the benefit of the SMPng work that we've been doing for 5 years. Scott From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 08:44:54 2005 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 5129716A41F; Fri, 16 Dec 2005 08:44:54 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB6F843D72; Fri, 16 Dec 2005 08:44:39 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id jBG8iGqW059538; Fri, 16 Dec 2005 10:44:16 +0200 (EET) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 72538-01; Fri, 16 Dec 2005 10:44:11 +0200 (EET) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id jBG8aohm059373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Dec 2005 10:36:50 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.4/8.13.4) id jBG8avXK023513; Fri, 16 Dec 2005 10:36:57 +0200 (EET) (envelope-from ru) Date: Fri, 16 Dec 2005 10:36:57 +0200 From: Ruslan Ermilov To: Artemiev Igor Message-ID: <20051216083657.GA41326@ip.net.ua> References: <200512141749.jBEHnjRV081112@repoman.freebsd.org> <20051214183345.GE51686@ip.net.ua> <20051215093643.694e995b.ai@bmc.brk.ru> <200512151306.57961.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LQksG6bCIzRHxTLp" Content-Disposition: inline In-Reply-To: <200512151306.57961.jhb@freebsd.org> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua Cc: current@freebsd.org Subject: Re: cvs commit: src/sys/pci amdpm.c 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, 16 Dec 2005 08:44:54 -0000 --LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 15, 2005 at 01:06:57PM -0500, John Baldwin wrote: > On Thursday 15 December 2005 01:36 am, Artemiev Igor wrote: > > > No go on Asus SK8N: > > > > > > amdpm0: port > > > 0x5000-0x503f,0x5040-0x507f,0x5000-0x501f at device 1.1 on pci0 > > > amdpm0: could not map i/o space device_attach: amdpm0 attach returned > > > 6 > > > > > > ... with amdpm.ko loaded from the loader or from multiuser, > > > does not matter. > > > > > > amdpm0@pci0:1:1: class=3D0x0c0500 card=3D0x80c51043 > > > chip=3D0x00d410de rev=3D0xa4 hdr=3D0x00 vendor =3D 'NVIDIA Corporat= ion' > > > device =3D 'nForce MCP3? SMBus Controller' > > > class =3D serial bus > > > subclass =3D SMBus > > > > > > Has this been ported from Linux, or do you have specs available > > > for these parts? (I never succeeded in finding them.) > > > > I do not have a full documentation on this chipset, I used an > > lm_sensors' sources when writing driver. Because their algorithms were > > very close, and in lm_sensors support for nForce3/ nForce4 was > > declared, I've added them too, but didn't test it. Soon I'll get myself > > a motherboard with nForce3, then I will be able to check those > > problems. Right now, I think that it may be something with ACPI. > > Probably, chipsets revisions are different. I'll investigate it further. > > Also, there is a chance something is wrong with a size of a bus > > resource block, allocated at PCI bus for the device. I was thinking > > that the memory size will be similar to AMD-8111, and it was so for > > nForce2. Yet, for the new versions the assumption is probably false. > > Try this patch: > > http://stalker.bmc.brk.ru/~ai/patches/amdpm.nforce34.diff >=20 OK, I looked some more, and I doubt the usefullness of the nForce-2/3/4 support in its current shape. Perhaps I'm mistaken and you can shed a light on this. :-) The amdpm(4) driver originally supported AMD-756's PMC SMBus 1.0. Later, AMD-8111 support was added. All of these AMDs seem to support both SMBus 2.0 and SMBus 1.0 interfaces, and the driver uses the SMBus 1.0 interface (offset 0xe0). The nForce seems to also support SMBus 1.0 interface (offset 0). At least, the following lm_sensors pages amd AMD-8111 datasheet confirm this: http://www.lm-sensors.org/supported.html http://www2.lm-sensors.nu/~lm78/cvs/lm_sensors2/doc/busses/i2c-amd756 http://www2.lm-sensors.nu/~lm78/cvs/lm_sensors2/doc/busses/i2c-amd8111 Now, the same supported.html page and googling says that nForce2/3/4 MCPs all use SMBus 2.0 interface similar to AMD-8111 SMBus 2.0 interface. But we don't support SMBus 2.0 interface in amdpm(4)! (lm_sensors, OTOH, does implement SMBus 2.0.). Now about xmbmon... The SMBus support in xmbmon is exclusively for FreeBSD, and AMD-8111/nForce2 support through SMBus was added at the same time: ChangeLog: * The AMD8111 and NVidia nForce2 SMBus access is supported (by information from Alex van Kaam). Obviously, nForce2 couldn't have been tested with an unpatched amdpm.c, so I don't know what magic Alex van Kaam used to test nForce2 SMBus. I don't know about nForce2, perhaps it implements SMBus 1.0 similar to nForce (I can't find information anywhere), but it doesn't match lm_sensors sources which uses SMBus 2.0 on nForce2/3/4, and uses different drivers for AMD-8111(SMBus 1.0)/nForce and nForce2/3/4. Igor, can you show me the output of "mbmon -S -c10 1" on your nForce2 based machine? Because, like I said, I get the nonsense with nForce3 Pro150, after solving the "could not map i/o space" problem, and I think this may be due to accessing SMBus 2.0 as SMBus 1.0. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --LQksG6bCIzRHxTLp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDonypqRfpzJluFF4RAvODAJ9UlNm45Glc+ge4xc6+w+HH5mBAuwCeOGOT 9ZI3C8Dzry8F23l5BC+QIeo= =1lVP -----END PGP SIGNATURE----- --LQksG6bCIzRHxTLp-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 09:17:14 2005 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 C150F16A41F for ; Fri, 16 Dec 2005 09:17:14 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mail2.fluidhosting.com [204.14.90.12]) by mx1.FreeBSD.org (Postfix) with SMTP id 6164B43D53 for ; Fri, 16 Dec 2005 09:17:13 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 92321 invoked by uid 399); 16 Dec 2005 09:17:12 -0000 Received: from localhost (HELO ?192.168.1.101?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 16 Dec 2005 09:17:12 -0000 Message-ID: <43A28616.8010900@FreeBSD.org> Date: Fri, 16 Dec 2005 01:17:10 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5 (X11/20051203) MIME-Version: 1.0 To: Gary Kline References: <43A266E5.3080103@samsco.org> <20051216082704.GA52634@thought.org> In-Reply-To: <20051216082704.GA52634@thought.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, current Subject: Re: HEADS UP: Release schedule for 2006 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, 16 Dec 2005 09:17:14 -0000 Gary Kline wrote: > Sounds like an ambitious schedule... All my FBSD servers > are at least up to 5.3; my laptop is happy at 5.4. I have > what I believe to be a rationalquestion. Why should I go > beyond v5.5? There is one school of thought that says you shouldn't. If it works for you, there is no real need to upgrade. > More to the point, why can't minor security > tweaks be maintained indefinitely for 5.5? We don't support any branch of FreeBSD indefinitely. > What will > releases -6 and -7 offer that can;t reasonably be dropped > into -5? New features that require protocol/ABI changes, etc. for one. For example, I'm working on adding ports/local rc.d scripts to the overall rcorder, and that change won't go back into RELENG_5 because it constitutes a major paradigm shift, and we don't mess with -stable branches in that way. hth, Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 09:50:06 2005 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 106E016A425; Fri, 16 Dec 2005 09:50:06 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id C3F1743D5D; Fri, 16 Dec 2005 09:50:00 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by smtp6-g19.free.fr (Postfix) with ESMTP id 0C33B18194; Fri, 16 Dec 2005 10:49:57 +0100 (CET) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 10C3E9B6E7; Fri, 16 Dec 2005 01:39:56 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id D63C8405A; Fri, 16 Dec 2005 02:39:55 +0100 (CET) Date: Fri, 16 Dec 2005 02:39:55 +0100 From: Jeremie Le Hen To: Doug Barton Message-ID: <20051216013955.GW3512@obiwan.tataz.chchile.org> References: <200512022006.jB2K67AK078509@repoman.freebsd.org> <20051203004057.GA20872@nagual.pp.ru> <4390EFB6.3090307@FreeBSD.org> <20051203012324.GA34147@nagual.pp.ru> <4390F9A2.208@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4390F9A2.208@FreeBSD.org> User-Agent: Mutt/1.5.11 Cc: freebsd-current@FreeBSD.ORG Subject: Re: cvs commit: src/etc rc rc.shutdown rc.subr src/etc/rc.d localpkg src/sys/sys param.h 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, 16 Dec 2005 09:50:06 -0000 Hi, Doug, On Fri, Dec 02, 2005 at 05:49:22PM -0800, Doug Barton wrote: > > Typical problem for porter (like me) is not knowing deeps of rc.d > > subsystem. To be more specific, personally me can't make 'apache13' port > > do its limits without damaging main rc shell in the same time. If you can, > > please look 'apache13' port and feel free to fix rc script there. > > I'm sorry if I wasn't clear before, the only thing port authors need to do > for properly functioning rc.d-style scripts is to install them as foo > instead of foo.sh. I have attached an untested patch for apache13 that > should do the trick, or at least show you what I have in mind. > > At some point down the road, when we've dropped support for releases prior > to 6.1, this will simply be the way that all such scripts are installed, but > between now and then, there will be some transition pain involved. When I first read your mail on arch@ I didn't think about it, but now I'm reading this thread, it stirs my mind. RELENG_6 is supposed to be very stable. Though the ultimate stability would be to stay in RELENG_6_0, I think MFC'ing those changes to RELENG_6 would cause much pain to system administrators who will be upgrading from 6.0 to 6.1 if they don't not update their apache13 port accordingly. I mean this would require a bold flashing note in UPDATING. However this still implies the 350 dragging ports to be updated in time for 6.1. IMHO this update might be degrade the excellent image of the FreeBSD Release Engineering. -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 09:50:06 2005 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 1E8D616A422 for ; Fri, 16 Dec 2005 09:50:06 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from smtp2-g19.free.fr (smtp2-g19.free.fr [212.27.42.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id E448743D60 for ; Fri, 16 Dec 2005 09:50:00 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by smtp2-g19.free.fr (Postfix) with ESMTP id 6BF906CC2F; Fri, 16 Dec 2005 10:49:57 +0100 (CET) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 9DD829BB79; Fri, 16 Dec 2005 01:10:20 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 65E26405A; Fri, 16 Dec 2005 02:10:20 +0100 (CET) Date: Fri, 16 Dec 2005 02:10:20 +0100 From: Jeremie Le Hen To: Brian Candler Message-ID: <20051216011020.GV3512@obiwan.tataz.chchile.org> References: <20051201095426.GD17378@uk.tiscali.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051201095426.GD17378@uk.tiscali.com> User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org Subject: Re: current@ and freebsd-current@ 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, 16 Dec 2005 09:50:06 -0000 Hi, > I see a number of mails cross-posted to current@freebsd.org and > freebsd-current@freebsd.org, and so get two copies in the freebsd-current > digest I receive. > > Is there any reason to have two addresses pointing at this list? As far as I > can see from the web, 'freebsd-current@' is the advertised address. If > current@ is a legacy hangover, could it be killed? I suppose both exist for historical reasons. However the correct mailing-lists addresses are the form freebsd-*@FreeBSD.org. The simple reason is coherency among all mailing-lists : freebsd-security@FreeBSD.org is not the same as security@FreeBSD.org which points to the FreeBSD Security Officer (so@FreeBSD.org) IIRC. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 09:54:02 2005 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 147E816A41F; Fri, 16 Dec 2005 09:54:02 +0000 (GMT) (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 4DC4043D64; Fri, 16 Dec 2005 09:53:59 +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 B65D41A3C1C; Fri, 16 Dec 2005 01:53:58 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 0765E51258; Fri, 16 Dec 2005 04:53:58 -0500 (EST) Date: Fri, 16 Dec 2005 04:53:57 -0500 From: Kris Kennaway To: Jeremie Le Hen Message-ID: <20051216095357.GA61789@xor.obsecurity.org> References: <200512022006.jB2K67AK078509@repoman.freebsd.org> <20051203004057.GA20872@nagual.pp.ru> <4390EFB6.3090307@FreeBSD.org> <20051203012324.GA34147@nagual.pp.ru> <4390F9A2.208@FreeBSD.org> <20051216013955.GW3512@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/9DWx/yDrRhgMJTb" Content-Disposition: inline In-Reply-To: <20051216013955.GW3512@obiwan.tataz.chchile.org> User-Agent: Mutt/1.4.2.1i Cc: Doug Barton , freebsd-current@FreeBSD.ORG Subject: Re: cvs commit: src/etc rc rc.shutdown rc.subr src/etc/rc.d localpkg src/sys/sys param.h 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, 16 Dec 2005 09:54:02 -0000 --/9DWx/yDrRhgMJTb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 16, 2005 at 02:39:55AM +0100, Jeremie Le Hen wrote: > Hi, Doug, >=20 > On Fri, Dec 02, 2005 at 05:49:22PM -0800, Doug Barton wrote: > > > Typical problem for porter (like me) is not knowing deeps of rc.d=20 > > > subsystem. To be more specific, personally me can't make 'apache13' p= ort=20 > > > do its limits without damaging main rc shell in the same time. If you= can,=20 > > > please look 'apache13' port and feel free to fix rc script there. > >=20 > > I'm sorry if I wasn't clear before, the only thing port authors need to= do > > for properly functioning rc.d-style scripts is to install them as foo > > instead of foo.sh. I have attached an untested patch for apache13 that > > should do the trick, or at least show you what I have in mind. > >=20 > > At some point down the road, when we've dropped support for releases pr= ior > > to 6.1, this will simply be the way that all such scripts are installed= , but > > between now and then, there will be some transition pain involved. >=20 > When I first read your mail on arch@ I didn't think about it, but now > I'm reading this thread, it stirs my mind. RELENG_6 is supposed to > be very stable. Though the ultimate stability would be to stay in > RELENG_6_0, I think MFC'ing those changes to RELENG_6 would cause much > pain to system administrators who will be upgrading from 6.0 to 6.1 if > they don't not update their apache13 port accordingly. Similar changes to ports are ongoing all the time, so I don't think this argument is a very good one. Kris --/9DWx/yDrRhgMJTb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDoo61Wry0BWjoQKURAoCpAJ9xN05AVb4puugbPk3GU0rTupE1kwCcD03A 0lo15wQi5fpQBrNGHuLGfqY= =xRKZ -----END PGP SIGNATURE----- --/9DWx/yDrRhgMJTb-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 10:42:29 2005 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 2020716A420; Fri, 16 Dec 2005 10:42:29 +0000 (GMT) (envelope-from ai@bmc.brk.ru) Received: from stalker.bmc.brk.ru (stalker.bmc.brk.ru [217.150.59.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FAB843D49; Fri, 16 Dec 2005 10:42:28 +0000 (GMT) (envelope-from ai@bmc.brk.ru) Date: Fri, 16 Dec 2005 13:42:25 +0300 From: Artemiev Igor To: Ruslan Ermilov Message-Id: <20051216134225.09aa93a3.ai@bmc.brk.ru> In-Reply-To: <20051216083657.GA41326@ip.net.ua> References: <200512141749.jBEHnjRV081112@repoman.freebsd.org> <20051214183345.GE51686@ip.net.ua> <20051215093643.694e995b.ai@bmc.brk.ru> <200512151306.57961.jhb@freebsd.org> <20051216083657.GA41326@ip.net.ua> Organization: Bryansk Medical Center X-Mailer: Sylpheed version 2.0.0beta4 (GTK+ 2.6.8; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: cvs commit: src/sys/pci amdpm.c 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, 16 Dec 2005 10:42:29 -0000 > OK, I looked some more, and I doubt the usefullness of the > nForce-2/3/4 support in its current shape. Perhaps I'm mistaken and > you can shed a light on this. :-) > The amdpm(4) driver originally supported AMD-756's PMC SMBus 1.0. > Later, AMD-8111 support was added. All of these AMDs seem to support > both SMBus 2.0 and SMBus 1.0 interfaces, and the driver uses the SMBus > 1.0 interface (offset 0xe0). The nForce seems to also support SMBus > 1.0 interface (offset 0). At least, the following lm_sensors pages > amd AMD-8111 datasheet confirm this: > > http://www.lm-sensors.org/supported.html > http://www2.lm-sensors.nu/~lm78/cvs/lm_sensors2/doc/busses/i2c-amd756 > http://www2.lm-sensors.nu/~lm78/cvs/lm_sensors2/doc/busses/i2c-amd8111 > > Now, the same supported.html page and googling says that nForce2/3/4 > MCPs all use SMBus 2.0 interface similar to AMD-8111 SMBus 2amd86.0 > interface. But we don't support SMBus 2.0 interface in amdpm(4)! > (lm_sensors, OTOH, does implement SMBus 2.0.). i2c-amd756.c, i2c-amd8111.c and i2c-nforce2.c looks very similar for me. Differences between i2c-amd756 and i2c-nforce2.c/i2c-amd8111.c in pair ioctl. > I don't know about nForce2, perhaps it implements SMBus 1.0 similar to > nForce (I can't find information anywhere), but it doesn't match > lm_sensors sources which uses SMBus 2.0 on nForce2/3/4, and uses > different drivers for AMD-8111(SMBus 1.0)/nForce and nForce2/3/4. > Igor, can you show me the output of "mbmon -S -c10 1" on your nForce2 Sorry, i can make this only tomorow. > based machine? Because, like I said, I get the nonsense with nForce3 > Pro150, after solving the "could not map i/o space" problem, and I > think this may be due to accessing SMBus 2.0 as SMBus 1.0. Burp. I guess, nForce3 have the overlapped regions, it`s not a problem SMBus v1.0 vs SMBus 2.0 at bus resource allocation time. In any time, i`m too lame to talk about this now :) -- iprefetch ai From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 11:15:23 2005 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 78BB516A41F; Fri, 16 Dec 2005 11:15:23 +0000 (GMT) (envelope-from matthias.andree@gmx.de) Received: from mail.dt.e-technik.uni-dortmund.de (krusty.dt.E-Technik.Uni-Dortmund.DE [129.217.163.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id B731F43D5A; Fri, 16 Dec 2005 11:15:22 +0000 (GMT) (envelope-from matthias.andree@gmx.de) Received: from localhost (localhost [127.0.0.1]) by mail.dt.e-technik.uni-dortmund.de (Postfix) with ESMTP id 815E7440CE; Fri, 16 Dec 2005 12:15:21 +0100 (CET) Received: from mail.dt.e-technik.uni-dortmund.de ([127.0.0.1]) by localhost (krusty [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14955-03; Fri, 16 Dec 2005 12:15:20 +0100 (CET) Received: from m2a2.dyndns.org (p50912389.dip0.t-ipconnect.de [80.145.35.137]) by mail.dt.e-technik.uni-dortmund.de (Postfix) with ESMTP id CB259440A4; Fri, 16 Dec 2005 12:15:19 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by merlin.emma.line.org (Postfix) with ESMTP id 2EECB20094B; Fri, 16 Dec 2005 12:15:19 +0100 (CET) Received: from m2a2.dyndns.org ([127.0.0.1]) by localhost (m2a2.dyndns.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29815-14; Fri, 16 Dec 2005 12:15:17 +0100 (CET) Received: by merlin.emma.line.org (Postfix, from userid 500) id 2772D200EAA; Fri, 16 Dec 2005 12:15:17 +0100 (CET) From: Matthias Andree To: Craig Rodrigues In-Reply-To: <20051213151908.GA26821@crodrigues.org> (Craig Rodrigues's message of "Tue, 13 Dec 2005 10:19:08 -0500") References: <20051213151908.GA26821@crodrigues.org> X-PGP-Key: http://home.pages.de/~mandree/keys/GPGKEY.asc Date: Fri, 16 Dec 2005 12:15:17 +0100 Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: amavisd-new at dt.e-technik.uni-dortmund.de Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: XFS (read-only) support committed to CURRENT 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, 16 Dec 2005 11:15:23 -0000 Craig Rodrigues writes: > Read-only XFS support has been committed to FreeBSD-CURRENT. > Write access to XFS is not supported at this time. > The XFS for FreeBSD source code is based off of GPL'd sources > provided by SGI. Hm. Does this mean that FreeBSD's XFS implementation is GPL'd like ext2fs is? If so, allow me a question why XFS was chosen in preference to ext3fs? Ext3fs appears to have some advantages, easy migration from and to ext2fs, shrinkable, data journalling, data ordering (write data blocks before the file metadata is written) and so on. I don't mean this should become an advocacy discussion, as XFS surely has advantages, too, real-time capability and so on - but ext2fs is already there and has write support. Just curious. -- Matthias Andree From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 11:19:12 2005 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 2BDAA16A41F; Fri, 16 Dec 2005 11:19:12 +0000 (GMT) (envelope-from q@galgenberg.net) Received: from wrzx28.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id D54CB43D45; Fri, 16 Dec 2005 11:19:06 +0000 (GMT) (envelope-from q@galgenberg.net) Received: from wrzx30.rz.uni-wuerzburg.de (wrzx30.rz.uni-wuerzburg.de [132.187.1.30]) by wrzx28.rz.uni-wuerzburg.de (Postfix) with ESMTP id 0F56113FC1D; Fri, 16 Dec 2005 12:18:56 +0100 (CET) Received: from virusscan (localhost [127.0.0.1]) by wrzx30.rz.uni-wuerzburg.de (Postfix) with ESMTP id ED77D9DEFE; Fri, 16 Dec 2005 12:18:55 +0100 (CET) Received: from wrzx28.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by wrzx30.rz.uni-wuerzburg.de (Postfix) with ESMTP id D78B39B2A4; Fri, 16 Dec 2005 12:18:55 +0100 (CET) Received: from frodo.galgenberg.net (wwsx14.win-screen.uni-wuerzburg.de [132.187.253.14]) by wrzx28.rz.uni-wuerzburg.de (Postfix) with ESMTP id BAAAB13FC1D; Fri, 16 Dec 2005 12:18:55 +0100 (CET) Received: from coyote.q.local (gb-21-237.galgenberg.net [172.16.21.237]) by frodo.galgenberg.net (8.13.1/8.13.1) with ESMTP id jBGBItb2059059; Fri, 16 Dec 2005 12:18:55 +0100 (CET) (envelope-from q@galgenberg.net) Received: from roadrunner.q.local (roadrunner.q.local [192.168.0.148]) by coyote.q.local (8.13.4/8.13.4) with ESMTP id jBGBItGO000590; Fri, 16 Dec 2005 12:18:55 +0100 (CET) (envelope-from q@galgenberg.net) Received: from roadrunner.q.local (localhost [127.0.0.1]) by roadrunner.q.local (8.13.4/8.13.4) with ESMTP id jBGBIt1u062270; Fri, 16 Dec 2005 12:18:55 +0100 (CET) (envelope-from q@galgenberg.net) Received: (from q@localhost) by roadrunner.q.local (8.13.4/8.13.4/Submit) id jBGBIsAU062269; Fri, 16 Dec 2005 12:18:54 +0100 (CET) (envelope-from q@galgenberg.net) Date: Fri, 16 Dec 2005 12:18:54 +0100 From: Ulrich Spoerlein To: John Baldwin Message-ID: <20051216111854.GC1103@galgenberg.net> Mail-Followup-To: John Baldwin , current@freebsd.org References: <200512141720.01572.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LTeJQqWS0MN7I/qa" Content-Disposition: inline In-Reply-To: <200512141720.01572.jhb@freebsd.org> X-Virus-Scanned: by amavisd-new (Rechenzentrum Universitaet Wuerzburg) Cc: current@freebsd.org Subject: Re: hostb(4) and vgapci(4) 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: Fri, 16 Dec 2005 11:19:12 -0000 --LTeJQqWS0MN7I/qa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable John Baldwin wrote: > I have a patch that is an attempt to untangle a few things in relation to= =20 > Host-PCI bridges and VGA PCI devices. Basically, the change is to create= a=20 > more "real" hostb driver as well as a new vgapci driver and to change agp= ,=20 > drm, and acpi_video to attach to these drivers. This means among other= =20 > things: >=20 > - You can now use acpi_video with drm as both attach as children of vgapc= i0. >=20 > http://www.FreeBSD.org/~jhb/patches/agp_cvs.patch Hi, I'm eager to try this patch on RELENG_6 with a Radeon Mobility card, however the patch wont compile on RELENG_6. Could you please provide a diff against RELENG_6? That would be great, thanks! /usr/src/sys/dev/pci/pci.c: In function `pci_find_extcap_method': /usr/src/sys/dev/pci/pci.c:509: error: `PCIR_CAP_PTR_2' undeclared (first u= se in this function) /usr/src/sys/dev/pci/pci.c:509: error: (Each undeclared identifier is repor= ted only once /usr/src/sys/dev/pci/pci.c:509: error: for each function it appears in.) Ulrich Spoerlein --=20 PGP Key ID: F0DB9F44 Encrypted mail welcome! Fingerprint: F1CE D062 0CA9 ADE3 349B 2FE8 980A C6B5 F0DB 9F44 Ok, which part of "Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn." didn't you understand? --LTeJQqWS0MN7I/qa Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDoqKemArGtfDbn0QRAveUAKCEhrpibQs8oWo6xwptCO/b6TnwvwCfdwOl aBVfCBIN90jy4ip5OG3t0q8= =7vj0 -----END PGP SIGNATURE----- --LTeJQqWS0MN7I/qa-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 11:19:36 2005 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 59BF516A427 for ; Fri, 16 Dec 2005 11:19:36 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 17BD643D66 for ; Fri, 16 Dec 2005 11:19:31 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id jBGBJPX3066019; Fri, 16 Dec 2005 13:19:25 +0200 (EET) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 73929-02-4; Fri, 16 Dec 2005 13:19:21 +0200 (EET) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id jBGBI6Ih065907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Dec 2005 13:18:06 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.4/8.13.4) id jBGBIEX6024459; Fri, 16 Dec 2005 13:18:14 +0200 (EET) (envelope-from ru) Date: Fri, 16 Dec 2005 13:18:13 +0200 From: Ruslan Ermilov To: Artemiev Igor Message-ID: <20051216111813.GE41326@ip.net.ua> References: <200512141749.jBEHnjRV081112@repoman.freebsd.org> <20051214183345.GE51686@ip.net.ua> <20051215093643.694e995b.ai@bmc.brk.ru> <200512151306.57961.jhb@freebsd.org> <20051216083657.GA41326@ip.net.ua> <20051216134225.09aa93a3.ai@bmc.brk.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="L2Brqb15TUChFOBK" Content-Disposition: inline In-Reply-To: <20051216134225.09aa93a3.ai@bmc.brk.ru> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua Cc: freebsd-current@FreeBSD.org Subject: Re: cvs commit: src/sys/pci amdpm.c 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, 16 Dec 2005 11:19:36 -0000 --L2Brqb15TUChFOBK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 16, 2005 at 01:42:25PM +0300, Artemiev Igor wrote: > > OK, I looked some more, and I doubt the usefullness of the > > nForce-2/3/4 support in its current shape. Perhaps I'm mistaken and > > you can shed a light on this. :-) > > The amdpm(4) driver originally supported AMD-756's PMC SMBus 1.0. > > Later, AMD-8111 support was added. All of these AMDs seem to support > > both SMBus 2.0 and SMBus 1.0 interfaces, and the driver uses the SMBus > > 1.0 interface (offset 0xe0). The nForce seems to also support SMBus > > 1.0 interface (offset 0). At least, the following lm_sensors pages > > amd AMD-8111 datasheet confirm this: > >=20 > > http://www.lm-sensors.org/supported.html > > http://www2.lm-sensors.nu/~lm78/cvs/lm_sensors2/doc/busses/i2c-amd756 > > http://www2.lm-sensors.nu/~lm78/cvs/lm_sensors2/doc/busses/i2c-amd8111 > >=20 > > Now, the same supported.html page and googling says that nForce2/3/4 > > MCPs all use SMBus 2.0 interface similar to AMD-8111 SMBus 2amd86.0 > > interface. But we don't support SMBus 2.0 interface in amdpm(4)! > > (lm_sensors, OTOH, does implement SMBus 2.0.). > i2c-amd756.c, i2c-amd8111.c and i2c-nforce2.c looks very similar for me. > Differences between i2c-amd756 and i2c-nforce2.c/i2c-amd8111.c in > pair ioctl. >=20 i2c-amd8111.c and i2c-nforce2.c are indeed very similar, because they both use SMBus 2.0 API. :-) But i2c-amd756.c, which also handles AMD-8111 SMBus 1.0, and is similar to FreeBSD's amdpm.c, uses a different API (SMBus 1.0). Are you sure the following fragments look similar to you? http://www2.lm-sensors.nu/~lm78/cvs/browse.cgi/lm_sensors2/kernel/busses/i2= c-amd756.c http://www2.lm-sensors.nu/~lm78/cvs/browse.cgi/lm_sensors2/kernel/busses/i2= c-nforce2.c Let's consider I2C_SMBUS_QUICK+I2C_SMBUS_WRITE case, which is in FreeBSD's smb(4) spelling is: SMB_QUICK_WRITE The QuickWrite command just issues the device addre= ss with write intent to the bus, without transferring = any data. I've added offsets in `//' style comments... 203 static s32 amd756_access(struct i2c_adapter * adap, u16 addr, 204 unsigned short flags, char read_write, 205 u8 command, int size, union i2c_smbus_data * data) 206 { 207 int i, len; 208=09 209 /** TODO: Should I supporte the 10-bit transfers? */ 210 switch (size) { 211 /* TODO: proc call is supported, I'm just not sure what to do here.= =2E. */ 212 case I2C_SMBUS_QUICK: 213 outw_p(((addr & 0x7f) << 1) | (read_write & 0x01), 214 SMB_HOST_ADDRESS); // (0x4 + amd756_ioport) 215 size =3D AMD756_QUICK; 216 break; [...] 264 /* How about enabling interrupts... */ 265 outw_p(size & GE_CYC_TYPE_MASK, SMB_GLOBAL_ENABLE); // (0x2 + amd75= 6_ioport) word 266=09 267 if (amd756_transaction()) /* Error in transaction */ 268 return -1; 269=09 270 if ((read_write =3D=3D I2C_SMBUS_WRITE) || (size =3D=3D AMD756_QUIC= K)) 271 return 0; 141 s32 nforce2_access(struct i2c_adapter * adap, u16 addr, unsigned sho= rt flags, 142 char read_write, u8 command, int size, 143 union i2c_smbus_data * data) 144 { 145 struct nforce2_smbus *smbus =3D adap->algo_data; 146 unsigned char protocol, pec, temp; 147 unsigned char len =3D 0; /* to keep the compiler quiet */ 148 int i; 149=09 150 protocol =3D (read_write =3D=3D I2C_SMBUS_READ) ? NVIDIA_SMB_PRTCL_= READ : NVIDIA_SMB_PRTCL_WRITE; 151 pec =3D (flags & I2C_CLIENT_PEC) ? NVIDIA_SMB_PRTCL_PEC : 0; 152=09 153 switch (size) { 154=09 155 case I2C_SMBUS_QUICK: 156 protocol |=3D NVIDIA_SMB_PRTCL_QUICK; 157 read_write =3D I2C_SMBUS_WRITE; 158 break; [...] 214 } 215=09 216 outb_p((addr & 0x7f) << 1, NVIDIA_SMB_ADDR); // smbus->base + 0x02= (byte) 217 outb_p(protocol, NVIDIA_SMB_PRTCL); // smbus->base + 0x00 (byte) 218=09 219 temp =3D inb_p(NVIDIA_SMB_STS); // smbus->base + 0x01 (byte) 220=09 221 if (~temp & NVIDIA_SMB_STS_DONE) { 222 udelay(500); 223 temp =3D inb_p(NVIDIA_SMB_STS); 224 } 225 if (~temp & NVIDIA_SMB_STS_DONE) { 226 i2c_delay(HZ/100); 227 temp =3D inb_p(NVIDIA_SMB_STS); 228 } 229=09 230 if ((~temp & NVIDIA_SMB_STS_DONE) || (temp & NVIDIA_SMB_STS_STATUS)= ) { 231 printk(KERN_DEBUG "i2c-nforce2.o: SMBus Timeout! (0x%02x)\n", 232 temp); 233 return -1; 234 } 235=09 236 if (read_write =3D=3D I2C_SMBUS_WRITE) 237 return 0; See how the offset 0x2 register means completely different things. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --L2Brqb15TUChFOBK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDoqJ1qRfpzJluFF4RAgDYAKCGdajD3GfCD9OzsYTkb9Nph7YMnACfYG47 Xfr+95AmFva/CjM6YOdM9p0= =nrSp -----END PGP SIGNATURE----- --L2Brqb15TUChFOBK-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 08:27:08 2005 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 2F82616A41F; Fri, 16 Dec 2005 08:27:08 +0000 (GMT) (envelope-from kline@tao.thought.org) Received: from tao.thought.org (dsl231-043-140.sea1.dsl.speakeasy.net [216.231.43.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0AE3843D55; Fri, 16 Dec 2005 08:27:06 +0000 (GMT) (envelope-from kline@tao.thought.org) Received: from tao.thought.org (localhost [127.0.0.1]) by tao.thought.org (8.13.1/8.13.1) with ESMTP id jBG8R57Y055040; Fri, 16 Dec 2005 00:27:05 -0800 (PST) (envelope-from kline@tao.thought.org) Received: (from kline@localhost) by tao.thought.org (8.13.1/8.13.1/Submit) id jBG8R4CP055039; Fri, 16 Dec 2005 00:27:04 -0800 (PST) (envelope-from kline) Date: Fri, 16 Dec 2005 00:27:04 -0800 From: Gary Kline To: Scott Long Message-ID: <20051216082704.GA52634@thought.org> References: <43A266E5.3080103@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43A266E5.3080103@samsco.org> User-Agent: Mutt/1.4.2.1i X-Organization: Thought Unlimited. Public service Unix since 1986. X-Of_Interest: Observing 19 years of service to the Unix community X-Mailman-Approved-At: Fri, 16 Dec 2005 12:24:24 +0000 Cc: stable@freebsd.org, current Subject: Re: HEADS UP: Release schedule for 2006 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, 16 Dec 2005 08:27:08 -0000 On Fri, Dec 16, 2005 at 12:04:05AM -0700, Scott Long wrote: > All, > > The following is the approximate schedule for FreeBSD releases in 2006: > > Jan 30: Freeze RELENG_5 and RELENG_6 > Mar 20: Release FreeBSD 6.1 > Apr 3: Release FreeBSD 5.5 > Jun 12: Freeze RELENG_6 > Jul 31: Release FreeBSD 6.2 > Oct 23: Freeze RELENG_6 > Dec 11: Release FreeBSD 6.3 > > A 'freeze' means that the tree will be closed to changes except with > specific approval, and the focus will be on producing, testing, and > fixing release candidates. The release dates are targets that we hope > to make, but we will continue with the policy of only releasing once > all of the showstoppers are cleared, i.e. we will release when it is > ready. > > FreeBSD 5 > 5.5 will be the final release from the RELENG_5 tree. We are doing it > to provide support for users who have committed to FreeBSD 5 and who > need more time to transition to FreeBSD 6. However, in order to keep > forward progress with FreeBSD 6, we will produce this in parallel with > the 6.1 release, and thus it will not be our main focus. Users who are > using FreeBSD 5 are strongly encouraged to evaluate FreeBSD 6. After > this final release, the security team will provide security update > support through 2007. Sounds like an ambitious schedule... All my FBSD servers are at least up to 5.3; my laptop is happy at 5.4. I have what I believe to be a rationalquestion. Why should I go beyond v5.5? More to the point, why can't minor security tweaks be maintained indefinitely for 5.5? What will releases -6 and -7 offer that can;t reasonably be dropped into -5? gary -- Gary Kline kline@thought.org www.thought.org Public service Unix From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 09:13:55 2005 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 8F4EC16A41F; Fri, 16 Dec 2005 09:13:55 +0000 (GMT) (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 5BE3A43D62; Fri, 16 Dec 2005 09:13:53 +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.4/8.13.4) with ESMTP id jBG9Dl7U012137; Fri, 16 Dec 2005 10:13:47 +0100 Received: from localhost (ggajic@localhost) by afrodita.rcub.bg.ac.yu (8.13.4/8.13.4/Submit) with ESMTP id jBG9DiUr012104; Fri, 16 Dec 2005 10:13:47 +0100 Date: Fri, 16 Dec 2005 10:13:44 +0100 (CET) From: Goran Gajic To: John Baldwin In-Reply-To: <200512151356.41550.jhb@freebsd.org> Message-ID: References: <200512151356.41550.jhb@freebsd.org> 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: Fri, 16 Dec 2005 12:34:25 +0000 Cc: freebsd-current@freebsd.org Subject: Re: skype-1.2.0.18-static for linux and FreeBSD 7.0 CURRENT 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, 16 Dec 2005 09:13:55 -0000 On Thu, 15 Dec 2005, John Baldwin wrote: > > If you are in X this is probably a panic (currently the kernel doesn't create > a coredump while you are in X which is a bug). Can you hook up a serial > console and use that to get the panic message? > > Yes, here is capture from minicom: drm0: port 0xc000-0xc0ff mem 0xe8000000-0xefffffff,0xff8f0000-0xff8fffff irq 16 at device 0.0 on pci1 info: [drm] AGP at 0xf8000000 64MB info: [drm] Initialized radeon 1.19.0 20050911 info: [drm] Loading R200 Microcode lock order reversal: 1st 0xc366e21c vnode interlock (vnode interlock) @ kern/vfs_vnops.c:791 2nd 0xc3b8fb44 process lock (process lock) @ i386/i386/trap.c:742 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c0975450,c0975900,c0927544) at kdb_backtrace+0x29 witness_checkorder(c3b8fb44,9,c08be5a5,2e6) at witness_checkorder+0x580 _mtx_lock_flags(c3b8fb44,0,c08be59c,2e6,c3b91780) at _mtx_lock_flags+0x5b trap_pfault(dbc9da28,0,3) at trap_pfault+0xb2 trap(dbc90008,c0680028,c09b0028,c3b91780,dbc9da84) at trap+0x3cd calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc081799c, esp = 0xdbc9da68, ebp = 0xdbc9da70 --- stack_save(dbc9da84) at stack_save+0x1c lockmgr(c366e1ac,3002,c366e21c,c3b91780,dbc9db0c) at lockmgr+0x51 vop_stdlock(dbc9db50,c093b180,dbc9db50,dbc9db1c,c07a9204) at vop_stdlock+0x21 VOP_LOCK_APV(c093b6c0,dbc9db50,dbc9db30,c083c513,dbc9db50) at VOP_LOCK_APV+0x87 ffs_lock(dbc9db50,1002,c366e154,dbc9db6c,c06cdd5c) at ffs_lock+0x10 VOP_LOCK_APV(c093b180,dbc9db50) at VOP_LOCK_APV+0x87 vn_lock(c366e154,1002,c3b91780,0,0) at vn_lock+0xac vn_read(c3aba6c0,dbc9dc60,c3c7dd80,0,c3b91780) at vn_read+0xd7 dofileread(c3b91780,a,c3aba6c0,dbc9dc60,ffffffff) at dofileread+0x85 kern_readv(c3b91780,a,dbc9dc60,befff8ac,8) at kern_readv+0x36 read(c3b91780,dbc9dd04,c,c3b91780,dbc9dd30) at read+0x45 syscall(8f3003b,8f3003b,bfbf003b,befff92c,906256c) at syscall+0x27e Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (3, Linux ELF, read), eip = 0x28feec3b, esp = 0xbefff860, ebp = 0xffffffff --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x3 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0816f04 stack pointer = 0x28:0xdbc9d804 frame pointer = 0x28:0xdbc9d83c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 570 (skype) [thread pid 570 tid 100082 ] Stopped at db_read_bytes+0x30: movb 0(%edx),%al db> ps pid proc uid ppid pgrp flag stat wmesg wchan cmd 570 c3b8fadc 1001 545 544 0000002 [CPU 0] skype 569 c3b93458 1001 545 544 0000002 [SLPQ nanslp 0xc0967d84][SLP] skype 568 c3b93684 1001 545 544 0000002 [SLPQ pause 0xc3b936b8][SLP] skype 545 c3b938b0 1001 544 544 0000002 [SLPQ select 0xc09b1ad0][SLP] skype 544 c3b93000 1001 540 544 0004003 [SLPQ nanslp 0xc0967d84][SLP] skype 540 c3b8f684 1001 539 540 0004002 [SLPQ pause 0xc3b8f6b8][SLP] tcsh 539 c3b8f8b0 1001 1 539 0004100 [SLPQ select 0xc09b1ad0][SLP] xterm-static 537 c3b8f22c 1001 536 537 0004002 [SLPQ select 0xc09b1ad0][SLP] mwm 536 c3b8f458 1001 532 536 0004002 [SLPQ pause 0xc3b8f48c][SLP] tcsh 532 c3b8fd08 1001 523 532 0004100 [SLPQ select 0xc09b1ad0][SLP] xterm-static 523 c33de8b0 0 520 520 0000000 [SLPQ wait 0xc33de8b0][SLP] kdm 522 c3abfd08 0 520 522 0004000 [SLPQ select 0xc09b1ad0][SLP] Xorg 520 c3abb000 0 1 520 0000001 [SLPQ select 0xc09b1ad0][SLP] kdm 518 c353a684 0 492 49 0004000 [LOCK lockbuilder mtxpool c3405a00] fsck_ufs 507 c3abb22c 0 495 507 0004002 [SLPQ ttyin 0xc3408410][SLP] csh 504 c3abb458 0 494 504 0004002 [SLPQ ttyin 0xc3408c10][SLP] csh 503 c3abb684 0 1 1 0004000 [SLPQ ttydcd 0xc3407000][SLP] getty 502 c3abb8b0 0 1 502 0004002 [SLPQ ttyin 0xc3406410][SLP] getty 501 c3abbadc 0 1 501 0004002 [SLPQ ttyin 0xc341d810][SLP] getty 500 c3abbd08 0 1 500 0004002 [SLPQ ttyin 0xc341c810][SLP] getty 499 c3abf000 0 1 499 0004002 [SLPQ ttyin 0xc341c010][SLP] getty 498 c3abf22c 0 1 498 0004002 [SLPQ ttyin 0xc33fbc10][SLP] getty 497 c3abf458 0 1 497 0004002 [SLPQ ttyin 0xc341d010][SLP] getty 496 c3abf684 0 1 496 0004002 [SLPQ ttyin 0xc3407810][SLP] getty 495 c3abf8b0 0 1 495 0004102 [SLPQ wait 0xc3abf8b0][SLP] login 494 c3abfadc 0 1 494 0004102 [SLPQ wait 0xc3abfadc][SLP] login 492 c358b458 0 489 49 0004002 [SLPQ wait 0xc358b458][SLP] fsck 490 c353a8b0 0 1 49 0004002 [SLPQ piperd 0xc356e7d0][SLP] logger 489 c358b8b0 0 1 49 0000002 [SLPQ wait 0xc358b8b0][SLP] sh 460 c353a22c 0 1 460 0000000 [SLPQ select 0xc09b1ad0][SLP] moused 431 c358b000 0 1 431 0000000 [SLPQ nanslp 0xc0967d84][SLP] cron 419 c353ad08 25 1 419 0000100 [SLPQ pause 0xc353ad3c][SLP] sendmail 415 c358bd08 0 1 415 0000100 [SLPQ select 0xc09b1ad0][SLP] sendmail 409 c353aadc 0 1 409 0000100 [SLPQ select 0xc09b1ad0][SLP] sshd 365 c33de684 0 0 0 0000204 [IWAIT] irq17: pcm0 352 c358b22c 0 1 352 0000000 [SLPQ select 0xc09b1ad0][SLP] usbd 275 c358badc 0 1 275 0000000 [LOCK buf queue lock c3405e80] syslogd 245 c358b684 0 1 245 0000000 [SLPQ select 0xc09b1ad0][SLP] devd 136 c353a458 0 1 136 0000000 [SLPQ pause 0xc353a48c][SLP] adjkerntz 48 c33deadc 0 0 0 0000204 [SLPQ - 0xd96ffd04][SLP] schedcpu 47 c33ded08 0 0 0 0000204 [SLPQ - 0xc09b992c][SLP] nfsiod 3 46 c3539000 0 0 0 0000204 [SLPQ - 0xc09b9928][SLP] nfsiod 2 45 c353922c 0 0 0 0000204 [SLPQ - 0xc09b9924][SLP] nfsiod 1 44 c3539458 0 0 0 0000204 [SLPQ - 0xc09b9920][SLP] nfsiod 0 43 c3539684 0 0 0 0000204 [SLPQ vlruwt 0xc3539684][SLP] vnlru 42 c35398b0 0 0 0 0000204 [SLPQ syncer 0xc0967aac][SLP] syncer 41 c3539adc 0 0 0 0000204 [SLPQ psleep 0xc09b1f4c][SLP] bufdaemon 40 c3539d08 0 0 0 000020c [SLPQ pgzero 0xc09bfc60][SLP] pagezero 39 c353a000 0 0 0 0000204 [SLPQ psleep 0xc09bf7c8][SLP] vmdaemon 38 c3389d08 0 0 0 0000204 [SLPQ psleep 0xc09bf788][SLP] pagedaemon 37 c33dd000 0 0 0 0000204 [IWAIT] swi0: sio 36 c33dd22c 0 0 0 0000204 [IWAIT] irq12: psm0 35 c33dd458 0 0 0 0000204 [IWAIT] irq1: atkbd0 34 c33dd684 0 0 0 0000204 [IWAIT] irq7: ppc0 33 c33dd8b0 0 0 0 0000204 [SLPQ - 0xc33f283c][SLP] fdc0 32 c33ddadc 0 0 0 0000204 [IWAIT] irq15: ata1 31 c33ddd08 0 0 0 0000204 [IWAIT] irq14: ata0 30 c33de000 0 0 0 0000204 [IWAIT] irq22: rl0 29 c33de22c 0 0 0 0000204 [SLPQ usbevt 0xc3375a10][SLP] usb4 28 c33de458 0 0 0 0000204 [IWAIT] irq23: ehci0 27 c3302684 0 0 0 0000204 [SLPQ usbevt 0xc33c3210][SLP] usb3 26 c33028b0 0 0 0 0000204 [SLPQ usbevt 0xc33b7210][SLP] usb2 25 c3302adc 0 0 0 0000204 [IWAIT] irq18: uhci2 24 c3302d08 0 0 0 0000204 [SLPQ usbevt 0xc33bd210][SLP] usb1 23 c3389000 0 0 0 0000204 [IWAIT] irq19: uhci1 22 c338922c 0 0 0 0000204 [SLPQ usbtsk 0xc0965004][SLP] usbtask 21 c3389458 0 0 0 0000204 [SLPQ usbevt 0xc3382210][SLP] usb0 20 c3389684 0 0 0 0000204 [IWAIT] irq16: uhci0 uhci+ 19 c33898b0 0 0 0 0000204 [IWAIT] irq9: acpi0 18 c3389adc 0 0 0 0000204 [IWAIT] swi6: task queue 9 c329c22c 0 0 0 0000204 [SLPQ - 0xc33584c0][SLP] acpi_task2 8 c329c458 0 0 0 0000204 [SLPQ - 0xc33584c0][SLP] acpi_task1 7 c329c684 0 0 0 0000204 [SLPQ - 0xc33584c0][SLP] acpi_task0 6 c329c8b0 0 0 0 0000204 [SLPQ - 0xc3358500][SLP] kqueue taskq 17 c329cadc 0 0 0 0000204 [IWAIT] swi2: cambio 16 c329cd08 0 0 0 0000204 [IWAIT] swi5: Fast taskq 5 c3302000 0 0 0 0000204 [SLPQ - 0xc3358700][SLP] thread taskq 15 c330222c 0 0 0 0000204 [IWAIT] swi6: Giant taskq 14 c3302458 0 0 0 0000204 [SLPQ - 0xc0962c20][SLP] yarrow 4 c3297000 0 0 0 0000204 [SLPQ - 0xc09657a0][SLP] g_down 3 c329722c 0 0 0 0000204 [SLPQ - 0xc096579c][SLP] g_up 2 c3297458 0 0 0 0000204 [SLPQ - 0xc0965794][SLP] g_event 13 c3297684 0 0 0 0000204 [IWAIT] swi1: net 12 c32978b0 0 0 0 0000204 [IWAIT] swi3: vm 11 c3297adc 0 0 0 000020c [IWAIT] swi4: clock sio 10 c3297d08 0 0 0 000020c [Can run] idle 1 c329c000 0 0 1 0004200 [SLPQ wait 0xc329c000][SLP] init 0 c09658a0 0 0 0 0000200 [IWAIT] swapper db> sh locks exclusive sleep mutex vnode interlock r = 0 (0xc366e21c) locked @ kern/vfs_vnops.c:791 db> Regards, gg. From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 12:34:33 2005 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 DB58116A422 for ; Fri, 16 Dec 2005 12:34:33 +0000 (GMT) (envelope-from lerik@nolink.net) Received: from electra.nolink.net (electra.nolink.net [195.139.204.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65A2143D5A for ; Fri, 16 Dec 2005 12:34:24 +0000 (GMT) (envelope-from lerik@nolink.net) Received: (qmail 50431 invoked by uid 1000); 16 Dec 2005 12:34:23 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 16 Dec 2005 12:34:23 -0000 Date: Fri, 16 Dec 2005 13:34:23 +0100 (CET) From: Lars Erik Gullerud To: Matthias Andree In-Reply-To: Message-ID: <20051216132641.C29205@electra.nolink.net> References: <20051213151908.GA26821@crodrigues.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org, Craig Rodrigues , freebsd-current@freebsd.org Subject: Re: XFS (read-only) support committed to CURRENT 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, 16 Dec 2005 12:34:34 -0000 On Fri, 16 Dec 2005, Matthias Andree wrote: > Craig Rodrigues writes: > >> Read-only XFS support has been committed to FreeBSD-CURRENT. >> Write access to XFS is not supported at this time. >> The XFS for FreeBSD source code is based off of GPL'd sources >> provided by SGI. > > Hm. Does this mean that FreeBSD's XFS implementation is GPL'd like > ext2fs is? If so, allow me a question why XFS was chosen in preference > to ext3fs? What do you mean by "chosen in preference to", the two are hardly mutually exclusive...? UFS2 is still FreeBSD's native filesystem, however FreeBSD also supports handling a range of other filesystems like ext2fs, NTFS, etc. - and now also XFS. If you happen to want/need ext3fs more than XFS then you can always add the required bits yourself and send patches, or pay someone to do it? Someone wanted XFS support, so someone went ahead and worked on it - not to the exclusion of any other filesystem that anyone else might want/need support for... > Ext3fs appears to have some advantages, easy migration from and to > ext2fs, shrinkable, data journalling, data ordering (write data blocks > before the file metadata is written) and so on. ...and this has what to do with the fact that FreeBSD now supports XFS? > I don't mean this should become an advocacy discussion, as XFS surely > has advantages, too, real-time capability and so on - but ext2fs is > already there and has write support. Then use ext2fs. Isn't the availability of multiple choices great? /leg From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 13:37:43 2005 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 9DEBA16A41F for ; Fri, 16 Dec 2005 13:37:43 +0000 (GMT) (envelope-from csaba@beastie.creo.hu) Received: from beastie.creo.hu (www.creo.hu [217.113.62.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id E5A8C43D58 for ; Fri, 16 Dec 2005 13:37:42 +0000 (GMT) (envelope-from csaba@beastie.creo.hu) Received: from beastie.creo.hu (localhost [127.0.0.1]) by beastie.creo.hu (8.13.3/8.13.3) with ESMTP id jBGDYmOE010977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 16 Dec 2005 14:34:48 +0100 (CET) (envelope-from csaba@beastie.creo.hu) Received: (from csaba@localhost) by beastie.creo.hu (8.13.3/8.13.3/Submit) id jBGDYmMV010976 for freebsd-current@freebsd.org; Fri, 16 Dec 2005 14:34:48 +0100 (CET) (envelope-from csaba) Date: Fri, 16 Dec 2005 14:34:48 +0100 From: Csaba Henk To: freebsd-current@freebsd.org Message-ID: <20051216133448.GA10382@beastie.creo.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Subject: Easy DoS 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, 16 Dec 2005 13:37:43 -0000 Do echo 'main() { write(1, 0, 1); }' > edos.c gcc -o edos edos.c ./edos | cat ... and now the edos process gets stuck in the write syscall, unkillably, keeping the CPU spinning. (Seen on my 6.0-RELEASE and 7.0-CURRENT boxen.) Is it a bug or a feature? Csaba From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 14:59:11 2005 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 DFC9316A41F for ; Fri, 16 Dec 2005 14:59:11 +0000 (GMT) (envelope-from joao.barros@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2EC043D5D for ; Fri, 16 Dec 2005 14:59:10 +0000 (GMT) (envelope-from joao.barros@gmail.com) Received: by xproxy.gmail.com with SMTP id t12so511928wxc for ; Fri, 16 Dec 2005 06:59:10 -0800 (PST) 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=JuZzbGlLzMBi6b94EsJmvGaC1kXyL4DS1HpQMeYLW+QT4zLS2ylZ3EzIpx4ljttDFEy2zVf9CjIBK3s3x/eM9XojI9iRkGgFOuhIFZKsjClmQCi8J8Tf3FOXHo1A2NdODlH64oQezvXmtfPQ+v6rjswHcZiS0QDInwzcbgiwLRM= Received: by 10.70.44.16 with SMTP id r16mr1010444wxr; Fri, 16 Dec 2005 06:59:09 -0800 (PST) Received: by 10.70.36.7 with HTTP; Fri, 16 Dec 2005 06:59:09 -0800 (PST) Message-ID: <70e8236f0512160659h3379253dw468e5aad3f741002@mail.gmail.com> Date: Fri, 16 Dec 2005 14:59:09 +0000 From: Joao Barros To: Scott Long In-Reply-To: <43A266E5.3080103@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <43A266E5.3080103@samsco.org> Cc: stable@freebsd.org, current Subject: Re: HEADS UP: Release schedule for 2006 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, 16 Dec 2005 14:59:12 -0000 On 12/16/05, Scott Long wrote: > FreeBSD 7 > We will start preparing for FreeBSD 7.0 in June 2007. > > I'll hopefully update the release engineering pages soon to reflect > this. If you have any questions, please feel free to contact me and the > rest of the release engineering team. Thanks!ott There have been some questions on the lists about what to expect from release x.y and I personnally have always looked at the TODO list like http://www.freebsd.org/releases/6.0R/todo.html For 6.0 I noticed there were more updates on that page for bugs and their fixes than for features per se. My sugestion, maybe at a first stage setting the TODO list has it's advantages, one knows what to expect from a release, it's clearly stated and documented there and the developers can see their goals. This is valid for minor and major releases of course. How about it? -- Joao Barros From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 15:10:46 2005 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 7296616A41F for ; Fri, 16 Dec 2005 15:10:46 +0000 (GMT) (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 CEFE743D80 for ; Fri, 16 Dec 2005 15:10:37 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.38]) by fw.zoral.com.ua (8.13.3/8.13.1) with ESMTP id jBGFAI13007233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Dec 2005 17:10:18 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.13.4/8.13.4) with ESMTP id jBGFAHE2052881; Fri, 16 Dec 2005 17:10:17 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.4/8.13.4/Submit) id jBGFAG5C052880; Fri, 16 Dec 2005 17:10:16 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 16 Dec 2005 17:10:16 +0200 From: Kostik Belousov To: Csaba Henk Message-ID: <20051216151016.GE84442@deviant.zoral.local> References: <20051216133448.GA10382@beastie.creo.hu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WChQLJJJfbwij+9x" Content-Disposition: inline In-Reply-To: <20051216133448.GA10382@beastie.creo.hu> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 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.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on fw.zoral.com.ua Cc: freebsd-current@freebsd.org Subject: Re: Easy DoS 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, 16 Dec 2005 15:10:46 -0000 --WChQLJJJfbwij+9x Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 16, 2005 at 02:34:48PM +0100, Csaba Henk wrote: > Do >=20 > echo 'main() { write(1, 0, 1); }' > edos.c > gcc -o edos edos.c > ./edos | cat >=20 > ... and now the edos process gets stuck in the write syscall, unkillably, > keeping the CPU spinning. (Seen on my 6.0-RELEASE and 7.0-CURRENT boxen.) >=20 > Is it a bug or a feature? >=20 > Csaba Sure, it is a bug :). Please, try the following patch (against 7-CURRENT, shall work for 6-STABLE too): --- src-pristine/sys/kern/sys_pipe.c Mon Jul 11 11:33:58 2005 +++ src-quotas/sys/kern/sys_pipe.c Fri Dec 16 17:03:01 2005 @@ -1176,6 +1176,8 @@ ("Pipe buffer overflow")); } pipeunlock(wpipe); + if (error !=3D 0) + break; } else { /* * If the "read-side" has been blocked, wake it up = now. Best regards, Kostik Belousov --WChQLJJJfbwij+9x Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDotjWC3+MBN1Mb4gRAgmTAJ49URDjOy/WU9j4bZgx0iYUzSHz7gCdFDPB huwhGk09BPeSoLV8FhzOS5s= =6lBC -----END PGP SIGNATURE----- --WChQLJJJfbwij+9x-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 15:12:53 2005 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 3CD1C16A420; Fri, 16 Dec 2005 15:12:53 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from rwcrmhc12.comcast.net (rwcrmhc14.comcast.net [216.148.227.89]) by mx1.FreeBSD.org (Postfix) with ESMTP id 589A143D68; Fri, 16 Dec 2005 15:12:31 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from c-24-63-58-245.hsd1.ma.comcast.net ([24.63.58.245]) by comcast.net (rwcrmhc14) with ESMTP id <20051216151221014008mjnje>; Fri, 16 Dec 2005 15:12:22 +0000 Received: from c-24-63-58-245.hsd1.ma.comcast.net (localhost [127.0.0.1]) by c-24-63-58-245.hsd1.ma.comcast.net (8.13.4/8.13.1) with ESMTP id jBGFCTaB034694; Fri, 16 Dec 2005 10:12:29 -0500 (EST) (envelope-from rodrigc@c-24-63-58-245.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-24-63-58-245.hsd1.ma.comcast.net (8.13.4/8.13.1/Submit) id jBGFCT4r034693; Fri, 16 Dec 2005 10:12:29 -0500 (EST) (envelope-from rodrigc) Date: Fri, 16 Dec 2005 10:12:28 -0500 From: Craig Rodrigues To: Matthias Andree Message-ID: <20051216151228.GA34670@crodrigues.org> References: <20051213151908.GA26821@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: XFS (read-only) support committed to CURRENT 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, 16 Dec 2005 15:12:53 -0000 On Fri, Dec 16, 2005 at 12:15:17PM +0100, Matthias Andree wrote: > Hm. Does this mean that FreeBSD's XFS implementation is GPL'd like > ext2fs is? If so, allow me a question why XFS was chosen in preference > to ext3fs? Your comment makes no sense. What does being GPL have to do with choosing ext2fs vs. XFS? We ported XFS to FreeBSD because we felt like it, and it was fun. ext3fs is irrelevant. -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 16:27:20 2005 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 4E9FA16A420 for ; Fri, 16 Dec 2005 16:27:20 +0000 (GMT) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B39943D7B for ; Fri, 16 Dec 2005 16:27:14 +0000 (GMT) (envelope-from freebsd-listen@fabiankeil.de) Received: (qmail 6411 invoked from network); 16 Dec 2005 16:27:13 -0000 Received: from unknown (HELO TP51.local) ([pbs]775067@[217.187.182.222]) (envelope-sender ) by smtprelay01.ispgateway.de (qmail-ldap-1.03) with SMTP for ; 16 Dec 2005 16:27:13 -0000 Date: Fri, 16 Dec 2005 17:26:43 +0100 From: Fabian Keil To: Kostik Belousov Message-ID: <20051216172643.7cb10a57@TP51.local> In-Reply-To: <20051216151016.GE84442@deviant.zoral.local> References: <20051216133448.GA10382@beastie.creo.hu> <20051216151016.GE84442@deviant.zoral.local> X-Mailer: Sylpheed-Claws 1.9.100 (GTK+ 2.8.6; i386-portbld-freebsd5.4) 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_BbIMm2NoBmmZdmNvSZPO0E1; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: Csaba Henk , freebsd-current@freebsd.org Subject: Re: Easy DoS 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, 16 Dec 2005 16:27:20 -0000 --Sig_BbIMm2NoBmmZdmNvSZPO0E1 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Kostik Belousov wrote: > On Fri, Dec 16, 2005 at 02:34:48PM +0100, Csaba Henk wrote: > > Do > >=20 > > echo 'main() { write(1, 0, 1); }' > edos.c > > gcc -o edos edos.c > > ./edos | cat > >=20 > > ... and now the edos process gets stuck in the write syscall, > > unkillably, keeping the CPU spinning. (Seen on my 6.0-RELEASE and > > 7.0-CURRENT boxen.) > >=20 > > Is it a bug or a feature? > >=20 > > Csaba >=20 > Sure, it is a bug :). >=20 > Please, try the following patch (against 7-CURRENT, > shall work for 6-STABLE too): >=20 > --- src-pristine/sys/kern/sys_pipe.c Mon Jul 11 11:33:58 2005 > +++ src-quotas/sys/kern/sys_pipe.c Fri Dec 16 17:03:01 2005 > @@ -1176,6 +1176,8 @@ > ("Pipe buffer overflow")); > } > pipeunlock(wpipe); > + if (error !=3D 0) > + break; > } else { > /* > * If the "read-side" has been blocked, wake > it up now. The patch fixed the bug for 5.4-STABLE. Fabian --=20 http://www.fabiankeil.de/ --Sig_BbIMm2NoBmmZdmNvSZPO0E1 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDourWjV8GA4rMKUQRApHZAKCNxxtSA717ucXIcJCUeN5z93bv2gCgkx6R /bh1jzj7m/yUHPa5FJKFTc4= =mL65 -----END PGP SIGNATURE----- --Sig_BbIMm2NoBmmZdmNvSZPO0E1-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 16:34:29 2005 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 9ACBB16A41F for ; Fri, 16 Dec 2005 16:34:29 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 412EB43D5E for ; Fri, 16 Dec 2005 16:34:29 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.4/8.13.4) with ESMTP id jBGGYQEC002838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Dec 2005 11:34:26 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id jBGGYGNM035801; Fri, 16 Dec 2005 11:34:16 -0500 (EST) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17314.60552.595375.783753@grasshopper.cs.duke.edu> Date: Fri, 16 Dec 2005 11:34:16 -0500 (EST) To: freebsd-current@freebsd.org X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Subject: PREEMPTION vs ndisulator 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, 16 Dec 2005 16:34:29 -0000 I'm trying to use an ndis driver on an amd64 machine running FreeBSD/amd64 -current from yesterday. If I enable PREEMPTION, the machine hangs when loading the driver (kldload never returns): ndis0: mem 0xfc000000-0xfcffffff,0xfdf00000-0xfdffffff irq 18 at device 0.0 on pci5 ndis0: NDIS API version: 5.1 Witness detects no problems, and if I disable PREEMPTION, the driver seems to work fine. Is PREEMPTION not safe to be used with the ndisulator, or is there a problem with the ndis driver itself? I've included some very brief debugging info below.. Thanks, Drew KDB: enter: Line break on console [thread pid 11 tid 100002 ] Stopped at kdb_enter+0x2f: nop db> tr Tracing pid 11 tid 100002 td 0xffffff001ed499c0 kdb_enter() at kdb_enter+0x2f siointr1() at siointr1+0x400 siointr() at siointr+0x3d intr_execute_handlers() at intr_execute_handlers+0x124 lapic_handle_intr() at lapic_handle_intr+0x21 Xapic_isr1() at Xapic_isr1+0x7c --- interrupt, rip = 0xffffffff803d6972, rsp = 0xffffffff94e78bf0, rbp = 0xffffffff94e78c10 --- spinlock_exit() at spinlock_exit+0x32 ithread_loop() at ithread_loop+0x355 fork_exit() at fork_exit+0x86 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffff94e78d40, rbp = 0 --- db> ps pid proc uid ppid pgrp flag stat wmesg wchan cmd 637 ffffff00148f3700 0 0 0 0000204 [SLPQ KeWFS 0xffffffff966ffb80][SLP] Windows Workitem 3 636 ffffff00148f3380 0 0 0 0000204 [SLPQ KeWFS 0xffffffff966f6b80][SLP] Windows Workitem 2 635 ffffff0014c72a80 0 0 0 0000204 [SLPQ KeWFS 0xffffffff966edb80][SLP] Windows Workitem 1 634 ffffff00148f3a80 0 0 0 0000204 [SLPQ KeWFS 0xffffffff966e4b80][SLP] Windows Workitem 0 633 ffffff0014c72700 0 0 0 0000204 [RUNQ] Windows DPC 0 632 ffffff0014ccd380 0 519 632 0004002 [RUNQ] kldload 519 ffffff00152a2380 1387 518 519 0004002 [SLPQ pause 0xffffff00152a23e8][SLP] tcsh 518 ffffff0014f5f700 1387 516 516 0000100 [SLPQ select 0xffffffff805e5a20][SLP] sshd 516 ffffff00152a2000 0 460 516 0004100 [SLPQ sbwait 0xffffff0017b0b128][SLP] sshd 515 ffffff001ec53000 0 1 515 0004002 [SLPQ ttyin 0xffffff001ec94c10][SLP] getty 514 ffffff0015363a80 0 1 514 0004002 [SLPQ ttyin 0xffffff00009c6810][SLP] getty 513 ffffff00186f9000 0 1 513 0004002 [SLPQ ttyin 0xffffff00009c6c10][SLP] getty 512 ffffff0018778380 0 1 512 0004002 [SLPQ ttyin 0xffffff0000a8b010][SLP] getty 511 ffffff0015363380 0 1 511 0004002 [SLPQ ttyin 0xffffff0000a8b410][SLP] getty 510 ffffff0015363700 0 1 510 0004002 [SLPQ ttyin 0xffffff0000a8b810][SLP] getty 509 ffffff0015363000 0 1 509 0004002 [SLPQ ttyin 0xffffff0000a8bc10][SLP] getty 508 ffffff00152a2a80 0 1 508 0004002 [SLPQ ttyin 0xffffff0000a8c010][SLP] getty 507 ffffff00152a2700 0 1 507 0004002 [SLPQ ttyin 0xffffff0000a8c410][SLP] getty 482 ffffff001eb18380 0 1 482 0000000 [SLPQ nanslp 0xffffffff805de528][SLP] cron --More-- db> tr 633 Tracing pid 633 tid 100074 td 0xffffff0013e8f270 sched_switch() at sched_switch+0x11f mi_switch() at mi_switch+0x153 sleepq_wait() at sleepq_wait+0x9 cv_wait_unlock() at cv_wait_unlock+0x131 cv_wait() at cv_wait+0x2c KeWaitForSingleObject() at KeWaitForSingleObject+0x2a1 ntoskrnl_dpc_thread() at ntoskrnl_dpc_thread+0xcc fork_exit() at fork_exit+0x86 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffff966dbd40, rbp = 0 --- db> tr 632 Tracing pid 632 tid 100069 td 0xffffff001eb1a750 sched_switch() at sched_switch+0x11f mi_switch() at mi_switch+0x153 critical_exit() at critical_exit+0x9a spinlock_exit() at spinlock_exit+0x17 turnstile_unpend() at turnstile_unpend+0x2b2 KfLowerIrql() at KfLowerIrql+0x4a dmapbase() at 0xffffff001370b34e myri10ge_sys_drv_data_start() at myri10ge_sys_drv_data_start+0x46a9 ndis_attach() at ndis_attach+0x1b0 ndis_attach_pci() at ndis_attach_pci+0x4d2 device_attach() at device_attach+0x292 pci_driver_added() at pci_driver_added+0xe0 devclass_add_driver() at devclass_add_driver+0xc8 driver_module_handler() at driver_module_handler+0xad module_register_init() at module_register_init+0x58 linker_load_module() at linker_load_module+0x950 kldload() at kldload+0x109 syscall() at syscall+0x6b2 Xfast_syscall() at Xfast_syscall+0xa8 --- syscall (304, FreeBSD ELF64, kldload), rip = 0x80067901c, rsp = 0x7fffffffe6e8, rbp = 0x7fffffffe760 --- From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 17:36:07 2005 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 EBA8016A42B for ; Fri, 16 Dec 2005 17:36:06 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from mail.united-ware.com (am-productions.biz [69.61.164.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92A0343D5A for ; Fri, 16 Dec 2005 17:35:19 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.100] (am-productions.biz [69.61.164.22]) (authenticated bits=0) by mail.united-ware.com (8.13.4/8.13.4) with ESMTP id jBGHcDAU025604 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 16 Dec 2005 12:38:19 -0500 (EST) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: freebsd-current@freebsd.org Date: Fri, 16 Dec 2005 12:37:07 -0500 User-Agent: KMail/1.8.3 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1365204.SIc5Ei55ez"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200512161237.15148.mistry.7@osu.edu> X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED, BAYES_05, BIZ_TLD, MYFREEBSD2 autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on mail.united-ware.com X-Virus-Scanned: ClamAV 0.87/1210/Thu Dec 15 10:23:22 2005 on mail.united-ware.com X-Virus-Status: Clean Subject: Reproducable Panic on CURRENT and 6.0-RELEASE 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, 16 Dec 2005 17:36:07 -0000 --nextPart1365204.SIc5Ei55ez Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Here is the offending program/code. The interesting program is=20 avidemux_2.1_branch_anish/avidemux/avidemux2. (It is compiled for CURRENT, and I left all the object code stuff in=20 so it's a bit large 21MB) http://am-productions.biz/docs/avidemux_2.1_branch_anish.tgz =46irst you'll need to compile spidermonkey to be threadsafe so add the=20 following to your lang/spidermonkey/Makefile before installing it: LIB_DEPENDS=3D nspr4.1:${PORTSDIR}/devel/nspr MAKE_ARGS+=3D JS_THREADSAFE=3DYES LDFLAGS=3D"-L${LOCALBASE}/lib=20 =2Dlpthread -lm" CFLAGS+=3D -I${LOCALBASE}/include/nspr Once a threadsafe spidermonkey is installed to kill the machine you'll=20 need to: cd avidemux_2.1_branch_anish/avidemux =2E/avidemux2 --run new-features-test.js On CURRENT: kernel trap 12 with interrupts disabled =46atal trap 12: page fault while in kernel mode fault virtual address =3D 0x68 fault code =3D supervisor read, page not present instruction pointer =3D 0x20:0xc04e6f36 stack pointer =3D 0x28:0xcc9edb3c frame pointer =3D 0x28:0xcc9edbb0 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D resume, IOPL =3D 0 current process =3D 798 (gdb) trap number =3D 12 panic: page fault #0 doadump () at pcpu.h:165 #1 0xc04bb7eb in boot (howto=3D260)=20 at /usr/src/sys/kern/kern_shutdown.c:399 #2 0xc04bb353 in panic (fmt=3D0xc06069a7 "%s") at /usr/src/sys/kern/kern_shutdown.c:555 #3 0xc05e91ba in trap_fatal (frame=3D0xcc9edafc, eva=3D104) at /usr/src/sys/i386/i386/trap.c:862 #4 0xc05e96d9 in trap (frame=3D {tf_fs =3D 8, tf_es =3D 40, tf_ds =3D 40, tf_edi =3D -1032878460, tf_= esi=20 =3D 1, tf_ebp =3D -862004304, tf_isp =3D -862004440, tf_ebx =3D -1033297504= ,=20 tf_edx =3D -1033987232, tf_ecx =3D 4, tf_eax =3D 0, tf_trapno =3D 12, tf_er= r=20 =3D 0, tf_eip =3D -1068601546, tf_cs =3D 32, tf_eflags =3D 65687, tf_esp = =3D=20 =2D1032878356, tf_ss =3D -1067380424}) at /usr/src/sys/i386/i386/trap.c:273 #5 0xc05db6fa in calltrap ()=20 at /usr/src/sys/i386/i386/exception.s:137 #6 0xc04e6f36 in kern_ptrace (td=3D0xc25e9b60, req=3D10, pid=3D1, addr=3D0= x0,=20 data=3D17) at /usr/src/sys/kern/sys_process.c:802 #7 0xc04e71f0 in ptrace (td=3D0xc25e9b60, uap=3D0xcc9edd04) at /usr/src/sys/kern/sys_process.c:433 #8 0xc05e9ca6 in syscall (frame=3D {tf_fs =3D 59, tf_es =3D 59, tf_ds =3D 59, tf_edi =3D 136221752, tf_e= si=20 =3D 796, tf_ebp =3D -1077943184, tf_isp =3D -862003868, tf_ebx =3D 796,=20 tf_edx =3D 674587084, tf_ecx =3D 674505768, tf_eax =3D 26, tf_trapno =3D 12= ,=20 tf_err =3D 2, tf_eip =3D 673978987, tf_cs =3D 51, tf_eflags =3D 518, tf_esp= =3D=20 =2D1077943208, tf_ss =3D 59}) at /usr/src/sys/i386/i386/trap.c:1008 =2D--Type to continue, or q to quit--- #9 0xc05db74f in Xint0x80_syscall ()=20 at /usr/src/sys/i386/i386/exception.s:190 #10 0x00000033 in ?? () http://am-productions.biz/docs/littleguy-dmesg.gz http://am-productions.biz/docs/littleguy-pciconf.gz =46rom my previous email to questions with the info on 6.0-RELEASE: I'm getting the following panic, which I can reproduce easily. Let me=20 know what other information I should provide. The backtrace seems=20 really short for some reason. I get the panic when running a=20 multi-threaded application I'm developing/modifying. kernel trap 12 with interrupts disabled =46atal trap 12: page fault while in kernel mode fault virtual address =3D 0x48 fault code =3D supervisor write, page not present instruction pointer =3D 0x20:0xc0510cb3 stack pointer =3D 0x28:0xe9aebb74 frame pointer =3D 0x28:0xe9aebbf8 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D resume, IOPL =3D 0 current process =3D 7848 (gdb) [thread pid 7848 tid 100184 ] Stopped at kern_ptrace+0x11e3: andl $0xfffbffff,0x48(%eax) db> bt Tracing pid 7848 tid 100184 td 0xc4302180 kern_ptrace(c4302180,a,1ea6,0,11) at kern_ptrace+0x11e3 ptrace(c4302180,e9aebd04,10,418,4) at ptrace+0x56 syscall(3b,3b,3b,bfbfe580,1ea6) at syscall+0x13d Xint0x80_syscall() at Xint0x80_syscall+0x1f =2D-- syscall (26, FreeBSD ELF32, ptrace), eip =3D 0x283360e7, esp =3D=20 0xbfbfe3bc, ebp =3D 0xbfbfe3d8 --- =46ull panic and backtrace, and alltrace: http://am-productions.biz/docs/bigguy-panic.gz http://am-productions.biz/docs/bigguy-dmesg.gz http://am-productions.biz/docs/bigguy-pciconf.gz Kernel config: http://am-productions.biz/docs/BIGGUY.gz I have firewire console access to the CURRENT system, and serial=20 console access for the 6.0-RELEASE. Thanks, =2D-=20 Anish Mistry --nextPart1365204.SIc5Ei55ez Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDovtLxqA5ziudZT0RAsU1AJ9viVGpoPeNFS2PViXY4ca75un5bACfSXOe ZUozyc3R6qZ+glVDHiIjKRM= =aCS+ -----END PGP SIGNATURE----- --nextPart1365204.SIc5Ei55ez-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 18:34:04 2005 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 23F4B16A41F for ; Fri, 16 Dec 2005 18:34:04 +0000 (GMT) (envelope-from delphij@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E1B243D6E for ; Fri, 16 Dec 2005 18:33:56 +0000 (GMT) (envelope-from delphij@gmail.com) Received: by wproxy.gmail.com with SMTP id i31so685784wra for ; Fri, 16 Dec 2005 10:33:56 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=O91uPzWCMgHmDmqkGWR5psdemNU49PPVyAeEl5dunak7TMgSxStONkpH5oQpYqpyDS7W2zSu/TYEcHoQontpnz/WsvwSZ6a3s0yJGw3saB2GgbgLHe2d3Zx16PECn6bjDBkqxTUzXKbA5rY8XqgrYbr/YDqOdsEjNM+a+mNKMFo= Received: by 10.64.253.1 with SMTP id a1mr100440qbi; Fri, 16 Dec 2005 10:33:56 -0800 (PST) Received: by 10.65.72.5 with HTTP; Fri, 16 Dec 2005 10:33:56 -0800 (PST) Message-ID: Date: Sat, 17 Dec 2005 02:33:56 +0800 From: Xin LI To: Kostik Belousov In-Reply-To: <20051216151016.GE84442@deviant.zoral.local> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <20051216133448.GA10382@beastie.creo.hu> <20051216151016.GE84442@deviant.zoral.local> Cc: Csaba Henk , freebsd-current@freebsd.org Subject: Re: Easy DoS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: delphij@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2005 18:34:04 -0000 SGksCgpPbiAxMi8xNi8wNSwgS29zdGlrIEJlbG91c292IDxrb3N0aWtiZWxAZ21haWwuY29tPiB3 cm90ZToKPiBTdXJlLCBpdCBpcyBhIGJ1ZyA6KS4KPgo+IFBsZWFzZSwgdHJ5IHRoZSBmb2xsb3dp bmcgcGF0Y2ggKGFnYWluc3QgNy1DVVJSRU5ULAo+IHNoYWxsIHdvcmsgZm9yIDYtU1RBQkxFIHRv byk6Cj4KPiAtLS0gc3JjLXByaXN0aW5lL3N5cy9rZXJuL3N5c19waXBlLmMgICAgTW9uIEp1bCAx MSAxMTozMzo1OCAyMDA1Cj4gKysrIHNyYy1xdW90YXMvc3lzL2tlcm4vc3lzX3BpcGUuYyAgICAg IEZyaSBEZWMgMTYgMTc6MDM6MDEgMjAwNQo+IEBAIC0xMTc2LDYgKzExNzYsOCBAQAo+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICgiUGlwZSBidWZmZXIgb3ZlcmZsb3ci KSk7Cj4gICAgICAgICAgICAgICAgICAgICAgICB9Cj4gICAgICAgICAgICAgICAgICAgICAgICBw aXBldW5sb2NrKHdwaXBlKTsKPiArICAgICAgICAgICAgICAgICAgICAgICBpZiAoZXJyb3IgIT0g MCkKPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJyZWFrOwo+ICAgICAgICAgICAg ICAgIH0gZWxzZSB7Cj4gICAgICAgICAgICAgICAgICAgICAgICAvKgo+ICAgICAgICAgICAgICAg ICAgICAgICAgICogSWYgdGhlICJyZWFkLXNpZGUiIGhhcyBiZWVuIGJsb2NrZWQsIHdha2UgaXQg dXAgbm93LgoKUGF0Y2ggbG9va3MgZ29vZCBzbyBJIGhhdmUgY29tbWl0dGVkIGl0IGFzIHN5cy9r ZXJuL3N5c19waXBlLmMsdgoxLjE4NS4gIFRoYW5rcyBmb3IgdGhlIHN1Ym1pc3Npb24hCgpDaGVl cnMsCi0tClhpbiBMSSA8ZGVscGhpakBkZWxwaGlqLm5ldD4gaHR0cDovL3d3dy5kZWxwaGlqLm5l dAo= From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 18:41:34 2005 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 DB96416A41F; Fri, 16 Dec 2005 18:41:34 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CEA343D58; Fri, 16 Dec 2005 18:41:24 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.3/8.13.3) with ESMTP id jBGIfC9l066308; Fri, 16 Dec 2005 10:41:12 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.3/8.13.3/Submit) id jBGIfBDB066307; Fri, 16 Dec 2005 10:41:11 -0800 (PST) (envelope-from jmg) Date: Fri, 16 Dec 2005 10:41:11 -0800 From: John-Mark Gurney To: Matthias Andree Message-ID: <20051216184111.GG55657@funkthat.com> Mail-Followup-To: Matthias Andree , Craig Rodrigues , freebsd-fs@freebsd.org, freebsd-current@freebsd.org References: <20051213151908.GA26821@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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-fs@freebsd.org, Craig Rodrigues , freebsd-current@freebsd.org Subject: Re: XFS (read-only) support committed to CURRENT 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: Fri, 16 Dec 2005 18:41:35 -0000 Matthias Andree wrote this message on Fri, Dec 16, 2005 at 12:15 +0100: > Craig Rodrigues writes: > > > Read-only XFS support has been committed to FreeBSD-CURRENT. > > Write access to XFS is not supported at this time. > > The XFS for FreeBSD source code is based off of GPL'd sources > > provided by SGI. > > Hm. Does this mean that FreeBSD's XFS implementation is GPL'd like > ext2fs is? You could of just looked at the source code yourself: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/gnu/fs/xfs/xfs_cap.c?rev=1.1&content-type=text/x-cvsweb-markup (And for the others, yes it is GPL'd) -- 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 Fri Dec 16 19:04:02 2005 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 9A75916A41F; Fri, 16 Dec 2005 19:04:02 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DA1E43D73; Fri, 16 Dec 2005 19:03:51 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id jBGJ3mTA019804; Fri, 16 Dec 2005 12:03:48 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <43A30F94.2030909@samsco.org> Date: Fri, 16 Dec 2005 12:03:48 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gary Kline References: <43A266E5.3080103@samsco.org> <70e8236f0512160659h3379253dw468e5aad3f741002@mail.gmail.com> <20051216190031.GD58262@thought.org> In-Reply-To: <20051216190031.GD58262@thought.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: Joao Barros , stable@freebsd.org, current Subject: Re: HEADS UP: Release schedule for 2006 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, 16 Dec 2005 19:04:02 -0000 Gary Kline wrote: > On Fri, Dec 16, 2005 at 02:59:09PM +0000, Joao Barros wrote: > >>On 12/16/05, Scott Long wrote: >> >> >>>FreeBSD 7 >>>We will start preparing for FreeBSD 7.0 in June 2007. >>> >>>I'll hopefully update the release engineering pages soon to reflect >>>this. If you have any questions, please feel free to contact me and the >>>rest of the release engineering team. Thanks!ott >> >>There have been some questions on the lists about what to expect from >>release x.y and I personnally have always looked at the TODO list like >>http://www.freebsd.org/releases/6.0R/todo.html >>For 6.0 I noticed there were more updates on that page for bugs and >>their fixes than for features per se. My sugestion, maybe at a first >>stage setting the TODO list has it's advantages, one knows what to >>expect from a release, it's clearly stated and documented there and >>the developers can see their goals. >>This is valid for minor and major releases of course. >> >>How about it? >> > > > Are you volunteering to post the TODO lists here on -stable > every N months? I think it's a great idea to have some > clues about where we're going, or hope to be going. > > gary > > > > The release TODO list is maintained on the FreeBSD.org website, though it's usually only active during release cycles. I used to also email it out in text format to the mailing lists on a weekly basis. Scott From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 19:00:36 2005 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 34DB816A436; Fri, 16 Dec 2005 19:00:36 +0000 (GMT) (envelope-from kline@tao.thought.org) Received: from tao.thought.org (dsl231-043-140.sea1.dsl.speakeasy.net [216.231.43.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6F7143D5C; Fri, 16 Dec 2005 19:00:34 +0000 (GMT) (envelope-from kline@tao.thought.org) Received: from tao.thought.org (localhost [127.0.0.1]) by tao.thought.org (8.13.1/8.13.1) with ESMTP id jBGJ0XZu058687; Fri, 16 Dec 2005 11:00:33 -0800 (PST) (envelope-from kline@tao.thought.org) Received: (from kline@localhost) by tao.thought.org (8.13.1/8.13.1/Submit) id jBGJ0Vts058686; Fri, 16 Dec 2005 11:00:31 -0800 (PST) (envelope-from kline) Date: Fri, 16 Dec 2005 11:00:31 -0800 From: Gary Kline To: Joao Barros Message-ID: <20051216190031.GD58262@thought.org> References: <43A266E5.3080103@samsco.org> <70e8236f0512160659h3379253dw468e5aad3f741002@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <70e8236f0512160659h3379253dw468e5aad3f741002@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-Organization: Thought Unlimited. Public service Unix since 1986. X-Of_Interest: Observing 19 years of service to the Unix community X-Mailman-Approved-At: Fri, 16 Dec 2005 19:12:48 +0000 Cc: stable@freebsd.org, current Subject: Re: HEADS UP: Release schedule for 2006 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, 16 Dec 2005 19:00:36 -0000 On Fri, Dec 16, 2005 at 02:59:09PM +0000, Joao Barros wrote: > On 12/16/05, Scott Long wrote: > > > FreeBSD 7 > > We will start preparing for FreeBSD 7.0 in June 2007. > > > > I'll hopefully update the release engineering pages soon to reflect > > this. If you have any questions, please feel free to contact me and the > > rest of the release engineering team. Thanks!ott > > There have been some questions on the lists about what to expect from > release x.y and I personnally have always looked at the TODO list like > http://www.freebsd.org/releases/6.0R/todo.html > For 6.0 I noticed there were more updates on that page for bugs and > their fixes than for features per se. My sugestion, maybe at a first > stage setting the TODO list has it's advantages, one knows what to > expect from a release, it's clearly stated and documented there and > the developers can see their goals. > This is valid for minor and major releases of course. > > How about it? > Are you volunteering to post the TODO lists here on -stable every N months? I think it's a great idea to have some clues about where we're going, or hope to be going. gary > -- Gary Kline kline@thought.org www.thought.org Public service Unix From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 19:49:51 2005 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 6F75416A41F; Fri, 16 Dec 2005 19:49:51 +0000 (GMT) (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 0E3AE43D66; Fri, 16 Dec 2005 19:49:44 +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.4/8.13.4) with ESMTP id jBGJnZh0007215; Fri, 16 Dec 2005 20:49:35 +0100 Received: from localhost (ggajic@localhost) by afrodita.rcub.bg.ac.yu (8.13.4/8.13.4/Submit) with ESMTP id jBGJnYdW007212; Fri, 16 Dec 2005 20:49:35 +0100 Date: Fri, 16 Dec 2005 20:49:34 +0100 (CET) From: Goran Gajic To: John Baldwin In-Reply-To: <200512151356.41550.jhb@freebsd.org> Message-ID: References: <200512151356.41550.jhb@freebsd.org> 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: Fri, 16 Dec 2005 19:51:18 +0000 Cc: freebsd-current@freebsd.org Subject: Re: skype-1.2.0.18-static for linux and FreeBSD 7.0 CURRENT 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, 16 Dec 2005 19:49:51 -0000 Sorry, forgot to attach: [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: 3b91780,dbc9dd04,c,c3b91780,dbc9dd30) at read+0x45 syscall(8f3003b,8f3003b,bfbf003b,befff92c,906256c) at syscall+0x27e Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (3, Linux ELF, read), eip = 0x28feec3b, esp = 0xbefff860, ebp = 0xffffffff --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x3 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0816f04 stack pointer = 0x28:0xdbc9d804 frame pointer = 0x28:0xdbc9d83c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 570 (skype) exclusive sleep mutex vnode interlock r = 0 (0xc366e21c) locked @ kern/vfs_vnops.c:791 panic: from debugger Uptime: 3m24s Dumping 511 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 511MB (130736 pages) 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:165 165 pcpu.h: No such file or directory. in pcpu.h (kgdb) backtrace #0 doadump () at pcpu.h:165 #1 0xc066b0d4 in boot (howto=260) at ../../../kern/kern_shutdown.c:399 #2 0xc066b37f in panic (fmt=0xc0861fba "from debugger") at ../../../kern/kern_shutdown.c:555 #3 0xc0484e15 in db_panic (addr=-1065259260, have_addr=0, count=-1, modif=0xdbc9d5d8 "") at ../../../ddb/db_command.c:435 #4 0xc0484dac in db_command (last_cmdp=0xc094e7a4, cmd_table=0x0, aux_cmd_tablep=0xc08c4d24, aux_cmd_tablep_end=0xc08c4d40) at ../../../ddb/db_command.c:404 #5 0xc0484e74 in db_command_loop () at ../../../ddb/db_command.c:455 #6 0xc0486a8d in db_trap (type=12, code=0) at ../../../ddb/db_main.c:221 #7 0xc0684f2b in kdb_trap (type=12, code=0, tf=0xdbc9d7c4) at ../../../kern/subr_kdb.c:485 #8 0xc0829f68 in trap_fatal (frame=0xdbc9d7c4, eva=3) at ../../../i386/i386/trap.c:853 #9 0xc0829cd3 in trap_pfault (frame=0xdbc9d7c4, usermode=0, eva=3) at ../../../i386/i386/trap.c:770 #10 0xc08298ed in trap (frame= {tf_fs = 1717960712, tf_es = -1066860504, tf_ds = 40, tf_edi = -1063052000, tf_esi = 4, tf_ebp = -607528900, tf_isp = -607528976, tf_ebx = 0, tf_edx = 3, tf_ecx = 683600955, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1065259260, tf_cs = 32, tf_eflags = 66067, tf_esp = 0, tf_ss = -607528952}) at ../../../i386/i386/trap.c:455 #11 0xc08188ba in calltrap () at ../../../i386/i386/exception.s:137 #12 0xc0816f04 in db_read_bytes (addr=3, size=3, data=0xdbc9d850 "") at ../../../i386/i386/db_interface.c:63 #13 0xc04845a1 in db_get_value (addr=3, size=4, is_signed=0) at ../../../ddb/db_access.c:66 #14 0xc08172a7 in db_numargs (fp=0xffffffff) at ../../../i386/i386/db_trace.c:207 #15 0xc0817870 in db_backtrace (td=0xc3b91780, tf=0x0, frame=0xffffffff, pc=687795259, count=1006) at ../../../i386/i386/db_trace.c:458 #16 0xc0817957 in db_trace_self () at pcpu.h:162 #17 0xc0684c2d in kdb_backtrace () at ../../../kern/subr_kdb.c:253 #18 0xc068ef98 in witness_checkorder (lock=0xc3b8fb44, flags=9, file=0xc08be5a5 "i386/i386/trap.c", line=742) at ../../../kern/subr_witness.c:1085 #19 0xc06633ab in _mtx_lock_flags (m=0xc3b8fb44, opts=0, file=0xc08be59c "../../../i386/i386/trap.c", line=742) at ../../../kern/kern_mutex.c:284 #20 0xc0829bfa in trap_pfault (frame=0xdbc9da28, usermode=0, eva=3) at ../../../i386/i386/trap.c:742 #21 0xc08298ed in trap (frame= {tf_fs = -607584248, tf_es = -1066926040, tf_ds = -1063583704, tf_edi = -1011280000, tf_esi = -607528316, tf_ebp = -607528336, tf_isp = -607528364, tf_ebx = -1, tf_edx = -1065252593, tf_ecx = -607528316, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1065256548, tf_cs = 32, tf_eflags = 66054, tf_esp = 12290, t f_ss = -1016667620}) at ../../../i386/i386/trap.c:455 #22 0xc08188ba in calltrap () at ../../../i386/i386/exception.s:137 #23 0xc081799c in stack_save (st=0xdbc9da84) at ../../../i386/i386/db_trace.c:521 #24 0xc065fd49 in lockmgr (lkp=0xc366e1ac, flags=12290, interlkp=0xc366e21c, td=0xc3b91780) at ../../../kern/kern_lock.c:172 #25 0xc06b9ae5 in vop_stdlock (ap=0xc081890f) at ../../../kern/vfs_default.c:263 #26 0xc083c513 in VOP_LOCK_APV (vop=0xc092f4e0, a=0xdbc9db50) at vnode_if.c:1612 #27 0xc07a9204 in ffs_lock (ap=0xdbc9db50) at ../../../ufs/ffs/ffs_vnops.c:341 #28 0xc083c513 in VOP_LOCK_APV (vop=0xc093b180, a=0xdbc9db50) at vnode_if.c:1612 #29 0xc06cdd5c in vn_lock (vp=0xc366e154, flags=4098, td=0xc3b91780) at vnode_if.h:844 #30 0xc06cd477 in vn_read (fp=0xc3aba6c0, uio=0xdbc9dc60, active_cred=0xc3c7dd80, flags=0, td=0xc3b91780) at ../../../kern/vfs_vnops.c:498 #31 0xc0690709 in dofileread (td=0xc3b91780, fd=10, fp=0xc3aba6c0, auio=0xdbc9dc60, offset=Unhandled dwarf expression opcode 0x93 ) at file.h:235 #32 0xc06905a2 in kern_readv (td=0xc3b91780, fd=10, auio=0xdbc9dc60) at ../../../kern/sys_generic.c:192 #33 0xc06904cd in read (td=0xc3b91780, uap=0xdbc9da84) at ../../../kern/sys_generic.c:116 #34 0xc082a27e in syscall (frame= {tf_fs = 150143035, tf_es = 150143035, tf_ds = -1078001605, tf_edi = -1090520788, tf_esi = 151397740, tf_ebp = -1, tf_isp = -607527580, tf_ebx = 10, tf_ed x = 8, tf_ecx = -1090520916, tf_eax = 3, tf_trapno = 12, tf_err = 2, tf_eip = 687795259, tf_cs = 51, tf_eflags = 582, tf_esp = -1090520992, tf_ss = 59}) at ../../../i386/i386/trap.c:1008 #35 0xc081890f in Xint0x80_syscall () at ../../../i386/i386/exception.s:190 #36 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) gg. From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 20:10:49 2005 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 CCCEC16A41F for ; Fri, 16 Dec 2005 20:10:49 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5A9B43D5C for ; Fri, 16 Dec 2005 20:10:48 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 3960496 for multiple; Fri, 16 Dec 2005 15:08:49 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jBGKAgBK081855; Fri, 16 Dec 2005 15:10:42 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 16 Dec 2005 14:54:21 -0500 User-Agent: KMail/1.8.2 References: <17314.60552.595375.783753@grasshopper.cs.duke.edu> In-Reply-To: <17314.60552.595375.783753@grasshopper.cs.duke.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512161454.22232.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1210/Thu Dec 15 10:23:22 2005 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: Andrew Gallatin Subject: Re: PREEMPTION vs ndisulator 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, 16 Dec 2005 20:10:49 -0000 On Friday 16 December 2005 11:34 am, Andrew Gallatin wrote: > I'm trying to use an ndis driver on an amd64 machine running > FreeBSD/amd64 -current from yesterday. If I enable PREEMPTION, the > machine hangs when loading the driver (kldload never returns): > > ndis0: mem > 0xfc000000-0xfcffffff,0xfdf00000-0xfdffffff irq 18 at device 0.0 on pci5 > ndis0: NDIS API version: 5.1 > > > Witness detects no problems, and if I disable PREEMPTION, the driver > seems to work fine. Is PREEMPTION not safe to be used with the > ndisulator, or is there a problem with the ndis driver itself? > > I've included some very brief debugging info below.. Looks like an ithread has preempted your driver's start routine. If you let it run some more and then break into ddb is the same thread (pid 11) still running? Also, which process is pid 11? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 20:10:51 2005 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 0D3C216A41F for ; Fri, 16 Dec 2005 20:10:51 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B92E43D49 for ; Fri, 16 Dec 2005 20:10:50 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 3960499 for multiple; Fri, 16 Dec 2005 15:08:52 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jBGKAgBL081855; Fri, 16 Dec 2005 15:10:46 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 16 Dec 2005 15:11:09 -0500 User-Agent: KMail/1.8.2 References: <200512161237.15148.mistry.7@osu.edu> In-Reply-To: <200512161237.15148.mistry.7@osu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512161511.10903.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1210/Thu Dec 15 10:23:22 2005 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=4.2 tests=ALL_TRUSTED,BIZ_TLD autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: Subject: Re: Reproducable Panic on CURRENT and 6.0-RELEASE 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, 16 Dec 2005 20:10:51 -0000 On Friday 16 December 2005 12:37 pm, Anish Mistry wrote: > Here is the offending program/code. The interesting program is > avidemux_2.1_branch_anish/avidemux/avidemux2. > (It is compiled for CURRENT, and I left all the object code stuff in > so it's a bit large 21MB) > http://am-productions.biz/docs/avidemux_2.1_branch_anish.tgz > > First you'll need to compile spidermonkey to be threadsafe so add the > following to your lang/spidermonkey/Makefile before installing it: > LIB_DEPENDS= nspr4.1:${PORTSDIR}/devel/nspr > MAKE_ARGS+= JS_THREADSAFE=YES LDFLAGS="-L${LOCALBASE}/lib > -lpthread -lm" > CFLAGS+= -I${LOCALBASE}/include/nspr > > Once a threadsafe spidermonkey is installed to kill the machine you'll > need to: > cd avidemux_2.1_branch_anish/avidemux > ./avidemux2 --run new-features-test.js > > On CURRENT: > kernel trap 12 with interrupts disabled > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x68 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc04e6f36 > stack pointer = 0x28:0xcc9edb3c > frame pointer = 0x28:0xcc9edbb0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = resume, IOPL = 0 > current process = 798 (gdb) > trap number = 12 > panic: page fault > > #0 doadump () at pcpu.h:165 > #1 0xc04bb7eb in boot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:399 > #2 0xc04bb353 in panic (fmt=0xc06069a7 "%s") > at /usr/src/sys/kern/kern_shutdown.c:555 > #3 0xc05e91ba in trap_fatal (frame=0xcc9edafc, eva=104) > at /usr/src/sys/i386/i386/trap.c:862 > #4 0xc05e96d9 in trap (frame= > {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -1032878460, tf_esi > = 1, tf_ebp = -862004304, tf_isp = -862004440, tf_ebx = -1033297504, > tf_edx = -1033987232, tf_ecx = 4, tf_eax = 0, tf_trapno = 12, tf_err > = 0, tf_eip = -1068601546, tf_cs = 32, tf_eflags = 65687, tf_esp = > -1032878356, tf_ss = -1067380424}) > at /usr/src/sys/i386/i386/trap.c:273 > #5 0xc05db6fa in calltrap () > at /usr/src/sys/i386/i386/exception.s:137 > #6 0xc04e6f36 in kern_ptrace (td=0xc25e9b60, req=10, pid=1, addr=0x0, > data=17) > at /usr/src/sys/kern/sys_process.c:802 On HEAD this is: p->p_xthread->td_flags &= ~TDF_XSIG; If two threads called kern_ptrace() with the same PID and this could happen. Hmm, I have no idea how p_xthread is supposed to not be racey here in fact. It would be helpful to know what PTRACE action it it is trying to do and maybe a KTR trace of the various ptrace events leading up to this condition. I have no idea what thread you are supposed to act on if p_xthread is NULL either. > #7 0xc04e71f0 in ptrace (td=0xc25e9b60, uap=0xcc9edd04) > at /usr/src/sys/kern/sys_process.c:433 > #8 0xc05e9ca6 in syscall (frame= > {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 136221752, tf_esi > = 796, tf_ebp = -1077943184, tf_isp = -862003868, tf_ebx = 796, > tf_edx = 674587084, tf_ecx = 674505768, tf_eax = 26, tf_trapno = 12, > tf_err = 2, tf_eip = 673978987, tf_cs = 51, tf_eflags = 518, tf_esp = > -1077943208, tf_ss = 59}) > at /usr/src/sys/i386/i386/trap.c:1008 > ---Type to continue, or q to quit--- > #9 0xc05db74f in Xint0x80_syscall () > at /usr/src/sys/i386/i386/exception.s:190 > #10 0x00000033 in ?? () > > > http://am-productions.biz/docs/littleguy-dmesg.gz > http://am-productions.biz/docs/littleguy-pciconf.gz > > > > From my previous email to questions with the info on 6.0-RELEASE: > I'm getting the following panic, which I can reproduce easily. Let me > know what other information I should provide. The backtrace seems > really short for some reason. I get the panic when running a > multi-threaded application I'm developing/modifying. > > kernel trap 12 with interrupts disabled > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x48 > fault code = supervisor write, page not present > instruction pointer = 0x20:0xc0510cb3 > stack pointer = 0x28:0xe9aebb74 > frame pointer = 0x28:0xe9aebbf8 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = resume, IOPL = 0 > current process = 7848 (gdb) > [thread pid 7848 tid 100184 ] > Stopped at kern_ptrace+0x11e3: andl $0xfffbffff,0x48(%eax) > db> bt > Tracing pid 7848 tid 100184 td 0xc4302180 > kern_ptrace(c4302180,a,1ea6,0,11) at kern_ptrace+0x11e3 > ptrace(c4302180,e9aebd04,10,418,4) at ptrace+0x56 > syscall(3b,3b,3b,bfbfe580,1ea6) at syscall+0x13d > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (26, FreeBSD ELF32, ptrace), eip = 0x283360e7, esp = > 0xbfbfe3bc, ebp > = 0xbfbfe3d8 --- > > > > Full panic and backtrace, and alltrace: > http://am-productions.biz/docs/bigguy-panic.gz > http://am-productions.biz/docs/bigguy-dmesg.gz > http://am-productions.biz/docs/bigguy-pciconf.gz > Kernel config: > http://am-productions.biz/docs/BIGGUY.gz > > > I have firewire console access to the CURRENT system, and serial > console access for the 6.0-RELEASE. > > Thanks, -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 20:21:55 2005 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 A499616A420 for ; Fri, 16 Dec 2005 20:21:55 +0000 (GMT) (envelope-from raj@cserv62.csub.edu) Received: from cserv62.csub.edu (cserv62.csub.edu [136.168.10.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B64D43D7B for ; Fri, 16 Dec 2005 20:21:54 +0000 (GMT) (envelope-from raj@cserv62.csub.edu) Received: from vala (vala-00080daa2608.dhcp.csub.edu [136.168.248.171]) by cserv62.csub.edu (8.13.4/8.13.4) with ESMTP id jBGKLpEn064542 for ; Fri, 16 Dec 2005 12:21:52 -0800 (PST) (envelope-from raj@cserv62.csub.edu) Date: Fri, 16 Dec 2005 12:22:09 +0000 From: Russell Jackson To: freebsd-current@freebsd.org Message-ID: <20051216122209.28c18db8@vala> Organization: CSUB X-Mailer: Sylpheed-Claws 1.9.100 (GTK+ 2.8.7; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Toshiba Portege 4010 g_vfs_done error = 6 on resume 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, 16 Dec 2005 20:21:55 -0000 My Toshiba Portege 4010 continues to be unable to resume after a suspend on a freshly compiled CURRENT. On suspend I get an interrupt storm on irq11 (USB controller), but it does successfully go into suspend. On resume, the video comes back up and the console is responsive; however, any attempt to access the disk results in g_vfs_done() = 6 errors for either READ or WRITE along with the occasional 'initiate_write_filepage: already started'. A sync results in an immediate kernel panic: 'vinvalbuf: dirty bufs'. I've included both my dmesg output and an AML dump in the case that this is related to ACPI. /var/run/dmesg.boot: Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 7.0-CURRENT #5: Thu Dec 15 18:14:40 UTC 2005 raj@vala:/usr/src/sys/i386/compile/VALA Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Mobile Intel(R) Pentium(R) III CPU - M 933MHz (929.57-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6b4 Stepping = 4 Features=0x383f9ff real memory = 251002880 (239 MB) avail memory = 236101632 (225 MB) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xee08-0xee0b on acpi0 cpu0: on acpi0 acpi_perf0: on cpu0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 acpi_video0: mem 0xfc000000-0xfdffffff,0xfbc00000-0xfbffffff,0xf8000000-0xf9ffffff,0xf7ff8000-0xf7ffffff irq 11 at device 0.0 on pci1 ohci0: mem 0xf7eff000-0xf7efffff irq 11 at device 2.0 on pci0 controller> ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: AcerLabs OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xeff0-0xefff at device 4.0 on pci0 atapci0: using PIO transfers above 137GB as workaround for 48bit DMA access bug, expect reduced performance ata0: on atapci0 ata1: on atapci0 pcm0: at device 6.0 on pci0 pcm0: pcm0: [GIANT-LOCKED] isab0: at device 7.0 on pci0 isa0: on isab0 pci0: at device 8.0 (no driver attached) fxp0: port 0xeec0-0xeeff mem 0xf7efe000-0xf7efefff,0xf7ec0000-0xf7edffff irq 11 at device 10.0 on pci0 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:08:0d:aa:26:08 fwohci0: at device 12.0 on pci0 fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:00:39:00:00:1a:26:b1 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=0xc000ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) cbb0: at device 16.0 on pci0 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb1: at device 17.0 on pci0 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 cbb2: at device 17.1 on pci0 cardbus2: on cbb2 pccard2: <16-bit PCCard bus> on cbb2 pci0: at device 18.0 (no driver attached) acpi_lid0: on acpi0 battery0: on acpi0 battery1: on acpi0 acpi_acad0: on acpi0 acpi_toshiba0: on acpi0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcbfff,0xe0000-0xeffff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled uhub1: Mitsumi Electric Hub in Apple Extended USB Keyboard, class 9/0, rev 1.10/1.22, addr 2 uhub1: 3 ports with 2 removable, bus powered ukbd0: Mitsumi Electric Apple Extended USB Keyboard, rev 1.10/1.22, addr 3, iclass 3/1 kbd1 at ukbd0 uhid0: Mitsumi Electric Apple Extended USB Keyboard, rev 1.10/1.22, addr 3, iclass 3/1 ums0: vendor 0x045e product 0x0009, rev 1.00/1.05, addr 4, iclass 3/1 ums0: 3 buttons and Z dir. Timecounter "TSC" frequency 929567735 Hz quality 800 Timecounters tick every 1.000 msec ata2: at port 0x100-0x10f irq 11 function 0 config 1 on pccard1 wi0: at port 0x180-0x1bf irq 11 function 0 config 1 on pccard0 wi0: using Lucent Embedded WaveLAN/IEEE wi0: Lucent Firmware: Station (8.10.1) wi0: Ethernet address: 00:02:2d:6c:f7:ca ad0: 28615MB at ata0-master UDMA66 acd0: CDRW at ata1-master UDMA33 ad4: 119MB at ata2-master PIO2 Trying to mount root from ufs:/dev/ad0s3a WARNING: / was not properly dismounted WARNING: /var was not properly dismounted WARNING: /tmp was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /home was not properly dismounted fxp0: link state changed to UP AML dump: /* * Intel ACPI Component Architecture * AML Disassembler version 20041119 * * Disassembly of dump, Sun May 29 19:22:09 2005 */ DefinitionBlock ("DSDT.aml", "DSDT", 1, "TOSHIB", "4010 ", 537003538) { Name (\_S0, Package (0x04) { 0x00, 0x00, 0x00, 0x00 }) Name (\_S3, Package (0x04) { 0x07, 0x00, 0x00, 0x00 }) Name (\_S4, Package (0x04) { 0x07, 0x00, 0x00, 0x00 }) Name (\_S5, Package (0x04) { 0x07, 0x00, 0x00, 0x00 }) Scope (\_PR) { Processor (CPU0, 0x01, 0x0000EE10, 0x06) { Name (_PCT, Package (0x02) { ResourceTemplate () { Register (SystemIO, 0x08, 0x00, 0x00000000000000B1) }, ResourceTemplate () { Register (SystemIO, 0x10, 0x00, 0x000000000000EF40) } }) Method (_PSS, 0, NotSerialized) { If (\_SB.MEM.PSS1) { Name (PSSD, Package (0x02) { Package (0x00) {}, Package (0x00) {} }) Name (PSD0, Package (0x06) { 0x03E8, 0x55F0, 0xFA, 0xFA, 0x90, 0x00 }) Name (PSD1, Package (0x06) { 0x02BC, 0x2648, 0xFA, 0xFA, 0x91, 0x01 }) Store (\_SB.MEM.PSS0, Index (PSD0, 0x00)) Store (\_SB.MEM.PSS1, Index (PSD1, 0x00)) Store (PSD0, Index (PSSD, 0x00)) Store (PSD1, Index (PSSD, 0x01)) Return (PSSD) } Else { Name (PSSC, Package (0x01) { Package (0x00) {} }) Name (PSC0, Package (0x06) { 0x03E8, 0x55F0, 0xFA, 0xFA, 0x90, 0x00 }) Store (\_SB.MEM.PSS0, Index (PSC0, 0x00)) Store (PSC0, Index (PSSC, 0x00)) Return (PSSC) } } Method (_PPC, 0, NotSerialized) { SMBR (0xFC00, 0x3D, 0x00, 0x00, 0xB2) And (\_SB.MEM.OECX, 0x03, Local0) If (LEqual (Local0, 0x00)) { If (\_SB.MEM.HPSU) { If (\_SB.MEM.ACST) { Return (\_SB.MEM.PULA) } Else { Return (\_SB.MEM.PULD) } } Else { Return (0x00) } } Else { If (LEqual (Local0, 0x01)) { Return (0x00) } Else { Return (0x01) } } } } } Scope (\_SB) { Device (MEM) { Name (_HID, EisaId ("PNP0C01")) Name (_STA, 0x0F) Method (_CRS, 0, NotSerialized) { Return (CRS (0x01)) } OperationRegion (SRAM, SystemMemory, 0x000EE800, 0x1800) Field (SRAM, AnyAcc, NoLock, Preserve) { PAR1, 16, PAR2, 16, PAR3, 16, PAR4, 16, PAR5, 16, PAR6, 16 } Field (SRAM, AnyAcc, NoLock, Preserve) { Offset (0x02), RDID, 32, RDSN, 32, CAPB, 16 } Field (SRAM, AnyAcc, NoLock, Preserve) { IEAX, 32, IEBX, 32, IECX, 32, IEDX, 32, IESI, 32, IEDI, 32, IEBP, 32, Offset (0x20), OEAX, 32, OEBX, 32, OECX, 32, OEDX, 32, OESI, 32, OEDI, 32, OEBP, 32, Offset (0xFF), ACST, 1, BES1, 1, BES2, 1, Offset (0x100), BMN1, 104, BSN1, 88, BTP1, 72, BPU1, 32, BDC1, 32, BLF1, 32, BTC1, 32, BDV1, 32, BST1, 32, BPR1, 32, BRC1, 32, BPV1, 32, Offset (0x149), BCW1, 32, BCL1, 32, BG11, 32, BG21, 32, BOI1, 8, BRF1, 1, Offset (0x200), BMN2, 104, BSN2, 88, BTP2, 72, BPU2, 32, BDC2, 32, BLF2, 32, BTC2, 32, BDV2, 32, BST2, 32, BPR2, 32, BRC2, 32, BPV2, 32, Offset (0x249), BCW2, 32, BCL2, 32, BG12, 32, BG22, 32, BOI2, 32, Offset (0x300), AC01, 16, AC11, 16, PSV1, 16, CRT1, 16, TMP1, 16, AST1, 16, AC21, 16, AC31, 16, AC02, 16, AC12, 16, PSV2, 16, CRT2, 16, TMP2, 16, AST2, 16, AC22, 16, AC32, 16, AC03, 16, AC13, 16, PSV3, 16, CRT3, 16, TMP3, 16, AST3, 16, AC23, 16, AC33, 16, Offset (0x340), TMPF, 16, Offset (0x3F0), FANH, 1, FANL, 7, TF11, 1, TF21, 1, TF31, 1, , 1, TF10, 1, TF20, 1, TF30, 1, Offset (0x3F2), TP11, 1, TP21, 1, TP31, 1, Offset (0x400), GP50, 1, GP51, 1, GP52, 1, GP53, 1, GP54, 1, Offset (0x401), GP60, 1, GP61, 1, GP62, 1, GP63, 1, GP64, 1, GP65, 1, GP66, 1, Offset (0x402), GP70, 1, GP71, 1, GP72, 1, GP73, 1, GP74, 1, GP75, 1, GP76, 1, GP77, 1, WED0, 1, WED1, 1, WED2, 1, WED3, 1, WED4, 1, Offset (0x404), SBL0, 1, SBL1, 1, SBL2, 1, SBL3, 1, Offset (0x405), LIDS, 1, VALF, 1, DCST, 1, DOS2, 1, DCKI, 1, DCKF, 1, BT1F, 1, BT2F, 1, NXLA, 1, NXCA, 1, NXTA, 1, NXDA, 1, CTLA, 1, CTCA, 1, CTTA, 1, CTDA, 1, LANA, 1, Offset (0x483), GCVS, 8, Offset (0x4C0), PSS0, 16, PSS1, 16, Offset (0x4D0), SYU0, 1, SYU1, 1, SYU2, 1, SYU3, 1, SYU4, 1, SYU5, 1, SYU6, 1, SYU7, 1, RPPC, 1, Offset (0x500), HKCD, 8, Offset (0x502), DLID, 32, DSRN, 32, Offset (0x50E), BDID, 32, DSPW, 1, VGAF, 1, VWE0, 1, VWE1, 1, PPSC, 1, SPSC, 1, EWLD, 1, EPWS, 1, LCDS, 4, CRTS, 4, VWE2, 1, WEF0, 1, WEF1, 1, WED5, 1, IEWE, 1, Offset (0x515), BTMD, 1, WSF0, 1, WSF1, 1, GP83, 1, WUIE, 1, , 1, BPFE, 1, BWUE, 1, DVIS, 4, Offset (0x517), HTM0, 1, HTM1, 1, Offset (0x518), PSND, 1, PMDM, 1, Offset (0x520), VGAR, 1, KBCR, 1, ID0R, 1, ID1R, 1, ID2R, 1, ID3R, 1, IDAR, 1, ACLR, 1, BTRE, 1, Offset (0x701), HAPS, 2, HHSW, 2, HPSU, 2, HRCU, 2, HGSU, 2, HEBI, 2, HTMD, 2, Offset (0x708), TNVS, 1, OSPC, 1, ACBK, 1, Offset (0x70A), PULD, 8, PULA, 8, BCLD, 8, BCLA, 8, Offset (0x710), OSID, 8, Offset (0x720), MSSI, 16, MSSS, 8, MSSR, 8, MSP0, 8, MSC0, 8, MSP1, 8, MSC1, 8, Offset (0x740), Offset (0x800), PRES, 32768 } Field (SRAM, AnyAcc, NoLock, Preserve) { Offset (0x406), NXDD, 4, CTDD, 4 } Field (SRAM, AnyAcc, NoLock, Preserve) { Offset (0x800), Offset (0x808), Offset (0x812), Offset (0x814), Offset (0x818), FSDP, 8, Offset (0x823), Offset (0x826), Offset (0x836), Offset (0x87E), Offset (0x87F), EDCK, 8 } } Device (PCI0) { Name (_HID, EisaId ("PNP0A03")) Name (_ADR, 0x00) Name (_CRS, ResourceTemplate () { WordBusNumber (ResourceProducer, MinFixed, MaxFixed, PosDecode, 0x0000, 0x0000, 0x00FF, 0x0000, 0x0100) IO (Decode16, 0x0CF8, 0x0CF8, 0x01, 0x08) WordIO (ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange, 0x0000, 0x0000, 0x0CF7, 0x0000, 0x0CF8) WordIO (ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange, 0x0000, 0x0D00, 0xFFFF, 0x0000, 0xF300) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, NonCacheable, ReadWrite, 0x00000000, 0x000A0000, 0x000BFFFF, 0x00000000, 0x00020000) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, NonCacheable, ReadWrite, 0x00000000, 0x000D8000, 0x000DFFFF, 0x00000000, 0x00008000) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, NonCacheable, ReadWrite, 0x00000000, 0x40100000, 0xFEE9FFFF, 0x00000000, 0xBEEA0000) }) Name (_PRT, Package (0x09) { Package (0x04) { 0x0011FFFF, 0x00, \_SB.PCI0.FNC0.LNKA, 0x00 }, Package (0x04) { 0x0011FFFF, 0x01, \_SB.PCI0.FNC0.LNKB, 0x00 }, Package (0x04) { 0x000AFFFF, 0x00, \_SB.PCI0.FNC0.LNKD, 0x00 }, Package (0x04) { 0x0010FFFF, 0x00, \_SB.PCI0.FNC0.LNKC, 0x00 }, Package (0x04) { 0x0010FFFF, 0x01, \_SB.PCI0.FNC0.LNKD, 0x00 }, Package (0x04) { 0x000CFFFF, 0x00, \_SB.PCI0.FNC0.LNKD, 0x00 }, Package (0x04) { 0x0006FFFF, 0x00, \_SB.PCI0.FNC0.LNKH, 0x00 }, Package (0x04) { 0x0012FFFF, 0x00, \_SB.PCI0.FNC0.LNKA, 0x00 }, Package (0x04) { 0x0002FFFF, 0x00, \_SB.PCI0.FNC0.LNKG, 0x00 } }) Device (FNC0) { Name (_ADR, 0x00070000) OperationRegion (M153, PCI_Config, 0x00, 0xFF) Field (M153, ByteAcc, NoLock, Preserve) { Offset (0x44), IRQJ, 4, , 3, RSTC, 1, Offset (0x48), IRQA, 4, IRQB, 4, IRQC, 4, IRQD, 4, IRQE, 4, IRQF, 4, IRQI, 4, IRQH, 4, Offset (0x52), , 13, CUS1, 1, Offset (0x74), IRQG, 4, Offset (0x75), IRQK, 4, Offset (0x77), , 3, CSND, 1, , 1, CMDM, 1 } Device (LNKA) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x01) Method (_STA, 0, NotSerialized) { Return (STAL (\_SB.PCI0.FNC0.IRQA)) } Name (_PRS, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {3,4,5,6,7,10,11} }) Method (_CRS, 0, NotSerialized) { Return (CRSL (\_SB.PCI0.FNC0.IRQA)) } Method (_DIS, 0, NotSerialized) { Store (0x00, \_SB.PCI0.FNC0.IRQA) } Method (_SRS, 1, NotSerialized) { Name (IRQT, Package (0x10) { 0x00, 0x08, 0x00, 0x02, 0x04, 0x05, 0x07, 0x06, 0x00, 0x01, 0x03, 0x09, 0x0B, 0x00, 0x0D, 0x0F }) CreateWordField (Arg0, 0x01, IRQX) FindSetRightBit (IRQX, Local0) Decrement (Local0) Store (DerefOf (Index (IRQT, Local0)), Local1) Store (Local1, \_SB.PCI0.FNC0.IRQA) } } Device (LNKB) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x02) Method (_STA, 0, NotSerialized) { Return (STAL (\_SB.PCI0.FNC0.IRQB)) } Name (_PRS, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {3,4,5,6,7,10,11} }) Method (_CRS, 0, NotSerialized) { Return (CRSL (\_SB.PCI0.FNC0.IRQB)) } Method (_DIS, 0, NotSerialized) { Store (0x00, \_SB.PCI0.FNC0.IRQB) } Method (_SRS, 1, NotSerialized) { Name (IRQT, Package (0x10) { 0x00, 0x08, 0x00, 0x02, 0x04, 0x05, 0x07, 0x06, 0x00, 0x01, 0x03, 0x09, 0x0B, 0x00, 0x0D, 0x0F }) CreateWordField (Arg0, 0x01, IRQX) FindSetRightBit (IRQX, Local0) Decrement (Local0) Store (DerefOf (Index (IRQT, Local0)), Local1) Store (Local1, \_SB.PCI0.FNC0.IRQB) } } Device (LNKC) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x03) Method (_STA, 0, NotSerialized) { Return (STAL (\_SB.PCI0.FNC0.IRQC)) } Name (_PRS, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {3,4,5,6,7,10,11} }) Method (_CRS, 0, NotSerialized) { Return (CRSL (\_SB.PCI0.FNC0.IRQC)) } Method (_DIS, 0, NotSerialized) { Store (0x00, \_SB.PCI0.FNC0.IRQC) } Method (_SRS, 1, NotSerialized) { Name (IRQT, Package (0x10) { 0x00, 0x08, 0x00, 0x02, 0x04, 0x05, 0x07, 0x06, 0x00, 0x01, 0x03, 0x09, 0x0B, 0x00, 0x0D, 0x0F }) CreateWordField (Arg0, 0x01, IRQX) FindSetRightBit (IRQX, Local0) Decrement (Local0) Store (DerefOf (Index (IRQT, Local0)), Local1) Store (Local1, \_SB.PCI0.FNC0.IRQC) } } Device (LNKD) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x04) Method (_STA, 0, NotSerialized) { Return (STAL (\_SB.PCI0.FNC0.IRQD)) } Name (_PRS, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {3,4,5,6,7,10,11} }) Method (_CRS, 0, NotSerialized) { Return (CRSL (\_SB.PCI0.FNC0.IRQD)) } Method (_DIS, 0, NotSerialized) { Store (0x00, \_SB.PCI0.FNC0.IRQD) } Method (_SRS, 1, NotSerialized) { Name (IRQT, Package (0x10) { 0x00, 0x08, 0x00, 0x02, 0x04, 0x05, 0x07, 0x06, 0x00, 0x01, 0x03, 0x09, 0x0B, 0x00, 0x0D, 0x0F }) CreateWordField (Arg0, 0x01, IRQX) FindSetRightBit (IRQX, Local0) Decrement (Local0) Store (DerefOf (Index (IRQT, Local0)), Local1) Store (Local1, \_SB.PCI0.FNC0.IRQD) } } Device (LNKG) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x07) Method (_STA, 0, NotSerialized) { Return (STAL (\_SB.PCI0.FNC0.IRQG)) } Name (_PRS, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {3,4,5,6,7,10,11} }) Method (_CRS, 0, NotSerialized) { Return (CRSL (\_SB.PCI0.FNC0.IRQG)) } Method (_DIS, 0, NotSerialized) { Store (0x00, \_SB.PCI0.FNC0.IRQG) } Method (_SRS, 1, NotSerialized) { Name (IRQT, Package (0x10) { 0x00, 0x08, 0x00, 0x02, 0x04, 0x05, 0x07, 0x06, 0x00, 0x01, 0x03, 0x09, 0x0B, 0x00, 0x0D, 0x0F }) CreateWordField (Arg0, 0x01, IRQX) FindSetRightBit (IRQX, Local0) Decrement (Local0) Store (DerefOf (Index (IRQT, Local0)), Local1) Store (Local1, \_SB.PCI0.FNC0.IRQG) } } Device (LNKH) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x08) Method (_STA, 0, NotSerialized) { Return (STAL (\_SB.PCI0.FNC0.IRQH)) } Name (_PRS, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {3,4,5,6,7,10,11} }) Method (_CRS, 0, NotSerialized) { Return (CRSL (\_SB.PCI0.FNC0.IRQH)) } Method (_DIS, 0, NotSerialized) { Store (0x00, \_SB.PCI0.FNC0.IRQH) } Method (_SRS, 1, NotSerialized) { Name (IRQT, Package (0x10) { 0x00, 0x08, 0x00, 0x02, 0x04, 0x05, 0x07, 0x06, 0x00, 0x01, 0x03, 0x09, 0x0B, 0x00, 0x0D, 0x0F }) CreateWordField (Arg0, 0x01, IRQX) FindSetRightBit (IRQX, Local0) Decrement (Local0) Store (DerefOf (Index (IRQT, Local0)), Local1) Store (Local1, \_SB.PCI0.FNC0.IRQH) } } Device (DMAC) { Name (_HID, EisaId ("PNP0200")) Name (_STA, 0x0F) Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0000, 0x0000, 0x01, 0x10) IO (Decode16, 0x0081, 0x0081, 0x01, 0x03) IO (Decode16, 0x0087, 0x0087, 0x01, 0x01) IO (Decode16, 0x0089, 0x0089, 0x01, 0x03) IO (Decode16, 0x008F, 0x008F, 0x01, 0x01) IO (Decode16, 0x00C0, 0x00C0, 0x01, 0x20) DMA (Compatibility, NotBusMaster, Transfer8) {4} }) } Device (PIC) { Name (_HID, EisaId ("PNP0000")) Name (_STA, 0x0F) Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0020, 0x0020, 0x01, 0x02) IO (Decode16, 0x00A0, 0x00A0, 0x01, 0x02) IRQ (Edge, ActiveHigh, Exclusive) {2} }) } Device (PIT) { Name (_HID, EisaId ("PNP0100")) Name (_STA, 0x0F) Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0040, 0x0040, 0x01, 0x04) IRQ (Edge, ActiveHigh, Exclusive) {0} }) } Device (SPKR) { Name (_HID, EisaId ("PNP0800")) Name (_STA, 0x0F) Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0061, 0x0061, 0x01, 0x01) }) } Device (NDP) { Name (_HID, EisaId ("PNP0C04")) Name (_STA, 0x0F) Name (_CRS, ResourceTemplate () { IO (Decode16, 0x00F0, 0x00F0, 0x01, 0x10) IRQ (Edge, ActiveHigh, Shared) {13} }) } Device (KBC) { Name (_HID, EisaId ("PNP0303")) Method (_STA, 0, NotSerialized) { While (LEqual (\_SB.MEM.KBCR, 0x00)) {} Return (0x0F) } Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0060, 0x0060, 0x01, 0x01) IO (Decode16, 0x0064, 0x0064, 0x01, 0x01) IRQ (Edge, ActiveHigh, Exclusive) {1} }) } Device (PS2M) { Name (_HID, EisaId ("PNP0F13")) Method (_STA, 0, NotSerialized) { While (LEqual (\_SB.MEM.KBCR, 0x00)) {} Return (0x0F) } Name (_CRS, ResourceTemplate () { IRQ (Edge, ActiveHigh, Exclusive) {12} }) } Device (RTC) { Name (_HID, EisaId ("PNP0B00")) Name (_STA, 0x0F) Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0070, 0x0070, 0x01, 0x02) IRQ (Edge, ActiveHigh, Exclusive) {8} }) } Device (SYSR) { Name (_HID, EisaId ("PNP0C02")) Name (_STA, 0x0F) Name (_CRS, ResourceTemplate () { IO (Decode16, 0x002E, 0x002E, 0x01, 0x02) IO (Decode16, 0x0062, 0x0062, 0x01, 0x01) IO (Decode16, 0x0066, 0x0066, 0x01, 0x01) IO (Decode16, 0x0080, 0x0080, 0x01, 0x01) IO (Decode16, 0x0084, 0x0084, 0x01, 0x03) IO (Decode16, 0x0088, 0x0088, 0x01, 0x01) IO (Decode16, 0x008C, 0x008C, 0x01, 0x03) IO (Decode16, 0x0092, 0x0092, 0x01, 0x01) IO (Decode16, 0x00B0, 0x00B0, 0x01, 0x04) IO (Decode16, 0x00E0, 0x00E0, 0x01, 0x10) IO (Decode16, 0x0370, 0x0370, 0x01, 0x02) IO (Decode16, 0x040B, 0x040B, 0x01, 0x01) IO (Decode16, 0x0480, 0x0480, 0x01, 0x10) IO (Decode16, 0x04D0, 0x04D0, 0x01, 0x02) IO (Decode16, 0x04D6, 0x04D6, 0x01, 0x01) IO (Decode16, 0x06C0, 0x06C0, 0x01, 0x40) IO (Decode16, 0xE000, 0xE000, 0x01, 0x80) IO (Decode16, 0xE080, 0xE080, 0x01, 0x80) IO (Decode16, 0xE400, 0xE400, 0x01, 0x80) IO (Decode16, 0xE480, 0xE480, 0x01, 0x80) IO (Decode16, 0xE800, 0xE800, 0x01, 0x80) IO (Decode16, 0xE880, 0xE880, 0x01, 0x80) IO (Decode16, 0xEC00, 0xEC00, 0x01, 0x80) IO (Decode16, 0xEC80, 0xEC80, 0x01, 0x80) IO (Decode16, 0xEE00, 0xEE00, 0x01, 0x42) IO (Decode16, 0xEE90, 0xEE90, 0x01, 0x10) IO (Decode16, 0xEEAC, 0xEEAC, 0x01, 0x01) IO (Decode16, 0xEF00, 0xEF00, 0x01, 0x40) IO (Decode16, 0xEF40, 0xEF40, 0x01, 0x20) }) OperationRegion (SRG1, SystemIO, 0xB1, 0x01) Field (SRG1, ByteAcc, NoLock, Preserve) { TRP4, 8 } } Device (COM) { Name (_HID, EisaId ("PNP0501")) Method (_STA, 0, NotSerialized) { Return (STA (0x0E)) } Method (_CRS, 0, NotSerialized) { Return (CRS (0x0E)) } Method (_PRS, 0, NotSerialized) { Return (PRS (0x0E)) } Method (_SRS, 1, NotSerialized) { SRS (0x0E, Arg0) } Method (_DIS, 0, NotSerialized) { DIS (0x0E) } Method (_PS0, 0, NotSerialized) { PS0 (0x0E) } Method (_PS3, 0, NotSerialized) { PS3 (0x0E) } Method (_PSC, 0, NotSerialized) { Return (PSC (0x0E)) } Name (_PRW, Package (0x02) { 0x08, 0x03 }) Method (_PSW, 1, NotSerialized) { Store (Arg0, \_SB.MEM.WED0) } } Device (FSIR) { Name (_HID, EisaId ("SMCF010")) Method (_STA, 0, NotSerialized) { Return (STA (0x0F)) } Method (_CRS, 0, NotSerialized) { Return (CRS (0x0F)) } Method (_PRS, 0, NotSerialized) { Return (PRS (0x0F)) } Method (_SRS, 1, NotSerialized) { SRS (0x0F, Arg0) } Method (_DIS, 0, NotSerialized) { DIS (0x0F) } } Device (PRT) { Name (_HID, EisaId ("PNP0401")) Method (_STA, 0, NotSerialized) { Return (STA (0x10)) } Method (_CRS, 0, NotSerialized) { Return (CRS (0x10)) } Method (_PRS, 0, NotSerialized) { Return (PRS (0x10)) } Method (_SRS, 1, NotSerialized) { SRS (0x10, Arg0) } Method (_DIS, 0, NotSerialized) { DIS (0x10) } } Device (PRT1) { Name (_HID, EisaId ("PNP0400")) Method (_STA, 0, NotSerialized) { Return (STA (0x12)) } Method (_CRS, 0, NotSerialized) { Return (CRS (0x12)) } Method (_PRS, 0, NotSerialized) { Return (PRS (0x12)) } Method (_SRS, 1, NotSerialized) { SRS (0x12, Arg0) } Method (_DIS, 0, NotSerialized) { DIS (0x12) } } Device (PCC0) { Name (_HID, EisaId ("PNP0E00")) Name (_UID, 0x01) Method (_STA, 0, NotSerialized) { Return (STA (0x13)) } Method (_CRS, 0, NotSerialized) { Return (CRS (0x13)) } Method (_PRS, 0, NotSerialized) { Return (PRS (0x13)) } Method (_SRS, 1, NotSerialized) { SRS (0x13, Arg0) } Method (_DIS, 0, NotSerialized) { DIS (0x13) } Name (_PRW, Package (0x02) { 0x09, 0x03 }) Method (_PSW, 1, NotSerialized) { Store (Arg0, \_SB.MEM.WED2) } Device (PCS0) { Name (_ADR, 0x00) Name (_SUN, 0x00) } Device (PCS1) { Name (_ADR, 0x01) Name (_SUN, 0x01) } } Device (ATA) { Name (_HID, EisaId ("PNP0600")) Name (_UID, 0x03) Method (_STA, 0, NotSerialized) { Return (STA (0x16)) } Method (_CRS, 0, NotSerialized) { Return (CRS (0x16)) } Method (_PRS, 0, NotSerialized) { Return (PRS (0x16)) } Method (_SRS, 1, NotSerialized) { SRS (0x16, Arg0) } Method (_DIS, 0, NotSerialized) { DIS (0x16) } } } Device (FNC1) { Name (_ADR, 0x00040000) OperationRegion (IDEC, PCI_Config, 0x00, 0xFF) Field (IDEC, ByteAcc, NoLock, Preserve) { Offset (0x54), FTHP, 4, Offset (0x55), FTHS, 4, Offset (0x56), PUDS, 4, Offset (0x57), SUDS, 4, Offset (0x58), PAST, 3, Offset (0x59), PCRC, 4, PCAC, 3, Offset (0x5A), PDRC, 4, PDAC, 3, Offset (0x5C), SAST, 3, Offset (0x5D), SCRC, 4, SCAC, 3, Offset (0x5E), SDRC, 4, SDAC, 3 } Device (IDE0) { Name (_ADR, 0x00) Method (_STA, 0, NotSerialized) { Return (0x0F) } Method (_PS0, 0, NotSerialized) { While (LEqual (\_SB.MEM.ID0R, 0x00)) {} Store (0x00, \_SB.MEM.PPSC) } Method (_PS3, 0, NotSerialized) { While (LEqual (\_SB.MEM.ID0R, 0x00)) {} Store (0x01, \_SB.MEM.PPSC) } Method (_PSC, 0, NotSerialized) { While (LEqual (\_SB.MEM.ID0R, 0x00)) {} If (\_SB.MEM.PPSC) { Return (0x03) } Else { Return (0x00) } } Method (_STM, 3, NotSerialized) { While (LEqual (\_SB.MEM.ID0R, 0x00)) {} Store (0x01, \_SB.MEM.HTM0) CreateDWordField (Arg0, 0x00, PPIO) CreateDWordField (Arg0, 0x04, PDMA) CreateDWordField (Arg0, 0x10, PFLG) Store (PPIO, Local0) Store (0x03, Local1) Store (0x0A, Local2) Store (0x00, Local3) Store (0x08, Local4) Store (0x08, Local5) If (LNot (LGreater (Local0, 0x78))) { Store (0x02, Local1) Store (0x01, Local2) Store (0x03, Local3) Store (0x01, Local4) Store (0x03, Local5) } Else { If (LNot (LGreater (Local0, 0xB4))) { Store (0x02, Local1) Store (0x03, Local2) Store (0x03, Local3) Store (0x03, Local4) Store (0x03, Local5) } Else { If (LNot (LGreater (Local0, 0xF0))) { Store (0x02, Local1) Store (0x01, Local2) Store (0x00, Local3) Store (0x04, Local4) Store (0x04, Local5) } Else { If (LNot (LGreater (Local0, 0x017F))) { Store (0x02, Local1) Store (0x03, Local2) Store (0x00, Local3) Store (0x08, Local4) Store (0x05, Local5) } } } } If (LNot (LEqual (Local0, 0xFFFFFFFF))) { Store (Local1, \_SB.PCI0.FNC1.PAST) Store (Local2, \_SB.PCI0.FNC1.PCRC) Store (Local3, \_SB.PCI0.FNC1.PCAC) Store (Local4, \_SB.PCI0.FNC1.PDRC) Store (Local5, \_SB.PCI0.FNC1.PDAC) Store (0x05, \_SB.PCI0.FNC1.FTHP) } Store (PDMA, Local0) Store (PFLG, Local1) And (Local1, 0x01, Local1) ShiftLeft (Local1, 0x03, Local1) If (Local1) { Store (0x04, Local2) If (LNot (LGreater (Local0, 0x1E))) { Store (0x00, Local2) } Else { If (LNot (LGreater (Local0, 0x2D))) { Store (0x01, Local2) } Else { If (LNot (LGreater (Local0, 0x3C))) { Store (0x02, Local2) } Else { If (LNot (LGreater (Local0, 0x5A))) { Store (0x03, Local2) } } } } } Else { Store (0x07, Local2) If (LNot (LGreater (Local0, 0x4B))) { Store (0x05, Local2) } Else { If (LNot (LGreater (Local0, 0x5A))) { Store (0x06, Local2) } } } If (LNot (LEqual (Local0, 0xFFFFFFFF))) { Or (Local1, Local2, Local1) Store (Local1, \_SB.PCI0.FNC1.PUDS) Store (0x01, \_SB.PCI0.FNC1.FTHP) } } Method (_GTM, 0, NotSerialized) { While (LEqual (\_SB.MEM.ID0R, 0x00)) {} Store (0x01, \_SB.MEM.HTM0) Store (\_SB.PCI0.FNC1.PCRC, Local0) Store (\_SB.PCI0.FNC1.PCAC, Local1) ShiftLeft (Local1, 0x04, Local1) Or (Local0, Local1, Local0) Store (0x0258, Local2) If (LEqual (Local0, 0x31)) { Store (0x78, Local2) } Else { If (LEqual (Local0, 0x33)) { Store (0xB4, Local2) } Else { If (LEqual (Local0, 0x01)) { Store (0xF0, Local2) } Else { If (LEqual (Local0, 0x03)) { Store (0x017F, Local2) } } } } Store (\_SB.PCI0.FNC1.PUDS, Local0) And (Local0, 0x08, Local1) And (Local0, 0x07, Local0) Store (0x02, Local4) If (Local1) { Store (0x03, Local4) Store (0x78, Local3) If (LEqual (Local0, 0x00)) { Store (0x1E, Local3) } Else { If (LEqual (Local0, 0x01)) { Store (0x2D, Local3) } Else { If (LEqual (Local0, 0x02)) { Store (0x3C, Local3) } Else { If (LEqual (Local0, 0x03)) { Store (0x5A, Local3) } } } } } Else { Store (0x69, Local3) If (LEqual (Local0, 0x05)) { Store (0x4B, Local3) } Else { If (LEqual (Local0, 0x06)) { Store (0x5A, Local3) } } } Name (BUFF, Buffer (0x14) {}) CreateDWordField (BUFF, 0x00, PIO1) CreateDWordField (BUFF, 0x04, DMA1) CreateDWordField (BUFF, 0x08, PIO2) CreateDWordField (BUFF, 0x0C, DMA2) CreateDWordField (BUFF, 0x10, FLGS) Store (Local2, PIO1) Store (Local3, DMA1) Store (0xFFFFFFFF, PIO2) Store (0xFFFFFFFF, DMA2) Store (Local4, FLGS) Return (BUFF) } Device (HD_0) { Name (_ADR, 0x00) Method (_GTF, 0, NotSerialized) { While (LEqual (\_SB.MEM.ID0R, 0x00)) {} Store (0x01, \_SB.MEM.HTM0) Name (BUFF, Buffer (0x0E) { 0x03, 0x0C, 0x00, 0x00, 0x00, 0x00, 0xEF, 0x03, 0x23, 0x00, 0x00, 0x00, 0x00, 0xEF }) CreateByteField (BUFF, 0x01, PIOM) CreateByteField (BUFF, 0x08, DMAM) Store (\_SB.PCI0.FNC1.PCRC, Local0) Store (\_SB.PCI0.FNC1.PCAC, Local1) ShiftLeft (Local1, 0x04, Local1) Or (Local0, Local1, Local0) Store (0x08, Local1) If (LEqual (Local0, 0x31)) { Store (0x0C, Local1) } Else { If (LEqual (Local0, 0x33)) { Store (0x0B, Local1) } Else { If (LEqual (Local0, 0x01)) { Store (0x0A, Local1) } Else { If (LEqual (Local0, 0x03)) { Store (0x09, Local1) } } } } Store (\_SB.PCI0.FNC1.PUDS, Local0) And (Local0, 0x08, Local2) And (Local0, 0x07, Local0) If (Local2) { Store (0x40, Local2) If (LEqual (Local0, 0x00)) { Store (0x44, Local2) } Else { If (LEqual (Local0, 0x01)) { Store (0x43, Local2) } Else { If (LEqual (Local0, 0x02)) { Store (0x42, Local2) } Else { If (LEqual (Local0, 0x03)) { Store (0x41, Local2) } } } } } Else { Store (0x20, Local2) If (LEqual (Local0, 0x05)) { Store (0x22, Local2) } Else { If (LEqual (Local0, 0x06)) { Store (0x21, Local2) } } } Store (Local1, PIOM) Store (Local2, DMAM) Return (BUFF) } } } Device (IDE1) { Name (_ADR, 0x01) Method (_PS0, 0, NotSerialized) { While (LEqual (\_SB.MEM.ID1R, 0x00)) {} SMBR (0xFE00, 0x14, 0x00, 0x00, 0xB2) And (\_SB.MEM.OECX, 0x02, Local0) If (Local0) { Store (0x00, \_SB.MEM.SPSC) Store (0x01, \_SB.MEM.IESI) Store (0x02, \_SB.MEM.IEDI) SMBR (0xFE00, 0x23, 0x20, 0x00, 0xB2) If (\_SB.MEM.OEDX) { Store (0x01, \_SB.MEM.IESI) Store (0x02, \_SB.MEM.IEDI) SMBR (0xFF00, 0x23, 0x20, 0x00, 0xB2) Store (0x01, \_SB.MEM.OECX) While (\_SB.MEM.OECX) { Store (0x01, \_SB.MEM.IESI) Store (0x02, \_SB.MEM.IEDI) SMBR (0xFE00, 0x23, 0x20, 0x00, 0xB2) } } } } Method (_PS3, 0, NotSerialized) { While (LEqual (\_SB.MEM.ID1R, 0x00)) {} SMBR (0xFE00, 0x14, 0x00, 0x00, 0xB2) And (\_SB.MEM.OECX, 0x02, Local0) If (Local0) { Store (0x01, \_SB.MEM.SPSC) Store (0x01, \_SB.MEM.IESI) Store (0x02, \_SB.MEM.IEDI) SMBR (0xFE00, 0x23, 0x20, 0x00, 0xB2) If (LNot (LEqual (\_SB.MEM.OEDX, 0x03))) { Store (0x01, \_SB.MEM.IESI) Store (0x02, \_SB.MEM.IEDI) SMBR (0xFF00, 0x23, 0x20, 0x03, 0xB2) Store (0x01, \_SB.MEM.OECX) While (\_SB.MEM.OECX) { Store (0x01, \_SB.MEM.IESI) Store (0x02, \_SB.MEM.IEDI) SMBR (0xFE00, 0x23, 0x20, 0x00, 0xB2) } } } } Method (_PSC, 0, NotSerialized) { While (LEqual (\_SB.MEM.ID1R, 0x00)) {} SMBR (0xFE00, 0x14, 0x00, 0x00, 0xB2) And (\_SB.MEM.OECX, 0x02, Local0) If (Local0) { If (\_SB.MEM.SPSC) { Return (0x03) } Else { Return (0x00) } } Else { Return (0x00) } } Method (_STM, 3, NotSerialized) { While (LEqual (\_SB.MEM.ID1R, 0x00)) {} Store (0x01, \_SB.MEM.HTM1) CreateDWordField (Arg0, 0x00, PPIO) CreateDWordField (Arg0, 0x04, PDMA) CreateDWordField (Arg0, 0x10, PFLG) Store (PPIO, Local0) Store (0x03, Local1) Store (0x0A, Local2) Store (0x00, Local3) Store (0x08, Local4) Store (0x08, Local5) If (LNot (LGreater (Local0, 0x78))) { Store (0x02, Local1) Store (0x01, Local2) Store (0x03, Local3) Store (0x01, Local4) Store (0x03, Local5) } Else { If (LNot (LGreater (Local0, 0xB4))) { Store (0x02, Local1) Store (0x03, Local2) Store (0x03, Local3) Store (0x03, Local4) Store (0x03, Local5) } Else { If (LNot (LGreater (Local0, 0xF0))) { Store (0x02, Local1) Store (0x01, Local2) Store (0x00, Local3) Store (0x04, Local4) Store (0x04, Local5) } Else { If (LNot (LGreater (Local0, 0x017F))) { Store (0x02, Local1) Store (0x03, Local2) Store (0x00, Local3) Store (0x08, Local4) Store (0x05, Local5) } } } } If (LNot (LEqual (Local0, 0xFFFFFFFF))) { Store (Local1, \_SB.PCI0.FNC1.SAST) Store (Local2, \_SB.PCI0.FNC1.SCRC) Store (Local3, \_SB.PCI0.FNC1.SCAC) Store (Local4, \_SB.PCI0.FNC1.SDRC) Store (Local5, \_SB.PCI0.FNC1.SDAC) Store (0x05, \_SB.PCI0.FNC1.FTHS) } Store (PDMA, Local0) Store (PFLG, Local1) And (Local1, 0x01, Local1) ShiftLeft (Local1, 0x03, Local1) If (Local1) { Store (0x04, Local2) If (LNot (LGreater (Local0, 0x1E))) { Store (0x00, Local2) } Else { If (LNot (LGreater (Local0, 0x2D))) { Store (0x01, Local2) } Else { If (LNot (LGreater (Local0, 0x3C))) { Store (0x02, Local2) } Else { If (LNot (LGreater (Local0, 0x5A))) { Store (0x03, Local2) } } } } } Else { Store (0x07, Local2) If (LNot (LGreater (Local0, 0x4B))) { Store (0x05, Local2) } Else { If (LNot (LGreater (Local0, 0x5A))) { Store (0x06, Local2) } } } If (LNot (LEqual (Local0, 0xFFFFFFFF))) { Or (Local1, Local2, Local1) Store (Local1, \_SB.PCI0.FNC1.SUDS) Store (0x01, \_SB.PCI0.FNC1.FTHS) } } Method (_GTM, 0, NotSerialized) { While (LEqual (\_SB.MEM.ID1R, 0x00)) {} Store (0x01, \_SB.MEM.HTM1) Store (\_SB.PCI0.FNC1.SCRC, Local0) Store (\_SB.PCI0.FNC1.SCAC, Local1) ShiftLeft (Local1, 0x04, Local1) Or (Local0, Local1, Local0) Store (0x0258, Local2) If (LEqual (Local0, 0x31)) { Store (0x78, Local2) } Else { If (LEqual (Local0, 0x33)) { Store (0xB4, Local2) } Else { If (LEqual (Local0, 0x01)) { Store (0xF0, Local2) } Else { If (LEqual (Local0, 0x03)) { Store (0x017F, Local2) } } } } Store (\_SB.PCI0.FNC1.SUDS, Local0) And (Local0, 0x08, Local1) And (Local0, 0x07, Local0) Store (0x02, Local4) If (Local1) { Store (0x03, Local4) Store (0x78, Local3) If (LEqual (Local0, 0x00)) { Store (0x1E, Local3) } Else { If (LEqual (Local0, 0x01)) { Store (0x2D, Local3) } Else { If (LEqual (Local0, 0x02)) { Store (0x3C, Local3) } Else { If (LEqual (Local0, 0x03)) { Store (0x5A, Local3) } } } } } Else { Store (0x69, Local3) If (LEqual (Local0, 0x05)) { Store (0x4B, Local3) } Else { If (LEqual (Local0, 0x06)) { Store (0x5A, Local3) } } } Name (BUFF, Buffer (0x14) {}) CreateDWordField (BUFF, 0x00, PIO1) CreateDWordField (BUFF, 0x04, DMA1) CreateDWordField (BUFF, 0x08, PIO2) CreateDWordField (BUFF, 0x0C, DMA2) CreateDWordField (BUFF, 0x10, FLGS) Store (Local2, PIO1) Store (Local3, DMA1) Store (0xFFFFFFFF, PIO2) Store (0xFFFFFFFF, DMA2) Store (Local4, FLGS) Return (BUFF) } Device (HD_1) { Name (_ADR, 0x00) Method (_STA, 0, NotSerialized) { While (LEqual (\_SB.MEM.ID1R, 0x00)) {} SMBR (0xFE00, 0x14, 0x00, 0x00, 0xB2) And (\_SB.MEM.OECX, 0x02, Local0) If (Local0) { Return (0x0F) } Else { Return (0x00) } } Method (_EJ0, 1, NotSerialized) { SMBR (0xFE00, 0x14, 0x00, 0x00, 0xB2) And (\_SB.MEM.OECX, 0x02, Local0) If (Local0) { Store (0x01, \_SB.MEM.IESI) Store (0x02, \_SB.MEM.IEDI) SMBR (0xFE00, 0x23, 0x20, 0x00, 0xB2) If (LNot (LEqual (\_SB.MEM.OEDX, 0x03))) { Store (0x01, \_SB.MEM.IESI) Store (0x02, \_SB.MEM.IEDI) SMBR (0xFF00, 0x23, 0x20, 0x03, 0xB2) Store (0x01, \_SB.MEM.OECX) While (\_SB.MEM.OECX) { Store (0x01, \_SB.MEM.IESI) Store (0x02, \_SB.MEM.IEDI) SMBR (0xFE00, 0x23, 0x20, 0x00, 0xB2) } } } } Method (_GTF, 0, NotSerialized) { While (LEqual (\_SB.MEM.ID1R, 0x00)) {} Store (0x01, \_SB.MEM.HTM1) Name (BUFF, Buffer (0x0E) { 0x03, 0x0C, 0x00, 0x00, 0x00, 0x00, 0xEF, 0x03, 0x23, 0x00, 0x00, 0x00, 0x00, 0xEF }) CreateByteField (BUFF, 0x01, PIOM) CreateByteField (BUFF, 0x08, DMAM) Store (\_SB.PCI0.FNC1.SCRC, Local0) Store (\_SB.PCI0.FNC1.SCAC, Local1) ShiftLeft (Local1, 0x04, Local1) Or (Local0, Local1, Local0) Store (0x08, Local1) If (LEqual (Local0, 0x31)) { Store (0x0C, Local1) } Else { If (LEqual (Local0, 0x33)) { Store (0x0B, Local1) } Else { If (LEqual (Local0, 0x01)) { Store (0x0A, Local1) } Else { If (LEqual (Local0, 0x03)) { Store (0x09, Local1) } } } } Store (\_SB.PCI0.FNC1.SUDS, Local0) And (Local0, 0x08, Local2) And (Local0, 0x07, Local0) If (Local2) { Store (0x40, Local2) If (LEqual (Local0, 0x00)) { Store (0x44, Local2) } Else { If (LEqual (Local0, 0x01)) { Store (0x43, Local2) } Else { If (LEqual (Local0, 0x02)) { Store (0x42, Local2) } Else { If (LEqual (Local0, 0x03)) { Store (0x41, Local2) } } } } } Else { Store (0x20, Local2) If (LEqual (Local0, 0x05)) { Store (0x22, Local2) } Else { If (LEqual (Local0, 0x06)) { Store (0x21, Local2) } } } Store (Local1, PIOM) Store (Local2, DMAM) Return (BUFF) } } } } Device (USB1) { Name (_ADR, 0x00020000) OperationRegion (USP1, PCI_Config, 0x00, 0xFF) Field (USP1, ByteAcc, NoLock, Preserve) { UVI1, 16, UDI1, 16, Offset (0x09), UPI1, 8, USC1, 8, UBC1, 8 } Name (_PRW, Package (0x02) { 0x09, 0x03 }) Method (_PSW, 1, NotSerialized) { If (Arg0) { Store (0x01, \_SB.MEM.WED3) } Else { Store (0x00, \_SB.MEM.WED3) } } Device (RHB0) { Name (_ADR, 0x00) Device (PT01) { Name (_ADR, 0x01) Name (_EJD, "\\_SB_.PCI0.DOCK") } Device (PT02) { Name (_ADR, 0x02) Name (_EJD, "\\_SB_.PCI0.DOCK") } } } Device (ASND) { Name (_ADR, 0x00060000) Method (_PS0, 0, NotSerialized) { While (LEqual (\_SB.MEM.ACLR, 0x00)) {} Store (0x00, \_SB.MEM.PSND) } Method (_PS3, 0, NotSerialized) { Store (0x01, \_SB.MEM.PSND) } Method (_PSC, 0, NotSerialized) { If (\_SB.MEM.PSND) { Return (0x03) } Else { Return (0x00) } } Name (_PRW, Package (0x02) { 0x09, 0x03 }) Method (_PSW, 1, NotSerialized) { If (Arg0) { Store (0x01, \_SB.MEM.WED1) } Else { Store (0x00, \_SB.MEM.WED1) } } } Device (IEEE) { Name (_ADR, 0x000C0000) OperationRegion (IEEC, PCI_Config, 0x00, 0xFF) Field (IEEC, ByteAcc, NoLock, Preserve) { IVI0, 16, IDI0, 16, Offset (0x09), IPI0, 8, ISC0, 8, IBC0, 8 } Name (_EJD, "\\_SB_.PCI0.DOCK") } Device (VIY0) { Name (_ADR, 0x00110000) Name (_SUN, 0x00) Name (_PRW, Package (0x02) { 0x09, 0x03 }) Method (_PSW, 1, NotSerialized) { If (Arg0) { Store (0x01, \_SB.MEM.VWE0) } Else { Store (0x00, \_SB.MEM.VWE0) } } } Device (VIY1) { Name (_ADR, 0x00110001) Name (_SUN, 0x01) Name (_PRW, Package (0x02) { 0x09, 0x03 }) Method (_PSW, 1, NotSerialized) { If (Arg0) { Store (0x01, \_SB.MEM.VWE1) } Else { Store (0x00, \_SB.MEM.VWE1) } } } Device (LAN) { Name (_ADR, 0x000A0000) OperationRegion (PLAN, PCI_Config, 0x00, 0xFF) Field (PLAN, ByteAcc, NoLock, Preserve) { PLVI, 16, Offset (0xE1), PMES, 8 } Name (_PRW, Package (0x02) { 0x09, 0x04 }) Method (_PSW, 1, NotSerialized) { If (Arg0) { Store (0x01, \_SB.MEM.WED4) } Else { Store (0x00, \_SB.MEM.WED4) } } } Device (MPC0) { Name (_ADR, 0x00100000) OperationRegion (MPF0, PCI_Config, 0x00, 0xFF) Field (MPF0, ByteAcc, NoLock, Preserve) { Offset (0x0A), MCC0, 16 } } Device (MPC1) { Name (_ADR, 0x00100001) OperationRegion (MPF1, PCI_Config, 0x00, 0xFF) Field (MPF1, ByteAcc, NoLock, Preserve) { Offset (0x0A), MCC1, 16 } } Device (SDC) { Name (_ADR, 0x00120000) } Device (DOCK) { Name (_HID, EisaId ("PNP0A05")) Method (_STA, 0, NotSerialized) { SMBR (0x0136FA00, 0x05F3, 0x00, 0x00, 0xB2) And (\_SB.MEM.OEAX, 0xFF00, Local0) If (LOr (LAnd (LEqual (Local0, 0x00), LEqual (\_SB.MEM.OECX, 0x00)), LNot (LEqual (Local0, 0x00)))) { Store (0x00, \_SB.MEM.RDID) Store (0x00, \_SB.MEM.RDSN) Store (0x05, \_SB.PCI0.FNC0.SYSR.TRP4) Store (\_SB.MEM.RDID, \_SB.MEM.DLID) Store (\_SB.MEM.RDSN, \_SB.MEM.DSRN) If (\_SB.MEM.PAR1) { Return (0x00) } Else { If (LEqual (0x1B51F351, \_SB.MEM.RDID)) { Return (0x0F) } Else { Return (0x00) } } } Else { Return (0x00) } } Method (_BDN, 0, NotSerialized) { Store (0x00, \_SB.MEM.RDID) Store (0x05, \_SB.PCI0.FNC0.SYSR.TRP4) Return (\_SB.MEM.RDID) } Method (_UID, 0, NotSerialized) { Store (0x00, \_SB.MEM.RDSN) Store (0x05, \_SB.PCI0.FNC0.SYSR.TRP4) Return (\_SB.MEM.RDSN) } Method (XDCK, 1, NotSerialized) { If (Arg0) { Store (0x05, \_SB.PCI0.FNC0.SYSR.TRP4) If (\_SB.MEM.PAR1) { Store (0x41, \_SB.PCI0.FNC0.SYSR.TRP4) Reset (\_SB.PCI0.DKSQ) Wait (\_SB.PCI0.DKSQ, 0x0BB8) Notify (\_SB.PCI0.PCI1.VGA, 0x80) Return (One) } Return (Zero) } Else { Return (One) } } Method (_EJ0, 1, NotSerialized) { If (LOr (\_SB.MEM.BES1, \_SB.MEM.BES2)) { Store (0x40, \_SB.PCI0.FNC0.SYSR.TRP4) Reset (\_SB.PCI0.DKSQ) Wait (\_SB.PCI0.DKSQ, 0x1388) Notify (\_SB.PCI0.PCI1.VGA, 0x80) } } PowerResource (PDOC, 0x01, 0x0000) { Method (_STA, 0, NotSerialized) { Return (\_SB.MEM.DSPW) } Method (_ON, 0, NotSerialized) { Store (0x01, \_SB.MEM.DSPW) } Method (_OFF, 0, NotSerialized) { Store (0x00, \_SB.MEM.DSPW) } } Name (_PR0, Package (0x01) { \_SB.PCI0.DOCK.PDOC }) Name (_PR1, Package (0x01) { \_SB.PCI0.DOCK.PDOC }) } Event (DKSQ) Device (PCI1) { Name (_ADR, 0x00010000) Name (_PRT, Package (0x01) { Package (0x04) { 0xFFFF, 0x00, \_SB.PCI0.FNC0.LNKC, 0x00 } }) Device (VGA) { Name (_ADR, 0x00) Method (_PS0, 0, Serialized) { While (LEqual (\_SB.MEM.VGAR, 0x00)) {} Store (0x01, \_SB.MEM.IESI) Store (0x00, \_SB.MEM.IEDI) SMBR (0xFE00, 0x23, 0x0100, 0x00, 0xB2) If (LEqual (\_SB.MEM.OEAX, 0x00)) { Store (0x01, \_SB.MEM.IESI) Store (0x00, \_SB.MEM.IEDI) SMBR (0xFF00, 0x23, 0x0100, 0x00, 0xB2) WPSX (0x0100, 0x01, 0x00, 0x00) Store (0x00, \_SB.MEM.VGAF) } } Method (_PS3, 0, Serialized) { While (LEqual (\_SB.MEM.VGAR, 0x00)) {} Store (0x01, \_SB.MEM.IESI) Store (0x00, \_SB.MEM.IEDI) SMBR (0xFE00, 0x23, 0x0100, 0x00, 0xB2) If (LEqual (\_SB.MEM.OEAX, 0x00)) { Store (0x01, \_SB.MEM.IESI) Store (0x00, \_SB.MEM.IEDI) SMBR (0xFF00, 0x23, 0x0100, 0x03, 0xB2) WPSX (0x0100, 0x01, 0x00, 0x03) Store (0x01, \_SB.MEM.VGAF) } } Method (_PSC, 0, NotSerialized) { While (LEqual (\_SB.MEM.VGAR, 0x00)) {} Store (0x01, \_SB.MEM.IESI) Store (0x00, \_SB.MEM.IEDI) SMBR (0xFE00, 0x23, 0x0100, 0x00, 0xB2) Return (\_SB.MEM.OEDX) } Method (_DOS, 1, NotSerialized) { If (LEqual (Arg0, 0x00)) { Store (0x01, \_SB.MEM.DCST) Store (0x00, \_SB.MEM.DOS2) } Else { If (LEqual (Arg0, 0x01)) { Store (0x00, \_SB.MEM.DCST) Store (0x01, \_SB.MEM.DOS2) } Else { If (LEqual (Arg0, 0x02)) { Store (0x01, \_SB.MEM.DCST) Store (0x01, \_SB.MEM.DOS2) } } } } Method (_DOD, 0, NotSerialized) { Name (BUFF, Package (0x02) { 0x0110, 0x0100 }) Return (BUFF) } Method (_ROM, 2, NotSerialized) { Add (Arg0, 0x000C0000, Local0) ShiftLeft (Arg1, 0x03, Local1) Name (BUFF, Buffer (Arg1) {}) Scope (\) { OperationRegion (VROM, SystemMemory, Local0, Local1) Field (VROM, ByteAcc, NoLock, Preserve) { ROMI, 65536 } } Store (\ROMI, BUFF) Return (BUFF) } Device (LCD) { Name (_ADR, 0x0110) Method (_DCS, 0, NotSerialized) { If (\_SB.MEM.CTLA) { Return (0x0F) } Else { Return (0x0D) } } Method (_DDC, 1, NotSerialized) { If (LEqual (Arg0, 0x01)) { Store (0x80, Local0) } Else { If (LEqual (Arg0, 0x02)) { Store (0x0100, Local0) } Else { Return (Zero) } } Store (0x00, \_SB.MEM.PRES) ShiftLeft (Arg0, 0x08, Local1) Or (Local1, 0x01, Local1) Name (BUFF, Buffer (Local0) {}) SMBR (0xFE00, 0x37, Local1, 0x000EF000, 0xB2) And (Local1, 0xFF00, Local1) Store (0x0100, \_SB.MEM.OECX) While (\_SB.MEM.OECX) { SMBR (0xFE00, 0x37, Local1, 0x00, 0xB2) } Store (\_SB.MEM.FSDP, Local0) Or (Local0, 0x22, \_SB.MEM.FSDP) Subtract (\_SB.MEM.FSDP, Local0, Local0) Subtract (\_SB.MEM.EDCK, Local0, \_SB.MEM.EDCK) Store (\_SB.MEM.PRES, BUFF) Return (BUFF) } Method (_DGS, 0, NotSerialized) { If (\_SB.MEM.NXLA) { Return (One) } Else { Return (Zero) } } Method (_DSS, 1, NotSerialized) { Store (Arg0, Local0) And (Local0, 0x01, Local1) If (Local1) { Store (0x01, \_SB.MEM.NXLA) } Else { Store (0x00, \_SB.MEM.NXLA) } And (Local0, 0x80000000, Local1) If (Local1) { Store (0x0100, Local1) If (\_SB.MEM.NXLA) { Or (0x01, Local1, Local1) } If (\_SB.MEM.NXCA) { Or (0x02, Local1, Local1) } If (\_SB.MEM.NXTA) { Or (0x04, Local1, Local1) } If (\_SB.MEM.NXDA) { Or (0x08, Local1, Local1) } SMBR (0xFF00, 0x1C, Local1, 0x00, 0xB2) And (\_SB.MEM.OEAX, 0xFF00, Local1) If (LEqual (Local1, 0x00)) { Store (0x80, Local1) While (LEqual (Local1, 0x80)) { SMBR (0xFE00, 0x1C, 0x00, 0x00, 0xB2) And (\_SB.MEM.OECX, 0x80, Local1) } If (\_SB.MEM.CTLA) { If (LEqual (\_SB.MEM.LCDS, 0x00)) { SMBR (0xFF00, 0x02, 0x01, 0x00, 0xB2) Store (0x01, \_SB.MEM.OEDX) While (\_SB.MEM.OEDX) { SMBR (0xFE00, 0x02, 0x00, 0x00, 0xB2) } } } } } } Method (_BCL, 0, NotSerialized) { Name (BUFF, Package (0x05) { 0x64, 0x28, 0x00, 0x28, 0x64 }) If (\_SB.MEM.HPSU) { Store (\_SB.MEM.BCLA, Index (BUFF, 0x00)) Store (\_SB.MEM.BCLD, Index (BUFF, 0x01)) } Return (BUFF) } Method (_BCM, 1, NotSerialized) { If (LEqual (\_SB.MEM.HPSU, 0x00)) { Multiply (Arg0, 0xFFFF, Local0) Divide (Local0, 0x64, , Local0) SMBR (0xFF00, 0x2A, Local0, 0x00, 0xB2) } } Method (_PS0, 0, Serialized) { Store (0x00, \_SB.MEM.LCDS) If (LEqual (\_SB.MEM.RPPC, 0x01)) { Notify (\_PR.CPU0, 0x80) Store (0x00, \_SB.MEM.RPPC) } } Method (_PS3, 0, Serialized) { Store (0x03, \_SB.MEM.LCDS) } Method (_PSC, 0, Serialized) { Return (\_SB.MEM.LCDS) } } Device (CRT) { Name (_ADR, 0x0100) Method (_DCS, 0, NotSerialized) { If (\_SB.MEM.CTCA) { Return (0x0F) } Else { Return (0x0D) } } Method (_DDC, 1, NotSerialized) { If (LEqual (Arg0, 0x01)) { Store (0x80, Local0) } Else { If (LEqual (Arg0, 0x02)) { Store (0x0100, Local0) } Else { Return (Zero) } } Store (0x00, \_SB.MEM.PRES) ShiftLeft (Arg0, 0x08, Local1) Or (Local1, 0x02, Local1) Name (BUFF, Buffer (Local0) {}) SMBR (0xFE00, 0x37, Local1, 0x000EF000, 0xB2) And (Local1, 0xFF00, Local1) Store (0x0100, \_SB.MEM.OECX) While (\_SB.MEM.OECX) { SMBR (0xFE00, 0x37, Local1, 0x00, 0xB2) } Store (\_SB.MEM.PRES, BUFF) Return (BUFF) } Method (_DGS, 0, NotSerialized) { If (\_SB.MEM.NXCA) { Return (One) } Else { Return (Zero) } } Method (_DSS, 1, NotSerialized) { Store (Arg0, Local0) And (Local0, 0x01, Local1) If (Local1) { Store (0x01, \_SB.MEM.NXCA) } Else { Store (0x00, \_SB.MEM.NXCA) } And (Local0, 0x80000000, Local1) If (Local1) { Store (0x0100, Local1) If (\_SB.MEM.NXLA) { Or (0x01, Local1, Local1) } If (\_SB.MEM.NXCA) { Or (0x02, Local1, Local1) } If (\_SB.MEM.NXTA) { Or (0x04, Local1, Local1) } If (\_SB.MEM.NXDA) { Or (0x08, Local1, Local1) } SMBR (0xFF00, 0x1C, Local1, 0x00, 0xB2) And (\_SB.MEM.OEAX, 0xFF00, Local1) If (LEqual (Local1, 0x00)) { Store (0x80, Local1) While (LEqual (Local1, 0x80)) { SMBR (0xFE00, 0x1C, 0x00, 0x00, 0xB2) And (\_SB.MEM.OECX, 0x80, Local1) } If (\_SB.MEM.CTLA) { If (LEqual (\_SB.MEM.LCDS, 0x00)) { SMBR (0xFF00, 0x02, 0x01, 0x00, 0xB2) Store (0x01, \_SB.MEM.OEDX) While (\_SB.MEM.OEDX) { SMBR (0xFE00, 0x02, 0x00, 0x00, 0xB2) } } } } } } Method (_PS0, 0, Serialized) { Store (0x00, \_SB.MEM.CRTS) If (LEqual (\_SB.MEM.RPPC, 0x01)) { Notify (\_PR.CPU0, 0x80) Store (0x00, \_SB.MEM.RPPC) } } Method (_PS3, 0, Serialized) { Store (0x03, \_SB.MEM.CRTS) } Method (_PSC, 0, Serialized) { Return (\_SB.MEM.CRTS) } } } } Method (_INI, 0, NotSerialized) { Store (\_SB.MEM.BES1, \_SB.MEM.BT1F) Store (\_SB.MEM.BES2, \_SB.MEM.BT2F) Store (0x00, \_SB.MEM.DSPW) Store (0x00, \_SB.MEM.VGAF) Store (0x00, \_SB.MEM.VWE0) Store (0x00, \_SB.MEM.VWE1) Store (0x00, \_SB.MEM.PPSC) Store (0x00, \_SB.MEM.SPSC) Store (0x00, Local0) If (CMPS (\_OS, "Microsoft Windows NT")) { Store (0x03, Local0) If (CondRefOf (\_OSI, Local1)) { If (\_OSI ("Windows 2001")) { Store (0x04, Local0) } } } Else { If (CMPS (\_OS, "Microsoft Windows")) { Store (0x01, Local0) } If (CMPS (\_OS, "Microsoft WindowsME:Millennium Edition")) { Store (0x02, Local0) } } Store (Local0, \_SB.MEM.OSID) DIS (0x14) While (LEqual (\_SB.MEM.BTRE, 0x00)) {} SMBR (0xFF00, 0x1E, 0x01, 0x00, 0xB2) Store (0x01, \_SB.MEM.PAR1) Store (0x60, \_SB.PCI0.FNC0.SYSR.TRP4) } } Device (BT) { Name (_HID, "TOS6205") Method (_STA, 0, NotSerialized) { If (\_SB.MEM.BTMD) { Return (0x0F) } Else { Return (0x00) } } Name (_PRW, Package (0x02) { 0x09, 0x04 }) Method (BTST, 0, NotSerialized) { Store (0x00, \_SB.MEM.OESI) SMBR (0xFE00, 0x4D, 0x01, 0xC600, 0xB2) Store (0x01, Local0) While (Local0) { SMBR (0xFE00, 0x4D, 0x0101, 0xC600, 0xB2) Store (\_SB.MEM.OESI, Local2) And (\_SB.MEM.OEAX, 0xFF00, Local1) If (Local1) { And (\_SB.MEM.OEAX, 0xFF, Local1) If (LNot (LEqual (Local1, 0x20))) { Store (0x00, Local2) Store (0x00, Local0) } } Else { Store (0x00, Local0) } } And (Local2, 0x02, Local0) ShiftLeft (Local0, 0x06, Local0) And (Local2, 0x04, Local1) ShiftLeft (Local1, 0x04, Local1) Or (Local0, Local1, Local0) And (Local2, 0x10, Local3) ShiftRight (Local3, 0x04, Local3) Or (Local0, Local3, Local0) Return (Local0) } Method (AUSB, 0, NotSerialized) { If (\_SB.MEM.BTMD) { Store (0x00, \_SB.MEM.IEDI) Store (0x03, \_SB.MEM.IESI) SMBR (0xFF00, 0x4D, 0x01, 0x7C00, 0xB2) Store (0x01, Local0) While (Local0) { SMBR (0xFF00, 0x4D, 0x0101, 0x7C00, 0xB2) And (\_SB.MEM.OEAX, 0xFF00, Local1) If (Local1) { And (\_SB.MEM.OEAX, 0xFF, Local1) If (LNot (LEqual (Local1, 0x20))) { Store (0x00, Local0) } } Else { Store (0x00, Local0) } } } } Method (DUSB, 0, NotSerialized) { If (\_SB.MEM.BTMD) { Store (0x00, \_SB.MEM.IEDI) Store (0x04, \_SB.MEM.IESI) SMBR (0xFF00, 0x4D, 0x01, 0x7C00, 0xB2) Store (0x01, Local0) While (Local0) { SMBR (0xFF00, 0x4D, 0x0101, 0x7C00, 0xB2) And (\_SB.MEM.OEAX, 0xFF00, Local1) If (Local1) { And (\_SB.MEM.OEAX, 0xFF, Local1) If (LNot (LEqual (Local1, 0x20))) { Store (0x00, Local0) } } Else { Store (0x00, Local0) } } } } Method (BTPO, 0, NotSerialized) { If (\_SB.MEM.BTMD) { Store (0x00, \_SB.MEM.IEDI) Store (0x01, \_SB.MEM.IESI) SMBR (0xFF00, 0x4D, 0x01, 0x7C00, 0xB2) Store (0x01, Local0) While (Local0) { SMBR (0xFF00, 0x4D, 0x0101, 0x7C00, 0xB2) And (\_SB.MEM.OEAX, 0xFF00, Local1) If (Local1) { And (\_SB.MEM.OEAX, 0xFF, Local1) If (LNot (LEqual (Local1, 0x20))) { Store (0x00, Local0) } } Else { Store (0x00, Local0) } } } } Method (BTPF, 0, NotSerialized) { If (\_SB.MEM.BTMD) { Store (0x00, \_SB.MEM.IEDI) Store (0x02, \_SB.MEM.IESI) SMBR (0xFF00, 0x4D, 0x01, 0x7C00, 0xB2) Store (0x01, Local0) While (Local0) { SMBR (0xFF00, 0x4D, 0x0101, 0x7C00, 0xB2) And (\_SB.MEM.OEAX, 0xFF00, Local1) If (Local1) { And (\_SB.MEM.OEAX, 0xFF, Local1) If (LNot (LEqual (Local1, 0x20))) { Store (0x00, Local0) } } Else { Store (0x00, Local0) } } } } } Device (LID) { Name (_HID, EisaId ("PNP0C0D")) Method (_LID, 0, NotSerialized) { Return (\_SB.MEM.LIDS) } Name (_PRW, Package (0x02) { 0x25, 0x04 }) Method (_PSW, 1, NotSerialized) { If (LEqual (Arg0, 0x00)) { Store (0x00, \_SB.MEM.EWLD) } Else { Store (0x01, \_SB.MEM.EWLD) } } } Device (BAT1) { Name (_HID, EisaId ("PNP0C0A")) Name (_UID, 0x01) Name (_PCL, Package (0x01) { \_SB }) Method (_STA, 0, NotSerialized) { If (\_SB.MEM.BES1) { Return (0x1F) } Else { Return (0x0F) } } Method (_BIF, 0, NotSerialized) { Name (BUFF, Package (0x0D) {}) Store (0x00, Index (BUFF, 0x00)) Store (\_SB.MEM.BDV1, Local2) Multiply (\_SB.MEM.BDC1, Local2, Local0) Divide (Local0, 0x03E8, Local1, Local0) Store (Local0, Index (BUFF, 0x01)) Multiply (\_SB.MEM.BLF1, Local2, Local0) Divide (Local0, 0x03E8, Local1, Local0) Store (Local0, Index (BUFF, 0x02)) Store (\_SB.MEM.BTC1, Index (BUFF, 0x03)) Store (\_SB.MEM.BDV1, Index (BUFF, 0x04)) Multiply (\_SB.MEM.BCW1, Local2, Local0) Divide (Local0, 0x03E8, Local1, Local0) Store (Local0, Index (BUFF, 0x05)) Multiply (\_SB.MEM.BCL1, Local2, Local0) Divide (Local0, 0x03E8, Local1, Local0) Store (Local0, Index (BUFF, 0x06)) Multiply (\_SB.MEM.BG11, Local2, Local0) Divide (Local0, 0x03E8, Local1, Local0) Store (Local0, Index (BUFF, 0x07)) Multiply (\_SB.MEM.BG21, Local2, Local0) Divide (Local0, 0x03E8, Local1, Local0) Store (Local0, Index (BUFF, 0x08)) Store (\_SB.MEM.BMN1, Index (BUFF, 0x09)) Store (\_SB.MEM.BSN1, Index (BUFF, 0x0A)) Store (\_SB.MEM.BTP1, Index (BUFF, 0x0B)) Store (\_SB.MEM.BOI1, Index (BUFF, 0x0C)) Return (BUFF) } Method (_BST, 0, NotSerialized) { If (\_SB.MEM.BES2) { And (\_SB.MEM.BST1, 0x03, Local0) And (\_SB.MEM.BST2, 0x03, Local1) If (LOr (Local0, Local1)) { Multiply (\_SB.MEM.BPR1, \_SB.MEM.BDV1, Local0) Divide (Local0, 0x07D0, Local1, Local0) } Else { Store (0x00, Local0) } } Else { If (LAnd (\_SB.MEM.BST1, 0x03)) { Multiply (\_SB.MEM.BPR1, \_SB.MEM.BDV1, Local0) Divide (Local0, 0x03E8, Local1, Local0) } Else { Store (0x00, Local0) } } Name (BUFF, Package (0x04) {}) Store (\_SB.MEM.BST1, Index (BUFF, 0x00)) Store (Local0, Index (BUFF, 0x01)) Multiply (\_SB.MEM.BRC1, \_SB.MEM.BDV1, Local0) Divide (Local0, 0x03E8, Local1, Local0) Store (Local0, Index (BUFF, 0x02)) Store (\_SB.MEM.BPV1, Index (BUFF, 0x03)) Return (BUFF) } Method (_BTP, 1, NotSerialized) { Store (0x01, \_SB.MEM.PAR1) Store (Arg0, \_SB.MEM.PAR2) Store (0x61, \_SB.PCI0.FNC0.SYSR.TRP4) } } Device (BAT2) { Name (_HID, EisaId ("PNP0C0A")) Name (_UID, 0x02) Name (_PCL, Package (0x01) { \_SB }) Method (_STA, 0, NotSerialized) { If (\_SB.MEM.BES2) { Return (0x1F) } Else { Return (0x0F) } } Method (_BIF, 0, NotSerialized) { Name (BUFF, Package (0x0D) {}) Store (0x00, Index (BUFF, 0x00)) Store (\_SB.MEM.BDV2, Local2) Multiply (\_SB.MEM.BDC2, Local2, Local0) Divide (Local0, 0x03E8, Local1, Local0) Store (Local0, Index (BUFF, 0x01)) Multiply (\_SB.MEM.BLF2, Local2, Local0) Divide (Local0, 0x03E8, Local1, Local0) Store (Local0, Index (BUFF, 0x02)) Store (\_SB.MEM.BTC2, Index (BUFF, 0x03)) Store (\_SB.MEM.BDV2, Index (BUFF, 0x04)) Multiply (\_SB.MEM.BCW2, Local2, Local0) Divide (Local0, 0x03E8, Local1, Local0) Store (Local0, Index (BUFF, 0x05)) Multiply (\_SB.MEM.BCL2, Local2, Local0) Divide (Local0, 0x03E8, Local1, Local0) Store (Local0, Index (BUFF, 0x06)) Multiply (\_SB.MEM.BG12, Local2, Local0) Divide (Local0, 0x03E8, Local1, Local0) Store (Local0, Index (BUFF, 0x07)) Multiply (\_SB.MEM.BG22, Local2, Local0) Divide (Local0, 0x03E8, Local1, Local0) Store (Local0, Index (BUFF, 0x08)) Store (\_SB.MEM.BMN2, Index (BUFF, 0x09)) Store (\_SB.MEM.BSN2, Index (BUFF, 0x0A)) Store (\_SB.MEM.BTP2, Index (BUFF, 0x0B)) Store (\_SB.MEM.BOI2, Index (BUFF, 0x0C)) Return (BUFF) } Method (_BST, 0, NotSerialized) { If (\_SB.MEM.BES1) { And (\_SB.MEM.BST1, 0x03, Local0) And (\_SB.MEM.BST2, 0x03, Local1) If (LOr (Local0, Local1)) { Multiply (\_SB.MEM.BPR2, \_SB.MEM.BDV2, Local0) Divide (Local0, 0x07D0, Local1, Local0) } Else { Store (0x00, Local0) } } Else { If (LAnd (\_SB.MEM.BST2, 0x03)) { Multiply (\_SB.MEM.BPR2, \_SB.MEM.BDV2, Local0) Divide (Local0, 0x03E8, Local1, Local0) } Else { Store (0x00, Local0) } } Name (BUFF, Package (0x04) {}) Store (\_SB.MEM.BST2, Index (BUFF, 0x00)) Store (Local0, Index (BUFF, 0x01)) Multiply (\_SB.MEM.BRC2, \_SB.MEM.BDV2, Local0) Divide (Local0, 0x03E8, Local1, Local0) Store (Local0, Index (BUFF, 0x02)) Store (\_SB.MEM.BPV2, Index (BUFF, 0x03)) Return (BUFF) } Method (_BTP, 1, NotSerialized) { Store (0x02, \_SB.MEM.PAR1) Store (Arg0, \_SB.MEM.PAR2) Store (0x61, \_SB.PCI0.FNC0.SYSR.TRP4) } } Device (ADP1) { Name (_HID, "ACPI0003") Name (_PCL, Package (0x03) { \_SB, \_SB.BAT1, \_SB.BAT2 }) Name (_STA, 0x0F) Method (_PSR, 0, NotSerialized) { Return (\_SB.MEM.ACST) } } Device (VALD) { Name (_HID, EisaId ("TOS6200")) Name (_DDN, "VALD") Name (_STA, 0x0B) Method (ENAB, 0, NotSerialized) { Store (0x01, \_SB.MEM.VALF) SMBR (0xFF00, 0x16, 0x01, 0x00, 0xB2) } Method (INFO, 0, NotSerialized) { Store (0x00, \_SB.MEM.OECX) SMBR (0xFE00, 0x16, 0x00, 0x00, 0xB2) If (LNot (LEqual (\_SB.MEM.OEAX, 0x00))) { Store (0x00, \_SB.MEM.OECX) } Return (\_SB.MEM.OECX) } Method (GHCI, 6, Serialized) { CreateDWordField (Arg0, 0x00, REAX) CreateWordField (Arg1, 0x00, R_BX) And (REAX, 0xFF00, Local0) If (LEqual (Local0, 0xFE00)) { If (LEqual (R_BX, 0xC000)) { Return (G000 (Local0, R_BX, Arg2, Arg3, Arg4, Arg5)) } If (LEqual (R_BX, 0xC800)) { Return (G800 (Local0, R_BX, Arg2, Arg3, Arg4, Arg5)) } If (LEqual (R_BX, 0xC801)) { Return (G801 (Local0, R_BX, Arg2, Arg3, Arg4, Arg5)) } } If (LEqual (Local0, 0xFF00)) { If (LEqual (R_BX, 0xC000)) { Return (G000 (Local0, R_BX, Arg2, Arg3, Arg4, Arg5)) } If (LEqual (R_BX, 0xC801)) { Return (G801 (Local0, R_BX, Arg2, Arg3, Arg4, Arg5)) } } Return (GCH0 (Arg0, Arg1, Arg2, Arg3, Arg4, Arg5)) } Method (GCH0, 6, NotSerialized) { Store (Arg4, \_SB.MEM.IESI) Store (Arg5, \_SB.MEM.IEDI) SMBR (Arg0, Arg1, Arg2, Arg3, 0xB2) Name (BUFF, Package (0x06) {}) Store (\_SB.MEM.OEAX, Index (BUFF, 0x00)) Store (\_SB.MEM.OEBX, Index (BUFF, 0x01)) Store (\_SB.MEM.OECX, Index (BUFF, 0x02)) Store (\_SB.MEM.OEDX, Index (BUFF, 0x03)) Store (\_SB.MEM.OESI, Index (BUFF, 0x04)) Store (\_SB.MEM.OEDI, Index (BUFF, 0x05)) Return (BUFF) } Method (G000, 6, NotSerialized) { Name (BUFF, Package (0x06) {}) CreateDWordField (Arg2, 0x00, RECX) CreateDWordField (Arg3, 0x00, REDX) CreateDWordField (Arg4, 0x00, RESI) CreateDWordField (Arg5, 0x00, REDI) CreateByteField (Arg2, 0x00, R_CL) Store (0x00, Index (BUFF, 0x00)) Store (Arg1, Index (BUFF, 0x01)) Store (RECX, Index (BUFF, 0x02)) Store (REDX, Index (BUFF, 0x03)) Store (RESI, Index (BUFF, 0x04)) Store (REDI, Index (BUFF, 0x05)) If (\_SB.MEM.GCVS) { If (LEqual (Arg0, 0xFE00)) { If (LEqual (R_CL, 0x00)) { Store (\_SB.MEM.TNVS, Local0) Store (Local0, Index (BUFF, 0x02)) } Else { If (LAnd (LNot (LLess (R_CL, 0x01)), LNot (LGreater (R_CL, 0x04)))) { Store (R_CL, Local0) Or (Local0, 0x3000, Local0) SMBR (0xFA00, Local0, 0x00, 0x00, 0xB2) Store (\_SB.MEM.OECX, Index (BUFF, 0x02)) Store (\_SB.MEM.OEDX, Index (BUFF, 0x03)) } Else { If (LEqual (R_CL, 0x05)) { Store (0x21, Index (BUFF, 0x02)) } Else { Store (0x8300, Index (BUFF, 0x00)) } } } } Else { CreateWordField (Arg3, 0x00, R_DX) If (LEqual (R_CL, 0x00)) { If (LEqual (R_DX, 0x00)) { Store (0x00, \_SB.MEM.TNVS) } Else { Store (0x01, \_SB.MEM.TNVS) } } Else { If (LEqual (R_CL, 0x01)) { Store (R_CL, Local0) Or (Local0, 0x3080, Local0) SMBR (0xFA00, Local0, R_DX, 0x00, 0xB2) } Else { If (LEqual (R_CL, 0x02)) { FindSetRightBit (R_DX, Local0) Store (Local0, \_SB.MEM.NXDD) If (LLess (\_SB.MEM.OSID, 0x03)) { Or (Local0, 0x0100, Local0) SMBR (0xFF00, 0x1C, Local0, 0x00, 0xB2) And (\_SB.MEM.OEAX, 0xFF00, Local0) If (LEqual (Local0, 0x00)) { Store (0x80, Local0) While (LEqual (Local0, 0x80)) { SMBR (0xFE00, 0x1C, 0x00, 0x00, 0xB2) And (\_SB.MEM.OECX, 0x80, Local0) } If (\_SB.MEM.CTLA) { If (LEqual (\_SB.MEM.LCDS, 0x00)) { SMBR (0xFF00, 0x02, 0x01, 0x00, 0xB2) Store (0x01, \_SB.MEM.OEDX) While (\_SB.MEM.OEDX) { SMBR (0xFE00, 0x02, 0x00, 0x00, 0xB2) } } } } } Else { Notify (\_SB.PCI0.PCI1.VGA, 0x80) } } Else { Store (0x8300, Index (BUFF, 0x00)) } } } } } Else { Store (0x8000, Index (BUFF, 0x00)) } Return (BUFF) } Method (G800, 6, NotSerialized) { Store (\_SB.MEM.OSPC, Local0) Name (BUFF, Package (0x06) {}) CreateDWordField (Arg3, 0x00, REDX) CreateDWordField (Arg4, 0x00, RESI) CreateDWordField (Arg5, 0x00, REDI) Store (0x00, Index (BUFF, 0x00)) Store (Arg1, Index (BUFF, 0x01)) Store (Local0, Index (BUFF, 0x02)) Store (REDX, Index (BUFF, 0x03)) Store (RESI, Index (BUFF, 0x04)) Store (REDI, Index (BUFF, 0x05)) Return (BUFF) } Method (G801, 6, NotSerialized) { CreateDWordField (Arg2, 0x00, RECX) CreateDWordField (Arg3, 0x00, REDX) CreateDWordField (Arg4, 0x00, RESI) CreateDWordField (Arg5, 0x00, REDI) Store (0x8300, Local0) Store (RECX, Local1) If (LEqual (REDX, 0x01)) { Store (0x00, Local0) If (LEqual (Arg0, 0xFE00)) { Store (\_SB.MEM.PULD, Local1) Store (\_SB.MEM.PULA, Local2) ShiftLeft (Local2, 0x08, Local2) Or (Local1, Local2, Local1) } Else { And (Local1, 0xFF, Local2) ShiftRight (Local1, 0x08, Local3) Store (Local2, \_SB.MEM.PULD) Store (Local3, \_SB.MEM.PULA) } } If (LEqual (REDX, 0x02)) { Store (0x00, Local0) If (LEqual (Arg0, 0xFE00)) { Store (\_SB.MEM.BCLD, Local1) Store (\_SB.MEM.BCLA, Local2) ShiftLeft (Local2, 0x08, Local2) Or (Local1, Local2, Local1) } Else { And (Local1, 0xFF, Local2) ShiftRight (Local1, 0x08, Local3) Store (Local2, \_SB.MEM.BCLD) Store (Local3, \_SB.MEM.BCLA) } } Name (BUFF, Package (0x06) {}) Store (Local0, Index (BUFF, 0x00)) Store (Arg1, Index (BUFF, 0x01)) Store (Local1, Index (BUFF, 0x02)) Store (REDX, Index (BUFF, 0x03)) Store (RESI, Index (BUFF, 0x04)) Store (REDI, Index (BUFF, 0x05)) Return (BUFF) } } Device (VALG) { Name (_HID, EisaId ("TOS6202")) Name (_DDN, "VALGeneral") Name (_STA, 0x0B) Method (VCID, 0, NotSerialized) { Store (0x00, \_SB.MEM.RDID) Store (0x05, \_SB.PCI0.FNC0.SYSR.TRP4) Return (\_SB.MEM.RDID) } Method (VUID, 0, NotSerialized) { Store (0x00, \_SB.MEM.RDSN) Store (0x05, \_SB.PCI0.FNC0.SYSR.TRP4) Return (\_SB.MEM.RDSN) } Method (VDCK, 1, NotSerialized) { If (Arg0) { Store (0x05, \_SB.PCI0.FNC0.SYSR.TRP4) If (\_SB.MEM.PAR1) { Store (0x41, \_SB.PCI0.FNC0.SYSR.TRP4) Reset (\_SB.PCI0.DKSQ) Wait (\_SB.PCI0.DKSQ, 0x0BB8) Notify (\_SB.PCI0.PCI1.VGA, 0x80) Return (One) } Return (Zero) } Else { Return (One) } } Method (VEJ0, 1, NotSerialized) { If (LOr (\_SB.MEM.BES1, \_SB.MEM.BES2)) { Store (0x40, \_SB.PCI0.FNC0.SYSR.TRP4) Reset (\_SB.PCI0.DKSQ) Wait (\_SB.PCI0.DKSQ, 0x1388) Notify (\_SB.PCI0.PCI1.VGA, 0x80) } } Method (DLSZ, 0, NotSerialized) { Return (0x03) } Method (DLIB, 0, NotSerialized) { Name (BUFF, Buffer (0x30) { 0x80, 0x00, 0x00, 0x00, 0x01, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x80, 0x00, 0x00, 0x00, 0x02, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x80, 0x00, 0x00, 0x00, 0x02, 0x60, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }) Store (\_SB.PCI0.USB1.UVI1, Local0) CreateByteField (BUFF, 0x08, VI1L) CreateByteField (BUFF, 0x09, VI1H) CreateByteField (BUFF, 0x18, VI2L) CreateByteField (BUFF, 0x19, VI2H) ShiftRight (Local0, 0x08, Local1) And (Local0, 0xFF, Local0) Store (Local0, VI1L) Store (Local1, VI1H) Store (Local0, VI2L) Store (Local1, VI2H) Store (\_SB.PCI0.USB1.UDI1, Local0) CreateByteField (BUFF, 0x0A, DI1L) CreateByteField (BUFF, 0x0B, DI1H) CreateByteField (BUFF, 0x1A, DI2L) CreateByteField (BUFF, 0x1B, DI2H) ShiftRight (Local0, 0x08, Local1) And (Local0, 0xFF, Local0) Store (Local0, DI1L) Store (Local1, DI1H) Store (Local0, DI2L) Store (Local1, DI2H) Store (\_SB.PCI0.USB1.UPI1, Local0) CreateByteField (BUFF, 0x01, PIC1) CreateByteField (BUFF, 0x11, PIC2) Store (Local0, PIC1) Store (Local0, PIC2) Store (\_SB.PCI0.USB1.USC1, Local0) CreateByteField (BUFF, 0x02, SCC1) CreateByteField (BUFF, 0x12, SCC2) Store (Local0, SCC1) Store (Local0, SCC2) Store (\_SB.PCI0.USB1.UBC1, Local0) CreateByteField (BUFF, 0x03, BCC1) CreateByteField (BUFF, 0x13, BCC2) Store (Local0, BCC1) Store (Local0, BCC2) Store (\_SB.PCI0.IEEE.IVI0, Local0) CreateByteField (BUFF, 0x28, VI3L) CreateByteField (BUFF, 0x29, VI3H) ShiftRight (Local0, 0x08, Local1) And (Local0, 0xFF, Local0) Store (Local0, VI3L) Store (Local1, VI3H) Store (\_SB.PCI0.IEEE.IDI0, Local0) CreateByteField (BUFF, 0x2A, DI3L) CreateByteField (BUFF, 0x2B, DI3H) ShiftRight (Local0, 0x08, Local1) And (Local0, 0xFF, Local0) Store (Local0, DI3L) Store (Local1, DI3H) Store (\_SB.PCI0.IEEE.IPI0, Local0) CreateByteField (BUFF, 0x21, PIC3) Store (Local0, PIC3) Store (\_SB.PCI0.IEEE.ISC0, Local0) CreateByteField (BUFF, 0x22, SCC3) Store (Local0, SCC3) Store (\_SB.PCI0.IEEE.IBC0, Local0) CreateByteField (BUFF, 0x23, BCC3) Store (Local0, BCC3) Return (BUFF) } Method (VNTF, 1, NotSerialized) { And (Arg0, 0xFFFF, Local0) ShiftRight (Arg0, 0x10, Local1) If (LEqual (Local1, 0x01)) { Notify (\_PR.CPU0, Local0) } } Method (EHSS, 0, NotSerialized) { Name (BUFF, Buffer (0x20) { 0x07, 0x00, 0x00, 0x00, 0x5F, 0x00, 0x00, 0x00, 0x32, 0x00, 0x00, 0x00, 0x05, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0xE8, 0x03, 0x00, 0x00, 0x3C, 0x00, 0x00, 0x00, 0x05, 0x00, 0x00, 0x00 }) If (LNot (LEqual (\_SB.MEM.MSP0, 0x00))) { CreateWordField (BUFF, 0x00, INF0) CreateDWordField (BUFF, 0x04, SSP0) CreateDWordField (BUFF, 0x08, SSP1) CreateDWordField (BUFF, 0x0C, SSCH) CreateDWordField (BUFF, 0x10, SSCL) CreateDWordField (BUFF, 0x14, SSSI) CreateDWordField (BUFF, 0x18, SSS0) CreateDWordField (BUFF, 0x1C, SSR0) Divide (SizeOf (BUFF), 0x04, Local1, Local0) Decrement (Local0) Store (Local0, INF0) Store (\_SB.MEM.MSP0, SSP0) Store (\_SB.MEM.MSP1, SSP1) Store (\_SB.MEM.MSC0, SSCH) Store (\_SB.MEM.MSC1, SSCL) Store (\_SB.MEM.MSSI, SSSI) Store (\_SB.MEM.MSSS, SSS0) Store (\_SB.MEM.MSSR, SSR0) } Return (BUFF) } } } Scope (\_TZ) { PowerResource (PFAN, 0x00, 0x0000) { Method (_STA, 0, NotSerialized) { SMBR (0xFA00, 0x2201, 0x00, 0x00, 0xB2) If (\_SB.MEM.OECX) { Return (One) } Else { Return (0x00) } } Method (_ON, 0, Serialized) { SMBR (0xFA00, 0x2200, 0xFF, 0x00, 0xB2) } Method (_OFF, 0, Serialized) { SMBR (0xFA00, 0x2200, 0x00, 0x00, 0xB2) } } Device (FAN) { Name (_HID, EisaId ("PNP0C0B")) Name (_PR0, Package (0x01) { \_TZ.PFAN }) } ThermalZone (THRM) { Method (_TMP, 0, NotSerialized) { If (LNot (LGreater (\_SB.MEM.TMP1, 0x0B4C))) { Store (0x0B4C, \_SB.MEM.AST1) Return (0x0B4C) } Else { Store (\_SB.MEM.TMP1, \_SB.MEM.AST1) Return (\_SB.MEM.TMP1) } } Method (_AC0, 0, NotSerialized) { Return (\_SB.MEM.AC01) } Method (_AC1, 0, NotSerialized) { Return (\_SB.MEM.AC11) } Name (_AL0, Package (0x01) { \_TZ.FAN }) Name (_AL1, Package (0x01) { \_TZ.FAN }) Method (_PSV, 0, NotSerialized) { Return (\_SB.MEM.PSV1) } Name (_PSL, Package (0x01) { \_PR.CPU0 }) Method (_CRT, 0, NotSerialized) { Return (\_SB.MEM.CRT1) } Name (_TC1, 0x09) Name (_TC2, 0x02) Name (_TSP, 0x0708) } } Scope (\_GPE) { Method (_L08, 0, Serialized) { If (\_SB.MEM.GP72) { Store (0x00, \_SB.MEM.GP72) Notify (\_SB.PCI0.FNC0.COM, 0x02) } } Method (_L09, 0, Serialized) { If (LNot (LEqual (\_SB.PCI0.LAN.PLVI, 0xFFFF))) { And (\_SB.PCI0.LAN.PMES, 0x80, Local0) If (LEqual (Local0, 0x80)) { Notify (\_SB.PCI0.LAN, 0x02) } } While (LOr (\_SB.MEM.GP73, LOr (\_SB.MEM.GP74, LOr (\_SB.MEM.GP75, LOr (\_SB.MEM.GP83, \_SB.MEM.BWUE))))) { If (\_SB.MEM.GP73) { Store (0x00, \_SB.MEM.GP73) Notify (\_SB.PCI0.ASND, 0x02) } If (\_SB.MEM.GP74) { Store (0x00, \_SB.MEM.GP74) Notify (\_SB.PCI0.FNC0.PCC0, 0x02) Notify (\_SB.PCI0.VIY0, 0x02) Notify (\_SB.PCI0.VIY1, 0x02) } If (\_SB.MEM.GP75) { Store (0x00, \_SB.MEM.GP75) Notify (\_SB.PCI0.USB1, 0x02) } If (\_SB.MEM.GP83) { Store (0x00, \_SB.MEM.GP83) Notify (\_SB.PCI0.LAN, 0x02) } If (\_SB.MEM.BWUE) { Store (0x00, \_SB.MEM.BWUE) Notify (\_SB.BT, 0x80) } } } Method (_L25, 0, Serialized) { Store (0xAF, \_SB.MEM.IEDI) SMBR (0xFF00, 0x0028B10B, 0x00, 0x00, 0xB2) While (LOr (\_SB.MEM.GP50, LOr (\_SB.MEM.GP51, LOr (\_SB.MEM.GP52, LOr (\_SB.MEM.GP53, LOr (\_SB.MEM.GP54, LOr (\_SB.MEM.GP60, LOr (\_SB.MEM.GP61, LOr (\_SB.MEM.GP62, LOr (\_SB.MEM.GP63, LOr (\_SB.MEM.GP64, LOr (\_SB.MEM.GP66, LOr (\_SB.MEM.GP70, LOr (\_SB.MEM.GP71, \_SB.MEM.BPFE)))))))))))))) { If (\_SB.MEM.GP50) { Store (0x00, \_SB.MEM.GP50) Notify (\_SB.ADP1, 0x80) Notify (\_PR.CPU0, 0x80) } If (\_SB.MEM.GP51) { Store (0x00, \_SB.MEM.GP51) If (LEqual (\_SB.MEM.BES2, \_SB.MEM.BT2F)) { Notify (\_SB.BAT2, 0x80) } Else { Store (\_SB.MEM.BES2, \_SB.MEM.BT2F) If (\_SB.MEM.BES2) { Notify (\_SB.BAT2, 0x00) } Else { Notify (\_SB.BAT2, 0x01) } } } If (\_SB.MEM.GP52) { Store (0x00, \_SB.MEM.GP52) If (LEqual (\_SB.MEM.BES1, \_SB.MEM.BT1F)) { Notify (\_SB.BAT1, 0x80) } Else { Store (\_SB.MEM.BES1, \_SB.MEM.BT1F) If (\_SB.MEM.BES1) { Notify (\_SB.BAT1, 0x00) } Else { Notify (\_SB.BAT1, 0x01) } } } If (\_SB.MEM.GP53) { Store (0x00, \_SB.MEM.GP53) If (LNot (LEqual (\_SB.MEM.TMP1, \_SB.MEM.AST1))) { Notify (\_TZ.THRM, 0x80) } } If (\_SB.MEM.GP54) { Store (0x00, \_SB.MEM.GP54) If (\_SB.MEM.LANA) { Store (0x00, \_SB.MEM.LANA) Notify (\_SB.PCI0.LAN, 0x01) } } If (\_SB.MEM.GP60) { Store (0x00, \_SB.MEM.GP60) SMBR (0x0136FA00, 0x05F3, 0x00, 0x00, 0xB2) And (\_SB.MEM.OEAX, 0xFF00, Local0) If (LOr (LAnd (LEqual (Local0, 0x00), LEqual (\_SB.MEM.OECX, 0x00)), LNot (LEqual (Local0, 0x00)))) { Notify (\_SB.PCI0.DOCK, 0x00) } Else { Notify (\_SB.VALG, 0x83) } Notify (\_PR.CPU0, 0x80) } If (\_SB.MEM.GP61) { Signal (\_SB.PCI0.DKSQ) Store (0x00, \_SB.MEM.GP61) SMBR (0x0136FA00, 0x05F3, 0x00, 0x00, 0xB2) And (\_SB.MEM.OEAX, 0xFF00, Local0) If (LOr (LAnd (LEqual (Local0, 0x00), LEqual (\_SB.MEM.OECX, 0x00)), LNot (LEqual (Local0, 0x00)))) { Notify (\_SB.PCI0.DOCK, 0x00) } Else { Notify (\_SB.VALG, 0x83) } Notify (\_PR.CPU0, 0x80) } If (\_SB.MEM.GP62) { Store (0x00, \_SB.MEM.GP62) SMBR (0x0136FA00, 0x05F3, 0x00, 0x00, 0xB2) And (\_SB.MEM.OEAX, 0xFF00, Local0) If (LOr (LAnd (LEqual (Local0, 0x00), LEqual (\_SB.MEM.OECX, 0x00)), LNot (LEqual (Local0, 0x00)))) { Notify (\_SB.PCI0.DOCK, 0x01) } Else { Notify (\_SB.VALG, 0x82) } } If (\_SB.MEM.GP63) { Store (0x00, \_SB.MEM.GP63) If (LEqual (\_SB.MEM.DCKF, 0x00)) { Store (0x01, \_SB.MEM.DCKF) SMBR (0x0136FA00, 0x05F3, 0x00, 0x00, 0xB2) And (\_SB.MEM.OEAX, 0xFF00, Local0) If (LOr (LAnd (LEqual (Local0, 0x00), LEqual (\_SB.MEM.OECX, 0x00)), LNot (LEqual (Local0, 0x00)))) { Notify (\_SB.PCI0.DOCK, 0x00) } Else { Notify (\_SB.VALG, 0x81) } } Else { Signal (\_SB.PCI0.DKSQ) Store (0x00, \_SB.MEM.DCKF) } Notify (\_PR.CPU0, 0x80) } If (\_SB.MEM.GP64) { Store (0x00, \_SB.MEM.GP64) If (\_SB.MEM.VALF) { Notify (\_SB.VALD, 0x80) } Else { If (\_SB.MEM.SBL0) { Store (0x00, \_SB.MEM.SBL0) SMBR (0xFE00, 0x14, 0x00, 0x00, 0xB2) Store (\_SB.MEM.OECX, \_SB.MEM.BDID) If (LNot (LEqual (\_SB.MEM.OECX, 0x00))) { If (LEqual (\_SB.MEM.OECX, 0x01)) {} Else { If (LEqual (\_SB.MEM.OECX, 0x04)) {} Else { Notify (\_SB.PCI0.FNC1.IDE1, 0x03) } } } } If (\_SB.MEM.SBL1) { Store (0x00, \_SB.MEM.SBL1) SMBR (0xFE00, 0x14, 0x00, 0x00, 0xB2) If (LNot (LEqual (\_SB.MEM.OECX, 0x00))) { If (LEqual (\_SB.MEM.OECX, 0x01)) {} Else { If (LEqual (\_SB.MEM.OECX, 0x04)) {} Else { Notify (\_SB.PCI0.FNC1.IDE1, 0x00) Sleep (0x64) Notify (\_SB.PCI0.FNC1.IDE1, 0x01) } } } } If (\_SB.MEM.SBL2) { Store (0x00, \_SB.MEM.SBL2) If (LNot (LEqual (\_SB.MEM.BDID, 0x00))) { If (LEqual (\_SB.MEM.BDID, 0x01)) {} Else { If (LEqual (\_SB.MEM.BDID, 0x04)) {} Else { Notify (\_SB.PCI0.FNC1.IDE1, 0x01) } } } } If (\_SB.MEM.SBL3) { Store (0x00, \_SB.MEM.SBL3) } } } If (\_SB.MEM.GP66) { Store (0x00, \_SB.MEM.GP66) SMBR (0xFE00, 0x14, 0x00, 0x00, 0xB2) If (LNot (LEqual (\_SB.MEM.OECX, 0x00))) { If (LEqual (\_SB.MEM.OECX, 0x01)) {} Else { If (LEqual (\_SB.MEM.OECX, 0x04)) { Notify (\_SB.BAT2, 0x00) } Else { Notify (\_SB.PCI0.FNC1.IDE1, 0x00) Sleep (0x64) Notify (\_SB.PCI0.FNC1.IDE1, 0x01) } } } } If (\_SB.MEM.GP70) { Store (0x00, \_SB.MEM.GP70) If (\_SB.MEM.VALF) { Notify (\_SB.VALD, 0x80) } If (LEqual (\_SB.MEM.HKCD, 0x3D)) { TRAP (\_SB.MEM.HKCD) } If (LEqual (\_SB.MEM.DOS2, 0x00)) { If (LEqual (\_SB.MEM.HKCD, 0x3F)) { If (LEqual (\_SB.MEM.TNVS, 0x00)) { Notify (\_SB.PCI0.PCI1.VGA, 0x80) } } } } If (\_SB.MEM.GP71) { Store (0x00, \_SB.MEM.GP71) Notify (\_SB.LID, 0x80) } If (\_SB.MEM.BPFE) { Store (0x00, \_SB.MEM.BPFE) Notify (\_SB.BT, 0x90) } } } } Method (_PTS, 1, NotSerialized) { If (LOr (LOr (\_SB.MEM.VWE0, \_SB.MEM.VWE1), \_SB.MEM.VWE2)) { Store (0x01, \_SB.MEM.WED2) } Else { Store (0x00, \_SB.MEM.WED2) } Store (\_SB.MEM.ACST, \_SB.MEM.ACBK) Store (0x01, \_SB.MEM.RPPC) If (LAnd (LNot (LLess (Arg0, 0x01)), LNot (LGreater (Arg0, 0x04)))) { Store (\_SB.MEM.EWLD, \_SB.MEM.PAR1) Store (0x60, \_SB.PCI0.FNC0.SYSR.TRP4) } And (Arg0, 0x07, Local0) Or (Local0, 0x2100, Local0) SMBR (0xFA00, Local0, 0x00, 0x00, 0xB2) } Method (_WAK, 1, NotSerialized) { And (Arg0, 0x07, Local0) Or (Local0, 0x2180, Local0) SMBR (0xFA00, Local0, 0x00, 0x00, 0xB2) Notify (\_SB.PCI0.FNC1.IDE1, 0x00) Store (0x00, \_SB.MEM.RDID) Store (0x00, \_SB.MEM.RDSN) Store (0x05, \_SB.PCI0.FNC0.SYSR.TRP4) If (LEqual (\_SB.MEM.PAR1, 0x00)) { If (LEqual (0x1B51F351, \_SB.MEM.RDID)) { If (LOr (LNot (LEqual (\_SB.MEM.RDID, \_SB.MEM.DLID)), LNot (LEqual (\_SB.MEM.RDSN, \_SB.MEM.DSRN)))) { SMBR (0x0136FA00, 0x05F3, 0x00, 0x00, 0xB2) And (\_SB.MEM.OEAX, 0xFF00, Local0) If (LOr (LAnd (LEqual (Local0, 0x00), LEqual (\_SB.MEM.OECX, 0x00)), LNot (LEqual (Local0, 0x00)))) { Notify (\_SB.PCI0.DOCK, 0x00) } Else { Notify (\_SB.VALG, 0x81) } } } } Else { If (\_SB.MEM.DLID) { SMBR (0x0136FA00, 0x05F3, 0x00, 0x00, 0xB2) And (\_SB.MEM.OEAX, 0xFF00, Local0) If (LOr (LAnd (LEqual (Local0, 0x00), LEqual (\_SB.MEM.OECX, 0x00)), LNot (LEqual (Local0, 0x00)))) { Notify (\_SB.PCI0.DOCK, 0x01) } Else { Notify (\_SB.VALG, 0x83) } } } If (LEqual (\_SB.MEM.DOS2, 0x00)) { If (LOr (LNot (LEqual (\_SB.MEM.CTLA, \_SB.MEM.NXLA)), LNot (LEqual (\_SB.MEM.CTCA, \_SB.MEM.NXCA)))) { Notify (\_SB.PCI0.PCI1.VGA, 0x80) } Else { If (LNot (LEqual (\_SB.MEM.CTTA, \_SB.MEM.NXTA))) { Notify (\_SB.PCI0.PCI1.VGA, 0x80) } } } DIS (0x14) SMBR (0xFF00, 0x1E, 0x01, 0x00, 0xB2) If (LNot (LGreater (\_SB.MEM.OSID, 0x03))) { While (LEqual (\_SB.MEM.KBCR, 0x00)) {} } Store (0x01, \_SB.MEM.PAR1) Store (0x60, \_SB.PCI0.FNC0.SYSR.TRP4) If (LNot (LEqual (\_SB.MEM.ACST, \_SB.MEM.ACBK))) { If (LNot (LEqual (\_SB.MEM.RPPC, 0x01))) { Notify (\_PR.CPU0, 0x80) } } Name (BUFF, Package (0x02) { 0x00, 0x01 }) If (LEqual (\_SB.MEM.ACST, 0x00)) { And (\_SB.MEM.BST1, 0x04, Local0) If (LEqual (Local0, 0x04)) { Store (0x01, Index (BUFF, 0x00)) } } Return (BUFF) } Method (TRAP, 1, NotSerialized) { Add (Arg0, 0x12340000, Debug) } Method (SMBR, 5, NotSerialized) { Store (Arg0, \_SB.MEM.IEAX) Store (Arg1, \_SB.MEM.IEBX) Store (Arg2, \_SB.MEM.IECX) Store (Arg3, \_SB.MEM.IEDX) Store (Arg4, \_SB.PCI0.FNC0.SYSR.TRP4) } Method (STA, 1, NotSerialized) { Store (Arg0, \_SB.MEM.PAR1) Store (0x00, \_SB.MEM.PAR2) Store (0x00, \_SB.MEM.PAR3) Store (0x00, \_SB.MEM.PAR4) Store (0x00, \_SB.MEM.PAR5) Store (0x00, \_SB.MEM.PAR6) Store (0x01, \_SB.PCI0.FNC0.SYSR.TRP4) Return (\_SB.MEM.PAR4) } Method (CRS, 1, NotSerialized) { Store (Arg0, \_SB.MEM.PAR1) Store (0x00, \_SB.MEM.PAR2) Store (0x00, \_SB.MEM.PAR3) Store (0x00, \_SB.MEM.PAR4) Store (0x00, \_SB.MEM.PAR5) Store (0x00, \_SB.MEM.PAR6) Store (0x01, \_SB.PCI0.FNC0.SYSR.TRP4) If (LEqual (\_SB.MEM.PAR3, 0x00)) { Return (ResourceTemplate () { }) } Name (BUFF, Buffer (\_SB.MEM.PAR3) {}) Store (\_SB.MEM.PRES, BUFF) Return (BUFF) } Method (PRS, 1, NotSerialized) { Store (Arg0, \_SB.MEM.PAR1) Store (0x01, \_SB.MEM.PAR2) Store (0x00, \_SB.MEM.PAR3) Store (0x00, \_SB.MEM.PAR4) Store (0x00, \_SB.MEM.PAR5) Store (0x00, \_SB.MEM.PAR6) Store (0x01, \_SB.PCI0.FNC0.SYSR.TRP4) If (LEqual (\_SB.MEM.PAR3, 0x00)) { Return (ResourceTemplate () { }) } Name (BUFF, Buffer (\_SB.MEM.PAR3) {}) Store (\_SB.MEM.PRES, BUFF) Return (BUFF) } Method (SRS, 2, NotSerialized) { Store (Arg0, \_SB.MEM.PAR1) Store (0x00, \_SB.MEM.PAR2) Store (0x00, \_SB.MEM.PAR3) Store (0x00, \_SB.MEM.PAR4) Store (0x00, \_SB.MEM.PAR5) Store (0x00, \_SB.MEM.PAR6) Store (Arg1, \_SB.MEM.PRES) Store (0x02, \_SB.PCI0.FNC0.SYSR.TRP4) } Method (DIS, 1, NotSerialized) { Store (Arg0, \_SB.MEM.PAR1) Store (0x00, \_SB.MEM.PAR2) Store (0x00, \_SB.MEM.PAR3) Store (0x00, \_SB.MEM.PAR4) Store (0x00, \_SB.MEM.PAR5) Store (0x00, \_SB.MEM.PAR6) Store (0x03, \_SB.PCI0.FNC0.SYSR.TRP4) } Method (PS0, 1, NotSerialized) { Store (0x00, \_SB.MEM.IESI) SMBR (0xFE00, 0x23, Arg0, 0x00, 0xB2) If (LEqual (\_SB.MEM.OEAX, 0x00)) { Store (0x00, \_SB.MEM.IESI) SMBR (0xFF00, 0x23, Arg0, 0x00, 0xB2) WPSX (Arg0, 0x00, 0x00, 0x00) } } Method (PS3, 1, NotSerialized) { Store (0x00, \_SB.MEM.IESI) SMBR (0xFE00, 0x23, Arg0, 0x00, 0xB2) If (LEqual (\_SB.MEM.OEAX, 0x00)) { Store (0x00, \_SB.MEM.IESI) SMBR (0xFF00, 0x23, Arg0, 0x03, 0xB2) WPSX (Arg0, 0x00, 0x00, 0x03) } } Method (WPSX, 4, NotSerialized) { Store (Arg1, \_SB.MEM.IESI) Store (Arg2, \_SB.MEM.IEDI) SMBR (0xFE00, 0x23, Arg0, 0x00, 0xB2) While (LNot (LEqual (\_SB.MEM.OECX, 0x00))) { Store (Arg1, \_SB.MEM.IESI) Store (Arg2, \_SB.MEM.IEDI) SMBR (0xFE00, 0x23, Arg0, 0x00, 0xB2) } } Method (PSC, 1, NotSerialized) { Store (0x00, \_SB.MEM.IESI) SMBR (0xFE00, 0x23, Arg0, 0x00, 0xB2) Return (\_SB.MEM.OEDX) } Method (CMPS, 2, NotSerialized) { If (LEqual (SizeOf (Arg0), SizeOf (Arg1))) { Return (One) } Else { Return (Zero) } } Method (STAL, 1, NotSerialized) { If (LEqual (Arg0, 0x00)) { Return (0x09) } Else { Return (0x0B) } } Method (CRSL, 1, NotSerialized) { Name (IRQB, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {} }) CreateWordField (IRQB, 0x01, INTX) If (LNot (LEqual (Arg0, 0x00))) { Name (IRQT, Package (0x10) { 0x00, 0x0200, 0x08, 0x0400, 0x10, 0x20, 0x80, 0x40, 0x02, 0x0800, 0x00, 0x1000, 0x00, 0x4000, 0x00, 0x8000 }) Store (DerefOf (Index (IRQT, Arg0)), Local0) Store (Local0, INTX) } Return (IRQB) } Mutex (MTEX, 0x00) } -- Russell A. Jackson "I dread success. To have succeeded is to have finished one's business on earth, like the male spider, who is killed by the female the moment he has succeeded in his courtship. I like a state of continual becoming, with a goal in front and not behind." -- George Bernard Shaw From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 20:22:04 2005 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 95AEA16A41F for ; Fri, 16 Dec 2005 20:22:04 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id D50D743D69 for ; Fri, 16 Dec 2005 20:21:44 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 3961078 for multiple; Fri, 16 Dec 2005 15:19:41 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jBGKLav1081921; Fri, 16 Dec 2005 15:21:36 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Anish Mistry Date: Fri, 16 Dec 2005 15:22:03 -0500 User-Agent: KMail/1.8.2 References: <200512141720.01572.jhb@freebsd.org> <200512151631.26253.jhb@freebsd.org> <200512152133.28401.mistry.7@osu.edu> In-Reply-To: <200512152133.28401.mistry.7@osu.edu> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_sHyoDEs6QsjsMkO" Message-Id: <200512161522.04051.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1210/Thu Dec 15 10:23:22 2005 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: freebsd-current@freebsd.org Subject: Re: hostb(4) and vgapci(4) 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: Fri, 16 Dec 2005 20:22:04 -0000 --Boundary-00=_sHyoDEs6QsjsMkO Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Thursday 15 December 2005 09:33 pm, Anish Mistry wrote: > On Thursday 15 December 2005 04:31 pm, you wrote: > > On Thursday 15 December 2005 12:32 am, Anish Mistry wrote: > > > On Wednesday 14 December 2005 05:20 pm, John Baldwin wrote: > > > > I have a patch that is an attempt to untangle a few things in > > > > relation to Host-PCI bridges and VGA PCI devices. Basically, > > > > the change is to create a more "real" hostb driver as well as a > > > > new vgapci driver and to change agp, drm, and acpi_video to > > > > attach to these drivers. This means among other things: > > > > > > > > - In theory you can now kldload agp after boot since it still > > > > has a place to attach to. > > > > - i830/915 drm is no longer a child of agp, instead both become > > > > children of vgapci0. > > > > - You can now use acpi_video with drm as both attach as > > > > children of vgapci0. - This provides a way for us to possibly > > > > solve the DPMS problem for suspend/resume (including a cleaner > > > > way to do the hack dpms patch I posted to acpi@ a long while > > > > ago that several people still use). > > > > > > > > Some other details include: > > > > > > > > - agp devices no longer map the _entire_ aperture into > > > > contiguous KVA meaning that it might be possible now to use a > > > > 256 MB aperture without panicing - I've added a new pci_if.m > > > > method for locating a specific capability for a PCI device. > > > > > > > > I have tested this on my laptop and verified that dri still > > > > works, but it needs some wider testing, especially the > > > > i830/i915 case is slightly more complicated. Also, this is not > > > > going to work with the nvidia-driver currently, but that's > > > > something that can be fixed in the future. If the agp > > > > non-mapping does fix the 256 MB aperture issues then I will > > > > probably MFC that part to RELENG_6. > > > > > > > > http://www.FreeBSD.org/~jhb/patches/agp_cvs.patch > > > > > > Thank you! It seems to work as advertised. I'm running mach64 > > > DRM with the DPMS patch acpi_video and they both work. :) > > > One small problem though. When I unload the acpi_video module > > > and reload it I get the following: > > > littleguy# kldload acpi_video > > > acpi_video0: on vgapci0 > > > acpi_video1: on vgapci0 > > > littleguy# kldunload acpi_video > > > acpi_video0: detached > > > acpi_video1: detached > > > littleguy# kldunload acpi_video > > > kldunload: can't find file acpi_video: No such file or directory > > > littleguy# kldload acpi_video > > > acpi_video0: on vgapci0 > > > acpi_video1: on vgapci0 > > > acpi_video2: on vgapci0 > > > littleguy# > > > It also created multiple sysctls with subsequent loads: > > > hw.acpi.video.crt0.active: 1 > > > hw.acpi.video.lcd0.active: 1 > > > hw.acpi.video.tv0.active: 0 > > > hw.acpi.video.crt1.active: 1 > > > hw.acpi.video.lcd1.active: 1 > > > hw.acpi.video.tv1.active: 0 > > > hw.acpi.video.crt2.active: 1 > > > hw.acpi.video.lcd2.active: 1 > > > hw.acpi.video.tv2.active: 0 > > > > Revert just the changes to acpi_video.c and then apply the attached > > patch to see if it fixes the multiple load issue. > > Yes. The patch corrects the problem. Actually, can you try a simpler one just to be sure? Thanks. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org --Boundary-00=_sHyoDEs6QsjsMkO Content-Type: text/x-diff; charset="iso-8859-6"; name="agp_acpi.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="agp_acpi.patch" --- //depot/vendor/freebsd/src/sys/dev/acpica/acpi_video.c 2005/09/11 18:40:38 +++ //depot/user/jhb/agp/dev/acpica/acpi_video.c 2005/12/16 16:42:11 @@ -70,6 +70,7 @@ /* interfaces */ static int acpi_video_modevent(struct module*, int, void *); +static void acpi_video_identify(driver_t *driver, device_t parent); static int acpi_video_probe(device_t); static int acpi_video_attach(device_t); static int acpi_video_detach(device_t); @@ -137,6 +138,7 @@ #define DSS_COMMIT (1 << 31) static device_method_t acpi_video_methods[] = { + DEVMETHOD(device_identify, acpi_video_identify), DEVMETHOD(device_probe, acpi_video_probe), DEVMETHOD(device_attach, acpi_video_attach), DEVMETHOD(device_detach, acpi_video_detach), @@ -152,7 +154,7 @@ static devclass_t acpi_video_devclass; -DRIVER_MODULE(acpi_video, pci, acpi_video_driver, acpi_video_devclass, +DRIVER_MODULE(acpi_video, vgapci, acpi_video_driver, acpi_video_devclass, acpi_video_modevent, NULL); MODULE_DEPEND(acpi_video, acpi, 1, 1, 1); @@ -189,6 +191,14 @@ return (err); } +static void +acpi_video_identify(driver_t *driver, device_t parent) +{ + + if (device_find_child(parent, "acpi_video", -1) == NULL) + device_add_child(parent, "acpi_video", -1); +} + static int acpi_video_probe(device_t dev) { --Boundary-00=_sHyoDEs6QsjsMkO-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 20:24:55 2005 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 1D03216A41F for ; Fri, 16 Dec 2005 20:24:55 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 627C443D46 for ; Fri, 16 Dec 2005 20:24:54 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 3961300 for multiple; Fri, 16 Dec 2005 15:22:51 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jBGKOfnp081948; Fri, 16 Dec 2005 15:24:45 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Ulrich Spoerlein Date: Fri, 16 Dec 2005 15:23:19 -0500 User-Agent: KMail/1.8.2 References: <200512141720.01572.jhb@freebsd.org> <20051216111854.GC1103@galgenberg.net> In-Reply-To: <20051216111854.GC1103@galgenberg.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512161523.20685.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1210/Thu Dec 15 10:23:22 2005 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: current@freebsd.org Subject: Re: hostb(4) and vgapci(4) 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: Fri, 16 Dec 2005 20:24:55 -0000 On Friday 16 December 2005 06:18 am, Ulrich Spoerlein wrote: > John Baldwin wrote: > > I have a patch that is an attempt to untangle a few things in relation to > > Host-PCI bridges and VGA PCI devices. Basically, the change is to create > > a more "real" hostb driver as well as a new vgapci driver and to change > > agp, drm, and acpi_video to attach to these drivers. This means among > > other things: > > > > - You can now use acpi_video with drm as both attach as children of > > vgapci0. > > > > http://www.FreeBSD.org/~jhb/patches/agp_cvs.patch > > Hi, > > I'm eager to try this patch on RELENG_6 with a Radeon Mobility card, > however the patch wont compile on RELENG_6. Could you please provide a > diff against RELENG_6? That would be great, thanks! > > /usr/src/sys/dev/pci/pci.c: In function `pci_find_extcap_method': > /usr/src/sys/dev/pci/pci.c:509: error: `PCIR_CAP_PTR_2' undeclared (first > use in this function) /usr/src/sys/dev/pci/pci.c:509: error: (Each > undeclared identifier is reported only once /usr/src/sys/dev/pci/pci.c:509: > error: for each function it appears in.) Hmm, for now I want to get it working against 7.0. I will probably not be able to MFC much of it at all (perhaps the one part to stop mapping the AGP aperture into KVA) since it would break existing agp and drm drivers for 6.x. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 20:25:10 2005 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 0434016A427 for ; Fri, 16 Dec 2005 20:25:10 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE5EE43D55 for ; Fri, 16 Dec 2005 20:24:57 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 3961306 for multiple; Fri, 16 Dec 2005 15:22:55 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jBGKOfnq081948; Fri, 16 Dec 2005 15:24:47 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Goran Gajic Date: Fri, 16 Dec 2005 15:25:11 -0500 User-Agent: KMail/1.8.2 References: <200512151356.41550.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512161525.12656.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1210/Thu Dec 15 10:23:22 2005 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: freebsd-current@freebsd.org Subject: Re: skype-1.2.0.18-static for linux and FreeBSD 7.0 CURRENT 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, 16 Dec 2005 20:25:10 -0000 On Friday 16 December 2005 04:13 am, Goran Gajic wrote: > On Thu, 15 Dec 2005, John Baldwin wrote: > > If you are in X this is probably a panic (currently the kernel doesn't > > create a coredump while you are in X which is a bug). Can you hook up a > > serial console and use that to get the panic message? > > Yes, here is capture from minicom: > > drm0: port 0xc000-0xc0ff mem > 0xe8000000-0xefffffff,0xff8f0000-0xff8fffff irq 16 at device 0.0 on pci1 > info: [drm] AGP at 0xf8000000 64MB > info: [drm] Initialized radeon 1.19.0 20050911 > info: [drm] Loading R200 Microcode > lock order reversal: > 1st 0xc366e21c vnode interlock (vnode interlock) @ kern/vfs_vnops.c:791 > 2nd 0xc3b8fb44 process lock (process lock) @ i386/i386/trap.c:742 > KDB: stack backtrace: > kdb_backtrace(0,ffffffff,c0975450,c0975900,c0927544) at kdb_backtrace+0x29 > witness_checkorder(c3b8fb44,9,c08be5a5,2e6) at witness_checkorder+0x580 > _mtx_lock_flags(c3b8fb44,0,c08be59c,2e6,c3b91780) at _mtx_lock_flags+0x5b > trap_pfault(dbc9da28,0,3) at trap_pfault+0xb2 > trap(dbc90008,c0680028,c09b0028,c3b91780,dbc9da84) at trap+0x3cd > calltrap() at calltrap+0x5 > --- trap 0xc, eip = 0xc081799c, esp = 0xdbc9da68, ebp = 0xdbc9da70 --- > stack_save(dbc9da84) at stack_save+0x1c Ah, I think the stack_save() stuff in 6.0 is buggy. I think there's a fix in HEAD. I would just turn those DEBUG options off for now. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 20:25:51 2005 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 9C02416A41F; Fri, 16 Dec 2005 20:25:51 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from mail.united-ware.com (am-productions.biz [69.61.164.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32FA943D49; Fri, 16 Dec 2005 20:25:33 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.100] (am-productions.biz [69.61.164.22]) (authenticated bits=0) by mail.united-ware.com (8.13.4/8.13.4) with ESMTP id jBGKSXBJ031856 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 16 Dec 2005 15:28:39 -0500 (EST) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: John Baldwin Date: Fri, 16 Dec 2005 15:27:19 -0500 User-Agent: KMail/1.8.3 References: <200512161237.15148.mistry.7@osu.edu> <200512161511.10903.jhb@freebsd.org> In-Reply-To: <200512161511.10903.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1386866.TTEqWZtIAv"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200512161527.34667.mistry.7@osu.edu> X-Spam-Status: No, score=-8.4 required=5.0 tests=ALL_TRUSTED, BAYES_00, BIZ_TLD, MYFREEBSD2,MYFREEBSD3 autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on mail.united-ware.com X-Virus-Scanned: ClamAV 0.87/1210/Thu Dec 15 10:23:22 2005 on mail.united-ware.com X-Virus-Status: Clean Cc: freebsd-current@freebsd.org Subject: Re: Reproducable Panic on CURRENT and 6.0-RELEASE 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, 16 Dec 2005 20:25:51 -0000 --nextPart1386866.TTEqWZtIAv Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 16 December 2005 03:11 pm, you wrote: > On Friday 16 December 2005 12:37 pm, Anish Mistry wrote: > > Here is the offending program/code. The interesting program is > > avidemux_2.1_branch_anish/avidemux/avidemux2. > > (It is compiled for CURRENT, and I left all the object code stuff > > in so it's a bit large 21MB) > > http://am-productions.biz/docs/avidemux_2.1_branch_anish.tgz > > > > First you'll need to compile spidermonkey to be threadsafe so add > > the following to your lang/spidermonkey/Makefile before > > installing it: LIB_DEPENDS=3D nspr4.1:${PORTSDIR}/devel/nspr > > MAKE_ARGS+=3D JS_THREADSAFE=3DYES LDFLAGS=3D"-L${LOCALBASE}/lib > > -lpthread -lm" > > CFLAGS+=3D -I${LOCALBASE}/include/nspr > > > > Once a threadsafe spidermonkey is installed to kill the machine > > you'll need to: > > cd avidemux_2.1_branch_anish/avidemux > > ./avidemux2 --run new-features-test.js > > > > On CURRENT: > > kernel trap 12 with interrupts disabled > > > > Fatal trap 12: page fault while in kernel mode > > fault virtual address =3D 0x68 > > fault code =3D supervisor read, page not present > > instruction pointer =3D 0x20:0xc04e6f36 > > stack pointer =3D 0x28:0xcc9edb3c > > frame pointer =3D 0x28:0xcc9edbb0 > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > > =3D DPL 0, pres 1, def32 1, gran 1 > > processor eflags =3D resume, IOPL =3D 0 > > current process =3D 798 (gdb) > > trap number =3D 12 > > panic: page fault > > > > #0 doadump () at pcpu.h:165 > > #1 0xc04bb7eb in boot (howto=3D260) > > at /usr/src/sys/kern/kern_shutdown.c:399 > > #2 0xc04bb353 in panic (fmt=3D0xc06069a7 "%s") > > at /usr/src/sys/kern/kern_shutdown.c:555 > > #3 0xc05e91ba in trap_fatal (frame=3D0xcc9edafc, eva=3D104) > > at /usr/src/sys/i386/i386/trap.c:862 > > #4 0xc05e96d9 in trap (frame=3D > > {tf_fs =3D 8, tf_es =3D 40, tf_ds =3D 40, tf_edi =3D -1032878460, > > tf_esi =3D 1, tf_ebp =3D -862004304, tf_isp =3D -862004440, tf_ebx =3D > > -1033297504, tf_edx =3D -1033987232, tf_ecx =3D 4, tf_eax =3D 0, > > tf_trapno =3D 12, tf_err =3D 0, tf_eip =3D -1068601546, tf_cs =3D 32, > > tf_eflags =3D 65687, tf_esp =3D -1032878356, tf_ss =3D -1067380424}) > > at /usr/src/sys/i386/i386/trap.c:273 > > #5 0xc05db6fa in calltrap () > > at /usr/src/sys/i386/i386/exception.s:137 > > #6 0xc04e6f36 in kern_ptrace (td=3D0xc25e9b60, req=3D10, pid=3D1, > > addr=3D0x0, data=3D17) > > at /usr/src/sys/kern/sys_process.c:802 > > On HEAD this is: > p->p_xthread->td_flags &=3D ~TDF_XSIG; > > If two threads called kern_ptrace() with the same PID and this > could happen. Hmm, I have no idea how p_xthread is supposed to not > be racey here in fact. It would be helpful to know what PTRACE > action it it is trying to do and maybe a KTR trace of the various > ptrace events leading up to this condition. I have no idea what > thread you are supposed to act on if p_xthread is NULL either. How would I do this? My kdb/ddb skills are prettymuch limited to=20 getting a backtrace. > > > #7 0xc04e71f0 in ptrace (td=3D0xc25e9b60, uap=3D0xcc9edd04) > > at /usr/src/sys/kern/sys_process.c:433 > > #8 0xc05e9ca6 in syscall (frame=3D > > {tf_fs =3D 59, tf_es =3D 59, tf_ds =3D 59, tf_edi =3D 136221752, > > tf_esi =3D 796, tf_ebp =3D -1077943184, tf_isp =3D -862003868, tf_ebx = =3D > > 796, tf_edx =3D 674587084, tf_ecx =3D 674505768, tf_eax =3D 26, > > tf_trapno =3D 12, tf_err =3D 2, tf_eip =3D 673978987, tf_cs =3D 51, > > tf_eflags =3D 518, tf_esp =3D -1077943208, tf_ss =3D 59}) > > at /usr/src/sys/i386/i386/trap.c:1008 > > ---Type to continue, or q to quit--- > > #9 0xc05db74f in Xint0x80_syscall () > > at /usr/src/sys/i386/i386/exception.s:190 > > #10 0x00000033 in ?? () > > > > > > http://am-productions.biz/docs/littleguy-dmesg.gz > > http://am-productions.biz/docs/littleguy-pciconf.gz > > > > > > > > From my previous email to questions with the info on 6.0-RELEASE: > > I'm getting the following panic, which I can reproduce easily.=20 > > Let me know what other information I should provide. The > > backtrace seems really short for some reason. I get the panic > > when running a multi-threaded application I'm > > developing/modifying. > > > > kernel trap 12 with interrupts disabled > > > > Fatal trap 12: page fault while in kernel mode > > fault virtual address =3D 0x48 > > fault code =3D supervisor write, page not present > > instruction pointer =3D 0x20:0xc0510cb3 > > stack pointer =3D 0x28:0xe9aebb74 > > frame pointer =3D 0x28:0xe9aebbf8 > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > > =3D DPL 0, pres 1, def32 1, gran 1 > > processor eflags =3D resume, IOPL =3D 0 > > current process =3D 7848 (gdb) > > [thread pid 7848 tid 100184 ] > > Stopped at kern_ptrace+0x11e3: andl =20 > > $0xfffbffff,0x48(%eax) db> bt > > Tracing pid 7848 tid 100184 td 0xc4302180 > > kern_ptrace(c4302180,a,1ea6,0,11) at kern_ptrace+0x11e3 > > ptrace(c4302180,e9aebd04,10,418,4) at ptrace+0x56 > > syscall(3b,3b,3b,bfbfe580,1ea6) at syscall+0x13d > > Xint0x80_syscall() at Xint0x80_syscall+0x1f > > --- syscall (26, FreeBSD ELF32, ptrace), eip =3D 0x283360e7, esp =3D > > 0xbfbfe3bc, ebp > > =3D 0xbfbfe3d8 --- > > > > > > > > Full panic and backtrace, and alltrace: > > http://am-productions.biz/docs/bigguy-panic.gz > > http://am-productions.biz/docs/bigguy-dmesg.gz > > http://am-productions.biz/docs/bigguy-pciconf.gz > > Kernel config: > > http://am-productions.biz/docs/BIGGUY.gz > > > > > > I have firewire console access to the CURRENT system, and serial > > console access for the 6.0-RELEASE. > > > > Thanks, =2D-=20 Anish Mistry --nextPart1386866.TTEqWZtIAv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDoyM2xqA5ziudZT0RAslwAKCH12JtBe80VgBXA14EIjbATnxL5ACgpU57 5FKCFjdb3Md2Kzy6fH1lJ8k= =lh5N -----END PGP SIGNATURE----- --nextPart1386866.TTEqWZtIAv-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 20:53:02 2005 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 CEE2C16A41F; Fri, 16 Dec 2005 20:53:02 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF83343D60; Fri, 16 Dec 2005 20:53:01 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.4/8.13.4) with ESMTP id jBGKr045021666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Dec 2005 15:53:00 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id jBGKqqFb036241; Fri, 16 Dec 2005 15:52:52 -0500 (EST) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17315.10532.603357.165238@grasshopper.cs.duke.edu> Date: Fri, 16 Dec 2005 15:52:52 -0500 (EST) To: John Baldwin In-Reply-To: <200512161454.22232.jhb@freebsd.org> References: <17314.60552.595375.783753@grasshopper.cs.duke.edu> <200512161454.22232.jhb@freebsd.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: freebsd-current@freebsd.org Subject: Re: PREEMPTION vs ndisulator 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, 16 Dec 2005 20:53:03 -0000 John Baldwin writes: > On Friday 16 December 2005 11:34 am, Andrew Gallatin wrote: > > I'm trying to use an ndis driver on an amd64 machine running > > FreeBSD/amd64 -current from yesterday. If I enable PREEMPTION, the > > machine hangs when loading the driver (kldload never returns): > > > > ndis0: mem > > 0xfc000000-0xfcffffff,0xfdf00000-0xfdffffff irq 18 at device 0.0 on pci5 > > ndis0: NDIS API version: 5.1 > > > > > > Witness detects no problems, and if I disable PREEMPTION, the driver > > seems to work fine. Is PREEMPTION not safe to be used with the > > ndisulator, or is there a problem with the ndis driver itself? > > > > I've included some very brief debugging info below.. > > Looks like an ithread has preempted your driver's start routine. If you let > it run some more and then break into ddb is the same thread (pid 11) still > running? Also, which process is pid 11? Naturally, I no longer have that kernel :( I just built a new, PREEMPTION enabled kernel. Booting in single user, I see a hang in the irq thread. It seems to always be in this thread. I think the difference is that I don't have the if_sk driver loaded, which shares that irq. Can you remind me how to get irq counts from ddb? It would be intersting to see if the irq hander was called repeatedly, or if it was just stuck in the handler. BTW, when it works, I can send at nearly 7Gb/s. Not bad for an amd3000+ running an emulated driver. Solaris/linux can do a native 9.5Gb/sec on this hardware. I'll do a native FreeBSD driver when I get a chance to come up for air ;) Thanks, Drew db> ps pid proc uid ppid pgrp flag stat wmesg wchan cmd 55 ffffff001e64ea80 0 0 0 0000204 [CPU 0] irq18: ndis0 54 ffffff001898b000 0 0 0 0000204 [SLPQ KeWFS 0xffffffff9670cb80][SLP] Windows Workitem 3 53 ffffff001898b380 0 0 0 0000204 [SLPQ KeWFS 0xffffffff96703b80][SLP] Windows Workitem 2 52 ffffff001898b700 0 0 0 0000204 [SLPQ KeWFS 0xffffffff966fab80][SLP] Windows Workitem 1 51 ffffff001898ba80 0 0 0 0000204 [SLPQ KeWFS 0xffffffff966f1b80][SLP] Windows Workitem 0 50 ffffff00189cc000 0 0 0 0000204 [RUNQ] Windows DPC 0 49 ffffff00189cc380 0 45 49 0004002 [RUNQ] kldload 45 ffffff001ecc6a80 0 43 45 0004002 [SLPQ pause 0xffffff001ecc6ae8][SLP] tcsh 43 ffffff001e989380 0 1 43 0004002 [SLPQ wait 0xffffff001e989380][SLP] sh 42 ffffff001e989700 0 0 0 0000204 [SLPQ - 0xffffffff95119c24][SLP] schedcpu 41 ffffff001e989a80 0 0 0 0000204 [SLPQ - 0xffffffff80662918][SLP] nfsiod 3 40 ffffff001e98a000 0 0 0 0000204 [SLPQ - 0xffffffff80662910][SLP] nfsiod 2 39 ffffff001e98a380 0 0 0 0000204 [SLPQ - 0xffffffff80662908][SLP] nfsiod 1 38 ffffff001e98a700 0 0 0 0000204 [SLPQ - 0xffffffff80662900][SLP] nfsiod 0 37 ffffff001e98aa80 0 0 0 0000204 [SLPQ syncer 0xffffffff805d9500][SLP] syncer 36 ffffff001e64e000 0 0 0 0000204 [SLPQ vlruwt 0xffffff001e64e000][SLP] vnlru 35 ffffff001ed0d700 0 0 0 0000204 [SLPQ psleep 0xffffffff8065d818][SLP] bufdaemon 34 ffffff001ed0da80 0 0 0 000020c [SLPQ pgzero 0xffffffff8066a9f0][SLP] pagezero 33 ffffff001ec65000 0 0 0 0000204 [SLPQ psleep 0xffffffff8066a0d4][SLP] vmdaemon --More--^M ^M 32 ffffff001ec65380 0 0 0 0000204 [SLPQ psleep 0xffffffff8066a08c][SLP] pagedae mon 31 ffffff001ec65700 0 0 0 0000204 [IWAIT] swi0: sio 30 ffffff001ec65a80 0 0 0 0000204 [SLPQ cooling 0xffffff001ec9f958][SLP] acpi_cooling0 29 ffffff001ecc6000 0 0 0 0000204 [SLPQ tzpoll 0xffffffff805d2488][SLP] acpi_thermal 28 ffffff001ecc6380 0 0 0 0000204 [IWAIT] irq17: fwohci0 27 ffffff001ecc6700 0 0 0 0000204 [IWAIT] irq23: atapci1 26 ffffff001ed36700 0 0 0 0000204 [IWAIT] irq15: ata1 25 ffffff001ed36a80 0 0 0 0000204 [IWAIT] irq14: ata0 24 ffffff001ed2c000 0 0 0 0000204 [SLPQ usbevt 0xffffff0000917420][SLP] usb1 23 ffffff001ed2c380 0 0 0 0000204 [IWAIT] irq22: nve0 ehci0 22 ffffff001ed2c700 0 0 0 0000204 [SLPQ usbtsk 0xffffffff805d4d90][SLP] usbtask 21 ffffff001ed2ca80 0 0 0 0000204 [SLPQ usbevt 0xffffffff83ce9420][SLP] usb0 20 ffffff001ed0d000 0 0 0 0000204 [IWAIT] irq21: ohci0+ 19 ffffff001ed0d380 0 0 0 0000204 [IWAIT] irq9: acpi0 9 ffffff001ecf9a80 0 0 0 0000204 [SLPQ - 0xffffff00008f0c00][SLP] thread taskq 18 ffffff001ed12000 0 0 0 0000204 [IWAIT] swi5: Fast taskq 8 ffffff001ed12380 0 0 0 0000204 [SLPQ - 0xffffff00008f0d80][SLP] acpi_task2 7 ffffff001ed12700 0 0 0 0000204 [SLPQ - 0xffffff00008f0d80][SLP] acpi_task1 6 ffffff001ed12a80 0 0 0 0000204 [SLPQ - 0xffffff00008f0d80][SLP] acpi_task0 5 ffffff001ed36000 0 0 0 0000204 [SLPQ - 0xffffff00008f0e00][SLP] kqueue taskq --More--^M ^M 17 ffffff001ed36380 0 0 0 0000204 [IWAIT] swi2: cambio 16 ffffff001ed32380 0 0 0 0000204 [IWAIT] swi6: task queue 15 ffffff001ed32700 0 0 0 0000204 [IWAIT] swi6: Giant taskq 14 ffffff001ed32a80 0 0 0 0000204 [SLPQ - 0xffffffff805d2c80][SLP] yarrow 4 ffffff001ecf9000 0 0 0 0000204 [SLPQ - 0xffffffff805d5938][SLP] g_down 3 ffffff001ecf9380 0 0 0 0000204 [SLPQ - 0xffffffff805d5930][SLP] g_up 2 ffffff001ecf9700 0 0 0 0000204 [SLPQ - 0xffffffff805d5920][SLP] g_event 13 ffffff001ed48000 0 0 0 0000204 [IWAIT] swi3: vm 12 ffffff001ed48380 0 0 0 000020c [RUNQ] swi4: clock sio 11 ffffff001ed48700 0 0 0 0000204 [IWAIT] swi1: net 10 ffffff001ed48a80 0 0 0 000020c [Can run] idle 1 ffffff001ed32000 0 0 1 0004200 [SLPQ wait 0xffffff001ed32000][SLP] init 0 ffffffff805d5aa0 0 0 0 0000200 [IWAIT] swapper db> trace Tracing pid 55 tid 100047 td 0xffffff001e890000 kdb_enter() at kdb_enter+0x2f siointr1() at siointr1+0x400 siointr() at siointr+0x2e intr_execute_handlers() at intr_execute_handlers+0x124 lapic_handle_intr() at lapic_handle_intr+0x21 Xapic_isr1() at Xapic_isr1+0x7c --- interrupt, rip = 0xffffffff803c17e2, rsp = 0xffffffff953c0bf0, rbp = 0xffffffff953c0c10 --- spinlock_exit() at spinlock_exit+0x32 ithread_loop() at ithread_loop+0x30d fork_exit() at fork_exit+0xbb fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffff953c0d40, rbp = 0 --- db> From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 21:01:16 2005 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 7F22016A41F for ; Fri, 16 Dec 2005 21:01:16 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD44443D7C for ; Fri, 16 Dec 2005 21:01:11 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id CE918BC66 for ; Fri, 16 Dec 2005 21:01:03 +0000 (UTC) To: current@freebsd.org From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 16 Dec 2005 18:56:39 GMT." <200512161856.jBGIudig093608@repoman.freebsd.org> Date: Fri, 16 Dec 2005 22:01:03 +0100 Message-ID: <8509.1134766863@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Subject: About extensible prinf(3), a slightly long X-mas card 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, 16 Dec 2005 21:01:16 -0000 Those of you following CVS commits will have have noticed that I just added an extensible printf(3) implemention as an experiment. This email is intended to provide some insight and background. First, what is it ? ------------------- In a program I'm writing right now, I have some measurement points which are identified by a triplet of numbers, usually encoded in a single integer. That means I have to write things like printf("%03u.%03u.%03u", SITE_OF(p), GROUP_OF(p), POINT_OF(p)); where each of the three macros basically does "(X >> a) & b" for varying a and b. I could have made a function: char * fmt_U(unsigned p) { static char buf[12]; sprintf(buf, "%03u.%03u.%03u", SITE_OF(p), GROUP_OF(p), POINT_OF(p)); return (buf); } and that would mostly work, only not where it is most needed because of the static buffer: fprintf(stderr, "WARNING: configuring %03u.%03u.%03u as analog-input" " conflicts with pin usage on %03u.%03u.%03u thru " "%03u.%03u.%03u\n", SITE_OF(p), GROUP_OF(p), POINT_OF(p), SITE_OF(a), GROUP_OF(a), POINT_OF(a), SITE_OF(b), GROUP_OF(b), POINT_OF(b)); Obviously, it would be much smarter if I could tell printf that %U in my program means format an integer this particular way and write the much more readable: fprintf(stderr, "WARNING: configuring %U as analog-input" " conflicts with pin usage on %U thru %U\n", a, b, c); What ABI to use ? ----------------- GLIBC got here before us, so, lets examine their ABI: The GLIBC ABI consists of a function int register_printf_function( int spec, printf_function *render, printf_arginfo_function *arginfo); The arginfo function is called first, to determine the kinds of arguments, and the render function is called to do the actual formatting. This two-step approach is necessary because at some point some madhatter in some standardsbody or other added a positional argument facility to printf() without thinking about the consequences: Did you know that printf("%2$s %1$s\n", "world\n", "Hello"); is legal ? There are semi-quasi-good reasons for allowing something like this, but the cost in performance is high: One is forced to scan the format string at least twice to first determine the types for the arguments and then again in order to actually render them to the output. In practice one is forced to scan the format string _three_ times, once to find the number of arguments so that memory can be allocated for the second pass which finds the type so that this info can be made available for the third pass. Sigh... Well, anyway, back to my example: The code to implement my points would in GLIBC's world look like this: First a function which says that we take one argument of type int: int printf_arginfo_point(const struct printf_info *pi, size_t n, int *argt) { assert(n >= 1); argt[0] = PA_INT; return (1); } and then a function to render that: int printf_render_point(FILE *fp, const struct printf_info *pi, const void *const *arg) { unsigned u; u = *((unsigned **)arg[0]); return (fprintf(fp, "%03u.%03u.%03u", SITE_OF(u), GROUP_OF(u), POINT_OF(u))); } And finally a call to register these two; i = register_printf_function('U', printf_render_point, printf_arginfo_point); I can live with that, so I have adopted that ABI. Implementation & performance ---------------------------- The next thing was to teach our printf(3) implementation about this, and boy, what a monster. Take a peek for yourself in: src/lib/libc/stdio/vfprintf.c This is why we in FreeBSD have such a damn good performance: every trick in the book have been used where it matters. Attempting to shoe-horn extensibility into this piece of code would be suicide, both from a performance point of view and for my sanity. Instead what I did was write a new implementation of the core task: parsing the format string, and then extracted the integer, floating-point, string and char stuff from the vfprintf.c code and put it into separate files and aligned those with the GLIBC ABI. Until somebody specifically ask for it (with a global variable or an environment variable) or registers an extension, we keep running on our good old fast spaghetti vprintf, but once extensibility is called for, we switch to my code. Unfortunately, the extensible printf had a totally unsatisfactory perforamnce in comparison with the vprintf.c one and something had to happen. The problem is that printing for instance a floating point number consists of marshalling up to 6 pieces of the string: * [+|-| ] [0x|0X] MMM . NNN [e|E|p|P] [+|-] ZZ * A B ---C--- D E F (taken from an exceptionally good comment in vfprintf.c) and in addition there may be leading and trailing padding to the requested field width. That means that worst (sensible) case, 8 separate I/O requests will be made for one floating point number. Ouch. The vprintf.c implementation has its own private struct uio implementation for this exact reason. I reimplmented that so that it was compatible with the extensibility of the new printf, but that unfortunately breaks the GLIBC ABI because now the render function must take a "struct __printf_io *" instead of a "FILE *" So right now we have two ABIs, the GLIBC and the FreeBSD. I'm not happy with that, and I may drop the FreeBSD one again and decide to live with the performance hit. Another trick which vfprintf.c does is that if the file is unbuffered (setbuf(fp, NULL)) it creates a local buffer so that each of the I/Os won't result in a write(2) system call, and only at the end of the printf(3) operation, does the buffer get written to the file. Sneaky. I've added that as well and that helped performance a good deal too. Default extensions ------------------ I also decided that there were some pieces of code that I have written far too many times to be funny, and therefore I added three sets of arginfo/render functions for things I have missed more times than I could count: %H -- Hexdump Takes a pointer and a length: printf("Received %H\n", packet, packet_len); 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 If you add a width, that will control how many columns are printed: printf("Received %4H\n", packet, packet_len); 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 Adding the printf flag for alternate will add ascii dump and a "+" will give addresses: printf("Received %+#8H\n", packet, packet_len); 0000 00 01 02 03 04 05 06 07 |........| 0008 08 09 0a 0b 0c 0d 0e 0f |........| 0010 10 11 12 13 |.... | %V -- Stringvis Expands non-printable characters to C-style back-slash escapes, octal back-slash escapes or HTTP stype %xx escapes: printf("%V", recv_string) Hello\tWor\377ld printf("%0V", recv_string) Hello\011Wor\377ld printf("%+V", recv_string) Hello%09Wor%FFld %T -- time_t/timeval/timespec Making sense of time intervals takes a lot of printf work, and I do this a lot: printf("%T\n", &delta_t); /* time_t */ 20349 printf("%#T\n", &delta_t); /* time_t */ 5h39m9 printf("%#lT\n", &tv); /* struct timeval */ 5h39m9.245000 printf("%#.3llT\n", &ts); /* struct timespec */ 5h39m9.245 You can enable these with register_printf_render_std("HVT"); Style(9) and GCC issues ----------------------- Obviously, such extensions are not condoned by style(9) but probably more damning, GCC's printf format checker knows nothing about them, so it will take a fit if you use them. For these reasons, and for general reasons of sanity, printf format extensions should _not_ be added to FreeBSD programs at this time, if ever. Conclusion & future -------------------- Well, there you have it: Some of you will, like me, have implemented your own printf many times to do stuff like this, now FreeBSD offers a sane way to do that. If this proves useful, it'll stay in the tree and be part of 7.0 (no MFCs!) it people break out in bikesheds about it, it will not. Keep me posted... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 21:05:24 2005 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 678DB16A41F for ; Fri, 16 Dec 2005 21:05:24 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from mail.united-ware.com (am-productions.biz [69.61.164.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08A6D43D5A for ; Fri, 16 Dec 2005 21:05:18 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.100] (am-productions.biz [69.61.164.22]) (authenticated bits=0) by mail.united-ware.com (8.13.4/8.13.4) with ESMTP id jBGL8Nga032519 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 16 Dec 2005 16:08:29 -0500 (EST) (envelope-from mistry.7@osu.edu) From: Anish Mistry Date: Fri, 16 Dec 2005 16:07:02 -0500 User-Agent: KMail/1.8.3 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: multipart/signed; boundary="nextPart2979708.qt17fU5D22"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200512161607.24657.mistry.7@osu.edu> X-Spam-Status: No, score=-4.8 required=5.0 tests=ALL_TRUSTED,BAYES_50, MYFREEBSD2 autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on mail.united-ware.com X-Virus-Scanned: ClamAV 0.87/1210/Thu Dec 15 10:23:22 2005 on mail.united-ware.com X-Virus-Status: Clean Subject: LOR #155 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, 16 Dec 2005 21:05:24 -0000 --nextPart2979708.qt17fU5D22 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I got LOR #155 *I think* when unload acpi_video while testing some of=20 jhb's patches. acpi_video0: detached lock order reversal: (sleepable after non-sleepable) 1st 0xc104e8c8 mt_zone (UMA zone) @ /usr/src/sys/vm/uma_core.c:2452 2nd 0xc2424d34 user map (user map) @ /usr/src/sys/vm/vm_map.c:2993 KDB: stack backtrace: witness_checkorder(c2424d34,9,c062abe6,bb1,cc9dbaac) at=20 witness_checkorder+0x5aa _sx_xlock(c2424d34,c062abe6,bb1,1000001,cc9dbaac) at _sx_xlock+0x3c vm_map_lookup(cc9dbaac,0,1,cc9dbab0,cc9dbaa0,cc9dbaa4,cc9dba87,cc9dba88)=20 at vm_map_lookup+0x24 vm_fault(c2424cf0,0,1,0,c25ed1a0) at vm_fault+0x63 trap_pfault(15) at trap_pfault+0x12c trap(8,28,28,0,c104e8c0) at trap+0x37a calltrap() at calltrap+0x5 =2D-- trap 0xc, eip =3D 0xc05a8ec8, esp =3D 0xcc9dbc08, ebp =3D 0xcc9dbc1c = =2D-- uma_zfree_internal(0,1,3) at uma_zfree_internal+0xb8 malloc_uninit(c078f020,c078ee1c,0,cc9dbc70,c04aebc2) at=20 malloc_uninit+0xb3 linker_file_unload(c2049b00,0,0,c25ed1a0,c25ebadc) at=20 linker_file_unload+0x2f8 kern_kldunload(0,cc9dbd04,2,0,3) at kern_kldunload+0x68 syscall(3b,3b,3b,5,bfbfe9de) at syscall+0x166 Xint0x80_syscall() at Xint0x80_syscall+0x1f =2D-- syscall (444, FreeBSD ELF32, kldunloadf), eip =3D 0x280ab48b, esp =3D= =20 0xbfbfe464, ebp =3D 0xbfbfe8a8 --- KDB: enter: witness_checkorder [thread pid 717 tid 100061 ] Stopped at kdb_enter+0x2c: leal 0(%esi),%esi db> bt Tracing pid 717 tid 100061 td 0xc25ed1a0 kdb_enter(c05ff2df,9,c062abe6,bb1,cc9dbaac) at kdb_enter+0x2c _sx_xlock(c2424d34,c062abe6,bb1,1000001,cc9dbaac) at _sx_xlock+0x3c vm_map_lookup(cc9dbaac,0,1,cc9dbab0,cc9dbaa0,cc9dbaa4,cc9dba87,cc9dba88)=20 at vm_map_lookup+0x24 vm_fault(c2424cf0,0,1,0,c25ed1a0) at vm_fault+0x63 trap_pfault(15) at trap_pfault+0x12c trap(8,28,28,0,c104e8c0) at trap+0x37a calltrap() at calltrap+0x5 =2D-- trap 0xc, eip =3D 0xc05a8ec8, esp =3D 0xcc9dbc08, ebp =3D 0xcc9dbc1c = =2D-- uma_zfree_internal(0,1,3) at uma_zfree_internal+0xb8 malloc_uninit(c078f020,c078ee1c,0,cc9dbc70,c04aebc2) at=20 malloc_uninit+0xb3 linker_file_unload(c2049b00,0,0,c25ed1a0,c25ebadc) at=20 linker_file_unload+0x2f8 kern_kldunload(0,cc9dbd04,2,0,3) at kern_kldunload+0x68 syscall(3b,3b,3b,5,bfbfe9de) at syscall+0x166 Xint0x80_syscall() at Xint0x80_syscall+0x1f =2D-- syscall (444, FreeBSD ELF32, kldunloadf), eip =3D 0x280ab48b, esp =3D= =20 0xbfbfe464, ebp =3D 0xbfbfe8a8 --- db>=20 =2D-=20 Anish Mistry --nextPart2979708.qt17fU5D22 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDoyyMxqA5ziudZT0RAu3YAKDd3WLJjbgu6dHqctCRWFCK7H+0egCcDLSK qzEo/Klk/YGGkLuWtZZ1OCE= =mZ33 -----END PGP SIGNATURE----- --nextPart2979708.qt17fU5D22-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 21:05:36 2005 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 05EFE16A43D; Fri, 16 Dec 2005 21:05:36 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from mail.united-ware.com (am-productions.biz [69.61.164.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D52F43D5F; Fri, 16 Dec 2005 21:05:35 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.100] (am-productions.biz [69.61.164.22]) (authenticated bits=0) by mail.united-ware.com (8.13.4/8.13.4) with ESMTP id jBGL8eL5032535 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 16 Dec 2005 16:08:45 -0500 (EST) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: John Baldwin Date: Fri, 16 Dec 2005 16:07:41 -0500 User-Agent: KMail/1.8.3 References: <200512141720.01572.jhb@freebsd.org> <200512152133.28401.mistry.7@osu.edu> <200512161522.04051.jhb@freebsd.org> In-Reply-To: <200512161522.04051.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart7773695.MfYHKRH1RF"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200512161607.41975.mistry.7@osu.edu> X-Spam-Status: No, score=-10.4 required=5.0 tests=ALL_TRUSTED,BAYES_00, MYFREEBSD2,MYFREEBSD3 autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on mail.united-ware.com X-Virus-Scanned: ClamAV 0.87/1210/Thu Dec 15 10:23:22 2005 on mail.united-ware.com X-Virus-Status: Clean Cc: freebsd-current@freebsd.org Subject: Re: hostb(4) and vgapci(4) 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: Fri, 16 Dec 2005 21:05:36 -0000 --nextPart7773695.MfYHKRH1RF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 16 December 2005 03:22 pm, John Baldwin wrote: > On Thursday 15 December 2005 09:33 pm, Anish Mistry wrote: > > On Thursday 15 December 2005 04:31 pm, you wrote: > > > On Thursday 15 December 2005 12:32 am, Anish Mistry wrote: > > > > On Wednesday 14 December 2005 05:20 pm, John Baldwin wrote: > > > > > I have a patch that is an attempt to untangle a few things > > > > > in relation to Host-PCI bridges and VGA PCI devices.=20 > > > > > Basically, the change is to create a more "real" hostb > > > > > driver as well as a new vgapci driver and to change agp, > > > > > drm, and acpi_video to attach to these drivers. This means > > > > > among other things: > > > > > > > > > > - In theory you can now kldload agp after boot since it > > > > > still has a place to attach to. > > > > > - i830/915 drm is no longer a child of agp, instead both > > > > > become children of vgapci0. > > > > > - You can now use acpi_video with drm as both attach as > > > > > children of vgapci0. - This provides a way for us to > > > > > possibly solve the DPMS problem for suspend/resume > > > > > (including a cleaner way to do the hack dpms patch I posted > > > > > to acpi@ a long while ago that several people still use). > > > > > > > > > > Some other details include: > > > > > > > > > > - agp devices no longer map the _entire_ aperture into > > > > > contiguous KVA meaning that it might be possible now to use > > > > > a 256 MB aperture without panicing - I've added a new > > > > > pci_if.m method for locating a specific capability for a > > > > > PCI device. > > > > > > > > > > I have tested this on my laptop and verified that dri still > > > > > works, but it needs some wider testing, especially the > > > > > i830/i915 case is slightly more complicated. Also, this is > > > > > not going to work with the nvidia-driver currently, but > > > > > that's something that can be fixed in the future. If the > > > > > agp non-mapping does fix the 256 MB aperture issues then I > > > > > will probably MFC that part to RELENG_6. > > > > > > > > > > http://www.FreeBSD.org/~jhb/patches/agp_cvs.patch > > > > > > > > Thank you! It seems to work as advertised. I'm running > > > > mach64 DRM with the DPMS patch acpi_video and they both work. > > > > :) One small problem though. When I unload the acpi_video > > > > module and reload it I get the following: > > > > littleguy# kldload acpi_video > > > > acpi_video0: on vgapci0 > > > > acpi_video1: on vgapci0 > > > > littleguy# kldunload acpi_video > > > > acpi_video0: detached > > > > acpi_video1: detached > > > > littleguy# kldunload acpi_video > > > > kldunload: can't find file acpi_video: No such file or > > > > directory littleguy# kldload acpi_video > > > > acpi_video0: on vgapci0 > > > > acpi_video1: on vgapci0 > > > > acpi_video2: on vgapci0 > > > > littleguy# > > > > It also created multiple sysctls with subsequent loads: > > > > hw.acpi.video.crt0.active: 1 > > > > hw.acpi.video.lcd0.active: 1 > > > > hw.acpi.video.tv0.active: 0 > > > > hw.acpi.video.crt1.active: 1 > > > > hw.acpi.video.lcd1.active: 1 > > > > hw.acpi.video.tv1.active: 0 > > > > hw.acpi.video.crt2.active: 1 > > > > hw.acpi.video.lcd2.active: 1 > > > > hw.acpi.video.tv2.active: 0 > > > > > > Revert just the changes to acpi_video.c and then apply the > > > attached patch to see if it fixes the multiple load issue. > > > > Yes. The patch corrects the problem. > > Actually, can you try a simpler one just to be sure? Thanks. I just enabled witness for my previous problem and got LOR #155, but=20 the lines numbers are slightly different, probably just normal=20 updates. I tried to reproduce it with the old patch, but I couldn't. =20 So it seems that something else triggered it during the kldunload. The current patch works fine. =2D-=20 Anish Mistry --nextPart7773695.MfYHKRH1RF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDoyydxqA5ziudZT0RAtNMAKCQV3X3yBXmLXeeALH3ST+0bRT/yQCgmlpR 6r/d0YRg5XZx98UmXNERc7c= =byvv -----END PGP SIGNATURE----- --nextPart7773695.MfYHKRH1RF-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 21:37:50 2005 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 38A6016A420 for ; Fri, 16 Dec 2005 21:37:50 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 781B743D45 for ; Fri, 16 Dec 2005 21:37:49 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 3965765 for ; Fri, 16 Dec 2005 16:35:51 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jBGLbaIF082363 for ; Fri, 16 Dec 2005 16:37:46 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: current@freebsd.org Date: Fri, 16 Dec 2005 16:36:16 -0500 User-Agent: KMail/1.8.2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512161636.17091.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1210/Thu Dec 15 10:23:22 2005 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: Subject: Anyone use any si(4) cards? 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, 16 Dec 2005 21:37:50 -0000 Does anyone have any si(4) cards that they use? I'm curious because 1) I'd like to know if the si(4) driver works on HEAD, and 2) there is updated firmware for the SIJET cards I'd like someone to test. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 21:38:10 2005 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 5F5C716A426 for ; Fri, 16 Dec 2005 21:38:10 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3044643D58 for ; Fri, 16 Dec 2005 21:38:06 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 3965769 for multiple; Fri, 16 Dec 2005 16:35:53 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jBGLbaIG082363; Fri, 16 Dec 2005 16:37:48 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Andrew Gallatin Date: Fri, 16 Dec 2005 16:38:02 -0500 User-Agent: KMail/1.8.2 References: <17314.60552.595375.783753@grasshopper.cs.duke.edu> <200512161454.22232.jhb@freebsd.org> <17315.10532.603357.165238@grasshopper.cs.duke.edu> In-Reply-To: <17315.10532.603357.165238@grasshopper.cs.duke.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512161638.03037.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1210/Thu Dec 15 10:23:22 2005 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: freebsd-current@freebsd.org Subject: Re: PREEMPTION vs ndisulator 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, 16 Dec 2005 21:38:11 -0000 On Friday 16 December 2005 03:52 pm, Andrew Gallatin wrote: > John Baldwin writes: > > On Friday 16 December 2005 11:34 am, Andrew Gallatin wrote: > > > I'm trying to use an ndis driver on an amd64 machine running > > > FreeBSD/amd64 -current from yesterday. If I enable PREEMPTION, the > > > machine hangs when loading the driver (kldload never returns): > > > > > > ndis0: mem > > > 0xfc000000-0xfcffffff,0xfdf00000-0xfdffffff irq 18 at device 0.0 on > > > pci5 ndis0: NDIS API version: 5.1 > > > > > > > > > Witness detects no problems, and if I disable PREEMPTION, the driver > > > seems to work fine. Is PREEMPTION not safe to be used with the > > > ndisulator, or is there a problem with the ndis driver itself? > > > > > > I've included some very brief debugging info below.. > > > > Looks like an ithread has preempted your driver's start routine. If you > > let it run some more and then break into ddb is the same thread (pid 11) > > still running? Also, which process is pid 11? > > Naturally, I no longer have that kernel :( > > I just built a new, PREEMPTION enabled kernel. Booting in > single user, I see a hang in the irq thread. It seems to > always be in this thread. > > I think the difference is that I don't have the if_sk driver loaded, > which shares that irq. > > Can you remind me how to get irq counts from ddb? It > would be intersting to see if the irq hander was called > repeatedly, or if it was just stuck in the handler. show intrcnt -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 21:44:03 2005 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 CE70316A420 for ; Fri, 16 Dec 2005 21:44:03 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mail2.fluidhosting.com [204.14.90.12]) by mx1.FreeBSD.org (Postfix) with SMTP id 26A3E43D5D for ; Fri, 16 Dec 2005 21:44:02 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 89280 invoked by uid 399); 16 Dec 2005 21:44:00 -0000 Received: from localhost (HELO ?192.168.0.3?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 16 Dec 2005 21:44:00 -0000 Message-ID: <43A3351E.8010005@FreeBSD.org> Date: Fri, 16 Dec 2005 13:43:58 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5 (X11/20051206) MIME-Version: 1.0 To: Jeremie Le Hen References: <200512022006.jB2K67AK078509@repoman.freebsd.org> <20051203004057.GA20872@nagual.pp.ru> <4390EFB6.3090307@FreeBSD.org> <20051203012324.GA34147@nagual.pp.ru> <4390F9A2.208@FreeBSD.org> <20051216013955.GW3512@obiwan.tataz.chchile.org> In-Reply-To: <20051216013955.GW3512@obiwan.tataz.chchile.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.ORG Subject: Re: cvs commit: src/etc rc rc.shutdown rc.subr src/etc/rc.d localpkg src/sys/sys param.h 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, 16 Dec 2005 21:44:04 -0000 Jeremie Le Hen wrote: > When I first read your mail on arch@ I didn't think about it, but now > I'm reading this thread, it stirs my mind. RELENG_6 is supposed to > be very stable. Though the ultimate stability would be to stay in > RELENG_6_0, I think MFC'ing those changes to RELENG_6 would cause much > pain to system administrators who will be upgrading from 6.0 to 6.1 if > they don't not update their apache13 port accordingly. Thank you for putting more thought into this topic. :) Your concerns are valid, and that is why the code was changed shortly after I introduced it into HEAD to run all scripts in a subshell, which is what was happening prior to the changes being introduced. The only changes that are present now are to the order in which the scripts are run at boot time, and while there have been no reports of problems since the change I mentioned above was made, any problems that do exist in that area will need to be addressed in any case, since that is fundamental to what is being added (the ability to run local boot scripts in the base rcorder). There is another aspect to this that you should be aware of. A group of stalwart developers have stepped forward and agreed to work on converting the boot scripts that are still in the old style, and helping to fix any of the new style scripts that have problems. They are also working on changes to the ports infrastructure to handle installing the boot scripts as foo instead of foo.sh on RELENG_6 and HEAD systems that have already had the update. Meanwhile, while this work is in progress, all scripts will still be run in a subshell, so there is virtually zero danger that a wonky script will cause the boot to fail. I hope that this information helps you feel more comfortable with this change. I agree that we want to keep FreeBSD's standards high, and that we don't want to violate the release engineering principles that our users have come to rely on. That is why this change will not be ported back to RELENG_5. On the other hand, this is still early enough in the release cycle for RELENG_6, and there is enough time between now and when the 6.1 release will be cut to ferret out any remaining problems, that we feel it's safe to move forward with this. And, if it turns out that I'm wrong, we can easily back the changes out in RELENG_6 and keep this change on hold for the 7.x-RELEASE cycle. Regards, Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 21:54:36 2005 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 8CAE616A41F for ; Fri, 16 Dec 2005 21:54:36 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF94B43D53 for ; Fri, 16 Dec 2005 21:54:35 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 3966801 for multiple; Fri, 16 Dec 2005 16:52:34 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jBGLsSax083701; Fri, 16 Dec 2005 16:54:28 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Anish Mistry Date: Fri, 16 Dec 2005 16:38:58 -0500 User-Agent: KMail/1.8.2 References: <200512161237.15148.mistry.7@osu.edu> <200512161511.10903.jhb@freebsd.org> <200512161527.34667.mistry.7@osu.edu> In-Reply-To: <200512161527.34667.mistry.7@osu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512161638.58917.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1210/Thu Dec 15 10:23:22 2005 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=4.2 tests=ALL_TRUSTED,BIZ_TLD autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: freebsd-current@freebsd.org Subject: Re: Reproducable Panic on CURRENT and 6.0-RELEASE 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, 16 Dec 2005 21:54:36 -0000 On Friday 16 December 2005 03:27 pm, Anish Mistry wrote: > On Friday 16 December 2005 03:11 pm, you wrote: > > On Friday 16 December 2005 12:37 pm, Anish Mistry wrote: > > > Here is the offending program/code. The interesting program is > > > avidemux_2.1_branch_anish/avidemux/avidemux2. > > > (It is compiled for CURRENT, and I left all the object code stuff > > > in so it's a bit large 21MB) > > > http://am-productions.biz/docs/avidemux_2.1_branch_anish.tgz > > > > > > First you'll need to compile spidermonkey to be threadsafe so add > > > the following to your lang/spidermonkey/Makefile before > > > installing it: LIB_DEPENDS= nspr4.1:${PORTSDIR}/devel/nspr > > > MAKE_ARGS+= JS_THREADSAFE=YES LDFLAGS="-L${LOCALBASE}/lib > > > -lpthread -lm" > > > CFLAGS+= -I${LOCALBASE}/include/nspr > > > > > > Once a threadsafe spidermonkey is installed to kill the machine > > > you'll need to: > > > cd avidemux_2.1_branch_anish/avidemux > > > ./avidemux2 --run new-features-test.js > > > > > > On CURRENT: > > > kernel trap 12 with interrupts disabled > > > > > > Fatal trap 12: page fault while in kernel mode > > > fault virtual address = 0x68 > > > fault code = supervisor read, page not present > > > instruction pointer = 0x20:0xc04e6f36 > > > stack pointer = 0x28:0xcc9edb3c > > > frame pointer = 0x28:0xcc9edbb0 > > > code segment = base 0x0, limit 0xfffff, type 0x1b > > > = DPL 0, pres 1, def32 1, gran 1 > > > processor eflags = resume, IOPL = 0 > > > current process = 798 (gdb) > > > trap number = 12 > > > panic: page fault > > > > > > #0 doadump () at pcpu.h:165 > > > #1 0xc04bb7eb in boot (howto=260) > > > at /usr/src/sys/kern/kern_shutdown.c:399 > > > #2 0xc04bb353 in panic (fmt=0xc06069a7 "%s") > > > at /usr/src/sys/kern/kern_shutdown.c:555 > > > #3 0xc05e91ba in trap_fatal (frame=0xcc9edafc, eva=104) > > > at /usr/src/sys/i386/i386/trap.c:862 > > > #4 0xc05e96d9 in trap (frame= > > > {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -1032878460, > > > tf_esi = 1, tf_ebp = -862004304, tf_isp = -862004440, tf_ebx = > > > -1033297504, tf_edx = -1033987232, tf_ecx = 4, tf_eax = 0, > > > tf_trapno = 12, tf_err = 0, tf_eip = -1068601546, tf_cs = 32, > > > tf_eflags = 65687, tf_esp = -1032878356, tf_ss = -1067380424}) > > > at /usr/src/sys/i386/i386/trap.c:273 > > > #5 0xc05db6fa in calltrap () > > > at /usr/src/sys/i386/i386/exception.s:137 > > > #6 0xc04e6f36 in kern_ptrace (td=0xc25e9b60, req=10, pid=1, > > > addr=0x0, data=17) > > > at /usr/src/sys/kern/sys_process.c:802 > > > > On HEAD this is: > > p->p_xthread->td_flags &= ~TDF_XSIG; > > > > If two threads called kern_ptrace() with the same PID and this > > could happen. Hmm, I have no idea how p_xthread is supposed to not > > be racey here in fact. It would be helpful to know what PTRACE > > action it it is trying to do and maybe a KTR trace of the various > > ptrace events leading up to this condition. I have no idea what > > thread you are supposed to act on if p_xthread is NULL either. > > How would I do this? My kdb/ddb skills are prettymuch limited to > getting a backtrace. You could add some new KTR tracepoints to log each request into kern_ptrace() and then do a 'show ktr' at the ddb prompt. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 21:43:51 2005 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 D903216A41F; Fri, 16 Dec 2005 21:43:51 +0000 (GMT) (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 D7FF243D5C; Fri, 16 Dec 2005 21:43:50 +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.4/8.13.4) with ESMTP id jBGLhj1j014345; Fri, 16 Dec 2005 22:43:45 +0100 Received: from localhost (ggajic@localhost) by afrodita.rcub.bg.ac.yu (8.13.4/8.13.4/Submit) with ESMTP id jBGLhgIl014334; Fri, 16 Dec 2005 22:43:45 +0100 Date: Fri, 16 Dec 2005 22:43:42 +0100 (CET) From: Goran Gajic To: John Baldwin In-Reply-To: <200512161525.12656.jhb@freebsd.org> Message-ID: References: <200512151356.41550.jhb@freebsd.org> <200512161525.12656.jhb@freebsd.org> 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: Fri, 16 Dec 2005 21:56:46 +0000 Cc: freebsd-current@freebsd.org Subject: Re: skype-1.2.0.18-static for linux and FreeBSD 7.0 CURRENT 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, 16 Dec 2005 21:43:52 -0000 Without mentioned DEBUG options everything seems to be ok except when skype and xmms are running together. Then this appears occasionaly: lock order reversal: 1st 0xc245a100 pcm0 (sound cdev) @ /usr/src/sys/modules/sound/sound/../../../dev/sound/pcm/dsp.c:277 2nd 0xc245a200 pcm0:record:0 (pcm record channel) @ /usr/src/sys/modules/sound/sound/../../../dev/sound/pcm/dsp.c:290 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c09574a8,c0957430,c090b6e4) at kdb_backtrace+0x29 witness_checkorder(c245a200,9,c24aab3b,122) at witness_checkorder+0x580 _mtx_lock_flags(c245a200,0,c24aab3b,122,1) at _mtx_lock_flags+0x5b dsp_open(c23b3a00,3,2000,c2b49000,c0948c6c) at dsp_open+0x2fd giant_open(c23b3a00,3,2000,c2b49000,c23b3a00) at giant_open+0x30 devfs_open(d26b49f8) at devfs_open+0x223 VOP_OPEN_APV(c0903fc0,d26b49f8) at VOP_OPEN_APV+0x7e vn_open_cred(d26b4b60,d26b4c60,464,c2a46180,23) at vn_open_cred+0x3fe vn_open(d26b4b60,d26b4c60,464,23,d26b4b00) at vn_open+0x1e kern_open(c2b49000,c22f5800,1,3,bf1ff674) at kern_open+0xb6 linux_open(c2b49000,d26b4d04,c,c2b49000,d26b4d30) at linux_open+0xad syscall(3b,3b,88d003b,8d51904,0) at syscall+0x27e Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (5, Linux ELF, linux_open), eip = 0x28fef6ab, esp = 0xbf1ff630, ebp = 0xbf1ff6c4 --- Maybe this has something to do with problem someone mentioned with skype and kde? Btw. this has happened while I was running skype+xmms under mwm. Regards, gg. On Fri, 16 Dec 2005, John Baldwin wrote: > On Friday 16 December 2005 04:13 am, Goran Gajic wrote: > > Ah, I think the stack_save() stuff in 6.0 is buggy. I think there's a fix in > HEAD. I would just turn those DEBUG options off for now. > > From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 22:12:27 2005 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 D358416A41F; Fri, 16 Dec 2005 22:12:27 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2817943D5C; Fri, 16 Dec 2005 22:12:27 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.4/8.13.4) with ESMTP id jBGMCQET005033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Dec 2005 17:12:26 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id jBGMCLd7036313; Fri, 16 Dec 2005 17:12:21 -0500 (EST) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17315.15301.316482.649755@grasshopper.cs.duke.edu> Date: Fri, 16 Dec 2005 17:12:21 -0500 (EST) To: John Baldwin In-Reply-To: <200512161638.03037.jhb@freebsd.org> References: <17314.60552.595375.783753@grasshopper.cs.duke.edu> <200512161454.22232.jhb@freebsd.org> <17315.10532.603357.165238@grasshopper.cs.duke.edu> <200512161638.03037.jhb@freebsd.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: freebsd-current@freebsd.org Subject: Re: PREEMPTION vs ndisulator 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, 16 Dec 2005 22:12:28 -0000 John Baldwin writes: > On Friday 16 December 2005 03:52 pm, Andrew Gallatin wrote: > > John Baldwin writes: > > > On Friday 16 December 2005 11:34 am, Andrew Gallatin wrote: > > > Looks like an ithread has preempted your driver's start routine. If you > > > let it run some more and then break into ddb is the same thread (pid 11) > > > still running? Also, which process is pid 11? It looks like the ithread is looping: db> show intrcnt irq4: sio0 1007 irq14: ata0 33 irq17: fwohci0 1 irq18: ndis0 757379 irq21: ohci0+ 382 cpu0: timer 1254872 db> c [halt - sent] KDB: enter: Line break on console [thread pid 76 tid 100049 ] Stopped at kdb_enter+0x2f: nop db> show intrcnt irq4: sio0 1009 irq14: ata0 33 irq17: fwohci0 1 irq18: ndis0 992263 irq21: ohci0+ 382 cpu0: timer 1259314 I know the interrupt is actually disabled in the DPC, and not in the interrupt handler. That's probably the problem. The DPC is just never getting scheduled, so the interrupt line is never lowered. Thanks! Drew From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 22:31:21 2005 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 9EFA516A41F for ; Fri, 16 Dec 2005 22:31:21 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0083143D60 for ; Fri, 16 Dec 2005 22:31:15 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper [212.12.50.230]) by schlepper.zs64.net (8.13.3/8.12.9) with ESMTP id jBGMVFsU032122; Fri, 16 Dec 2005 23:31:15 +0100 (CET) (envelope-from cracauer@schlepper.zs64.net) Received: (from cracauer@localhost) by schlepper.zs64.net (8.13.3/8.12.9/Submit) id jBGMV6ba032120; Fri, 16 Dec 2005 17:31:06 -0500 (EST) (envelope-from cracauer) Date: Fri, 16 Dec 2005 17:31:06 -0500 From: Martin Cracauer To: "Bjoern A. Zeeb" Message-ID: <20051216173106.B31803@cons.org> References: <20051209175607.C23668@maildrop.int.zabbadoz.net> <20051210125221.M23668@maildrop.int.zabbadoz.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20051210125221.M23668@maildrop.int.zabbadoz.net>; from bzeeb-lists@lists.zabbadoz.net on Sat, Dec 10, 2005 at 12:56:33PM +0000 Cc: FreeBSD current mailing list Subject: Re: nve(4) patch - please test! 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, 16 Dec 2005 22:31:21 -0000 Sorry for being late. The code that has been committed to -current works fine for me (DFI NF4 SLI-DR). It occasionally prints a timeout message on startup (long into userland start), but it works fine and doesn't print more messages. Performance is lower than Linux (about 70 MB/sec versus Linux which gets the 108 MB/sec). Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/ From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 22:43:55 2005 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 2F7B516A422 for ; Fri, 16 Dec 2005 22:43:55 +0000 (GMT) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id C81B943D82 for ; Fri, 16 Dec 2005 22:43:44 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.13.4/8.13.4) with ESMTP id jBGMhVMn097718; Fri, 16 Dec 2005 17:43:31 -0500 (EST) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.3/8.13.3) with ESMTP id jBGMhPUX070137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Dec 2005 17:43:26 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <6.2.3.4.0.20051216174201.07cf0728@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Fri, 16 Dec 2005 17:43:05 -0500 To: Martin Cracauer From: Mike Tancsa In-Reply-To: <20051216173106.B31803@cons.org> References: <20051209175607.C23668@maildrop.int.zabbadoz.net> <20051210125221.M23668@maildrop.int.zabbadoz.net> <20051216173106.B31803@cons.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: FreeBSD current mailing list Subject: Re: nve(4) patch - please test! 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, 16 Dec 2005 22:43:55 -0000 At 05:31 PM 16/12/2005, Martin Cracauer wrote: >Performance is lower than Linux (about 70 MB/sec versus Linux which >gets the 108 MB/sec). How do you get 108MB/s out of a 100Mb nic ? ---Mike From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 22:46:39 2005 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 742BC16A420 for ; Fri, 16 Dec 2005 22:46:39 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 055D843D4C for ; Fri, 16 Dec 2005 22:46:37 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper [212.12.50.230]) by schlepper.zs64.net (8.13.3/8.12.9) with ESMTP id jBGMkaPF032542; Fri, 16 Dec 2005 23:46:36 +0100 (CET) (envelope-from cracauer@schlepper.zs64.net) Received: (from cracauer@localhost) by schlepper.zs64.net (8.13.3/8.12.9/Submit) id jBGMkaPT032541; Fri, 16 Dec 2005 17:46:36 -0500 (EST) (envelope-from cracauer) Date: Fri, 16 Dec 2005 17:46:36 -0500 From: Martin Cracauer To: Mike Tancsa Message-ID: <20051216174636.A32507@cons.org> References: <20051209175607.C23668@maildrop.int.zabbadoz.net> <20051210125221.M23668@maildrop.int.zabbadoz.net> <20051216173106.B31803@cons.org> <6.2.3.4.0.20051216174201.07cf0728@64.7.153.2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <6.2.3.4.0.20051216174201.07cf0728@64.7.153.2>; from mike@sentex.net on Fri, Dec 16, 2005 at 05:43:05PM -0500 Cc: Martin Cracauer , FreeBSD current mailing list Subject: Re: nve(4) patch - please test! 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, 16 Dec 2005 22:46:41 -0000 Mike Tancsa wrote on Fri, Dec 16, 2005 at 05:43:05PM -0500: > At 05:31 PM 16/12/2005, Martin Cracauer wrote: > > >Performance is lower than Linux (about 70 MB/sec versus Linux which > >gets the 108 MB/sec). > > How do you get 108MB/s out of a 100Mb nic ? Uh? It's GbE. The NVidia soutbridge GbE against Intel CSA on an i875 board. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/ From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 22:56:57 2005 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 CB7AF16A41F for ; Fri, 16 Dec 2005 22:56:57 +0000 (GMT) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F7F743D58 for ; Fri, 16 Dec 2005 22:56:56 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.13.4/8.13.4) with ESMTP id jBGMuscu000444; Fri, 16 Dec 2005 17:56:54 -0500 (EST) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.3/8.13.3) with ESMTP id jBGMumfT070171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Dec 2005 17:56:48 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <6.2.3.4.0.20051216174923.079679f8@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Fri, 16 Dec 2005 17:56:28 -0500 To: Martin Cracauer From: Mike Tancsa In-Reply-To: <20051216174636.A32507@cons.org> References: <20051209175607.C23668@maildrop.int.zabbadoz.net> <20051210125221.M23668@maildrop.int.zabbadoz.net> <20051216173106.B31803@cons.org> <6.2.3.4.0.20051216174201.07cf0728@64.7.153.2> <20051216174636.A32507@cons.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: FreeBSD current mailing list Subject: Re: nve(4) patch - please test! 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, 16 Dec 2005 22:56:58 -0000 At 05:46 PM 16/12/2005, Martin Cracauer wrote: >Mike Tancsa wrote on Fri, Dec 16, 2005 at 05:43:05PM -0500: > > At 05:31 PM 16/12/2005, Martin Cracauer wrote: > > > > >Performance is lower than Linux (about 70 MB/sec versus Linux which > > >gets the 108 MB/sec). > > > > How do you get 108MB/s out of a 100Mb nic ? > >Uh? > >It's GbE. > >The NVidia soutbridge GbE against Intel CSA on an i875 board. Strange, I was just going by the MAN page which I guess is a bit misleading. Dont really use the cards, so I never bothered to check them in a gigE port. http://www.freebsd.org/cgi/man.cgi?query=nve&apropos=0&sektion=0&manpath=FreeBSD+6.0-stable&format=html The nve driver supports the following media types: autoselect Enable autoselection of the media type and options. 10baseT/UTP Set 10Mbps operation. 100baseTX Set 100Mbps (Fast Ethernet) operation. The nve driver supports the following media options: full-duplex Set full duplex operation. For more information on configuring this device, see ifconfig(8). From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 23:13:00 2005 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 1570A16A41F for ; Fri, 16 Dec 2005 23:13:00 +0000 (GMT) (envelope-from dunstan@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [80.48.250.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3370743D66 for ; Fri, 16 Dec 2005 23:12:58 +0000 (GMT) (envelope-from dunstan@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [80.48.250.4]) by freebsd.czest.pl (8.12.10/8.12.9) with ESMTP id jBGNFPPx059138 for ; Fri, 16 Dec 2005 23:15:26 GMT (envelope-from dunstan@freebsd.czest.pl) Received: (from dunstan@localhost) by freebsd.czest.pl (8.13.4/8.12.9/Submit) id jBGNFNwX059137 for freebsd-current@freebsd.org; Fri, 16 Dec 2005 23:15:23 GMT (envelope-from dunstan) Date: Fri, 16 Dec 2005 23:15:22 +0000 From: "Wojciech A. Koszek" To: freebsd-current@freebsd.org Message-ID: <20051216231521.GA59072@FreeBSD.czest.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: [PATCH] sbuf_copyin() can return number of bytes copied from user-space 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, 16 Dec 2005 23:13:00 -0000 Hello, Function sbuf_copyin() at current stage makes no use of "done" argument, used internally. "done", which is a result of copying string from user-space address with copyinstr(), contains number of bytes copied. We can easily extend current implementation: http://freebsd.czest.pl/dunstan/FreeBSD/sbuf_copyin.0.patch I'd like to receive comments from people making use of sbuf_copyin() in their sources. This change will probably make it necessary to compare return value with -1 in order to detect failure. At current stage, existing FreeBSD code uses sbuf_copyin in two files, both ignoring return value, so this shouldn't break anything. If noone will object, above change will probably be commited. Comments are welcome! -- * Wojciech A. Koszek && dunstan@FreeBSD.czest.pl From owner-freebsd-current@FreeBSD.ORG Fri Dec 16 23:15:17 2005 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 03B1616A420; Fri, 16 Dec 2005 23:15:17 +0000 (GMT) (envelope-from antoine@peanut.dreadbsd.org) Received: from barton.dreadbsd.org (peanut.dreadbsd.org [82.67.196.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 38E6243D62; Fri, 16 Dec 2005 23:15:11 +0000 (GMT) (envelope-from antoine@peanut.dreadbsd.org) Received: from barton.dreadbsd.org (localhost [127.0.0.1]) by barton.dreadbsd.org (8.13.4/8.13.4) with ESMTP id jBGNF8vq024550; Sat, 17 Dec 2005 00:15:08 +0100 (CET) (envelope-from antoine@peanut.dreadbsd.org) Received: (from antoine@localhost) by barton.dreadbsd.org (8.13.4/8.13.1/Submit) id jBGNF7wo024549; Sat, 17 Dec 2005 00:15:07 +0100 (CET) (envelope-from antoine) Date: Sat, 17 Dec 2005 00:15:07 +0100 From: Antoine Brodin To: John Baldwin Message-Id: <20051217001507.71b04041.antoine.brodin@laposte.net> In-Reply-To: <200512161525.12656.jhb@freebsd.org> References: <200512151356.41550.jhb@freebsd.org> <200512161525.12656.jhb@freebsd.org> X-Mailer: Sylpheed version 2.0.4 (GTK+ 2.8.9; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, ggajic@afrodita.rcub.bg.ac.yu Subject: Re: skype-1.2.0.18-static for linux and FreeBSD 7.0 CURRENT 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, 16 Dec 2005 23:15:17 -0000 John Baldwin wrote: > On Friday 16 December 2005 04:13 am, Goran Gajic wrote: > > On Thu, 15 Dec 2005, John Baldwin wrote: > > > If you are in X this is probably a panic (currently the kernel doesn't > > > create a coredump while you are in X which is a bug). Can you hook up a > > > serial console and use that to get the panic message? > > > > Yes, here is capture from minicom: > > > > drm0: port 0xc000-0xc0ff mem > > 0xe8000000-0xefffffff,0xff8f0000-0xff8fffff irq 16 at device 0.0 on pci1 > > info: [drm] AGP at 0xf8000000 64MB > > info: [drm] Initialized radeon 1.19.0 20050911 > > info: [drm] Loading R200 Microcode > > lock order reversal: > > 1st 0xc366e21c vnode interlock (vnode interlock) @ kern/vfs_vnops.c:791 > > 2nd 0xc3b8fb44 process lock (process lock) @ i386/i386/trap.c:742 > > KDB: stack backtrace: > > kdb_backtrace(0,ffffffff,c0975450,c0975900,c0927544) at kdb_backtrace+0x29 > > witness_checkorder(c3b8fb44,9,c08be5a5,2e6) at witness_checkorder+0x580 > > _mtx_lock_flags(c3b8fb44,0,c08be59c,2e6,c3b91780) at _mtx_lock_flags+0x5b > > trap_pfault(dbc9da28,0,3) at trap_pfault+0xb2 > > trap(dbc90008,c0680028,c09b0028,c3b91780,dbc9da84) at trap+0x3cd > > calltrap() at calltrap+0x5 > > --- trap 0xc, eip = 0xc081799c, esp = 0xdbc9da68, ebp = 0xdbc9da70 --- > > stack_save(dbc9da84) at stack_save+0x1c > > Ah, I think the stack_save() stuff in 6.0 is buggy. I think there's a fix in > HEAD. I would just turn those DEBUG options off for now. Hi, Could you try the patch at : http://bsd.miki.eu.org/~antoine/stack/stack-12-16.diff Cheers, Antoine From owner-freebsd-current@FreeBSD.ORG Sat Dec 17 00:01:59 2005 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 D23DF16A41F; Sat, 17 Dec 2005 00:01:59 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from mail.united-ware.com (am-productions.biz [69.61.164.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 426EC43D49; Sat, 17 Dec 2005 00:01:59 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.100] (am-productions.biz [69.61.164.22]) (authenticated bits=0) by mail.united-ware.com (8.13.4/8.13.4) with ESMTP id jBH0546f035027 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 16 Dec 2005 19:05:10 -0500 (EST) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: John Baldwin Date: Fri, 16 Dec 2005 19:03:51 -0500 User-Agent: KMail/1.8.3 References: <200512161237.15148.mistry.7@osu.edu> <200512161527.34667.mistry.7@osu.edu> <200512161638.58917.jhb@freebsd.org> In-Reply-To: <200512161638.58917.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2528648.6EAe5K8Tst"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200512161904.04913.mistry.7@osu.edu> X-Spam-Status: No, score=-8.4 required=5.0 tests=ALL_TRUSTED, BAYES_00, BIZ_TLD, MYFREEBSD2,MYFREEBSD3 autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on mail.united-ware.com X-Virus-Scanned: ClamAV 0.87/1210/Thu Dec 15 10:23:22 2005 on mail.united-ware.com X-Virus-Status: Clean Cc: freebsd-current@freebsd.org Subject: Re: Reproducable Panic on CURRENT and 6.0-RELEASE 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, 17 Dec 2005 00:02:00 -0000 --nextPart2528648.6EAe5K8Tst Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 16 December 2005 04:38 pm, you wrote: > On Friday 16 December 2005 03:27 pm, Anish Mistry wrote: > > On Friday 16 December 2005 03:11 pm, you wrote: > > > On Friday 16 December 2005 12:37 pm, Anish Mistry wrote: > > > > Here is the offending program/code. The interesting program > > > > is avidemux_2.1_branch_anish/avidemux/avidemux2. > > > > (It is compiled for CURRENT, and I left all the object code > > > > stuff in so it's a bit large 21MB) > > > > http://am-productions.biz/docs/avidemux_2.1_branch_anish.tgz > > > > > > > > First you'll need to compile spidermonkey to be threadsafe so > > > > add the following to your lang/spidermonkey/Makefile before > > > > installing it: LIB_DEPENDS=3D nspr4.1:${PORTSDIR}/devel/nspr > > > > MAKE_ARGS+=3D JS_THREADSAFE=3DYES LDFLAGS=3D"-L${LOCALBASE}/lib > > > > -lpthread -lm" > > > > CFLAGS+=3D -I${LOCALBASE}/include/nspr > > > > > > > > Once a threadsafe spidermonkey is installed to kill the > > > > machine you'll need to: > > > > cd avidemux_2.1_branch_anish/avidemux > > > > ./avidemux2 --run new-features-test.js > > > > > > > > On CURRENT: > > > > kernel trap 12 with interrupts disabled > > > > > > > > Fatal trap 12: page fault while in kernel mode > > > > fault virtual address =3D 0x68 > > > > fault code =3D supervisor read, page not present > > > > instruction pointer =3D 0x20:0xc04e6f36 > > > > stack pointer =3D 0x28:0xcc9edb3c > > > > frame pointer =3D 0x28:0xcc9edbb0 > > > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > > > > =3D DPL 0, pres 1, def32 1, gran 1 > > > > processor eflags =3D resume, IOPL =3D 0 > > > > current process =3D 798 (gdb) > > > > trap number =3D 12 > > > > panic: page fault > > > > > > > > #0 doadump () at pcpu.h:165 > > > > #1 0xc04bb7eb in boot (howto=3D260) > > > > at /usr/src/sys/kern/kern_shutdown.c:399 > > > > #2 0xc04bb353 in panic (fmt=3D0xc06069a7 "%s") > > > > at /usr/src/sys/kern/kern_shutdown.c:555 > > > > #3 0xc05e91ba in trap_fatal (frame=3D0xcc9edafc, eva=3D104) > > > > at /usr/src/sys/i386/i386/trap.c:862 > > > > #4 0xc05e96d9 in trap (frame=3D > > > > {tf_fs =3D 8, tf_es =3D 40, tf_ds =3D 40, tf_edi =3D > > > > -1032878460, tf_esi =3D 1, tf_ebp =3D -862004304, tf_isp =3D > > > > -862004440, tf_ebx =3D -1033297504, tf_edx =3D -1033987232, > > > > tf_ecx =3D 4, tf_eax =3D 0, tf_trapno =3D 12, tf_err =3D 0, tf_eip = =3D > > > > -1068601546, tf_cs =3D 32, tf_eflags =3D 65687, tf_esp =3D > > > > -1032878356, tf_ss =3D -1067380424}) at > > > > /usr/src/sys/i386/i386/trap.c:273 > > > > #5 0xc05db6fa in calltrap () > > > > at /usr/src/sys/i386/i386/exception.s:137 > > > > #6 0xc04e6f36 in kern_ptrace (td=3D0xc25e9b60, req=3D10, pid=3D1, > > > > addr=3D0x0, data=3D17) > > > > at /usr/src/sys/kern/sys_process.c:802 > > > > > > On HEAD this is: > > > p->p_xthread->td_flags &=3D ~TDF_XSIG; > > > > > > If two threads called kern_ptrace() with the same PID and this > > > could happen. Hmm, I have no idea how p_xthread is supposed to > > > not be racey here in fact. It would be helpful to know what > > > PTRACE action it it is trying to do and maybe a KTR trace of > > > the various ptrace events leading up to this condition. I have > > > no idea what thread you are supposed to act on if p_xthread is > > > NULL either. > > > > How would I do this? My kdb/ddb skills are prettymuch limited to > > getting a backtrace. > > You could add some new KTR tracepoints to log each request into > kern_ptrace() and then do a 'show ktr' at the ddb prompt. I put a KTR_GEN tracepoint in kern_ptrace and only got 1 entry in the=20 log: =46atal trap 12: page fault while in kernel mode fault virtual address =3D 0x68 fault code =3D supervisor read, page not present instruction pointer =3D 0x20:0xc04ed896 stack pointer =3D 0x28:0xcc9a9b3c frame pointer =3D 0x28:0xcc9a9bb0 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D resume, IOPL =3D 0 current process =3D 697 (gdb) [thread pid 697 tid 100073 ] Stopped at kern_ptrace+0xef6: movl 0x68(%eax),%ebx db> show ktr 0 (0xc2354b60): kern_ptrace: td=3D0xc2354b60 req=3D0xa pid=3D695 addr=3D=3D= 0x0=20 data=3D=3D0x0 =2D-- End of trace buffer --- db>=20 The full alltrace: http://am-productions.biz/docs/ktr-trace.txt.gz =46rom alltrace results for pid 695 is: db> bt Tracing pid 697 tid 100073 td 0xc2354b60 kern_ptrace(c2354b60,a,2b7,0,11) at kern_ptrace+0xef6 ptrace(c2354b60,cc9a9d04,4,0,23) at ptrace+0x40 syscall(3b,3b,3b,81e9438,2b7) at syscall+0x19a Xint0x80_syscall() at Xint0x80_syscall+0x1f =2D-- syscall (26, FreeBSD ELF32, ptrace), eip =3D 0x282c1a6b, esp =3D=20 0xbfbfe468, ebp =3D 0xbfbfe480 --- db> alltrace Tracing command gdb pid 697 tid 100073 td 0xc2354b60 kern_ptrace(c2354b60,a,2b7,0,11) at kern_ptrace+0xef6 ptrace(c2354b60,cc9a9d04,4,0,23) at ptrace+0x40 syscall(3b,3b,3b,81e9438,2b7) at syscall+0x19a Xint0x80_syscall() at Xint0x80_syscall+0x1f =2D-- syscall (26, FreeBSD ELF32, ptrace), eip =3D 0x282c1a6b, esp =3D=20 0xbfbfe468, ebp =3D 0xbfbfe480 --- Tracing command avidemux2 pid 696 tid 100072 td 0xc2354d00 sched_switch(c2354d00,0,1,c8d6d692,17b1f6d8) at sched_switch+0xb5 mi_switch(1,0,c2354d00,c06c5510,cc9aca9c) at mi_switch+0x259 sleepq_switch(c2354d00,c06c5510,cc9acadc,c0496ca8,c06c5510) at=20 sleepq_switch+0xc2 sleepq_timedwait_sig(c06c5510,0,c06c5510,c06c5510,65) at=20 sleepq_timedwait_sig+0xd cv_timedwait_sig(c06c5510,c06c54f4,65) at cv_timedwait_sig+0x178 kern_select(c2354d00,14,bfbfdd80,0,0) at kern_select+0x55a select(c2354d00,cc9acd04,5,0,6) at select+0x2c syscall(3b,3b,3b,94f1000,bfbfdc68) at syscall+0x19a Xint0x80_syscall() at Xint0x80_syscall+0x1f =2D-- syscall (93, FreeBSD ELF32, select), eip =3D 0x29085397, esp =3D=20 0xbfbfdc08, ebp =3D 0xbfbfdc38 --- Tracing command avidemux2 pid 695 tid 100080 td 0xc2635680 sched_switch(c2635680,0,2,2ffd8312,ea5ba7fb) at sched_switch+0xb5 mi_switch(2,0,c2635680,ac,c0619941) at mi_switch+0x259 uio_yield(0,0,47000,0,c25f0074) at uio_yield+0x72 vn_rdwr_inchunks(1,c2642840,89b1000,b37000,47000,0,0,101,c2640c00,0,0,c2635= 680)=20 at vn_rdwr_inchunks+0xb4 elf32_coredump(c2635680,c2642840,ffffffff,7fffffff) at=20 elf32_coredump+0x132 sigexit(c2635680,6,c2634294,8,c0618e65) at sigexit+0x8df kse_thr_interrupt(c2635680,cca0dd04,3,0,0) at kse_thr_interrupt+0x10c syscall(3b,3b,3b,20,0) at syscall+0x19a Xint0x80_syscall() at Xint0x80_syscall+0x1f =2D-- syscall (382, FreeBSD ELF32, kse_thr_interrupt), eip =3D 0x28fe5603,= =20 esp =3D 0xbf8fdaec, ebp =3D 0xbf8fdb60 --- Tracing command avidemux2 pid 695 tid 100078 td 0xc26359c0 sched_switch(c26359c0,c2635820,1,82b08812,3b03415f) at=20 sched_switch+0xb5 mi_switch(1,c2635820,0,c26359c0,cca13ba0) at mi_switch+0x259 sleepq_switch(0,cca13bd0,c04c5896,c263422c,0) at sleepq_switch+0xc2 sleepq_wait_sig(c263422c,0,100,c0618588,31f) at sleepq_wait_sig+0xc msleep(c263422c,c2634294,15c,c0620da6,0) at msleep+0x356 kern_wait(c26359c0,2b8,cca13c28,0,0) at kern_wait+0x350 wait4(c26359c0,cca13d04,4,0,0) at wait4+0x2d syscall(3b,3b,3b,94f1000,bfbfde90) at syscall+0x19a Xint0x80_syscall() at Xint0x80_syscall+0x1f =2D-- syscall (7, FreeBSD ELF32, wait4), eip =3D 0x2903a067, esp =3D=20 0xbfbfdc04, ebp =3D 0xbfbfdc1c --- Tracing command avidemux2 pid 695 tid 100077 td 0xc2635b60 sched_switch(c2635b60,0,1,cbf0f192,13141da1) at sched_switch+0xb5 mi_switch(1,0,0,c2635b60,cca16c04) at mi_switch+0x259 sleepq_switch(0,c2635b60,cca16c38,c04c595a,c26342b4) at=20 sleepq_switch+0xc2 sleepq_timedwait_sig(c26342b4) at sleepq_timedwait_sig+0xd msleep(c26342b4,c2634294,168,c0618e91,bb9) at msleep+0x41a kse_release(c2635b60,cca16d04,1,0,1) at kse_release+0xb8 syscall(3b,3b,3b,81,97c3200) at syscall+0x19a Xint0x80_syscall() at Xint0x80_syscall+0x1f =2D-- syscall (383, FreeBSD ELF32, kse_release), eip =3D 0x28fe55c3, esp = =3D=20 0xbf9fef78, ebp =3D 0xbf9fefa8 --- =2D-=20 Anish Mistry --nextPart2528648.6EAe5K8Tst Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDo1X0xqA5ziudZT0RAle0AKDg7koTKpjPbcF26IMkntavMVPbxwCfe7Hx JJcSDRCP9/r/RpTvqTs8ZBw= =q3R8 -----END PGP SIGNATURE----- --nextPart2528648.6EAe5K8Tst-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 17 00:43:22 2005 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 3D68616A420 for ; Sat, 17 Dec 2005 00:43:22 +0000 (GMT) (envelope-from joao.barros@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 266F943D5A for ; Sat, 17 Dec 2005 00:43:21 +0000 (GMT) (envelope-from joao.barros@gmail.com) Received: by xproxy.gmail.com with SMTP id t12so593733wxc for ; Fri, 16 Dec 2005 16:43:20 -0800 (PST) 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=CObsC0GR/TPA9P/zt6RYOHaSgRn6wzcG/3NMyUuOn+7Eq29wdVbIF0viWCfuqqmMauRxc++oUg/J1wti/GOyUK+Qh+UwObzpkb590ugqsL41/ws08X/3kxx5c1Gju/5rlwiiU02SgQ/QuW4/xpbJxs9iDTBFD5lplCE0pCr+KAQ= Received: by 10.70.87.2 with SMTP id k2mr1716227wxb; Fri, 16 Dec 2005 16:43:20 -0800 (PST) Received: by 10.70.36.7 with HTTP; Fri, 16 Dec 2005 16:43:20 -0800 (PST) Message-ID: <70e8236f0512161643t605ff100see3100bf99604ba0@mail.gmail.com> Date: Sat, 17 Dec 2005 00:43:20 +0000 From: Joao Barros To: Scott Long In-Reply-To: <43A30F94.2030909@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <43A266E5.3080103@samsco.org> <70e8236f0512160659h3379253dw468e5aad3f741002@mail.gmail.com> <20051216190031.GD58262@thought.org> <43A30F94.2030909@samsco.org> Cc: Gary Kline , stable@freebsd.org, current Subject: Re: HEADS UP: Release schedule for 2006 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, 17 Dec 2005 00:43:22 -0000 > Gary Kline wrote: > > Are you volunteering to post the TODO lists here on -stable > > every N months? I think it's a great idea to have some > > clues about where we're going, or hope to be going. No I am not. But you are right on the "it's a great idea to have some clues about where we're going, or hope to be going" part. That was my poin= t. On 12/16/05, Scott Long wrote: > The release TODO list is maintained on the FreeBSD.org website, As I pointed, available for anyone interested in knowing what's going on. > though > it's usually only active during release cycles. Yes, but until that time only by reading yours and other Dev's answers to the same questions one knows where a Release is heading. The users know what to expect and the Dev's know what they set themselfes to do :-) -- Joao Barros From owner-freebsd-current@FreeBSD.ORG Sat Dec 17 01:13:02 2005 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 3191116A41F; Sat, 17 Dec 2005 01:13:02 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: from mail.localelinks.com (web.localelinks.com [64.39.75.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A5A743D6B; Sat, 17 Dec 2005 01:12:58 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: from draco.over-yonder.net (adsl-157-23-19.jan.bellsouth.net [70.157.23.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.localelinks.com (Postfix) with ESMTP id 3E1E5AD; Fri, 16 Dec 2005 19:12:57 -0600 (CST) Received: by draco.over-yonder.net (Postfix, from userid 100) id CFF1D61C21; Fri, 16 Dec 2005 19:12:55 -0600 (CST) Date: Fri, 16 Dec 2005 19:12:55 -0600 From: "Matthew D. Fuller" To: Joao Barros Message-ID: <20051217011255.GL63497@over-yonder.net> References: <43A266E5.3080103@samsco.org> <70e8236f0512160659h3379253dw468e5aad3f741002@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <70e8236f0512160659h3379253dw468e5aad3f741002@mail.gmail.com> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.11-fullermd.2 Cc: stable@freebsd.org, current Subject: Re: HEADS UP: Release schedule for 2006 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, 17 Dec 2005 01:13:02 -0000 On Fri, Dec 16, 2005 at 02:59:09PM +0000 I heard the voice of Joao Barros, and lo! it spake thus: > > There have been some questions on the lists about what to expect > from release x.y and I personnally have always looked at the TODO > list like http://www.freebsd.org/releases/6.0R/todo.html It's always been my impression that the todo list is put together as we close in on a release as a "these things still need to get done". It's not really a "here are the things this release offers over the previous one"... -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-current@FreeBSD.ORG Sat Dec 17 05:48:42 2005 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 413EC16A41F; Sat, 17 Dec 2005 05:48:42 +0000 (GMT) (envelope-from ai@bmc.brk.ru) Received: from stalker.bmc.brk.ru (stalker.bmc.brk.ru [217.150.59.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id B89F843D55; Sat, 17 Dec 2005 05:48:41 +0000 (GMT) (envelope-from ai@bmc.brk.ru) Date: Sat, 17 Dec 2005 08:48:36 +0300 From: Artemiev Igor To: Ruslan Ermilov Message-Id: <20051217084836.71eb86e6.ai@bmc.brk.ru> In-Reply-To: <20051216111813.GE41326@ip.net.ua> References: <200512141749.jBEHnjRV081112@repoman.freebsd.org> <20051214183345.GE51686@ip.net.ua> <20051215093643.694e995b.ai@bmc.brk.ru> <200512151306.57961.jhb@freebsd.org> <20051216083657.GA41326@ip.net.ua> <20051216134225.09aa93a3.ai@bmc.brk.ru> <20051216111813.GE41326@ip.net.ua> Organization: Bryansk Medical Center X-Mailer: Sylpheed version 2.0.0beta4 (GTK+ 2.6.8; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: cvs commit: src/sys/pci amdpm.c 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, 17 Dec 2005 05:48:42 -0000 > i2c-amd8111.c and i2c-nforce2.c are indeed very similar, because they > both use SMBus 2.0 API. :-) ... > See how the offset 0x2 register means completely different things. Yep. Sorry for this little diversion :-(( I wrote new driver, nfpm, which completely based on linux`s i2c- nforce2 driver. Can you review it? http://stalker.bmc.brk.ru/~ai/patches/nfpm.c -- iprefetch ai From owner-freebsd-current@FreeBSD.ORG Sat Dec 17 06:53:58 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id B533216A420; Sat, 17 Dec 2005 06:53:58 +0000 (GMT) In-Reply-To: <17315.15301.316482.649755@grasshopper.cs.duke.edu> from Andrew Gallatin at "Dec 16, 2005 05:12:21 pm" To: gallatin@cs.duke.edu (Andrew Gallatin) Date: Sat, 17 Dec 2005 06:53:58 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20051217065358.B533216A420@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) Cc: freebsd-current@freebsd.org Subject: Re: PREEMPTION vs ndisulator 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, 17 Dec 2005 06:53:58 -0000 > John Baldwin writes: > > On Friday 16 December 2005 03:52 pm, Andrew Gallatin wrote: > > > John Baldwin writes: > > > > On Friday 16 December 2005 11:34 am, Andrew Gallatin wrote: > > > > Looks like an ithread has preempted your driver's start routine. If you > > > > let it run some more and then break into ddb is the same thread (pid 11) > > > > still running? Also, which process is pid 11? > > It looks like the ithread is looping: > > db> show intrcnt > irq4: sio0 1007 > irq14: ata0 33 > irq17: fwohci0 1 > irq18: ndis0 757379 > irq21: ohci0+ 382 > cpu0: timer 1254872 > db> c > [halt - sent] > KDB: enter: Line break on console > [thread pid 76 tid 100049 ] > Stopped at kdb_enter+0x2f: nop > db> show intrcnt > irq4: sio0 1009 > irq14: ata0 33 > irq17: fwohci0 1 > irq18: ndis0 992263 > irq21: ohci0+ 382 > cpu0: timer 1259314 > > > I know the interrupt is actually disabled in the DPC, and > not in the interrupt handler. That's probably the problem. > The DPC is just never getting scheduled, so the interrupt > line is never lowered. Whoa whoa whoa, hold on just a second. Are you telling me your Windows driver code does not ack/mask interrupts in its MiniportISR() routine? If so, you realize that's a violation of the API and you'd never get your driver WHQL'ed thay way (that is assuming the Microsoft Driver Verifier can catch this mistake, and I'm not certain that it can). I'm kind of surprised you can get away with this in Windows at all. -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= you're just BEGGING to face the moose ============================================================================= From owner-freebsd-current@FreeBSD.ORG Sat Dec 17 09:31:42 2005 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 8183716A41F; Sat, 17 Dec 2005 09:31:42 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from smtp2-g19.free.fr (smtp2-g19.free.fr [212.27.42.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0AB6043D4C; Sat, 17 Dec 2005 09:31:41 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by smtp2-g19.free.fr (Postfix) with ESMTP id D758365BC9; Sat, 17 Dec 2005 10:31:40 +0100 (CET) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 5B9039B6E7; Sat, 17 Dec 2005 09:31:16 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 0F6D5405A; Sat, 17 Dec 2005 10:31:16 +0100 (CET) Date: Sat, 17 Dec 2005 10:31:15 +0100 From: Jeremie Le Hen To: Doug Barton Message-ID: <20051217093115.GY3512@obiwan.tataz.chchile.org> References: <200512022006.jB2K67AK078509@repoman.freebsd.org> <20051203004057.GA20872@nagual.pp.ru> <4390EFB6.3090307@FreeBSD.org> <20051203012324.GA34147@nagual.pp.ru> <4390F9A2.208@FreeBSD.org> <20051216013955.GW3512@obiwan.tataz.chchile.org> <43A3351E.8010005@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43A3351E.8010005@FreeBSD.org> User-Agent: Mutt/1.5.11 Cc: freebsd-current@FreeBSD.ORG Subject: Re: [fbsd] Re: cvs commit: src/etc rc rc.shutdown rc.subr src/etc/rc.d localpkg src/sys/sys param.h 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, 17 Dec 2005 09:31:42 -0000 Hi, Doug, On Fri, Dec 16, 2005 at 01:43:58PM -0800, Doug Barton wrote: > [... many things...] I didn't use to waste bandwidth for thanking people for their answers, but yours was so clear and complete that I can't help not doing it :-). Thank you. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Sat Dec 17 10:28:39 2005 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 E728016A41F for ; Sat, 17 Dec 2005 10:28:39 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn.pobox.com (thorn.pobox.com [208.210.124.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A56743D45 for ; Sat, 17 Dec 2005 10:28:39 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id 14AAE9D; Sat, 17 Dec 2005 05:29:00 -0500 (EST) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thorn.sasl.smtp.pobox.com (Postfix) with ESMTP id AF0D62515; Sat, 17 Dec 2005 05:28:58 -0500 (EST) Received: from lists by mappit.local.linnet.org with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EnZIp-0008ew-L5; Sat, 17 Dec 2005 10:28:35 +0000 Date: Sat, 17 Dec 2005 10:28:35 +0000 From: Brian Candler To: Poul-Henning Kamp Message-ID: <20051217102835.GC33190@uk.tiscali.com> References: <200512161856.jBGIudig093608@repoman.freebsd.org> <8509.1134766863@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8509.1134766863@critter.freebsd.dk> User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org Subject: Re: About extensible prinf(3), a slightly long X-mas card 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, 17 Dec 2005 10:28:40 -0000 On Fri, Dec 16, 2005 at 10:01:03PM +0100, Poul-Henning Kamp wrote: > Until somebody specifically ask for it (with a global variable or an > environment variable) or registers an extension, we keep running on > our good old fast spaghetti vprintf, but once extensibility is called > for, we switch to my code. Perhaps the semantics of this extended printf() are so far divorced from the standard one that you might as well just call it something else? e.g. ext_printf() or whatever. I can see two advantages to this approach: (1) you don't take a big performance hit on all your other printf() calls just because you used an extended format once in your code. (2) clear marking of non-portable code: you are not tempted to use non-standard features in a call to regular printf(), and end up with a program which compiles happily on any other platform but dumps core when run. In fact, why not stick it in a completely separate library altogether, rather than libc? That would greatly *assist* portability, since you could simply build this library on other targets. In this case it would be OK to call it printf(), as long as you don't mind the possible confusion and the requirement to do your linking in the correct order. > Obviously, such extensions are not condoned by style(9) but probably more > damning, GCC's printf format checker knows nothing about them, so it will > take a fit if you use them. > > For these reasons, and for general reasons of sanity, printf format > extensions should _not_ be added to FreeBSD programs at this time, if ever. Sounds to me like another good reason for calling the function something else, and/or putting it in a separate library. Regards, Brian. From owner-freebsd-current@FreeBSD.ORG Sat Dec 17 10:35:04 2005 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 366E416A41F for ; Sat, 17 Dec 2005 10:35:04 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCA0043D58 for ; Sat, 17 Dec 2005 10:35:03 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 8D23FBC66; Sat, 17 Dec 2005 10:35:00 +0000 (UTC) To: Brian Candler From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 17 Dec 2005 10:28:35 GMT." <20051217102835.GC33190@uk.tiscali.com> Date: Sat, 17 Dec 2005 11:34:59 +0100 Message-ID: <23883.1134815699@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: current@freebsd.org Subject: Re: About extensible prinf(3), a slightly long X-mas card 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, 17 Dec 2005 10:35:04 -0000 In message <20051217102835.GC33190@uk.tiscali.com>, Brian Candler writes: >Perhaps the semantics of this extended printf() are so far divorced from the >standard one that you might as well just call it something else? e.g. > > ext_printf() the reasons not to are ext_printf() ext_fprintf() ext_sprintf() ext_snprintf() ext_asprintf() ext_vprintf() ext_vfprintf() ext_vsfprintf() ext_vasfprintf() There is little or no point in replicating all of this stuff. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Sat Dec 17 10:37:11 2005 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 8DEDA16A41F for ; Sat, 17 Dec 2005 10:37:11 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59A7D43D5C for ; Sat, 17 Dec 2005 10:37:05 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id jBHAajk2018822; Sat, 17 Dec 2005 12:36:45 +0200 (EET) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 92464-09; Sat, 17 Dec 2005 12:36:43 +0200 (EET) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id jBHAXHtS018760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 Dec 2005 12:33:17 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.4/8.13.4) id jBHAXP8x014314; Sat, 17 Dec 2005 12:33:25 +0200 (EET) (envelope-from ru) Date: Sat, 17 Dec 2005 12:33:25 +0200 From: Ruslan Ermilov To: Artemiev Igor Message-ID: <20051217103325.GO41326@ip.net.ua> References: <200512141749.jBEHnjRV081112@repoman.freebsd.org> <20051214183345.GE51686@ip.net.ua> <20051215093643.694e995b.ai@bmc.brk.ru> <200512151306.57961.jhb@freebsd.org> <20051216083657.GA41326@ip.net.ua> <20051216134225.09aa93a3.ai@bmc.brk.ru> <20051216111813.GE41326@ip.net.ua> <20051217084836.71eb86e6.ai@bmc.brk.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7PAM/4G1BR2SfWzg" Content-Disposition: inline In-Reply-To: <20051217084836.71eb86e6.ai@bmc.brk.ru> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua Cc: freebsd-current@freebsd.org Subject: Re: cvs commit: src/sys/pci amdpm.c 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, 17 Dec 2005 10:37:11 -0000 --7PAM/4G1BR2SfWzg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 17, 2005 at 08:48:36AM +0300, Artemiev Igor wrote: > > i2c-amd8111.c and i2c-nforce2.c are indeed very similar, because they > > both use SMBus 2.0 API. :-) > ... > > See how the offset 0x2 register means completely different things. > Yep. Sorry for this little diversion :-(( > I wrote new driver, nfpm, which completely based on linux`s i2c- > nforce2 driver. Can you review it? > http://stalker.bmc.brk.ru/~ai/patches/nfpm.c >=20 I've also written such a driver tonight. I'll compare what you wrote with what I have and let you know. It would help if you showed me the output from "pciconf -lv", "devinfo -rv", dmesg, and "mbmon -A -d" which this driver (but make sure your mbmon has SMBus support, the -s option (lowercase "s"). Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --7PAM/4G1BR2SfWzg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDo+l1qRfpzJluFF4RAp/xAKCbtIrDY4U150LjbJkt9N7iFyjYagCglsfS bneexwSrAKSkO5TF8401cJQ= =o3Nh -----END PGP SIGNATURE----- --7PAM/4G1BR2SfWzg-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 17 11:02:05 2005 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 5BCEB16A41F for ; Sat, 17 Dec 2005 11:02:05 +0000 (GMT) (envelope-from kjelderg@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6760143D5F for ; Sat, 17 Dec 2005 11:02:04 +0000 (GMT) (envelope-from kjelderg@gmail.com) Received: by wproxy.gmail.com with SMTP id i31so792919wra for ; Sat, 17 Dec 2005 03:02:03 -0800 (PST) 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=DKd3/0EpJWsKNS0mSI+ng60qGLpYz4tfk3Q7rSWm1F69eKNN+FoGM9253Cl3HfpbYA0N7Hx8bqSNtvr18vJOnZZHC1uECv6KUEd1aucjtx5KgNjALsc9sce3p3PviWXrSdfw6AqW/1okQM7b5xSYz46OYHdpqhonRYoNgv3UaFU= Received: by 10.64.10.15 with SMTP id 15mr480711qbj; Sat, 17 Dec 2005 03:02:03 -0800 (PST) Received: by 10.65.22.9 with HTTP; Sat, 17 Dec 2005 03:02:03 -0800 (PST) Message-ID: Date: Sat, 17 Dec 2005 20:02:03 +0900 From: Eric Kjeldergaard To: Andy Bontoft In-Reply-To: <42FCDD7B.6040307@bontoft.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <42F47354.6000109@bontoft.net> <42F56A66.9080607@errno.com> <42FCDD7B.6040307@bontoft.net> Cc: freebsd-current@freebsd.org Subject: Re: ath 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: Sat, 17 Dec 2005 11:02:05 -0000 Welp, seems I'm having a similar problem to what is descibed here.=20 I'll give similar information. I'm quite sure I was able to make my card do hostap in the 5.3 days. > >> I'm unable to get a wireless access point to work properly and for > >> the life of me I can't work out why. I've spent the past few evenings > >> trawling the mailing list archives without much success. I'm hoping > >> someone can point me in the right direction. > >> It's an Atheros 5212 (Wistron cm9 miniPCI) in a soekris 4801 box. > > > > > > 5212 Wistron cm9 means nothing; dmesg|grep ath will get you the > > mac+phy revs that identify your part. > > ap# dmesg| grep ath > ath_hal: 0.9.14.9 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413) > ath0: mem 0xa0010000-0xa001ffff irq 11 at device 14.0 on > pci0 > ath0: Ethernet address: 00:0b:6b:35:cb:82 > ath0: mac 5.9 phy 4.3 radio 3.6 ath_hal: 0.9.14.9 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413) ath0: mem 0xd0200000-0xd020ffff irq 11 at device 2.0 on pci2 ath0: Ethernet address: 00:05:4e:42:8b:2d ath0: mac 4.2 phy 3.0 5ghz radio 1.7 2ghz radio 2.3 > pciconf provides this information > ath0@pci0:14:0: class=3D0x020000 card=3D0x1012185f chip=3D0x0013168c rev= =3D0x01 > hdr=3D0x00 > vendor =3D 'Atheros Communications Inc.' > device =3D 'AR5212, AR5213 802.11a/b/g Wireless Adapter' > class =3D network > subclass =3D ethernet ath0@pci2:2:0: class=3D0x020000 card=3D0x831017ab chip=3D0x0012168c rev=3D0x01 hdr=3D0x00 vendor =3D 'Atheros Communications Inc.' device =3D 'AR5211 802.11a/b/g Mini-PCI Wireless Adapter' class =3D network subclass =3D ethernet > >> A test client (WinXP SP2) can associate and on occasion obtains an > >> address from the DHCP server on the ether side of the AP. Most of the > >> time it is unable to obtain an address however, and even when it does > >> after a few seconds it changes to the default not connected address > >> of the 169.254/16 network. > >> Initially I was trying to configure hostap for wpa+802.1x (EAP_TLS), > >> the 802.1x worked fine and the XP laptop received its address, again > >> after a few seconds the address would revert to the 169.254/16 > >> network. To try and identify the issue I switched to a simple wep > >> mode (without hostap), but I have the same issue. The athstats tool > >> reports a lot of failures. > >> I haven't attached pages and pages of debug output as I'm not sure > >> what would be required and don't want to flood the list. I have just > >> attached a few of the basic things, but if more information is > >> required I can obviously supply it. > >> Thanks for your time > >> andy > >> btw - the same laptop works perfectly with an identical config > >> (except the SSID is different) on second 'off the shelf' AP. > >> > >> ap# ifconfig ath0 > >> ath0: flags=3D8847 mtu 1= 500 > >> inet6 fe80::20b:6bff:fe35:cb82%ath0 prefixlen 64 scopeid 0x4 > >> inet 0.0.0.0 netmask 0xff000000 broadcast 0.255.255.255 > >> ether 00:0b:6b:35:cb:82 > >> media: IEEE 802.11 Wireless Ethernet autoselect mode 11g > >> status: associated > >> ssid Z channel 9 bssid 00:0b:6b:35:cb:82 > >> authmode OPEN privacy ON deftxkey 1 wepkey 1:104-bit txpowmax 5= 3 > >> protmode CTS dtimperiod 1 bintval 100 > > > > > > Run open and simplify your config until you figure out what's wrong. > > Channels 1, 6, and 11 are usually the best for signal w/ 6 preferred. > > Not sure why your ap is using 9. > > I set it to run on channel nine as at any given time I can see between > seven and fifteen wireless networks, with on average half of them > running on channel eleven. I run the 'off the shelf' ap I mentioned on > channel six and as they're about two foot apart I thought picking an > unused channel might be reasonable - incorrectly it seems. > > I have configured it as a completely open ap, and the problem is the same= . > The interface entry from my /etc/rc.conf is... > ifconfig_ath0=3D"ssid Z mode 11g mediaopt hostap channel 6 up" So then, I have a palmos client trying to connect as a client (using autoscans to see if it is detected, though I have tried to set it up manually as well) to my freebsd machine which is configured as follows: [~] #ifconfig ath0 ssid Z mode 11b mediaopt hostap channel 6 up [~] #ifconfig ath0 ath0: flags=3D8843 mtu 1500 inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 ether 00:05:4e:42:8b:2d media: IEEE 802.11 Wireless Ethernet DS/11Mbps mode 11b status: associated ssid Z channel 6 bssid 00:05:4e:42:8b:2d authmode OPEN privacy ON deftxkey UNDEF txpowmax 34 dtimperiod 1 bintval 100 I've tried this with and without an IP with the same results.=20 Everything in there looks right to me. I'm using compiled-into-kernel ath_hal, ath, and ath_rate_sample. > > You don't indicate if the client is using 11g or 11b; based on the > > statistics I'm guessing 11g. For mine it is an 11b setup. > > You probably need to setup a 3rd machine and sniff the traffic to see > > what's going on. Windows has some serious timing requirements in > > their system and if you enable debugging on the ap you may slow things > > down enough that the client will time out. > > > > Sam > > > >> > >> ap# sysctl net.link.ether.bridge > >> net.link.ether.bridge_cfg: "ath0,sis0" > >> net.link.ether.bridge_ipfw: 0 > >> net.link.ether.bridge_ipf: 0 > >> net.link.ether.bridge.config: "ath0,sis0" > >> net.link.ether.bridge.enable: 1 > >> net.link.ether.bridge.predict: 0 > >> net.link.ether.bridge.dropped: 0 > >> net.link.ether.bridge.packets: 0 > >> net.link.ether.bridge.ipfw_collisions: 0 > >> net.link.ether.bridge.ipfw_drop: 0 > >> net.link.ether.bridge.copy: 0 > >> net.link.ether.bridge.ipfw: 0 > >> net.link.ether.bridge.ipf: 0 > >> net.link.ether.bridge.debug: 2 > >> net.link.ether.bridge.version: 031224 > >> > >> ap# ./athstats > >> 1666 tx management frames > >> 5 tx frames discarded prior to association > >> 996 tx failed 'cuz too many retries > >> 11502 long on-chip tx retries > >> 221 tx frames with no ack marked > >> 204 tx frames with short preamble > >> 57002 rx failed 'cuz of bad CRC > >> 136258 rx failed 'cuz of PHY err > >> 122418 OFDM timing > >> 13840 CCK timing > >> 28961 beacons transmitted > >> 165 periodic calibrations > >> 4 rfgain value change > >> 4489 rate control checks > >> 5 rate control dropped xmit rate > > > > > > This is odd; are you using ath_rate_sample? If there is noise causing > > the rate control code to drop the tx rate then > > > >> rssi of last ack: 19 > >> avg recv rssi: 33 > >> 59 switched default/rx antenna > >> Antenna profile: > >> [1] tx 472 rx 3037 > >> [2] tx 414 rx 29 In case this is useful: [~] #athstats 48 tx management frames 28 tx frames discarded prior to association 8 tx failed 'cuz too many retries 96 long on-chip tx retries 17 tx frames with no ack marked 112 rx failed 'cuz of bad CRC 42334 beacons transmitted 139 periodic calibrations rssi of last ack: 4 Antenna profile: [0] tx 39 rx 0 [1] tx 0 rx 405 That's all the information I can think of. I'm quite sure this used to work with an ifconfig incantation (almost) exactly like that. In fact, I often copied and pasted the one from the man page and it worked. It seems that it doesn't now. Is there some change that occurred that I should be aware of and missed? Thanks in advance for your time and expertise, Eric Kjeldergaard -- If I write a signature, my emails will appear more personalised. From owner-freebsd-current@FreeBSD.ORG Sat Dec 17 11:05:17 2005 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 48E0016A41F for ; Sat, 17 Dec 2005 11:05:17 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA6F943D53 for ; Sat, 17 Dec 2005 11:05:16 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id jBHB5ECC082607; Sat, 17 Dec 2005 03:05:14 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id jBHB5DdN082606; Sat, 17 Dec 2005 03:05:13 -0800 (PST) (envelope-from rizzo) Date: Sat, 17 Dec 2005 03:05:13 -0800 From: Luigi Rizzo To: Poul-Henning Kamp Message-ID: <20051217030513.A82342@xorpc.icir.org> References: <20051217102835.GC33190@uk.tiscali.com> <23883.1134815699@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <23883.1134815699@critter.freebsd.dk>; from phk@phk.freebsd.dk on Sat, Dec 17, 2005 at 11:34:59AM +0100 Cc: current@freebsd.org, Brian Candler Subject: Re: About extensible prinf(3), a slightly long X-mas card 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, 17 Dec 2005 11:05:17 -0000 On Sat, Dec 17, 2005 at 11:34:59AM +0100, Poul-Henning Kamp wrote: > In message <20051217102835.GC33190@uk.tiscali.com>, Brian Candler writes: > > >Perhaps the semantics of this extended printf() are so far divorced from the > >standard one that you might as well just call it something else? e.g. > > > > ext_printf() > > the reasons not to are > > ext_printf() > ext_fprintf() > ext_sprintf() > ext_snprintf() > ext_asprintf() > ext_vprintf() > ext_vfprintf() > ext_vsfprintf() > ext_vasfprintf() > > There is little or no point in replicating all of this stuff. phk, i don't understand your objection. aren't (or shouldn't) all of these written as wrappers for a generic ext_*printf() ? or your objection is not on the number of different interfaces to the same thing, but rather the fact that by calling it printf you can use the existing GLIBC glue to register extensions etc ? I love the idea of extensible printf, and it's way way useful when handling ip addresses, hexdump and whatnot; but portability is an issue, and nobody would use it if the source code doesn't port to other systems. cheers luigi From owner-freebsd-current@FreeBSD.ORG Sat Dec 17 11:18:13 2005 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 CFF1D16A41F for ; Sat, 17 Dec 2005 11:18:13 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6976B43D55 for ; Sat, 17 Dec 2005 11:18:13 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 5D0B4BC89; Sat, 17 Dec 2005 11:18:11 +0000 (UTC) To: Luigi Rizzo From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 17 Dec 2005 03:05:13 PST." <20051217030513.A82342@xorpc.icir.org> Date: Sat, 17 Dec 2005 12:18:11 +0100 Message-ID: <24068.1134818291@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: current@freebsd.org, Brian Candler Subject: Re: About extensible prinf(3), a slightly long X-mas card 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, 17 Dec 2005 11:18:13 -0000 In message <20051217030513.A82342@xorpc.icir.org>, Luigi Rizzo writes: >> >Perhaps the semantics of this extended printf() are so far divorced from the >> >standard one that you might as well just call it something else? e.g. >> > >> > ext_printf() >> >> the reasons not to are >> >> ext_printf() >> ext_fprintf() >> ext_sprintf() >> ext_snprintf() >> ext_asprintf() >> ext_vprintf() >> ext_vfprintf() >> ext_vsfprintf() >> ext_vasfprintf() >> >> There is little or no point in replicating all of this stuff. > >phk, i don't understand your objection. >aren't (or shouldn't) all of these written as wrappers >for a generic ext_*printf() ? My objection is that we would need an entirely new familiy of wrappers such as the above. >I love the idea of extensible printf, and it's way way useful >when handling ip addresses, hexdump and whatnot; but >portability is an issue, and nobody would use it if >the source code doesn't port to other systems. Everything under the sun has a portability cost these days because the portable subset of the UNIX API is still too small to support sensible programming. My favourite example is this: After 30 years, wouldn't you have expected that UNIX would sport a: open_tcp_connection(const char *host, const char *proto) call ? Try to compare the primitives modern languages offer to what you can portably use on UNIX and see the disparity :-( The sorry situation is that after Dennis and Ken let go, nobody has been able to work on th UNIX API in a coherent fashion, and instead various extensions have been slapped on haphazardly where people could fit them in. For an extensible printf, I see little reason to add yet another API, the GLIBC people got here first, the API is not optimal, but it does work. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Sat Dec 17 11:27:07 2005 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 2C40A16A41F for ; Sat, 17 Dec 2005 11:27:07 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4A3143D5C for ; Sat, 17 Dec 2005 11:27:06 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id jBHBR6XP083048; Sat, 17 Dec 2005 03:27:06 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id jBHBR6nS083047; Sat, 17 Dec 2005 03:27:06 -0800 (PST) (envelope-from rizzo) Date: Sat, 17 Dec 2005 03:27:06 -0800 From: Luigi Rizzo To: Poul-Henning Kamp Message-ID: <20051217032706.A82898@xorpc.icir.org> References: <20051217030513.A82342@xorpc.icir.org> <24068.1134818291@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <24068.1134818291@critter.freebsd.dk>; from phk@phk.freebsd.dk on Sat, Dec 17, 2005 at 12:18:11PM +0100 Cc: current@freebsd.org, Brian Candler Subject: Re: About extensible prinf(3), a slightly long X-mas card 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, 17 Dec 2005 11:27:07 -0000 On Sat, Dec 17, 2005 at 12:18:11PM +0100, Poul-Henning Kamp wrote: > In message <20051217030513.A82342@xorpc.icir.org>, Luigi Rizzo writes: ... > >I love the idea of extensible printf, and it's way way useful > >when handling ip addresses, hexdump and whatnot; but > >portability is an issue, and nobody would use it if > >the source code doesn't port to other systems. > > Everything under the sun has a portability cost these days because > the portable subset of the UNIX API is still too small to support > sensible programming. ... > For an extensible printf, I see little reason to add yet another > API, the GLIBC people got here first, the API is not optimal, but > it does work. so let me understand - perhaps i am missing this point. are you saying that if you link a program that uses these extensions with glibc it behaves as expected ? Then the portability issue would disappear (i.e. moves elsewhere where hopefully it has been solved already). cheers luigi From owner-freebsd-current@FreeBSD.ORG Sat Dec 17 11:30:34 2005 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 4E11F16A422 for ; Sat, 17 Dec 2005 11:30:34 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93FBC43D45 for ; Sat, 17 Dec 2005 11:30:31 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 52D50BC66; Sat, 17 Dec 2005 11:30:29 +0000 (UTC) To: Luigi Rizzo From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 17 Dec 2005 03:27:06 PST." <20051217032706.A82898@xorpc.icir.org> Date: Sat, 17 Dec 2005 12:30:28 +0100 Message-ID: <24152.1134819028@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: current@freebsd.org, Brian Candler Subject: Re: About extensible prinf(3), a slightly long X-mas card 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, 17 Dec 2005 11:30:34 -0000 In message <20051217032706.A82898@xorpc.icir.org>, Luigi Rizzo writes: >On Sat, Dec 17, 2005 at 12:18:11PM +0100, Poul-Henning Kamp wrote: >> In message <20051217030513.A82342@xorpc.icir.org>, Luigi Rizzo writes: >... >> >I love the idea of extensible printf, and it's way way useful >> >when handling ip addresses, hexdump and whatnot; but >> >portability is an issue, and nobody would use it if >> >the source code doesn't port to other systems. >> >> Everything under the sun has a portability cost these days because >> the portable subset of the UNIX API is still too small to support >> sensible programming. >... >> For an extensible printf, I see little reason to add yet another >> API, the GLIBC people got here first, the API is not optimal, but >> it does work. > >so let me understand - perhaps i am missing this point. > >are you saying that if you link a program that uses these extensions >with glibc it behaves as expected ? Then the portability issue >would disappear (i.e. moves elsewhere where hopefully it has been >solved already). I'd really hope so, but havn't tried. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Sat Dec 17 11:32:24 2005 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 DAB7416A41F; Sat, 17 Dec 2005 11:32:24 +0000 (GMT) (envelope-from shurd@sasktel.net) Received: from misav08.sasknet.sk.ca (misav08.sasknet.sk.ca [142.165.20.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E2B843D5E; Sat, 17 Dec 2005 11:32:23 +0000 (GMT) (envelope-from shurd@sasktel.net) Received: from bgmpomr2.sasknet.sk.ca ([142.165.72.23]) by misav08 with InterScan Messaging Security Suite; Sat, 17 Dec 2005 05:32:22 -0600 Received: from [192.168.0.193] ([142.165.59.202]) by bgmpomr2.sasknet.sk.ca (SaskTel eMessaging Service) with ESMTPA id <0IRN005EC41W8A10@bgmpomr2.sasknet.sk.ca>; Sat, 17 Dec 2005 05:32:22 -0600 (CST) Date: Sat, 17 Dec 2005 05:32:20 -0600 From: Stephen Hurd In-reply-to: <43A27C32.6020501@samsco.org> To: Scott Long Message-id: <43A3F744.7040301@sasktel.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-ca, en-gb, en-us, en References: <43A266E5.3080103@samsco.org> <20051216082704.GA52634@thought.org> <43A27C32.6020501@samsco.org> User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051108 X-Mailman-Approved-At: Sat, 17 Dec 2005 14:15:12 +0000 Cc: Gary Kline , stable@freebsd.org, current Subject: Re: HEADS UP: Release schedule for 2006 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, 17 Dec 2005 11:32:25 -0000 > Security updates will be maintained for quite a while. However, it > takes manpower to test each proposed security change, so it's very hard > to justify doing them 'indefinitely'. The stated policy from the > security team is 2 years. So they will probably support 5.5 into > 2008, but I wanted to be conservative in my statement in case they > have different plans. It seems to me like FBSD may be pushing too much to a new major version. Although NBSD is stepping up the "-release" versions significantly, I feel that FBSD (and friends, but this is hardly the place for B&W about them) are/is moving a bit too quickly. While the SMP changes are nice and all (my main application server at home is a dual coppermine 1GHz), the tty (for example) seems to be getting more and more unstable as it goes on... this seems to a certain degree to be that features in -CURRENT are barely cooking let alone baking, and talk is already that 5.x is obsolete. Pushing off GIANT was a 5.x goal iirc, and making existing changes stable is a per-major goal (again, imho). It seems like the version numbers aren't actually meaningfull anymore. I mean... I'm used to a FBSD that would change majors when an API and/or ABI *needed* changing. It feels like it's happening 'cause it'd be "cool" to have a 7.x now. The FBSD pthread support for example has been better than Linux since libc_r... and it's only improved. But I can't actualy *rely* on anything specific working. A project I work on has had a THREADS_ACTUALLY_WORK flag available for Linux when they acually do (not yet, let's not talk about sigwait()) for the last few years. But I can't depend on a major version for strtold()... can't even depend on a > comparison. It's hard to know what to depend on now... "Things are Changing" and you need to know exactly what you need to discover what is required. A few years ago, I was flabbergasted when I was asked for a way to identify the libc version under FBSD. The need to do something like that never occured to me.... the possibility of having libc "out of sync" with the kernel never even crossed my mind, and the reason was that the whole thing was one system. It's starting to feel a lot more like some Linux system now... only without the spiffy up2date thinger to go with it. Upgrading from major to major has been something I never minded when needed, but it's too needed now and there's nothing to make it happy. Either the OBSD "no need to rebuild GENERIC" model is being accepted, or we're dumping the "/etc/,/usr/*/etc/*" backup and restore model. I love rcNG for example... but my OPL3 no longer does anything usefull... I had an AWE32 with gobs of RAM plugged in and had to use the Voxware drivers until I couldn't... and now I *need* to use timidity because what other choice do I have? I guess I'm old-fashioned, but I just recently managed to have my LaserWriter 16/600 (using the built-in AUI port) be as easy to set up with CUPS as with printcap I was happy and joyfull. But I had to *manually* do the /usr/bin/* and /usr/sbin/* symlinks *and rebuild KDE samba, and OOo. Why? Probobly 'cause I had lpr working before... does the vaunted handbook even suggest CUPS is there the slighest hint of a migration path? My home NIS and NFS server recently became a Solaris 10 one because it Just Works -- despite the inetd, local service, etc horribleness (still not an AMd fan... mount /home via NFS and don't worry) but I'm worried... even I, a FBSD fanatic am moving my servives off of my various FBSD boxes. Why? They may not work when Things are Better. FBSD currently out "sells" any *nix you pick... *BSD, */Linux, heck, *X.. but when Apache and PostgreSQL move to Linux as their primary system (and the world yawns... let's not talk about BDB) this is a wake-up call... I still haven't tried DragonFly, I think their development model is surpassed by FBSD. But hey, they fixed their clock and no other BSD did. Small incremental fixes. Have we lost that? One tool for the job. Perl killed it? FBSD is *NOT* a kernel bsdtar is *way* too late to make excuses for... where did the pascal compiler go? > Significant performance and stability enhancements that simply cannot > be broken up and backported to FreeBSD 5. We are marching towards a > 'Giant-less' kernel, which means continuing better SMP performance and > better UP responsiveness. With 6.0 we are finally starting to see the > benefit of the SMPng work that we've been doing for 5 years. iirc, this was a 5.x goal. We get a Major with no reason. Release notes between Majors are BORING... one needs to look at the userland to get anything they expect to use, and *BASIC* subsystems like the tty suffer. Will UP ever match what it once was? From owner-freebsd-current@FreeBSD.ORG Sat Dec 17 14:16:10 2005 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 B61C616A41F for ; Sat, 17 Dec 2005 14:16:10 +0000 (GMT) (envelope-from matthias.andree@gmx.de) Received: from mail.gmx.net (mail.gmx.de [213.165.64.21]) by mx1.FreeBSD.org (Postfix) with SMTP id 4567543D62 for ; Sat, 17 Dec 2005 14:16:06 +0000 (GMT) (envelope-from matthias.andree@gmx.de) Received: (qmail invoked by alias); 17 Dec 2005 14:16:02 -0000 Received: from p509137D6.dip0.t-ipconnect.de (EHLO merlin) [80.145.55.214] by mail.gmx.net (mp036) with SMTP; 17 Dec 2005 15:16:02 +0100 X-Authenticated: #428038 Date: Sat, 17 Dec 2005 15:15:28 +0100 From: Matthias Andree To: Lars Erik Gullerud Message-ID: <20051217141528.GB27992@merlin.emma.line.org> Mail-Followup-To: Lars Erik Gullerud , Craig Rodrigues , freebsd-fs@freebsd.org, freebsd-current@freebsd.org References: <20051213151908.GA26821@crodrigues.org> <20051216132641.C29205@electra.nolink.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051216132641.C29205@electra.nolink.net> X-PGP-Key: http://home.pages.de/~mandree/keys/GPGKEY.asc User-Agent: Mutt/1.5.11 X-Y-GMX-Trusted: 0 Cc: freebsd-fs@freebsd.org, Craig Rodrigues , Matthias Andree , freebsd-current@freebsd.org Subject: Re: XFS (read-only) support committed to CURRENT 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, 17 Dec 2005 14:16:10 -0000 On Fri, 16 Dec 2005, Lars Erik Gullerud wrote: > >Ext3fs appears to have some advantages, easy migration from and to > >ext2fs, shrinkable, data journalling, data ordering (write data blocks > >before the file metadata is written) and so on. > > ...and this has what to do with the fact that FreeBSD now supports XFS? I was wondering if the way from ext2fs to ext3fs might have been shorter, code-wise. I will skip lots of good points in defense of XFS, and I really don't mind it being supported by XFS (in fact I'm looking forward to write support). > >I don't mean this should become an advocacy discussion, as XFS surely > >has advantages, too, real-time capability and so on - but ext2fs is > >already there and has write support. > > Then use ext2fs. Isn't the availability of multiple choices great? Yes, it is :-) -- Matthias Andree From owner-freebsd-current@FreeBSD.ORG Sat Dec 17 14:17:19 2005 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 C146716A41F for ; Sat, 17 Dec 2005 14:17:19 +0000 (GMT) (envelope-from matthias.andree@gmx.de) Received: from mail.gmx.net (mail.gmx.de [213.165.64.21]) by mx1.FreeBSD.org (Postfix) with SMTP id ED89843D45 for ; Sat, 17 Dec 2005 14:17:18 +0000 (GMT) (envelope-from matthias.andree@gmx.de) Received: (qmail invoked by alias); 17 Dec 2005 14:17:13 -0000 Received: from p509137D6.dip0.t-ipconnect.de (EHLO merlin) [80.145.55.214] by mail.gmx.net (mp038) with SMTP; 17 Dec 2005 15:17:13 +0100 X-Authenticated: #428038 Date: Sat, 17 Dec 2005 15:16:47 +0100 From: Matthias Andree To: freebsd-current@freebsd.org Message-ID: <20051217141647.GC27992@merlin.emma.line.org> Mail-Followup-To: freebsd-current@freebsd.org References: <20051213151908.GA26821@crodrigues.org> <20051216151228.GA34670@crodrigues.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051216151228.GA34670@crodrigues.org> X-PGP-Key: http://home.pages.de/~mandree/keys/GPGKEY.asc User-Agent: Mutt/1.5.11 X-Y-GMX-Trusted: 0 Subject: Re: XFS (read-only) support committed to CURRENT 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, 17 Dec 2005 14:17:19 -0000 On Fri, 16 Dec 2005, Craig Rodrigues wrote: > Your comment makes no sense. What does being GPL have to do with > choosing ext2fs vs. XFS? We ported XFS to FreeBSD because we felt like it, > and it was fun. [...] That's a compelling reason. Seriously. -- Matthias Andree From owner-freebsd-current@FreeBSD.ORG Sat Dec 17 17:57:44 2005 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 957ED16A41F for ; Sat, 17 Dec 2005 17:57:44 +0000 (GMT) (envelope-from mdodd@FreeBSD.ORG) Received: from sasami.jurai.net (sasami.jurai.net [70.88.158.93]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB59643D53 for ; Sat, 17 Dec 2005 17:57:23 +0000 (GMT) (envelope-from mdodd@FreeBSD.ORG) Received: from sasami.jurai.net (winter@sasami.jurai.net [70.88.158.93]) by sasami.jurai.net (8.13.1/8.13.1) with ESMTP id jBHHvFcl024364; Sat, 17 Dec 2005 12:57:20 -0500 (EST) (envelope-from mdodd@FreeBSD.ORG) Date: Sat, 17 Dec 2005 12:57:15 -0500 (EST) From: "Matthew N. Dodd" X-X-Sender: winter@sasami.jurai.net To: Poul-Henning Kamp In-Reply-To: <8509.1134766863@critter.freebsd.dk> Message-ID: <20051217124717.H97875@sasami.jurai.net> References: <8509.1134766863@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-256505370-1134842235=:97875" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.5.6 (sasami.jurai.net [70.88.158.93]); Sat, 17 Dec 2005 12:57:21 -0500 (EST) Cc: current@FreeBSD.ORG Subject: Re: About extensible prinf(3), a slightly long X-mas card 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, 17 Dec 2005 17:57:44 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-256505370-1134842235=:97875 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Fri, 16 Dec 2005, Poul-Henning Kamp wrote: > If this proves useful, it'll stay in the tree and be part of 7.0 (no MFCs!) > it people break out in bikesheds about it, it will not. I'd rather leave the single letter specifiers and modifiers to the standards compliant printf and use something like %{foo} as the specifier for extensions. I've re-arranged some of the internals to make this easier to implement, and stubbed out the parsing of the %{} formats. I'm a little unsure what sort of errors to throw on extension lookup failure. ... What are your feelings on implementing things in such a way that the compiler could use this same sort of extension plugin to perform type checking? --0-256505370-1134842235=:97875 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="xprintf.diff" Content-Transfer-Encoding: BASE64 Content-ID: <20051217125715.C97875@sasami.jurai.net> Content-Description: Content-Disposition: attachment; filename="xprintf.diff" SW5kZXg6IGluY2x1ZGUvcHJpbnRmLmgNCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0NClJDUyBmaWxlOiAvaG9tZS9jdnMvc3JjL2luY2x1ZGUvcHJpbnRmLmgs dg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjENCmRpZmYgLXUgLXUgLXIxLjEg cHJpbnRmLmgNCi0tLSBpbmNsdWRlL3ByaW50Zi5oCTE2IERlYyAyMDA1IDE4 OjU2OjM4IC0wMDAwCTEuMQ0KKysrIGluY2x1ZGUvcHJpbnRmLmgJMTcgRGVj IDIwMDUgMTc6MTM6MjcgLTAwMDANCkBAIC03NCw2ICs3NCw3IEBADQogCWNv bnN0IGNoYXIJKmJlZ2luOw0KIAljb25zdCBjaGFyCSplbmQ7DQogCXZvaWQg CQkqYXJnW19fUFJJTlRGTUFYQVJHXTsNCisJc3RydWN0IGFyZ19mdW5jdGlv biAqYXJnX2ZjbjsNCiB9Ow0KIA0KIGVudW0gew0KQEAgLTEwNSw2ICsxMDYs MTIgQEANCiBzdHJ1Y3QgX19wcmludGZfaW87DQogdHlwZWRlZiBpbnQgcHJp bnRmX3JlbmRlcihzdHJ1Y3QgX19wcmludGZfaW8gKiwgY29uc3Qgc3RydWN0 IHByaW50Zl9pbmZvICosIGNvbnN0IHZvaWQgKmNvbnN0ICopOw0KIA0KK3N0 cnVjdCBhcmdfZnVuY3Rpb24gew0KKwlwcmludGZfYXJnaW5mb19mdW5jdGlv bgkqYXJnaW5mbzsNCisJcHJpbnRmX2Z1bmN0aW9uCQkqZ251cmVuZGVyOw0K KwlwcmludGZfcmVuZGVyCQkqcmVuZGVyOw0KK307DQorDQogLyogdnByaW50 Zi5jICovDQogZXh0ZXJuIGNvbnN0IGNoYXIgX19sb3dlcmNhc2VfaGV4WzE3 XTsNCiBleHRlcm4gY29uc3QgY2hhciBfX3VwcGVyY2FzZV9oZXhbMTddOw0K SW5kZXg6IGxpYi9saWJjL3N0ZGlvL3hwcmludGYuYw0KPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQ0KUkNTIGZpbGU6IC9ob21lL2N2cy9zcmMvbGliL2xpYmMv c3RkaW8veHByaW50Zi5jLHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4xDQpk aWZmIC11IC11IC1yMS4xIHhwcmludGYuYw0KLS0tIGxpYi9saWJjL3N0ZGlv L3hwcmludGYuYwkxNiBEZWMgMjAwNSAxODo1NjozOCAtMDAwMAkxLjENCisr KyBsaWIvbGliYy9zdGRpby94cHJpbnRmLmMJMTcgRGVjIDIwMDUgMTc6NDg6 MzcgLTAwMDANCkBAIC0yMzAsMTEgKzIzMCw3IEBADQogLyogdGFibGUgLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSovDQogDQogLypsaW50IC1lc3ltKDc4NSwgcHJpbnRm X3RibCkgKi8NCi1zdGF0aWMgc3RydWN0IHsNCi0JcHJpbnRmX2FyZ2luZm9f ZnVuY3Rpb24JKmFyZ2luZm87DQotCXByaW50Zl9mdW5jdGlvbgkJKmdudXJl bmRlcjsNCi0JcHJpbnRmX3JlbmRlcgkJKnJlbmRlcjsNCi19IHByaW50Zl90 YmxbMjU2XSA9IHsNCitzdHJ1Y3QgYXJnX2Z1bmN0aW9uIHByaW50Zl90Ymxb MjU2XSA9IHsNCiAJWyclJ10gPSB7IF9fcHJpbnRmX2FyZ2luZm9fcGN0LAkJ TlVMTCwJX19wcmludGZfcmVuZGVyX3BjdCB9LA0KIAlbJ0EnXSA9IHsgX19w cmludGZfYXJnaW5mb19mbG9hdCwJTlVMTCwJX19wcmludGZfcmVuZGVyX2Zs b2F0IH0sDQogCVsnQyddID0geyBfX3ByaW50Zl9hcmdpbmZvX2NociwJCU5V TEwsCV9fcHJpbnRmX3JlbmRlcl9jaHIgfSwNCkBAIC00MjksMTMgKzQyNSwz MSBAQA0KIAkJCQlwaS0+aXNfc2l6ZSA9IDE7DQogCQkJCWZtdCsrOw0KIAkJ CQljb250aW51ZTsNCisJCQljYXNlICd7JzoNCisJCQkJLyogU2tpcCB7ICov DQorCQkJCXBpLT5zcGVjKys7DQorDQorCQkJCS8qIExvb2sgZm9yIGVuZCBi cmFjZS4gKi8NCisJCQkJd2hpbGUgKCpmbXQrKyAhPSAnfScpDQorCQkJCQk7 DQorDQorCQkJCS8qIE5vIGNsb3NpbmcgYnJhY2UhICovDQorCQkJCWlmICgq Zm10ID09ICdcMCcpDQorCQkJCQlhYm9ydCgpOw0KKw0KKwkJCQkvKiBsZW4g PSBwaS0+c3BlYyAtIGZtdCAtIDEgKi8NCisJCQkJYnJlYWs7DQogCQkJZGVm YXVsdDoNCiAJCQkJZm10Kys7DQogCQkJCWJyZWFrOw0KIAkJCX0NCi0JCQlp ZiAocHJpbnRmX3RibFtwaS0+c3BlY10uYXJnaW5mbyA9PSBOVUxMKQ0KKw0K KwkJCWlmIChwaS0+YXJnX2ZjbiA9PSBOVUxMKQ0KKwkJCQlwaS0+YXJnX2Zj biA9ICZwcmludGZfdGJsW3BpLT5zcGVjXTsNCisNCisJCQlpZiAocGktPmFy Z19mY24tPmFyZ2luZm8gPT0gTlVMTCkNCiAJCQkJZXJyeCgxLCAiYXJnaW5m b1slY10gPSBOVUxMIiwgcGktPnNwZWMpOw0KLQkJCWNoID0gcHJpbnRmX3Ri bFtwaS0+c3BlY10uYXJnaW5mbygNCisJCQljaCA9IHBpLT5hcmdfZmNuLT5h cmdpbmZvKA0KIAkJCSAgICBwaSwgX19QUklOVEZNQVhBUkcsICZhcmd0W25l eHRhcmddKTsNCiAJCQlpZiAoY2ggPiAwKQ0KIAkJCQlwaS0+YXJnWzBdID0g JmFyZ3NbbmV4dGFyZ107DQpAQCAtNTQwLDE0ICs1NTQsMTQgQEANCiAJCWlm IChwaS0+Z2V0X3ByZWMpIA0KIAkJCXBpLT5wcmVjID0gYXJnc1twaS0+Z2V0 X3ByZWNdLmludGFyZzsNCiAJCXJldCArPSBfX3ByaW50Zl9wdXRzKCZpbywg cGktPmJlZ2luLCBwaS0+ZW5kIC0gcGktPmJlZ2luKTsNCi0JCWlmIChwcmlu dGZfdGJsW3BpLT5zcGVjXS5nbnVyZW5kZXIgIT0gTlVMTCkgew0KKwkJaWYg KHBpLT5hcmdfZmNuLT5nbnVyZW5kZXIgIT0gTlVMTCkgew0KIAkJCV9fcHJp bnRmX2ZsdXNoKCZpbyk7DQogCQkJcGktPnNvZmFyID0gcmV0Ow0KLQkJCXJl dCArPSBwcmludGZfdGJsW3BpLT5zcGVjXS5nbnVyZW5kZXIoDQorCQkJcmV0 ICs9IHBpLT5hcmdfZmNuLT5nbnVyZW5kZXIoDQogCQkJICAgIGZwLCBwaSwg KGNvbnN0IHZvaWQgKilwaS0+YXJnKTsNCi0JCX0gZWxzZSBpZiAocHJpbnRm X3RibFtwaS0+c3BlY10ucmVuZGVyICE9IE5VTEwpIHsNCisJCX0gZWxzZSBp ZiAocGktPmFyZ19mY24tPnJlbmRlciAhPSBOVUxMKSB7DQogCQkJcGktPnNv ZmFyID0gcmV0Ow0KLQkJCW4gPSBwcmludGZfdGJsW3BpLT5zcGVjXS5yZW5k ZXIoDQorCQkJbiA9IHBpLT5hcmdfZmNuLT5yZW5kZXIoDQogCQkJICAgICZp bywgcGksIChjb25zdCB2b2lkICopcGktPmFyZyk7DQogCQkJaWYgKG4gPCAw KQ0KIAkJCQlpby5mcC0+X2ZsYWdzIHw9IF9fU0VSUjsNCg== --0-256505370-1134842235=:97875-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 17 18:34:49 2005 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 01B8116A420; Sat, 17 Dec 2005 18:34:49 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BFDB43D49; Sat, 17 Dec 2005 18:34:48 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 12288BC66; Sat, 17 Dec 2005 18:34:47 +0000 (UTC) To: "Matthew N. Dodd" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 17 Dec 2005 12:57:15 EST." <20051217124717.H97875@sasami.jurai.net> Date: Sat, 17 Dec 2005 19:34:46 +0100 Message-ID: <27690.1134844486@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: current@FreeBSD.ORG Subject: Re: About extensible prinf(3), a slightly long X-mas card 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, 17 Dec 2005 18:34:49 -0000 In message <20051217124717.H97875@sasami.jurai.net>, "Matthew N. Dodd" writes: >I'd rather leave the single letter specifiers and modifiers to the >standards compliant printf and use something like %{foo} as the specifier >for extensions. Well, I would do 10 things different, but I don't see much point in adding yet another API just because we like it better that way, so I stuck with the GLIBC api. As far as i know, the upper-case letters apart from [DIOUXL] are available in all standards. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Sat Dec 17 18:50:46 2005 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 02AD616A41F; Sat, 17 Dec 2005 18:50:46 +0000 (GMT) (envelope-from tom.hurst@clara.net) Received: from spork.qfe3.net (spork.qfe3.net [212.13.207.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA80B43D6A; Sat, 17 Dec 2005 18:50:44 +0000 (GMT) (envelope-from tom.hurst@clara.net) Received: from [81.104.55.176] (helo=voi.aagh.net) by spork.qfe3.net with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Enh8g-000MED-BQ; Sat, 17 Dec 2005 18:50:38 +0000 Received: from freaky by voi.aagh.net with local (Exim 4.54 (FreeBSD)) id 1Enh8f-000Ao9-Qc; Sat, 17 Dec 2005 18:50:37 +0000 Date: Sat, 17 Dec 2005 18:50:37 +0000 From: Thomas Hurst To: =?iso-8859-1?Q?S=F8ren?= Schmidt Message-ID: <20051217185037.GA32331@voi.aagh.net> Mail-Followup-To: =?iso-8859-1?Q?S=F8ren?= Schmidt , Wilko Bulte , thron forum , freebsd-current@FreeBSD.ORG, =?iso-8859-1?Q?S=F8ren?= Schmidt References: <20051215194325.49909.qmail@web35908.mail.mud.yahoo.com> <43A1CCFE.10705@FreeBSD.org> <20051215201737.GA10846@freebie.xs4all.nl> <43A1D51D.7070804@deepcore.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43A1D51D.7070804@deepcore.dk> Organization: Not much. User-Agent: Mutt/1.5.11 Sender: Thomas Hurst X-RBL-Warning: 81.104.55.176 is in RBL blacklist at dnsbl.sorbs.net Cc: Wilko Bulte , =?iso-8859-1?Q?S=F8ren?= Schmidt , freebsd-current@FreeBSD.ORG, thron forum Subject: Re: Adaptec SATA 1205sa support for FreeBSD 6.0 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, 17 Dec 2005 18:50:46 -0000 * S?ren Schmidt (sos@deepcore.dk) wrote: > > Soren, what would you recommend for a plain SATA controller? > > Something Promise, a tx2 or tx4 depending on channels needed. What about their 8 port cards like the SX8, or the [ES]X8300? -- Thomas 'Freaky' Hurst http://hur.st/ From owner-freebsd-current@FreeBSD.ORG Sat Dec 17 18:59:37 2005 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 090BD16A41F for ; Sat, 17 Dec 2005 18:59:37 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn.pobox.com (vds.fauxbox.com [208.210.124.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9203043D46 for ; Sat, 17 Dec 2005 18:59:28 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id 5C836AC; Sat, 17 Dec 2005 13:59:49 -0500 (EST) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thorn.sasl.smtp.pobox.com (Postfix) with ESMTP id DB9A41FE7; Sat, 17 Dec 2005 13:59:46 -0500 (EST) Received: from lists by mappit.local.linnet.org with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EnhH9-0008xy-Pu; Sat, 17 Dec 2005 18:59:23 +0000 Date: Sat, 17 Dec 2005 18:59:23 +0000 From: Brian Candler To: Luigi Rizzo Message-ID: <20051217185923.GB34401@uk.tiscali.com> References: <20051217030513.A82342@xorpc.icir.org> <24068.1134818291@critter.freebsd.dk> <20051217032706.A82898@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051217032706.A82898@xorpc.icir.org> User-Agent: Mutt/1.4.2.1i Cc: Poul-Henning Kamp , current@freebsd.org Subject: Re: About extensible prinf(3), a slightly long X-mas card 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, 17 Dec 2005 18:59:37 -0000 On Sat, Dec 17, 2005 at 03:27:06AM -0800, Luigi Rizzo wrote: > are you saying that if you link a program that uses these extensions > with glibc it behaves as expected ? Then the portability issue > would disappear (i.e. moves elsewhere where hopefully it has been > solved already). Hmm, but that's easier said than done - e.g. I don't see glibc in ports. From owner-freebsd-current@FreeBSD.ORG Sat Dec 17 19:39:10 2005 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 373CE16A41F; Sat, 17 Dec 2005 19:39:10 +0000 (GMT) (envelope-from sos@deepcore.dk) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD1DE43D7E; Sat, 17 Dec 2005 19:38:48 +0000 (GMT) (envelope-from sos@deepcore.dk) Received: from [194.192.25.142] (spider.deepcore.dk [194.192.25.142]) by spider.deepcore.dk (8.13.4/8.13.4) with ESMTP id jBHJceM4078779; Sat, 17 Dec 2005 20:38:40 +0100 (CET) (envelope-from sos@deepcore.dk) Message-ID: <43A46940.3020407@deepcore.dk> Date: Sat, 17 Dec 2005 20:38:40 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Hurst References: <20051215194325.49909.qmail@web35908.mail.mud.yahoo.com> <43A1CCFE.10705@FreeBSD.org> <20051215201737.GA10846@freebie.xs4all.nl> <43A1D51D.7070804@deepcore.dk> <20051217185037.GA32331@voi.aagh.net> In-Reply-To: <20051217185037.GA32331@voi.aagh.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-mail-scanned: by DeepCore Virus & Spam killer v1.16 Cc: Wilko Bulte , =?ISO-8859-1?Q?S=F8ren_Schmidt?= , freebsd-current@FreeBSD.ORG, thron forum Subject: Re: Adaptec SATA 1205sa support for FreeBSD 6.0 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, 17 Dec 2005 19:39:10 -0000 Thomas Hurst wrote: > * S?ren Schmidt (sos@deepcore.dk) wrote: > > >>>Soren, what would you recommend for a plain SATA controller? >> >>Something Promise, a tx2 or tx4 depending on channels needed. > > > What about their 8 port cards like the SX8, or the [ES]X8300? I have drivers for both in the works but since this is spare time work there is no timeline, unless it important enough for someone to contract me to do it ASAP. The SX8 will be under ATA, but the EX83[50]0 will get their own driver as they are intelligent devices that doesn't fit the ATA driver model. -Sřren From owner-freebsd-current@FreeBSD.ORG Sat Dec 17 22:08:14 2005 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 BA15016A41F; Sat, 17 Dec 2005 22:08:14 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from smtp-vbr7.xs4all.nl (smtp-vbr7.xs4all.nl [194.109.24.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id BEB9143D5C; Sat, 17 Dec 2005 22:08:13 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp-vbr7.xs4all.nl (8.13.3/8.13.3) with ESMTP id jBHM8818024849; Sat, 17 Dec 2005 23:08:08 +0100 (CET) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.13.4/8.13.3) with ESMTP id jBHM87gT028757; Sat, 17 Dec 2005 23:08:07 +0100 (CET) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.13.4/8.13.1/Submit) id jBHM873S028756; Sat, 17 Dec 2005 23:08:07 +0100 (CET) (envelope-from wb) Date: Sat, 17 Dec 2005 23:08:07 +0100 From: Wilko Bulte To: Joe Rhett Message-ID: <20051217220807.GA28741@freebie.xs4all.nl> References: <43A266E5.3080103@samsco.org> <20051217215434.GB92180@svcolo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051217215434.GB92180@svcolo.com> X-OS: FreeBSD 6.0-STABLE User-Agent: Mutt/1.5.11 X-Virus-Scanned: by XS4ALL Virus Scanner Cc: stable@freebsd.org, current Subject: Re: HEADS UP: Release schedule for 2006 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, 17 Dec 2005 22:08:14 -0000 On Sat, Dec 17, 2005 at 01:54:34PM -0800, Joe Rhett wrote.. > On Fri, Dec 16, 2005 at 12:04:05AM -0700, Scott Long wrote: > > There will be three FreeBSD 6 releases in 2006. > > While this is nice, may I suggest that it is time to put aside/delay one > release cycle and come up with a binary update mechanism supported well by > the OS? Increasing the speed of releases is good. Increasing the number > of deployed systems out of date because there are no easy binary upgrade > mechanisms is bad. > > It has been bad, it's getting worse. So, when will you fix it? Or hire someone to fix it? FreeBSD after all is mostly a volunteer operation. -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sat Dec 17 22:19:00 2005 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 D5C9C16A41F; Sat, 17 Dec 2005 22:19:00 +0000 (GMT) (envelope-from wollman@khavrinen.csail.mit.edu) Received: from khavrinen.csail.mit.edu (khavrinen.csail.mit.edu [128.30.28.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id DDEA443D64; Sat, 17 Dec 2005 22:18:59 +0000 (GMT) (envelope-from wollman@khavrinen.csail.mit.edu) Received: from khavrinen.csail.mit.edu (localhost.csail.mit.edu [127.0.0.1]) by khavrinen.csail.mit.edu (8.13.1/8.13.4) with ESMTP id jBHMIwvs047481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.csail.mit.edu issuer=Client+20CA); Sat, 17 Dec 2005 17:18:58 -0500 (EST) (envelope-from wollman@khavrinen.csail.mit.edu) Received: (from wollman@localhost) by khavrinen.csail.mit.edu (8.13.1/8.13.4/Submit) id jBHMIvNb047478; Sat, 17 Dec 2005 17:18:57 -0500 (EST) (envelope-from wollman) From: Garrett Wollman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17316.36560.980457.783837@khavrinen.csail.mit.edu> Date: Sat, 17 Dec 2005 17:18:56 -0500 To: Alexander Leidinger In-Reply-To: <20051211010454.59a174cc@Magellan.Leidinger.net> References: <439AE13D.1040800@locolomo.org> <1134239935.685.8.camel@dude.automatvapen.se> <20051211010454.59a174cc@Magellan.Leidinger.net> X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" XEmacs Lucid X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-1.6 (khavrinen.csail.mit.edu [127.0.0.1]); Sat, 17 Dec 2005 17:18:58 -0500 (EST) X-Spam-Status: No, score=-0.0 required=5.0 tests=SPF_HELO_PASS,SPF_PASS version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on khavrinen.csail.mit.edu Cc: Erik =?UTF-8?B?TsO4cmdhYXJk?= , current@FreeBSD.ORG Subject: Re: Contacts for project idea list 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, 17 Dec 2005 22:19:01 -0000 < said: > something like this. Just do a PXE boot from a special server and you > get the box installed. I think the simplest implementation would be a > "boot a minimal system, parition the disk, extract an archive"-one. Many people have already implemented this. I am reluctant to release my version, for various reasons. -GAWollman From owner-freebsd-current@FreeBSD.ORG Sat Dec 17 22:47:35 2005 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 DDA0716A41F for ; Sat, 17 Dec 2005 22:47:35 +0000 (GMT) (envelope-from kaasboer@laverenz.de) Received: from natblindhugh.rzone.de (natblindhugh.rzone.de [81.169.145.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5762943D5C for ; Sat, 17 Dec 2005 22:47:34 +0000 (GMT) (envelope-from kaasboer@laverenz.de) Received: from athena.laverenz.de (p5480B104.dip.t-dialin.net [84.128.177.4]) by post.webmailer.de (8.13.1/8.13.1) with ESMTP id jBHMlVHs001463 for ; Sat, 17 Dec 2005 23:47:31 +0100 (MET) Received: from localhost (localhost.localdomain [127.0.0.1]) by athena.laverenz.de (Postfix) with ESMTP id 515DDE393C3A for ; Sat, 17 Dec 2005 23:47:31 +0100 (CET) Received: from athena.laverenz.de ([127.0.0.1]) by localhost (athena [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 24514-03 for ; Sat, 17 Dec 2005 23:47:30 +0100 (CET) Received: from localhost.localdomain (brianna.laverenz.de [192.168.100.88]) by athena.laverenz.de (Postfix) with ESMTP id 8C08AE393C39 for ; Sat, 17 Dec 2005 23:47:30 +0100 (CET) Received: by localhost.localdomain (Postfix, from userid 1000) id 87A565C00F5; Sat, 17 Dec 2005 23:47:28 +0100 (CET) Date: Sat, 17 Dec 2005 23:47:28 +0100 From: Uwe Laverenz To: freebsd-current@freebsd.org Message-ID: <20051217224728.GA7568@laverenz.de> References: <43A266E5.3080103@samsco.org> <20051217215434.GB92180@svcolo.com> <20051217220807.GA28741@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051217220807.GA28741@freebie.xs4all.nl> Organization: private site Sender: uwe@laverenz.de User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at laverenz.de Subject: Re: HEADS UP: Release schedule for 2006 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, 17 Dec 2005 22:47:36 -0000 On Sat, Dec 17, 2005 at 11:08:07PM +0100, Wilko Bulte wrote: > So, when will you fix it? Or hire someone to fix it? FreeBSD after > all is mostly a volunteer operation. Yes, this certainly is correct, and many users think this way. This might be the reason why we don't hear or read much about the existing problems and annoyances with FreeBSD, people just stay quiet. The problem is that this doesn't help to make things better, because many users will simply vote with their feet and quit using FreeBSD. Uwe From owner-freebsd-current@FreeBSD.ORG Sat Dec 17 22:53:27 2005 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 E104616A41F for ; Sat, 17 Dec 2005 22:53:27 +0000 (GMT) (envelope-from saturnero@freesbie.org) Received: from jail1-fbsd4.consiagnet.it (jail1-fbsd4.consiagnet.it [83.149.128.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63F7643D58 for ; Sat, 17 Dec 2005 22:53:27 +0000 (GMT) (envelope-from saturnero@freesbie.org) Received: by jail1-fbsd4.consiagnet.it (Postfix, from userid 1000) id D84BE57FE; Sat, 17 Dec 2005 23:59:39 +0100 (CET) Date: Sat, 17 Dec 2005 23:59:39 +0100 From: Dario Freni To: current@FreeBSD.org Message-ID: <20051217225939.GD9343@cvs.freesbie.org> References: <439AE13D.1040800@locolomo.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="iVCmgExH7+hIHJ1A" Content-Disposition: inline In-Reply-To: <439AE13D.1040800@locolomo.org> X-Operating-System: FreeBSD 4.10-STABLE (What else? ;) X-Sent-From: cvs.freesbie.org X-GPG-Key: http://www.saturnero.net/saturnero.asc X-GPG-Fingerprint: 9C23 3CED 32A4 1E6E 7F83 042F CA68 BBD8 8892 872B User-Agent: Mutt/1.5.9i Cc: Subject: Re: Contacts for project idea list 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, 17 Dec 2005 22:53:28 -0000 --iVCmgExH7+hIHJ1A Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 10, 2005 at 03:07:57PM +0100, Erik N?rgaard wrote: > Hi, >=20 > One on the questions-list pointed my attention to the PXE installer=20 > project on the project idea list http://www.freebsd.org/projects/ideas/ >=20 > There is no responsible for the project yet, nor are there any technical= =20 > contacts for the category (userland/installation tools) nor is there any= =20 > contact address for the idea-list maintainer. >=20 > So ... who came up with this idea? Who should I bug if I want to=20 > contribute to this? (re-sending to mailing list) This can be intepreted/implemented in many ways. As Alexander said, this can be a "dummy" installer which formats, partitions and install over the network. In my todo list, instead, there's (since at least one year) the idea to implement this with FreeSBIE and BSD Installer. BSD Installer was already ported to FreeSBIE one year ago, and the actual version of BSD Installer works with the new version of the FreeSBIE toolkit. It can be nice to have a dedicated version of FreeSBIE which ships with a dhcp server on it and can act as a PXE server, allowing clients to netboot into BSD Installer. If you agree, we can start working on it. Bye, Dario --=20 Dario Freni (saturnero@freesbie.org) FreeSBIE developer (http://www.freesbie.org) GPG Public key at http://www.saturnero.net/saturnero.asc --iVCmgExH7+hIHJ1A Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDpJhbymi72IiShysRAm7KAKCVwiTrH7T8CaGSLTLnazud9SD5lwCgpyH8 Uf+Rcps1gZhoQd3OsYymhR8= =iARH -----END PGP SIGNATURE----- --iVCmgExH7+hIHJ1A-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 17 23:15:09 2005 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 A70AC16A41F for ; Sat, 17 Dec 2005 23:15:09 +0000 (GMT) (envelope-from sullrich@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id C349843D5C for ; Sat, 17 Dec 2005 23:15:08 +0000 (GMT) (envelope-from sullrich@gmail.com) Received: by wproxy.gmail.com with SMTP id i31so893293wra for ; Sat, 17 Dec 2005 15:15:08 -0800 (PST) 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=BTTx62FNXayMEAvRCSFR3EReTXXJGSm4twIFSjARkT1gwmPwZFciHpUQu3bRsUI4LG9VI0bwd5GS9+TWdd8IJYKY40vrfnt2Hl8Y1L+9y9dBbpNWB7OHxatsqqxF9/Ja8wH0YoncyQhWQKt6negQpthK2BPK97udHJfOTdD5Zhs= Received: by 10.64.208.18 with SMTP id f18mr1175710qbg; Sat, 17 Dec 2005 15:15:07 -0800 (PST) Received: by 10.64.181.18 with HTTP; Sat, 17 Dec 2005 15:15:07 -0800 (PST) Message-ID: Date: Sat, 17 Dec 2005 18:15:07 -0500 From: Scott Ullrich To: Dario Freni In-Reply-To: <20051217225939.GD9343@cvs.freesbie.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <439AE13D.1040800@locolomo.org> <20051217225939.GD9343@cvs.freesbie.org> Cc: current@freebsd.org Subject: Re: Contacts for project idea list 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, 17 Dec 2005 23:15:09 -0000 Support already exists for NetBoot/PXE and works fine with DragonyFly. Last I tried (with FreeBSD 5) I ran into some type of issue that was fixed in DragonFly prior. I really wish that I can remember what the exact issue was but I cannot at this point. For all I know it may just work out of the box now with FreeBSD 6. I should give this a test soon. Scott On 12/17/05, Dario Freni wrote: > On Sat, Dec 10, 2005 at 03:07:57PM +0100, Erik N?rgaard wrote: > > Hi, > > > > One on the questions-list pointed my attention to the PXE installer > > project on the project idea list http://www.freebsd.org/projects/ideas/ > > > > There is no responsible for the project yet, nor are there any technica= l > > contacts for the category (userland/installation tools) nor is there an= y > > contact address for the idea-list maintainer. > > > > So ... who came up with this idea? Who should I bug if I want to > > contribute to this? > > (re-sending to mailing list) > > This can be intepreted/implemented in many ways. As Alexander said, > this can be a "dummy" installer which formats, partitions and install > over the network. > > In my todo list, instead, there's (since at least one year) the idea > to implement this with FreeSBIE and BSD Installer. BSD Installer was > already ported to FreeSBIE one year ago, and the actual version of BSD > Installer works with the new version of the FreeSBIE toolkit. > > It can be nice to have a dedicated version of FreeSBIE which ships > with a dhcp server on it and can act as a PXE server, allowing clients > to netboot into BSD Installer. If you agree, we can start working on > it. > > Bye, > Dario > > -- > Dario Freni (saturnero@freesbie.org) > FreeSBIE developer (http://www.freesbie.org) > GPG Public key at http://www.saturnero.net/saturnero.asc > > > From owner-freebsd-current@FreeBSD.ORG Sat Dec 17 23:29:00 2005 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 EDE2C16A41F; Sat, 17 Dec 2005 23:29:00 +0000 (GMT) (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 2C3B443D5A; Sat, 17 Dec 2005 23:28:59 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail23.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id jBHNSv79027788 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 18 Dec 2005 10:28:57 +1100 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.10/8.12.10) with ESMTP id jBHNSuHh088005; Sun, 18 Dec 2005 10:28:56 +1100 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost) by cirb503493.alcatel.com.au (8.12.10/8.12.9/Submit) id jBHNSuPf088004; Sun, 18 Dec 2005 10:28:56 +1100 (EST) (envelope-from pjeremy) Date: Sun, 18 Dec 2005 10:28:56 +1100 From: Peter Jeremy To: =?iso-8859-1?Q?K=F6vesd=E1n_G=E1bor?= Message-ID: <20051217232856.GT77268@cirb503493.alcatel.com.au> References: <43A266E5.3080103@samsco.org> <20051217215434.GB92180@svcolo.com> <20051217220807.GA28741@freebie.xs4all.nl> <43A492B6.6050305@t-hosting.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <43A492B6.6050305@t-hosting.hu> User-Agent: Mutt/1.4.2.1i X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc Cc: stable@freebsd.org, current Subject: Re: HEADS UP: Release schedule for 2006 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, 17 Dec 2005 23:29:01 -0000 On Sat, 2005-Dec-17 23:35:34 +0100, Kövesdán Gábor wrote: >I agree. And after all, tracking a security branch isn't too difficult, ... ># cd /usr/src ># patch < /path/to/patch ># cd /usr/src/gnu/usr.bin/cvs/cvsbug ># make obj && make depend && make && make install ># cd /usr/src/gnu/usr.bin/send-pr ># make obj && make depend && make && make install > >Is that difficult? Speaking as a developer, I think it's trivially easy. As an end user, I don't think this is acceptable. Firstly, it requires that the user has installed the src distribution - which is optional. Secondly, the user is expected to use development tools without understanding what they do - this is scary for them. Running the above commands is OK as long as nothing goes wrong but the "support" group (who inhabit -questions and answer seemingly silly questions) are going to have to cope with people who've made a typo somewhere in the sequence and can't explain exactly what they did - without putting them off FreeBSD. I think FreeBSD Update shows the way forward but IMHO there needs to be an "official" binary update tool accessible from www.freebsd.org. -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Sat Dec 17 23:46:48 2005 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 C39F216A41F; Sat, 17 Dec 2005 23:46:48 +0000 (GMT) (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 C43DF43D8D; Sat, 17 Dec 2005 23:46:28 +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 349321A3C27; Sat, 17 Dec 2005 15:46:28 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 6E2E751257; Sat, 17 Dec 2005 18:46:27 -0500 (EST) Date: Sat, 17 Dec 2005 18:46:27 -0500 From: Kris Kennaway To: Joe Rhett Message-ID: <20051217234627.GB68713@xor.obsecurity.org> References: <43A266E5.3080103@samsco.org> <20051217220021.GB93998@svcolo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mxv5cy4qt+RJ9ypb" Content-Disposition: inline In-Reply-To: <20051217220021.GB93998@svcolo.com> User-Agent: Mutt/1.4.2.1i Cc: stable@freebsd.org, current Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006) 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, 17 Dec 2005 23:46:48 -0000 --mxv5cy4qt+RJ9ypb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 17, 2005 at 02:00:21PM -0800, Joe Rhett wrote: > On Fri, Dec 16, 2005 at 12:04:05AM -0700, Scott Long wrote: > > There will be three FreeBSD 6 releases in 2006. >=20 > While this is nice, may I suggest that it is time to put aside/delay one > release cycle and come up with a binary update mechanism supported well by > the OS? Increasing the speed of releases is good. Increasing the number > of deployed systems out of date because there are no easy binary upgrade > mechanisms is bad. >=20 > It has been bad, it's getting worse. Suggestions are nice, but who do you think will work on solving this? Kris --mxv5cy4qt+RJ9ypb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDpKNTWry0BWjoQKURArrgAJ46xm5kLCiEpGDtHeWHA8L3fkjMCgCeLTiu UfX7Pm71Cu1oNGyQ+QHj3vc= =Qoqa -----END PGP SIGNATURE----- --mxv5cy4qt+RJ9ypb-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 17 23:55:06 2005 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 25EA316A41F; Sat, 17 Dec 2005 23:55:06 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7F4643D53; Sat, 17 Dec 2005 23:55:05 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id E768A5EA2; Sat, 17 Dec 2005 18:55:04 -0500 (EST) Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28850-03; Sat, 17 Dec 2005 18:55:04 -0500 (EST) Received: from [192.168.1.3] (pool-68-161-122-227.ny325.east.verizon.net [68.161.122.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id D0A8E5E80; Sat, 17 Dec 2005 18:55:03 -0500 (EST) Message-ID: <43A4A557.3010600@mac.com> Date: Sat, 17 Dec 2005 18:55:03 -0500 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Rhett References: <43A266E5.3080103@samsco.org> <20051217220021.GB93998@svcolo.com> In-Reply-To: <20051217220021.GB93998@svcolo.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at codefab.com Cc: stable@freebsd.org, current Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006) 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, 17 Dec 2005 23:55:06 -0000 Joe Rhett wrote: > On Fri, Dec 16, 2005 at 12:04:05AM -0700, Scott Long wrote: >>There will be three FreeBSD 6 releases in 2006. > > While this is nice, may I suggest that it is time to put aside/delay one > release cycle and come up with a binary update mechanism supported well by > the OS? Increasing the speed of releases is good. Increasing the number > of deployed systems out of date because there are no easy binary upgrade > mechanisms is bad. > > It has been bad, it's getting worse. YMMV. I burned a 6.0 release from the ISO image, and did a binary upgrade on an IBM ThinkPad (T.34? maybe), which worked perfectly. All of the 5.x binaries, including X11, KDE, printing, Mozilla, etc worked just fine. Upgrading the ports from there was somewhat annoying, as this guy's machine had ~400 or so, but deleting them all, and then using "pkg_add -r " works just fine if you want to grab the latest current binaries. From there you can portupgrade as usual. Now, if you want to talk about upgrading to intermediate patch releases, you've got a valid point there. :-) -- -Chuck