From owner-freebsd-current@FreeBSD.ORG Sun Aug 28 01:05: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 D2C0016A41F for ; Sun, 28 Aug 2005 01:05:35 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from smtp101.rog.mail.re2.yahoo.com (smtp101.rog.mail.re2.yahoo.com [206.190.36.79]) by mx1.FreeBSD.org (Postfix) with SMTP id 3D32243D46 for ; Sun, 28 Aug 2005 01:05:32 +0000 (GMT) (envelope-from mikej@rogers.com) Received: (qmail 87704 invoked from network); 28 Aug 2005 01:05:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:Message-ID:In-Reply-To:References:Date:Subject:From:To:Cc:User-Agent:MIME-Version:Content-Type:Content-Transfer-Encoding; b=QrUwATxs/qYzgCxqBQLm+C65QkgKn1jgQp5oSSi/z+IquI9r/ut0JYvmsjfPXcSz3zIABrS7njpFkWaDij9Xa1qcCfhhh8ElwV2svnKyqlG+VL9bxnxSwVlWbBVXWabcVLwmei11Trb8NmGIo6G/73pI4zcOr3X1ZrDGnX/QJvI= ; Received: from unknown (HELO 172.16.0.1) (mikej@70.31.50.81 with login) by smtp101.rog.mail.re2.yahoo.com with SMTP; 28 Aug 2005 01:05:32 -0000 Received: from 172.16.0.199 (SquirrelMail authenticated user mikej) by 172.16.0.1 with HTTP; Sat, 27 Aug 2005 21:05:31 -0400 (EDT) Message-ID: <1668.172.16.0.199.1125191131.squirrel@172.16.0.1> In-Reply-To: <20050827175151.GM26920@bunrab.catwhisker.org> References: <1268.172.16.0.199.1125164980.squirrel@172.16.0.1> <20050827175151.GM26920@bunrab.catwhisker.org> Date: Sat, 27 Aug 2005 21:05:31 -0400 (EDT) From: "Mike Jakubik" To: "David Wolfskill" User-Agent: SquirrelMail/1.5.1 [CVS] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: Creating own snap isos X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2005 01:05:35 -0000 On Sat, August 27, 2005 1:51 pm, David Wolfskill said: > On Sat, Aug 27, 2005 at 01:49:40PM -0400, Mike Jakubik wrote: > >> Can someone tell me or point to a resource explaining how one can >> create their own bootable install isos, based on their current source? >> Are there >> any tools provided to automate the process? > > I believe the process to research is called "make release." Thanks, i followed the man page instructions, but the process seems to stop with this error: --- ===> share/zoneinfo (install) umask 022; cd /usr/src/share/zoneinfo; zic -D -d /tmp/chroot/usr/share/zoneinfo -p America/New_York -u root -g wheel -m 444 -y /usr/obj/usr/src/share/zoneinfo/yearistype africa antarctica asia australasia etcetera europe factory northamerica southamerica systemv zic: can't link from /tmp/chroot/usr/share/zoneinfo/America/Indianapolis to /tmp/chroot/usr/share/zoneinfo/EST: No such file or directory *** Error code 1 Stop in /usr/src/share/zoneinfo. *** Error code 1 From owner-freebsd-current@FreeBSD.ORG Sun Aug 28 01:24: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 B9BA216A41F for ; Sun, 28 Aug 2005 01:24:29 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from nic.ach.sch.gr (nic.sch.gr [194.63.238.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA5FB43D45 for ; Sun, 28 Aug 2005 01:24:28 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: (qmail 19087 invoked by uid 207); 28 Aug 2005 01:24:27 -0000 Received: from keramida@freebsd.org by nic by uid 201 with qmail-scanner-1.21 (sophie: 3.04/2.19/3.81. Clear:RC:1(81.186.70.65):. Processed in 0.650424 secs); 28 Aug 2005 01:24:27 -0000 Received: from dialup65.ach.sch.gr (HELO gothmog.gr) ([81.186.70.65]) (envelope-sender ) by nic.sch.gr (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 28 Aug 2005 01:24:26 -0000 Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.13.4/8.13.4) with ESMTP id j7S1OJe4007103; Sun, 28 Aug 2005 04:24:19 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from giorgos@localhost) by gothmog.gr (8.13.4/8.13.4/Submit) id j7S1OJWN007102; Sun, 28 Aug 2005 04:24:19 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Sun, 28 Aug 2005 04:24:19 +0300 From: Giorgos Keramidas To: Mike Jakubik Message-ID: <20050828012419.GA7073@gothmog.gr> References: <1268.172.16.0.199.1125164980.squirrel@172.16.0.1> <20050827175151.GM26920@bunrab.catwhisker.org> <1668.172.16.0.199.1125191131.squirrel@172.16.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1668.172.16.0.199.1125191131.squirrel@172.16.0.1> Cc: freebsd-current@freebsd.org Subject: Re: Creating own snap isos X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2005 01:24:29 -0000 On 2005-08-27 21:05, Mike Jakubik wrote: >On Sat, August 27, 2005 1:51 pm, David Wolfskill said: >> On Sat, Aug 27, 2005 at 01:49:40PM -0400, Mike Jakubik wrote: >> >>> Can someone tell me or point to a resource explaining how one can >>> create their own bootable install isos, based on their current source? >>> Are there >>> any tools provided to automate the process? >> >> I believe the process to research is called "make release." > > Thanks, i followed the man page instructions, but the process seems to > stop with this error: > > ===> share/zoneinfo (install) > umask 022; cd /usr/src/share/zoneinfo; zic -D -d > /tmp/chroot/usr/share/zoneinfo -p America/New_York -u root -g wheel -m > 444 -y /usr/obj/usr/src/share/zoneinfo/yearistype africa antarctica asia > australasia etcetera europe factory northamerica southamerica systemv > zic: can't link from /tmp/chroot/usr/share/zoneinfo/America/Indianapolis > to /tmp/chroot/usr/share/zoneinfo/EST: No such file or directory > *** Error code 1 > > Stop in /usr/src/share/zoneinfo. > *** Error code 1 You're not using make's -j option, are you? If you are, then try without it and see if that works better. From owner-freebsd-current@FreeBSD.ORG Sun Aug 28 01:33: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 8F2FE16A41F for ; Sun, 28 Aug 2005 01:33:06 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from smtp104.rog.mail.re2.yahoo.com (smtp104.rog.mail.re2.yahoo.com [206.190.36.82]) by mx1.FreeBSD.org (Postfix) with SMTP id B659E43D45 for ; Sun, 28 Aug 2005 01:33:05 +0000 (GMT) (envelope-from mikej@rogers.com) Received: (qmail 24987 invoked from network); 28 Aug 2005 01:33:05 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:Message-ID:In-Reply-To:References:Date:Subject:From:To:Cc:User-Agent:MIME-Version:Content-Type:Content-Transfer-Encoding; b=JktSqYVwKDjEEs/giwsYAhe8pxLme1sZt2uJWuMBJiBOIOWGp/wqJ9gnPy1r1+UXCK+neeCl5duEdwZrwqNEY/pE5S8HZak9DKvNme5oJo5RzgudS18hkuODW0K3buea91EZXbsfANP+YjS5k9inZnSrk4tdo7iDLZ56F/Nnqas= ; Received: from unknown (HELO 172.16.0.1) (mikej@70.31.50.81 with login) by smtp104.rog.mail.re2.yahoo.com with SMTP; 28 Aug 2005 01:33:05 -0000 Received: from 172.16.0.199 (SquirrelMail authenticated user mikej) by 172.16.0.1 with HTTP; Sat, 27 Aug 2005 21:33:04 -0400 (EDT) Message-ID: <1854.172.16.0.199.1125192784.squirrel@172.16.0.1> In-Reply-To: <20050828012419.GA7073@gothmog.gr> References: <1268.172.16.0.199.1125164980.squirrel@172.16.0.1> <20050827175151.GM26920@bunrab.catwhisker.org> <1668.172.16.0.199.1125191131.squirrel@172.16.0.1> <20050828012419.GA7073@gothmog.gr> Date: Sat, 27 Aug 2005 21:33:04 -0400 (EDT) From: "Mike Jakubik" To: "Giorgos Keramidas" User-Agent: SquirrelMail/1.5.1 [CVS] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: Creating own snap isos X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2005 01:33:06 -0000 On Sat, August 27, 2005 9:24 pm, Giorgos Keramidas said: > On 2005-08-27 21:05, Mike Jakubik wrote: >> >> Thanks, i followed the man page instructions, but the process seems to >> stop with this error: >> >> ===> share/zoneinfo (install) >> umask 022; cd /usr/src/share/zoneinfo; zic -D -d >> /tmp/chroot/usr/share/zoneinfo -p America/New_York -u root -g wheel -m >> 444 -y /usr/obj/usr/src/share/zoneinfo/yearistype africa antarctica >> asia australasia etcetera europe factory northamerica southamerica >> systemv zic: can't link from >> /tmp/chroot/usr/share/zoneinfo/America/Indianapolis >> to /tmp/chroot/usr/share/zoneinfo/EST: No such file or directory *** >> Error code 1 >> >> >> Stop in /usr/src/share/zoneinfo. >> *** Error code 1 >> > > You're not using make's -j option, are you? If you are, then try > without it and see if that works better. No, i am not. root@fbsd.local:/usr/src/release# cvsup /etc/cvs-supfile && make release CHROOTDIR=/tmp/chroot CVSROOT=/usr/home/ncvs BUILDNAME=7.0-CURRENT MAKE_ISOS=YES From owner-freebsd-current@FreeBSD.ORG Sun Aug 28 01: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 B3EF116A41F for ; Sun, 28 Aug 2005 01:57:18 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6617B43D45 for ; Sun, 28 Aug 2005 01:57:18 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id DAD0946B86; Sat, 27 Aug 2005 21:57:17 -0400 (EDT) Date: Sun, 28 Aug 2005 02:57:17 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "M. Warner Losh" In-Reply-To: <20050827.120448.37592601.imp@bsdimp.com> Message-ID: <20050828025428.V43518@fledge.watson.org> References: <20050827181827.O24510@fledge.watson.org> <20050827.114013.35047360.imp@bsdimp.com> <20050827184153.A24510@fledge.watson.org> <20050827.120448.37592601.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: bzeeb-lists@lists.zabbadoz.net, freebsd-current@FreeBSD.org, dandee@volny.cz Subject: Re: LOR route vr0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2005 01:57:18 -0000 On Sat, 27 Aug 2005, M. Warner Losh wrote: > : Note that sets of ordered entries are terminated with a double-null. This > : declares that locks of type "tcp" preceed "tcpinp" which preceed > : "so_snd". > > So would I add "ed1" to the list or "network driver"? 'ed1' I think, but to be honest, I'm not sure how lock classes interact with WITNESS. John should be able to tell us, but you can take a look at the WITNESS tables by breaking into DDB and running "show witness", and see what it identifies it as? In some ways, "network driver" might actually be better as it would let us make universal assertions across drivers. > : If I had to guess, you do a media status update, which can cause routing > : socket events indicating the link went up or down. > > No link moditoring, since the ED card I'm testing has no mii bus. That > might be ANOTHER problem, but it isn't this one :-). Okidoki. > : I think this case should be OK, and we should document that as being the > : case using a hard-coded witness entry. > > rearranging the code in this case would be at the very least awkward. > Maybe quite difficult, but likely doable. I think we need to make the if_addr_mtx follow device driver mutexes in the lock order because device drivers have an explicit need to acquire it while frobbing state. I'll peruse the if_addr_mtx consuming code in the network stack and see if we accidentally call into anything (specifically device drivers) while holding the mutex. I meant not to, but I may have done. I think I was fairly careful to avoid calling the routing code while holding it. Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Sun Aug 28 01:59: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 BACF516A420 for ; Sun, 28 Aug 2005 01:59:06 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9827A43D6B for ; Sun, 28 Aug 2005 01:59:03 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 38C0546B86; Sat, 27 Aug 2005 21:59:03 -0400 (EDT) Date: Sun, 28 Aug 2005 02:59:03 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "M. Warner Losh" In-Reply-To: <20050827.124941.14976142.imp@bsdimp.com> Message-ID: <20050828025721.X43518@fledge.watson.org> References: <20050827181827.O24510@fledge.watson.org> <20050827.114013.35047360.imp@bsdimp.com> <20050827184153.A24510@fledge.watson.org> <20050827.124941.14976142.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: bzeeb-lists@lists.zabbadoz.net, freebsd-current@FreeBSD.org, dandee@volny.cz Subject: Re: LOR route vr0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2005 01:59:07 -0000 On Sat, 27 Aug 2005, M. Warner Losh wrote: > : You need to add an entry to subr_witness.c creating a graph edge between > : the softc lock and the routing lock. An example of an entry in > : subr_witness.c: > : > : /* > : * TCP/IP > : */ > : { "tcp", &lock_class_mtx_sleep }, > : { "tcpinp", &lock_class_mtx_sleep }, > : { "so_snd", &lock_class_mtx_sleep }, > : { NULL, NULL }, > : > : Note that sets of ordered entries are terminated with a double-null. This > : declares that locks of type "tcp" preceed "tcpinp" which preceed > : "so_snd". > > So you have to have locks of type tcp BEFORE you take out tcpinp type > locks? Correct. 'tcp' reflects the global TCP state tables (pcbinfo) locks, and 'tcpinp' is for individual PCBs. If you acquire first a tcpinp and then tcp, the above settings should cause WITNESS to generate a lock order warning. Likewise, both tcp and tcpinp preceed so_snd, so if you acquire a protocol lock after a socket lock, it will get unhappy. WITNESS handles transitive relationships, so it gets connected up to the rest of the lock graph, explicit and implicit, so indirect violations of orders are fully handled. Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Sun Aug 28 02:38: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 A1C6016A41F; Sun, 28 Aug 2005 02:38:02 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FAA243D46; Sun, 28 Aug 2005 02:38:02 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j7S2atwp020758; Sat, 27 Aug 2005 20:36:55 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 27 Aug 2005 20:37:14 -0600 (MDT) Message-Id: <20050827.203714.93196510.imp@bsdimp.com> To: rwatson@freebsd.org From: "M. Warner Losh" In-Reply-To: <20050828025721.X43518@fledge.watson.org> References: <20050827184153.A24510@fledge.watson.org> <20050827.124941.14976142.imp@bsdimp.com> <20050828025721.X43518@fledge.watson.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.village.org [127.0.0.1]); Sat, 27 Aug 2005 20:36:59 -0600 (MDT) Cc: bzeeb-lists@lists.zabbadoz.net, freebsd-current@freebsd.org, dandee@volny.cz Subject: Re: LOR route vr0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2005 02:38:02 -0000 In message: <20050828025721.X43518@fledge.watson.org> Robert Watson writes: : : On Sat, 27 Aug 2005, M. Warner Losh wrote: : : > : You need to add an entry to subr_witness.c creating a graph edge between : > : the softc lock and the routing lock. An example of an entry in : > : subr_witness.c: : > : : > : /* : > : * TCP/IP : > : */ : > : { "tcp", &lock_class_mtx_sleep }, : > : { "tcpinp", &lock_class_mtx_sleep }, : > : { "so_snd", &lock_class_mtx_sleep }, : > : { NULL, NULL }, : > : : > : Note that sets of ordered entries are terminated with a double-null. This : > : declares that locks of type "tcp" preceed "tcpinp" which preceed : > : "so_snd". : > : > So you have to have locks of type tcp BEFORE you take out tcpinp type : > locks? : : Correct. 'tcp' reflects the global TCP state tables (pcbinfo) locks, and : 'tcpinp' is for individual PCBs. If you acquire first a tcpinp and then : tcp, the above settings should cause WITNESS to generate a lock order : warning. Likewise, both tcp and tcpinp preceed so_snd, so if you acquire : a protocol lock after a socket lock, it will get unhappy. WITNESS handles : transitive relationships, so it gets connected up to the rest of the lock : graph, explicit and implicit, so indirect violations of orders are fully : handled. So I should make entries like: /* * Network driver */ { "network driver", &lock_class_mtx_sleep }, { "if_addr_mtx", &lock_class_mtx_sleep }, { NULL, NULL }, somewhere in the list? Warner From owner-freebsd-current@FreeBSD.ORG Sun Aug 28 03:49: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 EC77216A41F; Sun, 28 Aug 2005 03:49:46 +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 95E8043D45; Sun, 28 Aug 2005 03:49:46 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.3) id j7S3nhTH054574; Sat, 27 Aug 2005 22:49:43 -0500 (CDT) (envelope-from dan) Date: Sat, 27 Aug 2005 22:49:43 -0500 From: Dan Nelson To: Michael Bushkov Message-ID: <20050828034943.GE88693@dan.emsphone.com> References: <20050827170633.Y5409@stinger.cc.rsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050827170633.Y5409@stinger.cc.rsu.ru> X-OS: FreeBSD 5.4-STABLE X-message-flag: Outlook Error User-Agent: Mutt/1.5.9i Cc: Jacques Vidrine , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, Brooks Davis Subject: Re: [PATCH] caching daemon release and nsswitch patches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2005 03:49:47 -0000 In the last episode (Aug 27), Michael Bushkov said: > Please try the patches and send me your feedback. I also hope that > there are no reasons not to merge changes, which were made to libc > (they are in include.diff and libc.diff) into the CURRENT. As for the > caching daemon (usr.sbin.diff patch) - I also think that it could be > merged into the CURRENT. I applied the patches to 5-stable (only minor conflicts) and I'm getting an assertion failure in cached running "id" as root: Assertion failed: (key_var != NULL), function ht_item_hash_func, file /usr/src/usr.sbin/cached/cachelib/cachelib.c, line 34. You should probably convert cached's argument processing to use getopt, btw. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Sun Aug 28 04:03: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 EA2D716A420; Sun, 28 Aug 2005 04:03:41 +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 6B81943D45; Sun, 28 Aug 2005 04:03:41 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j7S42iA5021295; Sat, 27 Aug 2005 22:02:44 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 27 Aug 2005 22:03:03 -0600 (MDT) Message-Id: <20050827.220303.130848154.imp@bsdimp.com> To: rwatson@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20050828025721.X43518@fledge.watson.org> References: <20050827184153.A24510@fledge.watson.org> <20050827.124941.14976142.imp@bsdimp.com> <20050828025721.X43518@fledge.watson.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.village.org [127.0.0.1]); Sat, 27 Aug 2005 22:02:49 -0600 (MDT) Cc: bzeeb-lists@lists.zabbadoz.net, freebsd-current@FreeBSD.org, dandee@volny.cz Subject: Re: LOR route vr0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2005 04:03:42 -0000 In message: <20050828025721.X43518@fledge.watson.org> Robert Watson writes: : : On Sat, 27 Aug 2005, M. Warner Losh wrote: : : > : You need to add an entry to subr_witness.c creating a graph edge between : > : the softc lock and the routing lock. An example of an entry in : > : subr_witness.c: : > : : > : /* : > : * TCP/IP : > : */ : > : { "tcp", &lock_class_mtx_sleep }, : > : { "tcpinp", &lock_class_mtx_sleep }, : > : { "so_snd", &lock_class_mtx_sleep }, : > : { NULL, NULL }, : > : : > : Note that sets of ordered entries are terminated with a double-null. This : > : declares that locks of type "tcp" preceed "tcpinp" which preceed : > : "so_snd". : > : > So you have to have locks of type tcp BEFORE you take out tcpinp type : > locks? : : Correct. 'tcp' reflects the global TCP state tables (pcbinfo) locks, and : 'tcpinp' is for individual PCBs. If you acquire first a tcpinp and then : tcp, the above settings should cause WITNESS to generate a lock order : warning. Likewise, both tcp and tcpinp preceed so_snd, so if you acquire : a protocol lock after a socket lock, it will get unhappy. WITNESS handles : transitive relationships, so it gets connected up to the rest of the lock : graph, explicit and implicit, so indirect violations of orders are fully : handled. OK. I've been seeing similar LORs in ed, sn, iwi (ed is my locked version of ed, not in tree GIANT locked ed). I've made the following changes, and the LORs go away (except for one, which was unrelated). I further don't get the first place where they locks happen that caused the original LORs, so I'm mightly confused. ==== //depot/user/imp/newcard/kern/subr_witness.c#62 - /dell/imp/p4/newcard/src/sys/kern/subr_witness.c ==== @@ -273,6 +273,13 @@ { "allprison", &lock_class_mtx_sleep }, { NULL, NULL }, /* + * Network driver locking order + */ + { "rawinp", &lock_class_mtx_sleep }, + { MTX_NETWORK_LOCK, &lock_class_mtx_sleep }, + { "if_addr_mtx", &lock_class_mtx_sleep }, + { NULL, NULL }, + /* * Sockets */ { "filedesc structure", &lock_class_mtx_sleep }, @@ -309,6 +316,7 @@ { "udp", &lock_class_mtx_sleep }, { "udpinp", &lock_class_mtx_sleep }, { "so_snd", &lock_class_mtx_sleep }, + { MTX_NETWORK_LOCK, &lock_class_mtx_sleep }, { NULL, NULL }, /* * TCP/IP @@ -316,6 +324,7 @@ { "tcp", &lock_class_mtx_sleep }, { "tcpinp", &lock_class_mtx_sleep }, { "so_snd", &lock_class_mtx_sleep }, + { MTX_NETWORK_LOCK, &lock_class_mtx_sleep }, { NULL, NULL }, /* * SLIP I'm not sure if I need to add the if_addr_mtx after each thing or not. Clearly I've done something wrong :-(. I just don't see what. Warner From owner-freebsd-current@FreeBSD.ORG Sun Aug 28 04:20: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 B862A16A420 for ; Sun, 28 Aug 2005 04:20:17 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69B0243D48 for ; Sun, 28 Aug 2005 04:20:17 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id A212146C2D; Sun, 28 Aug 2005 00:20:16 -0400 (EDT) Date: Sun, 28 Aug 2005 05:20:13 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "M. Warner Losh" In-Reply-To: <20050827.220303.130848154.imp@bsdimp.com> Message-ID: <20050828051917.W52467@fledge.watson.org> References: <20050827184153.A24510@fledge.watson.org> <20050827.124941.14976142.imp@bsdimp.com> <20050828025721.X43518@fledge.watson.org> <20050827.220303.130848154.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: bzeeb-lists@lists.zabbadoz.net, freebsd-current@FreeBSD.org, dandee@volny.cz Subject: Re: LOR route vr0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2005 04:20:17 -0000 On Sat, 27 Aug 2005, M. Warner Losh wrote: > : Correct. 'tcp' reflects the global TCP state tables (pcbinfo) locks, and > : 'tcpinp' is for individual PCBs. If you acquire first a tcpinp and then > : tcp, the above settings should cause WITNESS to generate a lock order > : warning. Likewise, both tcp and tcpinp preceed so_snd, so if you acquire > : a protocol lock after a socket lock, it will get unhappy. WITNESS handles > : transitive relationships, so it gets connected up to the rest of the lock > : graph, explicit and implicit, so indirect violations of orders are fully > : handled. > > OK. I've been seeing similar LORs in ed, sn, iwi (ed is my locked > version of ed, not in tree GIANT locked ed). > > I've made the following changes, and the LORs go away (except for one, > which was unrelated). I further don't get the first place where they > locks happen that caused the original LORs, so I'm mightly confused. Hmm. I've seen another identical report recently -- that when a lock order is put into WITNESS, reversals against it are not reported. I wonder if we've got a witness bug on our hands? Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Sun Aug 28 07:34: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 152EF16A41F for ; Sun, 28 Aug 2005 07:34:59 +0000 (GMT) (envelope-from loader@freebsdmall.com) Received: from mail.freebsdmall.com (ns1.freebsdmall.com [69.50.233.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB4E943D46 for ; Sun, 28 Aug 2005 07:34:58 +0000 (GMT) (envelope-from loader@freebsdmall.com) Received: by mail.freebsdmall.com (Postfix, from userid 2136) id F0ABE1CE62; Sun, 28 Aug 2005 00:34:58 -0700 (PDT) X-Mailer: emacs 22.0.50.1 (via feedmail 8 I) To: freebsd-current@freebsd.org From: loader X-GPG-Public-Key: http://www.freebsdmall.com/~loader/loader.asc X-GPG-Key-ID: 1024D/0277E075 X-GPG-Key-Fingerprint: F8A0 A354 5D97 B175 7FC9 15DC 0771 07CF 0277 E075 Date: Sun, 28 Aug 2005 15:35:03 +0000 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: loader@freebsdmall.com Subject: Is it possible to setup a WPA ap with D-Link DWL-G520? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2005 07:34:59 -0000 http://www.dlink.com/products/?pid=12 ath0@pci2:2:0: class=0x020000 card=0x3a131186 chip=0x0013168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR5212, AR5213 802.11a/b/g Wireless Adapter' class = network subclass = ethernet If this adapter could work as a access point with WPA, could someone give me some hints about the settings? If it can't work, could you recommand another PCI adapter? Thanks in advance. Regards, loader From owner-freebsd-current@FreeBSD.ORG Sun Aug 28 07:52: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 2696516A41F for ; Sun, 28 Aug 2005 07:52:33 +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 20E4743D48 for ; Sun, 28 Aug 2005 07:52:31 +0000 (GMT) (envelope-from freebsd-listen@fabiankeil.de) Received: (qmail 3783 invoked from network); 28 Aug 2005 07:52:29 -0000 Received: from unknown (HELO localhost) ([pbs]775067@[217.187.179.145]) (envelope-sender ) by smtprelay01.ispgateway.de (qmail-ldap-1.03) with SMTP for ; 28 Aug 2005 07:52:29 -0000 Date: Sun, 28 Aug 2005 09:52:54 +0200 From: Fabian Keil To: Gavin Atkinson Message-ID: <20050828095254.3de97e88@localhost> In-Reply-To: <20050823133046.Q73182@ury.york.ac.uk> References: <20050821150125.56f992e0@localhost> <20050823133046.Q73182@ury.york.ac.uk> X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; 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="Signature_Sun__28_Aug_2005_09_52_54_+0200_5Dx/n+d95+o7E4jE"; protocol="application/pgp-signature"; micalg=pgp-sha1 Cc: freebsd-current@freebsd.org Subject: Re: Reproducible FreeBSD 6.0-BETA2 panic - probably ATA-ng related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2005 07:52:33 -0000 --Signature_Sun__28_Aug_2005_09_52_54_+0200_5Dx/n+d95+o7E4jE Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Gavin Atkinson wrote: > On Sun, 21 Aug 2005, Fabian Keil wrote: > > I own a Plextor PlexWriter Premium, the drive has a buggy firmware > > which crashes if you try to burn multi session in SAO mode. > > On FreeBSD 6.0-BETA2 a panic is caused: >=20 > [snip the CD ROM drive detaching...] =20 > It's a known issue. I see exactly this same panic 80% of the time on my= =20 > laptop on resume from ACPI suspend. I believe it was introduced during=20 > the newbus-ification of ATA-mk3. On the call to acd_geom_detach,=20 > acd_softc is already null. >=20 > (kgdb) f 23 > #23 0xc04dd936 in acd_geom_detach (arg=3D0xc16dd680, flag=3D0) > at /usr/src/sys/dev/ata/atapi-cd.c:199 > 199 g_wither_geom(cdp->gp, ENXIO); > (kgdb) list > 194 acd_geom_detach(void *arg, int flag) > 195 { > 196 struct acd_softc *cdp =3D device_get_ivars(arg); > 197 > 198 /* signal geom so we dont get any further requests */ > 199 g_wither_geom(cdp->gp, ENXIO); > 200 > 201 /* fail requests on the queue and any thats "in flight" for t= his device */ > 202 ata_fail_requests(arg); > 203 > (kgdb) p cdp > $5 =3D (struct acd_softc *) 0x0 Thanks for the information. Is this the problem you described in and did you already find the causing commit? Fabian --=20 http://www.fabiankeil.de/ --Signature_Sun__28_Aug_2005_09_52_54_+0200_5Dx/n+d95+o7E4jE Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFDEW1kjV8GA4rMKUQRAg2YAKDYgMIEBvaPQAVoN5EzCtJe0X5J/wCgpTVZ G3suL7JkztnR2SJS1cgKdK4= =gSG0 -----END PGP SIGNATURE----- --Signature_Sun__28_Aug_2005_09_52_54_+0200_5Dx/n+d95+o7E4jE-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 28 09:19: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 CDDD216A41F for ; Sun, 28 Aug 2005 09:19:54 +0000 (GMT) (envelope-from victor.cruceru@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D01B43D48 for ; Sun, 28 Aug 2005 09:19:54 +0000 (GMT) (envelope-from victor.cruceru@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so411712wri for ; Sun, 28 Aug 2005 02:19:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type; b=F4u68KhcaMsFHioJhotK8uS2OK1Ewrf0IvLDD5Y1WMvE0EMAt9F75cRCndvndcsAZ1LtYV4WtuajSLY8+EF1Xlqd9u0EuMuIWxifpnU9c5uWcdLkg93MN97OWK4r+rZUiQKMu2ZpprNbMzmyZW+t5uTrKQqfUQdP3vsnIP90fkw= Received: by 10.54.89.14 with SMTP id m14mr5147432wrb; Sun, 28 Aug 2005 02:19:53 -0700 (PDT) Received: by 10.54.91.20 with HTTP; Sun, 28 Aug 2005 02:19:53 -0700 (PDT) Message-ID: <494025505082802195dde06e@mail.gmail.com> Date: Sun, 28 Aug 2005 12:19:53 +0300 From: victor cruceru To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_13991_8873011.1125220793590" Subject: 6.0-BETA3: SATA HDD not detected X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: soc-victor@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: Sun, 28 Aug 2005 09:19:55 -0000 ------=_Part_13991_8873011.1125220793590 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, I've just tried the beta-3 install disk and my SAT HDD is still undetected by the new kernel. Please find attached to this email the dmesgs from the same pc (and the same bios settings) from 5.4 and this beta-3 for comparison. In 5.4 release the SATA hdd is working as a charm. BR, victor cruceru ------=_Part_13991_8873011.1125220793590 Content-Type: text/plain; name="dmesg_6_0_BETA3.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dmesg_6_0_BETA3.txt" Q29weXJpZ2h0IChjKSAxOTkyLTIwMDUgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIDYuMC1CRVRBMyAjMDogTW9uIEF1ZyAyMiAyMjo1OTo0NiBV VEMgMjAwNQogICAgcm9vdEBoYXJsb3cuY3NlLmJ1ZmZhbG8uZWR1Oi91c3Ivb2JqL3Vzci9zcmMv c3lzL0dFTkVSSUMKV0FSTklORzogV0lUTkVTUyBvcHRpb24gZW5hYmxlZCwgZXhwZWN0IHJlZHVj ZWQgcGVyZm9ybWFuY2UuClRpbWVjb3VudGVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMxODIgSHog cXVhbGl0eSAwCkNQVTogSW50ZWwoUikgUGVudGl1bShSKSA0IENQVSAzLjAwR0h6ICgzMDAwLjg2 LU1IeiA2ODYtY2xhc3MgQ1BVKQogIE9yaWdpbiA9ICJHZW51aW5lSW50ZWwiICBJZCA9IDB4ZjQx ICBTdGVwcGluZyA9IDEKICBGZWF0dXJlcz0weGJmZWJmYmZmPEZQVSxWTUUsREUsUFNFLFRTQyxN U1IsUEFFLE1DRSxDWDgsQVBJQyxTRVAsTVRSUixQR0UsTUNBLENNT1YsUEFULFBTRTM2LENMRkxV U0gsRFRTLEFDUEksTU1YLEZYU1IsU1NFLFNTRTIsU1MsSFRULFRNLFBCRT4KICBGZWF0dXJlczI9 MHg0NDFkPFNTRTMsUlNWRDIsTU9OLERTX0NQTCxDTlRYLUlELDxiMTQ+PgogIEh5cGVydGhyZWFk aW5nOiAyIGxvZ2ljYWwgQ1BVcwpyZWFsIG1lbW9yeSAgPSAxMDczNDE0MTQ0ICgxMDIzIE1CKQph dmFpbCBtZW1vcnkgPSAxMDM3MTY4NjQwICg5ODkgTUIpCkFDUEkgQVBJQyBUYWJsZTogPEEgTSBJ ICBPRU1BUElDID4KRnJlZUJTRC9TTVA6IE11bHRpcHJvY2Vzc29yIFN5c3RlbSBEZXRlY3RlZDog MiBDUFVzCiBjcHUwIChCU1ApOiBBUElDIElEOiAgMAogY3B1MSAoQVApOiBBUElDIElEOiAgMQpp b2FwaWMwOiBDaGFuZ2luZyBBUElDIElEIHRvIDIKaW9hcGljMCA8VmVyc2lvbiAxLjE+IGlycXMg MC0yMyBvbiBtb3RoZXJib2FyZApucHgwOiBbRkFTVF0KbnB4MDogPG1hdGggcHJvY2Vzc29yPiBv biBtb3RoZXJib2FyZApucHgwOiBJTlQgMTYgaW50ZXJmYWNlCmFjcGkwOiA8QSBNIEkgT0VNUlNE VD4gb24gbW90aGVyYm9hcmQKYWNwaTA6IFBvd2VyIEJ1dHRvbiAoZml4ZWQpCnBjaV9saW5rMDog PEFDUEkgUENJIExpbmsgTE5LQT4gaXJxIDExIG9uIGFjcGkwCnBjaV9saW5rMTogPEFDUEkgUENJ IExpbmsgTE5LQj4gaXJxIDEwIG9uIGFjcGkwCnBjaV9saW5rMjogPEFDUEkgUENJIExpbmsgTE5L Qz4gaXJxIDUgb24gYWNwaTAKcGNpX2xpbmszOiA8QUNQSSBQQ0kgTGluayBMTktEPiBpcnEgMTAg b24gYWNwaTAKcGNpX2xpbms0OiA8QUNQSSBQQ0kgTGluayBMTktFPiBpcnEgNSBvbiBhY3BpMApw Y2lfbGluazU6IDxBQ1BJIFBDSSBMaW5rIExOS0Y+IGlycSAxMCBvbiBhY3BpMApwY2lfbGluazY6 IDxBQ1BJIFBDSSBMaW5rIExOS0c+IGlycSA3IG9uIGFjcGkwCnBjaV9saW5rNzogPEFDUEkgUENJ IExpbmsgTE5LSD4gaXJxIDMgb24gYWNwaTAKVGltZWNvdW50ZXIgIkFDUEktZmFzdCIgZnJlcXVl bmN5IDM1Nzk1NDUgSHogcXVhbGl0eSAxMDAwCmFjcGlfdGltZXIwOiA8MjQtYml0IHRpbWVyIGF0 IDMuNTc5NTQ1TUh6PiBwb3J0IDB4ODA4LTB4ODBiIG9uIGFjcGkwCmNwdTA6IDxBQ1BJIENQVT4g b24gYWNwaTAKYWNwaV90aHJvdHRsZTA6IDxBQ1BJIENQVSBUaHJvdHRsaW5nPiBvbiBjcHUwCmNw dTE6IDxBQ1BJIENQVT4gb24gYWNwaTAKYWNwaV90aHJvdHRsZTE6IDxBQ1BJIENQVSBUaHJvdHRs aW5nPiBvbiBjcHUxCmFjcGlfdGhyb3R0bGUxOiBmYWlsZWQgdG8gYXR0YWNoIFBfQ05UCmRldmlj ZV9hdHRhY2g6IGFjcGlfdGhyb3R0bGUxIGF0dGFjaCByZXR1cm5lZCA2CnBjaWIwOiA8QUNQSSBI b3N0LVBDSSBicmlkZ2U+IHBvcnQgMHhjZjgtMHhjZmYgb24gYWNwaTAKcGNpMDogPEFDUEkgUENJ IGJ1cz4gb24gcGNpYjAKYWdwMDogPFNpUyA2NTUgaG9zdCB0byBBR1AgYnJpZGdlPiBtZW0gMHhm ODAwMDAwMC0weGZiZmZmZmZmIGF0IGRldmljZSAwLjAgb24gcGNpMApwY2liMTogPEFDUEkgUENJ LVBDSSBicmlkZ2U+IGF0IGRldmljZSAxLjAgb24gcGNpMApwY2kxOiA8QUNQSSBQQ0kgYnVzPiBv biBwY2liMQpwY2kxOiA8ZGlzcGxheSwgVkdBPiBhdCBkZXZpY2UgMC4wIChubyBkcml2ZXIgYXR0 YWNoZWQpCnBjaTE6IDxkaXNwbGF5PiBhdCBkZXZpY2UgMC4xIChubyBkcml2ZXIgYXR0YWNoZWQp CmlzYWIwOiA8UENJLUlTQSBicmlkZ2U+IGF0IGRldmljZSAyLjAgb24gcGNpMAppc2EwOiA8SVNB IGJ1cz4gb24gaXNhYjAKYXRhcGNpMDogPFNpUyA5NjQgVURNQTEzMyBjb250cm9sbGVyPiBwb3J0 IDB4MWYwLTB4MWY3LDB4M2Y2LDB4MTcwLTB4MTc3LDB4Mzc2LDB4ZmZhMC0weGZmYWYgYXQgZGV2 aWNlIDIuNSBvbiBwY2kwCmF0YTA6IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFwY2kwCmF0YTE6IDxB VEEgY2hhbm5lbCAxPiBvbiBhdGFwY2kwCnBjaTA6IDxtdWx0aW1lZGlhLCBhdWRpbz4gYXQgZGV2 aWNlIDIuNyAobm8gZHJpdmVyIGF0dGFjaGVkKQpvaGNpMDogPFNpUyA1NTcxIFVTQiBjb250cm9s bGVyPiBtZW0gMHhmZjZmYzAwMC0weGZmNmZjZmZmIGlycSAyMCBhdCBkZXZpY2UgMy4wIG9uIHBj aTAKb2hjaTA6IFtHSUFOVC1MT0NLRURdCnVzYjA6IE9IQ0kgdmVyc2lvbiAxLjAsIGxlZ2FjeSBz dXBwb3J0CnVzYjA6IFNNTSBkb2VzIG5vdCByZXNwb25kLCByZXNldHRpbmcKdXNiMDogPFNpUyA1 NTcxIFVTQiBjb250cm9sbGVyPiBvbiBvaGNpMAp1c2IwOiBVU0IgcmV2aXNpb24gMS4wCnVodWIw OiBTaVMgT0hDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDEKdWh1 YjA6IDMgcG9ydHMgd2l0aCAzIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCm9oY2kxOiA8U2lTIDU1 NzEgVVNCIGNvbnRyb2xsZXI+IG1lbSAweGZmNmZkMDAwLTB4ZmY2ZmRmZmYgaXJxIDIxIGF0IGRl dmljZSAzLjEgb24gcGNpMApvaGNpMTogW0dJQU5ULUxPQ0tFRF0KdXNiMTogT0hDSSB2ZXJzaW9u IDEuMCwgbGVnYWN5IHN1cHBvcnQKdXNiMTogU01NIGRvZXMgbm90IHJlc3BvbmQsIHJlc2V0dGlu Zwp1c2IxOiA8U2lTIDU1NzEgVVNCIGNvbnRyb2xsZXI+IG9uIG9oY2kxCnVzYjE6IFVTQiByZXZp c2lvbiAxLjAKdWh1YjE6IFNpUyBPSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEu MDAsIGFkZHIgMQp1aHViMTogMyBwb3J0cyB3aXRoIDMgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQK b2hjaTI6IDxTaVMgNTU3MSBVU0IgY29udHJvbGxlcj4gbWVtIDB4ZmY2ZmUwMDAtMHhmZjZmZWZm ZiBpcnEgMjIgYXQgZGV2aWNlIDMuMiBvbiBwY2kwCm9oY2kyOiBbR0lBTlQtTE9DS0VEXQp1c2Iy OiBPSENJIHZlcnNpb24gMS4wLCBsZWdhY3kgc3VwcG9ydAp1c2IyOiBTTU0gZG9lcyBub3QgcmVz cG9uZCwgcmVzZXR0aW5nCnVzYjI6IDxTaVMgNTU3MSBVU0IgY29udHJvbGxlcj4gb24gb2hjaTIK dXNiMjogVVNCIHJldmlzaW9uIDEuMAp1aHViMjogU2lTIE9IQ0kgcm9vdCBodWIsIGNsYXNzIDkv MCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxCnVodWIyOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUs IHNlbGYgcG93ZXJlZAplaGNpMDogPEVIQ0kgKGdlbmVyaWMpIFVTQiAyLjAgY29udHJvbGxlcj4g bWVtIDB4ZmY2ZmYwMDAtMHhmZjZmZmZmZiBpcnEgMjMgYXQgZGV2aWNlIDMuMyBvbiBwY2kwCmVo Y2kwOiBbR0lBTlQtTE9DS0VEXQp1c2IzOiBFSENJIHZlcnNpb24gMS4wCnVzYjM6IGNvbXBhbmlv biBjb250cm9sbGVycywgMyBwb3J0cyBlYWNoOiB1c2IwIHVzYjEgdXNiMgp1c2IzOiA8RUhDSSAo Z2VuZXJpYykgVVNCIDIuMCBjb250cm9sbGVyPiBvbiBlaGNpMAp1c2IzOiBVU0IgcmV2aXNpb24g Mi4wCnVodWIzOiBTaVMgRUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMi4wMC8xLjAwLCBh ZGRyIDEKdWh1YjM6IDggcG9ydHMgd2l0aCA4IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnNpczA6 IDxTaVMgOTAwIDEwLzEwMEJhc2VUWD4gcG9ydCAweGU0MDAtMHhlNGZmIG1lbSAweGZmNmZiMDAw LTB4ZmY2ZmJmZmYgaXJxIDE5IGF0IGRldmljZSA0LjAgb24gcGNpMAptaWlidXMwOiA8TUlJIGJ1 cz4gb24gc2lzMApybHBoeTA6IDxSVEw4MjAxTCAxMC8xMDAgbWVkaWEgaW50ZXJmYWNlPiBvbiBt aWlidXMwCnJscGh5MDogIDEwYmFzZVQsIDEwYmFzZVQtRkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VU WC1GRFgsIGF1dG8Kc2lzMDogRXRoZXJuZXQgYWRkcmVzczogMDA6MTE6ZDg6MGE6ZTc6ZWEKYXRh cGNpMTogPFNpUyAxODAgU0FUQTE1MCBjb250cm9sbGVyPiBwb3J0IDB4ZWZmMC0weGVmZjcsMHhl ZmU0LTB4ZWZlNywweGVmYTgtMHhlZmFmLDB4ZWZlMC0weGVmZTMsMHhlZjkwLTB4ZWY5ZiBpcnEg MTcgYXQgZGV2aWNlIDUuMCBvbiBwY2kwCmF0YTI6IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFwY2kx CmF0YTM6IDxBVEEgY2hhbm5lbCAxPiBvbiBhdGFwY2kxCmFjcGlfYnV0dG9uMDogPFBvd2VyIEJ1 dHRvbj4gb24gYWNwaTAKYXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4gcG9y dCAweDYwLDB4NjQgaXJxIDEgb24gYWNwaTAKYXRrYmQwOiA8QVQgS2V5Ym9hcmQ+IGlycSAxIG9u IGF0a2JkYzAKa2JkMCBhdCBhdGtiZDAKYXRrYmQwOiBbR0lBTlQtTE9DS0VEXQpmZGMwOiA8Zmxv cHB5IGRyaXZlIGNvbnRyb2xsZXIgKEZERSk+IHBvcnQgMHgzZjAtMHgzZjUsMHgzZjcgaXJxIDYg ZHJxIDIgb24gYWNwaTAKZmRjMDogW0ZBU1RdCmZkMDogPDE0NDAtS0IgMy41IiBkcml2ZT4gb24g ZmRjMCBkcml2ZSAwCnNpbzA6IGNvbmZpZ3VyZWQgaXJxIDQgbm90IGluIGJpdG1hcCBvZiBwcm9i ZWQgaXJxcyAwCnNpbzA6IHBvcnQgbWF5IG5vdCBiZSBlbmFibGVkCnNpbzA6IDwxNjU1MEEtY29t cGF0aWJsZSBDT00gcG9ydD4gcG9ydCAweDNmOC0weDNmZiBpcnEgNCBmbGFncyAweDEwIG9uIGFj cGkwCnNpbzA6IHR5cGUgMTY1NTBBCnBtdGltZXIwIG9uIGlzYTAKb3JtMDogPElTQSBPcHRpb24g Uk9Ncz4gYXQgaW9tZW0gMHhjMDAwMC0weGNjZmZmLDB4Y2QwMDAtMHhkNGZmZiBvbiBpc2EwCnBw YzA6IHBhcmFsbGVsIHBvcnQgbm90IGZvdW5kLgpzYzA6IDxTeXN0ZW0gY29uc29sZT4gYXQgZmxh Z3MgMHgxMDAgb24gaXNhMApzYzA6IFZHQSA8MTYgdmlydHVhbCBjb25zb2xlcywgZmxhZ3M9MHgz MDA+CnNpbzE6IGNvbmZpZ3VyZWQgaXJxIDMgbm90IGluIGJpdG1hcCBvZiBwcm9iZWQgaXJxcyAw CnNpbzE6IHBvcnQgbWF5IG5vdCBiZSBlbmFibGVkCnZnYTA6IDxHZW5lcmljIElTQSBWR0E+IGF0 IHBvcnQgMHgzYzAtMHgzZGYgaW9tZW0gMHhhMDAwMC0weGJmZmZmIG9uIGlzYTAKdW1zMDogTG9n aXRlY2ggVVNCLVBTLzIgT3B0aWNhbCBNb3VzZSwgcmV2IDIuMDAvMTEuMTAsIGFkZHIgMiwgaWNs YXNzIDMvMQp1bXMwOiAzIGJ1dHRvbnMgYW5kIFogZGlyLgpUaW1lY291bnRlcnMgdGljayBldmVy eSAxLjAwMCBtc2VjCm1kMDogUHJlbG9hZGVkIGltYWdlIDwvYm9vdC9tZnNyb290PiA0NDIzNjgw IGJ5dGVzIGF0IDB4YzBhODAzNzgKYWNkMDogRFZEUiA8VE9TSElCQSBDRC9EVkRXIFNELVI1Mzcy L1RVNTU+IGF0IGF0YTAtbWFzdGVyIFVETUEzMwpTTVA6IEFQIENQVSAjMSBMYXVuY2hlZCEKVHJ5 aW5nIHRvIG1vdW50IHJvb3QgZnJvbSB1ZnM6L2Rldi9tZDAKV2FpdGluZyAobWF4IDYwIHNlY29u ZHMpIGZvciBzeXN0ZW0gcHJvY2VzcyBgdm5scnUnIHRvIHN0b3AuLi5kb25lCldhaXRpbmcgKG1h eCA2MCBzZWNvbmRzKSBmb3Igc3lzdGVtIHByb2Nlc3MgYGJ1ZmRhZW1vbicgdG8gc3RvcC4uLmRv bmUKV2FpdGluZyAobWF4IDYwIHNlY29uZHMpIGZvciBzeXN0ZW0gcHJvY2VzcyBgc3luY2VyJyB0 byBzdG9wLi4uClN5bmNpbmcgZGlza3MsIHZub2RlcyByZW1haW5pbmcuLi4zIDAgZG9uZQpBbGwg YnVmZmVycyBzeW5jZWQuCnVubW91bnQgb2YgL2RldiBmYWlsZWQgKEJVU1kpCkNvcHlyaWdodCAo YykgMTk5Mi0yMDA1IFRoZSBGcmVlQlNEIFByb2plY3QuCkNvcHlyaWdodCAoYykgMTk3OSwgMTk4 MCwgMTk4MywgMTk4NiwgMTk4OCwgMTk4OSwgMTk5MSwgMTk5MiwgMTk5MywgMTk5NAoJVGhlIFJl Z2VudHMgb2YgdGhlIFVuaXZlcnNpdHkgb2YgQ2FsaWZvcm5pYS4gQWxsIHJpZ2h0cyByZXNlcnZl ZC4KRnJlZUJTRCA2LjAtQkVUQTMgIzA6IE1vbiBBdWcgMjIgMjI6NTk6NDYgVVRDIDIwMDUKICAg IHJvb3RAaGFybG93LmNzZS5idWZmYWxvLmVkdTovdXNyL29iai91c3Ivc3JjL3N5cy9HRU5FUklD CldBUk5JTkc6IFdJVE5FU1Mgb3B0aW9uIGVuYWJsZWQsIGV4cGVjdCByZWR1Y2VkIHBlcmZvcm1h bmNlLgpQcmVsb2FkZWQgZWxmIGtlcm5lbCAiL2Jvb3Qva2VybmVsL2tlcm5lbCIgYXQgMHhjMGYx MjAwMC4KUHJlbG9hZGVkIG1mc19yb290ICIvYm9vdC9tZnNyb290IiBhdCAweGMwZjEyMTgwLgpQ cmVsb2FkZWQgZWxmIG1vZHVsZSAiL2Jvb3Qva2VybmVsL2FjcGkua28iIGF0IDB4YzBmMTIxYzQu CkNhbGlicmF0aW5nIGNsb2NrKHMpIC4uLiBpODI1NCBjbG9jazogMTE5MzI5NyBIegpDTEtfVVNF X0k4MjU0X0NBTElCUkFUSU9OIG5vdCBzcGVjaWZpZWQgLSB1c2luZyBkZWZhdWx0IGZyZXF1ZW5j eQpUaW1lY291bnRlciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgyIEh6IHF1YWxpdHkgMApDYWxp YnJhdGluZyBUU0MgY2xvY2sgLi4uIFRTQyBjbG9jazogMzAwMDg2ODYxMyBIegpDUFU6IEludGVs KFIpIFBlbnRpdW0oUikgNCBDUFUgMy4wMEdIeiAoMzAwMC44Ny1NSHogNjg2LWNsYXNzIENQVSkK ICBPcmlnaW4gPSAiR2VudWluZUludGVsIiAgSWQgPSAweGY0MSAgU3RlcHBpbmcgPSAxCiAgRmVh dHVyZXM9MHhiZmViZmJmZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNSLFBBRSxNQ0UsQ1g4LEFQSUMs U0VQLE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxQU0UzNixDTEZMVVNILERUUyxBQ1BJLE1NWCxGWFNS LFNTRSxTU0UyLFNTLEhUVCxUTSxQQkU+CiAgRmVhdHVyZXMyPTB4NDQxZDxTU0UzLFJTVkQyLE1P TixEU19DUEwsQ05UWC1JRCw8YjE0Pj4KICBIeXBlcnRocmVhZGluZzogMiBsb2dpY2FsIENQVXMK cmVhbCBtZW1vcnkgID0gMTA3MzQxNDE0NCAoMTAyMyBNQikKUGh5c2ljYWwgbWVtb3J5IGNodW5r KHMpOgoweDAwMDAwMDAwMDAwMDEwMDAgLSAweDAwMDAwMDAwMDAwOWVmZmYsIDY0NzE2OCBieXRl cyAoMTU4IHBhZ2VzKQoweDAwMDAwMDAwMDAxMDAwMDAgLSAweDAwMDAwMDAwMDAzZmZmZmYsIDMx NDU3MjggYnl0ZXMgKDc2OCBwYWdlcykKMHgwMDAwMDAwMDAxMDI4MDAwIC0gMHgwMDAwMDAwMDNl ZDc4ZmZmLCAxMDM3MzczNDQwIGJ5dGVzICgyNTMyNjUgcGFnZXMpCmF2YWlsIG1lbW9yeSA9IDEw MzcxNjg2NDAgKDk4OSBNQikKVGFibGUgJ0ZBQ1AnIGF0IDB4M2ZmYjAyMDAKVGFibGUgJ0FQSUMn IGF0IDB4M2ZmYjAzOTAKTUFEVDogRm91bmQgdGFibGUgYXQgMHgzZmZiMDM5MApBUElDOiBVc2lu ZyB0aGUgTUFEVCBlbnVtZXJhdG9yLgpNQURUOiBGb3VuZCBDUFUgQVBJQyBJRCAwIEFDUEkgSUQg MTogZW5hYmxlZApTTVA6IEFkZGVkIENQVSAwIChBUCkKTUFEVDogRm91bmQgQ1BVIEFQSUMgSUQg MSBBQ1BJIElEIDI6IGVuYWJsZWQKU01QOiBBZGRlZCBDUFUgMSAoQVApCkFDUEkgQVBJQyBUYWJs ZTogPEEgTSBJICBPRU1BUElDID4KQVBJQyBJRDogcGh5c2ljYWwgMCwgbG9naWNhbCAwOjAKQVBJ QyBJRDogcGh5c2ljYWwgMSwgbG9naWNhbCAwOjEKRnJlZUJTRC9TTVA6IE11bHRpcHJvY2Vzc29y IFN5c3RlbSBEZXRlY3RlZDogMiBDUFVzCiBjcHUwIChCU1ApOiBBUElDIElEOiAgMAogY3B1MSAo QVApOiBBUElDIElEOiAgMQpiaW9zMzI6IEZvdW5kIEJJT1MzMiBTZXJ2aWNlIERpcmVjdG9yeSBo ZWFkZXIgYXQgMHhjMDBmMDAwMApiaW9zMzI6IEVudHJ5ID0gMHhmMDAxMCAoYzAwZjAwMTApICBS ZXYgPSAwICBMZW4gPSAxCnBjaWJpb3M6IFBDSSBCSU9TIGVudHJ5IGF0IDB4ZjAwMDArMHgzMQpw bnBiaW9zOiBGb3VuZCBQblAgQklPUyBkYXRhIGF0IDB4YzAwZjZhZTAKcG5wYmlvczogRW50cnkg PSBmMDAwMDo3NmRhICBSZXYgPSAxLjAKT3RoZXIgQklPUyBzaWduYXR1cmVzIGZvdW5kOgpBUElD OiBDUFUgMCBoYXMgQUNQSSBJRCAxCkFQSUM6IENQVSAxIGhhcyBBQ1BJIElEIDIKTUFEVDogRm91 bmQgSU8gQVBJQyBJRCAyLCBJbnRlcnJ1cHQgMCBhdCAweGZlYzAwMDAwCmlvYXBpYzA6IENoYW5n aW5nIEFQSUMgSUQgdG8gMgppb2FwaWMwOiBSb3V0aW5nIGV4dGVybmFsIDgyNTlBJ3MgLT4gaW50 cGluIDAKaW9hcGljMDogaW50cGluIDAgLT4gRXh0SU5UIChlZGdlLCBoaWdoKQppb2FwaWMwOiBp bnRwaW4gMSAtPiBJU0EgSVJRIDEgKGVkZ2UsIGhpZ2gpCmlvYXBpYzA6IGludHBpbiAyIC0+IElT QSBJUlEgMiAoZWRnZSwgaGlnaCkKaW9hcGljMDogaW50cGluIDMgLT4gSVNBIElSUSAzIChlZGdl LCBoaWdoKQppb2FwaWMwOiBpbnRwaW4gNCAtPiBJU0EgSVJRIDQgKGVkZ2UsIGhpZ2gpCmlvYXBp YzA6IGludHBpbiA1IC0+IElTQSBJUlEgNSAoZWRnZSwgaGlnaCkKaW9hcGljMDogaW50cGluIDYg LT4gSVNBIElSUSA2IChlZGdlLCBoaWdoKQppb2FwaWMwOiBpbnRwaW4gNyAtPiBJU0EgSVJRIDcg KGVkZ2UsIGhpZ2gpCmlvYXBpYzA6IGludHBpbiA4IC0+IElTQSBJUlEgOCAoZWRnZSwgaGlnaCkK aW9hcGljMDogaW50cGluIDkgLT4gSVNBIElSUSA5IChlZGdlLCBoaWdoKQppb2FwaWMwOiBpbnRw aW4gMTAgLT4gSVNBIElSUSAxMCAoZWRnZSwgaGlnaCkKaW9hcGljMDogaW50cGluIDExIC0+IElT QSBJUlEgMTEgKGVkZ2UsIGhpZ2gpCmlvYXBpYzA6IGludHBpbiAxMiAtPiBJU0EgSVJRIDEyIChl ZGdlLCBoaWdoKQppb2FwaWMwOiBpbnRwaW4gMTMgLT4gSVNBIElSUSAxMyAoZWRnZSwgaGlnaCkK aW9hcGljMDogaW50cGluIDE0IC0+IElTQSBJUlEgMTQgKGVkZ2UsIGhpZ2gpCmlvYXBpYzA6IGlu dHBpbiAxNSAtPiBJU0EgSVJRIDE1IChlZGdlLCBoaWdoKQppb2FwaWMwOiBpbnRwaW4gMTYgLT4g UENJIElSUSAxNiAobGV2ZWwsIGxvdykKaW9hcGljMDogaW50cGluIDE3IC0+IFBDSSBJUlEgMTcg KGxldmVsLCBsb3cpCmlvYXBpYzA6IGludHBpbiAxOCAtPiBQQ0kgSVJRIDE4IChsZXZlbCwgbG93 KQppb2FwaWMwOiBpbnRwaW4gMTkgLT4gUENJIElSUSAxOSAobGV2ZWwsIGxvdykKaW9hcGljMDog aW50cGluIDIwIC0+IFBDSSBJUlEgMjAgKGxldmVsLCBsb3cpCmlvYXBpYzA6IGludHBpbiAyMSAt PiBQQ0kgSVJRIDIxIChsZXZlbCwgbG93KQppb2FwaWMwOiBpbnRwaW4gMjIgLT4gUENJIElSUSAy MiAobGV2ZWwsIGxvdykKaW9hcGljMDogaW50cGluIDIzIC0+IFBDSSBJUlEgMjMgKGxldmVsLCBs b3cpCk1BRFQ6IEludGVycnVwdCBvdmVycmlkZTogc291cmNlIDAsIGlycSAyCmlvYXBpYzA6IFJv dXRpbmcgSVJRIDAgLT4gaW50cGluIDIKaW9hcGljMDogaW50cGluIDIgdHJpZ2dlcjogZWRnZQpp b2FwaWMwOiBpbnRwaW4gMiBwb2xhcml0eTogaGlnaApNQURUOiBJbnRlcnJ1cHQgb3ZlcnJpZGU6 IHNvdXJjZSA5LCBpcnEgOQppb2FwaWMwOiBpbnRwaW4gOSB0cmlnZ2VyOiBsZXZlbAppb2FwaWMw OiBpbnRwaW4gOSBwb2xhcml0eTogbG93CmlvYXBpYzAgPFZlcnNpb24gMS4xPiBpcnFzIDAtMjMg b24gbW90aGVyYm9hcmQKY3B1MCBCU1A6CiAgICAgSUQ6IDB4MDAwMDAwMDAgICBWRVI6IDB4MDAw NTAwMTQgTERSOiAweDAxMDAwMDAwIERGUjogMHgwZmZmZmZmZgogIGxpbnQwOiAweDAwMDEwNzAw IGxpbnQxOiAweDAwMDAwNDAwIFRQUjogMHgwMDAwMDAwMCBTVlI6IDB4MDAwMDAxZmYKICB0aW1l cjogMHgwMDAxMDBlZiB0aGVybTogMHgwMDAxMDAwMCBlcnI6IDB4MDAwMTAwMGYgcGNtOiAweDAw MDEwMDAwCndsYW46IDw4MDIuMTEgTGluayBMYXllcj4KcmFuZG9tOiA8ZW50cm9weSBzb3VyY2Us IFNvZnR3YXJlLCBZYXJyb3c+Cm5mc2xvY2s6IHBzZXVkby1kZXZpY2UKaW86IDxJL08+Cm1lbTog PG1lbW9yeT4KUGVudGl1bSBQcm8gTVRSUiBzdXBwb3J0IGVuYWJsZWQKbnVsbDogPG51bGwgZGV2 aWNlLCB6ZXJvIGRldmljZT4KbnB4MDogW0ZBU1RdCm5weDA6IDxtYXRoIHByb2Nlc3Nvcj4gb24g bW90aGVyYm9hcmQKbnB4MDogSU5UIDE2IGludGVyZmFjZQphY3BpMDogPEEgTSBJIE9FTVJTRFQ+ IG9uIG1vdGhlcmJvYXJkCmFjcGkwOiBbTVBTQUZFXQpwY2lfb3BlbigxKToJbW9kZSAxIGFkZHIg cG9ydCAoMHgwY2Y4KSBpcyAweDgwMDAxMGM4CnBjaV9vcGVuKDFhKToJbW9kZTFyZXM9MHg4MDAw MDAwMCAoMHg4MDAwMDAwMCkKcGNpX2NmZ2NoZWNrOglkZXZpY2UgMCBbY2xhc3M9MDYwMDAwXSBb aGRyPTgwXSBpcyB0aGVyZSAoaWQ9MDY1NTEwMzkpCnBjaWJpb3M6IEJJT1MgdmVyc2lvbiAyLjEw CkZvdW5kICRQSVIgdGFibGUsIDEwIGVudHJpZXMgYXQgMHhjMDBmNjliMApQQ0ktT25seSBJbnRl cnJ1cHRzOiBub25lCkxvY2F0aW9uICBCdXMgRGV2aWNlIFBpbiAgTGluayAgSVJRcwplbWJlZGRl ZCAgICAwICAgIDIgICAgQSAgIDB4NDEgIDMgNCA1IDcgMTAgMTEgMTIgMTQgMTUKZW1iZWRkZWQg ICAgMCAgICAyICAgIEIgICAweDQyICAzIDQgNSA3IDEwIDExIDEyIDE0IDE1CmVtYmVkZGVkICAg IDAgICAgMiAgICBDICAgMHg0MyAgMyA0IDUgNyAxMCAxMSAxMiAxNCAxNQplbWJlZGRlZCAgICAw ICAgIDIgICAgRCAgIDB4NDQgIDMgNCA1IDcgMTAgMTEgMTIgMTQgMTUKZW1iZWRkZWQgICAgMCAg ICAzICAgIEEgICAweDYwICAzIDQgNSA3IDEwIDExIDEyIDE0IDE1CmVtYmVkZGVkICAgIDAgICAg MyAgICBCICAgMHg2MSAgMyA0IDUgNyAxMCAxMSAxMiAxNCAxNQplbWJlZGRlZCAgICAwICAgIDMg ICAgQyAgIDB4NjIgIDMgNCA1IDcgMTAgMTEgMTIgMTQgMTUKZW1iZWRkZWQgICAgMCAgICAzICAg IEQgICAweDYzICAzIDQgNSA3IDEwIDExIDEyIDE0IDE1CmVtYmVkZGVkICAgIDAgICAgNSAgICBB ICAgMHg0MiAgMyA0IDUgNyAxMCAxMSAxMiAxNCAxNQplbWJlZGRlZCAgICAwICAgIDEgICAgQSAg IDB4NDEgIDMgNCA1IDcgMTAgMTEgMTIgMTQgMTUKZW1iZWRkZWQgICAgMCAgICAxICAgIEIgICAw eDQyICAzIDQgNSA3IDEwIDExIDEyIDE0IDE1CmVtYmVkZGVkICAgIDAgICAgMSAgICBDICAgMHg0 MyAgMyA0IDUgNyAxMCAxMSAxMiAxNCAxNQplbWJlZGRlZCAgICAwICAgIDEgICAgRCAgIDB4NDQg IDMgNCA1IDcgMTAgMTEgMTIgMTQgMTUKZW1iZWRkZWQgICAgMCAgICA0ICAgIEEgICAweDQ0ICAz IDQgNSA3IDEwIDExIDEyIDE0IDE1CnNsb3QgMSAgICAgIDAgICAgOCAgICBBICAgMHg0MSAgMyA0 IDUgNyAxMCAxMSAxMiAxNCAxNQpzbG90IDEgICAgICAwICAgIDggICAgQiAgIDB4NDIgIDMgNCA1 IDcgMTAgMTEgMTIgMTQgMTUKc2xvdCAxICAgICAgMCAgICA4ICAgIEMgICAweDQzICAzIDQgNSA3 IDEwIDExIDEyIDE0IDE1CnNsb3QgMSAgICAgIDAgICAgOCAgICBEICAgMHg0NCAgMyA0IDUgNyAx MCAxMSAxMiAxNCAxNQpzbG90IDIgICAgICAwICAgIDkgICAgQSAgIDB4NDIgIDMgNCA1IDcgMTAg MTEgMTIgMTQgMTUKc2xvdCAyICAgICAgMCAgICA5ICAgIEIgICAweDQzICAzIDQgNSA3IDEwIDEx IDEyIDE0IDE1CnNsb3QgMiAgICAgIDAgICAgOSAgICBDICAgMHg0NCAgMyA0IDUgNyAxMCAxMSAx MiAxNCAxNQpzbG90IDIgICAgICAwICAgIDkgICAgRCAgIDB4NDEgIDMgNCA1IDcgMTAgMTEgMTIg MTQgMTUKc2xvdCAzICAgICAgMCAgIDEwICAgIEEgICAweDQzICAzIDQgNSA3IDEwIDExIDEyIDE0 IDE1CnNsb3QgMyAgICAgIDAgICAxMCAgICBCICAgMHg0NCAgMyA0IDUgNyAxMCAxMSAxMiAxNCAx NQpzbG90IDMgICAgICAwICAgMTAgICAgQyAgIDB4NDEgIDMgNCA1IDcgMTAgMTEgMTIgMTQgMTUK c2xvdCAzICAgICAgMCAgIDEwICAgIEQgICAweDQyICAzIDQgNSA3IDEwIDExIDEyIDE0IDE1CnNs b3QgNCAgICAgIDAgICAxMSAgICBBICAgMHg0NCAgMyA0IDUgNyAxMCAxMSAxMiAxNCAxNQpzbG90 IDQgICAgICAwICAgMTEgICAgQiAgIDB4NDEgIDMgNCA1IDcgMTAgMTEgMTIgMTQgMTUKc2xvdCA0 ICAgICAgMCAgIDExICAgIEMgICAweDQyICAzIDQgNSA3IDEwIDExIDEyIDE0IDE1CnNsb3QgNCAg ICAgIDAgICAxMSAgICBEICAgMHg0MyAgMyA0IDUgNyAxMCAxMSAxMiAxNCAxNQpzbG90IDUgICAg ICAwICAgMTIgICAgQSAgIDB4NDEgIDMgNCA1IDcgMTAgMTEgMTIgMTQgMTUKc2xvdCA1ICAgICAg MCAgIDEyICAgIEIgICAweDQyICAzIDQgNSA3IDEwIDExIDEyIDE0IDE1CnNsb3QgNSAgICAgIDAg ICAxMiAgICBDICAgMHg0MyAgMyA0IDUgNyAxMCAxMSAxMiAxNCAxNQpzbG90IDUgICAgICAwICAg MTIgICAgRCAgIDB4NDQgIDMgNCA1IDcgMTAgMTEgMTIgMTQgMTUKQWNwaU9zRGVyaXZlUGNpSWQ6 IGJ1cyAwIGRldiAyIGZ1bmMgMApBY3BpT3NEZXJpdmVQY2lJZDogYnVzIDAgZGV2IDIgZnVuYyAw CmFjcGkwOiBQb3dlciBCdXR0b24gKGZpeGVkKQpwY2lfbGluazA6IDxBQ1BJIFBDSSBMaW5rIExO S0E+IGlycSAxMSBvbiBhY3BpMApwY2lfbGluazA6IExpbmtzIGFmdGVyIGluaXRpYWwgcHJvYmU6 CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAgMTEgICBOICAgICAwICAzIDQgNSA3 IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rMDogTGlua3MgYWZ0ZXIgaW5pdGlhbCB2YWxpZGF0aW9u OgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgIDExICAgTiAgICAgMCAgMyA0IDUg NyAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazA6IExpbmtzIGFmdGVyIGRpc2FibGU6CkluZGV4ICBJ UlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICAzIDQgNSA3IDEwIDExIDEy IDE0IDE1CnBjaV9saW5rMTogPEFDUEkgUENJIExpbmsgTE5LQj4gaXJxIDEwIG9uIGFjcGkwCnBj aV9saW5rMTogTGlua3MgYWZ0ZXIgaW5pdGlhbCBwcm9iZToKSW5kZXggIElSUSAgUnRkICBSZWYg IElSUXMKICAgIDAgICAxMCAgIE4gICAgIDAgIDMgNCA1IDcgMTAgMTEgMTIgMTQgMTUKcGNpX2xp bmsxOiBMaW5rcyBhZnRlciBpbml0aWFsIHZhbGlkYXRpb246CkluZGV4ICBJUlEgIFJ0ZCAgUmVm ICBJUlFzCiAgICAwICAgMTAgICBOICAgICAwICAzIDQgNSA3IDEwIDExIDEyIDE0IDE1CnBjaV9s aW5rMTogTGlua3MgYWZ0ZXIgZGlzYWJsZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAg IDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbmsyOiA8QUNQ SSBQQ0kgTGluayBMTktDPiBpcnEgNSBvbiBhY3BpMApwY2lfbGluazI6IExpbmtzIGFmdGVyIGlu aXRpYWwgcHJvYmU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAgIDUgICBOICAg ICAwICAzIDQgNSA3IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rMjogTGlua3MgYWZ0ZXIgaW5pdGlh bCB2YWxpZGF0aW9uOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgICA1ICAgTiAg ICAgMCAgMyA0IDUgNyAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazI6IExpbmtzIGFmdGVyIGRpc2Fi bGU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICAzIDQg NSA3IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rMzogPEFDUEkgUENJIExpbmsgTE5LRD4gaXJxIDEw IG9uIGFjcGkwCnBjaV9saW5rMzogTGlua3MgYWZ0ZXIgaW5pdGlhbCBwcm9iZToKSW5kZXggIElS USAgUnRkICBSZWYgIElSUXMKICAgIDAgICAxMCAgIE4gICAgIDAgIDMgNCA1IDcgMTAgMTEgMTIg MTQgMTUKcGNpX2xpbmszOiBMaW5rcyBhZnRlciBpbml0aWFsIHZhbGlkYXRpb246CkluZGV4ICBJ UlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAgMTAgICBOICAgICAwICAzIDQgNSA3IDEwIDExIDEy IDE0IDE1CnBjaV9saW5rMzogTGlua3MgYWZ0ZXIgZGlzYWJsZToKSW5kZXggIElSUSAgUnRkICBS ZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgMTAgMTEgMTIgMTQgMTUKcGNp X2xpbms0OiA8QUNQSSBQQ0kgTGluayBMTktFPiBpcnEgNSBvbiBhY3BpMApwY2lfbGluazQ6IExp bmtzIGFmdGVyIGluaXRpYWwgcHJvYmU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAw ICAgIDUgICBOICAgICAwICAzIDQgNSA3IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rNDogTGlua3Mg YWZ0ZXIgaW5pdGlhbCB2YWxpZGF0aW9uOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAg MCAgICA1ICAgTiAgICAgMCAgMyA0IDUgNyAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazQ6IExpbmtz IGFmdGVyIGRpc2FibGU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBO ICAgICAwICAzIDQgNSA3IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rNTogPEFDUEkgUENJIExpbmsg TE5LRj4gaXJxIDEwIG9uIGFjcGkwCnBjaV9saW5rNTogTGlua3MgYWZ0ZXIgaW5pdGlhbCBwcm9i ZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgICAxMCAgIE4gICAgIDAgIDMgNCA1 IDcgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbms1OiBMaW5rcyBhZnRlciBpbml0aWFsIHZhbGlkYXRp b246CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAgMTAgICBOICAgICAwICAzIDQg NSA3IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rNTogTGlua3MgYWZ0ZXIgZGlzYWJsZToKSW5kZXgg IElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgMTAgMTEg MTIgMTQgMTUKcGNpX2xpbms2OiA8QUNQSSBQQ0kgTGluayBMTktHPiBpcnEgNyBvbiBhY3BpMApw Y2lfbGluazY6IExpbmtzIGFmdGVyIGluaXRpYWwgcHJvYmU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVm ICBJUlFzCiAgICAwICAgIDcgICBOICAgICAwICAzIDQgNSA3IDEwIDExIDEyIDE0IDE1CnBjaV9s aW5rNjogTGlua3MgYWZ0ZXIgaW5pdGlhbCB2YWxpZGF0aW9uOgpJbmRleCAgSVJRICBSdGQgIFJl ZiAgSVJRcwogICAgMCAgICA3ICAgTiAgICAgMCAgMyA0IDUgNyAxMCAxMSAxMiAxNCAxNQpwY2lf bGluazY6IExpbmtzIGFmdGVyIGRpc2FibGU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAg ICAwICAyNTUgICBOICAgICAwICAzIDQgNSA3IDEwIDExIDEyIDE0IDE1CnBjaV9saW5rNzogPEFD UEkgUENJIExpbmsgTE5LSD4gaXJxIDMgb24gYWNwaTAKcGNpX2xpbms3OiBMaW5rcyBhZnRlciBp bml0aWFsIHByb2JlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgICAzICAgTiAg ICAgMCAgMyA0IDUgNyAxMCAxMSAxMiAxNCAxNQpwY2lfbGluazc6IExpbmtzIGFmdGVyIGluaXRp YWwgdmFsaWRhdGlvbjoKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgICAgMyAgIE4g ICAgIDAgIDMgNCA1IDcgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbms3OiBMaW5rcyBhZnRlciBkaXNh YmxlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0 IDUgNyAxMCAxMSAxMiAxNCAxNQpBQ1BJIHRpbWVyOiAxLzEgMS8xIDEvMSAwLzgxNCAxLzEgMS8x IDEvMSAxLzEgMS8xIDEvMSAtPiA5ClRpbWVjb3VudGVyICJBQ1BJLXNhZmUiIGZyZXF1ZW5jeSAz NTc5NTQ1IEh6IHF1YWxpdHkgMTAwMAphY3BpX3RpbWVyMDogPDI0LWJpdCB0aW1lciBhdCAzLjU3 OTU0NU1Iej4gcG9ydCAweDgwOC0weDgwYiBvbiBhY3BpMApjcHUwOiA8QUNQSSBDUFU+IG9uIGFj cGkwCmFjcGlfdGhyb3R0bGUwOiA8QUNQSSBDUFUgVGhyb3R0bGluZz4gb24gY3B1MAphY3BpX3Ro cm90dGxlMDogUF9DTlQgZnJvbSBQX0JMSyAweDgxMApjcHUxOiA8QUNQSSBDUFU+IG9uIGFjcGkw CmFjcGlfdGhyb3R0bGUxOiA8QUNQSSBDUFUgVGhyb3R0bGluZz4gb24gY3B1MQphY3BpX3Rocm90 dGxlMTogZmFpbGVkIHRvIGF0dGFjaCBQX0NOVApkZXZpY2VfYXR0YWNoOiBhY3BpX3Rocm90dGxl MSBhdHRhY2ggcmV0dXJuZWQgNgpwY2liMDogPEFDUEkgSG9zdC1QQ0kgYnJpZGdlPiBwb3J0IDB4 Y2Y4LTB4Y2ZmIG9uIGFjcGkwCnBjaTA6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIwCnBjaTA6IHBo eXNpY2FsIGJ1cz0wCmZvdW5kLT4JdmVuZG9yPTB4MTAzOSwgZGV2PTB4MDY1NSwgcmV2aWQ9MHg1 MAoJYnVzPTAsIHNsb3Q9MCwgZnVuYz0wCgljbGFzcz0wNi0wMC0wMCwgaGRydHlwZT0weDAwLCBt ZmRldj0xCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MjIxMCwgY2FjaGVsbnN6PTAgKGR3b3Jk cykKCWxhdHRpbWVyPTB4MjAgKDk2MCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4 MDAgKDAgbnMpCgltYXBbMTBdOiB0eXBlIDEsIHJhbmdlIDMyLCBiYXNlIGY4MDAwMDAwLCBzaXpl IDI2LCBlbmFibGVkCmZvdW5kLT4JdmVuZG9yPTB4MTAzOSwgZGV2PTB4MDAwMywgcmV2aWQ9MHgw MAoJYnVzPTAsIHNsb3Q9MSwgZnVuYz0wCgljbGFzcz0wNi0wNC0wMCwgaGRydHlwZT0weDAxLCBt ZmRldj0wCgljbWRyZWc9MHgwMTA3LCBzdGF0cmVnPTB4MDAyMCwgY2FjaGVsbnN6PTAgKGR3b3Jk cykKCWxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5nbnQ9MHgwYSAoMjUwMCBucyksIG1heGxh dD0weDAwICgwIG5zKQpmb3VuZC0+CXZlbmRvcj0weDEwMzksIGRldj0weDA5NjQsIHJldmlkPTB4 MzYKCWJ1cz0wLCBzbG90PTIsIGZ1bmM9MAoJY2xhc3M9MDYtMDEtMDAsIGhkcnR5cGU9MHgwMCwg bWZkZXY9MQoJY21kcmVnPTB4MDAwZiwgc3RhdHJlZz0weDAyMDAsIGNhY2hlbG5zej0wIChkd29y ZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgw MCAoMCBucykKZm91bmQtPgl2ZW5kb3I9MHgxMDM5LCBkZXY9MHg1NTEzLCByZXZpZD0weDAxCgli dXM9MCwgc2xvdD0yLCBmdW5jPTUKCWNsYXNzPTAxLTAxLThhLCBoZHJ0eXBlPTB4MDAsIG1mZGV2 PTAKCWNtZHJlZz0weDAwMDUsIHN0YXRyZWc9MHgwMjEwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJ bGF0dGltZXI9MHg4MCAoMzg0MCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAg KDAgbnMpCglpbnRwaW49YSwgaXJxPTI1NQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBj dXJyZW50IEQwCgltYXBbMjBdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDBmZmEwLCBzaXpl ICA0LCBlbmFibGVkCmZvdW5kLT4JdmVuZG9yPTB4MTAzOSwgZGV2PTB4NzAxMiwgcmV2aWQ9MHhh MAoJYnVzPTAsIHNsb3Q9MiwgZnVuYz03CgljbGFzcz0wNC0wMS0wMCwgaGRydHlwZT0weDAwLCBt ZmRldj0wCgljbWRyZWc9MHgwMTA1LCBzdGF0cmVnPTB4MDI5MCwgY2FjaGVsbnN6PTAgKGR3b3Jk cykKCWxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5nbnQ9MHgzNCAoMTMwMDAgbnMpLCBtYXhs YXQ9MHgwYiAoMjc1MCBucykKCWludHBpbj1jLCBpcnE9NQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRz IEQwIEQxIEQyIEQzICBjdXJyZW50IEQwCgltYXBbMTBdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNl IDAwMDBlODAwLCBzaXplICA4LCBlbmFibGVkCgltYXBbMTRdOiB0eXBlIDQsIHJhbmdlIDMyLCBi YXNlIDAwMDBlYzAwLCBzaXplICA3LCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAw LjIuSU5UQwpwY2liMDogc2xvdCAyIElOVEMgaGFyZHdpcmVkIHRvIElSUSAxOApmb3VuZC0+CXZl bmRvcj0weDEwMzksIGRldj0weDcwMDEsIHJldmlkPTB4MGYKCWJ1cz0wLCBzbG90PTMsIGZ1bmM9 MAoJY2xhc3M9MGMtMDMtMTAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDExNywg c3RhdHJlZz0weDAyODAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDQwICgxOTIw IG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHg1MCAoMjAwMDAgbnMpCglpbnRwaW49 YSwgaXJxPTUKCW1hcFsxMF06IHR5cGUgMSwgcmFuZ2UgMzIsIGJhc2UgZmY2ZmMwMDAsIHNpemUg MTIsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMy5JTlRBCnBjaWIwOiBzbG90 IDMgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDIwCmZvdW5kLT4JdmVuZG9yPTB4MTAzOSwgZGV2PTB4 NzAwMSwgcmV2aWQ9MHgwZgoJYnVzPTAsIHNsb3Q9MywgZnVuYz0xCgljbGFzcz0wYy0wMy0xMCwg aGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMTE3LCBzdGF0cmVnPTB4MDI4MCwgY2Fj aGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5nbnQ9MHgwMCAo MCBucyksIG1heGxhdD0weDUwICgyMDAwMCBucykKCWludHBpbj1iLCBpcnE9MTAKCW1hcFsxMF06 IHR5cGUgMSwgcmFuZ2UgMzIsIGJhc2UgZmY2ZmQwMDAsIHNpemUgMTIsIGVuYWJsZWQKcGNpYjA6 IG1hdGNoZWQgZW50cnkgZm9yIDAuMy5JTlRCCnBjaWIwOiBzbG90IDMgSU5UQiBoYXJkd2lyZWQg dG8gSVJRIDIxCmZvdW5kLT4JdmVuZG9yPTB4MTAzOSwgZGV2PTB4NzAwMSwgcmV2aWQ9MHgwZgoJ YnVzPTAsIHNsb3Q9MywgZnVuYz0yCgljbGFzcz0wYy0wMy0xMCwgaGRydHlwZT0weDAwLCBtZmRl dj0wCgljbWRyZWc9MHgwMTE3LCBzdGF0cmVnPTB4MDI4MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykK CWxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDUw ICgyMDAwMCBucykKCWludHBpbj1jLCBpcnE9NwoJbWFwWzEwXTogdHlwZSAxLCByYW5nZSAzMiwg YmFzZSBmZjZmZTAwMCwgc2l6ZSAxMiwgZW5hYmxlZApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3Ig MC4zLklOVEMKcGNpYjA6IHNsb3QgMyBJTlRDIGhhcmR3aXJlZCB0byBJUlEgMjIKZm91bmQtPgl2 ZW5kb3I9MHgxMDM5LCBkZXY9MHg3MDAyLCByZXZpZD0weDAwCglidXM9MCwgc2xvdD0zLCBmdW5j PTMKCWNsYXNzPTBjLTAzLTIwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAxMDYs IHN0YXRyZWc9MHgwMjkwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHg0MCAoMTky MCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4NTAgKDIwMDAwIG5zKQoJaW50cGlu PWQsIGlycT0zCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCW1hcFsx MF06IHR5cGUgMSwgcmFuZ2UgMzIsIGJhc2UgZmY2ZmYwMDAsIHNpemUgMTIsIGVuYWJsZWQKcGNp YjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMy5JTlRECnBjaWIwOiBzbG90IDMgSU5URCBoYXJkd2ly ZWQgdG8gSVJRIDIzCmZvdW5kLT4JdmVuZG9yPTB4MTAzOSwgZGV2PTB4MDkwMCwgcmV2aWQ9MHg5 MQoJYnVzPTAsIHNsb3Q9NCwgZnVuYz0wCgljbGFzcz0wMi0wMC0wMCwgaGRydHlwZT0weDAwLCBt ZmRldj0wCgljbWRyZWc9MHgwMTA3LCBzdGF0cmVnPTB4MDI5MCwgY2FjaGVsbnN6PTAgKGR3b3Jk cykKCWxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5nbnQ9MHgzNCAoMTMwMDAgbnMpLCBtYXhs YXQ9MHgwYiAoMjc1MCBucykKCWludHBpbj1hLCBpcnE9MTAKCXBvd2Vyc3BlYyAyICBzdXBwb3J0 cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMAoJbWFwWzEwXTogdHlwZSA0LCByYW5nZSAzMiwgYmFz ZSAwMDAwZTQwMCwgc2l6ZSAgOCwgZW5hYmxlZAoJbWFwWzE0XTogdHlwZSAxLCByYW5nZSAzMiwg YmFzZSBmZjZmYjAwMCwgc2l6ZSAxMiwgZW5hYmxlZApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3Ig MC40LklOVEEKcGNpYjA6IHNsb3QgNCBJTlRBIGhhcmR3aXJlZCB0byBJUlEgMTkKZm91bmQtPgl2 ZW5kb3I9MHgxMDM5LCBkZXY9MHgwMTgwLCByZXZpZD0weDAxCglidXM9MCwgc2xvdD01LCBmdW5j PTAKCWNsYXNzPTAxLTA0LTg1LCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDA0MDUs IHN0YXRyZWc9MHgwMjIwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHg4MCAoMzg0 MCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwg aXJxPTEwCgltYXBbMTBdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDBlZmYwLCBzaXplICAz LCBlbmFibGVkCgltYXBbMTRdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDBlZmU0LCBzaXpl ICAyLCBlbmFibGVkCgltYXBbMThdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDBlZmE4LCBz aXplICAzLCBlbmFibGVkCgltYXBbMWNdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDBlZmUw LCBzaXplICAyLCBlbmFibGVkCgltYXBbMjBdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDBl ZjkwLCBzaXplICA0LCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjUuSU5UQQpw Y2liMDogc2xvdCA1IElOVEEgaGFyZHdpcmVkIHRvIElSUSAxNwphZ3AwOiA8U2lTIDY1NSBob3N0 IHRvIEFHUCBicmlkZ2U+IG1lbSAweGY4MDAwMDAwLTB4ZmJmZmZmZmYgYXQgZGV2aWNlIDAuMCBv biBwY2kwCmFncDA6IFJlc2VydmVkIDB4NDAwMDAwMCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSAz IGF0IDB4ZjgwMDAwMDAKYWdwMDogYWxsb2NhdGluZyBHQVRUIGZvciBhcGVydHVyZSBvZiBzaXpl IDY0TQpwY2liMTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAxLjAgb24gcGNpMApw Y2liMTogICBzZWNvbmRhcnkgYnVzICAgICAxCnBjaWIxOiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDEK cGNpYjE6ICAgSS9PIGRlY29kZSAgICAgICAgMHhkMDAwLTB4ZGZmZgpwY2liMTogICBtZW1vcnkg ZGVjb2RlICAgICAweGZmNTAwMDAwLTB4ZmY1ZmZmZmYKcGNpYjE6ICAgcHJlZmV0Y2hlZCBkZWNv ZGUgMHhkN2YwMDAwMC0weGY3ZWZmZmZmCnBjaWIxOiBjb3VsZCBub3QgZ2V0IFBDSSBpbnRlcnJ1 cHQgcm91dGluZyB0YWJsZSBmb3IgXFxfU0JfLlBDSTAuUDBQMSAtIEFFX05PVF9GT1VORApwY2kx OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMQpwY2kxOiBwaHlzaWNhbCBidXM9MQpmb3VuZC0+CXZl bmRvcj0weDEwMDIsIGRldj0weDU5NjAsIHJldmlkPTB4MDEKCWJ1cz0xLCBzbG90PTAsIGZ1bmM9 MAoJY2xhc3M9MDMtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDEwNywg c3RhdHJlZz0weDAyYjAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHg0MCAoMTky MCBucyksIG1pbmdudD0weDA4ICgyMDAwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49 YSwgaXJxPTExCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDEgRDIgRDMgIGN1cnJlbnQgRDAK CW1hcFsxMF06IHR5cGUgMywgcmFuZ2UgMzIsIGJhc2UgZTgwMDAwMDAsIHNpemUgMjcsIGVuYWJs ZWQKcGNpYjE6IChudWxsKSByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4ZTgwMDAwMDAtMHhlZmZm ZmZmZjogZ29vZAoJbWFwWzE0XTogdHlwZSA0LCByYW5nZSAzMiwgYmFzZSAwMDAwZDAwMCwgc2l6 ZSAgOCwgZW5hYmxlZApwY2liMTogKG51bGwpIHJlcXVlc3RlZCBJL08gcmFuZ2UgMHhkMDAwLTB4 ZDBmZjogaW4gcmFuZ2UKCW1hcFsxOF06IHR5cGUgMSwgcmFuZ2UgMzIsIGJhc2UgZmY1ZjAwMDAs IHNpemUgMTYsIGVuYWJsZWQKcGNpYjE6IChudWxsKSByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4 ZmY1ZjAwMDAtMHhmZjVmZmZmZjogZ29vZApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4xLklO VEEKcGNpYjA6IHNsb3QgMSBJTlRBIGhhcmR3aXJlZCB0byBJUlEgMTYKcGNpYjE6IHNsb3QgMCBJ TlRBIGlzIHJvdXRlZCB0byBpcnEgMTYKZm91bmQtPgl2ZW5kb3I9MHgxMDAyLCBkZXY9MHg1OTQw LCByZXZpZD0weDAxCglidXM9MSwgc2xvdD0wLCBmdW5jPTEKCWNsYXNzPTAzLTgwLTAwLCBoZHJ0 eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMmIwLCBjYWNoZWxu c3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5nbnQ9MHgwOCAoMjAw MCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQxIEQy IEQzICBjdXJyZW50IEQwCgltYXBbMTBdOiB0eXBlIDMsIHJhbmdlIDMyLCBiYXNlIGUwMDAwMDAw LCBzaXplIDI3LCBlbmFibGVkCnBjaWIxOiAobnVsbCkgcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAw eGUwMDAwMDAwLTB4ZTdmZmZmZmY6IGdvb2QKCW1hcFsxNF06IHR5cGUgMSwgcmFuZ2UgMzIsIGJh c2UgZmY1ZTAwMDAsIHNpemUgMTYsIGVuYWJsZWQKcGNpYjE6IChudWxsKSByZXF1ZXN0ZWQgbWVt b3J5IHJhbmdlIDB4ZmY1ZTAwMDAtMHhmZjVlZmZmZjogZ29vZApwY2kxOiA8ZGlzcGxheSwgVkdB PiBhdCBkZXZpY2UgMC4wIChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaTE6IDxkaXNwbGF5PiBhdCBk ZXZpY2UgMC4xIChubyBkcml2ZXIgYXR0YWNoZWQpCmlzYWIwOiA8UENJLUlTQSBicmlkZ2U+IGF0 IGRldmljZSAyLjAgb24gcGNpMAppc2EwOiA8SVNBIGJ1cz4gb24gaXNhYjAKYXRhcGNpMDogPFNp UyA5NjQgVURNQTEzMyBjb250cm9sbGVyPiBwb3J0IDB4MWYwLTB4MWY3LDB4M2Y2LDB4MTcwLTB4 MTc3LDB4Mzc2LDB4ZmZhMC0weGZmYWYgYXQgZGV2aWNlIDIuNSBvbiBwY2kwCmF0YXBjaTA6IFJl c2VydmVkIDB4MTAgYnl0ZXMgZm9yIHJpZCAweDIwIHR5cGUgNCBhdCAweGZmYTAKYXRhMDogPEFU QSBjaGFubmVsIDA+IG9uIGF0YXBjaTAKYXRhcGNpMDogUmVzZXJ2ZWQgMHg4IGJ5dGVzIGZvciBy aWQgMHgxMCB0eXBlIDQgYXQgMHgxZjAKYXRhcGNpMDogUmVzZXJ2ZWQgMHgxIGJ5dGVzIGZvciBy aWQgMHgxNCB0eXBlIDQgYXQgMHgzZjYKYXRhMDogcmVzZXQgdHAxIG1hc2s9MDMgb3N0YXQwPTUw IG9zdGF0MT0wMAphdGEwOiBzdGF0MD0weDAwIGVycj0weDAxIGxzYj0weDE0IG1zYj0weGViCmF0 YTA6IHN0YXQxPTB4MDAgZXJyPTB4MDQgbHNiPTB4MDAgbXNiPTB4MDAKYXRhMDogcmVzZXQgdHAy IHN0YXQwPTAwIHN0YXQxPTAwIGRldmljZXM9MHg0PEFUQVBJX01BU1RFUj4KYXRhMDogW01QU0FG RV0KYXRhMTogPEFUQSBjaGFubmVsIDE+IG9uIGF0YXBjaTAKYXRhcGNpMDogUmVzZXJ2ZWQgMHg4 IGJ5dGVzIGZvciByaWQgMHgxOCB0eXBlIDQgYXQgMHgxNzAKYXRhcGNpMDogUmVzZXJ2ZWQgMHgx IGJ5dGVzIGZvciByaWQgMHgxYyB0eXBlIDQgYXQgMHgzNzYKYXRhMTogcmVzZXQgdHAxIG1hc2s9 MDMgb3N0YXQwPTAwIG9zdGF0MT0wMAphdGExOiBzdGF0MD0weDAwIGVycj0weDAwIGxzYj0weDAw IG1zYj0weDAwCmF0YTE6IHN0YXQxPTB4MDAgZXJyPTB4MDAgbHNiPTB4MDAgbXNiPTB4MDAKYXRh MTogcmVzZXQgdHAyIHN0YXQwPTAwIHN0YXQxPTAwIGRldmljZXM9MHgwCmF0YTE6IFtNUFNBRkVd CnBjaTA6IDxtdWx0aW1lZGlhLCBhdWRpbz4gYXQgZGV2aWNlIDIuNyAobm8gZHJpdmVyIGF0dGFj aGVkKQpwY2kwOjI6NzogVHJhbnNpdGlvbiBmcm9tIEQwIHRvIEQzCm9oY2kwOiA8U2lTIDU1NzEg VVNCIGNvbnRyb2xsZXI+IG1lbSAweGZmNmZjMDAwLTB4ZmY2ZmNmZmYgaXJxIDIwIGF0IGRldmlj ZSAzLjAgb24gcGNpMApvaGNpMDogUmVzZXJ2ZWQgMHgxMDAwIGJ5dGVzIGZvciByaWQgMHgxMCB0 eXBlIDMgYXQgMHhmZjZmYzAwMApvaGNpMDogW0dJQU5ULUxPQ0tFRF0KdXNiMDogT0hDSSB2ZXJz aW9uIDEuMCwgbGVnYWN5IHN1cHBvcnQKdXNiMDogU01NIGRvZXMgbm90IHJlc3BvbmQsIHJlc2V0 dGluZwp1c2IwOiA8U2lTIDU1NzEgVVNCIGNvbnRyb2xsZXI+IG9uIG9oY2kwCnVzYjA6IFVTQiBy ZXZpc2lvbiAxLjAKdWh1YjA6IFNpUyBPSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAw LzEuMDAsIGFkZHIgMQp1aHViMDogMyBwb3J0cyB3aXRoIDMgcmVtb3ZhYmxlLCBzZWxmIHBvd2Vy ZWQKb2hjaTE6IDxTaVMgNTU3MSBVU0IgY29udHJvbGxlcj4gbWVtIDB4ZmY2ZmQwMDAtMHhmZjZm ZGZmZiBpcnEgMjEgYXQgZGV2aWNlIDMuMSBvbiBwY2kwCm9oY2kxOiBSZXNlcnZlZCAweDEwMDAg Ynl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgMyBhdCAweGZmNmZkMDAwCm9oY2kxOiBbR0lBTlQtTE9D S0VEXQp1c2IxOiBPSENJIHZlcnNpb24gMS4wLCBsZWdhY3kgc3VwcG9ydAp1c2IxOiBTTU0gZG9l cyBub3QgcmVzcG9uZCwgcmVzZXR0aW5nCnVzYjE6IDxTaVMgNTU3MSBVU0IgY29udHJvbGxlcj4g b24gb2hjaTEKdXNiMTogVVNCIHJldmlzaW9uIDEuMAp1aHViMTogU2lTIE9IQ0kgcm9vdCBodWIs IGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxCnVodWIxOiAzIHBvcnRzIHdpdGggMyBy ZW1vdmFibGUsIHNlbGYgcG93ZXJlZApvaGNpMjogPFNpUyA1NTcxIFVTQiBjb250cm9sbGVyPiBt ZW0gMHhmZjZmZTAwMC0weGZmNmZlZmZmIGlycSAyMiBhdCBkZXZpY2UgMy4yIG9uIHBjaTAKb2hj aTI6IFJlc2VydmVkIDB4MTAwMCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4ZmY2ZmUw MDAKb2hjaTI6IFtHSUFOVC1MT0NLRURdCnVzYjI6IE9IQ0kgdmVyc2lvbiAxLjAsIGxlZ2FjeSBz dXBwb3J0CnVzYjI6IFNNTSBkb2VzIG5vdCByZXNwb25kLCByZXNldHRpbmcKdXNiMjogPFNpUyA1 NTcxIFVTQiBjb250cm9sbGVyPiBvbiBvaGNpMgp1c2IyOiBVU0IgcmV2aXNpb24gMS4wCnVodWIy OiBTaVMgT0hDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDEKdWh1 YjI6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCmVoY2kwOiA8RUhDSSAo Z2VuZXJpYykgVVNCIDIuMCBjb250cm9sbGVyPiBtZW0gMHhmZjZmZjAwMC0weGZmNmZmZmZmIGly cSAyMyBhdCBkZXZpY2UgMy4zIG9uIHBjaTAKZWhjaTA6IFJlc2VydmVkIDB4MTAwMCBieXRlcyBm b3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4ZmY2ZmYwMDAKZWhjaTA6IFtHSUFOVC1MT0NLRURdCnVz YjM6IEVIQ0kgdmVyc2lvbiAxLjAKdXNiMzogY29tcGFuaW9uIGNvbnRyb2xsZXJzLCAzIHBvcnRz IGVhY2g6IHVzYjAgdXNiMSB1c2IyCnVzYjM6IDxFSENJIChnZW5lcmljKSBVU0IgMi4wIGNvbnRy b2xsZXI+IG9uIGVoY2kwCnVzYjM6IFVTQiByZXZpc2lvbiAyLjAKdWh1YjM6IFNpUyBFSENJIHJv b3QgaHViLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMQp1aHViMzogOCBwb3J0cyB3 aXRoIDggcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKc2lzMDogPFNpUyA5MDAgMTAvMTAwQmFzZVRY PiBwb3J0IDB4ZTQwMC0weGU0ZmYgbWVtIDB4ZmY2ZmIwMDAtMHhmZjZmYmZmZiBpcnEgMTkgYXQg ZGV2aWNlIDQuMCBvbiBwY2kwCnNpczA6IFJlc2VydmVkIDB4MTAwIGJ5dGVzIGZvciByaWQgMHgx MCB0eXBlIDQgYXQgMHhlNDAwCm1paWJ1czA6IDxNSUkgYnVzPiBvbiBzaXMwCnJscGh5MDogPFJU TDgyMDFMIDEwLzEwMCBtZWRpYSBpbnRlcmZhY2U+IG9uIG1paWJ1czAKcmxwaHkwOiAgMTBiYXNl VCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAwYmFzZVRYLUZEWCwgYXV0bwpzaXMwOiBicGYg YXR0YWNoZWQKc2lzMDogW01QU0FGRV0KYXRhcGNpMTogPFNpUyAxODAgU0FUQTE1MCBjb250cm9s bGVyPiBwb3J0IDB4ZWZmMC0weGVmZjcsMHhlZmU0LTB4ZWZlNywweGVmYTgtMHhlZmFmLDB4ZWZl MC0weGVmZTMsMHhlZjkwLTB4ZWY5ZiBpcnEgMTcgYXQgZGV2aWNlIDUuMCBvbiBwY2kwCmF0YXBj aTE6IFJlc2VydmVkIDB4MTAgYnl0ZXMgZm9yIHJpZCAweDIwIHR5cGUgNCBhdCAweGVmOTAKYXRh cGNpMTogW01QU0FGRV0KYXRhMjogPEFUQSBjaGFubmVsIDA+IG9uIGF0YXBjaTEKYXRhcGNpMTog UmVzZXJ2ZWQgMHg4IGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDQgYXQgMHhlZmYwCmF0YXBjaTE6 IFJlc2VydmVkIDB4NCBieXRlcyBmb3IgcmlkIDB4MTQgdHlwZSA0IGF0IDB4ZWZlNAphdGEyOiBy ZXNldCB0cDEgbWFzaz0wMyBvc3RhdDA9NTAgb3N0YXQxPTAwCmF0YTI6IHN0YXQwPTB4NTAgZXJy PTB4MDEgbHNiPTB4MDAgbXNiPTB4MDAKYXRhMjogc3RhdDE9MHgwMCBlcnI9MHgwMSBsc2I9MHgw MCBtc2I9MHgwMAphdGEyOiByZXNldCB0cDIgc3RhdDA9NTAgc3RhdDE9MDAgZGV2aWNlcz0weDE8 QVRBX01BU1RFUj4KYXRhMjogW01QU0FGRV0KYXRhMzogPEFUQSBjaGFubmVsIDE+IG9uIGF0YXBj aTEKYXRhcGNpMTogUmVzZXJ2ZWQgMHg4IGJ5dGVzIGZvciByaWQgMHgxOCB0eXBlIDQgYXQgMHhl ZmE4CmF0YXBjaTE6IFJlc2VydmVkIDB4NCBieXRlcyBmb3IgcmlkIDB4MWMgdHlwZSA0IGF0IDB4 ZWZlMAphdGEzOiByZXNldCB0cDEgbWFzaz0wMyBvc3RhdDA9N2Ygb3N0YXQxPTdmCmF0YTM6IHN0 YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhMzogc3RhdDA9MHg3ZiBlcnI9 MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGEzOiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZm IG1zYj0weGZmCmF0YTM6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRh Mzogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGEzOiBzdGF0MD0weDdm IGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTM6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNi PTB4ZmYgbXNiPTB4ZmYKYXRhMzogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhm ZgphdGEzOiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTM6IHN0YXQw PTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhMzogc3RhdDA9MHg3ZiBlcnI9MHhm ZiBsc2I9MHhmZiBtc2I9MHhmZgphdGEzOiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1z Yj0weGZmCmF0YTM6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhMzog c3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGEzOiBzdGF0MD0weDdmIGVy cj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTM6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4 ZmYgbXNiPTB4ZmYKYXRhMzogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgph dGEzOiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTM6IHN0YXQwPTB4 N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhMzogc3RhdDA9MHg3ZiBlcnI9MHhmZiBs c2I9MHhmZiBtc2I9MHhmZgphdGEzOiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0w eGZmCmF0YTM6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhMzogc3Rh dDE9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGEzOiByZXNldCB0cDIgc3RhdDA9 ZmYgc3RhdDE9ZmYgZGV2aWNlcz0weDAKYXRhMzogW01QU0FGRV0KYWNwaV9idXR0b24wOiA8UG93 ZXIgQnV0dG9uPiBvbiBhY3BpMAphdGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgwNDIp PiBwb3J0IDB4NjAsMHg2NCBpcnEgMSBvbiBhY3BpMAphdGtiZDA6IDxBVCBLZXlib2FyZD4gaXJx IDEgb24gYXRrYmRjMAphdGtiZDogdGhlIGN1cnJlbnQga2JkIGNvbnRyb2xsZXIgY29tbWFuZCBi eXRlIDAwNjUKYXRrYmQ6IGtleWJvYXJkIElEIDB4NDFhYiAoMikKa2JkMCBhdCBhdGtiZDAKa2Jk MDogYXRrYmQwLCBBVCAxMDEvMTAyICgyKSwgY29uZmlnOjB4MCwgZmxhZ3M6MHgzZDAwMDAKYXRr YmQwOiBbR0lBTlQtTE9DS0VEXQpwc20wOiB1bmFibGUgdG8gYWxsb2NhdGUgSVJRCmZkYzA6IDxm bG9wcHkgZHJpdmUgY29udHJvbGxlciAoRkRFKT4gcG9ydCAweDNmMC0weDNmNSwweDNmNyBpcnEg NiBkcnEgMiBvbiBhY3BpMApmZGMwOiBpY190eXBlIDkwIHBhcnRfaWQgODAKZmRjMDogW01QU0FG RV0KZmRjMDogW0ZBU1RdCmZkMDogPDE0NDAtS0IgMy41IiBkcml2ZT4gb24gZmRjMCBkcml2ZSAw CnNpbzA6IGNvbmZpZ3VyZWQgaXJxIDQgbm90IGluIGJpdG1hcCBvZiBwcm9iZWQgaXJxcyAwCnNp bzA6IHBvcnQgbWF5IG5vdCBiZSBlbmFibGVkCnNpbzA6IGlycSBtYXBzOiAwIDAgMCAwCnNpbzA6 IDwxNjU1MEEtY29tcGF0aWJsZSBDT00gcG9ydD4gcG9ydCAweDNmOC0weDNmZiBpcnEgNCBmbGFn cyAweDEwIG9uIGFjcGkwCnNpbzA6IHR5cGUgMTY1NTBBCmFoY19pc2FfcHJvYmUgMTQ6IGlvcG9y dCAweGVjMDAgYWxsb2MgZmFpbGVkCmF0YTogYXRhMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcg aXQKYXRhOiBhdGExIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdAphdGtiZGM6IGF0a2JkYzAg YWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0CmZkYzogZmRjMCBhbHJlYWR5IGV4aXN0czsgc2tp cHBpbmcgaXQKc2lvOiBzaW8wIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdApwbnBfaWRlbnRp Znk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMjAzCnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9y dCBhdCAyNDMKcG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDI4MwpwbnBfaWRlbnRp Znk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMmMzCnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9y dCBhdCAzMDMKcG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDM0MwpwbnBfaWRlbnRp Znk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMzgzCnBucF9pZGVudGlmeTogVHJ5aW5nIFJlYWRfUG9y dCBhdCAzYzMKUE5QIElkZW50aWZ5IGNvbXBsZXRlCmV4X2lzYV9pZGVudGlmeSgpCnVua25vd246 IHN0YXR1cyByZWcgdGVzdCBmYWlsZWQgZmYKdW5rbm93bjogc3RhdHVzIHJlZyB0ZXN0IGZhaWxl ZCBmZgp1bmtub3duOiBzdGF0dXMgcmVnIHRlc3QgZmFpbGVkIGZmCnVua25vd246IHN0YXR1cyBy ZWcgdGVzdCBmYWlsZWQgZmYKdW5rbm93bjogc3RhdHVzIHJlZyB0ZXN0IGZhaWxlZCBmZgp1bmtu b3duOiBzdGF0dXMgcmVnIHRlc3QgZmFpbGVkIGZmCnNjOiBzYzAgYWxyZWFkeSBleGlzdHM7IHNr aXBwaW5nIGl0CnZnYTogdmdhMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKaXNhX3Byb2Jl X2NoaWxkcmVuOiBkaXNhYmxpbmcgUG5QIGRldmljZXMKaXNhX3Byb2JlX2NoaWxkcmVuOiBwcm9i aW5nIG5vbi1QblAgZGV2aWNlcwpwbXRpbWVyMCBvbiBpc2EwCm9ybTA6IDxJU0EgT3B0aW9uIFJP TXM+IGF0IGlvbWVtIDB4YzAwMDAtMHhjY2ZmZiwweGNkMDAwLTB4ZDRmZmYgb24gaXNhMAphZHYw OiBub3QgcHJvYmVkIChkaXNhYmxlZCkKYWhhMDogbm90IHByb2JlZCAoZGlzYWJsZWQpCmFpYzA6 IG5vdCBwcm9iZWQgKGRpc2FibGVkKQpidDA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQpjczA6IG5v dCBwcm9iZWQgKGRpc2FibGVkKQplZDA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQpmZTA6IG5vdCBw cm9iZWQgKGRpc2FibGVkKQppZTA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQpsbmMwOiBub3QgcHJv YmVkIChkaXNhYmxlZCkKcHBjMDogcGFyYWxsZWwgcG9ydCBub3QgZm91bmQuCnBwYzA6IDxQYXJh bGxlbCBwb3J0PiBmYWlsZWQgdG8gcHJvYmUgYXQgaXJxIDcgb24gaXNhMApzYzA6IDxTeXN0ZW0g Y29uc29sZT4gYXQgZmxhZ3MgMHgxMDAgb24gaXNhMApzYzA6IFZHQSA8MTYgdmlydHVhbCBjb25z b2xlcywgZmxhZ3M9MHgzMDA+CnNjMDogZmIwLCBrYmQwLCB0ZXJtaW5hbCBlbXVsYXRvcjogc2Mg KHN5c2NvbnMgdGVybWluYWwpCnNpbzE6IGNvbmZpZ3VyZWQgaXJxIDMgbm90IGluIGJpdG1hcCBv ZiBwcm9iZWQgaXJxcyAwCnNpbzE6IHBvcnQgbWF5IG5vdCBiZSBlbmFibGVkCnNpbzE6IGlycSBt YXBzOiAwIDAgMCAwCnNpbzE6IHByb2JlIGZhaWxlZCB0ZXN0KHMpOiAwIDEgMiA0IDYgNyA5CnNp bzEgZmFpbGVkIHRvIHByb2JlIGF0IHBvcnQgMHgyZjgtMHgyZmYgaXJxIDMgb24gaXNhMApzaW8y OiBub3QgcHJvYmVkIChkaXNhYmxlZCkKc2lvMzogbm90IHByb2JlZCAoZGlzYWJsZWQpCnNuMDog bm90IHByb2JlZCAoZGlzYWJsZWQpCnZnYTA6IDxHZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgz YzAtMHgzZGYgaW9tZW0gMHhhMDAwMC0weGJmZmZmIG9uIGlzYTAKdnQwOiBub3QgcHJvYmVkIChk aXNhYmxlZCkKaXNhX3Byb2JlX2NoaWxkcmVuOiBwcm9iaW5nIFBuUCBkZXZpY2VzCnVtczA6IExv Z2l0ZWNoIFVTQi1QUy8yIE9wdGljYWwgTW91c2UsIHJldiAyLjAwLzExLjEwLCBhZGRyIDIsIGlj bGFzcyAzLzEKdW1zMDogMyBidXR0b25zIGFuZCBaIGRpci4KRGV2aWNlIGNvbmZpZ3VyYXRpb24g ZmluaXNoZWQuCnByb2NmcyByZWdpc3RlcmVkCmxhcGljOiBEaXZpc29yIDIsIEZyZXF1ZW5jeSAx MDAwMjg2MDAgaHoKVGltZWNvdW50ZXIgIlRTQyIgZnJlcXVlbmN5IDMwMDA4Njg2MTMgSHogcXVh bGl0eSAtMTAwClRpbWVjb3VudGVycyB0aWNrIGV2ZXJ5IDEuMDAwIG1zZWMKbG8wOiBicGYgYXR0 YWNoZWQKbWQwOiBQcmVsb2FkZWQgaW1hZ2UgPC9ib290L21mc3Jvb3Q+IDQ0MjM2ODAgYnl0ZXMg YXQgMHhjMGE4MDM3OAphdGEwLW1hc3RlcjogcGlvPVBJTzQgd2RtYT1XRE1BMiB1ZG1hPVVETUEz MyBjYWJsZT00MCB3aXJlCmFjZDA6IHNldHRpbmcgUElPNCBvbiBTaVMgOTY0IGNoaXAKYWNkMDog c2V0dGluZyBVRE1BMzMgb24gU2lTIDk2NCBjaGlwCmFjZDA6IDxUT1NISUJBIENEL0RWRFcgU0Qt UjUzNzIvVFU1NT4gRFZEUiBkcml2ZSBhdCBhdGEwIGFzIG1hc3RlcgphY2QwOiByZWFkIDgyNjhL Qi9zICg4MjY4S0Ivcykgd3JpdGUgODI2OEtCL3MgKDgyNjhLQi9zKSwgMjA0OEtCIGJ1ZmZlciwg VURNQTMzCmFjZDA6IFJlYWRzOiBDRFIsIENEUlcsIENEREEgc3RyZWFtLCBEVkRST00sIERWRFIs IERWRFJBTSwgcGFja2V0CmFjZDA6IFdyaXRlczogQ0RSLCBDRFJXLCBEVkRSLCB0ZXN0IHdyaXRl LCBidXJucHJvb2YKYWNkMDogQXVkaW86IHBsYXksIDE2IHZvbHVtZSBsZXZlbHMKYWNkMDogTWVj aGFuaXNtOiBlamVjdGFibGUgdHJheSwgdW5sb2NrZWQKYWNkMDogTWVkaXVtOiBDRC1SIDEyMG1t IGRhdGEgZGlzYwphdGEyOiByZWluaXRpbmcgY2hhbm5lbCAuLgphdGEyOiByZXNldCB0cDEgbWFz az0wMyBvc3RhdDA9NTggb3N0YXQxPTU4CmF0YTI6IHN0YXQwPTB4NTAgZXJyPTB4MDEgbHNiPTB4 MDAgbXNiPTB4MDAKYXRhMjogc3RhdDE9MHgwMCBlcnI9MHgwMSBsc2I9MHgwMCBtc2I9MHgwMAph dGEyOiByZXNldCB0cDIgc3RhdDA9NTAgc3RhdDE9MDAgZGV2aWNlcz0weDE8QVRBX01BU1RFUj4K YXRhMjogcmVpbml0IGRvbmUgLi4KYXRhMjogcmVpbml0aW5nIGNoYW5uZWwgLi4KYXRhMjogcmVz ZXQgdHAxIG1hc2s9MDMgb3N0YXQwPTU4IG9zdGF0MT01OAphdGEyOiBzdGF0MD0weDUwIGVycj0w eDAxIGxzYj0weDAwIG1zYj0weDAwCmF0YTI6IHN0YXQxPTB4MDAgZXJyPTB4MDEgbHNiPTB4MDAg bXNiPTB4MDAKYXRhMjogcmVzZXQgdHAyIHN0YXQwPTUwIHN0YXQxPTAwIGRldmljZXM9MHgxPEFU QV9NQVNURVI+CmF0YTI6IHJlaW5pdCBkb25lIC4uCkFUQSBQc2V1ZG9SQUlEIGxvYWRlZApTTVA6 IEFQIENQVSAjMSBMYXVuY2hlZCEKY3B1MSBBUDoKICAgICBJRDogMHgwMTAwMDAwMCAgIFZFUjog MHgwMDA1MDAxNCBMRFI6IDB4MDIwMDAwMDAgREZSOiAweDBmZmZmZmZmCiAgbGludDA6IDB4MDAw MTA3MDAgbGludDE6IDB4MDAwMDA0MDAgVFBSOiAweDAwMDAwMDAwIFNWUjogMHgwMDAwMDFmZgog IHRpbWVyOiAweDAwMDIwMGVmIHRoZXJtOiAweDAwMDEwMDAwIGVycjogMHgwMDAxMDAwMCBwY206 IDB4MDAwMTAwMDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMSAoSVNBIElSUSAxKSB0byBjbHVz dGVyIDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gNCAoSVNBIElSUSA0KSB0byBjbHVzdGVyIDAK aW9hcGljMDogcm91dGluZyBpbnRwaW4gNiAoSVNBIElSUSA2KSB0byBjbHVzdGVyIDAKaW9hcGlj MDogcm91dGluZyBpbnRwaW4gOSAoSVNBIElSUSA5KSB0byBjbHVzdGVyIDAKaW9hcGljMDogcm91 dGluZyBpbnRwaW4gMTMgKElTQSBJUlEgMTMpIHRvIGNsdXN0ZXIgMAppb2FwaWMwOiByb3V0aW5n IGludHBpbiAxNCAoSVNBIElSUSAxNCkgdG8gY2x1c3RlciAwCmlvYXBpYzA6IHJvdXRpbmcgaW50 cGluIDE1IChJU0EgSVJRIDE1KSB0byBjbHVzdGVyIDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4g MTcgKFBDSSBJUlEgMTcpIHRvIGNsdXN0ZXIgMAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAxOSAo UENJIElSUSAxOSkgdG8gY2x1c3RlciAwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDIwIChQQ0kg SVJRIDIwKSB0byBjbHVzdGVyIDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMjEgKFBDSSBJUlEg MjEpIHRvIGNsdXN0ZXIgMAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAyMiAoUENJIElSUSAyMikg dG8gY2x1c3RlciAwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDIzIChQQ0kgSVJRIDIzKSB0byBj bHVzdGVyIDAKVHJ5aW5nIHRvIG1vdW50IHJvb3QgZnJvbSB1ZnM6L2Rldi9tZDAKc3RhcnRfaW5p dDogdHJ5aW5nIC9zYmluL2luaXQKc3RhcnRfaW5pdDogdHJ5aW5nIC9zYmluL29pbml0CnN0YXJ0 X2luaXQ6IHRyeWluZyAvc2Jpbi9pbml0LmJhawpzdGFydF9pbml0OiB0cnlpbmcgL3Jlc2N1ZS9p bml0CnN0YXJ0X2luaXQ6IHRyeWluZyAvc3RhbmQvc3lzaW5zdGFsbAo= ------=_Part_13991_8873011.1125220793590 Content-Type: text/plain; name="dmesg_5_4_RELEASE.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dmesg_5_4_RELEASE.txt" cG10aW1lcjAgb24gaXNhMApwcGMwOiBwYXJhbGxlbCBwb3J0IG5vdCBmb3VuZC4Kc2MwOiA8U3lz dGVtIGNvbnNvbGU+IGF0IGZsYWdzIDB4MTAwIG9uIGlzYTAKc2MwOiBWR0EgPDE2IHZpcnR1YWwg Y29uc29sZXMsIGZsYWdzPTB4MzAwPgpzaW8xOiBjb25maWd1cmVkIGlycSAzIG5vdCBpbiBiaXRt YXAgb2YgcHJvYmVkIGlycXMgMApzaW8xOiBwb3J0IG1heSBub3QgYmUgZW5hYmxlZAp2Z2EwOiA8 R2VuZXJpYyBJU0EgVkdBPiBhdCBwb3J0IDB4M2MwLTB4M2RmIGlvbWVtIDB4YTAwMDAtMHhiZmZm ZiBvbiBpc2EwCnVtczA6IExvZ2l0ZWNoIFVTQi1QUy8yIE9wdGljYWwgTW91c2UsIHJldiAyLjAw LzExLjEwLCBhZGRyIDIsIGljbGFzcyAzLzEKdW1zMDogMyBidXR0b25zIGFuZCBaIGRpci4KVGlt ZWNvdW50ZXIgIlRTQyIgZnJlcXVlbmN5IDMwMDA4NjAxMDcgSHogcXVhbGl0eSA4MDAKVGltZWNv dW50ZXJzIHRpY2sgZXZlcnkgMTAuMDAwIG1zZWMKYWNkMDogRFZEUiA8VE9TSElCQSBDRC9EVkRX IFNELVI1MzcyL1RVNTU+IGF0IGF0YTAtbWFzdGVyIFBJTzQKYWQ0OiA3NjMxOU1CIDxTVDM4MDgx N0FTLzMuNDI+IFsxNTUwNjEvMTYvNjNdIGF0IGF0YTItbWFzdGVyIFNBVEExNTAKTW91bnRpbmcg cm9vdCBmcm9tIHVmczovZGV2L2FkNHMzYQpXYWl0aW5nIChtYXggNjAgc2Vjb25kcykgZm9yIHN5 c3RlbSBwcm9jZXNzIGB2bmxydScgdG8gc3RvcC4uLmRvbmUKV2FpdGluZyAobWF4IDYwIHNlY29u ZHMpIGZvciBzeXN0ZW0gcHJvY2VzcyBgYnVmZGFlbW9uJyB0byBzdG9wLi4uZG9uZQpXYWl0aW5n IChtYXggNjAgc2Vjb25kcykgZm9yIHN5c3RlbSBwcm9jZXNzIGBzeW5jZXInIHRvIHN0b3AuLi4K U3luY2luZyBkaXNrcywgdm5vZGVzIHJlbWFpbmluZy4uLjMgMyAzIDEgMSAwIDAgMCBkb25lCk5v IGJ1ZmZlcnMgYnVzeSBhZnRlciBmaW5hbCBzeW5jClVwdGltZTogMWgyNG0zM3MKQ29weXJpZ2h0 IChjKSAxOTkyLTIwMDUgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChjKSAxOTc5LCAx OTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAxOTk0CglUaGUg UmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmlnaHRzIHJlc2Vy dmVkLgpGcmVlQlNEIDUuNC1SRUxFQVNFICMwOiBTYXQgSnVsICAyIDAxOjI1OjM1IEVFU1QgMjAw NQogICAgcm9vdEBwNDovdXNyL29iai91c3Ivc3JjL3N5cy9DVVNUT01LRVJORUwKUHJlbG9hZGVk IGVsZiBrZXJuZWwgIi9ib290L2tlcm5lbC9rZXJuZWwiIGF0IDB4YzBhNGQwMDAuClByZWxvYWRl ZCBlbGYgbW9kdWxlICIvYm9vdC9rZXJuZWwvYWNwaS5rbyIgYXQgMHhjMGE0ZDIxYy4KVGFibGUg J0ZBQ1AnIGF0IDB4M2ZmYjAyMDAKVGFibGUgJ0FQSUMnIGF0IDB4M2ZmYjAzOTAKTUFEVDogRm91 bmQgdGFibGUgYXQgMHgzZmZiMDM5MApBUElDOiBVc2luZyB0aGUgTUFEVCBlbnVtZXJhdG9yLgpN QURUOiBGb3VuZCBDUFUgQVBJQyBJRCAwIEFDUEkgSUQgMTogZW5hYmxlZApNQURUOiBGb3VuZCBD UFUgQVBJQyBJRCAxIEFDUEkgSUQgMjogZW5hYmxlZApBQ1BJIEFQSUMgVGFibGU6IDxBIE0gSSAg T0VNQVBJQyA+CkNhbGlicmF0aW5nIGNsb2NrKHMpIC4uLiBpODI1NCBjbG9jazogMTE5MzI4NSBI egpDTEtfVVNFX0k4MjU0X0NBTElCUkFUSU9OIG5vdCBzcGVjaWZpZWQgLSB1c2luZyBkZWZhdWx0 IGZyZXF1ZW5jeQpUaW1lY291bnRlciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgyIEh6IHF1YWxp dHkgMApDYWxpYnJhdGluZyBUU0MgY2xvY2sgLi4uIFRTQyBjbG9jazogMzAwMDg2MDI4NyBIegpD UFU6IEludGVsKFIpIFBlbnRpdW0oUikgNCBDUFUgMy4wMEdIeiAoMzAwMC44Ni1NSHogNjg2LWNs YXNzIENQVSkKICBPcmlnaW4gPSAiR2VudWluZUludGVsIiAgSWQgPSAweGY0MSAgU3RlcHBpbmcg PSAxCiAgRmVhdHVyZXM9MHhiZmViZmJmZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNSLFBBRSxNQ0Us Q1g4LEFQSUMsU0VQLE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxQU0UzNixDTEZMVVNILERUUyxBQ1BJ LE1NWCxGWFNSLFNTRSxTU0UyLFNTLEhUVCxUTSxQQkU+CiAgSHlwZXJ0aHJlYWRpbmc6IDIgbG9n aWNhbCBDUFVzCnJlYWwgbWVtb3J5ICA9IDEwNzM0MTQxNDQgKDEwMjMgTUIpClBoeXNpY2FsIG1l bW9yeSBjaHVuayhzKToKMHgwMDAwMDAwMDAwMDAxMDAwIC0gMHgwMDAwMDAwMDAwMDllZmZmLCA2 NDcxNjggYnl0ZXMgKDE1OCBwYWdlcykKMHgwMDAwMDAwMDAwMTAwMDAwIC0gMHgwMDAwMDAwMDAw M2ZmZmZmLCAzMTQ1NzI4IGJ5dGVzICg3NjggcGFnZXMpCjB4MDAwMDAwMDAwMGMyNTAwMCAtIDB4 MDAwMDAwMDAzZWQ4MGZmZiwgMTA0MTYxMjgwMCBieXRlcyAoMjU0MzAwIHBhZ2VzKQphdmFpbCBt ZW1vcnkgPSAxMDQwODY3MzI4ICg5OTIgTUIpCmJpb3MzMjogRm91bmQgQklPUzMyIFNlcnZpY2Ug RGlyZWN0b3J5IGhlYWRlciBhdCAweGMwMGYwMDAwCmJpb3MzMjogRW50cnkgPSAweGYwMDEwIChj MDBmMDAxMCkgIFJldiA9IDAgIExlbiA9IDEKcGNpYmlvczogUENJIEJJT1MgZW50cnkgYXQgMHhm MDAwMCsweDMxCnBucGJpb3M6IEZvdW5kIFBuUCBCSU9TIGRhdGEgYXQgMHhjMDBmNmFlMApwbnBi aW9zOiBFbnRyeSA9IGYwMDAwOjc2ZGEgIFJldiA9IDEuMApPdGhlciBCSU9TIHNpZ25hdHVyZXMg Zm91bmQ6CkFQSUM6IENQVSAwIGhhcyBBQ1BJIElEIDEKTUFEVDogRm91bmQgSU8gQVBJQyBJRCAy LCBJbnRlcnJ1cHQgMCBhdCAweGZlYzAwMDAwCmlvYXBpYzA6IENoYW5naW5nIEFQSUMgSUQgdG8g Mgppb2FwaWMwOiBSb3V0aW5nIGV4dGVybmFsIDgyNTlBJ3MgLT4gaW50cGluIDAKaW9hcGljMDog aW50cGluIDAgLT4gRXh0SU5UIChlZGdlLCBoaWdoKQppb2FwaWMwOiBpbnRwaW4gMSAtPiBJU0Eg SVJRIDEgKGVkZ2UsIGhpZ2gpCmlvYXBpYzA6IGludHBpbiAyIC0+IElTQSBJUlEgMiAoZWRnZSwg aGlnaCkKaW9hcGljMDogaW50cGluIDMgLT4gSVNBIElSUSAzIChlZGdlLCBoaWdoKQppb2FwaWMw OiBpbnRwaW4gNCAtPiBJU0EgSVJRIDQgKGVkZ2UsIGhpZ2gpCmlvYXBpYzA6IGludHBpbiA1IC0+ IElTQSBJUlEgNSAoZWRnZSwgaGlnaCkKaW9hcGljMDogaW50cGluIDYgLT4gSVNBIElSUSA2IChl ZGdlLCBoaWdoKQppb2FwaWMwOiBpbnRwaW4gNyAtPiBJU0EgSVJRIDcgKGVkZ2UsIGhpZ2gpCmlv YXBpYzA6IGludHBpbiA4IC0+IElTQSBJUlEgOCAoZWRnZSwgaGlnaCkKaW9hcGljMDogaW50cGlu IDkgLT4gSVNBIElSUSA5IChlZGdlLCBoaWdoKQppb2FwaWMwOiBpbnRwaW4gMTAgLT4gSVNBIElS USAxMCAoZWRnZSwgaGlnaCkKaW9hcGljMDogaW50cGluIDExIC0+IElTQSBJUlEgMTEgKGVkZ2Us IGhpZ2gpCmlvYXBpYzA6IGludHBpbiAxMiAtPiBJU0EgSVJRIDEyIChlZGdlLCBoaWdoKQppb2Fw aWMwOiBpbnRwaW4gMTMgLT4gSVNBIElSUSAxMyAoZWRnZSwgaGlnaCkKaW9hcGljMDogaW50cGlu IDE0IC0+IElTQSBJUlEgMTQgKGVkZ2UsIGhpZ2gpCmlvYXBpYzA6IGludHBpbiAxNSAtPiBJU0Eg SVJRIDE1IChlZGdlLCBoaWdoKQppb2FwaWMwOiBpbnRwaW4gMTYgLT4gUENJIElSUSAxNiAobGV2 ZWwsIGxvdykKaW9hcGljMDogaW50cGluIDE3IC0+IFBDSSBJUlEgMTcgKGxldmVsLCBsb3cpCmlv YXBpYzA6IGludHBpbiAxOCAtPiBQQ0kgSVJRIDE4IChsZXZlbCwgbG93KQppb2FwaWMwOiBpbnRw aW4gMTkgLT4gUENJIElSUSAxOSAobGV2ZWwsIGxvdykKaW9hcGljMDogaW50cGluIDIwIC0+IFBD SSBJUlEgMjAgKGxldmVsLCBsb3cpCmlvYXBpYzA6IGludHBpbiAyMSAtPiBQQ0kgSVJRIDIxIChs ZXZlbCwgbG93KQppb2FwaWMwOiBpbnRwaW4gMjIgLT4gUENJIElSUSAyMiAobGV2ZWwsIGxvdykK aW9hcGljMDogaW50cGluIDIzIC0+IFBDSSBJUlEgMjMgKGxldmVsLCBsb3cpCk1BRFQ6IEludGVy cnVwdCBvdmVycmlkZTogc291cmNlIDAsIGlycSAyCmlvYXBpYzA6IFJvdXRpbmcgSVJRIDAgLT4g aW50cGluIDIKaW9hcGljMDogaW50cGluIDIgdHJpZ2dlcjogZWRnZQppb2FwaWMwOiBpbnRwaW4g MiBwb2xhcml0eTogaGlnaApNQURUOiBJbnRlcnJ1cHQgb3ZlcnJpZGU6IHNvdXJjZSA5LCBpcnEg OQppb2FwaWMwOiBpbnRwaW4gOSB0cmlnZ2VyOiBsZXZlbAppb2FwaWMwOiBpbnRwaW4gOSBwb2xh cml0eTogbG93CmlvYXBpYzAgPFZlcnNpb24gMS4xPiBpcnFzIDAtMjMgb24gbW90aGVyYm9hcmQK Y3B1MCBCU1A6CiAgICAgSUQ6IDB4MDAwMDAwMDAgICBWRVI6IDB4MDAwNTAwMTQgTERSOiAweDAx MDAwMDAwIERGUjogMHgwZmZmZmZmZgogIGxpbnQwOiAweDAwMDEwNzAwIGxpbnQxOiAweDAwMDAw NDAwIFRQUjogMHgwMDAwMDAwMCBTVlI6IDB4MDAwMDAxZmYKd2xhbjogPDgwMi4xMSBMaW5rIExh eWVyPgpudWxsOiA8bnVsbCBkZXZpY2UsIHplcm8gZGV2aWNlPgpyYW5kb206IDxlbnRyb3B5IHNv dXJjZSwgU29mdHdhcmUsIFlhcnJvdz4KaW86IDxJL08+Cm1lbTogPG1lbW9yeT4KUGVudGl1bSBQ cm8gTVRSUiBzdXBwb3J0IGVuYWJsZWQKbnB4MDogW0ZBU1RdCm5weDA6IDxtYXRoIHByb2Nlc3Nv cj4gb24gbW90aGVyYm9hcmQKbnB4MDogSU5UIDE2IGludGVyZmFjZQphY3BpMDogPEEgTSBJIE9F TVJTRFQ+IG9uIG1vdGhlcmJvYXJkCmFjcGkwOiBbTVBTQUZFXQpwY2lfb3BlbigxKToJbW9kZSAx IGFkZHIgcG9ydCAoMHgwY2Y4KSBpcyAweDgwMDEwMDE0CnBjaV9vcGVuKDFhKToJbW9kZTFyZXM9 MHg4MDAwMDAwMCAoMHg4MDAwMDAwMCkKcGNpX2NmZ2NoZWNrOglkZXZpY2UgMCBbY2xhc3M9MDYw MDAwXSBbaGRyPTgwXSBpcyB0aGVyZSAoaWQ9MDY1NTEwMzkpCnBjaWJpb3M6IEJJT1MgdmVyc2lv biAyLjEwCkZvdW5kICRQSVIgdGFibGUsIDEwIGVudHJpZXMgYXQgMHhjMDBmNjliMApQQ0ktT25s eSBJbnRlcnJ1cHRzOiBub25lCkxvY2F0aW9uICBCdXMgRGV2aWNlIFBpbiAgTGluayAgSVJRcwpl bWJlZGRlZCAgICAwICAgIDIgICAgQSAgIDB4NDEgIDMgNCA1IDcgMTAgMTEgMTIgMTQgMTUKZW1i ZWRkZWQgICAgMCAgICAyICAgIEIgICAweDQyICAzIDQgNSA3IDEwIDExIDEyIDE0IDE1CmVtYmVk ZGVkICAgIDAgICAgMiAgICBDICAgMHg0MyAgMyA0IDUgNyAxMCAxMSAxMiAxNCAxNQplbWJlZGRl ZCAgICAwICAgIDIgICAgRCAgIDB4NDQgIDMgNCA1IDcgMTAgMTEgMTIgMTQgMTUKZW1iZWRkZWQg ICAgMCAgICAzICAgIEEgICAweDYwICAzIDQgNSA3IDEwIDExIDEyIDE0IDE1CmVtYmVkZGVkICAg IDAgICAgMyAgICBCICAgMHg2MSAgMyA0IDUgNyAxMCAxMSAxMiAxNCAxNQplbWJlZGRlZCAgICAw ICAgIDMgICAgQyAgIDB4NjIgIDMgNCA1IDcgMTAgMTEgMTIgMTQgMTUKZW1iZWRkZWQgICAgMCAg ICAzICAgIEQgICAweDYzICAzIDQgNSA3IDEwIDExIDEyIDE0IDE1CmVtYmVkZGVkICAgIDAgICAg NSAgICBBICAgMHg0MiAgMyA0IDUgNyAxMCAxMSAxMiAxNCAxNQplbWJlZGRlZCAgICAwICAgIDEg ICAgQSAgIDB4NDEgIDMgNCA1IDcgMTAgMTEgMTIgMTQgMTUKZW1iZWRkZWQgICAgMCAgICAxICAg IEIgICAweDQyICAzIDQgNSA3IDEwIDExIDEyIDE0IDE1CmVtYmVkZGVkICAgIDAgICAgMSAgICBD ICAgMHg0MyAgMyA0IDUgNyAxMCAxMSAxMiAxNCAxNQplbWJlZGRlZCAgICAwICAgIDEgICAgRCAg IDB4NDQgIDMgNCA1IDcgMTAgMTEgMTIgMTQgMTUKZW1iZWRkZWQgICAgMCAgICA0ICAgIEEgICAw eDQ0ICAzIDQgNSA3IDEwIDExIDEyIDE0IDE1CnNsb3QgMSAgICAgIDAgICAgOCAgICBBICAgMHg0 MSAgMyA0IDUgNyAxMCAxMSAxMiAxNCAxNQpzbG90IDEgICAgICAwICAgIDggICAgQiAgIDB4NDIg IDMgNCA1IDcgMTAgMTEgMTIgMTQgMTUKc2xvdCAxICAgICAgMCAgICA4ICAgIEMgICAweDQzICAz IDQgNSA3IDEwIDExIDEyIDE0IDE1CnNsb3QgMSAgICAgIDAgICAgOCAgICBEICAgMHg0NCAgMyA0 IDUgNyAxMCAxMSAxMiAxNCAxNQpzbG90IDIgICAgICAwICAgIDkgICAgQSAgIDB4NDIgIDMgNCA1 IDcgMTAgMTEgMTIgMTQgMTUKc2xvdCAyICAgICAgMCAgICA5ICAgIEIgICAweDQzICAzIDQgNSA3 IDEwIDExIDEyIDE0IDE1CnNsb3QgMiAgICAgIDAgICAgOSAgICBDICAgMHg0NCAgMyA0IDUgNyAx MCAxMSAxMiAxNCAxNQpzbG90IDIgICAgICAwICAgIDkgICAgRCAgIDB4NDEgIDMgNCA1IDcgMTAg MTEgMTIgMTQgMTUKc2xvdCAzICAgICAgMCAgIDEwICAgIEEgICAweDQzICAzIDQgNSA3IDEwIDEx IDEyIDE0IDE1CnNsb3QgMyAgICAgIDAgICAxMCAgICBCICAgMHg0NCAgMyA0IDUgNyAxMCAxMSAx MiAxNCAxNQpzbG90IDMgICAgICAwICAgMTAgICAgQyAgIDB4NDEgIDMgNCA1IDcgMTAgMTEgMTIg MTQgMTUKc2xvdCAzICAgICAgMCAgIDEwICAgIEQgICAweDQyICAzIDQgNSA3IDEwIDExIDEyIDE0 IDE1CnNsb3QgNCAgICAgIDAgICAxMSAgICBBICAgMHg0NCAgMyA0IDUgNyAxMCAxMSAxMiAxNCAx NQpzbG90IDQgICAgICAwICAgMTEgICAgQiAgIDB4NDEgIDMgNCA1IDcgMTAgMTEgMTIgMTQgMTUK c2xvdCA0ICAgICAgMCAgIDExICAgIEMgICAweDQyICAzIDQgNSA3IDEwIDExIDEyIDE0IDE1CnNs b3QgNCAgICAgIDAgICAxMSAgICBEICAgMHg0MyAgMyA0IDUgNyAxMCAxMSAxMiAxNCAxNQpzbG90 IDUgICAgICAwICAgMTIgICAgQSAgIDB4NDEgIDMgNCA1IDcgMTAgMTEgMTIgMTQgMTUKc2xvdCA1 ICAgICAgMCAgIDEyICAgIEIgICAweDQyICAzIDQgNSA3IDEwIDExIDEyIDE0IDE1CnNsb3QgNSAg ICAgIDAgICAxMiAgICBDICAgMHg0MyAgMyA0IDUgNyAxMCAxMSAxMiAxNCAxNQpzbG90IDUgICAg ICAwICAgMTIgICAgRCAgIDB4NDQgIDMgNCA1IDcgMTAgMTEgMTIgMTQgMTUKQWNwaU9zRGVyaXZl UGNpSWQ6IGJ1cyAwIGRldiAyIGZ1bmMgMApBY3BpT3NEZXJpdmVQY2lJZDogYnVzIDAgZGV2IDIg ZnVuYyAwCmFjcGkwOiBQb3dlciBCdXR0b24gKGZpeGVkKQpBQ1BJIHRpbWVyOiAxLzEgMS8xIDEv MSAxLzEgMS8xIDEvMSAxLzEgMS8xIDEvMSAxLzEgLT4gMTAKVGltZWNvdW50ZXIgIkFDUEktZmFz dCIgZnJlcXVlbmN5IDM1Nzk1NDUgSHogcXVhbGl0eSAxMDAwCmFjcGlfdGltZXIwOiA8MjQtYml0 IHRpbWVyIGF0IDMuNTc5NTQ1TUh6PiBwb3J0IDB4ODA4LTB4ODBiIG9uIGFjcGkwCmNwdTA6IDxB Q1BJIENQVT4gb24gYWNwaTAKYWNwaV90aHJvdHRsZTA6IDxBQ1BJIENQVSBUaHJvdHRsaW5nPiBv biBjcHUwCmFjcGlfdGhyb3R0bGUwOiBQX0NOVCBmcm9tIFBfQkxLIDB4ODEwCnBjaWIwOiA8QUNQ SSBIb3N0LVBDSSBicmlkZ2U+IHBvcnQgMHhjZjgtMHhjZmYgb24gYWNwaTAKQUNQSSBQQ0kgbGlu ayBpbml0aWFsIGNvbmZpZ3VyYXRpb246CnBjaTA6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIwCnBj aTA6IHBoeXNpY2FsIGJ1cz0wCgltYXBbMTBdOiB0eXBlIDEsIHJhbmdlIDMyLCBiYXNlIGY4MDAw MDAwLCBzaXplIDI2LCBlbmFibGVkCmZvdW5kLT4JdmVuZG9yPTB4MTAzOSwgZGV2PTB4MDY1NSwg cmV2aWQ9MHg1MAoJYnVzPTAsIHNsb3Q9MCwgZnVuYz0wCgljbGFzcz0wNi0wMC0wMCwgaGRydHlw ZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MjIxMCwgY2FjaGVsbnN6 PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MjAgKDk2MCBucyksIG1pbmdudD0weDAwICgwIG5zKSwg bWF4bGF0PTB4MDAgKDAgbnMpCmZvdW5kLT4JdmVuZG9yPTB4MTAzOSwgZGV2PTB4MDAwMywgcmV2 aWQ9MHgwMAoJYnVzPTAsIHNsb3Q9MSwgZnVuYz0wCgljbGFzcz0wNi0wNC0wMCwgaGRydHlwZT0w eDAxLCBtZmRldj0wCgljbWRyZWc9MHgwMTA3LCBzdGF0cmVnPTB4MDAyMCwgY2FjaGVsbnN6PTAg KGR3b3JkcykKCWxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5nbnQ9MHgwYSAoMjUwMCBucyks IG1heGxhdD0weDAwICgwIG5zKQpmb3VuZC0+CXZlbmRvcj0weDEwMzksIGRldj0weDA5NjQsIHJl dmlkPTB4MzYKCWJ1cz0wLCBzbG90PTIsIGZ1bmM9MAoJY2xhc3M9MDYtMDEtMDAsIGhkcnR5cGU9 MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwZiwgc3RhdHJlZz0weDAyMDAsIGNhY2hlbG5zej0w IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhs YXQ9MHgwMCAoMCBucykKCW1hcFsyMF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMGZmYTAs IHNpemUgIDQsIGVuYWJsZWQKZm91bmQtPgl2ZW5kb3I9MHgxMDM5LCBkZXY9MHg1NTEzLCByZXZp ZD0weDAxCglidXM9MCwgc2xvdD0yLCBmdW5jPTUKCWNsYXNzPTAxLTAxLThhLCBoZHJ0eXBlPTB4 MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDUsIHN0YXRyZWc9MHgwMjEwLCBjYWNoZWxuc3o9MCAo ZHdvcmRzKQoJbGF0dGltZXI9MHg4MCAoMzg0MCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4 bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTI1NQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRz IEQwIEQzICBjdXJyZW50IEQwCgltYXBbMTBdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDBl ODAwLCBzaXplICA4LCBlbmFibGVkCgltYXBbMTRdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAw MDBlYzAwLCBzaXplICA3LCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjIuSU5U QwpwY2liMDogc2xvdCAyIElOVEMgaGFyZHdpcmVkIHRvIElSUSAxOApmb3VuZC0+CXZlbmRvcj0w eDEwMzksIGRldj0weDcwMTIsIHJldmlkPTB4YTAKCWJ1cz0wLCBzbG90PTIsIGZ1bmM9NwoJY2xh c3M9MDQtMDEtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDEwNSwgc3RhdHJl Zz0weDAyOTAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDQwICgxOTIwIG5zKSwg bWluZ250PTB4MzQgKDEzMDAwIG5zKSwgbWF4bGF0PTB4MGIgKDI3NTAgbnMpCglpbnRwaW49Yywg aXJxPTE4Cglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDEgRDIgRDMgIGN1cnJlbnQgRDAKCW1h cFsxMF06IHR5cGUgMSwgcmFuZ2UgMzIsIGJhc2UgZmY2ZmMwMDAsIHNpemUgMTIsIGVuYWJsZWQK cGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMy5JTlRBCnBjaWIwOiBzbG90IDMgSU5UQSBoYXJk d2lyZWQgdG8gSVJRIDIwCmZvdW5kLT4JdmVuZG9yPTB4MTAzOSwgZGV2PTB4NzAwMSwgcmV2aWQ9 MHgwZgoJYnVzPTAsIHNsb3Q9MywgZnVuYz0wCgljbGFzcz0wYy0wMy0xMCwgaGRydHlwZT0weDAw LCBtZmRldj0xCgljbWRyZWc9MHgwMTE3LCBzdGF0cmVnPTB4MDI4MCwgY2FjaGVsbnN6PTAgKGR3 b3JkcykKCWxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxh dD0weDUwICgyMDAwMCBucykKCWludHBpbj1hLCBpcnE9MjAKCW1hcFsxMF06IHR5cGUgMSwgcmFu Z2UgMzIsIGJhc2UgZmY2ZmQwMDAsIHNpemUgMTIsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50 cnkgZm9yIDAuMy5JTlRCCnBjaWIwOiBzbG90IDMgSU5UQiBoYXJkd2lyZWQgdG8gSVJRIDIxCmZv dW5kLT4JdmVuZG9yPTB4MTAzOSwgZGV2PTB4NzAwMSwgcmV2aWQ9MHgwZgoJYnVzPTAsIHNsb3Q9 MywgZnVuYz0xCgljbGFzcz0wYy0wMy0xMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9 MHgwMTE3LCBzdGF0cmVnPTB4MDI4MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4 NDAgKDE5MjAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDUwICgyMDAwMCBucykK CWludHBpbj1iLCBpcnE9MjEKCW1hcFsxMF06IHR5cGUgMSwgcmFuZ2UgMzIsIGJhc2UgZmY2ZmUw MDAsIHNpemUgMTIsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMy5JTlRDCnBj aWIwOiBzbG90IDMgSU5UQyBoYXJkd2lyZWQgdG8gSVJRIDIyCmZvdW5kLT4JdmVuZG9yPTB4MTAz OSwgZGV2PTB4NzAwMSwgcmV2aWQ9MHgwZgoJYnVzPTAsIHNsb3Q9MywgZnVuYz0yCgljbGFzcz0w Yy0wMy0xMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMTE3LCBzdGF0cmVnPTB4 MDI4MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5n bnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDUwICgyMDAwMCBucykKCWludHBpbj1jLCBpcnE9MjIK CW1hcFsxMF06IHR5cGUgMSwgcmFuZ2UgMzIsIGJhc2UgZmY2ZmYwMDAsIHNpemUgMTIsIGVuYWJs ZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMy5JTlRECnBjaWIwOiBzbG90IDMgSU5URCBo YXJkd2lyZWQgdG8gSVJRIDIzCmZvdW5kLT4JdmVuZG9yPTB4MTAzOSwgZGV2PTB4NzAwMiwgcmV2 aWQ9MHgwMAoJYnVzPTAsIHNsb3Q9MywgZnVuYz0zCgljbGFzcz0wYy0wMy0yMCwgaGRydHlwZT0w eDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMTA2LCBzdGF0cmVnPTB4MDI5MCwgY2FjaGVsbnN6PTAg KGR3b3JkcykKCWxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1h eGxhdD0weDUwICgyMDAwMCBucykKCWludHBpbj1kLCBpcnE9MjMKCXBvd2Vyc3BlYyAyICBzdXBw b3J0cyBEMCBEMyAgY3VycmVudCBEMAoJbWFwWzEwXTogdHlwZSA0LCByYW5nZSAzMiwgYmFzZSAw MDAwZTQwMCwgc2l6ZSAgOCwgZW5hYmxlZAoJbWFwWzE0XTogdHlwZSAxLCByYW5nZSAzMiwgYmFz ZSBmZjZmYjAwMCwgc2l6ZSAxMiwgZW5hYmxlZApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC40 LklOVEEKcGNpYjA6IHNsb3QgNCBJTlRBIGhhcmR3aXJlZCB0byBJUlEgMTkKZm91bmQtPgl2ZW5k b3I9MHgxMDM5LCBkZXY9MHgwOTAwLCByZXZpZD0weDkxCglidXM9MCwgc2xvdD00LCBmdW5jPTAK CWNsYXNzPTAyLTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAxMDcsIHN0 YXRyZWc9MHgwMjkwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHg0MCAoMTkyMCBu cyksIG1pbmdudD0weDM0ICgxMzAwMCBucyksIG1heGxhdD0weDBiICgyNzUwIG5zKQoJaW50cGlu PWEsIGlycT0xOQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50IEQw CgltYXBbMTBdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDBlZmYwLCBzaXplICAzLCBlbmFi bGVkCgltYXBbMTRdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDBlZmU0LCBzaXplICAyLCBl bmFibGVkCgltYXBbMThdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDBlZmE4LCBzaXplICAz LCBlbmFibGVkCgltYXBbMWNdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDBlZmUwLCBzaXpl ICAyLCBlbmFibGVkCgltYXBbMjBdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDBlZjkwLCBz aXplICA0LCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjUuSU5UQQpwY2liMDog c2xvdCA1IElOVEEgaGFyZHdpcmVkIHRvIElSUSAxNwpmb3VuZC0+CXZlbmRvcj0weDEwMzksIGRl dj0weDAxODAsIHJldmlkPTB4MDEKCWJ1cz0wLCBzbG90PTUsIGZ1bmM9MAoJY2xhc3M9MDEtMDQt ODUsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDQwNSwgc3RhdHJlZz0weDAyMjAs IGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDgwICgzODQwIG5zKSwgbWluZ250PTB4 MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MTcKYWdwMDogPFNp UyA2NTUgaG9zdCB0byBBR1AgYnJpZGdlPiBtZW0gMHhmODAwMDAwMC0weGZiZmZmZmZmIGF0IGRl dmljZSAwLjAgb24gcGNpMAphZ3AwOiBSZXNlcnZlZCAweDQwMDAwMDAgYnl0ZXMgZm9yIHJpZCAw eDEwIHR5cGUgMyBhdCAweGY4MDAwMDAwCmFncDA6IGFsbG9jYXRpbmcgR0FUVCBmb3IgYXBlcnR1 cmUgb2Ygc2l6ZSA2NE0KcGNpYjE6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMS4w IG9uIHBjaTAKcGNpYjE6ICAgc2Vjb25kYXJ5IGJ1cyAgICAgMQpwY2liMTogICBzdWJvcmRpbmF0 ZSBidXMgICAxCnBjaWIxOiAgIEkvTyBkZWNvZGUgICAgICAgIDB4ZDAwMC0weGRmZmYKcGNpYjE6 ICAgbWVtb3J5IGRlY29kZSAgICAgMHhmZjUwMDAwMC0weGZmNWZmZmZmCnBjaWIxOiAgIHByZWZl dGNoZWQgZGVjb2RlIDB4ZDdmMDAwMDAtMHhmN2VmZmZmZgpwY2liMTogY291bGQgbm90IGdldCBQ Q0kgaW50ZXJydXB0IHJvdXRpbmcgdGFibGUgZm9yIFxcX1NCXy5QQ0kwLlAwUDEgLSBBRV9OT1Rf Rk9VTkQKcGNpMTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjEKcGNpMTogcGh5c2ljYWwgYnVzPTEK CW1hcFsxMF06IHR5cGUgMywgcmFuZ2UgMzIsIGJhc2UgZTgwMDAwMDAsIHNpemUgMjcsIGVuYWJs ZWQKcGNpYjE6IGRldmljZSAobnVsbCkgcmVxdWVzdGVkIGRlY29kZWQgbWVtb3J5IHJhbmdlIDB4 ZTgwMDAwMDAtMHhlZmZmZmZmZgoJbWFwWzE0XTogdHlwZSA0LCByYW5nZSAzMiwgYmFzZSAwMDAw ZDAwMCwgc2l6ZSAgOCwgZW5hYmxlZApwY2liMTogZGV2aWNlIChudWxsKSByZXF1ZXN0ZWQgZGVj b2RlZCBJL08gcmFuZ2UgMHhkMDAwLTB4ZDBmZgoJbWFwWzE4XTogdHlwZSAxLCByYW5nZSAzMiwg YmFzZSBmZjVmMDAwMCwgc2l6ZSAxNiwgZW5hYmxlZApwY2liMTogZGV2aWNlIChudWxsKSByZXF1 ZXN0ZWQgZGVjb2RlZCBtZW1vcnkgcmFuZ2UgMHhmZjVmMDAwMC0weGZmNWZmZmZmCnBjaWIwOiBt YXRjaGVkIGVudHJ5IGZvciAwLjEuSU5UQQpwY2liMDogc2xvdCAxIElOVEEgaGFyZHdpcmVkIHRv IElSUSAxNgpwY2liMTogc2xvdCAwIElOVEEgaXMgcm91dGVkIHRvIGlycSAxNgpmb3VuZC0+CXZl bmRvcj0weDEwMDIsIGRldj0weDU5NjAsIHJldmlkPTB4MDEKCWJ1cz0xLCBzbG90PTAsIGZ1bmM9 MAoJY2xhc3M9MDMtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDEwNywg c3RhdHJlZz0weDAyYjAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHg0MCAoMTky MCBucyksIG1pbmdudD0weDA4ICgyMDAwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49 YSwgaXJxPTE2Cglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDEgRDIgRDMgIGN1cnJlbnQgRDAK CW1hcFsxMF06IHR5cGUgMywgcmFuZ2UgMzIsIGJhc2UgZTAwMDAwMDAsIHNpemUgMjcsIGVuYWJs ZWQKcGNpYjE6IGRldmljZSAobnVsbCkgcmVxdWVzdGVkIGRlY29kZWQgbWVtb3J5IHJhbmdlIDB4 ZTAwMDAwMDAtMHhlN2ZmZmZmZgoJbWFwWzE0XTogdHlwZSAxLCByYW5nZSAzMiwgYmFzZSBmZjVl MDAwMCwgc2l6ZSAxNiwgZW5hYmxlZApwY2liMTogZGV2aWNlIChudWxsKSByZXF1ZXN0ZWQgZGVj b2RlZCBtZW1vcnkgcmFuZ2UgMHhmZjVlMDAwMC0weGZmNWVmZmZmCmZvdW5kLT4JdmVuZG9yPTB4 MTAwMiwgZGV2PTB4NTk0MCwgcmV2aWQ9MHgwMQoJYnVzPTEsIHNsb3Q9MCwgZnVuYz0xCgljbGFz cz0wMy04MC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVn PTB4MDJiMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpCglsYXR0aW1lcj0weDQwICgxOTIwIG5zKSwg bWluZ250PTB4MDggKDIwMDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCXBvd2Vyc3BlYyAyICBz dXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMApkcm0wOiA8QVRJIFJhZGVvbiBSVjI4MCA5 MjAwPiBwb3J0IDB4ZDAwMC0weGQwZmYgbWVtIDB4ZmY1ZjAwMDAtMHhmZjVmZmZmZiwweGU4MDAw MDAwLTB4ZWZmZmZmZmYgaXJxIDE2IGF0IGRldmljZSAwLjAgb24gcGNpMQppbmZvOiBbZHJtXSBB R1AgYXQgMHhmODAwMDAwMCA2NE1CCmluZm86IFtkcm1dIEluaXRpYWxpemVkIHJhZGVvbiAxLjEx LjAgMjAwMjA4Mjggb24gbWlub3IgMApwY2kxOiA8ZGlzcGxheT4gYXQgZGV2aWNlIDAuMSAobm8g ZHJpdmVyIGF0dGFjaGVkKQppc2FiMDogPFBDSS1JU0EgYnJpZGdlPiBhdCBkZXZpY2UgMi4wIG9u IHBjaTAKaXNhMDogPElTQSBidXM+IG9uIGlzYWIwCmF0YXBjaTA6IDxTaVMgOTY0IFVETUExMzMg Y29udHJvbGxlcj4gcG9ydCAweGZmYTAtMHhmZmFmLDB4Mzc2LDB4MTcwLTB4MTc3LDB4M2Y2LDB4 MWYwLTB4MWY3IGF0IGRldmljZSAyLjUgb24gcGNpMAphdGFwY2kwOiBSZXNlcnZlZCAweDEwIGJ5 dGVzIGZvciByaWQgMHgyMCB0eXBlIDQgYXQgMHhmZmEwCmF0YTA6IGNoYW5uZWwgIzAgb24gYXRh cGNpMAphdGFwY2kwOiBSZXNlcnZlZCAweDggYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgNCBhdCAw eDFmMAphdGFwY2kwOiBSZXNlcnZlZCAweDEgYnl0ZXMgZm9yIHJpZCAweDE0IHR5cGUgNCBhdCAw eDNmNgphdGEwOiByZXNldCB0cDEgbWFzaz0wMyBvc3RhdDA9NTAgb3N0YXQxPTAwCmF0YTAtbWFz dGVyOiBzdGF0PTB4MDAgZXJyPTB4MDEgbHNiPTB4MTQgbXNiPTB4ZWIKYXRhMC1zbGF2ZTogIHN0 YXQ9MHgwMCBlcnI9MHgwNCBsc2I9MHgwMCBtc2I9MHgwMAphdGEwOiByZXNldCB0cDIgc3RhdDA9 MDAgc3RhdDE9MDAgZGV2aWNlcz0weDQ8QVRBUElfTUFTVEVSPgphdGEwOiBbTVBTQUZFXQphdGEx OiBjaGFubmVsICMxIG9uIGF0YXBjaTAKYXRhcGNpMDogUmVzZXJ2ZWQgMHg4IGJ5dGVzIGZvciBy aWQgMHgxOCB0eXBlIDQgYXQgMHgxNzAKYXRhcGNpMDogUmVzZXJ2ZWQgMHgxIGJ5dGVzIGZvciBy aWQgMHgxYyB0eXBlIDQgYXQgMHgzNzYKYXRhMTogcmVzZXQgdHAxIG1hc2s9MDMgb3N0YXQwPTAw IG9zdGF0MT0wMAphdGExLW1hc3Rlcjogc3RhdD0weDAwIGVycj0weDAwIGxzYj0weDAwIG1zYj0w eDAwCmF0YTEtc2xhdmU6ICBzdGF0PTB4MDAgZXJyPTB4MDAgbHNiPTB4MDAgbXNiPTB4MDAKYXRh MTogcmVzZXQgdHAyIHN0YXQwPTAwIHN0YXQxPTAwIGRldmljZXM9MHgwCmF0YTE6IFtNUFNBRkVd CnBjaTA6IDxtdWx0aW1lZGlhLCBhdWRpbz4gYXQgZGV2aWNlIDIuNyAobm8gZHJpdmVyIGF0dGFj aGVkKQpvaGNpMDogPFNpUyA1NTcxIFVTQiBjb250cm9sbGVyPiBtZW0gMHhmZjZmYzAwMC0weGZm NmZjZmZmIGlycSAyMCBhdCBkZXZpY2UgMy4wIG9uIHBjaTAKb2hjaTA6IFJlc2VydmVkIDB4MTAw MCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4ZmY2ZmMwMDAKb2hjaTA6IFtHSUFOVC1M T0NLRURdCnVzYjA6IE9IQ0kgdmVyc2lvbiAxLjAsIGxlZ2FjeSBzdXBwb3J0CnVzYjA6IFNNTSBk b2VzIG5vdCByZXNwb25kLCByZXNldHRpbmcKdXNiMDogPFNpUyA1NTcxIFVTQiBjb250cm9sbGVy PiBvbiBvaGNpMAp1c2IwOiBVU0IgcmV2aXNpb24gMS4wCnVodWIwOiBTaVMgT0hDSSByb290IGh1 YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDEKdWh1YjA6IDMgcG9ydHMgd2l0aCAz IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCm9oY2kxOiA8U2lTIDU1NzEgVVNCIGNvbnRyb2xsZXI+ IG1lbSAweGZmNmZkMDAwLTB4ZmY2ZmRmZmYgaXJxIDIxIGF0IGRldmljZSAzLjEgb24gcGNpMApv aGNpMTogUmVzZXJ2ZWQgMHgxMDAwIGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDMgYXQgMHhmZjZm ZDAwMApvaGNpMTogW0dJQU5ULUxPQ0tFRF0KdXNiMTogT0hDSSB2ZXJzaW9uIDEuMCwgbGVnYWN5 IHN1cHBvcnQKdXNiMTogU01NIGRvZXMgbm90IHJlc3BvbmQsIHJlc2V0dGluZwp1c2IxOiA8U2lT IDU1NzEgVVNCIGNvbnRyb2xsZXI+IG9uIG9oY2kxCnVzYjE6IFVTQiByZXZpc2lvbiAxLjAKdWh1 YjE6IFNpUyBPSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMQp1 aHViMTogMyBwb3J0cyB3aXRoIDMgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKb2hjaTI6IDxTaVMg NTU3MSBVU0IgY29udHJvbGxlcj4gbWVtIDB4ZmY2ZmUwMDAtMHhmZjZmZWZmZiBpcnEgMjIgYXQg ZGV2aWNlIDMuMiBvbiBwY2kwCm9oY2kyOiBSZXNlcnZlZCAweDEwMDAgYnl0ZXMgZm9yIHJpZCAw eDEwIHR5cGUgMyBhdCAweGZmNmZlMDAwCm9oY2kyOiBbR0lBTlQtTE9DS0VEXQp1c2IyOiBPSENJ IHZlcnNpb24gMS4wLCBsZWdhY3kgc3VwcG9ydAp1c2IyOiBTTU0gZG9lcyBub3QgcmVzcG9uZCwg cmVzZXR0aW5nCnVzYjI6IDxTaVMgNTU3MSBVU0IgY29udHJvbGxlcj4gb24gb2hjaTIKdXNiMjog VVNCIHJldmlzaW9uIDEuMAp1aHViMjogU2lTIE9IQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2 IDEuMDAvMS4wMCwgYWRkciAxCnVodWIyOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYg cG93ZXJlZApwY2kwOiA8c2VyaWFsIGJ1cywgVVNCPiBhdCBkZXZpY2UgMy4zIChubyBkcml2ZXIg YXR0YWNoZWQpCnNpczA6IDxTaVMgOTAwIDEwLzEwMEJhc2VUWD4gcG9ydCAweGU0MDAtMHhlNGZm IG1lbSAweGZmNmZiMDAwLTB4ZmY2ZmJmZmYgaXJxIDE5IGF0IGRldmljZSA0LjAgb24gcGNpMApz aXMwOiBSZXNlcnZlZCAweDEwMCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSA0IGF0IDB4ZTQwMApt aWlidXMwOiA8TUlJIGJ1cz4gb24gc2lzMApybHBoeTA6IDxSVEw4MjAxTCAxMC8xMDAgbWVkaWEg aW50ZXJmYWNlPiBvbiBtaWlidXMwCnJscGh5MDogIDEwYmFzZVQsIDEwYmFzZVQtRkRYLCAxMDBi YXNlVFgsIDEwMGJhc2VUWC1GRFgsIGF1dG8Kc2lzMDogYnBmIGF0dGFjaGVkCnNpczA6IEV0aGVy bmV0IGFkZHJlc3M6IDAwOjExOmQ4OjBhOmU3OmVhCnNpczA6IFtNUFNBRkVdCmF0YXBjaTE6IDxT aVMgOTY0IFNBVEExNTAgY29udHJvbGxlcj4gcG9ydCAweGVmOTAtMHhlZjlmLDB4ZWZlMC0weGVm ZTMsMHhlZmE4LTB4ZWZhZiwweGVmZTQtMHhlZmU3LDB4ZWZmMC0weGVmZjcgaXJxIDE3IGF0IGRl dmljZSA1LjAgb24gcGNpMAphdGFwY2kxOiBSZXNlcnZlZCAweDEwIGJ5dGVzIGZvciByaWQgMHgy MCB0eXBlIDQgYXQgMHhlZjkwCmF0YXBjaTE6IFtNUFNBRkVdCmF0YTI6IGNoYW5uZWwgIzAgb24g YXRhcGNpMQphdGFwY2kxOiBSZXNlcnZlZCAweDggYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgNCBh dCAweGVmZjAKYXRhcGNpMTogUmVzZXJ2ZWQgMHg0IGJ5dGVzIGZvciByaWQgMHgxNCB0eXBlIDQg YXQgMHhlZmU0CmF0YTI6IHJlc2V0IHRwMSBtYXNrPTAzIG9zdGF0MD01MCBvc3RhdDE9MDAKYXRh Mi1tYXN0ZXI6IHN0YXQ9MHg1MCBlcnI9MHgwMSBsc2I9MHgwMCBtc2I9MHgwMAphdGEyLXNsYXZl OiAgc3RhdD0weDAwIGVycj0weDAxIGxzYj0weDAwIG1zYj0weDAwCmF0YTI6IHJlc2V0IHRwMiBz dGF0MD01MCBzdGF0MT0wMCBkZXZpY2VzPTB4MTxBVEFfTUFTVEVSPgphdGEyOiBbTVBTQUZFXQph dGEzOiBjaGFubmVsICMxIG9uIGF0YXBjaTEKYXRhcGNpMTogUmVzZXJ2ZWQgMHg4IGJ5dGVzIGZv ciByaWQgMHgxOCB0eXBlIDQgYXQgMHhlZmE4CmF0YXBjaTE6IFJlc2VydmVkIDB4NCBieXRlcyBm b3IgcmlkIDB4MWMgdHlwZSA0IGF0IDB4ZWZlMAphdGEzOiByZXNldCB0cDEgbWFzaz0wMyBvc3Rh dDA9N2Ygb3N0YXQxPTdmCmF0YTMtbWFzdGVyOiBzdGF0PTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYg bXNiPTB4ZmYKYXRhMy1tYXN0ZXI6IHN0YXQ9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhm ZgphdGEzLW1hc3Rlcjogc3RhdD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTMt bWFzdGVyOiBzdGF0PTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhMy1tYXN0ZXI6 IHN0YXQ9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGEzLW1hc3Rlcjogc3RhdD0w eDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTMtbWFzdGVyOiBzdGF0PTB4N2YgZXJy PTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhMy1tYXN0ZXI6IHN0YXQ9MHg3ZiBlcnI9MHhmZiBs c2I9MHhmZiBtc2I9MHhmZgphdGEzLXNsYXZlOiAgc3RhdD0weDdmIGVycj0weGZmIGxzYj0weGZm IG1zYj0weGZmCmF0YTM6IHJlc2V0IHRwMiBzdGF0MD1mZiBzdGF0MT1mZiBkZXZpY2VzPTB4MAph dGEzOiBbTVBTQUZFXQphY3BpX2J1dHRvbjA6IDxQb3dlciBCdXR0b24+IG9uIGFjcGkwCmF0a2Jk YzA6IDxLZXlib2FyZCBjb250cm9sbGVyIChpODA0Mik+IHBvcnQgMHg2NCwweDYwIGlycSAxIG9u IGFjcGkwCmF0a2JkMDogPEFUIEtleWJvYXJkPiBpcnEgMSBvbiBhdGtiZGMwCmF0a2JkOiB0aGUg Y3VycmVudCBrYmQgY29udHJvbGxlciBjb21tYW5kIGJ5dGUgMDA2NQphdGtiZDoga2V5Ym9hcmQg SUQgMHg0MWFiICgyKQprYmQwIGF0IGF0a2JkMAprYmQwOiBhdGtiZDAsIEFUIDEwMS8xMDIgKDIp LCBjb25maWc6MHgwLCBmbGFnczoweDNkMDAwMAphdGtiZDA6IFtHSUFOVC1MT0NLRURdCnBzbTA6 IHVuYWJsZSB0byBhbGxvY2F0ZSBJUlEKdW5rbm93bjogbm90IHByb2JlZCAoZGlzYWJsZWQpCmZk YzA6IDxmbG9wcHkgZHJpdmUgY29udHJvbGxlciAoRkRFKT4gcG9ydCAweDNmNywweDNmMC0weDNm NSBpcnEgNiBkcnEgMiBvbiBhY3BpMApmZGMwOiBpY190eXBlIDkwIHBhcnRfaWQgODAKZmRjMDog W01QU0FGRV0KZmRjMDogW0ZBU1RdCmZkMDogPDE0NDAtS0IgMy41IiBkcml2ZT4gb24gZmRjMCBk cml2ZSAwCnVua25vd246IG5vdCBwcm9iZWQgKGRpc2FibGVkKQp1bmtub3duOiBub3QgcHJvYmVk IChkaXNhYmxlZCkKdW5rbm93bjogbm90IHByb2JlZCAoZGlzYWJsZWQpCnNpbzA6IGNvbmZpZ3Vy ZWQgaXJxIDQgbm90IGluIGJpdG1hcCBvZiBwcm9iZWQgaXJxcyAwCnNpbzA6IHBvcnQgbWF5IG5v dCBiZSBlbmFibGVkCnNpbzA6IGlycSBtYXBzOiAwIDAgMCAwCnNpbzA6IDwxNjU1MEEtY29tcGF0 aWJsZSBDT00gcG9ydD4gcG9ydCAweDNmOC0weDNmZiBpcnEgNCBmbGFncyAweDEwIG9uIGFjcGkw CnNpbzA6IHR5cGUgMTY1NTBBCnVua25vd246IG5vdCBwcm9iZWQgKGRpc2FibGVkKQp1bmtub3du OiBub3QgcHJvYmVkIChkaXNhYmxlZCkKdW5rbm93bjogbm90IHByb2JlZCAoZGlzYWJsZWQpCnVu a25vd246IG5vdCBwcm9iZWQgKGRpc2FibGVkKQphdGE6IGF0YTAgYWxyZWFkeSBleGlzdHM7IHNr aXBwaW5nIGl0CmF0YTogYXRhMSBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKYXRrYmRjOiBh dGtiZGMwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdApmZGM6IGZkYzAgYWxyZWFkeSBleGlz dHM7IHNraXBwaW5nIGl0CnNpbzogc2lvMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKVHJ5 aW5nIFJlYWRfUG9ydCBhdCAyMDMKVHJ5aW5nIFJlYWRfUG9ydCBhdCAyNDMKVHJ5aW5nIFJlYWRf UG9ydCBhdCAyODMKVHJ5aW5nIFJlYWRfUG9ydCBhdCAyYzMKVHJ5aW5nIFJlYWRfUG9ydCBhdCAz MDMKVHJ5aW5nIFJlYWRfUG9ydCBhdCAzNDMKVHJ5aW5nIFJlYWRfUG9ydCBhdCAzODMKVHJ5aW5n IFJlYWRfUG9ydCBhdCAzYzMKZXhfaXNhX2lkZW50aWZ5KCkKdW5rbm93bjogc3RhdHVzIHJlZyB0 ZXN0IGZhaWxlZCBmZgp1bmtub3duOiBzdGF0dXMgcmVnIHRlc3QgZmFpbGVkIGZmCnVua25vd246 IHN0YXR1cyByZWcgdGVzdCBmYWlsZWQgZmYKdW5rbm93bjogc3RhdHVzIHJlZyB0ZXN0IGZhaWxl ZCBmZgp1bmtub3duOiBzdGF0dXMgcmVnIHRlc3QgZmFpbGVkIGZmCnVua25vd246IHN0YXR1cyBy ZWcgdGVzdCBmYWlsZWQgZmYKYWhjX2lzYV9wcm9iZSAxNDogaW9wb3J0IDB4ZWMwMCBhbGxvYyBm YWlsZWQKc2M6IHNjMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKdmdhOiB2Z2EwIGFscmVh ZHkgZXhpc3RzOyBza2lwcGluZyBpdAppc2FfcHJvYmVfY2hpbGRyZW46IGRpc2FibGluZyBQblAg ZGV2aWNlcwppc2FfcHJvYmVfY2hpbGRyZW46IHByb2Jpbmcgbm9uLVBuUCBkZXZpY2VzCm9ybTA6 IDxJU0EgT3B0aW9uIFJPTXM+IGF0IGlvbWVtIDB4Y2QwMDAtMHhkNGZmZiwweGMwMDAwLTB4Y2Nm ZmYgb24gaXNhMApwbXRpbWVyMCBvbiBpc2EwCmFkdjA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQph aGEwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKYWljMDogbm90IHByb2JlZCAoZGlzYWJsZWQpCmJ0 MDogbm90IHByb2JlZCAoZGlzYWJsZWQpCmNzMDogbm90IHByb2JlZCAoZGlzYWJsZWQpCmVkMDog bm90IHByb2JlZCAoZGlzYWJsZWQpCmZlMDogbm90IHByb2JlZCAoZGlzYWJsZWQpCmllMDogbm90 IHByb2JlZCAoZGlzYWJsZWQpCmxuYzA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQpwY2ljMCBmYWls ZWQgdG8gcHJvYmUgYXQgcG9ydCAweDNlMCBpb21lbSAweGQwMDAwIG9uIGlzYTAKcGNpYzE6IG5v dCBwcm9iZWQgKGRpc2FibGVkKQpwcGMwOiBwYXJhbGxlbCBwb3J0IG5vdCBmb3VuZC4KcHBjMDog PFBhcmFsbGVsIHBvcnQ+IGZhaWxlZCB0byBwcm9iZSBhdCBpcnEgNyBvbiBpc2EwCnNjMDogPFN5 c3RlbSBjb25zb2xlPiBhdCBmbGFncyAweDEwMCBvbiBpc2EwCnNjMDogVkdBIDwxNiB2aXJ0dWFs IGNvbnNvbGVzLCBmbGFncz0weDMwMD4Kc2MwOiBmYjAsIGtiZDAsIHRlcm1pbmFsIGVtdWxhdG9y OiBzYyAoc3lzY29ucyB0ZXJtaW5hbCkKc2lvMTogY29uZmlndXJlZCBpcnEgMyBub3QgaW4gYml0 bWFwIG9mIHByb2JlZCBpcnFzIDAKc2lvMTogcG9ydCBtYXkgbm90IGJlIGVuYWJsZWQKc2lvMTog aXJxIG1hcHM6IDAgMCAwIDAKc2lvMTogcHJvYmUgZmFpbGVkIHRlc3Qocyk6IDAgMSAyIDQgNiA3 IDkKc2lvMSBmYWlsZWQgdG8gcHJvYmUgYXQgcG9ydCAweDJmOC0weDJmZiBpcnEgMyBvbiBpc2Ew CnNpbzI6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQpzaW8zOiBub3QgcHJvYmVkIChkaXNhYmxlZCkK c24wOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKdmdhMDogPEdlbmVyaWMgSVNBIFZHQT4gYXQgcG9y dCAweDNjMC0weDNkZiBpb21lbSAweGEwMDAwLTB4YmZmZmYgb24gaXNhMApmYjA6IHZnYTAsIHZn YSwgdHlwZTpWR0EgKDUpLCBmbGFnczoweDcwMDdmCmZiMDogcG9ydDoweDNjMC0weDNkZiwgY3J0 YzoweDNkNCwgbWVtOjB4YTAwMDAgMHgyMDAwMApmYjA6IGluaXQgbW9kZToyNCwgYmlvcyBtb2Rl OjMsIGN1cnJlbnQgbW9kZToyNApmYjA6IHdpbmRvdzoweGMwMGI4MDAwIHNpemU6MzJrIGdyYW46 MzJrLCBidWY6MCBzaXplOjMyawpWR0EgcGFyYW1ldGVycyB1cG9uIHBvd2VyLXVwCjUwIDE4IDEw IDAwIDAwIDAwIDAzIDAwIDAyIDY3IDVmIDRmIDUwIDgyIDU1IDgxIApiZiAxZiAwMCA0ZiAwZCAw ZSAwMCAwMCAwNyA4MCA5YyA4ZSA4ZiAyOCAxZiA5NiAKYjkgYTMgZmYgMDAgMDEgMDIgMDMgMDQg MDUgMTQgMDcgMzggMzkgM2EgM2IgM2MgCjNkIDNlIDNmIDBjIDAwIDBmIDA4IDAwIDAwIDAwIDAw IDAwIDEwIDBlIDAwIGZmIApWR0EgcGFyYW1ldGVycyBpbiBCSU9TIGZvciBtb2RlIDI0CjUwIDE4 IDEwIDAwIDEwIDAwIDAzIDAwIDAyIDY3IDVmIDRmIDUwIDgyIDU1IDgxIApiZiAxZiAwMCA0ZiAw ZCAwZSAwMCAwMCAwMCAwMCA5YyA4ZSA4ZiAyOCAxZiA5NiAKYjkgYTMgZmYgMDAgMDEgMDIgMDMg MDQgMDUgMTQgMDcgMzggMzkgM2EgM2IgM2MgCjNkIDNlIDNmIDBjIDAwIDBmIDA4IDAwIDAwIDAw IDAwIDAwIDEwIDBlIDAwIGZmIApFR0EvVkdBIHBhcmFtZXRlcnMgdG8gYmUgdXNlZCBmb3IgbW9k ZSAyNAo1MCAxOCAxMCAwMCAxMCAwMCAwMyAwMCAwMiA2NyA1ZiA0ZiA1MCA4MiA1NSA4MSAKYmYg MWYgMDAgNGYgMGQgMGUgMDAgMDAgMDAgMDAgOWMgOGUgOGYgMjggMWYgOTYgCmI5IGEzIGZmIDAw IDAxIDAyIDAzIDA0IDA1IDE0IDA3IDM4IDM5IDNhIDNiIDNjIAozZCAzZSAzZiAwYyAwMCAwZiAw OCAwMCAwMCAwMCAwMCAwMCAxMCAwZSAwMCBmZiAKdnQwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkK aXNhX3Byb2JlX2NoaWxkcmVuOiBwcm9iaW5nIFBuUCBkZXZpY2VzCnVtczA6IExvZ2l0ZWNoIFVT Qi1QUy8yIE9wdGljYWwgTW91c2UsIHJldiAyLjAwLzExLjEwLCBhZGRyIDIsIGljbGFzcyAzLzEK dW1zMDogMyBidXR0b25zIGFuZCBaIGRpci4KRGV2aWNlIGNvbmZpZ3VyYXRpb24gZmluaXNoZWQu CnByb2NmcyByZWdpc3RlcmVkClRpbWVjb3VudGVyICJUU0MiIGZyZXF1ZW5jeSAzMDAwODYwMjg3 IEh6IHF1YWxpdHkgODAwClRpbWVjb3VudGVycyB0aWNrIGV2ZXJ5IDEwLjAwMCBtc2VjCmxvMDog YnBmIGF0dGFjaGVkCmF0YTAtbWFzdGVyOiBwaW89MHgwYyB3ZG1hPTB4MjIgdWRtYT0weDQyIGNh YmxlPTQwcGluCmF0YTAtbWFzdGVyOiBzZXR0aW5nIFBJTzQgb24gU2lTIDk2NCBjaGlwCmFjZDA6 IDxUT1NISUJBIENEL0RWRFcgU0QtUjUzNzIvVFU1NT4gRFZEUiBkcml2ZSBhdCBhdGEwIGFzIG1h c3RlcgphY2QwOiByZWFkIDgyNjhLQi9zICg4MjY4S0Ivcykgd3JpdGUgODI2OEtCL3MgKDgyNjhL Qi9zKSwgMjA0OEtCIGJ1ZmZlciwgUElPNAphY2QwOiBSZWFkczogQ0RSLCBDRFJXLCBDRERBIHN0 cmVhbSwgRFZEUk9NLCBEVkRSLCBEVkRSQU0sIHBhY2tldAphY2QwOiBXcml0ZXM6IENEUiwgQ0RS VywgRFZEUiwgdGVzdCB3cml0ZSwgYnVybnByb29mCmFjZDA6IEF1ZGlvOiBwbGF5LCAxNiB2b2x1 bWUgbGV2ZWxzCmFjZDA6IE1lY2hhbmlzbTogZWplY3RhYmxlIHRyYXksIHVubG9ja2VkCmFjZDA6 IE1lZGl1bTogbm8vYmxhbmsgZGlzYwphdGEyLW1hc3RlcjogcGlvPTB4MGMgd2RtYT0weDIyIHVk bWE9MHg0NiBjYWJsZT00MHBpbgphZDQ6IDxTVDM4MDgxN0FTLzMuNDI+IEFUQS02IGRpc2sgYXQg YXRhMi1tYXN0ZXIKYWQ0OiA3NjMxOU1CICgxNTYzMDE0ODggc2VjdG9ycyksIDE1NTA2MSBDLCAx NiBILCA2MyBTLCA1MTIgQgphZDQ6IDE2IHNlY3MvaW50LCAxIGRlcHRoIHF1ZXVlLCBTQVRBMTUw CmFyOiBGcmVlQlNEIGNoZWNrMSBmYWlsZWQKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMSAoSVNB IElSUSAxKSB0byBjbHVzdGVyIDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gNCAoSVNBIElSUSA0 KSB0byBjbHVzdGVyIDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gNiAoSVNBIElSUSA2KSB0byBj bHVzdGVyIDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gOCAoSVNBIElSUSA4KSB0byBjbHVzdGVy IDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gOSAoSVNBIElSUSA5KSB0byBjbHVzdGVyIDAKaW9h cGljMDogcm91dGluZyBpbnRwaW4gMTMgKElTQSBJUlEgMTMpIHRvIGNsdXN0ZXIgMAppb2FwaWMw OiByb3V0aW5nIGludHBpbiAxNCAoSVNBIElSUSAxNCkgdG8gY2x1c3RlciAwCmlvYXBpYzA6IHJv dXRpbmcgaW50cGluIDE1IChJU0EgSVJRIDE1KSB0byBjbHVzdGVyIDAKaW9hcGljMDogcm91dGlu ZyBpbnRwaW4gMTcgKFBDSSBJUlEgMTcpIHRvIGNsdXN0ZXIgMAppb2FwaWMwOiByb3V0aW5nIGlu dHBpbiAxOSAoUENJIElSUSAxOSkgdG8gY2x1c3RlciAwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGlu IDIwIChQQ0kgSVJRIDIwKSB0byBjbHVzdGVyIDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMjEg KFBDSSBJUlEgMjEpIHRvIGNsdXN0ZXIgMAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAyMiAoUENJ IElSUSAyMikgdG8gY2x1c3RlciAwCkdFT006IG5ldyBkaXNrIGFkNApbMF0gZjowMCB0eXA6NyBz KENIUyk6MC8xLzEgZShDSFMpOjEwMjMvMjU0LzYzIHM6NjMgbDoyMDk2NDc2MgpbMV0gZjowMCB0 eXA6NyBzKENIUyk6MTAyMy8yNTUvNjMgZShDSFMpOjEwMjMvMjU0LzYzIHM6MjA5NjQ4MjUgbDoy MDk2NDgyNQpbMl0gZjo4MCB0eXA6MTY1IHMoQ0hTKToxMDIzLzI1NS82MyBlKENIUyk6MTAyMy8y NTQvNjMgczo0MTkyOTY1MCBsOjQwOTY1NzUwClszXSBmOjAwIHR5cDo1IHMoQ0hTKToxMDIzLzI1 NS82MyBlKENIUyk6MTAyMy8yNTQvNjMgczo4Mjg5NTQwMCBsOjczNDAwOTg1CkdFT006IENvbmZp Z3VyZSBhZDRzMSwgc3RhcnQgMzIyNTYgbGVuZ3RoIDEwNzMzOTU4MTQ0IGVuZCAxMDczMzk5MDM5 OQpHRU9NOiBDb25maWd1cmUgYWQ0czIsIHN0YXJ0IDEwNzMzOTkwNDAwIGxlbmd0aCAxMDczMzk5 MDQwMCBlbmQgMjE0Njc5ODA3OTkKR0VPTTogQ29uZmlndXJlIGFkNHMzLCBzdGFydCAyMTQ2Nzk4 MDgwMCBsZW5ndGggMjA5NzQ0NjQwMDAgZW5kIDQyNDQyNDQ0Nzk5CkdFT006IENvbmZpZ3VyZSBh ZDRzNCwgc3RhcnQgNDI0NDI0NDQ4MDAgbGVuZ3RoIDM3NTgxMzA0MzIwIGVuZCA4MDAyMzc0OTEx OQpbMF0gZjo2MyB0eXA6MTE0IHMoQ0hTKTozNjgvMTExLzQ1IGUoQ0hTKTozNzEvMTAxLzUxIHM6 MjE4MTI5NTA5IGw6MTcwMTk5MDQxMApbMV0gZjo3MyB0eXA6MTE2IHMoQ0hTKTo2Ny8xMTUvMzIg ZShDSFMpOjI5OS8xMTQvNDQgczo3MjkwNTAxNzcgbDo1NDM5NzQ3MjQKWzJdIGY6NzQgdHlwOjEw MSBzKENIUyk6MTE0LzExMS8zMiBlKENIUyk6MzUzLzExNS81MiBzOjE2ODY1MzkzOCBsOjAKWzNd IGY6MDAgdHlwOjAgcyhDSFMpOjAvMC8wIGUoQ0hTKTowLzAvMCBzOi0xNjAyMDI3NTIwIGw6NTE2 MzUKWzBdIGY6NjMgdHlwOjExNCBzKENIUyk6MzY4LzExMS80NSBlKENIUyk6MzcxLzEwMS81MSBz OjIxODEyOTUwOSBsOjE3MDE5OTA0MTAKWzFdIGY6NzMgdHlwOjExNiBzKENIUyk6NjcvMTE1LzMy IGUoQ0hTKToyOTkvMTE0LzQ0IHM6NzI5MDUwMTc3IGw6NTQzOTc0NzI0ClsyXSBmOjc0IHR5cDox MDEgcyhDSFMpOjExNC8xMTEvMzIgZShDSFMpOjM1My8xMTUvNTIgczoxNjg2NTM5MzggbDowClsz XSBmOjAwIHR5cDowIHMoQ0hTKTowLzAvMCBlKENIUyk6MC8wLzAgczotMTYwMjAyNzUyMCBsOjUx NjM1ClswXSBmOjAwIHR5cDowIHMoQ0hTKTowLzAvMCBlKENIUyk6MC8wLzAgczowIGw6MApbMV0g ZjowMCB0eXA6MCBzKENIUyk6MC8wLzAgZShDSFMpOjAvMC8wIHM6MCBsOjAKWzJdIGY6MDAgdHlw OjAgcyhDSFMpOjAvMC8wIGUoQ0hTKTowLzAvMCBzOjAgbDowClszXSBmOjgwIHR5cDoxNjUgcyhD SFMpOjAvMC8xIGUoQ0hTKToxMDIzLzI1NC82MyBzOjAgbDo1MDAwMApHRU9NOiBDb25maWd1cmUg YWQ0czNhLCBzdGFydCAwIGxlbmd0aCAyNjg0MzU0NTYgZW5kIDI2ODQzNTQ1NQpHRU9NOiBDb25m aWd1cmUgYWQ0czNiLCBzdGFydCAyNjg0MzU0NTYgbGVuZ3RoIDIxMjA1NTY1NDQgZW5kIDIzODg5 OTE5OTkKR0VPTTogQ29uZmlndXJlIGFkNHMzYywgc3RhcnQgMCBsZW5ndGggMjA5NzQ0NjQwMDAg ZW5kIDIwOTc0NDYzOTk5CkdFT006IENvbmZpZ3VyZSBhZDRzM2QsIHN0YXJ0IDIzODg5OTIwMDAg bGVuZ3RoIDI2ODQzNTQ1NiBlbmQgMjY1NzQyNzQ1NQpHRU9NOiBDb25maWd1cmUgYWQ0czNlLCBz dGFydCAyNjU3NDI3NDU2IGxlbmd0aCAyNjg0MzU0NTYgZW5kIDI5MjU4NjI5MTEKR0VPTTogQ29u ZmlndXJlIGFkNHMzZiwgc3RhcnQgMjkyNTg2MjkxMiBsZW5ndGggMTA3Mzc0MTgyNCBlbmQgMzk5 OTYwNDczNQpHRU9NOiBDb25maWd1cmUgYWQ0czNnLCBzdGFydCAzOTk5NjA0NzM2IGxlbmd0aCAx Njk3NDg1OTI2NCBlbmQgMjA5NzQ0NjM5OTkKTUJSRVhUIFNsaWNlIDUgb24gYWQ0czQ6ClswXSBm OjAwIHR5cDo3IHMoQ0hTKToxMDIzLzEvMSBlKENIUyk6MTAyMy8yNTQvNjMgczo2MyBsOjUxMTk5 MDkyClsxXSBmOjAwIHR5cDowIHMoQ0hTKTowLzAvMCBlKENIUyk6MC8wLzAgczowIGw6MApHRU9N OiBDb25maWd1cmUgYWQ0czUsIHN0YXJ0IDMyMjU2IGxlbmd0aCAyNjIxMzkzNTEwNCBlbmQgMjYy MTM5NjczNTkKWzBdIGY6MDAgdHlwOjcgcyhDSFMpOjEwMjMvMS8xIGUoQ0hTKToxMDIzLzI1NC82 MyBzOjYzIGw6NTExOTkwOTIKWzFdIGY6MDAgdHlwOjAgcyhDSFMpOjAvMC8wIGUoQ0hTKTowLzAv MCBzOjAgbDowClsyXSBmOjAwIHR5cDowIHMoQ0hTKTowLzAvMCBlKENIUyk6MC8wLzAgczowIGw6 MApbM10gZjowMCB0eXA6MCBzKENIUyk6MC8wLzAgZShDSFMpOjAvMC8wIHM6MCBsOjAKR0VPTTog Q29uZmlndXJlIGFkNHM0czEsIHN0YXJ0IDMyMjU2IGxlbmd0aCAyNjIxMzkzNTEwNCBlbmQgMjYy MTM5NjczNTkKWzBdIGY6MDAgdHlwOjAgcyhDSFMpOjAvMC8wIGUoQ0hTKTowLzAvMCBzOjAgbDow ClsxXSBmOjAwIHR5cDowIHMoQ0hTKTowLzAvMCBlKENIUyk6MC8wLzAgczowIGw6MApbMl0gZjow MCB0eXA6MCBzKENIUyk6MC8wLzAgZShDSFMpOjAvMC8wIHM6MCBsOjAKWzNdIGY6ODAgdHlwOjE2 NSBzKENIUyk6MC8wLzEgZShDSFMpOjEwMjMvMjU0LzYzIHM6MCBsOjUwMDAwClswXSBmOjAwIHR5 cDowIHMoQ0hTKTowLzAvMCBlKENIUyk6MC8wLzAgczowIGw6MApbMV0gZjowMCB0eXA6MCBzKENI Uyk6MC8wLzAgZShDSFMpOjAvMC8wIHM6MCBsOjAKWzJdIGY6MDAgdHlwOjAgcyhDSFMpOjAvMC8w IGUoQ0hTKTowLzAvMCBzOjAgbDowClszXSBmOjgwIHR5cDoxNjUgcyhDSFMpOjAvMC8xIGUoQ0hT KToxMDIzLzI1NC82MyBzOjAgbDo1MDAwMApbMF0gZjo2MyB0eXA6MTE0IHMoQ0hTKTozNjgvMTEx LzQ1IGUoQ0hTKTozNzEvMTAxLzUxIHM6MjE4MTI5NTA5IGw6MTcwMTk5MDQxMApbMV0gZjo3MyB0 eXA6MTE2IHMoQ0hTKTo2Ny8xMTUvMzIgZShDSFMpOjI5OS8xMTQvNDQgczo3MjkwNTAxNzcgbDo1 NDM5NzQ3MjQKWzJdIGY6NzQgdHlwOjEwMSBzKENIUyk6MTE0LzExMS8zMiBlKENIUyk6MzUzLzEx NS81MiBzOjE2ODY1MzkzOCBsOjAKWzNdIGY6MDAgdHlwOjAgcyhDSFMpOjAvMC8wIGUoQ0hTKTow LzAvMCBzOi0xNjAyMDI3NTIwIGw6NTE2MzUKWzBdIGY6NjMgdHlwOjExNCBzKENIUyk6MzY4LzEx MS80NSBlKENIUyk6MzcxLzEwMS81MSBzOjIxODEyOTUwOSBsOjE3MDE5OTA0MTAKWzFdIGY6NzMg dHlwOjExNiBzKENIUyk6NjcvMTE1LzMyIGUoQ0hTKToyOTkvMTE0LzQ0IHM6NzI5MDUwMTc3IGw6 NTQzOTc0NzI0ClsyXSBmOjc0IHR5cDoxMDEgcyhDSFMpOjExNC8xMTEvMzIgZShDSFMpOjM1My8x MTUvNTIgczoxNjg2NTM5MzggbDowClszXSBmOjAwIHR5cDowIHMoQ0hTKTowLzAvMCBlKENIUyk6 MC8wLzAgczotMTYwMjAyNzUyMCBsOjUxNjM1Ck1vdW50aW5nIHJvb3QgZnJvbSB1ZnM6L2Rldi9h ZDRzM2EKc3RhcnRfaW5pdDogdHJ5aW5nIC9zYmluL2luaXQKTGludXggRUxGIGV4ZWMgaGFuZGxl ciBpbnN0YWxsZWQK ------=_Part_13991_8873011.1125220793590-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 28 09:31:19 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 0A28016A41F; Sun, 28 Aug 2005 09:31:19 +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 9162B43D45; Sun, 28 Aug 2005 09:31:18 +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.3/8.13.3) with ESMTP id j7S9VH9s079189; Sun, 28 Aug 2005 05:31:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j7S9VHIS088596; Sun, 28 Aug 2005 05:31:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 573FD7304D; Sun, 28 Aug 2005 05:31:17 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050828093117.573FD7304D@freebsd-current.sentex.ca> Date: Sun, 28 Aug 2005 05:31:17 -0400 (EDT) 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: Sun, 28 Aug 2005 09:31:19 -0000 TB --- 2005-08-28 07:21:34 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-08-28 07:21:34 - starting HEAD tinderbox run for amd64/amd64 TB --- 2005-08-28 07:21:34 - cleaning the object tree TB --- 2005-08-28 07:22:20 - checking out the source tree TB --- 2005-08-28 07:22:20 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2005-08-28 07:22:20 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-08-28 07:35:21 - building world (CFLAGS=-O2 -pipe) TB --- 2005-08-28 07:35:21 - cd /src TB --- 2005-08-28 07:35:21 - /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-08-28 09:22:05 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-08-28 09:22:05 - cd /src TB --- 2005-08-28 09:22:05 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Aug 28 09:22:06 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 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -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 /src/sys/amd64/linux32/linux32_machdep.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -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 /src/sys/amd64/linux32/linux32_sysent.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -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 /src/sys/amd64/linux32/linux32_sysvec.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -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 /src/sys/compat/linux/linux_file.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -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 /src/sys/compat/linux/linux_getcwd.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -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 /src/sys/compat/linux/linux_ioctl.c /src/sys/compat/linux/linux_ioctl.c: In function `linux_ifconf': /src/sys/compat/linux/linux_ioctl.c:2217: warning: passing arg 1 of `memcpy' makes pointer from integer without a cast *** Error code 1 Stop in /obj/amd64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-08-28 09:31:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-08-28 09:31:16 - ERROR: failed to build generic kernel TB --- 2005-08-28 09:31:16 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sun Aug 28 10:44: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 D15E616A420 for ; Sun, 28 Aug 2005 10:44:22 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 302FE43D46 for ; Sun, 28 Aug 2005 10:44:21 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from Andro-Beta.Leidinger.net (p54A5C881.dip.t-dialin.net [84.165.200.129]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.1/8.13.1) with ESMTP id j7SAZmFt092786; Sun, 28 Aug 2005 12:36:05 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) by Andro-Beta.Leidinger.net (8.13.3/8.13.3) with ESMTP id j7SAhL5H052025; Sun, 28 Aug 2005 12:43:22 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Sun, 28 Aug 2005 12:43:21 +0200 From: Alexander Leidinger To: freebsd-current@freebsd.org, Stefan Bethke Message-ID: <20050828124321.43365136@Magellan.Leidinger.net> In-Reply-To: <7A0B19EC-2F90-495F-B242-7FB701C32908@lassitu.de> References: <7A0B19EC-2F90-495F-B242-7FB701C32908@lassitu.de> X-Mailer: Sylpheed-Claws 1.9.13 (GTK+ 2.6.9; 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: Subject: Re: Trouble with 6 boot/loader: system resets X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2005 10:44:23 -0000 On Sat, 27 Aug 2005 21:54:20 +0200 Stefan Bethke wrote: > When trying to boot off the CF, boot will load loader. Then the > machine resets. I assume you've rebuild the loader yourself. I also assume you have some additional compile flags in make.conf (e.g. additional ones for CFLAGS or by setting your CPUTYPE). I have this problem too, I have to copy /boot/loader.old to /boot/loader everytime I do a installworld. It's a bad interaction of one of those additional compile flags and the loader source. Bye, Alexander. -- "One world, one web, one program" -- Microsoft promotional ad "Ein Volk, ein Reich, ein Fuehrer" -- Adolf Hitler 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 Aug 28 10:48: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 E68C816A41F for ; Sun, 28 Aug 2005 10:48:25 +0000 (GMT) (envelope-from stb@lassitu.de) Received: from schlepper.zs64.net (schlepper.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 639FC43D49 for ; Sun, 28 Aug 2005 10:48:24 +0000 (GMT) (envelope-from stb@lassitu.de) Received: from [IPv6:::1] (schlepper [212.12.50.230]) by schlepper.zs64.net (8.13.1/8.12.9) with ESMTP id j7SAmJCu008939; Sun, 28 Aug 2005 12:48:19 +0200 (CEST) (envelope-from stb@lassitu.de) In-Reply-To: <20050828124321.43365136@Magellan.Leidinger.net> References: <7A0B19EC-2F90-495F-B242-7FB701C32908@lassitu.de> <20050828124321.43365136@Magellan.Leidinger.net> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Stefan Bethke Date: Sun, 28 Aug 2005 12:48:18 +0200 To: Alexander Leidinger X-Mailer: Apple Mail (2.734) Cc: freebsd-current@freebsd.org Subject: Re: Trouble with 6 boot/loader: system resets X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2005 10:48:26 -0000 Am 28.08.2005 um 12:43 schrieb Alexander Leidinger: > On Sat, 27 Aug 2005 21:54:20 +0200 Stefan Bethke > wrote: > >> When trying to boot off the CF, boot will load loader. Then the >> machine resets. > > I assume you've rebuild the loader yourself. I also assume you have > some additional compile flags in make.conf (e.g. additional ones for > CFLAGS or by setting your CPUTYPE). I have this problem too, I have to > copy /boot/loader.old to /boot/loader everytime I do a installworld. > It's a bad interaction of one of those additional compile flags and > the > loader source. OK, I'll try without CPUTYPE=pentium3. Thanks, Stefan -- Stefan Bethke Fon +49 170 346 0140 From owner-freebsd-current@FreeBSD.ORG Sun Aug 28 11: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 73EA016A41F for ; Sun, 28 Aug 2005 11:25:10 +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 0536943D45 for ; Sun, 28 Aug 2005 11:25:09 +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 B13231FF9AF; Sun, 28 Aug 2005 13:25:07 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id 5759F1FF9AD; Sun, 28 Aug 2005 13:25:05 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id 8FEF8157F3; Sun, 28 Aug 2005 11:25:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id 853C41577D; Sun, 28 Aug 2005 11:25:02 +0000 (UTC) Date: Sun, 28 Aug 2005 11:25:02 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: "M. Warner Losh" In-Reply-To: <20050827.104631.10908351.imp@bsdimp.com> Message-ID: References: <20050826115503.D4B0C4E704@pipa.profix.cz> <20050827.104631.10908351.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Cc: freebsd-current@freebsd.org Subject: Re: LOR route vr0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2005 11:25:10 -0000 On Sat, 27 Aug 2005, M. Warner Losh wrote: for the archives... > ock order reversal > 1st 0xc17490e4 rtentry (rtentry) @ sys/netinet/if_ether.c:445 > 2nd 0xc15c94b0 rl1 (network driver) @ sys/pci/if_rl.c:1451 LOR http://sources.zabbadoz.net/freebsd/lor.html#144 > and am seeing the following in my newly locked ed driver: > > lock order reversal > 1st 0xc1cb3588 rtentry (rtentry) @ net/route.c:1269 > 2nd 0xc1fd3420 ed1 (network driver) @ /dell/imp/p4/newcard/src/sys/modules/ed/../../dev/ed/if_ed.c:697 I added this one two though this LOR may not (yet) be seen in the wild. LOR http://sources.zabbadoz.net/freebsd/lor.html#145 -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-current@FreeBSD.ORG Sat Aug 27 16:46: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 324CB16A42B; Sat, 27 Aug 2005 16:46:53 +0000 (GMT) (envelope-from jerrymc@clunix.cl.msu.edu) Received: from clunix.cl.msu.edu (clunix.cl.msu.edu [35.9.2.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id C778B43D45; Sat, 27 Aug 2005 16:46:52 +0000 (GMT) (envelope-from jerrymc@clunix.cl.msu.edu) Received: from clunix.cl.msu.edu (localhost [127.0.0.1]) by clunix.cl.msu.edu (8.12.10+Sun/8.12.2) with ESMTP id j7RGkjBn000686; Sat, 27 Aug 2005 12:46:45 -0400 (EDT) Received: (from jerrymc@localhost) by clunix.cl.msu.edu (8.12.10+Sun/8.12.2/Submit) id j7RGkiJe000685; Sat, 27 Aug 2005 12:46:44 -0400 (EDT) From: Jerry McAllister Message-Id: <200508271646.j7RGkiJe000685@clunix.cl.msu.edu> To: Emanuel.strobl@gmx.net (Emanuel Strobl) Date: Sat, 27 Aug 2005 12:46:44 -0400 (EDT) In-Reply-To: <200508271231.34470@harrymail> X-Mailer: ELM [version 2.5 PL7] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 28 Aug 2005 11:28:12 +0000 Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org Subject: Re: cpio and tar are loosing flags (and a panic message without X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Aug 2005 16:46:53 -0000 > > Am Samstag, 27. August 2005 06:58 CEST schrieb Matthew Dillon: > > :Thank you, I know cpdup but I haven't known that it's flags aware! > > :Unfortunately I need to write to a raw device, I guess there's no way > > : for=3D20 cpdup without a filesystem... > > : > > :I guess cpio and tar really should take care about flags. Am I wrong? > > : > > :Thanks, > > : > > :=3D2DHarry > > > > cpio won't do it, tar won't do it, dump only does whole partitions, > > cpdup is not an archiver. Hmm. > > > > I can think of two possibilities. First, use a MFS or VN block > > device, create a filesystem, and use cpdup, then gzip the file > > representing the backing store. Since the extra space in the filesystem > > will contain zeros (you should make sure it does, that is), it should > > compress pretty well. Second, use cpio and then do a separate 'find' or > > 'ls' or something to get the chflags info and write a script that > > restores the flags after unpacking. > > > > They are both pretty narley solutions. > > > > Hmm.. wait a sec... I just thought up of another possibility... take > > the tar or cpio source code and modify it to also save and restore > > the chflags data. It won't be a 'standard' utility any more, but it > > WILL work for your needs. Call it by another name so there's no > > confusion. That might be your best bet, actually. > > Right, and you can be sure, I had that done already if I spoke c. > But if I understand you correctly, it is intended that cpio doesn't hanlde= > =20 > file flags? And (bsb)tar too? Then what are flags good for if no=20 > application makes use of them? Many utilities make use of the flags. As for preserving flags when transferring files, dump/restore do that as does mv. ////jerry > =46or now I think I have to be happy with my script solution, at least it=20 > works. > > Thanks, > > =2Dharry > > > > > -Matt > > --nextPart1588043.I67yfi4mi7 > Content-Type: application/pgp-signature > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (FreeBSD) > > iD8DBQBDEEEGBylq0S4AzzwRAk9jAJ9BtF55VtpB39Ac3Z0fTkzq9Nv8HwCeKxZY > tIuf0zf92rpNIyaZYgUlV4A= > =QCBs > -----END PGP SIGNATURE----- > > --nextPart1588043.I67yfi4mi7-- > From owner-freebsd-current@FreeBSD.ORG Sun Aug 28 14:03: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 4BE6A16A41F for ; Sun, 28 Aug 2005 14:03:40 +0000 (GMT) (envelope-from loader@freebsdmall.com) Received: from mail.freebsdmall.com (ns1.freebsdmall.com [69.50.233.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id E014443D48 for ; Sun, 28 Aug 2005 14:03:39 +0000 (GMT) (envelope-from loader@freebsdmall.com) Received: by mail.freebsdmall.com (Postfix, from userid 2136) id C2CB71CE5B; Sun, 28 Aug 2005 07:03:39 -0700 (PDT) X-Mailer: emacs 22.0.50.1 (via feedmail 8 I) To: freebsd-current@freebsd.org References: From: loader X-GPG-Public-Key: http://www.freebsdmall.com/~loader/loader.asc X-GPG-Key-ID: 1024D/0277E075 X-GPG-Key-Fingerprint: F8A0 A354 5D97 B175 7FC9 15DC 0771 07CF 0277 E075 Date: Sun, 28 Aug 2005 22:03:49 +0000 In-Reply-To: (loader@freebsdmall.com's message of "Sun, 28 Aug 2005 15:35:03 +0000") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: loader@freebsdmall.com Subject: Re: Is it possible to setup a WPA ap with D-Link DWL-G520? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2005 14:03:40 -0000 Please ignore my previous email, it's working now. Regards, loader loader writes: > http://www.dlink.com/products/?pid=12 > ath0@pci2:2:0: class=0x020000 card=0x3a131186 chip=0x0013168c rev=0x01 hdr=0x00 > vendor = 'Atheros Communications Inc.' > device = 'AR5212, AR5213 802.11a/b/g Wireless Adapter' > class = network > subclass = ethernet > > If this adapter could work as a access point with WPA, > could someone give me some hints about the settings? > If it can't work, could you recommand another PCI adapter? > Thanks in advance. > > Regards, > loader > _______________________________________________ > 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 Sun Aug 28 15:01: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 3A8C816A41F for ; Sun, 28 Aug 2005 15:01:56 +0000 (GMT) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 063DF43D45 for ; Sun, 28 Aug 2005 15:01:55 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtp (Exim 4.51 (FreeBSD)) id 1E9OfT-000PBn-Ju for freebsd-current@freebsd.org; Sun, 28 Aug 2005 15:01:55 +0000 Received: from [127.0.0.1] (helo=roam.psg.com.psg.com) by roam.psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1E9OfR-000LZk-4r for freebsd-current@freebsd.org; Sun, 28 Aug 2005 05:01:53 -1000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17169.53728.733783.412819@roam.psg.com> Date: Sun, 28 Aug 2005 05:01:52 -1000 To: FreeBSD Current Subject: ugly/unreadable log entry X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2005 15:01:56 -0000 i read my logs daily. new one. in the midst of the usual daily garbage, i got a bunch of ugliness sshd[31126]: Did not receive identification string from 205.234.132.21 sshd[31127]: Did not receive identification string from 205.234.132.21 sshd[31130]: Did not receive identification string from 205.234.132.21 kernel: <<111>d1ro1p 8se>A kernel: s kernel: s, 1 kernel: 2<:24:1171 1p>stg kernel: oen kernel: s0t kernel: d kernel: rssa kernel: r:i kernel: om kernel: /sa kernel: net kernel: s<.all1o1w1>,s kernel: sshd[43443]: fatal: Read from socket failed: Connection reset by peer sshd[44138]: fatal: Read from socket failed: Connection reset by peer inetd[44950]: warning: /etc/hosts.allow, line 28: host name/name mismatch: gw.ipoteka-sakha.ru != ns.ipoteka-sakha.ru inetd[44969]: warning: /etc/hosts.allow, line 28: host name/name mismatch: gw.ipoteka-sakha.ru != ns.ipoteka-sakha.ru any clues? should i worry? randy From owner-freebsd-current@FreeBSD.ORG Sun Aug 28 15:03: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 B491316A41F for ; Sun, 28 Aug 2005 15:03:23 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from smtp100.rog.mail.re2.yahoo.com (smtp100.rog.mail.re2.yahoo.com [206.190.36.78]) by mx1.FreeBSD.org (Postfix) with SMTP id 1EC9743D45 for ; Sun, 28 Aug 2005 15:03:22 +0000 (GMT) (envelope-from mikej@rogers.com) Received: (qmail 66033 invoked from network); 28 Aug 2005 15:03:22 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:Message-ID:In-Reply-To:References:Date:Subject:From:To:Cc:User-Agent:MIME-Version:Content-Type:Content-Transfer-Encoding; b=DdMN+LnugJYdxfbJS+eq+mEW3zRphnmWzNb1/YvsWdu6Uat1JnwA/cYD9lbiOJKvAB9DBT1gOQgs/bNp0478R2ztLpR2S/5kwcaZtPpH0Tuu+ge7OTUUdD/ijFFGM5ifT5MhV2zCMXyZ10TcJ2b9XLiBGWhfJoIGpAfPax22Ydg= ; Received: from unknown (HELO 172.16.0.1) (mikej@70.31.50.81 with login) by smtp100.rog.mail.re2.yahoo.com with SMTP; 28 Aug 2005 15:03:22 -0000 Received: from 172.16.0.199 (SquirrelMail authenticated user mikej) by 172.16.0.1 with HTTP; Sun, 28 Aug 2005 11:03:20 -0400 (EDT) Message-ID: <3930.172.16.0.199.1125241400.squirrel@172.16.0.1> In-Reply-To: <431151C7.2040906@mawer.org> References: <1268.172.16.0.199.1125164980.squirrel@172.16.0.1> <20050827175151.GM26920@bunrab.catwhisker.org> <1668.172.16.0.199.1125191131.squirrel@172.16.0.1> <431151C7.2040906@mawer.org> Date: Sun, 28 Aug 2005 11:03:20 -0400 (EDT) From: "Mike Jakubik" To: "Antony Mawer" User-Agent: SquirrelMail/1.5.1 [CVS] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: Creating own snap isos X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2005 15:03:23 -0000 On Sun, August 28, 2005 1:55 am, Antony Mawer said: > On 28/08/2005 11:05 AM, Mike Jakubik wrote: >> >> ===> share/zoneinfo (install) >> umask 022; cd /usr/src/share/zoneinfo; zic -D -d >> /tmp/chroot/usr/share/zoneinfo -p America/New_York -u root -g wheel -m >> 444 -y /usr/obj/usr/src/share/zoneinfo/yearistype africa antarctica >> asia australasia etcetera europe factory northamerica southamerica >> systemv zic: can't link from >> /tmp/chroot/usr/share/zoneinfo/America/Indianapolis >> to /tmp/chroot/usr/share/zoneinfo/EST: No such file or directory *** >> Error code 1 >> >> >> Stop in /usr/src/share/zoneinfo. >> *** Error code 1 >> > > How much disk space is available on /tmp? 'make release' requires > several gigabytes available in order to succeed (from memory). There is 30GB available. From owner-freebsd-current@FreeBSD.ORG Sun Aug 28 15:23: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 AFEE016A41F for ; Sun, 28 Aug 2005 15:23:07 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DCFA43D45 for ; Sun, 28 Aug 2005 15:23:07 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j7SFLouu030235; Sun, 28 Aug 2005 09:21:59 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 28 Aug 2005 09:22:09 -0600 (MDT) Message-Id: <20050828.092209.77060388.imp@bsdimp.com> To: bzeeb-lists@lists.zabbadoz.net From: "M. Warner Losh" In-Reply-To: References: <20050827.104631.10908351.imp@bsdimp.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.village.org [127.0.0.1]); Sun, 28 Aug 2005 09:21:59 -0600 (MDT) Cc: freebsd-current@freebsd.org Subject: Re: LOR route vr0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2005 15:23:07 -0000 In message: "Bjoern A. Zeeb" writes: : On Sat, 27 Aug 2005, M. Warner Losh wrote: : : for the archives... : : > ock order reversal : > 1st 0xc17490e4 rtentry (rtentry) @ sys/netinet/if_ether.c:445 : > 2nd 0xc15c94b0 rl1 (network driver) @ sys/pci/if_rl.c:1451 : : LOR http://sources.zabbadoz.net/freebsd/lor.html#144 I cut and pasted this one from your LOR site... : > and am seeing the following in my newly locked ed driver: : > : > lock order reversal : > 1st 0xc1cb3588 rtentry (rtentry) @ net/route.c:1269 : > 2nd 0xc1fd3420 ed1 (network driver) @ /dell/imp/p4/newcard/src/sys/modules/ed/../../dev/ed/if_ed.c:697 : : I added this one two though this LOR may not (yet) be seen in : the wild. : : LOR http://sources.zabbadoz.net/freebsd/lor.html#145 heh. I'm expecting to figure out what the real LOR is here and then about 20-25 of the LORs in your list can go away... Warner From owner-freebsd-current@FreeBSD.ORG Sun Aug 28 15:35: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 C95F216A41F for ; Sun, 28 Aug 2005 15:35:10 +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 536A943D45 for ; Sun, 28 Aug 2005 15:35:09 +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 1BB101FF9AF; Sun, 28 Aug 2005 17:35:08 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id B3A4E1FF9AD; Sun, 28 Aug 2005 17:35:05 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id 5A58D1577D; Sun, 28 Aug 2005 15:31:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id 57F6D15329; Sun, 28 Aug 2005 15:31:06 +0000 (UTC) Date: Sun, 28 Aug 2005 15:31:06 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: "M. Warner Losh" In-Reply-To: <20050828.092209.77060388.imp@bsdimp.com> Message-ID: References: <20050827.104631.10908351.imp@bsdimp.com> <20050828.092209.77060388.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Cc: freebsd-current@freebsd.org Subject: Re: LOR route vr0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2005 15:35:10 -0000 On Sun, 28 Aug 2005, M. Warner Losh wrote: > In message: > "Bjoern A. Zeeb" writes: > : On Sat, 27 Aug 2005, M. Warner Losh wrote: > : > : for the archives... > : > : > ock order reversal > : > 1st 0xc17490e4 rtentry (rtentry) @ sys/netinet/if_ether.c:445 > : > 2nd 0xc15c94b0 rl1 (network driver) @ sys/pci/if_rl.c:1451 > : > : LOR http://sources.zabbadoz.net/freebsd/lor.html#144 > > I cut and pasted this one from your LOR site... *gnaa* my grep-o-logic failed. I should really really really split this page... I removed the duplicate. The original one was http://sources.zabbadoz.net/freebsd/lor.html#139 > : > and am seeing the following in my newly locked ed driver: > : > > : > lock order reversal > : > 1st 0xc1cb3588 rtentry (rtentry) @ net/route.c:1269 > : > 2nd 0xc1fd3420 ed1 (network driver) @ /dell/imp/p4/newcard/src/sys/modules/ed/../../dev/ed/if_ed.c:697 > : > : I added this one two though this LOR may not (yet) be seen in > : the wild. > : > : LOR http://sources.zabbadoz.net/freebsd/lor.html#145 > > heh. I'm expecting to figure out what the real LOR is here and then > about 20-25 of the LORs in your list can go away... great. let me know the IDs and the patch that will fix them then. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-current@FreeBSD.ORG Sun Aug 28 17:51: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 C61DD16A55A for ; Sun, 28 Aug 2005 17:50:59 +0000 (GMT) (envelope-from wouter@mx0.businessconnect.nl) Received: from mx0.businessconnect.nl (mx0.businessconnect.nl [213.206.89.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B66843F1C for ; Sun, 28 Aug 2005 17:18:13 +0000 (GMT) (envelope-from wouter@mx0.businessconnect.nl) Received: by mx0.businessconnect.nl (Postfix, from userid 1000) id 41DCA63D7C; Sun, 28 Aug 2005 19:18:11 +0200 (CEST) Date: Sun, 28 Aug 2005 19:18:11 +0200 From: Wouter Prins To: freebsd-current@freebsd.org Message-ID: <20050828171811.GB7529@businessconnect.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DKU6Jbt7q3WqK7+M" Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: Mergemaster issues in 5.4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2005 17:51:24 -0000 --DKU6Jbt7q3WqK7+M Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello everyone, I am having issues with running mergemaster on the following type of system: FreeBSD base.null0.nl 5.4-RELEASE-p6 FreeBSD 5.4-RELEASE-p6 #0: Sun Aug 28 15:10:22 CEST 2005 root@base.null0.nl:/usr/obj/usr/src/sys/BASE i386 1.) I have installed this box from a mini-iso image and cvsup-ed ports and src's. 2.) Created a custom kernel and installed it 3.) build and install of the world When i want to run a mergemaster (although it isnt really needed in this case) i am getting the following error: -- cd /usr/src/etc; install -o root -g wheel -m 644 /var/tmp/temproot/etc/ssh usage: install [-bCcpSsv] [-B suffix] [-f flags] [-g group] [-m mode] [-o owner] file1 file2 install [-bCcpSsv] [-B suffix] [-f flags] [-g group] [-m mode] *** Error code 64 Stop in /usr/src/etc. *** FATAL ERROR: Cannot 'cd' to /usr/src/etc and install files to the tempr= oot environment -- It looks like mergemaster doesnt copy over the sourcefile for some reason, i have tried to check the archives but couldnt find anyone with the same issues. I ignored the above message and stumbled upon the same error when i wanted = to do a 'make distribution DESTDIR=3D/j/1' to create a jail. I have removed the world and sync-ed against another cvsup server but still the same issues. Is there anything i am doing wrong? If more info is needed please ask. Kind regards, Wouter Prins --=20 QOTD: "Everything I am today I owe to people, whom it is now to late to punish." --DKU6Jbt7q3WqK7+M Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDEfHTMWlPMjAfqRIRAtEQAJ44Lj2+5viUEmukTv/Hv+gpbPxMAQCeKaOF H3spa2MGaaTRwPvZ+PBzowc= =gjiy -----END PGP SIGNATURE----- --DKU6Jbt7q3WqK7+M-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 28 17:51: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 7AB8C16A648 for ; Sun, 28 Aug 2005 17:51:09 +0000 (GMT) (envelope-from stb@lassitu.de) Received: from schlepper.zs64.net (schlepper.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2DD243EEC for ; Sun, 28 Aug 2005 16:46:25 +0000 (GMT) (envelope-from stb@lassitu.de) Received: from [IPv6:::1] (schlepper [212.12.50.230]) by schlepper.zs64.net (8.13.3/8.12.9) with ESMTP id j7SGkI0T003892; Sun, 28 Aug 2005 18:46:19 +0200 (CEST) (envelope-from stb@lassitu.de) In-Reply-To: References: <7A0B19EC-2F90-495F-B242-7FB701C32908@lassitu.de> <20050828124321.43365136@Magellan.Leidinger.net> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3923443F-6926-4BB7-8681-40FC68A41B79@lassitu.de> Content-Transfer-Encoding: 7bit From: Stefan Bethke Date: Sun, 28 Aug 2005 18:46:13 +0200 To: Alexander Leidinger X-Mailer: Apple Mail (2.734) Cc: freebsd-current@freebsd.org Subject: Boot off CF card hangs at "Trying to mount root" (was: Trouble with 6 boot/loader: system resets) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2005 17:51:48 -0000 Compiling boot, loader, and kernel without a CPUTYPE setting fixed the boot and loader issues; however, the kernel doesn't seem to be happy with the CF card: ad3: 489MB at ata1-slave PIO4 Trying to mount root from ufs:/dev/ad3s1a Again, I can break into the debugger, but I'm not certain what I should be looking at. I just tried setting the master/slave jumper on the mainboard to "master", but that didn't change anything, either. Any suggestions? Stefan -- Stefan Bethke Fon +49 170 346 0140 From owner-freebsd-current@FreeBSD.ORG Sun Aug 28 18:01: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 7C1B216A41F for ; Sun, 28 Aug 2005 18:01:41 +0000 (GMT) (envelope-from wouter@mx0.businessconnect.nl) Received: from mx0.businessconnect.nl (mx0.businessconnect.nl [213.206.89.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87CE243D73 for ; Sun, 28 Aug 2005 18:01:39 +0000 (GMT) (envelope-from wouter@mx0.businessconnect.nl) Received: by mx0.businessconnect.nl (Postfix, from userid 1000) id B82FD63D7C; Sun, 28 Aug 2005 20:01:36 +0200 (CEST) Date: Sun, 28 Aug 2005 20:01:36 +0200 From: Wouter Prins To: freebsd-current@freebsd.org Message-ID: <20050828180136.GC7529@businessconnect.nl> References: <20050828171811.GB7529@businessconnect.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bKyqfOwhbdpXa4YI" Content-Disposition: inline In-Reply-To: <20050828171811.GB7529@businessconnect.nl> User-Agent: Mutt/1.5.6i Subject: Re: Mergemaster issues in 5.4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2005 18:01:41 -0000 --bKyqfOwhbdpXa4YI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I have fixed this issue by commenting some profiles in /etc/make.conf that i had previously enabled; With NO_PROFILE=3Dtrue and other profiles commented out it works fine. Wouter On Sun, Aug 28, 2005 at 07:18:11PM +0200, Wouter Prins wrote: > Hello everyone, >=20 > I am having issues with running mergemaster on the following type of > system: >=20 > FreeBSD base.null0.nl 5.4-RELEASE-p6 FreeBSD 5.4-RELEASE-p6 #0: Sun Aug > 28 15:10:22 CEST 2005 root@base.null0.nl:/usr/obj/usr/src/sys/BASE > i386 >=20 > 1.) I have installed this box from a mini-iso image and cvsup-ed ports and > src's. > 2.) Created a custom kernel and installed it > 3.) build and install of the world >=20 > When i want to run a mergemaster (although it isnt really needed in this > case) i am getting the following error: >=20 > -- > cd /usr/src/etc; install -o root -g wheel -m 644 /var/tmp/temproot/etc/s= sh > usage: install [-bCcpSsv] [-B suffix] [-f flags] [-g group] [-m mode] > [-o owner] file1 file2 > install [-bCcpSsv] [-B suffix] [-f flags] [-g > group] [-m mode] >=20 > *** Error code 64 >=20 > Stop in /usr/src/etc. >=20 > *** FATAL ERROR: Cannot 'cd' to /usr/src/etc and install files to the tem= proot environment >=20 > -- >=20 > It looks like mergemaster doesnt copy over the sourcefile for some > reason, i have tried to check the archives but couldnt find anyone with > the same issues. >=20 > I ignored the above message and stumbled upon the same error when i wante= d to do a 'make > distribution DESTDIR=3D/j/1' to create a jail. >=20 > I have removed the world and sync-ed against another cvsup server but > still the same issues. Is there anything i am doing wrong? >=20 > If more info is needed please ask. >=20 > Kind regards, >=20 > Wouter Prins > --=20 >=20 > QOTD: > "Everything I am today I owe to people, whom it is now > to late to punish." --=20 Time to take stock. Go home with some office supplies. --bKyqfOwhbdpXa4YI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDEfwAMWlPMjAfqRIRAqm7AKDxqolv8lSNyZLmqYiBYYekcLiH1wCdHDJG nxHjkRBTxznmNTF0HJYrQb0= =9Sn8 -----END PGP SIGNATURE----- --bKyqfOwhbdpXa4YI-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 28 18:57: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 1FD0A16A41F for ; Sun, 28 Aug 2005 18:57:54 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from smtp104.rog.mail.re2.yahoo.com (smtp104.rog.mail.re2.yahoo.com [206.190.36.82]) by mx1.FreeBSD.org (Postfix) with SMTP id A2401441EF for ; Sun, 28 Aug 2005 18:57:53 +0000 (GMT) (envelope-from mikej@rogers.com) Received: (qmail 84229 invoked from network); 28 Aug 2005 18:57:52 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:Message-ID:Date:Subject:From:To:User-Agent:MIME-Version:Content-Type:Content-Transfer-Encoding; b=5IpV05/VBHYVOD+r404JmOhGpGRiAn7dvJKtI4xdmNyfguyy61amFxGc7wCvRxgkunH5oZ5wE3MxcDrz2Xp1Of5ZuTceL1ePzfIWvjW29PHDgX1WITvyYUy6CsRksSVkuMAnYK3uf3v5ZHmRHOEKj6rJFZF5IbIu4It6RlMIwCc= ; Received: from unknown (HELO 172.16.0.1) (mikej@70.31.50.81 with login) by smtp104.rog.mail.re2.yahoo.com with SMTP; 28 Aug 2005 18:57:52 -0000 Received: from 172.16.0.199 (SquirrelMail authenticated user mikej) by 172.16.0.1 with HTTP; Sun, 28 Aug 2005 14:57:50 -0400 (EDT) Message-ID: <4190.172.16.0.199.1125255470.squirrel@172.16.0.1> Date: Sun, 28 Aug 2005 14:57:50 -0400 (EDT) From: "Mike Jakubik" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.5.1 [CVS] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: make release borken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2005 18:57:54 -0000 It looks like make release is broken on -CURRENT. These are the steps i took to arrive at the problem. rm -rf /usr/obj/usr mkdir /tmp/chroot cvsup cvsup cvsup make buildworld make release CHROOTDIR=/tmp/chroot BUILDNAME=7.0-CURRENT CVSROOT=/usr/home/ncvs -DMAKE_ISOS and the error is: --- /tmp/chroot/usr/share/locale/en_NZ.UTF-8 -> ../en_GB.UTF-8/LC_TIME /tmp/chroot/usr/share/locale/it_CH.UTF-8 -> ../it_IT.UTF-8/LC_TIME /tmp/chroot/usr/share/locale/nl_BE.UTF-8 -> ../nl_NL.UTF-8/LC_TIME /tmp/chroot/usr/share/locale/en_IE.UTF-8 -> ../en_GB.UTF-8/LC_TIME /tmp/chroot/usr/share/locale/af_ZA.UTF-8 -> ../en_US.UTF-8/LC_TIME /tmp/chroot/usr/share/locale/zh_HK.UTF-8 -> ../zh_TW.UTF-8/LC_TIME ===> share/zoneinfo (install) umask 022; cd /usr/src/share/zoneinfo; zic -D -d /tmp/chroot/usr/share/zoneinfo -p America/New_York -u root -g wheel -m 444 -y /usr/obj/usr/src/share/zoneinfo/yearistype africa antarctica asia australasia etcetera europe factory northamerica southamerica systemv zic: can't link from /tmp/chroot/usr/share/zoneinfo/America/Indianapolis to /tmp/chroot/usr/share/zoneinfo/EST: No such file or directory *** Error code 1 Stop in /usr/src/share/zoneinfo. *** Error code 1 Stop in /usr/src/share. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src/release. From owner-freebsd-current@FreeBSD.ORG Sun Aug 28 19:58: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 2CCCF16A41F for ; Sun, 28 Aug 2005 19:58:54 +0000 (GMT) (envelope-from stb@lassitu.de) Received: from schlepper.zs64.net (schlepper.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 949E243D45 for ; Sun, 28 Aug 2005 19:58:52 +0000 (GMT) (envelope-from stb@lassitu.de) Received: from [IPv6:::1] (schlepper [212.12.50.230]) by schlepper.zs64.net (8.13.3/8.12.9) with ESMTP id j7SJwipO006482; Sun, 28 Aug 2005 21:58:49 +0200 (CEST) (envelope-from stb@lassitu.de) In-Reply-To: <3923443F-6926-4BB7-8681-40FC68A41B79@lassitu.de> References: <7A0B19EC-2F90-495F-B242-7FB701C32908@lassitu.de> <20050828124321.43365136@Magellan.Leidinger.net> <3923443F-6926-4BB7-8681-40FC68A41B79@lassitu.de> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Stefan Bethke Date: Sun, 28 Aug 2005 21:58:43 +0200 To: soekris@house.org, caa@columbus.rr.com X-Mailer: Apple Mail (2.734) Cc: Alexander Leidinger , freebsd-current@freebsd.org Subject: Re: Boot off CF card hangs at "Trying to mount root" (was: Trouble with 6 boot/loader: system resets) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2005 19:58:54 -0000 Am 28.08.2005 um 18:46 schrieb Stefan Bethke: > Compiling boot, loader, and kernel without a CPUTYPE setting fixed > the boot and loader issues; however, the kernel doesn't seem to be > happy with the CF card: > > ad3: 489MB at ata1-slave PIO4 > Trying to mount root from ufs:/dev/ad3s1a > > Again, I can break into the debugger, but I'm not certain what I > should be looking at. > > I just tried setting the master/slave jumper on the mainboard to > "master", but that didn't change anything, either. > > Any suggestions? I found a couple of people having similar issues, but no solutions. Did you ever get it to work? http://lists.soekris.com/pipermail/soekris-tech/2004-August/021425.html http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2003-09/0120.html Stefan -- Stefan Bethke Fon +49 170 346 0140 From owner-freebsd-current@FreeBSD.ORG Sun Aug 28 21:45: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 1425716A41F; Sun, 28 Aug 2005 21:45:06 +0000 (GMT) (envelope-from imachine@toya.net.pl) Received: from lazir.toya.net.pl (lazir.toya.net.pl [217.113.224.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5330A43D46; Sun, 28 Aug 2005 21:45:05 +0000 (GMT) (envelope-from imachine@toya.net.pl) Received: from localhost (unknown [192.168.120.26]) by lazir.toya.net.pl (TOYAnet MailServer) with ESMTP id DC0318C112; Sun, 28 Aug 2005 23:45:01 +0200 (CEST) Received: from lazir.toya.net.pl ([192.168.120.25]) by localhost (agregat [192.168.120.26]) (amavisd-new, port 10024) with ESMTP id 22918-04; Sun, 28 Aug 2005 23:45:01 +0200 (CEST) Received: from [192.168.0.5] (unknown [85.89.161.206]) by lazir.toya.net.pl (TOYAnet MailServer) with ESMTP id 303358C10C; Sun, 28 Aug 2005 23:45:01 +0200 (CEST) From: Mateusz =?utf-8?q?J=C4=99drasik?= To: current@freebsd.org, ports@freebsd.org, sobomax@freebsd.org, freebsd-emulation@freebsd.org, eta@lclark.edu Date: Sun, 28 Aug 2005 23:40:42 +0200 User-Agent: KMail/1.8.2 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_b9iEDbD8AOgHpaY" Message-Id: <200508282340.43561.> X-TOYA-AV: AntyVir-Skaner at toya.net.pl Cc: Subject: FreeBSD-6-BETA3 broken with ports/audio/aureal-kmod; ports/graphics/linux_dri not working. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2005 21:45:06 -0000 --Boundary-00=_b9iEDbD8AOgHpaY Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, I have recently upgraded my 5.4-STABLE system to the new FreeBSD-6 line, of BETA-3. FreeBSD prokreation 6.0-BETA3 FreeBSD 6.0-BETA3 #3: Sat Aug 27 19:16:28 CEST 2005 root@prokreation:/usr/obj/usr/src/sys/PROKREATION i386 I indeed have to say great job - the system is as snappy as ever, however, I have a few errors that i would believe need fixing before -RELEASE is tagged imho. Firstly, I cannot seem to be able to build my aureal kld to play any sound. I believe the problem is quite trivial, however, I do not know FreeBSD sources well enough to track the error and fix it. Also, the linux_dri port is utterly broken on FreeBSD-6 when using radeon cards. Due to the late improvements by anholt towards a better radeon card support for dri, the drm kernel module radeon.ko /in my case, built into the kernel/ no longer works with terribly old dri libs. The solution I would best see here is bumping emulators/linux_base-suse-9.3 as default linux compat, updating the unhappy ports to play nicely with such an upgrade, and using xorg-dri drivers for linux_dri compatible with the xorg-libs avaliable with emulators/linux_base-suse-9.3. I would gladly help doing that, as I am a little more familiar with ports hacking rather than kernel hacking - far from perfect with it tho ;-) Below follows the aureal-kmod build log. I have filed a pr about it, yet not recieved a confirmation yet with the number to track down, but I will keep it up to date :-) Cheers, /m. --Boundary-00=_b9iEDbD8AOgHpaY Content-Type: text/x-diff; charset="us-ascii"; name="aureal-log" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="aureal-log" ===> Extracting for aureal-kmod-1.5_5 => Checksum OK for au88x0-1.5_4.tar.gz. ===> Patching for aureal-kmod-1.5_5 ===> Applying FreeBSD patches for aureal-kmod-1.5_5 ===> Configuring for aureal-kmod-1.5_5 ===> Building for aureal-kmod-1.5_5 ===> 10 (all) Warning: Object directory not changed from original /usr/ports/audio/aureal-kmod/work/10 @ -> /usr/src/sys machine -> /usr/src/sys/i386/include awk -f @/tools/makeobjops.awk @/kern/device_if.m -h awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/isa/isa_if.m -h awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h awk -f @/tools/makeobjops.awk @/dev/sound/pcm/ac97_if.m -h awk -f @/tools/makeobjops.awk @/dev/sound/pcm/channel_if.m -h awk -f @/tools/makeobjops.awk @/dev/sound/pcm/feeder_if.m -h awk -f @/tools/makeobjops.awk @/dev/sound/pcm/mixer_if.m -h cc -O2 -pipe -march=pentium3 -I/usr/ports/audio/aureal-kmod/work -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -I/usr/ports/audio/aureal-kmod/work -I. -I@ -I@/contrib/altq -I@/../include -I/usr/include -finline-limit=8000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /usr/ports/audio/aureal-kmod/work/au88x0.c /usr/ports/audio/aureal-kmod/work/au88x0.c: In function `au_pci_attach': /usr/ports/audio/aureal-kmod/work/au88x0.c:811: error: `PCIR_MAPS' undeclared (first use in this function) /usr/ports/audio/aureal-kmod/work/au88x0.c:811: error: (Each undeclared identifier is reported only once /usr/ports/audio/aureal-kmod/work/au88x0.c:811: error: for each function it appears in.) *** Error code 1 Stop in /usr/ports/audio/aureal-kmod/work/10. *** Error code 1 Stop in /usr/ports/audio/aureal-kmod/work. *** Error code 1 Stop in /usr/ports/audio/aureal-kmod. --Boundary-00=_b9iEDbD8AOgHpaY-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 28 22:18: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 8925F16A41F for ; Sun, 28 Aug 2005 22:18:50 +0000 (GMT) (envelope-from imachine@toya.net.pl) Received: from lazir.toya.net.pl (lazir.toya.net.pl [217.113.224.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id D2E6143D48 for ; Sun, 28 Aug 2005 22:18:49 +0000 (GMT) (envelope-from imachine@toya.net.pl) Received: from localhost (unknown [192.168.120.26]) by lazir.toya.net.pl (TOYAnet MailServer) with ESMTP id 01B408BD9D for ; Mon, 29 Aug 2005 00:18:49 +0200 (CEST) Received: from lazir.toya.net.pl ([192.168.120.25]) by localhost (agregat [192.168.120.26]) (amavisd-new, port 10024) with ESMTP id 24235-06 for ; Mon, 29 Aug 2005 00:18:46 +0200 (CEST) Received: from [192.168.0.5] (unknown [85.89.161.206]) by lazir.toya.net.pl (TOYAnet MailServer) with ESMTP id 1DB158BD7E for ; Mon, 29 Aug 2005 00:18:47 +0200 (CEST) From: Mateusz =?utf-8?q?J=C4=99drasik?= To: freebsd-current@freebsd.org Date: Mon, 29 Aug 2005 00:16:52 +0200 User-Agent: KMail/1.8.2 References: <200508282340.43561.> In-Reply-To: <200508282340.43561.> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200508290016.53050.imachine@toya.net.pl> X-TOYA-AV: AntyVir-Skaner at toya.net.pl Subject: Re: FreeBSD-6-BETA3 broken with ports/audio/aureal-kmod; ports/graphics/linux_dri not working. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2005 22:18:50 -0000 Dnia niedziela, 28 sierpnia 2005 23:40, Mateusz J=C4=99drasik napisa=C5=82: > Hello, > > I have recently upgraded my 5.4-STABLE system to the new FreeBSD-6 line, = of > BETA-3. > > FreeBSD prokreation 6.0-BETA3 FreeBSD 6.0-BETA3 #3: Sat Aug 27 19:16:28 > CEST 2005 root@prokreation:/usr/obj/usr/src/sys/PROKREATION i386 > > I indeed have to say great job - the system is as snappy as ever, however, > I have a few errors that i would believe need fixing before -RELEASE is > tagged imho. > > Firstly, I cannot seem to be able to build my aureal kld to play any soun= d. > I believe the problem is quite trivial, however, I do not know FreeBSD > sources well enough to track the error and fix it. > > Also, the linux_dri port is utterly broken on FreeBSD-6 when using radeon > cards. > > Due to the late improvements by anholt towards a better radeon card suppo= rt > for dri, the drm kernel module radeon.ko /in my case, built into the > kernel/ no longer works with terribly old dri libs. > > The solution I would best see here is bumping emulators/linux_base-suse-9= =2E3 > as default linux compat, updating the unhappy ports to play nicely with > such an upgrade, and using xorg-dri drivers for linux_dri compatible with > the xorg-libs avaliable with emulators/linux_base-suse-9.3. > > I would gladly help doing that, as I am a little more familiar with ports > hacking rather than kernel hacking - far from perfect with it tho ;-) > > Below follows the aureal-kmod build log. I have filed a pr about it, yet > not recieved a confirmation yet with the number to track down, but I will > keep it up to date :-) > > Cheers, > > /m. Ok, so I have fixed the aureal-kmod with help of IRC and kind people=20 there /thanks, matthieu--/ - putting PCIR_BARS instead of PCIR_MAPS in=20 au88x0.c fixes the problem :-) Yet, the linux_dri still remains unsolved. Any suggestions to my suggestion= s?=20 More than welcome :-) Cheers, =2D-=20 Mateusz J=C4=99drasik From owner-freebsd-current@FreeBSD.ORG Sun Aug 28 22:26: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 5FD0516A41F for ; Sun, 28 Aug 2005 22:26:41 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail1.fluidhosting.com (mail1.fluidhosting.com [204.14.90.61]) by mx1.FreeBSD.org (Postfix) with SMTP id CFB8B43D46 for ; Sun, 28 Aug 2005 22:26:40 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 20395 invoked by uid 399); 28 Aug 2005 22:26:40 -0000 Received: from localhost (HELO ?192.168.1.100?) (dougb@dougbarton.net@127.0.0.1) by localhost with SMTP; 28 Aug 2005 22:26:40 -0000 Message-ID: <43123A1E.9030700@FreeBSD.org> Date: Sun, 28 Aug 2005 15:26:38 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050726) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Wouter Prins References: <20050828171811.GB7529@businessconnect.nl> <20050828180136.GC7529@businessconnect.nl> In-Reply-To: <20050828180136.GC7529@businessconnect.nl> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Mergemaster issues in 5.4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2005 22:26:41 -0000 Wouter Prins wrote: > Hi, > > I have fixed this issue by commenting some profiles in /etc/make.conf > that i had previously enabled; With NO_PROFILE=true and other profiles > commented out it works fine. FYI, you're on the right track with it being something in /etc/make.conf, but it's definitely not NO_PROFILE, as I've basically always had that defined. Based on your error message in your first e-mail I think it's probably a NO_ option for ssh or crypto, but nothing in the Makefile indicates an obvious error to me. If you can find out which option it is that causes this problem, I would be interested in that, since no options should cause the thing to fail altogether. hope this helps, Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Sun Aug 28 22:48: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 2050716A41F for ; Sun, 28 Aug 2005 22:48:31 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail1.fluidhosting.com (mail1.fluidhosting.com [204.14.90.61]) by mx1.FreeBSD.org (Postfix) with SMTP id 097EB43D4C for ; Sun, 28 Aug 2005 22:48:29 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 44685 invoked by uid 399); 28 Aug 2005 22:48:29 -0000 Received: from localhost (HELO ?192.168.1.100?) (dougb@dougbarton.net@127.0.0.1) by localhost with SMTP; 28 Aug 2005 22:48:29 -0000 Message-ID: <43123F3B.8070002@FreeBSD.org> Date: Sun, 28 Aug 2005 15:48:27 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050726) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Bushkov References: <20050827170633.Y5409@stinger.cc.rsu.ru> In-Reply-To: <20050827170633.Y5409@stinger.cc.rsu.ru> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jacques Vidrine , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, Brooks Davis Subject: Re: [PATCH] caching daemon release and nsswitch patches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2005 22:48:31 -0000 Michael Bushkov wrote: > Hi! I'm working on nsswitch improvement (during the Google Summer of > Code program. First off, let me say that this is very exciting stuff! I'm particularly excited about caching for the services stuff, as it will finally allow us to bring in a more complete version of the services file. I do have some comments for you, and I hope that you understand that they are in no way critical of your work, just suggestions for improvements, and ways that you can better fit into the FreeBSD code base. I'm not sure what guidelines were given to you when you started the project, but in reviewing your work the first thing I noticed was that you are not following the guidelines in the style(9) man page. You should read that page, and spend an afternoon reformatting your code to fit what is described there. The most common error you've made is not following the 80 column rule, which hopefully should be easily fixed. While one could argue with the specific items in that page, and quite possibly be right, the idea of having a style guideline is more to have a common format that we can all work towards than to have a perfect format that we can all agree on. By reformatting your code to fit this guideline you will greatly increase the chances that it will be welcomed into the tree with open arms. The other style area that you should look at is your man pages. If you look in /usr/share/examples/mdoc you will find the FreeBSD style guidelines for man pages. The line wrapping issue comes into play here as well. We generally don't go past column 60 in man pages, since that reduces CVS repo churn for corrections down the road. Also, any time you have a full stop (period) at the end of a sentence, you should start a new line. I think that you are also using some macros that I'm not familiar with, although I'm not an mdoc expert. The other area that I'm interested in is how you plan to have cached interact with DNS lookups, /etc/hosts, named, etc. If there was a project plan posted somewhere on this already and I missed it, please accept my apologies, and send along a reference. If not, I'm very interested to hear what your plans are. Regards, Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Sun Aug 28 23:47: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 6882C16A41F for ; Sun, 28 Aug 2005 23:47:08 +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 BCC9143D45 for ; Sun, 28 Aug 2005 23:47:05 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.47]) (authenticated bits=0) by cain.gsoft.com.au (8.13.4/8.13.4) with ESMTP id j7SNkrm1007520 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 29 Aug 2005 09:16:58 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Mon, 29 Aug 2005 09:16:42 +0930 User-Agent: KMail/1.8.1 References: <7A0B19EC-2F90-495F-B242-7FB701C32908@lassitu.de> <3923443F-6926-4BB7-8681-40FC68A41B79@lassitu.de> In-Reply-To: <3923443F-6926-4BB7-8681-40FC68A41B79@lassitu.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2225030.eL5iK3HDIK"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200508290916.51703.doconnor@gsoft.com.au> X-Spam-Score: -2.82 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.51 on 203.31.81.10 Cc: Alexander Leidinger , Stefan Bethke Subject: Re: Boot off CF card hangs at "Trying to mount root" (was: Trouble with 6 boot/loader: system resets) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Aug 2005 23:47:08 -0000 --nextPart2225030.eL5iK3HDIK Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 29 August 2005 02:16, Stefan Bethke wrote: > Compiling boot, loader, and kernel without a CPUTYPE setting fixed > the boot and loader issues; however, the kernel doesn't seem to be > happy with the CF card: > > ad3: 489MB at ata1-slave PIO4 > Trying to mount root from ufs:/dev/ad3s1a Why do you say the kernel doesn't like it? Looks fine to me.. It should still work if it's ad3, but you'll need to alter your fstab. =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 --nextPart2225030.eL5iK3HDIK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBDEkzr5ZPcIHs/zowRAtYxAKCFmbXqS2pUJI3OO/Qq2ibENaGj/ACfXObR MVDmA1/LhybjsOgkPcvaUoM= =Q2ZK -----END PGP SIGNATURE----- --nextPart2225030.eL5iK3HDIK-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 01:18: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 21CBD16A41F for ; Mon, 29 Aug 2005 01:18:32 +0000 (GMT) (envelope-from leafy7382@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83F5C43D46 for ; Mon, 29 Aug 2005 01:18:30 +0000 (GMT) (envelope-from leafy7382@gmail.com) Received: by zproxy.gmail.com with SMTP id z6so556787nzd for ; Sun, 28 Aug 2005 18:18:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=iJtjPglIIDHxWF2KzrvGGcWLoooqzpGitmuXb9917zAFpXS3u1eNQMNDu0AFw2WDfeDiuANHTDMLRiViGHmHbsdQU1lZEdgmFf1rwxoL1qH6rVQ/lapYkiz/3fQcW7XVmid8k233xF7rouFo6SUW0YE2NFrsNrZ6Y6anwshbVRw= Received: by 10.37.13.7 with SMTP id q7mr741810nzi; Sun, 28 Aug 2005 18:18:28 -0700 (PDT) Received: by 10.36.88.8 with HTTP; Sun, 28 Aug 2005 18:18:27 -0700 (PDT) Message-ID: Date: Mon, 29 Aug 2005 09:18:27 +0800 From: Jiawei Ye To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Strange threading issue with apache2 WITH_THREADS=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: Mon, 29 Aug 2005 01:18:32 -0000 I have been using www/apache2 with WITH_THREADS=3D1 for a long time on a -current system. With a recent world upgrade, I start to get "Fatal error Dead thread has assumed at line 158 in file src/lib/libpthread/thread/thr_exit.c (errno =3D 0)" and httpd no longer functions. Rebuilding kernel/world/libpthread does not seem to make any difference, nor does rebuilding www/apache2 itself. Any suggestions? Jiawei Ye --=20 "Without the userland, the kernel is useless." --inspired by The Tao of Programming From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 01:49: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 C9E2216A41F for ; Mon, 29 Aug 2005 01:49:03 +0000 (GMT) (envelope-from grog@lemis.com) Received: from echunga.lemis.com (ext-gw.lemis.com [150.101.14.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id A853C43D67 for ; Mon, 29 Aug 2005 01:49:00 +0000 (GMT) (envelope-from grog@lemis.com) Received: from blackwater.lemis.com (wantadilla.lemis.com [192.109.197.135]) by echunga.lemis.com (Postfix) with ESMTP id 852B9131B53 for ; Mon, 29 Aug 2005 11:18:59 +0930 (CST) Received: by blackwater.lemis.com (Postfix, from userid 1004) id AF98A84F82; Thu, 25 Aug 2005 07:55:16 +0930 (CST) Date: Thu, 25 Aug 2005 07:55:16 +0930 From: Greg 'groggy' Lehey To: Nikolay Kalev Message-ID: <20050824222516.GA1106@wantadilla.lemis.com> References: <430C36BD.1020808@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline In-Reply-To: <430C36BD.1020808@gmail.com> User-Agent: Mutt/1.4.2.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Cc: freebsd-current@freebsd.org Subject: Re: unknown coredump ! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 01:49:04 -0000 --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wednesday, 24 August 2005 at 11:58:37 +0300, Nikolay Kalev wrote: > I'm getting coredump of chkgrp.core and i don;t know the reason for > this. Any ideas or suggestions ? Take a look at the time of the dump. It might give you a clue. > I'm attaching the coredump file ... By itself, it's useless. Build a debug version of chkgrp and get a backtrace. Greg -- See complete headers for address and phone numbers. --FCuugMFkClbJLl1L Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFDDPPMIubykFB6QiMRAnMPAJ4k4OR48V82DPwLKga0ghl/Sill6QCdEtPN hgQzJtvEWdW3RzRpmLW3w8Q= =3JN2 -----END PGP SIGNATURE----- --FCuugMFkClbJLl1L-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 04:44: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 7954F16A41F for ; Mon, 29 Aug 2005 04:44:25 +0000 (GMT) (envelope-from girish.nandibasappa@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1841743D46 for ; Mon, 29 Aug 2005 04:44:24 +0000 (GMT) (envelope-from girish.nandibasappa@gmail.com) Received: by wproxy.gmail.com with SMTP id i11so357161wra for ; Sun, 28 Aug 2005 21:44:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=L6/bnzoAN76j82KWKjE5iIQES5PcuIr3+7hP5GL/lzNjtSTBgOF4Qq+n2Eivsg0cppD7zBR9cW/+g0BvSzFdqr+/DnPeVguTLWg3d+GjvOsAQnG8z2bnWgKGSXGNxbwzoqEeXOWjc4ygosllIDJhsaHZq9rl4X4lBx7v1x4nS7k= Received: by 10.54.151.7 with SMTP id y7mr5317252wrd; Sun, 28 Aug 2005 21:44:23 -0700 (PDT) Received: by 10.54.57.9 with HTTP; Sun, 28 Aug 2005 21:44:22 -0700 (PDT) Message-ID: Date: Mon, 29 Aug 2005 10:14:22 +0530 From: "Girish.Nandibasappa@lntinfotech.com giri" To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: (no subject) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 04:44:25 -0000 hi,=20 I am working for a driver on USB mass storage device. I have an SD Card I am able to format it in windows XP but it fails when i try to format it in windows 2k. can anybody help me out on this problem. thanks in advance. Giri From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 04:55: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 C50DB16A41F for ; Mon, 29 Aug 2005 04:55:34 +0000 (GMT) (envelope-from stb@lassitu.de) Received: from schlepper.zs64.net (schlepper.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A9DD43D4C for ; Mon, 29 Aug 2005 04:55:33 +0000 (GMT) (envelope-from stb@lassitu.de) Received: from [IPv6:::1] (schlepper [212.12.50.230]) by schlepper.zs64.net (8.13.3/8.12.9) with ESMTP id j7T4tVHm012987; Mon, 29 Aug 2005 06:55:31 +0200 (CEST) (envelope-from stb@lassitu.de) In-Reply-To: <200508290916.51703.doconnor@gsoft.com.au> References: <7A0B19EC-2F90-495F-B242-7FB701C32908@lassitu.de> <3923443F-6926-4BB7-8681-40FC68A41B79@lassitu.de> <200508290916.51703.doconnor@gsoft.com.au> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3B2E0DAA-C256-4FBE-A4EB-7BAD80E2D711@lassitu.de> Content-Transfer-Encoding: 7bit From: Stefan Bethke Date: Mon, 29 Aug 2005 06:55:30 +0200 To: "Daniel O'Connor" X-Mailer: Apple Mail (2.734) Cc: freebsd-current@freebsd.org Subject: Re: Boot off CF card hangs at "Trying to mount root" (was: Trouble with 6 boot/loader: system resets) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 04:55:34 -0000 Am 29.08.2005 um 01:46 schrieb Daniel O'Connor: > On Monday 29 August 2005 02:16, Stefan Bethke wrote: >> Compiling boot, loader, and kernel without a CPUTYPE setting fixed >> the boot and loader issues; however, the kernel doesn't seem to be >> happy with the CF card: >> >> ad3: 489MB at ata1-slave PIO4 >> Trying to mount root from ufs:/dev/ad3s1a > > Why do you say the kernel doesn't like it? > Looks fine to me.. > > It should still work if it's ad3, but you'll need to alter your fstab. Because it hangs after printing that line? Not changing fstab it complaints about being unable to mount root. Specifying the correct devices, it hangs. Stefan -- Stefan Bethke Fon +49 170 346 0140 From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 05:06: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 CAD8F16A41F for ; Mon, 29 Aug 2005 05:06:18 +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 1F9F343D48 for ; Mon, 29 Aug 2005 05:06:17 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.47]) (authenticated bits=0) by cain.gsoft.com.au (8.13.4/8.13.4) with ESMTP id j7T56Ao6011600 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 29 Aug 2005 14:36:15 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Stefan Bethke Date: Mon, 29 Aug 2005 14:36:02 +0930 User-Agent: KMail/1.8.1 References: <7A0B19EC-2F90-495F-B242-7FB701C32908@lassitu.de> <200508290916.51703.doconnor@gsoft.com.au> <3B2E0DAA-C256-4FBE-A4EB-7BAD80E2D711@lassitu.de> In-Reply-To: <3B2E0DAA-C256-4FBE-A4EB-7BAD80E2D711@lassitu.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2468916.JVBgW3R8gB"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200508291436.03694.doconnor@gsoft.com.au> X-Spam-Score: -2.82 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.51 on 203.31.81.10 Cc: freebsd-current@freebsd.org Subject: Re: Boot off CF card hangs at "Trying to mount root" (was: Trouble with 6 boot/loader: system resets) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 05:06:18 -0000 --nextPart2468916.JVBgW3R8gB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 29 August 2005 14:25, Stefan Bethke wrote: > > It should still work if it's ad3, but you'll need to alter your fstab. > > Because it hangs after printing that line? Not changing fstab it You neglected to mention the failure mode and I am not a mind reader. > complaints about being unable to mount root. Specifying the correct > devices, it hangs. OK. I would suggest getting the output of ps into a file (say, via serial conso= le)=20 as well as a back trace and posting a URL to it. =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 --nextPart2468916.JVBgW3R8gB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBDEpe75ZPcIHs/zowRAgybAJ98lLPUUPA3cF0H35OxLbsmWZ0YdwCgn06Q 3T5db9bjfpbd/sB7AU/Koyg= =g3GD -----END PGP SIGNATURE----- --nextPart2468916.JVBgW3R8gB-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 05:17:38 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 EF22C16A41F for ; Mon, 29 Aug 2005 05:17:38 +0000 (GMT) (envelope-from stb@lassitu.de) Received: from schlepper.zs64.net (schlepper.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64E4D43D45 for ; Mon, 29 Aug 2005 05:17:38 +0000 (GMT) (envelope-from stb@lassitu.de) Received: from [IPv6:::1] (schlepper [212.12.50.230]) by schlepper.zs64.net (8.13.3/8.12.9) with ESMTP id j7T5Hawr013262; Mon, 29 Aug 2005 07:17:37 +0200 (CEST) (envelope-from stb@lassitu.de) In-Reply-To: <200508291436.03694.doconnor@gsoft.com.au> References: <7A0B19EC-2F90-495F-B242-7FB701C32908@lassitu.de> <200508290916.51703.doconnor@gsoft.com.au> <3B2E0DAA-C256-4FBE-A4EB-7BAD80E2D711@lassitu.de> <200508291436.03694.doconnor@gsoft.com.au> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8D7F65A5-DF50-498C-BBAC-3AACE9989FBB@lassitu.de> Content-Transfer-Encoding: 7bit From: Stefan Bethke Date: Mon, 29 Aug 2005 07:17:35 +0200 To: "Daniel O'Connor" X-Mailer: Apple Mail (2.734) Cc: freebsd-current@freebsd.org Subject: Re: Boot off CF card hangs at "Trying to mount root" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 05:17:39 -0000 Am 29.08.2005 um 07:06 schrieb Daniel O'Connor: > On Monday 29 August 2005 14:25, Stefan Bethke wrote: >>> It should still work if it's ad3, but you'll need to alter your >>> fstab. >> Because it hangs after printing that line? Not changing fstab it > You neglected to mention the failure mode and I am not a mind reader. Sorry, I thought it would be obvious from the subject line. > OK. > I would suggest getting the output of ps into a file (say, via > serial console) > as well as a back trace and posting a URL to it. Since this is my router, and I need to get a cross-over serial cable before doing that, should I kick off a kernel compile with any particular debugging options, or would a standard verbose boot be sufficient? Thanks, Stefan -- Stefan Bethke Fon +49 170 346 0140 From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 05:26:26 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 21A4116A41F for ; Mon, 29 Aug 2005 05:26:26 +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 4F13843D46 for ; Mon, 29 Aug 2005 05:26:25 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.47]) (authenticated bits=0) by cain.gsoft.com.au (8.13.4/8.13.4) with ESMTP id j7T5QIct011768 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 29 Aug 2005 14:56:23 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Stefan Bethke Date: Mon, 29 Aug 2005 14:56:14 +0930 User-Agent: KMail/1.8.1 References: <7A0B19EC-2F90-495F-B242-7FB701C32908@lassitu.de> <200508291436.03694.doconnor@gsoft.com.au> <8D7F65A5-DF50-498C-BBAC-3AACE9989FBB@lassitu.de> In-Reply-To: <8D7F65A5-DF50-498C-BBAC-3AACE9989FBB@lassitu.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1670745.Vn4p1kThRL"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200508291456.14532.doconnor@gsoft.com.au> X-Spam-Score: -2.82 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.51 on 203.31.81.10 Cc: freebsd-current@freebsd.org Subject: Re: Boot off CF card hangs at "Trying to mount root" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 05:26:26 -0000 --nextPart1670745.Vn4p1kThRL Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 29 August 2005 14:47, Stefan Bethke wrote: > > You neglected to mention the failure mode and I am not a mind reader. > > Sorry, I thought it would be obvious from the subject line. Doh.. Sorry I am blind :( > > OK. > > I would suggest getting the output of ps into a file (say, via > > serial console) > > as well as a back trace and posting a URL to it. > > Since this is my router, and I need to get a cross-over serial cable > before doing that, should I kick off a kernel compile with any > particular debugging options, or would a standard verbose boot be > sufficient? Just a normal verbose boot should do for that sort of information. =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 --nextPart1670745.Vn4p1kThRL Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBDEpx25ZPcIHs/zowRAjgjAKCKXVzWZCBWWvLfwv/W5WeZifEvPgCbBh0e DqGuiFpK1rORNGkrCe/8VhQ= =atTE -----END PGP SIGNATURE----- --nextPart1670745.Vn4p1kThRL-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 06:06: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 B358616A41F; Mon, 29 Aug 2005 06:06:50 +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 44A6B43D46; Mon, 29 Aug 2005 06:06:50 +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.3/8.13.3) with ESMTP id j7T66ntl041627; Mon, 29 Aug 2005 02:06:49 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j7T66me1060169; Mon, 29 Aug 2005 02:06:49 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 716AD7304D; Mon, 29 Aug 2005 02:06:48 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050829060648.716AD7304D@freebsd-current.sentex.ca> Date: Mon, 29 Aug 2005 02:06:48 -0400 (EDT) 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 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: Mon, 29 Aug 2005 06:06:51 -0000 TB --- 2005-08-29 04:09:21 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-08-29 04:09:21 - starting HEAD tinderbox run for i386/pc98 TB --- 2005-08-29 04:09:21 - cleaning the object tree TB --- 2005-08-29 04:10:04 - checking out the source tree TB --- 2005-08-29 04:10:04 - cd /tinderbox/HEAD/i386/pc98 TB --- 2005-08-29 04:10:04 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-08-29 04:25:30 - building world (CFLAGS=-O2 -pipe) TB --- 2005-08-29 04:25:30 - cd /src TB --- 2005-08-29 04:25:30 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2005-08-29 05:57:28 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-08-29 05:57:28 - cd /src TB --- 2005-08-29 05:57:28 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Aug 29 05:57: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 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/dev/ata/ata-card.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/dev/awi/if_awi_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/dev/ct/bshw_machdep.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/dev/ct/ct.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/dev/ct/ct_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 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/dev/ed/if_ed_cbus.c In file included from /src/sys/dev/ed/if_ed_cbus.c:49: /src/sys/dev/ed/if_edvar.h:37: error: field `ifmedia' has incomplete type *** Error code 1 Stop in /obj/pc98/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-08-29 06:06:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-08-29 06:06:47 - ERROR: failed to build generic kernel TB --- 2005-08-29 06:06:47 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 06:12: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 156D416A41F for ; Mon, 29 Aug 2005 06:12:47 +0000 (GMT) (envelope-from rowinggoon@hotmail.com) Received: from hotmail.com (bay101-f17.bay101.hotmail.com [64.4.56.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id D961343D45 for ; Mon, 29 Aug 2005 06:12:46 +0000 (GMT) (envelope-from rowinggoon@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 28 Aug 2005 23:12:44 -0700 Message-ID: Received: from 64.4.56.200 by by101fd.bay101.hotmail.msn.com with HTTP; Mon, 29 Aug 2005 06:12:44 GMT X-Originating-IP: [64.4.56.200] X-Originating-Email: [rowinggoon@hotmail.com] X-Sender: rowinggoon@hotmail.com From: "Hanns Hartman" To: freebsd-current@freebsd.org Date: Sun, 28 Aug 2005 23:12:44 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 29 Aug 2005 06:12:44.0660 (UTC) FILETIME=[ABA6CB40:01C5AC60] Subject: wpa_supplicant segfaults with ath X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 06:12:47 -0000 Hi, This is my first time posting to the list so if you need more information let me know. also since I have no internet on my freebsd box it is difficult to get all of the verbose output. so here goes. I am using freebsd6.0beta2 on an amd64. I am using the src tree from august 21. I am trying to associate with a 2wire gateway that was supplied by sbc for my dsl. I have set the gateway up with wpa-psk encription. I am able to connect perfectly fine to this gateway with my ibm t42 but when I try to associate with the gateway using wpa_supplicant I get a segmentation fault after the program reaches "wpa: sending eapol-key 4/4" specifially it faults right after displaying "wpa: rsc - hexdump(len=6): 00 00 00 00 00 00" while using option -d for output. when running the supplicant in gdb I get program received SIGSEGV, segmentation fault. 0x000000080082d4d0 in strlen () from /lib/libc.so.6 if there is anything else needed that might help to explain the problem let me know. I appoligize for not having more output to post at this time. thanks for the help Hanns From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 06:33: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 0CD5716A41F for ; Mon, 29 Aug 2005 06:33:50 +0000 (GMT) (envelope-from mischa.peters@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6222243D48 for ; Mon, 29 Aug 2005 06:33:49 +0000 (GMT) (envelope-from mischa.peters@gmail.com) Received: by xproxy.gmail.com with SMTP id i31so545474wxd for ; Sun, 28 Aug 2005 23:33:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=ds6j9nbGZCAuV2phyUwFFkDfMtnLRj/XNYA20HwgVKOy+uMm0clUpJ2F4eOivrTgTXl1LcskbUtCwW6Esar/aw86eOEn0MuOagQ6vnGEwj9HY20NjaCE4OtzAofv4AY6ZMAoiEwfNAGqiMdqrecAWQAIg49kb+eha/Fk7fFiFKM= Received: by 10.70.62.12 with SMTP id k12mr90983wxa; Sun, 28 Aug 2005 23:33:46 -0700 (PDT) Received: by 10.70.76.10 with HTTP; Sun, 28 Aug 2005 23:33:46 -0700 (PDT) Message-ID: <25e9cd0105082823337369bb6d@mail.gmail.com> Date: Mon, 29 Aug 2005 08:33:46 +0200 From: Mischa Peters To: freebsd-current@freebsd.org, freebsd-scsi@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Subject: LSI Logic fibre channel adapter in FreeBSD 6.0-BETA3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 06:33:50 -0000 Hi All, I am not sure if this is the correct list. But I have the following issue. I have a Fibre Channel card in my server, LSI Logic FC909A which was working fine under FreeBSD 4.11 but is no longer working with 6.0-BETA3. I have also tried it with BETA1 which also didn't work. The thing that I see in messages is: pci0: at device 11.0 (no driver attached) pci0: at device 11.1 (no driver attached) I have seen that in GENERIC the old ncr drivers are disabled and are replaced with sym. Does this matter at all, or is this b0rken and does it needs fixing? Thanx!! Mischa From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 06:38: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 98F9F16A41F for ; Mon, 29 Aug 2005 06:38:17 +0000 (GMT) (envelope-from caelian@gmail.com) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2437643D48 for ; Mon, 29 Aug 2005 06:38:16 +0000 (GMT) (envelope-from caelian@gmail.com) Received: by rproxy.gmail.com with SMTP id r35so955194rna for ; Sun, 28 Aug 2005 23:38:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=luch6CgayjXQnvXB74JbVpxbGsZzcF5XmbQVfW8nbAPI9hVSZjX4r7s2EQALnNrsSpgDQFRIyr5LvfHoJyL14XjO0GgZDktzMtTYm1iOUpBqZBhFdp/mMZgCH7Z2JB4+6STc2eS8Hl9CAe2uJQ0gI6ll+WbEIUQgD74UTdVMSz4= Received: by 10.38.151.35 with SMTP id y35mr175319rnd; Sun, 28 Aug 2005 23:38:16 -0700 (PDT) Received: from ?192.168.15.104? ( [68.190.230.198]) by mx.gmail.com with ESMTP id m35sm777835rnd.2005.08.28.23.38.15; Sun, 28 Aug 2005 23:38:16 -0700 (PDT) From: Pascal Hofstee To: Hanns Hartman In-Reply-To: References: Content-Type: text/plain Date: Sun, 28 Aug 2005 23:38:14 -0700 Message-Id: <1125297494.67517.19.camel@synergy.charterpipeline.net.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.3.8 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: wpa_supplicant segfaults with ath X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 06:38:17 -0000 On Sun, 2005-08-28 at 23:12 -0700, Hanns Hartman wrote: > Hi, > This is my first time posting to the list so if you need more information > let me know. also since I have no internet on my freebsd box it is difficult > to get all of the verbose output. so here goes. > > I am using freebsd6.0beta2 on an amd64. I am using the src tree from august > 21. > > I am trying to associate with a 2wire gateway that was supplied by sbc for > my dsl. I have set the gateway up with wpa-psk encription. > I am able to connect perfectly fine to this gateway with my ibm t42 but when > I try to associate with the gateway using wpa_supplicant I get a > segmentation fault after the program reaches "wpa: sending eapol-key 4/4" > specifially it faults right after displaying "wpa: rsc - hexdump(len=6): 00 > 00 00 00 00 00" while using option -d for output. > > when running the supplicant in gdb I get program received SIGSEGV, > segmentation fault. 0x000000080082d4d0 in strlen () from /lib/libc.so.6 > > if there is anything else needed that might help to explain the problem let > me know. I appoligize for not having more output to post at this time. > thanks for the help > Hanns Thank you for posting this ... as it reminded me i should probably file a bug report on this. I recently tried to do some investigative work of my own hoping to find out why my if_ral interface kept acting up when i bumped into the exact same problem myself. i can tell you why the segfault happens .. though i am not entirely sure how it should be fixed properly. The problem you're experiencing is caused by the ether_ntoa(addr) call in /usr/src/usr.sbin/wpa/wpa_supplicant/driver_freebsd.c:280 ether_ntoa expects a "const struct ether_addr" as it's parameter where in the code the parameter passed is a "const unsigned char*", further more in that same printf statement seq_len and key_len are being displayed using "%d" where this should be "%zu" since these are size_t's. The size_t construct happens a few more times in the code if i recall correctly. The actual crash you're experiencing though is caused by the faulty ether_ntoa argument. If somebody more knowledgable on this particular subject could have a closer look at what was actually intended here that would be appreciated. -- Pascal Hofstee From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 07:44: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 A1A2C16A41F for ; Mon, 29 Aug 2005 07:44:18 +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 452F543D4C for ; Mon, 29 Aug 2005 07:44:18 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.52 (FreeBSD)) id 1E9eJV-0004mI-5E for current@freebsd.org; Mon, 29 Aug 2005 11:44:17 +0400 From: Vladimir Grebenschikov To: current Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: SWsoft Date: Mon, 29 Aug 2005 11:44:16 +0400 Message-Id: <1125301456.1087.7.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov Cc: Subject: Failed to create package for ruby18-bdb1-0.2.2.tbz X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vova@fbsd.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2005 07:44:18 -0000 Hi ===> Installing for ruby18-bdb1-0.2.2 ===> ruby18-bdb1-0.2.2 depends on file: /usr/local/bin/ruby18 - found ===> Generating temporary packing list install -c -p -m 0755 bdb1.so /usr/local/lib/ruby/site_ruby/1.8/i386-freebsd6 ===> Registering installation for ruby18-bdb1-0.2.2 ===> Building package for ruby18-bdb1-0.2.2 Creating package /usr/ports/packages/All/ruby18-bdb1-0.2.2.tbz Registering depends: ruby-1.8.2_4. Creating bzip'd tar ball in '/usr/ports/packages/All/ruby18-bdb1-0.2.2.tbz' tar: lib/ruby/site_ruby/1.8/i386-freebsd7/bdb1.so: Cannot stat: No such file or directory pkg_create: make_dist: tar command failed with code 256 *** Error code 1 Stop in /usr/ports/databases/ruby-bdb1. *** Error code 1 Stop in /usr/ports/sysutils/portupgrade. *** Error code 1 Stop in /usr/ports/sysutils/portupgrade. ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade15753.0 make BATCH=yes DEPENDS_TARGET=package reinstall egrep: /var/db/pkg/portupgrade-20041226_5/+CONTENTS: No such file or directory -- Vladimir B. Grebenschikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 08:12: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 4906216A41F; Mon, 29 Aug 2005 08:12:17 +0000 (GMT) (envelope-from bushman@rsu.ru) Received: from mail.r61.net (mail.r61.net [195.208.245.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD7B643D49; Mon, 29 Aug 2005 08:12:16 +0000 (GMT) (envelope-from bushman@rsu.ru) Received: from stinger.cc.rsu.ru (stinger.cc.rsu.ru [195.208.252.82]) by mail.r61.net (8.13.4/8.13.4) with ESMTP id j7T8C5o4091247; Mon, 29 Aug 2005 12:12:05 +0400 (MSD) (envelope-from bushman@rsu.ru) Date: Mon, 29 Aug 2005 12:16:01 +0400 (MSD) From: Michael Bushkov X-X-Sender: bushman@stinger.cc.rsu.ru To: Doug Barton In-Reply-To: <43123F3B.8070002@FreeBSD.org> Message-ID: <20050829115740.N5409@stinger.cc.rsu.ru> References: <20050827170633.Y5409@stinger.cc.rsu.ru> <43123F3B.8070002@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.86.2, clamav-milter version 0.86 on asterix.r61.net X-Virus-Status: Clean X-Spam-Status: No, score=-5.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on asterix.r61.net Cc: Jacques Vidrine , freebsd-hackers@FreeBSD.org, freebsd-current@FreeBSD.org, Brooks Davis Subject: Re: [PATCH] caching daemon release and nsswitch patches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 08:12:17 -0000 Hi, Doug! > I'm not sure what guidelines were given to you when you started the project, > but in reviewing your work the first thing I noticed was that you are not > following the guidelines in the style(9) man page. You should read that page, > and spend an afternoon reformatting your code to fit what is described there. > The most common error you've made is not following the 80 column rule, which > hopefully should be easily fixed. While one could argue with the specific > items in that page, and quite possibly be right, the idea of having a style > guideline is more to have a common format that we can all work towards than > to have a perfect format that we can all agree on. By reformatting your code > to fit this guideline you will greatly increase the chances that it will be > welcomed into the tree with open arms. > > The other style area that you should look at is your man pages. If you look > in /usr/share/examples/mdoc you will find the FreeBSD style guidelines for > man pages. The line wrapping issue comes into play here as well. We generally > don't go past column 60 in man pages, since that reduces CVS repo churn for > corrections down the road. Also, any time you have a full stop (period) at > the end of a sentence, you should start a new line. I think that you are also > using some macros that I'm not familiar with, although I'm not an mdoc > expert. Thank you very much for your suggestions - I'll reformat the code and man files. I've seemed to forget about style(9) in some places :( > > The other area that I'm interested in is how you plan to have cached interact > with DNS lookups, /etc/hosts, named, etc. If there was a project plan posted > somewhere on this already and I missed it, please accept my apologies, and > send along a reference. If not, I'm very interested to hear what your plans > are. > There is some information in my project's description here: http://wikitest.freebsd.org/moin.cgi/NsswitchAndCachingTechnicalDetails The "Integrating nsswitch and caching" describes the way that I use to make cached work. It can actually interact with any nsswitch database. All we need is to supply the special structure (in patches it is usually called "cache_info") with 3 functions pointers (*_id_func, *_marshal_func, *_unmarshal_func). These functions are used by nsdispatch during the caching of sccessful results. id_func identifies the key - the unique identifier, which will identify the data in the cache. And marshal_func/unmarshal_func pack/unpack data into/from the (char *)buffer. So almost all data, that go through nsdispatch calls, can be cached. And "struct hostent" and "struct addrinfo" are no exceptions to this rule. I already have the patch with *_id_func, *_marshal and *_unmarshal_func implemented for the "hosts" nsswitch database. I'll send it to the list along with the corrected version of the cached a bit later (in about 12 hours). P.S. the patched version of nsdispatch uses the functions that are implemented in nscache.c and nscachedcli.c files (they are present in the patch). With best regards, Michael From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 08:37: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 A6FEE16A41F for ; Mon, 29 Aug 2005 08:37:37 +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 26BCD43D45 for ; Mon, 29 Aug 2005 08:37:36 +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 18218440DA for ; Mon, 29 Aug 2005 10:37:36 +0200 (CEST) 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 17697-07 for ; Mon, 29 Aug 2005 10:37:34 +0200 (CEST) Received: from m2a2.dyndns.org (p50912F9F.dip0.t-ipconnect.de [80.145.47.159]) by mail.dt.e-technik.uni-dortmund.de (Postfix) with ESMTP id A83D8440A0 for ; Mon, 29 Aug 2005 10:37:34 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by merlin.emma.line.org (Postfix) with ESMTP id 5C7B7775BB for ; Mon, 29 Aug 2005 10:37:32 +0200 (CEST) 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 26748-04 for ; Mon, 29 Aug 2005 10:37:31 +0200 (CEST) Received: by merlin.emma.line.org (Postfix, from userid 500) id 90C9A77C09; Mon, 29 Aug 2005 10:37:31 +0200 (CEST) From: Matthias Andree To: freebsd-current@freebsd.org X-PGP-Key: http://home.pages.de/~mandree/keys/GPGKEY.asc Date: Mon, 29 Aug 2005 10:37:31 +0200 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 Subject: 6.0-BETA3: ext2fs: no cp(1) possible, mmap returns EINVAL X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 08:37:37 -0000 Greetings, I mounted a Linux ext3 as ext2fs, which worked fine. However, trying to cvsupd or cp data out of the partition was refused, tracing the processes revealed that mmap() returned EINVAL. rsync(1) (from ports) worked though. Are further details required? If so, which? TIA. Regards, -- Matthias Andree From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 08: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 0316216A41F for ; Mon, 29 Aug 2005 08:42:29 +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 6F0A443D45 for ; Mon, 29 Aug 2005 08:42:28 +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 8282B440DA for ; Mon, 29 Aug 2005 10:42:27 +0200 (CEST) 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 17697-09 for ; Mon, 29 Aug 2005 10:42:26 +0200 (CEST) Received: from m2a2.dyndns.org (p50912F9F.dip0.t-ipconnect.de [80.145.47.159]) by mail.dt.e-technik.uni-dortmund.de (Postfix) with ESMTP id 24735440A0 for ; Mon, 29 Aug 2005 10:42:26 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by merlin.emma.line.org (Postfix) with ESMTP id 651C9775BB for ; Mon, 29 Aug 2005 10:42:25 +0200 (CEST) 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 27113-06 for ; Mon, 29 Aug 2005 10:42:24 +0200 (CEST) Received: by merlin.emma.line.org (Postfix, from userid 500) id B005277C09; Mon, 29 Aug 2005 10:42:24 +0200 (CEST) From: Matthias Andree To: freebsd-current@freebsd.org X-PGP-Key: http://home.pages.de/~mandree/keys/GPGKEY.asc Date: Mon, 29 Aug 2005 10:42:24 +0200 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 Subject: 6.0-BETA3: ext2fs through nullfs: panic "locking against myself" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 08:42:29 -0000 Subject says it all. mount a ext2 file system, use it as basis for a nullfs mount -> panic. -- Matthias Andree From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 08:44: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 5C3C116A41F for ; Mon, 29 Aug 2005 08:44:33 +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 CE89F43D49 for ; Mon, 29 Aug 2005 08:44:32 +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 EFCE5440DA for ; Mon, 29 Aug 2005 10:44:31 +0200 (CEST) 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 17438-10 for ; Mon, 29 Aug 2005 10:44:30 +0200 (CEST) Received: from m2a2.dyndns.org (p50912F9F.dip0.t-ipconnect.de [80.145.47.159]) by mail.dt.e-technik.uni-dortmund.de (Postfix) with ESMTP id 76965440A0 for ; Mon, 29 Aug 2005 10:44:30 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by merlin.emma.line.org (Postfix) with ESMTP id C22E1775BB for ; Mon, 29 Aug 2005 10:44:29 +0200 (CEST) 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 26748-07 for ; Mon, 29 Aug 2005 10:44:29 +0200 (CEST) Received: by merlin.emma.line.org (Postfix, from userid 500) id 1C7E377C09; Mon, 29 Aug 2005 10:44:29 +0200 (CEST) From: Matthias Andree To: freebsd-current@freebsd.org X-PGP-Key: http://home.pages.de/~mandree/keys/GPGKEY.asc Date: Mon, 29 Aug 2005 10:44:29 +0200 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 Subject: 6.0-BETA3: ext2fs: if mounted at shutdown, fsck at next boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 08:44:33 -0000 See Subject - this bug has already haunted FreeBSD 5 and still persists in FreeBSD 6.0: shutting down FreeBSD 5 or 6 with a mounted ext2fs file system prevents proper synching of the super blocks (vnode count remains nonzero, until kernel gives up), so all file systems that were mounted are fsck'd at next reboot, UFS, UFS2, ext2fs, doesn't matter. Someone please check the ext2fs locking. -- Matthias Andree From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 08:59: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 2672916A41F for ; Mon, 29 Aug 2005 08:59:47 +0000 (GMT) (envelope-from mux@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id C9A4643D55 for ; Mon, 29 Aug 2005 08:59:46 +0000 (GMT) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id 72B545C75B; Mon, 29 Aug 2005 01:59:46 -0700 (PDT) Date: Mon, 29 Aug 2005 10:59:46 +0200 From: Maxime Henrion To: Antoine Pelisse Message-ID: <20050829085946.GH12934@elvis.mu.org> References: <2DCDD948-DFEE-4E88-A8AB-6AD268ACFADC@nevada.net.nz> <61c7468305082705071783718c@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <61c7468305082705071783718c@mail.gmail.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org, Philip Murray Subject: Re: Panic (nve) on install with 6.0-BETA3 ISO X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 08:59:47 -0000 Antoine Pelisse wrote: > This has been fixed by mux@ four weeks ago (if_nve.c revision 1.8) but > has not been MFC'd yet (any reason ?) I asked for re@'s approval to MFC this yesterday, and got the approval today, so you should this commit in RELENG_6 later today. The reason why it hadn't been done earlier is that I was looking for feedback from nve(4) users to check that my change really helps, and I've got none for now. If you can confirm that this commit helps, I would really like to know. Cheers, Maxime From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 10:37:57 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 3D8B616A41F; Mon, 29 Aug 2005 10:37:57 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67B4C43D49; Mon, 29 Aug 2005 10:37:54 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id j7TAbkZW088536; Mon, 29 Aug 2005 14:37:47 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id j7TAbjc0088535; Mon, 29 Aug 2005 14:37:45 +0400 (MSD) (envelope-from yar) Date: Mon, 29 Aug 2005 14:37:45 +0400 From: Yar Tikhiy To: Emanuel Strobl Message-ID: <20050829103745.GA78113@comp.chem.msu.su> References: <200508262004.54637@harrymail> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200508262004.54637@harrymail> User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org Subject: Re: cpio and tar are loosing flags (and a panic message without trace) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 10:37:57 -0000 On Fri, Aug 26, 2005 at 08:04:45PM +0200, Emanuel Strobl wrote: > > Then I remember Tim Kienzles great work for bsdtar and all the ACL stuff, > but unfortunately a cvPPzf <> xvpPfz also looses the arch flag :( Would you mind sending a PR on this issue with kientzle@freebsd.org in Cc:? I believe Tim will be interested in it. I've just confirmed myself using not-too-old CURRENT that bsdtar won't restore file flags stored in its own archive: vpc7# tar --version bsdtar 1.02.023, libarchive 1.02.026 Copyright (C) 2003-2005 Tim Kientzle vpc7# sysctl kern.securelevel kern.securelevel: -1 vpc7# mkdir dir vpc7# touch dir/file vpc7# chflags arch,sunlink dir/file vpc7# ls -lo dir/file -rw-r--r-- 1 root staff arch,sunlnk 0 Aug 29 14:35 dir/file vpc7# tar cf dir.tar dir vpc7# hd dir.tar | grep -1 fflags 00000420 35 33 32 36 31 34 39 0a 32 39 20 53 43 48 49 4c |5326149.29 SCHIL| 00000430 59 2e 66 66 6c 61 67 73 3d 61 72 63 68 2c 73 75 |Y.fflags=arch,su| 00000440 6e 6c 6e 6b 0a 31 37 20 53 43 48 49 4c 59 2e 64 |nlnk.17 SCHILY.d| vpc7# mv dir dir.bak vpc7# tar xpf dir.tar vpc7# ls -lo dir/file -rw-r--r-- 1 root staff - 0 Aug 29 14:35 dir/file This is at variance with what the tar(1) manpage says: -p (x mode only) Preserve file permissions. Attempt to restore the full permissions, including owner, file modes, file flags and ACLs, if available, for each item extracted from the archive... I think it might be reasonable to include these details in the PR. -- Yar From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 11:17: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 674C316A41F; Mon, 29 Aug 2005 11:17:36 +0000 (GMT) (envelope-from wouter@mx0.businessconnect.nl) Received: from mx0.businessconnect.nl (mx0.businessconnect.nl [213.206.89.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86D0443D46; Mon, 29 Aug 2005 11:17:35 +0000 (GMT) (envelope-from wouter@mx0.businessconnect.nl) Received: by mx0.businessconnect.nl (Postfix, from userid 1000) id 789B363ED7; Mon, 29 Aug 2005 13:17:33 +0200 (CEST) Date: Mon, 29 Aug 2005 13:17:33 +0200 From: Wouter Prins To: Doug Barton Message-ID: <20050829111733.GA26033@businessconnect.nl> References: <20050828171811.GB7529@businessconnect.nl> <20050828180136.GC7529@businessconnect.nl> <43123A1E.9030700@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="W/nzBZO5zC0uMSeA" Content-Disposition: inline In-Reply-To: <43123A1E.9030700@FreeBSD.org> User-Agent: Mutt/1.5.6i Cc: freebsd-current@freebsd.org Subject: Re: Mergemaster issues in 5.4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 11:17:36 -0000 --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, When i had the issue the following was defined in make.conf: Please note that i dont remember if something was set for OpenSSH (if i rem= ember correctly it was not set). The rest of my makefile contains compiler = options and nothing else has changed. I'm happy it works ok now, so i'll leave this as currently set. Thank you for your help. # To avoid building various parts of the base system: NO_ACPI=3D true # do not build acpiconf(8) and related programs #NO_BOOT=3D true # do not build boot blocks and loader #NO_CVS=3D true # do not build CVS #NO_CXX=3D true # do not build C++ and friends NO_BLUETOOTH=3D true # do not build Bluetooth related stuff #NO_DYNAMICROOT=3Dtrue # do not link /bin and /sbin dynamically #NO_FORTRAN=3D true # do not build g77 and related libraries #NO_GDB=3D true # do not build GDB #NO_GPIB=3D true # do not build GPIB support #NO_I4B=3D true # do not build isdn4bsd package #NO_IPFILTER=3D true # do not build IP Filter package #NO_PF=3D true # do not build PF firewall package #NO_AUTHPF=3D true # do not build and install authpf (setuid/gid) #NO_KERBEROS=3D true # do not build and install Kerberos 5 (KTH Heimdal) #NO_LIB32=3D true # do not build 32-bit versions of libs on 64-bit systems #NO_LPR=3D true # do not build lpr and related programs #NO_MAILWRAPPER=3Dtrue # do not build the mailwrapper(8) MTA selector #NO_MODULES=3D true # do not build modules with the kernel #NO_NETCAT=3D true # do not build netcat NO_NIS=3D true # do not build NIS support and related programs #NO_OBJC=3D true # do not build Objective C support #NO_OPENSSH=3D true # do not build OpenSSH #NO_OPENSSL=3D true # do not build OpenSSL (implies NO_KERBEROS/NO_OPENSSH) #NO_SENDMAIL=3D true # do not build sendmail and related programs #NO_SHAREDOCS=3D true # do not build the 4.4BSD legacy docs #NO_TCSH=3D true # do not build and install /bin/csh (which is tcsh) #NO_TOOLCHAIN=3D true # do not build programs for program development NO_USB=3D true # do not build usbd(8) and related programs NO_VINUM=3D true # do not build Vinum utilities NOATM=3D true # do not build ATM related programs and libraries #NOCRYPT=3D true # do not build any crypto code #NOGAMES=3D true # do not build games (games/ subdir) #NOINET6=3D true # do not build IPv6 related programs and libraries #NOINFO=3D true # do not make or install info files #NOLIBC_R=3D true # do not build libc_r (re-entrant version of libc) #NOLIBPTHREAD=3D true # do not build libpthread (M:N threading library) #NOLIBTHR=3D true # do not build libthr (1:1 threading library) #NOMAN=3D true # do not build manual pages NOPROFILE=3D true # Avoid compiling profiled libraries #NOSHARE=3D true # do not go into the share subdir On Sun, Aug 28, 2005 at 03:26:38PM -0700, Doug Barton wrote: > Wouter Prins wrote: > >Hi, > > > >I have fixed this issue by commenting some profiles in /etc/make.conf > >that i had previously enabled; With NO_PROFILE=3Dtrue and other profiles > >commented out it works fine. >=20 > FYI, you're on the right track with it being something in /etc/make.conf,= =20 > but it's definitely not NO_PROFILE, as I've basically always had that=20 > defined. Based on your error message in your first e-mail I think it's=20 > probably a NO_ option for ssh or crypto, but nothing in the Makefile=20 > indicates an obvious error to me. >=20 > If you can find out which option it is that causes this problem, I would = be=20 > interested in that, since no options should cause the thing to fail=20 > altogether. >=20 > hope this helps, >=20 > Doug >=20 >=20 > --=20 >=20 > This .signature sanitized for your protection >=20 > _______________________________________________ > 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" --=20 Cats are intended to teach us that not everything in nature has a function. -- Garrison Keillor --W/nzBZO5zC0uMSeA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDEu7NMWlPMjAfqRIRAjABAKCdBtOHJ075uisz9yBBTJxp7FTedACfZMpZ N330NfFoccj9dc7RcfFbclQ= =06tK -----END PGP SIGNATURE----- --W/nzBZO5zC0uMSeA-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 28 13:26: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 654F416A41F for ; Sun, 28 Aug 2005 13:26:21 +0000 (GMT) (envelope-from mi@blue.virtual-estates.net) Received: from mail25.sea5.speakeasy.net (mail25.sea5.speakeasy.net [69.17.117.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 964D643D49 for ; Sun, 28 Aug 2005 13:26:19 +0000 (GMT) (envelope-from mi@blue.virtual-estates.net) Received: (qmail 20549 invoked from network); 28 Aug 2005 13:26:18 -0000 Received: from aldan.algebra.com (HELO blue.virtual-estates.net) ([216.254.65.224]) (envelope-sender ) by mail25.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 28 Aug 2005 13:26:17 -0000 Received: from blue.virtual-estates.net (blue [127.0.0.1]) by blue.virtual-estates.net (8.13.3/8.13.1) with ESMTP id j7SDQG0T073330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Aug 2005 09:26:16 -0400 (EDT) (envelope-from mi@blue.virtual-estates.net) Received: (from mi@localhost) by blue.virtual-estates.net (8.13.3/8.13.1/Submit) id j7SDQGfc073329; Sun, 28 Aug 2005 09:26:16 -0400 (EDT) (envelope-from mi) From: "Mikhail T." Message-Id: <200508281326.j7SDQGfc073329@blue.virtual-estates.net> To: current@FreeBSD.org Date: Sun, 28 Aug 2005 09:26:16 -0400 (EDT) X-Face: %UW#n0|w>ydeGt/b@1-.UFP=K^~-:0f#O:D7w hJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2005 13:26:21 -0000 --ELM1125235576-70046-0_ Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Hello! I'm installing 6.0-BETA3 from the boot-only CD-image on an old Pentium-MMX laptop. The processor runs at 267MHz and there is 160Mb of RAM in it (dmesg attached). Here is my "report" so far -- various things some of them unrelated: . Something is wrong with the ed-driver (in my case -- Kingston's KNE-PC2T, FCC ID L40WST200). Kernel reports being unable to do something with pccard1, then reports ed1: .... and hangs. I let it wait for an hour and it never continued booting. I'll try to investigate, when I'm done installing. The card worked just fine in a newer Pentium-II laptop under FreeBSD-5.x . So I switched to the wireless card. This worked flawlessly except it bound -- without asking me for any WiFi parameters -- to my neighbor's unprotected access point. Mine is protected, but sysinstall did not give me a chance to enter the network name nor the password -- I agreed to try DHCP and there it was. This can land someone into a legal trouble... . WITNESS et. al suck -- this is the first time in my life, when an Internet install was CPU-bound. The chunks would start arriving at 300Kb/second, but the extraction to disk would throttle things down to about 90-110Kb/second for regular distributions and 27Kb/second for the ports (lots of small files). Once the base install was about 60% through, I was able to start systat the "emergency shell" (ALT-F4) and saw that, indeed, the system part of the CPU would run at sustained 80-90%. I know, what WITNESS is for, but the next BETA should, probably, come with it disabled -- there may be something triggered by its absence. . Dangerously dedicated mode did not work -- things installed, but the BIOS would not boot (Read Error). . Trying to create 4 separate entries (ad0s1a for /, ad0s2b for swap, ad0s3x for /var, and ad0s4x for /home) did not work either -- things installed, but would not boot complaining about "Invalid Partition Table". It was, indeed, invalid, when I rebooted from the CD again and went into Partition part of the install. In addition to the entries I created, there were duplicates with names like ad0cs3 or something... . The third install succeeded with non-dangerous full disk and separate file-systems and swap on ad0s1a, b, e, and d. . Trying to cvs-checkout src from anoncvs.FreeBSD.org over ssh would not work. Despite my specifying -R (for read-only), the server kept complaining about being unable to write some file. . Non-anonymous read-only cvs-checkout from ncvs succeeded, but exposed a lock-order reversal complaint (see the attached dmesg). . Should not wlan be dragged into the kernel _automatically_, when its dependents (like wi) are selected? Kernel would not link without it, should not config do something about it? . World-rebuild is still running (with the attached make.conf) -- about 8 hours already. WITNESS/INVARIANTS, probably, have something to do with it too -- the disk is, obviously, not fast, but the average load is firmly at 1.0 (or slightly above), meaning that kernel keeps the CPU busy. That's it so far. Thanks for your time. -mi --ELM1125235576-70046-0_ Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Disposition: attachment; filename=60-dmesg Content-Description: 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-BETA3 #0: Mon Aug 22 22:59:46 UTC 2005 root@harlow.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Pentium/P55C (quarter-micron) (267.27-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x581 Stepping = 1 Features=0x8001bf real memory = 167772160 (160 MB) avail memory = 150335488 (143 MB) Intel Pentium detected, installing workaround for F00F bug npx0: [FAST] npx0: on motherboard npx0: INT 16 interface cpu0 on motherboard pcib0: pcibus 0 on motherboard pir0: on motherboard pci0: on pcib0 isab0: at device 1.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfcf0-0xfcff at device 1.1 on pci0 ata0: on atapci0 ata1: on atapci0 uhci0: port 0xfcc0-0xfcdf at device 1.2 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 piix0: port 0x2180-0x218f at device 1.3 on pci0 Timecounter "PIIX" frequency 3579545 Hz quality 0 pci0: at device 2.0 (no driver attached) cbb0: at device 10.0 on pci0 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb1: at device 10.1 on pci0 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcbfff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model GlidePoint, device ID 0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A 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 unknown: can't assign resources (memory) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (irq) unknown: can't assign resources (port) unknown: can't assign resources (port) ppc1: parallel port not found. Timecounter "TSC" frequency 267274860 Hz quality 800 Timecounters tick every 1.000 msec md0: Preloaded image 4423680 bytes at 0xc0a80378 ad0: 7815MB at ata0-master UDMA33 acd0: CDROM at ata1-master PIO3 wi0: at port 0x100-0x13f irq 9 function 0 config 1 on pccard1 wi0: using Lucent Technologies, WaveLAN/IEEE wi0: Lucent Firmware: Station (8.72.1) wi0: Ethernet address: 00:02:2d:50:30:49 Trying to mount root from ufs:/dev/md0 lock order reversal 1st 0xc097ca00 UMA lock (UMA lock) @ /usr/src/sys/vm/uma_core.c:1494 2nd 0xc1460144 system map (system map) @ /usr/src/sys/vm/vm_map.c:2317 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c0931ab8,c0931bf8,c08bc1c4) at kdb_backtrace+0x29 witness_checkorder(c1460144,9,c087273f,90d) at witness_checkorder+0x564 _mtx_lock_flags(c1460144,0,c087273f,90d) at _mtx_lock_flags+0x5b _vm_map_lock(c14600c0,c087273f,90d) at _vm_map_lock+0x26 vm_map_remove(c14600c0,c1fdc000,c1fdd000,c9714c0c,c077fba9) at vm_map_remove+0x1f kmem_free(c14600c0,c1fdc000,1000,c9714c3c,c077f556) at kmem_free+0x25 page_free(c1fdc000,1000,2) at page_free+0x29 zone_drain(c143f1e0) at zone_drain+0x26a zone_foreach(c077f2ec,c9714cec,c07914d7,c9714c74,246) at zone_foreach+0x37 uma_reclaim(c9714c74,246,0,c9714c80,c062a4f5) at uma_reclaim+0x12 vm_pageout_scan(0,c097ce60,0,c0873c2c,604) at vm_pageout_scan+0x103 vm_pageout(0,c9714d38,0,c079232c,0) at vm_pageout+0x2c3 fork_exit(c079232c,0,c9714d38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xc9714d6c, ebp = 0 --- Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...5 2 1 1 0 0 done All buffers synced. unmount of /mnt/dev failed (BUSY) unmount of /dev failed (BUSY) Uptime: 39m8s Rebooting... 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-BETA3 #0: Mon Aug 22 22:59:46 UTC 2005 root@harlow.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Pentium/P55C (quarter-micron) (267.27-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x581 Stepping = 1 Features=0x8001bf real memory = 167772160 (160 MB) avail memory = 150335488 (143 MB) Intel Pentium detected, installing workaround for F00F bug npx0: [FAST] npx0: on motherboard npx0: INT 16 interface cpu0 on motherboard pcib0: pcibus 0 on motherboard pir0: on motherboard pci0: on pcib0 isab0: at device 1.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfcf0-0xfcff at device 1.1 on pci0 ata0: on atapci0 ata1: on atapci0 uhci0: port 0xfcc0-0xfcdf at device 1.2 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 piix0: port 0x2180-0x218f at device 1.3 on pci0 Timecounter "PIIX" frequency 3579545 Hz quality 0 pci0: at device 2.0 (no driver attached) cbb0: at device 10.0 on pci0 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb1: at device 10.1 on pci0 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcbfff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model GlidePoint, device ID 0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A 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 unknown: can't assign resources (memory) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (irq) unknown: can't assign resources (port) unknown: can't assign resources (port) ppc1: parallel port not found. Timecounter "TSC" frequency 267274344 Hz quality 800 Timecounters tick every 1.000 msec md0: Preloaded image 4423680 bytes at 0xc0a80378 ad0: 7815MB at ata0-master UDMA33 acd0: CDROM at ata1-master PIO3 wi0: at port 0x100-0x13f irq 9 function 0 config 1 on pccard1 wi0: using Lucent Technologies, WaveLAN/IEEE wi0: Lucent Firmware: Station (8.72.1) wi0: Ethernet address: 00:02:2d:50:30:49 Trying to mount root from ufs:/dev/md0 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...1 0 done All buffers synced. unmount of /dev failed (BUSY) Uptime: 6m23s Rebooting... 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-BETA3 #0: Mon Aug 22 22:59:46 UTC 2005 root@harlow.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Pentium/P55C (quarter-micron) (267.27-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x581 Stepping = 1 Features=0x8001bf real memory = 167772160 (160 MB) avail memory = 150335488 (143 MB) Intel Pentium detected, installing workaround for F00F bug npx0: [FAST] npx0: on motherboard npx0: INT 16 interface cpu0 on motherboard pcib0: pcibus 0 on motherboard pir0: on motherboard pci0: on pcib0 isab0: at device 1.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfcf0-0xfcff at device 1.1 on pci0 ata0: on atapci0 ata1: on atapci0 uhci0: port 0xfcc0-0xfcdf at device 1.2 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 piix0: port 0x2180-0x218f at device 1.3 on pci0 Timecounter "PIIX" frequency 3579545 Hz quality 0 pci0: at device 2.0 (no driver attached) cbb0: at device 10.0 on pci0 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb1: at device 10.1 on pci0 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcbfff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model GlidePoint, device ID 0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A 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 unknown: can't assign resources (memory) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (irq) unknown: can't assign resources (port) unknown: can't assign resources (port) ppc1: parallel port not found. Timecounter "TSC" frequency 267274632 Hz quality 800 Timecounters tick every 1.000 msec md0: Preloaded image 4423680 bytes at 0xc0a80378 ad0: 7815MB at ata0-master UDMA33 acd0: CDROM at ata1-master PIO3 wi0: at port 0x100-0x13f irq 9 function 0 config 1 on pccard1 wi0: using Lucent Technologies, WaveLAN/IEEE wi0: Lucent Firmware: Station (8.72.1) wi0: Ethernet address: 00:02:2d:50:30:49 Trying to mount root from ufs:/dev/md0 lock order reversal 1st 0xc097ca00 UMA lock (UMA lock) @ /usr/src/sys/vm/uma_core.c:1494 2nd 0xc1460144 system map (system map) @ /usr/src/sys/vm/vm_map.c:2317 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c0931ab8,c0931bf8,c08bc1c4) at kdb_backtrace+0x29 witness_checkorder(c1460144,9,c087273f,90d) at witness_checkorder+0x564 _mtx_lock_flags(c1460144,0,c087273f,90d) at _mtx_lock_flags+0x5b _vm_map_lock(c14600c0,c087273f,90d) at _vm_map_lock+0x26 vm_map_remove(c14600c0,c20b0000,c20b1000,c9714c0c,c077fba9) at vm_map_remove+0x1f kmem_free(c14600c0,c20b0000,1000,c9714c3c,c077f556) at kmem_free+0x25 page_free(c20b0000,1000,2) at page_free+0x29 zone_drain(c143f1e0) at zone_drain+0x26a zone_foreach(c077f2ec,c9714cec,c07914d7,c9714c74,246) at zone_foreach+0x37 uma_reclaim(c9714c74,246,0,c9714c80,c062a4f5) at uma_reclaim+0x12 vm_pageout_scan(0,c097ce60,0,c0873c2c,604) at vm_pageout_scan+0x103 vm_pageout(0,c9714d38,0,c079232c,0) at vm_pageout+0x2c3 fork_exit(c079232c,0,c9714d38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xc9714d6c, ebp = 0 --- Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...1 2 1 1 1 0 0 0 done All buffers synced. unmount of /dev failed (BUSY) Uptime: 16m5s Rebooting... 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-BETA3 #0: Mon Aug 22 22:59:46 UTC 2005 root@harlow.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Pentium/P55C (quarter-micron) (267.27-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x581 Stepping = 1 Features=0x8001bf real memory = 167772160 (160 MB) avail memory = 154517504 (147 MB) Intel Pentium detected, installing workaround for F00F bug npx0: [FAST] npx0: on motherboard npx0: INT 16 interface cpu0 on motherboard pcib0: pcibus 0 on motherboard pir0: on motherboard pci0: on pcib0 isab0: at device 1.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfcf0-0xfcff at device 1.1 on pci0 ata0: on atapci0 ata1: on atapci0 uhci0: port 0xfcc0-0xfcdf at device 1.2 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 piix0: port 0x2180-0x218f at device 1.3 on pci0 Timecounter "PIIX" frequency 3579545 Hz quality 0 pci0: at device 2.0 (no driver attached) cbb0: at device 10.0 on pci0 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb1: at device 10.1 on pci0 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcbfff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model GlidePoint, device ID 0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A 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 unknown: can't assign resources (memory) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (irq) unknown: can't assign resources (port) unknown: can't assign resources (port) ppc1: parallel port not found. Timecounter "TSC" frequency 267274240 Hz quality 800 Timecounters tick every 1.000 msec ad0: 7815MB at ata0-master UDMA33 acd0: CDROM at ata1-master PIO3 wi0: at port 0x100-0x13f irq 9 function 0 config 1 on pccard1 wi0: using Lucent Technologies, WaveLAN/IEEE wi0: Lucent Firmware: Station (8.72.1) wi0: Ethernet address: 00:02:2d:50:30:49 Trying to mount root from ufs:/dev/ad0s1a lock order reversal 1st 0xc097ca00 UMA lock (UMA lock) @ /usr/src/sys/vm/uma_core.c:1494 2nd 0xc1060144 system map (system map) @ /usr/src/sys/vm/vm_map.c:2317 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c0931ab8,c0931bf8,c08bc1c4) at kdb_backtrace+0x29 witness_checkorder(c1060144,9,c087273f,90d) at witness_checkorder+0x564 _mtx_lock_flags(c1060144,0,c087273f,90d) at _mtx_lock_flags+0x5b _vm_map_lock(c10600c0,c087273f,90d) at _vm_map_lock+0x26 vm_map_remove(c10600c0,c18d4000,c18d5000,c9523c0c,c077fba9) at vm_map_remove+0x1f kmem_free(c10600c0,c18d4000,1000,c9523c3c,c077f556) at kmem_free+0x25 page_free(c18d4000,1000,2) at page_free+0x29 zone_drain(c1042b40) at zone_drain+0x26a zone_foreach(c077f2ec,c9523cec,c07914d7,c9523c74,246) at zone_foreach+0x37 uma_reclaim(c9523c74,246,0,c9523c80,c062a4f5) at uma_reclaim+0x12 vm_pageout_scan(0,c097ce60,0,c0873c2c,604) at vm_pageout_scan+0x103 vm_pageout(0,c9523d38,0,c079232c,0) at vm_pageout+0x2c3 fork_exit(c079232c,0,c9523d38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xc9523d6c, ebp = 0 --- stray irq7 stray irq7 --ELM1125235576-70046-0_ Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-Disposition: attachment; filename=make.conf Content-Description: CPUTYPE= pentium-mmx KERNCONF= MICRON .for o in IPFILTER MAILWRAPPER NIS PF ACPI BLUETOOTH FORTRAN I4B INET6 \ MODULES OBJS PROFILE SHAREDOCS HTML NO_$o= yes .endfor MAKE_IDEA= yes ENABLE_SUID_K5SU=yes WITH_BIND_LIBS= yes TOP_TABLE_SIZE= 41 DOC_LANG= en_US.ISO8859-1 uk_UA.KOI8-U ENABLE_WPA_SUPPLICANT_EAPOL=yes --ELM1125235576-70046-0_-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 03:53: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 1B51816A41F for ; Mon, 29 Aug 2005 03:53:44 +0000 (GMT) (envelope-from ebaroud@yahoo.com) Received: from web30514.mail.mud.yahoo.com (web30514.mail.mud.yahoo.com [68.142.201.242]) by mx1.FreeBSD.org (Postfix) with SMTP id 98BD443D45 for ; Mon, 29 Aug 2005 03:53:43 +0000 (GMT) (envelope-from ebaroud@yahoo.com) Received: (qmail 66350 invoked by uid 60001); 29 Aug 2005 03:53:43 -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=0zr/NTzmL8nWB1wVgcwDXMyRZ5YfOqRBI/PQlPO9buoo8vTH0K3GA42x0lcCcrpMKPJPs/5giiOcFd1DyY9GXFgDPQoW9zG8dgG/FjSBHza6K6grryOQuZRQ/Y9oPngJ4qolWd2838uHuwt4MVoy7ul8n80W5akHYrvTj09iquI= ; Message-ID: <20050829035343.66348.qmail@web30514.mail.mud.yahoo.com> Received: from [24.202.186.231] by web30514.mail.mud.yahoo.com via HTTP; Sun, 28 Aug 2005 23:53:42 EDT Date: Sun, 28 Aug 2005 23:53:42 -0400 (EDT) From: Edmond Baroud To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Mon, 29 Aug 2005 11:48:14 +0000 Subject: WPA: Failed to set PTK to the 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, 29 Aug 2005 03:53:44 -0000 Hi all, I'm a long time desktop FreeBSD user (almost 7 years) and now the time has come to install it on a laptop I got from the job. Didn't have the choice to pick an Intel card so my laptop came with the 'Dell TrueMobile 1450 Dual Band WLAN Mini-PCI Card'. HW: Dell Latitude D610 OS: 7-current custom kernel. I used ndisgen with the bcmwl5a.inf and bcmwl5.sys from various release of the driver but still can't get WPA to work and after some digging I looked at the net80211 layer source code and the error message I'm getting is coming fron there. I don't know if it's a bug in that module or an incompatibility between the layer and the ndis API. When I run the wpa_supplicant without initiating an 'ifconfig ndis0 ssid 'myssid' authmode wpa channel 1 up' the supplicant doesn't seem to communicate with the AP, so I get to reproduce my test in the following sequence: I have all the wlan* modules compiled in the kernel. -8<--cut--8<---cut--8<- normal boot cypher#kldload ndis cypher#kldload bcmwl5_sys ndis0: mem 0xdfcfe000-0xdfcfffff irq 17 at device 3.0 on pci3 ndis0: NDIS API version: 5.0 ndis0: Ethernet address: 00:0b:7d:27:30:81 cypher# ifconfig ndis0 ssid 'myssid' authmode wpa channel 1 up cypher# wpa_supplicant -i ndis0 -c /etc/wpa_supplicant.conf -ddd Initializing interface 'ndis0' conf '/etc/wpa_supplicant.conf' driver 'default' Configuration file '/etc/wpa_supplicant.conf' -> '/etc/wpa_supplicant.conf' Reading configuration file '/etc/wpa_supplicant.conf' ctrl_interface='/var/run/wpa_supplicant' ctrl_interface_group=0 Line: 7 - start of a new network block ssid - hexdump_ascii(len=6): 6d 73 73 69 64 myssid proto: 0x1 PSK (ASCII passphrase) - hexdump_ascii(len=15): [REMOVED] PSK (from passphrase) - hexdump(len=32): [REMOVED] Priority group 0 id=0 ssid='myssid' Initializing interface (2) 'ndis0' Own MAC address: 00:0b:7d:27:30:81 wpa_driver_bsd_set_wpa: enabled=1 wpa_driver_bsd_set_wpa_internal: wpa=3 privacy=1 wpa_driver_bsd_del_key: keyidx=0 wpa_driver_bsd_del_key: keyidx=1 wpa_driver_bsd_del_key: keyidx=2 wpa_driver_bsd_del_key: keyidx=3 wpa_driver_bsd_set_countermeasures: enabled=0 wpa_driver_bsd_set_drop_unencrypted: enabled=1 Setting scan request: 0 sec 100000 usec Starting AP scan (broadcast SSID) Received 0 bytes of scan results (1 BSSes) Scan results: 1 Selecting BSS from priority group 0 0: 00:09:5b:f9:b6:04 ssid='myssid' wpa_ie_len=24 rsn_ie_len=0 selected Trying to associate with 00:09:5b:f9:b6:04 (SSID='myssid' freq=2412 MHz) Cancelling scan request Automatic auth_alg selection: 0x1 WPA: using IEEE 802.11i/D3.0 WPA: Selected cipher suites: group 8 pairwise 8 key_mgmt 2 WPA: using GTK TKIP WPA: using PTK TKIP WPA: using KEY_MGMT WPA-PSK WPA: Own WPA IE - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 02 01 00 00 50 f2 02 No keys have been configured - skip key clearing wpa_driver_bsd_set_drop_unencrypted: enabled=1 wpa_driver_bsd_associate: ssid 'myssid' wpa ie len 24 pairwise 2 group 2 key mgmt 1 wpa_driver_bsd_associate: set PRIVACY 1 Setting authentication timeout: 5 sec 0 usec RX EAPOL from 00:09:5b:f9:b6:04 RX EAPOL - hexdump(len=99): 01 03 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 01 35 27 ab 37 5f 76 d8 76 78 39 43 22 40 01 7f 2c d1 ae 7d b4 b0 6f 88 aa f0 cf 54 66 5c 48 b5 c6 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Setting authentication timeout: 10 sec 0 usec IEEE 802.1X RX: version=1 type=3 length=95 EAPOL-Key type=254 WPA: RX EAPOL-Key - hexdump(len=99): 01 03 00 5f fe 00 89 00 20 00 00 00 00 00 00 00 01 35 27 ab 37 5f 76 d8 76 78 39 43 22 40 01 7f 2c d1 ae 7d b4 b0 6f 88 aa f0 cf 54 66 5c 48 b5 c6 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 WPA: RX message 1 of 4-Way Handshake from 00:09:5b:f9:b6:04 (ver=1) WPA: Renewed SNonce - hexdump(len=32): 7c 11 51 60 d3 4e 87 6b 40 73 ed 50 33 9d 10 05 95 0d 72 23 a4 21 db f5 b2 45 40 47 44 35 a5 0a WPA: PMK - hexdump(len=32): [REMOVED] WPA: PTK - hexdump(len=64): [REMOVED] WPA: EAPOL-Key MIC - hexdump(len=16): 3b 08 8a 26 36 3c 57 7c a0 90 77 07 40 84 65 47 WPA: Sending EAPOL-Key 2/4 WPA: TX EAPOL-Key 2/4 - hexdump(len=137): 00 09 5b f9 b6 04 00 0b 7d 27 30 81 88 8e 01 03 00 77 fe 01 09 00 20 00 00 00 00 00 00 00 01 7c 11 51 60 d3 4e 87 6b 40 73 ed 50 33 9d 10 05 95 0d 72 23 a4 21 db f5 b2 45 40 47 44 35 a5 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3b 08 8a 26 36 3c 57 7c a0 90 77 07 40 84 65 47 00 18 dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 02 01 00 00 50 f2 02 RX EAPOL from 00:09:5b:f9:b6:04 RX EAPOL - hexdump(len=123): 01 03 00 77 fe 01 c9 00 20 00 00 00 00 00 00 00 02 35 27 ab 37 5f 76 d8 76 78 39 43 22 40 01 7f 2c d1 ae 7d b4 b0 6f 88 aa f0 cf 54 66 5c 48 b5 c6 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 33 4c df 12 27 d1 21 a2 43 e8 92 72 07 41 2a f4 00 18 dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 02 01 00 00 50 f2 02 IEEE 802.1X RX: version=1 type=3 length=119 EAPOL-Key type=254 WPA: RX EAPOL-Key - hexdump(len=123): 01 03 00 77 fe 01 c9 00 20 00 00 00 00 00 00 00 02 35 27 ab 37 5f 76 d8 76 78 39 43 22 40 01 7f 2c d1 ae 7d b4 b0 6f 88 aa f0 cf 54 66 5c 48 b5 c6 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 33 4c df 12 27 d1 21 a2 43 e8 92 72 07 41 2a f4 00 18 dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 02 01 00 00 50 f2 02 WPA: RX message 3 of 4-Way Handshake from 00:09:5b:f9:b6:04 (ver=1) WPA: IE KeyData - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 02 01 00 00 50 f2 02 WPA: Sending EAPOL-Key 4/4 WPA: TX EAPOL-Key 4/4 - hexdump(len=113): 00 09 5b f9 b6 04 00 0b 7d 27 30 81 88 8e 01 03 00 5f fe 01 09 00 20 00 00 00 00 00 00 00 02 7c 11 51 60 d3 4e 87 6b 40 73 ed 50 33 9d 10 05 95 0d 72 23 a4 21 db f5 b2 45 40 47 44 35 a5 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 27 b8 2e 54 25 a9 e0 ba 21 72 28 ac 16 37 7d 24 00 00 WPA: Installing PTK to the driver. WPA: RSC - hexdump(len=6): 00 00 00 00 00 00 wpa_driver_bsd_set_key: alg=TKIP addr=00:09:5b:f9:b6:04 key_idx=0 set_tx=1 seq_len=6 key_len=32 ioctl[SIOCS80211, op 19, len 60]: Operation not supported by device WPA: Failed to set PTK to the driver. -8<--cut--8<---cut--8<- Any ideas? Please CC me I'm not subscribed to the list. I'll be glad to do some debugging to help fix that if it's a bug. Cheers, -Ed __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 12:18:14 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 9B39516A41F for ; Mon, 29 Aug 2005 12:18:14 +0000 (GMT) (envelope-from shigeru@iij.ad.jp) Received: from omgo.iij.ad.jp (omgo.iij.ad.jp [202.232.30.157]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FAC643D48 for ; Mon, 29 Aug 2005 12:18:13 +0000 (GMT) (envelope-from shigeru@iij.ad.jp) Received: OTM-MO id j7TCICqn016998; Mon, 29 Aug 2005 21:18:12 +0900 (JST) DomainKey-Signature: a=rsa-sha1; s=omgo; d=iij.ad.jp; c=nofws; q=dns; h=date:message-id:to:from:x-mailer:mime-version: content-type:content-transfer-encoding; b=fss9KSyP9bEwCbnIXpTc+75RVeRPSyKlopuYEp+iyWX/L1z2mEFCK+rADQVVB8jLo 2fpSQKUT/t8aNLI+7G1ZQ== Received: OTM-MIX0 id j7TCICNM025115; Mon, 29 Aug 2005 21:18:12 +0900 (JST) Received: from localhost (mercury.iij.ad.jp [192.168.184.90]) by jc-smtp.iij.ad.jp (JC-SMTP/jc-smtp) id j7TCIBEK013483 for ; Mon, 29 Aug 2005 21:18:11 +0900 (JST) Date: Mon, 29 Aug 2005 21:18:11 +0900 (JST) Message-Id: <20050829.211811.74756443.shigeru@iij.ad.jp> To: freebsd-current@freebsd.org From: Yamamoto Shigeru X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Mon_Aug_29_21:18:11_2005_475)--" Content-Transfer-Encoding: 7bit Subject: patch for zoneinfo to make 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, 29 Aug 2005 12:18:14 -0000 ----Next_Part(Mon_Aug_29_21:18:11_2005_475)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, all, In @src/share/zoneinfo/northamerica Rev. 1.26, 'America/Indianapolis' is changed to 'America/Indiana/Indianapolis'. So some fixes are needed for @src/share/zoneinfo/{northamerica,systemv}. #These fiexes are needed at 'make release'. I create a small patch and send it. Thanks, ------- YAMAMOTO Shigeru ----Next_Part(Mon_Aug_29_21:18:11_2005_475)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="zoneinfo.diff" Index: share/zoneinfo/northamerica =================================================================== RCS file: /share/cvsup/FreeBSD/current/usr/src/share/zoneinfo/northamerica,v retrieving revision 1.26 diff -u -r1.26 northamerica --- share/zoneinfo/northamerica 26 Aug 2005 18:46:27 -0000 1.26 +++ share/zoneinfo/northamerica 29 Aug 2005 09:30:11 -0000 @@ -723,7 +723,7 @@ Link America/Chicago CST6CDT Link America/Denver MST7MDT Link America/Los_Angeles PST8PDT -Link America/Indianapolis EST +Link America/Indiana/Indianapolis EST Link America/Phoenix MST Link Pacific/Honolulu HST Index: share/zoneinfo/systemv =================================================================== RCS file: /share/cvsup/FreeBSD/current/usr/src/share/zoneinfo/systemv,v retrieving revision 1.1.2.2 diff -u -r1.1.2.2 systemv --- share/zoneinfo/systemv 6 Apr 2001 16:43:21 -0000 1.1.2.2 +++ share/zoneinfo/systemv 29 Aug 2005 09:31:34 -0000 @@ -42,7 +42,7 @@ Link America/Los_Angeles SystemV/PST8PDT Link America/Anchorage SystemV/YST9YDT Link America/Puerto_Rico SystemV/AST4 -Link America/Indianapolis SystemV/EST5 +Link America/Indiana/Indianapolis SystemV/EST5 Link America/Regina SystemV/CST6 Link America/Phoenix SystemV/MST7 Link Pacific/Pitcairn SystemV/PST8 ----Next_Part(Mon_Aug_29_21:18:11_2005_475)---- From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 13:26: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 B163C16A41F for ; Mon, 29 Aug 2005 13:26:17 +0000 (GMT) (envelope-from stb@lassitu.de) Received: from schlepper.zs64.net (schlepper.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1933343D4C for ; Mon, 29 Aug 2005 13:26:16 +0000 (GMT) (envelope-from stb@lassitu.de) Received: from [IPv6:::1] (schlepper [212.12.50.230]) by schlepper.zs64.net (8.13.3/8.12.9) with ESMTP id j7TDPrRS020266; Mon, 29 Aug 2005 15:25:55 +0200 (CEST) (envelope-from stb@lassitu.de) In-Reply-To: <200508281326.j7SDQGfc073329@blue.virtual-estates.net> References: <200508281326.j7SDQGfc073329@blue.virtual-estates.net> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8371950F-18A4-459B-8EAA-934E0FD91571@lassitu.de> Content-Transfer-Encoding: 7bit From: Stefan Bethke Date: Mon, 29 Aug 2005 15:25:52 +0200 To: "Mikhail T." X-Mailer: Apple Mail (2.734) Cc: current@freebsd.org Subject: Re: installing 6.0-BETA3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 13:26:17 -0000 Am 28.08.2005 um 15:26 schrieb Mikhail T.: > . Trying to cvs-checkout src from anoncvs.FreeBSD.org over ssh > would not work. Despite my specifying -R (for read-only), the > server kept complaining about being unable to write some file. That's because the *server* needs to be in read-only mode. I'd figure the server operator for anoncvs.freebsd.org should set it up like that, but for any random server, you need to specify CVS_SERVER="cvs -R", as in $ env CVS_SERVER="cvs -R" cvs co -dP src Stefan -- Stefan Bethke Fon +49 170 346 0140 From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 13:42: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 AC46C16A41F; Mon, 29 Aug 2005 13:42:44 +0000 (GMT) (envelope-from markus@freebsd.org) Received: from mailout10.sul.t-online.com (mailout10.sul.t-online.com [194.25.134.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF9DE43D55; Mon, 29 Aug 2005 13:42:43 +0000 (GMT) (envelope-from markus@freebsd.org) Received: from fwd35.aul.t-online.de by mailout10.sul.t-online.com with smtp id 1E9juM-0001HI-00; Mon, 29 Aug 2005 15:42:42 +0200 Received: from ramses.kicks-ass.net (TEOJUwZlQe+MkitaD8HMKGQznimjkLhSngv0tjjAMDm+qBb-kbvc4O@[80.143.238.133]) by fwd35.sul.t-online.de with esmtp id 1E9juC-12UnD60; Mon, 29 Aug 2005 15:42:32 +0200 Received: from cheops.phoenix (cheops.phoenix [192.168.1.3]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ramses.kicks-ass.net (Postfix) with ESMTP id 39FE0B83E; Mon, 29 Aug 2005 15:42:17 +0200 (CEST) From: Markus Brueffer To: freebsd-current@freebsd.org Date: Mon, 29 Aug 2005 15:42:38 +0200 User-Agent: KMail/1.8.1 References: <200508101658.09719.jhb@FreeBSD.org> <20050812121551.GA888@unixpages.org> <200508120916.14378.jhb@FreeBSD.org> In-Reply-To: <200508120916.14378.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3756378.GDYTsVmUzb"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200508291542.46098.markus@freebsd.org> X-ID: TEOJUwZlQe+MkitaD8HMKGQznimjkLhSngv0tjjAMDm+qBb-kbvc4O@t-dialin.net X-TOI-MSGID: da4b040a-bf33-4188-bcad-73801b22db85 Cc: Subject: Re: Locking fixes for sf(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 13:42:44 -0000 --nextPart3756378.GDYTsVmUzb Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi John, On Friday 12 August 2005 15:16, John Baldwin wrote: > On Friday 12 August 2005 08:15 am, Christian Brueffer wrote: > > On Thu, Aug 11, 2005 at 11:24:10AM -0400, John Baldwin wrote: > > > On Thursday 11 August 2005 11:00 am, Christian Brueffer wrote: > > > > On Wed, Aug 10, 2005 at 04:58:09PM -0400, John Baldwin wrote: > > > > > I've fixed up the locking in sf(4) but do not have the hardware > > > > > to test the changes. Can someone please test these patches?=20 > > > > > Thanks. > > > > > > > > > > http://www.freebsd.org/~jhb/patches/sf_locking.patch > > > > > > > > Results in a "recursed on non-recursive mutex" panic.=20 > > > > Unfortunately the dump looks busted, I'll get a good one tomorrow > > > > (can also test the my(4) patch then). > > > > > > Ok. If you could just get the backtrace from ddb that would probably > > > be sufficient. Thanks for testing! > > > > panic: _mtx_lock_sleep: recursed on non-recursive mutex sf0 @ > > /usr/home/build/src/sys/modules/sf/.. > > /../pci/if_sf.c:477 > > > > CPUID =3D 1 > > KDB: enter: panic > > [thread pid 220 tid 100072 ] > > Stopped at kdb_enter+0x30: leave > > db> tr > > Tracing pid 220 tid 100072 td 0xc1d63480 > > kdb_enter(c079421b,1,c0793681,d8945ab4,c1d63480) at kdb_enter+0x30 > > panic(c0793681,c1ad6ab0,c08ed18a,1dd,1dd) at panic+0x14e > > _mtx_lock_sleep(c1ac3c4c,c1d63480,0,c08ed18a,1dd) at > > _mtx_lock_sleep+0x47 _mtx_lock_flags(c1ac3c4c,0,c08ed18a,1dd,0) at > > _mtx_lock_flags+0x9c > > sf_ifmedia_upd(c1adb800,1000,c08ed18a,4b7,c1ac3c4c) at > > sf_ifmedia_upd+0x3e sf_init_locked(c1ac3c4c,0,c08ed18a,4aa,c1adb800) at > > sf_init_locked+0x4bc sf_init(c1ac3c00,740,c07a8534,8020690c,c1ac3c00) > > at sf_init+0x39 ether_ioctl(c1adb800,8020690c,c1d67e00,c05a7cd1,0) at > > ether_ioctl+0x67 sf_ioctl(c1adb800,8020690c,c1d67e00,100,1) at > > sf_ioctl+0xbb > > in_ifinit(c1adb800,c1d67e00,c1cef3d0,0,1) at in_ifinit+0x208 > > in_control(c1dfcde8,8040691a,c1cef3c0,c1adb800,c1d63480) at > > in_control+0x986 ifioctl(c1dfcde8,8040691a,c1cef3c0,c1d63480,2) at > > ifioctl+0x1cd > > soo_ioctl(c1d59d80,8040691a,c1cef3c0,c19dca80,c1d63480) at > > soo_ioctl+0x3ef ioctl(c1d63480,d8945d04,c,422,3) at ioctl+0x45d > > syscall(3b,3b,3b,80beac0,1) at syscall+0x2c0 > > Xint0x80_syscall() at Xint0x80_syscall+0x1f > > --- syscall (54, FreeBSD ELF32, ioctl), eip =3D 0x8055473, esp =3D > > 0xbfbfe5fc, ebp =3D 0xbfbfee68 --- > > Ah, ok, thanks. This is the first driver I've seen that calls its > ifmedia_update routine internally. I'll fix this and update the patch. > Thanks! I'm getting this LOR with the latest if_sf.c in RELENG_6: lock order reversal 1st 0xc1b0d7cc sf0 (network driver) @ /usr/src/sys/pci/if_sf.c:1201 2nd 0xc07a49e0 Giant (Giant) @ /usr/src/sys/kern/kern_poll.c:460 KDB: stack backtrace: kdb_backtrace(c0742772,c07a49e0,c074dd5f,c074dd5f,c073e09e) at=20 kdb_backtrace+0x2e witness_checkorder(c07a49e0,9,c073e09e,1cc,18a) at witness_checkorder+0x6c3 _mtx_lock_flags(c07a49e0,0,c073e09e,1cc,c1b0d780) at _mtx_lock_flags+0x8a ether_poll_deregister(c1af3000,0,c074def0,5c3,c1af3000) at=20 ether_poll_deregister+0x2e sf_stop(c1b0d780,1,c074def0,4be,c1b0d780) at sf_stop+0x52 sf_init_locked(c1b0d780,0,c074def0,4b1,c1af3000) at sf_init_locked+0x44 sf_init(c1b0d780,c055f18d,c07ac2c0,8020690c,c1b0d780) at sf_init+0x3a ether_ioctl(c1af3000,8020690c,c1c19a00,c07423ea,0) at ether_ioctl+0x67 sf_ioctl(c1af3000,8020690c,c1c19a00,c1c19a7c,1) at sf_ioctl+0x270 in_ifinit(c1af3000,c1c19a00,c1c6aa10,0,1) at in_ifinit+0x208 in_control(c1e98de8,8040691a,c1c6aa00,c1af3000,c1c16a80) at in_control+0x986 ifioctl(c1e98de8,8040691a,c1c6aa00,c1c16a80,2) at ifioctl+0x1bc soo_ioctl(c1c57168,8040691a,c1c6aa00,c19d7a80,c1c16a80) at soo_ioctl+0x3ef ioctl(c1c16a80,d7827d04,c,422,3) at ioctl+0x45d syscall(3b,3b,3b,8058aa0,0) at syscall+0x2c0 Xint0x80_syscall() at Xint0x80_syscall+0x1f =2D-- syscall (54, FreeBSD ELF32, ioctl), eip =3D 0x280d17ef, esp =3D 0xbfb= fe99c,=20 ebp =3D 0xbfbfe9c8 --- brueffer@galaxy:/usr/src/sys/pci > ident if_sf.c if_sf.c: $FreeBSD: src/sys/pci/if_sf.c,v 1.82.2.3 2005/08/26 14:50:16 jhb Exp $ This results in a stalling network connection (watchdog timeout messages on= =20 the console), sometimes after 5 Minutes, sometimes after several hours. Markus =2D-=20 Markus Brueffer =A0 =A0| GPG-Key: http://people.FreeBSD.org/~markus/markus.= asc markus@brueffer.de | FP: 3F9B EBE8 F290 E5CC 1447 8760 D48D 1072 78F8 A8D4 markus@FreeBSD.org | FreeBSD: The Power to Serve! --nextPart3756378.GDYTsVmUzb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDExDW1I0Qcnj4qNQRAm3AAJ9/MGn7PnPRpj2nar9uS0O66P2siQCgl8VU LBDUPtxOVav287o2Bi8TBA0= =5tdy -----END PGP SIGNATURE----- --nextPart3756378.GDYTsVmUzb-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 13:45:43 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 555A516A41F for ; Mon, 29 Aug 2005 13:45:43 +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 8F9C043D53 for ; Mon, 29 Aug 2005 13:45:41 +0000 (GMT) (envelope-from saturnero@freesbie.org) Received: by jail1-fbsd4.consiagnet.it (Postfix, from userid 1000) id D4E3157AC; Mon, 29 Aug 2005 15:47:08 +0200 (CEST) Date: Mon, 29 Aug 2005 15:47:08 +0200 From: Dario Freni To: current@freebsd.org Message-ID: <20050829134708.GC1436@cvs.freesbie.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TiqCXmo5T1hvSQQg" Content-Disposition: inline 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: mdconfig recently 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: Mon, 29 Aug 2005 13:45:43 -0000 --TiqCXmo5T1hvSQQg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi everybody, due to limited connectivity in August, I've been able to update my -CURRENT box only yesterday since the first days of August (iirc). I noticed that mdconfig -a -t vnode -f ${myfile} isn't working anymore when ${myfile} is on a read-only filesystem: sberta:/usr/local/freesbie-clone/uzip# mdconfig -a -t vnode -f usr.uzip md0 sberta:/usr/local/freesbie-clone/uzip# mdconfig -d -u 0 sberta:/usr/local/freesbie-clone/uzip# mount -fru /usr sberta:/usr/local/freesbie-clone/uzip# mdconfig -a -t vnode -f usr.uzip mdconfig: ioctl(/dev/mdctl): Read-only file system This makes impossible to use compressed filesystems on devices like cdrom or read-only diskless environment. Any idea? I'm using: FreeBSD sberta.saturnero.sat 7.0-CURRENT FreeBSD 7.0-CURRENT #2: Sat Aug 27= 18:1 5:39 CEST 2005 satu@sberta.saturnero.sat:/usr/obj/usr/src/sys/SBERTA i= 386 sberta:/usr/local/freesbie-clone/uzip# Bye and thanks in advance, Dario --=20 Dario Freni (saturnero@freesbie.org) FreeSBIE developer (http://www.freesbie.org) GPG Public key at http://www.saturnero.net/saturnero.asc --TiqCXmo5T1hvSQQg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFDExHbymi72IiShysRAqIKAKCyvIFp4lTfd0tOMA72D2x8djRhCACguJSd OxybuZvKYJFp5pIpyCftYGI= =fhxa -----END PGP SIGNATURE----- --TiqCXmo5T1hvSQQg-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 14:26: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 7B9D416A41F for ; Mon, 29 Aug 2005 14:26:41 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA54A43D48 for ; Mon, 29 Aug 2005 14:26:39 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id j7TEQZdo098680; Mon, 29 Aug 2005 18:26:35 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id j7TEQX86098678; Mon, 29 Aug 2005 18:26:33 +0400 (MSD) (envelope-from yar) Date: Mon, 29 Aug 2005 18:26:33 +0400 From: Yar Tikhiy To: Beecher Rintoul Message-ID: <20050829142633.GB78113@comp.chem.msu.su> References: <200508261939.35889.akbeech@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200508261939.35889.akbeech@gmail.com> User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org Subject: Re: Trying to make 7.0 snapshot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 14:26:41 -0000 On Fri, Aug 26, 2005 at 07:39:34PM -0800, Beecher Rintoul wrote: > I am attempting to make a release snapshot. From /usr/src/release I did the > following: > > make release CHROOTDIR=/bak/release BUILDNAME=7.0-CURRENT CVSROOT=/bak/cvs > > It bails with this error: > ----------------------------------------------------------- > >>> Installing everything > -------------------------------------------------------------- > cd /usr/src; make -f Makefile.inc1 install > ===> share/info (install) > install -o root -g wheel -m 444 dir-tmpl /bak/release/usr/share/info/dir > ===> include (install) > creating osreldate.h from newvers.sh > touch: not found > *** Error code 127 This error is generally believed to result from system clock problems, when time goes backwards during the build/install process. This can happen due to buggy hardware or improper time zone set-up. It was the topic of numerous threads on freebsd-* lists in the past. Just google for "touch not found" (in quotes). However, in your case the time zone problem might lurk within "make release" itself. Could you try "make release" on a different machine? By the way, is your working system older than the one your are trying to do "make release" for? The influence of the recent import of new tzdata to HEAD shouldn't be ruled out. The import took place at "Fri Aug 26 18:46:27 2005 UTC". I'd suggest updating the working system *and* /etc/localtime (which is never updated automatically, to the best of my knowledge) to after the import if you were unlucky to update your CVS tree at about its time. -- Yar From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 14:48: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 1CA7716A41F; Mon, 29 Aug 2005 14:48:12 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 574F843D45; Mon, 29 Aug 2005 14:48:10 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from Andro-Beta.Leidinger.net (p54A5CD12.dip.t-dialin.net [84.165.205.18]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.1/8.13.1) with ESMTP id j7TEdOVw004107; Mon, 29 Aug 2005 16:39:39 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from localhost (localhost [127.0.0.1]) by Andro-Beta.Leidinger.net (8.13.3/8.13.3) with ESMTP id j7TEl8LU092869; Mon, 29 Aug 2005 16:47:08 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from 141.113.101.31 ([141.113.101.31]) by netchild.homeip.net (Horde MIME library) with HTTP for ; Mon, 29 Aug 2005 16:47:08 +0200 Message-ID: <20050829164708.1se6krp2oscgwso4@netchild.homeip.net> X-Priority: 3 (Normal) Date: Mon, 29 Aug 2005 16:47:08 +0200 From: Alexander Leidinger To: Mateusz =?iso-8859-15?b?SsSZZHJhc2lr?= References: <200508282340.43561.> In-Reply-To: <200508282340.43561.> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) / FreeBSD-4.11 X-Virus-Scanned: by amavisd-new Cc: ports@freebsd.org, freebsd-emulation@freebsd.org, current@freebsd.org Subject: Re: FreeBSD-6-BETA3 broken with ports/audio/aureal-kmod; ports/graphics/linux_dri not working. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 14:48:12 -0000 Mateusz J=C4=99drasik wrote: > Also, the linux_dri port is utterly broken on FreeBSD-6 when using radeon > cards. > > Due to the late improvements by anholt towards a better radeon card suppo= rt > for dri, the drm kernel module radeon.ko /in my case, built into the kern= el/ > no longer works with terribly old dri libs. > > The solution I would best see here is bumping > emulators/linux_base-suse-9.3 as > default linux compat, updating the unhappy ports to play nicely with such= an > upgrade, and using xorg-dri drivers for linux_dri compatible with the > xorg-libs avaliable with emulators/linux_base-suse-9.3. > > I would gladly help doing that, as I am a little more familiar with ports > hacking rather than kernel hacking - far from perfect with it tho ;-) As the person which changed the default linux base from 7.x to 8.0: it's no= w easy to switch the default linux_base port (OVERRIDE_LINUX_BASE_PORT=3Dsuse-9.3 in make.conf to test it yourself), but you need at least one full ports build run. This is the "I'm lucky" case. Most probably you need 3-5 full port build runs until everyting which worke= d before works after the update too. But the ports tree is already tagged for 6.0 and the cluster is building the packages for every architecture. I also don't think we should switch the default such short before a release without important reasons (like the security reason which was the cause of the change from 7.x to 8.0). Luckily I had much of the work for the 7.x -> 8.0 transition done already (several hours spread over several months), but Kris and I spend several hours at Christmas to get it into a shape which we could ship. If you have a newer linux_dri version which works with linux_base-8, we can update the port and ask portmgr if they can update the release-packages. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 Humans are communications junkies. We just can't get enough. =09=09-- Alan Kay From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 15:07: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 B525016A422 for ; Mon, 29 Aug 2005 15:07:11 +0000 (GMT) (envelope-from Emanuel.strobl@gmx.net) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 2059C43D53 for ; Mon, 29 Aug 2005 15:07:09 +0000 (GMT) (envelope-from Emanuel.strobl@gmx.net) Received: (qmail invoked by alias); 29 Aug 2005 15:07:08 -0000 Received: from flb.schmalzbauer.de (EHLO cale.flintsbach.schmalzbauer.de) [62.245.232.135] by mail.gmx.net (mp032) with SMTP; 29 Aug 2005 17:07:08 +0200 X-Authenticated: #301138 From: Emanuel Strobl To: freebsd-current@freebsd.org Date: Mon, 29 Aug 2005 17:06:58 +0200 User-Agent: KMail/1.8.1 References: <200508262004.54637@harrymail> <20050829103745.GA78113@comp.chem.msu.su> In-Reply-To: <20050829103745.GA78113@comp.chem.msu.su> X-Birthday: Oct. 6th 1972 X-CelPhone: +49 (0) 173 9967781 X-Tel: +49 (0) 89 18947781 X-Country: Germany X-Address: Munich, 80686 X-OS: FreeBSD MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6990414.5hKRV5JcGA"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200508291707.07636@harrymail> X-Y-GMX-Trusted: 0 Cc: kientzle@freebsd.org, freebsd-questions@freebsd.org Subject: Re: cpio and tar are loosing flags (and a panic message without trace) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 15:07:11 -0000 --nextPart6990414.5hKRV5JcGA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Montag, 29. August 2005 12:37 CEST schrieb Yar Tikhiy: > On Fri, Aug 26, 2005 at 08:04:45PM +0200, Emanuel Strobl wrote: > > Then I remember Tim Kienzles great work for bsdtar and all the ACL > > stuff, but unfortunately a cvPPzf <> xvpPfz also looses the arch flag > > :( > > Would you mind sending a PR on this issue with kientzle@freebsd.org > in Cc:? I believe Tim will be interested in it. I've just confirmed > myself using not-too-old CURRENT that bsdtar won't restore file > flags stored in its own archive: > > vpc7# tar --version > bsdtar 1.02.023, libarchive 1.02.026 > Copyright (C) 2003-2005 Tim Kientzle > vpc7# sysctl kern.securelevel > kern.securelevel: -1 > vpc7# mkdir dir > vpc7# touch dir/file > vpc7# chflags arch,sunlink dir/file > vpc7# ls -lo dir/file > -rw-r--r-- 1 root staff arch,sunlnk 0 Aug 29 14:35 dir/file > vpc7# tar cf dir.tar dir > vpc7# hd dir.tar | grep -1 fflags > 00000420 35 33 32 36 31 34 39 0a 32 39 20 53 43 48 49 4c |5326149.29 > SCHIL| 00000430 59 2e 66 66 6c 61 67 73 3d 61 72 63 68 2c 73 75=20 > |Y.fflags=3Darch,su| 00000440 6e 6c 6e 6b 0a 31 37 20 53 43 48 49 4c 59 > 2e 64 |nlnk.17 SCHILY.d| vpc7# mv dir dir.bak > vpc7# tar xpf dir.tar > vpc7# ls -lo dir/file > -rw-r--r-- 1 root staff - 0 Aug 29 14:35 dir/file > > This is at variance with what the tar(1) manpage says: > > -p (x mode only) Preserve file permissions. Attempt to > restore the full permissions, including owner, file modes, file flags > and ACLs, if available, for each item extracted from the archive... > > I think it might be reasonable to include these details in the PR. I filed a PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=3D84135 Unfortunately I forgot to include your analysis here, so I CC this message= =20 to Tim Kientzle. =2DHarry --nextPart6990414.5hKRV5JcGA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBDEySbBylq0S4AzzwRAveWAJ4yHaFrkgs3Tm0FYV0i0D8I5JvOeQCfTWRL n9mfMzGETkB4EpVcaO9vTZo= =dL8y -----END PGP SIGNATURE----- --nextPart6990414.5hKRV5JcGA-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 15:57: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 56D9216A41F for ; Mon, 29 Aug 2005 15:57:22 +0000 (GMT) (envelope-from Emanuel.strobl@gmx.net) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id EBE0743D5C for ; Mon, 29 Aug 2005 15:57:19 +0000 (GMT) (envelope-from Emanuel.strobl@gmx.net) Received: (qmail invoked by alias); 29 Aug 2005 15:57:18 -0000 Received: from flb.schmalzbauer.de (EHLO cale.flintsbach.schmalzbauer.de) [62.245.232.135] by mail.gmx.net (mp006) with SMTP; 29 Aug 2005 17:57:18 +0200 X-Authenticated: #301138 From: Emanuel Strobl To: freebsd-current@freebsd.org Date: Mon, 29 Aug 2005 17:57:09 +0200 User-Agent: KMail/1.8.1 X-Birthday: Oct. 6th 1972 X-CelPhone: +49 (0) 173 9967781 X-Tel: +49 (0) 89 18947781 X-Country: Germany X-Address: Munich, 80686 X-OS: FreeBSD MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1310401.x34mSM8sf9"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200508291757.17501@harrymail> X-Y-GMX-Trusted: 0 Subject: hw RNG 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, 29 Aug 2005 15:57:22 -0000 --nextPart1310401.x34mSM8sf9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, the (4) random man page describes that kern.random.sys.seeded would not be= =20 seen if the system has a hardware RNG. Now my chipset (i815) is supposed=20 to have one, also I have a box with a HIFN 7951, which, according to man=20 (4) hifn, also has a RNG, but I'm seeing the mentioned sysctls. How can I test if my hw rng is used at all? I'd like to disable=20 entropy-harvesting on machines with hw rng. Thanks, =2DHarry --nextPart1310401.x34mSM8sf9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBDEzBdBylq0S4AzzwRAqNLAJ9sO1p+braFB6W62OMSUTeOE8FyfACfVd+T 33CGFkXY/4HgEW9hlhw1A6w= =D9+Z -----END PGP SIGNATURE----- --nextPart1310401.x34mSM8sf9-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 16:30: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 C764F16A41F; Mon, 29 Aug 2005 16:30:29 +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 484E043D55; Mon, 29 Aug 2005 16:30:29 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.3) id j7TGUQGB003862; Mon, 29 Aug 2005 11:30:26 -0500 (CDT) (envelope-from dan) Date: Mon, 29 Aug 2005 11:30:26 -0500 From: Dan Nelson To: Michael Bushkov Message-ID: <20050829163025.GA25664@dan.emsphone.com> References: <20050827170633.Y5409@stinger.cc.rsu.ru> <43123F3B.8070002@FreeBSD.org> <20050829115740.N5409@stinger.cc.rsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050829115740.N5409@stinger.cc.rsu.ru> X-OS: FreeBSD 5.4-STABLE X-message-flag: Outlook Error User-Agent: Mutt/1.5.9i Cc: Jacques Vidrine , freebsd-hackers@freebsd.org, Doug Barton , Brooks Davis , freebsd-current@freebsd.org Subject: Re: [PATCH] caching daemon release and nsswitch patches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 16:30:30 -0000 In the last episode (Aug 29), Michael Bushkov said: > There is some information in my project's description here: > http://wikitest.freebsd.org/moin.cgi/NsswitchAndCachingTechnicalDetails One question that comes to mind: It looks like the end-user application is still responsible for performing nss lookups. How do you ensure that one user can't poison the cache and cause problems for other users? Could cached do all nss operations itself (making it more like nscd in other OSes)? -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 16:46: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 AB9B716A41F; Mon, 29 Aug 2005 16:46:03 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id F273843D45; Mon, 29 Aug 2005 16:46:02 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id j7TGjagu012880; Mon, 29 Aug 2005 09:45:40 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200508291645.j7TGjagu012880@gw.catspoiler.org> Date: Mon, 29 Aug 2005 09:45:36 -0700 (PDT) From: Don Lewis To: rwatson@FreeBSD.org In-Reply-To: <20050828051917.W52467@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: bzeeb-lists@lists.zabbadoz.net, freebsd-current@FreeBSD.org, dandee@volny.cz, imp@bsdimp.com Subject: Re: LOR route vr0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 16:46:03 -0000 On 28 Aug, Robert Watson wrote: > > On Sat, 27 Aug 2005, M. Warner Losh wrote: > >> : Correct. 'tcp' reflects the global TCP state tables (pcbinfo) locks, and >> : 'tcpinp' is for individual PCBs. If you acquire first a tcpinp and then >> : tcp, the above settings should cause WITNESS to generate a lock order >> : warning. Likewise, both tcp and tcpinp preceed so_snd, so if you acquire >> : a protocol lock after a socket lock, it will get unhappy. WITNESS handles >> : transitive relationships, so it gets connected up to the rest of the lock >> : graph, explicit and implicit, so indirect violations of orders are fully >> : handled. >> >> OK. I've been seeing similar LORs in ed, sn, iwi (ed is my locked >> version of ed, not in tree GIANT locked ed). >> >> I've made the following changes, and the LORs go away (except for one, >> which was unrelated). I further don't get the first place where they >> locks happen that caused the original LORs, so I'm mightly confused. > > Hmm. I've seen another identical report recently -- that when a lock > order is put into WITNESS, reversals against it are not reported. I > wonder if we've got a witness bug on our hands? What version of subr_witness.c? I'm not convinced that the reparenting and rebalancing transformations in versions 1.197 and earlier won't generate bogus lock relationships, though I'm having a hard time thinking of a way for an inverse relationship to be "learned" and it would seem odd that this problem would just now be showing up. Even hard-wired relationships can be modified on the fly by the reparenting and rebalancing code, which *might* explain the oddness of no LORs begin reported when the relationship is hardwired. On the other hand I'm certainly hoping that my changes in 1.198 aren't causing this problem. There is some code common to both versions that provide exceptions to the reporting of lock order reversals and the learning of certain locking relationships, but I don't think that matters in this case. There is some KTR code in subr_witness.c that could be used to debug this problem, but it may not be a fine enough filter. It might be useful to unwire the relationship and call kdb_backtrace() from insertchild() when the "incorrect" lock order is first learned. From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 17: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 908F216A41F for ; Mon, 29 Aug 2005 17:02:05 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B9F943D48 for ; Mon, 29 Aug 2005 17:02:05 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.91] ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j7TH1HBd070243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Aug 2005 10:01:19 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <431340F9.4060407@errno.com> Date: Mon, 29 Aug 2005 10:08:09 -0700 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050327) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dandee@volny.cz References: <20050824151056.40CCB4E704@pipa.profix.cz> In-Reply-To: <20050824151056.40CCB4E704@pipa.profix.cz> Content-Type: multipart/mixed; boundary="------------060006050908010801070704" Cc: freebsd-current@freebsd.org, 'Milan Obuch' Subject: Re: ATHCTRL for ATH X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 17:02:05 -0000 This is a multi-part message in MIME format. --------------060006050908010801070704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit [coming in late here...] athctrl is a trivial program that should be a shell script at best. It currently makes no sense to add this sort of support to ifconfig because each device does things very differently (if at all) and trying to unify the operation is likely to lead to more confusion than anything else. Attached is an untested shell script I wrote for someone else. If you can tell me it does the right thing for you then I'll commit it to tools/tools/ath where I've stuck other similar things. Sam --------------060006050908010801070704 Content-Type: text/plain; name="athctrl.sh" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="athctrl.sh" #! /bin/sh # # Set the IFS parameters for an interface configured for # point-to-point use at a specific distance. Based on a # program by Gunter Burchardt. # DEV=ath0 d=0 usage() { echo "Usage: $0 [-i athX] [-d meters]" exit 2 } args=`getopt d:i: $*` test $? -ne 0 && usage set -- $args for i; do case "$i" in -i) DEV="$2"; shift; shift;; -d) d="$2"; shift; shift;; --) shift; break; esac done test $d -eq 0 && usage slottime=`expr 9 + \( $d / 300 \)` if expr \( $d % 300 \) != 0 >/dev/null 2>&1; then slottime=`expr $slottime + 1` fi timeout=`expr $slottime \* 2 + 3` printf "Setup IFS parameters on interface ${DEV} for %i meter p-2-p link\n" $d ATHN=`echo $DEV | sed 's/ath//'` sysctl dev.ath.$ATHN.slottime=$slottime sysctl dev.ath.$ATHN.acktimeout=$timeout sysctl dev.ath.$ATHN.ctstimeout=$timeout --------------060006050908010801070704-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 17:03: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 5BFA216A41F for ; Mon, 29 Aug 2005 17:03:06 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9447343D5E for ; Mon, 29 Aug 2005 17:03:03 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.91] ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j7TH31Bd070261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Aug 2005 10:03:03 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <43134161.70207@errno.com> Date: Mon, 29 Aug 2005 10:09:53 -0700 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050327) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dorijan Jelincic References: <09950876.20050824112311@kset.org> In-Reply-To: <09950876.20050824112311@kset.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: wireless part: 2.3 gh band X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 17:03:06 -0000 Dorijan Jelincic wrote: > Hello freebsd-current, > > I am using 2.3 gh band since it is legal radioamater band, and it > would be great if you could implement it in ieee80211.c > > ieee80211_mhz2ieee(u_int freq, u_int flags) > { > if (flags & IEEE80211_CHAN_2GHZ) { /* 2GHz band */ > if (freq == 2484) > return 14; > if (freq<=2402) > return (255 - (2402-freq)/5); /* 2.3GHz band */ > if (freq < 2484) > return (freq - 2407) / 5; > else > return 15 + ((freq - 2512) / 20);} > > ..... > > > ieee80211_ieee2mhz(u_int chan, u_int flags) > { > if (flags & IEEE80211_CHAN_2GHZ) { /* 2GHz band */ > if (chan == 14) > return 2484; > if (chan>236) > return 2402 - (255-chan)*5; /* 2.3GHz band */ > > if (chan < 14) > return 2407 + chan*5; > else > return 2512 + ((chan-15)*20);} > > > This way channel list is compatibile even with Mikrotik and StarOS... > > I don't see the use in this change; please explain why it's worth doing. In particular this can only be useful w/ some other changes and/or a new driver so please indicate what else you've got. Sam From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 17:07: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 0789B16A41F for ; Mon, 29 Aug 2005 17:07:56 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8570643D53 for ; Mon, 29 Aug 2005 17:07:55 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.91] ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j7TH7sBd070311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Aug 2005 10:07:55 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <43134287.9080307@errno.com> Date: Mon, 29 Aug 2005 10:14:47 -0700 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050327) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Edmond Baroud References: <20050829035343.66348.qmail@web30514.mail.mud.yahoo.com> In-Reply-To: <20050829035343.66348.qmail@web30514.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: WPA: Failed to set PTK to the 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, 29 Aug 2005 17:07:56 -0000 Edmond Baroud wrote: > Hi all, > > I'm a long time desktop FreeBSD user (almost 7 years) > and now the time has come to install it on a laptop I > got from the job. > Didn't have the choice to pick an Intel card so my > laptop came with the 'Dell TrueMobile 1450 Dual Band > WLAN Mini-PCI Card'. > HW: Dell Latitude D610 > OS: 7-current custom kernel. > I used ndisgen with the bcmwl5a.inf and bcmwl5.sys > from various release of the driver but still can't get > WPA to work and after some digging I looked at the > net80211 layer source code and the error message I'm > getting is coming fron there. I don't know if it's a > bug in that module or an incompatibility between the > layer and the ndis API. > When I run the wpa_supplicant without initiating an > 'ifconfig ndis0 ssid 'myssid' authmode wpa channel 1 > up' the supplicant doesn't seem to communicate with > the AP, so I get to reproduce my test in the following > sequence: > I have all the wlan* modules compiled in the kernel. > > -8<--cut--8<---cut--8<- > normal boot > cypher#kldload ndis > cypher#kldload bcmwl5_sys > ndis0: Card> mem 0xdfcfe000-0xdfcfffff irq 17 at device 3.0 > on pci3 > ndis0: NDIS API version: 5.0 > ndis0: Ethernet address: 00:0b:7d:27:30:81 > cypher# ifconfig ndis0 ssid 'myssid' authmode wpa > channel 1 up > cypher# wpa_supplicant -i ndis0 -c > /etc/wpa_supplicant.conf -ddd > Initializing interface 'ndis0' conf > '/etc/wpa_supplicant.conf' driver 'default' > Configuration file '/etc/wpa_supplicant.conf' -> > '/etc/wpa_supplicant.conf' > Reading configuration file '/etc/wpa_supplicant.conf' > ctrl_interface='/var/run/wpa_supplicant' > ctrl_interface_group=0 > Line: 7 - start of a new network block > ssid - hexdump_ascii(len=6): > 6d 73 73 69 64 myssid > proto: 0x1 > PSK (ASCII passphrase) - hexdump_ascii(len=15): > [REMOVED] > PSK (from passphrase) - hexdump(len=32): [REMOVED] > Priority group 0 > id=0 ssid='myssid' > Initializing interface (2) 'ndis0' > Own MAC address: 00:0b:7d:27:30:81 > wpa_driver_bsd_set_wpa: enabled=1 > wpa_driver_bsd_set_wpa_internal: wpa=3 privacy=1 > wpa_driver_bsd_del_key: keyidx=0 > wpa_driver_bsd_del_key: keyidx=1 > wpa_driver_bsd_del_key: keyidx=2 > wpa_driver_bsd_del_key: keyidx=3 > wpa_driver_bsd_set_countermeasures: enabled=0 > wpa_driver_bsd_set_drop_unencrypted: enabled=1 > Setting scan request: 0 sec 100000 usec > Starting AP scan (broadcast SSID) > Received 0 bytes of scan results (1 BSSes) > Scan results: 1 > Selecting BSS from priority group 0 > 0: 00:09:5b:f9:b6:04 ssid='myssid' wpa_ie_len=24 > rsn_ie_len=0 > selected > Trying to associate with 00:09:5b:f9:b6:04 > (SSID='myssid' freq=2412 MHz) > Cancelling scan request > Automatic auth_alg selection: 0x1 > WPA: using IEEE 802.11i/D3.0 > WPA: Selected cipher suites: group 8 pairwise 8 > key_mgmt 2 > WPA: using GTK TKIP > WPA: using PTK TKIP > WPA: using KEY_MGMT WPA-PSK > WPA: Own WPA IE - hexdump(len=24): dd 16 00 50 f2 01 > 01 00 00 50 f2 02 01 00 00 50 f2 02 01 00 00 50 f2 02 > No keys have been configured - skip key clearing > wpa_driver_bsd_set_drop_unencrypted: enabled=1 > wpa_driver_bsd_associate: ssid 'myssid' wpa ie len 24 > pairwise 2 group 2 key mgmt 1 > wpa_driver_bsd_associate: set PRIVACY 1 > Setting authentication timeout: 5 sec 0 usec > RX EAPOL from 00:09:5b:f9:b6:04 > RX EAPOL - hexdump(len=99): 01 03 00 5f fe 00 89 00 20 > 00 00 00 00 00 00 00 01 35 27 ab 37 5f 76 d8 76 78 39 > 43 22 40 01 7f 2c d1 ae 7d b4 b0 6f 88 aa f0 cf 54 66 > 5c 48 b5 c6 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > Setting authentication timeout: 10 sec 0 usec > IEEE 802.1X RX: version=1 type=3 length=95 > EAPOL-Key type=254 > WPA: RX EAPOL-Key - hexdump(len=99): 01 03 00 5f fe 00 > 89 00 20 00 00 00 00 00 00 00 01 35 27 ab 37 5f 76 d8 > 76 78 39 43 22 40 01 7f 2c d1 ae 7d b4 b0 6f 88 aa f0 > cf 54 66 5c 48 b5 c6 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 > WPA: RX message 1 of 4-Way Handshake from > 00:09:5b:f9:b6:04 (ver=1) > WPA: Renewed SNonce - hexdump(len=32): 7c 11 51 60 d3 > 4e 87 6b 40 73 ed 50 33 9d 10 05 95 0d 72 23 a4 21 db > f5 b2 45 40 47 44 35 a5 0a > WPA: PMK - hexdump(len=32): [REMOVED] > WPA: PTK - hexdump(len=64): [REMOVED] > WPA: EAPOL-Key MIC - hexdump(len=16): 3b 08 8a 26 36 > 3c 57 7c a0 90 77 07 40 84 65 47 > WPA: Sending EAPOL-Key 2/4 > WPA: TX EAPOL-Key 2/4 - hexdump(len=137): 00 09 5b f9 > b6 04 00 0b 7d 27 30 81 88 8e 01 03 00 77 fe 01 09 00 > 20 00 00 00 00 00 00 00 01 7c 11 51 60 d3 4e 87 6b 40 > 73 ed 50 33 9d 10 05 95 0d 72 23 a4 21 db f5 b2 45 40 > 47 44 35 a5 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 3b 08 8a 26 36 3c 57 7c a0 90 77 07 40 84 65 47 00 > 18 dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 > 02 01 00 00 50 f2 02 > RX EAPOL from 00:09:5b:f9:b6:04 > RX EAPOL - hexdump(len=123): 01 03 00 77 fe 01 c9 00 > 20 00 00 00 00 00 00 00 02 35 27 ab 37 5f 76 d8 76 78 > 39 43 22 40 01 7f 2c d1 ae 7d b4 b0 6f 88 aa f0 cf 54 > 66 5c 48 b5 c6 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 33 4c df 12 27 d1 21 a2 43 e8 92 72 07 41 2a f4 00 > 18 dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 > 02 01 00 00 50 f2 02 > IEEE 802.1X RX: version=1 type=3 length=119 > EAPOL-Key type=254 > WPA: RX EAPOL-Key - hexdump(len=123): 01 03 00 77 fe > 01 c9 00 20 00 00 00 00 00 00 00 02 35 27 ab 37 5f 76 > d8 76 78 39 43 22 40 01 7f 2c d1 ae 7d b4 b0 6f 88 aa > f0 cf 54 66 5c 48 b5 c6 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 33 4c df 12 27 d1 21 a2 43 e8 92 72 07 41 > 2a f4 00 18 dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 > 00 50 f2 02 01 00 00 50 f2 02 > WPA: RX message 3 of 4-Way Handshake from > 00:09:5b:f9:b6:04 (ver=1) > WPA: IE KeyData - hexdump(len=24): dd 16 00 50 f2 01 > 01 00 00 50 f2 02 01 00 00 50 f2 02 01 00 00 50 f2 02 > WPA: Sending EAPOL-Key 4/4 > WPA: TX EAPOL-Key 4/4 - hexdump(len=113): 00 09 5b f9 > b6 04 00 0b 7d 27 30 81 88 8e 01 03 00 5f fe 01 09 00 > 20 00 00 00 00 00 00 00 02 7c 11 51 60 d3 4e 87 6b 40 > 73 ed 50 33 9d 10 05 95 0d 72 23 a4 21 db f5 b2 45 40 > 47 44 35 a5 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 27 b8 2e 54 25 a9 e0 ba 21 72 28 ac 16 37 7d 24 00 > 00 > WPA: Installing PTK to the driver. > WPA: RSC - hexdump(len=6): 00 00 00 00 00 00 > wpa_driver_bsd_set_key: alg=TKIP > addr=00:09:5b:f9:b6:04 key_idx=0 set_tx=1 seq_len=6 > key_len=32 > ioctl[SIOCS80211, op 19, len 60]: Operation not > supported by device > WPA: Failed to set PTK to the driver. > > -8<--cut--8<---cut--8<- > > Any ideas? Please CC me I'm not subscribed to the > list. > I'll be glad to do some debugging to help fix that if > it's a bug. > Please show the output of kldstat; it appears you may not have wlan_tkip loaded. Sam From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 17:20: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 77FD816A41F; Mon, 29 Aug 2005 17:20:14 +0000 (GMT) (envelope-from flynn@energyhq.es.eu.org) Received: from mindfields.energyhq.es.eu.org (73.Red-213-97-200.pooles.rima-tde.net [213.97.200.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FD6C43D46; Mon, 29 Aug 2005 17:20:10 +0000 (GMT) (envelope-from flynn@energyhq.es.eu.org) Received: from scienide.energyhq.es.eu.org (scienide.energyhq.es.eu.org [192.168.100.1]) by mindfields.energyhq.es.eu.org (Postfix) with SMTP id C013B123FDC; Mon, 29 Aug 2005 19:20:08 +0200 (CEST) Date: Mon, 29 Aug 2005 19:19:27 +0200 From: Miguel Mendez To: "Mikhail T." Message-Id: <20050829191927.6694a969.flynn@energyhq.es.eu.org> In-Reply-To: <200508281326.j7SDQGfc073329@blue.virtual-estates.net> References: <200508281326.j7SDQGfc073329@blue.virtual-estates.net> X-Mailer: Sylpheed version 2.0.0 (GTK+ 2.6.9; amd64-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: re@FreeBSD.org, current@FreeBSD.org Subject: Re: installing 6.0-BETA3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 17:20:14 -0000 On Sun, 28 Aug 2005 09:26:16 -0400 (EDT) "Mikhail T." wrote: Hi, [re@ cc trimmed] > . Something is wrong with the ed-driver (in my case -- > Kingston's KNE-PC2T, FCC ID L40WST200). Kernel reports > being unable to do something with pccard1, then reports > ed1: .... > and hangs. I let it wait for an hour and it never continued > booting. I'll try to investigate, when I'm done installing. > The card worked just fine in a newer Pentium-II laptop under > FreeBSD-5.x If the card is a 16bit pcmcia car make sure the bridge is set to 16bit. I had a similar problem on an old Thinkpad when trying to use a 32bit cardbus nic while the bridge was set to default to 16bit in the BIOS. > . Dangerously dedicated mode did not work -- things installed, > but the BIOS would not boot (Read Error). AFAIK the use of dangerously dedicated mode has been discouraged for some time. I don't see any real advantage of using it, and some BIOSes have problems booting from such disks. Just create a big slice covering the whole disk and go on. > . The third install succeeded with non-dangerous full disk and > separate file-systems and swap on ad0s1a, b, e, and d. Note the you only need one MS-DOS partition and you can put all your BSD partitions inside that one. Like I've said above I don't see any advantage in using the partition-less mode. > . World-rebuild is still running (with the attached make.conf) > -- about 8 hours already. WITNESS/INVARIANTS, probably, have > something to do with it too -- the disk is, obviously, not fast, > but the average load is firmly at 1.0 (or slightly above), > meaning that kernel keeps the CPU busy. I wouldn't blame WITNESS on this. Laptops, especially old ones, have incredibly slow disks. The buildworld process is heavily i/o bounded, my bet is on the disk subsystem. My experience with wi-fi on FreeBSD is limited, others surely can fill in the blanks. Cheers, -- Miguel Mendez http://www.energyhq.es.eu.org PGP Key: 0xDC8514F1 From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 17:22: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 35DB816A41F for ; Mon, 29 Aug 2005 17:22:08 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB03643D45 for ; Mon, 29 Aug 2005 17:22:07 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.91] ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j7THK6Bd070373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Aug 2005 10:21:22 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <43134562.7040009@errno.com> Date: Mon, 29 Aug 2005 10:26:58 -0700 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050327) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pascal Hofstee References: <1125297494.67517.19.camel@synergy.charterpipeline.net.lan> In-Reply-To: <1125297494.67517.19.camel@synergy.charterpipeline.net.lan> Content-Type: multipart/mixed; boundary="------------040305080809040502010401" Cc: freebsd-current@freebsd.org, Hanns Hartman Subject: Re: wpa_supplicant segfaults with ath X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 17:22:08 -0000 This is a multi-part message in MIME format. --------------040305080809040502010401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Pascal Hofstee wrote: > On Sun, 2005-08-28 at 23:12 -0700, Hanns Hartman wrote: > >>Hi, >> This is my first time posting to the list so if you need more information >>let me know. also since I have no internet on my freebsd box it is difficult >>to get all of the verbose output. so here goes. >> >>I am using freebsd6.0beta2 on an amd64. I am using the src tree from august >>21. >> >>I am trying to associate with a 2wire gateway that was supplied by sbc for >>my dsl. I have set the gateway up with wpa-psk encription. >>I am able to connect perfectly fine to this gateway with my ibm t42 but when >>I try to associate with the gateway using wpa_supplicant I get a >>segmentation fault after the program reaches "wpa: sending eapol-key 4/4" >>specifially it faults right after displaying "wpa: rsc - hexdump(len=6): 00 >>00 00 00 00 00" while using option -d for output. >> >>when running the supplicant in gdb I get program received SIGSEGV, >>segmentation fault. 0x000000080082d4d0 in strlen () from /lib/libc.so.6 >> >>if there is anything else needed that might help to explain the problem let >>me know. I appoligize for not having more output to post at this time. >>thanks for the help >>Hanns > > > Thank you for posting this ... as it reminded me i should probably file > a bug report on this. I recently tried to do some investigative work of > my own hoping to find out why my if_ral interface kept acting up when i > bumped into the exact same problem myself. > > i can tell you why the segfault happens .. though i am not entirely sure > how it should be fixed properly. > > The problem you're experiencing is caused by the ether_ntoa(addr) call > in /usr/src/usr.sbin/wpa/wpa_supplicant/driver_freebsd.c:280 > > ether_ntoa expects a "const struct ether_addr" as it's parameter where > in the code the parameter passed is a "const unsigned char*", further > more in that same printf statement seq_len and key_len are being > displayed using "%d" where this should be "%zu" since these are > size_t's. The size_t construct happens a few more times in the code if i > recall correctly. > > The actual crash you're experiencing though is caused by the faulty > ether_ntoa argument. > > If somebody more knowledgable on this particular subject could have a > closer look at what was actually intended here that would be > appreciated. > A stack trace at the time of the segfault would be useful. The type mismatches should not be an issue unless there are alignment problems. Please try the attached change which should correct any alignment issues. Sam --------------040305080809040502010401 Content-Type: text/plain; name="driver_freebsd.c.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="driver_freebsd.c.patch" Index: driver_freebsd.c =================================================================== RCS file: /usr/ncvs/src/usr.sbin/wpa/wpa_supplicant/driver_freebsd.c,v retrieving revision 1.7 diff -u -r1.7 driver_freebsd.c --- driver_freebsd.c 13 Aug 2005 04:23:33 -0000 1.7 +++ driver_freebsd.c 29 Aug 2005 17:24:14 -0000 @@ -30,6 +30,7 @@ #include #include +#include #include #include @@ -231,8 +232,11 @@ memset(&wk, 0, sizeof(wk)); if (addr != NULL && bcmp(addr, "\xff\xff\xff\xff\xff\xff", IEEE80211_ADDR_LEN) != 0) { + struct ether_addr ea; + + memcpy(&ea, addr, IEEE80211_ADDR_LEN); wpa_printf(MSG_DEBUG, "%s: addr=%s keyidx=%d", - __func__, ether_ntoa(addr), key_idx); + __func__, ether_ntoa(&ea), key_idx); memcpy(wk.idk_macaddr, addr, IEEE80211_ADDR_LEN); wk.idk_keyix = (uint8_t) IEEE80211_KEYIX_NONE; } else { @@ -250,6 +254,7 @@ { struct wpa_driver_bsd_data *drv = priv; struct ieee80211req_key wk; + struct ether_addr ea; char *alg_name; u_int8_t cipher; @@ -275,18 +280,19 @@ return -1; } + memcpy(&ea, addr, IEEE80211_ADDR_LEN); wpa_printf(MSG_DEBUG, - "%s: alg=%s addr=%s key_idx=%d set_tx=%d seq_len=%d key_len=%d", - __func__, alg_name, ether_ntoa(addr), key_idx, set_tx, + "%s: alg=%s addr=%s key_idx=%d set_tx=%d seq_len=%zu key_len=%zu", + __func__, alg_name, ether_ntoa(&ea), key_idx, set_tx, seq_len, key_len); if (seq_len > sizeof(u_int64_t)) { - wpa_printf(MSG_DEBUG, "%s: seq_len %d too big", + wpa_printf(MSG_DEBUG, "%s: seq_len %zu too big", __func__, seq_len); return -2; } if (key_len > sizeof(wk.ik_keydata)) { - wpa_printf(MSG_DEBUG, "%s: key length %d too big", + wpa_printf(MSG_DEBUG, "%s: key length %zu too big", __func__, key_len); return -3; } --------------040305080809040502010401-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 17:28: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 6FF8016A41F for ; Mon, 29 Aug 2005 17:28:23 +0000 (GMT) (envelope-from stb@lassitu.de) Received: from schlepper.zs64.net (schlepper.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7074143D45 for ; Mon, 29 Aug 2005 17:28:21 +0000 (GMT) (envelope-from stb@lassitu.de) Received: from [IPv6:::1] (schlepper [212.12.50.230]) by schlepper.zs64.net (8.13.3/8.12.9) with ESMTP id j7THS4Kp024893; Mon, 29 Aug 2005 19:28:07 +0200 (CEST) (envelope-from stb@lassitu.de) In-Reply-To: <3923443F-6926-4BB7-8681-40FC68A41B79@lassitu.de> References: <7A0B19EC-2F90-495F-B242-7FB701C32908@lassitu.de> <20050828124321.43365136@Magellan.Leidinger.net> <3923443F-6926-4BB7-8681-40FC68A41B79@lassitu.de> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: multipart/mixed; boundary=Apple-Mail-4-1000395906 Message-Id: <0046E5C3-22EE-4F5D-B2B0-DFF4F0157F6B@lassitu.de> From: Stefan Bethke Date: Mon, 29 Aug 2005 19:28:03 +0200 To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.734) Cc: =?ISO-8859-1?Q?S=F8ren_Schmidt?= Subject: Re: Boot off CF card hangs at "Trying to mount root" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 17:28:23 -0000 --Apple-Mail-4-1000395906 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Am 28.08.2005 um 18:46 schrieb Stefan Bethke: > Compiling boot, loader, and kernel without a CPUTYPE setting fixed > the boot and loader issues; however, the kernel doesn't seem to be > happy with the CF card: > > ad3: 489MB at ata1-slave PIO4 > Trying to mount root from ufs:/dev/ad3s1a > > Again, I can break into the debugger, but I'm not certain what I > should be looking at. OK brought home a couple of useful things; I can now run both the HD and the CF card at the same time, and I have a serial console. Booting into 5-stable from the HD let's me access the CF card just fine. I've attached a verbose boot from both 5-stable and 6-beta3. The most striking difference (to me) is that 5-stable thinks DMA66 is fine (and my tests show that at least reading is not a problem at all), while 6-beta wants to do PIO4, but seemingly gets stuck. Time to add debugging to ata? Just to make sure I didn't mess up the kernel config, I'll try with GENERIC. Thanks, Stefan --Apple-Mail-4-1000395906 Content-Transfer-Encoding: 7bit Content-Type: text/plain; x-unix-mode=0644; name="dmesg-5.txt" Content-Disposition: attachment; filename=dmesg-5.txt FreeBSD/i386 (diesel.lassitu.de) (ttyd0) login: Console: serial port BIOS drive C: is disk0 BIOS drive D: is disk1 BIOS 640kB/515008kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 (root@diesel.lassitu.de, Sat Jun 4 12:21:42 CEST 2005) Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x2d781c data=0x32cc0+0x35940 syms=[0x4+0x42fd0+0x4+0x55559] /boot/kernel/snd_via82c686.ko text=0x235c data=0x26c syms=[0x4+0x850+0x4+0x8a3] loading required module 'sound' /boot/kernel/sound.ko text=0x13848 data=0x279c+0x10cc syms=[0x4+0x2bc0+0x4+0x30c9] /boot/kernel/mem.ko text=0x24f8 data=0x244+0x24 syms=[0x4+0x790+0x4+0x6e3] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel] in 9 seconds... Type '?' for a list of commands, 'help' for more detailed help. OK boot -vs GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base=0000000000000000 len=00000000000a0000 SMAP type=02 base=00000000000f0000 len=0000000000010000 SMAP type=02 base=00000000ffff0000 len=0000000000010000 SMAP type=01 base=0000000000100000 len=000000001f6f0000 SMAP type=03 base=000000001f7f3000 len=000000000000d000 SMAP type=04 base=000000001f7f0000 len=0000000000003000 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 5.4-STABLE #2: Sat Jun 4 15:51:17 CEST 2005 root@diesel.lassitu.de:/usr/obj/usr/src/sys/DIESEL Preloaded elf kernel "/boot/kernel/kernel" at 0xc0803000. Preloaded elf module "/boot/kernel/snd_via82c686.ko" at 0xc08031d8. Preloaded elf module "/boot/kernel/sound.ko" at 0xc080328c. Preloaded elf module "/boot/kernel/mem.ko" at 0xc0803338. Calibrating clock(s) ... i8254 clock: 1193099 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 532639770 Hz CPU: VIA C3 Samuel 2 (532.64-MHz 686-class CPU) Origin = "CentaurHauls" Id = 0x673 Stepping = 3 Features=0x803035 real memory = 528416768 (503 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009ffff, 651264 bytes (159 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c25000 - 0x000000001eee3fff, 506195968 bytes (123583 pages) avail memory = 507424768 (483 MB) bios32: Found BIOS32 Service Directory header at 0xc00fb090 bios32: Entry = 0xfb500 (c00fb500) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xb530 pnpbios: Found PnP BIOS data at 0xc00fbfd0 pnpbios: Entry = f0000:c000 Rev = 1.0 Other BIOS signatures found: wlan: <802.11 Link Layer> null: random: mem: acpi0: on motherboard acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x80000060 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=06011106) pcibios: BIOS version 2.10 Found $PIR table, 7 entries at 0xc00fde40 PCI-Only Interrupts: 5 10 11 12 Location Bus Device Pin Link IRQs slot 1 0 8 A 0x01 3 4 5 7 9 10 11 12 14 15 slot 1 0 8 B 0x02 3 4 5 7 9 10 11 12 14 15 slot 1 0 8 C 0x03 3 4 5 7 9 10 11 12 14 15 slot 1 0 8 D 0x05 3 4 5 7 9 10 11 12 14 15 slot 2 0 9 A 0x02 3 4 5 7 9 10 11 12 14 15 slot 2 0 9 B 0x03 3 4 5 7 9 10 11 12 14 15 slot 2 0 9 C 0x05 3 4 5 7 9 10 11 12 14 15 slot 2 0 9 D 0x01 3 4 5 7 9 10 11 12 14 15 slot 3 0 6 A 0x03 3 4 5 7 9 10 11 12 14 15 slot 3 0 6 B 0x05 3 4 5 7 9 10 11 12 14 15 slot 3 0 6 C 0x01 3 4 5 7 9 10 11 12 14 15 slot 3 0 6 D 0x02 3 4 5 7 9 10 11 12 14 15 slot 4 0 11 A 0x05 3 4 5 7 9 10 11 12 14 15 slot 4 0 11 B 0x01 3 4 5 7 9 10 11 12 14 15 slot 4 0 11 C 0x02 3 4 5 7 9 10 11 12 14 15 slot 4 0 11 D 0x03 3 4 5 7 9 10 11 12 14 15 slot 5 0 7 A 0x02 3 4 5 7 9 10 11 12 14 15 slot 5 0 7 B 0x03 3 4 5 7 9 10 11 12 14 15 slot 5 0 7 C 0x05 3 4 5 7 9 10 11 12 14 15 slot 5 0 7 D 0x01 3 4 5 7 9 10 11 12 14 15 embedded 0 1 A 0x01 3 4 5 7 9 10 11 12 14 15 embedded 0 1 B 0x02 3 4 5 7 9 10 11 12 14 15 embedded 0 1 C 0x03 3 4 5 7 9 10 11 12 14 15 embedded 0 1 D 0x05 3 4 5 7 9 10 11 12 14 15 embedded 0 7 C 0x03 3 4 5 7 9 10 11 12 14 15 embedded 0 7 D 0x05 3 4 5 7 9 10 11 12 14 15 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 7 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 7 func 0 acpi0: Power Button (fixed) ACPI timer: 0/6 0/4 0/5 0/4 0/5 0/4 0/5 0/4 0/5 0/5 -> 0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 unknown: not probed (disabled) cpu0: on acpi0 acpi_throttle0: on cpu0 acpi_throttle0: P_CNT from P_BLK 0x4010 acpi_button0: on acpi0 pcib0: port 0x6000-0x607f,0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0 ACPI PCI link initial configuration: \_SB_.PCI0.LNKA irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 12+ low,level,sharable 0.8.0 \_SB_.PCI0.LNKB irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 10+ low,level,sharable 0.8.1 \_SB_.PCI0.LNKC irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 5+ low,level,sharable 0.8.2 \_SB_.PCI0.LNKD irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 11+ low,level,sharable 0.8.3 \_SB_.PCI0.LNKB irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 10+ low,level,sharable 0.9.0 \_SB_.PCI0.LNKC irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 5+ low,level,sharable 0.9.1 \_SB_.PCI0.LNKD irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 11+ low,level,sharable 0.9.2 \_SB_.PCI0.LNKA irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 12+ low,level,sharable 0.9.3 \_SB_.PCI0.LNKC irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 5+ low,level,sharable 0.6.0 \_SB_.PCI0.LNKD irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 11+ low,level,sharable 0.6.1 \_SB_.PCI0.LNKA irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 12+ low,level,sharable 0.6.2 \_SB_.PCI0.LNKB irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 10+ low,level,sharable 0.6.3 \_SB_.PCI0.LNKD irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 11+ low,level,sharable 0.11.0 \_SB_.PCI0.LNKA irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 12+ low,level,sharable 0.11.1 \_SB_.PCI0.LNKB irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 10+ low,level,sharable 0.11.2 \_SB_.PCI0.LNKC irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 5+ low,level,sharable 0.11.3 \_SB_.PCI0.LNKB irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 10+ low,level,sharable 0.7.0 \_SB_.PCI0.LNKC irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 5+ low,level,sharable 0.7.1 \_SB_.PCI0.LNKD irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 11+ low,level,sharable 0.7.2 \_SB_.PCI0.LNKA irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 12+ low,level,sharable 0.7.3 \_SB_.PCI0.LNKA irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 12+ low,level,sharable 0.1.0 \_SB_.PCI0.LNKB irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 10+ low,level,sharable 0.1.1 \_SB_.PCI0.LNKC irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 5+ low,level,sharable 0.1.2 \_SB_.PCI0.LNKD irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 11+ low,level,sharable 0.1.3 pci0: on pcib0 pci0: physical bus=0 map[10]: type 3, range 32, base e0000000, size 26, enabled found-> vendor=0x1106, dev=0x0601, revid=0x05 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2290, cachelnsz=0 (dwords) lattimer=0x08 (240 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1106, dev=0x8601, revid=0x00 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0xa230, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x0c (3000 ns), maxlat=0x00 (0 ns) found-> vendor=0x1106, dev=0x0686, revid=0x40 bus=0, slot=7, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0087, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000c000, size 4, enabled found-> vendor=0x1106, dev=0x0571, revid=0x06 bus=0, slot=7, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000c400, size 5, enabled found-> vendor=0x1106, dev=0x3038, revid=0x1a bus=0, slot=7, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=255 powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000c800, size 5, enabled found-> vendor=0x1106, dev=0x3038, revid=0x1a bus=0, slot=7, func=3 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=255 powerspec 2 supports D0 D3 current D0 found-> vendor=0x1106, dev=0x3057, revid=0x40 bus=0, slot=7, func=4 class=06-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 0000cc00, size 8, enabled map[14]: type 4, range 32, base 0000d000, size 2, enabled map[18]: type 4, range 32, base 0000d400, size 2, enabled pcib0: matched entry for 0.7.INTC (src \_SB_.PCI0.LNKD) pcib0: possible interrupts: 1 3 4 5 6 7 10 11 12 14 15 ACPI PCI link arbitrated settings: \_SB_.PCI0.LNKA (references 6, priority 124194): interrupts: 11 10 5 12 7 6 4 3 15 14 1 penalty: 240 240 290 5240 5240 5240 5240 5240 50240 50240100240 \_SB_.PCI0.LNKB (references 6, priority 124194): interrupts: 11 10 5 12 7 6 4 3 15 14 1 penalty: 240 240 290 5240 5240 5240 5240 5240 50240 50240100240 \_SB_.PCI0.LNKC (references 6, priority 124194): interrupts: 11 10 5 12 7 6 4 3 15 14 1 penalty: 240 240 290 5240 5240 5240 5240 5240 50240 50240100240 \_SB_.PCI0.LNKD (references 6, priority 124194): interrupts: 11 10 5 12 7 6 4 3 15 14 1 penalty: 240 240 290 5240 5240 5240 5240 5240 50240 50240100240 pcib0: slot 7 INTC routed to irq 11 via \_SB_.PCI0.LNKD found-> vendor=0x1106, dev=0x3058, revid=0x50 bus=0, slot=7, func=5 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 0000d800, size 8, enabled map[14]: type 1, range 32, base e5810000, size 8, enabled pcib0: matched entry for 0.8.INTA (src \_SB_.PCI0.LNKA) pcib0: possible interrupts: 1 3 4 5 6 7 10 11 12 14 15 ACPI PCI link arbitrated settings: \_SB_.PCI0.LNKA (references 6, priority 125667): interrupts: 10 5 11 12 7 6 4 3 15 14 1 penalty: 480 530 540 5480 5480 5480 5480 5480 50480 50480100480 \_SB_.PCI0.LNKB (references 6, priority 125667): interrupts: 10 5 11 12 7 6 4 3 15 14 1 penalty: 480 530 540 5480 5480 5480 5480 5480 50480 50480100480 \_SB_.PCI0.LNKC (references 6, priority 125667): interrupts: 10 5 11 12 7 6 4 3 15 14 1 penalty: 480 530 540 5480 5480 5480 5480 5480 50480 50480100480 pcib0: slot 8 INTA routed to irq 12 via \_SB_.PCI0.LNKA found-> vendor=0x10ec, dev=0x8139, revid=0x10 bus=0, slot=8, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns) intpin=a, irq=12 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000dc00, size 8, enabled map[14]: type 1, range 32, base e5811000, size 8, enabled pcib0: matched entry for 0.9.INTA (src \_SB_.PCI0.LNKB) pcib0: possible interrupts: 1 3 4 5 6 7 10 11 12 14 15 ACPI PCI link arbitrated settings: \_SB_.PCI0.LNKB (references 6, priority 127140): interrupts: 10 5 11 7 6 4 3 12 15 14 1 penalty: 720 770 780 5720 5720 5720 5720 5780 50720 50720100720 \_SB_.PCI0.LNKC (references 6, priority 127140): interrupts: 10 5 11 7 6 4 3 12 15 14 1 penalty: 720 770 780 5720 5720 5720 5720 5780 50720 50720100720 pcib0: slot 9 INTA routed to irq 10 via \_SB_.PCI0.LNKB found-> vendor=0x10ec, dev=0x8139, revid=0x10 bus=0, slot=9, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000e000, size 8, enabled map[14]: type 1, range 32, base e5812000, size 8, enabled pcib0: matched entry for 0.11.INTA (src \_SB_.PCI0.LNKD) pcib0: slot 11 INTA is already routed to irq 11 found-> vendor=0x10ec, dev=0x8139, revid=0x10 bus=0, slot=11, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 agp0: mem 0xe0000000-0xe3ffffff at device 0.0 on pci0 agp0: Reserved 0x4000000 bytes for rid 0x10 type 3 at 0xe0000000 agp0: allocating GATT for aperture of size 256M pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xf000-0xfff pcib1: memory decode 0xe4000000-0xe57fffff pcib1: prefetched decode 0xfff00000-0xfffff pci1: on pcib1 pci1: physical bus=1 map[10]: type 1, range 32, base e4000000, size 23, enabled pcib1: device (null) requested decoded memory range 0xe4000000-0xe47fffff map[14]: type 1, range 32, base e5000000, size 17, enabled pcib1: device (null) requested decoded memory range 0xe5000000-0xe501ffff map[18]: type 1, range 32, base e4800000, size 23, enabled pcib1: device (null) requested decoded memory range 0xe4800000-0xe4ffffff pcib0: matched entry for 0.1.INTA (src \_SB_.PCI0.LNKA) pcib0: slot 1 INTA is already routed to irq 12 pcib1: slot 0 INTA is routed to irq 12 found-> vendor=0x1023, dev=0x8500, revid=0x6a bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=12 powerspec 1 supports D0 D1 D2 D3 current D0 pci1: at device 0.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xc000-0xc00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xc000 ata0: channel #0 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata0-slave: stat=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 ata0: [MPSAFE] ata1: channel #1 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=01 ostat0=50 ostat1=ff ata1-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata1: reset tp2 stat0=50 stat1=00 devices=0x1 ata1: [MPSAFE] uhci0: port 0xc400-0xc41f at device 7.2 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xc400 pcib0: matched entry for 0.7.INTD (src \_SB_.PCI0.LNKA) pcib0: slot 7 INTD is already routed to irq 12 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xc800-0xc81f at device 7.3 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xc800 pcib0: matched entry for 0.7.INTD (src \_SB_.PCI0.LNKA) pcib0: slot 7 INTD is already routed to irq 12 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pci0: at device 7.4 (no driver attached) pcm0: port 0xd400-0xd403,0xd000-0xd003,0xcc00-0xccff irq 11 at device 7.5 on pci0 pcm0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xcc00 pcm0: [GIANT-LOCKED] pcm0: pcm0: Codec features headphone, 18 bit DAC, 18 bit ADC, 5 bit master volume, Realtek 3D Stereo Enhancement pcm0: Primary codec extended features variable rate PCM, reserved 1, AMAP, reserved 4 pcm0: sndbuf_setmap 21d000, 1000; 0xc1669000 -> 21d000 pcm0: sndbuf_setmap 25f000, 1000; 0xc166b000 -> 25f000 rl0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xd800 rl0: port 0xd800-0xd8ff mem 0xe5810000-0xe58100ff irq 12 at device 8.0 on pci0 miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: bpf attached rl0: Ethernet address: 00:40:f4:67:ec:84 rl0: [MPSAFE] rl1: Reserved 0x100 bytes for rid 0x10 type 4 at 0xdc00 rl1: port 0xdc00-0xdcff mem 0xe5811000-0xe58110ff irq 10 at device 9.0 on pci0 miibus1: on rl1 rlphy1: on miibus1 rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl1: bpf attached rl1: Ethernet address: 00:40:f4:67:ec:83 rl1: [MPSAFE] rl2: Reserved 0x100 bytes for rid 0x10 type 4 at 0xe000 rl2: port 0xe000-0xe0ff mem 0xe5812000-0xe58120ff irq 11 at device 11.0 on pci0 miibus2: on rl2 rlphy2: on miibus2 rlphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl2: bpf attached rl2: Ethernet address: 00:40:f4:67:ec:82 rl2: [MPSAFE] sio0: irq maps: 0x1 0x11 0x1 0x1 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console sio1: irq maps: 0x1 0x9 0x1 0x1 sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A unknown: not probed (disabled) ppc0: using extended I/O port range ppc0: EPP SPP ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: on ppc0 plip0: on ppbus0 plip0: bpf attached lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 unknown: not probed (disabled) unknown: not probed (disabled) atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0067 atkbd: keyboard ID 0x41ab (2) kbdc: RESET_KBD return code:00fa kbdc: RESET_KBD status:00aa kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it ppc: ppc0 already exists; skipping it sio: sio0 already exists; skipping it sio: sio1 already exists; skipping it Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xcc000-0xcffff,0xc0000-0xcbfff on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) pcic0 failed to probe at port 0x3e0 iomem 0xd0000 on isa0 pcic1: not probed (disabled) sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0e 0f 00 00 07 80 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff EGA/VGA parameters to be used for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. procfs registered Timecounter "TSC" frequency 532639770 Hz quality 800 Timecounters tick every 10.000 msec lo0: bpf attached DUMMYNET initialized (011031) ipfw2 initialized, divert enabled, rule-based forwarding disabled, default to accept, logging disabled ata0-master: pio=0x0c wdma=0x22 udma=0x44 cable=80pin ata0-master: setting PIO4 on VIA 82C686B chip ata0-master: setting UDMA66 on VIA 82C686B chip ad0: ATA-5 disk at ata0-master ad0: 9590MB (19640880 sectors), 19485 C, 16 H, 63 S, 512 B ad0: 16 secs/int, 1 depth queue, UDMA66 GEOM: new disk ad0 ata1-master: pio=0x0c wdma=0xffffffff udma=0xffffffff cable=40pin ata1-master: setting PIO4 on VIA 82C686B chip ata1-master: setting PIO4 on VIA 82C686B chip ad2: FAILURE - SETFEATURES ENABLE RCACHE status=51 error=4 ad2: FAILURE - SETFEATURES ENABLE WCACHE status=51 error=4 ad2: ATA-0 disk at ata1-master ad2: 489MB (1001952 sectors), 994 C, 16 H, 63 S, 512 B ad2: 1 secs/int, 1 depth queue, PIO4 [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/15/63 s:63 l:19640817 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad0s1, start 32256 length 10056098304 end 10056130559 GEOM: new disk ad2 GEOM: Configure ad0s1a, start 536870912 length 9519227392 end 10056098303 GEOM: Configure ad0s1b, start 0 length 536870912 end 536870911 GEOM: Configure ad0s1c, start 0 length 10056098304 end 10056098303 [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):488/63/32 s:32 l:1001440 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad2s1, start 16384 length 512737280 end 512753663 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 GEOM: Configure ad2s1a, start 8192 length 512729088 end 512737279 GEOM: Configure ad2s1c, start 0 length 512737280 end 512737279 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 Mounting root from ufs:/dev/ad0s1a start_init: trying /sbin/init Enter full pathname of shell or RETURN for /bin/sh: # dd if=/dev/ad2s1a of=/dev/null bs=64k count=64 64+0 records in 64+0 records out 4194304 bytes transferred in 0.708893 secs (5916695 bytes/sec) --Apple-Mail-4-1000395906 Content-Transfer-Encoding: 7bit Content-Type: text/plain; x-unix-mode=0644; name="dmesg-6.txt" Content-Disposition: attachment; filename=dmesg-6.txt OK boot -vs GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base=0000000000000000 len=00000000000a0000 SMAP type=02 base=00000000000f0000 len=0000000000010000 SMAP type=02 base=00000000ffff0000 len=0000000000010000 SMAP type=01 base=0000000000100000 len=000000001f6f0000 SMAP type=03 base=000000001f7f3000 len=000000000000d000 SMAP type=04 base=000000001f7f0000 len=0000000000003000 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-BETA3 #5: Sun Aug 28 17:43:50 CEST 2005 root@little:/usr/obj/usr/src/sys/LITTLE Preloaded elf kernel "/boot/kernel/kernel" at 0xc06b8000. Preloaded elf module "/boot/modules/agp.ko" at 0xc06b81d8. Preloaded elf module "/boot/modules/io.ko" at 0xc06b8284. Preloaded elf module "/boot/modules/mem.ko" at 0xc06b832c. Preloaded elf module "/boot/modules/random.ko" at 0xc06b83d8. module agp already present! Calibrating clock(s) ... i8254 clock: 1193103 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 532639997 Hz CPU: VIA C3 Samuel 2 (532.64-MHz 686-class CPU) Origin = "CentaurHauls" Id = 0x673 Stepping = 3 Features=0x803035 real memory = 528416768 (503 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009ffff, 651264 bytes (159 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000825000 - 0x000000001eedbfff, 510357504 bytes (124599 pages) avail memory = 511975424 (488 MB) bios32: Found BIOS32 Service Directory header at 0xc00fb090 bios32: Entry = 0xfb500 (c00fb500) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xb530 pnpbios: Found PnP BIOS data at 0xc00fbfd0 pnpbios: Entry = f0000:c000 Rev = 1.0 Other BIOS signatures found: null: io: mem: random: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface cpu0 on motherboard pci_open(1): mode 1 addr port (0x0cf8) is 0x80000060 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=06011106) pcibios: BIOS version 2.10 Found $PIR table, 7 entries at 0xc00fde40 PCI-Only Interrupts: 5 10 11 12 Location Bus Device Pin Link IRQs slot 1 0 8 A 0x01 3 4 5 7 9 10 11 12 14 15 slot 1 0 8 B 0x02 3 4 5 7 9 10 11 12 14 15 slot 1 0 8 C 0x03 3 4 5 7 9 10 11 12 14 15 slot 1 0 8 D 0x05 3 4 5 7 9 10 11 12 14 15 slot 2 0 9 A 0x02 3 4 5 7 9 10 11 12 14 15 slot 2 0 9 B 0x03 3 4 5 7 9 10 11 12 14 15 slot 2 0 9 C 0x05 3 4 5 7 9 10 11 12 14 15 slot 2 0 9 D 0x01 3 4 5 7 9 10 11 12 14 15 slot 3 0 6 A 0x03 3 4 5 7 9 10 11 12 14 15 slot 3 0 6 B 0x05 3 4 5 7 9 10 11 12 14 15 slot 3 0 6 C 0x01 3 4 5 7 9 10 11 12 14 15 slot 3 0 6 D 0x02 3 4 5 7 9 10 11 12 14 15 slot 4 0 11 A 0x05 3 4 5 7 9 10 11 12 14 15 slot 4 0 11 B 0x01 3 4 5 7 9 10 11 12 14 15 slot 4 0 11 C 0x02 3 4 5 7 9 10 11 12 14 15 slot 4 0 11 D 0x03 3 4 5 7 9 10 11 12 14 15 slot 5 0 7 A 0x02 3 4 5 7 9 10 11 12 14 15 slot 5 0 7 B 0x03 3 4 5 7 9 10 11 12 14 15 slot 5 0 7 C 0x05 3 4 5 7 9 10 11 12 14 15 slot 5 0 7 D 0x01 3 4 5 7 9 10 11 12 14 15 embedded 0 1 A 0x01 3 4 5 7 9 10 11 12 14 15 embedded 0 1 B 0x02 3 4 5 7 9 10 11 12 14 15 embedded 0 1 C 0x03 3 4 5 7 9 10 11 12 14 15 embedded 0 1 D 0x05 3 4 5 7 9 10 11 12 14 15 embedded 0 7 C 0x03 3 4 5 7 9 10 11 12 14 15 embedded 0 7 D 0x05 3 4 5 7 9 10 11 12 14 15 pcib0: pcibus 0 on motherboard pir0: on motherboard $PIR: Links after initial probe: Link IRQ Rtd Ref IRQs 0x1 255 N 6 3 4 5 7 9 10 11 12 14 15 0x2 255 N 6 3 4 5 7 9 10 11 12 14 15 0x3 255 N 7 3 4 5 7 9 10 11 12 14 15 0x5 255 N 7 3 4 5 7 9 10 11 12 14 15 $PIR: Found matching pin for 0.8.INTA at func 0: 12 $PIR: Found matching pin for 0.9.INTA at func 0: 10 $PIR: Found matching pin for 0.11.INTA at func 0: 11 $PIR: Found matching pin for 0.7.INTC at func 5: 5 $PIR: BIOS IRQ 5 for 0.7.INTC does not match link 0x5 irq 11 $PIR: Found matching pin for 0.7.INTD at func 2: 255 $PIR: Found matching pin for 0.7.INTD at func 3: 255 $PIR: Found matching pin for 0.7.INTC at func 5: 5 $PIR: Found matching pin for 0.7.INTD at func 2: 255 $PIR: Found matching pin for 0.7.INTD at func 3: 255 $PIR: Links after initial IRQ discovery: Link IRQ Rtd Ref IRQs 0x1 12 Y 6 3 4 5 7 9 10 11 12 14 15 0x2 10 Y 6 3 4 5 7 9 10 11 12 14 15 0x3 5 Y 7 3 4 5 7 9 10 11 12 14 15 0x5 11 Y 7 3 4 5 7 9 10 11 12 14 15 $PIR: IRQs used by BIOS: 5 10 11 12 $PIR: Interrupt Weights: [ 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ] [ 0 0 0 0 0 7 0 0 0 0 6 7 6 0 0 0 ] pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x1106, dev=0x0601, revid=0x05 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2290, cachelnsz=0 (dwords) lattimer=0x08 (240 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 3, range 32, base e0000000, size 26, enabled found-> vendor=0x1106, dev=0x8601, revid=0x00 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0xa230, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x0c (3000 ns), maxlat=0x00 (0 ns) found-> vendor=0x1106, dev=0x0686, revid=0x40 bus=0, slot=7, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0087, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 found-> vendor=0x1106, dev=0x0571, revid=0x06 bus=0, slot=7, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000c000, size 4, enabled found-> vendor=0x1106, dev=0x3038, revid=0x1a bus=0, slot=7, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=255 powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000c400, size 5, enabled found-> vendor=0x1106, dev=0x3038, revid=0x1a bus=0, slot=7, func=3 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=255 powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000c800, size 5, enabled found-> vendor=0x1106, dev=0x3057, revid=0x40 bus=0, slot=7, func=4 class=06-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 found-> vendor=0x1106, dev=0x3058, revid=0x50 bus=0, slot=7, func=5 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=5 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 0000cc00, size 8, enabled map[14]: type 4, range 32, base 0000d000, size 2, enabled map[18]: type 4, range 32, base 0000d400, size 2, enabled $PIR: 0:7 INTC routed to irq 5 found-> vendor=0x10ec, dev=0x8139, revid=0x10 bus=0, slot=8, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns) intpin=a, irq=12 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000d800, size 8, enabled map[14]: type 1, range 32, base e5810000, size 8, enabled $PIR: 0:8 INTA routed to irq 12 found-> vendor=0x10ec, dev=0x8139, revid=0x10 bus=0, slot=9, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000dc00, size 8, enabled map[14]: type 1, range 32, base e5811000, size 8, enabled $PIR: 0:9 INTA routed to irq 10 found-> vendor=0x10ec, dev=0x8139, revid=0x10 bus=0, slot=11, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000e000, size 8, enabled map[14]: type 1, range 32, base e5812000, size 8, enabled $PIR: 0:11 INTA routed to irq 11 agp0: mem 0xe0000000-0xe3ffffff at device 0.0 on pci0 agp0: Reserved 0x4000000 bytes for rid 0x10 type 3 at 0xe0000000 agp0: allocating GATT for aperture of size 256M pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xf000-0xfff pcib1: memory decode 0xe4000000-0xe57fffff pcib1: prefetched decode 0xfff00000-0xfffff pci1: on pcib1 pci1: physical bus=1 found-> vendor=0x1023, dev=0x8500, revid=0x6a bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=12 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base e4000000, size 23, enabled pcib1: (null) requested memory range 0xe4000000-0xe47fffff: good map[14]: type 1, range 32, base e5000000, size 17, enabled pcib1: (null) requested memory range 0xe5000000-0xe501ffff: good map[18]: type 1, range 32, base e4800000, size 23, enabled pcib1: (null) requested memory range 0xe4800000-0xe4ffffff: good $PIR: 0:1 INTA routed to irq 12 pcib1: slot 0 INTA is routed to irq 12 pci1: at device 0.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc000-0xc00f at device 7.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xc000 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 ata0: [MPSAFE] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=01 ostat0=50 ostat1=ff ata1: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata1: reset tp2 stat0=50 stat1=00 devices=0x1 ata1: [MPSAFE] pci0: at device 7.2 (no driver attached) pci0:7:2: Transition from D0 to D3 pci0: at device 7.3 (no driver attached) pci0:7:3: Transition from D0 to D3 pci0: at device 7.4 (no driver attached) pci0:7:4: Transition from D0 to D3 pci0: at device 7.5 (no driver attached) pci0:7:5: Transition from D0 to D3 pci0: at device 8.0 (no driver attached) pci0:8:0: Transition from D0 to D3 pci0: at device 9.0 (no driver attached) pci0:9:0: Transition from D0 to D3 pci0: at device 11.0 (no driver attached) pci0:11:0: Transition from D0 to D3 pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete pnpbios: 14 devices, largest 69 bytes PNP0200: adding dma mask 0x10 PNP0200: adding io range 0-0xf, size=0x10, align=0 PNP0200: adding io range 0x81-0x83, size=0x3, align=0 PNP0200: adding io range 0x87-0x87, size=0x1, align=0 PNP0200: adding io range 0x89-0x8b, size=0x3, align=0 PNP0200: adding io range 0x8f-0x91, size=0x3, align=0 PNP0200: adding io range 0xc0-0xdf, size=0x20, align=0 pnpbios: handle 1 device ID PNP0200 (0002d041) PNP0100: adding irq mask 0x1 PNP0100: adding io range 0x40-0x43, size=0x4, align=0 pnpbios: handle 2 device ID PNP0100 (0001d041) PNP0b00: adding irq mask 0x100 PNP0b00: adding io range 0x70-0x71, size=0x2, align=0 pnpbios: handle 3 device ID PNP0b00 (000bd041) PNP0303: adding irq mask 0x2 PNP0303: adding io range 0x60-0x60, size=0x1, align=0 PNP0303: adding io range 0x64-0x64, size=0x1, align=0 pnpbios: handle 4 device ID PNP0303 (0303d041) PNP0800: adding io range 0x61-0x61, size=0x1, align=0 pnpbios: handle 5 device ID PNP0800 (0008d041) PNP0c04: adding irq mask 0x2000 PNP0c04: adding io range 0xf0-0xff, size=0x10, align=0 pnpbios: handle 6 device ID PNP0c04 (040cd041) PNP0c01: adding fixed memory32 range 0-0x9ffff, size=0xa0000 PNP0c01: adding fixed memory32 range 0xfffe0000-0xffffffff, size=0x20000 PNP0c01: adding fixed memory32 range 0xfee00000-0xfee0ffff, size=0x10000 PNP0c01: adding fixed memory32 range 0x100000-0xffffff, size=0xf00000 pnpbios: handle 7 device ID PNP0c01 (010cd041) PNP0c02: adding fixed memory32 range 0xf0000-0xf3fff, size=0x4000 PNP0c02: adding fixed memory32 range 0xf4000-0xf7fff, size=0x4000 PNP0c02: adding fixed memory32 range 0xf8000-0xfffff, size=0x8000 PNP0c02: adding fixed memory32 range 0xcc000-0xcffff, size=0x4000 pnpbios: handle 8 device ID PNP0c02 (020cd041) PNP0a03: adding io range 0x4d0-0x4d1, size=0x2, align=0 PNP0a03: adding io range 0xcf8-0xcff, size=0x8, align=0 PNP0a03: adding io range 0x4000-0x407f, size=0x80, align=0 PNP0a03: adding io range 0x4080-0x40ff, size=0x80, align=0 PNP0a03: adding io range 0x5000-0x501f, size=0x20, align=0 PNP0a03: adding io range 0x6000-0x607f, size=0x80, align=0 pnpbios: handle 9 device ID PNP0a03 (030ad041) PNP0700: adding dma mask 0x4 PNP0700: adding io range 0x3f0-0x3f5, size=0x6, align=0 PNP0700: adding io range 0x3f7-0x3f7, size=0x1, align=0 PNP0700: adding irq mask 0x40 pnpbios: handle 11 device ID PNP0700 (0007d041) PNP0501: adding irq mask 0x10 PNP0501: adding io range 0x3f8-0x3ff, size=0x8, align=0 pnpbios: handle 12 device ID PNP0501 (0105d041) PNP0501: adding irq mask 0x8 PNP0501: adding io range 0x2f8-0x2ff, size=0x8, align=0 pnpbios: handle 13 device ID PNP0501 (0105d041) PNP0400: adding irq mask 0x80 PNP0400: adding io range 0x378-0x37f, size=0x8, align=0 pnpbios: handle 14 device ID PNP0400 (0004d041) ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcbfff,0xcc000-0xcffff on isa0 atkbd: the current kbd controller command byte 0067 atkbd: keyboard ID 0x41ab (2) kbdc: RESET_KBD return code:00fa kbdc: RESET_KBD status:00aa sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: current command byte:0067 kbdc: TEST_AUX_PORT status:0000 kbdc: RESET_AUX return code:00fe kbdc: RESET_AUX return code:00fe kbdc: RESET_AUX return code:00fe kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 psm0: failed to reset the aux device. bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) pcic0 failed to probe at port 0x3e0 iomem 0xd0000 on isa0 pcic1: not probed (disabled) ppc0 failed to probe at irq 7 on isa0 sio0: irq maps: 0x1 0x11 0x1 0x1 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A, console sio1: irq maps: 0x1 0x9 0x1 0x1 sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vt0: not probed (disabled) isa_probe_children: probing PnP devices unknown: can't assign resources (port) unknown: at port 0x60 on isa0 unknown: failed to probe at port 0x61 on isa0 unknown: can't assign resources (memory) unknown: at iomem 0-0x9ffff on isa0 unknown: can't assign resources (memory) unknown: at iomem 0xf0000-0xf3fff,0xf4000-0xf7fff,0xf8000-0xfffff,0xcc000-0xcffff on isa0 unknown: failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 unknown: can't assign resources (port) unknown: at port 0x3f8-0x3ff on isa0 unknown: can't assign resources (port) unknown: at port 0x2f8-0x2ff on isa0 unknown: failed to probe at port 0x378-0x37f irq 7 on isa0 Device configuration finished. Timecounter "TSC" frequency 532639997 Hz quality 800 Timecounters tick every 1.000 msec lo0: bpf attached ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA66 cable=80 wire ad0: setting PIO4 on VIA 82C686B chip ad0: setting UDMA66 on VIA 82C686B chip ad0: 9590MB at ata0-master UDMA66 ad0: 19640880 sectors [19485C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad0 ata1-master: pio=PIO4 wdma=BIOSDMA udma=BIOSDMA cable=40 wire ad2: setting PIO4 on VIA 82C686B chip ad2: 489MB at ata1-master PIO4 ad2: 1001952 sectors [994C/16H/63S] 1 sectors/interrupt 1 depth queue GEOM: new disk ad2 Trying to mount root from ufs:/dev/ad3s1a Manual root filesystem specification: : Mount using filesystem eg. ufs:da0s1a ? List valid disstray irq7 k boot devices Abort manual input mountroot> ufsV: Trying to mount root from ufs: Manual root filesystem specification: : Mount using filesystem eg. ufs:da0s1a ? List valid disk boot devices Abort manual input mountroot> ufs:/dev/ad2s1a Trying to mount root from ufs:/dev/ad2s1a start_init: trying /sbin/init KDB: enter: manual escape to debstray irq7 ugger [thread pid 13 tid 100003 ] Stopped at kdb_enter+0x2b: nop db> ps pid proc uid ppid pgrp flag stat wmesg wchan cmd 39 c12ef000 0 0 0 0000204 [SLPQ - 0xd4c87d08][SLP] schedcpu 38 c11c7c48 0 0 0 0000204 [SLPQ vlruwt 0xc11c7c48][SLP] vnlru 37 c120c000 0 0 0 0000204 [SLPQ syncer 0xc06079fc][SLP] syncer 36 c120c20c 0 0 0 0000204 [SLPQ psleep 0xc060cb2c][SLP] bufdaemon 9 c120c418 0 0 0 000020c [RUNQ] pagezero 8 c120c624 0 0 0 0000204 [SLPQ psleep 0xc060fdb4][SLP] vmdaemon 7 c120c830 0 0 0 0000204 [SLPQ psleep 0xc060fd70][SLP] pagedaemon 35 c120ca3c 0 0 0 0000204 [IWAIT] swi0: sio 34 c120cc48 0 0 0 0000204 [IWAIT] swi6:+ 33 c120d000 0 0 0 0000204 [IWAIT] swi6: task queue 32 c120d20c 0 0 0 0000204 [IWAIT] swi2: cambio 6 c120d418 0 0 0 0000204 [SLPQ - 0xc1184e00][SLP] kqueue taskq 31 c11bf624 0 0 0 0000204 [IWAIT] swi5:+ 5 c11bf830 0 0 0 0000204 [SLPQ - 0xc11d3080][SLP] thread taskq 30 c11bfa3c 0 0 0 0000204 [SLPQ - 0xc06b45e0][SLP] yarrow 4 c11bfc48 0 0 0 0000204 [SLPQ - 0xc06051a8][SLP] g_down 3 c11c7000 0 0 0 0000204 [SLPQ - 0xc06051a4][SLP] g_up 2 c11c720c 0 0 0 0000204 [SLPQ - 0xc060519c][SLP] g_event 29 c11c7418 0 0 0 0000204 [IWAIT] swi3: vm 28 c11c7624 0 0 0 000020c [RUNQ] swi4: clock sio 27 c11c7830 0 0 0 0000204 [IWAIT] swi1: net 26 c11c7a3c 0 0 0 0000204 [IWAIT] irq15: ata1 25 c118b20c 0 0 0 0000204 [IWAIT] irq14: ata0 24 c118b418 0 0 0 0000204 [IWAIT] irq13: 23 c118b624 0 0 0 0000204 [IWAIT] irq12: 22 c118b830 0 0 0 0000204 [IWAIT] irq11: 21 c118ba3c 0 0 0 0000204 [IWAIT] irq10: 20 c118bc48 0 0 0 0000204 [IWAIT] irq9: 19 c11bf000 0 0 0 0000204 [IWAIT] irq8: rtc 18 c11bf20c 0 0 0 0000204 [IWAIT] irq7: 17 c11bf418 0 0 0 0000204 [IWAIT] irq6: 16 c1185000 0 0 0 0000204 [IWAIT] irq5: 15 c118520c 0 0 0 0000204 [IWAIT] irq4: sio0 14 c1185418 0 0 0 0000204 [IWAIT] irq3: sio1 13 c1185624 0 0 0 0000204 [CPU 0] irq1: atkbd0 12 c1185830 0 0 0 0000204 [IWAIT] irq0: clk 11 c1185a3c 0 0 0 000020c [Can run] idle 1 c1185c48 0 0 0 0004200 [RUNQ] init 10 c118b000 0 0 0 0000204 [SLPQ ktrace 0xc0605bf8][SLP] ktrace 0 c06052a0 0 0 0 0000200 [IWAIT] swapper db> tr Tracing pid 13 tid 100003 td 0xc1186a80 kdb_enter(c05d155d) at kdb_enter+0x2b scgetc(c06263a0,2,1,c1239300,c0610280) at scgetc+0x498 sckbdevent(c0610280,0,c06263a0) at sckbdevent+0x1c8 atkbd_intr(c0610280,0,d3a86d10,c048cdd5,c0610280) at atkbd_intr+0x20 atkbdintr(c0610280) at atkbdintr+0x16 ithread_loop(c1183d00,d3a86d38) at ithread_loop+0x145 fork_exit(c048cc90,c1183d00,d3a86d38) at fork_exit+0x70 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xd3a86d6c, ebp = 0 --- --Apple-Mail-4-1000395906 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed -- Stefan Bethke Fon +49 170 346 0140 --Apple-Mail-4-1000395906-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 17:32: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 973D016A421; Mon, 29 Aug 2005 17:32:20 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE87C43D69; Mon, 29 Aug 2005 17:32:13 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[10.50.40.201]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Mon, 29 Aug 2005 13:47:30 -0400 From: John Baldwin To: Markus Brueffer Date: Mon, 29 Aug 2005 13:17:23 -0400 User-Agent: KMail/1.8 References: <200508101658.09719.jhb@FreeBSD.org> <200508120916.14378.jhb@FreeBSD.org> <200508291542.46098.markus@freebsd.org> In-Reply-To: <200508291542.46098.markus@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508291317.24624.jhb@FreeBSD.org> Cc: freebsd-current@freebsd.org, Robert Watson Subject: Re: Locking fixes for sf(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 17:32:20 -0000 On Monday 29 August 2005 09:42 am, Markus Brueffer wrote: > Hi John, > > On Friday 12 August 2005 15:16, John Baldwin wrote: > > On Friday 12 August 2005 08:15 am, Christian Brueffer wrote: > > > On Thu, Aug 11, 2005 at 11:24:10AM -0400, John Baldwin wrote: > > > > On Thursday 11 August 2005 11:00 am, Christian Brueffer wrote: > > > > > On Wed, Aug 10, 2005 at 04:58:09PM -0400, John Baldwin wrote: > > > > > > I've fixed up the locking in sf(4) but do not have the hardware > > > > > > to test the changes. Can someone please test these patches? > > > > > > Thanks. > > > > > > > > > > > > http://www.freebsd.org/~jhb/patches/sf_locking.patch > > > > > > > > > > Results in a "recursed on non-recursive mutex" panic. > > > > > Unfortunately the dump looks busted, I'll get a good one tomorrow > > > > > (can also test the my(4) patch then). > > > > > > > > Ok. If you could just get the backtrace from ddb that would probably > > > > be sufficient. Thanks for testing! > > > > > > panic: _mtx_lock_sleep: recursed on non-recursive mutex sf0 @ > > > /usr/home/build/src/sys/modules/sf/.. > > > /../pci/if_sf.c:477 > > > > > > CPUID = 1 > > > KDB: enter: panic > > > [thread pid 220 tid 100072 ] > > > Stopped at kdb_enter+0x30: leave > > > db> tr > > > Tracing pid 220 tid 100072 td 0xc1d63480 > > > kdb_enter(c079421b,1,c0793681,d8945ab4,c1d63480) at kdb_enter+0x30 > > > panic(c0793681,c1ad6ab0,c08ed18a,1dd,1dd) at panic+0x14e > > > _mtx_lock_sleep(c1ac3c4c,c1d63480,0,c08ed18a,1dd) at > > > _mtx_lock_sleep+0x47 _mtx_lock_flags(c1ac3c4c,0,c08ed18a,1dd,0) at > > > _mtx_lock_flags+0x9c > > > sf_ifmedia_upd(c1adb800,1000,c08ed18a,4b7,c1ac3c4c) at > > > sf_ifmedia_upd+0x3e sf_init_locked(c1ac3c4c,0,c08ed18a,4aa,c1adb800) at > > > sf_init_locked+0x4bc sf_init(c1ac3c00,740,c07a8534,8020690c,c1ac3c00) > > > at sf_init+0x39 ether_ioctl(c1adb800,8020690c,c1d67e00,c05a7cd1,0) at > > > ether_ioctl+0x67 sf_ioctl(c1adb800,8020690c,c1d67e00,100,1) at > > > sf_ioctl+0xbb > > > in_ifinit(c1adb800,c1d67e00,c1cef3d0,0,1) at in_ifinit+0x208 > > > in_control(c1dfcde8,8040691a,c1cef3c0,c1adb800,c1d63480) at > > > in_control+0x986 ifioctl(c1dfcde8,8040691a,c1cef3c0,c1d63480,2) at > > > ifioctl+0x1cd > > > soo_ioctl(c1d59d80,8040691a,c1cef3c0,c19dca80,c1d63480) at > > > soo_ioctl+0x3ef ioctl(c1d63480,d8945d04,c,422,3) at ioctl+0x45d > > > syscall(3b,3b,3b,80beac0,1) at syscall+0x2c0 > > > Xint0x80_syscall() at Xint0x80_syscall+0x1f > > > --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x8055473, esp = > > > 0xbfbfe5fc, ebp = 0xbfbfee68 --- > > > > Ah, ok, thanks. This is the first driver I've seen that calls its > > ifmedia_update routine internally. I'll fix this and update the patch. > > Thanks! > > I'm getting this LOR with the latest if_sf.c in RELENG_6: > > lock order reversal > 1st 0xc1b0d7cc sf0 (network driver) @ /usr/src/sys/pci/if_sf.c:1201 > 2nd 0xc07a49e0 Giant (Giant) @ /usr/src/sys/kern/kern_poll.c:460 > KDB: stack backtrace: > kdb_backtrace(c0742772,c07a49e0,c074dd5f,c074dd5f,c073e09e) at > kdb_backtrace+0x2e > witness_checkorder(c07a49e0,9,c073e09e,1cc,18a) at witness_checkorder+0x6c3 > _mtx_lock_flags(c07a49e0,0,c073e09e,1cc,c1b0d780) at _mtx_lock_flags+0x8a > ether_poll_deregister(c1af3000,0,c074def0,5c3,c1af3000) at > ether_poll_deregister+0x2e > sf_stop(c1b0d780,1,c074def0,4be,c1b0d780) at sf_stop+0x52 > sf_init_locked(c1b0d780,0,c074def0,4b1,c1af3000) at sf_init_locked+0x44 > sf_init(c1b0d780,c055f18d,c07ac2c0,8020690c,c1b0d780) at sf_init+0x3a > ether_ioctl(c1af3000,8020690c,c1c19a00,c07423ea,0) at ether_ioctl+0x67 > sf_ioctl(c1af3000,8020690c,c1c19a00,c1c19a7c,1) at sf_ioctl+0x270 > in_ifinit(c1af3000,c1c19a00,c1c6aa10,0,1) at in_ifinit+0x208 > in_control(c1e98de8,8040691a,c1c6aa00,c1af3000,c1c16a80) at > in_control+0x986 ifioctl(c1e98de8,8040691a,c1c6aa00,c1c16a80,2) at > ifioctl+0x1bc > soo_ioctl(c1c57168,8040691a,c1c6aa00,c19d7a80,c1c16a80) at soo_ioctl+0x3ef > ioctl(c1c16a80,d7827d04,c,422,3) at ioctl+0x45d > syscall(3b,3b,3b,8058aa0,0) at syscall+0x2c0 > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x280d17ef, esp = 0xbfbfe99c, > ebp = 0xbfbfe9c8 --- > > brueffer@galaxy:/usr/src/sys/pci > ident if_sf.c > if_sf.c: > $FreeBSD: src/sys/pci/if_sf.c,v 1.82.2.3 2005/08/26 14:50:16 jhb Exp $ > > This results in a stalling network connection (watchdog timeout messages on > the console), sometimes after 5 Minutes, sometimes after several hours. I haven't changed this. This seems to be a problem with DEVICE_POLLING. You probably need to run with debug.mpsafenet=0 with DEVICE_POLLING for now. The polling code in sys/kern/kern_poll.c needs to stop using Giant before it will be safe to use debug.mpsafenet=1 with DEVICE_POLLING. sys/kern/kern_poll.c might need to include a 'NET_NEEDS_GIANT(polling)' line 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 Mon Aug 29 18:15: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 E6C5416A41F for ; Mon, 29 Aug 2005 18:15:06 +0000 (GMT) (envelope-from stb@lassitu.de) Received: from schlepper.zs64.net (schlepper.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4450443D48 for ; Mon, 29 Aug 2005 18:15:05 +0000 (GMT) (envelope-from stb@lassitu.de) Received: from [IPv6:::1] (schlepper [212.12.50.230]) by schlepper.zs64.net (8.13.3/8.12.9) with ESMTP id j7TIEvMm026105; Mon, 29 Aug 2005 20:14:57 +0200 (CEST) (envelope-from stb@lassitu.de) In-Reply-To: <0046E5C3-22EE-4F5D-B2B0-DFF4F0157F6B@lassitu.de> References: <7A0B19EC-2F90-495F-B242-7FB701C32908@lassitu.de> <20050828124321.43365136@Magellan.Leidinger.net> <3923443F-6926-4BB7-8681-40FC68A41B79@lassitu.de> <0046E5C3-22EE-4F5D-B2B0-DFF4F0157F6B@lassitu.de> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Stefan Bethke Date: Mon, 29 Aug 2005 20:14:56 +0200 To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.734) Cc: =?ISO-8859-1?Q?S=F8ren_Schmidt?= Subject: Re: Boot off CF card hangs at "Trying to mount root" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 18:15:07 -0000 Am 29.08.2005 um 19:28 schrieb Stefan Bethke: > Just to make sure I didn't mess up the kernel config, I'll try with > GENERIC. No difference with a GENERIC kernel. Stefan -- Stefan Bethke Fon +49 170 346 0140 From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 18:15: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 8136B16A41F for ; Mon, 29 Aug 2005 18:15:48 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 29ECE43D48 for ; Mon, 29 Aug 2005 18:15:45 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id j7TIFXw1013092; Mon, 29 Aug 2005 11:15:37 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200508291815.j7TIFXw1013092@gw.catspoiler.org> Date: Mon, 29 Aug 2005 11:15:33 -0700 (PDT) From: Don Lewis To: kabaev@gmail.com, doconnor@gsoft.com.au In-Reply-To: <20050825202033.579b3e9c@kan.dnsalias.net> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org Subject: Re: Odd performance problem (hitching) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 18:15:48 -0000 On 25 Aug, Alexander Kabaev wrote: > On Fri, 26 Aug 2005 09:13:53 +0930 > "Daniel O'Connor" wrote: > >> I updated to -current recently (from an earlier -current) and haven't >> changed any kernel options, but now the systems seems to 'hitch' >> fairly frequently. ie the system will run fine then stall for half a >> second or so, then continue as normal. It is most noticeable when >> playing music. >> >> If I turn powerd off and run the CPU at full speed it works better, >> but it still happens on occasion so I am guessing powerd isn't the >> problem per se, but just makes it worse. >> >> I am not 100% sure when the problem started but if I get time I will >> try a binary search to find out.. It believe around 6.0-BETA1 (30 >> July) was OK, but I don't have any more data points yet. >> >> I've attached my dmesg and kernel config file if it helps. >> >> -- >> 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 > > > Can you try backing out this commit? > > http://cvsweb.FreeBSD.org/src/sys/kern/vfs_subr.c.diff?r1=1.641&r2=1.642 Any more info on this problem? I just got my MFC reminder for this change and I don't want to request permission for the MFC until I know for sure that it (or 1.636, which is also has a pending MFC) isn't the cause of the problem. What else is happening on machine when the symptoms occur? I would only expect vfs_subr.c 1.636 and 1.642 to affect the behaviour if there was a lot of file system activity that put pressure on the system to free up vnodes. From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 18:33: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 2D43916A41F for ; Mon, 29 Aug 2005 18:33:15 +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 82BD243D48 for ; Mon, 29 Aug 2005 18:33:14 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.136] (mac.deepcore.dk [194.192.25.136]) by spider.deepcore.dk (8.13.3/8.13.3) with ESMTP id j7TITKkt013002; Mon, 29 Aug 2005 20:29:21 +0200 (CEST) (envelope-from sos@DeepCore.dk) In-Reply-To: <0046E5C3-22EE-4F5D-B2B0-DFF4F0157F6B@lassitu.de> References: <7A0B19EC-2F90-495F-B242-7FB701C32908@lassitu.de> <20050828124321.43365136@Magellan.Leidinger.net> <3923443F-6926-4BB7-8681-40FC68A41B79@lassitu.de> <0046E5C3-22EE-4F5D-B2B0-DFF4F0157F6B@lassitu.de> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= Date: Mon, 29 Aug 2005 20:33:02 +0200 To: Stefan Bethke X-Mailer: Apple Mail (2.734) X-mail-scanned: by DeepCore Virus & Spam killer v1.12 Cc: freebsd-current@freebsd.org Subject: Re: Boot off CF card hangs at "Trying to mount root" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 18:33:15 -0000 On 29/08/2005, at 19:28, Stefan Bethke wrote: > Am 28.08.2005 um 18:46 schrieb Stefan Bethke: > > >> Compiling boot, loader, and kernel without a CPUTYPE setting fixed =20= >> the boot and loader issues; however, the kernel doesn't seem to be =20= >> happy with the CF card: >> >> ad3: 489MB at ata1-slave PIO4 >> Trying to mount root from ufs:/dev/ad3s1a >> >> Again, I can break into the debugger, but I'm not certain what I =20 >> should be looking at. >> > > OK brought home a couple of useful things; I can now run both the =20 > HD and the CF card at the same time, and I have a serial console. > > Booting into 5-stable from the HD let's me access the CF card just =20 > fine. I've attached a verbose boot from both 5-stable and 6-beta3. > > The most striking difference (to me) is that 5-stable thinks DMA66 =20 > is fine (and my tests show that at least reading is not a problem =20 > at all), while 6-beta wants to do PIO4, but seemingly gets stuck. Uhm, both use PIO4 as far as I can tell.. > Time to add debugging to ata? Enable debugging in ata-all.h and set ATA_R_DEBUG in request->flags =20 early in ata_queue_request() and see how far it gets. I'd suspect subtle timing in the lowest levels though.... - S=F8ren From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 18:36: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 4AE9816A423 for ; Mon, 29 Aug 2005 18:36:01 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F74743D4C for ; Mon, 29 Aug 2005 18:36:00 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[10.50.40.201]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Mon, 29 Aug 2005 14:51:04 -0400 From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 29 Aug 2005 14:24:10 -0400 User-Agent: KMail/1.8 References: <20050828.092209.77060388.imp@bsdimp.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508291424.11549.jhb@FreeBSD.org> Cc: "Bjoern A. Zeeb" , "M. Warner Losh" Subject: Re: LOR route vr0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 18:36:01 -0000 On Sunday 28 August 2005 11:31 am, Bjoern A. Zeeb wrote: > On Sun, 28 Aug 2005, M. Warner Losh wrote: > > In message: > > > > > > "Bjoern A. Zeeb" writes: > > : On Sat, 27 Aug 2005, M. Warner Losh wrote: > > : > > : for the archives... > > : > > : > ock order reversal > > : > 1st 0xc17490e4 rtentry (rtentry) @ sys/netinet/if_ether.c:445 > > : > 2nd 0xc15c94b0 rl1 (network driver) @ sys/pci/if_rl.c:1451 > > : > > : LOR http://sources.zabbadoz.net/freebsd/lor.html#144 > > > > I cut and pasted this one from your LOR site... > > *gnaa* my grep-o-logic failed. I should really really really split > this page... > > I removed the duplicate. > The original one was http://sources.zabbadoz.net/freebsd/lor.html#139 > > > : > and am seeing the following in my newly locked ed driver: > > : > > > : > lock order reversal > > : > 1st 0xc1cb3588 rtentry (rtentry) @ net/route.c:1269 > > : > 2nd 0xc1fd3420 ed1 (network driver) @ > > : > /dell/imp/p4/newcard/src/sys/modules/ed/../../dev/ed/if_ed.c:697 > > : > > : I added this one two though this LOR may not (yet) be seen in > > : the wild. > > : > > : LOR http://sources.zabbadoz.net/freebsd/lor.html#145 > > > > heh. I'm expecting to figure out what the real LOR is here and then > > about 20-25 of the LORs in your list can go away... > > great. let me know the IDs and the patch that will fix them then. Note that all network driver locks are considered the same in witness (they have a lock "type" of MTX_NETWORK_LOCK). You probably want to look at the lock "type" for LORs and don't log duplicate LORs for the same type. The only widespread case of locks that use a type other than their name are network device drivers. I imagine that other device drivers might do this in the future as well. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 18:36: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 B310916A423; Mon, 29 Aug 2005 18:36:01 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9258143D53; Mon, 29 Aug 2005 18:36:00 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[10.50.40.201]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Mon, 29 Aug 2005 14:51:03 -0400 From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 29 Aug 2005 14:13:23 -0400 User-Agent: KMail/1.8 References: <20050827184153.A24510@fledge.watson.org> <20050827.220303.130848154.imp@bsdimp.com> <20050828051917.W52467@fledge.watson.org> In-Reply-To: <20050828051917.W52467@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508291413.25426.jhb@FreeBSD.org> Cc: bzeeb-lists@lists.zabbadoz.net, Robert Watson , dandee@volny.cz, "M. Warner Losh" Subject: Re: LOR route vr0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 18:36:01 -0000 On Sunday 28 August 2005 12:20 am, Robert Watson wrote: > On Sat, 27 Aug 2005, M. Warner Losh wrote: > > : Correct. 'tcp' reflects the global TCP state tables (pcbinfo) locks, > > : and 'tcpinp' is for individual PCBs. If you acquire first a tcpinp and > > : then tcp, the above settings should cause WITNESS to generate a lock > > : order warning. Likewise, both tcp and tcpinp preceed so_snd, so if you > > : acquire a protocol lock after a socket lock, it will get unhappy. > > : WITNESS handles transitive relationships, so it gets connected up to > > : the rest of the lock graph, explicit and implicit, so indirect > > : violations of orders are fully handled. > > > > OK. I've been seeing similar LORs in ed, sn, iwi (ed is my locked > > version of ed, not in tree GIANT locked ed). > > > > I've made the following changes, and the LORs go away (except for one, > > which was unrelated). I further don't get the first place where they > > locks happen that caused the original LORs, so I'm mightly confused. > > Hmm. I've seen another identical report recently -- that when a lock > order is put into WITNESS, reversals against it are not reported. I > wonder if we've got a witness bug on our hands? Note that in this case the problem shows up because of a series of transitive lock orders. It would be useful to see the graph from show witness before you add the hard-coded entries to see why it thinks rtentry comes after MTX_NETWORK_LOCK. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 19:06: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 D129E16A41F; Mon, 29 Aug 2005 19:06:14 +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 8AE0843D60; Mon, 29 Aug 2005 19:06:10 +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.3/8.13.3) with ESMTP id j7TJ697w008672; Mon, 29 Aug 2005 15:06:09 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.3/8.13.3) with ESMTP id j7TJ69fX003410; Mon, 29 Aug 2005 15:06:09 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 48D037304D; Mon, 29 Aug 2005 15:06:09 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050829190609.48D037304D@freebsd-current.sentex.ca> Date: Mon, 29 Aug 2005 15:06:09 -0400 (EDT) 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 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, 29 Aug 2005 19:06:15 -0000 TB --- 2005-08-29 17:22:48 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-08-29 17:22:48 - starting HEAD tinderbox run for amd64/amd64 TB --- 2005-08-29 17:22:48 - cleaning the object tree TB --- 2005-08-29 17:23:19 - checking out the source tree TB --- 2005-08-29 17:23:19 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2005-08-29 17:23:19 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-08-29 17:29:56 - building world (CFLAGS=-O2 -pipe) TB --- 2005-08-29 17:29:56 - cd /src TB --- 2005-08-29 17:29:56 - /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-08-29 19:00:46 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-08-29 19:00:46 - cd /src TB --- 2005-08-29 19:00:46 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Aug 29 19:00:46 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 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -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 /src/sys/dev/vx/if_vx.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -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 /src/sys/dev/vx/if_vx_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 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -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 /src/sys/dev/watchdog/watchdog.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -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 /src/sys/dev/wi/if_wi.c /src/sys/dev/wi/if_wi.c: In function `wi_cmd': /src/sys/dev/wi/if_wi.c:2447: error: `count' undeclared (first use in this function) /src/sys/dev/wi/if_wi.c:2447: error: (Each undeclared identifier is reported only once /src/sys/dev/wi/if_wi.c:2447: error: for each function it appears in.) *** Error code 1 Stop in /obj/amd64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-08-29 19:06:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-08-29 19:06:09 - ERROR: failed to build generic kernel TB --- 2005-08-29 19:06:09 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 19:10: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 6203316A41F for ; Mon, 29 Aug 2005 19:10:11 +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 D62D143D48 for ; Mon, 29 Aug 2005 19:10:10 +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 292431FFE25; Mon, 29 Aug 2005 21:10:08 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id C9F0C1FFE24; Mon, 29 Aug 2005 21:10:05 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id B374E15823; Mon, 29 Aug 2005 19:07:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id A91D31562F; Mon, 29 Aug 2005 19:07:38 +0000 (UTC) Date: Mon, 29 Aug 2005 19:07:38 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: freebsd-current@freebsd.org In-Reply-To: Message-ID: References: <20050827.104631.10908351.imp@bsdimp.com> <20050828.092209.77060388.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Cc: "M. Warner Losh" Subject: Re: LOR route vr0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 19:10:11 -0000 On Sun, 28 Aug 2005, Bjoern A. Zeeb wrote: > On Sun, 28 Aug 2005, M. Warner Losh wrote: > > > In message: "Bjoern A. Zeeb" writes: > > : On Sat, 27 Aug 2005, M. Warner Losh wrote: > > : > > : for the archives... > > : > > : > ock order reversal > > : > 1st 0xc17490e4 rtentry (rtentry) @ sys/netinet/if_ether.c:445 > > : > 2nd 0xc15c94b0 rl1 (network driver) @ sys/pci/if_rl.c:1451 > > : > > : LOR http://sources.zabbadoz.net/freebsd/lor.html#144 > > > > I cut and pasted this one from your LOR site... > > I removed the duplicate. > The original one was http://sources.zabbadoz.net/freebsd/lor.html#139 it was a duplicate of 135 not 139. correcting that. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 19:13: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 694FC16A41F for ; Mon, 29 Aug 2005 19:13:54 +0000 (GMT) (envelope-from stb@lassitu.de) Received: from schlepper.zs64.net (schlepper.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E88243D4C for ; Mon, 29 Aug 2005 19:13:53 +0000 (GMT) (envelope-from stb@lassitu.de) Received: from [IPv6:::1] (schlepper [212.12.50.230]) by schlepper.zs64.net (8.13.3/8.12.9) with ESMTP id j7TJDZYQ027489; Mon, 29 Aug 2005 21:13:36 +0200 (CEST) (envelope-from stb@lassitu.de) In-Reply-To: References: <7A0B19EC-2F90-495F-B242-7FB701C32908@lassitu.de> <20050828124321.43365136@Magellan.Leidinger.net> <3923443F-6926-4BB7-8681-40FC68A41B79@lassitu.de> <0046E5C3-22EE-4F5D-B2B0-DFF4F0157F6B@lassitu.de> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: multipart/mixed; boundary=Apple-Mail-11-1006727391 Message-Id: <9105C2F5-0D77-4B43-AFFA-7558BBEDA26A@lassitu.de> From: Stefan Bethke Date: Mon, 29 Aug 2005 21:13:35 +0200 To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= X-Mailer: Apple Mail (2.734) Cc: freebsd-current@freebsd.org Subject: Re: Boot off CF card hangs at "Trying to mount root" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 19:13:54 -0000 --Apple-Mail-11-1006727391 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Thanks for looking into this! Am 29.08.2005 um 20:33 schrieb S=F8ren Schmidt: > On 29/08/2005, at 19:28, Stefan Bethke wrote: > >> Am 28.08.2005 um 18:46 schrieb Stefan Bethke: >> The most striking difference (to me) is that 5-stable thinks DMA66 =20= >> is fine (and my tests show that at least reading is not a problem =20 >> at all), while 6-beta wants to do PIO4, but seemingly gets stuck. >> > Uhm, both use PIO4 as far as I can tell.. > Sorry, no idea what I was looking at. > Enable debugging in ata-all.h and set ATA_R_DEBUG in request->flags =20= > early in ata_queue_request() and see how far it gets. > > I'd suspect subtle timing in the lowest levels though.... > I still have the wrong entry in fstab, so this is from right after =20 specifying the proper root device: --Apple-Mail-11-1006727391 Content-Transfer-Encoding: 7bit Content-Type: text/plain; x-unix-mode=0644; name="atadebug1.txt" Content-Disposition: attachment; filename=atadebug1.txt Trying to mount root from ufs:/dev/ad3s1a Manual root filesystem specification: : Mount using filesystem eg. ufs:da0s1a ? List valid disk boot devices Abort manual input mountroot> ufs:/dev/ad2s1a Trying to mount root from ufs:/dev/ad2s1a ad2: req=0xc17fc898 READ queued ad2: req=0xc17fc898 READ starting ad2: req=0xc17fc898 READ begin transaction ad2: req=0xc17fc898 READ interrupt ad2: req=0xc17fc898 READ end transaction ad2: req=0xc17fc898 READ interrupt ad2: req=0xc17fc898 READ end transaction ad2: req=0xc17fc898 READ interrupt ad2: req=0xc17fc898 READ end transaction ad2: req=0xc17fc898 READ interrupt ad2: req=0xc17fc898 READ end transaction ad2: req=0xc17fc898 READ interrupt ad2: req=0xc17fc898 READ end transaction ad2: req=0xc17fc898 READ interrupt ad2: req=0xc17fc898 READ end transaction ad2: req=0xc17fc898 READ interrupt ad2: req=0xc17fc898 READ end transaction ad2: req=0xc17fc898 READ interrupt ad2: req=0xc17fc898 READ end transaction ad2: req=0xc17fc898 READ interrupt ad2: req=0xc17fc898 READ end transaction ad2: req=0xc17fc898 READ interrupt ad2: req=0xc17fc898 READ end transaction ad2: req=0xc17fc898 READ interrupt ad2: req=0xc17fc898 READ end transaction ad2: req=0xc17fc898 READ interrupt ad2: req=0xc17fc898 READ end transaction ad2: req=0xc17fc898 READ interrupt ad2: req=0xc17fc898 READ end transaction ad2: req=0xc17fc898 READ interrupt ad2: req=0xc17fc898 READ end transaction ad2: req=0xc17fc898 READ interrupt ad2: req=0xc17fc898 READ end transaction ad2: req=0xc17fc898 READ interrupt ad2: req=0xc17fc898 READ end transaction ad2: req=0xc17fc898 READ finish bio_taskqueue ad2: req=0xc17fc898 READ completed entered ad2: req=0xc17fc898 READ completed callback/wakeup ad2: req=0xc17fc7d0 READ queued ad2: req=0xc17fc7d0 READ starting ad2: req=0xc17fc7d0 READ begin transaction ad2: req=0xc17fc7d0 READ interrupt ad2: req=0xc17fc7d0 READ end transaction ad2: req=0xc17fc7d0 READ interrupt ad2: req=0xc17fc7d0 READ end transaction ad2: req=0xc17fc7d0 READ interrupt ad2: req=0xc17fc7d0 READ end transaction ad2: req=0xc17fc7d0 READ interrupt ad2: req=0xc17fc7d0 READ end transaction ad2: req=0xc17fc7d0 READ finish bio_taskqueue ad2: req=0xc17fc7d0 READ completed entered ad2: req=0xc17fc7d0 READ completed callback/wakeup ad2: req=0xc17fc708 READ queued ad2: req=0xc17fc708 READ starting ad2: req=0xc17fc708 READ begin transaction ad2: req=0xc17fc708 READ interrupt ad2: req=0xc17fc708 READ end transaction ad2: req=0xc17fc708 READ interrupt ad2: req=0xc17fc708 READ end transaction ad2: req=0xc17fc708 READ interrupt ad2: req=0xc17fc708 READ end transaction ad2: req=0xc17fc708 READ interrupt ad2: req=0xc17fc708 READ end transaction ad2: req=0xc17fc708 READ interrupt ad2: req=0xc17fc708 READ end transaction ad2: req=0xc17fc708 READ interrupt ad2: req=0xc17fc708 READ end transaction ad2: req=0xc17fc708 READ interrupt ad2: req=0xc17fc708 READ end transaction ad2: req=0xc17fc708 READ interrupt ad2: req=0xc17fc708 READ end transaction ad2: req=0xc17fc708 READ interrupt ad2: req=0xc17fc708 READ end transaction ad2: req=0xc17fc708 READ interrupt ad2: req=0xc17fc708 READ end transaction ad2: req=0xc17fc708 READ interrupt ad2: req=0xc17fc708 READ end transaction ad2: req=0xc17fc708 READ interrupt ad2: req=0xc17fc708 READ end transaction ad2: req=0xc17fc708 READ interrupt ad2: req=0xc17fc708 READ end transaction ad2: req=0xc17fc708 READ interrupt ad2: req=0xc17fc708 READ end transaction ad2: req=0xc17fc708 READ interrupt ad2: req=0xc17fc708 READ end transaction ad2: req=0xc17fc708 READ interrupt ad2: req=0xc17fc708 READ end transaction ad2: req=0xc17fc708 READ interrupt ad2: req=0xc17fc708 READ end transaction ad2: req=0xc17fc708 READ interrupt ad2: req=0xc17fc708 READ end transaction ad2: req=0xc17fc708 READ interrupt ad2: req=0xc17fc708 READ end transaction ad2: req=0xc17fc708 READ interrupt ad2: req=0xc17fc708 READ end transaction ad2: req=0xc17fc708 READ interrupt ad2: req=0xc17fc708 READ end transaction ad2: req=0xc17fc708 READ interrupt ad2: req=0xc17fc708 READ end transaction ad2: req=0xc17fc708 READ interrupt ad2: req=0xc17fc708 READ end transaction ad2: req=0xc17fc708 READ interrupt ad2: req=0xc17fc708 READ end transaction ad2: req=0xc17fc708 READ interrupt ad2: req=0xc17fc708 READ end transaction ad2: req=0xc17fc708 READ interrupt ad2: req=0xc17fc708 READ end transaction ad2: req=0xc17fc708 READ interrupt ad2: req=0xc17fc708 READ end transaction ad2: req=0xc17fc708 READ interrupt ad2: req=0xc17fc708 READ end transaction ad2: req=0xc17fc708 READ interrupt ad2: req=0xc17fc708 READ end transaction ad2: req=0xc17fc708 READ interrupt ad2: req=0xc17fc708 READ end transaction ad2: req=0xc17fc708 READ interrupt ad2: req=0xc17fc708 READ end transaction ad2: req=0xc17fc708 READ interrupt ad2: req=0xc17fc708 READ end transaction ad2: req=0xc17fc708 READ finish bio_taskqueue ad2: req=0xc17fc708 READ completed entered ad2: req=0xc17fc708 READ completed callback/wakeup ad2: req=0xc17fc640 READ queued ad2: req=0xc17fc640 READ starting ad2: req=0xc17fc640 READ begin transaction ad2: req=0xc17fc640 READ interrupt ad2: req=0xc17fc640 READ end transaction ad2: req=0xc17fc640 READ interrupt ad2: req=0xc17fc640 READ end transaction ad2: req=0xc17fc640 READ interrupt ad2: req=0xc17fc640 READ end transaction ad2: req=0xc17fc640 READ interrupt ad2: req=0xc17fc640 READ end transaction ad2: req=0xc17fc640 READ finish bio_taskqueue ad2: req=0xc17fc640 READ completed entered ad2: req=0xc17fc640 READ completed callback/wakeup ad2: req=0xc17fc578 READ queued ad2: req=0xc17fc578 READ starting ad2: req=0xc17fc578 READ begin transaction ad2: req=0xc17fc578 READ interrupt ad2: req=0xc17fc578 READ end transaction ad2: req=0xc17fc578 READ interrupt ad2: req=0xc17fc578 READ end transaction ad2: req=0xc17fc578 READ interrupt ad2: req=0xc17fc578 READ end transaction ad2: req=0xc17fc578 READ interrupt ad2: req=0xc17fc578 READ end transaction ad2: req=0xc17fc578 READ interrupt ad2: req=0xc17fc578 READ end transaction ad2: req=0xc17fc578 READ interrupt ad2: req=0xc17fc578 READ end transaction ad2: req=0xc17fc578 READ interrupt ad2: req=0xc17fc578 READ end transaction ad2: req=0xc17fc578 READ interrupt ad2: req=0xc17fc578 READ end transaction ad2: req=0xc17fc578 READ interrupt ad2: req=0xc17fc578 READ end transaction ad2: req=0xc17fc578 READ interrupt ad2: req=0xc17fc578 READ end transaction ad2: req=0xc17fc578 READ interrupt ad2: req=0xc17fc578 READ end transaction ad2: req=0xc17fc578 READ interrupt ad2: req=0xc17fc578 READ end transaction ad2: req=0xc17fc578 READ interrupt ad2: req=0xc17fc578 READ end transaction ad2: req=0xc17fc578 READ interrupt ad2: req=0xc17fc578 READ end transaction ad2: req=0xc17fc578 READ interrupt ad2: req=0xc17fc578 READ end transaction ad2: req=0xc17fc578 READ interrupt ad2: req=0xc17fc578 READ end transaction ad2: req=0xc17fc578 READ interrupt ad2: req=0xc17fc578 READ end transaction ad2: req=0xc17fc578 READ interrupt ad2: req=0xc17fc578 READ end transaction ad2: req=0xc17fc578 READ interrupt ad2: req=0xc17fc578 READ end transaction ad2: req=0xc17fc578 READ interrupt ad2: req=0xc17fc578 READ end transaction ad2: req=0xc17fc578 READ interrupt ad2: req=0xc17fc578 READ end transaction ad2: req=0xc17fc578 READ interrupt ad2: req=0xc17fc578 READ end transaction ad2: req=0xc17fc578 READ interrupt ad2: req=0xc17fc578 READ end transaction ad2: req=0xc17fc578 READ interrupt ad2: req=0xc17fc578 READ end transaction ad2: req=0xc17fc578 READ interrupt ad2: req=0xc17fc578 READ end transaction ad2: req=0xc17fc578 READ interrupt ad2: req=0xc17fc578 READ end transaction ad2: req=0xc17fc578 READ interrupt ad2: req=0xc17fc578 READ end transaction ad2: req=0xc17fc578 READ interrupt ad2: req=0xc17fc578 READ end transaction ad2: req=0xc17fc578 READ interrupt ad2: req=0xc17fc578 READ end transaction ad2: req=0xc17fc578 READ interrupt ad2: req=0xc17fc578 READ end transaction ad2: req=0xc17fc578 READ interrupt ad2: req=0xc17fc578 READ end transaction ad2: req=0xc17fc578 READ interrupt ad2: req=0xc17fc578 READ end transaction ad2: req=0xc17fc578 READ finish bio_taskqueue ad2: req=0xc17fc578 READ completed entered ad2: req=0xc17fc578 READ completed callback/wakeup ad2: req=0xc17fc4b0 READ queued ad2: req=0xc17fc4b0 READ starting ad2: req=0xc17fc4b0 READ begin transaction ad2: req=0xc17fc4b0 READ interrupt ad2: req=0xc17fc4b0 READ end transaction ad2: req=0xc17fc4b0 READ interrupt ad2: req=0xc17fc4b0 READ end transaction ad2: req=0xc17fc4b0 READ interrupt ad2: req=0xc17fc4b0 READ end transaction ad2: req=0xc17fc4b0 READ interrupt ad2: req=0xc17fc4b0 READ end transaction ad2: req=0xc17fc4b0 READ interrupt ad2: req=0xc17fc4b0 READ end transaction ad2: req=0xc17fc4b0 READ interrupt ad2: req=0xc17fc4b0 READ end transaction ad2: req=0xc17fc4b0 READ interrupt ad2: req=0xc17fc4b0 READ end transaction ad2: req=0xc17fc4b0 READ interrupt ad2: req=0xc17fc4b0 READ end transaction ad2: req=0xc17fc4b0 READ interrupt ad2: req=0xc17fc4b0 READ end transaction ad2: req=0xc17fc4b0 READ interrupt ad2: req=0xc17fc4b0 READ end transaction ad2: req=0xc17fc4b0 READ interrupt ad2: req=0xc17fc4b0 READ end transaction ad2: req=0xc17fc4b0 READ interrupt ad2: req=0xc17fc4b0 READ end transaction ad2: req=0xc17fc4b0 READ interrupt ad2: req=0xc17fc4b0 READ end transaction ad2: req=0xc17fc4b0 READ interrupt ad2: req=0xc17fc4b0 READ end transaction ad2: req=0xc17fc4b0 READ interrupt ad2: req=0xc17fc4b0 READ end transaction ad2: req=0xc17fc4b0 READ interrupt ad2: req=0xc17fc4b0 READ end transaction ad2: req=0xc17fc4b0 READ interrupt ad2: req=0xc17fc4b0 READ end transaction ad2: req=0xc17fc4b0 READ interrupt ad2: req=0xc17fc4b0 READ end transaction ad2: req=0xc17fc4b0 READ interrupt ad2: req=0xc17fc4b0 READ end transaction ad2: req=0xc17fc4b0 READ interrupt ad2: req=0xc17fc4b0 READ end transaction ad2: req=0xc17fc4b0 READ interrupt ad2: req=0xc17fc4b0 READ end transaction ad2: req=0xc17fc4b0 READ interrupt ad2: req=0xc17fc4b0 READ end transaction ad2: req=0xc17fc4b0 READ interrupt ad2: req=0xc17fc4b0 READ end transaction ad2: req=0xc17fc4b0 READ interrupt ad2: req=0xc17fc4b0 READ end transaction ad2: req=0xc17fc4b0 READ interrupt ad2: req=0xc17fc4b0 READ end transaction ad2: req=0xc17fc4b0 READ interrupt ad2: req=0xc17fc4b0 READ end transaction ad2: req=0xc17fc4b0 READ interrupt ad2: req=0xc17fc4b0 READ end transaction ad2: req=0xc17fc4b0 READ interrupt ad2: req=0xc17fc4b0 READ end transaction ad2: req=0xc17fc4b0 READ interrupt ad2: req=0xc17fc4b0 READ end transaction ad2: req=0xc17fc4b0 READ interrupt ad2: req=0xc17fc4b0 READ end transaction ad2: req=0xc17fc4b0 READ interrupt ad2: req=0xc17fc4b0 READ end transaction ad2: req=0xc17fc4b0 READ interrupt ad2: req=0xc17fc4b0 READ end transaction ad2: req=0xc17fc4b0 READ finish bio_taskqueue ad2: req=0xc17fc4b0 READ completed entered ad2: req=0xc17fc4b0 READ completed callback/wakeup ad2: req=0xc17fc3e8 READ queued ad2: req=0xc17fc3e8 READ starting ad2: req=0xc17fc3e8 READ begin transaction ad2: req=0xc17fc3e8 READ interrupt ad2: req=0xc17fc3e8 READ end transaction ad2: req=0xc17fc3e8 READ interrupt ad2: req=0xc17fc3e8 READ end transaction ad2: req=0xc17fc3e8 READ interrupt ad2: req=0xc17fc3e8 READ end transaction ad2: req=0xc17fc3e8 READ interrupt ad2: req=0xc17fc3e8 READ end transaction ad2: req=0xc17fc3e8 READ interrupt ad2: req=0xc17fc3e8 READ end transaction ad2: req=0xc17fc3e8 READ interrupt ad2: req=0xc17fc3e8 READ end transaction ad2: req=0xc17fc3e8 READ interrupt ad2: req=0xc17fc3e8 READ end transaction ad2: req=0xc17fc3e8 READ interrupt ad2: req=0xc17fc3e8 READ end transaction ad2: req=0xc17fc3e8 READ finish bio_taskqueue ad2: req=0xc17fc3e8 READ completed entered ad2: req=0xc17fc3e8 READ completed callback/wakeup ad2: req=0xc17fc258 READ queued ad2: req=0xc17fc258 READ starting ad2: req=0xc17fc258 READ begin transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ timeout ad2: req=0xc17fc258 READ finish taskqueue_swi ad2: req=0xc17fc258 READ completed entered ad2: req=0xc17fc320 SETFEATURES SET TRANSFER MODE begin transaction aad2: req=0xc17fc320 SETFEATURES SET TRANSFER MODE interrupt ad2: req=0xc17fc320 SETFEATURES SET TRANSFER MODE end transaction ad2: req=0xc17fc320 SETFEATURES SET TRANSFER MODE finish directly ad2: req=0xc17fc320 SETFEATURES SET TRANSFER MODE completed entered ad2: req=0xc17fc320 SETFEATURES SET TRANSFER MODE completed callback/wakeup d2: req=0xc17fc320 SETFEATURES SET TRANSFER MODE wait for completition ad2: TIMEOUT - READ retrying (1 retry left) LBA=860752 ad2: req=0xc17fc258 READ queued ad2: req=0xc17fc258 READ starting ad2: req=0xc17fc258 READ begin transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ interrupt ad2: req=0xc17fc258 READ end transaction ad2: req=0xc17fc258 READ finish bio_taskqueue ad2: req=0xc17fc258 READ completed entered ad2: req=0xc17fc258 READ completed callback/wakeup ad2: req=0xc17fc190 READ queued ad2: req=0xc17fc190 READ starting ad2: req=0xc17fc190 READ begin transaction ad2: req=0xc17fc190 READ interrupt ad2: req=0xc17fc190 READ end transaction ad2: req=0xc17fc190 READ interrupt ad2: req=0xc17fc190 READ end transaction ad2: req=0xc17fc190 READ interrupt ad2: req=0xc17fc190 READ end transaction ad2: req=0xc17fc190 READ interrupt ad2: req=0xc17fc190 READ end transaction ad2: req=0xc17fc190 READ interrupt ad2: req=0xc17fc190 READ end transaction ad2: req=0xc17fc190 READ interrupt ad2: req=0xc17fc190 READ end transaction ad2: req=0xc17fc190 READ interrupt ad2: req=0xc17fc190 READ end transaction ad2: req=0xc17fc190 READ interrupt ad2: req=0xc17fc190 READ end transaction ad2: req=0xc17fc190 READ interrupt ad2: req=0xc17fc190 READ end transaction ad2: req=0xc17fc190 READ interrupt ad2: req=0xc17fc190 READ end transaction ad2: req=0xc17fc190 READ interrupt ad2: req=0xc17fc190 READ end transaction ad2: req=0xc17fc190 READ interrupt ad2: req=0xc17fc190 READ end transaction ad2: req=0xc17fc190 READ interrupt ad2: req=0xc17fc190 READ end transaction ad2: req=0xc17fc190 READ interrupt ad2: req=0xc17fc190 READ end transaction ad2: req=0xc17fc190 READ interrupt ad2: req=0xc17fc190 READ end transaction ad2: req=0xc17fc190 READ interrupt ad2: req=0xc17fc190 READ end transaction ad2: req=0xc17fc190 READ interrupt ad2: req=0xc17fc190 READ end transaction ad2: req=0xc17fc190 READ interrupt ad2: req=0xc17fc190 READ end transaction ad2: req=0xc17fc190 READ interrupt ad2: req=0xc17fc190 READ end transaction ad2: req=0xc17fc190 READ interrupt ad2: req=0xc17fc190 READ end transaction ad2: req=0xc17fc190 READ interrupt ad2: req=0xc17fc190 READ end transaction ad2: req=0xc17fc190 READ interrupt ad2: req=0xc17fc190 READ end transaction ad2: req=0xc17fc190 READ interrupt ad2: req=0xc17fc190 READ end transaction ad2: req=0xc17fc190 READ interrupt ad2: req=0xc17fc190 READ end transaction ad2: req=0xc17fc190 READ interrupt ad2: req=0xc17fc190 READ end transaction ad2: req=0xc17fc190 READ interrupt ad2: req=0xc17fc190 READ end transaction ad2: req=0xc17fc190 READ interrupt ad2: req=0xc17fc190 READ end transaction ad2: req=0xc17fc190 READ interrupt ad2: req=0xc17fc190 READ end transaction ad2: req=0xc17fc190 READ interrupt ad2: req=0xc17fc190 READ end transaction ad2: req=0xc17fc190 READ interrupt ad2: req=0xc17fc190 READ end transaction ad2: req=0xc17fc190 READ interrupt ad2: req=0xc17fc190 READ end transaction ad2: req=0xc17fc190 READ interrupt ad2: req=0xc17fc190 READ end transaction ad2: req=0xc17fc190 READ finish bio_taskqueue ad2: req=0xc17fc190 READ completed entered ad2: req=0xc17fc190 READ completed callback/wakeup ad2: req=0xc17fc0c8 READ queued ad2: req=0xc17fc0c8 READ starting ad2: req=0xc17fc0c8 READ begin transaction ad2: req=0xc17fc0c8 READ interrupt ad2: req=0xc17fc0c8 READ end transaction ad2: req=0xc17fc0c8 READ interrupt ad2: req=0xc17fc0c8 READ end transaction ad2: req=0xc17fc0c8 READ interrupt ad2: req=0xc17fc0c8 READ end transaction ad2: req=0xc17fc0c8 READ interrupt ad2: req=0xc17fc0c8 READ end transaction ad2: req=0xc17fc0c8 READ interrupt ad2: req=0xc17fc0c8 READ end transaction ad2: req=0xc17fc0c8 READ interrupt ad2: req=0xc17fc0c8 READ end transaction ad2: req=0xc17fc0c8 READ interrupt ad2: req=0xc17fc0c8 READ end transaction ad2: req=0xc17fc0c8 READ interrupt ad2: req=0xc17fc0c8 READ end transaction ad2: req=0xc17fc0c8 READ finish bio_taskqueue ad2: req=0xc17fc0c8 READ completed entered ad2: req=0xc17fc0c8 READ completed callback/wakeup ad2: req=0xc17fc000 READ queued ad2: req=0xc17fc000 READ starting ad2: req=0xc17fc000 READ begin transaction ad2: req=0xc17fc000 READ interrupt ad2: req=0xc17fc000 READ end transaction ad2: req=0xc17fc000 READ interrupt ad2: req=0xc17fc000 READ end transaction ad2: req=0xc17fc000 READ interrupt ad2: req=0xc17fc000 READ end transaction ad2: req=0xc17fc000 READ interrupt ad2: req=0xc17fc000 READ end transaction ad2: req=0xc17fc000 READ interrupt ad2: req=0xc17fc000 READ end transaction ad2: req=0xc17fc000 READ interrupt ad2: req=0xc17fc000 READ end transaction ad2: req=0xc17fc000 READ interrupt ad2: req=0xc17fc000 READ end transaction ad2: req=0xc17fc000 READ interrupt ad2: req=0xc17fc000 READ end transaction ad2: req=0xc17fc000 READ finish bio_taskqueue ad2: req=0xc17fc000 READ completed entered ad2: req=0xc17fc000 READ completed callback/wakeup --Apple-Mail-11-1006727391 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed After the final "ad2: req=0xc17fc000 READ completed callback/wakeup", nothing else happens. Stefan p.s. this is what I did to enable debugging: little:/usr/src/sys/dev/ata# cvs diff cvs diff: Diffing . Index: ata-all.h =================================================================== RCS file: /home/ncvs/src/sys/dev/ata/ata-all.h,v retrieving revision 1.103.2.2 diff -u -r1.103.2.2 ata-all.h --- ata-all.h 25 Aug 2005 16:21:05 -0000 1.103.2.2 +++ ata-all.h 29 Aug 2005 18:07:33 -0000 @@ -391,7 +391,7 @@ }; /* define this for debugging request processing */ -#if 0 +#if 1 #define ATA_DEBUG_RQ(request, string) \ { \ if (request->flags & ATA_R_DEBUG) \ Index: ata-queue.c =================================================================== RCS file: /home/ncvs/src/sys/dev/ata/ata-queue.c,v retrieving revision 1.50 diff -u -r1.50 ata-queue.c --- ata-queue.c 28 Jun 2005 09:06:52 -0000 1.50 +++ ata-queue.c 29 Aug 2005 18:57:15 -0000 @@ -54,6 +54,7 @@ ata_queue_request(struct ata_request *request) { struct ata_channel *ch = device_get_softc(device_get_parent (request->dev)); + request->flags |= ATA_R_DEBUG; /* mark request as virgin (this might be a ATA_R_REQUEUE) */ request->result = request->status = request->error = 0; -- Stefan Bethke Fon +49 170 346 0140 --Apple-Mail-11-1006727391-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 19:15:09 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 6219B16A41F; Mon, 29 Aug 2005 19:15:09 +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 5923E43D53; Mon, 29 Aug 2005 19:15:08 +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 A080D1FFAD3; Mon, 29 Aug 2005 21:15:07 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id 5C0901FF9AB; Mon, 29 Aug 2005 21:15:05 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id 729EE15823; Mon, 29 Aug 2005 19:12:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id 685301562F; Mon, 29 Aug 2005 19:12:02 +0000 (UTC) Date: Mon, 29 Aug 2005 19:12:02 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: Markus Brueffer In-Reply-To: <200508291542.46098.markus@freebsd.org> Message-ID: References: <200508101658.09719.jhb@FreeBSD.org> <20050812121551.GA888@unixpages.org> <200508120916.14378.jhb@FreeBSD.org> <200508291542.46098.markus@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Cc: freebsd-current@freebsd.org Subject: Re: Locking fixes for sf(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 19:15:09 -0000 On Mon, 29 Aug 2005, Markus Brueffer wrote: > I'm getting this LOR with the latest if_sf.c in RELENG_6: > > lock order reversal > 1st 0xc1b0d7cc sf0 (network driver) @ /usr/src/sys/pci/if_sf.c:1201 > 2nd 0xc07a49e0 Giant (Giant) @ /usr/src/sys/kern/kern_poll.c:460 LOR added with ID 146: http://sources.zabbadoz.net/freebsd/lor.html#146 -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 19:20: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 076C316A41F for ; Mon, 29 Aug 2005 19:20:36 +0000 (GMT) (envelope-from clive@tongi.org) Received: from drop.bsdchat.com (drop.bsdchat.com [209.237.225.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2CCC243D58 for ; Mon, 29 Aug 2005 19:20:35 +0000 (GMT) (envelope-from clive@tongi.org) Received: from CARTIER (drag.bsdchat.com [209.237.225.37]) by drop.bsdchat.com (8.13.3/8.13.3) with SMTP id j7TJKUGG023612; Mon, 29 Aug 2005 19:20:33 GMT (envelope-from clive@tongi.org) Received: (nullmailer pid 47631 invoked by uid 1000); Mon, 29 Aug 2005 19:20:22 -0000 Date: Tue, 30 Aug 2005 03:20:22 +0800 From: Clive Lin To: Jiawei Ye Message-ID: <20050829192022.GB47151@tongi.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xA008C03E User-Agent: Mutt/1.5.9i X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (drop.bsdchat.com [209.237.225.38]); Mon, 29 Aug 2005 19:20:34 +0000 (UTC) Cc: freebsd-current@freebsd.org Subject: Re: Strange threading issue with apache2 WITH_THREADS=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: Mon, 29 Aug 2005 19:20:36 -0000 On Mon, Aug 29, 2005 at 09:18:27AM +0800, Jiawei Ye wrote: > I have been using www/apache2 with WITH_THREADS=1 for a long time on a > -current system. With a recent world upgrade, I start to get "Fatal > error Dead thread has assumed at line 158 in file > src/lib/libpthread/thread/thr_exit.c (errno = 0)" and httpd no longer > functions. Rebuilding kernel/world/libpthread does not seem to make > any difference, nor does rebuilding www/apache2 itself. > > Any suggestions? try putting WITH_APACHE2=yes WITH_MPM=worker in /etc/make.conf, and portupgrade apache. also, try some "suggestions" as described in libmap.conf(5) Hope this helps. -- Clive Tong-I Lin | http://tongi.org | PGP KeyID: A008C03E From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 19:36: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 A49D416A41F for ; Mon, 29 Aug 2005 19:36:08 +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 476BA43D46 for ; Mon, 29 Aug 2005 19:36:08 +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.4/8.13.4/NETPLEX) with ESMTP id j7TJa7YX005058; Mon, 29 Aug 2005 15:36:07 -0400 (EDT) Date: Mon, 29 Aug 2005 15:36:06 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Clive Lin In-Reply-To: <20050829192022.GB47151@tongi.org> 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: freebsd-current@freebsd.org, Jiawei Ye Subject: Re: Strange threading issue with apache2 WITH_THREADS=1 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, 29 Aug 2005 19:36:08 -0000 On Tue, 30 Aug 2005, Clive Lin wrote: > On Mon, Aug 29, 2005 at 09:18:27AM +0800, Jiawei Ye wrote: > > I have been using www/apache2 with WITH_THREADS=1 for a long time on a > > -current system. With a recent world upgrade, I start to get "Fatal > > error Dead thread has assumed at line 158 in file > > src/lib/libpthread/thread/thr_exit.c (errno = 0)" and httpd no longer > > functions. Rebuilding kernel/world/libpthread does not seem to make > > any difference, nor does rebuilding www/apache2 itself. > > > > Any suggestions? > > try putting > > WITH_APACHE2=yes > WITH_MPM=worker > > in /etc/make.conf, and portupgrade apache. > > also, try some "suggestions" as described in libmap.conf(5) How about try making sure you're not using multiple thread libraries at the same time. After upgrading, libpthread's version # was bumped along with everything else. ldd(1) is your friend. -- DE From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 20:03: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 177BB16A41F for ; Mon, 29 Aug 2005 20:03:56 +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 ABA6D43D49 for ; Mon, 29 Aug 2005 20:03:55 +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 j7TK3sPI090238 for ; Mon, 29 Aug 2005 13:03:54 -0700 (PDT) (envelope-from eta@lclark.edu) Received: (from anholt@localhost) by leguin.anholt.net (8.13.4/8.13.1/Submit) id j7TK3r4T090237 for current@FreeBSD.org; Mon, 29 Aug 2005 13:03:53 -0700 (PDT) (envelope-from eta@lclark.edu) X-Authentication-Warning: leguin.anholt.net: anholt set sender to eta@lclark.edu using -f From: Eric Anholt To: current@FreeBSD.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-lDr/E6ojjPXRLDfDr0ht" Date: Mon, 29 Aug 2005 13:03:52 -0700 Message-Id: <1125345832.1005.32.camel@leguin> Mime-Version: 1.0 X-Mailer: Evolution 2.3.8 FreeBSD GNOME Team Port Cc: Subject: DRM merge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 20:03:56 -0000 --=-lDr/E6ojjPXRLDfDr0ht Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I've put a patch to merge current DRM CVS to FreeBSD here: http://people.freebsd.org/~anholt/dri/drm-20050826.diff Along with various changes as usual, it includes jake@'s port of the VIA DRM (note: this requires a patch to the x server to work, which is in X.org CVS). I've tested on r200, r128, mga, sis on my x86 testbox. However, I was getting a crash on X startup with DRI on my amd64 desktop. I couldn't get it to drop to debugger for some reason, so I don't know if the merge is at fault or not. So, I would really appreciate some testing on amd64, in particular. --=20 Eric Anholt eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org --=-lDr/E6ojjPXRLDfDr0ht Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBDE2onHUdvYGzw6vcRAg4VAJ4gAJIQbrbYMwtOsAm76BcxyMfQMgCfRfYA 019ZmrjJakWaRsayLqPzlVM= =Pi+v -----END PGP SIGNATURE----- --=-lDr/E6ojjPXRLDfDr0ht-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 20:22: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 CA23616A41F; Mon, 29 Aug 2005 20:22:05 +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 6185B43D45; Mon, 29 Aug 2005 20:22:05 +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.3/8.13.3) with ESMTP id j7TKM4Ks016649; Mon, 29 Aug 2005 16:22:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j7TKM3V7004202; Mon, 29 Aug 2005 16:22:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id CCA3C7304D; Mon, 29 Aug 2005 16:22:03 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050829202203.CCA3C7304D@freebsd-current.sentex.ca> Date: Mon, 29 Aug 2005 16:22:03 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner5 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 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: Mon, 29 Aug 2005 20:22:06 -0000 TB --- 2005-08-29 19:06:09 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-08-29 19:06:09 - starting HEAD tinderbox run for i386/i386 TB --- 2005-08-29 19:06:09 - cleaning the object tree TB --- 2005-08-29 19:06:36 - checking out the source tree TB --- 2005-08-29 19:06:36 - cd /tinderbox/HEAD/i386/i386 TB --- 2005-08-29 19:06:36 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-08-29 19:12:54 - building world (CFLAGS=-O2 -pipe) TB --- 2005-08-29 19:12:54 - cd /src TB --- 2005-08-29 19:12:54 - /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-08-29 20:16:38 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-08-29 20:16:38 - cd /src TB --- 2005-08-29 20:16:38 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Aug 29 20:16:38 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 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/dev/vx/if_vx_eisa.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/dev/vx/if_vx_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 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/dev/watchdog/watchdog.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/dev/wi/if_wi.c /src/sys/dev/wi/if_wi.c: In function `wi_cmd': /src/sys/dev/wi/if_wi.c:2447: error: `count' undeclared (first use in this function) /src/sys/dev/wi/if_wi.c:2447: error: (Each undeclared identifier is reported only once /src/sys/dev/wi/if_wi.c:2447: error: for each function it appears in.) *** Error code 1 Stop in /obj/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-08-29 20:22:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-08-29 20:22:03 - ERROR: failed to build generic kernel TB --- 2005-08-29 20:22:03 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 20:26: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 DEB5F16A41F for ; Mon, 29 Aug 2005 20:26:02 +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 2F4CC43D4C for ; Mon, 29 Aug 2005 20:26:02 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.136] (mac.deepcore.dk [194.192.25.136]) by spider.deepcore.dk (8.13.3/8.13.3) with ESMTP id j7TKM7xf014272; Mon, 29 Aug 2005 22:22:07 +0200 (CEST) (envelope-from sos@DeepCore.dk) In-Reply-To: <9105C2F5-0D77-4B43-AFFA-7558BBEDA26A@lassitu.de> References: <7A0B19EC-2F90-495F-B242-7FB701C32908@lassitu.de> <20050828124321.43365136@Magellan.Leidinger.net> <3923443F-6926-4BB7-8681-40FC68A41B79@lassitu.de> <0046E5C3-22EE-4F5D-B2B0-DFF4F0157F6B@lassitu.de> <9105C2F5-0D77-4B43-AFFA-7558BBEDA26A@lassitu.de> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: multipart/mixed; boundary=Apple-Mail-3-1011052415 Message-Id: <2E95AA3B-2CF7-4EFB-9EAC-45683D1F8D7D@DeepCore.dk> From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= Date: Mon, 29 Aug 2005 22:25:40 +0200 To: Stefan Bethke X-Mailer: Apple Mail (2.734) X-mail-scanned: by DeepCore Virus & Spam killer v1.12 Cc: freebsd-current@freebsd.org Subject: Re: Boot off CF card hangs at "Trying to mount root" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 20:26:03 -0000 --Apple-Mail-3-1011052415 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 29/08/2005, at 21:13, Stefan Bethke wrote: > Thanks for looking into this! NP! :) > > > After the final "ad2: req=0xc17fc000 READ completed callback/ > wakeup", nothing else happens. Hmm, the timeout in there is worrying me, please try the below hack and se if that makes it get through. Might be that the device doesn't like 64K (ie size 0) transfers... --Apple-Mail-3-1011052415 Content-Transfer-Encoding: 7bit Content-Type: application/octet-stream; x-unix-mode=0644; name="diff" Content-Disposition: attachment; filename=diff Index: ata-disk.c =================================================================== RCS file: /home/ncvs/src/sys/dev/ata/ata-disk.c,v retrieving revision 1.190 diff -u -r1.190 ata-disk.c --- ata-disk.c 17 Aug 2005 15:00:33 -0000 1.190 +++ ata-disk.c 29 Aug 2005 20:20:34 -0000 @@ -142,10 +142,14 @@ adp->disk->d_dump = ad_dump; adp->disk->d_name = "ad"; adp->disk->d_drv1 = dev; +#if 0 if (ch->dma) adp->disk->d_maxsize = ch->dma->max_iosize; else adp->disk->d_maxsize = DFLTPHYS; +#else + adp->disk->d_maxsize = 32*1024; +#endif adp->disk->d_sectorsize = DEV_BSIZE; adp->disk->d_mediasize = DEV_BSIZE * (off_t)adp->total_secs; adp->disk->d_fwsectors = adp->sectors; --Apple-Mail-3-1011052415 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; format=flowed - S=F8ren --Apple-Mail-3-1011052415-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 20:56:38 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 8BA2F16A420; Mon, 29 Aug 2005 20:56:38 +0000 (GMT) (envelope-from csjp@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5745A43D4C; Mon, 29 Aug 2005 20:56:38 +0000 (GMT) (envelope-from csjp@FreeBSD.org) Received: from freefall.freebsd.org (csjp@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j7TKucaO002817; Mon, 29 Aug 2005 20:56:38 GMT (envelope-from csjp@freefall.freebsd.org) Received: (from csjp@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j7TKucGE002816; Mon, 29 Aug 2005 20:56:38 GMT (envelope-from csjp) Date: Mon, 29 Aug 2005 20:56:38 +0000 From: "Christian S.J. Peron" To: saturnero@freesbie.org Message-ID: <20050829205638.GA2458@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@FreeBSD.org, pjd@FreeBSD.org Subject: Re: mdconfig recently 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: Mon, 29 Aug 2005 20:56:38 -0000 >Hi everybody, >due to limited connectivity in August, I've been able to >update my -CURRENT box only yesterday since the first days of August >(iirc). > >I noticed that mdconfig -a -t vnode -f ${myfile} isn't working anymore >when ${myfile} is on a read-only filesystem: > >sberta:/usr/local/freesbie-clone/uzip# mdconfig -a -t vnode -f usr.uzip >md0 >sberta:/usr/local/freesbie-clone/uzip# mdconfig -d -u 0 >sberta:/usr/local/freesbie-clone/uzip# mount -fru /usr >sberta:/usr/local/freesbie-clone/uzip# mdconfig -a -t vnode -f usr.uzip >mdconfig: ioctl(/dev/mdctl): Read-only file system > >This makes impossible to use compressed filesystems on devices like >cdrom or read-only diskless environment. Any idea? I'm using: > >FreeBSD sberta.saturnero.sat 7.0-CURRENT FreeBSD 7.0-CURRENT #2: Sat Aug 27 18:1 >5:39 CEST 2005 satu at sberta.saturnero.sat:/usr/obj/usr/src/sys/SBERTA i386 >sberta:/usr/local/freesbie-clone/uzip# > >Bye and thanks in advance, >Dario Yes, this is the expected result. I changed this after it was noted that it was possible to bypass schg flags through mdconfig. See kern/84635 for more details. As a result the user needs to specify -o readonly to mdconfig(8) when using read only files as backing stores. phk and pjd both have expressed some interests in having me revert to a graceful downgrade of access, which I am open to, provided we display this fact to the user. I am just thinking if we should downgrade the request in mdconfig instead of the kernel as it keeps the kernel code more clean. Here is a reference to the commit log, see revision 1.154 http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/md/md.c Thoughts? -- Christian S.J. Peron csjp@FreeBSD.ORG FreeBSD Committer From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 21:03: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 6698216A41F; Mon, 29 Aug 2005 21:03:11 +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 8D7EA43D4C; Mon, 29 Aug 2005 21:03:06 +0000 (GMT) (envelope-from q@galgenberg.net) Received: from wrzx34.rz.uni-wuerzburg.de (wrzx34.rz.uni-wuerzburg.de [132.187.3.34]) by wrzx28.rz.uni-wuerzburg.de (Postfix) with ESMTP id DF9EB1363B2; Mon, 29 Aug 2005 23:03:05 +0200 (CEST) Received: from virusscan (localhost [127.0.0.1]) by wrzx34.rz.uni-wuerzburg.de (Postfix) with ESMTP id C1744B137A; Mon, 29 Aug 2005 23:03:05 +0200 (CEST) Received: from wrzx28.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by wrzx34.rz.uni-wuerzburg.de (Postfix) with ESMTP id 9CB82B1318; Mon, 29 Aug 2005 23:03:05 +0200 (CEST) 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 605121363B2; Mon, 29 Aug 2005 23:03:05 +0200 (CEST) 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 j7TL35eY037044; Mon, 29 Aug 2005 23:03:05 +0200 (CEST) (envelope-from q@galgenberg.net) Received: from roadrunner.q.local (roadrunner.q.local [192.168.0.148]) by coyote.q.local (8.13.3/8.13.1) with ESMTP id j7TL344n078104; Mon, 29 Aug 2005 23:03:04 +0200 (CEST) (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 j7TL348F031912; Mon, 29 Aug 2005 23:03:04 +0200 (CEST) (envelope-from q@galgenberg.net) Received: (from q@localhost) by roadrunner.q.local (8.13.4/8.13.4/Submit) id j7TL34Ee031911; Mon, 29 Aug 2005 23:03:04 +0200 (CEST) (envelope-from q@galgenberg.net) Date: Mon, 29 Aug 2005 23:03:04 +0200 From: Ulrich Spoerlein To: Mateusz J??drasik Message-ID: <20050829210303.GH976@galgenberg.net> Mail-Followup-To: Mateusz J??drasik , current@freebsd.org, ports@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+9faIjRurCDpBc7U" Content-Disposition: inline User-Agent: mutt-ng devel (FreeBSD) X-Virus-Scanned: by amavisd-new (Rechenzentrum Universitaet Wuerzburg) Cc: ports@freebsd.org, current@freebsd.org Subject: Re: FreeBSD-6-BETA3 broken with ports/audio/aureal-kmod; ports/graphics/linux_dri not working. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 21:03:11 -0000 --+9faIjRurCDpBc7U Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, 28.08.2005 at 23:40:42 +0200, Mateusz J??drasik wrote: > The solution I would best see here is bumping emulators/linux_base-suse-9= =2E3 as=20 > default linux compat, updating the unhappy ports to play nicely with such= an=20 > upgrade, and using xorg-dri drivers for linux_dri compatible with the=20 > xorg-libs avaliable with emulators/linux_base-suse-9.3. I already did this locally, but it won't solve your problem. There is no binary r300 DRI driver in SuSE 9.3 and even compiling one on your own won't make it load, because you need to hack the DRI stuff so it will load the appropriate module (see pkg-descr of linux_dri). I already asked Eric for the patch, but it looks like he hasn't got it anymore. 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? --+9faIjRurCDpBc7U Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDE3gHmArGtfDbn0QRAs4nAJ9V0mNNl+wotL6mQ2KNh/xp07PIEgCghlYv AFdV53CbeL08zmpMdHIsphs= =wJQU -----END PGP SIGNATURE----- --+9faIjRurCDpBc7U-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 21:21:14 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 BFF8016A41F for ; Mon, 29 Aug 2005 21:21:14 +0000 (GMT) (envelope-from stb@lassitu.de) Received: from schlepper.zs64.net (schlepper.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8868643D45 for ; Mon, 29 Aug 2005 21:21:12 +0000 (GMT) (envelope-from stb@lassitu.de) Received: from [IPv6:::1] (schlepper [212.12.50.230]) by schlepper.zs64.net (8.13.3/8.12.9) with ESMTP id j7TLKt17029694; Mon, 29 Aug 2005 23:20:55 +0200 (CEST) (envelope-from stb@lassitu.de) In-Reply-To: <2E95AA3B-2CF7-4EFB-9EAC-45683D1F8D7D@DeepCore.dk> References: <7A0B19EC-2F90-495F-B242-7FB701C32908@lassitu.de> <20050828124321.43365136@Magellan.Leidinger.net> <3923443F-6926-4BB7-8681-40FC68A41B79@lassitu.de> <0046E5C3-22EE-4F5D-B2B0-DFF4F0157F6B@lassitu.de> <9105C2F5-0D77-4B43-AFFA-7558BBEDA26A@lassitu.de> <2E95AA3B-2CF7-4EFB-9EAC-45683D1F8D7D@DeepCore.dk> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: multipart/mixed; boundary=Apple-Mail-14-1014365941 Message-Id: <95B83146-2D52-42D3-8C2E-113CD280743F@lassitu.de> From: Stefan Bethke Date: Mon, 29 Aug 2005 23:20:53 +0200 To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= X-Mailer: Apple Mail (2.734) Cc: freebsd-current@freebsd.org Subject: Re: Boot off CF card hangs at "Trying to mount root" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 21:21:14 -0000 --Apple-Mail-14-1014365941 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Am 29.08.2005 um 22:25 schrieb S=F8ren Schmidt: > On 29/08/2005, at 21:13, Stefan Bethke wrote: >> After the final "ad2: req=3D0xc17fc000 READ completed callback/=20 >> wakeup", nothing else happens. > Hmm, the timeout in there is worrying me, please try the below hack =20= > and se if that makes it get through. Might be that the device =20 > doesn't like 64K (ie size 0) transfers... Hhm, doesn't look too different. I've fixed fstab, so this is a =20 complete verbose boot. --Apple-Mail-14-1014365941 Content-Transfer-Encoding: 7bit Content-Type: text/plain; x-unix-mode=0644; name="atadebug2.txt" Content-Disposition: attachment; filename=atadebug2.txt OK boot -sv /boot/kernel/kernel text=0x485000 data=0x811c0+0x9cb64 syms=[0x4+0x64560+0x4+0x7a61e] /boot/modules/acpi.ko text=0x40a00 data=0x2060+0x1090 syms=[0x4+0x76a0+0x4+0x9e43] GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base=0000000000000000 len=00000000000a0000 SMAP type=02 base=00000000000f0000 len=0000000000010000 SMAP type=02 base=00000000ffff0000 len=0000000000010000 SMAP type=01 base=0000000000100000 len=000000001f6f0000 SMAP type=03 base=000000001f7f3000 len=000000000000d000 SMAP type=04 base=000000001f7f0000 len=0000000000003000 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-BETA3 #4: Mon Aug 29 23:00:36 CEST 2005 root@little:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xc0ad9000. Preloaded elf module "/boot/modules/acpi.ko" at 0xc0ad9158. Calibrating clock(s) ... i8254 clock: 1193105 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 532640456 Hz CPU: VIA C3 Samuel 2 (532.64-MHz 686-class CPU) Origin = "CentaurHauls" Id = 0x673 Stepping = 3 Features=0x803035 real memory = 528416768 (503 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c28000 - 0x000000001eedbfff, 506150912 bytes (123572 pages) avail memory = 507584512 (484 MB) bios32: Found BIOS32 Service Directory header at 0xc00fb090 bios32: Entry = 0xfb500 (c00fb500) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xb530 pnpbios: Found PnP BIOS data at 0xc00fbfd0 pnpbios: Entry = f0000:c000 Rev = 1.0 Other BIOS signatures found: wlan: <802.11 Link Layer> random: nfslock: pseudo-device io: mem: null: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x80000060 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=06011106) pcibios: BIOS version 2.10 Found $PIR table, 7 entries at 0xc00fde40 PCI-Only Interrupts: 5 10 11 12 Location Bus Device Pin Link IRQs slot 1 0 8 A 0x01 3 4 5 7 9 10 11 12 14 15 slot 1 0 8 B 0x02 3 4 5 7 9 10 11 12 14 15 slot 1 0 8 C 0x03 3 4 5 7 9 10 11 12 14 15 slot 1 0 8 D 0x05 3 4 5 7 9 10 11 12 14 15 slot 2 0 9 A 0x02 3 4 5 7 9 10 11 12 14 15 slot 2 0 9 B 0x03 3 4 5 7 9 10 11 12 14 15 slot 2 0 9 C 0x05 3 4 5 7 9 10 11 12 14 15 slot 2 0 9 D 0x01 3 4 5 7 9 10 11 12 14 15 slot 3 0 6 A 0x03 3 4 5 7 9 10 11 12 14 15 slot 3 0 6 B 0x05 3 4 5 7 9 10 11 12 14 15 slot 3 0 6 C 0x01 3 4 5 7 9 10 11 12 14 15 slot 3 0 6 D 0x02 3 4 5 7 9 10 11 12 14 15 slot 4 0 11 A 0x05 3 4 5 7 9 10 11 12 14 15 slot 4 0 11 B 0x01 3 4 5 7 9 10 11 12 14 15 slot 4 0 11 C 0x02 3 4 5 7 9 10 11 12 14 15 slot 4 0 11 D 0x03 3 4 5 7 9 10 11 12 14 15 slot 5 0 7 A 0x02 3 4 5 7 9 10 11 12 14 15 slot 5 0 7 B 0x03 3 4 5 7 9 10 11 12 14 15 slot 5 0 7 C 0x05 3 4 5 7 9 10 11 12 14 15 slot 5 0 7 D 0x01 3 4 5 7 9 10 11 12 14 15 embedded 0 1 A 0x01 3 4 5 7 9 10 11 12 14 15 embedded 0 1 B 0x02 3 4 5 7 9 10 11 12 14 15 embedded 0 1 C 0x03 3 4 5 7 9 10 11 12 14 15 embedded 0 1 D 0x05 3 4 5 7 9 10 11 12 14 15 embedded 0 7 C 0x03 3 4 5 7 9 10 11 12 14 15 embedded 0 7 D 0x05 3 4 5 7 9 10 11 12 14 15 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 7 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 7 func 0 acpi0: Power Button (fixed) pci_link0: irq 12 on acpi0 pci_link0: Links after initial probe: Index IRQ Rtd Ref IRQs 0 12 N 0 1 3 4 5 6 7 10 11 12 14 15 pci_link0: Links after initial validation: Index IRQ Rtd Ref IRQs 0 12 N 0 1 3 4 5 6 7 10 11 12 14 15 pci_link0: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 1 3 4 5 6 7 10 11 12 14 15 pci_link1: irq 10 on acpi0 pci_link1: Links after initial probe: Index IRQ Rtd Ref IRQs 0 10 N 0 1 3 4 5 6 7 10 11 12 14 15 pci_link1: Links after initial validation: Index IRQ Rtd Ref IRQs 0 10 N 0 1 3 4 5 6 7 10 11 12 14 15 pci_link1: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 1 3 4 5 6 7 10 11 12 14 15 pci_link2: irq 5 on acpi0 pci_link2: Links after initial probe: Index IRQ Rtd Ref IRQs 0 5 N 0 1 3 4 5 6 7 10 11 12 14 15 pci_link2: Links after initial validation: Index IRQ Rtd Ref IRQs 0 5 N 0 1 3 4 5 6 7 10 11 12 14 15 pci_link2: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 1 3 4 5 6 7 10 11 12 14 15 pci_link3: irq 11 on acpi0 pci_link3: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 1 3 4 5 6 7 10 11 12 14 15 pci_link3: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 1 3 4 5 6 7 10 11 12 14 15 pci_link3: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 1 3 4 5 6 7 10 11 12 14 15 ACPI timer: 0/4 0/5 0/5 0/5 0/4 0/5 0/4 0/5 0/5 0/5 -> 0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 acpi_throttle0: P_CNT from P_BLK 0x4010 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff,0x4000-0x407f,0x4080-0x40ff,0x5000-0x500f,0x6000-0x607f on acpi0 pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x1106, dev=0x0601, revid=0x05 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2290, cachelnsz=0 (dwords) lattimer=0x08 (240 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 3, range 32, base e0000000, size 26, enabled found-> vendor=0x1106, dev=0x8601, revid=0x00 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0xa230, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x0c (3000 ns), maxlat=0x00 (0 ns) found-> vendor=0x1106, dev=0x0686, revid=0x40 bus=0, slot=7, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0087, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 found-> vendor=0x1106, dev=0x0571, revid=0x06 bus=0, slot=7, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000c000, size 4, enabled found-> vendor=0x1106, dev=0x3038, revid=0x1a bus=0, slot=7, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=255 powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000c400, size 5, enabled found-> vendor=0x1106, dev=0x3038, revid=0x1a bus=0, slot=7, func=3 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=255 powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000c800, size 5, enabled found-> vendor=0x1106, dev=0x3057, revid=0x40 bus=0, slot=7, func=4 class=06-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 found-> vendor=0x1106, dev=0x3058, revid=0x50 bus=0, slot=7, func=5 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=5 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 0000cc00, size 8, enabled map[14]: type 4, range 32, base 0000d000, size 2, enabled map[18]: type 4, range 32, base 0000d400, size 2, enabled pcib0: matched entry for 0.7.INTC (src \_SB_.PCI0.LNKD:0) pcib0: slot 7 INTC routed to irq 11 via \_SB_.PCI0.LNKD found-> vendor=0x10ec, dev=0x8139, revid=0x10 bus=0, slot=8, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns) intpin=a, irq=12 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000d800, size 8, enabled map[14]: type 1, range 32, base e5810000, size 8, enabled pcib0: matched entry for 0.8.INTA (src \_SB_.PCI0.LNKA:0) pcib0: slot 8 INTA routed to irq 12 via \_SB_.PCI0.LNKA found-> vendor=0x10ec, dev=0x8139, revid=0x10 bus=0, slot=9, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000dc00, size 8, enabled map[14]: type 1, range 32, base e5811000, size 8, enabled pcib0: matched entry for 0.9.INTA (src \_SB_.PCI0.LNKB:0) pcib0: slot 9 INTA routed to irq 10 via \_SB_.PCI0.LNKB found-> vendor=0x10ec, dev=0x8139, revid=0x10 bus=0, slot=11, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000e000, size 8, enabled map[14]: type 1, range 32, base e5812000, size 8, enabled pcib0: matched entry for 0.11.INTA (src \_SB_.PCI0.LNKD:0) pcib0: slot 11 INTA routed to irq 11 via \_SB_.PCI0.LNKD agp0: mem 0xe0000000-0xe3ffffff at device 0.0 on pci0 agp0: Reserved 0x4000000 bytes for rid 0x10 type 3 at 0xe0000000 agp0: allocating GATT for aperture of size 256M pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xf000-0xfff pcib1: memory decode 0xe4000000-0xe57fffff pcib1: prefetched decode 0xfff00000-0xfffff pci1: on pcib1 pci1: physical bus=1 found-> vendor=0x1023, dev=0x8500, revid=0x6a bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=12 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base e4000000, size 23, enabled pcib1: (null) requested memory range 0xe4000000-0xe47fffff: good map[14]: type 1, range 32, base e5000000, size 17, enabled pcib1: (null) requested memory range 0xe5000000-0xe501ffff: good map[18]: type 1, range 32, base e4800000, size 23, enabled pcib1: (null) requested memory range 0xe4800000-0xe4ffffff: good pcib0: matched entry for 0.1.INTA (src \_SB_.PCI0.LNKA:0) pcib0: slot 1 INTA routed to irq 12 via \_SB_.PCI0.LNKA pcib1: slot 0 INTA is routed to irq 12 pci1: at device 0.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc000-0xc00f at device 7.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xc000 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 ata0: [MPSAFE] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=01 ostat0=50 ostat1=ff ata1: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata1: reset tp2 stat0=50 stat1=00 devices=0x1 ata1: [MPSAFE] uhci0: port 0xc400-0xc41f at device 7.2 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xc400 pcib0: matched entry for 0.7.INTD (src \_SB_.PCI0.LNKA:0) pcib0: slot 7 INTD routed to irq 12 via \_SB_.PCI0.LNKA uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xc800-0xc81f at device 7.3 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xc800 pcib0: matched entry for 0.7.INTD (src \_SB_.PCI0.LNKA:0) pcib0: slot 7 INTD routed to irq 12 via \_SB_.PCI0.LNKA uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pci0: at device 7.4 (no driver attached) pci0:7:4: Transition from D0 to D3 pci0: at device 7.5 (no driver attached) pci0:7:5: Transition from D0 to D3 re0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xd800 rl0: port 0xd800-0xd8ff mem 0xe5810000-0xe58100ff irq 12 at device 8.0 on pci0 miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: bpf attached rl0: Ethernet address: 00:40:f4:67:ec:84 rl0: [MPSAFE] re0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xdc00 rl1: port 0xdc00-0xdcff mem 0xe5811000-0xe58110ff irq 10 at device 9.0 on pci0 miibus1: on rl1 rlphy1: on miibus1 rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl1: bpf attached rl1: Ethernet address: 00:40:f4:67:ec:83 rl1: [MPSAFE] re0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xe000 rl2: port 0xe000-0xe0ff mem 0xe5812000-0xe58120ff irq 11 at device 11.0 on pci0 miibus2: on rl2 rlphy2: on miibus2 rlphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl2: bpf attached rl2: Ethernet address: 00:40:f4:67:ec:82 rl2: [MPSAFE] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: ic_type 90 part_id 80 fdc0: [MPSAFE] fdc0: [FAST] sio0: irq maps: 0x1 0x11 0x1 0x1 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console sio1: irq maps: 0x1 0x9 0x1 0x1 sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0: using extended I/O port range ppc0: EPP SPP ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: on ppc0 plip0: on ppbus0 plip0: bpf attached lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0067 atkbd: keyboard ID 0x41ab (2) kbdc: RESET_KBD return code:00fa kbdc: RESET_KBD status:00aa kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ ahc_isa_probe 12: ioport 0xcc00 alloc failed ahc_isa_probe 13: ioport 0xdc00 alloc failed ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it fdc: fdc0 already exists; skipping it ppc: ppc0 already exists; skipping it sio: sio0 already exists; skipping it sio: sio1 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete ex_isa_identify() unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcbfff,0xcc000-0xcffff on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. procfs registered Timecounter "TSC" frequency 532640456 Hz quality 800 Timecounters tick every 1.000 msec lo0: bpf attached unknown: req=0xc17f4000 ATA_IDENTIFY queued unknown: req=0xc17f4000 ATA_IDENTIFY starting unknown: req=0xc17f4000 ATA_IDENTIFY begin transaction unknowunknown: req=0xc17f4000 ATA_IDENTIFY interrupt unknown: req=0xc17f4000 ATA_IDENTIFY end transaction unknown: req=0xc17f4000 ATA_IDENTIFY finish directly unknown: req=0xc17f4000 ATA_IDENTIFY completed entered unknown: req=0xc17f4000 ATA_IDENTIFY completed callback/wakeup n: req=0xc17f4000 ATA_IDENTIFY wait for completition ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA66 cable=80 wire ad0: req=0xc17f3e10 SETFEATURES SET TRANSFER MODE queued ad0: req=0xc17f3e10 SETFEATURES SET TRANSFER MODE starting ad0: req=0xc17f3e10 SETFEATURES SET TRANSFER MODE begin transaction ad0: req=0ad0: req=0xc17f3e10 SETFEATURES SET TRANSFER MODE interrupt ad0: req=0xc17f3e10 SETFEATURES SET TRANSFER MODE end transaction ad0: req=0xc17f3e10 SETFEATURES SET TRANSFER MODE finish taskqueue_swi xc17f3e10 SETFEATURES SET TRANSFER MODE wait for completition ad0: req=0xc17f3e10 SETFEATURES SET TRANSFER MODE completed entered ad0: req=0xc17f3e10 SETFEATURES SET TRANSFER MODE completed callback/wakeup fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout ad0: setting PIO4 on VIA 82C686B chip ad0: req=0xc17f3d48 SETFEATURES SET TRANSFER MODE queued ad0: req=0xc17f3d48 SETFEATURES SET TRANSFER MODE starting ad0: req=0xc17f3d48 SETFEATURES SET TRANSFER MODE begin transaction ad0: ad0: req=0xc17f3d48 SETFEATURES SET TRANSFER MODE interrupt ad0: req=0xc17f3d48 SETFEATURES SET TRANSFER MODE end transaction ad0: req=0xc17f3d48 SETFEATURES SET TRANSFER MODE finish taskqueue_swi req=0xc17f3d48 SETFEATURES SET TRANSFER MODE wait for completition ad0: req=0xc17f3d48 SETFEATURES SET TRANSFER MODE completed entered ad0: req=0xc17f3d48 SETFEATURES SET TRANSFER MODE completed callback/wakeup ad0: setting UDMA66 on VIA 82C686B chip ad0: req=0xc17f3c80 SETFEATURES ENABLE RCACHE queued ad0: req=0xc17f3c80 SETFEATURES ENABLE RCACHE starting ad0: req=0xc17f3c80 SETFEATURES ENABLE RCACHE begin transaction ad0: reqad0: req=0xc17f3c80 SETFEATURES ENABLE RCACHE interrupt ad0: req=0xc17f3c80 SETFEATURES ENABLE RCACHE end transaction ad0: req=0xc17f3c80 SETFEATURES ENABLE RCACHE finish taskqueue_swi =0xc17f3c80 SETFEATURES ENABLE RCACHE wait for completition ad0: req=0xc17f3c80 SETFEATURES ENABLE RCACHE completed entered ad0: req=0xc17f3c80 SETFEATURES ENABLE RCACHE completed callback/wakeup fdc0: output ready timeout fdc0: input ready timeout fdc0: input ready timeout fdc0: output ready timeout fdc0: input ready timeout fdc0: input ready timeout fdc0: output ready timeout fdc0: input ready timeout fdc0: input ready timeout fdc0: output ready timeout fdc0: input ready timeout fdc0: input ready timeout ad0: req=0xc17f3bb8 SETFEATURES ENABLE WCACHE queued ad0: req=0xc17f3bb8 SETFEATURES ENABLE WCACHE starting ad0: req=0xc17f3bb8 SETFEATURES ENABLE WCACHE begin transaction adad0: req=0xc17f3bb8 SETFEATURES ENABLE WCACHE interrupt ad0: req=0xc17f3bb8 SETFEATURES ENABLE WCACHE end transaction ad0: req=0xc17f3bb8 SETFEATURES ENABLE WCACHE finish taskqueue_swi 0: req=0xc17f3bb8 SETFEATURES ENABLE WCACHE wait for completition ad0: req=0xc17f3bb8 SETFEATURES ENABLE WCACHE completed entered ad0: req=0xc17f3bb8 SETFEATURES ENABLE WCACHE completed callback/wakeup ad0: req=0xc17f3af0 SET_MULTI queued ad0: req=0xc17f3af0 SET_MULTI starting ad0: req=0xc17f3af0 SET_MULTI begin transaction ad0:ad0: req=0xc17f3af0 SET_MULTI interrupt ad0: req=0xc17f3af0 SET_MULTI end transaction ad0: req=0xc17f3af0 SET_MULTI finish taskqueue_swi req=0xc17f3af0 SET_MULTI wait for completition ad0: req=0xc17f3af0 SET_MULTI completed entered ad0: req=0xc17f3af0 SET_MULTI completed callback/wakeup ad0: 9590MB at ata0-master UDMA66 ad0: 19640880 sectors [19485C/16H/63S] 16 sectors/interrupt 1 depth queue ad0: req=0xc17f3a28 READ_DMA queued ad0: req=0xc17f3a28 READ_DMA starting ad0: req=0xc17f3a28 READ_DMA begin transaction ad0: req=0xc17f3a28 READ_DMA wait for completition GEOM: new disk ad0 ad0: req=0xc17f3960 READ_DMA queued ad0: req=0xc17f3a28 READ_DMA interrupt ad0: req=0xc17f3a28 READ_DMA end transaction ad0: req=0xc17f3a28 READ_DMA finish taskqueue_swi ad0: req=0xc17f3a28 READ_DMA completed entered ad0: req=0xc17f3a28 READ_DMA completed callback/wakeup ad0: req=0xc17f3960 READ_DMA starting ad0: req=0xc17f3960 READ_DMA begin transaction ad0: VIA check1 failed ad0: req=0xc17f3960 READ_DMA interrupt ad0: req=0xc17f3960 READ_DMA end transaction ad0: req=0xc17f3960 READ_DMA finish bio_taskqueue ad0: req=0xc17f3898 READ_DMA queued ad0: req=0xc17f3898 READ_DMA starting ad0: req=0xc17f3898 READ_DMA begin transaction ad0: reqad0: req=0xc17f3898 READ_DMA interrupt ad0: req=0xc17f3898 READ_DMA end transaction ad0: req=0xc17f3898 READ_DMA finish taskqueue_swi =0xc17f3898 READ_DMA wait for completition ad0: req=0xc17f3898 READ_DMA completed entered ad0: req=0xc17f3898 READ_DMA completed callback/wakeup ad0: req=0xc17f3960 READ_DMA completed entered ad0: req=0xc17f3960 READ_DMA completed callback/wakeup ad0: req=0xc17f37d0 READ_DMA queued ad0: req=0xc17f37d0 READ_DMA starting ad0: req=0xc17f37d0 READ_DMA begin transaction ad0: Adaptad0: req=0xc17f37d0 READ_DMA interrupt ad0: req=0xc17f37d0 READ_DMA end transaction ad0: req=0xc17f37d0 READ_DMA finish bio_taskqueue ec check1 failed ad0: req=0xc17f3708 READ_DMA queued ad0: req=0xc17f3708 READ_DMA starting ad0: req=0xc17f3708 READ_DMA begin transaction ad0: ad0: req=0xc17f3708 READ_DMA interrupt ad0: req=0xc17f3708 READ_DMA end transaction ad0: req=0xc17f3708 READ_DMA finish taskqueue_swi req=0xc17f3708 READ_DMA wait for completition ad0: req=0xc17f3708 READ_DMA completed entered ad0: req=0xc17f3708 READ_DMA completed callback/wakeup ad0: req=0xc17f37d0 READ_DMA completed entered ad0: req=0xc17f37d0 READ_DMA completed callback/wakeup ad0: req=0xc17f3640 READ_DMA queued ad0: req=0xc17f3640 READ_DMA starting ad0: req=0xc17f3640 READ_DMA begin transaction ad0: LSIad0: req=0xc17f3640 READ_DMA interrupt ad0: req=0xc17f3640 READ_DMA end transaction ad0: req=0xc17f3640 READ_DMA finish bio_taskqueue (v3) check1 failed ad0: req=0xc17f3578 READ_DMA queued ad0: req=0xc17f3578 READ_DMA starting ad0: req=0xc17f3578 READ_DMA begin transaction adad0: req=0xc17f3578 READ_DMA interrupt ad0: req=0xc17f3578 READ_DMA end transaction ad0: req=0xc17f3578 READ_DMA finish taskqueue_swi 0: req=0xc17f3578 READ_DMA wait for completition ad0: req=0xc17f3578 READ_DMA completed entered ad0: req=0xc17f3578 READ_DMA completed callback/wakeup ad0: req=0xc17f3640 READ_DMA completed entered ad0: req=0xc17f3640 READ_DMA completed callback/wakeup ad0: req=0xc17f34b0 READ_DMA queued ad0: req=0xc17f34b0 READ_DMA starting ad0: req=0xc17f34b0 READ_DMA begin transaction ad0: ad0: req=0xc17f34b0 READ_DMA interrupt ad0: req=0xc17f34b0 READ_DMA end transaction ad0: req=0xc17f34b0 READ_DMA finish bio_taskqueue LSI (v2) check1 failed ad0: req=0xc17f33e8 READ_DMA queued ad0: req=0xc17f33e8 READ_DMA starting ad0: req=0xc17f33e8 READ_DMA begin transaction ad0: req=0xc17f33e8 READ_ad0: req=0xc17f33e8 READ_DMA interrupt ad0: req=0xc17f33e8 READ_DMA end transaction ad0: req=0xc17f33e8 READ_DMA finish taskqueue_swi DMA wait for completition ad0: req=0xc17f33e8 READ_DMA completed entered ad0: req=0xc17f33e8 READ_DMA completed callback/wakeup ad0: req=0xc17f34b0 READ_DMA completed entered ad0: req=0xc17f34b0 READ_DMA completed callback/wakeup ad0: req=0xc17f3320 READ_DMA queued ad0: req=0xc17f3320 READ_DMA starting ad0: req=0xc17f3320 READ_DMA begin transaction ad0: Frad0: req=0xc17f3320 READ_DMA interrupt ad0: req=0xc17f3320 READ_DMA end transaction ad0: req=0xc17f3320 READ_DMA finish bio_taskqueue eeBSD check1 failed unknown: req=0xc17f3258 ATA_IDENTIFY queued unknown: req=0xc17f3258 ATA_IDENTIFY starting unknown: req=0xc17f3258 ATA_IDENTIFY begin transaction ununknown: req=0xc17f3258 ATA_IDENTIFY interrupt unknown: req=0xc17f3258 ATA_IDENTIFY end transaction unknown: req=0xc17f3258 ATA_IDENTIFY finish directly unknown: req=0xc17f3258 ATA_IDENTIFY completed entered unknown: req=0xc17f3258 ATA_IDENTIFY completed callback/wakeup known: req=0xc17f3258 ATA_IDENTIFY wait for completition ata1-master: pio=PIO4 wdma=BIOSDMA udma=BIOSDMA cable=40 wire ad2: req=0xc17f3190 SETFEATURES SET TRANSFER MODE queued ad2: req=0xc17f3190 SETFEATURES SET TRANSFER MODE starting ad2: req=0xc17f3190 SETFEATURES SET TRANSFER MODE begin transaction aad2: req=0xc17f3190 SETFEATURES SET TRANSFER MODE interrupt ad2: req=0xc17f3190 SETFEATURES SET TRANSFER MODE end transaction ad2: req=0xc17f3190 SETFEATURES SET TRANSFER MODE finish taskqueue_swi d2: req=0xc17f3190 SETFEATURES SET TRANSFER MODE wait for completition ad2: req=0xc17f3190 SETFEATURES SET TRANSFER MODE completed entered ad2: req=0xc17f3190 SETFEATURES SET TRANSFER MODE completed callback/wakeup ad0: req=0xc17f3320 READ_DMA completed entered ad0: req=0xc17f3320 READ_DMA completed callback/wakeup ad0: req=0xc17f30c8 READ_DMA queued ad0: req=0xc17f30c8 READ_DMA starting ad0: req=0xc17f30c8 READ_DMA begin transaction ad2:ad0: req=0xc17f30c8 READ_DMA interrupt ad0: req=0xc17f30c8 READ_DMA end transaction ad0: req=0xc17f30c8 READ_DMA finish bio_taskqueue setting PIO4 on VIA 82C686B chip ad2: 489MB at ata1-master PIO4 ad2: 1001952 sectors [994C/16H/63S] 1 sectors/interrupt 1 depth queue ad2: req=0xc17f3000 READ queued ad2: req=0xc17f3000 READ starting ad2: req=0xc17f3000 READ begin transaction aad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ finish taskqueue_swi d2: req=0xc17f3000 READ wait for completition ad2: req=0xc17f3000 READ completed entered ad2: req=0xc17f3000 READ completed callback/wakeup ad0: req=0xc17f30c8 READ_DMA completed entered ad0: req=0xc17f30c8 READ_DMA completed callback/wakeup ad0: req=0xc17f30c8 READ_DMA queued ad0: req=0xc17f30c8 READ_DMA starting ad0: req=0xc17f30c8 READ_DMA begin transaction ad2: VIA check1 failed aad0: req=0xc17f30c8 READ_DMA interrupt ad0: req=0xc17f30c8 READ_DMA end transaction ad0: req=0xc17f30c8 READ_DMA finish bio_taskqueue d2: req=0xc17f3190 READ queued ad2: req=0xc17f3190 READ starting ad2: req=0xc17f3190 READ begin transaction aad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction dad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction 2ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction :ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction rad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ead2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction qad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction =ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction 0ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction xad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ finish taskqueue_swi c17f3190 READ wait for completition ad2: req=0xc17f3190 READ completed entered ad2: req=0xc17f3190 READ completed callback/wakeup ad0: req=0xc17f30c8 READ_DMA completed entered ad0: req=0xc17f30c8 READ_DMA completed callback/wakeup ad0: req=0xc17f3320 READ_DMA queued ad0: req=0xc17f3320 READ_DMA starting ad0: req=0xc17f3320 READ_DMA begin transaction ad2:ad0: req=0xc17f3320 READ_DMA interrupt ad0: req=0xc17f3320 READ_DMA end transaction ad0: req=0xc17f3320 READ_DMA finish bio_taskqueue Adaptec check1 failed ad2: req=0xc17f3258 READ queued ad2: req=0xc17f3258 READ starting ad2: req=0xc17f3258 READ begin transaction aad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction dad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction 2ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ finish taskqueue_swi : req=0xc17f3258 READ wait for completition ad2: req=0xc17f3258 READ completed entered ad2: req=0xc17f3258 READ completed callback/wakeup ad0: req=0xc17f3320 READ_DMA completed entered ad0: req=0xc17f3320 READ_DMA completed callback/wakeup ad0: req=0xc17f33e8 READ_DMA queued ad0: req=0xc17f33e8 READ_DMA starting ad0: req=0xc17f33e8 READ_DMA begin transaction ad2: LSI ad0: req=0xc17f33e8 READ_DMA interrupt ad0: req=0xc17f33e8 READ_DMA end transaction ad0: req=0xc17f33e8 READ_DMA finish bio_taskqueue (v3) check1 failed ad2: req=0xc17f34b0 READ queued ad2: req=0xc17f34b0 READ starting ad2: req=0xc17f34b0 READ begin transaction aad2: req=0xc17f34b0 READ interrupt ad2: req=0xc17f34b0 READ end transaction ad2: req=0xc17f34b0 READ finish taskqueue_swi d2: req=0xc17f34b0 READ wait for completition ad2: req=0xc17f34b0 READ completed entered ad2: req=0xc17f34b0 READ completed callback/wakeup ad0: req=0xc17f33e8 READ_DMA completed entered ad0: req=0xc17f33e8 READ_DMA completed callback/wakeup ad0: req=0xc17f3578 READ_DMA queued ad0: req=0xc17f3578 READ_DMA starting ad0: req=0xc17f3578 READ_DMA begin transaction ad2: LSad0: req=0xc17f3578 READ_DMA interrupt ad0: req=0xc17f3578 READ_DMA end transaction ad0: req=0xc17f3578 READ_DMA finish bio_taskqueue I (v2) check1 failed ad2: req=0xc17f3640 READ queued ad2: req=0xc17f3640 READ starting ad2: req=0xc17f3640 READ begin transaction aad2: req=0xc17f3640 READ interrupt ad2: req=0xc17f3640 READ end transaction ad2: req=0xc17f3640 READ interrupt ad2: req=0xc17f3640 READ end transaction dad2: req=0xc17f3640 READ interrupt ad2: req=0xc17f3640 READ end transaction 2ad2: req=0xc17f3640 READ interrupt ad2: req=0xc17f3640 READ end transaction ad2: req=0xc17f3640 READ finish taskqueue_swi : req=0xc17f3640 READ wait for completition ad2: req=0xc17f3640 READ completed entered ad2: req=0xc17f3640 READ completed callback/wakeup ad0: req=0xc17f3578 READ_DMA completed entered ad0: req=0xc17f3578 READ_DMA completed callback/wakeup ad0: req=0xc17f3708 READ_DMA queued ad0: req=0xc17f3708 READ_DMA starting ad0: req=0xc17f3708 READ_DMA begin transaction ad2: FreeBad0: req=0xc17f3708 READ_DMA interrupt ad0: req=0xc17f3708 READ_DMA end transaction ad0: req=0xc17f3708 READ_DMA finish bio_taskqueue SD check1 failed ATA PseudoRAID loaded ad0: req=0xc17f3708 READ_DMA completed entered ad0: req=0xc17f3708 READ_DMA completed callback/wakeup ad0: req=0xc17f37d0 READ_DMA queued ad0: req=0xc17f37d0 READ_DMA starting ad0: req=0xc17f37d0 READ_DMA begin transaction ad0: req=0xc17f37d0 READ_DMA interrupt ad0: req=0xc17f37d0 READ_DMA end transaction ad0: req=0xc17f37d0 READ_DMA finish bio_taskqueue ad0: req=0xc17f37d0 READ_DMA completed entered ad0: req=0xc17f37d0 READ_DMA completed callback/wakeup ad0: req=0xc17f3898 READ_DMA queued ad0: req=0xc17f3898 READ_DMA starting ad0: req=0xc17f3898 READ_DMA begin transaction ad0: req=0xc17f3898 READ_DMA interrupt ad0: req=0xc17f3898 READ_DMA end transaction ad0: req=0xc17f3898 READ_DMA finish bio_taskqueue ad0: req=0xc17f3898 READ_DMA completed entered ad0: req=0xc17f3898 READ_DMA completed callback/wakeup ad0: req=0xc17f3960 READ_DMA queued ad0: req=0xc17f3960 READ_DMA starting ad0: req=0xc17f3960 READ_DMA begin transaction ad0: req=0xc17f3960 READ_DMA interrupt ad0: req=0xc17f3960 READ_DMA end transaction ad0: req=0xc17f3960 READ_DMA finish bio_taskqueue ad0: req=0xc17f3960 READ_DMA completed entered ad0: req=0xc17f3960 READ_DMA completed callback/wakeup ad0: req=0xc17f3a28 READ_DMA queued ad0: req=0xc17f3a28 READ_DMA starting ad0: req=0xc17f3a28 READ_DMA begin transaction ad0: req=0xc17f3a28 READ_DMA interrupt ad0: req=0xc17f3a28 READ_DMA end transaction ad0: req=0xc17f3a28 READ_DMA finish bio_taskqueue ad0: req=0xc17f3a28 READ_DMA completed entered ad0: req=0xc17f3a28 READ_DMA completed callback/wakeup ad0: req=0xc17f3af0 READ_DMA queued ad0: req=0xc17f3af0 READ_DMA starting ad0: req=0xc17f3af0 READ_DMA begin transaction ad0: req=0xc17f3af0 READ_DMA interrupt ad0: req=0xc17f3af0 READ_DMA end transaction ad0: req=0xc17f3af0 READ_DMA finish bio_taskqueue ad0: req=0xc17f3af0 READ_DMA completed entered ad0: req=0xc17f3af0 READ_DMA completed callback/wakeup GEOM: new disk ad2 ad2: req=0xc17f3bb8 READ queued ad2: req=0xc17f3bb8 READ starting ad2: req=0xc17f3bb8 READ begin transaction ad2: req=0xc17f3bb8 READ interrupt ad2: req=0xc17f3bb8 READ end transaction ad2: req=0xc17f3bb8 READ finish bio_taskqueue ad2: req=0xc17f3bb8 READ completed entered ad2: req=0xc17f3bb8 READ completed callback/wakeup ad2: req=0xc17f3c80 READ queued ad2: req=0xc17f3c80 READ starting ad2: req=0xc17f3c80 READ begin transaction ad2: req=0xc17f3c80 READ interrupt ad2: req=0xc17f3c80 READ end transaction ad2: req=0xc17f3c80 READ finish bio_taskqueue ad2: req=0xc17f3c80 READ completed entered ad2: req=0xc17f3c80 READ completed callback/wakeup ad2: req=0xc17f3d48 READ queued ad2: req=0xc17f3d48 READ starting ad2: req=0xc17f3d48 READ begin transaction ad2: req=0xc17f3d48 READ interrupt ad2: req=0xc17f3d48 READ end transaction ad2: req=0xc17f3d48 READ finish bio_taskqueue ad2: req=0xc17f3d48 READ completed entered ad2: req=0xc17f3d48 READ completed callback/wakeup ad2: req=0xc17f3e10 READ queued ad2: req=0xc17f3e10 READ starting ad2: req=0xc17f3e10 READ begin transaction ad2: req=0xc17f3e10 READ interrupt ad2: req=0xc17f3e10 READ end transaction ad2: req=0xc17f3e10 READ interrupt ad2: req=0xc17f3e10 READ end transaction ad2: req=0xc17f3e10 READ finish bio_taskqueue ad2: req=0xc17f3e10 READ completed entered ad2: req=0xc17f3e10 READ completed callback/wakeup ad2: req=0xc17f4000 READ queued ad2: req=0xc17f4000 READ starting ad2: req=0xc17f4000 READ begin transaction ad2: req=0xc17f4000 READ interrupt ad2: req=0xc17f4000 READ end transaction ad2: req=0xc17f4000 READ finish bio_taskqueue ad2: req=0xc17f4000 READ completed entered ad2: req=0xc17f4000 READ completed callback/wakeup ad2: req=0xc17f4000 READ queued ad2: req=0xc17f4000 READ starting ad2: req=0xc17f4000 READ begin transaction ad2: req=0xc17f4000 READ interrupt ad2: req=0xc17f4000 READ end transaction ad2: req=0xc17f4000 READ interrupt ad2: req=0xc17f4000 READ end transaction ad2: req=0xc17f4000 READ finish bio_taskqueue ad2: req=0xc17f4000 READ completed entered ad2: req=0xc17f4000 READ completed callback/wakeup ad2: req=0xc17f3e10 READ queued ad2: req=0xc17f3e10 READ starting ad2: req=0xc17f3e10 READ begin transaction ad2: req=0xc17f3e10 READ interrupt ad2: req=0xc17f3e10 READ end transaction ad2: req=0xc17f3e10 READ finish bio_taskqueue ad2: req=0xc17f3e10 READ completed entered ad2: req=0xc17f3e10 READ completed callback/wakeup ad2: req=0xc17f3d48 READ queued ad2: req=0xc17f3d48 READ starting ad2: req=0xc17f3d48 READ begin transaction ad2: req=0xc17f3d48 READ interrupt ad2: req=0xc17f3d48 READ end transaction ad2: req=0xc17f3d48 READ finish bio_taskqueue ad2: req=0xc17f3d48 READ completed entered ad2: req=0xc17f3d48 READ completed callback/wakeup ad2: req=0xc17f3c80 READ queued ad2: req=0xc17f3c80 READ starting ad2: req=0xc17f3c80 READ begin transaction ad2: req=0xc17f3c80 READ interrupt ad2: req=0xc17f3c80 READ end transaction ad2: req=0xc17f3c80 READ finish bio_taskqueue ad2: req=0xc17f3c80 READ completed entered ad2: req=0xc17f3c80 READ completed callback/wakeup ad2: req=0xc17f3bb8 READ queued ad2: req=0xc17f3bb8 READ starting ad2: req=0xc17f3bb8 READ begin transaction ad2: req=0xc17f3bb8 READ interrupt ad2: req=0xc17f3bb8 READ end transaction ad2: req=0xc17f3bb8 READ interrupt ad2: req=0xc17f3bb8 READ end transaction ad2: req=0xc17f3bb8 READ finish bio_taskqueue ad2: req=0xc17f3bb8 READ completed entered ad2: req=0xc17f3bb8 READ completed callback/wakeup ad2: req=0xc17f3af0 READ queued ad2: req=0xc17f3af0 READ starting ad2: req=0xc17f3af0 READ begin transaction ad2: req=0xc17f3af0 READ interrupt ad2: req=0xc17f3af0 READ end transaction ad2: req=0xc17f3af0 READ finish bio_taskqueue ad2: req=0xc17f3af0 READ completed entered ad2: req=0xc17f3af0 READ completed callback/wakeup ad2: req=0xc17f3a28 READ queued ad2: req=0xc17f3a28 READ starting ad2: req=0xc17f3a28 READ begin transaction ad2: req=0xc17f3a28 READ interrupt ad2: req=0xc17f3a28 READ end transaction ad2: req=0xc17f3a28 READ finish bio_taskqueue ad2: req=0xc17f3a28 READ completed entered ad2: req=0xc17f3a28 READ completed callback/wakeup ad2: req=0xc17f3960 READ queued ad2: req=0xc17f3960 READ starting ad2: req=0xc17f3960 READ begin transaction ad2: req=0xc17f3960 READ interrupt ad2: req=0xc17f3960 READ end transaction ad2: req=0xc17f3960 READ interrupt ad2: req=0xc17f3960 READ end transaction ad2: req=0xc17f3960 READ finish bio_taskqueue ad2: req=0xc17f3960 READ completed entered ad2: req=0xc17f3960 READ completed callback/wakeup Trying to mount root from ufs:/dev/ad2s1a ad2: req=0xc17f3898 READ queued ad2: req=0xc17f3898 READ starting ad2: req=0xc17f3898 READ begin transaction ad2: req=0xc17f3898 READ interrupt ad2: req=0xc17f3898 READ end transaction ad2: req=0xc17f3898 READ interrupt ad2: req=0xc17f3898 READ end transaction ad2: req=0xc17f3898 READ interrupt ad2: req=0xc17f3898 READ end transaction ad2: req=0xc17f3898 READ interrupt ad2: req=0xc17f3898 READ end transaction ad2: req=0xc17f3898 READ interrupt ad2: req=0xc17f3898 READ end transaction ad2: req=0xc17f3898 READ interrupt ad2: req=0xc17f3898 READ end transaction ad2: req=0xc17f3898 READ interrupt ad2: req=0xc17f3898 READ end transaction ad2: req=0xc17f3898 READ interrupt ad2: req=0xc17f3898 READ end transaction ad2: req=0xc17f3898 READ interrupt ad2: req=0xc17f3898 READ end transaction ad2: req=0xc17f3898 READ interrupt ad2: req=0xc17f3898 READ end transaction ad2: req=0xc17f3898 READ interrupt ad2: req=0xc17f3898 READ end transaction ad2: req=0xc17f3898 READ interrupt ad2: req=0xc17f3898 READ end transaction ad2: req=0xc17f3898 READ interrupt ad2: req=0xc17f3898 READ end transaction ad2: req=0xc17f3898 READ interrupt ad2: req=0xc17f3898 READ end transaction ad2: req=0xc17f3898 READ interrupt ad2: req=0xc17f3898 READ end transaction ad2: req=0xc17f3898 READ interrupt ad2: req=0xc17f3898 READ end transaction ad2: req=0xc17f3898 READ finish bio_taskqueue ad2: req=0xc17f3898 READ completed entered ad2: req=0xc17f3898 READ completed callback/wakeup ad2: req=0xc17f37d0 READ queued ad2: req=0xc17f37d0 READ starting ad2: req=0xc17f37d0 READ begin transaction ad2: req=0xc17f37d0 READ interrupt ad2: req=0xc17f37d0 READ end transaction ad2: req=0xc17f37d0 READ interrupt ad2: req=0xc17f37d0 READ end transaction ad2: req=0xc17f37d0 READ interrupt ad2: req=0xc17f37d0 READ end transaction ad2: req=0xc17f37d0 READ interrupt ad2: req=0xc17f37d0 READ end transaction ad2: req=0xc17f37d0 READ finish bio_taskqueue ad2: req=0xc17f37d0 READ completed entered ad2: req=0xc17f37d0 READ completed callback/wakeup ad2: req=0xc17f3708 READ queued ad2: req=0xc17f3708 READ starting ad2: req=0xc17f3708 READ begin transaction ad2: req=0xc17f3708 READ interrupt ad2: req=0xc17f3708 READ end transaction ad2: req=0xc17f3708 READ interrupt ad2: req=0xc17f3708 READ end transaction ad2: req=0xc17f3708 READ interrupt ad2: req=0xc17f3708 READ end transaction ad2: req=0xc17f3708 READ interrupt ad2: req=0xc17f3708 READ end transaction ad2: req=0xc17f3708 READ interrupt ad2: req=0xc17f3708 READ end transaction ad2: req=0xc17f3708 READ interrupt ad2: req=0xc17f3708 READ end transaction ad2: req=0xc17f3708 READ interrupt ad2: req=0xc17f3708 READ end transaction ad2: req=0xc17f3708 READ interrupt ad2: req=0xc17f3708 READ end transaction ad2: req=0xc17f3708 READ interrupt ad2: req=0xc17f3708 READ end transaction ad2: req=0xc17f3708 READ interrupt ad2: req=0xc17f3708 READ end transaction ad2: req=0xc17f3708 READ interrupt ad2: req=0xc17f3708 READ end transaction ad2: req=0xc17f3708 READ interrupt ad2: req=0xc17f3708 READ end transaction ad2: req=0xc17f3708 READ interrupt ad2: req=0xc17f3708 READ end transaction ad2: req=0xc17f3708 READ interrupt ad2: req=0xc17f3708 READ end transaction ad2: req=0xc17f3708 READ interrupt ad2: req=0xc17f3708 READ end transaction ad2: req=0xc17f3708 READ interrupt ad2: req=0xc17f3708 READ end transaction ad2: req=0xc17f3708 READ interrupt ad2: req=0xc17f3708 READ end transaction ad2: req=0xc17f3708 READ interrupt ad2: req=0xc17f3708 READ end transaction ad2: req=0xc17f3708 READ interrupt ad2: req=0xc17f3708 READ end transaction ad2: req=0xc17f3708 READ interrupt ad2: req=0xc17f3708 READ end transaction ad2: req=0xc17f3708 READ interrupt ad2: req=0xc17f3708 READ end transaction ad2: req=0xc17f3708 READ interrupt ad2: req=0xc17f3708 READ end transaction ad2: req=0xc17f3708 READ interrupt ad2: req=0xc17f3708 READ end transaction ad2: req=0xc17f3708 READ interrupt ad2: req=0xc17f3708 READ end transaction ad2: req=0xc17f3708 READ interrupt ad2: req=0xc17f3708 READ end transaction ad2: req=0xc17f3708 READ interrupt ad2: req=0xc17f3708 READ end transaction ad2: req=0xc17f3708 READ interrupt ad2: req=0xc17f3708 READ end transaction ad2: req=0xc17f3708 READ interrupt ad2: req=0xc17f3708 READ end transaction ad2: req=0xc17f3708 READ interrupt ad2: req=0xc17f3708 READ end transaction ad2: req=0xc17f3708 READ interrupt ad2: req=0xc17f3708 READ end transaction ad2: req=0xc17f3708 READ interrupt ad2: req=0xc17f3708 READ end transaction ad2: req=0xc17f3708 READ interrupt ad2: req=0xc17f3708 READ end transaction ad2: req=0xc17f3708 READ finish bio_taskqueue ad2: req=0xc17f3708 READ completed entered ad2: req=0xc17f3708 READ completed callback/wakeup ad2: req=0xc17f3640 READ queued ad2: req=0xc17f3640 READ starting ad2: req=0xc17f3640 READ begin transaction ad2: req=0xc17f3640 READ interrupt ad2: req=0xc17f3640 READ end transaction ad2: req=0xc17f3640 READ interrupt ad2: req=0xc17f3640 READ end transaction ad2: req=0xc17f3640 READ interrupt ad2: req=0xc17f3640 READ end transaction ad2: req=0xc17f3640 READ interrupt ad2: req=0xc17f3640 READ end transaction ad2: req=0xc17f3640 READ finish bio_taskqueue ad2: req=0xc17f3640 READ completed entered ad2: req=0xc17f3640 READ completed callback/wakeup ad2: req=0xc17f3578 READ queued ad2: req=0xc17f3578 READ starting ad2: req=0xc17f3578 READ begin transaction ad2: req=0xc17f3578 READ interrupt ad2: req=0xc17f3578 READ end transaction ad2: req=0xc17f3578 READ interrupt ad2: req=0xc17f3578 READ end transaction ad2: req=0xc17f3578 READ interrupt ad2: req=0xc17f3578 READ end transaction ad2: req=0xc17f3578 READ interrupt ad2: req=0xc17f3578 READ end transaction ad2: req=0xc17f3578 READ interrupt ad2: req=0xc17f3578 READ end transaction ad2: req=0xc17f3578 READ interrupt ad2: req=0xc17f3578 READ end transaction ad2: req=0xc17f3578 READ interrupt ad2: req=0xc17f3578 READ end transaction ad2: req=0xc17f3578 READ interrupt ad2: req=0xc17f3578 READ end transaction ad2: req=0xc17f3578 READ interrupt ad2: req=0xc17f3578 READ end transaction ad2: req=0xc17f3578 READ interrupt ad2: req=0xc17f3578 READ end transaction ad2: req=0xc17f3578 READ interrupt ad2: req=0xc17f3578 READ end transaction ad2: req=0xc17f3578 READ interrupt ad2: req=0xc17f3578 READ end transaction ad2: req=0xc17f3578 READ interrupt ad2: req=0xc17f3578 READ end transaction ad2: req=0xc17f3578 READ interrupt ad2: req=0xc17f3578 READ end transaction ad2: req=0xc17f3578 READ interrupt ad2: req=0xc17f3578 READ end transaction ad2: req=0xc17f3578 READ interrupt ad2: req=0xc17f3578 READ end transaction ad2: req=0xc17f3578 READ interrupt ad2: req=0xc17f3578 READ end transaction ad2: req=0xc17f3578 READ interrupt ad2: req=0xc17f3578 READ end transaction ad2: req=0xc17f3578 READ interrupt ad2: req=0xc17f3578 READ end transaction ad2: req=0xc17f3578 READ interrupt ad2: req=0xc17f3578 READ end transaction ad2: req=0xc17f3578 READ interrupt ad2: req=0xc17f3578 READ end transaction ad2: req=0xc17f3578 READ interrupt ad2: req=0xc17f3578 READ end transaction ad2: req=0xc17f3578 READ interrupt ad2: req=0xc17f3578 READ end transaction ad2: req=0xc17f3578 READ interrupt ad2: req=0xc17f3578 READ end transaction ad2: req=0xc17f3578 READ interrupt ad2: req=0xc17f3578 READ end transaction ad2: req=0xc17f3578 READ interrupt ad2: req=0xc17f3578 READ end transaction ad2: req=0xc17f3578 READ interrupt ad2: req=0xc17f3578 READ end transaction ad2: req=0xc17f3578 READ interrupt ad2: req=0xc17f3578 READ end transaction ad2: req=0xc17f3578 READ interrupt ad2: req=0xc17f3578 READ end transaction ad2: req=0xc17f3578 READ interrupt ad2: req=0xc17f3578 READ end transaction ad2: req=0xc17f3578 READ interrupt ad2: req=0xc17f3578 READ end transaction ad2: req=0xc17f3578 READ interrupt ad2: req=0xc17f3578 READ end transaction ad2: req=0xc17f3578 READ finish bio_taskqueue ad2: req=0xc17f3578 READ completed entered ad2: req=0xc17f3578 READ completed callback/wakeup start_init: trying /sbin/init ad2: req=0xc17f34b0 READ queued ad2: req=0xc17f34b0 READ starting ad2: req=0xc17f34b0 READ begin transaction ad2: req=0xc17f34b0 READ interrupt ad2: req=0xc17f34b0 READ end transaction ad2: req=0xc17f34b0 READ interrupt ad2: req=0xc17f34b0 READ end transaction ad2: req=0xc17f34b0 READ interrupt ad2: req=0xc17f34b0 READ end transaction ad2: req=0xc17f34b0 READ interrupt ad2: req=0xc17f34b0 READ end transaction ad2: req=0xc17f34b0 READ interrupt ad2: req=0xc17f34b0 READ end transaction ad2: req=0xc17f34b0 READ interrupt ad2: req=0xc17f34b0 READ end transaction ad2: req=0xc17f34b0 READ interrupt ad2: req=0xc17f34b0 READ end transaction ad2: req=0xc17f34b0 READ interrupt ad2: req=0xc17f34b0 READ end transaction ad2: req=0xc17f34b0 READ interrupt ad2: req=0xc17f34b0 READ end transaction ad2: req=0xc17f34b0 READ interrupt ad2: req=0xc17f34b0 READ end transaction ad2: req=0xc17f34b0 READ interrupt ad2: req=0xc17f34b0 READ end transaction ad2: req=0xc17f34b0 READ interrupt ad2: req=0xc17f34b0 READ end transaction ad2: req=0xc17f34b0 READ interrupt ad2: req=0xc17f34b0 READ end transaction ad2: req=0xc17f34b0 READ interrupt ad2: req=0xc17f34b0 READ end transaction ad2: req=0xc17f34b0 READ interrupt ad2: req=0xc17f34b0 READ end transaction ad2: req=0xc17f34b0 READ interrupt ad2: req=0xc17f34b0 READ end transaction ad2: req=0xc17f34b0 READ interrupt ad2: req=0xc17f34b0 READ end transaction ad2: req=0xc17f34b0 READ interrupt ad2: req=0xc17f34b0 READ end transaction ad2: req=0xc17f34b0 READ interrupt ad2: req=0xc17f34b0 READ end transaction ad2: req=0xc17f34b0 READ interrupt ad2: req=0xc17f34b0 READ end transaction ad2: req=0xc17f34b0 READ interrupt ad2: req=0xc17f34b0 READ end transaction ad2: req=0xc17f34b0 READ interrupt ad2: req=0xc17f34b0 READ end transaction ad2: req=0xc17f34b0 READ interrupt ad2: req=0xc17f34b0 READ end transaction ad2: req=0xc17f34b0 READ interrupt ad2: req=0xc17f34b0 READ end transaction ad2: req=0xc17f34b0 READ interrupt ad2: req=0xc17f34b0 READ end transaction ad2: req=0xc17f34b0 READ interrupt ad2: req=0xc17f34b0 READ end transaction ad2: req=0xc17f34b0 READ interrupt ad2: req=0xc17f34b0 READ end transaction ad2: req=0xc17f34b0 READ interrupt ad2: req=0xc17f34b0 READ end transaction ad2: req=0xc17f34b0 READ interrupt ad2: req=0xc17f34b0 READ end transaction ad2: req=0xc17f34b0 READ interrupt ad2: req=0xc17f34b0 READ end transaction ad2: req=0xc17f34b0 READ interrupt ad2: req=0xc17f34b0 READ end transaction ad2: req=0xc17f34b0 READ interrupt ad2: req=0xc17f34b0 READ end transaction ad2: req=0xc17f34b0 READ finish bio_taskqueue ad2: req=0xc17f34b0 READ completed entered ad2: req=0xc17f34b0 READ completed callback/wakeup ad2: req=0xc17f33e8 READ queued ad2: req=0xc17f33e8 READ starting ad2: req=0xc17f33e8 READ begin transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ finish bio_taskqueue ad2: req=0xc17f33e8 READ completed entered ad2: req=0xc17f33e8 READ completed callback/wakeup ad2: req=0xc17f3258 READ queued ad2: req=0xc17f3258 READ starting ad2: req=0xc17f3258 READ begin transaction aad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ finish bio_taskqueue d2: req=0ad2: req=0xc17f3320 xc17f3258 READ queueREAD compld ad2: reeted enterq=0xc17f3ed ad2:3 req=0xc127f3258 RE0AD complet READ staed callbarting acd2: req=0xk/wakeup c17f3320 READ begin transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ finish bio_taskqueue ad2: req=0xc17f3320 READ completed entered ad2: req=0xc17f3320 READ completed callback/wakeup ad2: req=0xc17f3190 READ queued ad2: req=0xc17f3190 READ starting ad2: req=0xc17f3190 READ begin transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ finish bio_taskqueue ad2: req=0xc17f3190 READ completed entered ad2: req=0xc17f3190 READ completed callback/wakeup ad2: req=0xc17f30c8 READ queued ad2: req=0xc17f30c8 READ starting ad2: req=0xc17f30c8 READ begin transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ finish bio_taskqueue ad2: req=0xc17f30c8 READ completed entered ad2: req=0xc17f30c8 READ completed callback/wakeup ad2: req=0xc17f3000 READ queued ad2: req=0xc17f3000 READ starting ad2: req=0xc17f3000 READ begin transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ finish bio_taskqueue ad2: req=0xc17f3000 READ completed entered ad2: req=0xc17f3000 READ completed callback/wakeup ad2: req=0xc17f3000 READ queued ad2: req=0xc17f3000 READ starting ad2: req=0xc17f3000 READ begin transaction aad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ interrupt ad2: req=0xc17f3000 READ end transaction ad2: req=0xc17f3000 READ finish bio_taskqueue d2: req=0ad2: reqxc17f30c8=0xc17f3000 READ co READ queumpleted ened ad2: treq=0xc17fered ad2:3 req=0xc10c8 READ 7starting n3000 READad2: req=0 complexted callbc17f30c8 ack/wakeupREAD begi transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ interrupt ad2: req=0xc17f30c8 READ end transaction ad2: req=0xc17f30c8 READ finish bio_taskqueue ad2: req=0xc17f30c8 READ completed entered ad2: req=0xc17f30c8 READ completed callback/wakeup ad2: req=0xc17f3190 READ queued ad2: req=0xc17f3190 READ starting ad2: req=0xc17f3190 READ begin transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ interrupt ad2: req=0xc17f3190 READ end transaction ad2: req=0xc17f3190 READ finish bio_taskqueue ad2: req=0xc17f3190 READ completed entered ad2: req=0xc17f3190 READ completed callback/wakeup ad2: req=0xc17f3320 READ queued ad2: req=0xc17f3320 READ starting ad2: req=0xc17f3320 READ begin transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ interrupt ad2: req=0xc17f3320 READ end transaction ad2: req=0xc17f3320 READ finish bio_taskqueue ad2: req=0xc17f3320 READ completed entered ad2: req=0xc17f3320 READ completed callback/wakeup ad2: req=0xc17f3258 READ queued ad2: req=0xc17f3258 READ starting ad2: req=0xc17f3258 READ begin transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ interrupt ad2: req=0xc17f3258 READ end transaction ad2: req=0xc17f3258 READ finish bio_taskqueue ad2: req=0xc17f3258 READ completed entered ad2: req=0xc17f3258 READ completed callback/wakeup ad2: req=0xc17f33e8 READ queued ad2: req=0xc17f33e8 READ starting ad2: req=0xc17f33e8 READ begin transaction aad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ interrupt ad2: req=0xc17f33e8 READ end transaction ad2: req=0xc17f33e8 READ finish bio_taskqueue d2: req=0axc17f34b0d READ que2ued xd2:: req=0x rc17f34b0eq READ st=0arting ac17f33e8d2 READ c:ompleted req=0xc 1entered 7ad2: req=f0xc17f33e38 READ c4ob0 READ bmegin tranpsaction lead2: req=0xc17f34b0 READ interrupt ad2: req=0xc17f34b0 READ end transaction ad2: req=0xc17f34b0 READ interrupt ad2: req=0xc17f34b0 READ end transaction ad2: req=0xc17f34b0 READ interrupt ad2: req=0xc17f34b0 READ end transaction ad2: req=0xc17f34b0 READ interrupt ad2: req=0xc17f34b0 READ end transaction ad2: req=0xc17f34b0 READ interrupt ad2: req=0xc17f34b0 READ end transaction ad2: req=0xc17f34b0 READ interrupt ad2: req=0xc17f34b0 READ end transaction ad2: req=0xc17f34b0 READ interrupt ad2: req=0xc17f34b0 READ end transaction ad2: req=0xc17f34b0 READ interrupt ad2: req=0xc17f34b0 READ end transaction ad2: req=0xc17f34b0 READ finish bio_taskqueue ted callback/wakeup ad2: req=0xc17f34b0 READ completed entered ad2: req=0xc17f34b0 READ completed callback/wakeup KDB: enter: manual escape to debugger [thread pid 13 tid 100003 ] Stopped at kdb_enter+0x2b: nop db> tr Tracing pid 13 tid 100003 td 0xc15dda80 kdb_enter(c087ae35) at kdb_enter+0x2b scgetc(c09a2780,2,c0654dbe,c1736040,c097e8c0) at scgetc+0x510 sckbdevent(c097e8c0,0,c09a2780) at sckbdevent+0x1c8 atkbd_intr(c097e8c0,0,d3ca4d0c,c0620b90,c097e8c0) at atkbd_intr+0x20 atkbdintr(c097e8c0) at atkbdintr+0x16 ithread_loop(c15da900,d3ca4d38,c15da900,c0620a74,0) at ithread_loop+0x11c fork_exit(c0620a74,c15da900,d3ca4d38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xd3ca4d6c, ebp = 0 --- db> ps pid proc uid ppid pgrp flag stat wmesg wchan cmd 50 c16c1624 0 0 0 0000204 [SLPQ - 0xd4ea6d04][SLP] schedcpu 49 c16c1830 0 0 0 0000204 [SLPQ - 0xc097812c][SLP] nfsiod 3 48 c16c1a3c 0 0 0 0000204 [SLPQ - 0xc0978128][SLP] nfsiod 2 47 c16c1c48 0 0 0 0000204 [SLPQ - 0xc0978124][SLP] nfsiod 1 46 c1723000 0 0 0 0000204 [SLPQ - 0xc0978120][SLP] nfsiod 0 45 c172320c 0 0 0 0000204 [SLPQ syncer 0xc09225dc][SLP] syncer 44 c1723418 0 0 0 0000204 [SLPQ vlruwt 0xc1723418][SLP] vnlru 43 c1723624 0 0 0 0000204 [SLPQ psleep 0xc09700cc][SLP] bufdaemon 42 c1723830 0 0 0 000020c [RUNQ] pagezero 41 c1723a3c 0 0 0 0000204 [SLPQ psleep 0xc097e234][SLP] vmdaemon 40 c1723c48 0 0 0 0000204 [SLPQ psleep 0xc097e1f0][SLP] pagedaemon 39 c1724000 0 0 0 0000204 [IWAIT] swi0: sio 38 c1622c48 0 0 0 0000204 [SLPQ - 0xc15d023c][SLP] fdc0 37 c16c0000 0 0 0 0000204 [SLPQ usbevt 0xc16fe210][SLP] usb1 36 c16c020c 0 0 0 0000204 [SLPQ usbtsk 0xc091d544][SLP] usbtask 35 c16c0418 0 0 0 0000204 [SLPQ usbevt 0xc16c4210][SLP] usb0 9 c16c0624 0 0 0 0000204 [SLPQ - 0xc16d0400][SLP] kqueue taskq 34 c16c0830 0 0 0 0000204 [IWAIT] swi2: cambio 8 c16c0a3c 0 0 0 0000204 [SLPQ - 0xc15dbc00][SLP] acpi_task2 7 c16c0c48 0 0 0 0000204 [SLPQ - 0xc15dbc00][SLP] acpi_task1 6 c16c1000 0 0 0 0000204 [SLPQ - 0xc15dbc00][SLP] acpi_task0 33 c16c120c 0 0 0 0000204 [IWAIT] swi5:+ 5 c16c1418 0 0 0 0000204 [SLPQ - 0xc15dbd80][SLP] thread taskq 32 c1613624 0 0 0 0000204 [IWAIT] swi6:+ 31 c1613830 0 0 0 0000204 [IWAIT] swi6: task queue 30 c1613a3c 0 0 0 0000204 [SLPQ - 0xc091b260][SLP] yarrow 4 c1613c48 0 0 0 0000204 [SLPQ - 0xc091fd68][SLP] g_down 3 c1622000 0 0 0 0000204 [SLPQ - 0xc091fd64][SLP] g_up 2 c162220c 0 0 0 0000204 [SLPQ - 0xc091fd5c][SLP] g_event 29 c1622418 0 0 0 0000204 [IWAIT] swi1: net 28 c1622624 0 0 0 0000204 [IWAIT] swi3: vm 27 c1622830 0 0 0 000020c [RUNQ] swi4: clock sio 26 c1622a3c 0 0 0 0000204 [IWAIT] irq15: ata1 25 c15e120c 0 0 0 0000204 [IWAIT] irq14: ata0 24 c15e1418 0 0 0 0000204 [IWAIT] irq13: 23 c15e1624 0 0 0 0000204 [IWAIT] irq12: rl0 uhci0+ 22 c15e1830 0 0 0 0000204 [IWAIT] irq11: rl2 21 c15e1a3c 0 0 0 0000204 [IWAIT] irq10: rl1 20 c15e1c48 0 0 0 0000204 [IWAIT] irq9: acpi0 19 c1613000 0 0 0 0000204 [IWAIT] irq8: rtc 18 c161320c 0 0 0 0000204 [IWAIT] irq7: ppc0 17 c1613418 0 0 0 0000204 [IWAIT] irq6: fdc0 16 c15dc000 0 0 0 0000204 [IWAIT] irq5: 15 c15dc20c 0 0 0 0000204 [IWAIT] irq4: sio0 14 c15dc418 0 0 0 0000204 [IWAIT] irq3: sio1 13 c15dc624 0 0 0 0000204 [CPU 0] irq1: atkbd0 12 c15dc830 0 0 0 0000204 [IWAIT] irq0: clk 11 c15dca3c 0 0 0 000020c [Can run] idle: cpu0 1 c15dcc48 0 0 0 0004200 [RUNQ] init 10 c15e1000 0 0 0 0000204 [SLPQ ktrace 0xc09207b8][SLP] ktrace 0 c091fe60 0 0 0 0000200 [IWAIT] swapper db> --Apple-Mail-14-1014365941 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I also had to comment out - struct ata_channel *ch = device_get_softc(device_get_parent(dev)); +// struct ata_channel *ch = device_get_softc(device_get_parent (dev)); to make the compiler happy. Stefan -- Stefan Bethke Fon +49 170 346 0140 --Apple-Mail-14-1014365941-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 21:38: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 6D11616A41F; Mon, 29 Aug 2005 21:38: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 F398C43D48; Mon, 29 Aug 2005 21:38: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.3/8.13.3) with ESMTP id j7TLc8AS037977; Mon, 29 Aug 2005 17:38:08 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j7TLc8wC045766; Mon, 29 Aug 2005 17:38:08 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 4DBC47304D; Mon, 29 Aug 2005 17:38:08 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050829213808.4DBC47304D@freebsd-current.sentex.ca> Date: Mon, 29 Aug 2005 17:38:08 -0400 (EDT) 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 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: Mon, 29 Aug 2005 21:38:10 -0000 TB --- 2005-08-29 20:22:04 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-08-29 20:22:04 - starting HEAD tinderbox run for i386/pc98 TB --- 2005-08-29 20:22:04 - cleaning the object tree TB --- 2005-08-29 20:22:24 - checking out the source tree TB --- 2005-08-29 20:22:24 - cd /tinderbox/HEAD/i386/pc98 TB --- 2005-08-29 20:22:24 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-08-29 20:28:41 - building world (CFLAGS=-O2 -pipe) TB --- 2005-08-29 20:28:41 - cd /src TB --- 2005-08-29 20:28: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-08-29 21:32:05 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-08-29 21:32:05 - cd /src TB --- 2005-08-29 21:32:05 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Aug 29 21:32:05 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 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/dev/ata/ata-card.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/dev/awi/if_awi_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/dev/ct/bshw_machdep.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/dev/ct/ct.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/dev/ct/ct_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 -g -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/dev/ed/if_ed_cbus.c In file included from /src/sys/dev/ed/if_ed_cbus.c:49: /src/sys/dev/ed/if_edvar.h:37: error: field `ifmedia' has incomplete type *** Error code 1 Stop in /obj/pc98/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-08-29 21:38:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-08-29 21:38:08 - ERROR: failed to build generic kernel TB --- 2005-08-29 21:38:08 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 21:41: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 D795216A420; Mon, 29 Aug 2005 21:41:31 +0000 (GMT) (envelope-from csjp@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9DD5143D48; Mon, 29 Aug 2005 21:41:31 +0000 (GMT) (envelope-from csjp@FreeBSD.org) Received: from freefall.freebsd.org (csjp@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j7TLfVN1009778; Mon, 29 Aug 2005 21:41:31 GMT (envelope-from csjp@freefall.freebsd.org) Received: (from csjp@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j7TLfVLJ009777; Mon, 29 Aug 2005 21:41:31 GMT (envelope-from csjp) Date: Mon, 29 Aug 2005 21:41:31 +0000 From: "Christian S.J. Peron" To: saturnero@freesbie.org Message-ID: <20050829214131.GA2855@freefall.freebsd.org> References: <20050829205638.GA2458@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050829205638.GA2458@freefall.freebsd.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@FreeBSD.org, pjd@FreeBSD.org Subject: Re: mdconfig recently 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: Mon, 29 Aug 2005 21:41:32 -0000 >Hi everybody, >due to limited connectivity in August, I've been able to >update my -CURRENT box only yesterday since the first days of August >(iirc). > >I noticed that mdconfig -a -t vnode -f ${myfile} isn't working anymore >when ${myfile} is on a read-only filesystem: > >sberta:/usr/local/freesbie-clone/uzip# mdconfig -a -t vnode -f usr.uzip >md0 >sberta:/usr/local/freesbie-clone/uzip# mdconfig -d -u 0 >sberta:/usr/local/freesbie-clone/uzip# mount -fru /usr >sberta:/usr/local/freesbie-clone/uzip# mdconfig -a -t vnode -f usr.uzip >mdconfig: ioctl(/dev/mdctl): Read-only file system > >This makes impossible to use compressed filesystems on devices like >cdrom or read-only diskless environment. Any idea? I'm using: > >FreeBSD sberta.saturnero.sat 7.0-CURRENT FreeBSD 7.0-CURRENT #2: Sat Aug 27 18:1 >5:39 CEST 2005 satu at sberta.saturnero.sat:/usr/obj/usr/src/sys/SBERTA i386 >sberta:/usr/local/freesbie-clone/uzip# > >Bye and thanks in advance, >Dario > Come to think about it, -o readonly isnt going to help. the bottom line is, if the backing store is readonly, it should never be possible to write to it. -- Christian S.J. Peron csjp@FreeBSD.ORG FreeBSD Committer From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 22:17: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 D9CD916A41F for ; Mon, 29 Aug 2005 22:17:33 +0000 (GMT) (envelope-from chris@haakonia.hitnet.rwth-aachen.de) Received: from ms-dienst.rz.rwth-aachen.de (ms-1.rz.RWTH-Aachen.DE [134.130.3.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F98743D45 for ; Mon, 29 Aug 2005 22:17:32 +0000 (GMT) (envelope-from chris@haakonia.hitnet.rwth-aachen.de) Received: from r220-1 (r220-1.rz.RWTH-Aachen.DE [134.130.3.31]) by ms-dienst.rz.rwth-aachen.de (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IM0001YV8L710@ms-dienst.rz.rwth-aachen.de> for current@freebsd.org; Tue, 30 Aug 2005 00:17:31 +0200 (MEST) Received: from relay.rwth-aachen.de ([134.130.3.1]) by r220-1 (MailMonitor for SMTP v1.2.2 ) ; Tue, 30 Aug 2005 00:17:30 +0200 (MEST) Received: from bigboss.hitnet.rwth-aachen.de (bigspace.hitnet.RWTH-Aachen.DE [137.226.181.2]) by relay.rwth-aachen.de (8.13.3/8.13.3/1) with ESMTP id j7TMHUWE007010 for ; Tue, 30 Aug 2005 00:17:30 +0200 (MEST) Received: from moria.hitnet.rwth-aachen.de ([137.226.181.149] helo=haakonia.hitnet.rwth-aachen.de) by bigboss.hitnet.rwth-aachen.de with esmtp (Exim 3.35 #1 (Debian)) id 1E9rwY-0008RQ-00 for ; Tue, 30 Aug 2005 00:17:30 +0200 Received: by haakonia.hitnet.rwth-aachen.de (Postfix, from userid 1001) id 4E21828442; Tue, 30 Aug 2005 00:17:00 +0200 (CEST) Date: Tue, 30 Aug 2005 00:17:00 +0200 From: Christian Brueffer To: current@freebsd.org Message-id: <20050829221700.GC1118@unixpages.org> MIME-version: 1.0 Content-type: multipart/signed; boundary=lMM8JwqTlfDpEaS6; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-disposition: inline User-Agent: Mutt/1.5.9i X-Operating-System: FreeBSD 7.0-CURRENT X-PGP-Key: http://people.FreeBSD.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D Cc: Subject: panic: sackhint rexmit == 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: Mon, 29 Aug 2005 22:17:34 -0000 --lMM8JwqTlfDpEaS6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Got this panic on a 7.0-CURRENT SMP machine with kernel from 19th August. Kernel dump available for further debugging. panic: sackhint rexmit =3D=3D 0 cpuid =3D 1 KDB: enter: panic db> tr kdb_enter() panic() tcp_input() ip_input() netisr_dispatch() ether_demux() ether_input() sf_intr() ithread_loop() fork_exit() fork_trampoline() #23 0xc063ae06 in tcp_input (m=3D0xc1e56400, off0=3D20) at /usr/home/build/src/sys/netinet/tcp_input.c:1915 1915 KASSERT(tp->sackhint. - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --lMM8JwqTlfDpEaS6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFDE4lcbHYXjKDtmC0RAtxSAJ4zm6bNLRB8k0PRKW6FMUwofZw7yQCfWxCJ lkk6tg7Ydp5nvOs892F1iqg= =Q556 -----END PGP SIGNATURE----- --lMM8JwqTlfDpEaS6-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 22:18: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 AD9CF16A41F for ; Mon, 29 Aug 2005 22:18:50 +0000 (GMT) (envelope-from ps@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DED743D67 for ; Mon, 29 Aug 2005 22:18:43 +0000 (GMT) (envelope-from ps@freebsd.org) Received: from [216.145.53.62] (cream.corp.yahoo.com [216.145.53.62]) by elvis.mu.org (Postfix) with ESMTP id 94FB05C75D; Mon, 29 Aug 2005 15:18:43 -0700 (PDT) Message-ID: <431389C1.4080805@freebsd.org> Date: Mon, 29 Aug 2005 15:18:41 -0700 From: Paul Saab User-Agent: Thunderbird 1.6a1 (Macintosh/20050828) MIME-Version: 1.0 To: Christian Brueffer References: <20050829221700.GC1118@unixpages.org> In-Reply-To: <20050829221700.GC1118@unixpages.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: panic: sackhint rexmit == 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: Mon, 29 Aug 2005 22:18:50 -0000 Should already be fixed in -current. Christian Brueffer wrote: > Got this panic on a 7.0-CURRENT SMP machine with kernel from 19th August. > Kernel dump available for further debugging. > > panic: sackhint rexmit == 0 > cpuid = 1 > KDB: enter: panic > db> tr > kdb_enter() > panic() > tcp_input() > ip_input() > netisr_dispatch() > ether_demux() > ether_input() > sf_intr() > ithread_loop() > fork_exit() > fork_trampoline() > > > #23 0xc063ae06 in tcp_input (m=0xc1e56400, off0=20) > at /usr/home/build/src/sys/netinet/tcp_input.c:1915 > 1915 KASSERT(tp->sackhint. > > > - Christian > > From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 22:21: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 C130516A41F for ; Mon, 29 Aug 2005 22:21:47 +0000 (GMT) (envelope-from rainer@ultra-secure.de) Received: from bsd.ultra-secure.de (bsd.ultra-secure.de [62.146.20.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF2A543D60 for ; Mon, 29 Aug 2005 22:21:43 +0000 (GMT) (envelope-from rainer@ultra-secure.de) Received: (qmail 25190 invoked by uid 89); 29 Aug 2005 22:21:42 -0000 Received: by simscan 1.1.0 ppid: 25167, pid: 25183, t: 2.6057s scanners: attach: 1.1.0 clamav: 0.86.2/m:33/d:1045 spam: 3.0.4 Received: from unknown (HELO ?192.168.1.33?) (rainer@ultra-secure.de@217.71.83.52) by bsd.ultra-secure.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 29 Aug 2005 22:21:39 -0000 Message-ID: <43138A6B.30108@ultra-secure.de> Date: Tue, 30 Aug 2005 00:21:31 +0200 From: Rainer Duffner User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050815) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on bsd.ultra-secure.de X-Spam-Level: X-Spam-Status: No, score=-2.6 required=7.5 tests=BAYES_00 autolearn=ham version=3.0.4 Subject: devfs.conf & usb-thumbdrives X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 22:21:47 -0000 Hi, I recently bought some Samsung USB-stick: umass0: 0 USB DRIVE, rev 2.00/2.00, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: < USB DRIVE 2.00> Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: Attempt to query device size failed: UNIT ATTENTION, Not ready to ready change, it 1 GB. I created a devfs.conf-entry like this: lbe# egrep da0 /etc/devfs.conf perm da0 770 perm da0s1 770 but the permissions are still like this: lbe# ll /dev/da0* crw-r----- 1 root operator 11, 112 29 Aug 23:13 /dev/da0 crw-r----- 1 root operator 11, 115 30 Aug 00:15 /dev/da0s1 I first need to restart devfs: lbe# /etc/rc.d/devfs restart lbe# ll /dev/da0* crwxrwx--- 1 root operator 11, 112 29 Aug 23:13 /dev/da0 crwxrwx--- 1 root operator 11, 115 29 Aug 23:13 /dev/da0s1 Why does it ignore these settings until a restart of the service? cheers, Rainer From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 22:25:45 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 B066F16A41F for ; Mon, 29 Aug 2005 22:25:45 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D88143D5E for ; Mon, 29 Aug 2005 22:25:45 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j7TMPicc006480; Mon, 29 Aug 2005 15:25:44 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j7TMPiMT006478; Mon, 29 Aug 2005 15:25:44 -0700 Date: Mon, 29 Aug 2005 15:25:44 -0700 From: Brooks Davis To: Rainer Duffner Message-ID: <20050829222544.GB31841@odin.ac.hmc.edu> References: <43138A6B.30108@ultra-secure.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dc+cDN39EJAMEtIO" Content-Disposition: inline In-Reply-To: <43138A6B.30108@ultra-secure.de> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: freebsd-current@freebsd.org Subject: Re: devfs.conf & usb-thumbdrives X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 22:25:45 -0000 --dc+cDN39EJAMEtIO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 30, 2005 at 12:21:31AM +0200, Rainer Duffner wrote: > Hi, >=20 > I recently bought some Samsung USB-stick: > umass0: 0 USB DRIVE, rev 2.00/2.00, addr 2 > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: < USB DRIVE 2.00> Removable Direct Access SCSI-2 device > da0: 40.000MB/s transfers > da0: Attempt to query device size failed: UNIT ATTENTION, Not ready to=20 > ready change, >=20 >=20 > it 1 GB. >=20 > I created a devfs.conf-entry like this: > lbe# egrep da0 /etc/devfs.conf > perm da0 770 > perm da0s1 770 >=20 > but the permissions are still like this: > lbe# ll /dev/da0* > crw-r----- 1 root operator 11, 112 29 Aug 23:13 /dev/da0 > crw-r----- 1 root operator 11, 115 30 Aug 00:15 /dev/da0s1 >=20 > I first need to restart devfs: > lbe# /etc/rc.d/devfs restart > lbe# ll /dev/da0* > crwxrwx--- 1 root operator 11, 112 29 Aug 23:13 /dev/da0 > crwxrwx--- 1 root operator 11, 115 29 Aug 23:13 /dev/da0s1 >=20 > Why does it ignore these settings until a restart of the service? /etc/devfs.conf is a set of rules to be applied at startup, not a set of rules to apply when creating devices. For that, you want devfs.rules(5). -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --dc+cDN39EJAMEtIO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDE4tnXY6L6fI4GtQRAj9uAJ9gPTEftpD9fP84mEDuq9bZUneK5ACfefSN t4NfvYSfGLpVnF18Th7Tm7k= =sKRL -----END PGP SIGNATURE----- --dc+cDN39EJAMEtIO-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 22:25: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 1CB2916A41F for ; Mon, 29 Aug 2005 22:25:47 +0000 (GMT) (envelope-from jpeg@thilelli.net) Received: from smtp.thilelli.net (smtp.thilelli.net [213.41.129.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 774B743D4C for ; Mon, 29 Aug 2005 22:25:45 +0000 (GMT) (envelope-from jpeg@thilelli.net) Received: from localhost (localhost [127.0.0.1]) by bento.thilelli.net (Postfix) with ESMTP id 68E2E5C98; Tue, 30 Aug 2005 00:25:44 +0200 (CEST) Received: from bento.thilelli.net ([127.0.0.1]) by localhost (bento.thilelli.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 83421-06; Tue, 30 Aug 2005 00:25:39 +0200 (CEST) Received: from webmail.thilelli.net (localhost [127.0.0.1]) by bento.thilelli.net (Postfix) with ESMTP id B75B15C96; Tue, 30 Aug 2005 00:25:39 +0200 (CEST) Received: from 192.168.1.20 (SquirrelMail authenticated user jgabel) by webmail.thilelli.net with HTTP; Tue, 30 Aug 2005 00:25:39 +0200 (CEST) Message-ID: <60957.192.168.1.20.1125354339.squirrel@webmail.thilelli.net> In-Reply-To: <43138A6B.30108@ultra-secure.de> References: <43138A6B.30108@ultra-secure.de> Date: Tue, 30 Aug 2005 00:25:39 +0200 (CEST) From: "Julien Gabel" To: "Rainer Duffner" User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: amavisd-new at thilelli.net Cc: freebsd-current@freebsd.org Subject: Re: devfs.conf & usb-thumbdrives. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jpeg@thilelli.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2005 22:25:47 -0000 > I recently bought some Samsung USB-stick: > umass0: 0 USB DRIVE, rev 2.00/2.00, addr 2 > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: < USB DRIVE 2.00> Removable Direct Access SCSI-2 device > da0: 40.000MB/s transfers > da0: Attempt to query device size failed: UNIT ATTENTION, Not ready to > ready change, it 1 GB. > > I created a devfs.conf-entry like this: > lbe# egrep da0 /etc/devfs.conf > perm da0 770 > perm da0s1 770 > > but the permissions are still like this: > lbe# ll /dev/da0* > crw-r----- 1 root operator 11, 112 29 Aug 23:13 /dev/da0 > crw-r----- 1 root operator 11, 115 30 Aug 00:15 /dev/da0s1 > > I first need to restart devfs: > lbe# /etc/rc.d/devfs restart > lbe# ll /dev/da0* > crwxrwx--- 1 root operator 11, 112 29 Aug 23:13 /dev/da0 > crwxrwx--- 1 root operator 11, 115 29 Aug 23:13 /dev/da0s1 > > Why does it ignore these settings until a restart of the service? For devices not available at boot time, you must prefer devfs.rules(5). -- -jpeg. From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 23:31: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 3857616A41F; Mon, 29 Aug 2005 23:31:17 +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 B64E643D46; Mon, 29 Aug 2005 23:31:16 +0000 (GMT) (envelope-from saturnero@freesbie.org) Received: from [192.168.10.2] (host235-73.pool8256.interbusiness.it [82.56.73.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jail1-fbsd4.consiagnet.it (Postfix) with ESMTP id 8895357AC; Tue, 30 Aug 2005 01:32:43 +0200 (CEST) Message-ID: <43139AC9.50705@freesbie.org> Date: Tue, 30 Aug 2005 01:31:21 +0200 From: Dario Freni User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050828) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christian S.J. Peron" References: <20050829205638.GA2458@freefall.freebsd.org> <20050829214131.GA2855@freefall.freebsd.org> In-Reply-To: <20050829214131.GA2855@freefall.freebsd.org> X-Enigmail-Version: 0.92.0.0 OpenPGP: url=http://www.saturnero.net/saturnero.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC76DB8A492AF1C55B672FF16" Cc: freebsd-current@FreeBSD.org, pjd@FreeBSD.org Subject: Re: mdconfig recently 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: Mon, 29 Aug 2005 23:31:17 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC76DB8A492AF1C55B672FF16 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Christian S.J. Peron wrote: >>Hi everybody, >>due to limited connectivity in August, I've been able to >>update my -CURRENT box only yesterday since the first days of August >>(iirc). >> >>I noticed that mdconfig -a -t vnode -f ${myfile} isn't working anymore >>when ${myfile} is on a read-only filesystem: >> >>sberta:/usr/local/freesbie-clone/uzip# mdconfig -a -t vnode -f usr.uzip >>md0 >>sberta:/usr/local/freesbie-clone/uzip# mdconfig -d -u 0 >>sberta:/usr/local/freesbie-clone/uzip# mount -fru /usr >>sberta:/usr/local/freesbie-clone/uzip# mdconfig -a -t vnode -f usr.uzip >>mdconfig: ioctl(/dev/mdctl): Read-only file system >> >>This makes impossible to use compressed filesystems on devices like >>cdrom or read-only diskless environment. Any idea? I'm using: >> >>FreeBSD sberta.saturnero.sat 7.0-CURRENT FreeBSD 7.0-CURRENT #2: Sat Aug 27 18:1 >>5:39 CEST 2005 satu at sberta.saturnero.sat:/usr/obj/usr/src/sys/SBERTA i386 >>sberta:/usr/local/freesbie-clone/uzip# >> >>Bye and thanks in advance, >>Dario >> > > > Come to think about it, -o readonly isnt going to help. the bottom line is, > if the backing store is readonly, it should never be possible to write to it. -o readonly seems to help: # mdconfig -a -t vnode -f usr.uzip mdconfig: ioctl(/dev/mdctl): Read-only file system # mdconfig -a -t vnode -o readonly -f usr.uzip md0 Anyway, imho, the readonly option should be automatically set if the backing store is readonly. Otherwise, this behaviour should be well documented in mdconfig(8) and/or md(4). Bye and thanks, Dario -- Dario Freni (saturnero@freesbie.org) FreeSBIE developer (http://www.freesbie.org) GPG Public key at http://www.saturnero.net/saturnero.asc --------------enigC76DB8A492AF1C55B672FF16 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDE5rMymi72IiShysRAnXaAKC5Qq8ht3hu460V2JSXS//FdL994QCeJPXW uRpYEARpBEkrajw/+Tckpuk= =6PfX -----END PGP SIGNATURE----- --------------enigC76DB8A492AF1C55B672FF16-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 00:35: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 7A07A16A420 for ; Tue, 30 Aug 2005 00:35:22 +0000 (GMT) (envelope-from ckleski@mbc.edu) Received: from mbc.edu (mail.mbc.edu [216.57.240.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 246FC43D58 for ; Tue, 30 Aug 2005 00:35:20 +0000 (GMT) (envelope-from ckleski@mbc.edu) DKIM-Signature: a=rsa-sha1; c=nowsp; d=mbc.edu; s=MDaemon; t=1125362118; x=1125966918; i=ckleski@mbc.edu; q=dns; h=DomainKey-Signature: Received:From:To:Subject:Date:User-Agent:Cc:References: In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-Disposition:Message-Id; b=oy9uqCSaQ00oTQpmau1tXFpMJbelUKS seV+kGTEimMqZ6xXpXVHY+FizL7uo6nl8b4c7cqu8Pohtq5w69kfoSRHqaowhv4h p3xWmrnCY4NjzmidEp27ytP8xCajjcWCQgnIagwv7AddlTLZe9LOyX7yLmVRcZ4c OQ+M+DcxPfC8= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=mbc.edu; c=simple; q=dns; h=from:message-id; b=hJ2psl1VJZbfK9PTrBmZ68aSUrikbPIKlhTn+0KaJje5nwWPr4iCh0rJ6JO4IvVBAOKhqs7E0SGBeEGd3IWnfpYenx+cjikh6DAxpj1gxUDQ9YwKRRNlLnrawrcahRbHIi36oqRqvrcTXs+IhpZrL9+1KEJzeb58Y8DSvA0RzYA=; Received: from [192.168.0.100] by mbc.edu (Cipher TLSv1:RC4-MD5:128) (MDaemon.PRO.v8.1.2c.R) with ESMTP id md50006414418.msg for ; Mon, 29 Aug 2005 20:35:14 -0400 From: Craig Kleski To: freebsd-current@freebsd.org Date: Mon, 29 Aug 2005 20:36:50 +0000 User-Agent: KMail/1.8.1 References: <1125345832.1005.32.camel@leguin> In-Reply-To: <1125345832.1005.32.camel@leguin> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508292036.50597.ckleski@mbc.edu> X-Authenticated-Sender: ckleski@mbc.edu X-Spam-Processed: mail.mbc.edu, Mon, 29 Aug 2005 20:35:14 -0400 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 65.202.151.105 X-Return-Path: ckleski@mbc.edu X-MDaemon-Deliver-To: freebsd-current@freebsd.org X-MDAV-Processed: mail.mbc.edu, Mon, 29 Aug 2005 20:35:18 -0400 Cc: Eric Anholt Subject: Re: DRM merge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2005 00:35:22 -0000 On Monday 29 August 2005 08:03 pm, Eric Anholt wrote: > I've put a patch to merge current DRM CVS to FreeBSD here: > http://people.freebsd.org/~anholt/dri/drm-20050826.diff > > Along with various changes as usual, it includes jake@'s port of the > VIA DRM (note: this requires a patch to the x server to work, which > is in X.org CVS). > > I've tested on r200, r128, mga, sis on my x86 testbox. However, I > was getting a crash on X startup with DRI on my amd64 desktop. I > couldn't get it to drop to debugger for some reason, so I don't know > if the merge is at fault or not. So, I would really appreciate some > testing on amd64, in particular. Is i915 DRI working? From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 00:38: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 8721116A420 for ; Tue, 30 Aug 2005 00:38:29 +0000 (GMT) (envelope-from dodell@offmyserver.com) Received: from raqdevil.offmyserver.com (ext-unused-110.ixsystems.net [206.40.55.110]) by mx1.FreeBSD.org (Postfix) with ESMTP id C442343D69 for ; Tue, 30 Aug 2005 00:38:26 +0000 (GMT) (envelope-from dodell@offmyserver.com) Received: from raqdevil.offmyserver.com (dho@localhost [127.0.0.1]) by raqdevil.offmyserver.com (8.13.1/8.13.1) with ESMTP id j7U0cLpN089030; Mon, 29 Aug 2005 17:38:21 -0700 (PDT) (envelope-from dodell@offmyserver.com) Received: (from dho@localhost) by raqdevil.offmyserver.com (8.13.1/8.13.1/Submit) id j7U0cLZR089029; Mon, 29 Aug 2005 17:38:21 -0700 (PDT) (envelope-from dodell@offmyserver.com) X-Authentication-Warning: raqdevil.offmyserver.com: dho set sender to dodell@offmyserver.com using -f Date: Mon, 29 Aug 2005 17:38:21 -0700 From: "Devon H. O'Dell" To: Craig Kleski Message-ID: <20050830003821.GZ58560@raqdevil.offmyserver.com> References: <1125345832.1005.32.camel@leguin> <200508292036.50597.ckleski@mbc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200508292036.50597.ckleski@mbc.edu> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org, Eric Anholt Subject: Re: DRM merge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2005 00:38:29 -0000 On Mon, Aug 29, 2005 at 08:36:50PM +0000, Craig Kleski wrote: > On Monday 29 August 2005 08:03 pm, Eric Anholt wrote: > > I've put a patch to merge current DRM CVS to FreeBSD here: > > http://people.freebsd.org/~anholt/dri/drm-20050826.diff > > > > Along with various changes as usual, it includes jake@'s port of the > > VIA DRM (note: this requires a patch to the x server to work, which > > is in X.org CVS). > > > > I've tested on r200, r128, mga, sis on my x86 testbox. However, I > > was getting a crash on X startup with DRI on my amd64 desktop. I > > couldn't get it to drop to debugger for some reason, so I don't know > > if the merge is at fault or not. So, I would really appreciate some > > testing on amd64, in particular. > > Is i915 DRI working? No. From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 00:40: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 1EAF516A41F; Tue, 30 Aug 2005 00:40:03 +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 7BE9843D46; Tue, 30 Aug 2005 00:40:02 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.31]) (authenticated bits=0) by cain.gsoft.com.au (8.13.4/8.13.4) with ESMTP id j7U0dpik048576 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 30 Aug 2005 10:09:56 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Don Lewis Date: Tue, 30 Aug 2005 10:09:32 +0930 User-Agent: KMail/1.8.1 References: <200508291815.j7TIFXw1013092@gw.catspoiler.org> In-Reply-To: <200508291815.j7TIFXw1013092@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1842116.vNLOQVKfAC"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200508301009.46402.doconnor@gsoft.com.au> X-Spam-Score: -2.82 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.51 on 203.31.81.10 Cc: freebsd-current@freebsd.org, kabaev@gmail.com Subject: Re: Odd performance problem (hitching) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2005 00:40:03 -0000 --nextPart1842116.vNLOQVKfAC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 30 August 2005 03:45, Don Lewis wrote: > Any more info on this problem? I just got my MFC reminder for this > change and I don't want to request permission for the MFC until I know > for sure that it (or 1.636, which is also has a pending MFC) isn't the > cause of the problem. I backed out that change and have observed no change whatsoever. > What else is happening on machine when the symptoms occur? I would only > expect vfs_subr.c 1.636 and 1.642 to affect the behaviour if there was a > lot of file system activity that put pressure on the system to free up > vnodes. It's my workstation/laptop so.. "a variety of things" :) The hitching happens even when the system is idle so I think you can MFC=20 safely. =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 --nextPart1842116.vNLOQVKfAC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBDE6rS5ZPcIHs/zowRAjZbAJ0T7cZyrLSWVYJkXNvM4+c6caWMpACfRmRh BFM5g37sLzo8a5FBHRSfZ1Y= =VNVz -----END PGP SIGNATURE----- --nextPart1842116.vNLOQVKfAC-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 02:50:39 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 B0AEB16A41F for ; Tue, 30 Aug 2005 02:50:39 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 643BA43D45 for ; Tue, 30 Aug 2005 02:50:39 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id j7U2oRhe014021; Mon, 29 Aug 2005 19:50:35 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200508300250.j7U2oRhe014021@gw.catspoiler.org> Date: Mon, 29 Aug 2005 19:50:27 -0700 (PDT) From: Don Lewis To: doconnor@gsoft.com.au In-Reply-To: <200508301009.46402.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org, kabaev@gmail.com Subject: Re: Odd performance problem (hitching) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2005 02:50:39 -0000 On 30 Aug, Daniel O'Connor wrote: > On Tuesday 30 August 2005 03:45, Don Lewis wrote: >> Any more info on this problem? I just got my MFC reminder for this >> change and I don't want to request permission for the MFC until I know >> for sure that it (or 1.636, which is also has a pending MFC) isn't the >> cause of the problem. > > I backed out that change and have observed no change whatsoever. > >> What else is happening on machine when the symptoms occur? I would only >> expect vfs_subr.c 1.636 and 1.642 to affect the behaviour if there was a >> lot of file system activity that put pressure on the system to free up >> vnodes. > > It's my workstation/laptop so.. "a variety of things" :) > > The hitching happens even when the system is idle so I think you can MFC > safely. I'd be most suspicious of the MNT_VNODE_FOREACH loop in ffs_sync(), especially if the symptoms occur every 30 seconds. Running the CPU at slow speed (with powerd, etc.) is likely to aggravate the problem. What is the value of "sysctl kern.maxvnodes"? You might try significantly decreasing MAXVNODES_MAX in sys/kern/vfs_subr.c and rebuilding your kernel. From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 03:05: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 96A2116A41F; Tue, 30 Aug 2005 03:05:57 +0000 (GMT) (envelope-from demizu@dd.iij4u.or.jp) Received: from r-dd.iij4u.or.jp (r-dd.iij4u.or.jp [210.130.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id F3B9643D46; Tue, 30 Aug 2005 03:05:56 +0000 (GMT) (envelope-from demizu@dd.iij4u.or.jp) Received: from localhost (h124.p049.iij4u.or.jp [210.130.49.124]) by r-dd.iij4u.or.jp (4U-MR/r-dd) id j7U35oTn020072; Tue, 30 Aug 2005 12:05:51 +0900 (JST) Date: Tue, 30 Aug 2005 12:06:04 +0900 (JST) Message-Id: <20050830.120604.97293728.Noritoshi@Demizu.ORG> From: Noritoshi Demizu To: Paul Saab In-Reply-To: <431389C1.4080805@freebsd.org> References: <20050829221700.GC1118@unixpages.org> <431389C1.4080805@freebsd.org> X-Mailer: Mew version 4.1 on Emacs 21 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: panic: sackhint rexmit == 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: Tue, 30 Aug 2005 03:05:57 -0000 > > #23 0xc063ae06 in tcp_input (m=0xc1e56400, off0=20) > > at /usr/home/build/src/sys/netinet/tcp_input.c:1915 > > 1915 KASSERT(tp->sackhint. > Should already be fixed in -current. The change of tcp_input.c rev 1.283 does not *fix* the problem. It is just a workaround of the problem. I believe the real problem is that tp->snd_cwnd, tp->snd_ssthresh, tp->snd_recover, and tp->snd_nxt are falsely recovered by an algorithm using tp->t_badrxtwin in the following scenario. 1. An Retransmission Timeout occurs. Now, t_rxtshift is 1. (snd_cwnd, snd_ssthresh, snd_recover are saved in tcp_timer_rexmt().) 2. Before t_rxtshift is reset to zero, Fast Retransmit is triggered and TCP enters Fast Recovery. (Note: t_rxtshift is reset to zero by tcp_xmit_timer() when a new RTT measurement is taken. If my memory serves correctly, this behavior is specified in RFC2988). 3. A partial ACK or a full ACK is received before "ticks" reaches at tp->t_badrxtwin. In this case, lines 2047-2056 in tcp_input.c 1.283 recovers snd_cwnd, snd_ssthresh, snd_recover and snd_nxt. (Note: t_rxtshift has not been reset to zero. It will be reset at line 2074 or 2076 of tcp_input.c 1.283.) I believe those variables must not be recovered in this case. Since snd_recover is recovered, snd_recover becomes smaller than the actual value. Hence, the condition at line 2134 of tcp_input.c 1.283 falsely becomes true, and TCP falsely exits Fast Recovery. It breaks internal states of TCP SACK. In tcp_input.c 1.282 or before, the possible corruption was detected by the lines removed in the change of tcp_input.c 1.283. Since the check was not so significant, the check was removed as a workaround. I believe the following change fixes the problem by avoiding step 3 above. Introducing a new flag indicating whether t_badrxtwin is valid would be a better solution because a TCP connection may live longer than 2^32 ticks of time. <> 1915: ENTER_FASTRECOVERY(tp); 1916: tp->snd_recover = tp->snd_max; 1917: callout_stop(tp->tt_rexmt); 1918: tp->t_rtttime = 0; + tp->t_badrxtwin = ticks; 1919: if (tp->sack_enable) { Regards, Noritoshi Demizu From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 04:09:09 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 CDCE816A421 for ; Tue, 30 Aug 2005 04:09:09 +0000 (GMT) (envelope-from leafy7382@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DE8F43D48 for ; Tue, 30 Aug 2005 04:09:08 +0000 (GMT) (envelope-from leafy7382@gmail.com) Received: by zproxy.gmail.com with SMTP id z6so715868nzd for ; Mon, 29 Aug 2005 21:09:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=soWc3DwTLAvk3t0s2ryB5mEoHGQJB0vCNNT/X6g/ssbaiiRWfEEP9JZwGDL23qG5iKLs6N4FiUKzmyExLKZwj0sqbONYHpeIWXk/HGm8MJF2OPnYz4UAS0UGqJL9T4QoEeamyVXbrDKe0XAECUCSjxw02eaKZG/5YfpHjvle5Rg= Received: by 10.36.105.13 with SMTP id d13mr1436740nzc; Mon, 29 Aug 2005 21:09:08 -0700 (PDT) Received: by 10.36.88.8 with HTTP; Mon, 29 Aug 2005 21:09:08 -0700 (PDT) Message-ID: Date: Tue, 30 Aug 2005 12:09:08 +0800 From: Jiawei Ye To: Daniel Eischen In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050829192022.GB47151@tongi.org> Cc: freebsd-current@freebsd.org Subject: Re: Strange threading issue with apache2 WITH_THREADS=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, 30 Aug 2005 04:09:09 -0000 On 8/30/05, Daniel Eischen wrote: > > try putting > > > > WITH_APACHE2=3Dyes > > WITH_MPM=3Dworker > > > > in /etc/make.conf, and portupgrade apache. > > > > also, try some "suggestions" as described in libmap.conf(5) >=20 > How about try making sure you're not using multiple thread > libraries at the same time. After upgrading, libpthread's > version # was bumped along with everything else. ldd(1) > is your friend. >=20 > -- > DE I rebuilt all my ports after the version bump, so that does not seem to be the problem. Jiawei --=20 "Without the userland, the kernel is useless." --inspired by The Tao of Programming From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 04:58: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 66FD816A41F for ; Tue, 30 Aug 2005 04:58:36 +0000 (GMT) (envelope-from marcus@FreeBSD.org) Received: from creme-brulee.marcuscom.com (creme-brulee.marcuscom.com [24.172.16.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78E0B43D45 for ; Tue, 30 Aug 2005 04:58:35 +0000 (GMT) (envelope-from marcus@FreeBSD.org) Received: from shumai.marcuscom.com (shumai.marcuscom.com [192.168.1.4]) by creme-brulee.marcuscom.com (8.13.3/8.13.3) with ESMTP id j7U4x7Fh065788 for ; Tue, 30 Aug 2005 00:59:07 -0400 (EDT) (envelope-from marcus@FreeBSD.org) From: Joe Marcus Clarke To: current@FreeBSD.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-D2aJxtgTx0WIkP0gmEan" Organization: FreeBSD, Inc. Date: Tue, 30 Aug 2005 00:58:34 -0400 Message-Id: <1125377914.99029.8.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Cc: Subject: Pointyhat panicked X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2005 04:58:36 -0000 --=-D2aJxtgTx0WIkP0gmEan Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Not sure if this has been reported, but since Kris is out, I thought Id send it in. Pointyhat entered ddb with the following. I was unable to get a dump: db> call doadump Dumping 2047 MB (2 chunks) chunk 0: 1MB (154 pages) ... ok chunk 1: 2047MB (523968 pages) ... fail ** DUMP FAILED (ERROR 1) ** =3D 0x1d However, all the other details are at http://www.marcuscom.com/downloads/pointyhat-panic.txt. Since we need the machine for 6.0 package builds, I cannot leave it at the debugger. Joe --=20 Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome --=-D2aJxtgTx0WIkP0gmEan 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) iD8DBQBDE+d6b2iPiv4Uz4cRAuS7AJ44BBYa/Q2sd80osGFl8v8+D98h6wCghk9f dBshb+54hU3HzjXMsY6tRQA= =HGaz -----END PGP SIGNATURE----- --=-D2aJxtgTx0WIkP0gmEan-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 06:19:45 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 35D6216A41F; Tue, 30 Aug 2005 06:19:45 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fileserver.fields.utoronto.ca (fileserver.fields.utoronto.ca [128.100.216.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id C02BA43D46; Tue, 30 Aug 2005 06:19:44 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fields.fields.utoronto.ca (fields.localdomain [192.168.216.11]) by fileserver.fields.utoronto.ca (8.12.8/8.12.8/Fields 6.0) with ESMTP id j7U6Jivf026052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Aug 2005 02:19:44 -0400 Received: from obsecurity.dyndns.org (localhost.localdomain [127.0.0.1]) by fields.fields.utoronto.ca (8.12.8/8.12.8/Fields WS 6.0) with ESMTP id j7U6Jh6P026427; Tue, 30 Aug 2005 02:19:44 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id F11315136B; Tue, 30 Aug 2005 02:19:42 -0400 (EDT) Date: Tue, 30 Aug 2005 02:19:42 -0400 From: Kris Kennaway To: Joe Marcus Clarke Message-ID: <20050830061942.GA19812@xor.obsecurity.org> References: <1125377914.99029.8.camel@shumai.marcuscom.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline In-Reply-To: <1125377914.99029.8.camel@shumai.marcuscom.com> User-Agent: Mutt/1.4.2.1i Cc: current@FreeBSD.org Subject: Re: Pointyhat panicked X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2005 06:19:45 -0000 --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 30, 2005 at 12:58:34AM -0400, Joe Marcus Clarke wrote: > Not sure if this has been reported, but since Kris is out, I thought Id > send it in. Pointyhat entered ddb with the following. I was unable to > get a dump: >=20 > db> call doadump > Dumping 2047 MB (2 chunks) > chunk 0: 1MB (154 pages) ... ok > chunk 1: 2047MB (523968 pages) ... fail >=20 > ** DUMP FAILED (ERROR 1) ** > =3D 0x1d >=20 > However, all the other details are at > http://www.marcuscom.com/downloads/pointyhat-panic.txt. Since we need > the machine for 6.0 package builds, I cannot leave it at the debugger. FYI, this is a secondary panic, and some other CPU also panicked at the same time. Kris --r5Pyd7+fXNt84Ff3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDE/p+Wry0BWjoQKURAiT7AKDT/afOG7GAwQ2ywMQXIUpQys3bLwCg8ugW VbTr1baQCODTqAUcK934KTA= =/n37 -----END PGP SIGNATURE----- --r5Pyd7+fXNt84Ff3-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 06:22: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 3E67816A41F for ; Tue, 30 Aug 2005 06:22:54 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fileserver.fields.utoronto.ca (fileserver.fields.utoronto.ca [128.100.216.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id C36A743D46 for ; Tue, 30 Aug 2005 06:22:53 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fields.fields.utoronto.ca (fields.localdomain [192.168.216.11]) by fileserver.fields.utoronto.ca (8.12.8/8.12.8/Fields 6.0) with ESMTP id j7U6Mkvf026544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Aug 2005 02:22:46 -0400 Received: from obsecurity.dyndns.org (localhost.localdomain [127.0.0.1]) by fields.fields.utoronto.ca (8.12.8/8.12.8/Fields WS 6.0) with ESMTP id j7U6Mj6P026571; Tue, 30 Aug 2005 02:22:46 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 555105137D; Tue, 30 Aug 2005 02:22:45 -0400 (EDT) Date: Tue, 30 Aug 2005 02:22:45 -0400 From: Kris Kennaway To: Vladimir Grebenschikov Message-ID: <20050830062245.GB19812@xor.obsecurity.org> References: <1125301456.1087.7.camel@localhost> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="A6N2fC+uXW/VQSAv" Content-Disposition: inline In-Reply-To: <1125301456.1087.7.camel@localhost> User-Agent: Mutt/1.4.2.1i Cc: current Subject: Re: Failed to create package for ruby18-bdb1-0.2.2.tbz X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2005 06:22:54 -0000 --A6N2fC+uXW/VQSAv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 29, 2005 at 11:44:16AM +0400, Vladimir Grebenschikov wrote: > Hi=20 >=20 > =3D=3D=3D> Installing for ruby18-bdb1-0.2.2 > =3D=3D=3D> ruby18-bdb1-0.2.2 depends on file: /usr/local/bin/ruby18 - f= ound > =3D=3D=3D> Generating temporary packing list > install -c -p -m 0755 bdb1.so /usr/local/lib/ruby/site_ruby/1.8/i386-free= bsd6 > =3D=3D=3D> Registering installation for ruby18-bdb1-0.2.2 > =3D=3D=3D> Building package for ruby18-bdb1-0.2.2 > Creating package /usr/ports/packages/All/ruby18-bdb1-0.2.2.tbz > Registering depends: ruby-1.8.2_4. > Creating bzip'd tar ball in '/usr/ports/packages/All/ruby18-bdb1-0.2.2.tb= z' > tar: lib/ruby/site_ruby/1.8/i386-freebsd7/bdb1.so: Cannot stat: No such f= ile or directory > pkg_create: make_dist: tar command failed with code 256 > *** Error code 1 >=20 > Stop in /usr/ports/databases/ruby-bdb1. > *** Error code 1 >=20 > Stop in /usr/ports/sysutils/portupgrade. > *** Error code 1 >=20 > Stop in /usr/ports/sysutils/portupgrade. > ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade1575= 3.0 make BATCH=3Dyes DEPENDS_TARGET=3Dpackage reinstall > egrep: /var/db/pkg/portupgrade-20041226_5/+CONTENTS: No such file or dire= ctory You forgot to include details about your configuration, but I'm guessing you recently updated this machine to 7.0 from some older version, but did not rebuild all your packages. Kris --A6N2fC+uXW/VQSAv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDE/s0Wry0BWjoQKURAhWfAKCJhteDo+dItpiLrI3v9+zM3sp0mQCg6dp3 Z0L3hnvDgCZhGccbuiUUwYk= =OJZw -----END PGP SIGNATURE----- --A6N2fC+uXW/VQSAv-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 07:18: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 C4F0416A41F for ; Tue, 30 Aug 2005 07:18:51 +0000 (GMT) (envelope-from freebsd@meijome.net) Received: from sigma.octantis.com.au (ns2.octantis.com.au [207.44.189.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D25B43D46 for ; Tue, 30 Aug 2005 07:18:51 +0000 (GMT) (envelope-from freebsd@meijome.net) Received: (qmail 7076 invoked from network); 30 Aug 2005 17:18:50 +1000 Received: from andromeda.lef.com.au (HELO ?10.168.101.24?) (210.8.93.2) by sigma.octantis.com.au with (DHE-RSA-AES256-SHA encrypted) SMTP; 30 Aug 2005 17:18:50 +1000 Message-ID: <43140856.2050602@meijome.net> Date: Tue, 30 Aug 2005 17:18:46 +1000 From: Norberto Meijome User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: make buildworld stalls - handbook needs updating? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2005 07:18:51 -0000 hi there, FreeBSD cerberus.xxx.xx 6.0-BETA3 FreeBSD 6.0-BETA3 #0: Tue Aug 30 14:35:20 EST 2005 root@cerberus.xxx.xxx:/usr/obj/usr/src/sys/GENERIC amd64 (dual amd64, 4 x SATA) cvsuped a few hours ago with --standard-supfile-- *default host=cvsup.au.FreeBSD.org *default base=/var/db *default prefix=/usr *default release=cvs tag=RELENG_6 *default delete use-rel-suffix *default compress src-all -- If I follow the steps to make buildworld from the handbook ( section 20.4.1), it just stalls, does nothing. ktrace attached to 3 of the make processes spawned didnt show any activity. It worked fine if I did: cd /usr/src/usr.sbin/mergemaster; ./mergemaster.sh -p cd /usr/obj ; chflags -R noschg *; rm -rf * cd /usr/src ; make -j3 buildworld Am I doing something wrong? missing something? should I file a PR? cheers, Beto From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 07:50: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 0853E16A41F for ; Tue, 30 Aug 2005 07:50:07 +0000 (GMT) (envelope-from rainer@ultra-secure.de) Received: from bsd.ultra-secure.de (bsd.ultra-secure.de [62.146.20.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 265DD43D4C for ; Tue, 30 Aug 2005 07:50:03 +0000 (GMT) (envelope-from rainer@ultra-secure.de) Received: (qmail 20685 invoked by uid 89); 30 Aug 2005 07:50:02 -0000 Received: by simscan 1.1.0 ppid: 20637, pid: 20648, t: 2.8009s scanners: attach: 1.1.0 clamav: 0.86.2/m:33/d:1045 spam: 3.0.4 Received: from unknown (HELO ?192.168.100.179?) (rainer@ultra-secure.de@213.196.191.65) by bsd.ultra-secure.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 30 Aug 2005 07:50:00 -0000 Message-ID: <43140FA2.7000001@ultra-secure.de> Date: Tue, 30 Aug 2005 09:49:54 +0200 From: Rainer Duffner User-Agent: Mozilla Thunderbird 1.0.5 (X11/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jpeg@thilelli.net References: <43138A6B.30108@ultra-secure.de> <60957.192.168.1.20.1125354339.squirrel@webmail.thilelli.net> In-Reply-To: <60957.192.168.1.20.1125354339.squirrel@webmail.thilelli.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on bsd.ultra-secure.de X-Spam-Level: X-Spam-Status: No, score=-2.6 required=7.5 tests=AWL,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-current@freebsd.org Subject: Re: devfs.conf & usb-thumbdrives. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2005 07:50:07 -0000 Julien Gabel wrote: >For devices not available at boot time, you must prefer devfs.rules(5). > > Oh. OK, that's probably the reason it doesn't work as expected. ;-) Thanks. Rainer From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 08:20:58 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 F41A716A420; Tue, 30 Aug 2005 08:20:57 +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 6AB0243D5D; Tue, 30 Aug 2005 08:20:49 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp215-145.lns1.adl2.internode.on.net [203.122.215.145]) (authenticated bits=0) by cain.gsoft.com.au (8.13.4/8.13.4) with ESMTP id j7U8KeIj059069 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 30 Aug 2005 17:50:47 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Don Lewis Date: Tue, 30 Aug 2005 17:50:21 +0930 User-Agent: KMail/1.8.1 References: <200508300250.j7U2oRhe014021@gw.catspoiler.org> In-Reply-To: <200508300250.j7U2oRhe014021@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1698497.szEUjhWFQ0"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200508301750.31495.doconnor@gsoft.com.au> X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.51 on 203.31.81.10 Cc: freebsd-current@freebsd.org, kabaev@gmail.com Subject: Re: Odd performance problem (hitching) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2005 08:20:58 -0000 --nextPart1698497.szEUjhWFQ0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 30 August 2005 12:20, Don Lewis wrote: > > The hitching happens even when the system is idle so I think you can MFC > > safely. > > I'd be most suspicious of the MNT_VNODE_FOREACH loop in ffs_sync(), > especially if the symptoms occur every 30 seconds. Running the CPU at > slow speed (with powerd, etc.) is likely to aggravate the problem. What > is the value of "sysctl kern.maxvnodes"? kern.maxvnodes: 35360 kern.minvnodes: 8840 vfs.numvnodes: 12723 vfs.wantfreevnodes: 8840 vfs.freevnodes: 7829 > You might try significantly decreasing MAXVNODES_MAX in > sys/kern/vfs_subr.c and rebuilding your kernel. OK.. I'll try timing when the drop outs happen :) =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 --nextPart1698497.szEUjhWFQ0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBDFBbP5ZPcIHs/zowRAgnNAJ0V4ZUnL9xhsb5q3k3OhfavGwIfpQCffQ24 3hALZFdxToGq+JX2gjfAOfk= =mk+9 -----END PGP SIGNATURE----- --nextPart1698497.szEUjhWFQ0-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 08:27:51 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 A85C716A41F; Tue, 30 Aug 2005 08:27:51 +0000 (GMT) (envelope-from imachine@toya.net.pl) Received: from lazir.toya.net.pl (lazir.toya.net.pl [217.113.224.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3627D43D48; Tue, 30 Aug 2005 08:27:51 +0000 (GMT) (envelope-from imachine@toya.net.pl) Received: from localhost (unknown [192.168.120.26]) by lazir.toya.net.pl (TOYAnet MailServer) with ESMTP id 613E28BCC7; Tue, 30 Aug 2005 10:27:49 +0200 (CEST) Received: from lazir.toya.net.pl ([192.168.120.25]) by localhost (agregat [192.168.120.26]) (amavisd-new, port 10024) with ESMTP id 25914-07; Tue, 30 Aug 2005 10:27:49 +0200 (CEST) Received: from [192.168.0.5] (unknown [85.89.161.206]) by lazir.toya.net.pl (TOYAnet MailServer) with ESMTP id 670978BCE3; Tue, 30 Aug 2005 10:27:47 +0200 (CEST) From: Mateusz =?utf-8?q?J=C4=99drasik?= To: current@freebsd.org, ports@freebsd.org Date: Tue, 30 Aug 2005 10:25:46 +0200 User-Agent: KMail/1.8.2 References: <20050829210303.GH976@galgenberg.net> In-Reply-To: <20050829210303.GH976@galgenberg.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200508301025.47001.imachine@toya.net.pl> X-TOYA-AV: AntyVir-Skaner at toya.net.pl Cc: Subject: Re: FreeBSD-6-BETA3 broken with ports/audio/aureal-kmod; ports/graphics/linux_dri not working. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2005 08:27:51 -0000 Dnia poniedzia=C5=82ek, 29 sierpnia 2005 23:03, Ulrich Spoerlein napisa=C5= =82: > On Sun, 28.08.2005 at 23:40:42 +0200, Mateusz J??drasik wrote: > > The solution I would best see here is bumping > > emulators/linux_base-suse-9.3 as default linux compat, updating the > > unhappy ports to play nicely with such an upgrade, and using xorg-dri > > drivers for linux_dri compatible with the xorg-libs avaliable with > > emulators/linux_base-suse-9.3. > > I already did this locally, but it won't solve your problem. There is no > binary r300 DRI driver in SuSE 9.3 and even compiling one on your own I use r200 radeon cards, so that is not the issue, at least in my case=20 locally; the issue is with the kernel module radeon.ko which is afaik no=20 longer compatible with 4.3.0 drivers for dri from redhat8. If you could whip up a patch of your local hacks, I guess they might be use= ful=20 for any further work of people interested in bumping linux stuff and making= =20 it work alltogether with different linux_base settings. > won't make it load, because you need to hack the DRI stuff so it will > load the appropriate module (see pkg-descr of linux_dri). > > I already asked Eric for the patch, but it looks like he hasn't got it > anymore. > > Ulrich Spoerlein Cheers, /m. =2D-=20 Mateusz J=C4=99drasik From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 08:34:30 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 91D7C16A420 for ; Tue, 30 Aug 2005 08:34:30 +0000 (GMT) (envelope-from imachine@toya.net.pl) Received: from lazir.toya.net.pl (lazir.toya.net.pl [217.113.224.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0207643D46 for ; Tue, 30 Aug 2005 08:34:29 +0000 (GMT) (envelope-from imachine@toya.net.pl) Received: from localhost (unknown [192.168.120.26]) by lazir.toya.net.pl (TOYAnet MailServer) with ESMTP id 4492B8BCF0 for ; Tue, 30 Aug 2005 10:34:28 +0200 (CEST) Received: from lazir.toya.net.pl ([192.168.120.25]) by localhost (agregat [192.168.120.26]) (amavisd-new, port 10024) with ESMTP id 26611-09 for ; Tue, 30 Aug 2005 10:34:27 +0200 (CEST) Received: from [192.168.0.5] (unknown [85.89.161.206]) by lazir.toya.net.pl (TOYAnet MailServer) with ESMTP id C486C8BCF5 for ; Tue, 30 Aug 2005 10:34:26 +0200 (CEST) From: Mateusz =?utf-8?q?J=C4=99drasik?= To: freebsd-current@freebsd.org Date: Tue, 30 Aug 2005 10:32:24 +0200 User-Agent: KMail/1.8.2 References: <1125345832.1005.32.camel@leguin> <200508292036.50597.ckleski@mbc.edu> <20050830003821.GZ58560@raqdevil.offmyserver.com> In-Reply-To: <20050830003821.GZ58560@raqdevil.offmyserver.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200508301032.25239.imachine@toya.net.pl> X-TOYA-AV: AntyVir-Skaner at toya.net.pl Subject: Re: DRM merge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2005 08:34:30 -0000 Dnia wtorek, 30 sierpnia 2005 02:38, Devon H. O'Dell napisa=C5=82: > On Mon, Aug 29, 2005 at 08:36:50PM +0000, Craig Kleski wrote: > > On Monday 29 August 2005 08:03 pm, Eric Anholt wrote: > > > I've put a patch to merge current DRM CVS to FreeBSD here: > > > http://people.freebsd.org/~anholt/dri/drm-20050826.diff > > > > > > Along with various changes as usual, it includes jake@'s port of the > > > VIA DRM (note: this requires a patch to the x server to work, which > > > is in X.org CVS). > > > > > > I've tested on r200, r128, mga, sis on my x86 testbox. However, I > > > was getting a crash on X startup with DRI on my amd64 desktop. I > > > couldn't get it to drop to debugger for some reason, so I don't know > > > if the merge is at fault or not. So, I would really appreciate some > > > testing on amd64, in particular. > > > > Is i915 DRI working? > > No. It seems a kick ass patch :-) Quickly browsing through it tho does not reve= al=20 to me completely if the savage.ko module availability has been resolved for= =20 all us poor souls with savage crappy cards in their laptops - I will=20 nevertheless patch my 6.0-beta box with this asap :-) Thank You for Your great work, I believe I speak for more people when I say= We=20 appreciate it very much! :-) > _______________________________________________ > 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" =2D-=20 Mateusz J=C4=99drasik From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 08:46: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 1837616A421 for ; Tue, 30 Aug 2005 08:46:08 +0000 (GMT) (envelope-from kuriyama@imgsrc.co.jp) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [210.226.20.147]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D58243D4C for ; Tue, 30 Aug 2005 08:46:03 +0000 (GMT) (envelope-from kuriyama@imgsrc.co.jp) Received: from localhost (localhost [127.0.0.1]) by black.imgsrc.co.jp (Postfix) with ESMTP id DCB7D50D48 for ; Tue, 30 Aug 2005 17:46:01 +0900 (JST) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [IPv6:2001:218:422:2::9999]) by black.imgsrc.co.jp (Postfix) with ESMTP id A243150D44 for ; Tue, 30 Aug 2005 17:45:59 +0900 (JST) Date: Tue, 30 Aug 2005 17:45:59 +0900 Message-ID: <7m7je36ce0.wl%kuriyama@imgsrc.co.jp> From: Jun Kuriyama To: Current User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd 0.1 Cc: Subject: panic when filesystem full X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2005 08:46:08 -0000 I bought amd64 box recently, and trying to use 6.0-BETA3 on it. When I built many ports, /tmp filesystem is going to full (used as $WRKDIRPREFIX), and paniced. ----- some character is strange in this serial console log... Aug 30 16:a56:56 waterblue ukernel: pid 4488l6 (bsdtar), uid t0 inumber 263574 on /tmp: filesyvstem full irtual address = 0x0 fault code = supervisor write, page not present instruction pointer = 0x8:0xffffffff8029a849 stack pointer = 0x10:0xffffffffb43673a0 frame pointer = 0x10:0xffffffffb43673b0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 44886 (bsdtar) [thread pid 44886 tid 100120 ] Stopped at putc+0xa9: movb %dil,0(%r8) db> trace Tracing pid 44886 tid 100120 td 0xffffff0060c24be0 putc() at putc+0xa9 ttyoutput() at ttyoutput+0x89 tputchar() at tputchar+0x35 putchar() at putchar+0xf8 kvprintf() at kvprintf+0x91 uprintf() at uprintf+0x1ce ffs_realloccg() at ffs_realloccg+0x7ae ffs_balloc_ufs2() at ffs_balloc_ufs2+0xb76 ffs_write() at ffs_write+0x21d VOP_WRITE_APV() at VOP_WRITE_APV+0xa4 vn_write() at vn_write+0x1c3 dofilewrite() at dofilewrite+0x87 kern_writev() at kern_writev+0x51 write() at write+0x4a syscall() at syscall+0x4b2 Xfast_syscall() at Xfast_syscall+0xa8 --- syscall (4, FreeBSD ELF64, write), rip = 0x8009cb39c, rsp = 0x7fffffffe4d8, rbp = 0x400 --- db> call doadump Dumping 2046 MB (2 chunks) chunk 0: 1MB (148 pages) ... ok chunk 1: 2046MB (523744 pages) 2030 2014 1998 1982 1966 1950 1934 1918 1902 1886 1870 1854 1838 1822 1806 1790 1774 1758 1742 1726 1710 1694 1678 1662 1646 1630 1614 1598 1582 1566 1550 1534 1518 1502 1486 1470 1454 1438 1422 1406 1390 1374 1358 1342 1326 1310 1294 1278 1262 1246 1230 1214 1198 1182 1166 1150 1134 1118 1102 1086 1070 1054 1038 1022 1006 990 974 958 942 926 910 894 878 862 846 830 814 798 782 766 750 734 718 702 686 670 654 638 622 606 590 574 558 542 526 510 494 478 462 446 430 414 398 382 366 350 334 318 302 286 270 254 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14 ... ok ----- % sudo kgdb /boot/kernel/kernel.debug /home/crash/vmcore.0 (kgdb) where #0 doadump () at pcpu.h:172 #1 0xffffffff8017d9f1 in db_fncall (dummy1=0, dummy2=0, dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:489 #2 0xffffffff8017de45 in db_command_loop () at /usr/src/sys/ddb/db_command.c:349 #3 0xffffffff8017fcb3 in db_trap (type=-1271500496, code=0) at /usr/src/sys/ddb/db_main.c:221 #4 0xffffffff802770a9 in kdb_trap (type=12, code=0, tf=0xffffffffb43672f0) at /usr/src/sys/kern/subr_kdb.c:473 #5 0xffffffff803c6bde in trap_fatal (frame=0xffffffffb43672f0, eva=18446742975821269984) at /usr/src/sys/amd64/amd64/trap.c:655 #6 0xffffffff803c6f73 in trap_pfault (frame=0xffffffffb43672f0, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:580 #7 0xffffffff803c7155 in trap (frame= {tf_rdi = 32, tf_rsi = -1097439369136, tf_rdx = 32, tf_rcx = 1, tf_r8 = 0, tf_r9 = 0, tf_rax = 0, tf_rbx = 32, tf_rbp = -1271499856, tf_r10 = 4, tf_r11 = 4, tf_r12 = -1097439369216, tf_r13 = -1271499472, tf_r14 = 0, tf_r15 = -2144892352, tf_trapno = 12, tf_addr = 0, tf_flags = 582, tf_err = 2, tf_rip = -2144753591, tf_cs = 8, tf_rflags = 66118, tf_rsp = -1271499856, tf_ss = 16}) at /usr/src/sys/amd64/amd64/trap.c:359 #8 0xffffffff803b4bcb in calltrap () at /usr/src/sys/amd64/amd64/exception.S:170 #9 0x0000000000000020 in ?? () #10 0xffffff007b842850 in ?? () #11 0x0000000000000020 in ?? () #12 0x0000000000000001 in ?? () #13 0x0000000000000000 in ?? () #14 0x0000000000000000 in ?? () #15 0x0000000000000000 in ?? () #16 0x0000000000000020 in ?? () #17 0xffffffffb43673b0 in ?? () #18 0x0000000000000004 in ?? () #19 0x0000000000000004 in ?? () #20 0xffffff007b842800 in ?? () #21 0xffffffffb4367530 in ?? () #22 0x0000000000000000 in ?? () #23 0xffffffff80278a40 in msglogchar () at /usr/src/sys/kern/subr_prf.c:807 #24 0xffffffff802918a9 in ttyoutput (c=32, tp=0xffffff007b842800) at /usr/src/sys/kern/tty.c:760 #25 0xffffffff80295c65 in tputchar (c=32, tp=0xffffff007b842800) at /usr/src/sys/kern/tty.c:2753 #26 0xffffffff80278b38 in putchar (c=32, arg=0x0) at /usr/src/sys/kern/subr_prf.c:341 #27 0xffffffff80278ce1 in kvprintf (fmt=0xffffffff8044ee4e "is full\n", func=0xffffffff80278a40 , arg=0xffffffffb4367530, radix=10, ap=0x0) at /usr/src/sys/kern/subr_prf.c:523 #28 0xffffffff8027a6ce in uprintf ( fmt=0xffffffff8044ee30 "\n%s: write failed, filesystem is full\n") at /usr/src/sys/kern/subr_prf.c:149 #29 0xffffffff80363c7e in ffs_realloccg (ip=0xffffff004550acc0, lbprev=0, bprev=-1098348712768, bpref=1034712, osize=2048, nsize=6144, cred=0xffffff0000d71c00, bpp=0xffffffffb4367778) at /usr/src/sys/ufs/ffs/ffs_alloc.c:402 #30 0xffffffff803675d6 in ffs_balloc_ufs2 (vp=0xffffff004d3d09b0, startoffset=0, size=5930, cred=0xffffff0000d71c00, flags=50397184, bpp=0xffffffffb4367880) at /usr/src/sys/ufs/ffs/ffs_balloc.c:655 #31 0xffffffff8037c07d in ffs_write (ap=0xffffffffb4367a10) at /usr/src/sys/ufs/ffs/ffs_vnops.c:662 #32 0xffffffff8040a3b4 in VOP_WRITE_APV (vop=0xffffffff805a89e0, a=0xffffffffb4367a10) at vnode_if.c:698 #33 0xffffffff802cc163 in vn_write (fp=0xffffff00515db1e0, uio=0xffffffffb4367b50, active_cred=0x0, flags=0, td=0xffffff0060c24be0) at vnode_if.h:372 #34 0xffffffff802857d7 in dofilewrite (td=0xffffff0060c24be0, fd=3, fp=0xffffff00515db1e0, auio=0xffffffffb4367b50, offset=0, flags=0) at file.h:246 #35 0xffffffff80285aa1 in kern_writev (td=0xffffff0060c24be0, fd=3, auio=0xffffffffb4367b50) at /usr/src/sys/kern/sys_generic.c:402 #36 0xffffffff80285b9a in write (td=0x0, uap=0x0) at /usr/src/sys/kern/sys_generic.c:326 #37 0xffffffff803c7942 in syscall (frame= {tf_rdi = 3, tf_rsi = 5349376, tf_rdx = 4906, tf_rcx = 0, tf_r8 = 12288, tf_r9 = 140737488348184, tf_rax = 4, tf_rbx = 5316608, tf_rbp = 1024, tf_r10 = 6, tf_r11 = 1, tf_r12 = 3, tf_r13 = 5320704, tf_r14 = 5, tf_r15 = 5316608, tf_trapno = 12, tf_addr = 4205132, tf_flags = 10240, tf_err = 2, tf_rip = 34370007964, tf_cs = 43, tf_rflags = 643, tf_rsp = 140737488348376, tf_ss = 35}) at /usr/src/sys/amd64/amd64/trap.c:796 #38 0xffffffff803b4d68 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:272 ---Type to continue, or q to quit---q Quit (kgdb) up 23 #23 0xffffffff80278a40 in msglogchar () at /usr/src/sys/kern/subr_prf.c:807 807 dangling = 0; (kgdb) list 802 if (c == '\0' || c == '\r') 803 return; 804 if (pri != -1 && pri != lastpri) { 805 if (dangling) { 806 msgbuf_addchar(msgbufp, '\n'); 807 dangling = 0; 808 } 809 msgbuf_addchar(msgbufp, '<'); 810 for (p = ksprintn(nbuf, (uintmax_t)pri, 10, NULL); *p;) 811 msgbuf_addchar(msgbufp, *p--); -- Jun Kuriyama // IMG SRC, Inc. // FreeBSD Project From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 08:49: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 91C9816A41F for ; Tue, 30 Aug 2005 08:49:02 +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 2144F43D45 for ; Tue, 30 Aug 2005 08:49:01 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.52 (FreeBSD)) id 1EA1nf-0000SF-Tk; Tue, 30 Aug 2005 12:48:59 +0400 From: Vladimir Grebenschikov To: Kris Kennaway In-Reply-To: <20050830062245.GB19812@xor.obsecurity.org> References: <1125301456.1087.7.camel@localhost> <20050830062245.GB19812@xor.obsecurity.org> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: SWsoft Date: Tue, 30 Aug 2005 12:48:59 +0400 Message-Id: <1125391739.1088.15.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov Cc: current Subject: Re: Failed to create package for ruby18-bdb1-0.2.2.tbz X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vova@fbsd.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2005 08:49:02 -0000 =F7 =D7=D4, 30/08/2005 =D7 02:22 -0400, Kris Kennaway =D0=C9=DB=C5=D4: > On Mon, Aug 29, 2005 at 11:44:16AM +0400, Vladimir Grebenschikov wrote: > > Hi=20 > >=20 > > =3D=3D=3D> Installing for ruby18-bdb1-0.2.2 > > =3D=3D=3D> ruby18-bdb1-0.2.2 depends on file: /usr/local/bin/ruby18 -= found > > =3D=3D=3D> Generating temporary packing list > > install -c -p -m 0755 bdb1.so /usr/local/lib/ruby/site_ruby/1.8/i386-fr= eebsd6 > > =3D=3D=3D> Registering installation for ruby18-bdb1-0.2.2 > > =3D=3D=3D> Building package for ruby18-bdb1-0.2.2 > > Creating package /usr/ports/packages/All/ruby18-bdb1-0.2.2.tbz > > Registering depends: ruby-1.8.2_4. > > Creating bzip'd tar ball in '/usr/ports/packages/All/ruby18-bdb1-0.2.2.= tbz' > > tar: lib/ruby/site_ruby/1.8/i386-freebsd7/bdb1.so: Cannot stat: No such= file or directory > > pkg_create: make_dist: tar command failed with code 256 > > *** Error code 1 > >=20 > > Stop in /usr/ports/databases/ruby-bdb1. > > *** Error code 1 > >=20 > > Stop in /usr/ports/sysutils/portupgrade. > > *** Error code 1 > >=20 > > Stop in /usr/ports/sysutils/portupgrade. > > ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade15= 753.0 make BATCH=3Dyes DEPENDS_TARGET=3Dpackage reinstall > > egrep: /var/db/pkg/portupgrade-20041226_5/+CONTENTS: No such file or di= rectory >=20 > You forgot to include details about your configuration,=20 Sorry > but I'm > guessing you recently updated this machine to 7.0 from some older > version, but did not rebuild all your packages. No, I live on -CURRENT many years, and do 'make world' and 'portupgrade -ap' more or less often.=20 So my machine cross 6-7 boundary some time ago. ruby18-bdb1 successfull installed by 'make install', but make package fails. It was during 'portupgrade -p portupgrade'. Looks like installation was into invalid directory freebsd6 instead of freebsd7 and this=20 vbook:/home/vova 122_> pkg_info -L ruby18-bdb1-0.2.2 Information for ruby18-bdb1-0.2.2: Files: /usr/local/lib/ruby/site_ruby/1.8/i386-freebsd7/bdb1.so vbook:/home/vova 123_> file /usr/local/lib/ruby/site_ruby/1.8/i386-freebsd7= /bdb1.so /usr/local/lib/ruby/site_ruby/1.8/i386-freebsd7/bdb1.so: cannot open `/usr/= local/lib/ruby/site_ruby/1.8/i386-freebsd7/bdb1.so' (No such file or direct= ory) vbook:/home/vova 124_> cd /usr/ports/databases/ruby-bdb1/ vbook:/usr/ports/databases/ruby-bdb1 125_> make -V PKGNAME ruby18-bdb1-0.2.2 vbook:/usr/ports/databases/ruby-bdb1 126_> cat pkg-plist=20 %%RUBY_SITEARCHLIBDIR%%/bdb1.so ... vbook:/usr/ports/databases/ruby-bdb1 127_> make -V RUBY_SITEARCHLIBDIR /usr/local/lib/ruby/site_ruby/1.8/i386-freebsd7 vbook:/usr/ports/databases/ruby-bdb1 128_> find /usr/local/lib/ruby/site_ru= by -name bdb1.so /usr/local/lib/ruby/site_ruby/1.8/i386-freebsd6/bdb1.so vbook:/usr/ports/databases/ruby-bdb1 129_> ls -l /var/db/pkg/ruby18-bdb1-0.2.2/ total 32 -rw-r--r-- 1 root wheel 70 Aug 29 11:54 +COMMENT -rw-r--r-- 1 root wheel 8610 Aug 29 11:54 +CONTENTS -rw-r--r-- 1 root wheel 396 Aug 29 11:54 +DESC -r--r--r-- 1 root wheel 15242 Aug 29 11:54 +MTREE_DIRS -rw-r--r-- 1 root wheel 64 Aug 29 20:21 +REQUIRED_BY vbook:/usr/ports/databases/ruby-bdb1 130_>=20 > Kris --=20 Vladimir B. Grebenschikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 09:18: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 2AE7C16A41F for ; Tue, 30 Aug 2005 09:18:06 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B00F43D45 for ; Tue, 30 Aug 2005 09:18:05 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: (qmail 22018 invoked by uid 89); 30 Aug 2005 09:17:06 -0000 Message-ID: <20050830091706.22017.qmail@avocado.salatschuessel.net> References: <7m7je36ce0.wl%kuriyama@imgsrc.co.jp> In-Reply-To: <7m7je36ce0.wl%kuriyama@imgsrc.co.jp> From: "Oliver Lehmann" To: Jun Kuriyama Date: Tue, 30 Aug 2005 11:17:06 +0200 Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Cc: Current Subject: Re: panic when filesystem full X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2005 09:18:06 -0000 Jun Kuriyama writes: > > I bought amd64 box recently, and trying to use 6.0-BETA3 on it. > > When I built many ports, /tmp filesystem is going to full (used as > $WRKDIRPREFIX), and paniced. I experienced the same some time ago with BETA1, but my box freezed completly (debugging completly, disabled so no debugger). It's amd64 here too From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 10: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 1DB0016A41F for ; Tue, 30 Aug 2005 10:43:43 +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 B351143D49 for ; Tue, 30 Aug 2005 10:43:42 +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.4/8.13.4/NETPLEX) with ESMTP id j7UAhfZf027497; Tue, 30 Aug 2005 06:43:41 -0400 (EDT) Date: Tue, 30 Aug 2005 06:43:41 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Jiawei Ye 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: freebsd-current@freebsd.org Subject: Re: Strange threading issue with apache2 WITH_THREADS=1 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: Tue, 30 Aug 2005 10:43:43 -0000 On Tue, 30 Aug 2005, Jiawei Ye wrote: > On 8/30/05, Daniel Eischen wrote: > > > try putting > > > > > > WITH_APACHE2=yes > > > WITH_MPM=worker > > > > > > in /etc/make.conf, and portupgrade apache. > > > > > > also, try some "suggestions" as described in libmap.conf(5) > > > > How about try making sure you're not using multiple thread > > libraries at the same time. After upgrading, libpthread's > > version # was bumped along with everything else. ldd(1) > > is your friend. > > > > -- > > DE > I rebuilt all my ports after the version bump, so that does not seem > to be the problem. And make sure /etc/libmap.conf isn't forcing libpthread.so.1 somewhere. -- DE From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 12:19: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 3E9FD16A41F for ; Tue, 30 Aug 2005 12:19:16 +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 936B743D48 for ; Tue, 30 Aug 2005 12:19:15 +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 j7UCJ5ba027609; Tue, 30 Aug 2005 13:19:05 +0100 (BST) Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.13.3/8.13.4) with ESMTP id j7UCJ55S031168; Tue, 30 Aug 2005 13:19:05 +0100 (BST) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: (from ga9@localhost) by buffy.york.ac.uk (8.13.3/8.13.4/Submit) id j7UCJ4SG031167; Tue, 30 Aug 2005 13:19:04 +0100 (BST) (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: Fabian Keil In-Reply-To: <20050828095254.3de97e88@localhost> References: <20050821150125.56f992e0@localhost> <20050823133046.Q73182@ury.york.ac.uk> <20050828095254.3de97e88@localhost> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 30 Aug 2005 13:19:04 +0100 Message-Id: <1125404344.30555.8.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 Subject: Re: Reproducible FreeBSD 6.0-BETA2 panic - probably ATA-ng related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2005 12:19:16 -0000 On Sun, 2005-08-28 at 09:52 +0200, Fabian Keil wrote: > Gavin Atkinson wrote: > > > On Sun, 21 Aug 2005, Fabian Keil wrote: > > > I own a Plextor PlexWriter Premium, the drive has a buggy firmware > > > which crashes if you try to burn multi session in SAO mode. > > > On FreeBSD 6.0-BETA2 a panic is caused: > > > > [snip the CD ROM drive detaching...] > > > It's a known issue. I see exactly this same panic 80% of the time on my > > laptop on resume from ACPI suspend. I believe it was introduced during > > the newbus-ification of ATA-mk3. On the call to acd_geom_detach, > > acd_softc is already null. > > > > (kgdb) f 23 > > #23 0xc04dd936 in acd_geom_detach (arg=0xc16dd680, flag=0) > > at /usr/src/sys/dev/ata/atapi-cd.c:199 > > 199 g_wither_geom(cdp->gp, ENXIO); > > (kgdb) list > > 194 acd_geom_detach(void *arg, int flag) > > 195 { > > 196 struct acd_softc *cdp = device_get_ivars(arg); > > 197 > > 198 /* signal geom so we dont get any further requests */ > > 199 g_wither_geom(cdp->gp, ENXIO); > > 200 > > 201 /* fail requests on the queue and any thats "in flight" for this device */ > > 202 ata_fail_requests(arg); > > 203 > > (kgdb) p cdp > > $5 = (struct acd_softc *) 0x0 > > Thanks for the information. Is this the problem you described in > > and did you already find the causing commit? Well, I thought so, but now I'm slightly confused. I had been running with the ATA-III changes for several weeks before they were committed without problem, but updated a couple of weeks after they hit the tree and had this issue. In my mind I was sure the newbus changes happened a week or so after the ATA-III commit, but looking at the CVS logs I don't know any more. However, I can't find any evidence at the moment that I actually reported which commit was to blame, and I have no idea now. I can probably take my laptop back to (say) April 15th and see if I have any problems, however this is made significantly harder due to the version library bump... Gavin Gavin From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 16:45: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 D1A5116A41F for ; Mon, 29 Aug 2005 16:45:55 +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 5712143D45 for ; Mon, 29 Aug 2005 16:45:52 +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.1) with ESMTP id j7TGjp7n075308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.csail.mit.edu issuer=Client+20CA); Mon, 29 Aug 2005 12:45:51 -0400 (EDT) (envelope-from wollman@khavrinen.csail.mit.edu) Received: (from wollman@localhost) by khavrinen.csail.mit.edu (8.13.1/8.13.1/Submit) id j7TGjo4J075305; Mon, 29 Aug 2005 12:45:50 -0400 (EDT) (envelope-from wollman) From: Garrett Wollman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17171.15294.685251.140522@khavrinen.csail.mit.edu> Date: Mon, 29 Aug 2005 12:45:50 -0400 To: Yamamoto Shigeru In-Reply-To: <20050829.211811.74756443.shigeru@iij.ad.jp> References: <20050829.211811.74756443.shigeru@iij.ad.jp> 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]); Mon, 29 Aug 2005 12:45:51 -0400 (EDT) X-Spam-Status: No, score=0.0 required=5.0 tests=none version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on khavrinen.csail.mit.edu X-Mailman-Approved-At: Tue, 30 Aug 2005 12:27:07 +0000 Cc: freebsd-current@FreeBSD.ORG Subject: patch for zoneinfo to make 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, 29 Aug 2005 16:45:56 -0000 < said: > In @src/share/zoneinfo/northamerica Rev. 1.26, 'America/Indianapolis' is > changed to 'America/Indiana/Indianapolis'. > So some fixes are needed for @src/share/zoneinfo/{northamerica,systemv}. > #These fiexes are needed at 'make release'. This will be fixed in a new version of tzdata which should be imported later today. -GAWollman From owner-freebsd-current@FreeBSD.ORG Mon Aug 29 19:16: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 61E1A16A41F; Mon, 29 Aug 2005 19:16:04 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57BFD43D5C; Mon, 29 Aug 2005 19:16:00 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id C79EE811; Mon, 29 Aug 2005 14:15:59 -0500 (CDT) Date: Mon, 29 Aug 2005 14:15:59 -0500 To: Alexander Leidinger Message-ID: <20050829191559.GB6427@soaustin.net> References: <20050829164708.1se6krp2oscgwso4@netchild.homeip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050829164708.1se6krp2oscgwso4@netchild.homeip.net> User-Agent: Mutt/1.5.9i From: linimon@lonesome.com (Mark Linimon) X-Mailman-Approved-At: Tue, 30 Aug 2005 12:27:07 +0000 Cc: ports@freebsd.org, freebsd-emulation@freebsd.org, Mateusz =?iso-8859-1?B?SsSZZHJhc2lr?= , current@freebsd.org Subject: Re: FreeBSD-6-BETA3 broken with ports/audio/aureal-kmod; ports/graphics/linux_dri not working. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Aug 2005 19:16:04 -0000 On Mon, Aug 29, 2005 at 04:47:08PM +0200, Alexander Leidinger wrote: > I also don't think we should switch the [linux-base] default such short > before a release without important reasons (like the security reason > which was the cause of the change from 7.x to 8.0). portmgr would not approve such a switch. At this late date we would have to go through a re-freeze, entire regression test, and re-tag. Since we have already unthawed the tree, and there have been hundreds of commits, it would take weeks before things calmed down again. The 7->8 switch at least happened before an unthaw. mcl From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 00:44:12 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 0D4E816A41F for ; Tue, 30 Aug 2005 00:44:12 +0000 (GMT) (envelope-from Sosec2001@aol.com) Received: from imo-m26.mx.aol.com (imo-m26.mx.aol.com [64.12.137.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id A208843D46 for ; Tue, 30 Aug 2005 00:44:11 +0000 (GMT) (envelope-from Sosec2001@aol.com) Received: from Sosec2001@aol.com by imo-m26.mx.aol.com (mail_out_v38_r4.1.) id n.96.2e8a13d7 (57341) for ; Mon, 29 Aug 2005 20:44:09 -0400 (EDT) From: Sosec2001@aol.com Message-ID: <96.2e8a13d7.304505d9@aol.com> Date: Mon, 29 Aug 2005 20:44:09 EDT To: freebsd-current@freebsd.org MIME-Version: 1.0 X-Mailer: 9.0 for Windows sub 5119 X-Spam-Flag: NO X-Mailman-Approved-At: Tue, 30 Aug 2005 12:27:07 +0000 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Silicon Image Sil 3112 SATARaid Controller X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2005 00:44:12 -0000 I Happen To see Your Message Do You Think I Can Accomplish This Going This Way I Have An Asus Motherboard With 3112 Raid Controller Built In. I Did Not Set Them Up For Raid Configuration. I am Using Windows XP Pro Sp2 I. Want To Add Another 3112 PCI Card To Give Me 2 More SATA Inputs. My System Is Already Operational With The Internal 3112. Will I Have Any Problems Adding This New card? I Want to Add another Raptor Drive And A SATA Plextor 16 x DVD DVD RW Drive. Not In The Raid configuration. I Just Want To Add another Harddrive To Clone To For Backups. My Mb model Asus A7N8X-E Deluxe. I Can't Flash The BIOS Or My System Crashes And Some Of The Programs I Have On This Computer Can't Be Reactivated. So I Went Back To The BIOS It Had When XP Pro Was Installed For The First Time. This Is The NTFS File System. Name David Bernstein 4937 N.W. Foxworth Ave. Port saint Lucie, FL 34983 Ph 772-878-6769 Fx 772-878-8434 Thank You For Your cooperation In This Matter. Hope This Will Work Without Any Problems. I Have 3 Open PCI Slots. I Have A PCI 3112 Controller Board with SATA Cable. If I Plug It In To A PCI Slot Will It Come UP Just Like Any other Device Does When It Is Installed For The First Time. I Have Drivers Already In XP For The Onboard 3112 Controller Chip And I Am Booting From The First SATA Raptor Drive At The Present Time, And The Second Raptor Drive Is Used For My Swap File And Temp Video Data. Will There Be Any Conflicts With Using Them Both Being A 3112 Host Controller Chip And PCI Card Together Working At The Same Time. From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 11:26:09 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 7E6DD16A41F for ; Tue, 30 Aug 2005 11:26:09 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43A8843D45 for ; Tue, 30 Aug 2005 11:26:08 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 09A245EA; Tue, 30 Aug 2005 06:26:08 -0500 (CDT) Date: Tue, 30 Aug 2005 06:26:08 -0500 To: Jun Kuriyama Message-ID: <20050830112608.GA9465@soaustin.net> References: <7m7je36ce0.wl%kuriyama@imgsrc.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7m7je36ce0.wl%kuriyama@imgsrc.co.jp> User-Agent: Mutt/1.5.9i From: linimon@lonesome.com (Mark Linimon) X-Mailman-Approved-At: Tue, 30 Aug 2005 12:27:07 +0000 Cc: Current Subject: Re: panic when filesystem full X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2005 11:26:09 -0000 On Tue, Aug 30, 2005 at 05:45:59PM +0900, Jun Kuriyama wrote: > When I built many ports, /tmp filesystem is going to full (used as > $WRKDIRPREFIX), and paniced. Is this possibly the same as kern/85440? mcl From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 12:39: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 2B3E016A41F for ; Tue, 30 Aug 2005 12:39:25 +0000 (GMT) (envelope-from dreamer2@tikhvin.info) Received: from mail.lsi.ru (mail.lsi.ru [212.58.192.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7B6543D45 for ; Tue, 30 Aug 2005 12:39:24 +0000 (GMT) (envelope-from dreamer2@tikhvin.info) Received: by mail.lsi.ru (Postfix, from userid 426) id CDC9B386FA7; Tue, 30 Aug 2005 16:39:21 +0400 (MSD) Received: from [192.168.8.101] (unknown [212.58.217.41]) by mail.lsi.ru (Postfix) with ESMTP id 6E710386EF6 for ; Tue, 30 Aug 2005 16:39:20 +0400 (MSD) Message-ID: <4314537C.5050808@tikhvin.info> Date: Tue, 30 Aug 2005 16:39:24 +0400 From: Vitaly User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: ru-ru, ru MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <430060FB.1000405@tikhvin.info> In-Reply-To: <430060FB.1000405@tikhvin.info> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: ath bridge panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2005 12:39:25 -0000 Vitaly ÐÉÛÅÔ: > problem on FreeBSD 6.0-BETA1 > ath0 is bridge with fxp0 > panic occured when i connect wireless client to my hostap, client - > FujitsuSiemens PocketLOOX720 with internal 11b adapter > > when his connecting i get next messages > >> couldn't m_pullup >> couldn't m_pullup >> couldn't m_pullup > > > and first ping kill my system > what i need to get more information about this? > >> Fatal trap 12: page fault while in kernel mode >> fault virtual address = 0x10 >> fault code = supervisor read, page not present >> instruction pointer = 0x20:0xc06bef70 >> stack pointer = 0x28:0xd274c85c >> frame pointer = 0x28:0x0 >> 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 = 27 (swi1: net) >> trap number = 12 >> panic: page fault >> Uptime: 4m41s >> Dumping 191 MB (2 chunks) >> chunk 0: 1MB (159 pages) ... ok >> chunk 1: 191MB (48893 pages) 176 160 144 128 112 96 80 64 48 32 16 >> ... ok > > > > >> net.link.ether.bridge.enable: 0 -> 1 >> net.link.ether.bfridge.config: xp0: promiscuous mode enabled >> ath0: promiscuous mode enabled >> fxp0: link state changed to UP >> -> fxp0:2,ath0:2 >> fxp1: link state changed to UP >> fxp0: >> flags=18943 >> mtu 1500 >> options=48 >> inet 192.168.7.1 netmask 0xffffff00 broadcast 192.168.7.255 >> ether 00:04:ac:d7:bd:24 >> media: Ethernet autoselect (100baseTX ) >> status: active >> ath0: flags=8943 mtu >> 1500 >> ether 00:0f:3d:a9:4e:20 >> media: IEEE 802.11 Wireless Ethernet autoselect mode 11g >> >> status: associated >> ssid D2HOME channel 6 bssid 00:0f:3d:a9:4e:20 >> authmode OPEN privacy ON deftxkey 1 >> wepkey 1:104-bit >> txpowmax 39 rtsthreshold 2346 protmode CTS dtimperiod 1 >> bintval 100 > > Problem still exists, what I must do? From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 12:44: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 53C7316A41F for ; Tue, 30 Aug 2005 12:44:18 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id C412D43D45 for ; Tue, 30 Aug 2005 12:44:17 +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 postfix3-1.free.fr (Postfix) with ESMTP id BB85B1734E6; Tue, 30 Aug 2005 14:44:16 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id D54434080; Tue, 30 Aug 2005 14:44:35 +0200 (CEST) Date: Tue, 30 Aug 2005 14:44:35 +0200 From: Jeremie Le Hen To: Matthias Andree Message-ID: <20050830124435.GW659@obiwan.tataz.chchile.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org Subject: Re: nfs through nullfs (was: 6.0-BETA3: ext2fs through nullfs: panic "locking against myself") X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2005 12:44:18 -0000 > Subject says it all. > > mount a ext2 file system, use it as basis for a nullfs mount -> panic. Mount a NFS filesystem, use it as basis for nullfs mount -> panic. -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 13:10: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 DE91C16A41F for ; Tue, 30 Aug 2005 13:10:00 +0000 (GMT) (envelope-from rowinggoon@hotmail.com) Received: from hotmail.com (bay101-f4.bay101.hotmail.com [64.4.56.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 97EC643D45 for ; Tue, 30 Aug 2005 13:10:00 +0000 (GMT) (envelope-from rowinggoon@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 30 Aug 2005 06:10:00 -0700 Message-ID: Received: from 64.4.56.200 by by101fd.bay101.hotmail.msn.com with HTTP; Tue, 30 Aug 2005 13:10:00 GMT X-Originating-IP: [64.4.56.200] X-Originating-Email: [rowinggoon@hotmail.com] X-Sender: rowinggoon@hotmail.com In-Reply-To: <43134562.7040009@errno.com> From: "Hanns Hartman" To: sam@errno.com, caelian@gmail.com Date: Tue, 30 Aug 2005 06:10:00 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 30 Aug 2005 13:10:00.0314 (UTC) FILETIME=[207A2DA0:01C5AD64] Cc: freebsd-current@freebsd.org Subject: Re: wpa_supplicant segfaults with ath X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2005 13:10:01 -0000 That work perfectly thanks. No more errors. I also wanted to know if there is an easy bit of script I can impliment in order to have the wpa_supplicant load at boot up. thanks Hanns >From: Sam Leffler >To: Pascal Hofstee >CC: freebsd-current@freebsd.org, Hanns Hartman >Subject: Re: wpa_supplicant segfaults with ath >Date: Mon, 29 Aug 2005 10:26:58 -0700 > >Pascal Hofstee wrote: >>On Sun, 2005-08-28 at 23:12 -0700, Hanns Hartman wrote: >> >>>Hi, >>> This is my first time posting to the list so if you need more >>>information let me know. also since I have no internet on my freebsd box >>>it is difficult to get all of the verbose output. so here goes. >>> >>>I am using freebsd6.0beta2 on an amd64. I am using the src tree from >>>august 21. >>> >>>I am trying to associate with a 2wire gateway that was supplied by sbc >>>for my dsl. I have set the gateway up with wpa-psk encription. >>>I am able to connect perfectly fine to this gateway with my ibm t42 but >>>when I try to associate with the gateway using wpa_supplicant I get a >>>segmentation fault after the program reaches "wpa: sending eapol-key 4/4" >>> specifially it faults right after displaying "wpa: rsc - >>>hexdump(len=6): 00 00 00 00 00 00" while using option -d for output. >>> >>>when running the supplicant in gdb I get program received SIGSEGV, >>>segmentation fault. 0x000000080082d4d0 in strlen () from /lib/libc.so.6 >>> >>>if there is anything else needed that might help to explain the problem >>>let me know. I appoligize for not having more output to post at this >>>time. >>>thanks for the help >>>Hanns >> >> >>Thank you for posting this ... as it reminded me i should probably file >>a bug report on this. I recently tried to do some investigative work of >>my own hoping to find out why my if_ral interface kept acting up when i >>bumped into the exact same problem myself. >> >>i can tell you why the segfault happens .. though i am not entirely sure >>how it should be fixed properly. >> >>The problem you're experiencing is caused by the ether_ntoa(addr) call >>in /usr/src/usr.sbin/wpa/wpa_supplicant/driver_freebsd.c:280 >> >>ether_ntoa expects a "const struct ether_addr" as it's parameter where >>in the code the parameter passed is a "const unsigned char*", further >>more in that same printf statement seq_len and key_len are being >>displayed using "%d" where this should be "%zu" since these are >>size_t's. The size_t construct happens a few more times in the code if i >>recall correctly. >> >>The actual crash you're experiencing though is caused by the faulty >>ether_ntoa argument. >> >>If somebody more knowledgable on this particular subject could have a >>closer look at what was actually intended here that would be >>appreciated. >> > >A stack trace at the time of the segfault would be useful. The type >mismatches should not be an issue unless there are alignment problems. >Please try the attached change which should correct any alignment issues. > > Sam >Index: driver_freebsd.c >=================================================================== >RCS file: /usr/ncvs/src/usr.sbin/wpa/wpa_supplicant/driver_freebsd.c,v >retrieving revision 1.7 >diff -u -r1.7 driver_freebsd.c >--- driver_freebsd.c 13 Aug 2005 04:23:33 -0000 1.7 >+++ driver_freebsd.c 29 Aug 2005 17:24:14 -0000 >@@ -30,6 +30,7 @@ > > #include > #include >+#include > > #include > #include >@@ -231,8 +232,11 @@ > memset(&wk, 0, sizeof(wk)); > if (addr != NULL && > bcmp(addr, "\xff\xff\xff\xff\xff\xff", IEEE80211_ADDR_LEN) != 0) { >+ struct ether_addr ea; >+ >+ memcpy(&ea, addr, IEEE80211_ADDR_LEN); > wpa_printf(MSG_DEBUG, "%s: addr=%s keyidx=%d", >- __func__, ether_ntoa(addr), key_idx); >+ __func__, ether_ntoa(&ea), key_idx); > memcpy(wk.idk_macaddr, addr, IEEE80211_ADDR_LEN); > wk.idk_keyix = (uint8_t) IEEE80211_KEYIX_NONE; > } else { >@@ -250,6 +254,7 @@ > { > struct wpa_driver_bsd_data *drv = priv; > struct ieee80211req_key wk; >+ struct ether_addr ea; > char *alg_name; > u_int8_t cipher; > >@@ -275,18 +280,19 @@ > return -1; > } > >+ memcpy(&ea, addr, IEEE80211_ADDR_LEN); > wpa_printf(MSG_DEBUG, >- "%s: alg=%s addr=%s key_idx=%d set_tx=%d seq_len=%d key_len=%d", >- __func__, alg_name, ether_ntoa(addr), key_idx, set_tx, >+ "%s: alg=%s addr=%s key_idx=%d set_tx=%d seq_len=%zu key_len=%zu", >+ __func__, alg_name, ether_ntoa(&ea), key_idx, set_tx, > seq_len, key_len); > > if (seq_len > sizeof(u_int64_t)) { >- wpa_printf(MSG_DEBUG, "%s: seq_len %d too big", >+ wpa_printf(MSG_DEBUG, "%s: seq_len %zu too big", > __func__, seq_len); > return -2; > } > if (key_len > sizeof(wk.ik_keydata)) { >- wpa_printf(MSG_DEBUG, "%s: key length %d too big", >+ wpa_printf(MSG_DEBUG, "%s: key length %zu too big", > __func__, key_len); > return -3; > } >_______________________________________________ >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 Tue Aug 30 13:22: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 3B8FF16A41F for ; Tue, 30 Aug 2005 13:22:05 +0000 (GMT) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF8F243D46 for ; Tue, 30 Aug 2005 13:21:56 +0000 (GMT) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id B804044; Tue, 30 Aug 2005 15:21:40 +0200 (SAST) Date: Tue, 30 Aug 2005 15:21:40 +0200 From: John Hay To: Garrett Wollman Message-ID: <20050830132140.GA46369@zibbi.meraka.csir.co.za> References: <20050829.211811.74756443.shigeru@iij.ad.jp> <17171.15294.685251.140522@khavrinen.csail.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17171.15294.685251.140522@khavrinen.csail.mit.edu> User-Agent: Mutt/1.4.1i Cc: freebsd-current@FreeBSD.ORG Subject: Re: patch for zoneinfo to make 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: Tue, 30 Aug 2005 13:22:05 -0000 Hi Garrett, On Mon, Aug 29, 2005 at 12:45:50PM -0400, Garrett Wollman wrote: > < said: > > > In @src/share/zoneinfo/northamerica Rev. 1.26, 'America/Indianapolis' is > > changed to 'America/Indiana/Indianapolis'. > > > So some fixes are needed for @src/share/zoneinfo/{northamerica,systemv}. > > #These fiexes are needed at 'make release'. > > This will be fixed in a new version of tzdata which should be imported > later today. It looks like my snapshot release box is still not happy with it: #################################### ===> share/zoneinfo (distribute) cd /usr/src/share/zoneinfo; make install -DNO_SUBDIR DESTDIR=/R/stage/trees/bas e SHARED=copies umask 022; cd /usr/src/share/zoneinfo; zic -D -d /R/stage/trees/base/usr/share/ zoneinfo -p America/New_York -u root -g wheel -m 444 -y /usr/obj/usr/src/shar e/zoneinfo/yearistype africa antarctica asia australasia etcetera europe factor y northamerica southamerica systemv zic: can't link from /R/stage/trees/base/usr/share/zoneinfo/America/Indianapolis to /R/stage/trees/base/usr/share/zoneinfo/SystemV/EST5: No such file or directo ry *** Error code 1 Stop in /usr/src/share/zoneinfo. ... #################################### John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 13:26: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 6143A16A41F for ; Tue, 30 Aug 2005 13:26:08 +0000 (GMT) (envelope-from mischa.peters@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id B264043D46 for ; Tue, 30 Aug 2005 13:26:07 +0000 (GMT) (envelope-from mischa.peters@gmail.com) Received: by xproxy.gmail.com with SMTP id i31so769766wxd for ; Tue, 30 Aug 2005 06:26:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NRvBYs7jaQ24/+sRO0EA4b/4OcsTyCbaBFY8mBHVhYE3rYYXLof4GosWDFAsKW/VCidzlILRXHIEpoMoxjiRhq7Vw2uFzbltxP+tjnljByHLckRh3d5aFuKgtcclKb8o9o/Cx3FLkyrHr8anzK5z675GfY+w8MorSKmvP3NwJdM= Received: by 10.70.129.8 with SMTP id b8mr127705wxd; Tue, 30 Aug 2005 06:00:27 -0700 (PDT) Received: by 10.70.76.10 with HTTP; Tue, 30 Aug 2005 06:00:27 -0700 (PDT) Message-ID: <25e9cd0105083006006713c8ca@mail.gmail.com> Date: Tue, 30 Aug 2005 15:00:27 +0200 From: Mischa Peters To: =?ISO-8859-2?Q?Krzysztof_Ciep=B3ucha?= In-Reply-To: <4312C7BC.1010603@home.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <25e9cd0105082823337369bb6d@mail.gmail.com> <4312C7BC.1010603@home.pl> Cc: freebsd-current@freebsd.org Subject: Re: LSI Logic fibre channel adapter in FreeBSD 6.0-BETA3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2005 13:26:08 -0000 T24gOC8yOS8wNSwgS3J6eXN6dG9mIENpZXCzdWNoYSA8a3Jpc0Bob21lLnBsPiB3cm90ZToKPiBN aXNjaGEgUGV0ZXJzIHdyb3RlOgo+ID4gSGkgQWxsLAo+ID4KPiA+IEkgYW0gbm90IHN1cmUgaWYg dGhpcyBpcyB0aGUgY29ycmVjdCBsaXN0LiBCdXQgSSBoYXZlIHRoZSBmb2xsb3dpbmcgaXNzdWUu Cj4gPgo+ID4gSSBoYXZlIGEgRmlicmUgQ2hhbm5lbCBjYXJkIGluIG15IHNlcnZlciwgTFNJIExv Z2ljIEZDOTA5QSB3aGljaCB3YXMKPiA+IHdvcmtpbmcgZmluZSB1bmRlciBGcmVlQlNEIDQuMTEg YnV0IGlzIG5vIGxvbmdlciB3b3JraW5nIHdpdGgKPiA+IDYuMC1CRVRBMy4gSSBoYXZlIGFsc28g dHJpZWQgaXQgd2l0aCBCRVRBMSB3aGljaCBhbHNvIGRpZG4ndCB3b3JrLgo+ID4KPiA+IFRoZSB0 aGluZyB0aGF0IEkgc2VlIGluIG1lc3NhZ2VzIGlzOgo+ID4KPiA+IHBjaTA6IDxzZXJpYWwgYnVz LCBGaWJyZSBDaGFubmVsPiBhdCBkZXZpY2UgMTEuMCAobm8gZHJpdmVyIGF0dGFjaGVkKQo+ID4g cGNpMDogPHNlcmlhbCBidXMsIEZpYnJlIENoYW5uZWw+IGF0IGRldmljZSAxMS4xIChubyBkcml2 ZXIgYXR0YWNoZWQpCj4gPgo+ID4gSSBoYXZlIHNlZW4gdGhhdCBpbiBHRU5FUklDIHRoZSBvbGQg bmNyIGRyaXZlcnMgYXJlIGRpc2FibGVkIGFuZCBhcmUKPiA+IHJlcGxhY2VkIHdpdGggc3ltLgo+ ID4gRG9lcyB0aGlzIG1hdHRlciBhdCBhbGwsIG9yIGlzIHRoaXMgYjBya2VuIGFuZCBkb2VzIGl0 IG5lZWRzIGZpeGluZz8KPiAKPiBtYW4gbXB0Cj4gCj4gSEFSRFdBUkUKPiAgICAgICBUaGUgZm9s bG93aW5nIGNvbnRyb2xsZXJzIGFyZSBzdXBwb3J0ZWQgYnkgdGhlIG1wdCBkcml2ZXI6Cj4gCj4g ICAgICAgbyAgIExTSSBMb2dpYyA1M2MxMDMwIChEdWFsIFVsdHJhMzIwIFNDU0kpCj4gICAgICAg byAgIExTSSBMb2dpYyBGQzkwOSAoMUdiL3MgRmlicmUgQ2hhbm5lbCkKPiAgICAgICBvICAgTFNJ IExvZ2ljIEZDOTA5QSAoRHVhbCAxR2IvcyBGaWJyZSBDaGFubmVsKQo+ICAgICAgIG8gICBMU0kg TG9naWMgRkM5MTkgKDJHYi9zIEZpYnJlIENoYW5uZWwpCj4gICAgICAgbyAgIExTSSBMb2dpYyBG QzkyOSwgTFNJIExvZ2ljIEZDOTI5WCAoRHVhbCAyR2IvcyBGaWJyZSBDaGFubmVsKQo+IAo+IAoK SSBoYXZlIHZlcmlmaWVkIHRoYXQgdGhpcyBpcyBpbmRlZWQgZW5hYmxlZCBpbiB0aGUga2VybmVs IGNvbmYgZmlsZS4KCmRldmljZSAgICAgICAgICBtcHQgICAgICAgICAgICAgIyBMU0ktTG9naWMg TVBULUZ1c2lvbgoKQW55dGhpbmcgZWxzZSB0aGF0IEkgbmVlZCB0byBjaGVjaz8KCk1pc2NoYQo= From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 13:29:12 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 8450C16A41F; Tue, 30 Aug 2005 13:29:12 +0000 (GMT) (envelope-from bushman@rsu.ru) Received: from mail.r61.net (mail.r61.net [195.208.245.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 251A143D46; Tue, 30 Aug 2005 13:29:10 +0000 (GMT) (envelope-from bushman@rsu.ru) Received: from stinger.cc.rsu.ru (stinger.cc.rsu.ru [195.208.252.82]) by mail.r61.net (8.13.4/8.13.4) with ESMTP id j7UDSmZW051676; Tue, 30 Aug 2005 17:28:48 +0400 (MSD) (envelope-from bushman@rsu.ru) Date: Tue, 30 Aug 2005 17:32:52 +0400 (MSD) From: Michael Bushkov X-X-Sender: bushman@stinger.cc.rsu.ru To: Dan Nelson In-Reply-To: <20050829163025.GA25664@dan.emsphone.com> Message-ID: <20050830172127.E5409@stinger.cc.rsu.ru> References: <20050827170633.Y5409@stinger.cc.rsu.ru> <43123F3B.8070002@FreeBSD.org> <20050829115740.N5409@stinger.cc.rsu.ru> <20050829163025.GA25664@dan.emsphone.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.86.2, clamav-milter version 0.86 on asterix.r61.net X-Virus-Status: Clean X-Spam-Status: No, score=-5.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on asterix.r61.net Cc: Jacques Vidrine , freebsd-hackers@freebsd.org, Doug Barton , Brooks Davis , freebsd-current@freebsd.org Subject: Re: [PATCH] caching daemon release and nsswitch patches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2005 13:29:12 -0000 On Mon, 29 Aug 2005, Dan Nelson wrote: We can't ensure that, I guess. In the upcoming version (before the 1st of September), the cache would be per-user. This would solve all the security problems. In a little while, I'll implement the ability for cached to act as nscd. So you'll be able to choose the behaviour. > In the last episode (Aug 29), Michael Bushkov said: >> There is some information in my project's description here: >> http://wikitest.freebsd.org/moin.cgi/NsswitchAndCachingTechnicalDetails > > One question that comes to mind: > > It looks like the end-user application is still responsible for > performing nss lookups. How do you ensure that one user can't poison > the cache and cause problems for other users? Could cached do all nss > operations itself (making it more like nscd in other OSes)? > > -- > Dan Nelson > dnelson@allantgroup.com > With best regards, Michael Bushkov Rostov State University From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 13:46: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 5A00A16A41F for ; Tue, 30 Aug 2005 13:46:29 +0000 (GMT) (envelope-from dandee@hellteam.net) Received: from pipa.profix.cz (server1.pcsvet.net [82.208.25.157]) by mx1.FreeBSD.org (Postfix) with ESMTP id DAB2143D46 for ; Tue, 30 Aug 2005 13:46:28 +0000 (GMT) (envelope-from dandee@hellteam.net) Received: from localhost (localhost [127.0.0.1]) by pipa.profix.cz (Postfix) with ESMTP id 620AE4E707; Tue, 30 Aug 2005 15:46:30 +0200 (CEST) Received: from pipa.profix.cz ([127.0.0.1]) by localhost (pipa [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05170-07; Tue, 30 Aug 2005 15:46:30 +0200 (CEST) Received: from gandalf (unknown [80.95.121.105]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by pipa.profix.cz (Postfix) with ESMTP id 1CFB54E706; Tue, 30 Aug 2005 15:46:30 +0200 (CEST) From: =?US-ASCII?Q?Daniel_Dvorak?= To: "'Sam Leffler'" Date: Tue, 30 Aug 2005 15:46:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <431340F9.4060407@errno.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcWsu2tcYsUJ61FWQzegF3t9Of7L1gAFLaBA Message-Id: <20050830134630.1CFB54E706@pipa.profix.cz> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at profix.cz Cc: freebsd-current@freebsd.org Subject: RE: ATHCTRL for ATH X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dandee@volny.cz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2005 13:46:29 -0000 Okay, I tried and it worked fine. And is it possible to rewrite your code of athctrl from madwifi to fbsd to /tools/tools/ath to use sysctl dev.ath.0.X commands instead /proc/net/dev/ath in linux ? Thanks Dan -----Original Message----- From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd-current@freebsd.org] On Behalf Of Sam Leffler Sent: Monday, August 29, 2005 7:08 PM To: dandee@volny.cz Cc: freebsd-current@freebsd.org; 'Milan Obuch' Subject: Re: ATHCTRL for ATH [coming in late here...] athctrl is a trivial program that should be a shell script at best. It currently makes no sense to add this sort of support to ifconfig because each device does things very differently (if at all) and trying to unify the operation is likely to lead to more confusion than anything else. Attached is an untested shell script I wrote for someone else. If you can tell me it does the right thing for you then I'll commit it to tools/tools/ath where I've stuck other similar things. Sam From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 16:14: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 2068C16A420 for ; Tue, 30 Aug 2005 16:14:41 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id A43A443D45 for ; Tue, 30 Aug 2005 16:14:40 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by xproxy.gmail.com with SMTP id i31so797656wxd for ; Tue, 30 Aug 2005 09:14:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=O0sNbCn/6SKdqXz5C4J9xyy8cBpaGbFT4MIWssacrVD/n9MYYAjWZuH8+LwyQaqrG0LxhC9u8wEolY6IUyPeOJkRSTMml7ctfT3q//ti1vFYsf4nCOGTkcERhL/wzSFa5IdGmJ1QElE+0bdhAeDu6+9fM2PcGqEySDpup8d65JI= Received: by 10.70.94.6 with SMTP id r6mr133435wxb; Tue, 30 Aug 2005 09:14:39 -0700 (PDT) Received: by 10.70.115.15 with HTTP; Tue, 30 Aug 2005 09:14:39 -0700 (PDT) Message-ID: <84dead72050830091476c82c74@mail.gmail.com> Date: Tue, 30 Aug 2005 21:44:39 +0530 From: Joseph Koshy To: Randy Bush In-Reply-To: <17073.47359.49105.538751@roam.psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <17073.28802.502964.714076@roam.psg.com> <17073.47359.49105.538751@roam.psg.com> Cc: FreeBSD Current Subject: Re: kbd goes away on multi X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2005 16:14:41 -0000 On 6/16/05, Randy Bush wrote: rb> installing from june snapshot cd on a dell poweredge 2850 rb> 1ru rackem-stackem server rb> install was fine rb> boot single user and all is fine rb> go multi and the keyboard does nothing It appears that once USB gets started up, the onboard 'DRAC' (Dell Remote Access Console, I believe) takes over as a USB "keyboard", leaving the PS/2 keyboard out in the cold. The following work-arounds worked for me: 1) Booting using a USB keyboard attached to one of the USB ports. Attaching a USB keyboard *after* the machine has booted didn't work for some reason. 2) Turning off USB (usbd_enable=3D"NO" in /etc/rc.conf) in single user mode. --=20 FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 16:47: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 8EDF316A420; Tue, 30 Aug 2005 16:47:55 +0000 (GMT) (envelope-from csjp@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 551F043D45; Tue, 30 Aug 2005 16:47:55 +0000 (GMT) (envelope-from csjp@FreeBSD.org) Received: from freefall.freebsd.org (csjp@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j7UGltFq061507; Tue, 30 Aug 2005 16:47:55 GMT (envelope-from csjp@freefall.freebsd.org) Received: (from csjp@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j7UGls0C061506; Tue, 30 Aug 2005 16:47:54 GMT (envelope-from csjp) Date: Tue, 30 Aug 2005 16:47:54 +0000 From: "Christian S.J. Peron" To: Dario Freni Message-ID: <20050830164754.GA53629@freefall.freebsd.org> References: <20050829205638.GA2458@freefall.freebsd.org> <20050829214131.GA2855@freefall.freebsd.org> <43139AC9.50705@freesbie.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43139AC9.50705@freesbie.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@FreeBSD.org, pjd@FreeBSD.org Subject: Re: mdconfig recently broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2005 16:47:55 -0000 On Tue, Aug 30, 2005 at 01:31:21AM +0200, Dario Freni wrote: > > -o readonly seems to help: > > # mdconfig -a -t vnode -f usr.uzip > mdconfig: ioctl(/dev/mdctl): Read-only file system > # mdconfig -a -t vnode -o readonly -f usr.uzip > md0 > > Anyway, imho, the readonly option should be automatically set if the > backing store is readonly. Otherwise, this behaviour should be well > documented in mdconfig(8) and/or md(4). > Fixed in revision 1.44 of mdconfig(8) I have included the commit log for your reference: When using files as backing stores for devices, and the user has requested the device be created read+write, check to see if the backing store is read only through the use of the access(2) system call. If this check fails returning EACCES, EPERM or EROFS then gracefully downgrade the access to read only. Also print a warning message to stderr, informing the user that the access mode they requested is not available. This behavior used to be handled by md(4) but was changed in revision 1.154 Discussed with: pjd, phk, Dario Freni Reviewed by: phk -- Christian S.J. Peron csjp@FreeBSD.ORG FreeBSD Committer From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 17:06:14 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 BC07A16A41F for ; Tue, 30 Aug 2005 17:06:14 +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 ED4DB43D49 for ; Tue, 30 Aug 2005 17:06:06 +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 j7UH65a6073987 for ; Tue, 30 Aug 2005 19:06:05 +0200 (CEST) (envelope-from cracauer@schlepper.zs64.net) Received: (from cracauer@localhost) by schlepper.zs64.net (8.13.3/8.12.9/Submit) id j7UH65c2073986 for freebsd-current@freebsd.org; Tue, 30 Aug 2005 13:06:05 -0400 (EDT) (envelope-from cracauer) Date: Tue, 30 Aug 2005 13:06:05 -0400 From: Martin Cracauer To: freebsd-current@freebsd.org Message-ID: <20050830130605.A73730@cons.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Subject: Recent 6-beta issue: high delay when loading kernel on thinkpad on battery X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2005 17:06:14 -0000 I cannot nail down when exactly this issue was introduced but I think it was recently. I remember to boot this laptop fine when on battery during summer. Recent 6-betas make my thinkpad R40 wait for 80 seconds when loading the kernel (after announcing kernel version but before probing devices), when it is on battery power. On A/C the delay is normal. This is a boot -v screenshot photo of the stage where it is hanging: http://wavehh.dyndns.org/tmp/thinkpad-6beta-delay.jpg As you can see, -v doesn't give a clue what it is doing. It is hanging there doing nothing before reloading the kernel modules. dmesg, acpi stats, kernel config etc is all on: http://www.cons.org/cracauer/machines/grisu/ I just updated these files to be from a -v boot when on A/C. Any idea what this can be caused by? Any additional tests or info I can provide? Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ No warranty. This email is probably produced by one of my cats stepping on the keys. No, I don't have an infinite number of cats. From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 17:13: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 45D4F16A41F for ; Tue, 30 Aug 2005 17:13:32 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id D478E43D48 for ; Tue, 30 Aug 2005 17:13:31 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j7UHDTUJ025911; Tue, 30 Aug 2005 10:13:29 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j7UHDTHp025910; Tue, 30 Aug 2005 10:13:29 -0700 Date: Tue, 30 Aug 2005 10:13:29 -0700 From: Brooks Davis To: Hanns Hartman Message-ID: <20050830171329.GA22722@odin.ac.hmc.edu> References: <43134562.7040009@errno.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qDbXVdCdHGoSgWSk" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: sam@errno.com, freebsd-current@freebsd.org, caelian@gmail.com Subject: Re: wpa_supplicant segfaults with ath X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2005 17:13:32 -0000 --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 30, 2005 at 06:10:00AM -0700, Hanns Hartman wrote: > That work perfectly thanks. No more errors. I also wanted to know if=20 > there is an easy bit of script I can impliment in order to have the=20 > wpa_supplicant load at boot up. As per rc.conf(5), add WPA to your ifconfig_ entry in /etc/rc.conf. -- Brooks > >From: Sam Leffler > >To: Pascal Hofstee > >CC: freebsd-current@freebsd.org, Hanns Hartman > >Subject: Re: wpa_supplicant segfaults with ath > >Date: Mon, 29 Aug 2005 10:26:58 -0700 > > > >Pascal Hofstee wrote: > >>On Sun, 2005-08-28 at 23:12 -0700, Hanns Hartman wrote: > >> > >>>Hi, > >>> This is my first time posting to the list so if you need more=20 > >>>information let me know. also since I have no internet on my freebsd b= ox=20 > >>>it is difficult to get all of the verbose output. so here goes. > >>> > >>>I am using freebsd6.0beta2 on an amd64. I am using the src tree from= =20 > >>>august 21. > >>> > >>>I am trying to associate with a 2wire gateway that was supplied by sbc= =20 > >>>for my dsl. I have set the gateway up with wpa-psk encription. > >>>I am able to connect perfectly fine to this gateway with my ibm t42 bu= t=20 > >>>when I try to associate with the gateway using wpa_supplicant I get a= =20 > >>>segmentation fault after the program reaches "wpa: sending eapol-key= =20 > >>>4/4" specifially it faults right after displaying "wpa: rsc -=20 > >>>hexdump(len=3D6): 00 00 00 00 00 00" while using option -d for output. > >>> > >>>when running the supplicant in gdb I get program received SIGSEGV,=20 > >>>segmentation fault. 0x000000080082d4d0 in strlen () from /lib/libc.so= .6 > >>> > >>>if there is anything else needed that might help to explain the proble= m=20 > >>>let me know. I appoligize for not having more output to post at this= =20 > >>>time. > >>>thanks for the help > >>>Hanns > >> > >> > >>Thank you for posting this ... as it reminded me i should probably file > >>a bug report on this. I recently tried to do some investigative work of > >>my own hoping to find out why my if_ral interface kept acting up when i > >>bumped into the exact same problem myself. > >> > >>i can tell you why the segfault happens .. though i am not entirely sure > >>how it should be fixed properly. > >> > >>The problem you're experiencing is caused by the ether_ntoa(addr) call > >>in /usr/src/usr.sbin/wpa/wpa_supplicant/driver_freebsd.c:280 > >> > >>ether_ntoa expects a "const struct ether_addr" as it's parameter where > >>in the code the parameter passed is a "const unsigned char*", further > >>more in that same printf statement seq_len and key_len are being > >>displayed using "%d" where this should be "%zu" since these are > >>size_t's. The size_t construct happens a few more times in the code if i > >>recall correctly. > >> > >>The actual crash you're experiencing though is caused by the faulty > >>ether_ntoa argument. > >> > >>If somebody more knowledgable on this particular subject could have a > >>closer look at what was actually intended here that would be > >>appreciated. > >> > > > >A stack trace at the time of the segfault would be useful. The type=20 > >mismatches should not be an issue unless there are alignment problems.= =20 > >Please try the attached change which should correct any alignment issues. > > > > Sam >=20 >=20 > >Index: driver_freebsd.c > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >RCS file: /usr/ncvs/src/usr.sbin/wpa/wpa_supplicant/driver_freebsd.c,v > >retrieving revision 1.7 > >diff -u -r1.7 driver_freebsd.c > >--- driver_freebsd.c 13 Aug 2005 04:23:33 -0000 1.7 > >+++ driver_freebsd.c 29 Aug 2005 17:24:14 -0000 > >@@ -30,6 +30,7 @@ > > > > #include > > #include > >+#include > > > > #include > > #include > >@@ -231,8 +232,11 @@ > > memset(&wk, 0, sizeof(wk)); > > if (addr !=3D NULL && > > bcmp(addr, "\xff\xff\xff\xff\xff\xff", IEEE80211_ADDR_LEN) !=3D 0)= =20 > > { > >+ struct ether_addr ea; > >+ > >+ memcpy(&ea, addr, IEEE80211_ADDR_LEN); > > wpa_printf(MSG_DEBUG, "%s: addr=3D%s keyidx=3D%d", > >- __func__, ether_ntoa(addr), key_idx); > >+ __func__, ether_ntoa(&ea), key_idx); > > memcpy(wk.idk_macaddr, addr, IEEE80211_ADDR_LEN); > > wk.idk_keyix =3D (uint8_t) IEEE80211_KEYIX_NONE; > > } else { > >@@ -250,6 +254,7 @@ > > { > > struct wpa_driver_bsd_data *drv =3D priv; > > struct ieee80211req_key wk; > >+ struct ether_addr ea; > > char *alg_name; > > u_int8_t cipher; > > > >@@ -275,18 +280,19 @@ > > return -1; > > } > > > >+ memcpy(&ea, addr, IEEE80211_ADDR_LEN); > > wpa_printf(MSG_DEBUG, > >- "%s: alg=3D%s addr=3D%s key_idx=3D%d set_tx=3D%d seq_len=3D%d=20 > >key_len=3D%d", > >- __func__, alg_name, ether_ntoa(addr), key_idx, set_tx, > >+ "%s: alg=3D%s addr=3D%s key_idx=3D%d set_tx=3D%d seq_len=3D%zu=20 > >key_len=3D%zu", > >+ __func__, alg_name, ether_ntoa(&ea), key_idx, set_tx, > > seq_len, key_len); > > > > if (seq_len > sizeof(u_int64_t)) { > >- wpa_printf(MSG_DEBUG, "%s: seq_len %d too big", > >+ wpa_printf(MSG_DEBUG, "%s: seq_len %zu too big", > > __func__, seq_len); > > return -2; > > } > > if (key_len > sizeof(wk.ik_keydata)) { > >- wpa_printf(MSG_DEBUG, "%s: key length %d too big", > >+ wpa_printf(MSG_DEBUG, "%s: key length %zu too big", > > __func__, key_len); > > return -3; > > } >=20 >=20 > >_______________________________________________ > >freebsd-current@freebsd.org mailing list > >http://lists.freebsd.org/mailman/listinfo/freebsd-current > >To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g" >=20 >=20 > _______________________________________________ > 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" --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --qDbXVdCdHGoSgWSk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDFJO4XY6L6fI4GtQRAq0IAJ942gLmUnEh3waODCxNV5bH3r6TLwCfXUnP oZpNiEGK2DVsmpeO1fD5q2o= =Edl2 -----END PGP SIGNATURE----- --qDbXVdCdHGoSgWSk-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 17:23:57 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 B969816A41F for ; Tue, 30 Aug 2005 17:23:57 +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 160F743D46 for ; Tue, 30 Aug 2005 17:23:55 +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 j7UHNoba003275 for ; Tue, 30 Aug 2005 18:23:50 +0100 (BST) Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.13.3/8.13.4) with ESMTP id j7UHNoOw032035 for ; Tue, 30 Aug 2005 18:23:50 +0100 (BST) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: (from ga9@localhost) by buffy.york.ac.uk (8.13.3/8.13.4/Submit) id j7UHNnHG032034 for freebsd-current@freebsd.org; Tue, 30 Aug 2005 18:23:49 +0100 (BST) (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: freebsd-current@freebsd.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 30 Aug 2005 18:23:49 +0100 Message-Id: <1125422629.30555.27.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 Subject: 6.0-BETA3 bge0 and vlans X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2005 17:23:58 -0000 Hi, I'm having no success setting vlans up on a bge interface. Can anyone confirm they work? I've got no problems using them on fxp interfaces, so I'm pretty sure it's not user error... Everything looks good: bge0: flags=8843 mtu 1500 options=1a inet6 fe80::209:3dff:fe12:6c06%bge0 prefixlen 64 scopeid 0x1 inet x.y.12.120 netmask 0xfffffe00 broadcast x.y.13.255 ether 00:09:3d:12:6c:06 media: Ethernet autoselect (100baseTX ) status: active [bge1/lo0 snipped] vlan76: flags=8843 mtu 1500 inet x.y.76.59 netmask 0xfffffe00 broadcast x.y.77.255 inet6 fe80::209:3dff:fe12:6c06%vlan0 prefixlen 64 scopeid 0x4 ether 00:09:3d:12:6c:06 media: Ethernet autoselect (100baseTX ) status: active vlan: 76 parent interface: bge0 ... but I can get no packets through the vlan interface (the parent interface works as expected). Can anyone actually confirm that vlans work with bge cards? My card is a BCM5704 (vend=0x14e4, prod=0x1648, rev=0x03) I've also just discovered that ifconfig is sensitive to the order that the options "vlandev" and "vlan" are passed to it. wiggum# ifconfig vlan76 vlandev bge0 vlan 76 ifconfig: must specify both vlan tag and device wiggum# ifconfig vlan76 vlan 76 vlandev bge0 wiggum# This to me seems counter-intuitive. Due to the design of ifconfig this doesn't seem to be easy to change, so maybe it should be documented? Thanks, Gavin From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 18:19: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 4FE8616A421 for ; Tue, 30 Aug 2005 18:19:43 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id B390B44090 for ; Tue, 30 Aug 2005 18:12:40 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.91] ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j7UICTBd076237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Aug 2005 11:12:31 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <4314A32A.9050105@errno.com> Date: Tue, 30 Aug 2005 11:19:22 -0700 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050327) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vitaly References: <430060FB.1000405@tikhvin.info> <4314537C.5050808@tikhvin.info> In-Reply-To: <4314537C.5050808@tikhvin.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: ath bridge panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2005 18:19:43 -0000 Vitaly wrote: > Vitaly ÐÉÛÅÔ: > >> problem on FreeBSD 6.0-BETA1 >> ath0 is bridge with fxp0 >> panic occured when i connect wireless client to my hostap, client - >> FujitsuSiemens PocketLOOX720 with internal 11b adapter >> >> when his connecting i get next messages >> >>> couldn't m_pullup >>> couldn't m_pullup >>> couldn't m_pullup >> >> >> >> and first ping kill my system >> what i need to get more information about this? >> >>> Fatal trap 12: page fault while in kernel mode >>> fault virtual address = 0x10 >>> fault code = supervisor read, page not present >>> instruction pointer = 0x20:0xc06bef70 >>> stack pointer = 0x28:0xd274c85c >>> frame pointer = 0x28:0x0 >>> 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 = 27 (swi1: net) >>> trap number = 12 >>> panic: page fault >>> Uptime: 4m41s >>> Dumping 191 MB (2 chunks) >>> chunk 0: 1MB (159 pages) ... ok >>> chunk 1: 191MB (48893 pages) 176 160 144 128 112 96 80 64 48 32 16 >>> ... ok >> >> >> >> >> >>> net.link.ether.bridge.enable: 0 -> 1 >>> net.link.ether.bfridge.config: xp0: promiscuous mode enabled >>> ath0: promiscuous mode enabled >>> fxp0: link state changed to UP >>> -> fxp0:2,ath0:2 >>> fxp1: link state changed to UP >>> fxp0: >>> flags=18943 >>> mtu 1500 >>> options=48 >>> inet 192.168.7.1 netmask 0xffffff00 broadcast 192.168.7.255 >>> ether 00:04:ac:d7:bd:24 >>> media: Ethernet autoselect (100baseTX ) >>> status: active >>> ath0: flags=8943 mtu >>> 1500 >>> ether 00:0f:3d:a9:4e:20 >>> media: IEEE 802.11 Wireless Ethernet autoselect mode 11g >>> >>> status: associated >>> ssid D2HOME channel 6 bssid 00:0f:3d:a9:4e:20 >>> authmode OPEN privacy ON deftxkey 1 >>> wepkey 1:104-bit >>> txpowmax 39 rtsthreshold 2346 protmode CTS dtimperiod 1 >>> bintval 100 >> >> >> > Problem still exists, what I must do? Still exists with what version of the system? If you haven't tried BETA3 then do that first. To get something like this fixed you need to provide the steps needed to reproduce the problem. Sam From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 18:22: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 472CC16A41F for ; Tue, 30 Aug 2005 18:22:52 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20ADB43FA6 for ; Tue, 30 Aug 2005 18:14:30 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id j7UIJ7FZ085213; Tue, 30 Aug 2005 14:19:07 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Tue, 30 Aug 2005 14:14:10 -0400 User-Agent: KMail/1.6.2 References: <1125422629.30555.27.camel@buffy.york.ac.uk> In-Reply-To: <1125422629.30555.27.camel@buffy.york.ac.uk> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: 7bit Message-Id: <200508301414.15449.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.85.1/1048/Tue Aug 30 03:03:53 2005 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: Subject: Re: 6.0-BETA3 bge0 and vlans X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2005 18:22:52 -0000 On Tuesday 30 August 2005 01:23 pm, Gavin Atkinson wrote: > Hi, > > I'm having no success setting vlans up on a bge interface. Can > anyone confirm they work? I've got no problems using them on fxp > interfaces, so I'm pretty sure it's not user error... Everything > looks good: > > bge0: flags=8843 mtu 1500 > options=1a > inet6 fe80::209:3dff:fe12:6c06%bge0 prefixlen 64 scopeid > 0x1 inet x.y.12.120 netmask 0xfffffe00 broadcast x.y.13.255 ether > 00:09:3d:12:6c:06 > media: Ethernet autoselect (100baseTX ) > status: active > [bge1/lo0 snipped] > vlan76: flags=8843 mtu 1500 > inet x.y.76.59 netmask 0xfffffe00 broadcast x.y.77.255 > inet6 fe80::209:3dff:fe12:6c06%vlan0 prefixlen 64 scopeid > 0x4 ether 00:09:3d:12:6c:06 > media: Ethernet autoselect (100baseTX ) > status: active > vlan: 76 parent interface: bge0 > > ... but I can get no packets through the vlan interface (the parent > interface works as expected). Can anyone actually confirm that > vlans work with bge cards? My card is a BCM5704 (vend=0x14e4, > prod=0x1648, rev=0x03) It was discussed here but I don't think any actions were taken actually. Follow the thread: http://docs.freebsd.org/cgi/mid.cgi?9256D57F598E6C41B288AA7DB94F29C902DFB963 Jung-uk Kim > I've also just discovered that ifconfig is sensitive to the order > that the options "vlandev" and "vlan" are passed to it. > > wiggum# ifconfig vlan76 vlandev bge0 vlan 76 > ifconfig: must specify both vlan tag and device > wiggum# ifconfig vlan76 vlan 76 vlandev bge0 > wiggum# > > This to me seems counter-intuitive. Due to the design of ifconfig > this doesn't seem to be easy to change, so maybe it should be > documented? > > Thanks, > > Gavin > _______________________________________________ > 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 Tue Aug 30 18: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 AA8D216A41F for ; Tue, 30 Aug 2005 18:58:49 +0000 (GMT) (envelope-from dandee@hellteam.net) Received: from pipa.profix.cz (server1.pcsvet.net [82.208.25.157]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA62743D53 for ; Tue, 30 Aug 2005 18:58:48 +0000 (GMT) (envelope-from dandee@hellteam.net) Received: from localhost (localhost [127.0.0.1]) by pipa.profix.cz (Postfix) with ESMTP id 820994E706 for ; Tue, 30 Aug 2005 20:58:52 +0200 (CEST) Received: from pipa.profix.cz ([127.0.0.1]) by localhost (pipa [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02929-08 for ; Tue, 30 Aug 2005 20:58:52 +0200 (CEST) Received: from gandalf (unknown [80.95.121.105]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by pipa.profix.cz (Postfix) with ESMTP id ECF554E704 for ; Tue, 30 Aug 2005 20:58:51 +0200 (CEST) From: =?iso-8859-2?Q?Daniel_Dvo=F8=E1k?= To: Date: Tue, 30 Aug 2005 20:58:44 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcWtlNhqQl/+DJRqTjyFloYUndiwQQ== Message-Id: <20050830185851.ECF554E704@pipa.profix.cz> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at profix.cz Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Application layer firewall on FreeBSD, is it possible ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dandee@volny.cz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2005 18:58:49 -0000 Hi all, =20 let me ask you for task "how to control p2p applications and their = traffic with dynamic ports from user=B4s commputers on gateway". =20 We are small wireless community and have shared access to internet for = all members. Core members decided to control p2p traffic by default and to = allow each person in individual way, after showing their knowledge of authorial low. :) =20 But since many dc hubs, edonkey servers, bittorents web trackers and so = on use dynamic not standard ports, how to control it ? =20 Linux use l7-filter http://sourceforge.net/projects/l7-filter sourceforge = freeware and , it is based on iptables, defination application protocols like ethereal project do. =20 So, is there any way to do same application layer osi model firewall = with FreeBSD gateway ? =20 Of course, I tried to find on web, I have not been successful in = searching so far. =20 If my question is not right in this mailing list, if my question is = annoying here, so I am sorry. =20 Dan From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 19:17:13 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 8EA1D16A423; Tue, 30 Aug 2005 19:17:13 +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 EFE5043D45; Tue, 30 Aug 2005 19:17:12 +0000 (GMT) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from ury.york.ac.uk (ury.york.ac.uk [144.32.108.81]) by mail-gw1.york.ac.uk (8.12.10/8.12.10) with ESMTP id j7UJHACv028006; Tue, 30 Aug 2005 20:17:10 +0100 (BST) Received: from ury.york.ac.uk (localhost.york.ac.uk [127.0.0.1]) by ury.york.ac.uk (8.13.1/8.13.1) with ESMTP id j7UJUOcp057391; Tue, 30 Aug 2005 20:30:24 +0100 (BST) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from localhost (gavin@localhost) by ury.york.ac.uk (8.13.1/8.13.1/Submit) with ESMTP id j7UJUOJv057388; Tue, 30 Aug 2005 20:30:24 +0100 (BST) (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: ury.york.ac.uk: gavin owned process doing -bs Date: Tue, 30 Aug 2005 20:30:24 +0100 (BST) From: Gavin Atkinson X-X-Sender: gavin@ury.york.ac.uk To: Jung-uk Kim In-Reply-To: <200508301414.15449.jkim@FreeBSD.org> Message-ID: <20050830202721.K57336@ury.york.ac.uk> References: <1125422629.30555.27.camel@buffy.york.ac.uk> <200508301414.15449.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin.atkinson@ury.york.ac.uk Cc: freebsd-current@FreeBSD.org Subject: Re: 6.0-BETA3 bge0 and vlans X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2005 19:17:13 -0000 On Tue, 30 Aug 2005, Jung-uk Kim wrote: > On Tuesday 30 August 2005 01:23 pm, Gavin Atkinson wrote: >> Hi, >> >> I'm having no success setting vlans up on a bge interface. Can anyone >> confirm they work? I've got no problems using them on fxp interfaces, >> so I'm pretty sure it's not user error... Everything looks good but I >> can get no packets through the vlan interface (the parent interface >> works as expected). Can anyone actually confirm that vlans work with >> bge cards? My card is a BCM5704 (vend=0x14e4, prod=0x1648, rev=0x03) > > It was discussed here but I don't think any actions were taken > actually. Follow the thread: > > http://docs.freebsd.org/cgi/mid.cgi?9256D57F598E6C41B288AA7DB94F29C902DFB963 Ah yes. After sending that, I did a bit more googling. The patch contained in http://lists.freebsd.org/pipermail/freebsd-net/2005-April/006932.html fixes the problem for me... Gavin From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 19:49: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 E91A616A41F for ; Tue, 30 Aug 2005 19:49:52 +0000 (GMT) (envelope-from noackjr@alumni.rice.edu) Received: from smtp108.sbc.mail.mud.yahoo.com (smtp108.sbc.mail.mud.yahoo.com [68.142.198.207]) by mx1.FreeBSD.org (Postfix) with SMTP id 61CFC43D46 for ; Tue, 30 Aug 2005 19:49:52 +0000 (GMT) (envelope-from noackjr@alumni.rice.edu) Received: (qmail 34498 invoked from network); 30 Aug 2005 19:49:52 -0000 Received: from unknown (HELO optimator.noacks.org) (noacks@swbell.net@70.240.205.153 with login) by smtp108.sbc.mail.mud.yahoo.com with SMTP; 30 Aug 2005 19:49:51 -0000 Received: from localhost (localhost [127.0.0.1]) by optimator.noacks.org (Postfix) with ESMTP id 4AF6F6168; Tue, 30 Aug 2005 14:49:51 -0500 (CDT) Received: from optimator.noacks.org ([127.0.0.1]) by localhost (optimator.noacks.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 32910-15; Tue, 30 Aug 2005 14:49:48 -0500 (CDT) Received: from compgeek.noacks.org (compgeek [192.168.1.10]) by optimator.noacks.org (Postfix) with ESMTP id 79AF360E8; Tue, 30 Aug 2005 14:49:48 -0500 (CDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by compgeek.noacks.org (8.13.4/8.13.4) with ESMTP id j7UJnlGb085729; Tue, 30 Aug 2005 14:49:48 -0500 (CDT) (envelope-from noackjr@alumni.rice.edu) Message-ID: <4314B854.6070302@alumni.rice.edu> Date: Tue, 30 Aug 2005 14:49:40 -0500 From: Jonathan Noack User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050830) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Cracauer References: <20050830130605.A73730@cons.org> In-Reply-To: <20050830130605.A73730@cons.org> X-Enigmail-Version: 0.92.0.0 OpenPGP: id=991D8195; url=http://www.noacks.org/cert/noackjr.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig83EB159CA88F40FB1A81EFC0" X-Virus-Scanned: amavisd-new at noacks.org Cc: freebsd-current@freebsd.org Subject: Re: Recent 6-beta issue: high delay when loading kernel on thinkpad on battery X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: noackjr@alumni.rice.edu List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2005 19:49:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig83EB159CA88F40FB1A81EFC0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 08/30/05 12:06, Martin Cracauer wrote: > I cannot nail down when exactly this issue was introduced but I think > it was recently. I remember to boot this laptop fine when on battery > during summer. > > Recent 6-betas make my thinkpad R40 wait for 80 seconds when loading > the kernel (after announcing kernel version but before probing > devices), when it is on battery power. On A/C the delay is normal. > > This is a boot -v screenshot photo of the stage where it is hanging: > http://wavehh.dyndns.org/tmp/thinkpad-6beta-delay.jpg > > As you can see, -v doesn't give a clue what it is doing. It is > hanging there doing nothing before reloading the kernel modules. > > dmesg, acpi stats, kernel config etc is all on: > http://www.cons.org/cracauer/machines/grisu/ > > I just updated these files to be from a -v boot when on A/C. > > Any idea what this can be caused by? Any additional tests or info I > can provide? I have seen similar boot delays on a Compaq DL360 (G1?) server I have. Also, I have a dual P3 machine that no longer reboots after a "shutdown -r now"; it just hangs after printing "Shutting down ACPI". I think there may be some edge cases with ACPI but have no direct evidence. Here's my message: http://docs.freebsd.org/cgi/mid.cgi?430960DD.6040608 -- Jonathan Noack | noackjr@alumni.rice.edu | OpenPGP: 0x991D8195 --------------enig83EB159CA88F40FB1A81EFC0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDFLhbUFz01pkdgZURArolAJ97FPFOnUN4Oaj9qHEcN9HkvQGsbACgpkmE XLUkC/gfvBs9+f4AhX7CCN8= =I9iT -----END PGP SIGNATURE----- --------------enig83EB159CA88F40FB1A81EFC0-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 19:50: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 70EB316A41F for ; Tue, 30 Aug 2005 19:50:52 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id A939843D4C for ; Tue, 30 Aug 2005 19:50:51 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (Xserve/8.12.11/smtpout13/MantshX 4.0) with ESMTP id j7UJooTV025137; Tue, 30 Aug 2005 12:50:51 -0700 (PDT) Received: from [10.1.1.209] (nfw2.codefab.com [199.103.21.225] (may be forged)) (authenticated bits=0) by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id j7UJom6i022379; Tue, 30 Aug 2005 12:50:49 -0700 (PDT) In-Reply-To: <20050830185851.ECF554E704@pipa.profix.cz> References: <20050830185851.ECF554E704@pipa.profix.cz> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed Message-Id: <8DC722F7-1946-4CE3-B4B9-A6F8624CE9A3@mac.com> Content-Transfer-Encoding: quoted-printable From: Charles Swiger Date: Tue, 30 Aug 2005 15:50:47 -0400 To: dandee@volny.cz X-Mailer: Apple Mail (2.734) Cc: freebsd-current@freebsd.org Subject: Re: Application layer firewall on FreeBSD, is it possible ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2005 19:50:52 -0000 On Aug 30, 2005, at 2:58 PM, Daniel Dvo=C5=99=C3=A1k wrote: > let me ask you for task "how to control p2p applications and their =20 > traffic > with dynamic ports from user=C2=B4s commputers on gateway". > > We are small wireless community and have shared access to internet =20 > for all > members. Core members decided to control p2p traffic by default and =20= > to allow > each person in individual way, after showing their knowledge of =20 > authorial low. :) > > But since many dc hubs, edonkey servers, bittorents web trackers =20 > and so on > use dynamic not standard ports, how to control it ? Start with a "deny all" policy, and use L7 proxies like squid for the =20= specific protocols like HTTP which you want to permit. If you're =20 really serious about controlling the traffic, don't let your router =20 talk to anything but your proxy server in order to be certain that =20 the client machines have to go through that. --=20 -Chuck From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 20:08: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 4CD0416A41F; Tue, 30 Aug 2005 20:08:41 +0000 (GMT) (envelope-from bushman@rsu.ru) Received: from mail.r61.net (mail.r61.net [195.208.245.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9307543D48; Tue, 30 Aug 2005 20:08:40 +0000 (GMT) (envelope-from bushman@rsu.ru) Received: from stinger.cc.rsu.ru (stinger.cc.rsu.ru [195.208.252.82]) by mail.r61.net (8.13.4/8.13.4) with ESMTP id j7UK8VlX021201; Wed, 31 Aug 2005 00:08:31 +0400 (MSD) (envelope-from bushman@rsu.ru) Date: Wed, 31 Aug 2005 00:12:37 +0400 (MSD) From: Michael Bushkov X-X-Sender: bushman@stinger.cc.rsu.ru To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Message-ID: <20050830232904.V72814@stinger.cc.rsu.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.86.2, clamav-milter version 0.86 on asterix.r61.net X-Virus-Status: Clean X-Spam-Status: No, score=-5.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on asterix.r61.net Cc: Jacques Vidrine , Brooks Davis Subject: [PATCH] nsswitch and cached release 2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2005 20:08:41 -0000 Hello! Here is the second (corrected) release of my Google SoC project (the project's aim is to implement the caching daemon and to extend the nsswitch subsystem). You can download the patch from here: http://www.rsu.ru/~bushman/nsswitch_cached.diff (the patch is absolute, use: patch -p0 < nsswitch_cached.diff) This patch includes everything that was in the previous release: - services, rpc and proto nsswitch databases implemented - passwd, group, services, rpc and proto caching implemented - caching daemon implemented The new things are: - caching for "hosts" nsswitch database is implemented - some bugs in cached were fixed. cache is now per-user (user can only use data, that he has cached by himself. he can't poison the cache of the other user) - all sources now meet the style(9) guidelines much more than they had before - and some other minor fixes Please, test the stuff if you can and send me your bug-reports :) With best regards, Michael Bushkov Rostov State University From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 20:33:23 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 F051D16A41F; Tue, 30 Aug 2005 20:33:23 +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 DC18C43D46; Tue, 30 Aug 2005 20:33:20 +0000 (GMT) (envelope-from saturnero@freesbie.org) Received: from [192.168.10.2] (host235-73.pool8256.interbusiness.it [82.56.73.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jail1-fbsd4.consiagnet.it (Postfix) with ESMTP id 0BF095836; Tue, 30 Aug 2005 22:34:49 +0200 (CEST) Message-ID: <4314C299.3030003@freesbie.org> Date: Tue, 30 Aug 2005 22:33:29 +0200 From: Dario Freni User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050828) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hackers@freebsd.org, current@freebsd.org, freesbie@gufi.org, esperti@gufi.org X-Enigmail-Version: 0.92.0.0 OpenPGP: url=http://www.saturnero.net/saturnero.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig74C4A2F9C77E3C2A12E3D155" Cc: Subject: FreeSBIE 2 toolkit, developers' preview X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2005 20:33:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig74C4A2F9C77E3C2A12E3D155 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi guys, I've put a snapshot of the now toolkit I've been working for the Google Summer of Code here: http://cvs.freesbie.org/~saturnero/freesbie2.tar.gz If you have a FreeBSD version > 6.x, on i386, amd64 and powerpc, you can give it a test and send feedbacks to me. As usual, comments and suggestions are greatly appreciated. Many thanks to Google for this wonderful opportunity, as well as FreeBSD release engeering members (particularly Murray Stokely) for mentoring, Peter Grehan and many FreeBSD developers for being so nice and responsive. Bye everybody, Dario -- Dario Freni (saturnero@freesbie.org) FreeSBIE developer (http://www.freesbie.org) GPG Public key at http://www.saturnero.net/saturnero.asc --------------enig74C4A2F9C77E3C2A12E3D155 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDFMKZymi72IiShysRAtRQAKDZJMfGW/rk5XZHzV9X8i94UQHsBACfQaU5 yE1iWheQ8g9GnBzpiaVvNzc= =c42A -----END PGP SIGNATURE----- --------------enig74C4A2F9C77E3C2A12E3D155-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 21:22:39 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 7908F16A41F for ; Tue, 30 Aug 2005 21:22:39 +0000 (GMT) (envelope-from bryce@bryce.net) Received: from bryce.net (c-67-187-50-70.hsd1.tx.comcast.net [67.187.50.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id E34A143D45 for ; Tue, 30 Aug 2005 21:22:38 +0000 (GMT) (envelope-from bryce@bryce.net) Received: from bryce by bryce.net (MDaemon.PRO.v8.1.1.R) with ESMTP id md50000004408.msg for ; Tue, 30 Aug 2005 16:22:37 -0500 Message-ID: <004b01c5ada8$ef5e68e0$e201a8c0@home.bryce.net> From: "Bryce Edwards" To: Date: Tue, 30 Aug 2005 16:22:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Authenticated-Sender: bryce@bryce.net X-Spam-Processed: mail.bryce.net, Tue, 30 Aug 2005 16:22:37 -0500 (not processed: message from valid local sender) X-Return-Path: bryce@bryce.net X-MDaemon-Deliver-To: freebsd-current@freebsd.org X-MDAV-Processed: mail.bryce.net, Tue, 30 Aug 2005 16:22:38 -0500 Subject: ndis/wpa_supplicant error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2005 21:22:39 -0000 Hi, I'm running 6.0-BETA3 and am having a problem with wpa_supplicant and the kernel error points to ndis0. Here's the wpa_supplicant debug output: Initializing interface 'ndis0' conf '/etc/wpa_supplicant.conf' driver 'default' Configuration file '/etc/wpa_supplicant.conf' -> '/etc/wpa_supplicant.conf' Reading configuration file '/etc/wpa_supplicant.conf' Line: 7 - start of a new network block ssid - hexdump_ascii(len=5): 42 52 59 43 45 BRYCE key_mgmt: 0x2 PSK (ASCII passphrase) - hexdump_ascii(len=8): [REMOVED] PSK (from passphrase) - hexdump(len=32): [REMOVED] Priority group 0 id=0 ssid='BRYCE' Initializing interface (2) 'ndis0' Own MAC address: 00:90:4b:13:8f:83 wpa_driver_bsd_set_wpa: enabled=1 wpa_driver_bsd_del_key: keyidx=0 wpa_driver_bsd_del_key: keyidx=1 wpa_driver_bsd_del_key: keyidx=2 wpa_driver_bsd_del_key: keyidx=3 wpa_driver_bsd_set_countermeasures: enabled=0 wpa_driver_bsd_set_drop_unencrypted: enabled=1 Setting scan request: 0 sec 100000 usec Starting AP scan (broadcast SSID) Received 0 bytes of scan results (1 BSSes) Scan results: 1 Selecting BSS from priority group 0 0: 00:13:10:27:2c:7a ssid='BRYCE' wpa_ie_len=24 rsn_ie_len=0 selected Trying to associate with 00:13:10:27:2c:7a (SSID='BRYCE' freq=2437 MHz) Cancelling scan request Automatic auth_alg selection: 0x1 WPA: using IEEE 802.11i/D3.0 WPA: Selected cipher suites: group 16 pairwise 16 key_mgmt 2 WPA: using GTK CCMP WPA: using PTK CCMP WPA: using KEY_MGMT WPA-PSK WPA: Own WPA IE - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 f2 04 01 00 00 50 f2 04 01 00 00 50 f2 02 No keys have been configured - skip key clearing wpa_driver_bsd_set_drop_unencrypted: enabled=1 wpa_driver_bsd_associate: ssid 'BRYCE' wpa ie len 24 pairwise 3 group 3 key mgmt 1 wpa_driver_bsd_associate: set PRIVACY 1 Then I get the following console/dmesg error: ndis0: setting wep privacy filter failed Please help me understand what it is trying to do and how to fix it. Here's my NDIS module info: 4 2 0xc0aa8000 b7cc if_ndis.ko 5 3 0xc0ab4000 165c0 ndis.ko 6 1 0xc0acb000 92a8c bcmwl5_sys.ko The adapter is: ndis0: mem 0xe0210000-0xe0211fff irq 5 at device 4.0 on pci2 ndis0: NDIS API version: 5.1 TIA, ::Bryce:: From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 23:25: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 AF85216A423 for ; Tue, 30 Aug 2005 23:25:06 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from smtp102.rog.mail.re2.yahoo.com (smtp102.rog.mail.re2.yahoo.com [206.190.36.80]) by mx1.FreeBSD.org (Postfix) with SMTP id 204F043D46 for ; Tue, 30 Aug 2005 23:25:05 +0000 (GMT) (envelope-from mikej@rogers.com) Received: (qmail 89225 invoked from network); 30 Aug 2005 23:25:05 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:Message-ID:Date:Subject:From:To:User-Agent:MIME-Version:Content-Type:Content-Transfer-Encoding; b=qeATxNN1tDorPfy+Ni3Emp4jVTZyLIw5FJ9/5RCnOLCqLqFUNqKP44nEwhC2rdUR5G6oD69qC60Tma8b01rsvyL/IQc4/zwAZCPqbrWFktO3mH+tCsc2KJu/Q44BV4pGY/DWRIsDmFkJiM7kmvZPkIpQQRb9IvyxjjE0pNKaovw= ; Received: from unknown (HELO 172.16.0.1) (mikej@70.31.50.81 with login) by smtp102.rog.mail.re2.yahoo.com with SMTP; 30 Aug 2005 23:25:05 -0000 Received: from 172.16.0.199 (SquirrelMail authenticated user mikej) by 172.16.0.1 with HTTP; Tue, 30 Aug 2005 19:25:07 -0400 (EDT) Message-ID: <4740.172.16.0.199.1125444307.squirrel@172.16.0.1> Date: Tue, 30 Aug 2005 19:25:07 -0400 (EDT) From: "Mike Jakubik" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.5.1 [CVS] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: More "make release" problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2005 23:25:06 -0000 ===> share/info (all) ===> include (all) ===> include/arpa (all) ===> include/protocols (all) ===> include/rpcsvc (all) ===> include/rpc (all) ===> lib (all) ===> lib/csu/i386-elf (all) ===> lib/libcom_err (all) cc -pg -O2 -fno-strict-aliasing -pipe -I/usr/src/lib/libcom_err/../../contrib/com_err -c /usr/src/lib/libcom_err/../../contrib/com_err/com_err.c -o com_err.po cc -pg -O2 -fno-strict-aliasing -pipe -I/usr/src/lib/libcom_err/../../contrib/com_err -c /usr/src/lib/libcom_err/../../contrib/com_err/error.c -o error.po building profiled com_err library ranlib libcom_err_p.a gzip -cn /usr/src/lib/libcom_err/../../contrib/com_err/com_err.3 > com_err.3.gz groff -Tascii -mtty-char -man -t /usr/src/lib/libcom_err/../../contrib/com_err/com_err.3 | gzip -cn > com_err.3.cat.gz ===> lib/libcom_err/doc (all) makeinfo --no-split -I /usr/src/lib/libcom_err/doc -I /usr/src/lib/libcom_err/doc /usr/src/lib/libcom_err/doc/com_err.texinfo -o com_err.info makeinfo:No such file or directory *** Error code 1 Stop in /usr/src/lib/libcom_err/doc. *** Error code 1 -- Can anyone get this stupid process to work? This is the second problem i've encountered trying to make a fsking install iso.. From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 23:28:21 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 9A67A16A41F for ; Tue, 30 Aug 2005 23:28:21 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fileserver.fields.utoronto.ca (fileserver.fields.utoronto.ca [128.100.216.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A83D43D45 for ; Tue, 30 Aug 2005 23:28:21 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fields.fields.utoronto.ca (fields.localdomain [192.168.216.11]) by fileserver.fields.utoronto.ca (8.12.8/8.12.8/Fields 6.0) with ESMTP id j7UNSKvf004849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Aug 2005 19:28:20 -0400 Received: from obsecurity.dyndns.org (localhost.localdomain [127.0.0.1]) by fields.fields.utoronto.ca (8.12.8/8.12.8/Fields WS 6.0) with ESMTP id j7UNSJ6P020763; Tue, 30 Aug 2005 19:28:19 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id D63CF51262; Tue, 30 Aug 2005 19:28:18 -0400 (EDT) Date: Tue, 30 Aug 2005 19:28:18 -0400 From: Kris Kennaway To: Jeremie Le Hen Message-ID: <20050830232818.GA83944@xor.obsecurity.org> References: <20050830124435.GW659@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SUOF0GtieIMvvwua" Content-Disposition: inline In-Reply-To: <20050830124435.GW659@obiwan.tataz.chchile.org> User-Agent: Mutt/1.4.2.1i Cc: Matthias Andree , freebsd-current@freebsd.org Subject: Re: nfs through nullfs (was: 6.0-BETA3: ext2fs through nullfs: panic "locking against myself") X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2005 23:28:21 -0000 --SUOF0GtieIMvvwua Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 30, 2005 at 02:44:35PM +0200, Jeremie Le Hen wrote: > > Subject says it all. > >=20 > > mount a ext2 file system, use it as basis for a nullfs mount -> panic. >=20 > Mount a NFS filesystem, use it as basis for nullfs mount -> panic. Please provide details. Kris --SUOF0GtieIMvvwua Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDFOuSWry0BWjoQKURAgClAKDM/SCNq/FsBqiLzKhmezn1pvXpDACeP3PD Suphz7RzMpEO4ZNUculJYbg= =lX6/ -----END PGP SIGNATURE----- --SUOF0GtieIMvvwua-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 00:14:58 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 CBC2D16A41F for ; Wed, 31 Aug 2005 00:14:58 +0000 (GMT) (envelope-from dandee@hellteam.net) Received: from pipa.profix.cz (server1.pcsvet.net [82.208.25.157]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C30543D45 for ; Wed, 31 Aug 2005 00:14:58 +0000 (GMT) (envelope-from dandee@hellteam.net) Received: from localhost (localhost [127.0.0.1]) by pipa.profix.cz (Postfix) with ESMTP id F3C2E4E706; Wed, 31 Aug 2005 02:15:04 +0200 (CEST) Received: from pipa.profix.cz ([127.0.0.1]) by localhost (pipa [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22951-05; Wed, 31 Aug 2005 02:15:04 +0200 (CEST) Received: from gandalf (unknown [80.95.121.105]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by pipa.profix.cz (Postfix) with ESMTP id B6E984E704; Wed, 31 Aug 2005 02:15:04 +0200 (CEST) From: =?iso-8859-2?Q?Daniel_Dvo=F8=E1k?= To: "'Charles Swiger'" , Date: Wed, 31 Aug 2005 02:14:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <8DC722F7-1946-4CE3-B4B9-A6F8624CE9A3@mac.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcWtnCsgVOYOP21DQTaIhujIuXWA5AAIZ/yQ Message-Id: <20050831001504.B6E984E704@pipa.profix.cz> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at profix.cz Cc: freebsd-current@freebsd.org Subject: RE: Application layer firewall on FreeBSD, is it possible ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dandee@volny.cz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2005 00:14:59 -0000 Okay, thank you for advise. Maybe I did not understand fully but ... ... but you know, proxy is not what I am asking, proxy is not firewall. We do not need to restrict everything and all members. We like full routeable network with full access to IPv6 / IPv4 internet without any necessary action like configure proxy clients at all pc=B4s = our members. We only want to deny only p2p applications by default for all pc=B4s regardless of used protocol/ports and to allow grantting access to p2p networks each members in individual way, because we have to prevent = another letter from our ISP which was contacted by BSA that from our public IP ( from one member in private ip space ) ... traffic ... share ... violate = ... authorial law.=20 So of course it must be combination of IP and application osi model firewall. Gateway server should check all packets and their contents to decide if allowed or denied in fast way like l7-filter on Linux OS. So is it possible on FreeBSD OS ? Thanks Since my question here is not right like somebody told me, this is last e-mail in this mailling list for this theme, and I send it to freebsd-question, freebsd-ipfw and freebsd-pf mailling lists. Dan -----Original Message----- From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd-current@freebsd.org] On Behalf Of Charles Swiger Sent: Tuesday, August 30, 2005 9:51 PM To: dandee@volny.cz Cc: freebsd-current@freebsd.org Subject: Re: Application layer firewall on FreeBSD, is it possible ? On Aug 30, 2005, at 2:58 PM, Daniel Dvo=F8=E1k wrote: > let me ask you for task "how to control p2p applications and their=20 > traffic with dynamic ports from user=B4s commputers on gateway". > > We are small wireless community and have shared access to internet for = > all members. Core members decided to control p2p traffic by default=20 > and to allow each person in individual way, after showing their=20 > knowledge of authorial low. :) > > But since many dc hubs, edonkey servers, bittorents web trackers and=20 > so on use dynamic not standard ports, how to control it ? Start with a "deny all" policy, and use L7 proxies like squid for the specific protocols like HTTP which you want to permit. If you're really serious about controlling the traffic, don't let your router talk to anything but your proxy server in order to be certain that the client machines have to go through that. -- -Chuck _______________________________________________ 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 Aug 31 00:16: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 04A8616A41F for ; Wed, 31 Aug 2005 00:16:59 +0000 (GMT) (envelope-from akbeech@gmail.com) Received: from vfemail.net (miwi2dsl-a234.wi.tds.net [216.170.248.235]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B45E43D45 for ; Wed, 31 Aug 2005 00:16:57 +0000 (GMT) (envelope-from akbeech@gmail.com) Received: (qmail 66313 invoked by uid 85); 31 Aug 2005 00:16:53 -0000 Received: from akbeech@gmail.com by mail.vfemail.net by uid 0 with qmail-scanner-1.16 (clamscan: 0.75.1. spamassassin: 2.63. Clear:. Processed in 1.496618 secs); 31 Aug 2005 00:16:53 -0000 Received: from unknown (HELO ?192.168.2.200?) (alaska@vfemail.net@209.124.141.64) by miwi2dsl-a234.wi.tds.net with SMTP; 31 Aug 2005 00:16:52 -0000 From: Beecher Rintoul Organization: NorthWind Communications To: freebsd-current@freebsd.org Date: Tue, 30 Aug 2005 16:16:48 -0800 User-Agent: KMail/1.8.2 References: <4740.172.16.0.199.1125444307.squirrel@172.16.0.1> In-Reply-To: <4740.172.16.0.199.1125444307.squirrel@172.16.0.1> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508301616.50131.akbeech@gmail.com> Cc: Mike Jakubik Subject: Re: More "make release" problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 00:16:59 -0000 On Tuesday 30 August 2005 03:25 pm, Mike Jakubik wrote: > ===> share/info (all) > ===> include (all) > ===> include/arpa (all) > ===> include/protocols (all) > ===> include/rpcsvc (all) > ===> include/rpc (all) > ===> lib (all) > ===> lib/csu/i386-elf (all) > ===> lib/libcom_err (all) > cc -pg -O2 -fno-strict-aliasing -pipe > -I/usr/src/lib/libcom_err/../../contrib/com_err -c > /usr/src/lib/libcom_err/../../contrib/com_err/com_err.c -o com_err.po > cc -pg -O2 -fno-strict-aliasing -pipe > -I/usr/src/lib/libcom_err/../../contrib/com_err -c > /usr/src/lib/libcom_err/../../contrib/com_err/error.c -o error.po > building profiled com_err library > ranlib libcom_err_p.a > gzip -cn /usr/src/lib/libcom_err/../../contrib/com_err/com_err.3 > > com_err.3.gz > groff -Tascii -mtty-char -man -t > /usr/src/lib/libcom_err/../../contrib/com_err/com_err.3 | gzip -cn > > com_err.3.cat.gz > ===> lib/libcom_err/doc (all) > makeinfo --no-split -I /usr/src/lib/libcom_err/doc -I > /usr/src/lib/libcom_err/doc /usr/src/lib/libcom_err/doc/com_err.texinfo > -o com_err.info > makeinfo:No such file or directory > *** Error code 1 > > Stop in /usr/src/lib/libcom_err/doc. > *** Error code 1 > > > -- > > Can anyone get this stupid process to work? This is the second problem > i've encountered trying to make a fsking install iso.. I have the exact same problem trying to make install disks. So far I haven't gotten any responses to my post. I could file a PR on this but I was hoping somebody would shed some light on the problem first. Beech --------------------------------------------------------------------------------------- Beech Rintoul - System Administrator - akbeech@gmail.com /"\ ASCII Ribbon Campaign | NorthWind Communications \ / - NO HTML/RTF in e-mail | 201 East 9th Avenue Ste.310 X - NO Word docs in e-mail | Anchorage, AK 99501 / \ --------------------------------------------------------------------------------------- From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 00:44:14 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 BCFFD16A41F for ; Wed, 31 Aug 2005 00:44:14 +0000 (GMT) (envelope-from jd@ugcs.caltech.edu) Received: from riyal.ugcs.caltech.edu (riyal.ugcs.caltech.edu [131.215.176.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72CE443D45 for ; Wed, 31 Aug 2005 00:44:14 +0000 (GMT) (envelope-from jd@ugcs.caltech.edu) Received: by riyal.ugcs.caltech.edu (Postfix, from userid 3640) id 573EE45804; Tue, 30 Aug 2005 17:44:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by riyal.ugcs.caltech.edu (Postfix) with ESMTP id D3AEA45802; Tue, 30 Aug 2005 17:44:12 -0700 (PDT) Date: Tue, 30 Aug 2005 17:44:12 -0700 (PDT) From: Jon Dama To: dandee@volny.cz In-Reply-To: <20050831001504.B6E984E704@pipa.profix.cz> Message-ID: References: <20050831001504.B6E984E704@pipa.profix.cz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-2 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: freebsd-current@freebsd.org Subject: RE: Application layer firewall on FreeBSD, is it possible ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 00:44:14 -0000 I do not think this is possible with an existing "shrink-wrapped" solution. Though, one would expect that it would be a relatively trivial matter to make a userland application from the linux application filter and then use the tun/tap(4) driver. -Jon On Wed, 31 Aug 2005, [iso-8859-2] Daniel Dvo=F8=E1k wrote: > Okay, thank you for advise. Maybe I did not understand fully but ... > > ... but you know, proxy is not what I am asking, proxy is not firewall. > > We do not need to restrict everything and all members. > > We like full routeable network with full access to IPv6 / IPv4 internet > without any necessary action like configure proxy clients at all pc=B4s o= ur > members. > > We only want to deny only p2p applications by default for all pc=B4s > regardless of used protocol/ports and to allow grantting access to p2p > networks each members in individual way, because we have to prevent anoth= er > letter from our ISP which was contacted by BSA that from our public IP ( > from one member in private ip space ) ... traffic ... share ... violate .= =2E. > authorial law. > > So of course it must be combination of IP and application osi model > firewall. > > Gateway server should check all packets and their contents to decide if > allowed or denied in fast way like l7-filter on Linux OS. > > So is it possible on FreeBSD OS ? > > Thanks > > Since my question here is not right like somebody told me, this is last > e-mail in this mailling list for this theme, and I send it to > freebsd-question, freebsd-ipfw and freebsd-pf mailling lists. > > Dan > > -----Original Message----- > From: owner-freebsd-current@freebsd.org > [mailto:owner-freebsd-current@freebsd.org] On Behalf Of Charles Swiger > Sent: Tuesday, August 30, 2005 9:51 PM > To: dandee@volny.cz > Cc: freebsd-current@freebsd.org > Subject: Re: Application layer firewall on FreeBSD, is it possible ? > > On Aug 30, 2005, at 2:58 PM, Daniel Dvo=F8=E1k wrote: > > let me ask you for task "how to control p2p applications and their > > traffic with dynamic ports from user=B4s commputers on gateway". > > > > We are small wireless community and have shared access to internet for > > all members. Core members decided to control p2p traffic by default > > and to allow each person in individual way, after showing their > > knowledge of authorial low. :) > > > > But since many dc hubs, edonkey servers, bittorents web trackers and > > so on use dynamic not standard ports, how to control it ? > > Start with a "deny all" policy, and use L7 proxies like squid for the > specific protocols like HTTP which you want to permit. If you're really > serious about controlling the traffic, don't let your router talk to > anything but your proxy server in order to be certain that the client > machines have to go through that. > > -- > -Chuck > > _______________________________________________ > 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= " > > _______________________________________________ > 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 Aug 31 01:16:13 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 BE7E016A41F; Wed, 31 Aug 2005 01:16:13 +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 2CAEF43D49; Wed, 31 Aug 2005 01:16:12 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.31]) (authenticated bits=0) by cain.gsoft.com.au (8.13.4/8.13.4) with ESMTP id j7V1G0gi090857 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 31 Aug 2005 10:46:06 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Don Lewis Date: Wed, 31 Aug 2005 10:45:49 +0930 User-Agent: KMail/1.8.1 References: <200508300250.j7U2oRhe014021@gw.catspoiler.org> <200508301750.31495.doconnor@gsoft.com.au> In-Reply-To: <200508301750.31495.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1178409.EUTh5oDTXH"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200508311045.56657.doconnor@gsoft.com.au> X-Spam-Score: -2.82 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.51 on 203.31.81.10 Cc: freebsd-current@freebsd.org, kabaev@gmail.com Subject: Re: Odd performance problem (hitching) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 01:16:13 -0000 --nextPart1178409.EUTh5oDTXH Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 30 August 2005 17:50, Daniel O'Connor wrote: > > You might try significantly decreasing MAXVNODES_MAX in > > sys/kern/vfs_subr.c and rebuilding your kernel. > > OK.. > I'll try timing when the drop outs happen :) Hmm they appear to be every 10 seconds on the dot. I haven't changed any syncer delay stuff either.. kern.filedelay: 30 kern.dirdelay: 29 kern.metadelay: 28 Still using SCHED_4BSD too. =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 --nextPart1178409.EUTh5oDTXH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBDFQTM5ZPcIHs/zowRAsGMAKCNTHlk+X8u0Nq/MO/qhvRm3/Xt4gCgh4iq Ga6JjDyxgK39071+8cxEpT4= =rfK5 -----END PGP SIGNATURE----- --nextPart1178409.EUTh5oDTXH-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 01: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 72B1C16A41F for ; Wed, 31 Aug 2005 01:37:11 +0000 (GMT) (envelope-from captinsmock@columbus.rr.com) Received: from ms-smtp-02-eri0.ohiordc.rr.com (ms-smtp-02-smtplb.ohiordc.rr.com [65.24.5.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id E20D043D46 for ; Wed, 31 Aug 2005 01:37:10 +0000 (GMT) (envelope-from captinsmock@columbus.rr.com) Received: from cpe-65-24-34-161.columbus.res.rr.com (cpe-65-24-34-161.columbus.res.rr.com [65.24.34.161]) by ms-smtp-02-eri0.ohiordc.rr.com (8.12.10/8.12.7) with ESMTP id j7V1b8XV019669 for ; Tue, 30 Aug 2005 21:37:08 -0400 (EDT) From: Kyle Brooks To: freebsd-current@freebsd.org Content-Type: text/plain Date: Wed, 31 Aug 2005 01:37:08 +0000 Message-Id: <1125452228.740.3.camel@arbitor.homelinux.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Subject: panic after removing usb flash drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 01:37:11 -0000 umass0: LEXAR MEDIA JUMPDRIVE2, rev 2.00/1.25, addr 2 umass0: at uhub4 port 6 (addr 2) disconnected panic: vm_fault: fault on nofault entry, addr: deadc000 kernel: FreeBSD 7.0-CURRENT #2: Mon Aug 29 00:39:21 UTC 2005 problem: kernel panics when usb flash drive is removed backtrace: #0 doadump () at pcpu.h:165 #1 0xc068610e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:397 #2 0xc0685b92 in panic ( fmt=0xc090e46c "vm_fault: fault on nofault entry, addr: %lx") at /usr/src/sys/kern/kern_shutdown.c:553 #3 0xc0812de1 in vm_fault (map=0xc1060000, vaddr=3735928832, fault_type=2 '\002', fault_flags=0) at /usr/src/sys/vm/vm_fault.c:884 #4 0xc0888807 in trap_pfault (frame=0xe6a06bf0, usermode=0, eva=3735929110) at /usr/src/sys/i386/i386/trap.c:741 #5 0xc0888d04 in trap (frame= {tf_fs = 8, tf_es = -1063649240, tf_ds = 40, tf_edi = -993875968, tf_esi = -1014223872, tf_ebp = -425694000, tf_isp = -425694180, tf_ebx = -1063640044, tf_edx = -993875900, tf_ecx = 0, tf_eax = -559038242, tf_trapno = 12, tf_err = 2, tf_eip = -1069194040, tf_cs = 32, tf_eflags = 66050, tf_esp = -1063640032, tf_ss = 0}) at /usr/src/sys/i386/i386/trap.c:442 #6 0xc08745ba in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0x00000008 in ?? () #8 0xc09a0028 in atdma_acpi_driver_mod () #9 0x00000028 in ?? () #10 0xc4c2a800 in ?? () #11 0xc38c2c00 in ?? () #12 0xe6a06cd0 in ?? () #13 0xe6a06c1c in ?? () ---Type to continue, or q to quit--- #14 0xc09a2414 in xsoftc () #15 0xc4c2a844 in ?? () #16 0x00000000 in ?? () #17 0xdeadc0de in ?? () #18 0x0000000c in ?? () #19 0x00000002 in ?? () #20 0xc04564c8 in camisr (V_queue=0xc09a2414) at /usr/src/sys/cam/cam_xpt.c:7066 #21 0xc066f84e in ithread_loop (arg=0xc356fa80) at /usr/src/sys/kern/kern_intr.c:545 #22 0xc066e808 in fork_exit (callout=0xc066f665 , arg=0x0, frame=0x0) at /usr/src/sys/kern/kern_fork.c:789 #23 0xc087461c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:208 From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 01:53: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 5345116A41F for ; Wed, 31 Aug 2005 01:53:24 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id D2F2143D46 for ; Wed, 31 Aug 2005 01:53:23 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from [192.168.1.254] (really [70.32.199.60]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with ESMTP id <20050831015321.DZLW12165.mta10.adelphia.net@[192.168.1.254]>; Tue, 30 Aug 2005 21:53:21 -0400 Message-ID: <43150D94.8050502@savvis.net> Date: Tue, 30 Aug 2005 18:53:24 -0700 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jon Dama References: <20050831001504.B6E984E704@pipa.profix.cz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org, dandee@volny.cz Subject: Re: Application layer firewall on FreeBSD, is it possible ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 01:53:24 -0000 Jon Dama wrote: > I do not think this is possible with an existing "shrink-wrapped" > solution. yes, it is. take a look at netgraph(4). for example with ethernet interfaces you can connect userspace and/or application kernel module to "lower" and "upper" ng_ether(4) hooks and effectively look at every packet that goes in/out on the wire. max > > Though, one would expect that it would be a relatively trivial matter to > make a userland application from the linux application filter and then use > the tun/tap(4) driver. > > -Jon > > On Wed, 31 Aug 2005, [iso-8859-2] Daniel Dvoøák wrote: > > >>Okay, thank you for advise. Maybe I did not understand fully but ... >> >>... but you know, proxy is not what I am asking, proxy is not firewall. >> >>We do not need to restrict everything and all members. >> >>We like full routeable network with full access to IPv6 / IPv4 internet >>without any necessary action like configure proxy clients at all pc´s our >>members. >> >>We only want to deny only p2p applications by default for all pc´s >>regardless of used protocol/ports and to allow grantting access to p2p >>networks each members in individual way, because we have to prevent another >>letter from our ISP which was contacted by BSA that from our public IP ( >>from one member in private ip space ) ... traffic ... share ... violate ... >>authorial law. >> >>So of course it must be combination of IP and application osi model >>firewall. >> >>Gateway server should check all packets and their contents to decide if >>allowed or denied in fast way like l7-filter on Linux OS. >> >>So is it possible on FreeBSD OS ? >> >>Thanks >> >>Since my question here is not right like somebody told me, this is last >>e-mail in this mailling list for this theme, and I send it to >>freebsd-question, freebsd-ipfw and freebsd-pf mailling lists. >> >>Dan >> >>-----Original Message----- >>From: owner-freebsd-current@freebsd.org >>[mailto:owner-freebsd-current@freebsd.org] On Behalf Of Charles Swiger >>Sent: Tuesday, August 30, 2005 9:51 PM >>To: dandee@volny.cz >>Cc: freebsd-current@freebsd.org >>Subject: Re: Application layer firewall on FreeBSD, is it possible ? >> >>On Aug 30, 2005, at 2:58 PM, Daniel Dvoøák wrote: >> >>>let me ask you for task "how to control p2p applications and their >>>traffic with dynamic ports from user´s commputers on gateway". >>> >>>We are small wireless community and have shared access to internet for >>>all members. Core members decided to control p2p traffic by default >>>and to allow each person in individual way, after showing their >>>knowledge of authorial low. :) >>> >>>But since many dc hubs, edonkey servers, bittorents web trackers and >>>so on use dynamic not standard ports, how to control it ? >> >>Start with a "deny all" policy, and use L7 proxies like squid for the >>specific protocols like HTTP which you want to permit. If you're really >>serious about controlling the traffic, don't let your router talk to >>anything but your proxy server in order to be certain that the client >>machines have to go through that. >> >>-- >>-Chuck >> >>_______________________________________________ >>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" >> >>_______________________________________________ >>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" >> > > _______________________________________________ > 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 Aug 31 01:55:14 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 C2FE116A41F for ; Wed, 31 Aug 2005 01:55:14 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7AC8143D46 for ; Wed, 31 Aug 2005 01:55:14 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id j7V1t57O016802; Tue, 30 Aug 2005 18:55:09 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200508310155.j7V1t57O016802@gw.catspoiler.org> Date: Tue, 30 Aug 2005 18:55:05 -0700 (PDT) From: Don Lewis To: doconnor@gsoft.com.au In-Reply-To: <200508311045.56657.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org, kabaev@gmail.com Subject: Re: Odd performance problem (hitching) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 01:55:14 -0000 On 31 Aug, Daniel O'Connor wrote: > On Tuesday 30 August 2005 17:50, Daniel O'Connor wrote: >> > You might try significantly decreasing MAXVNODES_MAX in >> > sys/kern/vfs_subr.c and rebuilding your kernel. >> >> OK.. >> I'll try timing when the drop outs happen :) > > Hmm they appear to be every 10 seconds on the dot. Hmn, I wonder what runs every 10 seconds ... > I haven't changed any syncer delay stuff either.. > kern.filedelay: 30 > kern.dirdelay: 29 > kern.metadelay: 28 Those won't make any difference. They govern how many slots behind in the worklist that items of various types get inserted. The syncer wakes up once per second, processes all the items in a worklist slot, then goes back to sleep. The syncer vnode for each file system gets inserted when the file system is mounted and stays in the same slot, so the ugly FOREACH loop I mentioned earlier gets executed once each time the entire worklist is scanned, and since the worklist has 32 slots, the problem should only occur once every 32 seconds if you have one file system that has hogged most of the vnodes. If there are multiple file systems, the syncer vnodes will inserted at various power of two locations in the list, but I don't see a way to get activity spaced at ten second intervals. > Still using SCHED_4BSD too. > From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 01:56:45 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 5CF0516A41F for ; Wed, 31 Aug 2005 01:56:45 +0000 (GMT) (envelope-from jd@ugcs.caltech.edu) Received: from riyal.ugcs.caltech.edu (riyal.ugcs.caltech.edu [131.215.176.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BEE943D45 for ; Wed, 31 Aug 2005 01:56:45 +0000 (GMT) (envelope-from jd@ugcs.caltech.edu) Received: by riyal.ugcs.caltech.edu (Postfix, from userid 3640) id 0538B45804; Tue, 30 Aug 2005 18:56:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by riyal.ugcs.caltech.edu (Postfix) with ESMTP id A8AB145802; Tue, 30 Aug 2005 18:56:43 -0700 (PDT) Date: Tue, 30 Aug 2005 18:56:43 -0700 (PDT) From: Jon Dama To: Maksim Yevmenkin In-Reply-To: <43150D94.8050502@savvis.net> Message-ID: References: <20050831001504.B6E984E704@pipa.profix.cz> <43150D94.8050502@savvis.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-2 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: freebsd-current@freebsd.org, dandee@volny.cz Subject: Re: Application layer firewall on FreeBSD, is it possible ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 01:56:45 -0000 Um, how is that effectively different than my recommendation that he build something around tun/tap(4)? It seems to me that you are saying essentially the same thing. -Jon On Tue, 30 Aug 2005, Maksim Yevmenkin wrote: > Jon Dama wrote: > > I do not think this is possible with an existing "shrink-wrapped" > > solution. > > yes, it is. take a look at netgraph(4). for example with ethernet > interfaces you can connect userspace and/or application kernel module to > "lower" and "upper" ng_ether(4) hooks and effectively look at every > packet that goes in/out on the wire. > > max > > > > > Though, one would expect that it would be a relatively trivial matter t= o > > make a userland application from the linux application filter and then = use > > the tun/tap(4) driver. > > > > -Jon > > > > On Wed, 31 Aug 2005, [iso-8859-2] Daniel Dvo=F8=E1k wrote: > > > > > >>Okay, thank you for advise. Maybe I did not understand fully but ... > >> > >>... but you know, proxy is not what I am asking, proxy is not firewall. > >> > >>We do not need to restrict everything and all members. > >> > >>We like full routeable network with full access to IPv6 / IPv4 internet > >>without any necessary action like configure proxy clients at all pc=B4s= our > >>members. > >> > >>We only want to deny only p2p applications by default for all pc=B4s > >>regardless of used protocol/ports and to allow grantting access to p2p > >>networks each members in individual way, because we have to prevent ano= ther > >>letter from our ISP which was contacted by BSA that from our public IP = ( > >>from one member in private ip space ) ... traffic ... share ... violate= ... > >>authorial law. > >> > >>So of course it must be combination of IP and application osi model > >>firewall. > >> > >>Gateway server should check all packets and their contents to decide if > >>allowed or denied in fast way like l7-filter on Linux OS. > >> > >>So is it possible on FreeBSD OS ? > >> > >>Thanks > >> > >>Since my question here is not right like somebody told me, this is last > >>e-mail in this mailling list for this theme, and I send it to > >>freebsd-question, freebsd-ipfw and freebsd-pf mailling lists. > >> > >>Dan > >> > >>-----Original Message----- > >>From: owner-freebsd-current@freebsd.org > >>[mailto:owner-freebsd-current@freebsd.org] On Behalf Of Charles Swiger > >>Sent: Tuesday, August 30, 2005 9:51 PM > >>To: dandee@volny.cz > >>Cc: freebsd-current@freebsd.org > >>Subject: Re: Application layer firewall on FreeBSD, is it possible ? > >> > >>On Aug 30, 2005, at 2:58 PM, Daniel Dvo=F8=E1k wrote: > >> > >>>let me ask you for task "how to control p2p applications and their > >>>traffic with dynamic ports from user=B4s commputers on gateway". > >>> > >>>We are small wireless community and have shared access to internet for > >>>all members. Core members decided to control p2p traffic by default > >>>and to allow each person in individual way, after showing their > >>>knowledge of authorial low. :) > >>> > >>>But since many dc hubs, edonkey servers, bittorents web trackers and > >>>so on use dynamic not standard ports, how to control it ? > >> > >>Start with a "deny all" policy, and use L7 proxies like squid for the > >>specific protocols like HTTP which you want to permit. If you're reall= y > >>serious about controlling the traffic, don't let your router talk to > >>anything but your proxy server in order to be certain that the client > >>machines have to go through that. > >> > >>-- > >>-Chuck > >> > >>_______________________________________________ > >>freebsd-current@freebsd.org mailing list > >>http://lists.freebsd.org/mailman/listinfo/freebsd-current > >>To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" > >> > >>_______________________________________________ > >>freebsd-current@freebsd.org mailing list > >>http://lists.freebsd.org/mailman/listinfo/freebsd-current > >>To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" > >> > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" > From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 02:12: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 2103816A420 for ; Wed, 31 Aug 2005 02:12:44 +0000 (GMT) (envelope-from dandee@hellteam.net) Received: from pipa.profix.cz (server1.pcsvet.net [82.208.25.157]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F2C743D46 for ; Wed, 31 Aug 2005 02:12:43 +0000 (GMT) (envelope-from dandee@hellteam.net) Received: from localhost (localhost [127.0.0.1]) by pipa.profix.cz (Postfix) with ESMTP id 6E6164E706 for ; Wed, 31 Aug 2005 04:12:51 +0200 (CEST) Received: from pipa.profix.cz ([127.0.0.1]) by localhost (pipa [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21546-03 for ; Wed, 31 Aug 2005 04:12:51 +0200 (CEST) Received: from gandalf (unknown [80.95.121.105]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by pipa.profix.cz (Postfix) with ESMTP id 328814E704 for ; Wed, 31 Aug 2005 04:12:51 +0200 (CEST) From: =?US-ASCII?Q?Daniel_Dvorak?= To: Date: Wed, 31 Aug 2005 04:12:42 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcWt0VORTdD9XpoERgykAFwpdJNPdQAABZqg Message-Id: <20050831021251.328814E704@pipa.profix.cz> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at profix.cz Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: LOR wi0 device timeout followed by LOR ifnet new line 1155 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dandee@volny.cz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2005 02:12:44 -0000 wi0: device timeout lock order reversal 1st 0xc08d4d60 ifnet (ifnet) @ /usr/src/sys/net/if.c:1155 2nd 0xc1626b44 wi0 (network driver) @ /usr/src/sys/dev/wi/if_wi.c:656 KDB: stack backtrace: kdb_backtrace(c07e22d4,c1626b44,c161e950,c07cac1d,c07d6e24) at kdb_backtrace+0x2e witness_checkorder(c1626b44,9,c07d6e24,290,267) at witness_checkorder+0x6c3 _mtx_lock_flags(c1626b44,0,c07d6e24,290,18a) at _mtx_lock_flags+0x8a wi_init(c1626000,c07caff8,483,c07df5f9,c0884260) at wi_init+0x3d wi_watchdog(c1623c00,0,c07e86e6,483,c0884260) at wi_watchdog+0x5c if_slowtimo(0,0,c07df5f9,107,c05f0fe0) at if_slowtimo+0x67 softclock(0,0,c07dbd79,251,cc9f9d00) at softclock+0x24e ithread_loop(c1571900,cc9f9d38,c07dbb64,30d,deadc0de) at ithread_loop+0x162 fork_exit(c05572e0,c1571900,cc9f9d38) at fork_exit+0xc1 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xcc9f9d6c, ebp = 0 --- From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 02:55: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 5937516A41F for ; Wed, 31 Aug 2005 02:55:36 +0000 (GMT) (envelope-from ivoras@fer.hr) Received: from geri.cc.fer.hr (geri.cc.fer.hr [161.53.72.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 96CC243D45 for ; Wed, 31 Aug 2005 02:55:35 +0000 (GMT) (envelope-from ivoras@fer.hr) Received: from geri.cc.fer.hr (localhost.cc.fer.hr [127.0.0.1]) by geri.cc.fer.hr (8.13.3/8.13.1) with ESMTP id j7V2sK4q051026 for ; Wed, 31 Aug 2005 04:54:20 +0200 (CEST) (envelope-from ivoras@fer.hr) Received: from localhost (ivoras@localhost) by geri.cc.fer.hr (8.13.3/8.13.1/Submit) with ESMTP id j7V2sKG0051023 for ; Wed, 31 Aug 2005 04:54:20 +0200 (CEST) (envelope-from ivoras@fer.hr) X-Authentication-Warning: geri.cc.fer.hr: ivoras owned process doing -bs Date: Wed, 31 Aug 2005 04:54:20 +0200 (CEST) From: Ivan Voras Sender: ivoras@geri.cc.fer.hr To: current@freebsd.org Message-ID: <20050831044823.N50961@geri.cc.fer.hr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: gjournal beta3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 02:55:36 -0000 I'm happy to announce beta3 version of gjournal! The only reason I'm not calling it "1.0 release" is that it hasn't received much testing yet and there have been many changes since the last public beta, so I still don't recommend it for production use. For all intents and purposes this is the final version (+/- bugfixes, of course :) ). The source is available at: http://ivoras.sharanet.org/stuff/gjournal-beta3.tgz (read the README file!) More information is available at: http://wikitest.freebsd.org/moin.cgi/gjournal This work has been sponsored by Google's SoC project, which I thank. Also thanks to menthors, Poul Henning Kamp and Pawel Jakub Dawidek. -- Every sufficiently advanced magic is indistinguishable from technology - Arthur C Anticlarke From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 03:04: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 6C5D516A41F for ; Wed, 31 Aug 2005 03:04:31 +0000 (GMT) (envelope-from minimarmot@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7D0143D4C for ; Wed, 31 Aug 2005 03:04:30 +0000 (GMT) (envelope-from minimarmot@gmail.com) Received: by wproxy.gmail.com with SMTP id i4so31263wra for ; Tue, 30 Aug 2005 20:04:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=FgYfEgm8BvXhEspJbS7LOb1QqglxY3xS1fUnV8XfMzAeneKLzuuqMWKHTpfraWI9ije6cTZ1s2YiFbAoes9sXxmUIMrKyBIs87m3Mbmu0AVum99ug8OIB7JGFFtBiwWfJN66UOSV5zQWO8efTFfgKieJIKT9npVRtDktW7k86hE= Received: by 10.54.130.10 with SMTP id c10mr368084wrd; Tue, 30 Aug 2005 20:04:29 -0700 (PDT) Received: by 10.54.44.25 with HTTP; Tue, 30 Aug 2005 20:04:29 -0700 (PDT) Message-ID: <47d0403c05083020044f6ac0be@mail.gmail.com> Date: Wed, 31 Aug 2005 03:04:29 +0000 From: Ben Kaduk To: Kyle Brooks In-Reply-To: <1125452228.740.3.camel@arbitor.homelinux.com> Mime-Version: 1.0 References: <1125452228.740.3.camel@arbitor.homelinux.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: panic after removing usb flash drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 03:04:31 -0000 On 8/31/05, Kyle Brooks wrote: >=20 > umass0: LEXAR MEDIA JUMPDRIVE2, rev 2.00/1.25, addr 2 > umass0: at uhub4 port 6 (addr 2) disconnected > panic: vm_fault: fault on nofault entry, addr: deadc000 >=20 > kernel: >=20 > FreeBSD 7.0-CURRENT #2: Mon Aug 29 00:39:21 UTC 2005 >=20 > problem: >=20 > kernel panics when usb flash drive is removed >=20 > backtrace: >=20 > #0 doadump () at pcpu.h:165 > #1 0xc068610e in boot (howto=3D260) > at /usr/src/sys/kern/kern_shutdown.c:397 > #2 0xc0685b92 in panic ( > fmt=3D0xc090e46c "vm_fault: fault on nofault entry, addr: %lx") > at /usr/src/sys/kern/kern_shutdown.c:553 > #3 0xc0812de1 in vm_fault (map=3D0xc1060000, vaddr=3D3735928832, > fault_type=3D2 '\002', fault_flags=3D0) > at /usr/src/sys/vm/vm_fault.c:884 > #4 0xc0888807 in trap_pfault (frame=3D0xe6a06bf0, usermode=3D0, > eva=3D3735929110) > at /usr/src/sys/i386/i386/trap.c:741 > #5 0xc0888d04 in trap (frame=3D > {tf_fs =3D 8, tf_es =3D -1063649240, tf_ds =3D 40, tf_edi =3D -993875968, > tf_esi =3D -1014223872, tf_ebp =3D -425694000, tf_isp =3D -425694180, tf_= ebx =3D > -1063640044, tf_edx =3D -993875900, tf_ecx =3D 0, tf_eax =3D -559038242, > tf_trapno =3D 12, tf_err =3D 2, tf_eip =3D -1069194040, tf_cs =3D 32, tf_= eflags > =3D 66050, tf_esp =3D -1063640032, tf_ss =3D 0}) > at /usr/src/sys/i386/i386/trap.c:442 > #6 0xc08745ba in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > #7 0x00000008 in ?? () > #8 0xc09a0028 in atdma_acpi_driver_mod () > #9 0x00000028 in ?? () > #10 0xc4c2a800 in ?? () > #11 0xc38c2c00 in ?? () > #12 0xe6a06cd0 in ?? () > #13 0xe6a06c1c in ?? () > ---Type to continue, or q to quit--- > #14 0xc09a2414 in xsoftc () > #15 0xc4c2a844 in ?? () > #16 0x00000000 in ?? () > #17 0xdeadc0de in ?? () > #18 0x0000000c in ?? () > #19 0x00000002 in ?? () > #20 0xc04564c8 in camisr (V_queue=3D0xc09a2414) > at /usr/src/sys/cam/cam_xpt.c:7066 > #21 0xc066f84e in ithread_loop (arg=3D0xc356fa80) > at /usr/src/sys/kern/kern_intr.c:545 > #22 0xc066e808 in fork_exit (callout=3D0xc066f665 , arg=3D0= x0, > frame=3D0x0) at /usr/src/sys/kern/kern_fork.c:789 > #23 0xc087461c in fork_trampoline () > at /usr/src/sys/i386/i386/exception.s:208 >=20 > _______________________________________________ > 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= " >=20 This is the expected behaviour if you didn't unmount the filesystem on the= =20 thumbdrive before removing it. There was some discussion on this a while ag= o=20 (but I don't seem to be able to find the exact posts), but the general idea= =20 is that the kernel has no idea in what state the actual physical medium=20 (disc) is/was in after being pulled, and may have some stale buffers holdin= g=20 data that got written to disk. It doesn't know what to do with this data, o= r=20 how to treat requests to that device, so it panics. Of course, if you did unmount the filesystem before pulling the drive, then= =20 this shoule be looked into. Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 03:37: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 2748516A41F for ; Wed, 31 Aug 2005 03:37:02 +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 7CB2A43D55 for ; Wed, 31 Aug 2005 03:37:00 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.31]) (authenticated bits=0) by cain.gsoft.com.au (8.13.4/8.13.4) with ESMTP id j7V3ak2A092813 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 31 Aug 2005 13:06:52 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Wed, 31 Aug 2005 13:06:46 +0930 User-Agent: KMail/1.8.1 References: <1125452228.740.3.camel@arbitor.homelinux.com> <47d0403c05083020044f6ac0be@mail.gmail.com> In-Reply-To: <47d0403c05083020044f6ac0be@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3855473.0QIpjHGBHX"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200508311306.46876.doconnor@gsoft.com.au> X-Spam-Score: -2.82 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.51 on 203.31.81.10 Cc: Kyle Brooks , Ben Kaduk Subject: Re: panic after removing usb flash drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 03:37:02 -0000 --nextPart3855473.0QIpjHGBHX Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 31 August 2005 12:34, Ben Kaduk wrote: > Of course, if you did unmount the filesystem before pulling the drive, th= en > this shoule be looked into. IMHO it would be really nice if you could tell the kernel that it should ju= st=20 ditch the data (and whine to the log file) instead of panicing. =46or your "main" file systems the panic approach is sensible, but for remo= vable=20 things it's more likely to cause data loss I think (because the panic could= =20 eat data on your other drives). Although last time I saw this discussed I came away with the impression tha= t=20 it wasn't possible for the kernel to do this..? (without substantial work=20 anyway) =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 --nextPart3855473.0QIpjHGBHX Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBDFSXO5ZPcIHs/zowRAkomAJ9QLe0NWPOuNZt3bps9WJv7fSaVNwCeMAn6 lj8cxOOehWU4+j7Ow/Ik9lw= =cyPY -----END PGP SIGNATURE----- --nextPart3855473.0QIpjHGBHX-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 05:38:45 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 AC95D16A41F for ; Wed, 31 Aug 2005 05:38:45 +0000 (GMT) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4388E43D45 for ; Wed, 31 Aug 2005 05:38:43 +0000 (GMT) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 2871940; Wed, 31 Aug 2005 07:38:40 +0200 (SAST) Date: Wed, 31 Aug 2005 07:38:40 +0200 From: John Hay To: Beecher Rintoul Message-ID: <20050831053839.GA76471@zibbi.meraka.csir.co.za> References: <4740.172.16.0.199.1125444307.squirrel@172.16.0.1> <200508301616.50131.akbeech@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200508301616.50131.akbeech@gmail.com> User-Agent: Mutt/1.4.1i Cc: Mike Jakubik , freebsd-current@freebsd.org Subject: Re: More "make release" problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 05:38:45 -0000 On Tue, Aug 30, 2005 at 04:16:48PM -0800, Beecher Rintoul wrote: > On Tuesday 30 August 2005 03:25 pm, Mike Jakubik wrote: ... > > ===> lib/libcom_err/doc (all) > > makeinfo --no-split -I /usr/src/lib/libcom_err/doc -I > > /usr/src/lib/libcom_err/doc /usr/src/lib/libcom_err/doc/com_err.texinfo > > -o com_err.info > > makeinfo:No such file or directory > > *** Error code 1 > > > > Stop in /usr/src/lib/libcom_err/doc. > > *** Error code 1 > > I have the exact same problem trying to make install disks. So far I haven't > gotten any responses to my post. I could file a PR on this but I was hoping > somebody would shed some light on the problem first. The problem is that NO_INFO controls more than just the info docs nowadays, it also controls the installation of the info tools. The installworld part of make release that populates the chroot area, use NO_INFO as a speed optimization. The fix is to remove NO_INFO from the installworld line in release/Makefile. I'll get to it within a day or so. John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 05:55:45 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 BAFE916A41F for ; Wed, 31 Aug 2005 05:55:45 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail1.fluidhosting.com (mail1.fluidhosting.com [204.14.90.61]) by mx1.FreeBSD.org (Postfix) with SMTP id 3522C43D45 for ; Wed, 31 Aug 2005 05:55:45 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 24239 invoked by uid 399); 31 Aug 2005 05:55:44 -0000 Received: from localhost (HELO ?192.168.1.101?) (dougb@dougbarton.net@127.0.0.1) by localhost with SMTP; 31 Aug 2005 05:55:44 -0000 Message-ID: <4315465C.8090506@FreeBSD.org> Date: Tue, 30 Aug 2005 22:55:40 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050829) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Hay References: <4740.172.16.0.199.1125444307.squirrel@172.16.0.1> <200508301616.50131.akbeech@gmail.com> <20050831053839.GA76471@zibbi.meraka.csir.co.za> In-Reply-To: <20050831053839.GA76471@zibbi.meraka.csir.co.za> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mike Jakubik , freebsd-current@freebsd.org, Beecher Rintoul Subject: Re: More "make release" problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 05:55:45 -0000 John Hay wrote: > The problem is that NO_INFO controls more than just the info docs nowadays, > it also controls the installation of the info tools. Wouldn't a better solution be to granulate the knobs, and have NO_INFO_TOOLS and NO_INFO_DOCS, with NO_INFO implying both? Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 09:29: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 1D3A916A41F for ; Wed, 31 Aug 2005 09:29:28 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id B38C843D48 for ; Wed, 31 Aug 2005 09:29:27 +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 postfix4-1.free.fr (Postfix) with ESMTP id AEE1B319EF0; Wed, 31 Aug 2005 11:29:26 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id D6675405A; Wed, 31 Aug 2005 11:29:44 +0200 (CEST) Date: Wed, 31 Aug 2005 11:29:44 +0200 From: Jeremie Le Hen To: Kris Kennaway Message-ID: <20050831092944.GB659@obiwan.tataz.chchile.org> References: <20050830124435.GW659@obiwan.tataz.chchile.org> <20050830232818.GA83944@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050830232818.GA83944@xor.obsecurity.org> User-Agent: Mutt/1.5.9i Cc: Matthias Andree , Jeremie Le Hen , freebsd-current@freebsd.org Subject: Re: nfs through nullfs (was: 6.0-BETA3: ext2fs through nullfs: panic "locking against myself") X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 09:29:28 -0000 Hi Kris, > > > Subject says it all. > > > > > > mount a ext2 file system, use it as basis for a nullfs mount -> panic. > > > > Mount a NFS filesystem, use it as basis for nullfs mount -> panic. > > Please provide details. I already provided details on this one month ago [1]. By the way, you told me to send the report to jeff@ directly. Unfortunately, I think he had too much real life work to take care of this for the moment, and I think we will have to live with this for the release. Regards, [1] http://lists.freebsd.org/pipermail/freebsd-current/2005-July/053451.html -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 10:12:26 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 788E516A41F for ; Wed, 31 Aug 2005 10:12:26 +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 D7C9843D70 for ; Wed, 31 Aug 2005 10:12:18 +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 27953440A9; Wed, 31 Aug 2005 12:12:16 +0200 (CEST) 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 22240-02; Wed, 31 Aug 2005 12:12:14 +0200 (CEST) Received: from m2a2.dyndns.org (p5091368B.dip0.t-ipconnect.de [80.145.54.139]) by mail.dt.e-technik.uni-dortmund.de (Postfix) with ESMTP id 8DB7A440A0; Wed, 31 Aug 2005 12:12:14 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by merlin.emma.line.org (Postfix) with ESMTP id 78006774D4; Wed, 31 Aug 2005 12:12:12 +0200 (CEST) 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 14534-16; Wed, 31 Aug 2005 12:12:11 +0200 (CEST) Received: by merlin.emma.line.org (Postfix, from userid 500) id A61C277790; Wed, 31 Aug 2005 12:12:11 +0200 (CEST) From: Matthias Andree To: Kris Kennaway In-Reply-To: <20050830232818.GA83944@xor.obsecurity.org> (Kris Kennaway's message of "Tue, 30 Aug 2005 19:28:18 -0400") References: <20050830124435.GW659@obiwan.tataz.chchile.org> <20050830232818.GA83944@xor.obsecurity.org> X-PGP-Key: http://home.pages.de/~mandree/keys/GPGKEY.asc Date: Wed, 31 Aug 2005 12:12:11 +0200 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: Matthias Andree , Jeremie Le Hen , freebsd-current@freebsd.org Subject: Re: nfs through nullfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 10:12:26 -0000 Kris Kennaway writes: > On Tue, Aug 30, 2005 at 02:44:35PM +0200, Jeremie Le Hen wrote: >> > Subject says it all. >> > >> > mount a ext2 file system, use it as basis for a nullfs mount -> panic. >> >> Mount a NFS filesystem, use it as basis for nullfs mount -> panic. > > Please provide details. OK, to reproduce, three steps apart from having an ext2 file system (the ext2 FS is clean according to e2fsck) mount_ext2fs /dev/ad0s5 /linux mount_nullfs /linux /mnt umount /mnt -> panic, "locking against myself" backtrace in the kernel debugger, copied manually: kdb_enter panic +0x13d lockmgr +0x44d vop_stdlock +0x2f VOP_LOCK_APV vn_lock vrele null_reclaim VOP_RECLAIM_APV vgonel vgone vflush nullfs_unmount dounmount unmount syscall... (process unmount) If needed, I can save a core of this. -- Matthias Andree From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 11:10:45 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 5363416A41F for ; Wed, 31 Aug 2005 11:10:45 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1186043D46 for ; Wed, 31 Aug 2005 11:10:45 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 418AC46BD9 for ; Wed, 31 Aug 2005 07:10:44 -0400 (EDT) Date: Wed, 31 Aug 2005 12:10:44 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Message-ID: <20050831120730.B39418@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Ctrl-c abort of dhclient during rc.d start aborts all network configuration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 11:10:45 -0000 I believe this is related to the new dhclient -- when I run my notebook disconnected from the network, the boot pauses for about 15-20 seconds waiting for a link on xl0. Being impatient when booting in airports just before my flight, I like to hit Ctrl-C and abort it, since I know that there will be no link. In the old world order, this was fine, dhclient was simply killed and all was good. In the new world order, it kills all of the netif startup script, and for some reason (ordering related, presumably), this prevents 127.0.0.1 from being configured on lo0, which causes a number of applications to die, since 0.0.0.0 cannot be bound. It sounds like a couple of things are unfortunate here: (1) It would be good to configure lo0 first. (2) If a dhclient is ctrl-c'd, it would be nice if the rest of the network configuration continued. The printing of '.'s in dhclient is also a bit excessive. Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 11:19: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 584E116A41F for ; Wed, 31 Aug 2005 11:19:10 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FC7F43D45 for ; Wed, 31 Aug 2005 11:19:10 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id AAD9F46B23; Wed, 31 Aug 2005 07:19:09 -0400 (EDT) Date: Wed, 31 Aug 2005 12:19:09 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: dandee@volny.cz In-Reply-To: <20050830185851.ECF554E704@pipa.profix.cz> Message-ID: <20050831121627.J39418@fledge.watson.org> References: <20050830185851.ECF554E704@pipa.profix.cz> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1143843103-1125487149=:39418" Cc: freebsd-current@freebsd.org Subject: Re: Application layer firewall on FreeBSD, is it possible ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 11:19:10 -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-1143843103-1125487149=:39418 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 30 Aug 2005, [iso-8859-2] Daniel Dvo?=E1k wrote: > So, is there any way to do same application layer osi model firewall=20 > with FreeBSD gateway ? > > Of course, I tried to find on web, I have not been successful in=20 > searching so far. > > If my question is not right in this mailing list, if my question is=20 > annoying here, so I am sorry. I can't speak to the details of the environment or protocols, but you=20 might take a look at "ipfw fwd", which allows you to locally intercept=20 wide area network TCP connections passing through an IP router. This can= =20 be used for things like transparent proxy caching, transparent firewalls,= =20 and so on. ipfw(8) contains some details, but I've not played with it=20 myself so I can't tell you much more than that it looks like applications= =20 can simply bind a TCP port, and then you can use ipfw fwd to redirect=20 connections to it. I'm not sure how well ICMP is handled. Robert N M Watson --0-1143843103-1125487149=:39418-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 11:24: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 D7D0416A41F for ; Wed, 31 Aug 2005 11:24:50 +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 D4EA443D46 for ; Wed, 31 Aug 2005 11:24:49 +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 j7VBOlCv025355 for ; Wed, 31 Aug 2005 12:24:47 +0100 (BST) Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.13.3/8.13.4) with ESMTP id j7VBOk7A058513 for ; Wed, 31 Aug 2005 12:24:46 +0100 (BST) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: (from ga9@localhost) by buffy.york.ac.uk (8.13.3/8.13.4/Submit) id j7VBOktm058512 for freebsd-current@freebsd.org; Wed, 31 Aug 2005 12:24:46 +0100 (BST) (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: freebsd-current@freebsd.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 31 Aug 2005 12:24:45 +0100 Message-Id: <1125487485.34476.6.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 Subject: 6.0BETA3 panic in ip_output (vlan/RIP related?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2005 11:24:51 -0000 Hi, I've just managed to panic an amd64 machine running 6.0BETA3. wiggum# ifconfig vlan76 destroy wiggum# Aug 31 12:02:48 wiggum routed[244]: IP_DROP_MEMBERSHIP ALLHOSTS: Can't assign requested address wiggum# wiggum# ifconfig vlan76 create wiggum# ifconfig vlan76 vlan 76 vlandev bge0 wiggum# ifconfig vlan76 inet x.y.76.59 netmask 255.255.254.0 Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x8:0xffffffff80429420 stack pointer = 0x10:0xffffffffb260b600 frame pointer = 0x10:0xffffffffb260b710 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 244 (routed) [thread pid 244 tid 100077 ] Stopped at strlen: cmpb $0,0(%rdi) db> tr Tracing pid 244 tid 100077 td 0xffffff0078c74980 strlen() at strlen vsnprintf() at vsnprintf+0x2e panic() at panic+0x14b _mtx_lock_flags() at _mtx_lock_flags+0xd6 ip_output() at ip_output+0x692 rip_output() at rip_output+0x161 rip_send() at rip_send+0x65 sosend() at sosend+0x654 kern_sendit() at kern_sendit+0x104 sendit() at sendit+0x66 sendto() at sendto+0x54 syscall() at syscall+0x4b2 Xfast_syscall() at Xfast_syscall+0xa8 --- syscall (133, FreeBSD ELF64, sendto), rip = 0x800799dfc, rsp = 0x7fffffffeb28, rbp = 0x413112 --- db> (kgdb) where #23 0xffffffff803d3d5e in vsnprintf (str=0x0, size=0, format=0x0, ap=0x0) at /usr/src/sys/kern/subr_prf.c:408 #24 0xffffffff803b3efb in panic (fmt=0xffffffff80615639 "%s @ %s:%d") at /usr/src/sys/kern/kern_shutdown.c:520 #25 0xffffffff803ab6e6 in _mtx_lock_flags (m=0xffffff00622dec78, opts=0, file=0xffffffff80628080 "/usr/src/sys/netinet/ip_output.c", line=296) at /usr/src/sys/kern/kern_mutex.c:268 #26 0xffffffff80464a52 in ip_output (m=0xffffff005e402300, opt=0xffffff0042432000, ro=0xffffffffb260b8d0, flags=32, imo=0xffffff007b8aa500, inp=0xffffff0061bf2000) at /usr/src/sys/netinet/ip_output.c:296 #27 0xffffffff80465791 in rip_output (m=0xffffff005e402300, so=0x0, dst=64) at /usr/src/sys/netinet/raw_ip.c:320 #28 0xffffffff80466535 in rip_send (so=0xffffff0061ccf000, flags=0, m=0xffffff005e402300, nam=0xffffff007b5b90f0, control=0x0, td=0x0) at /usr/src/sys/netinet/raw_ip.c:785 #29 0xffffffff803f95c4 in sosend (so=0xffffff0061ccf000, addr=0xffffff007b5b90f0, uio=0xffffffffb260ba80, top=0xffffff005e402300, control=0x0, flags=0, td=0xffffff0078c74980) at /usr/src/sys/kern/uipc_socket.c:829 #30 0xffffffff80400534 in kern_sendit (td=0xffffff0078c74980, s=5, mp=0xffffffffb260bb50, flags=0, control=0x0, segflg=8) at /usr/src/sys/kern/uipc_syscalls.c:772 #31 0xffffffff804016f6 in sendit (td=0xffffff0078c74980, s=5, mp=0xffffffffb260bb50, flags=0) at /usr/src/sys/kern/uipc_syscalls.c:712 #32 0xffffffff80401ab4 in sendto (td=0x0, uap=0x0) at /usr/src/sys/kern/uipc_syscalls.c:830 #33 0xffffffff80570042 in syscall (frame= {tf_rdi = 5, tf_rsi = 140737488350080, tf_rdx = 8, tf_rcx = 0, tf_r8 = 140737488350016, tf_r9 = 16, tf_rax = 133, tf_rbx = 5367808, tf) at /usr/src/sys/amd64/amd64/trap.c:796 #34 0xffffffff8055d468 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:272 (kgdb) f 25 #25 0xffffffff803ab6e6 in _mtx_lock_flags (m=0xffffff00622dec78, opts=0, file=0xffffffff80628080 "/usr/src/sys/netinet/ip_output.c", line=296) at /usr/src/sys/kern/kern_mutex.c:268 268 KASSERT(m->mtx_object.lo_class == &lock_class_mtx_sleep, (kgdb) l 263 void 264 _mtx_lock_flags(struct mtx *m, int opts, const char *file, int line) 265 { 266 267 MPASS(curthread != NULL); 268 KASSERT(m->mtx_object.lo_class == &lock_class_mtx_sleep, 269 ("mtx_lock() of spin mutex %s @ %s:%d", m->mtx_object.lo_name, 270 file, line)); 271 WITNESS_CHECKORDER(&m->mtx_object, opts | LOP_NEWORDER | LOP_EXCLUSIVE, 272 file, line); (kgdb) up #26 0xffffffff80464a52 in ip_output (m=0xffffff005e402300, opt=0xffffff0042432000, ro=0xffffffffb260b8d0, flags=32, imo=0xffffff007b8aa500, inp=0xffffff0061bf2000) at /usr/src/sys/netinet/ip_output.c:296 296 IN_LOOKUP_MULTI(ip->ip_dst, ifp, inm); (kgdb) l 291 if (ia != NULL) 292 ip->ip_src = IA_SIN(ia)->sin_addr; 293 } 294 295 IN_MULTI_LOCK(); 296 IN_LOOKUP_MULTI(ip->ip_dst, ifp, inm); 297 if (inm != NULL && 298 (imo == NULL || imo->imo_multicast_loop)) { 299 IN_MULTI_UNLOCK(); 300 /* I've got the core file if anyone wants any more info. Gavin From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 11:48: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 BFA1116A41F for ; Wed, 31 Aug 2005 11:48:05 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from efnet-math.org (efnet-math.org [69.60.109.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3ECC643D45 for ; Wed, 31 Aug 2005 11:48:05 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from [192.168.1.5] (host191-173.pool8259.interbusiness.it [82.59.173.191]) (authenticated bits=0) by efnet-math.org (8.13.1/8.13.1) with ESMTP id j7VBm00r019010 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 31 Aug 2005 07:48:02 -0400 In-Reply-To: References: <20050830124435.GW659@obiwan.tataz.chchile.org> <20050830232818.GA83944@xor.obsecurity.org> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <66A71CA4-8134-43A3-BEAB-485C7DF59EA1@FreeBSD.org> Content-Transfer-Encoding: 7bit From: Suleiman Souhlal Date: Wed, 31 Aug 2005 13:47:49 +0200 To: Matthias Andree X-Mailer: Apple Mail (2.733) Cc: freebsd-current@FreeBSD.org, Jeremie Le Hen , Kris Kennaway Subject: Re: nfs through nullfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 11:48:05 -0000 Hi, On Aug 31, 2005, at 12:12 PM, Matthias Andree wrote: > Kris Kennaway writes: > > >> On Tue, Aug 30, 2005 at 02:44:35PM +0200, Jeremie Le Hen wrote: >> >>>> Subject says it all. >>>> >>>> mount a ext2 file system, use it as basis for a nullfs mount -> >>>> panic. >>>> >>> >>> Mount a NFS filesystem, use it as basis for nullfs mount -> panic. >>> >> >> Please provide details. >> > > OK, to reproduce, three steps apart from having an ext2 file system > (the ext2 FS is clean according to e2fsck) > > mount_ext2fs /dev/ad0s5 /linux > mount_nullfs /linux /mnt > umount /mnt -> panic, "locking against myself" > > backtrace in the kernel debugger, copied manually: Can you try the patch at http://people.freebsd.org/~ssouhlal/testing/ null_vnops.c-20050831.diff ? Bye, -- Suleiman Souhlal | ssouhlal@vt.edu The FreeBSD Project | ssouhlal@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 11:54: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 74EAC16A41F; Wed, 31 Aug 2005 11:54:55 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98BD043D48; Wed, 31 Aug 2005 11:54:52 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id j7VBsnWG015635; Wed, 31 Aug 2005 15:54:49 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id j7VBsnYd015630; Wed, 31 Aug 2005 15:54:49 +0400 (MSD) (envelope-from yar) Date: Wed, 31 Aug 2005 15:54:48 +0400 From: Yar Tikhiy To: Gavin Atkinson Message-ID: <20050831115448.GB13201@comp.chem.msu.su> References: <1125422629.30555.27.camel@buffy.york.ac.uk> <200508301414.15449.jkim@FreeBSD.org> <20050830202721.K57336@ury.york.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050830202721.K57336@ury.york.ac.uk> User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org, Jung-uk Kim Subject: Re: 6.0-BETA3 bge0 and vlans X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 11:54:55 -0000 On Tue, Aug 30, 2005 at 08:30:24PM +0100, Gavin Atkinson wrote: > On Tue, 30 Aug 2005, Jung-uk Kim wrote: > >On Tuesday 30 August 2005 01:23 pm, Gavin Atkinson wrote: > >>Hi, > >> > >>I'm having no success setting vlans up on a bge interface. Can anyone > >>confirm they work? I've got no problems using them on fxp interfaces, > >>so I'm pretty sure it's not user error... Everything looks good but I > >>can get no packets through the vlan interface (the parent interface > >>works as expected). Can anyone actually confirm that vlans work with > >>bge cards? My card is a BCM5704 (vend=0x14e4, prod=0x1648, rev=0x03) > > > >It was discussed here but I don't think any actions were taken > >actually. Follow the thread: > > > >http://docs.freebsd.org/cgi/mid.cgi?9256D57F598E6C41B288AA7DB94F29C902DFB963 This seems a different problem to me. Can't tell if it still exists. Perhaps it has to do with doing promiscuous mode (tcpdump) and hardware tagging on bge0 at once. We saw this problem on em(4) already. Alas, my test machine with bge(4) will stay down for quite a while. > Ah yes. After sending that, I did a bit more googling. The patch > contained in > http://lists.freebsd.org/pipermail/freebsd-net/2005-April/006932.html > fixes the problem for me... Keep in mind that that patch hides the problem instead of fixing it. The problem was fixed in CURRENT yesterday by glebius@. If you would like to stay with 6.0-BETA3 for now, please apply the following patch to /sys/net/if_vlan.c: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/net/if_vlan.c.diff?r1=1.81&r2=1.82 Than you'll be able to use the unpatched if_bge.c. -- Yar From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 16:10: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 24B2316A41F for ; Tue, 30 Aug 2005 16:10:00 +0000 (GMT) (envelope-from dandee@volny.cz) Received: from pipa.profix.cz (server1.pcsvet.net [82.208.25.157]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DD5C43D5A for ; Tue, 30 Aug 2005 16:09:58 +0000 (GMT) (envelope-from dandee@volny.cz) Received: from localhost (localhost [127.0.0.1]) by pipa.profix.cz (Postfix) with ESMTP id 861DA4E706 for ; Tue, 30 Aug 2005 18:10:01 +0200 (CEST) Received: from pipa.profix.cz ([127.0.0.1]) by localhost (pipa [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13501-08 for ; Tue, 30 Aug 2005 18:10:01 +0200 (CEST) Received: from gandalf (unknown [80.95.121.105]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by pipa.profix.cz (Postfix) with ESMTP id 343DD4E704 for ; Tue, 30 Aug 2005 18:10:01 +0200 (CEST) From: "Stay d" To: Date: Tue, 30 Aug 2005 18:09:55 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcWtfUMc7cc2FNbMSRaeidfduLD57g== Message-Id: <20050830161001.343DD4E704@pipa.profix.cz> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at profix.cz X-Mailman-Approved-At: Wed, 31 Aug 2005 12:24:24 +0000 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Application layer firewall on FreeBSD, is it possible ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dandee@volny.cz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2005 16:10:00 -0000 Hi all, =20 let me ask you for task "how to control p2p applications and their = traffic with dynamic ports from user=B4s commputers on gateway". =20 We are small wireless community and have shared access to internet for = all members. Core members decided to control p2p traffic by default and to = allow each person in individual way, after showing their knowledge of authorial low. :) =20 But since many dc hubs, edonkey servers, bittorents web trackers and so = on use dynamic not standard ports, how to control it ? =20 Linux use l7-filter http://sourceforge.net/projects/l7-filter = sourceforge freeware and , it is based on iptables, defination application protocols like ethereal project do. =20 So, is there any way to do same application layer osi model firewall = with FreeBSD gateway ? =20 Of course, I tried to find on web, I have not been successful in = searching so far. =20 If my question is not right in this mailing list, if my question is = annoying here, so I am sorry. =20 Dan =20 =20 From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 02:11: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 9AC7116A41F for ; Wed, 31 Aug 2005 02:11:44 +0000 (GMT) (envelope-from dandee@volny.cz) Received: from pipa.profix.cz (server1.pcsvet.net [82.208.25.157]) by mx1.FreeBSD.org (Postfix) with ESMTP id DEC7243D46 for ; Wed, 31 Aug 2005 02:11:43 +0000 (GMT) (envelope-from dandee@volny.cz) Received: from localhost (localhost [127.0.0.1]) by pipa.profix.cz (Postfix) with ESMTP id BCBA64E706 for ; Wed, 31 Aug 2005 04:11:50 +0200 (CEST) Received: from pipa.profix.cz ([127.0.0.1]) by localhost (pipa [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21546-02 for ; Wed, 31 Aug 2005 04:11:50 +0200 (CEST) Received: from gandalf (unknown [80.95.121.105]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by pipa.profix.cz (Postfix) with ESMTP id 7B6084E704 for ; Wed, 31 Aug 2005 04:11:50 +0200 (CEST) From: "Stay d" To: Date: Wed, 31 Aug 2005 04:11:41 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcWt0VORTdD9XpoERgykAFwpdJNPdQ== Message-Id: <20050831021150.7B6084E704@pipa.profix.cz> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at profix.cz X-Mailman-Approved-At: Wed, 31 Aug 2005 12:24:24 +0000 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: LOR wi0 device timeout followed by LOR ifnet new line 1155 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dandee@volny.cz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2005 02:11:44 -0000 wi0: device timeout lock order reversal 1st 0xc08d4d60 ifnet (ifnet) @ /usr/src/sys/net/if.c:1155 2nd 0xc1626b44 wi0 (network driver) @ /usr/src/sys/dev/wi/if_wi.c:656 KDB: stack backtrace: kdb_backtrace(c07e22d4,c1626b44,c161e950,c07cac1d,c07d6e24) at kdb_backtrace+0x2e witness_checkorder(c1626b44,9,c07d6e24,290,267) at witness_checkorder+0x6c3 _mtx_lock_flags(c1626b44,0,c07d6e24,290,18a) at _mtx_lock_flags+0x8a wi_init(c1626000,c07caff8,483,c07df5f9,c0884260) at wi_init+0x3d wi_watchdog(c1623c00,0,c07e86e6,483,c0884260) at wi_watchdog+0x5c if_slowtimo(0,0,c07df5f9,107,c05f0fe0) at if_slowtimo+0x67 softclock(0,0,c07dbd79,251,cc9f9d00) at softclock+0x24e ithread_loop(c1571900,cc9f9d38,c07dbb64,30d,deadc0de) at ithread_loop+0x162 fork_exit(c05572e0,c1571900,cc9f9d38) at fork_exit+0xc1 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xcc9f9d6c, ebp = 0 --- From owner-freebsd-current@FreeBSD.ORG Tue Aug 30 16: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 EB23C16A41F for ; Tue, 30 Aug 2005 16:23:46 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: from mail23.sea5.speakeasy.net (mail23.sea5.speakeasy.net [69.17.117.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9E4543D4C for ; Tue, 30 Aug 2005 16:23:45 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: (qmail 13557 invoked from network); 30 Aug 2005 16:23:45 -0000 Received: from aldan.algebra.com (HELO blue.virtual-estates.net) ([216.254.65.224]) (envelope-sender ) by mail23.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 30 Aug 2005 16:23:41 -0000 Received: from corbulon.video-collage.com (static-151-204-231-237.bos.east.verizon.net [151.204.231.237]) by blue.virtual-estates.net (8.13.3/8.13.3) with ESMTP id j7UGNcFw067246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 30 Aug 2005 12:23:39 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from mteterin.us.murex.com (195-11.customer.cloud9.net [168.100.195.11]) by corbulon.video-collage.com (8.13.4/8.13.1) with ESMTP id j7UGNU8u029410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Aug 2005 12:23:32 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from mteterin.us.murex.com (mteterin@localhost [127.0.0.1]) by mteterin.us.murex.com (8.13.3/8.13.3) with ESMTP id j7UGNNop027060; Tue, 30 Aug 2005 12:23:23 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from localhost (localhost [[UNIX: localhost]]) by mteterin.us.murex.com (8.13.3/8.13.3/Submit) id j7UGNKHJ027059; Tue, 30 Aug 2005 12:23:20 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) X-Authentication-Warning: mteterin.us.murex.com: mteterin set sender to mi+mx@aldan.algebra.com using -f From: Mikhail Teterin Organization: Virtual Estates, Inc. To: Miguel Mendez Date: Tue, 30 Aug 2005 12:23:20 -0400 User-Agent: KMail/1.8.2 References: <200508281326.j7SDQGfc073329@blue.virtual-estates.net> <20050829191927.6694a969.flynn@energyhq.es.eu.org> In-Reply-To: <20050829191927.6694a969.flynn@energyhq.es.eu.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508301223.20626.mi+mx@aldan.algebra.com> X-Virus-Scanned: ClamAV devel-20050525/1047/Mon Aug 29 13:00:08 2005 on corbulon.video-collage.com X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.43 X-Mailman-Approved-At: Wed, 31 Aug 2005 12:26:09 +0000 Cc: re@freebsd.org, current@freebsd.org Subject: Re: installing 6.0-BETA3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2005 16:23:47 -0000 > > . Something is wrong with the ed-driver (in my case -- > > Kingston's KNE-PC2T, FCC ID L40WST200). Kernel reports > > being unable to do something with pccard1, then reports > > ed1: .... > > and hangs. I let it wait for an hour and it never continued > > booting. I'll try to investigate, when I'm done installing. > > The card worked just fine in a newer Pentium-II laptop under > > FreeBSD-5.x > > If the card is a 16bit pcmcia car make sure the bridge is set to 16bit. How do I do that? > I had a similar problem on an old Thinkpad when trying to use a 32bit > cardbus nic while the bridge was set to default to 16bit in the BIOS. Both -- the hanging ed1 and the working wi0 are 16bit 5volt cards, according to their labeling. Prior to the ed1-hang, there is a message about 32 cfe allocation failure. > I don't see any advantage in using the partition-less mode. Less layers, and (slightly) more diskspace -- just feels neater, I guess. But the BIOS would not boot, so out with it in this case. > I wouldn't blame WITNESS on this. Laptops, especially old ones, have > incredibly slow disks. The buildworld process is heavily i/o bounded, > my bet is on the disk subsystem. According to systat and top, the CPU is never idle -- as would've been the case, if the I/O were the limiting factor. The Sys-component of `systat -vm' was steadily above 50%. Now that I have a witness-less kernel, the builds are, indeed, I/O bound. -mi From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 08:16: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 4627B16A41F for ; Wed, 31 Aug 2005 08:16:49 +0000 (GMT) (envelope-from stanley.jobson@gmx.ch) Received: from sigma.informatik.hu-berlin.de (sigma.informatik.hu-berlin.de [141.20.20.51]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA8EA43D45 for ; Wed, 31 Aug 2005 08:16:48 +0000 (GMT) (envelope-from stanley.jobson@gmx.ch) Received: from tyrael.linnet (p54BCCE31.dip.t-dialin.net [84.188.206.49]) (authenticated bits=0) by sigma.informatik.hu-berlin.de (8.13.4+Sun/8.13.4/INF-2.0-MA-SOLARIS-2.10) with ESMTP id j7V8GMjJ006730 for ; Wed, 31 Aug 2005 10:16:43 +0200 (CEST) Date: Wed, 31 Aug 2005 10:15:23 +0200 From: stanley jobson To: freebsd-current@freebsd.org Message-Id: <20050831101523.48a9f80a.stanley.jobson@gmx.ch> In-Reply-To: <20050831044823.N50961@geri.cc.fer.hr> References: <20050831044823.N50961@geri.cc.fer.hr> X-Mailer: Sylpheed version 1.0.5 (GTK+ 1.2.10; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Status: No (sigma) X-Spam-Status: No, score=1.8 required=5.0 tests=FORGED_RCVD_HELO, RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on rabe X-Mailman-Approved-At: Wed, 31 Aug 2005 12:26:09 +0000 Subject: Re: gjournal beta3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 08:16:49 -0000 hi, well done - as soon as i will get some spare time i will play around with it ... when will it find its way into the fbsd source tree ? regards, stan On Wed, 31 Aug 2005 04:54:20 +0200 (CEST) Ivan Voras wrote: > I'm happy to announce beta3 version of gjournal! The only reason I'm > not calling it "1.0 release" is that it hasn't received much testing > yet and there have been many changes since the last public beta, so I > still don't recommend it for production use. For all intents and > purposes > this is the final version (+/- bugfixes, of course :) ). > > The source is available at: > http://ivoras.sharanet.org/stuff/gjournal-beta3.tgz > (read the README file!) > > More information is available at: > http://wikitest.freebsd.org/moin.cgi/gjournal > > This work has been sponsored by Google's SoC project, which I thank. > Also thanks to menthors, Poul Henning Kamp and Pawel Jakub Dawidek. > > -- > Every sufficiently advanced magic is indistinguishable from technology > - Arthur C Anticlarke > > _______________________________________________ > 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" > -- "Perfection is achieved, not when there is nothing left to add, but when there is nothing left to take away." --- Antoine de St. Exupery, Wind, Sand, and Stars, 1939 From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 11:08:13 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 14ED616A41F for ; Wed, 31 Aug 2005 11:08:13 +0000 (GMT) (envelope-from sem@core.inec.ru) Received: from relay-er5.mbrd.ru (relay-er5.mbrd.ru [194.117.71.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0028B43D5A for ; Wed, 31 Aug 2005 11:08:11 +0000 (GMT) (envelope-from sem@core.inec.ru) Received: from msd.mbrd.ru ([172.16.4.9]) by relay-er5.mbrd.ru with esmtp (Exim 4.x) id 1EAQRs-0006Es-GT for freebsd-current@freebsd.org; Wed, 31 Aug 2005 15:08:08 +0400 Message-ID: <43158F98.7040704@core.inec.ru> Date: Wed, 31 Aug 2005 15:08:08 +0400 From: Sergey Matveychuk User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 31 Aug 2005 12:26:09 +0000 Subject: panic right now in 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: Wed, 31 Aug 2005 11:08:13 -0000 I've just got a panic when run tinderbox on my test 6.0 box. It's a day before BETA3. Here is details: Tracing pid 53094 tid 100125 td 0xc19c8190 kdb_enter(c070076b,c075a380,c06ff31a,d11a496c,100) at kdb_enter+0x30 panic(c06ff31a,c177204c,c2d71018,c2d71000,c0606a03) at panic+0xd5 lockmgr(c2675af8,2002,c2675b1c,c19c8190,d11a49c0) at lockmgr+0x42d vop_stdlock(d11a49f0,c19c8190,2002,c2675aa0,d11a4a0c) at vop_stdlock+0x2f VOP_LOCK_APV(c0738d00,d11a49f0,c2607bb0,d11a49ec,c058bd42) at VOP_LOCK_APV+0x54 vn_lock(c2675aa0,2002,c19c8190,4,d11a4a40) at vn_lock+0x13c vrele(c2675aa0,0,c22af76e,27c,c2675aa0) at vrele+0x10c null_reclaim(d11a4a94,d11a4ac0,c0597d8f,c22b0a40,d11a4a94) at null_reclaim+0x7b VOP_RECLAIM_APV(c22b0a40,d11a4a94,c19c8190,0,0) at VOP_RECLAIM_APV+0x3e vgonel(c2837880,d11a4b78,c05a5ef1,c19c8190,60) at vgonel+0x25f vrecycle(c2837880,c19c8190,d11a4b00,c06e7fde,d11a4b1c) at vrecycle+0x76 null_inactive(d11a4b1c,d11a4b30,c0597262,c22b0a40,d11a4b1c) at null_inactive+0x25 VOP_INACTIVE_APV(c22b0a40,d11a4b1c,0,d11a4b24,c22af511) at VOP_INACTIVE_APV+0x3e vinactive(c2837880,c19c8190,0,0,11ad3b1) at vinactive+0x82 vput(c2837880,ffffffdf,c236ea00,0,c19c8190) at vput+0x18f kern_lstat(c19c8190,8055240,0,d11a4c68,0) at kern_lstat+0xb3 lstat(c19c8190,d11a4d04,8,d11a4d2c,c05535e6) at lstat+0x2f syscall(3b,3b,3b,8055200,8055244) at syscall+0x340 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (190, FreeBSD ELF32, lstat), eip = 0x280acde8, esp = 0xbfbf73a4, ebp = 0xbfbf7430 --- -- Sem. From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 12:29: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 C0B0916A41F for ; Wed, 31 Aug 2005 12:29:46 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from efnet-math.org (efnet-math.org [69.60.109.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DBE343D53 for ; Wed, 31 Aug 2005 12:29:46 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from [192.168.1.5] (host191-173.pool8259.interbusiness.it [82.59.173.191]) (authenticated bits=0) by efnet-math.org (8.13.1/8.13.1) with ESMTP id j7VCTdB6019161 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 31 Aug 2005 08:29:41 -0400 In-Reply-To: <43158F98.7040704@core.inec.ru> References: <43158F98.7040704@core.inec.ru> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <73418676-5CB7-47BE-8BED-387E98A1705B@FreeBSD.org> Content-Transfer-Encoding: 7bit From: Suleiman Souhlal Date: Wed, 31 Aug 2005 14:29:33 +0200 To: Sergey Matveychuk X-Mailer: Apple Mail (2.733) Cc: freebsd-current@FreeBSD.org Subject: Re: panic right now in 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: Wed, 31 Aug 2005 12:29:46 -0000 Hi, On Aug 31, 2005, at 1:08 PM, Sergey Matveychuk wrote: > I've just got a panic when run tinderbox on my test 6.0 box. > It's a day before BETA3. > > Here is details: > Tracing pid 53094 tid 100125 td 0xc19c8190 > kdb_enter(c070076b,c075a380,c06ff31a,d11a496c,100) at kdb_enter+0x30 > panic(c06ff31a,c177204c,c2d71018,c2d71000,c0606a03) at panic+0xd5 > lockmgr(c2675af8,2002,c2675b1c,c19c8190,d11a49c0) at lockmgr+0x42d > vop_stdlock(d11a49f0,c19c8190,2002,c2675aa0,d11a4a0c) at vop_stdlock > +0x2f > VOP_LOCK_APV(c0738d00,d11a49f0,c2607bb0,d11a49ec,c058bd42) at > VOP_LOCK_APV+0x54 > vn_lock(c2675aa0,2002,c19c8190,4,d11a4a40) at vn_lock+0x13c > vrele(c2675aa0,0,c22af76e,27c,c2675aa0) at vrele+0x10c > null_reclaim(d11a4a94,d11a4ac0,c0597d8f,c22b0a40,d11a4a94) at > null_reclaim+0x7b > VOP_RECLAIM_APV(c22b0a40,d11a4a94,c19c8190,0,0) at VOP_RECLAIM_APV > +0x3e > vgonel(c2837880,d11a4b78,c05a5ef1,c19c8190,60) at vgonel+0x25f > vrecycle(c2837880,c19c8190,d11a4b00,c06e7fde,d11a4b1c) at vrecycle > +0x76 > null_inactive(d11a4b1c,d11a4b30,c0597262,c22b0a40,d11a4b1c) at > null_inactive+0x25 > VOP_INACTIVE_APV(c22b0a40,d11a4b1c,0,d11a4b24,c22af511) at > VOP_INACTIVE_APV+0x3e > vinactive(c2837880,c19c8190,0,0,11ad3b1) at vinactive+0x82 > vput(c2837880,ffffffdf,c236ea00,0,c19c8190) at vput+0x18f > kern_lstat(c19c8190,8055240,0,d11a4c68,0) at kern_lstat+0xb3 > lstat(c19c8190,d11a4d04,8,d11a4d2c,c05535e6) at lstat+0x2f > syscall(3b,3b,3b,8055200,8055244) at syscall+0x340 > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (190, FreeBSD ELF32, lstat), eip = 0x280acde8, esp = > 0xbfbf73a4, ebp = 0xbfbf7430 --- Can you try http://people.freebsd.org/~ssouhlal/testing/ null_vnops.c-20050831.diff ? -- Suleiman Souhlal | ssouhlal@vt.edu The FreeBSD Project | ssouhlal@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 12:48:58 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 8C81116A41F for ; Wed, 31 Aug 2005 12:48:58 +0000 (GMT) (envelope-from dominique.goncalves@gmail.com) Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC5D143D45 for ; Wed, 31 Aug 2005 12:48:57 +0000 (GMT) (envelope-from dominique.goncalves@gmail.com) Received: by nproxy.gmail.com with SMTP id x4so41560nfb for ; Wed, 31 Aug 2005 05:48:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=ZKVY5oF0r+f17gInOTCwZ2olplRvFnfeLHyQu1LWjGEy9vQxNJ3Y25QBQepKh1eLngdEQdlJpEWOHz72gyWaIqBKvhiTQOwR1fzxCVxdjFK9wvFTBhQtkCW4Qnz+tuQLSyRbHfpOV/IwqBTJxAiphm9+h6vpmEz0kOL7P7dWewM= Received: by 10.48.248.10 with SMTP id v10mr46883nfh; Wed, 31 Aug 2005 05:48:56 -0700 (PDT) Received: by 10.49.1.1 with HTTP; Wed, 31 Aug 2005 05:48:56 -0700 (PDT) Message-ID: <7daacbbe05083105486887f43e@mail.gmail.com> Date: Wed, 31 Aug 2005 14:48:56 +0200 From: Dominique Goncalves To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: make distribution fails with RELENG_6 on a 5.4-RELEASE-p6 host X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 12:48:58 -0000 Hi, I'm trying to create a livecd with freesbie2 [1] with RELENG_6 source on FreeBSD 5.4-RELEASE-p6, but the make distribution fails: =3D=3D=3D> etc/sendmail (install) cd /net/FreeBSD/RELENG_6/src/etc/../share/man; /usr/obj/net/FreeBSD/RELENG_6/src/make.i386/make makedb makewhatis /net/FreeBSD/freesbie-fs/usr/share/man makewhatis /net/FreeBSD/freesbie-fs/usr/share/openssl/man rm -rf /tmp/install.52xkwmMp cd /net/FreeBSD/RELENG_6/src/etc; install -o root -g wheel -m 644 amd.map apmd.conf auth.conf crontab csh.cshrc csh.login csh.logout devd.conf devfs.conf dhclient.conf disktab fbtab ftpusers gettytab group hosts hosts.allow hosts.equiv hosts.lpd inetd.conf login.access login.conf mac.conf motd netconfig network.subr networks newsyslog.conf portsnap.conf pf.conf pf.os phones profile protocols rc rc.bsdextended rc.firewall rc.firewall6 rc.initdiskless rc.sendmail rc.shutdown rc.subr remote rpc services shells snmpd.config sysctl.conf syslog.conf usbd.conf etc.i386/ttys /net/FreeBSD/RELENG_6/src/etc/../gnu/usr.bin/man/manpath/manpath.config /net/FreeBSD/RELENG_6/src/etc/../usr.bin/mail/misc/mail.rc /net/FreeBSD/RELENG_6/src/etc/../usr.bin/locate/locate/locate.rc printcap /net/FreeBSD/freesbie-fs/etc; cap_mkdb -l /net/FreeBSD/freesbie-fs/etc/login.conf; install -o root -g wheel -m 755 netstart pccard_ether rc.suspend rc.resume /net/FreeBSD/freesbie-fs/etc; install -o root -g wheel -m 600 master.passwd nsmb.conf opieaccess /net/FreeBSD/freesbie-fs/etc; pwd_mkdb -L -p -d /net/FreeBSD/freesbie-fs/etc /net/FreeBSD/freesbie-fs/etc/master.passwd cap_mkdb: illegal option -- l usage: cap_mkdb [-v] [-f outfile] file [file ...] *** Error code 1 Regards [1] http://lists.freebsd.org/pipermail/freebsd-current/2005-August/054993.h= tml --=20 There's this old saying: "Give a man a fish, feed him for a day. Teach a man to fish, feed him for life." From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 12:49: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 AC26A16A420 for ; Wed, 31 Aug 2005 12:49:18 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5197843D46 for ; Wed, 31 Aug 2005 12:49:18 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id j7VCnDAP072497; Wed, 31 Aug 2005 07:49:17 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <4315A757.5020108@centtech.com> Date: Wed, 31 Aug 2005 07:49:27 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.10) Gecko/20050815 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Daniel O'Connor" References: <1125452228.740.3.camel@arbitor.homelinux.com> <47d0403c05083020044f6ac0be@mail.gmail.com> <200508311306.46876.doconnor@gsoft.com.au> In-Reply-To: <200508311306.46876.doconnor@gsoft.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/1049/Wed Aug 31 02:19:01 2005 on mh1.centtech.com X-Virus-Status: Clean Cc: freebsd-current@freebsd.org Subject: Re: panic after removing usb flash drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 12:49:18 -0000 Daniel O'Connor wrote: > On Wednesday 31 August 2005 12:34, Ben Kaduk wrote: > >>Of course, if you did unmount the filesystem before pulling the drive, then >>this shoule be looked into. > > > IMHO it would be really nice if you could tell the kernel that it should just > ditch the data (and whine to the log file) instead of panicing. > > For your "main" file systems the panic approach is sensible, but for removable > things it's more likely to cause data loss I think (because the panic could > eat data on your other drives). > > Although last time I saw this discussed I came away with the impression that > it wasn't possible for the kernel to do this..? (without substantial work > anyway) > Why not just use the automounter to mount/umount this for you? This probably won't get around umounting while in use, but you might be able to tell amd to use a umount -f on it. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 13:00: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 6DC6E16A41F for ; Wed, 31 Aug 2005 13:00:43 +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 8AF1443D5C for ; Wed, 31 Aug 2005 13:00:40 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp215-145.lns1.adl2.internode.on.net [203.122.215.145]) (authenticated bits=0) by cain.gsoft.com.au (8.13.4/8.13.4) with ESMTP id j7VD0TM7002205 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 31 Aug 2005 22:30:36 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Eric Anderson Date: Wed, 31 Aug 2005 22:30:12 +0930 User-Agent: KMail/1.8.1 References: <1125452228.740.3.camel@arbitor.homelinux.com> <200508311306.46876.doconnor@gsoft.com.au> <4315A757.5020108@centtech.com> In-Reply-To: <4315A757.5020108@centtech.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3010421.UUNVzW7rWS"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200508312230.20301.doconnor@gsoft.com.au> X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.51 on 203.31.81.10 Cc: freebsd-current@freebsd.org Subject: Re: panic after removing usb flash drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 13:00:43 -0000 --nextPart3010421.UUNVzW7rWS Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 31 August 2005 22:19, Eric Anderson wrote: > > Although last time I saw this discussed I came away with the impression > > that it wasn't possible for the kernel to do this..? (without substanti= al > > work anyway) > > Why not just use the automounter to mount/umount this for you? This > probably won't get around umounting while in use, but you might be able > to tell amd to use a umount -f on it. I would have thought you'd still get a panic anyway..? The VM will try and flush the dirty pages when you umount and consequently= =20 panic. =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 --nextPart3010421.UUNVzW7rWS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBDFank5ZPcIHs/zowRAkvfAJ96Lnl3gz3nms2U651SxEUFqEDPswCfQmDZ eMx15OQsxvaeLdag8xvKCyU= =YPSq -----END PGP SIGNATURE----- --nextPart3010421.UUNVzW7rWS-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 13:02:38 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 A8B7916A421; Wed, 31 Aug 2005 13:02:38 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2672243D55; Wed, 31 Aug 2005 13:02:36 +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 postfix4-1.free.fr (Postfix) with ESMTP id EF57A319FB5; Wed, 31 Aug 2005 15:02:35 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 4868C4080; Wed, 31 Aug 2005 15:02:54 +0200 (CEST) Date: Wed, 31 Aug 2005 15:02:54 +0200 From: Jeremie Le Hen To: Suleiman Souhlal Message-ID: <20050831130254.GF659@obiwan.tataz.chchile.org> References: <20050830124435.GW659@obiwan.tataz.chchile.org> <20050830232818.GA83944@xor.obsecurity.org> <66A71CA4-8134-43A3-BEAB-485C7DF59EA1@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <66A71CA4-8134-43A3-BEAB-485C7DF59EA1@FreeBSD.org> User-Agent: Mutt/1.5.9i Cc: freebsd-current@FreeBSD.org, Matthias Andree , Jeremie Le Hen , Kris Kennaway Subject: Re: nfs through nullfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 13:02:38 -0000 Hi Suleiman, > Can you try the patch at http://people.freebsd.org/~ssouhlal/testing/ > null_vnops.c-20050831.diff ? Thanks. I'll give a try to this patch later today if I can find some time. I will test it tomorrow otherwise. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 13:08:45 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 8FA8316A41F for ; Wed, 31 Aug 2005 13:08:45 +0000 (GMT) (envelope-from ivoras@fer.hr) Received: from geri.cc.fer.hr (geri.cc.fer.hr [161.53.72.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id E4EAB43D60 for ; Wed, 31 Aug 2005 13:08:41 +0000 (GMT) (envelope-from ivoras@fer.hr) Received: from geri.cc.fer.hr (localhost.cc.fer.hr [127.0.0.1]) by geri.cc.fer.hr (8.13.3/8.13.1) with ESMTP id j7VD7MUS059579 for ; Wed, 31 Aug 2005 15:07:22 +0200 (CEST) (envelope-from ivoras@fer.hr) Received: from localhost (ivoras@localhost) by geri.cc.fer.hr (8.13.3/8.13.1/Submit) with ESMTP id j7VD7M1O059576 for ; Wed, 31 Aug 2005 15:07:22 +0200 (CEST) (envelope-from ivoras@fer.hr) X-Authentication-Warning: geri.cc.fer.hr: ivoras owned process doing -bs Date: Wed, 31 Aug 2005 15:07:22 +0200 (CEST) From: Ivan Voras Sender: ivoras@geri.cc.fer.hr To: current@freebsd.org Message-ID: <20050831150412.E59551@geri.cc.fer.hr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Re: gjournal beta3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 13:08:45 -0000 stanley jobson wrote: > when will it find its way into the fbsd source tree ? That's not upto me, but I wouldn't recommend it before it gets some more serious testing. (I'll reformat it in style(9) when that happens, also) -- Every sufficiently advanced magic is indistinguishable from technology - Arthur C Anticlarke From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 13:12: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 EEF9216A41F for ; Wed, 31 Aug 2005 13:12:20 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix4-2.free.fr (postfix4-2.free.fr [213.228.0.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 902B343D46 for ; Wed, 31 Aug 2005 13:12:20 +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 postfix4-2.free.fr (Postfix) with ESMTP id 81E4C323404; Wed, 31 Aug 2005 15:12:17 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id B95F2405A; Wed, 31 Aug 2005 15:12:35 +0200 (CEST) Date: Wed, 31 Aug 2005 15:12:35 +0200 From: Jeremie Le Hen To: Stay d Message-ID: <20050831131235.GG659@obiwan.tataz.chchile.org> References: <20050830161001.343DD4E704@pipa.profix.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050830161001.343DD4E704@pipa.profix.cz> User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org Subject: Re: Application layer firewall on FreeBSD, is it possible ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 13:12:21 -0000 Hi, [ this is not the correct list ask this kind of question, please use -net@ ] > let me ask you for task "how to control p2p applications and their traffic > with dynamic ports from user?s commputers on gateway". > > We are small wireless community and have shared access to internet for all > members. Core members decided to control p2p traffic by default and to allow > each person in individual way, > after showing their knowledge of authorial low. :) > > But since many dc hubs, edonkey servers, bittorents web trackers and so on > use dynamic not standard ports, how to control it ? > > Linux use l7-filter http://sourceforge.net/projects/l7-filter sourceforge > freeware and , it is based on iptables, defination application protocols > like ethereal project do. > > So, is there any way to do same application layer osi model firewall with > FreeBSD gateway ? > > Of course, I tried to find on web, I have not been successful in searching > so far. No this is not possible and not indented to be someday. See this these messages for answers : http://lists.freebsd.org/pipermail/freebsd-pf/2005-July/001227.html http://lists.freebsd.org/pipermail/freebsd-pf/2005-July/001262.html http://lists.freebsd.org/pipermail/freebsd-pf/2005-July/001287.html http://lists.freebsd.org/pipermail/freebsd-pf/2005-July/001288.html And this thread : http://lists.freebsd.org/pipermail/freebsd-ipfw/2004-March/thread.html#996 Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 13:13: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 A514516A41F for ; Wed, 31 Aug 2005 13:13:23 +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 4BB2A43D45 for ; Wed, 31 Aug 2005 13:13:23 +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 j7VDDMVP051828; Wed, 31 Aug 2005 08:13:22 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <4315AD00.70809@centtech.com> Date: Wed, 31 Aug 2005 08:13:36 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.10) Gecko/20050815 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Daniel O'Connor" References: <1125452228.740.3.camel@arbitor.homelinux.com> <200508311306.46876.doconnor@gsoft.com.au> <4315A757.5020108@centtech.com> <200508312230.20301.doconnor@gsoft.com.au> In-Reply-To: <200508312230.20301.doconnor@gsoft.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: panic after removing usb flash drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 13:13:23 -0000 Daniel O'Connor wrote: > On Wednesday 31 August 2005 22:19, Eric Anderson wrote: > >>>Although last time I saw this discussed I came away with the impression >>>that it wasn't possible for the kernel to do this..? (without substantial >>>work anyway) >> >>Why not just use the automounter to mount/umount this for you? This >>probably won't get around umounting while in use, but you might be able >>to tell amd to use a umount -f on it. > > > I would have thought you'd still get a panic anyway..? > The VM will try and flush the dirty pages when you umount and consequently > panic. My thinking was that amd would auto-unmount the filesystem when it isn't being used, and if the timeout is set low (I think the default is 5 minutes), then once done using the flash, it would have time to umount before it was unplugged. Now that I think about it though, if he is using it (and open files), it won't even attempt to unmount it anyhow. This is where I think it would be great to have a sort of 'flashfs' - something like a UFS2 filesystem, but read only until a write happens, and all writes would be synchronous, and after the write occurs, the fs goes back to a 'read only' state. Maybe this could be done with gjournal or even unionfs - mount the usb flash read only, do all writes to a memory backed disk, and then flush the writes out to the usb flash periodically. Not perfect, but maybe this will stir some ideas up. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 13: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 8988516A420 for ; Wed, 31 Aug 2005 13:25:51 +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 35B8C43D48 for ; Wed, 31 Aug 2005 13:25:47 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp215-145.lns1.adl2.internode.on.net [203.122.215.145]) (authenticated bits=0) by cain.gsoft.com.au (8.13.4/8.13.4) with ESMTP id j7VDPZTA002372 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 31 Aug 2005 22:55:42 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Eric Anderson Date: Wed, 31 Aug 2005 22:55:25 +0930 User-Agent: KMail/1.8.1 References: <1125452228.740.3.camel@arbitor.homelinux.com> <200508312230.20301.doconnor@gsoft.com.au> <4315AD00.70809@centtech.com> In-Reply-To: <4315AD00.70809@centtech.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1804758.TfUzCiH1id"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200508312255.26347.doconnor@gsoft.com.au> X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.51 on 203.31.81.10 Cc: freebsd-current@freebsd.org Subject: Re: panic after removing usb flash drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 13:25:51 -0000 --nextPart1804758.TfUzCiH1id Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 31 August 2005 22:43, Eric Anderson wrote: > This is where I think it would be great to have a sort of 'flashfs' - > something like a UFS2 filesystem, but read only until a write happens, > and all writes would be synchronous, and after the write occurs, the fs > goes back to a 'read only' state. Maybe this could be done with > gjournal or even unionfs - mount the usb flash read only, do all writes > to a memory backed disk, and then flush the writes out to the usb flash > periodically. Not perfect, but maybe this will stir some ideas up. I think if you can differentiate behaviour for normal file systems based on= =20 some information about the device then it would be good. ie if it is a removable type device the default behaviour would be to disab= le=20 write caching and mount it synchronously. Coupled with a kernel that is=20 willing to throw away pages dirtied on such a volume you would be able to=20 readily hot plug a device without too much worry about data loss. =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 --nextPart1804758.TfUzCiH1id Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBDFa/G5ZPcIHs/zowRAtmmAJ96qePIPxCmvHLnZnwbwiwtx/DhQwCePKxx xXuxitNE+QkniUwVFhwI9m8= =tpzq -----END PGP SIGNATURE----- --nextPart1804758.TfUzCiH1id-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 13:49: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 0A04816A41F for ; Wed, 31 Aug 2005 13:49:36 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C02943D46 for ; Wed, 31 Aug 2005 13:49:32 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id j7VDnSvp020746; Wed, 31 Aug 2005 17:49:28 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id j7VDnSt7020745; Wed, 31 Aug 2005 17:49:28 +0400 (MSD) (envelope-from yar) Date: Wed, 31 Aug 2005 17:49:27 +0400 From: Yar Tikhiy To: Gavin Atkinson Message-ID: <20050831134927.GA20529@comp.chem.msu.su> References: <1125487485.34476.6.camel@buffy.york.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1125487485.34476.6.camel@buffy.york.ac.uk> User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org Subject: Re: 6.0BETA3 panic in ip_output (vlan/RIP related?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2005 13:49:36 -0000 On Wed, Aug 31, 2005 at 12:24:45PM +0100, Gavin Atkinson wrote: > > I've just managed to panic an amd64 machine running 6.0BETA3. > > wiggum# ifconfig vlan76 destroy > wiggum# Aug 31 12:02:48 wiggum routed[244]: IP_DROP_MEMBERSHIP ALLHOSTS: Can't assign requested address > wiggum# > wiggum# ifconfig vlan76 create > wiggum# ifconfig vlan76 vlan 76 vlandev bge0 > wiggum# ifconfig vlan76 inet x.y.76.59 netmask 255.255.254.0 > > > Fatal trap 9: general protection fault while in kernel mode > cpuid = 0; apic id = 00 > instruction pointer = 0x8:0xffffffff80429420 > stack pointer = 0x10:0xffffffffb260b600 > frame pointer = 0x10:0xffffffffb260b710 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 244 (routed) Thanks for reporting this! The problem seems known and has to do with a deficiency in our multicast code WRT interface removal/re-insertion. It is on the to-do list of our networking gurus and hopefully will be dealt with RSN, after IP multicast code locking and cleanup are complete. -- Yar From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 13:58:26 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 68F1A16A41F for ; Wed, 31 Aug 2005 13:58:26 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7469543D55 for ; Wed, 31 Aug 2005 13:58:25 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id j7VDwMdX021026; Wed, 31 Aug 2005 17:58:23 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id j7VDwM3b021025; Wed, 31 Aug 2005 17:58:22 +0400 (MSD) (envelope-from yar) Date: Wed, 31 Aug 2005 17:58:22 +0400 From: Yar Tikhiy To: Gavin Atkinson Message-ID: <20050831135822.GB20529@comp.chem.msu.su> References: <1125487485.34476.6.camel@buffy.york.ac.uk> <20050831134927.GA20529@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050831134927.GA20529@comp.chem.msu.su> User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org Subject: Re: 6.0BETA3 panic in ip_output (vlan/RIP related?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2005 13:58:26 -0000 On Wed, Aug 31, 2005 at 05:49:27PM +0400, Yar Tikhiy wrote: > > Thanks for reporting this! The problem seems known and has > to do with a deficiency in our multicast code WRT interface > removal/re-insertion. It is on the to-do list of our networking > gurus and hopefully will be dealt with RSN, after IP multicast > code locking and cleanup are complete. BTW, there is a number of PR's related to this issue. Here are their numbers for reference: kern/77665 kern/78227 kern/82882 -- Yar From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 14:54: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 8F3C216A41F; Wed, 31 Aug 2005 14:54:46 +0000 (GMT) (envelope-from setantae@submonkey.net) Received: from shrike.submonkey.net (cpc2-cdif2-3-1-cust208.cdif.cable.ntl.com [82.31.78.208]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C20443D46; Wed, 31 Aug 2005 14:54:45 +0000 (GMT) (envelope-from setantae@submonkey.net) Received: from setantae by shrike.submonkey.net with local (Exim 4.52 (FreeBSD)) id 1EATzB-000Lgr-8q; Wed, 31 Aug 2005 15:54:45 +0100 Date: Wed, 31 Aug 2005 15:54:45 +0100 From: Ceri Davies To: Giorgos Keramidas Message-ID: <20050831145445.GC69728@submonkey.net> Mail-Followup-To: Ceri Davies , Giorgos Keramidas , Matthew Seaman , freebsd-current@freebsd.org References: <20050830153242.GA74299@submonkey.net> <20050831134138.GD9292@lack-of-gravitas.thebunker.net> <20050831135319.GB88117@orion.daedalusnetworks.priv> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bKyqfOwhbdpXa4YI" Content-Disposition: inline In-Reply-To: <20050831135319.GB88117@orion.daedalusnetworks.priv> X-PGP: finger ceri@FreeBSD.org User-Agent: Mutt/1.5.10i Sender: Ceri Davies Cc: Matthew Seaman , freebsd-current@freebsd.org Subject: Re: Setting HTTP_PROXY for all users X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 14:54:46 -0000 --bKyqfOwhbdpXa4YI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 31, 2005 at 04:53:19PM +0300, Giorgos Keramidas wrote: > ## Thread moved here from -questions. >=20 > On 2005-08-31 14:41, Matthew Seaman wro= te: > >On Tue, Aug 30, 2005 at 04:32:42PM +0100, Ceri Davies wrote: > >> I want to set HTTP_PROXY for all users on my machine, and I'd like to = do > >> it in /etc/login.conf as then it's only in one place. > >> > >> However, I need to put a colon in for the port number and can't see how > >> to escape it so that the entry doesn't get chopped off halfway through. > >> None of these work: > >> > >> :setenv=3DHTTP_PROXY=3Dwww-cache.private.submonkey.net:3128:\ > >> > >> :setenv=3DHTTP_PROXY=3Dwww-cache.private.submonkey.net\:3128:\ > >> > >> :setenv=3DHTTP_PROXY=3D"www-cache.private.submonkey.net:3128":\ > >> > >> Is there a way to do this, or should I just throw this in /etc/profile > >> and /etc/csh.cshrc instead? > > > > \c generates a colon. Documented in getcap(3) >=20 > Hmmm, I think this should also be documented in the login.conf file, > with a comment and a pointer to getcap(3) manpage. Any objections to > the following patch? Looks good. Ceri --=20 Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. -- Einstein (attrib.) --bKyqfOwhbdpXa4YI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDFcS1ocfcwTS3JF8RAriiAKCKGV/euCLHAR1+/aQ7pOvUaxvvwgCgonwz 4+cTOasHsaNfN37BENU0n3s= =2j1E -----END PGP SIGNATURE----- --bKyqfOwhbdpXa4YI-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 15:07: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 676CC16A41F for ; Wed, 31 Aug 2005 15:07:54 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix4-2.free.fr (postfix4-2.free.fr [213.228.0.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE7AF43D46 for ; Wed, 31 Aug 2005 15:07:53 +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 postfix4-2.free.fr (Postfix) with ESMTP id 00FBD3234D7; Wed, 31 Aug 2005 17:07:53 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 5EBC1405A; Wed, 31 Aug 2005 17:08:11 +0200 (CEST) Date: Wed, 31 Aug 2005 17:08:11 +0200 From: Jeremie Le Hen To: Dominique Goncalves Message-ID: <20050831150811.GL659@obiwan.tataz.chchile.org> References: <7daacbbe05083105486887f43e@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7daacbbe05083105486887f43e@mail.gmail.com> User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org Subject: Re: make distribution fails with RELENG_6 on a 5.4-RELEASE-p6 host X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 15:07:54 -0000 > I'm trying to create a livecd with freesbie2 [1] with RELENG_6 source > on FreeBSD 5.4-RELEASE-p6, > but the make distribution fails: > > ===> etc/sendmail (install) > cd /net/FreeBSD/RELENG_6/src/etc/../share/man; > /usr/obj/net/FreeBSD/RELENG_6/src/make.i386/make makedb > makewhatis /net/FreeBSD/freesbie-fs/usr/share/man > makewhatis /net/FreeBSD/freesbie-fs/usr/share/openssl/man > rm -rf /tmp/install.52xkwmMp > cd /net/FreeBSD/RELENG_6/src/etc; install -o root -g wheel -m 644 > amd.map apmd.conf auth.conf crontab csh.cshrc csh.login csh.logout > devd.conf devfs.conf dhclient.conf disktab fbtab ftpusers gettytab > group hosts hosts.allow hosts.equiv hosts.lpd inetd.conf > login.access login.conf mac.conf motd netconfig network.subr networks > newsyslog.conf portsnap.conf pf.conf pf.os phones profile protocols > rc rc.bsdextended rc.firewall rc.firewall6 rc.initdiskless > rc.sendmail rc.shutdown rc.subr remote rpc services shells > snmpd.config sysctl.conf syslog.conf usbd.conf etc.i386/ttys > /net/FreeBSD/RELENG_6/src/etc/../gnu/usr.bin/man/manpath/manpath.config > /net/FreeBSD/RELENG_6/src/etc/../usr.bin/mail/misc/mail.rc > /net/FreeBSD/RELENG_6/src/etc/../usr.bin/locate/locate/locate.rc > printcap /net/FreeBSD/freesbie-fs/etc; cap_mkdb -l > /net/FreeBSD/freesbie-fs/etc/login.conf; install -o root -g wheel -m > 755 netstart pccard_ether rc.suspend rc.resume > /net/FreeBSD/freesbie-fs/etc; install -o root -g wheel -m 600 > master.passwd nsmb.conf opieaccess /net/FreeBSD/freesbie-fs/etc; > pwd_mkdb -L -p -d /net/FreeBSD/freesbie-fs/etc > /net/FreeBSD/freesbie-fs/etc/master.passwd > cap_mkdb: illegal option -- l > usage: cap_mkdb [-v] [-f outfile] file [file ...] > *** Error code 1 You are supposed to make buildworld first, as stated in src/UPDATING. Otherwise, Warner Losh recently fixed this in CURRENT [1], I hope he will MFC this before RELEASE. You can manually patch your sources. Regards, [1] http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/Makefile.diff?r1=1.346&r2=1.347 -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 15:38: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 0FCD016A41F for ; Wed, 31 Aug 2005 15:38:37 +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 403D543D49 for ; Wed, 31 Aug 2005 15:38:33 +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.3/8.13.3) with ESMTP id j7VFq9po007322; Wed, 31 Aug 2005 09:52:10 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4315CEEC.80100@samsco.org> Date: Wed, 31 Aug 2005 09:38:20 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Kaduk References: <1125452228.740.3.camel@arbitor.homelinux.com> <47d0403c05083020044f6ac0be@mail.gmail.com> In-Reply-To: <47d0403c05083020044f6ac0be@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: freebsd-current@freebsd.org, Kyle Brooks Subject: Re: panic after removing usb flash drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 15:38:37 -0000 Ben Kaduk wrote: > On 8/31/05, Kyle Brooks wrote: > >>umass0: LEXAR MEDIA JUMPDRIVE2, rev 2.00/1.25, addr 2 >>umass0: at uhub4 port 6 (addr 2) disconnected >>panic: vm_fault: fault on nofault entry, addr: deadc000 >> >>kernel: >> >>FreeBSD 7.0-CURRENT #2: Mon Aug 29 00:39:21 UTC 2005 >> >>problem: >> >>kernel panics when usb flash drive is removed >> >>backtrace: >> >>#0 doadump () at pcpu.h:165 >>#1 0xc068610e in boot (howto=260) >>at /usr/src/sys/kern/kern_shutdown.c:397 >>#2 0xc0685b92 in panic ( >>fmt=0xc090e46c "vm_fault: fault on nofault entry, addr: %lx") >>at /usr/src/sys/kern/kern_shutdown.c:553 >>#3 0xc0812de1 in vm_fault (map=0xc1060000, vaddr=3735928832, >>fault_type=2 '\002', fault_flags=0) >>at /usr/src/sys/vm/vm_fault.c:884 >>#4 0xc0888807 in trap_pfault (frame=0xe6a06bf0, usermode=0, >>eva=3735929110) >>at /usr/src/sys/i386/i386/trap.c:741 >>#5 0xc0888d04 in trap (frame= >>{tf_fs = 8, tf_es = -1063649240, tf_ds = 40, tf_edi = -993875968, >>tf_esi = -1014223872, tf_ebp = -425694000, tf_isp = -425694180, tf_ebx = >>-1063640044, tf_edx = -993875900, tf_ecx = 0, tf_eax = -559038242, >>tf_trapno = 12, tf_err = 2, tf_eip = -1069194040, tf_cs = 32, tf_eflags >>= 66050, tf_esp = -1063640032, tf_ss = 0}) >>at /usr/src/sys/i386/i386/trap.c:442 >>#6 0xc08745ba in calltrap () at /usr/src/sys/i386/i386/exception.s:139 >>#7 0x00000008 in ?? () >>#8 0xc09a0028 in atdma_acpi_driver_mod () >>#9 0x00000028 in ?? () >>#10 0xc4c2a800 in ?? () >>#11 0xc38c2c00 in ?? () >>#12 0xe6a06cd0 in ?? () >>#13 0xe6a06c1c in ?? () >>---Type to continue, or q to quit--- >>#14 0xc09a2414 in xsoftc () >>#15 0xc4c2a844 in ?? () >>#16 0x00000000 in ?? () >>#17 0xdeadc0de in ?? () >>#18 0x0000000c in ?? () >>#19 0x00000002 in ?? () >>#20 0xc04564c8 in camisr (V_queue=0xc09a2414) >>at /usr/src/sys/cam/cam_xpt.c:7066 >>#21 0xc066f84e in ithread_loop (arg=0xc356fa80) >>at /usr/src/sys/kern/kern_intr.c:545 >>#22 0xc066e808 in fork_exit (callout=0xc066f665 , arg=0x0, >>frame=0x0) at /usr/src/sys/kern/kern_fork.c:789 >>#23 0xc087461c in fork_trampoline () >>at /usr/src/sys/i386/i386/exception.s:208 >> > > This is the expected behaviour Panics are not acceptable or expected behaviour in any situation, btw. > if you didn't unmount the filesystem on the > thumbdrive before removing it. There was some discussion on this a while ago > (but I don't seem to be able to find the exact posts), but the general idea > is that the kernel has no idea in what state the actual physical medium > (disc) is/was in after being pulled, and may have some stale buffers holding > data that got written to disk. It doesn't know what to do with this data, or > how to treat requests to that device, so it panics. > I probably missed the earlier discussion that you are referring to, but what you are saying here actually isn't true. There are a number of problems: 1) When the thumbdrive gets pulled, the umass driver gets told to detach. It tries to detach itself from CAM, but things don't get torn down correctly because there is an open reference to the target in CAM (because there is a mounted filesystem on the device). umass truddles along anyways and goes away, leaving lots of dangling pointers in CAM that blow up on the next attempted I/O access. Part of the problem here is that the umass driver is architected wrong. It creates a SIM, bus, and target instance for every umass device that gets inserted. When the device gets pulled, it tries to tear down each of those instances all at once. CAM simply wasn't designed for this. It was designed for the SIMs and buses to be long-lived objects where only the targets (and luns) come and go. Making umass fit this model would invlove turning it into two logical drivers. One would be a SIM that would attach to the root hub instance of each USB controller and would treat the USB bus as a CAM bus. The other would be a target driver that gets created and destroyed on a per-device basis as those devices come and go. When a umass device gets plugged in, the USB framework would tell the apprpriate SIM to create a target instance. When the device gets pulled, the framework would tell the SIM to detach and destroy the target. No dangling pointers would be left behind by the SIM going away. I have some prototype work in progress on this. 2) Some filesystems, UFS in particular, assume that an I/O will never fail. Instead of checking the error status of the buf on completion, they just continue on and assume that everything is fine. If the VM is trying to page in a vnode, for example, it'll think that the operation succeeded, and then really bad things will happen. I'm not sure if the same problem exists in MSDOSFS because I don't have any DOS filesystems except on USB, and the problem with umass stands in the way of further testing. In luei of fixing umass, I might have to create a synthetic md device to hold a msdos filesystem so that I can test how it behaves. 3) It's unknown if the VM system knows how to rationally deal with failed I/O or how to propagate that kind of failure to the rest of the kernel and/or applications. What happens if you mmap a file, and then the device holding the file goes away? How do you let the application know that its mmap is now invalid? Send it a Sig11, maybe? How should the vnode pager deal with failure? There are lots of interesting problems here. In any case, the panic posted in the grandparent message implicates CAM and umass, which is what I would expect. There may be more layers of problems underneath it. Scott From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 16:48:30 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 C89DC16A41F for ; Wed, 31 Aug 2005 16:48:30 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4837F43D48 for ; Wed, 31 Aug 2005 16:48:30 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j7VGmTFv006975; Wed, 31 Aug 2005 09:48:29 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j7VGmTPa006971; Wed, 31 Aug 2005 09:48:29 -0700 Date: Wed, 31 Aug 2005 09:48:29 -0700 From: Brooks Davis To: Jeremie Le Hen Message-ID: <20050831164829.GE32477@odin.ac.hmc.edu> References: <7daacbbe05083105486887f43e@mail.gmail.com> <20050831150811.GL659@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050831150811.GL659@obiwan.tataz.chchile.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: freebsd-current@freebsd.org, Dominique Goncalves Subject: Re: make distribution fails with RELENG_6 on a 5.4-RELEASE-p6 host X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 16:48:30 -0000 On Wed, Aug 31, 2005 at 05:08:11PM +0200, Jeremie Le Hen wrote: > > I'm trying to create a livecd with freesbie2 [1] with RELENG_6 source > > on FreeBSD 5.4-RELEASE-p6, > > but the make distribution fails: > > > > ===> etc/sendmail (install) > > cd /net/FreeBSD/RELENG_6/src/etc/../share/man; > > /usr/obj/net/FreeBSD/RELENG_6/src/make.i386/make makedb > > makewhatis /net/FreeBSD/freesbie-fs/usr/share/man > > makewhatis /net/FreeBSD/freesbie-fs/usr/share/openssl/man > > rm -rf /tmp/install.52xkwmMp > > cd /net/FreeBSD/RELENG_6/src/etc; install -o root -g wheel -m 644 > > amd.map apmd.conf auth.conf crontab csh.cshrc csh.login csh.logout > > devd.conf devfs.conf dhclient.conf disktab fbtab ftpusers gettytab > > group hosts hosts.allow hosts.equiv hosts.lpd inetd.conf > > login.access login.conf mac.conf motd netconfig network.subr networks > > newsyslog.conf portsnap.conf pf.conf pf.os phones profile protocols > > rc rc.bsdextended rc.firewall rc.firewall6 rc.initdiskless > > rc.sendmail rc.shutdown rc.subr remote rpc services shells > > snmpd.config sysctl.conf syslog.conf usbd.conf etc.i386/ttys > > /net/FreeBSD/RELENG_6/src/etc/../gnu/usr.bin/man/manpath/manpath.config > > /net/FreeBSD/RELENG_6/src/etc/../usr.bin/mail/misc/mail.rc > > /net/FreeBSD/RELENG_6/src/etc/../usr.bin/locate/locate/locate.rc > > printcap /net/FreeBSD/freesbie-fs/etc; cap_mkdb -l > > /net/FreeBSD/freesbie-fs/etc/login.conf; install -o root -g wheel -m > > 755 netstart pccard_ether rc.suspend rc.resume > > /net/FreeBSD/freesbie-fs/etc; install -o root -g wheel -m 600 > > master.passwd nsmb.conf opieaccess /net/FreeBSD/freesbie-fs/etc; > > pwd_mkdb -L -p -d /net/FreeBSD/freesbie-fs/etc > > /net/FreeBSD/freesbie-fs/etc/master.passwd > > cap_mkdb: illegal option -- l > > usage: cap_mkdb [-v] [-f outfile] file [file ...] > > *** Error code 1 > > You are supposed to make buildworld first, as stated in src/UPDATING. You should also do the "make distribution" from / not /etc/ which will actually use the tools. I can't tell from the given output where it's being done in this case. -- Brooks From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 17:47:26 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 7F53216A41F for ; Wed, 31 Aug 2005 17:47:26 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8E3E43D48 for ; Wed, 31 Aug 2005 17:47:25 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [10.1.1.7]) (authenticated bits=0) by srv1.cosmo-project.de (8.12.10/8.12.10) with ESMTP id j7VHlGBS038209 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 31 Aug 2005 19:47:18 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id j7VHkaKi004717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Aug 2005 19:46:37 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.11/8.12.11) with ESMTP id j7VHkaMG011919; Wed, 31 Aug 2005 19:46:36 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id j7VHkWHs011918; Wed, 31 Aug 2005 19:46:32 +0200 (CEST) (envelope-from ticso) Date: Wed, 31 Aug 2005 19:46:31 +0200 From: Bernd Walter To: Scott Long Message-ID: <20050831174631.GE37930@cicely12.cicely.de> References: <1125452228.740.3.camel@arbitor.homelinux.com> <47d0403c05083020044f6ac0be@mail.gmail.com> <4315CEEC.80100@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4315CEEC.80100@samsco.org> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org, Kyle Brooks , Ben Kaduk Subject: Re: panic after removing usb flash drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2005 17:47:26 -0000 On Wed, Aug 31, 2005 at 09:38:20AM -0600, Scott Long wrote: > Ben Kaduk wrote: > >On 8/31/05, Kyle Brooks wrote: > 1) When the thumbdrive gets pulled, the umass driver gets told to > detach. It tries to detach itself from CAM, but things don't get torn > down correctly because there is an open reference to the target in CAM > (because there is a mounted filesystem on the device). umass truddles > along anyways and goes away, leaving lots of dangling pointers in CAM > that blow up on the next attempted I/O access. > > Part of the problem here is that the umass driver is architected wrong. > It creates a SIM, bus, and target instance for every umass device that > gets inserted. When the device gets pulled, it tries to tear down > each of those instances all at once. CAM simply wasn't designed for > this. It was designed for the SIMs and buses to be long-lived objects > where only the targets (and luns) come and go. Making umass fit this > model would invlove turning it into two logical drivers. One would be > a SIM that would attach to the root hub instance of each USB controller > and would treat the USB bus as a CAM bus. The other would be a target > driver that gets created and destroyed on a per-device basis as those > devices come and go. When a umass device gets plugged in, the USB > framework would tell the apprpriate SIM to create a target instance. > When the device gets pulled, the framework would tell the SIM to detach > and destroy the target. No dangling pointers would be left behind by > the SIM going away. I have some prototype work in progress on this. This would really a step backward. Originally we had LUN creation/deletion on shared SIM and lots of different problems. SIM deletion should really be fixed - not only for umass, but generally as we live in a world with removeable cards. Technically a shared sim with using targets could be made work for umass as it's defined today, but it won't work for USB to SCSI converters - that we don't support one of these adapters today doesn't solve the problem. Is is a academical standpoint defining where in the USB/umass infrastrukture the SIM is located, but I personally always saw it inside the USB-device and not on the USB. USB is just a transport medium and not a SIM in the same way as PCI is just a transport medium for a classical SCSI-Interface. Yes - umass creates a SIM, bus and targed, because that is what a user really attaches/detaches. > In any case, the panic posted in the grandparent message implicates CAM > and umass, which is what I would expect. There may be more layers of > problems underneath it. Possible, but lets solve them. -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 18:01: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 12CB816A41F for ; Wed, 31 Aug 2005 18:01:07 +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 7A26443D45 for ; Wed, 31 Aug 2005 18:01:06 +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.4/8.13.4/NETPLEX) with ESMTP id j7VI1119006337; Wed, 31 Aug 2005 14:01:01 -0400 (EDT) Date: Wed, 31 Aug 2005 14:01:01 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: "Justin T. Gibbs" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-851401618-1125511261=:20427" X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: freebsd-current@freebsd.org, Sam Lawrance Subject: Re: adaptec 39320 - ahd0: Invalid Sequencer interrupt occurred 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: Wed, 31 Aug 2005 18: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. Send mail to mime@docserver.cac.washington.edu for more info. ---559023410-851401618-1125511261=:20427 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 17 Aug 2005, Justin T. Gibbs wrote: > > I see the ahd0 message below on just about every boot of a dell sc1425 > > running 6.0-BETA2, just after "waiting for scsi devices to settle". > > Once the system is up I don't see it again. > > > > Is it harmful? Can I help? The machine has a serial cable attached so > > it can be peeked and poked if need be. > > Sam, > > This message indicates that the firmware engine wound up in its > interrupt handler with no status indicating an interrupt should > have occurred. I'm not sure why this is happening in some configurations > (yours is not the first), but it seems to be harmless enough. I > would love to better understand why this is happening, but without > being able to replicate the problem here (and I have tried), I > don't think I can do much other than just turn off the message in > the driver. I have the same problem as Sam, under 5.2.1, 5.4-stable (as of yesterday), and now in 6.0 (as of yesterday). Everything seems to work just fine, though. The machine is not in production yet, so I can play with it a bit if you have any ideas. Other than that, I'll just ignore the error message. -- DE ---559023410-851401618-1125511261=:20427 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="dmesg.fatboy" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: fatboy dmesg Content-Disposition: attachment; filename="dmesg.fatboy" Q29weXJpZ2h0IChjKSAxOTkyLTIwMDUgVGhlIEZyZWVCU0QgUHJvamVjdC4N CkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwg MTk4OSwgMTk5MSwgMTk5MiwgMTk5MywgMTk5NA0KICAgICAgICBUaGUgUmVn ZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLg0KRnJlZUJTRCA2LjAtQkVUQTMgIzA6IFdlZCBBdWcg MzEgMTM6MDY6MTUgRURUIDIwMDUNCiAgICByb290QGZhdGJveTEuY2xjLmdk ZWIuY29tOi91c3Ivb2JqL3Vzci9zcmMvc3lzL2ZhdGJveQ0KV0FSTklORzog V0lUTkVTUyBvcHRpb24gZW5hYmxlZCwgZXhwZWN0IHJlZHVjZWQgcGVyZm9y bWFuY2UuDQpUaW1lY291bnRlciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgy IEh6IHF1YWxpdHkgMA0KQ1BVOiBJbnRlbChSKSBYZW9uKFRNKSBDUFUgMy4w MEdIeiAoMzAwMC4xMi1NSHogNjg2LWNsYXNzIENQVSkNCiAgT3JpZ2luID0g IkdlbnVpbmVJbnRlbCIgIElkID0gMHhmNDMgIFN0ZXBwaW5nID0gMw0KICBG ZWF0dXJlcz0weGJmZWJmYmZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1IsUEFF LE1DRSxDWDgsQVBJQyxTRVAsTVRSUixQR0UsTUNBLENNT1YsUEFULFBTRTM2 LENMRkxVU0gsRFRTLEFDUEksTU1YLEZYU1IsU1NFLFNTRTIsU1MsSFRULFRN LFBCRT4NCiAgRmVhdHVyZXMyPTB4NjQxZDxTU0UzLFJTVkQyLE1PTixEU19D UEwsQ05UWC1JRCxDWDE2LDxiMTQ+Pg0KICBBTUQgRmVhdHVyZXM9MHgyMDEw MDAwMDxOWCxMTT4NCiAgSHlwZXJ0aHJlYWRpbmc6IDIgbG9naWNhbCBDUFVz DQpyZWFsIG1lbW9yeSAgPSAyMTQ2ODkzODI0ICgyMDQ3IE1CKQ0KYXZhaWwg bWVtb3J5ID0gMjA5NTkzOTU4NCAoMTk5OCBNQikNCkFDUEkgQVBJQyBUYWJs ZTogPFBUTFREICAgICAgICAgIEFQSUMgID4NCkZyZWVCU0QvU01QOiBNdWx0 aXByb2Nlc3NvciBTeXN0ZW0gRGV0ZWN0ZWQ6IDQgQ1BVcw0KIGNwdTAgKEJT UCk6IEFQSUMgSUQ6ICAwDQogY3B1MSAoQVApOiBBUElDIElEOiAgMQ0KIGNw dTIgKEFQKTogQVBJQyBJRDogIDYNCiBjcHUzIChBUCk6IEFQSUMgSUQ6ICA3 DQppb2FwaWMwIDxWZXJzaW9uIDIuMD4gaXJxcyAwLTIzIG9uIG1vdGhlcmJv YXJkDQppb2FwaWMxIDxWZXJzaW9uIDIuMD4gaXJxcyAyNC00NyBvbiBtb3Ro ZXJib2FyZA0KaW9hcGljMiA8VmVyc2lvbiAyLjA+IGlycXMgNDgtNzEgb24g bW90aGVyYm9hcmQNCm5weDA6IFtGQVNUXQ0KbnB4MDogPG1hdGggcHJvY2Vz c29yPiBvbiBtb3RoZXJib2FyZA0KbnB4MDogSU5UIDE2IGludGVyZmFjZQ0K YWNwaTA6IDxQVExURCAgIFJTRFQ+IG9uIG1vdGhlcmJvYXJkDQphY3BpMDog UG93ZXIgQnV0dG9uIChmaXhlZCkNCnBjaV9saW5rMDogPEFDUEkgUENJIExp bmsgTE5LQT4gaXJxIDUgb24gYWNwaTANCnBjaV9saW5rMTogPEFDUEkgUENJ IExpbmsgTE5LQj4gaXJxIDEwIG9uIGFjcGkwDQpwY2lfbGluazI6IDxBQ1BJ IFBDSSBMaW5rIExOS0M+IGlycSA3IG9uIGFjcGkwDQpwY2lfbGluazM6IDxB Q1BJIFBDSSBMaW5rIExOS0Q+IGlycSAxMSBvbiBhY3BpMA0KcGNpX2xpbms0 OiA8QUNQSSBQQ0kgTGluayBMTktFPiBpcnEgMCBvbiBhY3BpMA0KcGNpX2xp bms1OiA8QUNQSSBQQ0kgTGluayBMTktGPiBpcnEgMCBvbiBhY3BpMA0KcGNp X2xpbms2OiA8QUNQSSBQQ0kgTGluayBMTktHPiBpcnEgMCBvbiBhY3BpMA0K cGNpX2xpbms3OiA8QUNQSSBQQ0kgTGluayBMTktIPiBpcnEgMTAgb24gYWNw aTANClRpbWVjb3VudGVyICJBQ1BJLWZhc3QiIGZyZXF1ZW5jeSAzNTc5NTQ1 IEh6IHF1YWxpdHkgMTAwMA0KYWNwaV90aW1lcjA6IDwyNC1iaXQgdGltZXIg YXQgMy41Nzk1NDVNSHo+IHBvcnQgMHgxMDA4LTB4MTAwYiBvbiBhY3BpMA0K Y3B1MDogPEFDUEkgQ1BVPiBvbiBhY3BpMA0KY3B1MTogPEFDUEkgQ1BVPiBv biBhY3BpMA0KY3B1MjogPEFDUEkgQ1BVPiBvbiBhY3BpMA0KY3B1MzogPEFD UEkgQ1BVPiBvbiBhY3BpMA0KcGNpYjA6IDxBQ1BJIEhvc3QtUENJIGJyaWRn ZT4gcG9ydCAweGNmOC0weGNmZiBvbiBhY3BpMA0KcGNpMDogPEFDUEkgUENJ IGJ1cz4gb24gcGNpYjANCnBjaTA6IDx1bmtub3duPiBhdCBkZXZpY2UgMC4x IChubyBkcml2ZXIgYXR0YWNoZWQpDQpwY2liMTogPEFDUEkgUENJLVBDSSBi cmlkZ2U+IGlycSAxNiBhdCBkZXZpY2UgMi4wIG9uIHBjaTANCnBjaTE6IDxB Q1BJIFBDSSBidXM+IG9uIHBjaWIxDQpwY2liMjogPEFDUEkgUENJLVBDSSBi cmlkZ2U+IGF0IGRldmljZSAwLjAgb24gcGNpMQ0KcGNpMjogPEFDUEkgUENJ IGJ1cz4gb24gcGNpYjINCmFoZDA6IDxBZGFwdGVjIEFJQzc5MDIgVWx0cmEz MjAgU0NTSSBhZGFwdGVyPiBwb3J0IDB4MjQwMC0weDI0ZmYsMHgyMDAwLTB4 MjBmZiBtZW0gMHhkZDIwMDAwMC0weGRkMjAxZmZmIGlycSAzMiBhdCBkZXZp Y2UgMi4wIG9uIHBjaTINCmFoZDA6IFtHSUFOVC1MT0NLRURdDQphaWM3OTAy OiBVbHRyYTMyMCBXaWRlIENoYW5uZWwgQSwgU0NTSSBJZD03LCBQQ0ktWCAx MDEtMTMzTWh6LCA1MTIgU0NCcw0KYWhkMTogPEFkYXB0ZWMgQUlDNzkwMiBV bHRyYTMyMCBTQ1NJIGFkYXB0ZXI+IHBvcnQgMHgyYzAwLTB4MmNmZiwweDI4 MDAtMHgyOGZmIG1lbSAweGRkMjAyMDAwLTB4ZGQyMDNmZmYgaXJxIDMzIGF0 IGRldmljZSAyLjEgb24gcGNpMg0KYWhkMTogW0dJQU5ULUxPQ0tFRF0NCmFp Yzc5MDI6IFVsdHJhMzIwIFdpZGUgQ2hhbm5lbCBCLCBTQ1NJIElkPTcsIFBD SS1YIDEwMS0xMzNNaHosIDUxMiBTQ0JzDQpwY2kxOiA8YmFzZSBwZXJpcGhl cmFsLCBpbnRlcnJ1cHQgY29udHJvbGxlcj4gYXQgZGV2aWNlIDAuMSAobm8g ZHJpdmVyIGF0dGFjaGVkKQ0KcGNpYjM6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdl PiBhdCBkZXZpY2UgMC4yIG9uIHBjaTENCnBjaTM6IDxBQ1BJIFBDSSBidXM+ IG9uIHBjaWIzDQplbTA6IDxJbnRlbChSKSBQUk8vMTAwMCBOZXR3b3JrIENv bm5lY3Rpb24sIFZlcnNpb24gLSAyLjEuNz4gcG9ydCAweDMwMDAtMHgzMDNm IG1lbSAweGRkMzAwMDAwLTB4ZGQzMWZmZmYgaXJxIDU0IGF0IGRldmljZSAy LjAgb24gcGNpMw0KZW0wOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDozMDo0ODoy ZDo3YjpiNA0KZW0wOiAgU3BlZWQ6Ti9BICBEdXBsZXg6Ti9BDQplbTE6IDxJ bnRlbChSKSBQUk8vMTAwMCBOZXR3b3JrIENvbm5lY3Rpb24sIFZlcnNpb24g LSAyLjEuNz4gcG9ydCAweDMwNDAtMHgzMDdmIG1lbSAweGRkMzIwMDAwLTB4 ZGQzM2ZmZmYgaXJxIDU1IGF0IGRldmljZSAyLjEgb24gcGNpMw0KZW0xOiBF dGhlcm5ldCBhZGRyZXNzOiAwMDozMDo0ODoyZDo3YjpiNQ0KZW0xOiAgU3Bl ZWQ6Ti9BICBEdXBsZXg6Ti9BDQpwY2kxOiA8YmFzZSBwZXJpcGhlcmFsLCBp bnRlcnJ1cHQgY29udHJvbGxlcj4gYXQgZGV2aWNlIDAuMyAobm8gZHJpdmVy IGF0dGFjaGVkKQ0KcGNpYjQ6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEg MTYgYXQgZGV2aWNlIDQuMCBvbiBwY2kwDQpwY2k0OiA8QUNQSSBQQ0kgYnVz PiBvbiBwY2liNA0KcGNpYjU6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEg MTYgYXQgZGV2aWNlIDYuMCBvbiBwY2kwDQpwY2k1OiA8QUNQSSBQQ0kgYnVz PiBvbiBwY2liNQ0KdWhjaTA6IDxJbnRlbCA4MjgwMUVCIChJQ0g1KSBVU0Ig Y29udHJvbGxlciBVU0ItQT4gcG9ydCAweDE0MDAtMHgxNDFmIGlycSAxNiBh dCBkZXZpY2UgMjkuMCBvbiBwY2kwDQp1aGNpMDogW0dJQU5ULUxPQ0tFRF0N CnVzYjA6IDxJbnRlbCA4MjgwMUVCIChJQ0g1KSBVU0IgY29udHJvbGxlciBV U0ItQT4gb24gdWhjaTANCnVzYjA6IFVTQiByZXZpc2lvbiAxLjANCnVodWIw OiBJbnRlbCBVSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEu MDAsIGFkZHIgMQ0KdWh1YjA6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwg c2VsZiBwb3dlcmVkDQp1aGNpMTogPEludGVsIDgyODAxRUIgKElDSDUpIFVT QiBjb250cm9sbGVyIFVTQi1CPiBwb3J0IDB4MTQyMC0weDE0M2YgaXJxIDE5 IGF0IGRldmljZSAyOS4xIG9uIHBjaTANCnVoY2kxOiBbR0lBTlQtTE9DS0VE XQ0KdXNiMTogPEludGVsIDgyODAxRUIgKElDSDUpIFVTQiBjb250cm9sbGVy IFVTQi1CPiBvbiB1aGNpMQ0KdXNiMTogVVNCIHJldmlzaW9uIDEuMA0KdWh1 YjE6IEludGVsIFVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAv MS4wMCwgYWRkciAxDQp1aHViMTogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxl LCBzZWxmIHBvd2VyZWQNCnVoY2kyOiA8SW50ZWwgODI4MDFFQiAoSUNINSkg VVNCIGNvbnRyb2xsZXIgVVNCLUM+IHBvcnQgMHgxNDQwLTB4MTQ1ZiBpcnEg MTggYXQgZGV2aWNlIDI5LjIgb24gcGNpMA0KdWhjaTI6IFtHSUFOVC1MT0NL RURdDQp1c2IyOiA8SW50ZWwgODI4MDFFQiAoSUNINSkgVVNCIGNvbnRyb2xs ZXIgVVNCLUM+IG9uIHVoY2kyDQp1c2IyOiBVU0IgcmV2aXNpb24gMS4wDQp1 aHViMjogSW50ZWwgVUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4w MC8xLjAwLCBhZGRyIDENCnVodWIyOiAyIHBvcnRzIHdpdGggMiByZW1vdmFi bGUsIHNlbGYgcG93ZXJlZA0KdWhjaTM6IDxJbnRlbCA4MjgwMUVCIChJQ0g1 KSBVU0IgY29udHJvbGxlciBVU0ItRD4gcG9ydCAweDE0NjAtMHgxNDdmIGly cSAxNiBhdCBkZXZpY2UgMjkuMyBvbiBwY2kwDQp1aGNpMzogW0dJQU5ULUxP Q0tFRF0NCnVzYjM6IDxJbnRlbCA4MjgwMUVCIChJQ0g1KSBVU0IgY29udHJv bGxlciBVU0ItRD4gb24gdWhjaTMNCnVzYjM6IFVTQiByZXZpc2lvbiAxLjAN CnVodWIzOiBJbnRlbCBVSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAx LjAwLzEuMDAsIGFkZHIgMQ0KdWh1YjM6IDIgcG9ydHMgd2l0aCAyIHJlbW92 YWJsZSwgc2VsZiBwb3dlcmVkDQplaGNpMDogPEVIQ0kgKGdlbmVyaWMpIFVT QiAyLjAgY29udHJvbGxlcj4gbWVtIDB4ZGQwMDAwMDAtMHhkZDAwMDNmZiBp cnEgMjMgYXQgZGV2aWNlIDI5Ljcgb24gcGNpMA0KZWhjaTA6IFtHSUFOVC1M T0NLRURdDQp1c2I0OiBFSENJIHZlcnNpb24gMS4wDQp1c2I0OiBjb21wYW5p b24gY29udHJvbGxlcnMsIDIgcG9ydHMgZWFjaDogdXNiMCB1c2IxIHVzYjIg dXNiMw0KdXNiNDogPEVIQ0kgKGdlbmVyaWMpIFVTQiAyLjAgY29udHJvbGxl cj4gb24gZWhjaTANCnVzYjQ6IFVTQiByZXZpc2lvbiAyLjANCnVodWI0OiBJ bnRlbCBFSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAs IGFkZHIgMQ0KdWh1YjQ6IDggcG9ydHMgd2l0aCA4IHJlbW92YWJsZSwgc2Vs ZiBwb3dlcmVkDQpwY2liNjogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRl dmljZSAzMC4wIG9uIHBjaTANCnBjaTY6IDxBQ1BJIFBDSSBidXM+IG9uIHBj aWI2DQpwY2k2OiA8ZGlzcGxheSwgVkdBPiBhdCBkZXZpY2UgMS4wIChubyBk cml2ZXIgYXR0YWNoZWQpDQppc2FiMDogPFBDSS1JU0EgYnJpZGdlPiBhdCBk ZXZpY2UgMzEuMCBvbiBwY2kwDQppc2EwOiA8SVNBIGJ1cz4gb24gaXNhYjAN CmF0YXBjaTA6IDxJbnRlbCBJQ0g1IFVETUExMDAgY29udHJvbGxlcj4gcG9y dCAweDFmMC0weDFmNywweDNmNiwweDE3MC0weDE3NywweDM3NiwweDE0YTAt MHgxNGFmIGF0IGRldmljZSAzMS4xIG9uIHBjaTANCmF0YTA6IDxBVEEgY2hh bm5lbCAwPiBvbiBhdGFwY2kwDQphdGExOiA8QVRBIGNoYW5uZWwgMT4gb24g YXRhcGNpMA0KcGNpMDogPHNlcmlhbCBidXMsIFNNQnVzPiBhdCBkZXZpY2Ug MzEuMyAobm8gZHJpdmVyIGF0dGFjaGVkKQ0KYWNwaV9idXR0b24wOiA8UG93 ZXIgQnV0dG9uPiBvbiBhY3BpMA0KYXRrYmRjMDogPEtleWJvYXJkIGNvbnRy b2xsZXIgKGk4MDQyKT4gcG9ydCAweDYwLDB4NjQgaXJxIDEgb24gYWNwaTAN CmF0a2JkMDogPEFUIEtleWJvYXJkPiBpcnEgMSBvbiBhdGtiZGMwDQprYmQw IGF0IGF0a2JkMA0KYXRrYmQwOiBbR0lBTlQtTE9DS0VEXQ0KcHNtMDogPFBT LzIgTW91c2U+IGlycSAxMiBvbiBhdGtiZGMwDQpwc20wOiBbR0lBTlQtTE9D S0VEXQ0KcHNtMDogbW9kZWwgSW50ZWxsaU1vdXNlLCBkZXZpY2UgSUQgMw0K c2lvMDogPDE2NTUwQS1jb21wYXRpYmxlIENPTSBwb3J0PiBwb3J0IDB4M2Y4 LTB4M2ZmIGlycSA0IGZsYWdzIDB4MTAgb24gYWNwaTANCnNpbzA6IHR5cGUg MTY1NTBBDQpzaW8xOiA8MTY1NTBBLWNvbXBhdGlibGUgQ09NIHBvcnQ+IHBv cnQgMHgyZjgtMHgyZmYgaXJxIDMgb24gYWNwaTANCnNpbzE6IHR5cGUgMTY1 NTBBDQpmZGMwOiA8ZmxvcHB5IGRyaXZlIGNvbnRyb2xsZXI+IHBvcnQgMHgz ZjAtMHgzZjUsMHgzZjcgaXJxIDYgZHJxIDIgb24gYWNwaTANCmZkYzA6IFtG QVNUXQ0KZmQwOiA8MTQ0MC1LQiAzLjUiIGRyaXZlPiBvbiBmZGMwIGRyaXZl IDANCnBtdGltZXIwIG9uIGlzYTANCm9ybTA6IDxJU0EgT3B0aW9uIFJPTXM+ IGF0IGlvbWVtIDB4YzAwMDAtMHhjN2ZmZiwweGM4MDAwLTB4YzhmZmYgb24g aXNhMA0Kc2MwOiA8U3lzdGVtIGNvbnNvbGU+IGF0IGZsYWdzIDB4MTAwIG9u IGlzYTANCnNjMDogVkdBIDwxNiB2aXJ0dWFsIGNvbnNvbGVzLCBmbGFncz0w eDMwMD4NCnZnYTA6IDxHZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAt MHgzZGYgaW9tZW0gMHhhMDAwMC0weGJmZmZmIG9uIGlzYTANCnBwYzA6IHBh cmFsbGVsIHBvcnQgbm90IGZvdW5kLg0KVGltZWNvdW50ZXJzIHRpY2sgZXZl cnkgMS4wMDAgbXNlYw0KV2FpdGluZyA1IHNlY29uZHMgZm9yIFNDU0kgZGV2 aWNlcyB0byBzZXR0bGUNCmFjZDA6IERWRFJPTSA8TUFUU0hJVEFEVkQtUk9N IFNSLTgxNzcvTkUxNj4gYXQgYXRhMS1zbGF2ZSBVRE1BMzMNCmFoZDA6IElu dmFsaWQgU2VxdWVuY2VyIGludGVycnVwdCBvY2N1cnJlZC4NCj4+Pj4+Pj4+ Pj4+Pj4+Pj4+PiBEdW1wIENhcmQgU3RhdGUgQmVnaW5zIDw8PDw8PDw8PDw8 PDw8PDw8DQphaGQwOiBEdW1waW5nIENhcmQgU3RhdGUgYXQgcHJvZ3JhbSBh ZGRyZXNzIDB4MjNiIE1vZGUgMHgwDQpDYXJkIHdhcyBwYXVzZWQNCklOVFNU QVRbMHgwXSBTRUxPSURbMHgzXSBTRUxJRFsweDIwXSBIU19NQUlMQk9YWzB4 MF0gDQpJTlRDVExbMHg4MF06KFNXVE1JTlRNQVNLKSBTRVFJTlRTVEFUWzB4 MF0gU0FWRURfTU9ERVsweDExXSANCkRGRlNUQVRbMHgzM106KENVUlJGSUZP X05PTkV8RklGTzBGUkVFfEZJRk8xRlJFRSkgDQpTQ1NJU0lHSVsweDBdOihQ X0RBVEFPVVQpIFNDU0lQSEFTRVsweDBdIFNDU0lCVVNbMHgwXSANCkxBU1RQ SEFTRVsweDFdOihQX0RBVEFPVVR8UF9CVVNGUkVFKSBTQ1NJU0VRMFsweDBd IA0KU0NTSVNFUTFbMHgxMl06KEVOQVVUT0FUTlB8RU5SU0VMSSkgU0VRQ1RM MFsweDBdIFNFUUlOVENUTFsweDZdOihJTlRNQVNLMXxJTlRNQVNLMikgDQpT RVFfRkxBR1NbMHgwXSBTRVFfRkxBR1MyWzB4MF0gUUZSRUVaRV9DT1VOVFsw eDVdIA0KS0VSTkVMX1FGUkVFWkVfQ09VTlRbMHg1XSBNS19NRVNTQUdFX1ND QlsweGZmMDBdIE1LX01FU1NBR0VfU0NTSUlEWzB4ZmZdIA0KU1NUQVQwWzB4 MF0gU1NUQVQxWzB4MF0gU1NUQVQyWzB4MF0gU1NUQVQzWzB4MF0gUEVSUkRJ QUdbMHgwXSANClNJTU9ERTFbMHhhNF06KEVOU0NTSVBFUlJ8RU5TQ1NJUlNU fEVOU0VMVElNTykgTFFJU1RBVDBbMHgwXSANCkxRSVNUQVQxWzB4MF0gTFFJ U1RBVDJbMHgwXSBMUU9TVEFUMFsweDBdIExRT1NUQVQxWzB4MF0gDQpMUU9T VEFUMlsweDBdIA0KDQpTQ0IgQ291bnQgPSAxNiBDTURTX1BFTkRJTkcgPSAx IExBU1RTQ0IgMHhmZmZmIENVUlJTQ0IgMHg0IE5FWFRTQ0IgMHhmZjgwDQpx aW5zdGFydCA9IDQ5IHFpbmZpZm9uZXh0ID0gNTENClFJTkZJRk86IDB4ZiAw eGINCldBSVRJTkdfVElEX1FVRVVFUzoNCiAgICAgICAxICggMHhkICkNClBl bmRpbmcgbGlzdDoNCiAxMSBGSUZPX1VTRVsweDBdIFNDQl9DT05UUk9MWzB4 NDhdOihTVEFUVVNfUkNWRHxESVNDRU5CKSBTQ0JfU0NTSUlEWzB4NjddIA0K IDE1IEZJRk9fVVNFWzB4MF0gU0NCX0NPTlRST0xbMHg0MF06KERJU0NFTkIp IFNDQl9TQ1NJSURbMHg3XSANCiAxMyBGSUZPX1VTRVsweDBdIFNDQl9DT05U Uk9MWzB4NTBdOihNS19NRVNTQUdFfERJU0NFTkIpIFNDQl9TQ1NJSURbMHgx N10gDQpUb3RhbCAzDQpLZXJuZWwgRnJlZSBTQ0IgbGlzdDogMTQgNCAxIDIg MyA1IDYgNyA4IDkgMTAgMTIgMCANClNlcXVlbmNlciBDb21wbGV0ZSBETUEt aW5wcm9nIGxpc3Q6IA0KU2VxdWVuY2VyIENvbXBsZXRlIGxpc3Q6IA0KU2Vx dWVuY2VyIERNQS1VcCBhbmQgQ29tcGxldGUgbGlzdDogDQpTZXF1ZW5jZXIg T24gUUZyZWV6ZSBhbmQgQ29tcGxldGUgbGlzdDogDQoNCg0KYWhkMDogRklG TzAgRnJlZSwgTE9OR0pNUCA9PSAweDgwMDAsIFNDQiAweGUNClNFUUlNT0RF WzB4M2ZdOihFTkNGRzRUQ01EfEVOQ0ZHNElDTUR8RU5DRkc0VFNUQVR8RU5D Rkc0SVNUQVR8RU5DRkc0REFUQXxFTlNBVkVQVFJTKSANClNFUUlOVFNSQ1sw eDBdIERGQ05UUkxbMHgwXSBERlNUQVRVU1sweDg5XTooRklGT0VNUHxIRE9O RXxQUkVMT0FEX0FWQUlMKSANClNHX0NBQ0hFX1NIQURPV1sweDJdOihMQVNU X1NFRykgU0dfU1RBVEVbMHgwXSBERkZTWEZSQ1RMWzB4MF0gDQpTT0ZGQ05U WzB4MF0gTURGRlNUQVRbMHg1XTooRklGT0ZSRUV8RExaRVJPKSBTSEFERFIg PSAweDAwLCBTSENOVCA9IDB4MCANCkhBRERSID0gMHgwMCwgSENOVCA9IDB4 MCBDQ1NHQ1RMWzB4MTBdOihTR19DQUNIRV9BVkFJTCkgDQoNCmFoZDA6IEZJ Rk8xIEZyZWUsIExPTkdKTVAgPT0gMHg4MDYzLCBTQ0IgMHhiDQpTRVFJTU9E RVsweDNmXTooRU5DRkc0VENNRHxFTkNGRzRJQ01EfEVOQ0ZHNFRTVEFUfEVO Q0ZHNElTVEFUfEVOQ0ZHNERBVEF8RU5TQVZFUFRSUykgDQpTRVFJTlRTUkNb MHgwXSBERkNOVFJMWzB4MF0gREZTVEFUVVNbMHg4OV06KEZJRk9FTVB8SERP TkV8UFJFTE9BRF9BVkFJTCkgDQpTR19DQUNIRV9TSEFET1dbMHgyXTooTEFT VF9TRUcpIFNHX1NUQVRFWzB4MF0gREZGU1hGUkNUTFsweDBdIA0KU09GRkNO VFsweDBdIE1ERkZTVEFUWzB4NV06KEZJRk9GUkVFfERMWkVSTykgU0hBRERS ID0gMHgwMCwgU0hDTlQgPSAweDAgDQpIQUREUiA9IDB4MDAsIEhDTlQgPSAw eDAgQ0NTR0NUTFsweDEwXTooU0dfQ0FDSEVfQVZBSUwpIA0KTFFJTjogMHg4 IDB4MCAweDAgMHhlIDB4MCAweDEgMHgwIDB4MCAweDAgMHgwIDB4MCAweDAg MHgwIDB4MCAweDAgMHgwIDB4MCAweDAgMHgwIDB4MCANCmFoZDA6IExRSVNU QVRFID0gMHgwLCBMUU9TVEFURSA9IDB4MCwgT1BUSU9OTU9ERSA9IDB4NDIN CmFoZDA6IE9TX1NQQUNFX0NOVCA9IDB4MjAgTUFYQ01EQ05UID0gMHgxDQph aGQwOiBTQVZFRF9TQ1NJSUQgPSAweDAgU0FWRURfTFVOID0gMHgwDQoNClNJ TU9ERTBbMHhjXTooRU5PVkVSUlVOfEVOSU9FUlIpIA0KQ0NTQ0JDVExbMHgw XSANCmFoZDA6IFJFRzAgPT0gMHgxNjAsIFNJTkRFWCA9IDB4MTBlLCBESU5E RVggPSAweDEwOA0KYWhkMDogU0NCUFRSID09IDB4ZSwgU0NCX05FWFQgPT0g MHhmZjgwLCBTQ0JfTkVYVDIgPT0gMHg0DQpDREIgMTIgMjAgMCA4MCA4IGE1 DQpTVEFDSzogMHgyMzYgMHgyIDB4MCAweDAgMHgwIDB4MCAweDAgMHgwDQo8 PDw8PDw8PDw8PDw8PDw8PCBEdW1wIENhcmQgU3RhdGUgRW5kcyA+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4NCnNlczAgYXQgYWhkMCBidXMgMCB0YXJnZXQgNiBsdW4g MA0Kc2VzMDogPFNVUEVSIEdFTTMxOCAwPiBGaXhlZCBQcm9jZXNzb3IgU0NT SS0yIGRldmljZSANCnNlczA6IDMuMzAwTUIvcyB0cmFuc2ZlcnMNCnNlczA6 IFNBRi1URSBDb21wbGlhbnQgRGV2aWNlDQpDb3BpZWQgMTggYnl0ZXMgb2Yg c2Vuc2UgZGF0YSBvZmZzZXQgMTI6IDB4NzAgMHgwIDB4NiAweDAgMHgwIDB4 MCAweDAgMHhhIDB4MCAweDAgMHgwIDB4MCAweDI5IDB4MiAweDIgMHgwIDB4 MCAweDANCkNvcGllZCAxOCBieXRlcyBvZiBzZW5zZSBkYXRhIG9mZnNldCAx MjogMHg3MCAweDAgMHg2IDB4MCAweDAgMHgwIDB4MCAweGEgMHgwIDB4MCAw eDAgMHgwIDB4MjkgMHgyIDB4MiAweDAgMHgwIDB4MA0KQ29waWVkIDE4IGJ5 dGVzIG9mIHNlbnNlIGRhdGEgb2Zmc2V0IDEyOiAweDcwIDB4MCAweDYgMHgw IDB4MCAweDAgMHgwIDB4YSAweDAgMHgwIDB4MCAweDAgMHgyOSAweDIgMHgy IDB4MCAweDAgMHgwDQpDb3BpZWQgMTggYnl0ZXMgb2Ygc2Vuc2UgZGF0YSBv ZmZzZXQgMTI6IDB4NzAgMHgwIDB4NiAweDAgMHgwIDB4MCAweDAgMHhhIDB4 MCAweDAgMHgwIDB4MCAweDI5IDB4MiAweDIgMHgwIDB4MCAweDANCmRhMCBh dCBhaGQwIGJ1cyAwIHRhcmdldCAwIGx1biAwDQpkYTA6IDxTRUFHQVRFIFNU MzczMjA3TEMgMDAwMz4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTMgZGV2 aWNlIA0KZGEwOiAzMjAuMDAwTUIvcyB0cmFuc2ZlcnMgKDE2MC4wMDBNSHos IG9mZnNldCA2MywgMTZiaXQpLCBUYWdnZWQgUXVldWVpbmcgRW5hYmxlZA0K ZGEwOiA3MDAwN01CICgxNDMzNzQ3NDQgNTEyIGJ5dGUgc2VjdG9yczogMjU1 SCA2M1MvVCA4OTI0QykNCmRhMyBhdCBhaGQwIGJ1cyAwIHRhcmdldCAzIGx1 biAwDQpkYTM6IDxTRUFHQVRFIFNUMzczMjA3TEMgMDAwMz4gRml4ZWQgRGly ZWN0IEFjY2VzcyBTQ1NJLTMgZGV2aWNlIA0KZGEzOiAzMjAuMDAwTUIvcyB0 cmFuc2ZlcnMgKDE2MC4wMDBNSHosIG9mZnNldCA2MywgMTZiaXQpLCBUYWdn ZWQgUXVldWVpbmcgRW5hYmxlZA0KZGEzOiA3MDAwN01CICgxNDMzNzQ3NDQg NTEyIGJ5dGUgc2VjdG9yczogMjU1SCA2M1MvVCA4OTI0QykNCmRhMiBhdCBh aGQwIGJ1cyAwIHRhcmdldCAyIGx1biAwDQpkYTI6IDxTRUFHQVRFIFNUMzcz MjA3TEMgMDAwMz4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTMgZGV2aWNl IA0KZGEyOiAzMjAuMDAwTUIvcyB0cmFuc2ZlcnMgKDE2MC4wMDBNSHosIG9m ZnNldCA2MywgMTZiaXQpLCBUYWdnZWQgUXVldWVpbmcgRW5hYmxlZA0KZGEy OiA3MDAwN01CICgxNDMzNzQ3NDQgNTEyIGJ5dGUgc2VjdG9yczogMjU1SCA2 M1MvVCA4OTI0QykNCmRhMSBhdCBhaGQwIGJ1cyAwIHRhcmdldCAxIGx1biAw DQpkYTE6IDxTRUFHQVRFIFNUMzczMjA3TEMgMDAwMz4gRml4ZWQgRGlyZWN0 IEFjY2VzcyBTQ1NJLTMgZGV2aWNlIA0KZGExOiAzMjAuMDAwTUIvcyB0cmFu c2ZlcnMgKDE2MC4wMDBNSHosIG9mZnNldCA2MywgMTZiaXQpLCBUYWdnZWQg UXVldWVpbmcgRW5hYmxlZA0KZGExOiA3MDAwN01CICgxNDMzNzQ3NDQgNTEy IGJ5dGUgc2VjdG9yczogMjU1SCA2M1MvVCA4OTI0QykNCmNkMCBhdCBhdGEx IGJ1cyAwIHRhcmdldCAxIGx1biAwDQpjZDA6IDxNQVRTSElUQSBEVkQtUk9N IFNSLTgxNzcgTkUxNj4gUmVtb3ZhYmxlIENELVJPTSBTQ1NJLTAgZGV2aWNl IA0KY2QwOiAzMy4wMDBNQi9zIHRyYW5zZmVycw0KY2QwOiBBdHRlbXB0IHRv IHF1ZXJ5IGRldmljZSBzaXplIGZhaWxlZDogTk9UIFJFQURZLCBNZWRpdW0g bm90IHByZXNlbnQNClNNUDogQVAgQ1BVICMxIExhdW5jaGVkIQ0KU01QOiBB UCBDUFUgIzMgTGF1bmNoZWQhDQpTTVA6IEFQIENQVSAjMiBMYXVuY2hlZCEN ClRyeWluZyB0byBtb3VudCByb290IGZyb20gdWZzOi9kZXYvZGEwczFhDQpl bTA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBVUA0K ---559023410-851401618-1125511261=:20427-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 18:05: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 1CC0616A41F for ; Wed, 31 Aug 2005 18:05:27 +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 96C2643D45 for ; Wed, 31 Aug 2005 18:05:26 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j7VIItFC007998; Wed, 31 Aug 2005 12:18:55 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4315F15D.4090209@samsco.org> Date: Wed, 31 Aug 2005 12:05:17 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ticso@cicely.de References: <1125452228.740.3.camel@arbitor.homelinux.com> <47d0403c05083020044f6ac0be@mail.gmail.com> <4315CEEC.80100@samsco.org> <20050831174631.GE37930@cicely12.cicely.de> In-Reply-To: <20050831174631.GE37930@cicely12.cicely.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: freebsd-current@freebsd.org, Kyle Brooks , Ben Kaduk Subject: Re: panic after removing usb flash drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 18:05:27 -0000 Bernd Walter wrote: > On Wed, Aug 31, 2005 at 09:38:20AM -0600, Scott Long wrote: > >>Ben Kaduk wrote: >> >>>On 8/31/05, Kyle Brooks wrote: >> >>1) When the thumbdrive gets pulled, the umass driver gets told to >>detach. It tries to detach itself from CAM, but things don't get torn >>down correctly because there is an open reference to the target in CAM >>(because there is a mounted filesystem on the device). umass truddles >>along anyways and goes away, leaving lots of dangling pointers in CAM >>that blow up on the next attempted I/O access. >> >>Part of the problem here is that the umass driver is architected wrong. >>It creates a SIM, bus, and target instance for every umass device that >>gets inserted. When the device gets pulled, it tries to tear down >>each of those instances all at once. CAM simply wasn't designed for >>this. It was designed for the SIMs and buses to be long-lived objects >>where only the targets (and luns) come and go. Making umass fit this >>model would invlove turning it into two logical drivers. One would be >>a SIM that would attach to the root hub instance of each USB controller >>and would treat the USB bus as a CAM bus. The other would be a target >>driver that gets created and destroyed on a per-device basis as those >>devices come and go. When a umass device gets plugged in, the USB >>framework would tell the apprpriate SIM to create a target instance. >>When the device gets pulled, the framework would tell the SIM to detach >>and destroy the target. No dangling pointers would be left behind by >>the SIM going away. I have some prototype work in progress on this. > > > This would really a step backward. > Originally we had LUN creation/deletion on shared SIM and lots of > different problems. > SIM deletion should really be fixed - not only for umass, but generally > as we live in a world with removeable cards. Bugs in the umass detach code are immediately responsible for the problem, but you are correct that CAM in general doesn't like SIMs going away. DFly worked on this a while back, but I don't recall whether the work there was to add more sanity checks in the data path (which I don't want to do), or if it was the correct approach of flushing and quiescing the data/queuing, topology, and error recovery paths. > Technically a shared sim with using targets could be made work for > umass as it's defined today, but it won't work for USB to SCSI > converters - that we don't support one of these adapters today doesn't > solve the problem. This is a completely different situation. A USB-SCSI adapter would provide its own SCSI bus that is separate from the USB bus with its own queueing resources and own error recovery mechanisms. > Is is a academical standpoint defining where in the USB/umass > infrastrukture the SIM is located, but I personally always saw it > inside the USB-device and not on the USB. > USB is just a transport medium and not a SIM in the same way as PCI is > just a transport medium for a classical SCSI-Interface. > Yes - umass creates a SIM, bus and targed, because that is what a user > really attaches/detaches. > It is muddy, but for a mass storage class device, you are using the USB bus as the transport medium and you are using the USB controller as the transport initiator. Command queueing and resource arbitration happens in the USB controller and driver, not in the umass device or driver. Same for error recovery. The USB controller is essentially acting as a SCSI controller, just with a USB bus instead of a SPI bus. The whole point of CAM is to assist with queueing and arbitrating bus resources. There is no way that the SIM-per-device approach can provide this information. Your analogy of a PCI bus is correct for the USB-SCSI adapters, where the adapter is doing a full conversion and bridge from one bus type to another. It's not true for a umass device where it's merely using the USB bus as a SCSI transport. > >>In any case, the panic posted in the grandparent message implicates CAM >>and umass, which is what I would expect. There may be more layers of >>problems underneath it. > > > Possible, but lets solve them. > Indeed. Scott From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 19:01: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 6B11416A41F for ; Wed, 31 Aug 2005 19:01:01 +0000 (GMT) (envelope-from jilles@stack.nl) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0819E43D49 for ; Wed, 31 Aug 2005 19:01:00 +0000 (GMT) (envelope-from jilles@stack.nl) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mailhost.stack.nl (Postfix) with ESMTP id 766AFA2FD3; Wed, 31 Aug 2005 21:00:59 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 63DA52287D; Wed, 31 Aug 2005 21:00:59 +0200 (CEST) Date: Wed, 31 Aug 2005 21:00:59 +0200 From: Jilles Tjoelker To: Michael Bushkov Message-ID: <20050831190059.GA23652@stack.nl> References: <20050827170633.Y5409@stinger.cc.rsu.ru> <43123F3B.8070002@FreeBSD.org> <20050829115740.N5409@stinger.cc.rsu.ru> <20050829163025.GA25664@dan.emsphone.com> <20050830172127.E5409@stinger.cc.rsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050830172127.E5409@stinger.cc.rsu.ru> X-Operating-System: FreeBSD 5.4-RELEASE i386 User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org, Dan Nelson Subject: Re: [PATCH] caching daemon release and nsswitch patches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 19:01:01 -0000 [cc list stripped] On Tue, Aug 30, 2005 at 05:32:52PM +0400, Michael Bushkov wrote: > We can't ensure that, I guess. In the upcoming version (before the 1st of > September), the cache would be per-user. This would solve all the security > problems. In a little while, I'll implement the ability for cached to act > as nscd. So you'll be able to choose the behaviour. What about setuid/setgid programs then? setuid root programs can use root's cache, perhaps a similar thing could be done for other setuid programs, but what about setgid? perhaps don't cache at all for set*id programs (issetugid(2))? -- Jilles Tjoelker From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 19:09: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 C5D5116A41F for ; Wed, 31 Aug 2005 19:09:24 +0000 (GMT) (envelope-from stb@lassitu.de) Received: from schlepper.zs64.net (schlepper.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DD6643D46 for ; Wed, 31 Aug 2005 19:09:23 +0000 (GMT) (envelope-from stb@lassitu.de) Received: from [IPv6:::1] (schlepper [212.12.50.230]) by schlepper.zs64.net (8.13.3/8.12.9) with ESMTP id j7VJ9DCQ019022; Wed, 31 Aug 2005 21:09:13 +0200 (CEST) (envelope-from stb@lassitu.de) In-Reply-To: <95B83146-2D52-42D3-8C2E-113CD280743F@lassitu.de> References: <7A0B19EC-2F90-495F-B242-7FB701C32908@lassitu.de> <20050828124321.43365136@Magellan.Leidinger.net> <3923443F-6926-4BB7-8681-40FC68A41B79@lassitu.de> <0046E5C3-22EE-4F5D-B2B0-DFF4F0157F6B@lassitu.de> <9105C2F5-0D77-4B43-AFFA-7558BBEDA26A@lassitu.de> <2E95AA3B-2CF7-4EFB-9EAC-45683D1F8D7D@DeepCore.dk> <95B83146-2D52-42D3-8C2E-113CD280743F@lassitu.de> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <48966896-18ED-4CB6-81E4-7C1113372272@lassitu.de> Content-Transfer-Encoding: quoted-printable From: Stefan Bethke Date: Wed, 31 Aug 2005 21:09:12 +0200 To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.734) Cc: =?ISO-8859-1?Q?S=F8ren_Schmidt?= Subject: Re: Boot off CF card hangs at "Trying to mount root" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 19:09:24 -0000 Am 29.08.2005 um 23:20 schrieb Stefan Bethke: > Am 29.08.2005 um 22:25 schrieb S=F8ren Schmidt: >> On 29/08/2005, at 21:13, Stefan Bethke wrote: >>> After the final "ad2: req=3D0xc17fc000 READ completed callback/=20 >>> wakeup", nothing else happens. >> Hmm, the timeout in there is worrying me, please try the below =20 >> hack and se if that makes it get through. Might be that the device =20= >> doesn't like 64K (ie size 0) transfers... > Hhm, doesn't look too different. I've fixed fstab, so this is a =20 > complete verbose boot. Anyone got any further suggestions? Currently the router is laying =20 on the table open with bits hanging out, and that does not improve =20 it's WAF :-) Stefan --=20 Stefan Bethke Fon +49 170 346 0140 From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 19:14: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 B381616A41F for ; Wed, 31 Aug 2005 19:14:27 +0000 (GMT) (envelope-from bushman@rsu.ru) Received: from mail.r61.net (mail.r61.net [195.208.245.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFAC643D45 for ; Wed, 31 Aug 2005 19:14:26 +0000 (GMT) (envelope-from bushman@rsu.ru) Received: from stinger.cc.rsu.ru (stinger.cc.rsu.ru [195.208.252.82]) by mail.r61.net (8.13.4/8.13.4) with ESMTP id j7VJE6xH012923; Wed, 31 Aug 2005 23:14:06 +0400 (MSD) (envelope-from bushman@rsu.ru) Date: Wed, 31 Aug 2005 23:18:19 +0400 (MSD) From: Michael Bushkov X-X-Sender: bushman@stinger.cc.rsu.ru To: Jilles Tjoelker In-Reply-To: <20050831190059.GA23652@stack.nl> Message-ID: <20050831231233.T72814@stinger.cc.rsu.ru> References: <20050827170633.Y5409@stinger.cc.rsu.ru> <43123F3B.8070002@FreeBSD.org> <20050829115740.N5409@stinger.cc.rsu.ru> <20050829163025.GA25664@dan.emsphone.com> <20050830172127.E5409@stinger.cc.rsu.ru> <20050831190059.GA23652@stack.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.86.2, clamav-milter version 0.86 on asterix.r61.net X-Virus-Status: Clean X-Spam-Status: No, score=-5.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on asterix.r61.net Cc: freebsd-current@freebsd.org, Dan Nelson Subject: Re: [PATCH] caching daemon release and nsswitch patches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 19:14:27 -0000 > On Tue, Aug 30, 2005 at 05:32:52PM +0400, Michael Bushkov wrote: >> We can't ensure that, I guess. In the upcoming version (before the 1st of >> September), the cache would be per-user. This would solve all the security >> problems. In a little while, I'll implement the ability for cached to act >> as nscd. So you'll be able to choose the behaviour. > > What about setuid/setgid programs then? > > setuid root programs can use root's cache, perhaps a similar thing could > be done for other setuid programs, but what about setgid? > > perhaps don't cache at all for set*id programs (issetugid(2))? Per-user cache uses euid as the user identifier. So every setuid program will use the cache, which corresponds to its euid. But how can setgid affect the cache operations? Do you see some potential issue? With best regards, Michael Bushkov Rostov State University From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 19:22: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 0A7BD16A420 for ; Wed, 31 Aug 2005 19:22:34 +0000 (GMT) (envelope-from minimarmot@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B71F43D45 for ; Wed, 31 Aug 2005 19:22:32 +0000 (GMT) (envelope-from minimarmot@gmail.com) Received: by wproxy.gmail.com with SMTP id i4so179810wra for ; Wed, 31 Aug 2005 12:22:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=OOi7m4yTNGr8gJEGhWin3XmZYnaw72QVao8E2At7B0mulD5hoMokVhwQYr1wvOmFqbWURTn335O92OAPZYmUDT0s0z3Y6dBVKdOnxJW9utBPjIulfzl2zyJr4UMXIisFzm5UzWpqyp+WYiAXzDBXIPb1BGymaxisjImAmBUdNe4= Received: by 10.54.118.13 with SMTP id q13mr947631wrc; Wed, 31 Aug 2005 12:22:31 -0700 (PDT) Received: by 10.54.44.25 with HTTP; Wed, 31 Aug 2005 12:22:31 -0700 (PDT) Message-ID: <47d0403c05083112223e874ea8@mail.gmail.com> Date: Wed, 31 Aug 2005 19:22:31 +0000 From: Ben Kaduk To: Scott Long In-Reply-To: <4315CEEC.80100@samsco.org> Mime-Version: 1.0 References: <1125452228.740.3.camel@arbitor.homelinux.com> <47d0403c05083020044f6ac0be@mail.gmail.com> <4315CEEC.80100@samsco.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, Kyle Brooks Subject: Re: panic after removing usb flash drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 19:22:34 -0000 On 8/31/05, Scott Long wrote: >=20 > Ben Kaduk wrote: > > On 8/31/05, Kyle Brooks wrote: > > > >>umass0: LEXAR MEDIA JUMPDRIVE2, rev 2.00/1.25, addr 2 > >>umass0: at uhub4 port 6 (addr 2) disconnected > >>panic: vm_fault: fault on nofault entry, addr: deadc000 > >> > >>kernel: > >> > >>FreeBSD 7.0-CURRENT #2: Mon Aug 29 00:39:21 UTC 2005 > >> > >>problem: > >> > >>kernel panics when usb flash drive is removed > >> > >>backtrace: > >> > >>#0 doadump () at pcpu.h:165 > >>#1 0xc068610e in boot (howto=3D260) > >>at /usr/src/sys/kern/kern_shutdown.c:397 > >>#2 0xc0685b92 in panic ( > >>fmt=3D0xc090e46c "vm_fault: fault on nofault entry, addr: %lx") > >>at /usr/src/sys/kern/kern_shutdown.c:553 > >>#3 0xc0812de1 in vm_fault (map=3D0xc1060000, vaddr=3D3735928832, > >>fault_type=3D2 '\002', fault_flags=3D0) > >>at /usr/src/sys/vm/vm_fault.c:884 > >>#4 0xc0888807 in trap_pfault (frame=3D0xe6a06bf0, usermode=3D0, > >>eva=3D3735929110) > >>at /usr/src/sys/i386/i386/trap.c:741 > >>#5 0xc0888d04 in trap (frame=3D > >>{tf_fs =3D 8, tf_es =3D -1063649240, tf_ds =3D 40, tf_edi =3D -99387596= 8, > >>tf_esi =3D -1014223872, tf_ebp =3D -425694000, tf_isp =3D -425694180, t= f_ebx =3D > >>-1063640044, tf_edx =3D -993875900, tf_ecx =3D 0, tf_eax =3D -559038242= , > >>tf_trapno =3D 12, tf_err =3D 2, tf_eip =3D -1069194040, tf_cs =3D 32, t= f_eflags > >>=3D 66050, tf_esp =3D -1063640032, tf_ss =3D 0}) > >>at /usr/src/sys/i386/i386/trap.c:442 > >>#6 0xc08745ba in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > >>#7 0x00000008 in ?? () > >>#8 0xc09a0028 in atdma_acpi_driver_mod () > >>#9 0x00000028 in ?? () > >>#10 0xc4c2a800 in ?? () > >>#11 0xc38c2c00 in ?? () > >>#12 0xe6a06cd0 in ?? () > >>#13 0xe6a06c1c in ?? () > >>---Type to continue, or q to quit--- > >>#14 0xc09a2414 in xsoftc () > >>#15 0xc4c2a844 in ?? () > >>#16 0x00000000 in ?? () > >>#17 0xdeadc0de in ?? () > >>#18 0x0000000c in ?? () > >>#19 0x00000002 in ?? () > >>#20 0xc04564c8 in camisr (V_queue=3D0xc09a2414) > >>at /usr/src/sys/cam/cam_xpt.c:7066 > >>#21 0xc066f84e in ithread_loop (arg=3D0xc356fa80) > >>at /usr/src/sys/kern/kern_intr.c:545 > >>#22 0xc066e808 in fork_exit (callout=3D0xc066f665 , arg= =3D0x0, > >>frame=3D0x0) at /usr/src/sys/kern/kern_fork.c:789 > >>#23 0xc087461c in fork_trampoline () > >>at /usr/src/sys/i386/i386/exception.s:208 > >> > > > > This is the expected behaviour >=20 > Panics are not acceptable or expected behaviour in any situation, btw. >=20 > > if you didn't unmount the filesystem on the > > thumbdrive before removing it. There was some discussion on this a whil= e=20 > ago > > (but I don't seem to be able to find the exact posts), but the general= =20 > idea > > is that the kernel has no idea in what state the actual physical medium > > (disc) is/was in after being pulled, and may have some stale buffers=20 > holding > > data that got written to disk. It doesn't know what to do with this=20 > data, or > > how to treat requests to that device, so it panics. > > >=20 > I probably missed the earlier discussion that you are referring to, but > what you are saying here actually isn't true. There are a number of > problems: Sorry to be giving out bad information -- I really should have found the ol= d=20 discussions I remember before posting.=20 1) When the thumbdrive gets pulled, the umass driver gets told to > detach. It tries to detach itself from CAM, but things don't get torn > down correctly because there is an open reference to the target in CAM > (because there is a mounted filesystem on the device). umass truddles > along anyways and goes away, leaving lots of dangling pointers in CAM > that blow up on the next attempted I/O access. >=20 > Part of the problem here is that the umass driver is architected wrong. > It creates a SIM, bus, and target instance for every umass device that > gets inserted. When the device gets pulled, it tries to tear down > each of those instances all at once. CAM simply wasn't designed for > this. It was designed for the SIMs and buses to be long-lived objects > where only the targets (and luns) come and go. Making umass fit this > model would invlove turning it into two logical drivers. One would be > a SIM that would attach to the root hub instance of each USB controller > and would treat the USB bus as a CAM bus. The other would be a target > driver that gets created and destroyed on a per-device basis as those > devices come and go. When a umass device gets plugged in, the USB > framework would tell the apprpriate SIM to create a target instance. > When the device gets pulled, the framework would tell the SIM to detach > and destroy the target. No dangling pointers would be left behind by > the SIM going away. I have some prototype work in progress on this. >=20 > 2) Some filesystems, UFS in particular, assume that an I/O will never > fail. Instead of checking the error status of the buf on completion, > they just continue on and assume that everything is fine. If the > VM is trying to page in a vnode, for example, it'll think that > the operation succeeded, and then really bad things will happen. I'm > not sure if the same problem exists in MSDOSFS because I don't have > any DOS filesystems except on USB, and the problem with umass stands > in the way of further testing. In luei of fixing umass, I might have to > create a synthetic md device to hold a msdos filesystem so that I can > test how it behaves. >=20 > 3) It's unknown if the VM system knows how to rationally deal with > failed I/O or how to propagate that kind of failure to the rest of the > kernel and/or applications. What happens if you mmap a file, and then > the device holding the file goes away? How do you let the application > know that its mmap is now invalid? Send it a Sig11, maybe? How should > the vnode pager deal with failure? There are lots of interesting > problems here. >=20 > In any case, the panic posted in the grandparent message implicates CAM > and umass, which is what I would expect. There may be more layers of > problems underneath it. >=20 > Scott >=20 Thanks for the in-depth explanation. I will search the archives tonight to= =20 find the old discussion and see where I was misreading things. Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 19:35: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 3F8CA16A41F for ; Wed, 31 Aug 2005 19:35:42 +0000 (GMT) (envelope-from captinsmock@columbus.rr.com) Received: from ms-smtp-01-eri0.ohiordc.rr.com (ms-smtp-01-smtplb.ohiordc.rr.com [65.24.5.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D18343D49 for ; Wed, 31 Aug 2005 19:35:41 +0000 (GMT) (envelope-from captinsmock@columbus.rr.com) Received: from cpe-65-24-34-161.columbus.res.rr.com (cpe-65-24-34-161.columbus.res.rr.com [65.24.34.161]) by ms-smtp-01-eri0.ohiordc.rr.com (8.12.10/8.12.7) with ESMTP id j7VJZcWY007308; Wed, 31 Aug 2005 15:35:38 -0400 (EDT) From: Kyle Brooks To: Ben Kaduk In-Reply-To: <47d0403c05083112223e874ea8@mail.gmail.com> References: <1125452228.740.3.camel@arbitor.homelinux.com> <47d0403c05083020044f6ac0be@mail.gmail.com> <4315CEEC.80100@samsco.org> <47d0403c05083112223e874ea8@mail.gmail.com> Content-Type: text/plain Date: Wed, 31 Aug 2005 19:35:38 +0000 Message-Id: <1125516938.682.4.camel@arbitor.homelinux.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Cc: freebsd-current@freebsd.org Subject: Re: panic after removing usb flash drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 19:35:42 -0000 On Wed, 2005-08-31 at 19:22 +0000, Ben Kaduk wrote: > On 8/31/05, Scott Long wrote: > > > > Ben Kaduk wrote: > > > On 8/31/05, Kyle Brooks wrote: > > > > > >>umass0: LEXAR MEDIA JUMPDRIVE2, rev 2.00/1.25, addr 2 > > >>umass0: at uhub4 port 6 (addr 2) disconnected > > >>panic: vm_fault: fault on nofault entry, addr: deadc000 > > >> > > >>kernel: > > >> > > >>FreeBSD 7.0-CURRENT #2: Mon Aug 29 00:39:21 UTC 2005 > > >> > > >>problem: > > >> > > >>kernel panics when usb flash drive is removed > > >> > > >>backtrace: > > >> > > >>#0 doadump () at pcpu.h:165 > > >>#1 0xc068610e in boot (howto=260) > > >>at /usr/src/sys/kern/kern_shutdown.c:397 > > >>#2 0xc0685b92 in panic ( > > >>fmt=0xc090e46c "vm_fault: fault on nofault entry, addr: %lx") > > >>at /usr/src/sys/kern/kern_shutdown.c:553 > > >>#3 0xc0812de1 in vm_fault (map=0xc1060000, vaddr=3735928832, > > >>fault_type=2 '\002', fault_flags=0) > > >>at /usr/src/sys/vm/vm_fault.c:884 > > >>#4 0xc0888807 in trap_pfault (frame=0xe6a06bf0, usermode=0, > > >>eva=3735929110) > > >>at /usr/src/sys/i386/i386/trap.c:741 > > >>#5 0xc0888d04 in trap (frame= > > >>{tf_fs = 8, tf_es = -1063649240, tf_ds = 40, tf_edi = -993875968, > > >>tf_esi = -1014223872, tf_ebp = -425694000, tf_isp = -425694180, tf_ebx = > > >>-1063640044, tf_edx = -993875900, tf_ecx = 0, tf_eax = -559038242, > > >>tf_trapno = 12, tf_err = 2, tf_eip = -1069194040, tf_cs = 32, tf_eflags > > >>= 66050, tf_esp = -1063640032, tf_ss = 0}) > > >>at /usr/src/sys/i386/i386/trap.c:442 > > >>#6 0xc08745ba in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > > >>#7 0x00000008 in ?? () > > >>#8 0xc09a0028 in atdma_acpi_driver_mod () > > >>#9 0x00000028 in ?? () > > >>#10 0xc4c2a800 in ?? () > > >>#11 0xc38c2c00 in ?? () > > >>#12 0xe6a06cd0 in ?? () > > >>#13 0xe6a06c1c in ?? () > > >>---Type to continue, or q to quit--- > > >>#14 0xc09a2414 in xsoftc () > > >>#15 0xc4c2a844 in ?? () > > >>#16 0x00000000 in ?? () > > >>#17 0xdeadc0de in ?? () > > >>#18 0x0000000c in ?? () > > >>#19 0x00000002 in ?? () > > >>#20 0xc04564c8 in camisr (V_queue=0xc09a2414) > > >>at /usr/src/sys/cam/cam_xpt.c:7066 > > >>#21 0xc066f84e in ithread_loop (arg=0xc356fa80) > > >>at /usr/src/sys/kern/kern_intr.c:545 > > >>#22 0xc066e808 in fork_exit (callout=0xc066f665 , arg=0x0, > > >>frame=0x0) at /usr/src/sys/kern/kern_fork.c:789 > > >>#23 0xc087461c in fork_trampoline () > > >>at /usr/src/sys/i386/i386/exception.s:208 > > >> > > > > > > This is the expected behaviour > > > > Panics are not acceptable or expected behaviour in any situation, btw. > > > > > if you didn't unmount the filesystem on the > > > thumbdrive before removing it. There was some discussion on this a while > > ago > > > (but I don't seem to be able to find the exact posts), but the general > > idea > > > is that the kernel has no idea in what state the actual physical medium > > > (disc) is/was in after being pulled, and may have some stale buffers > > holding > > > data that got written to disk. It doesn't know what to do with this > > data, or > > > how to treat requests to that device, so it panics. > > > > > > > I probably missed the earlier discussion that you are referring to, but > > what you are saying here actually isn't true. There are a number of > > problems: > > > Sorry to be giving out bad information -- I really should have found the old > discussions I remember before posting. > > 1) When the thumbdrive gets pulled, the umass driver gets told to > > detach. It tries to detach itself from CAM, but things don't get torn > > down correctly because there is an open reference to the target in CAM > > (because there is a mounted filesystem on the device). umass truddles > > along anyways and goes away, leaving lots of dangling pointers in CAM > > that blow up on the next attempted I/O access. > > > > Part of the problem here is that the umass driver is architected wrong. > > It creates a SIM, bus, and target instance for every umass device that > > gets inserted. When the device gets pulled, it tries to tear down > > each of those instances all at once. CAM simply wasn't designed for > > this. It was designed for the SIMs and buses to be long-lived objects > > where only the targets (and luns) come and go. Making umass fit this > > model would invlove turning it into two logical drivers. One would be > > a SIM that would attach to the root hub instance of each USB controller > > and would treat the USB bus as a CAM bus. The other would be a target > > driver that gets created and destroyed on a per-device basis as those > > devices come and go. When a umass device gets plugged in, the USB > > framework would tell the apprpriate SIM to create a target instance. > > When the device gets pulled, the framework would tell the SIM to detach > > and destroy the target. No dangling pointers would be left behind by > > the SIM going away. I have some prototype work in progress on this. > > > > 2) Some filesystems, UFS in particular, assume that an I/O will never > > fail. Instead of checking the error status of the buf on completion, > > they just continue on and assume that everything is fine. If the > > VM is trying to page in a vnode, for example, it'll think that > > the operation succeeded, and then really bad things will happen. I'm > > not sure if the same problem exists in MSDOSFS because I don't have > > any DOS filesystems except on USB, and the problem with umass stands > > in the way of further testing. In luei of fixing umass, I might have to > > create a synthetic md device to hold a msdos filesystem so that I can > > test how it behaves. > > > > 3) It's unknown if the VM system knows how to rationally deal with > > failed I/O or how to propagate that kind of failure to the rest of the > > kernel and/or applications. What happens if you mmap a file, and then > > the device holding the file goes away? How do you let the application > > know that its mmap is now invalid? Send it a Sig11, maybe? How should > > the vnode pager deal with failure? There are lots of interesting > > problems here. > > > > In any case, the panic posted in the grandparent message implicates CAM > > and umass, which is what I would expect. There may be more layers of > > problems underneath it. > > > > Scott > > > > Thanks for the in-depth explanation. I will search the archives tonight to > find the old discussion and see where I was misreading things. > > Ben Kaduk > _______________________________________________ > 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" I did not notice this before but after leaving the device in the drive for about 10 minutes the following kernel messages appear: umass0: LEXAR MEDIA JUMPDRIVE2, rev 2.00/1.25, addr 2 (da0:umass-sim0:0:0:0): got CAM status 0x4 (da0:umass-sim0:0:0:0): fatal error, failed to attach to device (da0:umass-sim0:0:0:0): lost device The device file never shows up in the /dev directory From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 19:38: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 5BD1A16A41F for ; Wed, 31 Aug 2005 19:38:49 +0000 (GMT) (envelope-from captinsmock@columbus.rr.com) Received: from ms-smtp-02-eri0.ohiordc.rr.com (ms-smtp-02-smtplb.ohiordc.rr.com [65.24.5.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2D3E43D45 for ; Wed, 31 Aug 2005 19:38:48 +0000 (GMT) (envelope-from captinsmock@columbus.rr.com) Received: from cpe-65-24-34-161.columbus.res.rr.com (cpe-65-24-34-161.columbus.res.rr.com [65.24.34.161]) by ms-smtp-02-eri0.ohiordc.rr.com (8.12.10/8.12.7) with ESMTP id j7VJckXV011444; Wed, 31 Aug 2005 15:38:46 -0400 (EDT) From: Kyle Brooks To: Ben Kaduk In-Reply-To: <47d0403c05083112334da7cfee@mail.gmail.com> References: <1125452228.740.3.camel@arbitor.homelinux.com> <47d0403c05083020044f6ac0be@mail.gmail.com> <1125516236.682.2.camel@arbitor.homelinux.com> <47d0403c05083112334da7cfee@mail.gmail.com> Content-Type: text/plain Date: Wed, 31 Aug 2005 19:38:45 +0000 Message-Id: <1125517125.682.7.camel@arbitor.homelinux.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Cc: freebsd-current@freebsd.org Subject: Re: panic after removing usb flash drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 19:38:49 -0000 On Wed, 2005-08-31 at 19:33 +0000, Ben Kaduk wrote: > > > On 8/31/05, Kyle Brooks wrote: > On Wed, 2005-08-31 at 03:04 +0000, Ben Kaduk wrote: > > > > > > On 8/31/05, Kyle Brooks wrote: > > umass0: LEXAR MEDIA JUMPDRIVE2, rev 2.00/1.25, addr > 2 > > umass0: at uhub4 port 6 (addr 2) disconnected > > panic: vm_fault: fault on nofault entry, addr: > deadc000 > > > > kernel: > > > > FreeBSD 7.0-CURRENT #2: Mon Aug 29 00:39:21 UTC 2005 > > > > problem: > > > > kernel panics when usb flash drive is removed > > > > backtrace: > > > > #0 doadump () at pcpu.h:165 > > #1 0xc068610e in boot (howto=260) > > at /usr/src/sys/kern/kern_shutdown.c:397 > > #2 0xc0685b92 in panic ( > > fmt=0xc090e46c "vm_fault: fault on nofault > entry, addr: % > > lx") > > at /usr/src/sys/kern/kern_shutdown.c:553 > > #3 0xc0812de1 in vm_fault (map=0xc1060000, > vaddr=3735928832, > > fault_type=2 '\002', fault_flags=0) > > at /usr/src/sys/vm/vm_fault.c:884 > > #4 0xc0888807 in trap_pfault (frame=0xe6a06bf0, > usermode=0, > > eva=3735929110) > > at /usr/src/sys/i386/i386/trap.c:741 > > #5 0xc0888d04 in trap (frame= > > {tf_fs = 8, tf_es = -1063649240, tf_ds = 40, > tf_edi = > > -993875968, > > tf_esi = -1014223872, tf_ebp = -425694000, tf_isp = > > -425694180, tf_ebx = > > -1063640044, tf_edx = -993875900, tf_ecx = 0, tf_eax > = > > -559038242, > > tf_trapno = 12, tf_err = 2, tf_eip = -1069194040, > tf_cs = 32, > > tf_eflags > > = 66050, tf_esp = -1063640032, tf_ss = 0}) > > at /usr/src/sys/i386/i386/trap.c:442 > > #6 0xc08745ba in calltrap () > > at /usr/src/sys/i386/i386/exception.s:139 > > #7 0x00000008 in ?? () > > #8 0xc09a0028 in atdma_acpi_driver_mod () > > #9 0x00000028 in ?? () > > #10 0xc4c2a800 in ?? () > > #11 0xc38c2c00 in ?? () > > #12 0xe6a06cd0 in ?? () > > #13 0xe6a06c1c in ?? () > > ---Type to continue, or q to > quit--- > > #14 0xc09a2414 in xsoftc () > > #15 0xc4c2a844 in ?? () > > #16 0x00000000 in ?? () > > #17 0xdeadc0de in ?? () > > #18 0x0000000c in ?? () > > #19 0x00000002 in ?? () > > #20 0xc04564c8 in camisr (V_queue=0xc09a2414) > > at /usr/src/sys/cam/cam_xpt.c:7066 > > #21 0xc066f84e in ithread_loop (arg=0xc356fa80) > > at /usr/src/sys/kern/kern_intr.c:545 > > #22 0xc066e808 in fork_exit (callout=0xc066f665 > > , arg=0x0, > > frame=0x0) at /usr/src/sys/kern/kern_fork.c:789 > > #23 0xc087461c in fork_trampoline () > > at /usr/src/sys/i386/i386/exception.s:208 > > > > _______________________________________________ > > 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" > > > > This is the expected behaviour if you didn't unmount the > filesystem on > > the thumbdrive before removing it. There was some > discussion on this > > a while ago (but I don't seem to be able to find the exact > posts), but > > the general idea is that the kernel has no idea in what > state the > > actual physical medium (disc) is/was in after being pulled, > and may > > have some stale buffers holding data that got written to > disk. It > > doesn't know what to do with this data, or how to treat > requests to > > that device, so it panics. > > > > Of course, if you did unmount the filesystem before pulling > the drive, > > then this shoule be looked into. > > > > Ben Kaduk > > I was never able to mount the device, it was detected as > umass0, then i > removed it nothing else, it was not mounted sorry for not > specifying. > > > Curious. It turns out that my original explanation was in error, > Scott Long has posted an excellent explanation of the bug I was > attempting to describe, on freebsd-current@freebsd.org, recently: > http://lists.freebsd.org/pipermail/freebsd-current/2005-August/055036.html > > I suspect that other, more qualified people will be interested in > tracking down what's happening with your system -- perhaps you should > post again to -current with what you just told me. > > Sorry if I have been misleading > > Ben Kaduk It no longer panics when removed if you wait for these messages to appear. Sorry for missing this. From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 19:46: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 231C816A41F; Wed, 31 Aug 2005 19:46:13 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB0C243D46; Wed, 31 Aug 2005 19:46:12 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j7VJkCO1002691; Wed, 31 Aug 2005 12:46:12 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j7VJkC7E002690; Wed, 31 Aug 2005 12:46:12 -0700 Date: Wed, 31 Aug 2005 12:46:12 -0700 From: Brooks Davis To: Robert Watson Message-ID: <20050831194612.GG32477@odin.ac.hmc.edu> References: <20050831120730.B39418@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050831120730.B39418@fledge.watson.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: current@freebsd.org Subject: Re: Ctrl-c abort of dhclient during rc.d start aborts all network configuration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 19:46:13 -0000 On Wed, Aug 31, 2005 at 12:10:44PM +0100, Robert Watson wrote: > > I believe this is related to the new dhclient -- when I run my notebook > disconnected from the network, the boot pauses for about 15-20 seconds > waiting for a link on xl0. Being impatient when booting in airports just > before my flight, I like to hit Ctrl-C and abort it, since I know that > there will be no link. In the old world order, this was fine, dhclient > was simply killed and all was good. In the new world order, it kills all > of the netif startup script, and for some reason (ordering related, > presumably), this prevents 127.0.0.1 from being configured on lo0, which > causes a number of applications to die, since 0.0.0.0 cannot be bound. It > sounds like a couple of things are unfortunate here: The wait should be 10 seconds plus some startup time. > (1) It would be good to configure lo0 first. Interfaces are configured in order of index by default. If lo0 were attached sooner, it would be configured sooner. I'm somewhat tempted to change it from it's current (apparently bogus) position in the startup process at SI_SUB_PROTO_IFATTACHDOMAIN to SI_SUB_INIT_IF/SI_ORDER_ANY and push the l2com attachments from SI_ORDER_ANY to SI_ORDER_MIDDLE. Strictly speaking I think lo(4) should be SI_SUB_PSEUDO, but moving it up so it attached first makes some sense given how critical it is. Alternativly, one could add code to sort the result of "ifconfig -l" to configure lo0 first. > (2) If a dhclient is ctrl-c'd, it would be nice if the rest of the network > configuration continued. I don't see any code in the startup scripts that would cause them to exit on failure so the issue is probalby that the signal is being delivered to the /etc/rc.d/netif instance. I don't really know what the solution to that is. > The printing of '.'s in dhclient is also a bit excessive. Hanging with no output seems even less unhelpful. :( Longer term I want to get rid of syncronous calls to dhclient in the startup process, but I haven't had time to work on it and IMO, it's a bit late in the game for 6.0. -- Brooks From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 19:48: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 CEE1116A41F for ; Wed, 31 Aug 2005 19:48:17 +0000 (GMT) (envelope-from jilles@stack.nl) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 678A743D45 for ; Wed, 31 Aug 2005 19:48:17 +0000 (GMT) (envelope-from jilles@stack.nl) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mailhost.stack.nl (Postfix) with ESMTP id 9B8B3A310F; Wed, 31 Aug 2005 21:48:08 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 7F1342287D; Wed, 31 Aug 2005 21:48:08 +0200 (CEST) Date: Wed, 31 Aug 2005 21:48:08 +0200 From: Jilles Tjoelker To: Michael Bushkov Message-ID: <20050831194808.GA12742@stack.nl> References: <20050827170633.Y5409@stinger.cc.rsu.ru> <43123F3B.8070002@FreeBSD.org> <20050829115740.N5409@stinger.cc.rsu.ru> <20050829163025.GA25664@dan.emsphone.com> <20050830172127.E5409@stinger.cc.rsu.ru> <20050831190059.GA23652@stack.nl> <20050831231233.T72814@stinger.cc.rsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050831231233.T72814@stinger.cc.rsu.ru> X-Operating-System: FreeBSD 5.4-RELEASE i386 User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org, Dan Nelson Subject: Re: [PATCH] caching daemon release and nsswitch patches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 19:48:17 -0000 On Wed, Aug 31, 2005 at 11:18:19PM +0400, Michael Bushkov wrote: > >On Tue, Aug 30, 2005 at 05:32:52PM +0400, Michael Bushkov wrote: > >>We can't ensure that, I guess. In the upcoming version (before the 1st of > >>September), the cache would be per-user. This would solve all the security > >>problems. In a little while, I'll implement the ability for cached to act > >>as nscd. So you'll be able to choose the behaviour. > >What about setuid/setgid programs then? > >setuid root programs can use root's cache, perhaps a similar thing could > >be done for other setuid programs, but what about setgid? > >perhaps don't cache at all for set*id programs (issetugid(2))? > Per-user cache uses euid as the user identifier. So every setuid program > will use the cache, which corresponds to its euid. > But how can setgid affect the cache operations? Do you see some potential > issue? User X puts some garbled information in the cache for his uid, then starts a setgid program. That setgid program will use the bad data in the cache which is potentially exploitable. -- Jilles Tjoelker From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 19:56: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 6874016A41F for ; Wed, 31 Aug 2005 19:56:10 +0000 (GMT) (envelope-from bushman@rsu.ru) Received: from mail.r61.net (mail.r61.net [195.208.245.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 781B343D46 for ; Wed, 31 Aug 2005 19:56:09 +0000 (GMT) (envelope-from bushman@rsu.ru) Received: from stinger.cc.rsu.ru (stinger.cc.rsu.ru [195.208.252.82]) by mail.r61.net (8.13.4/8.13.4) with ESMTP id j7VJtv8b020053; Wed, 31 Aug 2005 23:55:57 +0400 (MSD) (envelope-from bushman@rsu.ru) Date: Thu, 1 Sep 2005 00:00:09 +0400 (MSD) From: Michael Bushkov X-X-Sender: bushman@stinger.cc.rsu.ru To: Jilles Tjoelker In-Reply-To: <20050831194808.GA12742@stack.nl> Message-ID: <20050831235458.L72814@stinger.cc.rsu.ru> References: <20050827170633.Y5409@stinger.cc.rsu.ru> <43123F3B.8070002@FreeBSD.org> <20050829115740.N5409@stinger.cc.rsu.ru> <20050829163025.GA25664@dan.emsphone.com> <20050830172127.E5409@stinger.cc.rsu.ru> <20050831190059.GA23652@stack.nl> <20050831231233.T72814@stinger.cc.rsu.ru> <20050831194808.GA12742@stack.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.86.2, clamav-milter version 0.86 on asterix.r61.net X-Virus-Status: Clean X-Spam-Status: No, score=-5.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on asterix.r61.net Cc: freebsd-current@freebsd.org, Dan Nelson Subject: Re: [PATCH] caching daemon release and nsswitch patches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 19:56:10 -0000 On Wed, 31 Aug 2005, Jilles Tjoelker wrote: > On Wed, Aug 31, 2005 at 11:18:19PM +0400, Michael Bushkov wrote: >>> On Tue, Aug 30, 2005 at 05:32:52PM +0400, Michael Bushkov wrote: >>>> We can't ensure that, I guess. In the upcoming version (before the 1st of >>>> September), the cache would be per-user. This would solve all the security >>>> problems. In a little while, I'll implement the ability for cached to act >>>> as nscd. So you'll be able to choose the behaviour. > >>> What about setuid/setgid programs then? > >>> setuid root programs can use root's cache, perhaps a similar thing could >>> be done for other setuid programs, but what about setgid? > >>> perhaps don't cache at all for set*id programs (issetugid(2))? >> Per-user cache uses euid as the user identifier. So every setuid program >> will use the cache, which corresponds to its euid. >> But how can setgid affect the cache operations? Do you see some potential >> issue? > > User X puts some garbled information in the cache for his uid, then > starts a setgid program. That setgid program will use the bad data > in the cache which is potentially exploitable. Yes - you're right. I see 2 solutions: 1) The thing that you said - to turn off the caching for set*id programs 2) To separate users in the cache not only by their euid, but by their euid and egid together. In this case, if user X poisons the cache and starts the setgid program, then it will use the different (not poisoned) cache. I don't think that such a partitioning will cause the cache to grow too much. With best regards, Michael Bushkov Rostov State University From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 20:11: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 82C6216A41F for ; Wed, 31 Aug 2005 20:11:20 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2896843D45 for ; Wed, 31 Aug 2005 20:11:19 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j7VKBHeJ007241; Wed, 31 Aug 2005 13:11:17 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j7VKBGV0007240; Wed, 31 Aug 2005 13:11:16 -0700 Date: Wed, 31 Aug 2005 13:11:16 -0700 From: Brooks Davis To: Michael Bushkov Message-ID: <20050831201116.GH32477@odin.ac.hmc.edu> References: <20050827170633.Y5409@stinger.cc.rsu.ru> <43123F3B.8070002@FreeBSD.org> <20050829115740.N5409@stinger.cc.rsu.ru> <20050829163025.GA25664@dan.emsphone.com> <20050830172127.E5409@stinger.cc.rsu.ru> <20050831190059.GA23652@stack.nl> <20050831231233.T72814@stinger.cc.rsu.ru> <20050831194808.GA12742@stack.nl> <20050831235458.L72814@stinger.cc.rsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050831235458.L72814@stinger.cc.rsu.ru> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: freebsd-current@freebsd.org, Dan Nelson , Jilles Tjoelker Subject: Re: [PATCH] caching daemon release and nsswitch patches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 20:11:20 -0000 On Thu, Sep 01, 2005 at 12:00:09AM +0400, Michael Bushkov wrote: > On Wed, 31 Aug 2005, Jilles Tjoelker wrote: > > >On Wed, Aug 31, 2005 at 11:18:19PM +0400, Michael Bushkov wrote: > >>>On Tue, Aug 30, 2005 at 05:32:52PM +0400, Michael Bushkov wrote: > >>>>We can't ensure that, I guess. In the upcoming version (before the 1st > >>>>of > >>>>September), the cache would be per-user. This would solve all the > >>>>security > >>>>problems. In a little while, I'll implement the ability for cached to > >>>>act > >>>>as nscd. So you'll be able to choose the behaviour. > > > >>>What about setuid/setgid programs then? > > > >>>setuid root programs can use root's cache, perhaps a similar thing could > >>>be done for other setuid programs, but what about setgid? > > > >>>perhaps don't cache at all for set*id programs (issetugid(2))? > >>Per-user cache uses euid as the user identifier. So every setuid program > >>will use the cache, which corresponds to its euid. > >>But how can setgid affect the cache operations? Do you see some potential > >>issue? > > > >User X puts some garbled information in the cache for his uid, then > >starts a setgid program. That setgid program will use the bad data > >in the cache which is potentially exploitable. > Yes - you're right. I see 2 solutions: > > 1) The thing that you said - to turn off the caching for set*id programs > > 2) To separate users in the cache not only by their euid, but by their > euid and egid together. In this case, if user X poisons the cache and > starts the setgid program, then it will use the different (not poisoned) > cache. I don't think that such a partitioning will cause the cache to grow > too much. I'd be inclined toward the first option. Getting edge cases right for suid apps requires lots of thinking so I'd rather just not support the feature initially. Performance critical suid applications probably aren't too common anyway. -- Brooks From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 20:17:13 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 E099616A41F for ; Wed, 31 Aug 2005 20:17:13 +0000 (GMT) (envelope-from bushman@rsu.ru) Received: from mail.r61.net (mail.r61.net [195.208.245.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DA2A43D46 for ; Wed, 31 Aug 2005 20:17:12 +0000 (GMT) (envelope-from bushman@rsu.ru) Received: from stinger.cc.rsu.ru (stinger.cc.rsu.ru [195.208.252.82]) by mail.r61.net (8.13.4/8.13.4) with ESMTP id j7VKGrNu023238; Thu, 1 Sep 2005 00:16:53 +0400 (MSD) (envelope-from bushman@rsu.ru) Date: Thu, 1 Sep 2005 00:21:05 +0400 (MSD) From: Michael Bushkov X-X-Sender: bushman@stinger.cc.rsu.ru To: Brooks Davis In-Reply-To: <20050831201116.GH32477@odin.ac.hmc.edu> Message-ID: <20050901001719.Q72814@stinger.cc.rsu.ru> References: <20050827170633.Y5409@stinger.cc.rsu.ru> <43123F3B.8070002@FreeBSD.org> <20050829115740.N5409@stinger.cc.rsu.ru> <20050829163025.GA25664@dan.emsphone.com> <20050830172127.E5409@stinger.cc.rsu.ru> <20050831190059.GA23652@stack.nl> <20050831231233.T72814@stinger.cc.rsu.ru> <20050831194808.GA12742@stack.nl> <20050831235458.L72814@stinger.cc.rsu.ru> <20050831201116.GH32477@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.86.2, clamav-milter version 0.86 on asterix.r61.net X-Virus-Status: Clean X-Spam-Status: No, score=-5.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on asterix.r61.net Cc: freebsd-current@freebsd.org, Dan Nelson , Jilles Tjoelker Subject: Re: [PATCH] caching daemon release and nsswitch patches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 20:17:14 -0000 Hello! >>> User X puts some garbled information in the cache for his uid, then >>> starts a setgid program. That setgid program will use the bad data >>> in the cache which is potentially exploitable. >> Yes - you're right. I see 2 solutions: >> >> 1) The thing that you said - to turn off the caching for set*id programs >> >> 2) To separate users in the cache not only by their euid, but by their >> euid and egid together. In this case, if user X poisons the cache and >> starts the setgid program, then it will use the different (not poisoned) >> cache. I don't think that such a partitioning will cause the cache to grow >> too much. > > I'd be inclined toward the first option. Getting edge cases right for > suid apps requires lots of thinking so I'd rather just not support the > feature initially. Performance critical suid applications probably > aren't too common anyway. Ok - I'm absolutely agreed. I'll do it this way. With best regards, Michael Bushkov Rostov State University From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 20:26: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 BDEF616A41F; Wed, 31 Aug 2005 20:26:24 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E4C643D45; Wed, 31 Aug 2005 20:26:24 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin01-en2 [10.13.10.146]) by smtpout.mac.com (Xserve/8.12.11/smtpout05/MantshX 4.0) with ESMTP id j7VKQNhd013443; Wed, 31 Aug 2005 13:26:24 -0700 (PDT) Received: from [10.1.1.209] (nfw1.codefab.com [199.103.21.225]) (authenticated bits=0) by mac.com (Xserve/smtpin01/MantshX 4.0) with ESMTP id j7VKQLSm026003; Wed, 31 Aug 2005 13:26:22 -0700 (PDT) In-Reply-To: <20050831194612.GG32477@odin.ac.hmc.edu> References: <20050831120730.B39418@fledge.watson.org> <20050831194612.GG32477@odin.ac.hmc.edu> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <932461F5-1E5B-4E6C-9109-97A54C128EE5@mac.com> Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Wed, 31 Aug 2005 16:26:17 -0400 To: Brooks Davis X-Mailer: Apple Mail (2.734) Cc: Robert Watson , current@freebsd.org Subject: Re: Ctrl-c abort of dhclient during rc.d start aborts all network configuration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 20:26:24 -0000 On Aug 31, 2005, at 3:46 PM, Brooks Davis wrote: >> (2) If a dhclient is ctrl-c'd, it would be nice if the rest of the >> network >> configuration continued. > > I don't see any code in the startup scripts that would cause them to > exit on failure so the issue is probalby that the signal is being > delivered to the /etc/rc.d/netif instance. I don't really know > what the > solution to that is. Add: trap "" 2 3 ...to the beginning of /etc/rc.d/netif, and a "trap 2 3" at the end, so the shell ignores SIGQUIT (aka Control-C)? -- -Chuck From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 20:36: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 D6DD716A41F for ; Wed, 31 Aug 2005 20:36:01 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 440A943D49 for ; Wed, 31 Aug 2005 20:36:01 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[10.50.40.201]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Wed, 31 Aug 2005 16:51:20 -0400 From: John Baldwin To: current@FreeBSD.org Date: Wed, 31 Aug 2005 16:36:48 -0400 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508311636.49278.jhb@FreeBSD.org> Cc: Subject: [PATCH] Locking fixes for tl(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 20:36:02 -0000 Patch fixes locking for tl(4) and marks it MPSAFE. Please test, thanks! http://www.FreeBSD.org/~jhb/patches/tl_locking.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 Aug 31 20:36: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 DBE1C16A420 for ; Wed, 31 Aug 2005 20:36:01 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43F3C43D48 for ; Wed, 31 Aug 2005 20:36:01 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[10.50.40.201]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Wed, 31 Aug 2005 16:51:20 -0400 From: John Baldwin To: current@FreeBSD.org Date: Wed, 31 Aug 2005 16:36:51 -0400 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508311636.51741.jhb@FreeBSD.org> Cc: Subject: [PATCH] Locking fixes for wb(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 20:36:02 -0000 Patch fixes locking for wb(4) and marks it MPSAFE. Please test, thanks! http://www.FreeBSD.org/~jhb/patches/wb_locking.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 Aug 31 20:38:43 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 14AE716A41F for ; Wed, 31 Aug 2005 20:38:43 +0000 (GMT) (envelope-from flynn@energyhq.es.eu.org) Received: from mindfields.energyhq.es.eu.org (73.Red-213-97-200.pooles.rima-tde.net [213.97.200.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67F0C43D45 for ; Wed, 31 Aug 2005 20:38:39 +0000 (GMT) (envelope-from flynn@energyhq.es.eu.org) Received: from scienide.energyhq.es.eu.org (scienide.energyhq.es.eu.org [192.168.100.1]) by mindfields.energyhq.es.eu.org (Postfix) with SMTP id E7CB3123FDD; Wed, 31 Aug 2005 22:38:36 +0200 (CEST) Date: Wed, 31 Aug 2005 22:37:49 +0200 From: Miguel Mendez To: Mikhail Teterin Message-Id: <20050831223749.6db2ccc3.flynn@energyhq.es.eu.org> In-Reply-To: <200508301223.20626.mi+mx@aldan.algebra.com> References: <200508281326.j7SDQGfc073329@blue.virtual-estates.net> <20050829191927.6694a969.flynn@energyhq.es.eu.org> <200508301223.20626.mi+mx@aldan.algebra.com> X-Mailer: Sylpheed version 2.0.0 (GTK+ 2.6.9; amd64-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: installing 6.0-BETA3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 20:38:43 -0000 On Tue, 30 Aug 2005 12:23:20 -0400 Mikhail Teterin wrote: > > If the card is a 16bit pcmcia card make sure the bridge is set to 16bit. > > How do I do that? On my old Thinkpad you had to access the BIOS and there were pcmcia settings in one of the menus. It was set to 16bit, changing it made it possible to use a realtek8139-based cardbus card. This was in the 5.0-CURRENT days, btw, so YMMV. > > I wouldn't blame WITNESS on this. Laptops, especially old ones, have > > incredibly slow disks. The buildworld process is heavily i/o bounded, > > my bet is on the disk subsystem. > > According to systat and top, the CPU is never idle -- as would've been the > case, if the I/O were the limiting factor. The Sys-component of `systat -vm' > was steadily above 50%. > > Now that I have a witness-less kernel, the builds are, indeed, I/O bound. Out of curiosity, how long does it take now for a buildworld run? The only full world build I ever did on my old laptop was for OpenBSD and I left overnight. Cheers, -- Miguel Mendez http://www.energyhq.es.eu.org PGP Key: 0xDC8514F1 From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 20:42:59 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 6BB7916A41F for ; Wed, 31 Aug 2005 20:42:59 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0074943D45 for ; Wed, 31 Aug 2005 20:42:58 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 5B3D046C14; Wed, 31 Aug 2005 16:42:58 -0400 (EDT) Date: Wed, 31 Aug 2005 21:42:58 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Brooks Davis In-Reply-To: <20050831194612.GG32477@odin.ac.hmc.edu> Message-ID: <20050831213925.M83712@fledge.watson.org> References: <20050831120730.B39418@fledge.watson.org> <20050831194612.GG32477@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: Ctrl-c abort of dhclient during rc.d start aborts all network configuration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 20:42:59 -0000 On Wed, 31 Aug 2005, Brooks Davis wrote: > The wait should be 10 seconds plus some startup time. It seemed a bit longer, but maybe I was counting fast. I'll time it next time and see if there's more going on there. >> (1) It would be good to configure lo0 first. > > Interfaces are configured in order of index by default. If lo0 were > attached sooner, it would be configured sooner. I'm somewhat tempted to > change it from it's current (apparently bogus) position in the startup > process at SI_SUB_PROTO_IFATTACHDOMAIN to SI_SUB_INIT_IF/SI_ORDER_ANY > and push the l2com attachments from SI_ORDER_ANY to SI_ORDER_MIDDLE. > Strictly speaking I think lo(4) should be SI_SUB_PSEUDO, but moving it > up so it attached first makes some sense given how critical it is. > > Alternativly, one could add code to sort the result of "ifconfig -l" to > configure lo0 first. I wonder if we could sed out lo0 from the automatic list and just configure it first by fiat? While if_loop is in theory optional, it turns out not to be very practical using our default boot scripts (since many tools assume you can bind 0.0.0.0). >> (2) If a dhclient is ctrl-c'd, it would be nice if the rest of the network >> configuration continued. > > I don't see any code in the startup scripts that would cause them to > exit on failure so the issue is probalby that the signal is being > delivered to the /etc/rc.d/netif instance. I don't really know what the > solution to that is. Me neither. All I know is that I don't remember seeing this before. >> The printing of '.'s in dhclient is also a bit excessive. > > Hanging with no output seems even less unhelpful. :( Longer term I want > to get rid of syncronous calls to dhclient in the startup process, but I > haven't had time to work on it and IMO, it's a bit late in the game for > 6.0. I thought a bit about this, but concluded that we probably still have components that assume a one IP (no more, no less) world, and slide by now due to luck. A gradual conversion towards the assumptions of changing IPs has been happening over time (vis natd -dynamic), but perhaps we need to accelerate it some by forcing the issue in 7.x after 6.0 gets out the door? Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 20:56:15 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 69C8B16A41F; Wed, 31 Aug 2005 20:56:15 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 061F343D46; Wed, 31 Aug 2005 20:56:14 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j7VKuE3b014564; Wed, 31 Aug 2005 13:56:14 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j7VKuEbJ014561; Wed, 31 Aug 2005 13:56:14 -0700 Date: Wed, 31 Aug 2005 13:56:14 -0700 From: Brooks Davis To: Charles Swiger Message-ID: <20050831205614.GI32477@odin.ac.hmc.edu> References: <20050831120730.B39418@fledge.watson.org> <20050831194612.GG32477@odin.ac.hmc.edu> <932461F5-1E5B-4E6C-9109-97A54C128EE5@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <932461F5-1E5B-4E6C-9109-97A54C128EE5@mac.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: Robert Watson , current@freebsd.org Subject: Re: Ctrl-c abort of dhclient during rc.d start aborts all network configuration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 20:56:15 -0000 On Wed, Aug 31, 2005 at 04:26:17PM -0400, Charles Swiger wrote: > On Aug 31, 2005, at 3:46 PM, Brooks Davis wrote: > >>(2) If a dhclient is ctrl-c'd, it would be nice if the rest of the > >>network > >> configuration continued. > > > >I don't see any code in the startup scripts that would cause them to > >exit on failure so the issue is probalby that the signal is being > >delivered to the /etc/rc.d/netif instance. I don't really know > >what the > >solution to that is. > > Add: > > trap "" 2 3 > > ...to the beginning of /etc/rc.d/netif, and a "trap 2 3" at the end, > so the shell ignores SIGQUIT (aka Control-C)? Thanks, that reminded me where to looks. I think I'll probably /etc/rc.d/fsck's example and add: trap : 3 -- Brooks From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 21:05: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 6C51E16A41F; Wed, 31 Aug 2005 21:05:08 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D91243D6E; Wed, 31 Aug 2005 21:04:57 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j7VL4v9o015815; Wed, 31 Aug 2005 14:04:57 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j7VL4vSu015814; Wed, 31 Aug 2005 14:04:57 -0700 Date: Wed, 31 Aug 2005 14:04:57 -0700 From: Brooks Davis To: Robert Watson Message-ID: <20050831210457.GJ32477@odin.ac.hmc.edu> References: <20050831120730.B39418@fledge.watson.org> <20050831194612.GG32477@odin.ac.hmc.edu> <20050831213925.M83712@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050831213925.M83712@fledge.watson.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: current@FreeBSD.org Subject: Re: Ctrl-c abort of dhclient during rc.d start aborts all network configuration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 21:05:08 -0000 On Wed, Aug 31, 2005 at 09:42:58PM +0100, Robert Watson wrote: > > On Wed, 31 Aug 2005, Brooks Davis wrote: > > >The wait should be 10 seconds plus some startup time. > > It seemed a bit longer, but maybe I was counting fast. I'll time it next > time and see if there's more going on there. It seems longer, but here's what I got with a quick trial: # time dhclient em0 em0: no link .............. giving up 11.05 real 0.00 user 0.01 sys > >>(1) It would be good to configure lo0 first. > > > >Interfaces are configured in order of index by default. If lo0 were > >attached sooner, it would be configured sooner. I'm somewhat tempted to > >change it from it's current (apparently bogus) position in the startup > >process at SI_SUB_PROTO_IFATTACHDOMAIN to SI_SUB_INIT_IF/SI_ORDER_ANY > >and push the l2com attachments from SI_ORDER_ANY to SI_ORDER_MIDDLE. > >Strictly speaking I think lo(4) should be SI_SUB_PSEUDO, but moving it > >up so it attached first makes some sense given how critical it is. > > > >Alternativly, one could add code to sort the result of "ifconfig -l" to > >configure lo0 first. > > I wonder if we could sed out lo0 from the automatic list and just > configure it first by fiat? While if_loop is in theory optional, it turns > out not to be very practical using our default boot scripts (since many > tools assume you can bind 0.0.0.0). That's probably a good idea though we don't have sed yet at this point in the process. I believe in practice, if you have either INET or INET6 compiled in and don't load lo you'll panic in the routing code. > >>(2) If a dhclient is ctrl-c'd, it would be nice if the rest of the network > >> configuration continued. > > > >I don't see any code in the startup scripts that would cause them to > >exit on failure so the issue is probalby that the signal is being > >delivered to the /etc/rc.d/netif instance. I don't really know what the > >solution to that is. > > Me neither. All I know is that I don't remember seeing this before. I think I'll add a "trap : 3" like fsck has. > >>The printing of '.'s in dhclient is also a bit excessive. > > > >Hanging with no output seems even less unhelpful. :( Longer term I want > >to get rid of syncronous calls to dhclient in the startup process, but I > >haven't had time to work on it and IMO, it's a bit late in the game for > >6.0. > > I thought a bit about this, but concluded that we probably still have > components that assume a one IP (no more, no less) world, and slide by now > due to luck. A gradual conversion towards the assumptions of changing IPs > has been happening over time (vis natd -dynamic), but perhaps we need to > accelerate it some by forcing the issue in 7.x after 6.0 gets out the > door? I definitely think this is something we need to work on for 7.x. Fortunately, I think Apple has probably shaken out the bugs in the big applications like bind and apache since they have a nice, dynamic interface configuration process. -- Brooks From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 21:46: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 659AB16A421 for ; Wed, 31 Aug 2005 21:46:17 +0000 (GMT) (envelope-from freebsd@powered.net) Received: from relay.xpto.com (xpto.brasiltelecom.com.br [200.181.14.30]) by mx1.FreeBSD.org (Postfix) with SMTP id 7410343D46 for ; Wed, 31 Aug 2005 21:46:15 +0000 (GMT) (envelope-from freebsd@powered.net) Received: (qmail 39406 invoked by uid 1009); 31 Aug 2005 21:43:18 -0000 Received: from unknown (HELO ?10.61.218.95?) (10.61.218.95) by relay.xpto.com with SMTP; 31 Aug 2005 21:43:18 -0000 Message-ID: <431624D4.5080800@powered.net> Date: Wed, 31 Aug 2005 18:44:52 -0300 From: Rainer Alves User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050828) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: 6.0-BETA3: ext2fs: if mounted at shutdown, fsck at next boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 21:46:17 -0000 Actually there's a workaround for this... add the following near the end of /etc/rc.shutdown: Sure, it isn't the perfect solution, but it works. Rainer Alves BrasilTelecom ----------- # Insert other shutdown procedures here extfs=`eval mount | grep ext2fs | awk '{print $1 }'` for _elem in $extfs; do echo -n "Unmounting ext2/ext3 filesystems: " umount -f $_elem echo -n "$_elem " done ----------- Matthias Andree wrote: >See Subject - this bug has already haunted FreeBSD 5 and still persists >in FreeBSD 6.0: shutting down FreeBSD 5 or 6 with a mounted ext2fs file >system prevents proper synching of the super blocks (vnode count remains >nonzero, until kernel gives up), so all file systems that were mounted >are fsck'd at next reboot, UFS, UFS2, ext2fs, doesn't matter. > >Someone please check the ext2fs locking. > > > From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 22:16: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 8995C16A41F for ; Wed, 31 Aug 2005 22:16:28 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id D9E9043D46 for ; Wed, 31 Aug 2005 22:16:27 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [10.1.1.7]) (authenticated bits=0) by srv1.cosmo-project.de (8.12.10/8.12.10) with ESMTP id j7VMGIBS043594 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 1 Sep 2005 00:16:21 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id j7VMFgKi006343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Sep 2005 00:15:43 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.11/8.12.11) with ESMTP id j7VMFgbX001065; Thu, 1 Sep 2005 00:15:42 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id j7VMFaFg001064; Thu, 1 Sep 2005 00:15:36 +0200 (CEST) (envelope-from ticso) Date: Thu, 1 Sep 2005 00:15:36 +0200 From: Bernd Walter To: Scott Long Message-ID: <20050831221535.GB670@cicely12.cicely.de> References: <1125452228.740.3.camel@arbitor.homelinux.com> <47d0403c05083020044f6ac0be@mail.gmail.com> <4315CEEC.80100@samsco.org> <20050831174631.GE37930@cicely12.cicely.de> <4315F15D.4090209@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4315F15D.4090209@samsco.org> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 X-Spam-Report: * -3.3 ALL_TRUSTED Did not pass through any untrusted hosts * -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on cicely12.cicely.de Cc: freebsd-current@freebsd.org, Kyle Brooks , ticso@cicely.de, Ben Kaduk Subject: Re: panic after removing usb flash drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2005 22:16:28 -0000 On Wed, Aug 31, 2005 at 12:05:17PM -0600, Scott Long wrote: > Bernd Walter wrote: > >On Wed, Aug 31, 2005 at 09:38:20AM -0600, Scott Long wrote: > >>Ben Kaduk wrote: > >>>On 8/31/05, Kyle Brooks wrote: > >This would really a step backward. > >Originally we had LUN creation/deletion on shared SIM and lots of > >different problems. > >SIM deletion should really be fixed - not only for umass, but generally > >as we live in a world with removeable cards. > > Bugs in the umass detach code are immediately responsible for the > problem, but you are correct that CAM in general doesn't like SIMs > going away. DFly worked on this a while back, but I don't recall > whether the work there was to add more sanity checks in the data > path (which I don't want to do), or if it was the correct approach of > flushing and quiescing the data/queuing, topology, and error recovery > paths. What bugs are you refering? Sample code on how to correctly detach a sim a sparse. The umass code doesn't know that devices on a scbus are in use, or should it? I think with a single sim style the target remains a ghost device as long as it is refered, right? In the USB-world we have the problem that a blocking detach blocks other port attachment/detachments on the same bus as well. This is because we currently have a single thread per bus processing these events. We already see this problem with ucom devices where an open tty on a detached device blocks. But it is better than the panic that we have right now. In the tty case we have a timeout, don't know what we can do with CAM. > >Technically a shared sim with using targets could be made work for > >umass as it's defined today, but it won't work for USB to SCSI > >converters - that we don't support one of these adapters today doesn't > >solve the problem. > > This is a completely different situation. A USB-SCSI adapter would > provide its own SCSI bus that is separate from the USB bus with its > own queueing resources and own error recovery mechanisms. Many umass devices are ide converters - even some flash drives. > >Is is a academical standpoint defining where in the USB/umass > >infrastrukture the SIM is located, but I personally always saw it > >inside the USB-device and not on the USB. > >USB is just a transport medium and not a SIM in the same way as PCI is > >just a transport medium for a classical SCSI-Interface. > >Yes - umass creates a SIM, bus and targed, because that is what a user > >really attaches/detaches. > > > > It is muddy, but for a mass storage class device, you are using the > USB bus as the transport medium and you are using the USB controller > as the transport initiator. Command queueing and resource arbitration > happens in the USB controller and driver, not in the umass device or > driver. Same for error recovery. The USB controller is essentially > acting as a SCSI controller, just with a USB bus instead of a SPI bus. > The whole point of CAM is to assist with queueing and arbitrating bus > resources. There is no way that the SIM-per-device approach can provide > this information. I can follow you to some degree. With the single-sim design we have had the following problems: - probing of LUNs filed on attach and required a manual rescan. undoubly fixable by someone with good CAM knowledge. - CAM needs a max target value, but how many target do we really have? Each USB has up to 127 devices (pratically 100 useable as we need some hubs) Each device can have multiple functions, which means multiple umass instances. Previously we had a small hardcoded number, too big numbers slow down bus rescans, too small restrict the number of possible devices. We should have a dynamic way. Don't remember if ther were others. >From the technical standpoint - no matter what we do, there are problems to solve. > Your analogy of a PCI bus is correct for the USB-SCSI adapters, where > the adapter is doing a full conversion and bridge from one bus type to > another. It's not true for a umass device where it's merely using the > USB bus as a SCSI transport. So what is an USB-IDE converter? OK - that won't help for a practical solution. In the practical way it sounded easier to go the multiple sim way. sim detach needs to be fixed either way. Are there any other technical reasons for doing single sim? You've mentioned rescource arbitration and error recovery. Is there anything that can CAM do for us that it won't with multiple sim? -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 23:03: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 3CEF616A41F for ; Wed, 31 Aug 2005 23:03:00 +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 B3AF743D45 for ; Wed, 31 Aug 2005 23:02:57 +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.3/8.13.3) with ESMTP id j7VNGOM4009714; Wed, 31 Aug 2005 17:16:24 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4316370E.4030809@samsco.org> Date: Wed, 31 Aug 2005 17:02:38 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ticso@cicely.de References: <1125452228.740.3.camel@arbitor.homelinux.com> <47d0403c05083020044f6ac0be@mail.gmail.com> <4315CEEC.80100@samsco.org> <20050831174631.GE37930@cicely12.cicely.de> <4315F15D.4090209@samsco.org> <20050831221535.GB670@cicely12.cicely.de> In-Reply-To: <20050831221535.GB670@cicely12.cicely.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: freebsd-current@freebsd.org, Kyle Brooks , Ben Kaduk Subject: Re: panic after removing usb flash drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 23:03:00 -0000 Bernd Walter wrote: > On Wed, Aug 31, 2005 at 12:05:17PM -0600, Scott Long wrote: > >>Bernd Walter wrote: >> >>>On Wed, Aug 31, 2005 at 09:38:20AM -0600, Scott Long wrote: >>> >>>>Ben Kaduk wrote: >>>> >>>>>On 8/31/05, Kyle Brooks wrote: >>> >>>This would really a step backward. >>>Originally we had LUN creation/deletion on shared SIM and lots of >>>different problems. >>>SIM deletion should really be fixed - not only for umass, but generally >>>as we live in a world with removeable cards. >> >>Bugs in the umass detach code are immediately responsible for the >>problem, but you are correct that CAM in general doesn't like SIMs >>going away. DFly worked on this a while back, but I don't recall >>whether the work there was to add more sanity checks in the data >>path (which I don't want to do), or if it was the correct approach of >>flushing and quiescing the data/queuing, topology, and error recovery >>paths. > > > What bugs are you refering? The CAM detach code should be returning EBUSY errors since the 'da' periph has open references to it. I'm pretty sure that thse errors are being ignored by umass.c, leading to the SIM going away unexpectedly to CAM. > Sample code on how to correctly detach a sim a sparse. > The umass code doesn't know that devices on a scbus are in use, or > should it? Well, it doesn't need to right now because you only have one target per SIM. It should though; most normal SCSI drivers keep a table of known devices in order to remember negotiated transfer settings and handle reconnections. > I think with a single sim style the target remains a ghost device > as long as it is refered, right? More or less, yes. Periph drivers are refcounted and understand the idea of going away when a selection fails (i.e. the device got pulled from the bus). > > In the USB-world we have the problem that a blocking detach blocks > other port attachment/detachments on the same bus as well. > This is because we currently have a single thread per bus processing > these events. > We already see this problem with ucom devices where an open tty on a > detached device blocks. > But it is better than the panic that we have right now. > In the tty case we have a timeout, don't know what we can do with CAM. > In the sim-per-target model, you need to completely drain the simq and devq for the SIM before allowing detach to complete. This means freezing the simq then waiting until the camisr can run and process any pending CCBs on the completion queue. The camisr is an SWI, so you'll need to sleep so that it can run. > >>>Technically a shared sim with using targets could be made work for >>>umass as it's defined today, but it won't work for USB to SCSI >>>converters - that we don't support one of these adapters today doesn't >>>solve the problem. >> >>This is a completely different situation. A USB-SCSI adapter would >>provide its own SCSI bus that is separate from the USB bus with its >>own queueing resources and own error recovery mechanisms. > > > Many umass devices are ide converters - even some flash drives. > > >>>Is is a academical standpoint defining where in the USB/umass >>>infrastrukture the SIM is located, but I personally always saw it >>>inside the USB-device and not on the USB. >>>USB is just a transport medium and not a SIM in the same way as PCI is >>>just a transport medium for a classical SCSI-Interface. >>>Yes - umass creates a SIM, bus and targed, because that is what a user >>>really attaches/detaches. >>> >> >>It is muddy, but for a mass storage class device, you are using the >>USB bus as the transport medium and you are using the USB controller >>as the transport initiator. Command queueing and resource arbitration >>happens in the USB controller and driver, not in the umass device or >>driver. Same for error recovery. The USB controller is essentially >>acting as a SCSI controller, just with a USB bus instead of a SPI bus. >>The whole point of CAM is to assist with queueing and arbitrating bus >>resources. There is no way that the SIM-per-device approach can provide >>this information. > > > I can follow you to some degree. > With the single-sim design we have had the following problems: > - probing of LUNs filed on attach and required a manual rescan. > undoubly fixable by someone with good CAM knowledge. I'm not parsing this. Are you referring to the need to do a rescan after plugging in a device? This is easy to solve. When a umass target is attached, you either send an AC_FOUND_DEVICE async event to announce the target, or you request a bus rescan from within the driver. I think that the ciss driver has an example of this. > - CAM needs a max target value, but how many target do we really have? > Each USB has up to 127 devices (pratically 100 useable as we need > some hubs) The max target value is really only important for bus rescans. The SIM can just track what targets it currently knows about and reject CCBs for ones that don't exist (it somewhat does this now, though with only one target per SIM it's kinda silly). Setting the max target value to 127 and rejecting targets that don't exist won't slow down a bus rescan but much at all. > Each device can have multiple functions, which means multiple umass > instances. I have a umass device that is a CF+SD card reader. It shows up in CAM as a single target with 2 LUNs. Is this the kind of thing that you are talking about? If so, then there is no reason not to continue to use the model of a single target with multiple LUNs. > Previously we had a small hardcoded number, too big numbers slow > down bus rescans, too small restrict the number of possible devices. > We should have a dynamic way. > Don't remember if ther were others. > > From the technical standpoint - no matter what we do, there are > problems to solve. > > >>Your analogy of a PCI bus is correct for the USB-SCSI adapters, where >>the adapter is doing a full conversion and bridge from one bus type to >>another. It's not true for a umass device where it's merely using the >>USB bus as a SCSI transport. > > > So what is an USB-IDE converter? I assumed that you were talking about devices that bridge from USB to IDE/SCSI and did not conform to the umass standard. I have a USB2-IDE converter in an external exclosure that speaks umass and is probably closer to what you are talking about here. But again, umass is really about using the USB bus to transport SCSI/ATA protocol, not about providing full access to a SCSI/IDE bus via a USB tunnel. That is a significant difference, IMHO. The USB controller is acting in a direct role as the SCSI/ATA initiator, vs. just tunnelling to a smart initiator. > OK - that won't help for a practical solution. > In the practical way it sounded easier to go the multiple sim way. > sim detach needs to be fixed either way. Yes. It somewhat works now as long as the system is completely idle. It breaks down horribly if I/O or error recovery is in progress and a periph driver is left with CCBs in flight and/or a dangling reference to a SIM. The only way to deal with this is to allow blocking while CAM drains itself. > Are there any other technical reasons for doing single sim? > You've mentioned rescource arbitration and error recovery. > Is there anything that can CAM do for us that it won't with multiple > sim? > It means that you'll be able to detach umass targets without doing the complicated dance of sleeping for CAM to drain itself. It also will mean that it's less fragile to edge cases that are hard to identify and deal with. Fixing CAM detach so that this works reliably is definitely something that must be done, but you can't avoid sleeping in order for it to work. Scott From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 23:16:23 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 85A7816A41F; Wed, 31 Aug 2005 23:16:23 +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 B3D8043D58; Wed, 31 Aug 2005 23:16:19 +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 j7VNCXZM014083; Wed, 31 Aug 2005 17:12:38 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 31 Aug 2005 17:12:59 -0600 (MDT) Message-Id: <20050831.171259.56563279.imp@bsdimp.com> To: mi+mx@aldan.algebra.com From: "M. Warner Losh" In-Reply-To: <200508301223.20626.mi+mx@aldan.algebra.com> References: <200508281326.j7SDQGfc073329@blue.virtual-estates.net> <20050829191927.6694a969.flynn@energyhq.es.eu.org> <200508301223.20626.mi+mx@aldan.algebra.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Wed, 31 Aug 2005 17:12:42 -0600 (MDT) Cc: re@freebsd.org, current@freebsd.org Subject: Re: installing 6.0-BETA3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 23:16:23 -0000 In message: <200508301223.20626.mi+mx@aldan.algebra.com> Mikhail Teterin writes: : > > . Something is wrong with the ed-driver (in my case -- : > > Kingston's KNE-PC2T, FCC ID L40WST200). Kernel reports : > > being unable to do something with pccard1, then reports : > > ed1: .... : > > and hangs. I let it wait for an hour and it never continued : > > booting. I'll try to investigate, when I'm done installing. : > > The card worked just fine in a newer Pentium-II laptop under : > > FreeBSD-5.x : > : > If the card is a 16bit pcmcia car make sure the bridge is set to 16bit. : : How do I do that? You can't. The advice was bogus and should be completely ignored. I have a number of pending MFCs for PC Cards to make them work a lot better than they do now. Maybe they will solve your problems. Warner From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 23:18: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 30D2C16A41F for ; Wed, 31 Aug 2005 23:18:55 +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 BB19143D45 for ; Wed, 31 Aug 2005 23:18:54 +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 j7VNFZ3C014096; Wed, 31 Aug 2005 17:15:35 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 31 Aug 2005 17:16:01 -0600 (MDT) Message-Id: <20050831.171601.65987352.imp@bsdimp.com> To: dominique.goncalves@gmail.com From: "M. Warner Losh" In-Reply-To: <7daacbbe05083105486887f43e@mail.gmail.com> References: <7daacbbe05083105486887f43e@mail.gmail.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Wed, 31 Aug 2005 17:15:35 -0600 (MDT) Cc: freebsd-current@FreeBSD.org Subject: Re: make distribution fails with RELENG_6 on a 5.4-RELEASE-p6 host X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 23:18:55 -0000 In message: <7daacbbe05083105486887f43e@mail.gmail.com> Dominique Goncalves writes: : I'm trying to create a livecd with freesbie2 [1] with RELENG_6 source : on FreeBSD 5.4-RELEASE-p6, : but the make distribution fails: ... : cap_mkdb: illegal option -- l : usage: cap_mkdb [-v] [-f outfile] file [file ...] : *** Error code 1 I recently added the following knobs to the makefile to allow one to do this. You'll need to invoke make distribution with CAP_MKDB_ENDIAN="" and PWD_MKDB_ENDIAN="". This will limit you to building only on the endian as the host, but that's usually not an issue. However, I've not yet MFC'd these changes to RELENG_6, so you'll need to change the *_MKDB_ENDAIN= lines in etc/Makefile to be ?= Warner From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 00:03: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 0D83A16A41F for ; Thu, 1 Sep 2005 00:03:31 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id D98A343D45 for ; Thu, 1 Sep 2005 00:03:29 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [10.1.1.7]) (authenticated bits=0) by srv1.cosmo-project.de (8.12.10/8.12.10) with ESMTP id j8103KBS045684 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 1 Sep 2005 02:03:22 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id j8102MKi007224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Sep 2005 02:02:22 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.11/8.12.11) with ESMTP id j8102LPE001465; Thu, 1 Sep 2005 02:02:21 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id j8102H5b001464; Thu, 1 Sep 2005 02:02:17 +0200 (CEST) (envelope-from ticso) Date: Thu, 1 Sep 2005 02:02:17 +0200 From: Bernd Walter To: Scott Long Message-ID: <20050901000216.GD670@cicely12.cicely.de> References: <1125452228.740.3.camel@arbitor.homelinux.com> <47d0403c05083020044f6ac0be@mail.gmail.com> <4315CEEC.80100@samsco.org> <20050831174631.GE37930@cicely12.cicely.de> <4315F15D.4090209@samsco.org> <20050831221535.GB670@cicely12.cicely.de> <4316370E.4030809@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4316370E.4030809@samsco.org> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 X-Spam-Report: * -3.3 ALL_TRUSTED Did not pass through any untrusted hosts * -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on cicely12.cicely.de Cc: freebsd-current@freebsd.org, Kyle Brooks , ticso@cicely.de, Ben Kaduk Subject: Re: panic after removing usb flash drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2005 00:03:31 -0000 On Wed, Aug 31, 2005 at 05:02:38PM -0600, Scott Long wrote: > Bernd Walter wrote: > >On Wed, Aug 31, 2005 at 12:05:17PM -0600, Scott Long wrote: > >What bugs are you refering? > > The CAM detach code should be returning EBUSY errors since the 'da' > periph has open references to it. I'm pretty sure that thse errors > are being ignored by umass.c, leading to the SIM going away unexpectedly > to CAM. OK. > >Sample code on how to correctly detach a sim a sparse. > >The umass code doesn't know that devices on a scbus are in use, or > >should it? > > Well, it doesn't need to right now because you only have one target > per SIM. It should though; most normal SCSI drivers keep a table of > known devices in order to remember negotiated transfer settings and > handle reconnections. OK. > >In the USB-world we have the problem that a blocking detach blocks > >other port attachment/detachments on the same bus as well. > >This is because we currently have a single thread per bus processing > >these events. > >We already see this problem with ucom devices where an open tty on a > >detached device blocks. > >But it is better than the panic that we have right now. > >In the tty case we have a timeout, don't know what we can do with CAM. > > > > In the sim-per-target model, you need to completely drain the simq and > devq for the SIM before allowing detach to complete. This means > freezing the simq then waiting until the camisr can run and process any > pending CCBs on the completion queue. The camisr is an SWI, so you'll > need to sleep so that it can run. Sounds doable. > >With the single-sim design we have had the following problems: > >- probing of LUNs filed on attach and required a manual rescan. > > undoubly fixable by someone with good CAM knowledge. > > I'm not parsing this. Are you referring to the need to do a rescan > after plugging in a device? This is easy to solve. When a umass Yes. > target is attached, you either send an AC_FOUND_DEVICE async event to > announce the target, or you request a bus rescan from within the driver. > I think that the ciss driver has an example of this. Don't know ciss, but I never had doubts that this is was a fixable thing. > >- CAM needs a max target value, but how many target do we really have? > > Each USB has up to 127 devices (pratically 100 useable as we need > > some hubs) > > The max target value is really only important for bus rescans. The SIM > can just track what targets it currently knows about and reject CCBs > for ones that don't exist (it somewhat does this now, though with only > one target per SIM it's kinda silly). Setting the max target value to > 127 and rejecting targets that don't exist won't slow down a bus rescan > but much at all. But you can have more than 127 umass instances per bus. > > Each device can have multiple functions, which means multiple umass > > instances. > > I have a umass device that is a CF+SD card reader. It shows up in CAM > as a single target with 2 LUNs. Is this the kind of thing that you are > talking about? If so, then there is no reason not to continue to use > the model of a single target with multiple LUNs. No, that is multiple LUN with a single umass instance. What I mean is a single USB device with multiple umass instances. umass ist just a logical interface in the USB world, normaly ment to allow e.g. an ulpt and umass on the same USB device, but also possible to have multiple umass interfaces on the same USB device. Since an umass interface needs at least two bulk endpoints a single USB-channel can have up to 16 * 127 umass instances. > > Previously we had a small hardcoded number, too big numbers slow > > down bus rescans, too small restrict the number of possible devices. > > We should have a dynamic way. > >Don't remember if ther were others. > > > >From the technical standpoint - no matter what we do, there are > >problems to solve. > > > > > >>Your analogy of a PCI bus is correct for the USB-SCSI adapters, where > >>the adapter is doing a full conversion and bridge from one bus type to > >>another. It's not true for a umass device where it's merely using the > >>USB bus as a SCSI transport. > > > > > >So what is an USB-IDE converter? > > I assumed that you were talking about devices that bridge from USB to > IDE/SCSI and did not conform to the umass standard. I have a USB2-IDE > converter in an external exclosure that speaks umass and is probably > closer to what you are talking about here. But again, umass is really > about using the USB bus to transport SCSI/ATA protocol, not about > providing full access to a SCSI/IDE bus via a USB tunnel. That is a > significant difference, IMHO. The USB controller is acting in a direct > role as the SCSI/ATA initiator, vs. just tunnelling to a smart > initiator. OK - I got it now. Nevertheless I could imagine a pseudo USB-SCSI converter that just enhances umass transactions with a target-ID. This won't invalidate what you wrote above, since you still don't have full access on the SCSI-bus, but also requires a sim per (enhanced)umass. > >OK - that won't help for a practical solution. > >In the practical way it sounded easier to go the multiple sim way. > >sim detach needs to be fixed either way. > > Yes. It somewhat works now as long as the system is completely idle. > It breaks down horribly if I/O or error recovery is in progress and > a periph driver is left with CCBs in flight and/or a dangling > reference to a SIM. The only way to deal with this is to allow > blocking while CAM drains itself. Have to think about it. > >Are there any other technical reasons for doing single sim? > >You've mentioned rescource arbitration and error recovery. > >Is there anything that can CAM do for us that it won't with multiple > >sim? > > > > It means that you'll be able to detach umass targets without doing the > complicated dance of sleeping for CAM to drain itself. It also will > mean that it's less fragile to edge cases that are hard to identify and > deal with. Fixing CAM detach so that this works reliably is definitely > something that must be done, but you can't avoid sleeping in order for > it to work. Mmm. -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 00:09: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 C915916A41F for ; Thu, 1 Sep 2005 00:09:36 +0000 (GMT) (envelope-from captinsmock@columbus.rr.com) Received: from ms-smtp-01-eri0.ohiordc.rr.com (ms-smtp-01-smtplb.ohiordc.rr.com [65.24.5.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2980143D45 for ; Thu, 1 Sep 2005 00:09:36 +0000 (GMT) (envelope-from captinsmock@columbus.rr.com) Received: from cpe-65-24-34-161.columbus.res.rr.com (cpe-65-24-34-161.columbus.res.rr.com [65.24.34.161]) by ms-smtp-01-eri0.ohiordc.rr.com (8.12.10/8.12.7) with ESMTP id j8109QWY002797; Wed, 31 Aug 2005 20:09:30 -0400 (EDT) From: Kyle Brooks To: Scott Long In-Reply-To: <4316370E.4030809@samsco.org> References: <1125452228.740.3.camel@arbitor.homelinux.com> <47d0403c05083020044f6ac0be@mail.gmail.com> <4315CEEC.80100@samsco.org> <20050831174631.GE37930@cicely12.cicely.de> <4315F15D.4090209@samsco.org> <20050831221535.GB670@cicely12.cicely.de> <4316370E.4030809@samsco.org> Content-Type: multipart/mixed; boundary="=-FYZp8LaGu/8HvL5hC1wt" Date: Thu, 01 Sep 2005 00:09:26 +0000 Message-Id: <1125533366.685.11.camel@arbitor.homelinux.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 FreeBSD GNOME Team Port X-Virus-Scanned: Symantec AntiVirus Scan Engine Cc: freebsd-current@freebsd.org, ticso@cicely.de, Ben Kaduk Subject: Re: panic after removing usb flash drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2005 00:09:36 -0000 --=-FYZp8LaGu/8HvL5hC1wt Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, 2005-08-31 at 17:02 -0600, Scott Long wrote: > Bernd Walter wrote: > > On Wed, Aug 31, 2005 at 12:05:17PM -0600, Scott Long wrote: > > > >>Bernd Walter wrote: > >> > >>>On Wed, Aug 31, 2005 at 09:38:20AM -0600, Scott Long wrote: > >>> > >>>>Ben Kaduk wrote: > >>>> > >>>>>On 8/31/05, Kyle Brooks wrote: > >>> > >>>This would really a step backward. > >>>Originally we had LUN creation/deletion on shared SIM and lots of > >>>different problems. > >>>SIM deletion should really be fixed - not only for umass, but generally > >>>as we live in a world with removeable cards. > >> > >>Bugs in the umass detach code are immediately responsible for the > >>problem, but you are correct that CAM in general doesn't like SIMs > >>going away. DFly worked on this a while back, but I don't recall > >>whether the work there was to add more sanity checks in the data > >>path (which I don't want to do), or if it was the correct approach of > >>flushing and quiescing the data/queuing, topology, and error recovery > >>paths. > > > > > > What bugs are you refering? > > The CAM detach code should be returning EBUSY errors since the 'da' > periph has open references to it. I'm pretty sure that thse errors > are being ignored by umass.c, leading to the SIM going away unexpectedly > to CAM. > > > Sample code on how to correctly detach a sim a sparse. > > The umass code doesn't know that devices on a scbus are in use, or > > should it? > > Well, it doesn't need to right now because you only have one target > per SIM. It should though; most normal SCSI drivers keep a table of > known devices in order to remember negotiated transfer settings and > handle reconnections. > > > I think with a single sim style the target remains a ghost device > > as long as it is refered, right? > > More or less, yes. Periph drivers are refcounted and understand the > idea of going away when a selection fails (i.e. the device got pulled > from the bus). > > > > > In the USB-world we have the problem that a blocking detach blocks > > other port attachment/detachments on the same bus as well. > > This is because we currently have a single thread per bus processing > > these events. > > We already see this problem with ucom devices where an open tty on a > > detached device blocks. > > But it is better than the panic that we have right now. > > In the tty case we have a timeout, don't know what we can do with CAM. > > > > In the sim-per-target model, you need to completely drain the simq and > devq for the SIM before allowing detach to complete. This means > freezing the simq then waiting until the camisr can run and process any > pending CCBs on the completion queue. The camisr is an SWI, so you'll > need to sleep so that it can run. > > > > >>>Technically a shared sim with using targets could be made work for > >>>umass as it's defined today, but it won't work for USB to SCSI > >>>converters - that we don't support one of these adapters today doesn't > >>>solve the problem. > >> > >>This is a completely different situation. A USB-SCSI adapter would > >>provide its own SCSI bus that is separate from the USB bus with its > >>own queueing resources and own error recovery mechanisms. > > > > > > Many umass devices are ide converters - even some flash drives. > > > > > >>>Is is a academical standpoint defining where in the USB/umass > >>>infrastrukture the SIM is located, but I personally always saw it > >>>inside the USB-device and not on the USB. > >>>USB is just a transport medium and not a SIM in the same way as PCI is > >>>just a transport medium for a classical SCSI-Interface. > >>>Yes - umass creates a SIM, bus and targed, because that is what a user > >>>really attaches/detaches. > >>> > >> > >>It is muddy, but for a mass storage class device, you are using the > >>USB bus as the transport medium and you are using the USB controller > >>as the transport initiator. Command queueing and resource arbitration > >>happens in the USB controller and driver, not in the umass device or > >>driver. Same for error recovery. The USB controller is essentially > >>acting as a SCSI controller, just with a USB bus instead of a SPI bus. > >>The whole point of CAM is to assist with queueing and arbitrating bus > >>resources. There is no way that the SIM-per-device approach can provide > >>this information. > > > > > > I can follow you to some degree. > > With the single-sim design we have had the following problems: > > - probing of LUNs filed on attach and required a manual rescan. > > undoubly fixable by someone with good CAM knowledge. > > I'm not parsing this. Are you referring to the need to do a rescan > after plugging in a device? This is easy to solve. When a umass > target is attached, you either send an AC_FOUND_DEVICE async event to > announce the target, or you request a bus rescan from within the driver. > I think that the ciss driver has an example of this. > > > - CAM needs a max target value, but how many target do we really have? > > Each USB has up to 127 devices (pratically 100 useable as we need > > some hubs) > > The max target value is really only important for bus rescans. The SIM > can just track what targets it currently knows about and reject CCBs > for ones that don't exist (it somewhat does this now, though with only > one target per SIM it's kinda silly). Setting the max target value to > 127 and rejecting targets that don't exist won't slow down a bus rescan > but much at all. > > > Each device can have multiple functions, which means multiple umass > > instances. > > I have a umass device that is a CF+SD card reader. It shows up in CAM > as a single target with 2 LUNs. Is this the kind of thing that you are > talking about? If so, then there is no reason not to continue to use > the model of a single target with multiple LUNs. > > > Previously we had a small hardcoded number, too big numbers slow > > down bus rescans, too small restrict the number of possible devices. > > We should have a dynamic way. > > Don't remember if ther were others. > > > > From the technical standpoint - no matter what we do, there are > > problems to solve. > > > > > >>Your analogy of a PCI bus is correct for the USB-SCSI adapters, where > >>the adapter is doing a full conversion and bridge from one bus type to > >>another. It's not true for a umass device where it's merely using the > >>USB bus as a SCSI transport. > > > > > > So what is an USB-IDE converter? > > I assumed that you were talking about devices that bridge from USB to > IDE/SCSI and did not conform to the umass standard. I have a USB2-IDE > converter in an external exclosure that speaks umass and is probably > closer to what you are talking about here. But again, umass is really > about using the USB bus to transport SCSI/ATA protocol, not about > providing full access to a SCSI/IDE bus via a USB tunnel. That is a > significant difference, IMHO. The USB controller is acting in a direct > role as the SCSI/ATA initiator, vs. just tunnelling to a smart > initiator. > > > OK - that won't help for a practical solution. > > In the practical way it sounded easier to go the multiple sim way. > > sim detach needs to be fixed either way. > > Yes. It somewhat works now as long as the system is completely idle. > It breaks down horribly if I/O or error recovery is in progress and > a periph driver is left with CCBs in flight and/or a dangling > reference to a SIM. The only way to deal with this is to allow > blocking while CAM drains itself. > > > Are there any other technical reasons for doing single sim? > > You've mentioned rescource arbitration and error recovery. > > Is there anything that can CAM do for us that it won't with multiple > > sim? > > > > It means that you'll be able to detach umass targets without doing the > complicated dance of sleeping for CAM to drain itself. It also will > mean that it's less fragile to edge cases that are hard to identify and > deal with. Fixing CAM detach so that this works reliably is definitely > something that must be done, but you can't avoid sleeping in order for > it to work. > > Scott > _______________________________________________ > 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" I'm don't really know the mechanics of CAM, but just for the record this flash drive works in 5.4, but CAM in current seems to give up after about 10 minutes with this: umass0: LEXAR MEDIA JUMPDRIVE2, rev 2.00/1.25, addr 2 (da0:umass-sim0:0:0:0): got CAM status 0x4 (da0:umass-sim0:0:0:0): fatal error, failed to attach to device (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): removing device entry Opened disk da0 -> 5 sorry i missed this before, didn't keep it in that long, if it helps attached is a diff file for CAM from 5.4 to current. --=-FYZp8LaGu/8HvL5hC1wt Content-Disposition: attachment; filename=cam.diff Content-Type: text/x-patch; name=cam.diff; charset=us-ascii Content-Transfer-Encoding: 7bit diff -ru cam_old/cam.c cam_new/cam.c --- cam_old/cam.c Sun Jan 30 00:59:15 2005 +++ cam_new/cam.c Wed Jan 5 22:34:34 2005 @@ -27,7 +27,7 @@ */ #include -__FBSDID("$FreeBSD: src/sys/cam/cam.c,v 1.8.4.1 2005/01/30 00:59:15 imp Exp $"); +__FBSDID("$FreeBSD: src/sys/cam/cam.c,v 1.9 2005/01/05 22:34:34 imp Exp $"); #include #ifdef _KERNEL diff -ru cam_old/cam.h cam_new/cam.h --- cam_old/cam.h Sun Jan 30 00:59:15 2005 +++ cam_new/cam.h Wed Jan 5 22:34:34 2005 @@ -25,7 +25,7 @@ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * - * $FreeBSD: src/sys/cam/cam.h,v 1.10.8.1 2005/01/30 00:59:15 imp Exp $ + * $FreeBSD: src/sys/cam/cam.h,v 1.11 2005/01/05 22:34:34 imp Exp $ */ #ifndef _CAM_CAM_H diff -ru cam_old/cam_ccb.h cam_new/cam_ccb.h --- cam_old/cam_ccb.h Sun Jan 30 00:59:15 2005 +++ cam_new/cam_ccb.h Wed Jan 5 22:34:34 2005 @@ -25,7 +25,7 @@ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * - * $FreeBSD: src/sys/cam/cam_ccb.h,v 1.27.2.1 2005/01/30 00:59:15 imp Exp $ + * $FreeBSD: src/sys/cam/cam_ccb.h,v 1.28 2005/01/05 22:34:34 imp Exp $ */ #ifndef _CAM_CAM_CCB_H diff -ru cam_old/cam_debug.h cam_new/cam_debug.h --- cam_old/cam_debug.h Sun Jan 30 00:59:15 2005 +++ cam_new/cam_debug.h Wed Jan 5 22:34:34 2005 @@ -25,7 +25,7 @@ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * - * $FreeBSD: src/sys/cam/cam_debug.h,v 1.7.8.1 2005/01/30 00:59:15 imp Exp $ + * $FreeBSD: src/sys/cam/cam_debug.h,v 1.8 2005/01/05 22:34:34 imp Exp $ */ #ifndef _CAM_CAM_DEBUG_H #define _CAM_CAM_DEBUG_H 1 diff -ru cam_old/cam_periph.c cam_new/cam_periph.c --- cam_old/cam_periph.c Sat Mar 12 10:01:39 2005 +++ cam_new/cam_periph.c Fri Jul 1 15:21:29 2005 @@ -28,12 +28,13 @@ */ #include -__FBSDID("$FreeBSD: src/sys/cam/cam_periph.c,v 1.56.4.3 2005/03/12 10:01:39 delphij Exp $"); +__FBSDID("$FreeBSD: src/sys/cam/cam_periph.c,v 1.60 2005/07/01 15:21:29 avatar Exp $"); #include #include #include #include +#include #include #include #include @@ -83,6 +84,8 @@ static int nperiph_drivers; struct periph_driver **periph_drivers; +MALLOC_DEFINE(M_CAMPERIPH, "CAM periph", "CAM peripheral buffers"); + void periphdriver_register(void *data) { @@ -144,7 +147,7 @@ return (CAM_REQ_INVALID); } - periph = (struct cam_periph *)malloc(sizeof(*periph), M_DEVBUF, + periph = (struct cam_periph *)malloc(sizeof(*periph), M_CAMPERIPH, M_NOWAIT); if (periph == NULL) @@ -220,7 +223,7 @@ xpt_free_path(periph->path); /* FALLTHROUGH */ case 1: - free(periph, M_DEVBUF); + free(periph, M_CAMPERIPH); /* FALLTHROUGH */ case 0: /* No cleanup to perform. */ @@ -485,7 +488,7 @@ periph->path, arg); } xpt_free_path(periph->path); - free(periph, M_DEVBUF); + free(periph, M_CAMPERIPH); } /* diff -ru cam_old/cam_periph.h cam_new/cam_periph.h --- cam_old/cam_periph.h Sun Jan 30 00:59:16 2005 +++ cam_new/cam_periph.h Wed Jan 5 22:34:34 2005 @@ -25,7 +25,7 @@ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * - * $FreeBSD: src/sys/cam/cam_periph.h,v 1.14.2.1 2005/01/30 00:59:16 imp Exp $ + * $FreeBSD: src/sys/cam/cam_periph.h,v 1.16 2005/01/05 22:34:34 imp Exp $ */ #ifndef _CAM_CAM_PERIPH_H @@ -81,8 +81,7 @@ }; typedef enum { - CAM_PERIPH_BIO, - CAM_PERIPH_NET + CAM_PERIPH_BIO } cam_periph_type; /* Generically usefull offsets into the peripheral private area */ diff -ru cam_old/cam_queue.c cam_new/cam_queue.c --- cam_old/cam_queue.c Sun Jan 30 00:59:16 2005 +++ cam_new/cam_queue.c Fri Jul 1 15:21:29 2005 @@ -27,18 +27,23 @@ */ #include -__FBSDID("$FreeBSD: src/sys/cam/cam_queue.c,v 1.7.4.1 2005/01/30 00:59:16 imp Exp $"); +__FBSDID("$FreeBSD: src/sys/cam/cam_queue.c,v 1.9 2005/07/01 15:21:29 avatar Exp $"); #include #include #include #include +#include #include #include #include #include +MALLOC_DEFINE(M_CAMQ, "CAM queue", "CAM queue buffers"); +MALLOC_DEFINE(M_CAMDEVQ, "CAM dev queue", "CAM dev queue buffers"); +MALLOC_DEFINE(M_CAMCCBQ, "CAM ccb queue", "CAM ccb queue buffers"); + static __inline int queue_cmp(cam_pinfo **queue_array, int i, int j); static __inline void @@ -52,10 +57,10 @@ { struct camq *camq; - camq = (struct camq *)malloc(sizeof(*camq), M_DEVBUF, M_NOWAIT); + camq = (struct camq *)malloc(sizeof(*camq), M_CAMQ, M_NOWAIT); if (camq != NULL) { if (camq_init(camq, size) != 0) { - free(camq, M_DEVBUF); + free(camq, M_CAMQ); camq = NULL; } } @@ -69,7 +74,7 @@ camq->array_size = size; if (camq->array_size != 0) { camq->queue_array = (cam_pinfo**)malloc(size*sizeof(cam_pinfo*), - M_DEVBUF, M_NOWAIT); + M_CAMQ, M_NOWAIT); if (camq->queue_array == NULL) { printf("camq_init: - cannot malloc array!\n"); return (1); @@ -94,7 +99,7 @@ { if (queue != NULL) { camq_fini(queue); - free(queue, M_DEVBUF); + free(queue, M_CAMQ); } } @@ -107,7 +112,7 @@ * our pointer into the heap array is offset by one element. */ queue->queue_array++; - free(queue->queue_array, M_DEVBUF); + free(queue->queue_array, M_CAMQ); } } @@ -122,7 +127,7 @@ "queued entries."); #endif new_array = (cam_pinfo **)malloc(new_size * sizeof(cam_pinfo *), - M_DEVBUF, M_NOWAIT); + M_CAMQ, M_NOWAIT); if (new_array == NULL) { /* Couldn't satisfy request */ return (CAM_RESRC_UNAVAIL); @@ -136,7 +141,7 @@ queue->queue_array++; bcopy(queue->queue_array, new_array, queue->entries * sizeof(cam_pinfo *)); - free(queue->queue_array, M_DEVBUF); + free(queue->queue_array, M_CAMQ); } queue->queue_array = new_array-1; queue->array_size = new_size; @@ -210,13 +215,13 @@ { struct cam_devq *devq; - devq = (struct cam_devq *)malloc(sizeof(*devq), M_DEVBUF, M_NOWAIT); + devq = (struct cam_devq *)malloc(sizeof(*devq), M_CAMDEVQ, M_NOWAIT); if (devq == NULL) { printf("cam_devq_alloc: - cannot malloc!\n"); return (NULL); } if (cam_devq_init(devq, devices, openings) != 0) { - free(devq, M_DEVBUF); + free(devq, M_CAMDEVQ); return (NULL); } @@ -246,7 +251,7 @@ { camq_fini(&devq->alloc_queue); camq_fini(&devq->send_queue); - free(devq, M_DEVBUF); + free(devq, M_CAMDEVQ); } u_int32_t @@ -267,13 +272,13 @@ { struct cam_ccbq *ccbq; - ccbq = (struct cam_ccbq *)malloc(sizeof(*ccbq), M_DEVBUF, M_NOWAIT); + ccbq = (struct cam_ccbq *)malloc(sizeof(*ccbq), M_CAMCCBQ, M_NOWAIT); if (ccbq == NULL) { printf("cam_ccbq_alloc: - cannot malloc!\n"); return (NULL); } if (cam_ccbq_init(ccbq, openings) != 0) { - free(ccbq, M_DEVBUF); + free(ccbq, M_CAMCCBQ); return (NULL); } @@ -285,7 +290,7 @@ { if (ccbq) { camq_fini(&ccbq->queue); - free(ccbq, M_DEVBUF); + free(ccbq, M_CAMCCBQ); } } diff -ru cam_old/cam_queue.h cam_new/cam_queue.h --- cam_old/cam_queue.h Sun Jan 30 00:59:16 2005 +++ cam_new/cam_queue.h Wed Jan 5 22:34:34 2005 @@ -25,7 +25,7 @@ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * - * $FreeBSD: src/sys/cam/cam_queue.h,v 1.8.8.1 2005/01/30 00:59:16 imp Exp $ + * $FreeBSD: src/sys/cam/cam_queue.h,v 1.9 2005/01/05 22:34:34 imp Exp $ */ #ifndef _CAM_CAM_QUEUE_H diff -ru cam_old/cam_sim.c cam_new/cam_sim.c --- cam_old/cam_sim.c Sun Jan 30 00:59:16 2005 +++ cam_new/cam_sim.c Wed Aug 31 21:25:59 2005 @@ -1,4 +1,4 @@ -/*- +/* * Common functions for SCSI Interface Modules (SIMs). * * Copyright (c) 1997 Justin T. Gibbs. @@ -27,11 +27,12 @@ */ #include -__FBSDID("$FreeBSD: src/sys/cam/cam_sim.c,v 1.7.4.1 2005/01/30 00:59:16 imp Exp $"); +__FBSDID("$FreeBSD: src/sys/cam/cam_sim.c,v 1.9 2005/07/01 15:21:29 avatar Exp $"); #include #include #include +#include #include #include @@ -40,6 +41,8 @@ #define CAM_PATH_ANY (u_int32_t)-1 +MALLOC_DEFINE(M_CAMSIM, "CAM SIM", "CAM SIM buffers"); + struct cam_devq * cam_simq_alloc(u_int32_t max_sim_transactions) { @@ -68,10 +71,10 @@ */ if (strcmp(sim_name, "xpt") == 0) sim = (struct cam_sim *)malloc(sizeof(struct cam_sim), - M_DEVBUF, M_WAITOK); + M_CAMSIM, M_WAITOK); else sim = (struct cam_sim *)malloc(sizeof(struct cam_sim), - M_DEVBUF, M_NOWAIT); + M_CAMSIM, M_NOWAIT); if (sim != NULL) { sim->sim_action = sim_action; @@ -96,7 +99,7 @@ { if (free_devq) cam_simq_free(sim->devq); - free(sim, M_DEVBUF); + free(sim, M_CAMSIM); } void diff -ru cam_old/cam_sim.h cam_new/cam_sim.h --- cam_old/cam_sim.h Sun Jan 30 00:59:16 2005 +++ cam_new/cam_sim.h Wed Jan 5 22:34:34 2005 @@ -25,7 +25,7 @@ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * - * $FreeBSD: src/sys/cam/cam_sim.h,v 1.5.8.1 2005/01/30 00:59:16 imp Exp $ + * $FreeBSD: src/sys/cam/cam_sim.h,v 1.6 2005/01/05 22:34:34 imp Exp $ */ #ifndef _CAM_CAM_SIM_H diff -ru cam_old/cam_xpt.c cam_new/cam_xpt.c --- cam_old/cam_xpt.c Fri Apr 1 12:44:03 2005 +++ cam_new/cam_xpt.c Fri Jul 1 15:21:29 2005 @@ -28,7 +28,7 @@ */ #include -__FBSDID("$FreeBSD: src/sys/cam/cam_xpt.c,v 1.142.2.4 2005/04/01 12:44:03 delphij Exp $"); +__FBSDID("$FreeBSD: src/sys/cam/cam_xpt.c,v 1.155 2005/07/01 15:21:29 avatar Exp $"); #include #include @@ -43,6 +43,9 @@ #include #include +#include +#include + #ifdef PC98 #include /* geometry translation */ #endif @@ -62,6 +65,7 @@ #include "opt_cam.h" /* Datastructures internal to the xpt layer */ +MALLOC_DEFINE(M_CAMXPT, "CAM XPT", "CAM XPT buffers"); /* * Definition of an async handler callback block. These are used to add @@ -200,10 +204,20 @@ #define CAM_QUIRK_NOLUNS 0x01 #define CAM_QUIRK_NOSERIAL 0x02 #define CAM_QUIRK_HILUNS 0x04 +#define CAM_QUIRK_NOHILUNS 0x08 u_int mintags; u_int maxtags; }; #define CAM_SCSI2_MAXLUN 8 +/* + * If we're not quirked to search <= the first 8 luns + * and we are either quirked to search above lun 8, + * or we're > SCSI-2, we can look for luns above lun 8. + */ +#define CAN_SRCH_HI(dv) \ + (((dv->quirk->quirks & CAM_QUIRK_NOHILUNS) == 0) \ + && ((dv->quirk->quirks & CAM_QUIRK_HILUNS) \ + || SID_ANSI_REV(&dv->inq_data) > SCSI_REV_2)) typedef enum { XPT_FLAG_OPEN = 0x01 @@ -552,6 +566,11 @@ CAM_QUIRK_NOLUNS, /*mintags*/0, /*maxtags*/0 }, { + /* EasyRAID E5A aka. areca ARC-6010 */ + { T_DIRECT, SIP_MEDIA_FIXED, "easyRAID", "*", "*" }, + CAM_QUIRK_NOHILUNS, /*mintags*/2, /*maxtags*/255 + }, + { /* Default tagged queuing parameters for all devices */ { T_ANY, SIP_MEDIA_REMOVABLE|SIP_MEDIA_FIXED, @@ -599,7 +618,7 @@ /* Queues for our software interrupt handler */ typedef TAILQ_HEAD(cam_isrq, ccb_hdr) cam_isrq_t; static cam_isrq_t cam_bioq; -static cam_isrq_t cam_netq; +static struct mtx cam_bioq_lock; /* "Pool" of inactive ccbs managed by xpt_alloc_ccb and xpt_free_ccb */ static SLIST_HEAD(,ccb_hdr) ccb_freeq; @@ -659,7 +678,6 @@ #endif /* Pointers to software interrupt handlers */ -static void *camnet_ih; static void *cambio_ih; #if defined(CAM_DEBUG_FLAGS) && !defined(CAMDEBUG) @@ -1368,10 +1386,11 @@ TAILQ_INIT(&xpt_busses); TAILQ_INIT(&cam_bioq); - TAILQ_INIT(&cam_netq); SLIST_INIT(&ccb_freeq); STAILQ_INIT(&highpowerq); + mtx_init(&cam_bioq_lock, "CAM BIOQ lock", NULL, MTX_DEF); + /* * The xpt layer is, itself, the equivelent of a SIM. * Allow 16 ccbs in the ccb pool for it. This should @@ -1430,7 +1449,6 @@ } /* Install our software interrupt handlers */ - swi_add(NULL, "camnet", camisr, &cam_netq, SWI_CAMNET, 0, &camnet_ih); swi_add(NULL, "cambio", camisr, &cam_bioq, SWI_CAMBIO, 0, &cambio_ih); } @@ -3384,12 +3402,12 @@ SLIST_REMOVE(async_head, cur_entry, async_node, links); csa->ccb_h.path->device->refcount--; - free(cur_entry, M_DEVBUF); + free(cur_entry, M_CAMXPT); } else { cur_entry->event_enable = csa->event_enable; } } else { - cur_entry = malloc(sizeof(*cur_entry), M_DEVBUF, + cur_entry = malloc(sizeof(*cur_entry), M_CAMXPT, M_NOWAIT); if (cur_entry == NULL) { splx(s); @@ -3611,7 +3629,6 @@ && (--timeout > 0)) { DELAY(1000); (*(sim->sim_poll))(sim); - camisr(&cam_netq); camisr(&cam_bioq); } @@ -3622,7 +3639,6 @@ xpt_action(start_ccb); while(--timeout > 0) { (*(sim->sim_poll))(sim); - camisr(&cam_netq); camisr(&cam_bioq); if ((start_ccb->ccb_h.status & CAM_STATUS_MASK) != CAM_REQ_INPROG) @@ -4000,7 +4016,7 @@ GIANT_REQUIRED; - path = (struct cam_path *)malloc(sizeof(*path), M_DEVBUF, M_NOWAIT); + path = (struct cam_path *)malloc(sizeof(*path), M_CAMXPT, M_NOWAIT); if (path == NULL) { status = CAM_RESRC_UNAVAIL; @@ -4008,7 +4024,7 @@ } status = xpt_compile_path(path, perph, path_id, target_id, lun_id); if (status != CAM_REQ_CMP) { - free(path, M_DEVBUF); + free(path, M_CAMXPT); path = NULL; } *new_path_ptr = path; @@ -4114,7 +4130,7 @@ CAM_DEBUG(path, CAM_DEBUG_TRACE, ("xpt_free_path\n")); xpt_release_path(path); - free(path, M_DEVBUF); + free(path, M_CAMXPT); } @@ -4340,7 +4356,7 @@ sim->bus_id = bus; new_bus = (struct cam_eb *)malloc(sizeof(*new_bus), - M_DEVBUF, M_NOWAIT); + M_CAMXPT, M_NOWAIT); if (new_bus == NULL) { /* Couldn't satisfy request */ return (CAM_RESRC_UNAVAIL); @@ -4822,8 +4838,6 @@ { int s; - GIANT_REQUIRED; - s = splcam(); CAM_DEBUG(done_ccb->ccb_h.path, CAM_DEBUG_TRACE, ("xpt_done\n")); @@ -4834,17 +4848,16 @@ */ switch (done_ccb->ccb_h.path->periph->type) { case CAM_PERIPH_BIO: + mtx_lock(&cam_bioq_lock); TAILQ_INSERT_TAIL(&cam_bioq, &done_ccb->ccb_h, sim_links.tqe); done_ccb->ccb_h.pinfo.index = CAM_DONEQ_INDEX; + mtx_unlock(&cam_bioq_lock); swi_sched(cambio_ih, 0); break; - case CAM_PERIPH_NET: - TAILQ_INSERT_TAIL(&cam_netq, &done_ccb->ccb_h, - sim_links.tqe); - done_ccb->ccb_h.pinfo.index = CAM_DONEQ_INDEX; - swi_sched(camnet_ih, 0); - break; + default: + panic("unknown periph type %d", + done_ccb->ccb_h.path->periph->type); } } splx(s); @@ -4857,14 +4870,25 @@ GIANT_REQUIRED; - new_ccb = malloc(sizeof(*new_ccb), M_DEVBUF, M_WAITOK); + new_ccb = malloc(sizeof(*new_ccb), M_CAMXPT, M_WAITOK); + return (new_ccb); +} + +union ccb * +xpt_alloc_ccb_nowait() +{ + union ccb *new_ccb; + + GIANT_REQUIRED; + + new_ccb = malloc(sizeof(*new_ccb), M_CAMXPT, M_NOWAIT); return (new_ccb); } void xpt_free_ccb(union ccb *free_ccb) { - free(free_ccb, M_DEVBUF); + free(free_ccb, M_CAMXPT); } @@ -4886,7 +4910,7 @@ s = splsoftcam(); if ((new_ccb = (union ccb *)SLIST_FIRST(&ccb_freeq)) == NULL) { - new_ccb = malloc(sizeof(*new_ccb), M_DEVBUF, M_NOWAIT); + new_ccb = xpt_alloc_ccb_nowait(); if (new_ccb == NULL) { splx(s); return (NULL); @@ -4913,7 +4937,7 @@ TAILQ_REMOVE(&xpt_busses, bus, links); bus_generation++; splx(s); - free(bus, M_DEVBUF); + free(bus, M_CAMXPT); } else splx(s); } @@ -4923,7 +4947,7 @@ { struct cam_et *target; - target = (struct cam_et *)malloc(sizeof(*target), M_DEVBUF, M_NOWAIT); + target = (struct cam_et *)malloc(sizeof(*target), M_CAMXPT, M_NOWAIT); if (target != NULL) { struct cam_et *cur_target; @@ -4965,7 +4989,7 @@ TAILQ_REMOVE(&bus->et_entries, target, links); bus->generation++; splx(s); - free(target, M_DEVBUF); + free(target, M_CAMXPT); xpt_release_bus(bus); } else splx(s); @@ -4989,7 +5013,7 @@ device = NULL; } else { device = (struct cam_ed *)malloc(sizeof(*device), - M_DEVBUF, M_NOWAIT); + M_CAMXPT, M_NOWAIT); } if (device != NULL) { @@ -5003,13 +5027,13 @@ device->lun_id = lun_id; /* Initialize our queues */ if (camq_init(&device->drvq, 0) != 0) { - free(device, M_DEVBUF); + free(device, M_CAMXPT); return (NULL); } if (cam_ccbq_init(&device->ccbq, bus->sim->max_dev_openings) != 0) { camq_fini(&device->drvq); - free(device, M_DEVBUF); + free(device, M_CAMXPT); return (NULL); } SLIST_INIT(&device->asyncs); @@ -5095,7 +5119,9 @@ devq = bus->sim->devq; cam_devq_resize(devq, devq->alloc_queue.array_size - 1); splx(s); - free(device, M_DEVBUF); + camq_fini(&device->drvq); + camq_fini(&device->ccbq.queue); + free(device, M_CAMXPT); xpt_release_target(bus, target); } else splx(s); @@ -5308,7 +5334,7 @@ s = splcam(); device = TAILQ_FIRST(&target->ed_entries); if (device != NULL) { - phl = device->quirk->quirks & CAM_QUIRK_HILUNS; + phl = CAN_SRCH_HI(device); if (device->lun_id == 0) device = TAILQ_NEXT(device, links); } @@ -5324,8 +5350,8 @@ if ((device->quirk->quirks & CAM_QUIRK_NOLUNS) == 0) { /* Try the next lun */ - if (lun_id < (CAM_SCSI2_MAXLUN-1) || - (device->quirk->quirks & CAM_QUIRK_HILUNS)) + if (lun_id < (CAM_SCSI2_MAXLUN-1) + || CAN_SRCH_HI(device)) lun_id++; } } @@ -5351,7 +5377,6 @@ struct cam_path *path; cam_status status; - path = request_ccb->ccb_h.path; status = xpt_create_path(&path, xpt_periph, path_id, target_id, lun_id); if (status != CAM_REQ_CMP) { @@ -5367,8 +5392,8 @@ free(scan_info, M_TEMP); request_ccb->ccb_h.status = CAM_REQ_CMP; xpt_done(request_ccb); - break; } + break; } xpt_setup_ccb(&request_ccb->ccb_h, path, request_ccb->ccb_h.pinfo.priority); @@ -5944,7 +5969,7 @@ /* Clean up from previous instance of this device */ if (path->device->serial_num != NULL) { - free(path->device->serial_num, M_DEVBUF); + free(path->device->serial_num, M_CAMXPT); path->device->serial_num = NULL; path->device->serial_num_len = 0; } @@ -5959,7 +5984,7 @@ have_serialnum = 1; path->device->serial_num = (u_int8_t *)malloc((serial_buf->length + 1), - M_DEVBUF, M_NOWAIT); + M_CAMXPT, M_NOWAIT); if (path->device->serial_num != NULL) { bcopy(serial_buf->serial_num, path->device->serial_num, @@ -6978,15 +7003,26 @@ static void camisr(void *V_queue) { - cam_isrq_t *queue = V_queue; + cam_isrq_t *oqueue = V_queue; + cam_isrq_t queue; int s; struct ccb_hdr *ccb_h; + /* + * Transfer the ccb_bioq list to a temporary list so we can operate + * on it without needing to lock/unlock on every loop. The concat + * function with re-init the real list for us. + */ s = splcam(); - while ((ccb_h = TAILQ_FIRST(queue)) != NULL) { + mtx_lock(&cam_bioq_lock); + TAILQ_INIT(&queue); + TAILQ_CONCAT(&queue, oqueue, sim_links.tqe); + mtx_unlock(&cam_bioq_lock); + + while ((ccb_h = TAILQ_FIRST(&queue)) != NULL) { int runq; - TAILQ_REMOVE(queue, ccb_h, sim_links.tqe); + TAILQ_REMOVE(&queue, ccb_h, sim_links.tqe); ccb_h->pinfo.index = CAM_UNQUEUED_INDEX; splx(s); diff -ru cam_old/cam_xpt.h cam_new/cam_xpt.h --- cam_old/cam_xpt.h Sun Jan 30 00:59:16 2005 +++ cam_new/cam_xpt.h Wed Jan 5 22:34:34 2005 @@ -26,7 +26,7 @@ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * - * $FreeBSD: src/sys/cam/cam_xpt.h,v 1.4.8.1 2005/01/30 00:59:16 imp Exp $ + * $FreeBSD: src/sys/cam/cam_xpt.h,v 1.5 2005/01/05 22:34:34 imp Exp $ */ #ifndef _CAM_CAM_XPT_H diff -ru cam_old/cam_xpt_periph.h cam_new/cam_xpt_periph.h --- cam_old/cam_xpt_periph.h Sun Jan 30 00:59:16 2005 +++ cam_new/cam_xpt_periph.h Fri Jul 1 15:21:29 2005 @@ -27,7 +27,7 @@ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * - * $FreeBSD: src/sys/cam/cam_xpt_periph.h,v 1.3.26.1 2005/01/30 00:59:16 imp Exp $ + * $FreeBSD: src/sys/cam/cam_xpt_periph.h,v 1.5 2005/07/01 15:21:29 avatar Exp $ */ #ifndef _CAM_CAM_XPT_PERIPH_H @@ -39,6 +39,7 @@ #ifdef _KERNEL void xpt_polled_action(union ccb *ccb); union ccb *xpt_alloc_ccb(void); +union ccb *xpt_alloc_ccb_nowait(void); void xpt_free_ccb(union ccb *free_ccb); void xpt_release_ccb(union ccb *released_ccb); void xpt_schedule(struct cam_periph *perph, u_int32_t new_priority); diff -ru cam_old/cam_xpt_sim.h cam_new/cam_xpt_sim.h --- cam_old/cam_xpt_sim.h Sun Jan 30 00:59:16 2005 +++ cam_new/cam_xpt_sim.h Wed Jan 5 22:34:34 2005 @@ -26,7 +26,7 @@ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * - * $FreeBSD: src/sys/cam/cam_xpt_sim.h,v 1.7.26.1 2005/01/30 00:59:16 imp Exp $ + * $FreeBSD: src/sys/cam/cam_xpt_sim.h,v 1.8 2005/01/05 22:34:34 imp Exp $ */ #ifndef _CAM_CAM_XPT_SIM_H diff -ru cam_old/scsi/scsi_all.c cam_new/scsi/scsi_all.c --- cam_old/scsi/scsi_all.c Sat Mar 12 10:05:39 2005 +++ cam_new/scsi/scsi_all.c Thu Apr 14 03:52:50 2005 @@ -28,7 +28,7 @@ */ #include -__FBSDID("$FreeBSD: src/sys/cam/scsi/scsi_all.c,v 1.45.2.2 2005/03/12 10:05:39 delphij Exp $"); +__FBSDID("$FreeBSD: src/sys/cam/scsi/scsi_all.c,v 1.48 2005/04/14 03:52:50 mjacob Exp $"); #include @@ -2311,6 +2311,15 @@ { int i; int num_syncrates; + + /* + * It's a bug if period is zero, but if it is anyway, don't + * die with a divide fault- instead return something which + * 'approximates' async + */ + if (period_factor == 0) { + return (3300); + } num_syncrates = sizeof(scsi_syncrates) / sizeof(scsi_syncrates[0]); /* See if the period is in the "exception" table */ diff -ru cam_old/scsi/scsi_all.h cam_new/scsi/scsi_all.h --- cam_old/scsi/scsi_all.h Sun Jan 30 00:59:16 2005 +++ cam_new/scsi/scsi_all.h Wed Jan 5 22:34:34 2005 @@ -14,7 +14,7 @@ * * Ported to run under 386BSD by Julian Elischer (julian@tfs.com) Sept 1992 * - * $FreeBSD: src/sys/cam/scsi/scsi_all.h,v 1.23.6.1 2005/01/30 00:59:16 imp Exp $ + * $FreeBSD: src/sys/cam/scsi/scsi_all.h,v 1.24 2005/01/05 22:34:34 imp Exp $ */ /* diff -ru cam_old/scsi/scsi_cd.c cam_new/scsi/scsi_cd.c --- cam_old/scsi/scsi_cd.c Wed Mar 30 14:54:17 2005 +++ cam_new/scsi/scsi_cd.c Sat Mar 26 06:05:06 2005 @@ -46,7 +46,7 @@ */ #include -__FBSDID("$FreeBSD: src/sys/cam/scsi/scsi_cd.c,v 1.89.2.3 2005/03/30 14:54:17 ken Exp $"); +__FBSDID("$FreeBSD: src/sys/cam/scsi/scsi_cd.c,v 1.93 2005/03/26 06:05:06 ken Exp $"); #include "opt_cd.h" @@ -1909,7 +1909,7 @@ struct cam_periph *periph; struct cd_softc *softc; - int error; + int error, nocopyout; periph = (struct cam_periph *)dp->d_drv1; if (periph == NULL) @@ -1946,6 +1946,7 @@ } } + nocopyout = 0; switch (cmd) { case CDIOCPLAYTRACKS: @@ -2104,6 +2105,9 @@ error = cdplay(periph, args->blk, args->len); } break; + case CDIOCREADSUBCHANNEL_SYSSPACE: + nocopyout = 1; + /* Fallthrough */ case CDIOCREADSUBCHANNEL: { struct ioc_read_subchannel *args @@ -2144,8 +2148,12 @@ len = min(len, ((data->header.data_len[0] << 8) + data->header.data_len[1] + sizeof(struct cd_sub_channel_header))); - if (copyout(data, args->data, len) != 0) { - error = EFAULT; + if (nocopyout == 0) { + if (copyout(data, args->data, len) != 0) { + error = EFAULT; + } + } else { + bcopy(data, args->data, len); } free(data, M_TEMP); } diff -ru cam_old/scsi/scsi_ch.c cam_new/scsi/scsi_ch.c --- cam_old/scsi/scsi_ch.c Wed Mar 30 14:52:03 2005 +++ cam_new/scsi/scsi_ch.c Sat Mar 26 04:21:11 2005 @@ -68,7 +68,7 @@ */ #include -__FBSDID("$FreeBSD: src/sys/cam/scsi/scsi_ch.c,v 1.40.2.2 2005/03/30 14:52:03 ken Exp $"); +__FBSDID("$FreeBSD: src/sys/cam/scsi/scsi_ch.c,v 1.42 2005/03/26 04:21:11 ken Exp $"); #include #include diff -ru cam_old/scsi/scsi_ch.h cam_new/scsi/scsi_ch.h --- cam_old/scsi/scsi_ch.h Sun Jan 30 00:59:16 2005 +++ cam_new/scsi/scsi_ch.h Wed Jan 5 22:34:34 2005 @@ -1,4 +1,4 @@ -/* $FreeBSD: src/sys/cam/scsi/scsi_ch.h,v 1.4.4.1 2005/01/30 00:59:16 imp Exp $ */ +/* $FreeBSD: src/sys/cam/scsi/scsi_ch.h,v 1.5 2005/01/05 22:34:34 imp Exp $ */ /* $NetBSD: scsi_changer.h,v 1.11 1998/02/13 08:28:32 enami Exp $ */ /*- diff -ru cam_old/scsi/scsi_da.c cam_new/scsi/scsi_da.c --- cam_old/scsi/scsi_da.c Sun Jan 30 00:59:16 2005 +++ cam_new/scsi/scsi_da.c Thu Jun 9 17:35:04 2005 @@ -27,11 +27,7 @@ */ #include -__FBSDID("$FreeBSD: src/sys/cam/scsi/scsi_da.c,v 1.171.2.1 2005/01/30 00:59:16 imp Exp $"); - -#ifdef _KERNEL -#include "opt_hw_wdog.h" -#endif /* _KERNEL */ +__FBSDID("$FreeBSD: src/sys/cam/scsi/scsi_da.c,v 1.180 2005/06/09 17:35:04 pjd Exp $"); #include @@ -204,6 +200,7 @@ { /* * Doesn't like the synchronize cache command. + * Reported by: Blaz Zupan */ {T_DIRECT, SIP_MEDIA_FIXED, quantum, "MAVERICK 540S", "*"}, /*quirks*/ DA_Q_NO_SYNC_CACHE @@ -217,6 +214,14 @@ }, { /* + * Doesn't like the synchronize cache command. + * Reported by: walter@pelissero.de + */ + {T_DIRECT, SIP_MEDIA_FIXED, quantum, "LPS540S", "*"}, + /*quirks*/ DA_Q_NO_SYNC_CACHE + }, + { + /* * Doesn't work correctly with 6 byte reads/writes. * Returns illegal request, and points to byte 9 of the * 6-byte CDB. @@ -232,6 +237,14 @@ }, { /* + * Doesn't like the synchronize cache command. + * Reported by: walter@pelissero.de + */ + {T_DIRECT, SIP_MEDIA_FIXED, "CONNER", "CP3500*", "*"}, + /*quirks*/ DA_Q_NO_SYNC_CACHE + }, + { + /* * The CISS RAID controllers do not support SYNC_CACHE */ {T_DIRECT, SIP_MEDIA_FIXED, "COMPAQ", "RAID*", "*"}, @@ -315,7 +328,30 @@ * Frontier Labs NEX IA+ Digital Audio Player, rev 1.10/0.01 * PR: kern/70158 */ - {T_DIRECT, SIP_MEDIA_REMOVABLE, "FL" , "NexIA+*", "*"}, + {T_DIRECT, SIP_MEDIA_REMOVABLE, "FL" , "Nex*", "*"}, + /*quirks*/ DA_Q_NO_SYNC_CACHE + }, + { + /* + * ZICPlay USB MP3 Player with FM + * PR: kern/75057 + */ + {T_DIRECT, SIP_MEDIA_REMOVABLE, "ACTIONS*" , "USB DISK*", "*"}, + /*quirks*/ DA_Q_NO_SYNC_CACHE + }, + { + /* + * TEAC USB floppy mechanisms + */ + {T_DIRECT, SIP_MEDIA_REMOVABLE, "TEAC" , "FD-05*", "*"}, + /*quirks*/ DA_Q_NO_SYNC_CACHE + }, + { + /* + * Kingston DataTraveler II+ USB Pen-Drive. + * Reported by: Pawel Jakub Dawidek + */ + {T_DIRECT, SIP_MEDIA_REMOVABLE, "Kingston" , "DataTraveler II+", "*"}, /*quirks*/ DA_Q_NO_SYNC_CACHE }, }; diff -ru cam_old/scsi/scsi_da.h cam_new/scsi/scsi_da.h --- cam_old/scsi/scsi_da.h Sat Feb 5 09:19:04 2005 +++ cam_new/scsi/scsi_da.h Wed Jan 5 22:34:34 2005 @@ -46,7 +46,7 @@ * * Ported to run under 386BSD by Julian Elischer (julian@tfs.com) Sept 1992 * - * $FreeBSD: src/sys/cam/scsi/scsi_da.h,v 1.5.8.2 2005/02/05 09:19:04 bms Exp $ + * $FreeBSD: src/sys/cam/scsi/scsi_da.h,v 1.8 2005/01/05 22:34:34 imp Exp $ */ #ifndef _SCSI_SCSI_DA_H diff -ru cam_old/scsi/scsi_dvcfg.h cam_new/scsi/scsi_dvcfg.h --- cam_old/scsi/scsi_dvcfg.h Sun Jan 30 00:59:16 2005 +++ cam_new/scsi/scsi_dvcfg.h Wed Jan 5 22:34:34 2005 @@ -1,4 +1,4 @@ -/* $FreeBSD: src/sys/cam/scsi/scsi_dvcfg.h,v 1.1.10.1 2005/01/30 00:59:16 imp Exp $ */ +/* $FreeBSD: src/sys/cam/scsi/scsi_dvcfg.h,v 1.2 2005/01/05 22:34:34 imp Exp $ */ /* $NecBSD: scsi_dvcfg.h,v 1.4 1998/03/14 07:05:06 kmatsuda Exp $ */ /* $NetBSD$ */ diff -ru cam_old/scsi/scsi_iu.h cam_new/scsi/scsi_iu.h --- cam_old/scsi/scsi_iu.h Sun Jan 30 00:59:16 2005 +++ cam_new/scsi/scsi_iu.h Wed Jan 5 22:34:34 2005 @@ -1,6 +1,6 @@ /*- * This file is in the public domain. - * $FreeBSD: src/sys/cam/scsi/scsi_iu.h,v 1.2.6.1 2005/01/30 00:59:16 imp Exp $ + * $FreeBSD: src/sys/cam/scsi/scsi_iu.h,v 1.3 2005/01/05 22:34:34 imp Exp $ */ #ifndef _SCSI_SCSI_IU_H #define _SCSI_SCSI_IU_H 1 diff -ru cam_old/scsi/scsi_low.c cam_new/scsi/scsi_low.c --- cam_old/scsi/scsi_low.c Fri Apr 1 12:29:23 2005 +++ cam_new/scsi/scsi_low.c Fri Jul 1 15:21:30 2005 @@ -2,7 +2,7 @@ /* $NetBSD$ */ #include -__FBSDID("$FreeBSD: src/sys/cam/scsi/scsi_low.c,v 1.21.4.2 2005/04/01 12:29:23 delphij Exp $"); +__FBSDID("$FreeBSD: src/sys/cam/scsi/scsi_low.c,v 1.24 2005/07/01 15:21:30 avatar Exp $"); #define SCSI_LOW_STATICS #define SCSI_LOW_DEBUG @@ -111,6 +111,7 @@ #include #include #include +#include #include #include @@ -144,6 +145,8 @@ #define SCSI_LOW_DISK_LFLAGS 0x0000ffff #define SCSI_LOW_DISK_TFLAGS 0xffff0000 +MALLOC_DEFINE(M_SCSILOW, "SCSI low", "SCSI low buffers"); + /************************************************************** * Declarations **************************************************************/ @@ -394,8 +397,8 @@ * SCSI INTERFACE (XS) **************************************************************/ #define SCSI_LOW_MINPHYS 0x10000 -#define SCSI_LOW_MALLOC(size) malloc((size), M_DEVBUF, M_NOWAIT) -#define SCSI_LOW_FREE(pt) free((pt), M_DEVBUF) +#define SCSI_LOW_MALLOC(size) malloc((size), M_SCSILOW, M_NOWAIT) +#define SCSI_LOW_FREE(pt) free((pt), M_SCSILOW) #define SCSI_LOW_ALLOC_CCB(flags) scsi_low_get_ccb((flags)) #define SCSI_LOW_XS_POLL_HZ 1000 @@ -884,8 +887,8 @@ /************************************************************** * SCSI INTERFACE (CAM) **************************************************************/ -#define SCSI_LOW_MALLOC(size) malloc((size), M_DEVBUF, M_NOWAIT) -#define SCSI_LOW_FREE(pt) free((pt), M_DEVBUF) +#define SCSI_LOW_MALLOC(size) malloc((size), M_SCSILOW, M_NOWAIT) +#define SCSI_LOW_FREE(pt) free((pt), M_SCSILOW) #define SCSI_LOW_ALLOC_CCB(flags) scsi_low_get_ccb() static void scsi_low_poll_cam(struct cam_sim *); @@ -955,7 +958,7 @@ { xpt_free_path(ccb->ccb_h.path); - free(ccb, M_DEVBUF); + xpt_free_ccb(ccb); } static void @@ -963,7 +966,7 @@ struct scsi_low_softc *slp; { struct cam_path *path; - union ccb *ccb = malloc(sizeof(union ccb), M_DEVBUF, M_WAITOK); + union ccb *ccb = xpt_alloc_ccb(); cam_status status; bzero(ccb, sizeof(union ccb)); @@ -1412,7 +1415,7 @@ } if (xpt_bus_register(slp->sl_si.sim, 0) != CAM_SUCCESS) { - free(slp->sl_si.sim, M_DEVBUF); + free(slp->sl_si.sim, M_SCSILOW); return ENODEV; } diff -ru cam_old/scsi/scsi_low.h cam_new/scsi/scsi_low.h --- cam_old/scsi/scsi_low.h Sun Jan 30 00:59:16 2005 +++ cam_new/scsi/scsi_low.h Wed Jan 5 22:34:34 2005 @@ -1,4 +1,4 @@ -/* $FreeBSD: src/sys/cam/scsi/scsi_low.h,v 1.7.2.1 2005/01/30 00:59:16 imp Exp $ */ +/* $FreeBSD: src/sys/cam/scsi/scsi_low.h,v 1.8 2005/01/05 22:34:34 imp Exp $ */ /* $NecBSD: scsi_low.h,v 1.24.10.5 2001/06/26 07:31:46 honda Exp $ */ /* $NetBSD$ */ diff -ru cam_old/scsi/scsi_low_pisa.c cam_new/scsi/scsi_low_pisa.c --- cam_old/scsi/scsi_low_pisa.c Sun Jan 30 00:59:16 2005 +++ cam_new/scsi/scsi_low_pisa.c Wed Jan 5 22:34:34 2005 @@ -32,7 +32,7 @@ */ #include -__FBSDID("$FreeBSD: src/sys/cam/scsi/scsi_low_pisa.c,v 1.7.4.1 2005/01/30 00:59:16 imp Exp $"); +__FBSDID("$FreeBSD: src/sys/cam/scsi/scsi_low_pisa.c,v 1.8 2005/01/05 22:34:34 imp Exp $"); #ifdef __NetBSD__ #include diff -ru cam_old/scsi/scsi_low_pisa.h cam_new/scsi/scsi_low_pisa.h --- cam_old/scsi/scsi_low_pisa.h Sun Jan 30 00:59:16 2005 +++ cam_new/scsi/scsi_low_pisa.h Wed Jan 5 22:34:34 2005 @@ -1,4 +1,4 @@ -/* $FreeBSD: src/sys/cam/scsi/scsi_low_pisa.h,v 1.4.8.1 2005/01/30 00:59:16 imp Exp $ */ +/* $FreeBSD: src/sys/cam/scsi/scsi_low_pisa.h,v 1.5 2005/01/05 22:34:34 imp Exp $ */ /* $NecBSD: scsi_low_pisa.h,v 1.3.14.1 2001/06/08 06:27:49 honda Exp $ */ /* $NetBSD$ */ diff -ru cam_old/scsi/scsi_message.h cam_new/scsi/scsi_message.h --- cam_old/scsi/scsi_message.h Sun Jan 30 00:59:16 2005 +++ cam_new/scsi/scsi_message.h Wed Jan 5 22:34:34 2005 @@ -1,6 +1,6 @@ /*- * This file is in the public domain. - * $FreeBSD: src/sys/cam/scsi/scsi_message.h,v 1.6.8.1 2005/01/30 00:59:16 imp Exp $ + * $FreeBSD: src/sys/cam/scsi/scsi_message.h,v 1.7 2005/01/05 22:34:34 imp Exp $ */ /* Messages (1 byte) */ /* I/T (M)andatory or (O)ptional */ diff -ru cam_old/scsi/scsi_pass.c cam_new/scsi/scsi_pass.c --- cam_old/scsi/scsi_pass.c Fri Apr 1 12:40:25 2005 +++ cam_new/scsi/scsi_pass.c Sat Jan 22 07:21:25 2005 @@ -26,7 +26,7 @@ */ #include -__FBSDID("$FreeBSD: src/sys/cam/scsi/scsi_pass.c,v 1.41.2.2 2005/04/01 12:40:25 delphij Exp $"); +__FBSDID("$FreeBSD: src/sys/cam/scsi/scsi_pass.c,v 1.43 2005/01/22 07:21:25 mjacob Exp $"); #include #include diff -ru cam_old/scsi/scsi_pass.h cam_new/scsi/scsi_pass.h --- cam_old/scsi/scsi_pass.h Sun Jan 30 00:59:17 2005 +++ cam_new/scsi/scsi_pass.h Wed Jan 5 22:34:34 2005 @@ -22,7 +22,7 @@ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * - * $FreeBSD: src/sys/cam/scsi/scsi_pass.h,v 1.4.8.1 2005/01/30 00:59:17 imp Exp $ + * $FreeBSD: src/sys/cam/scsi/scsi_pass.h,v 1.5 2005/01/05 22:34:34 imp Exp $ */ #ifndef _SCSI_PASS_H diff -ru cam_old/scsi/scsi_pt.c cam_new/scsi/scsi_pt.c --- cam_old/scsi/scsi_pt.c Sun Jan 30 00:59:17 2005 +++ cam_new/scsi/scsi_pt.c Wed Jan 5 22:34:34 2005 @@ -27,7 +27,7 @@ */ #include -__FBSDID("$FreeBSD: src/sys/cam/scsi/scsi_pt.c,v 1.42.2.1 2005/01/30 00:59:17 imp Exp $"); +__FBSDID("$FreeBSD: src/sys/cam/scsi/scsi_pt.c,v 1.43 2005/01/05 22:34:34 imp Exp $"); #include #include diff -ru cam_old/scsi/scsi_pt.h cam_new/scsi/scsi_pt.h --- cam_old/scsi/scsi_pt.h Sun Jan 30 00:59:17 2005 +++ cam_new/scsi/scsi_pt.h Wed Jan 5 22:34:35 2005 @@ -25,7 +25,7 @@ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * - * $FreeBSD: src/sys/cam/scsi/scsi_pt.h,v 1.3.8.1 2005/01/30 00:59:17 imp Exp $ + * $FreeBSD: src/sys/cam/scsi/scsi_pt.h,v 1.4 2005/01/05 22:34:35 imp Exp $ */ #ifndef _SCSI_SCSI_PT_H diff -ru cam_old/scsi/scsi_sa.c cam_new/scsi/scsi_sa.c --- cam_old/scsi/scsi_sa.c Sun Jan 30 00:59:17 2005 +++ cam_new/scsi/scsi_sa.c Fri Jul 1 15:21:30 2005 @@ -27,7 +27,7 @@ */ #include -__FBSDID("$FreeBSD: src/sys/cam/scsi/scsi_sa.c,v 1.101.2.1 2005/01/30 00:59:17 imp Exp $"); +__FBSDID("$FreeBSD: src/sys/cam/scsi/scsi_sa.c,v 1.105 2005/07/01 15:21:30 avatar Exp $"); #include #include @@ -101,6 +101,7 @@ * Driver states */ +MALLOC_DEFINE(M_SCSISA, "SCSI sa", "SCSI sequential access buffers"); typedef enum { SA_STATE_NORMAL, SA_STATE_ABNORMAL @@ -810,10 +811,29 @@ } break; + case MTIOCTOP: + { + struct mtop *mt = (struct mtop *) arg; + + /* + * Check to make sure it's an OP we can perform + * with no media inserted. + */ + switch (mt->mt_op) { + case MTSETBSIZ: + case MTSETDNSTY: + case MTCOMP: + mt = NULL; + /* FALLTHROUGH */ + default: + break; + } + if (mt != NULL) { + break; + } + /* FALLTHROUGH */ + } case MTIOCSETEOTMODEL: - case MTSETBSIZ: - case MTSETDNSTY: - case MTCOMP: /* * We need to acquire the peripheral here rather * than at open time because we are sharing writable @@ -1335,7 +1355,7 @@ xpt_print_path(periph->path); printf("removing device entry\n"); - free(softc, M_DEVBUF); + free(softc, M_SCSISA); } static void @@ -1401,7 +1421,7 @@ } softc = (struct sa_softc *) - malloc(sizeof (*softc), M_DEVBUF, M_NOWAIT | M_ZERO); + malloc(sizeof (*softc), M_SCSISA, M_NOWAIT | M_ZERO); if (softc == NULL) { printf("saregister: Unable to probe new device. " "Unable to allocate softc\n"); @@ -1822,8 +1842,8 @@ * will now attempt to rewind/load it. */ softc->flags &= ~SA_FLAG_TAPE_MOUNTED; - if (CAM_DEBUGGED(ccb->ccb_h.path, CAM_DEBUG_INFO)) { - xpt_print_path(ccb->ccb_h.path); + if (CAM_DEBUGGED(periph->path, CAM_DEBUG_INFO)) { + xpt_print_path(periph->path); printf("error %d on TUR in samount\n", error); } } @@ -1887,7 +1907,7 @@ rblim = (struct scsi_read_block_limits_data *) malloc(8192, M_TEMP, M_WAITOK); if (rblim == NULL) { - xpt_print_path(ccb->ccb_h.path); + xpt_print_path(periph->path); printf("no memory for test read\n"); xpt_release_ccb(ccb); error = ENOMEM; @@ -1909,7 +1929,7 @@ softc->device_stats); QFRLS(ccb); if (error) { - xpt_print_path(ccb->ccb_h.path); + xpt_print_path(periph->path); printf("unable to rewind after test read\n"); xpt_release_ccb(ccb); goto exit; @@ -2074,7 +2094,7 @@ if ((softc->max_blk < softc->media_blksize) || (softc->min_blk > softc->media_blksize && softc->media_blksize)) { - xpt_print_path(ccb->ccb_h.path); + xpt_print_path(periph->path); printf("BLOCK LIMITS (%d..%d) could not match current " "block settings (%d)- adjusting\n", softc->min_blk, softc->max_blk, softc->media_blksize); @@ -2109,7 +2129,7 @@ error = sasetparams(periph, SA_PARAM_BLOCKSIZE, softc->media_blksize, 0, 0, SF_NO_PRINT); if (error) { - xpt_print_path(ccb->ccb_h.path); + xpt_print_path(periph->path); printf("unable to set fixed blocksize to %d\n", softc->media_blksize); goto exit; @@ -2136,7 +2156,7 @@ softc->last_media_blksize = 512; goto tryagain; } - xpt_print_path(ccb->ccb_h.path); + xpt_print_path(periph->path); printf("unable to set variable blocksize\n"); goto exit; } @@ -2194,7 +2214,7 @@ if (error == 0) { softc->buffer_mode = SMH_SA_BUF_MODE_SIBUF; } else { - xpt_print_path(ccb->ccb_h.path); + xpt_print_path(periph->path); printf("unable to set buffered mode\n"); } error = 0; /* not an error */ diff -ru cam_old/scsi/scsi_sa.h cam_new/scsi/scsi_sa.h --- cam_old/scsi/scsi_sa.h Sun Jan 30 00:59:17 2005 +++ cam_new/scsi/scsi_sa.h Wed Jan 5 22:34:35 2005 @@ -26,7 +26,7 @@ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * - * $FreeBSD: src/sys/cam/scsi/scsi_sa.h,v 1.9.8.1 2005/01/30 00:59:17 imp Exp $ + * $FreeBSD: src/sys/cam/scsi/scsi_sa.h,v 1.10 2005/01/05 22:34:35 imp Exp $ */ #ifndef _SCSI_SCSI_SA_H diff -ru cam_old/scsi/scsi_ses.c cam_new/scsi/scsi_ses.c --- cam_old/scsi/scsi_ses.c Fri Apr 1 12:40:25 2005 +++ cam_new/scsi/scsi_ses.c Fri Jul 1 15:21:30 2005 @@ -25,7 +25,7 @@ */ #include -__FBSDID("$FreeBSD: src/sys/cam/scsi/scsi_ses.c,v 1.29.2.2 2005/04/01 12:40:25 delphij Exp $"); +__FBSDID("$FreeBSD: src/sys/cam/scsi/scsi_ses.c,v 1.32 2005/07/01 15:21:30 avatar Exp $"); #include #include @@ -51,6 +51,8 @@ #include +MALLOC_DEFINE(M_SCSISES, "SCSI SES", "SCSI SES buffers"); + /* * Platform Independent Driver Internal Definitions for SES devices. */ @@ -120,8 +122,8 @@ #define SES_DLOG if (0) ses_log #endif #define SES_VLOG if (bootverbose) ses_log -#define SES_MALLOC(amt) malloc(amt, M_DEVBUF, M_NOWAIT) -#define SES_FREE(ptr, amt) free(ptr, M_DEVBUF) +#define SES_MALLOC(amt) malloc(amt, M_SCSISES, M_NOWAIT) +#define SES_FREE(ptr, amt) free(ptr, M_SCSISES) #define MEMZERO bzero #define MEMCPY(dest, src, amt) bcopy(src, dest, amt) @@ -250,7 +252,7 @@ xpt_print_path(periph->path); printf("removing device entry\n"); - free(softc, M_DEVBUF); + free(softc, M_SCSISES); } static void @@ -324,7 +326,7 @@ return (CAM_REQ_CMP_ERR); } - softc = malloc(sizeof (struct ses_softc), M_DEVBUF, M_NOWAIT); + softc = malloc(sizeof (struct ses_softc), M_SCSISES, M_NOWAIT); if (softc == NULL) { printf("sesregister: Unable to probe new device. " "Unable to allocate softc\n"); @@ -359,7 +361,7 @@ break; case SES_NONE: default: - free(softc, M_DEVBUF); + free(softc, M_SCSISES); return (CAM_REQ_CMP_ERR); } diff -ru cam_old/scsi/scsi_ses.h cam_new/scsi/scsi_ses.h --- cam_old/scsi/scsi_ses.h Sun Jan 30 00:59:17 2005 +++ cam_new/scsi/scsi_ses.h Wed Jan 5 22:34:35 2005 @@ -1,4 +1,4 @@ -/* $FreeBSD: src/sys/cam/scsi/scsi_ses.h,v 1.2.26.1 2005/01/30 00:59:17 imp Exp $ */ +/* $FreeBSD: src/sys/cam/scsi/scsi_ses.h,v 1.3 2005/01/05 22:34:35 imp Exp $ */ /*- * Copyright (c) 2000 by Matthew Jacob * All rights reserved. diff -ru cam_old/scsi/scsi_targ_bh.c cam_new/scsi/scsi_targ_bh.c --- cam_old/scsi/scsi_targ_bh.c Sun Jan 30 00:59:17 2005 +++ cam_new/scsi/scsi_targ_bh.c Fri Jul 1 15:21:30 2005 @@ -27,7 +27,7 @@ */ #include -__FBSDID("$FreeBSD: src/sys/cam/scsi/scsi_targ_bh.c,v 1.20.4.1 2005/01/30 00:59:17 imp Exp $"); +__FBSDID("$FreeBSD: src/sys/cam/scsi/scsi_targ_bh.c,v 1.22 2005/07/01 15:21:30 avatar Exp $"); #include #include @@ -50,6 +50,8 @@ #include #include +MALLOC_DEFINE(M_SCSIBH, "SCSI bh", "SCSI blackhole buffers"); + typedef enum { TARGBH_STATE_NORMAL, TARGBH_STATE_EXCEPTION, @@ -276,7 +278,7 @@ for (i = 0; i < MAX_ACCEPT; i++) { struct ccb_accept_tio *atio; - atio = (struct ccb_accept_tio*)malloc(sizeof(*atio), M_DEVBUF, + atio = (struct ccb_accept_tio*)malloc(sizeof(*atio), M_SCSIBH, M_NOWAIT); if (atio == NULL) { status = CAM_RESRC_UNAVAIL; @@ -286,7 +288,7 @@ atio->ccb_h.ccb_descr = targbhallocdescr(); if (atio->ccb_h.ccb_descr == NULL) { - free(atio, M_DEVBUF); + free(atio, M_SCSIBH); status = CAM_RESRC_UNAVAIL; break; } @@ -298,7 +300,7 @@ status = atio->ccb_h.status; if (status != CAM_REQ_INPROG) { targbhfreedescr(atio->ccb_h.ccb_descr); - free(atio, M_DEVBUF); + free(atio, M_SCSIBH); break; } ((struct targbh_cmd_desc*)atio->ccb_h.ccb_descr)->atio_link = @@ -321,7 +323,7 @@ for (i = 0; i < MAX_ACCEPT; i++) { struct ccb_immed_notify *inot; - inot = (struct ccb_immed_notify*)malloc(sizeof(*inot), M_DEVBUF, + inot = (struct ccb_immed_notify*)malloc(sizeof(*inot), M_SCSIBH, M_NOWAIT); if (inot == NULL) { @@ -335,7 +337,7 @@ xpt_action((union ccb *)inot); status = inot->ccb_h.status; if (status != CAM_REQ_INPROG) { - free(inot, M_DEVBUF); + free(inot, M_SCSIBH); break; } SLIST_INSERT_HEAD(&softc->immed_notify_slist, &inot->ccb_h, @@ -409,7 +411,7 @@ /* Allocate our per-instance private storage */ softc = (struct targbh_softc *)malloc(sizeof(*softc), - M_DEVBUF, M_NOWAIT); + M_SCSIBH, M_NOWAIT); if (softc == NULL) { printf("targctor: unable to malloc softc\n"); return (CAM_REQ_CMP_ERR); @@ -446,7 +448,7 @@ default: /* XXX Wait for callback of targbhdislun() */ tsleep(softc, PRIBIO, "targbh", hz/2); - free(softc, M_DEVBUF); + free(softc, M_SCSIBH); break; } } @@ -576,7 +578,7 @@ if (softc->state == TARGBH_STATE_TEARDOWN || atio->ccb_h.status == CAM_REQ_ABORTED) { targbhfreedescr(descr); - free(done_ccb, M_DEVBUF); + xpt_free_ccb(done_ccb); return; } @@ -725,7 +727,7 @@ break; } else { targbhfreedescr(desc); - free(atio, M_DEVBUF); + free(atio, M_SCSIBH); } break; } @@ -737,7 +739,7 @@ if (softc->state == TARGBH_STATE_TEARDOWN || done_ccb->ccb_h.status == CAM_REQ_ABORTED) { printf("Freed an immediate notify\n"); - free(done_ccb, M_DEVBUF); + xpt_free_ccb(done_ccb); } else { /* Requeue for another immediate event */ xpt_action(done_ccb); @@ -771,16 +773,16 @@ /* Allocate the targbh_descr structure */ descr = (struct targbh_cmd_desc *)malloc(sizeof(*descr), - M_DEVBUF, M_NOWAIT); + M_SCSIBH, M_NOWAIT); if (descr == NULL) return (NULL); bzero(descr, sizeof(*descr)); /* Allocate buffer backing store */ - descr->backing_store = malloc(MAX_BUF_SIZE, M_DEVBUF, M_NOWAIT); + descr->backing_store = malloc(MAX_BUF_SIZE, M_SCSIBH, M_NOWAIT); if (descr->backing_store == NULL) { - free(descr, M_DEVBUF); + free(descr, M_SCSIBH); return (NULL); } descr->max_size = MAX_BUF_SIZE; @@ -790,6 +792,6 @@ static void targbhfreedescr(struct targbh_cmd_desc *descr) { - free(descr->backing_store, M_DEVBUF); - free(descr, M_DEVBUF); + free(descr->backing_store, M_SCSIBH); + free(descr, M_SCSIBH); } diff -ru cam_old/scsi/scsi_target.c cam_new/scsi/scsi_target.c --- cam_old/scsi/scsi_target.c Sat Mar 12 09:59:33 2005 +++ cam_new/scsi/scsi_target.c Mon Aug 8 19:55:30 2005 @@ -28,7 +28,7 @@ */ #include -__FBSDID("$FreeBSD: src/sys/cam/scsi/scsi_target.c,v 1.63.2.2 2005/03/12 09:59:33 delphij Exp $"); +__FBSDID("$FreeBSD: src/sys/cam/scsi/scsi_target.c,v 1.68 2005/08/08 19:55:30 rwatson Exp $"); #include #include @@ -141,8 +141,8 @@ static struct targ_cmd_descr * targgetdescr(struct targ_softc *softc); static periph_init_t targinit; -static void targclone(void *arg, char *name, int namelen, - struct cdev **dev); +static void targclone(void *arg, struct ucred *cred, char *name, + int namelen, struct cdev **dev); static void targasync(void *callback_arg, u_int32_t code, struct cam_path *path, void *arg); static void abort_all_pending(struct targ_softc *softc); @@ -196,7 +196,7 @@ TAILQ_INIT(&softc->work_queue); TAILQ_INIT(&softc->abort_queue); TAILQ_INIT(&softc->user_ccb_queue); - knlist_init(&softc->read_select.si_note, &softc->mtx); + knlist_init(&softc->read_select.si_note, &softc->mtx, NULL, NULL, NULL); return (0); } @@ -1025,7 +1025,8 @@ } static void -targclone(void *arg, char *name, int namelen, struct cdev **dev) +targclone(void *arg, struct ucred *cred, char *name, int namelen, + struct cdev **dev) { int u; @@ -1035,6 +1036,7 @@ return; *dev = make_dev(&targ_cdevsw, unit2minor(u), UID_ROOT, GID_WHEEL, 0600, "targ%d", u); + dev_ref(*dev); (*dev)->si_flags |= SI_CHEAPCLONE; } diff -ru cam_old/scsi/scsi_targetio.h cam_new/scsi/scsi_targetio.h --- cam_old/scsi/scsi_targetio.h Sun Jan 30 00:59:17 2005 +++ cam_new/scsi/scsi_targetio.h Wed Jan 5 22:34:35 2005 @@ -26,7 +26,7 @@ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * - * $FreeBSD: src/sys/cam/scsi/scsi_targetio.h,v 1.11.8.1 2005/01/30 00:59:17 imp Exp $ + * $FreeBSD: src/sys/cam/scsi/scsi_targetio.h,v 1.12 2005/01/05 22:34:35 imp Exp $ */ #ifndef _CAM_SCSI_SCSI_TARGETIO_H_ --=-FYZp8LaGu/8HvL5hC1wt-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 00:24:43 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 E2F6D16A41F; Thu, 1 Sep 2005 00:24:43 +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 5FCB743D45; Thu, 1 Sep 2005 00:24:43 +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 j810LIHj014693; Wed, 31 Aug 2005 18:21:18 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 31 Aug 2005 18:21:44 -0600 (MDT) Message-Id: <20050831.182144.12174403.imp@bsdimp.com> To: mi+mx@aldan.algebra.com From: "M. Warner Losh" In-Reply-To: <200508311920.02927.mi+mx@aldan.algebra.com> References: <200508301223.20626.mi+mx@aldan.algebra.com> <20050831.171259.56563279.imp@bsdimp.com> <200508311920.02927.mi+mx@aldan.algebra.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Wed, 31 Aug 2005 18:21:18 -0600 (MDT) Cc: re@freebsd.org, current@freebsd.org Subject: Re: installing 6.0-BETA3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2005 00:24:44 -0000 In message: <200508311920.02927.mi+mx@aldan.algebra.com> Mikhail Teterin writes: : > I have a number of pending MFCs for PC Cards to make them work a lo= t : > better than they do now. =A0Maybe they will solve your problems. : = : Before 6.0-RELEASE? Great! I hope so. I need to put together an actual patch for the re@ to sign off on, however. That's what the holdup has been... Warner From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 00:30: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 BB4BC16A41F for ; Thu, 1 Sep 2005 00:30:16 +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 D94A043D45 for ; Thu, 1 Sep 2005 00:30:11 +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.3/8.13.3) with ESMTP id j810hZOv010101; Wed, 31 Aug 2005 18:43:36 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <43164B88.8010903@samsco.org> Date: Wed, 31 Aug 2005 18:30:00 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ticso@cicely.de References: <1125452228.740.3.camel@arbitor.homelinux.com> <47d0403c05083020044f6ac0be@mail.gmail.com> <4315CEEC.80100@samsco.org> <20050831174631.GE37930@cicely12.cicely.de> <4315F15D.4090209@samsco.org> <20050831221535.GB670@cicely12.cicely.de> <4316370E.4030809@samsco.org> <20050901000216.GD670@cicely12.cicely.de> In-Reply-To: <20050901000216.GD670@cicely12.cicely.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: freebsd-current@freebsd.org, Kyle Brooks , Ben Kaduk Subject: Re: panic after removing usb flash drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2005 00:30:16 -0000 Bernd Walter wrote: > On Wed, Aug 31, 2005 at 05:02:38PM -0600, Scott Long wrote: > >>Bernd Walter wrote: >> >>>On Wed, Aug 31, 2005 at 12:05:17PM -0600, Scott Long wrote: >>>What bugs are you refering? >> >>The CAM detach code should be returning EBUSY errors since the 'da' >>periph has open references to it. I'm pretty sure that thse errors >>are being ignored by umass.c, leading to the SIM going away unexpectedly >>to CAM. > > > OK. > > >>>Sample code on how to correctly detach a sim a sparse. >>>The umass code doesn't know that devices on a scbus are in use, or >>>should it? >> >>Well, it doesn't need to right now because you only have one target >>per SIM. It should though; most normal SCSI drivers keep a table of >>known devices in order to remember negotiated transfer settings and >>handle reconnections. > > > OK. > > >>>In the USB-world we have the problem that a blocking detach blocks >>>other port attachment/detachments on the same bus as well. >>>This is because we currently have a single thread per bus processing >>>these events. >>>We already see this problem with ucom devices where an open tty on a >>>detached device blocks. >>>But it is better than the panic that we have right now. >>>In the tty case we have a timeout, don't know what we can do with CAM. >>> >> >>In the sim-per-target model, you need to completely drain the simq and >>devq for the SIM before allowing detach to complete. This means >>freezing the simq then waiting until the camisr can run and process any >>pending CCBs on the completion queue. The camisr is an SWI, so you'll >>need to sleep so that it can run. > > > Sounds doable. > You could probably get around the problem of sleeping in the USB event thread by doing the sleep parts of the detach in a taskqueue. But that just adds more complexity and more need for synchronization. If the only choice was to retain the SIM-per-device model then this is what I would do, but it's not a choice that I like. > >>>With the single-sim design we have had the following problems: >>>- probing of LUNs filed on attach and required a manual rescan. >>> undoubly fixable by someone with good CAM knowledge. >> >>I'm not parsing this. Are you referring to the need to do a rescan >>after plugging in a device? This is easy to solve. When a umass > > > Yes. > > >>target is attached, you either send an AC_FOUND_DEVICE async event to >>announce the target, or you request a bus rescan from within the driver. >>I think that the ciss driver has an example of this. > > > Don't know ciss, but I never had doubts that this is was a fixable > thing. > > >>>- CAM needs a max target value, but how many target do we really have? >>> Each USB has up to 127 devices (pratically 100 useable as we need >>> some hubs) >> >>The max target value is really only important for bus rescans. The SIM >>can just track what targets it currently knows about and reject CCBs >>for ones that don't exist (it somewhat does this now, though with only >>one target per SIM it's kinda silly). Setting the max target value to >>127 and rejecting targets that don't exist won't slow down a bus rescan >>but much at all. > > > But you can have more than 127 umass instances per bus. > > >>> Each device can have multiple functions, which means multiple umass >>> instances. >> >>I have a umass device that is a CF+SD card reader. It shows up in CAM >>as a single target with 2 LUNs. Is this the kind of thing that you are >>talking about? If so, then there is no reason not to continue to use >>the model of a single target with multiple LUNs. > > > No, that is multiple LUN with a single umass instance. > What I mean is a single USB device with multiple umass instances. > umass ist just a logical interface in the USB world, normaly ment > to allow e.g. an ulpt and umass on the same USB device, but also > possible to have multiple umass interfaces on the same USB device. > Since an umass interface needs at least two bulk endpoints a single > USB-channel can have up to 16 * 127 umass instances. > CAM right now is really geared for parallel SCSI with only 16 targets, but it should work fine with 2048 targets. A project for CAMng is to properly support FC fabrics properly as well as iSCSI; in both cases the max-target-per-bus concept has little meaning and would need fundamental changes. That's future work, though. For a physical device with multiple umass logical devices, each logical device would again just be a target. The actual target and bus numbers don't really matter in practical use because they aren't exposed to /dev. To make it truly transparent we would need to have an automounter like other OSes that mounts based on filesystem label, not based on device node name. But that's mostly a detail at this point. > >>> Previously we had a small hardcoded number, too big numbers slow >>> down bus rescans, too small restrict the number of possible devices. >>> We should have a dynamic way. >>>Don't remember if ther were others. >>> >> >>>From the technical standpoint - no matter what we do, there are >> >>>problems to solve. >>> >>> >>> >>>>Your analogy of a PCI bus is correct for the USB-SCSI adapters, where >>>>the adapter is doing a full conversion and bridge from one bus type to >>>>another. It's not true for a umass device where it's merely using the >>>>USB bus as a SCSI transport. >>> >>> >>>So what is an USB-IDE converter? >> >>I assumed that you were talking about devices that bridge from USB to >>IDE/SCSI and did not conform to the umass standard. I have a USB2-IDE >>converter in an external exclosure that speaks umass and is probably >>closer to what you are talking about here. But again, umass is really >>about using the USB bus to transport SCSI/ATA protocol, not about >>providing full access to a SCSI/IDE bus via a USB tunnel. That is a >>significant difference, IMHO. The USB controller is acting in a direct >>role as the SCSI/ATA initiator, vs. just tunnelling to a smart >>initiator. > > > OK - I got it now. > Nevertheless I could imagine a pseudo USB-SCSI converter that just > enhances umass transactions with a target-ID. > This won't invalidate what you wrote above, since you still don't have > full access on the SCSI-bus, but also requires a sim per (enhanced)umass. > I assume that this is really just a mythical device, right? If it were really just a very simple extension of the umass protocol then I'd probably elect to treat it as multiple targets with the same single SIM. > >>>OK - that won't help for a practical solution. >>>In the practical way it sounded easier to go the multiple sim way. >>>sim detach needs to be fixed either way. >> >>Yes. It somewhat works now as long as the system is completely idle. >>It breaks down horribly if I/O or error recovery is in progress and >>a periph driver is left with CCBs in flight and/or a dangling >>reference to a SIM. The only way to deal with this is to allow >>blocking while CAM drains itself. > > > Have to think about it. > > >>>Are there any other technical reasons for doing single sim? >>>You've mentioned rescource arbitration and error recovery. >>>Is there anything that can CAM do for us that it won't with multiple >>>sim? >>> >> >>It means that you'll be able to detach umass targets without doing the >>complicated dance of sleeping for CAM to drain itself. It also will >>mean that it's less fragile to edge cases that are hard to identify and >>deal with. Fixing CAM detach so that this works reliably is definitely >>something that must be done, but you can't avoid sleeping in order for >>it to work. > > > Mmm. > So was the motivation to change from a single SIM to SIM-per-device based solely on the problem of doing manual bus rescans when a device got inserted? If not, what were the other problems that got solved? Btw, I envision my changes resulting in a SIM per USB controller. So on a system with 3-4 controllers (as seem to be common these days), you'd have that many SIMs. umass targets would be paired with the SIM that was associated with the physical USB controller/bus of the target. Scott From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 01:34:45 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 5572E16A41F for ; Thu, 1 Sep 2005 01:34:45 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from smtp105.rog.mail.re2.yahoo.com (smtp105.rog.mail.re2.yahoo.com [206.190.36.83]) by mx1.FreeBSD.org (Postfix) with SMTP id 7140443D49 for ; Thu, 1 Sep 2005 01:34:44 +0000 (GMT) (envelope-from mikej@rogers.com) Received: (qmail 63344 invoked from network); 1 Sep 2005 01:34:43 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:Message-ID:In-Reply-To:References:Date:Subject:From:To:Cc:User-Agent:MIME-Version:Content-Type:Content-Transfer-Encoding; b=VMsAl4kM4Hc2xS/Vthetz6V3aAV0dvLgxj0Irz4dveUjRaikVqaiEp61kuCpAHBpli+wGSOuZb/J/HZpSG0LCkeerjZI68altUxW1ooUODYlHgDLZEacFOmRwkYDvT3Ay63UQ9IxqXW2/RRZ7Lv6W0NNaN+1j3IqAY1e2EeaNds= ; Received: from unknown (HELO 172.16.0.1) (mikej@70.31.50.81 with login) by smtp105.rog.mail.re2.yahoo.com with SMTP; 1 Sep 2005 01:34:43 -0000 Received: from 172.16.0.199 (SquirrelMail authenticated user mikej) by 172.16.0.1 with HTTP; Wed, 31 Aug 2005 21:34:41 -0400 (EDT) Message-ID: <2313.172.16.0.199.1125538481.squirrel@172.16.0.1> In-Reply-To: <4315465C.8090506@FreeBSD.org> References: <4740.172.16.0.199.1125444307.squirrel@172.16.0.1> <200508301616.50131.akbeech@gmail.com> <20050831053839.GA76471@zibbi.meraka.csir.co.za> <4315465C.8090506@FreeBSD.org> Date: Wed, 31 Aug 2005 21:34:41 -0400 (EDT) From: "Mike Jakubik" To: "Doug Barton" User-Agent: SquirrelMail/1.5.1 [CVS] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: John Hay , Beecher Rintoul , freebsd-current@freebsd.org Subject: Re: More 'make release' problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2005 01:34:45 -0000 On Wed, August 31, 2005 1:55 am, Doug Barton said: > John Hay wrote: > > >> The problem is that NO_INFO controls more than just the info docs >> nowadays, it also controls the installation of the info tools. > > Wouldn't a better solution be to granulate the knobs, and have > NO_INFO_TOOLS > and NO_INFO_DOCS, with NO_INFO implying both? Whatever the solution is, i hope it gets commited soon. What about the timezone copy problem? I have to manually copy the timezones to the chroot when make release is running, otherwise it fails. From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 02:09: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 A400E16A41F; Thu, 1 Sep 2005 02:09:17 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C42543D46; Thu, 1 Sep 2005 02:09:17 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id j8128uvW019560; Wed, 31 Aug 2005 19:09:00 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200509010209.j8128uvW019560@gw.catspoiler.org> Date: Wed, 31 Aug 2005 19:08:56 -0700 (PDT) From: Don Lewis To: imp@bsdimp.com In-Reply-To: <20050827.220303.130848154.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: bzeeb-lists@lists.zabbadoz.net, freebsd-current@FreeBSD.org, rwatson@FreeBSD.org, dandee@volny.cz Subject: Re: LOR route vr0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2005 02:09:18 -0000 On 27 Aug, M. Warner Losh wrote: > In message: <20050828025721.X43518@fledge.watson.org> > Robert Watson writes: > : > : On Sat, 27 Aug 2005, M. Warner Losh wrote: > : > : > : You need to add an entry to subr_witness.c creating a graph edge between > : > : the softc lock and the routing lock. An example of an entry in > : > : subr_witness.c: > : > : > : > : /* > : > : * TCP/IP > : > : */ > : > : { "tcp", &lock_class_mtx_sleep }, > : > : { "tcpinp", &lock_class_mtx_sleep }, > : > : { "so_snd", &lock_class_mtx_sleep }, > : > : { NULL, NULL }, > : > : > : > : Note that sets of ordered entries are terminated with a double-null. This > : > : declares that locks of type "tcp" preceed "tcpinp" which preceed > : > : "so_snd". > : > > : > So you have to have locks of type tcp BEFORE you take out tcpinp type > : > locks? > : > : Correct. 'tcp' reflects the global TCP state tables (pcbinfo) locks, and > : 'tcpinp' is for individual PCBs. If you acquire first a tcpinp and then > : tcp, the above settings should cause WITNESS to generate a lock order > : warning. Likewise, both tcp and tcpinp preceed so_snd, so if you acquire > : a protocol lock after a socket lock, it will get unhappy. WITNESS handles > : transitive relationships, so it gets connected up to the rest of the lock > : graph, explicit and implicit, so indirect violations of orders are fully > : handled. > > OK. I've been seeing similar LORs in ed, sn, iwi (ed is my locked > version of ed, not in tree GIANT locked ed). Just as a datapoint, I've got fxp interfaces on all my machines running -CURRENT and I'm not seeing the problem here. > I've made the following changes, and the LORs go away (except for > one, which was unrelated). I further don't get the first place where > they locks happen that caused the original LORs, so I'm mightly > confused. What is the other LOR that you are seeing? Does it go away if you unwire the MTX_NETWORK_LOCK order? If so, that LOR is where witness is breaking the loop in the lock ordering graph. As jhb mentioned, the output of "show witness" would be interesting in the case where the lock orders are not wired. > ==== //depot/user/imp/newcard/kern/subr_witness.c#62 - /dell/imp/p4/newcard/src/sys/kern/subr_witness.c ==== > @@ -273,6 +273,13 @@ > { "allprison", &lock_class_mtx_sleep }, > { NULL, NULL }, > /* > + * Network driver locking order > + */ > + { "rawinp", &lock_class_mtx_sleep }, > + { MTX_NETWORK_LOCK, &lock_class_mtx_sleep }, > + { "if_addr_mtx", &lock_class_mtx_sleep }, > + { NULL, NULL }, > + /* > * Sockets > */ > { "filedesc structure", &lock_class_mtx_sleep }, > @@ -309,6 +316,7 @@ > { "udp", &lock_class_mtx_sleep }, > { "udpinp", &lock_class_mtx_sleep }, > { "so_snd", &lock_class_mtx_sleep }, > + { MTX_NETWORK_LOCK, &lock_class_mtx_sleep }, > { NULL, NULL }, > /* > * TCP/IP > @@ -316,6 +324,7 @@ > { "tcp", &lock_class_mtx_sleep }, > { "tcpinp", &lock_class_mtx_sleep }, > { "so_snd", &lock_class_mtx_sleep }, > + { MTX_NETWORK_LOCK, &lock_class_mtx_sleep }, > { NULL, NULL }, > /* > * SLIP > > I'm not sure if I need to add the if_addr_mtx after each thing or > not. Nope. You also don't need to add MTX_NETWORK_LOCK after so_snd more than once. If you are finding that you need to wire the order of if_addr_mtx, that is a potential clue. The only lock I see taken after if_addr_mtx is "UMA zone". If you are seeing other locks under if_addr_mtx, maybe one of those is looping back to rtentry. I also see taskqueue, "if send queue", and various memory subsystem locks under "network driver". Both taskqueue and "if send queue" appear to be leaf locks. From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 02:41:21 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 0165D16A41F; Thu, 1 Sep 2005 02:41:21 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF4A443D46; Thu, 1 Sep 2005 02:41:20 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id CD01546B9F; Wed, 31 Aug 2005 22:41:19 -0400 (EDT) Date: Thu, 1 Sep 2005 03:41:19 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Don Lewis In-Reply-To: <200509010209.j8128uvW019560@gw.catspoiler.org> Message-ID: <20050901033730.X83712@fledge.watson.org> References: <200509010209.j8128uvW019560@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: bzeeb-lists@lists.zabbadoz.net, freebsd-current@FreeBSD.org, dandee@volny.cz, imp@bsdimp.com Subject: Re: LOR route vr0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2005 02:41:21 -0000 On Wed, 31 Aug 2005, Don Lewis wrote: > If you are finding that you need to wire the order of if_addr_mtx, that > is a potential clue. The only lock I see taken after if_addr_mtx is > "UMA zone". If you are seeing other locks under if_addr_mtx, maybe one > of those is looping back to rtentry. I also see taskqueue, "if send > queue", and various memory subsystem locks under "network driver". > Both taskqueue and "if send queue" appear to be leaf locks. In the link layer multicast address code, I'm fairly careful not to hold if_addr_mtx over calls into the ifnet code. Three suspect points are the call to ifp->if_resolvemulti(), which looks like it is OK for all current implementations, and the call to rt_newmaddrmsg() in if_addmulti(), which is made before the unlock call so that the 'ifma' reference remains valid, and a similar call to rt_newmaddrmsg() in if_delmulti(). These calls should acquire only mbuf allocator and general allocator locks, and the netisr handoff mutex for NETISR_ROUTE. However, perhaps there's a case here I'm not seeing. It might be worth commenting out those two calls under if_addr_mtx and seeing if the lock order warning goes away. Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 04:45: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 CC05716A41F for ; Thu, 1 Sep 2005 04:45:25 +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 6CB9143D45 for ; Thu, 1 Sep 2005 04:45:25 +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 j814hjsj016541; Wed, 31 Aug 2005 22:43:45 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 31 Aug 2005 22:44:12 -0600 (MDT) Message-Id: <20050831.224412.98347286.imp@bsdimp.com> To: ticso@cicely.de From: "M. Warner Losh" In-Reply-To: <20050831174631.GE37930@cicely12.cicely.de> References: <47d0403c05083020044f6ac0be@mail.gmail.com> <4315CEEC.80100@samsco.org> <20050831174631.GE37930@cicely12.cicely.de> 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]); Wed, 31 Aug 2005 22:43:48 -0600 (MDT) Cc: freebsd-current@freebsd.org Subject: Re: panic after removing usb flash drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2005 04:45:25 -0000 In message: <20050831174631.GE37930@cicely12.cicely.de> Bernd Walter writes: : Yes - umass creates a SIM, bus and targed, because that is what a user : really attaches/detaches. For what it is worth, in the PC Card and CardBus case, the drivers aren't allowed to 'fail' the detach. They are required to succeed, and are removed from the driver tree if they try to return a failure code. All their resources are removed and interrupts are removed. The hardware is gone, and the driver has no say so about going away. At least that's the model we currently have. Warner From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 04:51: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 E799316A41F for ; Thu, 1 Sep 2005 04:51:00 +0000 (GMT) (envelope-from akbeech@gmail.com) Received: from vfemail.net (miwi2dsl-a234.wi.tds.net [216.170.248.235]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0EDB443D4C for ; Thu, 1 Sep 2005 04:50:59 +0000 (GMT) (envelope-from akbeech@gmail.com) Received: (qmail 66888 invoked by uid 85); 1 Sep 2005 04:50:54 -0000 Received: from akbeech@gmail.com by mail.vfemail.net by uid 0 with qmail-scanner-1.16 (clamscan: 0.75.1. spamassassin: 2.63. Clear:. Processed in 1.134222 secs); 01 Sep 2005 04:50:54 -0000 Received: from unknown (HELO ?192.168.2.200?) (alaska@vfemail.net@209.124.141.64) by miwi2dsl-a234.wi.tds.net with SMTP; 1 Sep 2005 04:50:53 -0000 From: Beecher Rintoul Organization: NorthWind Communications To: "Mike Jakubik" Date: Wed, 31 Aug 2005 20:50:48 -0800 User-Agent: KMail/1.8.2 References: <4740.172.16.0.199.1125444307.squirrel@172.16.0.1> <4315465C.8090506@FreeBSD.org> <2313.172.16.0.199.1125538481.squirrel@172.16.0.1> In-Reply-To: <2313.172.16.0.199.1125538481.squirrel@172.16.0.1> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200508312050.50782.akbeech@gmail.com> Cc: Doug Barton , John Hay , freebsd-current@freebsd.org Subject: Re: More 'make release' problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2005 04:51:01 -0000 On Wednesday 31 August 2005 05:34 pm, Mike Jakubik wrote: > On Wed, August 31, 2005 1:55 am, Doug Barton said: > > John Hay wrote: > >> The problem is that NO_INFO controls more than just the info docs > >> nowadays, it also controls the installation of the info tools. > > > > Wouldn't a better solution be to granulate the knobs, and have > > NO_INFO_TOOLS > > and NO_INFO_DOCS, with NO_INFO implying both? > > Whatever the solution is, i hope it gets commited soon. What about the > timezone copy problem? I have to manually copy the timezones to the chroot > when make release is running, otherwise it fails. Looks like the tz problem is fixed. Now I have a new problem. After updating cvs and building today's -current it now fails here: if [ -d /usr/src/release/../../ports/distfiles/ ]; then cp -rp /usr/src/release/../../ports/distfiles /bak/release/usr/ports/distfiles; else mkdir -p /bak/release/usr/ports/distfiles; fi cd: can't cd to /bak/release/usr/ports/lang/perl5.8 *** Error code 2 It did a full checkout of the ports cvs, but didn't populate anything. Hopefully someone will shed some light on the problems. Has anyone been successful at building a release lately? Beech -- --------------------------------------------------------------------------------------- Beech Rintoul - System Administrator - akbeech@gmail.com /"\ ASCII Ribbon Campaign | NorthWind Communications \ / - NO HTML/RTF in e-mail | 201 East 9th Avenue Ste.310 X - NO Word docs in e-mail | Anchorage, AK 99501 / \ --------------------------------------------------------------------------------------- From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 05:00: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 71F6316A420 for ; Thu, 1 Sep 2005 05:00:28 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1114C43D45 for ; Thu, 1 Sep 2005 05:00:28 +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 j814vgS9016697; Wed, 31 Aug 2005 22:57:42 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 31 Aug 2005 22:58:08 -0600 (MDT) Message-Id: <20050831.225808.69990745.imp@bsdimp.com> To: ticso@cicely.de From: "M. Warner Losh" In-Reply-To: <20050831.224412.98347286.imp@bsdimp.com> References: <4315CEEC.80100@samsco.org> <20050831174631.GE37930@cicely12.cicely.de> <20050831.224412.98347286.imp@bsdimp.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Wed, 31 Aug 2005 22:57:42 -0600 (MDT) Cc: freebsd-current@freebsd.org Subject: Re: panic after removing usb flash drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2005 05:00:28 -0000 In message: <20050831.224412.98347286.imp@bsdimp.com> "M. Warner Losh" writes: : In message: <20050831174631.GE37930@cicely12.cicely.de> : Bernd Walter writes: : : Yes - umass creates a SIM, bus and targed, because that is what a user : : really attaches/detaches. : : For what it is worth, in the PC Card and CardBus case, the drivers : aren't allowed to 'fail' the detach. They are required to succeed, : and are removed from the driver tree if they try to return a failure : code. All their resources are removed and interrupts are removed. : The hardware is gone, and the driver has no say so about going away. : At least that's the model we currently have. Also, in detach, drivers are supposed to wait for all their references to go away before returning. If they have any threads running, it is their job to clean them up, etc. This means, however, that cam PC Card and CardBus drivers have issues detaching (since CAM has issues detaching SIMs). Hopefully your work with CAM will help this situation, and I look forward to it. Having a virtual driver that attaches to the physical driver, like we talked about in IRC, wouldn't violate those assumptions. Warner From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 06:44: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 259FC16A41F for ; Thu, 1 Sep 2005 06:44:56 +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 782BF43D45 for ; Thu, 1 Sep 2005 06:44:55 +0000 (GMT) (envelope-from sos@deepcore.dk) Received: from [194.192.25.136] (mac.deepcore.dk [194.192.25.136]) by spider.deepcore.dk (8.13.3/8.13.3) with ESMTP id j816eaQP065191; Thu, 1 Sep 2005 08:40:36 +0200 (CEST) (envelope-from sos@deepcore.dk) In-Reply-To: <48966896-18ED-4CB6-81E4-7C1113372272@lassitu.de> References: <7A0B19EC-2F90-495F-B242-7FB701C32908@lassitu.de> <20050828124321.43365136@Magellan.Leidinger.net> <3923443F-6926-4BB7-8681-40FC68A41B79@lassitu.de> <0046E5C3-22EE-4F5D-B2B0-DFF4F0157F6B@lassitu.de> <9105C2F5-0D77-4B43-AFFA-7558BBEDA26A@lassitu.de> <2E95AA3B-2CF7-4EFB-9EAC-45683D1F8D7D@DeepCore.dk> <95B83146-2D52-42D3-8C2E-113CD280743F@lassitu.de> <48966896-18ED-4CB6-81E4-7C1113372272@lassitu.de> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= Date: Thu, 1 Sep 2005 08:44:39 +0200 To: Stefan Bethke X-Mailer: Apple Mail (2.734) X-mail-scanned: by DeepCore Virus & Spam killer v1.12 Cc: freebsd-current@freebsd.org Subject: Re: Boot off CF card hangs at "Trying to mount root" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2005 06:44:56 -0000 On 31/08/2005, at 21:09, Stefan Bethke wrote: > Am 29.08.2005 um 23:20 schrieb Stefan Bethke: > >> Am 29.08.2005 um 22:25 schrieb S=F8ren Schmidt: >> >>> On 29/08/2005, at 21:13, Stefan Bethke wrote: >>> >>>> After the final "ad2: req=3D0xc17fc000 READ completed callback/=20 >>>> wakeup", nothing else happens. >>>> >>> Hmm, the timeout in there is worrying me, please try the below =20 >>> hack and se if that makes it get through. Might be that the =20 >>> device doesn't like 64K (ie size 0) transfers... >>> >> Hhm, doesn't look too different. I've fixed fstab, so this is a =20 >> complete verbose boot. >> > > Anyone got any further suggestions? Currently the router is laying =20= > on the table open with bits hanging out, and that does not improve =20 > it's WAF :-) No, I have to find/setup a system here that I can reproduce this on =20 to get further debugging done, that takes time which is in short supply. - S=F8ren From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 07:42: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 8956E16A41F; Thu, 1 Sep 2005 07:42:44 +0000 (GMT) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F1C743D45; Thu, 1 Sep 2005 07:42:14 +0000 (GMT) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 9A69F44; Thu, 1 Sep 2005 09:42:07 +0200 (SAST) Date: Thu, 1 Sep 2005 09:42:07 +0200 From: John Hay To: Beecher Rintoul Message-ID: <20050901074207.GA25355@zibbi.meraka.csir.co.za> References: <4740.172.16.0.199.1125444307.squirrel@172.16.0.1> <4315465C.8090506@FreeBSD.org> <2313.172.16.0.199.1125538481.squirrel@172.16.0.1> <200508312050.50782.akbeech@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200508312050.50782.akbeech@gmail.com> User-Agent: Mutt/1.4.1i Cc: Mike Jakubik , Doug Barton , freebsd-current@freebsd.org Subject: Re: More 'make release' problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2005 07:42:44 -0000 > > Looks like the tz problem is fixed. Now I have a new problem. After updating > cvs and building today's -current it now fails here: > > if [ -d /usr/src/release/../../ports/distfiles/ ]; then cp > -rp /usr/src/release/../../ports/distfiles /bak/release/usr/ports/distfiles; > else mkdir -p /bak/release/usr/ports/distfiles; fi > cd: can't cd to /bak/release/usr/ports/lang/perl5.8 > *** Error code 2 > > It did a full checkout of the ports cvs, but didn't populate anything. > > Hopefully someone will shed some light on the problems. Has anyone been > successful at building a release lately? My nightly build finished without a problem. I use this patch. Only the first part, removal of -DNO_INFO, is needed. The rest is a leftover from earlier stuff. It is only applied to my /usr/src tree and not to the chroot area. My nightly script define a few things that might make a difference: NOPORTS=YES WORLD_FLAGS=-DNO_WERROR KERNEL_FLAGS=-DNO_WERROR DOC_LANG=en_US.ISO8859-1 The NO_WERROR ones I can probably remove, but there was a stage where warnings broke the release so often that I added that. The DOC_LANG one I added recently because some of the other languages was broken and that was the easy way out of that. My script also do a prefetch of all the distfiles that will be needed for the doc ports. John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org Index: release/Makefile =================================================================== RCS file: /home/ncvs/src/release/Makefile,v retrieving revision 1.888 diff -u -r1.888 Makefile --- release/Makefile 11 Jul 2005 15:50:29 -0000 1.888 +++ release/Makefile 31 Aug 2005 10:57:15 -0000 @@ -354,7 +354,7 @@ .endif mkdir -p ${CHROOTDIR} @echo ">>> make release for ${TARGET} started on `LC_ALL=C TZ=GMT date`" - cd ${WORLDDIR} && ${NATIVEMAKE} -DNO_GAMES -DNO_HTML -DNO_INFO \ + cd ${WORLDDIR} && ${NATIVEMAKE} -DNO_GAMES -DNO_HTML \ -DNO_LIB32 -DNO_MAN -DNO_NLS -DNO_PROFILE installworld \ DESTDIR=${CHROOTDIR} cd ${WORLDDIR} && ${NATIVEMAKE} distribution DESTDIR=${CHROOTDIR} @@ -379,10 +379,6 @@ patch -d ${CHROOTDIR}/usr/${RELEASESRCMODULE} ${PATCH_FLAGS} < ${p} .endfor .endif -.if defined(LOCAL_SCRIPT) - cd ${CHROOTDIR} && env CHROOTDIR=${CHROOTDIR} BUILDNAME=${BUILDNAME} \ - RELEASETAG=${RELEASETAG} ${LOCAL_SCRIPT} -.endif rm -rf ${CHROOTDIR}/usr/ports .if !defined(NOPORTSATALL) cd ${CHROOTDIR}/usr && ${CVSPREFIX} cvs -R ${CVSARGS} -d ${CVSROOT} \ @@ -405,6 +401,10 @@ @cd ${.CURDIR} && ${MAKE} fetch-distfiles .endif .endif +.if defined(LOCAL_SCRIPT) && exists(${LOCAL_SCRIPT}) + cd ${CHROOTDIR} && env CHROOTDIR=${CHROOTDIR} BUILDNAME=${BUILDNAME} \ + RELEASETAG=${RELEASETAG} ${LOCAL_SCRIPT} +.endif .endif .if make(rerelease) .if !defined(RELEASENOUPDATE) From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 08:26: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 77C2316A41F for ; Thu, 1 Sep 2005 08:26:34 +0000 (GMT) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC90243D4C for ; Thu, 1 Sep 2005 08:26:33 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 12921 invoked from network); 1 Sep 2005 08:04:12 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 1 Sep 2005 08:04:12 -0000 Message-ID: <4316BB37.9070901@freebsd.org> Date: Thu, 01 Sep 2005 10:26:31 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: Scott Long References: <1125452228.740.3.camel@arbitor.homelinux.com> <47d0403c05083020044f6ac0be@mail.gmail.com> <4315CEEC.80100@samsco.org> <20050831174631.GE37930@cicely12.cicely.de> <4315F15D.4090209@samsco.org> <20050831221535.GB670@cicely12.cicely.de> <4316370E.4030809@samsco.org> <20050901000216.GD670@cicely12.cicely.de> <43164B88.8010903@samsco.org> In-Reply-To: <43164B88.8010903@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Kyle Brooks , ticso@cicely.de, Ben Kaduk Subject: Re: panic after removing usb flash drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2005 08:26:34 -0000 Scott Long wrote: > > CAM right now is really geared for parallel SCSI with only 16 targets, > but it should work fine with 2048 targets. A project for CAMng is to > properly support FC fabrics properly as well as iSCSI; in both cases > the max-target-per-bus concept has little meaning and would need > fundamental changes. That's future work, though. Please take SAS fabrics and SAS link bonding into account too when doing this. -- Andre From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 09:48: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 7E3F016A41F; Thu, 1 Sep 2005 09:48:50 +0000 (GMT) (envelope-from fli+freebsd-current@shapeshifter.se) Received: from mx1.h3q.net (manticore.shapeshifter.se [212.37.5.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF6C443D46; Thu, 1 Sep 2005 09:48:49 +0000 (GMT) (envelope-from fli+freebsd-current@shapeshifter.se) Received: from localhost (localhost [127.0.0.1]) by mx1.h3q.net (Postfix) with ESMTP id 429B11A743; Thu, 1 Sep 2005 11:48:47 +0200 (CEST) Received: from mx1.h3q.net ([127.0.0.1]) by localhost (manticore.shapeshifter.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37569-03; Thu, 1 Sep 2005 11:48:45 +0200 (CEST) Received: from [192.168.0.96] (h4n2fls31o270.telia.com [217.208.199.4]) by mx1.h3q.net (Postfix) with ESMTP id 5FF061A714; Thu, 1 Sep 2005 11:48:44 +0200 (CEST) Message-ID: <4316CE7B.2090303@shapeshifter.se> Date: Thu, 01 Sep 2005 11:48:43 +0200 From: Fredrik Lindberg User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050816) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Don Lewis References: <200509010209.j8128uvW019560@gw.catspoiler.org> In-Reply-To: <200509010209.j8128uvW019560@gw.catspoiler.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: at mail.hamnpolare.net Cc: bzeeb-lists@lists.zabbadoz.net, freebsd-current@FreeBSD.org, rwatson@FreeBSD.org, dandee@volny.cz, imp@bsdimp.com Subject: Re: LOR route vr0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2005 09:48:50 -0000 Don Lewis wrote: > On 27 Aug, M. Warner Losh wrote: > >>In message: <20050828025721.X43518@fledge.watson.org> >> Robert Watson writes: >>: >>: On Sat, 27 Aug 2005, M. Warner Losh wrote: >>: >>: > : You need to add an entry to subr_witness.c creating a graph edge between >>: > : the softc lock and the routing lock. An example of an entry in >>: > : subr_witness.c: >>: > : >>: > : /* >>: > : * TCP/IP >>: > : */ >>: > : { "tcp", &lock_class_mtx_sleep }, >>: > : { "tcpinp", &lock_class_mtx_sleep }, >>: > : { "so_snd", &lock_class_mtx_sleep }, >>: > : { NULL, NULL }, >>: > : >>: > : Note that sets of ordered entries are terminated with a double-null. This >>: > : declares that locks of type "tcp" preceed "tcpinp" which preceed >>: > : "so_snd". >>: > >>: > So you have to have locks of type tcp BEFORE you take out tcpinp type >>: > locks? >>: >>: Correct. 'tcp' reflects the global TCP state tables (pcbinfo) locks, and >>: 'tcpinp' is for individual PCBs. If you acquire first a tcpinp and then >>: tcp, the above settings should cause WITNESS to generate a lock order >>: warning. Likewise, both tcp and tcpinp preceed so_snd, so if you acquire >>: a protocol lock after a socket lock, it will get unhappy. WITNESS handles >>: transitive relationships, so it gets connected up to the rest of the lock >>: graph, explicit and implicit, so indirect violations of orders are fully >>: handled. >> >>OK. I've been seeing similar LORs in ed, sn, iwi (ed is my locked >>version of ed, not in tree GIANT locked ed). > > > Just as a datapoint, I've got fxp interfaces on all my machines running > -CURRENT and I'm not seeing the problem here. > I'm seeing both the rentry and the tcpinp LORs on my fxp interface on a machine running a few days old -current (Aug 25). lock order reversal 1st 0xc1e30d38 inp (tcpinp) @ /usr/src/sys/netinet/tcp_input.c:742 2nd 0xc1b74018 fxp0 (network driver) @/usr/src/sys/dev/fxp/if_fxp.c:1172 lock order reversal 1st 0xc1e06bb8 rtentry (rtentry) @ /usr/src/sys/net/route.c:1269 2nd 0xc1b74018 fxp0 (network driver) @/usr/src/sys/dev/fxp/if_fxp.c:1172 As for their backtraces they are almost identical to the once already posted. > >>I've made the following changes, and the LORs go away (except for >>one, which was unrelated). I further don't get the first place where >>they locks happen that caused the original LORs, so I'm mightly >>confused. > > > What is the other LOR that you are seeing? Does it go away if you > unwire the MTX_NETWORK_LOCK order? If so, that LOR is where witness is > breaking the loop in the lock ordering graph. > > As jhb mentioned, the output of "show witness" would be interesting in > the case where the lock orders are not wired. > > >>==== //depot/user/imp/newcard/kern/subr_witness.c#62 - /dell/imp/p4/newcard/src/sys/kern/subr_witness.c ==== >>@@ -273,6 +273,13 @@ >> { "allprison", &lock_class_mtx_sleep }, >> { NULL, NULL }, >> /* >>+ * Network driver locking order >>+ */ >>+ { "rawinp", &lock_class_mtx_sleep }, >>+ { MTX_NETWORK_LOCK, &lock_class_mtx_sleep }, >>+ { "if_addr_mtx", &lock_class_mtx_sleep }, >>+ { NULL, NULL }, >>+ /* >> * Sockets >> */ >> { "filedesc structure", &lock_class_mtx_sleep }, >>@@ -309,6 +316,7 @@ >> { "udp", &lock_class_mtx_sleep }, >> { "udpinp", &lock_class_mtx_sleep }, >> { "so_snd", &lock_class_mtx_sleep }, >>+ { MTX_NETWORK_LOCK, &lock_class_mtx_sleep }, >> { NULL, NULL }, >> /* >> * TCP/IP >>@@ -316,6 +324,7 @@ >> { "tcp", &lock_class_mtx_sleep }, >> { "tcpinp", &lock_class_mtx_sleep }, >> { "so_snd", &lock_class_mtx_sleep }, >>+ { MTX_NETWORK_LOCK, &lock_class_mtx_sleep }, >> { NULL, NULL }, >> /* >> * SLIP >> >>I'm not sure if I need to add the if_addr_mtx after each thing or >>not. > > > Nope. You also don't need to add MTX_NETWORK_LOCK after so_snd more > than once. > > If you are finding that you need to wire the order of if_addr_mtx, that > is a potential clue. The only lock I see taken after if_addr_mtx is > "UMA zone". If you are seeing other locks under if_addr_mtx, maybe one > of those is looping back to rtentry. I also see taskqueue, "if send > queue", and various memory subsystem locks under "network driver". Both > taskqueue and "if send queue" appear to be leaf locks. > > > _______________________________________________ > 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 Thu Sep 1 11:10: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 E0B5016A41F for ; Thu, 1 Sep 2005 11:10:16 +0000 (GMT) (envelope-from gregorynou@altern.org) Received: from esemetz.metz.supelec.fr (esemetz.metz.supelec.fr [193.48.224.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F64443D45 for ; Thu, 1 Sep 2005 11:10:13 +0000 (GMT) (envelope-from gregorynou@altern.org) Received: from smtp.metz.supelec.fr (smtp.metz.supelec.fr [193.48.224.205]) by esemetz.metz.supelec.fr (8.11.6/8.9.3) with ESMTP id j81BACI29242 for ; Thu, 1 Sep 2005 13:10:12 +0200 Received: from [193.48.225.2] (nou.rez-metz.supelec.fr [193.48.225.2]) by smtp.metz.supelec.fr (8.11.6/8.11.6) with ESMTP id j81B6EK31122 for ; Thu, 1 Sep 2005 13:06:14 +0200 Message-ID: <4316E1A0.8070307@altern.org> Date: Thu, 01 Sep 2005 13:10:24 +0200 From: Gregory Nou User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050831) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Problem with deleting files X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2005 11:10:17 -0000 Hi, I'm currently experiencing a weird problem : some of my folders are completely empty (ls -a doesn't even mention . or ..) But, I cannot remove them, and a ls is very very slow (but just in those folders, and it is quite rare, but now I cannot update firefox, nor openoffice, because make clean will fail). uname -a gives : FreeBSD *.fr 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Fri Aug 26 10:12:03 CEST 2005 root@*.fr:/usr/obj/usr/src/sys/MYKERNEL i386 my questions are : Is it Freebsd related, or may it be a problem with my hard disk ? Is there a way to delete, or just unlink a folder, even if it doesn't appear to be empty ? Currently, I'm trying to make world again, to see if the problem desappear, but I'm experiencing a problem with groff. By the way, is it possible to make world without groff ? Do I need it to make my system run well ? Thanks -- Gregory From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 19:13:39 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 DFA9816A41F for ; Wed, 31 Aug 2005 19:13:39 +0000 (GMT) (envelope-from lists@masterplan.org) Received: from corona.resourcechain.com (207-34-127-10.ip.cal.radiant.net [207.34.127.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5990243D45 for ; Wed, 31 Aug 2005 19:13:39 +0000 (GMT) (envelope-from lists@masterplan.org) Received: from f1.masterplan.org (S01060800200525a9.cg.shawcable.net [68.144.69.51]) by corona.resourcechain.com (8.13.3/8.13.3) with ESMTP id j7VJDUbe091108 for ; Wed, 31 Aug 2005 13:13:31 -0600 (MDT) (envelope-from lists@masterplan.org) Received: from f1.masterplan.org (localhost [127.0.0.1]) by f1.masterplan.org (8.13.3/8.13.3) with ESMTP id j7VJDNBv022461 for ; Wed, 31 Aug 2005 13:13:23 -0600 (MDT) (envelope-from lists@masterplan.org) Received: from localhost (lists@localhost) by f1.masterplan.org (8.13.3/8.13.3/Submit) with ESMTP id j7VJDMOk022458 for ; Wed, 31 Aug 2005 13:13:23 -0600 (MDT) (envelope-from lists@masterplan.org) X-Authentication-Warning: f1.masterplan.org: lists owned process doing -bs Date: Wed, 31 Aug 2005 13:13:22 -0600 (MDT) From: Jason George X-X-Sender: lists@f1 To: freebsd-current@freebsd.org Message-ID: <20050831130543.C22426@f1> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, score=0.2 required=5.0 tests=FORGED_RCVD_HELO, RCVD_IN_SORBS_DUL autolearn=no version=3.0.3 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on corona.resourcechain.com X-Mailman-Approved-At: Thu, 01 Sep 2005 11:35:28 +0000 Subject: 6.0-BETA3 and Asterisk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 19:13:40 -0000 I have been messing around with 6.0-BETA3, the ZapTel driver and Asterisk, all running on one of my scratch machines. I have been running 6.0-BETA? on this machine for a few weeks now. No issues there. The zaptel driver appears to load fine. Starting up Asterisk (built from the port) causes the machine to panic. I've attached the full dmesg. If anyone wants me to probe some specifics within the debugger, please let me know. --Jason OK boot GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb 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-BETA3 #2: Tue Aug 30 13:23:07 MDT 2005 jbg@ingenuity.resourcechain.com:/v00/opt/FreeBSD/FreeBSD-6/src/sys/i386/compile/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Pentium II/Pentium II Xeon/Celeron (397.95-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping = 2 Features=0x183f9ff real memory = 134217728 (128 MB) avail memory = 121765888 (116 MB) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface cpu0 on motherboard pcib0: pcibus 0 on motherboard pir0: on motherboard pci0: on pcib0 agp0: mem 0x44000000-0x47ffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) fxp0: port 0x2000-0x201f mem 0x40200000-0x40200fff,0x40100000-0x401fffff 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:c7:c3:64:df pci0: at device 14.0 (no driver attached) isab0: at device 20.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x2040-0x204f at device 20.1 on pci0 ata0: on atapci0 ata1: on atapci0 uhci0: port 0x2020-0x203f irq 11 at device 20.2 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 piix0: port 0xfc00-0xfc0f at device 20.3 on pci0 Timecounter "PIIX" frequency 3579545 Hz quality 0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff,0xe0000-0xe7fff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A, console sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (memory) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) Timecounter "TSC" frequency 397949172 Hz quality 800 Timecounters tick every 1.000 msec ad0: 152627MB at ata0-master UDMA33 Trying to mount root from ufs:/dev/ad0s1a WARNING: / was not properly dismounted /: mount pending error: blocks 72 files 25 Loading configuration files. kenv: unable to get dumpdev kernel dumps on /dev/ad0s1b Entropy harvesting: interrupts ethernet point_to_point kickstart. swapon: adding /dev/ad0s1b as swap device Starting file system checks: /dev/ad0s1a: INCORRECT BLOCK COUNT I=1177725 (4 should be 0) (CORRECTED) /dev/ad0s1a: INCORRECT BLOCK COUNT I=1177727 (4 should be 0) (CORRECTED) /dev/ad0s1a: UNREF FILE I=1177721 OWNER=root MODE=100644 /dev/ad0s1a: SIZE=0 MTIME=Aug 31 06:58 2005 (CLEARED) /dev/ad0s1a: UNREF FILE I=1177722 OWNER=root MODE=100644 /dev/ad0s1a: SIZE=0 MTIME=Aug 31 12:58 2005 (CLEARED) /dev/ad0s1a: UNREF FILE I=1177723 OWNER=root MODE=140755 /dev/ad0s1a: SIZE=0 MTIME=Aug 31 12:58 2005 (CLEARED) /dev/ad0s1a: UNREF FILE I=1177724 OWNER=root MODE=140755 /dev/ad0s1a: SIZE=0 MTIME=Aug 31 12:58 2005 (CLEARED) /dev/ad0s1a: UNREF FILE I=1177725 OWNER=root MODE=100644 /dev/ad0s1a: SIZE=0 MTIME=Aug 31 12:58 2005 (CLEARED) /dev/ad0s1a: UNREF FILE I=1177726 OWNER=root MODE=140755 /dev/ad0s1a: SIZE=0 MTIME=Aug 31 12:58 2005 (CLEARED) /dev/ad0s1a: UNREF FILE I=1177727 OWNER=root MODE=100644 /dev/ad0s1a: SIZE=0 MTIME=Aug 31 12:58 2005 (CLEARED) /dev/ad0s1a: FREE BLK COUNT(S) WRONG IN SUPERBLK (SALVAGED) /dev/ad0s1a: SUMMARY INFORMATION BAD (SALVAGED) /dev/ad0s1a: BLK(S) MISSING IN BIT MAPS (SALVAGED) /dev/ad0s1a: 21720 files, 471895 used, 4605184 free (5576 frags, 574951 blocks, 0.1% fragmentation) /dev/ad0s1d: DEFER FOR BACKGROUND CHECKING WARNING: /v00 was not properly dismounted Setting hostname: ingenuity.resourcechain.com. fxp0: link state changed to UP fxp0: flags=8843 mtu 1500 options=8 inet 192.168.4.3 netmask 0xffffff00 broadcast 192.168.4.255 inet6 fe80::208:c7ff:fec3:64df%fxp0 prefixlen 64 tentative scopeid 0x1 ether 00:08:c7:c3:64:df media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 add net default: gateway 192.168.4.8 Additional routing options:. Starting devd. Mounting NFS file systems:. Creating and/or trimming log files:. Starting syslogd. Checking for core dump on /dev/ad0s1b... savecore: unable to open bounds file, using 0 savecore: no dumps found Starting rpcbind. NFS access cache time=2 ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout Starting mountd. Starting nfsd. Starting statd. Starting lockd. Starting usbd. Starting local daemons:. Updating motd. Configuring syscons: blanktime. Starting sshd. Starting sendmail. Initial i386 initialization:. Additional ABI support:. Starting cron. Local package initialization:Starting asterisk. Starting rsyncd. Zapata Telephony Interface Registered on major 196 ZapTel device: vendor=e159 device=1 subvendor=8086 wcfxo0: port 0x2400-0x24ff mem 0x42000000-0x42000fff irq 11 at device 14.0 on pci0 ZapTel Attach for wcfxo0: deviceID : 0xe159 wcfxo0: [GIANT-LOCKED] lock order reverswcfxo: DAA mode is 'FCC' Found a Wildcard FXO: Generic Clone ZapTel device loaded. al 1st 0xc12df4b4 sleep mtxpool (sleep mtxpool) @ kern/kern_descrip.c:2275 2nd 0xc15c582c filedesc structure (filedesc structure) @ kern/kern_descrip.c:2276 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c09331f8,c0933ae0,c08bdba4) at kdb_backtrace+0x29 witness_checkorder(c15c582c,9,c08562a4,8e4) at witness_checkorder+0x564 _mtx_lock_flags(c15c582c,0,c085629b,8e4) at _mtx_lock_flags+0x5b dupfdopen(c15c3780,c15c5800,b,c,3) at dupfdopen+0x310 kern_open(c15c3780,28403e6a,0,3,0) at kern_open+0x134 open(c15c3780,ccaaed04,3,1,246) at open+0x1a syscall(3b,3b,3b,80d7000,0) at syscall+0x22f Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (5, FreeBSD ELF32, open), eip = 0x282c3797, esp = 0xbfbfe7bc, ebp = 0xbfbfe7e8 --- Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x10 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0616467 stack pointer = 0x28:0xccaa8b90 frame pointer = 0x28:0xccaa8bf4 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 = 458 (asterisk) [thread pid 458 tid 100087 ] Stopped at closef+0x23: cmpl $0,0x10(%edi) db> trace Tracing pid 458 tid 100087 td 0xc15c3480 closef(c1514510,c15c3480) at closef+0x23 fdfree(c15c3480,c15c4d94,0,c085ccf7,6b3) at fdfree+0x473 exit1(c15c3480,100,ccaa8d30,c07f15fb,c15c3480) at exit1+0x3f6 exit1(c15c3480,ccaa8d04,1,0,296) at exit1 syscall(3b,3b,3b,14,80bdf20) at syscall+0x22f Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x282c1433, esp = 0xbfbfeacc, ebp = 0xbfbfeae8 --- db> From owner-freebsd-current@FreeBSD.ORG Wed Aug 31 23:20: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 4E8F116A41F for ; Wed, 31 Aug 2005 23:20:25 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: from mail24.sea5.speakeasy.net (mail24.sea5.speakeasy.net [69.17.117.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 228F543D48 for ; Wed, 31 Aug 2005 23:20:24 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: (qmail 6306 invoked from network); 31 Aug 2005 23:20:22 -0000 Received: from aldan.algebra.com (HELO blue.virtual-estates.net) ([216.254.65.224]) (envelope-sender ) by mail24.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 31 Aug 2005 23:20:21 -0000 Received: from corbulon.video-collage.com (static-151-204-231-237.bos.east.verizon.net [151.204.231.237]) by blue.virtual-estates.net (8.13.3/8.13.3) with ESMTP id j7VNKJZF016243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 31 Aug 2005 19:20:20 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from mteterin.us.murex.com (195-11.customer.cloud9.net [168.100.195.11]) by corbulon.video-collage.com (8.13.4/8.13.1) with ESMTP id j7VNK9rk019534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Aug 2005 19:20:13 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from mteterin.us.murex.com (mteterin@localhost [127.0.0.1]) by mteterin.us.murex.com (8.13.3/8.13.3) with ESMTP id j7VNK3mV035600; Wed, 31 Aug 2005 19:20:03 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from localhost (localhost [[UNIX: localhost]]) by mteterin.us.murex.com (8.13.3/8.13.3/Submit) id j7VNK3Xg035599; Wed, 31 Aug 2005 19:20:03 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) X-Authentication-Warning: mteterin.us.murex.com: mteterin set sender to mi+mx@aldan.algebra.com using -f From: Mikhail Teterin Organization: Virtual Estates, Inc. To: "M. Warner Losh" Date: Wed, 31 Aug 2005 19:20:02 -0400 User-Agent: KMail/1.8.2 References: <200508281326.j7SDQGfc073329@blue.virtual-estates.net> <200508301223.20626.mi+mx@aldan.algebra.com> <20050831.171259.56563279.imp@bsdimp.com> In-Reply-To: <20050831.171259.56563279.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200508311920.02927.mi+mx@aldan.algebra.com> X-Virus-Scanned: ClamAV devel-20050525/1049/Wed Aug 31 03:19:01 2005 on corbulon.video-collage.com X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.43 X-Mailman-Approved-At: Thu, 01 Sep 2005 11:35:28 +0000 Cc: re@freebsd.org, current@freebsd.org Subject: Re: installing 6.0-BETA3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2005 23:20:25 -0000 > I have a number of pending MFCs for PC Cards to make them work a lot > better than they do now.  Maybe they will solve your problems. Before 6.0-RELEASE? Great! -mi From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 11:42: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 9E55E16A41F for ; Thu, 1 Sep 2005 11:42:34 +0000 (GMT) (envelope-from bsam@bsam.ru) Received: from bsam.ru (gw.ipt.ru [80.253.10.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFAE243D5C for ; Thu, 1 Sep 2005 11:42:30 +0000 (GMT) (envelope-from bsam@bsam.ru) Received: from bsam by bsam.ru with local (Exim 4.30; FreeBSD) id 1EAnUT-000229-9f; Thu, 01 Sep 2005 15:44:21 +0400 To: Jason George References: <20050831130543.C22426@f1> From: Boris Samorodov Date: Thu, 01 Sep 2005 15:44:21 +0400 In-Reply-To: <20050831130543.C22426@f1> (Jason George's message of "Wed, 31 Aug 2005 13:13:22 -0600 (MDT)") Message-ID: <31776986@srv.sem.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: "Boris B. Samorodov" Cc: freebsd-current@freebsd.org Subject: Re: 6.0-BETA3 and Asterisk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2005 11:42:34 -0000 On Wed, 31 Aug 2005 13:13:22 -0600 (MDT) Jason George wrote: > I have been messing around with 6.0-BETA3, the ZapTel driver and > Asterisk, all running on one of my scratch machines. > I have been running 6.0-BETA? on this machine for a few weeks now. No > issues there. The zaptel driver appears to load fine. Starting > up Asterisk (built from the port) causes the machine to panic. > I've attached the full dmesg. If anyone wants me to probe some specifics > within the debugger, please let me know. AFAIK just before BETA3 system libraries were bumpted. One should rebuild ports after upgrading the system from earlier one. Is it your case? WBR -- bsam From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 13:07: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 6F84A16A420 for ; Thu, 1 Sep 2005 13:07:43 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from leto.uk.clara.net (leto.uk.clara.net [80.168.69.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0827E43D48 for ; Thu, 1 Sep 2005 13:07:42 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from bloodhound.noc.clara.net ([195.8.70.207]) by leto.uk.clara.net with esmtp (Exim 4.43) id 1EAomQ-0001mG-Tx; Thu, 01 Sep 2005 14:06:58 +0100 Received: from personal by bloodhound.noc.clara.net with local (Exim 4.50 (FreeBSD)) id 1EAoml-000EIH-Ay; Thu, 01 Sep 2005 14:07:19 +0100 Date: Thu, 1 Sep 2005 14:07:19 +0100 From: Brian Candler To: Boris Samorodov Message-ID: <20050901130719.GB54918@uk.tiscali.com> References: <20050831130543.C22426@f1> <31776986@srv.sem.ipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <31776986@srv.sem.ipt.ru> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org, Jason George Subject: Re: 6.0-BETA3 and Asterisk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2005 13:07:43 -0000 On Thu, Sep 01, 2005 at 03:44:21PM +0400, Boris Samorodov wrote: > On Wed, 31 Aug 2005 13:13:22 -0600 (MDT) Jason George wrote: > > > I have been messing around with 6.0-BETA3, the ZapTel driver and > > Asterisk, all running on one of my scratch machines. > > > I have been running 6.0-BETA? on this machine for a few weeks now. No > > issues there. The zaptel driver appears to load fine. Starting > > up Asterisk (built from the port) causes the machine to panic. > > > I've attached the full dmesg. If anyone wants me to probe some specifics > > within the debugger, please let me know. > > AFAIK just before BETA3 system libraries were bumpted. One should > rebuild ports after upgrading the system from earlier one. Is it your > case? Can mismatched library versions really cause kernel panics?? From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 13:53: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 9C89116A41F for ; Thu, 1 Sep 2005 13:53:11 +0000 (GMT) (envelope-from haro@h4.dion.ne.jp) Received: from smtp1.dcns.ne.jp (smtp1.dcns.ne.jp [203.178.100.134]) by mx1.FreeBSD.org (Postfix) with SMTP id 14B8F43D45 for ; Thu, 1 Sep 2005 13:53:08 +0000 (GMT) (envelope-from haro@h4.dion.ne.jp) Received: (qmail 4258 invoked by uid 503); 1 Sep 2005 22:53:07 +0900 Received: from unknown (HELO localhost) (211.10.184.118) by smtp1.dcns.ne.jp with SMTP; 1 Sep 2005 22:53:07 +0900 Date: Thu, 01 Sep 2005 22:51:49 +0900 (JST) Message-Id: <20050901.225149.41626079.haro@h4.dion.ne.jp> To: freebsd-current@FreeBSD.org From: Munehiro Matsuda X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: LOR with iwi and UMA on 7-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, 01 Sep 2005 13:53:11 -0000 Hi all, FYI, I'm getting some LOR with iwi and a LOR with UMA. This is current from a day or two old. FreeBSD legacy.xxx 7.0-CURRENT FreeBSD 7.0-CURRENT #52: Tue Aug 30 22:28:21 JST 2005 haro@legacy.xxx:/home/haro/tmp/sys-7/i386/compile/LEGACY i386 =-------------------------------------------------------------------------- lock order reversal 1st 0xc0758820 Giant (Giant) @ kern/kern_conf.c:310 2nd 0xc1f36b68 iwi0 (network driver) @ /home/haro/tmp/sys-7/modules/iwi/../../dev/iwi/if_iwi.c:1587 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c0769c48,c0768640,c072c8c4) at kdb_backtrace+0x29 witness_checkorder(c1f36b68,9,c08e62d1,633) at witness_checkorder+0x52c _mtx_lock_flags(c1f36b68,0,c08e62d1,633,c075fc80) at _mtx_lock_flags+0x5b iwi_start(c1f43400) at iwi_start+0x35 if_start(c1f43400) at if_start+0x7b ether_output_frame(c1f43400,c1f52100,c1f67000,ffffffff,0) at ether_output_frame+0x1dc ether_output(c1f43400,c1f52100,e5b5bbf0,0,c1f52100) at ether_output+0x3e4 bpfwrite(c22d4900,c20c2a80,0,c0758820,0) at bpfwrite+0xb0 giant_write(c22d4900,c20c2a80,0,c22d4900,c0735b20) at giant_write+0x2d devfs_write_f(c21d0900,c20c2a80,c22c5e00,0,c1f4a000) at devfs_write_f+0x7b dofilewrite(c1f4a000,7,c21d0900,c20c2a80,ffffffff) at dofilewrite+0x77 kern_writev(c1f4a000,7,c20c2a80,c20c2a80,0) at kern_writev+0x3b writev(c1f4a000,e5b5bd04,3,2,282) at writev+0x30 syscall(3b,3b,3b,bfbfee00,bfbfec9c) at syscall+0x22f Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (121, FreeBSD ELF32, writev), eip = 0x28129447, esp = 0xbfbfec7c, ebp = 0xbfbfedc8 --- lock order reversal 1st 0xc07a7060 ifnet (ifnet) @ net/if.c:1159 2nd 0xc1f36b68 iwi0 (network driver) @ /home/haro/tmp/sys-7/modules/iwi/../../dev/iwi/if_iwi.c:1643 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c07689b0,c0768640,c072c8c4) at kdb_backtrace+0x29 witness_checkorder(c1f36b68,9,c08e62d1,66b) at witness_checkorder+0x52c _mtx_lock_flags(c1f36b68,0,c08e62d1,66b,c1f36004) at _mtx_lock_flags+0x5b iwi_watchdog(c1f43400) at iwi_watchdog+0x2a if_slowtimo(0) at if_slowtimo+0x4a softclock(0) at softclock+0x1e7 ithread_loop(c1e54d00,dda84d38,c1e54d00,c051e450,0) at ithread_loop+0x11c fork_exit(c051e450,c1e54d00,dda84d38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xdda84d6c, ebp = 0 --- lock order reversal 1st 0xc22c2bb8 rtentry (rtentry) @ net/route.c:1269 2nd 0xc1f36b68 iwi0 (network driver) @ /home/haro/tmp/sys-7/modules/iwi/../../dev/iwi/if_iwi.c:1587 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c07699f0,c0768640,c072c8c4) at kdb_backtrace+0x29 witness_checkorder(c1f36b68,9,c08e62d1,633) at witness_checkorder+0x52c _mtx_lock_flags(c1f36b68,0,c08e62d1,633,c075fc80) at _mtx_lock_flags+0x5b iwi_start(c1f43400) at iwi_start+0x35 if_start(c1f43400) at if_start+0x7b ether_output_frame(c1f43400,c2167500,c0527e80,ffffffff,0) at ether_output_frame+0x1dc ether_output(c1f43400,c2167500,e77cca38,0,2) at ether_output+0x3e4 arprequest(c1f43400,c22d5cc8,e77ccb08,c1ede2ac) at arprequest+0xd8 arpresolve(c1f43400,c22c2b58,c2167400,e77ccb04,e77ccaa8) at arpresolve+0x30b ether_output(c1f43400,c2167400,e77ccb04,c22c2b58,c22d5c00) at ether_output+0x6b ip_output(c2167400,0,e77ccb00,0,0) at ip_output+0x78c udp_output(c2291924,c2167400,0,0,c22d0000) at udp_output+0x4a7 udp_send(c221642c,0,c2167400,0,0) at udp_send+0x1a sosend(c221642c,0,e77ccc3c,c2167400,0) at sosend+0x5e3 kern_sendit(c22d0000,4,e77cccbc,0,0) at kern_sendit+0x104 sendit(c22d0000,4,e77cccbc,0,807b020) at sendit+0x163 sendto(c22d0000,e77ccd04,6,1,216) at sendto+0x4d syscall(3b,3b,3b,0,2814fb04) at syscall+0x22f Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (133, FreeBSD ELF32, sendto), eip = 0x2812a85f, esp = 0xbfbfd82c, ebp = 0xbfbfd858 --- lock order reversal 1st 0xc230a1f8 inp (tcpinp) @ netinet/tcp_usrreq.c:368 2nd 0xc1f36b68 iwi0 (network driver) @ /home/haro/tmp/sys-7/modules/iwi/../../dev/iwi/if_iwi.c:1587 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c0769888,c0768640,c072c8c4) at kdb_backtrace+0x29 witness_checkorder(c1f36b68,9,c08e62d1,633) at witness_checkorder+0x52c _mtx_lock_flags(c1f36b68,0,c08e62d1,633,c075fc80) at _mtx_lock_flags+0x5b iwi_start(c1f43400) at iwi_start+0x35 if_start(c1f43400) at if_start+0x7b ether_output_frame(c1f43400,c216ab00,0,0,0) at ether_output_frame+0x1dc ether_output(c1f43400,c216ab00,c22d17b0,c22c2bdc,c22d5c00) at ether_output+0x3e4 ip_output(c216ab00,0,e7833b80,0,0) at ip_output+0x78c tcp_output(c230d1cc,c2601590,25,c237f000,e7833c98) at tcp_output+0xfb2 tcp_usr_connect(c2601590,c1fb4960,c237f000) at tcp_usr_connect+0xe3 soconnect(c2601590,c1fb4960,c237f000,0,c248bdc8) at soconnect+0x4e kern_connect(c237f000,3,c1fb4960,c1fb4960,0) at kern_connect+0x74 connect(c237f000,e7833d04,3,7,206) at connect+0x2f syscall(3b,282c003b,bfbf003b,3,806e349) at syscall+0x22f Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (98, FreeBSD ELF32, connect), eip = 0x2829e97f, esp = 0xbfbfbb5c, ebp = 0xbfbfbbb8 --- lock order reversal 1st 0xc07a8a6c tcp (tcp) @ netinet/tcp_input.c:615 2nd 0xc1f36b68 iwi0 (network driver) @ /home/haro/tmp/sys-7/modules/iwi/../../dev/iwi/if_iwi.c:1587 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c07698b0,c0768640,c072c8c4) at kdb_backtrace+0x29 witness_checkorder(c1f36b68,9,c08e62d1,633) at witness_checkorder+0x52c _mtx_lock_flags(c1f36b68,0,c08e62d1,633,c075fc80) at _mtx_lock_flags+0x5b iwi_start(c1f43400) at iwi_start+0x35 if_start(c1f43400) at if_start+0x7b ether_output_frame(c1f43400,c1f57a00,0,0,0) at ether_output_frame+0x1dc ether_output(c1f43400,c1f57a00,c22d17b0,c22c2bdc,c22d5c00) at ether_output+0x3e4 ip_output(c1f57a00,0,dda81b28,0,0,0) at ip_output+0x78c tcp_respond(0,c1f8e840,c1f8e854,c1f57a00,0,80bb1033,4) at tcp_respond+0x3e1 tcp_input(c1f57a00,14,12c,c1f57a00,0) at tcp_input+0x2e32 ip_input(c1f57a00) at ip_input+0x5a1 netisr_processqueue(c07a7b78) at netisr_processqueue+0x6e swi_net(0) at swi_net+0xbe ithread_loop(c1e54d80,dda81d38,c1e54d80,c051e450,0) at ithread_loop+0x11c fork_exit(c051e450,c1e54d80,dda81d38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xdda81d6c, ebp = 0 --- lock order reversal 1st 0xc07b4580 UMA lock (UMA lock) @ vm/uma_core.c:1494 2nd 0xc1060144 system map (system map) @ vm/vm_map.c:2317 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c07695e0,c0769720,c072c8c4) at kdb_backtrace+0x29 witness_checkorder(c1060144,9,c070169d,90d) at witness_checkorder+0x52c _mtx_lock_flags(c1060144,0,c0701694,90d) at _mtx_lock_flags+0x5b _vm_map_lock(c10600c0,c0701694,90d) at _vm_map_lock+0x26 vm_map_remove(c10600c0,c41a8000,c41a9000,dda99c0c,c0650959) at vm_map_remove+0x1f kmem_free(c10600c0,c41a8000,1000,dda99c3c,c0650306) at kmem_free+0x25 page_free(c41a8000,1000,2) at page_free+0x29 zone_drain(c103f1e0) at zone_drain+0x26a zone_foreach(c065009c,dda99cec,c066228b,dda99c74,246) at zone_foreach+0x37 uma_reclaim(dda99c74,246,0,dda99c80,c0529039) at uma_reclaim+0x12 vm_pageout_scan(0,c07b49e0,0,c0702bb5,604) at vm_pageout_scan+0x103 vm_pageout(0,dda99d38,0,c06630e0,0) at vm_pageout+0x2c3 fork_exit(c06630e0,0,dda99d38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xdda99d6c, ebp = 0 --- =-------------------------------------------------------------------------- Thanks, Haro =------------------------------------------------------------------------------ _ _ Munehiro (haro) Matsuda -|- /_\ |_|_| Internet Solution Dept., KGT Inc. /|\ |_| |_|_| 2-8-8 Shinjuku Shinjuku-ku Tokyo 160-0022, Japan Tel: +81-3-3225-0767 Fax: +81-3-3225-0740 From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 14:35:13 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 A23F216A41F for ; Thu, 1 Sep 2005 14:35:13 +0000 (GMT) (envelope-from bsam@bsam.ru) Received: from bsam.ru (gw.ipt.ru [80.253.10.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB98A43D4C for ; Thu, 1 Sep 2005 14:35:12 +0000 (GMT) (envelope-from bsam@bsam.ru) Received: from bsam by bsam.ru with local (Exim 4.30; FreeBSD) id 1EAqBV-00029m-5D; Thu, 01 Sep 2005 18:36:57 +0400 To: Brian Candler References: <20050831130543.C22426@f1> <31776986@srv.sem.ipt.ru> <20050901130719.GB54918@uk.tiscali.com> From: Boris Samorodov Date: Thu, 01 Sep 2005 18:36:57 +0400 In-Reply-To: <20050901130719.GB54918@uk.tiscali.com> (Brian Candler's message of "Thu, 1 Sep 2005 14:07:19 +0100") Message-ID: <74646630@srv.sem.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: "Boris B. Samorodov" Cc: freebsd-current@freebsd.org, Jason George Subject: Re: 6.0-BETA3 and Asterisk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2005 14:35:13 -0000 On Thu, 1 Sep 2005 14:07:19 +0100 Brian Candler wrote: > On Thu, Sep 01, 2005 at 03:44:21PM +0400, Boris Samorodov wrote: > > On Wed, 31 Aug 2005 13:13:22 -0600 (MDT) Jason George wrote: > > > > > I have been messing around with 6.0-BETA3, the ZapTel driver and > > > Asterisk, all running on one of my scratch machines. > > > > > I have been running 6.0-BETA? on this machine for a few weeks now. No > > > issues there. The zaptel driver appears to load fine. Starting > > > up Asterisk (built from the port) causes the machine to panic. > > > > > I've attached the full dmesg. If anyone wants me to probe some specifics > > > within the debugger, please let me know. > > > > AFAIK just before BETA3 system libraries were bumpted. One should > > rebuild ports after upgrading the system from earlier one. Is it your > > case? > Can mismatched library versions really cause kernel panics?? Can't say for sure. But lets solve problems by steps. Using different system libraries simultaneously is not right (we don't have compat-5x). If the case remain after rebuilding ports, we'll ask kernel gurus to help us. WBR -- bsam From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 16:35: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 8A15C16A41F for ; Thu, 1 Sep 2005 16:35:13 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fileserver.fields.utoronto.ca (fileserver.fields.utoronto.ca [128.100.216.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27E1743D45 for ; Thu, 1 Sep 2005 16:35:13 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fields.fields.utoronto.ca (fields.localdomain [192.168.216.11]) by fileserver.fields.utoronto.ca (8.12.8/8.12.8/Fields 6.0) with ESMTP id j81GZCvf007726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 1 Sep 2005 12:35:12 -0400 Received: from obsecurity.dyndns.org (localhost.localdomain [127.0.0.1]) by fields.fields.utoronto.ca (8.12.8/8.12.8/Fields WS 6.0) with ESMTP id j81GZC6P028977 for ; Thu, 1 Sep 2005 12:35:12 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 0C2E0514DD; Thu, 1 Sep 2005 12:35:11 -0400 (EDT) Date: Thu, 1 Sep 2005 12:35:11 -0400 From: Kris Kennaway To: current@FreeBSD.org Message-ID: <20050901163511.GB67218@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pvezYHf7grwyp3Bc" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: twe dumping broken again? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2005 16:35:13 -0000 --pvezYHf7grwyp3Bc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I'm getting the following error when trying to dump on a twe controller: db> call doadump Dumping 2047 MB (2 chunks) chunk 0: 1MB (154 pages) ... ok chunk 1: 2047MB (523968 pages) ... fail ** DUMP FAILED (ERROR 1) ** = 0x1d This was working previously..is it my hardware or the driver at fault? Kris --pvezYHf7grwyp3Bc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDFy2+Wry0BWjoQKURAiP4AKDWgmM/nxS2HjDvjvJtJXb6t6CQEACgl26K zQDYtj67hIoGz8+xS6QzFeY= =dAbk -----END PGP SIGNATURE----- --pvezYHf7grwyp3Bc-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 16:37:13 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 C40F516A41F for ; Thu, 1 Sep 2005 16:37:13 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fileserver.fields.utoronto.ca (fileserver.fields.utoronto.ca [128.100.216.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 593FA43D45 for ; Thu, 1 Sep 2005 16:37:13 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fields.fields.utoronto.ca (fields.localdomain [192.168.216.11]) by fileserver.fields.utoronto.ca (8.12.8/8.12.8/Fields 6.0) with ESMTP id j81GbBvf008132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Sep 2005 12:37:11 -0400 Received: from obsecurity.dyndns.org (localhost.localdomain [127.0.0.1]) by fields.fields.utoronto.ca (8.12.8/8.12.8/Fields WS 6.0) with ESMTP id j81Gb66P029067; Thu, 1 Sep 2005 12:37:11 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 5C7AC511FD; Thu, 1 Sep 2005 12:37:06 -0400 (EDT) Date: Thu, 1 Sep 2005 12:37:05 -0400 From: Kris Kennaway To: Gregory Nou Message-ID: <20050901163705.GA67384@xor.obsecurity.org> References: <4316E1A0.8070307@altern.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Kj7319i9nmIyA2yE" Content-Disposition: inline In-Reply-To: <4316E1A0.8070307@altern.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: Problem with deleting files X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2005 16:37:13 -0000 --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 01, 2005 at 01:10:24PM +0200, Gregory Nou wrote: > Hi, >=20 > I'm currently experiencing a weird problem : some of my folders are=20 > completely empty (ls -a doesn't even mention . or ..) > But, I cannot remove them, and a ls is very very slow (but just in those= =20 > folders, and it is quite rare, but now I cannot update firefox, nor=20 > openoffice, because make clean will fail). >=20 > uname -a gives : > FreeBSD *.fr 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Fri Aug 26 10:12:03=20 > CEST 2005 root@*.fr:/usr/obj/usr/src/sys/MYKERNEL i386 >=20 > my questions are : > Is it Freebsd related, or may it be a problem with my hard disk ? > Is there a way to delete, or just unlink a folder, even if it doesn't=20 > appear to be empty ? You forgot to show us the problem, but try unmounting your filesystem and running fsck -f. Kris --Kj7319i9nmIyA2yE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDFy4xWry0BWjoQKURAu9yAJ45+HEA/3xh8ZnpV/zFpY2p8Z/xGQCeME9T PXlutTLLZ8tpEzoQGjTChUg= =NVmc -----END PGP SIGNATURE----- --Kj7319i9nmIyA2yE-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 16:47:45 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 0688116A41F; Thu, 1 Sep 2005 16:47:45 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9690143D45; Thu, 1 Sep 2005 16:47:44 +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 postfix3-1.free.fr (Postfix) with ESMTP id 2A11A173498; Thu, 1 Sep 2005 18:47:41 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 1D660405A; Thu, 1 Sep 2005 18:47:58 +0200 (CEST) Date: Thu, 1 Sep 2005 18:47:58 +0200 From: Jeremie Le Hen To: Suleiman Souhlal Message-ID: <20050901164757.GQ659@obiwan.tataz.chchile.org> References: <20050830124435.GW659@obiwan.tataz.chchile.org> <20050830232818.GA83944@xor.obsecurity.org> <66A71CA4-8134-43A3-BEAB-485C7DF59EA1@FreeBSD.org> <20050831130254.GF659@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050831130254.GF659@obiwan.tataz.chchile.org> User-Agent: Mutt/1.5.9i Cc: freebsd-current@FreeBSD.org, Matthias Andree , Jeremie Le Hen , Kris Kennaway Subject: Re: nfs through nullfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2005 16:47:45 -0000 Hi Suleiman, > > Can you try the patch at http://people.freebsd.org/~ssouhlal/testing/ > > null_vnops.c-20050831.diff ? > > Thanks. > > I'll give a try to this patch later today if I can find some time. > I will test it tomorrow otherwise. The patch removes the panic for a NFS filesystem which you null mount somewhere else. %%% # mount -t nfs obiwan:/home/ncvs /nfs/obiwan/cvs # mount_nullfs /nfs/obiwan/cvs /cvs # cd /sys # cat CVS/Root /cvs # cvs diff -up [...] %%% No panic any more. Thank you ! :-) Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 17:10:58 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 8918C16A41F for ; Thu, 1 Sep 2005 17:10:58 +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 12B8943D45 for ; Thu, 1 Sep 2005 17:10:57 +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 j81HAck2021988; Thu, 1 Sep 2005 18:10:38 +0100 (BST) Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.13.3/8.13.4) with ESMTP id j81HAcCr063109; Thu, 1 Sep 2005 18:10:38 +0100 (BST) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: (from ga9@localhost) by buffy.york.ac.uk (8.13.3/8.13.4/Submit) id j81HAa1c063108; Thu, 1 Sep 2005 18:10:36 +0100 (BST) (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: Yar Tikhiy In-Reply-To: <20050831134927.GA20529@comp.chem.msu.su> References: <1125487485.34476.6.camel@buffy.york.ac.uk> <20050831134927.GA20529@comp.chem.msu.su> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 01 Sep 2005 18:10:35 +0100 Message-Id: <1125594635.63101.3.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 Subject: Re: 6.0BETA3 panic in ip_output (vlan/RIP related?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2005 17:10:58 -0000 On Wed, 2005-08-31 at 17:49 +0400, Yar Tikhiy wrote: > On Wed, Aug 31, 2005 at 12:24:45PM +0100, Gavin Atkinson wrote: > > > > I've just managed to panic an amd64 machine running 6.0BETA3. > > > > wiggum# ifconfig vlan76 destroy > > wiggum# Aug 31 12:02:48 wiggum routed[244]: IP_DROP_MEMBERSHIP ALLHOSTS: Can't assign requested address > > wiggum# > > wiggum# ifconfig vlan76 create > > wiggum# ifconfig vlan76 vlan 76 vlandev bge0 > > wiggum# ifconfig vlan76 inet x.y.76.59 netmask 255.255.254.0 > > > > > > Fatal trap 9: general protection fault while in kernel mode > > cpuid = 0; apic id = 00 > > instruction pointer = 0x8:0xffffffff80429420 > > stack pointer = 0x10:0xffffffffb260b600 > > frame pointer = 0x10:0xffffffffb260b710 > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 244 (routed) > > Thanks for reporting this! The problem seems known and has > to do with a deficiency in our multicast code WRT interface > removal/re-insertion. It is on the to-do list of our networking > gurus and hopefully will be dealt with RSN, after IP multicast > code locking and cleanup are complete. It's good to hear that the problem is understood, however it seems that this panic is trivial to recreate for anyone running routed, and therefore 6.0-RELEASE may well be unusable for me. I've just got this second panic from the same machine which looks like it may also be related to the multicast code. wiggum# reboot Sep 1 18:05:05 wiggum reboot: r Faooted by root Sep 1 18:05:05 wiggum syslogd: exiting on signal 15 tal trap 9: general protection fault while in kernel mode cpuid = 1; apic id = 01 instruction pointer = 0x8:0xffffffff80429420 stack pointer = 0x10:0xffffffffb49c4590 frame pointer = 0x10:0xffffffffb49c46a0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 244 (routed) [thread pid 244 tid 100101 ] Stopped at strlen: cmpb $0,0(%rdi) db> tr Tracing pid 244 tid 100101 td 0xffffff0061d1b980 strlen() at strlen vsnprintf() at vsnprintf+0x2e panic() at panic+0x14b _mtx_lock_flags() at _mtx_lock_flags+0xd6 if_delmulti() at if_delmulti+0x3f in_delmulti() at in_delmulti+0x4b ip_freemoptions() at ip_freemoptions+0x30 in_pcbdetach() at in_pcbdetach+0x182 udp_detach() at udp_detach+0x51 soclose() at soclose+0x1a0 soo_close() at soo_close+0x3f fdrop_locked() at fdrop_locked+0xa1 closef() at closef+0x31 fdfree() at fdfree+0x48a exit1() at exit1+0x302 sys_exit() at sys_exit+0xe syscall() at syscall+0x4b2 Xfast_syscall() at Xfast_syscall+0xa8 Given I've accidentally been able to panic this machine twice in two days, is there any chance a fix or at least a band-aid will be in place before the release? Thanks, Gavin From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 17:22: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 A807716A41F; Thu, 1 Sep 2005 17:22:40 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34B4F43D46; Thu, 1 Sep 2005 17:22:40 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id j81HMMPp021231; Thu, 1 Sep 2005 10:22:26 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200509011722.j81HMMPp021231@gw.catspoiler.org> Date: Thu, 1 Sep 2005 10:22:22 -0700 (PDT) From: Don Lewis To: fli+freebsd-current@shapeshifter.se In-Reply-To: <4316CE7B.2090303@shapeshifter.se> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: bzeeb-lists@lists.zabbadoz.net, freebsd-current@FreeBSD.org, rwatson@FreeBSD.org, dandee@volny.cz, imp@bsdimp.com Subject: Re: LOR route vr0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2005 17:22:40 -0000 On 1 Sep, Fredrik Lindberg wrote: > Don Lewis wrote: >> On 27 Aug, M. Warner Losh wrote: >> >>>In message: <20050828025721.X43518@fledge.watson.org> >>> Robert Watson writes: >>>: >>>: On Sat, 27 Aug 2005, M. Warner Losh wrote: >>>: >>>: > : You need to add an entry to subr_witness.c creating a graph edge between >>>: > : the softc lock and the routing lock. An example of an entry in >>>: > : subr_witness.c: >>>: > : >>>: > : /* >>>: > : * TCP/IP >>>: > : */ >>>: > : { "tcp", &lock_class_mtx_sleep }, >>>: > : { "tcpinp", &lock_class_mtx_sleep }, >>>: > : { "so_snd", &lock_class_mtx_sleep }, >>>: > : { NULL, NULL }, >>>: > : >>>: > : Note that sets of ordered entries are terminated with a double-null. This >>>: > : declares that locks of type "tcp" preceed "tcpinp" which preceed >>>: > : "so_snd". >>>: > >>>: > So you have to have locks of type tcp BEFORE you take out tcpinp type >>>: > locks? >>>: >>>: Correct. 'tcp' reflects the global TCP state tables (pcbinfo) locks, and >>>: 'tcpinp' is for individual PCBs. If you acquire first a tcpinp and then >>>: tcp, the above settings should cause WITNESS to generate a lock order >>>: warning. Likewise, both tcp and tcpinp preceed so_snd, so if you acquire >>>: a protocol lock after a socket lock, it will get unhappy. WITNESS handles >>>: transitive relationships, so it gets connected up to the rest of the lock >>>: graph, explicit and implicit, so indirect violations of orders are fully >>>: handled. >>> >>>OK. I've been seeing similar LORs in ed, sn, iwi (ed is my locked >>>version of ed, not in tree GIANT locked ed). >> >> >> Just as a datapoint, I've got fxp interfaces on all my machines running >> -CURRENT and I'm not seeing the problem here. >> > > I'm seeing both the rentry and the tcpinp LORs on my fxp interface > on a machine running a few days old -current (Aug 25). > > lock order reversal > 1st 0xc1e30d38 inp (tcpinp) @ /usr/src/sys/netinet/tcp_input.c:742 > 2nd 0xc1b74018 fxp0 (network driver) @/usr/src/sys/dev/fxp/if_fxp.c:1172 > > lock order reversal > 1st 0xc1e06bb8 rtentry (rtentry) @ /usr/src/sys/net/route.c:1269 > 2nd 0xc1b74018 fxp0 (network driver) @/usr/src/sys/dev/fxp/if_fxp.c:1172 > > As for their backtraces they are almost identical to the > once already posted. Are you using any applications that use multicast? Can you break into DDB and capture the output of "show witness"? From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 17:45: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 C949B16A41F; Thu, 1 Sep 2005 17:45:39 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BD7C43D46; Thu, 1 Sep 2005 17:45:39 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[10.50.40.201]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Thu, 01 Sep 2005 14:01:00 -0400 From: John Baldwin To: current@FreeBSD.org Date: Thu, 1 Sep 2005 13:46:31 -0400 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509011346.32361.jhb@FreeBSD.org> Cc: Robert Watson Subject: Witness 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, 01 Sep 2005 17:45:39 -0000 This patch forces witness to complain if any mutex is held when Giant is locked to enforce Giant being the first mutex in the lock order. This might help track down some of the network LORs being reported recently. http://www.FreeBSD.org/~jhb/patches/witness.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 Thu Sep 1 17:45: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 3DA9316A41F; Thu, 1 Sep 2005 17:45:41 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA29B43D48; Thu, 1 Sep 2005 17:45:40 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[10.50.40.201]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Thu, 01 Sep 2005 14:01:00 -0400 From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 1 Sep 2005 13:32:21 -0400 User-Agent: KMail/1.8 References: <200509011722.j81HMMPp021231@gw.catspoiler.org> In-Reply-To: <200509011722.j81HMMPp021231@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509011332.24342.jhb@FreeBSD.org> Cc: Don Lewis , rwatson@freebsd.org, dandee@volny.cz, bzeeb-lists@lists.zabbadoz.net, fli+freebsd-current@shapeshifter.se, imp@bsdimp.com Subject: Re: LOR route vr0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2005 17:45:41 -0000 On Thursday 01 September 2005 01:22 pm, Don Lewis wrote: > On 1 Sep, Fredrik Lindberg wrote: > > Don Lewis wrote: > >> On 27 Aug, M. Warner Losh wrote: > >>>In message: <20050828025721.X43518@fledge.watson.org> > >>> > >>> Robert Watson writes: > >>>: On Sat, 27 Aug 2005, M. Warner Losh wrote: > >>>: > : You need to add an entry to subr_witness.c creating a graph edge > >>>: > : between the softc lock and the routing lock. An example of an > >>>: > : entry in subr_witness.c: > >>>: > : > >>>: > : /* > >>>: > : * TCP/IP > >>>: > : */ > >>>: > : { "tcp", &lock_class_mtx_sleep }, > >>>: > : { "tcpinp", &lock_class_mtx_sleep }, > >>>: > : { "so_snd", &lock_class_mtx_sleep }, > >>>: > : { NULL, NULL }, > >>>: > : > >>>: > : Note that sets of ordered entries are terminated with a > >>>: > : double-null. This declares that locks of type "tcp" preceed > >>>: > : "tcpinp" which preceed "so_snd". > >>>: > > >>>: > So you have to have locks of type tcp BEFORE you take out tcpinp > >>>: > type locks? > >>>: > >>>: Correct. 'tcp' reflects the global TCP state tables (pcbinfo) locks, > >>>: and 'tcpinp' is for individual PCBs. If you acquire first a tcpinp > >>>: and then tcp, the above settings should cause WITNESS to generate a > >>>: lock order warning. Likewise, both tcp and tcpinp preceed so_snd, so > >>>: if you acquire a protocol lock after a socket lock, it will get > >>>: unhappy. WITNESS handles transitive relationships, so it gets > >>>: connected up to the rest of the lock graph, explicit and implicit, so > >>>: indirect violations of orders are fully handled. > >>> > >>>OK. I've been seeing similar LORs in ed, sn, iwi (ed is my locked > >>>version of ed, not in tree GIANT locked ed). > >> > >> Just as a datapoint, I've got fxp interfaces on all my machines running > >> -CURRENT and I'm not seeing the problem here. > > > > I'm seeing both the rentry and the tcpinp LORs on my fxp interface > > on a machine running a few days old -current (Aug 25). > > > > lock order reversal > > 1st 0xc1e30d38 inp (tcpinp) @ /usr/src/sys/netinet/tcp_input.c:742 > > 2nd 0xc1b74018 fxp0 (network driver) @/usr/src/sys/dev/fxp/if_fxp.c:1172 > > > > lock order reversal > > 1st 0xc1e06bb8 rtentry (rtentry) @ /usr/src/sys/net/route.c:1269 > > 2nd 0xc1b74018 fxp0 (network driver) @/usr/src/sys/dev/fxp/if_fxp.c:1172 > > > > As for their backtraces they are almost identical to the > > once already posted. > > Are you using any applications that use multicast? Can you break into > DDB and capture the output of "show witness"? Also, are you using DEVICE_POLLING? -- 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 Sep 1 19:07: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 6D74916A41F for ; Thu, 1 Sep 2005 19:07:41 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF5B243D53 for ; Thu, 1 Sep 2005 19:07:38 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id j81JCMu7057621 for ; Thu, 1 Sep 2005 15:12:22 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Thu, 1 Sep 2005 15:07:21 -0400 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_rF1FDNJiSOCEkkA" Message-Id: <200509011507.23432.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.85.1/1051/Thu Sep 1 10:57:21 2005 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: Subject: [PATCH] boot loader fixes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2005 19:07:41 -0000 --Boundary-00=_rF1FDNJiSOCEkkA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline This patch has various boot loader fixes. 1. Add capability to allow BOOT_COMCONSOLE_SPEED=0, which is extension of the following commit: http://docs.freebsd.org/cgi/mid.cgi?200411241539.iAOFd40s041084 2. Remove '-fno-unit-at-a-time' from boot2.c build. It seems there were two problems. '-fno-unit-at-a-time' and '-mrtd' conflict: http://docs.freebsd.org/cgi/mid.cgi?200408062059.i76KxTBW026143 This problem seems to be resolved by importing new GCC. static memcpy(): http://docs.freebsd.org/cgi/mid.cgi?20040807011451.GA51119 I can be easily resolved by removing static as suggested. 3. Add more bound checks. Note that comconsole speed check is currently disabled because of size limitation. :-( 4. Allow '-S0' or simply '-S'. This is not to change serial speed. 5. Fix array size bug. 6. Clean up style for more readability. Please test. Thanks, Jung-uk Kim --Boundary-00=_rF1FDNJiSOCEkkA Content-Type: text/x-diff; charset="us-ascii"; name="boot.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="boot.diff" Index: src/sys/boot/i386/boot0/Makefile =================================================================== RCS file: /home/ncvs/src/sys/boot/i386/boot0/Makefile,v retrieving revision 1.32 diff -u -r1.32 Makefile --- src/sys/boot/i386/boot0/Makefile 25 Apr 2005 17:41:35 -0000 1.32 +++ src/sys/boot/i386/boot0/Makefile 1 Sep 2005 17:12:16 -0000 @@ -45,6 +45,8 @@ BOOT_BOOT0_COMCONSOLE_SPEED= "1 << 5 + 3" .elif ${BOOT_COMCONSOLE_SPEED} == 110 BOOT_BOOT0_COMCONSOLE_SPEED= "0 << 5 + 3" +.elif ${BOOT_COMCONSOLE_SPEED} == 0 +BOOT_BOOT0_COMCONSOLE_SPEED= 0 .else BOOT_BOOT0_COMCONSOLE_SPEED= "7 << 5 + 3" .endif Index: src/sys/boot/i386/boot2/Makefile =================================================================== RCS file: /home/ncvs/src/sys/boot/i386/boot2/Makefile,v retrieving revision 1.59 diff -u -r1.59 Makefile --- src/sys/boot/i386/boot2/Makefile 15 Jul 2005 12:22:14 -0000 1.59 +++ src/sys/boot/i386/boot2/Makefile 1 Sep 2005 17:12:16 -0000 @@ -23,7 +23,6 @@ CFLAGS= -Os \ -fno-guess-branch-probability \ -fomit-frame-pointer \ - -fno-unit-at-a-time \ -mno-align-long-strings \ -mrtd \ -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 \ Index: src/sys/boot/i386/boot2/boot2.c =================================================================== RCS file: /home/ncvs/src/sys/boot/i386/boot2/boot2.c,v retrieving revision 1.74 diff -u -r1.74 boot2.c --- src/sys/boot/i386/boot2/boot2.c 18 Aug 2005 00:42:45 -0000 1.74 +++ src/sys/boot/i386/boot2/boot2.c 1 Sep 2005 17:12:16 -0000 @@ -63,6 +63,7 @@ #define RBX_NOINTR 0x1c /* -n */ /* 0x1d is reserved for log2(RB_MULTIPLE) and is just misnamed here. */ #define RBX_DUAL 0x1d /* -D */ +/* 0x1e is RBX_PROBEKBD (-P). No longer needed here. */ /* 0x1f is reserved for log2(RB_BOOTINFO). */ /* pass: -a, -s, -r, -d, -c, -v, -h, -C, -g, -m, -p, -D */ @@ -73,7 +74,7 @@ #define PATH_KERNEL "/boot/kernel/kernel" #define ARGS 0x900 -#define NOPT 12 +#define NOPT 11 #define NDEV 3 #define MEM_BASE 0x12 #define MEM_EXT 0x15 @@ -90,13 +91,26 @@ extern uint32_t _end; -static const char optstr[NOPT] = "DhaCgmnprsv"; /* Also 'P', 'S' */ +static const char optstr[NOPT] = { + 'a', /* RBX_ASKNAME */ + 'C', /* RBX_CDROM */ + 'D', /* RBX_DUAL */ + 'g', /* RBX_GDB */ + 'h', /* RBX_SERIAL */ + 'm', /* RBX_MUTE */ + 'n', /* RBX_NOINTR */ + 'p', /* RBX_PAUSE */ + 'r', /* RBX_DFLTROOT */ + 's', /* RBX_SINGLE */ + 'v' /* RBX_VERBOSE */ +}; + static const unsigned char flags[NOPT] = { - RBX_DUAL, - RBX_SERIAL, RBX_ASKNAME, RBX_CDROM, + RBX_DUAL, RBX_GDB, + RBX_SERIAL, RBX_MUTE, RBX_NOINTR, RBX_PAUSE, @@ -138,8 +152,8 @@ static int xgetc(int); static int getc(int); -static void memcpy(void *, const void *, int); -static void +void memcpy(void *, const void *, int); +void memcpy(void *dst, const void *src, int len) { const char *s = src; @@ -388,22 +402,21 @@ static int parse() { - char *arg = cmd; - char *ep, *p, *q; + char *arg; + char *p, *q; const char *cp; - unsigned int drv; - int c, i, j; + unsigned drv; + int i, j; - while ((c = *arg++)) { - if (c == ' ' || c == '\t' || c == '\n') + for (arg = cmd; *arg; arg++) { + if (*arg == ' ' || *arg == '\t' || *arg == '\n') continue; for (p = arg; *p && *p != '\n' && *p != ' ' && *p != '\t'; p++); - ep = p; if (*p) - *p++ = 0; - if (c == '-') { - while ((c = *arg++)) { - if (c == 'P') { + *p = '\0'; + if (*arg == '-') { + for (q = arg + 1; *q; q++) { + if (*q == 'P') { if (*(uint8_t *)PTOV(0x496) & 0x10) { cp = "yes"; } else { @@ -411,33 +424,42 @@ cp = "no"; } printf("Keyboard: %s\n", cp); - continue; - } else if (c == 'S') { - j = 0; - while ((unsigned int)(i = *arg++ - '0') <= 9) - j = j * 10 + i; - if (j > 0 && i == -'0') { + } else if (*q == 'S') { + for (i = 1, j = 0; q[i] >= '0' && q[i] <= '9'; i++) + j = j * 10 + q[i] - '0'; +#if defined(UFS1_ONLY) || defined(UFS2_ONLY) + switch(i) { + case 0: /* do not change speed */ + case 110: case 150: case 300: case 1200: + case 2400: case 4800: case 9600: case 19200: + case 38400: case 57600: case 115200: comspeed = j; break; + default: /* invalid speed */ + return -1; } - /* Fall through to error below ('S' not in optstr[]). */ +#else + comspeed = j; +#endif + q += i - 1; + } else { + for (i = 0; *q != optstr[i]; i++) + if (i == NOPT - 1) + return -1; + opts ^= 1 << flags[i]; } - for (i = 0; c != optstr[i]; i++) - if (i == NOPT - 1) - return -1; - opts ^= 1 << flags[i]; } ioctrl = opts & 1 << RBX_DUAL ? (IO_SERIAL|IO_KEYBOARD) : opts & 1 << RBX_SERIAL ? IO_SERIAL : IO_KEYBOARD; - if (ioctrl & IO_SERIAL) - sio_init(115200 / comspeed); + if (comspeed && (ioctrl & IO_SERIAL)) + sio_init(115200 / comspeed); } else { - for (q = arg--; *q && *q != '('; q++); + for (q = arg; *q && *q != '('; q++); if (*q) { drv = -1; if (arg[1] == ':') { drv = *arg - '0'; - if (drv > 9) + if (drv < 0 || drv > 9) return (-1); arg += 2; } @@ -447,32 +469,31 @@ arg[1] != dev_nm[i][1]; i++) if (i == NDEV - 1) return -1; - dsk.type = i; arg += 3; dsk.unit = *arg - '0'; - if (arg[1] != ',' || dsk.unit > 9) + if (arg[1] != ',' || dsk.unit < 0 || dsk.unit > 9) return -1; arg += 2; dsk.slice = WHOLE_DISK_SLICE; if (arg[1] == ',') { dsk.slice = *arg - '0' + 1; - if (dsk.slice > NDOSPART) + if (dsk.slice < 1 || dsk.slice > NDOSPART) return -1; arg += 2; } if (arg[1] != ')') return -1; dsk.part = *arg - 'a'; - if (dsk.part > 7) + if (dsk.part < 0 || dsk.part > 7) return (-1); arg += 2; if (drv == -1) drv = dsk.unit; - dsk.drive = (dsk.type <= TYPE_MAXHARD - ? DRV_HARD : 0) + drv; + dsk.drive = (i <= TYPE_MAXHARD ? DRV_HARD : 0) + drv; + dsk.type = i; dsk_meta = 0; } - if ((i = ep - arg)) { + if ((i = p - arg)) { if ((size_t)i >= sizeof(kname)) return -1; memcpy(kname, arg, i + 1); Index: src/sys/boot/i386/libi386/comconsole.c =================================================================== RCS file: /home/ncvs/src/sys/boot/i386/libi386/comconsole.c,v retrieving revision 1.11 diff -u -r1.11 comconsole.c --- src/sys/boot/i386/libi386/comconsole.c 18 Aug 2005 01:39:43 -0000 1.11 +++ src/sys/boot/i386/libi386/comconsole.c 1 Sep 2005 17:12:16 -0000 @@ -96,6 +96,8 @@ if (speed > 0) comc_curspeed = speed; } + if (comc_curspeed == 0) + comc_curspeed = comc_getspeed(); sprintf(speedbuf, "%d", comc_curspeed); unsetenv("comconsole_speed"); @@ -145,7 +147,7 @@ { int speed; - if (value == NULL || (speed = comc_parsespeed(value)) <= 0) { + if (value == NULL || (speed = comc_parsespeed(value)) < 0) { printf("Invalid speed\n"); return (CMD_ERROR); } @@ -162,6 +164,8 @@ comc_setup(int speed) { + if (speed == 0) + return; comc_curspeed = speed; outb(COMPORT + com_cfcr, CFCR_DLAB | COMC_FMT); @@ -182,7 +186,7 @@ int speed; speed = strtol(speedstr, &p, 0); - if (p == speedstr || *p != '\0' || speed <= 0) + if (p == speedstr || *p != '\0' || speed < 0) return (-1); return (speed); --Boundary-00=_rF1FDNJiSOCEkkA-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 19:15: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 E4BD716A41F for ; Thu, 1 Sep 2005 19:15:19 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DB7343D45 for ; Thu, 1 Sep 2005 19:15:19 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id j81JK2cC057893 for ; Thu, 1 Sep 2005 15:20:02 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Thu, 1 Sep 2005 15:15:01 -0400 User-Agent: KMail/1.6.2 References: <200509011507.23432.jkim@FreeBSD.org> In-Reply-To: <200509011507.23432.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: 7bit Message-Id: <200509011515.03244.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.85.1/1051/Thu Sep 1 10:57:21 2005 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: Subject: Re: [PATCH] boot loader fixes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2005 19:15:20 -0000 On Thursday 01 September 2005 03:07 pm, Jung-uk Kim wrote: --- >8 --- SNIP!!! --- >8 --- > 2. Remove '-fno-unit-at-a-time' from boot2.c build. It seems > there were two problems. > > '-fno-unit-at-a-time' and '-mrtd' conflict: --- >8 --- SNIP!!! --- >8 --- I meant '-funit-at-a-time' here, of course. Sorry for the typo, Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 19:50:09 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 07A1C16A41F for ; Thu, 1 Sep 2005 19:50:09 +0000 (GMT) (envelope-from incmc@gmx.de) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 3182C43D45 for ; Thu, 1 Sep 2005 19:50:07 +0000 (GMT) (envelope-from incmc@gmx.de) Received: (qmail invoked by alias); 01 Sep 2005 19:50:06 -0000 Received: from dsl-084-061-012-051.arcor-ip.net (EHLO ms.homeip.net) [84.61.12.51] by mail.gmx.net (mp009) with SMTP; 01 Sep 2005 21:50:06 +0200 X-Authenticated: #15946415 Received: from p508f5bee.dip.t-dialin.net ([80.143.91.238] helo=nix-rechnername-auspaehen-hier) by ms.homeip.net with esmtpsa (SSLv3:RC4-MD5:128) id 1EAv4d-000D5U-OT for freebsd-current@freebsd.org; Thu, 01 Sep 2005 21:50:11 +0200 From: Jochen Gensch To: freebsd-current@freebsd.org Date: Thu, 1 Sep 2005 21:49:26 +0200 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: <200509012149.26400.incmc@gmx.de> X-Y-GMX-Trusted: 0 Subject: Default route doesn't change to wireless device (ath0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2005 19:50:09 -0000 Hi! If I plug in my wireless nic (atheros) it comes up automatically through wpa_supplicant. However the default route still points to my non wireless nic (fxp0) even if remove the network cable before plugging in the wireless device. I have found no way around this, the only way of getting the default route changed to ath0 is setting in manually. Can't that be done automatically on plugging in either? Jochen From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 20:01: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 B2FBC16A41F for ; Thu, 1 Sep 2005 20:01:41 +0000 (GMT) (envelope-from jd@ugcs.caltech.edu) Received: from vomit.ugcs.caltech.edu (vomit.ugcs.caltech.edu [131.215.176.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id 536C243D49 for ; Thu, 1 Sep 2005 20:01:41 +0000 (GMT) (envelope-from jd@ugcs.caltech.edu) Received: by vomit.ugcs.caltech.edu (Postfix, from userid 3640) id D4062E816; Thu, 1 Sep 2005 13:01:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by vomit.ugcs.caltech.edu (Postfix) with ESMTP id BB77CE815; Thu, 1 Sep 2005 13:01:38 -0700 (PDT) Date: Thu, 1 Sep 2005 13:01:38 -0700 (PDT) From: Jon Dama To: Jochen Gensch In-Reply-To: <200509012149.26400.incmc@gmx.de> Message-ID: References: <200509012149.26400.incmc@gmx.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-current@freebsd.org Subject: Re: Default route doesn't change to wireless device (ath0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2005 20:01:41 -0000 Flush the routing table or at least delete the default entry in a start_if.ath0 script. -Jon On Thu, 1 Sep 2005, Jochen Gensch wrote: > Hi! > > If I plug in my wireless nic (atheros) it comes up automatically through > wpa_supplicant. However the default route still points to my non wireless nic > (fxp0) even if remove the network cable before plugging in the wireless > device. I have found no way around this, the only way of getting the default > route changed to ath0 is setting in manually. Can't that be done > automatically on plugging in either? > > Jochen > _______________________________________________ > 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 Thu Sep 1 20:14: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 2F64616A41F; Thu, 1 Sep 2005 20:14:51 +0000 (GMT) (envelope-from fli+freebsd-current@shapeshifter.se) Received: from mx1.h3q.net (manticore.shapeshifter.se [212.37.5.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9183243D49; Thu, 1 Sep 2005 20:14:48 +0000 (GMT) (envelope-from fli+freebsd-current@shapeshifter.se) Received: from localhost (localhost [127.0.0.1]) by mx1.h3q.net (Postfix) with ESMTP id AF9BF1A744; Thu, 1 Sep 2005 22:14:45 +0200 (CEST) Received: from mx1.h3q.net ([127.0.0.1]) by localhost (manticore.shapeshifter.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39106-20; Thu, 1 Sep 2005 22:14:43 +0200 (CEST) Received: from [192.168.0.96] (h4n2fls31o270.telia.com [217.208.199.4]) by mx1.h3q.net (Postfix) with ESMTP id 8B83D1A743; Thu, 1 Sep 2005 22:14:41 +0200 (CEST) Message-ID: <43176130.4020604@shapeshifter.se> Date: Thu, 01 Sep 2005 22:14:40 +0200 From: Fredrik Lindberg User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050816) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <200509011722.j81HMMPp021231@gw.catspoiler.org> <200509011332.24342.jhb@FreeBSD.org> In-Reply-To: <200509011332.24342.jhb@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: at mail.hamnpolare.net Cc: Don Lewis , freebsd-current@freebsd.org, rwatson@freebsd.org, dandee@volny.cz, bzeeb-lists@lists.zabbadoz.net, imp@bsdimp.com Subject: Re: LOR route vr0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2005 20:14:51 -0000 John Baldwin wrote: > On Thursday 01 September 2005 01:22 pm, Don Lewis wrote: > >>On 1 Sep, Fredrik Lindberg wrote: >> >>>Don Lewis wrote: >>> >>>>On 27 Aug, M. Warner Losh wrote: >>>> >>>>>In message: <20050828025721.X43518@fledge.watson.org> >>>>> >>>>> Robert Watson writes: >>>>>: On Sat, 27 Aug 2005, M. Warner Losh wrote: >>>>>: > : You need to add an entry to subr_witness.c creating a graph edge >>>>>: > : between the softc lock and the routing lock. An example of an >>>>>: > : entry in subr_witness.c: >>>>>: > : >>>>>: > : /* >>>>>: > : * TCP/IP >>>>>: > : */ >>>>>: > : { "tcp", &lock_class_mtx_sleep }, >>>>>: > : { "tcpinp", &lock_class_mtx_sleep }, >>>>>: > : { "so_snd", &lock_class_mtx_sleep }, >>>>>: > : { NULL, NULL }, >>>>>: > : >>>>>: > : Note that sets of ordered entries are terminated with a >>>>>: > : double-null. This declares that locks of type "tcp" preceed >>>>>: > : "tcpinp" which preceed "so_snd". >>>>>: > >>>>>: > So you have to have locks of type tcp BEFORE you take out tcpinp >>>>>: > type locks? >>>>>: >>>>>: Correct. 'tcp' reflects the global TCP state tables (pcbinfo) locks, >>>>>: and 'tcpinp' is for individual PCBs. If you acquire first a tcpinp >>>>>: and then tcp, the above settings should cause WITNESS to generate a >>>>>: lock order warning. Likewise, both tcp and tcpinp preceed so_snd, so >>>>>: if you acquire a protocol lock after a socket lock, it will get >>>>>: unhappy. WITNESS handles transitive relationships, so it gets >>>>>: connected up to the rest of the lock graph, explicit and implicit, so >>>>>: indirect violations of orders are fully handled. >>>>> >>>>>OK. I've been seeing similar LORs in ed, sn, iwi (ed is my locked >>>>>version of ed, not in tree GIANT locked ed). >>>> >>>>Just as a datapoint, I've got fxp interfaces on all my machines running >>>>-CURRENT and I'm not seeing the problem here. >>> >>>I'm seeing both the rentry and the tcpinp LORs on my fxp interface >>>on a machine running a few days old -current (Aug 25). >>> >>>lock order reversal >>>1st 0xc1e30d38 inp (tcpinp) @ /usr/src/sys/netinet/tcp_input.c:742 >>>2nd 0xc1b74018 fxp0 (network driver) @/usr/src/sys/dev/fxp/if_fxp.c:1172 >>> >>>lock order reversal >>>1st 0xc1e06bb8 rtentry (rtentry) @ /usr/src/sys/net/route.c:1269 >>>2nd 0xc1b74018 fxp0 (network driver) @/usr/src/sys/dev/fxp/if_fxp.c:1172 >>> >>>As for their backtraces they are almost identical to the >>>once already posted. >> >>Are you using any applications that use multicast? Can you break into >>DDB and capture the output of "show witness"? > > > Also, are you using DEVICE_POLLING? > No, I'm not using any multicast applications, however the LORs are always triggerd by dhclient at boot, but only at the first DHCPDISCOVER. Initiating a a new discovery does not trigger a LOR. I had DEVICE_POLLLING in my kernel but never used it, I compiled a new kernel without it and the LORs appears to be gone. This particular machine has no serial port (laptop) so getting the full output of show witness is a bit hard (is there a way to extract it from a dump?). I hand-typed some of the output, not sure how usefull it is. I have another machine with a fxp interface (and a serial port) but it needs to be running at the moment, I can probably "play" with it this weekend. 0 fifo mutex -- last acquired @ /usr/src/sys/fs/fifofs/fifo_vnops.c:212 9 so_snd -- last acquired @ /usr/src/sys/kern/uipc_socket.c:1993 10 so_rcv -- last acquired @ /usr/src/sys/kern/uipc_socket.c:1994 11 sellck -- last acquired @ /usr/src/sys/kern/sys_generic.c:764 11 radix node head -- last acquired @ /usr/src/sys/net/route.c:148 12 rtentry -- last acquired @ /usr/src/sys/netinet/ip_route.c:830 13 ifaddr -- last acquired @ /usr/src/sys/net/route.c:791 13 rts_inq -- last acquired @ /usr/src/sys/net/netisr.c:232 13 if send queue -- last acquired @ /usr/src/sys/dev/fxp/if_fxp.c:1212 12 ifnet -- last acquired @ /usr/src/sys/net/if.c:1159 Also, while trying various things with dhclient (with a DEVICE_POLLING-aware kernel), I got two other networking related LORs. lock order reversal 1st 0xc0810180 Giant (Giant) @ /usr/src/sys/kern/kern_descrip.c:1874 2nd 0xc085f88c udp (udp) @ /usr/src/sys/netinet/udp_usrreq.c:1009 KDB: stack backtrace: kdb_backtrace(c07a2861,c085f88c,c07a23ce,c07a23ce,c07acb9d) at kdb_backtrace+0x2e witness_checkorder(c085f88c,9,c07acb9d,3f1,0) at witness_checkorder+0x5a4 _mtx_lock_flags(c085f88c,0,c07acb9d,3f1,c1d53a20) at _mtx_lock_flags+0x32 udp_detach(c2079858,c05a9550,246,c07df404,c1973304) at udp_detach+0x2b soclose(c2079858,c079d789,847,c1d53a20,c1d53a20) at soclose+0x262 soo_close(c1d53a20,c1c3fc80,c079d789,847,c1d53a20) at soo_close+0x6d fdrop_locked(c1d53a20,c1c3fc80,c079d789,832) at fdrop_locked+0x94 fdrop(c1d53a20,c1c3fc80,c079d789,77d,c05a9550,c079d789,c07a26ec,3,c1c3fc80,e5943bb0 ,1,c079d789,e5943bac,c05a9cd6,c085bda0,c20f192c,246,c07df404,c20f192c,64a,c079d789, e5943bd4,c0578b92,c20f192c,8,c079d789,64a) at fdrop+0x3c closef(c1d53a20,c1c3fc80,c079d789,64a,c085bda0) at closef+0x3f2 fdfree(c1c3fc80,0,c079db0d,e6,0) at fdfree+0x526 exit1(c1c3fc80,100,e5943d30,c0754370,c1c3fc80) at exit1+0x4a7 sys_exit(c1c3fc80,e5943d04,4,6,1) at sys_exit+0x1d syscall(3b,3b,3b,1,805670d) at syscall+0x2c0 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x2814af73, esp = 0xbfbfe3cc, ebp = 0xbfbfe3d8 --- lock order reversal 1st 0xc085ca40 bpf global lock (bpf global lock) @ /usr/src/sys/net/bpf.c:425 2nd 0xc1b74018 fxp0 (network driver) @ /usr/src/sys/dev/fxp/if_fxp.c:2367 KDB: stack backtrace: kdb_backtrace(c07a2861,c1b74018,c1b71520,c0785ad5,c0793032) at kdb_backtrace+0x2e witness_checkorder(c1b74018,9,c0793032,93f,246) at witness_checkorder+0x5a4 _mtx_lock_flags(c1b74018,0,c0793032,93f,0) at _mtx_lock_flags+0x32 fxp_ioctl(c1b6f000,80206910,e593da38,c07a26ec,1) at fxp_ioctl+0x90 if_setflag(c1b6f000,100,20000,c1b6f044,0) at if_setflag+0x138 ifpromisc(c1b6f000,0,c07a6c65,14f,c2104100) at ifpromisc+0x3b bpf_detachd(c2104100,0,c07a6c65,1a9,c1fea400) at bpf_detachd+0xeb bpfclose(c1fea400,3,2000,c1c3f960,c2100440) at bpfclose+0xb4 giant_close(c1fea400,3,2000,c1c3f960,c1fea400) at giant_close+0x4f devfs_close(e593db44,e593db70,c05f0626,c07d7f00,e593db44) at devfs_close+0x36b VOP_CLOSE_APV(c07d7f00,e593db44,c1c3f960,c1c6a000,c0802940) at VOP_CLOSE_APV+0x3e vn_close(c2100440,3,c1ff7a00,c1c3f960,68f) at vn_close+0x76 vn_closefile(c20d41f8,c1c3f960,e593dc04,c0561054,c20d41f8) at vn_closefile+0xf4 devfs_close_f(c20d41f8,c1c3f960,c079d789,847,c20d41f8) at devfs_close_f+0x19 fdrop_locked(c20d41f8,c1c3f960,c079d789,832) at fdrop_locked+0x94 fdrop(c20d41f8,c1c3f960,c079d789,77d,c0815d60,0,c07a2570,68f,c085bda4,e593dc7c,1,c0 85bda0,e593dc78,c05a9d07,0,c1e1162c,246,c07df404,c1e1162c,3ea,c079d789,e593dca0,c05 78b92,c1e1162c,8,c079d789,3ea) at fdrop+0x3c closef(c20d41f8,c1c3f960,c079d789,3ea,c1c3f960) at closef+0x3f2 close(c1c3f960,e593dd04,4,c07b2fd7,1) at close+0x1f2 syscall(3b,3b,3b,0,8199000) at syscall+0x2c0 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (6, FreeBSD ELF32, close), eip = 0x282df9a7, esp = 0xbfbfeabc, ebp = 0x bfbfead8 --- Fredrik Lindberg From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 20:25: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 3487116A41F for ; Thu, 1 Sep 2005 20:25:28 +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 9DCF543D4C for ; Thu, 1 Sep 2005 20:25:27 +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 8B590440DA; Thu, 1 Sep 2005 22:25:26 +0200 (CEST) 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 16832-04; Thu, 1 Sep 2005 22:25:25 +0200 (CEST) Received: from m2a2.dyndns.org (p5091378B.dip0.t-ipconnect.de [80.145.55.139]) by mail.dt.e-technik.uni-dortmund.de (Postfix) with ESMTP id 13164440A7; Thu, 1 Sep 2005 22:25:25 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by merlin.emma.line.org (Postfix) with ESMTP id 5B58A79CBB; Thu, 1 Sep 2005 22:25:24 +0200 (CEST) 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 22867-04; Thu, 1 Sep 2005 22:25:23 +0200 (CEST) Received: by merlin.emma.line.org (Postfix, from userid 500) id 9AB8B79CBC; Thu, 1 Sep 2005 22:25:23 +0200 (CEST) From: Matthias Andree To: Rainer Alves In-Reply-To: <431624D4.5080800@powered.net> (Rainer Alves's message of "Wed, 31 Aug 2005 18:44:52 -0300") References: <431624D4.5080800@powered.net> X-PGP-Key: http://home.pages.de/~mandree/keys/GPGKEY.asc Date: Thu, 01 Sep 2005 22:25:23 +0200 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-current@freebsd.org Subject: Re: 6.0-BETA3: ext2fs: if mounted at shutdown, fsck at next boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2005 20:25:28 -0000 Rainer Alves writes: > Actually there's a workaround for this... add the following near the end > of /etc/rc.shutdown: > Sure, it isn't the perfect solution, but it works. I know this workaround, but that such a severe availability bug has not been fixed since it was introduced early in the 5.X times is more than just an annoyance, and apparently nobody cares. (Besides, the workaround doesn't work when the system goes down hard, through a panic or such.) -- Matthias Andree From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 20:26:12 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 28F2616A41F; Thu, 1 Sep 2005 20:26:12 +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 6FF0043D53; Thu, 1 Sep 2005 20:26:09 +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 89FBE440DA; Thu, 1 Sep 2005 22:26:08 +0200 (CEST) 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 16827-05; Thu, 1 Sep 2005 22:26:07 +0200 (CEST) Received: from m2a2.dyndns.org (p5091378B.dip0.t-ipconnect.de [80.145.55.139]) by mail.dt.e-technik.uni-dortmund.de (Postfix) with ESMTP id 0C30D440A7; Thu, 1 Sep 2005 22:26:07 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by merlin.emma.line.org (Postfix) with ESMTP id 6B64379CBB; Thu, 1 Sep 2005 22:26:06 +0200 (CEST) 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 19672-11; Thu, 1 Sep 2005 22:26:05 +0200 (CEST) Received: by merlin.emma.line.org (Postfix, from userid 500) id B978D79CBC; Thu, 1 Sep 2005 22:26:05 +0200 (CEST) From: Matthias Andree To: Suleiman Souhlal In-Reply-To: <66A71CA4-8134-43A3-BEAB-485C7DF59EA1@FreeBSD.org> (Suleiman Souhlal's message of "Wed, 31 Aug 2005 13:47:49 +0200") References: <20050830124435.GW659@obiwan.tataz.chchile.org> <20050830232818.GA83944@xor.obsecurity.org> <66A71CA4-8134-43A3-BEAB-485C7DF59EA1@FreeBSD.org> X-PGP-Key: http://home.pages.de/~mandree/keys/GPGKEY.asc Date: Thu, 01 Sep 2005 22:26:05 +0200 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-current@FreeBSD.org, Matthias Andree , Jeremie Le Hen , Kris Kennaway Subject: Re: nfs through nullfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2005 20:26:12 -0000 Suleiman Souhlal writes: > On Aug 31, 2005, at 12:12 PM, Matthias Andree wrote: > >> OK, to reproduce, three steps apart from having an ext2 file system >> (the ext2 FS is clean according to e2fsck) >> >> mount_ext2fs /dev/ad0s5 /linux >> mount_nullfs /linux /mnt >> umount /mnt -> panic, "locking against myself" >> >> backtrace in the kernel debugger, copied manually: > > Can you try the patch at http://people.freebsd.org/~ssouhlal/testing/ > null_vnops.c-20050831.diff ? Yup. Tried it, no more panic on umount. Thanks a lot. -- Matthias Andree From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 20:51: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 1C9AF16A41F for ; Thu, 1 Sep 2005 20:51:19 +0000 (GMT) (envelope-from incmc@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 3B25543D49 for ; Thu, 1 Sep 2005 20:51:17 +0000 (GMT) (envelope-from incmc@gmx.de) Received: (qmail invoked by alias); 01 Sep 2005 20:51:16 -0000 Received: from dsl-084-061-012-051.arcor-ip.net (EHLO ms.homeip.net) [84.61.12.51] by mail.gmx.net (mp006) with SMTP; 01 Sep 2005 22:51:16 +0200 X-Authenticated: #15946415 Received: from p508f5bee.dip.t-dialin.net ([80.143.91.238] helo=[10.0.0.104]) by ms.homeip.net with esmtpsa (TLSv1:AES256-SHA:256) id 1EAw1q-000DUn-6K; Thu, 01 Sep 2005 22:51:22 +0200 Message-ID: <431769A7.5000407@gmx.de> Date: Thu, 01 Sep 2005 22:50:47 +0200 From: Jochen Gensch User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Jon Dama , freebsd-current@freebsd.org References: <200509012149.26400.incmc@gmx.de> In-Reply-To: X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Subject: Re: Default route doesn't change to wireless device (ath0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2005 20:51:19 -0000 Jon Dama schrieb: > Flush the routing table or at least delete the default entry in a > start_if.ath0 script. Hi! Just tell me where to put it... I guess I need to configure devd.conf for that!? Jochen From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 21:26: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 683F216A41F for ; Thu, 1 Sep 2005 21:26:47 +0000 (GMT) (envelope-from oberman@es.net) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2EC3343D45 for ; Thu, 1 Sep 2005 21:26:47 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id IBA74465; Thu, 01 Sep 2005 14:26:46 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id BE5615D07; Thu, 1 Sep 2005 14:26:45 -0700 (PDT) To: Jon Dama In-reply-to: Your message of "Thu, 01 Sep 2005 13:01:38 PDT." Date: Thu, 01 Sep 2005 14:26:45 -0700 From: "Kevin Oberman" Message-Id: <20050901212645.BE5615D07@ptavv.es.net> Cc: Jochen Gensch , freebsd-current@freebsd.org Subject: Re: Default route doesn't change to wireless device (ath0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2005 21:26:47 -0000 > Date: Thu, 1 Sep 2005 13:01:38 -0700 (PDT) > From: Jon Dama > Sender: owner-freebsd-current@freebsd.org > > Flush the routing table or at least delete the default entry in a > start_if.ath0 script. This is obvious, but does not answer the question: "Can't that be done automatically on plugging in either?" As I recall, when the OpenSSH dhclient was added, one of the things it was supposed to do was flush the routing table. This never seems to have happened and I'm not sure I'd want it to. Maybe devd could automate it? (I think I'm going to try that.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 > On Thu, 1 Sep 2005, Jochen Gensch wrote: > > > Hi! > > > > If I plug in my wireless nic (atheros) it comes up automatically through > > wpa_supplicant. However the default route still points to my non wireless > > nic (fxp0) even if remove the network cable before plugging in the wireless > > device. I have found no way around this, the only way of getting the > > default route changed to ath0 is setting in manually. Can't that be done > > automatically on plugging in either? From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 21:41: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 42C1D16A41F for ; Thu, 1 Sep 2005 21:41:18 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBD3143D49 for ; Thu, 1 Sep 2005 21:41:17 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j81LfDlm018336; Thu, 1 Sep 2005 14:41:13 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j81LfDjt018334; Thu, 1 Sep 2005 14:41:13 -0700 Date: Thu, 1 Sep 2005 14:41:13 -0700 From: Brooks Davis To: Kevin Oberman Message-ID: <20050901214113.GE4108@odin.ac.hmc.edu> References: <20050901212645.BE5615D07@ptavv.es.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WBsA/oQW3eTA3LlM" Content-Disposition: inline In-Reply-To: <20050901212645.BE5615D07@ptavv.es.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: Jochen Gensch , freebsd-current@freebsd.org Subject: Re: Default route doesn't change to wireless device (ath0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2005 21:41:18 -0000 --WBsA/oQW3eTA3LlM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 01, 2005 at 02:26:45PM -0700, Kevin Oberman wrote: > > Date: Thu, 1 Sep 2005 13:01:38 -0700 (PDT) > > From: Jon Dama > > Sender: owner-freebsd-current@freebsd.org > >=20 > > Flush the routing table or at least delete the default entry in a > > start_if.ath0 script. >=20 > This is obvious, but does not answer the question: "Can't that be done > automatically on plugging in either?" >=20 > As I recall, when the OpenSSH dhclient was added, one of the things it > was supposed to do was flush the routing table. This never seems to have > happened and I'm not sure I'd want it to. >=20 > Maybe devd could automate it? (I think I'm going to try that.) devd is probably not the answer. Right now, we refuse to modify the default route if another interface has it, but the expected behavior is probably to modify it even if it's on another interface if that interface is down. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --WBsA/oQW3eTA3LlM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDF3V4XY6L6fI4GtQRAlILAKCRAEvOqKdck42BhXuaCf2MSWhrnwCfT6nG zl/D+989s8XLN834g6rmNic= =GJST -----END PGP SIGNATURE----- --WBsA/oQW3eTA3LlM-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 21:43:58 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 40CD016A41F for ; Thu, 1 Sep 2005 21:43:58 +0000 (GMT) (envelope-from jd@ugcs.caltech.edu) Received: from vomit.ugcs.caltech.edu (vomit.ugcs.caltech.edu [131.215.176.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED8B443D46 for ; Thu, 1 Sep 2005 21:43:57 +0000 (GMT) (envelope-from jd@ugcs.caltech.edu) Received: by vomit.ugcs.caltech.edu (Postfix, from userid 3640) id 8B591E816; Thu, 1 Sep 2005 14:43:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by vomit.ugcs.caltech.edu (Postfix) with ESMTP id 7179DE815; Thu, 1 Sep 2005 14:43:57 -0700 (PDT) Date: Thu, 1 Sep 2005 14:43:57 -0700 (PDT) From: Jon Dama To: Kevin Oberman In-Reply-To: <20050901212645.BE5615D07@ptavv.es.net> Message-ID: References: <20050901212645.BE5615D07@ptavv.es.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Jochen Gensch , freebsd-current@freebsd.org Subject: Re: Default route doesn't change to wireless device (ath0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2005 21:43:58 -0000 If the start_if.ath0 script isn't running, you should check that you have removable_interfaces="ath0" in rc.conf. Though, I saw some traffic that say this was going away. Anyway, quoting Brooks in "HEADSUP: OpenBSD dhclient incoming" "Second the pccard_ifconfig variable is only used as a default value for interfaces that are on the removable_interfaces list, but do not have an ifconfig_ variable. Third, interfaces must be on the removable_interfaces list for pccard_ether to work." There should not be a need to modify devd.conf as there is already this line: attach 0 { device-name "$ethernet-nic-regex"; action "/etc/pccard_ether $device-name start"; } The regex does cover ath0, and pccard_ether should handle the event if the interface is listed in removable_interfaces I also saw some traffic from Brooks where he explicitly stated that the new dhclient does not touch the default route if one is already configured. afaik, this should not actually be a problem because start_if is always run before dhclient has a change to start. Also I agree, it would rather dangerous if dhclient just started flushing the routing table. Incidentially, I've seen this topic come up a dozen times + never knew what do myself until Nate Lawson pointed me in the right direction a year ago. At that time, he remarked that this stuff isn't documented any where + it really should be in the handbook. Can someone point me to where I should look for information on how to contribute to the handbook in a format that is likely to be accepted? This is such a standard thing to want, it has to be done! -Jon On Thu, 1 Sep 2005, Kevin Oberman wrote: > > Date: Thu, 1 Sep 2005 13:01:38 -0700 (PDT) > > From: Jon Dama > > Sender: owner-freebsd-current@freebsd.org > > > > Flush the routing table or at least delete the default entry in a > > start_if.ath0 script. > > This is obvious, but does not answer the question: "Can't that be done > automatically on plugging in either?" > > As I recall, when the OpenSSH dhclient was added, one of the things it > was supposed to do was flush the routing table. This never seems to have > happened and I'm not sure I'd want it to. > > Maybe devd could automate it? (I think I'm going to try that.) > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: oberman@es.net Phone: +1 510 486-8634 > > > > On Thu, 1 Sep 2005, Jochen Gensch wrote: > > > > > Hi! > > > > > > If I plug in my wireless nic (atheros) it comes up automatically through > > > wpa_supplicant. However the default route still points to my non wireless > > > nic (fxp0) even if remove the network cable before plugging in the wireless > > > device. I have found no way around this, the only way of getting the > > > default route changed to ath0 is setting in manually. Can't that be done > > > automatically on plugging in either? > From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 21:49: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 16B5716A41F for ; Thu, 1 Sep 2005 21:49:40 +0000 (GMT) (envelope-from benlutz@datacomm.ch) Received: from maxlor.mine.nu (c-213-160-32-54.customer.ggaweb.ch [213.160.32.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6828D43D45 for ; Thu, 1 Sep 2005 21:49:39 +0000 (GMT) (envelope-from benlutz@datacomm.ch) Received: from localhost (localhost [127.0.0.1]) by maxlor.mine.nu (Postfix) with ESMTP id D526B33C for ; Thu, 1 Sep 2005 23:49:37 +0200 (CEST) Received: from maxlor.mine.nu ([127.0.0.1]) by localhost (midgard.intranet [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14970-03 for ; Thu, 1 Sep 2005 23:49:36 +0200 (CEST) Received: from [10.0.0.23] (mini.intranet [10.0.0.23]) by maxlor.mine.nu (Postfix) with ESMTP id A858D44 for ; Thu, 1 Sep 2005 23:49:36 +0200 (CEST) Message-ID: <4317776C.9070307@datacomm.ch> Date: Thu, 01 Sep 2005 23:49:32 +0200 From: Benjamin Lutz User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: FreeBSD-Current X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7571E4437D729800AEF3E41C" X-Virus-Scanned: amavisd-new at maxlor.mine.nu Cc: Subject: installing ld-elf.so.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: Thu, 01 Sep 2005 21:49:40 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7571E4437D729800AEF3E41C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, While examining my system (FreeBSD 6.0-BETA3 amd64) and removing the old libs from before the version bump, I noticed that the time stamp on /libexec/ld-elf.so.1 does not match that of other system files. The date leads me to believe that my current ld-elf.so.1 is a remainder of a previous installation (its date matches the date of libm.so.3, which was recently bumped to libm.so.4). While trying to figure out why the new ld-elf.so.1 (which appears to have been built correctly) isn't installed. I finally arrived at this point: # cp -p /usr/obj/usr/src/libexec/rtld-elf/ld-elf.so.1 /libexec cp: /libexec/ld-elf.so.1: Text file busy # (This is in single user mode. The result is the same if I use /rescue/cp, which is statically linked.) The open(2) manpage has this to say about it: [ETXTBSY] The file is a pure procedure (shared text) file that is being executed and the open() system call requests write access. So, my question: How can Install the new ld-elf.so.1? Cheers Benjamin --------------enig7571E4437D729800AEF3E41C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (Darwin) iD8DBQFDF3dwgShs4qbRdeQRAleiAJ9mvSqa9oQ2sBh6HorAoFyUEPKLXQCfTfKT eB8kY3LJbgiayz8uo71hw2E= =hxUg -----END PGP SIGNATURE----- --------------enig7571E4437D729800AEF3E41C-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 21:57: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 970F816A41F for ; Thu, 1 Sep 2005 21:57:05 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd5mo3so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id F32FD43D4C for ; Thu, 1 Sep 2005 21:57:04 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd3mr3so.prod.shaw.ca (pd3mr3so-qfe3.prod.shaw.ca [10.0.141.179]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IM5007GTRKSRIE0@l-daemon> for current@freebsd.org; Thu, 01 Sep 2005 15:55:40 -0600 (MDT) Received: from pn2ml8so.prod.shaw.ca ([10.0.121.152]) by pd3mr3so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IM500KXGRKRVBE0@pd3mr3so.prod.shaw.ca> for current@freebsd.org; Thu, 01 Sep 2005 15:55:40 -0600 (MDT) Received: from [192.168.0.60] (S0106006067227a4a.vc.shawcable.net [24.87.209.6]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0IM500J0ARKM2K@l-daemon> for current@freebsd.org; Thu, 01 Sep 2005 15:55:39 -0600 (MDT) Date: Thu, 01 Sep 2005 14:55:33 -0700 From: Colin Percival In-reply-to: <4317776C.9070307@datacomm.ch> To: Benjamin Lutz Message-id: <431778D5.9050505@freebsd.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en X-Enigmail-Version: 0.92.0.0 References: <4317776C.9070307@datacomm.ch> User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050724) Cc: FreeBSD-Current Subject: Re: installing ld-elf.so.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: Thu, 01 Sep 2005 21:57:05 -0000 Benjamin Lutz wrote: > While trying to figure out why the new ld-elf.so.1 (which appears to > have been built correctly) isn't installed. I finally arrived at this point: > > # cp -p /usr/obj/usr/src/libexec/rtld-elf/ld-elf.so.1 /libexec > cp: /libexec/ld-elf.so.1: Text file busy > > So, my question: How can Install the new ld-elf.so.1? Use install(1). Colin Percival From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 22:05: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 7AD3916A41F; Thu, 1 Sep 2005 22:05:24 +0000 (GMT) (envelope-from benlutz@datacomm.ch) Received: from maxlor.mine.nu (c-213-160-32-54.customer.ggaweb.ch [213.160.32.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id EDFF343D45; Thu, 1 Sep 2005 22:05:23 +0000 (GMT) (envelope-from benlutz@datacomm.ch) Received: from localhost (localhost [127.0.0.1]) by maxlor.mine.nu (Postfix) with ESMTP id CFB29343; Fri, 2 Sep 2005 00:05:22 +0200 (CEST) Received: from maxlor.mine.nu ([127.0.0.1]) by localhost (midgard.intranet [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14970-10; Fri, 2 Sep 2005 00:05:21 +0200 (CEST) Received: from [10.0.0.23] (mini.intranet [10.0.0.23]) by maxlor.mine.nu (Postfix) with ESMTP id 9EEFD13E; Fri, 2 Sep 2005 00:05:21 +0200 (CEST) Message-ID: <43177B1D.1030907@datacomm.ch> Date: Fri, 02 Sep 2005 00:05:17 +0200 From: Benjamin Lutz User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Colin Percival References: <4317776C.9070307@datacomm.ch> <431778D5.9050505@freebsd.org> In-Reply-To: <431778D5.9050505@freebsd.org> X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3502447BBF4BBDA3AF8C69D4" X-Virus-Scanned: amavisd-new at maxlor.mine.nu Cc: FreeBSD-Current Subject: Re: installing ld-elf.so.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: Thu, 01 Sep 2005 22:05:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3502447BBF4BBDA3AF8C69D4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Colin Percival wrote: > Benjamin Lutz wrote: > >>While trying to figure out why the new ld-elf.so.1 (which appears to >>have been built correctly) isn't installed. I finally arrived at this point: >> >># cp -p /usr/obj/usr/src/libexec/rtld-elf/ld-elf.so.1 /libexec >>cp: /libexec/ld-elf.so.1: Text file busy >> >>So, my question: How can Install the new ld-elf.so.1? > > Use install(1). Oh. That was kinda obvious... thanks, worked just fine! Cheers Benjamin --------------enig3502447BBF4BBDA3AF8C69D4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (Darwin) iD8DBQFDF3shgShs4qbRdeQRAir0AJ4ihro6fNq7xrodNtwkG67Yuhma/QCbBecG jwJpjd0IWO41OdqMiXM6fPw= =kuan -----END PGP SIGNATURE----- --------------enig3502447BBF4BBDA3AF8C69D4-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 22:36:38 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 7E7EB16A41F for ; Thu, 1 Sep 2005 22:36:38 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A7F343D45 for ; Thu, 1 Sep 2005 22:36:38 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j81MaXw2026573; Thu, 1 Sep 2005 15:36:33 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j81MaXUw026571; Thu, 1 Sep 2005 15:36:33 -0700 Date: Thu, 1 Sep 2005 15:36:33 -0700 From: Brooks Davis To: Jon Dama Message-ID: <20050901223633.GF4108@odin.ac.hmc.edu> References: <20050901212645.BE5615D07@ptavv.es.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="65ImJOski3p8EhYV" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: Jochen Gensch , freebsd-current@freebsd.org Subject: Re: Default route doesn't change to wireless device (ath0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2005 22:36:38 -0000 --65ImJOski3p8EhYV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 01, 2005 at 02:43:57PM -0700, Jon Dama wrote: > If the start_if.ath0 script isn't running, you should check that you have > removable_interfaces=3D"ath0" in rc.conf. Though, I saw some traffic that > say this was going away. Yup, it's dying. > Anyway, quoting Brooks in "HEADSUP: OpenBSD dhclient incoming" > "Second the pccard_ifconfig variable is only used as a default value for > interfaces that are on the removable_interfaces list, but do not have an > ifconfig_ variable. Third, interfaces must be on the > removable_interfaces list for pccard_ether to work." This is now wrong. I've nuked the pccard_ifconfig and added an ifconfig_DEFAULT variable which applies to all interfaces that don't have ifconfig_ variables (actually, it applies to those with empty ones as well at this point which is probably a bug.) > There should not be a need to modify devd.conf as there is already this > line: >=20 > attach 0 { > device-name "$ethernet-nic-regex"; > action "/etc/pccard_ether $device-name start"; > } >=20 > The regex does cover ath0, and pccard_ether should handle the event if the > interface is listed in removable_interfaces We've actually done away with the regex in HEAD and are using interface types so anything should work now. > I also saw some traffic from Brooks where he explicitly stated that > the new dhclient does not touch the default route if one is already > configured. afaik, this should not actually be a problem because start_if > is always run before dhclient has a change to start. Also I agree, it > would rather dangerous if dhclient just started flushing the routing > table. If you want to forcably set the default route via dhclient, you can do it via /etc/dhclient-exit-hooks which is executed when dhclient-script exits or you could write code to unset the current default route if the interface is down and put it in /etc/dhclient-enter-hooks. > Incidentially, I've seen this topic come up a dozen times + never knew > what do myself until Nate Lawson pointed me in the right direction a year > ago. At that time, he remarked that this stuff isn't documented any where > + it really should be in the handbook. >=20 > Can someone point me to where I should look for information on how to > contribute to the handbook in a format that is likely to be accepted? > > This is such a standard thing to want, it has to be done! You're probably looking for the doc project primer. http://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/index.html We're hoping to make route handling a bit more flexable in dhclient, but I haven't had time to work on it yet. -- Brooks > -Jon >=20 > On Thu, 1 Sep 2005, Kevin Oberman wrote: >=20 > > > Date: Thu, 1 Sep 2005 13:01:38 -0700 (PDT) > > > From: Jon Dama > > > Sender: owner-freebsd-current@freebsd.org > > > > > > Flush the routing table or at least delete the default entry in a > > > start_if.ath0 script. > > > > This is obvious, but does not answer the question: "Can't that be done > > automatically on plugging in either?" > > > > As I recall, when the OpenSSH dhclient was added, one of the things it > > was supposed to do was flush the routing table. This never seems to have > > happened and I'm not sure I'd want it to. > > > > Maybe devd could automate it? (I think I'm going to try that.) > > -- > > R. Kevin Oberman, Network Engineer > > Energy Sciences Network (ESnet) > > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > > E-mail: oberman@es.net Phone: +1 510 486-8634 > > > > > > > On Thu, 1 Sep 2005, Jochen Gensch wrote: > > > > > > > Hi! > > > > > > > > If I plug in my wireless nic (atheros) it comes up automatically th= rough > > > > wpa_supplicant. However the default route still points to my non wi= reless > > > > nic (fxp0) even if remove the network cable before plugging in the = wireless > > > > device. I have found no way around this, the only way of getting the > > > > default route changed to ath0 is setting in manually. Can't that be= done > > > > automatically on plugging in either? > > > _______________________________________________ > 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" --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --65ImJOski3p8EhYV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDF4FXXY6L6fI4GtQRAkz2AJ0Yvw37RkqjSUSvx4plODxMoDdjHgCdGXqy 9lLX7MizZ04CvAYIAmg2OQY= =upY/ -----END PGP SIGNATURE----- --65ImJOski3p8EhYV-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 22:42: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 539AB16A41F for ; Thu, 1 Sep 2005 22:42:33 +0000 (GMT) (envelope-from oberman@es.net) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F46D43D46 for ; Thu, 1 Sep 2005 22:42:32 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id IBA74465; Thu, 01 Sep 2005 15:42:31 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 402465D08; Thu, 1 Sep 2005 15:42:31 -0700 (PDT) To: Brooks Davis In-reply-to: Your message of "Thu, 01 Sep 2005 15:36:33 PDT." <20050901223633.GF4108@odin.ac.hmc.edu> Date: Thu, 01 Sep 2005 15:42:31 -0700 From: "Kevin Oberman" Message-Id: <20050901224231.402465D08@ptavv.es.net> Cc: Jochen Gensch , freebsd-current@freebsd.org Subject: Re: Default route doesn't change to wireless device (ath0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2005 22:42:33 -0000 > Date: Thu, 1 Sep 2005 15:36:33 -0700 > From: Brooks Davis > > > On Thu, Sep 01, 2005 at 02:43:57PM -0700, Jon Dama wrote: > > If the start_if.ath0 script isn't running, you should check that you have > > removable_interfaces="ath0" in rc.conf. Though, I saw some traffic that > > say this was going away. > > Yup, it's dying. > > > Anyway, quoting Brooks in "HEADSUP: OpenBSD dhclient incoming" > > "Second the pccard_ifconfig variable is only used as a default value for > > interfaces that are on the removable_interfaces list, but do not have an > > ifconfig_ variable. Third, interfaces must be on the > > removable_interfaces list for pccard_ether to work." > > This is now wrong. I've nuked the pccard_ifconfig and added an > ifconfig_DEFAULT variable which applies to all interfaces that don't > have ifconfig_ variables (actually, it applies to those with empty > ones as well at this point which is probably a bug.) > > > There should not be a need to modify devd.conf as there is already this > > line: > > > > attach 0 { > > device-name "$ethernet-nic-regex"; > > action "/etc/pccard_ether $device-name start"; > > } > > > > The regex does cover ath0, and pccard_ether should handle the event if the > > interface is listed in removable_interfaces > > We've actually done away with the regex in HEAD and are using interface > types so anything should work now. > > > I also saw some traffic from Brooks where he explicitly stated that > > the new dhclient does not touch the default route if one is already > > configured. afaik, this should not actually be a problem because start_if > > is always run before dhclient has a change to start. Also I agree, it > > would rather dangerous if dhclient just started flushing the routing > > table. > > If you want to forcably set the default route via dhclient, you can do > it via /etc/dhclient-exit-hooks which is executed when dhclient-script > exits or you could write code to unset the current default route if the > interface is down and put it in /etc/dhclient-enter-hooks. > > > Incidentially, I've seen this topic come up a dozen times + never knew > > what do myself until Nate Lawson pointed me in the right direction a year > > ago. At that time, he remarked that this stuff isn't documented any where > > + it really should be in the handbook. > > > > Can someone point me to where I should look for information on how to > > contribute to the handbook in a format that is likely to be accepted? > > > > This is such a standard thing to want, it has to be done! > > You're probably looking for the doc project primer. > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/index.html > > We're hoping to make route handling a bit more flexable in dhclient, but > I haven't had time to work on it yet. > > -- Brooks > > > -Jon > > > > On Thu, 1 Sep 2005, Kevin Oberman wrote: > > > > > > Date: Thu, 1 Sep 2005 13:01:38 -0700 (PDT) > > > > From: Jon Dama > > > > Sender: owner-freebsd-current@freebsd.org > > > > > > > > Flush the routing table or at least delete the default entry in a > > > > start_if.ath0 script. > > > > > > This is obvious, but does not answer the question: "Can't that be done > > > automatically on plugging in either?" > > > > > > As I recall, when the OpenSSH dhclient was added, one of the things it > > > was supposed to do was flush the routing table. This never seems to have > > > happened and I'm not sure I'd want it to. > > > > > > Maybe devd could automate it? (I think I'm going to try that.) > > > -- > > > R. Kevin Oberman, Network Engineer > > > Energy Sciences Network (ESnet) > > > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > > > E-mail: oberman@es.net Phone: +1 510 486-8634 > > > > > > > > > > On Thu, 1 Sep 2005, Jochen Gensch wrote: > > > > > > > > > Hi! > > > > > > > > > > If I plug in my wireless nic (atheros) it comes up automatically th> rough > > > > > wpa_supplicant. However the default route still points to my non wi> reless > > > > > nic (fxp0) even if remove the network cable before plugging in the > wireless > > > > > device. I have found no way around this, the only way of getting the > > > > > default route changed to ath0 is setting in manually. Can't that be> done > > > > > automatically on plugging in either? > > > > > _______________________________________________ > > 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" Thank you, Brooks! I had entirely forgotten the dhclient hooks. This will make it easy to do what I want. (I use Tobias Roth's profile, which allows files to be selected based on where I am when I boot my system.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 22:51:32 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 3FE6216A41F for ; Thu, 1 Sep 2005 22:51:32 +0000 (GMT) (envelope-from ertr1013@student.uu.se) Received: from pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD3F843D5D for ; Thu, 1 Sep 2005 22:51:31 +0000 (GMT) (envelope-from ertr1013@student.uu.se) Received: from falcon.midgard.homeip.net (212.181.162.201) by pne-smtpout1-sn2.hy.skanova.net (7.2.060.1) id 42BFBBD200B05BF0 for current@freebsd.org; Fri, 2 Sep 2005 00:51:29 +0200 Received: (qmail 58727 invoked by uid 1001); 2 Sep 2005 00:51:29 +0200 Date: Fri, 2 Sep 2005 00:51:28 +0200 From: Erik Trulsson To: Benjamin Lutz Message-ID: <20050901225128.GA52607@falcon.midgard.homeip.net> Mail-Followup-To: Benjamin Lutz , FreeBSD-Current References: <4317776C.9070307@datacomm.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4317776C.9070307@datacomm.ch> User-Agent: Mutt/1.5.9i Cc: FreeBSD-Current Subject: Re: installing ld-elf.so.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: Thu, 01 Sep 2005 22:51:32 -0000 On Thu, Sep 01, 2005 at 11:49:32PM +0200, Benjamin Lutz wrote: > Hello, > > While examining my system (FreeBSD 6.0-BETA3 amd64) and removing the old > libs from before the version bump, I noticed that the time stamp on > /libexec/ld-elf.so.1 does not match that of other system files. The date > leads me to believe that my current ld-elf.so.1 is a remainder of a > previous installation (its date matches the date of libm.so.3, which was > recently bumped to libm.so.4). That belief is most likely incorrect. ld-elf.so.1 is installed by 'install -C', and the -C flags for install(1) is documented as: -C Copy the file. If the target file already exists and the files are the same, then don't change the modification time of the tar- get. If the target's file flags and mode need not to be changed, the target's inode change time is also unchanged. I.e. the timestamp for ld-elf.so.1 will not match that of your other files, unless there there has actually been some changes to ld-elf.so.1 since your last install. > > While trying to figure out why the new ld-elf.so.1 (which appears to > have been built correctly) isn't installed. I finally arrived at this point: > > # cp -p /usr/obj/usr/src/libexec/rtld-elf/ld-elf.so.1 /libexec > cp: /libexec/ld-elf.so.1: Text file busy > # > > (This is in single user mode. The result is the same if I use > /rescue/cp, which is statically linked.) > > The open(2) manpage has this to say about it: > > [ETXTBSY] The file is a pure procedure (shared text) file that > is being executed and the open() system call requests > write access. > > So, my question: How can Install the new ld-elf.so.1? Rename or delete the old file, and then copy the new file (a file which is being executed cannot be modified, but it can be deleted.) This is most easily done by install(1), which is what 'make installworld' uses to to install files. -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 22:53:30 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 D8C0016A420 for ; Thu, 1 Sep 2005 22:53:30 +0000 (GMT) (envelope-from incmc@gmx.de) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id CB60743D6B for ; Thu, 1 Sep 2005 22:53:29 +0000 (GMT) (envelope-from incmc@gmx.de) Received: (qmail invoked by alias); 01 Sep 2005 22:53:28 -0000 Received: from dsl-084-061-011-192.arcor-ip.net (EHLO ms.homeip.net) [84.61.11.192] by mail.gmx.net (mp026) with SMTP; 02 Sep 2005 00:53:28 +0200 X-Authenticated: #15946415 Received: from p508f5bee.dip.t-dialin.net ([80.143.91.238] helo=nix-rechnername-auspaehen-hier) by ms.homeip.net with esmtpsa (SSLv3:RC4-MD5:128) id 1EAxw6-000ELo-D5; Fri, 02 Sep 2005 00:53:34 +0200 From: Jochen Gensch To: Jon Dama , freebsd-current@freebsd.org Date: Fri, 2 Sep 2005 00:52:54 +0200 User-Agent: KMail/1.8.2 References: <200509012149.26400.incmc@gmx.de> <431769A7.5000407@gmx.de> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509020052.55538.incmc@gmx.de> X-Y-GMX-Trusted: 0 Cc: Subject: Re: Default route doesn't change to wireless device (ath0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2005 22:53:31 -0000 Am Donnerstag 01 September 2005 23:31 schrieben Sie: > It should be sufficient to just > > echo 'route -n flush -inet' >> /etc/start_if.ath0 Doesn't work. Fxp0 still holds the deault route! I even tried a following "ifconfig fxp0 down" + "route add default 10.0.0.1". Jochen From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 22:54: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 C2EB416A41F for ; Thu, 1 Sep 2005 22:54:01 +0000 (GMT) (envelope-from jd@ugcs.caltech.edu) Received: from vomit.ugcs.caltech.edu (vomit.ugcs.caltech.edu [131.215.176.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C69143D7F for ; Thu, 1 Sep 2005 22:54:00 +0000 (GMT) (envelope-from jd@ugcs.caltech.edu) Received: by vomit.ugcs.caltech.edu (Postfix, from userid 3640) id 914B6E816; Thu, 1 Sep 2005 15:53:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by vomit.ugcs.caltech.edu (Postfix) with ESMTP id 6C68FE815; Thu, 1 Sep 2005 15:53:59 -0700 (PDT) Date: Thu, 1 Sep 2005 15:53:45 -0700 (PDT) From: Jon Dama To: Brooks Davis In-Reply-To: <20050901223633.GF4108@odin.ac.hmc.edu> Message-ID: References: <20050901212645.BE5615D07@ptavv.es.net> <20050901223633.GF4108@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Jochen Gensch , freebsd-current@freebsd.org Subject: Re: Default route doesn't change to wireless device (ath0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2005 22:54:01 -0000 Okay. Thanks for the info. But since -current still applies to 6-BETA users, I suspect some of my suggestions may still be valid depending on whether they are running something from 6.0 or actually running head. IMO, this should actually be a nonissue. The trouble is that the routing code does not do the right thing b.c. it should be possible to have multiple default routes used selectively based on (1) whether the interface is actually running, (2) the metric.... Hacking up dhclient to handle this issue does not seem like the right plan unless there really is no expectation that the routing situation will improve... -Jon On Thu, 1 Sep 2005, Brooks Davis wrote: > On Thu, Sep 01, 2005 at 02:43:57PM -0700, Jon Dama wrote: > > If the start_if.ath0 script isn't running, you should check that you have > > removable_interfaces="ath0" in rc.conf. Though, I saw some traffic that > > say this was going away. > > Yup, it's dying. > > > Anyway, quoting Brooks in "HEADSUP: OpenBSD dhclient incoming" > > "Second the pccard_ifconfig variable is only used as a default value for > > interfaces that are on the removable_interfaces list, but do not have an > > ifconfig_ variable. Third, interfaces must be on the > > removable_interfaces list for pccard_ether to work." > > This is now wrong. I've nuked the pccard_ifconfig and added an > ifconfig_DEFAULT variable which applies to all interfaces that don't > have ifconfig_ variables (actually, it applies to those with empty > ones as well at this point which is probably a bug.) > > > There should not be a need to modify devd.conf as there is already this > > line: > > > > attach 0 { > > device-name "$ethernet-nic-regex"; > > action "/etc/pccard_ether $device-name start"; > > } > > > > The regex does cover ath0, and pccard_ether should handle the event if the > > interface is listed in removable_interfaces > > We've actually done away with the regex in HEAD and are using interface > types so anything should work now. > > > I also saw some traffic from Brooks where he explicitly stated that > > the new dhclient does not touch the default route if one is already > > configured. afaik, this should not actually be a problem because start_if > > is always run before dhclient has a change to start. Also I agree, it > > would rather dangerous if dhclient just started flushing the routing > > table. > > If you want to forcably set the default route via dhclient, you can do > it via /etc/dhclient-exit-hooks which is executed when dhclient-script > exits or you could write code to unset the current default route if the > interface is down and put it in /etc/dhclient-enter-hooks. > > > Incidentially, I've seen this topic come up a dozen times + never knew > > what do myself until Nate Lawson pointed me in the right direction a year > > ago. At that time, he remarked that this stuff isn't documented any where > > + it really should be in the handbook. > > > > Can someone point me to where I should look for information on how to > > contribute to the handbook in a format that is likely to be accepted? > > > > This is such a standard thing to want, it has to be done! > > You're probably looking for the doc project primer. > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/index.html > > We're hoping to make route handling a bit more flexable in dhclient, but > I haven't had time to work on it yet. > > -- Brooks > > > -Jon > > > > On Thu, 1 Sep 2005, Kevin Oberman wrote: > > > > > > Date: Thu, 1 Sep 2005 13:01:38 -0700 (PDT) > > > > From: Jon Dama > > > > Sender: owner-freebsd-current@freebsd.org > > > > > > > > Flush the routing table or at least delete the default entry in a > > > > start_if.ath0 script. > > > > > > This is obvious, but does not answer the question: "Can't that be done > > > automatically on plugging in either?" > > > > > > As I recall, when the OpenSSH dhclient was added, one of the things it > > > was supposed to do was flush the routing table. This never seems to have > > > happened and I'm not sure I'd want it to. > > > > > > Maybe devd could automate it? (I think I'm going to try that.) > > > -- > > > R. Kevin Oberman, Network Engineer > > > Energy Sciences Network (ESnet) > > > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > > > E-mail: oberman@es.net Phone: +1 510 486-8634 > > > > > > > > > > On Thu, 1 Sep 2005, Jochen Gensch wrote: > > > > > > > > > Hi! > > > > > > > > > > If I plug in my wireless nic (atheros) it comes up automatically through > > > > > wpa_supplicant. However the default route still points to my non wireless > > > > > nic (fxp0) even if remove the network cable before plugging in the wireless > > > > > device. I have found no way around this, the only way of getting the > > > > > default route changed to ath0 is setting in manually. Can't that be done > > > > > automatically on plugging in either? > > > > > _______________________________________________ > > 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" > -- > Any statement of the form "X is the one, true Y" is FALSE. > PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 > From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 22:57: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 E8C8716A41F for ; Thu, 1 Sep 2005 22:57:16 +0000 (GMT) (envelope-from incmc@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 181BC43D48 for ; Thu, 1 Sep 2005 22:57:15 +0000 (GMT) (envelope-from incmc@gmx.de) Received: (qmail invoked by alias); 01 Sep 2005 22:57:15 -0000 Received: from dsl-084-061-011-192.arcor-ip.net (EHLO ms.homeip.net) [84.61.11.192] by mail.gmx.net (mp031) with SMTP; 02 Sep 2005 00:57:15 +0200 X-Authenticated: #15946415 Received: from p508f5bee.dip.t-dialin.net ([80.143.91.238] helo=nix-rechnername-auspaehen-hier) by ms.homeip.net with esmtpsa (SSLv3:RC4-MD5:128) id 1EAxzk-000ENT-1d; Fri, 02 Sep 2005 00:57:20 +0200 From: Jochen Gensch To: Brooks Davis , freebsd-current@freebsd.org Date: Fri, 2 Sep 2005 00:56:42 +0200 User-Agent: KMail/1.8.2 References: <20050901212645.BE5615D07@ptavv.es.net> <20050901214113.GE4108@odin.ac.hmc.edu> In-Reply-To: <20050901214113.GE4108@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509020056.42733.incmc@gmx.de> X-Y-GMX-Trusted: 0 Cc: Subject: Re: Default route doesn't change to wireless device (ath0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2005 22:57:17 -0000 Am Donnerstag 01 September 2005 23:41 schrieben Sie: > Right now, we refuse to modify the default route if another interface > has it, but the expected behavior is probably to modify it even if it's > on another interface if that interface is down. Yes, that actually is, what I expected to happen. However fxp0 seems to hold the deault route, even if the cable has been removed. Jochen From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 23: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 66FE516A41F for ; Thu, 1 Sep 2005 23:27:20 +0000 (GMT) (envelope-from incmc@gmx.de) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id A015A43D48 for ; Thu, 1 Sep 2005 23:27:19 +0000 (GMT) (envelope-from incmc@gmx.de) Received: (qmail invoked by alias); 01 Sep 2005 23:27:18 -0000 Received: from dsl-084-061-011-192.arcor-ip.net (EHLO ms.homeip.net) [84.61.11.192] by mail.gmx.net (mp033) with SMTP; 02 Sep 2005 01:27:18 +0200 X-Authenticated: #15946415 Received: from p508f5bee.dip.t-dialin.net ([80.143.91.238] helo=nix-rechnername-auspaehen-hier) by ms.homeip.net with esmtpsa (SSLv3:RC4-MD5:128) id 1EAySq-000Ea9-0P for freebsd-current@freebsd.org; Fri, 02 Sep 2005 01:27:24 +0200 From: Jochen Gensch To: freebsd-current@freebsd.org Date: Fri, 2 Sep 2005 01:26:45 +0200 User-Agent: KMail/1.8.2 References: <20050901225346.0923E16A41F@hub.freebsd.org> In-Reply-To: <20050901225346.0923E16A41F@hub.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509020126.45337.incmc@gmx.de> X-Y-GMX-Trusted: 0 Subject: Re: freebsd-current Digest, Vol 112, Issue 11 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2005 23:27:20 -0000 Am Freitag 02 September 2005 00:53 schrieb > Right now, we refuse to modify the default route if another interface > has it, but the expected behavior is probably to modify it even if it's > on another interface if that interface is down. Something else: does that mean, once a non removable nic got the default route it cannot be changed again? At least it seems like I'm experiencing that here (Even though I tried so many different ways now, that I'm not too sure about that any more, lol). > If the start_if.ath0 script isn't running, you should check that you have > removable_interfaces="ath0" in rc.conf. Though, I saw some traffic that > say this was going away. > > Anyway, quoting Brooks in "HEADSUP: OpenBSD dhclient incoming" > "Second the pccard_ifconfig variable is only used as a default value for > interfaces that are on the removable_interfaces list, but do not have an > ifconfig_ variable. Third, interfaces must be on the > removable_interfaces list for pccard_ether to work." Yes, rc.conf looks as follows: -------------------------------- background_dhclient="YES" ifconfig_fxp0="DHCP" ifconfig_ath0="WPA DHCP" removable_interfaces="ath0" However, as I'm not too familiar with things like "pccard_ifconfig variable" it is difficult to follow you szenario. But it seems, that start_if.ath0 shouldn't run since ath0 has an ifconfig_ath0 entry here for wpa_supplicant. > There should not be a need to modify devd.conf as there is already this > line: > > attach 0 { > device-name "$ethernet-nic-regex"; > action "/etc/pccard_ether $device-name start"; > } Yep, I saw that right after your first reply. > I also saw some traffic from Brooks where he explicitly stated that > the new dhclient does not touch the default route if one is already > configured. afaik, this should not actually be a problem because start_if > is always run before dhclient has a change to start. Also I agree, it > would rather dangerous if dhclient just started flushing the routing > table. But it needs to be configurable somewhere. As I understand it now I cannot use start_if.ath0 since it has a (mandatory) ifconfig_if entry in rc.conf related to wpa_supplicant. Therefore one needs to hack it in somewhere by hand. > This is such a standard thing to want, it has to be done! Agreed :-) Jochen From owner-freebsd-current@FreeBSD.ORG Fri Sep 2 00:14:38 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 D324116A41F for ; Fri, 2 Sep 2005 00:14:38 +0000 (GMT) (envelope-from oberman@es.net) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F57343D58 for ; Fri, 2 Sep 2005 00:14:38 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id IBA74465; Thu, 01 Sep 2005 17:14:37 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id A43645D07; Thu, 1 Sep 2005 17:14:36 -0700 (PDT) To: Jochen Gensch In-reply-to: Your message of "Fri, 02 Sep 2005 01:26:45 +0200." <200509020126.45337.incmc@gmx.de> Date: Thu, 01 Sep 2005 17:14:36 -0700 From: "Kevin Oberman" Message-Id: <20050902001436.A43645D07@ptavv.es.net> Cc: freebsd-current@freebsd.org Subject: Re: Default route doesn't change to wireless device (ath0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2005 00:14:39 -0000 > From: Jochen Gensch > Date: Fri, 2 Sep 2005 01:26:45 +0200 > Sender: owner-freebsd-current@freebsd.org > > Am Freitag 02 September 2005 00:53 schrieb > > > Right now, we refuse to modify the default route if another interface > > has it, but the expected behavior is probably to modify it even if it's > > on another interface if that interface is down. > > Something else: does that mean, once a non removable nic got the default route > it cannot be changed again? At least it seems like I'm experiencing that here > (Even though I tried so many different ways now, that I'm not too sure about > that any more, lol). > > > > If the start_if.ath0 script isn't running, you should check that you have > > removable_interfaces="ath0" in rc.conf. Though, I saw some traffic that > > say this was going away. > > > > Anyway, quoting Brooks in "HEADSUP: OpenBSD dhclient incoming" > > "Second the pccard_ifconfig variable is only used as a default value for > > interfaces that are on the removable_interfaces list, but do not have an > > ifconfig_ variable. Third, interfaces must be on the > > removable_interfaces list for pccard_ether to work." > > Yes, rc.conf looks as follows: > -------------------------------- > background_dhclient="YES" > ifconfig_fxp0="DHCP" > ifconfig_ath0="WPA DHCP" > removable_interfaces="ath0" > > However, as I'm not too familiar with things like "pccard_ifconfig variable" > it is difficult to follow you szenario. But it seems, that start_if.ath0 > shouldn't run since ath0 has an ifconfig_ath0 entry here for wpa_supplicant. > > > > There should not be a need to modify devd.conf as there is already this > > line: > > > > attach 0 { > > device-name "$ethernet-nic-regex"; > > action "/etc/pccard_ether $device-name start"; > > } > > Yep, I saw that right after your first reply. > > > > I also saw some traffic from Brooks where he explicitly stated that > > the new dhclient does not touch the default route if one is already > > configured. afaik, this should not actually be a problem because start_if > > is always run before dhclient has a change to start. Also I agree, it > > would rather dangerous if dhclient just started flushing the routing > > table. > > But it needs to be configurable somewhere. As I understand it now I cannot use > start_if.ath0 since it has a (mandatory) ifconfig_if entry in rc.conf related > to wpa_supplicant. Therefore one needs to hack it in somewhere by hand. > > > > This is such a standard thing to want, it has to be done! > > Agreed :-) I do the command 'route flush' quite routinely and it seems to work for me. I just tried it on my laptop with the fxp0 interface still up and it deleted default just fine. Did dhclient assign the default? Mine was static. Perhaps the flush works, but dhclient is putting it back in. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-current@FreeBSD.ORG Fri Sep 2 00:39: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 32FF216A420; Fri, 2 Sep 2005 00:39:52 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCFB543D46; Fri, 2 Sep 2005 00:39:51 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id j820dcst021990; Thu, 1 Sep 2005 17:39:42 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200509020039.j820dcst021990@gw.catspoiler.org> Date: Thu, 1 Sep 2005 17:39:38 -0700 (PDT) From: Don Lewis To: jhb@FreeBSD.org In-Reply-To: <200509011332.24342.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org, rwatson@FreeBSD.org, dandee@volny.cz, bzeeb-lists@lists.zabbadoz.net, fli+freebsd-current@shapeshifter.se, imp@bsdimp.com Subject: Re: LOR route vr0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2005 00:39:52 -0000 On 1 Sep, John Baldwin wrote: > On Thursday 01 September 2005 01:22 pm, Don Lewis wrote: >> On 1 Sep, Fredrik Lindberg wrote: >> > I'm seeing both the rentry and the tcpinp LORs on my fxp interface >> > on a machine running a few days old -current (Aug 25). >> > >> > lock order reversal >> > 1st 0xc1e30d38 inp (tcpinp) @ /usr/src/sys/netinet/tcp_input.c:742 >> > 2nd 0xc1b74018 fxp0 (network driver) @/usr/src/sys/dev/fxp/if_fxp.c:1172 >> > >> > lock order reversal >> > 1st 0xc1e06bb8 rtentry (rtentry) @ /usr/src/sys/net/route.c:1269 >> > 2nd 0xc1b74018 fxp0 (network driver) @/usr/src/sys/dev/fxp/if_fxp.c:1172 >> > >> > As for their backtraces they are almost identical to the >> > once already posted. >> >> Are you using any applications that use multicast? Can you break into >> DDB and capture the output of "show witness"? > > Also, are you using DEVICE_POLLING? I can reproduce this if I add DEVICE_POLLING to my kernel. And I see Giant under "network driver" in the output of "show witness". If I apply your witness patch: http://www.FreeBSD.org/~jhb/patches/witness.patch then I get the following LOR: lock order reversal 1st 0xc23e2018 fxp0 (network driver) @ /usr/src/sys/dev/fxp/if_fxp.c:1907 2nd 0xc09387e0 Giant (Giant) @ /usr/src/sys/kern/kern_poll.c:460 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c0946470,c0947f28,c08d3a84) at kdb_backtrace+0x29 witness_checkorder(c09387e0,9,c086d0d3,1cc) at witness_checkorder+0x53c _mtx_lock_flags(c09387e0,0,c086d0d3,1cc) at _mtx_lock_flags+0x5b ether_poll_deregister(c23de000,c23e2000,c23e2018,0,e9295b60) at ether_poll_deregister+0x1d fxp_stop(c23e2000,c23e2018,1,c084c9ff,787) at fxp_stop+0x21 fxp_init_body(c23e2000,c23e2018,0,c084c9ff,773) at fxp_init_body+0x31 fxp_init(c23e2000,8020690c,c23e2000,c264bb00,e9295bc0) at fxp_init+0x23 ether_ioctl(c23de000,8020690c,c264bb00,0,c264bb00) at ether_ioctl+0x50 fxp_ioctl(c23de000,8020690c,c264bb00,1,c0a86503) at fxp_ioctl+0x232 in_ifinit(c23de000,c264bb00,c24b3490,0,e9295c38) at in_ifinit+0x206 in_control(c270fde8,8040691a,c24b3480,c23de000,c248e900) at in_control+0x882 ifioctl(c270fde8,8040691a,c24b3480,c248e900,0) at ifioctl+0x198 soo_ioctl(c2647dc8,8040691a,c24b3480,c2271d00,c248e900) at soo_ioctl+0x2db ioctl(c248e900,e9295d04,3,1,286) at ioctl+0x370 syscall(3b,3b,3b,8056e40,8059140) at syscall+0x22f Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x48136e4b, esp = 0xbfbfe5ec, ebp = 0xbfbfee38 --- fxp0: link state changed to UP I also get another LOR: cd0: Attempt to query device size failed: NOT READY, Medium not present lock order reversal 1st 0xe35e0cc4 g_xdown (g_xdown) @ /usr/src/sys/geom/geom_io.c:465 2nd 0xc09387e0 Giant (Giant) @ /usr/src/sys/geom/geom_disk.c:99 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c0945e30,c0947f28,c08d3a84) at kdb_backtrace+0x29 witness_checkorder(c09387e0,9,c0866bc0,63) at witness_checkorder+0x53c _mtx_lock_flags(c09387e0,0,c0866bc0,63) at _mtx_lock_flags+0x5b g_disk_start(c2632a50,e35e0cc4,0,c086722e,1d1) at g_disk_start+0x152 g_io_schedule_down(c2275480) at g_io_schedule_down+0x160 g_down_procbody(0,e35e0d38,0,c0606960,0) at g_down_procbody+0x5a fork_exit(c0606960,0,e35e0d38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe35e0d6c, ebp = 0 --- Trying to mount root from ufs:/dev/da0s1a From owner-freebsd-current@FreeBSD.ORG Fri Sep 2 01:52: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 D4B7B16A41F for ; Fri, 2 Sep 2005 01:52:43 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D0F743D46 for ; Fri, 2 Sep 2005 01:52:43 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j821qg2Q024873; Thu, 1 Sep 2005 18:52:42 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j821qgPi024872; Thu, 1 Sep 2005 18:52:42 -0700 Date: Thu, 1 Sep 2005 18:52:42 -0700 From: Brooks Davis To: Jochen Gensch Message-ID: <20050902015242.GJ4108@odin.ac.hmc.edu> References: <20050901225346.0923E16A41F@hub.freebsd.org> <200509020126.45337.incmc@gmx.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BOmey7/79ja+7F5w" Content-Disposition: inline In-Reply-To: <200509020126.45337.incmc@gmx.de> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: freebsd-current@freebsd.org Subject: Re: freebsd-current Digest, Vol 112, Issue 11 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2005 01:52:44 -0000 --BOmey7/79ja+7F5w Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 02, 2005 at 01:26:45AM +0200, Jochen Gensch wrote: > Am Freitag 02 September 2005 00:53 schrieb=20 >=20 > > Right now, we refuse to modify the default route if another interface > > has it, but the expected behavior is probably to modify it even if it's > > on another interface if that interface is down. >=20 > Something else: does that mean, once a non removable nic got the default = route=20 > it cannot be changed again? At least it seems like I'm experiencing that = here=20 > (Even though I tried so many different ways now, that I'm not too sure ab= out=20 > that any more, lol). No. Just that dhclient won't do it. > > If the start_if.ath0 script isn't running, you should check that you ha= ve > > removable_interfaces=3D"ath0" in rc.conf. Though, I saw some traffic t= hat > > say this was going away. > > > > Anyway, quoting Brooks in "HEADSUP: OpenBSD dhclient incoming" > > "Second the pccard_ifconfig variable is only used as a default value for > > interfaces that are on the removable_interfaces list, but do not have an > > ifconfig_ variable. Third, interfaces must be on the > > removable_interfaces list for pccard_ether to work." >=20 > Yes, rc.conf looks as follows: > -------------------------------- > background_dhclient=3D"YES" > ifconfig_fxp0=3D"DHCP" > ifconfig_ath0=3D"WPA DHCP" > removable_interfaces=3D"ath0" >=20 > However, as I'm not too familiar with things like "pccard_ifconfig variab= le"=20 > it is difficult to follow you szenario. But it seems, that start_if.ath0= =20 > shouldn't run since ath0 has an ifconfig_ath0 entry here for wpa_supplica= nt. > > > There should not be a need to modify devd.conf as there is already this > > line: > > > > attach 0 { > > device-name "$ethernet-nic-regex"; > > action "/etc/pccard_ether $device-name start"; > > } >=20 > Yep, I saw that right after your first reply. >=20 >=20 > > I also saw some traffic from Brooks where he explicitly stated that > > the new dhclient does not touch the default route if one is already > > configured. afaik, this should not actually be a problem because start= _if > > is always run before dhclient has a change to start. Also I agree, it > > would rather dangerous if dhclient just started flushing the routing > > table. >=20 > But it needs to be configurable somewhere. As I understand it now I canno= t use=20 > start_if.ath0 since it has a (mandatory) ifconfig_if entry in rc.conf rel= ated=20 > to wpa_supplicant. Therefore one needs to hack it in somewhere by hand. This is not the issue. I have no idea where you got the idea that having an ifconfig_ entry has anyting to do with start_if.ath0 running. The issue is that start_if.ath0 always runs at boot or when you insert the card, but not when you get a lease. If you want to take an action when you get a lease, you need to do it in the dhclient hooks. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --BOmey7/79ja+7F5w Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDF7BpXY6L6fI4GtQRAnR6AJ0djNg8obt2yenRlxC00STo3x7u2wCgoc4g AWQjgQBVJC4INee/mqKH+zk= =H/67 -----END PGP SIGNATURE----- --BOmey7/79ja+7F5w-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 2 03:25:13 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 CC58216A41F for ; Fri, 2 Sep 2005 03:25:13 +0000 (GMT) (envelope-from robbak@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19A9B43D46 for ; Fri, 2 Sep 2005 03:25:12 +0000 (GMT) (envelope-from robbak@gmail.com) Received: by wproxy.gmail.com with SMTP id i4so470456wra for ; Thu, 01 Sep 2005 20:25:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RwzN4wnwqBXJeWWVkQTrHKiVyB29sC51U/xHa8/E1XuKsndDMuPO5Y7ZCSbluSqWew3XVjvDwCEWfIMgri4m1924nbDkQArAOxtdRN57bGJfRahmt9FykTNPO56Rr+EIShuVbOkKcMLinf1WFxTR1HiY2hoEtbVSPRJAbYdG2f8= Received: by 10.54.118.13 with SMTP id q13mr2172823wrc; Thu, 01 Sep 2005 20:25:11 -0700 (PDT) Received: by 10.54.128.12 with HTTP; Thu, 1 Sep 2005 20:25:11 -0700 (PDT) Message-ID: Date: Fri, 2 Sep 2005 03:25:11 +0000 From: Robert Backhaus To: Gregory Nou In-Reply-To: <4316E1A0.8070307@altern.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4316E1A0.8070307@altern.org> Cc: freebsd-current@freebsd.org Subject: Re: Problem with deleting files X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2005 03:25:13 -0000 On 9/1/05, Gregory Nou wrote: > Hi, >=20 > I'm currently experiencing a weird problem : some of my folders are > completely empty (ls -a doesn't even mention . or ..) > But, I cannot remove them, and a ls is very very slow (but just in those > folders, and it is quite rare, but now I cannot update firefox, nor > openoffice, because make clean will fail). >=20 This will happen if you try to delete folders while background fsck is operating. The files are being retained in the "snapshot" of the disk that fsck is cleaning. It will go away once the filesystem checks are finished. You can watch the progress of fstab with "ps -waux |grep fsck". From owner-freebsd-current@FreeBSD.ORG Fri Sep 2 03:52: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 C9E9F16A420; Fri, 2 Sep 2005 03:52:29 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7571743D49; Fri, 2 Sep 2005 03:52:29 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id j823qKm9022255; Thu, 1 Sep 2005 20:52:24 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200509020352.j823qKm9022255@gw.catspoiler.org> Date: Thu, 1 Sep 2005 20:52:20 -0700 (PDT) From: Don Lewis To: jhb@FreeBSD.org In-Reply-To: <200509011346.32361.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: rwatson@FreeBSD.org, current@FreeBSD.org Subject: Re: Witness 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, 02 Sep 2005 03:52:29 -0000 On 1 Sep, John Baldwin wrote: > This patch forces witness to complain if any mutex is held when Giant is > locked to enforce Giant being the first mutex in the lock order. This might > help track down some of the network LORs being reported recently. > > http://www.FreeBSD.org/~jhb/patches/witness.patch I think it would make sense to print different messages for the different trigger conditions. From owner-freebsd-current@FreeBSD.ORG Fri Sep 2 07:49: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 54EC116A41F for ; Fri, 2 Sep 2005 07:49:46 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from leto.uk.clara.net (leto.uk.clara.net [80.168.69.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFA9143D45 for ; Fri, 2 Sep 2005 07:49:45 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from bloodhound.noc.clara.net ([195.8.70.207]) by leto.uk.clara.net with esmtp (Exim 4.43) id 1EB6Iy-0005M8-VF; Fri, 02 Sep 2005 08:49:44 +0100 Received: from personal by bloodhound.noc.clara.net with local (Exim 4.50 (FreeBSD)) id 1EB6JM-000GDM-Ly; Fri, 02 Sep 2005 08:50:08 +0100 Date: Fri, 2 Sep 2005 08:50:08 +0100 From: Brian Candler To: Boris Samorodov Message-ID: <20050902075008.GA62280@uk.tiscali.com> References: <20050831130543.C22426@f1> <31776986@srv.sem.ipt.ru> <20050901130719.GB54918@uk.tiscali.com> <74646630@srv.sem.ipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <74646630@srv.sem.ipt.ru> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org, Jason George Subject: Re: 6.0-BETA3 and Asterisk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2005 07:49:46 -0000 On Thu, Sep 01, 2005 at 06:36:57PM +0400, Boris Samorodov wrote: > > > AFAIK just before BETA3 system libraries were bumpted. One should > > > rebuild ports after upgrading the system from earlier one. Is it your > > > case? > > > Can mismatched library versions really cause kernel panics?? > > Can't say for sure. But lets solve problems by steps. Using different > system libraries simultaneously is not right (we don't have compat-5x). I disagree strongly. If the OP's system suffers a kernel panic, it's a kernel problem which *needs* to be fixed. Otherwise the system is open to a trivial denial-of-service attack: any userland program can replicate whatever any library does to trigger the panic. If upgrading the libraries did make the problem go away (which I doubt in this case), then the OP might have a working system, but the stability of FreeBSD as a whole would be the worse for it. Regards, Brian. From owner-freebsd-current@FreeBSD.ORG Fri Sep 2 08:04: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 DCA8C16A41F for ; Fri, 2 Sep 2005 08:04:18 +0000 (GMT) (envelope-from incmc@gmx.de) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 0C64E43D53 for ; Fri, 2 Sep 2005 08:04:17 +0000 (GMT) (envelope-from incmc@gmx.de) Received: (qmail invoked by alias); 02 Sep 2005 08:04:16 -0000 Received: from dsl-084-061-011-192.arcor-ip.net (EHLO ms.homeip.net) [84.61.11.192] by mail.gmx.net (mp029) with SMTP; 02 Sep 2005 10:04:16 +0200 X-Authenticated: #15946415 Received: from p508f5bee.dip.t-dialin.net ([80.143.91.238] helo=nix-rechnername-auspaehen-hier) by ms.homeip.net with esmtpsa (SSLv3:RC4-MD5:128) id 1EB6X0-000L0T-Bq; Fri, 02 Sep 2005 10:04:14 +0200 From: Jochen Gensch To: Brooks Davis , freebsd-current@freebsd.org Date: Fri, 2 Sep 2005 10:03:39 +0200 User-Agent: KMail/1.8.2 References: <20050901225346.0923E16A41F@hub.freebsd.org> <200509020126.45337.incmc@gmx.de> <20050902015242.GJ4108@odin.ac.hmc.edu> In-Reply-To: <20050902015242.GJ4108@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Disposition: inline X-UID: 1 X-Length: 2202 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200509021003.39863.incmc@gmx.de> X-Y-GMX-Trusted: 0 Cc: Subject: Re: Default route doesn't change to wireless device (ath0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2005 08:04:19 -0000 Am Freitag 02 September 2005 03:52 schrieben Sie: > The issue is that start_if.ath0 always runs at boot or when > you insert the card, but not when you get a lease. If you want to take > an action when you get a lease, you need to do it in the dhclient hooks. I cannot manage to get ath0 up properly. If dhclient doesn't change the default route again, once a device got it one should be able to do it by hand. So when I bootet the system was running on fxp0. Then I did the followiing: SU NB /:route -n flush -inet default 10.0.0.1 done 10.0.0.104 127.0.0.1 done [REMOVED network cable from fxp0] [Pluged in wireless nic ath0] SU NB /:ping i-mc.de PING i-mc.de (213.203.199.12): 56 data bytes ping: sendto: No route to host ^C --- i-mc.de ping statistics --- 2 packets transmitted, 0 packets received, 100% packet loss [OK, routes have not been corrected yet] SU NB /:route add default 10.0.0.1 route: writing to routing socket: File exists add net default: gateway 10.0.0.1: File exists [Why does that route sitll exist, it has been deleted above] SU NB /:ping i-mc.de ^C SU NB /:route delete default delete net default SU NB /:route add default 10.0.0.1 add net default: gateway 10.0.0.1 SU NB /:ping i-mc.de ^C I cannot set the routes to ath0 once fxp0 was active. I guess I must still be misunderstandung what you guys are saying / doing. Jochen From owner-freebsd-current@FreeBSD.ORG Fri Sep 2 09:43: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 1C63716A420 for ; Fri, 2 Sep 2005 09:43:16 +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 840F443D4C for ; Fri, 2 Sep 2005 09:43:15 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from 217-13-2-82.dd.nextgentel.com ([217.13.2.82] helo=h311r4z3r) by mail.yazzy.org with esmtps (TLSv1:AES256-SHA:256) (YazzY.org) id 1EB84N-0002yJ-TK; Fri, 02 Sep 2005 11:42:50 +0200 Date: Fri, 2 Sep 2005 11:43:09 +0200 From: Marcin Jessa To: dandee@volny.cz Message-Id: <20050902114309.5582887e.lists@yazzy.org> In-Reply-To: <20050830185851.ECF554E704@pipa.profix.cz> References: <20050830185851.ECF554E704@pipa.profix.cz> Organization: YazzY.org X-Mailer: Sylpheed version 2.0.0 (GTK+ 2.6.8; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.6 (--) Cc: dandee@hellteam.net, freebsd-current@freebsd.org Subject: Re: Application layer firewall on FreeBSD, is it possible ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2005 09:43:16 -0000 Maybe this can help as well: http://jk.yazzy.org/openbsd/kazaa.php On Tue, 30 Aug 2005 20:58:44 +0200 Daniel Dvořák wrote: > Hi all, > > let me ask you for task "how to control p2p applications and their traffic > with dynamic ports from user´s commputers on gateway". > > We are small wireless community and have shared access to internet for all > members. Core members decided to control p2p traffic by default and to allow > each person in individual way, > after showing their knowledge of authorial low. :) > > But since many dc hubs, edonkey servers, bittorents web trackers and so on > use dynamic not standard ports, how to control it ? > > Linux use l7-filter http://sourceforge.net/projects/l7-filter > sourceforge freeware > and , it is based on iptables, defination application protocols like > ethereal project do. > > So, is there any way to do same application layer osi model firewall with > FreeBSD gateway ? > > Of course, I tried to find on web, I have not been successful in searching > so far. > > If my question is not right in this mailing list, if my question is annoying > here, so I am sorry. > > Dan > _______________________________________________ > 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 Fri Sep 2 11:58: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 06AF816A41F for ; Fri, 2 Sep 2005 11:58:51 +0000 (GMT) (envelope-from dreamer2@tikhvin.info) Received: from mail.lsi.ru (mail.lsi.ru [212.58.192.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CE7943D46 for ; Fri, 2 Sep 2005 11:58:50 +0000 (GMT) (envelope-from dreamer2@tikhvin.info) Received: by mail.lsi.ru (Postfix, from userid 426) id 4841A386FED; Fri, 2 Sep 2005 15:58:48 +0400 (MSD) Received: from [192.168.8.101] (unknown [212.58.217.41]) by mail.lsi.ru (Postfix) with ESMTP id 57A3B386FB5; Fri, 2 Sep 2005 15:58:46 +0400 (MSD) Message-ID: <43183E7D.50802@tikhvin.info> Date: Fri, 02 Sep 2005 15:58:53 +0400 From: Vitaly User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: ru-ru, ru MIME-Version: 1.0 To: Sam Leffler , freebsd-current@freebsd.org References: <430060FB.1000405@tikhvin.info> <4314537C.5050808@tikhvin.info> <4314A32A.9050105@errno.com> In-Reply-To: <4314A32A.9050105@errno.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: ath bridge panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2005 11:58:51 -0000 > > Still exists with what version of the system? If you haven't tried > BETA3 then do that first. > > To get something like this fixed you need to provide the steps needed > to reproduce the problem. > I tried BETA3, while client authentification in progress i get error messages but after all ok without panic ath0: device timeout ath0: device timeout ath0: device timeout ath0: device timeout couldn't m_pullup couldn't m_pullup couldn't m_pullup couldn't m_pullup couldn't m_pullup .... but i have another problem here - 80211b PDA client success communicates with another 80211g client, but not with 80211b client what debug modes i must set to athdebug to view activity with this problem sorry for bad english :( From owner-freebsd-current@FreeBSD.ORG Fri Sep 2 12:00: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 F286816A434 for ; Fri, 2 Sep 2005 12:00:40 +0000 (GMT) (envelope-from ofsen@enderunix.org) Received: from istanbul.enderunix.org (freefall.marmara.edu.tr [193.140.143.23]) by mx1.FreeBSD.org (Postfix) with SMTP id CC44E43D45 for ; Fri, 2 Sep 2005 12:00:39 +0000 (GMT) (envelope-from ofsen@enderunix.org) Received: (qmail 82690 invoked by uid 89); 2 Sep 2005 12:01:14 -0000 X-Mail-Scanner: Scanned by qSheff 1.0-r1 (http://www.enderunix.org/qsheff/) Message-ID: <20050902120114.82685.qmail@istanbul.enderunix.org> From: Omer Faruk Sen To: freebsd-current@freebsd.org Date: Fri, 02 Sep 2005 15:01:14 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-9" Content-Transfer-Encoding: 7bit Subject: kgdb core dumps X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2005 12:00:41 -0000 Hi, I am trying to remote dump but I get the following erros. The kernel.debug is the file that I copied to my host system from target (remote). Why I am getting that error? Is there anything that I can do. What I have done is: 1) boot system with a kernel (target) 2) set 0x80 in device.hints on target 3) Copy kernel.debug from target to host 4) CTRL-ALT-ESC on target 5) kgdb -r /dev/cuad0 /boot/kernel/kernel.debug on host and I get the following error. By the way with the src/ that comes with 6.0BETA-3 I can't get any output using kgdb -r /dev/cuad0 /boot/kernel/kernel.debug. I have cvsup'ed my source files yesterday but now I get these errors: root@balli# kgdb -r /dev/cuad0 /boot/kernel/kernel.debug [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". Switching to remote protocol 0xc064ad9b in kdb_enter (msg=0x26
) at cpufunc.h:60 60 cpufunc.h: No such file or directory. in cpufunc.h Segmentation fault: 11 (core dumped) ----------------------- Omer Faruk Sen http://www.EnderUNIX.ORG Software Development Team @ Turkey http://www.Faruk.NET For Public key: http://www.enderunix.org/ofsen/ofsen.asc ******************************************************** First Turkish Qmail book is out! Go check it. Duydunuz mu! Turkiye'nin ilk Qmail kitabi cikti. http://www.acikakademi.com/catalog/qmail/ From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 13:15: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 4B6B816A420 for ; Thu, 1 Sep 2005 13:15:27 +0000 (GMT) (envelope-from edwin.brown@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C0FB43D46 for ; Thu, 1 Sep 2005 13:15:24 +0000 (GMT) (envelope-from edwin.brown@gmail.com) Received: by zproxy.gmail.com with SMTP id 8so219711nzo for ; Thu, 01 Sep 2005 06:15:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=jUVibjdNeeznYb90udOjncWsWLsDYxGdhXzgtVDyryxNqvZZEdUubGKJ6+T+nIiXrKd7i+K7Q/IJY9Db04kzk6g6r2xKPbHL8QVJ0Z3eMCPzKJWadD560h1v6ZeQkzhfqBOdHAV0f86r0a0BPC/vDoxGfFL/uv8XjyWP0ufKWL8= Received: by 10.36.17.7 with SMTP id 7mr1538543nzq; Thu, 01 Sep 2005 06:14:53 -0700 (PDT) Received: by 10.36.61.10 with HTTP; Thu, 1 Sep 2005 06:15:08 -0700 (PDT) Message-ID: <8b6eae9605090106151a81174d@mail.gmail.com> Date: Thu, 1 Sep 2005 09:15:08 -0400 From: Edwin Brown To: freebsd-stable@freebsd.org, freebsd-current@freebsd.org Mime-Version: 1.0 X-Mailman-Approved-At: Fri, 02 Sep 2005 12:01:56 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: FreeBSD6.0 and VMWare 5.0.. No go X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2005 13:15:27 -0000 This morning I tried to install FreeBSD6.0 under VMWare 5. I got=20 the following message when it was extracting the base into \=20 directory: Panic: duplicate free of item 0xc1c5a210 from zone 0xc143f000(g_bio) cpuid=3D0 KDB: enter: panic [thread pid 3 tid 100034 ] stopped at kdb_enter+0x2b: nop db>=20 Is this a known issue?=20 Best regards, Edwin From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 23:15: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 101AF16A41F for ; Thu, 1 Sep 2005 23:15:42 +0000 (GMT) (envelope-from lists@masterplan.org) Received: from corona.resourcechain.com (207-34-127-10.ip.cal.radiant.net [207.34.127.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DE8243D53 for ; Thu, 1 Sep 2005 23:15:41 +0000 (GMT) (envelope-from lists@masterplan.org) Received: from f1.masterplan.org (S01060800200525a9.cg.shawcable.net [68.144.69.51]) by corona.resourcechain.com (8.13.3/8.13.3) with ESMTP id j81NFZdR022839; Thu, 1 Sep 2005 17:15:36 -0600 (MDT) (envelope-from lists@masterplan.org) Received: from f1.masterplan.org (localhost [127.0.0.1]) by f1.masterplan.org (8.13.3/8.13.3) with ESMTP id j81NFSf2025335; Thu, 1 Sep 2005 17:15:28 -0600 (MDT) (envelope-from lists@masterplan.org) Received: from localhost (lists@localhost) by f1.masterplan.org (8.13.3/8.13.3/Submit) with ESMTP id j81NFRDX025332; Thu, 1 Sep 2005 17:15:27 -0600 (MDT) (envelope-from lists@masterplan.org) X-Authentication-Warning: f1.masterplan.org: lists owned process doing -bs Date: Thu, 1 Sep 2005 17:15:27 -0600 (MDT) From: Jason George X-X-Sender: lists@f1 To: Boris Samorodov In-Reply-To: <74646630@srv.sem.ipt.ru> Message-ID: <20050901170053.H25305@f1> References: <20050831130543.C22426@f1> <31776986@srv.sem.ipt.ru> <20050901130719.GB54918@uk.tiscali.com> <74646630@srv.sem.ipt.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, score=0.2 required=5.0 tests=FORGED_RCVD_HELO, RCVD_IN_SORBS_DUL autolearn=no version=3.0.3 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on corona.resourcechain.com X-Mailman-Approved-At: Fri, 02 Sep 2005 12:01:56 +0000 Cc: freebsd-current@freebsd.org, Brian Candler Subject: Re: 6.0-BETA3 and Asterisk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2005 23:15:42 -0000 On Thu, 1 Sep 2005, Boris Samorodov wrote: > On Thu, 1 Sep 2005 14:07:19 +0100 Brian Candler wrote: > > Can mismatched library versions really cause kernel panics?? > > Can't say for sure. But lets solve problems by steps. Using different > system libraries simultaneously is not right (we don't have compat-5x). > > If the case remain after rebuilding ports, we'll ask kernel gurus to > help us. > It isn't the libraries... it's the kernel... kldunload is causing a panic in this case for the Zaptel driver. I'm not even getting as far as starting up Asterisk. Kernel and full buildworld: FreeBSD 6.0-BETA3 #3: Thu Sep 1 16:33:06 MDT 2005 Running "/usr/local/etc/rc.d/zaptel.sh start" Zapata Telephony Interface Registered on major 196 ZapTel device: vendor=e159 device=1 subvendor=8086 wcfxo0: port 0x2400-0x24ff mem 0x42000000-0x42000fff irq 11 at device 14.0 on pci0 ZapTel Attach for wcfxo0: deviceID : 0xe159 wcfxo0: [GIANT-LOCKED] wcfxo: DAA mode is 'FCC' Found a Wildcard FXO: Generic Clone ZapTel device loaded. Running "/usr/local/etc/rc.d/zaptel.sh stop" lock order reversal 1st 0xc106c8c8 mt_zone (UMA zone) @ vm/uma_core.c:2461 2nd 0xc18c3044 user map (user map) @ vm/vm_map.c:2997 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c09334f8,c0933408,c08bf06c) at kdb_backtrace+0x29 witness_checkorder(c18c3044,9,c08741f6,bb5) at witness_checkorder+0x564 _sx_xlock(c18c3044,c08741ed,bb5) at _sx_xlock+0x50 _vm_map_lock_read(c18c3000,c08741ed,bb5,1000016,c18c5480) at _vm_map_lock_read+0x37 vm_map_lookup(ccb03b1c,0,1,ccb03b20,ccb03b10) at vm_map_lookup+0x28 vm_fault(c18c3000,0,1,0,c16b2d80) at vm_fault+0x66 trap_pfault(ccb03be4,0,15) at trap_pfault+0xee trap(c0870008,ccb00028,c0620028,0,c106c8c0) at trap+0x341 calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc07833d4, esp = 0xccb03c24, ebp = 0xccb03c30 --- uma_zfree_internal(c1061960,c1945800,0,1,3) at uma_zfree_internal+0xd4 uma_zfree_arg(c1061960,c1945800,0) at uma_zfree_arg+0x2ed malloc_uninit(c194cce0) at malloc_uninit+0x95 linker_file_sysuninit(c16d6300,0,2,c16d6300,c18c5418) at linker_file_sysuninit+0x7d linker_file_unload(c16d6300,0,0,c16b2d80,ccb03cdc) at linker_file_unload+0x116 kern_kldunload(c16b2d80,3,0,ccb03d30,c07f167b) at kern_kldunload+0x7c kldunloadf(c16b2d80,ccb03d04,2,2,292) at kldunloadf+0x1e syscall(3b,3b,3b,3,bfbfee04) at syscall+0x22f Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (444, FreeBSD ELF32, kldunloadf), eip = 0x280b45b7, esp = 0xbfbfe85c, ebp = 0xbfbfecc8 --- Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x15 fault code = supervisor read, page not present instruction pointer = 0x20:0xc07833d4 stack pointer = 0x28:0xccb03c24 frame pointer = 0x28:0xccb03c30 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 = 921 (kldunload) [thread pid 921 tid 100100 ] Stopped at uma_zfree_internal+0xd4: movzbl 0x15(%ebx),%eax db> db> db> trace Tracing pid 921 tid 100100 td 0xc16b2d80 uma_zfree_internal(c1061960,c1945800,0,1,3) at uma_zfree_internal+0xd4 uma_zfree_arg(c1061960,c1945800,0) at uma_zfree_arg+0x2ed malloc_uninit(c194cce0) at malloc_uninit+0x95 linker_file_sysuninit(c16d6300,0,2,c16d6300,c18c5418) at linker_file_sysuninit+0x7d linker_file_unload(c16d6300,0,0,c16b2d80,ccb03cdc) at linker_file_unload+0x116 kern_kldunload(c16b2d80,3,0,ccb03d30,c07f167b) at kern_kldunload+0x7c kldunloadf(c16b2d80,ccb03d04,2,2,292) at kldunloadf+0x1e syscall(3b,3b,3b,3,bfbfee04) at syscall+0x22f Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (444, FreeBSD ELF32, kldunloadf), eip = 0x280b45b7, esp = 0xbfbfe85c, ebp = 0xbfbfecc8 --- db> db> ps pid proc uid ppid pgrp flag stat wmesg wchan cmd 921 c18c5418 0 920 920 0004002 [CPU 0] kldunload [snip] From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 23: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 9D73D16A41F for ; Thu, 1 Sep 2005 23:47:35 +0000 (GMT) (envelope-from lists@mawer.org) Received: from mail10.syd.optusnet.com.au (mail10.syd.optusnet.com.au [211.29.132.191]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFD7F43D48 for ; Thu, 1 Sep 2005 23:47:34 +0000 (GMT) (envelope-from lists@mawer.org) Received: from c211-30-90-140.belrs3.nsw.optusnet.com.au (c211-30-246-162.belrs3.nsw.optusnet.com.au [211.30.246.162]) by mail10.syd.optusnet.com.au (8.12.11/8.12.11) with SMTP id j81NlWvK021133 for ; Fri, 2 Sep 2005 09:47:32 +1000 Received: (qmail 96862 invoked from network); 1 Sep 2005 23:47:31 -0000 Received: from unknown (HELO ?127.0.0.1?) (unknown) by unknown with SMTP; 1 Sep 2005 23:47:31 -0000 Message-ID: <43179314.7050008@mawer.org> Date: Fri, 02 Sep 2005 09:47:32 +1000 From: Antony Mawer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Edwin Brown References: <8b6eae9605090106151a81174d@mail.gmail.com> In-Reply-To: <8b6eae9605090106151a81174d@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 02 Sep 2005 12:01:56 +0000 Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: FreeBSD6.0 and VMWare 5.0.. No go X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2005 23:47:35 -0000 On 1/09/2005 11:15 PM, Edwin Brown wrote: > This morning I tried to install FreeBSD6.0 under VMWare 5. I got > the following message when it was extracting the base into \ > directory: > > Panic: duplicate free of item 0xc1c5a210 from zone 0xc143f000(g_bio) > > cpuid=0 > KDB: enter: panic > [thread pid 3 tid 100034 ] > stopped at kdb_enter+0x2b: nop > db> > > Is this a known issue? I've seen it reported before, but I don't recall seeing a solution. I hope this is a show-stopper for 6.0, as a number of places I know of use VMware for testing and development with FreeBSD... -Antony From owner-freebsd-current@FreeBSD.ORG Fri Sep 2 05:50: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 2595716A41F; Fri, 2 Sep 2005 05:50:02 +0000 (GMT) (envelope-from sem@core.inec.ru) Received: from relay-er5.mbrd.ru (relay-er5.mbrd.ru [194.117.71.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 398E843D5D; Fri, 2 Sep 2005 05:50:01 +0000 (GMT) (envelope-from sem@core.inec.ru) Received: from msd.mbrd.ru ([172.16.4.9]) by relay-er5.mbrd.ru with esmtp (Exim 4.x) id 1EB4R2-000Dbb-7R; Fri, 02 Sep 2005 09:49:56 +0400 Message-ID: <4317E804.7080002@core.inec.ru> Date: Fri, 02 Sep 2005 09:49:56 +0400 From: Sergey Matveychuk User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Suleiman Souhlal References: <43158F98.7040704@core.inec.ru> <73418676-5CB7-47BE-8BED-387E98A1705B@FreeBSD.org> In-Reply-To: <73418676-5CB7-47BE-8BED-387E98A1705B@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 02 Sep 2005 12:01:56 +0000 Cc: freebsd-current@freebsd.org Subject: Re: panic right now in 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: Fri, 02 Sep 2005 05:50:02 -0000 Suleiman Souhlal wrote: > Can you try http://people.freebsd.org/~ssouhlal/testing/ > null_vnops.c-20050831.diff ? I'm trying it. No panics yet. But because of the panic is not clearly reproducable I can't say it gone. May be after awhile. -- Sem. From owner-freebsd-current@FreeBSD.ORG Fri Sep 2 06:43: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 421F816A473; Fri, 2 Sep 2005 06:43:02 +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 992B343D45; Fri, 2 Sep 2005 06:43:01 +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 j826fOUw003043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Sep 2005 08:41:24 +0200 (CEST) (envelope-from csaba@beastie.creo.hu) Received: (from csaba@localhost) by beastie.creo.hu (8.13.3/8.13.3/Submit) id j826fKxK003042; Fri, 2 Sep 2005 08:41:20 +0200 (CEST) (envelope-from csaba) Date: Fri, 2 Sep 2005 08:41:20 +0200 From: Csaba Henk To: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Message-ID: <20050902064120.GC73367@beastie.creo.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-Mailman-Approved-At: Fri, 02 Sep 2005 12:01:56 +0000 Cc: brennan.stehling@offwhite.net, scottl@freebsd.org Subject: [ANN] Google Soc: Fuse port with sshfs 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: Fri, 02 Sep 2005 06:43:02 -0000 Hi! I'm glad to announce the first public release of my Fuse port to FreeBSD. Fuse is programmer-friendly userspace filesystem framework, getting more and more popular, originally written for Linux. See more at http://fuse.sourceforge.net. As a Google Summer of Code 2005 participant, my aim was originally to provide FreeBSD with an ssh based networked filesystem. I went on to port Fuse because this is already available there. The instructions to run Fuse on FreeBSD with sshfs can be found in the README of the tarball. Look for the latest tarball in http://creo.hu/~csaba/projects/fuse4bsd/downloads/ as fuse4bsd-.tar.bz2. (Currently this means version 0.01). What is closest to be a project homepage is http://wikitest.freebsd.org/moin.cgi/FuseFilesystem Latest development versions will be available via Darcs, the darcs get http://creo.hu/~csaba/darcs-repos/fuse4bsd command gets them for you. The release is pretty much beta quality, so don't run them on production servers, given that you have production servers running CURRENT, as it's been developed on/for that branch (should work with RELENG-6, too, though). But certainly now you can mount them, even if you don't run NFS on them -- what they will see from inside is just an ordinary sftp connection... And you can try the other things, like GmailFS, and Fuse frontends to compression libraries, and so on (see the list at http://fuse.sourceforge.net/filesystems.html). Mainly their usability should depend on the portability of their private userspace solutions, which shouldn't mean a big problem in the world of open source Unices and lookalikes. (I personally didn't yet get there to play with them.) Any feedback is warmly welcome at my FreeBSD dot org address, soc-chenk. Regards, Csaba From owner-freebsd-current@FreeBSD.ORG Fri Sep 2 14:58: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 750AA16A41F; Fri, 2 Sep 2005 14:58:06 +0000 (GMT) (envelope-from emaste@phaedrus.sandvine.ca) Received: from mailserver.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id F108F43D45; Fri, 2 Sep 2005 14:58:05 +0000 (GMT) (envelope-from emaste@phaedrus.sandvine.ca) Received: from labgw2.phaedrus.sandvine.com ([192.168.3.11]) by mailserver.sandvine.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 2 Sep 2005 10:58:04 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 12627) id 7520213595; Fri, 2 Sep 2005 10:58:04 -0400 (EDT) Date: Fri, 2 Sep 2005 10:58:04 -0400 From: Ed Maste To: Jung-uk Kim Message-ID: <20050902145804.GA31248@sandvine.com> References: <200509011507.23432.jkim@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200509011507.23432.jkim@FreeBSD.org> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 02 Sep 2005 14:58:04.0657 (UTC) FILETIME=[B8AFA610:01C5AFCE] Cc: freebsd-current@FreeBSD.org Subject: Re: [PATCH] boot loader fixes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2005 14:58:06 -0000 On Thu, Sep 01, 2005 at 03:07:21PM -0400, Jung-uk Kim wrote: > This patch has various boot loader fixes. > > [...] > > 4. Allow '-S0' or simply '-S'. This is not to change serial speed. I gave the patch a try but couldn't get the -S0 functionality to work. I suspect that either my BIOS is clearing the UART before starting the mbr code, or that it's just leaving some registers in an undesired state. Maybe the rest of sio_init (other than the divisor) is needed in this case. -- Ed Maste Sandvine Incorporated From owner-freebsd-current@FreeBSD.ORG Fri Sep 2 15:19:38 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 0392116A41F for ; Fri, 2 Sep 2005 15:19:38 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E69343D46 for ; Fri, 2 Sep 2005 15:19:37 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EBDIO-0006MQ-73 for freebsd-current@freebsd.org; Fri, 02 Sep 2005 17:17:36 +0200 Received: from mulder.f5.com ([205.229.151.150]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 02 Sep 2005 17:17:36 +0200 Received: from atkin901 by mulder.f5.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 02 Sep 2005 17:17:36 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: othermark Date: Fri, 02 Sep 2005 08:15:34 -0700 Lines: 37 Message-ID: References: <4316E1A0.8070307@altern.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: mulder.f5.com User-Agent: KNode/0.9.2 Sender: news Subject: Re: Problem with deleting files X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2005 15:19:38 -0000 Gregory Nou wrote: > I'm currently experiencing a weird problem : some of my folders are > completely empty (ls -a doesn't even mention . or ..) > But, I cannot remove them, and a ls is very very slow (but just in those > folders, and it is quite rare, but now I cannot update firefox, nor > openoffice, because make clean will fail). Yeah, I've seen this. For me, this is the direct result of the ServerWorks chipset on the box not properly doing DMA, and in fact causes corruption on the bus when DMA is enabled for the IDE controller. Usually you see this when doing large extracts or deletes (like the openoffice of mozilla/firefox ports). You need to fsck, hopefully before you even read this (you'll see lots of softupdate problems being fixed). You'll also notice that your daily automatic reports sent to root will mention problems with traversing files or directories. For reference this bad boy: atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc90-0xfc9f at device 15.1 on pci0 atapci0@pci0:15:1: class=0x01018a card=0x00000000 chip=0x02111166 rev=0x00 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'OSB4 PCI EIDE Controller' class = mass storage subclass = ATA The only solution is to run with dma off (see atacontrol, or shut it off in BIOS). -- othermark atkin901 at nospam dot yahoo dot com (!wired)?(coffee++):(wired); From owner-freebsd-current@FreeBSD.ORG Fri Sep 2 15:54: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 9514B16A41F for ; Fri, 2 Sep 2005 15:54:10 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id A22B343D45 for ; Fri, 2 Sep 2005 15:54:09 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id j82Fs73g047495; Fri, 2 Sep 2005 19:54:07 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id j82Fs6Uk047490; Fri, 2 Sep 2005 19:54:06 +0400 (MSD) (envelope-from yar) Date: Fri, 2 Sep 2005 19:54:06 +0400 From: Yar Tikhiy To: Gavin Atkinson Message-ID: <20050902155406.GA44959@comp.chem.msu.su> References: <1125487485.34476.6.camel@buffy.york.ac.uk> <20050831134927.GA20529@comp.chem.msu.su> <1125594635.63101.3.camel@buffy.york.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1125594635.63101.3.camel@buffy.york.ac.uk> User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org Subject: Re: 6.0BETA3 panic in ip_output (vlan/RIP related?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2005 15:54:10 -0000 On Thu, Sep 01, 2005 at 06:10:35PM +0100, Gavin Atkinson wrote: > > wiggum# reboot > Sep 1 18:05:05 > wiggum reboot: r > Faooted by root > Sep 1 18:05:05 wiggum syslogd: exiting on signal 15 > tal trap 9: general protection fault while in kernel mode > cpuid = 1; apic id = 01 > instruction pointer = 0x8:0xffffffff80429420 > stack pointer = 0x10:0xffffffffb49c4590 > frame pointer = 0x10:0xffffffffb49c46a0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 244 (routed) > [thread pid 244 tid 100101 ] > Stopped at strlen: cmpb $0,0(%rdi) > db> tr > Tracing pid 244 tid 100101 td 0xffffff0061d1b980 > strlen() at strlen > vsnprintf() at vsnprintf+0x2e > panic() at panic+0x14b > _mtx_lock_flags() at _mtx_lock_flags+0xd6 > if_delmulti() at if_delmulti+0x3f > in_delmulti() at in_delmulti+0x4b > ip_freemoptions() at ip_freemoptions+0x30 > in_pcbdetach() at in_pcbdetach+0x182 > udp_detach() at udp_detach+0x51 > soclose() at soclose+0x1a0 > soo_close() at soo_close+0x3f > fdrop_locked() at fdrop_locked+0xa1 > closef() at closef+0x31 > fdfree() at fdfree+0x48a > exit1() at exit1+0x302 > sys_exit() at sys_exit+0xe > syscall() at syscall+0x4b2 > Xfast_syscall() at Xfast_syscall+0xa8 > > Given I've accidentally been able to panic this machine twice in two > days, is there any chance a fix or at least a band-aid will be in place > before the release? It's a shame, but I can't tell for sure. The problem in the IP multicast code is really easy to hit, but it will be rather hard to fix it without major changes to the code. The workaround is to avoid destroying interfaces with multicast groups still joined on them. Both panics you saw seemed to result from the code trying to use memory structures of a now-deceased interface. -- Yar From owner-freebsd-current@FreeBSD.ORG Fri Sep 2 16:49:58 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 916AB16A41F for ; Fri, 2 Sep 2005 16:49:58 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B27543D45 for ; Fri, 2 Sep 2005 16:49:58 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j82GnvDH026436; Fri, 2 Sep 2005 09:49:57 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j82Gnv6Y026433; Fri, 2 Sep 2005 09:49:57 -0700 Date: Fri, 2 Sep 2005 09:49:57 -0700 From: Brooks Davis To: Jochen Gensch Message-ID: <20050902164957.GA22097@odin.ac.hmc.edu> References: <20050901225346.0923E16A41F@hub.freebsd.org> <200509020126.45337.incmc@gmx.de> <20050902015242.GJ4108@odin.ac.hmc.edu> <200509021003.39863.incmc@gmx.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline In-Reply-To: <200509021003.39863.incmc@gmx.de> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: freebsd-current@freebsd.org Subject: Re: Default route doesn't change to wireless device (ath0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2005 16:49:58 -0000 --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 02, 2005 at 10:03:39AM +0200, Jochen Gensch wrote: > Am Freitag 02 September 2005 03:52 schrieben Sie: >=20 > > The issue is that start_if.ath0 always runs at boot or when=20 > > you insert the card, but not when you get a lease. If you want to take > > an action when you get a lease, you need to do it in the dhclient hooks. >=20 > I cannot manage to get ath0 up properly. If dhclient doesn't change the= =20 > default route again, once a device got it one should be able to do it by= =20 > hand. So when I bootet the system was running on fxp0. Then I did the=20 > followiing: >=20 > SU NB /:route -n flush -inet > default 10.0.0.1 done > 10.0.0.104 127.0.0.1 done > [REMOVED network cable from fxp0] > [Pluged in wireless nic ath0] > SU NB /:ping i-mc.de > PING i-mc.de (213.203.199.12): 56 data bytes > ping: sendto: No route to host > ^C > --- i-mc.de ping statistics --- > 2 packets transmitted, 0 packets received, 100% packet loss > [OK, routes have not been corrected yet] > SU NB /:route add default 10.0.0.1 > route: writing to routing socket: File exists > add net default: gateway 10.0.0.1: File exists > [Why does that route sitll exist, it has been deleted above] > SU NB /:ping i-mc.de > ^C > SU NB /:route delete default > delete net default > SU NB /:route add default 10.0.0.1 > add net default: gateway 10.0.0.1 > SU NB /:ping i-mc.de > ^C >=20 > I cannot set the routes to ath0 once fxp0 was active. I guess I must stil= l be=20 > misunderstandung what you guys are saying / doing. I need to see the IPv4 routing table before and after each step to understand what's going. Please send the results of "netstat -rnf inet" at each stage. Also, please, please, please, ping by IP address so we're not testing your resolver (which is dependent on your routing configuration.) -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --tKW2IUtsqtDRztdT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDGIK0XY6L6fI4GtQRAkTnAJ4qwar1fi1gg/Z1VipQGun/4GUWVgCgt8G5 wDt8itoXzPCRVGnbmpIZLe4= =FxOo -----END PGP SIGNATURE----- --tKW2IUtsqtDRztdT-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 2 17:31:52 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 4A51D16A41F for ; Fri, 2 Sep 2005 17:31:52 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACF4D43D45 for ; Fri, 2 Sep 2005 17:31:51 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[10.50.40.201]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Fri, 02 Sep 2005 13:47:13 -0400 From: John Baldwin To: current@FreeBSD.org Date: Fri, 2 Sep 2005 13:21:35 -0400 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509021321.36320.jhb@FreeBSD.org> Cc: Subject: Locking for txp(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2005 17:31:52 -0000 I have a patch that adds locking to txp(4) and marks it MPSAFE. I also think I've found a bug in the driver in low-memory conditions where txp_rxbuf_reclaim() can't allocate a new mbuf cluster, so I'd appreciate it if folks could test this. Thanks. http://www.FreeBSD.org/~jhb/patches/txp_locking.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 Fri Sep 2 18:51: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 6C36A16A41F; Fri, 2 Sep 2005 18:51:11 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id C66CA43D45; Fri, 2 Sep 2005 18:51:10 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[10.50.40.201]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Fri, 02 Sep 2005 15:06:33 -0400 From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 2 Sep 2005 14:40:11 -0400 User-Agent: KMail/1.8 References: <200509020352.j823qKm9022255@gw.catspoiler.org> In-Reply-To: <200509020352.j823qKm9022255@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509021440.13022.jhb@FreeBSD.org> Cc: Don Lewis , rwatson@freebsd.org, current@freebsd.org Subject: Re: Witness 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, 02 Sep 2005 18:51:11 -0000 On Thursday 01 September 2005 11:52 pm, Don Lewis wrote: > On 1 Sep, John Baldwin wrote: > > This patch forces witness to complain if any mutex is held when Giant is > > locked to enforce Giant being the first mutex in the lock order. This > > might help track down some of the network LORs being reported recently. > > > > http://www.FreeBSD.org/~jhb/patches/witness.patch > > I think it would make sense to print different messages for the > different trigger conditions. Hmm, I guess I view them as all just being reversals, and that we have some implicit orders that go something like this: sleepable locks --> Giant --> non-sleepable locks --> spin locks -- 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 Sep 2 18:51: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 6C36A16A41F; Fri, 2 Sep 2005 18:51:11 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id C66CA43D45; Fri, 2 Sep 2005 18:51:10 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[10.50.40.201]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Fri, 02 Sep 2005 15:06:33 -0400 From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 2 Sep 2005 14:40:11 -0400 User-Agent: KMail/1.8 References: <200509020352.j823qKm9022255@gw.catspoiler.org> In-Reply-To: <200509020352.j823qKm9022255@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509021440.13022.jhb@FreeBSD.org> Cc: Don Lewis , rwatson@freebsd.org, current@freebsd.org Subject: Re: Witness 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, 02 Sep 2005 18:51:11 -0000 On Thursday 01 September 2005 11:52 pm, Don Lewis wrote: > On 1 Sep, John Baldwin wrote: > > This patch forces witness to complain if any mutex is held when Giant is > > locked to enforce Giant being the first mutex in the lock order. This > > might help track down some of the network LORs being reported recently. > > > > http://www.FreeBSD.org/~jhb/patches/witness.patch > > I think it would make sense to print different messages for the > different trigger conditions. Hmm, I guess I view them as all just being reversals, and that we have some implicit orders that go something like this: sleepable locks --> Giant --> non-sleepable locks --> spin locks -- 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 Sep 2 18:51:12 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 64D8416A41F; Fri, 2 Sep 2005 18:51:12 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id D620E43D45; Fri, 2 Sep 2005 18:51:11 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[10.50.40.201]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Fri, 02 Sep 2005 15:06:32 -0400 From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 2 Sep 2005 14:37:31 -0400 User-Agent: KMail/1.8 References: <200509020039.j820dcst021990@gw.catspoiler.org> In-Reply-To: <200509020039.j820dcst021990@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509021437.34361.jhb@FreeBSD.org> Cc: Don Lewis , rwatson@freebsd.org, dandee@volny.cz, bzeeb-lists@lists.zabbadoz.net, fli+freebsd-current@shapeshifter.se, imp@bsdimp.com Subject: Re: LOR route vr0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2005 18:51:12 -0000 On Thursday 01 September 2005 08:39 pm, Don Lewis wrote: > On 1 Sep, John Baldwin wrote: > > On Thursday 01 September 2005 01:22 pm, Don Lewis wrote: > >> On 1 Sep, Fredrik Lindberg wrote: > >> > I'm seeing both the rentry and the tcpinp LORs on my fxp interface > >> > on a machine running a few days old -current (Aug 25). > >> > > >> > lock order reversal > >> > 1st 0xc1e30d38 inp (tcpinp) @ /usr/src/sys/netinet/tcp_input.c:742 > >> > 2nd 0xc1b74018 fxp0 (network driver) > >> > @/usr/src/sys/dev/fxp/if_fxp.c:1172 > >> > > >> > lock order reversal > >> > 1st 0xc1e06bb8 rtentry (rtentry) @ /usr/src/sys/net/route.c:1269 > >> > 2nd 0xc1b74018 fxp0 (network driver) > >> > @/usr/src/sys/dev/fxp/if_fxp.c:1172 > >> > > >> > As for their backtraces they are almost identical to the > >> > once already posted. > >> > >> Are you using any applications that use multicast? Can you break into > >> DDB and capture the output of "show witness"? > > > > Also, are you using DEVICE_POLLING? > > I can reproduce this if I add DEVICE_POLLING to my kernel. And I see > Giant under "network driver" in the output of "show witness". > > If I apply your witness patch: > http://www.FreeBSD.org/~jhb/patches/witness.patch > then I get the following LOR: > > lock order reversal > 1st 0xc23e2018 fxp0 (network driver) @ /usr/src/sys/dev/fxp/if_fxp.c:1907 > 2nd 0xc09387e0 Giant (Giant) @ /usr/src/sys/kern/kern_poll.c:460 > KDB: stack backtrace: > kdb_backtrace(0,ffffffff,c0946470,c0947f28,c08d3a84) at kdb_backtrace+0x29 > witness_checkorder(c09387e0,9,c086d0d3,1cc) at witness_checkorder+0x53c > _mtx_lock_flags(c09387e0,0,c086d0d3,1cc) at _mtx_lock_flags+0x5b > ether_poll_deregister(c23de000,c23e2000,c23e2018,0,e9295b60) at > ether_poll_deregister+0x1d fxp_stop(c23e2000,c23e2018,1,c084c9ff,787) at > fxp_stop+0x21 > fxp_init_body(c23e2000,c23e2018,0,c084c9ff,773) at fxp_init_body+0x31 > fxp_init(c23e2000,8020690c,c23e2000,c264bb00,e9295bc0) at fxp_init+0x23 > ether_ioctl(c23de000,8020690c,c264bb00,0,c264bb00) at ether_ioctl+0x50 > fxp_ioctl(c23de000,8020690c,c264bb00,1,c0a86503) at fxp_ioctl+0x232 > in_ifinit(c23de000,c264bb00,c24b3490,0,e9295c38) at in_ifinit+0x206 > in_control(c270fde8,8040691a,c24b3480,c23de000,c248e900) at > in_control+0x882 ifioctl(c270fde8,8040691a,c24b3480,c248e900,0) at > ifioctl+0x198 > soo_ioctl(c2647dc8,8040691a,c24b3480,c2271d00,c248e900) at soo_ioctl+0x2db > ioctl(c248e900,e9295d04,3,1,286) at ioctl+0x370 > syscall(3b,3b,3b,8056e40,8059140) at syscall+0x22f > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x48136e4b, esp = 0xbfbfe5ec, > ebp = 0xbfbfee38 --- fxp0: link state changed to UP Yeah, because of this bug, DEVICE_POLLING really needs debug.mpsafenet=0. Perhaps someone should add NET_NEEDS_GIANT(polling) to sys/kern/kern_poll.c for now? The problem is that the polling code needs to use something other than Giant to protect its internal data that it accesses in ether_poll_deregister() since all the drivers I've seen call ether_poll_deregister() with the driver lock held. > I also get another LOR: > > cd0: Attempt to query device size failed: NOT READY, Medium not present > lock order reversal > 1st 0xe35e0cc4 g_xdown (g_xdown) @ /usr/src/sys/geom/geom_io.c:465 > 2nd 0xc09387e0 Giant (Giant) @ /usr/src/sys/geom/geom_disk.c:99 > KDB: stack backtrace: > kdb_backtrace(0,ffffffff,c0945e30,c0947f28,c08d3a84) at kdb_backtrace+0x29 > witness_checkorder(c09387e0,9,c0866bc0,63) at witness_checkorder+0x53c > _mtx_lock_flags(c09387e0,0,c0866bc0,63) at _mtx_lock_flags+0x5b > g_disk_start(c2632a50,e35e0cc4,0,c086722e,1d1) at g_disk_start+0x152 > g_io_schedule_down(c2275480) at g_io_schedule_down+0x160 > g_down_procbody(0,e35e0d38,0,c0606960,0) at g_down_procbody+0x5a > fork_exit(c0606960,0,e35e0d38) at fork_exit+0xa0 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xe35e0d6c, ebp = 0 --- > Trying to mount root from ufs:/dev/da0s1a Hummmm. That means if anyone does a msleep(g_xdown) while holding Giant then it could deadlock on resume since msleep() always acquires Giant first. Perhaps g_xdown should be an sx lock or some such. -- 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 Sep 2 19:32: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 1A96B16A41F; Fri, 2 Sep 2005 19:32:03 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 786A943D46; Fri, 2 Sep 2005 19:32:02 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[10.50.40.201]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Fri, 02 Sep 2005 15:47:24 -0400 From: John Baldwin To: current@FreeBSD.org Date: Fri, 2 Sep 2005 15:32:53 -0400 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509021532.54579.jhb@FreeBSD.org> Cc: powerpc@FreeBSD.org, alpha@FreeBSD.org Subject: [PATCH] Cleanup asm constraints in atomic operations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2005 19:32:03 -0000 alc@ brought to my attention a while back that while gcc allows one to use the '+' constraint modifier to collapse identical input and output operands that are in registers, it is only allowed for registers and not for memory operands. The patch below removes uses of the '+' modifier in conjunction with memory operands in the atomic operations for alpha, amd64, i386, and powerpc. Please test and let me know if there are any regressions. -- 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 Sep 2 19:41:30 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 D139D16A41F; Fri, 2 Sep 2005 19:41:30 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FCDE43D46; Fri, 2 Sep 2005 19:41:30 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.40.201] (Not Verified[10.50.40.201]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Fri, 02 Sep 2005 15:56:52 -0400 From: John Baldwin To: current@freebsd.org Date: Fri, 2 Sep 2005 15:42:20 -0400 User-Agent: KMail/1.8 References: <200509021532.54579.jhb@FreeBSD.org> In-Reply-To: <200509021532.54579.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509021542.22227.jhb@FreeBSD.org> Cc: powerpc@freebsd.org, alpha@freebsd.org Subject: Re: [PATCH] Cleanup asm constraints in atomic operations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2005 19:41:31 -0000 On Friday 02 September 2005 03:32 pm, John Baldwin wrote: > alc@ brought to my attention a while back that while gcc allows one to use > the '+' constraint modifier to collapse identical input and output operands > that are in registers, it is only allowed for registers and not for memory > operands. The patch below removes uses of the '+' modifier in conjunction > with memory operands in the atomic operations for alpha, amd64, i386, and > powerpc. Please test and let me know if there are any regressions. *sigh* http://www.FreeBSD.org/~jhb/patches/atomic.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 Fri Sep 2 21:32:14 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 8B5A316A41F for ; Fri, 2 Sep 2005 21:32:14 +0000 (GMT) (envelope-from psamuel01@yahoo.com) Received: from web33508.mail.mud.yahoo.com (web33508.mail.mud.yahoo.com [68.142.206.157]) by mx1.FreeBSD.org (Postfix) with SMTP id 0F2AB43D46 for ; Fri, 2 Sep 2005 21:32:13 +0000 (GMT) (envelope-from psamuel01@yahoo.com) Received: (qmail 34330 invoked by uid 60001); 2 Sep 2005 21:32:13 -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=Ocx2N2xVl3m+8+fzLhpt2m+GuBNIBr7DOAyPp+nCI3eZrbQqZO3aaDwhbnCvnTwuQbaigyplVi/a+72cJYtQYIuxxQBISpQvvHXwY3D3lbnOhw6UB1ivSQ5+8HwxJMbJ34aBBMwOU70pgnBDD6trfEkl9M1BFntTwbc5ftNF+JI= ; Message-ID: <20050902213213.34328.qmail@web33508.mail.mud.yahoo.com> Received: from [12.2.142.7] by web33508.mail.mud.yahoo.com via HTTP; Fri, 02 Sep 2005 14:32:13 PDT Date: Fri, 2 Sep 2005 14:32:13 -0700 (PDT) From: Dean Patterson To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: Installation error Intel mobile ICH6M SATA controller. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2005 21:32:14 -0000 PLEASE save me from LINUX!! I can install FBSD on a Dell D610 laptop just fine, but when I reboot it does not recognize the drive/controller. When I install the boot loader I am presented with the F1 option and when pressed I get "invalid slice." When I install a standard MBR I get "invalid partition table." Any fixes or patches? I enjoy Gentoo, but I REALLY MISS FREEBSD!! Dean. ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From owner-freebsd-current@FreeBSD.ORG Fri Sep 2 21:37: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 3912216A41F; Fri, 2 Sep 2005 21:37:41 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8FBB43D48; Fri, 2 Sep 2005 21:37:40 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id j82LbUj2024170; Fri, 2 Sep 2005 14:37:34 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200509022137.j82LbUj2024170@gw.catspoiler.org> Date: Fri, 2 Sep 2005 14:37:30 -0700 (PDT) From: Don Lewis To: jhb@FreeBSD.org In-Reply-To: <200509021440.13022.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org, rwatson@FreeBSD.org, current@FreeBSD.org Subject: Re: Witness 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, 02 Sep 2005 21:37:41 -0000 On 2 Sep, John Baldwin wrote: > On Thursday 01 September 2005 11:52 pm, Don Lewis wrote: >> On 1 Sep, John Baldwin wrote: >> > This patch forces witness to complain if any mutex is held when Giant is >> > locked to enforce Giant being the first mutex in the lock order. This >> > might help track down some of the network LORs being reported recently. >> > >> > http://www.FreeBSD.org/~jhb/patches/witness.patch >> >> I think it would make sense to print different messages for the >> different trigger conditions. > > Hmm, I guess I view them as all just being reversals, and that we have some > implicit orders that go something like this: > > sleepable locks --> Giant --> non-sleepable locks --> spin locks Attempting to lock one one of the other lock types while holding a spin lock already prints a unique message and results in a panic. Identifying the other cases of incorrect lock type ordering with a unique warning message eliminates the need to grovel through the source code just to find the types of the locks, and it indicates that looking at the output of "show witness" is not needed. From owner-freebsd-current@FreeBSD.ORG Fri Sep 2 21:37:41 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 3912216A41F; Fri, 2 Sep 2005 21:37:41 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8FBB43D48; Fri, 2 Sep 2005 21:37:40 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id j82LbUj2024170; Fri, 2 Sep 2005 14:37:34 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200509022137.j82LbUj2024170@gw.catspoiler.org> Date: Fri, 2 Sep 2005 14:37:30 -0700 (PDT) From: Don Lewis To: jhb@FreeBSD.org In-Reply-To: <200509021440.13022.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org, rwatson@FreeBSD.org, current@FreeBSD.org Subject: Re: Witness 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, 02 Sep 2005 21:37:41 -0000 On 2 Sep, John Baldwin wrote: > On Thursday 01 September 2005 11:52 pm, Don Lewis wrote: >> On 1 Sep, John Baldwin wrote: >> > This patch forces witness to complain if any mutex is held when Giant is >> > locked to enforce Giant being the first mutex in the lock order. This >> > might help track down some of the network LORs being reported recently. >> > >> > http://www.FreeBSD.org/~jhb/patches/witness.patch >> >> I think it would make sense to print different messages for the >> different trigger conditions. > > Hmm, I guess I view them as all just being reversals, and that we have some > implicit orders that go something like this: > > sleepable locks --> Giant --> non-sleepable locks --> spin locks Attempting to lock one one of the other lock types while holding a spin lock already prints a unique message and results in a panic. Identifying the other cases of incorrect lock type ordering with a unique warning message eliminates the need to grovel through the source code just to find the types of the locks, and it indicates that looking at the output of "show witness" is not needed. From owner-freebsd-current@FreeBSD.ORG Fri Sep 2 21:56:39 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 D970516A41F for ; Fri, 2 Sep 2005 21:56:39 +0000 (GMT) (envelope-from oberman@es.net) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id A81C643D45 for ; Fri, 2 Sep 2005 21:56:39 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id IBA74465; Fri, 02 Sep 2005 14:56:38 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 3381E5D07; Fri, 2 Sep 2005 14:56:38 -0700 (PDT) To: Dean Patterson In-reply-to: Your message of "Fri, 02 Sep 2005 14:32:13 PDT." <20050902213213.34328.qmail@web33508.mail.mud.yahoo.com> Date: Fri, 02 Sep 2005 14:56:38 -0700 From: "Kevin Oberman" Message-Id: <20050902215638.3381E5D07@ptavv.es.net> Cc: freebsd-current@freebsd.org Subject: Re: Installation error Intel mobile ICH6M SATA controller. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2005 21:56:40 -0000 > Date: Fri, 2 Sep 2005 14:32:13 -0700 (PDT) > From: Dean Patterson > Sender: owner-freebsd-current@freebsd.org > > PLEASE save me from LINUX!! I can install FBSD on a > Dell D610 laptop just fine, but when I reboot it does > not recognize the drive/controller. When I install > the boot loader I am presented with the F1 option and > when pressed I get "invalid slice." When I install a > standard MBR I get "invalid partition table." Any > fixes or patches? I enjoy Gentoo, but I REALLY MISS > FREEBSD!! A little more information, please. What version of FreeBSD are you attempting to install? Which install did you do? How did you slice the disk? How did you partition the slice? If you boot the install floppy, can you start the holographic shell and do an "fdisk ad0"? "bsdlabel ad0s1"? I suspect something went awry in the configuration process. The exact details of how to do the above depends on just what version you were installing, but I'm assuming it was V6Beta? or you would have sent your message to questions@ and not to current@. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-current@FreeBSD.ORG Fri Sep 2 22:02:28 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 6010716A41F; Fri, 2 Sep 2005 22:02:28 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fileserver.fields.utoronto.ca (fileserver.fields.utoronto.ca [128.100.216.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE61243D48; Fri, 2 Sep 2005 22:02:27 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fields.fields.utoronto.ca (fields.localdomain [192.168.216.11]) by fileserver.fields.utoronto.ca (8.12.8/8.12.8/Fields 6.0) with ESMTP id j82M2Rvf012912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Sep 2005 18:02:27 -0400 Received: from obsecurity.dyndns.org (localhost.localdomain [127.0.0.1]) by fields.fields.utoronto.ca (8.12.8/8.12.8/Fields WS 6.0) with ESMTP id j82M2R6P022075; Fri, 2 Sep 2005 18:02:27 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 24A9D51222; Fri, 2 Sep 2005 18:02:26 -0400 (EDT) Date: Fri, 2 Sep 2005 18:02:25 -0400 From: Kris Kennaway To: current@FreeBSD.org, ssouhlal@FreeBSD.org Message-ID: <20050902220225.GA53096@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Qxx1br4bt0+wmkIi" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: lockmgr: thread 0xc8f5b000 unlocking unheld lock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2005 22:02:28 -0000 --Qxx1br4bt0+wmkIi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline lockmgr: thread 0xc8f5b000 unlocking unheld lock KDB: stack backtrace: kdb_backtrace(c070420e,c8f5b000,c07040a6,a3,c8f5b000) at kdb_backtrace+0x2f lockmgr(cb69dd18,6,cb69dd3c,c8f5b000,f7d3bbe0) at lockmgr+0x632 vop_stdunlock(f7d3bbf8,0,cb69dd3c,2,cb69dcc0) at vop_stdunlock+0x32 VOP_UNLOCK_APV(c073a2a0,f7d3bbf8,cb69dd3c,7d6,c0762460) at VOP_UNLOCK_APV+0xb2 vn_lock(cb69dcc0,2002,c8f5b000,7d6,c0703374) at vn_lock+0x133 vrele(cb69dcc0,0,c070336b,178,68f) at vrele+0xfa exit1(c8f5b000,0,f7d3bd30,c06c8194,c8f5b000) at exit1+0xb1e exit1(c8f5b000,f7d3bd04,4,8070000,1) at exit1 syscall(3b,3b,3b,0,bfbfe3e4) at syscall+0x295 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x8060543, esp = 0xbfbfe32c, ebp = 0xbfbfe338 --- At the time I was running a buildworld over r/w nullfs (/usr/src and /usr/obj). Kris --Qxx1br4bt0+wmkIi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDGMvwWry0BWjoQKURAsYxAKCILduwby6T0gRpyXXhD+SsgqIjqQCg63Jn kGdKJIBSrVTn//J4kk7gEBQ= =M1De -----END PGP SIGNATURE----- --Qxx1br4bt0+wmkIi-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 2 22:17: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 BA09516A41F; Fri, 2 Sep 2005 22:17:10 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 603D243D48; Fri, 2 Sep 2005 22:17:10 +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 postfix3-1.free.fr (Postfix) with ESMTP id 0020117348E; Sat, 3 Sep 2005 00:17:08 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 15F3E4080; Sat, 3 Sep 2005 00:17:25 +0200 (CEST) Date: Sat, 3 Sep 2005 00:17:24 +0200 From: Jeremie Le Hen To: Edwin Brown Message-ID: <20050902221724.GC659@obiwan.tataz.chchile.org> References: <8b6eae9605090106151a81174d@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8b6eae9605090106151a81174d@mail.gmail.com> User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: FreeBSD6.0 and VMWare 5.0.. No go X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2005 22:17:10 -0000 Hi Edwin, [ Please either post on -stable@ or -current@, not both. In this case you should have post on -current@ only, since 6.0 isn't stable yet. ] > This morning I tried to install FreeBSD6.0 under VMWare 5. I got > the following message when it was extracting the base into \ > directory: > > Panic: duplicate free of item 0xc1c5a210 from zone 0xc143f000(g_bio) > > cpuid=0 > KDB: enter: panic > [thread pid 3 tid 100034 ] > stopped at kdb_enter+0x2b: nop > db> > > Is this a known issue? Don't know if it's a known issue, but can you use the "trace" DDB command and post the output here please, this will greatly help debugging for kernel hackers. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Fri Sep 2 22:22: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 6459516A41F for ; Fri, 2 Sep 2005 22:22:41 +0000 (GMT) (envelope-from sullrich@gmail.com) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id C251943D45 for ; Fri, 2 Sep 2005 22:22:40 +0000 (GMT) (envelope-from sullrich@gmail.com) Received: by rproxy.gmail.com with SMTP id r35so590913rna for ; Fri, 02 Sep 2005 15:22:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=cgOs5EeDcnJA1FZPzvfdChYSjyQuhLj5vcishtCiHHN0gvqTJ3N3or67VH4Aq3N0xqVENDttdLwCyMdXJPzXvTHtXyeyZ6079rJ5Q2ya6sAN/9jEMcxqUJIZAyiRR176puavtwpkL0oGkInJWk5RTNfB1yNCsoOoToWb6r+et68= Received: by 10.38.98.5 with SMTP id v5mr286677rnb; Fri, 02 Sep 2005 15:22:40 -0700 (PDT) Received: by 10.38.207.79 with HTTP; Fri, 2 Sep 2005 15:22:40 -0700 (PDT) Message-ID: Date: Fri, 2 Sep 2005 18:22:40 -0400 From: Scott Ullrich To: Jeremie Le Hen In-Reply-To: <20050902221724.GC659@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <8b6eae9605090106151a81174d@mail.gmail.com> <20050902221724.GC659@obiwan.tataz.chchile.org> Cc: freebsd-current@freebsd.org, Edwin Brown Subject: Re: FreeBSD6.0 and VMWare 5.0.. No go X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2005 22:22:41 -0000 On 9/2/05, Jeremie Le Hen wrote: > Hi Edwin, >=20 > [ Please either post on -stable@ or -current@, not both. In this case > you should have post on -current@ only, since 6.0 isn't stable yet. ] Not sure if this is related or not but the SoC for BSDInstaller mentions: * Add a kernel without PREEMPTION for Qemu and Vmware http://wikitest.freebsd.org/moin.cgi/BSDInstaller Scott From owner-freebsd-current@FreeBSD.ORG Fri Sep 2 22:25: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 286DE16A41F for ; Fri, 2 Sep 2005 22:25:04 +0000 (GMT) (envelope-from psamuel01@yahoo.com) Received: from web33509.mail.mud.yahoo.com (web33509.mail.mud.yahoo.com [68.142.206.158]) by mx1.FreeBSD.org (Postfix) with SMTP id AA72C43D45 for ; Fri, 2 Sep 2005 22:25:03 +0000 (GMT) (envelope-from psamuel01@yahoo.com) Received: (qmail 12885 invoked by uid 60001); 2 Sep 2005 22:25:03 -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=dmrV+V73FKk+l5tjd20jqiDe+3m+uVrJg9rjk+DTuI/dcn/ELycoak8BD8G29NiB4W3VtqSnZLIrJsiFfN1y1FJI0K7nnF0jMMNNheN6VvZkhwT3z8Vh2zJxxgF8sTRwpG3OV0PviQy/jYqAH0CwYYdAlwKzBqYAsLN1YjwSyFk= ; Message-ID: <20050902222503.12883.qmail@web33509.mail.mud.yahoo.com> Received: from [12.2.142.7] by web33509.mail.mud.yahoo.com via HTTP; Fri, 02 Sep 2005 15:25:02 PDT Date: Fri, 2 Sep 2005 15:25:02 -0700 (PDT) From: Dean Patterson To: Kevin Oberman In-Reply-To: <20050902215638.3381E5D07@ptavv.es.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: Installation error Intel mobile ICH6M SATA controller. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2005 22:25:04 -0000 This occurred with 5.3/5.4-Release, 6-Current snapshot from June/July, and 6.0-BETA1/2. So I have tried them all. I have tried both a minimal cd using my NFS server to downloading the 6.0-BETA2 disc1. I always do a minimal install and as far as partitions I have tried the following; 1) Dangerously dedicated with one partition 2) One 20GB partition on a 40G HD and 3) Dual-booting with Windows hoping the NT loader woudl boot it. I even tried an FTP install from a mirror so I have tried several combos. I dont see how it is a configuration error when it happens each time. Please elaborate? --- Kevin Oberman wrote: > > Date: Fri, 2 Sep 2005 14:32:13 -0700 (PDT) > > From: Dean Patterson > > Sender: owner-freebsd-current@freebsd.org > > > > PLEASE save me from LINUX!! I can install FBSD on > a > > Dell D610 laptop just fine, but when I reboot it > does > > not recognize the drive/controller. When I > install > > the boot loader I am presented with the F1 option > and > > when pressed I get "invalid slice." When I > install a > > standard MBR I get "invalid partition table." Any > > fixes or patches? I enjoy Gentoo, but I REALLY > MISS > > FREEBSD!! > > A little more information, please. > > What version of FreeBSD are you attempting to > install? > Which install did you do? > How did you slice the disk? > How did you partition the slice? > > If you boot the install floppy, can you start the > holographic shell and > do an "fdisk ad0"? "bsdlabel ad0s1"? I suspect > something went awry in > the configuration process. > > The exact details of how to do the above depends on > just what version > you were installing, but I'm assuming it was V6Beta? > or you would have > sent your message to questions@ and not to current@. > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory > (Berkeley Lab) > E-mail: oberman@es.net Phone: +1 510 486-8634 > ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From owner-freebsd-current@FreeBSD.ORG Fri Sep 2 23:04:57 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 7896E16A41F for ; Fri, 2 Sep 2005 23:04:57 +0000 (GMT) (envelope-from jay@codegurus.org) Received: from ptb-relay01.plus.net (ptb-relay01.plus.net [212.159.14.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E2FB43D46 for ; Fri, 2 Sep 2005 23:04:57 +0000 (GMT) (envelope-from jay@codegurus.org) Received: from jayton.plus.com ([84.92.156.191] helo=[127.0.0.1]) by ptb-relay01.plus.net with esmtp (Exim) id 1EBKac-0006kC-D3 for freebsd-current@freebsd.org; Sat, 03 Sep 2005 00:04:54 +0100 Message-ID: <4318DA9A.6030300@codegurus.org> Date: Sat, 03 Sep 2005 00:04:58 +0100 From: Jayton Garnett User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: OvisLink Wireless X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jay@codegurus.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2005 23:04:57 -0000 Hello, Could anyone tell me if there are plans to introduce the OvisLink Wireless network cards into FreeBSD? The one I have uses a Texas Instruments chipset. http://www.ovislinkcorp.co.uk/wl8000pci.htm I have done a search on 5.4R but this card is not supported, only two other OvisLink Cards are supported. If you require any technical information about the card I would be more than willing to dig up some info if it means the driver will make it into ANY future release of FreeBSD. Also... would anyone know why my Linksys Router's wireless interface keeps going down? The cat5 cable interface still works fine, and I just have too reboot the router. -- Kind regards, Jayton Garnett email: jay@codegurus.org Main : www.uberhacker.co.uk Test server: jayton.plus.com From owner-freebsd-current@FreeBSD.ORG Fri Sep 2 23:48: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 3F2AD16A41F for ; Fri, 2 Sep 2005 23:48:11 +0000 (GMT) (envelope-from fbsd-current@mawer.org) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC73043D45 for ; Fri, 2 Sep 2005 23:48:10 +0000 (GMT) (envelope-from fbsd-current@mawer.org) Received: from [127.0.0.1] (c220-237-120-88.thorn1.nsw.optusnet.com.au [220.237.120.88]) by mail09.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j82Nm66U023404; Sat, 3 Sep 2005 09:48:09 +1000 Message-ID: <4318E4B5.5040800@mawer.org> Date: Sat, 03 Sep 2005 09:48:05 +1000 From: Antony Mawer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeremie Le Hen References: <8b6eae9605090106151a81174d@mail.gmail.com> <20050902221724.GC659@obiwan.tataz.chchile.org> In-Reply-To: <20050902221724.GC659@obiwan.tataz.chchile.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Edwin Brown Subject: Re: FreeBSD6.0 and VMWare 5.0.. No go X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2005 23:48:11 -0000 On 3/09/2005 8:17 AM, Jeremie Le Hen wrote: >>This morning I tried to install FreeBSD6.0 under VMWare 5. I got >>the following message when it was extracting the base into \ >>directory: >> >>Panic: duplicate free of item 0xc1c5a210 from zone 0xc143f000(g_bio) >> >>cpuid=0 >>KDB: enter: panic >>[thread pid 3 tid 100034 ] >>stopped at kdb_enter+0x2b: nop >>db> >> >>Is this a known issue? > > Don't know if it's a known issue, but can you use the "trace" DDB > command and post the output here please, this will greatly help > debugging for kernel hackers. > > Regards, I did this the other day, and after searching the PR database, turned up this: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/84102 which has the same stack trace that I was getting out of DDB. -Antony From owner-freebsd-current@FreeBSD.ORG Sat Sep 3 00:24: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 7542D16A41F; Sat, 3 Sep 2005 00:24:44 +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 042B043D48; Sat, 3 Sep 2005 00:24:43 +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.3/8.13.3) with ESMTP id j830Oh5T040086; Fri, 2 Sep 2005 20:24:43 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j830OgX1044556; Fri, 2 Sep 2005 20:24:42 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id CC2527304D; Fri, 2 Sep 2005 20:24:42 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050903002442.CC2527304D@freebsd-current.sentex.ca> Date: Fri, 2 Sep 2005 20:24:42 -0400 (EDT) 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: Sat, 03 Sep 2005 00:24:44 -0000 TB --- 2005-09-02 22:54:32 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-09-02 22:54:32 - starting HEAD tinderbox run for alpha/alpha TB --- 2005-09-02 22:54:32 - cleaning the object tree TB --- 2005-09-02 22:54:58 - checking out the source tree TB --- 2005-09-02 22:54:58 - cd /tinderbox/HEAD/alpha/alpha TB --- 2005-09-02 22:54:58 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-09-02 23:01:40 - building world (CFLAGS=-O2 -pipe) TB --- 2005-09-02 23:01:40 - cd /src TB --- 2005-09-02 23:01:40 - /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-09-03 00:04:59 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-09-03 00:04:59 - cd /src TB --- 2005-09-03 00:04:59 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Sep 3 00:04:59 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 >>> Kernel build for GENERIC completed on Sat Sep 3 00:18:15 UTC 2005 TB --- 2005-09-03 00:18:15 - generating LINT kernel config TB --- 2005-09-03 00:18:15 - cd /src/sys/alpha/conf TB --- 2005-09-03 00:18:15 - /usr/bin/make -B LINT TB --- 2005-09-03 00:18:15 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-09-03 00:18:15 - cd /src TB --- 2005-09-03 00:18:15 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Sep 3 00:18: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 >>> 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/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -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/fs/fdescfs/fdesc_vnops.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/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -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/fs/fifofs/fifo_vnops.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/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -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/fs/hpfs/hpfs_alsubr.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/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -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/fs/hpfs/hpfs_lookup.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/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -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/fs/hpfs/hpfs_subr.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/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -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/fs/hpfs/hpfs_vfsops.c /src/sys/fs/hpfs/hpfs_vfsops.c: In function `hpfs_mount': /src/sys/fs/hpfs/hpfs_vfsops.c:198: error: label `error_2' used but not defined *** Error code 1 Stop in /obj/alpha/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-09-03 00:24:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-09-03 00:24:42 - ERROR: failed to build lint kernel TB --- 2005-09-03 00:24:42 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sat Sep 3 00:50: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 79D8416A41F for ; Sat, 3 Sep 2005 00:50:33 +0000 (GMT) (envelope-from dmp@bitfreak.org) Received: from mail.bitfreak.org (mail.bitfreak.org [65.75.198.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FFE143D8C for ; Sat, 3 Sep 2005 00:50:28 +0000 (GMT) (envelope-from dmp@bitfreak.org) Received: from SMILEY (mail.bitfreak.org [65.75.198.146]) by mail.bitfreak.org (Postfix) with ESMTP id 3356819F3B; Fri, 2 Sep 2005 17:54:04 -0700 (PDT) From: "Darren Pilgrim" To: "'Dean Patterson'" , Date: Fri, 2 Sep 2005 17:50:27 -0700 Message-ID: <000d01c5b021$7a812320$642a15ac@SMILEY> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <20050902213213.34328.qmail@web33508.mail.mud.yahoo.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Cc: Subject: RE: Installation error Intel mobile ICH6M SATA controller. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Sep 2005 00:50:33 -0000 From: Dean Patterson >=20 > PLEASE save me from LINUX!! I can install FBSD on a > Dell D610 laptop just fine, but when I reboot it does > not recognize the drive/controller. When I install > the boot loader I am presented with the F1 option and > when pressed I get "invalid slice." When I install a > standard MBR I get "invalid partition table." Any > fixes or patches? I enjoy Gentoo, but I REALLY MISS > FREEBSD!! Run the fix-it shell and check which slices are marked active using fdisk. I don't know what the boot loader would do, but the standard MBR will tell you the partition table isn't valid if there are no active slices. I've run into this issue where sysinstall doesn't automatically mark the FreeBSD root slice active and doesn't warn you about having to explicitly mark slice(s) active during install. Tip: In most cases and assuming you not running something else as well, your Windows and FreeBSD root slices should be the only slices marked active. From owner-freebsd-current@FreeBSD.ORG Sat Sep 3 01:32: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 1403616A41F for ; Sat, 3 Sep 2005 01:32:41 +0000 (GMT) (envelope-from dandee@hellteam.net) Received: from pipa.profix.cz (pipa.profix.cz [82.208.25.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 932D643D45 for ; Sat, 3 Sep 2005 01:32:40 +0000 (GMT) (envelope-from dandee@hellteam.net) Received: from localhost (localhost [127.0.0.1]) by pipa.profix.cz (Postfix) with ESMTP id 981064E706; Sat, 3 Sep 2005 03:32:46 +0200 (CEST) Received: from pipa.profix.cz ([127.0.0.1]) by localhost (pipa [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12258-01; Sat, 3 Sep 2005 03:32:46 +0200 (CEST) Received: from gandalf (unknown [80.95.121.105]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by pipa.profix.cz (Postfix) with ESMTP id 5C06C4E704; Sat, 3 Sep 2005 03:32:46 +0200 (CEST) From: =?us-ascii?Q?Daniel_Dvorak?= To: "'Edwin Brown'" , Date: Sat, 3 Sep 2005 03:32:37 +0200 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.2527 In-Reply-To: <8b6eae9605090106151a81174d@mail.gmail.com> thread-index: AcWvt5L/kdC0Cm+WTPy64Gs5FfD4EwAb2zoA Message-Id: <20050903013246.5C06C4E704@pipa.profix.cz> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at profix.cz Cc: Subject: RE: FreeBSD6.0 and VMWare 5.0.. No go X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dandee@volny.cz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2005 01:32:41 -0000 Yes, I confirm this. :( I tried to install 32bit and 64bit version and both stoped with this panic. It hapens when installation proccess copy files to disk, usually. Dan -----Original Message----- From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd-current@freebsd.org] On Behalf Of Edwin Brown Sent: Thursday, September 01, 2005 3:15 PM To: freebsd-stable@freebsd.org; freebsd-current@freebsd.org Subject: FreeBSD6.0 and VMWare 5.0.. No go This morning I tried to install FreeBSD6.0 under VMWare 5. I got the following message when it was extracting the base into \ directory: Panic: duplicate free of item 0xc1c5a210 from zone 0xc143f000(g_bio) cpuid=0 KDB: enter: panic [thread pid 3 tid 100034 ] stopped at kdb_enter+0x2b: nop db> Is this a known issue? Best regards, Edwin _______________________________________________ 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 Sat Sep 3 01:35: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 83F2A16A41F for ; Sat, 3 Sep 2005 01:35:32 +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 A54F743D46 for ; Sat, 3 Sep 2005 01:35:29 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp200-227.lns1.adl4.internode.on.net [203.122.200.227]) (authenticated bits=0) by cain.gsoft.com.au (8.13.4/8.13.4) with ESMTP id j831Z9AH091937 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 3 Sep 2005 11:05:14 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org, jay@codegurus.org Date: Sat, 3 Sep 2005 11:04:47 +0930 User-Agent: KMail/1.8.1 References: <4318DA9A.6030300@codegurus.org> In-Reply-To: <4318DA9A.6030300@codegurus.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1730358.SZ1VszJoyD"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200509031104.59199.doconnor@gsoft.com.au> X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.51 on 203.31.81.10 Cc: Subject: Re: OvisLink Wireless X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Sep 2005 01:35:32 -0000 --nextPart1730358.SZ1VszJoyD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 03 September 2005 08:34, Jayton Garnett wrote: > Could anyone tell me if there are plans to introduce the OvisLink > Wireless network cards into FreeBSD? > The one I have uses a Texas Instruments chipset. > http://www.ovislinkcorp.co.uk/wl8000pci.htm > I have done a search on 5.4R but this card is not supported, only two > other OvisLink Cards are supported. > > If you require any technical information about the card I would be more > than willing to dig up some info if it > means the driver will make it into ANY future release of FreeBSD. I don't believe Ti release enough information on their chipsets to allow=20 people to write drivers - certainly the only way I am aware of to use stuff= =20 based on their chips is via ndis (which mostly works) I recommend you dig up an Atheros based card since it will almost certainly= be=20 supported now or in the very near future, and it supports a company that=20 supplies drivers for FreeBSD/Linux/etc not just Windows. eg http://www.aria.co.uk/wifi/product_info.asp?productid=3D14956 http://www.multitask-computing.co.uk/catalog/product_info.php?products_id= =3D275 > Also... would anyone know why my Linksys Router's wireless interface > keeps going down? The > cat5 cable interface still works fine, and I just have too reboot the > router. Broken firmware? =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 --nextPart1730358.SZ1VszJoyD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBDGP3D5ZPcIHs/zowRAhbUAKCW6q8XYKqi2ZvdTxXizNBd+4Ls0ACeO/Xh 1Q8SH/qA444B/vQtn0V+4FA= =U2aX -----END PGP SIGNATURE----- --nextPart1730358.SZ1VszJoyD-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 3 02:25: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 5D93D16A41F; Sat, 3 Sep 2005 02:25:13 +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 D66E943D46; Sat, 3 Sep 2005 02:25:12 +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.3/8.13.3) with ESMTP id j832PBN5045252; Fri, 2 Sep 2005 22:25:11 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j832PBPI029190; Fri, 2 Sep 2005 22:25:11 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 7CEAE7304D; Fri, 2 Sep 2005 22:25:11 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050903022511.7CEAE7304D@freebsd-current.sentex.ca> Date: Fri, 2 Sep 2005 22:25:11 -0400 (EDT) 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 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: Sat, 03 Sep 2005 02:25:13 -0000 TB --- 2005-09-03 00:24:43 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-09-03 00:24:43 - starting HEAD tinderbox run for amd64/amd64 TB --- 2005-09-03 00:24:43 - cleaning the object tree TB --- 2005-09-03 00:25:20 - checking out the source tree TB --- 2005-09-03 00:25:20 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2005-09-03 00:25:20 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-09-03 00:32:02 - building world (CFLAGS=-O2 -pipe) TB --- 2005-09-03 00:32:02 - cd /src TB --- 2005-09-03 00:32: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-09-03 02:02:20 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-09-03 02:02:20 - cd /src TB --- 2005-09-03 02:02:20 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Sep 3 02:02: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 >>> Kernel build for GENERIC completed on Sat Sep 3 02:18:02 UTC 2005 TB --- 2005-09-03 02:18:02 - generating LINT kernel config TB --- 2005-09-03 02:18:02 - cd /src/sys/amd64/conf TB --- 2005-09-03 02:18:02 - /usr/bin/make -B LINT TB --- 2005-09-03 02:18:02 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-09-03 02:18:02 - cd /src TB --- 2005-09-03 02:18:02 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Sep 3 02:18:02 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/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -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/fs/fdescfs/fdesc_vnops.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/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -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/fs/fifofs/fifo_vnops.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/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -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/fs/hpfs/hpfs_alsubr.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/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -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/fs/hpfs/hpfs_lookup.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/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -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/fs/hpfs/hpfs_subr.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/dev/acpica -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/contrib/dev/ath -I/src/sys/contrib/dev/ath/freebsd -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -D_KERNEL -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/fs/hpfs/hpfs_vfsops.c /src/sys/fs/hpfs/hpfs_vfsops.c: In function `hpfs_mount': /src/sys/fs/hpfs/hpfs_vfsops.c:198: error: label `error_2' used but not defined *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-09-03 02:25:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-09-03 02:25:11 - ERROR: failed to build lint kernel TB --- 2005-09-03 02:25:11 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sat Sep 3 04:01: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 98F7E16A41F for ; Sat, 3 Sep 2005 04:01:22 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39E5E43D45 for ; Sat, 3 Sep 2005 04:01:22 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.89] ([66.127.85.89]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j8341KBd094585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Sep 2005 21:01:21 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <4319200A.2010702@errno.com> Date: Fri, 02 Sep 2005 21:01:14 -0700 From: Sam Leffler User-Agent: Mozilla Thunderbird 0.8 (X11/20041021) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vitaly References: <430060FB.1000405@tikhvin.info> <4314537C.5050808@tikhvin.info> <4314A32A.9050105@errno.com> <43183E7D.50802@tikhvin.info> In-Reply-To: <43183E7D.50802@tikhvin.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: ath bridge panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Sep 2005 04:01:22 -0000 Vitaly wrote: > >> >> Still exists with what version of the system? If you haven't tried >> BETA3 then do that first. >> >> To get something like this fixed you need to provide the steps needed >> to reproduce the problem. >> > I tried BETA3, while client authentification in progress i get error > messages but after all ok without panic Sorry but I do not understand "while cleint authentication in progress". Is this an ap? Where is the configuration? What client is this? > > ath0: device timeout > ath0: device timeout > ath0: device timeout > ath0: device timeout These should not happen. > couldn't m_pullup > couldn't m_pullup > couldn't m_pullup > couldn't m_pullup > couldn't m_pullup Haven't a clue where these msgs come from. > .... > > but i have another problem here - 80211b PDA client success communicates > with another 80211g client, but not with 80211b client > what debug modes i must set to athdebug to view activity with this problem > ath is the wrong level to look for problems; look at the net80211 level. I have a number of changes in current that have yet to be MFC'd to RELENG_6 for ap operation so they may help you. Also I'm aware that 11g ap operation is not right for a mixed-bss. The ap does not announce a revised ERP information element in the beacons when non-ERP stations join/leave the bss so a mixed station bss may not function correctly due to inconsistent setup of preamble and/or protection. No eta on when that'll be fixed; it's easy but my time is limited right now. Sam From owner-freebsd-current@FreeBSD.ORG Sat Sep 3 05:33: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 06D7816A41F for ; Sat, 3 Sep 2005 05:33:50 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9078143D45 for ; Sat, 3 Sep 2005 05:33:46 +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.3/8.13.3) with ESMTP id j835lhP1001892; Fri, 2 Sep 2005 23:47:44 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <431935B7.6040904@samsco.org> Date: Fri, 02 Sep 2005 23:33:43 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dandee@volny.cz References: <20050903013246.5C06C4E704@pipa.profix.cz> In-Reply-To: <20050903013246.5C06C4E704@pipa.profix.cz> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: freebsd-current@freebsd.org, 'Edwin Brown' Subject: Re: FreeBSD6.0 and VMWare 5.0.. No go X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Sep 2005 05:33:50 -0000 Daniel Dvorak wrote: > Yes, I confirm this. :( > > I tried to install 32bit and 64bit version and both stoped with this panic. > It hapens when installation proccess copy files to disk, usually. > > Dan If anyone is interested, I have a FreeBSD 6 snapshot ISO with a custom kernel that has PREEMPTION, SMP, and apic removed. I've been trying to get it to work on VirtualPC, but I'm running into other problems with it now (mainly that VPC doesn't seem to expose the CDROM in a way that FreeBSD can find it). If anyone is interested in testing it with VMWare, let me know and I'll make it available. It's a normal disc1 install ISO, based on 6-BETA3. Scott From owner-freebsd-current@FreeBSD.ORG Sat Sep 3 05:33: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 B600716A424 for ; Sat, 3 Sep 2005 05:33:55 +0000 (GMT) (envelope-from andrew@fubar.geek.nz) Received: from avmta4-rme.xtra.co.nz (avmta4-rme.xtra.co.nz [210.86.15.159]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC30443D45 for ; Sat, 3 Sep 2005 05:33:54 +0000 (GMT) (envelope-from andrew@fubar.geek.nz) Received: from mta3-rme.xtra.co.nz ([210.86.15.143]) by avmta4-rme.xtra.co.nz with ESMTP id <20050903053353.OCMK9771.avmta4-rme.xtra.co.nz@mta3-rme.xtra.co.nz>; Sat, 3 Sep 2005 17:33:53 +1200 Received: from serv.int.fubar.geek.nz ([222.152.103.73]) by mta3-rme.xtra.co.nz with ESMTP id <20050903053353.LUKY1650.mta3-rme.xtra.co.nz@serv.int.fubar.geek.nz>; Sat, 3 Sep 2005 17:33:53 +1200 Received: from [192.168.1.160] (unknown [192.168.1.160]) by serv.int.fubar.geek.nz (Postfix) with ESMTP id 353FD60FB; Sat, 3 Sep 2005 17:33:52 +1200 (NZST) Message-ID: <431935C8.2060900@fubar.geek.nz> Date: Sat, 03 Sep 2005 17:34:00 +1200 From: Andrew Turner User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050727) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Ullrich References: <8b6eae9605090106151a81174d@mail.gmail.com> <20050902221724.GC659@obiwan.tataz.chchile.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Jeremie Le Hen , Edwin Brown Subject: Re: FreeBSD6.0 and VMWare 5.0.. No go X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Sep 2005 05:33:56 -0000 Scott Ullrich wrote: > >Not sure if this is related or not but the SoC for BSDInstaller mentions: > >* Add a kernel without PREEMPTION for Qemu and Vmware > >http://wikitest.freebsd.org/moin.cgi/BSDInstaller > > I found by removing PREEMPTION from the kernel it would stop the panic. I would get http://sources.zabbadoz.net/freebsd/lor.html#007 instead but this is harmless. I never had this problem on real hardware so made a second NOPREEMPTION kernel (http://perforce.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/soc2005/bsdinstaller/src/sys/i386/conf/NOPREEMPTION&REV=1) and added "KERNELS=NOPREEMPTION" to the make release command line. Andrew From owner-freebsd-current@FreeBSD.ORG Sat Sep 3 05:59: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 9F12916A41F for ; Sat, 3 Sep 2005 05:59:04 +0000 (GMT) (envelope-from psamuel01@yahoo.com) Received: from web33501.mail.mud.yahoo.com (web33501.mail.mud.yahoo.com [68.142.206.150]) by mx1.FreeBSD.org (Postfix) with SMTP id 3FD1A43D46 for ; Sat, 3 Sep 2005 05:59:04 +0000 (GMT) (envelope-from psamuel01@yahoo.com) Received: (qmail 19845 invoked by uid 60001); 3 Sep 2005 05:59:03 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=xmbmmwzG1mGk+Ud1q545qsMLcSYxKfHUCzWIKGPmm6xpOj+n5vb9vGGfofdWWbynC98cOj8xaw5HcaZgj6R0bJx2LBEEqhlUbog2fXPjDM0yOTarlIjDCN1fE9go0obEWpujmywSD7U8IjQt8F7u+6ad7vyu+f5kSKlIHUlRmqU= ; Message-ID: <20050903055903.19843.qmail@web33501.mail.mud.yahoo.com> Received: from [24.208.219.212] by web33501.mail.mud.yahoo.com via HTTP; Fri, 02 Sep 2005 22:59:03 PDT Date: Fri, 2 Sep 2005 22:59:03 -0700 (PDT) From: Dean Patterson To: Darren Pilgrim , freebsd-current@freebsd.org In-Reply-To: <000d01c5b021$7a812320$642a15ac@SMILEY> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: RE: Installation error Intel mobile ICH6M SATA controller. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Sep 2005 05:59:04 -0000 I am sorry I should have mentioned that I also tried explicitly setting the slice active. I will try again and check it using the shell; however, when I tried using the holographic shell nothing worked. I tried using fdisk, bsdlabel, and ls and I always get the message "command not found." --- Darren Pilgrim wrote: > From: Dean Patterson > > > > PLEASE save me from LINUX!! I can install FBSD on > a > > Dell D610 laptop just fine, but when I reboot it > does > > not recognize the drive/controller. When I > install > > the boot loader I am presented with the F1 option > and > > when pressed I get "invalid slice." When I > install a > > standard MBR I get "invalid partition table." Any > > fixes or patches? I enjoy Gentoo, but I REALLY > MISS > > FREEBSD!! > > Run the fix-it shell and check which slices are > marked active using > fdisk. I don't know what the boot loader would do, > but the standard MBR > will tell you the partition table isn't valid if > there are no active > slices. I've run into this issue where sysinstall > doesn't automatically > mark the FreeBSD root slice active and doesn't warn > you about having to > explicitly mark slice(s) active during install. > > Tip: In most cases and assuming you not running > something else as well, > your Windows and FreeBSD root slices should be the > only slices marked > active. > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-current@FreeBSD.ORG Sat Sep 3 06:29: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 E14B516A41F for ; Sat, 3 Sep 2005 06:29:44 +0000 (GMT) (envelope-from dmp@bitfreak.org) Received: from mail.bitfreak.org (mail.bitfreak.org [65.75.198.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B31743D45 for ; Sat, 3 Sep 2005 06:29:44 +0000 (GMT) (envelope-from dmp@bitfreak.org) Received: from SMILEY (mail.bitfreak.org [65.75.198.146]) by mail.bitfreak.org (Postfix) with ESMTP id 08E0819F3B; Fri, 2 Sep 2005 23:33:22 -0700 (PDT) From: "Darren Pilgrim" To: "'Dean Patterson'" Date: Fri, 2 Sep 2005 23:29:45 -0700 Message-ID: <000b01c5b050$e118fa70$642a15ac@SMILEY> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <20050903055903.19843.qmail@web33501.mail.mud.yahoo.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Cc: freebsd-current@freebsd.org Subject: RE: Installation error Intel mobile ICH6M SATA controller. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Sep 2005 06:29:45 -0000 From: Dean Patterson [mailto:psamuel01@yahoo.com]=20 >=20 > I am sorry I should have mentioned that I also tried > explicitly setting the slice active. I will try again > and check it using the shell; however, when I tried > using the holographic shell nothing worked. I tried > using fdisk, bsdlabel, and ls and I always get the > message "command not found." The holographic shell is not the same as the fix-it shell. The holographic shell lacks, among other things proper paths, which makes it impossible to run many programs. The "Fix-It" shell is a menu option in sysinstall and starts a fully-functional shell. From owner-freebsd-current@FreeBSD.ORG Sat Sep 3 07:52: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 E8D4816A420 for ; Sat, 3 Sep 2005 07:52:17 +0000 (GMT) (envelope-from psamuel01@yahoo.com) Received: from web33506.mail.mud.yahoo.com (web33506.mail.mud.yahoo.com [68.142.206.155]) by mx1.FreeBSD.org (Postfix) with SMTP id 5ED5243D4C for ; Sat, 3 Sep 2005 07:52:17 +0000 (GMT) (envelope-from psamuel01@yahoo.com) Received: (qmail 64010 invoked by uid 60001); 3 Sep 2005 07:52:16 -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=Nq9D4R/ggeclLiXm2nr8fhB8ftRHlZeJnU+3QNzGZxJDzQPjWRObRR6LeQ6zL5cGvE1xezo3BoJ4vU4ecHQ/eHPQmT7h/oTTGf7msdrj1AB8ixaPPTqZ+UIAOD/xQkawqGLYe5BUOuSOzA+nc6ISQhn0rbG3Znc0KYc67qD1LQ4= ; Message-ID: <20050903075216.64008.qmail@web33506.mail.mud.yahoo.com> Received: from [24.208.219.212] by web33506.mail.mud.yahoo.com via HTTP; Sat, 03 Sep 2005 00:52:16 PDT Date: Sat, 3 Sep 2005 00:52:16 -0700 (PDT) From: Dean Patterson To: Darren Pilgrim In-Reply-To: <000b01c5b050$e118fa70$642a15ac@SMILEY> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: RE: Installation error Intel mobile ICH6M SATA controller. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Sep 2005 07:52:18 -0000 Ah I see. Thank you for the speedy reply and I will try it soon and let you know if that is the issue. --- Darren Pilgrim wrote: > From: Dean Patterson [mailto:psamuel01@yahoo.com] > > > > I am sorry I should have mentioned that I also > tried > > explicitly setting the slice active. I will try > again > > and check it using the shell; however, when I > tried > > using the holographic shell nothing worked. I > tried > > using fdisk, bsdlabel, and ls and I always get the > > message "command not found." > > The holographic shell is not the same as the fix-it > shell. The > holographic shell lacks, among other things proper > paths, which makes it > impossible to run many programs. The "Fix-It" shell > is a menu option in > sysinstall and starts a fully-functional shell. > > ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From owner-freebsd-current@FreeBSD.ORG Sat Sep 3 08:59: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 3399616A41F for ; Sat, 3 Sep 2005 08:59:50 +0000 (GMT) (envelope-from dan.cojocar@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98B7143D46 for ; Sat, 3 Sep 2005 08:59:49 +0000 (GMT) (envelope-from dan.cojocar@gmail.com) Received: by xproxy.gmail.com with SMTP id h32so298392wxd for ; Sat, 03 Sep 2005 01:59:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type; b=MroIyKAjA7ye0TPerTto4e/9yXZl5yt19Gp44a3oT3ag79zd8PCy4vNMiLhNuyBeK3QA1VU6CcAs851aF0ldR0DL91BDI6oeYHat6uQnKaYRnb8Zjuims89rYZzBBe01BSo/rAENCaywDLcTcM+YlSgVoCxwzVJdOGabCW9L7ho= Received: by 10.70.58.20 with SMTP id g20mr3347wxa; Sat, 03 Sep 2005 01:59:48 -0700 (PDT) Received: by 10.70.56.10 with HTTP; Sat, 3 Sep 2005 01:59:48 -0700 (PDT) Message-ID: Date: Sat, 3 Sep 2005 11:59:48 +0300 From: Dan Cojocar To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: LOR in /usr/src/sys/kern/kern_descrip.c:1876 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dan.cojocar@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2005 08:59:50 -0000 Here is a LOR that i don't find on: sources.zabbadoz.net . I received this after booting current from: 7.0-CURRENT FreeBSD 7.0-CURRENT#1: Sat Sep 3 11:35:25 EEST 2005 lock order reversal 1st 0xc0655660 Giant (Giant) @ /usr/src/sys/kern/kern_descrip.c:1876 2nd 0xc06a3eec udp (udp) @ /usr/src/sys/netinet6/udp6_usrreq.c:674 KDB: stack backtrace: witness_checkorder(c06a3eec,9,c06185b2,2a2,0) at witness_checkorder+0x51c _mtx_lock_flags(c06a3eec,0,c06185b2,2a2,c1ba23f0) at _mtx_lock_flags+0x54 udp6_detach(c1c696f4,c06060df,8,c19747f0,849) at udp6_detach+0x2b soclose(c1c696f4,12c,0,c1ba23f0,c1ba23f0) at soclose+0x187 soo_close(c1ba23f0,c1aa14b0,c06060df,849,c1ce6770) at soo_close+0x37 fdrop_locked(c1ba23f0,c1aa14b0,c06060df,77f,64a,d5735ba0,1,c06060df,c063303= c,c1aa1528,64c,c06060df,8,c1ce672c,64c,c06060df,d5735bd8,c04911f2,c1ce672c,= 1,c06086ec,12c,0) at fdrop_locked+0xb5 closef(c1ba23f0,c1aa14b0,c06060df,64c,8) at closef+0x25 fdfree(c1aa14b0,8,c0606814,e6,c060aa55) at fdfree+0x264 exit1(c1aa14b0,0,d5735d30,c05e707d,c1aa14b0) at exit1+0x346 sys_exit(c1aa14b0,d5735d04,4,1,1) at sys_exit+0x1d syscall(3b,3b,3b,28054540,bfbfeeb0) at syscall+0x13d Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (1, FreeBSD ELF32, sys_exit), eip =3D 0x28148453, esp =3D=20 0xbfbfee5c, ebp =3D 0xbfbfee68 --- Dan From owner-freebsd-current@FreeBSD.ORG Sat Sep 3 11:01: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 B985A16A41F for ; Sat, 3 Sep 2005 11:01:22 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7005A43D55 for ; Sat, 3 Sep 2005 11:01:21 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [10.1.1.7]) (authenticated bits=0) by srv1.cosmo-project.de (8.12.10/8.12.10) with ESMTP id j83B1EBS022930 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sat, 3 Sep 2005 13:01:16 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id j83B0gqK032316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 Sep 2005 13:00:42 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.11/8.12.11) with ESMTP id j83B0fjH013658; Sat, 3 Sep 2005 13:00:41 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id j83B0a9V013657; Sat, 3 Sep 2005 13:00:36 +0200 (CEST) (envelope-from ticso) Date: Sat, 3 Sep 2005 13:00:36 +0200 From: Bernd Walter To: Scott Long Message-ID: <20050903110035.GN3267@cicely12.cicely.de> References: <1125452228.740.3.camel@arbitor.homelinux.com> <47d0403c05083020044f6ac0be@mail.gmail.com> <4315CEEC.80100@samsco.org> <20050831174631.GE37930@cicely12.cicely.de> <4315F15D.4090209@samsco.org> <20050831221535.GB670@cicely12.cicely.de> <4316370E.4030809@samsco.org> <20050901000216.GD670@cicely12.cicely.de> <43164B88.8010903@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43164B88.8010903@samsco.org> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 X-Spam-Report: * -3.3 ALL_TRUSTED Did not pass through any untrusted hosts * -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on cicely12.cicely.de Cc: freebsd-current@freebsd.org, Kyle Brooks , ticso@cicely.de, Ben Kaduk Subject: Re: panic after removing usb flash drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2005 11:01:22 -0000 On Wed, Aug 31, 2005 at 06:30:00PM -0600, Scott Long wrote: > Bernd Walter wrote: > >On Wed, Aug 31, 2005 at 05:02:38PM -0600, Scott Long wrote: > >>Bernd Walter wrote: > >>>On Wed, Aug 31, 2005 at 12:05:17PM -0600, Scott Long wrote: > You could probably get around the problem of sleeping in the USB event > thread by doing the sleep parts of the detach in a taskqueue. But that > just adds more complexity and more need for synchronization. If the > only choice was to retain the SIM-per-device model then this is what I > would do, but it's not a choice that I like. I don't see how your single-SIM per bus solves that problem - you still have to delete a SIM in case an USB-controller is detached. USB-controller detachments can happen more often as one think, e.g. in case of a cardbus host controller. > >What I mean is a single USB device with multiple umass instances. > >umass ist just a logical interface in the USB world, normaly ment > >to allow e.g. an ulpt and umass on the same USB device, but also > >possible to have multiple umass interfaces on the same USB device. > >Since an umass interface needs at least two bulk endpoints a single > >USB-channel can have up to 16 * 127 umass instances. > > > > CAM right now is really geared for parallel SCSI with only 16 targets, > but it should work fine with 2048 targets. A project for CAMng is to > properly support FC fabrics properly as well as iSCSI; in both cases > the max-target-per-bus concept has little meaning and would need > fundamental changes. That's future work, though. OK - 2048 per bus should be fine for any possible case of umass compliant devices. I personally was worried about bus scan-time with that many targets. > For a physical device with multiple umass logical devices, each logical > device would again just be a target. The actual target and bus numbers > don't really matter in practical use because they aren't exposed to > /dev. To make it truly transparent we would need to have an automounter > like other OSes that mounts based on filesystem label, not based on > device node name. But that's mostly a detail at this point. Not exactly the same, but there is already glabel. > >OK - I got it now. > >Nevertheless I could imagine a pseudo USB-SCSI converter that just > >enhances umass transactions with a target-ID. > >This won't invalidate what you wrote above, since you still don't have > >full access on the SCSI-bus, but also requires a sim per (enhanced)umass. > > > > I assume that this is really just a mythical device, right? If it were > really just a very simple extension of the umass protocol then I'd > probably elect to treat it as multiple targets with the same single > SIM. USB to SCSI converters do exist, but I don't know if ant of them is really based on umass, so yes one can call it mythical. > >>>OK - that won't help for a practical solution. > >>>In the practical way it sounded easier to go the multiple sim way. > >>>sim detach needs to be fixed either way. > >> > >>Yes. It somewhat works now as long as the system is completely idle. > >>It breaks down horribly if I/O or error recovery is in progress and > >>a periph driver is left with CCBs in flight and/or a dangling > >>reference to a SIM. The only way to deal with this is to allow > >>blocking while CAM drains itself. > > > > > >Have to think about it. OK - dangling SIM reference is bad. But Sorry - I still don't understand any other influences. In which way a loaded single SIM system is in a better position than a multi SIM one? > >>>Are there any other technical reasons for doing single sim? > >>>You've mentioned rescource arbitration and error recovery. > >>>Is there anything that can CAM do for us that it won't with multiple > >>>sim? > >>> > >> > >>It means that you'll be able to detach umass targets without doing the > >>complicated dance of sleeping for CAM to drain itself. It also will Ack, but your proposed way of using a SIM per bus still requires SIM detaching in some cases. In the meantime I understood your point of view why you think that SIMs are logically assigned with the USB channels, but I still don't understand what it brings code-wise. I still don't see any other positive effects other than reducing the places where we need to detach a SIM. > So was the motivation to change from a single SIM to SIM-per-device > based solely on the problem of doing manual bus rescans when a device > got inserted? If not, what were the other problems that got solved? The motivation was a mix of rescan, max_lun and flexibility for mythical devices. > Btw, I envision my changes resulting in a SIM per USB controller. So > on a system with 3-4 controllers (as seem to be common these days), > you'd have that many SIMs. umass targets would be paired with the SIM > that was associated with the physical USB controller/bus of the target. > > Scott -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de From owner-freebsd-current@FreeBSD.ORG Sat Sep 3 01:44: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 7C34C16A41F for ; Sat, 3 Sep 2005 01:44:29 +0000 (GMT) (envelope-from edwin.brown@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0143A43D45 for ; Sat, 3 Sep 2005 01:44:28 +0000 (GMT) (envelope-from edwin.brown@gmail.com) Received: by zproxy.gmail.com with SMTP id 8so454617nzo for ; Fri, 02 Sep 2005 18:44:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=KuxSN+0XH97qLOk/exUCjjgH2TI8FK1rPVTmTwwLg9We3gbelP0hT2FuTNHys1ioj8mBdP5NXK+QLM22QVOJSPJ5nrcf9UgIe2VZcBPFXtmfoHP1A0zhUg9Oi6I+q+UE3fstDe1abR+hkWujGVYPFaZcVtv0poH/VDcv76WHOYg= Received: by 10.36.17.7 with SMTP id 7mr2894400nzq; Fri, 02 Sep 2005 18:43:30 -0700 (PDT) Received: by 10.36.61.10 with HTTP; Fri, 2 Sep 2005 18:44:28 -0700 (PDT) Message-ID: <8b6eae96050902184478022e6c@mail.gmail.com> Date: Fri, 2 Sep 2005 21:44:28 -0400 From: Edwin Brown To: Scott Ullrich In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_14109_22879841.1125711868381" References: <8b6eae9605090106151a81174d@mail.gmail.com> <20050902221724.GC659@obiwan.tataz.chchile.org> X-Mailman-Approved-At: Sat, 03 Sep 2005 11:35:40 +0000 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, Jeremie Le Hen Subject: Re: FreeBSD6.0 and VMWare 5.0.. No go X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Sep 2005 01:44:29 -0000 ------=_Part_14109_22879841.1125711868381 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline U29ycnkgZm9yIHRoZSBwaWN0dXJlLiBJdCdzIGJlZW4gYSBsb25nIGRheSBhbmQgSSBkb24ndCBm ZWVsIGxpa2UgY29weWluZyAKdGhlIHRleHQuIEhlcmUncyB0aGUgZHVtcC4gCkl0IGRvZXMgbG9v ayByZWxhdGVkIHRvIDg0MTAyLgoKQmVzdCAKCkVkd2luCgpPbiA5LzIvMDUsIFNjb3R0IFVsbHJp Y2ggPHN1bGxyaWNoQGdtYWlsLmNvbT4gd3JvdGU6Cj4gCj4gT24gOS8yLzA1LCBKZXJlbWllIExl IEhlbiA8amVyZW1pZUBsZS1oZW4ub3JnPiB3cm90ZToKPiA+IEhpIEVkd2luLAo+ID4KPiA+IFsg UGxlYXNlIGVpdGhlciBwb3N0IG9uIC1zdGFibGVAIG9yIC1jdXJyZW50QCwgbm90IGJvdGguIElu IHRoaXMgY2FzZQo+ID4geW91IHNob3VsZCBoYXZlIHBvc3Qgb24gLWN1cnJlbnRAIG9ubHksIHNp bmNlIDYuMCBpc24ndCBzdGFibGUgeWV0LiBdCj4gCj4gTm90IHN1cmUgaWYgdGhpcyBpcyByZWxh dGVkIG9yIG5vdCBidXQgdGhlIFNvQyBmb3IgQlNESW5zdGFsbGVyIG1lbnRpb25zOgo+IAo+ICog QWRkIGEga2VybmVsIHdpdGhvdXQgUFJFRU1QVElPTiBmb3IgUWVtdSBhbmQgVm13YXJlCj4gCj4g aHR0cDovL3dpa2l0ZXN0LmZyZWVic2Qub3JnL21vaW4uY2dpL0JTREluc3RhbGxlcgo+IAo+IFNj b3R0Cj4K ------=_Part_14109_22879841.1125711868381-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 3 07:45: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 2A7BC16A41F for ; Sat, 3 Sep 2005 07:45:47 +0000 (GMT) (envelope-from mirya@matrix.kiev.ua) Received: from gw.matrix.kiev.ua (gw.matrix.kiev.ua [213.159.235.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id A754543D48 for ; Sat, 3 Sep 2005 07:45:46 +0000 (GMT) (envelope-from mirya@matrix.kiev.ua) Received: by gw.matrix.kiev.ua (Postfix, from userid 426) id D3524C50C6; Sat, 3 Sep 2005 10:45:44 +0300 (EEST) Received: from [192.168.0.27] (bt2.matrix.kiev.ua [192.168.0.27]) by gw.matrix.kiev.ua (Postfix) with ESMTP id 3B9A6C50C3 for ; Sat, 3 Sep 2005 10:45:44 +0300 (EEST) Message-ID: <431954CE.9000105@matrix.kiev.ua> Date: Sat, 03 Sep 2005 10:46:22 +0300 From: Kyryll A Mirnenko User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on gw.matrix.kiev.ua X-Spam-Level: X-Spam-Status: No, score=-104.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.0.2 X-Mailman-Approved-At: Sat, 03 Sep 2005 11:35:40 +0000 Subject: sysmouse is broken in 6_RELENG X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mirya@matrix.kiev.ua List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2005 07:45:47 -0000 Seems like yesterday's commit of syscons/* 's broken sysmouse. The kernel panics on any mouse activity (integer div. by zero) From owner-freebsd-current@FreeBSD.ORG Sat Sep 3 13:34: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 5A0E916A41F for ; Sat, 3 Sep 2005 13:34:20 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from nic.ach.sch.gr (nic.sch.gr [194.63.238.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0025743D48 for ; Sat, 3 Sep 2005 13:34:16 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: (qmail 20074 invoked by uid 207); 3 Sep 2005 13:34:15 -0000 Received: from keramida@freebsd.org by nic by uid 201 with qmail-scanner-1.21 (sophie: 3.04/2.19/3.81. Clear:RC:1(81.186.70.111):. Processed in 4.376236 secs); 03 Sep 2005 13:34:15 -0000 Received: from dialup111.ach.sch.gr (HELO gothmog.gr) ([81.186.70.111]) (envelope-sender ) by nic.sch.gr (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 3 Sep 2005 13:34:10 -0000 Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.13.4/8.13.4) with ESMTP id j83DXt5Q000687; Sat, 3 Sep 2005 16:33:55 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from giorgos@localhost) by gothmog.gr (8.13.4/8.13.4/Submit) id j83DXscV000686; Sat, 3 Sep 2005 16:33:54 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Sat, 3 Sep 2005 16:33:44 +0300 From: Giorgos Keramidas To: rodrigc@freebsd.org Message-ID: <20050903133344.GA633@gothmog.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Cc: freebsd-current@freebsd.org Subject: moused related panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Sep 2005 13:34:20 -0000 I've been unable to enable moused since a few days ago, because moving the mouse panics with: % Fatal trap 18: integer divide fault while in kernel mode % instruction pointer = 0x20:0xc0672388 % stack pointer = 0x28:0xda93bbc0 % frame pointer = 0x28:0xda93bbc8 % 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 = 566 (moused) This was on a console running with 132x25 mode. A backtrace didn't help track down the problem, because when I try to see the values of local variables in the backtrace `scp' is NULL in set_mouse_pos(scr_stat *scp). Script started on Sat Sep 3 16:16:14 2005 gothmog:/var/crash# kgdb /usr/obj/usr/src/sys/GOTHMOG/kernel.debug vmcore.40 [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: Fatal trap 18: integer divide fault while in kernel mode instruction pointer = 0x20:0xc0672388 stack pointer = 0x28:0xda93bbc0 frame pointer = 0x28:0xda93bbc8 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 = 566 (moused) panic: from debugger KDB: stack backtrace: Uptime: 41s Dumping 511 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 511MB (130800 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) bt #0 doadump () at pcpu.h:165 #1 0xc05360e8 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:397 #2 0xc0536393 in panic (fmt=0xc06bad52 "from debugger") at /usr/src/sys/kern/kern_shutdown.c:553 #3 0xc0478b21 in db_panic (addr=-1066982520, have_addr=0, count=-1, modif=0xda93ba14 "") at /usr/src/sys/ddb/db_command.c:432 #4 0xc0478ab8 in db_command (last_cmdp=0xc0740804, cmd_table=0x0, aux_cmd_tablep=0xc06eeab0, aux_cmd_tablep_end=0xc06eeab4) at /usr/src/sys/ddb/db_command.c:401 #5 0xc0478b80 in db_command_loop () at /usr/src/sys/ddb/db_command.c:452 #6 0xc047a721 in db_trap (type=18, code=0) at /usr/src/sys/ddb/db_main.c:221 #7 0xc054de3b in kdb_trap (type=18, code=0, tf=0xda93bb80) at /usr/src/sys/kern/subr_kdb.c:473 #8 0xc0693440 in trap_fatal (frame=0xda93bb80, eva=0) at /usr/src/sys/i386/i386/trap.c:832 #9 0xc0692fc4 in trap (frame= {tf_fs = -1066729464, tf_es = 40, tf_ds = -1072431064, tf_edi = -1065647296, tf_esi = 1840130, tf_ebp = -627852344, tf_isp = -627852372, tf_ebx = 1584, tf_edx = -1, tf_ecx = -1065647296, tf_eax = -1, tf_trapno = 18, tf_err = 0, tf_eip = -1066982520, tf_cs = 32, tf_eflags = 66054, tf_esp = -1065647296, tf_ss = -1043082592}) at /usr/src/sys/i386/i386/trap.c:639 #10 0xc0685eda in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #11 0xc06b0008 in __func__.0 () #12 0x00000028 in ?? () #13 0xc0140028 in ?? () #14 0xc07b8340 in kernel_console_ts () #15 0x001c1402 in ?? () #16 0xda93bbc8 in ?? () #17 0xda93bbac in ?? () #18 0x00000630 in ?? () #19 0xffffffff in ?? () #20 0xc07b8340 in kernel_console_ts () #21 0xffffffff in ?? () #22 0x00000012 in ?? () #23 0x00000000 in ?? () #24 0xc0672388 in set_mouse_pos (scp=0x0) at /usr/src/sys/dev/syscons/scmouse.c:162 #25 0xc0672f27 in sc_mouse_ioctl (tp=0x0, cmd=3229320000, data=0xc1d3d2a0 "\b", flag=3, td=0xc1d39900) at /usr/src/sys/dev/syscons/scmouse.c:732 #26 0xc06790ac in scioctl (dev=0xc1aa8b00, cmd=3222561546, data=0xc1d3d2a0 "\b", flag=3, td=0xc1d39900) at /usr/src/sys/dev/syscons/syscons.c:689 #27 0xc05127bb in giant_ioctl (dev=0xc1aa8b00, cmd=3222561546, data=0xc1d3d2a0 "\b", fflag=3, td=0xc1d39900) at /usr/src/sys/kern/kern_conf.c:287 #28 0xc04effe3 in devfs_ioctl_f (fp=0xc1badc60, com=3222561546, data=0xc1d3d2a0, cred=0xc1e1bb80, td=0xc1d39900) at /usr/src/sys/fs/devfs/devfs_vnops.c:546 #29 0xc05597e8 in ioctl (td=0xc1d39900, uap=0xda93bd04) at file.h:258 #30 0xc0693707 in syscall (frame= {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = -2147483648, tf_esi = 0, tf_ebp = -1077943096, tf_isp = -627851932, tf_ebx = 1, tf_edx = -2147483648, tf_ecx = 0, tf_eax = 54, tf_trapno = 22, tf_err = 2, tf_eip = 672370251, tf_cs = 51, tf_eflags = 663, tf_esp = -1077943540, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:986 #31 0xc0685f2f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200 #32 0x0000003b in ?? () #33 0x0000003b in ?? () #34 0x0000003b in ?? () #35 0x80000000 in ?? () #36 0x00000000 in ?? () #37 0xbfbfe4c8 in ?? () #38 0xda93bd64 in ?? () #39 0x00000001 in ?? () #40 0x80000000 in ?? () #41 0x00000000 in ?? () #42 0x00000036 in ?? () #43 0x00000016 in ?? () #44 0x00000002 in ?? () #45 0x28138e4b in ?? () #46 0x00000033 in ?? () #47 0x00000297 in ?? () #48 0xbfbfe30c in ?? () #49 0x0000003b in ?? () #50 0x08078f38 in ?? () #51 0x08078f68 in ?? () #52 0xffffffff in ?? () #53 0x08078f08 in ?? () #54 0x1f4f4000 in ?? () #55 0xc1e48000 in ?? () #56 0xc1d39900 in ?? () #57 0xda93b7f4 in ?? () #58 0xda93b7dc in ?? () #59 0xc1976000 in ?? () #60 0xc0546833 in sched_switch (td=0x0, newtd=0x1, flags=Cannot access memory at address 0xbfbfe4d8 ) at /usr/src/sys/kern/sched_4bsd.c:973 Previous frame inner to this frame (corrupt stack?) (kgdb) up 24 #24 0xc0672388 in set_mouse_pos (scp=0x0) at /usr/src/sys/dev/syscons/scmouse.c:162 162 scp->mouse_pos = (kgdb) list 157 scp->mouse_ypos = (scp->ysize + scp->yoff)*scp->font_size - 1; 158 } 159 160 if (scp->mouse_xpos != scp->mouse_oldxpos || scp->mouse_ypos != scp->mouse_oldypos) { 161 scp->status |= MOUSE_MOVED; 162 scp->mouse_pos = 163 (scp->mouse_ypos/scp->font_size - scp->yoff)*scp->xsize 164 + scp->mouse_xpos/scp->font_width - scp->xoff; 165 #ifndef SC_NO_CUTPASTE 166 if ((scp->status & MOUSE_VISIBLE) && (scp->status & MOUSE_CUTTING)) (kgdb) p scp->font_width Cannot access memory at address 0x6c (kgdb) p *scp Cannot access memory at address 0x0 (kgdb) p scp $1 = (scr_stat *) 0x0 (kgdb) list set_mouse_pos 137 } 138 139 /* adjust mouse position */ 140 static void 141 set_mouse_pos(scr_stat *scp) 142 { 143 if (scp->mouse_xpos < scp->xoff*scp->font_width) 144 scp->mouse_xpos = scp->xoff*scp->font_width; 145 if (scp->mouse_ypos < scp->yoff*scp->font_size) 146 scp->mouse_ypos = scp->yoff*scp->font_size; (kgdb) 147 if (ISGRAPHSC(scp)) { 148 if (scp->mouse_xpos > scp->xpixel-1) 149 scp->mouse_xpos = scp->xpixel-1; 150 if (scp->mouse_ypos > scp->ypixel-1) 151 scp->mouse_ypos = scp->ypixel-1; 152 return; 153 } else { 154 if (scp->mouse_xpos > (scp->xsize + scp->xoff)*scp->font_width - 1) 155 scp->mouse_xpos = (scp->xsize + scp->xoff)*scp->font_width - 1; 156 if (scp->mouse_ypos > (scp->ysize + scp->yoff)*scp->font_size - 1) (kgdb) p scp $2 = (scr_stat *) 0x0 (kgdb) list set_mouse_pos 137 } 138 139 /* adjust mouse position */ 140 static void 141 set_mouse_pos(scr_stat *scp) 142 { 143 if (scp->mouse_xpos < scp->xoff*scp->font_width) 144 scp->mouse_xpos = scp->xoff*scp->font_width; 145 if (scp->mouse_ypos < scp->yoff*scp->font_size) 146 scp->mouse_ypos = scp->yoff*scp->font_size; (kgdb) 147 if (ISGRAPHSC(scp)) { 148 if (scp->mouse_xpos > scp->xpixel-1) 149 scp->mouse_xpos = scp->xpixel-1; 150 if (scp->mouse_ypos > scp->ypixel-1) 151 scp->mouse_ypos = scp->ypixel-1; 152 return; 153 } else { 154 if (scp->mouse_xpos > (scp->xsize + scp->xoff)*scp->font_width - 1) 155 scp->mouse_xpos = (scp->xsize + scp->xoff)*scp->font_width - 1; 156 if (scp->mouse_ypos > (scp->ysize + scp->yoff)*scp->font_size - 1) (kgdb) 157 scp->mouse_ypos = (scp->ysize + scp->yoff)*scp->font_size - 1; 158 } 159 160 if (scp->mouse_xpos != scp->mouse_oldxpos || scp->mouse_ypos != scp->mouse_oldypos) { 161 scp->status |= MOUSE_MOVED; 162 scp->mouse_pos = 163 (scp->mouse_ypos/scp->font_size - scp->yoff)*scp->xsize 164 + scp->mouse_xpos/scp->font_width - scp->xoff; 165 #ifndef SC_NO_CUTPASTE 166 if ((scp->status & MOUSE_VISIBLE) && (scp->status & MOUSE_CUTTING)) (kgdb) q gothmog:/var/crash# exit exit Script done on Sat Sep 3 16:23:25 2005 From owner-freebsd-current@FreeBSD.ORG Sat Sep 3 14:15: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 6FA2A16A41F for ; Sat, 3 Sep 2005 14:15:42 +0000 (GMT) (envelope-from dandee@hellteam.net) Received: from pipa.profix.cz (server1.pcsvet.net [82.208.25.157]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB72E43D4C for ; Sat, 3 Sep 2005 14:15:41 +0000 (GMT) (envelope-from dandee@hellteam.net) Received: from localhost (localhost [127.0.0.1]) by pipa.profix.cz (Postfix) with ESMTP id 15F204E706; Sat, 3 Sep 2005 16:15:44 +0200 (CEST) Received: from pipa.profix.cz ([127.0.0.1]) by localhost (pipa [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28834-04; Sat, 3 Sep 2005 16:15:43 +0200 (CEST) Received: from gandalf (unknown [80.95.121.105]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by pipa.profix.cz (Postfix) with ESMTP id 307DE4E704; Sat, 3 Sep 2005 16:15:43 +0200 (CEST) From: =?us-ascii?Q?Daniel_Dvorak?= To: "'Scott Long'" , Date: Sat, 3 Sep 2005 16:15:31 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWwSRyrzM/NGpSUTaOoFMkhDKiAUQASKNDg In-Reply-To: <431935B7.6040904@samsco.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Message-Id: <20050903141543.307DE4E704@pipa.profix.cz> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at profix.cz Cc: freebsd-current@freebsd.org, 'Edwin Brown' Subject: RE: FreeBSD6.0 and VMWare 5.0.. No go X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dandee@volny.cz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2005 14:15:42 -0000 Okay I am interested in. -----Original Message----- From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd-current@freebsd.org] On Behalf Of Scott Long Sent: Saturday, September 03, 2005 7:34 AM To: dandee@volny.cz Cc: freebsd-current@freebsd.org; 'Edwin Brown' Subject: Re: FreeBSD6.0 and VMWare 5.0.. No go Daniel Dvorak wrote: > Yes, I confirm this. :( > > I tried to install 32bit and 64bit version and both stoped with this panic. > It hapens when installation proccess copy files to disk, usually. > > Dan If anyone is interested, I have a FreeBSD 6 snapshot ISO with a custom kernel that has PREEMPTION, SMP, and apic removed. I've been trying to get it to work on VirtualPC, but I'm running into other problems with it now (mainly that VPC doesn't seem to expose the CDROM in a way that FreeBSD can find it). If anyone is interested in testing it with VMWare, let me know and I'll make it available. It's a normal disc1 install ISO, based on 6-BETA3. Scott _______________________________________________ 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 Sat Sep 3 14:34: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 D4DD016A41F for ; Sat, 3 Sep 2005 14:34:19 +0000 (GMT) (envelope-from dan.cojocar@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63CD143D48 for ; Sat, 3 Sep 2005 14:34:19 +0000 (GMT) (envelope-from dan.cojocar@gmail.com) Received: by xproxy.gmail.com with SMTP id h32so305063wxd for ; Sat, 03 Sep 2005 07:34:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:mime-version:content-type; b=Bhcj9cGXxF0B+4o6INGBku4yglgkaRAv0lILxrTw+/bm6KK8AnBIMK1mZpLGginJ6WukRDMKsHEx1IkjyAnpOIAmpwr7S3xN/AXlDWysoT/aPaxDGVO9+gp2Ujqp8em3bE0QheCrdj8RLqqahMAPgoZciF3NinMrasQQGIfNbHs= Received: by 10.70.58.20 with SMTP id g20mr5387wxa; Sat, 03 Sep 2005 07:28:08 -0700 (PDT) Received: by 10.70.56.10 with HTTP; Sat, 3 Sep 2005 07:28:08 -0700 (PDT) Message-ID: Date: Sat, 3 Sep 2005 17:28:08 +0300 From: Dan Cojocar To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: bzeeb+freebsd+lor@zabbadoz.net Subject: LOR in /usr/src/sys/netinet/in.c:972 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dan.cojocar@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2005 14:34:20 -0000 Hello, Here is my second lor for today :) that i didn't find on=20 http://sources.zabbadoz.net/freebsd/lor.html I get this when i run dhclient on cdce0 interface. It's harmless, because I= =20 obtain an valid ip and everything is working ok. lock order reversal 1st 0xc06a2e40 in_multi_mtx (in_multi_mtx) @ /usr/src/sys/netinet/in.c:972 2nd 0xc0655660 Giant (Giant) @ /usr/src/sys/net/if.c:1998 KDB: stack backtrace: witness_checkorder(c0655660,9,c0612eef,7ce,12c) at witness_checkorder+0x51c _mtx_lock_flags(c0655660,0,c0612eef,7ce,c) at _mtx_lock_flags+0x54 if_addmulti(c1a67800,d5729afc,d5729af8,3cc,c1bf0780) at if_addmulti+0x260 in_addmulti(d5729b40,c1a67800,1,2cc,c1b8bbc8) at in_addmulti+0x66 in_ifinit(c1f53190,0,0,0,d5729b90) at in_ifinit+0x5bc in_control(c1f8b000,8040691a,c1f53180,c1a67800,c1aa0e10) at in_control+0xfa= a ifioctl(c1f8b000,8040691a,c1f53180,c1aa0e10,2) at ifioctl+0x15a soo_ioctl(c1f5e000,8040691a,c1f53180,c1f65200,c1aa0e10) at soo_ioctl+0x2e8 ioctl(c1aa0e10,d5729d04,c,422,3) at ioctl+0x118 syscall(3b,3b,3b,808e3a0,0) at syscall+0x13d Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (54, FreeBSD ELF32, ioctl), eip =3D 0x807f49b, esp =3D 0xbfbfe5= bc,=20 ebp =3D 0xbfbfee28 --- Thanks, Dan From owner-freebsd-current@FreeBSD.ORG Sat Sep 3 16:48: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 7236216A41F for ; Sat, 3 Sep 2005 16:48:31 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0898B43D45 for ; Sat, 3 Sep 2005 16:48:31 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1EBbBt-0004y2-JE for freebsd-current@freebsd.org; Sat, 03 Sep 2005 19:48:29 +0300 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Sat, 03 Sep 2005 19:48:29 +0300 From: Danny Braniss Message-ID: Subject: 6.0-BETA3 -- process stuck on [lockd] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Sep 2005 16:48:31 -0000 hi, this is 6.0-BETA3 on an smp box, = with ^t I get: load: 1.09 cmd: dpkg 63786 [lockd] 0.00u 0.00s 0% 1124k load: 0.01 cmd: dpkg 63786 [lockd] 0.00u 0.00s 0% 1124k load: 0.00 cmd: dpkg 63786 [lockd] 0.00u 0.00s 0% 1124k (it's now more than 1 hour :-) and it's not killable. % ps lwp 63786 UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMA= ND 0 63786 63785 0 96 0 2376 1132 lockd D+ d0 0:00.01 = /usr/local/bin/dpkg --root=3D/compat/linux --admindir=3D/compat/linux/var= /lib/dpkg = -- anything i can to to help? danny From owner-freebsd-current@FreeBSD.ORG Sat Sep 3 19:19: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 C680A16A41F for ; Sat, 3 Sep 2005 19:19:29 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7714B43D45 for ; Sat, 3 Sep 2005 19:19:29 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 84DB846B95; Sat, 3 Sep 2005 15:19:28 -0400 (EDT) Date: Sat, 3 Sep 2005 20:19:28 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Gavin Atkinson In-Reply-To: <1125594635.63101.3.camel@buffy.york.ac.uk> Message-ID: <20050903201628.D88940@fledge.watson.org> References: <1125487485.34476.6.camel@buffy.york.ac.uk> <20050831134927.GA20529@comp.chem.msu.su> <1125594635.63101.3.camel@buffy.york.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Yar Tikhiy , freebsd-current@freebsd.org Subject: Re: 6.0BETA3 panic in ip_output (vlan/RIP related?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2005 19:19:29 -0000 On Thu, 1 Sep 2005, Gavin Atkinson wrote: >> Thanks for reporting this! The problem seems known and has to do with >> a deficiency in our multicast code WRT interface removal/re-insertion. >> It is on the to-do list of our networking gurus and hopefully will be >> dealt with RSN, after IP multicast code locking and cleanup are >> complete. > > It's good to hear that the problem is understood, however it seems that > this panic is trivial to recreate for anyone running routed, and > therefore 6.0-RELEASE may well be unusable for me. I've just got this > second panic from the same machine which looks like it may also be > related to the multicast code. I believe I've chatted with Gleb about this some, but want to confirm that I understand the problem here: this occurs when an interface is removed while IP multicast membership is still present for multicast groups on the interface. When the multicast socket is closed, then the kernel panics because it has a now invalid cached pointer to the interface structure (now freed), which cases an assertion failure because the mutex code detects that it is operating on an invalid mutex. So it sounds like we need to figure out how the multicast code should behave on interface removal -- I wonder what other operating systems do here? Do they simply invalidate current membership related with the interface, or do they leave the multicast sockets in a state such that if the interface comes back, the memberships are re-bound? Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Sat Sep 3 20:30: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 555CD16A420 for ; Sat, 3 Sep 2005 20:30:19 +0000 (GMT) (envelope-from psamuel01@yahoo.com) Received: from web33507.mail.mud.yahoo.com (web33507.mail.mud.yahoo.com [68.142.206.156]) by mx1.FreeBSD.org (Postfix) with SMTP id 57EB543D5F for ; Sat, 3 Sep 2005 20:30:15 +0000 (GMT) (envelope-from psamuel01@yahoo.com) Received: (qmail 33290 invoked by uid 60001); 3 Sep 2005 20:30:14 -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=2DqF0EQm2wgASmmlCgMvRcuOk+7SF3CA9UHwQVV+eLofg5e7EvONTytpj+ver8mTj3fvLdt0ikM9UCMMdxk8/4rlGFhCtsjiJHqZ8YeAAWgZ3/RMiFR71F6TXaQouSChoFcakiYCYV6I6xzAD5N6C1rPERTmgGs+Z1cr2NJkT+s= ; Message-ID: <20050903203014.33288.qmail@web33507.mail.mud.yahoo.com> Received: from [24.208.219.212] by web33507.mail.mud.yahoo.com via HTTP; Sat, 03 Sep 2005 13:30:14 PDT Date: Sat, 3 Sep 2005 13:30:14 -0700 (PDT) From: Dean Patterson To: Darren Pilgrim In-Reply-To: <000b01c5b050$e118fa70$642a15ac@SMILEY> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: RE: Installation error Intel mobile ICH6M SATA controller. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Sep 2005 20:30:19 -0000 Well I checked it using the shell and it was marked as active. But the problem is that the ATA driver only supports up to ICH5, per the man pages. So how is that situation handled? I assume that I am NEVER going to run FBSD on this laptop? --- Darren Pilgrim wrote: > From: Dean Patterson [mailto:psamuel01@yahoo.com] > > > > I am sorry I should have mentioned that I also > tried > > explicitly setting the slice active. I will try > again > > and check it using the shell; however, when I > tried > > using the holographic shell nothing worked. I > tried > > using fdisk, bsdlabel, and ls and I always get the > > message "command not found." > > The holographic shell is not the same as the fix-it > shell. The > holographic shell lacks, among other things proper > paths, which makes it > impossible to run many programs. The "Fix-It" shell > is a menu option in > sysinstall and starts a fully-functional shell. > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-current@FreeBSD.ORG Sat Sep 3 21:36:14 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 67EC416A41F for ; Sat, 3 Sep 2005 21:36:14 +0000 (GMT) (envelope-from lists@c0mplx.org) Received: from home.c0mplx.org (home.c0mplx.org [213.178.180.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0506843D45 for ; Sat, 3 Sep 2005 21:36:13 +0000 (GMT) (envelope-from lists@c0mplx.org) Received: from pi by home.c0mplx.org with local (Exim 4.52) id 1EBfgM-000K2Z-A6 for freebsd-current@freebsd.org; Sat, 03 Sep 2005 23:36:14 +0200 Date: Sat, 3 Sep 2005 23:36:14 +0200 From: Kurt Jaeger To: freebsd-current@freebsd.org Message-ID: <20050903213614.GG76888@home.c0mplx.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: LOR on 6.0-BETA3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lists@c0mplx.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2005 21:36:14 -0000 Hello, after booting an DELL Inspiron 3200 D266XT with 6.0-BETA3, the following LOR can be found in the dmesg output: lock order reversal 1st 0xc097e980 UMA lock (UMA lock) @ /usr/src/sys/vm/uma_core.c:1494 2nd 0xc1060144 system map (system map) @ /usr/src/sys/vm/vm_map.c:2317 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c0933960,c0933aa0,c08be0a4) at kdb_backtrace+0x29 witness_checkorder(c1060144,9,c08745c9,90d) at witness_checkorder+0x564 _mtx_lock_flags(c1060144,0,c08745c9,90d) at _mtx_lock_flags+0x5b _vm_map_lock(c10600c0,c08745c9,90d) at _vm_map_lock+0x26 vm_map_remove(c10600c0,c1984000,c1985000,c8c56c0c,c0781b69) at vm_map_remove+0x1f kmem_free(c10600c0,c1984000,1000,c8c56c3c,c0781516) at kmem_free+0x25 page_free(c1984000,1000,2) at page_free+0x29 zone_drain(c1498000) at zone_drain+0x26a zone_foreach(c07812ac,c8c56cec,c0793497,c8c56c74,246) at zone_foreach+0x37 uma_reclaim(c8c56c74,246,0,c8c56c80,c062b459) at uma_reclaim+0x12 vm_pageout_scan(0,c097ede0,0,c0875ab6,604) at vm_pageout_scan+0x103 vm_pageout(0,c8c56d38,0,c07942ec,0) at vm_pageout+0x2c3 fork_exit(c07942ec,0,c8c56d38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xc8c56d6c, ebp = 0 --- The full dmesg output can be found at: http://c0mplx.org/backup/lor-dmesg -- pi@c0mplx.org +49 171 3101372 15 years to go ! From owner-freebsd-current@FreeBSD.ORG Sat Sep 3 21:40: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 C2BE416A41F for ; Sat, 3 Sep 2005 21:40:37 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fileserver.fields.utoronto.ca (fileserver.fields.utoronto.ca [128.100.216.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5AF9E43D46 for ; Sat, 3 Sep 2005 21:40:37 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fields.fields.utoronto.ca (fields.localdomain [192.168.216.11]) by fileserver.fields.utoronto.ca (8.12.8/8.12.8/Fields 6.0) with ESMTP id j83LeUvf004438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 Sep 2005 17:40:30 -0400 Received: from obsecurity.dyndns.org (localhost.localdomain [127.0.0.1]) by fields.fields.utoronto.ca (8.12.8/8.12.8/Fields WS 6.0) with ESMTP id j83LeR6P028907; Sat, 3 Sep 2005 17:40:29 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 8EB78515A7; Sat, 3 Sep 2005 17:40:26 -0400 (EDT) Date: Sat, 3 Sep 2005 17:40:26 -0400 From: Kris Kennaway To: Kurt Jaeger Message-ID: <20050903214026.GA50975@xor.obsecurity.org> References: <20050903213614.GG76888@home.c0mplx.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="C7zPtVaVf+AK4Oqc" Content-Disposition: inline In-Reply-To: <20050903213614.GG76888@home.c0mplx.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: LOR on 6.0-BETA3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Sep 2005 21:40:37 -0000 --C7zPtVaVf+AK4Oqc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 03, 2005 at 11:36:14PM +0200, Kurt Jaeger wrote: > Hello, >=20 > after booting an DELL Inspiron 3200 D266XT with 6.0-BETA3, the > following LOR can be found in the dmesg output: >=20 > lock order reversal > 1st 0xc097e980 UMA lock (UMA lock) @ /usr/src/sys/vm/uma_core.c:1494 > 2nd 0xc1060144 system map (system map) @ /usr/src/sys/vm/vm_map.c:2317 Reported 2^n times already, but thanks anyway :-) Kris --C7zPtVaVf+AK4Oqc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDGhhJWry0BWjoQKURAquRAJ9dre1QgV29TkFc5qxMhXpmo1uIcACeOZSr O4h1jPwaB0KDJDW4FHF3+II= =2jSY -----END PGP SIGNATURE----- --C7zPtVaVf+AK4Oqc-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 3 22:38: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 05F9616A41F for ; Sat, 3 Sep 2005 22:38:14 +0000 (GMT) (envelope-from benlutz@datacomm.ch) Received: from maxlor.mine.nu (c-213-160-32-54.customer.ggaweb.ch [213.160.32.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05D9B43D48 for ; Sat, 3 Sep 2005 22:38:12 +0000 (GMT) (envelope-from benlutz@datacomm.ch) Received: from localhost (localhost [127.0.0.1]) by maxlor.mine.nu (Postfix) with ESMTP id F33B94F0 for ; Sun, 4 Sep 2005 00:42:51 +0200 (CEST) Received: from maxlor.mine.nu ([127.0.0.1]) by localhost (midgard.intranet [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38478-02 for ; Sun, 4 Sep 2005 00:42:50 +0200 (CEST) Received: from [10.0.0.23] (mini.intranet [10.0.0.23]) by maxlor.mine.nu (Postfix) with ESMTP id 6C82C190 for ; Sun, 4 Sep 2005 00:42:50 +0200 (CEST) Message-ID: <431A25CB.8050503@datacomm.ch> Date: Sun, 04 Sep 2005 00:38:03 +0200 From: Benjamin Lutz User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: FreeBSD-Current X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF87B48B842847D74CC9623D1" X-Virus-Scanned: amavisd-new at maxlor.mine.nu X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Very slow disk writes because of wdrain X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Sep 2005 22:38:14 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF87B48B842847D74CC9623D1 Content-Type: multipart/mixed; boundary="------------070801050104030503010500" This is a multi-part message in MIME format. --------------070801050104030503010500 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, I've upgraded a Server of mine to FreeBSD-6.0-BETA3 today (fresh install), and I've run into a problem. Writes to the disk are extremely slow, eg: $ dd if=/dev/zero of=/usr/test bs=1048576 count=100 100+0 records in 100+0 records out 104857600 bytes transferred in 13.771165 secs (7614287 bytes/sec) $ During the write, dd spends pretty much all it's time in the wdrain state, CPU usage is about 5% (this is a Pentium 4 2.4GHz). Reading from the disk (as far as I can tell by dd'ing stuff to /dev/null) is as fast as it's supposed to be. wdrain is defined in /usr/src/sys/kern/vfs_bio.c:384. A posting to questions in march last year recommends increasing vfs.hirunningspace (default: 1M) to 4M. This has no impact however on the speed, nor does increasing it to 16M. The disk in question is a SCSI RAID 1 array, which has been working very well under FreeBSD 4.11 before. I'm running a custom kernel with the debugging options as well as the hardware I don't use removed. Please see the attached dmesg.txt and kernel.txt for details. Now, I'd like to get fast speeds again from this machine, can anyone help me? Thanks, Benjamin --------------070801050104030503010500-- --------------enigF87B48B842847D74CC9623D1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (Darwin) iD8DBQFDGiXRgShs4qbRdeQRAsJbAJ9sAojdcTEaN/sL4RwFiGYX0t4vPwCggZnp Ged9TKv4L68XYb4M2gGoK3c= =Cpir -----END PGP SIGNATURE----- --------------enigF87B48B842847D74CC9623D1-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 3 23:26: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 D110716A41F for ; Sat, 3 Sep 2005 23:26:43 +0000 (GMT) (envelope-from patfbsdc@davenulle.org) Received: from smtp.lamaiziere.net (lamaiziere.net [213.41.172.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E2A443D46 for ; Sat, 3 Sep 2005 23:26:43 +0000 (GMT) (envelope-from patfbsdc@davenulle.org) Received: from [192.168.0.59] (unknown [192.168.0.59]) by smtp.lamaiziere.net (Postfix) with ESMTP id 6EA5FA6C81 for ; Sun, 4 Sep 2005 01:26:42 +0200 (CEST) From: Patrick =?iso-8859-1?q?Lamaizi=E8re?= Organization: >/dave/nulle To: freebsd-current@freebsd.org Date: Sun, 4 Sep 2005 01:26:37 +0200 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: <200509040126.37561.patfbsdc@davenulle.org> Subject: [6.0 beta3] problem with cvsup and wifi (iwi) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Sep 2005 23:26:43 -0000 Hello, I've got this problem only with cvsup... Cvsup and csup don't work when i'm connected in wifi. (iwi driver / Intel 2200 BG). The cvsup server resets the connection : # cvsup ... Updating collection ports-all/cvs TreeList failed: Network write failure: Connection closed I tried with and without wpa_supplicant with the same result. Csup has got the same problem. My acces point is connected to the LAN, the LAN is connected via a gateway to Internet (adsl). If i run a tcp proxy on the gateway to handle the connection between my laptop and the cvsup server all work fine. Any idea for this problem ? (The AP is a Linksys WRT54G) Thanks, regards.