From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 6 06:16:43 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E0D8F16A4CE for ; Sun, 6 Feb 2005 06:16:43 +0000 (GMT) Received: from panther.cs.ucla.edu (Panther.CS.UCLA.EDU [131.179.128.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FDDF43D5C for ; Sun, 6 Feb 2005 06:16:43 +0000 (GMT) (envelope-from yanyu@CS.UCLA.EDU) Received: from localhost (yanyu@localhost)j166GeW26933 for ; Sat, 5 Feb 2005 22:16:41 -0800 (PST) Date: Sat, 5 Feb 2005 22:16:40 -0800 (PST) From: Yan Yu To: freebsd-hackers@freebsd.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: falloc() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2005 06:16:44 -0000 Hi, all, I am wondering if there is a way to use kernel loadable module to replace the original falloc() (kern/kern_descrip.c) in the system. I know how to do this if the funciton to be replaced is some system call function or ufs* operatio ( i could just change the symbol table which holds these function pointers),. but i could not find the symbol table which holds the falloc() function pointer... Any pointers are appreciated! yan From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 6 11:22:05 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0607016A4CE for ; Sun, 6 Feb 2005 11:22:05 +0000 (GMT) Received: from smtp.ucla.edu (smtp.ucla.edu [169.232.48.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBD9C43D41 for ; Sun, 6 Feb 2005 11:22:04 +0000 (GMT) (envelope-from ashcs@ucla.edu) Received: from mail.ucla.edu (mail.ucla.edu [169.232.47.135]) by smtp.ucla.edu (8.13.1/8.13.1) with ESMTP id j16BM4jc003839 for ; Sun, 6 Feb 2005 03:22:04 -0800 Received: from ash (s226-88.resnet.ucla.edu [164.67.226.88]) (authenticated bits=0) by mail.ucla.edu (8.13.3/8.13.3) with ESMTP id j16BM4aH027985 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sun, 6 Feb 2005 03:22:04 -0800 Message-ID: <001301c50c3e$1a8003b0$58e243a4@ash> From: "Ashwin Chandra" To: Date: Sun, 6 Feb 2005 03:22:11 -0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Probable-Spam: no X-Spam-Hits: 0.152 X-Scanned-By: smtp.ucla.edu Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Opening and wriiting to file in Kern X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2005 11:22:05 -0000 Does anyone know the correct calls to open a file, write to it, and = close it, IN *kernel* mode.=20 Ash From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 6 11:33:48 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1637516A4CE for ; Sun, 6 Feb 2005 11:33:48 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5280F43D46 for ; Sun, 6 Feb 2005 11:33:47 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.254.12] (g4.samsco.home [192.168.254.12]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j16BWuhO071680; Sun, 6 Feb 2005 04:32:56 -0700 (MST) (envelope-from scottl@freebsd.org) Message-ID: <4206008F.2060100@freebsd.org> Date: Sun, 06 Feb 2005 04:33:35 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ashwin Chandra References: <001301c50c3e$1a8003b0$58e243a4@ash> In-Reply-To: <001301c50c3e$1a8003b0$58e243a4@ash> 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-hackers@freebsd.org Subject: Re: Opening and wriiting to file in Kern X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2005 11:33:48 -0000 Ashwin Chandra wrote: > Does anyone know the correct calls to open a file, write to it, and close it, IN *kernel* mode. > > Ash There is no common API for doing this, which is pretty much on purpose. First, you need to ask yourself why your task needs it done in the kernel and not in userland. If you mist do this, the general set of steps are: 1. use namei() to convert a pathname to a vnode 2. Use vn_open(), vn_rdwr(), and vn_close() to operate on the vnode. 3. Observe proper vnode locking and reference counting with vref(), vn_lock(), and vput() Scott From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 6 12:22:42 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F47916A4CE for ; Sun, 6 Feb 2005 12:22:42 +0000 (GMT) Received: from web52702.mail.yahoo.com (web52702.mail.yahoo.com [206.190.39.153]) by mx1.FreeBSD.org (Postfix) with SMTP id E022843D46 for ; Sun, 6 Feb 2005 12:22:41 +0000 (GMT) (envelope-from kamalpr@yahoo.com) Received: (qmail 63592 invoked by uid 60001); 6 Feb 2005 12:22:41 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=W2nI/dxYI4qJ86YEdwEVlEukRQMRHCT0UPADohjNP6DJDQPzXrwWk/YPvXQQUiIkX0MCakwdaJNkH1UNQ9YxeV4+5qvXvT6VYiS4UCuSQEeg7HztC7fLM/weNavefL+IXKUJtu39sb1fuwPrbAuxFyMyuWTXqDctBsUJTv6CUig= ; Message-ID: <20050206122241.63590.qmail@web52702.mail.yahoo.com> Received: from [202.91.78.244] by web52702.mail.yahoo.com via HTTP; Sun, 06 Feb 2005 04:22:41 PST Date: Sun, 6 Feb 2005 04:22:41 -0800 (PST) From: "Kamal R. Prasad" To: freebsd-hackers@freebsd.org In-Reply-To: <4206008F.2060100@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: Opening and wriiting to file in Kern X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kamalp@acm.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2005 12:22:42 -0000 --- Scott Long wrote: > Ashwin Chandra wrote: > > > Does anyone know the correct calls to open a file, > write to it, and close it, IN *kernel* mode. > > > > Ash > > There is no common API for doing this, which is > pretty much on purpose. > First, you need to ask yourself why your task > needs it done in the > kernel and not in userland. > A feature implemented within the kernel that requires making stuff persistent would almost certainly require file I/O. For that matter, a kernel (module) that reads a configuration file will also need the same facility. I don't see anything wrong with providing a stream (like) interface to the filesystem. regards -kamal __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250 From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 6 12:41:13 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 19BCD16A4CE for ; Sun, 6 Feb 2005 12:41:13 +0000 (GMT) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id 9149D43D39 for ; Sun, 6 Feb 2005 12:41:11 +0000 (GMT) (envelope-from roam@ringlet.net) Received: (qmail 1036 invoked from network); 6 Feb 2005 12:41:06 -0000 Received: from unknown (HELO straylight.ringlet.net) (213.16.36.109) by gandalf.online.bg with SMTP; 6 Feb 2005 12:41:06 -0000 Received: (qmail 37492 invoked by uid 1000); 6 Feb 2005 12:41:09 -0000 Date: Sun, 6 Feb 2005 14:41:09 +0200 From: Peter Pentchev To: kamalp@acm.org Message-ID: <20050206124109.GA29361@straylight.m.ringlet.net> Mail-Followup-To: kamalp@acm.org, freebsd-hackers@freebsd.org References: <4206008F.2060100@freebsd.org> <20050206122241.63590.qmail@web52702.mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZGiS0Q5IWpPtfppv" Content-Disposition: inline In-Reply-To: <20050206122241.63590.qmail@web52702.mail.yahoo.com> User-Agent: Mutt/1.5.6i cc: freebsd-hackers@freebsd.org Subject: Re: Opening and wriiting to file in Kern X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2005 12:41:13 -0000 --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 06, 2005 at 04:22:41AM -0800, Kamal R. Prasad wrote: >=20 > --- Scott Long wrote: >=20 > > Ashwin Chandra wrote: > >=20 > > > Does anyone know the correct calls to open a file, > > write to it, and close it, IN *kernel* mode.=20 > > >=20 > > > Ash > >=20 > > There is no common API for doing this, which is > > pretty much on purpose.=20 > > First, you need to ask yourself why your task > > needs it done in the=20 > > kernel and not in userland. >=20 > A feature implemented within the kernel that requires > making stuff persistent would almost certainly require > file I/O. For that matter, a kernel (module) that > reads a configuration file will also need the same > facility. I don't see anything wrong with providing a > stream (like) interface to the filesystem. While there might indeed be nothing wrong with it, besides added complexity, the traditional way to do it would be to have a userland configuration utility that communicates with the kernel module either via ioctl's on some standard device, or via ioctl's or reading/writing of a driver-specific device. This has the advantage of being a bit more portable - while different OS's implement disk/file I/O within the kernel in wildly different ways, all OS's provide relatively simple ways for a kernel module to define a new device and handle ioctl's to it, and all OS's provide basically the same userland-to-kernel interface for having a program open a device and issue ioctl's to it :) Another way would be, again, communication between a userland utility and a kernel module, but this time using mmap'd files/devices instead of ioctl's. G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@cnsys.bg roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence was in the past tense. --ZGiS0Q5IWpPtfppv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCBhBl7Ri2jRYZRVMRAg8PAKCnuRtriq792sCo6XNJ23hAzHSgcwCgoZI2 Tw3DyJDCymoLdFrbnOp0lOw= =0uuZ -----END PGP SIGNATURE----- --ZGiS0Q5IWpPtfppv-- From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 6 12:51:23 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2611A16A4CE for ; Sun, 6 Feb 2005 12:51:23 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id E38CE43D31 for ; Sun, 6 Feb 2005 12:51:22 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id 14C6E46B16; Sun, 6 Feb 2005 07:51:22 -0500 (EST) Date: Sun, 6 Feb 2005 12:50:26 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Yan Yu In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org Subject: Re: falloc() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2005 12:51:23 -0000 On Sat, 5 Feb 2005, Yan Yu wrote: > I am wondering if there is a way to use kernel loadable module to > replace the original falloc() (kern/kern_descrip.c) in the system. I > know how to do this if the funciton to be replaced is some system call > function or ufs* operatio ( i could just change the symbol table which > holds these function pointers),. but i could not find the symbol table > which holds the falloc() function pointer... falloc() isn't considered a "pluggable" kernel API, that is to say, we've not engineered FreeBSD with the intent that it be replaced at run-time. As such, to get falloc() replaced on your out-of-the-box FreeBSD install, you'll need to modify the kernel linking. falloc is non-static, so it should be an exported symbol from kern_descrip.o and in theory exposed to modules -- however, replugging the current reference in kern_descript.o might be the hard one to modify. If you don't mind my asking, what motivates you to replace falloc()? Robert N M Watson From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 6 13:00:31 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1612916A4CF for ; Sun, 6 Feb 2005 13:00:31 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD42443D1D for ; Sun, 6 Feb 2005 13:00:28 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id 8966646B16; Sun, 6 Feb 2005 08:00:28 -0500 (EST) Date: Sun, 6 Feb 2005 12:59:33 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Ashwin Chandra In-Reply-To: <001301c50c3e$1a8003b0$58e243a4@ash> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org Subject: Re: Opening and wriiting to file in Kern X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2005 13:00:31 -0000 On Sun, 6 Feb 2005, Ashwin Chandra wrote: > Does anyone know the correct calls to open a file, write to it, and > close it, IN *kernel* mode. I fyou want to be file system independent, you can currently do it using two different currently available kernel abstractions: - VFS interface. Using vn_open(), return a reference to an opened vnode. Use vn_rdwr() to perform I/O on the vnode, and vn_close() to close it. Make sure to properly lock the vnode during I/O and other operations. This interface is abstract in the sense that it's file systme independent, but not in most other senses. This can be done from many contexts in the kernel, including kernel worker threads, etc. - File interface. Using kern_open(), return a reference to an open 'struct file' Use the calls fo_read(), fo_write(), etc. This is more abstract than the VFS interface, and strongly resembles the interface used via file descriptors (since that's what it implements). It's less functionally complete than the VFS interface, so you can't do stuff like changing the file mode, etc, directly (you have to perform them on the file's vnode). It also requires file descriptor context, so possibly one associated with a user process and then "borrowed" by the kernel. Linux exports a FILE stream like interface in its kernel, and for the purposes of porting the FLASK/TE components from DTOS/SELinux to FreeBSD, we also ported a subset of this functionality. Feel free to grab and reuse as appropriate in a kernel module or the like. You can find it at: http://fxr.watson.org/fxr/source/security/sebsd/ss/fileutils.c?v=TRUSTEDBSD-SEBSD http://fxr.watson.org/fxr/source/security/sebsd/ss/fileutils.h?v=TRUSTEDBSD-SEBSD Right now it just implements fopen(), fread(), and fclose(), but it would be easy to imagine implementing fwrite(), feof(), etc by wrapping the vnode interface. Robert N M Watson From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 6 13:20:37 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F80716A4CE for ; Sun, 6 Feb 2005 13:20:37 +0000 (GMT) Received: from qmail1.ifxnetworks.com (qmail1.ifxnetworks.com [200.110.128.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B02C43D45 for ; Sun, 6 Feb 2005 13:20:37 +0000 (GMT) (envelope-from dmw@unete.cl) Received: (qmail 13730 invoked from network); 6 Feb 2005 13:20:36 -0000 Received: from unknown (HELO dmw.hopto.org) ([200.73.29.178]) (envelope-sender ) by qmail1.ifxnetworks.com (qmail-ldap-1.03) with SMTP for ; 6 Feb 2005 13:20:35 -0000 Received: by dmw.hopto.org (sSMTP sendmail emulation); Sun, 6 Feb 2005 10:21:24 -0300 Date: Sun, 6 Feb 2005 10:21:24 -0300 From: Daniel Molina Wegener To: FreeBSD Hackers Mailing List Message-ID: <20050206132124.GA746@daemon.unete.cl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Description: message Content-Disposition: inline Organization: DMW X-Spam-DCC: : qmail1.ifxnetworks.com 1074; Body=1 Fuz1=1 Fuz2=1 X-Spam-Status: No, hits=0.0 required=6.0 tests=none autolearn=no version=2.63 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on qmail1.ifxnetworks.com Subject: any way to reset errno? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Molina Wegener List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2005 13:20:37 -0000 Hello, Any way to reset errno? Thanks... Regards. -- . 0 . | Daniel Molina Wegener . . 0 | dmw at trauco dot cl 0 0 0 | http://trauco.cl/ From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 6 13:39:58 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 817CC16A4CE for ; Sun, 6 Feb 2005 13:39:58 +0000 (GMT) Received: from web52703.mail.yahoo.com (web52703.mail.yahoo.com [206.190.39.154]) by mx1.FreeBSD.org (Postfix) with SMTP id 1096A43D3F for ; Sun, 6 Feb 2005 13:39:58 +0000 (GMT) (envelope-from kamalpr@yahoo.com) Received: (qmail 79625 invoked by uid 60001); 6 Feb 2005 13:39:57 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=QCJMKKa4QAvW8B7F6LtiBXE8nfUEaR58bzzPKdk9QwJVYtrRO3wIPeHIoepzQ+C3ANC25/DugDDafcVJWEa4h9nrVMRXaHEQnla8ZpG6rkPlreoOsxrzAN7PQUXBLcBUdpDYqPnfW0t+AeT0YzakI/s4YwfZq7AiN8XndQFf6Gk= ; Message-ID: <20050206133957.79623.qmail@web52703.mail.yahoo.com> Received: from [202.91.78.244] by web52703.mail.yahoo.com via HTTP; Sun, 06 Feb 2005 05:39:57 PST Date: Sun, 6 Feb 2005 05:39:57 -0800 (PST) From: "Kamal R. Prasad" To: freebsd-hackers@freebsd.org In-Reply-To: <20050206124109.GA29361@straylight.m.ringlet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: Opening and wriiting to file in Kern X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kamalp@acm.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2005 13:39:58 -0000 --- Peter Pentchev wrote: > On Sun, Feb 06, 2005 at 04:22:41AM -0800, Kamal R. > Prasad wrote: > > > > --- Scott Long wrote: > > > > > Ashwin Chandra wrote: [snip] > > facility. I don't see anything wrong with > providing a > > stream (like) interface to the filesystem. > > While there might indeed be nothing wrong with it, > besides added > complexity, the traditional way to do it would be to > have a userland > configuration utility that communicates with the > kernel module either > via ioctl's on some standard device, or via ioctl's > or reading/writing > of a driver-specific device. This has the advantage > of being a bit more > portable - while different OS's implement disk/file > I/O within the > kernel in wildly different ways, all OS's provide > relatively simple ways > for a kernel module to define a new device and > handle ioctl's to it, and > all OS's provide basically the same > userland-to-kernel interface for > having a program open a device and issue ioctl's to > it :) > No doubt about the portability aspect. But there are situations wherein the kernel does *NOT* want userland to know that it is using the filesystem for providing some functionaality. For a device, it is indeed typical for a userland program to accompany the driver. But besides that, there are definately situations (1 of which I am dealing with) wherein there is no userland code to help one out. [snip] regards -kamal __________________________________ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250 From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 6 13:49:18 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E8D2516A4CE for ; Sun, 6 Feb 2005 13:49:18 +0000 (GMT) Received: from smtp1.powertech.no (smtp1.powertech.no [195.159.0.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id 426E143D4C for ; Sun, 6 Feb 2005 13:49:18 +0000 (GMT) (envelope-from frode@nordahl.net) Received: from [192.168.1.34] (unknown [195.159.232.31]) by smtp1.powertech.no (Postfix) with ESMTP id D25FE7F1D; Sun, 6 Feb 2005 14:49:15 +0100 (CET) In-Reply-To: <20050206132124.GA746@daemon.unete.cl> References: <20050206132124.GA746@daemon.unete.cl> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <711cf8a59a61549a7ced0e791376be66@nordahl.net> Content-Transfer-Encoding: 7bit From: Frode Nordahl Date: Sun, 6 Feb 2005 14:49:15 +0100 To: Daniel Molina Wegener X-Mailer: Apple Mail (2.619.2) cc: FreeBSD Hackers Mailing List Subject: Re: any way to reset errno? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2005 13:49:19 -0000 On Feb 6, 2005, at 14:21, Daniel Molina Wegener wrote: > Hello, > > Any way to reset errno? errno = 0; :-) Regards, Frode Nordahl > Thanks... > > Regards. > -- > . 0 . | Daniel Molina Wegener > . . 0 | dmw at trauco dot cl > 0 0 0 | http://trauco.cl/ > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 6 02:13:33 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4332416A4CE; Sun, 6 Feb 2005 02:13:33 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1089643D1F; Sun, 6 Feb 2005 02:13:33 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j156IObc009513; Fri, 4 Feb 2005 22:18:25 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j156IHbR009512; Fri, 4 Feb 2005 22:18:17 -0800 (PST) (envelope-from www) Date: Fri, 4 Feb 2005 22:18:17 -0800 (PST) Message-Id: <200502050618.j156IHbR009512@marlena.vvi.at> To: dillon@apollo.backplane.com, rwatson@FreeBSD.org From: "ALeine" X-Mailman-Approved-At: Sun, 06 Feb 2005 13:55:20 +0000 cc: freebsd-hackers@FreeBSD.org cc: kernel@crater.dragonflybsd.org Subject: Re: RFC: backporting GEOM to the 4.x branch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2005 02:13:33 -0000 rwatson@FreeBSD.org wrote: > What you may want to do is create a character device driver that > resembles the md(4)/vn(4) mechanism: it consumes another file or > device, forwards I/O from its own device node to the underlying > device after performing the transformation. If possible, you'd > want to attempt to provide a small and approximate subset of the > GEOM API to GBDE so that you could leave GBDE as intact as possible. I have been examining the GEOM code and at this point it seems that creating a subset of the GEOM API in order to leave GBDE intact would take more effort than ripping the cryptographic mechanism out of GBDE and integrating it into vn(4). Speaking of examining code, do you guys use data flow diagrams and other visual representation systems so you can work more quickly and effectively on such a huge and complex code base? I'm using doxygen and graphviz and I have to say they're really great, as can be seen from the following g_bde_work struct example: http://manson.vistech.net/~manager/gbde/structg__bde__work.html The rest can be found at: http://manson.vistech.net/~manager/gbde/ This sort of detailed visual documentation would allow faster development while also making it easier for new developers to join the project. What do you guys think about having such documentation for the entire source tree available on the web? Having the docs regenerated automatically once a day would probably be sufficient to be useful. > Regarding getting this into 4.x: I suspect the biggest concern > would be forward compatibility issues. It would be substantially > counter-productive to merge a feature back with a different > interface/compatibility, as it would make forward upgrades > harder. That is another reason why I think I should isolate the whole thing by creating a cryptographic character device driver (cvn(4)). It would also make it easier to port to DragonFly BSD. ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 6 17:15:06 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C27FB16A4CE for ; Sun, 6 Feb 2005 17:15:06 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E3C643D46 for ; Sun, 6 Feb 2005 17:15:06 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j16HF5A0090893 for ; Sun, 6 Feb 2005 18:15:05 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: hackers@freebsd.org From: Poul-Henning Kamp Date: Sun, 06 Feb 2005 18:15:05 +0100 Message-ID: <90892.1107710105@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Subject: GPIB: (very) basic ibfoo() library support X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2005 17:15:06 -0000 I needed to get some data out from some of my measurement equipment for some $work and the hacked up userland /dev/io code I have used for some time just didn't cut it. So now we have the skeleton of ibfoo() support in FreeBSD. We only support PCIIA compatible adapters, and only a very small subset of the ibfoo() functions are implemented, but the framework has been written so that both other hardware and more functions should be a matter of very little work. Completing this is on my wish-list, but only on my todo list to the extent that I need it for something else. Help to get this more complete is most welcome! The "wish list": o Complete more of the ibfoo() functions. o Support for different GPIB cards. o IEEE488.2 API implentation. o Manual pages. (Either just reference the NI docs or rewrite it all to avoid copyright issues). Reading material: http://www.ni.com/pdf/manuals/321038g.pdf http://www.measurementcomputing.com/gpibhelp_Lib4881.html http://linux-gpib.sourceforge.net/doc_html/index.html The following program should be able to pull out the identity of any SCPI instrument which happens to sit on PAD21 on your GPIB bus, /* compile with: cc -o ibtest ibtest.c -lgpib */ #include #include #include #include int main(int argc __unused, char **argv __unused) { int dmm; unsigned char buf[100]; char vbuf[sizeof buf * 4]; /* DVM */ dmm = ibdev(0, 21, 0, T10s, 1, 0); if (dmm < 0) errx(1, "ibdev = %d\n", dmm); ibwrt(dmm, "*IDN?\r\n", 7); ibrd(dmm, buf, sizeof buf - 1); strvisx(vbuf, buf, ibcnt, VIS_WHITE | VIS_CSTYLE); printf("%s\n", vbuf); return (0); } Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 6 20:18:28 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6CA1716A4CE for ; Sun, 6 Feb 2005 20:18:28 +0000 (GMT) Received: from april.chuckr.org (april.chuckr.org [66.92.151.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1D6F43D4C for ; Sun, 6 Feb 2005 20:18:27 +0000 (GMT) (envelope-from chuckr@chuckr.org) Received: from april.chuckr.org (localhost [127.0.0.1]) by april.chuckr.org (8.13.1/8.12.11) with ESMTP id j16KUSfZ084772 for ; Sun, 6 Feb 2005 15:30:28 -0500 (EST) (envelope-from chuckr@chuckr.org) Received: from localhost (chuckr@localhost)j16KURwK084769 for ; Sun, 6 Feb 2005 15:30:28 -0500 (EST) (envelope-from chuckr@chuckr.org) X-Authentication-Warning: april.chuckr.org: chuckr owned process doing -bs Date: Sun, 6 Feb 2005 15:30:26 -0500 (EST) From: Chuck Robey To: FreeBSD Hackers List Message-ID: <20050206152314.A62347@april.chuckr.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: i86 install images X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2005 20:18:28 -0000 I need someone to verify for me, the disc1 image on the main (ftp.freebsd.org) website image, I have downloaded it 3 times now, and it keeps on reporting to me, when I try to burn it, that it's the miniinst image. I'm capable of missing something obvious, so I am asking someone (anyone) else to check this, please. One item that always irks me, what's the actual name of the disk images. There is a reticence to answer this on the website, cause they're trying to make one answer do correct duty for all the arches, but what they've accomplished is managing to completely miss the mark, to leave out the main data of what's the correct actual names of the images to download. They keep on referring to "the install disks", so I can't figure out what the miniinst is, or the bootonly. I have a small universe to choose from, yes, but it should be size zero. ---------------------------------------------------------------------------- Chuck Robey | Interests include C & Java programming, FreeBSD, chuckr@chuckr.org | electronics, communications, and SF/Fantasy. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary (on the wall at my old fraternity, Signa Phi Nothing). ---------------------------------------------------------------------------- From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 6 20:50:42 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7066D16A4CE for ; Sun, 6 Feb 2005 20:50:42 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCCC143D2F for ; Sun, 6 Feb 2005 20:50:41 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.254.12] (g4.samsco.home [192.168.254.12]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j16KnoVO074082; Sun, 6 Feb 2005 13:49:51 -0700 (MST) (envelope-from scottl@freebsd.org) Message-ID: <4206831A.7020404@freebsd.org> Date: Sun, 06 Feb 2005 13:50:34 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chuck Robey References: <20050206152314.A62347@april.chuckr.org> In-Reply-To: <20050206152314.A62347@april.chuckr.org> 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 Hackers List Subject: Re: i86 install images X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2005 20:50:42 -0000 Chuck Robey wrote: > I need someone to verify for me, the disc1 image on the main > (ftp.freebsd.org) website image, I have downloaded it 3 times now, and it > keeps on reporting to me, when I try to burn it, that it's the miniinst > image. I'm capable of missing something obvious, so I am asking someone > (anyone) else to check this, please. > I assume that you're talking about 5.3-R or 4.11-R? If you think that the image might be corrupt, could you verify the MD5 checksum with what was published in the release announcement? > One item that always irks me, what's the actual name of the disk images. > There is a reticence to answer this on the website, cause they're trying > to make one answer do correct duty for all the arches, but what they've > accomplished is managing to completely miss the mark, to leave out the > main data of what's the correct actual names of the images to download. > They keep on referring to "the install disks", so I can't figure out what > the miniinst is, or the bootonly. I have a small universe to choose from, > yes, but it should be size zero. > The general scheme is: bootonly: just the kernel and sysinstall. Equivalent to the boot floppies. Only for doing network installs miniinst: kernel, sysinstall, installation distributions, perl package. The minimum you need to install FreeBSD from a single CD. disc1: kernel, sysinstall, install distributions, lots of packages. Good for installing a desktop like Gnome or KDE. disc2: kernel, sysinstall, no install distributions, live filesystem. Good for recovering broken systems. I used it for just this a few days ago myself. The iso9660 label name sometimes gets screwed up when we cut releases. We should be better about this, but it's not something that is always obvious. We are working on a new scheme that combines disc2 and miniinst and puts all packages on disc2. There will no longer be a miniinst after that, just disc1, disc2, and possbily bootonly. Scott From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 6 20:54:07 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A9B1C16A4D2 for ; Sun, 6 Feb 2005 20:54:07 +0000 (GMT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9BFF43D31 for ; Sun, 6 Feb 2005 20:54:04 +0000 (GMT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 4C0E9530C; Sun, 6 Feb 2005 21:54:03 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 5891F5308; Sun, 6 Feb 2005 21:53:30 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id 404ADB861; Sun, 6 Feb 2005 21:53:29 +0100 (CET) To: Chuck Robey References: <20050206152314.A62347@april.chuckr.org> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Sun, 06 Feb 2005 21:53:28 +0100 In-Reply-To: <20050206152314.A62347@april.chuckr.org> (Chuck Robey's message of "Sun, 6 Feb 2005 15:30:26 -0500 (EST)") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on flood.des.no X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,FORGED_RCVD_HELO autolearn=disabled version=3.0.1 cc: FreeBSD Hackers List Subject: Re: i86 install images X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2005 20:54:07 -0000 Chuck Robey writes: > One item that always irks me, what's the actual name of the disk images. > There is a reticence to answer this on the website, cause they're trying > to make one answer do correct duty for all the arches, but what they've > accomplished is managing to completely miss the mark, to leave out the > main data of what's the correct actual names of the images to download. > They keep on referring to "the install disks", so I can't figure out what > the miniinst is, or the bootonly. I have a small universe to choose from, > yes, but it should be size zero. disc1 has the sysinstall, the distribution and the most popular packages. miniinst only has sysinstall and the distribution, without any packages. bootonly only has boot blocks and loader (useful for system recovery). DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 6 21:01:59 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C14416A4CE; Sun, 6 Feb 2005 21:01:59 +0000 (GMT) Received: from smtp-vbr11.xs4all.nl (smtp-vbr11.xs4all.nl [194.109.24.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F74C43D1F; Sun, 6 Feb 2005 21:01:58 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) j16L1sqB067282; Sun, 6 Feb 2005 22:01:54 +0100 (CET) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.13.1/8.12.9) with ESMTP id j16L1rhK093418; Sun, 6 Feb 2005 22:01:53 +0100 (CET) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.13.1/8.13.1/Submit) id j16L1rY2093417; Sun, 6 Feb 2005 22:01:53 +0100 (CET) (envelope-from wb) Date: Sun, 6 Feb 2005 22:01:53 +0100 From: Wilko Bulte To: Scott Long Message-ID: <20050206210153.GA93388@freebie.xs4all.nl> References: <20050206152314.A62347@april.chuckr.org> <4206831A.7020404@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4206831A.7020404@freebsd.org> X-OS: FreeBSD 4.11-RC2 User-Agent: Mutt/1.5.6i X-Virus-Scanned: by XS4ALL Virus Scanner cc: Chuck Robey cc: FreeBSD Hackers List Subject: Re: i86 install images X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2005 21:01:59 -0000 On Sun, Feb 06, 2005 at 01:50:34PM -0700, Scott Long wrote.. > Chuck Robey wrote: > >I need someone to verify for me, the disc1 image on the main > >(ftp.freebsd.org) website image, I have downloaded it 3 times now, and it > >keeps on reporting to me, when I try to burn it, that it's the miniinst > >image. I'm capable of missing something obvious, so I am asking someone > >(anyone) else to check this, please. > > > > I assume that you're talking about 5.3-R or 4.11-R? If you think that > the image might be corrupt, could you verify the MD5 checksum with what > was published in the release announcement? > > >One item that always irks me, what's the actual name of the disk images. > >There is a reticence to answer this on the website, cause they're trying > >to make one answer do correct duty for all the arches, but what they've > >accomplished is managing to completely miss the mark, to leave out the > >main data of what's the correct actual names of the images to download. > >They keep on referring to "the install disks", so I can't figure out what > >the miniinst is, or the bootonly. I have a small universe to choose from, > >yes, but it should be size zero. > > > > The general scheme is: > > bootonly: just the kernel and sysinstall. Equivalent to the boot > floppies. Only for doing network installs > > miniinst: kernel, sysinstall, installation distributions, perl package. > The minimum you need to install FreeBSD from a single CD. > > disc1: kernel, sysinstall, install distributions, lots of packages. > Good for installing a desktop like Gnome or KDE. For 4.11R there were two disc1 images, one with KDE, one with GNOME. The iso file names reflect this. -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 6 21:21:23 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C21D816A4CE for ; Sun, 6 Feb 2005 21:21:23 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39E7243D49 for ; Sun, 6 Feb 2005 21:21:23 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id j16LJN1X077862; Sun, 6 Feb 2005 14:19:24 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sun, 06 Feb 2005 14:21:20 -0700 (MST) Message-Id: <20050206.142120.13026592.imp@bsdimp.com> To: PeterJeremy@optushome.com.au From: "M. Warner Losh" In-Reply-To: <20050205055119.GC44250@cirb503493.alcatel.com.au> References: <20050205055119.GC44250@cirb503493.alcatel.com.au> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: Sharing memory between ithread and userland X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2005 21:21:23 -0000 Have you marked the dev_status struct volatile so that the compiler is forced to re-fetch from memory the values? The example you provided didn't have this... Warner From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 6 21:24:22 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8ACF516A4CE for ; Sun, 6 Feb 2005 21:24:22 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2069143D1F for ; Sun, 6 Feb 2005 21:24:22 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id j16LLMCc077873; Sun, 6 Feb 2005 14:21:23 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sun, 06 Feb 2005 14:23:19 -0700 (MST) Message-Id: <20050206.142319.22504831.imp@bsdimp.com> To: dmw@unete.cl From: "M. Warner Losh" In-Reply-To: <20050206132124.GA746@daemon.unete.cl> References: <20050206132124.GA746@daemon.unete.cl> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-hackers@FreeBSD.ORG Subject: Re: any way to reset errno? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2005 21:24:22 -0000 In message: <20050206132124.GA746@daemon.unete.cl> Daniel Molina Wegener writes: : Any way to reset errno? errno = 0; Routines that return an error status in errno generally don't set it to 0 to mean no error. Warner From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 6 22:16:01 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 758F016A4CE for ; Sun, 6 Feb 2005 22:16:01 +0000 (GMT) Received: from gau.lava.net (gau.lava.net [64.65.64.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4025E43D31 for ; Sun, 6 Feb 2005 22:16:01 +0000 (GMT) (envelope-from julian@lava.net) Received: from [64.65.85.10] (taurus.cesta.com [64.65.85.10]) by gau.lava.net (Postfix) with ESMTP id 82E421715C; Sun, 6 Feb 2005 12:16:00 -1000 (HST) Message-ID: <4206971F.1020005@lava.net> Date: Sun, 06 Feb 2005 12:15:59 -1000 From: Julian Cowley User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M. Warner Losh" References: <20050206132124.GA746@daemon.unete.cl> <20050206.142319.22504831.imp@bsdimp.com> In-Reply-To: <20050206.142319.22504831.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@FreeBSD.ORG cc: dmw@unete.cl Subject: Re: [Hackers] Re: any way to reset errno? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2005 22:16:01 -0000 M. Warner Losh wrote: > In message: <20050206132124.GA746@daemon.unete.cl> > Daniel Molina Wegener writes: > : Any way to reset errno? > > errno = 0; > > Routines that return an error status in errno generally don't set it > to 0 to mean no error. Which implies errno should never need to be set to zero since the convention is to only look at errno if a system call fails. The only time errno needs to be explicitly set (to any value) is when preserving the error value between system calls. Such as: if (write(fd, buf, len) < 0) { int saved_errno; saved_errno = errno; close(fd); /* ignore any error */ errno = saved_errno; return -1; } From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 6 22:30:10 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 36BC816A4CF; Sun, 6 Feb 2005 22:30:10 +0000 (GMT) Received: from april.chuckr.org (april.chuckr.org [66.92.151.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B5EA43D39; Sun, 6 Feb 2005 22:30:09 +0000 (GMT) (envelope-from chuckr@chuckr.org) Received: from april.chuckr.org (localhost [127.0.0.1]) by april.chuckr.org (8.13.1/8.12.11) with ESMTP id j16Mg8Nu085291; Sun, 6 Feb 2005 17:42:08 -0500 (EST) (envelope-from chuckr@chuckr.org) Received: from localhost (chuckr@localhost)j16Mg8l8085288; Sun, 6 Feb 2005 17:42:08 -0500 (EST) (envelope-from chuckr@chuckr.org) X-Authentication-Warning: april.chuckr.org: chuckr owned process doing -bs Date: Sun, 6 Feb 2005 17:42:07 -0500 (EST) From: Chuck Robey To: Scott Long In-Reply-To: <4206831A.7020404@freebsd.org> Message-ID: <20050206173738.V84804@april.chuckr.org> References: <20050206152314.A62347@april.chuckr.org> <4206831A.7020404@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: FreeBSD Hackers List Subject: Re: i86 install images X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2005 22:30:10 -0000 On Sun, 6 Feb 2005, Scott Long wrote: > Chuck Robey wrote: > > I need someone to verify for me, the disc1 image on the main > > (ftp.freebsd.org) website image, I have downloaded it 3 times now, and it > > keeps on reporting to me, when I try to burn it, that it's the miniinst > > image. I'm capable of missing something obvious, so I am asking someone > > (anyone) else to check this, please. > > > > I assume that you're talking about 5.3-R or 4.11-R? If you think that > the image might be corrupt, could you verify the MD5 checksum with what > was published in the release announcement? > > > One item that always irks me, what's the actual name of the disk images. > > There is a reticence to answer this on the website, cause they're trying > > to make one answer do correct duty for all the arches, but what they've > > accomplished is managing to completely miss the mark, to leave out the > > main data of what's the correct actual names of the images to download. > > They keep on referring to "the install disks", so I can't figure out what > > the miniinst is, or the bootonly. I have a small universe to choose from, > > yes, but it should be size zero. > > > > The general scheme is: > > bootonly: just the kernel and sysinstall. Equivalent to the boot > floppies. Only for doing network installs > > miniinst: kernel, sysinstall, installation distributions, perl package. > The minimum you need to install FreeBSD from a single CD. > > disc1: kernel, sysinstall, install distributions, lots of packages. > Good for installing a desktop like Gnome or KDE. > > disc2: kernel, sysinstall, no install distributions, live filesystem. > Good for recovering broken systems. I used it for just this a few days > ago myself. > > The iso9660 label name sometimes gets screwed up when we cut releases. > We should be better about this, but it's not something that is always > obvious. We are working on a new scheme that combines disc2 and > miniinst and puts all packages on disc2. There will no longer be a > miniinst after that, just disc1, disc2, and possbily bootonly. 3 different responses, all 3 entirely professional, and this is the reason why FreeBSD is never going to be entirely removed by Linux, because the support is so GREAT! Anyhow, I do my downloading using my Mac machine, and it's reporting the, say for the disc1, it's "miniinst" and for disc2, it's reporting "LiveFS". I know it's not important what label's on the disc, as long as it's not part of the install, but having the names not only being wrong. but actually overwriting good names, that's not very good. If I was root, I would want that fixed, it would embarrass me. Just before I sign off here, once more, thanks for the gret response! > > Scott > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > ---------------------------------------------------------------------------- Chuck Robey | Interests include C & Java programming, FreeBSD, chuckr@chuckr.org | electronics, communications, and SF/Fantasy. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary (on the wall at my old fraternity, Signa Phi Nothing). ---------------------------------------------------------------------------- From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 6 23:12:31 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 441B816A4CE for ; Sun, 6 Feb 2005 23:12:31 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id C477F43D45 for ; Sun, 6 Feb 2005 23:12:30 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id j16NBa4H078932; Sun, 6 Feb 2005 16:11:36 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sun, 06 Feb 2005 16:13:33 -0700 (MST) Message-Id: <20050206.161333.103235960.imp@bsdimp.com> To: julian@lava.net From: "M. Warner Losh" In-Reply-To: <4206971F.1020005@lava.net> References: <20050206132124.GA746@daemon.unete.cl> <20050206.142319.22504831.imp@bsdimp.com> <4206971F.1020005@lava.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-hackers@FreeBSD.ORG cc: dmw@unete.cl Subject: Re: [Hackers] Re: any way to reset errno? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2005 23:12:31 -0000 In message: <4206971F.1020005@lava.net> Julian Cowley writes: : M. Warner Losh wrote: : > In message: <20050206132124.GA746@daemon.unete.cl> : > Daniel Molina Wegener writes: : > : Any way to reset errno? : > : > errno = 0; : > : > Routines that return an error status in errno generally don't set it : > to 0 to mean no error. : : Which implies errno should never need to be set to zero since the : convention is to only look at errno if a system call fails. The only : time errno needs to be explicitly set (to any value) is when preserving : the error value between system calls. Such as: : : if (write(fd, buf, len) < 0) { : int saved_errno; : : saved_errno = errno; : close(fd); /* ignore any error */ : errno = saved_errno; : return -1; : } Well, to portably[*] use some of the math(3) routines in libc, you need to set it to 0 before calling them (strtol, et al come to mind). Otherwise you are correct. In fact, it is generally incorrect to write code like: errno = 0; close(fd); if (errno != 0) because errno isn't necessarily valid even if it has changed in that case... Warner From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 6 23:23:30 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9EDE216A4CE; Sun, 6 Feb 2005 23:23:30 +0000 (GMT) Received: from mail.ipnet.kiev.ua (cielago.ip.net.ua [82.193.96.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB85C43D49; Sun, 6 Feb 2005 23:23:28 +0000 (GMT) (envelope-from nick@nicks.ipnet.kiev.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by mail.ipnet.kiev.ua (8.12.11/8.12.11) with ESMTP id j16NMuF5019378; Mon, 7 Feb 2005 01:22:56 +0200 (EET) (envelope-from nick@nicks.ipnet.kiev.ua) Received: from mail.ipnet.kiev.ua ([82.193.96.7]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 38679-04; Mon, 7 Feb 2005 01:23:05 +0200 (EET) Received: from nicks.ipnet.kiev.ua (82.193.102.156.ipnet.kiev.ua [82.193.102.156]) by mail.ipnet.kiev.ua (8.12.11/8.12.11) with ESMTP id j16NMtXc019375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Feb 2005 01:22:55 +0200 (EET) (envelope-from nick@nicks.ipnet.kiev.ua) Received: from nicks.ipnet.kiev.ua (localhost [127.0.0.1]) by nicks.ipnet.kiev.ua (8.13.1/8.13.1) with ESMTP id j16NN5fm002458; Mon, 7 Feb 2005 01:23:05 +0200 (EET) (envelope-from nick@nicks.ipnet.kiev.ua) Received: (from nick@localhost) by nicks.ipnet.kiev.ua (8.13.1/8.13.1/Submit) id j16NN5nx002457; Mon, 7 Feb 2005 01:23:05 +0200 (EET) (envelope-from nick) Date: Mon, 7 Feb 2005 01:23:05 +0200 From: Nick Strebkov To: Robert Watson Message-ID: <20050206232304.GA2346@nicks.ipnet.kiev.ua> Mail-Followup-To: Nick Strebkov , Robert Watson , Deomid Ryabkov , freebsd-hackers@freebsd.org, Milan Obuch References: <4200DCF6.1010002@rojer.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-u Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.3-STABLE X-Real-Name: =?koi8-u?B?89TSxcLLz9cgSMnLz8zByiDhzsHU?= =?koi8-u?B?z8zYxdfJ3g==?= X-Virus-Scanned: by amavisd-new at ip.net.ua cc: Deomid Ryabkov cc: Milan Obuch cc: freebsd-hackers@freebsd.org Subject: Re: Question: tracking filesystem changes? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2005 23:23:30 -0000 Hi, > > No, won't do the trick either. I cannot afford setting up watchdogs for > > every file or even every directory. And I'm essentially "interested" in > > every one of them (for mirroring purposes). A more general approach is > > needed. E.g., if an unlink call is issued and an inode is within a > > particular filesystem (luckily, most of our data already lives on or can > > be easily moved to a separate filesystem), a notice is sent to some > > userland daemon: "file /www/xxx/yyy.shtml is unlinked". Or opened for > > writing, or renamed... etc. The file is then scheduled for distribution > > to mirrors. The idea seems simple and straightforward, yet I don't know > > if it is achievable. > > > > The essential part is obtaining the full pathname of the file (won't > > bother with hardlinks at first, they aren't used here). Could that be > > done with the FreeBSD's filesystem (vnode/vfs?) code? (which I'm not > > familiar with) > > The TrustedBSD Audit code should be able to fill this need -- the goal of > the Audit code is to be able to track "security critical events" in a > configurable way, so file open/link/symlink/unlink operations are an > important subset of that. We hope to integrate the Audit code into 6.x in > the next few months, and then (in as much as is possible given kernel ABI > requirements) merge for 5.5. However, this is some time away still, so > presumably can't help in the short term. The result, though, is an event > stream file that's mechanically parseable, and the even stream can be > configured to indicate which types of events are important at a fairly > fine granularity. Sounds great. But i have similar tasks (not so huge amount of files) and i'd prefer to extend kqueue/kevent with EVFILT_INODE filter to have ability to monitor changes in file without opening it. -- Nick Strebkov Public key: http://humgat.org/~nick/pubkey.txt fpr: 552C 88D6 895B 6E64 F277 D367 8A70 8132 47F5 C1B6 From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 6 23:27:03 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C0B416A4CE for ; Sun, 6 Feb 2005 23:27:03 +0000 (GMT) Received: from node15.coopprint.com (node15.cooperativeprinting.com [208.4.77.15]) by mx1.FreeBSD.org (Postfix) with SMTP id C96E143D46 for ; Sun, 6 Feb 2005 23:27:02 +0000 (GMT) (envelope-from ryans@gamersimpact.com) Received: (qmail 63522 invoked by uid 0); 6 Feb 2005 23:26:53 -0000 Received: from unknown (HELO ?192.168.0.5?) (63.231.157.250) by node15.coopprint.com with SMTP; 6 Feb 2005 23:26:53 -0000 Message-ID: <4206A7C5.1000201@gamersimpact.com> Date: Sun, 06 Feb 2005 17:27:01 -0600 From: Ryan Sommers User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chuck Robey References: <20050206152314.A62347@april.chuckr.org> <4206831A.7020404@freebsd.org> <20050206173738.V84804@april.chuckr.org> In-Reply-To: <20050206173738.V84804@april.chuckr.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: FreeBSD Hackers List cc: Scott Long Subject: Re: i86 install images X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2005 23:27:03 -0000 Chuck Robey wrote: > Anyhow, I do my downloading using my Mac machine, and it's reporting the, > say for the disc1, it's "miniinst" and for disc2, it's reporting "LiveFS". > I know it's not important what label's on the disc, as long as it's not > part of the install, but having the names not only being wrong. but > actually overwriting good names, that's not very good. If I was root, I > would want that fixed, it would embarrass me. FYI, within the past 2 weeks I downloaded the 5.3-RELEASE image to an OSX mac and successfully burned it, not sure exactly what site it was. I never looked at the label however. One thing to remember though, when burning ISOs on an OSX mac the best way I've found it to open up a terminal (Applications / Utilities, if I remember correctly) and then do 'hdutil burn isoname' -- Ryan Sommers ryans@gamersimpact.com From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 7 00:45:42 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D1E2916A4CE for ; Mon, 7 Feb 2005 00:45:42 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7988943D39 for ; Mon, 7 Feb 2005 00:45:42 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id B4D9246B33; Sun, 6 Feb 2005 19:45:41 -0500 (EST) Date: Mon, 7 Feb 2005 00:44:45 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Nick Strebkov In-Reply-To: <20050206232304.GA2346@nicks.ipnet.kiev.ua> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Deomid Ryabkov cc: Milan Obuch cc: freebsd-hackers@freebsd.org Subject: Re: Question: tracking filesystem changes? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2005 00:45:42 -0000 On Mon, 7 Feb 2005, Nick Strebkov wrote: > > The TrustedBSD Audit code should be able to fill this need -- the goal of > > the Audit code is to be able to track "security critical events" in a > > configurable way, so file open/link/symlink/unlink operations are an > > important subset of that. We hope to integrate the Audit code into 6.x in > > the next few months, and then (in as much as is possible given kernel ABI > > requirements) merge for 5.5. However, this is some time away still, so > > presumably can't help in the short term. The result, though, is an event > > stream file that's mechanically parseable, and the even stream can be > > configured to indicate which types of events are important at a fairly > > fine granularity. > > Sounds great. But i have similar tasks (not so huge amount of files) > and i'd prefer to extend kqueue/kevent with EVFILT_INODE filter to have > ability to monitor changes in file without opening it. What mechanism do you have in mind for KQueue to notify you as to which file had an event? Robert N M Watson From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 7 01:05:31 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C4A5416A4CE for ; Mon, 7 Feb 2005 01:05:31 +0000 (GMT) Received: from walk.com.br (mail.walk.com.br [200.205.240.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 33FD443D48 for ; Mon, 7 Feb 2005 01:05:30 +0000 (GMT) (envelope-from luiz@microeletronica.com.br) Received: (qmail 98458 invoked by uid 1006); 7 Feb 2005 01:05:24 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 7 Feb 2005 01:05:24 -0000 Date: Sun, 6 Feb 2005 23:05:24 -0200 (BRDT) From: Luiz Otavio Souza X-X-Sender: luiz@serv-qmp.walk.com.br To: freebsd-hackers@freebsd.org Message-ID: <20050206222416.O88635@serv-qmp.walk.com.br> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: ATA_IDENTIFY timed out on ASUS P4VP-MX X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2005 01:05:31 -0000 Recently one of my clients get a new (very cheap) P4VP-MX wich uses a VIA VT8235 Southbridge. This machine is not detecting (identify) ATA disk under 5.3. I have tested with 5.3-STABLE and 5.3-RELEASE, with 4.X it works. I tried with different disks and with CDROM, but nothing works. The same disk run on another machines (including a P4SP-MX wich uses SIS chipset) and 4.X run normaly. I have do some code debug, and ata_getparam() get no return (no interrupt is generated - ata_interrupt() never run). The workaround of PR/73706 not work for me (my secondary ATA also fail) and break another machine on tests. I'm playing with interrupt routing, but i cant get it working. Also tried with dma, acpi, pci.enable_io_modes and apic disabled. There is no error on dmesg until ATA_IDENTIFY timed out. Any ideas / workaround ? Thanks, Luiz From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 7 04:58:27 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0FAB016A4CE for ; Mon, 7 Feb 2005 04:58:27 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6164743D2D for ; Mon, 7 Feb 2005 04:58:25 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by rproxy.gmail.com with SMTP id z35so669894rne for ; Sun, 06 Feb 2005 20:58:23 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=oj4iCmlCzu46AMDj/GXbekSjG2zTmhrdAV8T/VSj+hhYMxiNQvicW9tYJoQup4x8XcqcWsWy3wN/dDNu0Yx6sVs3z5RGQvaYTNJZbydBn+u+5vipoyvssCvlviJdZ/wdVypQVvOemKMVgaiUUcFGDcU9UXJ6AhYgM8JYkdM8H9s= Received: by 10.38.96.29 with SMTP id t29mr179822rnb; Sun, 06 Feb 2005 20:58:23 -0800 (PST) Received: by 10.38.209.12 with HTTP; Sun, 6 Feb 2005 20:58:23 -0800 (PST) Message-ID: <84dead720502062058551f61c2@mail.gmail.com> Date: Mon, 7 Feb 2005 04:58:23 +0000 From: Joseph Koshy To: Ashwin Chandra In-Reply-To: <4206008F.2060100@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <001301c50c3e$1a8003b0$58e243a4@ash> <4206008F.2060100@freebsd.org> cc: freebsd-hackers@freebsd.org Subject: Re: Opening and wriiting to file in Kern X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Joseph Koshy List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2005 04:58:27 -0000 > If you mist do this, the general set of steps are: > > 1. use namei() to convert a pathname to a vnode > 2. Use vn_open(), vn_rdwr(), and vn_close() to operate on the vnode. > 3. Observe proper vnode locking and reference counting with vref(), > vn_lock(), and vput() Take a look at "sys/kern/kern_ktrace.c" or "sys/kern/kern_alq.c" for a template. -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 7 05:33:13 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B4D3316A4CE for ; Mon, 7 Feb 2005 05:33:13 +0000 (GMT) Received: from smtp.ucla.edu (smtp.ucla.edu [169.232.48.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63F1643D1F for ; Mon, 7 Feb 2005 05:33:13 +0000 (GMT) (envelope-from ashcs@ucla.edu) Received: from mail.ucla.edu (mail.ucla.edu [169.232.48.135]) by smtp.ucla.edu (8.13.1/8.13.1) with ESMTP id j175X9Uc000925 for ; Sun, 6 Feb 2005 21:33:09 -0800 Received: from ash (s226-88.resnet.ucla.edu [164.67.226.88]) (authenticated bits=0) by mail.ucla.edu (8.13.3/8.13.3) with ESMTP id j175XCGx016247 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sun, 6 Feb 2005 21:33:12 -0800 Message-ID: <002901c50cd6$89db4330$58e243a4@ash> From: "Ashwin Chandra" To: Date: Sun, 6 Feb 2005 21:33:22 -0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Probable-Spam: no X-Spam-Hits: 1.054 X-Spam-Score: * X-Scanned-By: smtp.ucla.edu Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Opening files in Kernel Mode: help X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2005 05:33:13 -0000 So this is the code I got from help from you hackers out there and = templates in the /kern library. This compiles but causes a kernel panic. = I was wondering if any of you knew why this was happening and if I am = calling all the virtual node functions correctly? =20 ***********************CODE BELOW************************ register struct proc *p; struct nameidata nd; int flags =3D FWRITE | O_CREAT; struct ucred *uc; static struct ucred *acctcred; char data[1000]; acctcred =3D crhold(curthread->td_ucred); uc =3D crhold(acctcred); NDINIT(&nd, CREATE, FOLLOW, UIO_SYSSPACE, "/home/achandra/LOG", = curthread); vn_open(&nd, &flags, 0,-1); NDFREE(&nd, NDF_ONLY_PNBUF); vref(nd.ni_vp); VOP_LEASE(nd.ni_vp, curthread, uc, LEASE_WRITE); sprintf(data, "%s", "asdsada"); vn_rdwr(UIO_WRITE, nd.ni_vp, (caddr_t)data, strlen(data), (off_t)0, UIO_SYSSPACE, IO_APPEND|IO_UNIT, uc, NOCRED, (int *)0, curthread); vrele(nd.ni_vp); crfree(uc); vn_close(nd.ni_vp, flags, curthread->td_ucred, curthread); From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 7 05:55:06 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF08D16A4CE for ; Mon, 7 Feb 2005 05:55:06 +0000 (GMT) Received: from mta1.srv.hcvlny.cv.net (mta1.srv.hcvlny.cv.net [167.206.5.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D1D143D1D for ; Mon, 7 Feb 2005 05:55:06 +0000 (GMT) (envelope-from alex@hightemplar.com) Received: from [192.168.1.50] (ool-18b99517.dyn.optonline.net [24.185.149.23]) by mta1.srv.hcvlny.cv.net (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IBJ00CSL1RS7O@mta1.srv.hcvlny.cv.net> for freebsd-hackers@freebsd.org; Mon, 07 Feb 2005 00:55:05 -0500 (EST) Date: Mon, 07 Feb 2005 00:54:55 -0500 From: A G Keahan To: Nick Strebkov Message-id: <420702AF.3000705@hightemplar.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) cc: freebsd-hackers@freebsd.org Subject: Re: Question: tracking filesystem changes? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2005 05:55:06 -0000 > > No, won't do the trick either. I cannot afford setting up watchdogs > > for every file or even every directory. And I'm essentially > > "interested" in every one of them (for mirroring purposes). A more > > general approach is needed. E.g., if an unlink call is issued and > > an inode is within a particular filesystem (luckily, most of our > > data already lives on or can be easily moved to a separate > > filesystem), a notice is sent to some userland daemon: > > "file /www/xxx/yyy.shtml is unlinked". Or opened for writing, or > > renamed... etc. The file is then scheduled for distribution to > > mirrors. The idea seems simple and straightforward, yet I don't > > know if it is achievable. > > > > The essential part is obtaining the full pathname of the file (won't > > bother with hardlinks at first, they aren't used here). Could that > > be done with the FreeBSD's filesystem (vnode/vfs?) code? (which I'm > > not familiar with) Nick, You might want to take a look at Matt Dillon's journalling work in DragonFly BSD. Their journalling layer can send a filesystem operations change stream (essentially, vfsops such as create, write, truncate, rmdir, etc) to any file descriptor, which makes filesystem changes easy to track and replicate to other machines. See the "Description of the Journaling topology" thread at http://leaf.dragonflybsd.org/mailarchive/kernel/2004-12/dateindex.html Alex From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 7 07:27:47 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8AFD116A4CE for ; Mon, 7 Feb 2005 07:27:47 +0000 (GMT) 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 CABE443D58 for ; Mon, 7 Feb 2005 07:27:46 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id j177RcRS073398; Mon, 7 Feb 2005 08:27:40 +0100 (CET) (envelope-from sos@DeepCore.dk) Message-ID: <42071856.5080205@DeepCore.dk> Date: Mon, 07 Feb 2005 08:27:18 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Luiz Otavio Souza References: <20050206222416.O88635@serv-qmp.walk.com.br> In-Reply-To: <20050206222416.O88635@serv-qmp.walk.com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-mail-scanned: by DeepCore Virus & Spam killer v1.6 cc: freebsd-hackers@freebsd.org Subject: Re: ATA_IDENTIFY timed out on ASUS P4VP-MX X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2005 07:27:47 -0000 Luiz Otavio Souza wrote: >=20 > Recently one of my clients get a new (very cheap) P4VP-MX wich uses a=20 > VIA VT8235 Southbridge. >=20 > This machine is not detecting (identify) ATA disk under 5.3. >=20 > I have tested with 5.3-STABLE and 5.3-RELEASE, with 4.X it works. >=20 > I tried with different disks and with CDROM, but nothing works. >=20 > The same disk run on another machines (including a P4SP-MX wich uses SI= S=20 > chipset) and 4.X run normaly. >=20 > I have do some code debug, and ata_getparam() get no return (no=20 > interrupt is generated - ata_interrupt() never run). >=20 > The workaround of PR/73706 not work for me (my secondary ATA also fail)= =20 > and break another machine on tests. >=20 > I'm playing with interrupt routing, but i cant get it working. >=20 > Also tried with dma, acpi, pci.enable_io_modes and apic disabled. >=20 > There is no error on dmesg until ATA_IDENTIFY timed out. >=20 > Any ideas / workaround ? Please try the ATA-mkIII patches+tarfile I announced last week on=20 -current and -stable.. --=20 -S=F8ren From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 7 09:16:37 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D94B16A4CE for ; Mon, 7 Feb 2005 09:16:37 +0000 (GMT) Received: from gatekeeper.syskonnect.de (gatekeeper.syskonnect.de [213.144.13.149]) by mx1.FreeBSD.org (Postfix) with ESMTP id 149A143D1D for ; Mon, 7 Feb 2005 09:16:36 +0000 (GMT) (envelope-from gheinig@syskonnect.de) Received: from syskonnect.de (skd.de [10.9.15.1])j179Gl91025088 for ; Mon, 7 Feb 2005 10:16:47 +0100 (MET) Received: from syskonnect.de (localhost [127.0.0.1]) by syskonnect.de (8.12.11/8.12.11) with ESMTP id j179GXJ7018014 for ; Mon, 7 Feb 2005 10:16:34 +0100 (MET) Message-ID: <420731DD.3050206@syskonnect.de> Date: Mon, 07 Feb 2005 10:16:13 +0100 From: Gerald Heinig User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hackers@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Firewire blues X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2005 09:16:37 -0000 Hi all, I'm having problems getting two 5.3-RELEASE boxes to communicate over firewire. I'm using two VIA Vt-6306 -based cards which are correctly recognised at boot-time. I've loaded the dcons and dconschat modules and obtained both firewire addresses via fwcontrol. When I try to set up a connection with dconschat I get [dcons disconnected (get crom failed)] The exact command I gave is: dconschat -br -G 5556 -t I also tried setting the control ROM address with the -a option, to no avail. Anyone have any ideas as to where I'm going wrong? BTW, I'm trying to set up remote debugging with gdb to debug a kernel hang. Cheers, Gerald From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 7 09:27:08 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 252F516A4D2; Mon, 7 Feb 2005 09:27:08 +0000 (GMT) Received: from mir.ics.es.osaka-u.ac.jp (mir.ics.es.osaka-u.ac.jp [133.1.12.154]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2288143D41; Mon, 7 Feb 2005 09:27:06 +0000 (GMT) (envelope-from k-sasaki@ist.osaka-u.ac.jp) Received: from pinklady2 ([192.168.144.174])j179QtPq037564; Mon, 7 Feb 2005 18:27:03 +0900 (JST) (envelope-from k-sasaki@ist.osaka-u.ac.jp) Message-Id: <200502070927.j179QtPq037564@mir.ics.es.osaka-u.ac.jp> From: "Kei Sasaki" To: , Date: Mon, 7 Feb 2005 18:26:56 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUIVwUrRGyx+8VFSOeQg2eVKY8zDQEm8lTw cc: k-sasaki@ist.osaka-u.ac.jp Subject: FW: Call for comments: CoxR, a CVS/mail-lists/BTS searching system X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2005 09:27:08 -0000 Dear Sirs Thanks for the many feedbacks about CoxR. We modified the CoxR based on feedback. And so, please try CoxR function once more. Our website: http://sel.ics.es.osaka-u.ac.jp/~k-sasaki/coxr.html and CoxR can be found at http://scorpion.ics.es.osaka-u.ac.jp/cgi-bin/CodeSearch/coxr.html I would like to have your impressions on the above mentioned information system as an open source expert Any feedback including the answer of questions above, comments, suggestions, etc are always welcome, Please email to$B!!(B" k-sasaki@ist.osaka-u.ac.jp ". We want your comments for usefulness evaluation. Thanks in advance for your time. Best regards, Sasaki Kei ------------------------- SASAKI Kei Graduate School of Information Science and Technology, Osaka University, Japan email-address : k-sasaki@ist.osaka-u.ac.jp > > Dear Sirs/Madams > > > I am a second-year master's student at the Osaka University, Japan. > My major is computer science and my interests lie in the development process of open source software, interests that I pursue being part of the local >>> > research group on software process. > > My research group is suggesting an approach for exploiting the informations implicitly contained in history archives like, for example, project's CVS, > > > > mailing lists archives, Bug Trucking System and so on. > > The result of our research is the information system named "CoxR" > we developed and that can be found the detail about it at : > http://sel.ics.es.osaka-u.ac.jp/~k-sasaki/coxr.html > > I would like to have your impressions on the above mentioned information system as an open source expert. > CoxR can be found at > http://scorpion.ics.es.osaka-u.ac.jp/cgi-bin/CodeSearch/coxr.html > > Thanks in advance for your time. > > Best regards, > Sasaki Kei > > ------------------------- > SASAKI Kei > Graduate School of Information Science and Technology, Osaka University, Japan email-address : k-sasaki@ist.osaka-u.ac.jp > From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 7 12:28:05 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7299516A4CE for ; Mon, 7 Feb 2005 12:28:05 +0000 (GMT) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 169D143D2F for ; Mon, 7 Feb 2005 12:28:02 +0000 (GMT) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: from ednmsw503.dsto.defence.gov.au (ednmsw503.dsto.defence.gov.au [131.185.2.150]) by digger1.defence.gov.au with ESMTP id j17CQkis010424 for ; Mon, 7 Feb 2005 22:56:46 +1030 (CST) Received: from muttley.dsto.defence.gov.au (unverified) by ednmsw503.dsto.defence.gov.au (Content Technologies SMTPRS 4.3.10) with ESMTP id for ; Mon, 7 Feb 2005 22:57:55 +1030 Received: from ednex501.dsto.defence.gov.au (ednex501.dsto.defence.gov.au [131.185.2.81]) by muttley.dsto.defence.gov.au (8.11.3/8.11.3) with ESMTP id j17CLJQ22376 for ; Mon, 7 Feb 2005 22:51:19 +1030 (CST) Received: from squash.dsto.defence.gov.au ([131.185.40.212]) by ednex501.dsto.defence.gov.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YK392NQC; Mon, 7 Feb 2005 22:51:13 +1030 Received: from squash.dsto.defence.gov.au (localhost [127.0.0.1]) by squash.dsto.defence.gov.au (8.12.11/8.12.11) with ESMTP id j17CNRKD053117 for ; Mon, 7 Feb 2005 22:53:27 +1030 (CST) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by squash.dsto.defence.gov.au (8.12.11/8.12.11/Submit) id j17CNRQh053116 for hackers@freebsd.org; Mon, 7 Feb 2005 22:53:27 +1030 (CST) (envelope-from wilkinsa) Date: Mon, 7 Feb 2005 22:53:26 +1030 From: "Wilkinson, Alex" To: hackers@freebsd.org Message-ID: <20050207122325.GB53000@squash.dsto.defence.gov.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: kgdb(1) - dealing with a corrupt stack [?] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2005 12:28:05 -0000 Hi all, I am trying to debug why my kernel is panicing whilst playing audio via xmms. I am manually calling 'doadump' via ddb(4) - this seems ok. However, when I do a backtrace via kgdb(1) I seem to get a corrupt stack. Can anyone suggest why this would be happening and solutions to get a 'healthy' backtrace. NOTE: I have tryed a backtrace on a kernel with staticly compiled drivers and with klds'. Same outcome. (kgdb) where #0 doadump () at pcpu.h:159 #1 0xc044e7b3 in db_fncall (dummy1=-1068282275, dummy2=0, dummy3=-1, dummy4=0xe52b68e8 "") at /usr/src/sys/ddb/db_command.c:531 #2 0xc044ec55 in db_command_loop () at /usr/src/sys/ddb/db_command.c:349 #3 0xc0450910 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:221 #4 0xc052c112 in kdb_trap (type=0, code=0, tf=0xe52b6a58) at /usr/src/sys/kern/subr_kdb.c:418 #5 0xc06827d6 in trap_fatal (frame=0xe52b6a58, eva=36) at /usr/src/sys/i386/i386/trap.c:804 #6 0xc0682d65 in trap (frame= {tf_fs = -1030160360, tf_es = -1033502704, tf_ds = 2147418128, tf_edi = -1066324840, tf_esi = -1023201776, tf_ebp = -450139444, tf_isp = -450139516, tf_ebx = -1030158384, tf_edx = -1028611392, tf_ecx = 160, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1068282275, tf_cs = 8, tf_eflags = 77971, tf_esp = 0, tf_ss = -1068294051}) at /usr/src/sys/i386/i386/trap.c:247 #7 0xc06712da in calltrap () at /usr/src/sys/i386/i386/exception.s:140 #8 0xc2990018 in ?? () #9 0xc2660010 in ?? () #10 0x7fff0010 in ?? () #11 0xc0712c98 in turnstile_chains () #12 0xc3032e10 in ?? () #13 0xe52b6acc in ?? () #14 0xe52b6a84 in ?? () #15 0xc29907d0 in ?? () #16 0xc2b0a2c0 in ?? () #17 0x000000a0 in ?? () #18 0x00000000 in ?? () #19 0x0000000c in ?? () #20 0x00000000 in ?? () #21 0xc0534e5d in turnstile_wait (ts=0xc2b35d80, lock=0xc070efe0, owner=0xc3032e10) at /usr/src/sys/kern/subr_turnstile.c:243 #22 0xc05055ef in _mtx_lock_sleep (m=0xc070efe0, td=0xc29907d0, opts=0, file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:560 #23 0xc04e3509 in cv_timedwait_sig (cvp=0xc0714064, mp=0xc0714040, timo=0) at /usr/src/sys/kern/kern_condvar.c:334 #24 0xc0536cca in kern_select (td=0xc29907d0, nd=64, fd_in=0x81c63c0, fd_ou=0x0, fd_ex=0x0, tvp=0xe52b6ccc) at /usr/src/sys/kern/sys_generic.c:753 #25 0xc053731c in select (td=0x0, uap=0xe52b6d14) at /usr/src/sys/kern/sys_generic.c:625 #26 0xc0683334 in syscall (frame= {tf_fs = 47, tf_es = 47, tf_ds = -1078001617, tf_edi = -1, tf_esi = -1, tf_ebp = -1077941784, tf_isp = -450138764, tf_ebx = 119451, tf_edx = 16, tf_ecx = 139525536, tf_eax = 93, tf_trapno = 0, tf_err = 2, tf_eip = 673567859, tf_cs = 31, tf_eflags = 12870, tf_esp = -1077942388, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1001 #27 0xc067132f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:201 #28 0x0000002f in ?? () #29 0x0000002f in ?? () #30 0xbfbf002f in ?? () #31 0xffffffff in ?? () #32 0xffffffff in ?? () #33 0xbfbfe9e8 in ?? () #34 0xe52b6d74 in ?? () #35 0x0001d29b in ?? () #36 0x00000010 in ?? () #37 0x0850fda0 in ?? () #38 0x0000005d in ?? () #39 0x00000000 in ?? () #40 0x00000002 in ?? () #41 0x2825d473 in ?? () #42 0x0000001f in ?? () #43 0x00003246 in ?? () #44 0xbfbfe78c in ?? () #45 0x0000002f in ?? () #46 0xffffffff in ?? () #47 0xffffffff in ?? () #48 0xffffffff in ?? () #49 0xffffefff in ?? () #50 0x3e9d7000 in ?? () #51 0xc2b78388 in ?? () #52 0xc29907d0 in ?? () #53 0xe52b6a6c in ?? () #54 0xe52b6a54 in ?? () #55 0xc26644b0 in ?? () #56 0xc0523eda in sched_switch (td=0xffffffff, newtd=0x1d29b, flags=Cannot access memory at address 0xbfbfe9f8 ) at /usr/src/sys/kern/sched_4bsd.c:865 Previous frame inner to this frame (corrupt stack?) (kgdb) Thanks - aW From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 7 02:24:55 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF5FB16A4CE for ; Mon, 7 Feb 2005 02:24:55 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DF5643D2D for ; Mon, 7 Feb 2005 02:24:53 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j166Tpbc027145; Sat, 5 Feb 2005 22:29:52 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j166Tj8c027144; Sat, 5 Feb 2005 22:29:45 -0800 (PST) (envelope-from www) Date: Sat, 5 Feb 2005 22:29:45 -0800 (PST) Message-Id: <200502060629.j166Tj8c027144@marlena.vvi.at> To: justin@shiningsilence.com From: "ALeine" X-Mailman-Approved-At: Mon, 07 Feb 2005 13:26:04 +0000 cc: freebsd-hackers@freebsd.org cc: kernel@crater.dragonflybsd.org Subject: Re: RFC: backporting GEOM to the 4.x branch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2005 02:24:55 -0000 justin@shiningsilence.com wrote: > The subject of doxygen has come up a few times, and people haven't been > too keen on it: > > http://leaf.dragonflybsd.org/mailarchive/kernel/2003-10/msg00197.html > http://leaf.dragonflybsd.org/mailarchive/kernel/2003-10/msg00199.html > > I'm assuming you'd have to have the extra data from doxygen to generate > those graphs, as I've not done that process, myself. Basically, doxygen generates graph file language (dot) files, which are then fed to graphviz to generate the graphs. An important thing to note is that the HTML generated by doxygen uses map area tags, which means that graph nodes are clickable, so you can browse code graphically and very quickly familiarize yourself with all the dependencies and intricate details. Here is another demonstrative example: http://manson.vistech.net/~manager/vfs__syscalls_8c_a44_cgraph.png If you install doxygen from the FreeBSD ports (devel/doxygen) it will automatically install graphviz (graphics/graphviz) and then you can just launch doxywizard and create a doxyfile within 3 minutes even if you've never set eyes on doxygen before. Once you are happy with the results all you need is a cron job to run doxygen using your doxywizard generated doxyfile. There is no maintenance overhead, so I do not see a reason why this should not be implemented. Also, the generated documentation can reside where ever you want it to be, so the source tree can remain intact. This sort of documentation should be seen as supplementary and not as a replacement for the handbook documentation or anything else. It's also not meant to be implemented in a way that would interfere with the established source coding and documenting practices. The few developers who "live the code" could totally ignore the doxygen generated documentation, but the rest of us would find it a great help to have this kind of resource. I also think that even those hardcore developers could use this kind of documentation for quickly looking up all the functions that call a certain function and to save time when explaining the details to other developers. Why spend 5 minutes describing something you can explain by having someone take a look at a graph? Maybe most developers think that etags and cscope are all they need, but to me personally the reference graphs alone are reason enough to use doxygen. As you probably know Robert Watson runs a nice FreeBSD Cross-reference site (fxr.watson.org), but I believe doxygen to be superior to the LXR/FXR engine, so perhaps it would be a good idea to replace LXR/FXR with doxygen. Any opinions on that? The bottom line is, doxygen takes 10 minutes to set up and other than a fair amount of CPU time and a few GB of disk space for the generated documentation it requires nothing special. :-) It will not interfere with anyone's work, but it will make the development process easier and more accessible to a number of potential developers. ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 6 19:45:54 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 035E516A4CF for ; Sun, 6 Feb 2005 19:45:54 +0000 (GMT) Received: from web40902.mail.yahoo.com (web40902.mail.yahoo.com [66.218.78.199]) by mx1.FreeBSD.org (Postfix) with SMTP id A5EBC43D39 for ; Sun, 6 Feb 2005 19:45:53 +0000 (GMT) (envelope-from yanyu_1997@yahoo.com) Received: (qmail 33197 invoked by uid 60001); 6 Feb 2005 19:45:53 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=Be5adDbqeFj9rZu7M6xAmCPvAbrYtQEm6y4RC8xO7syEEh0Dj+iAmaJKczg+31n66eEQiXz60InXxYm04KN9QKiheITxwQgB0vZ20DCjIFlzw7+3eO68OI2iC1gbQZdKJVKazm9CpXQbW/XUT2H9efBE2cpI6a50crODFIplRh0= ; Message-ID: <20050206194553.33195.qmail@web40902.mail.yahoo.com> Received: from [24.127.104.185] by web40902.mail.yahoo.com via HTTP; Sun, 06 Feb 2005 11:45:53 PST Date: Sun, 6 Feb 2005 11:45:53 -0800 (PST) From: Yan Yu To: Robert Watson , Yan Yu In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Mon, 07 Feb 2005 13:26:22 +0000 cc: freebsd-hackers@freebsd.org Subject: Re: falloc() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Feb 2005 19:45:54 -0000 hi, THANKS FOR the pointer! > falloc() isn't considered a "pluggable" kernel API, > that is to say, we've > not engineered FreeBSD with the intent that it be > replaced at run-time. > If you don't mind my asking, what motivates you to > replace falloc()? i would like to add more checks (e.g., resource usage restrictions) before a file is being created, e.g., the upper limit of the total number of file descriptors that can be created by a single user (the same uid). THe reason I did not replace fopen() is that: there are many places (besides fopen) will create a new file (vnode). a quick checked shows that _falloc_ is called by many places.. does this make sense, or i should make change in some other place? THanks! yan __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 7 14:01:05 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 14D7416A4CE; Mon, 7 Feb 2005 14:01:05 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC2C243D1D; Mon, 7 Feb 2005 14:01:04 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j16I6Abc037041; Sun, 6 Feb 2005 10:06:11 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j16I64bE037040; Sun, 6 Feb 2005 10:06:04 -0800 (PST) (envelope-from www) Date: Sun, 6 Feb 2005 10:06:04 -0800 (PST) Message-Id: <200502061806.j16I64bE037040@marlena.vvi.at> To: k-sasaki@ist.osaka-u.ac.jp From: "ALeine" cc: freebsd-hackers@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: FW: Call for comments: CoxR, a CVS/mail-lists/BTS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2005 14:01:05 -0000 k-sasaki@ist.osaka-u.ac.jp wrote: > Thanks for the many feedbacks about CoxR. > We modified the CoxR based on feedback. > And so, please try CoxR function once more. > I would like to have your impressions on the above mentioned information > system as an open source expert > Any feedback including the answer of questions above, comments, suggestions, > etc are always welcome, I took a quick look, but the page does not even display properly due to bad HTML. I suggest you run a HTML validator on the page and clean up the HTML code first: http://validator.w3.org/check?uri=http%3A%2F%2Fscorpion.ics.es.osaka-u.ac.jp%2Fcgi-bin%2FCodeSearch%2Fcoxr.html > Bug Trucking System Oh come, FreeBSD 5.x does have a mutex hell going on, but to say it has so many bugs as to require a truck is absurd. :-> A smaller lorry perhaps, but a truck - definitely not. :-) It might also be a good idea to use an automated spell-check on your pages, I've noticed a number of typos such as "divelopers" and similar. ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 7 14:28:32 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E4ECD16A4CF for ; Mon, 7 Feb 2005 14:28:31 +0000 (GMT) Received: from walk.com.br (mail.walk.com.br [200.205.240.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id D606B43D45 for ; Mon, 7 Feb 2005 14:28:29 +0000 (GMT) (envelope-from luiz@microeletronica.com.br) Received: (qmail 3246 invoked by uid 1006); 7 Feb 2005 14:28:25 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 7 Feb 2005 14:28:25 -0000 Date: Mon, 7 Feb 2005 12:28:25 -0200 (BRDT) From: Luiz Otavio Souza X-X-Sender: luiz@serv-qmp.walk.com.br To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= In-Reply-To: <42071856.5080205@DeepCore.dk> Message-ID: <20050207122355.N1626@serv-qmp.walk.com.br> References: <20050206222416.O88635@serv-qmp.walk.com.br> <42071856.5080205@DeepCore.dk> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1470598922-1107786476=:1626" Content-ID: <20050207122759.F1626@serv-qmp.walk.com.br> cc: freebsd-hackers@freebsd.org Subject: Re: ATA_IDENTIFY timed out on ASUS P4VP-MX X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2005 14:28:32 -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-1470598922-1107786476=:1626 Content-Type: TEXT/PLAIN; CHARSET=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: <20050207122759.S1626@serv-qmp.walk.com.br> On Mon, 7 Feb 2005, [ISO-8859-1] S=F8ren Schmidt wrote: > > Please try the ATA-mkIII patches+tarfile I announced last week on -curren= t=20 > and -stable.. > I tried the patch, and just get a different warning. i'm attaching two dmesg, one with 5.3-RELEASE (with some extra debug info)= =20 and one for ATA-mIII. Thanks, Luiz --0-1470598922-1107786476=:1626 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=dmesg-ATA-mkIII Content-Transfer-Encoding: BASE64 Content-ID: <20050207122825.G1626@serv-qmp.walk.com.br> Content-Description: Content-Disposition: attachment; filename=dmesg-ATA-mkIII U01BUCB0eXBlPTAxIGJhc2U9MDAwMDAwMDAwMDAwMDAwMCBsZW49MDAwMDAw MDAwMDA5ZmMwMA0NClNNQVAgdHlwZT0wMiBiYXNlPTAwMDAwMDAwMDAwOWZj MDAgbGVuPTAwMDAwMDAwMDAwMDA0MDANDQpTTUFQIHR5cGU9MDIgYmFzZT0w MDAwMDAwMDAwMGU4MDAwIGxlbj0wMDAwMDAwMDAwMDE4MDAwDQ0KU01BUCB0 eXBlPTAxIGJhc2U9MDAwMDAwMDAwMDEwMDAwMCBsZW49MDAwMDAwMDAwZjYz MDAwMA0NClNNQVAgdHlwZT0wMyBiYXNlPTAwMDAwMDAwMGY3MzAwMDAgbGVu PTAwMDAwMDAwMDAwMTAwMDANDQpTTUFQIHR5cGU9MDQgYmFzZT0wMDAwMDAw MDBmNzQwMDAwIGxlbj0wMDAwMDAwMDAwMGIwMDAwDQ0KU01BUCB0eXBlPTAy IGJhc2U9MDAwMDAwMDAwZjdmMDAwMCBsZW49MDAwMDAwMDAwMDAxMDAwMA0N ClNNQVAgdHlwZT0wMiBiYXNlPTAwMDAwMDAwZmZiYzAwMDAgbGVuPTAwMDAw MDAwMDA0NDAwMDANDQpDb3B5cmlnaHQgKGMpIDE5OTItMjAwNSBUaGUgRnJl ZUJTRCBQcm9qZWN0Lg0NCkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4 MywgMTk4NiwgMTk4OCwgMTk4OSwgMTk5MSwgMTk5MiwgMTk5MywgMTk5NA0N CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlh LiBBbGwgcmlnaHRzIHJlc2VydmVkLg0NCkZyZWVCU0QgNS4zLVNUQUJMRSAj MjogTW9uIEZlYiAgNyAxMDo1MDowMCBCUlNUIDIwMDUNDQogICAgcm9vdEA6 L3Vzci9vYmovdXNyL3NyYy9zeXMvR0VORVJJQw0NClByZWxvYWRlZCBlbGYg a2VybmVsICIvYm9vdC9rZXJuZWwva2VybmVsIiBhdCAweGMwYTJlMDAwLg0N ClByZWxvYWRlZCBlbGYgbW9kdWxlICIvYm9vdC9rZXJuZWwvYWNwaS5rbyIg YXQgMHhjMGEyZTIyOC4NDQpUYWJsZSAnRkFDUCcgYXQgMHhmNzMwMjAwDQ0K VGFibGUgJ0FQSUMnIGF0IDB4ZjczMDMwMA0NCk1BRFQ6IEZvdW5kIHRhYmxl IGF0IDB4ZjczMDMwMA0NCk1QIENvbmZpZ3VyYXRpb24gVGFibGUgdmVyc2lv biAxLjEgZm91bmQgYXQgMHhjMDBmMGY1MA0NCkFQSUM6IFVzaW5nIHRoZSBN QURUIGVudW1lcmF0b3IuDQ0KTUFEVDogRm91bmQgQ1BVIEFQSUMgSUQgMCBB Q1BJIElEIDE6IGVuYWJsZWQNDQpNQURUOiBGb3VuZCBDUFUgQVBJQyBJRCAx MjkgQUNQSSBJRCAyOiBkaXNhYmxlZA0NCkFDUEkgQVBJQyBUYWJsZTogPEEg TSBJICBPRU1BUElDID4NDQpDYWxpYnJhdGluZyBjbG9jayhzKSAuLi4gaTgy NTQgY2xvY2s6IDExOTMxNTQgSHoNDQpDTEtfVVNFX0k4MjU0X0NBTElCUkFU SU9OIG5vdCBzcGVjaWZpZWQgLSB1c2luZyBkZWZhdWx0IGZyZXF1ZW5jeQ0N ClRpbWVjb3VudGVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMxODIgSHogcXVh bGl0eSAwDQ0KQ2FsaWJyYXRpbmcgVFNDIGNsb2NrIC4uLiBUU0MgY2xvY2s6 IDIyNjQ3NjYyOTkgSHoNDQpDUFU6IEludGVsKFIpIENlbGVyb24oUikgQ1BV IDIuMjZHSHogKDIyNjQuNzctTUh6IDY4Ni1jbGFzcyBDUFUpDQ0KICBPcmln aW4gPSAiR2VudWluZUludGVsIiAgSWQgPSAweGYzMyAgU3RlcHBpbmcgPSAz DQ0KICBGZWF0dXJlcz0weGJmZWJmYmZmPEZQVSxWTUUsREUsUFNFLFRTQyxN U1IsUEFFLE1DRSxDWDgsQVBJQyxTRVAsTVRSUixQR0UsTUNBLENNT1YsUEFU LFBTRTM2LENMRkxVU0gsRFRTLEFDUEksTU1YLEZYU1IsU1NFLFNTRTIsU1Ms SFRULFRNLFBCRT4NDQpyZWFsIG1lbW9yeSAgPSAyNTkxOTQ4ODAgKDI0NyBN QikNDQpQaHlzaWNhbCBtZW1vcnkgY2h1bmsocyk6DQ0KMHgwMDAwMDAwMDAw MDAxMDAwIC0gMHgwMDAwMDAwMDAwMDllZmZmLCA2NDcxNjggYnl0ZXMgKDE1 OCBwYWdlcykNDQoweDAwMDAwMDAwMDAxMDAwMDAgLSAweDAwMDAwMDAwMDAz ZmZmZmYsIDMxNDU3MjggYnl0ZXMgKDc2OCBwYWdlcykNDQoweDAwMDAwMDAw MDBjMjUwMDAgLSAweDAwMDAwMDAwMGYyYTZmZmYsIDI0MTcwNDk2MCBieXRl cyAoNTkwMTAgcGFnZXMpDQ0KYXZhaWwgbWVtb3J5ID0gMjQ0MDgwNjQwICgy MzIgTUIpDQ0KYmlvczMyOiBGb3VuZCBCSU9TMzIgU2VydmljZSBEaXJlY3Rv cnkgaGVhZGVyIGF0IDB4YzAwZjAwMDANDQpiaW9zMzI6IEVudHJ5ID0gMHhm MDAxMCAoYzAwZjAwMTApICBSZXYgPSAwICBMZW4gPSAxDQ0KcGNpYmlvczog UENJIEJJT1MgZW50cnkgYXQgMHhmMDAwMCsweDMxDQ0KcG5wYmlvczogRm91 bmQgUG5QIEJJT1MgZGF0YSBhdCAweGMwMGY2MDYwDQ0KcG5wYmlvczogRW50 cnkgPSBmMDAwMDo2Y2JhICBSZXYgPSAxLjANDQpPdGhlciBCSU9TIHNpZ25h dHVyZXMgZm91bmQ6DQ0KQVBJQzogQ1BVIDAgaGFzIEFDUEkgSUQgMQ0NCk1B RFQ6IEZvdW5kIElPIEFQSUMgSUQgMSwgSW50ZXJydXB0IDAgYXQgMHhmZWMw MDAwMA0NCmlvYXBpYzA6IFJvdXRpbmcgZXh0ZXJuYWwgODI1OUEncyAtPiBp bnRwaW4gMA0NCmlvYXBpYzA6IGludHBpbiAwIC0+IEV4dElOVCAoZWRnZSwg aGlnaCkNDQppb2FwaWMwOiBpbnRwaW4gMSAtPiBJU0EgSVJRIDEgKGVkZ2Us IGhpZ2gpDQ0KaW9hcGljMDogaW50cGluIDIgLT4gSVNBIElSUSAyIChlZGdl LCBoaWdoKQ0NCmlvYXBpYzA6IGludHBpbiAzIC0+IElTQSBJUlEgMyAoZWRn ZSwgaGlnaCkNDQppb2FwaWMwOiBpbnRwaW4gNCAtPiBJU0EgSVJRIDQgKGVk Z2UsIGhpZ2gpDQ0KaW9hcGljMDogaW50cGluIDUgLT4gSVNBIElSUSA1IChl ZGdlLCBoaWdoKQ0NCmlvYXBpYzA6IGludHBpbiA2IC0+IElTQSBJUlEgNiAo ZWRnZSwgaGlnaCkNDQppb2FwaWMwOiBpbnRwaW4gNyAtPiBJU0EgSVJRIDcg KGVkZ2UsIGhpZ2gpDQ0KaW9hcGljMDogaW50cGluIDggLT4gSVNBIElSUSA4 IChlZGdlLCBoaWdoKQ0NCmlvYXBpYzA6IGludHBpbiA5IC0+IElTQSBJUlEg OSAoZWRnZSwgaGlnaCkNDQppb2FwaWMwOiBpbnRwaW4gMTAgLT4gSVNBIElS USAxMCAoZWRnZSwgaGlnaCkNDQppb2FwaWMwOiBpbnRwaW4gMTEgLT4gSVNB IElSUSAxMSAoZWRnZSwgaGlnaCkNDQppb2FwaWMwOiBpbnRwaW4gMTIgLT4g SVNBIElSUSAxMiAoZWRnZSwgaGlnaCkNDQppb2FwaWMwOiBpbnRwaW4gMTMg LT4gSVNBIElSUSAxMyAoZWRnZSwgaGlnaCkNDQppb2FwaWMwOiBpbnRwaW4g MTQgLT4gSVNBIElSUSAxNCAoZWRnZSwgaGlnaCkNDQppb2FwaWMwOiBpbnRw aW4gMTUgLT4gSVNBIElSUSAxNSAoZWRnZSwgaGlnaCkNDQppb2FwaWMwOiBp bnRwaW4gMTYgLT4gUENJIElSUSAxNiAobGV2ZWwsIGxvdykNDQppb2FwaWMw OiBpbnRwaW4gMTcgLT4gUENJIElSUSAxNyAobGV2ZWwsIGxvdykNDQppb2Fw aWMwOiBpbnRwaW4gMTggLT4gUENJIElSUSAxOCAobGV2ZWwsIGxvdykNDQpp b2FwaWMwOiBpbnRwaW4gMTkgLT4gUENJIElSUSAxOSAobGV2ZWwsIGxvdykN DQppb2FwaWMwOiBpbnRwaW4gMjAgLT4gUENJIElSUSAyMCAobGV2ZWwsIGxv dykNDQppb2FwaWMwOiBpbnRwaW4gMjEgLT4gUENJIElSUSAyMSAobGV2ZWws IGxvdykNDQppb2FwaWMwOiBpbnRwaW4gMjIgLT4gUENJIElSUSAyMiAobGV2 ZWwsIGxvdykNDQppb2FwaWMwOiBpbnRwaW4gMjMgLT4gUENJIElSUSAyMyAo bGV2ZWwsIGxvdykNDQpNQURUOiBpbnRyIG92ZXJyaWRlOiBzb3VyY2UgMCwg aXJxIDINDQppb2FwaWMwOiBSb3V0aW5nIElSUSAwIC0+IGludHBpbiAyDQ0K aW9hcGljMDogaW50cGluIDIgdHJpZ2dlcjogZWRnZQ0NCmlvYXBpYzA6IGlu dHBpbiAyIHBvbGFyaXR5OiBoaWdoDQ0KTUFEVDogRm9yY2luZyBhY3RpdmUt bG93IHBvbGFyaXR5IGFuZCBsZXZlbCB0cmlnZ2VyIGZvciBTQ0kNDQppb2Fw aWMwOiBpbnRwaW4gOSBwb2xhcml0eTogbG93DQ0KaW9hcGljMDogaW50cGlu IDkgdHJpZ2dlcjogbGV2ZWwNDQppb2FwaWMwIDxWZXJzaW9uIDAuMz4gaXJx cyAwLTIzIG9uIG1vdGhlcmJvYXJkDQ0KY3B1MCBCU1A6DQ0KICAgICBJRDog MHgwMDAwMDAwMCAgIFZFUjogMHgwMDA1MDAxNCBMRFI6IDB4MDEwMDAwMDAg REZSOiAweDBmZmZmZmZmDQ0KICBsaW50MDogMHgwMDAxMDcwMCBsaW50MTog MHgwMDAwMDQwMCBUUFI6IDB4MDAwMDAwMDAgU1ZSOiAweDAwMDAwMWZmDQ0K d2xhbjogPDgwMi4xMSBMaW5rIExheWVyPg0NCm51bGw6IDxudWxsIGRldmlj ZSwgemVybyBkZXZpY2U+DQ0KcmFuZG9tOiA8ZW50cm9weSBzb3VyY2UsIFNv ZnR3YXJlLCBZYXJyb3c+DQ0KaW86IDxJL08+DQ0KbWVtOiA8bWVtb3J5Pg0N ClBlbnRpdW0gUHJvIE1UUlIgc3VwcG9ydCBlbmFibGVkDQ0KbnB4MDogW0ZB U1RdDQ0KbnB4MDogPG1hdGggcHJvY2Vzc29yPiBvbiBtb3RoZXJib2FyZA0N Cm5weDA6IElOVCAxNiBpbnRlcmZhY2UNDQphY3BpMDogPEEgTSBJIE9FTVhT RFQ+IG9uIG1vdGhlcmJvYXJkDQ0KYWNwaTA6IFtNUFNBRkVdDQ0KcGNpX29w ZW4oMSk6CW1vZGUgMSBhZGRyIHBvcnQgKDB4MGNmOCkgaXMgMHg4MDAwMDA2 MA0NCnBjaV9vcGVuKDFhKToJbW9kZTFyZXM9MHg4MDAwMDAwMCAoMHg4MDAw MDAwMCkNDQpwY2lfY2ZnY2hlY2s6CWRldmljZSAwIFtjbGFzcz0wNjAwMDBd IFtoZHI9MDBdIGlzIHRoZXJlIChpZD0zMTQ4MTEwNikNDQpwY2liaW9zOiBC SU9TIHZlcnNpb24gMi4xMA0NCkZvdW5kICRQSVIgdGFibGUsIDcgZW50cmll cyBhdCAweGMwMGY1ZjYwDQ0KUENJLU9ubHkgSW50ZXJydXB0czogbm9uZQ0N CkxvY2F0aW9uICBCdXMgRGV2aWNlIFBpbiAgTGluayAgSVJRcw0NCmVtYmVk ZGVkICAgIDAgICAxNyAgICBDICAgMHgwMyAgMyA0IDUgNyAxMCAxMSAxNCAx NQ0NCmVtYmVkZGVkICAgIDAgICAxOCAgICBBICAgMHgwMSAgMyA0IDUgNyAx MCAxMSAxNCAxNQ0NCmVtYmVkZGVkICAgIDAgICAgMSAgICBBICAgMHgwMSAg MyA0IDUgNyAxMCAxMSAxNCAxNQ0NCmVtYmVkZGVkICAgIDAgICAgMSAgICBC ICAgMHgwMiAgMyA0IDUgNyAxMCAxMSAxNCAxNQ0NCnNsb3QgMSAgICAgIDAg ICAgOSAgICBBICAgMHgwMiAgMyA0IDUgNyAxMCAxMSAxNCAxNQ0NCnNsb3Qg MSAgICAgIDAgICAgOSAgICBCICAgMHgwMyAgMyA0IDUgNyAxMCAxMSAxNCAx NQ0NCnNsb3QgMSAgICAgIDAgICAgOSAgICBDICAgMHgwNSAgMyA0IDUgNyAx MCAxMSAxNCAxNQ0NCnNsb3QgMSAgICAgIDAgICAgOSAgICBEICAgMHgwMSAg MyA0IDUgNyAxMCAxMSAxNCAxNQ0NCnNsb3QgMiAgICAgIDAgICAxMCAgICBB ICAgMHgwMyAgMyA0IDUgNyAxMCAxMSAxNCAxNQ0NCnNsb3QgMiAgICAgIDAg ICAxMCAgICBCICAgMHgwNSAgMyA0IDUgNyAxMCAxMSAxNCAxNQ0NCnNsb3Qg MiAgICAgIDAgICAxMCAgICBDICAgMHgwMSAgMyA0IDUgNyAxMCAxMSAxNCAx NQ0NCnNsb3QgMiAgICAgIDAgICAxMCAgICBEICAgMHgwMiAgMyA0IDUgNyAx MCAxMSAxNCAxNQ0NCnNsb3QgMyAgICAgIDAgICAxMSAgICBBICAgMHgwNSAg MyA0IDUgNyAxMCAxMSAxNCAxNQ0NCnNsb3QgMyAgICAgIDAgICAxMSAgICBC ICAgMHgwMSAgMyA0IDUgNyAxMCAxMSAxNCAxNQ0NCnNsb3QgMyAgICAgIDAg ICAxMSAgICBDICAgMHgwMiAgMyA0IDUgNyAxMCAxMSAxNCAxNQ0NCnNsb3Qg MyAgICAgIDAgICAxMSAgICBEICAgMHgwMyAgMyA0IDUgNyAxMCAxMSAxNCAx NQ0NCmVtYmVkZGVkICAgIDAgICAxNiAgICBBICAgMHgwMSAgMyA0IDUgNyAx MCAxMSAxNCAxNQ0NCmVtYmVkZGVkICAgIDAgICAxNiAgICBCICAgMHgwMiAg MyA0IDUgNyAxMCAxMSAxNCAxNQ0NCmVtYmVkZGVkICAgIDAgICAxNiAgICBD ICAgMHgwMyAgMyA0IDUgNyAxMCAxMSAxNCAxNQ0NCmVtYmVkZGVkICAgIDAg ICAxNiAgICBEICAgMHgwNSAgMyA0IDUgNyAxMCAxMSAxNCAxNQ0NCkFjcGlP c0Rlcml2ZVBjaUlkOiBidXMgMCBkZXYgMTcgZnVuYyAwDQ0KYWNwaTA6IFBv d2VyIEJ1dHRvbiAoZml4ZWQpDQ0KQUNQSSB0aW1lcjogMC8zIDAvNiAxLzIg MS8yIDEvMiAwLzQgMC80IDAvMyAxLzIgMS8yIC0+IDUNDQpUaW1lY291bnRl ciAiQUNQSS1zYWZlIiBmcmVxdWVuY3kgMzU3OTU0NSBIeiBxdWFsaXR5IDEw MDANDQphY3BpX3RpbWVyMDogPDI0LWJpdCB0aW1lciBhdCAzLjU3OTU0NU1I ej4gcG9ydCAweDgwOC0weDgwYiBvbiBhY3BpMA0NCmNwdTA6IDxBQ1BJIENQ VT4gb24gYWNwaTANDQpwY2liMDogPEFDUEkgSG9zdC1QQ0kgYnJpZGdlPiBw b3J0IDB4Y2Y4LTB4Y2ZmIG9uIGFjcGkwDQ0KQUNQSSBQQ0kgbGluayBpbml0 aWFsIGNvbmZpZ3VyYXRpb246DQ0KcGNpMDogPEFDUEkgUENJIGJ1cz4gb24g cGNpYjANDQpwY2kwOiBwaHlzaWNhbCBidXM9MA0NCgltYXBbMTBdOiB0eXBl IDMsIHJhbmdlIDMyLCBiYXNlIGUwMDAwMDAwLCBzaXplIDIyLCBlbmFibGVk DQ0KZm91bmQtPgl2ZW5kb3I9MHgxMTA2LCBkZXY9MHgzMTQ4LCByZXZpZD0w eDAwDQ0KCWJ1cz0wLCBzbG90PTAsIGZ1bmM9MA0NCgljbGFzcz0wNi0wMC0w MCwgaGRydHlwZT0weDAwLCBtZmRldj0wDQ0KCWNtZHJlZz0weDAwMDYsIHN0 YXRyZWc9MHgyMjMwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQ0NCglsYXR0aW1l cj0weDA4ICgyNDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0w eDAwICgwIG5zKQ0NCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1 cnJlbnQgRDANDQpmb3VuZC0+CXZlbmRvcj0weDExMDYsIGRldj0weGIwOTEs IHJldmlkPTB4MDANDQoJYnVzPTAsIHNsb3Q9MSwgZnVuYz0wDQ0KCWNsYXNz PTA2LTA0LTAwLCBoZHJ0eXBlPTB4MDEsIG1mZGV2PTANDQoJY21kcmVnPTB4 MDEwNywgc3RhdHJlZz0weGEyMzAsIGNhY2hlbG5zej0wIChkd29yZHMpDQ0K CWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwYyAoMzAwMCBucyks IG1heGxhdD0weDAwICgwIG5zKQ0NCgltYXBbMjBdOiB0eXBlIDQsIHJhbmdl IDMyLCBiYXNlIDAwMDBlNDAwLCBzaXplICA1LCBlbmFibGVkDQ0KcGNpYjA6 IG1hdGNoZWQgZW50cnkgZm9yIDAuMTYuSU5UQQ0NCnBjaWIwOiBzbG90IDE2 IElOVEEgaGFyZHdpcmVkIHRvIElSUSAyMQ0NCmZvdW5kLT4JdmVuZG9yPTB4 MTEwNiwgZGV2PTB4MzAzOCwgcmV2aWQ9MHg4MA0NCglidXM9MCwgc2xvdD0x NiwgZnVuYz0wDQ0KCWNsYXNzPTBjLTAzLTAwLCBoZHJ0eXBlPTB4MDAsIG1m ZGV2PTENDQoJY21kcmVnPTB4MDAxNywgc3RhdHJlZz0weDAyMTAsIGNhY2hl bG5zej04IChkd29yZHMpDQ0KCWxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBt aW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQ0NCglpbnRw aW49YSwgaXJxPTIxDQ0KCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMSBE MiBEMyAgY3VycmVudCBEMA0NCgltYXBbMjBdOiB0eXBlIDQsIHJhbmdlIDMy LCBiYXNlIDAwMDBlNDgwLCBzaXplICA1LCBlbmFibGVkDQ0KcGNpYjA6IG1h dGNoZWQgZW50cnkgZm9yIDAuMTYuSU5UQg0NCnBjaWIwOiBzbG90IDE2IElO VEIgaGFyZHdpcmVkIHRvIElSUSAyMQ0NCmZvdW5kLT4JdmVuZG9yPTB4MTEw NiwgZGV2PTB4MzAzOCwgcmV2aWQ9MHg4MA0NCglidXM9MCwgc2xvdD0xNiwg ZnVuYz0xDQ0KCWNsYXNzPTBjLTAzLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2 PTENDQoJY21kcmVnPTB4MDAxNywgc3RhdHJlZz0weDAyMTAsIGNhY2hlbG5z ej04IChkd29yZHMpDQ0KCWxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5n bnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQ0NCglpbnRwaW49 YiwgaXJxPTIxDQ0KCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMSBEMiBE MyAgY3VycmVudCBEMA0NCgltYXBbMjBdOiB0eXBlIDQsIHJhbmdlIDMyLCBi YXNlIDAwMDBlYzAwLCBzaXplICA1LCBlbmFibGVkDQ0KcGNpYjA6IG1hdGNo ZWQgZW50cnkgZm9yIDAuMTYuSU5UQw0NCnBjaWIwOiBzbG90IDE2IElOVEMg aGFyZHdpcmVkIHRvIElSUSAyMQ0NCmZvdW5kLT4JdmVuZG9yPTB4MTEwNiwg ZGV2PTB4MzAzOCwgcmV2aWQ9MHg4MA0NCglidXM9MCwgc2xvdD0xNiwgZnVu Yz0yDQ0KCWNsYXNzPTBjLTAzLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEN DQoJY21kcmVnPTB4MDAxNywgc3RhdHJlZz0weDAyMTAsIGNhY2hlbG5zej04 IChkd29yZHMpDQ0KCWxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5nbnQ9 MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQ0NCglpbnRwaW49Yywg aXJxPTIxDQ0KCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAg Y3VycmVudCBEMA0NCmZvdW5kLT4JdmVuZG9yPTB4MTEwNiwgZGV2PTB4MzE3 NywgcmV2aWQ9MHgwMA0NCglidXM9MCwgc2xvdD0xNywgZnVuYz0wDQ0KCWNs YXNzPTA2LTAxLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTENDQoJY21kcmVn PTB4MDA4Nywgc3RhdHJlZz0weDAyMTAsIGNhY2hlbG5zej0wIChkd29yZHMp DQ0KCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyks IG1heGxhdD0weDAwICgwIG5zKQ0NCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMg RDAgRDMgIGN1cnJlbnQgRDANDQoJbWFwWzIwXTogdHlwZSA0LCByYW5nZSAz MiwgYmFzZSAwMDAwZmMwMCwgc2l6ZSAgNCwgZW5hYmxlZA0NCmZvdW5kLT4J dmVuZG9yPTB4MTEwNiwgZGV2PTB4MDU3MSwgcmV2aWQ9MHgwNg0NCglidXM9 MCwgc2xvdD0xNywgZnVuYz0xDQ0KCWNsYXNzPTAxLTAxLThhLCBoZHJ0eXBl PTB4MDAsIG1mZGV2PTANDQoJY21kcmVnPTB4MDAwNywgc3RhdHJlZz0weDAy OTAsIGNhY2hlbG5zej0wIChkd29yZHMpDQ0KCWxhdHRpbWVyPTB4MjAgKDk2 MCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMp DQ0KCWludHBpbj1hLCBpcnE9MjU1DQ0KCXBvd2Vyc3BlYyAyICBzdXBwb3J0 cyBEMCBEMyAgY3VycmVudCBEMA0NCgltYXBbMTBdOiB0eXBlIDQsIHJhbmdl IDMyLCBiYXNlIDAwMDBlODAwLCBzaXplICA4LCBlbmFibGVkDQ0KCW1hcFsx NF06IHR5cGUgMSwgcmFuZ2UgMzIsIGJhc2UgZmZhZmZjMDAsIHNpemUgIDgs IGVuYWJsZWQNDQpwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4xOC5JTlRB DQ0KcGNpYjA6IHNsb3QgMTggSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDIzDQ0K Zm91bmQtPgl2ZW5kb3I9MHgxMTA2LCBkZXY9MHgzMDY1LCByZXZpZD0weDc0 DQ0KCWJ1cz0wLCBzbG90PTE4LCBmdW5jPTANDQoJY2xhc3M9MDItMDAtMDAs IGhkcnR5cGU9MHgwMCwgbWZkZXY9MA0NCgljbWRyZWc9MHgwMTE3LCBzdGF0 cmVnPTB4MDIxMCwgY2FjaGVsbnN6PTggKGR3b3JkcykNDQoJbGF0dGltZXI9 MHg0MCAoMTkyMCBucyksIG1pbmdudD0weDAzICg3NTAgbnMpLCBtYXhsYXQ9 MHgwOCAoMjAwMCBucykNDQoJaW50cGluPWEsIGlycT0yMw0NCglwb3dlcnNw ZWMgMiAgc3VwcG9ydHMgRDAgRDEgRDIgRDMgIGN1cnJlbnQgRDANDQphZ3Aw OiA8VklBIEdlbmVyaWMgaG9zdCB0byBQQ0kgYnJpZGdlPiBtZW0gMHhlMDAw MDAwMC0weGUwM2ZmZmZmIGF0IGRldmljZSAwLjAgb24gcGNpMA0NCmFncDA6 IFJlc2VydmVkIDB4NDAwMDAwIGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDMg YXQgMHhlMDAwMDAwMA0NCmFncDA6IGFsbG9jYXRpbmcgR0FUVCBmb3IgYXBl cnR1cmUgb2Ygc2l6ZSAyMjhNDQ0KcGNpYjE6IDxBQ1BJIFBDSS1QQ0kgYnJp ZGdlPiBhdCBkZXZpY2UgMS4wIG9uIHBjaTANDQpwY2liMTogICBzZWNvbmRh cnkgYnVzICAgICAxDQ0KcGNpYjE6ICAgc3Vib3JkaW5hdGUgYnVzICAgMQ0N CnBjaWIxOiAgIEkvTyBkZWNvZGUgICAgICAgIDB4ZjAwMC0weGZmZg0NCnBj aWIxOiAgIG1lbW9yeSBkZWNvZGUgICAgIDB4ZmY4MDAwMDAtMHhmZjlmZmZm Zg0NCnBjaWIxOiAgIHByZWZldGNoZWQgZGVjb2RlIDB4Y2ZmMDAwMDAtMHhk ZmVmZmZmZg0NCnBjaWIxOiBjb3VsZCBub3QgZ2V0IFBDSSBpbnRlcnJ1cHQg cm91dGluZyB0YWJsZSBmb3IgXF9TQl8uUENJMC5QMFAxIC0gQUVfTk9UX0ZP VU5EDQ0KcGNpMTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjENDQpwY2kxOiBw aHlzaWNhbCBidXM9MQ0NCgltYXBbMTBdOiB0eXBlIDEsIHJhbmdlIDMyLCBi YXNlIGZmOTgwMDAwLCBzaXplIDE5LCBlbmFibGVkDQ0KcGNpYjE6IGRldmlj ZSAobnVsbCkgcmVxdWVzdGVkIGRlY29kZWQgbWVtb3J5IHJhbmdlIDB4ZmY5 ODAwMDAtMHhmZjlmZmZmZg0NCgltYXBbMTRdOiB0eXBlIDMsIHJhbmdlIDMy LCBiYXNlIGQwMDAwMDAwLCBzaXplIDI3LCBlbmFibGVkDQ0KcGNpYjE6IGRl dmljZSAobnVsbCkgcmVxdWVzdGVkIGRlY29kZWQgbWVtb3J5IHJhbmdlIDB4 ZDAwMDAwMDAtMHhkN2ZmZmZmZg0NCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZv ciAwLjEuSU5UQQ0NCnBjaWIwOiBzbG90IDEgSU5UQSBoYXJkd2lyZWQgdG8g SVJRIDE2DQ0KcGNpYjE6IHNsb3QgMCBJTlRBIGlzIHJvdXRlZCB0byBpcnEg MTYNDQpmb3VuZC0+CXZlbmRvcj0weDUzMzMsIGRldj0weDhkMDQsIHJldmlk PTB4MDANDQoJYnVzPTEsIHNsb3Q9MCwgZnVuYz0wDQ0KCWNsYXNzPTAzLTAw LTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTANDQoJY21kcmVnPTB4MDAwNywg c3RhdHJlZz0weDAyMzAsIGNhY2hlbG5zej04IChkd29yZHMpDQ0KCWxhdHRp bWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5nbnQ9MHgwNCAoMTAwMCBucyksIG1h eGxhdD0weGZmICg2Mzc1MCBucykNDQoJaW50cGluPWEsIGlycT0xNg0NCglw b3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDEgRDIgRDMgIGN1cnJlbnQgRDAN DQpwY2kxOiA8ZGlzcGxheSwgVkdBPiBhdCBkZXZpY2UgMC4wIChubyBkcml2 ZXIgYXR0YWNoZWQpDQ0KdWhjaTA6IDxWSUEgODNDNTcyIFVTQiBjb250cm9s bGVyPiBwb3J0IDB4ZTQwMC0weGU0MWYgaXJxIDIxIGF0IGRldmljZSAxNi4w IG9uIHBjaTANDQp1aGNpMDogUmVzZXJ2ZWQgMHgyMCBieXRlcyBmb3Igcmlk IDB4MjAgdHlwZSA0IGF0IDB4ZTQwMA0NCnVoY2kwOiBbR0lBTlQtTE9DS0VE XQ0NCnVzYjA6IDxWSUEgODNDNTcyIFVTQiBjb250cm9sbGVyPiBvbiB1aGNp MA0NCnVzYjA6IFVTQiByZXZpc2lvbiAxLjANDQp1aHViMDogVklBIFVIQ0kg cm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxDQ0K dWh1YjA6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVk DQ0KdWhjaTE6IDxWSUEgODNDNTcyIFVTQiBjb250cm9sbGVyPiBwb3J0IDB4 ZTQ4MC0weGU0OWYgaXJxIDIxIGF0IGRldmljZSAxNi4xIG9uIHBjaTANDQp1 aGNpMTogUmVzZXJ2ZWQgMHgyMCBieXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0 IGF0IDB4ZTQ4MA0NCnVoY2kxOiBbR0lBTlQtTE9DS0VEXQ0NCnVzYjE6IDxW SUEgODNDNTcyIFVTQiBjb250cm9sbGVyPiBvbiB1aGNpMQ0NCnVzYjE6IFVT QiByZXZpc2lvbiAxLjANDQp1aHViMTogVklBIFVIQ0kgcm9vdCBodWIsIGNs YXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxDQ0KdWh1YjE6IDIgcG9y dHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkDQ0KdWhjaTI6IDxW SUEgODNDNTcyIFVTQiBjb250cm9sbGVyPiBwb3J0IDB4ZWMwMC0weGVjMWYg aXJxIDIxIGF0IGRldmljZSAxNi4yIG9uIHBjaTANDQp1aGNpMjogUmVzZXJ2 ZWQgMHgyMCBieXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0IGF0IDB4ZWMwMA0N CnVoY2kyOiBbR0lBTlQtTE9DS0VEXQ0NCnVzYjI6IDxWSUEgODNDNTcyIFVT QiBjb250cm9sbGVyPiBvbiB1aGNpMg0NCnVzYjI6IFVTQiByZXZpc2lvbiAx LjANDQp1aHViMjogVklBIFVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2 IDEuMDAvMS4wMCwgYWRkciAxDQ0KdWh1YjI6IDIgcG9ydHMgd2l0aCAyIHJl bW92YWJsZSwgc2VsZiBwb3dlcmVkDQ0KaXNhYjA6IDxQQ0ktSVNBIGJyaWRn ZT4gYXQgZGV2aWNlIDE3LjAgb24gcGNpMA0NCmlzYTA6IDxJU0EgYnVzPiBv biBpc2FiMA0NCmF0YXBjaTA6IDxWSUEgODIzNSBVRE1BMTMzIGNvbnRyb2xs ZXI+IHBvcnQgMHhmYzAwLTB4ZmMwZiwweDM3NiwweDE3MC0weDE3NywweDNm NiwweDFmMC0weDFmNyBhdCBkZXZpY2UgMTcuMSBvbiBwY2kwDQ0KYXRhcGNp MDogUmVzZXJ2ZWQgMHgxMCBieXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0IGF0 IDB4ZmMwMA0NCmF0YTA6IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFwY2kwDQ0K YXRhcGNpMDogUmVzZXJ2ZWQgMHg4IGJ5dGVzIGZvciByaWQgMHgxMCB0eXBl IDQgYXQgMHgxZjANDQphdGFwY2kwOiBSZXNlcnZlZCAweDEgYnl0ZXMgZm9y IHJpZCAweDE0IHR5cGUgNCBhdCAweDNmNg0NCmF0YTA6IHJlc2V0IHRwMSBt YXNrPTAzIG9zdGF0MD01MCBvc3RhdDE9MDANDQphdGEwOiBzdGF0MD0weDUw IGVycj0weDAxIGxzYj0weDAwIG1zYj0weDAwDQ0KYXRhMDogc3RhdDE9MHgw MCBlcnI9MHgwMSBsc2I9MHgwMCBtc2I9MHgwMA0NCmF0YTA6IHJlc2V0IHRw MiBzdGF0MD01MCBzdGF0MT0wMCBkZXZpY2VzPTB4MTxBVEFfTUFTVEVSPg0N CmF0YTA6IFtNUFNBRkVdDQ0KYXRhMTogPEFUQSBjaGFubmVsIDE+IG9uIGF0 YXBjaTANDQphdGFwY2kwOiBSZXNlcnZlZCAweDggYnl0ZXMgZm9yIHJpZCAw eDE4IHR5cGUgNCBhdCAweDE3MA0NCmF0YXBjaTA6IFJlc2VydmVkIDB4MSBi eXRlcyBmb3IgcmlkIDB4MWMgdHlwZSA0IGF0IDB4Mzc2DQ0KYXRhMTogcmVz ZXQgdHAxIG1hc2s9MDMgb3N0YXQwPTYwIG9zdGF0MT03MA0NCmF0YTE6IHN0 YXQwPTB4MjAgZXJyPTB4MjAgbHNiPTB4MjAgbXNiPTB4MjANDQphdGExOiBz dGF0MT0weDMwIGVycj0weDMwIGxzYj0weDMwIG1zYj0weDMwDQ0KYXRhMTog cmVzZXQgdHAyIHN0YXQwPTIwIHN0YXQxPTMwIGRldmljZXM9MHgwDQ0KYXRh MTogW01QU0FGRV0NDQp2cjA6IDxWSUEgVlQ2MTAyIFJoaW5lIElJIDEwLzEw MEJhc2VUWD4gcG9ydCAweGU4MDAtMHhlOGZmIG1lbSAweGZmYWZmYzAwLTB4 ZmZhZmZjZmYgaXJxIDIzIGF0IGRldmljZSAxOC4wIG9uIHBjaTANDQp2cjA6 IFJlc2VydmVkIDB4MTAwIGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDQgYXQg MHhlODAwDQ0KbWlpYnVzMDogPE1JSSBidXM+IG9uIHZyMA0NCnVrcGh5MDog PEdlbmVyaWMgSUVFRSA4MDIuM3UgbWVkaWEgaW50ZXJmYWNlPiBvbiBtaWli dXMwDQ0KdWtwaHkwOiBPVUkgMHgwMDQwNjMsIG1vZGVsIDB4MDAzMiwgcmV2 LiAxMA0NCnVrcGh5MDogIDEwYmFzZVQsIDEwYmFzZVQtRkRYLCAxMDBiYXNl VFgsIDEwMGJhc2VUWC1GRFgsIGF1dG8NDQp2cjA6IGJwZiBhdHRhY2hlZA0N CnZyMDogRXRoZXJuZXQgYWRkcmVzczogMDA6MTE6MmY6ZGM6Zjc6ZWQNDQp2 cjA6IFtNUFNBRkVdDQ0KYWNwaV9idXR0b24wOiA8UG93ZXIgQnV0dG9uPiBv biBhY3BpMA0NCmFjcGlfYnV0dG9uMTogPFNsZWVwIEJ1dHRvbj4gb24gYWNw aTANDQpzaW8wOiBjb25maWd1cmVkIGlycSA0IG5vdCBpbiBiaXRtYXAgb2Yg cHJvYmVkIGlycXMgMA0NCnNpbzA6IHBvcnQgbWF5IG5vdCBiZSBlbmFibGVk DQ0Kc2lvMDogaXJxIG1hcHM6IDAgMCAwIDANDQpzaW8wOiA8MTY1NTBBLWNv bXBhdGlibGUgQ09NIHBvcnQ+IHBvcnQgMHgzZjgtMHgzZmYgaXJxIDQgZmxh Z3MgMHgxMCBvbiBhY3BpMA0NCnNpbzA6IHR5cGUgMTY1NTBBLCBjb25zb2xl DQ0KZmRjMDogPGZsb3BweSBkcml2ZSBjb250cm9sbGVyIChGREUpPiBwb3J0 IDB4M2Y3LDB4M2YwLTB4M2Y1IGlycSA2IGRycSAyIG9uIGFjcGkwDQ0KZmRj MDogZG9lcyBub3QgcmVzcG9uZA0NCmRldmljZV9hdHRhY2g6IGZkYzAgYXR0 YWNoIHJldHVybmVkIDYNDQp1bmtub3duOiBub3QgcHJvYmVkIChkaXNhYmxl ZCkNDQp1bmtub3duOiBub3QgcHJvYmVkIChkaXNhYmxlZCkNDQp1bmtub3du OiBub3QgcHJvYmVkIChkaXNhYmxlZCkNDQphdGtiZGMwOiA8S2V5Ym9hcmQg Y29udHJvbGxlciAoaTgwNDIpPiBwb3J0IDB4NjQsMHg2MCBpcnEgMSBvbiBh Y3BpMA0NCmF0a2JkMDogPEFUIEtleWJvYXJkPiBpcnEgMSBvbiBhdGtiZGMw DQ0Ka2JkMCBhdCBhdGtiZDANDQprYmQwOiBhdGtiZDAsIGdlbmVyaWMgKDAp LCBjb25maWc6MHgwLCBmbGFnczoweDFmMDAwMA0NCmF0a2JkMDogW0dJQU5U LUxPQ0tFRF0NDQpwc20wOiB1bmFibGUgdG8gYWxsb2NhdGUgSVJRDQ0KdW5r bm93bjogbm90IHByb2JlZCAoZGlzYWJsZWQpDQ0KZmRjMDogPGZsb3BweSBk cml2ZSBjb250cm9sbGVyIChGREUpPiBwb3J0IDB4M2Y3LDB4M2YwLTB4M2Y1 IGlycSA2IGRycSAyIG9uIGFjcGkwDQ0KZmRjMDogZG9lcyBub3QgcmVzcG9u ZA0NCmRldmljZV9hdHRhY2g6IGZkYzAgYXR0YWNoIHJldHVybmVkIDYNDQp1 bmtub3duOiBub3QgcHJvYmVkIChkaXNhYmxlZCkNDQp1bmtub3duOiBub3Qg cHJvYmVkIChkaXNhYmxlZCkNDQp1bmtub3duOiBub3QgcHJvYmVkIChkaXNh YmxlZCkNDQp1bmtub3duOiBub3QgcHJvYmVkIChkaXNhYmxlZCkNDQphaGNf aXNhX3Byb2JlIDE0OiBpb3BvcnQgMHhlYzAwIGFsbG9jIGZhaWxlZA0NCmF0 YTogYXRhMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQNDQphdGE6IGF0 YTEgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0DQ0KYXRrYmRjOiBhdGti ZGMwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdA0NCmZkYzogZmRjMCBh bHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQNDQpzaW86IHNpbzAgYWxyZWFk eSBleGlzdHM7IHNraXBwaW5nIGl0DQ0KVHJ5aW5nIFJlYWRfUG9ydCBhdCAy MDMNDQpUcnlpbmcgUmVhZF9Qb3J0IGF0IDI0Mw0NClRyeWluZyBSZWFkX1Bv cnQgYXQgMjgzDQ0KVHJ5aW5nIFJlYWRfUG9ydCBhdCAyYzMNDQpUcnlpbmcg UmVhZF9Qb3J0IGF0IDMwMw0NClRyeWluZyBSZWFkX1BvcnQgYXQgMzQzDQ0K VHJ5aW5nIFJlYWRfUG9ydCBhdCAzODMNDQpUcnlpbmcgUmVhZF9Qb3J0IGF0 IDNjMw0NCmV4X2lzYV9pZGVudGlmeSgpDQ0KdW5rbm93bjogc3RhdHVzIHJl ZyB0ZXN0IGZhaWxlZCBmZg0NCnVua25vd246IHN0YXR1cyByZWcgdGVzdCBm YWlsZWQgZmYNDQp1bmtub3duOiBzdGF0dXMgcmVnIHRlc3QgZmFpbGVkIGZm DQ0KdW5rbm93bjogc3RhdHVzIHJlZyB0ZXN0IGZhaWxlZCBmZg0NCnVua25v d246IHN0YXR1cyByZWcgdGVzdCBmYWlsZWQgZmYNDQp1bmtub3duOiBzdGF0 dXMgcmVnIHRlc3QgZmFpbGVkIGZmDQ0Kc2M6IHNjMCBhbHJlYWR5IGV4aXN0 czsgc2tpcHBpbmcgaXQNDQp2Z2E6IHZnYTAgYWxyZWFkeSBleGlzdHM7IHNr aXBwaW5nIGl0DQ0KaXNhX3Byb2JlX2NoaWxkcmVuOiBkaXNhYmxpbmcgUG5Q IGRldmljZXMNDQppc2FfcHJvYmVfY2hpbGRyZW46IHByb2Jpbmcgbm9uLVBu UCBkZXZpY2VzDQ0Kb3JtMDogPElTQSBPcHRpb24gUk9NPiBhdCBpb21lbSAw eGMwMDAwLTB4Y2JmZmYgb24gaXNhMA0NCnBtdGltZXIwIG9uIGlzYTANDQph ZHYwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkNDQphaGEwOiBub3QgcHJvYmVk IChkaXNhYmxlZCkNDQphaWMwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkNDQpi dDA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQ0NCmNzMDogbm90IHByb2JlZCAo ZGlzYWJsZWQpDQ0KZWQwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkNDQpmZTA6 IG5vdCBwcm9iZWQgKGRpc2FibGVkKQ0NCmllMDogbm90IHByb2JlZCAoZGlz YWJsZWQpDQ0KbG5jMDogbm90IHByb2JlZCAoZGlzYWJsZWQpDQ0KcGNpYzAg ZmFpbGVkIHRvIHByb2JlIGF0IHBvcnQgMHgzZTAgaW9tZW0gMHhkMDAwMCBv biBpc2EwDQ0KcGNpYzE6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQ0NCnBwYzA6 IHBhcmFsbGVsIHBvcnQgbm90IGZvdW5kLg0NCnBwYzA6IDxQYXJhbGxlbCBw b3J0PiBmYWlsZWQgdG8gcHJvYmUgYXQgaXJxIDcgb24gaXNhMA0NCnNjMDog PFN5c3RlbSBjb25zb2xlPiBhdCBmbGFncyAweDEwMCBvbiBpc2EwDQ0Kc2Mw OiBWR0EgPDE2IHZpcnR1YWwgY29uc29sZXMsIGZsYWdzPTB4MTAwPg0NCnNj MDogZmIwLCBrYmQwLCB0ZXJtaW5hbCBlbXVsYXRvcjogc2MgKHN5c2NvbnMg dGVybWluYWwpDQ0Kc2lvMTogY29uZmlndXJlZCBpcnEgMyBub3QgaW4gYml0 bWFwIG9mIHByb2JlZCBpcnFzIDANDQpzaW8xOiBwb3J0IG1heSBub3QgYmUg ZW5hYmxlZA0NCnNpbzE6IGlycSBtYXBzOiAwIDAgMCAwDQ0Kc2lvMTogcHJv YmUgZmFpbGVkIHRlc3Qocyk6IDAgMSAyIDQgNiA3IDkNDQpzaW8xIGZhaWxl ZCB0byBwcm9iZSBhdCBwb3J0IDB4MmY4LTB4MmZmIGlycSAzIG9uIGlzYTAN DQpzaW8yOiBub3QgcHJvYmVkIChkaXNhYmxlZCkNDQpzaW8zOiBub3QgcHJv YmVkIChkaXNhYmxlZCkNDQpzbjA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQ0N CnZnYTA6IDxHZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAtMHgzZGYg aW9tZW0gMHhhMDAwMC0weGJmZmZmIG9uIGlzYTANDQpmYjA6IHZnYTAsIHZn YSwgdHlwZTpWR0EgKDUpLCBmbGFnczoweDcwMDdmDQ0KZmIwOiBwb3J0OjB4 M2MwLTB4M2RmLCBjcnRjOjB4M2Q0LCBtZW06MHhhMDAwMCAweDIwMDAwDQ0K ZmIwOiBpbml0IG1vZGU6MjQsIGJpb3MgbW9kZTozLCBjdXJyZW50IG1vZGU6 MjQNDQpmYjA6IHdpbmRvdzoweGMwMGI4MDAwIHNpemU6MzJrIGdyYW46MzJr LCBidWY6MCBzaXplOjMyaw0NClZHQSBwYXJhbWV0ZXJzIHVwb24gcG93ZXIt dXANDQo1MCAxOCAxMCAwMCAwMCAwMCAwMyAwMCAwMiA2NyA1ZiA0ZiA1MCA4 MiA1NSA4MSANDQpiZiAxZiAwMCA0ZiAwZCAwZSAwMCAwMCAwNSBhMCA5YyAw ZSA4ZiAyOCAxZiA5NiANDQpiOSBhMyBmZiAwMCAwMSAwMiAwMyAwNCAwNSAx NCAwNyAzOCAzOSAzYSAzYiAzYyANDQozZCAzZSAzZiAwYyAwMCAwZiAwOCAw MCAwMCAwMCAwMCAwMCAxMCAwZSAwMCBmZiANDQpWR0EgcGFyYW1ldGVycyBp biBCSU9TIGZvciBtb2RlIDI0DQ0KNTAgMTggMTAgMDAgMTAgMDAgMDMgMDAg MDIgNjcgNWYgNGYgNTAgODIgNTUgODEgDQ0KYmYgMWYgMDAgNGYgMGQgMGUg MDAgMDAgMDAgMDAgOWMgOGUgOGYgMjggMWYgOTYgDQ0KYjkgYTMgZmYgMDAg MDEgMDIgMDMgMDQgMDUgMTQgMDcgMzggMzkgM2EgM2IgM2MgDQ0KM2QgM2Ug M2YgMGMgMDAgMGYgMDggMDAgMDAgMDAgMDAgMDAgMTAgMGUgMDAgZmYgDQ0K RUdBL1ZHQSBwYXJhbWV0ZXJzIHRvIGJlIHVzZWQgZm9yIG1vZGUgMjQNDQo1 MCAxOCAxMCAwMCAwMCAwMCAwMyAwMCAwMiA2NyA1ZiA0ZiA1MCA4MiA1NSA4 MSANDQpiZiAxZiAwMCA0ZiAwZCAwZSAwMCAwMCAwNSBhMCA5YyAwZSA4ZiAy OCAxZiA5NiANDQpiOSBhMyBmZiAwMCAwMSAwMiAwMyAwNCAwNSAxNCAwNyAz OCAzOSAzYSAzYiAzYyANDQozZCAzZSAzZiAwYyAwMCAwZiAwOCAwMCAwMCAw MCAwMCAwMCAxMCAwZSAwMCBmZiANDQp2dDA6IG5vdCBwcm9iZWQgKGRpc2Fi bGVkKQ0NCmlzYV9wcm9iZV9jaGlsZHJlbjogcHJvYmluZyBQblAgZGV2aWNl cw0NCkRldmljZSBjb25maWd1cmF0aW9uIGZpbmlzaGVkLg0NCnByb2NmcyBy ZWdpc3RlcmVkDQ0KVGltZWNvdW50ZXIgIlRTQyIgZnJlcXVlbmN5IDIyNjQ3 NjYyOTkgSHogcXVhbGl0eSA4MDANDQpUaW1lY291bnRlcnMgdGljayBldmVy eSAxMC4wMDAgbXNlYw0NCmxvMDogYnBmIGF0dGFjaGVkDQ0KYXRhMC1tYXN0 ZXI6IHBpbz1QSU80IHdkbWE9V0RNQTIgdWRtYT1VRE1BMTAwIGNhYmxlPTgw IHdpcmUNDQpjcHUwOiBzZXQgc3BlZWQgdG8gMTAwLjAlDQ0KYWNwaV9jcHU6 IHRocm90dGxpbmcgZW5hYmxlZCwgMTYgc3RlcHMgKDEwMCUgdG8gNi4yJSks IGN1cnJlbnRseSAxMDAuMCUNDQphdGEwOiByZWluaXRpbmcgY2hhbm5lbCAu Lg0NCmF0YTA6IHJlc2V0IHRwMSBtYXNrPTAzIG9zdGF0MD01MCBvc3RhdDE9 MDANDQphdGEwOiBzdGF0MD0weDUwIGVycj0weDAxIGxzYj0weDAwIG1zYj0w eDAwDQ0KYXRhMDogc3RhdDE9MHgwMCBlcnI9MHgwMSBsc2I9MHgwMCBtc2I9 MHgwMA0NCmF0YTA6IHJlc2V0IHRwMiBzdGF0MD01MCBzdGF0MT0wMCBkZXZp Y2VzPTB4MTxBVEFfTUFTVEVSPg0NCmFkMDogV0FSTklORyAtIFNFVEZFQVRV UkVTIFNFVCBUUkFOU0ZFUiBNT0RFIHJlcXVldWVkIGR1ZSB0byBjaGFubmVs IHJlc2V0DQ0KYXRhMDogcmVpbml0IGRvbmUgLi4NDQphZDA6IEZBSUxVUkUg LSBTRVRGRUFUVVJFUyBTRVQgVFJBTlNGRVIgTU9ERSB0aW1lZCBvdXQNDQph ZDA6IEZBSUxVUkUgc2V0dGluZyBQSU80IG9uIFZJQSA4MjM1IGNoaXANDQph dGEwOiByZWluaXRpbmcgY2hhbm5lbCAuLg0NCmF0YTA6IHJlc2V0IHRwMSBt YXNrPTAzIG9zdGF0MD01MCBvc3RhdDE9MDANDQphdGEwOiBzdGF0MD0weDUw IGVycj0weDAxIGxzYj0weDAwIG1zYj0weDAwDQ0KYXRhMDogc3RhdDE9MHgw MCBlcnI9MHgwMSBsc2I9MHgwMCBtc2I9MHgwMA0NCmF0YTA6IHJlc2V0IHRw MiBzdGF0MD01MCBzdGF0MT0wMCBkZXZpY2VzPTB4MTxBVEFfTUFTVEVSPg0N CmFkMDogV0FSTklORyAtIFNFVEZFQVRVUkVTIFNFVCBUUkFOU0ZFUiBNT0RF IHJlcXVldWVkIGR1ZSB0byBjaGFubmVsIHJlc2V0DQ0KYXRhMDogcmVpbml0 IGRvbmUgLi4NDQphZDA6IEZBSUxVUkUgLSBTRVRGRUFUVVJFUyBTRVQgVFJB TlNGRVIgTU9ERSB0aW1lZCBvdXQNDQphZDA6IHRpbWVvdXQgc3RhdGU9MCB1 bmV4cGVjdGVkDQ0KYWQwOiByZXE9MHhjMTZjN2UxMCBTRVRGRUFUVVJFUyBT RVQgVFJBTlNGRVIgTU9ERSBzZW1hcGhvcmUgdGltZW91dCAhISBEQU5HRVIg V2lsbCBSb2JpbnNvbiAhIQ0NCmFkMDogcmVxPTB4YzE2YzdlMTAgU0VURkVB VFVSRVMgU0VUIFRSQU5TRkVSIE1PREUgc2VtYXBob3JlIHRpbWVvdXQgISEg REFOR0VSIFdpbGwgUm9iaW5zb24gISENDQphZDA6IHJlcT0weGMxNmM3ZTEw IFNFVEZFQVRVUkVTIFNFVCBUUkFOU0ZFUiBNT0RFIHNlbWFwaG9yZSB0aW1l b3V0ICEhIERBTkdFUiBXaWxsIFJvYmluc29uICEhDQ0KYWQwOiByZXE9MHhj MTZjN2UxMCBTRVRGRUFUVVJFUyBTRVQgVFJBTlNGRVIgTU9ERSBzZW1hcGhv cmUgdGltZW91dCAhISBEQU5HRVIgV2lsbCBSb2JpbnNvbiAhIQ0NCmFkMDog cmVxPTB4YzE2YzdlMTAgU0VURkVBVFVSRVMgU0VUIFRSQU5TRkVSIE1PREUg c2VtYXBob3JlIHRpbWVvdXQgISEgREFOR0VSIFdpbGwgUm9iaW5zb24gISEN DQphZDA6IHJlcT0weGMxNmM3ZTEwIFNFVEZFQVRVUkVTIFNFVCBUUkFOU0ZF UiBNT0RFIHNlbWFwaG9yZSB0aW1lb3V0ICEhIERBTkdFUiBXaWxsIFJvYmlu c29uICEhDQ0KYWQwOiByZXE9MHhjMTZjN2UxMCBTRVRGRUFUVVJFUyBTRVQg VFJBTlNGRVIgTU9ERSBzZW1hcGhvcmUgdGltZW91dCAhISBEQU5HRVIgV2ls bCBSb2JpbnNvbiAhIQ0NCg0K --0-1470598922-1107786476=:1626 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="dmesg-5.3-RELEASE" Content-Transfer-Encoding: BASE64 Content-ID: <20050207122825.Y1626@serv-qmp.walk.com.br> Content-Description: Content-Disposition: attachment; filename="dmesg-5.3-RELEASE" U01BUCB0eXBlPTAxIGJhc2U9MDAwMDAwMDAwMDAwMDAwMCBsZW49MDAwMDAw MDAwMDA5ZmMwMA0NClNNQVAgdHlwZT0wMiBiYXNlPTAwMDAwMDAwMDAwOWZj MDAgbGVuPTAwMDAwMDAwMDAwMDA0MDANDQpTTUFQIHR5cGU9MDIgYmFzZT0w MDAwMDAwMDAwMGU4MDAwIGxlbj0wMDAwMDAwMDAwMDE4MDAwDQ0KU01BUCB0 eXBlPTAxIGJhc2U9MDAwMDAwMDAwMDEwMDAwMCBsZW49MDAwMDAwMDAwZjYz MDAwMA0NClNNQVAgdHlwZT0wMyBiYXNlPTAwMDAwMDAwMGY3MzAwMDAgbGVu PTAwMDAwMDAwMDAwMTAwMDANDQpTTUFQIHR5cGU9MDQgYmFzZT0wMDAwMDAw MDBmNzQwMDAwIGxlbj0wMDAwMDAwMDAwMGIwMDAwDQ0KU01BUCB0eXBlPTAy IGJhc2U9MDAwMDAwMDAwZjdmMDAwMCBsZW49MDAwMDAwMDAwMDAxMDAwMA0N ClNNQVAgdHlwZT0wMiBiYXNlPTAwMDAwMDAwZmZiYzAwMDAgbGVuPTAwMDAw MDAwMDA0NDAwMDANDQpDb3B5cmlnaHQgKGMpIDE5OTItMjAwNCBUaGUgRnJl ZUJTRCBQcm9qZWN0Lg0NCkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4 MywgMTk4NiwgMTk4OCwgMTk4OSwgMTk5MSwgMTk5MiwgMTk5MywgMTk5NA0N CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlh LiBBbGwgcmlnaHRzIHJlc2VydmVkLg0NCkZyZWVCU0QgNS4zLVJFTEVBU0Ug IzY6IFN1biBGZWIgIDYgMTM6MzA6NDMgQlJTVCAyMDA1DQ0KICAgIHJvb3RA ZmxhZy5mYXg6L3Vzci9zcmMvc3lzL2kzODYvY29tcGlsZS9HRU5FUklDDQ0K UHJlbG9hZGVkIGVsZiBrZXJuZWwgIi9rZXJuZWwuZ2VuZXJpYyIgYXQgMHhj MGEyNTAwMC4NDQpQcmVsb2FkZWQgZWxmIG1vZHVsZSAiL2Jvb3Qva2VybmVs L2FjcGkua28iIGF0IDB4YzBhMjUyMjQuDQ0KbGlua19lbGY6IHN5bWJvbCBh Y3BpX3B3cl9mb3Jfc2xlZXBfZGVzYyB1bmRlZmluZWQNDQpLTEQgZmlsZSBh Y3BpLmtvIC0gY291bGQgbm90IGZpbmFsaXplIGxvYWRpbmcNDQpNUCBDb25m aWd1cmF0aW9uIFRhYmxlIHZlcnNpb24gMS4xIGZvdW5kIGF0IDB4YzAwZjBm NTANDQpBUElDOiBVc2luZyB0aGUgTVBUYWJsZSBlbnVtZXJhdG9yLg0NCk1Q VGFibGU6IDxURU1QTEFURSA+DQ0KQ2FsaWJyYXRpbmcgY2xvY2socykgLi4u IGk4MjU0IGNsb2NrOiAxMTkzMTQ0IEh6DQ0KQ0xLX1VTRV9JODI1NF9DQUxJ QlJBVElPTiBub3Qgc3BlY2lmaWVkIC0gdXNpbmcgZGVmYXVsdCBmcmVxdWVu Y3kNDQpUaW1lY291bnRlciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgyIEh6 IHF1YWxpdHkgMA0NCkNhbGlicmF0aW5nIFRTQyBjbG9jayAuLi4gVFNDIGNs b2NrOiAyMjY0NzYyMDMyIEh6DQ0KQ1BVOiBJbnRlbChSKSBDZWxlcm9uKFIp IENQVSAyLjI2R0h6ICgyMjY0Ljc2LU1IeiA2ODYtY2xhc3MgQ1BVKQ0NCiAg T3JpZ2luID0gIkdlbnVpbmVJbnRlbCIgIElkID0gMHhmMzMgIFN0ZXBwaW5n ID0gMw0NCiAgRmVhdHVyZXM9MHhiZmViZmJmZjxGUFUsVk1FLERFLFBTRSxU U0MsTVNSLFBBRSxNQ0UsQ1g4LEFQSUMsU0VQLE1UUlIsUEdFLE1DQSxDTU9W LFBBVCxQU0UzNixDTEZMVVNILERUUyxBQ1BJLE1NWCxGWFNSLFNTRSxTU0Uy LFNTLEhUVCxUTSxQQkU+DQ0KcmVhbCBtZW1vcnkgID0gMjU5MTk0ODgwICgy NDcgTUIpDQ0KUGh5c2ljYWwgbWVtb3J5IGNodW5rKHMpOg0NCjB4MDAwMDAw MDAwMDAwMTAwMCAtIDB4MDAwMDAwMDAwMDA5ZWZmZiwgNjQ3MTY4IGJ5dGVz ICgxNTggcGFnZXMpDQ0KMHgwMDAwMDAwMDAwMTAwMDAwIC0gMHgwMDAwMDAw MDAwM2ZmZmZmLCAzMTQ1NzI4IGJ5dGVzICg3NjggcGFnZXMpDQ0KMHgwMDAw MDAwMDAwYzI2MDAwIC0gMHgwMDAwMDAwMDBmMmE2ZmZmLCAyNDE3MDA4NjQg Ynl0ZXMgKDU5MDA5IHBhZ2VzKQ0NCmF2YWlsIG1lbW9yeSA9IDI0NDA4ODgz MiAoMjMyIE1CKQ0NCmJpb3MzMjogRm91bmQgQklPUzMyIFNlcnZpY2UgRGly ZWN0b3J5IGhlYWRlciBhdCAweGMwMGYwMDAwDQ0KYmlvczMyOiBFbnRyeSA9 IDB4ZjAwMTAgKGMwMGYwMDEwKSAgUmV2ID0gMCAgTGVuID0gMQ0NCnBjaWJp b3M6IFBDSSBCSU9TIGVudHJ5IGF0IDB4ZjAwMDArMHgzMQ0NCnBucGJpb3M6 IEZvdW5kIFBuUCBCSU9TIGRhdGEgYXQgMHhjMDBmNjA2MA0NCnBucGJpb3M6 IEVudHJ5ID0gZjAwMDA6NmNiYSAgUmV2ID0gMS4wDQ0KT3RoZXIgQklPUyBz aWduYXR1cmVzIGZvdW5kOg0NCmlvYXBpYzA6IEFzc3VtaW5nIGludGJhc2Ug b2YgMA0NCmlvYXBpYzA6IFJvdXRpbmcgZXh0ZXJuYWwgODI1OUEncyAtPiBp bnRwaW4gMA0NCmlvYXBpYzA6IGludHBpbiAwIC0+IEV4dElOVCAoZWRnZSwg aGlnaCkNDQppb2FwaWMwOiBpbnRwaW4gMSAtPiBJU0EgSVJRIDEgKGVkZ2Us IGhpZ2gpDQ0KaW9hcGljMDogaW50cGluIDIgLT4gSVNBIElSUSAyIChlZGdl LCBoaWdoKQ0NCmlvYXBpYzA6IGludHBpbiAzIC0+IElTQSBJUlEgMyAoZWRn ZSwgaGlnaCkNDQppb2FwaWMwOiBpbnRwaW4gNCAtPiBJU0EgSVJRIDQgKGVk Z2UsIGhpZ2gpDQ0KaW9hcGljMDogaW50cGluIDUgLT4gSVNBIElSUSA1IChl ZGdlLCBoaWdoKQ0NCmlvYXBpYzA6IGludHBpbiA2IC0+IElTQSBJUlEgNiAo ZWRnZSwgaGlnaCkNDQppb2FwaWMwOiBpbnRwaW4gNyAtPiBJU0EgSVJRIDcg KGVkZ2UsIGhpZ2gpDQ0KaW9hcGljMDogaW50cGluIDggLT4gSVNBIElSUSA4 IChlZGdlLCBoaWdoKQ0NCmlvYXBpYzA6IGludHBpbiA5IC0+IElTQSBJUlEg OSAoZWRnZSwgaGlnaCkNDQppb2FwaWMwOiBpbnRwaW4gMTAgLT4gSVNBIElS USAxMCAoZWRnZSwgaGlnaCkNDQppb2FwaWMwOiBpbnRwaW4gMTEgLT4gSVNB IElSUSAxMSAoZWRnZSwgaGlnaCkNDQppb2FwaWMwOiBpbnRwaW4gMTIgLT4g SVNBIElSUSAxMiAoZWRnZSwgaGlnaCkNDQppb2FwaWMwOiBpbnRwaW4gMTMg LT4gSVNBIElSUSAxMyAoZWRnZSwgaGlnaCkNDQppb2FwaWMwOiBpbnRwaW4g MTQgLT4gSVNBIElSUSAxNCAoZWRnZSwgaGlnaCkNDQppb2FwaWMwOiBpbnRw aW4gMTUgLT4gSVNBIElSUSAxNSAoZWRnZSwgaGlnaCkNDQppb2FwaWMwOiBp bnRwaW4gMTYgLT4gUENJIElSUSAxNiAobGV2ZWwsIGxvdykNDQppb2FwaWMw OiBpbnRwaW4gMTcgLT4gUENJIElSUSAxNyAobGV2ZWwsIGxvdykNDQppb2Fw aWMwOiBpbnRwaW4gMTggLT4gUENJIElSUSAxOCAobGV2ZWwsIGxvdykNDQpp b2FwaWMwOiBpbnRwaW4gMTkgLT4gUENJIElSUSAxOSAobGV2ZWwsIGxvdykN DQppb2FwaWMwOiBpbnRwaW4gMjAgLT4gUENJIElSUSAyMCAobGV2ZWwsIGxv dykNDQppb2FwaWMwOiBpbnRwaW4gMjEgLT4gUENJIElSUSAyMSAobGV2ZWws IGxvdykNDQppb2FwaWMwOiBpbnRwaW4gMjIgLT4gUENJIElSUSAyMiAobGV2 ZWwsIGxvdykNDQppb2FwaWMwOiBpbnRwaW4gMjMgLT4gUENJIElSUSAyMyAo bGV2ZWwsIGxvdykNDQppb2FwaWMwOiBpbnRwaW4gMSBidXMgSVNBDQ0KaW9h cGljMDogaW50cGluIDEgdHJpZ2dlcjogZWRnZQ0NCmlvYXBpYzA6IGludHBp biAxIHBvbGFyaXR5OiBoaWdoDQ0KaW9hcGljMDogaW50cGluIDIgYnVzIElT QQ0NCmlvYXBpYzA6IFJvdXRpbmcgSVJRIDAgLT4gaW50cGluIDINDQppb2Fw aWMwOiBpbnRwaW4gMiB0cmlnZ2VyOiBlZGdlDQ0KaW9hcGljMDogaW50cGlu IDIgcG9sYXJpdHk6IGhpZ2gNDQppb2FwaWMwOiBpbnRwaW4gMyBidXMgSVNB DQ0KaW9hcGljMDogaW50cGluIDMgdHJpZ2dlcjogZWRnZQ0NCmlvYXBpYzA6 IGludHBpbiAzIHBvbGFyaXR5OiBoaWdoDQ0KaW9hcGljMDogaW50cGluIDQg YnVzIElTQQ0NCmlvYXBpYzA6IGludHBpbiA0IHRyaWdnZXI6IGVkZ2UNDQpp b2FwaWMwOiBpbnRwaW4gNCBwb2xhcml0eTogaGlnaA0NCmlvYXBpYzA6IGlu dHBpbiA2IGJ1cyBJU0ENDQppb2FwaWMwOiBpbnRwaW4gNiB0cmlnZ2VyOiBl ZGdlDQ0KaW9hcGljMDogaW50cGluIDYgcG9sYXJpdHk6IGhpZ2gNDQppb2Fw aWMwOiBpbnRwaW4gNyBidXMgSVNBDQ0KaW9hcGljMDogaW50cGluIDcgdHJp Z2dlcjogZWRnZQ0NCmlvYXBpYzA6IGludHBpbiA3IHBvbGFyaXR5OiBoaWdo DQ0KaW9hcGljMDogaW50cGluIDggYnVzIElTQQ0NCmlvYXBpYzA6IGludHBp biA4IHRyaWdnZXI6IGVkZ2UNDQppb2FwaWMwOiBpbnRwaW4gOCBwb2xhcml0 eTogaGlnaA0NCmlvYXBpYzA6IGludHBpbiA5IGJ1cyBJU0ENDQppb2FwaWMw OiBpbnRwaW4gOSB0cmlnZ2VyOiBlZGdlDQ0KaW9hcGljMDogaW50cGluIDkg cG9sYXJpdHk6IGhpZ2gNDQppb2FwaWMwOiBpbnRwaW4gMTIgYnVzIElTQQ0N CmlvYXBpYzA6IGludHBpbiAxMiB0cmlnZ2VyOiBlZGdlDQ0KaW9hcGljMDog aW50cGluIDEyIHBvbGFyaXR5OiBoaWdoDQ0KaW9hcGljMDogaW50cGluIDEz IGJ1cyBJU0ENDQppb2FwaWMwOiBpbnRwaW4gMTMgdHJpZ2dlcjogZWRnZQ0N CmlvYXBpYzA6IGludHBpbiAxMyBwb2xhcml0eTogaGlnaA0NCmlvYXBpYzA6 IGludHBpbiAxNCBidXMgSVNBDQ0KaW9hcGljMDogaW50cGluIDE0IHRyaWdn ZXI6IGVkZ2UNDQppb2FwaWMwOiBpbnRwaW4gMTQgcG9sYXJpdHk6IGhpZ2gN DQppb2FwaWMwOiBpbnRwaW4gMTUgYnVzIElTQQ0NCmlvYXBpYzA6IGludHBp biAxNSB0cmlnZ2VyOiBlZGdlDQ0KaW9hcGljMDogaW50cGluIDE1IHBvbGFy aXR5OiBoaWdoDQ0KaW9hcGljMDogaW50cGluIDIzIGJ1cyBJU0ENDQppb2Fw aWMwOiBSb3V0aW5nIElSUSAxMSAtPiBpbnRwaW4gMjMNDQppb2FwaWMwOiBp bnRwaW4gMTEgZGlzYWJsZWQNDQppb2FwaWMwOiBpbnRwaW4gMjMgdHJpZ2dl cjogbGV2ZWwNDQppb2FwaWMwOiBpbnRwaW4gMjMgcG9sYXJpdHk6IGxvdw0N CmlvYXBpYzA6IGludHBpbiAxNiBidXMgSVNBDQ0KaW9hcGljMDogUm91dGlu ZyBJUlEgMTEgLT4gaW50cGluIDE2DQ0KaW9hcGljMDogaW50cGluIDE2IHRy aWdnZXI6IGxldmVsDQ0KaW9hcGljMDogaW50cGluIDE2IHBvbGFyaXR5OiBs b3cNDQppb2FwaWMwOiBpbnRwaW4gMjEgYnVzIElTQQ0NCmlvYXBpYzA6IFJv dXRpbmcgSVJRIDExIC0+IGludHBpbiAyMQ0NCmlvYXBpYzA6IGludHBpbiAy MSB0cmlnZ2VyOiBsZXZlbA0NCmlvYXBpYzA6IGludHBpbiAyMSBwb2xhcml0 eTogbG93DQ0KaW9hcGljMDogaW50cGluIDIxIGJ1cyBJU0ENDQppb2FwaWMw OiBSb3V0aW5nIElSUSA1IC0+IGludHBpbiAyMQ0NCmlvYXBpYzA6IGludHBp biA1IGRpc2FibGVkDQ0KaW9hcGljMDogaW50cGluIDIxIHRyaWdnZXI6IGxl dmVsDQ0KaW9hcGljMDogaW50cGluIDIxIHBvbGFyaXR5OiBsb3cNDQppb2Fw aWMwOiBpbnRwaW4gMjEgYnVzIElTQQ0NCmlvYXBpYzA6IFJvdXRpbmcgSVJR IDEwIC0+IGludHBpbiAyMQ0NCmlvYXBpYzA6IGludHBpbiAxMCBkaXNhYmxl ZA0NCmlvYXBpYzA6IGludHBpbiAyMSB0cmlnZ2VyOiBsZXZlbA0NCmlvYXBp YzA6IGludHBpbiAyMSBwb2xhcml0eTogbG93DQ0KbGFwaWM6IFJvdXRpbmcg RXh0SU5UIC0+IExJTlQwDQ0KbGFwaWM6IFJvdXRpbmcgTk1JIC0+IExJTlQx DQ0KaW9hcGljMCA8VmVyc2lvbiAwLjM+IGlycXMgMC0yMyBvbiBtb3RoZXJi b2FyZA0NCmNwdTAgQlNQOg0NCiAgICAgSUQ6IDB4MDAwMDAwMDAgICBWRVI6 IDB4MDAwNTAwMTQgTERSOiAweDAxMDAwMDAwIERGUjogMHgwZmZmZmZmZg0N CiAgbGludDA6IDB4MDAwMTA3MDAgbGludDE6IDB4MDAwMDA0MDAgVFBSOiAw eDAwMDAwMDAwIFNWUjogMHgwMDAwMDFmZg0NCndsYW46IDw4MDIuMTEgTGlu ayBMYXllcj4NDQphdGFfaW5pdA0NCmF0YV9pbml0IG9rDQ0KbnVsbDogPG51 bGwgZGV2aWNlLCB6ZXJvIGRldmljZT4NDQpyYW5kb206IDxlbnRyb3B5IHNv dXJjZSwgU29mdHdhcmUsIFlhcnJvdz4NDQppbzogPEkvTz4NDQptZW06IDxt ZW1vcnk+DQ0KUGVudGl1bSBQcm8gTVRSUiBzdXBwb3J0IGVuYWJsZWQNDQpu cHgwOiBbRkFTVF0NDQpucHgwOiA8bWF0aCBwcm9jZXNzb3I+IG9uIG1vdGhl cmJvYXJkDQ0KbnB4MDogSU5UIDE2IGludGVyZmFjZQ0NCnBjaV9vcGVuKDEp Ogltb2RlIDEgYWRkciBwb3J0ICgweDBjZjgpIGlzIDB4ODAwMDAwNjANDQpw Y2lfb3BlbigxYSk6CW1vZGUxcmVzPTB4ODAwMDAwMDAgKDB4ODAwMDAwMDAp DQ0KcGNpX2NmZ2NoZWNrOglkZXZpY2UgMCBbY2xhc3M9MDYwMDAwXSBbaGRy PTAwXSBpcyB0aGVyZSAoaWQ9MzE0ODExMDYpDQ0KcGNpYmlvczogQklPUyB2 ZXJzaW9uIDIuMTANDQpGb3VuZCAkUElSIHRhYmxlLCA3IGVudHJpZXMgYXQg MHhjMDBmNWY2MA0NClBDSS1Pbmx5IEludGVycnVwdHM6IG5vbmUNDQpMb2Nh dGlvbiAgQnVzIERldmljZSBQaW4gIExpbmsgIElSUXMNDQplbWJlZGRlZCAg ICAwICAgMTcgICAgQyAgIDB4MDMgIDMgNCA1IDcgMTAgMTEgMTQgMTUNDQpl bWJlZGRlZCAgICAwICAgMTggICAgQSAgIDB4MDEgIDMgNCA1IDcgMTAgMTEg MTQgMTUNDQplbWJlZGRlZCAgICAwICAgIDEgICAgQSAgIDB4MDEgIDMgNCA1 IDcgMTAgMTEgMTQgMTUNDQplbWJlZGRlZCAgICAwICAgIDEgICAgQiAgIDB4 MDIgIDMgNCA1IDcgMTAgMTEgMTQgMTUNDQpzbG90IDEgICAgICAwICAgIDkg ICAgQSAgIDB4MDIgIDMgNCA1IDcgMTAgMTEgMTQgMTUNDQpzbG90IDEgICAg ICAwICAgIDkgICAgQiAgIDB4MDMgIDMgNCA1IDcgMTAgMTEgMTQgMTUNDQpz bG90IDEgICAgICAwICAgIDkgICAgQyAgIDB4MDUgIDMgNCA1IDcgMTAgMTEg MTQgMTUNDQpzbG90IDEgICAgICAwICAgIDkgICAgRCAgIDB4MDEgIDMgNCA1 IDcgMTAgMTEgMTQgMTUNDQpzbG90IDIgICAgICAwICAgMTAgICAgQSAgIDB4 MDMgIDMgNCA1IDcgMTAgMTEgMTQgMTUNDQpzbG90IDIgICAgICAwICAgMTAg ICAgQiAgIDB4MDUgIDMgNCA1IDcgMTAgMTEgMTQgMTUNDQpzbG90IDIgICAg ICAwICAgMTAgICAgQyAgIDB4MDEgIDMgNCA1IDcgMTAgMTEgMTQgMTUNDQpz bG90IDIgICAgICAwICAgMTAgICAgRCAgIDB4MDIgIDMgNCA1IDcgMTAgMTEg MTQgMTUNDQpzbG90IDMgICAgICAwICAgMTEgICAgQSAgIDB4MDUgIDMgNCA1 IDcgMTAgMTEgMTQgMTUNDQpzbG90IDMgICAgICAwICAgMTEgICAgQiAgIDB4 MDEgIDMgNCA1IDcgMTAgMTEgMTQgMTUNDQpzbG90IDMgICAgICAwICAgMTEg ICAgQyAgIDB4MDIgIDMgNCA1IDcgMTAgMTEgMTQgMTUNDQpzbG90IDMgICAg ICAwICAgMTEgICAgRCAgIDB4MDMgIDMgNCA1IDcgMTAgMTEgMTQgMTUNDQpl bWJlZGRlZCAgICAwICAgMTYgICAgQSAgIDB4MDEgIDMgNCA1IDcgMTAgMTEg MTQgMTUNDQplbWJlZGRlZCAgICAwICAgMTYgICAgQiAgIDB4MDIgIDMgNCA1 IDcgMTAgMTEgMTQgMTUNDQplbWJlZGRlZCAgICAwICAgMTYgICAgQyAgIDB4 MDMgIDMgNCA1IDcgMTAgMTEgMTQgMTUNDQplbWJlZGRlZCAgICAwICAgMTYg ICAgRCAgIDB4MDUgIDMgNCA1IDcgMTAgMTEgMTQgMTUNDQpwY2liMDogPEhv c3QgdG8gUENJIGJyaWRnZT4gcGNpYnVzIDAgb24gbW90aGVyYm9hcmQNDQpw aXIwOiA8UENJIEludGVycnVwdCBSb3V0aW5nIFRhYmxlOiA3IEVudHJpZXM+ IG9uIG1vdGhlcmJvYXJkDQ0KJFBJUjogTGlua3MgYWZ0ZXIgaW5pdGlhbCBw cm9iZToNDQpMaW5rICBJUlEgIFJ0ZCAgUmVmICBJUlFzDQ0KIDB4MyAgMjU1 ICAgTiAgICAgNSAgMyA0IDUgNyAxMCAxMSAxNCAxNQ0NCiAweDEgIDI1NSAg IE4gICAgIDYgIDMgNCA1IDcgMTAgMTEgMTQgMTUNDQogMHgyICAyNTUgICBO ICAgICA1ICAzIDQgNSA3IDEwIDExIDE0IDE1DQ0KIDB4NSAgMjU1ICAgTiAg ICAgNCAgMyA0IDUgNyAxMCAxMSAxNCAxNQ0NCiRQSVI6IEZvdW5kIG1hdGNo aW5nIHBpbiBmb3IgMC4xOC5JTlRBIGF0IGZ1bmMgMDogMTENDQokUElSOiBG b3VuZCBtYXRjaGluZyBwaW4gZm9yIDAuMTYuSU5UQSBhdCBmdW5jIDA6IDEx DQ0KJFBJUjogRm91bmQgbWF0Y2hpbmcgcGluIGZvciAwLjE2LklOVEIgYXQg ZnVuYyAxOiA1DQ0KJFBJUjogRm91bmQgbWF0Y2hpbmcgcGluIGZvciAwLjE2 LklOVEMgYXQgZnVuYyAyOiAxMA0NCiRQSVI6IExpbmtzIGFmdGVyIGluaXRp YWwgSVJRIGRpc2NvdmVyeToNDQpMaW5rICBJUlEgIFJ0ZCAgUmVmICBJUlFz DQ0KIDB4MyAgIDEwICAgWSAgICAgNSAgMyA0IDUgNyAxMCAxMSAxNCAxNQ0N CiAweDEgICAxMSAgIFkgICAgIDYgIDMgNCA1IDcgMTAgMTEgMTQgMTUNDQog MHgyICAgIDUgICBZICAgICA1ICAzIDQgNSA3IDEwIDExIDE0IDE1DQ0KIDB4 NSAgMjU1ICAgTiAgICAgNCAgMyA0IDUgNyAxMCAxMSAxNCAxNQ0NCiRQSVI6 IElSUXMgdXNlZCBieSBCSU9TOiA1IDEwIDExDQ0KJFBJUjogSW50ZXJydXB0 IFdlaWdodHM6DQ0KWyAgICAwICAgMSAgIDIgICAzICAgNCAgIDUgICA2ICAg NyAgIDggICA5ICAxMCAgMTEgIDEyICAxMyAgMTQgIDE1IF0NDQpbICAgIDAg ICAwICAgMCAgIDAgICAwICAgNSAgIDAgICAwICAgMCAgIDAgICA1ICAgNiAg IDAgICAwICAgMCAgIDAgXQ0NCnBjaTA6IDxQQ0kgYnVzPiBvbiBwY2liMA0N CnBjaTA6IHBoeXNpY2FsIGJ1cz0wDQ0KCW1hcFsxMF06IHR5cGUgMywgcmFu Z2UgMzIsIGJhc2UgZTAwMDAwMDAsIHNpemUgMjIsIGVuYWJsZWQNDQpmb3Vu ZC0+CXZlbmRvcj0weDExMDYsIGRldj0weDMxNDgsIHJldmlkPTB4MDANDQoJ YnVzPTAsIHNsb3Q9MCwgZnVuYz0wDQ0KCWNsYXNzPTA2LTAwLTAwLCBoZHJ0 eXBlPTB4MDAsIG1mZGV2PTANDQoJY21kcmVnPTB4MDAwNiwgc3RhdHJlZz0w eDIyMzAsIGNhY2hlbG5zej0wIChkd29yZHMpDQ0KCWxhdHRpbWVyPTB4MDgg KDI0MCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAg bnMpDQ0KCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBE MA0NCmZvdW5kLT4JdmVuZG9yPTB4MTEwNiwgZGV2PTB4YjA5MSwgcmV2aWQ9 MHgwMA0NCglidXM9MCwgc2xvdD0xLCBmdW5jPTANDQoJY2xhc3M9MDYtMDQt MDAsIGhkcnR5cGU9MHgwMSwgbWZkZXY9MA0NCgljbWRyZWc9MHgwMTA3LCBz dGF0cmVnPTB4YTIzMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykNDQoJbGF0dGlt ZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDBjICgzMDAwIG5zKSwgbWF4bGF0 PTB4MDAgKDAgbnMpDQ0KCW1hcFsyMF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJh c2UgMDAwMGU0MDAsIHNpemUgIDUsIGVuYWJsZWQNDQppbnRlcnJ1cHQgcmUt cm91dGUNDQokUElSOiAwOjE2IElOVEEgcm91dGVkIHRvIGlycSAxMQ0NCmZv dW5kLT4JdmVuZG9yPTB4MTEwNiwgZGV2PTB4MzAzOCwgcmV2aWQ9MHg4MA0N CglidXM9MCwgc2xvdD0xNiwgZnVuYz0wDQ0KCWNsYXNzPTBjLTAzLTAwLCBo ZHJ0eXBlPTB4MDAsIG1mZGV2PTENDQoJY21kcmVnPTB4MDAxNywgc3RhdHJl Zz0weDAyMTAsIGNhY2hlbG5zej04IChkd29yZHMpDQ0KCWxhdHRpbWVyPTB4 NDAgKDE5MjAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAw ICgwIG5zKQ0NCglpbnRwaW49YSwgaXJxPTExDQ0KCXBvd2Vyc3BlYyAyICBz dXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMA0NCgltYXBbMjBdOiB0 eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDBlNDgwLCBzaXplICA1LCBlbmFi bGVkDQ0KaW50ZXJydXB0IHJlLXJvdXRlDQ0KJFBJUjogMDoxNiBJTlRCIHJv dXRlZCB0byBpcnEgNQ0NCmZvdW5kLT4JdmVuZG9yPTB4MTEwNiwgZGV2PTB4 MzAzOCwgcmV2aWQ9MHg4MA0NCglidXM9MCwgc2xvdD0xNiwgZnVuYz0xDQ0K CWNsYXNzPTBjLTAzLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTENDQoJY21k cmVnPTB4MDAxNywgc3RhdHJlZz0weDAyMTAsIGNhY2hlbG5zej04IChkd29y ZHMpDQ0KCWxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5nbnQ9MHgwMCAo MCBucyksIG1heGxhdD0weDAwICgwIG5zKQ0NCglpbnRwaW49YiwgaXJxPTUN DQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50 IEQwDQ0KCW1hcFsyMF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMGVj MDAsIHNpemUgIDUsIGVuYWJsZWQNDQppbnRlcnJ1cHQgcmUtcm91dGUNDQok UElSOiAwOjE2IElOVEMgcm91dGVkIHRvIGlycSAxMA0NCmZvdW5kLT4JdmVu ZG9yPTB4MTEwNiwgZGV2PTB4MzAzOCwgcmV2aWQ9MHg4MA0NCglidXM9MCwg c2xvdD0xNiwgZnVuYz0yDQ0KCWNsYXNzPTBjLTAzLTAwLCBoZHJ0eXBlPTB4 MDAsIG1mZGV2PTENDQoJY21kcmVnPTB4MDAxNywgc3RhdHJlZz0weDAyMTAs IGNhY2hlbG5zej04IChkd29yZHMpDQ0KCWxhdHRpbWVyPTB4NDAgKDE5MjAg bnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQ0N CglpbnRwaW49YywgaXJxPTEwDQ0KCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBE MCBEMSBEMiBEMyAgY3VycmVudCBEMA0NCmZvdW5kLT4JdmVuZG9yPTB4MTEw NiwgZGV2PTB4MzE3NywgcmV2aWQ9MHgwMA0NCglidXM9MCwgc2xvdD0xNywg ZnVuYz0wDQ0KCWNsYXNzPTA2LTAxLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2 PTENDQoJY21kcmVnPTB4MDA4Nywgc3RhdHJlZz0weDAyMTAsIGNhY2hlbG5z ej0wIChkd29yZHMpDQ0KCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9 MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQ0NCglwb3dlcnNwZWMg MiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDANDQppbnRlcnJ1cHQgYXRh X21hcHMNDQoJbWFwWzIwXTogdHlwZSA0LCByYW5nZSAzMiwgYmFzZSAwMDAw ZmMwMCwgc2l6ZSAgNCwgZW5hYmxlZA0NCmZvdW5kLT4JdmVuZG9yPTB4MTEw NiwgZGV2PTB4MDU3MSwgcmV2aWQ9MHgwNg0NCglidXM9MCwgc2xvdD0xNywg ZnVuYz0xDQ0KCWNsYXNzPTAxLTAxLThhLCBoZHJ0eXBlPTB4MDAsIG1mZGV2 PTANDQoJY21kcmVnPTB4MDAwNywgc3RhdHJlZz0weDAyOTAsIGNhY2hlbG5z ej0wIChkd29yZHMpDQ0KCWxhdHRpbWVyPTB4MjAgKDk2MCBucyksIG1pbmdu dD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpDQ0KCWludHBpbj1h LCBpcnE9MjU1DQ0KCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3Vy cmVudCBEMA0NCgltYXBbMTBdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAw MDBlODAwLCBzaXplICA4LCBlbmFibGVkDQ0KCW1hcFsxNF06IHR5cGUgMSwg cmFuZ2UgMzIsIGJhc2UgZmZhZmZjMDAsIHNpemUgIDgsIGVuYWJsZWQNDQpp bnRlcnJ1cHQgcmUtcm91dGUNDQokUElSOiAwOjE4IElOVEEgcm91dGVkIHRv IGlycSAxMQ0NCmZvdW5kLT4JdmVuZG9yPTB4MTEwNiwgZGV2PTB4MzA2NSwg cmV2aWQ9MHg3NA0NCglidXM9MCwgc2xvdD0xOCwgZnVuYz0wDQ0KCWNsYXNz PTAyLTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTANDQoJY21kcmVnPTB4 MDExNywgc3RhdHJlZz0weDAyMTAsIGNhY2hlbG5zej04IChkd29yZHMpDQ0K CWxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5nbnQ9MHgwMyAoNzUwIG5z KSwgbWF4bGF0PTB4MDggKDIwMDAgbnMpDQ0KCWludHBpbj1hLCBpcnE9MTEN DQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50 IEQwDQ0KYWdwMDogPFZJQSBHZW5lcmljIGhvc3QgdG8gUENJIGJyaWRnZT4g bWVtIDB4ZTAwMDAwMDAtMHhlMDNmZmZmZiBhdCBkZXZpY2UgMC4wIG9uIHBj aTANDQphZ3AwOiBSZXNlcnZlZCAweDQwMDAwMCBieXRlcyBmb3IgcmlkIDB4 MTAgdHlwZSAzIGF0IDB4ZTAwMDAwMDANDQphZ3AwOiBhbGxvY2F0aW5nIEdB VFQgZm9yIGFwZXJ0dXJlIG9mIHNpemUgMjI4TQ0NCnBjaWIxOiA8UENJLVBD SSBicmlkZ2U+IGF0IGRldmljZSAxLjAgb24gcGNpMA0NCnBjaWIxOiAgIHNl Y29uZGFyeSBidXMgICAgIDENDQpwY2liMTogICBzdWJvcmRpbmF0ZSBidXMg ICAxDQ0KcGNpYjE6ICAgSS9PIGRlY29kZSAgICAgICAgMHhmMDAwLTB4ZmZm DQ0KcGNpYjE6ICAgbWVtb3J5IGRlY29kZSAgICAgMHhmZjgwMDAwMC0weGZm OWZmZmZmDQ0KcGNpYjE6ICAgcHJlZmV0Y2hlZCBkZWNvZGUgMHhjZmYwMDAw MC0weGRmZWZmZmZmDQ0KcGNpMTogPFBDSSBidXM+IG9uIHBjaWIxDQ0KcGNp MTogcGh5c2ljYWwgYnVzPTENDQoJbWFwWzEwXTogdHlwZSAxLCByYW5nZSAz MiwgYmFzZSBmZjk4MDAwMCwgc2l6ZSAxOSwgZW5hYmxlZA0NCnBjaWIxOiBk ZXZpY2UgKG51bGwpIHJlcXVlc3RlZCBkZWNvZGVkIG1lbW9yeSByYW5nZSAw eGZmOTgwMDAwLTB4ZmY5ZmZmZmYNDQoJbWFwWzE0XTogdHlwZSAzLCByYW5n ZSAzMiwgYmFzZSBkMDAwMDAwMCwgc2l6ZSAyNywgZW5hYmxlZA0NCnBjaWIx OiBkZXZpY2UgKG51bGwpIHJlcXVlc3RlZCBkZWNvZGVkIG1lbW9yeSByYW5n ZSAweGQwMDAwMDAwLTB4ZDdmZmZmZmYNDQppbnRlcnJ1cHQgcmUtcm91dGUN DQokUElSOiAwOjEgSU5UQSByb3V0ZWQgdG8gaXJxIDExDQ0KcGNpYjE6IHNs b3QgMCBJTlRBIGlzIHJvdXRlZCB0byBpcnEgMTENDQpmb3VuZC0+CXZlbmRv cj0weDUzMzMsIGRldj0weDhkMDQsIHJldmlkPTB4MDANDQoJYnVzPTEsIHNs b3Q9MCwgZnVuYz0wDQ0KCWNsYXNzPTAzLTAwLTAwLCBoZHJ0eXBlPTB4MDAs IG1mZGV2PTANDQoJY21kcmVnPTB4MDAwNywgc3RhdHJlZz0weDAyMzAsIGNh Y2hlbG5zej04IChkd29yZHMpDQ0KCWxhdHRpbWVyPTB4NDAgKDE5MjAgbnMp LCBtaW5nbnQ9MHgwNCAoMTAwMCBucyksIG1heGxhdD0weGZmICg2Mzc1MCBu cykNDQoJaW50cGluPWEsIGlycT0xMQ0NCglwb3dlcnNwZWMgMiAgc3VwcG9y dHMgRDAgRDEgRDIgRDMgIGN1cnJlbnQgRDANDQpwY2kxOiA8ZGlzcGxheSwg VkdBPiBhdCBkZXZpY2UgMC4wIChubyBkcml2ZXIgYXR0YWNoZWQpDQ0KdWhj aTA6IDxWSUEgODNDNTcyIFVTQiBjb250cm9sbGVyPiBwb3J0IDB4ZTQwMC0w eGU0MWYgaXJxIDExIGF0IGRldmljZSAxNi4wIG9uIHBjaTANDQp1aGNpMDog UmVzZXJ2ZWQgMHgyMCBieXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0IGF0IDB4 ZTQwMA0NCnVoY2kwOiBbR0lBTlQtTE9DS0VEXQ0NCnVzYjA6IDxWSUEgODND NTcyIFVTQiBjb250cm9sbGVyPiBvbiB1aGNpMA0NCnVzYjA6IFVTQiByZXZp c2lvbiAxLjANDQp1aHViMDogVklBIFVIQ0kgcm9vdCBodWIsIGNsYXNzIDkv MCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxDQ0KdWh1YjA6IDIgcG9ydHMgd2l0 aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkDQ0KdWhjaTE6IDxWSUEgODND NTcyIFVTQiBjb250cm9sbGVyPiBwb3J0IDB4ZTQ4MC0weGU0OWYgaXJxIDUg YXQgZGV2aWNlIDE2LjEgb24gcGNpMA0NCnVoY2kxOiBSZXNlcnZlZCAweDIw IGJ5dGVzIGZvciByaWQgMHgyMCB0eXBlIDQgYXQgMHhlNDgwDQ0KdWhjaTE6 IFtHSUFOVC1MT0NLRURdDQ0KdXNiMTogPFZJQSA4M0M1NzIgVVNCIGNvbnRy b2xsZXI+IG9uIHVoY2kxDQ0KdXNiMTogVVNCIHJldmlzaW9uIDEuMA0NCnVo dWIxOiBWSUEgVUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8x LjAwLCBhZGRyIDENDQp1aHViMTogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxl LCBzZWxmIHBvd2VyZWQNDQp1aGNpMjogPFZJQSA4M0M1NzIgVVNCIGNvbnRy b2xsZXI+IHBvcnQgMHhlYzAwLTB4ZWMxZiBpcnEgMTAgYXQgZGV2aWNlIDE2 LjIgb24gcGNpMA0NCnVoY2kyOiBSZXNlcnZlZCAweDIwIGJ5dGVzIGZvciBy aWQgMHgyMCB0eXBlIDQgYXQgMHhlYzAwDQ0KdWhjaTI6IFtHSUFOVC1MT0NL RURdDQ0KdXNiMjogPFZJQSA4M0M1NzIgVVNCIGNvbnRyb2xsZXI+IG9uIHVo Y2kyDQ0KdXNiMjogVVNCIHJldmlzaW9uIDEuMA0NCnVodWIyOiBWSUEgVUhD SSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDEN DQp1aHViMjogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2Vy ZWQNDQppc2FiMDogPFBDSS1JU0EgYnJpZGdlPiBhdCBkZXZpY2UgMTcuMCBv biBwY2kwDQ0KaXNhMDogPElTQSBidXM+IG9uIGlzYWIwDQ0KYXRhcGNpMDog PEdFTkVSSUMgQVRBIGNvbnRyb2xsZXI+IHBvcnQgMHhmYzAwLTB4ZmMwZiww eDM3NiwweDE3MC0weDE3NywweDNmNiwweDFmMC0weDFmNyBhdCBkZXZpY2Ug MTcuMSBvbiBwY2kwDQ0KYXRhcGNpMDogUmVzZXJ2ZWQgMHgxMCBieXRlcyBm b3IgcmlkIDB4MjAgdHlwZSA0IGF0IDB4ZmMwMA0NCmF0YV9wcm9iZQ0NCmF0 YV9wcm9iZQ0NCmF0YV9wcm9iZSBvaw0NCmF0YTA6IGNoYW5uZWwgIzAgb24g YXRhcGNpMA0NCmF0YXBjaTA6IFJlc2VydmVkIDB4OCBieXRlcyBmb3Igcmlk IDB4MTAgdHlwZSA0IGF0IDB4MWYwDQ0KYXRhcGNpMDogUmVzZXJ2ZWQgMHgx IGJ5dGVzIGZvciByaWQgMHgxNCB0eXBlIDQgYXQgMHgzZjYNDQphdGFfYXR0 YWNoDQ0KYXRhX2F0dGFjaA0NCmF0YTA6IHJlc2V0IHRwMSBtYXNrPTAzIG9z dGF0MD01MCBvc3RhdDE9MDANDQphdGEwLW1hc3Rlcjogc3RhdD0weDUwIGVy cj0weDAxIGxzYj0weDAwIG1zYj0weDAwDQ0KYXRhMC1zbGF2ZTogIHN0YXQ9 MHgwMCBlcnI9MHgwMSBsc2I9MHgwMCBtc2I9MHgwMA0NCmF0YTA6IHJlc2V0 IHRwMiBzdGF0MD01MCBzdGF0MT0wMCBkZXZpY2VzPTB4MTxBVEFfTUFTVEVS Pg0NCmF0YTA6IFtNUFNBRkVdDQ0KYXRhX2F0dGFjaCBvazENDQphdGFfcHJv YmUNDQphdGFfcHJvYmUNDQphdGFfcHJvYmUgb2sNDQphdGExOiBjaGFubmVs ICMxIG9uIGF0YXBjaTANDQphdGFwY2kwOiBSZXNlcnZlZCAweDggYnl0ZXMg Zm9yIHJpZCAweDE4IHR5cGUgNCBhdCAweDE3MA0NCmF0YXBjaTA6IFJlc2Vy dmVkIDB4MSBieXRlcyBmb3IgcmlkIDB4MWMgdHlwZSA0IGF0IDB4Mzc2DQ0K YXRhX2F0dGFjaA0NCmF0YV9hdHRhY2gNDQphdGExOiByZXNldCB0cDEgbWFz az0wMyBvc3RhdDA9MjAgb3N0YXQxPTMwDQ0KYXRhMS1tYXN0ZXI6IHN0YXQ9 MHgyMCBlcnI9MHgyMCBsc2I9MHgyMCBtc2I9MHgyMA0NCmF0YTEtc2xhdmU6 ICBzdGF0PTB4MzAgZXJyPTB4MzAgbHNiPTB4MzAgbXNiPTB4MzANDQphdGEx OiByZXNldCB0cDIgc3RhdDA9MjAgc3RhdDE9MzAgZGV2aWNlcz0weDANDQph dGExOiBbTVBTQUZFXQ0NCmF0YV9hdHRhY2ggb2sxDQ0KdnIwOiA8VklBIFZU NjEwMiBSaGluZSBJSSAxMC8xMDBCYXNlVFg+IHBvcnQgMHhlODAwLTB4ZThm ZiBtZW0gMHhmZmFmZmMwMC0weGZmYWZmY2ZmIGlycSAxMSBhdCBkZXZpY2Ug MTguMCBvbiBwY2kwDQ0KdnIwOiBSZXNlcnZlZCAweDEwMCBieXRlcyBmb3Ig cmlkIDB4MTAgdHlwZSA0IGF0IDB4ZTgwMA0NCm1paWJ1czA6IDxNSUkgYnVz PiBvbiB2cjANDQp1a3BoeTA6IDxHZW5lcmljIElFRUUgODAyLjN1IG1lZGlh IGludGVyZmFjZT4gb24gbWlpYnVzMA0NCnVrcGh5MDogT1VJIDB4MDA0MDYz LCBtb2RlbCAweDAwMzIsIHJldi4gMTANDQp1a3BoeTA6ICAxMGJhc2VULCAx MGJhc2VULUZEWCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgtRkRYLCBhdXRvDQ0K dnIwOiBicGYgYXR0YWNoZWQNDQp2cjA6IEV0aGVybmV0IGFkZHJlc3M6IDAw OjExOjJmOmRjOmY3OmVkDQ0KdnIwOiBbTVBTQUZFXQ0NCmNwdTAgb24gbW90 aGVyYm9hcmQNDQphdGE6IGF0YTAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5n IGl0DQ0KYXRhOiBhdGExIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdA0N ClRyeWluZyBSZWFkX1BvcnQgYXQgMjAzDQ0KVHJ5aW5nIFJlYWRfUG9ydCBh dCAyNDMNDQpUcnlpbmcgUmVhZF9Qb3J0IGF0IDI4Mw0NClRyeWluZyBSZWFk X1BvcnQgYXQgMmMzDQ0KVHJ5aW5nIFJlYWRfUG9ydCBhdCAzMDMNDQpUcnlp bmcgUmVhZF9Qb3J0IGF0IDM0Mw0NClRyeWluZyBSZWFkX1BvcnQgYXQgMzgz DQ0KVHJ5aW5nIFJlYWRfUG9ydCBhdCAzYzMNDQpleF9pc2FfaWRlbnRpZnko KQ0NCnVua25vd246IHN0YXR1cyByZWcgdGVzdCBmYWlsZWQgZmYNDQp1bmtu b3duOiBzdGF0dXMgcmVnIHRlc3QgZmFpbGVkIGZmDQ0KdW5rbm93bjogc3Rh dHVzIHJlZyB0ZXN0IGZhaWxlZCBmZg0NCnVua25vd246IHN0YXR1cyByZWcg dGVzdCBmYWlsZWQgZmYNDQp1bmtub3duOiBzdGF0dXMgcmVnIHRlc3QgZmFp bGVkIGZmDQ0KdW5rbm93bjogc3RhdHVzIHJlZyB0ZXN0IGZhaWxlZCBmZg0N CnBucGJpb3M6IDEyIGRldmljZXMsIGxhcmdlc3QgMTk0IGJ5dGVzDQ0KUE5Q MGMwMTogYWRkaW5nIGZpeGVkIG1lbW9yeTMyIHJhbmdlIDAtMHg5ZmJmZiwg c2l6ZT0weDlmYzAwDQ0KUE5QMGMwMTogYWRkaW5nIGZpeGVkIG1lbW9yeTMy IHJhbmdlIDB4OWZjMDAtMHg5ZmZmZiwgc2l6ZT0weDQwMA0NClBOUDBjMDE6 IGFkZGluZyBmaXhlZCBtZW1vcnkzMiByYW5nZSAweGU4MDAwLTB4ZmZmZmYs IHNpemU9MHgxODAwMA0NClBOUDBjMDE6IGFkZGluZyBmaXhlZCBtZW1vcnkz MiByYW5nZSAweDEwMDAwMC0weGY3MmZmZmYsIHNpemU9MHhmNjMwMDAwDQ0K UE5QMGMwMTogYWRkaW5nIGZpeGVkIG1lbW9yeTMyIHJhbmdlIDB4ZjczMDAw MC0weGY3M2ZmZmYsIHNpemU9MHgxMDAwMA0NClBOUDBjMDE6IGFkZGluZyBm aXhlZCBtZW1vcnkzMiByYW5nZSAweGY3NDAwMDAtMHhmN2VmZmZmLCBzaXpl PTB4YjAwMDANDQpQTlAwYzAxOiBhZGRpbmcgZml4ZWQgbWVtb3J5MzIgcmFu Z2UgMHhmN2YwMDAwLTB4ZjdmZmZmZiwgc2l6ZT0weDEwMDAwDQ0KUE5QMGMw MTogYWRkaW5nIGZpeGVkIG1lbW9yeTMyIHJhbmdlIDB4ZmZiYzAwMDAtMHhm ZmZmZmZmZiwgc2l6ZT0weDQ0MDAwMA0NCnBucGJpb3M6IGhhbmRsZSAwIGRl dmljZSBJRCBQTlAwYzAxICgwMTBjZDA0MSkNDQpQTlAwMjAwOiBhZGRpbmcg ZG1hIG1hc2sgMHgxMA0NClBOUDAyMDA6IGFkZGluZyBpbyByYW5nZSAwLTB4 Ziwgc2l6ZT0weDEwLCBhbGlnbj0weDENDQpQTlAwMjAwOiBhZGRpbmcgaW8g cmFuZ2UgMHg4MC0weDkwLCBzaXplPTB4MTEsIGFsaWduPTB4MQ0NClBOUDAy MDA6IGFkZGluZyBpbyByYW5nZSAweDk0LTB4OWYsIHNpemU9MHhjLCBhbGln bj0weDENDQpQTlAwMjAwOiBhZGRpbmcgaW8gcmFuZ2UgMHhjMC0weGRlLCBz aXplPTB4MWYsIGFsaWduPTB4MQ0NCnBucGJpb3M6IGhhbmRsZSAyIGRldmlj ZSBJRCBQTlAwMjAwICgwMDAyZDA0MSkNDQpQTlAwMTAwOiBhZGRpbmcgaXJx IG1hc2sgMHgxDQ0KUE5QMDEwMDogYWRkaW5nIGlvIHJhbmdlIDB4NDAtMHg0 Mywgc2l6ZT0weDQsIGFsaWduPTB4MQ0NCnBucGJpb3M6IGhhbmRsZSAzIGRl dmljZSBJRCBQTlAwMTAwICgwMDAxZDA0MSkNDQpQTlAwYjAwOiBhZGRpbmcg aXJxIG1hc2sgMHgxMDANDQpQTlAwYjAwOiBhZGRpbmcgaW8gcmFuZ2UgMHg3 MC0weDcxLCBzaXplPTB4MiwgYWxpZ249MHgxDQ0KcG5wYmlvczogaGFuZGxl IDQgZGV2aWNlIElEIFBOUDBiMDAgKDAwMGJkMDQxKQ0NCnBucGJpb3M6IGhh bmRsZSA1IGRldmljZSBJRCBQTlAwYTAzICgwMzBhZDA0MSkNDQpQTlAwODAw OiBhZGRpbmcgaW8gcmFuZ2UgMHg2MS0weDYxLCBzaXplPTB4MSwgYWxpZ249 MHgxDQ0KcG5wYmlvczogaGFuZGxlIDYgZGV2aWNlIElEIFBOUDA4MDAgKDAw MDhkMDQxKQ0NClBOUDBjMDQ6IGFkZGluZyBpcnEgbWFzayAweDIwMDANDQpQ TlAwYzA0OiBhZGRpbmcgaW8gcmFuZ2UgMHhmMC0weGZmLCBzaXplPTB4MTAs IGFsaWduPTB4MQ0NCnBucGJpb3M6IGhhbmRsZSA3IGRldmljZSBJRCBQTlAw YzA0ICgwNDBjZDA0MSkNDQpQTlAwNTAxOiBhZGRpbmcgaW8gcmFuZ2UgMHgz ZjgtMHgzZmYsIHNpemU9MHg4LCBhbGlnbj0weDgNDQpQTlAwNTAxOiBhZGRp bmcgaXJxIG1hc2sgMHgxMA0NCnBucGJpb3M6IGhhbmRsZSA4IGRldmljZSBJ RCBQTlAwNTAxICgwMTA1ZDA0MSkNDQpQTlAwYzAyOiBhZGRpbmcgaW8gcmFu Z2UgMHg0ZDAtMHg0ZDEsIHNpemU9MHgyLCBhbGlnbj0weDENDQpQTlAwYzAy OiBhZGRpbmcgaW8gcmFuZ2UgMHhjZjgtMHhjZmYsIHNpemU9MHg4LCBhbGln bj0weDENDQpQTlAwYzAyOiBhZGRpbmcgaW8gcmFuZ2UgMHgyZS0weDJlLCBz aXplPTB4MSwgYWxpZ249MHgxDQ0KUE5QMGMwMjogYWRkaW5nIGlvIHJhbmdl IDB4MmYtMHgyZiwgc2l6ZT0weDEsIGFsaWduPTB4MQ0NClBOUDBjMDI6IGFk ZGluZyBpbyByYW5nZSAweDY4MC0weDY4Ziwgc2l6ZT0weDEwLCBhbGlnbj0w eDENDQpQTlAwYzAyOiBhZGRpbmcgaW8gcmFuZ2UgMHg3ODAtMHg3OGYsIHNp emU9MHgxMCwgYWxpZ249MHgxDQ0KUE5QMGMwMjogYWRkaW5nIGlvIHJhbmdl IDB4ODgwLTB4ODhmLCBzaXplPTB4MTAsIGFsaWduPTB4MQ0NClBOUDBjMDI6 IGFkZGluZyBpbyByYW5nZSAweDI5MC0weDJjZiwgc2l6ZT0weDQwLCBhbGln bj0weDENDQpwbnBiaW9zOiBoYW5kbGUgOSBkZXZpY2UgSUQgUE5QMGMwMiAo MDIwY2QwNDEpDQ0KcG5wYmlvczogaGFuZGxlIDEwIGRldmljZSBJRCBQTlAw YzAyICgwMjBjZDA0MSkNDQpQTlAwMzAzOiBhZGRpbmcgaXJxIG1hc2sgMHgy DQ0KUE5QMDMwMzogYWRkaW5nIGlvIHJhbmdlIDB4NjAtMHg2MCwgc2l6ZT0w eDEsIGFsaWduPTB4MQ0NClBOUDAzMDM6IGFkZGluZyBpbyByYW5nZSAweDY0 LTB4NjQsIHNpemU9MHgxLCBhbGlnbj0weDENDQpwbnBiaW9zOiBoYW5kbGUg MTEgZGV2aWNlIElEIFBOUDAzMDMgKDAzMDNkMDQxKQ0NCmFoY19pc2FfcHJv YmUgMTQ6IGlvcG9ydCAweGVjMDAgYWxsb2MgZmFpbGVkDQ0Kc2M6IHNjMCBh bHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQNDQp2Z2E6IHZnYTAgYWxyZWFk eSBleGlzdHM7IHNraXBwaW5nIGl0DQ0KaXNhX3Byb2JlX2NoaWxkcmVuOiBk aXNhYmxpbmcgUG5QIGRldmljZXMNDQppc2FfcHJvYmVfY2hpbGRyZW46IHBy b2Jpbmcgbm9uLVBuUCBkZXZpY2VzDQ0Kb3JtMDogPElTQSBPcHRpb24gUk9N PiBhdCBpb21lbSAweGMwMDAwLTB4Y2JmZmYgb24gaXNhMA0NCnBtdGltZXIw IG9uIGlzYTANDQphZHYwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkNDQphaGEw OiBub3QgcHJvYmVkIChkaXNhYmxlZCkNDQphaWMwOiBub3QgcHJvYmVkIChk aXNhYmxlZCkNDQphdGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgw NDIpPiBhdCBwb3J0IDB4NjQsMHg2MCBvbiBpc2EwDQ0KYXRrYmQwOiA8QVQg S2V5Ym9hcmQ+IGlycSAxIG9uIGF0a2JkYzANDQprYmQwIGF0IGF0a2JkMA0N CmtiZDA6IGF0a2JkMCwgZ2VuZXJpYyAoMCksIGNvbmZpZzoweDAsIGZsYWdz OjB4MWYwMDAwDQ0KYXRrYmQwOiBbR0lBTlQtTE9DS0VEXQ0NCnBzbTA6IGN1 cnJlbnQgY29tbWFuZCBieXRlOjAwNjUNDQprYmRjOiBURVNUX0FVWF9QT1JU IHN0YXR1czowMDAwDQ0Ka2JkYzogUkVTRVRfQVVYIHJldHVybiBjb2RlOjAw ZmUNDQprYmRjOiBSRVNFVF9BVVggcmV0dXJuIGNvZGU6MDBmZQ0NCmtiZGM6 IFJFU0VUX0FVWCByZXR1cm4gY29kZTowMGZlDQ0Ka2JkYzogRElBR05PU0Ug c3RhdHVzOjAwNTUNDQprYmRjOiBURVNUX0tCRF9QT1JUIHN0YXR1czowMDAw DQ0KcHNtMDogZmFpbGVkIHRvIHJlc2V0IHRoZSBhdXggZGV2aWNlLg0NCmJ0 MDogbm90IHByb2JlZCAoZGlzYWJsZWQpDQ0KY3MwOiBub3QgcHJvYmVkIChk aXNhYmxlZCkNDQplZDA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQ0NCmZkYzAg ZmFpbGVkIHRvIHByb2JlIGF0IHBvcnQgMHgzZjAtMHgzZjUgaXJxIDYgZHJx IDIgb24gaXNhMA0NCmZlMDogbm90IHByb2JlZCAoZGlzYWJsZWQpDQ0KaWUw OiBub3QgcHJvYmVkIChkaXNhYmxlZCkNDQpsbmMwOiBub3QgcHJvYmVkIChk aXNhYmxlZCkNDQpwY2ljMCBmYWlsZWQgdG8gcHJvYmUgYXQgcG9ydCAweDNl MCBpb21lbSAweGQwMDAwIG9uIGlzYTANDQpwY2ljMTogbm90IHByb2JlZCAo ZGlzYWJsZWQpDQ0KcHBjMDogcGFyYWxsZWwgcG9ydCBub3QgZm91bmQuDQ0K cHBjMDogPFBhcmFsbGVsIHBvcnQ+IGZhaWxlZCB0byBwcm9iZSBhdCBpcnEg NyBvbiBpc2EwDQ0Kc2MwOiA8U3lzdGVtIGNvbnNvbGU+IGF0IGZsYWdzIDB4 MTAwIG9uIGlzYTANDQpzYzA6IFZHQSA8MTYgdmlydHVhbCBjb25zb2xlcywg ZmxhZ3M9MHgxMDA+DQ0Kc2MwOiBmYjAsIGtiZDAsIHRlcm1pbmFsIGVtdWxh dG9yOiBzYyAoc3lzY29ucyB0ZXJtaW5hbCkNDQpzaW8wOiBjb25maWd1cmVk IGlycSA0IG5vdCBpbiBiaXRtYXAgb2YgcHJvYmVkIGlycXMgMA0NCnNpbzA6 IHBvcnQgbWF5IG5vdCBiZSBlbmFibGVkDQ0Kc2lvMDogaXJxIG1hcHM6IDAg MCAwIDANDQpzaW8wIGF0IHBvcnQgMHgzZjgtMHgzZmYgaXJxIDQgZmxhZ3Mg MHgxMCBvbiBpc2EwDQ0Kc2lvMDogdHlwZSAxNjU1MEEsIGNvbnNvbGUNDQpz aW8xOiBjb25maWd1cmVkIGlycSAzIG5vdCBpbiBiaXRtYXAgb2YgcHJvYmVk IGlycXMgMA0NCnNpbzE6IHBvcnQgbWF5IG5vdCBiZSBlbmFibGVkDQ0Kc2lv MTogaXJxIG1hcHM6IDAgMCAwIDANDQpzaW8xOiBwcm9iZSBmYWlsZWQgdGVz dChzKTogMCAxIDIgNCA2IDcgOQ0NCnNpbzEgZmFpbGVkIHRvIHByb2JlIGF0 IHBvcnQgMHgyZjgtMHgyZmYgaXJxIDMgb24gaXNhMA0NCnNpbzI6IG5vdCBw cm9iZWQgKGRpc2FibGVkKQ0NCnNpbzM6IG5vdCBwcm9iZWQgKGRpc2FibGVk KQ0NCnNuMDogbm90IHByb2JlZCAoZGlzYWJsZWQpDQ0KdmdhMDogPEdlbmVy aWMgSVNBIFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBpb21lbSAweGEwMDAw LTB4YmZmZmYgb24gaXNhMA0NCmZiMDogdmdhMCwgdmdhLCB0eXBlOlZHQSAo NSksIGZsYWdzOjB4NzAwN2YNDQpmYjA6IHBvcnQ6MHgzYzAtMHgzZGYsIGNy dGM6MHgzZDQsIG1lbToweGEwMDAwIDB4MjAwMDANDQpmYjA6IGluaXQgbW9k ZToyNCwgYmlvcyBtb2RlOjMsIGN1cnJlbnQgbW9kZToyNA0NCmZiMDogd2lu ZG93OjB4YzAwYjgwMDAgc2l6ZTozMmsgZ3JhbjozMmssIGJ1ZjowIHNpemU6 MzJrDQ0KVkdBIHBhcmFtZXRlcnMgdXBvbiBwb3dlci11cA0NCjUwIDE4IDEw IDAwIDAwIDAwIDAzIDAwIDAyIDY3IDVmIDRmIDUwIDgyIDU1IDgxIA0NCmJm IDFmIDAwIDRmIDBkIDBlIDAwIDAwIDA1IGEwIDljIDBlIDhmIDI4IDFmIDk2 IA0NCmI5IGEzIGZmIDAwIDAxIDAyIDAzIDA0IDA1IDE0IDA3IDM4IDM5IDNh IDNiIDNjIA0NCjNkIDNlIDNmIDBjIDAwIDBmIDA4IDAwIDAwIDAwIDAwIDAw IDEwIDBlIDAwIGZmIA0NClZHQSBwYXJhbWV0ZXJzIGluIEJJT1MgZm9yIG1v ZGUgMjQNDQo1MCAxOCAxMCAwMCAxMCAwMCAwMyAwMCAwMiA2NyA1ZiA0ZiA1 MCA4MiA1NSA4MSANDQpiZiAxZiAwMCA0ZiAwZCAwZSAwMCAwMCAwMCAwMCA5 YyA4ZSA4ZiAyOCAxZiA5NiANDQpiOSBhMyBmZiAwMCAwMSAwMiAwMyAwNCAw NSAxNCAwNyAzOCAzOSAzYSAzYiAzYyANDQozZCAzZSAzZiAwYyAwMCAwZiAw OCAwMCAwMCAwMCAwMCAwMCAxMCAwZSAwMCBmZiANDQpFR0EvVkdBIHBhcmFt ZXRlcnMgdG8gYmUgdXNlZCBmb3IgbW9kZSAyNA0NCjUwIDE4IDEwIDAwIDAw IDAwIDAzIDAwIDAyIDY3IDVmIDRmIDUwIDgyIDU1IDgxIA0NCmJmIDFmIDAw IDRmIDBkIDBlIDAwIDAwIDA1IGEwIDljIDBlIDhmIDI4IDFmIDk2IA0NCmI5 IGEzIGZmIDAwIDAxIDAyIDAzIDA0IDA1IDE0IDA3IDM4IDM5IDNhIDNiIDNj IA0NCjNkIDNlIDNmIDBjIDAwIDBmIDA4IDAwIDAwIDAwIDAwIDAwIDEwIDBl IDAwIGZmIA0NCnZ0MDogbm90IHByb2JlZCAoZGlzYWJsZWQpDQ0KaXNhX3By b2JlX2NoaWxkcmVuOiBwcm9iaW5nIFBuUCBkZXZpY2VzDQ0KYWR2MTogSW52 YWxpZCBiYXNlcG9ydCBvZiAweDAgc3BlY2lmaWVkLiBOZWFyZXN0IHZhbGlk IGJhc2Vwb3J0IGlzIDB4MTAwLiAgRmFpbGluZyBwcm9iZS4NDQphZHYxOiBJ bnZhbGlkIGJhc2Vwb3J0IG9mIDB4NDAgc3BlY2lmaWVkLiBOZWFyZXN0IHZh bGlkIGJhc2Vwb3J0IGlzIDB4MTAwLiAgRmFpbGluZyBwcm9iZS4NDQphZHYx OiBJbnZhbGlkIGJhc2Vwb3J0IG9mIDB4NzAgc3BlY2lmaWVkLiBOZWFyZXN0 IHZhbGlkIGJhc2Vwb3J0IGlzIDB4MTAwLiAgRmFpbGluZyBwcm9iZS4NDQph ZHYxOiBJbnZhbGlkIGJhc2Vwb3J0IG9mIDB4NjEgc3BlY2lmaWVkLiBOZWFy ZXN0IHZhbGlkIGJhc2Vwb3J0IGlzIDB4MTAwLiAgRmFpbGluZyBwcm9iZS4N DQp1bmtub3duOiA8UE5QMDgwMD4gZmFpbGVkIHRvIHByb2JlIGF0IHBvcnQg MHg2MSBvbiBpc2EwDQ0KYWR2MTogSW52YWxpZCBiYXNlcG9ydCBvZiAweGYw IHNwZWNpZmllZC4gTmVhcmVzdCB2YWxpZCBiYXNlcG9ydCBpcyAweDEwMC4g IEZhaWxpbmcgcHJvYmUuDQ0KdW5rbm93bjogPFBOUDA1MDE+IGNhbid0IGFz c2lnbiByZXNvdXJjZXMgKHBvcnQpDQ0KdW5rbm93bjogPFBOUDA1MDE+IGF0 IHBvcnQgMHgzZjgtMHgzZmYgb24gaXNhMA0NCmFkdjE6IEludmFsaWQgYmFz ZXBvcnQgb2YgMHg0ZDAgc3BlY2lmaWVkLiBOZWFyZXN0IHZhbGlkIGJhc2Vw b3J0IGlzIDB4MzMwLiAgRmFpbGluZyBwcm9iZS4NDQp1bmtub3duOiA8UE5Q MDMwMz4gY2FuJ3QgYXNzaWduIHJlc291cmNlcyAocG9ydCkNDQp1bmtub3du OiA8UE5QMDMwMz4gYXQgcG9ydCAweDYwIG9uIGlzYTANDQpEZXZpY2UgY29u ZmlndXJhdGlvbiBmaW5pc2hlZC4NDQpwcm9jZnMgcmVnaXN0ZXJlZA0NClRp bWVjb3VudGVyICJUU0MiIGZyZXF1ZW5jeSAyMjY0NzYyMDMyIEh6IHF1YWxp dHkgODAwDQ0KVGltZWNvdW50ZXJzIHRpY2sgZXZlcnkgMTAuMDAwIG1zZWMN DQpsbzA6IGJwZiBhdHRhY2hlZA0NCmF0YV9ib290X2F0dGFjaA0NCmF0YV9p ZGVudGlmeQ0NCmF0YV9nZXRwYXJhbQ0NCmF0YTAtbWFzdGVyOiByZXE9MHhj MTZhMzAwMCBBVEFfSURFTlRJRlkgcXVldWVkDQ0KYXRhMC1tYXN0ZXI6IHJl cT0weGMxNmEzMDAwIEFUQV9JREVOVElGWSBzdGFydGluZw0NCmF0YTAtbWFz dGVyOiByZXE9MHhjMTZhMzAwMCBBVEFfSURFTlRJRlkgYmVnaW4gdHJhbnNh Y3Rpb24NDQphdGEwLW1hc3RlcjogcmVxPTB4YzE2YTMwMDAgQVRBX0lERU5U SUZZIHdhaXQgZm9yIGNvbXBsZXRpdGlvbg0NCmF0YTAtbWFzdGVyOiByZXE9 MHhjMTZhMzAwMCBBVEFfSURFTlRJRlkgdGltZW91dA0NCmF0YTAtbWFzdGVy OiByZXE9MHhjMTZhMzAwMCBBVEFfSURFTlRJRlkgZW5kIHRyYW5zYWN0aW9u DQ0KYXRhMC1tYXN0ZXI6IHJlcT0weGMxNmEzMDAwIEFUQV9JREVOVElGWSBm aW5pc2ggdGFza3F1ZXVlX3RocmVhZA0NCmF0YTAtbWFzdGVyOiByZXE9MHhj MTZhMzAwMCBBVEFfSURFTlRJRlkgY29tcGxldGVkIGVudGVyZWQNDQphdGFf cmVpbml0DQ0KYXRhX3JlaW5pdA0NCmF0YTA6IHJlaW5pdGluZyBjaGFubmVs IC4uDQ0KYXRhMDogcmVzZXQgdHAxIG1hc2s9MDMgb3N0YXQwPTUwIG9zdGF0 MT0wMA0NCmF0YTAtbWFzdGVyOiBzdGF0PTB4NTAgZXJyPTB4MDEgbHNiPTB4 MDAgbXNiPTB4MDANDQphdGEwLXNsYXZlOiAgc3RhdD0weDAwIGVycj0weDAx IGxzYj0weDAwIG1zYj0weDAwDQ0KYXRhMDogcmVzZXQgdHAyIHN0YXQwPTUw IHN0YXQxPTAwIGRldmljZXM9MHgxPEFUQV9NQVNURVI+DQ0KYXRhMDogcmVz ZXR0aW5nIGRvbmUgLi4NDQphdGFfaWRlbnRpZnkNDQphdGFfZ2V0cGFyYW0N DQphdGEwLW1hc3RlcjogcmVxPTB4YzE2YTJlMTAgQVRBX0lERU5USUZZIGJl Z2luIHRyYW5zYWN0aW9uDQ0KYXRhMC1tYXN0ZXI6IHJlcT0weGMxNmEyZTEw IEFUQV9JREVOVElGWSB3YWl0IGZvciBjb21wbGV0aXRpb24NDQphdGEwLW1h c3RlcjogcmVxPTB4YzE2YTJlMTAgQVRBX0lERU5USUZZIHRpbWVvdXQNDQph dGEwLW1hc3RlcjogcmVxPTB4YzE2YTJlMTAgQVRBX0lERU5USUZZIGVuZCB0 cmFuc2FjdGlvbg0NCmF0YTAtbWFzdGVyOiByZXE9MHhjMTZhMmUxMCBBVEFf SURFTlRJRlkgZmluaXNoIGRpcmVjdGx5DQ0KYXRhMC1tYXN0ZXI6IHJlcT0w eGMxNmEyZTEwIEFUQV9JREVOVElGWSBjb21wbGV0ZWQgZW50ZXJlZA0NCmF0 YV9yZWluaXQNDQphdGFfcmVpbml0DQ0KYXRhMDogcmVpbml0aW5nIGNoYW5u ZWwgLi4NDQphdGEwLW1hc3RlcjogRkFJTFVSRSAtIEFUQV9JREVOVElGWSB0 aW1lZCBvdXQNDQphdGEwLW1hc3RlcjogcmVxPTB4YzE2YTJlMTAgQVRBX0lE RU5USUZZIGNvbXBsZXRlZCBjYWxsYmFjay93YWtldXANDQphdGEwLW1hc3Rl cjogcmVxPTB4YzE2YTJlMTAgQVRBX0lERU5USUZZIGJlZ2luIHRyYW5zYWN0 aW9uDQ0KYXRhMC1tYXN0ZXI6IHJlcT0weGMxNmEyZTEwIEFUQV9JREVOVElG WSB3YWl0IGZvciBjb21wbGV0aXRpb24NDQphdGEwLW1hc3RlcjogcmVxPTB4 YzE2YTJlMTAgQVRBX0lERU5USUZZIHRpbWVvdXQNDQphdGEwLW1hc3Rlcjog cmVxPTB4YzE2YTJlMTAgQVRBX0lERU5USUZZIGVuZCB0cmFuc2FjdGlvbg0N CmF0YTAtbWFzdGVyOiByZXE9MHhjMTZhMmUxMCBBVEFfSURFTlRJRlkgZmlu aXNoIGRpcmVjdGx5DQ0KYXRhMC1tYXN0ZXI6IHJlcT0weGMxNmEyZTEwIEFU QV9JREVOVElGWSBjb21wbGV0ZWQgZW50ZXJlZA0NCmF0YV9yZWluaXQNDQph dGFfcmVpbml0DQ0KYXRhMDogcmVpbml0aW5nIGNoYW5uZWwgLi4NDQphdGEw LW1hc3RlcjogRkFJTFVSRSAtIEFUQV9JREVOVElGWSB0aW1lZCBvdXQNDQph dGEwLW1hc3RlcjogcmVxPTB4YzE2YTJlMTAgQVRBX0lERU5USUZZIGNvbXBs ZXRlZCBjYWxsYmFjay93YWtldXANDQphdGFfZ2V0cGFyYW0gb2sNDQphdGFf aWRlbnRpZnkgb2sNDQphdGEwOiBkZXZpY2UgY29uZmlnIGRvbmUgLi4NDQph dGFfcmVpbml0IG9rDQ0KYXRhMC1tYXN0ZXI6IEZBSUxVUkUgLSBBVEFfSURF TlRJRlkgdGltZWQgb3V0DQ0KYXRhMC1tYXN0ZXI6IHJlcT0weGMxNmEzMDAw IEFUQV9JREVOVElGWSBjb21wbGV0ZWQgY2FsbGJhY2svd2FrZXVwDQ0KYXRh MC1tYXN0ZXI6IHJlcT0weGMxNmEzMDAwIEFUQV9JREVOVElGWSBxdWV1ZWQN DQphdGEwLW1hc3RlcjogcmVxPTB4YzE2YTMwMDAgQVRBX0lERU5USUZZIHN0 YXJ0aW5nDQ0KYXRhMC1tYXN0ZXI6IHJlcT0weGMxNmEzMDAwIEFUQV9JREVO VElGWSBmaW5pc2ggdGFza3F1ZXVlX3RocmVhZA0NCmF0YTAtbWFzdGVyOiBy ZXE9MHhjMTZhMzAwMCBBVEFfSURFTlRJRlkgd2FpdCBmb3IgY29tcGxldGl0 aW9uDQ0KYXRhMC1tYXN0ZXI6IHJlcT0weGMxNmEzMDAwIEFUQV9JREVOVElG WSBjb21wbGV0ZWQgZW50ZXJlZA0NCmF0YTAtbWFzdGVyOiByZXE9MHhjMTZh MzAwMCBBVEFfSURFTlRJRlkgY29tcGxldGVkIGNhbGxiYWNrL3dha2V1cA0N CmF0YV9nZXRwYXJhbSBvaw0NCmF0YV9pZGVudGlmeSBvaw0NCmF0YV9pZGVu dGlmeQ0NCmF0YV9pZGVudGlmeSBvaw0NCmF0YV9ib290X2F0dGFjaCBvaw0N CmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDEgKElTQSBJUlEgMSkgdG8gY2x1 c3RlciAwDQ0KaW9hcGljMDogcm91dGluZyBpbnRwaW4gNCAoSVNBIElSUSA0 KSB0byBjbHVzdGVyIDANDQppb2FwaWMwOiByb3V0aW5nIGludHBpbiA4IChJ U0EgSVJRIDgpIHRvIGNsdXN0ZXIgMA0NCmlvYXBpYzA6IHJvdXRpbmcgaW50 cGluIDEzIChJU0EgSVJRIDEzKSB0byBjbHVzdGVyIDANDQppb2FwaWMwOiBy b3V0aW5nIGludHBpbiAxNCAoSVNBIElSUSAxNCkgdG8gY2x1c3RlciAwDQ0K aW9hcGljMDogcm91dGluZyBpbnRwaW4gMTUgKElTQSBJUlEgMTUpIHRvIGNs dXN0ZXIgMA0NCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE2IChJU0EgSVJR IDExKSB0byBjbHVzdGVyIDANDQppb2FwaWMwOiByb3V0aW5nIGludHBpbiAy MSAoSVNBIElSUSAxMCkgdG8gY2x1c3RlciAwDQ0KTW91bnRpbmcgcm9vdCBm cm9tIHVmczovZGV2L2FkMHMxYQ0NCnNldHJvb3RieW5hbWUgZmFpbGVkDQ0K ZmZzX21vdW50cm9vdDogY2FuJ3QgZmluZCByb290dnANDQpSb290IG1vdW50 IGZhaWxlZDogNg0NCg0NCk1hbnVhbCByb290IGZpbGVzeXN0ZW0gc3BlY2lm aWNhdGlvbjoNDQogIDxmc3R5cGU+OjxkZXZpY2U+ICBNb3VudCA8ZGV2aWNl PiB1c2luZyBmaWxlc3lzdGVtIDxmc3R5cGU+DQ0KICAgICAgICAgICAgICAg ICAgICAgICBlZy4gdWZzOmRhMHMxYQ0NCiAgPyAgICAgICAgICAgICAgICAg IExpc3QgdmFsaWQgZGlzayBib290IGRldmljZXMNDQogIDxlbXB0eSBsaW5l PiAgICAgICBBYm9ydCBtYW51YWwgaW5wdXQNDQoNDQptb3VudHJvb3Q+IA0N CnBhbmljOiBSb290IG1vdW50IGZhaWxlZCwgc3RhcnR1cCBhYm9ydGVkLg0N ClVwdGltZTogMjVzDQ0KYXRhX3NodXRkb3duDQ0KYXRhX3NodXRkb3duIG9r DQ0KQ2Fubm90IGR1bXAuIE5vIGR1bXAgZGV2aWNlIGRlZmluZWQuDQ0KQXV0 b21hdGljIHJlYm9vdCBpbiAxNSBzZWNvbmRzIC0gcHJlc3MgYSBrZXkgb24g dGhlIGNvbnNvbGUgdG8gYWJvcnQNDQoNCg== --0-1470598922-1107786476=:1626-- From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 7 14:38:29 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 609B516A4CE for ; Mon, 7 Feb 2005 14:38:29 +0000 (GMT) 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 8AF9F43D41 for ; Mon, 7 Feb 2005 14:38:28 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id j17EcOSR078821; Mon, 7 Feb 2005 15:38:27 +0100 (CET) (envelope-from sos@DeepCore.dk) Message-ID: <42077D4E.1030604@DeepCore.dk> Date: Mon, 07 Feb 2005 15:38:06 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Luiz Otavio Souza References: <20050206222416.O88635@serv-qmp.walk.com.br> <42071856.5080205@DeepCore.dk> <20050207122355.N1626@serv-qmp.walk.com.br> In-Reply-To: <20050207122355.N1626@serv-qmp.walk.com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-mail-scanned: by DeepCore Virus & Spam killer v1.6 cc: freebsd-hackers@freebsd.org Subject: Re: ATA_IDENTIFY timed out on ASUS P4VP-MX X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2005 14:38:29 -0000 Luiz Otavio Souza wrote: > I tried the patch, and just get a different warning. >=20 > i'm attaching two dmesg, one with 5.3-RELEASE (with some extra debug=20 > info) and one for ATA-mIII. Hmm, seems interrupt arent getting through, not much I can do about that = one. Maybe -current can help as its interrupt routing code has changed=20 quite a bit. Otherwise try to get ahold of an updated BIOS ... --=20 -S=F8ren From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 7 15:22:57 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D7E316A4CE; Mon, 7 Feb 2005 15:22:57 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id B146343D48; Mon, 7 Feb 2005 15:22:56 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id 0E62C46B11; Mon, 7 Feb 2005 10:22:56 -0500 (EST) Date: Mon, 7 Feb 2005 15:21:57 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: ALeine In-Reply-To: <200502061806.j16I64bE037040@marlena.vvi.at> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org cc: k-sasaki@ist.osaka-u.ac.jp cc: freebsd-current@freebsd.org Subject: Re: FW: Call for comments: CoxR, a CVS/mail-lists/BTS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2005 15:22:57 -0000 On Sun, 6 Feb 2005, ALeine wrote: > Oh come, FreeBSD 5.x does have a mutex hell going on, but to say it has > so many bugs as to require a truck is absurd. :-> A smaller lorry > perhaps, but a truck - definitely not. :-) It might also be a good idea > to use an automated spell-check on your pages, I've noticed a number of > typos such as "divelopers" and similar. I appreciate that not everyone is a fan of mutex synchronization, but "mutex hell" is a bit of an odd description: most bugs I see getting reported (and fixed) aren't even locking-related. They're generally a property of lack of testing exposure for more obscure features or edge cases that are hard to test for without a wide testing base, such as edge-case hardware, bugs associated with longer run times, or a recently introduced feature, etc. Generally speaking, in the last week, I saw a couple of classes of bug fix fly by in commits, in order of frequency of occurence: - Minor device driver bugs involving alignment, feature mapping for device IDs, attach/detach bugs, error handling, etc. In one case, the bug was that a device driver was able to run MPSAFE, but the flag was set incorrectly to not let it. As usual, a moderate amount of change in ACPI. This was the vast majority of bug fixes. - Network stack logical errors or C-related errors: generally, doing something wrong with mbufs or routing. Mostly "syntax" and not "semantics", although a couple of netflow bugs that were more serious and the result of more broad exposure since its commit (last month?). - Scheduling related bugs in ULE -- Jeff MFC'd a number of fixes to RELENG_5 for the first time in several months, so there was some backlog, but I think it's not unusual to see a trickle of scheduling related changes, so isn't entirely unrepresentative. - VFS/file system bugs -- a couple were locking related as a result of Jeff's on-going work to get Giant off of the file system code, but more were associated with on-going buffer cache work by Poul-Henning. While I haven't made any attempt to determine if the last week is "typical" of long term bug fixes, it was easily on-hand, and the results are suggestive. Locking, as with other complex changes in the OS, comes with bugs, but it's hardly "hell" :-). One of the nice things about the locking approach to synchronization is that it comes with a strong assertion model: this means you can often find bugs without actually triggering the symptoms of the bugs, which may be difficult to trigger or very sensitive to timing. So when there are locking bug fixes, there more often found through a WITNESS warning than an exercised bug. When I do complex application pthreads programming, I often wish it had the threading/locking debugging facilities the FreeBSD kernel has :-). Robert N M Watson From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 7 16:10:09 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A68816A4CE for ; Mon, 7 Feb 2005 16:10:09 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 330B543D2F for ; Mon, 7 Feb 2005 16:10:09 +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 j17GAD2Y024938 for ; Mon, 7 Feb 2005 08:10:13 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j17GADaK024937 for hackers@freebsd.org; Mon, 7 Feb 2005 08:10:13 -0800 Date: Mon, 7 Feb 2005 08:10:13 -0800 From: Brooks Davis To: hackers@freebsd.org Message-ID: <20050207161012.GA23177@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline 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 Subject: finding casts from a type X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2005 16:10:09 -0000 --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'm trying to figure out an efficent way to find all the places where a given type (in my case struct ifnet *) is cast to another. Does anyone know of a tool to do this? I need to include implicit casts to (void *). I could do it by hand, but this is would be tedious and error prone given that there are over 330 files that refrence struct ifnet in the kernel. The ideal solution would be a pragma or something to cause gcc to generate a warning since once I move struct ifnet out of driver softc's all casts will be bugs. Initially I need to catch (void *) casts, but that probably won't be necessicary long term. -- 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 --2oS5YaxWCcQjTEyO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCB5LhXY6L6fI4GtQRAol9AKC1Xw6pvXMZR/Yxd6jeJnPZjhoLdQCffhpc lUfwt6PgYO0ST0Dt6d5R5kA= =BlgB -----END PGP SIGNATURE----- --2oS5YaxWCcQjTEyO-- From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 7 16:23:20 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3383F16A4CE for ; Mon, 7 Feb 2005 16:23:20 +0000 (GMT) Received: from gidgate.gid.co.uk (gid.co.uk [194.32.164.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 315E143D1D for ; Mon, 7 Feb 2005 16:23:19 +0000 (GMT) (envelope-from rb@gid.co.uk) Received: (from rb@localhost) by gidgate.gid.co.uk (8.11.7/8.11.6) id j17GNIe14865; Mon, 7 Feb 2005 16:23:18 GMT (envelope-from rb) Message-Id: <6.2.0.14.2.20050207162155.048bf020@gid.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Mon, 07 Feb 2005 16:23:05 +0000 To: Brooks Davis , hackers@freebsd.org From: Bob Bishop In-Reply-To: <20050207161012.GA23177@odin.ac.hmc.edu> References: <20050207161012.GA23177@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: finding casts from a type X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2005 16:23:20 -0000 At 16:10 07/02/2005, Brooks Davis wrote: >I'm trying to figure out an efficent way to find all the places where a >given type (in my case struct ifnet *) is cast to another. Hack up a copy of ports/devel/splint? -- Bob Bishop +44 (0)118 940 1243 rb@gid.co.uk fax +44 (0)118 940 1295 From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 7 16:26:50 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D72D16A4CE for ; Mon, 7 Feb 2005 16:26:50 +0000 (GMT) Received: from hydra.bec.de (www.ostsee-abc.de [62.206.222.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C9B1643D2D for ; Mon, 7 Feb 2005 16:26:49 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: from britannica.bec.de (unknown [139.30.252.67]) by hydra.bec.de (Postfix) with ESMTP id 60DF735707 for ; Mon, 7 Feb 2005 17:26:43 +0100 (CET) Received: by britannica.bec.de (Postfix, from userid 1001) id 021E3A0; Mon, 7 Feb 2005 17:25:46 +0100 (CET) Date: Mon, 7 Feb 2005 17:25:46 +0100 From: Joerg Sonnenberger To: hackers@freebsd.org Message-ID: <20050207162546.GA41246@britannica.bec.de> Mail-Followup-To: hackers@freebsd.org References: <20050207161012.GA23177@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050207161012.GA23177@odin.ac.hmc.edu> User-Agent: Mutt/1.5.6i Subject: Re: finding casts from a type X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2005 16:26:50 -0000 On Mon, Feb 07, 2005 at 08:10:13AM -0800, Brooks Davis wrote: > I'm trying to figure out an efficent way to find all the places where a > given type (in my case struct ifnet *) is cast to another. Does anyone > know of a tool to do this? I need to include implicit casts to (void > *). I could do it by hand, but this is would be tedious and error prone > given that there are over 330 files that refrence struct ifnet in the > kernel. The ideal solution would be a pragma or something to cause > gcc to generate a warning since once I move struct ifnet out of driver > softc's all casts will be bugs. Initially I need to catch (void *) > casts, but that probably won't be necessicary long term. What about using preprocessor / sed magic to convert struct ifnet to volatile struct ifnet? The few places where this is correctly casted away should be easy to find. Joerg From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 7 17:56:45 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEA8416A4CE for ; Mon, 7 Feb 2005 17:56:45 +0000 (GMT) Received: from duchess.speedfactory.net (duchess.speedfactory.net [66.23.201.84]) by mx1.FreeBSD.org (Postfix) with SMTP id 4E8E843D5D for ; Mon, 7 Feb 2005 17:56:45 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 8550 invoked by uid 89); 7 Feb 2005 17:56:41 -0000 Received: from duchess.speedfactory.net (66.23.201.84) by duchess.speedfactory.net with SMTP; 7 Feb 2005 17:56:41 -0000 Received: (qmail 7415 invoked by uid 89); 7 Feb 2005 17:56:22 -0000 Received: from unknown (HELO palm.tree.com) (66.23.216.49) by duchess.speedfactory.net with SMTP; 7 Feb 2005 17:56:22 -0000 Received: from [127.0.0.1] (localhost.tree.com [127.0.0.1]) by palm.tree.com (8.12.10/8.12.10) with ESMTP id j17HuLw6006407; Mon, 7 Feb 2005 12:56:22 -0500 (EST) (envelope-from ups@tree.com) From: Stephan Uphoff To: Gerald Heinig In-Reply-To: <420731DD.3050206@syskonnect.de> References: <420731DD.3050206@syskonnect.de> Content-Type: text/plain Message-Id: <1107798981.6309.9.camel@palm.tree.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 07 Feb 2005 12:56:21 -0500 Content-Transfer-Encoding: 7bit cc: hackers@freebsd.org Subject: Re: Firewire blues X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2005 17:56:46 -0000 On Mon, 2005-02-07 at 04:16, Gerald Heinig wrote: > Hi all, > > I'm having problems getting two 5.3-RELEASE boxes to communicate over > firewire. > I'm using two VIA Vt-6306 -based cards which are correctly recognised at > boot-time. > > I've loaded the dcons and dconschat modules and obtained both firewire > addresses via fwcontrol. I assume you mean dcons_crom module instead of dconschat. Did you reset the firewire bus? DCONS_CROM(4): ..... BUGS If you load dcons_crom.ko manually after booted, you may have to initiate a bus reset by ``fwcontrol -r'' to update Configuration ROM. > When I try to set up a connection with dconschat I get > > [dcons disconnected (get crom failed)] > > The exact command I gave is: > > dconschat -br -G 5556 -t > > I also tried setting the control ROM address with the -a option, to no > avail. > > Anyone have any ideas as to where I'm going wrong? > > BTW, I'm trying to set up remote debugging with gdb to debug a kernel hang. I recall some issues with gdb and firewire as a module that may or may not be fixed. I recommend to put the dcons into the kernel to avoid any problems. Stephan From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 7 18:42:48 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B51016A4CE; Mon, 7 Feb 2005 18:42:48 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D8AF43D31; Mon, 7 Feb 2005 18:42:47 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j16Mlmbc041150; Sun, 6 Feb 2005 14:47:54 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j16Mlg0r041149; Sun, 6 Feb 2005 14:47:42 -0800 (PST) (envelope-from www) Date: Sun, 6 Feb 2005 14:47:42 -0800 (PST) Message-Id: <200502062247.j16Mlg0r041149@marlena.vvi.at> To: rwatson@freebsd.org From: "ALeine" cc: freebsd-hackers@freebsd.org cc: k-sasaki@ist.osaka-u.ac.jp cc: freebsd-current@freebsd.org Subject: Re: FW: Call for comments: CoxR, a CVS/mail-lists/BTS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2005 18:42:48 -0000 rwatson@freebsd.org wrote: > I appreciate that not everyone is a fan of mutex synchronization, > but "mutex hell" is a bit of an odd description: most bugs I see > getting reported (and fixed) aren't even locking-related. They're > generally a property of lack of testing exposure for more obscure > features or edge cases that are hard to test for without a wide > testing base, such as edge-case hardware, bugs associated with > longer run times, or a recently introduced feature, etc. Well, mutex hell is more of a humorous description, but unfortunately it is not too far from what is becoming a reality. I believe that the path the FreeBSD Project has taken with the 5.x branch (not only in regard to mutex locking but in general) has made things far too complex in ways that make even seasoned hardcore developers such as yourself unwilling to touch certain subsystems because only one or two people really understand that system well enough to introduce only a few (instead of a few dozen) critical bugs when changing that subsystem. Or do you want to tell me that you could go right in and get the critical section related stuff sorted out on your own without John Baldwin and Stephan Uphoff in order to get to merge your UMA related changes? :-) I've been examining kernel sources in greater detail these past few days and from what I've seen so far I believe certain subsystems should just be rewritten from scratch in order to simplify things in terms of solving MP problems and UP performance (burning a lot of unnecessary cycles on every mutex release and the like is just not acceptable, IMHO). Rewritting the IPI code and the scheduler should be a good start, but I doubt anyone from the Core team would even consider that because you've all invested so much into what is in place now. As you keep working on the same things you've been working on for years things get more and more complex and you become more and more resistant to change, while potential developers become more and more discouraged and in the end things might get very stale with only a handful overworked developers who won't be able to see the forest for the trees. I do not mean to start a flame war or anything, this is just my opinion, I do have a lot of respect for all of you guys working hard on the 5.x and the 6.x branches, I just politely disagree with the direction in which the project is heading. :-) ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 7 19:12:51 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 005D916A4EA for ; Mon, 7 Feb 2005 19:12:51 +0000 (GMT) Received: from wrzx28.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77DFC43D1D for ; Mon, 7 Feb 2005 19:12:50 +0000 (GMT) (envelope-from q@uni.de) 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 9D36DD822A; Mon, 7 Feb 2005 20:12:49 +0100 (CET) Received: from virusscan (localhost [127.0.0.1]) by wrzx34.rz.uni-wuerzburg.de (Postfix) with ESMTP id 7FC4CA9E5D; Mon, 7 Feb 2005 20:12:49 +0100 (CET) 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 64D74A6DA5; Mon, 7 Feb 2005 20:12:49 +0100 (CET) Received: from coyote.q.local (wwsx14.win-screen.uni-wuerzburg.de [132.187.253.14]) by wrzx28.rz.uni-wuerzburg.de (Postfix) with ESMTP id 23DEED822A; Mon, 7 Feb 2005 20:12:49 +0100 (CET) Received: from roadrunner.q.local (roadrunner.q.local [192.168.0.148]) by coyote.q.local (8.13.1/8.13.1) with ESMTP id j17JCmA7006772; Mon, 7 Feb 2005 20:12:48 +0100 (CET) (envelope-from q@uni.de) Received: from roadrunner.q.local (localhost [127.0.0.1]) by roadrunner.q.local (8.13.1/8.13.1) with ESMTP id j17JCmde004250; Mon, 7 Feb 2005 20:12:48 +0100 (CET) (envelope-from q@uni.de) Received: (from q@localhost) by roadrunner.q.local (8.13.1/8.13.1/Submit) id j17JClOI004249; Mon, 7 Feb 2005 20:12:47 +0100 (CET) (envelope-from q@uni.de) Date: Mon, 7 Feb 2005 20:12:47 +0100 From: Ulrich Spoerlein To: Gerald Heinig Message-ID: <20050207191247.GC771@galgenberg.net> References: <420731DD.3050206@syskonnect.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <420731DD.3050206@syskonnect.de> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new (Rechenzentrum Universitaet Wuerzburg) cc: hackers@freebsd.org Subject: Re: Firewire blues X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2005 19:12:51 -0000 On Mon, 07.02.2005 at 10:16:13 +0100, Gerald Heinig wrote: > [dcons disconnected (get crom failed)] > [...] > BTW, I'm trying to set up remote debugging with gdb to debug a kernel hang. As Stephan already suggested, try fwcontrol -r (probably on both hosts). This worked for me. And good luck in getting kgdb to work over firewire, I failed :( If you get it working, please get back to me! Ulrich Spoerlein -- 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? From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 7 22:19:11 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C334016A4CE for ; Mon, 7 Feb 2005 22:19:11 +0000 (GMT) Received: from smtp.intellex.com (smtp.intellex.com [199.233.213.9]) by mx1.FreeBSD.org (Postfix) with SMTP id 0A94D43D31 for ; Mon, 7 Feb 2005 22:19:11 +0000 (GMT) (envelope-from chris@smtp.intellex.com) Received: (qmail 56179 invoked by uid 0); 7 Feb 2005 22:37:32 -0000 Received: (qmail 62948 invoked from network); 7 Feb 2005 14:26:28 -0000 Received: from mx2.freebsd.org (216.136.204.119) by smtp.intellex.com with SMTP; 7 Feb 2005 14:26:28 -0000 Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id B2A9656B19; Mon, 7 Feb 2005 14:04:49 +0000 (GMT) (envelope-from owner-freebsd-current@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id B8A8316A4DC; Mon, 7 Feb 2005 14:04:46 +0000 (GMT) Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 14D7416A4CE; Mon, 7 Feb 2005 14:01:05 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC2C243D1D; Mon, 7 Feb 2005 14:01:04 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j16I6Abc037041; Sun, 6 Feb 2005 10:06:11 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j16I64bE037040; Sun, 6 Feb 2005 10:06:04 -0800 (PST) (envelope-from www) Date: Sun, 6 Feb 2005 10:06:04 -0800 (PST) Message-Id: <200502061806.j16I64bE037040@marlena.vvi.at> To: k-sasaki@ist.osaka-u.ac.jp From: "ALeine" X-Mailman-Approved-At: Mon, 07 Feb 2005 14:04:41 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-current@freebsd.org Errors-To: owner-freebsd-current@freebsd.org cc: freebsd-hackers@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: FW: Call for comments: CoxR, a CVS/mail-lists/BTS X-BeenThere: freebsd-hackers@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2005 22:19:12 -0000 k-sasaki@ist.osaka-u.ac.jp wrote: > Thanks for the many feedbacks about CoxR. > We modified the CoxR based on feedback. > And so, please try CoxR function once more. > I would like to have your impressions on the above mentioned information > system as an open source expert > Any feedback including the answer of questions above, comments, suggestions, > etc are always welcome, I took a quick look, but the page does not even display properly due to bad HTML. I suggest you run a HTML validator on the page and clean up the HTML code first: http://validator.w3.org/check?uri=http%3A%2F%2Fscorpion.ics.es.osaka-u.ac.jp%2Fcgi-bin%2FCodeSearch%2Fcoxr.html > Bug Trucking System Oh come, FreeBSD 5.x does have a mutex hell going on, but to say it has so many bugs as to require a truck is absurd. :-> A smaller lorry perhaps, but a truck - definitely not. :-) It might also be a good idea to use an automated spell-check on your pages, I've noticed a number of typos such as "divelopers" and similar. ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net _______________________________________________ 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-hackers@FreeBSD.ORG Mon Feb 7 22:20:29 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6FD4D16A4CE for ; Mon, 7 Feb 2005 22:20:29 +0000 (GMT) Received: from smtp.intellex.com (smtp.intellex.com [199.233.213.9]) by mx1.FreeBSD.org (Postfix) with SMTP id 9DF6443D45 for ; Mon, 7 Feb 2005 22:20:28 +0000 (GMT) (envelope-from chris@smtp.intellex.com) Received: (qmail 61162 invoked by uid 0); 7 Feb 2005 22:38:53 -0000 Received: (qmail 10023 invoked from network); 7 Feb 2005 15:44:01 -0000 Received: from mx2.freebsd.org (216.136.204.119) by smtp.intellex.com with SMTP; 7 Feb 2005 15:44:01 -0000 Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 01BB557425; Mon, 7 Feb 2005 15:23:13 +0000 (GMT) (envelope-from owner-freebsd-current@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 1495616A4EE; Mon, 7 Feb 2005 15:23:04 +0000 (GMT) Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D7E316A4CE; Mon, 7 Feb 2005 15:22:57 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id B146343D48; Mon, 7 Feb 2005 15:22:56 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id 0E62C46B11; Mon, 7 Feb 2005 10:22:56 -0500 (EST) Date: Mon, 7 Feb 2005 15:21:57 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: ALeine In-Reply-To: <200502061806.j16I64bE037040@marlena.vvi.at> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-current@freebsd.org Errors-To: owner-freebsd-current@freebsd.org cc: freebsd-hackers@freebsd.org cc: k-sasaki@ist.osaka-u.ac.jp cc: freebsd-current@freebsd.org Subject: Re: FW: Call for comments: CoxR, a CVS/mail-lists/BTS X-BeenThere: freebsd-hackers@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2005 22:20:29 -0000 On Sun, 6 Feb 2005, ALeine wrote: > Oh come, FreeBSD 5.x does have a mutex hell going on, but to say it has > so many bugs as to require a truck is absurd. :-> A smaller lorry > perhaps, but a truck - definitely not. :-) It might also be a good idea > to use an automated spell-check on your pages, I've noticed a number of > typos such as "divelopers" and similar. I appreciate that not everyone is a fan of mutex synchronization, but "mutex hell" is a bit of an odd description: most bugs I see getting reported (and fixed) aren't even locking-related. They're generally a property of lack of testing exposure for more obscure features or edge cases that are hard to test for without a wide testing base, such as edge-case hardware, bugs associated with longer run times, or a recently introduced feature, etc. Generally speaking, in the last week, I saw a couple of classes of bug fix fly by in commits, in order of frequency of occurence: - Minor device driver bugs involving alignment, feature mapping for device IDs, attach/detach bugs, error handling, etc. In one case, the bug was that a device driver was able to run MPSAFE, but the flag was set incorrectly to not let it. As usual, a moderate amount of change in ACPI. This was the vast majority of bug fixes. - Network stack logical errors or C-related errors: generally, doing something wrong with mbufs or routing. Mostly "syntax" and not "semantics", although a couple of netflow bugs that were more serious and the result of more broad exposure since its commit (last month?). - Scheduling related bugs in ULE -- Jeff MFC'd a number of fixes to RELENG_5 for the first time in several months, so there was some backlog, but I think it's not unusual to see a trickle of scheduling related changes, so isn't entirely unrepresentative. - VFS/file system bugs -- a couple were locking related as a result of Jeff's on-going work to get Giant off of the file system code, but more were associated with on-going buffer cache work by Poul-Henning. While I haven't made any attempt to determine if the last week is "typical" of long term bug fixes, it was easily on-hand, and the results are suggestive. Locking, as with other complex changes in the OS, comes with bugs, but it's hardly "hell" :-). One of the nice things about the locking approach to synchronization is that it comes with a strong assertion model: this means you can often find bugs without actually triggering the symptoms of the bugs, which may be difficult to trigger or very sensitive to timing. So when there are locking bug fixes, there more often found through a WITNESS warning than an exercised bug. When I do complex application pthreads programming, I often wish it had the threading/locking debugging facilities the FreeBSD kernel has :-). Robert N M Watson _______________________________________________ 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-hackers@FreeBSD.ORG Tue Feb 8 01:48:36 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AEAE816A4CE; Tue, 8 Feb 2005 01:48:36 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6484743D1F; Tue, 8 Feb 2005 01:48:36 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 4E26351432; Mon, 7 Feb 2005 17:48:35 -0800 (PST) Date: Mon, 7 Feb 2005 17:48:35 -0800 From: Kris Kennaway To: ALeine Message-ID: <20050208014835.GA567@xor.obsecurity.org> References: <200502062247.j16Mlg0r041149@marlena.vvi.at> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VbJkn9YxBvnuCH5J" Content-Disposition: inline In-Reply-To: <200502062247.j16Mlg0r041149@marlena.vvi.at> User-Agent: Mutt/1.4.2.1i cc: freebsd-hackers@freebsd.org cc: k-sasaki@ist.osaka-u.ac.jp cc: rwatson@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: FW: Call for comments: CoxR, a CVS/mail-lists/BTS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2005 01:48:37 -0000 --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 06, 2005 at 02:47:42PM -0800, ALeine wrote: > rwatson@freebsd.org wrote:=20 >=20 > > I appreciate that not everyone is a fan of mutex synchronization, > > but "mutex hell" is a bit of an odd description: most bugs I see > > getting reported (and fixed) aren't even locking-related. They're > > generally a property of lack of testing exposure for more obscure > > features or edge cases that are hard to test for without a wide > > testing base, such as edge-case hardware, bugs associated with > > longer run times, or a recently introduced feature, etc. >=20 > Well, mutex hell is more of a humorous description, but unfortunately > it is not too far from what is becoming a reality. I believe that > the path the FreeBSD Project has taken with the 5.x branch (not only > in regard to mutex locking but in general) has made things far too > complex in ways that make even seasoned hardcore developers such as > yourself unwilling to touch certain subsystems because only one or > two people really understand that system well enough to introduce > only a few (instead of a few dozen) critical bugs when changing that > subsystem. Or do you want to tell me that you could go right in and > get the critical section related stuff sorted out on your own without > John Baldwin and Stephan Uphoff in order to get to merge your UMA > related changes? :-) [...] Consider not insulting the intelligence of the FreeBSD developers if you want them to ever help you again with your kernel newbie questions. That kind of trash-talking may be cool in other projects, but around here it's not going to win you friends. Kris --VbJkn9YxBvnuCH5J Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCCBpzWry0BWjoQKURAvilAKCOQpK0IOV04tUrVHXg6Og44lHm6gCgmQQy FufOtDWz+FTCB6KehbR169U= =oQAQ -----END PGP SIGNATURE----- --VbJkn9YxBvnuCH5J-- From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 8 09:11:40 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E88A716A4CE for ; Tue, 8 Feb 2005 09:11:40 +0000 (GMT) Received: from gatekeeper.syskonnect.de (gatekeeper.syskonnect.de [213.144.13.149]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E99343D49 for ; Tue, 8 Feb 2005 09:11:39 +0000 (GMT) (envelope-from gheinig@syskonnect.de) Received: from syskonnect.de (skd.de [10.9.15.1])j189Bp91019519; Tue, 8 Feb 2005 10:11:51 +0100 (MET) Received: from syskonnect.de (localhost [127.0.0.1]) by syskonnect.de (8.12.11/8.12.11) with ESMTP id j189BaVW017268; Tue, 8 Feb 2005 10:11:37 +0100 (MET) Message-ID: <42088232.1030001@syskonnect.de> Date: Tue, 08 Feb 2005 10:11:14 +0100 From: Gerald Heinig User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephan Uphoff References: <420731DD.3050206@syskonnect.de> <1107798981.6309.9.camel@palm.tree.com> In-Reply-To: <1107798981.6309.9.camel@palm.tree.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: hackers@freebsd.org Subject: Re: Firewire blues X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2005 09:11:41 -0000 Stephan Uphoff wrote: > On Mon, 2005-02-07 at 04:16, Gerald Heinig wrote: > >>Hi all, >> >>I'm having problems getting two 5.3-RELEASE boxes to communicate over >>firewire. >>I'm using two VIA Vt-6306 -based cards which are correctly recognised at >>boot-time. >> >>I've loaded the dcons and dconschat modules and obtained both firewire >>addresses via fwcontrol. > > > I assume you mean dcons_crom module instead of dconschat. Yes, sorry, my mistake. > > Did you reset the firewire bus? I did reset it, but only on the debugging system, not on the target system. > > DCONS_CROM(4): > ..... > BUGS > If you load dcons_crom.ko manually after booted, you may have to > initiate > a bus reset by ``fwcontrol -r'' to update Configuration ROM. > > > >>When I try to set up a connection with dconschat I get >> >>[dcons disconnected (get crom failed)] >> >>The exact command I gave is: >> >>dconschat -br -G 5556 -t >> >>I also tried setting the control ROM address with the -a option, to no >>avail. >> >>Anyone have any ideas as to where I'm going wrong? >> >>BTW, I'm trying to set up remote debugging with gdb to debug a kernel hang. > > > I recall some issues with gdb and firewire as a module that may or may > not be fixed. > I recommend to put the dcons into the kernel to avoid any problems. I tried that too. There are a few additional flags that can be set. Of particular interest are DCONS_FORCE_CONSOLE and DCONS_FORCE_GDB. I presume I should set FORCE_CONSOLE to 1 if I want a console over firewire, am I right? I'll take a look and see if there are any bugfixes for firewire. Thanks for the reply! Cheers, Gerald From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 8 09:57:04 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6884716A4CE; Tue, 8 Feb 2005 09:57:04 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0841D43D46; Tue, 8 Feb 2005 09:57:04 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j17E27bc056210; Mon, 7 Feb 2005 06:02:12 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j17E21Jb056209; Mon, 7 Feb 2005 06:02:01 -0800 (PST) (envelope-from www) Date: Mon, 7 Feb 2005 06:02:01 -0800 (PST) Message-Id: <200502071402.j17E21Jb056209@marlena.vvi.at> To: kris@obsecurity.org From: "ALeine" cc: freebsd-hackers@freebsd.org cc: k-sasaki@ist.osaka-u.ac.jp cc: rwatson@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: FW: Call for comments: CoxR, a CVS/mail-lists/BTS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2005 09:57:04 -0000 kris@obsecurity.org wrote: > Consider not insulting the intelligence of the FreeBSD developers > if you want them to ever help you again with your kernel newbie > questions. That kind of trash-talking may be cool in other > projects, but around here it's not going to win you friends. Consider not mischaracterizing, belittling and alienating people for voicing their opinions. I had no intention of insulting anyone, my point was exactly the opposite of what you seem to believe - I claim that if such seasoned, highly intelligent and skilled developers do not feel comfortable making changes to certain subsystems then that is an indication that the complexity has gone too far. Let me reiterate, I believe the Core team members to be highly intelligent, skilled and friendly people and I have a lot of respect for them and their work. I have utmost respect for Mr. Watson because I believe he better than anyone else embodies the spirit of the Project, he is always very informative, thorough, helpful, friendly, polite, willing to share his vast knowledge and experience and offer his insight, unlike certain former Security Officers. ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 8 13:08:45 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B4D216A4CF for ; Tue, 8 Feb 2005 13:08:45 +0000 (GMT) Received: from gatekeeper.syskonnect.de (gatekeeper.syskonnect.de [213.144.13.149]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF0E843D1D for ; Tue, 8 Feb 2005 13:08:43 +0000 (GMT) (envelope-from gheinig@syskonnect.de) Received: from syskonnect.de (skd.de [10.9.15.1])j18D8t91025685; Tue, 8 Feb 2005 14:08:55 +0100 (MET) Received: from syskonnect.de (localhost [127.0.0.1]) by syskonnect.de (8.12.11/8.12.11) with ESMTP id j18D8eU9022931; Tue, 8 Feb 2005 14:08:41 +0100 (MET) Message-ID: <4208B9C2.6020007@syskonnect.de> Date: Tue, 08 Feb 2005 14:08:18 +0100 From: Gerald Heinig User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hackers@freebsd.org References: <420731DD.3050206@syskonnect.de> <1107798981.6309.9.camel@palm.tree.com> <42088232.1030001@syskonnect.de> In-Reply-To: <42088232.1030001@syskonnect.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Stephan Uphoff Subject: Re: Firewire blues X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2005 13:08:45 -0000 Gerald Heinig wrote: >> >> >> I recall some issues with gdb and firewire as a module that may or may >> not be fixed. >> I recommend to put the dcons into the kernel to avoid any problems. > > > I tried that too. There are a few additional flags that can be set. Of > particular interest are DCONS_FORCE_CONSOLE and DCONS_FORCE_GDB. I > presume I should set FORCE_CONSOLE to 1 if I want a console over > firewire, am I right? > I'll take a look and see if there are any bugfixes for firewire. It turns out that you need to set DCONS_FORCE_CONSOLE to 1 if you want to have a remote console over firewire. I've got my link working with firewire now, but unfortunately I still can't get kgdb to connect. If I do the following on the debugging machine: kgdb -r /dev/fwmem0.0 kernel.debug I get: [general gdb stuff] Switching to remote protocol get_tty_state failed: Invalid argument set_tty_state failed: Invalid argument get_tty_state failed: Invalid argument set_tty_state failed: Invalid argument Couldn't establish connection to remote target Reply contains invalid hex digit 12 When doing this, the remote machine's kernel wqas compiled with devices dcons and dcons_crom and options DCONS_FORCE_GDB=1 Any ideas? Cheers, Gerald From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 7 15:44:28 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A7B216A5DF for ; Mon, 7 Feb 2005 15:44:28 +0000 (GMT) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1103643D46 for ; Mon, 7 Feb 2005 15:44:24 +0000 (GMT) (envelope-from avg@icyb.net.ua) Received: from oddity (oddity.topspin.kiev.ua [212.40.38.87]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA04259 for ; Mon, 07 Feb 2005 17:44:21 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <42051ECC.5010304@icyb.net.ua> Date: Sat, 05 Feb 2005 14:30:20 -0500 From: Andriy Gapon User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Status: RO X-UID: 3831 X-Keywords: ReSent-Date: Mon, 7 Feb 2005 17:44:13 +0200 (EET) Resent-From: Andriy Gapon Resent-To: freebsd-hackers@freebsd.org ReSent-Subject: ata_request question ReSent-Message-ID: <20050207174413.H15949@oddity.topspin.kiev.ua> X-Mailman-Approved-At: Tue, 08 Feb 2005 13:16:33 +0000 Subject: ata_request question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2005 15:44:28 -0000 I am doing some minor hacking into ata driver, or rather atapi part of it, and I am a little bit confused about meaning and usage of ata_request.status ata_request.error ata_request.result for higher level code - i.e. the code that invokes ata_queue_request() - what it should look at to see if a request is successfully processed and, if not, what happened ? -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 8 13:45:49 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6903916A4CF for ; Tue, 8 Feb 2005 13:45:49 +0000 (GMT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 2942843D4C for ; Tue, 8 Feb 2005 13:45:48 +0000 (GMT) (envelope-from michaelnottebrock@gmx.net) Received: (qmail invoked by alias); 08 Feb 2005 13:45:46 -0000 Received: from pD955FBD7.dip.t-dialin.net (EHLO lofi.dyndns.org) (217.85.251.215) by mail.gmx.net (mp013) with SMTP; 08 Feb 2005 14:45:46 +0100 X-Authenticated: #443188 Received: from kiste.my.domain (kiste.my.domain [192.168.8.4]) (authenticated bits=0) by lofi.dyndns.org (8.12.10/8.12.10) with ESMTP id j18DjZaY040744 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 8 Feb 2005 14:45:37 +0100 (CET) (envelope-from michaelnottebrock@gmx.net) From: Michael Nottebrock To: "ALeine" Date: Tue, 8 Feb 2005 14:45:30 +0100 User-Agent: KMail/1.7.2 References: <200502071402.j17E21Jb056209@marlena.vvi.at> In-Reply-To: <200502071402.j17E21Jb056209@marlena.vvi.at> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2530468.nGQrFJ7Y45"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200502081445.35268.michaelnottebrock@gmx.net> X-Virus-Scanned: by amavisd-new X-Y-GMX-Trusted: 0 X-Mailman-Approved-At: Tue, 08 Feb 2005 14:06:39 +0000 cc: freebsd-hackers@freebsd.org cc: k-sasaki@ist.osaka-u.ac.jp cc: rwatson@freebsd.org cc: kris@obsecurity.org Subject: Re: FW: Call for comments: CoxR, a CVS/mail-lists/BTS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2005 13:45:49 -0000 --nextPart2530468.nGQrFJ7Y45 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday, 7. February 2005 15:02, ALeine wrote: [-current cut from recipients, why was this thread ever posted there anyway] > I have utmost respect for Mr. > Watson because I believe he better than anyone else embodies > the spirit of the Project, he is always very informative, > thorough, helpful, friendly, polite, willing to share his > vast knowledge and experience and offer his insight, unlike > certain former Security Officers. See, you're doing it again. =2D-=20 ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org --nextPart2530468.nGQrFJ7Y45 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCCMJ/Xhc68WspdLARArOjAKCGG2RfntvYEmWSPcHw+fxAM50uVACeMiUz P8KFJHoqLJsxlf5ZxHgtxYA= =lNM2 -----END PGP SIGNATURE----- --nextPart2530468.nGQrFJ7Y45-- From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 8 15:22:06 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D326016A4CE; Tue, 8 Feb 2005 15:22:06 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4765B43D31; Tue, 8 Feb 2005 15:22:06 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id j18FJ6Ti006911; Tue, 8 Feb 2005 08:19:06 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 08 Feb 2005 08:21:04 -0700 (MST) Message-Id: <20050208.082104.00724757.imp@bsdimp.com> To: aleine@austrosearch.net From: "M. Warner Losh" In-Reply-To: <200502071402.j17E21Jb056209@marlena.vvi.at> References: <200502071402.j17E21Jb056209@marlena.vvi.at> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org cc: k-sasaki@ist.osaka-u.ac.jp cc: rwatson@freebsd.org cc: freebsd-current@freebsd.org cc: kris@obsecurity.org Subject: Re: Call for comments: CoxR, a CVS/mail-lists/BTS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2005 15:22:07 -0000 In message: <200502071402.j17E21Jb056209@marlena.vvi.at> "ALeine" writes: : kris@obsecurity.org wrote: : : > Consider not insulting the intelligence of the FreeBSD developers : > if you want them to ever help you again with your kernel newbie : > questions. That kind of trash-talking may be cool in other : > projects, but around here it's not going to win you friends. : : Consider not mischaracterizing, belittling and alienating people for : voicing their opinions. I had no intention of insulting anyone, my : point was exactly the opposite of what you seem to believe - I claim : that if such seasoned, highly intelligent and skilled developers do : not feel comfortable making changes to certain subsystems then that : is an indication that the complexity has gone too far. : : Let me reiterate, I believe the Core team members to be highly : intelligent, skilled and friendly people and I have a lot of : respect for them and their work. I have utmost respect for Mr. : Watson because I believe he better than anyone else embodies : the spirit of the Project, he is always very informative, : thorough, helpful, friendly, polite, willing to share his : vast knowledge and experience and offer his insight, unlike : certain former Security Officers. If I were to reply in kind to your message, it would be something like: Listen you worthless hunk of flesh. I'm not trying to insult you, since I have the utmost respect for the miserable life you no doubt must lead. Nothing could be farther from the intentions I had when I set out ot write this, but you clearly could use a personality transplant. The secret to effective communication is making sure that you communicate the message that you intend to communicate. By saying in one paragraph that you have the utmost respect for people (and by the way misunderstanding how the core team works and its relationship to the project, but I digress), and then insulting them in the next paragraph, you're clearly showing your contempt or disrespect. Please, learn some manners. Warner From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 8 18:54:31 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A8CF416A4CE for ; Tue, 8 Feb 2005 18:54:31 +0000 (GMT) Received: from duchess.speedfactory.net (duchess.speedfactory.net [66.23.201.84]) by mx1.FreeBSD.org (Postfix) with SMTP id BE51C43D49 for ; Tue, 8 Feb 2005 18:54:30 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 24022 invoked by uid 89); 8 Feb 2005 18:54:12 -0000 Received: from duchess.speedfactory.net (66.23.201.84) by duchess.speedfactory.net with SMTP; 8 Feb 2005 18:54:12 -0000 Received: (qmail 23934 invoked by uid 89); 8 Feb 2005 18:54:11 -0000 Received: from unknown (HELO palm.tree.com) (66.23.216.49) by duchess.speedfactory.net with SMTP; 8 Feb 2005 18:54:11 -0000 Received: from [127.0.0.1] (localhost.tree.com [127.0.0.1]) by palm.tree.com (8.12.10/8.12.10) with ESMTP id j18Is4w6012851; Tue, 8 Feb 2005 13:54:05 -0500 (EST) (envelope-from ups@tree.com) From: Stephan Uphoff To: Gerald Heinig In-Reply-To: <4208B9C2.6020007@syskonnect.de> References: <420731DD.3050206@syskonnect.de> <42088232.1030001@syskonnect.de> <4208B9C2.6020007@syskonnect.de> Content-Type: text/plain Message-Id: <1107888844.6309.221.camel@palm.tree.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 08 Feb 2005 13:54:04 -0500 Content-Transfer-Encoding: 7bit cc: hackers@freebsd.org Subject: Re: Firewire blues X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2005 18:54:31 -0000 On Tue, 2005-02-08 at 08:08, Gerald Heinig wrote: > Gerald Heinig wrote: > >> > >> > >> I recall some issues with gdb and firewire as a module that may or may > >> not be fixed. > >> I recommend to put the dcons into the kernel to avoid any problems. > > > > > > I tried that too. There are a few additional flags that can be set. Of > > particular interest are DCONS_FORCE_CONSOLE and DCONS_FORCE_GDB. I > > presume I should set FORCE_CONSOLE to 1 if I want a console over > > firewire, am I right? > > I'll take a look and see if there are any bugfixes for firewire. > > It turns out that you need to set DCONS_FORCE_CONSOLE to 1 if you want > to have a remote console over firewire. > I've got my link working with firewire now, but unfortunately I still > can't get kgdb to connect. > > If I do the following on the debugging machine: > > kgdb -r /dev/fwmem0.0 kernel.debug > > I get: > > [general gdb stuff] > Switching to remote protocol > get_tty_state failed: Invalid argument > set_tty_state failed: Invalid argument > get_tty_state failed: Invalid argument > set_tty_state failed: Invalid argument > Couldn't establish connection to remote target > Reply contains invalid hex digit 12 > > When doing this, the remote machine's kernel wqas compiled with devices > dcons and dcons_crom and options DCONS_FORCE_GDB=1 > > Any ideas? There are two ways using kgdb to debug a target with firewire. The first way basically replaces the slow serial cable for communication to the remote target gdb stub. The second way uses the remote DMA capabilities of firewire to directly read memory of the target WITHOUT using any debugging software/stub on the target. (Think remote core file) Greg Lehey wrote a nice kernel debugging tutorial that explains both types of firewire debugging. http://www.lemis.com/grog/Papers/Debug-tutorial/tutorial.pdf This should get you started with only minor adjustments (gdb->kgdb) . Stephan From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 8 21:38:46 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F3D2616A4CE; Tue, 8 Feb 2005 21:38:45 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id B71D743D48; Tue, 8 Feb 2005 21:38:45 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j181hcbc063614; Mon, 7 Feb 2005 17:43:40 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j181hQa8063613; Mon, 7 Feb 2005 17:43:26 -0800 (PST) (envelope-from www) Date: Mon, 7 Feb 2005 17:43:26 -0800 (PST) Message-Id: <200502080143.j181hQa8063613@marlena.vvi.at> To: imp@bsdimp.com From: "ALeine" cc: freebsd-hackers@freebsd.org cc: k-sasaki@ist.osaka-u.ac.jp cc: rwatson@freebsd.org cc: freebsd-current@freebsd.org cc: kris@obsecurity.org Subject: Re: Call for comments: CoxR, a CVS/mail-lists/BTS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2005 21:38:46 -0000 imp@bsdimp.com wrote: > If I were to reply in kind to your message, it would be something > like: > > Listen you worthless hunk of flesh. I'm not trying to insult > you, since I have the utmost respect for the miserable life > you no doubt must lead. Nothing could be farther from the > intentions I had when I set out ot write this, but you clearly > could use a personality transplant. > > The secret to effective communication is making sure that you > communicate the message that you intend to communicate. By > saying in one paragraph that you have the utmost respect for people > (and by the way misunderstanding how the core team works and its > relationship to the project, but I digress), and then insulting > them in the next paragraph, you're clearly showing your contempt > or disrespect. > > Please, learn some manners. The secret to effective communication is making sure you first understand what was said before speaking up. If you were to reply in that manner I would have to conclude either that you grossly misunderstood what I had said and that you were overreacting in an insulting and patronizing manner unbecoming of a Core team member or that someone else was posting as you. If I were then to reply in kind it would be something like: Dear Mr. Losh, a village idiot seems to be posting as you and lashing out against me. I am not impressed, but you may not find the impact of such posts important enough to prevent the imposter from impersonating you further with impunity. Someone more impartial might impart the same advice, but it is up to you to decide how impeccable or impaired you want your reputation to be. If you care to reread my previous post you might notice that in the first paragraph I was referring to the post I posted before my previous post. I also said I had a lot of respect for the (current) Core team members and that I have utmost respect for Mr. Watson (my utmost respect does not extend to the entire team, you misunderstood that as well), who is unlike certain former Security Officers. Why you are lashing out against me and jumping to conclusions is not clear, but I suspect that it must fall under the "If the shoe fits" category with you being both a former Security Officer and a current Core team member. There are no contradictions in what I said. I have a lot of respect for most of the current Core team members (sadly, that status changed slightly after your post) and Mr. Watson still has my utmost respect. I never intended to insult Mr. Watson in any way, I was making a point about the complexity of the system going too far. Complexity of the system was the issue, but nobody even mentioned that in their replies, yet all those who replied got very defensive and offensive and started going on about disrespect in an attempt to turn this into a personal issue. But I digress, you see what you want to see. I will attribute your incorrect conclusion that I am misunderstanding the role of the Core team to the same misunderstanding and flawed reasoning that led you to the conclusion that I was being disrespectful to the current Core team members. I was not, my comment in the previous post was directed at Kris Kennaway, your successor in the role of Security Officer. One who advises others to learn some manners should at least try to show one has at least some manners oneself. Using words like worthless, miserable and personality transplant while directly addressing someone you claim should learn some manners is not the best way to show manners, at least not in Austria. ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 8 21:49:29 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A89916A4CE; Tue, 8 Feb 2005 21:49:29 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04ED543D49; Tue, 8 Feb 2005 21:49:29 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id j18LlsGV010939; Tue, 8 Feb 2005 14:47:54 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 08 Feb 2005 14:49:51 -0700 (MST) Message-Id: <20050208.144951.120056601.imp@bsdimp.com> To: aleine@austrosearch.net From: "M. Warner Losh" In-Reply-To: <200502080143.j181hQa8063613@marlena.vvi.at> References: <200502080143.j181hQa8063613@marlena.vvi.at> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org cc: k-sasaki@ist.osaka-u.ac.jp cc: rwatson@freebsd.org cc: freebsd-current@freebsd.org cc: kris@obsecurity.org Subject: Re: Call for comments: CoxR, a CVS/mail-lists/BTS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2005 21:49:29 -0000 It's official. You're on the list. Have a nice day. Warner From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 9 08:14:24 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5EA3616A4CE for ; Wed, 9 Feb 2005 08:14:24 +0000 (GMT) Received: from gatekeeper.syskonnect.de (gatekeeper.syskonnect.de [213.144.13.149]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D8BB43D31 for ; Wed, 9 Feb 2005 08:14:23 +0000 (GMT) (envelope-from gheinig@syskonnect.de) Received: from syskonnect.de (skd.de [10.9.15.1])j198EZ91009549; Wed, 9 Feb 2005 09:14:35 +0100 (MET) Received: from syskonnect.de (localhost [127.0.0.1]) by syskonnect.de (8.12.11/8.12.11) with ESMTP id j198EGB5015214; Wed, 9 Feb 2005 09:14:20 +0100 (MET) Message-ID: <4209C640.3070502@syskonnect.de> Date: Wed, 09 Feb 2005 09:13:52 +0100 From: Gerald Heinig User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephan Uphoff References: <420731DD.3050206@syskonnect.de> <1107798981.6309.9.camel@palm.tree.com> <42088232.1030001@syskonnect.de> <4208B9C2.6020007@syskonnect.de> <1107888844.6309.221.camel@palm.tree.com> In-Reply-To: <1107888844.6309.221.camel@palm.tree.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: hackers@freebsd.org Subject: Re: Firewire blues X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2005 08:14:24 -0000 Stephan Uphoff wrote: > There are two ways using kgdb to debug a target with firewire. > The first way basically replaces the slow serial cable for communication > to the remote target gdb stub. > The second way uses the remote DMA capabilities of firewire to directly > read memory of the target WITHOUT using any debugging software/stub on > the target. (Think remote core file) > > Greg Lehey wrote a nice kernel debugging tutorial that explains both > types of firewire debugging. > http://www.lemis.com/grog/Papers/Debug-tutorial/tutorial.pdf > > This should get you started with only minor adjustments (gdb->kgdb) . This is actually the paper I'm using. I've followed the instructions on both methods, but I can't get it to work. The direct machine-machine connection is fine (ie. the one with dconschat). It's the kgdb connection that doesn't work. I presume it worked out of the box for you then? Cheers, Gerald From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 9 12:18:28 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF62616A4CE; Wed, 9 Feb 2005 12:18:28 +0000 (GMT) Received: from smtp-vbr7.xs4all.nl (smtp-vbr7.xs4all.nl [194.109.24.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id E56BD43D1D; Wed, 9 Feb 2005 12:18:27 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp-vbr7.xs4all.nl (8.12.11/8.12.11) with ESMTP id j19CIQd3046887; Wed, 9 Feb 2005 13:18:26 +0100 (CET) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.13.1/8.12.9) with ESMTP id j19CIPCO009854; Wed, 9 Feb 2005 13:18:25 +0100 (CET) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.13.1/8.13.1/Submit) id j19CIP0w009853; Wed, 9 Feb 2005 13:18:25 +0100 (CET) (envelope-from wb) Date: Wed, 9 Feb 2005 13:18:25 +0100 From: Wilko Bulte To: Willy Offermans Message-ID: <20050209121825.GA9807@freebie.xs4all.nl> References: <20050209120827.GD39864@tom.chem.tue.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050209120827.GD39864@tom.chem.tue.nl> X-OS: FreeBSD 4.11-RC2 User-Agent: Mutt/1.5.6i X-Virus-Scanned: by XS4ALL Virus Scanner cc: freebsd-hackers@freebsd.org cc: freebsd-stable@freebsd.org cc: freebsd-hardware@freebsd.org Subject: Re: NetMos NM9805 1284 Printer port X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2005 12:18:29 -0000 I'll stick it in -current later today. Wilko -- Wilko Bulte wilko@FreeBSD.org On Wed, Feb 09, 2005 at 01:08:27PM +0100, Willy Offermans wrote.. > Dear FreeBSD friends, > > I have sent the following e-mail 3 times before. I believe always to > freebsd-hackers, but I'm not sure. > > I'm running 5.3-RELEASE-p5 and downloaded the source yesterday. I > compiled the source and it works great, believe me. My boss is so > proud.... > > But I encounter a minor but annoying problem: > > <<>>> > > I have an additional LPT port: > > puc0@pci3:13:0: class=0x078000 card=0x00101000 chip=0x98059710 rev=0x01 hdr=0x00 > vendor = 'MosChip Semiconductors (Was: Netmos Technology)' > device = 'Nm9805 PCI + 1284 Printer Port' > class = simple comms > > I was able to get it work by adding the following to /usr/src/sys/dev/puc/pucdata.c > > /* Added by Willy@Rompen.nl 06/05/2004 */ > /* recommended by john@feith.com */ > > /* NetMos 0S1P PCI : 0S, 1P */ > { "NetMos NM9805 1284 Printer port", > { 0x9710, 0x9805, 0, 0 }, > { 0xffff, 0xffff, 0, 0 }, > { > { PUC_PORT_TYPE_LPT, 0x10, 0x00, 0x00 }, > }, > }, > > and to enable the puc driver in the kernel of course. > > Is it possible to add the data to /usr/src/sys/dev/puc/pucdata.c permanently? > > Thnx a lot, > > <<>>> > > This time I will sent it to three mailinglist at the same time, hoping > that someone picks it up. I was also looking for the maintainer of the > puc driver, but I couldn't figure out how to reach her or him. > > -- > Met vriendelijke groeten, > With kind regards, > Mit freundlichen Gruessen, > De jrus wah, > > Willy > > ************************************* > W.K. Offermans > Eindhoven University of Technology > Department of Chemical Engineering > Laboratory of Catalysis (SKA) > building ST-W 4.27, PO Box 513 > 5600 MB Eindhoven, Netherlands > Tel: +31 40 247 37 81 > Fax: +31 40 245 50 54 > Home: +31 45 544 49 44 > Mobile: +31 653 119 666 > e-mail: w.k.offermans@tue.nl > http://www.catalysis.nl > > Powered by .... > > (__) > \\\'',) > \/ \ ^ > .\._/_) > > www.FreeBSD.org > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" --- end of quoted text --- -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 9 12:52:03 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7387616A4CE for ; Wed, 9 Feb 2005 12:52:03 +0000 (GMT) Received: from walk.com.br (mail.walk.com.br [200.205.240.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id E169043D2D for ; Wed, 9 Feb 2005 12:52:01 +0000 (GMT) (envelope-from luiz@microeletronica.com.br) Received: (qmail 4177 invoked by uid 1006); 9 Feb 2005 12:51:57 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 9 Feb 2005 12:51:57 -0000 Date: Wed, 9 Feb 2005 10:51:57 -0200 (BRDT) From: Luiz Otavio Souza X-X-Sender: luiz@serv-qmp.walk.com.br To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= In-Reply-To: <42077D4E.1030604@DeepCore.dk> Message-ID: <20050209104136.D222@serv-qmp.walk.com.br> References: <20050206222416.O88635@serv-qmp.walk.com.br> <42071856.5080205@DeepCore.dk><42077D4E.1030604@DeepCore.dk> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-2117158322-1107953517=:222" cc: freebsd-hackers@freebsd.org Subject: Re: ATA_IDENTIFY timed out on ASUS P4VP-MX X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2005 12:52:03 -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-2117158322-1107953517=:222 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Mon, 7 Feb 2005, [ISO-8859-1] S=F8ren Schmidt wrote: > Luiz Otavio Souza wrote: > >> I tried the patch, and just get a different warning. >>=20 >> i'm attaching two dmesg, one with 5.3-RELEASE (with some extra debug inf= o)=20 >> and one for ATA-mIII. > > Hmm, seems interrupt arent getting through, not much I can do about that = one.=20 > Maybe -current can help as its interrupt routing code has changed quite a= =20 > bit. Otherwise try to get ahold of an updated BIOS ... > --=20 > > -S=F8ren Yep, this motherboard has some kind of problem on interrupt routing and i= =20 already running the lastest bios available. Thanks for your reply. Luiz Souza --0-2117158322-1107953517=:222-- From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 9 12:08:32 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D80116A4CE; Wed, 9 Feb 2005 12:08:32 +0000 (GMT) Received: from pastinakel.tue.nl (pastinakel.tue.nl [131.155.2.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22E9343D49; Wed, 9 Feb 2005 12:08:32 +0000 (GMT) (envelope-from willy@tom.chem.tue.nl) Received: by pastinakel.tue.nl (Postfix, from userid 40) id 4CFD114C021; Wed, 9 Feb 2005 13:08:31 +0100 (CET) Received: from tom.chem.tue.nl (tom.chem.tue.nl [131.155.80.7]) by pastinakel.tue.nl (Postfix) with ESMTP id 0C05814BE0D; Wed, 9 Feb 2005 13:08:28 +0100 (CET) Received: (from willy@localhost) by tom.chem.tue.nl (8.12.10/8.12.10/Submit) id j19C8Rkd040414; Wed, 9 Feb 2005 13:08:27 +0100 (CET) (envelope-from willy) Date: Wed, 9 Feb 2005 13:08:27 +0100 From: Willy Offermans To: freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org, freebsd-stable@freebsd.org Message-ID: <20050209120827.GD39864@tom.chem.tue.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on pastinakel.tue.nl X-Spam-DCC: CollegeOfNewCaledonia: pastinakel.tue.nl 1189; Body=1 Fuz1=1 Fuz2=1 X-Spam-Status: No, hits=-4.9 required=6.3 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Level: X-Mailman-Approved-At: Wed, 09 Feb 2005 13:11:25 +0000 Subject: NetMos NM9805 1284 Printer port X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: W.K.Offermans@TUe.nl List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2005 12:08:32 -0000 Dear FreeBSD friends, I have sent the following e-mail 3 times before. I believe always to freebsd-hackers, but I'm not sure. I'm running 5.3-RELEASE-p5 and downloaded the source yesterday. I compiled the source and it works great, believe me. My boss is so proud.... But I encounter a minor but annoying problem: <<>>> I have an additional LPT port: puc0@pci3:13:0: class=0x078000 card=0x00101000 chip=0x98059710 rev=0x01 hdr=0x00 vendor = 'MosChip Semiconductors (Was: Netmos Technology)' device = 'Nm9805 PCI + 1284 Printer Port' class = simple comms I was able to get it work by adding the following to /usr/src/sys/dev/puc/pucdata.c /* Added by Willy@Rompen.nl 06/05/2004 */ /* recommended by john@feith.com */ /* NetMos 0S1P PCI : 0S, 1P */ { "NetMos NM9805 1284 Printer port", { 0x9710, 0x9805, 0, 0 }, { 0xffff, 0xffff, 0, 0 }, { { PUC_PORT_TYPE_LPT, 0x10, 0x00, 0x00 }, }, }, and to enable the puc driver in the kernel of course. Is it possible to add the data to /usr/src/sys/dev/puc/pucdata.c permanently? Thnx a lot, <<>>> This time I will sent it to three mailinglist at the same time, hoping that someone picks it up. I was also looking for the maintainer of the puc driver, but I couldn't figure out how to reach her or him. -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Willy ************************************* W.K. Offermans Eindhoven University of Technology Department of Chemical Engineering Laboratory of Catalysis (SKA) building ST-W 4.27, PO Box 513 5600 MB Eindhoven, Netherlands Tel: +31 40 247 37 81 Fax: +31 40 245 50 54 Home: +31 45 544 49 44 Mobile: +31 653 119 666 e-mail: w.k.offermans@tue.nl http://www.catalysis.nl Powered by .... (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 9 14:36:29 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C5BC916A4CF for ; Wed, 9 Feb 2005 14:36:29 +0000 (GMT) Received: from agava.mipt.ru (ofc2.agava.net [81.5.88.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1ACF43D1F for ; Wed, 9 Feb 2005 14:36:28 +0000 (GMT) (envelope-from rzhe@agava.com) Received: by agava.mipt.ru (Postfix, from userid 426) id E1E4E720FF0; Wed, 9 Feb 2005 17:35:39 +0300 (MSK) Received: from mailhub (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 99C57721183 for ; Wed, 9 Feb 2005 17:35:39 +0300 (MSK) Received: from rzhe.agava-dubna.local (unknown [213.33.195.194]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by agava.mipt.ru (Postfix) with ESMTP id 1A5CF72116E for ; Wed, 9 Feb 2005 17:35:39 +0300 (MSK) Date: Wed, 9 Feb 2005 17:36:25 +0300 From: Dmitry Agaphonov To: freebsd-hackers@freebsd.org Message-Id: <20050209173625.29d50ffd.rzhe@agava.com> Organization: AGAVA Software X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i386-portbld-freebsd4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: kqueue & pthread X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2005 14:36:29 -0000 Hello all, There's a server application that use non-bloking sockets with kqueue in its main thread and blocking I/O in two auxiliary threads. While watching the server in top(1), I've noticed that it is in the 'poll' state instead of 'kqread'. And breaking the server process execution in the debugger drops to __sys_poll() instead of kevent(). So, the question is: does it really mean that linking to libc_r forces me to use poll (somehow internally?) and lose the benefit from using kqueue system? I'm using gcc-3.4.4 with -pthread option. FreeBSD version is 4.10-STABLE. Thanks. From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 9 14:42:04 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8499816A4CE for ; Wed, 9 Feb 2005 14:42:04 +0000 (GMT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C10143D3F for ; Wed, 9 Feb 2005 14:42:02 +0000 (GMT) (envelope-from mhersant@comcast.net) Received: from [192.168.2.102] (c-24-22-136-36.client.comcast.net[24.22.136.36]) by comcast.net (rwcrmhc13) with ESMTP id <2005020914415901500fupq3e>; Wed, 9 Feb 2005 14:41:59 +0000 Message-ID: <420A213A.2040503@comcast.net> Date: Wed, 09 Feb 2005 06:42:02 -0800 From: Matt User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: deleting jail X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2005 14:42:04 -0000 I'm trying to remove an old jail I don't use any more. From single user mode, I mount the relevant partition and try: prompt# rm - rf old_jail rm: old_jail/dumb/rcp: Operation not permitted rm: old_jail/dumb: Directory not empty rm: old_jail/lib/libcrypt.so.2: Operation not permitted rm: old_jail/lib/libc.so.5: Operation not permitted rm: old_jail/lib: Directory not empty rm: old_jail/libexec/ld-elf.so.1: Operation not permitted rm: old_jail/libexec: Directory not empty rm: old_jail/sbin/init: Operation not permitted rm: old_jail/sbin: Directory not empty rm: old_jail/usr/bin/ksu: Operation not permitted rm: old_jail/usr/bin/chpass: Operation not permitted rm: old_jail/usr/bin/chfn: Operation not permitted rm: old_jail/usr/bin/chsh: Operation not permitted rm: old_jail/usr/bin/ypchpass: Operation not permitted rm: old_jail/usr/bin/ypchfn: Operation not permitted rm: old_jail/usr/bin/ypchsh: Operation not permitted rm: old_jail/usr/bin/login: Operation not permitted rm: old_jail/usr/bin/opieinfo: Operation not permitted rm: old_jail/usr/bin/opiepasswd: Operation not permitted rm: old_jail/usr/bin/passwd: Operation not permitted rm: old_jail/usr/bin/yppasswd: Operation not permitted rm: old_jail/usr/bin/rlogin: Operation not permitted rm: old_jail/usr/bin/rsh: Operation not permitted rm: old_jail/usr/bin/su: Operation not permitted rm: old_jail/usr/bin/crontab: Operation not permitted rm: old_jail/usr/bin: Directory not empty rm: old_jail/usr/lib/libc_r.so.5: Operation not permitted rm: old_jail/usr/lib/libkse.so.1: Operation not permitted rm: old_jail/usr/lib/libthr.so.1: Operation not permitted rm: old_jail/usr/lib: Directory not empty rm: old_jail/usr/sbin/sliplogin: Operation not permitted rm: old_jail/usr/sbin: Directory not empty rm: old_jail/usr/home/jail/bin/rcp: Operation not permitted rm: old_jail/usr/home/jail/bin: Directory not empty rm: old_jail/usr/home/jail/sbin/init: Operation not permitted rm: old_jail/usr/home/jail/sbin: Directory not empty rm: old_jail/usr/home/jail/usr/bin/cu: Operation not permitted rm: old_jail/usr/home/jail/usr/bin/uucp: Operation not permitted rm: old_jail/usr/home/jail/usr/bin/uuname: Operation not permitted rm: old_jail/usr/home/jail/usr/bin/uustat: Operation not permitted rm: old_jail/usr/home/jail/usr/bin/uux: Operation not permitted rm: old_jail/usr/home/jail/usr/bin/man: Operation not permitted rm: old_jail/usr/home/jail/usr/bin/chpass: Operation not permitted rm: old_jail/usr/home/jail/usr/bin/chfn: Operation not permitted rm: old_jail/usr/home/jail/usr/bin/chsh: Operation not permitted rm: old_jail/usr/home/jail/usr/bin/ypchpass: Operation not permitted rm: old_jail/usr/home/jail/usr/bin/ypchfn: Operation not permitted rm: old_jail/usr/home/jail/usr/bin/ypchsh: Operation not permitted rm: old_jail/usr/home/jail/usr/bin/login: Operation not permitted rm: old_jail/usr/home/jail/usr/bin/opieinfo: Operation not permitted rm: old_jail/usr/home/jail/usr/bin/opiepasswd: Operation not permitted rm: old_jail/usr/home/jail/usr/bin/passwd: Operation not permitted rm: old_jail/usr/home/jail/usr/bin/yppasswd: Operation not permitted rm: old_jail/usr/home/jail/usr/bin/rlogin: Operation not permitted rm: old_jail/usr/home/jail/usr/bin/rsh: Operation not permitted rm: old_jail/usr/home/jail/usr/bin/su: Operation not permitted rm: old_jail/usr/home/jail/usr/bin/tip: Operation not permitted rm: old_jail/usr/home/jail/usr/bin/crontab: Operation not permitted rm: old_jail/usr/home/jail/usr/bin: Directory not empty rm: old_jail/usr/home/jail/usr/lib/libcrypt.so.2: Operation not permitted rm: old_jail/usr/home/jail/usr/lib/libc.so.4: Operation not permitted rm: old_jail/usr/home/jail/usr/lib/libc_r.so.4: Operation not permitted rm: old_jail/usr/home/jail/usr/lib/libcipher.so.2: Operation not permitted rm: old_jail/usr/home/jail/usr/lib: Directory not empty rm: old_jail/usr/home/jail/usr/libexec/ld-elf.so.1: Operation not permitted rm: old_jail/usr/home/jail/usr/libexec: Directory not empty rm: old_jail/usr/home/jail/usr/sbin/sliplogin: Operation not permitted rm: old_jail/usr/home/jail/usr/sbin: Directory not empty rm: old_jail/usr/home/jail/usr: Directory not empty rm: old_jail/usr/home/jail/var/empty: Operation not permitted rm: old_jail/usr/home/jail/var: Directory not empty rm: old_jail/usr/home/jail: Directory not empty rm: old_jail/usr/home: Directory not empty rm: old_jail/usr: Directory not empty rm: old_jail/var/empty: Operation not permitted rm: old_jail/var: Directory not empty rm: old_jail/: Directory not empty I saw a jail_delete utility in an older version of jailutils, but the newer version I built from ports doesn't have it. Thanks for any help. From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 9 14:48:29 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B97216A4CE for ; Wed, 9 Feb 2005 14:48:29 +0000 (GMT) Received: from mail.freebsd.org.cn (dns3.freebsd.org.cn [61.129.66.75]) by mx1.FreeBSD.org (Postfix) with SMTP id 29D7743D49 for ; Wed, 9 Feb 2005 14:48:19 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: (qmail 83164 invoked by uid 0); 9 Feb 2005 14:39:51 -0000 Received: from unknown (HELO beastie.frontfree.net) (219.239.99.7) by mail.freebsd.org.cn with SMTP; 9 Feb 2005 14:39:51 -0000 Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id 4CBC4134DCE; Wed, 9 Feb 2005 22:48:16 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46681-19; Wed, 9 Feb 2005 22:48:08 +0800 (CST) Received: by beastie.frontfree.net (Postfix, from userid 1001) id 2DE40132CE8; Wed, 9 Feb 2005 22:48:08 +0800 (CST) Date: Wed, 9 Feb 2005 22:48:08 +0800 From: Xin LI To: Matt Message-ID: <20050209144808.GA47422@frontfree.net> References: <420A213A.2040503@comcast.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline In-Reply-To: <420A213A.2040503@comcast.net> User-Agent: Mutt/1.4.2.1i X-GPG-key-ID/Fingerprint: 0xCAEEB8C0 / 43B8 B703 B8DD 0231 B333 DC28 39FB 93A0 CAEE B8C0 X-GPG-Public-Key: http://www.delphij.net/delphij.asc X-Operating-System: FreeBSD beastie.frontfree.net 5.3-RELEASE-p2 FreeBSD 5.3-RELEASE-p2 #15: Wed Dec 15 10:43:16 CST 2004 delphij@beastie.frontfree.net:/usr/obj/usr/src/sys/BEASTIE i386 X-URL: http://www.delphij.net X-By: delphij@beastie.frontfree.net X-Location: Beijing, China X-Virus-Scanned: by amavisd-new at frontfree.net cc: freebsd-hackers@freebsd.org Subject: Re: deleting jail X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2005 14:48:29 -0000 --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 09, 2005 at 06:42:02AM -0800, Matt wrote: > I'm trying to remove an old jail I don't use any more. From single user= =20 > mode, I mount the relevant partition and try: >=20 > prompt# rm - rf old_jail You need: rm -fr old_jail chflags -R noschg old_jail rm -fr old_jail Since some files are marked "schg". > I saw a jail_delete utility in an older version of jailutils, but the=20 > newer version I built from ports doesn't have it. Thanks for any help. Cheers, --=20 Xin LI http://www.delphij.net/ See complete headers for GPG key and other information. --AqsLC8rIMeq19msA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCCiKo/cVsHxFZiIoRAo1JAJ0XWtsR/V5uqiyVONnmhNpzexfptgCcC/DL TFhs/xpfZdC15lXe5HZHlR4= =XRB4 -----END PGP SIGNATURE----- --AqsLC8rIMeq19msA-- From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 9 14:49:26 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id B16E816A4CE; Wed, 9 Feb 2005 14:49:25 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.1/8.13.1) with ESMTP id j19EnPI4096050; Wed, 9 Feb 2005 09:49:25 -0500 (EST) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.1/8.13.1/Submit) id j19EnOHU096049; Wed, 9 Feb 2005 09:49:24 -0500 (EST) (envelope-from green) Date: Wed, 9 Feb 2005 09:49:24 -0500 From: Brian Fundakowski Feldman To: Dmitry Agaphonov Message-ID: <20050209144924.GB65523@green.homeunix.org> References: <20050209173625.29d50ffd.rzhe@agava.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050209173625.29d50ffd.rzhe@agava.com> User-Agent: Mutt/1.5.6i cc: freebsd-hackers@freebsd.org Subject: Re: kqueue & pthread X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2005 14:49:26 -0000 On Wed, Feb 09, 2005 at 05:36:25PM +0300, Dmitry Agaphonov wrote: > Hello all, > > There's a server application that use non-bloking sockets with kqueue in > its main thread and blocking I/O in two auxiliary threads. While watching > the server in top(1), I've noticed that it is in the 'poll' state instead > of 'kqread'. And breaking the server process execution in the debugger > drops to __sys_poll() instead of kevent(). > > So, the question is: does it really mean that linking to libc_r forces me > to use poll (somehow internally?) and lose the benefit from using kqueue > system? > > I'm using gcc-3.4.4 with -pthread option. FreeBSD version is 4.10-STABLE. > > Thanks. Since you're using user threads, not kernel threads, the kernel can only have one "object" (poll or select list, or kqueue file descriptor) to wait upon at any given time. Since kqueues are pollable, what happens is that the kqueue along with every other fd being polled/selected are all polled by a single poll(2) system call. Yes, your kqueue is being used, but it has an indirection of another poll(2) system call determining when your kevent(2) thread should be woken up. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 9 14:51:09 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B068016A4CE for ; Wed, 9 Feb 2005 14:51:09 +0000 (GMT) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52A7B43D2D for ; Wed, 9 Feb 2005 14:51:09 +0000 (GMT) (envelope-from mhersant@comcast.net) Received: from [192.168.2.102] (c-24-22-136-36.client.comcast.net[24.22.136.36]) by comcast.net (sccrmhc11) with ESMTP id <200502091451080110012d4re>; Wed, 9 Feb 2005 14:51:08 +0000 Message-ID: <420A235F.3030000@comcast.net> Date: Wed, 09 Feb 2005 06:51:11 -0800 From: Matt User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matt References: <420A213A.2040503@comcast.net> In-Reply-To: <420A213A.2040503@comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: deleting jail X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2005 14:51:09 -0000 Matt wrote: > I'm trying to remove an old jail I don't use any more. From single > user mode, I mount the relevant partition and try: > > prompt# rm - rf old_jail > > rm: old_jail/dumb/rcp: Operation not permitted > rm: old_jail/dumb: Directory not empty > rm: old_jail/lib/libcrypt.so.2: Operation not permitted > rm: old_jail/lib/libc.so.5: Operation not permitted > rm: old_jail/lib: Directory not empty > rm: old_jail/libexec/ld-elf.so.1: Operation not permitted > rm: old_jail/libexec: Directory not empty > rm: old_jail/sbin/init: Operation not permitted > rm: old_jail/sbin: Directory not empty > rm: old_jail/usr/bin/ksu: Operation not permitted > rm: old_jail/usr/bin/chpass: Operation not permitted > rm: old_jail/usr/bin/chfn: Operation not permitted > rm: old_jail/usr/bin/chsh: Operation not permitted > rm: old_jail/usr/bin/ypchpass: Operation not permitted > rm: old_jail/usr/bin/ypchfn: Operation not permitted > rm: old_jail/usr/bin/ypchsh: Operation not permitted > rm: old_jail/usr/bin/login: Operation not permitted > rm: old_jail/usr/bin/opieinfo: Operation not permitted > rm: old_jail/usr/bin/opiepasswd: Operation not permitted > rm: old_jail/usr/bin/passwd: Operation not permitted > rm: old_jail/usr/bin/yppasswd: Operation not permitted > rm: old_jail/usr/bin/rlogin: Operation not permitted > rm: old_jail/usr/bin/rsh: Operation not permitted > rm: old_jail/usr/bin/su: Operation not permitted > rm: old_jail/usr/bin/crontab: Operation not permitted > rm: old_jail/usr/bin: Directory not empty > rm: old_jail/usr/lib/libc_r.so.5: Operation not permitted > rm: old_jail/usr/lib/libkse.so.1: Operation not permitted > rm: old_jail/usr/lib/libthr.so.1: Operation not permitted > rm: old_jail/usr/lib: Directory not empty > rm: old_jail/usr/sbin/sliplogin: Operation not permitted > rm: old_jail/usr/sbin: Directory not empty > rm: old_jail/usr/home/jail/bin/rcp: Operation not permitted > rm: old_jail/usr/home/jail/bin: Directory not empty > rm: old_jail/usr/home/jail/sbin/init: Operation not permitted > rm: old_jail/usr/home/jail/sbin: Directory not empty > rm: old_jail/usr/home/jail/usr/bin/cu: Operation not permitted > rm: old_jail/usr/home/jail/usr/bin/uucp: Operation not permitted > rm: old_jail/usr/home/jail/usr/bin/uuname: Operation not permitted > rm: old_jail/usr/home/jail/usr/bin/uustat: Operation not permitted > rm: old_jail/usr/home/jail/usr/bin/uux: Operation not permitted > rm: old_jail/usr/home/jail/usr/bin/man: Operation not permitted > rm: old_jail/usr/home/jail/usr/bin/chpass: Operation not permitted > rm: old_jail/usr/home/jail/usr/bin/chfn: Operation not permitted > rm: old_jail/usr/home/jail/usr/bin/chsh: Operation not permitted > rm: old_jail/usr/home/jail/usr/bin/ypchpass: Operation not permitted > rm: old_jail/usr/home/jail/usr/bin/ypchfn: Operation not permitted > rm: old_jail/usr/home/jail/usr/bin/ypchsh: Operation not permitted > rm: old_jail/usr/home/jail/usr/bin/login: Operation not permitted > rm: old_jail/usr/home/jail/usr/bin/opieinfo: Operation not permitted > rm: old_jail/usr/home/jail/usr/bin/opiepasswd: Operation not permitted > rm: old_jail/usr/home/jail/usr/bin/passwd: Operation not permitted > rm: old_jail/usr/home/jail/usr/bin/yppasswd: Operation not permitted > rm: old_jail/usr/home/jail/usr/bin/rlogin: Operation not permitted > rm: old_jail/usr/home/jail/usr/bin/rsh: Operation not permitted > rm: old_jail/usr/home/jail/usr/bin/su: Operation not permitted > rm: old_jail/usr/home/jail/usr/bin/tip: Operation not permitted > rm: old_jail/usr/home/jail/usr/bin/crontab: Operation not permitted > rm: old_jail/usr/home/jail/usr/bin: Directory not empty > rm: old_jail/usr/home/jail/usr/lib/libcrypt.so.2: Operation not permitted > rm: old_jail/usr/home/jail/usr/lib/libc.so.4: Operation not permitted > rm: old_jail/usr/home/jail/usr/lib/libc_r.so.4: Operation not permitted > rm: old_jail/usr/home/jail/usr/lib/libcipher.so.2: Operation not > permitted > rm: old_jail/usr/home/jail/usr/lib: Directory not empty > rm: old_jail/usr/home/jail/usr/libexec/ld-elf.so.1: Operation not > permitted > rm: old_jail/usr/home/jail/usr/libexec: Directory not empty > rm: old_jail/usr/home/jail/usr/sbin/sliplogin: Operation not permitted > rm: old_jail/usr/home/jail/usr/sbin: Directory not empty > rm: old_jail/usr/home/jail/usr: Directory not empty > rm: old_jail/usr/home/jail/var/empty: Operation not permitted > rm: old_jail/usr/home/jail/var: Directory not empty > rm: old_jail/usr/home/jail: Directory not empty > rm: old_jail/usr/home: Directory not empty > rm: old_jail/usr: Directory not empty > rm: old_jail/var/empty: Operation not permitted > rm: old_jail/var: Directory not empty > rm: old_jail/: Directory not empty > > I saw a jail_delete utility in an older version of jailutils, but the > newer version I built from ports doesn't have it. Thanks for any help. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" > You can disregard this message. I now see that the schg flag is set on these files. Oops. From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 9 14:54:20 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEFE016A4CE for ; Wed, 9 Feb 2005 14:54:20 +0000 (GMT) Received: from mailout08.sul.t-online.com (mailout08.sul.t-online.com [194.25.134.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B57E43D1D for ; Wed, 9 Feb 2005 14:54:20 +0000 (GMT) (envelope-from mike@reifenberger.com) Received: from fwd00.aul.t-online.de by mailout08.sul.t-online.com with smtp id 1CytEQ-0007K8-04; Wed, 09 Feb 2005 15:54:18 +0100 Received: from fw.reifenberger.com (Z69UOmZF8ew-sNBT+sStV1IC4vP2QijxzVgF9A8EvlXzVagS+Mkxw0@[84.128.70.245]) by fmrl00.sul.t-online.com with esmtp id 1CytEO-1LOlea0; Wed, 9 Feb 2005 15:54:16 +0100 Received: from localhost (mike@localhost)j19EsF0F008513; Wed, 9 Feb 2005 15:54:15 +0100 (CET) (envelope-from mike@reifenberger.com) X-Authentication-Warning: fw.reifenberger.com: mike owned process doing -bs Date: Wed, 9 Feb 2005 15:54:14 +0100 (CET) From: Michael Reifenberger To: Matt In-Reply-To: <420A213A.2040503@comcast.net> Message-ID: <20050209154633.J8490@fw.reifenberger.com> References: <420A213A.2040503@comcast.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-ID: Z69UOmZF8ew-sNBT+sStV1IC4vP2QijxzVgF9A8EvlXzVagS+Mkxw0@t-dialin.net X-TOI-MSGID: 3ac23022-4f05-4304-a165-d68dc5b6606d cc: freebsd-hackers@freebsd.org Subject: Re: deleting jail X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2005 14:54:21 -0000 On Wed, 9 Feb 2005, Matt wrote: > Date: Wed, 09 Feb 2005 06:42:02 -0800 > From: Matt > To: freebsd-hackers@freebsd.org > Subject: deleting jail > > I'm trying to remove an old jail I don't use any more. From single user > mode, I mount the relevant partition and try: > > prompt# rm - rf old_jail > prompt# chflags -R noschg old_jail prompt# rm -rf old_jail Bye/2 --- Michael Reifenberger, Business Development Manager SAP-Basis, Plaut Consulting Comp: Michael.Reifenberger@plaut.de | Priv: Michael@Reifenberger.com http://www.plaut.de | http://www.Reifenberger.com From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 9 14:56:22 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E7E116A4CE for ; Wed, 9 Feb 2005 14:56:22 +0000 (GMT) Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A1D143D45 for ; Wed, 9 Feb 2005 14:56:21 +0000 (GMT) (envelope-from erik.u@dnainternet.net) Received: from b-188-250.dsl.kpy.customers.dnainternet.fi ([212.149.188.250]:57438smtp2.dnainternet.net with ESMTP id S1228840AbVBIO4U (ORCPT ); Wed, 9 Feb 2005 16:56:20 +0200 Message-ID: <420A2493.30607@dnainternet.net> Date: Wed, 09 Feb 2005 16:56:19 +0200 From: Erik Udo User-Agent: Mozilla Thunderbird 1.0 (X11/20050106) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matt References: <420A213A.2040503@comcast.net> In-Reply-To: <420A213A.2040503@comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: deleting jail X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2005 14:56:22 -0000 Matt wrote: > I'm trying to remove an old jail I don't use any more. From single user > mode, I mount the relevant partition and try: > > prompt# rm - rf old_jail > > rm: old_jail/dumb/rcp: Operation not permitted > rm: old_jail/dumb: Directory not empty > rm: old_jail/lib/libcrypt.so.2: Operation not permitted Try chflags -R noschg old_jail before rm. Some files are protected with no-touch fags :) From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 9 15:19:32 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2954F16A4CE for ; Wed, 9 Feb 2005 15:19:32 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id B313843D2F for ; Wed, 9 Feb 2005 15:19:31 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id j19FHxIZ023282; Wed, 9 Feb 2005 08:18:00 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 09 Feb 2005 08:19:56 -0700 (MST) Message-Id: <20050209.081956.118779478.imp@bsdimp.com> To: mike@Reifenberger.com From: "M. Warner Losh" In-Reply-To: <20050209154633.J8490@fw.reifenberger.com> References: <420A213A.2040503@comcast.net> <20050209154633.J8490@fw.reifenberger.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 cc: freebsd-hackers@freebsd.org cc: mhersant@comcast.net Subject: Re: deleting jail X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2005 15:19:32 -0000 In message: <20050209154633.J8490@fw.reifenberger.com> Michael Reifenberger writes: : prompt# chflags -R noschg old_jail : prompt# rm -rf old_jail I have a scrub script, but it uses '0' rather than 'noschg' to turn off any and all flags that might have been set. Since rm is about to happen, this is safe :-) Warner From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 9 15:20:30 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 34FEF16A4CE for ; Wed, 9 Feb 2005 15:20:30 +0000 (GMT) Received: from natco3.natcotech.com (natco3.natcotech.com [205.167.142.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id B79AD43D53 for ; Wed, 9 Feb 2005 15:20:29 +0000 (GMT) (envelope-from smartweb@leadhill.net) Received: from ibm.nlcc.us (lhr4-dial-12-28-49-177.natcotech.com [12.28.49.177]) by natco3.natcotech.com (Postfix) with ESMTP id 894C263046 for ; Wed, 9 Feb 2005 09:20:28 -0600 (CST) Received: (qmail 14649 invoked by uid 89); 9 Feb 2005 15:20:27 -0000 Received: from unknown (HELO ?192.168.0.2?) (billy@192.168.0.2) by ibm.nlcc.us with SMTP; 9 Feb 2005 15:20:27 -0000 Message-ID: <420A2A3B.2060507@leadhill.net> Date: Wed, 09 Feb 2005 09:20:27 -0600 From: Billy Newsom User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Cold Reboot (or cold restart) FreeBSD? locore.s hack attempt X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2005 15:20:30 -0000 I want to do a cold reboot of FreeBSD due to (what seens to be) a problem with the FreeBSD 5.3 system on my particular machine. To make a long story short, I have determined that FreeBSD 5.3 sputters and coughs when it tries to reboot this system. (The problem wasn't on 4.7, for example, and DOS can reboot the machine fine.) I believe the solution (barring a change of the kernel I'm not sure how to do) is to merely rewrite the code which send the command to reboot the system. I want to be able to do a shutdown -r now, or merely a "reboot" from single user mode, etc. and the system restart, do its full POST, count memory, and run properly. So here's my unified diff, which did not seem to work: -----------------Code --- locore.s Thu Jul 8 17:35:34 2004 +++ /usr/src/sys/i386/i386/locore.s Wed Feb 2 01:50:36 2005 @@ -214,7 +214,8 @@ movsb #else /* IBM-PC */ /* Tell the bios to warmboot next time */ - movw $0x1234,0x472 +/* movw $0x1234,0x472 */ + movw $0x0000,0x472 /* Billy: Perform Cold Reboot! */ #endif /* PC98 */ /* Set up a real frame in case the double return in newboot is executed. */ -----------------Code Recompiling my kernel and using that diff did not work. The system would still lock up and freeze when I attempted to do a shutdown -r now. The 0x472h address is supposed to point to a region of memory that the BIOS looks at when deciding to do a cold or warm restart. Perhaps doing this in locore.s is not working somehow, or that region of memory gets corrupted. So to see the full discussion of my problem in detail, see the archives of the freebsd-questions list: http://lists.freebsd.org/pipermail/freebsd-questions/2005-January/074567.html (my original post) Here's what I came up with: http://lists.freebsd.org/pipermail/freebsd-questions/2005-February/074728.html Well, so far I tried this hack: http://lists.freebsd.org/pipermail/freebsd-questions/2005-February/074867.html This problem is very weird, because only FreeBSD 5.3 seems to break the rebooting ability of this machine. The underlying problem might have to do with some sort of aggressive use of the BIOS memroy region or some reserved memory which causes a warm (or perhaps even the cold) reboot to fail. IF that's the case, is there a hack to reserve memory from FreeBSD's kernel so that these secret regions get left in tact? Other than that, would someone like to see if my hack of locore.s Works For Them? I'm curious to see if someone else's computer will perform the cold restart (count memory). This code region is apparently about 10 years old or more (pre-3.0.5), so it would be interesting to hack it now. As a side note, I believe that linux and others allow you to decide on which reboot flavor you prefer. Thanks, Billy From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 9 15:40:01 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD03A16A4CF; Wed, 9 Feb 2005 15:40:01 +0000 (GMT) Received: from agava.mipt.ru (ofc2.agava.net [81.5.88.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE53543D45; Wed, 9 Feb 2005 15:40:00 +0000 (GMT) (envelope-from rzhe@agava.com) Received: by agava.mipt.ru (Postfix, from userid 426) id E363371E0FA; Wed, 9 Feb 2005 18:39:11 +0300 (MSK) Received: from mailhub (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id A50A572151D; Wed, 9 Feb 2005 18:39:11 +0300 (MSK) Received: from rzhe.agava-dubna.local (unknown [213.33.195.194]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by agava.mipt.ru (Postfix) with ESMTP id 44B2B720E2B; Wed, 9 Feb 2005 18:39:11 +0300 (MSK) Date: Wed, 9 Feb 2005 18:39:52 +0300 From: Dmitry Agaphonov To: Brian Fundakowski Feldman Message-Id: <20050209183952.30f4c5b6.rzhe@agava.com> In-Reply-To: <20050209144924.GB65523@green.homeunix.org> References: <20050209173625.29d50ffd.rzhe@agava.com> <20050209144924.GB65523@green.homeunix.org> Organization: AGAVA Software X-Mailer: Sylpheed version 0.9.4claws (GTK+ 1.2.10; i386-portbld-freebsd4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: kqueue & pthread X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2005 15:40:02 -0000 On Wed, 9 Feb 2005 09:49:24 -0500 Brian Fundakowski Feldman wrote: BFF> Since you're using user threads, not kernel threads, the kernel can only BFF> have one "object" (poll or select list, or kqueue file descriptor) to wait BFF> upon at any given time. Since kqueues are pollable, what happens is BFF> that the kqueue along with every other fd being polled/selected are all BFF> polled by a single poll(2) system call. Yes, your kqueue is being used, BFF> but it has an indirection of another poll(2) system call determining BFF> when your kevent(2) thread should be woken up. Brian, thank a lot for your explanation! So, pthreads since they are user threads do not provide concurrency on multiprocessor systems? And by the way, are there another ways to have kernel threads in FreeBSD 4.x applications, rather than use LinuxThreads port or implement it via rfork'ed processes? From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 9 15:47:41 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8261616A4CE for ; Wed, 9 Feb 2005 15:47:41 +0000 (GMT) Received: from duchess.speedfactory.net (duchess.speedfactory.net [66.23.201.84]) by mx1.FreeBSD.org (Postfix) with SMTP id C67F443D3F for ; Wed, 9 Feb 2005 15:47:40 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 12308 invoked by uid 89); 9 Feb 2005 15:47:23 -0000 Received: from duchess.speedfactory.net (66.23.201.84) by duchess.speedfactory.net with SMTP; 9 Feb 2005 15:47:23 -0000 Received: (qmail 12167 invoked by uid 89); 9 Feb 2005 15:47:20 -0000 Received: from unknown (HELO palm.tree.com) (66.23.216.49) by duchess.speedfactory.net with SMTP; 9 Feb 2005 15:47:20 -0000 Received: from [127.0.0.1] (localhost.tree.com [127.0.0.1]) by palm.tree.com (8.12.10/8.12.10) with ESMTP id j19FlIw6017795; Wed, 9 Feb 2005 10:47:19 -0500 (EST) (envelope-from ups@tree.com) From: Stephan Uphoff To: Gerald Heinig In-Reply-To: <4209C640.3070502@syskonnect.de> References: <420731DD.3050206@syskonnect.de> <42088232.1030001@syskonnect.de> <1107888844.6309.221.camel@palm.tree.com> <4209C640.3070502@syskonnect.de> Content-Type: text/plain Message-Id: <1107964038.6309.1137.camel@palm.tree.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 09 Feb 2005 10:47:18 -0500 Content-Transfer-Encoding: 7bit cc: hackers@freebsd.org Subject: Re: Firewire blues X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2005 15:47:41 -0000 On Wed, 2005-02-09 at 03:13, Gerald Heinig wrote: > Stephan Uphoff wrote: > > There are two ways using kgdb to debug a target with firewire. > > The first way basically replaces the slow serial cable for communication > > to the remote target gdb stub. > > The second way uses the remote DMA capabilities of firewire to directly > > read memory of the target WITHOUT using any debugging software/stub on > > the target. (Think remote core file) > > > > Greg Lehey wrote a nice kernel debugging tutorial that explains both > > types of firewire debugging. > > http://www.lemis.com/grog/Papers/Debug-tutorial/tutorial.pdf > > > > This should get you started with only minor adjustments (gdb->kgdb) . > > This is actually the paper I'm using. I've followed the instructions on > both methods, but I can't get it to work. The direct machine-machine > connection is fine (ie. the one with dconschat). It's the kgdb > connection that doesn't work. > I presume it worked out of the box for you then? Once I linked in dcons, dcons_crom and firewire into the kernel everything worked. (I think only dcons is really needed - maybe a link set issue?) I only used the gdb stub method. Can you send me your dmesg? (After you linked the dcons stuff into the kernel) Stephan From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 9 15:51:38 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 4ECC016A4CE; Wed, 9 Feb 2005 15:51:38 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.1/8.13.1) with ESMTP id j19Fpb8R096389; Wed, 9 Feb 2005 10:51:37 -0500 (EST) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.1/8.13.1/Submit) id j19FparC096388; Wed, 9 Feb 2005 10:51:36 -0500 (EST) (envelope-from green) Date: Wed, 9 Feb 2005 10:51:36 -0500 From: Brian Fundakowski Feldman To: Dmitry Agaphonov Message-ID: <20050209155136.GC65523@green.homeunix.org> References: <20050209173625.29d50ffd.rzhe@agava.com> <20050209144924.GB65523@green.homeunix.org> <20050209183952.30f4c5b6.rzhe@agava.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050209183952.30f4c5b6.rzhe@agava.com> User-Agent: Mutt/1.5.6i cc: freebsd-hackers@freebsd.org Subject: Re: kqueue & pthread X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2005 15:51:38 -0000 On Wed, Feb 09, 2005 at 06:39:52PM +0300, Dmitry Agaphonov wrote: > On Wed, 9 Feb 2005 09:49:24 -0500 > Brian Fundakowski Feldman wrote: > > BFF> Since you're using user threads, not kernel threads, the kernel can only > BFF> have one "object" (poll or select list, or kqueue file descriptor) to wait > BFF> upon at any given time. Since kqueues are pollable, what happens is > BFF> that the kqueue along with every other fd being polled/selected are all > BFF> polled by a single poll(2) system call. Yes, your kqueue is being used, > BFF> but it has an indirection of another poll(2) system call determining > BFF> when your kevent(2) thread should be woken up. > > Brian, thank a lot for your explanation! > > So, pthreads since they are user threads do not provide concurrency on > multiprocessor systems? Right, the libc_r implementation specifically. > And by the way, are there another ways to have kernel threads in FreeBSD 4.x > applications, rather than use LinuxThreads port or implement it via rfork'ed > processes? The LinuxThreads library seems to be the best-supported way. I don't think that there should be legal/licensing issues using it. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 9 21:35:25 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B8FAD16A4CE for ; Wed, 9 Feb 2005 21:35:25 +0000 (GMT) Received: from corp.globat.com (corp.globat.com [216.193.201.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 510F343D1F for ; Wed, 9 Feb 2005 21:35:25 +0000 (GMT) (envelope-from drice@globat.com) Received: from globat.com (globat [66.159.202.156]) by corp.globat.com (8.12.11/8.12.9) with ESMTP id j19LZOxl095033 for ; Wed, 9 Feb 2005 13:35:24 -0800 (PST) (envelope-from drice@globat.com) From: David Rice Organization: Globat To: freebsd-hackers@freebsd.org Date: Wed, 9 Feb 2005 13:35:27 -0800 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502091335.27289.drice@globat.com> Subject: Fatal trap 12: page fault while in kernel mode - HELP! X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2005 21:35:25 -0000 We have two NFS file servers running FreeBSD 5.2.1-RELEASE-p9 on Dell Poweredge 1750's that crash randomly. They each have about 1.3TB of disk. They are used to server email and web content to several WEB/EMAIL servers. Followin is the console log messages and the kernel boot messages. Any ideas as to what the problem may be? eme: fvp == tvp (can't happen) ufs_rename: fvp == tvp (can't happen) ufs_rename: fvp == tvp (can't happen) ufs_rename: fvp == tvp (can't happen) ufs_rename: fvp == tvp (can't happen) Feb 9 07:57:31 dst5 kernel: pid 14842 (send_nsca), uid 0: exited on signal 11 (core dumped) ufs_rename: fvp == tvp (can't happen) ufs_rename: fvp == tvp (can't happen) ufs_rename: fvp == tvp (can't happen) ufs_rename: fvp == tvp (can't happen) ufs_rename: fvp == tvp (can't happen) Feb 9 09:23:55 dst5 kernel: pid 20246 (send_nsca), uid 0: exited on signal 11 (core dumped) ufs_rename: fvp == tvp (can't happen) ufs_rename: fvp == tvp (can't happen) ufs_rename: fvp == tvp (can't happen) Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 06 fault virtual address = 0x20 fault code = supervisor read, page not present instruction pointer = 0x8:0xc056471f stack pointer = 0x10:0xe1b19920 frame pointer = 0x10:0xe1b199b8 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 = 61 (swi1: net) kernel: type 12 trap, code=0 Stopped at tcp_output+0xf: movl 0x20(%esi),%eax db> db> db> -------------------------------------------------------------------------------------------------------------- The Regents of the University of California. All rights reserved. FreeBSD 5.2.1-RELEASE-p9 #1: Wed Sep 1 18:39:24 PDT 2004 root@dst5.globat.com:/usr/obj/usr/src/sys/DST5 Preloaded elf kernel "/boot/kernel/kernel" at 0xc07c9000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc07c921c. ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 2.40GHz (2387.13-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff real memory = 1073573888 (1023 MB) avail memory = 1037717504 (989 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 6 ioapic0: Changing APIC ID to 8 ioapic1: Changing APIC ID to 9 ioapic2: Changing APIC ID to 10 ioapic0 irqs 0-15 on motherboard ioapic1 irqs 16-31 on motherboard ioapic2 irqs 32-47 on motherboard Pentium Pro MTRR support enabled npx0: [FAST] stray irq13 npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 pcibios: BIOS version 2.10 Using $PIR table, 7 entries at 0xc00fc4a0 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_cpu0: on acpi0 acpi_cpu1: on acpi0 acpi_cpu2: on acpi0 device_probe_and_attach: acpi_cpu2 attach returned 6 acpi_cpu2: on acpi0 device_probe_and_attach: acpi_cpu2 attach returned 6 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib0: slot 15 INTA is routed to irq 15 pci0: at device 14.0 (no driver attached) pci0: at device 15.2 (no driver attached) isab0: at device 15.3 on pci0 isa0: on isab0 pcib1: on acpi0 pci4: on pcib1 mpt0: port 0xdc00-0xdcff mem 0xfcb20000-0xfcb2ffff,0xfcb30000-0xfcb3ffff irq 18 at device 5.0 on pci4 mpt1: port 0xd800-0xd8ff mem 0xfcb00000-0xfcb0ffff,0xfcb10000-0xfcb1ffff irq 19 at device 5.1 on pci4 pcib2: on acpi0 pci3: on pcib2 amr0: mem 0xfcc00000-0xfcc0ffff irq 24 at device 6.0 on pci3 amr0: Firmware 350O, BIOS 1.09, 128MB RAM pcib3: on acpi0 pci2: on pcib3 bge0: mem 0xfcf20000-0xfcf2ffff,0xfcf30000-0xfcf3ffff irq 16 at device 0.0 on pci2 bge0: Ethernet address: 00:0f:1f:66:34:0e miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge1: mem 0xfcf00000-0xfcf0ffff,0xfcf10000-0xfcf1ffff irq 17 at device 0.1 on pci2 bge1: Ethernet address: 00:0f:1f:66:34:0f miibus1: on bge1 brgphy1: on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto pcib4: on acpi0 pci1: on pcib4 fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A, console acpi_cpu2: on acpi0 device_probe_and_attach: acpi_cpu2 attach returned 6 acpi_cpu2: on acpi0 device_probe_and_attach: acpi_cpu2 attach returned 6 orm0: